ProTop Knowledge Base

Managing extent size

Does ProTop tell me when it is time to add a new fixed and or variable extent to my OpenEdge database? It can.

Mind the following points:

keep your extents manageable (250GB to 500GB); moderate-sized extents are easier to move around
don't hit the 1 TB limit for an extent (unrecoverable)
you don't need to use fixed extents
monitor the usage of your last fixed extent and avoid growing your variable extent
watch the size of your variable extent as it grows

ProTop monitors several database extent-related metrics via etc/alert.cfg to keep your extent management honest by letting you know when you might be approaching a limit that will impinge upon your chosen extent management approach. All of these are in etc/alert.cfg except where noted otherwise:

lrgExtent - the largest extent in the database; monitor this to prevent any extent from reaching 1 TB
hasVar - alerts when an area has no variable extent; there should always be a variable extent for every area, whether you plan to use it or have it just for overflow; it is possible to forget to add a variable extent after adding a new fixed extent.
NOTE: "yes" means there is an uncapped or "pure" variable extent (i.e., "v"). If an xv extent is in use, then, even though it is “variable,” it has a cap and, thus, hasVar should be “no.”
pctLastX - percent used of the last fixed extent (export PCTLASTX=yes in bin/localenv to enable); if you prefer to manage fixed extents, this will alert you when the last fixed extent has reached 85% utilized so you can prepare to add a new extent. This also applies to variable extents with a configured maximum size (or cap).
areaMaxPct - percent of maximum area size used; important to watch, especially when large files are not enabled and or you using Type I storage areas and small database block sizes
fsPctUsed - percent of disk space used (specific file systems can be monitored with alert filters)
varGB - this size of the storage area's variable extent in GB. This alertable metric is not in etc/alert.cfg by default. It is found in the StorageAreas Data Collector. Alerting on this metric is discussed below.

Managing your database space using variable extents

When using the variable extent management approach, you define a variable extent for each application data and index area in your database. Then you allow the database to grow those variable extents as needed. Typically you have a manageable extent size you prefer to work with (say ~250GB), and you want to know when any of your variable extents are around that size to stop that extent from growing further.

For this approach, we use the varGB alertable metric found in the StorageArea data collector as mentioned above. To be alerted once each day when a variable extent has reached and or passed 250GB:

Be sure the StorageAreas data collector name is in the ptInitDC variable in etc/pt3agent.*.cfg. It is included by default. If it has been removed for some reason, please replace it in the list. If you changed ptInitDC, restart ProTop by removing tmp/*.flg. ProTop will restart shortly.

Now add the following line to your etc/alert.*.cfg file:

varGB   num   >=   250   ""   "daily"   "Variable Extent &1 &2 &3"   alert

ProTop will automatically read this change to the alert configuration file, start monitoring the variable extents, and alert you when any grows to 250GB or more.

Add a new variable extent

When you receive the alert you defined above, simply add a new variable extent. This can be done online or offline with these steps:

1. create a file called "add.st" (any name will do) describing the new extent like the current variable extent.
2. add the new extent with this command:
```
prostrct [add|addonline] <dbname> add.st
```
  The current variable extent is fixed at its current size and the new variable extent is added.
3. generate an updated structure definition file, and you are done:
```
prostrct list <dbname>
```

Pros

No maintenance window is needed; the database can remain online
Database disk space consumption is organic

Cons

Extents will grow in place during the business day (though users are unlikely to feel it, read the argument here)
All connected sessions must have permission to access the new area
Fixed extent sizes will not likely be the same size

Managing your database with fixed and variable extents

When using the fixed extent approach, you still have a variable extent defined for each application storage area, but only as a backup to your fixed extent approach; this is considered an OpenEdge database best practice. Should a last fixed extent fill (you missed the alert to add a new extent, for instance, because it grew too fast, etc.) and you do not have a variable extent defined, the database cannot grow and will shut down.

This approach involves monitoring the space used in the last fixed extent rather than the growth of the variable extent as described above. It relies on the pctLastX alert, which exists in etc/alert.cfg by default:

pctLastX num > 85 "" "daily" "Last fixed extent &1 &2 &3" alert # export PCTLASTX=yes in bin/localenv to enable

But, as the comment at the end of the above indicates, it has to be enabled.

To be alerted once a day when any last fixed extent is 85% used:

Be sure the StorageAreas data collector name is in the ptInitDC variable in etc/pt3agent.*.cfg. It is included by default. If it has been removed for some reason, please replace it in the list.
Uncomment the line in your bin/localenv[.bat] containing PCTLASTX (if bin/localenv[.bat] is not there, copy bin/localenv.[bat]x to bin/localenv[.bat]). It will look like this:
```
export PCTLASTX=yes  # turns ON alerts for the last fixed extent becoming close to full
```
Restart ProTop by removing tmp/*.flg files. ProTop will restart shortly.

When you receive an alert with the subject "Last fixed extent [num] > 85", follow these steps to add new fixed and variable extents. NOTE: This must be done offline as you have to remove the existing variable extent which cannot be done online.

create an "add.st" that defines a new fixed extent (like the last fixed extent) and a variable extent (like the current variable extent)
stop the database in a maintenance window
remove the unused variable extent:
```
prostrct remove <dbname> d [area-name]
```
add the new fixed and variable extents:
```
prostrct add <dbname> add.st
```
generate an updated structure file:
```
prostrct list <dbname>
```
restart the database

Pros

extents can be managed to a precisely consistent size
extents will not grow in place during the business day

Cons

must be done offline
will pre-allocate disk space that cannot be used by other areas if this area stops growing