Re: LMT- Migrated tablespaces
The paper by Juan Loaiza ("How to stop ... and start...") is not really
relevant or useful for LMT's. The 160 thing should really have been 128,
but was rounded due to the allocation algorithm. With LMTs that
algorithm is not a problem anymore, so more "sensible" extent sizes
should be used.
Also, the whole thing with many extents, etc. was an issue when dropping
DMTs, but nothing else. And it's completely gone with LMTs. One of my
guys - Johannes Djernes - ran a test where he first created a 60.000
extents table and dropped it (took about 2 seconds), then a 180.000
extents table and dropped it (took about 6-7 seconds).
It's of course all a matter of opinion, but I like the LMTs with a
uniform extent size. And then I don't much care what extent size it is,
but it would typically be a factor of 64. The auto allocate stuff
doesn't appeal to me, I must confess. I like the same extent size all over.
Mogens
Browett, Darren wrote:
I have crossposted this question on the Oracle-Apps list, I would like
to
get the opinion of this list as it is more of database issue as opposed
to apps.
The question is about LMT and extent management with regards to Oracle
11i.
When upgrading to 11i, it creates "migrated" LMTS as opposed to
"uniform/system" ones, and therefore do not conform to the rules
of "correct" LMTS.
My understanding is, even though my tablespaces are LMT, the tables
still act like they are dictionary managed with regards to extent
growth.
According to "How to stop defrag, and start living ." for tables
under 160M I should have an extent size of 160k.
With that in mind, should I
1) Create LMT Tablespaces with an extent size of 160k ? ( This is
ignored
by the import, tables will be one extent big)
2) Reset the "next_extent" on my apps tables to 160k ?
3) Set pctincrease to 0 ? ( I think this is a given )
Thanks
Darren
--
Darren Browett P.Eng This
message was transmitted
Data Administrator using
100% recycled electrons
Information and Communication Technology
City of Coquitlam
P:(604)927 - 3614
E:[EMAIL PROTECTED]
---
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?=
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).
Re: LMT- Migrated tablespaces
IIRC, a 160m table would be in an LMT with 4m extents. The 3 extent sizes recommended in the paper are 128k, 4m and 128m. > 1) Create LMT Tablespaces with an extent size of 160k ? ( This is > ignored by the import, tables will be one extent big) Not so. If you create an LMT of the correct name for imp to import a table into, it will be created with the uniform size extents you specified at tablespace creation. By 'correct name', I mean either a tablespace of the same name as the one the table was exported from, or the owners default tablespace is an LMT, and there is not a tablespace to match the name of that in the import file. > 2) Reset the "next_extent" on my apps tables to 160k ? > 3) Set pctincrease to 0 ? ( I think this is a given ) Both of these are invalid on an LMT. HTH, Jared On Friday 27 December 2002 10:13, Browett, Darren wrote: > I have crossposted this question on the Oracle-Apps list, I would like > to > get the opinion of this list as it is more of database issue as opposed > to apps. > > The question is about LMT and extent management with regards to Oracle > 11i. > > When upgrading to 11i, it creates "migrated" LMTS as opposed to > "uniform/system" ones, and therefore do not conform to the rules > of "correct" LMTS. > > My understanding is, even though my tablespaces are LMT, the tables > still act like they are dictionary managed with regards to extent > growth. > > According to "How to stop defrag, and start living ." for tables > under 160M I should have an extent size of 160k. > > With that in mind, should I > > 1) Create LMT Tablespaces with an extent size of 160k ? ( This is > ignored >by the import, tables will be one extent big) > 2) Reset the "next_extent" on my apps tables to 160k ? > 3) Set pctincrease to 0 ? ( I think this is a given ) > > Thanks > > Darren > > > > -- > Darren Browett P.Eng This > message was transmitted > Data Administratorusing > 100% recycled electrons > Information and Communication Technology > City of Coquitlam > P:(604)927 - 3614 > E:[EMAIL PROTECTED] > > --- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jared Still 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).
LMT- Migrated tablespaces
I have crossposted this question on the Oracle-Apps list, I would like to get the opinion of this list as it is more of database issue as opposed to apps. The question is about LMT and extent management with regards to Oracle 11i. When upgrading to 11i, it creates "migrated" LMTS as opposed to "uniform/system" ones, and therefore do not conform to the rules of "correct" LMTS. My understanding is, even though my tablespaces are LMT, the tables still act like they are dictionary managed with regards to extent growth. According to "How to stop defrag, and start living ." for tables under 160M I should have an extent size of 160k. With that in mind, should I 1) Create LMT Tablespaces with an extent size of 160k ? ( This is ignored by the import, tables will be one extent big) 2) Reset the "next_extent" on my apps tables to 160k ? 3) Set pctincrease to 0 ? ( I think this is a given ) Thanks Darren -- Darren Browett P.EngThis message was transmitted Data Administrator using 100% recycled electrons Information and Communication Technology City of Coquitlam P:(604)927 - 3614 E:[EMAIL PROTECTED] --- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Browett, Darren 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).
