SlideShare ist ein Scribd-Unternehmen logo
1 von 40
Downloaden Sie, um offline zu lesen
Santosh Kangane – Oracle DBA
santoshkangane.wordpress.com
santoshkangane.blogspot.in
www.linkedin.com/pub/santosh-kangane/1b/78b/6b
                                                 1
Highlights

    Background of CBO
    Oracle Database Memory Structures
    Table Scans
    CPU Costing Model
    Index and Clustering Factor
    Dynamic Sampling and Histogram
    Query transformation
    Join Methodologies

 There are NO thumb Rules in Oracle. Different Versions of Oracle and data
                  Patterns Drives the SQL performance !!!!
 This presentation is just to introduce as to How CBO workouts the SQL plans
       That probably will help you to find what is suitable for given SQL.
                      How you write a SQL, it matters !!!!
                                                                           2
Cost Based Optimization : Evolution


 • Traditional          : Simple counting of read requests
 • System statistics (1) : Accounting for size and time of read requests
 • System statistics (2) : Accounting for size and time of read requests and
                           CPU costs
 • System statistics (3) : Accounting for size and time of read requests and
                           CPU costs and caching.




                                                                               3
Query Execution




                  4
Three different layers of operational complexity

• First : The execution plan tells you what the optimizer thinks is going to
     happen at run time, and produces a cost based on this model.

• Second : The execution engine starts up and executes the model dictated by
     the optimizer- but the actual mechanism is not always identical to the
     model (alternatively, the model is not a good description of what
     actually happens).

• Finally: there are cases where the resources required to execute the model
     vary dramatically with the way in which the incoming data happens to
     be distributed.

In other words, the optimizer’s execution plan may not be exactly the run-
time execution path, and the speed of the run-time execution path may be
affected by an unlucky choice of data.


                                                                           5
When CBO makes errors

•   Some inappropriate assumptions are built into the cost model.
•   The relevant statistics about the data distribution are available, but
    misleading.
•   The relevant statistics about the data distribution are not available.
•   The performance characteristics of the hardware are not known.
•   The current workload is not known.
•   There are bugs in the code.




                                                                             6
Oracle Database Memory Structure




                                   7
Table Scans


1. db_file_multiblock_read_count :
         Multiple block read count allowed in single IO operation.
         Is always set to the maximum allowed by the operating system by
           default.
         Oracle Calculates the IO cost based on the MBRC and system
           statistics.
         When Oracle executes the tablescan, how many blocks does it try
           to read in a multiblock read? Is it the value of MBRCor something
           else?
            Answer: Oracle still tries to use the actual value for
           db_file_multiblock_read_count—scaled up or down if we are
           reading from a tablespace with a nondefault block size.
         If workload statistics are not gathered then system uses non
           workload stats.



                                                                         8
Table Scans


2. Full Table Scan:
   When performing a full table scan, it reads the blocks of the table into
    buffers and puts them on the LRU end (instead of the MRU end) of the
    LRU list.
   This is because a fully scanned table usually is needed only briefly, so the
    blocks should be moved out quickly to leave more frequently used
    blocks in the cache.
   You can control this default behavior on a table-by-table basis.
   To specify that blocks of the table are to be placed at the MRU end of
    the list during a full table scan, use the CACHE clause when creating or
    altering a table or cluster.
   You can specify this behavior for small lookup tables (Keep pool) or large
    static historical tables(Recycle pool) to avoid I/O on subsequent
    accesses of the table.
   Transactional table MUST not be added to CACHE.

                                                                             9
Table Scans


3.   Parallel Execution: (/*+ PARALLEL */ or ALTER TABLE <<T1>> PARALLEL)
         I. The user session or shadow process takes on the role of a
              coordinator, often called the query coordinator and necessary
              number of parallel slave processes.
         II. The SQL statement is executed as a sequence of operations.
              While the parallel slaves are executing, the query coordinator
              performs any portion of the work that cannot be executed in
              parallel.
         III. Finally, the query coordinator returns results to the user.

 Parallel scans use direct path reads to bypass the data buffer and read
  blocks directly into local (PGA) memory.
 A parallel query will first issue a segment checkpoint to get all dirty blocks
  status for the segment written to disk before it reads.
 This could lead to a performance problem in rare cases that mixed a large
  data buffer, a busy OLTP system, and parallel execution for reports.
                                                                            10
Costing Model




                11
What is Cost ?

 According to the CPU costing model:
 Cost = (
            #SRds * sreadtim +
            #MRds * mreadtim +
            #CPUCycles / cpuspeed
         ) / sreadtim
 where,
            #SRDs - number of single block reads
            #MRDs - number of multi block reads
            #CPUCycles - number of CPU Cycles
            sreadtim - single block read time
            mreadtim - multi block read time
            cpuspeed - CPU cycles per second

Translated,
The cost is the time spent on single-block reads, plus the time spent on multi block
reads, plus the CPU time required, all divided by the time it takes to do a single-
block read.

                                                                                 12
Statistics

Optimizer statistics are a collection of data that describe more details about the
database and the objects in the database.

Optimizer statistics includes :
Table statistics
     Number of rows
     Number of blocks                                    USER_TABLES / DBA_TABLES
     Average row length
Column statistics
     Number of distinct values (NDV) in column
                                                            USER_TAB_COLUMNS /
     Number of nulls in column
                                                             DBA_TAB_COLUMNS
     Data distribution (histogram)
     Average Column length
Index statistics
     Number of leaf blocks                                      USER_INDEXES
     Levels
     Clustering factor
System statistics
     I/O performance and utilization                         DBA_TAB_STATISTICS
     CPU performance and utilization                                                 13
Cardinality (Selectivity)

 In an audience of 1,200 people. How many of them do you think were
 born in December? And What if 120 of them don’t remember their birth date ?
Optimizer is thinking ....
    •   Base selectivity = 1/12 (from density or from 1/num_distinct)
                        user_tab_col_statistics.num_nulls = 0         user_tab_col_statistics.
    •   num_nulls = 120 & num_rows = 1200
                        user_tab_col_statistics.num_distinct = 12     user_tab_col_statistics.n
                                                                                      /13?
    •   Adjusted selectivity = Base selectivity * (num_rows - num_nulls)
                        user_tab_histograms.low_value = 1             user_tab_histograms.low
                                            num_rows
                        user_tab_histograms.high_value = 12           user_tab_histograms.hig
    •   Adjusted selectivity = (1/12) * ((1200 - 120)/1200) = 0.075
                        user_tables.num_rows = 1,200                  user_tables.num_rows =
    •   Adjusted cardinality = Adjusted selectivity * num_rows
    •                   So, user_tab_col_statistics.Density = 1/12
        Adjusted cardinality = 0.075 * 1200 = 90                      So, user_tab_col_statist

                             Cardinality = 100       Cardinality = 90


