Can't add a new bi extent after variable bi reached 2 GB limit

Adding a new bi extent since the variable bi extent reached 2 GB limit fails with error 8898
Before-Image filled to 2 gigabyte limit which caused database to shutdown with errors 10601 854.
Database BI file reached 2 Gig.
The bi file on disk is within 32-bytes of 2GB: 2,097,120 KB
 

Error 8898 refers to the current variable before-image extent.
There is enough disk space to add the new extent
ulimit as defined in .profile (UNIX) or disk quota limit (Windows) are not set disallowing files GT 2GB.

This is expected behavior. A BI file cannot be added to a database without first truncating the bi file and removing the existing variable BI extent.

The fact that the before-image extent has reached the 2GB Progress limit, is the cause of the database to crash initially as the bi file could not be extended and is the issue with any access to the database after the fact. 

The fact that another bi extent could not be added due to the 8225 error, is a known issue when:

1. The crashed flag has reset by subsequent actions after initial failure or
2. The current size of this variable length BI extent on disk already exceeds (2GB - 32KB). This means that the current variable BI extent cannot first be rounded up in order to mark it a fixed extent. Before adding a new extent, the existing variable length extent must first be made into a "Fixed" extent.  In order to do this, the current variable length extent is first rounded up so that it is divisible by 32.  Since 2GB sharp cannot be represented by a 32-bit signed integer, the "real" 2GB limit on a variable bi extent is : 2,147,450,880

1. immediately enablelargefiles or
2. immediately add new bi extents, in order that the crashed flag is not reset by other actions.

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.

Bear the following in mind before doing so:  
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 subsequent PROREST action: b)  Delete the database c)  Create a new database structure with additional bi extents to facilitate twice the current bi file sizes: d)  Restore the backup into this new structure: e) Should this fix fail, refer to Option 1
 
Method 4: Force into the database  (This is by far the most drastic measure).
 
If no backup is available it may be possible to force entry into the database and access it,  but the database will be logically inconsistent and may not (very possibly will not) be reliable from this point forward. Please first review Article: 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: b) Remove all the bi file(s) from the database, run the following command until no bi files remain: c) Create a new st file that contains only information about the new bi files that need to be added:
d) Add these bi extents to the database structure: e) Run a PROSTRCT list to verify the added extents:
  f) Take a backup of the database and initiate corrective actions.  It is strongly suggested that this includes a full dump and load of the recovered database. Otherwise database teams need to also run database integrity checks (DBTOOL for data and IDXCHECK for indexes). Once physical integrity is restored, development teams need to run application logic backend reports, to assure business logic (delivery notes without invoices) and parent-child relational (order-lines without orders) integrity.