Oracle 11g New Features Student Guide

Overview This course is designed to introduce you to the new features of Oracle Database 11g that are applicable
to the work usually performed by database administrators and related personnel. The course does not attempt to provide every detail about a feature or cover aspects of a feature that were available in previous releases (except when defining the context for a new feature or comparing past behavior with current behavior). Consequently, the course is most useful to you if you have already administered other versions of Oracle databases, particularly Oracle Database 10g. Even with this background, you should not expect to be able to implement all of the features discussed in the course without supplemental reading, especially the Oracle Database 11g documentation. The course consists of instructor-led lessons and demonstrations, plus many hands-on practices and demos that enable you to see for yourself how certain new features behave. As with the course content in general, these practices are designed to introduce you to the fundamental aspects of a feature. They are not intended to test your knowledge of unfamiliar syntax or to provide an opportunity for you to examine every nuance of a new feature. The length of this course precludes such activity. Consequently, you are strongly encouraged to use the provided scripts to complete the practices rather than struggle with unfamiliar syntax.
Oracle Database 11g: New Features for Administrators I - 2
Oracle Database Innovation As a result of its early focus on innovation, Oracle has maintained the lead in the industry with a large number of trend-setting products. Continued emphasis on Oracles key development areas has led to a number of industry firstsfrom the first commercial relational database, to the first portable tool set and UNIX-based client/server applications, to the first multimedia database architecture.
Enterprise Grid Computing Oracle Database 10g was the first database designed for grid computing. Oracle Database 11g consolidates and extends Oracles unique ability to deliver the benefits of grid computing. Oracle Infrastructure grids fundamentally changed the way data centers look and operate, transforming data centers from silos of isolated system resources to shared pools of servers and storage. Oracles unique grid architecture enables all types of applications to scale-out server and storage capacity on demand. By clustering low-cost commodity server and storage modules on Infrastructure grids, Oracle Database 11g enables customers to improve their user service levels, reduce their down time, and make more efficient use of their IT resources while still increasing the performance, scalability, and security of their business applications. Oracle Database 11g furthers the adoption of grid computing by offering: Unique scale-out technology with a single database image Lower server and storage costs Increased availability and scalability
Oracle Database 11g: Focus Areas The Oracle Infrastructure grid technology enables information technology systems to be built out of pools of low-cost servers and storage that deliver the highest quality of service in terms of manageability, high availability, and performance. With Oracle Database 11g, the existing grid capabilities are extended in the areas listed in the slide, thereby making your databases more manageable.
Manageability: New manageability features and enhancements increase DBA productivity, reduce costs, minimize errors, and maximize quality of service through change management, additional management automation, and fault diagnosis. Availability: New high-availability features further reduce the risk of down time and data loss, including further disaster recovery offerings, important high-availability enhancements to Automatic Storage Management, support for online database patching, improved online operations, and more. Performance: Many innovative new performance capabilities are available, including SecureFiles, compression for OLTP, Real Application Clusters optimizations, Result Query Caches, TimesTen enhancements, and more.
Oracle Database 11g: Focus Areas (continued) The Oracle Infrastructure grid provides the additional functionality required to manage all the information in the enterprise with robust security, information lifecycle management, and integrated business intelligence analytics to support fast and accurate business decisions at the lowest cost.
Management Automation Oracle Database 11g continues the effort begun in Oracle9i Database and carried on through Oracle Database 10g to dramatically simplify and ultimately, fully automate the tasks that DBAs must perform. What is new in Oracle Database 11g is Automatic SQL Tuning with self-learning capabilities. Other new capabilities include automatic, unified tuning of both SGA and PGA memory buffers, and new advisors for partitioning, database repair, streams performance, and space management. Enhancements to Oracle Automatic Database Diagnostic Monitor (ADDM) give it a better global view of performance in Oracle Real Application Clusters (RAC) environments and improved comparative performance analysis capabilities.
Self-Managing Database: The Next Generation Self-management is an ongoing goal for Oracle Database. Oracle Database 10g marked the beginning of a major effort to make the database easy to use. With Oracle Database 10g, the focus for self-managing was on performance and resources. Oracle Database 11g adds two important axes to the overall self-management goal: change management and fault management.
Suggested Additional Courses For more information about the key grid computing technologies used by the Oracle products, you can obtain additional training from Oracle University (courses listed in the slide).
Suggested Schedule The lessons in this guide are arranged in the order in which you will probably study them in the class. The lessons are grouped into topic areas, but they are also organized by other criteria, including the following: A feature is introduced in an early lesson and then referenced in later lessons. Topics alternate between difficult and easy to facilitate learning. Lessons are supplemented with hands-on practices throughout the course to provide regular opportunities for you to explore what you are learning. If your instructor teaches the class in the sequence in which the lessons are printed in this guide, the class should run approximately as shown in the schedule. Your instructor, however, may vary the sequence of the lessons for a number of reasons, including: Customizing material for a specific audience Covering a topic in a single day instead of splitting the material across two days Maximizing the use of course resources (such as hardware and software)
Oracle Database 11g: New Features for Administrators I - 13 13
Oracle Database 11g : New Features Oracle Databasefor 11g: New Features for Administrators I - 15 Administrators 1 - 15
Oracle Database 11g Installation: Changes During an Oracle Database 11g installation, you will notice several changes to the installation process. These changes include standard database out-of-box memory calculations, character set determination, support for the new SYSASM role, and a corresponding operating system privileges group (OSASM) that is intended to secure privileges to perform ASM administration tasks.
The following are the new components that are available when you install Oracle Database 11g: Oracle Application Express is installed with Oracle Database 11g. It was previously named HTML DB and was available as a separate companion CD component. Oracle Configuration Manager is offered during installation. It was previously named Customer Configuration Repository (CCR). It is an optional component for database installation. Oracle Configuration Manager gathers and stores details relating to the configuration of the software stored in Oracle Database home directories. Oracle SQL Developer is installed by default with template-based database installations, such as General Purpose/Transaction Processing and Data Warehousing. It is also installed with database client Administrator, Runtime, and Custom installations. Oracle Warehouse Builder is installed with Oracle Database 11g. Oracle Database Vault is installed with Oracle Database 11g. It is an optional component
for database installation. It was previously available as a separate companion CD component.
Oracle Database 11g: New Features for Administrators I - # 16
Oracle Database 11g Installation: Changes (continued) The following components are part of Oracle Database 10g, Release 2 (10.2) but are not available for installation with Oracle Database 11g: iSQL*Plus Oracle Workflow Oracle Data Mining Scoring Engine Oracle Enterprise Manager Java Console
Oracle Database 11g Installation: Changes (continued) In Oracle Database 11g, Oracle Universal Installer (OUI) prompts you to specify the Oracle base. The Oracle base that you provide during installation is logged in the local inventory. You can share this Oracle base across all of the Oracle homes that you create on the system. Oracle recommends that you share an Oracle base for all of the Oracle homes created by a user. Oracle Universal Installer has a list box in which you can edit or select the Oracle base. The installer derives the default Oracle home from the Oracle base location that you provide in the list box. However, you can change the default Oracle home by editing the location. The following are changes made in Oracle Database 11g with respect to the Oracle base to make it compliant with Optimal Flexible Architecture (OFA): ORACLE_BASE is a recommended environment variable. (This variable will be mandatory in future releases.) By default, the Oracle base and the Oracle Clusterware home are at the same directory level during Oracle Clusterware installation. You should not create an Oracle Clusterware home under the Oracle base. Because, specifying an Oracle Clusterware home under the Oracle base results in an error. Oracle recommends that you create the flash recovery area and the data file location under the Oracle base.
Oracle Database 11g: Software Installation The Oracle Database 11g software installation is a straightforward process. As the operating system oracle user, change directory to Disk1 on your installation media or software staging directory, and then start Oracle Universal Installer (OUI): $ ./runInstaller Select Oracle Database 11g on the Select a Product to Install page and click Next. On the Select Installation Method page, provide the Oracle base (if the ORACLE_BASE parameter has not been set) and Oracle home locations. The default installation type and UNIX DBA group values are Enterprise Edition and dba, respectively. You must use the Advanced/Custom installation path to install many of the Enterprise Edition options (such as Real Application Testing). Starting with Oracle Database 11g, OUI tries to install its inventory in $ORACLE_BASE/.. As a result, you must ensure that $ORACLE_BASE/.. is writable by any user installing the Oracle software. This translates to the following (as root user): # mkdir -p /u01/app # chgrp oinstall /u01/app # chmod 775 /u01/app
However, if you are running previous versions of the Oracle software, OUI uses the inventory that already exists.
Oracle Database 11g: Software Installation (continued) On the Product-Specific Prerequisite Checks page, your system is examined for supported operating systems and kernels, required RPMs, Oracle environment consistencies, and so on. If no discrepancies are discovered, proceed with the installation by clicking Next. Review the information on the Summary page, and then click Install.
Oracle Database Upgrade Enhancements Oracle Database 11g, Release 1 continues to make improvements to simplify manual upgrades, upgrades performed using the Database Upgrade Assistant (DBUA), and downgrades. The DBUA provides the following enhancements for single-instance databases: Support for improvements to the pre-upgrade tool in the areas of space estimation, initialization parameters, statistics gathering, and new warnings The catupgrd.sql script performs all upgrades and the catdwgrd.sql script performs all downgrades, for both patch releases and major releases. The DBUA can automatically take into account multi-CPU systems to perform parallel object recompilation. Errors are now collected as they are generated during the upgrade and displayed by the Post-Upgrade Status Tool for each component.
Pre-Upgrade Information Tool The Pre-Upgrade Information Tool analyzes the database to be upgraded. It is a SQL script that ships with Oracle Database 11g, Release 1 and must be run in the environment of the database being upgraded. This tool displays warnings about possible upgrade issues with the database. It also displays information about the required initialization parameters for Oracle Database 11g, Release 1.
Pre-Upgrade Information Analysis After installing Oracle Database 11g, you should analyze your database before upgrading it to the new release. This is done by running the Pre-Upgrade Information Tool. This is a necessary step if you are upgrading manually. It is also recommended if you are upgrading with the DBUA so that you can preview the items that the DBUA checks. The Pre-Upgrade Information Tool is a SQL script that ships with Oracle Database 11g and must be copied to and run from the environment of the database being upgraded. To run the tool, follow these steps: 1. Log in to the system as the owner of the Oracle Database 11g Oracle home directory. 2. Copy the Pre-Upgrade Information Tool (utlu111i.sql) from the Oracle Database 11g ORACLE_HOME/rdbms/admin directory to a directory outside of Oracle home (such as /tmp). 3. Log in to the system as the owner of the Oracle home directory of the database to be upgraded. 4. Change to the directory that you copied the files to. Then start SQL*Plus. 5. Connect to the database instance as a user with SYSDBA privileges. 6. Set the system to spool results to a log file for later analysis: SQL> SPOOL upgrade_info.log 7. Run the Pre-Upgrade Information Tool: SQL> @utlu111i.sql Oracle Database 11g : New Features Oracle Databasefor 11g: New Features for Administrators I - 25 Administrators 1 - 25
8. Turn off the spooling of the script results to the log file and check the output of the Pre-Upgrade Information Tool in upgrade_info.log.
STARTUP UPGRADE STARTUP UPGRADE enables you to open a database based on an earlier Oracle Database release. It also restricts logons to AS SYSDBA sessions, disables system triggers, and performs additional operations that prepare the environment for the upgrade (some of which are listed in the slide). To upgrade the candidate database, follow the directions below: 1. Set the ORACLE_SID correctly. The oratab file should point to your Oracle Database 11g Oracle home. The following environment variables point to the Oracle Database 11g directories: ORACLE_HOME PATH 2. Log in to the system as the owner of the Oracle Database 11g Oracle home directory. 3. At system prompt, change to the ORACLE_HOME/rdbms/admin directory and SQL*Plus. 4. Connect to the database instance as a user with SYSDBA privileges. 5. Start up the instance by issuing the following command: SQL> STARTUP UPGRADE
Upgrade Performance Enhancement The script is a wrapper based on the UTL_RECOMP package. UTL_RECOMP provides a more general recompilation interface, including options to recompile objects in a single schema. For details, see the documentation for UTL_RECOMP. By default, this script invokes the utlprp.sql script with 0 as the degree of parallelism for recompilation. This means that UTL_RECOMP automatically determines the appropriate level of parallelism based on the Oracle CPU_COUNT and PARALLEL_THREADS_PER_CPU parameters. If the parameter is set to 1, sequential recompilation is used.
Post-Upgrade Status Tool The Post-Upgrade Status Tool provides a summary of the upgrade at the end of the spool log. It displays the status of the database components in the upgraded database and the time required to complete each component upgrade. Any errors that occur during the upgrade are listed with each component and must be addressed. Run utlu111s.sql to display the results of the upgrade.
Rerun the Upgrade The Post-Upgrade Status Tool should report a status of VALID for all components at the end of the upgrade. Other Status Values As shown in the slide, the report returns INVALID for the Spatial component. This is because of the ORA-04031 error. In this case, you should fix the problem; subsequently running utlrp.sql might change the status to VALID without rerunning the entire upgrade. Check the DBA_REGISTRY view after running utlrp.sql. If that does not fix the problem, or if you see a status of UPGRADING, the component upgrade did not complete. Resolve the problem and rerun catupgrd.sql after you shut down, immediately followed by a startup upgrade.
Oracle Database 11g Release 1 Upgrade Paths The path that you must take to upgrade to Oracle Database 11g, Release 1 depends on the release number of your current database. It might not be possible to upgrade directly from the current version of the Oracle Database to the latest version. Depending on your current release, you might be required to upgrade through one or more intermediate releases to upgrade to Oracle Database 11g, Release 1.
For example, if the current database is running release 8.1.6, follow these steps: 1. Upgrade release 8.1.6 to release 8.1.7 by using the instructions in the Oracle8i Database Migration, Release 3 (8.1.7). 2. Upgrade release 8.1.7 to release 9.2.0.8 by using the instructions in the Oracle9i Database Migration, Release 2 (9.2). 3. Upgrade release 9.2.0.8 to Oracle Database 11g, Release 1 by using the instructions in this lesson.
Choose an Upgrade Method Oracle Database 11g, Release 1 supports the following tools and methods for upgrading a database to the new release: Database Upgrade Assistant (DBUA) provides a graphical user interface (GUI) that guides you through the upgrade of a database. The DBUA can be launched during installation with Oracle Universal Installer, or you can launch the DBUA as a stand-alone tool at any time in the future. The DBUA is the recommended method for performing a major release upgrade or patch release upgrade. Manual upgrade can be performed using SQL scripts and utilities to provide a commandline upgrade of a database. Export and Import utilities: Use the Oracle Data Pump Export and Import utilities, available as of Oracle Database 10g, Release 1 (10.1), or the original Export and Import utilities to perform a full or partial export from your database, followed by a full or partial import into a new Oracle Database 11g, Release 1 database. Export/Import can copy a subset of the data, leaving the database unchanged. CREATE TABLE AS SELECT statement copies data from a database into a new Oracle Database 11g, Release 1 database. Data copying can copy a subset of the data, leaving the database unchanged.
Database Upgrade Assistant: Advantages and Disadvantages The Database Upgrade Assistant (DBUA) guides you through the upgrade process and configures a database for the new release. The DBUA automates the upgrade process and makes appropriate recommendations for configuration options such as tablespaces and redo logs. While the upgrade is running, the DBUA shows the upgrade progress for each component. The DBUA writes detailed trace and log files, and produces a complete HTML report for later reference. To enhance security, the DBUA automatically locks new user accounts in the upgraded database. The DBUA then proceeds to create new configuration files (initialization parameter and listener files) in the new Oracle home. If the DBA requires more control over the individual steps in the upgrade process, a manual upgrade is still possible. Usually, however, the manual upgrade method is more error prone, is harder to automate, and involves a greater amount of work than upgrading with the DBUA.
Sample Test Plan A series of carefully designed tests is required to validate all stages of the upgrade process. Executed rigorously and completed successfully, these tests ensure that the process of upgrading the production database is well understood, predictable, and successful. Perform as much testing as possible before upgrading the production database. Do not underestimate the importance of a test program.
Testing the upgraded database is just as important as testing the upgrade process. Test the newly upgraded test database with existing applications to verify that they operate properly with a new Oracle database. You might also want to test enhanced functions by adding the available Oracle Database features. However, first make sure that the applications operate in the same manner as they did in the current database.
Database Upgrade Assistant (DBUA) The Database Upgrade Assistant (DBUA) guides you through the upgrade process and configures a database for the new release. The DBUA automates the upgrade process and makes appropriate recommendations for configuration options such as tablespaces and redo logs. The DBUA can be used to upgrade databases that were created with any edition of the Oracle Database software, including the Express Edition (XE) databases. The DBUA supports the following versions of Oracle Database for upgrading to Oracle Database 11g, Release 1: Oracle9i, Release 2 (9.2.0.4) and later 9i releases Oracle Database 10g, Release 1 (10.1) Oracle Database 10g, Release 2 (10.2) If your database version is not in this list, you must first upgrade to the closest release listed and then upgrade to Oracle Database 11g, Release 1. The Database Upgrade Assistant is fully compliant with Oracle RAC environments. In RAC environments, the DBUA upgrades all database and configuration files on all nodes in the cluster.
The DBUA supports upgrades of databases that use Automatic Storage Management (ASM). If an ASM instance is detected, you have the choice of updating both the database and the ASM, or updating only the ASM instance.
The Database Upgrade Assistant supports a silent mode of operation in which no user interface is presented to the user. Silent mode enables you to use a single statement for the upgrade.
Key DBUA Features Before starting the upgrade process, Oracle Corporation strongly recommends that you back up your existing database, although the DBUA can perform a backup during the pre-upgrade stage. If you use the DBUA to back up your database, it creates a copy of all your database files in the directory that you specify. The DBUA performs this cold backup automatically after it shuts down the database and before it begins performing the upgrade procedure. However, the cold backup does not compress your database files, and the backup directory must be a valid file system path. In addition, the DBUA creates a batch file in the specified directory. You can use this batch file to restore the database files if needed. During the upgrade, the DBUA automatically modifies or creates new required tablespaces and invokes the appropriate upgrade scripts. While the upgrade is running, DBUA shows the upgrade progress for each component. The DBUA then creates new configuration files (parameter and listener files) in the new Oracle home. The DBUA performs the following checks before the upgrade: Invalid user accounts or roles Invalid data types or invalid objects De-supported character sets Adequate resources (including rollback segments, tablespaces, and free disk space) Missing SQL scripts needed for the upgrade
Listener running (if Oracle EM Database Control upgrade or configuration is requested) The DBUA provides a comprehensive summary of the pre-upgrade checks when finished.
Key DBUA Features (continued) During the upgrade, the DBUA automatically modifies or creates new init.ora and spfile in the new ORACLE_HOME directory. In addition, the DBUA updates the network configurations, creates the required tablespaces, and invokes the appropriate upgrade scripts. While the upgrade is running, the DBUA shows the upgrade progress for each component. The DBUA writes detailed trace and log files in $ORACLE_BASE/cfgtoollogs/dbua/<sid>/upgradeNN and produces a complete HTML report for later reference.
Key DBUA Features (continued) After completing the pre-upgrade steps, the DBUA automatically archives redo logs and disables archiving during the upgrade phase. To enhance security, the DBUA automatically locks new user accounts in the upgraded database. The DBUA then proceeds to create new configuration files (initialization parameter and listener files) in the new Oracle home. The Database Upgrade Assistant is fully compliant with Oracle RAC environments. In RAC environments, the DBUA upgrades all database and configuration files on all nodes in the cluster.
Command-Line Syntax When invoked with the -silent command line option, the DBUA operates in silent mode. In the silent mode, the DBUA does not present a user interface. It also writes any messages (including information, errors, and warnings) to a log file in ORACLE_HOME/cfgtoollogs/dbua/SID/upgraden, where n is the number of upgrades that the DBUA has performed as of this upgrade.
For example, the following command upgrades a database named ORCL in the silent mode: $ dbua -silent -dbName ORCL &
Here is a list of important options that you can use: -backupLocation directory specifies a directory to back up your database before the upgrade starts. -postUpgradeScripts script [, script ] specifies a comma-delimited list of SQL scripts. Specify complete path names. The scripts are executed at the end of the upgrade. -initParam parameter=value [, parameter=value ] specifies a commadelimited list of initialization parameter values of the form name=value. -emConfiguration {CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE}specifies the Oracle Oracle Database 11g : New Features Oracle Databasefor 11g: New Features for Administrators I - 42 Administrators 1 - 42
Enterprise Manager management options. Note: For more information about these options, see the Oracle Database Upgrade Guide 11g.
Using DBUA to Upgrade Your Database To upgrade a database by using the DBUA graphical user interface: On Linux or UNIX platforms, enter the dbua command at system prompt in the Oracle Database 11g, Release 1 environment. The DBUA Welcome screen appears. Click Next. If an ASM instance is detected on the system, the Upgrade Operations page provides you with the options to upgrade a database or an ASM instance. If no ASM instance is detected, the Databases screen appears. At the Upgrade Operations page, select Upgrade a Database. This operation upgrades a database to Oracle Database 11g, Release 1. Oracle recommends that you upgrade the database and ASM in separate DBUA sessions in separate Oracle homes. Click Next.
Choose Database to Upgrade and Diagnostic Destination The Databases screen appears. Select the database that you want to upgrade from the Available Databases table. You can select only one database at a time. If you do not see the database that you want, make sure that an entry with the database name exists in the oratab file in the etc directory. If you are running the DBUA from a user account that does not have SYSDBA privileges, you must enter the user name and password credentials to enable SYSDBA privileges for the selected database. Click Next. The DBUA analyzes the database, performing the following pre-upgrade checks and displaying warnings as necessary: Redo log files whose size is less than 4 MB. If such files are found, the DBUA gives the option to drop or create new redo log files. Obsolete or deprecated initialization parameters When the DBUA finishes its checks, the Diagnostic Destination screen appears. Perform one of the following: Accept the default location for your diagnostic destination. Enter the full path to a different diagnostic destination in the Diagnostic Destination field. Oracle Database 11g : New Features Oracle Databasefor 11g: New Features for Administrators I - 44 Administrators 1 - 44
Click Browse to select a diagnostic destination. Click Next.
Moving Database Files If you are upgrading a single-instance database, the Move Database Files page appears. However, if you are upgrading an Oracle Real Application Clusters database, the Move Database Files page does not appear. Select one of the following options: Do Not Move Database Files as Part of Upgrade Move Database Files during Upgrade If you choose to move database files, you must also select one of the following: File System: Your database files are stored on the host file system. Automatic Storage Management (ASM): Your database files are stored on the ASM storage, which must already exist on your system. If you do not have an ASM instance, you can create one using DBCA and then restart the DBUA. Click Next.
Database File Locations The Database File Locations screen appears. Select one of the following options: Use Common Location for All Database Files: If you choose to have all of your database files in one location, you must also perform one of the following: - Accept the default location for your database files. - Enter the full path to a different location in the Database File Locations field. - Click Browse and select a different location for your database files. Use Oracle-Managed Files: If you choose to use Oracle-Managed Files for your database files, you must also perform one of the following: - Accept the default database area. - Enter the full path to a different database area in the Database Area field. - Click Browse and select a different database area. Use a Mapping File to Specify Location of Database Files: This option enables you to specify different locations for your database files. A sample mapping file is available in the logging location. You can edit the property values of the mapping file to specify a different location for each database file. Click Next.
Recovery Configuration The Recovery Configuration page enables you to designate a Flash Recovery Area for your database. If you selected Move Database Files during Upgrade, or if an Oracle Express Edition database is being upgraded to Oracle Enterprise Edition, then a Flash Recovery Area must be configured. If a Flash Recovery Area is already configured, the current settings are retained but the screen is displayed to enable you to override these values. Click Next.
Management Options and Database Credentials If no other database is already being monitored with Enterprise Manager, the Management Options page appears. On this page, you have the option of setting up your database so that it can be managed with Enterprise Manager. Before you can register the database with Oracle Enterprise Manager Grid Control, an Oracle Enterprise Manager Agent must be configured on the host computer. To set up your database to be managed with Enterprise Manager, select Configure the Database with Enterprise Manager and then select one of the proposed options. Click Next. The Database Credentials page appears. Choose one of the proposed options and click Next.
Network Configuration If the DBUA detects that multiple listeners are configured, the Network Configuration for the database page appears. This page has two tabs. The Listeners tab is displayed if you have more than one listener. The Directory Service tab appears if you have the directory services configured. On the Listeners tab, select one of the following options: Register this database with all the listeners Register this database with selected listeners only If you choose to register selected listeners only, you must select the listeners that you want from the Available Listeners list, and then use the arrow buttons to move them to the Selected Listeners list. If you want to register your database with a directory service, click the Directory Service tab. On the Directory Service tab, select one of the following options: Yes, register the database: Selecting this option enables client computers to connect to this database without a local name file (tnsnames.ora) and also enables them to use the Oracle Enterprise User Security feature. No, dont register the database If you choose to register the database, you must also provide a user distinguished name (DN) in
the User DN field and a password for that user in the Password field. An Oracle Wallet is created as part of database registration. It contains credentials suitable for password authentication between this database and the directory service. Enter a password in both the Wallet Password field and the Confirm Password field. Then click Next.
Recompile Invalid Objects The Recompile Invalid Objects page appears. Select Recompile invalid objects at the end of upgrade if you want the DBUA to recompile all invalid PL/SQL modules after the upgrade is complete. This ensures that you do not experience any performance issues when you begin using your newly upgraded database. If you have multiple CPUs, you can reduce the time it takes to perform this task by taking advantage of parallel processing on your available CPUs. If you have multiple CPUs, the DBUA automatically adds an additional section to the Recompile Invalid Objects page and automatically determines the number of CPUs you have available. The DBUA also provides a recommended degree of parallelism, which determines how many parallel processes are used to recompile your invalid PL/SQL modules. Specifically, the DBUA sets the degree of parallelism to one less than the number of CPUs you have available. You can adjust this default value by selecting a new value from the Degree of Parallelism list. Select Turn off Archiving and Flashback logging, for the duration of upgrade to reduce the time required to complete the upgrade. If the database is in the ARCHIVELOG or flashback logging mode, the DBUA gives you the choice of turning them off for the duration of the upgrade. If you choose this option, Oracle recommends that you perform an offline backup immediately after the upgrade. Oracle Database 11g : New Features Oracle Databasefor 11g: New Features for Administrators I - 50 Administrators 1 - 50
Click Next.
Database Backup and Space Checks The Backup page appears. Select Backup database if you want the DBUA to back up your database. Oracle strongly recommends that you back up your database before starting the upgrade. If errors occur during the upgrade, you might be required to restore the database from the backup. If you use the DBUA to back up your database, it makes a copy of all your database files in the directory that you specify in the Backup Directory field. The DBUA performs this cold backup automatically after it shuts down the database, and before it begins performing the upgrade procedure. The cold backup does not compress your database files and the backup directory must be a valid file system path. You cannot specify a raw device for the cold backup files. In addition, the DBUA creates a batch file in the specified directory. You can use this batch file to restore the database files: On Windows operating systems, the file is db_name_restore.bat. On Linux and UNIX platforms, the file is db_name_restore.sh. If you choose not to use the DBUA for your backup, Oracle assumes that you have already backed up your database using your own backup procedures. Click Next. Note: If you decide to use the DBUA to back up your database, the DBUA checks that you have enough space before the backup is taken. Oracle Database 11g : New Features Oracle Databasefor 11g: New Features for Administrators I - 51 Administrators 1 - 51
Database Upgrade Summary The Summary page appears. It shows the following information about the upgrade before it starts: Name, version, and Oracle home of the old and new databases Database backup location, available space, and space required Warnings ignored Database components to be upgraded Initialization parameter changes Database file locations Listener registration Check all of the specifications. Then perform one of the following: If anything is incorrect, click Back repeatedly until you reach the screen where you can correct it. Click Finish if everything is correct.
Upgrade Progress and Results The Progress screen appears, and the DBUA begins the upgrade. You might encounter error messages with the Ignore and Abort choices. If other errors appear, you must address them accordingly. If an error is severe and cannot be handled during the upgrade, you have the following choices: Click Ignore to ignore the error and proceed with the upgrade. You can fix the problem, restart the DBUA, and complete the skipped steps. Click Abort to terminate the upgrade process. If a database backup was taken by the DBUA, it asks if you want to restore the database. After the database has been restored, you must correct the cause of the error and restart the DBUA to perform the upgrade again. If you do not want to restore the database, the DBUA leaves the database in its present state so that you can proceed with a manual upgrade. After the upgrade has completed, the following message is displayed: Upgrade is complete. Click OK to see the results of the upgrade. When you click OK, the Upgrade Results screen appears. The Upgrade Results screen displays a description of the original and upgraded databases, and the changes made to the initialization parameters. The screen also shows the directory where various log files are stored after the upgrade. You can examine these log files to obtain more
details about the upgrade process. Click Restore Database if you are not satisfied with the upgrade results.
You are now ready to use Oracle Database 11g, Release 1! After you have upgraded your database and before you can consider the database operational, you must complete some post-upgrade tasks regardless of whether you performed the upgrade either manually or by using the DBUA. Some of the more common tasks include: Update environment variables (Linux and UNIX systems only) Adjust initialization parameters as needed Upgrade the Recovery Catalog Test your applications and tune performance Upgrade the statistics tables created by the DBMS_STATS package Enable Oracle Database Vault Upgrade the TIMESTAMP data Use the latest Time Zone file for clients
Deprecated Features in Oracle Database 11g, Release 1 The slide lists the Oracle Database features that are deprecated in Oracle Database 11g, Release 1. Although they are supported in this release for backward compatibility, Oracle recommends that you migrate away from these deprecated features: Oracle Ultra Search Java Development Kit (JDK) 1.4: Oracle recommends that you use JDK 5.0; however, JDK 1.5 is also fully supported. CTXXPATH index: Oracle recommends that you use XMLIndex instead.
Important Initialization Parameter Changes The DIAGNOSTIC_DEST initialization parameter replaces the USER_DUMP_DEST, BACKGROUND_DUMP_DEST, and CORE_DUMP_DEST parameters. Starting with Oracle Database 11g, the default location for all trace information is defined by DIAGNOSTIC_DEST, which defaults to $ORACLE_BASE/diag. Old parameters are ignored if specified. For more information about diagnostics, refer to the lesson titled Diagnosability Enhancements. A newly installed Oracle Database 11g instance defaults to automatic undo management mode, and, if the database is created with the DBCA, an undo tablespace is automatically created. A null value for the UNDO_MANAGEMENT initialization parameter now defaults to automatic undo management; in previous releases, it defaulted to manual undo management mode. You must therefore use caution when upgrading a previous release to Oracle Database 11g. Note: The CONTROL_MANAGEMENT_PACK_ACCESS initialization parameter specifies the Server Manageability Packs that should be active. The following packs are available: The DIAGNOSTIC pack includes AWR, ADDM, and so on. The TUNING pack includes SQL Tuning Advisor, SQL Access Advisor, and so on. A license for DIAGNOSTIC is required to enable the TUNING pack.
Possible values for this parameter are NONE, DIAGNOSTIC, and DIAGNOSTIC+TUNING (default).
Direct NFS Client: Overview Direct NFS is implemented as a Direct Network File System client as part of the Oracle RDBMS kernel in the Oracle Disk Manager library. NAS-based storage systems use Network File System to access data. In Oracle Database 10g, NAS storage devices are accessed using the operating systemprovided kernel Network File System driver, which requires specific configuration settings to ensure its efficient and correct usage with Oracle Database. The following are the major problems that arise from incorrectly specifying these configuration parameters: NFS clients are very inconsistent across platforms and vary across operating system releases. With more than 20 parameters to tune, manageability is affected. Oracle Direct Network File System implements the NFS version 3 protocol in the Oracle RDBMS kernel. The following are the main advantages of implementing Oracle Direct NFS: It enables complete control over the input/output path to Network File Servers. This results in predictable performance and enables simpler configuration management and a superior diagnosability. Its operations avoid the kernel Network File System layer bottlenecks and resource limitations. However, the kernel is still used for network communication modules. It provides a common Network File System interface for Oracle for potential use on all host platforms and supported Network File System servers.
It enables improved performance through load balancing across multiple connections to Network File System servers and deep pipelines of asynchronous input/output operations with improved concurrency.
Direct NFS Configuration By default, Direct NFS attempts to serve mount entries found in /etc/mtab. No other configuration is required. You can optionally use oranfstab to specify additional Oraclespecific options to Direct NFS. For example, you can use oranfstab to specify additional paths for a mount point as shown in the example in the slide. When oranfstab is placed in $ORACLE_HOME/dbs, its entries are specific to a single database. However, when oranfstab is placed in /etc, it is global to all Oracle databases and thus, can contain mount points for all Oracle databases. Direct NFS looks for the mount point entries in the following order: $ORACLE_HOME/dbs/oranfstab, /etc/oranfstab, and /etc/mtab. It uses the first matched entry as the mount point. In all cases, Oracle requires that mount points be mounted by the kernel NFS system even when being served through Direct NFS. Oracle verifies kernel NFS mounts by cross-checking entries in oranfstab with the operating system NFS mount points. If a mismatch exists, Direct NFS logs an informational message and does not serve the NFS server.
Monitoring Direct NFS Use the following views for Direct NFS management: V$DNFS_SERVERS: Shows a table of servers accessed using Direct NFS V$DNFS_FILES: Shows a table of files currently open using Direct NFS V$DNFS_CHANNELS: Shows a table of open network paths (or channels) to servers for which Direct NFS is providing files V$DNFS_STATS: Shows a table of performance statistics for Direct NFS
Hot Patching: Overview Hot patching provides the ability to install, enable, and disable a bug fix or diagnostic patch on a live, running Oracle instance. Using hot patching is the recommended solution for avoiding down time when applying hot patches. Oracle provides the capability to do hot patching with any Oracle database using the opatch command-line utility. Hot patches can be provided when the changed code is small in scope and complexity (for example, with diagnostic patches or small bug fixes).
Installing a Hot Patch Unlike traditional patching mechanisms, applying a hot patch does not require instance shutdown or restart. Similar to traditional patching, you can use OPatch to install a hot patch. You can determine whether a patch is a hot patch by using the following command: opatch query -is_online_patch <patch location> or opatch query <patch location> -all Note: The patched code is shipped as a dynamic/shared library, which is then mapped into memory by each Oracle process.
Benefits of Hot Patching You do not have to shut down your database instance while you apply the hot patch. Unlike conventional patching, hot patching is extremely fast to install and uninstall. Because hot patching uses OPatch, you get all the benefits that you already have with conventional patching that uses OPatch. It does not matter how long or how many times you shut down your databasea hot patch always persists across instance shutdown and startup.
Conventional Patching and Hot Patching Conventional patching basically requires a shutdown of your database instance. Hot patching does not require any down time. Applications can keep running while you install a hot patch. Similarly, hot patches that have been installed can be uninstalled with no down time.
Hot Patching Considerations One operating system (OS) page is typically 4 KB on Linux x86 and 8 KB on Solaris SPARC64. With an average of approximately one thousand Oracle processes running at the same time, this represents around 4 MB of extra memory for a small hot patch.
Hot Patching Considerations (continued) A vast majority of diagnostic patches are available as hot patches. For bug fixes, it really depends on their nature. Not every bug fix or diagnostic patch is available as a hot patch. But the long-term goal of the hot-patching facility is to provide hot-patching capabilities for Critical Patch Updates.
Note: In this lesson, the term ASM data extent is shortened to extent.
Without ASM Fast Mirror Resync ASM offlines a disk whenever it is unable to complete a write to an extent allocated to the disk, while writing at least one mirror copy of the same extent on another disk if the corresponding disk group uses ASM redundancy. With Oracle Database 10g, ASM assumes that an offline disk contains only stale data; therefore, it no longer reads from such disks. Shortly after a disk is put offline, ASM drops it from the disk group by re-creating the extents allocated to the disk on the remaining disks in the disk group using redundant extent copies. This process is a relatively costly operation and can take hours to complete. If the disk failure is only a transient failure (such as failure of cables, host bus adapters, controllers, or disk power supply interruptions), you have to add the disk again after the transient failure is fixed. However, adding the dropped disk back to the disk group incurs the additional cost of migrating the extents back to the disk.
ASM Fast Mirror Resync: Overview ASM fast mirror resync significantly reduces the time required to resynchronize a transient failure of a disk. When a disk goes offline following a transient failure, ASM tracks the extents that are modified during the outage. When the transient failure is repaired, ASM can quickly resynchronize only the ASM disk extents that have been affected during the outage. This feature assumes that the content of the affected ASM disks has not been damaged or modified. When an ASM disk path fails, the ASM disk is taken offline but not dropped if you have set the DISK_REPAIR_TIME attribute for the corresponding disk group. The setting for this attribute determines the duration of disk outage that ASM will tolerate while still being able to resynchronize after you complete the repair. Note: The tracking mechanism uses one bit for each modified extent. This ensures that the tracking mechanism is very efficient.
Using EM to Perform Fast Mirror Resync When you offline an ASM disk in Oracle Enterprise Manager (EM), you are asked to confirm the operation. On the Confirmation page, you can override the default disk repair time. Similarly, you can view by failure group and choose a particular failure group to offline.
Using EM to Perform Fast Mirror Resync (continued) You can also online disks by using Enterprise Manager.
Setting Up ASM Fast Mirror Resync You set up this feature on a perdisk group basis. You can do so after disk-group creation using the ALTER DISKGROUP command. Use a command similar to the following to enable ASM fast mirror resync: ALTER DISKGROUP SET ATTRIBUTE 'DISK_REPAIR_TIME'='2D4H30M' After you repair the disk, run the SQL statement ALTER DISKGROUP ONLINE DISK. This statement brings a repaired disk group back online to enable writes so that no new writes are missed. This statement also starts a procedure to copy all extents that are marked as stale on their redundant copies. You cannot apply the ONLINE statement to already-dropped disks. You can view the current attribute values by querying the V$ASM_ATTRIBUTE view. You can determine the time left before ASM drops an offlined disk by querying the REPAIR_TIMER column of either V$ASM_DISK or V$ASM_DISK_IOSTAT. In addition, a row corresponding to a disk resync operation appears in V$ASM_OPERATION with the OPERATION column set to SYNC.
ASM Preferred Mirror Read: Overview When you configure ASM failure groups in Oracle Database 10g, ASM always reads the primary copy of a mirrored extent. It may be more efficient for a node to read from a failure group extent that is closest to the node, even if it is a secondary extent. This is especially true in extended cluster configurations (when nodes are spread across several sites) where reading from a local copy of an extent provides improved performance.
With Oracle Database 11g, you can do this by configuring the preferred mirror read using the new initialization parameter, ASM_PREFERRED_READ_FAILURE_GROUPS, to specify a list of preferred mirror read names. The disks in those failure groups become the preferred read disks. Thus, every node can read from its local disks. This results in higher efficiency and performance, and reduced network traffic. The setting for this parameter is instance-specific.
ASM Preferred Mirror Read: Setup To configure this feature, set the new ASM_PREFERRED_READ_FAILURE_GROUPS initialization parameter. This parameter is a multivalued parameter and should contain a string with a list of failure group names separated by commas. Each failure group name specified should be prefixed with its disk group name and a . character. This parameter is dynamic and can be modified using the ALTER SYSTEM command at any time. An example is shown in the slide. However, this initialization parameter is valid only for ASM instances. With the extended cluster, the failure groups specified in this parameter should contain only those disks that are local to the corresponding instance. The new column PREFERRED_READ has been added to the V$ASM_DISK view. Its format is a single character. If the disk group to which the disk belongs pertains to a preferred read failure group, the value of this column is Y. To identify specific performance issues with the ASM preferred read failure groups, use the V$ASM_DISK_IOSTAT view. This view displays the disk I/O statistics for each ASM client. If this view is queried from a database instance, only the rows for this instance are shown.
Enterprise Manager ASM Configuration Page You can specify a set of disks as preferred disks for each ASM instance by using Enterprise Manager. The preferred read attributes are instance-specific. In Oracle Database 11g, the Preferred Read Failure Groups field (asm_preferred_read_failure_group) is added to the configuration page. This parameter only takes effect before the disk group is mounted or when the disk group is created. It applies only to newly opened files or to a newly loaded extend map for a file.
ASM Preferred Mirror Read: Best Practice In practice, there are only a limited number of good disk group configurations in an extended cluster. A good configuration takes into account both performance and availability of a disk group in an extended cluster. Here are some possible examples: For a two-site extended cluster, a normal redundancy disk group should have only two failure groups; all disks local to one site should belong to the same failure group. Also, no more than one failure group should be specified as a preferred read failure group by each instance. If there are more than two failure groups, ASM may not mirror a virtual extent across both sites. Furthermore, if the site with more than two failure groups were to go down, it would take the disk group down as well. If the disk group to be created is a high-redundancy disk group, at most two failure groups should be created on each site with its local disks, with both local failure groups specified as preferred read failure groups for the local instance. For a three-site extended cluster, a high redundancy disk group with three failure groups should be used. In this way, ASM can guarantee that each virtual extent has a mirror copy local to each site and that the disk group is protected against a catastrophic disaster on any of the three sites.
ASM Scalability and Performance Enhancements ASM Variable Size Extents is an automated feature that enables ASM to support larger file sizes while improving memory usage efficiency. In Oracle Database 11g, ASM supports variable sizes for extents of 1, 8, and 64 allocation units (AU). ASM uses a predetermined number of extents of each size. As soon as a file crosses a certain threshold, the next extent size is used. With this feature, fewer extent pointers are needed to describe the file and less memory is required to manage the extent maps in the shared pool (which would have been prohibitive in large file configurations). Extent size can vary both across files and within files. Variable Size Extents also enables you to deploy Oracle databases using ASM that are several hundred TB (or even several PB) in size. Note: The management of Variable Size Extents is completely automated and does not require manual administration.
ASM Scalability in Oracle Database 11g ASM imposes the following limits: 63 disk groups in a storage system 10,000 ASM disks in a storage system 4 petabytes maximum storage for each ASM disk 40 exabytes maximum storage for each storage system 1 million files for each disk group Maximum file size depends on the redundancy type of the disk groups used: 140 PB for external redundancy (value currently greater than possible database file size), 42 PB for normal redundancy, and 15 PB for high redundancy. Note: In Oracle Database 10g, the maximum ASM file size for external redundancy is 35 TB.
SYSASM Role This feature introduces a new SYSASM role that is specifically intended for performing ASM administration tasks. Using the SYSASM role instead of the SYSDBA role improves security by separating ASM administration from database administration. With Oracle Database 11g, Release 1, the OS group for SYSASM and SYSDBA is the same, and the default installation group for SYSASM is dba. In a future release, separate groups will have to be created, and SYSDBA users will be restricted in ASM instances. As a member of the dba group, you can currently connect to an ASM instance by using the first statement in the slide. You also have the ability to use the combination of CREATE USER and GRANT SYSASM SQL statements from an ASM instance to create a new SYSASM user. This can be useful for remote ASM administration. These commands update the password file of each ASM instance and do not need the instance to be up and running. Similarly, you can revoke the SYSASM role from a user by using the REVOKE command, and you can drop a user from the password file by using the DROP USER command.
The V$PWFILE_USERS view integrates a new column called SYSASM, which indicates whether the user can connect with SYSASM privileges (TRUE) or not (FALSE).
Note: With Oracle Database 11g, Release 1, if you log in to an ASM instance as SYSDBA, warnings are written in the corresponding alert.log file.
Using EM to Manage ASM Users Oracle Enterprise Manager 11g enables you to manage the users who access the ASM instance through remote connection (using password file authentication). These users are used exclusively for the ASM instance. However, you have this functionality only when connected as the SYSASM user. It is hidden if you connect as the SYSDBA or SYSOPER user. When you click the Create button, the Create User page is displayed. When you click the Edit button, the Edit User page is displayed. By clicking the Delete button, you can delete the created users. Note: Oracle Database 11g adds the SYSASM role to the ASM instance login page.
ASM Disk Group Compatibility There are two kinds of compatibility applicable to ASM disk groups: ASM compatibility: Dealing with the persistent data structures that describe a disk group RDBMS compatibility: Dealing with the capabilities of the clients (consumers of disk groups) The compatibility of each disk group is independently controllable. This is required to enable heterogeneous environments with disk groups from both Oracle Database 10g and Oracle Database 11g. These two compatibility settings are attributes of each ASM disk group: RDBMS compatibility refers to the minimum compatible version of the RDBMS instance that would allow the instance to mount the disk group. This compatibility determines the format of messages that are exchanged between the ASM and database (RDBMS) instances. An ASM instance is capable of supporting different RDBMS clients running at different compatibility settings. The database-compatible version setting of each instance must be greater than or equal to the RDBMS compatibility of all disk groups used by that database. Database instances are typically run from a different Oracle home than the ASM instance. This implies that the database instance may be running a different software version than the ASM instance. When a database instance first connects to an ASM instance, it negotiates the highest version that they both can support. The compatibility
parameter setting of the database, the software version of the database, and the RDBMS compatibility setting of a disk group determine whether a database instance can mount a given disk group.
ASM Disk Group Attributes When you create or alter an ASM disk group, you can change its attributes by using the new ATTRIBUTE clause of the CREATE DISKGROUP or ALTER DISKGROUP commands. These attributes are briefly summarized in the table in the slide: ASM enables the use of different AU sizes that you specify when you create a disk group. The AU size can be 1 MB, 2 MB, 4 MB, 8 MB, 16 MB, 32 MB, or 64 MB. RDBMS compatibility: See the slide titled ASM Disk Group Compatibility for more information. ASM compatibility: See the slide titled ASM Disk Group Compatibility for more information. You can specify the DISK_REPAIR_TIME in units of minutes (M), hours (H), or days (D). If you omit the unit, the default is H. If you omit this attribute, then the default is 3.6H. You can override this attribute with an ALTER DISKGROUP statement. You can specify the redundancy attribute of the specified template. You can specify the striping attribute of the specified template. Note: For each defined disk group, you can look at all the defined attributes by using the V$ASM_ATTRIBUTE fixed view.
Using EM to Edit Disk Group Attributes EM provides a simple way to store and retrieve environment settings related to disk groups. You can now set the compatible attributes from both the Create Disk Group page and the Edit Advanced Attributes for Disk Group page. The disk_repair_time attribute is added to only the Edit Advanced Attributes for Disk Group page. Note: For 11g ASM instances, the default ASM and Database compatibility values are 11.1.
Enhanced Disk Group Checks The CHECK disk group command is simplified to check all the metadata directories by default. The CHECK command lets you verify the internal consistency of the ASM disk group metadata. ASM displays summary errors and writes the details of the detected errors in the alert log. In earlier releases, you could specify this clause for ALL, DISK, DISKS IN FAILGROUP, and FILE. Those clauses have been deprecated because they are no longer needed. In the current release, the CHECK keyword performs the following operations: Checks the consistency of the disk (equivalent to CHECK DISK and CHECK DISK IN FAILGROUP in previous releases) Cross-checks all the file extent maps and allocation tables for consistency (equivalent to CHECK FILE in previous releases) Checks that the alias metadata directory and the file directory are linked correctly Checks that the alias directory tree is linked correctly Checks that ASM metadata directories do not have unreachable allocated blocks The REPAIR | NOREPAIR clause enables you to tell ASM whether or not to attempt to repair the errors found during the consistency check. The default is REPAIR. The NOREPAIR setting is useful when you want to be alerted to any inconsistencies but do not want ASM to take any automatic action to resolve them.
Note: Introducing extra checks as part of check disk group slows down the entire check disk group operation.
Restricted Mount Disk Group for Fast Rebalance A new mount mode to mount a disk group in Oracle Database 11g is called RESTRICTED. When a disk group is mounted in RESTRICTED mode, clients cannot access the files in a disk group. When an ASM instance knows that there are no clients, the instance improves the performance of the rebalance operation by not attempting to message clients for locking/unlocking extent maps. A disk group mounted in RESTRICTED mode is mounted exclusively on only one node; clients of ASM on that node cannot use that disk group. The RESTRICTED mode allows you to perform all maintenance tasks on a disk group in the ASM instance without external interaction. At the end of the maintenance cycle, you must explicitly dismount the disk group and remount it in normal mode. The ALTER DISKROUP diskgroupname MOUNT command is extended to enable ASM to mount the disk group in RESTRICTED mode. An example is shown in the slide. When you use the RESTRICTED option to start up an ASM instance, all disk groups defined in the ASM_DISKGROUPS parameter are mounted in RESTRICTED mode.
Mount Force Disk Group This feature alters the behavior of ASM when mounting an incomplete disk group. With Oracle Database 10g, as long as there are enough failure groups to mount a disk group, the mount operation succeeds, even when there are missing or damaged failure groups. This behavior has the potential to automatically drop ASM disks, requiring their addition again later after repair, and thus incurring a long rebalance operation. With Oracle Database 11g, such an operation fails unless you specify the new FORCE option when mounting the damaged disk group. This allows you to correct configuration errors (such as ASM_DISKSTRING set incorrectly) or connectivity issues before trying the mount again. However, disk groups mounted with the FORCE option could potentially have one or more disks offline if they were not available at the time of the mount. You must take corrective action before DISK_REPAIR_TIME expires to restore those devices. Failing to online those devices results in the disks being expelled from the disk group and costly rebalancing being required to restore redundancy for all the files in the disk group. Also, if one or more devices are offlined as a result of MOUNT FORCE, some or all files will not be properly protected until the redundancy is restored in the disk group via rebalance. Therefore, MOUNT with FORCE is useful when you know that some of the disks belonging to a disk group are unavailable. The disk group mount succeeds if ASM finds enough disks to form a Oracle Database 11g : New Features Oracle Databasefor 11g: New Features for Administrators I - 96 Administrators 2 - 96
quorum.
Forcing Disk Group Drop Drop disk group force marks the headers of disks belonging to a disk group that cannot be mounted by the ASM instance as FORMER. However, the ASM instance first determines whether the disk group is being used by any other ASM instance using the same storage subsystem. If it is being used, and if the disk group is in the same cluster or on the same node, the statement fails. If the disk group is in a different cluster, the system checks further to determine whether the disk group is mounted by an instance in the other cluster. If the disk group is mounted elsewhere, the statement fails. However, this latter check is not as definitive as the checks for disk groups in the same cluster. You should therefore use this clause with caution. Note: When executing the DROP DISKGROUP command with the FORCE option, you must also specify the INCLUDING CONTENTS clause.
ASMCMD Extensions ASMCMD is extended to include ASM metadata backup and to restore functionality. This provides the ability to re-create a preexisting ASM disk group with the exact template and alias directory structure. Currently, if an ASM disk group is lost, it is possible to restore the lost files by using RMANbut you must manually re-create the ASM disk group and any required user directories or templates. ASM metadata backup and restore (AMBR) works in two modes: - In backup mode, AMBR parses ASM fixed tables and views to gather information about existing disks and failure group configurations, templates, and alias directory structures. It then dumps this metadata information to a text file. - In restore mode, AMBR reads the previously generated file to reconstruct the disk group and its metadata. You have the ability to control AMBR behavior in restore mode to do a full, nodg, or newdg restore. The difference among the three submodes is in whether you want to include the disk group creation and change its characteristics. The lsdsk command lists ASM disk information. This command can run in two modes: - In connected mode, ASMCMD uses the V$ and GV$ views to retrieve disk Oracle Database 11g : New Features Oracle Databasefor 11g: New Features for Administrators I - 99 Administrators 2 - 99
information. In nonconnected mode, ASMCMD scans disk headers to retrieve disk information, using an ASM disk string to restrict the discovery set. The connected mode is always attempted first.
ASMCMD Extensions: Example This example describes how to back up ASM metadata by using the md_backup command, and how to restore the data by using the md_restore command. The first statement specifies the b option and the g option of the command. This defines the name of the generated file containing the backup information as well as the disk group that needs to be backed up (jfv_backup_file and data, respectively, in the slide). In step 2, it is assumed that there is a problem in the DATA disk group. As a result, it gets dropped. Before you can restore the database files that the disk group contained, you have to restore the disk group itself. In step 3, you initiate the disk group re-creation as well as restoration of its metadata by using the md_restore command. Here you specify the name of the backup file generated in step 1 as well as the name of the disk group that you want to restore, plus the type of restore that you want. In this example, a full restore of the disk group is done because it no longer exists. After the disk group is re-created, you can restore its database files by using (for example) RMAN.
Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 101 Administrators 2 - 101
Change Management in Oracle Database 11g This lesson begins with a brief introduction to the Change Management features and benefits in Oracle Database 11g, which are covered in three lessons. Lesson 3 (SQL Performance Analyzer) begins on slide 9.
Challenges Faced by DBAs When Performing Changes Large business-critical applications are complex and have highly varying load and usage patterns. At the same time, these business systems are expected to provide certain service-level guarantees in terms of response time, throughput, uptime, and availability. Any change to a system (such as upgrading the database or modifying the configuration) often necessitates extensive testing and validation before these changes can make it to the production system. To be confident before moving to a production system, the database administrator (DBA) must expose a test system to a workload very similar to the workload to be experienced in a production environment. It is also beneficial for the DBA to have an effective way to analyze the impact of system-level changes on the overall SQL performance so that any required tuning changes can be performed before production.
Change Is the Only Constant Oracle Database 11g is designed for data center environments that are rapidly evolving and changing to keep up with business demands, enabling DBAs to manage change effectively and efficiently. Building on the self-managing capabilities of Oracle Database 10g, Oracle Database 11g offers significant advances in the areas of automatic diagnostics, supportability, and change management. Oracle DBAs and information technology managers are leading the key initiatives in data centers today. Some of these data center initiatives are moving to low-cost computing platforms (such as Oracle Enterprise Linux) and simplifying storage management by using ASM. DBAs need to test the databases by using realistic workloads with new operating systems or storage platforms to ensure that migration is successful. Todays enterprises must make significant investments in hardware and software to perform the infrastructure changes. For example, if the DBA wants to test the storage management of data files for a database, from file systembased to ASM for a typical J2EE application, the enterprise would need to invest in duplicate hardware for the entire application stack, including the Web server, application server, and database. The organization would also need to invest in expensive testing software to capture the end-user workload. These purchases make it very expensive for any organization to evaluate and implement changes to their data center infrastructure. Oracle Database 11g addresses this issue with a collection of solutions under the umbrella of Change Management. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 109 Administrators 3 - 109
Lifecycle of Change Management Oracle Database 11g supports realistic testing through the use of snapshot standbys to set up and test the physical environment. You can open a physical standby database temporarily (that is, activated) for read and write activities such as reporting and testing. Once testing is completed, you can then simply revert to the physical standby mode to allow catch-up to the primary site. This functionality preserves zero data loss and is similar to storage snapshots, but allows for disaster recovery and offers a single copy of storage at the time of testing. For enterprises to be able to perform an accurate test of a database environment, it is vital that they be able to reproduce the production scenarios accurately. Database Replay provides further support for realistic testing in Oracle Database 11g. Database Replay is designed to capture client requests on a given database to be reproduced on other copies of production databases. Oracle Enterprise Manager provides an easy-to-use set of steps to set up the capture of a workload. Some of the changes that a DBA deals with are database upgrades, new tuning recommendations, schema changes, statistics collection, and changes in operating system and hardware. DBAs can use SQL Performance Analyzer to track and forecast SQL performance changes caused by these changes. If SQL performance has regressed in some of the cases, the DBA can then run the SQL Tuning Advisor to tune the SQL statements.
Lifecycle of Change Management (continued) When upgrading from Oracle Database 11g, Release 1, you can use the rolling upgrade functionality to ensure that various versions of the software can still communicate with each other. This allows independent nodes of an ASM cluster to be migrated or patched without affecting the availability of the database, thereby providing higher uptime and problem-free migration to new releases. ASM offers further system capacity planning and workload change enhancements (Fast Disk Resync, Preferred Mirror Read). Numerous enhancements to the online functionality (online index reorganization and online table redefinition) further support application change. Automatic Diagnostic Repository (ADR) is a new system-managed repository for storing and organizing trace files and other error diagnostic data. You get a comprehensive view of all the serious errors encountered by the database, and the relevant data needed for problem diagnosis and eventual resolution. You can also use EM Support Workbench, which provides a simple workflow interface to view and diagnose incident data, and package it for Oracle Support. The Data Recovery Advisor tool can be used to automatically diagnose data failures and report on the appropriate repair option. Oracle Database 11g Enterprise Manager supports end-to-end automation of patch application on single-instance database homes and rolling patches on clusterware. You no longer need to perform manual steps for shutting down your system, invoking OPatch, applying SQL, and other such bestpractice steps in the patching procedure.
Oracle Database 11g : New Database Features for Oracle 11g: New Features for Administrators I - 111 Administrators 3 - 111
Setting Up a Test Environment by Using the Snapshot Standby Database In Oracle Database 11g, a physical standby database can be opened temporarily (that is, activated) for read or write activities such as reporting and testing. A physical standby database in the snapshot standby state still receives redo data from the primary database, thereby providing data protection for the primary database while still in the reporting or testing database role. You convert a physical standby database to a snapshot standby database, and you open the snapshot standby database for writes by applications for testing. When you have completed testing, you discard the testing writes and catch up with the primary database by applying the redo logs. Creating a snapshot standby database was possible with the previous releases. However, Oracle Database 11g simplifies greatly the way you set up a snapshot standby database. For more information about snapshot standby databases, refer to the Oracle Data Guard Concepts and Administration Guide. Note: Another important feature is the real-time query capability of physical standby databases in Oracle Database 11g. This feature makes it possible to query a physical standby database while Redo Apply is active.
Benefits of Snapshot Standby A snapshot standby database is a database that is activated from a physical standby database to be used for reporting and testing. The snapshot standby database receives redo from the primary database and continues to provide data protection for the primary database. The snapshot standby database: Is like the primary database in that the users can perform queries or updates Is like a physical standby database in that it continues receiving redo data from the primary database A snapshot standby database provides the combined benefit of disaster recovery and of reporting and testing using a physical standby database. Although similar to storage snapshots, snapshot standby databases provide a single copy of storage while maintaining disaster recovery.
SQL Performance Analyzer: Overview Oracle Database 11g introduces SQL Performance Analyzer, which gives you an exact and accurate assessment of the impact of change on the SQL statements that make up the workload. SQL Performance Analyzer helps you forecast the impact of a potential change on the performance of a SQL query workload. This capability provides DBAs with detailed information about the performance of SQL statements, such as before-and-after execution statistics, and statements with performance improvement or degradation. This enables you (for example) to make changes in a test environment to determine whether the workload performance will be improved through a database upgrade.
SQL Performance Analyzer: Use Cases SQL Performance Analyzer can be used to predict and prevent potential performance problems for any database environment change that affects the structure of the SQL execution plans. The changes can include (but are not limited to) any of the following: Database upgrades Implementation of tuning recommendations Schema changes Statistics gathering Database parameter changes OS and hardware changes DBAs can use SQL Performance Analyzer to foresee SQL performance changes that result from the preceding changes for even the most complex environments. As applications evolve through the development lifecycle, database application developers can test (for example) changes to schemas, database objects, and rewritten applications to mitigate any potential performance impact.
SQL Performance Analyzer also enables the comparison of SQL performance statistics.
Usage Model: Capture SQL Workload The first step to using SQL Performance Analyzer is to capture the SQL statements that represent your workload. This is done using the SQL Tuning Set technology.
Usage Model: Transport to a Test System The second step is to transport these SQL statements to a similar system that is being tested. Here, STS can be exported from production and then imported into a test system.
Usage Model: Build Before Change Performance The third step is to capture a baseline of the test system performance consisting of the execution plan and execution statistics.
Usage Model: Build After Change Performance The fourth step is to make the changes to the test system and then rerun the SQL statements to assess the impact of the changes on the SQL performance.
Usage Model: Compare and Analyze Performance Enterprise Manager provides the tools to make a full comparison of performance data, including execution statistics such as elapsed time, CPU time, and buffer gets. If the SQL performance has regressed in some of the cases, the DBA must then run SQL Tuning Advisor to tune the SQL statementseither immediately or at a scheduled time. As with any tuning strategy, it is recommended that only one change be implemented at a time and retested before making further changes.
SQL Performance Analyzer: Summary 1. Gather SQL: In this phase, you collect the set of SQL statements that represent your SQL workload on the production system. You can use SQL Tuning Sets or Automatic Workload Repository (AWR) to capture the information to transport. Because AWR essentially captures high-load SQLs, you should consider modifying the default AWR snapshot settings and captured Top SQL to ensure that AWR captures the maximum number of SQL statements. This ensures more complete SQL workload capture. 2. Transport: Here you transport the resultant workload to the test system. The STS is exported from the production system and the STS is imported into the test system. 3. Compute before-version performance: Before any changes take place, you execute the SQL statements, collecting baseline information that is needed to assess the impact that a future change might have on the performance of the workload. The information collected in this stage represents a snapshot of the current state of the system workload. The performance data includes: - Execution plans (for example, generated by explain plan) - Execution statistics (for example, includes elapsed time, buffer gets, disk reads, and rows processed) 4. Make a change: After you have the before-version data, you can implement your planned change and start viewing the impact on performance. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 123 Administrators 3 - 123
Capturing the SQL Workload Capturing SQL workload is done using SQL Tuning Sets (STS). This concept is not new in Oracle Database 11g, and it follows exactly the same workflow as with previous releases of the database. This workflow is briefly described in the slide. You can use either Enterprise Manager wizards or the DBMS_SQLTUNE PL/SQL package. With Oracle Database 11g, you access the SQL Tuning Sets page from the Performance tab in Database Control. The workload that you capture should reflect a representative period of time (in captured SQL statements) that you wish to test under some changed condition. The following information is captured in this process: The SQL text The execution context (including bind values, parsing schema, and compilation environment), which contains a set of initialization parameters under which the statement is executed The execution frequency, which tells how many times the SQL statement has been executed during the time interval of the workload Normally the capture SQL happens on the production system to capture the workload running on it. The performance data is computed later on the test system by the compute SQL performance Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 125 Administrators 3 - 125
processes. SQL Performance Analyzer tracks the SQL performance of the same STS before and after a change is made to the database.
Creating a SQL Performance Analyzer Task EM helps you manage each component in the SQL Performance Analyzer process and reports the analysis result. The workflow and user interface apply to both EM Database Control and EM Grid Control. You access SQL Performance Analyzer from the Software and Support tab of Database Control. Alternatively, select Database Instance > Advisor Central > Advisors > SQL Performance Analyzer. SQL Performance Analyzer offers three workflows for you to test different scenarios: Optimizer Upgrade Simulation: Test the effects of specified optimizer version changes on SQL Tuning Set performance. A SQL Performance Analyzer task is created and an initial trial run is performed with the optimizer_features_enable parameter set to an initial value. A second trial run is performed with the optimizer_features_enable parameter set to the targeted version. A replay trial comparison report is then run for the two trials. Parameter Change: Test and compare an initialization parameter change on SQL Tuning Set performance. A SQL Performance Analyzer task is created and an initial trial run is performed with the parameter set to the base value. A second trial run is performed with the parameter set to the changed value. A replay trial comparison report is then run for the two
trials. Guided Workflow: Create a SQL Performance Analyzer task and execute custom experiments by using manually created replay trials.
Optimizer Upgrade Simulation This page enables you to create a task that measures the performance impact on a SQL Tuning Set when the database is upgraded from one version to another. In the example in the slide, the simulated upgrade is done from 10.2.0.1 to 11.1.6. (You can go back to 8.0.0.) To create an analysis task, you must specify the following details: Enter the name of the task and (optionally) a description. Specify the STS to use for this analysis. It must already be created. Select the Per-SQL Time Limit from the list to specify the time limit for the execution of each SQL statement: - UNLIMITED: There is no time limit for the execution of each SQL statement. - EXPLAIN ONLY: The test plan is generated but not executed. - CUSTOMIZE: You can customize the execution time limit. Select the Optimizer Versions to indicate the original version of the database and the new version to which the database is being upgraded. Two replay trials are created. The first captures STS performance with the original optimizer version, and the second uses the targeted version. Select the Comparison Metric to be used to evaluate the performance impact due to the database upgrade.
Specify the Schedule for the task. Click Submit to proceed with the analysis.
SQL Performance Analyzer: Tasks After you create your SQL Performance Analyzer task, it might take a long time for it to be executed depending on the number of statements that are contained in your SQL Tuning Set. While your task is executing, you can click Refresh on the SQL Performance Analyzer page until you see a green tick in the Last Run Status column for your task in the SQL Performance Analyzer Tasks table.
After execution, you can click the link corresponding to the name of your task in the SQL Performance Analyzer Tasks table. This directs you to the corresponding SQL Performance Analyzer Task page.
SQL Performance Analyzer Task Page A SQL Performance Analyzer Task allows you to execute a specific SQL Tuning Set under changed environmental conditions. After you execute the task, you can assess the impact of these changes on the performance of the SQL Tuning Set. The Comparison Report is useful in assessing the impact of the changed environmental conditions on the performance of the specified SQL Tuning Set.
From this page, you can also: Create a Replay Trial to test the performance of a SQL Tuning Set under a specific environment. Click Create Replay Trial. Refer to the Guided Workflow page for detailed information about creating a Replay Trial. Run a Replay Trial Comparison to compare the differences between the Replay Trials that have been created so far. A Comparison Report is generated for each Replay Trial Run. Click Run Replay Trial Comparison. Refer to the Guided Workflow page for detailed information about running a Replay Trial Comparison. Click the eyeglass icon in the Comparison Report column to view the Replay Trial Comparison Report for your task.
Comparison Report Use the SQL Performance Analyzer Task Result page to see the Replay Trial Comparison Report. The following general details are displayed: Task details such as name, owner, and description of the task Name and owner of the SQL Tuning Set Total number of SQL statements and any SQL statements with errors. Click the SQL Statements With Errors link to access the Errors table. The Replay Trials being compared and comparison metric being used In addition to these details, you can view the following: Projected Workload [Comparison Metric]: This chart shows the projected workload for each Replay Trial based on the comparison metric along with the improvement, regression, and overall impact. Click the impact links to drill down to the complete list of SQL statements in each category. SQL Statement Count: This chart shows the number of SQL statements that have improved, regressed, or not changed performance based on the comparison metric. The colors of the bars indicate whether the plan changed between the two trial runs. Click the links or the data buckets to access the SQL Statement Count Details page, where you can see a list of SQL statements, and then click a SQL ID to access the SQL details.
Top 10 SQL Statements Based on Impact on Workload table: This table allows you to click a specific SQL ID to drill down to the corresponding SQL Details page.
Comparison Report (continued) On the SQL Details page, you can view the SQL statements and a line-by-line comparison between each Replay Trial Run for each statistic. You can also find the explain plan for each trial.
Tuning Regressing Statements From the SQL Performance Analyzer Task Result page, you can directly tune all regressing statements by invoking SQL Tuning Advisor. To do so, click the Run SQL Tuning Advisor button to access the Schedule SQL Tuning Task page, where you can specify the tuning task name and a schedule. When you are finished, click OK. This creates a new tuning task that analyzes all regressing statements found by SQL Performance Analyzer.
Tuning Regressing Statements (continued) After the SQL tuning task is created, you return to the SQL Performance Analyzer Task Result page, where you can clearly see (in the Recommendations section) that you now have a tuning task associated with your performance analysis. Click the SQL Tune Report link to access the corresponding SQL Tuning Results page, where you can see the Recommendations table that lists all recommendations for regressing statements. You can also access the SQL Tuning Results page directly from the SQL Performance Analyzer Task page by clicking the eyeglass icon in the SQL Tune Report column of the Replay Trial Comparisons section for your trial comparison.
Preventing Regressions Instead of using SQL Tuning Advisor to tune your regressing statements, you can also prevent regressions by using the SQL plan baselines. You can do so from the SQL Performance Analyzer Task Result page by clicking the Create SQL Plan Baselines button. Note: For more information about SQL plan baselines, refer to the lesson titled SQL Plan Manageability.
Parameter Change Analysis Use the Parameter Change page to create a task that allows you to test the performance impact on a SQL Tuning Set when the value of the initialization parameter is changed. This option is very useful because it is difficult to forecast whether changing the parameter value will have a positive or negative impact. To create a task, do the following: Enter the name of the task and a description. Click the Select icon and select a SQL Tuning Set from the list. Select the Per-SQL Time Limit from the list to specify the time limit for the execution of each SQL statement. Click the Select icon to select an initialization parameter from the list. Specify the current value (Base Value) and the new value (Changed Value) for the initialization parameter. Select the comparison metric that will be used to evaluate the performance impact due to the change. Specify the schedule for the task. After the task has been created, an initial trial run is performed with the initialization parameter set to the Base Value. A second trial run is performed with the initialization parameter set to the
Changed Value. Finally, a Replay Trial Comparison report is generated for the two trials with the specified comparison metric.
Guided Workflow Analysis You can use the Guided Workflow page to define a sequence of steps to execute a two-trial SQL Performance Analyzer test. The steps are as follows: Create a SQL Performance Analyzer task based on a SQL Tuning Set. Replay the SQL Tuning Set in the initial environment: Any changes to the trial environment that affect the STS must be made manually before the Replay Trial is executed. These trials may include changing initialization parameters, gathering optimizer statistics, and creating indexes. Create the Replay Trial using the changed environment: You can now create the second Replay Trial using the changed environment by specifying all the necessary information. Performance differences between the trials are attributed to the environmental differences. Create the Replay Trial Comparison using trials from previous steps: This allows you to assess the performance impact on the STS when each Replay Trial is executed. View the Trial Comparison Report: You can now generate the Replay Trial Comparison report. Note: Before submitting a replay trial, you must select the Trial environment established option on the corresponding task page. However, you must manually make the necessary changes.
SQL Performance Analyzer: PL/SQL Example The general example in the slide shows you how to use the DBMS_SQLPA package to invoke SQL Performance Analyzer to access the SQL performance impact of some changes. You could easily adapt this example to run your own analysis. 1. Create the tuning task to run SQL Performance Analyzer. 2. Execute the task once to build the before-change performance data, and produce the before- change report (special settings for report: set long 100000, longchunksize 100000, and linesize 90). With this call, you can specify various parameters, some of which are: - Set the execution_type parameter in either of the following ways: Set to EXPLAIN PLAN to generate explain plans for all SQL statements in the SQL workload. Set to TEST EXECUTE to execute all SQL statements in the SQL workload. The procedure executes only the query part of the DML statements to prevent side-effects to the database or user data. When TEST EXECUTE is specified, the procedure generates execution plans and execution statistics. - Specify execution parameters by using the execution_params parameter that needs to be specified as dbms_advisor.arglist(name,value,). The time_limit parameter specifies the global time limit to process all SQL statements in a SQL Tuning Set before timing out. The local_time_limit Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 137 Administrators 3 - 137
parameter specifies the time limit to process each SQL statement in a SQL Tuning Set before timing out.
SQL Performance Analyzer: Data Dictionary Views DBA{USER}_ADVISOR_SQLPLANS: Displays the list of all SQL execution plans (or those owned by the current user) DBA{USER}_ADVISOR_SQLSTATS: Displays the list of SQL compilation and execution statistics (or those owned by the current user) DBA{USER}_ADVISOR_TASKS: Displays details about the advisor task created to perform an impact analysis of a system environment change DBA{USER}_ADVISOR_EXECUTIONS: Lists metadata information for a task execution. SQL Performance Analyzer creates a minimum of three executions to perform a change impact analysis on a SQL workload: one execution to collect performance data for the before-change version of the workload, the second execution to collect data for the afterchange version of the workload, and a final execution to perform the actual analysis. DBA{USER}_ADVISOR_FINDINGS: Displays analysis findings. The advisor generates four types of findings: performance regression, symptoms, errors, and informative messages.
SQL Plan Management: Overview Potential performance risk occurs when the SQL execution plan changes for a SQL statement. A SQL plan change can occur due to a variety of reasons like optimizer version, optimizer statistics, optimizer parameters, schema definitions, system settings, and SQL profile creation. Various plan control techniques (such as stored outlines and SQL profiles) have been introduced in the past versions of Oracle Database to address performance regressions due to plan changes. However, these techniques are reactive processes that require manual intervention. SQL Plan Management is a new feature introduced with Oracle Database 11g that enables the system to automatically control SQL plan evolution by maintaining what is called SQL plan baselines. With this feature enabled, a newly generated SQL plan can integrate a SQL plan baseline only if it has been proven that doing so will not result in performance regression. So, during execution of a SQL statement, only a plan that is part of the corresponding SQL plan baseline can be used. As described later in this lesson, SQL plan baselines can be automatically loaded or can be seeded using SQL Tuning Sets. Various scenarios are covered later in this lesson.
The main benefit of the SQL Plan Management feature is the performance stability of the system through the avoidance of plan regressions. In addition, it saves the DBA time that is often spent in identifying and analyzing SQL performance regressions and finding workable solutions.
SQL Plan Baseline: Architecture The SQL Plan Management (SPM) feature introduces necessary infrastructure and services in support of plan maintenance and performance verification of new plans. For SQL statements that are executed more than once, the optimizer maintains a history of plans for individual SQL statements. The optimizer recognizes a repeatable SQL statement by maintaining a statement log. A SQL statement is recognized as repeatable when it is parsed or executed again after it has been logged. After a SQL statement is recognized as repeatable, various plans generated by the optimizer are maintained as a plan history containing relevant information (such as SQL text, outline, bind variables, and compilation environment) that is used by the optimizer to reproduce an execution plan. As an alternative or complement to the automatic recognition of repeatable SQL statements and the creation of their plan history, manual seeding of plans for a set of SQL statements is also supported. A plan history contains different plans generated by the optimizer for a SQL statement over time. However, only some of the plans in the plan history may be accepted for use. For example, a new plan generated by the optimizer is not normally used until it has been verified not to cause a performance regression. Plan verification is done out of the box as part of Automatic SQL Tuning running as an automated task in a maintenance window. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 145 Administrators 4 - 145
Loading SQL Plan Baselines There are two ways to load SQL plan baselines. On the fly capture: Uses automatic plan capture by setting the initialization parameter OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES to TRUE. This parameter is set to FALSE by default. Setting it to TRUE turns on automatic recognition of repeatable SQL statements and automatic creation of plan history for such statements. This is illustrated in the left graphic in the slide, where you can see the first generated SQL plan automatically integrated into the original SQL plan baseline. Bulk loading: Uses the DBMS_SPM package, which enables you to manually manage SQL plan baselines. With this package, you can load SQL plans into a SQL plan baseline directly from the cursor cache or from an existing SQL Tuning Set (STS). For a SQL statement to be loaded into a SQL plan baseline from an STS, the SQL statement needs to store its SQL plan in the STS. DBMS_SPM enables you to change the status of a baseline plan from accepted to not accepted (and from not accepted to accepted). It also enables you to export baseline plans from a staging table, which can then be used to load SQL plan baselines on other databases.
Evolving SQL Plan Baselines During the SQL plan baseline evolution phase, Oracle Database routinely evaluates the performance of new plans and integrates plans with better performance into SQL plan baselines. When the optimizer finds a new plan for a SQL statement, the plan is added to the plan history as a nonaccepted plan. The plan is then verified for performance relative to the SQL plan baseline performance. When it is verified that a nonaccepted plan does not cause a performance regression (either manually or automatically), the plan is changed to an accepted plan and integrated into the SQL plan baseline. Successful verification of a nonaccepted plan consists of comparing its performance to that of one plan selected from the SQL plan baseline and ensuring that it delivers better performance. There are two ways to evolve SQL plan baselines: By using the DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE function. An invocation example is shown in the slide. The function returns a report that tells you whether some of the existing history plans were moved to the plan baseline. You can also specify specific plans in the history to be tested. By running SQL Tuning Advisor: SQL plan baselines can be evolved by manually or automatically tuning SQL statements using SQL Tuning Advisor. When SQL Tuning Advisor finds a tuned plan and verifies its performance to be better than a plan chosen from
the corresponding SQL plan baseline, it makes a recommendation to accept a SQL profile. When the SQL profile is accepted, the tuned plan is added to the corresponding SQL plan baseline.
Important Baseline SQL Plan Attributes When a plan enters the plan history, it is associated with a number of important attributes: SIGNATURE, SQL_HANDLE, SQL_TEXT, and PLAN_NAME are important identifiers for search operations. ORIGIN allows you to determine whether the plan was automatically captured (AUTOCAPTURE), manually evolved (MANUAL-LOAD), automatically evolved by SQL Tuning Advisor (MANUAL-SQLTUNE), or automatically evolved by Automatic SQL Tuning (AUTO-SQLTUNE). ENABLED and ACCEPTED: The ENABLED attribute means that the plan is enabled for use by the optimizer. If ENABLED is not set, the plan is not considered. The ACCEPTED attribute means that the plan was validated as a good plan, either automatically by the system or manually when the user changes it to ACCEPTED. When a plan changes to ACCEPTED, it will become not ACCEPTED only when DBMS_SPM.ALTER_SQL_PLAN_BASELINE() is used to change its status. An ACCEPTED plan can be temporarily disabled by removing the ENABLED setting. A plan must be ENABLED and ACCEPTED for the optimizer to consider using it. FIXED means that the optimizer considers only those plans and not other plans. For example, if you have 10 baseline plans and three of them are marked FIXED, the optimizer uses only the best plan from these three, ignoring all the others. A SQL plan baseline is said Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 149 Administrators 4 - 149
to be FIXED if it contains at least one enabled fixed plan. If new plans are added to a fixed SQL plan baseline, these new plans cannot be used until they are manually declared as FIXED.
SQL Plan Selection If you are using automatic plan capture, the first time that a SQL statement is recognized as repeatable, its best-cost plan is added to the corresponding SQL plan baseline. That plan is then used to execute the statement. The optimizer uses a comparative plan selection policy when a plan baseline exists for a SQL statement and the initialization parameter OPTIMIZER_USE_SQL_PLAN_BASELINES is set to TRUE (default value). Each time a SQL statement is compiled, the optimizer first uses the traditional cost-based search method to build a best-cost plan. Then it tries to find a matching plan in the SQL plan baseline. If a match is found, it proceeds as usual. If no match is found, it first adds the new plan to the plan history, then costs each of the accepted plans in the SQL plan baseline, and picks the one with the lowest cost. The accepted plans are reproduced using the outline that is stored with each of them. So the effect of having a SQL plan baseline for a SQL statement is that the optimizer always selects one of the accepted plans in that SQL plan baseline. With SQL Plan Management, the optimizer can produce a plan that could be either a best-cost plan or a baseline plan. This information is dumped in the other_xml column of the plan_table upon explain plan. In addition, you can use the new dbms_xplain.display_sql_plan_baseline Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 151 Administrators 4 - 151
function to display one or more execution plans for the specified sql_handle of a plan baseline. If plan_name is also specified, the corresponding execution plan is displayed.
Possible SQL Plan Manageability Scenarios Database upgrade: Bulk SQL plan loading is especially useful when the system is being upgraded from an earlier version to Oracle Database 11g. For this, you can capture plans for a SQL workload into a SQL Tuning Set (STS) before the upgrade, and then load these plans from the STS into the SQL plan baseline immediately after the upgrade. This strategy can minimize plan regressions resulting from the use of the new optimizer version. New application deployment: The deployment of a new application module means the introduction of new SQL statements into the system. The software vendor can ship the application software along with the appropriate SQL plan baselines for the new SQL being introduced. Because of the plan baselines, the new SQL statements will initially run with the plans that are known to give good performance under a standard test configuration. However, if the customer system configuration is very different from the test configuration, the plan baselines can be evolved over time to produce better performance. In both scenarios, you can use the automatic SQL plan capture after manual loading to make sure that only better plans will be used for your applications in the future. Note: In all scenarios in this lesson, assume that OPTIMIZER_USE_SQL_PLAN_BASELINES is set to TRUE.
SQL Performance Analyzer and SQL Plan Baseline Scenario A variation of the first method described in the previous slide is through the use of SQL Performance Analyzer. You can capture preOracle Database 11g plans in an STS and import them into Oracle Database 11g. Then set the initialization parameter optimizer_features_enable to 10g to make the optimizer behave as if this were a 10g Oracle database. Next run SQL Performance Analyzer for the STS. When that is complete, set the initialization parameter optimizer_features_enable back to 11g and rerun SQL Performance Analyzer for the STS. SQL Performance Analyzer produces a report that lists a SQL statement whose plan has regressed from 10g to 11g. For those SQL statements that are shown by SQL Performance Analyzer to incur performance regression due to the new optimizer version, you can capture their plans using an STS and then load them into the SMB. This method represents the best form of the plan-seeding process because it helps prevent performance regressions while preserving performance improvements upon database upgrade.
Loading a SQL Plan Baseline Automatically: Scenario Another upgrade scenario involves using the automatic SQL plan capture mechanism. In this case, set the initialization parameter OPTIMIZER_FEATURES_ENABLE (OFE) to the pre Oracle Database 11g version value for an initial period of time such as a quarter, and execute your workload after upgrade by using the automatic SQL plan capture. During this initial time period, because of the OFE parameter setting, the optimizer is able to reproduce preOracle Database 11g plans for a majority of the SQL statements. Because automatic SQL plan capture is also enabled during this period, the preOracle Database 11g plans produced by the optimizer are captured as SQL plan baselines. When the initial time period ends, you can remove the setting of OFE to take advantage of the new optimizer version while incurring minimal or no plan regressions due to the plan baselines. Regressed plans will use the previous optimizer version; nonregressed statements will benefit from the new optimizer version.
Purging SQL Management Base Policy The space occupied by the SQL Management Base (SMB) is checked weekly against a defined limit. A limit based on the percentage size of the SYSAUX tablespace is defined. By default, the space budget limit for the SMB is set to 10 percent of SYSAUX size. However, you can configure SMB and change the space budget to a value between 1 percent and 50 percent by using the DBMS_SPM.CONFIGURE procedure.
If SMB space exceeds the defined percent limit, warnings are written to the alert log. Warnings are generated weekly until the SMB space limit is increased, the size of SYSAUX is increased, or the size of SMB is decreased by purging some of the SQL management objects (such as SQL plan baselines or SQL profiles). The space management of SQL plan baselines is done proactively using a weekly purging task. The task runs as an automated task in the maintenance window. Any plan that has not been used for more than 53 weeks is purged. However, you can configure SMB and change the unused plan retention period to a value between 5 weeks and 523 weeks (a little more than 10 years). To do so, use the DBMS_SPM.CONFIGURE procedure. You can look at the current configuration settings for the SMB by examining the DBA_SQL_MANAGEMENT_CONFIG view. In addition, you can manually purge the SMB by using the DBMS_SPM.DROP_SQL_PLAN_BASELINE function (as shown in the example in
the slide).
Enterprise Manager and SQL Plan Baselines Use the SQL Plan Management page to manage SQL profiles, SQL patches, and SQL plan baselines from one location rather than separate locations in Enterprise Manager. You can also enable, disable, drop, pack, unpack, load, and evolve selected baselines. From this page, you can also configure the various SQL plan baseline settings.
Why Use Database Replay? Large business-critical applications are complex and experience highly varying load and usage patterns. At the same time, these business systems are expected to provide certain service-level guarantees in terms of response time, throughput, uptime, and availability. Often any change to a system, such as upgrading the database or modifying the configuration, necessitates extensive testing and validation before these changes can make it to the production system. To be confident before moving to a production system, the DBA needs to expose a test system to a workload very similar to the workload to be experienced in a production environment. It is also beneficial for the DBA to have an effective means of analyzing the impact of system-level changes on overall SQL performance so that any tuning changes required can be performed before production.
Database Replay Oracle Database 11g provides specific solutions to the challenges described in the preceding slides. Database Replay allows you to test the impact of a system change by replaying real-world workload on the test system before it is exposed to a production system. The production workload (including transaction concurrency and dependency) of the database server is recorded over an illustrative period of time (for example, a peak period). This recorded data is used to replay the workload on a test system that has been appropriately configured. You gain a high degree of confidence in the overall success of the database change by subjecting the database server in a test system to a workload that is practically indistinguishable from a production workload.
System Architecture: Capture Here you see an illustration of a system that is being recorded. You should always record a workload that spans an interesting period in a production system. Typically, the replay of the recording is used to determine whether it is safe to upgrade to a new version of the RDBMS server. A special recording infrastructure built into the RDBMS records data about all external client requests while the production workload is running on the system. External requests are any SQL queries, PLSQL blocks, PLSQL remote procedure calls, DML statements, DDL statements, Object Navigation requests, or OCI calls. During the recording, background jobs and, in general, all internal clients continue their work without being recorded. The end product is a workload recording containing all necessary information for replaying the workload as seen by the RDBMS in the form of external requests. The recording infrastructure imposes minimal performance overhead (extra CPU, memory, and I/O) on the recording system. You should, however, plan to accommodate the additional disk space needed for the actual workload recording. RAC Note: Instances in a RAC environment have access to the common database files. However, they do not need to share a common general-purpose file system. In such an environment, the workload recording is written on each instances file system during recording. For processing and replay, all parts of the workload recording need to be manually copied into a
single directory.
System Architecture: Processing the Workload The workload capture data is processed, and new workload replay-specific metadata files are created that are required for the replay of the given workload capture. Only new files are created; no files are modified that were created during the workload capture. Because of this, you can run the preprocess multiple times on the same capture directory (for example, when the procedure encounters unexpected errors or is canceled).
External client connections are remapped at this stage. Any replay parameters that affect the replay outcome can be modified. Note: Because processing workload capture can be relatively expensive, the best practice is to do that operation on a system other than the production database system.
System Architecture: Replay Before replaying the workload on the replay system, be sure to do the following: 1. Restore the replay database on a test system to match the capture database at the start of the workload capture. 2. Make changes (such as performing an upgrade) to the test system as needed. 3. Copy the workload to the test system.
The workload recording is consumed by a special application called the replay driver, which sends requests to the RDBMS on which the workload is replayed. The RDBMS on which the workload is replayed is usually a test system. It is assumed that the database of the replay system is suitable for the replay of the workload that was recorded. The internal RDBMS clients are not replayed. The replay driver is a special client that consumes the workload recording and sends appropriate requests to the test system to make it behave as if the external requests were sent by the clients used during the recording of the workload (see previous example). The use of a special driver that acts as the sole external client to the RDBMS enables the record-and-replay infrastructure to be client agnostic. The replay driver consists of one or more clients that connect to the replay system and the replay driver sends requests based on the workload capture. The replay driver equally distributes the workload capture streams among all the replay clients based on the network bandwidth, CPU,
and memory capability.
The Big Picture With Oracle Database 11g managing system changes, a significant benefit is the added confidence to the business in the success of performing the change. The record-and-replay functionality offers confidence in the ease of upgrade during a database server upgrade. A useful application of Database Replay is to test the performance of a new server configuration. Consider a customer who is utilizing a single instance database and wants to move to a RAC setup. The customer records the workload of an interesting period and then sets up a RAC test system for replay. During replay, the customer is able to monitor the performance benefit of the new configuration by comparing the performance to the recorded system. This can also help convince the customer to move to a RAC configuration after seeing the benefits of using the Database Replay functionality. Another application is debugging. You can record and replay sessions emulating an environment to make bugs more reproducible. Manageability feature testing is another benefit. Self-managing and self-healing systems need to implement this advice automatically (autonomic computing model). Multiple replay iterations allow testing and fine-tuning of the control strategies effectiveness and stability. Many Oracle customers have expressed strong interest in this change-assurance functionality. The database administrator, or a user with special privileges granted by the DBA, initiates the Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 169 Administrators 5 - 169
record-and-replay cycle and has full control over the entire procedure.
Pre-Change Production System Database Replay focuses on recording and replaying the workload that is directed to the RDBMS. Therefore, recording the workload is done at the point indicated in the diagram in the slide. Recording at the RDBMS in the software stack makes it possible to exchange anything below this level and test the new setup using the record-and-replay functionality. While replaying the workload, the RDBMS performs the actions observed during recording. In other words, during the replay phase the RDBMS code is exercised in a way that is very similar to the way it was exercised during the recording phase. This is achieved by re-creating all external client requests to the RDBMS. External client requests include all the requests by all possible external clients of the RDBMS.
Supported Workloads The slide shows supported and nonsupported database operations.
Capture Considerations You perform the following tasks in the planning phase of the workload recording: Check the database backup strategy, ensuring that the database can be restored to StartSCN when the recording starts. Plan the capture period by selecting it based on the application and the peak periods. You can use existing manageability features such as Automatic Workload Repository (AWR) and Active Session History (ASH) to select an appropriate period based on workload history. The starting time for capture should be carefully planned because it is recommended that you shut down and restart the database before starting the capture. Specify the location of the workload capture data. You must set up a directory that is to be used to store the workload capture data. You should provide ample disk space because the recording stops if there is insufficient disk space. However, everything captured up to that point is usable for replay. Define capture filters for user sessions that are not to be captured. You can specify a recording filter to skip sessions that should not be captured. No new privileges or user roles are introduced with the Database Replay functionality. The recording user and replay user must have either the SYSDBA or SYSOPER privilege. This is because a user having only SYSOPER or SYSDBA can start up or shut down the database to start the recording. Correct operating system (OS) privileges should also be assigned so Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 172 Administrators 5 - 172
that the user is able to access the recording, replay directories, and manipulate the files under those directories.
Replay Considerations The preprocess phase is a once-only required action for the specified database version. After the necessary metadata has been created, you can replay the workload as many times as required. You must restore the replay database to match the capture database at the start of the workload capture. A successful replay depends on the application transactions accessing the application data identical to that on the capture system. You can choose to restore the application data using point-in-time recovery, flashback, and import/export.
Replay Considerations (continued) A captured workload may contain references to external systems that are meaningful only in the capture environment. Replaying a workload with unresolved references to external systems may cause unexpected problems in the production environment. A replay should be performed in a completely isolated test environment. You should make sure that all references to external systems have been resolved in the replay environment such that replaying a workload will cause no harm to your production environment. You can make one-to-one or many-to-one remappings. For example, database links in a captured production environment may reference external production databases that should not be referenced during replay. Therefore, you should modify any external references that could jeopardize the production environment during replay. The replay client (an executable named wrc) submits a captured sessions workload. You should install one or more replay clients, preferably on systems other than the production host. Each replay client must be able to access the directory that holds the preprocessed workload. You can also modify the replay parameters to change the behavior of the replay.
Replay Options The following replay options can be modified while replaying your workload: The synchronization parameter determines whether synchronization will be used during workload replay. If this parameter is set to TRUE, the COMMIT order in the captured workload will be preserved during replay and all replay actions will be executed only after all dependent COMMIT actions have completed. The default value is TRUE. The think_time_scale parameter scales the elapsed time between two successive user calls from the same session; it is interpreted as a percentage value. Use this parameter to increase or decrease the replay speed. Setting this parameter to 0 will send user calls to the database as fast as possible during replay. The default value is 100. The think_time_auto_correct parameter corrects the think time (based on the think_time_scale parameter) between calls, when user calls take longer to complete during replay than during capture. It is interpreted as a percentage value. The connect_time_scale parameter scales the elapsed time from when the workload capture started to when the session connects with the specified value; it is interpreted as a percentage. Use this option to manipulate the session connect time during replay. The default value is 100. Note: During workload capture, elapsed time is measured by user time and user think time. User time is the elapsed time of a user call to the database. User think time is the elapsed time while Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 175 Administrators 5 - 175
the user waits between issuing calls. During workload replay, elapsed time is measured by user time, user think time, and synchronization time.
Replay Analysis There may be some divergence of the replay compared to what was recorded. For example, when replaying on a newer version of the RDBMS, a new algorithm may cause specific requests to be faster, resulting in divergence appearing as a faster execution. This is considered a desirable divergence. Another example of a divergence is when a SQL statement returns fewer rows during replay than those returned during recording. This is clearly undesirable.
For data divergence, the result of an action can be considered as: The result set of SQL query An update to persistent database state A return code or error code Performance divergence is useful in determining how new algorithms introduced in the replay system may affect overall performance. There are numerous factors that can cause replay divergence. Though some of them cannot be controlled, others can be mitigated. It is the task of the DBA to understand the workload run-time operations and take the necessary actions to reduce the level of record-and-replay divergence. Online divergence should aid the decision to stop a replay that has diverged significantly. The results of the replay before the divergence may still be useful, but further replay would not produce reliable conclusions. Offline divergence reporting is used to determine how successful
the replay was after the replay has finished.
Database Replay Workflow in Enterprise Manager The following are the typical steps to perform Database Replay. Steps done with Enterprise Manager (EM) are marked as Task n. Other steps are not part of the EM workflow: 1. Capture the workload on a database. (Task 1) 2. Optionally export the AWR data. (Task 1) 3. Restore the replay database on a test system to match the capture database at the start of the workload capture. 4. Make changes (such as performing an upgrade) to the test system as required. 5. Copy the generated workload files to the test system. 6. Preprocess the captured workload on the test system. (Task 2) 7. Configure the test system for the replay. 8. Replay the workload on the restored database. (Task 3)
Capturing Workload with Enterprise Manager Enterprise Manager (EM) provides you with a user interface to manage each component in the Database Replay process. The workflow and user interface applies to both EM Database Control and EM Grid Control. You access Database Replay on the Software and Support tab of Database Control. On the Database Replay page, you can perform the following named tasks: Capture Workload Preprocess Capture Workload Replay Workload View Workload Capture History: Click this link to view or delete the history of all workload captures. Active Capture and Replay: If a capture or replay is currently in progress, this table appears at the bottom of the page even if there are no rows. To view the status of the capture or replay, select the name and click View, or just click the Name link. RAC Note: When an instance goes down during capture of a RAC system, the capture continues normally and is not aborted. The sessions that died as a result of an instance going down will be replayed up to the point at which the instance died. When a dead instance is repaired and comes up again during capture, all new sessions are recorded normally. During replay, the death of Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 179 Administrators 5 - 179
instances is not replayed.
Using the Capture Wizard On the Capture Workload: Plan Environment page, select each of the Acknowledge check boxes after you have met the prerequisites. If you do not handle the prerequisites, the following problems can occur: Not restarting the database could capture in-flight transactions, which may adversely affect the replay of subsequent captured transactions. The captured workload will be written to the file system and can use up all the available disk space. The chance of error and data divergence increases if application data does not match at the start of capture and replay. When you are finished, click Next to proceed with the rest of the wizard. Note: You can choose to restart the database before capture begins. Be sure that all other database activities can be temporarily stopped.
Using the Capture Wizard (continued) On the Capture Workload: Options page, you can do the following: Choose whether to restart the database before starting capture. You do this in the Database Restart Options section. If the database is not restarted before capture begins, some database activities may not be captured accurately and completely. During replay, these incompletely captured activities may cause the replay database state to diverge from the capture database. The replay reports errors in these cases. Define workload filters in the Workload Filters section. Decide whether you want to include or exclude certain sessions, and then provide filter names, corresponding session attributes, and values. Selecting Inclusion as the filter mode captures only what you specify, and selecting Exclusion captures everything except what you specify. You can either include or exclude certain sessions, but you cannot do both at the same time. The default filter names exclude Enterprise Manager activities. The Value column represents the actual name for the session attribute, whereas you can provide any filter name desired. When you are finished, click Next to proceed with the rest of the wizard.
Using the Capture Wizard (continued) On the Capture Workload: Parameters page, you can either provide your own required capture name or accept the system-supplied name. Select a directory object name from the list of existing directory objects defined in the system, or click Create Directory Object to specify a unique name and path for a new directory object. This directory is used to generate the capture files. Then click Next. This takes you to the Capture Workload: Schedule page, where you can either provide your own required job name or accept the system-supplied name. The job system automatically names the job in uppercase. The job and capture names do not have to match. If you schedule the job immediately and if you specified restarting the database in the Options step, the Information: Restart Database page appears after you submit the job in the Review step, and then the View Workload Capture page appears. If you schedule the job for a later time with or without a restart, the Database Replay page appears with a message notifying you that a job has been scheduled after you submit the job in the Review step. If you do not specify a capture duration, you must manually stop capture by clicking the Stop button on the Database Replay page while capture is in progress. You can also stop capture on the View Workload Capture page. Click Next to go to the Review page, where you can verify that the settings are as you intended before you submit the job. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 182 Administrators 5 - 182
RAC Note: For RAC, the DBA should define the directory for captured data at a storage location accessible by all instances. Otherwise, the workload capture data needs to be copied from all locations to a single location before starting the processing of the workload recording.
Using the Capture Wizard (continued) The slide illustrates the case in which you schedule the capture job immediately, do not specify restarting the database in the Options step, and do not indicate a capture duration. Capture is now in effect, and you must manually stop capture by clicking the Stop Capture button on the View Workload Capture page. At this point, you must run your workload.
Using the Capture Wizard (continued) Use the View Workload Capture page to see the progress of a workload capture that you have initiated, or to see historical information about the capture after it has completed execution. This page is available from the Active Capture and Replay table on the Database Replay home page, from the View Capture History page (for a completed capture), or after a nonscheduled capture job is submitted.
This page has the following elements: The Summary section gives you important information regarding the current workload capture. Use the Stop Capture button while capture is in progress. The Workload Profile subpage provides several performance-related totals for the capture. Click View Workload Capture Report to invoke a browser window to display the report. The report contains detailed information about the capture. The Comparison table compares the entire system with what has been captured. The Total column shows cumulative values for the system after you started the capture, and the Capture column shows the portion of these values that the capture yielded during the same period of time. The Workload Filters subpage shows the workload filters that you set up in the Options step of the Capture Workload Wizard.
When your workload is finished, click Stop Capture.
Using the Capture Wizard (continued) When you confirm that you want to stop your workload capture, you are asked whether you want to export AWR data. If you accept, the wizard generates an export job and automatically generates a dump file that contains AWR data for the capture period. This dump file is generated in the capture directory that you previously used to generate workload capture files. If you choose not to export AWR data or if the job is not yet done, the Export AWR Data button becomes available. When you click this button, a confirmation page is displayed. After confirmation, the export runs in the background and you return to the View Workload Capture page.
Viewing Workload Capture History Use the View Workload Capture History page to: Obtain an overview of all completed workload capture jobs ever performed on this database, except for capture jobs that have been deleted Delete one or more entries from the list of completed workload capture jobs Access more detailed information about a workload capture job by selecting the capture name and clicking View (or clicking the Capture Name link) Export AWR data A green check mark appears for a capture name in the AWR Data Exported column if AWR data has already been exported. Otherwise, the column has an X. To export data for a capture name with an X, select the name and click Export AWR Data. When the export is finished, a check mark appears in the column.
Processing Captured Workload Use the Preprocess Captured Workload page to: Select a directory object that contains a captured workload View historical information about the completed capture before you begin to preprocess the workload. This page contains the Capture Summary and Capture Details sections. The Workload Profile and Workload Filters subpages are accessed in the Capture Details section. When you have selected your directory and reviewed the capture details, click Preprocess Workload to invoke the Preprocess Captured Workload Wizard. RAC Note: In a RAC setup, one database instance of the preprocessing system is selected for processing the workload recording. If recorded data was written to a local file system for nodes in the RAC, the recorded data files from all the nodes in the RAC should first be copied to the directory for the instance on which the preprocessing is to be done. If the captured data is stored in a shared file system, copying is not necessary.
Using the Preprocess Captured Workload Wizard The slide describe the preprocess flow: Database Version: This step reminds you that the current database version must be the same as the database where you want to replay the captured workload. If the database versions are not the same, you can continue to the next step but the preprocessed workload may not replay correctly on a later major version of the database. Schedule: This page is a typical Enterprise Manager schedule page on which you must specify a job name, credentials, and a start time. Review: On this page, review the information you provided and click Submit to trigger the preprocessing job. This takes you back to the Database Replay home page, where you can see a Confirmation message pointing to the generated job.
Using the Replay Workload Wizard You are now again on the Database Replay home page. Click the Replay Workload icon to access the Replay Workload page, where you can: Specify the directory object that contains the preprocessed workload View capture information about the preprocessed workload View the replay history, if any, of the preprocessed workload
This page contains the Capture Summary and Capture Details sections. The Workload Profile and Workload Filters subpages are accessed in the Capture Details section. When ready, click Set Up Replay.
Using the Replay Workload Wizard (continued) Before entering the replay phase, the following items should be completed: Restore Database: Restore the replay database to match the capture database at the start of the workload capture. A successful workload replay depends on the application transactions accessing the application data identical to that on the capture system. Common ways to restore application data state include point-in-time recovery, flashback, and import/export. Perform System Changes: You should make any desired changes to the replay system, including any database or system upgrade, prior to replay. The primary purpose of Database Replay is to test the effect of system changes on a real captured application workload. Therefore, the changes you make, combined with the captured workload, define the test you are conducting. Resolve References to External Systems: A captured workload may contain references to external systems that may be meaningful only in the capture environment. For example, database links in a captured production environment may reference external production databases that should not be referenced during replay. In such a case, you should modify any external references that could jeopardize the production environment during replay. The Replay Workload: References to External Systems page helps you resolve these issues. Set Up Replay Clients: The replay client is a multithreaded program (an executable named wrc) where each thread submits a captured sessions workload. This program is
made available as part of the standard Oracle Client as well as the Oracle Instant Client. You should install one or more replay clients, preferably on systems other than the database host. In addition, each replay client must be able to access the directory that holds the preprocessed workload.
Using the Replay Workload Wizard (continued) On the Replay Workload: Choose Initial Options page, accept the default Replay Name, or provide your own. You can either select the default replay or use replay options from a previous replay. Initial replay options refer to the connection mappings and parameters on the Customize Options page. Connections are captured along with the workload. On the Replay Workload: Customize Options page, you can use the Connection Mappings subpage to conveniently use a single descriptor for all connections, either as a prepopulated string or as an alias name that maps to the descriptor string. You can also select a separate connect descriptor option that enables you to specify a unique descriptor for each connection. If you selected the Use replay options from a previous replay option in the Choose Initial Options step, the Use a separate connect descriptor option is selected and the previous replay system values appear in the table. RAC Note: The remapping of external interactions should include the remapping of instances. In particular, every captured connection string probably needs to be remapped to a connection string in the replay system. If the capture system is a single instance database and the replay system is also a single instance database, the remapping of the connection string is straightforward and involves adding the appropriate entry to the configuration file. The same is valid when both the capture and the replay systems are RAC databases with the same number of
nodes. Remapping becomes more complicated if the capture and replay systems have different numbers of nodes.
Using the Replay Workload Wizard (continued) The Replay Parameters subpage provides advanced parameters that control some aspects of the replay. You saw those parameters on the Replay Options slide in this lesson.
Using the Replay Workload Wizard (continued) Workload is replayed using replay clients connected to the database. When you reach the Replay Workload: Prepare Replay Clients page, you should be ready to start the replay clients. Click Next. This takes you to the Replay Workload: Wait for Client Connections page. The text below the clock changes if a replay client is connected. The Client Connections table is populated when at least one replay client is connected.
Using the Replay Workload Wizard (continued) The Replay Workload Wizard waits for you to start the replay clients. You open separate terminal windows to start the replay clients by using the wrc executable. You can start multiple replay clients depending on the workload replay size. Each of the clients initiates one or more replay threads with the database, with each replay thread corresponding to a stream from the workload capture. Here is a brief description of the syntax used by wrc. The userid and password parameters are the user ID and password of the replay user for the client. The server parameter is a connection string that connects to the instance of the replay system. The replaydir parameter points to the directory that contains the processed replay files. The workdir parameter defines the clients working directory; if left unspecified, it defaults to the current directory. Check the following before starting the replay clients: The replay client software is installed on the hosts. The client has access to the replay directory. The replay directory has the replay files that have been preprocessed. The userid and password for the replay user are correct. Furthermore, the user should be able to use the workload replay package and should have the user SWITCH privilege. The Client Connections table is populated when at least one replay client is connected.
After you start replay clients, click Next on the Wait for Client Connections page. Note: By default, replay is the wrc mode.
Using the Replay Workload Wizard (continued) At this point, replay clients are waiting for the database to start the replay. On the Replay Workload: Review page, click Submit to enter replay PREPARE mode. The replay clients now start replaying the captured workload.
Viewing Workload Replay Statistics A progress window provides comparison statistics as the replay progresses. You can terminate the replay at any stage with the Stop Replay button.
Viewing Workload Replay Statistics (continued) On successful completion of the replay, the terminal window that started the replay clients displays the message Replay finished, followed by a timestamp. The replayed workload is now complete. The Elapsed Time Comparison chart shows how much time the replayed workload has taken to accomplish the same amount of work as the captured workload. The divergence table gives information about both the data and error discrepancies between the replay and capture environments, which can be used as a measure of the replay quality. RAC Note: If a specific captured instance is mapped to a new instance in the replay system, all the captured calls for the captured instances are sent to the new instance. If the replay system is also RAC and a captured instance is mapped to the run-time load balancing of the replay system, all captured calls for that recorded instance are dynamically distributed to instances in the replay RAC system using run-time load balancing.
Viewing Workload Replay Statistics (continued) You can click the View Workload Replay Report button (or Report tab after replay has completed) to see a browser window that displays a report containing detailed information about the replay. The Report subpage contains several workload performance reports: Workload Replay Report AWR Compare Period Report AWR Report ASH Report
Packages and Procedures You need the EXECUTE privilege on the capture and replay packages to execute these packages. These privileges are usually assigned by the DBA. Note: For further details about the DBMS_WORKLOAD packages, see the Oracle Database PL/SQL Packages and Types Reference 11g, Release 1.
Data Dictionary Views: Database Replay For information about these views, see the Oracle Database Reference.
Database Replay: PL/SQL Example In this example, the ADD_FILTER procedure adds a filter named sessfilt that will filter out all sessions belonging to the user name JFV. To start the workload capture, use the START_CAPTURE procedure. In this example, a capture named june_peak is captured and stored in a directory named jun07. Because the duration parameter is not specified, the workload capture continues until the FINISH_CAPTURE procedure is called. At this point, you can run your workload. To stop the workload capture, use the FINISH_CAPTURE procedure. This procedure finalizes the workload capture and returns the database to a normal state. You can now generate a capture report by using the REPORT function. To preprocess a captured workload, use the PROCESS_CAPTURE procedure. In this example, the captured workload stored in the jun07 directory is preprocessed. When finished, you can start your replay clients. To initialize replay data, use the INITIALIZE_REPLAY procedure. Initializing replay data loads the necessary metadata into tables required by the workload replay. For example, captured connection strings are loaded into a table where they can be remapped for replay. In this example, the INITIALIZE_REPLAY procedure loads preprocessed workload data from the
jun07 directory into the database.
Database Replay: PL/SQL Example (continued) To remap connections, use the REMAP_CONNECTION procedure. In this example, the connection that corresponds to the connection ID 101 will use the new connection string defined by the replay_connection parameter. To prepare workload replay on the replay system, use the PREPARE_REPLAY procedure. In this example, the PREPARE_REPLAY procedure prepares the j_r replay to preserve the COMMIT order in the workload capture. To start a workload replay, use the START_REPLAY procedure. To stop a workload replay, use the REPLAY_CANCEL procedure To generate a workload replay report, use the REPORT function as shown in the slide.
Calibrating Replay Clients Because one replay client can initiate multiple sessions with the database, it is not necessary to start a replay client for each session that was captured. The number of replay clients that need to be started depends on the number of workload streams, the number of hosts, and the number of replay clients for each host. For example, suppose that a workload capture has 1,000 streams, that the number of average active sessions from the workload capture is about 60, and that one host can drive only 50 concurrent connections to the database. You should use two hosts, each with a replay client. To estimate the number of replay clients and hosts that are required to replay a particular workload, run the wrc executable in calibrate mode. In calibration mode, the wrc executable accepts the following parameters: replaydir specifies the directory that contains the preprocessed workload capture that you want to replay. If unspecified, it defaults to the current directory. process_per_cpu specifies the maximum number of client processes that can run for each CPU. The default value is 4. threads_per_process specifies the maximum number of threads that can run in a client process. The default value is 50. The example in the slide shows how to run the wrc executable in the calibrate mode. In this example, the wrc executable is executed to estimate the number of replay clients and hosts that
are required to replay the workload capture stored in the directory named replay. Note: To list the hosts that participated in the capture, use the list_hosts mode.
SQL Tuning in Oracle Database 10g Oracle Database 10g introduced SQL Tuning Advisor to help DBAs and application developers improve the performance of SQL statements. The advisor targets the problem of poorly written SQL, in which SQL statements have not been designed in the most efficient fashion. It also targets the (more common) problem in which a SQL statement is performing poorly because the optimizer generated a poor execution plan due to a lack of accurate and relevant data statistics. In all cases, the advisor makes specific suggestions for speeding up SQL performance, but it leaves the responsibility of implementing the recommendations to the user. In addition to SQL Tuning Advisor, Oracle Database 10g has an automated process to identify high-load SQL statements in your system. This is done by the Automatic Database Diagnostic Monitor (ADDM), which automatically identifies high-load SQL statements that are good candidates for tuning. However, major issues still remain: Although it is true that ADDM identifies some SQL that should be tuned, users must manually look at ADDM reports and run SQL Tuning Advisor on those reports for tuning.
Automatic SQL Tuning in Oracle Database 11g Oracle Database 11g further automates the SQL Tuning process by identifying problematic SQL statements, running SQL Tuning Advisor on them, and implementing the resulting SQL profile recommendations to tune the statement without requiring user intervention. Automatic SQL Tuning uses the AUTOTASK framework through a new task called Automatic SQL Tuning that runs every night by default. Here is a brief description of the automated SQL tuning process in Oracle Database 11g: Step 1: Based on the AWR Top SQL identification (SQLs that were top in four different time periods: the past week, any day in the past week, any hour in the past week, or single response time), Automatic SQL Tuning targets for automatic tuning. Steps 2 and 3: While the Automatic SQL Tuning task is executing during the maintenance window, the previously identified SQL statements are automatically tuned by invoking SQL Tuning Advisor. As a result, SQL profiles will be created for them if needed. However, before making any decision, the new profile is carefully tested. Step 4: At any point in time, you can request a report about these automatic tuning activities. You then have the option of checking the tuned SQL statements to validate or remove the automatic SQL profiles that were generated.
Selecting Potential SQL Statements for Tuning Oracle Database 11g analyzes the statistics in the AWR and generates a list of potential SQL statements that are eligible for tuning. These statements include repeating high-load statements that have a significant impact on the system. Only SQL statements that have an execution plan with a high potential for improvement will be tuned. Recursive SQL and statements that have been tuned recently (in the last month) are ignored, as are parallel queries, DMLs, DDLs, and SQL statements with performance problems that are caused by concurrency issues. The SQL statements that are selected as candidates are then ordered based on their performance impact. The performance impact of a SQL statement is calculated by summing the CPU time and the I/O times captured in the AWR for that SQL statement in the past week.
Maintenance Window Timeline The Automatic SQL Tuning process takes place during the maintenance window. Furthermore, it runs as part of a single AUTOTASK job on a single instance to avoid concurrency issues. This is portrayed in the slide for one scenario. In this scenario, at some time after the beginning of the maintenance window, AUTOTASK starts the Automatic SQL Tuning job (SYS_AUTO_SQL_TUNING_TASK). The first thing that the job does is to generate a list of candidate SQL for tuning, according to the AWR source. When the list is complete, the job tunes each statement in order of importance, one after another, considering only one statement at a time. In this scenario, it first tunes S1, which has a SQL profile recommendation (P1) generated for it by SQL Tuning Advisor. After P1 has been successfully tested, it is accepted and the job moves on to the next statement, S2. By default, Automatic SQL Tuning runs for at most one hour during a maintenance window. You can change this setting by using a call similar to the following: dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK ', 'TIME_LIMIT', 7200);
Note: The widths of boxes in the slide do not indicate relative execution times. Tuning and test execution should be the most expensive processes by far, with all the others completing relatively quickly.
Automatic Tuning Process With the list of candidate SQL already built and ordered, the statements are then tuned using SQL Tuning Advisor. During the tuning process, all the recommendation types are considered and reported, but only SQL profiles can be implemented automatically (when the ACCEPT_SQL_PROFILES task parameter is set to TRUE). Otherwise, only the recommendation to create a SQL profile will be reported in the automatic SQL tuning reports.
In Oracle Database 11g, the performance improvement factor has to be at least three before a SQL profile is implemented. As we have already mentioned, the Automatic SQL Tuning process implements only SQL profile recommendations automatically. Other recommendations (to create new indexes, refresh stale statistics, or restructure SQL statements) are generated as part of the SQL tuning process but are not implemented. These are left for the DBA to review and implement manually, as appropriate. Here is a short description of the general tuning process: Tuning is performed on a per-statement basis. Because only SQL profiles can be implemented, there is no need to consider the effect of such recommendations on the workload as a whole. For each statement (in order of importance), the tuning process carries out each of the following steps: 1. Tune the statement by using SQL Tuning Advisor. Look for a SQL profile and, if it is
found, verify that the base optimizer statistics are current for it.
DBA Controls Here is a PL/SQL control example for the Automatic SQL Tuning task: BEGIN dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'LOCAL_TIME_LIMIT', 1400); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'ACCEPT_SQL_PROFILES', 'TRUE'); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'MAX_SQL_PROFILES_PER_EXEC', 50); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'MAX_AUTO_SQL_PROFILES', 10002); END; The last three parameters in this example are supported only for the Automatic SQL Tuning task. You can also use parameters such as LOCAL_TIME_LIMIT, or TIME_LIMIT, which are valid parameters for the traditional SQL tuning tasks. One important example is to disable test-execute mode (to save time) and to use only execution plan costs to decide about the performance by using the TEST_EXECUTE parameter. In addition, you can control when the Automatic SQL Tuning task runs and the CPU resources that it is allowed to use. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 217 Administrators 6 - 217
Automatic SQL Tuning Task As has already been mentioned, Automatic SQL Tuning is implemented as an automated maintenance task that is itself called Automatic SQL Tuning. You can see some high-level information about the last runs of the Automatic SQL Tuning task by going to the Automated Maintenance Tasks page: On your Database Control home page, click the Server tab and, when you are on the Server page, click the Automated Maintenance Tasks link in the Tasks section.
On the Automated Maintenance Tasks page, you see the predefined tasks. You then access each task by clicking the corresponding link to get more information about the task itself (illustrated in the slide). When you click either the Automatic SQL Tuning link or the latest execution icon (the green area on the timeline), you go to the Automatic SQL Tuning Result Summary page.
Configuring Automatic SQL Tuning You can configure various Automatic SQL Tuning parameters by using the Automatic SQL Tuning Settings page. To get to that page, click the Configure button on the Automated Maintenance Tasks page. This takes you to the Automated Maintenance Tasks Configuration page, where you can see the various maintenance windows that are delivered with Oracle Database 11g. By default, Automatic SQL Tuning executes on all predefined maintenance windows in the MAINTENANCE_WINDOW_GROUP. You can disable it for specific days in the week. On this page, you can also edit each Window to change its characteristics. You can do so by clicking Edit Window Group. To get to the Automatic SQL Tuning Settings page, click the Configure button on the line corresponding to Automatic SQL Tuning in the Task Settings section. On the Automatic SQL Tuning Settings page, you can specify the parameters shown in the slide. By default, Automatic Implementation of SQL Profiles is deactivated. Note: If you set STATISTICS_LEVEL to BASIC, turn off the AWR snapshots by using DBMS_WORKLOAD_REPOSITORY, or if AWR retention is less than seven days, you also stop Automatic SQL Tuning.
Automatic SQL Tuning Result Summary In addition, the Automatic SQL Tuning Result Summary page contains various summary graphs so that you can control the Automatic SQL Tuning task. An example is given in the slide. The first chart in the Overall Task Statistics section shows you the breakdown by finding types for the designated period of time. You can control the period of time for which you want the report to be generated by selecting a value from the Time Period list. In the example, Customized is used; it shows you the latest run. You can choose All to cover all executions of the task so far. Users can request it for any time period over the past month, since that is the amount of time for which the advisor persists its tuning history. You then generate the report by clicking View Report. On the Breakdown by Finding Type chart, you can clearly see that only SQL profiles can be implemented. Although many more profiles were recommended, not all of them were automatically implemented for the reasons that we already explained. Similarly, recommendations for index creation and other types are not implemented. However, the advisor keeps historical information about all the recommendations if you want to implement them later. In the Profile Effect Statistics section, you can see the Tuned SQL DB Time Benefit chart, which shows you the before-and-after DB Time for implemented profiles and other recommendations.
Automatic SQL Tuning: Result Details On the Automatic SQL Tuning Result Details page, you can also see a variety of important information for each automatically tuned SQL statement, including its SQL text and SQL ID, the type of recommendation that was done by SQL Tuning Advisor, the verified benefit percentage, whether a particular recommendation was automatically implemented, and the date of the recommendation.
From this page, you can either drill down to the SQL statement itself by clicking its corresponding SQL ID link, or you can select one of the SQL statements and click the View Recommendations button to have more details about the recommendation for that statement. Note: The benefit percentage shown for each recommendation is calculated using the formula bnf% = (time_old - time_new)/(time_old). With this formula, you can see that a three-time benefit (for example, time_old = 100, time_new = 33) corresponds to 66%. So the system implements any profiles with benefits over 66%. According to this formula, 98% is a 50 times benefit.
Automatic SQL Tuning Result Details: Drilldown On the Recommendations for SQL ID page, you can see the corresponding recommendations and implement them manually. By clicking the SQL Test link, you access the SQL Details page, where you see the tuning history as well as the plan control associated with your SQL statement. In the slide, you see that the statement was tuned by Automatic SQL Tuning and that the associated profile was automatically implemented.
Automatic SQL Tuning: Fine Tune You can use the DBMS_SQLTUNE PL/SQL package to control various aspects of SYS_AUTO_SQL_TUNING_TASK. 1. SET_TUNING_TASK_PARAMETERS: The following parameters are supported for the automatic tuning task only: ACCEPT_SQL_PROFILES: TRUE/FALSE whether the system should accept SQL profiles automatically REPLACE_USER_SQL_PROFILES: TRUE/FALSE whether the task should replace SQL profiles created by the user MAX_SQL_PROFILES_PER_EXEC: Maximum number of SQL profiles to create for each run MAX_AUTO_SQL_PROFILES: Maximum number of automatic SQL profiles allowed on the system in total EXECUTION_DAYS_TO_EXPIRE: Specifies the number of days to save the task history in the advisor framework schema. By default, the task history is saved for 30 days before it expires. 2. EXECUTE_TUNING_TASK function: Used to manually run a new execution of the task in the foreground (behaves in the same way that it runs in the background) 3. REPORT_AUTO_TUNING_TASK: Get a text report covering a range of task executions You can enable and disable SYS_AUTO_SQL_TUNING_TASK by using the DBMS_AUTO_TASK_ADMIN PL/SQL package. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 223 Administrators 6 - 223
Using the PL/SQL Interface to Generate Reports The example in the slide shows how to generate a text report to display all SQL statements that were analyzed in the most recent execution, including recommendations that were not implemented. All sections of the report are included. Depending on the sections that were included in the report, you can view information about the automatic SQL tuning task in the following sections of the report: The general information section provides a high-level description of the automatic SQL tuning task, including information about the inputs given for the report, the number of SQL statements tuned during the maintenance, and the number of SQL profiles that were created. The summary section lists the SQL statements (by their SQL identifiers) that were tuned during the maintenance window and the estimated benefit of each SQL profile, or their actual execution statistics after test-executing the SQL statement with the SQL profile. The Tuning findings section gives you all findings and statistics that are associated with each SQL statement, as well as whether profiles were accepted (and why). The Explain plans section shows the old and new explain plans used by each SQL statement analyzed by SQL Tuning Advisor. The Errors section lists all errors encountered by the Automatic SQL Tuning task. Note: Obtain the execution list by using the following command: Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 225 Administrators 6 - 225
select execution_name,status,execution_start,execution_end from dba_advisor_executions where task_name='SYS_AUTO_SQL_TUNING_TASK';
Automatic SQL Tuning Considerations Automatic SQL Tuning does not seek to solve every SQL performance issue occurring on a system. It does not consider the following types of SQL. Ad hoc or rarely repeated SQL: If a SQL is not executed multiple times in the same form, the advisor ignores it. SQL that do not repeat within a week are also not considered. Parallel queries. Long-running queries (post-profile): If a query takes too long to run after being SQL profiled, it is not practical to test-execute and, therefore, it is ignored by the advisor. Note that this does not mean that the advisor ignores all long-running queries. If the advisor can find a SQL profile that causes a query that once took hours to run in minutes, it could be accepted because test-execution is still possible. The advisor would execute the old plan just long enough to determine that it is worse than the new one, and then would terminate test-execution without waiting for the old plan to finish, thereby switching the order of execution. Recursive SQL statements DMLs such as INSERT SELECT or CREATE TABLE AS SELECT With the exception of truly ad hoc SQL, these limitations apply to Automatic SQL Tuning only. Such statements can still be tuned by manually running SQL Tuning Advisor.
Comparative Performance Analysis with AWR Baselines What is the proper threshold to set on a performance metric? What is it that you want to detect? If you want to know that the performance metric value indicates that the server is nearing capacity, an absolute value is correct. But if you want to know that the performance is different today than it was at this time last week, or last month, the current performance must be compared to a baseline.
A baseline is a set of snapshots taken over a period of time. These snapshots are grouped statistically to yield a set of baseline values that vary over time. For example, the number of transactions per second in a certain database varies depending on the time of the day. The values for transactions per second are higher during working hours and lower during nonworking hours. The baseline records this variation and can be set to alert you if the current number of transactions per second is significantly different from the baseline values. Oracle Database 11g baselines provide the data required to calculate time-varying thresholds based on the baseline data. The baseline allows a real-time comparison of performance metrics with baseline data and can be used to produce AWR reports that compare two periods.
Automatic Workload Repository Baselines Oracle Database 11g consolidates the various concepts of baselines in Oracle (specifically in Enterprise Manager and RDBMS) into the single concept of the Automatic Workload Repository (AWR) baseline. Oracle Database 11g AWR baselines provide powerful capabilities for defining dynamic and future baselines, and considerably simplify the process of creating and managing performance data for comparison purposes.
Oracle Database 11g introduces the concept of moving window baselines. By default, a systemdefined moving window baseline is created that corresponds to all the AWR data within the AWR retention period. Oracle Database 11g provides the ability to collect two kinds of baselines: moving window and static baselines. Static baselines can be either single or repeating. A single AWR baseline is collected over a single time period. A repeating baseline is collected over a repeating time period (for example, every Monday in June). In Oracle Database 11g, baselines are enabled by default if STATISTICS_LEVEL=TYPICAL or ALL.
Moving Window Baseline Oracle Database automatically maintains a system-defined moving window baseline. The default window size for the system-defined moving window baseline is the current AWR retention period, which by default is eight days. If you are planning to use adaptive thresholds, consider using a larger moving window (such as 30 days) to accurately compute threshold values. You can resize the moving window baseline by changing the number of days in the moving window to a value that is equal to or less than the number of days in the AWR retention period. Therefore, to increase the size of a moving window, you first need to increase the AWR retention period accordingly. This system-defined baseline provides a default out-of-the-box baseline for EM performance screens to compare the performance with the current database performance. Note: The default retention period for snapshot data has been changed from seven days to eight days in Oracle Database 11g to ensure the capture of an entire week of performance data.
Baselines in Performance Page Settings The data for any defined baseline in the past is available in Oracle Database 11g. The baseline data may be displayed on the Performance page of Enterprise Manager. You have three display options: Do not show baseline information. Show the information from a specified static baseline. Show the information from the system moving baseline. Note: The system moving window baseline becomes valid after sufficient data has been collected and the statistics calculation occurs. By default, the statistics calculation is scheduled for every Saturday at midnight.
Baseline Templates Creating baselines for future time periods allows you to mark time periods that you know will be interesting. For example, you may want the system to automatically generate a baseline for every Monday morning for the whole year, or you can ask the system to generate a baseline for an upcoming holiday weekend if you suspect that it is a high-volume weekend. Previously, you could create baselines only on snapshots that already existed. With Oracle Database 11g, a nightly MMON task goes through all the templates for baseline generation and checks to see if any time ranges have changed from the future to the past within the last day. For the relevant time periods, the MMON task then creates a baseline for the time period.
Creating AWR Baselines You can create two types of AWR baselines: single and repeating. The Create Baseline: Baseline Interval Type page gives the following explanations. The single type of baseline has a single and fixed time interval: for example, from Jan 1, 2007, at 10:00 AM, to Jan 1, 2007, at 12:00 PM. The repeating type of baseline has a time interval that repeats over a time period: for example, every Monday from 10:00 AM to 12:00 PM for the year 2007. To view the AWR Baseline page, click the AWR Baselines link on the Server tab of the Database Instance page. On the Baseline page, click Create and follow the wizard to create your baseline. Note: Before you can set up AWR baseline metric thresholds for a particular baseline, you must compute the baseline statistics. Select Schedule Statistics Computation from the actions menu to compute the baseline statistics. There are several other actions available.
OK has change to Finish in Beta 5
Single AWR Baseline If you selected the Single option in the previous step, you access the page shown in this slide. Select the time period corresponding to your interest in one of two ways: Select the Snapshot Range option, and then set the Period Start Time and Period End Time by following the directions on the page. If the Icon that you want to select is not shown, you can change the chart time period. Specify the Time Range, with a date and time for start and end times. With Time Range, you can choose times in the future. When you are finished, click Finish to create the static baseline. Note: If the End Time of the baseline is in the future, a baseline template with the same name as the baseline will be created.
Creating a Repeating Baseline Template You can define repeating baselines by using Enterprise Manager. In the wizard, after selecting Repeating in step 1, you can specify the repeat interval as shown in this slide. You specify the start time and the duration of the baseline. Then specify when the baseline statistics will be collected (daily or weekly; if weekly, for which days). Specify the range of dates for which this baseline template will collect statistics. Retention Time sets an expiration value for the baseline; a value of NULL indicates that the baseline never expires.
Generate a Baseline Template for a Single Time Period You can now create a template for how baselines are to be created for different time periods in the future, for predictable schedules. If any part of the period is in the future, use the CREATE_BASELINE_TEMPLATE procedure. For the baseline template, when the end time becomes a time in the past, a task using these inputs automatically creates a baseline for the specified time period when the time comes. The example creates a baseline template that creates a baseline when 0:0:0 21-Sep-2008 is in the past. Using time-based definitions in baseline creation does not require the start-snapshot and endsnapshot identifiers. For the CREATE_BASELINE_TEMPLATE procedure, you can also now specify an expiration duration for the baseline that is created from the template. The expiration duration, specified in days, represents the number of days you want the baselines to be maintained. A value of NULL means that the baselines never expire. To create a baseline over a period in the past, use the CREATE_BASELINE procedure (as in Oracle Database 10g). The CREATE_BASELINE procedure has one new parameter: expiration duration. Expiration duration has the same meaning as it does for CREATE_BASELINE_TEMPLATE. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 242 Administrators 7 - 242
Creating a Repeating Baseline Template Use the CREATE_BASELINE_TEMPLATE procedure to generate baseline templates that automatically create baselines for a contiguous time period based on a repeating time schedule. You can also specify whether you want the baseline to be automatically removed after a specified expiration interval (expiration). The example in the slide generates a template that creates a baseline for a period that corresponds to each SATURDAY_MAINTENANCE_WINDOW for a year. The baseline is created over a 20-hour period (duration) that starts at 6:00 AM (hour_in_day) each Saturday (day_of_week). The baseline is named SAT_MAINT_WIN with time information appended to make the name unique. The template is named SAT_MAINT_WIN, and each baseline will be kept for 90 days (expiration). This template is created for the local database ( dbid => NULL ). Use this baseline to compare the resources that are used each Saturday during the maintenance window.
DBMS_WORKLOAD_REPOSITORY Package The slide shows the set of PL/SQL interfaces offered by Oracle Database 11g in the DBMS_WORKLOAD_REPOSITORY package for administration and filtering. MODIFY_BASELINE_WINDOW_SIZE enables you to modify the size of the SYSTEM_MOVING_WINDOW.
Baseline Views The data dictionary views supporting the AWR baselines have changed. DBA_HIST_BASELINE: Modified View DBA_HIST_BASELINE has been modified to support the SYSTEM_MOVING_WINDOW baseline and the baselines generated from templates. Additional information includes the date created, time of last statistics calculation, and type of baseline. DBA_HIST_BASELINE_DETAILS: New View DBA_HIST_BASELINE_DETAILS displays information that allows you to determine the validity of a given baseline, such as whether there was a shutdown during the baseline period and the percentage of the baseline period that is covered by the snapshot data. DBA_HIST_BASELINE_TEMPLATE: New View DBA_HIST_BASELINE_TEMPLATE holds the baseline templates. This view provides the information needed by MMON to determine when a baseline will be created from a template and when the baseline should be removed. For details, see Oracle Database Reference 11g.
Performance Monitoring and Baselines When they are properly set, alert thresholds provide a valuable servicean alertby indicating a performance metric that is at an unexpected value. Unfortunately, in many cases the expected value varies with the workload type, system load, time of day, or day of the week. Baselines associated with certain workload types or days of the week capture the metric values of that period. The baseline can then be used to set the threshold values when similar conditions exist.
Baselines capture metric values. The statistics for baselines are computed to place a minimal load on the system; statistics for static baselines are manually computed. You can schedule statistics computation on the AWR Baselines page. Statistics for the system moving window are automatically computed according to the BSLN_MAINTAIN_STATS_SCHED schedule. By default, this schedule starts the job every week at noon on Saturday.
Performance Monitoring and Baselines (continued) Metric statistics computed over a baseline enable you to set thresholds that compare the baseline statistics to the current activity. There are three methods of comparison: significance level, percentage of maximum, and fixed values. Thresholds based on significance level use statistical relevance to determine which current values are unusual. In simple terms, if the significance level is set to .99 for a critical threshold, the threshold is set where 1% of the baseline values fall outside this value and any current values that exceed this value trigger an alert. A higher significance level of .999 or .9999 causes fewer alerts to be triggered. Thresholds based on percentage of maximum are calculated based on the maximum value captured by the baseline. Threshold values based on fixed values are set by the DBA. No baseline is required.
Defining Alert Thresholds Using Static Baseline After AWR baseline statistics are computed for a particular baseline, you can set metric thresholds specific to your baseline. Compute baseline statistics directly from the Baselines page (as previously discussed). Then go to the AWR Baseline Metric Thresholds page and select the type of metrics that you want to set. When done, select a specific metric and click Edit Thresholds. On the corresponding Edit AWR Baseline Metric Thresholds page, specify your thresholds in the Thresholds Settings section, and then click Apply Thresholds. You can specify thresholds based on the statistics computed for your baseline. This is illustrated in the slide. In addition to Significance Level, the other possibilities are Percentage of Maximum and Fixed Values. Note: After a threshold is set using Baseline Metric Thresholds, the previous threshold values are forgotten forever and the statistics from the associated baseline are used to determine the threshold values until they are cleared (by using the Baseline Metric Threshold UI or PL/SQL interface).
Using EM to Quickly Configure Adaptive Thresholds Oracle Database 11g Enterprise Manager provides significant usability improvements in the selection of adaptive thresholds for database performance metrics, with full integration with AWR baselines as the source for the metric statistics. EM offers a quick configuration option in a one-click starter set of thresholds based on OLTP or Data Warehouse workload profiles. Make the selection of the appropriate workload profiles from the subsequent pop-up window. By making this simple selection, the system automatically configures and evolves adaptive thresholds based on the SYSTEM_MOVING_WINDOW baseline for the group of metrics that best correspond to the chosen workload.
Using EM to Quickly Configure Adaptive Thresholds (continued) On the OLTP Threshold settings page, configure the desired workload baselines. When it is configured, you can edit the threshold levels by using the Edit Threshold button. The Warning Level and Critical Level columns indicate the type of alert generated. The Significance Level indicates whether the level of observation is at or above a certain value. The following significance level thresholds are supported: High: Significant at 0.95 level (5 in 100) Very High: Significant at 0.99 level (1 in 100) Severe: Significant at 0.999 level (1 in 1,000) Extreme: Significant at 0.9999 level (1 in 10,000) Tip: When editing threshold levels, set the significance level thresholds conservatively and experimentally at first, and then observe the number and significance of alerts. Higher significance levels reduce the number of alerts. The threshold values are determined by examining the statistics for the metric values observed over the baseline time period. The system sets the thresholds based on prior data from the system itself and some metadata provided by you. This is significantly easier in the multitarget case because you no longer need to know the system-specific metric. The statistics to monitor are the maximum value as well as the significance levels. The significance levels let you set the Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 251 Administrators 7 - 251
threshold to a value that is statistically significant at the stated level (for example, 1 in 1,000).
Changing Adaptive Threshold Settings After the adaptive thresholds are set, you can change their values (if necessary) as shown in the slide. On the Edit AWR Baseline Metric Thresholds page corresponding to the metric that you want to modify, you see the graphic history of the observed value for the metric, the materialization of the computed baseline value, and the corresponding adaptive threshold.
Maintenance Windows Oracle Database 10g introduced the execution of automated maintenance tasks during a maintenance window. The automated tasks are statistics collection, segment advisor, and Automatic SQL Tuning. With Oracle Database 11g, the Automated Maintenance Tasks feature relies on the Resource Manager being enabled during the maintenance windows. Thus the resource plan associated with the window is automatically enabled when the window opens. The goal is to prevent maintenance work from consuming excessive amounts of system resources. Each maintenance window is associated with a resource plan that specifies how the resources will be allocated during the window duration. In Oracle Database 11g, WEEKNIGHT_WINDOW and WEEKEND_WINDOW (defined in Oracle Database 10g) are replaced with daily maintenance windows. Automated tasks are assigned to specific windows. All daily windows belong to MAINTENANCE_WINDOW_GROUP by default. You are still completely free to define other maintenance windows as well as change start times and durations for the daily maintenance windows. Likewise, any maintenance windows that are deemed unnecessary can be disabled or removed. The operations can be done by using EM or Scheduler interfaces.
Default Maintenance Plan When a maintenance window opens, the DEFAULT_MAINTENANCE_PLAN in the Resource Manager is automatically set to control the amount of CPU used by the automated maintenance tasks. To be able to give different priorities to each possible task during a maintenance window, various consumer groups are assigned to DEFAULT_MAINTENANCE_PLAN. The hierarchy between groups and plans is shown in the slide.
For high-priority tasks: Optimizer Statistics Gathering automatic task is assigned to the ORA$AUTOTASK_STATS_GROUP consumer group Segment Advisor automatic task is assigned to the ORA$AUTOTASK_SPACE_GROUP consumer group Automatic SQL Tuning automatic task is assigned to the ORA$AUTOTASK_SQL_GROUP consumer group Note: If necessary, you can manually change the percentage of CPU resources allocated to the various automated maintenance task consumer groups inside ORA$AUTOTASK_HIGH_SUB_PLAN.
Automated Maintenance Task Priorities The Automated Maintenance Tasks feature is implemented by Autotask Background Process (ABP). ABP functions as an intermediary between automated tasks and the Scheduler. Its main purpose is to translate automated tasks into AUTOTASK jobs for execution by the Scheduler. Just as important, ABP maintains a history of execution of all tasks. ABP stores its private repository in the SYSAUX tablespace; you view the repository through DBA_AUTOTASK_TASK.
ABP is started by MMON at the start of a maintenance window. There is only one ABP required for all instances. The MMON process monitors ABP and restarts it if necessary.
ABP determines the list of jobs that need to be created for each maintenance task. This list is ordered by priority: urgent, high, and medium. Within each priority group, jobs are arranged in the preferred order of execution. ABP creates jobs in the following manner: all urgent-priority jobs are created first, all high-priority jobs are created next, and all medium-priority jobs are created last. ABP assigns jobs to various Scheduler job classes. These job classes map the job to a consumer group based on priority.
Note: With Oracle Database 11g, there is no job that is permanently associated with a specific automated task. Therefore, it is not possible to use DBMS_SCHEDULER procedures to control the behavior of automated tasks. Use the DBMS_AUTO_TASK_ADMIN procedures instead.
Controlling Automatic Maintenance Tasks The Automatic Maintenance Tasks feature determines whenand in what ordertasks are performed. As a DBA, you can control the following: If the maintenance window turns out to be inadequate for the maintenance workload, adjust the duration and start time of the maintenance window. Control the resource plan that allocates resources to the automated maintenance tasks during each window. Enable or disable individual tasks in some or all maintenance windows. In a RAC environment, shift maintenance work to one or more instances by mapping maintenance work to a service. Enabling the service on a subset of instances shifts maintenance work to these instances. As shown in the slide, Enterprise Manager is the preferred way to control Automatic Maintenance Tasks. However, you can also use the DBMS_AUTO_TASK_ADMIN package.
Important I/O Metrics for Oracle Databases We first briefly summarize the types of I/O issued by the Oracle Database processes. The database I/O workload typically consists of small random I/O and large sequential I/O. Small random I/O is more prevalent in an OLTP application environment in which each foreground reads a data block into the buffer cache for updates and the changed blocks are written in batches by the dbwr process. Large sequential I/O is common in an OLAP application environment. The OLTP application performance depends on how fast a small I/O is serviced, which depends on how fast the disk can spin and find the data. Large I/O performance depends on the capacity of the I/O channel that connects the server to the storage array; large I/O throughput is better when the capacity of the channel is larger. IOPS (I/O per second): This metric represents the number of small random I/O that can be serviced in a second. The IOPS rate mainly depends on how fast the disk media can spin. The IOPS rate from a storage array can be increased either by adding more disk drives or by using disk drives with a higher RPM (rotations per minute) rate. MBPS (megabytes per second): The rate at which data can be transferred between the computing server node and the storage array depends on the capacity of the I/O channel that is used to transfer data. More data can be transferred through a wider pipe.
I/O Calibration and Enterprise Manager To determine the previously discussed I/O metrics, you can use the I/O Calibration tool from the Enterprise Manager Performance page or PL/SQL. I/O Calibration is a modified version of the ORION tool and is based on the asynchronous I/O library. Because calibration requires issuing enough I/O to saturate the storage system, any performance-critical sessions will be negatively impacted. Thus, you should run I/O calibration only when there is little activity on your system.
I/O Calibration takes approximately 10 minutes to run. You can launch an I/O Calibration task directly from Enterprise Manager (as shown in the slide). You do this by clicking the Performance tab. On the Performance page, you can click the I/O tab and then the I/O Calibration button. On the I/O Calibration page, specify the approximate number of physical disks attached to your database storage system as well as the maximum tolerable latency for a single-block I/O request. Then, in the Schedule section of the I/O Calibration page, specify when to execute the calibration operation. Click the Submit button to create a corresponding Scheduler job. On the Scheduler Jobs page, you can see the amount of time it takes for the calibration task to run. When finished, view the results of the calibration operation on the I/O Calibration page: maximum I/O per second, maximum megabytes per second, and average actual latency metrics.
I/O Calibration and the PL/SQL Interface You can run the I/O Calibration task by using the PL/SQL interface. Execute the CALIBRATE_IO procedure from the DBMS_RESOURCE_MANAGER package. This procedure calibrates the I/O capabilities of the storage. The calibration status and results are available from the V$IO_CALIBRATION_STATUS and DBA_RSRC_IO_CALIBRATE views. Here is a brief description of the parameters you can specify for the CALIBRATE_IO procedure: num_disks: Approximate number of physical disks in the database storage max_latency: Maximum tolerable latency (in milliseconds) for database-block-sized I/O requests max_iops: Maximum number of I/O requests per second that can be sustained. The I/O requests are randomly distributed, database-block-sized reads. max_bps: Maximum throughput of I/O that can be sustained (in megabytes per second). The I/O requests are randomly distributed 1 MB reads. actual_latency: Average latency of database-block-sized I/O requests at max_iops rate (in milliseconds) Usage notes: Only users with the SYSDBA privilege can run this procedure. Only one calibration can run at a time. If another calibration is initiated at the same time, it fails. For a RAC database, the workload is simultaneously generated from all instances. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 262 Administrators 7 - 262
The latency time is computed only when the TIMED_STATISTICS initialization parameter is set to TRUE (which is set when STATISTICS_LEVEL is set to TYPICAL or ALL).
I/O Statistics: Overview To give a consistent set of statistics for all I/O issued from an Oracle instance, Oracle Database 11g introduces a set of virtual views that collect I/O statistics in three dimensions: RDBMS components: Components are grouped by their functionality into 12 categories (shown in the slide). When Resource Management is enabled, I/O statistics are collected for all consumer groups that are part of the currently enabled resource plan. I/O statistics are also collected for the individual files that have been opened. Each dimension has statistics for read and write operations. Since read/write can occur in single block or multiblock operations, they are separated into four different operations (as shown in the slide). For each operation type, the number of corresponding requests and the amount of megabytes are cumulated. In addition to these, the total I/O wait time in milliseconds and the number of total waits are also cumulated for both component and consumer group statistics. For file statistics, total service time in microseconds is accumulated, in addition to statistics for single block reads. Virtual views show cumulative values for statistics. Component and consumer group statistics are transformed into AWR metrics that are sampled regularly and stored in the AWR repository. You can retrieve those metrics across a timeline directly on the Performance page of Enterprise Manager. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 263 Administrators 7 - 263
Note: V$IOSTAT_NETWORK collects network I/O statistics that are related to accessing files on a remote database instance.
I/O Statistics and Enterprise Manager You can retrieve I/O statistics directly on the Performance page in Enterprise Manager. On the Performance page, click the I/O subtab located under the Average Active Session graph. On the I/O subpage, you see a breakdown of I/O statistics on three possible dimensions: I/O Function, I/O Type, and Consumer Group. Select one of the options to look at the corresponding dimension graphs. The slide shows the two graphs corresponding to the I/O function dimension: I/O Megabytes per Second (by RDBMS component) I/O Requests per Second (by RDBMS component) Note: The Others RDBMS component category corresponds to everything that is not directly issued from SQL (for example, PL/SQL and Java).
I/O Statistics and Enterprise Manager (continued) From the I/O Function statistic graphs, you can drill down to a specific component by clicking that component. In the example in the slide, you drill down to the Buffer Cache Reads component. This takes you to the I/O Rates by I/O Function page, where you can see three important graphs for that particular component: MBPS, IOPS, and wait time.
Resource Manager: New EM Interface Using Enterprise Manager, you can access the Resource Manager section from the Server page. The Resource Manager section is organized in the same way as the Database Resource Manager. Clicking the Getting Started link takes you to the Getting Started with Database Resource Manager page, which provides a brief description of each step as well as the links to the corresponding pages.
Resource Plans Created by Default When you create an Oracle 11g database, the Resource Plans (shown in the slide) are created by default. However, none of these plans are active by default.
Default Plan The slide shows the properties of DEFAULT_PLAN. Note that there are no limits for its thresholds. As you can see, Oracle Database 11g introduces two new I/O limits that you can define as thresholds in a Resource Plan.
I/O Resource Limit Thresholds When you create a Resource Plan directive, you can specify the I/O resource limits. The example in the slide shows how to do this in both Enterprise Manager and PL/SQL. You can specify the following two arguments: switch_io_megabytes: Specifies the amount of I/O (in MB) that a session can issue before an action is taken. Default is NULL, which means unlimited. switch_io_reqs: Specifies the number of I/O requests that a session can issue before an action is taken. Default is NULL, which means unlimited.
Resource Manager Statistics You can also look at the Resource Manager Statistics page, which displays statistics for only the current active plan.
New Scheduler Feature: Lightweight Jobs Some customers need to create hundreds of jobs each second. With regular jobs, each job creates a database object describing the job, modifying several tables, and creating redo in the process. In the Oracle Database 11g Scheduler, there is a persistent lightweight job. The goal of a lightweight job is to reduce the overhead and the time required to start a job. A minimal amount of metadata is created for the job. This reduces the time required and the redo created when the job starts. To achieve these goals, the lightweight job has a small footprint on disk for the job metadata and for storing run-time data. The footprint on disk also makes recovery and load balancing possible in RAC environments. The lightweight job is always created from a job template, which can be a stored procedure or a program. The stored procedure holds all the information needed for the job. A few job attributes may be set (such as job arguments). Job templates are created by using the DBMS_SCHEDULER.CREATE_PROGRAM procedures. Oracle Database 11g continues to support the database object-based jobs that have existed since Oracle Scheduler was first introduced in Oracle 10g. Lightweight jobs are not intended to replace these jobs because each job type has its own advantages and gives you the flexibility to choose a job based on your needs.
Choosing the Right Job The advantages and disadvantages of the types of jobs are as follows: A regular job offers maximum flexibility but does entail a significant overhead in create/drop performance. A job can be created with a single command. Users have finegrained control of privileges on the job and can also use programs or stored procedures owned by other users. A regular job requires the job database object to be created and dropped. This action updates several tables and the associated redo. Users who are creating a relatively small number of jobs that run relatively infrequently should choose regular jobs. A persistent lightweight job has a significant improvement in create/drop time because it does not have the overhead of creating a database object. Every lightweight job is created from a job template, which is stored as a program. Because persistent lightweight jobs write state information to disk at run time, only a small improvement is expected in execution. There are several limitations to persistent lightweight jobs: - Users cannot set privileges on these jobs. Instead, they inherit their privileges from the parent job template. - The use of a template is mandatory. It is not possible to create a fully self-contained persistent lightweight job. - Only certain job attributes are available to be set, such as JOB_ARGUMENTS. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 273 Administrators 7 - 273
Lightweight jobs are most useful when the user needs to create a large number of jobs in a very short time (from 10 to 100 jobs a second) and has a library of programs (job templates) available for use.
Creating a Single Lightweight Job The DBMS_SCHEDULER package has overloaded a few packages to allow the lightweight jobs to be created with a minimum of new syntax. Lightweight jobs have very few parameters that can be specified: job arguments and schedule. The rest of the metadata for the job is inherited from the job template, including privileges. The template for a lightweight job must be a PL/SQL block or a stored procedure. Lightweight jobs must be created in PL/SQL by using the DBMS_SCHEDULER package. The JOB_STYLE argument is not exposed in EM. In the first example in the slide, MY_PROG is the job template, and the schedule is created as part of the CREATE_JOB method. In the second example, the schedule is applied from a named schedule. An example of a simple template is the following:
BEGIN DBMS_SCHEDULER.CREATE_PROGRAM( program_name=>'"SYSTEM"."MY_PROG"', program_action=> 'DECLARE time_now DATE; BEGIN SELECT SYSDATE INTO time_now FROM DUAL; END;', program_type=>'PLSQL_BLOCK',
enabled=>TRUE); END;
Creating an Array of Lightweight Jobs Using a job array is a more efficient way to create a set of jobs. This also applies to lightweight jobs. The job array type and the CREATE_JOBS procedure are new to the DBMS_SCEHDULER package in Oracle Database 11g. In the example in the slide, 100 job specifications are created in a job array and submitted to the job queue in a single transaction. Notice that, for a lightweight job, there is a very limited amount of information needed. In this example, the start_time parameter defaults to NULL, so the job is scheduled to start immediately. The example continues on the next two pages. 1. Declare the variable to hold a job definition and a job array variable. 2. Initialize the job array by using the SYS.JOB_ARRAY constructor. This creates a place for one job in the array. 3. Set the size of the array to the number of expected jobs. Note: If the array is very small, performance is not significantly better than submitting a single job.
Creating an Array of Lightweight Jobs (continued) 4. Create each job and place it in the array. In this example, the only difference is the name of the job. The start_time variable of the job is omitted and defaults to NULL, indicating that the job will run immediately. 5. Use the CREATE_JOBS procedure to submit all jobs in the array as one transaction. The full code of this example is as follows:
DECLARE newjob sys.job; newjobarr sys.job_array; BEGIN -- Create an array of JOB object types newjobarr := sys.job_array(); -- Allocate sufficient space in the array newjobarr.extend(100); -- Add definitions for jobs FOR i IN 1..100 LOOP -- Create a JOB object type newjob := sys.job(job_name => 'LWTJK' || to_char(i), job_style => 'LIGHTWEIGHT',
job_template => 'PROG_1', enabled => TRUE );
Viewing Lightweight Jobs in the Dictionary In Oracle Database 11g, changes to dictionary views to support lightweight jobs are minimal. No new views are added. Lightweight jobs are visible through the same views as are regular jobs: DBA_SCHEDULER_JOBS, ALL_SCHEDULER_JOBS, and USER_SCHEDULER_JOBS Arguments to lightweight jobs are visible through the same views as are those of regular jobs: DBA_SCHEDULER_JOB_ARGS, ALL_SCHEDULER_JOB_ARGS, and USER_SCHEDULER_JOB_ARGS Because lightweight jobs are not database objects, they are not visible through the DBA_OBJECTS, ALL_OBJECTS, and USER_OBJECTS views.
Oracle Database 11g: Automatic Database Diagnostic Monitor for RAC Oracle Database 11g offers an extension to the set of functionality that increases the databases manageability by offering clusterwide analysis of performance. A special mode of Automatic Database Diagnostic Monitor (ADDM) analyzes an Oracle Real Application Clusters (RAC) database cluster and reports on issues that are affecting the entire cluster as well as on those that are affecting individual instances. This mode is called database ADDM as opposed to instance ADDM, which already existed with Oracle Database 10g. Database ADDM for RAC is not just a report of reports but has independent analysis that is appropriate for RAC.
Automatic Database Diagnostic Monitor for RAC In Oracle Database 11g, you can create a period analysis mode for ADDM that analyzes the throughput performance for an entire cluster. When the advisor runs in this mode, it is called database ADDM. You can run the advisor for a single instance, which is equivalent to Oracle Database 10g ADDM and is now called instance ADDM. Instance ADDM has access to AWR data generated by all instances, thereby making the analysis of global resources more accurate. Both database and instance ADDM run on continuous time periods that can contain instance startup and shutdown. In the case of database ADDM, there may be several instances that are shut down or started during the analysis period. You must maintain the same database version throughout the entire time period, however. Database ADDM runs automatically after each snapshot is taken. The automatic instance ADDM runs are the same as in Oracle Database 10g. You can also perform analysis on a subset of instances in the cluster. This is called partial analysis ADDM. I/O capacity finding (the I/O system is overused) is a global finding because it concerns a global resource affecting multiple instances. A local finding concerns a local resource or issue that affects a single instance. For example, a CPU-bound instance results in a local finding about the CPU. Although ADDM can be used during application development to test changes to either the application, the database system, or the hosting machines, database ADDM is targeted at DBAs. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 285 Administrators 8 - 285
EM Support for ADDM for RAC Oracle Database 11g Enterprise Manager displays the ADDM analysis on the Cluster Database home page. The Findings table is displayed in the ADDM Performance Analysis section. For each finding, the Affected Instances column displays the number (m of n) of instances affected. The display also indicates the percentage impact for each instance. Drilling down further on the findings takes you to the Performance Findings Detail page.
EM Support for ADDM for RAC (continued) On the Performance Finding Details page, click the Finding History button to see a page with a chart on the top plotting the impact in active sessions for the findings over time. The default display period is 24 hours. The drop-down list supports viewing for seven days. At the bottom of the display, a table similar to the results section is shown, displaying all the findings for this named finding. On this page, you set filters on the findings results. Different types of findings (CPU, logins, SQL, and so on) have different kinds of criteria for filtering. Note: Only automatic runs of ADDM are considered for the Finding History. These results reflect the unfiltered results only.
Using the DBMS_ADDM Package The DBMS_ADDM package eases the ADDM management. It consists of the following procedures and functions: ANALYZE_DB: Creates an ADDM task for analyzing the database globally ANALYZE_INST: Creates an ADDM task for analyzing a local instance ANALYZE_PARTIAL: Creates an ADDM task for analyzing a subset of instances DELETE: Deletes a created ADDM task (of any kind) GET_REPORT: Gets the default text report of an executed ADDM task Parameters 1,2: Start and end snapshot
Advisor Named Findings and Directives Oracle Database 10g introduced the advisor framework and various advisors to help DBAs manage databases efficiently. These advisors provide feedback in the form of findings. Oracle Database 11g now classifies these findings so that you can query the advisor views to understand how often a given type of finding is recurring in the database. A FINDING_NAME column has been added to the following advisor views: DBA_ADVISOR_FINDINGS USER_ADVISOR_FINDINGS A new DBA_ADVISOR_FINDING_NAMES view displays all the finding names.
Using the DBMS_ADDM Package You can use possible finding names to query the findings repository to get all occurrences of that specific finding. In the slide, you see the creation of an instance ADDM task with a finding directive. When the task name is NULL, it applies to all subsequent ADDM tasks. The finding name (Undersized SGA) must exist in the DBA_ADVISOR_FINDING_NAMES view (which lists all the findings) and is case-sensitive. The result of DBMS_ADDM.GET_REPORT shows the Undersized SGA finding only if the finding is responsible for at least two (min_active_sessions) average active sessions during the analysis period. This is at least 10% (min_perc_impact) of the total database time during that period.
Using the DBMS_ADDM Package (continued) Additional PL/SQL directive procedures: INSERT_FINDING_DIRECTIVE: Creates a directive to limit reporting of a specific finding type INSERT_SQL_DIRECTIVE: Creates a directive to limit reporting of actions on specific SQL INSERT_SEGMENT_DIRECTIVE: Creates a directive to prevent ADDM from creating actions to run Segment Advisor for specific segments INSERT_PARAMETER_DIRECTIVE: Creates a directive to prevent ADDM from creating actions to alter the value of a specific system parameter Long syntax for parameters would again help here. Directives are reported if you specify ALL. Note: For a complete description of the available procedures, see the Oracle Database 11g PL/SQL References and Types documentation.
Modified Advisor Views The views containing advisor findings, recommendations, and actions have been enhanced by adding the FILTERED column.
New ADDM Views For a complete description of the available procedures, see the Oracle Database 11g documentation set.
Oracle Database 10g SGA Parameters As shown in the slide, the five most important pools are automatically tuned when Automatic Shared Memory Management (ASMM) is activated. These parameters are called auto-tuned parameters. The second category, called manual dynamic parameters, comprises parameters that can be manually resized without having to shut down the instance but are not automatically tuned by the system. The last category, manual static parameters, includes the parameters that are fixed in size and cannot be resized without first shutting down the instance.
Oracle Database 10g PGA Parameters PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory that is available to all server processes attached to the instance. Setting PGA_AGGREGATE_TARGET to a nonzero value automatically sets the WORKAREA_SIZE_POLICY parameter to AUTO. This means that the SQL working areas used by memory-intensive SQL operators are automatically sized. A nonzero value for this parameter is the default because, unless you specify otherwise, Oracle sets it to 20% of the SGA or 10 MB, whichever is greater. Setting PGA_AGGREGATE_TARGET to 0 automatically sets the WORKAREA_SIZE_POLICY parameter to MANUAL. This means that the SQL work areas are sized using the *_AREA_SIZE parameters. Keep in mind that PGA_AGGREGATE_TARGET is not a fixed value. It is used to help the system better manage PGA memory, but the system will exceed this setting if necessary. WORK_AREA_SIZE_POLICY can be altered per database session, allowing manual memory management on a per-session basis if needed. For example, suppose that a session loads a large import file and a rather large sort_area_size is needed. A logon trigger could be used to set WORK_AREA_SIZE_POLICY for the account doing the import. If WORK_AREA_SIZE_POLICY is AUTO and PGA_AGGREGATE_TARGET is set to 0, we throw Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 295 Administrators 8 - 295
an external error ORA-04032 at startup.
Oracle Database 10g Memory Advisors To help you size the most important SGA components, the advisors in the slide have been introduced in Oracle Database 11g: V$DB_CACHE_ADVICE contains rows that predict the number of physical reads and time for the cache size corresponding to each row. V$SHARED_POOL_ADVICE displays information about the estimated parse time in the shared pool for different pool sizes. V$JAVA_POOL_ADVICE displays information about the estimated class load time into the Java pool for different pool sizes. V$STREAMS_POOL_ADVICE displays information about the estimated count of spilled or unspilled messages, and the associated time spent in the spill or unspill activity for different streams pool sizes. Note: For more information about these views, see the Oracle Database Reference.
Oracle Database 10g Memory Advisors (continued) In Oracle Database 10g, the SGA Advisor shows the improvement in DB time that can be achieved for a particular setting of the total SGA size. This advisor allows you to reduce trial and error in setting the SGA size. The advisor data is stored in the V$SGA_TARGET_ADVICE view. V$PGA_TARGET_ADVICE predicts how the PGA cache hit percentage displayed by the V$PGASTAT performance view is impacted when the value of the PGA_AGGREGATE_TARGET parameter is changed. The prediction is performed for various values of the PGA_AGGREGATE_TARGET parameter, selected around its current value. The advice statistic is generated by simulating the past workload run by the instance. In 11g, a new column (ESTD_TIME) is added, corresponding to the CPU and I/O time required to process the bytes.
Automatic Memory Management: Overview With Automatic Memory Management, the system causes an indirect transfer of memory from SGA to PGA (and vice versa). It automates the sizing of PGA and SGA according to your workload. This indirect memory transfer relies on the OS mechanism of freeing shared memory. After memory is released to the OS, the other components can allocate memory by requesting memory from the OS. Currently, this is implemented on Linux, Solaris, HP-UX, AIX, and Windows. Set your memory target for the database instance and the system then tunes to the target memory size, redistributing memory as needed between the system global area (SGA) and the aggregate program global area (PGA). The slide displays the differences between the Oracle Database 10g mechanism and the new Automatic Memory Management with Oracle Database 11g.
Automatic Memory Management: Overview (continued) The simplest way to manage memory is to allow the database to automatically manage and tune it for you. To do so (on most platforms), you only have to set a target memory size initialization parameter (MEMORY_TARGET) and a maximum memory size initialization parameter (MEMORY_MAX_TARGET). Because the target memory initialization parameter is dynamic, you can change the target memory size at any time without restarting the database. The maximum memory size serves as an upper limit so that you do not accidentally set the target memory size too high. Because certain SGA components either cannot easily shrink or must remain at a minimum size, the database also prevents you from setting the target memory size too low.
Oracle Database 11g Memory Parameters The slide displays the memory initialization parameters hierarchy. Although you only have to set MEMORY_TARGET to trigger Automatic Memory Management, you still have the ability to set lower-bound values for various caches. So if the child parameters are set by the user, they will be the minimum values below which that component is not auto-tuned.
Automatic Memory Parameter Dependency The slide illustrates the relationships among the various memory sizing parameters. If MEMORY_TARGET is set to a nonzero value: If SGA_TARGET and PGA_AGGREGATE_TARGET are set, they will be considered to be minimum values for the sizes of SGA and PGA, respectively. MEMORY_TARGET can take values from SGA_TARGET + PGA_AGGREGATE_TARGET to MEMORY_MAX_SIZE. If SGA_TARGET is set and PGA_AGGREGATE_TARGET is not set, we still auto-tune both the parameters. PGA_AGGREGATE_TARGET is initialized to a value of (MEMORY_TARGET - SGA_TARGET). If PGA_AGGREGATE_TARGET is set and SGA_TARGET is not set, we still auto-tune both the parameters. SGA_TARGET is initialized to a value of min(MEMORY_TARGET PGA_AGGREGATE_TARGET, SGA_MAX_SIZE (if set by the user)) and will auto-tune subcomponents. If neither is set, they are auto-tuned without minimum or default values. We have a policy of distributing the total server memory in a fixed ratio to the SGA and PGA during initialization. The policy is to distribute 60% to SGA and 40% to PGA at startup.
Enabling Automatic Memory Management You can enable Automatic Memory Management by using Enterprise Manager, as shown in the slide. From the Database home page, click the Server tab. On the Server page, click the Memory Advisors link in the Database Configuration section. This takes you to the Memory Advisors page. On this page, you can click the Enable button to enable Automatic Memory Management. The value in the Total Memory Size for Automatic Memory Management field is set by default to the current SGA + PGA size. You can set it to anything more than this but less than the value in Maximum Memory Size. Note: On the Memory Advisors page, you can also specify the Maximum Memory Size. If you change this field, the database must be automatically restarted for your change to take effect.
Monitoring Automatic Memory Management When Automatic Memory Management is enabled, you see a new graphical representation of the history of your memory size components in the Allocation History section of the Memory Parameters page. The green part in the first graphic represents the PGA and the brownish-orange part is all of the SGA. The dark blue below in the lower histogram is the Shared Pool size; light blue corresponds to Buffer Cache.
The change in the slide displays the possible repartition of memory after the execution of the various demanding queries. Both SGA and PGA might therefore shrink. Note that with SGA shrink, its subcomponents also shrink around the same time. On this page, you can also access the memory target advisor by clicking the Advice button. This advisor gives you the possible DB time improvement for various total memory sizes. Note: V$MEMORY_TARGET_ADVICE displays the tuning advice for the MEMORY_TARGET initialization parameter.
Monitoring Automatic Memory Management (continued) The following views provide information about dynamic resize operations: V$MEMORY_DYNAMIC_COMPONENTS displays information about the current sizes of all dynamically tuned memory components, including the total sizes of the SGA and PGA. V$MEMORY_RESIZE_OPS displays information about the last 800 completed memory resize operations (both automatic and manual). This does not include in-progress operations. V$MEMORY_CURRENT_RESIZE_OPS displays information about the memory resize operations (both automatic and manual) that are currently in progress. V$SGA_CURRENT_RESIZE_OPS displays information about SGA resize operations that are currently in progress. An operation can be a grow or a shrink of a dynamic SGA component. V$SGA_RESIZE_OPS displays information about the last 800 completed SGA resize operations. This does not include operations currently in progress. V$SGA_DYNAMIC_COMPONENTS displays information about the dynamic components in SGA. This view summarizes information based on all completed SGA resize operations since startup. V$SGA_DYNAMIC_FREE_MEMORY displays information about the amount of SGA memory that is available for future dynamic SGA resize operations. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 306 Administrators 8 - 306
DBCA and Automatic Memory Management With Oracle Database 11g, DBCA has new options to accommodate Automatic Memory Management (AMM). Use the Memory tab of the Initialization Parameters page to set the initialization parameters that control how the database manages its memory usage. You can choose from two basic approaches to memory management: Typical: Requires very little configuration and allows the database to manage how it uses a percentage of your overall system memory. Select Typical to create a database with minimal configuration or user input. This option is sufficient for most environments and for DBAs who are inexperienced with advanced database creation procedures. Enter a value in megabytes in the Memory Size field. To use AMM, select the corresponding option in the Typical section of the page. Click Show Memory Distribution to see how much memory the DBCA assigns to both SGA and PGA when you do not select the AMM option. Custom (uses ASMM or not): Requires more configuration but provides you with more control over how the database uses available system memory. To allocate specific amounts of memory to the SGA and PGA, select Automatic. To customize how the SGA memory is distributed among the SGA memory structures (buffer cache, shared pool, and so on), select Manual and enter specific values for each SGA subcomponent. Review and modify these initialization parameters later in DBCA.
Note: When you use DBUA or manual DB creation, the MEMORY_TARGET parameter defaults to 0.
Statistic Preferences: Overview The automated statistics-gathering feature was introduced in Oracle Database 10g, Release 1 to reduce the burden of maintaining optimizer statistics. However, there were cases where you had to disable it and run your own scripts instead. One reason was the lack of object-level control. Whenever you found a small subset of objects for which the default gather statistics options did not work well, you had to lock the statistics and analyze them separately by using your own options. For example, the feature that automatically tries to determine adequate sample size (ESTIMATE_PERCENT=AUTO_SAMPLE_SIZE) does not work well against columns that contain data with very high frequency skews. The only way to get around this issue was to manually specify the sample size in your own script. The Statistic Preferences feature in Oracle Database 11g introduces flexibility so that you can rely more on the automated statistics-gathering feature to maintain the optimizer statistics when some objects require settings that are different from the database default. This feature allows you to associate the statistics-gathering options that override the default behavior of the GATHER_*_STATS procedures and the automated Optimizer Statistics Gathering task at the object or schema level. As a DBA, you can use the DBMS_STATS package to manage the gathering statistics options shown in the slide.
Setting Global Preferences with Enterprise Manager It is possible to control global preference settings by using Enterprise Manager. You do so on the Manage Optimizer Statistics page, which you access from the Database home page by clicking the Server tab, then the Manage Optimizer Statistics link, and then the Global Statistics Gathering Options link. On the Global Statistics Gathering Options page, change the global preferences in the Gather Optimizer Statistics Default Options section. When finished, click the Apply button. Note: To change the statistics gathering options at the object level or schema level, click the Object Level Statistics Gathering Preferences link on the Manage Optimizer Statistics page.
Partitioned Tables and Incremental Statistics: Overview For a partitioned table, the system maintains both the statistics on each partition and the overall statistics for the table. Generally, if the table is partitioned using a date range value, very few partitions go through data modifications (DML). For example, suppose we have a table that stores the sales transactions. We partition the table on sales date with each partition containing transactions for a quarter. Most of the DML activity happens on the partition that stores the transactions of the current quarter. The data in other partitions remains unchanged. The system currently keeps track of DML monitoring information at the table and (sub)partition levels. Statistics are gathered only for those partitions (in the example in the slide, the partition for the current quarter) that have significantly changed (current threshold is 10%) since the last statistics gathering. However, global statistics are gathered by scanning the entire table, which makes global statistics very expensive on partitioned tablesespecially when some partitions are stored in slow devices and not modified often. Oracle Database 11g can expedite the gathering of certain global statistics, such as the number of distinct values. In contrast to the traditional way of scanning the entire table, there is a new mechanism to define global statistics by scanning only those partitions that have been changed and still make use of the statistics gathered before for those partitions that are unchanged. In short, these global statistics can be maintained incrementally.
Hash-Based Sampling for Column Statistics For query optimization, it is essential to have a good estimate of the number of distinct values. By default, and without histograms, the optimizer uses the number of distinct values to evaluate the selectivity of a predicate of a column. The algorithm used in Oracle Database 10g computes the number of distinct values with a SQL statement counting the number of distinct values found on a sample of the underlying table. With Oracle Database 10g, you have two choices when gathering column statistics: 1. Use a small sample size, which leads to less accurate results but a short execution time. 2. Use a large sample or full scan, which leads to very accurate results but a very long execution time. In Oracle Database 11g, there is a new method for gathering column statistics that provides accuracy similar to a scan with the execution time of a small sample (1% to 5%). This new technique is used when you invoke a procedure from DBMS_STATS with the ESTIMATE_PERCENT gathering option set to AUTO_SAMPLE_SIZE, which is the default value. The row samplingbased algorithm is used for the collection of a number of distinct values if you specify any value other than AUTO_SAMPLE_SIZE. This preserves the old behavior when you specify sampling percentage.
Multicolumn Statistics: Overview With Oracle Database 10g, the query optimizer takes into account correlation between columns when computing the selectivity of multiple predicates in the following limited cases: If all the columns of a conjunctive predicate match all the columns of a concatenated index key, and the predicates are equalities used in equijoins, then the optimizer uses the number of distinct keys (NDK) in the index for estimating selectivity, as 1/NDK. When DYNAMIC_SAMPLING is set to level 4, the query optimizer uses dynamic sampling to estimate the selectivity of complex predicates involving several columns from the same table. However, the sample size is very small and increases parsing time. As a result, the sample is likely to be statistically inaccurate and may cause more harm than good. In all other cases, the optimizer assumes that the values of columns used in a complex predicate are independent of each other. It estimates the selectivity of a conjunctive predicate by multiplying the selectivity of individual predicates. This approach always results in underestimation of the selectivity. To circumvent this issue, Oracle Database 11g allows you to collect, store, and use the following statistics to capture functional dependency between two or more columns (also called groups of columns): number of distinct values, number of nulls, frequency histograms, and density.
Expression Statistics: Overview Predicates involving expressions on columns are a significant issue for the query optimizer. When computing selectivity on predicates of the form function(Column) = constant, the optimizer assumes a static selectivity value of 1 percent. Obviously, this approach is wrong and causes the optimizer to produce suboptimal plans. The query optimizer has been extended to better handle such predicates in limited cases where functions preserve the data distribution characteristics of the column and thus allow the optimizer to use the columns statistics. An example of such a function is TO_NUMBER. Further enhancements have been made to evaluate built-in functions during query optimization to derive better selectivity using dynamic sampling. Finally, the optimizer collects statistics on virtual columns created to support function-based indexes. However, these solutions are either limited to a certain class of functions or work only for expressions used to create function-based indexes. By using expression statistics in Oracle Database 11g, you can use a more general solution that includes arbitrary user-defined functions and does not depend on the presence of function-based indexes. As shown in the example in the slide, this feature relies on the virtual column infrastructure to create statistics on expressions of columns.
Deferred Statistics Publishing: Overview By default, the statistics gathering operation automatically stores the new statistics in the data dictionary each time it completes the iteration for one object (table, partition, subpartition, or index). The optimizer sees them as soon as they are written to the data dictionary, and these new statistics are called current statistics. This automatic publishing can be frustrating to the DBA, who is never sure of the aftermath of the new statisticsdays or even weeks later. In addition, the statistics used by the optimizer can be inconsistent if, for example, table statistics are published before the statistics of its indexes, partitions or subpartitions. To avoid these potential issues, in Oracle Database 11g, Release 1, you can separate the gathering step from the publication step for optimizer statistics. There are two benefits in separating the two steps: Supports the statistics gathering operation as an atomic transaction. The statistics of all tables and dependent objects (indexes, partitions, subpartitions) in a schema will be published at the same time. This new model has two beneficial properties: The optimizer will always have a consistent view of the statistics, and if for some reason the gathering step fails during the gathering process, it will be able to resume from where it left off when it is restarted by using the DBMS_STAT.RESUME_GATHER_STATS procedure. Allows DBAs to validate the new statistics by running all or part of the workload using the newly gathered statistics on a test system and, when satisfied with the test results, to Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 318 Administrators 8 - 318
proceed to the publishing step to make them current in the production environment.
Deferred Statistics Publishing: Example 1. Use the SET_TABLE_PREFS procedure to set the PUBLISH option to FALSE. This prevents the next statistics gathering operation from automatically publishing statistics as current. According to the first statement, this is true for the SH.CUSTOMERS table only. 2. Gather statistics for the SH.CUSTOMERS table in the pending area of the dictionary. 3. Test the new set of pending statistics from your session by setting the OPTIMIZER_USE_PENDING_STATISTICS to TRUE. 4. Issue queries against SH.CUSTOMERS. 5. If you are satisfied with the test results, use the PUBLISH_PENDING_STATS procedure to render the pending statistics for SH.CUSTOMERS current. Note: To analyze the differences between the pending statistics and the current ones, you could export the pending statistics to your own statistics table and then use the new DBMS_STAT.DIFF_TABLE_STATS function.
Oracle Partitioning The slide summarizes the ten years of partitioning development at Oracle. Note: REF partitioning enables pruning and partitionwise joins against child tables. While performance seems to be the most visible improvement, do not forget about the rest. Partitioning must address all business-relevant areas of performance, manageability, and availability.
Partitioning Enhancements Partitioning is an important tool for managing large databases. Partitioning allows the DBA to employ a divide and conquer methodology for managing database tables, especially as those tables grow. Partitioned tables allow a database to scale for very large data sets while maintaining consistent performance, without unduly impacting administrative or hardware resources.
Partitioning enables faster data access within an Oracle database. Whether a database has 10 GB or 10 TB of data, partitioning can speed up data access by orders of magnitude. With the introduction of Oracle Database 11g, the DBA will find a useful assortment of partitioning enhancements. These enhancements include: Addition of interval partitioning Addition of system partitioning Composite partitioning enhancements Addition of virtual column-based partitioning Addition of reference partitioning
Interval Partitioning Before the introduction of interval partitioning, the DBA was required to explicitly define the range of values for each partition. The problem is explicitly defining the bounds for each partition does not scale as the number of partitions grow. Interval partitioning is an extension of range partitioning, which instructs the database to automatically create partitions of a specified interval when data inserted into the table exceeds all of the range partitions. You must specify at least one range partition. The range partitioning key value determines the high value of the range partitions, which is called the transition point, and the database creates interval partitions for data beyond that transition point. Interval partitioning fully automates the creation of range partitions. Managing the creation of new partitions can be a cumbersome and highly repetitive task. This is especially true for predictable additions of partitions covering small ranges, such as adding new daily partitions. Interval partitioning automates this operation by creating partitions on demand. When using interval partitioning, consider the following restrictions: You can specify only one partitioning key column, and it must be of NUMBER or DATE type. Interval partitioning is not supported for index-organized tables. You cannot create a domain index on an interval-partitioned table. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 327 Administrators 9 - 327
Interval Partitioning: Example Consider the example in the slide, which illustrates the creation of an interval-partitioned table. The original CREATE TABLE statement specifies four partitions with varying widths. This portion of the table is range-partitioned. It also specifies that above the transition point of 1-12004, partitions are created with a width of one month. These partitions are interval-partitioned. Partition Pi1 is automatically created using this information when a row with a value corresponding to January 2004 is inserted into the table. The high bound of partition P3 represents a transition point. P3 and all partitions below it (P1 and P2 in this example) are in the range section, while all partitions above it fall into the interval section. The only argument to the INTERVAL clause is a constant of the interval type. Currently, you can specify only one partitioning key column, and it must be of DATE or NUMBER type. You can use the optional STORE IN clause of the INTERVAL clause to specify one or more tablespaces into which the database will store interval partition data in a round-robin fashion.
Moving the Transition Point: Example The graphic in the slide shows you a typical Information Lifecycle Management (ILM) scenario where after one year of automated partition creation, you merge the created partitions (SYS_Py and SYS_Pz in the example) to move the transition point. You can then move the resulting partitions to a different storage for ILM purposes. The example assumes that you created a table called ORDERS_INTERVAL that has initially one range partition called PREVIOUS, which holds orders from before 2007. The interval is defined to be one month. Then during the year 2007 and 2008, some orders are inserted, and it is assumed that four partitions are created. They are shown on the graphic. They are automatically named according to some system rules. Then you decide to merge the last two partitions of the year 2007 using the ALTER TABLE statement shown in the slide. You must merge two adjacent partitions. Note the new extended partition syntax that can be used to designate a partition without knowing its name. The syntax uses an expression that must represent a possible value for the partition in question. This syntax works for all cases when you have to reference a partition, whether it be range, list, interval, or hash. It supports all operations such as drop, merge, split, and so on. As a result of your MERGE operation, you can see that the transition point moved. The bottom part of the graphic shows you the new range section that now contains three partitions.
Note: You can change the interval of an interval-partitioned table; the existing intervals remain unaffected.
System Partitioning System partitioning enables application-controlled partitioning for arbitrary tables. This is mainly useful when you develop your own partitioned domain indexes. The database simply provides the ability to break down a table into meaningless partitions. All other aspects of partitioning are controlled by the application. System partitioning provides the well-known benefits of partitioning (scalability, availability, and manageability), but the partitioning and actual data placement are controlled by the application. The most fundamental difference between system partitioning and other methods is that system partitioning does not have any partitioning keys. Consequently, the distribution or mapping of the rows to a particular partition is not implicit. Instead, the user specifies the partition to which a row maps by using partition-extended syntax when inserting a row. Because system-partitioned tables do not have a partitioning key, the usual performance benefits of partitioned tables are not available for system-partitioned tables. Specifically, there is no support for traditional partition pruning, partitionwise joins, and so on. Partition pruning is achieved by accessing the same partitions in the system-partitioned tables as those that were accessed in the base table. System-partitioned tables provide the manageability advantages of equipartitioning. For example, a nested table can be created as a system-partitioned table that has the same number of
partitions as the base table. A domain index can be backed up by a system-partitioned table that has the same number of partitions as the base table.
System Partitioning: Example The syntax in the slide example creates a table with four partitions. Each partition can have different physical attributes. INSERT and MERGE statements must use partition-extended syntax to identify a particular partition that a row should go into. For example, the value (4,5) can be inserted into any one of the four partitions given in the example. Deletes and updates do not require the partition-extended syntax. However, because there is no partition pruning, if the partition-extended syntax is omitted, the entire table is scanned to execute the operation. Again, this example highlights the fact that there is no implicit mapping from rows to any partition.
System Partitioning: Guidelines The following operations are supported for system-partitioned tables: Partition maintenance operations and other DDLs (see exceptions below) Creation of local indexes Creation of local bitmapped indexes Creation of global indexes All DML operations INSERT SELECT with partition-extended syntax. Because of the peculiar requirements of system partitioning, the following operations are not supported for system partitioning: Unique local indexes are not supported because they require a partitioning key. CREATE TABLE AS SELECT is not supported because there is no partitioning method. It is not possible to distribute rows to partitions. Instead, you should first create the table and then insert rows into each partition. SPLIT PARTITION operations
Virtual ColumnBased Partitioning Columns of a table whose values are derived by computation of a function or an expression are known as virtual columns. These columns can be specified during a CREATE or ALTER table operation. Virtual columns share the same SQL namespace as other real table columns and conform to the data type of the underlying expression that describes it. These columns can be used in queries like any other table columns, thereby providing a simple, elegant, and consistent mechanism of accessing expressions in a SQL statement. The values for virtual columns are not physically stored in the table row on disk, rather they are evaluated on demand. The functions or expressions describing the virtual columns should be deterministic and pure, meaning the same set of input values should return the same output values. Virtual columns can be used like any other table columns. They can be indexed, and used in queries, DML, and DDL statements. Tables and indexes can be partitioned on a virtual column and even statistics can be gathered upon them. You can use virtual column partitioning to partition key columns defined on virtual columns of a table. Frequently, business requirements to logically partition objects do not match existing columns in a one-to-one manner. With the introduction of Oracle Database 11g, partitioning has been enhanced to allow a partitioning strategy defined on virtual columns, thus enabling a more Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 333 Administrators 9 - 333
comprehensive match of the business requirements.
Virtual Column-Based Partitioning: Example Consider the example in the slide. The EMPLOYEES table is created using the standard CREATE TABLE syntax. The total_compensation column is a virtual column calculated by multiplying the value of salary by the commission_pct plus one. The next statement declares total_compensation (a virtual column) to be the partitioning key of the EMPLOYEES table.
Partition pruning takes place for virtual column partition keys when the predicates on the partitioning key are of the following types: Equality or Like List Range Partition-extended names Given a join operation between two tables, the optimizer recognizes when a partitionwise join (full or partial) is applicable, decides whether to use it or not, and annotates the join properly when it decides to use it. This applies to both serial and parallel cases. In order to recognize full partitionwise joins, the optimizer relies on the definition of equipartitioning of two objects; this definition includes the equivalence of the virtual expression on which the tables were partitioned.
Reference Partitioning Reference partitioning provides the ability to partition a table based on the partitioning scheme of the table referenced in its referential constraint. The partitioning key is resolved through an existing parent/child relationship, which is enforced by active primary key or foreign key constraints. The benefit of this is that tables with a parent/child relationship can be logically equipartitioned by inheriting the partitioning key from the parent table without duplicating the key columns. The logical dependency also automatically cascades partition maintenance operations, making application development easier and less error prone.
Reference Partitioning: Benefit As illustrated in the slide, you can see the benefit of using reference partitioning. The left part of the graphic shows you the situation where you have two tables, ORDERS and ORDER_ITEMS, that are equipartitioned on the ORDER_DATE column. In that case, both tables need to define the ORDER_DATE column. However, defining ORDER_DATE in the ORDER_ITEMS table is redundant because there is a primary key/foreign key relationship between the two tables.
The right part of the graphic shows you the situation where you use reference partitioning. This time, you no longer need to define the ORDER_DATE column in the ORDER_ITEMS table. The partition key of the ORDER_ITEMS table is automatically inherited from the primary key/foreign key relationship that exists. When used for pruning and partitionwise joins, reference partitioning has the benefit that query predicates can be different and partitionwise joins still workfor example, partitioning on ORDER_DATE and search on ORDER_ID. With previous releases, both partitioning and predicates had to be identical for a partitionwise join to work. Note: This partitioning method can be useful for nested table partitioning.
Reference Partitioning: Example The example in the slide creates two tables: ORDERS: Range-partitioned table partitioned on order_date. It is created with four partitions, Q105, Q205, Q305, and Q405. ORDER_ITEMS: Reference-partitioned child table: - This table is created with four partitionsQ105, Q205, Q305, and Q405with each containing rows corresponding to ORDERS in the respective parent partition. - If partition descriptors are provided, the number of partitions described must be exactly equal to the number of partitions or subpartitions in the referenced table. - If the parent table is a composite-partitioned table, then the table will have one partition for each subpartition of its parent. - Partition bounds cannot be specified for the partitions of a reference-partitioned table. The partitions of a reference-partitioned table can be named unless there is a conflict with inherited names. In this case, the partition will have a system-generated name. - Partitions of a reference-partitioned table will collocate with the corresponding partition of the parent table, if no explicit tablespace is specified. As with other partitioned tables, you can specify object-level default attributes, and partition descriptors that override object-level defaults. - It is not possible to disable the foreign key constraint of a reference-partitioned table. - It is not permitted to add or drop partitions of a reference-partitioned table. However,
performing partition maintenance operations on the parent table is automatically cascaded to the child table.
Composite Partitioning Enhancements Before the release of Oracle Database 11g, the only composite partitioning methods supported were range-list and range-hash. With this new release, list partitioning can be a top-level partitioning method for composite partitioned tables giving us list-list, list-hash, list-range, and range-range composite methods. With the introduction of interval partitioning, interval-range, interval-list, and interval-hash are now supported composite partitioning methods. Range-Range Partitioning Composite range-range partitioning enables logical range partitioning along two dimensions; for example, range partition by order_date and range subpartition by shipping_date. List-Range Partitioning Composite list-range partitioning enables logical range subpartitioning within a given list partitioning strategy; for example, list partition by country_id and range subpartition by order_date. List-Hash Partitioning Composite list-hash partitioning enables hash subpartitioning of a list-partitioned object; for example, to enable partitionwise joins. List-List Partitioning
Composite list-list partitioning enables logical list partitioning along two dimensions; for example, list partition by country_id and list subpartition by sales_channel.
Composite Range-Range Partitioning: Example Composite range-range partitioning enables logical range partitioning along two dimensions. In the example in the slide, the SALES table is created and range-partitioned on time_id. Using a subpartition template, the SALES table is subpartitioned by range using cust_id as the subpartition key. Because of the template, all partitions have the same number of subpartitions with the same bounds as defined by the template. If no template is specified, a single default partition bound by MAXVALUE (range) or DEFAULT value (list) is created. Although the example illustrates the range-range methodology, the other new composite partitioning methods use similar syntax and statement structure. All of the composite partitioning methods fully support the existing partition pruning methods for queries involving predicates on the subpartitioning key.
Table Compression: Overview The Oracle database was the pioneer in terms of compression technology for databases with the introduction of table compression for bulk load operations in Oracle9i. Using this feature, you could compress data at the time of performing bulk load using operations such as direct loads, or Create Table As Select (CTAS). However, until now, compression was not available for regular data manipulation operations such as INSERT, UPDATE, and DELETE. Oracle Database 11g extends the compression technology to support these operations as well. Consequently, compression in Oracle Database 11g can be used for all kinds of workload, be it online transaction processing (OLTP) or data warehousing. It is important to mention that table compression enhancements introduced in Oracle database 11g are not just incremental changes. An enormous amount of work has gone into making sure that the new compression technology has negligible impact on updates because any noticeable write time penalty due to compression will not be acceptable in an OLTP environment. As a result, compression technology in Oracle Database 11g is very efficient and could reduce the space consumption by 5075%. And while you do that, not only your write performance does not degrade, but also your read performance or queries improve. This is because unlike desktopbased compression techniques where you have to wait for data to be uncompressed, Oracle technology reads the compressed data (less fetches needed) directly and does not require any uncompress operation. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 340 Administrators 9 - 340
Note: Compression technology is completely application transparent. This means that you can use this technology with any homegrown or packaged application such as SAP, Siebel, EBS, and so on.
Table Compression Concepts The slide shows you a data block evolution when that block is part of a compressed table. You should read it from left to right. At the start, the block is empty and available for inserts. When you start inserting into this block, data is stored in an uncompressed format (like for uncompressed tables). However, as soon as you reach the PCTFREE of that block, the data is automatically compressed, potentially reducing the space it originally occupied. This allows for new uncompressed inserts to take place in the same block, until PCTFREE is reached again. At that point compression is triggered again to reduce space occupation in the block. Note: Compression eliminates holes created due to deletions and maximizes contiguous free space in blocks.
Using Table Compression To use the new compression algorithm, you must flag your table with the COMPRESS FOR ALL OPERATIONS clause. You can do so at table creation, or after creation. This is illustrated in the examples given in the slide. If you use the COMPRESS clause without specifying any FOR option, or if you use the COMPRESS FOR DIRECT_LOAD OPERATIONS clause, you fall back to the old compression mechanism that was available in earlier releases. You can also enable compression at the partition or tablespace level. For example, you can use the DEFAULT storage clause of the CREATE TABLESPACE command to optionally specify a COMPRESS FOR clause. Note: You can view compression flags for your tables using the COMPRESS and COMPRESS_FOR columns in views such as DBA_TABLES and DBA_TAB_PARTITIONS.
SQL Access Advisor: Overview Defining appropriate access structures to optimize SQL queries has always been a concern for an Oracle DBA. As a result, there have been many papers and scripts written as well as high-end tools developed to address the matter. In addition, with the development of partitioning and materialized view technology, deciding on access structures has become even more complex. As part of the manageability improvements in Oracle Database 10g and 11g, SQL Access Advisor has been introduced to address this very critical need. SQL Access Advisor identifies and helps resolve performance problems relating to the execution of SQL statements by recommending which indexes, materialized views, materialized view logs, or partitions to create, drop, or retain. It can be run from Database Control or from the command line by using PL/SQL procedures. SQL Access Advisor takes an actual workload as input, or the Advisor can derive a hypothetical workload from the schema. It then recommends the access structures for faster execution path. It provides the following advantages: Does not require you to have expert knowledge Bases decision making on rules that actually reside in the cost-based optimizer Is synchronized with the optimizer and Oracle database enhancements Is a single advisor covering all aspects of SQL access methods Provides simple, user-friendly GUI wizards Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 343 Administrators 9 - 343
Generates scripts for implementation of recommendations
SQL Access Advisor: Usage Model SQL Access Advisor takes as input a workload that can be derived from multiple sources: SQL cache, to take the current content of V$SQL Hypothetical, to generate a likely workload from your dimensional model. This option is interesting when your system is being initially designed. SQL Tuning Sets, from the workload repository
SQL Access Advisor also provides powerful workload filters that you can use to target the tuning. For example, a user can specify that the advisor should look at only the 30 most resourceintensive statements in the workload, based on optimizer cost. For the given workload, the advisor then does the following: Simultaneously considers index solutions, materialized view solutions, partition solutions, or combinations of all three Considers storage for creation and maintenance costs Does not generate drop recommendations for partial workloads Optimizes materialized views for maximum query rewrite usage and fast refresh Recommends materialized view logs for fast refresh Recommends partitioning for tables, indexes, and materialized views Combines similar indexes into a single index
Generates recommendations that support multiple workload queries
Possible Recommendations SQL Access Advisor carefully considers the overall impact of recommendations and makes recommendations by using only the known workload and supplied information. Two workload analysis methods are available: Comprehensive: With this approach, SQL Access Advisor addresses all aspects of tuning partitions, materialized views, indexes, and materialized view logs. It assumes that the workload contains a complete and representative set of application SQL statements. Limited: Unlike the comprehensive workload approach, a limited workload approach assumes that the workload contains only problematic SQL statements. Thus, advice is sought for improving the performance of a portion of an application environment. When comprehensive workload analysis is chosen, SQL Access Advisor forms a better set of global tuning adjustments, but the effect may be a longer analysis time. As shown in the table, the chosen workload approach determines the type of recommendations made by the advisor. Note: Partition recommendations can work on only those tables that have at least 10,000 rows, and workloads that have some predicates and joins on columns of NUMBER or DATE type. Partitioning advices can be generated only on these types of columns. In addition, partitioning advices can be generated only for single-column interval and hash partitions. Interval partitioning recommendations can be output as range syntax but interval is the default. Hash
partitioning is done to leverage only partitionwise joins.
SQL Access Advisor Session: Initial Options The next few slides describe a typical SQL Access Advisor session. You can access the SQL Access Advisor wizard through the Advisor Central link on the Database Home page or through individual alerts or performance pages that may include a link to facilitate solving a performance problem. The SQL Access Advisor wizard consists of several steps during which you supply the SQL statements to tune and the types of access methods you want to use.
Use the SQL Access Advisor: Initial Options page to select a template or task from which to populate default options before starting the wizard. You can click Continue to start the wizard or Cancel to go back to the Advisor Central page. Note: The SQL Access Advisor may be interrupted while generating recommendations, thereby allowing the results to be reviewed. For general information about using SQL Access Advisor, see the Overview of the SQL Access Advisor section in the SQL Access Advisor lesson of the Oracle Data Warehousing Guide.
SQL Access Advisor Session: Initial Options (continued) If you choose the Inherit Options from a Task or Template option on the Initial Options page, you are able to select an existing task, or an existing template to inherit SQL Access Advisors options. By default, the SQLACCESS_EMTASK template is used. You can view the various options defined by a task or a template by selecting the corresponding object and clicking View Options.
SQL Access Advisor: Workload Source You can choose your workload source from three different sources: Current and Recent SQL Activity: This source corresponds to SQL statements that are still cached in your SGA. Use an existing SQL Tuning Set: You also have the possibility to create and use a SQL Tuning Set that holds your statements. Hypothetical Workload: This option provides a schema that allows the advisor to search for dimension tables and produce a workload. This is very useful to initially design your schema. Using the Filter Options section, you can further filter your workload source. Filter options are: Resource Consumption: Number of statements ordered by Optimizer Cost, Buffer Gets, CPU Time, Disk Reads, Elapsed Time, Executions. Users Tables SQL Text Module IDs Actions
SQL Access Advisor: Recommendation Options Use the Recommendations Options page to choose whether to limit the SQL Access Advisor to recommendations based on a single access method. You can choose the type of structures to be recommended by the advisor. If none of the three possible ones are chosen, the advisor evaluates existing structures instead of trying to recommend new ones. You can use the Advisor Mode section to run the advisor in one of two modes. These modes affect the quality of recommendations as well as the length of time required for processing. In Comprehensive mode, the Advisor searches a large pool of candidates resulting in recommendations of the highest quality. In Limited mode, the advisor performs quickly, limiting the candidate recommendations by working on the highest-cost statements only.
SQL Access Advisor: Recommendation Options (continued) You can choose Advanced Options to show or hide options that allow you to set space restrictions, tuning options, and default storage locations. Use the Workload Categorization section to set options for workload volatility and scope. For workload volatility, you can choose to favor read-only operations or you can consider the volatility of referenced objects when forming recommendations. For workload scope, you can select Partial Workload, which does not include recommendations to drop unused access structures, or Complete Workload, which includes recommendations to drop unused access structures. Use the Space Restrictions section to specify a hard space limit, which forces the advisor to produce only recommendations with total space requirements that do not exceed the specified limit. Use the Tuning Options section to specify options that customize the recommendations made by the advisor. The Prioritize Tuning of SQL Statements by drop-down list allows you to prioritize by Optimizer Cost, Buffer Gets, CPU Time, Disk Reads, Elapsed Time, and Execution Count. Use the Default Storage Locations section to override the defaults defined for schema and tablespace locations. By default, indexes are placed in the schema and tablespace of the table they reference. Materialized views are placed in the schema and tablespace of the user who executed one of the queries that contributed to the materialized view recommendation. Note: Oracle highly recommends that you specify the default schema and tablespaces for
materialized views.
SQL Access Advisor: Schedule and Review You can then schedule and submit your new analysis by specifying various parameters to the scheduler. The possible options are shown in the screenshots in the slide.
SQL Access Advisor: Results From the Advisor Central page, you can retrieve the task details for your analysis. By selecting the task name in the Results section of the Advisor Central page, you can access the Results for Task Summary page from where you can see an overview of the Access Advisor findings. The page shows you charts and statistics that provide overall workload performance and potential for improving query execution time for the recommendations. You can use the page to show statement counts and recommendation action counts.
SQL Access Advisor: Results (continued) To see other aspects of the results for the Access Advisor task, choose one of the three other tabs on the page, Recommendations, SQL Statements, or Details. On the Recommendation page, you can drill down to each of the recommendations. For each of them, you can see important information in the Select Recommendations for Implementation table. You can then select one or more recommendations and schedule their implementation. If you click the ID for a particular recommendation, you are taken to the Recommendation page that displays all actions for the specified recommendation and, optionally, to modify the tablespace name of the statement. When you complete any changes, choose OK to apply the changes. From that page, you can view the full text of an action by choosing the link in the Action field for the specified action. You can view the SQL for all actions in the recommendation by clicking Show SQL.
SQL Access Advisor: Recommendation Implementation Most of these recommendations can be executed on a production system by using simple SQL DDL statements. For those cases, SQL Advisor produces executable SQL statements. In some instances, for example, repartitioning existing partitioned tables or existing dependent indexes, simple SQL is not sufficient. SQL Advisor then generates a script calling external packages such as DBMS_REDEFINITION in order to enable the user to implement the recommended change.
In the slide example, the SQL Access Advisor makes the recommendation to partition the SH.CUSTOMERS table on the CUST_CREDIT_LIMIT column. The recommendation uses the INTERVAL partitioning scheme, and defines the first range of values as being less than 1600. Interval partitions are partitions based on a numeric range or date-time interval. They extend range partitioning by instructing the database to create partitions of the specified interval automatically when data inserted into the table exceeds all of the range partitions.
SQL Access Advisor: Results The SQL Statements page shows you a chart and a corresponding table that list SQL statements initially ordered by the largest cost improvement. The top SQL statement is improved the most by implementing its associated recommendation.
SQL Access Advisor: Results (continued) The Details page shows you the workload and task options that were used when the task was created. This page also gives you all journal entries that were logged during the task execution.
SQL Access Advisor: PL/SQL Procedure Flow The graphic shows the typical operational flow of the SQL Access Advisor procedures from the DBMS_ADVISOR package. You can find a complete description of each of these procedures in the Oracle Database PL/SQL Packages and Types Reference guide. Step 1: Create and manage tasks and data. This step uses a SQL Access Advisor task. Step 2: Prepare tasks for various operations. This step uses SQL Access Advisor parameters. Step 3: Prepare and analyze data. This step uses SQL Tuning Sets and SQL Access Advisor tasks. With Oracle Database 11g R1, GET_TASK_REPORT can report back using HTML or XML in addition to just text. Note: The DBMS_ADVISOR.QUICK_TUNE procedure is a shortcut that performs all the necessary operations to analyze a single SQL statement. The operation creates a task for which all parameters are defaulted. The workload is constituted by the specified statement only. Finally, the task is executed and the results are saved in the repository. You can also instruct the procedure to implement the final recommendations.
SQL Access Advisor: PL/SQL Example Matching the order shown in the previous slide, the examples in this slide show you a possible SQL Access Advisor tuning session using PL/SQL code. The first PL/SQL block creates a new tuning task called MYTASK. This task is uses the SQL Access Advisor. The second PL/SQL block sets SQL Access Advisor parameters for MYTASK. In the example, you set ANALYSIS_SCOPE to ALL, which means you generate recommendations for indexes, materialized views, and partitions. Then, you set MODE to COMPREHENSIVE to include all SQL statements that are part of the SQL Tuning Set associated to a future task. The third PL/SQL block associates a workload to MYTASK. Here, you use an existing SQL Tuning Set called MYSTS. You can now execute the tuning task. After its execution completes, you can generate corresponding recommendation scripts as shown in the third example in the slide. Note: For a complete list of SQL Access Advisor parameters (around 50), refer to the Oracle Database PL/SQL Packages and Types Reference guide.
New Features of RMAN Backup and recovery operations are a critical part of securing the availability of information, when an organization needs it, despite various levels of potential failures and errors. With Oracle Database 11g, the Recovery Manager (RMAN) enhancements provide the following benefits: Fast Incremental Backups on Physical Standby Database You can enable block change tracking on a physical standby database (use the existing ALTER DATABASE ENABLE/DISABLE BLOCK CHANGE TRACKING SQL statement). RMAN will then track changed blocks during standby managed recovery. This allows the off-loading of block tracking to the standby database and allows the same fast incremental backups to use the change tracking files that have been available on the primary. This feature enables faster incremental backups on a physical standby database than in previous releases. Improved Block Media Recovery Performance You can use the RECOVER command (formerly the BLOCKRECOVER command) to recover individual data blocks. If flashback logging is enabled and contains older, uncorrupted blocks, then RMAN can use these blocks, thereby speeding up block media recovery.
Optimized Backups Increased Speed of Compression When Preserving Backup Space You can use the CONFIGURE command to choose between the BZIP2 and ZLIB compression algorithms for RMAN backups. The new ZLIB backup compression algorithm can be 40% faster than the previous BZIP2 algorithm. The real-world data warehousing database from one large pharmaceutical company had a compression ratio 2.0:1 with the BZIP2 algorithm, and 1.68:1 with the ZLIB algorithm. Configure the backup compression algorithm with the following command (replace alg_name with either BZIP2 or ZLIB): CONFIGURE COMPRESSION ALGORITHM TO 'alg_name'; Note: For more details, see the Oracle Database Backup and Recovery Reference. Improved Block Corruption Detection In addition to the RMAN-detected block corruptions, Oracle Database 11g also records live block corruptions in the V$DATABASE_BLOCK_CORRUPTION view. The Oracle database automatically updates this view when block corruptions are detected or repaired. The VALIDATE command is enhanced with many new options such as VALIDATE ... BLOCK and VALIDATE DATABASE.
Optimized Backups (continued) Optimized Undo Backup Undo data that is not needed for transaction recovery (for example, for committed transactions), is not backed up. The benefit is reduced overall backup time and storage by not backing up undo that applies to committed transactions. This optimization is automatically enabled. Integration with VSS-Enabled Applications The Volume Shadow Copy Service (VSS) is an infrastructure on Windows. The Oracle VSS Writer is integrated with VSS-enabled applications. So you can use VSS-enabled software and storage systems to back up and restore an Oracle database. A key benefit is the ability to make a shadow copy of an open database. You can also use the BACKUP INCREMENTAL LEVEL 1 ... FROM SCN command in RMAN to make an incremental backup of a VSS shadow copy.
Optimized Backups (continued) Simplified Archive Log Management in a Multiple-Component Environment This feature simplifies archive log management when used by multiple components. It also increases availability when backing up archive logs, when an archive log in the Flash Recovery Area is missing or inaccessible. Enhanced Configuration of Deletion Policies Archived redo logs are eligible for deletion only when not needed by any required components such as Data Guard, Streams, Flashback Database, and so on. In a Data Guard environment, all standby destinations are considered (instead of just mandatory destinations), before marking archive logs to be deleted. This configuration is specified using the CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY command. When you configure an archived log deletion policy, the configuration applies to all archiving destinations, including the Flash Recovery Area. Both BACKUP ... DELETE INPUT and DELETE... ARCHIVELOG use this configuration, as does the Flash Recovery Area. When you back up the recovery area, RMAN can fail over to other archived redo log destinations if the archived redo log in the Flash Recovery Area is inaccessible or corrupted.
New Features of RMAN Intrafile Parallel Backup and Restore for Very Large Files Backups of a single large data file can now use multiple parallel server processes and channels to efficiently distribute the workload. The use of multiple sections improves the performance of backups. Simplified Active Database Duplication You can use the network-aware DUPLICATE command to create a duplicate or a standby database over the network without a need for preexisting database backups. The ease-of-use is especially apparent through the Enterprise Manager GUI. Archival Backups for Long-Term Storage Long-term backups, created with the KEEP option, no longer require all archived logs to be retained, when the backup is online. Instead, archive logs needed to recover the specified data files to a consistent point in time are backed up (along with specified data files and a control file). This functionality reduces archive log backup storage needed for online, long-term KEEP backups, and simplifies the command by using a single format string for all the files needed to restore and recover the backup.
Parallel Backup and Restore for Very Large Files Oracle data files can be up to 128 TB in size. In prior versions, the smallest unit of RMAN backup was an entire file. This is not practical with such large files. In Oracle Database 11g, the workload for each file is distributed among multiple parallel server processes. RMAN can break up a single large file into sections and back up and restore these sections independently, if you specify the SECTION SIZE option. In other words, RMAN can use multiple channels per file. Each channel backs up one file section. Each file section is a contiguous range of blocks in a file. Each file section can be processed independently, either serially or in parallel. Backing up a file in separate sections can both improve the performance and allow large file backups to be restarted. A multisection backup job produces a multipiece backup set. Each piece contains one section of the file. All sections of a multisection backup, except perhaps for the last section, are of the same size. There are a maximum of 256 sections per file. Tip: You should not apply large values of parallelism to back up a large file that resides on a small number of disks. This feature is built into RMAN. No installation is required beyond the normal installation of the Oracle Database 11g. COMPATIBLE must be set to at least 11.0, because earlier releases cannot restore multisection backups.
In Enterprise Manager select Availability > Backup Settings > Backup Set (tabbed page).
Using RMAN Multisection Backups The BACKUP and VALIDATE DATAFILE commands accept a new option:
SECTION SIZE <integer> [M | K | G].
Specify your planned size for each backup section. The option is both a backup-command and backup-spec level option, so that you can apply different section sizes to different files in the same backup job. Viewing metadata about your multisection backup: The V$BACKUP_SET and RC_BACKUP_SET views have a MULTI_SECTION column, which indicates whether this is a multisection backup or not. The V$BACKUP_DATAFILE and RC_BACKUP_DATAFILE views have a SECTION_SIZE column, which specifies the number of blocks in each section of a multisection backup. Zero means a whole-file backup.
Duplicating a Database Prior to Oracle Database 11g, you could create a duplicate database with RMAN for testing or for standby. It required the source database, a copy of a backup on the destination system, and the destination database itself. Oracle Database 11g greatly simplifies this process. You can instruct the source database to perform online image copies and archived log copies directly to the auxiliary instance, by using Enterprise Manager or the FROM ACTIVE DATABASE clause of the RMAN DUPLICATE command. Preexisting backups are no longer needed. The database files are copied from the source to a destination or AUXILIARY instance via an inter-instance network connection. RMAN then uses a memory script (one that is contained only in memory) to complete recovery and open the database.
Active Database Duplication Usage Notes for Active Database Duplication Oracle Net must be aware of the source and destination databases. The FROM ACTIVE DATABASE clause implies network action. If the source database is open, it must have archive logging enabled. If the source database is in mounted state (and not a standby), the source database must have been shut down cleanly. Availability of the source database is not affected by active database duplication. But the source database instance provides CPU cycles and network bandwidth. Enterprise Manager Interface In Enterprise Manager, select Data Movement > Clone Database.
Selecting the Destination Usage Notes for Active Database Duplication Password files are copied to the destination. The destination must have the same SYS user password as the source. In other words, at the beginning of the active database duplication process, both databases (source and destination) must have password files. When creating a standby database, the password file from the primary database overwrites the current (temporary) password file on the standby database. When you use the command line and do not duplicate for a standby database, then you need to use the PASSWORD clause (with the FROM ACTIVE DATABASE clause of the RMAN DUPLICATE command).
Customizing Destination Options Prior to Oracle Database 11g, the SPFILE was not copied, because it requires alterations appropriate for the destination environment. You had to copy the SPFILE into the new location, edit it, and specify it when starting the instance in NOMOUNT mode or on the RMAN command line to be used before opening the newly copied database. With Oracle Database 11g, you provide your list of parameters and desired values and the system sets them. The most obvious parameters are those whose value contains a directory specification. All parameter values that match your choice (with the exception of the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters) are placed. Note the case-sensitivity of parameters: The case must match for PARAMETER_VALUE_CONVERT. With the FILE_NAME_CONVERT parameters, pattern matching is operating system specific. This functionality is equivalent to pausing the database duplication after restoring the SPFILE and issuing ALTER SYSTEM SET commands to modify the parameter file (before the instance is mounted).
The example in the slide shows how to clone a database on the same host and in the same Oracle Home, with the use of different top-level disk locations. The source directories are under u01, the destination under u02: You need to confirm your choice.
Choosing Database Configuration Note how the information you enter is used for the new database.
Scheduling Job Execution Following the steps of the wizard, you can now schedule the job, so that it becomes active according to your specifications.
Reviewing the Job Scroll down to review more details and submit the job. Note that the ORCL database will create the DBTEST database on the same host in the /u02 directory structure.
Database Duplication: Job Run The example of the Job Run page shows the following steps: 1. Source Preparation 2. Create Control File 3. Destination Directories Creation 4. Copy Initialization and Password Files * Skip Copy or Transfer Controlfile 5. Destination Preparation 6. Duplicate Database * Skip Crating Standby Controlfile * Skip Switching Clone Type 7. Recover Database 8. Add Temporary Files 9. Check Database and Run Post Cloning Scripts 10. Add EM Target 11. Cleanup Source Temporary Directory
The RMAN DUPLICATE Command The example assumes that you have previously connected to both the source and the destination instances, which have a common directory structure but different top-level disks. The destination instance uses automatically configured channels. This RMAN DUPLICATE command duplicates an open database. The FROM ACTIVE DATABASE clause indicates that you are not using backups (it implies network action), and that the target is either open or mounted. The SPFILE clause indicates that the SPFILE will be restored and modified before opening the database. The repeating SET clause essentially issues an ALTER SYSTEM SET param = value SCOPE=SPFILE command. You can provide as many of these as necessary. Prerequisites The AUXILIARY instance is at the NOMOUNT state having been started with a minimal PFILE. The PFILE requires only the DB_NAME and REMOTE_LOGIN_PASSWORFILE parameters. The password file must exist and have the same SYS user password as the target. The directory structure must be in place with the proper permission. Connect to AUXILIARY by using the net service name as the SYS user. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 379 Administrators 10 - 379
Duplicating a Standby Database The example in the slide assumes that you are connected to the target and auxiliary instances and that the two environments have the same disk and directory structure. The FOR STANDBY FROM ACTIVE DATABASE clause initiates the creation of a standby database without using backups. The example uses u01 as the disk of the source and u02 as the top-level destination directory. All parameter values that match your choice (with the exception of the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters) are replaced in the SPFILE. If PARAMETER_VALUE_CONVERT sets the file name specified by a parameter, and if SET sets the file name specified by the same parameter, then the SET value overrides the PARAMETER_VALUE_CONVERT setting. If the DB_FILE_NAME_CONVERT clause is specified in the DUPLICATE command, then its file name settings override competing settings specified by SPFILE SET.
Creating Archival Backups with EM If you have business requirements to keep records for a long time, you can use RMAN to create a self-contained archival backup of the database or tablespaces. RMAN does not apply the regular retention policies to this backup. Place your archival backup in a different long-term storage area, other than in the Flash Recovery Area. To keep a backup for a long time, perform the following steps in Enterprise Manager: 1. Select Availability > Schedule Backup > Schedule Customized Backup. 2. Follow the steps of the Schedule Customized Backup wizard until you are on the Settings page. 3. Click Override Current Settings > Policy. In the Override Retention Policy section, you can select to keep a backup for a specified number of days. A restore point is generated based on the backup job name. Backups created with the KEEP option include the SPFILE, control files, and archive redo log files required to restore this backup. This backup is a snapshot of the database at a point in time, and can be used to restore the database to another host.
Creating Archival Backups with RMAN Prior to Oracle Database 11g, if you needed to preserve an online backup for a specified amount of time, RMAN assumed you might want to perform point-in-time recovery for any time within that period and RMAN retained all the archived logs for that time period unless you specified NOLOGS. However, you may have a requirement to simply keep the backup (and what is necessary to keep it consistent and recoverable) for a specified amount of time. With Oracle Database 11g, you can use the KEEP option to generate archival database backups that satisfy business or legal requirements. The KEEP option is an attribute of the backup set (not individual of the backup piece) or copy. The KEEP option overrides any configured retention policy for this backup. You can retain archival backups, so that they are considered obsolete after a specified time (KEEP UNTIL) or never (KEEP FOREVER). The KEEP FOREVER clause requires the use of a recovery catalog. The RESTORE POINT clause creates a consistency point in the control file. It assigns a name to a specific SCN. The SCN is captured just after the data-file backup completes. The archival backup can be restored and recovered for this point in time, enabling the database to be opened. In contrast, the UNTIL TIME clause specifies the date until which the backup must be kept. RMAN includes the data files, archived log files (only those needed to recover an online backup), and the relevant autobackup files. All these files must go to the same media family (or Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 382 Administrators 10 - 382
group of tapes) and have the same KEEP attributes.
Managing Archival Database Backups The CHANGE command changes the exemption status of a backup or copy in relation to the configured retention policy. For example, you can specify CHANGE ... NOKEEP, to make a backup that is currently exempt from the retention policy eligible for the OBSOLETE status. The first example in the slide changes a consistent backup into an archival backup, which you plan to store offsite. Because the database is consistent and, therefore, requires no recovery, you do not need to save archived redo logs with the backup. The second example specifies that any long-term image copies of data files and control files should lose their exempt status and so become eligible to be obsolete according to the existing retention policy: Deprecated clauses: KEEP [LOGS | NOLOGS] Preferred syntax: KEEP RESTORE POINT <rsname> Note: The RESTORE POINT option is not valid with CHANGE. You cannot use CHANGE ... UNAVAILABLE or KEEP for files stored in the Flash Recovery Area.
Managing Recovery Catalogs The basic workflow of managing recovery catalogs is not new. However, it has been enhanced by two important features: the consolidation of RMAN repositories and virtual private catalogs, which allow a separation of responsibilities. 1. Create the recovery catalog. 2. Register your target databases in the recovery catalog. This step enables RMAN to store metadata for the target databases in the recovery catalog. 3. If desired, you can also use the IMPORT CATALOG command to merge recovery catalogs (new in Oracle Database 11g). 4. If needed, catalog any older backups, whose records are no longer stored in the target control file. 5. If needed, create virtual recovery catalogs for specific users and determine the metadata to which they are permitted access (new in Oracle Database 11g). 6. Protect the recovery catalog by including it in your backup and recovery strategy.
Managing Catalogs: Using EM In Enterprise Manager, select Availability > Recovery Catalog Settings and then the activity you want to perform.
The IMPORT CATALOG Command With the IMPORT CATALOG command, you can import the metadata from one recovery catalog schema into a different catalog schema. If you created catalog schemas of different versions to store metadata for multiple target databases, then this command enables you to maintain a single catalog schema for all databases. 1. RMAN must be connected to the destination recovery catalogfor example, the cat111 schemawhich is the catalog into which you want to import catalog data. This is the first step in all examples given in the slide.
IMPORT CATALOG <connectStringSpec> [DBID = <dbid> [, <dbid>,]] [DB_NAME=<dbname>[, <dbname,]] [ NO UNREGISTER ];
<connectStringSpec> is the source recovery catalog connect string. The version of the source recovery catalog schema must be equal to the current version of the RMAN executable. If needed, upgrade the source catalog to the current RMAN version. DBID: You can specify the list of database IDs whose metadata should be imported from the source catalog schema. When not specified, RMAN merges metadata for all database IDs from the source catalog schema into the destination catalog schema. RMAN issues an error if the database whose metadata is merged is already registered in the recovery catalog schema. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 387 Administrators 10 - 387
Creating and Using Virtual Private Catalogs (VPCs) This feature allows a consolidation of RMAN repositories and maintains a separation of responsibilities, which is a basic security requirement. The RMAN catalog has been enhanced to create virtual private RMAN catalogs for groups of databases and users. The catalog owner creates the base catalog and grants the RECOVERY_CATALOG_OWNER privilege to the owner of the virtual catalog. The catalog owner can either grant access to a registered database or grant the REGISTER privilege to the virtual catalog owner. The virtual catalog owner can then connect to the catalog for a particular target or register a target database. After this configuration, the VPC owner uses the virtual private catalog just like a standard base catalog. As catalog owner, you can access all the registered database information in the catalog. You can list all databases registered with the SQL*Plus command:
SELECT DISTINCT db_name FROM DBINC;
As virtual catalog owner, you can see only the databases to which you have been granted access. Note: If a catalog owner has not been granted SYSDBA or SYSOPER on the target database, then most RMAN operations cannot be performed.
Using RMAN Virtual Private Catalogs You create virtual private RMAN catalogs for groups of databases and users. 1. The catalog owner creates the base catalog. 2. The DBA on the catalog database creates the user that will own the virtual private catalog (VPC) and grants him or her the RECOVERY_CATALOG_OWNER privilege. 3. The base catalog owner can grant access for previously registered databases to the VPC owner or grant REGISTER to the VPC owner. The GRANT CATALOG command is:
GRANT CATALOG FOR DATABASE prod1, prod2 TO vpcowner;
The GRANT REGISTER command is:

GRANT REGISTER DATABASE TO vpcowner;
The virtual catalog owner can then connect to the catalog for a particular target or register a target database. After the VPC is configured, the VPC owner uses it just like a standard base catalog.
Using RMAN Virtual Private Catalogs (continued) 4. Create a virtual private catalog. a. If the target database is an Oracle Database 11g database and the RMAN client is an 11g client, you can use the RMAN command:
CREATE VIRTUAL CATALOG;
b. If the target database is Oracle Database 10g Release 2 or earlier (using a compatible client), you must execute the supplied procedure from SQL*Plus:
base_catalog_owner.dbms_rcvcat.create_virtual_catalog;
5. Connect to the catalog using the VPC owner login, and use it as a normal catalog. 6. The virtual catalog owner can see only those databases that have been granted. For most RMAN operations, you additionally need the SYSDBA or SYSOPER privileges on the target database.
New and Enhanced Features for Flashback and LogMiner Organizations often have the requirement to track and store all transactional changes to a record for the duration of its lifetime. You no longer need to build this intelligence into the application. Flashback Data Archive satisfies long-retention requirements (that exceed the undo retention) in a secure way. Oracle Database 11g allows you to flash back selected transactions and all the dependent transactions. This recovery operation uses undo data to create and execute the corresponding compensating transactions that revert the affected data back to its original state. Flashback Transaction or Job Backout increases availability during logical recovery by easily and quickly backing out a specific transaction or a set of transactions, and their dependent transactions, with one command, while the database remains online. In prior releases, administrators were required to install and use the stand-alone Java Console for LogMiner. With the Enterprise Manager interface, administrators have one installation task less and an integrated interface with Flashback Transaction. These enhancements increase ease-of-use and time savings because they provide a task-based, intuitive approach (via the EM graphical user interface), or reduce the complexity of applications.
Flashback Data Archive: Overview A new database object, a flashback data archive is a logical container for storing historical information. It is stored in one or more tablespaces and tracks the history for one or more tables. You specify a retention duration for each flashback data archive. You can group the historical table data by your retention requirements in a flashback data archive. Multiple tables can share the same retention and purge policies.
With the Oracle Total Recall option, Oracle Database 11g has been specifically enhanced to track history with minimal performance impact and to store historical data in compressed form. This efficiency cannot be duplicated by your own triggers, which also cost time and effort to set up and maintain. Operations that invalidate history or prevent historical capture are not allowed, for example, dropping or truncating a table.
Flashback Data Archive Comparison How the Flashback Data Archive technology compares with Flashback Database: Flashback Data Archive offers the ability to access the data as of any point in time without actually changing the current data. This is in contrast with Flashback Database, which takes the database physically back in time. Tracking has to be enabled for historical access, while Flashback Database requires preconfiguration. Flashback Database is an offline operation, which requires resources. Flashback Data Archive is an online operation (historical access seamlessly coexists with current access). Because a new background process is used, it has almost no effect on the existing processes. Flashback Data Archive is enabled at the granularity of a table, whereas Flashback Database works only at the database level. With Flashback Data Archive, you can go back to different points in time for different rows of a table or for different tables, whereas with Flashback Database, you can go back to only one point in time for a particular invocation.
Flashback Data Archive: Overview A flashback data archive is a historical data store. Oracle Database 11g automatically tracks and archives the data in tables enabled for Flashback Data Archive with a new Flashback Data Archive background process, FBDA. You use this feature to satisfy long-retention requirements that exceed the undo retention. Flashback data archives ensure that flashback queries obtain SQL-level access to the versions of database objects without getting a snapshot-too-old error.
A flashback data archive consists of one or more tablespaces or parts thereof. You can have multiple flashback data archives. Each is configured with a specific retention duration. Based on your retention duration requirements, you should create different flashback data archivesfor example, one for all records that must be kept for one year, another for all records that must be kept for two years, and so on. FBDA asynchronously collects and writes original data to a flashback data archive. It does not include the original indexes, because your retrieval pattern of historical information might be quite different than your retrieval pattern of current information. Note: You might want to create appropriate indexes just for the duration of historical queries.
Flashback Data Archive: Architecture The Flashback Data Archive background process, FBDA, starts with the database. 1. FBDA operates first on the undo in the buffer cache. 2. In case the undo has already left the buffer cache, FBDA could also read the required values from the undo segments. 3. FBDA consolidates the modified rows of flashback archiveenabled tables and writes them into the appropriate history tables, which make up the flashback data archive. You can find the internally assigned names of the history tables by querying the *_FLASHBACK_ARCHIVE_TABLES view. History tables are compressed and internally partitioned. The database automatically purges all historical information on the day after the retention period expires. (It deletes the data, but does not destroy the flashback data archive.) For example, if the retention period is 10 days, then every day after the tenth day, the oldest information is deleted; thus leaving only 10 days of information in the archive. This is a way to implement digital shredding.
Preparing Your Database To enable Flashback Data Archive features, ensure that the following tasks are performed: Create one or more tablespaces for the data archives and grant access and the appropriate quota to your archive administrator. Also, grant the ARCHIVE ADMINISTER system privilege to your archive administrator, to allow execution of the following statements: CREATE FLASHBACK ARCHIVE ALTER FLASHBACK ARCHIVE DROP FLASHBACK ARCHIVE To allow a specific user the use a specific flashback data archive, grant the FLASHBACK ARCHIVE object privilege on that flashback data archive to the archive user. The archive user can then enable flashback archive on tables, by using the specific flashback data archive. Example executed as archive administrator:
GRANT FLASHBACK ARCHIVE ON FLA1 TO HR;
Most likely, your users will use other Flashback functionality. To allow access to specific objects during queries, grant the FLASHBACK and SELECT privileges on all objects involved in the query. If your users need access to the DBMS_FLASHBACK package, then you need to grant them the SELECT privilege for this package. Users can then use the DBMS_FLASHBACK.ENABLE and Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 402 Administrators 11 - 402
DBMS_FLASHBACK.DISABLE procedures to enable and disable the flashback data archives.
Preparing Your Database (continued) Oracle Database 11g uses the following defaults database initialization parameters: UNDO_MANAGEMENT='AUTO' UNDO_TABLESPACE='UNDOTBS1' UNDO_RETENTION=900 In other words, Automatic Undo Management is now enabled by default. If needed, enable Automatic Undo Management, as explained in the Oracle Database Administrators Guide. An automatically extensible undo tablespace is created upon database installation. For a fixed-size undo tablespace, the Oracle database automatically tunes the system to give the undo tablespace the best possible undo retention. For an automatically extensible undo tablespace (default), the Oracle database retains undo data to satisfy at a minimum, the retention periods needed by the longest-running query and the threshold of undo retention, specified by the UNDO_RETENTION parameter. Automatic tuning of undo retention generally achieves better results with a fixed-size undo tablespace. If you want to change the undo tablespace to fixed size for this or other reasons, the Undo Advisor can help you determine the proper fixed size to allocate. If you are uncertain about your space requirements and you do not have access to the Undo Advisor, follow these steps: 1. You can start with an automatically extensible undo tablespace. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 403 Administrators 11 - 403
2. Observe it through one business cycle (for example, this could be 1 or 2 days, or longer).
Flashback Data Archive: Workflow The first step is to create a flashback data archive. A flashback data archive consists of one or more tablespaces. You can have multiple flashback data archives. Second, you can optionally specify a default flashback data archive for the system. A flashback data archive is configured with retention time. Data archived in the flashback data archive is retained for the retention time. Third, you can enable flashback archiving (and then disable it again) for a table. While flashback archiving is enabled for a table, some DDL statements are not allowed on that table. By default, flashback archiving is off for any table. Fourth, when you query data past your possible undo retention, your query is transparently rewritten to use historical tables in the flashback data archive.
Flashback Data Archive: Scenario You create a flashback data archive with the CREATE FLASHBACK ARCHIVE statement. You can optionally specify the default flashback data archive for the system. If you omit this option, you can still make this flashback data archive the default later. You need to provide the name of the flashback data archive. You need to provide the name of the first tablespace of the flashback data archive. You can identify the maximum amount of space that the flashback data archive can use in the tablespace. The default is unlimited. Unless your space quota on the first tablespace is unlimited, you must specify this value, or else an ORA-55621 will ensue. You need to provide the retention time (number of days that flashback data archive data for the table is guaranteed to be stored). The basic workflow to create and use a flashback data archive has only three steps: 1. The archive administrator creates a flashback data archive named fla1, which uses up to 10 GB of the tbs1 tablespace, and whose data will be retained for five years. 2. In the second step, the archive user enables the Flashback Data Archive. If Automatic Undo Management is disabled, you receive the error ORA-55614 when you try to modify the table. 3. The third step shows the access of historical data with an AS OF query.
Configuring a Default Flashback Data Archive In the FLASHBACK ARCHIVE clause, you can specify the flashback data archive where the historical data for the table will be stored. By default, the system has no flashback data archive. In the preceding example, the default flashback data archive is specified for the system. You can create a default flashback archive in one of two ways: 1. Specify the name of an existing flashback data archive in the SET DEFAULT clause of the ALTER FLASHBACK ARCHIVE statement. 2. Include DEFAULT in the CREATE FLASHBACK ARCHIVE statement when you create a flashback data archive. You enable and disable flashback archiving for a table with the ALTER TABLE command. You can assign the internal archive table to a specific flashback data archive by specifying the flashback data archive name. If the name is omitted, the default flashback data archive is used. Specify NO FLASHBACK ARCHIVE to disable archiving of a table.
Filling the Flashback Data Archive Space When you are out of space in a flashback data archive, the FBDA and also all foreground processes (that generate tracked undo) raise either an ORA-55617 or an ORA-55623 error. An alert log entry is added, stating that Flashback archive fla1 is full, and archiving is suspended.\n. By default, this occurs when 90% of the assigned space has been used. Examples: 55623, 00000, "Flashback Archive \"%s\" is blocking and tracking on all tables is suspended" // *Cause: Flashback archive tablespace has run out of space. // *Action: Add tablespace or increase tablespace quota for the flashback archive. // 55623, 00000, "Flashback Archive \"%s\" is blocking and tracking on all tables is suspended" // *Cause: Flashback archive tablespace quota is running out. // *Action: Add tablespace or increase tablespace quota for the flashback archive. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 408 Administrators 11 - 408
Maintaining Flashback Data Archives 1. Example 1 adds up to 5 GB of the TBS3 tablespace to the FLA1 flashback data archive. (The archive administrator cannot exceed tablespace quota granted by the DBA.) 2. Example 2 changes the retention time for the FLA1 flashback data archive to two years. 3. Example 3 purges all historical data older than one day from the FLA1 flashback data archive. Normally, purging is done automatically, on the day after your retention time expires. You can also override this for ad hoc clean-up. 4. Example 4 drops the FLA1 flashback data archive and historical data, but not its tablespaces. With the ALTER FLASHBACK ARCHIVE command, you can: - Change the retention time of a flashback data archive - Purge some or all of its data - Add, modify, and remove tablespaces Note: Removing all tablespaces of a flashback data archive causes an error.
Flashback Data Archive: Examples Organizations require historical data stores for several purposes. Flashback Data Archive provides seamless access to historical data with as of queries. You can use Flashback Data Archive for compliance reporting, audit reports, data analysis, and decision support. You want to set up your database so that information in the TAX7_ARCHIVE is automatically deleted, the day after seven years are complete. To do this, you just specify a command as shown in example 1. To retrieve the stock price at the close of business on December 31, 2006, use a query as shown in example 2. You discover that JOEs employee record was deleted by error, and that it still existed at 11:30 on the 12th of June 2007. You can insert it again as shown in example 3.
Flashback Data Archive: DDL Restrictions For the sake of security and legal compliance, the preceding restrictions ensure that data in a flashback data archive cannot be invalidated.
Viewing Flashback Data Archives You can use the dynamic data dictionary views to view tracked tables and flashback data archive metadata. To access the USER_FLASHBACK views, you need table ownership privileges. For the others, you need SYSDBA privileges. Examples: Query the time when the flashback data archive(s) have been created:
SELECT FLASHBACK_ARCHIVE_NAME, CREATE_TIME, STATUS FROM DBA_FLASHBACK_ARCHIVE;
To list the tablespace(s), which are used for flashback data archives:
SELECT * FROM DBA_FLASHBACK_ARCHIVE_TS;
To list the archive table name for a specific table:

