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 CHAPTER

Features 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

Categories of Tables in the WR Workload Repository Structure

WRx$ tables

Files SQL

SGA
System Undo
MMON In Memory
Statistics
Concurrency Segments

WR Schema Snapshots at
Tuning RAC different times

DBA_HIST ...
views

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
 Workload Repository Schema Tables
related to historical data / snapshots
WRH$_ACTIVE_SESSION_HISTORY WRH$_PGASTAT_BL
WRH$_ACTIVE_SESSION_HISTORY_BL WRH$_PGA_TARGET_ADVICE
WRH$_BG_EVENT_SUMMARY WRH$_PGA_TARGET_ADVICE_BL
WRH$_BUFFER_POOL_STATISTICS WRH$_RECOVERY_FILE_DEST_STAT
WRH$_DATAFILE WRH$_RESOURCE_LIMIT
WRH$_DB_CACHE_ADVICE WRH$_RMAN_PERFORMANCE
WRH$_DB_CACHE_ADVICE_BL WRH$_ROLLSTAT
WRH$_DLM_MISC WRH$_ROWCACHE_SUMMARY
WRH$_ENQUEUE_STAT WRH$_ROWCACHE_SUMMARY_BL
WRH$_ENQUEUE_STAT_BL WRH$_SEG_STAT
WRH$_EVCMETRIC_HISTORY WRH$_SEG_STAT_BL
WRH$_EVENT_NAME WRH$_SEG_STAT_OBJ
WRH$_FILEMETRIC_HISTORY WRH$_SESSMETRIC_HISTORY
WRH$_FILESTATXS WRH$_SGA
WRH$_FILESTATXS_BL WRH$_SGASTAT
WRH$_INSTANCE_RECOVERY WRH$_SGASTAT_BL
WRH$_JAVA_POOL_ADVICE WRH$_SHARED_POOL_ADVICE
WRH$_LATCH WRH$_SQLBIND
WRH$_LATCH_BL WRH$_SQLBIND_BL
WRH$_LATCH_CHILDREN WRH$_SQLSTAT
WRH$_LATCH_CHILDREN_BL WRH$_SQLSTAT_BL
WRH$_LATCH_MISSES_SUMMARY WRH$_SQLTEXT
WRH$_LATCH_MISSES_SUMMARY_BL WRH$_SQL_PLAN
WRH$_LATCH_NAME WRH$_SQL_SUMMARY
WRH$_LATCH_PARENT WRH$_SQL_WORKAREA_HISTOGRAM
WRH$_LATCH_PARENT_BL WRH$_STAT_NAME
WRH$_LIBRARYCACHE WRH$_SYSMETRIC_HISTORY
WRH$_LOG WRH$_SYSMETRIC_SUMMARY
WRH$_METRIC_NAME WRH$_SYSSTAT
WRH$_MTTR_TARGET_ADVICE WRH$_SYSSTAT_BL
WRH$_UNDOSTAT WRH$_SYSTEM_EVENT
WRH$_WAITSTAT WRH$_SYSTEM_EVENT_BL
WRH$_WAITSTAT_BL WRH$_SYS_TIME_MODEL
WRH$_OPTIMIZER_ENV WRH$_SYS_TIME_MODEL_BL
WRH$_OSSTAT WRH$_TABLESPACE_SPACE_USAGE
WRH$_OSSTAT_BL WRH$_TABLESPACE_STAT
WRH$_OSSTAT_NAME WRH$_TABLESPACE_STAT_BL
WRH$_PARAMETER WRH$_TEMPFILE
WRH$_PARAMETER_BL WRH$_TEMPSTATXS
WRH$_PARAMETER_NAME WRH$_THREAD
WRH$_PGASTAT

Figure 9.2 Workload Repository Tables

14
 Dictionary Views to Query
the Histotrical Workload Repository Data
DBA_HIST_DATABASE_INSTANCE
DBA_HIST_SNAPSHOT
DBA_HIST_SNAP_ERROR
DBA_HIST_BASELINE
DBA_HIST_WR_CONTROL
DBA_HIST_DATAFILE
DBA_HIST_FILESTATXS
DBA_HIST_TEMPFILE
DBA_HIST_TEMPSTATXS
DBA_HIST_SQLSTAT
DBA_HIST_SQLTEXT
DBA_HIST_SQL_SUMMARY
DBA_HIST_SQL_PLAN
DBA_HIST_SQLBIND
DBA_HIST_OPTIMIZER_ENV
DBA_HIST_EVENT_NAME
DBA_HIST_SYSTEM_EVENT
DBA_HIST_BG_EVENT_SUMMARY
DBA_HIST_WAITSTAT
DBA_HIST_ENQUEUE_STAT
DBA_HIST_LATCH_NAME
DBA_HIST_LATCH
DBA_HIST_LATCH_CHILDREN
DBA_HIST_LATCH_PARENT
DBA_HIST_LATCH_MISSES_SUMMARY
DBA_HIST_LIBRARYCACHE
DBA_HIST_DB_CACHE_ADVICE
DBA_HIST_BUFFER_POOL_STAT
DBA_HIST_ROWCACHE_SUMMARY
DBA_HIST_SGA
DBA_HIST_SGASTAT
DBA_HIST_PGASTAT
DBA_HIST_RESOURCE_LIMIT
DBA_HIST_SHARED_POOL_ADVICE
DBA_HIST_SQL_WORKAREA_HSTGRM
DBA_HIST_PGA_TARGET_ADVICE
DBA_HIST_INSTANCE_RECOVERY
DBA_HIST_JAVA_POOL_ADVICE
DBA_HIST_THREAD
DBA_HIST_STAT_NAME
DBA_HIST_SYSSTAT
DBA_HIST_SYS_TIME_MODEL
DBA_HIST_OSSTAT_NAME
DBA_HIST_OSSTAT
DBA_HIST_PARAMETER_NAME
DBA_HIST_PARAMETER
DBA_HIST_UNDOSTAT
DBA_HIST_ROLLSTAT
DBA_HIST_SEG_STAT
DBA_HIST_SEG_STAT_OBJ
DBA_HIST_METRIC_NAME
DBA_HIST_SYSMETRIC_HISTORY
DBA_HIST_SYSMETRIC_SUMMARY
DBA_HIST_SESSMETRIC_HISTORY
DBA_HIST_FILEMETRIC_HISTORY
DBA_HIST_EVCMETRIC_HISTORY
DBA_HIST_DLM_MISC
DBA_HIST_RCVRY_FILE_DEST_STAT
DBA_HIST_RMAN_PERFORMANCE
DBA_HIST_ACTIVE_SESS_HISTORY
DBA_HIST_TABLESPACE_STAT
DBA_HIST_LOG
DBA_HIST_MTTR_TARGET_ADVICE
DBA_HIST_TBSPC_SPACE_USAGE

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
 Self Tuning Self Tuning
ADDM
Component Component

Internal Clients

Foreground
processes
In Memory
Workload MMON Statistics
Process
Repository
Background
SGA
processes

DBA views V$ views

AWR
OEM SQLPlus and its relation with other
components
External Clients

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.

Shared
Dispatchers Servers Database

User
Requests

LISTENER
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 REPLACED BY PARAMETER

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 local_listener
mts_multiple_listeners

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 DESCRIPTION

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

35