Oracle Database 10g New Features Oracle 10g Reference for Advanced Tuning & Administration

By Mike Ault, Daniel Liu, and Madhu Tumma

Copyright © 2003 by Rampant TechPress. Table of Contents

Using the Online Code Depot Conventions Used in this Book Acknowledgments Preface

Chapter 1 Database Management New Features SYSAUX Tablespace What is Automated Storage Management?

Automated Storage Management Configuration ASM Concepts ASM Files Failure Groups ASM Instances Database Instance ASM Background Processes Installation of ASM ASM Benefits Viewing Information About Automated Storage Management

Automated Memory Management Oracle Database 10g Automation Features

Automatic Workload Repository Automatic Maintenance Tasks Oracle Database 10g Automatic Memory Management (AMM) How AMM Works Adjusting the Oracle Database 10g data buffers Viewing Information About the SGA Adjusting the Oracle Database 10g Shared Pool Conclusions about AMM

Automated RAC Services Configuration Creating a Real Application Clusters Database with the DBCA

Simplified Upgrade for RAC and OPS Databases Drop Database Conclusion

Chapter 2 Database Tuning and Performance Database Resource Manager

Components of DRM Resource Plans and Plan Directives Procedure to implement and manage

1

Automatic Mapping Database Tuning Improvements

User initiated Buffer Cache Flushing Automated Checkpoint Tuning Easier Transaction Recovery Monitoring Performance Overview Charts

Application Tuning Improvements Optimizer Mode Moving from RBO to the Cost-Based Optimizer Dynamic Sampling Sample Table Scans trcsess utility

Self-Tuning Features Automatic Shared Memory Management

Automatic SQL Tuning Process SQL Tuning Advisor

Wait Event Model improvements Overview of Wait Event Model

Conclusion Chapter 3 Tablespace Management

Temporary Tablespace Temporary Tablespace Group Overview Temporary Tablespace Group Benefits New Data Dictionary View Examples

Rename Tablespace Tablespace Rename Overview Tablespace Rename Benefits

Bigfile Tablespace Bigfile Tablespace Overview Bigfile Tablespace Benefits Maximum Database Size Extended ROWID Format Data Dictionary Views Enhancement Examples

New Cross-Platform Transportable Tablespaces Benefits Supported Platforms and New Data Dictionary Views Determine Platform Endianness Convert Datafiles using RMAN

Conclusion Chapter 4 Table and Index Features

Table and Index Partitions Overview Index-Organized Tables LOB Column Support for IOT Partitions Locally Partitioned Bitmap Indexes on an IOT Partition Managing Index Partitions Skipping Unusable Indexes Enhanced Partition Management in OEM

2

Hash-Partitioned Global Indexes Sorted Hash-Clustered Tables

Overview of Hash Clusters Creating Sorted Hash-Clustered Tables

Conclusion Chapter 5 DML Features

Single-Set Aggregates in DML Returning Clause Single-set Aggregates in the INSERT Statement Single-set Aggregates in the UPDATE Statement Single-set Aggregates in the DELETE Statement Virtual Spreadsheets and Upsert Through SQL Interrow Calculations

Conclusion Chapter 6 SELECT Features

Grouped Table Outer Join Increased Number of Aggregates per Query Remote Stored Functions in SELECT Statements

hs_call_name Case-Insensitive and Accent-Insensitive Query and Sort Enhanced CONNECT BY Support

Hierarchical Query Pseudo-columns Oracle Expression Filter

The Expression Attribute Set Expression Datatype and Expressions The EVALUATE Operator Example use of the EVALUATE Operator Using CREATE INDEX for Expressions

SQL Regular Expressions Changes to INSTR Changes to LIKE Changes to REPLACE Changes to SUBSTR Multilingual Regular Expression Syntax Notes on the POSIX operators and Oracle enhancements: Regular Expression Operator Multilingual Enhancements

Row Timestamp Conclusion

Chapter 7 Improved Existing Features Existing Features That Have Changed Asynchronous Row Change Data Capture

Overview of Change Data Capture Change Data Capture Asynchronous Change Data Capture

Cross-Platform Transportable Tablespaces Transporting Tablespaces Between Databases: A General Procedure The RMAN CONVERT Clause Restrictions and Usage Notes

Enhanced Table Functions Returning Large Amounts of Data from a Function Representing Dynamically Typed Data Using SYS.AnyData, SYS.AnyType, and SYS.AnyDataSet Types

3

External Tables Unload Unloading Data Using External Tables and the oracle_datapump Access Driver The oracle_datapump Access Driver LOGFILE | NOLOGFILE Using LOGFILE clause for oracle_datapump Unloading Data With the oracle_datapump Access Driver PARALLEL UNLOAD Supported Datatypes Unsupported Datatypes Reserved Words For the oracle_datapump Access Driver

Enhanced MERGE Functionality Prerequisites MERGE Syntax

Conclusion Chapter 8 Initialization Parameters

Basic Parameters Old Parameters New Parameters

create_stored_outlines db_flashback_retention_target db_recovery_file_dest db_recovery_file_dest_size db_unique_name ddl_wait_for_locks ldap_directory_access log_archive_config instance_type osm_diskgroups osm_diskstring osm_power_limit plsql_code_type plsql_debug plsql_optimize_level plsql_warnings resumable_timeout sga_target skip_unusable_indexes smtp_out_server sqltune_category streams_pool_size

Conclusion Chapter 9 Manageability Features

Easy Management Self-Managing Database Overview Automatic Workload Repository (AWR)

General Benefits Physical Structures Collection Process Using and Managing AWR

4

Active Session History Database Feature Usage Metrics

Advisory Framework - ADDM Server Alert Mechanism

Pro-Active Space Management Shared Server Configuration Transaction Manageability

New Columns Changes to v$session_longops MAXTRANS and Maximum Concurrency

Statistics Collection Dictionary Objects Guidelines Changes to dbms_stats package DML Table Monitoring Changes

Audit Enhancements Uniform Audit Trails Fine-Grained Auditing (FGA)

Response File Conclusion

Chapter 10 Utilities Improvements Data Pump Utilities

Data Pump Overview Data Pump Export Data Pump Import

New Scheduler Utilities Scheduler Components Create, Enable, Disable, and Drop a Program Create and Drop a Schedule Create A Job Class Data Dictionary Views

SQL*Plus Enhancements New DEFINE Variables SPOOL Command Enhancement

Conclusion Chapter 11 Network Features

Enhanced Oracle Networking Export Directory Naming Entries to Local Naming File (tnsnames.ora) Dynamic Connection Manager Configuration Easy Connect Naming Method

Syntax Element Description Configuring Easy Connect Naming to Use an Alias

Improved Network Outage Detection Configuration of the Advanced Profile Information

Improved Connection Manager Access Rules Automated Shared Server Configuration Simplified Shared Server Configuration

Shared Server Initialization Parameters Certificate Validation with Certificate Revocation Lists (CRLs)

Certificate Revocation Lists

5

Centralized CRL Management Centralized User Management for Kerberos Users What Exactly is a Trusted Database? Access to Single Sign On Wallet Java Applications

Single Station Administration for Password Authentication Overview of Password-Authenticated Enterprise User Database Login Information Security Protecting Database Password Verifiers With Directory ACLS

Transport Layer Security (TLS) Support SSL and TLS in an Oracle Environment

Conclusion Chapter 12 Backup and Recovery Features

Flashback and RMAN Extended Flashback Functions

Flashback Database Flashback Standby Database Flashback Re-instantiation Flashback Drop Flashback Table Flashback Row History Flashback Transaction History

RMAN Enhancements Automated Channel Failover for Backup and Restore Automated File Creation During Recovery Simplified Backups to Disk Proxy Copy Backup of Archivelogs Incrementally Updated Backups Simplified Recovery Through Resetlogs Full Database Begin Backup Command Changes to the ALTER DATABASE END BACKUP command Change-Aware Incremental Backups Automated Disk-Based Backup and Recovery RMAN Database Dropping and Deregistration Automated TSPITR Instantiation Simplified Recovery Manager Cataloging of Backup Files RMAN and the new EM (Enterprise Manager)

Conclusion Chapter 13 High Availability and Scalability

Avoiding Disruption Online Redefinition

New Additions and Changes Synonyms and Views LOGMINER

Automatic Determination of Redo Log Files Data Guard Environment

Overview of New Features Supplemental Logging Real Application Clusters

Service Registration CRS – Cluster Ready Services Rolling Upgrades

6

Conclusion Chapter 14 Oracle Streams

Enhancement Areas Streams Overview Configuration and Management

Streams Administrator SYSAUX tablespace usage Streams Pool in the SGA Buffered Queues in the SGA Purge Streams Queues New and Modified Views

Downstream Capture Overview Advantages of Downstream Capture Downstream Capture Method Monitoring Downstream Capture Processes

Asynchronous Change Data Capture Rule Interface Improvements

Negative Rule Sets Rule Based Transformation Subset Rules

Replication Enhancements Instantiating with RMAN Instantiating with Transportable Tablespace

Migration from Advanced Replication Messaging Enhancements

Streams Messaging Client Simplified Configuration Advance Queue Enhancements

Conclusion Chapter 15 Security Enhancements

Virtual Private Database Virtual Private Database Overview Column-Level Privacy Apply a Column-Level VPD Policy New Types of VPD Policies

Audit Enhancements Conclusion

Chapter 16 Business Intelligence New Features and Enhancements Materialized View Enhancements

Partition Tracking Change MJV Enhancement Nested MV enhancement

Query Rewriting Generalized Multiple Table Instance Support

Summary Management Improvements Materialized View Column Aliases Partition Maintenance Operations (PMOP)

7

Enhanced Explain Plan for Materialized Views Materialized View Log Describe and Validate Dimensions

SQLAccess Advisor Overview Overall Benefits Using the SQLAccess Advisor

OLAP Enhancements Hierarchy Handling Improvements XML Support for Analytic Workspace (AW) Useful Views

Support for Bioinformatics Bioinformatics Overview

Data Mining for Analytical Multi-User Access Control Enhanced Adaptive Bayes Network (ABN) Non-Negative Matrix Factorization Text Mining

Conclusion Chapter 17 Globalization Improvements

New Features Globalization Development Kit Enhancements

Overview of the Globalization Development Kit and Its Components Overview of Designing a Global Internet Application Getting Started with Oracle Globalization Services Oracle Services in OGS Internet Services in OGS

Enhanced Character Set Scanner and Converter Character Set Scanner Reports Universal Character Sets

Conclusion Chapter 18 Oracle Enterprise Manager

Installation Of OEM Starting and Navigating in OEM The EM2GO Interface Conclusion Index

8

Manageability Features

CHAPTER

9 Easy Management

This chapter focuses on the new features aimed at database management. Self-management, or easy management, has been the key word for Oracle 10g. The main areas of enhancements are:

Self-Managing Database – To aid self-management and auto tuning of the database, Oracle introduces a new persistent store called automatic workload repository (AWR), which collects memory statistics, and the automatic database diagnostic monitor (ADDM), which monitors and analyzes statistics and provides advisory services.

Simplified Configuration of Shared Servers – The configuration of shared servers and their associated dispatchers has been largely made dynamic.

Transaction Manageability – Now, we can monitor normal transaction rollback or transactions recovered by SMON. In addition, we can view historical information about transaction recovery and transaction rollback. Also, Oracle 10g pre-configures objects for maximum concurrency.

Simplified Statistics Collection – Beginning with the 10g version, both the real and fixed dictionary tables need to be analyzed in order to get better performance. There are several new procedures that have been introduced to streamline and simplify the compute statistics operation of dictionary objects.

Extended Support for FGA (Fine Grain Audit) - There is now additional fine grain audit support for ‘insert’, ‘delete’, and ‘update’ statements.

Response File Creation during database install – With Oracle Database 10g you now have true silent capability. When running OUI in silent mode on a character mode console, you no longer need to specify an X-server or set the DISPLAY environment variable on UNIX. No GUI classes are instantiated.

Self-Managing Database Generally speaking, database administration primarily entails regular health checks, handling the performance issues, organizing periodic monitoring

9

activities, and locating the bottlenecks. Checking the space thresholds, creating indexes, allocating necessary resources, collecting statistics etc. are the other important activities. The Oracle 10g database release takes over many of these tedious database tasks and tuning processes. The collection, storage, and analysis of status information about the database and the host has become relatively easy. Many new features have been added to aid self-management and self-tuning. This section focuses on database manageability features newly introduced and enhanced.

Overview The Oracle 10g database introduces a new framework for managing many tuning tasks automatically, for producing real-time information about the database’s health, and for extending advisories to improve performance. The new manageability infrastructure mainly focuses on four areas. They are as follows: Automatic Workload Repository - The ability to automatically collect

