Consultor Eletrônico

Status: Verified

SYMPTOM(s):

Database crashes with 9451, 9450, 10560, 1119 errors

<function>:Unknown O/S error during <system call>, errno <error number>, fd <file descriptor>, len <bytes>, offset <bytes>, file <file-name>. (9451)

<function>:Insufficient disk space during read, fd <file descriptor>, len <bytes>, offset <bytes>, file <file-name>. (9450)

bkRead: Error occurred in area <num>, block number: <num>, extent<name>: . (10560)

SYSTEM ERROR: wrong BI blk, read <dbkey> from <dbkey> (1119)

re-starting the database fails with errors 9215 9213 9217

Last open date mismatch. (9215)

Extent <file-name> has a different last opened date <timestamp>, (9213)

Control Area has a last open date of <time-stamp>. (9217)

OS utilites were not running at the time

FACT(s) (Environment):

Progress 9.1X
All Supported Operating Systems
OpenEdge 10.x
Progress 9.x
Progress 8.x
Progress 7.x
Progress 6.x

CAUSE:

Restoring an OS backup of production database to a test environment with procopy. When first running "prostrct repair" in the OS copy file location, the absolute path structure file (.st) was of the production database. This is the reason that the production database server went down. In effect, the creation of two database control areas with identical area and extent information has resulted.

FIX:

If the described issue has arisen, the production database ideally needs to be restored from backup and after-image (ai) files rolled forward - if in use. Otherwise, it will need to be forced into. Please contact Progress Technical Support for further instruction.
In principle, whenever using 'prostrct' utilites, /always/ check the .st file. The following /set/ procedure to use when restoring a copy of a live database to a new location absolutely rules out the things that can go wrong:
A.) The simplest method, is to OS copy/ftp the "OS backup copy" of the production database, to the location where you need it and then to run "prostrct repair dbname dbname.st", where the dbname.st contains absolute paths to their existing physical location. Take special precautions to ensure that when the "OS backup copy" is initially taken, the production database is either shutdown or in a quiet point.
B.) Another method is to repair the structure of the "OS backup copy" in it's existing location and then to use either prodb or procopy utilities to place it in the desired location:
0) Where the OS copy of the production database is in the source directory and the end location is the target:
1) In the SOURCE directory, check that the structure (.st) file: dbname.st either contains relative paths to the database extents, or absolute paths to their existing physical location. Then run:
$ prostrct repair dbname dbname.st
$ prostrct list dbname dbname1.st
$ view dbname1.st to verify as correct. At this stage, the OS copy of the production database has had it's control area re-set to no longer point to the file locations of the production database, but where these files currently reside in the backup directory.
2a.) If the copy of the live database needs ALL the database files to be put in the same location, cd to the target location and run:
$ prodb dbname /bakup/location/of/OScopy/dbname
2b.) If the copy of the live database files will be not in all the same file location (there may be disk space restrictions preventing having all extents in the same place, for example). Go to the target location where the dbname.db will be located and check that the .st file in the TARGET directory has the absolute paths of where you want each of the procopied extents to be, then run:
$ prostrct create dbname dbname.st -blocksize <dbblocksize in use, bytes>
$ procopy /bakup/location/of/OScopy/dbname dbname
In this way, you're 100% sure that:
- the "newdatabase" has extents exactly where they should be
- the procopy copied from the exact source to the target - ie, not from the live database but from the OS backup location.