11.07.2015 Views

Oracle Database 11 g - Online Public Access Catalog

Oracle Database 11 g - Online Public Access Catalog

Oracle Database 11 g - Online Public Access Catalog

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 4 ■ PERFORMANCE MANAGEMENT 197Argument Name Type In/Out Default?----------------- --------------- ---------- ------------WORKLOAD_NAME VARCHAR2 INSTS_NAME VARCHAR2 INIMPORT_MODE VARCHAR2 IN DEFAULTThe workload_name attribute refers to the source SQL workload, and the sts_name attributepoints to the target STS into which you’ll be importing the SQL Workload object. The import_modeattribute can take the value append, new, or replace and determines the handling of the data inthe target STS upon the import of the SQL Workload object. Here’s an example showing how touse the copy_sqlwkload_to_sts procedure:SQL> exec dbms_advisor.copy_sqlwkld_to_sts ('workload_1','sts_1', 'new');<strong>Oracle</strong> will create a new STS if the STS you specify doesn’t exist.Optimizer and Statistics CollectionEnhancements<strong>Oracle</strong> <strong>Database</strong> <strong>11</strong>g provides several enhancements in the optimizer statistics collection area.One of the important new features is the extended statistics feature, which lets the optimizercollect statistics on correlated columns in a table, thus providing better selectivity estimates.You can also collect expression statistics on expression functions. The statistics that you cancollect for column groups and expressions are called extended statistics. The other importantenhancement is the new concept of private and public statistics, with private statistics beingstatistics that you’ve collected but not yet published for use by the cost optimizer. We’ll coverthe interesting new features in the following sections.Multicolumn StatisticsOne of the key things the cost optimizer considers during its execution plan evaluation is theselectivity (or cardinality) of the column in the where clause of a query. The number of differentvalues in a column determines the column’s selectivity. When a column in a table has manydifferent values, that column has good selectivity, and a column with many values that are thesame has poor selectivity. If you build an index on a column with good selectivity, the optimizeris able to access the necessary row faster than it will access a row with lower selectivity.If a column has poor selectivity—for example, a certain value that’s the same in more than95 percent of the table’s rows—it’s likely that the cost optimizer will opt for a full table scan,regardless of the existence of an index on that column. If, on the other hand, there are severaldistinct column values such that no column value is in more than 1 or 2 percent of the table’srows, the optimizer is likely to choose the index for accessing the rows when you issue a querythat contains a where clause containing this column.Several queries, however, contain multiple columns from a table, each with a differentdegree of selectivity. Some of these columns are related, but the optimizer doesn’t know aboutthe nature of these relationships. For example, in a table containing products and their prices,some products have higher prices than others. However, the cost optimizer, which bases its

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!