Comments on: Using Bitmap Indexes Effectively http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/ Oracle Database Performance And Scalability Blog Mon, 01 Mar 2010 22:11:26 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: vlad http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/comment-page-1/#comment-221 vlad Thu, 05 Jun 2008 06:55:42 +0000 http://structureddata.org/?p=65#comment-221 11g serial direct reads are not driven by the _serial_direct_read parameter. They are of a different nature and it is a new 11g feature. At execution time, oracle will decide, based on state of buffer cache (how much of the table is cached) and size of table if it should go direct or cache. The feature is on and can be disabled (so to force cache reads systematically) only through an event. Direct reads are also currently much more efficient than cache reads in part due to the true asynchronous nature of the process (we have at least 2 set of private memory buffers to read into so we can populate one while looking at the other). In 11.2 (and maybe 11107), the numbers of these set of buffers dynamically adapt to the io performance. 11g serial direct reads are not driven by the _serial_direct_read parameter. They are of a different nature and it is a new 11g feature. At execution time, oracle will decide, based on state of buffer cache (how much of the table is cached) and size of table if it should go direct or cache. The feature is on and can be disabled (so to force cache reads systematically) only through an event. Direct reads are also currently much more efficient than cache reads in part due to the true asynchronous nature of the process (we have at least 2 set of private memory buffers to read into so we can populate one while looking at the other). In 11.2 (and maybe 11107), the numbers of these set of buffers dynamically adapt to the io performance.

]]> By: Greg Rahn http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/comment-page-1/#comment-216 Greg Rahn Sat, 31 May 2008 20:41:38 +0000 http://structureddata.org/?p=65#comment-216 Vyacheslav- You are correct. In 10g one will observe <strong>db file scattered read</strong> in the tracefile, however, it is also worth noting the that the default for <code>_serial_direct_read</code> is <code>FALSE</code> on both 10.2.0.3 and 11.1.0.6. I'll have to look into this more. Vyacheslav-

You are correct. In 10g one will observe db file scattered read in the tracefile, however, it is also worth noting the that the default for _serial_direct_read is FALSE on both 10.2.0.3 and 11.1.0.6. I’ll have to look into this more.

]]> By: Vyacheslav Rasskazov http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/comment-page-1/#comment-220 Vyacheslav Rasskazov Sat, 31 May 2008 11:17:04 +0000 http://structureddata.org/?p=65#comment-220 Hi Greg, It's seems that Query C will show different results for 10g database. 11g can do serial direct reads using _db_file_direct_io_count parameter for read size (1MB). At 10g serial direct reads are disabled by default (_serial_direct_read parameter), therefore there will be scattered read with read size driven by db_file_multiblock_read_count parameter. Regards, Vyacheslav Hi Greg,
It’s seems that Query C will show different results for 10g database. 11g can do serial direct reads using _db_file_direct_io_count parameter for read size (1MB). At 10g serial direct reads are disabled by default (_serial_direct_read parameter), therefore there will be scattered read with read size driven by db_file_multiblock_read_count parameter.

Regards,
Vyacheslav

]]> By: Greg Rahn http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/comment-page-1/#comment-219 Greg Rahn Fri, 30 May 2008 21:36:38 +0000 http://structureddata.org/?p=65#comment-219 In the experiment I ran, db version was 11.1.0.6 and used the default NOWORKLOAD stats. <pre> ----------------------------- SYSTEM STATISTICS INFORMATION ----------------------------- Using NOWORKLOAD Stats CPUSPEED: 930 millions instructions/sec IOTFRSPEED: 4096 bytes per millisecond (default is 4096) IOSEEKTIM: 10 milliseconds (default is 10) </pre> Bitmap operations do use CPU costing in both 10g and 11g. We can see the costing in the 10053 trace. It is very plausible that the plans would change if WORKLOAD stats were gathered. Perhaps I'll look into this. <pre> *************************************** BASE STATISTICAL INFORMATION *********************** Table Stats:: Table: BM_TEST Alias: BM_TEST #Rows: 16000000 #Blks: 102590 AvgRowLen: 55.00 Index Stats:: Index: BM1 Col#: 1 LVLS: 2 #LB: 727 #DK: 2 LB/K: 363.00 DB/K: 727.00 CLUF: 1454.00 Index: BM2 Col#: 2 LVLS: 2 #LB: 1061 #DK: 3 LB/K: 353.00 DB/K: 707.00 CLUF: 2121.00 Index: BM3 Col#: 3 LVLS: 2 #LB: 1358 #DK: 4 LB/K: 339.00 DB/K: 679.00 CLUF: 2717.00 Access path analysis for BM_TEST *************************************** SINGLE TABLE ACCESS PATH Single Table Cardinality Estimation for BM_TEST[BM_TEST] Column (#1): NewDensity:0.247047, OldDensity:0.000000 BktCnt:5418, PopBktCnt:5418, PopValCnt:2, NDV:2 Column (#2): NewDensity:0.119601, OldDensity:0.000000 BktCnt:5418, PopBktCnt:5418, PopValCnt:3, NDV:3 Column (#3): NewDensity:0.084256, OldDensity:0.000000 BktCnt:5418, PopBktCnt:5418, PopValCnt:4, NDV:4 Table: BM_TEST Alias: BM_TEST Card: Original: 16000000.000000 Rounded: 326278 Computed: 326278.00 Non Adjusted: 326278.00 Access Path: TableScan Cost: 28214.04 Resp: 28214.04 Degree: 0 Cost_io: 27787.00 Cost_cpu: 4763747547 Resp_io: 27787.00 Resp_cpu: 4763747547 ****** trying bitmap/domain indexes ****** Access Path: index (AllEqRange) Index: BM1 resc_io: 370.00 resc_cpu: 2782133 ix_sel: 0.505906 ix_sel_with_filters: 0.505906 Cost: 370.25 Resp: 370.25 Degree: 0 Access Path: index (AllEqRange) Index: BM2 resc_io: 256.00 resc_cpu: 1924689 ix_sel: 0.239203 ix_sel_with_filters: 0.239203 Cost: 256.17 Resp: 256.17 Degree: 0 Access Path: index (AllEqRange) Index: BM3 resc_io: 231.00 resc_cpu: 1736653 ix_sel: 0.168512 ix_sel_with_filters: 0.168512 Cost: 231.16 Resp: 231.16 Degree: 0 Access path: Bitmap index - accepted Cost: 23313.521250 Cost_io: 23286.784562 Cost_cpu: 298253099.420163 Sel: 0.020392 Not Believed to be index-only ****** finished trying bitmap/domain indexes ****** Best:: AccessPath: IndexBitmap Cost: 23313.52 Degree: 1 Resp: 23313.52 Card: 326278.00 Bytes: 0 *************************************** </pre> In the experiment I ran, db version was 11.1.0.6 and used the default NOWORKLOAD stats.

