This Article only applies to OpenEdge databases enabled for After-Imaging or not at all. If the database is enabled for OpenEdge Replication, refer to Article
What effect does builddb have on a replication enabled database?.
STEPS:0. Ensure a valid verified full backup of the database prior to making these structural changes.
1. Ensure the database is shutdown and all processes running against the database (don't forget cron jobs that may try to access the database single user)
2. Truncate the bi file and refresh the .st file to ensure the exact latest reflection of the database Control Area:
$ proutil dbname -C truncate bi
$ prostrct list dbname dbname.st
3. Open the structure file (dbname.st) in an editor to reflect the new Storage Area name(s): See example below in Notes
a. The existing Area name(s) to the new Area name(s).
"Schema Area" 6 is reserved and cannot be re-named
b. The FULL PATH to every physical database extent on disk, not relative paths, including AI files if in use.
4. OS Copy then Delete (or re-name) the Database Control Area (the dbname.db file).
5. Rebuild the Database Control Area:
$ prostrct builddb dbname dbname.st
Where:
"dbname.st" is the edited structure file from Step 3 above.
6. Backup the 'New_Storage_Area_named' database and update OrganisationChange Control notes to reflect the database structure change.
If after-imaging is in use and the ai files are not included in the 'dbname.st' file used in Step 5 above:
- The database will fail to startup as the ai files are no longer part of the structure but after-imaging is still enabled.
- The only reliable way to recover from this situation is to disable after-imaging with 'rfutil -C aimage end' then the existing ai files will have to be backed up for reference for the pre Area-Name's change baseline, re-added and aimage begin for the new hot spare baseline which then needs to be re-instated. Refer to Article How does changing the name of a storage area affect after-imaging? for additional information.
