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

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Rebuilding MLOG tables

RE: Rebuilding MLOG tables

From: Stephen Lee <Stephen.Lee_at_DTAG.Com>
Date: Fri, 13 Jun 2003 09:49:51 -0700
Message-ID: <F001.005B1703.20030613092521@fatcity.com>

It looks like I must carefully go through all the replication stuff in the O'Reilly Oracle Built-in Packages and pick this stuff apart. This book puts the DBMS_REPCAT biz under Advanced Replication, so I have to see what differences there are (if any) and/or how applicable it is when doing simple snapshot replication -- which is what we have in this case. We have refresh groups on the clients, but since there is so much shuffling things around and changing things that goes on here, I really don't want to hard code any stuff in the script so it goes out to each client and tells them to lay low while I fiddle with the master. I guess I could have the script dig through dba_registered_snapshots to see what clients are out there, but geez, do I really have to make it that big of a chore? I'm trying to write a robust, reliably automated thing here. (What's the point in running Unix if you don't script all maintenance?)

One of the Murphy's Law issues I was thinking about was: What if I don't do anything with the clients and one of them decides the best time to update a snapshot is exactly the same time the MLOG table is getting moved around (Well sure!)? Does that get handled gracefully; or does it get handled like a bug on the windshield of high speed car?

There seems to be a dearth of info out there on the finer points of tidying up MLOG files.

> -----Original Message-----
> From: Arup Nanda [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2003 10:50 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Rebuilding MLOG tables
>
>
> You are very welcome.
>
> I agree, Oracle must have had a wave of those PHBs in their
> development side
> each with their own trumpet to blow and each left his or her
> legacy with a
> new package. Otherwise why they cose to have so many of
> these packages to
> do a few simple, very correlated things beats me. Even though
> I have been
> doing replication for seven years now, I have a hard time
> remembering which
> package has what.
>
> As to the last part of your post (the question actually), you
> always had to
> create a master group and associate a refresh group to that.
> The decision to
> include which tables in a master group depends on the
> relationship among the
> tables and whether they must be refreshed in one shot to
> maintain logical
> integerity. But I almost always found it better to have a
> group per a table.
>
> HTH.
>
> Arup Nanda
> www.proligence.com
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> Sent: Friday, June 13, 2003 10:09 AM
>
>
> >
> > Didn't know about this one. Thanky thanky.
> >
> > So now we have dbms_refresh, dbms_repcat, and dbms_mview
> (more?) each with
> > its own bucket of procedures. It gives one the impression
> that there is
> > some significant developer turnover at Oracle with each new batch of
> > programmers imposing their own ideas about things ought to done.
> >
> > I guess, for this to work, a master group (as opposed to a
> refresh group
> on
> > the client) must be created, eh?
> >
> > > -----Original Message-----
> > >
> > > The safest and recommended way is to queisce the replication
> > > master group by
> > >
> > > dbms_repcat.suspend_master_activity('GroupName');
> > >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Stephen Lee
> > INET: [EMAIL PROTECTED]
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web
> hosting services
> >
> ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> >
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Arup Nanda
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Stephen Lee
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Fri Jun 13 2003 - 11:49:51 CDT

Original text of this message

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