FAQ
Among some of the "Rube Goldberg" applications around here, is one that has
multiple replication clients that subscribe to a master. For whatever
reason, we might have a client not update for a while and the MLOG table(s)
get big. Then, after that, every update has to read up to sky-high high
water mark. From the looking around we have done, the thing to do to get
the HWM back down without rattling replication seems to be (during a time
when we know no updates are going into the master):

lock table xyz in exclusive mode;
alter table mlog$_xyz move tablespace over_there;
alter table mlog$_xyz move tablespace back_here; (optional, I suppose)
rollback; (release the lock)

Does anyone know of any issues, pitfalls, invitation for disaster, etc. with
this?
--
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).

Search Discussions

  • Arup Nanda at Jun 12, 2003 at 7:47 pm
    Stephen,

    I do it all the time. Actually you don't have to lock the table; you may
    simply quiesce the table, meaning no transations will be allowed.

    Steps:

    Quiesce the table
    Apply all the pending logs in the deferred trans queue on secondary database
    Truncate The MLOG$ table.

    No issues; in fact I think (note sure) it is supported by Oracle. And it
    should be; MLOG$ tables are just plain simple tables anyway.

    Hope this helps.

    Arup Nanda

    Original Message -----
    To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
    Sent: Thursday, June 12, 2003 3:54 PM
    Among some of the "Rube Goldberg" applications around here, is one that has
    multiple replication clients that subscribe to a master. For whatever
    reason, we might have a client not update for a while and the MLOG table(s)
    get big. Then, after that, every update has to read up to sky-high high
    water mark. From the looking around we have done, the thing to do to get
    the HWM back down without rattling replication seems to be (during a time
    when we know no updates are going into the master):

    lock table xyz in exclusive mode;
    alter table mlog$_xyz move tablespace over_there;
    alter table mlog$_xyz move tablespace back_here; (optional, I suppose)
    rollback; (release the lock)

    Does anyone know of any issues, pitfalls, invitation for disaster, etc. with
    this?
    --
    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).
  • Sarnowski, Chris at Jun 12, 2003 at 7:48 pm
    I don't think it will do quite what you want it to, since the 'alter table move'
    statements are DDL so will release the lock.

    I just tried this experiment in 2 SQLPlus windows:

    SQL 1.1> lock table blah in exclusive mode;
    returns with
    Table(s) Locked.

    SQL 2.1> insert into blah values (1);
    (this waits)

    SQL 1.2> alter table summ_snapshot move tablespace tools_data;
    returns with
    ERROR at line 1:
    ORA-00054: resource busy and acquire with NOWAIT specified

    but this is enough to release the first lock, because 2.1 now returns with
    1 row created.

    On the other hand the move should be harmless. I see someone else has given a response
    with the same ultimate moral, but I'll still post, to point out the lock behavior.
    -----Original Message-----
    From: Stephen Lee [mailto:[EMAIL PROTECTED]
    Sent: Thursday, June 12, 2003 3:55 PM
    To: Multiple recipients of list ORACLE-L
    Subject: Rebuilding MLOG tables



    Among some of the "Rube Goldberg" applications around here,
    is one that has
    multiple replication clients that subscribe to a master. For whatever
    reason, we might have a client not update for a while and the
    MLOG table(s)
    get big. Then, after that, every update has to read up to
    sky-high high
    water mark. From the looking around we have done, the thing
    to do to get
    the HWM back down without rattling replication seems to be
    (during a time
    when we know no updates are going into the master):

    lock table xyz in exclusive mode;
    alter table mlog$_xyz move tablespace over_there;
    alter table mlog$_xyz move tablespace back_here; (optional, I suppose)
    rollback; (release the lock)
    LEGAL NOTICE:

    Unless expressly stated otherwise, this message is confidential and may be privileged.
    It is intended for the addressee(s) only. Access to this e-mail by anyone else is
    unauthorized. If you are not an addressee, any disclosure or copying of the contents
    or any action taken (or not taken) in reliance on it is unauthorized and may be
    unlawful. If you are not an addressee, please inform the sender immediately.

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.net
    --
    Author: Sarnowski, Chris
    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).
  • Stephen Lee at Jun 12, 2003 at 7:59 pm
    I don't think we can go with the truncate table thing since there is too
    much weirdness around here in when a client -- and there are multiple
    clients -- might update: Network problems, box crashed, sunspots (Don't
    forget about the sunspots!). So if there are entries still hanging around
    in the MLOG table, we want to keep them.
    -----Original Message-----

    I do it all the time. Actually you don't have to lock the
    table; you may
    simply quiesce the table, meaning no transations will be allowed.

    Steps:

    Quiesce the table
    Apply all the pending logs in the deferred trans queue on
    secondary database
    Truncate The MLOG$ table.

    No issues; in fact I think (note sure) it is supported by
    Oracle. And it
    should be; MLOG$ tables are just plain simple tables anyway.

    Hope this helps.

    Arup Nanda
    --
    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).
  • Stephen Lee at Jun 12, 2003 at 8:08 pm
    Note: XYZ gets locked. MLOG$_XYZ gets moved.
    The lock on XYZ is probably overkill since I think replication puts
    trigger(s) on the master table which will prevent DML while MLOG is being
    moved. But ... A little overkill is good.
    -----Original Message-----
    From: Sarnowski, Chris [mailto:[EMAIL PROTECTED]
    Sent: Thursday, June 12, 2003 3:38 PM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: Rebuilding MLOG tables



    I don't think it will do quite what you want it to, since the
    'alter table move'
    statements are DDL so will release the lock.

    I just tried this experiment in 2 SQLPlus windows:

    SQL 1.1> lock table blah in exclusive mode;
    returns with
    Table(s) Locked.

    SQL 2.1> insert into blah values (1);
    (this waits)

    SQL 1.2> alter table summ_snapshot move tablespace tools_data;
    returns with
    ERROR at line 1:
    ORA-00054: resource busy and acquire with NOWAIT specified

    but this is enough to release the first lock, because 2.1 now
    returns with
    1 row created.

    On the other hand the move should be harmless. I see someone
    else has given a response with the same ultimate moral, but
    I'll still post, to point out the lock behavior.


    -----Original Message-----
    From: Stephen Lee [mailto:[EMAIL PROTECTED]
    Sent: Thursday, June 12, 2003 3:55 PM
    To: Multiple recipients of list ORACLE-L
    Subject: Rebuilding MLOG tables



    Among some of the "Rube Goldberg" applications around here,
    is one that has
    multiple replication clients that subscribe to a master.
    For whatever
    reason, we might have a client not update for a while and the
    MLOG table(s)
    get big. Then, after that, every update has to read up to
    sky-high high
    water mark. From the looking around we have done, the thing
    to do to get
    the HWM back down without rattling replication seems to be
    (during a time
    when we know no updates are going into the master):

    lock table xyz in exclusive mode;
    alter table mlog$_xyz move tablespace over_there;
    alter table mlog$_xyz move tablespace back_here; (optional,
    I suppose)
    rollback; (release the lock)

    LEGAL NOTICE:
    Unless expressly stated otherwise, this message is
    confidential and may be privileged. It is intended for the
    addressee(s) only. Access to this e-mail by anyone else is
    unauthorized. If you are not an addressee, any disclosure or
    copying of the contents or any action taken (or not taken) in
    reliance on it is unauthorized and may be unlawful. If you
    are not an addressee, please inform the sender immediately.
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.net
    --
    Author: Sarnowski, Chris
    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).
  • Arup Nanda at Jun 13, 2003 at 1:40 am
    XYZ does not get locked when the MLOG$_XYZ is moved. Moving the mlog$ will
    make any transactions on XYZ to fail because the trigger will fail to
    execute.

    The safest and recommended way is to queisce the replication master group by

    dbms_repcat.suspend_master_activity('GroupName');

    This makes the tables in the group "quiet", i.e. no DML is allowed. Then you
    can move the MLOG$ tables.

    .Hope this helps.

    Arup

    Original Message -----
    To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
    Sent: Thursday, June 12, 2003 4:45 PM
    Note: XYZ gets locked. MLOG$_XYZ gets moved.
    The lock on XYZ is probably overkill since I think replication puts
    trigger(s) on the master table which will prevent DML while MLOG is being
    moved. But ... A little overkill is good.
    -----Original Message-----
    From: Sarnowski, Chris [mailto:[EMAIL PROTECTED]
    Sent: Thursday, June 12, 2003 3:38 PM
    To: Multiple recipients of list ORACLE-L
    Subject: RE: Rebuilding MLOG tables



    I don't think it will do quite what you want it to, since the
    'alter table move'
    statements are DDL so will release the lock.

    I just tried this experiment in 2 SQLPlus windows:

    SQL 1.1> lock table blah in exclusive mode;
    returns with
    Table(s) Locked.

    SQL 2.1> insert into blah values (1);
    (this waits)

    SQL 1.2> alter table summ_snapshot move tablespace tools_data;
    returns with
    ERROR at line 1:
    ORA-00054: resource busy and acquire with NOWAIT specified

    but this is enough to release the first lock, because 2.1 now
    returns with
    1 row created.

    On the other hand the move should be harmless. I see someone
    else has given a response with the same ultimate moral, but
    I'll still post, to point out the lock behavior.


    -----Original Message-----
    From: Stephen Lee [mailto:[EMAIL PROTECTED]
    Sent: Thursday, June 12, 2003 3:55 PM
    To: Multiple recipients of list ORACLE-L
    Subject: Rebuilding MLOG tables



    Among some of the "Rube Goldberg" applications around here,
    is one that has
    multiple replication clients that subscribe to a master.
    For whatever
    reason, we might have a client not update for a while and the
    MLOG table(s)
    get big. Then, after that, every update has to read up to
    sky-high high
    water mark. From the looking around we have done, the thing
    to do to get
    the HWM back down without rattling replication seems to be
    (during a time
    when we know no updates are going into the master):

    lock table xyz in exclusive mode;
    alter table mlog$_xyz move tablespace over_there;
    alter table mlog$_xyz move tablespace back_here; (optional,
    I suppose)
    rollback; (release the lock)

    LEGAL NOTICE:
    Unless expressly stated otherwise, this message is
    confidential and may be privileged. It is intended for the
    addressee(s) only. Access to this e-mail by anyone else is
    unauthorized. If you are not an addressee, any disclosure or
    copying of the contents or any action taken (or not taken) in
    reliance on it is unauthorized and may be unlawful. If you
    are not an addressee, please inform the sender immediately.
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.net
    --
    Author: Sarnowski, Chris
    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).
    --
    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).
  • Jo_holvoet_at_amis.com at Jun 13, 2003 at 7:39 am
    IIRC you need to lock the parent table in one session and then do whatever
    you need to do to the mlog table in a SECOND session (because, as another
    poster pointed out, the lock will be released too soon otherwise).

    hth,
    Jo

    Stephen Lee <[EMAIL PROTECTED]>
    Sent by: [EMAIL PROTECTED]
    06/12/2003 22:41
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
    cc:
    Subject: RE: Rebuilding MLOG tables

    I don't think we can go with the truncate table thing since there is too
    much weirdness around here in when a client -- and there are multiple
    clients -- might update: Network problems, box crashed, sunspots (Don't
    forget about the sunspots!). So if there are entries still hanging around
    in the MLOG table, we want to keep them.
    -----Original Message-----

    I do it all the time. Actually you don't have to lock the
    table; you may
    simply quiesce the table, meaning no transations will be allowed.

    Steps:

    Quiesce the table
    Apply all the pending logs in the deferred trans queue on
    secondary database
    Truncate The MLOG$ table.

    No issues; in fact I think (note sure) it is supported by
    Oracle. And it
    should be; MLOG$ tables are just plain simple tables anyway.

    Hope this helps.

    Arup Nanda
    --
    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:
    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).
  • Stephen Lee at Jun 13, 2003 at 1:38 pm
    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).
  • Stephen Lee at Jun 13, 2003 at 2:13 pm
    Mebbe this has something to do with the implicit commit stuff associated
    with DDL (iirc)?

    I keep coming back to what Einstein said (I think it was him): Education is
    what is left over after you have forgotten everything you have learned.
    (quote might not be exactly correct)
    -----Original Message-----

    IIRC you need to lock the parent table in one session and
    then do whatever
    you need to do to the mlog table in a SECOND session
    (because, as another
    poster pointed out, the lock will be released too soon otherwise).
    --
    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).
  • Arup Nanda at Jun 13, 2003 at 3:34 pm
    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).
  • Stephen Lee at Jun 13, 2003 at 4:49 pm
    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).

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedJun 12, '03 at 7:20p
activeJun 13, '03 at 4:49p
posts11
users4
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase