DBTOOL crashes and returns to the command prompt


Article Number000018579
EnvironmentProduct: OpenEdge
Version: 10.x, 11.x
OS: All supported platforms
Question/Problem Description
DBTOOL with just the database name immediately returns to the command prompt
DBTOOL with a full path to the database name results in an error "dbtool has stopped working"
Running DBTOOL online crashes the database with errors 4232 10560 10561

PROUTIL -C DBSCAN reports errors related to invalid data block found, bad record fragments and overlapped records
DBSCAN reports sequential recids in the corruption messages

Steps to Reproduce
Clarifying Information
Error MessageInvalid data block found.  Reason: Bad record size Records overlap
** Bad Frag <recid> for rec <recid> Err:2
Record <recid> in area <area number> has table number 0 which doesn't exist
4232)  Corrupt block detected when attempting to release a buffer.
(10560) bmReleaseBuffer: Error occurred in area <area number>, block number: <dbkey>, extent: <extent>
(10561) Writing block <dbkey> to log file.
Defect/Enhancement Number
The database has record block corruption.  How this occurred is not known. 
Restart the entire server to confirm that the corruption was not in RAM or cache by re-running DBSCAN or performing a full offline PROBKUP without a backup volume.  The advantage of a PROBKUP over DBTOOL is that all blocks will be read by the backup, whereas DBTOOL Option 5 only scans data blocks.

Either run:
  1. $  proutil dbname -C dbscan
  2. $  probkup dbname NUL (WINDOWS) or probkup dbname /dev/null (UNIX)
1. If no corruption are reported, this verifies that the issue was caused by the underlying memory or cache on the system which will then require further investigation by the IT Administrators of the system before restarting the database.

2. If corruption are reported, this verifies that the block corruption was propagated to disk.  It is advised that the disk subsystems are checked before proceeding with restore operations on this system.

Option 1:  Restore the last known verified backup and roll-forward if AI is enabled.

If either of the remaining Options 2, 3 need to be employed, physical integrity will be restored but there will be data loss and neither option can guarantee logical integrity.

Option 2: Perform a ASCII dump and load. Tables that fail to dump will need to be dumped by skipping over corrupted records. Further steps are needed to retrieve the records that were skipped, if it is possible to find them in prior backup copies.  Option 3: Eliminate corruption by reformatting bad blocks in the current database

Refer to the instruction provided in Article 000016827, Possible method to fix an overlapped record: Bad record size Records overlap

Last Modified Date12/21/2018 8:22 AM

Did this article resolve your question/issue?


Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025