Oracle9i Database Performance Tuning Electronic Presentation
D11299GC21 Edition 2.1 June 2003 D38323
Authors
Copyright © Oracle Corporation, 2003. All rights reserved.
Peter Kilpatrick Shankar Raman Jim Womack
This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:
Technical Contributors and Reviewers Mirza Ahmad David Austin Ruth Baylis Howard Bradley Pietro Colombo Michele Cyran Benoit Dagerville Connie Dialeris Joel Goodman Scott Gossett Lilian Hobbs Alexander Hunold Sushil Kumar Roderick Manalac Howard Ostrow Darren Pelacchi Sander Rekveld Maria Senise Ranbir Singh Janet Stern Wayne Stokes Tracy Stollberg Harald Van Breederode John Watson Publisher Joseph Fernandez
Restricted Rights Legend Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to be Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988). This material or any portion of it may not be copied in any form or by any means without the express prior written permission of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminal penalties. If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with “Restricted Rights,” as defined in FAR 52.227-14, Rights in DataGeneral, including Alternate III (June 1987). The information in this document is subject to change without notice. If you find any problems in the documentation, please report them in writing to Education Products, Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065. Oracle Corporation does not warrant that this document is error-free. Oracle and all references to Oracle and Oracle products are trademarks or registered trademarks of Oracle Corporation. All other products or company names are used for identification purposes only, and may be trademarks of their respective owners.
Overview of Oracle9i Database Performance Tuning
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Define the roles associated with the database tuning process • Describe the dependencies between tuning in different development phases • Describe service level agreements • Identify tuning goals • Identify common tuning problems • Employ tuning activities during development and production • Balance performance and safety trade-offs Copyright © 2003, Oracle. All rights reserved.
Tuning Questions
•
Who tunes? – – – –
• •
Application designers Application developers Database administrators System administrators
What to tune? How much tuning is required?
Copyright © 2003, Oracle. All rights reserved.
Tuning Phases
Tuning can be divided into different phases: • Application design and programming • Database configuration • Adding a new application to an existing database • Troubleshooting and tuning
Copyright © 2003, Oracle. All rights reserved.
Tuning Goals
Tuning goals are usually specified in terms of: • Minimizing response time • Increasing throughput • Increasing load capabilities • Decreasing recovery time
Copyright © 2003, Oracle. All rights reserved.
Common Performance Problems
•
Bad session management: – Limits scalability to a point that cannot be exceeded – Makes the system one or two orders of magnitude slower than it should be
• •
Bad cursor management Bad relational design: – Unnecessary table joins performed – Usually a result of trying to build an object interface to relational storage
Copyright © 2003, Oracle. All rights reserved.
Tuning Steps During Development
• • • • • •
Tune the design Tune the application Tune memory Tune I/O Tune contention Tune the operating system
Copyright © 2003, Oracle. All rights reserved.
Collect a Baseline Set of Statistics
A baseline set of statistics is used to: • Provide a set of statistics that are collected when the system was operating within the bounds set • Create a hypothesis about what has changed on the system
Copyright © 2003, Oracle. All rights reserved.
Tuning Steps for a Production Database
1. 2. 3. 4. 5. 6.
Define the problem. Examine the host system and Oracle statistics. Consider some common performance errors. Build a conceptual model. Implement and measure the change. Check that the bottleneck has been resolved.
Copyright Š 2003, Oracle. All rights reserved.
Database Server Tuning Methodology
• • • •
Check alert log and trace files for errors. Check the parameter file for any diagnostic or inappropriate parameter setting. Check memory, I/O, and CPU usage. Identify processes with resource usage anomalies. Identify and tune SQL statements that are heavy consumers of CPU or I/O.
Copyright © 2003, Oracle. All rights reserved.
Database Server Tuning Methodology
Tuning response time: • Analyze system performance in terms of work done (CPU or service time) versus time spent waiting for work (wait time). • Determine which component consumes the greatest amount of time. • Drill down to tune that component, if appropriate.
Copyright © 2003, Oracle. All rights reserved.
Performance Versus Safety Trade-Offs
Factors that affect performance: • Multiple control files • Multiple redo log members in a group • Frequent checkpointing • Backing up data files • Performing archiving • Block check numbers • Number of concurrent users and transactions
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Create a good initial design • Define a tuning methodology • Perform production tuning • Establish quantifiable goals • List tuning problems • Decide between performance and safety
Copyright © 2003, Oracle. All rights reserved.
Diagnostic and Tuning Tools
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Identify key tuning components of the alert log file • Identify key tuning components of background trace files • Identify key tuning components of user trace files • Collect statistics with Oracle Enterprise Manager • Describe how Statspack collects statistics • Collect statistics with Statspack • Identify dynamic performance views useful in tuning • Describe other tools used for tuning Copyright © 2003, Oracle. All rights reserved.
Maintenance of the Alert Log File
• •
The alert log file consists of a chronological log of messages and errors. Check the alert log file regularly to: – Detect internal errors (ORA-600) and block corruption errors – Monitor database operations – View the nondefault initialization parameters
•
Remove or trim the file regularly after checking.
Copyright © 2003, Oracle. All rights reserved.
Tuning Components of the Alert Log File
The alert log file contains the following information which can be used in tuning the database: • Checkpoint start and end times • Incomplete checkpoints • Time to perform archiving • Instance recovery start and complete times • Deadlock and timeout errors
Copyright © 2003, Oracle. All rights reserved.
Background Processes Trace Files
•
• •
The Oracle server dumps information about errors detected by any background process into trace files. Oracle Support uses these trace files to diagnose and troubleshoot. These files do not usually contain tuning information.
Copyright © 2003, Oracle. All rights reserved.
User Trace Files
• • • •
Server process tracing can be enabled or disabled at the session or instance level. A user trace file contains statistics for traced SQL statements in that session. User trace files are created on a per server process basis. User trace files can also be created by: – Backup control file to trace – Database SET EVENTs
Copyright © 2003, Oracle. All rights reserved.
Views, Utilities, and Tools
Tools and views that are available to the DBA for determining performance: • Oracle Enterprise Manager • Diagnostics and tuning packs • Statspack • v$xxx dynamic troubleshooting and performance views • dba_xxx dictionary views • •
Oracle wait events utlbstat.sql and utlestat.sql scripts
Copyright © 2003, Oracle. All rights reserved.
Oracle Enterprise Manager Console
Copyright Š 2003, Oracle. All rights reserved.
Performance Manager
Copyright Š 2003, Oracle. All rights reserved.
Overview of Oracle Expert Tuning Methodology Specify tuning scope Collect data View and edit data and rules Analyze data Review recommendations Implement recommendations
Copyright Š 2003, Oracle. All rights reserved.
Tuning Using Oracle Expert
Copyright Š 2003, Oracle. All rights reserved.
Tuning Using Oracle Expert
Copyright Š 2003, Oracle. All rights reserved.
Statspack
• • • • •
Installation of Statspack using the spcreate.sql script Collection of statistics execute statspack.snap Automatic collection of statistics using the spauto.sql script Produce a report using the spreport.sql script To collect timing information, set TIMED_STATISTICS = True
Copyright © 2003, Oracle. All rights reserved.
Statspack Output
Information found on the first page: • Database and instance name • Time at which the snapshots were taken • Current sizes of the caches • Load profile • Efficiency percentages of the instance • Top five wait events
Copyright © 2003, Oracle. All rights reserved.
Statspack Output
Information found in the remainder of the document: • Complete list of wait events • Information on SQL statements currently in the pool • Instance activity statistics • Tablespace and file I/O • Buffer pool statistics
Copyright © 2003, Oracle. All rights reserved.
Statspack Output
Information found in the remainder of the document: • Rollback or undo segment statistics • Latch activity • Dictionary cache statistics • Library cache statistics • System Global Area (SGA) statistics • Startup values for initialization parameters
Copyright © 2003, Oracle. All rights reserved.
Dictionary and Special Views
The following dictionary and special views provide useful statistics after using the dbms_stats package: • dba_tables, dba_tab_columns • dba_clusters • dba_indexes, index_stats • index_histogram, dba_tab_histograms This statistical information is static until you reexecute dbms_stats.
Copyright © 2003, Oracle. All rights reserved.
Displaying Systemwide Statistics v$sysstat • statistic# • name • class • value
v$event_name • event number • name • parameter1 • parameter2 • parameter3
v$sgastat • pool • name • bytes
v$system_event • event • total_waits • total_timeouts • time_waited • average_wait
Copyright © 2003, Oracle. All rights reserved.
Displaying Session-Related Statistics v$statname
v$sesstat • sid • statistic# • value
• statistic# • name • class
v$session_event • sid • event • total_waits • total_timeouts • time_waited • average_wait • max_wait
v$event_name • event# • name • parameter1 • parameter2 • parameter3
v$session • sid • serial# • username • osuser
v$session_wait • sid • seq# • event • p1/2/3 • p1/2/3 text • p1/2/3 raw • wait time • seconds_in_wait • state
Copyright © 2003, Oracle. All rights reserved.
Oracle Wait Events
•
•
A collection of wait events provides information on the sessions that had to wait or must wait for different reasons. These events are listed in the v$event_name view, which has the following columns: – – – – –
EVENT# NAME PARAMETER1 PARAMETER2 PARAMETER3
Copyright © 2003, Oracle. All rights reserved.
The v$event_name View
SQL> SELECT name, parameter1, parameter2, parameter3 2 FROM v$event_name; NAME
PARAMETER1
PARAMETER2
PARAMETER3
-------------------------------
----------
----------
----------
PL/SQL lock timer
duration
alter system set mts_dispatcher
waited
buffer busy waits
file#
block#
id
library cache pin
handle addr pin address 0*mode+name
log buffer space log file switch (checkpoint incomplete) transaction
undo seg#
wrap#
... 286 rows selected.
Copyright Š 2003, Oracle. All rights reserved.
count
Statistics Event Views
• • •
v$session_event: Waits for an event for each session that had to wait v$session_wait: Waits for an event for current active sessions that are waiting v$system_event: Total waits for an event, all sessions together
Copyright © 2003, Oracle. All rights reserved.
The v$session_event View
SQL> SELECT sid, event, total_waits,average_wait 2 FROM v$session_event 3 WHERE sid=10; SID ---10 10 10 10 10 10
EVENT TOTAL_WAITS AVERAGE_WAIT ------------------------------ ----------- ------------buffer busy waits 12 5 db file sequential read 129 0 file open 1 0 SQL*Net message to client 77 0 SQL*Net more data to client 2 0 SQL*Net message from client 76 0
Copyright Š 2003, Oracle. All rights reserved.
The v$session_wait View
SQL> SELECT sid, seq#, event, wait_time, state 2 FROM v$session_wait; SID
SEQ#
EVENT
---- ------ --------------------------1 1284 pmon timer 2 1697 rdbms ipc message 3 183 rdbms ipc message 4 4688 rdbms ipc message 5 114 smon timer 6 14 SQL*Net message from client
Copyright Š 2003, Oracle. All rights reserved.
WAIT TIME ----0 0 0 0 0 -1
STATE ------WAITING WAITING WAITING WAITING WAITING WAITED SHORT TIME
The v$system_event View
SQL> 2 3 4
SELECT event, total_waits, total_timeouts, time_waited, average_wait FROM v$system_event ORDER BY time_waited DESC;
EVENT ----------------latch free pmon timer process startup buffer busy waits ... 34 rows selected.
TOTAL_ WAITS -----5 932 3 12
TOTAL_ TIMEOUTS -------5 535 0
TIME_ WAITED -----5 254430 8 5
Copyright Š 2003, Oracle. All rights reserved.
AVERAGE_ WAIT ---------1 272.993562 2.66666667 5
Dynamic Troubleshooting and Performance Views V$ views: • Based on X$ tables • Listed in v$fixed_table X$ tables: • Not usually queried directly • Dynamic and constantly changing • Names abbreviated and obscure Populated at startup and cleared at shutdown
Copyright © 2003, Oracle. All rights reserved.
Troubleshooting and Tuning Views
Instance/Database v$database v$instance v$option v$parameter v$backup v$px_process_sysstat v$process v$waitstat v$system_event
Disk v$datafile v$filestat v$log v$log_history v$dbfile v$tempfile v$tempstat v$segment_statistics Contention v$lock v$rollname v$rollstat v$waitstat v$latch
Copyright Š 2003, Oracle. All rights reserved.
Troubleshooting and Tuning Views Memory v$buffer_pool_statistics v$db_object_cache v$librarycache v$rowcache v$sysstat v$sgastat User/Session v$lock v$open_cursor v$process v$transaction v$px_sesstat v$px_session
v$sesstat v$session_event v$sort_usage v$session_wait v$session v$session_object_cache
Copyright Š 2003, Oracle. All rights reserved.
utlbstat and utlestat Scripts
• • • •
Gather performance figures over a defined period. Produce a hard-copy report. Should set TIMED_STATISTICS to True. Execute from SQL*Plus connected as SYSDBA.
•
Statspack provides clearer statistics.
Copyright © 2003, Oracle. All rights reserved.
DBA-Developed Tools
• • • • •
Develop your own scripts. Use the supplied packages for tuning. Schedule periodic performance checking. Take advantage of the Enterprise Manager Event service to track specific situations. Take advantage of the Oracle Enterprise Manager Job service to: – Automate the regular execution of administrative tasks. – Apply tasks that automatically solve problems detected by the Oracle Enterprise Manager event service. Copyright © 2003, Oracle. All rights reserved.
Level of Statistics Collection
The initialization parameters that determine the level of statistic collection are: • STATISTICS_LEVEL • TIMED_STATISTICS • TIMED_OS_STATISTICS • DB_CACHE_ADVICE
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Use the alert log file • Get information from background processes trace files • Trace user SQL statements • Collect statistics from dictionary and dynamic performance troubleshooting views • Use the Statspack utility to collect performance data • Retrieve wait events information
Copyright © 2003, Oracle. All rights reserved.
Database Configuration and I/O Issues
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • List the advantages of distributing different Oracle file types • Diagnose tablespace usage problems • List reasons for partitioning data in tablespaces • Describe how checkpoints work • Monitor and tune checkpoints • Monitor and tune redo logs
Copyright © 2003, Oracle. All rights reserved.
Oracle Processes and Files
Process
Oracle file I/O Data files Log
CKPT
Read/Write
DBWn
Write
Archive
Control Read/Write
LGWR
Write
ARCn
Read
Write
Read/Write
Read
Write
Read/Write
SERVER
Read/write
Read/Write
Copyright Š 2003, Oracle. All rights reserved.
Performance Guidelines
Basic performance rules are as follows: • Keep disk I/O to a minimum. • Spread your disk load across disk devices and controllers. • Use temporary tablespaces where appropriate.
Copyright © 2003, Oracle. All rights reserved.
Distributing Files Across Devices
• • •
Separate data files and redo log files. Stripe table data. Reduce disk I/O unrelated to the database.
Copyright © 2003, Oracle. All rights reserved.
IO Topology Support
Copyright Š 2003, Oracle. All rights reserved.
Tablespace Usage
• • • • • •
Reserve the system tablespace for data dictionary objects. Create locally managed tablespaces to avoid space management issues. Split tables and indexes into separate tablespaces. Create rollback segments in their own tablespaces. Store very large objects in their own tablespace. Create one or more temporary tablespaces.
Copyright © 2003, Oracle. All rights reserved.
Locally Managed system Tablespace
Create databases that have a locally managed system tablespace. CREATE DATABASE mydb … DATAFILE 'system01.dbf' SIZE 100M EXTENT MANAGEMENT LOCAL … DEFAULT TEMPORARY TABLESPACE temp TEMPFILE 'temp01.dbf' SIZE 15M …;
Copyright © 2003, Oracle. All rights reserved.
Diagnostic Tools for Checking I/O Statistics
System I/O utilization
Server I/O utilization
v$filestat v$tempstat v$datafile Data files
Performance tools
Statspack Copyright Š 2003, Oracle. All rights reserved.
Using the v$filestat View SQL> 2 3 4
SELECT phyrds, phywrts, d.name FROM v$datafile d, v$filestat f WHERE d.file#=f.file# ORDER BY d.name;
PHYRDS PHYWRTS ---------- -------806 116 168 675 8 8 26 257 65012 564 8 8 6 rows selected
NAME -------------------/…/u01/system01.dbf /…/u04/temp01.dbf /…/u02/sample01.dbf /…/u02/undots01.dbf /…/u03/users01.dbf /…/u01/query01.dbf
Copyright © 2003, Oracle. All rights reserved.
Performance Manager: I/O Statistics
Copyright Š 2003, Oracle. All rights reserved.
I/O Statistics SQL> SELECT d.tablespace_name TABLESPACE, 2 d.file_name, f.phyrds, f.phywrts 3 FROM v$filestat f, dba_data_files d 4 WHERE f.file# = d.file_id; TABLESPACE FILE_NAME PHYRDS PHYWRTS ------------- ----------------- ------ ------UNDO1 /u02/undots01.dbf 26 257 SAMPLE /u02/sample01.dbf 65012 564 USERS /u03/users01.dbf 8 8 SYSTEM /u01/system01.dbf 806 116 TEMP /u04/temp01.dbf 168 675 QUERY_DATA /u01/query01.dbf 8 8 6 rows selected. Copyright © 2003, Oracle. All rights reserved.
File Striping
•
Operating system striping: – Use operating system striping software or a redundant array of inexpensive disks (RAID). – Determine the right stripe size.
•
Manual striping: Use the CREATE TABLE or ALTER TABLE command with the ALLOCATE clause.
Copyright © 2003, Oracle. All rights reserved.
Tuning Full Table Scan Operations
• •
Investigate the need for full table scans. Configure the DB_FILE_MULTIBLOCK_READ_COUNT initialization parameter to: – Determine the number of database blocks the server reads at once – Influence the execution plan of the cost-based optimizer
•
Monitor long-running full table scans with v$session_longops view.
Copyright © 2003, Oracle. All rights reserved.
Table Scan Statistics SQL> 2
SELECT name, value FROM v$sysstat WHERE name LIKE '%table scan%';
NAME -------------------------------------table scans (short tables) table scans (long tables) table scans (rowid ranges table scans (cache partitions) table scans (direct read) table scan rows gotten table scan blocks gotten 7 rows selected.
Copyright Š 2003, Oracle. All rights reserved.
VALUE ----125 30 0 0 0 21224 804
Monitoring Full Table Scan Operations
•
Determine the progress of long operations using:
SQL> SELECT sid, serial#, opname, 2 TO_CHAR(start_time,'HH24:MI:SS') AS "START", 3 (sofar/totalwork)*100 AS PERCENT_COMPLETE 4 FROM v$session_longops;
•
Use SET_SESSION_LONGOPS to populate v$session_longops.
dbms_application_info.set_session_longops (rindex, slno, "Operation X", obj, 0, sofar, totalwork, "table", "tables");
Copyright © 2003, Oracle. All rights reserved.
Checkpoints
The two most common types of checkpoints are: • Incremental checkpoints – CKPT updates the control file. – During a log switch CKPT updates the control file and the data file headers.
•
Full checkpoints – CKPT updates the control file and the data file headers. – DBWn writes out all buffers on the checkpoint queue.
Copyright © 2003, Oracle. All rights reserved.
Full Checkpoints
Two categories of full checkpoints • Complete • Tablespace
Copyright © 2003, Oracle. All rights reserved.
Performance Manager: Response Time
Copyright Š 2003, Oracle. All rights reserved.
Regulating the Checkpoint Queue
Regulate the checkpoint queue with the following initialization parameters: • FAST_START_IO_TARGET • LOG_CHECKPOINT_INTERVAL • LOG_CHECKPOINT_TIMEOUT • FAST_START_MTTR_TARGET
Copyright © 2003, Oracle. All rights reserved.
Defining and Monitoring Fast Start Checkpointing Use v$instance_recovery to obtain the following information: • RECOVERY_ESTIMATED_IOS • LOG_FILE_SIZE_REDO_BLKS • LOG_CHKPT_TIMEOUT_REDO_BLKS • LOG_CHKPT_INTERVAL_REDO_BLKS • TARGET_MTTR • ESTIMATED_MTTR
Copyright © 2003, Oracle. All rights reserved.
Redo Log Groups and Members LGWR
Group 1
Group 2
Group 3 Disk 1
Member
Member
Member
Disk 2 Member
Member
Copyright Š 2003, Oracle. All rights reserved.
Member
Online Redo Log File Configuration
• • • •
Size redo log files to minimize contention. Provide enough groups to prevent waiting. Store redo log files on separate, fast devices. Monitor the redo log file configuration with: – v$logfile – v$log – v$log_history
Copyright © 2003, Oracle. All rights reserved.
Increasing the Performance of Archiving
•
Allow the LGWR process to write to a disk different from the one the ARCn process is reading.
•
Share the archiving work during a temporary increase in workload:
ALTER SYSTEM ARCHIVE LOG ALL TO <log_archive_dest>
• •
Increase the number of archive processes. Change archiving speed: – LOG_ARCHIVE_MAX_PROCESSES – LOG_ARCHIVE_DEST_n Copyright © 2003, Oracle. All rights reserved.
Diagnostic Tools
v$archive_dest v$archived_log v$archive_processes
LOG_ARCHIVE_DEST_STATE_n
Copyright Š 2003, Oracle. All rights reserved.
Archived logs
Summary
In this lesson, you should have learned how to: • List the advantages of distributing different Oracle file types • Diagnose tablespace usage problems • List reasons for segmenting data in tablespaces • Describe how checkpoints work • Monitor and tune checkpoints • Monitor and tune archive logging
Copyright © 2003, Oracle. All rights reserved.
Tuning the Shared Pool
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Determine the size of an object and pin it in the shared pool • Tune the shared pool reserved space • Describe the user global area (UGA) and session memory considerations • Measure the library cache hit ratio • List other tuning issues related to the shared pool • Measure the dictionary cache hit ratio • Set the large pool
Copyright © 2003, Oracle. All rights reserved.
Shared Pool Contents Major components of the shared pool are: • Library cache • Data dictionary cache • User global area (UGA) for shared server sessions Database buffer cache
Redo log buffer
Shared pool Library cache
Large pool UGA
Data dictionary cache
User global area
Copyright © 2003, Oracle. All rights reserved.
Shared Pool • • •
•
Defined by SHARED_POOL_SIZE Library cache contains statement text, parsed code, and execution plan. Data dictionary cache contains definitions for tables, columns, and privileges from the data dictionary tables. UGA contains session information for Oracle Shared Server users when a large pool is not configured. Shared pool Shared pool
Library cache Shared Datapool dictionary cache UGA
Copyright © 2003, Oracle. All rights reserved.
The Library Cache
• • • •
Used to store SQL statements and PL/SQL blocks that are to be shared by users Managed by a least recently used (LRU) algorithm Used to prevent statements reparsing Reports error ORA-04031 if the shared pool is out of free memory
Copyright © 2003, Oracle. All rights reserved.
The Library Cache
Shared SQL, PL/SQL areas Context area for SELECT statement 2
Context area for SELECT statement 1
SELECT statement 2
SELECT statement 1
Copyright Š 2003, Oracle. All rights reserved.
SELECT statement 1
Important Shared Pool Latches
• •
shared pool: Protects memory allocations in the shared pool library cache: Locates matching SQL in the shared pool
Copyright © 2003, Oracle. All rights reserved.
Shared Pool and Library Cache Latches
Contention for shared pool latch and library cache latch indicates one or more of the following: • Unshared SQL • Reparsed sharable SQL • Insufficiently sized library cache
Copyright © 2003, Oracle. All rights reserved.
Tuning the Library Cache
Reduce misses by keeping parsing to a minimum: • Make sure that users can share statements. • Prevent statements from being aged out by allocating enough space. • Avoid invalidations that induce reparsing.
Copyright © 2003, Oracle. All rights reserved.
Tuning the Library Cache
Avoid fragmentation by: • Reserving space for large memory requirements • Pinning frequently required large objects • Eliminating large anonymous PL/SQL blocks • Enabling the use of large pool for Oracle Shared Server connections
Copyright © 2003, Oracle. All rights reserved.
Terminology
• • •
•
Gets: (Parse) The number of lookups for objects of the namespace Pins: (Execution) The number of reads or executions of the objects of the namespace Reloads: (Parse) The number of library cache misses on the execution step, thereby causing an implicit reparsing of the SQL statement Invalidations: (Parse) If an object is modified then all explain plans that reference the object are marked invalid and must be parsed again
Copyright © 2003, Oracle. All rights reserved.
Diagnostic Tools for Tuning the Library Cache v$sgastat v$librarycache
Shared pool
Library cache Shared SQL
sp_m_n.lst
v$sql
and PL/SQL
Views v$sqlarea v$sqltext v$db_object_cache
report.txt Data dictionary cache UGA
Parameters affecting the components: SHARED_POOL_SIZE, OPEN_CURSORS SESSION_CACHED_CURSORS, CURSOR_SPACE_FOR_TIME CURSOR_SHARING, SHARED_POOL_RESERVED_SIZE Copyright Š 2003, Oracle. All rights reserved.
Are Cursors Being Shared?
•
Check gethitration in v$librarycache: SQL> SELECT gethitratio 2 FROM v$librarycache 3 WHERE namespace = 'SQL AREA';
•
Determine which statements users are running: SQL> SELECT sql_text, users_executing, 2 executions, loads 3 FROM v$sqlarea; SQL> SELECT * FROM v$sqltext 2 WHERE sql_text LIKE 3 'SELECT * FROM hr.employees WHERE %';
Copyright © 2003, Oracle. All rights reserved.
Sharing Cursors
Values for CURSOR_SHARING are: • • •
Exact Similar Force
Copyright © 2003, Oracle. All rights reserved.
Guidelines: Library Cache Reloads
•
Reloads should be less than 1% of the pins: SQL> SELECT SUM(pins) "Executions", 2 SUM(reloads) "Cache Misses", 3 SUM(reloads)/SUM(pins) 4 FROM v$librarycache;
•
If the reloads-to-pins ratio is greater than 1%, increase the value of the SHARED_POOL_SIZE parameter. Executes PROC1 —> 1st pin, 1 load Executes PROC1 —> 2nd pin, no reload Executes PROC1 —> 3rd pin, no reload Executes PROC1 —> 4th pin, no reload
Copyright © 2003, Oracle. All rights reserved.
4 pins and no reloads
Invalidations The number of times objects of the namespace were marked invalid, causing reloads: SQL> SQL> 2 3 SQL> > SQL> SQL> 2 3
SELECT count(*) FROM hr.employees; SELECT namespace,pins,reloads, invalidations FROM v$librarycache; execute dbms_stats.gather_table_stats ('HR','EMPLOYEES'); SELECT count(*) FROM hr.employees; SELECT namespace,pins,reloads, invalidations FROM v$librarycache; Copyright Š 2003, Oracle. All rights reserved.
Sizing the Library Cache
• • • • •
Define the global space necessary for stored objects (packages, views, and so on). Define the amount of memory used by the usual SQL statements. Reserve space for large memory requirements to avoid misses and fragmentation. Pin frequently used objects. Convert large anonymous PL/SQL blocks into small anonymous blocks calling packaged functions.
Copyright © 2003, Oracle. All rights reserved.
Shared Pool Advisory SQL> SELECT shared_pool_size_for_estimate AS 2 pool_size, estd_lc_size, 3 estd_lc_time_saved 4 FROM v$shared_pool_advice; POOL_SIZE ESTD_LC_SIZE ESTD_LC_TIME_SAVED ---------- ------------ -----------------32 8 7868 40 15 7868 48 17 7868 56 17 7868 64 17 7868 72 17 7868 80 17 7868 88 17 7868 Copyright Š 2003, Oracle. All rights reserved.
Oracle Enterprise Manager Shared Pool Size Advisor
Copyright Š 2003, Oracle. All rights reserved.
Cached Execution Plans
• •
•
The Oracle server preserves the execution plan of a cached SQL statement in memory. When the SQL statement ages out of the library cache, the corresponding cached execution plan is removed. You can use the cached plans to diagnose query performance.
Copyright © 2003, Oracle. All rights reserved.
Views to Support Cached Execution Plans You can use the v$sql_plan dynamic performance view to view the actual execution plan information for cached cursors. SQL> SELECT operation, object_owner, 2 object_name, cost 3 FROM v$sql_plan 4 ORDER BY hash_value;
Copyright Š 2003, Oracle. All rights reserved.
Support for Cached Execution Plans
•
The v$sql view has a column, plan_hash_value, which references the hash_value column of v$sql_plan.
•
The column information is a hash value built from the corresponding execution plan. The column can be used to compare cursor plans the same way the hash_value column is used to compare cursor SQL texts.
•
Copyright © 2003, Oracle. All rights reserved.
Global Space Allocation
Stored objects such as packages and views: SQL> SELECT SUM(sharable_mem) 2 FROM v$db_object_cache; SUM(SHARABLE_MEM) ----------------379600 SQL statements: SQL> SELECT SUM(sharable_mem) 2 FROM v$sqlarea WHERE executions > 5; SUM(SHARABLE_MEM) ----------------381067 Copyright Š 2003, Oracle. All rights reserved.
Large Memory Requirements
• •
Satisfy requests for large contiguous memory Reserve contiguous memory within the shared pool Shared pool
v$shared_pool_reserved
Library cache Shared SQL and PL/SQL
SHARED_POOL_SIZE SHARED_POOL_RESERVED_SIZE
Data dictionary cache
UGA
Copyright © 2003, Oracle. All rights reserved.
Tuning the Shared Pool Reserved Space •
Diagnostic tools for tuning: – The v$shared_pool_reserved dictionary view – The supplied aborted_request_threshold procedure in the dbms_shared_pool package
•
Guidelines: Set the SHARED_POOL_RESERVED_SIZE parameter
Copyright © 2003, Oracle. All rights reserved.
Keeping Large Objects
•
Find those PL/SQL objects that are not kept in the library cache: SQL> 2 3 4 5
•
SELECT * FROM v$db_object_cache WHERE sharable_mem > 10000 AND (type='PACKAGE' OR type='PACKAGE BODY' OR type='FUNCTION' OR type='PROCEDURE') AND kept='NO';
Pin large packages in the library cache: SQL> EXECUTE dbms_shared_pool.keep(‘package_name’);
Copyright © 2003, Oracle. All rights reserved.
Anonymous PL/SQL Blocks
Find the anonymous PL/SQL blocks and convert them into small anonymous PL/SQL blocks that call packaged functions: SQL> SELECT sql_text FROM v$sqlarea 2 WHERE command_type = 47 3 AND length(sql_text) > 500;
Copyright Š 2003, Oracle. All rights reserved.
Other Parameters Affecting the Library Cache • • • •
OPEN_CURSORS CURSOR_SPACE_FOR_TIME SESSION_CACHED_CURSORS CURSOR_SHARING
Copyright © 2003, Oracle. All rights reserved.
Tuning the Data Dictionary Cache
Use v$rowcache to obtain information about the data dictionary cache. • Content: Definitions of dictionary objects • Terminology: – gets: Number of requests on objects – getmisses: Number of requests resulting in cache misses
•
Tuning: Avoid dictionary cache misses
Copyright © 2003, Oracle. All rights reserved.
Diagnostic Tools for Tuning the Data Dictionary Cache Shared pool
Library cache v$rowcache: parameter gets getmisses
Shared SQL and PL/SQL Data dictionary cache UGA
SHARED_POOL_SIZE
Copyright Š 2003, Oracle. All rights reserved.
Sp_1_2.lst
Measuring the Dictionary Cache Statistics
In the Dictionary Cache Stats section of Statspack: •
Percent misses should be very low: – < 2% for most data dictionary objects – < 15% for the entire data dictionary cache
• •
Cache Usage is the number of cache entries being used. Pct SGA is a percentage of usage to allocated size for that cache.
Copyright © 2003, Oracle. All rights reserved.
Tuning the Data Dictionary Cache
Keep the percentage of the sum of getmisses to the sum of gets less than 15%: SQL> SELECT parameter, gets, getmisses 2 FROM v$rowcache; PARAMETER GETS GETMISSES -------------------------- --------- --------dc_objects 143434 171 dc_synonyms 140432 127
Copyright Š 2003, Oracle. All rights reserved.
Guidelines: Dictionary Cache Misses
Statspack report output: (font size incorrect) Get Cache
Requests
Pct Miss
Scan Reqs
Pct
Mod
Miss
Reqs
Final Usage
Pct SGA
------------------ --------- ------ ----- ----- ----- ------ ---dc_free_extents
2
0.
0
0
3
3
dc_histogram_defs
11
0.0
0
0
49
92
dc_object_ids
19
0.0
0
0
440
98
If there are too many cache misses, increase the SHARED_POOL_SIZE parameter.
Copyright Š 2003, Oracle. All rights reserved.
Performance Manager: Shared Pool Statistics
Copyright Š 2003, Oracle. All rights reserved.
UGA and Oracle Shared Server Dedicated server configuration
PGA Stack space
Shared pool
UGA User Cursor session state data
Shared server configuration Shared pool or large pool
v$statname v$sesstat v$mystat
UGA User Cursor session state data
PGA Stack space
OPEN_CURSORS SESSION_CACHED_CURSORS
Copyright Š 2003, Oracle. All rights reserved.
Determining the User Global Area Size •
UGA space used by your connection: SQL> SELECT SUM(value) ||'bytes' "Total session 2 3 4
•
FROM v$mystat, v$statname WHERE name = 'session uga memory' AND v$mystat.statistic# = v$statname.statistic#;
UGA space used by all Oracle Shared Server users:
SQL> 2 3 4
•
memory"
SELECT SUM(value) ||'bytes' "Total session memory" FROM v$sesstat, v$statname WHERE name = 'session uga memory' AND v$sesstat.statistic# = v$statname.statistic#;
Maximum UGA space used by all users:
SQL> 2 3 4
SELECT SUM(value) ||'bytes' "Total max memory" FROM v$sesstat, v$statname WHERE name = 'session uga memory max' AND v$sesstat.statistic# = v$statname.statistic#;
Copyright © 2003, Oracle. All rights reserved.
Large Pool •
Can be configured as a separate memory area in the SGA, used for memory with: – – – –
• •
I/O server processes: DBWR_IO_SLAVES Backup and restore operations Session memory for the shared servers Parallel query messaging
Used to avoid performance overhead caused by shrinking the shared SQL cache Sized by the parameter LARGE_POOL_SIZE Database Redo buffer cache log buffer
Shared pool Library cache Data dictionary cache User global area
Copyright © 2003, Oracle. All rights reserved.
Large pool
Summary
In this lesson, you should have learned how to: • Size shared SQL and PL/SQL areas (library cache) • Size data dictionary cache or row cache • Size the large pool • Allow for the user global area, if using Oracle Shared Server connections
Copyright © 2003, Oracle. All rights reserved.
Tuning the Buffer Cache
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Employ the buffer cache sizing advisor • Describe how the buffer cache is used by different Oracle processes • Create and manage different buffer caches • Monitor the use of the buffer caches • Identify and resolve buffer cache performance problems
Copyright © 2003, Oracle. All rights reserved.
Buffer Cache Characteristics DB buffer cache
SGA Server
LRU lists
Checkpoint Queue
. . . .
. . . .
DBWn
DB_BLOCK_SIZE DB_CACHE_SIZE DB_KEEP_CACHE_SIZE DB_RECYCLE_CACHE_SIZE DB_BLOCK_CHECKSUM
Data files Copyright © 2003, Oracle. All rights reserved.
Buffer Cache Sizing Parameters
•
•
•
The buffer cache can consist of independent subcaches for buffer pools and for multiple block sizes. The DB_BLOCK_SIZE parameter determines the primary block size, which is the block size used for the system tablespace and the primary buffer caches (recycle, keep, and default). The following parameters define the sizes of the caches for buffers for the primary block size: – DB_CACHE_SIZE – DB_KEEP_CACHE_SIZE – DB_RECYCLE_CACHE_SIZE
Copyright © 2003, Oracle. All rights reserved.
Dynamic Buffer Cache Advisory Parameter •
•
•
The buffer cache advisory feature enables and disables statistics gathering for predicting behavior with different cache sizes. DBAs can use the information provided by these statistics to size the buffer cache optimally for a given workload. The buffer cache advisory is enabled by means of the DB_CACHE_ADVICE initialization parameter: – This parameter is dynamic and can be changed using ALTER SYSTEM. – Three values are allowed: Off, On, and Ready.
Copyright © 2003, Oracle. All rights reserved.
View to Support Buffer Cache Advisory
•
Buffer cache advisory information is collected in the v$db_cache_advice view.
•
The view contains different rows that estimate the number of physical reads for different caches. The rows also compute a physical read factor, which is the ratio of the number of estimated reads to the number of actual reads.
•
Copyright © 2003, Oracle. All rights reserved.
Using the v$db_cache_advice View
SQL> 2 3 4 4 5 6 7 8 9 10 11
SELECT size_for_estimate "Cache Size (MB)", buffers_for_estimate "Buffers", estd_physical_read_factor AS "Estd Phys Read Factor", estd_physical_reads "Estd Phys Reads" FROM v$db_cache_advice WHERE name = 'DEFAULT' AND block_size = ( SELECT value FROM v$parameter WHERE name = 'db_block_size') AND advice_status = 'ON';
Copyright Š 2003, Oracle. All rights reserved.
Using the Buffer Cache Advisory
Copyright Š 2003, Oracle. All rights reserved.
Managing the Database Buffer Cache SGA Server
2
1
LRU lists
Checkpoint Queue
. . . .
. . . .
DB buffer cache
2 3 4
DBWn Data files Copyright Š 2003, Oracle. All rights reserved.
LGWR
Managing the Database Buffer Cache DB buffer cache
SGA Server
LRU lists
Checkpoint Queue
. . . .
. . . .
DBWn
LGWR
Data files Copyright Š 2003, Oracle. All rights reserved.
Tuning Goals and Techniques •
Tuning goals: – Servers find data in memory – No waits on the buffer cache
•
Diagnostic measures – Wait events – Cache hit ratio – The v$db_cache_advice view
•
Tuning techniques: – Reduce the number of blocks required by SQL statements – Increase buffer cache size – Use multiple buffer pools – Cache tables – Bypass the cache for sorting and parallel reads Copyright © 2003, Oracle. All rights reserved.
Diagnostic Tools v$sysstat v$buffer_pool_statistics v$buffer_pool v$db_cache_advice
SGA LRU list
Checkpoint queue Buffer cache
v$sesstat v$system_event v$session_wait v$bh v$cache
Keep buffer pool Recycle buffer pool
DB_CACHE_SIZE DB_KEEP_CACHE_SIZE DB_RECYCLE_CACHE_SIZE Copyright Š 2003, Oracle. All rights reserved.
Statspack Report
Performance Manager
Copyright Š 2003, Oracle. All rights reserved.
Buffer Cache Performance Indicators
From v$sysstat: SQL> SELECT name, value 2 FROM v$sysstat 3 WHERE name = 'free buffer inspected'; NAME VALUE --------------------------- -------free buffer inspected 183
Copyright Š 2003, Oracle. All rights reserved.
More Buffer Cache Performance Indicators
From v$system_event: SQL> SELECT event, total_waits 2 FROM v$system_event 3 WHERE event in 4 ('free buffer waits', 5 'buffer busy waits'); EVENT TOTAL_WAITS ---------------------- ----------free buffer waits 337 buffer busy waits 3466
Copyright Š 2003, Oracle. All rights reserved.
Measuring the Cache Hit Ratio •
From v$sysstat: SQL> 2 3 4 5 6 7 8
•
SELECT 1 - (phy.value - lob.value - dir.value) / ses.value "CACHE HIT RATIO" FROM v$sysstat ses, v$sysstat lob, v$sysstat dir, v$sysstat phy WHERE ses.name = 'session logical reads' AND dir.name = 'physical reads direct' AND lob.name = 'physical reads direct (lob)' AND phy.name = 'physical reads';
From the Statspack report: Statistic
Total Per Per Trans Logon Second ------------------------- -------- ------ -------physical reads 15,238 13.0 15,238.0 physical reads direct 863 0.7 863.0 Physical reads direct(lob) 0 0 0 session logical reads 119,376 101.8 119,376.0
Copyright © 2003, Oracle. All rights reserved.
Guidelines for Using the Cache Hit Ratio
Hit ratio is affected by data access methods: • Full table scans • Data or application design • Large table with random access • Uneven distribution of cache hits
Copyright © 2003, Oracle. All rights reserved.
Buffer Cache Hit Ratio Isn’t Everything
• • • •
A badly tuned database can still have a hit ratio of 99% or better. Hit ratio is only one part in determining tuning performance. Hit ratio does not determine whether a database is optimally tuned. Use the Oracle Wait Interface to examine what is causing a bottleneck. – v$session_wait – v$session_event – v$system_event
•
Tune SQL statements. Copyright © 2003, Oracle. All rights reserved.
Guidelines to Increase the Cache Size
Increase the cache size ratio under the following conditions: • Any wait events have been tuned • SQL statements have been tuned • There is no undue page faulting • The previous increase of the buffer cache was effective • Low cache hit ratio
Copyright © 2003, Oracle. All rights reserved.
Using Multiple Buffer Pools SGA DB buffer caches
Recycle pool
Keep pool
Default pool
Copyright Š 2003, Oracle. All rights reserved.
Defining Multiple Buffer Pools
In the Oracle database: • Individual pools have their own size defined by: – DB_CACHE_SIZE – DB_KEEP_CACHE_SIZE – DB_RECYCLE_CACHE_SIZE • •
These parameters are dynamic. Latches are automatically allocated by Oracle RDBMS.
Copyright © 2003, Oracle. All rights reserved.
Enabling Multiple Buffer Pools
CREATE INDEX cust_idx … STORAGE (BUFFER_POOL KEEP …); ALTER TABLE customer STORAGE (BUFFER_POOL RECYCLE); ALTER INDEX cust_name_idx STORAGE (BUFFER_POOL KEEP);
Copyright © 2003, Oracle. All rights reserved.
KEEP Buffer Pool Guidelines • • •
Tuning goal: Keeping blocks in memory Size: Holds all or nearly all blocks of the segments assigned to this pool Tool: dbms_stats.gather_table_stats SQL> EXECUTE dbms_stats.gather_table_stats > ('HR','DEPARTMENTS'); SQL> 2 3 4
SELECT table_name, blocks FROM dba_tables WHERE owner = 'HR' AND table_name = 'DEPARTMENTS';
TABLE_NAME BLOCKS ---------- ---------DEPARTMENTS 1 Copyright © 2003, Oracle. All rights reserved.
RECYCLE Buffer Pool Guidelines
• • •
Tuning goal: Eliminate blocks from memory when transactions are completed Size: Holds only active blocks Tool: v$cache SQL> SELECT owner#, name, count(*) blocks 2 FROM v$cache 3 GROUP BY owner#, name; OWNER# NAME BLOCKS ------ ---------- ---------5 CUSTOMER 147
Copyright © 2003, Oracle. All rights reserved.
RECYCLE Buffer Pool Guidelines
Tool: v$sess_io SQL> SELECT s.username, io.block_gets, 2 io.consistent_gets, io.physical_reads 3 FROM v$sess_io io, v$session s 4 WHERE io.sid = s.sid ; USERNAME -------HR
BLOCK_GETS CONSISTENT_GETS PHYSICAL_READS ---------- --------------- -------------21874 2327 1344
Copyright © 2003, Oracle. All rights reserved.
Calculating the Hit Ratio for Multiple Pools
SQL> 2 3 4
SELECT name, 1 - (physical_reads / (db_block_gets + consistent_gets)) "HIT_RATIO" FROM v$buffer_pool_statistics WHERE db_block_gets + consistent_gets > 0;
NAME HIT_RATIO ------------------ ---------KEEP .983520845 RECYCLE .503866235 DEFAULT .790350047
Copyright Š 2003, Oracle. All rights reserved.
Identifying Candidate Pool Segments
•
Keep pool – Blocks are accessed repeatedly. – Segment size is less than 10% of the default buffer pool size.
•
Recycle pool – Blocks are not reused outside of transaction. – Segment size is more than twice the default buffer pool size.
Copyright © 2003, Oracle. All rights reserved.
Dictionary Views with Buffer Pool Information SQL> SELECT id, name, block_size, buffers 2 FROM v$buffer_pool; ID -1 2 3
NAME block_size BUFFERS ------- ---------- -------KEEP 4096 14000 RECYCLE 4096 2000 DEFAULT 4096 4000
Copyright Š 2003, Oracle. All rights reserved.
Automatic Segment Space Management
•
Manages free space automatically inside database segments
•
Tracks segment free/used space with bitmaps instead of free lists
•
Provides better space utilization, especially for the objects with highly varying size rows
•
Specified when creating a tablespace
•
Supported by Oracle Enterprise Manager
Copyright © 2003, Oracle. All rights reserved.
Auto-Management of Free Space
•
Create an auto-managed tablespace: CREATE TABLESPACE BIT_SEG_TS DATAFILE '$HOME/ORADATA/u04/bit_seg01.dbf' SIZE 1M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
•
Create a table that uses auto-management of free space: CREATE TABLE bit_seg_table (idnum NUMBER) TABLESPACE bit_seg_ts;
Copyright © 2003, Oracle. All rights reserved.
Free Lists
• • • • •
A free list for an object maintains a list of blocks that are available for inserts. The number of free lists for an object can be set dynamically. Single-CPU systems do not benefit greatly from multiple free lists. The tuning goal is to ensure that an object has sufficient free lists to minimize contention. Using Automatic Free Space Management eliminates the need for free lists, thus reducing contention on the database.
Copyright © 2003, Oracle. All rights reserved.
Diagnosing Free List Contention v$waitstat columns:
Data SGA buffer cache
CLASS “segment header” COUNT TIME
v$system_event columns:
FREELISTS
EVENT “buffer busy waits” TOTAL_WAITS
Copyright © 2003, Oracle. All rights reserved.
Resolving Free List Contention v$session_wait columns: EVENT “buffer busy waits” P1 “FILE” P2 “BLOCK” P3 “ID” dba_segments columns: SEGMENT_NAME SEGMENT_TYPE FREELISTS HEADER_FILE HEADER_BLOCK
Server process Server process
Data SGA buffer cache
Object ID
FREELISTS
Copyright © 2003, Oracle. All rights reserved.
Multiple DBWn Processes
Multiple DB Writer (DBWn) processes: • Can be deployed with DB_WRITER_PROCESSES (DBW0 to DBW9) •
Can be useful for SMP systems with large numbers of CPUs • Cannot concurrently be used with multiple I/O slaves The DBA can turn asynchronous I/O on or off with the
DISK_ASYNCH_IO parameter.
Copyright © 2003, Oracle. All rights reserved.
Multiple I/O Slaves
• • •
Provide nonblocking asynchronous I/O requests Are typically not recommended if asynchronous I/O is available Follow the naming convention ora_innn_SID
Copyright © 2003, Oracle. All rights reserved.
Tuning DBWn I/O
Tune the DB Writer processes by looking at the value of the FREE BUFFER WAITS event.
Copyright Š 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Employ the buffer cache sizing advisor • Describe how the buffer cache is used by different Oracle processes • Create and manage different buffer caches • Monitor the use of the buffer caches • Identify and resolve buffer cache performance problems
Copyright © 2003, Oracle. All rights reserved.
Dynamic Instance Resizing
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Implement dynamic SGA allocation • Dynamically adjust the buffer caches • Dynamically adjust the shared pool
Copyright © 2003, Oracle. All rights reserved.
Dynamic SGA Feature
•
• •
The dynamic SGA feature implements an infrastructure to allow the server to change its SGA configuration without shutting down the instance. SGA is limited by SGA_MAX_SIZE. A dynamic SGA can grow and shrink in response to a DBA command.
Copyright © 2003, Oracle. All rights reserved.
Unit of Allocation in the Dynamic SGA
• • • •
In the dynamic SGA model, the unit of memory allocation is called a granule. SGA memory is tracked in granules by SGA components. A granule is a unit of contiguous virtual memory allocation. Use v$buffer_pool to monitor size of the buffer caches.
Copyright © 2003, Oracle. All rights reserved.
Granule
• •
SGA components are allocated and deallocated in units of contiguous memory called granules. The size of a granule depends on the estimated total SGA. If the estimated SGA size is: – Less than or equal to 128 MB then the granule size is 4 MB – Greater than 128 MB then the granule size is 16 MB
Copyright © 2003, Oracle. All rights reserved.
Allocating Granules at Startup
•
At instance startup, the Oracle server requests SGA_MAX_SIZE bytes of address space in memory.
•
As startup continues, each component will attempt to acquire the number of granules assigned. The minimum SGA configuration is three granules:
•
– One granule for fixed SGA (includes redo buffers) – One granule for the buffer cache – One granule for the shared pool
Copyright © 2003, Oracle. All rights reserved.
Adding Granules to Components
•
A DBA can dynamically increase memory allocation to a component by issuing an ALTER SYSTEM command.
•
Increasing the memory use of a component succeeds only if there is enough free granules to satisfy the request. Memory granules are not freed automatically from another component to satisfy the increase. Decreasing the size of a component is possible, but only if the granules being released are unused by the component.
• •
Copyright © 2003, Oracle. All rights reserved.
Dynamic Buffer Cache Size Parameters
•
Parameters that specify the size of buffer cache components are dynamic and can be changed while the instance is running by means of the ALTER SYSTEM command: ALTER SYSTEM SET DB_CACHE_SIZE = 1100M;
• • •
Each parameter is sized independently. New cache sizes are set to the next granule boundary. The allocation size has the following limits: – It must be an integer multiple of the granule size. – The total SGA size cannot exceed SGA_MAX_SIZE. – DB_CACHE_SIZE can never be set to zero. Copyright © 2003, Oracle. All rights reserved.
Example: Increasing the Size of an SGA Component Initial parameter values: • SGA_MAX_SIZE = 128M • DB_CACHE_SIZE = 88M • SHARED_POOL_SIZE = 32M ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;
•
Error message returned: insufficient memory ALTER SYSTEM SET DB_CACHE_SIZE = 56M; ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;
• •
Error message returned: insufficient memory Check v$buffer_pool to confirm shrink status. ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;
•
The statement is now processed. Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Implement dynamic SGA allocation • Dynamically adjust the buffer caches • Dynamically adjust the shared pool
Copyright © 2003, Oracle. All rights reserved.
Sizing Other SGA Structures
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Monitor and size the redo log buffer • Monitor and size the Java pool • Control the amount of Java session memory used by a session
Copyright © 2003, Oracle. All rights reserved.
The Redo Log Buffer Redo log buffer
Database buffer cache
Shared pool Library cache
Data dictionary cache
User global area
Server process
LGWR
ARCn
Control files
SQL> UPDATE employees 2
SET salary=salary*1.1
3
WHERE employee_id=736;
Data files Redo log files
Copyright Š 2003, Oracle. All rights reserved.
Archived log files
Sizing the Redo Log Buffer
•
Adjust the LOG_BUFFER parameter.
•
Default value: Either 512K or 128K * the value of CPU_COUNT, whichever is greater.
Copyright © 2003, Oracle. All rights reserved.
Diagnosing Redo Log Buffer Inefficiency SQL> UPDATE employees 2 SET salary=salary*1.1 3 WHERE employee_id=736; Server process
Server process LGRW SQL> DELETE FROM employees 2 WHERE employee_id=7400;
ARCH
Redo log files Copyright Š 2003, Oracle. All rights reserved.
Archived log files
Using Dynamic Views to Analyze Redo Log Buffer Efficiency v$session_wait
Redo log buffer
Log Buffer Space event
v$sysstat Redo Buffer Allocation Retries Redo Entries
Copyright Š 2003, Oracle. All rights reserved.
Performance Manager
Copyright Š 2003, Oracle. All rights reserved.
Redo Log Buffer Tuning Guidelines
•
There should be no Log Buffer Space waits. SQL> SELECT sid, event, seconds_in_wait, state 2 FROM v$session_wait 3 WHERE event = 'log buffer space';
•
Redo Buffer Allocation Retries value should be near 0 and should be less than 1% of redo entries. SQL> SELECT name, value 2 FROM v$sysstat 3 WHERE name IN ('redo entries', 4 'redo buffer allocation retries');
Copyright © 2003, Oracle. All rights reserved.
Reducing Redo Operations
Ways to avoid logging bulk operations in the redo log: • Direct Path loading without archiving does not generate redo. • Direct Path loading with archiving can use Nologging mode. • Direct Load Insert can use Nologging mode. • Some SQL statements can use Nologging mode.
Copyright © 2003, Oracle. All rights reserved.
Monitoring Java Pool Memory
Limit Java session memory usage: • JAVA_SOFT_SESSIONSPACE_LIMIT • JAVA_MAX_SESSIONSPACE_SIZE SQL> SELECT * FROM v$sgastat 2
WHERE pool = 'java pool';
POOL
NAME
BYTES
----------- ---------------------- ---------java pool
free memory
30261248
java pool
memory in use
19742720
Copyright © 2003, Oracle. All rights reserved.
Sizing the SGA for Java
•
SHARED_POOL_SIZE: – 8 KB per loaded class – 50 MB for loading large JAR files
• •
Configure Oracle Shared Server JAVA_POOL_SIZE – 24 MB default – 50 MB for medium-sized Java application
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Monitor and size the redo log buffer • Monitor and size the Java pool • Control the amount of Java session memory used by a session
Copyright © 2003, Oracle. All rights reserved.
Tuning the Oracle Shared Server
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Identify issues associated with managing users in an Oracle Shared Server environment • Configure the Oracle Shared Server environment to optimize performance • Diagnose and resolve performance issues with Oracle Shared Server processes
Copyright © 2003, Oracle. All rights reserved.
Overview
Dispatcher processes
Oracle server code program interface
Request queue
Shared server processes
Response queues
System Global Area
Oracle background processes
Copyright Š 2003, Oracle. All rights reserved.
Client Database server Listener
Oracle Shared Server Characteristics
• • • • •
Enables users to share processes Supports Oracle Net functionality Increases the number of concurrent users Useful on servers with remote clients CPU overhead could possibly increase for each individual user request
Copyright © 2003, Oracle. All rights reserved.
Monitoring Dispatchers
•
Use the following dynamic views: – v$shared_server_monitor – v$dispatcher – v$dispatcher_rate
•
Identify contention for dispatchers by checking: – Busy rates – Dispatcher waiting time
• •
Check for dispatcher contention. Add or remove dispatchers while the database is open.
Copyright © 2003, Oracle. All rights reserved.
Monitoring Shared Servers
• •
Oracle Shared Servers are started up dynamically. However, you should monitor the shared servers by: – Checking for shared server process contention – Adding or removing idle shared servers
Copyright © 2003, Oracle. All rights reserved.
Monitoring Process Usage
The v$circuit view displays: • • •
Server address Dispatcher address User session address
Copyright © 2003, Oracle. All rights reserved.
Shared Servers and Memory Usage
• • • •
Some user information goes into the shared pool. To reduce the load on the shared pool set a large pool. Overall memory demand is lower when using shared servers. Shared servers use the user global area (UGA) for sorts.
Copyright © 2003, Oracle. All rights reserved.
Troubleshooting
Possible causes of problems with the shared server include the following: • The database listener is not running. • The Oracle Shared Server initialization parameters are set incorrectly. • The dispatcher process has been killed. • The DBA does not have a dedicated connection. • The PROCESSES parameter is too low.
Copyright © 2003, Oracle. All rights reserved.
Obtaining Dictionary Information
Dynamic performance views: • v$circuit • v$dispatcher • v$dispatcher_rate • v$queue • v$shared_server_monitor • v$session • v$shared_server
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Describe the Oracle Shared Server as a resourcesharing configuration • List some situations in which it is appropriate to use the Oracle Shared Server • Monitor dispatcher and server usage • Troubleshoot Oracle Shared Server configuration
Copyright © 2003, Oracle. All rights reserved.
Optimizing Sort Operations
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • List the operations that use temporary space • Create and monitor temporary tablespaces • Identify actions that use the temporary tablespace • Describe and differentiate disk sorts and memory sorts • Identify the SQL operations that require sorts • List ways to reduce total sorts and disk sorts • Determine the number of memory sorts performed • Set parameters to optimize sorts Copyright © 2003, Oracle. All rights reserved.
Automatic Sort Area Management
•
Parameters for automatic sort area management: – PGA_AGGREGATE_TARGET (Ranges from 10 MB to 4000 GB)
•
– WORKAREA_SIZE_POLICY – AUTO | MANUAL Replaces all *_AREA_SIZE parameters
Copyright © 2003, Oracle. All rights reserved.
PGA Management Resources
Statistics to manage the PGA_AGGREGATE_TARGET initialization parameter • Views for monitoring the PGA work area include: – – – – –
•
v$sql_workarea_histogram v$pgastat v$sql_workarea_active v$sql_workarea v$tempseg_usage
Views to assist in sizing the PGA work area are: – v$pga_target_advice – v$pga_target_advice_histogram
Copyright © 2003, Oracle. All rights reserved.
Work Area Groups and PGA Cache Hit Percentages Percent executions
Optimal size One-pass size Multi-pass size
100%
97%
94%
0% …
0%
64-128KB
6%
0%
128-256KB
0% …
Copyright © 2003, Oracle. All rights reserved.
3% 64-128MB
Determining PGA Workload
SQL> 2 3 4 5 6 7 8 9 10 11
SELECT low_optimal_size/1024 AS low_kb, (high_optimal_size+1)/1024 AS high_kb, ROUND(100*optimal_executions /total_executions) AS optimal, ROUND(100*onepass_executions /total_executions) AS onepass, ROUND(100*multipasses_executions /total_executions) AS multipass FROM v$sql_workarea_histogram WHERE total_executions != 0 ORDER BY low_kb;
Copyright Š 2003, Oracle. All rights reserved.
Other Views for Work Areas
SQL> SELECT * 2 FROM v$pgastat 3 WHERE name = 'cache hit percentage'; NAME VALUE UNIT ------------------------- ---------- --------cache hit percentage 93 percent
Copyright Š 2003, Oracle. All rights reserved.
Querying v$pga_target_advice
SQL> 2 3 4 5 6
SELECT ROUND(pga_target_for_estimate /1024/1024) AS target_mb, estd_pga_cache_hit_percentage AS cache_hit_percent, estd_overalloc_count FROM v$pga_target_advice ORDER BY target_mb;
Copyright Š 2003, Oracle. All rights reserved.
Understanding v$pga_target_advice TARGET_MB CACHE_HIT_PERCENT ESTD_OVERALLOC_COUNT ---------- ----------------- -------------------63 23 367 125 24 30 250 30 3 375 39 1 500 58 0 600 59 0 700 59 0 800 60 0 900 60 0 1000 61 0 1500 67 0 2000 76 0 3000 83 0 4000 85 0 Copyright Š 2003, Oracle. All rights reserved.
PGA Sizing Advisor Output in Oracle Enterprise Manager
Copyright Š 2003, Oracle. All rights reserved.
Overview
The automatic sort area management feature is: • Easier to set up and size than the *_SORT_AREA parameters •
Easier to monitor using the advisory view
Copyright © 2003, Oracle. All rights reserved.
The Sorting Process
If sort space requirement is greater than SORT_AREA_SIZE:
Sort run 1
Sort run 2 TEMPORARY tablespace Temporary segment
Server process
Sort run 2
Copyright Š 2003, Oracle. All rights reserved.
Segments hold data while the server works on another sort run
Sort Area and Parameters
The sort space is in: • The PGA for a dedicated server connection PGA UGA Shared pool
•
User Stack Cursor Sort session space state area data
The shared pool for Oracle Shared Server connection PGA
UGA User session data
Cursor state
Sort area
Copyright © 2003, Oracle. All rights reserved.
Stack space
Sort Area and Parameters
• •
An execution plan can contain multiple sorts A single server performing a sort needs: – An area of SORT_AREA_SIZE, in bytes – At least one area of SORT_AREA_RETAINED_SIZE for a join sort
•
Each parallel query server needs SORT_AREA_SIZE
•
Two sets of servers can be writing at once, so: – Calculate SORT_AREA_SIZE × 2 × degree of parallelism – Add SORT_AREA_RETAINED_SIZE × degree of parallelism × number of sorts above two Copyright © 2003, Oracle. All rights reserved.
Tuning Sorts
• • • •
Use automatic sort area management. Avoid sort operations whenever possible. Reduce swapping and paging by making sure that sorting is done in memory when possible. Reduce space allocation calls by allocating temporary space appropriately.
Copyright © 2003, Oracle. All rights reserved.
The Sorting Process and Temporary Space Temporary tablespace Permanent
Objects
One single sort segment
2M
2M
2M
temp01.dbf
temp02.dbf
temp04.dbf
Create a temporary tablespace by using: CREATE TEMPORARY TABLESPACE TEMP TEMPFILE '$HOME/ORADATA/u06/temp01.dbf' size 200M; Copyright Š 2003, Oracle. All rights reserved.
Temporary Space Segments
A temporary space segment: • Is created by the first sort • Extends as demands are made on it • Comprises extents, which can be used by different sorts • Is described in the sort extent pool (SEP)
Copyright © 2003, Oracle. All rights reserved.
Operations Requiring Sorts
Some of the operations that may require sorts are: • Index creation • Parallel insert operations involving index maintenance • ORDER BY or GROUP BY clauses • DISTINCT values selection • UNION, INTERSECT, or MINUS operators • •
Sort-merge joins ANALYZE command execution
Copyright © 2003, Oracle. All rights reserved.
Avoiding Sorts
Avoid sort operations whenever possible: • Use NOSORT to create indexes. •
Use UNION ALL instead of UNION.
• •
Use index access for table joins. Create indexes on columns referenced in the ORDER BY clause.
• •
Select the columns for analysis. Use ESTIMATE rather than COMPUTE for large objects.
Copyright © 2003, Oracle. All rights reserved.
Diagnostic Tools v$sort_usage
Server process
Sort area (UGA)
Sort in memory
v$sort_segment
PCTINCREASE TEMPORARY INITIAL tablespace NEXT
Sort on disk v$sysstat
SORT_AREA_SIZE SORT_AREA_RETAINED_SIZE Statspack
Copyright Š 2003, Oracle. All rights reserved.
Diagnostics and Guidelines
• •
In an OLTP system the ratio of disk sorts to memory sorts should be less than 5%. Increase the value of SORT_AREA_SIZE / PGA_AGGREGATE_TARGET if the ratio is greater than 5%. SQL> 2 3 4 5
SELECT d.value "Disk", m.value "Mem", (d.value/m.value)*100 "Ratio" FROM v$sysstat m, v$sysstat d WHERE m.name = 'sorts (memory)' AND d.name = 'sorts (disk)'; Disk Mem Ratio ------------------------23 206 11.165049 Copyright © 2003, Oracle. All rights reserved.
Performance Manager: Sorts
Copyright Š 2003, Oracle. All rights reserved.
Monitoring Temporary Tablespaces
• •
Default storage parameters apply to sort segments. Sort segments have unlimited extents. SQL> SELECT tablespace_name, current_users, total_extents, 2
used_extents, extent_hits, max_used_blocks,
3
max_sort_blocks
4
FROM v$sort_segment;
TABLESPACE_NAME CURRENT_USERS TOTAL_EXTENTS USED_EXTENTS EXTENT_HITS MAX_USED_BLOCKS MAX_SORT_BLOCKS --------------- ------------- ------------- ---------------------- --------------- --------------TEMP 20
2 200
4 200
Copyright © 2003, Oracle. All rights reserved.
3
Temporary Tablespace Configuration
• •
Set appropriate storage values. Set up different temporary tablespaces based on sorting needs. SQL> SELECT session_num, tablespace, extents, blocks 2
FROM v$sort_usage;
SESSION_NUM
TABLESPACE
-----------
---------------------- -------- --------
16
• •
EXTENTS
TEMP
BLOCKS 4
200
Stripe temporary tablespaces. Use v$tempfile and dba_temp_files for information on temporary files. Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • List the operations that use temporary space • Create and monitor temporary tablespaces • Identify actions that use the temporary tablespace • Describe the use of disk and memory for sorting • Identify the SQL operations that require sorts • Differentiate between disk and memory sorts • List ways to reduce total sorts and disk sorts • Determine the number of memory sorts performed • Set parameters to optimize sorts
Copyright © 2003, Oracle. All rights reserved.
Using Resource Manager
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Set up Database Resource Manager • Assign users to Resource Manager groups • Create resource plans within groups
Copyright © 2003, Oracle. All rights reserved.
Overview
• •
Manage mixed workload Control system performance Database resource manager OLTP user
OLTP More resources DSS Less resources
DSS user Copyright © 2003, Oracle. All rights reserved.
Oracle9i
Database Resource Manager Concepts Resource consumer group
User groups with similar resource needs (one active resource consumer group per session)
Resource plan
Resource plan directives
Allocates CPU and PQ servers (one active plan)
Assigns groups and resources to plans Copyright Š 2003, Oracle. All rights reserved.
Using Sub-Plans to Limit CPU Utilization MYDB PLAN 30% @ L1
MAILDB PLAN 40% @ L1
70% @ L1
100% @ L3
100% @ L3
100% @ L2
BUGDB PLAN
80% @ L1
100% @ L2
20% @ L1
POSTMAN MAIL MAINT OTHER ONLINE BATCH BUG MAINT Groups Group Group Group Group Group
Copyright © 2003, Oracle. All rights reserved.
Resource Allocation Methods
Method
Resource
Recipient
Round-robin
CPU to sessions
Groups
Emphasis
CPU to groups
Plans
Absolute
Parallel degree
Plans
Copyright Š 2003, Oracle. All rights reserved.
The Initial Plan: SYSTEM_PLAN Allocation methods
Resource consumer group
P1CPU
P2CPU P3CPU P1//
SYS_GROUP
100%
0%
0%
0
OTHER_GROUPS
0%
100%
0%
0
LOW_GROUP
0%
0%
100%
0
Copyright Š 2003, Oracle. All rights reserved.
Administering the Database Resource Manager • •
Assign the resource manager system privileges to the administrator. Create resource objects with the package dbms_resource_manager: – Resource consumer groups – Resource plans – Resource plan directives
•
Assign users to groups with the package dbms_resource_manager_privs.
•
Specify the plan to be used by the instance.
Copyright © 2003, Oracle. All rights reserved.
Oracle Enterprise Manager: Resource Manager
Copyright Š 2003, Oracle. All rights reserved.
Assigning the Resource Manager Privilege
Assign the resource manager system privileges to the administrator. dbms_resource_manager_privs.grant_system_privilege ( grantee_name => 'OE', privilege_name => 'ADMINISTER_RESOURCE_MANAGER', admin_option => False );
Copyright Š 2003, Oracle. All rights reserved.
Creating Database Resource Manager Objects •
Create resource objects with the dbms_resource_manager package.
•
Create a pending area. dbms_resource_manager.create_pending_area();
•
Create resource consumer groups. dbms_resource_manager.create_consumer_group ( consumer_group => 'OLTP', comment => 'Online users' );
Copyright © 2003, Oracle. All rights reserved.
Creating Database Resource Manager Objects •
Create resource plans. dbms_resource_manager.create_plan ( plan => 'NIGHT', comment => 'DSS/Batch priority, ...' );
•
Create resource plan directives. dbms_resource_manager.create_plan_directive ( plan => 'NIGHT', group_or_subplan => 'SYS_GROUP', comment => '...', cpu_p1 => 100, parallel_degree_limit_p1 => 20); Copyright © 2003, Oracle. All rights reserved.
Active Session Pool
DBAs use Database Resource Manager to limit the amount of concurrent active sessions per resource consumer group by defining an active session pool. Benefits of an active session pool: • DBAs can meet performance service-level objectives by limiting the concurrent system workload. • The number of servers taking resources in the system is reduced. This avoids inefficient paging, swapping, and other resource depletion.
Copyright © 2003, Oracle. All rights reserved.
Active Session Pool Mechanism
•
The active session pool: – Size can be set per resource consumer group. – Size is limited to only one per consumer group. – Is the maximum number of concurrently active sessions. – Is defined as a session currently part of an active transaction, query, or parallel operation.
•
•
When the active session pool is filled with active sessions, all subsequent sessions attempting to become active are queued. Individual parallel slaves do not count toward the number of sessions. The entire parallel operation counts as one active session. Copyright © 2003, Oracle. All rights reserved.
Active Session Pool Parameters
The active session pool is defined by setting the parameters: • ACTIVE_SESS_POOL_P1 – Identifies the number of active sessions that establishes the resource consumer group's threshold – Default is 1000000
•
QUEUEING_P1 – Indicates how long, in seconds, any session will wait on the queue before aborting the current operation – Default is 1000000
Copyright © 2003, Oracle. All rights reserved.
Setting the Active Session Pool
Example: GROUP
ACTIVE SESSION POOL
OLTP BATCH
ACTIVE_SESS_POOL_P1 = 5 QUEUEING_P1 = 600
OLTP: Set no limit on concurrent active sessions. BATCH: Set to limit concurrent active sessions to 5. QUEUEING_P1, set to 600, aborts all operations that wait on the queue for more than ten minutes. Copyright Š 2003, Oracle. All rights reserved.
Maximum Estimated Execution Time
• •
• •
•
The Database Resource Manager can estimate the execution time of an operation proactively. A DBA can specify a maximum estimated execution time for an operation at the resource consumer group level. Operation will not start if the estimate is longer than MAX_EST_EXEC_TIME. The benefit of this feature is the elimination of the exceptionally large job that uses too many system resources. The default is 1000000 seconds.
Copyright © 2003, Oracle. All rights reserved.
Automatic Consumer Group Switching
•
The Database Resource Manager automatically switches a session’s consumer group based on the following resource plan directive parameters: – SWITCH_GROUP: Group switched to. Default is NULL. – SWITCH_TIME: Active time in seconds. Default is 1000000. – SWITCH_ESTIMATE: If value is True, execution time estimate is used to decide whether to switch an operation even before it starts. Default is False.
•
This feature can be used to limit the resources consumed by long-running operations.
Copyright © 2003, Oracle. All rights reserved.
Undo Quota
The UNDO_POOL plan directive: • • •
Limits the amount of undo space that can be used When exceeded, prevents DML SELECT statements are still allowed
• •
Is specified in kilobytes Default is 1000000
Copyright © 2003, Oracle. All rights reserved.
Creating Database Resource Manager Objects •
Validate the pending area.
dbms_resource_manager.validate_pending_area();
•
Commit the pending area.
dbms_resource_manager.submit_pending_area();
Copyright © 2003, Oracle. All rights reserved.
Assigning Users to Consumer Groups •
Assign users to groups. dbms_resource_manager_privs. grant_switch_consumer_group ( grantee_name => 'MOIRA', consumer_group => 'OLTP', grant_option => False );
•
Set the initial consumer group for users: dbms_resource_manager. set_initial_consumer_group ( user => 'MOIRA', consumer_group => 'OLTP' );
Copyright © 2003, Oracle. All rights reserved.
Setting the Resource Plan for an Instance
• •
Specify the plan to be used by the instance. Specify the RESOURCE_MANAGER_PLAN initialization parameter. RESOURCE_MANAGER_PLAN=day
•
Change the resource plan without shutting down and restarting the instance. ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=night;
Copyright © 2003, Oracle. All rights reserved.
Changing a Consumer Group Within a Session The user or the application can switch the current consumer group. dbms_session. switch_current_consumer_group ( new_consumer_group => 'DSS', old_consumer_group => v_old_group, initial_group_on_error => False );
Copyright Š 2003, Oracle. All rights reserved.
Changing Consumer Groups for Sessions •
Can be set by DBA for a session dbms_resource_manager. switch_consumer_group_for_sess ( session_id => 7, session_serial => 13, consumer_group => 'OLTP');
•
Can be set by DBA for all sessions for a user dbms_resource_manager. switch_consumer_group_for_user ( user => 'MOIRA', consumer_group => 'OLTP'); Copyright © 2003, Oracle. All rights reserved.
Database Resource Manager Information
• • • • • •
dba_rsrc_plans plans and status dba_rsrc_plan_directives plan directives dba_rsrc_consumer_groups consumer groups dba_rsrc_consumer_group_privs users/roles dba_users column initial_rsrc_consumer_group dba_rsrc_manager_system_privs users/roles
Copyright © 2003, Oracle. All rights reserved.
Resource Plan Directives
SQL> SELECT plan, group_or_subplan, cpu_p1, cpu_p2, 2 cpu_p3, parallel_degree_limit_p1, status 3 FROM dba_rsrc_plan_directives;
Copyright Š 2003, Oracle. All rights reserved.
Current Database Resource Manager Settings •
v$session: Contains the
resource_consumer_group column that • •
shows the current group for a session v$rsrc_plan: A view that shows the active resource plan v$rsrc_consumer_group: A view that contains statistics for all active groups
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to do the following: • Set up Database Resource Manager • Assign users to Resource Manager groups • Create resource plans within groups
Copyright © 2003, Oracle. All rights reserved.
SQL Statement Tuning
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Control optimizer options • Use optimizer hints • Employ plan stability • Use stored outlines • Use SQL Trace and TKPROF
Copyright © 2003, Oracle. All rights reserved.
Overview
The purpose of this lesson is: • To provide methods to determine the resources used by SQL statements: – – – –
Oracle Enterprise Manager Statspack Explain plan SQL Trace and TKPROF
– Autotrace
• •
To determine which SQL statements possibly require tuning Not to tune the actual SQL statements
Copyright © 2003, Oracle. All rights reserved.
Optimizer Modes
There are two types of optimizer modes: • Rule-based: – Uses a ranking system – Syntax- and data dictionary-driven
•
Cost-based: – Chooses the path with lowest cost – Statistics-driven
Copyright © 2003, Oracle. All rights reserved.
Setting the Optimizer Mode
•
At the instance level: – optimizer_mode = {Choose|Rule|First_rows|First_rows_n| All_rows}
•
At the session level: – ALTER SESSION SET optimizer_mode = {Choose|Rule|First_rows|First_rows_n| All_rows}
•
At the statement level: – Using hints
Copyright © 2003, Oracle. All rights reserved.
Using Hints in a SQL Statement
SQL> CREATE index gen_idx on customers 2 (cust_gender);
SQL> 2 3 4 5
SELECT /*+ INDEX(customers gen_idx)*/ cust_last_name, cust_street_address, cust_postal_code FROM sh.customers WHERE UPPER (cust_gender) = ‘M';
Copyright © 2003, Oracle. All rights reserved.
Optimizer Plan Stability
• • • •
Users can stabilize execution plans, to force applications to use a desired SQL access path. A consistent execution path is thereby maintained through database changes. This is done by creating a stored outline consisting of hints. The OPTIMIZER_FEATURES_ENABLE parameter enables the optimizer to retain CBO features of previous versions.
Copyright © 2003, Oracle. All rights reserved.
Plan Equivalence
• •
SQL statement text must match the text in a stored outline. Plans are maintained through: – – – – –
New Oracle versions New statistics on objects Initialization parameter changes Database reorganization Schema changes
Copyright © 2003, Oracle. All rights reserved.
Creating Stored Outlines
SQL> 2 SQL> SQL>
ALTER SESSION SET CREATE_STORED_OUTLINES = train; SELECT … FROM … ; SELECT … FROM … ;
SQL> 2 3 4 5 6
CREATE OR REPLACE OUTLINE co_cl_join FOR CATEGORY train ON SELECT co.crs_id, ... FROM courses co , classes cl WHERE co.crs_id = cl.crs_id;
Copyright © 2003, Oracle. All rights reserved.
Using Stored Outlines
•
Set the USE_STORED_OUTLINES parameter to True or to a category name: SQL> ALTER SESSION 2 SET USE_STORED_OUTLINES = train; SQL> SELECT … FROM … ;
•
Both CREATE_STORED_OUTLINES and USE_STORED_OUTLINES can be set at the instance or session level.
Copyright © 2003, Oracle. All rights reserved.
Using Private Outlines
Private outlines are: • Edited without affecting the running system • Copies of current storage outlines • Controlled using the USE_PRIVATE_OUTLINES parameter
Copyright © 2003, Oracle. All rights reserved.
Editing Stored Outlines
Editing and using private outlines: • Create the outline tables in the current schema. • Copy the selected outline to private outline. • Edit the outline stored as a private outline. • To use the private outline, set the USE_PRIVATE_OUTLINE parameter. • •
To allow public access to the new stored outline, overwrite the stored outline. Reset USE_PRIVATE_OUTLINE to False.
Copyright © 2003, Oracle. All rights reserved.
Maintaining Stored Outlines
•
Use the outln_pkg package to: – Drop outlines or categories of outlines – Rename categories
•
Use the ALTER OUTLINE command to: – Rename an outline – Rebuild an outline – Change the category of an outline
•
Outlines are stored in the outln schema
Copyright © 2003, Oracle. All rights reserved.
Oracle Enterprise Manager: Maintaining Stored Outlines
Copyright Š 2003, Oracle. All rights reserved.
Overview of Diagnostic Tools
• • •
Statspack EXPLAIN PLAN SQL trace and TKPROF
• •
SQL*Plus autotrace feature Oracle SQL Analyze
Copyright © 2003, Oracle. All rights reserved.
SQL Reports in Statspack
The following reports on statements are provided by Statspack: • SQL ordered by gets • SQL ordered by reads • SQL ordered by executions • SQL ordered by parse calls
Copyright © 2003, Oracle. All rights reserved.
Performance Manager: Top SQL
Copyright Š 2003, Oracle. All rights reserved.
Generate the Execution Plan
• •
Can be used without tracing Needs the plan_table table utlxplan.sql
•
Create the explain plan: SQL> EXPLAIN PLAN FOR 2 SELECT last_name FROM hr.employees;
Copyright © 2003, Oracle. All rights reserved.
Query the plan_table Table
Query plan_table to display the execution plans: • • • •
Query plan_table directly. Use script utlxpls.sql (hide Parallel Query information). Use script utlxplp.sql (show Parallel Query information). Use the dbms_xplan package. SQL> SELECT * 2 FROM TABLE(dbms_xplan.display);
Copyright © 2003, Oracle. All rights reserved.
Using SQL Trace and TKPROF
To use SQL trace and TKPROF: •
Set the initialization parameters. SQL> ALTER SESSION SET sql_trace = True;
•
Run the application. SQL> ALTER SESSION SET sql_trace = False;
•
Format the trace file with TKPROF.
•
Interpret the output.
Copyright © 2003, Oracle. All rights reserved.
Enabling and Disabling SQL Trace
•
At the instance level: SQL_TRACE = {True|False}
•
At the session level: SQL> ALTER SESSION SET 2 SQL_TRACE = {True|False}; SQL> 2 SQL> 2 3
EXECUTE dbms_session.set_sql_trace ({True|False}); EXECUTE dbms_system.set_sql_trace_in_session (session_id, serial_id, {True|False});
Copyright © 2003, Oracle. All rights reserved.
Formatting the Trace File with TKPROF
$ tkprof tracefile.trc output.txt [options]
tracefile.trc
output.txt
USER_DUMP_DEST
Copyright Š 2003, Oracle. All rights reserved.
TKPROF Statistics
• • • • • • •
Count: Number of execution calls CPU: CPU seconds used Elapsed: Total elapsed time Disk: Physical reads Query: Logical reads for consistent read Current: Logical reads in current mode Rows: Rows processed
Copyright © 2003, Oracle. All rights reserved.
SQL*Plus Autotrace
•
Create the plan_table table.
•
Create and grant the plustrace role. SQL> @$ORACLE_HOME/sqlplus/admin/plustrce.sql SQL> GRANT plustrace TO scott;
Autotrace syntax: SET AUTOTRACE [ Off | On | Traceonly ] [ Explain | Statistics ]
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Describe how the optimizer is used • Describe how hints are used • Explain the concept of plan stability • Explain the use of stored outlines • Use SQL Trace and TKPROF
Copyright © 2003, Oracle. All rights reserved.
Managing Statistics
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Collect system statistics • Collect statistics on indexes and tables • Collect and manage histogram statistics • Copy statistics between databases • Monitor indexes to determine usage
Copyright © 2003, Oracle. All rights reserved.
Managing Statistics
Use the dbms_stats package:
• • • • •
gather_table_stats gather_index_stats gather_schema_stats gather_database_stats gather_stale_stats
Copyright © 2003, Oracle. All rights reserved.
Table Statistics
• • • • • • •
Number of rows Number of blocks and empty blocks Average available free space Number of chained or migrated rows Average row length Last analyze date and sample size Data dictionary view: dba_tables
Copyright © 2003, Oracle. All rights reserved.
Collecting Segment-Level Statistics Statistics collected and the method of collection: • Logical reads: Sampled • Buffer busy waits: Continuous • Db block changes: Sampled • Physical reads: Continuous • Physical writes: Continuous • Physical reads direct: Continuous • Physical writes direct: Continuous • Global cache cr blocks served: Continuous • Global cache current blocks served: Continuous • ITL waits: Continuous • Row lock waits: Continuous Copyright © 2003, Oracle. All rights reserved.
Querying Segment-Level Statistics
Segment-level statistics are queried using: • v$segstat_name: Lists the segment statistics being collected • v$segstat: Displays the statistic value, statistic name, and other basic information • v$segment_statistics: Displays the segment owner and tablespace name in addition to all the rows contained in v$segstat
Copyright © 2003, Oracle. All rights reserved.
Using Dynamic Sampling
Dynamic sampling should be used when: • A better plan could be found • The cost of collecting the statistics is minimal compared to the execution time • The query is executed many times
Copyright © 2003, Oracle. All rights reserved.
Enabling Dynamic Sampling
Dynamic sampling is set using: • OPTIMIZER_DYNAMIC_SAMPLING = 0 Dynamic sampling is not performed • OPTIMIZER_DYNAMIC_SAMPLING = 1 Dynamic sampling performed when: – The query accesses more than one table. – A table has not been analyzed and there is no index. – The optimizer determines that a full table scan is required due to nonexistent statistics.
•
OPTIMIZER_DYNAMIC_SAMPLING > 1 – The higher the value the more aggressive dynamic sampling is performed. The upper limit is 10. Copyright © 2003, Oracle. All rights reserved.
Index Statistics
• • • • • • •
Index level (height) Number of leaf blocks and distinct keys Average number of leaf blocks per key Average number of data blocks per key Number of index entries Clustering factor Data dictionary view: dba_indexes
Copyright © 2003, Oracle. All rights reserved.
Index Tuning Wizard
Copyright Š 2003, Oracle. All rights reserved.
Column Statistics
• • • •
Number of distinct values Lowest value, highest value (stored in RAW [binary] format) Last analyze date and sample size Data dictionary view: user_tab_col_statistics
Copyright © 2003, Oracle. All rights reserved.
Histograms
• • • •
Histograms describe the data distribution of a particular column in more detail. They give better predicate selectivity estimates for unevenly distributed data. You create histograms with the dbms_stats.gather_table_stats procedure. Data dictionary views: dba_histograms, dba_tab_histograms
Copyright © 2003, Oracle. All rights reserved.
Generating Histogram Statistics
Histogram statistics are generated by: SQL> EXECUTE dbms_stats.gather_table_stats 2 ('HR','EMPLOYEES', METHOD_OPT => 3 'FOR COLUMNS SIZE 10 salary');
Copyright Š 2003, Oracle. All rights reserved.
Gathering Statistic Estimates
• •
dbms_stats.auto_sample_size: New estimate_percent value METHOD_OPT options: – REPEAT: New histogram with same number of buckets – AUTO: New histogram based on data distribution and application workload – SKEWONLY: New histogram based on data distribution SQL> 2 3 4
EXECUTE dbms_stats.gather_schema_stats( ownname => 'OE', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'for all columns size AUTO');
Copyright © 2003, Oracle. All rights reserved.
Automatic Statistic Collecting
For the dbms_stats.gather_schema_stats procedure set OPTIONS to:
• • •
Gather Stale Gather Empty Gather Auto
SQL> EXECUTE dbms_stats.gather_schema_stats 2 (OWNNAME => 'OE', 3 OPTIONS => 'GATHER AUTO');
Copyright © 2003, Oracle. All rights reserved.
Optimizer Cost Model
•
Three columns in plan_table are: – cpu_cost: Estimated CPU cost of the operation – io_cost: Estimated I/O cost of the operation – temp_space: Estimated temporary space (in bytes) used by the operation
• • •
Includes CPU usage Accounts for the effect of caching Accounts for index prefetching
Copyright © 2003, Oracle. All rights reserved.
Using System Statistics
• • •
System statistics enable the CBO to use CPU and I/O characteristics. System statistics must be gathered on a regular basis; this does not invalidate cached plans. Gathering system statistics equals analyzing system activity for a specified period of time.
Copyright © 2003, Oracle. All rights reserved.
Gathering System Statistics
Procedures of the dbms_stats package used to collect system statistics:
• • •
gather_system_stats set_system_stats get_system_stats
Copyright © 2003, Oracle. All rights reserved.
Automatic Gathering of System Statistics
•
Collect statistics for OLTP: SQL> EXECUTE dbms_stats.gather_system_stats 2 (interval => 120, stattab => 'mystats', 3 statid => 'OLTP');
•
Collect statistics for OLAP: SQL> EXECUTE dbms_stats.gather_system_stats 2 (interval => 120, stattab => 'mystats', 3 statid => 'OLAP');
Copyright © 2003, Oracle. All rights reserved.
Manual Gathering of System Statistics
•
Start manual system statistics collection in the data dictionary: SQL> EXECUTE dbms_stats.gather_system_stats 2 (gathering_mode => 'START');
• •
Generate the workload End system statistics collection: SQL> EXECUTE dbms_stats.gather_system_stats 2 (gathering_mode => 'STOP');
Copyright © 2003, Oracle. All rights reserved.
Import System Statistics Example
•
For daytime (OLTP): SQL> EXECUTE dbms_stats.import_system_stats 2 (stattab => 'mystats', statid => 'OLTP');
•
For nighttime (OLAP): SQL> EXECUTE dbms_stats.import_system_stats 2 (stattab => 'mystats', statid => 'OLAP');
Copyright © 2003, Oracle. All rights reserved.
Copying Statistics Between Databases
Data dictionary
Copy to user table 2
User-defined statistics table
Export 3 Import
Copy user table to DD 4
1 User-defined statistics table
Copyright Š 2003, Oracle. All rights reserved.
Data dictionary
Example: Create the Statistics Table
Step 1. Create the table to hold the statistics: dbms_stats.create_stat_table (‘SH' /* schema name */ ,'STATS' /* statistics table name */ ,'SAMPLE' /* tablespace */ );
Copyright © 2003, Oracle. All rights reserved.
Example: Copy the Statistics to a Table
Step 2. Copy the statistics to a table: dbms_stats.export_table_stats (’SH’ /* schema name */ ,’SALES’ /* table name */ , NULL /* no partitions */ ,’STATS’ /* statistics table name */ ,’CRS990601’ /* id for statistics */ , TRUE /* index statistics */ );
Step 3. Export the stats table and then import it into the second database.
Copyright © 2003, Oracle. All rights reserved.
Example: Import the Statistics
Step 4. Copy the statistics into the data dictionary: dbms_stats.import_table_stats (’SH’ /* schema name */ ,’SALES’ /* table name */ , NULL /* no partitions */ ,’STATS’ /* statistics table name */ ,’CRS990601’ /* id for statistics */ , TRUE /* index statistics */ );
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Collect system statistics • Collect statistics on indexes and tables • Describe the use of histograms • Copy statistics between databases • Determine usage of indexes
Copyright © 2003, Oracle. All rights reserved.
Using Oracle Blocks Efficiently
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Use automatic segment space management • Use manual segment space management • Describe the use of Oracle block parameters • Recover space from sparsely populated segments • Describe and detect chaining and migration of Oracle blocks • Perform index reorganization
Copyright © 2003, Oracle. All rights reserved.
Database Storage Hierarchy
Tablespace
Segments
Extents Extents
Extents
Blocks Copyright Š 2003, Oracle. All rights reserved.
Allocation of Extents
To avoid the disadvantages of dynamic extent allocation: • Create locally managed tablespaces. • Size the segments appropriately. • Monitor segments ready to extend.
Copyright © 2003, Oracle. All rights reserved.
Avoiding Dynamic Allocation
•
To display segments with less than 10% free blocks:
SQL> SELECT owner, table_name, blocks, empty_blocks 2 FROM dba_tables 3 WHERE empty_blocks/(blocks+empty_blocks) < .1; OWNER TABLE_NAME BLOCKS EMPTY_BLOCKS ------ ---------- ---------- -----------HR EMPLOYEES 1450 50 HR COUNTRIES 460 40
•
To avoid dynamic allocation:
SQL> ALTER TABLE hr.employees ALLOCATE EXTENT; Table altered.
Copyright © 2003, Oracle. All rights reserved.
Locally Managed Extents
•
Create a locally managed tablespace: SQL> 2 3 4 5 6
•
CREATE TABLESPACE user_data_1 DATAFILE ‘/oracle9i/oradata/db1/lm_1.dbf’ SIZE 100M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 2M;
With the Oracle database the default extent management is local.
Copyright © 2003, Oracle. All rights reserved.
Pros and Cons of Large Extents
•
Pros – Are less likely to extend dynamically – Deliver small performance benefit – Enable you to read the entire extent map with a single I/O operation
•
Cons – Free space may not be available – Unused space
Copyright © 2003, Oracle. All rights reserved.
The High-Water Mark
Extent 1 Empty blocks (rows deleted) Extent 2
Segment header block
Empty blocks (never used)
Copyright Š 2003, Oracle. All rights reserved.
Highwater mark
The High-Water Mark
•
The high-water mark is: – Recorded in the segment header block – Set to the beginning of the segment on creation – Incremented in five-block increments as rows are inserted – Reset by the TRUNCATE command
•
Never reset by using DELETE statements
Copyright © 2003, Oracle. All rights reserved.
Table Statistics
Populate the table statistics using the dbms_stats package and then query the values in dba_tables: SQL> EXECUTE dbms_stats.gather_table_stats > ('HR','EMPLOYEES'); PL/SQL procedure successfully completed. SQL> SELECT num_rows, blocks, empty_blocks as empty, 2 avg_space, chain_cnt, avg_row_len 3 FROM dba_tables 4 WHERE owner = 'HR' 5 AND table_name = 'EMPLOYEES'; NUM_ROWS BLOCKS EMPTY AVG_SPACE CHAIN_CNT AVG_ROW_LEN -------- ------ ----- --------- --------- ----------13214 615 35 1753 0 184
Copyright Š 2003, Oracle. All rights reserved.
The dbms_space Package DECLARE owner VARCHAR2(30); table_name VARCHAR2(30); seg_type VARCHAR2(30); tblock NUMBER; ... BEGIN dbms_space.unused_space ('&owner','&table_name','TABLE', tblock,tbyte,ublock,ubyte,lue_fid, lue_bid,lublock); dbms_output.put_line(... END; / Copyright Š 2003, Oracle. All rights reserved.
Recovering Space
Below the high-water mark: • Use the Export and Import utilities to: – Export the table – Drop or truncate the table – Import the table
•
Or use the Alter Table Employees Move command to move the table. Above the high-water mark, use the Alter Table Employees Deallocate Unused; command.
Copyright © 2003, Oracle. All rights reserved.
Database Block Size
Minimize block visits by: • Using a larger block size • Packing rows tightly • Preventing row migration Tablespace
Segments
Extents
Blocks Copyright © 2003, Oracle. All rights reserved.
The DB_BLOCK_SIZE Parameter
The database block size: • Is defined by the DB_BLOCK_SIZE parameter • • • • • •
Is set when the database is created Is the minimum I/O unit for data file reads Is 2 KB or 4 KB by default, but up to 64 KB is allowed Cannot be changed easily Should be an integer multiple of the OS block size Should be less than or equal to the OS I/O size
Copyright © 2003, Oracle. All rights reserved.
Small Block Size: Pros and Cons
•
Pros – Reduces block contention – Is good for small rows – Is good for random access
•
Cons – Has a relatively large overhead – Has a small number of rows per block – Can cause more index blocks to be read
Copyright © 2003, Oracle. All rights reserved.
Large Block Size: Pros and Cons
•
Pros – – – –
•
Less overhead Good for sequential access Good for very large rows Better performance of index reads
Cons – Increases block contention – Uses more space in the buffer cache
Copyright © 2003, Oracle. All rights reserved.
PCTFREE and PCTUSED
Inserts
Inserts
1
2
Inserts
Inserts
3
4
Copyright Š 2003, Oracle. All rights reserved.
Guidelines for PCTFREE and PCTUSED
•
PCTFREE – Default is 10 – Zero if no UPDATE activity
•
– PCTFREE = 100 × UPD / (Average row length) PCTUSED – Default is 40 – Set if rows are deleted – PCTUSED = 100 – PCTFREE – 100 × Rows × (Average row length) / Block size
Copyright © 2003, Oracle. All rights reserved.
Migration and Chaining Migration
Chaining
Index
Table
Copyright Š 2003, Oracle. All rights reserved.
Detecting Migration and Chaining
Use the ANALYZE command to detect migration and chaining: SQL> ANALYZE TABLE oe.orders COMPUTE STATISTICS; PL/SQL procedure successfully completed. SQL> SELECT num_rows, chain_cnt FROM dba_tables 2 WHERE table_name='ORDERS'; NUM_ROWS CHAIN_CNT --------- --------168 102
Detect migration and chaining by using Statspack: Statistic Total Per transaction ... ------------------------- ----- --------------- ... table fetch continued row 495 .02 …
Copyright © 2003, Oracle. All rights reserved.
Selecting Migrated Rows
SQL> ANALYZE TABLE oe.orders LIST CHAINED ROWS; Table analyzed. SQL> SELECT owner_name, table_name, head_rowid 2 FROM chained_rows 3 WHERE table_name = 'ORDERS'; OWNER_NAME TABLE_NAME HEAD_ROWID ---------- ---------- -----------------SALES ORDER_HIST AAAAluAAHAAAAA1AAA SALES ORDER_HIST AAAAluAAHAAAAA1AAB ...
Copyright © 2003, Oracle. All rights reserved.
Eliminating Migrated Rows
•
Export/Import – Export the table. – Drop or truncate the table. – Import the table.
•
Move table command: – Alter Table Employees Move
•
Copying migrated rows – Find migrated rows using ANALYZE. – Copy migrated rows to new table. – Delete migrated rows from original table. – Copy rows from new table to original table.
Copyright © 2003, Oracle. All rights reserved.
Index Reorganization
• • • •
Indexes on volatile tables are a performance problem. Only entirely empty index blocks go to the free list. If a block contains only one entry, it must be maintained. You may need to rebuild indexes.
Copyright © 2003, Oracle. All rights reserved.
Monitoring Index Space To collect usage statistics regarding an index: SQL> EXECUTE dbms_stats.gather_index_stats > ('OE','CUSTOMERS_PK');
To view statistics collected: SQL> SELECT name, 2 (DEL_LF_ROWS_LEN/LF_ROWS_LEN) * 100 AS wastage 3 FROM index_stats;
Rebuild indexes with wastage greater than 20%: SQL> ALTER INDEX oe.customers_pk REBUILD;
To coalesce indexes (alternative to REBUILD): SQL> ALTER INDEX oe.customers_pk COALESCE; Copyright Š 2003, Oracle. All rights reserved.
Deciding Whether to Rebuild or Coalesce an Index Rebuild
Coalesce
Quickly moves index to another tablespace.
Cannot move index to another tablespace.
Higher costs: Requires more disk space.
Lower costs: Does not require more disk space.
Creates new tree, shrinks height if applicable.
Coalesces leaf blocks within same branch of tree.
Enables you to quickly change storage and tablespace parameters without having to drop the original index.
Quickly frees up index leaf blocks for use.
Copyright Š 2003, Oracle. All rights reserved.
Monitoring Index Usage
•
Gathering statistics using an Oracle supplied package: SQL> EXECUTE
•
dbms_stats.gather_index_stats (‘HR’,’LOC_COUNTRY_IX’);
Gathering statistics at index creation: SQL> CREATE INDEX hr.loc_country_ix 2 …………………… 5 COMPUTE STATISTICS;
•
Gathering statistics when rebuilding an index: SQL> ALTER INDEX hr.loc_country_ix REBUILD 2 COMPUTE STATISTICS;
Copyright © 2003, Oracle. All rights reserved.
Identifying Unused Indexes
• •
•
To start monitoring the usage of an index: SQL> ALTER INDEX hr.emp_name_ix 2 MONITORING USAGE;
To query the usage of the index: SQL> SELECT index_name, used 2 FROM v$object_usage;
•
To stop monitoring the usage of an index: SQL> ALTER INDEX hr.emp_name_ix 2 NOMONITORING USAGE;
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned to do the following: • Use automatic segment space management • Use manual segment space management – Manage extents and Oracle blocks – Ensuring effective use of space – Determine the high-water mark
• • • •
Describe the use of Oracle Block parameters Recover space from sparsely populated segments Describe and detect chaining and migration of Oracle blocks Perform index reorganization Copyright © 2003, Oracle. All rights reserved.
Using Oracle Data Storage Structures Efficiently
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Compare and evaluate the different storage structures • Examine different data access methods • Implement different partitioning methods
Copyright © 2003, Oracle. All rights reserved.
Data Storage Structures
Heap table
Cluster
Indexorganized table
Organization by value Heap
Clustered
Sorted
Partitioned table
Copyright Š 2003, Oracle. All rights reserved.
Selecting the Physical Structure
Factors affecting the selection: • Rows read in groups • SELECT or DML statements • • • •
Table size Row size, row group, and block size Small or large transactions Using parallel queries to load or for SELECT statements
Copyright © 2003, Oracle. All rights reserved.
Data Access Methods
To enhance performance, you can use the following data access methods: • Clusters • Indexes • B-tree (normal or reverse key) • Bitmap • Function based • Index-organized tables • Materialized views
Copyright © 2003, Oracle. All rights reserved.
Clusters ORD_NO ----101 102 102 102 101 101
PROD -----A4102 A2091 G7830 N9587 A5675 W0824
QTY -----20 11 20 26 19 10
ORD_NO -----101 102
...
ORD_DT CUST_CD ----------05-JAN-97 R01 07-JAN-97 N45
Unclustered orders and order_item tables
Cluster Key (ORD_NO) 101 ORD_DT CUST_CD 05-JAN-97 R01 PROD QTY A4102 20 A5675 19 W0824 10 102 ORD_DT CUST_CD 07-JAN-97 N45 PROD QTY A2091 11 G7830 20 N9587 26
Clustered orders and order_item tables
Copyright Š 2003, Oracle. All rights reserved.
Cluster Types Index cluster
Hash cluster
Hash function
Copyright Š 2003, Oracle. All rights reserved.
Situations Where Clusters Are Useful
Criterion Uniform key distribution
Index
Hash
X
X
Evenly distributed key values
X
Rarely updated key
X
Often joined master-detail tables
X
X
Predictable number of key values
X
Queries using equality predicate on key
X
Copyright Š 2003, Oracle. All rights reserved.
Partitioning Methods
The following partitioning methods are available: • Range • Hash • List • Composite
Range partitioning
Hash partitioning
List partitioning
Copyright © 2003, Oracle. All rights reserved.
Composite partitioning
Range Partitioning Example
CREATE TABLE sales (acct_no NUMBER(5), person VARCHAR2(30), sales_amount NUMBER(8), 1 week_no NUMBER(2)) 3 PARTITION BY RANGE (week_no) 2 (PARTITION P1 VALUES LESS THAN (4) TABLESPACE data0, PARTITION P2 VALUES LESS THAN (8) TABLESPACE data1, ...… PARTITION P13 VALUES LESS THAN (53)TABLESPACE data12 );
The partition key is week_no. 2 VALUES LESS THAN must be specified as a literal. 3 Physical attributes can be set per partition. 1
Copyright © 2003, Oracle. All rights reserved.
Hash Partitioning Overview
• • • • •
Easy to Implement Enables better performance for PDML and partition-wise joins Inserts rows into partitions automatically based on the hash of the partition key Supports (hash) local indexes Does not support (hash) global indexes
Copyright © 2003, Oracle. All rights reserved.
List Partitioning Example SQL> CREATE TABLE locations 2 (location_id, street_address, 3 postal_code, city, state_province, 4 country_id) 5 STORAGE(INITIAL 10K NEXT 20K) 6 TABLESPACE users 7 PARTITION BY LIST (state_province) 8 (PARTITION region_east 9 VALUES('MA','NY','CT','ME','MD'), 10 PARTITION region_west 11 VALUES('CA','AZ','NM','OR','WA'), 12 PARTITION region_south 13 VALUES('TX','KY','TN','LA','MS'), 14 PARTITION region_central 15 VALUES('OH','ND','SD','MO','IL')); Copyright © 2003, Oracle. All rights reserved.
Default Partition for List Partitioning
Create a DEFAULT list partition for all values not covered by other partitions: CREATE TABLE customer ... PARTITION BY LIST (state) (PARTITION p1 VALUES ('CA','CO'), PARTITION p2 VALUES ('FL','TX'), PARTITION p3 VALUES (DEFAULT) );
Copyright Š 2003, Oracle. All rights reserved.
Composite Partitioned Table Overview
• • • • • •
Ideal for both historical data and data placement Provides high availability and manageability, like range partitioning Improves performance for parallel DML and supports partition-wise joins Allows more granular partition elimination Supports composite local indexes Does not support composite global indexes
Copyright © 2003, Oracle. All rights reserved.
Partitioned Indexes for Scalable Access Global Nonpartitioned index Global Partitioned Index
Table partition
Table partition
Table partition
Table partition
Local partitioned index Copyright Š 2003, Oracle. All rights reserved.
Partition Pruning 99-Jan 99-Feb 99-Mar 99-Apr 99-May 99-Jun
Partition pruning: Only the relevant partitions are accessed. SQL> 2 3 4 5 6 7
SELECT SUM(sales_amount) FROM sales WHERE sales_date BETWEEN TO_DATE(‘01-MAR-1999’, ‘DD-MON-YYYY’) AND TO_DATE(‘31-MAY-1999’, ‘DD-MON-YYYY’);
sales Copyright © 2003, Oracle. All rights reserved.
Partition-Wise Join
3 1
2
Full partition-wise join
Nonpartition-wise join
Partial partition-wise join Query slave
Partition
Copyright Š 2003, Oracle. All rights reserved.
Partitioned table
Statistics Collection for Partitioned Objects • • • •
You can gather object-, partition-, or subpartition level statistics. There are GLOBAL or NON-GLOBAL statistics. The dbms_stats package can gather global statistics at any level for tables only. It is not possible to gather: – Global histograms – Global statistics for indexes
Copyright © 2003, Oracle. All rights reserved.
Some dbms_stats Examples
CALL dbms_stats.gather_table_stats ( ownname => ‘o901’, tabname => ‘sales’, partname => ‘feb99’, granularity => ‘partition’);
CALL dbms_stats.gather_index_stats ( ownname => ‘o901’, indname => ‘isales’, partname => ‘s1’);
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to do the following: • Compare and evaluate the different storage structures • Examine different data access methods • Implement different partitioning methods
Copyright © 2003, Oracle. All rights reserved.
Application Tuning
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Explain the role of the DBA in tuning applications • Move tables using the ALTER TABLE command • • • •
Redefine a table online Create different types of indexes Build and manage index-organized tables Explain and plan OLTP, DSS, and hybrid systems
Copyright © 2003, Oracle. All rights reserved.
The Role of the Database Administrator
• • •
Application tuning is the most important part of tuning. DBAs are not always directly involved in application tuning. However, DBAs must be familiar with the impact that poorly written SQL statements can have upon database performance.
Copyright © 2003, Oracle. All rights reserved.
Moving Tables Using ALTER TABLE
Tables can be moved using the ALTER TABLE command. This allows: • Privileges and constraints to be kept • The table structure to be changed • Movement to another tablespace • The command to be parallelized SQL> ALTER TABLE hr.employees 2 MOVE 3 TABLESPACE users;
Copyright © 2003, Oracle. All rights reserved.
Redefining a Table Online
Online table redefinition enables you to: • Modify the storage parameters of the table • Move the table to a different tablespace in the same schema • Add support for parallel queries • Add or drop partitioning support • Re-create the table to reduce fragmentation • Change the organization of a normal table (heap organized) to an index-organized table and vice versa • Add or drop a column
Copyright © 2003, Oracle. All rights reserved.
B-Tree Indexes Index entry Root
Branch
Leaf
Index entry header Key column length Key column value Row ID
Copyright Š 2003, Oracle. All rights reserved.
Rebuilding Indexes
To assist in the rebuilding of indexes use: • ONLINE: Keeps the index available during the rebuild operation • COMPUTE STATISTICS: Collects the statistics while rebuilding the index
Copyright © 2003, Oracle. All rights reserved.
Compressed Indexes
When creating the index: SQL> 2 3 4
CREATE INDEX emp_last_name_idx ON hr.employees (last_name, first_name) COMPRESS;
When rebuilding the index: SQL> ALTER INDEX emp_last_name_idx 2 REBUILD COMPRESS;
Specify NOCOMPRESS (the default) to disable key compression. Copyright Š 2003, Oracle. All rights reserved.
Bitmap Indexes Table
File 3 Block 10 Block 11 Block 12
Index
Block 13 Start End Key ROWID ROWID
Bitmap
<Blue, 10.0.3, 12.8.3, 1000100100010010100> <Green, 10.0.3, 12.8.3, 0001010000100100000> <Red, 10.0.3, 12.8.3, 0100000011000001001> <Yellow, 10.0.3, 12.8.3, 0010001000001000010>
Copyright Š 2003, Oracle. All rights reserved.
Bitmap Indexes
• • • • •
Used for low-cardinality columns Good for multiple predicates Uses minimal storage space Best for read-only systems Good for very large tables
Copyright © 2003, Oracle. All rights reserved.
Creating and Maintaining Bitmap Indexes SQL> CREATE BITMAP INDEX departments_idx 2 ON hr.departments(manager_id) 3 STORAGE (INITIAL 200K NEXT 200K 4 PCTINCREASE 0 MAXEXTENTS 50) 5* TABLESPACE indx;
Copyright © 2003, Oracle. All rights reserved.
B-Tree Indexes and Bitmap Indexes
B-Tree Indexes
Bitmap Indexes
Suitable for high-cardinality columns
Suitable for low-cardinality columns
Updates on keys relatively inexpensive
Updates to key columns very expensive
Inefficient for queries using AND/OR predicates
Efficient for queries using AND/OR predicates
Row-level locking
Bitmap segment-level locking
More storage
Less storage
Useful for OLTP
Useful for DSS
Copyright Š 2003, Oracle. All rights reserved.
Reverse Key Index
KEY ----1257 2877 4567 6657 8967 9637 9947 ...
ROWID ------------------0000000F.0002.0001 0000000F.0006.0001 0000000F.0004.0001 0000000F.0003.0001 0000000F.0005.0001 0000000F.0001.0001 0000000F.0000.0001 ...
Index on employee_id column
EMPLOYEE_ID ----------7499 7369 7521 7566 7654 7698 7782 ... ...
LAST_NAME ... --------ALLEN SMITH WARD ... JONES MARTIN BLAKE CLARK ...
employees table
Copyright © 2003, Oracle. All rights reserved.
Creating Reverse Key Indexes
•
Create a reverse key unique index: SQL> 2 3 4 5
•
CREATE UNIQUE INDEX i1_t1 ON t1(c1) REVERSE PCTFREE 30 STORAGE(INITIAL 200K NEXT 200K PCTINCREASE 0 MAXEXTENTS 50) TABLESPACE indx;
Create a unique index, then alter the index to be reverse key: SQL> CREATE UNIQUE INDEX i2_t1 ON t1(c2); SQL> ALTER INDEX i2_t1 REBUILD REVERSE; Copyright © 2003, Oracle. All rights reserved.
Oracle Enterprise Manager: Index Management
Copyright Š 2003, Oracle. All rights reserved.
Index-Organized Tables Regular table access
IOT access
ROWID
Non-key columns Key column Row header
Copyright Š 2003, Oracle. All rights reserved.
Index-Organized Tables and Heap Tables •
Compared to heap tables, IOTs have: – Faster key-based access to table data – Reduced storage requirements – Secondary indexes and logical rowids
•
IOTs have the following restrictions: – Must have a primary key – Cannot be clustered
Copyright © 2003, Oracle. All rights reserved.
Creating Index-Organized Tables SQL> CREATE TABLE country 2 ( country_id CHAR(2) 3 CONSTRAINT country_id_nn NOT NULL, 4 country_name VARCHAR2(40), 5 currency_name VARCHAR2(25), 6 currency_symbol VARCHAR2(3), 7 map BLOB, 8 flag BLOB, 9 CONSTRAINT country_c_id_pk 10 PRIMARY KEY (country_id)) 11 ORGANIZATION INDEX 12 TABLESPACE indx 13 PCTTHRESHOLD 20 14 OVERFLOW TABLESPACE users; Copyright © 2003, Oracle. All rights reserved.
IOT Row Overflow indx tablespace Segment = COUNTRY_C_ID_PK IOT_type = IOT Segment_type = INDEX Index_type = IOT - TOP
Rows within
users tablespace Segment = SYS_IOT_OVER_n IOT_type = IOT_OVERFLOW Segment_type = TABLE
Remaining part of the row
PCTTHRESHOLD Copyright © 2003, Oracle. All rights reserved.
Querying dba_tables for IOT Information
SQL> SELECT table_name, iot_name, iot_type 2 FROM dba_tables; TABLE_NAME ----------------COUNTRY SYS_IOT_OVER_2268
IOT_NAME -------COUNTRY
IOT_TYPE -----------IOT IOT_OVERFLOW
Copyright © 2003, Oracle. All rights reserved.
Querying dba_indexes and dba_segments for IOT information SQL> SELECT index_name, index_type, 2 tablespace_name, table_name 2 FROM dba_indexes; INDEX_NAME INDEX_TYPE TABLESPACE --------------- ---------- ---------COUNTRY_C_ID_PK IOT - TOP INDX
TABLE_NAME ---------COUNTRY
SQL> SELECT segment_name, tablespace_name, 2 segment_type 3 FROM dba_segments; SEGMENT_NAME TABLESPACE_NAME SEGMENT_TYPE -----------------------------------------SYS_IOT_OVER_2268 USER TABLE COUNTRY_C_ID_PK INDX INDEX
Copyright © 2003, Oracle. All rights reserved.
Using a Mapping Table
SQL> 2 3 4 5 6 7 8 9 10
CREATE TABLE country ( country_id CHAR(2) CONSTRAINT country_id_nn NOT NULL , country_name VARCHAR2(40) , currency_name VARCHAR2(25) , currency_symbol VARCHAR2(3) , CONSTRAINT country_c_id_pk PRIMARY KEY (country_id)) ORGANIZATION INDEX MAPPING TABLE TABLESPACE users;
Copyright © 2003, Oracle. All rights reserved.
Maintaining a Mapping Table
• •
Collect statistics on a mapping table by analyzing the IOT. Query the dba_indexes view to determine the percentage accuracy of the mapping table. SQL> SELECT index_name, pct_direct_access 2 FROM dba_indexes 3 WHERE pct_direct_access IS NOT NULL;
• •
Rebuild the mapping table if required, using the ALTER TABLE command. Use the MINIMIZE RECORDS_PER_BLOCK clause of ALTER TABLE for the mapping table.
Copyright © 2003, Oracle. All rights reserved.
The ANALYZE Statement
Use the ANALYZE statement to: • VALIDATE STRUCTURE • LIST CHAINED ROWS • •
Collect statistics not used by the optimizer, such as information on free list blocks Sample a number (instead of a percentage) of rows SQL> ANALYZE TABLE hr.employees VALIDATE STRUCTURE;
Copyright © 2003, Oracle. All rights reserved.
Oracle Enterprise Manager: Collect Statistics
Copyright Š 2003, Oracle. All rights reserved.
OLTP Systems
• • • •
High-throughput, insert- and update-intensive Large, continuously growing data volume Concurrent access by many users Tuning goals: – – – –
Availability Speed Concurrency Recoverability
Copyright © 2003, Oracle. All rights reserved.
OLTP Requirements
• •
Explicit extent allocation Indexes: – Not too many (B-tree better than bitmap) – Reverse key for sequence columns – Rebuilt regularly
•
Clusters for tables in join queries: – Index clusters for growing tables – Hash clusters for stable tables
• •
Materialized views Index-organized tables
Copyright © 2003, Oracle. All rights reserved.
OLTP Application Issues
• • • •
Use declarative constraints instead of application code. Make sure that code is shared. Use bind variables rather than literals for optimally shared SQL. Use the CURSOR_SHARING parameter.
Copyright © 2003, Oracle. All rights reserved.
Decision Support Systems (Data Warehouses) • • •
Queries on large amounts of data Heavy use of full table scans Tuning goals: – Fast response time – Focus on SQL statement tuning
•
Data
The Parallel Query feature is designed for data warehouse environments
Copyright © 2003, Oracle. All rights reserved.
Data Warehouse Requirements
Storage allocation: • Set the block size and DB_FILE_MULTIBLOCK_READ_COUNT carefully. • •
Make sure that extent sizes are multiples of this parameter value. Run dbms_stats regularly.
Copyright © 2003, Oracle. All rights reserved.
Further Data Warehouse Requirements
•
Evaluate the need for indexes: – Use bitmap indexes when possible. – Use index-organized tables for (range) retrieval by primary keys. – Generate histograms for indexed columns that are not distributed uniformly.
•
Clustering: Consider hash clusters for performance access.
Copyright © 2003, Oracle. All rights reserved.
Data Warehouse Application Issues
• •
Parsing time is less important. The execution plan must be optimal: – – – –
•
Use the Parallel Query feature. Tune carefully, using hints if appropriate. Test on realistic amounts of data. Consider using PL/SQL functions to code logic into queries.
Bind variables are problematic.
Copyright © 2003, Oracle. All rights reserved.
Hybrid Systems OLTP
Data Warehouse
Performs index searches
More full table scans
Uses B-tree indexes
Uses bitmap indexes
Uses reverse key indexes
Uses index-organized tables
CURSOR_SHARING set to Similar can assist performance
CURSOR_SHARING should be left on Exact
Should not use Parallel Query
Employs Parallel Query for large operations
PCTFREE according to expected update activity
PCTFREE can be set to 0
Shared code and bind variables
Literal variables and hints
Uses ANALYZE indexes
Generates histograms
Copyright Š 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to do the following: • Explain the role of the DBA in tuning applications • Move tables using the ALTER TABLE command • • • •
Redefine a table online Create different types of indexes Build and manage index-organized tables Explain and plan OLTP, DSS, and hybrid systems
Copyright © 2003, Oracle. All rights reserved.
Using Materialized Views
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Create materialized views • Refresh materialized views • Create nested materialized views • Create UNION ALL materialized views • •
Explain the use of query rewrites Enable and control query rewrites
Copyright © 2003, Oracle. All rights reserved.
Materialized Views
• • •
Instantiations of a SQL query May be used for query rewrites Refresh types: – Complete or Fast – Force or Never
•
Refresh modes: – Manual – Automated (synchronous or asynchronous)
Copyright © 2003, Oracle. All rights reserved.
Creating Materialized Views
SQL> 2 3 4 5 6
CREATE MATERIALIZED VIEW depart_sal_sum AS SELECT d.department_name, SUM(e.salary) FROM hr.departments d, hr.employees e WHERE d.department_id = e.department_id GROUP BY d.department_name;
Copyright Š 2003, Oracle. All rights reserved.
Refreshing Materialized Views
The required parameters are: • A list of materialized views to refresh • The refresh method: F-Fast, ?-Force, C-Complete • Set push_deferred_rpc to True, if using updatable materialized views • Refresh after errors – True: Allows the process to continue after an error – False: Refresh will stop with errors (default value)
•
Atomic refresh – True: All refreshes are done in one transaction – False: Each refresh is a separate transaction SQL> EXEC dbms_mview.refresh ('SALES_MV', 2 'F', '', True, False, 0,0,0, False); Copyright © 2003, Oracle. All rights reserved.
Materialized Views: Manual Refreshing
•
Refresh specific materialized views: dbms_mview.refresh (’CUST_SALES’, parallelism => 10);
•
Refresh materialized views based on one or more base tables: dbms_mview.refresh_dependent (’SALES’);
•
Refresh all materialized views that are due to be refreshed: dbms_mview.refresh_all_mviews;
Copyright © 2003, Oracle. All rights reserved.
Nested Materialized Views
TOTAL_SALES
PROD_MV
PRODUCTS
Level 2
SALES_CUST_MV
CUSTOMERS
Level 1
SALES
Copyright Š 2003, Oracle. All rights reserved.
Level 0
Nested Materialized View Example
Copyright Š 2003, Oracle. All rights reserved.
Union All Materialized Views
Copyright Š 2003, Oracle. All rights reserved.
Query Rewrite Overview
• • • •
To use materialized views instead of the base tables, a query must be rewritten. Query rewrites are transparent and do not require any special privileges on the materialized view. Materialized views can be enabled or disabled for query rewrites. Query rewrites can: – Ignore alphabetic case – Recognize equivalent joins – Compare the defining text of a named view
Copyright © 2003, Oracle. All rights reserved.
Query Rewrites
• • •
The QUERY_REWRITE_ENABLED initialization parameter must be set to True. The QUERY REWRITE privilege allows users to enable materialized views. The Summary Advisor of the dbms_olap package has options to use materialized views.
Copyright © 2003, Oracle. All rights reserved.
Creating a Materialized View
SQL> CREATE MATERIALIZED VIEW sales_summary 2 TABLESPACE users 3 PARALLEL (DEGREE 4) 4 BUILD IMMEDIATE 5 ENABLE QUERY REWRITE 6 AS 7 SELECT p.prod_name, 8 SUM (s.quantity_sold), 8 SUM (s.amount_sold) 9 FROM sales s, products p 10 WHERE s.prod_id = p.prod_id 11 GROUP BY p.prod_name;
Copyright © 2003, Oracle. All rights reserved.
Materialized Views and Query Rewrites: Example SQL> 2 3 4 5
SELECT p.prod_name,SUM (s.quantity_sold), SUM (s.amount_sold) FROM sales s, products p WHERE s.prod_id = p.prod_id GROUP BY p.prod_name;
SQL> select operation, object_name 2 from v$sql_plan 3 where object_name like 'SALES%'; OPERATION NAME ---------------------- ----------------SELECT STATEMENT TABLE ACCESS SALES_SUMMARY Copyright Š 2003, Oracle. All rights reserved.
Enabling and Controlling Query Rewrites •
Initialization parameters: – OPTIMIZER_MODE – QUERY_REWRITE_ENABLED – QUERY_REWRITE_INTEGRITY
•
•
Dynamic and session-level parameters: – QUERY_REWRITE_ENABLED – QUERY_REWRITE_INTEGRITY Hints: REWRITE and NOREWRITE
•
Dimensions
Copyright © 2003, Oracle. All rights reserved.
Disabling Query Rewrites: Example
SQL> 2 3 4 5 6
SELECT /*+ NOREWRITE */ p.prod_name, SUM (s.quantity_sold), SUM (s.amount_sold) FROM sales s, products p WHERE s.prod_id = p.prod_id GROUP BY p.prod_name;
SQL> 2 3 4
SELECT p.operation, p.object_name FROM v$sql_plan p, v$sql s WHERE p.address = s.address AND sql_text LIKE 'SELECT /*+ NO%';
Copyright Š 2003, Oracle. All rights reserved.
Union All Query Rewrite CREATE MATERIALIZED VIEW sales_cube_mv ENABLE QUERY REWRITE AS SELECT ... GROUPING_ID(calendar_year,……) gid, GROUPING(calendar_year) grp_y, ... GROUPING(cust_city) grp_c, FROM sales s, times t, customers c WHERE s.time_id=t.time_id AND s.cust_id=c.cust_id GROUP BY GROUPING SETS( (calendar_year, cust_city), (calendar_year,..., cust_state_province), (calendar_year,..., cust_city));
Copyright © 2003, Oracle. All rights reserved.
Using the dbms_mview Package
The package contains the following procedures: • explain_mview • explain_rewrite • refresh • refresh_all_mviews
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to do the following: • Create materialized views • Refresh materialized views • Creating nested materialized views • Create UNION ALL materialized views • •
Explain the use of query rewrites Enable and control query rewrites
Copyright © 2003, Oracle. All rights reserved.
Monitoring and Detecting Lock Contention
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Define levels of locking • Identify causes of contention • Prevent locking problems • Use Oracle utilities to detect lock contention • Resolve contention in an emergency • Resolve deadlock conditions
Copyright © 2003, Oracle. All rights reserved.
Locking Mechanism
• •
Automatic management High level of data concurrency – Row-level locks for DML transactions – No locks required for queries
• • •
Multi-version consistency Exclusive and Share lock modes Locks held until commit or rollback operations are performed
Copyright © 2003, Oracle. All rights reserved.
Data Concurrency
Transaction 2
Transaction 1 SQL> UPDATE employees 2 SET salary=salary*1.1 3 WHERE id= 24877; 1 row updated.
SQL> UPDATE employees 2 SET salary=salary*1.1 3 WHERE id= 24878; 1 row updated.
SQL> UPDATE employees 2 SET salary=salary+1200; 13120 rows updated.
SQL> SELECT salary 2 FROM employees 3 WHERE id = 10; SALARY --------1000
Copyright Š 2003, Oracle. All rights reserved.
Two Types of Locks
•
DML or data locks: – Table-level locks – Row-level locks
•
(TM)
DDL or dictionary locks (TX)
Copyright © 2003, Oracle. All rights reserved.
DML Locks
A DML transaction gets at least two locks: • A shared table lock • An exclusive row lock
Copyright © 2003, Oracle. All rights reserved.
Enqueue Mechanism
The enqueue mechanism keeps track of: • Users waiting for locks • The requested lock mode • The order in which users requested the lock
Copyright © 2003, Oracle. All rights reserved.
Table Lock Modes
These table lock modes are automatically assigned by the Oracle server: • Row Exclusive (RX): INSERT, UPDATE, DELETE •
Row Share (RS): SELECT... FOR UPDATE
Copyright © 2003, Oracle. All rights reserved.
Manually Locking a Table
Manually acquired in LOCK TABLE statement: SQL> LOCK TABLE hr.employees IN share MODE;
•
Share (S) – No DML operations allowed – Implicitly used for referential integrity
Copyright © 2003, Oracle. All rights reserved.
Manually Locking a Table
•
Share Row Exclusive (SRX) – No DML operations or Share mode allowed – Implicitly used for referential integrity – No index is required on the foreign key column in the child table
•
Exclusive (X) – No DML or DDL operations allowed by other sessions – No manual locks allowed by other sessions – Queries are allowed
Copyright © 2003, Oracle. All rights reserved.
DML Locks in Blocks Block Header TX slot 1 TX slot 2
1
Row 6
Lock bytes
2
Row 1
Copyright Š 2003, Oracle. All rights reserved.
DDL Locks
•
Exclusive DDL locks are required for: – DROP TABLE statements – ALTER TABLE statements – (The lock is released when the DDL statement completes.)
•
Shared DDL locks are required for: – CREATE PROCEDURE statements – AUDIT statements – (The lock is released when the DDL parse completes.)
•
Breakable parse locks are used for invalidating statements in the shared SQL area. Copyright © 2003, Oracle. All rights reserved.
Possible Causes of Lock Contention
• • • •
Unnecessarily high locking levels Long-running transactions Uncommitted changes Other products imposing higher-level locks
Copyright © 2003, Oracle. All rights reserved.
Diagnostic Tools for Monitoring Locking Activity
Transaction 1
Transaction 2
Transaction 3
UPDATE employees SET salary = salary x 1.1; UPDATE employees SET salary = salary x 1.1 WHERE empno = 1000;
v$lock v$locked_object dba_waiters dba_blockers
UPDATE employees SET salary = salary x 1.1 WHERE empno = 2000;
Copyright Š 2003, Oracle. All rights reserved.
Guidelines for Resolving Contention Transaction 1
Transaction 2
UPDATE employees SET salary = salary x 1.1 WHERE empno = 1000;
9:00
9:05 10:30 >COMMIT/ROLLBACK;
>ALTER
UPDATE employees SET salary = salary x 1.1 WHERE empno = 1000;
11:30 1 row updated;
SYSTEM KILL SESSION ‘10,23’;
Copyright © 2003, Oracle. All rights reserved.
Performance Manager: Locks
Copyright Š 2003, Oracle. All rights reserved.
Deadlocks
Transaction
Transaction
1
2
UPDATE employees SET salary = salary x 1.1 WHERE empno = = 1000;
9:00
UPDATE employees SET manager = 1342 WHERE empno = 2000;
UPDATE employees SET salary = salary x 1.1 WHERE empno = 2000;
9:15
UPDATE employees SET manager = 1342 WHERE empno = 1000;
ORA-00060: Deadlock detected while waiting for resource
9:16
Copyright Š 2003, Oracle. All rights reserved.
Deadlocks
Server process
ORA-00060: Deadlock detected while waiting for resource
SID_ora_PID.trc UNIX
Trace file in USER_DUMP_DEST directory
Copyright Š 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned to do the following: • Define levels of locking • Identify causes of contention • Prevent locking problems • Use Oracle utilities to detect lock contention • Resolve contention in an emergency • Resolve deadlock conditions
Copyright © 2003, Oracle. All rights reserved.
Tuning the Operating System
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Describe different system architectures • Describe the primary steps of OS tuning • Identify similarities between OS and DB tuning • Understand virtual memory and paging • Explain the difference between a process and a thread
Copyright © 2003, Oracle. All rights reserved.
Operating System Tuning Memory SGA
Non-Oracle processes
Oracle processes OS
OS and DB files Copyright Š 2003, Oracle. All rights reserved.
System Architectures
The Oracle database can run on different system architectures. Some examples are: • Uni Processor systems • Symmetric multiprocessing systems (SMP) • Massively parallel processing systems (MPP) • Clustered systems • Nonuniform memory architecture systems (NUMA)
Copyright © 2003, Oracle. All rights reserved.
Virtual and Physical Memory
MMU
Virtual memory
Page table possibly with ISM Copyright Š 2003, Oracle. All rights reserved.
Physical memory
Paging and Swapping Memory
Process
Page
Swap device
Copyright Š 2003, Oracle. All rights reserved.
Tuning Memory
• • •
Database tuning can improve paging performance by locking SGA into real memory. The DBA should monitor real and virtual memory use. The DBA should use intimate shared memory, if it is available.
Copyright © 2003, Oracle. All rights reserved.
Tuning I/O Memory
CPU System bus
I/O controller
I/O controller
Copyright Š 2003, Oracle. All rights reserved.
I/O controller
Understanding Different I/O System Calls
Operating systems can perform disk I/O in two different ways: • Normal (blocking) I/O • Asynchronous (nonblocking) I/O is implemented on most platforms and file systems
Copyright © 2003, Oracle. All rights reserved.
CPU Tuning
•
Guidelines: – Maximum CPU busy rate: 90% – Maximum OS/User processing ratio: 40/60 – CPU load balanced across CPUs
•
Monitoring: – CPU – Process
Copyright © 2003, Oracle. All rights reserved.
Process versus Thread P r o c e s s e s T h r e a d s
Oracle processes S Q L P L U S
p m o n
a r c 0
SQL*PLUS process Thread
s m o n
d b w 0
l g w r
Oracle.exe process Threads
Copyright Š 2003, Oracle. All rights reserved.
c k p t
Summary
In this lesson, you should have learned how to: • Describe different system architectures • Describe the primary steps of OS tuning • Identify similarities between OS and DB tuning • Understand virtual memory and paging • Explain the difference between a process and a thread
Copyright © 2003, Oracle. All rights reserved.
Workshop Overview
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Follow the Oracle tuning methodology to diagnose and resolve performance problems • Improve your tuning skills • Use Oracle tools to diagnose performance problems
Copyright © 2003, Oracle. All rights reserved.
Approach to Workshop
The workshop is intended to provide: • A group-oriented and interactive experience • Intensive hands-on diagnosis and problem resolution • Proactive participant involvement
Copyright © 2003, Oracle. All rights reserved.
Workshop Background
The workshop is based on the XYZ Company, a fictional entity that has the following characteristics: • XYZ Company is new and still small: – Shares a database server with other companies – Currently has four employees who use the database
• • • •
System was set up by a part-time DBA trainee Database performance is unacceptable XYZ Company is seeking help from a consulting group Number of database users will be increasing
Copyright © 2003, Oracle. All rights reserved.
Workshop Outline
You are provided with scripts and tools to: • Configure your database with a tuning problem based on a selected scenario • Execute a simulated workload against your detuned database • Collect performance statistics for your database • Analyze your data and make changes to improve your database performance • Confirm that your changes have been beneficial by executing the same or a more intense workload simulation
Copyright © 2003, Oracle. All rights reserved.
Workshop Configuration
Workshop folder
Command window
Windows Explorer
SQL*Plus session in E:\Labs
Copyright Š 2003, Oracle. All rights reserved.
Workshop Setup: Overview
Step 1: Start the setup script Step 2: Respond to prompts Step 3: Verify configuration Step 4: Preserve your setup Step 5: Open the workshop window
Copyright Š 2003, Oracle. All rights reserved.
Workshop Setup: Step 1
Copyright Š 2003, Oracle. All rights reserved.
Workshop Setup: Step 2
… …
Copyright © 2003, Oracle. All rights reserved.
Workshop Setup: Step 3
Copyright Š 2003, Oracle. All rights reserved.
Workshop Setup: Step 3
Copyright Š 2003, Oracle. All rights reserved.
Workshop Setup: Step 4
Copyright Š 2003, Oracle. All rights reserved.
Workshop Setup: Step 5
Copyright Š 2003, Oracle. All rights reserved.
Steps to Run a Scenario 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Run the setup script for your selected scenario. Confirm that the Statspack job is running. Generate a workload for the current four users. Query tables to gather statistics interactively. Identify two snapshots and generate a Statspack report from them. Analyze your data and determine what problems to address. Make changes to improve performance. Repeat these steps (except step 1) until you achieve acceptable performance. Repeat steps 2 through 8 again, substituting the workload for the planned 20 users in step 2. Prepare your class presentation when you are satisfied with your work. Copyright Š 2003, Oracle. All rights reserved.
Run Scenario Setup Script
Scenario Description
Setup Icon
Shared pool performance
1.bat
Database buffer cache performance
2.bat
Redo log buffer performance
3.bat
Data access performance
4.bat
PGA performance
5.bat
Assorted performance areas
6.bat
Copyright Š 2003, Oracle. All rights reserved.
Check Statspack Job
SQL> CONNECT perfstat/perfstat
SQL> SHOW PARAMETER job_queue_processes
SQL> SELECT job, log_user, what, next_date, 2 next_sec, interval 3 FROM user_jobs;
Copyright Š 2003, Oracle. All rights reserved.
Check Statspack Job SQL> @E:\Labs\student\Wkshop\Setup\spauto PL/SQL procedure successfully completed. Job number for automated statistics collection for this instance ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . . . JOBNO ---------1 Job queue process ~~~~~~~~~~~~~~~~~ . . . NAME TYPE VALUE --------------------- ------------- ------------job_queue_processes integer 4 Next scheduled run ~~~~~~~~~~~~~~~~~~ . . . JOB NEXT_DATE NEXT_SEC ---------- --------------- ---------1 09-APR-03 23:00:00
Copyright Š 2003, Oracle. All rights reserved.
Generate a Workload
Simulates 4 users to test current load performance
Simulates 20 users to test future load performance
Copyright Š 2003, Oracle. All rights reserved.
Collect Statistics Interactively
Copyright Š 2003, Oracle. All rights reserved.
Identify Statspack Snapshots
Copyright Š 2003, Oracle. All rights reserved.
Create Statspack Report
Copyright Š 2003, Oracle. All rights reserved.
Analyze Statistics
Copyright Š 2003, Oracle. All rights reserved.
Apply Desired Changes
SQL> ALTER SYSTEM 2 SET db_cache_size = 25165824 3 SCOPE = BOTH; System altered. SQL> ALTER SYSTEM 2 SET log_buffer = 524288 3 SCOPE = SPFILE; System altered.
Copyright Š 2003, Oracle. All rights reserved.
Evaluate Impact of Changes
T
T Content?
Tried 20 users?
Repeat steps 2 through 6
Want to try 20 users?
Go to step 10
T
Go to step 10
Copyright Š 2003, Oracle. All rights reserved.
Go to step 9
Test Performance with More Users
Copyright Š 2003, Oracle. All rights reserved.
Summarize Findings
• • • • •
What changes you made Why you made those changes How your changes impacted performance What else you might have investigated How you could improve your methodology
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Implement the Oracle tuning methodology • Drill down the performance problems suggested by Statspack reports • Tune a database to support current and anticipated work loads • Justify the changes that are made to a database configuration for tuning purposes
Copyright © 2003, Oracle. All rights reserved.
Tuning Undo Segments
Copyright Š 2003, Oracle. All rights reserved.
Objectives
After completing this lesson, you should be able to do the following: • Describe the concept of automatic undo management • Create and maintain the automatic managed undo tablespace • Set the retention period • Use dynamic performance views to check rollback segment performance • Reconfigure and monitor rollback segments • Define the number and sizes of rollback segments • Allocate rollback segments to transactions Copyright © 2003, Oracle. All rights reserved.
Undo Segments: Usage
Transaction rollback
Read consistency Undo (Rollback) segment
Control files Transaction recovery Data files Copyright Š 2003, Oracle. All rights reserved.
Redo log files
Using Less Undo Space Per Transaction
• •
The design of the application should allow users to commit transactions regularly. Developers should not code long transactions.
Copyright © 2003, Oracle. All rights reserved.
Using Less Undo Space
•
Import – Set COMMIT = Y – Size the set of rows with the BUFFER keyword
•
Export: Set CONSISTENT = N
•
SQL*Loader operations: Set the commit intervals with ROWS
•
Developers should make sure that the transactions are not unduly long
Copyright © 2003, Oracle. All rights reserved.
Automatic Undo Management
• •
•
The automatic undo management feature simplifies the management of undo segments. Set the UNDO_MANAGEMENT parameter to: – AUTO for automatic undo management – MANUAL for managing rollback segments manually The UNDO_RETENTION parameter specifies the time (in seconds) to retain undo information.
Copyright © 2003, Oracle. All rights reserved.
Automatic Undo Management Tablespaces
•
Create a tablespace for automatic undo management in one of the following ways: – Using the UNDO TABLESPACE clause in the CREATE DATABASE command – Using the CREATE UNDO TABLESPACE command
•
MINIMUM EXTENT and DEFAULT STORAGE are
•
system generated for undo tablespaces. Restrictions: – Database objects cannot be created in this tablespace. – You can specify the data file and the extent_management clause only. Copyright © 2003, Oracle. All rights reserved.
Altering an Undo Tablespace
• •
The ALTER TABLESPACE command can be used to make changes to undo tablespaces. The following example adds another data file to the undo tablespace: ALTER TABLESPACE undotbs1 ADD DATAFILE ‘/u02/oradata/testdb/undotbs1_02.dbf’ AUTOEXTEND ON;
•
You cannot take an undo tablespace offline that has an active undo segment.
Copyright © 2003, Oracle. All rights reserved.
Switching Undo Tablespaces
• • •
A DBA can switch from using one undo tablespace to another. Only one undo tablespace per instance can be assigned as active. Switching is performed by using the ALTER SYSTEM command: ALTER SYSTEM SET UNDO_TABLESPACE=undotbs2;
Copyright © 2003, Oracle. All rights reserved.
Dropping an Undo Tablespace
The DROP TABLESPACE command can be used to drop an undo tablespace: DROP TABLESPACE undotbs_2;
•
An undo tablespace can be dropped only if: – It is not the active undo tablespace – It is not utilized by an active transaction
•
Queries that require a read-consistent image of undo data that is stored in an dropped undo tablespace will return an error.
Copyright © 2003, Oracle. All rights reserved.
Setting UNDO_RETENTION
UNDO_RETENTION parameter: • • •
Is specified in time (seconds) A target value. If space is required, then committed data will be overwritten. Controls the amount of undo data that is to be retained after committing
Copyright © 2003, Oracle. All rights reserved.
Other Parameters for Automatic Undo Management • • •
UNDO_MANAGEMENT: Specifies whether the database uses Auto or Manual mode UNDO_TABLESPACE: Specifies a particular undo tablespace to be used UNDO_SUPPRESS_ERRORS: Set to True, this parameter suppresses errors while attempting to execute manual operations, such as ALTER ROLLBACK SEGMENT ONLINE, while in Auto mode
Copyright © 2003, Oracle. All rights reserved.
Monitoring Automatic Undo Management
•
Use v$undostat view to monitor undo segments.
•
This view is available for both Manual and Auto mode. The undoblks column displays the number of undo blocks allocated.
•
Copyright © 2003, Oracle. All rights reserved.
Using v$undostat
SQL> SELECT begin_time, end_time, undoblks, 2 txncount, maxquerylen 3 FROM v$undostat; BEGIN_TIME --------------25-oct-01:06:04 25-oct-01:05:44 25-oct-01:05:34 25-oct-01:05:24 25-oct-01:05:14 ……
END_TIME UNDOBLKS TXNCOUNT --------------- -------- -------25-oct-01:06:14 234 12 25-oct-01:05:54 587 21 25-oct-01:05:44 1,187 45 25-oct-01:05:34 346 15 25-oct-01:05:24 642 23
Copyright © 2003, Oracle. All rights reserved.
Performance Manager: Rollback/Undo
Copyright Š 2003, Oracle. All rights reserved.
Overview
Setting manual rollback segments is: • Optional in the Oracle database • Time consuming for the DBA
Copyright © 2003, Oracle. All rights reserved.
Rollback Segment Activity T1 >update >update >insert >insert >update
1
2 T1 T2
T2 >update >update >insert >insert >update
T4 4
Inactive extent Copyright Š 2003, Oracle. All rights reserved.
T3 3
Active extent
Rollback Segment Header Activity
• •
Rollback segment headers contain entries for their respective transactions. Every transaction must have update access. T1 T2
1 2
T3 T4 T5
4
T6
Copyright © 2003, Oracle. All rights reserved.
3
Growth of Rollback Segments
1
4
2
1
2
5
3
3 4
Active extent
New extent
Inactive extent
Copyright Š 2003, Oracle. All rights reserved.
Tuning Manually Managed Rollback Segments Goals in tuning rollback segments: • Transactions should never wait for access to rollback segments. • Rollback segments should not extend during normal running. • Users and utilities should try to use less rollback per transaction. • No transaction should ever run out of rollback space. • Readers should always see the read-consistent images they need.
Copyright © 2003, Oracle. All rights reserved.
Diagnostic Tools
v$system_event v$waitstat
Statspack output 1
T3 T4 T5
2
v$rollstat v$rollname
Header
v$sysstat
v$transaction v$session
4
3
Copyright Š 2003, Oracle. All rights reserved.
Data SGA
Diagnosing Contention for Manual Rollback Segment Header If the number of waits for any rollback header is greater than 1% of the total number of requests, then create more rollback segments. SQL> 2 or SQL> 2 3 or SQL> 2 3
SELECT class, count FROM v$waitstat WHERE class LIKE '%undo%'; SELECT event, total_waits, total_timeouts FROM v$system_event WHERE event LIKE 'undo segment tx slot'; SELECT sum(waits)* 100 /sum(gets) "Ratio", sum(waits) "Waits", sum(gets) "Gets" FROM v$rollstat;
Copyright Š 2003, Oracle. All rights reserved.
Guidelines: Number of Manual Rollback Segments (RBSs) • •
OLTP: One RBS for four transactions Batch: One rollback segment for each concurrent job SQL> SET TRANSACTION USE 2 ROLLBACK SEGMENT large_rbs;
Large rollback Small RBS Small RBS
Small RBS Small RBS
Small RBS Copyright © 2003, Oracle. All rights reserved.
Guidelines: Sizing Manual Rollback Segments Probability of extending 0.50 0.40 0.30 0.20 0.10 0.00 0
Rollback segment 1 = Rollback segment 2 INITIAL = NEXT = 2n Mb MINEXTENTS = 20 OPTIMAL = 20 * INITIAL Copyright Š 2003, Oracle. All rights reserved.
10
20
30
Number of extents
40
Sizing Transaction Rollback Data
• • • •
Deletes are expensive for rollback activity. Inserts use minimal rollback space. Updates use rollback space, depending on the amount of data changed in the transaction. Index maintenance adds rollback. SQL> SELECT s.username, t.used_ublk, 2 t.start_time 3 FROM v$transaction t, v$session s 4 WHERE t.addr = s.taddr;
Copyright © 2003, Oracle. All rights reserved.
Sizing Transaction Rollback Data
•
The number of bytes in rollback segments before execution of statements: SQL> SELECT usn,writes 2 FROM v$rollstat;
•
After execution of statements: SQL> SELECT usn,writes 2 FROM v$rollstat;
Copyright © 2003, Oracle. All rights reserved.
Possible Problems Caused by Small Rollback Segments • •
The transaction fails for lack of rollback space. A “snapshot too old” error occurs if the statement requires data that has been modified, committed, and the rollback data is no longer available.
Copyright © 2003, Oracle. All rights reserved.
Summary
In this lesson, you should have learned how to: • Describe the concept of automatic undo management • Create and maintain the automatic managed undo tablespace • Set the retention period • Use dynamic performance views to check rollback segment performance • Reconfigure and monitor rollback segments • Define the number and sizes of rollback segments • Allocate rollback segments to transactions
Copyright © 2003, Oracle. All rights reserved.