Recommended Max Extent Size

lkeller

New Member
We are running Progress 11.7.3. I was wondering if Progress has a recommended max extent size. Does anyone happen to know? Many years ago it couldn't be over 2GB but then they gave us the ability to enable large files which allowed for larger extent sizes.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Service pack 3 of release 11.7 shipped in May of 2018, almost five years ago. You should update to 11.7.17; there is no cost other than your time.

The maximum size of a data extent is 2 GB when the large file support feature is not enabled, and 1 TB when it is enabled. Prior to 12.0, large file support was only available with the Enterprise RDBMS license. This feature should be enabled in all databases where it is possible to do so.

My personal comfort zone for extent size is to keep them to at most a double-digit number of GB, say 20 to 50. Other people may have different preferences, given their experiences and the size of the databases they work with.
 

TomBascom

Curmudgeon
I don't even raise an eyebrow at 16GB extents. I do frown severely when I see that someone is limiting themself to 2GB extents.

You probably don't really want to get into 100GB+ extents though. There are some utilities (like dbrpr) that can be used on individual extents (if needed) and having really huge extents can make that awkward.

If I am starting to see extents in the 16GB+ range then I also expect that they are part of a storage area that has a single very large table (or its indexes or LOBs) assigned to it. If your database is that large you should be implementing targeted areas rather than lumping everything into a small number of areas. (Obviously your storage areas should be type 2 areas - no application data should ever be in type 1 storage).

And you definitely do not want to run into the 1TB limit - it is not recoverable if you have that misfortune.
 

lkeller

New Member
Service pack 3 of release 11.7 shipped in May of 2018, almost five years ago. You should update to 11.7.17; there is no cost other than your time.

The maximum size of a data extent is 2 GB when the large file support feature is not enabled, and 1 TB when it is enabled. Prior to 12.0, large file support was only available with the Enterprise RDBMS license. This feature should be enabled in all databases where it is possible to do so.

My personal comfort zone for extent size is to keep them to at most a double-digit number of GB, say 20 to 50. Other people may have different preferences, given their experiences and the size of the databases they work with.
Thanks for the information @Rob Fitzpatrick . I was just curious to see if there were any recommendations or if a certain size, say over 100 GB was considered bad perhaps due to performance.
 

lkeller

New Member
I don't even raise an eyebrow at 16GB extents. I do frown severely when I see that someone is limiting themself to 2GB extents.

You probably don't really want to get into 100GB+ extents though. There are some utilities (like dbrpr) that can be used on individual extents (if needed) and having really huge extents can make that awkward.

If I am starting to see extents in the 16GB+ range then I also expect that they are part of a storage area that has a single very large table (or its indexes or LOBs) assigned to it. If your database is that large you should be implementing targeted areas rather than lumping everything into a small number of areas. (Obviously your storage areas should be type 2 areas - no application data should ever be in type 1 storage).

And you definitely do not want to run into the 1TB limit - it is not recoverable if you have that misfortune.
Thanks Tom for your feedback. I'm not familiar with dbrpr but I will look into it. We have one extent that is much larger than the others so I probably need to determine what is being written there.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I'm not familiar with dbrpr but I will look into it.
It is a proutil qualifier but it is undocumented and unsupported. You may find some KB articles that reference it.

Note that in the wrong hands it can damage a database, even fatally, so exercise due caution. If you want to experiment, run it on a throwaway copy of a database that you care about, rather than on the original.
 
Top