Banner Oracle Performance Tuning Training Workbook

Transcription

1 Banner Oracle Performance Tuning Training Workbook January 2005 Using Oracle 9i for Banner 6 HIGHER EDUCATION What can we help you achieve?

2 Confidential Business Information This documentation is proprietary information of SunGard Higher Education and is not to be copied, reproduced, lent or disposed of, nor used for any purpose other than that for which it is specifically provided without the written permission of SunGard Higher Education. Prepared By: SunGard Higher Education 4 Country View Road Malvern, Pennsylvania United States of America SunGard. All rights reserved. The unauthorized possession, use, reproduction, distribution, display or disclosure of this material or the information contained herein is prohibited. In preparing and providing this publication, SunGard Higher Education is not rendering legal, accounting, or other similar professional services. SunGard Higher Education makes no claims that an institution's use of this publication or the software for which it is provided will insure compliance with applicable federal or state laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services from competent providers of the organization s own choosing. Without limitation, SunGard, the SunGard logo, Banner, Campus Pipeline, Luminis, PowerCAMPUS, Matrix, and Plus are trademarks or registered trademarks of SunGard Data Systems Inc. or its subsidiaries in the U.S. and other countries. Third-party names and marks referenced herein are trademarks or registered trademarks of their respective owners.

3 Table of Contents Section A: Performance Tuning Course Overview...5 Overview...5 Course Description...6 Section B: Introduction...7 Overview...7 What is Performance Tuning?...8 Section C: System Configuration...11 Overview...11 System and Database Configuration...12 Checks For All Operating Systems...13 Dynamic Views: Pertaining to Instance/Database...14 Dynamic Views: Pertaining to Disk Performance...16 Individual Statements For Evaluation...18 Evaluating System Load...19 Section D: Application Performance Tuning...20 Overview...20 Banner 6 to Banner Oracle Optimization...22 Oracle Statistics...23 SQL Trace and Explain Plan...24 Analyze Tables and Indexes...26 High Water Mark...27 Plan Stability and Stored Outlines...28 Exercise...29 Oracle Hints...30 Section E: Stats Pack Tuning Tool...32 Overview...32 Installing and Configuring Stats Pack Package...33 Gathering a Statspack Snapshot...34 Creating a Statspack Performance Report...35 Removing Statspack...36 Section F: Library Cache and Shared Pool Tuning...37 Overview...37 Memory Fragmentation...38 Diagnosing Fragmentation...39 Pinning Packages in Memory...40 Shared Pool Calculation...42

4 Table of Contents (Continued) Section G: Tuning Oracle Sorts...43 Overview...43 Introduction...44 Disk Sorts...45 Sizing PGA_AGGREGATE_TARGET...46 Sorts and the Temporary Tablespace...47 Tuning PGA_AGGREGATE_TARGET...48 Section H: Latches, Locks and Contention...51 Overview...51 How Oracle Handles Locking...52 Lock Modes Required for Table Actions...53 Diagnosing Locking Problems...54 How to Resolve Locking Situations...55 Dynamic Views to Detect Locking Problems...56 Common Buffer Classes...57 Waits...58 Memory...62 Sessions...66 Unusual Locking Problems...70 Section I: Tuning Rollback Segments, Undos and Redo Logs...71 Overview...71 Tuning Rollback Segments...72 Tuning Undo Segments...77 Tuning Redo Logs...81 Section J: Instance Recovery Tuning...83 Overview...83 Fast Start Parameters in initialization file...84 V$INSTANCE_RECOVERY...85 Calculating Recovery Performance Overhead...87

5 Section A: Performance Tuning Course Overview Overview Workbook goal This course is designed to illustrate performance evaluation methods and tuning options that will assistance the IT staff in the evaluating and monitoring their database system. It will address the mechanisms that are used for evaluating and tuning the Oracle s SQL engine that manages the processing of tasks in the Relational Database Management System (RDBMS). It will also explore a variety of tools that can used to assist in these tasks to tune and monitor the RDBMS and underlying system. The mechanisms discussed are based on the Oracle 8i and 9i RDBMS. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Section contents Course Description 6 Page 5

6 Section A: Performance Tuning Course Overview Course Description Course description This course is designed to illustrate performance evaluation methods and tuning options that will assistance the IT staff in the evaluating and monitoring their database system. It will address the mechanisms that are used for evaluating and tuning the Oracle s SQL engine that manages the processing of tasks in the Relational Database Management System (RDBMS). It will also explore a variety of tools that can used to assist in these tasks to tune and monitor the RDBMS and underlying system. The mechanisms discussed are based on the Oracle 8i and 9i RDBMS. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Objectives Upon completion of this course, attendees will be able to evaluate the demand of a average system to plan for peak demands be able to use tool such as Oracle Hints, EXPLAIN PLAN, SQL_TRACE, ANALYZE and Outlines to tune and drive the optimization of SQL statements be familiar with the various dynamic views and the statistics that are provided to evaluate various performance issues that need to be evaluated on any production system. utilize the multiple managers of the Enterprise Manager console to monitor any Oracle database. be familiar with contention management and the tools to proactively resolve them. Page 6

7 Section B: Introduction Overview Introduction This section will provide an overview of the course material, explain some terminology, and address some common issues. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents What is Performance Tuning?...8 Page 7

8 Section B: Introduction What is Performance Tuning? What is Performance Tuning? Performance tuning encompases the trade-offs between response time and throughput, it must evaluate the demands made on the various systems and determine the effect on overall performance. This requires an understanding of the critical resources available to the user community and demands a proactive stance in allocating those resources. Since there is always the possibility of unexpected or emergency situations it is important to have a plan in place that determines the path taken when a critical system has issues. Finally, adjustments to the current system needs to be planned and executed with the least impact on the end users. Trade-offs It should be noted that the Banner system is a hybrid, neither strictly OLTP nor a batch processing system, but a mixture of both. Typically the production system will experience heavy on-line transactions throught the day but is often flooded with DSS requests from management. In addition batch processes are often submitted after normal working hours to perform massive updates. Response Time Response time is the sum of the elapsed time it takes to receive and process a request. The goal of course is to increase performance by reducing both service time and response time. Sequential Processing Involves a set of independent tasks competing for a single resource. Page 8

9 Section B: Introduction What is Performance Tuning? (Continued) System Throughput Equals the amount of work accomplished in a given amount of time. Throughput can be increased by discovering ways to either reduce service time or reduce overall response time. Wait Time and Demand Refers to users or processes waiting for services to become available. The longer a request has to wait, and the increase of requests waiting on a particular service, the higher the contention for that service. Possible solutions include: Limit the demand Add resources, CPU, disk, memory Page 9

10 Section B: Introduction What is Performance Tuning? (Continued) Critical Resources and Roles Performance depends on resources available, the number of users or clients needing a specific resource, how long the wait for the resource and how long they hold the resource. Many individuals have a role in tuning, including: the business executive; the applications designer; the applications developer; and the database, system and network administrators. Priority and Order of Tuning The first priority is to have developed well-tuned applications. It is critical to be proactive in the design and development portion of your application development. This requires an understanding of business rules, applications design, database normalization and the use of referential integrity. During the implementation and production phases a reactive stance is often necessary. First, tune the application Second, tune the memory by storig as much in memory as possible Then tune the I/O Optimize the instance performance Page 10

11 Section C: System Configuration Overview Introduction This section will address the overall configuration of the Banner Oracle system. Planning, implementing and monitoring typically precede database tuning. Performance issues are often found to be a result of a less than optimal system design or the result of system and application evolution. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents System and Database Configuration...12 Checks For All Operating Systems...13 Dynamic Views: Pertaining to Instance/Database...14 Dynamic Views: Pertaining to Disk Performance...16 Individual Statements For Evaluation...18 Evaluating System Load...19 Page 11

12 Section C: System Configuration System and Database Configuration Overview Sungard Higher Education s Banner and Oracle Installation Service provides clients with highly experienced and trained professionals to provide an initial Banner environment that is functional, stable, and current. Install Standards and Best Practices are guides used during the initial installation of the Oracle and Banner system. The configuration of the Oracle and Banner environments should be examined using the following set of Notes and FAQs available on the Sungard Higher Education Action Web. It is important to follow OFA guides in your naming conventions. Open VMS For OpenVMS System tuning recommendations see Doc ID: Note: and VMS System Tuning Recommendations for New 8i/9i RDBMS Installations. UNIX Also see FAQ #2450 Creating a Database in a UNIX environment. NT view/systemrequirements/ LINUX Sungard Higher Education has announced full support of Banner 6.x under RedHat Linux. All aspects of Banner, including the database, application servers, web server, C and Cobol processes can now be run in a Linux environment. Red Hat Advanced Server 2.x and 3.0 are supported. Page 12

13 Section C: System Configuration Checks For All Operating Systems Checks Certain checks are recommended for all operating system. There are also a number of FAQ documents on the Sungard Higher Education web site that will provide information on appropriate configuration and system settings. For space requirements, please consult the installation guide for the appropriate platform Check the OS release and patches applied. Verify the certification with Oracle Support. FAQ Oracle 9i Release Information. FAQ 2554 OS / Oracle RDBMS versions FAQ #3603 Oracle Forms Versions FAQ #5392 INB Solaris Web Forms Server FAQ FAQs and on Action Web for implementation Page 13

