[Oracle-l] Rebuilding MLOG tables

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).

reply | permalink

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).

reply | permalink

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).

reply | permalink

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).

reply | permalink

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).

reply | permalink

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).

reply | permalink

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).

reply | permalink

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).

reply | permalink

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).

reply | permalink

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).

reply | permalink

group	oracle-l @
categories	oracle
posted	Jun 12, '03 at 7:20p
active	Jun 13, '03 at 4:49p
posts	11
users	4
website	oracle.com

responses	expanded	Hotkey: s
font	variable	Hotkey: f
user style	avatars	Hotkey: a

[Oracle-l] Rebuilding MLOG tables

Search Discussions

Related Discussions

4 users in discussion