Database Tuning

Database tuning describes a group of activities used to optimize and homogenize the performance
of a database. It usually overlaps with query tuning, but refers to design of the database files,
selection of the database management system (DBMS) application, and configuration of the
database's environment (operating system, CPU, etc.).
Database tuning aims to maximize use of system resources to perform work as efficiently and
rapidly as possible. Most systems are designed to manage their use of system resources, but there is
still much room to improve their efficiency by customizing their settings and configuration for the
database and the DBMS.
It is expected to solve performance issues by DBA ( Database Administrator ) when performance
complaints in the Oracle database begin to increase.

The purpose of Performance tuning is as follows.

• Minimizing response time

• Increasing throughput
• Increasing load capabilities
• Reducing recovery time

Before start to solve the performance issue, you need to determine what the problems are and how
to solve them.

Introduction to SQL Tuning

SQL tuning is the attempt to diagnose and repair SQL statements that fail to meet a performance
standard.

SQL tuning is the iterative process of improving SQL statement performance to meet specific,
measurable, and achievable goals.

SQL tuning implies fixing problems in deployed applications. In contrast, application design sets the
security and performance goals before deploying an application.

Purpose of SQL Tuning

A SQL statement becomes a problem when it fails to perform according to a predetermined and
measurable standard.

After you have identified the problem, a typical tuning session has one of the following goals:

 Reduce user response time, which means decreasing the time between when a user issues
a statement and receives a response
 Improve throughput, which means using the least amount of resources necessary to
process all rows accessed by a statement
For a response time problem, consider an online book seller application that hangs for three
minutes after a customer updates the shopping cart. Contrast with a three-minute parallel
query in a data warehouse that consumes all of the database host CPU, preventing other queries
from running. In each case, the user response time is three minutes, but the cause of the problem is
different, and so is the tuning goal.

SQL Tuning Tasks

The specifics of a tuning session depend on many factors, including whether you tune proactively or
reactively.

In proactive SQL tuning, you regularly use SQL Tuning Advisor to determine whether you can
make SQL statements perform better. In reactive SQL tuning, you correct a SQL-related problem
that a user has experienced.

Whether you tune proactively or reactively, a typical SQL tuning session involves all or most of the
following tasks:

• Identifying high-load SQL statements

• Gathering performance-related data
• Determining the causes of the problem
• Defining the scope of the problem
• Implementing corrective actions for suboptimally performing SQL statements
• Preventing SQL performance regressions

SQL Tuning Tools

SQL tuning tools are either automated or manual.

In this context, a tool is automated if the database itself can provide diagnosis, advice, or corrective
actions. A manual tool requires you to perform all of these operations.

All tuning tools depend on the basic tools of the dynamic performance views, statistics, and metrics
that the database instance collects. The database itself contains the data and metadata required to
tune SQL statements.

Manual SQL Tuning Tools

In some situations, you may want to run manual tools in addition to the automated tools.
Alternatively, you may not have access to the automated tools.

Execution Plans

Execution plans are the principal diagnostic tool in manual SQL tuning. For example, you can view
plans to determine whether the optimizer selects the plan you expect, or identify the effect of
creating an index on a table.

You can display execution plans in multiple ways. The following tools are the most commonly used:
  EXPLAIN PLAN

This SQL statement enables you to view the execution plan that the optimizer would use to
execute a SQL statement without actually executing the statement.

 AUTOTRACE

The AUTOTRACE command in SQL*Plus generates the execution plan and statistics about
the performance of a query..

 V$SQL_PLAN and related views

These views contain information about executed SQL statements, and their execution plans,
that are still in the shared pool.

You can use the DBMS_XPLAN package methods to display the execution plan generated by
the EXPLAIN PLAN command and query of V$SQL_PLAN.

Introduction to Execution Plans

The combination of the steps that Oracle Database uses to execute a statement is an execution
plan. Each step either retrieves rows of data physically from the database or prepares them for the
user issuing the statement. An execution plan includes an access path for each table that the
statement accesses and an ordering of the tables (the join order) with the appropriate join
method.

