Oracle DBA FAQ's

Part:   1  2  3  4  5   6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21 

Oracle Monitoring and Performance Tuning (1)

Why and when should one tune?

One of the biggest responsibilities of a DBA is to ensure that the Oracle database is tuned properly. The Oracle RDBMS is highly tunable and allows the database to be monitored and adjusted to increase its performance. One should do performance tuning for the following reasons:
The speed of computing might be wasting valuable human time (users waiting for response); Enable your system to keep-up with the speed business is conducted; and Optimize hardware usage to save money (companies are spending millions on hardware). Although this FAQ is not overly concerned with hardware issues, one needs to remember than you cannot tune a Buick into a Ferrari.

What database aspects should be monitored?

One should implement a monitoring system to constantly monitor the following aspects of a database. Writing custom scripts, implementing Oracle's Enterprise Manager, or buying a third-party monitoring product can achieve this. If an alarm is triggered, the system should automatically notify the DBA (e-mail, page, etc.) to take appropriate action.
Infrastructure availability:
. Is the database up and responding to requests
. Are the listeners up and responding to requests
. Are the Oracle Names and LDAP Servers up and responding to requests
. Are the Web Listeners up and responding to requests

Things that can cause service outages:
. Is the archive log destination filling up?
. Objects getting close to their max extents
. User and process limits reached

Things that can cause bad performance:
See question "What tuning indicators can one use?".

Where should the tuning effort be directed?

Consider the following areas for tuning. The order in which steps are listed needs to be maintained to prevent tuning side effects. For example, it is no good increasing the buffer cache if you can reduce I/O by rewriting a SQL statement. Database Design (if it's not too late):
Poor system performance usually results from a poor database design. One should generally normalize to the 3NF. Selective denormalization can provide valuable performance improvements. When designing, always keep the "data access path" in mind. Also look at proper data partitioning, data replication, aggregation tables for decision support systems, etc.
Application Tuning:
Experience showed that approximately 80% of all Oracle system performance problems are resolved by coding optimal SQL. Also consider proper scheduling of batch tasks after peak working hours.
Memory Tuning:
Properly size your database buffers (shared pool, buffer cache, log buffer, etc) by looking at your buffer hit ratios. Pin large objects into memory to prevent frequent reloads.
Disk I/O Tuning:
Database files needs to be properly sized and placed to provide maximum disk subsystem throughput. Also look for frequent disk sorts, full table scans, missing indexes, row chaining, data fragmentation, etc
Eliminate Database Contention:
Study database locks, latches and wait events carefully and eliminate where possible. Tune the Operating System:
Monitor and tune operating system CPU, I/O and memory utilization. For more information, read the related Oracle FAQ dealing with your specific operating system.

What tuning indicators can one use?

The following high-level tuning indicators can be used to establish if a database is performing optimally or not:
. Buffer Cache Hit Ratio
Formula: Hit Ratio = (Logical Reads - Physical Reads) / Logical Reads
Action: Increase DB_CACHE_SIZE (DB_BLOCK_BUFFERS prior to 9i) to increase hit ratio
. Library Cache Hit Ratio
Action: Increase the SHARED_POOL_SIZE to increase hit ratio

What tools/utilities does Oracle provide to assist with performance tuning?

Oracle provide the following tools/ utilities to assist with performance monitoring and tuning:
. TKProf
. UTLBSTAT.SQL and UTLESTAT.SQL - Begin and end stats monitoring
. Statspack
. Oracle Enterprise Manager - Tuning Pack

What is STATSPACK and how does one use it?

Statspack is a set of performance monitoring and reporting utilities provided by Oracle from Oracle8i and above. Statspack provides improved BSTAT/ESTAT functionality, though the old BSTAT/ESTAT scripts are still available. For more information about STATSPACK, read the documentation in file $ORACLE_HOME/rdbms/admin/spdoc.txt.
Install Statspack:
cd $ORACLE_HOME/rdbms/admin
sqlplus "/ as sysdba" @spdrop.sql -- Install Statspack -
sqlplus "/ as sysdba" @spcreate.sql-- Enter tablespace names when prompted
Use Statspack:
sqlplus perfstat/perfstat
exec statspack.snap; -- Take a performance snapshots
exec statspack.snap;
o Get a list of snapshots
select SNAP_ID, SNAP_TIME from STATS$SNAPSHOT;
@spreport.sql -- Enter two snapshot id's for difference report
Other Statspack Scripts:
. sppurge.sql - Purge a range of Snapshot Id's between the specified begin and end Snap Id's
. spauto.sql - Schedule a dbms_job to automate the collection of STATPACK statistics
. spcreate.sql - Installs the STATSPACK user, tables and package on a database (Run as SYS).
. spdrop.sql - Deinstall STATSPACK from database (Run as SYS)
. sppurge.sql - Delete a range of Snapshot Id's from the database
. spreport.sql - Report on differences between values recorded in two snapshots
. sptrunc.sql - Truncates all data in Statspack tables

Part:   1  2  3  4  5   6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21