Salesforce

How to recover from lost AI files ?

« Go Back

Information

 
TitleHow to recover from lost AI files ?
URL Name000046256
Article Number000163813
EnvironmentProduct: OpenEdge
Version: All supported versions
OS: UNIX
Question/Problem Description
How to recover from lost AI files?
How to to recreate AI extents after they have been accidently deleted from the file system? 
What to do when database access fails with error 43 on AI files.
Steps to Reproduce
Clarifying Information
Database is enabled for After-Imaging.
Error Message** Cannot find or open file <file-name>, errno = <number>. (43)
** Cannot find or open file dbname.a1, errno = 2. (43)
** Cannot find or open file dbname.a1, errno = 0. (43)
** Cannot find or open file dbname.a1, errno = 9. (43)
enssbrocon: child exited with 2, err=9
Defect Number
Enhancement Number
Cause
Resolution

The following instruction need to be fully verified and documented against each application production environment.

A. Recovering from loss of all or some AI files that include the current BUSY AI extent to keep production online until downtime can be scheduled:
 
OPTION 1: Disable After-Imaging online 
 
(Starting point after the AI files have been removed eg: rm dbname.a*)
 
1.  Replace ALL ai files with the same permissions as the Control Area dbname.db file after reviewing "prostrct list dbname dbname.st" to count current ai files in control area:

$ touch dbname.a1
$ touch dbname.a2
$ touch dbname.a3

2.  Disable After-Imaging online

$ rfutil dbname -C aimage aioff

At this point, AI is disabled against the database (and AIMGT and Replication if enabled), new connections can now be made to the database without error, production continues. But the database still has dummy ai files in its Control Area structure which needs to be corrected at the next opportunity to shut the database down.

$ proshut dbname -by -shutdownTimeout immed


RECOVERY: 
 
3.  Remove the ai file references from the dbname.st file lines starting "a "

$ vi dbname.st

 4.  Remove the dummy ai files on disk previously created

$ rm dbname.a*

Although this methodology was never supported, in OpenEdge 10.0B and previous versions, it was possible to run PROSTRCT REMOVE against After Image files which did not exist. In OpenEdge 10.1A it's no longer possible to do this so "PROSTRCT builddb" with an up-to-date copy of the <dbname>.st file needs to be used to recreate the database Control Area, which can also be used in earlier versions. Do not list the After Image files that have already been removed in the modified .st file, but be sure to include all other database extents and their full paths.

$ mv dbname.db REN_dbname.db
$ prostrct builddb dbname dbname.st

 View dbname.st to see ai files are no longer present but all others are

$ prostrct list dbname

 
RENABLE AI : 

5.  Truncate the bi file

$ proutil dbname -C truncate bi

6.  Add the required AI extents

$ prostrct add dbname dbname_ai.st

Where the st text file which contains only the ai file definitions (dbname_ai.st)

# dbname_ai.st example

a . f 512000
a . v 512000
a .  

7.  Enable After-Imaging, AI Management (and replication if needed according to site procedures.)

$ rfutil dbname -C mark backedup
$ rfutil dbname -C aimage begin
$ rfutil dbname -C aiarchiver enable

 8.  Start the database and take an online PROBKUP

$ proserve dbname [+params]
$ probkup online dbname dbname_newbaseline.backup

 
OPTION 2: Leave AI enabled.  

(Starting point after the AI files have been removed eg: rm dbname.a*)

Let existing client sessions complete their current processing and new connections only once ai files are replaced as long as NO AI SWITCHING takes place.
Connected clients remain running, no new connections until the ai files are replaced. Transactions are being written to the database and bi recovery files, nothing reliable to ai files which existing processes still have handles to.
 
1.  Replace ALL the ai files with the same permissions as dbname.db file after reviewing "prostrct list dbname dbname.st" to count current ai files in the Control Area:

$ prostrct list dbname dbname.st

$ touch dbname.a1
$ touch dbname.a2
$ touch dbname.a3
 
$ proshut dbname -by

RECOVERY:  as above in Option 1 except AI will be disabled offline.
 
2.  Remove the ai file references from the dbname.st file lines starting "a "

$ vi dbname.st

 3.  Remove the dummy ai files previously created

$ rm dbname.a*

 4.  Recreate the database Control Area:

$ mv dbname.db REN_dbname.db
$ prostrct builddb dbname dbname.st
$ prostrct list dbname

5. Disable After-Imaging offline

$ rfutil dbname -C aimage end

 
RENABLE AI : 
(as above Option 1).
 

B. Recover from loss of a specific AI file or set of AI files that DO NOT INCLUDE the current BUSY AI extent to keep production online until downtime can be scheduled:

Identify missing AI extents then copy in a placeholder for missing AI extents understanding that these cannot be used when switched to.

viz: cp dbname.a6 dbname.a3
 
This will allow PROSTRCT LIST, RFUTIL AIMAGE to work and production to run until the copied (dummy placeholder) AI Extents are switched to.
 
If AI Management is enabled, consider changing the aiarchiver interval to 'on demand' instead of 'timed' in order to reduce switching:

$ rfutil dbname -C aiarchiver setinterval 0

 
RECOVER and RE-ENABLE AI are as above in Option 2
 
Alternatively simply disable ai online and proceed production until ai can be re-enabled online:

$ rfutil dbname -C aiarchiver end
$ rfutil dbname -C aiarchiver disable
$ rfutil dbname -C aimage aioff

Consider taking a FULL PROBKUP and periodic incremental backups while AI is disabled
 
RECOVER and RE-ENABLE AI are as above in Option 1
 

Workaround
Notes
Keyword Phrase
Last Modified Date11/20/2020 7:28 AM

Powered by