Академический Документы
Профессиональный Документы
Культура Документы
Robert J. Buda
President
Buda Consulting
rjbuda@budaconsulting.com
February 2011
Table of Contents
Introduction .................................................................................................................................................................. 1
Conclusion................................................................................................................................................................... 14
Copyright © 2011 by Buda Consulting, Inc. All rights reserved. Printed in USA.
Oracle is a registered trademark of Oracle Corporation. All other marks are property of their respective companies.
Buda Consulting
957 Route 33
Hamilton Square, NJ 08690
1-888-548-1801
ii
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
Introduction
As we evaluate our clients’ Oracle® database systems and help them solve problems relating to
performance and stability, we see many causes for these issues. However, there are a small number of
basic issues that tend to cause problems on the majority of systems.
This paper describes five of the more frequent issues that we see, and discusses how to identify these
problems and resolve them.
Page 1
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
exec dbms_stats.gather_database_stats(
options => 'GATHER AUTO',
-- include tables with empty or stale stats
estimate_percent => dbms_stats.auto_sample_size
-- auto determine sample size
)
Alternatively, you can gather stats for one particular schema with the following command:
exec dbms_stats.gather_schema_stats(
ownname => 'BIG_DATA’,
-- collect stats on the BIG_DATA Schema
options => 'GATHER AUTO',
-- include tables with empty or stale stats
estimate_percent => dbms_stats.auto_sample_size
-- auto determine sample size
)
Copying Statistics
After statistics have been gathered, they can be copied from one database to another. This is useful
if, for example, you want the optimizer to choose execution paths similar to your production paths
on databases that may have a smaller data set, such as development or QA databases.
This can be done using the following commands:
-- Create a table to hold the statistics
exec dbms_stats.create_stat_table
(ownname=>’BOB’, stattab=>'PRODUCTION_STATISTICS’);
-- Export statistics to the newly created table
exec dbms_stats.export_schema_stats
(ownname=>’BOB’, stattab=> 'PRODUCTION_STATISTICS');
-- Export the stats table
!exp bob/tiger tables='PRODUCTION_STATISTICS'
-- Drop the table
drop table PRODUCTION_STATISTICS;
Page 2
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
Page 3
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
The PGA is a set of buffers that is allocated for operations performed by user processes. This area is
comprised of:
Page 4
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
turned on, the prior redo log is then archived to another location. This process continues until the
third log is filled, and then the first log is reused, as illustrated in Figure 1.
When logs are undersized for the insertion or update rates, logs switch frequently. This results in
numerous problems. Here are three of the most typical:
1. Each of the log switches takes system resources, and so constitutes a general drag on the
system. Log switches can be seen by viewing the v$loghist system view.
Page 5
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
2. Very frequent switches can cause a very high number of log sync waits. These waits delay the
insertion of data. Log sync waits can be seen in an automatic workload repository (AWR)
report.
3. If an online log file cannot be archived by the time the system wants to use that file again, no
inserts or updates will take place until that file is successfully archived.
By increasing the size of the redo log, you can decrease the time between log switches. As a general
rule, you should try to log switch no more frequently than every 20 minutes.
Add new logfiles, and drop old ones, using the following commands:
Alter database add logfile To add the new, larger logfiles
Alter system switch logfile To ensure that the old logs are no longer used
Alter database drop logfile To drop the older logfiles
After increasing the size of your logs, check v$loghist after a few hours of production usage to see if
the time between log switches has been increased to more than twenty minutes. If it has not, repeat
the above process until you have at least twenty minutes between switches.
Page 6
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
To determine whether a query is using an index, you can view the execution plan of the query. To do
this, use the “explain plan” command as demonstrated in the following example. For this example,
we will use the warehouse_inventory table:
-- create the table that we will use for our example
Create table warehouse_inventory (
warehouse_id number,
warehouse_name varchar2(30),
product_id number ,
qty number
);
The above command stores the resulting execution plan in the plan table. Note that this form of the
“explain plan” command does not give a name to the stored execution plan. Therefore you must
delete all rows from the plan table before issuing another “explain plan” command.
To view the formatted results of the plan, use the following query:
substr (lpad(' ', level-1) || operation || ' (' || options || ')',1,30
) "Operation",
object_name "Object"
from
plan_table
start with id = 0
connect by prior id=parent_id;
Note the line that says TABLE ACCESS (FULL), followed by a table name. This indicates that this
query is not using any indexes for the referenced table.
After creating an index on the warehouse_name field, the results of the execution plan will reflect the
use of the index.
-- create an index on the warehouse_name field
create index warehouse_name1_ind on
warehouse_inventory(warehouse_name);
Page 7
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
Note how the newly created index is now used in the execution plan.
Page 8
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
Even though the warehouse_name column has an index, this index cannot be used because
the indexed value may not be the same as the result of the upper function.
However, if you must use a function in the query as above, you can create a function–based
index on the function that you are using. For example, to create an index on the function in
the above example:
-- create the function based index
CREATE INDEX Upper_Warehouse_Name_ind
ON warehouse_inventory (Upper(warehouse_name));
Page 9
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
• Use of a non-leading column in an index. Another reason that an index may be ignored
is when the leading column of a multi-column index is not used in the query. Revising the
indexes on our warehouse_inventory table gives us:
Create table warehouse_inventory (
warehouse_id number,
warehouse_name varchar2(30),
product_id number ,
qty number
);
Even though warehouse_name is in the wh1_ind index, it will not be used here because we
are not also using the warehouse_id, which is the leading column in the index, in the
WHERE clause.
Page 10
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
When a table or index is first created, the extents within the segment are on contiguous areas on the
disk. This means there is no empty space between them.
Page 11
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
In addition to the impact that these conditions have on query performance, they waste disk space.
For these reasons, you need to periodically reorganize database tables in order to ensure that the
storage is efficient.
Reorganizing will eliminate the empty space, thus freeing up the space for use by other tables. It will
also eliminate chaining and migration of rows.
Oracle also sometimes coalesces space automatically. As mentioned above, there can be multiple
non-contiguous free areas inside a database block. When this occurs, there are times that Oracle will
automatically coalesce those areas into one large area. According to the Oracle documentation, this
will occur only when the following occurs:
• An INSERT or UPDATE statement attempts to use a block that contains enough free space
to contain a new row piece,
• The free space is fragmented so the row piece cannot be inserted in a contiguous section of
the block.
Page 12
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
After the Segment Advisor is executed, there are numerous ways to view the results. The simplest
way to do this is to use the DBA_ADVISOR views.
The following examples from the Oracle documentation demonstrate each step of this process.
First, create, configure, and execute the task. In this example, we are examining the Employees table
in the HR schema.
Page 13
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
After reviewing the results and determining that reorganization is necessary, you can issue the online
“shrink” command. The “cascade” option indicates that index segments associated with the table
should be shrunk as well.
Online table redefinition can be used if you need to keep the table online but are not using ASSM.
This method requires extra disk space but, like online segment shrink, the table remains available for
use during the operation.
The online table redefinition process is complex and is beyond the scope of this paper. It is only a
good option for this purpose if the table must remain online.
If the table can be taken offline during the operation, then the following simpler options are
available.
1. Using “Create table as select * from ...”, truncating the table, and then re-inserting from the
copy.
2. Using export/import to dump the table out to an external file and then bring it back in.
3. Unload the data to a flat file and use the SQL Loader utility to bring it back in.
The best method to choose among these options depends on the size of the table involved and other
factors. We will explore this further in a future Tech Brief.
Conclusion
The five topics discussed in this paper are frequently the cause of performance problems in an
Oracle database. Resolving these issues before they cause problems can help keep your applications
running smoothly and trouble-free.
Page 14
Five Leading Causes of Oracle Performance Problems and How to Solve Them:
A Buda Consulting Technical Brief
Page 15