As far as DDL is concerned ,Yes. I have seen Dataware House application(not 
a good design) that dropping/truncating tables with lot of extents takes 
longer time because of extent management. Such code must take into account 
no of extents of such objects. If those objects are created with proper 
sizing then it will perform better for any DDL.
Regards


MOHAMMAD RAFIQ



Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Date: Tue, 02 Oct 2001 13:15:30 -0800

Why is that?  And would that only count for an object in a dictionary
managed tablespace?  Would the time/speed it takes for drops and truncates
really matter as far as performance is concerned? What I mean is who would
set storage specs for objects with the speed it takes for truncates and
drops of that object in mind?  It would seem to me that if an object is
getting dropped or truncated that often that speed should be an issue, there
are bigger problems at hand. Guru's correct me if I'm wrong please. Later,
Ivan

-----Original Message-----
Sent: Tuesday, October 02, 2001 3:56 PM
To: Multiple recipients of list ORACLE-L


Any DDL like drop table and truncate table definately take longer with
10,000 extents than 1 extent. Try it. There was a test result 1 year back by

a list member on that.

Regards

MOHAMMAD RAFIQ



Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Date: Tue, 02 Oct 2001 07:55:28 -0800

That is completely a myth.  There is no notable performance different with a
table with 10,000 extents and one with 1.

The only problem is when it comes to the bitmaps when dealing with LMT and
cluster when dealing with dictionary managed.  When you query the extent
views, or do space management type processes.

"Do not criticize someone until you walked a mile in their shoes, that way
when you criticize them, you are a mile a way and have their shoes."

Christopher R. Spence
Oracle DBA
Phone: (978) 322-5744
Fax:    (707) 885-2275

Fuelspot
73 Princeton Street
North, Chelmsford 01863



-----Original Message-----
Sent: Monday, October 01, 2001 7:15 PM
To: Multiple recipients of list ORACLE-L

May be it is good practice to keep number of extents to be less than 50, no
matter what the size of extent.



-----Original Message-----
Sent: Monday, October 01, 2001 3:35 PM
To: Multiple recipients of list ORACLE-L


Hello,

I'll do an reorganization of a database (about 140 gigs). Some people say
that it'd be good to use 128K, 4M and 128M extents. I saw somewhere it'd be
160K, 4M and 160M. Which size do you advice me ? I have also many small
indexes (less than 16K).

Regards,

Thanh-truc Nguyen

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Thanh-truc Nguyen
    INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Wong, Bing
    INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Christopher Spence
    INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Mohammad Rafiq
   INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Mohammad Rafiq
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).

Reply via email to