Cheating During DB Migration

Posted by Paul Koufalis on 03-Dec-2013 10:51

Production is in 10.2A

Future production will be 11.3

 

Problem: Need to refresh TEST (11.3) env from PROD (10.2A).

 

Question: Is there a way to avoid doing a prodel of the test 11.3 DB so that I can retain the physical structure on disk?  I want to trick OE 10.2A to permit a prorest of the 10.2A backup on top of the 11.3 structure.  After that I can run a conv1011.  All of this is just to save the time of re-creating 150 Gb of physical files on disk.

 

Paul

 

******************************************

* Paul Koufalis

* Progresswiz Consulting

*

* Email: pk@progresswiz.com

* Phone: 514 247 2023

* Fax  : 514 439 6782

*

* Progress, MFG/PRO, UNIX, Windows, EDI

******************************************

All Replies

Posted by Douglas R. Vanek on 03-Dec-2013 10:55

$DLC/(versionyouwant)utils/procopy empty sports

Posted by Paul Koufalis on 03-Dec-2013 11:11

That won't work because the existing test DB is 11.3. I cannot use 102b_dbutil to restore a 10.2B empty on top of an 11.3 DB.  But you've got the right idea: that's what I want to do.

Thanks

Paul

Posted by Marko Myllymäki on 04-Dec-2013 01:16

I'm not sure if I understood properly what you want (and don't want) to do, but since the database's physical structure is defined in the .st file, you can retain the existing structure by saving a copy of the .st file, deleting the old database and restoring the backup using the saved .st file. It might be a good idea to do "prostrct list" first to refresh the .st file.

Posted by Douglas R. Vanek on 04-Dec-2013 09:56

What he wants to do is to NOT have to delete and re-create the extents, but I can't think of a way to make this work.  The DB version is tagged in the master block... try deleting just the .DB file and using the v10 prostrct builddb to replace it? <-- This is so far beyond "not supported" that I hesitate to mention it.  :)

Posted by Paul Koufalis on 04-Dec-2013 10:27

Ha!  Great idea Doug!  I thought that would work but no.

$ rm dev-tst.db

$ which prostrct

/u1/oe102a/bin/prostrct

$ prostrct builddb dev-tst

** Database has the wrong version number. (db: 4269, pro: 4246). (44)

Any other such unsupported ideas?  Mike Furgal suggested a bunch of dd/hex edit stuff to hack the version but that's waaay too much of a pain to bother with.

Paul

Posted by Thomas Mercer-Hursh on 04-Dec-2013 11:07

I suspect that you are going to eventually come to the conclusion that any alternative will either take as long as building the extents or will be so much of a pain that it isn't worth it.  The one suggestion that I think buys you something is to use separate directories and build the void database in advance so that you don't have to spend that time in the actual transition.

Posted by Paul Koufalis on 04-Dec-2013 11:11

I have already come to that conclusion.  Now it's just about intellectual curiosity.

Posted by Rob Fitzpatrick on 04-Dec-2013 17:24

Isn't the DB master block in the schema area rather than the control area?

Posted by kunal.watkar on 07-Apr-2014 02:05

Paul,

So, did you got a way to restore 10.2A database backup on 11.3 database ?

Please let know if you had any luck.

Posted by Paul Koufalis on 07-Apr-2014 13:06

[mention:78986d0af21c4cfd90a7750353d17a0e:e9ed411860ed4f2ba0265705b8793d05] No I did not.  I suspect I could have hacked some master block somewhere and fooled the DB to allow it but that would not have exactly been a supported configuration!

This thread is closed