6599584-Oracle9i-Performance-Tuning by DELEEP AUGUSTIAN

Oracle9i Database Performance Tuning Electronic Presentation

D11299GC21 Edition 2.1 June 2003 D38323

Authors

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

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?

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

Tuning Goals

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

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

Tuning Steps During Development

• • • • • •

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

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

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.

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.

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.

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

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

Diagnostic and Tuning Tools

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.

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

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.

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

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

Oracle Enterprise Manager Console

Performance Manager

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

Tuning Using Oracle Expert

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

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

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

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

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.

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

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

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

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#

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.

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

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

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

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

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

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

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

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.

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

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

Database Configuration and I/O Issues

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

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

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.

Distributing Files Across Devices

• • •

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

IO Topology Support

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.

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 …;

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

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

Performance Manager: I/O Statistics

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.

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.

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.

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");

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.

Full Checkpoints

Two categories of full checkpoints • Complete • Tablespace

Performance Manager: Response Time

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

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

Redo Log Groups and Members LGWR

Group 1

Group 2

Group 3 Disk 1

Member

Disk 2 Member

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

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>

• •

Diagnostic Tools

v$archive_dest v$archived_log v$archive_processes

LOG_ARCHIVE_DEST_STATE_n

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

Tuning the Shared Pool

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

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

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

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

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

Important Shared Pool Latches

• •

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

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

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.

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

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

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 %';

Sharing Cursors

Values for CURSOR_SHARING are: • • •

Exact Similar Force

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

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.

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

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.

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;

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.

•

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

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

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’);

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;

Other Parameters Affecting the Library Cache • • • •

OPEN_CURSORS CURSOR_SPACE_FOR_TIME SESSION_CACHED_CURSORS CURSOR_SHARING

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

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

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.

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

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

dc_histogram_defs

0.0

dc_object_ids

0.0

440

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

Performance Manager: Shared Pool Statistics

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

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#;

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

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

Tuning the Buffer Cache

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

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

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

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.

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.

•

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';

Using the Buffer Cache Advisory

Managing the Database Buffer Cache SGA Server

LRU lists

Checkpoint Queue

. . . .

DB buffer cache

2 3 4

LGWR

Managing the Database Buffer Cache DB buffer cache

SGA Server

LRU lists

Checkpoint Queue

. . . .

DBWn

LGWR

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

Statspack Report

Performance Manager

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

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

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

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

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

•

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

Using Multiple Buffer Pools SGA DB buffer caches

Recycle pool

Keep pool

Default pool

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.

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);

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';

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

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

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

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.

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

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

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;

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.

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

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

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.

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

Tuning DBWn I/O

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

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

Dynamic Instance Resizing

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

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.

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.

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

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

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.

• •

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;

•

Summary

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

Sizing Other SGA Structures

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

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

WHERE employee_id=736;

Data files Redo log files

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.

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

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

Performance Manager

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');

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.

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

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

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

Tuning the Oracle Shared Server

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

Overview

Dispatcher processes

Oracle server code program interface

Request queue

Shared server processes

Response queues

System Global Area

Oracle background processes

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

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.

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

Monitoring Process Usage

The v$circuit view displays: • • •

Server address Dispatcher address User session address

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.

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.

Obtaining Dictionary Information

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

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

Optimizing Sort Operations

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

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

Work Area Groups and PGA Cache Hit Percentages Percent executions

Optimal size One-pass size Multi-pass size

100%

97%

94%

0% …

64-128KB

128-256KB

0% …

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;

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

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;

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

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

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

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

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.

The Sorting Process and Temporary Space Temporary tablespace Permanent

Objects

One single sort segment

temp01.dbf

temp02.dbf

temp04.dbf

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)

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

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.

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

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

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,

max_sort_blocks

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

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

-----------

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

• •

EXTENTS

TEMP

BLOCKS 4

200

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

Using Resource Manager

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

Overview

• •

Manage mixed workload Control system performance Database resource manager OLTP user

OLTP More resources DSS Less resources

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)

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

MAILDB PLAN 40% @ L1

70% @ L1

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

Resource Allocation Methods

Method

Resource

Recipient

Round-robin

CPU to sessions

Groups

Emphasis

CPU to groups

Plans

Absolute

Parallel degree

Plans

The Initial Plan: SYSTEM_PLAN Allocation methods

Resource consumer group

P1CPU

P2CPU P3CPU P1//

SYS_GROUP

100%

OTHER_GROUPS

100%

LOW_GROUP

100%

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.

Oracle Enterprise Manager: Resource Manager

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 );

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' );

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.

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

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.

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.

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

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();

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' );

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;

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 );

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');

•

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

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;

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

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

SQL Statement Tuning

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

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

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

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

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';

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.

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

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;

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.

Using Private Outlines

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

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.

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

Oracle Enterprise Manager: Maintaining Stored Outlines

Overview of Diagnostic Tools

• • •

Statspack EXPLAIN PLAN SQL trace and TKPROF

• •

SQL*Plus autotrace feature Oracle SQL Analyze

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

Performance Manager: Top SQL

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;

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);

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.

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});

Formatting the Trace File with TKPROF

$ tkprof tracefile.trc output.txt [options]