SELECT ARCHIVE_TABLE_NAME FROM USER_FLASHBACK_ARCHIVE_TABLES WHERE TABLE_NAME = 'EMPLOYEES';
You cannot retrieve past data from a dynamic performance (V$) view. A query on such a view always returns current data. However, you can perform queries on past data in static data dictionary views, such as *_TABLES.
Guidelines and Usage Tips To ensure database consistency, always perform a COMMIT or ROLLBACK operation before querying past data. Remember that all flashback processing uses the current session settings, such as national language and character set, not the settings that were in effect at the time being queried. To obtain an SCN to use later with a flashback feature, you can use the DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER function. To compute or retrieve a past time to use in a query, use a function return value as a time stamp or an SCN argument. For example, add or subtract an INTERVAL value to the value of the SYSTIMESTAMP function. To query past data at a precise time, use an SCN. If you use a time stamp, the actual time queried might be up to 3 seconds earlier than the time you specify. The Oracle database uses SCNs internally and maps them to time stamps at a granularity of 3 seconds.
Flashback Transaction Backout Flashback Transaction Backout is a logical recovery option to roll back a specific transaction and dependent transactions while the database remains online. A dependent transaction is related by either a write-after-write (WAW) relationship, in which a transaction modifies the same data that was changed by the target transaction, or a primary key constraint relationship, in which a transaction reinserts the same primary key value that was deleted by the target transaction. Flashback Transaction utilizes the undo and the redo generated for undo blocks to create and execute a compensating transaction for reverting the affected data back to its original state.
Flashback Transaction You can use the Flashback Transaction functionality from within Enterprise Manager or with PL/SQL packages.
DBMS_FLASHBACK.TRANSACTION_BACKOUT
Prerequisites In order to use this functionality, supplemental logging must be enabled and the correct privileges established. For example, the HR user in the HR schema decides to use Flashback Transaction for the REGIONS table. The SYSDBA ensures that the database is in archive log mode and performs the following setup steps in SQL*Plus: alter database add supplemental log data; alter database add supplemental log data (primary key) columns; grant execute on dbms_flashback to hr; grant select any transaction to hr; The HR user needs to either own the tables (as is the case in the preceding example) or have the SELECT, UPDATE, DELETE, and INSERT privileges, to allow execution of the compensating undo SQL code.
Flashing Back a Transaction Security Privileges To flash back or back-out a transaction, that is, to create a compensating transaction, you must have the SELECT, FLASHBACK and DML privileges on all affected tables. Conditions of Use Transaction Backout is not support across conflicting DDL. Transaction Backout inherits data type support from LogMiner. See the Oracle Database 11g documentation for supported data types. Recommendation When you discover the need for a transaction backout, performance is better, if you start the backout operation sooner. Large redo logs and high transaction rates result in slower transaction backout operations. Provide a transaction name for the backout operation to facilitate later auditing. If you do not provide a transaction name, it will be automatically generated for you.
Possible Workflow Assume that several transactions occurred as indicated below: connect hr/hr INSERT INTO hr.regions VALUES (5,'Pole'); COMMIT;
UPDATE hr.regions SET region_name='Poles' WHERE region_id = 5; UPDATE hr.regions SET region_name='North and South Poles' WHERE region_id = 5; COMMIT; INSERT INTO hr.countries VALUES ('TT','Test Country',5); COMMIT; connect sys/<password> as sysdba ALTER SYSTEM ARCHIVE LOG CURRENT;
Viewing Data To view the data in a table in Enterprise Manager, select Schema > Tables. While viewing the content of the HR.REGIONS table, you discover a logical problem. Region 20 is misnamed. You decide to immediately address this issue.
Flashback Transaction Wizard In Enterprise Manager, select Schema > Tables > HR.REGIONS, then select Flashback Transaction from the Actions drop-down list, and click Go. This invokes the Flashback Transaction Wizard for your selected table. The Flashback Transaction: Perform Query page is displayed. Select the appropriate time range and add query parameters. (The more specific you can be, the shorter is the search of the Flashback Transaction Wizard.) In Enterprise Manager, Flashback Transaction and LogMiner are seamlessly integrated (as this page demonstrates). Without Enterprise Manager, use the DBMS_FLASHBACK.TRANSACTION_BACKOUT procedure, which is described in the PL/SQL Packages and Types Reference. Essentially, you take an array of transaction IDs as the starting point of your dependency search. For example: CREATE TYPE XID_ARRAY AS VARRAY(100) OF RAW(8); CREATE OR REPLACE PROCEDURE TRANSACTION_BACKOUT( numberOfXIDs NUMBER, -- number of transactions passed as input xids XID_ARRAY, -- the list of transaction ids options NUMBER default NOCASCADE, -- back out dependent txn timeHint TIMESTAMP default MINTIME -- time hint on the txn Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 420 Administrators 11 - 420
start );
Flashback Transaction Wizard (continued) The Flashback Transaction: Select Transaction page displays the transactions according to your previously entered specifications. First, display the transaction details to confirm that you are flashing back the correct transaction. Then select the offending transaction and continue with the wizard.
Flashback Transaction Wizard (continued) The Flashback Transaction Wizard now generates the undo script and flashes back the transaction, but it gives you control to COMMIT this flashback. Click the Transaction ID to review its compensating SQL statements.
Flashback Transaction Wizard (continued) Before you commit the transaction, you can use the Execute SQL area at the bottom of the Flashback Transaction: Review page, to view what the result of your COMMIT will be.
Finishing Up On the Flashback Transaction: Review page, click the Show Undo SQL Script button to view the compensating SQL commands. Click Finish to commit your compensating transaction.
Choosing Other Backout Options The TRANSACTION_BACKOUT procedure checks dependencies, such as: Write-after-write (WAW) Primary and unique constraints A transaction can have a WAW dependency, which means a transaction updates or deletes a row that has been inserted or updated by a dependent transaction. This can occur, for example, in a master/detail relationship of primary (or unique) and mandatory foreign key constraints. To understand the difference between the NONCONFLICT_ONLY and the NOCASCADE_FORCE options, assume that the T1 transaction changes rows R1, R2, and R3 and the T2 transaction changes rows R1, R4, and R5. In this scenario, both transactions update row R1, so it is a conflicting row. The T2 transaction has a WAW dependency on the T1 transaction. With the NONCONFLICT_ONLY option, R2 and R3 are backed out, because there is no conflict and it is assumed that you know what to do with the R1 row. With the NOCASCADE_FORCE option, all three rows (R1, R2, and R3) are backed out. Note: This screenshot is not part of the workflow example, but shows additional details of a more complex situation.
Choosing Other Backout Options (continued) The Flashback Transaction Wizard works as follows: If the DBMS_FLASHBACK.TRANSACTION_BACKOUT procedure with the NOCASCADE option fails (because there are dependent transactions), you can change the recovery options. With the NONCONFLICT_ONLY option, nonconflicting rows within a transaction are backed out, which implies that database consistency is maintained (although the transaction atomicity is broken for the sake of data repair). If you want to forcibly back out the given transactions, without paying attention to the dependent transactions, use the NOCASCADE_FORCE option. The server just executes the compensating DML commands for the given transactions in reverse order of their commit times. If no constraints break, you can proceed to commit the changes, otherwise roll back. To initiate the complete removal of the given transactions and all their dependents in a post order fashion, use the CASCADE option.
Final Steps Without EM The DBA_FLASHBACK_TXN_STATE view contains the current state of a transaction: whether it is alive in the system or effectively backed out. This table is atomically maintained with the compensating transaction. For each compensating transaction, there could be multiple rows, where each row provides the dependency relation between the transactions that have been compensated by the compensating transaction. The DBA_FLASHBACK_TXN_REPORT view provides detailed information about all compensating transactions that have been committed in the database. Each row in this view is associated with one compensating transaction. For a detailed description of these tables, see the Oracle Database Reference.
Viewing Flashback Transaction Metadata You can use the data dictionary views to view information about Flashback Transaction Backouts. Sample content of DBA_ FLASHBACK_TXN_REPORT:
COMPENSATING_XID ---------------COMPENSATING_TXN_NAME ----------------------------------------------------------------------------COMMIT_TI --------XID_REPORT ----------------------------------------------------------------------------USER# ---------0500150069050000 26-JUN-07 <?xml version="1.0" encoding="ISO-8859-1"?> <COMP_XID_REPORT XID="05001500690500 0
Using LogMiner What you already know: LogMiner is a powerful audit tool for Oracle databases, which allows you to easily locate changes in the database, enabling sophisticated data analyses, and providing undo capabilities to roll back logical data corruptions or user errors. LogMiner directly accesses the Oracle redo logs, which are complete records of all activities performed on the database, and the associated data dictionary. The tool offers two interfaces: SQL command line and a GUI interface. What is new: Enterprise Manager Database Control now has an interface for LogMiner. In prior releases, administrators were required to install and use the stand-alone Java Console for LogMiner. With this new interface, administrators have a task-based, intuitive approach to using LogMiner. This improves the manageability of LogMiner. In Enterprise Manager, select Availability > View and Manage Transactions. LogMiner supports the following activities: Specifying query parameters Stopping the query and showing partial results, if the query takes a long time Partial querying, then showing the estimated complete query time Saving the query result Re-mining or refining the query based on initial results Showing transaction details, dependencies, and compensating undo SQL script Flashing back and committing the transaction Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 429 Administrators 11 - 429
For more details see the High-Availability eStudy and documentation.
Oracle Database 11g R1 Fault Management The goals of the fault diagnosability infrastructure are the following: Detecting problems proactively Limiting damage and interruptions after a problem is detected Reducing problem diagnostic time Reducing problem resolution time Simplifying customer interaction with Oracle Support
Ease Diagnosis: Automatic Diagnostic Workflow An always-on, in-memory tracing facility enables database components to capture diagnostic data upon first failure for critical errors. A special repository, called Automatic Diagnostic Repository, is automatically maintained to hold diagnostic information about critical error events. This information can be used to create incident packages to be sent to Oracle Support Services for investigation.
Here is a possible workflow for a diagnostic session: 1. Incident causes an alert to be raised in Enterprise Manager (EM). 2. The DBA can view the alert via the EM Alert page. 3. The DBA can drill down to incident and problem details. 4. DBA or Oracle Support Services can decide or ask for that information to be packaged and sent to Oracle Support Services via MetaLink. The DBA can add files to the data to be packaged automatically.
Automatic Diagnostic Repository (ADR) ADR is a file-based repository for database diagnostic data such as traces, incident dumps and packages, the alert log, Health Monitor reports, core dumps, and more. It has a unified directory structure across multiple instances and multiple products stored outside of any database. It is, therefore, available for problem diagnosis when the database is down. Beginning with Oracle Database 11g R1, the database, Automatic Storage Management (ASM), Cluster Ready Services (CRS), and other Oracle products or components store all diagnostic data in ADR. Each instance of each product stores diagnostic data underneath its own ADR home directory. For example, in a Real Application Clusters environment with shared storage and ASM, each database instance and each ASM instance have a home directory within ADR. ADRs unified directory structure uses consistent diagnostic data formats across products and instances, and a unified set of tools enable customers and Oracle Support to correlate and analyze diagnostic data across multiple instances. Starting with Oracle Database 11g R1, the traditional _DUMP_DEST initialization parameters are ignored. The ADR root directory is known as the ADR base. Its location is set by the DIAGNOSTIC_DEST initialization parameter. If this parameter is omitted or left null, the database sets DIAGNOSTIC_DEST upon startup as follows: If the environment variable ORACLE_BASE is set, DIAGNOSTIC_DEST is set to $ORACLE_BASE. If the environment
variable ORACLE_BASE is not set, DIAGNOSTIC_DEST is set to $ORACLE_HOME/log.
ADRCI: The ADR Command-Line Tool ADRCI is a command-line tool that is part of the fault diagnosability infrastructure introduced in Oracle Database Release 11g. ADRCI enables you to: View diagnostic data within Automatic Diagnostic Repository (ADR). Package incident and problem information into a zip file for transmission to Oracle Support. This is done using a service called Incident Package Service (IPS). ADRCI has a rich command set, and can be used in interactive mode or within scripts. In addition, ADRCI can execute scripts of ADRCI commands in the same way that SQL*Plus executes scripts of SQL and PL/SQL commands. There is no need to log in to ADRCI, because the data in ADR is not intended to be secure. ADR data is secured only by operating system permissions on the ADR directories. The easiest way to package and otherwise manage diagnostic data is with the Support Workbench of Oracle Enterprise Manager. ADRCI provides a command-line alternative to most of the functionality of Support Workbench, and adds capabilities such as listing and querying trace files. The slide example shows you an ADRCI session where you are listing all open incidents stored in ADR.
Note: For more information about ADRCI, refer to the Oracle Database Utilities guide.
V$DIAG_INFO The V$DIAG_INFO view lists all important ADR locations: ADR Base: Path of ADR base ADR Home: Path of ADR home for the current database instance Diag Trace: Location of the text alert log and background/foreground process trace files Diag Alert: Location of an XML version of the alert log Default Trace File: Path to the trace file for your session. SQL Trace files are written here.
Location for Diagnostic Traces The table shown in the slide describes the different classes of trace data and dumps that reside both in Oracle Database 10g and in Oracle Database 11g. With Oracle Database 11g, there is no distinction between foreground and background trace files. Both types of files go into the $ADR_HOME/trace directory. All nonincident traces are stored inside the TRACE subdirectory. This is the main difference compared with previous releases where critical error information is dumped into the corresponding process trace files instead of incident dumps. Incident dumps are placed in files separated from the normal process trace files starting with Oracle Database 11g. Note: The main difference between a trace and a dump is that a trace is more of a continuous output such as when SQL tracing is turned on, and a dump is a one-time output in response to an event such as an incident. Also, a core is a binary memory dump that is port specific. In the slide, $ADR_HOME is used to denote the ADR home directory. However, there is no official environment variable called ADR_HOME.
Viewing the Alert Log Using Enterprise Manager You can view the alert log with a text editor, with Enterprise Manager, or with the ADRCI utility. To view the alert log with Enterprise Manager: 1. Access the Database Home page in Enterprise Manager. 2. Under Related Links, click Alert Log Contents. The View Alert Log Contents page appears. 3. Select the number of entries to view, and then click Go.
Viewing the Alert Log Using ADRCI You can also use ADRCI to view the content of your alert log file. Optionally, you can change the current ADR home. Use the SHOW HOMES command to list all ADR homes, and the SET HOMEPATH command to change the current ADR home. Ensure that operating system environment variables such as ORACLE_HOME are set properly, and then enter the following command at the operating system command prompt: adrci. The utility starts and displays its prompt as shown in the slide. Then use the SHOW ALERT command. To limit the output, you can look at the last records using the TAIL option. This displays the last portion of the alert log (about 20 to 30 messages), and then waits for more messages to arrive in the alert log. As each message arrives, it is appended to the display. This command enables you to perform live monitoring of the alert log. Press CTRLC to stop waiting and return to the ADRCI prompt. You can also specify the amount of lines to be printed if you want. You can also filter the output of the SHOW ALERT command as shown in the bottom example in the slide, where you want to display only those alert log messages that contain the string ORA600. Note: ADRCI allows you to spool the output to a file exactly like in SQL*Plus.
Problems and Incidents To facilitate diagnosis and resolution of critical errors, the fault diagnosability infrastructure introduces two concepts for the Oracle database: problems and incidents. A problem is a critical error in the database. Problems are tracked in ADR. Each problem is identified by a unique problem ID and has a problem key, which is a set of attributes that describe the problem. The problem key includes the ORA error number, error parameter values, and other information. Here is a possible list of critical errors: - All internal Errors ORA-60x errors - All system access violations (SEGV, SIGBUS) - ORA-4020 (Deadlock on library object), ORA-8103 (Object no longer exists), ORA1410 (Invalid ROWID), ORA-1578 (Data block corrupted), ORA-29740 (Node eviction), ORA-255 (Database is not mounted), ORA-376 (File cannot be read at this time), ORA-4030 (Out of process memory), ORA-4031 (Unable to allocate more bytes of shared memory), ORA-355 (The change numbers are out of order), ORA356 (Inconsistent lengths in change description), ORA-353 (Log corruption), ORA7445 (Operating System exception) An incident is a single occurrence of a problem. When a problem occurs multiple times, as is often the case, an incident is created for each occurrence. Incidents are tracked in ADR. Each incident is identified by a numeric incident ID, which is unique within an ADR home. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 444 Administrators 12 - 444
Incident Packaging Service With the Incident Packaging Service (IPS), you can automatically and easily gather all diagnostic data (traces, dumps, health check reports, SQL test cases, and more) pertaining to a critical error and package the data into a zip file suitable for transmission to Oracle Support. Because all diagnostic data relating to a critical error are tagged with that errors incident number, you do not have to search through trace files, dump files, and so on to determine the files that are required for analysis; the Incident Packaging Service identifies all required files automatically and adds them to the package.
Incident Packages To upload diagnostic data to Oracle Support Services, you first collect the data in an incident package. When you create an incident package, you select one or more problems to add to the incident package. The Support Workbench then automatically adds to the incident package the incident information, trace files, and dump files associated with the selected problems. Because a problem can have many incidents (many occurrences of the same problem), by default only the first three and last three incidents for each problem are added to the incident package. You can change this default number on the Incident Packaging Configuration page accessible from the Support Workbench page. After the incident package is created, you can add any type of external file to the incident package, remove selected files from the incident package, or edit selected files in the incident package to remove sensitive data. An incident package is a logical construct only, until you create a physical file from the incident package contents. That is, an incident package starts out as a collection of metadata in ADR. As you add and remove incident package contents, only the metadata is modified. When you are ready to upload the data to Oracle Support Services, you invoke either a Support Workbench or an ADRCI function that gathers all the files referenced by the metadata, places them into a zip file, and then uploads the zip to MetaLink.
EM Support Workbench: Overview The Support Workbench is an Enterprise Manager wizard that helps you through the process of handling critical errors. It displays incident notifications, presents incident details, and enables you to select incidents for further processing. Further processing includes running additional health checks, invoking the IPS to package all diagnostic data about the incidents, adding SQL test cases and selected user files to the package, filing a technical assistance request (TAR) with Oracle Support, shipping the packaged incident information to Oracle Support, and tracking the TAR through its life cycle. You can perform the following tasks with the Support Workbench: View details on problems and incidents. Manually run health checks to gather additional diagnostic data for a problem. Generate additional dumps and SQL test cases to add to the diagnostic data for a problem. Run advisors to help resolve problems. Create and track a service request through MetaLink, and add the service request number to the problem data. Collect all diagnostic data relating to one or more problems into an incident package and then upload the incident package to Oracle Support Services. Close the problem when the problem is resolved.
Oracle Configuration Manager Enterprise Manager Support Workbench uses Oracle Configuration Manager to upload the physical files generated by IPS to MetaLink. If Oracle Configuration Manager is not installed or properly configured, the upload may fail. In this case, a message is displayed with a path to the incident package zip file and a request that you upload the file to Oracle Support manually. You can upload manually with MetaLink.
During an Oracle Database 11g installation, the Oracle Universal Installer has a special Oracle Configuration Manager Registration screen shown in the slide. On that screen, you need to select the Enable Oracle Configuration Manager check box and accept license agreement before you can enter your Customer Identification Number (CSI), your MetaLink account username, and your country code. If you do not configure Oracle Configuration Manager, you will still be able to manually upload incident packages to MetaLink. Note: For more information about Oracle Configuration Manager, see the Oracle Configuration Manager Installation and Administration Guide, available at the following URL: http://www.oracle.com/technology/documentation/oem.html
EM Support Workbench Roadmap The graphic gives a summary of the tasks that you complete to investigate, report, and in some cases, resolve a problem using Enterprise Manager Support Workbench: 1. Start by accessing the Database Home page in Enterprise Manager and reviewing critical error alerts. Select an alert for which to view details. 2. Examine the problem details and view a list of all incidents that were recorded for the problem. Display findings from any health checks that were automatically run. 3. Optionally, run additional health checks and invoke the SQL Test Case Builder, which gathers all required data related to a SQL problem and packages the information in a way that enables the problem to be reproduced by Oracle Support. The type of information that the SQL Test Case Builder gathers includes query being executed, table and index definitions (but no data), optimizer statistics, and initialization parameter settings. 4. Create a service request with MetaLink and optionally record the service request number with the problem information. 5. Invoke a wizard that automatically packages all gathered diagnostic data for a problem and uploads the data to Oracle Support. Optionally, edit the data to remove sensitive information before uploading. 6. Optionally, maintain an activity log for the service request in the Support Workbench. Run Oracle advisors to help repair SQL failures or corrupted data. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 451 Administrators 12 - 451
7. Set status for one, some, or all incidents for the problem to Closed.
View Critical Error Alerts in Enterprise Manager You begin the process of investigating problems (critical errors) by reviewing critical error alerts on the Database Home page. To view critical error alerts, access the Database Home page in Enterprise Manager. From the Home page, you can look at the Diagnostic Summary section from where you can click the Active Incidents link if there are incidents. You can also use the Alerts section and look for critical alerts flagged as Incidents.
When you click the Active Incidents link, you access the Support Workbench page on which you can retrieve details about all problems and corresponding incidents. From there, you can also retrieve all Health Monitor checker run and created packages. Note: The tasks described in this section are all Enterprise Manager based. You can also accomplish all of these tasks with the ADRCI command-line utility. See Oracle Database Utilities for more information about the ADRCI utility.
View Problem Details On the Problems subpage on the Support Workbench page, click the ID of the problem you want to investigate. This takes you to the corresponding Problem Details page. On this page, you can see all incidents that are related to your problem. You can associate your problem with a MetaLink service request and bug number. In the Investigate and Resolve section of the page, you have a Self Service subpage that has direct links to the operation you can perform on this problem. In the same section, the Oracle Support subpage has direct links to MetaLink. The Activity Log subpage shows you the system-generated operations that have occurred on your problem so far. This subpage allows you to add your own comments while investigating your problem. From the Incidents subpage, you can click a related incident ID to get to the corresponding Incident Details page.
View Incident Details After the Incident Details page opens, the Dump Files subpage appears and lists all corresponding dump files. You can then click the eyeglass icon for a particular dump file to visualize the file content with its various sections.
View Incident Details (continued) On the Incident Details page, click Checker Findings to view the Checker Findings subpage. This page displays findings from any health checks that were automatically run when the critical error was detected. Most of the time, you have the option to select one or more findings, and invoke an advisor to fix the issue.
Create a Service Request Before you can package and upload diagnostic information for the problem to Oracle Support, you must create a service request. To create a service request, you need to go to MetaLink first. MetaLink can be accessed directly from the Problem Details page when you click the Go to Metalink button in the Investigate and Resolve section of the page. When MetaLink opens, log in and create a service request in the usual manner.
When done, you have the option to enter that service request for your problem. This is entirely optional and is for your reference only. In the Summary section, click the Edit button that is adjacent to the SR# label, and in the window that opens, enter the SR#, and then click OK.
Package and Upload Diagnostic Data to Oracle Support The Support Workbench provides two methods for creating and uploading an incident package: the Quick Packaging method and the Custom Packaging method. The example in the slide shows you how to use Quick Packaging. Quick Packaging is a more automated method with a minimum of steps. You select a single problem, provide an incident package name and description, and then schedule the incident package upload, either immediately or at a specified date and time. The Support Workbench automatically places diagnostic data related to the problem into the incident package, finalizes the incident package, creates the zip file, and then uploads the file. With this method, you do not have the opportunity to add, edit, or remove incident package files or add other diagnostic data such as SQL test cases. To package and upload diagnostic data to Oracle Support: 1. On the Problem Details page, in the Investigate and Resolve section, click Quick Package. The Create New Package page of the Quick Packaging wizard appears. 2. Enter a package name and description. 3. Enter the service request number to identify your problem. 4. Click Next, and then proceed with the remaining pages of the Quick Packaging wizard. Click Submit on the Review page to upload the package.
Track the SR and Implement Repairs After uploading diagnostic information to Oracle Support, you may perform various activities to track the service request and implement repairs. Among these activities are the following: Add an Oracle bug number to the problem information. To do so, on the Problem Details page, click the Edit button that is adjacent to the Bug# label. This is for your reference only. Add comments to the problem activity log. To do so, complete the following steps: 1. Access the Problem Details page for the problem. 2. Click Activity Log to display the Activity Log subpage. 3. In the Comment field, enter a comment, and then click Add Comment. Your comment is recorded in the activity log. Respond to a request by Oracle Support to provide additional diagnostics. Your Oracle Support representative may provide instructions for gathering and uploading additional diagnostics.
Track the SR and Implement Repairs (continued) On the Incident Details page, you can run an Oracle advisor to implement repairs. Access the suggested advisor in one of the following ways: In the Self-Service tab of the Investigate and Resolve section of the Problem Details page On the Checker Findings subpage of the Incident Details page as shown in the slide The advisors that help you repair critical errors are: Data Recovery Advisor: Corrupted blocks, corrupted or missing files, and other data failures SQL Repair Advisor: SQL statement failures
Close Incidents and Problems When a particular incident is no longer of interest, you can close it. By default, closed incidents are not displayed on the Problem Details page. All incidents, whether closed or not, are purged after 30 days. You can disable purging for an incident on the Incident Details page. To close incidents: 1. Access the Support Workbench home page. 2. Select the desired problem, and then click View. The Problem Details page appears. 3. Select the incidents to close and then click Close. A Confirmation page appears. 4. Click Yes on the Confirmation page to close your incident.
Incident Packaging Configuration As already seen, you can configure various aspects of retention rules and packaging generation. Using the Support Workbench, you can access the Incident Packaging Configuration page from the Related Links section of the Support Workbench page by clicking the Incident Packaging Configuration link. Here are the parameters that you can change: Incident Metadata Retention Period: Metadata is basically information about the data. As for incidents, it is the incident time, ID, size, problem, and so forth. Data is the actual contents of an incident, such as traces. Cutoff Age for Incident Inclusion: This value includes incidents for packaging that are in the range to now. If the cutoff date is 90, for instance, the system only includes the incidents that are within the last 90 days. Leading Incidents Count: For every problem included in a package, the system selects a certain number of incidents from the problem from the beginning (leading) and the end (trailing). For example, if the problem has 30 incidents, and the leading incident count is 5 and the trailing incident count is 4, the system includes the first 5 incidents and the last 4 incidents. Trailing Incidents Count: See above.
Custom Packaging: Create New Package Custom Packaging is a more manual method than Quick Packaging, but gives you greater control over the incident package contents. You can create a new incident package with one or more problems, or you can add one or more problems to an existing incident package. You can then perform a variety of operations on the new or updated incident package, including: Adding or removing problems or incidents Adding, editing, or removing trace files in the incident package Adding or removing external files of any type Adding other diagnostic data such as SQL test cases Manually finalizing the incident package and then viewing incident package contents to determine whether you must edit or remove sensitive data or remove files to reduce incident package size. With the Custom Packaging method, you create the zip file and request upload to Oracle Support as two separate steps. Each of these steps can be performed immediately or scheduled for a future date and time.
To package and upload a problem with Custom Packaging: 1. In the Problems subpage at the bottom of the Support Workbench home page, select the first problem that you want to package, and then click Package.
2. On the Package: Select packaging mode subpage, select the Custom Packaging option, and then click Continue.
Custom Packaging: Manipulate Incident Package On the Customize Package page, you get the confirmation that your new package has been created. This page displays the incidents that are contained in the incident package, plus a selection of packaging tasks to choose from. You run these tasks against the new incident package or the updated existing incident package. As you can see from the slide, you can exclude/include incidents or files as well as many other possible tasks.
Custom Packaging: Finalize Incident Package Finalizing an incident package is used to add correlated files from other components, such as Health Monitor, to the package. Recent trace files and log files are also included in the package. You can finalize a package by clicking the Finish Contents Preparation link in the Packaging Tasks section as shown in the slide. A confirmation page is displayed that lists all files that will be part of the physical package.
Custom Packaging: Generate Package After your incident package has been finalized, you can generate the package file. You need to go back to the corresponding package page and click Generate Upload File. The Generate Upload File page appears. On this page, select the Full or Incremental option to generate a full incident package zip file or an incremental incident package zip file. For a full incident package zip file, all the contents of the incident package (original contents and all correlated data) are always added to the zip file. For an incremental incident package zip file, only the diagnostic information that is new or modified since the last time that you created a zip file for the same incident package is added to the zip file. When done, select the Schedule and click Submit. If you scheduled the generation immediately, a Processing page appears until packaging is finished. This is followed by the Confirmation page, where you can click OK. Note: The Incremental option is unavailable if a physical file was never created for the incident package.
Custom Packaging: Upload Package After you have generated the physical package, you can go back to the Customize Package page on which you can click the View/Send Uploaded Files link in the Packaging Tasks section. This takes you to the View/Send Upload Files page from where you can select your package, and click the Send to Oracle button. The Send to Oracle page appears. There, you can enter the service request number for your problem and choose a Schedule. You can then click Submit.
Viewing and Modifying Incident Packages After a package is created, you can always modify it through customization. For example, go to the Support Workbench page and click the Packages tab. This takes you to the Packages subpage. From this page, you can select a package and delete it, or click the package link to go to the Package Details page. There, you can click Customize to go to the Customize Package page from where you can manipulate your package by adding/removing problems, incidents, or files.
Creating User-Reported Problems Critical errors generated internally to the database are automatically added to Automatic Diagnostic Repository (ADR) and tracked in the Support Workbench. However, there may be a situation in which you want to manually add a problem that you noticed to the ADR so that you can put that problem through the Support Workbench workflow. An example of such a situation would be if the performance of the database or of a particular query suddenly noticeably degraded. The Support Workbench includes a mechanism for you to create and work with such a user-reported problem. To create a user-reported problem, open the Support Workbench page and click the Create UserReported Problem link in the Related Links section. This takes you to the Create User-Reported Problem page from where you are asked to run a corresponding advisor before continuing. This is necessary only if you are not sure about your problem. However, if you already know exactly what is going on, select the issue that describes most the type of problem you are encountering and click Continue with Creation of Problem. By clicking this button, you basically create a pseudo-problem inside the Support Workbench. This allows you to manipulate this problem using the previously seen Support Workbench workflow for handling critical errors. So, you end up on a Problem Details page for your issue. Note that at first the problem does not have any diagnostic data associated with it. At this point,
you need to create a package and upload necessary trace files by customizing that package. This has already been described previously.
Invoking IPS Using ADRCI Creating a package is a two-step process: you first create the logical package, and then generate the physical package as a zip file. Both steps can be performed using ADRCI commands. To create a logical package, the IPS CREATE PACKAGE command is used. There are several variants of this command that allow you to choose the contents: IPS CREATE PACKAGE creates an empty package. IPS CREATE PACKAGE PROBLEMKEY creates a package based on problem key. IPS CREATE PACKAGE PROBLEM creates a package based on problem ID. IPS CREATE PACKAGE INCIDENT creates a package based on incident ID. IPS CREATE PACKAGE SECONDS creates a package containing all incidents generated from seconds ago until now. IPS CREATE PACKAGE TIME creates a package based on the specified time range. It is also possible to add contents to an existing package. For instance: IPS ADD INCIDENT PACKAGE adds an incident to an existing package. IPS ADD FILE PACKAGE adds a file inside ADR to an existing package.
Health Monitor: Overview Beginning with Release 11g, the Oracle database includes a framework called Health Monitor for running diagnostic checks on various components of the database. Health Monitor checkers examine various components of the database, including files, memory, transaction integrity, metadata, and process usage. These checkers generate reports of their findings as well as recommendations for resolving problems. Health Monitor checks can be run in two ways: Reactive: The fault diagnosability infrastructure can run Health Monitor checks automatically in response to critical errors. Manual: As a DBA, you can manually run Health Monitor checks by using either the DBMS_HM PL/SQL package or the Enterprise Manager interface. In the slide, you can see some of the checks that Health Monitor can run. For a complete description of all possible checks, look at V$HM_CHECK. These health checks fall into one of two categories: DB-online: These checks can be run while the database is open (that is, in OPEN mode or MOUNT mode). DB-offline: In addition to being runnable while the database is open, these checks can also be run when the instance is available and the database itself is closed (that is, in
NOMOUNT mode).
Running Health Checks Manually: EM Example Enterprise Manager provides an interface for running Health Monitor checkers. You can find this interface in the Checkers tab on the Advisor Central page. The page lists each checker type, and you can run a checker by clicking it and then OK on the corresponding checker page after you have entered the parameters for the run. The slide shows how you can run the Data Block Checker manually.
After a check is completed, you can view the corresponding checker run details by selecting the checker run from the Results table and clicking Details. Checker runs can be reactive or manual. On the Findings subpage you can see the various findings and corresponding recommendations extracted from V$HM_RUN, V$HM_FINDING, and V$HM_RECOMMENDATION.
If you click View XML Report on the Runs subpage, you can view the run report in XML format. Viewing the XML report in Enterprise Manager generates the report for the first time if it is not yet generated in your ADR. You can then view the report using ADRCI without needing to generate it.
Running Health Checks Manually: PL/SQL Example You can use the DBMS_HM.RUN_CHECK procedure for running a health check. To call RUN_CHECK, supply the name of the check found in V$HM_CHECK, the name for the run (this is just a label used to retrieve reports later), and the corresponding set of input parameters for controlling its execution. You can view these parameters by using V$HM_CHECK_PARAM. In the example in the slide, you want to run a Dictionary Integrity Check for the TAB$ table. You call this run DICOCHECK, and you do not want to set any timeout for this check. After DICOCHECK is executed, you execute the DBMS_HM.GET_RUN_REPORT function to get the report extracted from V$HM_RUN, V$HM_FINDING, and V$HM_RECOMMENDATION. The output clearly shows you that a critical error was found in TAB$. This table contains an entry for a table with an invalid number of columns. Furthermore, the report gives you the name of the damaged table in TAB$. When you call the GET_RUN_REPORT function, it generates the XML report file in the HM directory of your ADR. For this example, the file is called HMREPORT_DicoCheck.hm. Note: Refer to the Oracle Database PL/SQL Packages and Types Reference for more information about DBMS_HM.
Viewing HM Reports Using the ADRCI Utility You can create and view Health Monitor checker reports using the ADRCI utility. To do that, ensure that operating system environment variables such as ORACLE_HOME are set properly, and then enter the following command at the operating system command prompt: adrci. The utility starts and displays its prompt as shown in the slide. Optionally, you can change the current ADR home. Use the SHOW HOMES command to list all ADR homes, and the SET HOMEPATH command to change the current ADR home. You can then enter the SHOW HM_RUN command to list all the checker runs registered in ADR and visible from V$HM_RUN. Locate the checker run for which you want to create a report and note the checker run name using the corresponding RUN_NAME field. The REPORT_FILE field contains a file name if a report already exists for this checker run. Otherwise, you can generate the report using the CREATE REPORT HM_RUN command as shown in the slide. To view the report, use the SHOW REPORT HM_RUN command.
SQL Repair Advisor: Overview You run the SQL Repair Advisor after a SQL statement fails with a critical error that generates a problem in ADR. The advisor analyzes the statement and in many cases recommends a patch to repair the statement. If you implement the recommendation, the applied SQL patch circumvents the failure by causing the query optimizer to choose an alternate execution plan for future executions. This is done without changing the SQL statement itself.
Note: In case no workaround is found by the SQL Repair Advisor, you are still able to package the incident files and send the corresponding diagnostic data to Oracle Support.
Accessing the SQL Repair Advisor Using EM There are basically two ways to access the SQL Repair Advisor from Enterprise Manager. The first and the easiest way is when you get alerted in the Diagnostic Summary section of the database home page. Following a SQL statement crash that generates an incident in ADR, you are automatically alerted through the Active Incidents field. You can click the corresponding link to get to the Support Workbench Problems page from where you can click the corresponding problem ID link. This takes you to the Problem Details page from where you can click the SQL Repair Advisor link in the Investigate and Resolve section of the page.
Accessing the SQL Repair Advisor Using EM (continued) If the SQL statement crash incident is no longer active, you can always go to the Advisor Central page, where you can click the SQL Advisors link and choose the Click here to go to Support Workbench link in the SQL Advisor section of the SQL Advisors page. This takes you directly to the Problem Details page, where you can click the SQL Repair Advisor link in the Investigate and Resolve section of the page.
Note: To access the SQL Repair Advisor in case of nonincident SQL failures, you can go either to the SQL Details page or to SQL Worksheet.
Using the SQL Repair Advisor from EM On the SQL Repair Advisor: SQL Incident Analysis page, specify a Task Name, a Task Description, and a Schedule. When done, click Submit to schedule a SQL diagnostic analysis task. If you specify Immediately, you end up on the Processing: SQL Repair Advisor Task page that shows you the various steps of the task execution.
Using the SQL Repair Advisor from EM (continued) After the SQL Repair Advisor task executes, you are sent to the SQL Repair Results for that task. On this page, you can see a corresponding Recommendations section, especially if SQL Patch was generated to fix your problem. As shown in the slide, you can select the statement for which you want to apply the generated SQL Patch and click View. This takes you to the Repair Recommendations for SQL ID page from where you can ask the system to implement the SQL Patch by clicking Implement after selecting the corresponding Findings. You then get a confirmation for the implementation and you can execute your SQL statement again.
Using the SQL Repair Advisor from PL/SQL: Example It is also possible that you invoke the SQL Repair Advisor directly from PL/SQL. After you get alerted about an incident SQL failure, you can execute a SQL Repair Advisor task by using the DBMS_SQLDIAG.CREATE_DIGNOSIS_TASK function as illustrated in the slide. You need to specify the SQL statement for which you want the analysis to be done, as well as a task name and a problem type you want to analyze (possible values are PROBLEM_TYPE_COMPILATION_ERROR and PROBLEM_TYPE_EXECUTION_ERROR). You can then give the created task parameters by using the DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER procedure. When you are ready, you can execute the task by using the DBMS_SQLDIAG.EXECUTE_DIAGNOSIS_TASK procedure. Finally, you can get the task report by using the DBMS_SQLDIAG.REPORT_DIAGNOSIS_TASK function. In the example given in the slide, it is assumed that the report asks you to implement a SQL Patch to fix the problem. You can then use the DBMS_SQLDIAG.ACCEPT_SQL_PATCH procedure to implement the SQL Patch.
Viewing, Disabling, or Removing a SQL Patch After you apply a SQL patch with the SQL Repair Advisor, you may want to view it to confirm its presence, disable it, or remove it. One reason to remove a patch is if you install a later release of the Oracle database that fixes the problem that caused the failure in the nonpatched SQL statement. To view, disable/enable, or remove a SQL Patch, access the Server page in Enterprise Manager and click the SQL Plan Control link in the Query Optimizer section of the page. This takes you to the SQL Plan Control page. On this page, click the SQL Patch tab. From the resulting SQL Patch subpage, locate the desired patch by examining the associated SQL statement. Select it, and perform the corresponding task: Disable, Enable, or Delete.
Using the SQL Test Case Builder The SQL Test Case Builder automates the somewhat difficult and time-consuming process of gathering as much information as possible about a SQL-related problem and the environment in which it occurred, so that the problem can be reproduced and tested by Oracle Support Services. The information gathered by the SQL Test Case Builder includes the query being executed, table and index definitions (but not the actual data), PL/SQL functions, procedures and packages, optimizer statistics, and initialization parameter settings. From the Support Workbench page, to access the SQL Test Case Builder: 1. Click the corresponding Problem ID to open the problem details page. 2. Click the Oracle Support tab. 3. Click Generate Additional Dumps and Test Cases. 4. On the Additional Dumps and Test Cases page, click the icon in the Go To Task column to run the SQL Test Case Builder against your particular Incident ID. The output of the SQL Test Case Builder is a SQL script that contains the commands required to re-create all the necessary objects and the environment. Note: You can also invoke the SQL Test Case Builder by using the DBMS_SQLDIAG. EXPORT_SQL_TESTCASE_DIR_BY_INC function. This function takes the incident ID as well as a directory object. It generates its output for the corresponding incident in the specified Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 485 Administrators 12 - 485
directory.
Intelligent Resolution: Data Recovery Advisor Data Recovery Advisor: Enterprise Manager integrates with database health checks and RMAN to display data corruption problems, assess the extent of the problem (critical, high priority, or low priority), describe the impact of the problem, recommend repair options, conduct a feasibility check of the customer-chosen option, and automate the repair process. Note: For more information about the Data Recovery Advisor, refer to the corresponding lesson in this course.
Repairing Data Failures A data failure is a missing, corrupted, or inconsistent data, log, control, or other file, whose content the Oracle instance cannot access. When your database has a problem, analyzing the underlying cause and choosing the correct solution is often the biggest component of down time. Oracle Database 11g offers several new and enhanced tools for analyzing and repairing database problems. Data Guard, by allowing you to fail over to a standby database (that has its own copy of the data), enables you to continue operation if the primary database gets a data failure. Then, after failing over to the standby, you can take the time to repair the failed database (old primary) without worrying about the impact on your applications. There are many enhancements to Data Guard. Data Recovery Advisor is a built-in tool that automatically diagnoses data failures and reports the appropriate repair option. If, for example, the Data Recovery Advisor discovers many bad blocks, it recommends restoring the entire file, rather than repairing individual blocks. Therefore, it assists you to perform the correct repair for a failure. You can either repair a data failure manually or request the Data Recovery Advisor to execute the repair for you. This decreases the amount of time to recover from a failure.
Functionality of the Data Recovery Advisor The Data Recovery Advisor automatically gathers data failure information when an error is encountered. In addition, it can proactively check for failures. In this mode, it can potentially detect and analyze data failures before a database process discovers the corruption and signals an error. (Note that repairs are always under human control.) Data failures can be very serious. For example, if your current log files are missing, you cannot start your database. Some data failures (such as block corruptions in data files) are not catastrophic, in that they do not take the database down or prevent you from starting the Oracle instance. The Data Recovery Advisor handles both cases: the one when you cannot start up the database (because some required database files are missing, inconsistent, or corrupted) and the one when file corruptions are discovered during run time. The preferred way to address serious data failures is to first fail over to a standby database, if you are in a Data Guard configuration. This allows users to come back online as soon as possible. Then you need to repair the primary cause of the data failure, but fortunately, this does not impact your users.
Data Recovery Advisor The automatic diagnostic workflow in Oracle Database 11g performs workflow steps for you. With the Data Recovery Advisor, you only need to initiate an advice and a repair. 1. The Health Monitor automatically executes checks and logs failures and their symptoms as findings into Automatic Diagnostic Repository (ADR). For more details about the Health Monitor, see the eStudy titled Diagnosability. 2. The Data Recovery Advisor consolidates findings into failures. It lists the results of previously executed assessments with failure severity (critical or high). 3. When you ask for repair advice on a failure, the Data Recovery Advisor maps failures to automatic and manual repair options, checks basic feasibility, and presents you with the repair advice. 4. You can choose to manually execute a repair or request the Data Recovery Advisor to do it for you. 5. In addition to the automatic, primarily reactive checks of the Health Monitor and Data Recovery Advisor, Oracle recommends to additionally use the VALIDATE command as a proactive check.
Assessing Data Failures This slide illustrates different access routes, which you can use to navigate between the Health Monitor and the Data Recovery Advisor. It also demonstrates the interaction of Health Monitor and Data Recovery Advisor.
Data Failures Data failures are detected by checks, which are diagnostic procedures that assess the health of the database or its components. Each check can diagnose one or more failures, which are mapped to a repair. Checks can be reactive or proactive. When an error occurs in the database, reactive checks are automatically executed. You can also initiate proactive checks, for example, by executing the VALIDATE DATABASE command. In Enterprise Manager, select Availability > Perform Recovery, or click the Perform Recovery button, if you find your database in a down or mounted state.
Data Failure: Examples The Data Recovery Advisor can analyze failures and suggest repair options for issues, as outlined in the slide.
Listing Data Failures On the Perform Recovery page, click Advise and Repair. The View and Manage Failures page is the home page of the Data Recovery Advisor. The example in the screenshot shows how the Data Recovery Advisor lists data failures and details. Activities that you can initiate include advising, setting priorities, and closing failures. The underlying RMAN LIST FAILURE command can also display data failures and details. Failure assessments are not initiated here; they are previously executed and stored in ADR. Failures are listed in decreasing priority order: CRITICAL, HIGH, and LOW. Failures with the same priority are listed in increasing time-stamp order.
Advising on Repair On the View and Manage Failures page, after you click the Advise button, the Data Recovery Advisor generates a manual checklist. Two types of failures could appear: Failures that require human intervention. An example is a connectivity failure, when a disk cable is not plugged in. Failures that are repaired faster if you can undo a previous erroneous action. For example, if you renamed a data file by error, it is faster to rename it back, rather than initiate RMAN restoration from backup. You can initiate the following actions: Click Re-assess Failures after you have performed a manual repair. Failures, which are resolved, are implicitly closed; any remaining ones are displayed on the View and Manage Failures page. Click Continue with Advise to initiate an automated repair. When the Data Recovery Advisor generates an automated repair option, it generates a script that shows you how RMAN plans to repair the failure. Click Continue, if you want to execute the automated repair. If you do not want the Data Recovery Advisor to automatically repair the failure, then you can use this script as a starting point for your manual repair.
Executing Repairs In the preceding example, the Data Recovery Advisor executes a successful repair in less than one second.
Data Recovery Advisor: RMAN Command-Line Interface If you suspect or know that a database failure has occurred, then use the LIST FAILURE command to obtain information about these failures. You can list all or a subset of failures and restrict output in various ways. Failures are uniquely identified by failure numbers. Note that these numbers are not consecutive, so gaps between failure numbers have no significance. The ADVISE FAILURE command displays a recommended repair option for the specified failures. It prints a summary of the input failure and implicitly closes all open failures that are already fixed. The default behavior when no option is used is to advise on all the CRITICAL and HIGH priority failures that are recorded in ADR. The REPAIR FAILURE command is used after an ADVISE FAILURE command within the same RMAN session. By default, the command uses the single, recommended repair option of the last ADVISE FAILURE execution in the current session. If none exists, the REPAIR FAILURE command initiates an implicit ADVISE FAILURE command. After completing the repair, the command closes the failure. The CHANGE FAILURE command changes the failure priority or closes one or more failures. You can change a failure priority only for HIGH or LOW priorities. Open failures are closed implicitly when a failure is repaired. However, you can also explicitly close a failure.
Listing Data Failures The RMAN LIST FAILURE command lists failures. If the target instance uses a recovery catalog, it can be in STARTED mode, otherwise it must be in MOUNTED mode. The LIST FAILURE command does not initiate checks to diagnose new failures; rather, it lists the results of previously executed assessments. Repeatedly executing the LIST FAILURE command revalidates all existing failures. If the database diagnoses new ones (between command executions), they are displayed. If a user manually fixes failures, or if transient failures disappear, then the Data Recovery Advisor removes these failures from the LIST FAILURE output. The following is a description of the syntax: failnum: Number of the failure to display repair options for ALL: List failures of all priorities. CRITICAL: List failures of CRITICAL priority and OPEN status. These failures require immediate attention, because they make the whole database unavailable (for example, a missing control file). HIGH: List failures of HIGH priority and OPEN status. These failures make a database partly unavailable or unrecoverable; so they should be repaired quickly (for example, missing archived redo logs).
LOW: List failures of LOW priority and OPEN status. Failures of a low priority can wait, until more important failures are fixed. CLOSED: List only closed failures.
Advising on Repair The RMAN ADVISE FAILURE command displays a recommended repair option for the specified failures. If this command is executed from within Enterprise Manager, then Data Guard is presented as a repair option. (This is not the case, if the command is executed directly from the RMAN command line). The ADVISE FAILURE command prints a summary of the input failure. The command implicitly closes all open failures that are already fixed. The default behavior (when no option is used) is to advise on all the CRITICAL and HIGH priority failures that are recorded in Automatic Diagnostic Repository (ADR). If a new failure has been recorded in ADR since the last LIST FAILURE command, this command includes a WARNING before advising on all CRITICAL and HIGH failures. Two general repair options are implemented: no-data-loss and data-loss repairs. When the Data Recovery Advisor generates an automated repair option, it generates a script that shows you how RMAN plans to repair the failure. If you do not want the Data Recovery Advisor to automatically repair the failure, then you can use this script as a starting point for your manual repair. The operating system (OS) location of the script is printed at the end of the command output. You can examine this script, customize it (if needed), and also execute it manually if, for example, your audit trail requirements recommend such an action.
Executing Repairs This command should be used after an ADVISE FAILURE command in the same RMAN session. By default (with no option), the command uses the single, recommended repair option of the last ADVISE FAILURE execution in the current session. If none exists, the REPAIR FAILURE command initiates an implicit ADVISE FAILURE command. By default, you are asked to confirm the command execution, because you may be requesting substantial changes, that take time to complete. During execution of a repair, the output of the command indicates what phase of the repair is being executed. After completing the repair, the command closes the failure. You cannot run multiple concurrent repair sessions. However, concurrent REPAIR PREVIEW sessions are allowed. PREVIEW means: Do not execute the repair(s); instead, display the previously generated RMAN script with all repair actions and comments. NOPROMPT means: Do not ask for confirmation.
Classifying (and Closing) Failures The CHANGE FAILURE command is used to change the failure priority or close one or more failures. Syntax
CHANGE FAILURE { ALL | CRITICAL | HIGH | LOW | failnum[,failnum,] } [ EXCLUDE FAILURE failnum[,failnum,] ] { PRIORITY {CRITICAL | HIGH | LOW} | CLOSE } change status of the failure(s) to closed [ NOPROMPT ] do not ask user for a confirmation
A failure priority can be changed only from HIGH to LOW and from LOW to HIGH. It is an error to change the priority level of CRITICAL. (One reason why you may want to change a failure from HIGH to LOW is to avoid seeing it on the default output list of the LIST FAILURE command. For example, if a block corruption has HIGH priority, you may want to temporarily change it to LOW if the block is in a little-used tablespace.) Open failures are closed implicitly when a failure is repaired. However, you can also explicitly close a failure. This involves a reevaluation of all other open failures, because some of them may become irrelevant as the result of the closure of the failure.
By default, the command asks the user to confirm a requested change.
Data Recovery Advisor Views A usage example: Assume that you need to display all failures that were detected on June 21, 2007.
SELECT * FROM v$ir_failure WHERE trunc (time_detected) = '21-JUN-2007';
(Output formatted to fit page)

