Académique Documents
Professionnel Documents
Culture Documents
Why Tune ?
• To improve response time
• To improve batch throughput
• To ensure scalability
• To reduce system load
• To avoid hardware upgrades
Tuning Techniques
• Re-wording the SQL
• Giving Oracle explicit instructions called Hints
• Creating or changing indexes or clusters
• Changing the table structure
Types of SQL Statements
• Data Definition Language (DDL), used to define the
database structure or schema: CREATE, DROP, ALTER,
TRUNCATE
• Data Manipulation Language (DML), used for
managing data within schema objects: SELECT, INSERT,
UPDATE, DELETE, MERGE/UPSERT
• Data Control Language (DCL), used to control access
to data stored in a database: GRANT, REVOKE, DENY
• Transaction Control Language (TCL), used to manage
the changes made by DML statements: COMMIT,
SAVEPOINT, ROLLBACK
Query Operations
• Subqueries: nested subquery (in the WHERE clause),
inline views (in the FROM clause), in the SELECT clause,
correlated subquery
• Joins: inner, outer, self, equi-joins
• Set: UNION, UNION ALL, MINUS, INTERSECT
• Aggregations: AVG, COUNT, MAX, MIN, SUM
SQL Processing
Create Cursor Allocate memory for cursor
Bind Variables
with SQL
Execute DML statement or
Execute SQL
prepare query to
Close Cursor
and discard
What is Parsing?
• It is the process of preparing the SQL statement for
execution
• Process:
» Check that the SQL statement syntactically valid
» Check that the statement is semantically valid
» Check security
» Determine an execution plan
Improving Parse Speed
• The parse phase for statements can be decreased
by efficient use of aliasing. If an alias is not present,
the engine must resolve which tables own the
specified columns. The following is an example:
• Rule based
– Based on predefined set of precedence rules (rigid
rules) to figure out which path it will use to access the
database.
– Does not take into account the volume of data
• Cost based
– Takes into account statistical information relating to
volume and distribution of data within tables and
indexes (it uses database information such as table
size, number of rows, key spread, and so forth,
rather than rigid rules).
Goals of Query Optimization (1 of 2)
• RULE
– This specifies that the optimizer is to take the rule based
approach to optimization
• CHOOSE
– This specifies that the optimizer is to use the cost based
approach if any of the table in the SQL statement has
been analyzed.
– If no tables have been analyzed, then use the rule based
approach.
Goals of Query Optimization (2 of 2)
• ALL_ROWS
– This explicitly chooses the cost-based approach to
optimize a statement block with a goal of best
throughput (that is, minimum total resource)
• FIRST_ROWS
– This 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).
Statistics Used for the Cost-Based Approach
• Syntax:
ANALYZE TABLE <table name> COMPUTE/ESTIMATE
STATISTICS
• The statistics are visible through these data dictionary
views:
– USER_TABLES, ALL_TABLES, and DBA_TABLES
– USER_TAB_COLUMNS, ALL_TAB_COLUMNS, and
DBA_TAB_COLUMNS
How Oracle Optimizes SQL Statements
SQL> explain plan for select empno, ename from emp order by empno,
ename;
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=26
INDEX FULL SCAN EMP_INDEX [ANALYZED]
Index Lookup Methods (4 of 5)
• Index Fast Full Scan
empno is PK and index name is pk_emp
SELECT /*+INDEX_FFS(EMP PK_EMP)*/ EMPNO FROM EMP;
Scans all the block in the index. Rows are not returned in
sorted order.
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
INDEX FAST FULL SCAN PK_EMP [ANALYZED]
Index Lookup Methods (5 of 5)
• Rowid
This is the quickest access method available Oracle simply
retrieves the block specified and extracts the rows it is
interested in.
SQL> explain plan for select * from dept where rowid = ':x';
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID DEPT [ANALYZED]
Common Execute Steps (1 of 5)
• For example:
SELECT /*+ USE_HASH (s i) */ DISTINCT s.srvr_id
FROM servers s, serv_inst i
WHERE s.srvr_id = i.srvr_id;
Some HINTS (8 of 8)
• USE_MERGE
The merge hint requires that both inputs be sorted on the merge
columns, which are defined by the equality (WHERE) clauses of the join
predicate. Because each input is sorted, the merge join operator gets a
row from each input and compares them. For example, for inner join
operations, the rows are returned if they are equal. If they are not equal,
whichever row has the lower value is discarded and another row is
obtained from that input. This process repeats until all rows have been
processed. The syntax for this hint is:
/*+ USE_MERGE(table_name) */
• For example:
SELECT /*+ USE_MERGE (s i) */ DISTINCT s.srvr_id
FROM servers s, serv_inst i
WHERE s.srvr_id = i.srvr_id;
Full Table Scans vs Index Lookups
• Avoid use of NOT (!=, <>, etc.) in the WHERE clause, use BETWEEN, '>='
'<=', or '>' '<'.
• Use column names in the ORDER BY clause.
• Use ORDER BY only when absolutely necessary and minimize the result
set by using additional constraints in the WHERE clause.
Optimizing DML (3 of 4)