Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: LMT monitoring

RE: LMT monitoring

From: Ron Thomas <rthomas_at_hypercom.com>
Date: Mon, 10 Mar 2003 13:29:30 -0800
Message-ID: <F001.005653D0.20030310132930@fatcity.com>

Was this a fresh tablespace or were there swiss cheese holes available to fill?

Ron Thomas
Hypercom, Inc
rthomas_at_hypercom.com
Each new user of a new system uncovers a new class of bugs. -- Kernighan

                                                                                                                                                 
                      ktoepke_at_trilegian                                                                                                          
                      t.com                    To:       ORACLE-L_at_fatcity.com                                                                    
                      Sent by:                 cc:                                                                                               
                      root_at_fatcity.com         Subject:  RE: LMT monitoring                                                                      
                                                                                                                                                 
                                                                                                                                                 
                      03/10/2003 02:02                                                                                                           
                      PM                                                                                                                         
                      Please respond to                                                                                                          
                      ORACLE-L                                                                                                                   
                                                                                                                                                 
                                                                                                                                                 




As mydata load continues, the saga continues. The simplistic algorithm does not hold....

Can anyone explain these results?

PARTITION_NAME                  EXTENT_ID BYTES/1024 BYTES/1024/1024
------------------------------ ---------- ---------- ---------------
FINS_FM_DATA_CLOSED_200207             84       6144               6
FINS_FM_DATA_CLOSED_200207             85       5120               5
FINS_FM_DATA_CLOSED_200207             86       6144               6
FINS_FM_DATA_CLOSED_200207             87       5120               5
FINS_FM_DATA_CLOSED_200207             88       5120               5
FINS_FM_DATA_CLOSED_200207             89       4096               4
FINS_FM_DATA_CLOSED_200207             90       5120               5
FINS_FM_DATA_CLOSED_200207             91       4096               4
FINS_FM_DATA_CLOSED_200207             92       4096               4
FINS_FM_DATA_CLOSED_200207             93       4096               4
FINS_FM_DATA_CLOSED_200207             94       4096               4
FINS_FM_DATA_CLOSED_200207             95       3072               3
FINS_FM_DATA_CLOSED_200207             96       4096               4
FINS_FM_DATA_CLOSED_200207             97       3072               3
FINS_FM_DATA_CLOSED_200207             98       3072               3
FINS_FM_DATA_CLOSED_200207             99       3072               3
FINS_FM_DATA_CLOSED_200207            100       3072               3
FINS_FM_DATA_CLOSED_200207            101       3072               3
FINS_FM_DATA_CLOSED_200207            102       3072               3
FINS_FM_DATA_CLOSED_200207            103       3072               3
FINS_FM_DATA_CLOSED_200207            104       3072               3
FINS_FM_DATA_CLOSED_200207            105       3072               3
FINS_FM_DATA_CLOSED_200207            106       3072               3
FINS_FM_DATA_CLOSED_200207            107       3072               3
FINS_FM_DATA_CLOSED_200207            108       3072               3
FINS_FM_DATA_CLOSED_200207            109       3072               3
FINS_FM_DATA_CLOSED_200207            110       3072               3
FINS_FM_DATA_CLOSED_200207            111       2048               2
FINS_FM_DATA_CLOSED_200207            112       2048               2
FINS_FM_DATA_CLOSED_200207            113       2048               2
FINS_FM_DATA_CLOSED_200207            114       2048               2
FINS_FM_DATA_CLOSED_200207            115       2048               2
-----Original Message-----
Sent: Monday, March 10, 2003 3:36 PM
To: 'ORACLE-L_at_fatcity.com'

According to a good email from Dan Fink (which I've since checked to 83 extents), the size of the extents is based soley on extent counts

             #extents                      next extent size
             1-15                                64k
             16-79                                     1m
             80-199                        8m
             200-                                64m

I would guess that in most cases "estimating" the next extent size to be 8m would be sufficient for space monitoring purposes

Kevin

-----Original Message-----
Sent: Monday, March 10, 2003 2:40 PM
To: Multiple recipients of list ORACLE-L

Kevin

   For Raj's purposes, is it possible to estimate a range? I'm thinking he really just needs an estimate to see if he is getting close.

Dennis Williams
DBA, 40%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Monday, March 10, 2003 12:40 PM
To: Multiple recipients of list ORACLE-L

There are three (3) types of LMTs (yes, three!)

UNIFORM Extent sizes
Every extent created in the tablespace will be the same size, no matter the storage parameters specified.

AUTOALLOCATE (System managed)
The system will decide the next extent size at creation. This is based on a large number of things. (I think the phase of the moon and the number of sun-spots on 03-03-1942 are included in this calculation) The min extent size is 64K

USER Allocated
This is only available for tablespaces that were converted from dictionary managed tablespaces. As it would seem, the user determines the space allocation -- the space allocation is the same as for dictionary managed tablespaces. The benefit is that bitmaps rather than freelists are used to identify free space.

With UNIFORM, you can tell exactly how many allocations will be required to fill up the tablespace. (freespace / extent-size = #allocs)

With User Allocated use the same logic as you would for dictionary managed tablespaces.

With Auto-Allocated extents, um. You don't know what the next extent size will be.

Kevin

-----Original Message-----
Sent: Monday, March 10, 2003 12:04 PM
To: Multiple recipients of list ORACLE-L

I admit to being sleep-deprived but I don't see how there is a difference between monitoring dictionary managed and locally managed tablespaces when you are talking about the inability to allocate another extent.

It seems relatively simple to me: check the size of the next extent that will be allocated (this can be calculated, regardless of auto allocate, uniform or dictionary managed next and pctincrease). Check to see if there is that much space available in the tablespace. If you REALLY want to be paranoid, do this as if you expect EVERY table and index in the tablespace to extend at the same time.

If remaining unallocated space is greater than the next extent allocation you calculate, you have enough space. If it is not, you have to add a datafile or extend the existing one.

Or am I missing something?

Rachel


Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Rachel Carmichael
  INET: wisernet100_at_yahoo.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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Toepke, Kevin M
  INET: ktoepke_at_TRILEGIANT.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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Toepke, Kevin M
  INET: ktoepke_at_trilegiant.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).





-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Ron Thomas
  INET: rthomas_at_hypercom.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).
Received on Mon Mar 10 2003 - 15:29:30 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US