Comments on: ASSM wreck

By: Jonathan Lewis

Jonathan Lewis — Wed, 27 Apr 2011 16:43:26 +0000

Coskan,

Thanks for that – I thought I’d tried it on 11.2.0.2 but the note in my script header says I’ve only tested it on 10.2.0.3. (That’s not 100% guaranteed, but I’m usually quite careful about keeping the records up to date.)

By: coskan gundogar

coskan gundogar — Tue, 26 Apr 2011 23:43:57 +0000

Jonathan,

Can you also let us know What was the database version ?

I saw worst output from 11.2.0.2 with factor of 8 which is very big difference to be honest.

My after resultset was like below with same resultset for before image (don’t think it can effect but I am running on OEL6 which is not certified yet)

HEIGHT                        : 3
BLOCKS                        : 1152
NAME                          : T1_I1
PARTITION_NAME                :
LF_ROWS                       : 82501
LF_BLKS                       : 1008
LF_ROWS_LEN                   : 4577764
LF_BLK_LEN                    : 7996
BR_ROWS                       : 1007
BR_BLKS                       : 11
BR_ROWS_LEN                   : 57369
BR_BLK_LEN                    : 8028
DEL_LF_ROWS                   : 62501
DEL_LF_ROWS_LEN               : 3467964
DISTINCT_KEYS                 : 178
MOST_REPEATED_KEY             : 1936
BTREE_SPACE                   : 8148276
USED_SPACE                    : 4635133
PCT_USED                      : 57
ROWS_PER_KEY                  : 463.488764044943820224719101123595505618
BLKS_GETS_PER_ACCESS          : 235.244382022471910112359550561797752809
PRE_ROWS                      : 0
PRE_ROWS_LEN                  : 0
OPT_CMPR_COUNT                : 2
OPT_CMPR_PCTSAVE              : 79

By: Log Buffer #215, A Carnival of the Vanities for DBAs | The Pythian Blog

Log Buffer #215, A Carnival of the Vanities for DBAs | The Pythian Blog — Fri, 01 Apr 2011 22:13:08 +0000

[...] Jonathan Lewis introduces a framework that helps avoiding the traps inherent in writing PL/SQL loops when modelling a session that does lots of simple calls to the database. [...]

By: Jonathan Lewis

Jonathan Lewis — Thu, 31 Mar 2011 16:02:56 +0000

Laimis N,

I think it depends on what you mean by “connected”. The bug you’re referring to relates to a problem Oracle had trying to find an appropriate empty block on a block split so it’s not directly connected.

However the excessive waste of space does do two things – first it means that the index gets much bigger than it should, so you are more likely to see a root block split; secondly you do get a lot of empty leaf blocks, so Oracle is more likely to attempt to reuse an empty block which is not a legal choice.

It’s possible, by the way, that one of my clients was the source of that bug report (though it may have been a very similar one) because we uncovered exactly the equivalent of your “enq: TX – index contention” type of problem on a very high speed FIFO index a few years ago. (Some related details here: http://jonathanlewis.wordpress.com/2008/09/29/index-analysis-2/ )

By: Laimis N

Laimis N — Thu, 31 Mar 2011 06:02:09 +0000

Interesting, if that excessive space waste can also be connected to bug 8286901 “SPACE SEARCH INEFFICIENCY DURING INDEX SPLIT.” We’ve stumbled upon that bug in ASSM enabled database, mostly on “FIFO” (i.e. queue like) tables. The bug manifests itself in long “enq: TX – index contention” waits.
The bug fix sounds interesting: “Whenever the fix is enabled, root block splits examine no more than 5 empty blocks for reclamation before attempting a segment extension.”