Consultor Eletrônico



Kbase P47100: A runaway process caused the database to shut down when the process was terminated through promon
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   16/06/2009
Status: Verified

SYMPTOM(s):

A runaway process caused the database to shut down when the process was terminated through promon

bi file at 1.5GB due to a runaway process

On restarting the database, the redo of the incomplete transaction fills the AI extent and returns error 5350

Database Server shutting down as a result of after-image extent switch failure. (5350)

Not enough disk space to add ai extents and bi extents to accomodate recovery

FACT(s) (Environment):

All Supported Operating Systems
Progress/OpenEdge Product Family
OpenEdge Category: Database

CAUSE:

On re-starting the database, the redo of the runaway process is causing the bi file to grow and in parallel, writing to the AI extents. As these fill quickly, there is not an empty one to switch to which raises the 5350 error.

FIX:

STEPS:

1.) Disable after-imaging, the hotspare database will need re-synching in any event with the AI extents having recorded the runaway transaction.
2.) Truncate the bi, this will run roll back recovery. For Progress 8, there may be just enough bi space left until the 2GB limit is reached, otherwise see step 4. For Progress 9 and OpenEdge 10, add more bi extents before truncating the bi file if more diskspace can be made available.
3.) If step 2 succeeds, re-synch the hotspare after-imaging recovery baseline. If extra bi filespace was added, these can now be removed.
4.) If step 2 fails, go to backup then roll forward the ai notes with -bithold 500. In this way, you will be able to roll forward as many transactions as safely as possible until the runaway process recorded in the AI files has clearly started "running away". When bi 500MB is reached, the roll forward with cease. Truncate the bi and take a backup of the database. This is then the new baseline for your LIVE database against which the hotspare can be re-synched and the re-run transactions against the Live database as needed.