B.Sc.

SE TY

Database Administration Using Oracle 10g

Chap 6 Performance and Application Tuning

6.1 Managing Optimizer Statistics
The optimizer statistics-gathering function in Oracle 10g has been enhanced to become more automated. If the database is created using the Database Creation Assistant (DBCA), a batch job is automatically created and started at database creation to collect statistics on database objects with missing or outdated statistics. To account for CPU-intensive or CPU-only operations, the optimizer now takes into account both CPU time and I/O load when creating an execution plan; in addition, the optimizer can use dynamic sampling to generate additional statistics at runtime to further fine-tune the execution plan. To further enhance the performance of CPUbound queries on fixed tables and data dictionary tables, the DBMS_STATS package has been enhanced to gather statistics on these tables. Monitoring tables for DML activity has been simplified by using a single initialization parameter to control the collection of statistics instead of collecting statistics on individual tables. 6.1.1 Gathering Automatic Statistics When a new database is created, the job GATHER_STATS_JOB is automatically created and scheduled. This job gathers statistics on a regular basis for database objects whose statistics are either missing or stale. It calls the procedure DBMS_STATS.GATHER_DATABASE_STATS_JOB_ PROC , which operates similarly to the procedure DBMS_STATS.GATHER_DATABASE_STATS with the GATHER AUTO option available in previous releases of Oracle. The GATHER_DATABASE_STATS_JOB_PROC procedure provides additional benefits beyond automating the collection process: it processes objects that most need updated statistics first. 6.1.2 Leveraging Enhanced Query Optimization Oracles enhanced cost model now takes into account CPU-intensive or CPU-only operations, in contrast to versions of Oracle before Oracle 9i that only considered I/O costs. In Oracle 10g, the default cost model considers both CPU and I/O. Also, the table PLAN_TABLE has a new column, TIME, that estimates the elapsed time, in seconds, for the query as estimated by the new cost model. The new initialization parameter OPTIMIZER_DYNAMIC_SAMPLING controls how the enhanced query optimizer can deal more effectively with objects at runtime that have no statistics, have outdated statistics, or are very volatile

1 College of Computer Science & Information Technology, Latur

Prepared by Arun S Shinde

B.Sc. SE TY

Database Administration Using Oracle 10g

Setting OPTIMIZER_DYNAMIC_SAMPLING to a number other than zero determines how much dynamic sampling will occur when the execution plan is generated. Dynamic sampling is a method of statistics collection, controlled by the initialization Parameter OPTIMZER_DYNAMIC_SAMPLING, that produces compile-time statistics for query objects that have outdated or missing statistics. The range of this parameter is from 0 to 10, with a default value of 2. For queries against very volatile objects, it is wise to not explicitly compute statistics and let dynamic sampling drive the generation of the execution plan. Another initialization parameter that is changed as part of the enhanced query optimizer is PGA_AGGREGATE_TARGET. Automatic PGA memory management is enabled by default unless PGA_AGGREGATE_TARGET is set to 0 or the parameter WORKAREA_SIZE_POLICY is set to MANUAL. By default, PGA_AGGREGATE_TARGET is 20 percent of the SGA size. 6.1.3 Gathering Data Dictionary Statistics As of Oracle 10 g , it is beneficial to collect statistics on data dictionary tables, both fixed and real tables. A fixed table is a table that exists in memory only that typically contains information about instance or memory structures and is presented in the form of a table. Since fixed tables reside in memory only, they have no I/O cost associated with them; now that the cost-based optimizer takes into account CPU cost, a more robust execution plan can be generated when taking into account statistics on fixed tables. In contrast, a real table is stored in a datafile, persists between instance restarts and incurs I/O overhead unless it is specifically cached in memory. Gathering statistics on real data dictionary tables provides the same benefit as statistics gathered on user or application tables: better execution plans. 6.1.4 Getting Statistics on Real Data Dictionary Tables To collect statistics on data dictionary tables, use the procedure DBMS_STATS.GATHER_SCHEMA_ STATS or DBMS_STATS.GATHER_DATABASE_STATS with the parameter GATHER_SYS set to TRUE. SQL> exec dbms_stats.gather_database_stats (-estimate_percent => 5, -gather_sys => true); PL/SQL procedure successfully completed. Alternatively, a new procedure called DBMS_STATS.GATHER_DICTIONARY_STATS is convenient shorthand for gathering statistics on only the SYS ,SYSTEM , and other RDBMS component tables.

