From oracle-l-bounce@freelists.org Mon Apr 25 16:12:58 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j3PLCwbZ017034 for ; Mon, 25 Apr 2005 16:12:58 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j3PLCw4Z017030 for ; Mon, 25 Apr 2005 16:12:58 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2A99818643F; Mon, 25 Apr 2005 15:10:33 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13315-03; Mon, 25 Apr 2005 15:10:33 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A927B186751; Mon, 25 Apr 2005 15:10:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Subject: RE: LOCALLY MANAGED EXTENT PERFORMANCE Date: Mon, 25 Apr 2005 16:07:43 -0400 Message-ID: <61C900F558E4184DBD8E177CC9D51F67035D76A9@msexdb06.lowes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LOCALLY MANAGED EXTENT PERFORMANCE Thread-Index: AcVJzcDGHTnjKkFSSbagYq4rtCRq+QAAGITg From: "Dogan, Ibrahim - Ibrahim" To: , X-OriginalArrivalTime: 25 Apr 2005 20:07:43.0994 (UTC) FILETIME=[7121FDA0:01C549D2] X-archive-position: 18970 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: Ibrahim.Dogan@Lowes.com Precedence: normal Reply-To: Ibrahim.Dogan@Lowes.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=0.6 required=5.0 tests=LINES_OF_YELLING,SUBJ_ALL_CAPS autolearn=no version=2.63 Very simple, this gives a rough idea of what your next extents will be: SELECT e.owner, e.segment_name, e.extent_id, bytes AS last_extent_size FROM dba_extents e,=20 (SELECT owner, segment_name, MAX(extent_id) AS extent_id FROM DBA_EXTENTS GROUP BY owner, segment_name) ee WHERE e.owner=3D 'xxx' AND e.owner =3D ee.owner AND e.segment_name =3D ee.segment_name AND e.extent_id =3D ee.extent_id; Thanks, =20 Ibrahim DOGAN Sr. Sybase/Oracle DBA www.lowes.com > -----Original Message----- > From: oracle-l-bounce@freelists.org=20 > [mailto:oracle-l-bounce@freelists.org] On Behalf Of Tim Gorman > Sent: Monday, April 25, 2005 3:22 PM > To: oracle-l@freelists.org > Subject: Re: LOCALLY MANAGED EXTENT PERFORMANCE >=20 >=20 > From a production-support perspective... >=20 > For years, we've been using a script that would alert if any=20 > segments in a tablespace are going to run out of space within=20 > "N" extents (i.e. 5, 10, whatever). How do you do this for=20 > autoallocate tablespaces? >=20 > I know that some folks have reverse-engineered the sizing=20 > algorithm for autoallocate, but I don't think it is yet=20 > documented anywhere. Which means that Oracle can feel free=20 > to "tweak" it whenever they wish... >=20 > ...which means lots of pages in the middle of the night... >=20 >=20 >=20 >=20 > on 4/24/05 8:53 PM, Tanel P=3DF5der at tanel.poder.003@mail.ee wrote: >=20 > > Hi, > >=3D20 > > I haven't read the whole thread - but I'd just like to=20 > contribute the=20 > >fac=3D > t, > > that nowadays I save my time and create all tablespaces as=20 > >autoallocate - and haven't seen any performance nor other=20 > problems so=20 > >far. And I don't worry about the number or size of extents=20 > at all. =3D20 > > Tanel. > >=3D20 -- http://www.freelists.org/webpage/oracle-l