Kbase P98311: Database crashes with errors 6091 111
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/11/2008 |
|
Status: Verified
SYMPTOM(s):
Database crashes with errors 6091 111
<function>:Insufficient disk space during <system call>, fd <file descriptor>, len <bytes>, offset <bytes>, file <file-name>. (6091)
bkioWrite:Insufficient disk space during write, fd <file descriptor>, len 16384, offset 2147482624, file dbname.dn. (6091)
SYSTEM ERROR: Unable to extend the database. (111)
offset in 6091 message is between 2147450880 and 2147483648 bytes
The file in 6091 message is a data extent
Adding new extents fails with error 6091
bkioWrite:Insufficient disk space during write, fd <file descriptor>, len 1024, offset -1048576, file dbname.dn. (6091)
offset in 6091 message is a negative number
Any access to the database fails with error 647
bkset: Extent /disk4/mls/pro/base/hist.d8 is below size -2147483648. (647)
Disk has not run out of space
Filesystem does not support large files
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
CAUSE:
The database crashed initially because when writing to the variable extent, more blocks needed to be added to this extent to accomodate the writes. This could not be achived without extending the variable extent beyond the 2GB limit on 32-bit systems.
The prostrct add operation failed because before adding a new extent, the exisiting variable length extent must first be made into a "Fixed" extent. When we do this, we round the current variable length extent up so that it is divisible by 32. Since 2GB sharp cannot be represented by a 32-bit signed integer, the "real" 2GB limit is actually 2147450880KB, or (2GB - 32KB). As the current size of this variable length extent already exceeds this value, the operation falis as reported in the 6091 message with the negative value representing how much "over" 2GB-1 the resulting filesize would have been.
Any access to the database at this stage fails with error 647, reporting the fact that the extention of this extent failed.
FIX:
There are two methods to correct this situation. The first is strongly recommended as there have been incidents reported to Technical Support where the second method has failed and the first has then had to be relied on. Using the first method is in all likelyhood, the quickest way to get the database back into production.
Method 1: Go to Backup
0.) If after-imaging is in use, copy the existing after-image (ai) extents off to a safe place.
1.) Restore the most recent verified backup
2.) Add new extents with the "prostrct add" utility to accomodate immediate and future growth in this area
3.) Roll forward ai files (if in use)
4.) Truncate the before-image file (bi) then start the database and re-run transactions as needed.
5.) Take an online backup with the "probkup online" utility
Method 2: Only for UNIX
0.) Take an OS copy of the existing database
1.) Create a structure file against the existing database:
$ prostrct list dbname now.st
2.) Edit the structure file for the "errant extent" by setting the Fixed size to 2097120
example: d "Area-mine":7,64 /fullpath/to/extent/dbname_7.dn f 2097120
3.) Change the physical size of the "errant extent" on disk to reflect the size in the structure file with the dd command. The resulting "trunc.d<n> file /must/ be 2147450880 bytes.
example 1: $ dd if=<dbname>.d<n> of=trunc.d<n> obs=1024 count=4194240
example 2: $ dd if=<dbname>.d<n> of=trunc.d<n> ibs=1024 count=2097120
Please refer to your OS documentation for specifics.
4.) Replace the "errant extent" with the extent of the correct size:
$ mv trunc.d<n> <dbname>.d<n>
5.) Repair the filesize in the Control Area: $ prostrct unlock dbname now.st
6.) Start the database and re-run transactions as needed
7.) Take an online backup with the "probkup online" utility
8.) Schedule a review of your disaster recovery plan as soon as possible