and store database information at regular intervals is crucial. This information should be persistent and accurate. Oracle introduces a new internal data store called Automatic Workload Repository (AWR) to collect and store data. AWR is central to the whole framework of self and automatic management. It works with internal Oracle database components to process, maintain, and access performance statistics for problem detection and self-tuning. Automatic Database Diagnostic Monitor - The second key

component is the advisory framework that provides expert recommendations to improve performance. The Automatic Database Diagnostic Monitor (ADDM) is a server-based performance expert in a box. It can perform real time root cause analysis of performance issues. It relies on the current statistics within the SGA and on the contents of the AWR. In addition, there are various advisory tools to help make tuning decisions. Next, are the Automatic Routine Administration tasks. By using the

newly introduced Scheduler, you can delegate to the Oracle database some of the repetitive tasks that need to be performed to keep the database up-to-date.

10

Server Generated Alerts - Oracle Database 10g is capable of automatically detecting many database alarm situations.

We have covered the topic of the Scheduler in Chapter 10, Utilities Improvements. We will examine the other features next.

Automatic Workload Repository (AWR) AWR is the main infrastructure that collects in-memory statistics at regular intervals and makes them available to the internal and external services or clients. External clients, such as Oracle Enterprise Manager and SQL*plus sessions, can view the AWR information through the data dictionary views. Internal clients, such as the ADDM and other self-tuning components or advisories, make use of the contents in the AWR.

General Benefits Advantages of the new workload repository include: AWR is a record of all database in-memory statistics historically stored.

In the past, historical data could be obtained manually using the ‘statspack’ utility. AWR automatically collects more precise and granular information than past methods. With a larger data sample, more informed decisions could be made. The

self-tuning mechanism uses this information for trend analysis. The statistics survive database reboots and crashes. Another benefit is that AWR statistics are accessible to external users,

who can build their own performance monitoring tools, routines, and scripts.

Oracle recommends that statspack users switch to the Workload Repository in Oracle Database 10g.

Physical Structures AWR is stored in tables owned by ‘SYS’ but physically located on the SYSAUX tablespace. The Workload Repository contains two types of tables: Metadata Tables: These are used to control, process, and describe the

Workload Repository tables. For example, Oracle uses the metadata tables to determine when to perform snapshots, and what to capture to disk.

11

Historical Statistics Tables: These tables store historical statistical information about the database in the form of snapshots. Each snapshot is a capture of the in–memory database statistics data at a certain point in time. All names of the AWR tables are prefixed with WRx$ with x specifying the kind of table: WRM$ tables store metadata information for the Workload

Repository. WRH$ tables store historical data or snapshots. WRI$ tables store data related to advisory functions.

The WRx$ tables are organized into the following categories: File Statistics, General System Statistics, Concurrency Statistics, Instance Tuning Statistics, SQL Statistics, Segment Statistics, Undo Statistics, Time– Model Statistics, Recovery Statistics, and RAC Statistics. Fig 9.1 shows a graphical view of the AWR table types. Following is the list of WRM$ tables that control all repository operations. WRM$_BASELINE WRM$_DATABASE_INSTANCE WRM$_SNAPSHOT WRM$_SNAP_ERROR WRM$_WR_CONTROL

MMON

WR Schema Snapshots atdifferent times

In MemoryStatistics

SGA

Files

System

Concurrency

Tuning

SQL

Undo

Segments

RAC

Categories of Tables in the WR

DBA_HIST ...views

Workload Repository StructureWRx$ tables

Figure 9.1 Automatic Workload Repository (AWR) Structures

Dictionary views are also provided, making the historical data available to users for query. Any view related to the historical information in the AWR has the dba_hist_ prefix. Figures 9.2 and 9.3 show the full list of the WR tables and the dba_hist* tables respectively.

12

Collection Process The collection process involves the capture of in-memory statistics from the SGA and their transfer to the physical tables located in the workload repository. The new background process, MMON, does this. The frequency of the capture snapshot is 30 minutes by default, however it can be adjusted suitably. You can control the interval and retention of snapshot generation by the dbms_workload_repository.modify_snapshot_settings procedure. For example: EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (43200, 15);

In this example, the retention period is specified as 30 days (43200 min) and the interval between each snapshot is 10 min.

Taking manual snapshots is also supported in conjunction with the automatic snapshots that the system generates. For this, the dbms_workload_repository.create_snapshot procedure is used.

The snapshots are used for computing the rate of change of a statistic. This is mainly used for performance analysis. A snapshot sequence numer (snap_id) identifies each snapshot, which is unique within the Workload Repository. Figure 9.4 shows the relation of AWR to other components.

13

WRH$_ACTIVE_SESSION_HISTORYWRH$_ACTIVE_SESSION_HISTORY_BLWRH$_BG_EVENT_SUMMARYWRH$_BUFFER_POOL_STATISTICSWRH$_DATAFILEWRH$_DB_CACHE_ADVICEWRH$_DB_CACHE_ADVICE_BLWRH$_DLM_MISCWRH$_ENQUEUE_STATWRH$_ENQUEUE_STAT_BLWRH$_EVCMETRIC_HISTORYWRH$_EVENT_NAMEWRH$_FILEMETRIC_HISTORYWRH$_FILESTATXSWRH$_FILESTATXS_BLWRH$_INSTANCE_RECOVERYWRH$_JAVA_POOL_ADVICEWRH$_LATCHWRH$_LATCH_BLWRH$_LATCH_CHILDRENWRH$_LATCH_CHILDREN_BLWRH$_LATCH_MISSES_SUMMARYWRH$_LATCH_MISSES_SUMMARY_BLWRH$_LATCH_NAMEWRH$_LATCH_PARENTWRH$_LATCH_PARENT_BLWRH$_LIBRARYCACHEWRH$_LOGWRH$_METRIC_NAMEWRH$_MTTR_TARGET_ADVICEWRH$_UNDOSTATWRH$_WAITSTATWRH$_WAITSTAT_BLWRH$_OPTIMIZER_ENVWRH$_OSSTATWRH$_OSSTAT_BLWRH$_OSSTAT_NAMEWRH$_PARAMETERWRH$_PARAMETER_BLWRH$_PARAMETER_NAMEWRH$_PGASTAT

WRH$_PGASTAT_BLWRH$_PGA_TARGET_ADVICEWRH$_PGA_TARGET_ADVICE_BLWRH$_RECOVERY_FILE_DEST_STATWRH$_RESOURCE_LIMITWRH$_RMAN_PERFORMANCEWRH$_ROLLSTATWRH$_ROWCACHE_SUMMARYWRH$_ROWCACHE_SUMMARY_BLWRH$_SEG_STATWRH$_SEG_STAT_BLWRH$_SEG_STAT_OBJWRH$_SESSMETRIC_HISTORYWRH$_SGAWRH$_SGASTATWRH$_SGASTAT_BLWRH$_SHARED_POOL_ADVICEWRH$_SQLBINDWRH$_SQLBIND_BLWRH$_SQLSTATWRH$_SQLSTAT_BLWRH$_SQLTEXTWRH$_SQL_PLANWRH$_SQL_SUMMARYWRH$_SQL_WORKAREA_HISTOGRAMWRH$_STAT_NAMEWRH$_SYSMETRIC_HISTORYWRH$_SYSMETRIC_SUMMARYWRH$_SYSSTATWRH$_SYSSTAT_BLWRH$_SYSTEM_EVENTWRH$_SYSTEM_EVENT_BLWRH$_SYS_TIME_MODELWRH$_SYS_TIME_MODEL_BLWRH$_TABLESPACE_SPACE_USAGEWRH$_TABLESPACE_STATWRH$_TABLESPACE_STAT_BLWRH$_TEMPFILEWRH$_TEMPSTATXSWRH$_THREAD

Workload Repository Schema Tablesrelated to historical data / snapshots

Figure 9.2 Workload Repository Tables

14

DBA_HIST_DATABASE_INSTANCEDBA_HIST_SNAPSHOTDBA_HIST_SNAP_ERRORDBA_HIST_BASELINEDBA_HIST_WR_CONTROLDBA_HIST_DATAFILEDBA_HIST_FILESTATXSDBA_HIST_TEMPFILEDBA_HIST_TEMPSTATXSDBA_HIST_SQLSTATDBA_HIST_SQLTEXTDBA_HIST_SQL_SUMMARYDBA_HIST_SQL_PLANDBA_HIST_SQLBINDDBA_HIST_OPTIMIZER_ENVDBA_HIST_EVENT_NAMEDBA_HIST_SYSTEM_EVENTDBA_HIST_BG_EVENT_SUMMARYDBA_HIST_WAITSTATDBA_HIST_ENQUEUE_STATDBA_HIST_LATCH_NAMEDBA_HIST_LATCHDBA_HIST_LATCH_CHILDRENDBA_HIST_LATCH_PARENTDBA_HIST_LATCH_MISSES_SUMMARYDBA_HIST_LIBRARYCACHEDBA_HIST_DB_CACHE_ADVICEDBA_HIST_BUFFER_POOL_STATDBA_HIST_ROWCACHE_SUMMARYDBA_HIST_SGADBA_HIST_SGASTATDBA_HIST_PGASTAT

DBA_HIST_RESOURCE_LIMITDBA_HIST_SHARED_POOL_ADVICEDBA_HIST_SQL_WORKAREA_HSTGRMDBA_HIST_PGA_TARGET_ADVICEDBA_HIST_INSTANCE_RECOVERYDBA_HIST_JAVA_POOL_ADVICEDBA_HIST_THREADDBA_HIST_STAT_NAMEDBA_HIST_SYSSTATDBA_HIST_SYS_TIME_MODELDBA_HIST_OSSTAT_NAMEDBA_HIST_OSSTATDBA_HIST_PARAMETER_NAMEDBA_HIST_PARAMETERDBA_HIST_UNDOSTATDBA_HIST_ROLLSTATDBA_HIST_SEG_STATDBA_HIST_SEG_STAT_OBJDBA_HIST_METRIC_NAMEDBA_HIST_SYSMETRIC_HISTORYDBA_HIST_SYSMETRIC_SUMMARYDBA_HIST_SESSMETRIC_HISTORYDBA_HIST_FILEMETRIC_HISTORYDBA_HIST_EVCMETRIC_HISTORYDBA_HIST_DLM_MISCDBA_HIST_RCVRY_FILE_DEST_STATDBA_HIST_RMAN_PERFORMANCEDBA_HIST_ACTIVE_SESS_HISTORYDBA_HIST_TABLESPACE_STATDBA_HIST_LOGDBA_HIST_MTTR_TARGET_ADVICEDBA_HIST_TBSPC_SPACE_USAGE

Dictionary Views to Querythe Histotrical Workload Repository Data

Figure 9.3 Dictionary Views exposing the historical workload repository

The statistics_level initialization parameter controls the type of statistics collected and stored. The parameter can take any one of these values. basic: The computation of AWR statistics and metrics is turned off. typical: Only a part of the statistics are collected. They are normally

enough to monitor the Oracle database behavior. all: All possible statistics are captured.

15

In MemoryStatistics

OEM

ADDM

SGA

WorkloadRepository

MMONProcess

Foregroundprocesses

Backgroundprocesses

Self TuningComponent

Self TuningComponent

SQLPlus

Internal Clients

External Clients

V$ viewsDBA views

A W Rand its relation with other

components

Figure 9.4 AWR and relation with components

Types of Data Collected

The collected statistics include: New time model statistics that show the amount of time spent on

database activities. Object Statistics that determine both access and usage of the segments. Some selected statistics collected in v$sysstat and v$sesstat. Some of the optimizer statistics that include statistics for self-learning

and tuning. The ADDM Active Session History (ASH), which represents the history

of the recent session’s activity. These statistics can be broadly categorized into 5 groups based on their nature. Base Statistics – This group represents raw data, which are generally

values from the start of the database, e.g. total physical reads. SQL Statistics – Important measurements regarding the SQL statement.

For example: Disk Read per SQL statement. Metrics – These are the secondary statistics, and the most interesting

ones from a tuning point of view. Metrics track the rates of change of activities in the database. For example, the average physical reads in the system in the last 30 min. is a metric.

16

Contents of Active Session History - For example, db file sequential read wait for SID of 16, file# 12, block# 1245, obj# 67, and time: 20000us. Advisor Results – Results of the expert analysis by the advisor

framework.

Note on Metrics

As we noted above, the Metrics are the statistics derived from base statistics. They represent the delta values between the snapshot periods. Metrics are used by internal components (clients) for system health monitoring, problem detection and self-tuning. Metrics are a key component in tracking threshold violations and thus for generating alerts. Since Metrics are pre-computed internally, they are readily available for use. Metrics are very useful in understanding the load and the nature of activity between two specified time periods. A unique number, which is referred to as a metric number, identifies metrics. Each metric is also associated with a metric name. You can query the view v$metricname to find the names of all the metrics. For example: SQL> select METRIC_NAME, METRIC_UNIT from v$metricname;