Cardinality = num_rows / num_distinct (If no histogram is prepared )
Cardinality = num_rows * density (If histogram is prepared )                         14
Cardinality (Selectivity)


Basic formulae of Selectivity :

     The selectivity of (predicate1 AND predicate2) =
                               Selectivity of (predicate1) * Selectivity of (predicate2).
     The selectivity of (predicate1 OR predicate2) =
                             selectivity of (predicate1) + selectivity of (predicate2) minus
                              selectivity of (predicate1 AND predicate2)
                                             ... otherwise, you’ve counted the overlap twice.
     The selectivity of (NOT predicate1) = 1 – selectivity of (predicate1)
     Range Selectivity = “required range” divided by “total available range”

Cardinality :
    Cardinality = Selectivity * num_rows




                                                                                         15
Index

  Cost = blevel +
        ceiling(leaf_blocks * effective index selectivity) +
        ceiling(clustering_factor * effective table selectivity)
Translated,
Cost to reach to, the Level of index node from root in Balanced B-Tree + number of
leaf blocks to be walk through to get rowids + cost to access table.

   B+ Tree Index :
    To Scan the index segment oracle uses Binary tree travels algorithm.
    The depth of B+ Tree varies from 1 to 4. Mostly its 2 or 3 and Max 4 for larger table
        index




                                                                                     16
Index: Clustering Factor




Clustering factor resolution logic does not consider the Cache hit, Hence some
time gives unrealistic values.                                               17
Index: Clustering Factor

     SELECT /*+
                   cursor_sharing_exact
                   dynamic_sampling(0)
                   no_monitoring
                   no_expand
                   index (t,"AWBMST_DPUDATE")
                   noparallel_index(t,"AWBMST_DPUDATE")
           */
           Sys_op_countchg(substrb(t.rowid,1,15),&m_history) as clf
     FROM AWBMST T;
     WHERE DPUDATE IS NOT NULL;


 • &m_history represent the number of block visited most recently. This value should be
   freelists value of table or 16 in case of ASSM tablespace.
 • use dbms_stats.get_index_stats and dbms_stats.set_index_stats to set the correct
   value of Clustering factor.
 • This should be used only for critical indexes where you find default method of oracle
    giving you a wrong statistics and it not recommended to apply for all index always.
                                                                                  18
Index: Selection

 1.   Range-based predicate (e.g., col1 between 1 and 3) would reduce the
      benefit of later columns in the index. Any predicates based on columns
      appearing after the earliest range-based predicate would be ignored
      when calculating the effective index selectivity—although they would
      still be used in the effective table selectivity—and this could leave Oracle
      with an unreasonably high figure for the cost of that index.
      Columns that usually appeared with a range-based predicate toward the
      end of the index definition.
 2.   For improving the compressibility of an index, Put the least selective
      (most repetitive) columns first.
 3.   Re-arranging the column sequence in the index changes the
      clustering_factor and Index Selectivity...
 4.   Appearance of column sequence in there WHERE clause does not affect
      the index selectivity.
 5.   If Index in unique in nature then do create them as UK index instead of
      normal index, other wise Optimizer has to refer Histogram and figure
      out the index uniqueness. That changes optimizers access path option.
                                                                               19
Dynamic Sampling

How and when will DS be use?
During the compilation of a SQL statement, the optimizer decides whether to
use DS or not by considering whether the available statistics are sufficient to
generate a good execution plan. If,
1. Available table statistics are not enough.
2. When the statement contains a complex predicate expression and
   extended statistics are not available.

OPTIMIZER_DYNAMIC_SAMPLING
 Parameter defines the number of blacks to read for Sampling.
 It can have value from 0 to 10. Default is 2.
 More the value if DS parameter, more time it takes to compile the SQL
   Statement.




                                                                            20
Histogram

Histograms feature in Oracle helps optimizer to determine how data is skewed
(distributed) with in the column
Advantage of Histogram :
1. Histograms are useful for Oracle optimizer to choose the right access
   method in a table.
2. It is also useful for optimizer to decide the correct table join order. When
   we join multiple tables, histogram helps to minimize the intermediate
   result set. Since the smaller size of the intermediate result set will
   improve the performance.




                                                                             21
Query transformation

1. Join elimination (JE) :
    A technique in which one or more tables can be eliminated from the
execution plan without altering functional behaviour.




                                                                         22
Query transformation

1. Join elimination (JE) :
   Example 2 : Elimination by Constraints or reference,
   Following table T1 and T2 has FK constraints over T1.N1 and T2.N2 and SQL is
   selecting data only from T2 table. So, No need to check if the Key is exists in
   T1 and join can be eliminated safely…




                                                                             23
Query transformation

2. Subquery Unnesting :
 Subqueries can be unnested in to a join.
                                                     Oracle executes a sub query
 Subquery is unnested in to a view and then joined to other row sources.
                                                     once for each distinct value
 In this listing, a correlated subquery is moved in to a view VW_SQ_1,Hashes
                                                     from driving table and
     unnested and then joined using Hash Join technique. subsequent rows it will
                                                     it. For
                                                      use the same results from
                                                      Hash table instead of re-
                                                      executing sub query.




                                                                               24
Query transformation : Transitive Closure




                                            25
IN Vs EXISTS , NOT IN Vs NOT EXISTS

 What to use ? Why ?
  Depends !
Why there is Myth ......
     Up to oracle 8i optimizer has suffer through the cardinality approximation issue.

                  select * from AUDIENCE where month_no in ( 6, 7, 8);

  Actual problem :
     Internally, the optimizer will convert a predicate in to OR clauses.
     The error that 8i suffers from is that after splitting the list into separate
          predicates, it applies the standard algorithm for multiple disjuncts (the
          technical term for OR’ed predicates) and Fails to process it correctly.
     sel(A or B or C) = sel(A) + sel(B) + sel(C) – Sel(A)sel(B) – Sel(B)sel(C) –
          sel(C)sel(A) + Sel(A)Sel(B)Sel(C)

       Good News, Oracle 9i/10g onwords this issue has been address perfectly !!!
But if you have large set of values then its good to have table type instead of IN LIST as
Table type will allow CBO to rewrite the SQL and use Semi-Nested loop Join for better data
retrieval.
                          How ??? Stay tuned......                                         26
IN Vs EXISTS




Then Who and When ???
      Both the SQLs gives same Explain plan and Elapse time in this case...
 If the main body of your query is highly selective, then an EXISTS clause might be more
    appropriate to semi-join to the target table.
 if the main body of your query is not so selective (over join Predicate) and the subquery (the
    target of the semi-join) is more selective, then an IN clause might be more appropriate.
Good News, This rule is valid only for 8i (or earlier) systems. 9i and later versions it doesn’t matter
much both works same in most of the cases. Still you will have to check for specific cases.
 IN and EXISTS uses Semi – Join technique. A “semi-join” between two tables returns rows
     from the first table where one or more matches are found in the second table.
 If you have to select the data from only one table and no columns from second table, then
     use semi-join (IN or EXISTS ) method instead conventional joins. As semi-join searches
     second table for first occurrence of matching values and stops there.                           27
NOT IN Vs NOT EXISTS

 Handling of NULL values :
 • If a sub query returns NULL values, NOT IN condition evaluates to False and
   returns zero rows, as it could not compare NULL values.
 • NOT EXISTS checks for non existence of the row, so it able to return rows even
   if sub query has NULL values.

 Anti - Join :
 • An “anti-join” between two tables returns rows from the first table where no
   matches are found in the second table.
 • NOT IN and NOT EXISTS uses Anti – Join access path method.
 • Consider NOT IN, if sub query never returns NULL values and whether the
   query might benefit from a merge or hash anti-join.
 • Else use NOT EXISTS.




                                                                                    28
Joins – Access Path Techniques

1.   Nested Loop
2.   Hash Join
3.   Merge Join
4.   SEMI Join
5.   ANTI Join

How Oracle select access path in a conventional join ?
 The nested loops algorithm is desirable when the predicates on the first table
  are very selective and the join columns in the second table are selectively
  indexed.
 The merge and hash join algorithms, are more desirable when predicates are
  not very selective or the join columns in the second table are not selectively
  indexed. And if both the data set are of large size.




                                                                           29
Joins – Nested Loop (old mechanism)

 for r1 in (select rows from table_1 where colx = {value})
 loop
      for r2 in (select rows from table_2 that match current row from table_1)
      loop
             output values from current row of table_1 and current row of table_2
       end loop
 end loop


             T1




 T2

                                                                                    30
Joins – Nested Loop (New mechanism)

1. Mechanism finds the first row in the outer table, traverses the index, and stops in the
   leaf block, picking up just the relevant rowids for the inner table.
2. Repeats this for all subsequent rows in the outer table.
3. When all the target rowids have been found, the engine can sort them and then visit
   the inner table in a single pass, working along the length of the table just once,
   picking the rows in whatever order they happen to appear.
4. optimizer_index_caching is used to adjust the cost calculation for index blocks of the
   inner table in nested loops and for the index blocks used during in-list iterator. It is
   not used in the calculation of costs for simple index unique scans or range scans into
   a single table.




Index Access




                                                                                      31
Joins – Hash Join

1. Build Table : It acquire one data set and convert it into the equivalent of an
   inmemory single-table hash cluster (assuming it have enough memory :
   hash_area_size) using an internal hashing function on the join column(s) to
   generate the hash key.
2. Probe Table : Start to acquire data from the second table, applying the
   same hashing function to the join column(s) as it read each row, and
   checking to see whether it can locate a matching row in the in-memory
   hash cluster.

  Types of Hash Join:
    - Optimal Hash Join
    - Onepass Hash Join
    - Multipass Hash Join




                                                                             32
Joins – Hash Join (Optimal hash join)

                                      (hash_area_size := 1024 = 10% PGA size)




Cost = Cost of acquiring data from the build table + Cost of acquiring data from the probe table
       + Cost of performing the Hashing and Matching                                       33
Joins – Hash Join (Onepass hash join )




                                         34
Joins – Merge Join



              Table 1                          Table 2




                        Merge          Merge
       Sort                                              Sort




                                To next step




                                                                35
Conclusions



     1.   Understand your data
     2.   Data distribution is important
     3.   Think about your parameters
     4.   Choose your Index Rightly
     5.   Help Oracle with the truth

    There are NO Thumb Rules But, They are the different
           options provided by Oracle to tune SQL !!!




                                                           36
References




1. Cost-Based Oracle, Book by : Jonathan Lewis
2. http://docs.oracle.com/cd/B10500_01/server.920/a96524/c08memor.htm
3. http://www.dba-oracle.com/art_otn_cbo.htm
4. http://docs.oracle.com/cd/B28359_01/server.111/b28318/memory.htm
5. http://blogs.oracle.com/optimizer/entry/dynamic_sampling_and_its_impact
   _on_the_optimizer
6. http://orainternals.wordpress.com/2010/05/01/query-transformation-part-
   1/
7. http://www.dbspecialists.com/files/presentations/semijoins.html




                                                                        37
santoshkangane.blogspot.com   38
Cost Based Oracle
Cost Based Oracle

Weitere ähnliche Inhalte

Was ist angesagt?

Memory Management
Memory ManagementMemory Management
Memory ManagementVisakh V
 
RUCK 2017 김성환 R 패키지 메타주성분분석(MetaPCA)
RUCK 2017 김성환 R 패키지 메타주성분분석(MetaPCA)RUCK 2017 김성환 R 패키지 메타주성분분석(MetaPCA)
RUCK 2017 김성환 R 패키지 메타주성분분석(MetaPCA)r-kor
 
SQL Server 2016 Query store
SQL Server 2016 Query storeSQL Server 2016 Query store
SQL Server 2016 Query storeVitaliy Popovych
 
Introduction of Memory Management
Introduction of Memory Management Introduction of Memory Management
Introduction of Memory Management Maitree Patel
 
previous question solve of operating system.
previous question solve of operating system.previous question solve of operating system.
previous question solve of operating system.Ibrahim Khalil Shakik
 
Oracle/SQL For Beginners - DDL | DML | DCL | TCL - Quick Learning
Oracle/SQL For Beginners - DDL | DML | DCL | TCL - Quick LearningOracle/SQL For Beginners - DDL | DML | DCL | TCL - Quick Learning
Oracle/SQL For Beginners - DDL | DML | DCL | TCL - Quick LearningeVideoTuition
 
Introducing ms sql_server
Introducing ms sql_serverIntroducing ms sql_server
Introducing ms sql_serverleetinhf
 
The best ETL questions in a nut shell
The best ETL questions in a nut shellThe best ETL questions in a nut shell
The best ETL questions in a nut shellSrinimf-Slides
 
Random forest using apache mahout
Random forest using apache mahoutRandom forest using apache mahout
Random forest using apache mahoutGaurav Kasliwal
 
View, Store Procedure & Function and Trigger in MySQL - Thaipt
View, Store Procedure & Function and Trigger in MySQL - ThaiptView, Store Procedure & Function and Trigger in MySQL - Thaipt
View, Store Procedure & Function and Trigger in MySQL - ThaiptFramgia Vietnam
 
Chapter 8 : Memory
Chapter 8 : MemoryChapter 8 : Memory
Chapter 8 : MemoryAmin Omi
 
Jan vitek distributedrandomforest_5-2-2013
Jan vitek distributedrandomforest_5-2-2013Jan vitek distributedrandomforest_5-2-2013
Jan vitek distributedrandomforest_5-2-2013Sri Ambati
 
Scaling up Machine Learning Algorithms for Classification
Scaling up Machine Learning Algorithms for ClassificationScaling up Machine Learning Algorithms for Classification
Scaling up Machine Learning Algorithms for Classificationsmatsus
 
Computer hardware | 3c
Computer hardware | 3cComputer hardware | 3c
Computer hardware | 3cCMDLMS
 

Was ist angesagt? (20)

Memory Management
Memory ManagementMemory Management
Memory Management
 
SQL
SQLSQL
SQL
 
RUCK 2017 김성환 R 패키지 메타주성분분석(MetaPCA)
RUCK 2017 김성환 R 패키지 메타주성분분석(MetaPCA)RUCK 2017 김성환 R 패키지 메타주성분분석(MetaPCA)
RUCK 2017 김성환 R 패키지 메타주성분분석(MetaPCA)
 
SQL Server 2016 Query store
SQL Server 2016 Query storeSQL Server 2016 Query store
SQL Server 2016 Query store
 
Introduction of Memory Management
Introduction of Memory Management Introduction of Memory Management
Introduction of Memory Management
 
previous question solve of operating system.
previous question solve of operating system.previous question solve of operating system.
previous question solve of operating system.
 
Oracle/SQL For Beginners - DDL | DML | DCL | TCL - Quick Learning
Oracle/SQL For Beginners - DDL | DML | DCL | TCL - Quick LearningOracle/SQL For Beginners - DDL | DML | DCL | TCL - Quick Learning
Oracle/SQL For Beginners - DDL | DML | DCL | TCL - Quick Learning
 
Oracle 11g SQL Overview
Oracle 11g SQL OverviewOracle 11g SQL Overview
Oracle 11g SQL Overview
 
Introducing ms sql_server
Introducing ms sql_serverIntroducing ms sql_server
Introducing ms sql_server
 
The best ETL questions in a nut shell
The best ETL questions in a nut shellThe best ETL questions in a nut shell
The best ETL questions in a nut shell
 
Memory management
Memory managementMemory management
Memory management
 
Random forest using apache mahout
Random forest using apache mahoutRandom forest using apache mahout
Random forest using apache mahout
 
View, Store Procedure & Function and Trigger in MySQL - Thaipt
View, Store Procedure & Function and Trigger in MySQL - ThaiptView, Store Procedure & Function and Trigger in MySQL - Thaipt
View, Store Procedure & Function and Trigger in MySQL - Thaipt
 
Chapter 8 : Memory
Chapter 8 : MemoryChapter 8 : Memory
Chapter 8 : Memory
 
Jan vitek distributedrandomforest_5-2-2013
Jan vitek distributedrandomforest_5-2-2013Jan vitek distributedrandomforest_5-2-2013
Jan vitek distributedrandomforest_5-2-2013
 
MySQL Views
MySQL ViewsMySQL Views
MySQL Views
 
Scaling up Machine Learning Algorithms for Classification
Scaling up Machine Learning Algorithms for ClassificationScaling up Machine Learning Algorithms for Classification
Scaling up Machine Learning Algorithms for Classification
 
Cell Profiler
Cell ProfilerCell Profiler
Cell Profiler
 
Computer hardware | 3c
Computer hardware | 3cComputer hardware | 3c
Computer hardware | 3c
 
Memory management
Memory managementMemory management
Memory management
 

Ähnlich wie Cost Based Oracle

Cost Based Optimizer - Part 1 of 2
Cost Based Optimizer - Part 1 of 2Cost Based Optimizer - Part 1 of 2
Cost Based Optimizer - Part 1 of 2Mahesh Vallampati
 
Presentación Oracle Database Migración consideraciones 10g/11g/12c
Presentación Oracle Database Migración consideraciones 10g/11g/12cPresentación Oracle Database Migración consideraciones 10g/11g/12c
Presentación Oracle Database Migración consideraciones 10g/11g/12cRonald Francisco Vargas Quesada
 
Overview of query evaluation
Overview of query evaluationOverview of query evaluation
Overview of query evaluationavniS
 
Advanced MySQL Query Optimizations
Advanced MySQL Query OptimizationsAdvanced MySQL Query Optimizations
Advanced MySQL Query OptimizationsDave Stokes
 
Myth busters - performance tuning 102 2008
Myth busters - performance tuning 102 2008Myth busters - performance tuning 102 2008
Myth busters - performance tuning 102 2008paulguerin
 
Deployment Preparedness
Deployment Preparedness Deployment Preparedness
Deployment Preparedness MongoDB
 
Building scalable application with sql server
Building scalable application with sql serverBuilding scalable application with sql server
Building scalable application with sql serverChris Adkin
 
Oracle Query Optimizer - An Introduction
Oracle Query Optimizer - An IntroductionOracle Query Optimizer - An Introduction
Oracle Query Optimizer - An Introductionadryanbub
 
Java Developers, make the database work for you (NLJUG JFall 2010)
Java Developers, make the database work for you (NLJUG JFall 2010)Java Developers, make the database work for you (NLJUG JFall 2010)
Java Developers, make the database work for you (NLJUG JFall 2010)Lucas Jellema
 
Whitepaper: Exadata Consolidation Success Story
Whitepaper: Exadata Consolidation Success StoryWhitepaper: Exadata Consolidation Success Story
Whitepaper: Exadata Consolidation Success StoryKristofferson A
 
Sql server performance tuning
Sql server performance tuningSql server performance tuning
Sql server performance tuningJugal Shah
 
Dremel interactive analysis of web scale datasets
Dremel interactive analysis of web scale datasetsDremel interactive analysis of web scale datasets
Dremel interactive analysis of web scale datasetsCarl Lu
 
PHP UK 2020 Tutorial: MySQL Indexes, Histograms And other ways To Speed Up Yo...
PHP UK 2020 Tutorial: MySQL Indexes, Histograms And other ways To Speed Up Yo...PHP UK 2020 Tutorial: MySQL Indexes, Histograms And other ways To Speed Up Yo...
PHP UK 2020 Tutorial: MySQL Indexes, Histograms And other ways To Speed Up Yo...Dave Stokes
 
