Kbase P138062: Is it possible to start a database without .bi files?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/12/2008 |
|
Status: Unverified
GOAL:
Is it possible to start a database without .bi files?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
It is not ever possible to start a Progress/OpenEdge database without the before-image files.
If the missing bi files were as a result of an OS copy which failed to include the bi files, the best next-steps are to copy this database again - after the database has been shutdown first or after a quiet-point has been raised.
IF the original database is no longer available, a method to add "dummy" bi file(s) to the copied set could be used .. however first confirm that the source database is no longer available (ie this is the only copy that you have remaining) and IF this is the case, it is very important that the following instructions do not interfere with your running databases. So it is very important to ensure that you pay special attention to the directory paths and database names listed in each utility.
[ in the copied-TO directory ]
1. Make absolutely sure you have a <dbname>.st file and that it contains a listing of ALL the database extents with FULL-PATHS to each extent that has been copied to the new directory
eg.
# dbname.st
b <full path>/<dbname>.b1
d "Schema Area":6,32 <full path>/<dbname>.d1
2. Repair the control area:
$ prostrct repair <dbname> <dbname>.st
3. Replace the bi file
$ echo y | prostrct unlock <dbname> -extents
4. Force into the database
$ echo y | proutil <dbname> -C truncate bi -F
5. The damaged flag is now set on this database, but they will now be accessible. It is up to you at this point to dump and load. You are likely to
find inconsistencies after forcing, but this depends if you truncated the originating databases before your OS copy.