Professional Documents
Culture Documents
http://santoshkangane.blogspot.in/
2011. Santosh Kangane
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 !!!!
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.
Query Execution
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 optimizers execution plan may not be exactly the runtime execution path, and the speed of the run-time execution path may be affected by an unlucky choice of data.
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_countscaled 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.
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.
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.
Costing Model
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 singleblock read.
Statistics
Optimizer statistics are a collection of data that describe more details about the database and the objects in the database.
Column statistics
Number of distinct values (NDV) in column Number of nulls in column Data distribution (histogram) Average Column length
Index statistics
Number of leaf blocks Levels Clustering factor
System statistics
I/O performance and utilization CPU performance and utilization
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 dont 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 /13? user_tab_col_statistics.num_distinct = 12 user_tab_col_statistics.n 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 So, user_tab_col_statist Adjusted cardinality = 0.075 * 1200 = 90
Cardinality = 100 Cardinality = 90
Cardinality = num_rows / num_distinct (If no histogram is prepared ) Cardinality = num_rows * density (If histogram is prepared )
Cardinality (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, youve counted the overlap twice. The selectivity of (NOT predicate1) = 1 selectivity of (predicate1) Range Selectivity = required range divided by total available range
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
Clustering factor resolution logic does not consider the Cache hit, Hence some time gives unrealistic values.
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 selectivityalthough they would still be used in the effective table selectivityand 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. For improving the compressibility of an index, Put the least selective (most repetitive) columns first. Re-arranging the column sequence in the index changes the clustering_factor and Index Selectivity... Appearance of column sequence in there WHERE clause does not affect the index selectivity. 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.
2.
3. 4. 5.
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.
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.
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.
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 it. For unnested and then joined using Hash Join technique. subsequent rows it will
use the same results from Hash table instead of reexecuting sub query.
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 and the subquery (the target of the semijoin) 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 doesnt 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.
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.
T1
T2
Index Access
Cost = Cost of acquiring data from the build table + Cost of acquiring data from the probe table + Cost of performing the Hashing and Matching
Table 1
Table 2
Merge
Merge
Sort
Sort
To next step
Conclusions
1. 2. 3. 4. 5.
Understand your data Data distribution is important Think about your parameters Choose your Index Rightly Help Oracle with the truth
There are NO Thumb Rules But, They are the different options provided by Oracle to tune SQL !!!
References
1. 2. 3. 4. 5.
Cost-Based Oracle, Book by : Jonathan Lewis http://docs.oracle.com/cd/B10500_01/server.920/a96524/c08memor.htm http://www.dba-oracle.com/art_otn_cbo.htm http://docs.oracle.com/cd/B28359_01/server.111/b28318/memory.htm http://blogs.oracle.com/optimizer/entry/dynamic_sampling_and_its_impact _on_the_optimizer 6. http://orainternals.wordpress.com/2010/05/01/query-transformation-part1/ 7. http://www.dbspecialists.com/files/presentations/semijoins.html
santoshkangane.blogspot.com