Kbase P4212: Before Image (.bi) file is missing, corrupt, or lost and the database fails to start
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/19/2010 |
|
Status: Verified
SYMPTOM(s):
Before Image (.bi) file is missing, corrupt, or lost and the database fails to start
Database fails to start with bi error messages
bi file is lost, missing or damaged
SYSTEM ERROR: The before-image file has the wrong cluster size. (881)
** The database was last used <date/time>. (886)
** The before-image file expected <date/time>. (887)
** Those dates don't match, so you have the wrong copy of one of them. (888)
**Cannot find or open file <filename>, errno = <number>. (43)
Cannot find or open file dbname.bx errno = 2. (43)
Cannot start database
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
CAUSE:
The result of hardware problems and/or operating system bugs that impact the database integrity without forewarning. A combination of these error messages indicate that the .bi file is lost, corrupted or is pointing to the wrong bi file at startup.
This scenario can also be a consequence of user error during OS backups, when failing to list all related components correctly for the database, or when using automated scripts and commands are executing in the background - there is not enough time between commands for the previous command to finish. For example: truncating the bi while the database is still shutting down, resulting in the incorrect OS copy of the bi file when you restore from a backup. Whatever the initial cause, a combination of these error messages will result and indicate that the cause of failure is that the .bi file is lost, corrupted or is pointing to an inappropriate bi file at startup.
FIX:
Progress recommends the restoration of a database backup in this scenario. Before considering either of the workarounds below, please review p24330, "Consequences of using the (-F) option to start the db"
The following workarounds are provided for situations where going to back up is not possible. These are highly reliant on an accurate structure file. If the database structure has been altered since last known dbname.st, then going to last fully verified backup should be the ONLY course of action.
WORKAROUND #1:
1.) First ensure that a structure file exists (dbname.st) where the dbname.db file resides with fully qualified paths, describing EVERY extent that should be in place including all the bi extents.
Run: prostrct list dbname
View the output of dbname.st
2.) If the bi extents are still present, remove them then replace the bi extent(s) with placebo extents. This utility uses the information in the dbname.st file which is a reflection of the information in the database control area (dbname.db)
Run: prostrct unlock dbname -extents
Answer "y" (without quotes) to skip crash recovery
For each bi extent messages similar to the following will result
Processing extent: <fullpath>\<dbname>.b1 size: <size>
** Cannot find or open file <full path>\<dbname>.b1, errno = 2. (43)
WARNING: Database is damaged, missing extent file <full path>\<dbname>.b1. (1990)
3.) Force crash recovery again:
Run: proutil dbname -C truncate bi -F
WORKAROUND #2:
The workaround involves creating a new database from an empty database and then creating the missing bi files. Once created, these files will be used as a replacement for the missing bi files.
1. Take an OS backup of the database before proceeding. This backup can be used to restore from if problems arise with this workaround.
2. Create a new database to mirror your existing database:
a. Copy your existing dbname.st file to newdbname.st file.
b. Replace the dbname in the newdbname.st file with the newdbname.
c. prostrct create newdbname newdbname.st -blocksize (same blocksize as original dbname). This will create a void database.
d. procopy $DLC/emptyN newdbname (N= block size used above. Example: procopy $DLC/empty8 newdbname if -blocksize 8192 was used to create the void database)
3. Once the new database has been created, copy the "newdbname.b1" file to replace the missing dbname.bi file. During the copy, rename the file to the name of the original database. Example: procopy newdbname.b1 dbname.b1
Note: If there was more than 1 bi file missing, copy all of the missing bi files from newdbname to dbname in order to fully recover the extents.
4. Once the new bi extent is in place, run "prostrct unlock" to fix the timestamp differences:
Command: prostrct unlock dbname
For each bi extent, a messages similar to the following will result confirming the timestamp inconsistency corrections:
Processing extent: ./dbname.b1 size: 0
Inconsistency: dbname last opened Mon Jun 13 13:54:04 2008
./dbname.b1 last opened Mon Jun 13 13:54:04 2008. (6948)
1 inconsistency(ies) fixed. (6951)
5. Force into the database. The new bi exents have no relation to the current database. The force option without the -G .needs to be specified.
Command: proutil dbname -C truncate bi -F (This option will then cause the Forced Flag to be set on the database).
Finally: After applying either of the above workarounds, the database should be accessible. It is strongly recommended that a dump and load operation is considered at the next convenience.
To validate that the database was not damaged as a result of the prostrct unlock or the forcing into the database, scan the database using the instructions provided in the Solutions referenced below..