tracefile.trc

output.txt

USER_DUMP_DEST

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

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 ]

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

Managing Statistics

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

Managing Statistics

Use the dbms_stats package:

• • • • •

gather_table_stats gather_index_stats gather_schema_stats gather_database_stats gather_stale_stats

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

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

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

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.

•

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

Index Tuning Wizard

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

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

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');

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');

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');

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

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.

Gathering System Statistics

Procedures of the dbms_stats package used to collect system statistics:

• • •

gather_system_stats set_system_stats get_system_stats

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');

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');

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');

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

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 */ );

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.

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 */ );

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

Using Oracle Blocks Efficiently

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

Database Storage Hierarchy

Tablespace

Segments

Extents Extents

Extents

Allocation of Extents

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

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.

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.

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

The High-Water Mark

Extent 1 Empty blocks (rows deleted) Extent 2

Segment header block

Empty blocks (never used)

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

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

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.

Database Block Size

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

Segments

Extents

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

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

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

PCTFREE and PCTUSED

Inserts

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

Migration and Chaining Migration

Chaining

Index

Table

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 …

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 ...

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.

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.

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;

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.

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;

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;

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

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

Data Storage Structures

Heap table

Cluster

Indexorganized table

Organization by value Heap

Clustered

Sorted

Partitioned table

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

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

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

Cluster Types Index cluster

Hash cluster

Hash function

Situations Where Clusters Are Useful

Criterion Uniform key distribution

Index

Hash

Evenly distributed key values

Rarely updated key

Often joined master-detail tables

Predictable number of key values

Queries using equality predicate on key

Partitioning Methods

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

Range partitioning

Hash partitioning

List partitioning

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

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

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) );

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

Partitioned Indexes for Scalable Access Global Nonpartitioned index Global Partitioned Index

Table partition

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’);

Partition-Wise Join

3 1

Full partition-wise join

Nonpartition-wise join

Partial partition-wise join Query slave

Partition

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

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’);

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

Application Tuning

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

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.

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;

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

B-Tree Indexes Index entry Root

Branch

Leaf

Index entry header Key column length Key column value Row ID

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

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;

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>

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

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;

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

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

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;

Oracle Enterprise Manager: Index Management

Index-Organized Tables Regular table access

IOT access

ROWID

Non-key columns Key column Row header

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

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

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

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

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;

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.

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;

Oracle Enterprise Manager: Collect Statistics

OLTP Systems

• • • •

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

Availability Speed Concurrency Recoverability

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

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.

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

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.

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.

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.

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

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

Using Materialized Views

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

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)

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;

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;

Nested Materialized Views

TOTAL_SALES

PROD_MV

PRODUCTS

Level 2

SALES_CUST_MV

CUSTOMERS

Level 1

SALES

Level 0

Nested Materialized View Example

Union All Materialized Views

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

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.

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;

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

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%';

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));

Using the dbms_mview Package

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

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

Monitoring and Detecting Lock Contention

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

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

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

Two Types of Locks

•

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

•

(TM)

DDL or dictionary locks (TX)

DML Locks

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

Enqueue Mechanism

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

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

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

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

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

Row 6

Lock bytes

Row 1

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.)

•

Possible Causes of Lock Contention

• • • •

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

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;

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’;

Performance Manager: Locks

Deadlocks

Transaction

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

Deadlocks

Server process

ORA-00060: Deadlock detected while waiting for resource

SID_ora_PID.trc UNIX

Trace file in USER_DUMP_DEST directory

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

Tuning the Operating System

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

Operating System Tuning Memory SGA

Non-Oracle processes

Oracle processes OS

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)

Virtual and Physical Memory

MMU

Virtual memory

Physical memory

Paging and Swapping Memory

Process

Page

Swap device

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.

Tuning I/O Memory

CPU System bus

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

CPU Tuning

•

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

•

Monitoring: – CPU – Process

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

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

Workshop Overview

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

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

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

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

Workshop Configuration

Workshop folder

Command window

Windows Explorer

SQL*Plus session in E:\Labs

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

Workshop Setup: Step 1

Workshop Setup: Step 2

… …

Workshop Setup: Step 3

Workshop Setup: Step 4

Workshop Setup: Step 5

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

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;

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

Generate a Workload

Simulates 4 users to test current load performance

Simulates 20 users to test future load performance

Collect Statistics Interactively

Identify Statspack Snapshots

Create Statspack Report

Analyze Statistics

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.

Evaluate Impact of Changes

T Content?

Tried 20 users?

Repeat steps 2 through 6

Want to try 20 users?

Go to step 10

Go to step 9

Test Performance with More Users

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

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

Tuning Undo Segments

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

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.

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

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.

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.

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;

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.

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

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

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.

•

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

Performance Manager: Rollback/Undo

Overview

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

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

2 T1 T2

T2 >update >update >insert >insert >update

T4 4

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

Growth of Rollback Segments

3 4

Active extent

New extent

Inactive extent

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.

Diagnostic Tools

v$system_event v$waitstat

Statspack output 1

T3 T4 T5

v$rollstat v$rollname

Header

v$sysstat

v$transaction v$session

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;

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

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

Number of extents

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;

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;

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.

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