Implementing the Databese Server session 02
Implementing the Databese Server session 02Implementing the Databese Server session 02
Implementing the Databese Server session 02Guillermo Julca
 
Chapter 3.pptx Oracle SQL or local Android database setup SQL, SQL-Lite, codi...
Chapter 3.pptx Oracle SQL or local Android database setup SQL, SQL-Lite, codi...Chapter 3.pptx Oracle SQL or local Android database setup SQL, SQL-Lite, codi...
Chapter 3.pptx Oracle SQL or local Android database setup SQL, SQL-Lite, codi...TAISEEREISA
 
PostgreSQL High_Performance_Cheatsheet
PostgreSQL High_Performance_CheatsheetPostgreSQL High_Performance_Cheatsheet
PostgreSQL High_Performance_CheatsheetLucian Oprea
 
Brad McGehee Intepreting Execution Plans Mar09
Brad McGehee Intepreting Execution Plans Mar09Brad McGehee Intepreting Execution Plans Mar09
Brad McGehee Intepreting Execution Plans Mar09guest9d79e073
 

Ähnlich wie Cost Based Oracle (20)

Cost Based Optimizer - Part 1 of 2
Cost Based Optimizer - Part 1 of 2Cost Based Optimizer - Part 1 of 2
Cost Based Optimizer - Part 1 of 2
 
Presentación Oracle Database Migración consideraciones 10g/11g/12c
Presentación Oracle Database Migración consideraciones 10g/11g/12cPresentación Oracle Database Migración consideraciones 10g/11g/12c
Presentación Oracle Database Migración consideraciones 10g/11g/12c
 
Overview of query evaluation
Overview of query evaluationOverview of query evaluation
Overview of query evaluation
 
Advanced MySQL Query Optimizations
Advanced MySQL Query OptimizationsAdvanced MySQL Query Optimizations
Advanced MySQL Query Optimizations
 
Performance Tuning
Performance TuningPerformance Tuning
Performance Tuning
 
Myth busters - performance tuning 102 2008
Myth busters - performance tuning 102 2008Myth busters - performance tuning 102 2008
Myth busters - performance tuning 102 2008
 
Deployment Preparedness
Deployment Preparedness Deployment Preparedness
Deployment Preparedness
 
Building scalable application with sql server
Building scalable application with sql serverBuilding scalable application with sql server
Building scalable application with sql server
 
Oracle Query Optimizer - An Introduction
Oracle Query Optimizer - An IntroductionOracle Query Optimizer - An Introduction
Oracle Query Optimizer - An Introduction
 
Java Developers, make the database work for you (NLJUG JFall 2010)
Java Developers, make the database work for you (NLJUG JFall 2010)Java Developers, make the database work for you (NLJUG JFall 2010)
Java Developers, make the database work for you (NLJUG JFall 2010)
 
01 oracle architecture
01 oracle architecture01 oracle architecture
01 oracle architecture
 
Whitepaper: Exadata Consolidation Success Story
Whitepaper: Exadata Consolidation Success StoryWhitepaper: Exadata Consolidation Success Story
Whitepaper: Exadata Consolidation Success Story
 
Sql server performance tuning
Sql server performance tuningSql server performance tuning
Sql server performance tuning
 
Dremel interactive analysis of web scale datasets
Dremel interactive analysis of web scale datasetsDremel interactive analysis of web scale datasets
Dremel interactive analysis of web scale datasets
 
PHP UK 2020 Tutorial: MySQL Indexes, Histograms And other ways To Speed Up Yo...
PHP UK 2020 Tutorial: MySQL Indexes, Histograms And other ways To Speed Up Yo...PHP UK 2020 Tutorial: MySQL Indexes, Histograms And other ways To Speed Up Yo...
PHP UK 2020 Tutorial: MySQL Indexes, Histograms And other ways To Speed Up Yo...
 
Implementing the Databese Server session 02
Implementing the Databese Server session 02Implementing the Databese Server session 02
Implementing the Databese Server session 02
 
DB
DBDB
DB
 
Chapter 3.pptx Oracle SQL or local Android database setup SQL, SQL-Lite, codi...
Chapter 3.pptx Oracle SQL or local Android database setup SQL, SQL-Lite, codi...Chapter 3.pptx Oracle SQL or local Android database setup SQL, SQL-Lite, codi...
Chapter 3.pptx Oracle SQL or local Android database setup SQL, SQL-Lite, codi...
 
PostgreSQL High_Performance_Cheatsheet
PostgreSQL High_Performance_CheatsheetPostgreSQL High_Performance_Cheatsheet
PostgreSQL High_Performance_Cheatsheet
 
Brad McGehee Intepreting Execution Plans Mar09
Brad McGehee Intepreting Execution Plans Mar09Brad McGehee Intepreting Execution Plans Mar09
Brad McGehee Intepreting Execution Plans Mar09
 

Cost Based Oracle

  • 1. Santosh Kangane – Oracle DBA santoshkangane.wordpress.com santoshkangane.blogspot.in www.linkedin.com/pub/santosh-kangane/1b/78b/6b 1
  • 2. Highlights  Background of CBO  Oracle Database Memory Structures  Table Scans  CPU Costing Model  Index and Clustering Factor  Dynamic Sampling and Histogram  Query transformation  Join Methodologies There are NO thumb Rules in Oracle. Different Versions of Oracle and data Patterns Drives the SQL performance !!!! This presentation is just to introduce as to How CBO workouts the SQL plans That probably will help you to find what is suitable for given SQL. How you write a SQL, it matters !!!! 2
  • 3. Cost Based Optimization : Evolution • Traditional : Simple counting of read requests • System statistics (1) : Accounting for size and time of read requests • System statistics (2) : Accounting for size and time of read requests and CPU costs • System statistics (3) : Accounting for size and time of read requests and CPU costs and caching. 3
  • 5. Three different layers of operational complexity • First : The execution plan tells you what the optimizer thinks is going to happen at run time, and produces a cost based on this model. • Second : The execution engine starts up and executes the model dictated by the optimizer- but the actual mechanism is not always identical to the model (alternatively, the model is not a good description of what actually happens). • Finally: there are cases where the resources required to execute the model vary dramatically with the way in which the incoming data happens to be distributed. In other words, the optimizer’s execution plan may not be exactly the run- time execution path, and the speed of the run-time execution path may be affected by an unlucky choice of data. 5
  • 6. When CBO makes errors • Some inappropriate assumptions are built into the cost model. • The relevant statistics about the data distribution are available, but misleading. • The relevant statistics about the data distribution are not available. • The performance characteristics of the hardware are not known. • The current workload is not known. • There are bugs in the code. 6
  • 8. Table Scans 1. db_file_multiblock_read_count :  Multiple block read count allowed in single IO operation.  Is always set to the maximum allowed by the operating system by default.  Oracle Calculates the IO cost based on the MBRC and system statistics.  When Oracle executes the tablescan, how many blocks does it try to read in a multiblock read? Is it the value of MBRCor something else? Answer: Oracle still tries to use the actual value for db_file_multiblock_read_count—scaled up or down if we are reading from a tablespace with a nondefault block size.  If workload statistics are not gathered then system uses non workload stats. 8
  • 9. Table Scans 2. Full Table Scan:  When performing a full table scan, it reads the blocks of the table into buffers and puts them on the LRU end (instead of the MRU end) of the LRU list.  This is because a fully scanned table usually is needed only briefly, so the blocks should be moved out quickly to leave more frequently used blocks in the cache.  You can control this default behavior on a table-by-table basis.  To specify that blocks of the table are to be placed at the MRU end of the list during a full table scan, use the CACHE clause when creating or altering a table or cluster.  You can specify this behavior for small lookup tables (Keep pool) or large static historical tables(Recycle pool) to avoid I/O on subsequent accesses of the table.  Transactional table MUST not be added to CACHE. 9
  • 10. Table Scans 3. Parallel Execution: (/*+ PARALLEL */ or ALTER TABLE <<T1>> PARALLEL) I. The user session or shadow process takes on the role of a coordinator, often called the query coordinator and necessary number of parallel slave processes. II. The SQL statement is executed as a sequence of operations. While the parallel slaves are executing, the query coordinator performs any portion of the work that cannot be executed in parallel. III. Finally, the query coordinator returns results to the user.  Parallel scans use direct path reads to bypass the data buffer and read blocks directly into local (PGA) memory.  A parallel query will first issue a segment checkpoint to get all dirty blocks status for the segment written to disk before it reads.  This could lead to a performance problem in rare cases that mixed a large data buffer, a busy OLTP system, and parallel execution for reports. 10
  • 12. What is Cost ? According to the CPU costing model: Cost = ( #SRds * sreadtim + #MRds * mreadtim + #CPUCycles / cpuspeed ) / sreadtim where, #SRDs - number of single block reads #MRDs - number of multi block reads #CPUCycles - number of CPU Cycles sreadtim - single block read time mreadtim - multi block read time cpuspeed - CPU cycles per second Translated, The cost is the time spent on single-block reads, plus the time spent on multi block reads, plus the CPU time required, all divided by the time it takes to do a single- block read. 12
  • 13. Statistics Optimizer statistics are a collection of data that describe more details about the database and the objects in the database. Optimizer statistics includes : Table statistics Number of rows Number of blocks USER_TABLES / DBA_TABLES Average row length Column statistics Number of distinct values (NDV) in column USER_TAB_COLUMNS / Number of nulls in column DBA_TAB_COLUMNS Data distribution (histogram) Average Column length Index statistics Number of leaf blocks USER_INDEXES Levels Clustering factor System statistics I/O performance and utilization DBA_TAB_STATISTICS CPU performance and utilization 13
  • 14. Cardinality (Selectivity) In an audience of 1,200 people. How many of them do you think were born in December? And What if 120 of them don’t remember their birth date ? Optimizer is thinking .... • Base selectivity = 1/12 (from density or from 1/num_distinct) user_tab_col_statistics.num_nulls = 0 user_tab_col_statistics. • num_nulls = 120 & num_rows = 1200 user_tab_col_statistics.num_distinct = 12 user_tab_col_statistics.n /13? • Adjusted selectivity = Base selectivity * (num_rows - num_nulls) user_tab_histograms.low_value = 1 user_tab_histograms.low num_rows user_tab_histograms.high_value = 12 user_tab_histograms.hig • Adjusted selectivity = (1/12) * ((1200 - 120)/1200) = 0.075 user_tables.num_rows = 1,200 user_tables.num_rows = • Adjusted cardinality = Adjusted selectivity * num_rows • So, user_tab_col_statistics.Density = 1/12 Adjusted cardinality = 0.075 * 1200 = 90 So, user_tab_col_statist Cardinality = 100 Cardinality = 90 Cardinality = num_rows / num_distinct (If no histogram is prepared ) Cardinality = num_rows * density (If histogram is prepared ) 14
  • 15. Cardinality (Selectivity) Basic formulae of Selectivity :  The selectivity of (predicate1 AND predicate2) = Selectivity of (predicate1) * Selectivity of (predicate2).  The selectivity of (predicate1 OR predicate2) = selectivity of (predicate1) + selectivity of (predicate2) minus selectivity of (predicate1 AND predicate2) ... otherwise, you’ve counted the overlap twice.  The selectivity of (NOT predicate1) = 1 – selectivity of (predicate1)  Range Selectivity = “required range” divided by “total available range” Cardinality :  Cardinality = Selectivity * num_rows 15
  • 16. Index Cost = blevel + ceiling(leaf_blocks * effective index selectivity) + ceiling(clustering_factor * effective table selectivity) Translated, Cost to reach to, the Level of index node from root in Balanced B-Tree + number of leaf blocks to be walk through to get rowids + cost to access table. B+ Tree Index :  To Scan the index segment oracle uses Binary tree travels algorithm.  The depth of B+ Tree varies from 1 to 4. Mostly its 2 or 3 and Max 4 for larger table index 16
  • 17. Index: Clustering Factor Clustering factor resolution logic does not consider the Cache hit, Hence some time gives unrealistic values. 17
  • 18. Index: Clustering Factor SELECT /*+ cursor_sharing_exact dynamic_sampling(0) no_monitoring no_expand index (t,"AWBMST_DPUDATE") noparallel_index(t,"AWBMST_DPUDATE") */ Sys_op_countchg(substrb(t.rowid,1,15),&m_history) as clf FROM AWBMST T; WHERE DPUDATE IS NOT NULL; • &m_history represent the number of block visited most recently. This value should be freelists value of table or 16 in case of ASSM tablespace. • use dbms_stats.get_index_stats and dbms_stats.set_index_stats to set the correct value of Clustering factor. • This should be used only for critical indexes where you find default method of oracle giving you a wrong statistics and it not recommended to apply for all index always. 18
  • 19. Index: Selection 1. Range-based predicate (e.g., col1 between 1 and 3) would reduce the benefit of later columns in the index. Any predicates based on columns appearing after the earliest range-based predicate would be ignored when calculating the effective index selectivity—although they would still be used in the effective table selectivity—and this could leave Oracle with an unreasonably high figure for the cost of that index. Columns that usually appeared with a range-based predicate toward the end of the index definition. 2. For improving the compressibility of an index, Put the least selective (most repetitive) columns first. 3. Re-arranging the column sequence in the index changes the clustering_factor and Index Selectivity... 4. Appearance of column sequence in there WHERE clause does not affect the index selectivity. 5. If Index in unique in nature then do create them as UK index instead of normal index, other wise Optimizer has to refer Histogram and figure out the index uniqueness. That changes optimizers access path option. 19
  • 20. Dynamic Sampling How and when will DS be use? During the compilation of a SQL statement, the optimizer decides whether to use DS or not by considering whether the available statistics are sufficient to generate a good execution plan. If, 1. Available table statistics are not enough. 2. When the statement contains a complex predicate expression and extended statistics are not available. OPTIMIZER_DYNAMIC_SAMPLING  Parameter defines the number of blacks to read for Sampling.  It can have value from 0 to 10. Default is 2.  More the value if DS parameter, more time it takes to compile the SQL Statement. 20
  • 21. Histogram Histograms feature in Oracle helps optimizer to determine how data is skewed (distributed) with in the column Advantage of Histogram : 1. Histograms are useful for Oracle optimizer to choose the right access method in a table. 2. It is also useful for optimizer to decide the correct table join order. When we join multiple tables, histogram helps to minimize the intermediate result set. Since the smaller size of the intermediate result set will improve the performance. 21
  • 22. Query transformation 1. Join elimination (JE) : A technique in which one or more tables can be eliminated from the execution plan without altering functional behaviour. 22
  • 23. Query transformation 1. Join elimination (JE) : Example 2 : Elimination by Constraints or reference, Following table T1 and T2 has FK constraints over T1.N1 and T2.N2 and SQL is selecting data only from T2 table. So, No need to check if the Key is exists in T1 and join can be eliminated safely… 23
  • 24. Query transformation 2. Subquery Unnesting :  Subqueries can be unnested in to a join. Oracle executes a sub query  Subquery is unnested in to a view and then joined to other row sources. once for each distinct value  In this listing, a correlated subquery is moved in to a view VW_SQ_1,Hashes from driving table and unnested and then joined using Hash Join technique. subsequent rows it will it. For use the same results from Hash table instead of re- executing sub query. 24
  • 25. Query transformation : Transitive Closure 25
  • 26. IN Vs EXISTS , NOT IN Vs NOT EXISTS What to use ? Why ?  Depends ! Why there is Myth ...... Up to oracle 8i optimizer has suffer through the cardinality approximation issue. select * from AUDIENCE where month_no in ( 6, 7, 8); Actual problem :  Internally, the optimizer will convert a predicate in to OR clauses.  The error that 8i suffers from is that after splitting the list into separate predicates, it applies the standard algorithm for multiple disjuncts (the technical term for OR’ed predicates) and Fails to process it correctly.  sel(A or B or C) = sel(A) + sel(B) + sel(C) – Sel(A)sel(B) – Sel(B)sel(C) – sel(C)sel(A) + Sel(A)Sel(B)Sel(C) Good News, Oracle 9i/10g onwords this issue has been address perfectly !!! But if you have large set of values then its good to have table type instead of IN LIST as Table type will allow CBO to rewrite the SQL and use Semi-Nested loop Join for better data retrieval. How ??? Stay tuned...... 26
  • 27. IN Vs EXISTS Then Who and When ??? Both the SQLs gives same Explain plan and Elapse time in this case...  If the main body of your query is highly selective, then an EXISTS clause might be more appropriate to semi-join to the target table.  if the main body of your query is not so selective (over join Predicate) and the subquery (the target of the semi-join) is more selective, then an IN clause might be more appropriate. Good News, This rule is valid only for 8i (or earlier) systems. 9i and later versions it doesn’t matter much both works same in most of the cases. Still you will have to check for specific cases.  IN and EXISTS uses Semi – Join technique. A “semi-join” between two tables returns rows from the first table where one or more matches are found in the second table.  If you have to select the data from only one table and no columns from second table, then use semi-join (IN or EXISTS ) method instead conventional joins. As semi-join searches second table for first occurrence of matching values and stops there. 27
  • 28. NOT IN Vs NOT EXISTS  Handling of NULL values : • If a sub query returns NULL values, NOT IN condition evaluates to False and returns zero rows, as it could not compare NULL values. • NOT EXISTS checks for non existence of the row, so it able to return rows even if sub query has NULL values.  Anti - Join : • An “anti-join” between two tables returns rows from the first table where no matches are found in the second table. • NOT IN and NOT EXISTS uses Anti – Join access path method. • Consider NOT IN, if sub query never returns NULL values and whether the query might benefit from a merge or hash anti-join. • Else use NOT EXISTS. 28
  • 29. Joins – Access Path Techniques 1. Nested Loop 2. Hash Join 3. Merge Join 4. SEMI Join 5. ANTI Join How Oracle select access path in a conventional join ?  The nested loops algorithm is desirable when the predicates on the first table are very selective and the join columns in the second table are selectively indexed.  The merge and hash join algorithms, are more desirable when predicates are not very selective or the join columns in the second table are not selectively indexed. And if both the data set are of large size. 29
  • 30. Joins – Nested Loop (old mechanism) for r1 in (select rows from table_1 where colx = {value}) loop for r2 in (select rows from table_2 that match current row from table_1) loop output values from current row of table_1 and current row of table_2 end loop end loop T1 T2 30
  • 31. Joins – Nested Loop (New mechanism) 1. Mechanism finds the first row in the outer table, traverses the index, and stops in the leaf block, picking up just the relevant rowids for the inner table. 2. Repeats this for all subsequent rows in the outer table. 3. When all the target rowids have been found, the engine can sort them and then visit the inner table in a single pass, working along the length of the table just once, picking the rows in whatever order they happen to appear. 4. optimizer_index_caching is used to adjust the cost calculation for index blocks of the inner table in nested loops and for the index blocks used during in-list iterator. It is not used in the calculation of costs for simple index unique scans or range scans into a single table. Index Access 31
  • 32. Joins – Hash Join 1. Build Table : It acquire one data set and convert it into the equivalent of an inmemory single-table hash cluster (assuming it have enough memory : hash_area_size) using an internal hashing function on the join column(s) to generate the hash key. 2. Probe Table : Start to acquire data from the second table, applying the same hashing function to the join column(s) as it read each row, and checking to see whether it can locate a matching row in the in-memory hash cluster. Types of Hash Join: - Optimal Hash Join - Onepass Hash Join - Multipass Hash Join 32
  • 33. Joins – Hash Join (Optimal hash join) (hash_area_size := 1024 = 10% PGA size) Cost = Cost of acquiring data from the build table + Cost of acquiring data from the probe table + Cost of performing the Hashing and Matching 33
  • 34. Joins – Hash Join (Onepass hash join ) 34
  • 35. Joins – Merge Join Table 1 Table 2 Merge Merge Sort Sort To next step 35
  • 36. Conclusions 1. Understand your data 2. Data distribution is important 3. Think about your parameters 4. Choose your Index Rightly 5. Help Oracle with the truth There are NO Thumb Rules But, They are the different options provided by Oracle to tune SQL !!! 36
  • 37. References 1. Cost-Based Oracle, Book by : Jonathan Lewis 2. http://docs.oracle.com/cd/B10500_01/server.920/a96524/c08memor.htm 3. http://www.dba-oracle.com/art_otn_cbo.htm 4. http://docs.oracle.com/cd/B28359_01/server.111/b28318/memory.htm 5. http://blogs.oracle.com/optimizer/entry/dynamic_sampling_and_its_impact _on_the_optimizer 6. http://orainternals.wordpress.com/2010/05/01/query-transformation-part- 1/ 7. http://www.dbspecialists.com/files/presentations/semijoins.html 37

Hinweis der Redaktion

  1. Parallel scans use direct path reads to bypass the data buffer and read blocks directly into local (PGA) memory.This helps to reduce the impact on the data buffer (but might mean you want a small Oracle buffer and a largefile system buffer in some special cases).But if the block in the data buffer is dirty (newer than the block on disk), then you might think a directread would not see the latest version, and may therefore get the wrong result. To solve this problem, a parallelquery will first issue a segment checkpoint to get all dirty blocks for the segment written to disk before itreads. (The cost is exposed through statistic DBWR parallel query checkpoint buffers written in10g, and otherwise indicated by enqueues of type TC.)This could lead to a performance problem in rare cases that mixed a large data buffer, a busy OLTPsystem, and parallel execution for reports—the work done by the database writer (DBWR) walking the checkpointqueue to find the relevant dirty blocks could have an undesirable impact on the OLTP activity.
  2. Which means the cost is the total predicted execution time for the statement, expressedin units of the single-block read time.
  3. Optimizer statistics are a collection of data that describe more details about the database and the objects in the database. These statistics are used by the query optimizer to choose the best execution plan for each SQL statement. As a general rule, the figures for bytes in execution plans are derived from the avg_col_len columns ofuser_tab_columns.special case of select * from table, the optimizer seems to use the avg_row_len fromuser_tables as the row size if the statistics have been generated by dbms_stats
  4. Page 64 to 66
  5. As far as possible try to mention more relational predicates in Where clause, By that optimizer will exactly know the which selectivity to workout and what degree of join to use.All Constraints defined on Table will add to your Join/Where Clause predicate. Example : if there is predicate Coln &gt; 90. Oracle has to rewrite this as Coln &gt; 90 AND Coln IS NOT NULL. If this column is never going to have NULL values then do add NOT null constraint on column, optimizer will not add extra predicate as its pretty sure that it will never gone encounter any NULL value.Same goes for Indexes if they are unique do create them as Unique, else optimizer will have to use Histogram and figure it out.
  6. select (1/12 + 1/12 + 1/12 - 1/12*1/12 - 1/12*1/12 - 1/12*1/12 + 1/12*1/12*1/12) * 1200 from dual= 275.6944 but that should be 300 right ????
  7. hash_area_size = 0.1 * pga_aggregate_targetBuild Table : It acquire one data set and convert it into the equivalent of an inmemorysingle-table hash cluster (assuming it have enough memory : hash_area_size) using an internal hashing function on the join column(s) to generate the hash key. The number of buckets in the hash table always seems to be an even power of two (common values for small hash joins are 1,024 or 4,096 buckets)Probe Table : Start to acquire data from the second table, applying the same hashing function to the join column(s) as it read each row, and checking to see whether it can locate a matching row in the in-memory hash cluster.If there are no rows in the relevant bucket, Oracle can immediately discard the row from the probe table. If there are some rows in the relevant bucket, Oracle does an exact check on the join column(s) to see if there is a proper match.
  8. 1. The first data set is acquired and scattered into the hash table. As a bucket is used, thecorresponding bit in the bitmap is set.2. As the memory fills up, clusters are dumped to disk. The dumping is done using a cautiousstrategy that tries to keep as many complete partitions in memory for as long as possible.When the build table is exhausted, it is possible that some partitions will still be heldcompletely in memory, while the rest have only a few (but at least one) clusters left inmemory. It may be that one partition has just a few clusters, in memory and the resthave only one each. Whatever the outcome, Oracle will have a detailed map of wherethe data from each partition can be found. Moreover, whenever a hash bucket has beenused (whether the relevant data items are in memory or on disk), the corresponding bitis set in the bitmap—which is always held completely in memory. At this point, Oracletidies up the hash table, trying to get as many complete partitions into memory as possibleand dumping any excess from other partitions to disk. As part of the rebuild,Oracle will reserve some clusters (a minimum of one per partition) for processing theprobe table.3. Once the hash table has been tidied up, Oracle starts to acquire rows from the seconddata set, applying the same hash function to the join column(s) of each row. The resultof the hash function is used to check the relevant bit in the bitmap (a detail I chose toignore in my description of the first example).4. Oracle takes one of several possible actions, depending on the result of the test.4a)Event: The bit is clear (0).Action: There is no match, and the row is discarded.4b)Event: The bit is set (1), and the relevant hash bucket is in a partition that is inmemory.Action: Check the hash bucket—if the probe row matches the build row, report it;otherwise discard it.4c)Event: The bit is set (1), but the relevant hash bucket is in a partition that is on disk.Action: Put the probe row to one side. It may match a build row that is on disk, but itwould be too expensive to reread the relevant build partition at this point to check it.Oracle has a complete map showing where all the data is and how many rowsthere are in each partition, so it picks a matched pair of dumped partitions (one build, oneprobe), and performs a hash join between them. As an extra optimization detail, Oracle canchoose to swap the roles of the two partitions at this point because it knows exactly how muchdata there is in each partition, and there may be some benefit in using whichever is the smallerone to build the new in-memory hash.So, in the case of a high-volume hash join, the hash table can spill to disk, with the probetable following it. The cost of the join ought to allow for the I/O performed in dumping theexcess to disk and reloading it for the second phase of the join. This type of hash join is recorded asa onepassworkarea execution because the probe dataset is reread from disk just once.
  9. Page 64 to 66
  10. Page 64 to 66