Rob Fitzpatrick
ProgressTalk.com Sponsor
RHEL 6.3
10.2B07
Here's my situation. A database was migrated from one RH server to another via backup/restore. Unfortunately the target database was created with an outdated structure file, so several of the area names are wrong. Prorest didn't throw an error because it happened that both structures had the same number of areas and the same RPB/BPC per area.
The upshot is that areas that should be for a single table or a single table's indexes are now, at least in name, multi-table or multi-index areas.
It's largely a cosmetic issue, in that the area names no longer reflect their contents; the RPBs are all 128 in this case so I'm not contemplating D&Ls unless I have to (this would take a while as the SAN is a dog). A preliminary analysis shows that, if I can rename the areas, I can address the remaining issues with table/index moves of empty or nearly-empty tables and indexes.
So as I see it I can use one of two approaches to rename existing storage areas, without resorting to D&L:
Approach 1:
Thanks in advance.
10.2B07
Here's my situation. A database was migrated from one RH server to another via backup/restore. Unfortunately the target database was created with an outdated structure file, so several of the area names are wrong. Prorest didn't throw an error because it happened that both structures had the same number of areas and the same RPB/BPC per area.
The upshot is that areas that should be for a single table or a single table's indexes are now, at least in name, multi-table or multi-index areas.
It's largely a cosmetic issue, in that the area names no longer reflect their contents; the RPBs are all 128 in this case so I'm not contemplating D&Ls unless I have to (this would take a while as the SAN is a dog). A preliminary analysis shows that, if I can rename the areas, I can address the remaining issues with table/index moves of empty or nearly-empty tables and indexes.
So as I see it I can use one of two approaches to rename existing storage areas, without resorting to D&L:
Approach 1:
- shut down the DB
- back up the DB
- restore the backup in a scratch partition and start the restored DB to ensure the backup is valid
- delete the original DB
- prostrct create a new DB with the correct structure file in place (where the area numbers now have the correct names)
- prorest the backup over the new void DB
- back up the new DB
- start the new DB
- delete the restored DB from the scratch partition
- shut down the DB
- back up the DB
- restore the backup in a scratch partition and start the restored DB to ensure the backup is valid
- rename the control area from the original DB (to dbname.db.old)
- rename the old structure file and replace it with the new, correct structure file
- recreate the control area with prostrct builddb dbname
- back up the new DB
- start the new DB
- delete the restored by from the scratch partition
- clean up the old files
Thanks in advance.
Last edited: