Re: Re: segment covers more blocks than needed

  • From: Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx>
  • To: "l.flatz@xxxxxxxxxx" <l.flatz@xxxxxxxxxx>
  • Date: Wed, 29 Jan 2020 10:49:05 +0000


Lothar,

Can you give an example of exactly what you mean by bad estimates.  Is it a 
significant over-estimate, or a zero estimate, or one of the "guess" figures ?

Regards
Jonathan Lewis


________________________________________
From: l.flatz@xxxxxxxxxx <l.flatz@xxxxxxxxxx>
Sent: 29 January 2020 10:38
To: Jonathan Lewis
Cc: Oracle-L@xxxxxxxxxxxxx
Subject: Re: Re: segment covers more blocks than needed

Hi Jonathan,

thanks for the explaination.
I have tested the Segment and indeed the populated blocks are somewhere in the 
extent and not at the start of the Segment.
Where I think Things goes wrong is that the blocks at the start of the Segment 
are even considered for dynamic sampling.
I believe the dynamic sampling arrives at the Conclusion that the segement is 
empty.
We have tested with serveral Levels of dynamic sampling . Anything below 3 
works, because DS is not done.
Any Level between 3-6 Fails to generate a correct estimate.
I wonder why empty blocks are not ignored by DS.
Can you shed some light on it?

Regards

Lothar

----Ursprüngliche Nachricht----
Von : jonathan@xxxxxxxxxxxxxxxxxx
Datum : 28/01/2020 - 17:00 (MZ)
An : Oracle-L@xxxxxxxxxxxxx
Betreff : Re: segment covers more blocks than needed


ASSM formats blocks on demand in chunks of 16 consecutive blocks. But the 
blocks aren't necessarily going to be the ones near the start of the extent 
(and when I've looked - only in passing - at cases where the segment size is 
1MB or 8MB the first 16 blocks seem to be at, or close to, the end of the 
extent.

The tablescan is then done from the start of segment to the "Low highwater mark 
(LHWM)" in unit of db_file_multiblock_read_count, then in units of multiples of 
16 blocks s between the LHWM and the High highwater mark (HHWM) - where the 
LHWM is nominally the point up to which the segment is formatted with no 
unformatted gaps below it.  (If you're unlucky Oracle could think that LHWM is 
right at the start of the segment when it's really thousands of blocks into the 
segment - but I haven't seen anything that extreme recently).

https://jonathanlewis.wordpress.com/2013/07/30/assm-2/
https://jonathanlewis.wordpress.com/2010/07/19/fragmentation-3/#more-4147

Regards
Jonathan Lewis

________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf 
of l.flatz@xxxxxxxxxx <l.flatz@xxxxxxxxxx>
Sent: 28 January 2020 15:50
To: Oracle-L@xxxxxxxxxxxxx
Subject: segment covers more blocks than needed

Hi,

I am no classical DBA, thus this question might be trivia for youl.
This issue causes serious misestomate when dynamic_sampling >= 4 is used.
We got a DWH with many small tables where stats are showing 502 blocks in 
DBA_TABLES.
Empty blocks is 0.
The Point is that there must be blocks which must (almost?) empty.
502 Blocks Matches with the initial size of the Segment.
We did a testcase. We created am empty table. No blocks when querying 
dba_tables of course.
After we inserted the first row (deferred_segment_creation = true) , again 502 
appeared in dba_tables.
DBMS_SPACE features this Output:

L/SQL-Prozedur erfolgreich abgeschlossen.
Unformatted Blocks = 486
Unformatted Bytes = 7962624
FS1 Bytes (at least 0 to 25% free space) = 0
FS1 Blocks(at least 0 to 25% free space) = 0
FS2 Bytes (at least 25 to 50% free space)= 0
FS2 Blocks(at least 25 to 50% free space)= 0
FS3 Bytes (at least 50 to 75% free space) = 0
FS3 Blocks(at least 50 to 75% free space) = 0
FS4 Bytes (at least 75 to 100% free space) = 262144
FS4 Blocks(at least 75 to 100% free space)= 16
Full Blocks in segment = 0
Full Bytes in segment  = 0

Segment_space_managment is AUTO. Tablespace has a uniform extent.
Runtime Stats show 28 buffers on FTS, proving that the HWM is not set after the 
first block.
Avg_row_len is 200. Remember this is only 1 row.

What is going on here?



Regards

Lothar











Full Bytes in segment  = 0Full Blocks in segment = 0FS4 Blocks(at least 75 to 
100% free space)= 63FS4 Bytes (at least 75 to 100% free space) = 1032192FS3 
Blocks(at least 50 to 75% free space) = 1FS3 Bytes (at least 50 to 75% free 
space) = 16384FS2 Blocks(at least 25 to 50% free space)= 0FS2 Bytes (at least 
25 to 50% free space)= 0FS1 Blocks(at least 0 to 25% free space) = 0FS1 Bytes 
(at least 0 to 25% free space) = 0Unformatted Bytes = 7176192Unformatted Blocks 
= 438
--
//www.freelists.org/webpage/oracle-l



--
//www.freelists.org/webpage/oracle-l


Other related posts: