Oracle Performance Tuning

SAURABH MEHTA
Date: 1-August-2011
Contact :
[email protected]
Discussion Objectives
Day1:
Basics of Performance Tuning
Understanding oracle Optimizer
Tools for performance Tuning
Q&A

Day2:
Identifying performance bottlenecks
How to Approach Performance Issue?
Writing SQL for performance
Understanding Analytic Functions
Q&A

Day3:
Understanding Materialized Views
Understanding Partitions
Understanding Hints
Q&A
Basics of Performance Tuning
 Performance??

Performance is exactly Performance is ‘poor’

what the user perceives when the user’s
it to be. No more, no perception does not
less. match their expectation.

Performance Tuning is a search for “lost time”

End User Metric : FAST or SLOW
 What Effects Performance
Hardware
> I/O
> Memory
> Network
> CPU
Operating System
Oracle Server parameter settings
Database Design
Application

SQL statements
 Performance Tuning Roles

Business analyst 1. Tune business function.

Designer 2. Tune data design.

3. Tune process design.

Application developer 4. Tune SQL statements.

5. Tune physical structure.

Database administrator 6. Tune memory allocation.

7. Tune I/O.
8. Tune memory contention.

9. Tune operating system.

Operating system administrator
10. Networking issues
Network administrator
 Why Does SQL Need Tuning?

> Optimizer limitations

> Many Ways to write a query
> Failure to use advanced
features/Analytic Functions
> Ad-hoc queries
> Poor logical and physical database
design
> Inadequate database maintenance
> Logical Database Structure
> How SQL Statement work in general
> How Oracle executes SQL
> Database changes over time
 How Does Oracle Process SQL?
Choose,
Check syntax + First_Rows,All_R
semantics ows

Generate plan
description
Execute the
plan

Transform plan
into “executable”
 How Does Oracle Process SQL?
[1] Syntactic - checks the syntax of the query

[2] Semantic- checks that all objects exist and are accessible

[3] View Merging - rewrites query as join on base tables as opposed to

using views

[4] Statement Transformation - rewrites query transforming complex constructs to

simpler ones (e.g. subquery unnesting, in/or transformation)

[5] Optimization- determines the optimal access path for the

query to take.
[6] QEP Generation
[7] QEP Execution

There is no substitute for thorough understanding of Oracle operation

Understanding oracle Optimizer
 Optimizer

• Optimizer determines the most efficient way

to execute a SQL statement after
considering many factors related to the
objects referenced and the conditions
specified in the query.

• The output from the optimizer is a plan that

describes an optimum method of execution.
 How Oracle Optimizer Work?

Internal rewrite Plan 1 Does it try every

possible way to
& generation of Plan 2 rewrite your SQL?
SQL multiple
Plan 3 Cost
execution plans estimation
Plan 4

Plan 1 cost=1000
How accurate is
Plan 2 cost=3000 the cost estimation?
Plan 3 cost=4000
Plan 4 cost= 500 Execution
 Limitations Of Optimizer

> Limited SQL rewrite

> Resource limitation
> Cost estimation is only an estimation
> Problems too complex for optimizer
Tools for performance Tuning
Tools for diagnosing Performance Issue

• EXPLAIN PLAN
• SQL trace and TKPROF
• SQL*Plus autotrace feature
• SQL Advisor
 Explain Plan
•Tool that describes the algorithm the database will use to run a SQL statement.
• With Oracle, there are a number of ways of running Explain Plan.
Assumption: You have access to PLAN_TABLE
• Option 1: SQL*PLUS EXPLAIN
This is the low-tech method for those with no access to a nice GUI tool. This is a two
step process:
Add the following line BEFORE your SQL statement
EXPLAIN PLAN SET STATEMENT_ID = ‘S314000011’ FOR
SELECT * FROM emp;

• HOW TO VIEW PLAN

SET LINESIZE 130
SET PAGESIZE 0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

• Option2: SQL*Plus AUTOTRACE

The is the easy low-tech method. In SQL*Plus, type:
SET AUTOTRACE TRACEONLY EXP
Now, every SQL you run will generate and display a plan.
 Query Plan
SELECT *
FROM ACCOUNT A, BRANCH B, TELLER T
WHERE A.BRANCH_ID = B.BRANCH_ID
AND B.BRANCH_ID = T.BRANCH_ID