Internally, MMON periodically updates metric data from the corresponding base statistics.

There are about 183 metrics for which you can define thresholds. Examples of metrics: Physical Reads Per Sec User Commits Per Sec SQL Service Response Time DB Block Changes Per Txn Redo Generated Per Sec Physical Writes Per Sec Tablespace Space Usage

17

Network Traffic Volume Per Sec Logical Reads Per Sec CR Blocks Created Per Sec

Using and Managing AWR You can query base statistics and metrics from the various fixed views provided. You can optionally create your own snapshots and baselines using the dbms_workload_repository package. dbms_workload_repository package procedures are as follows: modify_snapshot_settings: Procedure to modify the snapshot settings. drop_baseline: Procedure to drop a single baseline. create_baseline: Procedure to create a single baseline. drop_snapshot_range: Procedure to drop a range of snapshots. create_snapshot: Procedure to create a manual snapshot immediately.

You can use the Oracle-provided SQL scripts to generate reports to view the contents of AWR. swrfrpt.sql: This script generates a report showing information on the

overall behavior of the system over a time period. The script generates a text file. swrfrpth.sql: This script gives the same information as swrfrpt.sql, however,

the generated output file uses HTML format.

Active Session History The Active Session History (ASH) represents the history of a recent session’s activity. ASH facilitates the analysis of the system performance at the current time. ASH is composed of regular samples of information extracted from v$session. ASH is designed as a rolling buffer in memory, and earlier information is overwritten when needed. ASH uses the memory of the SGA.

It is also possible to access ASH through SQL*plus by querying v$active_session_history. This view contains one row for each active session per sample.

18

Database Feature Usage Metrics AWR is also used to track database usage metrics. The usage metrics represent how you use the database features. The database usage metrics are divided into two categories: The database feature usage statistics. The High Water Mark (HWM) values of certain database attributes.

Database Feature Usage Statistics include Advanced Replication, Oracle Streams, AQ, Virtual Private Database, Audit options etc. High Water Mark Statistics include the size of the largest segment, the maximum number of sessions, the maximum number of tables, the maximum size of the database, the maximum number of data files, etc. To view usage metric information, you can query the following: dba_feature_usage_statistics - Lists the usage statistics of various database

features. dba_high_water_mark_statistics - Lists the database high water mark

statistics.

Advisory Framework - ADDM So far we have examined the details of the workload repository. Now let us focus on the advisory framework Oracle 10g introduces. Advisors are the server components that provide you with useful feedback about resource utilization and performance. The most important of all advisors is the Automatic Database Diagnostic Monitor (ADDM). ADDM does analysis of the system, identifies problems and their potential causes, and comes up with recommendations for fixing the problems. It can call all other advisors also. The main features of the ADDM are as follows: ADDM runs automatically in the background process MMON whenever

a snapshot of in-memory statistics is taken. ADDM does analysis of the statistics collected between two snapshots. ADDM analysis results are written back to the workload repository for

further use.

19

ADDM uses the new wait and time statistics model, where activities with high time consumption are analyzed on a priority basis. This is where the big impact lies. ADDM can also be invoked manually.

The results of the proactive analysis performed by the ADDM module are posted to the workload repository and then they are available to users through the OEM console or by other SQL query means. ADDM analysis is also the driving point for Server Alerts whenever the threshold is exceeded for the specified metrics. The new OEM or Grid Control has many web pages devoted to displaying ADDM findings. Other advisors include: SQL Tuning Advisor: This advisor is responsible for providing tuning

advice for a SQL statement. We have covered this topic in detail in Chapter 2, Database Tuning and Performance Improvements. SQL Access Advisor: This provides expert advice on materialized views,

indexes, and materialized view logs. A full detailed account of its utility and usage is covered in Chapter 16, Business Intelligence. Segment Advisor: This advisor is responsible for space issues involving

a database object. It analyzes the growth trends. It can also extend advice on the shrink possibility for the segments. Undo Advisor: This advisor suggests parameter values, and how much

additional space would be needed to support flashback for a specified time. However, most of the undo tuning (like undo retention) is automatic in Oracle Database 10g. Redo Logfile Size Advisor: This determines the optimal smallest online

redo log file size, based on the current fast_start_mttr_target setting and MTTR statistics.

Server Alert Mechanism As we have noted, the Oracle 10g database collects and stores various statistics into the workload repository. Those statistics are then analyzed to produce various metrics. Server-generated alerts pretty much depend on the derived ‘metrics’ available in the workload repository. MMON wakes up every minute to compute the metric values. In addition, for all the metrics that have thresholds defined,

20

MMON verifies the thresholds and generates the alerts, if required. Then the alert is queued into the predefined persistent queue alert_que owned by SYS. Based on the values obtained in the alert_que, OEM manages the notification mechanism. Administrators are notified using e-mail, or pager. Server-Generated Alerts are always displayed on the OEM console. Previously available OEM alerts and the newly introduced 10g Server Alerts mainly differ in the way they are generated. Server Alerts depend on the metric's computation and threshold validations, which are performed by the Oracle Database and access the SGA directly, whereas the OEM alerts depend on statistics collected by intelligent agents.

Pro-Active Space Management In Oracle 10g, the tablespace disk space utilization is proactively managed by the database. The Server Alert Mechanism monitors Tablespace disk space utilization. Information gathered into the AWR is also used to do the growth trend analysis and capacity planning of the database. The background process (MMON) verifies tablespace thresholds. The threshold is reached if the allocated space in the tablespace has reached a certain percentage of the total size of the tablespace (if the threshold is configured as a percentage), or when the total allocated space has reached a certain value that is set by you. An alert is triggered when the threshold has been reached. Another important and useful feature introduced in 10g is the facility to shrink the segment. In the previous releases of the Oracle database, moving or redefining the segment was the only way to free space once allocated below the segment’s HWM. In Oracle 10g, you can now shrink segments. When a segment is shrunk, its data is compacted, its HWM is pushed down, and unused space is released back to the tablespace containing the segment. This is possible for the segments in Automatic Segment Space Managed (ASSM) tablespaces only. For example, to shrink the table sales_items, use the statement: ALTER TABLE sales_items SHRINK SPACE CASCADE;

21

