;> >the PCTFREE 99 and PCTUSED 1 attributes ?
>> >
>> >Hemant
>> >
>> >
>> >
>> >At 03:53 PM 24-09-02 -0800, you wrote:
>> >>I replied too soon earlier, I think.
>> >>
>> >>Yes, what you state is correct.
>>
Yes, I think I need to test it for myself and see what I get.
As for the busy table in a production environment [24x7, so there's no time
to rebuild the table normally], I've put in a request for 30minutes downtime
[I am allowed an occassional 15 to 30 minutes every two months] to rebuild
the t
ks in new extents take
> >the PCTFREE 99 and PCTUSED 1 attributes ?
> >
> >Hemant
> >
> >
> >
> >At 03:53 PM 24-09-02 -0800, you wrote:
> >>I replied too soon earlier, I think.
> >>
> >>Yes, what you state is cor
t;At 03:53 PM 24-09-02 -0800, you wrote:
> >>I replied too soon earlier, I think.
> >>
> >>Yes, what you state is correct.
> >>
> >>Jraed
> >>
> >>
> >>
> >>
> >>
> >>
> >>[EMAIL PROTECTED]
> &g
Hemant wrote
>>
Therefore, to reduce the contention for the "hot blocks", I decide
to have only 1 row in each block. Normally, with a *NEW* table,
PCTFRE 99 and PCTUSED 1 would ensure that I have only 1 row per block.
But if I have a large number of blocks in a few extents created when
PCTFREE w
what you state is correct.
>>
>>Jraed
>>
>>
>>
>>
>>
>>
>>[EMAIL PROTECTED]
>>Sent by: [EMAIL PROTECTED]
>> 09/24/2002 09:08 AM
>> Please respond to ORACLE-L
>>
>>
>> To: Multiple recipients of list O
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
> cc:
> Subject:RE: Is the effect of modifying PCTFREE/PCTUSED
> immediate ?
>
>
>Well I was sure about it until you had the temerity to question me :)
>I think we agree on extents s
RE: Is the effect of modifying PCTFREE/PCTUSED immediate ?
Well I was sure about it until you had the temerity to question me :)
I think we agree on extents sizes not being changed after the event so it
is
now a discussion on whether changes to a pctfree/pctused are
retrospective.
I contend tha
John,
You are right, I just find out note 1029850.6 on
metalink : "A block is relinked to a free list if
after DELETE or UPDATE operations, the percentage of
the used space falls below PCTUSED."
--- [EMAIL PROTECTED] a écrit : > Well I was
sure about it until you had the temerity
> to que
This was on 8.1.7 on Linux.
>
> It's in the archives if you care to look for it.
>
> Jared
>
>
>
>
>
>
> [EMAIL PROTECTED]
> Sent by: [EMAIL PROTECTED]
> 09/24/2002 09:08 AM
> Please respond to ORACLE-L
>
>
> To: Multiple
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
09/24/2002 09:08 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: RE: Is the effect of modifying PCTFREE/PCTUSED immediate ?
Well I was sure about i
I'm not sure either as I am rereading a document by
Craig Shallamaher where he is saying to change pctused
and pctfree in order to reduce data block
fragmentation. I have to test that.
At my new job, the DBAs are doing massive
export/import to reduce fragmentation... (with their
dictionnary manag
Well I was sure about it until you had the temerity to question me :)
I think we agree on extents sizes not being changed after the event so it is
now a discussion on whether changes to a pctfree/pctused are retrospective.
I contend that if a table is fully loaded upto its pctfree/pctused limits
Are you sure about that John?
On Tuesday 24 September 2002 04:28, [EMAIL PROTECTED] wrote:
> No, it is not retrospective.
> You are setting parameters to be used when the next extent is created.
> A better example is when setting next extent size to be different than the
> existing extent size
No, it is not retrospective.
You are setting parameters to be used when the next extent is created.
A better example is when setting next extent size to be different than the
existing extent size (dictionary managed tablespaces only).
It does not alter all the existing extents it only works on t
15 matches
Mail list logo
