This action might not be possible to undo. Are you sure you want to continue?
By: Divya CONTENTS Introduction Rule Based Optimizer Cost Based Optimizer Cost Based Optimizer and Database Statistics ANALYZE STATEMENT DBMS_UTILITY DBMS_STATS Scheduling Stats Transfering Stats Behaviour Adjustments Optimizer_index_cost_adj Optimizer_index_caching Optimizer_max_permutations Db_file_multiblock_read_count Parallel_automatic_tuning Hash_area_size Sort_area_size size Update Statistics Update Statistics with BRCONNECT Internal rules for Update Statistics Steps for running Optimizer Script 2 .
To set the optimizer goal. you can specify CHOOSE (for cost-based) or RULE (for rule-based) for the OPTIMIZER_MODE parameter in your database’s initialization parameter file.COST BASED OPTIMIZER INTRODUCTION Oracle's cost-based SQL optimizer is a sophisticated tool for tuning database performance. If you are attempting to tune an application. The better you understand the execution path oracle uses to perform the query. you should evaluate the application architecture and operating environment to determine if they are appropriate for your user’s requirements before examining the SQL. tuning the SQL in that example may yield little in the way of performance improvement. If you query the database. 3 . Oracle Corporation has invested millions of dollars in making the cost-based SQL optimizer (CBO) one of the most sophisticated tools ever created. The job of the CBO is to always choose the most optimal execution plan for any SQL statement. The Oracle optimizer has two primary modes of operation: cost based or rule based. An application that performs a large number of queries across a slow network just to display a data entry screen will be perceived as slow even if the database activity portion is fast. the better you will be able to manipulate and tune the query. you should be aware of the operations Oracle performed to retrieve and manipulate the data.
The CBO checks several possible execution plans and selects the one with the lowest cost.This method is used if internal statistics are present. and is found primarily in applications developed and tuned earlier versions of oracle. It evaluates possible execution paths and rates the alternative execution paths based on a series of syntactical rules. the RBO is seldom used by new applications. where cost relates to system resources.This method is used if the server has no internal statistics relating to the objects referenced by the statement. This decision can be made using one of two methods: Rule Based Optimizer (RBO) .Whenever a valid SQL statement is processed Oracle has to decide how to retrieve the necessary data. 4 . Cost Based Optimizer (CBO) . This method is no longer favoured by Oracle and will be desupported in future releases.
To improve performance. Since the CBO supports changes in data volumes and data distribution. the CBO selects values for the missing statistics-and it may decide to perform an inappropriate execution path. If you use the CBO. you should use either the RBO or the CBO consistently throughout your database. 5 . you should favour its use. the CBO evaluates the cost of the available execution path that has the lowest relative cost. The generated statistics include the number of rows in a table and the number if distinct keys in an index. If a query references tables that have been analyzed and tables that have not been analyzed. you need to make sure that you analyze the data frequently enough for the statistics to accurately reflect the data within your database. Based on the statistics.You can use the analyze command and the DBMS_STAT package to generate statistics about the objects in your database.
or the amount of data in the database changes the statistics will no longer represent the real state of the database so the CBO decision process may be seriously impaired.Cost Based Optimizer (CBO) and Database Statistics If new objects are created. The mechanisms and issues relating to maintenance of internal statistics are explained below: ANALYZE STATEMENT DBMS_UTILITY DBMS_STATS Scheduling Stats Transfering Stats Analyze Statement 6 .
EXEC DBMS_UTILITY. ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 100 ROWS.analyze_schema(‘SCOTT’. estimate_percent => 15). 7 . EXEC DBMS_UTILITY.’ESTIMATE’.analyze_schema(‘SCOTT’.analyze_database(‘ESTIMATE’.analyze_database(‘ESTIMATE’. you can gather adequate statistics by analyzing 10 to 20 percent of an object. you can query the statistics-related columns of the data dictionary views to see the values generated.analyze_schema(‘SCOTT’.The ANALYZE statement can be used to gather statistics for a specific table.’ESTIMATE’. ANALYZE INDEX employees_pk COMPUTE STATISTICS. When analyzing you can scan the full object (via the compute statistics clause) or part of the object (via the estimate statistics clause). DBMS_UTILITY The DBMS_UTILITY package can be used to gather statistics for a whole schema or database.analyze_database(‘COMPUTE’).’COMPUTE’). EXEC DBMS_UTILITY. EXEC DBMS_UTILITY. index or cluster. estimate_percent => 15). or estimated based on a specific number of rows. ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 15 PERCENT. EXEC DBMS_UTILITY. estimate_rows => 100). The statistics can be computed exactly. Both methods follow the same format as the analyze statement: EXEC DBMS_UTILITY. estimate_rows => 100). Once you have analyzed an object. or a percentage of rows: ANALYZE TABLE employees COMPUTE STATISTICS. In genera.
Oracle list a number of benefits to using it including parallel execution. Once again.gather_table_stats(‘SCOTT’.gather_index_stats(‘SCOTT’. It is a replacement of the analyze command. EXEC DBMS_STATS.delete_table_stats(‘SCOTT’. EXEC DBMS_STATS. This package also gives you the ability to delete statistics: EXEC DBMS_STATS. ‘EMPLOYEES_PK’. Scheduling Stats Scheduling the gathering of statistics using DBMS_Job is the easiest way to make sure they are always up to date: SET SERVEROUTPUT ON DECLARE l_job NUMBER.delete_database_stats. EXEC DBMS_STATS. estimate_percent => 15). ‘EMPLOYEES’.delete_schema_stats(‘SCOTT’). estimate_percent => 15).gather_table_stats(‘SCOTT’. EXEC DBMS_STATS.gather_database_stats(estimate_percent => 15).DBMS_STATS The DBMS_STATS package was introduced in Oracle 8i and is Oracles preferred method of gathering object statistics. long term storage of statistics and transfer of statistics between servers. EXEC DBMS_STATS. ‘EMPLOYEES’).gather_database_stats.delete_index_stats(‘SCOTT’. EXEC DBMS_STATS. ‘EMPLOYEES_PK’). it follows a similar format to the other methods: EXEC DBMS_STATS. EXEC DBMS_STATS. 8 . estimate_percent => 15). ‘EMPLOYEES’). EXEC DBMS_STATS. EXEC DBMS_STATS. ‘EMPLOYEES_PK’). EXEC DBMS_STATS.gather_index_stats(‘SCOTT’.gather_schema_stats(‘SCOTT’). and is the recommended method as of Oracle 9i.gather_schema_stats(‘SCOTT’.
BEGIN DBMS_JOB. ‘BEGIN DBMS_STATS. Where ‘X’ is the number of the job to be removed.) and the stats imported into the data dictionary as follows: 9 .gather_schema_stats(“SCOTT”). EXEC DBMS_JOB.’STATS_TABLE’).create_stat_table(‘DBASCHEMA’. / The above code sets up a job to gather statistics for SCOTT for the current time every day.put_line(‘Job: ‘ || l_job). SYSDATE.remove(X). COMMIT. COMMIT. STATS_TABLE. which is owned by DBASCHEMA: SQL> EXEC DBMS_STATS. This table can then be transfered to another server using your preferred method (Export/Import.N ULL.’STATS_TABLE’. You can list the current jobs on the server using the DBS_JOBS and DBA_JOBS_RUNNING views.submit(l_job.export_schema_stats(‘APPSCHEMA’. DBMS_OUTPUT.’DBASCHEMA’). In the following examples the statistics for the APPSCHEMA user are collected into a new table. END.’. ‘SYSDATE + 1’). SQL> EXEC DBMS_STATS. Transfering Status It is possible to transfer statistics between servers allowing consistent execution plans between servers with varying amounts of data. SQLPlus Copy etc. First the statistics must be collected into a statistics table. END.
import_schema_stats(‘APPSCHEMA’. SQL> EXEC DBMS_STATS. when the system is 90 percent utilized. the best execution plan at 4:00 A. For example. Hence the Oracle professional must adjust the CBO behavior periodically. the CBO is not psychic. which is where the DBA comes in. Despite the name "Oracle".drop_stat_table(‘DBASCHEMA’.’DBASCHEMA’). all affect the "best" execution plan for a SQL statement. the speed of the disks and the load on the CPUs. a priori.M. and Oracle can never know. the exact load on the Oracle system. The types of SQL statements. Most Oracle professionals make these behavior adjustments using the instance-wide CBO behavior parameters such as optimizer_index_cost_adj and optimizer_index_caching. when 16 CPUs are idle may be quite different from the same query at 3:00 P. Behavior Adjustments There are some things that the CBO cannot detect.’STATS_TABLE’.SQL> EXEC DBMS_STATS.’STATS_TABLE’). 10 .N ULL.M.
possible join orders for the tables. Oracle must evaluate 6-factorial. Oracle does not recommend changing the default values for many of these CBO settings because the changes can affect the execution plans for thousands of SQL statements. The setting for optimizer_index_caching affects the CBO's decision to use an index for a table join (nested loops). or 720. Optimizer_index_caching This is the parameter that tells Oracle how much of your index is likely to be in the RAM data buffer cache. Here are some of the major adjustable parameters that influence the behavior of the CBO: Optimizer_index_cost_adj Optimizer_index_caching Optimizer_max_permutations Db_file_multiblock_read_count Parallel_automatic_tuning Hash_area_size Sort_area_size size Optimizer_index_cost_adj This parameter alters the costing algorithm for access paths involving indexes. or to favor a full-table scan. Optimizer_max_permutations This controls the maximum number of table join permutations allowed before the CBO is forced to pick a table join order. the cheaper the cost of index access.However. The smaller the value. Db_file_multiblock_read_count 11 . For a six-way table join.
By running update statistics regularly. the CBO might generate inappropriate access paths (such as using the wrong index). so improving database performance. Sort_area_size size (if not using pga_aggregate_target) The sort_area_size influences the CBO when deciding whether to perform an index access or a sort of the result set. Hash_area_size (if not using pga_aggregate_target) The setting for hash_area_size parameter governs the propensity of the CBO to favor hash joins over nested loop and sort merge table joins. full-table scans are parallelized. Parallel_automatic_tuning When set "on".When set to a high value. and be friendlier to full-table scans. resulting in poor performance. the CBO recognizes that scattered (multi-block) reads may be less expensive than sequential reads. the more likely that a sort will be performed in RAM and the more likely that the CBO will favor a sort over pre-sorted index retrieval. you make sure that the database statistics are up-to-date. This makes the CBO friendlier to full-table scans. If the statistics are out-of-date. the CBO will give a higher cost to index access. UPDATE STATISTICS The Oracle cost-based optimizer (CBO) uses the statistics to optimize access paths when retrieving data for queries. The higher the value for sort_area_size. You can update statistics using one of the following methods: Using DBA Planning Calendar in the Computing Center Management System (CCMS) Using BRCONNECT 12 . Because parallel full-table scans are very fast.
see SAP Note 424243. If statistics are available for a table. For more information. Info cube tables for the SAP Business Information Warehouse (SAP BW) BRCONNECT performs update statistics using a two-step approach: Checks each table to see if the statistics are out-of-date If required. updates the statistics on the table immediately after the check Internal rules for update statistics This algorithm is used by BRCONNECT to update statistics. By running update statistics regularly. except where partitioned tables are explicitly excluded by setting the active flag in the DBSTATC table to I. the database system uses the cost-based optimizer. you make sure that the database statistics are up-to-date. Update Statistics with BRCONNECT You can use this BRCONNECT function to update the statistics on the Oracle database for the cost-based optimizer. so improving database performance. 13 . weekly). From Release 4. It is recommended to use this approach because you can easily schedule update statistics to run automatically at specified intervals (for example.0. Otherwise. it uses the rule-based optimizer.The DBA Planning Calendar uses the BRCONNECT commands. the CBO is a standard part of the SAP System. BRCONNECT supports update statistics for the following: Partitioned tables.
000 <= 100.000 Analysis method Sample size C E E P30 P10 14 . as follows: If the table has the MONITORING attribute set. including tables that have the ACTIVE flag in the DBSTATC table set to A or P. Otherwise. To do this. because they negatively affect database performance. 3. BRCONNECT checks statistics for the remaining tables in the working set. The method used is: • Method and sample defined for the table in the DBSTATC table (has highest priority) • Method and sample from the options -m|-method or -s|sample of -f stats -method (takes priority) or the stats_method and stats_sample_size parameters • Default method and sample (has lowest priority) The following table describes the default method Number of rows in table Rows 10. If the working set contains pool. cluster or other tables that have the ACTIVE flag in the DBSTATC table set to N or R.000 < 100. BRCONNECT determines the working set of tables and indexes to be checked and updated. deleted.1. it uses: Options -t|-table and -e|-exclude.1 onwards).000.000 < 1. BRCONNECT immediately deletes the statistics for these tables. and updated rows from the DBA_TAB_MODIFICATIONS table (this is available from Oracle 8. BRCONNECT reads the number of inserted.000 <= Rows Rows < 10. as described in -f stats (these options take priority) Stats_table and stats_exclude parameters 2. BRCONNECT uses the standard method (see table below) to update statistics by using the unique index.
EH. "E P10" means that BRCONNECT takes an estimated sample using 10% of rows. histograms are created. For example.000 E E P3 P1 10. For the CH. but the value defined in -f stats -change or the stats_change_threshold parameter is used if specified.000 <= Rows Analysis method C means computes the statistics exactly. and EX methods. EI and EX methods.000. 4. For the CI. 5. CX.000 <= Rows < 10. BRCONNECT immediately updates statistics after checking for the following tables: Tables where either of the conditions in the previous step is true Tables from the DBSTATC table with either of the following values: ACTIVE field U ACTIVE field R or N and USE field A (relevant for the application monitor) 15 .000.000. CX. the structure of indexes is validated in addition to collecting statistics.1. Analysis method E means estimate the statistics using the sample size specified. BRCONNECT uses the number of new rows for each table in the working set. as derived in the previous step. to see if either of the following is true: Number of new rows is greater than or equal to number of old rows * (100 + threshold) / 100 Number of new rows is less than or equal to number of old rows * 100 / (100 + threshold) The standard threshold is 50.
or CX. Steps for running the Optimizer Script Steps to be followed when running the database optimizer and check script: 1.6. BRCONNECT immediately deletes the statistics that it created in this procedure for tables with the ACTIVE flag set to N or R in the DBSTATC table. Now run the script brconnect -u / -c -f stats -t all 16 . BRCONNECT writes the results of update statistics to the DBSTATTORA table and also. to the DBSTAIHORA table. EX. for tables with the DBSTATC history flag or usage type A. CI. to the DBSTATHORA table. For tables with update statistics using methods EI. 7. 8. Login to the system (database instance) at OS level with the user sidadm 2. for tables with the DBSTATC history flag or usage type A. BRCONNECT validates the structure of all associated indexes and writes the results to the DBSTATIORA table and also.
It will take around 30 minutes to get complete. 3. Optimizer script has completed successfully 4. Running the check script brconnect -u / -f check 17 .
5. It will prompt for asking c to continue and s to stop 6. It has been successfully completed with warnings 18 .
This action might not be possible to undo. Are you sure you want to continue?