Re: Replication or copy

"Kevin Grant" <K.Grant_at_nowhere.com.au> wrote in message news:Xns90B06389196C8KGRANTBNEQLDAU_at_132.234.250.31...
> "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in
> news:th3sev1joqb815_at_beta-news.demon.nl:
>
> >
> > "Johan Lorier" <johan.lorier_at_nl.abb.com> wrote in message
> > news:c4ce07bf.0105272159.4b65633a_at_posting.google.com...
> >> Hi all,
> >>
> >> i need a copy of an OLTP database, that will be used as a DSS. I think
> >> I have 2 options:
> >>
> >> 1 - Every night make a copy of the db-files to the DSS server
> >> 2- use replication
> >>
> >> Can anyone point me to (dis-)advantages of these options, especially
> >> about performance issues?
> >>
> >> Thxs a lot.
> >
> > Option 1 will simply not work at all, or the OLTP database needs to be
> > down during the event. This is necessary because otherwise you will be
> > getting inconsistent copies. If the database is down during copy you
> > will also need to recreate the controlfile.
> > So, just forget about this scenario: it is not going to work
>
> Option 1 does work. Every night we make a clone copy of our production
> database (without bringing it down) by copying the datafiles.
>
> There are a couple of pre-requisites however:
>
> - The production database must be in archive log mode.
> - Each tablespace must be in backup mode when copying its datafiles.
>
> The whole process goes something like this:
>
> For each tablespace do
> Start backup mode;
> Copy datafiles to remote clone location;
> End backup mode;
> done;
> Copy applicable archive log files to remote clone location;
> Create control file for clone;
> Recover clone;
> Startup clone resetlogs;
>
> Overall it's a complicated process but, as with anything, with practice
> it becomes a whole lot easier.
>
> We've written a script which does all the hard work for us. Now we just
> schedule the job in cron and when we arrive in the morning we have a
> brand spanking new clone database ;)
>
> Kev.
>
>

I see. That very much looks like you invented your own standby mechanism, doesn't it?
I have seen similar setups for NT, it failed just too often because of replicator problems.
I would have adressed this by a standby database (in 8.1.6 and beyond you can open the standby database for readonly, without stopping the standby mechanism)
Of course, if you don't have the Enterprise Edition you would need to resort to measures like you implemented.
I'm still asking myself whether you wouldn't have been better off with a different architecture, or if this setup can't be avoided, with Oracle Parallel Server.

Regards,

Sybrand Bakker, Oracle DBA Received on Tue May 29 2001 - 03:20:41 CDT