14 Section C: System Configuration Dynamic Views: Pertaining to Instance/Database V$PX_ PROCESS_ SYSSTAT The V$PX_PROCESS_SYSSTAT view shows the status of query servers and provides buffer allocation statistics. V$PROCESS To monitor the Program Global Area (PGA) memory usage of the Oracle server processes, Query the V$PROCESS view using the following query: Page 14

15 Section C: System Configuration Dynamic Views: Pertaining to Instance/Database (Continued) V$PROCESS The V$PROCESS view is useful in the following situations: Bottleneck on the database server If the bottleneck on the database server is related to an operating system resource such as CPU or memory, the processes typically using most of the resources are the server processes. In such a case, the V$PROCESS view can be used to find the resource intensive processes and relate the processes to their sessions. Locating trace files for a session The SQL*Trace file names are based on the operating system process ID of the server process. To locate the trace file for a session, you can relate the session to the server process using the V$PROCESS view. Information about a process Some events, such as rdbms ipc reply, identify the Oracle process ID of the process on which a session is waiting. To learn what those processes are doing, you can find their sessions by using the V$PROCESS view. Background processes The background processes you see on the server (DBWR, LGWR, PMON, and so on) are all server processes. To learn what these processes are doing in the database, you can find their sessions by using the V$PROCESS view. Page 15

16 Section C: System Configuration Dynamic Views: Pertaining to Disk Performance V$FILESTAT: Example For disk contention, check datafile I/O using the V$FILESTAT dynamic performance view. Use the following query to monitor the number of physical reads and writes, and the total I/O time taken for these reads and writes. Observation The numbers in the output reflect I/O activity since the instance startup. Take another snapshot and calculate the difference in the statistics to obtain the I/O activity for the time interval Page 16

17 Section C: System Configuration Dynamic Views: Pertaining to Disk Performance (Continued) V$tempstat: Temporary Data Files Tempfiles were introduced in Release 8.1. Locally managed temporary tablespaces have temporary data files, or tempfiles. They are similar to ordinary data files, except as follows: Tempfiles are always set to NOLOGGING mode. You cannot make a tempfile read-only. You cannot rename a tempfile. You cannot create a tempfile with the ALTER DATABASE statement. When you create or resize tempfiles, allocation of disk space for the file size specified is not always guaranteed. On certain file systems, such as UNIX, disk blocks are not allocated at file creation or resizing, but before the blocks are accessed. Note: This enables fast tempfile creation and resizing. However, the disk could run out of space later when the tempfiles are accessed. Tempfile information is shown in the DBA_TEMP_FILES dictionary view and the V$TEMPFILE dynamic performance view, but not in the DBA_DATA_FILES or V$DATAFILE views. Page 17

18 Section C: System Configuration Individual Statements For Evaluation CPU Utilization: Parse calls SELECT ADDRESS, HASH_VALUE, BUFFER_GETS, EXECUTIONS, BUFFER GETS/EXECUTIONS "GETS/EXEC", SQL_TEXT FROM V$SQLAREA WHERE BUFFER_GETS > AND EXECUTIONS > 0 ORDER BY 3; Non-dynamic parameters select name from v$parameter where issys_modifiable='false' Page 18

19 Section C: System Configuration Evaluating System Load System load states Determining idle, average and peak loads Step Action 1 Choose a time window that will service so many transactions to calculate transactions/minute 2 Transactions = Minutes = TPM = 3 Determine the CPU value that must be available for the server to function (ex. 15%) 4 Using the following formulate, you could determine any one of the values if the others are known: Average TPM/ Peak TPM * Peak Oracle CPU VALUE = cpu utilization at average usage Page 19

20 Section D: Application Performance Tuning Overview Introduction This section is provided to assist developers and DBAs in tuning their own applications. There is no need to tune the Banner applications; any issues that point to a possible tuning problem in the Banner code should be reported to the Action Line. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents Banner 6 to Banner Oracle Optimization...22 Oracle Statistics...23 SQL Trace and Explain Plan...24 Analyze Tables and Indexes...26 High Water Mark...27 Plan Stability and Stored Outlines...28 Exercise...29 Oracle Hints...30 Page 20

21 Section D: Application Performance Tuning Banner 6 to Banner 7 Banner 6 to Banner 7 There will be a significant change in the move from Banner 6 to Banner 7, as Banner will be moving to Oracle s Cost Based Optimizer. Up to and including version 6 of Banner, the Rule Based Optimizer has been used. For additional information: Log into the Action Web from the Sungard Higher Education web site, Click the "Extended Search" link, Click on the "Banner 7.0 Information Center" link, Then click on the "Banner 7.0 General Information" link Page 21

22 Section D: Application Performance Tuning Oracle Optimization Optimizer types Whenever a query is parsed a series of steps is followed to determine whether the rule-based or cost-based optimizer should be used. If there is a question as to which optimizer is being used prior to version 7 of Banner, you may refer to Doc ID Note: on Sungard Higher Education s Action Web for "Which Optimizer is Being Used." Note that these features do not have to be used at the execution stage to force the CBO. The presence of these features at the evaluation stage is enough. Requiring Cost-based Optimizer In addition, there is a list of features that require the use of the cost-based Optimizer in the following manuals: Oracle8i Release Designing and Tuning for Performance Manual Page 4-19 Part Number A Oracle9i Database Performance Guide and Reference Page 1-14 Part Number A Page 22

23 Section D: Application Performance Tuning Oracle Statistics Forcing rule-based optimizer usage There have been sporadic instances with Oracle databases since the cost-based optimizer was introduced that cause it to choose the CBO even when the optimizer mode is explicitly set to rule. If you are encountering this behavior, then removing the statistics once you have processed them should make Oracle choose the rule-based optimizer in all cases. Checking for parallel specification If this doesn't work, the other possibility is that you have specified the parallel option for some of your tables and indexes; this may also cause CBO to be chosen. Run the following queries to see if this is the case: select owner,table_name,degree from dba_tables where degree > 1; select owner,index_name,degree from dba_indexes where degree > 1; If you find a table or index with these queries, you can modify them as in the following example: alter table foo noparallel; Statistics in the database Also, be sure that you don't have any statistics in the database either. You can check that with: select owner,table_name from dba_tables where last_analyzed is not null; select owner,index_name from dba_indexes where last_analyzed is not null; If you do have statistics, you can remove them with the ANALYZE TABLE (or INDEX)... DELETE STATISTICS statement. Page 23

24 Section D: Application Performance Tuning SQL Trace and Explain Plan SQL Trace and Explain Plan SQL*Trace is a facility to view the performance statistics and execution plan of the Oracle optimizer in SQL. The Oracle userid must have 'ALTER SESSION' privileges to run in trace mode. If BANNER Role Security is enabled, this privilege may need to be granted to the ban_default_m or ban_default_connect role. The most useful statistical performance result from the output of the 'tkprof' (explained later in this document) is the EXECPU value. This is the cpu time spent fetching. This value is only available if the initialization parameter, TIMED_STATISTICS, is set to TRUE or the SQL statement is issued, ALTER SYSTEM SET TIMED_STATISTICS=TRUE Enabling SQL*Trace To turn on SQL*Trace for a sqlplus session: ALTER SESSION SET SQL_TRACE TRUE; To turn on trace for the entire database, add the following init.ora parameter and restart the database: To enable SQL_TRACE in Banner with Forms6i: o Launch Oracle Forms Builder. o Load the GUAINIT.fmb form. o Place the following line of code in the When-New-Form-Instance Trigger after the 'Begin' statement in the GUAINIT.fmb form: FORMS_DDL('ALTER SESSION SET SQL_TRACE=TRUE'); Remember to 'Connect' to the database as baninst1 before compiling the trigger after the modification. To turn on SQL*Trace for a Unix C program execution: program_name -t userid/password To turn on SQL*Trace for a VMS C program execution: RUNPROC program_name -t userid/password To turn on SQL*Trace for specific Banner processes, see FAQ 1365 SQL Trace and Explain Plan. Page 24

25 Section D: Application Performance Tuning SQL Trace and Explain Plan (Continued) Enabling SQL*Trace (cont.) The SQL*Trace file will be created with a.trc extension in the Initialization file parameter USER_DUMP_DEST setting. The trace file is created with a name of the process id number. Tkprof utility The Oracle utility 'tkprof' is used to analyze the trace file. For example: tkprof yourfile.trc yourfile.out EXPLAIN=userid/password If an extension is not specified for 'yourfile.out', the default extension is '.prf'. EXPLAIN is an option to the 'tkprof' command, which will write information to the output file pertaining to the path used (indexes, table scans) when the SQL statement was executed. The userid is a user which has access to the SQL*Trace PLAN_TABLE database object. The table may be created in Unix by running the script SQL connect userid/password SQL $ORACLE_HOME/rdbms/admin/utlxplan.sql For VMS, the script resides in ORA_ROOT:[RDBMS] Page 25

26 Section D: Application Performance Tuning Analyze Tables and Indexes Analyze Tables and Indexes Although the Optimizer_Mode is set to Rule as required for Banner, Oracle's optimizer may use statistics if an object has been analyzed. For information on 'analyze', execute 'help analyze' in SQL*Plus. To verify if statistics exist on a table or index, select table_name from dba_tables where LAST_ANALYZED IS NOT NULL; select index_name from dba_indexes where LAST_ANALYZED IS NOT NULL; To remove statistics, SQL> analyze table table_name delete statistics; SQL> analyze index index_name delete statistics; Page 26

