Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Convert DM TSP to LM TSP w/ lots of data
This is what we have in mind.
For the partitioned tables that are going to have the 'rotation' logic, we will convert them to LMT when they become empty. We drop the 'oldest' partition and create a new one for next month. This will be carried out every month. Partition for November data is empty now and is being converted to use LMT as of this week; Next month we will do the same for December partition; This way, we would convert all our 5 CALLDETAIL tablespaces to use LMT in 5 months time.
Now, for other tablespaces that contain data and indexes, we need to decide whether we should create corresponding LMT tablespaces and move the existing objects to it or change them using the procedure that Oracle recommends; Some of these tablespaces are sized anywhere from 5Gb to 60Gb and we do not have much of freespace as buffer. Our database size is about 1.2 tera bytes. Also for this we might have to ask for a bigger maintenance window which will be hard to get. So we are toying up with the idea of converting them from DMT to LMT using 'in place' mechanism and rebuild the tables/indexes eventually as time permits. Obviously, we are not trying cause any outage knowingly. Hence these questions to the forum.
Thanks,
Govind
-----Original Message-----
Sent: Tuesday, October 29, 2002 8:49 AM
To: Multiple recipients of list ORACLE-L
Govind - I agree with Tom. Since you phrased your original question
asking
for those who had done the conversion, the silence was your answer. If
you
had also asked for replies from those who had decided to build new
tablespaces and convert the data ourselves, then more of us could have
replied. My reason for not using the conversion utility has to do with
the
smell test. After you've been a DBA for awhile, you realize you have
limited
time and you lose your eagerness to pursue things that will eat up
enormous
amounts of time and come to nothing. In my situation, I was able to move
a
table at a time to LMT as time permitted, and somehow I felt that the
resulting data situation would be better. I believe some of the new
nologging options may allow you to perform this while the table is still
available for DML. When first introduced, the conversion routines had
some
bugs. I don't think the conversion routines are bad today, so they may
work
just fine.
Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Tuesday, October 29, 2002 12:34 AM
To: Multiple recipients of list ORACLE-L
I tried having Oracle convert DMT to LMT out a few times on 10 GB
tablespaces. Whether or not that's a lot of data depends on you.
Worked
like a champ. And this was in the early days of LMT. People who pay a
lot
of attention to the internals will warn you that converting a DMT to LMT
is
not optimal. Your bitmaps wind up at the end of the files instead of
the
headers.
I've read posts here and elsewhere where people worried about the same
issues as they did with DMT. They wanted to limit the number of extents
segments grew to by creating tablespaces with different sized fixed
extents.
A DBA I worked with pointed out how very easy and quickly things worked
with
letting Oracle automatically size the next extent. I've gone that way
whenever possible and have never regretted it. I've not done a rigorous
benchmark but can tell you from casual observation dropping an object
with
lots of extents doesn't happen in the blink of an eye but doesn't lock
out
all other space allocation as UET/FET weren't constantly in use and the
ST
enque wasn't locked for exclusive use.
It's prudent to follow Oracle's recommendations if conditions permit. Create a new LMT and move your data to it.
I am reposting this. Has anyone tried to convert a dictionary managed
table
space containing lots of data to locally managed? We have tried this out
successfully on empty table spaces or created a new LMT tablespace and
moved
the existing objects to it.
Thanks,
Govind
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: DENNIS WILLIAMS
INET: DWILLIAMS_at_LIFETOUCH.COM
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: ListGuru_at_fatcity.com (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).
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: ListGuru_at_fatcity.com (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 Tue Oct 29 2002 - 11:48:51 CST
![]() |
![]() |