Jonathan wrote
> > I'd test what happens if the algorithm says 'I need a 64m extent'
> and
> > there is (say) 24m free space left. IIRC you do get an 'unable to
> > allocate extent blah' error but I can't swear to it, and it wouldn't
> at
> > all surprise me if the behaviour changed in a later rel
MAIL PROTECTED]
03/17/2003 12:28 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
cc:
Subject: Re: Autoallocate (was Re:
LMT monitoring)
No.. that should be:
With great power comes great responsibility.
CLE-L
To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
cc:
Subject: Re: Autoallocate (was Re:
LMT monitoring)
No.. that should be:
With great power comes great responsibility.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Now available
EMAIL PROTECTED]>
> cc:
> Subject:Re: Autoallocate (was Re:
> LMT monitoring)
>
>
>
>
> No.. that should be:
> With great power comes great responsibility.
>
> Regards
>
> Jonathan Lewis
> http://www.jlcomp.dem
yes, well, that too. :)
"Jonathan Lewis" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
03/17/2003 12:28 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject:Re: Autoallocate (
]
Sent by: cc:
[EMAIL PROTECTED] Subject: Re: Autoallocate (was Re:
LMT monitoring
No.. that should be:
With great power comes great responsibility.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Now available One-day tutorials:
Cost Based Optimisation
Trouble-shooting and Tuning
Indexing Strategies
(see http://www.jlcomp.demon.co.uk/tutorial.html )
UK_
Subject: RE: Autoallocate (was Re: LMT monitoring)
Jared - When it comes to comparing databases, a lot comes down to
perception. Oracle would like to market itself to small sites that don't
even have a DBA, otherwise if forfeits those accounts to Microsoft. Now,
when the MS sale
ecipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: RE: Autoallocate (was Re: LMT monitoring)
Jared - When it comes to comparing databases, a lot comes down to
perception. Oracle would like to market itself to small sites that don't
even have a DBA, ot
[EMAIL PROTECTED]
03/17/2003 06:28 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject:RE: Autoallocate (was Re: LMT monitoring)
Alex
If you do not specify the UNDO TABLESPACE when creating the d
pond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject:RE: Autoallocate (was Re: LMT monitoring)
Alex
If you do not specify the UNDO TABLESPACE when creating the database
then
AUTOEXTEND is set to ON. I was abl
-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject:RE: Autoallocate (was Re: LMT monitoring)
Alex
If you do not specify the UNDO TABLESPACE when creating the database
then
AUTOEXTEND is set to ON. I was able to alter that to OFF
Yet another reason for avoiding Automatic Undo -
one little accident can haunt you for ages.
It's also a major pain to find out exactly what does
go on in extreme cases because of the massive
delay between UNDO becoming redundant and
smon dropping it.
Regards
Jonathan Lewis
http://www.jlcomp.de
Alex
If you do not specify the UNDO TABLESPACE when creating the database then
AUTOEXTEND is set to ON. I was able to alter that to OFF.
The point of the UNDO is that it is automatically managed by Oracle. If
you can't cope with that, or you decide that doesn't work well for you, then
you ca
How about UNDO tablespace in 9.2?
It gets created with "autoallocate", and there is no way to change it or
specify any parameters for undo segments.
Each segment extended as needed, and when shrinked deallocated some extents
not necessary the last, than allocate new extent.
Alex.
- Original M
Notes inline
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Now available One-day tutorials:
Cost Based Optimisation
Trouble-shooting and Tuning
Indexing Strategies
(see http://www.jlcomp.demon.co.uk/tutorial.html )
UK___April 8th
UK___April 22nd
Denmark May 2
11 March 2003 16:29To: Multiple recipients
of list ORACLE-LSubject: RE: LMT monitoring
Here is my interpretation of algorithm suggested by
Conner, (I'll get to others too)
/* CASE WHEN
initial_extent < 1m THEN CASE WHEN EXTENTS < 16 THEN
NEXT = 64k,
Based on these two points:
> The version is 8.1.7.1.0
> The table is populated by sqlldr direct path.
I have a bit of gossip (i.e. someone I know
told me that someone he knows told him
that he'd heard that ...) there have been
cases where parallel execution slaves have
applied extent trimming in
Title: RE: LMT monitoring
Here is my interpretation of algorithm suggested by Conner,
(I'll get to others too)
/*
CASE WHEN initial_extent < 1m THEN
CASE WHEN EXTENTS < 16 THEN NEXT = 64k,
WHEN EXTENTS < 80 THEN NEXT = 1m,
WHEN EXTENTS < 2
Not that this helps Raj much, but the algorithm does
vary if the initial size of the segment is large,
along the lines of:
case
when initial_extent < 1m then
case when extents < 16 then next = 64k,
when extents < 80 then next = 1m,
when extents < 200 then ne
Title: RE: LMT monitoring
Connor,
What on earth you are doing on this list immediately after your Wedding? Which cruise liner has internet access?? I think Disney has ...
ps: Thanks for the algorithm, let me implement and see how good my data dictionary holds up.
Raj
The version is 8.1.7.1.0
The report is via this query:
SELECT partition_name, extent_id, bytes/1024, bytes/1024/1024
FROM dba_extents
WHERE segment_name = 'FORMATTER_DATA_HISTORY'
ANDowner = 'KEVIN'
ORDER BY 1, 2
The file is not autoextent.
The table is populated by sql
] 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
Which version of Oracle ?
How are you getting the report ?
Is the file autoextent - if so at what unit ?
How are you filling the table ?
Is the tablespace ASS Managed ?
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Now available One-day tutorials:
Cost Based Optimisation
Trouble-sh
Title: RE: LMT monitoring
Kevin, Dennis, JK and DF
Thanks for your input ... I am working on something to map out the extent list ... to find a pattern
Raj
-
Rajendra dot Jamadagni at espn dot com
Any views expressed here are
]
Sent by: cc:
[EMAIL PROTECTED] Subject: RE: LMT monitoring
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
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
#extentsnext extent size
1-1564k
16-79 1m
80-199 8m
200-
If you
read Jonathan Gennick's LMT article from the Nov/Dec 2000 Oracle Magazine
he discusses the possible extent sizes, i.e. 64k, 1M, 8M, and finally
64M.
http://www.oracle.com/oramag/oracle/00-nov/index.html?o60o8i.html
David
Ehresmann.
-Original Message-From: Daniel W. Fin
I *knew* I had talked to someone about a formula for this thanks!
I'm only half as crazy as I thought I was.
--- "Daniel W. Fink" <[EMAIL PROTECTED]> wrote:
> From my testing, I have found the following autoallocate alogrithm.
> The
> first 16 extents are 64k in size. The subsequent alloc
Title: RE: LMT monitoring
I was hoping someone would have the definitive answer!
A rough formula (derived from experimental observation) seems to be:
current object next extent
size (x) size
-- ---
0M < x <= 1M 64K
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 re
ndo, FL
Sunday, April 27 8:30am - 4:30pm - Problem Solving with Oracle 9i SQL
Wednesday, May 1 1:00pm - 2:00pm - Automatic Undo Internals
Jamadagni, Rajendra wrote:
RE: LMT monitoring
Rachel,
in case of auto allocate, oracle used 4 or 5 (experts
don't even agr
I thought (never having used autoallocate) that there was a set
formula for the allocation (I did mention I was sleep-deprived, didn't
I?)
Raj explained there is not and so I must apologize!
--- Jacques Kilchoer <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Rachel Carmicha
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
Title: RE: LMT monitoring
> -Original Message-
> From: Rachel Carmichael [mailto:[EMAIL PROTECTED]]
>
> 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
Title: RE: LMT monitoring
Rachel,
in case of auto allocate, oracle used 4 or 5 (experts don't even agree on if it is 4 or 5) fixed sizes (64k ...) and based on number of existing extents it will choose when an extent of next size should be allocated. The problem is there is no set fo
Title: RE: LMT monitoring
Dennis,
Yes it does, but it is too late in the game to do anything about it. That's why the question ...
Raj
-
Rajendra dot Jamadagni at espn dot com
Any views expressed here are strictly personal.
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 all
Raj
Are you using autoallocate or uniform extents. If you are using
autoallocate, wouldn't uniform extents make your task easier?
Dennis Williams
DBA, 40%OCP, 100% DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Monday, March 10, 2003 8:29 AM
To: Multiple recipie
Sounds like you are using LMTs with system allocation -
wait until you get to LMTs with system allocation and
ASS management.
Your problem is one of my favourite reasons for
sticking to LMTs with uniform extent management.
(see www.dbazine.com for an article wrote
on LMTs).
There is something on
41 matches
Mail list logo