2 College of Computer Science & Information Technology, Latur

Prepared by Arun S Shinde

B.Sc. SE TY

Database Administration Using Oracle 10g

SQL> exec dbms_stats.gather_dictionary_stats; PL/SQL procedure successfully completed. Either the SYSDBA privilege or the new system privilege ANALYZE ANY DICTIONARY is required to analyze data dictionary or fixed tables. Getting Statistics on Fixed Data Dictionary Tables If we use DBMS_STATS.GATHER_DATABASE_STATS, we can set the parameter GATHER_FIXED, which defaults to FALSE, to TRUE to gather statistics for fixed tables in addition to any other statistics collected. If the need arises to collect statistics on an individual fixed table, we can use the DBMS_STATS package as with any traditional table. SQL> exec dbms_stats.gather_table_stats( -ownname => 'SYS', -tabname => 'x$le'); PL/SQL procedure successfully completed. Only fixed table statistics can be gathered with the procedure GATHER_FIXED_OBJECT_STATS.

SQL> exec dbms_stats.gather_fixed_object_stats; PL/SQL procedure successfully completed. Gathering statistics on fixed tables is typically required only once during a typical system workload; in other words, unless a new application has been installed, a monthly data warehouse load has been performed, or the database software has been patched or upgraded, it is not necessary to regather fixed table statistics. 6.1.5 Exploring Other Changes to DBMS_STATS In addition to the new procedures in DBMS_STATS, new values for the parameters GRANULARITY and DEGREE are available in all the GATHER_*_STATS procedures. The new values for GRANULARITY are AUTO (the default value) and GLOBAL AND PARTITION. Using AUTO will determine the granularity value based on the partitioning and subpartitioning type: If the subpartition type is LIST, the global, partition, and subpartition statistics are generated; otherwise, only global and partition statistics are generated. Using GLOBAL AND PARTITION gathers only global and partition statistics even if subpartitions exist. DEGREE can now have a value of AUTO_DEGREE. Depending on the number of CPUs and the size of the object, Oracle sets DEGREE to either 1 or DEFAULT_DEGREE. The default value of DEGREE is NULL, which directs the DBMS_STATS procedures to use the default value specified for DEGREE when the table or index was created or altered. The default values for these parameters should be sufficient in most cases.

3 College of Computer Science & Information Technology, Latur

Prepared by Arun S Shinde

B.Sc. SE TY 6.2 Monitoring DML Tables

Database Administration Using Oracle 10g

In previous versions of Oracle, we would use the command ALTER TABLE MONITORING to capture the amount of DML activity against one or more tables and subsequently use DBMS_STATS to gather statistics on these tables under the assumption that the statistics have become stale. Starting with Oracle 10g, you can no longer monitor individual tables and must use the initialization parameter STATISTICS_LEVEL. The values for STATISTICS_LEVEL are as follows: BASIC TYPICAL ALL A value of BASIC disables monitoring, and as a result the Automatic Workload Repository (AWR) snapshots are disabled in addition to the Automatic Database Diagnostic Monitor (ADDM). Using BASIC may be advisable only in a DSS environment where the queries rarely vary day to day, the system has been thoroughly tuned already, the size of the database changes infrequently, the database is static, and the fastest possible execution speed of all queries is the top priority. Using a value of TYPICAL will collect most statistics required for database selfmanagement and delivers the best overall performance; specifying ALL collects additional statistics such as timed operating system statistics and plan execution statistics, but incurs a significant amount of overhead above and beyond the TYPICAL level that may have a noticeable impact on user transactions. Using a value of TYPICAL will collect most statistics required for database selfmanagement and delivers the best overall performance; specifying ALL collects additional statistics such as timed operating system statistics and plan execution statistics, but incurs a significant amount of overhead above and beyond the TYPICAL level that may have a noticeable impact on user transactions.

4 College of Computer Science & Information Technology, Latur

Prepared by Arun S Shinde