Consultor Eletrônico



Kbase P27203: Recovering from Bad counter in the .bi file. (880) on startup of database with no backup
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   03/07/2009
Status: Verified

SYMPTOM(s):

Bad counter in the .bi file. (880) on startup of database

SYSTEM ERROR: Bad counter in the .bi file. (880)

Starting database fails with error 880.

FACT(s) (Environment):

BI extents have NOT reached 2 GB
No recent backup to fall back on
All Supported Operating Systems
Progress/OpenEdge Product Family

CAUSE:

This error indicates that Progress encountered a problem while reading the .bi file during database startup or beginning a truncate bi session.

When a Progress database session starts up, it reads through the bi notes looking for a counter that indicates where the bi cluster ring begins. The beginning of a cluster ring is the oldest cluster, or the one with the lowest counter. Once the Progress Database Manager finds the lowest cluster counter, it should follow that each cluster we read after that has a higher counter. If we run into a cluster with a lower counter, the operation fails and we return the 880 error in the database log file. This error indicates that the bi file is corrupt.

FIX:

Since this error does indicate .bi corruption, and a restore from the last known valid backup (one preceding the action that caused the bi file corruption) is not an option, the ONLY option available is to recover the database by forcing in. Please refer to "Consequences of using the -F startup option" before proceeding.


The following Steps outline the use of the -F force option to force access into the database by skipping roll back recovery (ie: the notes in the bi file are ignored!) and then proceeding to dump and reload the database:


1.) OS COPY all database extents to place a baseline which can be returned to if needed.

From a PROENV session: (this will set all the relevant environment variables, or alternatively from a shell where the progress environment is set)

2.) force into the database by skipping crash recovery:
$ proutil dbname -C truncate bi ?F

3.) Update the database structure file as understood by the control area:
$ prostrct list dbname dbname.st

5.) Start the DBADMIN utility single-user:
$ prowin32 dbname -p _admin.p -1

6.) FROM THE DBADMIN utiltiy:

Admin -> Dump Data and Definitions
-> Data Definitions .df
-> [Select Some, Table Name = *, OK]
-> [Output file dbname.df, Code Page ISO8859-1 (or the codepage is in use),
include r compatibility = TRUE]

Admin -> Dump Data and Definitions
-> Table Contents.d -> [Select Some, Table Name = *, OK]

Admin -> Dump Data and Definitions
-> Sequence Current Values

Admin -> Create Bulk Loader Description File
-> Select Some, Table Name = *, [OK]
-> [Output file dbname.fd OK]
EXIT the Database Administration Tool.

7.) echo y | prodel dbname
# to delete the corrupt database, we have just sucessfully dumped the needed information to create a new database and have a backup from STEP 1 if needed.

8.) prostrct create dbname dbname.st -blocksize 8192
# this is the dbname.st from step 4, it is worth verifying it to make sure that the directory listings are correct, this step will create a VOID 8K database.

9.) procopy %DLC%\empty8 dbname # this will create an EMPTY database that can be accessed with a 8K blocksize

10a) prowin32 dbname -p _admin.p -1
FROM THE DBADMIN utiltiy:

Admin -> LOAD Data and Definitions
-> Data Definitions .df
-> Input File name dbname.df

EXIT the Database Administration Tool.

10b) LOAD Data and Definitions with the bulkload utility which will require a full index rebuild:
proutil dbname -C bulkload dbname.fd -B 10240 -G 0
proutil dbname -C idxbuild ALL -TB 24 -TM 32

- OR -
Admin -> LOAD Data and Definitions
-> Table Contents.d
-> all
-> input directory = Progress working directory where the table.d were dumped in step 6 above.

10c) prowin32 dbname -p _admin.p -1
Admin -> LOAD Data and Definitions
-> Sequence Current Values
-> _seqvals.d

EXIT the Database Administration Tool.

11) probkup dbname dbname.bak


Followup procedures should consider including investigation into WHY the .bi file got corrupted and rendered unusable in the first instance. This may include:

1 - Runing full hardware diagnostics on disk, memory.
2 - Analysing system logfiles together with the database logfile
3 - Disabling write cache