27 Section D: Application Performance Tuning High Water Mark High water mark The high water mark in a table or index points to the block immediately following the last block on the free list. It is incremented with an insert It does not decrease with a delete from the table, only when the truncate or drop commands are used Space may be reclaimed from above the high water mark only The unused_space procedure within the DBMS_SPACE package For Locally Managed Tablespaces, use the SPACE_USAGE package SQL> alter table xyz deal locate unused keep 80k Page 27

28 Section D: Application Performance Tuning Plan Stability and Stored Outlines Plan Stability Implementing plan stability creates a new schema called OUTLN, which is created with DBA privileges. The database administrator should change the password for the OUTLN schema just as for the SYS and SYSTEM schemas. After carefully tuning an application, you might want to ensure that the optimizer generates the same execution plan whenever the same SQL statements are executed. Plan stability allows you to maintain the same execution plans for the same SQL statements, regardless of changes to the database such as re-analyzing tables, adding or deleting data, modifying a table's columns, constraints, or indexes, changing the system configuration, or even upgrading to a new version of the optimizer. OUTLN user The OUTLN user is created automatically during installation of Oracle8i. This user is granted connect, resource, and execute any procedure privileges. Oracle8i adds the OUTLN user schema to support Plan Stability. The OUTLN user acts as a place to centrally manage metadata associated with stored outlines. You cannot create this user on the fly. The user OUTLN owns the package OUTLN_PKG, which is used to manage stored outlines and their outline categories. Stored Outlines In Oracle9i, you can edit optimizer stored outlines either with the Outline Editor in Enterprise Manager or manually by querying the local OL$HINTS tables and performing DML against the appropriate hint. Page 28

29 Section D: Application Performance Tuning Exercise Exercise Outlines can be used to move from Rule-Based to Cost-Based Optimization without affecting the entire system. This exercise uses the SCOTT/TIGER tables and schema. Step Action 1 SQL> grant CREATE ANY OUTLINE to username; 2 SQL> connect SCOTT/TIGER 3 SQL> CREATE OUTLINE salaries FOR CATEGORY special ON SELECT ename, sal FROM emp; 4 SQL> Connect OUTLN/OUTLN 5 SQL> select ol_name, category, sql_text from ol$ where ol_name = SALARIES ; 6 Use the stored outline. First set USE_STORED_OUTLINES = SPECIAL at the session level. 7 SQL> connect SCOTT/TIGER 8 SQL> alter session set USE_STORED_OUTLINES = SPECIAL; 9 SQL> SELECT ename, sal FROM emp; 10 Verify that the outline was used SQL> select USED from USER_OUTLINES; 11 Or connect to the database user SYSTEM or OUTLN. Sqlplus outln/outln 12 SQL> select outline_category, sql_text from v$sql where outline_category is not NULL; Page 29

30 Section D: Application Performance Tuning Oracle Hints Oracle Hints Hints are suggestions that you give the optimizer for optimizing a SQL statement. Hints allow you to make decisions usually made by the optimizer. You can use hints to specify: the optimization approach for a SQL statement the goal of the cost-based approach for a SQL statement the access path for a table accessed by the statement the join order for a join statement a join operation in a join statement To determine if a HINT is being used, you can run a SQL trace to see the SQL statement that your Forms application is sending to the Oracle Server. See the related GSX entry "USING SQL TRACING" for more information on using SQL Trace within Oracle Tools. If you specify hints incorrectly, the Oracle Server IGNORES them but does not return an error. Page 30

31 Section D: Application Performance Tuning Oracle Hints (Continued) Oracle Hints (cont.) Oracle ignores hints in all SQL statements in environments that use PL/SQL Version 1.X. Developer/2000 Release 2.X and above will use PL/SQL V2.X, which will avoid this limitation within Oracle tools like Forms. Oracle ignores hints if the comment containing them does not follow a DELETE, SELECT, or UPDATE keyword. Hints apply only to the optimization of the statement block in which they appear. A statement block is any one of the following statements or parts of statements: a simple SELECT, UPDATE, or DELETE statement a parent statement or subquery of a complex statement a part of a compound query A compound query consisting of two component queries combined by the UNION operator has two statement blocks, one for each component query. For this reason, hints in this first component query apply only to its optimization, not to the optimization of the second component query. Oracle ignores hints containing syntax errors, but considers other correctly specified hints within the same comment. Oracle ignores combinations of conflicting hints, but considers other hints within the same comment. The optimizer only recognizes hints when using the cost-based approach. If you include any hint (except the RULE hint) in a statement block, the optimizer automatically uses the cost-based approach. The ALTER SESSION OPTIMIZER_GOAL statement does not affect SQL that is run from PL/SQL (like Forms). The optimizer goal only applies to queries submitted directly. Hints are used to determine the access path for SQL statements submitted from within PL/SQL. Page 31

32 Section E: Stats Pack Tuning Tool Overview Introduction Stats Pack was created in response to a need for more relevant and more extensive statistical reporting beyond what was available via UTLBSTAT/ UTLESTAT reports. Further, this information can be stored permanently in the database instance itself so that historical data is always available for comparison and diagnosis. Stats Pack has been available since version 816, but can be installed on 806 and above. Snapshots created using older versions of stats pack can usually be read using newer versions of Stats pack although the newer features will not be available. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents Installing and Configuring Stats Pack Package...33 Gathering a Statspack Snapshot...34 Creating a Statspack Performance Report...35 Removing Statspack...36 Page 32

33 Section E: Stats Pack Tuning Tool Installing and Configuring Stats Pack Package Notes Allow at least 100M of space for the PERFSTAT schema s objects. Do not both use STATSPACK and UTL*STAT. They both use STATS$WAITSTAT. Step Action 1 Connect internal to the database, SQLPLUS "as/ sysdba" 2 Run the script to create the STATSPACK schema and objects. This script calls three other scripts: spcusr.sql (creates the user) spctab.sql (creates the underlying tables) spcpkg.sql (creates packages) 3 You will be prompted for a default and temporary tablespace for the PERFSTAT user. 4 The default password is PERFSTAT. It can be changed. 5 Collections will be uniquely identified by SNAP_ID in STATS$WAITSTAT (similar to v$waitstat) 6 TIMED_STATISTICS must be set to TRUE to run STATSPACK. Page 33

