Re: Restore to test env

In article <345FEF3E.8C2EC9B5@echonyc.com>, Cosmo Lee <"* N O - S P A M * cosmo"@echonyc.com> writes >It seems to me that this might be possible, but I haven't tried it. > >The issue that comes to my mind is this: If you're using a utility such as >`ontape` to make your archives, when you try to perform a restore, `ontape` >will seek to restore to the same links to the drive chunks as the production >DB from which the archive was created. *This would be a problem*, since >your production database is using those very same devices for real data. > >A way to get around this is to use something such as the chroot() function >to change your "root". Then, under your new root, you can create your >production DB with the "same" link paths. > >If you're using a utility such as `dbexport`, however, it doesn't care where >the chunks are, so you could just create a development DB in any physical >location and re-load the data. But in order to use `dbexport` for >archiving, it locks your DB in exclusive mode. So, this may not be an >option for you. But if you can do this (a DB lock), it is far easier to >implement a duplicate DB with `dbexport`, since it doesn't require restoring >data to the same chunk paths or an Online instance configured w/ virtually >the same ONCONFIG parameters. > >And that's another issue. If restoring w/ `ontape` you're going to have to >have almost all the ONCONFIG parameters the same in your development DB. >This can be a great: HASSLE. > >This brings up another issue: how will you restore from `ontape` (or other >archive utility) if you need to restore an Online instance with the same >name already running. I don't know the answer to this. Maybe someone else It is have the same SERVERNUM as an already running instance and hence fail creating it's first shared memory segment. Nice idea but won't boot!. >has an answer. I don't know if the archive utilites are specific regarding >the DBSERVERNAME. Could you restore from an `ontape` archive to a DBSERVER >w/ a different name??? > >My best answer to your problem is, "yes", if you can use `dbexport`. > >Though if you can afford the exclusive lock restriction and time required of >a `dbexport`, then you could actually skip `dbexport` altogether, just >create a duplicate DB and select from Production DB INTO Development DB. >This will be much faster than dumping Binary data to ASCII and then loading >ASCII back to Binary as `dbexport` would entail. > >How's that for a round-about answer?! > >HTH. > > >Adam Sorati wrote: > >> Eng: online 7.23.UC1 >> OS: AIX 2.4.1 >> HW: 1x166Mhz CPU, 128MG RAM and 2x4.5GIG disk. >> DB: 1.3 GIG >> 242 Tables >> >> I have a production instance and a development instance on the same >> machine, the database in each is the same. A level 0 backup is done >> each night for the production instance. >> >> A question has been put to me which I think is not possible however I >> am getting great pressure to solve it. >> >> The question ' Is it possible to restore an old production backup to the >> >> development instance, without effecting the production instance at all. >> >> Any help would be appreciated >> Thankyou >> >> Adam Sorati >> adams@sgen.com.au > > > >-- >* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >ADDRESS ALTERED TO FOIL SPAMMERS: Remove "*NO-SPAM*" to reply. > >Cosmo Lee Multi-User Computer Systems Brooklyn, NY > > "JUST SAY 'NO' TO SPAM" >* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > -- David Williams