Kbase 20448: Consequences of Using -F Startup Option.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
09/05/2003 |
|
Solution ID: 20448
FACT(s) (Environment):
Progress 8.2A
FACT(s) (Environment):
Progress 9.x
SYMPTOM(s):
Consequences of skipping crash recovery that occurs when a Progress database session is started with the -F parameter option.
After-imaging disabled by the FORCE parameter. (4790)
** The FORCE option was given, database recovery will be skipped. (33)
** Your database was damaged. Dump its data and reload it. (37)
The -F option has been specified to proutil. (6260)
Forcing into the database skips database recovery. (6261)
This leaves the database in an unknown state, considered damaged. (6262)
Are you sure you want to skip crash recovery? (6263)
CAUSE:
The -F option is provided as an emergency measure and should never be needed. It exists 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. You probably lose less data by restoring from a backup copy of the database.
With the -F parameter, the memory-resident state that is lost in a crash is not recreated. Consequently any database updates that were not written to disk are lost. Incomplete transactions are not rolled back. Most probably, only the out-of-date disk resident part of the database state is retained.
Use of the -F option when you start a database almost always produces a database that is in an inconsistent (corrupt) state. There usually are physical inconsistencies, such as incompletely updated records, partially deleted records, records without index entries, index entries that refer to nonexistent records, etc., as well as logical ones such as partially completed transactions.
The fact that a database is damaged by a skipped crash recovery is usually not immediately apparent. 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, except for the critical schema indexes the index rebuild utility needs can usually be repaired by rebuilding the indexes. This is possible because the index rebuild utility first deletes all the index blocks and then creates new ones using the key values present in records.
Physical inconsistencies in data records (including the records that describe the schema) cannot be repaired. The only thing that can be done is to remove damaged records manually (if they can be located).
Logical inconsistencies 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 extra records. This is almost always an impossible task.
FIX:
Beginning with Progress Version 8.2A, you could force access to the database by using the -F option with the PROUTIL utility in conjunction with the TRUNCATE BI qualifier:
proutil demo -C truncate bi -F
You can no longer start the database using the -F option. If you do, the following warnings and prompts are displayed:
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)
FIX:
References to Written Documentation:
Progress Solutions:
16774, "Force Access -F Parameter in Version 8.2 and Later"
21479, "What To Do Before Dumping Data After You Used the Option -F"