protop storage areas - Forum - OpenEdge RDBMS - Progress Community
 Forum

protop storage areas

This question is answered

At what point do you recommend adding an extent to replace the variable extent?

I have a fixed extent that is full and the variable at 86% of the size of the fixed.  

>  25 Index_Txn3              1000000    856440   1856440   1856316       124    186% 

Plenty of disk space so not worried there.  

Verified Answer
  • You have a decision to make.  You are either going to try to stay ahead of things and (try to) add fixed extents before you start writing to the variable extent *or* you might decide that you're not worried about that and you will just let the fixed extents grow.

    For many people with small to medium databases the "don't worry about it" option makes a lot of sense.

    If you have a larger database then you might want to be more proactive.

    Personally I'm not calling anything less than 1TB "large" anymore and it doesn't really bother me to see 64GB extents.  Other people have other opinions.  You do need to be careful about getting carried away -- there is a very hard limit of 1TB for an extent and there is no recovery if you try to exceed it.

    In that case the metric that you probably want to pay attention to is %LastX.  That is the percentage full of the last variable extent.  

    In your case, since you are already writing to the variable extent, so %LastX should be 100%.  If so then it is too late to be proactive, you have already overflowed, but that's ok, you just end up with a funky sized extent in the middle of all the others.

    If you are going to be actively managing things commercial ProTop has an alert that fires when the last fixed extent reaches a threshold (generally 80%).  (Free ProTop does not fire any alerts.)

    --
    Tom Bascom
    tom@wss.com

All Replies
  • You have a decision to make.  You are either going to try to stay ahead of things and (try to) add fixed extents before you start writing to the variable extent *or* you might decide that you're not worried about that and you will just let the fixed extents grow.

    For many people with small to medium databases the "don't worry about it" option makes a lot of sense.

    If you have a larger database then you might want to be more proactive.

    Personally I'm not calling anything less than 1TB "large" anymore and it doesn't really bother me to see 64GB extents.  Other people have other opinions.  You do need to be careful about getting carried away -- there is a very hard limit of 1TB for an extent and there is no recovery if you try to exceed it.

    In that case the metric that you probably want to pay attention to is %LastX.  That is the percentage full of the last variable extent.  

    In your case, since you are already writing to the variable extent, so %LastX should be 100%.  If so then it is too late to be proactive, you have already overflowed, but that's ok, you just end up with a funky sized extent in the middle of all the others.

    If you are going to be actively managing things commercial ProTop has an alert that fires when the last fixed extent reaches a threshold (generally 80%).  (Free ProTop does not fire any alerts.)

    --
    Tom Bascom
    tom@wss.com

  • Just want to share with you that in OE 12.1, we have added some new features to managing variable length extents. For example, you can use the "e" attribute in the .st file to extend a variable length extent to certain fixed size, then add a new variable extent (which can use the "x" attribute to pre-extend it to certain size).

    By doing this, you can avoid the "funky sized extent in the middle of all the others".

  • Opinions will vary and it may get religious.  I have seen many different type of implementation for storage areas and sizes of extents.  Some made sense to me, others had me shaking my head.  In my opinion, each Storage Area should be made up of us less than 10 extents (files).  If the storage area is less than 10 GB, then 1 or 2 extents are fine.  Large storage areas require larger extents, but there is no need to have 5 extents for a storage area that is less than 1 GB.  Yes, I have seen this many times.
     
    I think what happens at times is that someone did something that made sense 10 years ago when the database was 20 GB, and now the database is 200 GB and the storage area design hasn’t been updated, so same sized files are added to storage areas that are growing so now the database is made up of a large number of smaller files.
     
    Final word on extent sizes.  If your machine is fast (both CPU and Disk), then you can have large files.  If the machine is slower, then you need smaller files.  If you can do a database repair scan on a 64 GB extent in an hour or so, then 64 GB is a fine size.  But if it takes 5-10 hours, then it is too large.  I say this because all the repair utilities are based on extents.  They can’t start in the middle of an extent, they always start either at the beginning or end of an extent to do it’s scanning.  This will affect any disastrous repair downtime dramatically.  And I know, no one ever thinks they will need to use these repair utilities.  But if that was the case, we would have not built them.
     
    Mike
    -- 
    Mike Furgal
    Director – Database and Pro2 Services
    PROGRESS
    617-803-2870