Kbase P165890: Cannot start a database after moving the location of a bi extent and running the prostrct repair com
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
13/05/2010 |
|
Status: Unverified
SYMPTOM(s):
Cannot start a database after moving the location of a bi extent and running the prostrct repair command to detect new location for the bi file.
Last open date mismatch. (9215)
Extent <file-name> has a different last opened date <timestamp>, (9213)
(9213) Extent /dbname.b1 has a different last opened date Mon May 10 13:17:46 2010,
(9217) Control Area has a last open date of Mon May 10 14:46:26 2010.
Probable backup/restore error. (605)
Database is damaged, see documentation. (1486)
FACT(s) (Environment):
Database could not go through crash recovery with bi file in the original location because there was not enough file system space to grow the bi file.
prostrct list dbname to update the dbname.st file prior to making changes.
Created a copy of the bi file from the file system where there was insufficient space to another file system that had sufficient space to get through crash recovery.
Modified the dbname.st to see the new location for the bi file.
Ran prostrct repair dbname to update the location in the database associated with the bi file.
Validated with prostrct list dbname, that the database is now seeing the bi file in its new location
Bi file has reached 20 GB
Variable length bi file.
Large files enabled for this database.
Database was in a crashed state when the bi file was copied to another location.
All Supported Operating Systems
OpenEdge 10.1C
CAUSE:
An After Image script was running against the database while the database was in a crashed state and the bi file was being copied to another file system. The running of this utility updated the Control Area with information which subsequently resulted in a time difference between the bi file and Control Area.
FIX:
Prior to copying the bi file to a new location, ensure that no ai management scripts are running against this database. Scripts such as these could result in updates to information in the Control Area and result in the date/time mismatch.