| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: RAC and LMT
And to amplify back again ... :)
You can move tables online, provided they're IOT's. If not, normal tables = can be moved pretty much online using DBMS_REDEFINITION. One stage require= s a lock for a brief time, but that's all.
=
Pete
=
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
=
"Oh no, it's not. It's much harder than that!" Bruce Pihlamae, long-term Oracle DBA
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] =
On Behalf Of Tim Gorman
Sent: Friday, 21 May 2004 4:43 PM
To: oracle-l_at_freelists.org
Subject: FW: RAC and LMT
To amplify Mr Sharman's reply...
ALTER TABLE <table-name> MOVE
[ PARTITION <part-name> | SUBPARTITION <subpart-name> ]
TABLESPACE <new-LMT>
PARALLEL <as-much-as-you-can-stand>
NOLOGGING;
Moving ONLINE is available only for indexes, unfortunately. And doing the
former (ALTER TABLE ... MOVE) will absolutely require the latter (ALTER
INDEX ... REBUILD).
ALTER INDEX <index-name> REBUILD
[ PARTITION <part-name> | SUBPARTITION <subpart-name> ]
TABLESPACE <new-LMT>
PARALLEL <as-much-as-you-can-stand>
[ ONLINE ]
NOLOGGING COMPUTE STATISTICS;
A great way to exercise the heck out of your disk drives, too...
on 5/19/04 3:27 PM, Pete Sharman at peter.sharman_at_oracle.com wrote:
> Lies, damned lies and LMT's. :)
> =
> Whoever told you LMT's were a requirement was wrong. A damn good idea, y=
es=3D
> , but not a requirement.
> =
> I haven't played with it much, but I remember hearing from Howard Rogers =
th=3D
> at the procedure you referred to left a certain amount to be desired from=
a=3D
> fragmentation perspective. Can't recall the details, but if you googled =
o=3D
> n c.d.o.s you'd find it.
> =
> As an aside, you don't need to export/import to achieve what you want. M=
ov=3D
> e the objects online instead if that's preferable.
> =
> =3D
> =
> Pete
> =3D
> =
> "Controlling developers is like herding cats."
> Kevin Loney, Oracle DBA Handbook
> =3D
> =
> "Oh no, it's not. It's much harder than that!"
> Bruce Pihlamae, long-term Oracle DBA
> =
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org=
] =3D
> On Behalf Of todd.sheetz_at_aurora.org
> Sent: Thursday, 20 May 2004 6:50 AM
> To: oracle-l_at_freelists.org
> Subject: RAC and LMT
> =
> We are currently on Oracle 8.1.7.3 on VMS and are starting the planning t=
o =3D
> upgrade to 9.2.0.5 later this year. Early next year we are planning on =3D=
> =
> implementing RAC. I have heard/read that LMT are required for RAC. We =3D=
> =
> are currently on dictionary managed per vendor mandate but will be able t=
o =3D
> use LMT by the time we go to RAC. My (long winded) question is whether =3D=
> =
> the DBMS_SPACE_ADMIN.TABLEPSACE_MIGRATE_TO_LOCAL is good enough to =3D
> =
> implement LMT for RAC. I understand that we won't have all the positives=
=3D
> =
> of LMT, but we are currently at 1.75 terabytes and I would not be looking=
=3D
> =
> forward to exporting and importing it tablespace by tablespace.
> Any thoughts or comments are greatly appreciated!
> =
> Thanks
> =
> Todd Sheetz
> Senior Database Administrator
> Aurora Health Care
> =
> Who's the more foolish? The fool or the fool who follows him. Obi-Wan Ke=
nobi
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Fri May 21 2004 - 01:49:31 CDT
 |
 |