FAILURE_ID DESCRIPTION IMPACTS 142 0 0 PERSISTENT_DATA One or more non-system datafiles are missing See impact for individual child failures PRIORITY STATUS 21-JUN-07 21-JUN-07 HIGH CLOSED PARENT_ID CHILD_COUNT CLASS_NAME TIME_DETE MODIFIED
145 142 0 PERSISTENT_DATA 21-JUN-07 21-JUN-07 Datafile 4: '/u01/app/oracle/oradata/orcl/users01.dbf' is missing Some objects in tablespace USERS might be unavailable HIGH CLOSED 151 142 0 PERSISTENT_DATA 21-JUN-07 21-JUN-07 Datafile 5: '/u01/app/oracle/oradata/orcl/example01.dbf' is missing Some objects in tablespace EXAMPLE might be unavailable HIGH CLOSED
See the Oracle Database Reference for details of the dynamic data dictionary views that the Data Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 511 Administrators 13 - 511
Recovery Advisor uses.
Best Practice: Proactive Checks For very important databases, you may want to execute additional proactive checks (possibly daily during low peak interval periods). You can schedule periodic health checks through the Health Monitor or by using the RMAN VALIDATE command. In general, when a reactive check detects failure(s) in a database component, you may want to execute a more complete check of the affected component. The RMAN VALIDATE DATABASE command is used to invoke health checks for the database and its components. It extends the existing VALIDATE BACKUPSET command. Any problem detected during validation is displayed to you. Problems initiate the execution of a failure assessment. If a failure is detected, it is logged into ADR as a finding. You can use the LIST FAILURE command to view all failures recorded in the repository. The VALIDATE command supports validation of individual backup sets and data blocks. In a physical corruption, the database does not recognize the block at all. In a logical corruption, the contents of the block are logically inconsistent. By default, the VALIDATE command checks for physical corruption only. You can specify CHECK LOGICAL to check for logical corruption as well.
Setting Parameters to Detect Corruption You can use the DB_ULTRA_SAFE parameter for easy manageability. It affects the default values of the following parameters: DB_BLOCK_CHECKING, which initiates checking of database blocks. This check can often prevent memory and data corruption. (Default: FALSE, recommended: FULL) DB_BLOCK_CHECKSUM, which initiates the calculation and storage of a checksum in the cache header of every data block when writing it to disk. Checksums assist in detecting corruption caused by underlying disks, storage systems, or I/O systems. (Default: TYPICAL, recommended: TYPICAL) DB_LOST_WRITE_PROTECT, which initiates checking for lost writes. Data block lost writes occur on a physical standby database, when the I/O subsystem signals the completion of a block write, which has not yet been completely written in persistent storage. Of course, the write operation has been completed on the primary database. (Default: TYPICAL, recommended: TYPICAL) If you set any of these parameters explicitly, then your values remain in effect. The DB_ULTRA_SAFE parameter (which is new in Oracle Database 11g) changes only the default values for these parameters.
Setting Parameters to Detect Corruption (continued) Depending on your systems tolerance for block corruption, you can intensify the checking for block corruption. Enabling the DB_ULTRA_SAFE parameter (default: OFF) results in increased system overhead, because of these more intensive checks. The amount of overhead is related to the number of blocks changed per second; so it cannot be easily quantified. For a high-update application, you can expect a significant increase in CPU, likely in the ten to twenty percent range, but possibly higher. This overhead can be alleviated by allocating additional CPUs. When the DB_ULTRA_SAFE parameter is set to DATA_ONLY, then the DB_BLOCK_CHECKING parameter is set to MEDIUM. This checks that data in a block are logically self-consistent. Basic block header checks are performed after block contents change in memory (for example, after UPDATE or INSERT commands, on-disk reads, or inter-instance block transfers in Oracle RAC). This level of checks includes semantic block checking for all non-index-organized table blocks. When the DB_ULTRA_SAFE parameter is set to DATA_AND_INDEX, then the DB_BLOCK_CHECKING parameter is set to FULL. In addition to the preceding checks, semantic checks are executed for index blocks (that is, blocks of subordinate objects that can actually be dropped and reconstructed when faced with corruption). When the DB_ULTRA_SAFE parameter is set to DATA_ONLY or DATA_AND_INDEX, then the DB_BLOCK_CHECKSUM parameter is set to FULL and the Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 516 Administrators 13 - 516
DB_LOST_WRITE_PROTECT parameter is set to TYPICAL.
Secure Password Support You must use more secure passwords to meet the demands of compliance to various security and privacy regulations. Passwords that are very short and passwords that are formed from a limited set of characters are susceptible to brute force attacks. Longer passwords with more different characters allowed make the password much more difficult to guess or find. In Oracle Database 11g, the password is handled differently than in previous versions: Passwords are case-sensitive. Uppercase and lowercase characters are now different characters when used in a password. A password may contain multibyte characters without it being enclosed in quotation marks. A password must be enclosed in quotation marks if it contains any special characters apart from $, _, or #. Passwords are always passed through a hash algorithm, and then stored as a user credential. When the user presents a password, it is hashed and then compared to the stored credential. In Oracle Database 11g, the hash algorithm is SHA-1 of the public algorithm used in previous versions of the database. SHA-1 is a stronger algorithm using a 160-bit key. Passwords always use salt. A hash function always produces the same output, given the same input. Salt is a unique (random) value that is added to the input to ensure that the output credential is unique.
Automatic Secure Configuration Oracle Database 11g installs and creates the database with certain security features recommended by the Center for Internet Security (CIS) benchmark. The CIS recommended configuration is more secure than the 10gR2 default installation; yet open enough to allow the majority of applications to be successful. Many customers have adopted this benchmark already. There are some recommendations of the CIS benchmark that may be incompatible with some applications.
Secure Default Configuration When creating a custom database using the Database Configuration Assistant (DBCA), you can specify the Oracle Database 11g default security configuration. By default, if a user tries to connect to an Oracle instance multiple times using an incorrect password, the instance delays each login after the third try. This protection applies for attempts made from different IP addresses or multiple client connections. Later, it gradually increases the time before the user can try another password, up to a maximum of about ten seconds. The default password profile is enabled with these settings at database creation:
PASSWORD_LIFE_TIME 180 PASSWORD_GRACE_TIME 7 PASSWORD_REUSE_TIME UNLIMITED PASSWORD_REUSE_MAX UNLIMITED FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LOCK_TIME 1 PASSWORD_VERIFY_FUNCTION NULL
When an Oracle Database 10g database is upgraded, passwords are not case-sensitive until the ALTER USER command is used to change the password. When the database is created, the passwords will be case-sensitive by default.
Enable Built-in Password Complexity Checker verify_function_11g is a sample PL/SQL function that can be easily modified to enforce the password complexity policies at your site. This function does not require special characters to be embedded in the password. Both verify_function_11g and the older verify_function are included in the utlpwdmg.sql file. To enable the password complexity checking, create a verification function owned by SYS. Use one of the supplied functions or modify one of them to meet your requirements. The example shows how to use the utlpwdmg.sql script. If there is an error in the password complexity check function named in the profile or it does not exist, you cannot change passwords nor can you create users. The solution is to set the PASSWORD_VERIFY_FUNCTION to NULL in the profile, until the problem is solved. The verify_function_11g function checks that the password contains at least eight characters; contains at least one number and one alphabetic character; and differs from the previous password by at least three characters. The function also checks that the password is not a username or username appended with any number 1100; a username reversed; a server name or server name appended with 1100; or one of a set of well-known and common passwords such as welcome1, database1, oracle123, or oracle (appended with 1100), and so on.
Managing Default Audits Review the audit logs. By default, auditing is enabled in Oracle Database 11g for certain privileges that are very important to security. The audit trail is recorded in the database AUD$ table by default; the AUDIT_TRAIL parameter is set to DB. These audits should not have a large impact on database performance, for most sites. Oracle recommends the use of OS audit trail files.
Archive audit records. To retain audit records, export them using Oracle Data Pump Export, or use the SELECT statement to capture a set of audit records into a separate table. Remove archived audit records. Remove audit records from the SYS.AUD$ table after reviewing and archiving them. Audit records take up space in the SYSTEM tablespace. If the SYSTEM tablespace cannot grow, and there is no more space for audit records, errors will be generated for each audited statement. Because CREATE SESSION is one of the audited privileges, no new sessions may be created except by a user connected as SYSDBA. Archive the audit table with the export utility, using the QUERY option to specify the WHERE clause with a range of dates or SCNs. Then delete the records from the audit table by using the same WHERE clause. When AUDIT_TRAIL=OS, separate files are created for each audit record in the directory specified by AUDIT_FILE_DEST. All files as of a certain time can be copied, and then
removed. Note: The SYSTEM tablespace is created with the autoextend on option. So the SYSTEM tablespace grows as needed until there is no more space available on the disk.
Adjust Security Settings When you create a database using the DBCA tool, you are offered a choice of security settings: Keep the enhanced 11g default security settings (recommended). These settings include enabling auditing and new default password profile. Revert to pre-11g default security settings. To disable a particular category of enhanced settings for compatibility purposes, choose from the following: - Revert audit settings to pre-11g defaults - Revert password profile settings to pre-11g defaults These settings can also be changed after the database is created using the DBCA. Some applications may not work properly under the 11g default security settings. Secure permissions on software are always set. It is not impacted by a users choice for the Security Settings option.
Setting Security Parameters A set of new parameters have been added to Oracle Database 11g to enhance the default security of the database. These parameters are systemwide and static. Use Case-Sensitive Passwords to Improve Security A new parameter, SEC_CASE_SENSITIVE_LOGON, allows you to set the case-sensitivity of user passwords. Oracle recommends that you retain the default setting of TRUE. You can specify non-case-sensitive passwords for backward compatibility by setting this parameter to FALSE:
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE
Note: Disabling case-sensitivity increases vulnerability to brute force attacks. Protect Against Denial of Service (DoS) Attacks The two parameters listed in the slide specify the actions to be taken when the database receives bad packets from a client. The assumption is that the bad packets are from a possible malicious client. The SEC_PROTOCOL_ERROR_FURTHER_ACTION parameter specifies what action is to be taken with the client connection: continue, drop the connection, or delay accepting requests. The other parameter, SEC_PROTOCOL_ERROR_TRACE_ACTION, specifies a monitoring action: NONE, TRACE, LOG, or ALERT.
Setting Database Administrator Authentication The database administrator must always be authenticated. In Oracle Database 11g, there are new methods that make administrator authentication more secure and centralize the administration of these privileged users. Case-sensitive passwords have also been extended to remote connections for privileged users. You can override this default behavior with the following command:
orapwd file=orapworcl entries=5 ignorecase=Y
If your concern is that the password file might be vulnerable or that the maintenance of many password files is a burden, then strong authentication can be implemented: Grant SYSDBA, or SYSOPER enterprise role in Oracle Internet Directory (OID). Use Kerberos tickets Use certificates over SSL To use any of the strong authentication methods, the LDAP_DIRECTORY_SYSAUTH initialization parameter must be set to YES. Set this parameter to NO to disable the use of strong authentication methods. Authentication through OID or through Kerberos also can provide centralized administration or single sign-on. If the password file is configured, it is checked first. The user may also be authenticated by the local OS by being a member of the OSDBA or OSOPER groups.
For more information, see the Oracle Database Advanced Security Administrators Guide 11g Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 530 Administrators 14 - 530
Release 1.
Transparent Data Encryption Several new features enhance the capabilities of Transparent Data Encryption (TDE), and build on the same infrastructure. The changes in LogMiner to support TDE provide the infrastructure for change capture engines used for Logical Standby, Streams, and Asynchronous Change Data Capture. For LogMiner to support TDE, it must be able to access the encryption wallet. To access the wallet, the instance must be mounted and the wallet open. LogMiner does not support Hardware Security Module (HSM) or user-held keys. For Logical Standby, the logs may be mined either on the source or the target database, thus the wallet must be the same for both databases. Encrypted columns are handled the same way in both Streams and the Streams-based Change Data Capture. The redo records are mined at the source, where the wallet exists. The data is transmitted unencrypted to the target and encrypted using the wallet at the target. The data can be encrypted in transit by using Advanced Security Option to provide network encryption.
Tablespace Encryption Tablespace encryption is based on block-level encryption that encrypts on write and decrypts on read. The data is not encrypted in memory. The only encryption penalty is associated with I/O. The SQL access paths are unchanged and all data types are supported. To use tablespace encryption, the encryption wallet must be open. The CREATE TABLESPACE command has an ENCRYPTION clause that sets the encryption properties, and an ENCRYPT storage parameter that causes the encryption to be used. You specify USING 'encrypt_algorithm' to indicate the name of the algorithm to be used. Valid algorithms are 3DES168, AES128, AES192, and AES256. The default is AES128. You can view the properties in the V$ENCRYPTED_TABLESPACES view. The encrypted data is protected during operations such as JOIN and SORT. This means that the data is safe when it is moved to temporary tablespaces. Data in undo and redo logs is also protected. Encrypted tablespaces are transportable if the platforms have same endianess and the same wallet.
Restrictions Temporary and undo tablespaces cannot be encrypted. (Selected blocks are encrypted.) Bfiles and external tables are not encrypted.
Transportable tablespaces across different endian platforms are not supported. The key for an encrypted tablespaces cannot be changed at this time. A workaround is: create a tablespace with the desired properties and move all objects to the new tablespace.
Hardware Security Module A Hardware Security Module (HSM) is a physical device that provides secure storage for encryption keys. It also provides secure computational space (memory) to perform encryption and decryption operations. HSM is a more secure alternative to the Oracle wallet. Transparent Data Encryption (TDE) can use HSM to provide enhanced security for sensitive data. An HSM is used to store the master encryption key used for TDE. The key is secure from unauthorized access attempts because the HSM is a physical device and not an operating system file. All encryption and decryption operations that use the master encryption key are performed inside the HSM. This means that the master encryption key is never exposed in insecure memory. There are several vendors that provide Hardware Security Modules. The vendor must also supply the appropriate libraries.
Encryption for LOB Columns Oracle Database 11g introduces a completely reengineered large object (LOB) data type that dramatically improves performance, manageability, and ease of application development. This Secure Files implementation (of LOBs) offers advanced, next-generation functionality such as intelligent compression and transparent encryption. The encrypted data in Secure Files is stored in-place and is available for random reads and writes. You must create the LOB with the SECUREFILE parameter, with encryption enabled (ENCRYPT) or disabled (DECRYPTthe default) on the LOB column. The current TDE syntax is used for extending encryption to LOB data types. LOB implementation from earlier versions is still supported for backward compatibility and is now referred to as Basic Files. If you add a LOB column to a table, you can specify whether it should be created as SECUREFILES or BASICFILES. To ensure backward compatibility, the default LOB type is BASICFILES. Valid algorithms are 3DES168, AES128, AES192, and AES256. The default is AES192. Note: For further discussion on Secure Files, see the lesson titled Oracle SecureFiles.
Enterprise Manager Security Management Security management has been integrated into Enterprise Manager. The Policy Manager Java consolebased tool has been superseded. Oracle Label Security, Application Context, and Virtual Private Database previously administered through the Oracle Policy Manager tool are now managed through the Enterprise Manager. The Oracle Policy Manager tool is still available. The Enterprise Manager Security tool has been superseded by Enterprise Manager features. Enterprise User Security is also now managed though Enterprise Manager. The menu item for Enterprise Manager appears as soon as the ldap.ora file is configured. See the Enterprise User Administrators Guide for configuration details. The Enterprise Security Manager tool is still available. TDE can now be managed through Enterprise Manager, including wallet management. You can create, open, and close the wallet from Enterprise Manager pages.
Using RMAN Security Enhancements Backup shredding is a key management feature that allows the DBA to delete the encryption key of transparent encrypted backups, without physical access to the backup media. The encrypted backups are rendered inaccessible if the encryption key is destroyed. This does not apply to password-protected backups. Configure backup shredding with:
CONFIGURE ENCRYPTION EXTERNAL KEY STORAGE ON; Or SET ENCRYPTION EXTERNAL KEY STORAGE ON;
The default setting is OFF, and backup shredding is not enabled. To shred a backup, no new command is needed, simply use:
DELETE FORCE;
Managing Fine-Grained Access to External Network Services The network utility family of PL/SQL packages, such as UTL_TCP, UTL_INADDR, UTL_HTTP, UTL_SMTP, and UTL_MAIL, allow Oracle users to make network callouts from the database using raw TCP or using higher-level protocols built on raw TCP. A user either did or did not have the EXECUTE privilege on these packages and there was no control over which network hosts were accessed. The new package DBMS_NETWORK_ACL_ADMIN allows finegrained control using access control lists (ACL) implemented by XML DB. 1. Create an access control list (ACL). The ACL is a list of users and privileges held in an XML file. The XML document named in the acl parameter is relative to the /sys/acl/ folder in XML DB. In the example given in the slide, SCOTT is granted connect. The username is case-sensitive in the ACL and must match the username of the session. There are only resolve and connect privileges. The connect privilege implies resolve. Optional parameters can specify a start and end time stamp for these privileges. To add more users and privileges to this ACL, use the ADD_PRIVILEGE procedure.
Managing Fine-Grained Access to External Network Services (continued) 2. Assign an ACL to one or more network hosts. The ASSIGN_ACL procedure associates the ACL with a network host and, optionally, a port or range of ports. In the example, the host parameter allows wildcard characters for the host name to assign the ACL to all the hosts of a domain. The use of wildcard characters affects the order of precedence for the evaluation of the ACL. Fully qualified host names with ports are evaluated before hosts with ports. Fully qualified host names are evaluated before partial domain names, and subdomains are evaluated before the top-level domains. Multiple hosts can be assigned to the same ACL and multiple users can be added to the same ACL in any order after the ACL has been created.
Managing Enterprise Information Today, applications must deal with many kinds of data, broadly classified as structured, semistructured, and unstructured data. The features of large objects (LOBs) allow you to store all these kinds of data in the database as well as in operating system (OS) files that are accessed from the database. The simplicity and performance of file systems have made it attractive to store file data in file systems, while keeping object-relational data in a relational database.
Problems with Existing LOB Implementation In Oracle8i, LOB design decisions were made with the following assumptions: LOB instantiation was expected to be several megabytes in size. LOBs were considered mostly write once, read many times type of data. Updates would be rare; therefore, you could version entire chunks for all kinds of updateslarge or small. Few batch processes were expected to stream data. An online transaction processing (OLTP) kind of workload was not anticipated. The amount of undo retained is user-controlled with two parameters PCTVERSION and RETENTION. This is an additional management burden. The CHUNK size is a static parameter under the assumption that LOB sizes are typically uniform. There is an upper limit of 32 KB on CHUNK size. High concurrency writes in Oracle RAC was not anticipated. Since their initial implementation, business requirements have dramatically changed. LOBs are now being used in a manner similar to that of relational data, storing semi-structured and unstructured data of all possible sizes. The size of the data can vary from a few kilobytes for an HTML link to several terabytes for streaming video. Oracle file systems that store all the file system data in LOBs experience OLTP-like high concurrency access. As Oracle RAC is being more widely adopted, the scalability issues of Oracle RAC must be addressed. The existing
design of LOB space structures does not cater to these new requirements.
Oracle SecureFiles Oracle Database 11g completely reengineers the LOB data type as Oracle SecureFiles, dramatically improving the performance, manageability, and ease of application development. The new implementation also offers advanced, next-generation functionality such as intelligent compression and transparent encryption. With SecureFiles, chunks vary in size from Oracle data block size up to 64 MB. The Oracle database attempts to colocate data in physically adjacent locations on disk, thereby minimizing internal fragmentation. By using variable chunk sizes, SecureFiles avoids versioning of large, unnecessary blocks of LOB data. SecureFiles also offer a new client/server network layer allowing for high-speed data transfer between the client and server supporting significantly higher read and write performance. SecureFiles automatically determines the most efficient way for generating redo and undo, eliminating user-defined parameters. SecureFiles automatically determines whether to generate redo and undo for only the change, or create a new version by generating a full redo record. SecureFiles is designed to be intelligent and self-adaptable as it maintains different in-memory statistics that help in efficient memory and space allocation. This provides for easier manageability due to lower number of tunable parameters that are harder to tune with unpredictable loads. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 545 Administrators 15 - 545
Enabling SecureFiles Storage The DB_SECUREFILE initialization parameter allows database administrators (DBAs) to determine the usage of SecureFiles, where valid values are: ALWAYS: Attempts to create all LOBs as SecureFile LOBs but creates any LOBs not in Automatic Segment Space Management (ASSM) tablespaces as BasicFile LOBs FORCE: Forces all LOBs created going forward to be SecureFile LOBs PERMITTED: Allows SecureFiles to be created (default) NEVER: Disallows SecureFiles from being created going forward IGNORE: Disallows SecureFiles and ignores any errors that would otherwise be caused by forcing BasicFiles with SecureFiles options If NEVER is specified, any LOBs that are specified as SecureFiles are created as BasicFiles. All SecureFiles-specific storage options and features (for example, compression, encryption, and deduplication) cause an exception if used against BasicFiles. BasicFiles defaults are used for any storage options not specified. If ALWAYS is specified, all LOBs created in the system are created as SecureFiles. The LOB must be created in an ASSM tablespace, otherwise an error occurs. Any BasicFiles storage options specified are ignored. The SecureFiles defaults for all storage can be changed using the ALTER SYSTEM command as shown in the slide. You can also use Enterprise Manager to set the parameter from the Server tab > Initialization Parameters link. Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 546 Administrators 15 - 546
SecureFiles: Advanced Features Oracle SecureFiles implementation also offers advanced, next-generation functionality such as intelligent compression and transparent encryption. Compression enables you to explicitly compress SecureFiles. SecureFiles transparently uncompresses only the required set of data blocks for random read or write access, automatically maintaining the mapping between uncompressed and compressed offsets. If the compression level is changed from MEDIUM to HIGH, the mapping is automatically updated to reflect the new compression algorithm. Deduplication automatically detects duplicate SecureFile LOB data and conserves space by storing only one copyimplementing disk storage, I/O, and redo logging savings. Deduplication can be specified at the table level or partition level and does not span across partitioned LOBs. Deduplication requires the Advanced Compression Option. Encrypted LOB data is now stored in place and is available for random reads and writes offering enhanced data security. SecureFile LOBs can be encrypted only on a per-column basis (same as Transparent Data Encryption). All partitions within a LOB column are encrypted using the same encryption algorithm. BasicFiles data cannot be encrypted. SecureFiles supports the industrystandard encryption algorithms: 3DES168, AES128, AES192 (default), and AES256. Encryption is part of the Advanced Security Option. Note: The COMPATIBLE initialization parameter must be set to 11.0.0.0.0 or later to use SecureFiles. The BasicFiles (previous LOB) format is still supported under 11.1.0.0.0 Oracle Database 11Oracle g: New Database Features for 11g: New Features for Administrators I - 547 Administrators 15 - 547
compatibility. There is no downgrade capability after 11.0.0.0.0 is set.
SecureFiles: Storage Options MAXSIZE is a new storage clause governing the physical storage attribute for SecureFiles. MAXSIZE specifies the maximum segment size related to the storage clause level. RETENTION signifies the following for SecureFiles: MAX is used to start reclaiming old versions after segment MAXSIZE is reached. MIN keeps old versions for the specified least amount of time. AUTO is the default setting, which is basically a trade-off between space and time. This is automatically determined. NONE reuses old versions as much as possible. Altering the RETENTION with the ALTER TABLE statement affects the space created only after the statement is executed. For SecureFiles, you no longer need to specify CHUNK, PCTVERSION, FREEPOOLS, FREELISTS, and FREELIST GROUPS. For compatibility with existing scripts, these clauses are parsed but not interpreted.
Creating SecureFiles You create SecureFiles with the storage keyword SECUREFILE in the CREATE TABLE statement with a LOB column. The LOB implementation available in prior database versions is still supported for backward compatibility and is now referred to as BasicFiles. If you add a LOB column to a table, you can specify whether it should be created as SecureFiles or BasicFiles. If you do not specify the storage type, the LOB is created as BasicFiles to ensure backward compatibility. In the first example in the slide, you create a table called FUNC_SPEC to store documents as SecureFiles. Here you are specifying that you do not want duplicates stored for the LOB, that the LOB should be cached when read, and that redo should not be generated when updates are performed to the LOB. In addition, you are specifying that the documents stored in the doc column should be encrypted using the AES128 encryption algorithm. KEEP_DUPLICATE is the opposite of DEDUPLICATE, and can be used in an ALTER statement. In the third example in the slide, you are creating a table called DESIGN_SPEC that stores documents as SecureFiles. For this table you have specified that duplicates may be stored, and that the LOBs should be stored in compressed format and should be cached but not logged. Default compression is MEDIUM, which is the default. The compression algorithm is implemented on the server-side, which allows for random reads and writes to LOB data. That
property can also be changed via ALTER statements.
Creating SecureFiles Using Enterprise Manager You can use Enterprise Manager to create SecureFiles from the Schema tab > Tables link. After you click the Create button, you can click the Advanced Attributes button against the column you are storing as a SecureFile, to enter any SecureFiles options. The LOB implementation available in prior versions is still supported for backward compatibility reasons and is now referred to as BasicFiles. If you add a LOB column to a table, you can specify whether it should be created as a SecureFile or a BasicFile. If you do not specify the storage type, the LOB is created as a BasicFile to ensure backward compatibility. You can select the following as values for the Cache option: CACHE: Oracle places LOB pages in the buffer cache for faster access. NOCACHE: As a parameter in the STORE AS clause, NOCACHE specifies that LOB values are not brought into the buffer cache. CACHE READS: LOB values are brought into the buffer cache only during read and not during write operations. NOCACHE is the default for both SecureFile and BasicFile LOBs.
Shared I/O Pool The Shared I/O Pool memory component is added in Oracle Database 11g to support large I/Os from shared memory, as opposed to Program Global Area (PGA), for direct path access. This is only when SecureFiles are created as NOCACHE (the default). The Shared I/O Pool defaults to zero in size and, only if there is SecureFiles NOCACHE workload, the system increases its size to 4% of cache. Because this is a shared resource, it may get used by large concurrent SecureFiles workloads. Unlike other pools, such as the large pool or shared pool, the user process will not generate a ORA-04031 error but will fall back to the PGA temporarily until more shared I/O pool buffers get freed. The LOB Cache is a new component in the SecureFiles architecture, improving LOB access performance by gathering and batching data as well as overlapping network and disk I/O. The LOB Cache borrows memory from the buffer cacheeither regular buffers or memory from the Shared I/O Pool. Because memory borrowed from buffer cache buffers is naturally suitable for doing database I/Os as well as suitable for injecting back into the buffer cache after I/Os have been done, unnecessary copying of memory can be avoided.
In multi-instance Oracle Real Application Clusters, the LOB Cache holds one single lock for each of the LOB accessed.
Altering SecureFiles Using the DEDUPLICATE option, you can specify that LOB data that is identical in two or more rows in a LOB column should share the same data blocks. The opposite of this is KEEP_DUPLICATES. Oracle uses a secure hash index to detect duplication and combines LOBs with identical content into a single copy, reducing storage and simplifying storage management. The LOB keyword is optional and is for syntactic clarity only. The COMPRESS or NOCOMPRESS keywords enable or disable LOB compression, respectively. All LOBs in the LOB segment are altered with the new compression setting. The ENCRYPT or DECRYPT keyword turns on or off LOB encryption using Transparent Data Encryption (TDE). All LOBs in the LOB segment are altered with the new setting. A LOB segment can be altered only to enable or disable LOB encryption. That is, ALTER cannot be used to update the encryption algorithm or the encryption key. The encryption algorithm or encryption key can be updated using the ALTER TABLE REKEY syntax. Encryption is done at the block level allowing for better performance (smallest encryption amount possible) when combined with other options. Note: For a full description of the options available for the ALTER TABLE statement, see the Oracle Database SQL Reference.
Accessing SecureFiles Metadata DBMS_LOB package: LOBs inherit the LOB column settings for deduplication, encryption, and compression, which can also be configured on a per-LOB level using the LOB locator API. However, the LONG API cannot be used to configure these LOB settings. You must use the following DBMS_LOB package additions for these features: DBMS_LOB.GETOPTIONS: Settings can be obtained using this function. An integer corresponding to a predefined constant based on the option type is returned. DBMS_LOB.SETOPTIONS: This procedure sets features and allows the features to be set on a per-LOB basis, overriding the default LOB settings. It incurs a round-trip to the server to make the changes persistent. DBMS_LOB.GET_DEDUPLICATE_REGIONS: This procedure outputs a collection of records identifying the deduplicated regions in a LOB. LOB-level deduplication contains only a single deduplicated region. DBMS_SPACE.SPACE_USAGE: The existing SPACE_USAGE procedure is overloaded to return information about LOB space usage. It returns the amount of disk space in blocks used by all the LOBs in the LOB segment. This procedure can be used only on tablespaces created with ASSM and does not treat LOB chunks belonging to BasicFiles as used space. Note: For further details, see the Oracle Database PL/SQL Packages and Types Reference.
Migrating to SecureFiles A superset of LOB interfaces allows easy migration from BasicFile LOBs. The two recommended methods for migration to SecureFiles are partition exchange and online redefinition. Partition Exchange Needs additional space equal to the largest of the partitions in the table Can maintain indexes during the exchange Can spread the workload out over several smaller maintenance windows Requires that the table or partition needs to be offline to perform the exchange Online Redefinition (recommended practice) No need to take the table or partition offline Can be done in parallel Requires additional storage equal to the entire table and all LOB segments to be available Requires that any global indexes be rebuilt These solutions generally mean using twice the disk space used by the data in the input LOB column. However, using partitioning and taking these actions on a partition-by-partition basis may help lower the disk space required.
SecureFiles Migration: Example The example in the slide can be used to migrate BasicFile LOBs to SecureFile LOBs. First, you create your table using BasicFiles. The example uses a partitioned table. Then, you insert data in your table. Following this, you create a transient table that has the same number of partitions but this time using SecureFiles. Note that this transient table has the same columns and types. The last section demonstrates the redefinition of your table using the previously created transient table with the DBMS_REDEFINITION procedure.

