Re: Restore to test env
Posted in 1997
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
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"
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *