Estimating AI CapacityThe closest estimate on AI capacity can be found by knowing the current BI file capacity needs, particularly in environments where After-imaging has not yet been enabled.
Beginning in OpenEdge version 10.x changes to the architecture made AI and BI notes more similar it should be expected that AI notes will equal BI notes.
(Prior to version 10.x typically 1.5 more bytes are written to an AI buffers and files than are written to the BI buffers and files.)
By monitoring the BI writes with the PROMON utility in the BI Log Activity Display over a sampling interval, the BI "Bytes written” statistic will provide an estimate of the space required for an AI file for the same period of activity.
Sampling Metrics : Sample BI Checkpoints to estimate AI Capacity
Estimate AI file size using the BI Cluster size and the number of Checkpoints
- Find the BI Cluster size : PROMON > 7. Database Status : “Before image cluster size”
- Record the number of Checkpoints over the Sampling period: PROMON > 5. Activity : Checkpoints
- Multiply the BI Cluster size by the number of Checkpoints [ minimum size to record transaction notes ]
- Multiply the previous result by the period between backups [ disk capacity for archived ai extents ]
Example: If an AI file is intended to hold all changes made in an hour, determine how many checkpoints occur during that 1 hour time period of peak activity.
a. Each bi-cluster is 8 MB
b. 4 checkpoints in 1 hour, 100 checkpoints per 24 hours
c. AI files need to be at least 32 MB to record 1 hours of activity
d. 768 MB of disk space are needed to archive 1 day's AI activity daily backups, assuming the same load !
Sampling Metrics : Sample BI Statistics to plan AI CapacityDeciding on the sampling period to record the BI statistic, requires an understanding of application usage. Typically workload varies from day to day, peaking at daily scheduled batch processing times and end-of-month/year processing. Recording the amount of BI writes during these peak periods will provide sufficient metrics to ensure enough AI space is available to handle peak days. When the workload grows in future and if AI file size and switching frequency were correctly scoped, increasing the amount of space available for AI files is then a simple matter of either changing the frequency of ai switches or adding additional AI files to the database structure.
Sampling BI statistic information can be taken in 2 formats:
a) Capture the
Total Bytes Written, where the Sampling period is over the complete peak time.
- This will provide a maximum AI file capacity metric, which can then be divided over multiple AI files that are switched when either fixed size is reached or variable AI files that are switched at a configured time interval.
- For example; if the busy period lasts 1 hour then capture a sample of the Total BI writes for the complete hour.
b) Capture smaller
Bytes Written samples over a typical 24-hour period, where the Sampling period is the estimated AI Switch time.
- This will provide a metric for AI extent sizing, the number of AI files needed and the diskspace needed to archive a day's worth of AI files.
To Sampling BI writes metrics:
0. Start a PROMON session against a running production database:
$ promon <dbname>
1. Set the Sampling Interval to be recorded
- PROMON menu > R&D > 5. Adjust Monitor Options > 3. Monitor sampling interval: <seconds>
- Enter: “T” to return to the top R&D menu.
2. Gather BI Write Metrics
- PROMON R&D menu > 2. Activity Displays > 5. BI Log:
- Enter: “S” to enable the Sampling interval.
The Total column of the
"Bytes written" line, shows the total bytes written to the before image file for the Sampling interval selected.
- Selecting “L” will show these metrics since start-up of the database.
- “?” provides further information on promon monitoring options.
Example: In this environment,
161 MB of AI file space would be needed to record these 30 minutes of AI transaction activity. How those AI files are structured is an implementation decision, for example:
- n x fixed AI extents, that automatically switch when their fixed size is reached or otherwise when specifically switched (4 x 40 MB fixed extents + 1).
- n x variable AI extents, that switch at a configured time (10 minutes, 3 variable extents + 1)
Sampling for 1800 seconds ....
{date} Activity: BI Log
{time} {date} {time} to {date} {time} (30 min 00 sec)
Total Per Min Per Sec Per Tx
Total BI writes 10,849 361.63 6.03 124.70
BIW BI writes 9,731 324.37 5.41 111.85
Records written 635,233 21,174.43 352.91 7301.53
Bytes written 164431K 5,612,578.13 93,542.97 1935375.63
Total BI Reads 294 9.80 0.16 3.38
Records read 0 0.00 0.00 0.00
Bytes read 0 0.00 0.00 0.00
Clusters closed 80 2.67 0.04 0.92
Busy buffer waits 502 16.73 0.28 5.77
Empty buffer waits 13 0.43 0.01 0.15
...
Further Considerations:
Having obtained the AI sizing metrics, leaves decisions on:
a. Fixed or Variable AI extent structure.
- Fixed AI extents will automatically switch when the fixed size is reached.
- Variable AI or Fixed AI extents will switch when manually instructed with RFUTIL –C AIMAGE NEW, -aiarcinterval or ulimits are reached.
- PROBKUP (unless -norecover is specified) or PROQUIET (unless nolock is specified) will trigger either extent types to automatically switch.
b. The number of AI extents and the frequency that AI extents are switched.
AI files are recycled for use as soon as they become available (ie status = EMPTY). Assuring AI space is available, depends on how they are managed.
In an ideal world, 3 AI files are needed:
- a FULL AI extent which needs to be managed,
- a current BUSY AI extent being written to,
- and an EMPTY AI extent available for the current BUSY extent to be switched to.
In the real world, more than 3 AI files should always be configured. As a 'rule of thumb', at least enough AI file space is needed to cover a 'worst case' situation which would be (say) from Friday to Monday when the system is unattended and the unexpected happens. For example:
- The AI management routine is for some reason unable to archive FULL extents and make them available.
- Replication terminates while source activity continues, leaving all AI extents LOCKED as they are switched, therefore unavailable for re-use.
Under these conditions when there are no available ai files to switch to the database will SHUT DOWN, unless the
“-aistall” database startup parameter is in effect. With this parameter in use, the database will instead stall until manual intervention provides an AI file available to switch to again.
Once the after-image areas have been sized, the AI Management strategy needs to assure there is always space available to write in the current BUSY extent and switch to an available EMPTY extent when needed with sufficient archive space to save copies of used extents before they are emptied for re-use.
Managing AI extents means backing up and emptying out FULL AI extents so that when the current BUSY extent is switched (manually with RFUTIL -C AIMAGE NEW, automatically triggered when: a fixed extent size is reached, -aiarcinterval, during PROBKUP or PROQUIET) the next AI extent in sequence is an available EMPTY extent that can be switched to and continue recording AI transaction notes.
In OpenEdge Replication enabled environments, AI files cannot be re-used if they are LOCKED by replication (iow: they first need to be processed against the target database before they are marked as FULL). Only once they have been processed against the target database are they unlocked by the Replication Service and marked FULL so that they can be managed.
Managing AI extents is therefore the process of archiving the FULL AI extents, then marking them as EMPTY so that they can be re-used. Since OpenEdge 10.1C, the AI ARCHIVER feature makes managing AI files on Enterprise Databases really easy and is dynamically configurable in terms of switching extents and where these are archived. Otherwise this process needs to be scripted with a combination of OS copy and RFUTIL commands ( (RFUTIL -C AIMAGE NEW | EXTRACT | EMPTY).