About the Plan Explanation

A statement execution plan is the sequence of operations that the database performs to run the
statement.

The row source tree is the core of the execution plan. The tree shows the following information:

 An ordering of the tables referenced by the statement

 An access method for each table mentioned in the statement
 A join method for tables affected by join operations in the statement
 Data operations like filter, sort, or aggregation

In addition to the row source tree, the plan table contains information about the following:

 Optimization, such as the cost and cardinality of each operation

 Partitioning, such as the set of accessed partitions
 Parallel execution, such as the distribution method of join inputs
You can use the EXPLAIN PLAN results to determine whether the optimizer chose a particular
execution plan, such as a nested loops join. The results also help you to understand the optimizer
decisions, such as why the optimizer chose a nested loops join instead of a hash join.

Generating Execution Plans

The EXPLAIN PLAN statement enables you to examine the execution plan that the optimizer chose
for a SQL statement. When the statement is issued, the optimizer chooses an execution plan and
then inserts data describing the plan into a database table. Issue the EXPLAIN PLAN statement and
then query the output table.

Executing EXPLAIN PLAN for a Single Statement

The basics of using the EXPLAIN PLAN statement are as follows:

 Use the SQL script CATPLAN.SQL to create a sample output table called PLAN_TABLE in
your schema.
 Include the EXPLAIN PLAN FOR clause before the SQL statement.
 After issuing the EXPLAIN PLAN statement, use a script or package provided by Oracle
Database to display the most recent plan table output. .
 The execution order in EXPLAIN PLAN output begins with the line that is the furthest
indented to the right. The next step is the parent of that line. If two lines are indented
equally, then the top line is normally executed first.

To explain a SQL statement, use the EXPLAIN PLAN FOR clause immediately before the
statement. For example:
EXPLAIN PLAN FOR
SELECT last_name FROM employees;

Displaying PLAN_TABLE Output

After you have explained the plan, use the following SQL scripts or PL/SQL package provided by
Oracle Database to display the most recent plan table output:

 UTLXPLS.SQL

This script displays the plan table output for serial processing UTLXPLP.SQL

This script displays the plan table output including parallel execution columns.

 DBMS_XPLAN.DISPLAY table function

This function accepts options for displaying the plan table output. You can specify:

 A plan table name if you are using a table different than PLAN_TABLE
 A statement ID if you have set a statement ID with the EXPLAIN PLAN
 A format option that determines the level of detail: BASIC, SERIAL, TYPICAL, and ALL
 Examples of using DBMS_XPLAN to display PLAN_TABLE output are:

SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());

SELECT PLAN_TABLE_OUTPUT

FROM TABLE(DBMS_XPLAN.DISPLAY('MY_PLAN_TABLE', 'st1','TYPICAL'));

Oracle - Tuning with Database Design

Few things are more important for performance than a proper database design. In
fact, it is very difficult, if not impossible to tune a database that does not have an
efficient database design.

Essentially, by database design we are referring to the logical and physical design of
the Oracle tables, the presence of table indexes, and the design of the application that
accesses the database. For an overview, we can separate Oracle database design into
several areas:

1. Logical design - This refers to the logical structure of the tables and the
number of SQL joins operations that are required to service a request. As a
general rule, the more we pre-join tables together in design, the faster the tables
will perform at run time.
2. Physical design - Physical design is the implementation details behind the
database structure. This refers to the sizing of the table parameters, the
placement of indexes, and the physical configuration of the Oracle instance.
3. Application design - The design of the application also has a great impact on
Oracle performance. The proper use of PL/SQL stored procedures, and use of
database constraints, and the parallel processing demands of the application
will have a great impact on the performance of the database. While no two
databases are identical, this course will present each of these topics and show
how the Oracle DBA can ensure proper design through each phase of design.
Next, let's look at logical database design and see how it affects database
performance.