15 copyright © 2006, oracle. all rights reserved. performance tuning: summary

15Copyright © 2006, Oracle. All rights reserved.

Performance Tuning: Summary

Copyright © 2006, Oracle. All rights reserved.15-2

Objectives

After completing this lesson, you should be able to do the following:

• List best practices identified throughout the course

• Summarize the performance tuning methodology


Necessary Initialization Parameters with Little Performance Impact

Set to the maximum number of files that can be assigned to the database

DB_FILES

Set to TYPICALSTATISTICS_LEVEL

Set to contain at least two files on different disk drives to prevent failures from control file loss

CONTROL_FILES

Limit on the maximum number of cursors for each session. The setting is application-dependent; 500 is recommended.

OPEN_CURSORS

Location of the database in Internet dot notation

DB_DOMAIN

Name of the database. This should match the ORACLE_SID environment variable.

DB_NAME

DescriptionParameter


Important Initialization Parameters with Performance Impact

Undo tablespace to be used by instance UNDO_TABLESPACE

AUTO mode recommendedUNDO_MANAGEMENT

To be used essentially with shared server

SESSIONS

Maximum number of processes that can be started by that instance

PROCESSES

Automatic PGA managementPGA_AGGREGATE_TARGET

Automatically sized SGA components SGA_TARGET

8192 for OLTP and higher for DSSDB_BLOCK_SIZE

To take advantage of the latest improvements of a new release

COMPATIBLE

DescriptionParameter


Sizing Memory Initially

As an initial guess for memory allocation:

• Leave 20% of available memory to other applications.

• Leave 80% of memory to the Oracle instance.

• For OLTP:

• For DSS:

PGA_AGGREGATE_TARGET=(total_mem*80%)*20%

PGA_AGGREGATE_TARGET=(total_mem*80%)*50%

SGA_TARGET=(total_mem*80%)*80%

SGA_TARGET=(total_mem*80%)*50%


Database High Availability: Best Practices

• Use SPFILE.

• Multiplex redo logs.

• Use resumable space allocation.

• Create at least two control files.• Enable Flashback Database.

• Enable block checking.

• Use auto-tune checkpointing.

• Log checkpoints to the alert log.

• Use database resource manager.

• Use Automatic Undo Management.

• Use Automatic Segment Space Management.

• Use locally managed tablespaces.

• Use locally managed temporary tablespaces.

• Enable ARCHIVELOG mode and use a flash recovery area.• Set time long enough for CONTROL_FILE_RECORD_KEEP_TIME.• Designate a default permanent tablespace other than SYSTEM and

SYSAUX.


Undo Tablespace: Best Practices

• Use Automatic Undo Management.

• UNDO_RETENTION:– Oracle Database 10g Release 1: Set it to your

flashback requirement.– Oracle Database 10g Release 2: Do not set it.

• Undo tablespace size:– Initial size: Small with AUTOEXTEND enabled– Steady state: Fix size using the Undo Advisor and

add a 20% safe margin.


Temporary Tablespace: Best Practices

Locally managed temporary tablespaces use a uniform extent. Extent size should be:

• 1 MB to 10 MB extent size:– For DSS, OLAP applications involving huge work

areas– Large temporary LOBs are predominant.

• 64 KB or multiple less than 1 MB:– Small global temporary tables are predominant.– OLTP

Temporary tablespace group increases addressability from TB to PB.


General Tablespace: Best Practices

• Use locally managed tablespaces with auto-allocate extents policy.

• Use Automatic Segment Space Management (ASSM).

• Use online segment shrink to eliminate internal fragmentation.

• Periodically review the results of the Automatic Segment Advisor.

• Monitor tablespace space usage using server-generated alerts.

• Size of extents matter more than the number of extents in the segments.


Internal Fragmentation Considerations

• Watch for:– Bad choices of PCTFREE and PCTUSED for heap

segments– Bad choices of PCTVERSION and RETENTION for

LOB segments– Low density of data in segment– Direct loads followed by deletes (no inserts)– Indexes on tables with random updates and deletes

with no further inserts

• Remedy:– Online segment shrink– Online redefinition– MOVE operations


Block Size: Advantages and Disadvantages

Index leaf block contention (OLTP)

Good for sequential access

Waste cache space with random access of small rows

Lower overhead: more room for data

Larger

For large rows (chaining)

Reduce block contention (OLTP)

Relatively high overhead (block header)

Small rows with lots of random access

Smaller

DisadvantagesAdvantagesBlock Size


Sizing Redo Log Files

• Size of redo log files can influence performance.

• Larger redo log files provide better performance.

• Generally, redo log files should range between 100 MB and a few gigabytes.

• Switch redo log file at most once every twenty minutes.

• Use the Redo Logfile Size Advisor to correctly size your redo logs.


Automatic Statistics Gathering

• STATISTICS_LEVEL = TYPICAL | ALL• Statistics are gathered by the predefined

GATHER_STATS_JOB job.

• This job implicitly determines the following:– Database objects with missing or stale statistics– Appropriate sampling percentage necessary to

gather good statistics on those objects– Appropriate columns that require histograms and

the size of those histograms– Degree of parallelism for statistics gathering– Prioritization of objects on which to collect

statistics


Automatic Statistics Collection: Considerations

• You should still manually gather statistics in the following cases:– After bulk operations– When using external tables– To collect system statistics– To collect statistics on fixed objects

• Prevent automatic gathering for volatile tables:– Lock with statistics for representative values– Lock without statistics implies dynamic sampling.


Commonly Observed Wait Events

commits + rollbacks from V$SYSSTAT, Disks.

Slow I/O, un-batched commits

Over-commit, I/O

Log file sync

V$SYSSTAT redo buffer allocation retries, disk

Small buffer, slow I/OLog buffer I/Olog buffer space

V$SQLAREA parse calls, child cursors

SQL parsing/sharingLatchesLibrary cache waits

V$ENQUEUE_STATDepends on enq typeLocksEnqueue waits (enq:)

V$SQLAREA disk reads. V$FILESTAT read time

Poorly tuned SQL,Slow I/O system

I/O,SQL Tuning

db file scattered read, db file sequential read

Write time using OS stats. Buffer cache stats

Slow DBWRBuffer cache,

DBWR, I/O

free buffer waits

V$SESSION (block) while issue is occurring

Depends on buffer type. PK index and seq.

Buffer cache, DBWR

buffer busy waits

ExaminePossible causeAreaWait Event


Additional Statistics

Use automatic undo, tune the workload

How many rollbacks done for consistent read purposes

Consistent changes

Checkpoints, DBWR, or archiver activity should be tuned, larger log files

How many times a

server process had to wait for space in the online redo log

Redo Log Space Requests

Use automatic undo, tune the workload

How many blocks are read in Consistent Read mode

Consistent gets

ReorganizeMigrated or chained rows

Table Fetch by Continued Row

Recommended actionDescriptionStatistic name


Top 10 Mistakes Found in Oracle Systems

1. Bad connection management

2. Bad use of cursors and shared pool

3. Bad SQL

4. Use of nonstandard initialization parameters

5. Getting database I/O wrong

6. Redo log setup problems

7. Serialization of data blocks in the buffer cache

8. Long full-table scans

9. High amount of recursive SQL

10. Deployment and migration errors


Summary

In this lesson, you should have learned how to:• Create your initial database following the best

practices identified throughout the course

• Summarize the performance tuning methodology

15 copyright © 2006, oracle. all rights reserved. performance tuning: summary

Documents