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: '[EMAIL PROTECTED]'
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.
[EMAIL PROTECTED]
-----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
--- "Jamadagni, Rajendra" <[EMAIL PROTECTED]> wrote:
> I have been reading some docs on free space etc., but I have not yet
> found
> any conclusive document on how to monitors tables/indexes in LMT
> environment
> so that we could *predict* when a segment would not be able to
> allocated
> extent.
>
> Basically we want to monitor, when we needs to add more space to a
> tablespace, at-least 1 day before we get error messages. Devl team
> doesn't
> always tell us before dataload (it happens, and now they have been
> warned).
>
> I believe this is little bit complex compared to dictionary managed
> tablespaces, as (in auto allocate mode), there is no fixed published
> formula
> for next extent ...
>
> Any ideas? TIA
> Raj
> -------------------------------------------------------------
> Rajendra dot Jamadagni at espn dot com
> Any views expressed here are strictly personal.
> QOTD: Any clod can have facts, having an opinion is an art !!
>
> >
********************************************************************This
> e-mail message is confidential, intended only for the named
> recipient(s) above and may contain information that is privileged,
> attorney work product or exempt from disclosure under applicable law.
> If you have received this message in error, or are not the named
> recipient(s), please immediately notify corporate MIS at (860)
> 766-2000 and delete this e-mail message from your computer, Thank
>
you.*********************************************************************2
>
__________________________________________________
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: [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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Toepke, Kevin M
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: DENNIS WILLIAMS
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Toepke, Kevin M
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).
