Kbase P162697: How to determine if an area is reaching Type I storage area size limits?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
8/16/2010 |
|
Status: Verified
GOAL:
How to determine if an area is reaching Type I storage area size limits?
GOAL:
How to use dbanalys to identify if an area is approaching Type I storage area size limits?
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.x
FIX:
The output from dbanalys option to proutil can be analyzed to identify if an area is reaching areas size limits.
1. proutil dbname -C dbanalys > dbanalys.out
2. Look at the area within the dbanalys.out file that is in question of approaching the Type I storage area size limits.
Example:
AREA "Cust_data" : 22 BLOCK ANALYSIS
-------------------------------------------------
8315912 block(s) found in the area.
Current high water mark: 7510818
0 free block(s) found in the area
7510816 record block(s) found in the area
0 index block(s) found in the area
805094 empty block(s) found in the area
1 object block(s) found in the area
A Type I storage area for an 8 KB database block size with 256 records per block is limited to:
Maximum # of blocks per Storage Area** = 8,388,608
Maximum physical size of Storage Area per DB blocksize (in GB) = 64 GB
For databases areas with a database block size of 1 KB or 2 KB and 128 or 256 RPB (records per block), 1 GB of space is reserved for crash recovery purposes. Other database block sizes and records per block combinations have a 5 GB reserve.
This space is reserved for growth during crash recovery once an area has reached its maximum user addressable area size. If an area is close to reaching the maximum user addressable size, there is a possibility on a subsequent database startup when we are going through crash recovery, we could grow into this space. Growth into this reserve space would be dependant upon how close to limits an area was and what transactions needed to be undone and redone as a part of crash recovery associated with that area.
When going through crash recovery, no message is posted to the database log file to indicate that as a part of the crash recovery process we have now entered this reserved space. A message is not posted because the purpose of reserved space is to allow a database to go through crash recovery when user addressable space for an area has been exhausted. This is important to know because unless a Database Administrator is monitoring the growth of areas within a database, they may not realize that they have already breached the reserve space and no error would have been reported. Database Administrators need to make use of prostrct statistics, proutil dbname -C dbanalys or the database statistics tool located http://communities.progress.com/pcom/docs/DOC-518 on the web to monitor area growth. Monitoring area growth within a database is necessary to ensure that database limits are not reached that could result in a database not being able to go through database crash recovery.
Using the example above the area has a current high water mark of 7510818 blocks. Multiply that value by the database block size and you have an area size of 61528621056 = about 57 GB. With a user non-addressable reserve space of 5 GB, this means that the database area in question can only grow another 2 GB prior to reaching the limit for the maximum user addressable space for an area.
As of 9.1E04 and 10.0B05 and later, the prostrct statistics command can be ran against a database while the database is online to obtain information regarding current storage area size. The output of prostrct statistics has also been enhanced to provide a percentage associated with how close the area is to reaching the Maximum # of blocks for an area.