Kbase P16326: Before Image (.bi) corrupt or missing and database cannot st
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
02/10/2003 |
|
Status: Unverified
FACT(s) (Environment):
Progress 9.x
SYMPTOM(s):
.b1 is lost, missing or damaged
bi file is lost, missing or damaged
Cannot start database when the .b1 file cannot be used
Cannot start database when the .b1 file time stamp does not match
Error 43 with the bi file
Cannot find or open file database.bi errno = 2. (43)
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)
CAUSE:
This scenario is usually a result of hardware problems and/or operating system bugs that impact the database integrity without forewarning. It 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 it is restored 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:
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. Otherwise the following course of action may be undertaken with caution:
A new Version 9.x database needs to be created from an empty database as follows, using the sports2000 database by way of example.
In the following steps:
** "sports2000" = name of database that we've "lost" (?) the .b1 integrity
** "sportemp" = name of dummy mask database
STEPS:
1) Take a backup of the ".bi missing sports2000" database before proceeding
2) Create sportemp.st to mirror the sports2000.st exactly, (including the b1, except of course, for the database name being "sportemp" not "sports2000")
3) prostrct create sportemp sportemp.st # void db
4) procopy %DLC%\empty sportemp
5) copy sportemp.b1 sports2000.b1 # replacing the lost .bi file
IMPORTANT NOTE: If there are more than one bi files missing, in the underlying steps, where referencing 'b1', this will also include 'b2, b3 ....',
6) prostrct unlock sports2000
enter: y # to skipping crash recovery, this will be addressed later, the primary concern is to get the database up and running
# will show:
# "inconsistency sports2000 created [date1]
# C:\Progress\work\sports2000.b1 created [date2] (6948)
# "inconsistency sports2000 last opened [date1]
# C:\Progress\work\sports2000.b1 last opened [date2] (6948)
# ...
# 2 inconsistencies fixed (6951) # for each bi missing
7) proutil sports2000 -C truncate bi -G 0 -F
answer: y # cannot truncate bi so have to force!
8) at this stage the database should start again. When it does,
"Your databse was damaged. Dump its data and reload it. (37)
This is because the database damaged flag was set = TRUE when forcing in. Please read 14115 "The Perils of using the Force (-F) option to start the db"
9) To remove the damaged flag:
proutil sports2000 -C idxbuild all -G 0 < ssort.txt
# where ssort.txt:
-TB 24
-TM 32
-B 1024
10) pro sports2000 # to test that you can now connect
At this point, ascertain the damage that has been caused. A decision can be made to evaluate whether it would not be better to use the out of date backup rather?