Re: Candidate for replication?

In article <3bbccb01.27717545_at_news1.lig.bellsouth.net>, staryeti_at_bellsouth.net says...
>
>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).
>

you can have refresh groups as well so that multiple tables are refreshed at the same time.

>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)?
>

it sounds like snapshots would satisfy your needs and move less data then a full export/import every night -- also the web site would never be unavailable during a "reload" using replication -- it would always be up.

>Are there any other considerations of snapshots I'm not considering? I
>think I remember something about indexing not being supported on the
>replica???
>

thats not true, you can have indexes and all. Any constraints you add must be DEFERRABLE but you can have them all.

>Thanks,
>Harry Boswell
>

--
Thomas Kyte (tkyte@us.oracle.com)             http://asktom.oracle.com/ 
Expert one on one Oracle, programming techniques and solutions for Oracle.
http://www.amazon.com/exec/obidos/ASIN/1861004826/  
Opinions are mine and do not necessarily reflect those of Oracle Corp