Oracle SQL Notes

Introduction Logical Structure Memory Structure Execution Plan Gathering Statistics

Optimizer
Materialized Views Result Cache Oracle Hints SQL Best Practices

Introduction

A database is a collection of data on disk in one or more files on a database server that collects and maintains related information. The database consists of various physical and logical structures, the table being the most important logical structure in the database. A table consists of rows and columns containing related data. At a minimum, a database must have at least tables to store useful information.

Overview-Logical Structure
Block: A database block is the smallest unit of storage in the Oracle database : Extents The extent is the next level of logical grouping in the database. An extent consists of one or more database blocks. When you enlarge a database object, the space added to the object is allocated as an extent. Segments A Segment is nothing but collection of extents. For example, a table is a segment, Index is a segment etc. Tablespace: a TableSpace is nothing but Datafiles . Datafiles consist of OS Blocks. From the Application point of View OS Blocks are Datafiles

Memory Structure Automatic Shared Memory Management

library cache, data dictionary cache
state of the database and the instance, which the background processes need to access

SGA Shared pool Fixed SGA Database buffer cache Large pool Redo log buffer
Stores large memory allocations

Java pool

Holds copies of data blocks read from data files.

Keeps the state of Java program execution

1-3

Contains the information necessary to reconstruct changes made to the database by DML operations. The log writer then records this information in the redo logs.

Execution Plan

An execution plan (sometimes also called a query execution plan) is the sequence of operations that Oracle performs when it reads or writes data resulting from a SQL statement. The execution plan defines or maps out how Oracle finds (retrieves) or writes the data. This may include decisions on whether or not to use indexes, the order that nested statements or sub-queries will be executed, and other factors. Where there are multiple indexes, the execution plan determines which one(s) are used.

Using Execution Plans There are several uses for viewing execution plans:
Determining the current execution plan
Identifying the effect of creating an index on a table Finding cursors containing a certain access path (for example, full table scan or index range scan) Identifying indexes that are, or are not, selected by the optimizer Determining whether the optimizer selects the particular execution plan (for example, nested loops join) expected by the developer

You can use an execution plan to make decisions such as:

Dropping or creating indexes Generating statistics on the database objects Modifying initialization parameter values Migrating the application or the database to a new release

Gathering Statistics
Identify table, index, and column statistics

Table Statistics
Oracle collects the following statistics for a table. Number of rows (NUM_ROWS) Number of data blocks below the high water mark (that is, the number of data blocks that have been formatted to receive data, regardless whether they currently contain data or are empty) (BLOCKS)

Number of data blocks allocated to the table that have never been used (EMPTY_BLOCKS)
Average available free space in each data block in bytes (AVG_SPACE) Number of chained rows. (CHAIN_COUNT) Average row length, including the row's overhead, in bytes (AVG_ROW_LEN)

The Views which are usually Checked are USER_TABLES, ALL_TABLES, and DBA_TABLES

Index Statistics
Oracle collects the following statistics for an index. Depth of the index from its root block to its leaf blocks (BLEVEL) Number of leaf blocks (LEAF_BLOCKS) Number of distinct index values (DISTINCT_KEYS) Average number of leaf blocks per index value (AVG_LEAF_BLOCKS_PER_KEY) Average number of data blocks per index value (for an index on a table) (AVG_DATA_BLOCKS_PER_KEY) Clustering factor (how well ordered the rows are about the indexed values) (CLUSTERING_FACTOR) The Views which are usually Checked are USER_INDEXES, ALL_INDEXES, and DBA_INDEXES

 Statistics gathering
DBMS_STATS package
SQL> exec dbms_stats.set_table_prefs('SH', 'SALES', 'INCREMENTAL', 'TRUE'); SQL> exec dbms_stats.gather_table_stats( Owner=>'SH', Tabname=>'SALES', Partname=>'23_MAY_2008', Granularity=>'AUTO');

Optimizer
Query Optimizer
Parser
The parser performs two functions: Syntax analysis: checks SQL statements for correct syntax Semantic analysis: checks, for example, that current database objects and object attributes referenced are correct

