Answered Renaming storage areas

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:

• 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

Approach 2:

• 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

I have tested both approaches and they work. I am leaning toward approach 2 as it involves less I/O, so less downtime. I'd like to get some feedback to confirm that either approach is valid and I haven't missed anything.

Thanks in advance.

How about "rename/remount the scratch partition as the real partition" once you verify that the restore works? Then just do a prostrct repair.

I don't have root on the box, so I would prefer to confine my team's activities to DB utilities rather than file system changes. The application doesn't require 24/7 uptime, so getting a maintenance window to follow either of the approaches above shouldn't be an issue. I just want to confirm that they are both sound approaches.

In that case I would view option #1 as being somewhat more conservative. But I'd probably go with option #2 because it is faster and it isn't a production system and I like to live on the edge sometimes

In this case it is a prod DB. So I'll stick to option 1. Thanks Tom.

Is there something in particular that makes the second approach risky? Is this not the intended use case for prostrct builddb? (Aside from a damaged or deleted .db file I guess.)

Somehow I had the idea that it was non-prod

No really good reason why I feel #2 is riskier -- it's just that #1 is, essentially, the same steps that you got there. So it seems "safer" in that nothing new is being introduced.

OK, fair enough. Thanks for your help.

Just an update: (finally) got the activity scheduled in prod, using approach 1 above. Worked fine.