Kbase P167337: Why do I have a database area that appears to have grown into the reserved space within a Type I sto
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/06/2010 |
|
Status: Verified
GOAL:
Why do I have a database area that appears to have grown into the reserved space within a Type I storage area?
GOAL:
Why has a database area grown into reserved space limit?
GOAL:
Why is my Type I area making use of the reserved space within an area?
GOAL:
How is it possible that a database area appears to have some how started writing into the reserved space within an area?
GOAL:
Can a database area exceed the user addressable space for an area?
GOAL:
The database statistics tool is showing that a Type I storage area has exceeded the user addressable space threshold for an area. How is this possible?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.1E04 Service Pack
OpenEdge 10.0B05 Service Pack
OpenEdge 10.1x
OpenEdge 10.2x
FIX:
Growth into the reserved space within an area is allowed as a part of crash recovery. This is expected behavior when an area is close to reaching user addressable space limits for an area and crash recovery is performed and as a result of the crash recovery, further growth occurred within the area.
Growth into the reserved space within an area can occur as a result of the database having gone through crash recovery with an area already reaching the maximum user addressable amount of space for the area. When the database goes through crash recovery, which is really something we do every time the database is started. It is at that time, that transactions can be undone and redone associated with records/blocks within this area. These actions can result in growth into the reserved space within an area.
When the growth into the reserved space within an area occurs as a result of crash recovery, errors like the following will not be written to the database log file because growth in this manner is expected behavior.
bkxtn: Area: %l<areaNum> extent: %s<ExtentName> Attempt to exceed the maximum number of user-available
blocks per area - Max: %J<maxAreaBlocksize> Current: %J<currentHiWater> Extend: %l<extentAmount> (13517)
The whole purpose for the reserved space is so that when / if an area has reached or is close to reaching the maximum user addressable area size and we need to go through crash recovery, we will be able to do so.
The error above may not be experienced if a user process had not already hit the limit yet associated with maximum user addressable space for an area. However, upon one of the subsequent database start ups, the area was close enough to the maximum user addressable space that when we went to go through crash recovery it was just enough to exceed the remaining amount of user addressable space within an area and then continued into the reserve space.
When going through crash recovery, no checks are made to see if we are exceeding the maximum user addressable space, then issue the error messages above and then continue writing to the reserved space. Rather, as a part of crash recovery, we simply write to the available space within an areas and if user addressable space was exceeded, we would just continue to write to the reserved space.