Optimizer
The optimizer uses internal rules or costing methods to determine the most efficient way of producing the result of the query. The output from the optimizer is a plan that describes an optimum method of execution. The Oracle server provides two methods of optimization: cost-based optimizer (CBO) and rule-based optimizer (RBO).

Row Source Generator

The row source generator receives the optimal plan from the optimizer. It outputs the execution plan for the SQL statement. The execution plan is a collection of row sources structured in the form of a tree. Each row source returns a set of rows for that step.

SQL Execution Engine

The SQL execution engine is the component that operates on the execution plan associated with a SQL statement. It then produces the results of the query. Each row source produced by the row source generator is executed by the SQL execution engine.

Views
Views are Virtual Tables. It is a query . It does not take any memory in the database. When the table is dropped the views on it are not accessible ,but they become active once the table is recreated. Purpose
1.
2.

To restrict access of data because the view can display selective columns from table/tables
To present different views of the same data.

Materialized Views
A materialized view: Is a precomputed set of results Has its own data segment and offers:
Space management options Use of its own indexes One materialized view can be used to satisfy multiple queries. Less disk space is needed. Less time is needed for maintenance Is not recommended because it consumes too much disk space Improves one query's performance

14 - 11

If Materialized Views Are Not Used

SELECT c.cust_id, SUM(amount_sold) FROM sales s, customers c WHERE s.cust_id = c.cust_id GROUP BY c.cust_id;

CREATE TABLE cust_sales_sum AS SELECT c.cust_id, SUM(amount_sold) AS amount FROM sales s, customers c WHERE s.cust_id = c.cust_id GROUP BY c.cust_id;

SELECT * FROM cust_sales_sum;

14 - 12

Benefits of Using Materialized Views

CREATE MATERIALIZED VIEW cust_sales_mv ENABLE QUERY REWRITE AS SELECT c.cust_id, SUM(amount_sold) AS amount FROM sales s, customers c WHERE s.cust_id = c.cust_id GROUP BY c.cust_id; SELECT c.cust_id, SUM(amount_sold) FROM sales s, customers c WHERE s.cust_id = c.cust_id GROUP BY c.cust_id;
Execution Plan ---------------------------------------------------------0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 )
1 0 MAT_VIEW REWRITE ACCESS (FULL) OF 'CUST_SALES_MV' (MAT_VIEW REWRITE) (Cost=6 )

14 - 13

Benefits of Using Materialized Views With materialized views, end users no longer must be aware of the summaries that have been defined. You can create one or more materialized views that are the equivalent of summary tables. The advantage provided by creating a materialized view instead of a table is that a materialized view not only materializes the result of a query into a database table, but also generates information used by the query rewrite engine to automatically rewrite the SQL query to use the summary tables. Furthermore, a materialized view optionally offers another important possibility: refreshing data automatically. The slide shows that using materialized views is transparent to the user. If your application must execute the same SQL query as in the previous slide, all you need to do is create the materialized view called cust_sales_mv.

Then, whenever the application executes the SQL query, the Oracle Server automatically rewrites it to use the materialized view instead.
Compared to the time that is required by the summary table approach, the query response time is the same. The primary difference is that the application need not be rewritten. The rewrite phase is automatically handled by the system. In addition, the SQL statement that defines the materialized view does not need to match the SQL statement of the query itself.

Oracle Tuning Tools

Oracle Autotrace
The autotrace provides instantaneous feedback including the returned rows, execution plan, and statistics. The user doesnt need to be concerned about trace file locations and formatting since the output is displayed instantly on the screen. This is very important data that can be used to tune the SQL statement. Oracle autotrace supports the following options:
-

autotrace on Enables all options. autotrace on explain Displays returned rows and the explain plan. autotrace on statistics Displays returned rows and statistics. autotrace trace explain Displays the execution plan for a select statement without actually executing it. "set autotrace trace explain autotrace traceonly Displays execution plan and statistics without displaying the returned rows. This option should be used when a large result set is expected.

Oracle autotrace is so easy to use that it should be the first tracing utility used for most SQL performance tuning issues.

