Re: 8i server/8i lite replication

Thanks for the reply. turning off replication doesn't seem to be possible, since in the event that there is a change in the external feed, we would indeed want that to replicated by the snapshot sites. we'll just have to re-code the feed mechanism.

thanks.

In article <3820619D.3722D1FB_at_us.oracle.com>,   Pete Sharman <psharman_at_us.oracle.com> wrote:
> This is a multi-part message in MIME format.
> --------------A14A44D6FF16DE03B953FF95
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Babypuke
>
> Do you have the capability to add calls to REPLICATION_OFF and
> REPLICATION_ON procedures? Of course, there is a slight problem here
in
> that it's suggested that you need to suspend replication activity for
all
> master groups in your replicated environment before setting this
flag. I
> don't have two databases at the moment to play with to see if this is
> really a necessity or just a recommendation.
>
> Pete
>
> babypuke_at_my-deja.com wrote:
>
> > question about replication (fast refresh) behavior:
> >
> > consider a single-master replication system where the server is
8.1.5
> > on solaris. there are various oracle lite (8i) snapshot sites that
> > perform fast refreshes to retrieve updates from the server.
> >
> > the problem: the server is also updated nightly by an external data
> > source, with feeds that are NOT incremental. this data is fed into
the
> > server by a separate procedure (not by replication). the proc
> > typically updates ALL the rows in the server tables. what ends up
> > happening is that this procedure might have to set all the columns
in a
> > server table to themselves (i.e., no change), since the new data
feed
> > from the external source looks exactly like it did the day before.
> >
> > this, of course, is still considered an 'update' by replication, the
> > MLOG$_xxx get filled up, and the snapshot sites end up replicating
the
> > entire table even though nothing's changed and it's doing what it
> > thinks is a fast refresh.
> >
> > any ideas for a workaround? it's difficult to change the server
update
> > procedure. impossible to change the external source.
> >
> > thanks in advance ..
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --------------A14A44D6FF16DE03B953FF95
> Content-Type: text/x-vcard; charset=us-ascii;
> name="psharman.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Pete Sharman
> Content-Disposition: attachment;
> filename="psharman.vcf"
>
> begin:vcard
> n:Sharman;Pete
> tel;cell:+1.650.868.9969
> tel;fax:+1.650.633.1506
> tel;work:+1.650.607.0109
> x-mozilla-html:FALSE
> org:Advanced Technology Solutions;Oracle Corporation
> adr:;;500 Oracle Parkway M/S OPL-A4019;Redwood Shores;CA;94403;USA
> version:2.1
> email;internet:psharman_at_us.oracle.com
> title:Managing Principal Consultant
> note;quoted-printable:**** The statements and opinions expressed here
are my **** <br>=0D=0A **** own and do not necessarily represent those of **** <br>=0D=0A **** Oracle Corporation. **** <br>=0D=0A <br>=0D=0A "Controlling application developers is like herding cats." <br>=0D=0A Kevin Loney, ORACLE DBA Handbook <br>=0D=0A "Oh no it's not! It's much harder than that!" <br>=0D=0A Bruce Pihlamae, long term ORACLE DBA <br>
> x-mozilla-cpt:;9088
> fn:Pete Sharman
> end:vcard
>
> --------------A14A44D6FF16DE03B953FF95--
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Nov 15 1999 - 16:00:24 CST