Shared Server Configuration In shared server architecture, the listener assigns each new client session to one of the dispatchers. As the user makes requests, the dispatcher sends the request to the shared server. It is also possible that a different set of shared servers are utilized for a given user session. The dispatchers act as the coordinating agents between the user sessions and the shared servers. A dispatcher is capable of supporting multiple client connections concurrently. Each client connection is bound to a virtual circuit. A virtual circuit is a piece of shared memory used by the dispatcher for the client connection requests and replies. An idle shared server process picks up the virtual circuit from the common queue, services the request, and relinquishes the virtual circuit before attempting to retrieve another virtual circuit from the common queue. In this way, a small number of server processes are able to service a large number of clients or users. This method also supports an increased number of users with less system resources. Note that not all applications are certified to use shared servers, but that server-side load balancing in a RAC may benefit from using shared servers. As seen in Figure 9.5, the listener communicates with the dispatchers on behalf of the user or client sessions. Once the user sessions establish connectivity with dispatchers, the shared servers service them.

UserRequests

LISTENER

DispatchersSharedServers Database

Shared Server Configuration

Figure 9.5 Shared Server Architecture

Prior to the release of Oracle Database 10g, you needed to set up at least one dispatcher for the shared server configuration to be enabled. You normally

22

needed to set the dispatchers initialization parameter to configure the information about dispatchers. With Oracle Database 10g, even without specifying a dispatcher with the dispatchers parameter, you can enable shared server by setting shared_servers to a nonzero value. The default behavior is that Oracle creates one dispatcher for the TCP protocol automatically. This way, it is easier to configure a shared server environment. The equivalent dispatchers initialization parameter for this configuration would be: DISPATCHERS="(PROTOCOL=tcp)"

When you need to use shared servers while the system is running, you can simply set the dynamic shared_servers initialization parameter to a value greater than zero with an ALTER SYSTEM command. As with other parameters, you can change just the current instance with this command and, if you are using an SPFILE, you can change the parameter for future instances as well. For example, to activate three shared servers in the current instance and the SPFILE, enter this command: SQL> ALTER SYSTEM SET SHARED_SERVERS=3 SCOPE=BOTH;

There are several other parameters that can be set in the shared server environment, but they are not required. Once you set shared_servers, your system will be running in shared server mode.

When you need to configure another protocol other than TCP/IP, configure a protocol address with one of the following attributes: ADDRESS, DESCRIPTION, or PROTOCOL.

Parameters with the prefix MTS are now obsolete. This means if you try to start an instance using these parameters you will receive the following error: “ORA-25138: <parameter> initialization parameter has been made obsolete “ Even if you try to set mts_servers during the runtime of an instance:

23

SQL> ALTER SYSTEM SET MTS_SERVERS = 2; ALTER SYSTEM SET MTS_SERVERS = 2 * ERROR at line 1: ORA-25138: MTS_SERVERS initialization parameter has been made obsolete

All the replacement parameters listed in the table are dynamic, meaning that you can change the values while the instance is running. Table 9.1 shows the replaced parameters.

OBSOLETE PARAMETER

REPLACED BY PARAMETER

mts_servers shared_servers mts_max_servers max_shared_servers mts_dispatchers dispatchers mts_max-dispatchers max_dispatchers mts_circuits circuits mts_sessions shared_server_sessions mts_listener_address mts_multiple_listeners

local_listener

Table 9.1 Oracle 10g Replacement Parameters

In the case of the dispatchers parameter, the results of the change will depend on which attributes you modify. Since several of the attributes affect the network session layer when a dispatcher is started, they cannot be changed for dispatchers already started. These attributes are: protocol, address, description, presentation, connections, sessions, ticks, and multiplex. You can dynamically modify the other attributes (listener and service) and affect existing as well as new dispatchers of the same configuration. There is a new view, v$dispatcher_config, that shows more information about existing dispatchers. This view displays information about the dispatcher configurations, including attributes that were not specified and were given a default value. The column CONF_INDX in v$dispatcher_config can be joined to the conf_indx column in v$dispatcher to see all of the detailed information about a given dispatcher. This information helps you to make more informed decisions on what attributes to modify and helps determine if you need to add or remove dispatchers. For example, to get service and other details about dispatchers, use the following query: SQL> select name, dispatchers, substr(service,1,20) service, idle, busy

24

from v$dispatcher,v$dispatcher_config where v$dispatcher.conf_indx = v$dispatcher_config.conf_indx ; NAME DISPATCHERS SERVICE IDLE BUSY ---- ----------- ------------- ---------- -------- D000 1 LONDBXDB 1641097 8

Transaction Manageability The user can roll back Oracle database transactions with the ROLLBACK statement and also during instance recovery by the Oracle database. When the system crashes and instance recovery begins, the SMON process scans all the rollback/Undo segments and recovers the unfinished transactions. In the case of instance recovery, if the unfinished transactions are large enough, the SMON process spawns parallel transaction recovery servers to recover. Prior to Oracle Database 10g, you could monitor the parallel transaction recovery with two views: v$fast_start_servers and v$fast_start_transactions. However, you could not monitor normal transaction rollback or transactions recovered by SMON. With the changes introduced in Oracle Database 10g, it is possible to view and monitor the real-time normal transaction rollback and transaction recovery with the SMON process. Now, you can even view the historical information about the transaction recovery and also work out the average rollback duration. With the current state of the recovery, you can find out how much work has been done and how much work remains. Thus, it becomes possible to estimate transaction recovery time and set the fast_start_parallel_rollback parameter suitably to optimize the system performance.

New Columns The view v$fast_start_transactions records information about the progress of the transactions that Oracle is recovering and has recovered. There are certain new columns added to this view, which aids in understanding the identity of the transactions. They are shown in the following table

NAME DATA TYPE

DESCRIPTION

XID RAW(8) Transaction ID PXID RAW(8) Transaction ID of the Parent Transaction

25

RCVSERVERS NUMBER Servers working on this transaction The view v$fast_start_servers provides information about all the recovery servers performing, or that have performed, parallel transaction recovery. One additional column is added to this view: XID, which gives you the transaction ID of the transaction a particular server is working on. The following statement is used to track the transaction recovery after instance startup. The first output shows that the transaction is recovering and then the second statement output shows that the transaction has recovered. Total undo blocks recovered is shown also shown. SELECT state, undoblocksdone, undoblockstotal, cputime FROM V$FAST_START_TRANSACTIONS; STATE UNDOBLOCKSDONE UNDOBLOCKSTOTAL CPUTIME -------- -------------- --------------- ------- RECOVERING 324 1145 12… SQL> / STATE UNDOBLOCKSDONE UNDOBLOCKSTOTAL CPUTIME -------- -------------- --------------- ------- RECOVERED 1145 1145 28

