RE: LOCALLY MANAGED EXTENT PERFORMANCE

From: Dogan, Ibrahim - Ibrahim <Ibrahim.Dogan_at_Lowes.com>
Date: Sat, 23 Apr 2005 00:46:08 -0400
Message-ID: <61C900F558E4184DBD8E177CC9D51F67035D7486@msexdb06.lowes.com>

Do not use uniform sized LMTs for volatile tables since you may end up having a table/index with thousand of extents..

More important, don't blame LMTs for it..=20

If you use AUTO extent allocation instead of uniform size, you won't have problem...

Thanks,
=20
Ibrahim DOGAN
Sr. Sybase/Oracle DBA
www.lowes.com

> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org=20
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Wolfson=20
> Larry - lwolfs
> Sent: Saturday, April 23, 2005 12:24 AM
> Cc: oracle-l_at_freelists.org
> Subject: LOCALLY MANAGED EXTENT PERFORMANCE

>=20
>=20

> Hi guys!
> =09
> Anyone seen any issues with large locally mananged extents?

>=20


> 	Recently I noticed one of my applications taking a long=20

> time to do truncates.
> =09
> And an index rebuild where I increased the locally=20
> managed extent size from 16K took almost an hour for 58,000=20
> extents when larger indexes (and extents) only took 3-4 minutes.

>=20


> 	I once had a purchased app using a 16K extent size for=20

> huge tables took 2 hours and 7 minutes to do a truncate on=20
> just one table (dictionary managed). I killed it the first=20
> time after 45 minutes cause I thought it was hung up somewhere else.
> Not sure why it was set to 16K in the first place. =20
> Good for testing I guess.

>=20


> 	Thanks

> 	Larry

>=20

> =09

>=20
>=20


> **********************************************************************

> The information contained in this communication is=20
> confidential, is intended only for the use of the recipient=20
> named above, and may be legally privileged. If the reader of=20
> this message is not the intended recipient, you are hereby=20
> notified that any dissemination,=20
> distribution, or copying of this communication is strictly=20
> prohibited. If you have received this communication in error,=20
> please re-send this communication to the sender and delete=20
> the original message or any copy of it from your computer=20
> system. Thank You.

>=20

> --
> http://www.freelists.org/webpage/oracle-l
>=20

--
http://www.freelists.org/webpage/oracle-l

Received on Sat Apr 23 2005 - 00:52:46 CDT