Status: Verified
GOAL:
Consequences of using the -F startup option
GOAL:
The Perils of using the Force (-F) option to start the db
GOAL:
How to force into a damaged database?
GOAL:
How to force access into a damaged database?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
FIX:
OverviewThe -F option is provided as a last resort emergency measure and should never be needed. This parameter is made available to allow you to extract and salvage as much data as possible from a database that is damaged and otherwise unusable. It should be used only when the alternative is loss of the entire database.
It cannot be stressed strongly enough that using ?F must be considered as the very last resource. Going back to a backup is the safest option.
Also, please be aware that the following does not apply to when the ?F option is used with proshut or promon (the effect of using -F with proshut is detailed in Progress Solution P3222.
Some background informationAlways think of your Progress database as the sum of your data files .db file(s) (.db, .d1, .d2, etc.), your before-image file(s) (.bi, .b1, .b2, etc.) and the data resident in shared memory.
When a database is abnormally shut down (for example, in case of a power failure), the data resident in memory is lost, along with those updates that had not yet been written to disk.
When the database is started up again, the rollback process takes place; the rollback actually consists of two parts:
- Redo phase.
Because of how Progress optimizes writes to the data files (.d1, d2, etc.), some transactions that had been committed at the time the database crashed might have been flushed to the before-image file, but not to the data files. This is completely normal. During the redo phase Progress scans the two most-recently used before-image clusters to make sure that all committed transactions are indeed flushed to the data files. The start and the end of the redo phase are marked by informational messages 5326 and 7161 respectively; these message appear when the database is started up:
Begin Physical Redo Phase at <address>. (5326)
Physical Redo Phase Completed at blk <blk> off <off> upd <upd>. (7161)
- Rollback:
Once the redo phase is complete, Progress scans the before-image file backwards searching for transactions that were started but not committed at the time the database crashed. Any incomplete transaction is rolled back and this is possible thanks to the information in the before-image file itself.
Forcing access with ?FWhen access is forced into a database with the ?F option, both the redo phase and the rollback are skipped; also, the before-image is rebuilt from scratch, so the information needed by the redo phase and the rollback is permanently lost.
It is now easy to understand that the database is left in an inconsistent state:
- Because the redo phase was skipped, some of the transactions that were committed at the time of the crash might not be flushed to the data files or, even worse, they might be left partially committed. Note: this is the reason why a database might be damaged by using ?F even if there were no transactions active at the time the database crashed.
- Because the rollback was skipped, transactions which were uncommitted at the time of the crash will not be rolled back. The consequences include:
- incompletely updated records.
- partially deleted records.
- record fragments which refer to non-existent fragments.
- records without index entries.
- index entries that refer to nonexistent records.
- inconsistent free and RM chains (used internally to allocate space for new records).
- logical inconsistencies due to the partially completed transactions. The fact that a database is damaged is usually not immediately apparent. For example, the existence of a partially created record is revealed only when that record is accessed and an error occurs. Until then, everything may appear normal.
Physical inconsistencies in index structures .can be repaired by rebuilding the indexes with the offline index rebuild utility. This is possible because the index rebuild utility first deletes all index blocks and then creates new ones using the key values present in existing records.
Critical schema indexes however, will not be repaired in this way; the implication is that the database schema is corrupted, and information cannot be reliably pulled out from your database even by dumping the database. This is a worst-case scenario, but it's possible.
On the other hand, physical inconsistencies in data records (including the records that describe the schema) cannot be repaired. The only possibility is to remove damaged records manually (if they can be located).
Logical inconsistencies can be repaired only by an examination of all data values in all records and a verification that they are correct, that no records are missing, and that there are no duplicate records. This is usually a daunting and time consuming task.
Under these conditions, going back to a backup is probably a better option than trying to repair a database damaged by forcing access with ?F.
Using -FFirst of all, backup your database now. Try to use probkup first, but if probkup crashes because a database block is damaged too severely, you will have to resort to backing up your database with OS utilities.
After the backup, you can force access to the database by using the -F option with the proutil utility in conjunction with the truncate bi qualifier:
proutil <db> -C truncate bi -F
Once you start this command, the following messages and prompt appear:
The -F option has been specified to proutil. (6260)
Forcing into the database skips database recovery. (6261)
This leaves the database in unknown state, considered damaged. (6262)
Are you sure you want to skip crash recovery? (6263)
If you enter "y" for "yes", the forced access occurs and the following additional dire warnings are displayed and written to the log file:
** The FORCE option was given, database recovery will be skipped. (33)
** Your database was damaged. Dump its data and reload it. (37)
Now the database must be dumped and reloaded into a brand new database.
Prior to embarking upon this activity you may want run an idxbuild of all primary indexes, in an attempt to repair the damage on those indexes and try to dump out as much data as possible (refer to Progress Solution P6424 for further details). Please bear in mind that in this case the backup is even more important, because if anything goes wrong during idxbuild, the only way to recover the database is to restore it from backup.
Finally: Dump the database with the Data Dictionaries utilities, and then load it via the bulkload utility. Binary dump is highly discouraged, because while binary dump is much quicker, it checks record integrity to a very limited extent; therefore a corrupted record may well be dumped "as is" and then be loaded into the new database without any fix; as a consequence the new database would be corrupted too..