34 Section E: Stats Pack Tuning Tool Gathering a Statspack Snapshot Generate a snapshot To generate a snap shot of the current system statistics, log into SQLPLUS as user PERFSTAT and execute: SQL> Execute statspack.snap; The default level of statistics is level 5. To change the level, issue the following as user PERFSTAT: SQL> Execute statspack.modify_statspack_parameter (i_snap_level=>#) Profiles Profiles created using Statspack information are quite helpful in determining long-term trends such as load increases, usage trends, resource consumption, latch activity, etc. It is especially important that a DBA know these things and be able to demonstrate changes in them that necessitate hardware improvements and load balancing policies. Notes Snapshots during which the instance was recycled will not contain accurate information and should not be included in a Statspack report. Snapshots intervals should be about 15 minutes in length. This allows for fine-grained reporting when hangs are either suspected or detected. Page 34

35 Section E: Stats Pack Tuning Tool Creating a Statspack Performance Report Run a report To run the statistics report as user PERFSTAT: Notes Snapshots can also be combined into hourly reports for general performance tuning. When a value is too large for the Statspack field, it will be represented by a series of pound signs such as #######. Should this occur and you need to see the value in the field, you will need to decrease the number of snapshots in the report until the field can be read. Should there only be one snapshot in the report, then you will need to decrease the snapshot interval. Page 35

36 Section E: Stats Pack Tuning Tool Removing Statspack Removing Statspack If it is necessary to remove the PERFSTAT schema and objects connect internal to the database and run the following This script calls two other scripts to remove the objects and the user: spdtab.sql spdusr.sql Page 36

37 Section F: Library Cache and Shared Pool Tuning Overview Introduction This section discusses some of the common problems that occur with the library cache and the shared pool. It also describes how to diagnose and correct the problems. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents Memory Fragmentation...38 Diagnosing Fragmentation...39 Pinning Packages in Memory...40 Shared Pool Calculation...42 Page 37

38 Section F: Library Cache and Shared Pool Tuning Memory Fragmentation Memory Fragmentation The primary problem that occurs is that free memory in the shared pool becomes fragmented into small pieces over time. Any attempt to allocate a large piece of memory in the shared pool will cause large amount of objects in the library cache to be flushed out and may result in an ORA out of shared memory error. Fragmented memory With Release 7.2, breaking the latches into multiple symmetric latches reduced library cache latch contention. With both Release 7.2 and 7.3, significant changes have been made to reduce usage of shared memory as well as per-user (UGA) memory. Also, memory is not being allocated in large contiguous chunks anymore - resulting in much better shared-pool utilization and reducing fragmentation. The primary problem that occurs is that free memory in the shared pool becomes fragmented into small pieces over time. Any attempt to allocate a large piece of memory in the shared pool will cause large amount of objects in the library cache to be flushed out and may result in an ORA out of shared memory error. Page 38

39 Section F: Library Cache and Shared Pool Tuning Diagnosing Fragmentation Diagnosing Fragmentation One method of diagnosing fragmentation is to look for ORA-4031 errors being returned from applications. When an attempt is made to allocate a large contiguous piece of shared memory, and not enough contiguous memory can be created in the shared pool, the database will signal this error. Before this error is signaled, all objects in the shared pool that are not currently in use will be flushed from the shared pool, and their memory will be freed and merged. This error only occurs when there is still not a large enough contiguous piece of free memory after this happens. There may be very large amounts of total free memory in the shared pool, but just not enough contiguous memory. ORA Out of Shared Memory The two most common causes of the error "Out of shared memory" are lack of available shared pool and lack of available contiguous shared pool into which to map large PL/SQL packages. In order to avoid the latter, it is recommended that the application DBA pin all large packages using the sys.dbms_shared_pool.keep procedure. Page 39

40 Section F: Library Cache and Shared Pool Tuning Pinning Packages in Memory Large PL/SQL objects The primary source of problems is large PL/SQL objects. The means of correcting these errors is to 'keep' large PL/SQL objects in the shared pool at startup time. This will load the objects into the shared pool and will make sure that the objects are never aged out of the shared pool. If the objects are never aged out then there will not be a problem with trying to load them and not having enough memory. Objects are 'kept' in the shared pool using the dbms_shared_pool package that is defined in the dbmspool.sql file. For example: execute dbms_shared_pool.keep('sys.standard'); Pinning Packages is performed by the user SYS To be able to pin packages in memory, the package must already be created. Note that using the following command will remove pinned package from memory and your script to pin packages should be rerun. Step Action 1 Log into sqlplus as user sys as sysdba sqlplus "/ as sysdba" 2 Run the script to create the package 3 To pin a package, execute the pinning package as illustrated SQL> execute dbms_shared_pool.keep( sys.standard ); Note that the packages are not pinned until the first execution of the specific package. Page 40

41 Section F: Library Cache and Shared Pool Tuning Pinning Packages in Memory (Continued) Oracle and ias packages Oracle and ias packages that may be pinned for INB include: sys.dbms_shared_pool.keep('sys.standard'); sys.dbms_shared_pool.keep('sys.dbms_standard'); sys.dbms_shared_pool.keep('sys.dbms_utility'); sys.dbms_shared_pool.keep('sys.dbms_describe'); sys.dbms_shared_pool.keep('sys.dbms_output'); sys.dbms_shared_pool.keep('sys.dbms_sys_sql'); sys.dbms_shared_pool.keep('sys.dbms_sql'); sys.dbms_shared_pool.keep('sys.dbms_job'); sys.dbms_shared_pool.keep('sys.diutil'); sys.dbms_shared_pool.keep('sys.wpiutl'); sys.dbms_shared_pool.keep('sys.diana'); sys.dbms_shared_pool.keep('sys.pidl'); sys.dbms_shared_pool.keep('sys.htp'); sys.dbms_shared_pool.keep('sys.htf'); sys.dbms_shared_pool.keep('sys.owa_util'); sys.dbms_shared_pool.keep('sys.wpg_docload'); sys.dbms_shared_pool.keep('bansecr.g$_authorization_pkg'); sys.dbms_shared_pool.keep('bansecr.g$_security_pkg'); sys.dbms_shared_pool.keep('wtailor.twbkwbis'); sys.dbms_shared_pool.keep('wtailor.twbkwmnu'); Page 41

42 Section F: Library Cache and Shared Pool Tuning Shared Pool Calculation Shared Pool Calculation Shared pool is the amount of fixed, preallocated space in the SGA for use by multi-threaded server session PGA, shared SQL area, and other small, dynamically allocated SGA data structures. Since shared pool usage is highly application dependent, it is necessary to examine each database application individually in order to project a recommended shared pool value. Analyzing shared pool sizing While analyzing shared pool sizing, it is helpful to first increase the shared pool to a very large value, so that the dynamically allocated SGA structures may be allowed to expand to a desirable size. Once this sizing exercise has been completed, the shared pool may be downsized to the appropriate value. Multi-threaded server Shared pool calculation is especially critical when the multi-threaded server is in use because the PGA for each multi-threaded server database user will be allocated from shared pool. Formula Max Session Memory * No. of concurrent users + Total Shared SQL Area Usage + PLSQL Sharable Memory + Minimum 30% Free Space = Minimum Allowable Shared Pool Page 42

43 Section G: Tuning Oracle Sorts Overview Introduction This section provides an overview of tuning Oracle sorts. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents Introduction...44 Disk Sorts...45 Sizing PGA_AGGREGATE_TARGET...46 Sorts and the Temporary Tablespace...47 Tuning PGA_AGGREGATE_TARGET...48 Page 43

44 Section G: Tuning Oracle Sorts Introduction Sort types Oracle uses both disk sorts and memory sorts. Disk sorts, which require access of data on disk, can be a major performance hit Memory sorts are done with the process memory area, which is preallocated for sorting. Memory sorts are cheaper in terms of system resources, and should be the target for tuning Page 44

45 Section G: Tuning Oracle Sorts Disk Sorts Sort areas When you execute a SQL statement that requires sorting, Oracle requires space in memory. These memory areas are called sort areas. The size of the sort area is determined by two parameters: SORT_AREA_SIZE and SORT_AREA_RETAINED_SIZE, both of which are set in the init.ora file. Memory management in 8i and 9i Until Oracle8i, it is the DBA's responsibility to set the memory management parameter SORT_AREA_SIZE. DBAs sized the PGA by carefully adjusting a number of initialization parameters, such as, SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE, and CREATE_BITMAP_AREA_SIZE, etc. Oracle9i provides a new feature by which memory-consuming operations like sort dynamically alters the memory profile to ensure best possible use of system memory and optimal system performance. Automatic tuning mode In the automatic tuning mode, the size of the PGA tunable portion allocated by an instance depends on the overall PGA Memory target explicitly set by the DBA via PGA_AGGREGATE_TARGET parameter. It is recommended to let Oracle size the SORT_AREA_SIZE parameter unless the instance is configured with the shared server option: enable automatic sizing of SQL working areas by setting PGA_AGGREGATE_TARGET instead. Note: The parameter SORT_AREA_SIZE is retained in for backward compatibility. Automatic SQL execution memory management The automatic SQL execution memory management feature is enabled by setting the parameter WORKAREA_SIZE_POLICY to AUTO and by specifying a size of PGA_AGGREGATE_TARGET in the initialization file. These two parameters can also be set dynamically using the ALTER SYSTEM command. In the absence of either of these parameters, the database will revert to manual PGA management mode. In Oracle9i Release 2, advisory for PGA_AGGREGATE_TARGET was introduced. Just like in Buffer Cache Advisory, the PGA Advisory will suggest the appropriate size for PGA memory and thus make PGA tuning an even simpler task. Page 45

46 Section G: Tuning Oracle Sorts Sizing PGA_AGGREGATE_TARGET PGA_ AGGREGATE_ TARGET PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory available to all server processes attached to the instance. You must set this parameter to enable the automatic sizing of SQL working areas used by memory-intensive SQL operators such as sort, group-by, hash-join, bitmap merge, and bitmap create. Oracle uses this parameter as a target for PGA memory. Use this parameter to determine the optimal size of each work area allocated in AUTO mode (when WORKAREA_SIZE_POLICY is set to AUTO.) Oracle attempts to keep the amount of private memory below the target specified by this parameter by adapting the size of the work areas to private memory. When increasing the value of this parameter, you indirectly increase the memory allotted to work areas. Consequently, more memory-intensive operations are able to run fully in memory and less will work their way over to disk. When setting this parameter, you should examine the total memory on your system that is available to the Oracle instance and subtract the SGA. You can assign the remaining memory to PGA_AGGREGATE_TARGET. Page 46

47 Section G: Tuning Oracle Sorts Sorts and the Temporary Tablespace Temporary tablespace If the sort operation needs additional memory (above the value specified by the parameter), the sorted rows are written to disk to free up the sort area so that it can be re-used for the remaining sort. The sorted rows that are temporarily written to disk, are stored in temporary segments. When a new user is created, the TEMPORARY TABLESPACE clause identifies the tablespace for the user's temporary segments. Temporary tablespace designation should be assigned to avoid using the system temporary tablespace, which is the default. The view V$SORT_SEGMENT displays the extents created in temporary tablespaces The view V$SORT_USAGE displays information while sorts are performed Temporary segment cleanup During normal operations, user processes that create temporary segments are responsible for cleanup. If the user process dies before cleaning them up, or the user process receives an error causing the statement to fail, SMON is posted to do the cleanup. Sort segments residing in PERMANENT tablespace are cleaned up by SMON after the sort is completed For performance issues, extents in TEMPORARY tablespaces are not released or unallocated once the operation is complete. Instead, the extent is simply marked as available for the next sort operation. SMON cleans up the segments at startup Page 47

48 Section G: Tuning Oracle Sorts Tuning PGA_AGGREGATE_TARGET PGA_ AGGREGATE_ TARGET settings To determine the appropriate setting for PGA_AGGREGATE_TARGET parameter, consider using the following guide. First estimate Make a first estimate for PGA_AGGREGATE_TARGET based on the following rules. For OLTP systems: PGA_AGGREGATE_TARGET = (<Total Physical Memory > * 80%) * 20% For DSS systems: PGA_AGGREGATE_TARGET = (<Total Physical Memory > * 80%) * 50% For an Oracle instance configured on system with 16G of Physical memory, the suggested PGA_AGGREGATE_TARGET parameter value we should start with in the case of an OLTP system is (16 G * 80%)*20% ~= 2.5G The suggested value for a DSS system is (16 G * 80%)* 50% ~= 6.5 G. In the above equation, we assume that the OS will use 20% of the memory, and in OLTP system 20% of the remaining memory will be used for PGA_AGGREGATE_TARGET. The remaining memory is going for Oracle SGA memory and non-oracle processes memory. You must ensure that enough memory remains for Oracle SGA and also for non-oracle processes. Page 48

49 Section G: Tuning Oracle Sorts Tuning PGA_AGGREGATE_TARGET (Continued) Monitoring performance The second step in tuning the PGA_AGGREGATE_TARGET is to monitor performance using available PGA statistics to see if PGA_AGGREGATE_TARGET is undersized or oversized. Several dynamic performance views are available for this purpose: V$PGASTAT - This view provides instance-level statistics on the PGA memory usage and the automatic PGA memory manager. V$SQL_WORKAREA_HISTOGRAM (Oracle92 only) - This view shows the number of work areas executed with optimal memory size, one-pass memory size, and multi-pass memory size since instance start-up. Statistics in this view are subdivided into buckets that are defined by the optimal memory requirement of the work area. Each bucket is identified by a range of optimal memory requirements specified by the values of the columns LOW_OPTIMAL_SIZE and HIGH_OPTIMAL_SIZE. Tuning PGA_ AGGREGATE_ TARGET The third and last step is tuning the PGA_AGGREGATE_TARGET. In Oracle 9i Release 2 we have two new views that help us in this task: V$PGA_TARGET_ADVICE V$PGA_TARGET_ADVICE_HISTOGRAM By examining these two views, you will be able to determine how key PGA statistics will be impacted if you change the value of PGA_AGGREGATE_TARGET. To enable automatic generation of PGA advice performance views, make sure the following parameters are set: PGA_AGGREGATE_TARGET STATISTICS_LEVEL. Set this to TYPICAL (the default) or ALL; setting this parameter to BASIC turns off generation of PGA performance advice views. The content of these PGA advice performance views is reset at instance start-up or when PGA_AGGREGATE_TARGET is altered. Page 49

50 Section G: Tuning Oracle Sorts Tuning PGA_AGGREGATE_TARGET (Continued) Tuning PGA_ AGGREGATE_ TARGET (cont.) V$PGA_TARGET_ADVICE view predicts how the statistics cache hit percentage and over allocation count in V$PGASTAT will be impacted if you change the value of the initialization parameter PGA_AGGREGATE_TARGET. When we set the PGA_AGGREGATE_TARGET and WORKAREA_SIZE_POLICY to auto, then the *_area_size parameters are automatically ignored and Oracle will automatically use the computed value for these parameters. Notes In Oracle 8i and earlier, the PGA memory was static; once the process started and started to allocate memory for its PGA area, it would not release it back to the OS unless the process exited or died. The OS, when under heavy memory pressure, would decide to page out unused memory pages belonging to a process PGA to the swap space. In Oracle 9i and under the automatic PGA memory management, Oracle will be able to deallocate memory from a process PGA which is not using it any more so another process can use it. It can also adjust the different work areas size to accommodate the current workload and the amount of memory that can be used. Using the automatic PGA memory management feature will help limit resources used by Oracle process, and will use them more efficiently. Using automatic PGA memory management will help also reduce the possibility of getting ORA-4030 errors unless you hit a OS limit, because work area sizes will be controlled and adjusted automatically based on the PGA_AGGGREGATE_TARGET parameter first and then the current work load. Page 50

51 Section H: Latches, Locks and Contention Overview Introduction This section deals primarily with detecting and resolving locking problems. A number of Oracle views permit the DBA to detect locking problems. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents How Oracle Handles Locking...52 Lock Modes Required for Table Actions...53 Diagnosing Locking Problems...54 How to Resolve Locking Situations...55 Dynamic Views to Detect Locking Problems...56 Common Buffer Classes...57 Waits...58 Memory...62 Sessions...66 Unusual Locking Problems...70 Page 51

52 Section H: Latches, Locks and Contention How Oracle Handles Locking How Oracle handles locking Oracle use enqueues as locking mechanism for managing access to shared resources. A shared resource can be a table definition, a transaction or any type of structure that represent something sharable between sessions. Each type of actions performed by Oracle sessions on those shared resources will require a certain type of lock or lock mode (e.g. a 'select on a table' action will require that the executing session has a shared lock on the resource 'table definition' of the selected table). When conflicting actions are occurring, Oracle will serialize the processing by putting a number of sessions in waiting mode until the work of the blocking session has been completed. Each enqueue represents a sharable resource. Sessions are acquiring, converting and releasing locks on resources in function of the work they need to perform. Releasing locks are performed by the sessions when they issue a commit or a DDL statement or by SMON if the sessions have been killed. Conversion and acquisition Conversion is the process of changing a lock from the mode we currently hold to a different mode. Acquiring a lock is the process of getting a lock on a resource on which we currently do not have a lock. We are allowed to convert a lock if the mode we require is a subset of the mode we hold or is compatible with the modes already held by other sessions. Otherwise, we wait on the converters queue of the resource. We are allowed to acquire a lock, if there are no converters or waiters ahead of us and the mode we require is compatible with the modes already held by others. Otherwise, we wait on the waiters queue of the resource. When a session has a lock on a resource, then it stands in the owner queue of the resource. When a lock is released or converted, the converters and waiters are re-checked to see if they can be acquired. The converters are processed first, then the waiters. Page 52

53 Section H: Latches, Locks and Contention Lock Modes Required for Table Actions Lock Modes required The following table describes what lock modes on DML enqueues are actually gotten for which table operations in a standard Oracle installation. Operation Lock Mode LMODE Lock Description Select NULL 1 Null Select for update SS 2 sub share Insert SX 3 sub exclusive Update SX 3 sub exclusive Delete SX 3 sub exclusive Lock For Update SS 2 sub share Lock Share S 4 share Lock Exclusive X 6 exclusive Lock Row Share SS 2 sub share Lock Row Exclusive SX 3 sub exclusive Lock Share Row SSX 5 share/sub exclusive Exclusive Alter table X 6 exclusive Drop table X 6 exclusive Create Index S 4 share Drop Index X 6 exclusive Truncate table X 6 exclusive Page 53

54 Section H: Latches, Locks and Contention Diagnosing Locking Problems UTLLOCKT and CATBLOCK.SQL These are very helpful scripts that oracle provides with the other RDBMS installation scripts (CATALOG.SQL, CATPROC.SQL, etc.). For example, $ORACLE_HOME/rdbms/admin directory on Unix/NT and ora_rdbms directory on VMS. You can find more information in [NOTE: ]. Sometimes, the utllockt script can hang. It is mostly due to a contention on the ST enqueue since a table is created in this script. OEM Top Session OEM Top Session permits to see all the session information. The sessions that are in status ACTIVE can be waiting on locks. By right-clicking on those sessions and choosing the 'detail' screen, you can go to the 'lock' leaflet and find blocking sessions. You can find more information in [NOTE: ]. Using the Logminer From Oracle8i onwards, all locking statements are logged in the redo logs. Analyzing them permits to understand locking situations (see <Note >). Page 54

55 Section H: Latches, Locks and Contention How to Resolve Locking Situations Resolving locking contention Most locking issues are application-specific. To resolve locking contention, one needs to free the resource by: Asking the HOLDER to commit or rollback Killing the session which holds the lock, e.g. log internal and use command ALTER SESSION KILL SESSION sid, serial#; If the database is running on Unix or VMS, it is possible to kill the Unix/VMS shadow process directly. It is not recommended. When killing the Unix/VMS shadow process, please be careful of shared servers in a multi-threaded environment. ROLLBACK FORCE or COMMIT FORCE if 2pc pending transaction. Page 55

56 Section H: Latches, Locks and Contention Dynamic Views to Detect Locking Problems Contention: V$LATCH The following query obtains the name of each latch, the process holding it, and the wait ratio for all latches in the database. SELECT h.pid, n.name, (l.misses/l.gets)*100 wait_ratio FROM V$LATCHHOLDER h, V$LATCHNAME n, V$LATCH l WHERE h.laddr = l.addr AND l.latch# = n.latch#; The following query finds out the process ID for the process experiencing the wait, the name of the latch that is currently held by another process and the wait ratio for that latch overall. SELECT P.pid, n.name, (l.misses/l.gets)*100 wait_ratio FROM V$PROCESS p, V$LATCHNAME n, V$LATCH l WHERE p.latchwait is not null AND p.latchwait = l.addr AND l.latch# = n.latch#; Contention: V$WAITSTAT A busy buffer wait has been detected, which indicates that there are some buffers in the buffer cache that multiple processes are attempting to access concurrently. In order to determine the possible causes for the busy buffer wait, identify the type of class in contention by querying V$WAITSTAT: SELECT class, count FROM V$WAITSTAT WHERE count > 0 ORDER BY count DESC; Page 56

57 Section H: Latches, Locks and Contention Common Buffer Classes Common buffer classes Some common buffer classes that have buffer busy waits include: Data Block If the contention is on tables or indexes, and not on the segment header, then do the following: Check for SQL statements using unselective indexes Check for 'right-hand-indexes.' These are indexes that receive insertions at the same point by many processes; for example, those that use sequence number generators for the key values. Consider using automatic segment-space management, or increasing freelists to avoid multiple processes attempting to insert into the same block Segment Header If the contention is on the segment header, then it is most likely freelist contention. Perform the following actions: Set freelists, or increase of number of freelists. If adding more freelists does not alleviate the problem, use freelist groups, which can make a difference even in a single instance If using Oracle Real Application Clusters, make sure that each instance has its own freelist group Undo Header If the contention is on rollback segment header, then add more rollback segments if not using automatic undo management. Undo Block If the contention is on rollback segment block, then consider making rollback segment sizes larger if not using automatic undo management. Page 57

58 Section H: Latches, Locks and Contention Waits Waits The V$SESSION_WAIT, V$SESSION_EVENT, and V$SYSTEM_EVENT views provide information about which resources were waited for, and, if the TIMED_STATISTICS configuration parameter is set to True, how long each resource was waited for. These views are useful in investigating wait events and related timing data when reactive performance tuning is being done. The events with the most time listed against them are often strong indications of the performance bottleneck. Please Note: This topic concentrates on examples using the V$SESSION_WAIT, V$SESSION_EVENT, and V$SYSTEM_EVENT views. However, it is recommended that you capture performance data over an interval and keep this data for performance and capacity analysis. This form of rollup data can be queried from these views with tools such as Enterprise Manager Diagnostics Pack and Statspack. Page 58

59 Section H: Latches, Locks and Contention Waits (Continued) Waits: V$SESSION_ WAIT This view lists the resources or events for which active sessions are waiting. The users of an online transaction processing (OLTP) system are experiencing a performance lag. Use the V$SESSION_WAIT view to determine how to proceed in order to find bottlenecks. He uses the following query to find out if any sessions are waiting. He then uses this information to investigate further and see whether such waits occur frequently and if they can be correlated with other phenomena, such as the use of particular modules. Page 59

60 Section H: Latches, Locks and Contention Waits (Continued) Waits: V$SESSION_ EVENT This view summarizes wait events for every session. While V$SESSION_WAIT shows the current waits for a session, V$SESSION_EVENT provides a summary of all the events the session has waited for since it started. Example In investigating wait events and related timing data to find the cause for a performance bottleneck. Query the V$SESSION_EVENT view to get information on waits for an event by the database writer. Observation The db file parallel write event corresponds to I/Os performed against the data file headers, control files, or data files. Because the average time for this event is zero, there is no need to investigate I/O contention. Page 60

61 Section H: Latches, Locks and Contention Waits (Continued) Waits: V$SYSTEM_ EVENT This view contains information on total waits for an event. A performance-related support call from the users of an online transaction processing system, are experiencing a noticeably slower performance. The problem may be associated with resource contention. Begin investigation by querying the V$SYSTEM_EVENT view to obtain a summary of all the event waits on the instance since it started. Find the bottlenecks In order to find the bottlenecks, perform the following actions: Remove the idle events from the output Examine the time spent waiting for different events Also examine the average time per wait. Although some waits, such as log file switch completion, might happen only periodically, they can cause a big performance hit when they occur. Page 61

62 Section H: Latches, Locks and Contention Memory Memory: V$BUFFER_ POOL_ STATISTICS The V$BUFFER_POOL_STATISTICS view can be queried to determine the buffer pool hit ratio by using the following formula: hit ratio = 1-(PHYSICAL_READS/(DB_BLOCK_GETS + CONSISTENT_GETS)) Memory: V$ROWCACHE Because the statistics reflecting the data dictionary activity are kept in the V$ROWCACHE view, use the following query to monitor the data dictionary activity over a period of time while the application is running. The sum of the GETS column indicates that there were a total of requests for the dictionary data. The sum of the GETMISSES column indicates that 1042 of the requests for dictionary data resulted in cache misses. The ratio of the sums of GETMISSES to GETS is about 4.19%. SELECT (SUM(GETS - GETMISSES - USAGE - FIXED)) / SUM(GETS) "ROW CACHE" FROM V$ROWCACHE; Page 62

63 Section H: Latches, Locks and Contention Memory (Continued) Memory: V$DB_OBJECT_CACHE Can be used to find all objects that are using large amounts of memory or are being executed multiple times. The following query shows the distribution of the executions and the amount of shared pool memory used across different type of objects. It also shows whether any of the objects have been pinned in the shared pool using the procedure DBMS_SHARED_POOL.KEEP(). Observation You can see that the total number of shared pool executions for the CURSOR object is 8372, and the total amount of shared pool memory used by the CURSOR is Page 63

64 Section H: Latches, Locks and Contention Memory (Continued) Memory: V$LIBRARYCACHE What is happening to the shared pool? Observation Reloads should ideally be zero. SQLs are being aged out. The shared_pool may be too small. Page 64

65 Section H: Latches, Locks and Contention Memory (Continued) Memory: Observation No invalidations means that all SQLs loaded were not partially written over and did not need to be reparsed. Observation The hit ratio is lower than optimal. The shared_pool will need to be increased Page 65

66 Section H: Latches, Locks and Contention Sessions Sessions: V$LOCK Data processing is on hold and sessions are waiting for the wait event enqueue. Query the V$LOCK view to find the sessions holding the lock by using the following query: SELECT lpad(' ', DECODE(request,0,0,1)) sid sess, id1,id2,lmode,request,type FROM V$LOCK WHERE id1 IN (SELECT id1 FROM V$LOCK WHERE lmode = 0) ORDER BY id1,request; Then query the V$SESSION view, using the SID returned by the above query, to find out the SQL statements being executed by the sessions holding the lock and waiting for the lock. Sessions: V$OPEN_ CURSOR: Example Diagnose system resource usage and query the database for sessions that have executed expensive SQL statements. The V$OPEN_CURSOR view is used to find the sessions that have opened more than 400 cursors using the following query: SELECT sid, COUNT(*) FROM V$OPEN_CURSOR GROUP BY sid HAVING COUNT(*) > 400 ORDER BY 2 DESC; Sessions: V$SORT_ USAGE Where can the V$SORT_USAGE view be used? There are performance considerations involved in executing sorts. For best performance, most sorts should occur in memory because sorts to disks are the ones that impact performance. While tuning sorts, the V$SORT_USAGE view can be queried to identify the disk-sorting processes. The V$SORT_USAGE view can also be queried to retrieve LOB index information for temporary LOBs. For example: SELECT USER#, USERNAME, SEGTYPE, EXTENTS, BLOCKS FROM v$sort_usage, v$session WHERE SERIAL#=SESSION_NUM; Page 66

67 Section H: Latches, Locks and Contention Sessions (Continued) Sessions: V$SESSTAT This view lists user session statistics. To find the name of the statistic associated with each statistic number (STATISTIC#), query the V$STATNAME view. Sessions: V$SESSTAT: Example To check Oracle CPU utilization, query the V$SESSTAT view to check if unnecessary parse calls are using up the CPU. Use the following query to obtain a listing of all sessions and the amount of reparsing they do. Use each system identifier (SID) and query the V$SESSION view to find the name of the program that is causing the reparsing. Sessions: V$PX_ SESSTAT The V$PX_SESSTAT view contains information about the sessions that are running parallel execution. This view provides a join of the session information from V$PX_SESSION and the V$SESSTAT table. Thus, all session statistics available to a normal session are available for all sessions performed using parallel execution. Page 67

68 Section H: Latches, Locks and Contention Sessions (Continued) V$SESSION This view has one row for every session connected to the database instance. The sessions include user sessions, as well as background processes such as DBWR, LGWR, and archiver. V$SESSION is basically an information view used for finding the SID or SADDR of a user. However, it has some columns that change dynamically and are useful for examining a user, such as: Columns SQL_HASH_VALUE SQL_ADDRESS PREV_HASH_VALUE PREV_ADDRESS Purpose These identify the SQL statement currently being executed by the session. If NULL or 0, then the session is not executing any SQL statement. These columns identify the previous statement being executed by the session. STATUS This column identifies whether the session is: Active: executing a SQL statement (waiting for/using a resource) Inactive: waiting for more work (that is, SQL statements) Killed: marked to be killed Some other useful V$SESSION columns include: Columns Containing Session Information Column SID SERIAL# AUDSID USERNAME Purpose Session identifier, used to join to other columns Counter, which is incremented each time a SID is reused by another session (when a session ends and another session starts and uses the same SID) Auditing session ID uniquely identifies a session over the life of a database. It is also useful in finding the parallel query slaves for a query coordinator. (During the PQ execution, they have the same AUDSID.) The Oracle user name for the connected session. Page 68

69 Section H: Latches, Locks and Contention Sessions (Continued) Columns Containing Client Information The database session is initiated by a client process that could be running on the database server or connecting to the database across SQL*Net from a middle tier server or even a desktop. The following columns provide information about this client process: Column OSUSER MACHINE# TERMINAL PROCESS PROGRAM Purpose Operating system user name for the client process Machine where the client process is executing Terminal (if applicable) where the client process is running Process ID of the client process Client program being executed by the client process Finding Your Session Details The following query can be used to find your session details from the V$SESSION view. Page 69

70 Section H: Latches, Locks and Contention Unusual Locking Problems Foreign key locking When your application has referential integrity and attempts to modify the child/parent table, Oracle will get additional locking on the parent/child table when there is NO index on the foreign key. To bypass this problem, the most efficient way is to create indexes for all foreign key defined in the database. The script 'TFTS CHECK FOR FOREIGN KEY LOCKING' [NOTE: ] permits to find the problematic foreign keys. See also [NOTE: ]. Using DBMS_PIPE When your application is using DBMS_PIPE extensively, your session can wait for CI locks. You should increase your shared pool. CREATE INDEX and ALTER INDEX REBUILD When statements like 'CREATE INDEX' and 'ALTER INDEX REBUILD' are issued, Oracle behaves differently in Oracle8i compared to Oracle9i. To understand the benefit of the ONLINE option, find more information in [NOTE: ] Share Locks requested during DMLs When a table's INITRANS is set too low, the block is full with data, and there are many concurrent DMLs occurring on rows within the block, one may see a Share Lock being requested when doing a DML. This is the only time that the SHARED lock is grabbed. Instead of waiting for a lock, this process is waiting for some extra space or a release of an INITRANS within the transaction layer of the block. See [NOTE: ] TXTransaction locks - Example wait scenarios Other locks There are other systemwide locks that can be held at any given time. See [NOTE: ] Tracing sessions: waiting on an enqueue Distributed transactions use locks, too. See [NOTE: ] Detecting and Resolving Distributed Locking Conflicts Page 70

71 Section I: Tuning Rollback Segments, Undos and Redo Logs Overview Introduction The use of rollback segments (prior to Oracle9i) or undo segments (with Oracle9i) provides Oracle with the ability to retain a snapshot of data prior to an update and then roll the change back to the original status in the event of an error or other triggering event. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents Tuning Rollback Segments...72 Tuning Undo Segments...77 Tuning Redo Logs...81 Page 71

72 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Rollback Segments Overview Rollback segments are areas of the database that record transactions should the transactions need to be rolled back (or in Windows terms, 'undo'). The rollback segments consists of contiguous or adjoined extents. The extents are used in a circular (round-robin) order, and move from one extent to the next after the current extent is full. Rollback_ segments parameter Rollback segments are identified via the rollback_segments parameter in the database initsid.ora file. This parameter, available in all versions of Oracle specifies the number of rollback segments that are explicitly brought online during instance startup. The rollback segment must already exist, or otherwise, Oracle will give you an ORA-1534 regarding that rollback segment. The instance will then mount, but the database will not open. Benefits Rollback segments are important to the database, as they are used to provide read consistency, undo of transactions, and recovery. Read consistency is very important if you look at this from a business perspective. If user1 is running a query at the same time user2 is changing the data inside of a particular table, but user2 has incorrect information that he has yet to notice, you wouldn't want user1 seeing this data yet. Therefore, user1 can only see this data once it has been committed. There are numerous scenarios where this is important. Rolling back is, of course, used when you make a mistake; the data has not been automatically committed. You can "rollback" and start all over again. Sizing In order to properly configure a system's rollback segments, enough rollback segments must be created with sufficient size. The number of concurrent transactions in the database determines the number of rollback segments. The fewer transactions per rollback segment, the less contention. It is normally recommended to use one rollback segment for every four concurrent transactions. Page 72

73 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Rollback Segments (Continued) Contention Contention for rollback segments occurs when many transactions try to use the same rollback segment at the same time. SQL> select class, count from v$waitstat where class in ('undo header','undo block','system undo header', 'system undo block'); CLASS COUNT system undo header 0 system undo block 0 undo header 0 undo block 0 V$WAITSTAT The view v$waitstat can be queried to check for contention in rollback segments. Column Datatype Description CLASS VARCHAR2 Class of block COUNT NUMBER Number of waits by this OPERATION for this CLASS of block TIME NUMBER Sum of all wait times for all the waits by this OPERATION for this CLASS of block OPERATION for this CLASS of block Wait percentage Additional rollback segments need to be added if the number of waits for any of the rollback segment blocks or headers exceeds more than one percent of the total number of requests. SQL> select sum(value) "Data Requests" from v$sysstat where name in ('db block gets', 'consistent gets'); Data Requests 6100 Page 73

74 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Rollback Segments (Continued) SYSSTAT The SYSSTAT view provides more information about system statistics: Column Datatype Description STATISTIC# NUMBER Statistic number NAME VARCHAR2(64) Statistic name CLASS NUMBER Statistic Class: 1 (User) 2 (Redo) 4 (Enqueue) 8 (Cache) 16 (OS) 32 (Parallel Server) 64 (SQL) 128 (Debug) Other views Other views which can be used to gain information on rollback segments are V$ROLLSTAT and V$ROLLNAME, both of which are only populated when the database is open. Page 74

75 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Rollback Segments (Continued) V$ROLLSTAT This view contains rollback segment statistics: Column Datatype Description USN NUMBER Rollback Segment number EXTENTS NUMBER Number of extents in rollback segment RSIZE NUMBER Size in bytes of rollback segment WRITES NUMBER Number of bytes written to rollback segment XACTS NUMBER Number of active transactions GETS NUMBER Number of header gets WAITS NUMBER Number of header waits OPTSIZE NUMBER Optimal size of rollback segment HWMSIZE NUMBER High Water Mark of rollback segment SHRINKS NUMBER Number of times the size of rollback segment decreases WRAPS NUMBER Number of times the rollback segment is wrapped EXTENDS NUMBER Number of times the rollback segment is extended AVESHRINK NUMBER Average Shrink Size AVEACTIVE NUMBER Current size of active extents, averaged over time STATUS VARCHAR2(15) Rollback Segment Status CUREXT NUMBER Current Extent CURBLK NUMBER Current Block If the AVEACTIVE column is close to the size of OPTSIZE, the OPTIMAL is set correctly. If either EXTENDS or SHRINKS are high, the OPTIMAL can be increased for the rollback segment. V$ROLLNAME This view lists the names of all online rollback segments. Column Datatype Description USN NUMBER Rollback(undo) Segment number NAME VARCHAR2 Rollback Segment name Page 75

76 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Rollback Segments (Continued) Tips for Rollback Segments The usage of SYSTEM tablespace for the rollback segments should be avoided. Create a separate tablespace for the rollback segments. Create approximately one rollback segment for every four concurrent transactions expected. The large rollback segments should be assigned for the long-running queries and setting the storage parameter 'OPTIMAL' appropriately The dynamic expansion and reduction of rollback space can be avoided by monitoring the rollback information using dynamic views. Page 76

77 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Undo Segments Overview Oracle9i databases are capable of managing their own undo (rollback) segments. No longer will administrators need to carefully plan and tune the number and sizes of rollback segments or decide how to strategically assign transactions to a particular rollback segment. Oracle9i also allows administrators to allocate their undo space in a single undo tablespace with the database taking care of issues such as undo block contention, consistent read retention, and space utilization. With this design, you allocate undo space in a single undo tablespace, instead of maintaining a set of statically allocated rollback segments. Potential Oracle issues Note: Before moving from rollback segments to system managed undos, verify that there are no known issues with the version of Oracle you are running. For example, with Oracle version , some Banner processes encounter issues under the OpenVMS operating system. Extent algorithm The algorithm Oracle uses for getting extents: Acquire a free extent from the undo tablespace for the current undo segment, assuming the tablespace has free extents Acquire expired extent space from another undo segment for the current transaction, if no free space exists in the tablespace Reclaim expired extents from the current transaction's committed changes Obtain more space by datafile extension. Reclaim space from un-expired (but committed) transactions from the current undo segment Reclaim space from un-expired (but committed) transactions from other undo segments Page 77

78 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Undo Segments (Continued) Calculating space requirements using V$UNDOSTAT Use of UNDO_RETENTION can potentially increase the size of the undo segment for a given period of time, so the retention period should not be arbitrarily set too high. The UNDO tablespace still must be sized appropriately. Given a specific UNDO_RETENTION parameter setting and some system statistics, the amount of undo space required to satisfy the undo retention requirement can be estimated using the following formula: Undo Space = UR * UPS + overhead - where: o Undo Space is the number of undo blocks o UR is UNDO_RETENTION in seconds o UPS is undo blocks for each second overhead is the small overhead for metadata (transaction tables, bitmaps, and so forth) For example, if UNDO_RETENTION is set to 2 hours, and the transaction rate (UPS) is 200 undo blocks for each second, with a 4K-block size, the required undo space is computed as follows: (2 * 3600 * 200 * 4K) = 5.8GBs. Such computations can be performed by using information in the V$UNDOSTAT view. In the steady state, you can query the view to obtain the transaction rate. The overhead figure can also be obtained from the view. Page 78

79 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Undo Segments (Continued) ORA error in 9i The ORA error in 9i indicates one of the following, in order of probability: That there is not enough undo tablespace. Add datafile(s) to the defined undo_tablespace. OR The undo temp tablespace is restricted in size. Set the max_extent to unlimited. OR You can specify an undo pool for each consumer group. An undo pool controls the amount of total undo that can be generated by a consumer group. When the total undo generated by a consumer group exceeds its undo limit, the current UPDATE transaction generating the redo is terminated. No other members of the consumer group can perform further updates until undo space is freed from the pool. When no UNDO_POOL directive is explicitly defined, users are allowed unlimited undo space. OR The UNDO_RETENTION value is too low. Run the following query for more information. column name format a30 column value format a40 select name,value from v$parameter where name like '%undo%' The output will look similar to this: NAME VALUE undo_management AUTO undo_tablespace APPS_UNDOTS1 undo_suppress_errors FALSE undo_retention 1800 The default value of undo_retention is 900. This may be too small to allow planning to access older rollback data. A setting of 7500 (2 hours) is not uncommon. Page 79

80 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Undo Segments (Continued) Loading large files For Batch Loads that formerly used a BIG rollback segment, you might want to create a large undo tablespace with a different (larger?) block size. In 9i, you can create up to four additional non-standard block caches (block sizes) for your tablespaces. alter system set db_16k_cache_size=100m; Page 80

81 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Redo Logs Overview Redo logs act as transaction journals providing a detailed log of all transactions that affect data for a database. Redo logs are used for recovery caused by media or instance failure and are used to apply transaction data against the database during the roll-forward portion of recovery. If archive logging is enabled using the LOG_ARCHIVE_START initialization parameter, filled redo logs are copied through the ARCH process to the location named in the LOG_ARCHIVE_DEST parameter and are named according to the convention specified by the LOG_ARCHIVE_FORMAT parameter. All the redo log parameters are specified in the initsid.ora file. Processing Oracle writes a system change number (SCN) and timestamp data to the headers of all data files. This process, called a checkpoint, can be tuned to be either more frequent than or simultaneous with log file switches. Normally, log switches and check pointing happen simultaneously. The DBWR process performs the file header updates, while LGWR performs the log switch. If the CKPT process is not started, and DBWR is creating a checkpoint in the file that LGWR needs, LGWR must pause until DBWR completes the checkpoint. Oracle requires a minimum of two redo log groups and a minimum of one member for each group. For archive logging, three groups are suggested. Oracle writes to all members of a log group. When the log group fills, DBWR issues a checkpoint, and one member is selected to be archived if archive logging is enabled. This necessitates well-sized redo logs to avoid unnecessary checkpoints as a result of frequent log switches. The alert log is a valuable tool for monitoring the rate that log switches occur, and subsequently, checkpoints occur. Oracle recommends sizing the online redo logs such that switches occur no more than once per hour. A good starting size is probably 100M for a production database. Page 81

82 Section I: Tuning Rollback Segments, Undos and Redo Logs Tuning Redo Logs (Continued) LOG_CHECKPOINT _INTERVAL The LOG_CHECKPOINT_INTERVAL init.ora parameter controls how often a checkpoint operation will be performed based upon the number of operating system blocks that have been written to the redo log. If this value is larger than the size of the redo log, then the checkpoint will only occur when Oracle performs a log switch from one group to another, which is preferred. On most Unix systems the operating system block size is 512 bytes. This means that setting LOG_CHECKPOINT_INTERVAL to a value of 10,000 (the default setting), causes a checkpoint to occur after 5,120,000 (5M) bytes are written to the redo log. If the size of your redo log is 20M, you are taking four checkpoints for each log. Page 82

83 Section J: Instance Recovery Tuning Overview Introduction Instance recovery is automatic. Restarting the database performs the instance recovery, via the following steps: 1) Rolling forward. data that has not been recorded in the database the contents of rollback segments 2) Rolling back transactions that have been explicitly rolled back or have not been committed. 3) Releasing any resources held by transactions in process at the time of the failure. The length of time instance recovery takes is determined by the amount of data that must be written to the database. The time required can be manipulated using initsid.ora parameters. Intended audience The material is intended for developers, designers and system administrators that need to understand the mechanisms available for tuning SQL based programming. DBAs and system administrators that are directly responsible for the performance of the systems housing the Oracle and Banner products should have a degree of familiarity with all of these subjects. Prerequisites To complete this section, you should have: completed the Education Practices computer-based training (CBT) tutorial "Banner 6.x Fundamentals: Forms and Navigation," or have equivalent experience navigating in the Banner system completed the Sungard Higher Education Oracle Training: Advanced Oracle Database Administration training workbook completed the Sungard Higher Education Oracle Training: Oracle Backup and Recovery training workbook knowledge of Oracle architecture knowledge of Operating system backup and restore mechanisms and the hardware supporting them. Section contents Fast Start Parameters in initialization file...84 V$INSTANCE_RECOVERY...85 Calculating Recovery Performance Overhead...87 Page 83

