Re: Candidate for replication?

You could use standby database to implement your once-a-day-snapshot rather than exp/imp. Doing so would not require downtime on the primary database  assuming you are running in ARCHIVELOG ) and/or would not suffer from the Snapshot-too-old errors during a CONSISTENT exp with active users.

Do something like this...

foreach tablespace

    set in BACKUP MODE
    copy all associated datafiles to alternate location     END BACKUP MODE
end-foreach
create a standby controlfile -copy to alternate location Archive the current log on primary -copy to alternate location startup the alternate (secondary) database, recover it, and activate it.

You can get through that process much faster than an exp/imp.

Hth,

-Kevin

<staryeti_at_bellsouth.net> wrote in message news:3bbdc739.5503723_at_news1.lig.bellsouth.net...
> On 4 Oct 2001 23:57:58 -0700, pagesflames_at_usa.net (Dusan Bolek) wrote:
>
> >staryeti_at_bellsouth.net wrote in message
news:<3bbccb01.27717545_at_news1.lig.bellsouth.net>...
> >> I've got a project that will require making a
> >> read-only copy of our production database available
> >> to a new web-based system. The production database
> >> is Oracle8 (soon to be 8i); it consists of about
> >> 40 reference tables, which would tend to be fairly static,
> >> and about 60 data tables, about 30 of which would be
> >> used by the new web app, and which would be updated
> >> often. If I understand replication (snapshots) correctly, the
> >> replication is done on a table-by-table basis (I have to write a
> >> scripts for each table).
> >>
> >> Is this situation a good candidate for replication, or should I just
> >> create an automatic process to export from the production db each
> >> night and import a fresh copy into the read-only db daily? How
> >> fast would the replication scripts run once the initial copy is set up
> >> (i.e., is speed a consideration with this number of tables)?
> >
> >That depends on your needs. If your site is not 24/7 and read-only
> >copy of your database can contains one day old data, then running
> >exp/imp by scripts each night within backup window can be a good idea.
> >It will be simple to build and maintain. If you need exact copy
> >through the day, you can use replication or stand-by database.
> >
> >--
>
> The read-only db doesn't need to be real-time - right now it looks
> like a once-a-day snapshot would be fine. That could change down the
> road, maybe 6-12 months, though. At some point, the time spent doing
> the export/import could be a factor - it's not a 24/7, but it will
> be something like an 18/6.
>
> Thanks,
> Harry
>
Received on Fri Oct 05 2001 - 10:04:13 CDT