Oracle 11g New Features Student Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle 11g New Features Student Guide

Uploaded by

Copyright:

Available Formats

Overview This course is designed to introduce you to the new features of Oracle Database 11g that are applicable

Oracle Database 11g: New Features for Administrators I - 2

Oracle Database 11g: New Features for Administrators I - 3

Oracle Database 11g: New Features for Administrators I - 4

Oracle Database 11g: New Features for Administrators I - 5

Oracle Database 11g: New Features for Administrators I - 6

Oracle Database 11g: New Features for Administrators I - 7

Oracle Database 11g: New Features for Administrators I - 8

Oracle Database 11g: New Features for Administrators I - 9

Oracle Database 11g: New Features for Administrators I - 10

Oracle Database 11g: New Features for Administrators I - 11

Oracle Database 11g: New Features for Administrators I - 13 13

for database installation. It was previously available as a separate companion CD component.

Oracle Database 11g: New Features for Administrators I - # 16

Oracle Database 11g: New Features for Administrators I - # 20

Oracle Database 11g: New Features for Administrators I - # 25

Oracle Database 11g: New Features for Administrators I - # 38

Oracle Database 11g: New Features for Administrators I - # 39

Oracle Database 11g: New Features for Administrators I - # 42

Click Browse to select a diagnostic destination. Click Next.