84 Section J: Instance Recovery Tuning Fast Start Parameters in initialization file Fast-start checkpointing In fast-start checkpointing, introduced in Oracle 8i, the FAST_START_IO_TARGET parameter replaces DB_FILE_MAX_DIRTY_TARGET. FAST_START_IO_TARGET specifies the number of I/Os that should be needed during crash or instance recovery. When you set this parameter, DBWR writes dirty buffers out more aggressively, so that the number of blocks that must be processed during recovery stays below the value specified in the parameter. Oracle 8i In Oracle8i, the incremental checkpoint position should not lag the tail of the log by more than LOG_CHECKPOINT_INTERVAL operating system blocks. The LOG_CHECKPOINT_INTERVAL and FAST_START_IO_TARGET are taken into account to determine how far behind the end of the redo stream the checkpoint position can really be. Oracle 9i In Oracle9i, FAST_START_MTTR_TARGET is the preferred method of specifying how far the checkpoint position should be behind the tail of the redo stream. However, LOG_CHECKPOINT_INTERVAL is still supported if needed. It functions as per the Oracle8i behavior above. FAST_START_MTTR_TARGET enables you to specify the number of seconds the database takes to perform crash recovery of a single instance. FAST_START_MTTR_TARGET can be overridden by either FAST_START_IO_TARGET or LOG_CHECKPOINT_INTERVAL. Page 84