Changes to v$session_longops More operations are being added to v$session_longops. This view displays the status of various operations that run for longer than 6 seconds (in absolute time). These operations currently include many backup and recovery functions, statistics gathering, and query execution, and more operations are added for every Oracle release. In the 10g release, this view keeps track of ROLLBACK and ROLLBACK TO operations also.

MAXTRANS and Maximum Concurrency In previous releases of the Oracle Database, the MAXTRANS values used to represent a physical attribute for objects such as table, index, or cluster. MAXTRANS represented the maximum number of concurrent update transactions for any given data block belonging to the segment. With Oracle Database 10g, these objects are preconfigured for maximum concurrency. Oracle now allows up to 255 concurrent update transactions for any data block depending on the available space inside the block.

26

For backward compatibility reasons, even if you specify the MAXTRANS parameter while creating a table, an error is not flagged, and internally the value is ignored.

In the next section, we will examine the changes regarding the statistics collection mechanism. Oracle Database 10g introduces a statistics collection method for the data dictionary tables, as well as predefined jobs, to gather statistics regularly.

Statistics Collection It is a well-known practice for database administrators to collect statistics for tables and indexes located in the user or application schemas. With the impending de-support for RBO and wide adaptability of the CBO method, it becomes, more than ever, crucial and significant to collect statistics for the objects. Oracle Database 10g introduces many new statistics-gathering features. These include the ability to collect data dictionary statistics, as well as many changes in the existing Oracle supplied packages.

Dictionary Objects Beginning with Oracle Database 10g, Oracle recommends you compute statistics for dictionary tables also. This is a new suggestion. It is recommended in part to enhance the performance of database queries. There are broadly two types of objects in the data dictionary tables. They are: Fixed (in-memory) and Real (normal) Dictionary Tables. You can use the following Oracle supplied packages:

27

DBMS_STATS.GATHER_SCHEMA_STATS DBMS_STATS.GATHER_DATABASE_STATS DBMS_STATS.GATHER_DICTIONARY_STATS Note that the last package procedure gather_dictionary_stats is newly introduced in Oracle Database 10g and is specially designed for collecting statistics for dictionary objects. You need the new system privilege, ANALYZE ANY DICTIONARY, for this purpose. This privilege is required to be able to analyze the dictionary objects and fixed objects, unless you are the SYS user, or a user with SYSDBA privilege.

Data Dictionary Table Statistics

To collect statistics on dictionary objects, execute the following statements. The collection process can be done in different formats. Format (1) SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS ('SYS'); Format (2) SQL> exec DBMS_STATS.GATHER_DATABASE_STATS (gather_sys=>TRUE); Format (3) SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

As seen in the above examples, the gather_schema_stats procedure accepts the sys argument to perform statistics collections. In case of the gather_database_stats procedure, there is a new argument gather_sys whose default value is FALSE. When needed, you can set it to TRUE and execute the procedure. There is another procedure, delete_dictionary_stats, which allows you to remove data dictionary stats. When you execute the gather_dictionary_stats procedure, it gathers statistics from the SYS and SYSTEM schemas, as well as any other schemas that are related, such as OUTLN or DBSNMP schemas.

Fixed Table Statistics

The data dictionary has many fixed tables, such as X$ tables. Oracle suggests that you also collect statistics for these objects, however, less frequently than the other normal objects. There is a new parameter gather_fixed available in the procedure gather_database_stats which when set to TRUE, collects the statistics for data

28

dictionary fixed tables. gather_fixed is set to FALSE by default, and causes statistics not to be gathered for fixed tables. It may not be necessary to collect statistics very often for data dictionary fixed tables. Another procedure, gather_fixed_objects_stats, is primarily aimed at collecting statistics of fixed objects. This procedure takes the following arguments: STATTAB: The user statistics table identifier describing where to save the

current statistics. Default value is NULL for dictionary collection. STATID: The optional identifier to associate with these statistics within

STATTAB. Default value is also NULL STATOWN: The schema containing STATAB. Default value is NULL. NO_INVALIDATE: Do not invalidate the dependent cursors if it is set to TRUE. Default value is FALSE.

It is also possible to delete statistics on all fixed tables by using the new procedure delete_fixed_objects_stats. You can also perform export or import statistics on fixed tables by using the export_fixed_objects_stats and import_fixed_objects_stats procedures respectively. The following example shows different formats: SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS ('SYS', -gather_fixed=>TRUE) ; PL/SQL procedure successfully completed.

You can also use the gather_fixed_objects_stats procedure to collect statistics. SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS (´ALL´);

In addition to what has been shown above, it is also possible to collect statistics for individual fixed tables. The procedures in the dbms_stats package that accept a table name as an argument are enhanced to accept a fixed table name as an argument. Since the fixed tables do not have I/O cost, as the rows reside in memory, CBO takes into account the CPU cost of reading rows.

Guidelines Oracle suggests the following best practices for collecting statistics. Collect statistics for normal data dictionary objects using the same

interval that you would analyze objects in your schemas. In addition, you

29

need to analyze the dictionary objects after a sufficient amount of DDL operations have occurred. Use the procedures gather_database_stats or gather_schema_stats with options

set to GATHER AUTO. With this feature, only the objects that need to be re-analyzed are processed every time. For fixed objects, the initial collection of statistics is usually sufficient. A

subsequent collection is not usually needed, unless workload characteristics have changed dramatically.

In the next section, we will examine the changes introduced for the dbms_stats package.

Changes to dbms_stats package With Oracle Database 10g, there are some new arguments available for the dbms_stats package subprograms. Those parameters are as follows: granularity degree

granularity

This parameter is used in subprograms such as gather_table_stats and gather_schema_stats. This parameter indicates the granularity of the statistics that you want to collect, particularly for partitioned tables. As an example, you can gather the global statistics on a partitioned table, or you can gather global and partition-level statistics. It has two options. They are: AUTO and GLOBAL AND PARTITION.

When the AUTO option is specified, the procedure determines the granularity based on the partitioning type. Oracle collects global, partition-level, and sub-partition level statistics if sub-partition method is LIST. For other partitioned tables, only the global and partition level statistics are generated. When the GLOBAL AND PARTITION option is specified, Oracle gathers the

global and partition level statistics. No sub-partition level statistics are gathered even it is composite partitioned object.

30

degree

With this parameter, you are able to specify the degree of parallelism. In general, the degree parameter allows you to parallelize the statistics gathering process. The degree parameter can take the value of auto_degree. When you specify the auto_degree, Oracle will determine the degree of parallelism automatically. It will be either 1 (serial execution) or default_degree (the system default value based on number of CPUs and initialization parameters), according to the size of the object. Take care if Hyper Threading is used, as you will have less computational power than Oracle assumes.

