Re: Replication - how hard is it really? (Updatable snapshots..)

OK, I see where you're coming from with this point. Yes, it's not a straight forward process to investigate, but you can still see a lot of this happening inside the data dictionary. I haven't used Replication Manager in my current role with Oracle, so my memory's a bit vague on whether you could see it through that, but looking at some of the DBA views does allow you to track things (e.g. DBA_JOBS, DBA_JOBS_RUNNING, the DEF* views).

You can see whether the refresh is set to fast or whatever in DBA_REGISTERED_SNAPSHOTS, but I'm not sure if that shows you the status of the current refresh. What I mean by that needs a bit of explanation. As you're probably aware, the default for a refresh is FORCE (terrible default in my opinion). It can cause unexpected problems if you don't understand its effects. In my previous life as an Oracle consultant in Australia, we had a client who's data failed to refresh due to a communications failure. They did an alter snapshot refresh, which changed their setup from FAST to FORCE. WIth their flaky communications links, what this led to was:

1. The next refresh was attempted as FAST. This failed (comms down).
2. The next refresh was attempted as COMPLETE. This also failed (comms down).

That's the way FORCE works. It will attempt a FAST, then a COMPLETE refresh. And what does a COMPLETE do? Truncates the data first, then starts reloading it. As a result of the 2nd comms failure, the truncate succeeded, but only part of the reload did, so it appeared to the client they'd lost data. In fact, they hadn't; the next refresh to succeed would have repopulated the "missing" data.

So going back to my point of whether the current refresh is reflected in DBA_REGISTERED_SNAPSHOTS. It will probably show you the REFRESH_METHOD given by either the command to set the snapshot up or the command to alter it, but it may not show you that it's changed from FAST to COMPLETE when there's been a comms failure. I haven't investigated enough to confirm this though.

HTH. Pete

Kevin A Lewis wrote:

> Who knows how big the Lewis clan could be!
>
> Seriously though, my point about the 'black box' nature of relication is not
> being able (as far as I am aware) to see the state and nature of a
> replication process. You can see the start and end of reception from a
> snapshot and then the start and end of it's 'Refresh', however (again as far
> as I am aware) not be able to see where in each stage it has got to and what
> type of 'Refresh' is occuring i.e. Fast or otherwise. For information we are
> using a single Refresh Group to maintain referential integrity accross a
> number of simple snapshots.
>
> Regards
>
> --
> Kevin A Lewis (BOCM PAULS LTD - Animal Feed Manufacturer - Ipswich England)
> <KevinALewis_at_HotMail.com>
>
> The views expressed herein by the author of this document
> are not necessarily those of BOCM PAULS Ltd.
> Pete Sharman <psharman_at_us.oracle.com> wrote in message
> news:37655299.725D7FEB_at_us.oracle.com...
> > Oracle always has an answer, and in this case it's ...
> >
> > Oracle Consulting!
> >
> > Sorry, couldn't resist. As you say, it would be impossible to write such
> a
> > manual, and even if you did by the time you had it written it would be out
> > of date. That's where you need people involved. That's at least part of
> > why Tom and I (and others) keep an eye on this newsgroup, to try and
> ensure
> > people use the features appropriately. Unfortunately, it's impossible to
> > get all the information across in a newsgroup posting, so all we can do is
> > advise. You really need to get someone to come on site to determine
> > appropriateness of the advice to your business situation. I don't think
> > there's any danger to your livelihood here - we all still need people.
> >
> > Pete
> >
> > Jonathan Lewis wrote:
> >
> > > No relation (as far as I know).
> > >
> > > You've highlighted my biggest complaint about Oracle
> > > in that one small sentence. There are huge numbers of
> > > wonderful features to the product, but very little information
> > > about when it is appropriate to use one feature and avoid
> > > another.
> > >
> > > I have to admit that it would be very difficult to write
> > > some sort of manual that gave reasonably thorough
> > > guidelines - 8i stretches to about 20,000 pages
> > > when it does little more than list the commands and
> > > give syntactical examples of use; but it would be
> > > nice to have some sort documentation that outlined
> > > the realistic limitations of each feature.
> > >
> > > (Having said that, I make a living by advising people
> > > which are the best features of Oracle to use when
> > > turning a real-life problem into a physical model,
> > > so I'm really talking myself out of a livelihood here).
> > >
> > > --
> > >
> > > Jonathan Lewis
> > > Yet another Oracle-related web site: www.jlcomp.demon.co.uk
> > >
> > > Pete Sharman wrote in message <37652ECF.F7A31711_at_us.oracle.com>...
> > >
> > > >Kevin and Jonathan make some very good points (are you guys related at
> > > all?).
> > >
> > > > The main problem I have seen with it has been
> > > people not
> > > >understanding what it should be used for.
> >
> > --
> >
> >
> > Regards
> >
> > Pete
> >
> >

--

Regards

Pete

Received on Tue Jun 15 1999 - 10:58:52 CDT