After-Imaging Info (^a)
Ask the experts if you think you need more or less than 8 extents.
|ProTop RT Label||Alertable Metric*||Description|
|Extent||N/A||Name of the extent|
|Extent Type||aiExtType||Type of extent: variable or fixed|
|Size||aiSize||Size of the AI extent|
|AI Seq#||aiSeqNum||Sequence number (not extent number) of the AI file since after-imaging was enabled|
|Status||aiStatus||See table below|
|Last Op||aiLastOp||Timestamp of last operation performed on this extent|
*Requires data collector "aiInfo" in pt3agent.cfg. With the commercial version of ProTop, you can configure alerts using the metric names in this column. For a full list of metrics, see the Alertable Metrics section.
AI File Status
|Empty||Extents that are available for use|
|Busy||The extent where database changes are currently being written. There can only be one busy extent|
|Locked||Full extents containing database changes not yet replicated to the replication target database(s).|
|Full||Extents that contain database changes that have not yet been recycled.|
Insights into After-Imaging
AI Seq#: Once AI is activated, every AI file containing database changes is assigned a sequential number. The busy AI file, and hence the sequence number, changes when:
- An extent change is triggered manually (rfutil DB -C aimage new)
- An extent change is triggered by the AI File Management Daemon (AIMGT)
- A probkup is started, which automatically triggers an extent change
- A quiet point is enabled, which automatically triggers an extent change
Full AI Files: These need to be archived and emptied so that they can be reused. Normally this is done automatically by the AIMGT but some people still use their own AI rotation scripts.
Locked AI Files: When OpenEdge Replication is enabled, database changes in the AI files must be replicated to the target database(s), meaning that a full AI file cannot be emptied unless all the changes it contains have been successfully written to the target(s). Until those writes occur, the full AI files remain locked, preventing them from being emptied and recycled.
Archiving: It is imperative that you rotate AI files frequently and that you move the archived AI files off the production server, preferably out of the production data center. We often come across environments where the AI files are rotated every 15 minutes but only copied off the server once per day. What happens if the server crashes or the disks are corrupted?
Note that we do not suggest configuring the AIMGT to archive directly to a network-mounted drive as we have experienced issues with this configuration on numerous occasions. Instead, configure the AIMGT to archive to a local directory, then script a transfer to a secure offsite location.
Purging: There is no built-in functionality to purge AI archives so you will need to script this yourself. There is an example aipurge.shx script available in the $PROTOP/bin subdirectory.
Monitoring: You must monitor the status of your AI extents. You can easily write your own scripts to scrape the output from "rfutil DB -C aimage list", or write some 4GL code to read the VSTs, or simply use the commercial version of ProTop.