DML Table Monitoring Changes With Oracle Database 10g, the statistcis_level initialization parameter functions as a global option for the table monitoring mechanism. This mechanism overrides the table level MONITORING clause. In other words, the [NO]MONITORING clauses are now obsolete. The statistcis_level parameter was available in 9i. If the statistcis_level parameter is set to BASIC, the monitoring feature is disabled. When it is set to TYPICAL (which is the default setting) or ALL, then the global table monitoring is enabled. These changes are aimed at simplifying operations and also making them consistent with other related statistics. The modification monitoring mechanism is now enabled by default, and users of the GATHER AUTO or STALE feature of dbms_stats no longer have to enable monitoring explicitly for every table under the default settings.

You can still use the [NO]MONITORING clauses in the {CREATE | ALTER } TABLE statements as well as the alter_schema_tab_monitoring and alter_database_tab_monitoring procedures of the dbms_stats package, but these clauses and procedures are now considered as no operation. They execute without giving any error, but have no effect. There is also no table monitoring for temporary tables.

31

So far, we have covered changes and new features related to statistics collection. In the next section, we will focus on the new features regarding the fine grain audit method and other auditing changes.

Audit Enhancements Oracle databases have many types of auditing features. In mandatory auditing, certain actions are always audited, regardless of the other audit options or parameters. Database activities, such as system startup and shutdown, are always recorded. In the standard auditing method, auditing is set at the system level using the audit_trail initialization parameter. Once auditing is turned on, you have the option of selecting the objects and privileges you wish to audit. In the fine-grained auditing (FGA) method, the audit is based on the data content. FGA provides better control and is a more granular method of auditing. This method creates audit records based on the exact query, condition, and data retrieved or manipulated by the statement. This method also provides a facility to audit only those statements (including actual values of possible bind-variables) that reference a particular column. The FGA method was introduced in Oracle9i. Oracle Database 10g enhances the FGA capability. The Extended SQL Support in FGA now supports the granular auditing of queries, as well as UPDATE, INSERT, and DELETE operations. The next sections examine and discuss the new audit features introduced in the Oracle database 10g.

Uniform Audit Trails In Oracle Database 10g, it becomes possible to track the same fields for standard and fine-grained auditing. This allows you to easily examine and monitor security standards. Any unauthorized access can be effectively tracked. In order to assure uniformity between the standard and fine-grained auditing trail records, many new attributes have been added to complement the methods. Oracle Database 10g collects the following extra FGA information into the same audit trail table, such as: The system change number (SCN) records every change to the system.

32

The exact SQL text executed by the user. The bind variables used with the SQL text.

Again, in the case of fine-grained auditing, the following extra fields of information are collected: A serial number for each audit record. A statement number links together multiple audit entries that originate

from a single statement. For example, in a case where an UPDATE hits three different FGA policies, the fine-grained audit trail will show three entries (each with its own entry ID) and one statement number. A statement_type, telling which kind of statement was audited. For

example, SELECT for select statements. An object identifier that is a unique identifier for every object in the

database. The following queries show the new fields added: For Standard Auditing - SELECT username, owner, obj_name, sql_text FROM dba_audit_trail

For Fine-Grained Auditing - SELECT db_user, object_schema, object_name, sql_text FROM dba_fga_audit_trail ;

In addition to the above, other significant changes have been introduced with the Oracle Database 10g database release. The following fields have been modified. A global timestamp in Universal Coordinated Time (UTC) replaces

GMT. This field is useful for monitoring across servers in separate geographic locations and time zones. An instance number that is unique. The database uses this field to

combine audit records in Real Application Clusters (RAC) environments. A transaction identifier that is unique for each operation. This field

assists you in grouping audit records belonging to a single transaction.

Fine-Grained Auditing (FGA) In general, the FGA method of auditing monitors the data access based on the information retrieved or modified by the query or DML. With the help

33

of the FGA method, it becomes easier to focus on security-relevant columns and rows and ignore areas that are less important. Another advantage with the FGA method is that it produces far less audit records, while being more useful in keeping a safe security track. The FGA method was introduced in Oracle9i Enterprise Edition. However, this method provided only support for the ‘SELECT’ statements. With Oracle Database 10g, it becomes possible to extend the FGA method to cover UPDATE, INSERT, and DELETE statements as well. FGA helps in detecting the potential misuse of user privileges and possible security breaches, without having to make changes in the actual application code. With the help of FGA event handlers, policy violations may generate notifications to alert the administrators. We have covered more details on the topic of FGA in Chpter 15, Security Enhancements.

Response File When using the Oracle Universal Installer (OUI), a response file is generated. This file contains the responses you enter to the various prompts in the OUI. With Oracle Database 10g, you now have true silent capability. When running OUI in silent mode on a character mode console, you no longer need to specify an XServer or set the DISPLAY environment variable on UNIX. No GUI classes are instantiated, making the silent mode truly silent. The generated Response file can be used for future install needs. The response file format has been changed. The changes make it less likely that you will need to edit the file for deployment to other systems. These changes include: Only the variables used in dialogs needing user inputs in interview phases

are recorded. Minimized differences in response files generated between releases. New header format to make it easier for you to edit the file.

34

35

Conclusion In this chapter we have examined many new and enhanced features related to better manageability. The main features covered in this chapter include: Oracle introduces a new persistent store called automatic workload

repository (AWR), which collects in-memory statistics, and the automatic database diagnostic monitor (ADDM), which monitors, analyzes, and provides advisory services of statistics. Configuration of shared servers and its associated dispatchers has been

largely made dynamic. Many of the MTS parameters have been made obsolete. The transaction rollback monitoring method has been enhanced. In

addition, we can view historical information about transaction recovery and transaction rollback. Also with Oracle Database 10g, objects are pre-configured for maximum concurrency. In order to get better performance results, both the real and fixed

dictionary tables need to be analyzed. There are several new procedures that have been introduced to streamline and simplify the compute statistics operations. There are some changes in the dbms_stats package too. There is now additional fine-grained audit support for ‘insert’, ‘delete’,

and ‘update’ statements. Extra attributes or fields are added to bring in uniformity between standard and fine-grain auditing.

In the next chapter, we will cover the new features regarding the utilities. There are quite a good number of new features added. Those features include data pump utilities, SQL Loader improvements, SQL plus enhancements, and a new Scheduler utility.