Oracle Database 11g: New Features for Administrators I - # 44

Oracle Database 11g: New Features for Administrators I - # 49

Oracle Database 11g: New Features for Administrators I - # 50

Oracle Database 11g: New Features for Administrators I - # 53

Oracle Database 11g: New Features for Administrators I - # 57

Oracle Database 11g: New Features for Administrators I - # 59

Oracle Database 11g: New Features for Administrators I - 72 72

Oracle Database 11g: New Features for Administrators I - # 88

Oracle Database 11g: New Features for Administrators I - # 90

Oracle Database 11g: New Features for Administrators I - # 94

Oracle Database 11g: New Features for Administrators I - # 96

Oracle Database 11g: New Features for Administrators I - # 99

Oracle Database 11g: New Features for Administrators I - 105 105

Oracle Database 11g: New Features for Administrators I - # 125

Oracle Database 11g: New Features for Administrators I - # 126

Oracle Database 11g: New Features for Administrators I - # 127

Oracle Database 11g: New Features for Administrators I - # 130

Oracle Database 11g: New Features for Administrators I - # 135

Oracle Database 11g: New Features for Administrators I - # 137

Oracle Database 11g: New Features for Administrators I - # 148

Oracle Database 11g: New Features for Administrators I - # 149

Oracle Database 11g: New Features for Administrators I - # 151

Oracle Database 11g: New Features for Administrators I - # 156

Oracle Database 11g: New Features for Administrators I - 160 160

Oracle Database 11g: New Features for Administrators I - 161 161

Oracle Database 11g: New Features for Administrators I - # 166

and memory capability.

Oracle Database 11g: New Features for Administrators I - # 168

Oracle Database 11g: New Features for Administrators I - # 169

Oracle Database 11g: New Features for Administrators I - # 172

Oracle Database 11g: New Features for Administrators I - # 175

the replay was after the replay has finished.

Oracle Database 11g: New Features for Administrators I - # 176

instances is not replayed.

Oracle Database 11g: New Features for Administrators I - # 179

Oracle Database 11g: New Features for Administrators I - # 182

When your workload is finished, click Stop Capture.

Oracle Database 11g: New Features for Administrators I - # 184

Oracle Database 11g: New Features for Administrators I - # 190

Oracle Database 11g: New Features for Administrators I - # 191

Oracle Database 11g: New Features for Administrators I - # 194

jun07 directory into the database.

Oracle Database 11g: New Features for Administrators I - # 201