6599584-Oracle9i-Performance-Tuning

Page 1

Oracle9i Database Performance Tuning Electronic Presentation

D11299GC21 Edition 2.1 June 2003 D38323


Authors

Copyright © Oracle Corporation, 2003. All rights reserved.

Peter Kilpatrick Shankar Raman Jim Womack

This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:

Technical Contributors and Reviewers Mirza Ahmad David Austin Ruth Baylis Howard Bradley Pietro Colombo Michele Cyran Benoit Dagerville Connie Dialeris Joel Goodman Scott Gossett Lilian Hobbs Alexander Hunold Sushil Kumar Roderick Manalac Howard Ostrow Darren Pelacchi Sander Rekveld Maria Senise Ranbir Singh Janet Stern Wayne Stokes Tracy Stollberg Harald Van Breederode John Watson Publisher Joseph Fernandez

Restricted Rights Legend Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to be Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988). This material or any portion of it may not be copied in any form or by any means without the express prior written permission of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminal penalties. If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with “Restricted Rights,” as defined in FAR 52.227-14, Rights in DataGeneral, including Alternate III (June 1987). The information in this document is subject to change without notice. If you find any problems in the documentation, please report them in writing to Education Products, Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065. Oracle Corporation does not warrant that this document is error-free. Oracle and all references to Oracle and Oracle products are trademarks or registered trademarks of Oracle Corporation. All other products or company names are used for identification purposes only, and may be trademarks of their respective owners.


Overview of Oracle9i Database Performance Tuning

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Define the roles associated with the database tuning process • Describe the dependencies between tuning in different development phases • Describe service level agreements • Identify tuning goals • Identify common tuning problems • Employ tuning activities during development and production • Balance performance and safety trade-offs Copyright © 2003, Oracle. All rights reserved.


Tuning Questions

Who tunes? – – – –

• •

Application designers Application developers Database administrators System administrators

What to tune? How much tuning is required?

Copyright © 2003, Oracle. All rights reserved.


Tuning Phases

Tuning can be divided into different phases: • Application design and programming • Database configuration • Adding a new application to an existing database • Troubleshooting and tuning

Copyright © 2003, Oracle. All rights reserved.


Tuning Goals

Tuning goals are usually specified in terms of: • Minimizing response time • Increasing throughput • Increasing load capabilities • Decreasing recovery time

Copyright © 2003, Oracle. All rights reserved.


Common Performance Problems

Bad session management: – Limits scalability to a point that cannot be exceeded – Makes the system one or two orders of magnitude slower than it should be

• •

Bad cursor management Bad relational design: – Unnecessary table joins performed – Usually a result of trying to build an object interface to relational storage

Copyright © 2003, Oracle. All rights reserved.


Tuning Steps During Development

• • • • • •

Tune the design Tune the application Tune memory Tune I/O Tune contention Tune the operating system

Copyright © 2003, Oracle. All rights reserved.


Collect a Baseline Set of Statistics

A baseline set of statistics is used to: • Provide a set of statistics that are collected when the system was operating within the bounds set • Create a hypothesis about what has changed on the system

Copyright © 2003, Oracle. All rights reserved.


Tuning Steps for a Production Database

1. 2. 3. 4. 5. 6.

Define the problem. Examine the host system and Oracle statistics. Consider some common performance errors. Build a conceptual model. Implement and measure the change. Check that the bottleneck has been resolved.

Copyright Š 2003, Oracle. All rights reserved.


Database Server Tuning Methodology

• • • •

Check alert log and trace files for errors. Check the parameter file for any diagnostic or inappropriate parameter setting. Check memory, I/O, and CPU usage. Identify processes with resource usage anomalies. Identify and tune SQL statements that are heavy consumers of CPU or I/O.

Copyright © 2003, Oracle. All rights reserved.


Database Server Tuning Methodology

Tuning response time: • Analyze system performance in terms of work done (CPU or service time) versus time spent waiting for work (wait time). • Determine which component consumes the greatest amount of time. • Drill down to tune that component, if appropriate.

Copyright © 2003, Oracle. All rights reserved.


Performance Versus Safety Trade-Offs

Factors that affect performance: • Multiple control files • Multiple redo log members in a group • Frequent checkpointing • Backing up data files • Performing archiving • Block check numbers • Number of concurrent users and transactions

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Create a good initial design • Define a tuning methodology • Perform production tuning • Establish quantifiable goals • List tuning problems • Decide between performance and safety

Copyright © 2003, Oracle. All rights reserved.


Diagnostic and Tuning Tools

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Identify key tuning components of the alert log file • Identify key tuning components of background trace files • Identify key tuning components of user trace files • Collect statistics with Oracle Enterprise Manager • Describe how Statspack collects statistics • Collect statistics with Statspack • Identify dynamic performance views useful in tuning • Describe other tools used for tuning Copyright © 2003, Oracle. All rights reserved.


Maintenance of the Alert Log File

• •

The alert log file consists of a chronological log of messages and errors. Check the alert log file regularly to: – Detect internal errors (ORA-600) and block corruption errors – Monitor database operations – View the nondefault initialization parameters

Remove or trim the file regularly after checking.

Copyright © 2003, Oracle. All rights reserved.


Tuning Components of the Alert Log File

The alert log file contains the following information which can be used in tuning the database: • Checkpoint start and end times • Incomplete checkpoints • Time to perform archiving • Instance recovery start and complete times • Deadlock and timeout errors

Copyright © 2003, Oracle. All rights reserved.


Background Processes Trace Files

• •

The Oracle server dumps information about errors detected by any background process into trace files. Oracle Support uses these trace files to diagnose and troubleshoot. These files do not usually contain tuning information.

Copyright © 2003, Oracle. All rights reserved.


User Trace Files

• • • •

Server process tracing can be enabled or disabled at the session or instance level. A user trace file contains statistics for traced SQL statements in that session. User trace files are created on a per server process basis. User trace files can also be created by: – Backup control file to trace – Database SET EVENTs

Copyright © 2003, Oracle. All rights reserved.


Views, Utilities, and Tools

Tools and views that are available to the DBA for determining performance: • Oracle Enterprise Manager • Diagnostics and tuning packs • Statspack • v$xxx dynamic troubleshooting and performance views • dba_xxx dictionary views • •

Oracle wait events utlbstat.sql and utlestat.sql scripts

Copyright © 2003, Oracle. All rights reserved.


Oracle Enterprise Manager Console

Copyright Š 2003, Oracle. All rights reserved.


Performance Manager

Copyright Š 2003, Oracle. All rights reserved.


Overview of Oracle Expert Tuning Methodology Specify tuning scope Collect data View and edit data and rules Analyze data Review recommendations Implement recommendations

Copyright Š 2003, Oracle. All rights reserved.


Tuning Using Oracle Expert

Copyright Š 2003, Oracle. All rights reserved.


Tuning Using Oracle Expert

Copyright Š 2003, Oracle. All rights reserved.


Statspack

• • • • •

Installation of Statspack using the spcreate.sql script Collection of statistics execute statspack.snap Automatic collection of statistics using the spauto.sql script Produce a report using the spreport.sql script To collect timing information, set TIMED_STATISTICS = True

Copyright © 2003, Oracle. All rights reserved.


Statspack Output

Information found on the first page: • Database and instance name • Time at which the snapshots were taken • Current sizes of the caches • Load profile • Efficiency percentages of the instance • Top five wait events

Copyright © 2003, Oracle. All rights reserved.


Statspack Output

Information found in the remainder of the document: • Complete list of wait events • Information on SQL statements currently in the pool • Instance activity statistics • Tablespace and file I/O • Buffer pool statistics

Copyright © 2003, Oracle. All rights reserved.


Statspack Output

Information found in the remainder of the document: • Rollback or undo segment statistics • Latch activity • Dictionary cache statistics • Library cache statistics • System Global Area (SGA) statistics • Startup values for initialization parameters

Copyright © 2003, Oracle. All rights reserved.


Dictionary and Special Views

The following dictionary and special views provide useful statistics after using the dbms_stats package: • dba_tables, dba_tab_columns • dba_clusters • dba_indexes, index_stats • index_histogram, dba_tab_histograms This statistical information is static until you reexecute dbms_stats.

Copyright © 2003, Oracle. All rights reserved.


Displaying Systemwide Statistics v$sysstat • statistic# • name • class • value

v$event_name • event number • name • parameter1 • parameter2 • parameter3

v$sgastat • pool • name • bytes

v$system_event • event • total_waits • total_timeouts • time_waited • average_wait

Copyright © 2003, Oracle. All rights reserved.


Displaying Session-Related Statistics v$statname

v$sesstat • sid • statistic# • value

• statistic# • name • class

v$session_event • sid • event • total_waits • total_timeouts • time_waited • average_wait • max_wait

v$event_name • event# • name • parameter1 • parameter2 • parameter3

v$session • sid • serial# • username • osuser

v$session_wait • sid • seq# • event • p1/2/3 • p1/2/3 text • p1/2/3 raw • wait time • seconds_in_wait • state

Copyright © 2003, Oracle. All rights reserved.


Oracle Wait Events

A collection of wait events provides information on the sessions that had to wait or must wait for different reasons. These events are listed in the v$event_name view, which has the following columns: – – – – –

EVENT# NAME PARAMETER1 PARAMETER2 PARAMETER3

Copyright © 2003, Oracle. All rights reserved.


The v$event_name View

SQL> SELECT name, parameter1, parameter2, parameter3 2 FROM v$event_name; NAME

PARAMETER1

PARAMETER2

PARAMETER3

-------------------------------

----------

----------

----------

PL/SQL lock timer

duration

alter system set mts_dispatcher

waited

buffer busy waits

file#

block#

id

library cache pin

handle addr pin address 0*mode+name

log buffer space log file switch (checkpoint incomplete) transaction

undo seg#

wrap#

... 286 rows selected.

Copyright Š 2003, Oracle. All rights reserved.

count


Statistics Event Views

• • •

v$session_event: Waits for an event for each session that had to wait v$session_wait: Waits for an event for current active sessions that are waiting v$system_event: Total waits for an event, all sessions together

Copyright © 2003, Oracle. All rights reserved.


The v$session_event View

SQL> SELECT sid, event, total_waits,average_wait 2 FROM v$session_event 3 WHERE sid=10; SID ---10 10 10 10 10 10

EVENT TOTAL_WAITS AVERAGE_WAIT ------------------------------ ----------- ------------buffer busy waits 12 5 db file sequential read 129 0 file open 1 0 SQL*Net message to client 77 0 SQL*Net more data to client 2 0 SQL*Net message from client 76 0

Copyright Š 2003, Oracle. All rights reserved.


The v$session_wait View

SQL> SELECT sid, seq#, event, wait_time, state 2 FROM v$session_wait; SID

SEQ#

EVENT

---- ------ --------------------------1 1284 pmon timer 2 1697 rdbms ipc message 3 183 rdbms ipc message 4 4688 rdbms ipc message 5 114 smon timer 6 14 SQL*Net message from client

Copyright Š 2003, Oracle. All rights reserved.

WAIT TIME ----0 0 0 0 0 -1

STATE ------WAITING WAITING WAITING WAITING WAITING WAITED SHORT TIME


The v$system_event View

SQL> 2 3 4

SELECT event, total_waits, total_timeouts, time_waited, average_wait FROM v$system_event ORDER BY time_waited DESC;

EVENT ----------------latch free pmon timer process startup buffer busy waits ... 34 rows selected.

TOTAL_ WAITS -----5 932 3 12

TOTAL_ TIMEOUTS -------5 535 0

TIME_ WAITED -----5 254430 8 5

Copyright Š 2003, Oracle. All rights reserved.

AVERAGE_ WAIT ---------1 272.993562 2.66666667 5


Dynamic Troubleshooting and Performance Views V$ views: • Based on X$ tables • Listed in v$fixed_table X$ tables: • Not usually queried directly • Dynamic and constantly changing • Names abbreviated and obscure Populated at startup and cleared at shutdown

Copyright © 2003, Oracle. All rights reserved.


Troubleshooting and Tuning Views

Instance/Database v$database v$instance v$option v$parameter v$backup v$px_process_sysstat v$process v$waitstat v$system_event

Disk v$datafile v$filestat v$log v$log_history v$dbfile v$tempfile v$tempstat v$segment_statistics Contention v$lock v$rollname v$rollstat v$waitstat v$latch

Copyright Š 2003, Oracle. All rights reserved.


Troubleshooting and Tuning Views Memory v$buffer_pool_statistics v$db_object_cache v$librarycache v$rowcache v$sysstat v$sgastat User/Session v$lock v$open_cursor v$process v$transaction v$px_sesstat v$px_session

v$sesstat v$session_event v$sort_usage v$session_wait v$session v$session_object_cache

Copyright Š 2003, Oracle. All rights reserved.


utlbstat and utlestat Scripts

• • • •

Gather performance figures over a defined period. Produce a hard-copy report. Should set TIMED_STATISTICS to True. Execute from SQL*Plus connected as SYSDBA.

Statspack provides clearer statistics.

Copyright © 2003, Oracle. All rights reserved.


DBA-Developed Tools

• • • • •

Develop your own scripts. Use the supplied packages for tuning. Schedule periodic performance checking. Take advantage of the Enterprise Manager Event service to track specific situations. Take advantage of the Oracle Enterprise Manager Job service to: – Automate the regular execution of administrative tasks. – Apply tasks that automatically solve problems detected by the Oracle Enterprise Manager event service. Copyright © 2003, Oracle. All rights reserved.


Level of Statistics Collection

The initialization parameters that determine the level of statistic collection are: • STATISTICS_LEVEL • TIMED_STATISTICS • TIMED_OS_STATISTICS • DB_CACHE_ADVICE

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Use the alert log file • Get information from background processes trace files • Trace user SQL statements • Collect statistics from dictionary and dynamic performance troubleshooting views • Use the Statspack utility to collect performance data • Retrieve wait events information

Copyright © 2003, Oracle. All rights reserved.


Database Configuration and I/O Issues

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • List the advantages of distributing different Oracle file types • Diagnose tablespace usage problems • List reasons for partitioning data in tablespaces • Describe how checkpoints work • Monitor and tune checkpoints • Monitor and tune redo logs

Copyright © 2003, Oracle. All rights reserved.


Oracle Processes and Files

Process

Oracle file I/O Data files Log

CKPT

Read/Write

DBWn

Write

Archive

Control Read/Write

LGWR

Write

ARCn

Read

Write

Read/Write

Read

Write

Read/Write

SERVER

Read/write

Read/Write

Copyright Š 2003, Oracle. All rights reserved.


Performance Guidelines

Basic performance rules are as follows: • Keep disk I/O to a minimum. • Spread your disk load across disk devices and controllers. • Use temporary tablespaces where appropriate.

Copyright © 2003, Oracle. All rights reserved.


Distributing Files Across Devices

• • •

Separate data files and redo log files. Stripe table data. Reduce disk I/O unrelated to the database.

Copyright © 2003, Oracle. All rights reserved.


IO Topology Support

Copyright Š 2003, Oracle. All rights reserved.


Tablespace Usage

• • • • • •

Reserve the system tablespace for data dictionary objects. Create locally managed tablespaces to avoid space management issues. Split tables and indexes into separate tablespaces. Create rollback segments in their own tablespaces. Store very large objects in their own tablespace. Create one or more temporary tablespaces.

Copyright © 2003, Oracle. All rights reserved.


Locally Managed system Tablespace

Create databases that have a locally managed system tablespace. CREATE DATABASE mydb … DATAFILE 'system01.dbf' SIZE 100M EXTENT MANAGEMENT LOCAL … DEFAULT TEMPORARY TABLESPACE temp TEMPFILE 'temp01.dbf' SIZE 15M …;

Copyright © 2003, Oracle. All rights reserved.


Diagnostic Tools for Checking I/O Statistics

System I/O utilization

Server I/O utilization

v$filestat v$tempstat v$datafile Data files

Performance tools

Statspack Copyright Š 2003, Oracle. All rights reserved.


Using the v$filestat View SQL> 2 3 4

SELECT phyrds, phywrts, d.name FROM v$datafile d, v$filestat f WHERE d.file#=f.file# ORDER BY d.name;

PHYRDS PHYWRTS ---------- -------806 116 168 675 8 8 26 257 65012 564 8 8 6 rows selected

NAME -------------------/…/u01/system01.dbf /…/u04/temp01.dbf /…/u02/sample01.dbf /…/u02/undots01.dbf /…/u03/users01.dbf /…/u01/query01.dbf

Copyright © 2003, Oracle. All rights reserved.


Performance Manager: I/O Statistics

Copyright Š 2003, Oracle. All rights reserved.


I/O Statistics SQL> SELECT d.tablespace_name TABLESPACE, 2 d.file_name, f.phyrds, f.phywrts 3 FROM v$filestat f, dba_data_files d 4 WHERE f.file# = d.file_id; TABLESPACE FILE_NAME PHYRDS PHYWRTS ------------- ----------------- ------ ------UNDO1 /u02/undots01.dbf 26 257 SAMPLE /u02/sample01.dbf 65012 564 USERS /u03/users01.dbf 8 8 SYSTEM /u01/system01.dbf 806 116 TEMP /u04/temp01.dbf 168 675 QUERY_DATA /u01/query01.dbf 8 8 6 rows selected. Copyright © 2003, Oracle. All rights reserved.


File Striping

Operating system striping: – Use operating system striping software or a redundant array of inexpensive disks (RAID). – Determine the right stripe size.

Manual striping: Use the CREATE TABLE or ALTER TABLE command with the ALLOCATE clause.

Copyright © 2003, Oracle. All rights reserved.


Tuning Full Table Scan Operations

• •

Investigate the need for full table scans. Configure the DB_FILE_MULTIBLOCK_READ_COUNT initialization parameter to: – Determine the number of database blocks the server reads at once – Influence the execution plan of the cost-based optimizer

