Status: Verified
SYMPTOM(s):
Trying to add a new bi extent since the variable bi extent reached 2 GB limit fails with error 8898
SYSTEM ERROR: Attempted to exceed 2GB limit with file <pname>. (8898)
You must remove the variable length BI extent before adding additional BI extent(s). (8225)
Error 8898 refers to a before-image extent.
Before-Image filled to 2 gigabyte limit which caused database to shutdown.
** Insufficient disk space to extend the before-image file. (854)
bi file reached 2 Gig
The bi file on disk is within 32-bytes of 2GB: 2,097,120 KB
there is enough disk space to add the new extent
ulimit is not set
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
Fathom Versions
CAUSE:
Bug# OE00117215
FIX:
The fact that the before-image extent has reached the 2Gb Progress limit is the cause of the database to crash initially when the bi file could not be extended and is the issue with any access to the database after the fact. The fact that you were not able to add another bi extent due to the 8225 error is a known issue.
Go back to the last good backup. If no backup is available it may be possible to force entry into the database but the database will be logically inconsistent and may not (very possibly will not) be reliable from that point forward. Please see Progress Solution: P24330, Consequences of using the -F startup option
There are several methods to work around this situation. The first is most strongly recommended, the remainder all carry their associated risks.
Method 1: Go to backup
a) Restore the last verified database backup
b) Add new bi extents as may be appropriate with the "prostrct add" utility
c) Roll forward the appropriate ai files (if after-imaging is in use) up to the point of failure.
Method 2: EnableLargeFiles
With the Enterprise License for Progress 9.1C and later, large files can be enabled against the database with the "proutil -C EnableLargeFiles" utility. This will allow the current bi file to extend beyond this 2GB limit when access resumes.
Please bear the following in mind before doing so:
a) This utility is only available with Enterprise Licenses
b) Ensure that the files ystem on which the before-image resides is enabled to support large files
c) The Progress license must support large files for the operating system (ie: even though SCO or Linux may support large files, the Progress product does not in version 9)
d) When the database is eventually re-started, roll-back recovery will kick in. During this phase the before-image can grow to up twice as much its current size in a worst case scenario, so make sure that there will be enough space for the before-image extent to expand.
e) Should this fix fail, refer to Option 1.
Method 3: Move the database to a new structure
This method has worked in as many cases as it has not worked. It all depends on the variety of actions customers may have taken before-hand and how absolutely near the physical size of this errant variable bi extent is.
a) Take a backup of the database with the -norecover option which defers the truncation of the bi to the prorest action: "probkup dbname dbname.bak -norecover"
b) Delete the database - (you have verified your backup was successful?)
c) Create a new database structure with additional bi extents to facilitate twice the current bi file sizes: "prostrct create dbname dbname.st -blocksize n"
d) Restore the backup into this new structure: "prorest dbname dbname.bak"
e) Should this fix fail, refer to Option 1
Method 4: Force into the database - this is by far the most drastic measure. Please first refer to Progress Solution:P24330, Consequences of using the -F startup option
** Take an OS backup of all the database files to a safe place to ensure a recoverable baseline. **
a) Force into the database by skipping crash recovery: "proutil db-name -C truncate bi -F -G 0"
b) Remove the bi file(s) from the database: "prostrct remove dbname bi"
c) Create a new st file that contains only information about the new bi files that you want to add:
# example dbadd.st
b . f 1024000
b .
d) Add these bi extents to the database structure: "prostrct add dbname dbadd.st"
e) Run a prostrct. list to verify the added extents: "prostrct list dbname dbname.st"
f) Take a backup of the database and initiate corrective actions. It is strongly suggested that this includes a dump and load of the recovered database..