Consultor Eletrônico



Kbase P102720: Database crashes with error 9452 on a data extent with OpenEdge Replication
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   19/05/2009
Status: Verified

SYMPTOM(s):

The Source Database crashes with error 9452 on a data extent

SYSTEM ERROR: Attempted to exceed maximum size on file <pname>. (9452)

SYSTEM ERROR: Unable to extend database within area <pareaName>. (8897)

Begin transaction backout. (2252)

SYSTEM ERROR: Incomplete microtransaction. (2255)

The Source database is crashing. Site Replication cannot continue. (10672)

Begin ABNORMAL shutdown code 2 (2249)

FACT(s) (Environment):

Progress 9.x
OpenEdge 10.x
The source database re-starts without issues
A short time after re-starting, the source database crashes again with the same error messages
Enabling large files is not an option
All Supported Operating Systems
OpenEdge Replication

CAUSE:

The actions needed are essentially the same as would "normally" need to be taken without Fathom/OpenEdge Replication in the picture.

With Fathom Replication, there are two databases to consider:

The source database has already crashed having exceeded the 2GB limit on the last extent in the given area. The source database is able to be re-started, because it is only /when/ updates are done where we need to extend this last extent, and cannot.

Anything that happens on the source database is replicated to the target database, this means that the corrective actions described below need to be performed on /both/ databases before they are re-started.

FIX:

New extents need to be added to the databases in order to allow for further data expansion. Extents may be added to both source and target database using "prostrct add" utilities while Replication is enabled. To do this, shut down both the Source and Target databases, create a .st file that add's the needed extents to both databases, run prostrct add, and restart the databases as the Steps below outline:

Assuming that:
the source database is still shut down, and
the target database has the same database structure as the source database.

Steps:

1.) Shut down the target database:
$ proshut target -by

2.) Obtain the current structure from the control area of the SOURCE database:
$ prostrct list source source.st

3.) Create a new structure file "new.st" based on the "source.st" in Step 2 above to accomodate future growth in the Storage Area that has been affected by the 2GB limit. For more information on how to create structure files please refer to the Documentation below or contact your local Technical Support.

4.) Add the new extents to the target database:
$ prostrct add target new.st

5.) Add the new extents to the source database:
$ prostrct add source new.st

6.) Start the target database:
$ proserve target <..parameters..> -DBService replagent

7.) Start the source database:
$ proserve source <..parameters..> -DBService replserv

Note:

- Storage Areas/ Extents cannot be removed on the TARGET database when replication is enabled.
- After-Image extents cannot be removed on either database while after-imaging is active (ie replication enabled)
- New bi extents cannot be added to the target database, because by definition, the last bi extent on a database must be a variable extent. Since the variable BI extent first needs to removed to add additional bi extents, the operation will fail. It is therefore recommended to add more fixed bi extents to the target database than the source database when initialising the replication baseline.
- New Storage Areas and new Extents on existing Storage Areas can be added.