Monitor long-running full table scans with v$session_longops view.

Copyright © 2003, Oracle. All rights reserved.


Table Scan Statistics SQL> 2

SELECT name, value FROM v$sysstat WHERE name LIKE '%table scan%';

NAME -------------------------------------table scans (short tables) table scans (long tables) table scans (rowid ranges table scans (cache partitions) table scans (direct read) table scan rows gotten table scan blocks gotten 7 rows selected.

Copyright Š 2003, Oracle. All rights reserved.

VALUE ----125 30 0 0 0 21224 804


Monitoring Full Table Scan Operations

Determine the progress of long operations using:

SQL> SELECT sid, serial#, opname, 2 TO_CHAR(start_time,'HH24:MI:SS') AS "START", 3 (sofar/totalwork)*100 AS PERCENT_COMPLETE 4 FROM v$session_longops;

Use SET_SESSION_LONGOPS to populate v$session_longops.

dbms_application_info.set_session_longops (rindex, slno, "Operation X", obj, 0, sofar, totalwork, "table", "tables");

Copyright © 2003, Oracle. All rights reserved.


Checkpoints

The two most common types of checkpoints are: • Incremental checkpoints – CKPT updates the control file. – During a log switch CKPT updates the control file and the data file headers.

Full checkpoints – CKPT updates the control file and the data file headers. – DBWn writes out all buffers on the checkpoint queue.

Copyright © 2003, Oracle. All rights reserved.


Full Checkpoints

Two categories of full checkpoints • Complete • Tablespace

Copyright © 2003, Oracle. All rights reserved.


Performance Manager: Response Time

Copyright Š 2003, Oracle. All rights reserved.


Regulating the Checkpoint Queue

Regulate the checkpoint queue with the following initialization parameters: • FAST_START_IO_TARGET • LOG_CHECKPOINT_INTERVAL • LOG_CHECKPOINT_TIMEOUT • FAST_START_MTTR_TARGET

Copyright © 2003, Oracle. All rights reserved.


Defining and Monitoring Fast Start Checkpointing Use v$instance_recovery to obtain the following information: • RECOVERY_ESTIMATED_IOS • LOG_FILE_SIZE_REDO_BLKS • LOG_CHKPT_TIMEOUT_REDO_BLKS • LOG_CHKPT_INTERVAL_REDO_BLKS • TARGET_MTTR • ESTIMATED_MTTR

Copyright © 2003, Oracle. All rights reserved.


Redo Log Groups and Members LGWR

Group 1

Group 2

Group 3 Disk 1

Member

Member

Member

Disk 2 Member

Member

Copyright Š 2003, Oracle. All rights reserved.

Member


Online Redo Log File Configuration

• • • •

Size redo log files to minimize contention. Provide enough groups to prevent waiting. Store redo log files on separate, fast devices. Monitor the redo log file configuration with: – v$logfile – v$log – v$log_history

Copyright © 2003, Oracle. All rights reserved.


Increasing the Performance of Archiving

Allow the LGWR process to write to a disk different from the one the ARCn process is reading.

Share the archiving work during a temporary increase in workload:

ALTER SYSTEM ARCHIVE LOG ALL TO <log_archive_dest>

• •

Increase the number of archive processes. Change archiving speed: – LOG_ARCHIVE_MAX_PROCESSES – LOG_ARCHIVE_DEST_n Copyright © 2003, Oracle. All rights reserved.


Diagnostic Tools

v$archive_dest v$archived_log v$archive_processes

LOG_ARCHIVE_DEST_STATE_n

Copyright Š 2003, Oracle. All rights reserved.

Archived logs


Summary

In this lesson, you should have learned how to: • List the advantages of distributing different Oracle file types • Diagnose tablespace usage problems • List reasons for segmenting data in tablespaces • Describe how checkpoints work • Monitor and tune checkpoints • Monitor and tune archive logging

Copyright © 2003, Oracle. All rights reserved.


Tuning the Shared Pool

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Determine the size of an object and pin it in the shared pool • Tune the shared pool reserved space • Describe the user global area (UGA) and session memory considerations • Measure the library cache hit ratio • List other tuning issues related to the shared pool • Measure the dictionary cache hit ratio • Set the large pool

Copyright © 2003, Oracle. All rights reserved.


Shared Pool Contents Major components of the shared pool are: • Library cache • Data dictionary cache • User global area (UGA) for shared server sessions Database buffer cache

Redo log buffer

Shared pool Library cache

Large pool UGA

Data dictionary cache

User global area

Copyright © 2003, Oracle. All rights reserved.


Shared Pool • • •

Defined by SHARED_POOL_SIZE Library cache contains statement text, parsed code, and execution plan. Data dictionary cache contains definitions for tables, columns, and privileges from the data dictionary tables. UGA contains session information for Oracle Shared Server users when a large pool is not configured. Shared pool Shared pool

Library cache Shared Datapool dictionary cache UGA

Copyright © 2003, Oracle. All rights reserved.


The Library Cache

• • • •

Used to store SQL statements and PL/SQL blocks that are to be shared by users Managed by a least recently used (LRU) algorithm Used to prevent statements reparsing Reports error ORA-04031 if the shared pool is out of free memory

Copyright © 2003, Oracle. All rights reserved.


The Library Cache

Shared SQL, PL/SQL areas Context area for SELECT statement 2

Context area for SELECT statement 1

SELECT statement 2

SELECT statement 1

Copyright Š 2003, Oracle. All rights reserved.

SELECT statement 1


Important Shared Pool Latches

• •

shared pool: Protects memory allocations in the shared pool library cache: Locates matching SQL in the shared pool

Copyright © 2003, Oracle. All rights reserved.


Shared Pool and Library Cache Latches

Contention for shared pool latch and library cache latch indicates one or more of the following: • Unshared SQL • Reparsed sharable SQL • Insufficiently sized library cache

Copyright © 2003, Oracle. All rights reserved.


Tuning the Library Cache

Reduce misses by keeping parsing to a minimum: • Make sure that users can share statements. • Prevent statements from being aged out by allocating enough space. • Avoid invalidations that induce reparsing.

Copyright © 2003, Oracle. All rights reserved.


Tuning the Library Cache

Avoid fragmentation by: • Reserving space for large memory requirements • Pinning frequently required large objects • Eliminating large anonymous PL/SQL blocks • Enabling the use of large pool for Oracle Shared Server connections

Copyright © 2003, Oracle. All rights reserved.


Terminology

• • •

Gets: (Parse) The number of lookups for objects of the namespace Pins: (Execution) The number of reads or executions of the objects of the namespace Reloads: (Parse) The number of library cache misses on the execution step, thereby causing an implicit reparsing of the SQL statement Invalidations: (Parse) If an object is modified then all explain plans that reference the object are marked invalid and must be parsed again

Copyright © 2003, Oracle. All rights reserved.


Diagnostic Tools for Tuning the Library Cache v$sgastat v$librarycache

Shared pool

Library cache Shared SQL

sp_m_n.lst

v$sql

and PL/SQL

Views v$sqlarea v$sqltext v$db_object_cache

report.txt Data dictionary cache UGA

Parameters affecting the components: SHARED_POOL_SIZE, OPEN_CURSORS SESSION_CACHED_CURSORS, CURSOR_SPACE_FOR_TIME CURSOR_SHARING, SHARED_POOL_RESERVED_SIZE Copyright Š 2003, Oracle. All rights reserved.


Are Cursors Being Shared?

Check gethitration in v$librarycache: SQL> SELECT gethitratio 2 FROM v$librarycache 3 WHERE namespace = 'SQL AREA';

Determine which statements users are running: SQL> SELECT sql_text, users_executing, 2 executions, loads 3 FROM v$sqlarea; SQL> SELECT * FROM v$sqltext 2 WHERE sql_text LIKE 3 'SELECT * FROM hr.employees WHERE %';

Copyright © 2003, Oracle. All rights reserved.


Sharing Cursors

Values for CURSOR_SHARING are: • • •

Exact Similar Force

Copyright © 2003, Oracle. All rights reserved.


Guidelines: Library Cache Reloads

Reloads should be less than 1% of the pins: SQL> SELECT SUM(pins) "Executions", 2 SUM(reloads) "Cache Misses", 3 SUM(reloads)/SUM(pins) 4 FROM v$librarycache;

If the reloads-to-pins ratio is greater than 1%, increase the value of the SHARED_POOL_SIZE parameter. Executes PROC1 —> 1st pin, 1 load Executes PROC1 —> 2nd pin, no reload Executes PROC1 —> 3rd pin, no reload Executes PROC1 —> 4th pin, no reload

Copyright © 2003, Oracle. All rights reserved.

4 pins and no reloads


Invalidations The number of times objects of the namespace were marked invalid, causing reloads: SQL> SQL> 2 3 SQL> > SQL> SQL> 2 3

SELECT count(*) FROM hr.employees; SELECT namespace,pins,reloads, invalidations FROM v$librarycache; execute dbms_stats.gather_table_stats ('HR','EMPLOYEES'); SELECT count(*) FROM hr.employees; SELECT namespace,pins,reloads, invalidations FROM v$librarycache; Copyright Š 2003, Oracle. All rights reserved.


Sizing the Library Cache

• • • • •

Define the global space necessary for stored objects (packages, views, and so on). Define the amount of memory used by the usual SQL statements. Reserve space for large memory requirements to avoid misses and fragmentation. Pin frequently used objects. Convert large anonymous PL/SQL blocks into small anonymous blocks calling packaged functions.

Copyright © 2003, Oracle. All rights reserved.


Shared Pool Advisory SQL> SELECT shared_pool_size_for_estimate AS 2 pool_size, estd_lc_size, 3 estd_lc_time_saved 4 FROM v$shared_pool_advice; POOL_SIZE ESTD_LC_SIZE ESTD_LC_TIME_SAVED ---------- ------------ -----------------32 8 7868 40 15 7868 48 17 7868 56 17 7868 64 17 7868 72 17 7868 80 17 7868 88 17 7868 Copyright Š 2003, Oracle. All rights reserved.


Oracle Enterprise Manager Shared Pool Size Advisor

Copyright Š 2003, Oracle. All rights reserved.


Cached Execution Plans

• •

The Oracle server preserves the execution plan of a cached SQL statement in memory. When the SQL statement ages out of the library cache, the corresponding cached execution plan is removed. You can use the cached plans to diagnose query performance.

Copyright © 2003, Oracle. All rights reserved.


Views to Support Cached Execution Plans You can use the v$sql_plan dynamic performance view to view the actual execution plan information for cached cursors. SQL> SELECT operation, object_owner, 2 object_name, cost 3 FROM v$sql_plan 4 ORDER BY hash_value;

Copyright Š 2003, Oracle. All rights reserved.


Support for Cached Execution Plans

The v$sql view has a column, plan_hash_value, which references the hash_value column of v$sql_plan.

The column information is a hash value built from the corresponding execution plan. The column can be used to compare cursor plans the same way the hash_value column is used to compare cursor SQL texts.

Copyright © 2003, Oracle. All rights reserved.


Global Space Allocation

Stored objects such as packages and views: SQL> SELECT SUM(sharable_mem) 2 FROM v$db_object_cache; SUM(SHARABLE_MEM) ----------------379600 SQL statements: SQL> SELECT SUM(sharable_mem) 2 FROM v$sqlarea WHERE executions > 5; SUM(SHARABLE_MEM) ----------------381067 Copyright Š 2003, Oracle. All rights reserved.


Large Memory Requirements

• •

Satisfy requests for large contiguous memory Reserve contiguous memory within the shared pool Shared pool

v$shared_pool_reserved

Library cache Shared SQL and PL/SQL

SHARED_POOL_SIZE SHARED_POOL_RESERVED_SIZE

Data dictionary cache

UGA

Copyright © 2003, Oracle. All rights reserved.


Tuning the Shared Pool Reserved Space •

Diagnostic tools for tuning: – The v$shared_pool_reserved dictionary view – The supplied aborted_request_threshold procedure in the dbms_shared_pool package

Guidelines: Set the SHARED_POOL_RESERVED_SIZE parameter

Copyright © 2003, Oracle. All rights reserved.


Keeping Large Objects

Find those PL/SQL objects that are not kept in the library cache: SQL> 2 3 4 5

SELECT * FROM v$db_object_cache WHERE sharable_mem > 10000 AND (type='PACKAGE' OR type='PACKAGE BODY' OR type='FUNCTION' OR type='PROCEDURE') AND kept='NO';

Pin large packages in the library cache: SQL> EXECUTE dbms_shared_pool.keep(‘package_name’);

Copyright © 2003, Oracle. All rights reserved.


Anonymous PL/SQL Blocks

Find the anonymous PL/SQL blocks and convert them into small anonymous PL/SQL blocks that call packaged functions: SQL> SELECT sql_text FROM v$sqlarea 2 WHERE command_type = 47 3 AND length(sql_text) > 500;

Copyright Š 2003, Oracle. All rights reserved.


Other Parameters Affecting the Library Cache • • • •

OPEN_CURSORS CURSOR_SPACE_FOR_TIME SESSION_CACHED_CURSORS CURSOR_SHARING

Copyright © 2003, Oracle. All rights reserved.


Tuning the Data Dictionary Cache

Use v$rowcache to obtain information about the data dictionary cache. • Content: Definitions of dictionary objects • Terminology: – gets: Number of requests on objects – getmisses: Number of requests resulting in cache misses

Tuning: Avoid dictionary cache misses

Copyright © 2003, Oracle. All rights reserved.


Diagnostic Tools for Tuning the Data Dictionary Cache Shared pool

Library cache v$rowcache: parameter gets getmisses

Shared SQL and PL/SQL Data dictionary cache UGA

SHARED_POOL_SIZE

Copyright Š 2003, Oracle. All rights reserved.

Sp_1_2.lst


Measuring the Dictionary Cache Statistics

In the Dictionary Cache Stats section of Statspack: •

Percent misses should be very low: – < 2% for most data dictionary objects – < 15% for the entire data dictionary cache

• •

Cache Usage is the number of cache entries being used. Pct SGA is a percentage of usage to allocated size for that cache.

Copyright © 2003, Oracle. All rights reserved.


Tuning the Data Dictionary Cache

Keep the percentage of the sum of getmisses to the sum of gets less than 15%: SQL> SELECT parameter, gets, getmisses 2 FROM v$rowcache; PARAMETER GETS GETMISSES -------------------------- --------- --------dc_objects 143434 171 dc_synonyms 140432 127

Copyright Š 2003, Oracle. All rights reserved.


Guidelines: Dictionary Cache Misses

Statspack report output: (font size incorrect) Get Cache

Requests

Pct Miss

Scan Reqs

Pct

Mod

Miss

Reqs

Final Usage

Pct SGA

------------------ --------- ------ ----- ----- ----- ------ ---dc_free_extents

2

0.

0

0

3

3

dc_histogram_defs

11

0.0

0

0

49

92

dc_object_ids

19

0.0

0

0

440

98

If there are too many cache misses, increase the SHARED_POOL_SIZE parameter.

Copyright Š 2003, Oracle. All rights reserved.


Performance Manager: Shared Pool Statistics

Copyright Š 2003, Oracle. All rights reserved.


UGA and Oracle Shared Server Dedicated server configuration

PGA Stack space

Shared pool

UGA User Cursor session state data

Shared server configuration Shared pool or large pool

v$statname v$sesstat v$mystat

UGA User Cursor session state data

PGA Stack space

OPEN_CURSORS SESSION_CACHED_CURSORS

Copyright Š 2003, Oracle. All rights reserved.


Determining the User Global Area Size •

UGA space used by your connection: SQL> SELECT SUM(value) ||'bytes' "Total session 2 3 4

FROM v$mystat, v$statname WHERE name = 'session uga memory' AND v$mystat.statistic# = v$statname.statistic#;

UGA space used by all Oracle Shared Server users:

SQL> 2 3 4

memory"

SELECT SUM(value) ||'bytes' "Total session memory" FROM v$sesstat, v$statname WHERE name = 'session uga memory' AND v$sesstat.statistic# = v$statname.statistic#;

Maximum UGA space used by all users:

SQL> 2 3 4

SELECT SUM(value) ||'bytes' "Total max memory" FROM v$sesstat, v$statname WHERE name = 'session uga memory max' AND v$sesstat.statistic# = v$statname.statistic#;

Copyright © 2003, Oracle. All rights reserved.


Large Pool •

Can be configured as a separate memory area in the SGA, used for memory with: – – – –

• •

I/O server processes: DBWR_IO_SLAVES Backup and restore operations Session memory for the shared servers Parallel query messaging

Used to avoid performance overhead caused by shrinking the shared SQL cache Sized by the parameter LARGE_POOL_SIZE Database Redo buffer cache log buffer

Shared pool Library cache Data dictionary cache User global area

Copyright © 2003, Oracle. All rights reserved.

Large pool


Summary

In this lesson, you should have learned how to: • Size shared SQL and PL/SQL areas (library cache) • Size data dictionary cache or row cache • Size the large pool • Allow for the user global area, if using Oracle Shared Server connections

Copyright © 2003, Oracle. All rights reserved.


Tuning the Buffer Cache

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Employ the buffer cache sizing advisor • Describe how the buffer cache is used by different Oracle processes • Create and manage different buffer caches • Monitor the use of the buffer caches • Identify and resolve buffer cache performance problems

Copyright © 2003, Oracle. All rights reserved.


Buffer Cache Characteristics DB buffer cache

SGA Server

LRU lists

Checkpoint Queue

. . . .

. . . .

DBWn

DB_BLOCK_SIZE DB_CACHE_SIZE DB_KEEP_CACHE_SIZE DB_RECYCLE_CACHE_SIZE DB_BLOCK_CHECKSUM

Data files Copyright © 2003, Oracle. All rights reserved.


Buffer Cache Sizing Parameters

The buffer cache can consist of independent subcaches for buffer pools and for multiple block sizes. The DB_BLOCK_SIZE parameter determines the primary block size, which is the block size used for the system tablespace and the primary buffer caches (recycle, keep, and default). The following parameters define the sizes of the caches for buffers for the primary block size: – DB_CACHE_SIZE – DB_KEEP_CACHE_SIZE – DB_RECYCLE_CACHE_SIZE

Copyright © 2003, Oracle. All rights reserved.


Dynamic Buffer Cache Advisory Parameter •

The buffer cache advisory feature enables and disables statistics gathering for predicting behavior with different cache sizes. DBAs can use the information provided by these statistics to size the buffer cache optimally for a given workload. The buffer cache advisory is enabled by means of the DB_CACHE_ADVICE initialization parameter: – This parameter is dynamic and can be changed using ALTER SYSTEM. – Three values are allowed: Off, On, and Ready.

Copyright © 2003, Oracle. All rights reserved.


View to Support Buffer Cache Advisory

Buffer cache advisory information is collected in the v$db_cache_advice view.

The view contains different rows that estimate the number of physical reads for different caches. The rows also compute a physical read factor, which is the ratio of the number of estimated reads to the number of actual reads.

Copyright © 2003, Oracle. All rights reserved.


Using the v$db_cache_advice View

SQL> 2 3 4 4 5 6 7 8 9 10 11

SELECT size_for_estimate "Cache Size (MB)", buffers_for_estimate "Buffers", estd_physical_read_factor AS "Estd Phys Read Factor", estd_physical_reads "Estd Phys Reads" FROM v$db_cache_advice WHERE name = 'DEFAULT' AND block_size = ( SELECT value FROM v$parameter WHERE name = 'db_block_size') AND advice_status = 'ON';

Copyright Š 2003, Oracle. All rights reserved.


Using the Buffer Cache Advisory

Copyright Š 2003, Oracle. All rights reserved.


Managing the Database Buffer Cache SGA Server

2

1

LRU lists

Checkpoint Queue

. . . .

. . . .

DB buffer cache

2 3 4

DBWn Data files Copyright Š 2003, Oracle. All rights reserved.

LGWR


Managing the Database Buffer Cache DB buffer cache

SGA Server

LRU lists

Checkpoint Queue

. . . .

. . . .

DBWn

LGWR

Data files Copyright Š 2003, Oracle. All rights reserved.


Tuning Goals and Techniques •

Tuning goals: – Servers find data in memory – No waits on the buffer cache

Diagnostic measures – Wait events – Cache hit ratio – The v$db_cache_advice view

Tuning techniques: – Reduce the number of blocks required by SQL statements – Increase buffer cache size – Use multiple buffer pools – Cache tables – Bypass the cache for sorting and parallel reads Copyright © 2003, Oracle. All rights reserved.


Diagnostic Tools v$sysstat v$buffer_pool_statistics v$buffer_pool v$db_cache_advice

SGA LRU list

Checkpoint queue Buffer cache

v$sesstat v$system_event v$session_wait v$bh v$cache

Keep buffer pool Recycle buffer pool

DB_CACHE_SIZE DB_KEEP_CACHE_SIZE DB_RECYCLE_CACHE_SIZE Copyright Š 2003, Oracle. All rights reserved.

Statspack Report


Performance Manager

Copyright Š 2003, Oracle. All rights reserved.


Buffer Cache Performance Indicators

From v$sysstat: SQL> SELECT name, value 2 FROM v$sysstat 3 WHERE name = 'free buffer inspected'; NAME VALUE --------------------------- -------free buffer inspected 183

Copyright Š 2003, Oracle. All rights reserved.


More Buffer Cache Performance Indicators

From v$system_event: SQL> SELECT event, total_waits 2 FROM v$system_event 3 WHERE event in 4 ('free buffer waits', 5 'buffer busy waits'); EVENT TOTAL_WAITS ---------------------- ----------free buffer waits 337 buffer busy waits 3466

Copyright Š 2003, Oracle. All rights reserved.


Measuring the Cache Hit Ratio •

From v$sysstat: SQL> 2 3 4 5 6 7 8

SELECT 1 - (phy.value - lob.value - dir.value) / ses.value "CACHE HIT RATIO" FROM v$sysstat ses, v$sysstat lob, v$sysstat dir, v$sysstat phy WHERE ses.name = 'session logical reads' AND dir.name = 'physical reads direct' AND lob.name = 'physical reads direct (lob)' AND phy.name = 'physical reads';

From the Statspack report: Statistic

Total Per Per Trans Logon Second ------------------------- -------- ------ -------physical reads 15,238 13.0 15,238.0 physical reads direct 863 0.7 863.0 Physical reads direct(lob) 0 0 0 session logical reads 119,376 101.8 119,376.0

Copyright © 2003, Oracle. All rights reserved.


Guidelines for Using the Cache Hit Ratio

Hit ratio is affected by data access methods: • Full table scans • Data or application design • Large table with random access • Uneven distribution of cache hits

Copyright © 2003, Oracle. All rights reserved.


Buffer Cache Hit Ratio Isn’t Everything

• • • •

A badly tuned database can still have a hit ratio of 99% or better. Hit ratio is only one part in determining tuning performance. Hit ratio does not determine whether a database is optimally tuned. Use the Oracle Wait Interface to examine what is causing a bottleneck. – v$session_wait – v$session_event – v$system_event

Tune SQL statements. Copyright © 2003, Oracle. All rights reserved.


Guidelines to Increase the Cache Size

Increase the cache size ratio under the following conditions: • Any wait events have been tuned • SQL statements have been tuned • There is no undue page faulting • The previous increase of the buffer cache was effective • Low cache hit ratio

Copyright © 2003, Oracle. All rights reserved.


Using Multiple Buffer Pools SGA DB buffer caches

Recycle pool

Keep pool

Default pool

Copyright Š 2003, Oracle. All rights reserved.


Defining Multiple Buffer Pools

In the Oracle database: • Individual pools have their own size defined by: – DB_CACHE_SIZE – DB_KEEP_CACHE_SIZE – DB_RECYCLE_CACHE_SIZE • •

These parameters are dynamic. Latches are automatically allocated by Oracle RDBMS.

Copyright © 2003, Oracle. All rights reserved.


Enabling Multiple Buffer Pools

CREATE INDEX cust_idx … STORAGE (BUFFER_POOL KEEP …); ALTER TABLE customer STORAGE (BUFFER_POOL RECYCLE); ALTER INDEX cust_name_idx STORAGE (BUFFER_POOL KEEP);

Copyright © 2003, Oracle. All rights reserved.


KEEP Buffer Pool Guidelines • • •

Tuning goal: Keeping blocks in memory Size: Holds all or nearly all blocks of the segments assigned to this pool Tool: dbms_stats.gather_table_stats SQL> EXECUTE dbms_stats.gather_table_stats > ('HR','DEPARTMENTS'); SQL> 2 3 4

SELECT table_name, blocks FROM dba_tables WHERE owner = 'HR' AND table_name = 'DEPARTMENTS';

TABLE_NAME BLOCKS ---------- ---------DEPARTMENTS 1 Copyright © 2003, Oracle. All rights reserved.


RECYCLE Buffer Pool Guidelines

• • •

Tuning goal: Eliminate blocks from memory when transactions are completed Size: Holds only active blocks Tool: v$cache SQL> SELECT owner#, name, count(*) blocks 2 FROM v$cache 3 GROUP BY owner#, name; OWNER# NAME BLOCKS ------ ---------- ---------5 CUSTOMER 147

Copyright © 2003, Oracle. All rights reserved.


RECYCLE Buffer Pool Guidelines

Tool: v$sess_io SQL> SELECT s.username, io.block_gets, 2 io.consistent_gets, io.physical_reads 3 FROM v$sess_io io, v$session s 4 WHERE io.sid = s.sid ; USERNAME -------HR

BLOCK_GETS CONSISTENT_GETS PHYSICAL_READS ---------- --------------- -------------21874 2327 1344

Copyright © 2003, Oracle. All rights reserved.


Calculating the Hit Ratio for Multiple Pools

SQL> 2 3 4

SELECT name, 1 - (physical_reads / (db_block_gets + consistent_gets)) "HIT_RATIO" FROM v$buffer_pool_statistics WHERE db_block_gets + consistent_gets > 0;

NAME HIT_RATIO ------------------ ---------KEEP .983520845 RECYCLE .503866235 DEFAULT .790350047

Copyright Š 2003, Oracle. All rights reserved.


Identifying Candidate Pool Segments

Keep pool – Blocks are accessed repeatedly. – Segment size is less than 10% of the default buffer pool size.

Recycle pool – Blocks are not reused outside of transaction. – Segment size is more than twice the default buffer pool size.

Copyright © 2003, Oracle. All rights reserved.


Dictionary Views with Buffer Pool Information SQL> SELECT id, name, block_size, buffers 2 FROM v$buffer_pool; ID -1 2 3

NAME block_size BUFFERS ------- ---------- -------KEEP 4096 14000 RECYCLE 4096 2000 DEFAULT 4096 4000

Copyright Š 2003, Oracle. All rights reserved.


Automatic Segment Space Management

Manages free space automatically inside database segments

Tracks segment free/used space with bitmaps instead of free lists

Provides better space utilization, especially for the objects with highly varying size rows

Specified when creating a tablespace

Supported by Oracle Enterprise Manager

Copyright © 2003, Oracle. All rights reserved.


Auto-Management of Free Space

Create an auto-managed tablespace: CREATE TABLESPACE BIT_SEG_TS DATAFILE '$HOME/ORADATA/u04/bit_seg01.dbf' SIZE 1M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

Create a table that uses auto-management of free space: CREATE TABLE bit_seg_table (idnum NUMBER) TABLESPACE bit_seg_ts;

Copyright © 2003, Oracle. All rights reserved.


Free Lists

• • • • •

A free list for an object maintains a list of blocks that are available for inserts. The number of free lists for an object can be set dynamically. Single-CPU systems do not benefit greatly from multiple free lists. The tuning goal is to ensure that an object has sufficient free lists to minimize contention. Using Automatic Free Space Management eliminates the need for free lists, thus reducing contention on the database.

Copyright © 2003, Oracle. All rights reserved.


Diagnosing Free List Contention v$waitstat columns:

Data SGA buffer cache

CLASS “segment header” COUNT TIME

v$system_event columns:

FREELISTS

EVENT “buffer busy waits” TOTAL_WAITS

Copyright © 2003, Oracle. All rights reserved.


Resolving Free List Contention v$session_wait columns: EVENT “buffer busy waits” P1 “FILE” P2 “BLOCK” P3 “ID” dba_segments columns: SEGMENT_NAME SEGMENT_TYPE FREELISTS HEADER_FILE HEADER_BLOCK

Server process Server process

Data SGA buffer cache

Object ID

FREELISTS

Copyright © 2003, Oracle. All rights reserved.


Multiple DBWn Processes

Multiple DB Writer (DBWn) processes: • Can be deployed with DB_WRITER_PROCESSES (DBW0 to DBW9) •

Can be useful for SMP systems with large numbers of CPUs • Cannot concurrently be used with multiple I/O slaves The DBA can turn asynchronous I/O on or off with the

DISK_ASYNCH_IO parameter.

Copyright © 2003, Oracle. All rights reserved.


Multiple I/O Slaves

• • •

Provide nonblocking asynchronous I/O requests Are typically not recommended if asynchronous I/O is available Follow the naming convention ora_innn_SID

Copyright © 2003, Oracle. All rights reserved.


Tuning DBWn I/O

Tune the DB Writer processes by looking at the value of the FREE BUFFER WAITS event.

Copyright Š 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Employ the buffer cache sizing advisor • Describe how the buffer cache is used by different Oracle processes • Create and manage different buffer caches • Monitor the use of the buffer caches • Identify and resolve buffer cache performance problems

Copyright © 2003, Oracle. All rights reserved.


Dynamic Instance Resizing

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Implement dynamic SGA allocation • Dynamically adjust the buffer caches • Dynamically adjust the shared pool

Copyright © 2003, Oracle. All rights reserved.


Dynamic SGA Feature

• •

The dynamic SGA feature implements an infrastructure to allow the server to change its SGA configuration without shutting down the instance. SGA is limited by SGA_MAX_SIZE. A dynamic SGA can grow and shrink in response to a DBA command.

Copyright © 2003, Oracle. All rights reserved.


Unit of Allocation in the Dynamic SGA

• • • •

In the dynamic SGA model, the unit of memory allocation is called a granule. SGA memory is tracked in granules by SGA components. A granule is a unit of contiguous virtual memory allocation. Use v$buffer_pool to monitor size of the buffer caches.

Copyright © 2003, Oracle. All rights reserved.


Granule

• •

SGA components are allocated and deallocated in units of contiguous memory called granules. The size of a granule depends on the estimated total SGA. If the estimated SGA size is: – Less than or equal to 128 MB then the granule size is 4 MB – Greater than 128 MB then the granule size is 16 MB

Copyright © 2003, Oracle. All rights reserved.


Allocating Granules at Startup

At instance startup, the Oracle server requests SGA_MAX_SIZE bytes of address space in memory.

As startup continues, each component will attempt to acquire the number of granules assigned. The minimum SGA configuration is three granules:

– One granule for fixed SGA (includes redo buffers) – One granule for the buffer cache – One granule for the shared pool

Copyright © 2003, Oracle. All rights reserved.


Adding Granules to Components

A DBA can dynamically increase memory allocation to a component by issuing an ALTER SYSTEM command.

Increasing the memory use of a component succeeds only if there is enough free granules to satisfy the request. Memory granules are not freed automatically from another component to satisfy the increase. Decreasing the size of a component is possible, but only if the granules being released are unused by the component.

• •

Copyright © 2003, Oracle. All rights reserved.


Dynamic Buffer Cache Size Parameters

Parameters that specify the size of buffer cache components are dynamic and can be changed while the instance is running by means of the ALTER SYSTEM command: ALTER SYSTEM SET DB_CACHE_SIZE = 1100M;

• • •

Each parameter is sized independently. New cache sizes are set to the next granule boundary. The allocation size has the following limits: – It must be an integer multiple of the granule size. – The total SGA size cannot exceed SGA_MAX_SIZE. – DB_CACHE_SIZE can never be set to zero. Copyright © 2003, Oracle. All rights reserved.


Example: Increasing the Size of an SGA Component Initial parameter values: • SGA_MAX_SIZE = 128M • DB_CACHE_SIZE = 88M • SHARED_POOL_SIZE = 32M ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

Error message returned: insufficient memory ALTER SYSTEM SET DB_CACHE_SIZE = 56M; ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

• •

Error message returned: insufficient memory Check v$buffer_pool to confirm shrink status. ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

The statement is now processed. Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Implement dynamic SGA allocation • Dynamically adjust the buffer caches • Dynamically adjust the shared pool

Copyright © 2003, Oracle. All rights reserved.


Sizing Other SGA Structures

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Monitor and size the redo log buffer • Monitor and size the Java pool • Control the amount of Java session memory used by a session

Copyright © 2003, Oracle. All rights reserved.


The Redo Log Buffer Redo log buffer

Database buffer cache

Shared pool Library cache

Data dictionary cache

User global area

Server process

LGWR

ARCn

Control files

SQL> UPDATE employees 2

SET salary=salary*1.1

3

WHERE employee_id=736;

Data files Redo log files

Copyright Š 2003, Oracle. All rights reserved.

Archived log files


Sizing the Redo Log Buffer

Adjust the LOG_BUFFER parameter.

Default value: Either 512K or 128K * the value of CPU_COUNT, whichever is greater.

Copyright © 2003, Oracle. All rights reserved.


Diagnosing Redo Log Buffer Inefficiency SQL> UPDATE employees 2 SET salary=salary*1.1 3 WHERE employee_id=736; Server process

Server process LGRW SQL> DELETE FROM employees 2 WHERE employee_id=7400;

ARCH

Redo log files Copyright Š 2003, Oracle. All rights reserved.

Archived log files


Using Dynamic Views to Analyze Redo Log Buffer Efficiency v$session_wait

Redo log buffer

Log Buffer Space event

v$sysstat Redo Buffer Allocation Retries Redo Entries

Copyright Š 2003, Oracle. All rights reserved.


Performance Manager

Copyright Š 2003, Oracle. All rights reserved.


Redo Log Buffer Tuning Guidelines

There should be no Log Buffer Space waits. SQL> SELECT sid, event, seconds_in_wait, state 2 FROM v$session_wait 3 WHERE event = 'log buffer space';

Redo Buffer Allocation Retries value should be near 0 and should be less than 1% of redo entries. SQL> SELECT name, value 2 FROM v$sysstat 3 WHERE name IN ('redo entries', 4 'redo buffer allocation retries');

Copyright © 2003, Oracle. All rights reserved.


Reducing Redo Operations

Ways to avoid logging bulk operations in the redo log: • Direct Path loading without archiving does not generate redo. • Direct Path loading with archiving can use Nologging mode. • Direct Load Insert can use Nologging mode. • Some SQL statements can use Nologging mode.

Copyright © 2003, Oracle. All rights reserved.


Monitoring Java Pool Memory

Limit Java session memory usage: • JAVA_SOFT_SESSIONSPACE_LIMIT • JAVA_MAX_SESSIONSPACE_SIZE SQL> SELECT * FROM v$sgastat 2

WHERE pool = 'java pool';

POOL

NAME

BYTES

----------- ---------------------- ---------java pool

free memory

30261248

java pool

memory in use

19742720

Copyright © 2003, Oracle. All rights reserved.


Sizing the SGA for Java

SHARED_POOL_SIZE: – 8 KB per loaded class – 50 MB for loading large JAR files

• •

Configure Oracle Shared Server JAVA_POOL_SIZE – 24 MB default – 50 MB for medium-sized Java application

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Monitor and size the redo log buffer • Monitor and size the Java pool • Control the amount of Java session memory used by a session

Copyright © 2003, Oracle. All rights reserved.


Tuning the Oracle Shared Server

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Identify issues associated with managing users in an Oracle Shared Server environment • Configure the Oracle Shared Server environment to optimize performance • Diagnose and resolve performance issues with Oracle Shared Server processes

Copyright © 2003, Oracle. All rights reserved.


Overview

Dispatcher processes

Oracle server code program interface

Request queue

Shared server processes

Response queues

System Global Area

Oracle background processes

Copyright Š 2003, Oracle. All rights reserved.

Client Database server Listener


Oracle Shared Server Characteristics

• • • • •

Enables users to share processes Supports Oracle Net functionality Increases the number of concurrent users Useful on servers with remote clients CPU overhead could possibly increase for each individual user request

Copyright © 2003, Oracle. All rights reserved.


Monitoring Dispatchers

Use the following dynamic views: – v$shared_server_monitor – v$dispatcher – v$dispatcher_rate

Identify contention for dispatchers by checking: – Busy rates – Dispatcher waiting time

• •

Check for dispatcher contention. Add or remove dispatchers while the database is open.

Copyright © 2003, Oracle. All rights reserved.


Monitoring Shared Servers

• •

Oracle Shared Servers are started up dynamically. However, you should monitor the shared servers by: – Checking for shared server process contention – Adding or removing idle shared servers

Copyright © 2003, Oracle. All rights reserved.


Monitoring Process Usage

The v$circuit view displays: • • •

Server address Dispatcher address User session address

Copyright © 2003, Oracle. All rights reserved.


Shared Servers and Memory Usage

• • • •

Some user information goes into the shared pool. To reduce the load on the shared pool set a large pool. Overall memory demand is lower when using shared servers. Shared servers use the user global area (UGA) for sorts.

Copyright © 2003, Oracle. All rights reserved.


Troubleshooting

Possible causes of problems with the shared server include the following: • The database listener is not running. • The Oracle Shared Server initialization parameters are set incorrectly. • The dispatcher process has been killed. • The DBA does not have a dedicated connection. • The PROCESSES parameter is too low.

Copyright © 2003, Oracle. All rights reserved.


Obtaining Dictionary Information

Dynamic performance views: • v$circuit • v$dispatcher • v$dispatcher_rate • v$queue • v$shared_server_monitor • v$session • v$shared_server

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Describe the Oracle Shared Server as a resourcesharing configuration • List some situations in which it is appropriate to use the Oracle Shared Server • Monitor dispatcher and server usage • Troubleshoot Oracle Shared Server configuration

Copyright © 2003, Oracle. All rights reserved.


Optimizing Sort Operations

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • List the operations that use temporary space • Create and monitor temporary tablespaces • Identify actions that use the temporary tablespace • Describe and differentiate disk sorts and memory sorts • Identify the SQL operations that require sorts • List ways to reduce total sorts and disk sorts • Determine the number of memory sorts performed • Set parameters to optimize sorts Copyright © 2003, Oracle. All rights reserved.


Automatic Sort Area Management

Parameters for automatic sort area management: – PGA_AGGREGATE_TARGET (Ranges from 10 MB to 4000 GB)

– WORKAREA_SIZE_POLICY – AUTO | MANUAL Replaces all *_AREA_SIZE parameters

Copyright © 2003, Oracle. All rights reserved.


PGA Management Resources

Statistics to manage the PGA_AGGREGATE_TARGET initialization parameter • Views for monitoring the PGA work area include: – – – – –

v$sql_workarea_histogram v$pgastat v$sql_workarea_active v$sql_workarea v$tempseg_usage

Views to assist in sizing the PGA work area are: – v$pga_target_advice – v$pga_target_advice_histogram

Copyright © 2003, Oracle. All rights reserved.


Work Area Groups and PGA Cache Hit Percentages Percent executions

Optimal size One-pass size Multi-pass size

100%

97%

94%

0% …

0%

64-128KB

6%

0%

128-256KB

0% …

Copyright © 2003, Oracle. All rights reserved.

3% 64-128MB


Determining PGA Workload

SQL> 2 3 4 5 6 7 8 9 10 11

SELECT low_optimal_size/1024 AS low_kb, (high_optimal_size+1)/1024 AS high_kb, ROUND(100*optimal_executions /total_executions) AS optimal, ROUND(100*onepass_executions /total_executions) AS onepass, ROUND(100*multipasses_executions /total_executions) AS multipass FROM v$sql_workarea_histogram WHERE total_executions != 0 ORDER BY low_kb;

Copyright Š 2003, Oracle. All rights reserved.


Other Views for Work Areas

SQL> SELECT * 2 FROM v$pgastat 3 WHERE name = 'cache hit percentage'; NAME VALUE UNIT ------------------------- ---------- --------cache hit percentage 93 percent

Copyright Š 2003, Oracle. All rights reserved.


Querying v$pga_target_advice

SQL> 2 3 4 5 6

SELECT ROUND(pga_target_for_estimate /1024/1024) AS target_mb, estd_pga_cache_hit_percentage AS cache_hit_percent, estd_overalloc_count FROM v$pga_target_advice ORDER BY target_mb;

Copyright Š 2003, Oracle. All rights reserved.


Understanding v$pga_target_advice TARGET_MB CACHE_HIT_PERCENT ESTD_OVERALLOC_COUNT ---------- ----------------- -------------------63 23 367 125 24 30 250 30 3 375 39 1 500 58 0 600 59 0 700 59 0 800 60 0 900 60 0 1000 61 0 1500 67 0 2000 76 0 3000 83 0 4000 85 0 Copyright Š 2003, Oracle. All rights reserved.


PGA Sizing Advisor Output in Oracle Enterprise Manager

Copyright Š 2003, Oracle. All rights reserved.


Overview

The automatic sort area management feature is: • Easier to set up and size than the *_SORT_AREA parameters •

Easier to monitor using the advisory view

Copyright © 2003, Oracle. All rights reserved.


The Sorting Process

If sort space requirement is greater than SORT_AREA_SIZE:

Sort run 1

Sort run 2 TEMPORARY tablespace Temporary segment

Server process

Sort run 2

Copyright Š 2003, Oracle. All rights reserved.

Segments hold data while the server works on another sort run


Sort Area and Parameters

The sort space is in: • The PGA for a dedicated server connection PGA UGA Shared pool

User Stack Cursor Sort session space state area data

The shared pool for Oracle Shared Server connection PGA

UGA User session data

Cursor state

Sort area

Copyright © 2003, Oracle. All rights reserved.

Stack space


Sort Area and Parameters

• •

An execution plan can contain multiple sorts A single server performing a sort needs: – An area of SORT_AREA_SIZE, in bytes – At least one area of SORT_AREA_RETAINED_SIZE for a join sort

Each parallel query server needs SORT_AREA_SIZE

Two sets of servers can be writing at once, so: – Calculate SORT_AREA_SIZE × 2 × degree of parallelism – Add SORT_AREA_RETAINED_SIZE × degree of parallelism × number of sorts above two Copyright © 2003, Oracle. All rights reserved.


Tuning Sorts

• • • •

Use automatic sort area management. Avoid sort operations whenever possible. Reduce swapping and paging by making sure that sorting is done in memory when possible. Reduce space allocation calls by allocating temporary space appropriately.

Copyright © 2003, Oracle. All rights reserved.


The Sorting Process and Temporary Space Temporary tablespace Permanent

Objects

One single sort segment

2M

2M

2M

temp01.dbf

temp02.dbf

temp04.dbf

Create a temporary tablespace by using: CREATE TEMPORARY TABLESPACE TEMP TEMPFILE '$HOME/ORADATA/u06/temp01.dbf' size 200M; Copyright Š 2003, Oracle. All rights reserved.


Temporary Space Segments

A temporary space segment: • Is created by the first sort • Extends as demands are made on it • Comprises extents, which can be used by different sorts • Is described in the sort extent pool (SEP)

Copyright © 2003, Oracle. All rights reserved.


Operations Requiring Sorts

Some of the operations that may require sorts are: • Index creation • Parallel insert operations involving index maintenance • ORDER BY or GROUP BY clauses • DISTINCT values selection • UNION, INTERSECT, or MINUS operators • •

Sort-merge joins ANALYZE command execution

Copyright © 2003, Oracle. All rights reserved.


Avoiding Sorts

Avoid sort operations whenever possible: • Use NOSORT to create indexes. •

Use UNION ALL instead of UNION.

• •

Use index access for table joins. Create indexes on columns referenced in the ORDER BY clause.

• •

Select the columns for analysis. Use ESTIMATE rather than COMPUTE for large objects.

Copyright © 2003, Oracle. All rights reserved.


Diagnostic Tools v$sort_usage

Server process

Sort area (UGA)

Sort in memory

v$sort_segment

PCTINCREASE TEMPORARY INITIAL tablespace NEXT

Sort on disk v$sysstat

SORT_AREA_SIZE SORT_AREA_RETAINED_SIZE Statspack

Copyright Š 2003, Oracle. All rights reserved.


Diagnostics and Guidelines

• •

In an OLTP system the ratio of disk sorts to memory sorts should be less than 5%. Increase the value of SORT_AREA_SIZE / PGA_AGGREGATE_TARGET if the ratio is greater than 5%. SQL> 2 3 4 5

SELECT d.value "Disk", m.value "Mem", (d.value/m.value)*100 "Ratio" FROM v$sysstat m, v$sysstat d WHERE m.name = 'sorts (memory)' AND d.name = 'sorts (disk)'; Disk Mem Ratio ------------------------23 206 11.165049 Copyright © 2003, Oracle. All rights reserved.


Performance Manager: Sorts

Copyright Š 2003, Oracle. All rights reserved.


Monitoring Temporary Tablespaces

• •

Default storage parameters apply to sort segments. Sort segments have unlimited extents. SQL> SELECT tablespace_name, current_users, total_extents, 2

used_extents, extent_hits, max_used_blocks,

3

max_sort_blocks

4

FROM v$sort_segment;

TABLESPACE_NAME CURRENT_USERS TOTAL_EXTENTS USED_EXTENTS EXTENT_HITS MAX_USED_BLOCKS MAX_SORT_BLOCKS --------------- ------------- ------------- ---------------------- --------------- --------------TEMP 20

2 200

4 200

Copyright © 2003, Oracle. All rights reserved.

3


Temporary Tablespace Configuration

• •

Set appropriate storage values. Set up different temporary tablespaces based on sorting needs. SQL> SELECT session_num, tablespace, extents, blocks 2

FROM v$sort_usage;

SESSION_NUM

TABLESPACE

-----------

---------------------- -------- --------

16

• •

EXTENTS

TEMP

BLOCKS 4

200

Stripe temporary tablespaces. Use v$tempfile and dba_temp_files for information on temporary files. Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • List the operations that use temporary space • Create and monitor temporary tablespaces • Identify actions that use the temporary tablespace • Describe the use of disk and memory for sorting • Identify the SQL operations that require sorts • Differentiate between disk and memory sorts • List ways to reduce total sorts and disk sorts • Determine the number of memory sorts performed • Set parameters to optimize sorts

Copyright © 2003, Oracle. All rights reserved.


Using Resource Manager

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Set up Database Resource Manager • Assign users to Resource Manager groups • Create resource plans within groups

Copyright © 2003, Oracle. All rights reserved.


Overview

• •

Manage mixed workload Control system performance Database resource manager OLTP user

OLTP More resources DSS Less resources

DSS user Copyright © 2003, Oracle. All rights reserved.

Oracle9i


Database Resource Manager Concepts Resource consumer group

User groups with similar resource needs (one active resource consumer group per session)

Resource plan

Resource plan directives

Allocates CPU and PQ servers (one active plan)

Assigns groups and resources to plans Copyright Š 2003, Oracle. All rights reserved.


Using Sub-Plans to Limit CPU Utilization MYDB PLAN 30% @ L1

MAILDB PLAN 40% @ L1

70% @ L1

100% @ L3

100% @ L3

100% @ L2

BUGDB PLAN

80% @ L1

100% @ L2

20% @ L1

POSTMAN MAIL MAINT OTHER ONLINE BATCH BUG MAINT Groups Group Group Group Group Group

Copyright © 2003, Oracle. All rights reserved.


Resource Allocation Methods

Method

Resource

Recipient

Round-robin

CPU to sessions

Groups

Emphasis

CPU to groups

Plans

Absolute

Parallel degree

Plans

Copyright Š 2003, Oracle. All rights reserved.


The Initial Plan: SYSTEM_PLAN Allocation methods

Resource consumer group

P1CPU

P2CPU P3CPU P1//

SYS_GROUP

100%

0%

0%

0

OTHER_GROUPS

0%

100%

0%

0

LOW_GROUP

0%

0%

100%

0

Copyright Š 2003, Oracle. All rights reserved.


Administering the Database Resource Manager • •

Assign the resource manager system privileges to the administrator. Create resource objects with the package dbms_resource_manager: – Resource consumer groups – Resource plans – Resource plan directives

Assign users to groups with the package dbms_resource_manager_privs.

Specify the plan to be used by the instance.

Copyright © 2003, Oracle. All rights reserved.


Oracle Enterprise Manager: Resource Manager

Copyright Š 2003, Oracle. All rights reserved.


Assigning the Resource Manager Privilege

Assign the resource manager system privileges to the administrator. dbms_resource_manager_privs.grant_system_privilege ( grantee_name => 'OE', privilege_name => 'ADMINISTER_RESOURCE_MANAGER', admin_option => False );

Copyright Š 2003, Oracle. All rights reserved.


Creating Database Resource Manager Objects •

Create resource objects with the dbms_resource_manager package.

Create a pending area. dbms_resource_manager.create_pending_area();

Create resource consumer groups. dbms_resource_manager.create_consumer_group ( consumer_group => 'OLTP', comment => 'Online users' );

Copyright © 2003, Oracle. All rights reserved.


Creating Database Resource Manager Objects •

Create resource plans. dbms_resource_manager.create_plan ( plan => 'NIGHT', comment => 'DSS/Batch priority, ...' );

Create resource plan directives. dbms_resource_manager.create_plan_directive ( plan => 'NIGHT', group_or_subplan => 'SYS_GROUP', comment => '...', cpu_p1 => 100, parallel_degree_limit_p1 => 20); Copyright © 2003, Oracle. All rights reserved.


Active Session Pool

DBAs use Database Resource Manager to limit the amount of concurrent active sessions per resource consumer group by defining an active session pool. Benefits of an active session pool: • DBAs can meet performance service-level objectives by limiting the concurrent system workload. • The number of servers taking resources in the system is reduced. This avoids inefficient paging, swapping, and other resource depletion.

Copyright © 2003, Oracle. All rights reserved.


Active Session Pool Mechanism

The active session pool: – Size can be set per resource consumer group. – Size is limited to only one per consumer group. – Is the maximum number of concurrently active sessions. – Is defined as a session currently part of an active transaction, query, or parallel operation.

When the active session pool is filled with active sessions, all subsequent sessions attempting to become active are queued. Individual parallel slaves do not count toward the number of sessions. The entire parallel operation counts as one active session. Copyright © 2003, Oracle. All rights reserved.


Active Session Pool Parameters

The active session pool is defined by setting the parameters: • ACTIVE_SESS_POOL_P1 – Identifies the number of active sessions that establishes the resource consumer group's threshold – Default is 1000000

QUEUEING_P1 – Indicates how long, in seconds, any session will wait on the queue before aborting the current operation – Default is 1000000

Copyright © 2003, Oracle. All rights reserved.


Setting the Active Session Pool

Example: GROUP

ACTIVE SESSION POOL

OLTP BATCH

ACTIVE_SESS_POOL_P1 = 5 QUEUEING_P1 = 600

OLTP: Set no limit on concurrent active sessions. BATCH: Set to limit concurrent active sessions to 5. QUEUEING_P1, set to 600, aborts all operations that wait on the queue for more than ten minutes. Copyright Š 2003, Oracle. All rights reserved.


Maximum Estimated Execution Time

• •

• •

The Database Resource Manager can estimate the execution time of an operation proactively. A DBA can specify a maximum estimated execution time for an operation at the resource consumer group level. Operation will not start if the estimate is longer than MAX_EST_EXEC_TIME. The benefit of this feature is the elimination of the exceptionally large job that uses too many system resources. The default is 1000000 seconds.

Copyright © 2003, Oracle. All rights reserved.


Automatic Consumer Group Switching

The Database Resource Manager automatically switches a session’s consumer group based on the following resource plan directive parameters: – SWITCH_GROUP: Group switched to. Default is NULL. – SWITCH_TIME: Active time in seconds. Default is 1000000. – SWITCH_ESTIMATE: If value is True, execution time estimate is used to decide whether to switch an operation even before it starts. Default is False.

This feature can be used to limit the resources consumed by long-running operations.

Copyright © 2003, Oracle. All rights reserved.


Undo Quota

The UNDO_POOL plan directive: • • •

Limits the amount of undo space that can be used When exceeded, prevents DML SELECT statements are still allowed

• •

Is specified in kilobytes Default is 1000000

Copyright © 2003, Oracle. All rights reserved.


Creating Database Resource Manager Objects •

Validate the pending area.

dbms_resource_manager.validate_pending_area();

Commit the pending area.

dbms_resource_manager.submit_pending_area();

Copyright © 2003, Oracle. All rights reserved.


Assigning Users to Consumer Groups •

Assign users to groups. dbms_resource_manager_privs. grant_switch_consumer_group ( grantee_name => 'MOIRA', consumer_group => 'OLTP', grant_option => False );

Set the initial consumer group for users: dbms_resource_manager. set_initial_consumer_group ( user => 'MOIRA', consumer_group => 'OLTP' );

Copyright © 2003, Oracle. All rights reserved.


Setting the Resource Plan for an Instance

• •

Specify the plan to be used by the instance. Specify the RESOURCE_MANAGER_PLAN initialization parameter. RESOURCE_MANAGER_PLAN=day

Change the resource plan without shutting down and restarting the instance. ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=night;

Copyright © 2003, Oracle. All rights reserved.


Changing a Consumer Group Within a Session The user or the application can switch the current consumer group. dbms_session. switch_current_consumer_group ( new_consumer_group => 'DSS', old_consumer_group => v_old_group, initial_group_on_error => False );

Copyright Š 2003, Oracle. All rights reserved.


Changing Consumer Groups for Sessions •

Can be set by DBA for a session dbms_resource_manager. switch_consumer_group_for_sess ( session_id => 7, session_serial => 13, consumer_group => 'OLTP');

Can be set by DBA for all sessions for a user dbms_resource_manager. switch_consumer_group_for_user ( user => 'MOIRA', consumer_group => 'OLTP'); Copyright © 2003, Oracle. All rights reserved.


Database Resource Manager Information

• • • • • •

dba_rsrc_plans plans and status dba_rsrc_plan_directives plan directives dba_rsrc_consumer_groups consumer groups dba_rsrc_consumer_group_privs users/roles dba_users column initial_rsrc_consumer_group dba_rsrc_manager_system_privs users/roles

Copyright © 2003, Oracle. All rights reserved.


Resource Plan Directives

SQL> SELECT plan, group_or_subplan, cpu_p1, cpu_p2, 2 cpu_p3, parallel_degree_limit_p1, status 3 FROM dba_rsrc_plan_directives;

Copyright Š 2003, Oracle. All rights reserved.


Current Database Resource Manager Settings •

v$session: Contains the

resource_consumer_group column that • •

shows the current group for a session v$rsrc_plan: A view that shows the active resource plan v$rsrc_consumer_group: A view that contains statistics for all active groups

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to do the following: • Set up Database Resource Manager • Assign users to Resource Manager groups • Create resource plans within groups

Copyright © 2003, Oracle. All rights reserved.


SQL Statement Tuning

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Control optimizer options • Use optimizer hints • Employ plan stability • Use stored outlines • Use SQL Trace and TKPROF

Copyright © 2003, Oracle. All rights reserved.


Overview

The purpose of this lesson is: • To provide methods to determine the resources used by SQL statements: – – – –

Oracle Enterprise Manager Statspack Explain plan SQL Trace and TKPROF

– Autotrace

• •

To determine which SQL statements possibly require tuning Not to tune the actual SQL statements

Copyright © 2003, Oracle. All rights reserved.


Optimizer Modes

There are two types of optimizer modes: • Rule-based: – Uses a ranking system – Syntax- and data dictionary-driven

Cost-based: – Chooses the path with lowest cost – Statistics-driven

Copyright © 2003, Oracle. All rights reserved.


Setting the Optimizer Mode

At the instance level: – optimizer_mode = {Choose|Rule|First_rows|First_rows_n| All_rows}

At the session level: – ALTER SESSION SET optimizer_mode = {Choose|Rule|First_rows|First_rows_n| All_rows}

At the statement level: – Using hints

Copyright © 2003, Oracle. All rights reserved.


Using Hints in a SQL Statement

SQL> CREATE index gen_idx on customers 2 (cust_gender);

SQL> 2 3 4 5

SELECT /*+ INDEX(customers gen_idx)*/ cust_last_name, cust_street_address, cust_postal_code FROM sh.customers WHERE UPPER (cust_gender) = ‘M';

Copyright © 2003, Oracle. All rights reserved.


Optimizer Plan Stability

• • • •

Users can stabilize execution plans, to force applications to use a desired SQL access path. A consistent execution path is thereby maintained through database changes. This is done by creating a stored outline consisting of hints. The OPTIMIZER_FEATURES_ENABLE parameter enables the optimizer to retain CBO features of previous versions.

Copyright © 2003, Oracle. All rights reserved.


Plan Equivalence

• •

SQL statement text must match the text in a stored outline. Plans are maintained through: – – – – –

New Oracle versions New statistics on objects Initialization parameter changes Database reorganization Schema changes

Copyright © 2003, Oracle. All rights reserved.


Creating Stored Outlines

SQL> 2 SQL> SQL>

ALTER SESSION SET CREATE_STORED_OUTLINES = train; SELECT … FROM … ; SELECT … FROM … ;

SQL> 2 3 4 5 6

CREATE OR REPLACE OUTLINE co_cl_join FOR CATEGORY train ON SELECT co.crs_id, ... FROM courses co , classes cl WHERE co.crs_id = cl.crs_id;

Copyright © 2003, Oracle. All rights reserved.


Using Stored Outlines

Set the USE_STORED_OUTLINES parameter to True or to a category name: SQL> ALTER SESSION 2 SET USE_STORED_OUTLINES = train; SQL> SELECT … FROM … ;

Both CREATE_STORED_OUTLINES and USE_STORED_OUTLINES can be set at the instance or session level.

Copyright © 2003, Oracle. All rights reserved.


Using Private Outlines

Private outlines are: • Edited without affecting the running system • Copies of current storage outlines • Controlled using the USE_PRIVATE_OUTLINES parameter

Copyright © 2003, Oracle. All rights reserved.


Editing Stored Outlines

Editing and using private outlines: • Create the outline tables in the current schema. • Copy the selected outline to private outline. • Edit the outline stored as a private outline. • To use the private outline, set the USE_PRIVATE_OUTLINE parameter. • •

To allow public access to the new stored outline, overwrite the stored outline. Reset USE_PRIVATE_OUTLINE to False.

Copyright © 2003, Oracle. All rights reserved.


Maintaining Stored Outlines

Use the outln_pkg package to: – Drop outlines or categories of outlines – Rename categories

Use the ALTER OUTLINE command to: – Rename an outline – Rebuild an outline – Change the category of an outline

Outlines are stored in the outln schema

Copyright © 2003, Oracle. All rights reserved.


Oracle Enterprise Manager: Maintaining Stored Outlines

Copyright Š 2003, Oracle. All rights reserved.


Overview of Diagnostic Tools

• • •

Statspack EXPLAIN PLAN SQL trace and TKPROF

• •

SQL*Plus autotrace feature Oracle SQL Analyze

Copyright © 2003, Oracle. All rights reserved.


SQL Reports in Statspack

The following reports on statements are provided by Statspack: • SQL ordered by gets • SQL ordered by reads • SQL ordered by executions • SQL ordered by parse calls

Copyright © 2003, Oracle. All rights reserved.


Performance Manager: Top SQL

Copyright Š 2003, Oracle. All rights reserved.


Generate the Execution Plan

• •

Can be used without tracing Needs the plan_table table utlxplan.sql

Create the explain plan: SQL> EXPLAIN PLAN FOR 2 SELECT last_name FROM hr.employees;

Copyright © 2003, Oracle. All rights reserved.


Query the plan_table Table

Query plan_table to display the execution plans: • • • •

Query plan_table directly. Use script utlxpls.sql (hide Parallel Query information). Use script utlxplp.sql (show Parallel Query information). Use the dbms_xplan package. SQL> SELECT * 2 FROM TABLE(dbms_xplan.display);

Copyright © 2003, Oracle. All rights reserved.


Using SQL Trace and TKPROF

To use SQL trace and TKPROF: •

Set the initialization parameters. SQL> ALTER SESSION SET sql_trace = True;

Run the application. SQL> ALTER SESSION SET sql_trace = False;

Format the trace file with TKPROF.

Interpret the output.

Copyright © 2003, Oracle. All rights reserved.


Enabling and Disabling SQL Trace

At the instance level: SQL_TRACE = {True|False}

At the session level: SQL> ALTER SESSION SET 2 SQL_TRACE = {True|False}; SQL> 2 SQL> 2 3

EXECUTE dbms_session.set_sql_trace ({True|False}); EXECUTE dbms_system.set_sql_trace_in_session (session_id, serial_id, {True|False});

Copyright © 2003, Oracle. All rights reserved.


Formatting the Trace File with TKPROF

$ tkprof tracefile.trc output.txt [options]

tracefile.trc

output.txt

USER_DUMP_DEST

Copyright Š 2003, Oracle. All rights reserved.


TKPROF Statistics

• • • • • • •

Count: Number of execution calls CPU: CPU seconds used Elapsed: Total elapsed time Disk: Physical reads Query: Logical reads for consistent read Current: Logical reads in current mode Rows: Rows processed

Copyright © 2003, Oracle. All rights reserved.


SQL*Plus Autotrace

Create the plan_table table.

Create and grant the plustrace role. SQL> @$ORACLE_HOME/sqlplus/admin/plustrce.sql SQL> GRANT plustrace TO scott;

Autotrace syntax: SET AUTOTRACE [ Off | On | Traceonly ] [ Explain | Statistics ]

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Describe how the optimizer is used • Describe how hints are used • Explain the concept of plan stability • Explain the use of stored outlines • Use SQL Trace and TKPROF

Copyright © 2003, Oracle. All rights reserved.


Managing Statistics

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Collect system statistics • Collect statistics on indexes and tables • Collect and manage histogram statistics • Copy statistics between databases • Monitor indexes to determine usage

Copyright © 2003, Oracle. All rights reserved.


Managing Statistics

Use the dbms_stats package:

• • • • •

gather_table_stats gather_index_stats gather_schema_stats gather_database_stats gather_stale_stats

Copyright © 2003, Oracle. All rights reserved.


Table Statistics

• • • • • • •

Number of rows Number of blocks and empty blocks Average available free space Number of chained or migrated rows Average row length Last analyze date and sample size Data dictionary view: dba_tables

Copyright © 2003, Oracle. All rights reserved.


Collecting Segment-Level Statistics Statistics collected and the method of collection: • Logical reads: Sampled • Buffer busy waits: Continuous • Db block changes: Sampled • Physical reads: Continuous • Physical writes: Continuous • Physical reads direct: Continuous • Physical writes direct: Continuous • Global cache cr blocks served: Continuous • Global cache current blocks served: Continuous • ITL waits: Continuous • Row lock waits: Continuous Copyright © 2003, Oracle. All rights reserved.


Querying Segment-Level Statistics

Segment-level statistics are queried using: • v$segstat_name: Lists the segment statistics being collected • v$segstat: Displays the statistic value, statistic name, and other basic information • v$segment_statistics: Displays the segment owner and tablespace name in addition to all the rows contained in v$segstat

Copyright © 2003, Oracle. All rights reserved.


Using Dynamic Sampling

Dynamic sampling should be used when: • A better plan could be found • The cost of collecting the statistics is minimal compared to the execution time • The query is executed many times

Copyright © 2003, Oracle. All rights reserved.


Enabling Dynamic Sampling

Dynamic sampling is set using: • OPTIMIZER_DYNAMIC_SAMPLING = 0 Dynamic sampling is not performed • OPTIMIZER_DYNAMIC_SAMPLING = 1 Dynamic sampling performed when: – The query accesses more than one table. – A table has not been analyzed and there is no index. – The optimizer determines that a full table scan is required due to nonexistent statistics.

OPTIMIZER_DYNAMIC_SAMPLING > 1 – The higher the value the more aggressive dynamic sampling is performed. The upper limit is 10. Copyright © 2003, Oracle. All rights reserved.


Index Statistics

• • • • • • •

Index level (height) Number of leaf blocks and distinct keys Average number of leaf blocks per key Average number of data blocks per key Number of index entries Clustering factor Data dictionary view: dba_indexes

Copyright © 2003, Oracle. All rights reserved.


Index Tuning Wizard

Copyright Š 2003, Oracle. All rights reserved.


Column Statistics

• • • •

Number of distinct values Lowest value, highest value (stored in RAW [binary] format) Last analyze date and sample size Data dictionary view: user_tab_col_statistics

Copyright © 2003, Oracle. All rights reserved.


Histograms

• • • •

Histograms describe the data distribution of a particular column in more detail. They give better predicate selectivity estimates for unevenly distributed data. You create histograms with the dbms_stats.gather_table_stats procedure. Data dictionary views: dba_histograms, dba_tab_histograms

Copyright © 2003, Oracle. All rights reserved.


Generating Histogram Statistics

Histogram statistics are generated by: SQL> EXECUTE dbms_stats.gather_table_stats 2 ('HR','EMPLOYEES', METHOD_OPT => 3 'FOR COLUMNS SIZE 10 salary');

Copyright Š 2003, Oracle. All rights reserved.


Gathering Statistic Estimates

• •

dbms_stats.auto_sample_size: New estimate_percent value METHOD_OPT options: – REPEAT: New histogram with same number of buckets – AUTO: New histogram based on data distribution and application workload – SKEWONLY: New histogram based on data distribution SQL> 2 3 4

EXECUTE dbms_stats.gather_schema_stats( ownname => 'OE', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'for all columns size AUTO');

Copyright © 2003, Oracle. All rights reserved.


Automatic Statistic Collecting

For the dbms_stats.gather_schema_stats procedure set OPTIONS to:

• • •

Gather Stale Gather Empty Gather Auto

SQL> EXECUTE dbms_stats.gather_schema_stats 2 (OWNNAME => 'OE', 3 OPTIONS => 'GATHER AUTO');

Copyright © 2003, Oracle. All rights reserved.


Optimizer Cost Model

Three columns in plan_table are: – cpu_cost: Estimated CPU cost of the operation – io_cost: Estimated I/O cost of the operation – temp_space: Estimated temporary space (in bytes) used by the operation

• • •

Includes CPU usage Accounts for the effect of caching Accounts for index prefetching

Copyright © 2003, Oracle. All rights reserved.


Using System Statistics

• • •

System statistics enable the CBO to use CPU and I/O characteristics. System statistics must be gathered on a regular basis; this does not invalidate cached plans. Gathering system statistics equals analyzing system activity for a specified period of time.

Copyright © 2003, Oracle. All rights reserved.


Gathering System Statistics

Procedures of the dbms_stats package used to collect system statistics:

• • •

gather_system_stats set_system_stats get_system_stats

Copyright © 2003, Oracle. All rights reserved.


Automatic Gathering of System Statistics

Collect statistics for OLTP: SQL> EXECUTE dbms_stats.gather_system_stats 2 (interval => 120, stattab => 'mystats', 3 statid => 'OLTP');

Collect statistics for OLAP: SQL> EXECUTE dbms_stats.gather_system_stats 2 (interval => 120, stattab => 'mystats', 3 statid => 'OLAP');

Copyright © 2003, Oracle. All rights reserved.


Manual Gathering of System Statistics

Start manual system statistics collection in the data dictionary: SQL> EXECUTE dbms_stats.gather_system_stats 2 (gathering_mode => 'START');

• •

Generate the workload End system statistics collection: SQL> EXECUTE dbms_stats.gather_system_stats 2 (gathering_mode => 'STOP');

Copyright © 2003, Oracle. All rights reserved.


Import System Statistics Example

For daytime (OLTP): SQL> EXECUTE dbms_stats.import_system_stats 2 (stattab => 'mystats', statid => 'OLTP');

For nighttime (OLAP): SQL> EXECUTE dbms_stats.import_system_stats 2 (stattab => 'mystats', statid => 'OLAP');

Copyright © 2003, Oracle. All rights reserved.


Copying Statistics Between Databases

Data dictionary

Copy to user table 2

User-defined statistics table

Export 3 Import

Copy user table to DD 4

1 User-defined statistics table

Copyright Š 2003, Oracle. All rights reserved.

Data dictionary


Example: Create the Statistics Table

Step 1. Create the table to hold the statistics: dbms_stats.create_stat_table (‘SH' /* schema name */ ,'STATS' /* statistics table name */ ,'SAMPLE' /* tablespace */ );

Copyright © 2003, Oracle. All rights reserved.


Example: Copy the Statistics to a Table

Step 2. Copy the statistics to a table: dbms_stats.export_table_stats (’SH’ /* schema name */ ,’SALES’ /* table name */ , NULL /* no partitions */ ,’STATS’ /* statistics table name */ ,’CRS990601’ /* id for statistics */ , TRUE /* index statistics */ );

Step 3. Export the stats table and then import it into the second database.

Copyright © 2003, Oracle. All rights reserved.


Example: Import the Statistics

Step 4. Copy the statistics into the data dictionary: dbms_stats.import_table_stats (’SH’ /* schema name */ ,’SALES’ /* table name */ , NULL /* no partitions */ ,’STATS’ /* statistics table name */ ,’CRS990601’ /* id for statistics */ , TRUE /* index statistics */ );

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Collect system statistics • Collect statistics on indexes and tables • Describe the use of histograms • Copy statistics between databases • Determine usage of indexes

Copyright © 2003, Oracle. All rights reserved.


Using Oracle Blocks Efficiently

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Use automatic segment space management • Use manual segment space management • Describe the use of Oracle block parameters • Recover space from sparsely populated segments • Describe and detect chaining and migration of Oracle blocks • Perform index reorganization

Copyright © 2003, Oracle. All rights reserved.


Database Storage Hierarchy

Tablespace

Segments

Extents Extents

Extents

Blocks Copyright Š 2003, Oracle. All rights reserved.


Allocation of Extents

To avoid the disadvantages of dynamic extent allocation: • Create locally managed tablespaces. • Size the segments appropriately. • Monitor segments ready to extend.

Copyright © 2003, Oracle. All rights reserved.


Avoiding Dynamic Allocation

To display segments with less than 10% free blocks:

SQL> SELECT owner, table_name, blocks, empty_blocks 2 FROM dba_tables 3 WHERE empty_blocks/(blocks+empty_blocks) < .1; OWNER TABLE_NAME BLOCKS EMPTY_BLOCKS ------ ---------- ---------- -----------HR EMPLOYEES 1450 50 HR COUNTRIES 460 40

To avoid dynamic allocation:

SQL> ALTER TABLE hr.employees ALLOCATE EXTENT; Table altered.

Copyright © 2003, Oracle. All rights reserved.


Locally Managed Extents

Create a locally managed tablespace: SQL> 2 3 4 5 6

CREATE TABLESPACE user_data_1 DATAFILE ‘/oracle9i/oradata/db1/lm_1.dbf’ SIZE 100M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 2M;

With the Oracle database the default extent management is local.

Copyright © 2003, Oracle. All rights reserved.


Pros and Cons of Large Extents

Pros – Are less likely to extend dynamically – Deliver small performance benefit – Enable you to read the entire extent map with a single I/O operation

Cons – Free space may not be available – Unused space

Copyright © 2003, Oracle. All rights reserved.


The High-Water Mark

Extent 1 Empty blocks (rows deleted) Extent 2

Segment header block

Empty blocks (never used)

Copyright Š 2003, Oracle. All rights reserved.

Highwater mark


The High-Water Mark

The high-water mark is: – Recorded in the segment header block – Set to the beginning of the segment on creation – Incremented in five-block increments as rows are inserted – Reset by the TRUNCATE command

Never reset by using DELETE statements

Copyright © 2003, Oracle. All rights reserved.


Table Statistics

Populate the table statistics using the dbms_stats package and then query the values in dba_tables: SQL> EXECUTE dbms_stats.gather_table_stats > ('HR','EMPLOYEES'); PL/SQL procedure successfully completed. SQL> SELECT num_rows, blocks, empty_blocks as empty, 2 avg_space, chain_cnt, avg_row_len 3 FROM dba_tables 4 WHERE owner = 'HR' 5 AND table_name = 'EMPLOYEES'; NUM_ROWS BLOCKS EMPTY AVG_SPACE CHAIN_CNT AVG_ROW_LEN -------- ------ ----- --------- --------- ----------13214 615 35 1753 0 184

Copyright Š 2003, Oracle. All rights reserved.


The dbms_space Package DECLARE owner VARCHAR2(30); table_name VARCHAR2(30); seg_type VARCHAR2(30); tblock NUMBER; ... BEGIN dbms_space.unused_space ('&owner','&table_name','TABLE', tblock,tbyte,ublock,ubyte,lue_fid, lue_bid,lublock); dbms_output.put_line(... END; / Copyright Š 2003, Oracle. All rights reserved.


Recovering Space

Below the high-water mark: • Use the Export and Import utilities to: – Export the table – Drop or truncate the table – Import the table

Or use the Alter Table Employees Move command to move the table. Above the high-water mark, use the Alter Table Employees Deallocate Unused; command.

Copyright © 2003, Oracle. All rights reserved.


Database Block Size

Minimize block visits by: • Using a larger block size • Packing rows tightly • Preventing row migration Tablespace

Segments

Extents

Blocks Copyright © 2003, Oracle. All rights reserved.


The DB_BLOCK_SIZE Parameter

The database block size: • Is defined by the DB_BLOCK_SIZE parameter • • • • • •

Is set when the database is created Is the minimum I/O unit for data file reads Is 2 KB or 4 KB by default, but up to 64 KB is allowed Cannot be changed easily Should be an integer multiple of the OS block size Should be less than or equal to the OS I/O size

Copyright © 2003, Oracle. All rights reserved.


Small Block Size: Pros and Cons

Pros – Reduces block contention – Is good for small rows – Is good for random access

Cons – Has a relatively large overhead – Has a small number of rows per block – Can cause more index blocks to be read

Copyright © 2003, Oracle. All rights reserved.


Large Block Size: Pros and Cons

Pros – – – –

Less overhead Good for sequential access Good for very large rows Better performance of index reads

Cons – Increases block contention – Uses more space in the buffer cache

Copyright © 2003, Oracle. All rights reserved.


PCTFREE and PCTUSED

Inserts

Inserts

1

2

Inserts

Inserts

3

4

Copyright Š 2003, Oracle. All rights reserved.


Guidelines for PCTFREE and PCTUSED

PCTFREE – Default is 10 – Zero if no UPDATE activity

– PCTFREE = 100 × UPD / (Average row length) PCTUSED – Default is 40 – Set if rows are deleted – PCTUSED = 100 – PCTFREE – 100 × Rows × (Average row length) / Block size

Copyright © 2003, Oracle. All rights reserved.


Migration and Chaining Migration

Chaining

Index

Table

Copyright Š 2003, Oracle. All rights reserved.


Detecting Migration and Chaining

Use the ANALYZE command to detect migration and chaining: SQL> ANALYZE TABLE oe.orders COMPUTE STATISTICS; PL/SQL procedure successfully completed. SQL> SELECT num_rows, chain_cnt FROM dba_tables 2 WHERE table_name='ORDERS'; NUM_ROWS CHAIN_CNT --------- --------168 102

Detect migration and chaining by using Statspack: Statistic Total Per transaction ... ------------------------- ----- --------------- ... table fetch continued row 495 .02 …

Copyright © 2003, Oracle. All rights reserved.


Selecting Migrated Rows

SQL> ANALYZE TABLE oe.orders LIST CHAINED ROWS; Table analyzed. SQL> SELECT owner_name, table_name, head_rowid 2 FROM chained_rows 3 WHERE table_name = 'ORDERS'; OWNER_NAME TABLE_NAME HEAD_ROWID ---------- ---------- -----------------SALES ORDER_HIST AAAAluAAHAAAAA1AAA SALES ORDER_HIST AAAAluAAHAAAAA1AAB ...

Copyright © 2003, Oracle. All rights reserved.


Eliminating Migrated Rows

Export/Import – Export the table. – Drop or truncate the table. – Import the table.

Move table command: – Alter Table Employees Move

Copying migrated rows – Find migrated rows using ANALYZE. – Copy migrated rows to new table. – Delete migrated rows from original table. – Copy rows from new table to original table.

Copyright © 2003, Oracle. All rights reserved.


Index Reorganization

• • • •

Indexes on volatile tables are a performance problem. Only entirely empty index blocks go to the free list. If a block contains only one entry, it must be maintained. You may need to rebuild indexes.

Copyright © 2003, Oracle. All rights reserved.


Monitoring Index Space To collect usage statistics regarding an index: SQL> EXECUTE dbms_stats.gather_index_stats > ('OE','CUSTOMERS_PK');

To view statistics collected: SQL> SELECT name, 2 (DEL_LF_ROWS_LEN/LF_ROWS_LEN) * 100 AS wastage 3 FROM index_stats;

Rebuild indexes with wastage greater than 20%: SQL> ALTER INDEX oe.customers_pk REBUILD;

To coalesce indexes (alternative to REBUILD): SQL> ALTER INDEX oe.customers_pk COALESCE; Copyright Š 2003, Oracle. All rights reserved.


Deciding Whether to Rebuild or Coalesce an Index Rebuild

Coalesce

Quickly moves index to another tablespace.

Cannot move index to another tablespace.

Higher costs: Requires more disk space.

Lower costs: Does not require more disk space.

Creates new tree, shrinks height if applicable.

Coalesces leaf blocks within same branch of tree.

Enables you to quickly change storage and tablespace parameters without having to drop the original index.

Quickly frees up index leaf blocks for use.

Copyright Š 2003, Oracle. All rights reserved.


Monitoring Index Usage

Gathering statistics using an Oracle supplied package: SQL> EXECUTE

dbms_stats.gather_index_stats (‘HR’,’LOC_COUNTRY_IX’);

Gathering statistics at index creation: SQL> CREATE INDEX hr.loc_country_ix 2 …………………… 5 COMPUTE STATISTICS;

Gathering statistics when rebuilding an index: SQL> ALTER INDEX hr.loc_country_ix REBUILD 2 COMPUTE STATISTICS;

Copyright © 2003, Oracle. All rights reserved.


Identifying Unused Indexes

• •

To start monitoring the usage of an index: SQL> ALTER INDEX hr.emp_name_ix 2 MONITORING USAGE;

To query the usage of the index: SQL> SELECT index_name, used 2 FROM v$object_usage;

To stop monitoring the usage of an index: SQL> ALTER INDEX hr.emp_name_ix 2 NOMONITORING USAGE;

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned to do the following: • Use automatic segment space management • Use manual segment space management – Manage extents and Oracle blocks – Ensuring effective use of space – Determine the high-water mark

• • • •

Describe the use of Oracle Block parameters Recover space from sparsely populated segments Describe and detect chaining and migration of Oracle blocks Perform index reorganization Copyright © 2003, Oracle. All rights reserved.


Using Oracle Data Storage Structures Efficiently

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Compare and evaluate the different storage structures • Examine different data access methods • Implement different partitioning methods

Copyright © 2003, Oracle. All rights reserved.


Data Storage Structures

Heap table

Cluster

Indexorganized table

Organization by value Heap

Clustered

Sorted

Partitioned table

Copyright Š 2003, Oracle. All rights reserved.


Selecting the Physical Structure

Factors affecting the selection: • Rows read in groups • SELECT or DML statements • • • •

Table size Row size, row group, and block size Small or large transactions Using parallel queries to load or for SELECT statements

Copyright © 2003, Oracle. All rights reserved.


Data Access Methods

To enhance performance, you can use the following data access methods: • Clusters • Indexes • B-tree (normal or reverse key) • Bitmap • Function based • Index-organized tables • Materialized views

Copyright © 2003, Oracle. All rights reserved.


Clusters ORD_NO ----101 102 102 102 101 101

PROD -----A4102 A2091 G7830 N9587 A5675 W0824

QTY -----20 11 20 26 19 10

ORD_NO -----101 102

...

ORD_DT CUST_CD ----------05-JAN-97 R01 07-JAN-97 N45

Unclustered orders and order_item tables

Cluster Key (ORD_NO) 101 ORD_DT CUST_CD 05-JAN-97 R01 PROD QTY A4102 20 A5675 19 W0824 10 102 ORD_DT CUST_CD 07-JAN-97 N45 PROD QTY A2091 11 G7830 20 N9587 26

Clustered orders and order_item tables

Copyright Š 2003, Oracle. All rights reserved.


Cluster Types Index cluster

Hash cluster

Hash function

Copyright Š 2003, Oracle. All rights reserved.


Situations Where Clusters Are Useful

Criterion Uniform key distribution

Index

Hash

X

X

Evenly distributed key values

X

Rarely updated key

X

Often joined master-detail tables

X

X

Predictable number of key values

X

Queries using equality predicate on key

X

Copyright Š 2003, Oracle. All rights reserved.


Partitioning Methods

The following partitioning methods are available: • Range • Hash • List • Composite

Range partitioning

Hash partitioning

List partitioning

Copyright © 2003, Oracle. All rights reserved.

Composite partitioning


Range Partitioning Example

CREATE TABLE sales (acct_no NUMBER(5), person VARCHAR2(30), sales_amount NUMBER(8), 1 week_no NUMBER(2)) 3 PARTITION BY RANGE (week_no) 2 (PARTITION P1 VALUES LESS THAN (4) TABLESPACE data0, PARTITION P2 VALUES LESS THAN (8) TABLESPACE data1, ...… PARTITION P13 VALUES LESS THAN (53)TABLESPACE data12 );

The partition key is week_no. 2 VALUES LESS THAN must be specified as a literal. 3 Physical attributes can be set per partition. 1

Copyright © 2003, Oracle. All rights reserved.


Hash Partitioning Overview

• • • • •

Easy to Implement Enables better performance for PDML and partition-wise joins Inserts rows into partitions automatically based on the hash of the partition key Supports (hash) local indexes Does not support (hash) global indexes

Copyright © 2003, Oracle. All rights reserved.


List Partitioning Example SQL> CREATE TABLE locations 2 (location_id, street_address, 3 postal_code, city, state_province, 4 country_id) 5 STORAGE(INITIAL 10K NEXT 20K) 6 TABLESPACE users 7 PARTITION BY LIST (state_province) 8 (PARTITION region_east 9 VALUES('MA','NY','CT','ME','MD'), 10 PARTITION region_west 11 VALUES('CA','AZ','NM','OR','WA'), 12 PARTITION region_south 13 VALUES('TX','KY','TN','LA','MS'), 14 PARTITION region_central 15 VALUES('OH','ND','SD','MO','IL')); Copyright © 2003, Oracle. All rights reserved.


Default Partition for List Partitioning

Create a DEFAULT list partition for all values not covered by other partitions: CREATE TABLE customer ... PARTITION BY LIST (state) (PARTITION p1 VALUES ('CA','CO'), PARTITION p2 VALUES ('FL','TX'), PARTITION p3 VALUES (DEFAULT) );

Copyright Š 2003, Oracle. All rights reserved.


Composite Partitioned Table Overview

• • • • • •

Ideal for both historical data and data placement Provides high availability and manageability, like range partitioning Improves performance for parallel DML and supports partition-wise joins Allows more granular partition elimination Supports composite local indexes Does not support composite global indexes

Copyright © 2003, Oracle. All rights reserved.


Partitioned Indexes for Scalable Access Global Nonpartitioned index Global Partitioned Index

Table partition

Table partition

Table partition

Table partition

Local partitioned index Copyright Š 2003, Oracle. All rights reserved.


Partition Pruning 99-Jan 99-Feb 99-Mar 99-Apr 99-May 99-Jun

Partition pruning: Only the relevant partitions are accessed. SQL> 2 3 4 5 6 7

SELECT SUM(sales_amount) FROM sales WHERE sales_date BETWEEN TO_DATE(‘01-MAR-1999’, ‘DD-MON-YYYY’) AND TO_DATE(‘31-MAY-1999’, ‘DD-MON-YYYY’);

sales Copyright © 2003, Oracle. All rights reserved.


Partition-Wise Join

3 1

2

Full partition-wise join

Nonpartition-wise join

Partial partition-wise join Query slave

Partition

Copyright Š 2003, Oracle. All rights reserved.

Partitioned table


Statistics Collection for Partitioned Objects • • • •

You can gather object-, partition-, or subpartition level statistics. There are GLOBAL or NON-GLOBAL statistics. The dbms_stats package can gather global statistics at any level for tables only. It is not possible to gather: – Global histograms – Global statistics for indexes

Copyright © 2003, Oracle. All rights reserved.


Some dbms_stats Examples

CALL dbms_stats.gather_table_stats ( ownname => ‘o901’, tabname => ‘sales’, partname => ‘feb99’, granularity => ‘partition’);

CALL dbms_stats.gather_index_stats ( ownname => ‘o901’, indname => ‘isales’, partname => ‘s1’);

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to do the following: • Compare and evaluate the different storage structures • Examine different data access methods • Implement different partitioning methods

Copyright © 2003, Oracle. All rights reserved.


Application Tuning

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Explain the role of the DBA in tuning applications • Move tables using the ALTER TABLE command • • • •

Redefine a table online Create different types of indexes Build and manage index-organized tables Explain and plan OLTP, DSS, and hybrid systems

Copyright © 2003, Oracle. All rights reserved.


The Role of the Database Administrator

• • •

Application tuning is the most important part of tuning. DBAs are not always directly involved in application tuning. However, DBAs must be familiar with the impact that poorly written SQL statements can have upon database performance.

Copyright © 2003, Oracle. All rights reserved.


Moving Tables Using ALTER TABLE

Tables can be moved using the ALTER TABLE command. This allows: • Privileges and constraints to be kept • The table structure to be changed • Movement to another tablespace • The command to be parallelized SQL> ALTER TABLE hr.employees 2 MOVE 3 TABLESPACE users;

Copyright © 2003, Oracle. All rights reserved.


Redefining a Table Online

Online table redefinition enables you to: • Modify the storage parameters of the table • Move the table to a different tablespace in the same schema • Add support for parallel queries • Add or drop partitioning support • Re-create the table to reduce fragmentation • Change the organization of a normal table (heap organized) to an index-organized table and vice versa • Add or drop a column

Copyright © 2003, Oracle. All rights reserved.


B-Tree Indexes Index entry Root

Branch

Leaf

Index entry header Key column length Key column value Row ID

Copyright Š 2003, Oracle. All rights reserved.


Rebuilding Indexes

To assist in the rebuilding of indexes use: • ONLINE: Keeps the index available during the rebuild operation • COMPUTE STATISTICS: Collects the statistics while rebuilding the index

Copyright © 2003, Oracle. All rights reserved.


Compressed Indexes

When creating the index: SQL> 2 3 4

CREATE INDEX emp_last_name_idx ON hr.employees (last_name, first_name) COMPRESS;

When rebuilding the index: SQL> ALTER INDEX emp_last_name_idx 2 REBUILD COMPRESS;

Specify NOCOMPRESS (the default) to disable key compression. Copyright Š 2003, Oracle. All rights reserved.


Bitmap Indexes Table

File 3 Block 10 Block 11 Block 12

Index

Block 13 Start End Key ROWID ROWID

Bitmap

<Blue, 10.0.3, 12.8.3, 1000100100010010100> <Green, 10.0.3, 12.8.3, 0001010000100100000> <Red, 10.0.3, 12.8.3, 0100000011000001001> <Yellow, 10.0.3, 12.8.3, 0010001000001000010>

Copyright Š 2003, Oracle. All rights reserved.


Bitmap Indexes

• • • • •

Used for low-cardinality columns Good for multiple predicates Uses minimal storage space Best for read-only systems Good for very large tables

Copyright © 2003, Oracle. All rights reserved.


Creating and Maintaining Bitmap Indexes SQL> CREATE BITMAP INDEX departments_idx 2 ON hr.departments(manager_id) 3 STORAGE (INITIAL 200K NEXT 200K 4 PCTINCREASE 0 MAXEXTENTS 50) 5* TABLESPACE indx;

Copyright © 2003, Oracle. All rights reserved.


B-Tree Indexes and Bitmap Indexes

B-Tree Indexes

Bitmap Indexes

Suitable for high-cardinality columns

Suitable for low-cardinality columns

Updates on keys relatively inexpensive

Updates to key columns very expensive

Inefficient for queries using AND/OR predicates

Efficient for queries using AND/OR predicates

Row-level locking

Bitmap segment-level locking

More storage

Less storage

Useful for OLTP

Useful for DSS

Copyright Š 2003, Oracle. All rights reserved.


Reverse Key Index

KEY ----1257 2877 4567 6657 8967 9637 9947 ...

ROWID ------------------0000000F.0002.0001 0000000F.0006.0001 0000000F.0004.0001 0000000F.0003.0001 0000000F.0005.0001 0000000F.0001.0001 0000000F.0000.0001 ...

Index on employee_id column

EMPLOYEE_ID ----------7499 7369 7521 7566 7654 7698 7782 ... ...

LAST_NAME ... --------ALLEN SMITH WARD ... JONES MARTIN BLAKE CLARK ...

employees table

Copyright © 2003, Oracle. All rights reserved.


Creating Reverse Key Indexes

Create a reverse key unique index: SQL> 2 3 4 5

CREATE UNIQUE INDEX i1_t1 ON t1(c1) REVERSE PCTFREE 30 STORAGE(INITIAL 200K NEXT 200K PCTINCREASE 0 MAXEXTENTS 50) TABLESPACE indx;

Create a unique index, then alter the index to be reverse key: SQL> CREATE UNIQUE INDEX i2_t1 ON t1(c2); SQL> ALTER INDEX i2_t1 REBUILD REVERSE; Copyright © 2003, Oracle. All rights reserved.


Oracle Enterprise Manager: Index Management

Copyright Š 2003, Oracle. All rights reserved.


Index-Organized Tables Regular table access

IOT access

ROWID

Non-key columns Key column Row header

Copyright Š 2003, Oracle. All rights reserved.


Index-Organized Tables and Heap Tables •

Compared to heap tables, IOTs have: – Faster key-based access to table data – Reduced storage requirements – Secondary indexes and logical rowids

IOTs have the following restrictions: – Must have a primary key – Cannot be clustered

Copyright © 2003, Oracle. All rights reserved.


Creating Index-Organized Tables SQL> CREATE TABLE country 2 ( country_id CHAR(2) 3 CONSTRAINT country_id_nn NOT NULL, 4 country_name VARCHAR2(40), 5 currency_name VARCHAR2(25), 6 currency_symbol VARCHAR2(3), 7 map BLOB, 8 flag BLOB, 9 CONSTRAINT country_c_id_pk 10 PRIMARY KEY (country_id)) 11 ORGANIZATION INDEX 12 TABLESPACE indx 13 PCTTHRESHOLD 20 14 OVERFLOW TABLESPACE users; Copyright © 2003, Oracle. All rights reserved.


IOT Row Overflow indx tablespace Segment = COUNTRY_C_ID_PK IOT_type = IOT Segment_type = INDEX Index_type = IOT - TOP

Rows within

users tablespace Segment = SYS_IOT_OVER_n IOT_type = IOT_OVERFLOW Segment_type = TABLE

Remaining part of the row

PCTTHRESHOLD Copyright © 2003, Oracle. All rights reserved.


Querying dba_tables for IOT Information

SQL> SELECT table_name, iot_name, iot_type 2 FROM dba_tables; TABLE_NAME ----------------COUNTRY SYS_IOT_OVER_2268

IOT_NAME -------COUNTRY

IOT_TYPE -----------IOT IOT_OVERFLOW

Copyright © 2003, Oracle. All rights reserved.


Querying dba_indexes and dba_segments for IOT information SQL> SELECT index_name, index_type, 2 tablespace_name, table_name 2 FROM dba_indexes; INDEX_NAME INDEX_TYPE TABLESPACE --------------- ---------- ---------COUNTRY_C_ID_PK IOT - TOP INDX

TABLE_NAME ---------COUNTRY

SQL> SELECT segment_name, tablespace_name, 2 segment_type 3 FROM dba_segments; SEGMENT_NAME TABLESPACE_NAME SEGMENT_TYPE -----------------------------------------SYS_IOT_OVER_2268 USER TABLE COUNTRY_C_ID_PK INDX INDEX

Copyright © 2003, Oracle. All rights reserved.


Using a Mapping Table

SQL> 2 3 4 5 6 7 8 9 10

CREATE TABLE country ( country_id CHAR(2) CONSTRAINT country_id_nn NOT NULL , country_name VARCHAR2(40) , currency_name VARCHAR2(25) , currency_symbol VARCHAR2(3) , CONSTRAINT country_c_id_pk PRIMARY KEY (country_id)) ORGANIZATION INDEX MAPPING TABLE TABLESPACE users;

Copyright © 2003, Oracle. All rights reserved.


Maintaining a Mapping Table

• •

Collect statistics on a mapping table by analyzing the IOT. Query the dba_indexes view to determine the percentage accuracy of the mapping table. SQL> SELECT index_name, pct_direct_access 2 FROM dba_indexes 3 WHERE pct_direct_access IS NOT NULL;

• •

Rebuild the mapping table if required, using the ALTER TABLE command. Use the MINIMIZE RECORDS_PER_BLOCK clause of ALTER TABLE for the mapping table.

Copyright © 2003, Oracle. All rights reserved.


The ANALYZE Statement

Use the ANALYZE statement to: • VALIDATE STRUCTURE • LIST CHAINED ROWS • •

Collect statistics not used by the optimizer, such as information on free list blocks Sample a number (instead of a percentage) of rows SQL> ANALYZE TABLE hr.employees VALIDATE STRUCTURE;

Copyright © 2003, Oracle. All rights reserved.


Oracle Enterprise Manager: Collect Statistics

Copyright Š 2003, Oracle. All rights reserved.


OLTP Systems

• • • •

High-throughput, insert- and update-intensive Large, continuously growing data volume Concurrent access by many users Tuning goals: – – – –

Availability Speed Concurrency Recoverability

Copyright © 2003, Oracle. All rights reserved.


OLTP Requirements

• •

Explicit extent allocation Indexes: – Not too many (B-tree better than bitmap) – Reverse key for sequence columns – Rebuilt regularly

Clusters for tables in join queries: – Index clusters for growing tables – Hash clusters for stable tables

• •

Materialized views Index-organized tables

Copyright © 2003, Oracle. All rights reserved.


OLTP Application Issues

• • • •

Use declarative constraints instead of application code. Make sure that code is shared. Use bind variables rather than literals for optimally shared SQL. Use the CURSOR_SHARING parameter.

Copyright © 2003, Oracle. All rights reserved.


Decision Support Systems (Data Warehouses) • • •

Queries on large amounts of data Heavy use of full table scans Tuning goals: – Fast response time – Focus on SQL statement tuning

Data

The Parallel Query feature is designed for data warehouse environments

Copyright © 2003, Oracle. All rights reserved.


Data Warehouse Requirements

Storage allocation: • Set the block size and DB_FILE_MULTIBLOCK_READ_COUNT carefully. • •

Make sure that extent sizes are multiples of this parameter value. Run dbms_stats regularly.

Copyright © 2003, Oracle. All rights reserved.


Further Data Warehouse Requirements

Evaluate the need for indexes: – Use bitmap indexes when possible. – Use index-organized tables for (range) retrieval by primary keys. – Generate histograms for indexed columns that are not distributed uniformly.

Clustering: Consider hash clusters for performance access.

Copyright © 2003, Oracle. All rights reserved.


Data Warehouse Application Issues

• •

Parsing time is less important. The execution plan must be optimal: – – – –

Use the Parallel Query feature. Tune carefully, using hints if appropriate. Test on realistic amounts of data. Consider using PL/SQL functions to code logic into queries.

Bind variables are problematic.

Copyright © 2003, Oracle. All rights reserved.


Hybrid Systems OLTP

Data Warehouse

Performs index searches

More full table scans

Uses B-tree indexes

Uses bitmap indexes

Uses reverse key indexes

Uses index-organized tables

CURSOR_SHARING set to Similar can assist performance

CURSOR_SHARING should be left on Exact

Should not use Parallel Query

Employs Parallel Query for large operations

PCTFREE according to expected update activity

PCTFREE can be set to 0

Shared code and bind variables

Literal variables and hints

Uses ANALYZE indexes

Generates histograms

Copyright Š 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to do the following: • Explain the role of the DBA in tuning applications • Move tables using the ALTER TABLE command • • • •

Redefine a table online Create different types of indexes Build and manage index-organized tables Explain and plan OLTP, DSS, and hybrid systems

Copyright © 2003, Oracle. All rights reserved.


Using Materialized Views

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Create materialized views • Refresh materialized views • Create nested materialized views • Create UNION ALL materialized views • •

Explain the use of query rewrites Enable and control query rewrites

Copyright © 2003, Oracle. All rights reserved.


Materialized Views

• • •

Instantiations of a SQL query May be used for query rewrites Refresh types: – Complete or Fast – Force or Never

Refresh modes: – Manual – Automated (synchronous or asynchronous)

Copyright © 2003, Oracle. All rights reserved.


Creating Materialized Views

SQL> 2 3 4 5 6

CREATE MATERIALIZED VIEW depart_sal_sum AS SELECT d.department_name, SUM(e.salary) FROM hr.departments d, hr.employees e WHERE d.department_id = e.department_id GROUP BY d.department_name;

Copyright Š 2003, Oracle. All rights reserved.


Refreshing Materialized Views

The required parameters are: • A list of materialized views to refresh • The refresh method: F-Fast, ?-Force, C-Complete • Set push_deferred_rpc to True, if using updatable materialized views • Refresh after errors – True: Allows the process to continue after an error – False: Refresh will stop with errors (default value)

Atomic refresh – True: All refreshes are done in one transaction – False: Each refresh is a separate transaction SQL> EXEC dbms_mview.refresh ('SALES_MV', 2 'F', '', True, False, 0,0,0, False); Copyright © 2003, Oracle. All rights reserved.


Materialized Views: Manual Refreshing

Refresh specific materialized views: dbms_mview.refresh (’CUST_SALES’, parallelism => 10);

Refresh materialized views based on one or more base tables: dbms_mview.refresh_dependent (’SALES’);

Refresh all materialized views that are due to be refreshed: dbms_mview.refresh_all_mviews;

Copyright © 2003, Oracle. All rights reserved.


Nested Materialized Views

TOTAL_SALES

PROD_MV

PRODUCTS

Level 2

SALES_CUST_MV

CUSTOMERS

Level 1

SALES

Copyright Š 2003, Oracle. All rights reserved.

Level 0


Nested Materialized View Example

Copyright Š 2003, Oracle. All rights reserved.


Union All Materialized Views

Copyright Š 2003, Oracle. All rights reserved.


Query Rewrite Overview

• • • •

To use materialized views instead of the base tables, a query must be rewritten. Query rewrites are transparent and do not require any special privileges on the materialized view. Materialized views can be enabled or disabled for query rewrites. Query rewrites can: – Ignore alphabetic case – Recognize equivalent joins – Compare the defining text of a named view

Copyright © 2003, Oracle. All rights reserved.


Query Rewrites

• • •

The QUERY_REWRITE_ENABLED initialization parameter must be set to True. The QUERY REWRITE privilege allows users to enable materialized views. The Summary Advisor of the dbms_olap package has options to use materialized views.

Copyright © 2003, Oracle. All rights reserved.


Creating a Materialized View

SQL> CREATE MATERIALIZED VIEW sales_summary 2 TABLESPACE users 3 PARALLEL (DEGREE 4) 4 BUILD IMMEDIATE 5 ENABLE QUERY REWRITE 6 AS 7 SELECT p.prod_name, 8 SUM (s.quantity_sold), 8 SUM (s.amount_sold) 9 FROM sales s, products p 10 WHERE s.prod_id = p.prod_id 11 GROUP BY p.prod_name;

Copyright © 2003, Oracle. All rights reserved.


Materialized Views and Query Rewrites: Example SQL> 2 3 4 5

SELECT p.prod_name,SUM (s.quantity_sold), SUM (s.amount_sold) FROM sales s, products p WHERE s.prod_id = p.prod_id GROUP BY p.prod_name;

SQL> select operation, object_name 2 from v$sql_plan 3 where object_name like 'SALES%'; OPERATION NAME ---------------------- ----------------SELECT STATEMENT TABLE ACCESS SALES_SUMMARY Copyright Š 2003, Oracle. All rights reserved.


Enabling and Controlling Query Rewrites •

Initialization parameters: – OPTIMIZER_MODE – QUERY_REWRITE_ENABLED – QUERY_REWRITE_INTEGRITY

Dynamic and session-level parameters: – QUERY_REWRITE_ENABLED – QUERY_REWRITE_INTEGRITY Hints: REWRITE and NOREWRITE

Dimensions

Copyright © 2003, Oracle. All rights reserved.


Disabling Query Rewrites: Example

SQL> 2 3 4 5 6

SELECT /*+ NOREWRITE */ p.prod_name, SUM (s.quantity_sold), SUM (s.amount_sold) FROM sales s, products p WHERE s.prod_id = p.prod_id GROUP BY p.prod_name;

SQL> 2 3 4

SELECT p.operation, p.object_name FROM v$sql_plan p, v$sql s WHERE p.address = s.address AND sql_text LIKE 'SELECT /*+ NO%';

Copyright Š 2003, Oracle. All rights reserved.


Union All Query Rewrite CREATE MATERIALIZED VIEW sales_cube_mv ENABLE QUERY REWRITE AS SELECT ... GROUPING_ID(calendar_year,……) gid, GROUPING(calendar_year) grp_y, ... GROUPING(cust_city) grp_c, FROM sales s, times t, customers c WHERE s.time_id=t.time_id AND s.cust_id=c.cust_id GROUP BY GROUPING SETS( (calendar_year, cust_city), (calendar_year,..., cust_state_province), (calendar_year,..., cust_city));

Copyright © 2003, Oracle. All rights reserved.


Using the dbms_mview Package

The package contains the following procedures: • explain_mview • explain_rewrite • refresh • refresh_all_mviews

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to do the following: • Create materialized views • Refresh materialized views • Creating nested materialized views • Create UNION ALL materialized views • •

Explain the use of query rewrites Enable and control query rewrites

Copyright © 2003, Oracle. All rights reserved.


Monitoring and Detecting Lock Contention

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Define levels of locking • Identify causes of contention • Prevent locking problems • Use Oracle utilities to detect lock contention • Resolve contention in an emergency • Resolve deadlock conditions

Copyright © 2003, Oracle. All rights reserved.


Locking Mechanism

• •

Automatic management High level of data concurrency – Row-level locks for DML transactions – No locks required for queries

• • •

Multi-version consistency Exclusive and Share lock modes Locks held until commit or rollback operations are performed

Copyright © 2003, Oracle. All rights reserved.


Data Concurrency

Transaction 2

Transaction 1 SQL> UPDATE employees 2 SET salary=salary*1.1 3 WHERE id= 24877; 1 row updated.

SQL> UPDATE employees 2 SET salary=salary*1.1 3 WHERE id= 24878; 1 row updated.

SQL> UPDATE employees 2 SET salary=salary+1200; 13120 rows updated.

SQL> SELECT salary 2 FROM employees 3 WHERE id = 10; SALARY --------1000

Copyright Š 2003, Oracle. All rights reserved.


Two Types of Locks

DML or data locks: – Table-level locks – Row-level locks

(TM)

DDL or dictionary locks (TX)

Copyright © 2003, Oracle. All rights reserved.


DML Locks

A DML transaction gets at least two locks: • A shared table lock • An exclusive row lock

Copyright © 2003, Oracle. All rights reserved.


Enqueue Mechanism

The enqueue mechanism keeps track of: • Users waiting for locks • The requested lock mode • The order in which users requested the lock

Copyright © 2003, Oracle. All rights reserved.


Table Lock Modes

These table lock modes are automatically assigned by the Oracle server: • Row Exclusive (RX): INSERT, UPDATE, DELETE •

Row Share (RS): SELECT... FOR UPDATE

Copyright © 2003, Oracle. All rights reserved.


Manually Locking a Table

Manually acquired in LOCK TABLE statement: SQL> LOCK TABLE hr.employees IN share MODE;

Share (S) – No DML operations allowed – Implicitly used for referential integrity

Copyright © 2003, Oracle. All rights reserved.


Manually Locking a Table

Share Row Exclusive (SRX) – No DML operations or Share mode allowed – Implicitly used for referential integrity – No index is required on the foreign key column in the child table

Exclusive (X) – No DML or DDL operations allowed by other sessions – No manual locks allowed by other sessions – Queries are allowed

Copyright © 2003, Oracle. All rights reserved.


DML Locks in Blocks Block Header TX slot 1 TX slot 2

1

Row 6

Lock bytes

2

Row 1

Copyright Š 2003, Oracle. All rights reserved.


DDL Locks

Exclusive DDL locks are required for: – DROP TABLE statements – ALTER TABLE statements – (The lock is released when the DDL statement completes.)

Shared DDL locks are required for: – CREATE PROCEDURE statements – AUDIT statements – (The lock is released when the DDL parse completes.)

Breakable parse locks are used for invalidating statements in the shared SQL area. Copyright © 2003, Oracle. All rights reserved.


Possible Causes of Lock Contention

• • • •

Unnecessarily high locking levels Long-running transactions Uncommitted changes Other products imposing higher-level locks

Copyright © 2003, Oracle. All rights reserved.


Diagnostic Tools for Monitoring Locking Activity

Transaction 1

Transaction 2

Transaction 3

UPDATE employees SET salary = salary x 1.1; UPDATE employees SET salary = salary x 1.1 WHERE empno = 1000;

v$lock v$locked_object dba_waiters dba_blockers

UPDATE employees SET salary = salary x 1.1 WHERE empno = 2000;

Copyright Š 2003, Oracle. All rights reserved.


Guidelines for Resolving Contention Transaction 1

Transaction 2

UPDATE employees SET salary = salary x 1.1 WHERE empno = 1000;

9:00

9:05 10:30 >COMMIT/ROLLBACK;

>ALTER

UPDATE employees SET salary = salary x 1.1 WHERE empno = 1000;

11:30 1 row updated;

SYSTEM KILL SESSION ‘10,23’;

Copyright © 2003, Oracle. All rights reserved.


Performance Manager: Locks

Copyright Š 2003, Oracle. All rights reserved.


Deadlocks

Transaction

Transaction

1

2

UPDATE employees SET salary = salary x 1.1 WHERE empno = = 1000;

9:00

UPDATE employees SET manager = 1342 WHERE empno = 2000;

UPDATE employees SET salary = salary x 1.1 WHERE empno = 2000;

9:15

UPDATE employees SET manager = 1342 WHERE empno = 1000;

ORA-00060: Deadlock detected while waiting for resource

9:16

Copyright Š 2003, Oracle. All rights reserved.


Deadlocks

Server process

ORA-00060: Deadlock detected while waiting for resource

SID_ora_PID.trc UNIX

Trace file in USER_DUMP_DEST directory

Copyright Š 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned to do the following: • Define levels of locking • Identify causes of contention • Prevent locking problems • Use Oracle utilities to detect lock contention • Resolve contention in an emergency • Resolve deadlock conditions

Copyright © 2003, Oracle. All rights reserved.


Tuning the Operating System

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Describe different system architectures • Describe the primary steps of OS tuning • Identify similarities between OS and DB tuning • Understand virtual memory and paging • Explain the difference between a process and a thread

Copyright © 2003, Oracle. All rights reserved.


Operating System Tuning Memory SGA

Non-Oracle processes

Oracle processes OS

OS and DB files Copyright Š 2003, Oracle. All rights reserved.


System Architectures

The Oracle database can run on different system architectures. Some examples are: • Uni Processor systems • Symmetric multiprocessing systems (SMP) • Massively parallel processing systems (MPP) • Clustered systems • Nonuniform memory architecture systems (NUMA)

Copyright © 2003, Oracle. All rights reserved.


Virtual and Physical Memory

MMU

Virtual memory

Page table possibly with ISM Copyright Š 2003, Oracle. All rights reserved.

Physical memory


Paging and Swapping Memory

Process

Page

Swap device

Copyright Š 2003, Oracle. All rights reserved.


Tuning Memory

• • •

Database tuning can improve paging performance by locking SGA into real memory. The DBA should monitor real and virtual memory use. The DBA should use intimate shared memory, if it is available.

Copyright © 2003, Oracle. All rights reserved.


Tuning I/O Memory

CPU System bus

I/O controller

I/O controller

Copyright Š 2003, Oracle. All rights reserved.

I/O controller


Understanding Different I/O System Calls

Operating systems can perform disk I/O in two different ways: • Normal (blocking) I/O • Asynchronous (nonblocking) I/O is implemented on most platforms and file systems

Copyright © 2003, Oracle. All rights reserved.


CPU Tuning

Guidelines: – Maximum CPU busy rate: 90% – Maximum OS/User processing ratio: 40/60 – CPU load balanced across CPUs

Monitoring: – CPU – Process

Copyright © 2003, Oracle. All rights reserved.


Process versus Thread P r o c e s s e s T h r e a d s

Oracle processes S Q L P L U S

p m o n

a r c 0

SQL*PLUS process Thread

s m o n

d b w 0

l g w r

Oracle.exe process Threads

Copyright Š 2003, Oracle. All rights reserved.

c k p t


Summary

In this lesson, you should have learned how to: • Describe different system architectures • Describe the primary steps of OS tuning • Identify similarities between OS and DB tuning • Understand virtual memory and paging • Explain the difference between a process and a thread

Copyright © 2003, Oracle. All rights reserved.


Workshop Overview

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Follow the Oracle tuning methodology to diagnose and resolve performance problems • Improve your tuning skills • Use Oracle tools to diagnose performance problems

Copyright © 2003, Oracle. All rights reserved.


Approach to Workshop

The workshop is intended to provide: • A group-oriented and interactive experience • Intensive hands-on diagnosis and problem resolution • Proactive participant involvement

Copyright © 2003, Oracle. All rights reserved.


Workshop Background

The workshop is based on the XYZ Company, a fictional entity that has the following characteristics: • XYZ Company is new and still small: – Shares a database server with other companies – Currently has four employees who use the database

• • • •

System was set up by a part-time DBA trainee Database performance is unacceptable XYZ Company is seeking help from a consulting group Number of database users will be increasing

Copyright © 2003, Oracle. All rights reserved.


Workshop Outline

You are provided with scripts and tools to: • Configure your database with a tuning problem based on a selected scenario • Execute a simulated workload against your detuned database • Collect performance statistics for your database • Analyze your data and make changes to improve your database performance • Confirm that your changes have been beneficial by executing the same or a more intense workload simulation

Copyright © 2003, Oracle. All rights reserved.


Workshop Configuration

Workshop folder

Command window

Windows Explorer

SQL*Plus session in E:\Labs

Copyright Š 2003, Oracle. All rights reserved.


Workshop Setup: Overview

Step 1: Start the setup script Step 2: Respond to prompts Step 3: Verify configuration Step 4: Preserve your setup Step 5: Open the workshop window

Copyright Š 2003, Oracle. All rights reserved.


Workshop Setup: Step 1

Copyright Š 2003, Oracle. All rights reserved.


Workshop Setup: Step 2

… …

Copyright © 2003, Oracle. All rights reserved.


Workshop Setup: Step 3

Copyright Š 2003, Oracle. All rights reserved.


Workshop Setup: Step 3

Copyright Š 2003, Oracle. All rights reserved.


Workshop Setup: Step 4

Copyright Š 2003, Oracle. All rights reserved.


Workshop Setup: Step 5

Copyright Š 2003, Oracle. All rights reserved.


Steps to Run a Scenario 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Run the setup script for your selected scenario. Confirm that the Statspack job is running. Generate a workload for the current four users. Query tables to gather statistics interactively. Identify two snapshots and generate a Statspack report from them. Analyze your data and determine what problems to address. Make changes to improve performance. Repeat these steps (except step 1) until you achieve acceptable performance. Repeat steps 2 through 8 again, substituting the workload for the planned 20 users in step 2. Prepare your class presentation when you are satisfied with your work. Copyright Š 2003, Oracle. All rights reserved.


Run Scenario Setup Script

Scenario Description

Setup Icon

Shared pool performance

1.bat

Database buffer cache performance

2.bat

Redo log buffer performance

3.bat

Data access performance

4.bat

PGA performance

5.bat

Assorted performance areas

6.bat

Copyright Š 2003, Oracle. All rights reserved.


Check Statspack Job

SQL> CONNECT perfstat/perfstat

SQL> SHOW PARAMETER job_queue_processes

SQL> SELECT job, log_user, what, next_date, 2 next_sec, interval 3 FROM user_jobs;

Copyright Š 2003, Oracle. All rights reserved.


Check Statspack Job SQL> @E:\Labs\student\Wkshop\Setup\spauto PL/SQL procedure successfully completed. Job number for automated statistics collection for this instance ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . . . JOBNO ---------1 Job queue process ~~~~~~~~~~~~~~~~~ . . . NAME TYPE VALUE --------------------- ------------- ------------job_queue_processes integer 4 Next scheduled run ~~~~~~~~~~~~~~~~~~ . . . JOB NEXT_DATE NEXT_SEC ---------- --------------- ---------1 09-APR-03 23:00:00

Copyright Š 2003, Oracle. All rights reserved.


Generate a Workload

Simulates 4 users to test current load performance

Simulates 20 users to test future load performance

Copyright Š 2003, Oracle. All rights reserved.


Collect Statistics Interactively

Copyright Š 2003, Oracle. All rights reserved.


Identify Statspack Snapshots

Copyright Š 2003, Oracle. All rights reserved.


Create Statspack Report

Copyright Š 2003, Oracle. All rights reserved.


Analyze Statistics

Copyright Š 2003, Oracle. All rights reserved.


Apply Desired Changes

SQL> ALTER SYSTEM 2 SET db_cache_size = 25165824 3 SCOPE = BOTH; System altered. SQL> ALTER SYSTEM 2 SET log_buffer = 524288 3 SCOPE = SPFILE; System altered.

Copyright Š 2003, Oracle. All rights reserved.


Evaluate Impact of Changes

T

T Content?

Tried 20 users?

Repeat steps 2 through 6

Want to try 20 users?

Go to step 10

T

Go to step 10

Copyright Š 2003, Oracle. All rights reserved.

Go to step 9


Test Performance with More Users

Copyright Š 2003, Oracle. All rights reserved.


Summarize Findings

• • • • •

What changes you made Why you made those changes How your changes impacted performance What else you might have investigated How you could improve your methodology

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Implement the Oracle tuning methodology • Drill down the performance problems suggested by Statspack reports • Tune a database to support current and anticipated work loads • Justify the changes that are made to a database configuration for tuning purposes

Copyright © 2003, Oracle. All rights reserved.


Tuning Undo Segments

Copyright Š 2003, Oracle. All rights reserved.


Objectives

After completing this lesson, you should be able to do the following: • Describe the concept of automatic undo management • Create and maintain the automatic managed undo tablespace • Set the retention period • Use dynamic performance views to check rollback segment performance • Reconfigure and monitor rollback segments • Define the number and sizes of rollback segments • Allocate rollback segments to transactions Copyright © 2003, Oracle. All rights reserved.


Undo Segments: Usage

Transaction rollback

Read consistency Undo (Rollback) segment

Control files Transaction recovery Data files Copyright Š 2003, Oracle. All rights reserved.

Redo log files


Using Less Undo Space Per Transaction

• •

The design of the application should allow users to commit transactions regularly. Developers should not code long transactions.

Copyright © 2003, Oracle. All rights reserved.


Using Less Undo Space

Import – Set COMMIT = Y – Size the set of rows with the BUFFER keyword

Export: Set CONSISTENT = N

SQL*Loader operations: Set the commit intervals with ROWS

Developers should make sure that the transactions are not unduly long

Copyright © 2003, Oracle. All rights reserved.


Automatic Undo Management

• •

The automatic undo management feature simplifies the management of undo segments. Set the UNDO_MANAGEMENT parameter to: – AUTO for automatic undo management – MANUAL for managing rollback segments manually The UNDO_RETENTION parameter specifies the time (in seconds) to retain undo information.

Copyright © 2003, Oracle. All rights reserved.


Automatic Undo Management Tablespaces

Create a tablespace for automatic undo management in one of the following ways: – Using the UNDO TABLESPACE clause in the CREATE DATABASE command – Using the CREATE UNDO TABLESPACE command

MINIMUM EXTENT and DEFAULT STORAGE are

system generated for undo tablespaces. Restrictions: – Database objects cannot be created in this tablespace. – You can specify the data file and the extent_management clause only. Copyright © 2003, Oracle. All rights reserved.


Altering an Undo Tablespace

• •

The ALTER TABLESPACE command can be used to make changes to undo tablespaces. The following example adds another data file to the undo tablespace: ALTER TABLESPACE undotbs1 ADD DATAFILE ‘/u02/oradata/testdb/undotbs1_02.dbf’ AUTOEXTEND ON;

You cannot take an undo tablespace offline that has an active undo segment.

Copyright © 2003, Oracle. All rights reserved.


Switching Undo Tablespaces

• • •

A DBA can switch from using one undo tablespace to another. Only one undo tablespace per instance can be assigned as active. Switching is performed by using the ALTER SYSTEM command: ALTER SYSTEM SET UNDO_TABLESPACE=undotbs2;

Copyright © 2003, Oracle. All rights reserved.


Dropping an Undo Tablespace

The DROP TABLESPACE command can be used to drop an undo tablespace: DROP TABLESPACE undotbs_2;

An undo tablespace can be dropped only if: – It is not the active undo tablespace – It is not utilized by an active transaction

Queries that require a read-consistent image of undo data that is stored in an dropped undo tablespace will return an error.

Copyright © 2003, Oracle. All rights reserved.


Setting UNDO_RETENTION

UNDO_RETENTION parameter: • • •

Is specified in time (seconds) A target value. If space is required, then committed data will be overwritten. Controls the amount of undo data that is to be retained after committing

Copyright © 2003, Oracle. All rights reserved.


Other Parameters for Automatic Undo Management • • •

UNDO_MANAGEMENT: Specifies whether the database uses Auto or Manual mode UNDO_TABLESPACE: Specifies a particular undo tablespace to be used UNDO_SUPPRESS_ERRORS: Set to True, this parameter suppresses errors while attempting to execute manual operations, such as ALTER ROLLBACK SEGMENT ONLINE, while in Auto mode

Copyright © 2003, Oracle. All rights reserved.


Monitoring Automatic Undo Management

Use v$undostat view to monitor undo segments.

This view is available for both Manual and Auto mode. The undoblks column displays the number of undo blocks allocated.

Copyright © 2003, Oracle. All rights reserved.


Using v$undostat

SQL> SELECT begin_time, end_time, undoblks, 2 txncount, maxquerylen 3 FROM v$undostat; BEGIN_TIME --------------25-oct-01:06:04 25-oct-01:05:44 25-oct-01:05:34 25-oct-01:05:24 25-oct-01:05:14 ……

END_TIME UNDOBLKS TXNCOUNT --------------- -------- -------25-oct-01:06:14 234 12 25-oct-01:05:54 587 21 25-oct-01:05:44 1,187 45 25-oct-01:05:34 346 15 25-oct-01:05:24 642 23

Copyright © 2003, Oracle. All rights reserved.


Performance Manager: Rollback/Undo

Copyright Š 2003, Oracle. All rights reserved.


Overview

Setting manual rollback segments is: • Optional in the Oracle database • Time consuming for the DBA

Copyright © 2003, Oracle. All rights reserved.


Rollback Segment Activity T1 >update >update >insert >insert >update

1

2 T1 T2

T2 >update >update >insert >insert >update

T4 4

Inactive extent Copyright Š 2003, Oracle. All rights reserved.

T3 3

Active extent


Rollback Segment Header Activity

• •

Rollback segment headers contain entries for their respective transactions. Every transaction must have update access. T1 T2

1 2

T3 T4 T5

4

T6

Copyright © 2003, Oracle. All rights reserved.

3


Growth of Rollback Segments

1

4

2

1

2

5

3

3 4

Active extent

New extent

Inactive extent

Copyright Š 2003, Oracle. All rights reserved.


Tuning Manually Managed Rollback Segments Goals in tuning rollback segments: • Transactions should never wait for access to rollback segments. • Rollback segments should not extend during normal running. • Users and utilities should try to use less rollback per transaction. • No transaction should ever run out of rollback space. • Readers should always see the read-consistent images they need.

Copyright © 2003, Oracle. All rights reserved.


Diagnostic Tools

v$system_event v$waitstat

Statspack output 1

T3 T4 T5

2

v$rollstat v$rollname

Header

v$sysstat

v$transaction v$session

4

3

Copyright Š 2003, Oracle. All rights reserved.

Data SGA


Diagnosing Contention for Manual Rollback Segment Header If the number of waits for any rollback header is greater than 1% of the total number of requests, then create more rollback segments. SQL> 2 or SQL> 2 3 or SQL> 2 3

SELECT class, count FROM v$waitstat WHERE class LIKE '%undo%'; SELECT event, total_waits, total_timeouts FROM v$system_event WHERE event LIKE 'undo segment tx slot'; SELECT sum(waits)* 100 /sum(gets) "Ratio", sum(waits) "Waits", sum(gets) "Gets" FROM v$rollstat;

Copyright Š 2003, Oracle. All rights reserved.


Guidelines: Number of Manual Rollback Segments (RBSs) • •

OLTP: One RBS for four transactions Batch: One rollback segment for each concurrent job SQL> SET TRANSACTION USE 2 ROLLBACK SEGMENT large_rbs;

Large rollback Small RBS Small RBS

Small RBS Small RBS

Small RBS Copyright © 2003, Oracle. All rights reserved.


Guidelines: Sizing Manual Rollback Segments Probability of extending 0.50 0.40 0.30 0.20 0.10 0.00 0

Rollback segment 1 = Rollback segment 2 INITIAL = NEXT = 2n Mb MINEXTENTS = 20 OPTIMAL = 20 * INITIAL Copyright Š 2003, Oracle. All rights reserved.

10

20

30

Number of extents

40


Sizing Transaction Rollback Data

• • • •

Deletes are expensive for rollback activity. Inserts use minimal rollback space. Updates use rollback space, depending on the amount of data changed in the transaction. Index maintenance adds rollback. SQL> SELECT s.username, t.used_ublk, 2 t.start_time 3 FROM v$transaction t, v$session s 4 WHERE t.addr = s.taddr;

Copyright © 2003, Oracle. All rights reserved.


Sizing Transaction Rollback Data

The number of bytes in rollback segments before execution of statements: SQL> SELECT usn,writes 2 FROM v$rollstat;

After execution of statements: SQL> SELECT usn,writes 2 FROM v$rollstat;

Copyright © 2003, Oracle. All rights reserved.


Possible Problems Caused by Small Rollback Segments • •

The transaction fails for lack of rollback space. A “snapshot too old” error occurs if the statement requires data that has been modified, committed, and the rollback data is no longer available.

Copyright © 2003, Oracle. All rights reserved.


Summary

In this lesson, you should have learned how to: • Describe the concept of automatic undo management • Create and maintain the automatic managed undo tablespace • Set the retention period • Use dynamic performance views to check rollback segment performance • Reconfigure and monitor rollback segments • Define the number and sizes of rollback segments • Allocate rollback segments to transactions

Copyright © 2003, Oracle. All rights reserved.


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.