Result Cache
Result Cache is a new feature in Oracle 11g and it does exactly what its name implies, it caches the results of queries and puts it into a slice of the shared pool. If you have a query that is executed often and reads data that rarely changes, this feature can increase performance significantly. When the query executes, Oracle will first look in the result cache to see if a previous result for this query is cached. If so, it will retrieve those results instead of reading all the blocks and creating the results again. The initial execution will run in the normal time but subsequent executions will seem to be nearly instantaneous. An example query that makes good use of the result cache would be something similar to below. In this case, the ORDER_HISTORY table contains very static data that will not change often if at all.

When this query(SELECT /*+ result_cache */ state, SUM(order_total)

FROM order_history
WHERE order_date BETWEEN TO_DATE('20090101','YYYYMMDD') AND TO_DATE('20090331','YYYYMMDD') GROUP BY state; ) executes on my database, here are the statistics: Elapsed: 00:00:12.04 Consistent Gets: 31907 Physical Reads: 31897 The execution plan for this query:

Each time this query executes it is required to read a lot of data (2.9 million rows) to calculate the total sales by state for the 1st quarter of last year even if that data does not change

Elapsed: 00:00:14.85 Consistent Gets: 31907 Physical Reads: 31897 Elapsed: 00:00:00.06 Consistent Gets: 0 Physical Reads: 0 Elapsed: 00:00:00.04 Consistent Gets: 0 Physical Reads: 0

Oracle Hints
HINTS are nothing but the comments used in a SQL statement to pass instructions to the Oracle optimizer. The optimizer uses these hints as suggestions for choosing an execution plan for the statement. A statement block can have only one comment containing hints, and that comment must follow the SELECT, UPDATE, INSERT, or DELETE keyword.. /*+ ALL_ROWS */ Explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption) /*+ CHOOSE */ Causes the optimizer to choose between the rule-based approach and the costbased approach for a SQL statement based on the presence of statistics for the tables accessed by the statement /*+ FIRST_ROWS */ Explicitly chooses the cost-based approach to optimize a statement block with a goal of best response time (minimum resource usage to return first row). It will also force the optimizer to make use of index, if available. /*+ FULL(table) */ Explicitly chooses a full table scan for the specified table /*+ INDEX(table index) */ Explicitly chooses an index scan for the specified table

Hints
for Optimization Approaches and Goals ALL_ROWS
The ALL_ROWS hint instructs the optimizer to optimize a statement block with a goal of best throughputthat is, minimum total resource consumption.

FIRST_ROWS_(n)
The FIRST_ROWS/FIRST_ROWS_<n> hint instructs the optimizer to optimize a statement block with a goal of best response time for first n rows.

for Join Operations USE_NL

The USE_NL hint instructs the optimizer to join each specified table to another row source with a nested loops join, using the specified table as the inner table.

USE_MERGE
The USE_MERGE hint instructs the optimizer to join each specified table with another row source using a sort-merge join

USE_HASH
The USE_HASH hint instructs the optimizer to join each specified table with another row source using a hash join

Hints
for Access Paths FULL
The FULL hint instructs the optimizer to perform a full table scan for the specified table.

INDEX
The INDEX hint instructs the optimizer to use a specific index.

for Join Orders LEADING

The LEADING hint instructs the optimizer to perform Nested Loop join using the specified table as leading table.

ORDERED
The ORDERED hint instructs Oracle to join tables in the order in which they appear in the FROM clause. Oracle recommends that you use the LEADING hint, which is more versatile than the ORDERED hint

for Parallel Execution PARALLEL

The PARALLEL hint instructs the optimizer to use the specified number of concurrent servers for a parallel operation. The hint applies to the SELECT, INSERT, MERGE, UPDATE, and DELETE portions of a statement, as well as to the table scan portion

SQL Best Practices

Use uniform coding standards across the application Avoid data type mismatch for indexed columns. Avoid functions on indexed columns. (Function Based Indexes) Ensure where clause has indexed columns in same order when using a composite index. Move conditions from having clause to where clause. Use joins instead of nested selects, whenever possible. Replace Not IN by Not EXISTS or OUTER JOIN. Replace != by Union of < and > Use bulk inserts when inserting large number of records Use BULK COLLECT clause when fetching large number of records

Q&A

Thank You!!