-----------------------------
SYSTEM STATISTICS INFORMATION
-----------------------------
  Using NOWORKLOAD Stats
  CPUSPEED: 930 millions instructions/sec
  IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
  IOSEEKTIM: 10 milliseconds (default is 10)

Bitmap operations do use CPU costing in both 10g and 11g. We can see the costing in the 10053 trace. It is very plausible that the plans would change if WORKLOAD stats were gathered. Perhaps I’ll look into this.

***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: BM_TEST  Alias: BM_TEST
    #Rows: 16000000  #Blks:  102590  AvgRowLen:  55.00
Index Stats::
  Index: BM1  Col#: 1
    LVLS: 2  #LB: 727  #DK: 2  LB/K: 363.00  DB/K: 727.00  CLUF: 1454.00
  Index: BM2  Col#: 2
    LVLS: 2  #LB: 1061  #DK: 3  LB/K: 353.00  DB/K: 707.00  CLUF: 2121.00
  Index: BM3  Col#: 3
    LVLS: 2  #LB: 1358  #DK: 4  LB/K: 339.00  DB/K: 679.00  CLUF: 2717.00
Access path analysis for BM_TEST
***************************************
SINGLE TABLE ACCESS PATH
  Single Table Cardinality Estimation for BM_TEST[BM_TEST]
  Column (#1):
    NewDensity:0.247047, OldDensity:0.000000 BktCnt:5418, PopBktCnt:5418, PopValCnt:2, NDV:2
  Column (#2):
    NewDensity:0.119601, OldDensity:0.000000 BktCnt:5418, PopBktCnt:5418, PopValCnt:3, NDV:3
  Column (#3):
    NewDensity:0.084256, OldDensity:0.000000 BktCnt:5418, PopBktCnt:5418, PopValCnt:4, NDV:4

  Table: BM_TEST  Alias: BM_TEST
    Card: Original: 16000000.000000  Rounded: 326278  Computed: 326278.00  Non Adjusted: 326278.00
  Access Path: TableScan
    Cost:  28214.04  Resp: 28214.04  Degree: 0
      Cost_io: 27787.00  Cost_cpu: 4763747547
      Resp_io: 27787.00  Resp_cpu: 4763747547
  ****** trying bitmap/domain indexes ******
  Access Path: index (AllEqRange)
    Index: BM1
    resc_io: 370.00  resc_cpu: 2782133
    ix_sel: 0.505906  ix_sel_with_filters: 0.505906
    Cost: 370.25  Resp: 370.25  Degree: 0
  Access Path: index (AllEqRange)
    Index: BM2
    resc_io: 256.00  resc_cpu: 1924689
    ix_sel: 0.239203  ix_sel_with_filters: 0.239203
    Cost: 256.17  Resp: 256.17  Degree: 0
  Access Path: index (AllEqRange)
    Index: BM3
    resc_io: 231.00  resc_cpu: 1736653
    ix_sel: 0.168512  ix_sel_with_filters: 0.168512
    Cost: 231.16  Resp: 231.16  Degree: 0
  Access path: Bitmap index - accepted
    Cost: 23313.521250 Cost_io: 23286.784562 Cost_cpu: 298253099.420163 Sel: 0.020392
    Not Believed to be index-only
  ****** finished trying bitmap/domain indexes ******
  Best:: AccessPath: IndexBitmap
         Cost: 23313.52  Degree: 1  Resp: 23313.52  Card: 326278.00  Bytes: 0

***************************************
]]> By: Chris Adkin http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/comment-page-1/#comment-218 Chris Adkin Fri, 30 May 2008 20:28:17 +0000 http://structureddata.org/?p=65#comment-218 Hi Greg, Am I correct in thinking that bit map operations will not use CPU costing and hence not know an I/O sub systems capabilities regarding single versus multiblocks reads, at least in 10g ?. Regards, Chris Hi Greg,

Am I correct in thinking that bit map operations will not use CPU costing and hence not know an I/O sub systems capabilities regarding single versus multiblocks reads, at least in 10g ?.

Regards,

Chris

]]> By: Log Buffer #99: a Carnival of the Vanities for DBAs http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/comment-page-1/#comment-217 Log Buffer #99: a Carnival of the Vanities for DBAs Fri, 30 May 2008 16:44:23 +0000 http://structureddata.org/?p=65#comment-217 [...] On Structured Data, Greg Rahn demonstrates using bitmap indexes effectively. [...] [...] On Structured Data, Greg Rahn demonstrates using bitmap indexes effectively. [...]

]]>