SELECT STATEMENT
MERGE JOIN
SORT JOIN
NESTED LOOPS
TABLE ACCESS FULL TELLER
TABLE ACCESS BY ROWID BRANCH
INDEX UNIQUE SCAN IBRANCH
SORT JOIN
TABLE ACCESS FULL ACCOUNT
• SQL row source execution starts from the TOP RIGHTMOST INDENTED operation.
• Next stages in plan execution use row sources from previous operations
 Reading Query Plan
Sorted rows from step 6,7 are then
RESULT merged together

Sort records got from the

MERGE-JOIN row source, Cannot return
any rows before the sort is
Fetch the first batch
complete.
of rows from source 1
and then probe row
source 2 for each row
returned from source 6 7
1 FULL table scan scans all rows in
SORT-JOIN SORT-JOIN the table.

4 5
NESTED LOOP Table Access ACCOUNT (Full)

Table data is accessed by rowids.

3 2
Table Access TELLER(Full) Table Access BRANCH (ROWID)

1
FULL table scan scans all rows in
the table.
Index Unique-Scan IBRANCH
Data is accessed by looking up key values in
an index and returning rowids.
 SQL Trace & TKPROF
SQL TRACE is the main method for collecting SQL Execution information in Oracle, it
collects a wide range of information and statistics that can be used to tune SQL
operations.

Trace file generated can be found under “user_dump_dest”

Trace file is barely human-readable.

The SQL Trace facility can be enabled/disabled for an individual session or at the
instance level.
Enabling SQL tracing for an entire instance
> SQL_TRACE = TRUE (INIT.ORA)

Enabling SQL trace for your current session.

> ALTER SESSION SET SQLTRACE = ‘FALSE’ / ‘TRUE’
> EXECUTE DBMS_SESSION.SET_SQL_TRACE(TRUE)

Enabling SQL trace for another session.

− DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(SID,SERIAL#,TRUE|FALSE, BINDS=>true,WAITS=>true)
 SQL Trace & TKPROF
SQL trace generates the following statistics for each statement:

- Parse, execute, and fetch counts

- CPU and elapsed times

- Physical reads and logical reads

- Number of rows processed

- Misses on the library cache

- Username under which each parse occurred

-Each commit and rollback

 SQL Trace & TKPROF
•TKPROF: Transient Kernel Profile
Generated SQL trace file is barely human readable.TKPROF collates and formats the
data into a a more meaningful form.

Syntax:
tkprof tracefile outpufile explain=user/passwd sys=no waits=yes sort=exeela,fchela

Here exeela = elapsed time executing and fchela = elapsed time fetching

•TKPROF Output : Trace Statistics

SQL Text
Table containing the execution Statistics
Library Cache misses
Execution Plans
 Elements of a TKPROF Report
•Report heading
– TKPROF version, date run, sort option, trace file

•One entry for each distinct SQL statement in trace file

– Listing of SQL statement
– OCI call statistics: count of parse, execute, and fetch calls,
rows processed, and time and I/O used
– Parse information: parsing user, recursive depth, library
cache misses, and optimizer mode
– Row source operation listing
– Execution plan listing (optional)
– Wait event listing (optional)
 TKPROF Example
This is the actual execution of the
statement by Oracle. For INSERT,
UPDATE, and DELETE statements, this This translates the SQL statement into an execution plan,
modifies the data. For SELECT including checks for proper security authorization and
statements, this identifies the selected checks for the existence of tables, columns, and other
rows. referenced objects.

This retrieves rows returned by a query. Fetches are only

performed for SELECT statements.
.

d
ows P rocesse
R
 SQL Tuning Advisor: Overview

Automatic Tuning Optimizer Comprehensive SQL tuning

Statistics check
optimization mode Detect stale or missing
statistics

Plan tuning Tune SQL plan

optimization mode
(SQL profile)

Access analysis Add missing index

optimization mode
Run access advisor

SQL Tuning
SQL analysis
optimization mode Advisor Restructure SQL
 Using the SQL Tuning Advisor

– Use the SQL Tuning Advisor to analyze SQL

statements and obtain performance
recommendations.
– Sources for SQL Tuning Advisor to analyze
• Top SQL: Analyzes the top SQL statements
currently active
• SQL Tuning Sets: Analyzes a set of SQL statements
you provide
• Snapshots: Analyzes a snapshot
• Baselines: Analyzes a baseline
Performance bottlenecks
 Where Do Problems Come From
Applications/SQL – 60%
DB design & indexing – 20%
DB tuning (SGA) – 18%
O/S and Hardware
O/S & hardware – 2%
DB Tuning

DB Design & Indexing Applications & SQL

Watch Out For:

Schema changes
changes in stats
Changes in data volumes
Changes in application
Database upgrades
 ROLE OF HARDWARE & DESIGN
• All the hardware in world will not save you
• Memory, Disk & CPU speed can improve
performance
• Increased hardware does not always result into
better performance
• Poor application design accounts for over 70% of
performance issues
• Do Performance design review early in development
How to Approach Performance Issue?
 Approach to Tuning
> Analyze the SQL statement
For access path, Join methods
> Index Usage
Optimal Index choice, Composite index
> Compare plan
Explain Plan, SQL Trace (TKPROF).
> Tuning Hints
Join Methods
 Hash Joins
Hash Join
Very useful for larger result sets, especially
Data Warehouses.
 Nested Loop
When the outer table is small and the join
column of the inner table are highly selective

In this case
Row source 1 is outer table
Row source 2 is inner table
 Sort Merge

A merge join basically sorts all relevant rows in the

first table by the join key , and also sorts the
relevant rows in the second table by the join key,
and then merges these sorted rows.

The behavior of merge joins is influenced by the

initialization parameters sort_area_size and
db_file_mutliblock_read_count.
 Side by Side Comparison of Join Methods
Nested Loop Sort Merge Hash Join

When to Use Any Join Equi Joins only Equi Joins Only

Optimizer Hint use_nl use_merge use_hash

Resource Concern CPU, Disk I/O Temporary Segment Memory

Init Parameter None sort_area_size hash_area_size

db_file_multiblock_read_count hash_joined_enabled

Features Works with any join Better than NL when index Better than NL when
are missing or search not index are missing not
No sorting required restrictive restrictive

Highly efficient with

selective indexes Can work with limited memory Faster than SMJ

Returns first rows faster

than Sort Merge or hash

Drawbacks Very inefficient when index Must perform sort before rows Can require lot of
are missing or search in not are returned. Expensive operation memory
restrictive
 Indexes
•Indexed retrieval is almost always faster (not 100% true) than full-
table scans
•In general, index
• Primary key columns (By default)
• Foreign key columns
• Columns used frequently in WHERE and ORDER BY clauses
• Know your Indexes and use them to your advantage
Comparison Operators that will use an index Comparison Operators that will not use an index

= col = :a != col != :a
NOT anything col NOT <:a
>[=] col >= :a
NOT col <:a
<[=] col < :a col NOT LIKE 'ABC%'
BETWEEN col BETWEEN :a AND :b LIKE '%...' col LIKE '%ABC%'
LIKE '_...' col LIKE '_ABC%'
LIKE col LIKE 'ABC%'
IS NULL col IS NULL
IN (list) col IN (1, 2, 3) IS NOT NULL col IS NOT NULL
 B*Tree Index

• Suitable for high-cardinality columns

• Updates on keys relatively inexpensive
• Useful for OLTP
 Bitmap Index

• Suitable for low-cardinality columns (<= 0.1 % that the

column is ideal candidate, consider also 0.2% – 1%)
• Updates to key columns very expensive
• Useful for data warehousing
 Optimal Index Choice
Index Selectivity
Index selectivity is a number that determines the effectiveness of index. Best
possible selectivity is when all table records have a different value for the columns in
index (this is typical for primary keys and unique constraints).
A percentage close to hundred indicates good selectivity and hence better index.
•Index selectivity is determined as
INDEX SELECTIVITY = [ No of distinct values / (Total number of rows) ] * 100
•How to find distinct values
select column_name, num_distinct
from user_tab_columns
where table_name = 'EMP';
 Composite Indexes

A composite index contains more than one key column. Composite indexes can
provide additional advantages over single column indexes.
Better Selectivity :Sometimes two or more columns, each with poor selectivity,
can be combined to form a composite index with good selectivity.
Adding Data Storage: If all the columns selected by the query are in the composite
index, Oracle can return these values from the index without accessing the table.
CREATE INDEX idx_composite ON mytab (x, y, z);
These combinations of columns are leading portions of the index: X, XY, and XYZ.
These combinations of columns are not leading portions of the index: YZ and Z.
 Operations & Options

OPERATION OPTION DESCRIPTION

INDEX UNIQUE SCAN Retrieval of a single ROWID
from an index.

RANGE SCAN More than one row retrieved

by index. Either because
index is non-unique or a
range operator (e.g. ‘>’) was
used.

FULL SCAN Scan every entry in the index

in key order.
FULL SCAN Find the highest or lowest
index entry.
(MAX/MIN)
 Operations & Options
OPERATION OPTION DESCRIPTION
SORT ORDER BY A result set is sorted in order to
satisfy an ORDER BY clause.

AGGREGATE Retrieval of a single row that is the

result of applying a group function
to a group of selected rows
JOIN Sort the rows in preparation for a
merge join.
UNIQUE A sort to eliminate duplicate rows.
Caused by ‘Distinct’ clause.

GROUP BY A sort of a result set in order to

group them for the GROUP BY
clause.
 Why is my Index not used?
Quick Initial Checks
• The column is indexed isn’t it? 
• Why SHOULD the index be used?

Issues with the index itself

• Are the indexed columns/leading column of the index supplied in
the where clause of the query as a single table predicate?
• Are the indexed columns part of join predicates?
• Are the indexed columns part of an IN list or multiple OR's?
• Are the indexed columns modified by functions?
• Is implicit type conversion going on?
• Are the indexed columns NULLable?
 Why is my Index not used?
Optimization and Costing issues
• Are Accurate and Appropriate statistics in place?
• Is the index unselective?
• Deletes do not necessarily free up allocated index space (Example)

Other Issues
• Are any of the tables remote?
• Is Parallel execution involved? (Example)
Writing SQL for performance
 EXISTS vs IN
• Use NOT EXISTS in place of NOT IN.
In sub-query statement such as the following NOT IN clause causes an
internal Sort/Merge.
SELECT *
FROM emp e
WHERE e.deptno NOT IN ( SELECT d.deptno
FROM dept d
WHERE d.dname like %S% ) ;
To improve performance use the following code.
SELECT *
FROM emp e
WHERE NOT EXISTS ( SELECT d.deptno
FROM dept d
WHERE d.deptno = e.deptno
AND d.dname LIKE '%S%' ) ;
This would allow such statements to use an index, if one exists.
 EXISTS vs JOIN
•Use Joins in place of EXISTS.
In general, join tables rather than specifying sub-queries.
SELECT * FROM emp e WHERE EXISTS ( SELECT d.deptno FROM dept d WHERE e.deptno = d.deptno AND
d.dname = 'RESEARCH') ;
To improve performance use the following:
SELECT * FROM emp e, dept d WHERE e.deptno = d.deptno AND d.dname = 'RESEARCH' ; .
•EXISTS in place of DISTINCT.
Use EXISTS in place of DISTINCT if you want the result set to contain distinct values while joining tables.
SELECT DISTINCT d.deptno ,d.dname ,
FROM dept d , emp e
WHERE d.deptno = e.deptno ;

The following SQL statement is a better alternative.

SELECT d.deptno , d.dname

FROM dept d
WHERE EXISTS ( SELECT e.deptno
FROM emp e
WHERE d.deptno = e.deptno ) ;
 Index Usage
• The Optimizer does not use index for the following statement.
SELECT * FROM emp
WHERE sal*12 > 24000 ;
Instead use the following statement.

SELECT * FROM emp

WHERE sal > 24000/12 ;

• Never use NOT on an indexed column. Whenever Oracle encounters a NOT on an

index column, it will perform full-table scan.

SELECT *
FROM emp
WHERE NOT deptno = 0;

Instead use the following.

SELECT *
FROM emp
WHERE deptno > 0;
 Index Usage
/** Do Not use **/ /** Suggested Alternative **/
SELECT * SELECT *
FROM emp FROM emp
WHERE sal != 0 ; WHERE sal > 0 ;

Note: Index can tell you what is there in a table but not what is not in a table.

•ORDER BY clause

If A table is indexed with lastname, firstname.

Replace
SELECT * FROM emp
WHERE lastname = 'Smith'
ORDER BY firstname
With
SELECT * FROM emp
WHERE lastname = 'Smith'
ORDER BY lastname, firstname
 Using Case
EMP Table Structure
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

7369SMITH CLERK 7902 17-Dec-80 800 20

7499ALLEN SALESMAN 7698 20-Feb-81 1600 300 30

7521WARD SALESMAN 7698 22-Feb-81 1250 500 30

7566JONES MANAGER 7839 2-Apr-81 2975 20

7654MARTIN SALESMAN 7698 28-Sep-81 1250 1400 30

7698BLAKE MANAGER 7839 1-May-81 2850 30

7782CLARK MANAGER 7839 9-Jun-81 2450 10

7788SCOTT ANALYST 7566 19-Apr-87 3000 20

Required Output select count(case when sal between 1001 and 2000 then
empno end) Sal_1k_2k ,
count(case when sal between 2001 and 3000 then empno
Sal_1K_2K Sal_2K_3K Sal_3K_4K end) Sal_2k_3k ,
count(case when sal between 3001 and 4000 then empno
6 5 0 end) Sal_3k_4K
from scott.emp
 Working with Date
Find all objects created on a particular DATE?

Column Name Datatype

owner varchar2(30)
object_name varchar2(128)
subobject_name varchar2(30)
object_id number
data_object_id number
object_type varchar2(19)
created date
last_ddl_time date
timestamp varchar2(19)
status varchar2(7)
temporary varchar2(1)
generated varchar2(1)
secondary varchar2(1)
namespace number
edition_name varchar2(30)
 Working with DELETE Cascade
MY_UOBJECT(44260) MY_DEPENDENCIES(1324264)

Column Name Datatype Column Name Datatype

object_name varchar2(128) owner varchar2(30)

name varchar2(30)

type varchar2(18)

referenced_owner varchar2(30)

referenced_name varchar2(64)

Foreign Key (on delete cascade) referenced_type varchar2(18)

referenced_link_name varchar2(128)

dependency_type varchar2(4)

Issue: The delete below takes long time and sometime hangs.
delete from my_uobject where object_name='DUAL‘;
 Union vs Union All

What is the difference between UNION and UNION ALL?

UNION will eliminate any duplicate rows returned by the various select
statements being unioned whereas UNION ALL will not. It will return all
records even duplicates.

What this difference has got to do with Performance?

Understanding Analytic Functions
 Analytic Functions

• “standard” name is “Window” functions

• When? – Starting 8i

• Why? – Simple Solution of Complex Problems

• Why Exactly? – advanced ranking, aggregation, row comparison,

statistics, “what if” scenarios
• Note: Analytical function cannot exist in a WHERE, GROUP BY or
HAVING clause
 Why Analytical SQL
– Improved code
» Readability
» Supportability
– Improved Performance
» Fewer passes on a table
» Less resource consumption
» Faster run time
– Part of the core product
 Analytic Functions
Can be used for finding
• Selecting the Top n Records
• Calculate Moving Average
• Find most recent records
• Convert Rows into Columns
 Analytic Functions
STANDARD AGGREGATE FUNCTIONS
• ROW_NUMBER()
• LAG()
• LEAD()
• RANK()
• DENSE_RANK()
• FIRST_VALUE()
• LAST_VALUE()
• STATISTICAL FUNCTIONS
 Enhanced Analytical Functions
– New aggregation LISTAGG flattens result sets into a single
record
• Common requirement for 1:many correlations, e.g.
hierarchical data,bill of materials
– Example:
• SELECT deptno,
• LISTAGG(ename, '; ') WITHIN GROUP (order by
• ename) FROM emp GROUP BY deptno;
• DEPTNO LISTAGG(ENAME,';')WITHINGROUP(ORDERBYENAME)
• ------ -------------------------------------------
• 10 CLARK; KING; MILLER
• 20 ADAMS; FORD; JONES; SCOTT; SMITH
• 30 ALLEN; BLAKE; JAMES; MARTIN; TURNER; WARD
Understanding Materialized Views
 Materialized Views
What is a Materialized View?

•A database object that stores the results of a query

Features/Capabilities
• Can be partitioned and indexed
• Can be queried directly
• Can have DML applied against it
• Several refresh options are available
• Best in read-intensive environments
 Materialized Views
Advantages
• Useful for summarizing, pre-computing, replicating and distributing data
• Faster access for expensive and complex joins
• Transparent to end-users(MVs can be added/dropped without invalidating
coded SQL)

Disdvantages
• Storage costs of maintaining the views
• Maintenance overhead for Support team
 Materialized Views
Materialized View Syntax
CREATE MATERIALIZED VIEW <name>
TABLESPACE <tbs name> {<storage parameters>}
<build option>
REFRESH <refresh option> <refresh mode>
[ENABLE|DISABLE] QUERY REWRITE
AS
SELECT <select clause>;

The <build option> determines when MV is built

– BUILD IMMEDIATE: view is built at creation time
– BUILD DEFFERED: view is built at a later time
– ON PREBUILT TABLE: use an existing table as view source
 Must set QUERY_REWRITE_INTEGRITY to TRUSTED(Check whether needs
bounce)
 Materialized Views
Refresh Options
– COMPLETE – totally refreshes the view
 Can be done at any time; can be time consuming

– FAST – incrementally applies data changes

 A materialized view log is required on each detail table
 Data changes are recorded in MV logs or direct loader logs
 Many other requirements must be met for fast refreshes

– FORCE – does a FAST refresh in favor of a COMPLETE

 The default refresh option
 Materialized Views
Refresh Modes
– ON COMMIT – refreshes occur whenever a commit is performed on one of the
view’s underlying detail table(s)
 Available only with single table aggregate or join based views
 Keeps view data transactionally accurate
 Need to check alert log for view creation errors
– ON DEMAND – refreshes are initiated manually using one of the procedures in
the DBMS_MVIEW package
 Can be used with all types of materialized views
 Manual Refresh Procedures
– DBMS_MVIEW.REFRESH(<mv_name>, <refresh_option>)
– DBMS_MVIEW.REFRESH_ALL_MVIEWS()
– START WITH [NEXT] <date> - refreshes start at a specified date/time and
continue at regular intervals
Understanding Partitions
 Partitioning
Partitioning Defined
• The Concept of Divide and Rule
• Breaking down a large problem into smaller manageable pieces
• Dividing Tables and Indexes into manageable pieces
 Partitioning
Evolution of Partitioning
Oracle 8 Oracle 8i Oracle 9i Oracle 11g
Release 1&2
•Range •Range •Range •Range
•Hash •Hash •Hash
•Composite •List •List
• Range-Hash •Composite •Reference
• Range-Hash •Interval
• Range-List •Composite
• Range-Hash
• Range-List
• Range-Range
• List-Range
• List-Hash
• List-List
 Partitioning
When to partition?
• When a table reaches a “large” size. Large being defined relative to
your environment.
• When the archiving of data is on a schedule and is repetitive. For
instance, data warehouses usually hold data for a specific amount of
time (rolling window). Old data is then rolled off to be archived.
• When performance benefits outweigh the additional management
issues related to partitioning.
 Partitioning
Benefits of Partitioning
• Management at the individual partition level for data loads, index
creation and rebuilding, and backup/recovery.
• Increased query performance by selecting only from the relevant
partitions.
This weeding out process eliminates the partitions that do not contain
the data needed by the query through a technique called partition
pruning.(Example)
 Range Partitioning Example
CREATE TABLE emp (
empno NUMBER(4),
ename VARCHAR2(30),
sal NUMBER
)
PARTITION BY RANGE(empno) (
partition e1 values less than (1000) tablespace ts1,
partition e2 values less than (2000) tablespace ts2,
partition e3 values less than (MAXVALUE) tablespace ts3
);
 List Partitioning Example
CREATE TABLE myemp_work (
emp# NUMBER PRIMARY KEY,
ename VARCHAR2(30),
salary NUMBER(8,2),
deptno NUMBER)
PARTITION BY LIST (deptno) (
PARTITION p10 VALUES (10),
PARTITION p20 VALUES (20),
PARTITION p30 VALUES (30,40));
 Hash Partitioning Example
create table emp2 (
empno number(4),
ename varchar2(30),
sal number
)
partition by hash(empno) (
partition e1 tablespace emp1,
partition e2 tablespace emp2,
partition e3 tablespace emp3,
partition e4 tablespace emp4
);
 Partitioning
Indexes : Global, Local
• Global
• A global index is partitioned, but along different lines from the
table. It may be on the same key, but different ranges; or it
could be on a different key altogether.

• Local
• A local index is equi-partitioned with the underlying table, so
each index partition has entries for rows in a single table
partition. The partition bounds will be the same as for the table
itself.
Understanding Hints
External Links:

http://www.datadisk.co.uk/html_docs/oracle/sql_optimization.htm
http://www.akadia.com/services/ora_interpreting_explain_plan.html
http://www.adp-gmbh.ch/ora/sql/join/join_methods.html