Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Snapshots: Problematic Large Table

Snapshots: Problematic Large Table

From: Ian S. Fogarty <fogartis_at_capital.net>
Date: 1997/06/22
Message-ID: <5ok70l$rp0$1@usenet.logical.net>#1/1

I posted the following on the MetaLink Oracle Server 7 forum a week or so ago. I guess it's a stumper. Any ideas?

There is one production database, and one snapshoted replica. The replica is kept up to date nightly through the use of fast refresh. A few weeks ago the replica database encountered space problems, and unfortunately the snapshot was dropped. To avoid ever growing snapshot log tables, the snapshot logs were dropped a day later.

Lately, administrators of the reporting/replica database have been importing logical exports of the large table, to keep the database somewhat consistent.

The table has over 10 million rows and seems to take an eternity to replicate within the batch window, and runs into rollback segment consistency problems, even though on-line usage is low. WAN?

Sooo... I was hoping that someone might have already encountered this situation and figured out some way to: 1) dump the table to flat file with the rowid included, 2) recreate the snapshot log, 3) create the snapshot with a subquery that will replicate 1 row, 4) delete the row within the snap$_<table> on the replica database, 5) sqlload the data into the snap$_<table>, 6) then trick the snapshot into thinking it's up to date, 7) change the subquery to replicate everything, 8) fast refresh forever after.

We have performed some preliminary tests that do not look promising. Namely, rows manually placed within the snap$_<table> seem to be removed. Received on Sun Jun 22 1997 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US