85 Section J: Instance Recovery Tuning V$INSTANCE_RECOVERY V$INSTANCE_RECOVERY This view monitors the mechanisms available to users to limit recovery I/O. Set the initialization parameter LOG_CHECKPOINT_TIMEOUT Set the initialization parameter LOG_CHECKPOINT_INTERVAL Set the initialization parameter FAST_START_MTTR_TARGET Set the size of the smallest redo log Parameters RECOVERY_ESTIMATED_IOS: Contains the number of dirty buffers in the buffer cache. In the Standard Edition, this column is always NULL. ACTUAL_REDO_BLKS: The current actual number of redo blocks required for recovery TARGET_REDO_BLKS: The current target number of redo blocks that must be processed for recovery. This value is the minimum value of the following 3 columns, and identifies which of the 3 userdefined limits determines checkpointing. LOG_FILE_SIZE_REDO_BLKS: Maximum number of redo blocks required to guarantee that a log switch does not occur before the checkpoint completes. LOG_CHKPT_TIMEOUT_REDO_BLKS: Number of redo blocks that need to be processed during recovery to satisfy the LOG_CHECKPOINT_TIMEOUT parameter. The value displayed is not meaningful unless that parameter has been set. LOG_CHKPT_INTERVAL_REDO_BLKS: Number of redo blocks that need to be processed during recovery to satisfy the LOG_CHECKPOINT_INTERVAL parameter. The value displayed is not meaningful unless that parameter has been set. FAST_START_IO_TARGET_REDO_BLKS: This column is obsolete and maintained only for compatibility reasons. The value of this column is always NULL. Page 85

