Answered Change Physical Database Name

[RealHeavyDude]

OpenEdge 11.3 / Solaris SPARC 64Bit

I know that I can change the database name using probkup / prorest.

For a 1 TB large database this will take me a small alount of time given the ultra mega monster super duper SAN file systems I've been blessed with on which the database resides.

Although I doubt it, but nevertheless, does anybody know of a faster solution?

Thanks in Advance,
RealHeavyDude.

 

[Rob Fitzpatrick]

I'm not aware of any supported way to do this.

This might be technically possible with some kind of George Potemkin-esque extent surgery and file renaming. But even if it were possible, it wouldn't be supported and I wouldn't do it to a database I cared about.

It's a good idea for an enhancement though.
Products Enhancements - Progress Community

 

[TheMadDBA]

Nothing that I would use on a database I cared about. Why the need for the rename?

 

[TomBascom]

I would think that prostrct "builddb" might be an answer...

I'd be cautious. And test the daylights out of it.

 

[RealHeavyDude]

Thanks for your responses. The renaming is enforced on me - to me it does not make any sense at all.

Regards, RealHeavyDude.

 

[Cringer]

If it's enforced on you then tell them the cost associated with doing it right. Then it's their problem not yours.

 

[RealHeavyDude]

You wouldn't believe what can become solely your problem when the powers that be say it is yours ...

Regards, RealHeavyDude.

 

[RealHeavyDude]

I know this is not "officially supported" but, just for the record, here is what I did ( on a test system of course ):

1. Truncate the BI
2. Left AI enabled
3. Rename ( mv ) all files of the database ( from onedb_046 to xyz_4711 ).
4. Update the structure description file to reflect the name change.
5. Delete the .db file ( control area ) of the database.
6. Run prostrct buildb to re-generate a "lost" control area.

To my suprise I was successfully able to:

• Ttruncate the BI without any errors.
• Start the database server without errors.

So far I did not find any errors in the database log file.

Now I am wondering what other tests I should perform apart from having the applications run against the database?

Heavy Regards, RealHeavyDude.

 

[Cringer]

DBANALYS? Backup and restore? AI Roll Forward on the restored DB?

 

[RealHeavyDude]

Just to see what Progress is saying I opened a TechSupport call of type question on this. Hope to get a statement on that approach.

Heavy Regards, RealHeavyDude.

 

[TomBascom]

I would at least run a dbanalys

 

[RealHeavyDude]

dbanalys just passed out fine. Now poking around in promon ...

<just thinking out loud>
prostrct repair can officially be used to repair the database structure for example when one moved files of the database to another folder. I've done this several times in the past, never had any issue. It seems that only the whole path seems to be relevant. Now that I've moved ( renamed ) all files - it might a valid assumption that the scenario is the same, except that this time it is for ALL files ...
</just thinking out loud>

I am curious what Progress TechSupoort has to say on this.

 

[TomBascom]

While this is an unusual thing to do I think you are going to be fine. SFAIK the file names aren't kept anywhere except the .db file. The "repair" option is more common but "build db" is there to support just the sort of thing that you have done. Dbanalys shows that you didn't miss any extents.

 

[cj_brandt]

as a test, add a variable length extent without specifying the name to bi or ai or db and see if prostrct knows the proper name to give the new extent.

b .
a .
...

 

[RealHeavyDude]

Just added some extents online using the dot for the file name and prostrct did always pick up the correct file name.

As for TechSupport: They say, while it may work in test environments they do not recommend that approach for production environments. They reproduced my case with a copy of the sports2000 database. Anyway, their recommendation is Progress KB - How can I change the physical name of the database using probkup/prorest - using probkup / prorest.

So far this looks good and smells fine to me. Nevertheless, I will go for the probkup / prorest solution in the production environment. I don't want to add additional migration pressure ( to Oracle, Java ... ) onto the Progress environment by exposing myself utilizing unsupported approaches in a production system.

Anyway, it was worth a try and in the future I can use it in test environments.

Thanks for your ideas and comments, RealHeavyDude.

 

[Rob Fitzpatrick]

I don't have it in front of me but I seem to recall reading something (a KB? a Gus post on PEG?) about the impact of rebuilding the control area. As I recall it contains more than _Area and _Areaextext, like information about OE Replication, which would be lost if you ran prostrct builddb. But that may not be relevant for you.

I'll see if I can find the source of that info, assuming I'm remembering it correctly.