86 Section J: Instance Recovery Tuning V$INSTANCE_RECOVERY (Continued) Parameters (cont.) TARGET_MTTR: Effective MTTR (mean time to recover) target value in seconds. The TARGET_MTTR value is calculated based on the value of the FAST_START_MTTR_TARGET parameter (the TARGET_MTTR value is used internally), and is usually an approximation of the parameter's value. However, if the FAST_START_MTTR_TARGET parameter value is very small (for example, one second), or very large (for example, 3600 seconds), the calculation will produce a target value dictated by system limitations. In such cases, the TARGET_MTTR value will be the shortest calculated time, or the longest calculated time that recovery is expected to take. If FAST_START_MTTR_TARGET is not specified, the value of this field is the current estimated MTTR. ESTIMATED_MTTR: The current estimated mean time to recover (MTTR) based on the number of dirty buffers and log blocks (0 if FAST_START_MTTR_TARGET is not specified). Basically, this value tells you how long you could expect recovery to take based on the work your system is doing right now. CKPT_BLOCK_WRITES: Number of blocks written by checkpoint writes Page 86

87 Section J: Instance Recovery Tuning Calculating Recovery Performance Overhead Fast-start should be evaluated first The Mean Time To Recover (MTTR) should be evaluated first before setting up. Step Action 1 Log into sqlplus as user sys with sysdba privileges sqlplus "/ as sysdba" 2 Calculate performance overhead SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME IN ('physical reads','physical writes', 'physical writes non checkpoint'); 3 To effectively measure the percentage of extra writes, mark the values for these statistics at different times, t_1 and t_2. 4 Calculate the percentage of extra I/Os generated by fast-start check pointing using the following formula: [((PW_2 - PW_1) - (PWNC_2 - PWNC_1)) / ((PR_2 - PR_1) + (PW_2 - PW_1))] x 100% = EIO Where the variables are described below: *_1 Value of prefixed variable at time t_1, which is any time after the database has been running for a while *_2 Value of prefixed variable at time t_2, which is later than t_1 and not immediately after changing any of the checkpoint parameters PWNC physical writes non checkpoint PW physical writes PR physical reads EIO Percentage of estimated extra I/Os generated by enabling check pointing Page 87

88 Release Date This workbook was last updated on 10/11/2006.