Mcgraw Hill Osborne Ocp Oracle Database 10G New Features For Administrators Exam Guide

Color profile: Generic CMYK printer profile
Composite Default screen CertPrs8 / OCP Oracle Database 10g Exam Guide / Alapati / 225862-4 / Chapter 1
Blind Folio 1:1
1
Installation, Server
Configuration, and
Database Upgrades
CERTIFICATION OBJECTIVES
1.01 Installation New Features Support 1.06 Using New Utility to Perform
Pre-Upgrade Validation Checks
1.02 Performance Enhancements
to the Installation Processs 1.07 Using the Simplified Upgrade Process
1.03 Simplified Instance Configuration 1.08 Starting Up the Database Using
a New Mode When Upgrading
1.04 Viewing Database Feature Usage Statistics
1.05 Supported Upgrade Paths to Oracle
✓ Two-Minute Drill
Database 10g Q&A Self Test
P:\010Comp\CertPrs8\862-4\ch01.vp
Thursday, September 02, 2004 12:50:43 PM
2 Chapter 1: Installation, Server Configuration, and Database Upgrades
O racle Corporation has ambitiously positioned Oracle Database 10g as a

sophisticated self-managing database. Note that you don’t refer to the new
10g database as Oracle10g, as in Oracle9i. The correct name of our new
database is Oracle Database 10g. Throughout this text, I refer to the database as Oracle
Database 10g, although I may occasionally refer to it as simply Oracle 10g, for convenience.
The database server I use in this book is the Oracle Database 10g Enterprise
Edition Release 10.1.0.2.0. I use both a UNIX platform and a Windows platform
for most of the examples in this book. You can probably replicate several examples
in this book using a different version of the Oracle software, but you can get the
Enterprise Edition software free from Oracle, so there isn’t any reason for not using
that version. Practicing using the new features is essential not only for passing the
test, but also for learning the features well enough to implement them in your
databases. So, if you haven’t already downloaded the software, please do so now
(from www.oracle.com).
The g in Oracle 10g, stands for grid computing. Grid computing is all the rage now,
with IBM promoting “on-demand” computing, and Sun, HP, and other companies
talking about their own visions of grid computing. Regardless of what a particular
company might name it, grid computing really means treating computing as a utility,
somewhat like an electrical company’s power grid. When you want more or less
computing power, the grid will supply it to you automatically in a flexible manner.
The following three attributes lie at the heart of grid computing:
■ Virtualization between the layers of the computing stack and the users
■ Dynamic provisioning of work among the available resources, based on
changing needs
■ Pooling of resources to maximize availability and utilization
Several new manageability-enhancing features, along with revamped older features,

promise Oracle database administrators (DBAs) a very new way of managing their
powerful Oracle databases. The main goals of this new approach are to reduce
administrative effort and capital expenditures, while simultaneously keeping failure
costs to a minimum. The changes start, as they should, right with the installation of
the database software itself.
This first chapter discusses in detail features related to installation, configuration,
and upgrading.
Installation New Features Support 3
Please refer to the Oracle Database 10g documentation for complete details
on a given feature. This book is intended to provide the information you
need for upgrading your Oracle OCP certification from Oracle9i to Oracle
Database 10g. (The complete name of the test required for upgrading your
certification is Oracle Database 10g: New Features for Administrators (Exam
#1Z0-040) Therefore, unless the feature is completely new to Oracle 10g,
I don’t attempt to fully explain it in this book.
Let’s start our review of the new Oracle 10g installation features by looking at
some interesting changes in the installation process.
CERTIFICATION OBJECTIVE 1.01
Installation New Features Support

While the essential database software installation is through the familiar Oracle
Universal Installer, there are several appealing changes in the Oracle Database 10g
installation process itself. The entire installation process is simpler now, and the
typical server installation takes less than a half an hour to complete. Client installations
can now be done in less than a minute, and they require less than 70MB of disk space.
The following are some new features related to the Oracle Enterprise Server
software installation process:
■ Database management choices

■ Automatic pre-install checks
■ New file storage options
■ Backup and recovery options
■ Database user password specification
■ Cluster Ready Services
■ Enterprise Configuration Management Tool
■ OracleMetaLink integration
■ Oracle software cloning
■ Database cloning
Let’s look at each of these installation new features, starting with enhancements
in database management choices.
Database Management Choices

As part of the Oracle Database 10g software installation, Oracle offers you the choice
to create a “starter” database, as was the case in previous versions. However, now, you
have more management choices to make when you decide to let Oracle create the
starter database.
In Oracle9i, you could create the Oracle Enterprise Manager (OEM) central
management setup (including database management, as well as host and
network management) as part of the normal database installation. In Oracle 10g,
if you wish to configure a centralized (or grid-based) OEM capability, you must
configure this feature separately.
In Oracle9i, you needed to choose between an OEM console in the stand-alone
mode or log in to the Oracle Management Server. In the stand-alone mode, you
could manage only your databases. In order to manage HTTP servers, events, and
jobs, you needed to use the Oracle Management Server. You can now use the OEM
in two fundamentally different ways:
■ You can manage your databases locally using the OEM Database Control,
which is part of the Oracle 10g server software.
■ You can manage your databases centrally, through the OEM Grid Control,
which is available on separate CDs.
The OEM Database Control comes with the Oracle Database 10g
server software.
The OEM Database Control is a web-based application that you can use to manage
a single Oracle 10g database. The Database Control simply lets you monitor and
manage a single database. You can access the Database Control by using a web
browser; no configuration is necessary to start using the Database Control. Oracle
automatically installs the OEM Database Control in the same Oracle Home as your
Oracle database.
Alternatively, you can install the OEM Grid Control tool, which lets you
monitor and manage several databases and servers at once. In order to use the OEM
Grid Control, you need to configure and start the Oracle Management Agent on
each of the nodes you wish to monitor.
If you are managing a single database, the simple stand-alone OEM Database
Control is adequate. On the other hand, if you are in charge of several databases
on several hosts, you’ll need to install and use the OEM Grid Control. The
Grid Control includes the Oracle Management Agent, Oracle Management
Service, the Oracle Management Repository, and the Grid Control console.
It is through the console that you perform all monitoring, configuration, and
management tasks for not only databases, but also for the various hosts
and other services.
In Oracle9i databases, there was only one kind of OEM, and you had the
option of configuring it with or without Management Agents and the Management
Repository. Now, Oracle is making a formal distinction between a local and centrally
managed OEM.
The OEM Database Control runs with the help of a HTTP server, and you use a
regular Internet browser to see the OEM interface. The default URL for the OEM
Database Control is as follows:
http://host.domain:5500/em/
In order to manage your database, log in as the user SYS and connect as SYSDBA.
The default port number for the OEM is 5500. You can determine the correct
port number for your database by looking at the portlist.ini file, which you
can find in the $ORACLE_HOME/install directory.
In order to run the OEM Database Control, you must first start the database
from which the Database Control is running. Let’s say your database name
is nina. You then need to make sure that the service (on a Windows server)
OracleServiceDBConsoleNina is running, before you try to access the OEM Database
Control interface through your web browser.
When you choose local management using the Database Control, the installer
also gives you the choice of configuring default backup strategies administered by
the Recovery Manager (RMAN). In addition, choosing the Database Control also
enables you to configure the sending of automatic e-mail alerts to warn you about
space concerns and other problems.
The Apache HTTP Server isn’t a part of the Oracle Database 10g software,
unlike in the previous versions. Oracle continues to provide the Apache HTTP
Server, but as part of the supplemental product CD-ROM.
The Database Configuration Assistant (DBCA) can automatically configure the

OEM Database Control interface during database creation. However, if you create
a database manually, you must configure and install the OEM Database Control,
using the Oracle-supplied build script: $ORACLE_HOME/bin/emca for UNIX and
LINUX systems and $ORACLE_HOME\bin\emca.bat for Windows. This script
will configure the OEM repository and start up the Database Control console.
In order to access the OEM Database Control from your browser, you must first
have the dbconsole process running on your system. The dbconsole process
is automatically started during the installation process when you create a database
using the DBCA. When you create a database manually, the emca (UNIX) or the
emca.bat (Windows) script will start the dbconsole process. You can start, stop,
and check the status of the dbconsole process by using the following three
commands, respectively:
$ emctl start dbconsole
$ emctl stop dbconsole
$ emctl status dbconsole
Automatic Pre-Install Checks

In order to install Oracle 10g, you must meet several operating system hardware and
software requirements. In previous Oracle software versions, it wasn’t uncommon for
DBAs to start the installation process, only to stop it midway because they overlooked
one or two factors. The DBA was responsible for making sure that there were enough
system resources, that the correct set of initialization parameters were chosen, and
so on. To make the requirements phase go smoothly, the Oracle Universal Installer
(OUI) now manages the entire pre-install requirements check automatically. Oracle
writes the results of the prerequisite checking process to a results file.
Comprehensive hardware and software prerequisite checks ensure the detection
of resource and compatibility issues before your installation process gets underway.
Oracle even allows for the updating of the prerequisites directly via OracleMetaLink,
to reflect new operating system patches on your system. You may also add custom
prerequisite checks through XML files, in order to customize the installation process.
Pre-Installation Checks Performed

The following are some of the main pre-installation checks that the prerequisite checker
of the OUI automatically performs before you install the Oracle 10g server software:
■ Correct operating system version and compatibility level The first thing
that Oracle checks before you start the installation process is whether you
are running the current operating system version. For example, on a HP-UX
system, Oracle will verify that you have at least the HP 11.11 version.
Similarly, for Linux-based systems, Oracle will make sure you have one of
UnitedLinux 1.0, Red Hat 2.1, or Red Hat 3.0 versions before you can
proceed further with the installation. In addition, if you have a 32-bit
operating system, you cannot install the 64-bit version. Oracle will also
ensure that you have set the database compatibility level to 9.2.0 or higher.
■ Operating system patches Oracle automatically checks to make sure you
have installed all the necessary operating system patches.
■ Kernel parameters Oracle checks to make sure that operating system kernel
parameters like SHMMAX and SHMMIN are set appropriately.
■ Sufficient memory and file space Oracle checks the amount of swap space
and the minimum space in the temporary tablespace that are required during
the installation process. Oracle will also ensure that your redo logs are sized
sufficiently.
■ Oracle Home Your Oracle Home must be either empty or belong to a
supported release that permits the installation of Oracle 10g server software.
Methods for Performing Pre-Installation Checks

You can instruct the OUI to perform the prerequisite checks in three different ways:
■ As part of an actual installation process

■ As a stand-alone check without any installation
■ From the command line, in the silent mode (without using the OUI GUI)
Only after you pass all the preinstall validations will the OUI proceed with the
installation of the Oracle software.
New File Storage Options

The OUI now offers three choices for configuring the file systems for any new starter
database that you may create:
■ Automatic Storage Management (ASM) This option offers a way to easily

manage your datafiles using logical file management techniques. You can
think of ASM as an integration of a traditional file system with a built-in
Logical Volume Manager (LVM), which is separate from any LVM your
system may already have, like Veritas, for example. This means that you no
longer need to use a third-party LVM to stripe and mirror your hard drives.
Under ASM, all you need to do is create disk groups, and the database
automatically stripes and mirrors your data across the available disks in
the disk groups. You can also add or remove disks while the database is
up and running.
■ Raw Devices You need to think about using raw devices only if you are
considering using Oracle Real Application Clusters. If you use RAC, and a
Clustered File System (CFS) is available on your operating system, Oracle
recommends using either CFS or ASM for your file storage. If a CFS is
unavailable, Oracle recommends that you use raw, or “uncooked,” file
systems or ASM.
■ File Systems Choosing this option will mean that you are using the traditional
operating system files and directories for your database storage. Of course,
you should organize your directories and files according to the well-known
Optimal Flexible Architecture (OFA) guidelines.
Backup and Recovery Options

The next major management option involves the choice of backup and recovery options
for the starter database, during the Oracle server software installation process. You have a
choice of two options:
■ Do not enable automatic backups

■ Enable automatic backups
If you choose to enable automatic backups, you must also specify the location in
which you want the backups to reside. In addition, you need to provide the
credentials—name and password—for the user who will be performing the backups.
You can enable the automated backups after you’ve finished the server
software installation.
Database User Password Specification

The starter database will have several schemas for database management and post-
installation functions: SYS, SYSTEM, DBSNMP, and SYSMAN schemas. Oracle
will leave the passwords for these four usernames unlocked and unexpired. During
installation, you’ll be asked to furnish passwords for these four accounts, and you can
use the same password for all of them if you wish.
All other preloaded Oracle schemas will have passwords that are expired and
locked when you create any new database. It’s your job to unlock these standard user
accounts and set new passwords for them.
In Oracle9i, you had to change the SYS and SYSTEM passwords twice: once
during the installation of the software and once during database creation. In
Oracle 10g, you need to provide this information only once, during the installation
of the software.
Cluster Ready Services

The Oracle 10g installation supports several Real Application Clusters (RAC) features,
including the installation of the Cluster Ready Services (CRS) feature. CRS facilitate
the management of RAC and replace third-party cluster management software on
most operating system platforms. CRS provide a platform for services on RAC. For
example, when an RAC component database goes down, CRS will automatically
redirect the processing to an alternate available instance.
You can invoke the OUI from any node on a cluster that is part of an
installation. You can not only install new software, but also perform
upgrades and apply patches from any node in a cluster
Enterprise Configuration Management Tool

The Enterprise Configuration Management Tool is available through the OEM Grid
Control. As enterprises grow larger, so do the number and complexity of the hosts
and databases you need to manage the enterprise. You can use the new OEM Grid
Control tool to simplify the configuration and management of the enterprise. The
Grid Control offers a management console for your entire system, and it enables you
to monitor and configure complex enterprises by performing the following two tasks:
■ Collect necessary host and database configuration information.

■ Perform configuration changes.
Let’s briefly look at how you can perform these tasks in your enterprise.
Collecting Host and Database Configuration Information

The Oracle 10g OEM contains powerful new configuration management features to
help enforce best practice configuration parameter settings and track configuration
changes. These features apply to Oracle databases, as well as to the host servers and
the network. Continuous configuration monitoring helps you to adhere to best practice
configuration management and promotes availability, performance, and security.
The OEM Grid Control manages hosts and databases with the help of Management
Agents that run on various hosts. These Management Agents collect information
about the hosts, databases, listeners, web servers, and other services that run on the
host. By default, the Management Agents collects and sends information every 24
hours. The hosts send this information to the Oracle Management Repository. The
following is a list of some of the host and database configuration information that
the Management Agents send to OEM:
■ Memory, CPU, and I/O configuration on the host

■ Operating system details such as vendor, version, installed software components,
patches, and database patch information
■ Database and instance properties, including information about initialization
parameters
■ Tablespace and datafile information
■ Control file and redo log information
The OEM maintains a detailed configuration inventory of all the databases and
servers in its domain.
Monitoring and Managing Enterprise Configuration

Once the Grid Control collects the configuration information, you can use the same
tool to monitor and manage the configuration. Here’s a brief list of the various things
you can do to manage enterprise configuration with the OEM Grid Control:
■ View and compare the hardware and software configurations of individual

hosts and databases.
■ Track changes to host configurations.
■ See a summary view of your enterprise configuration.
■ Search the enterprise configuration to find configurations that meet a set
of search criteria that you specify.
■ Clone Oracle Homes and database instances.

■ View host and database policy violations.
■ Simplify the process of patching Oracle products and manage Oracle critical
patch advisories.
MetaLink Integration
Probably every Oracle DBA knows and relies on the OracleMetaLink service to some
extent during the performance of his or her duties. In Oracle 10g, you can directly link
the OEM to the OracleMetaLink service. Through this built-in MetaLink integration,
OEM can then automatically track any new software patches for you. You can arrange
to receive alerts whenever the OEM spots new patches. The OEM can even tell you
which systems need the new patches. Using the OEM OracleMetaLink link, you can
search for appropriate patches and download them, receive critical patch alerts, and
stage and apply patches on your system.
How does Oracle keep track of the exact software version that you are using, if
you are constantly downloading and uploading patches? Whenever you apply a
patch, Oracle immediately updates the OUI’s inventory, so it has the correct record
of your latest patch level. Exercise 1-1 shows how to use the OEM Database Control
to download Oracle software patches.
EXERCISE 1-1
Using OEM Database Control to

Download Oracle Software Patches
The OEM uses OracleMetaLink credentials to search for and download OracleMetaLink
patches. If you did not specify your OracleMetaLink credentials during installation, you
can follow the steps in this exercise.
1. On the OEM Database Control home page, click Setup.

2. On the Setup page, click Patching Setup.
3. Specify your OracleMetaLink username and password in the fields provided.
4. The URL to access the OracleMetaLink web site to search for and download
patches is displayed in the Patch Search URL field on this page, as shown here:
Patch Search URL : http://updates.oracle.com
You may access OracleMetaLink directly by going to the following web site:
http://oracle.com/support/metalink/index.html
5. From this page, Oracle licensees can register for an account or log in with
an existing account. Once logged in, you can search for patches, download
patches, and so on.
The OEM automatically alerts you to any new crtical patches that become
available. In addition, you can use the OEM Patch Wizard to find out what interim
patches are available for your system. You can now study patch details and README
notes directly from your OEM interface. Using the Patch Wizard, you can download
available patches from Metalink into the OEM patch cache, so you can propagate
these patches across your system at your convenience.
Oracle Software Cloning

The OEM Grid Control enables you to easily duplicate Oracle Database 10g software
installations (Oracle Homes) from a master installation to one more servers. Using an
OEM Wizard, you can specify the source and the destination host to which you want
to clone that Oracle Home. The cloning process will automatically adjust host names,
IP addresses, listener settings, and so on.
You can create multiple new installations in a single operation from the OEM
Grid Control framework. You can also create a library of master installations,
which you can use repeatedly in cloning operations.
Database Cloning
Using the OEM, you can now easily clone databases. OEM performs database cloning
by using RMAN. You use the OEM Clone Database wizard, also known as the Clone
Database Tool, to perform the various steps in a database cloning operation. To create
a duplicate of an existing database, from the home page of the OEM Database Control,
choose Maintenance | Deployments | Clone Database. OEM will back up the source
database’s datafiles as well as archive logs, and automatically restore and recover these
in the target location. The OEM also creates the necessary password files, initialization
files, and networking files.
When you use the OEM to clone a database, you can leave the database open.
You can clone databases that are release 8.1.7 and higher. The new database will
Performance Enhancements to the Installation Process 13
be up-to-date with the old one until the time the archived logs of the original
databases were backed up by the OEM.
Performance Enhancements
to the Installation Process
Oracle has implemented several changes to make the installation process more streamlined
and faster than in previous versions. You can literally install the entire Oracle 10g
software in less than half an hour, using just one CD. Moreover, during the installation
process, you can now automatically set up several features, such as database monitoring.
The important installation process enhancements are discussed in the following sections.
Single CD Installation
Although the Oracle Database 10g server software comes in a pack of CD-ROMs, you
need only a single 650MB CD to complete your Oracle 10g server installation. It takes
only about 20 minutes to complete the entire installation. The label on this main
database server software CD is Oracle Database 10g CD. Several older components are
now available on separate CDs. Along with the Oracle Database 10g CD, the following
CDs are supplied with the Oracle 10g package:
■ Companion CD
■ Oracle Database 10g Products CD
■ Oracle Database 10g Client CD
■ Oracle Documentation 10g CD
■ Oracle Database 10g Demos CD
■ Oracle Enterprise Manager CD
You install other tools, such as the HTTP Server, from the Oracle Database 10g
Companion CD. The Companion CD includes two products: the HTTP Server and
the new HTML DB feature.
The Database 10g Products CD includes the Oracle database examples, the Oracle
Workflow Server, and the Legato Single Server Version (LSSV).
The original installation includes only the new OEM Database Control, which
enables you to monitor just the database itself. The OEM Grid Control, which enables
the monitoring of your entire system, is available on the Oracle Enterprise Manager CD.
Minimal Hardware Requirements

You can use the Oracle Database 10g software with less stringent hardware requirements
than those in previous versions. The following are the basic hardware requirements for
Oracle Database 10g:
■ Memory You need 256MB for the basic database, and 512MB if you are
using the stand-alone version of the OEM (the OEM Database Control).
If you need to, you can run both the database and Database Control with
256MB or even less memory, say, for testing purposes. However, the more
memory you have, the easier it is to use the memory-hungry, Java-based
OEM tool.
■ Disk space You need a maximum of about 2.5GB of disk space for the
Oracle software. In addition, you need 1GB of swap space and about 400MB
of disk space in the /tmp directory. The OUI uses a more sophisticated
algorithm to estimate your disk space needs now, so there is less chance of
running out of disk space during the installation process.
Easier and Cleaner Deinstallation

Prior to Oracle Database 10g, you couldn’t always count on a clean Oracle server
deinstallation if you needed to remove the server software for some reason. Well,
this isn’t true anymore. With Oracle 10g, you can perform an easy and clean
deinstallation, marked by the following new features:
■ All files, including files that belong to configuration assistants and patch sets,
are automatically removed during the deinstallation process.
■ The installer automatically cleans up all the Windows Registry entries.
Performance Enhancements to the Installation Process 15
To deinstall your Oracle 10g software, follow these steps:
1. First, shut down all databases and ASM instances running under the Oracle
Home you want to remove, and then remove the databases (remove all
directories with database files).
2. Stop all the relevant processes running under this Oracle Home, by running
the following commands:
$ORACLE_HOME/bin/emctl stop dbconsole – shuts down the OEM.
$ORACLE_HOME/bin/lsnrctl stop – brings down the Oracle listener
$ORACLE_HOME/bin/isqlplusctl stop – brings down the iSQL*Plus server.
3. Start the OUI.

4. Click Deinstall Products in the Welcome window.
5. In the Inventory window, select the correct Oracle Home that contains the
software you want to deinstall, and then click Remove.
6. Manually remove the Home directory that you just deinstalled.
Don’t remove any Oracle Home directories without first using the OUI
to remove the Oracle software.
Automatic Launching of Software

In Oracle 10g, several Oracle products will launch automatically immediately after you
complete the server installation. Examples include the Oracle Management Agent,
the OEM Database Control, and the iSQL*Plus server. Oracle automatically sets up
an out-of-the-box monitoring and administration environment for you after the
installation is complete.
Response File Improvements

The response file is a file you can use to perform silent installations, which are installations
where the user doesn’t need to provide any interactive input. The response file contains
all the information that you normally provide during an interactive installation session.
If you have several off-site Oracle installations to perform, you could send an installation
response file to these locations, rather than going to each place to perform a manual
installation.
The following are the new Oracle 10g improvements in the response file, which
help you perform a truly “silent” Oracle installation:
■ The file has a new header format, which makes the response file easier to edit.
■ You don’t need to specify an X server when performing installations in a
character mode console.
■ You don’t need to set the DISPLAY variable on UNIX systems.
■ No GUI classes are instantiated, making this a truly silent method of
installing software.
Simplified Instance Configuration

In Oracle Database 10g, several enhancements make instance creation a lot simpler
than before. These enhancements include a more sophisticated DBCA, adoption of
a set of simplified database initialization parameters, and the ability to view database
feature usage statistics. The following are the main new features related to simplified
instance configuration:
■ DBCA enhancements
■ Policy-based database configuration framework
■ Simplified initialization parameters
■ Irreversible datafile compatibility
Let’s start with a discussion of the enhancements in the DBCA tool.
Database Configuration Assistant (DBCA) Enhancements

You can create new databases manually by using the standard create database
statement. You can also create databases with the help of Oracle’s DBCA. The DBCA
really makes the Oracle DBA’s database-creation tasks tremendously lighter when
creating complex Oracle 10g databases. Oracle 10g contains several enhancements
in routine database administration, and the DBCA helps you implement all these
new automatic management tasks. Using the DBCA ensures that you’re reminded
Simplified Instance Configuration 17
about all the important options, rather than needing to remember them and perform
them all manually.
EXERCISE 1-2
Creating a New Database Manually

You can create a new database with the simple statement create database
abcd, where abcd stands for your database instance name.
1. Create the instance before you try creating the database. On a Windows
system, first run the command oradim –new –sid my_sid. Make sure
you create a simple init.ora file with just one parameter: the instance name.
2. Log in as SYSDBA.
3. Use the command create database my_sid. Do not specify any
datafiles, tablespaces, or any other information.
4. Answer the following questions:
■ What tablespaces does Oracle create? Where are the datafiles?
■ What are key features of the initialization parameter file (init.ora or in
the SPFILE)?
■ How much SGA and other PGA memory is allocated?
■ What mode of undo management does your new database use?
■ What are the default passwords for the various system accounts?
■ What database features are currently configured?
Please make sure you create the instance before you try creating the
database. On a Windows system, first run the command oradim –new
–sid my_sid. Make sure you create a simple init.ora file with just one
parameter—the instance name. Next, log in as sysdba and use the command
‘create database my_sid. Now, you can answer the exercise questions.
There are several important DBCA enhancements in Oracle Database 10g,

including the creation of the mandatory SYSAUX tablespace, a flash recovery area,
and new database storage options. Let’s start with a discussion of the new mandatory
SYSAUX tablespace.
The SYSAUX Tablespace

You are aware that the OEM, the RMAN, and several other Oracle tools need
repositories—locations where these tools store all the database metadata. The
SYSTEM tablespace stores a lot of metadata, such as the data dictionary, but it does
not store the metadata relating to tools like the OEM. Traditionally, Oracle required
you to create separate tablespaces for the various repositories in your database. Now,
in Oracle 10g, Oracle introduces the SYSAUX tablespace, which is auxiliary to the
SYSTEM tablespace. This new tablespace is a central location for the metadata of all
tools like the OEM and RMAN. The SYSAUX tablespace consolidates the data that
various database features and products used to store in multiple tablespaces (or in the
SYSTEM tablespace). Thus, you need to create fewer tablespaces to store all the
repository data for the various utilities like the RMAN.
The DBCA automatically creates the SYSAUX tablespace for you, with a default
size of 500MB. Of course, you can customize the storage and file parameters for
SYSAUX, if you wish. Toward the end of this chapter, in the section detailing the
manual upgrading of a database to the Oracle 10g version, I’ll show you the syntax
for manually creating the SYSAUX tablespace.
Flash Recovery Area

The flash recovery area is a unified storage location on your server that Oracle reserves
exclusively for all database recovery-related files and activities. The main purpose
behind the creation of the flash recovery area is to automate the storage management
for many backup and recovery-related activities. The database will store all the files
that it needs during a database recovery in this flash recovery area.
Note that the flash recovery area is separate from the space you allocate to the
normal database files—datafile, redo log files, and the control files. You must allocate
separate physical space for the flash recovery area. When you use the DBCA to create
a new database, it automatically creates the flash recovery area for you.
The flash recovery area is mandatory if you wish to configure automatic

backups using the OEM.
How do you determine what size your database flash recovery area should be?
Oracle recommends that you allocate at least enough space to hold a copy of the
following files:
■ All datafiles
■ All redo log files
■ All control files

■ All archived redo logs necessary for recovery that haven’t been migrated
to tape
■ Any incremental backups, if they exist
If you want to manually define a flash recovery area, you can do so using the new
flash recovery initialization parameters, DBA_FLASH_RECOVERY_DEST and DB_
FLASH_RECOVERY_DEST_SIZE, as follows:
SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 500G;
SQL> ALTER SYSTEM SET db_recovery_file_dest ='/u22/oradata/
finance/recovery';
You can dynamically alter or disable both of the flash recovery initialization
parameters. You can find out details about the flash recovery area’s contents by using
the V$FLASH_RECOVERY_FILE_DEST view, as shown here:
SQL> SELECT name, space_limit, space_used,
space_reclaimable, number_of_files
FROM v$recovery_file_dest;
Automatic Storage Management (ASM)

ASM is an exciting new Oracle Database 10g feature. In essence, an ASM-based
storage system contains its own LVM for Oracle files. ASM makes it easier to manage
large databases. Chapter 10 is devoted to a detailed discussion of the ASM feature.
Management Options
As in the case of the starter database described earlier in this chapter, the DBCA gives
you a choice between two kinds of database management: local and central. If you
want to just manage a single database instance, simply choose the Database Control,
which Oracle automatically installs with your new database. If, on the other hand, you
need to manage several databases and several nodes, use the new Grid Control. The
Grid Control doesn’t come automatically with the database; you need to install this
tool from a separate CD.
As mentioned earlier in this chapter, Oracle automatically sets up an out-of-the-
box monitoring and administration environment for you after the installation is
complete. You don’t need to perform any configuration to start using the DB
Console (Database Control) to start managing a single database, including alert
notification, job scheduling, and software management.
You can access the OEM Database Control or the Grid Control from any client
browser. For example, to access the OEM Database Control, just open Internet
Explorer or Netscape and type in the following URL:
http://myhostname:default_port_number/em
where myhostname stands for the IP address or symbolic name of your machine, and
default_port_number is the port number that Oracle allocated to the Database Control
during installation. The default Database Control HTTP port number is 5500.
Once you get to the Database Control login page, log in as the SYS user (with
the SYSDBA password). This will take you to the home page of the OEM Database
Control utility.
Note that you’ll need Oracle licensing for the following three premium components
of OEM Database Control (technically speaking, you’ll be in violation of your
Oracle licensing requirements, if you use these options without paying for them!):
■ Database Diagnostics Pack
■ Database Tuning Pack
■ Configuration Management Pack
Here’s a brief listing of the components of each of these OEM premium packs:
Database
Database Diagnostics Pack Tuning Pack Configuration Management Pack
Performance Monitoring (database SQL Access Advisor Database and Host Configuration
and host)
Automated Database Diagnostic SQL Tuning Advisor Deployments
Monitor (ADDM)
Automatic Workload Repository SQL Tuning Sets Patch Database and Patch Staging
Event Notifications: Notification Object Reorganization Clone Database and Clone Oracle Home
Methods, Rules, and Schedules;
Notification Blackouts
Event history/metric history Search and Compare Configuration Policies
(database and host)
Policy-Based Database Configuration Framework

Oracle provides a set of established configuration recommendations, which are a set
of Oracle’s best practice recommendations, to ensure that your database performs at
an optimal level. Oracle 10g enables you to monitor all of your databases to see if there
are any violations of the predetermined configuration policies. Oracle collects these
configuration metrics for databases, host machines, and listener services.
The OEM Database Control provides an easy way to monitor the adherence of your
system to the predetermined policies. On the Database Control home page, there
is a section called Diagnostic Summary, which shows you if there are any policy
violations anywhere. If you drill down, using the All Policy Violations button, you
can get to the Policy Violations page, which summarizes all policy violations in
your databases and hosts. If you wish, you can disable a policy by going to the
Manage Policy Library page.
Here are a few examples of some typical policy rules:
■ The policy rule “critical patch advisories for Oracle Homes” checks for
missing Oracle patches.
■ The policy rule “insufficient number of control files” checks for the use of
a single control file.
■ The “listener password policy rule” checks for password-protected listeners.
Simplified Initialization Parameters

Instance configuration includes the all-important choice of initialization parameters.
Oracle 10g informally divides the available set of initialization parameters into a basic
and an advanced set of parameters, as follows:
■ Basic initialization parameters This set consists of about 25 to 30 of the
most common parameters that you need for an Oracle database. Oracle
defines the basic initialization parameters as those that are adequate to keep
your database running well. Examples include parameters like PROCESSES,
SESSIONS, UNDO_MANAGEMENT, DB_BLOCK_SIZE, CONTROL_FILES,
and DB_NAME.
■ Advanced initialization parameters These are parameters you’ll need to
deploy only rarely, to improve your database’s performance or to overcome
some special performance problems. Some examples of the initialization
parameters in the advanced set are the CURSOR_SHARING and CURSOR_
SPACE_FOR_TIME parameters. Oracle recommends that only experienced
Oracle DBAs configure the advanced initialization parameters.
Initialization Parameter Views

You can view the database initialization parameters, as in Oracle9i, by querying the
V$PARAMETER view or the V$SPPARAMETER view, depending on whether you
are using the init.ora file or the SPFILE to store your initialization parameters.
EXERCISE 1-3
Using the OEM Database Control

to View Initialization Parameters
You can also use the OEM Database Control to view your initialization parameters.
To view the parameters using the Database Control, follow these steps:
1. Go the Database Control home page.

2. Click the All Initialization Parameters tab on the Administration page.
3. If you wish to change any parameters, you can do so from here and click
Save to File.
4. If you wish configuration changes to come into force immediately, click the
SPFILE tab first, and then check the Apply Changes in SPFile mode to
the current running instance box.
Changes in the Initialization Parameters

In Oracle Database 10g, several traditional initialization parameters have become
obsolete or deprecated. You also have access to several new parameters. Here’s a list
of some of the important deprecated, obsolete, and new initialization parameters in
Oracle Database 10g:
Deprecated Parameters Obsolete Parameters New Parameters

MTS_DISPATCHERS DISTRIBUTED_TRANSACTIONS RESUMABLE_TIMEOUT
UNDO_SUPPRESS_ERRORS JOB_QUEUE_INTERVAL SGA_TARGET
PARALLEL_AUTOMATIC_ ORACLE_TRACE_COLLECTION_ PLSQL_OPTIMIZE_LEVEL
TUNING NAME
MAX_ENABLED_ROLES
Irreversible Datafile Compatibility

In prior Oracle database versions, you could revert to a previous compatibility
setting by using the alter database reset compatibility command.
This command is now obsolete. Once you start the database, you cannot go back
to a compatibility value that’s less than the current value of the COMPATIBLE
Viewing Database Feature Usage Statistics 23
initialization parameter in your init.ora (or SPFILE) file. Thus, the COMPATIBILE
initialization parameter is now irreversible. This section provides the new details on
the compatibility feature.
The minimum value of the compatibility setting is now 9.2.0. That is, if you set
the COMPATIBLE initialization parameter to 9.2.0., your datafile formats will be
compatible with the Oracle9i Release 2 version. This means that if you wish, you
can always downgrade your new Oracle 10g database to a 9.2.0 version, as long as
you have installed the Oracle9i Release 2 (9.2.0.3) or later executables on your
system along with the Oracle 10g server software. If you set the COMPATIBILE
initialization parameter to 9.2, however, you can take advantage of only a subset of
the new Oracle 10g features. Therefore, use the 9.2 compatibility setting only if you
think you may need to revert to the Oracle9i version for some reason.
By default, Oracle sets the file format compatibility to 10.0.0. If you don’t set the
COMPATIBLE parameter in your init.ora file, or if you set it explicitly to 10.0.0,
the compatibility level will be set to the Oracle 10g file format compatibility. This
means that you won’t be able to downgrade the Oracle 10g database to a prior
release. In that case, in order to start you database with a lower compatibility setting,
you would need to perform a point-in-time database recovery and recover to a point
in time that was before you advanced the compatibility level.
To check the current compatibility level of your database, which is set by the value
you chose for the COMPATIBLE initialization parameter, use the following statement.
SQL> SELECT name, value, description FROM v$parameter
WHERE name = 'compatible';
The minimum value of the COMPATIBILE initialization parameter is 9.2.0.

The default value, however, is 10.0.0.
Viewing Database Feature Usage Statistics

In Oracle 10g, you can track database usage metrics, which enable you to understand
two important aspects:
■ How you are using the various features of your Oracle database, including
whether the database is currently using a given feature, as well as the first
and last times it used a given feature.
■ The high-water mark (HWM) statistics for important database attributes. The
HWM is simply the highest usage point a feature has attained up to now.
The database features that you can track include features like Advanced Replication,
Oracle Streams, Virtual Private Database (VPD), and various auditing features.
Oracle Database 10g collects HWM statistics for items like the following:
■ Maximum size of tables

■ Maximum number of datafiles
■ Maximum number of sessions
■ Size of the largest data and index segment
Let’s briefly look at how the Oracle database collects these statistics.
The Statistics Collection Process

How exactly does Oracle collect these new kinds of statistics? Oracle Database 10g
introduces a new database process called Manageability Monitor Process (MMON),
which records both the database usage statistics and the HWM statistics for various
objects. MMON is a new Oracle 10g background process, and it is primarily
responsible for various manageability-related background tasks, including taking
snapshots of data, issuing database alerts, and collecting statistics.
MMON records the various statistics inside the Automatic Workload Repository
(AWR), which, as you’ll see in later chapters, is a new Oracle Database 10g innovation
that stores database performance data. By default, MMON samples the data dictionary
once a week, to collect both database feature usage and HWM statistics.
You can query the new DBA_FEATURE_USAGE_STATISTICS data dictionary
view to find out the usage statistics of various features that MMON has stored in the
AWR. Here’s the structure of this view:
SQL> desc dba_feature_usage_statistics
Name Null? Type
––––––––––––––––––––––––––
DBID NOT NULL NUMBER
NAME NOT NULL VARCHAR2(64)
VERSION NOT NULL VARCHAR2(17)
DETECTED_USAGES NOT NULL NUMBER
TOTAL_SAMPLES NOT NULL NUMBER
CURRENTLY_USED VARCHAR2(5)
FIRST_USAGE_DATE DATE
Viewing Database Feature Usage Statistics 25
LAST_USAGE_DATE DATE
AUX_COUNT NUMBER
FEATURE_INFO CLOB
LAST_SAMPLE_DATE DATE
LAST_SAMPLE_PERIOD NUMBER
SAMPLE_INTERVAL NUMBER
DESCRIPTION VARCHAR2(128)
You can also use the procedures REGISTER_DB_FEATURE and REGISTER_

HIGH_WATER_MARK in the new DBMS_FEATURE_USAGE package to track
feature usage and HWM statistics.
You can query the DBA_HIGH_WATER_MARK_STATISTICS data dictionary
view to see the HWM statistics and a description of all the database attributes that
the database is currently monitoring. Here’s a simple example:
SQL> select name, highwater, description
2* from dba_high_water_mark_statistics;
USER_TABLES Number of User Tables 760
SEGMENT_SIZE Size of Largest Segment (Bytes) 159383552
PART_TABLES Max Number of Partitions belonging to a Table 0
PART_INDEXES Max Number of Partitions belonging to a Index 0
USER_INDEXES Number of User Indexes 1353
SESSIONS Max No of Concurrent Sessions seen in database 28
DB_SIZE Maximum Size of the Database (Bytes) 901775360
DATAFILES Maximum Number of Datafiles 5
TABLESPACES Maximum Number of Tablespaces 6
CPU_COUNT Maximum Number of CPUs 1
QUERY_LENGTH Maximum Query Length 2122
Maximum Number of Services 4
12 rows selected.
SQL>
In this section, I have shown how you can query various data dictionary views to
track the database feature usage and HWM statistics. However, there’s an easier way
to monitor these statistics: just use the OEM Database Control to quickly check
the statistics. The next section describes how to use the OEM Database Control to
monitor database usage statistics.
Database Usage Statistics in the OEM

There are times when you would like to see whether and how the database is making
use of important features. A feature is simply a specific area of functionality for the
database. You can use the OEM Database Control to examine a list of the database
features and how the database is using those features. These usage patterns include
the frequency of usage, the first time the database used a certain feature, and the most
recent time the database used a certain feature. Following are the steps to viewing
database usage statistics in the OEM Database Control:
1. Go the Database Control home page. Click the Administration link and
go to the Configuration Management group. Click the Database Usage
Statistics link.
2. You’ll now be in the Database Usage Statistics property sheet. This property
sheet leads to two pages: the High Water Mark page and the Feature Usage
page. The Feature Usage page lists all the available database features by
name. You can also see if the database is currently using a certain feature, as
well as the first usage and last usage timings. To view details about the usage
statistics of any feature, just click the associated link on this page. Figure 1-1
shows the Feature Usage page of the Database Usage Statistics property sheet.
3. If you want to view the database HWMs, click the High Water Marks tab in
the Database Usage Statistics property sheet. This will take you to the High
Water Marks page. Here, you can see the HWM attained for each database
object, as well as the last sampled value for each feature and the version of
the database feature. Figure 1-2 shows the High Water Marks page of the
Database Usage Statistics property sheet.
FIGURE 1-1
The Feature
Usage page of
the Database
Usage Statistics
property sheet
Supported Upgrade Paths to Oracle Database 10g 27
FIGURE 1-2
The High Water

Marks page of
the Database
Usage Statistics
property sheet
Supported Upgrade Paths to Oracle Database 10g

Several of you currently use Oracle8i or Oracle9i databases. You’ll most likely be
upgrading all these databases to the new Oracle Database 10g version in the near
future. I have good news for all DBAs who are embarking on an Oracle Database 10g
upgrade project: Oracle has made the upgrade process remarkably simpler by automating
most of the upgrade process.
The following are the upgrade paths available to you to move up to Oracle
Database 10g:
■ If you have Oracle 7.3.3 or lower, or Oracle 7.3.4, 8.0.3, 8.0.4, 8.0.5, 8.1.5, or
8.1.6, you can’t directly upgrade to Oracle Database 10g. You’ll need to first
upgrade to an intermediate release database.
■ If you are using an Oracle 8.0.6, 8.1.7, 9.0.1, or 9.2 database, you can directly
upgrade to Oracle Database 10g.
You can migrate directly to the Oracle Database 10g version only if your
database is one of the following versions: 8.0.6, 8.1.7, 9.0.1, or 9.2.
You can upgrade to Oracle Database 10g in two ways: the traditional manual mode or
by using the Database Upgrade Assistant (DBUA), a tool that automates the upgrade
process. The DBUA is a refined version of the old Oracle Data Migration Assistant used
in previous versions. Note that you can also use the traditional export and import
utilities to perform your database upgrade, especially if you have a very small database.
Unlike in prior versions, the Oracle 10g upgrade process, even when you use the
manual method, is somewhat automatic. As you’ll see in the following sections,
the manual process invokes the startup upgrade command, after which you need
to run the main upgrade script, which performs all the necessary upgrades in the correct
dependency order. Oracle will determine the upgrade order of the various components,
by querying the new DBA_SERVER_REGISTRY data dictionary view. Oracle uses this
view to check for the existence of the various components that it needs to upgrade.
Oracle also queries the view to check the upgrade status of each component after the
main upgrade script finishes running. The DBMS_SERVER_REGISTRY is also the basis
for the new Post-Upgrade Status Tool, which you’ll learn about in a later section.
You can use either the DBA_REGISTRY or the DBA_SERVER_REGISTRY

view to ascertain the upgrade status of individual database components
loaded into the database. The two dictionary views are identical, except that
that the DBA_REGISTRY has an extra column: namespace. If you query this
view with the namespace set to SERVER, the results are identical to the
results you’ll obtain by using the DBA_REGISTRY data dictionary view.
Traditionally, Oracle DBAs have needed to run a number of scripts during the
database upgrade process, which made the whole process very strenuous and error-
prone. In Oracle Database 10g, you can now run the entire upgrade process with a
single upgrade script provided by Oracle. For example, to migrate from an Oracle
8.1.7.4 version database to the Oracle Database 10g version, you’ll need to run the
u0801070.sql script. You’ll see a detailed example of the execution of this script in
the “Steps in the Manual Upgrade Process” section later in this chapter.
In the following sections, I’ll briefly explain the upgrade process using both the
available methods.
The Manual Upgrade Process

The manual upgrade process means you do all the due diligence work: make sure
you remove or change all obsolete initialization parameters and run all the Oracle-
provided database upgrade scripts. During a manual upgrade process, you, the DBA,
must run SQL scripts from the command line to drive the upgrade process.
Using New Utility to Perform Pre-Upgrade Validation Checks 29
The advantage in using this method is that you control every part of the entire
upgrade process. Of course, the drawbacks of a manual method are that you must
perform a backup of the database yourself before the upgrade, remove or add all
necessary initialization parameters, and ensure that the SYSTEM tablespace has
adequate free space.
The Database Upgrade Assistant (DBUA)

When you use the DBUA, the tool performs all the preinstallation checks for you to
ensure that your database meets all the upgrade requirements, and then manages the
upgrade process automatically. Here is a summary of what the DBUA does for you
during a database upgrade:
■ Perform all pre-upgrade tasks, including checking for invalid datatypes, desupported
character sets, invalid user accounts, and sufficient free space in the tablespaces.
■ Back up the database.
■ Create any necessary objects.
■ Invoke the correct upgrade script.
■ Show the upgrade progress during the upgrade.
■ Create new parameter and listener files in the new Oracle Home.
The DBUA is a GUI tool, but you can also run it in the silent mode, by
using the following command at the operating system level: dbua.
To begin with, you need to analyze your existing system to see what changes may
be necessary. Fortunately, Oracle provides an excellent script called the Upgrade
Information Tool, which will ferret out this information for you automatically. We’ll
look at this new tool in the following section.
Using New Utility to Perform Pre-Upgrade

Validation Checks
Oracle now includes a brand-new tool, called the Upgrade Information Tool, to help
you collect various pieces of critical information before you start the upgrade process.
Too often, as you are aware, you might need to restart an upgrade process, owing to
incompatible initialization features or inadequate tablespace sizes.
The Upgrade Information Tool

The Upgrade Information Tool provides the following important information:
■ The SYSAUX tablespace You need to create a brand new tablespace

called the SYSAUX tablespace before you can run the Oracle Database 10g
upgrade script. The Upgrade Information Tool will tell you about this and
recommend the correct size for this tablespace.
■ Information about log files Oracle Database 10g requires the redo log files
to be at least 4MB in size. If your current log files in the database you are
going to upgrade are smaller than 4MB, the script will tell you to increase the
size of the redo log files before the upgrade.
■ Tablespace sizes If the current tablespaces don’t have enough free space,
the information will be logged, so you can increase the size of the tablespaces.
■ Initialization parameters The pre-upgrade script will save you a lot of
headaches by telling you which of your initialization parameters should be
removed (deprecated and obsolete parameters) and which new parameters
should be added before you can upgrade.
■ Database versions and compatibility level The Upgrade Information Tool
lets you know if you need to change your database compatibility level, using
the COMPATIBLE initialization parameter.
■ Time estimates The Upgrade Information Tool also provides you an
approximate estimate of the time it will take for you to complete your upgrade.
As you can see, running the Upgrade Information Tool prior to your manual
upgrade process does a lot of the manual work for you! As long as you read the log
file of the Upgrade Information Tool carefully and implement the recommended
changes, you are well set to upgrade to Oracle Database 10g.
Both the manual upgrade process and the DBUA can use the Upgrade
Information Tool. If you are performing a manual upgrade, you need
to invoke the tool by running the SQL script utlu101i.sql. The DBCA
automatically runs it as part of the pre-upgrade check.
Using New Utility to Perform Pre-Upgrade Validation Checks 31
The Upgrade Information Tool is really nothing but a simple Oracle-provided

SQL script, called utlu101i.sql (located in the usual $ORACLE_HOME/rdbms/
admin directory), which helps you find out how your database stacks up for the
upgrade process. Here’s how you start the Upgrade Information Tool in your
pre-upgrade database:
SQL> @$ORACLE_HOME\rdbms\admin\utlu101i.sql
Oracle Database 10.1 Upgrade Information Tool 04-14-2004 10:07:08
Database:
––––-
–> name: FINANCE
–> version: 8.1.7.0.0
–> compatibility: 8.1.0
WARNING: Database compatibility must be set to 9.2.0 prior to upgrade.
Oracle Database 10.1 Upgrade Information Tool 04-14-2004 10:07:08
. …
The Post-Upgrade Status Tool

Oracle Database 10g also provides a new Post-Upgrade Status Tool, which gives you
an accurate summary of the upgrade process and any necessary corrective steps to be
taken. In the past, you had to determine the success of an upgrade by looking for any
error messages. However, the absence of error messages during the upgrade doesn’t
guarantee that your upgrade was successful. The Post-Upgrade Status Tool looks in
the component registry called DBA_SERVER_REGISTRY to check the status of each
database component. If one or more components don’t have a valid status or carry
the wrong version number, the Post-Upgrade Status Tool will list the component
information for you.
You can restart a failed database upgrade job from the point where you failed.
The Post-Upgrade Status Tool provides the following information:
■ The name and status, either VALID or INVALID, of each database component
■ The component’s version compatibility with the current database version
■ Suggestions for corrective action to take if there are any invalid components
after the upgrade process is completed (such as the appropriate script names
to run)
As in the case of the Upgrade Information Tool, you use an Oracle-supplied script
to invoke the Post-Upgrade Status Tool. This script is the utlu101s.sql script, located
in the $ORACLE_HOME/rdbms/admin directory on your server.
if you use the DBUA to upgrade, the utlu101s.script runs automatically. If you
are performing a manual upgrade, you need to run the script yourself, after
the upgrade process is finished.
Using the Simplified Upgrade Process

Although it is easy to perform a manual upgrade to Oracle Database 10g, the fact
remains that you need to do all the due diligence, and a critical mistake like omitting
a key step could cost you dearly in terms of time. Oracle recommends that you use
the DBUA to facilitate the database upgrade process. The DBUA takes care of the
following tasks for you:
■ Deletes all obsolete initialization parameters

■ Changes the ORACLE_HOME settings automatically
■ Runs the appropriate upgrade scripts for your current release
■ Configures your listener.ora file
Both the manual upgrade and the DBUA upgrade process perform the same set
of steps: performing pre-upgrade checks to ensure that the database meets all the
requirements, running the Oracle-supplied upgrade script, and so on. However, the
DBUA performs additional chores like configuring the listener.ora file.
Which one of the two methods is superior? I think either one is good enough,
with the DBUA being easier on your nerves if you are relatively new to the
database upgrading business. If you are a veteran Oracle DBA, going through
the manual process may be the best way to go, in my opinion.
Note that some of the material regarding the database upgrade process in the
following sections may be more detailed than what’s necessary to merely pass the
certification exam. However, the review would come in handy when you are
upgrading your databases to Oracle Database 10g.
Using the Simplified Upgrade Process 33
How Does the DBUA Work?

The DBUA performs several steps before and during the database upgrade process.
In effect, the DBUA combines the work of the Upgrade Information Tool and the
manual upgrade process, which you have seen in the previous sections. The DBUA
performs all the necessary pre-upgrade steps for you automatically, including the
following:
■ Change the ORACLE_HOME settings to the new Oracle Database 10g

software locations.
■ Change the /etc/oratab entries to reflect the new location.
■ Copy the existing init.ora file from its old location to the new Oracle
Database 10g default init.ora location ($ORACLE-HOME/dbs under UNIX).
■ Check for adequate space in your tablespaces, including the undo tablespace
or the rollback segments, before the upgrade process begins.
■ Check for desupported character sets, invalid data types, invalid usernames,
and so on.
■ Perform a backup of the database, if you choose.
As you have seen, the upgrade process isn’t really a horrendous process, even
when you do it using the manual method. With the DBUA, upgrading becomes
even easier. As you know by now, the DBUA incorporates all three steps of the
upgrade process: the pre-install checks, the actual upgrade process, and the post-
upgrade checks. You can use the DBUA to upgrade any database configuration,
including RAC and standby databases.
DBUA Startup
You can start the DBUA by selecting Programs | Oracle | Configuration and Migration
Tools | Database Upgrade Assistant. Figure 1-3 shows the Welcome screen of the
DBUA. If you are on a UNIX system, simply type dbua (after logging in as the Oracle
user) at the operating system prompt to start up the DBUA GUI.
If you don’t want to deal with the GUI, you have the wonderful option of simply
doing a silent upgrade using the DBUA. This means you won’t be prompted for
anything—you simply wait for a couple of hours, and if there are no major problems,
your database will be automatically upgraded for you. Use the following command
for the silent invocation of the DBUA (assuming your database name is nina):
$ dbua -silent –dbName nina
FIGURE 1-3
The Welcome
Screen of the
Database
Upgrade
Assistant
This command is all you need to migrate your current database to Oracle Database 10g.
The Upgrade Process with the DBUA

The following are the steps to performing a database upgrade using the DBUA in the
interactive GUI mode (you click Next to continue after each step):
■ Select the database instance to upgrade. In the Selecting a Database

Instance screen, first ensure the chosen database has already been started.
Then select the database instance to be upgraded.
■ Create the SYSAUX tablespace. Next is the Sysaux Tablespace screen. Let
Oracle create the new SYSAUX tablespace for you.
The SYSAUX tablespace is a mandatory new tablespace in Oracle Database 10g.

Oracle uses the SYSAUX tablespace to store the data for several Oracle
features, including the RMAN. If you use the DBUA to upgrade, Oracle will
automatically create the SYSAUX tablespace for you. On the other hand, if
you manually upgrade, you must create the SYSAUX tablespace, as described
in the “Steps in the Manual Upgrade Process” section later in this chapter.
■ Choose the option to recompile invalid objects. The next screen gives you
the option of automatically recompiling any invalid database objects after the
database upgrade is completed. Let Oracle recompile objects that are invalid.
Letting Oracle recompile all invalid objects at the end of the upgrade is
equivalent to manually running the utlrp.sql script during a manual upgrade.
■ Back up your database. The next screen gives you a last chance to do a cold
backup of your database, if you haven’t already done so. If you (as any sane
DBA would) have already done your backups, choose the I Have Already
Backed Up My Database option.
■ Choose the OEM configuration. The next screen is the Management
Options screen, which provides options to configure the OEM, as well as
backups. You can choose either the Grid Control or Database Control
version of the OEM to manage your upgraded database. As noted previously
in this chapter, the Database Control component comes with your database
installation software, and Oracle automatically installs it when you install
Oracle Database 10g, but you must install the Grid Control from separate
software. Grid Control assumes that you have already created a Management
Service on one of the servers in your grid. If you haven’t already installed
the Grid Control software, it may be best to choose the Database Control
at this early stage in the game.
■ Define the Flash Recovery Area. The DBUA then asks you to choose a
flash recovery area, which, as described earlier in this chapter, is used as
the default area for your backup and recovery-related operations.
■ Choose database passwords. In the Database Credentials screen, the DBUA
asks you to choose passwords for users like SYSMAN and DBSNMP, which
are default users of all Oracle databases.
■ Verify the details of the upgrade The Upgrade Summary screen comes next.
The summary includes the source and target database names and database
versions. You should verify the following important details at this stage:
■ Database name
■ Oracle Homes for the source and target databases
■ Source and target database versions
The Upgrade Summary screen also shows an estimate of the database upgrade
time. Click Finish to start the upgrade process. Figure 1-4 shows the upgrade
progress screen of the DBUA.
FIGURE 1-4
The DBUA
upgrade progress
screen
■ Accept upgrade results or restore from backup. Finally, after the upgrade
is completed, the DBUA shows you the results in the Upgrade Results
screen, as shown in Figure 1-5. You can do three tasks using the Upgrade
Results screen:
■ Check the upgrade details.
■ Manage passwords in the database.
■ If you wish, restore the pre-upgrade database.
How to Restore to the Pre-Upgrade Version

Amazingly, you can now choose to go back to the pre-upgrade version of your database,
if you so choose. You can do this by simply clicking the Restore button. This will
restore the database to the pre-upgrade version, if you have chosen the option to have
the RMAN perform a cold backup during the DBUA process. If you didn’t use the
DBUA to perform the backup (through the RMAN), it will tell you that it cannot
perform a restore.
FIGURE 1-5
The DBUA
Upgrade Results
Screen
You can automatically revert to an older version of your database after

the 10g upgrade completes only if you’ve used the DBUA to back up your
database first.
What if you chose not to restore the database to the pre-upgrade status, and later
found that you had made a terrible mistake in turning down the kind offer of the
DBUA to undo the upgrade process? Not to worry—you can just run an Oracle-
provided script to restore back to the pre-upgrade database. This script is created by
Oracle when you choose to back up the database during the beginning part of the
upgrade process. Here’s how I ran the script on my Windows machine to undo an
Oracle Database 10g upgrade (Note that finance is the name of my recently upgraded
database.)
SQL> @C:\oracle\product\10.1.0\admin\finance\backup\FINANCE_restore.bat
Starting Up the Database Using

a New Mode When Upgrading
Although Oracle strongly recommends that you use the DBUA tool to upgrade your
database, we’ll step through the manual database process in this section, so you
understand the various activities that a database upgrade involves. This will also give
you the chance to see how to start up a database using a new mode—startup upgrade—
when you are upgrading it to Oracle Database 10g.
Remember that the DBUA automatically performs virtually all the same steps for
you behind the scenes. After you run your Upgrade Information Tool, as described
earlier in this chapter, make sure you’ve made all the recommended changes, so you
don’t run into unnecessary error messages during the upgrade process.
Steps in the Manual Upgrade Process

Here are the steps in the manual upgrade process:
1. Start a spool file.

2. Start the Upgrade Information Tool.
3. Back up your current database.
4. Copy your present init.ora file to the new Oracle Database 10g default location.
5. If you are using a Windows-based version of Oracle, remove the old instance.
6. Start up the database.
7. Create the SYSAUX tablespace.
8. Run the upgrade script.
9. Verify the existence of invalid objects.
10. Run the utlrp.sql script to automatically recompile and validate all the
invalidated PL/SQL and Java code in your database.
11. Run the utlu101s.sql script (the Post-Upgrade Status Tool).
These steps are detailed in the following sections:
Starting Up the Database Using a New Mode When Upgrading 39
Start a Spool File

Start a spool file, so you can easily review the upgrade process.
SQL> spool upgrade.log
Run the Upgrade Information Tool

Run the Upgrade Information Tool while connected to the database that you are
upgrading. The Upgrade Information Tool is run by executing the utlu101i.sql script,
which is located in the new Oracle Database 10g software’s ORACLE_HOME/rdbms/
admin directory.
SQL> @$ORACLE_HOME/rdbms/admin/utlu101i.sql
To review the results of this pre-upgrade check, turn spooling off using the
following command:
SQL> spool off
Here’s the partial output from a test I ran on my Windows server. Note that I am
upgrading an Oracle 8.17 database to the Oracle Database 10g version.
*************************************************************************
Database:
–> name: FINANCE
–> version: 8.1.7.0.0
–> compatibility: 8.1.0
WARNING: Database compatibility must be set to 9.2.0 prior to upgrade.
***********************************************************************
Update Parameters: [Update Oracle Database 10.1 init.ora or spfile]
WARNING: –> "shared_pool_size" needs to be increased to at least "150944944"
*************************************************************************
Obsolete Parameters: [Update Oracle Database 10.1 init.ora or spfile]
–> "job_queue_interval"
–> "max_enabled_roles”
*************************************************************************
Components: [The following database components will be upgraded or installed]
–> Oracle Catalog Views [upgrade]
–> Oracle Packages and Types [upgrade]
...
*************************************************************************
SYSAUX Tablespace: [Create tablespace in Oracle Database 10.1 environment]
–> New "SYSAUX" tablespace
.... minimum required size for database upgrade: 500 MB
Please create the new SYSAUX Tablespace AFTER the Oracle Database
10.1 server is started and BEFORE you invoke the upgrade script.
Back Up Your Database

At this point, shut down and back up your current database, by using either the
RMAN or by using user-managed backup techniques.
Copy Your init.ora File

Copy your present init.ora file to the new Oracle Database 10g default location (for
example, $ORACLE_HOME/dbs under UNIX). Make all the necessary changes in
your init.ora parameter file, as per the Upgrade Information Tool’s recommendations.
Completely Remove Any Windows-Based Oracle Instances

If you are using a Windows-based Oracle version, you need to do the following, to
make sure that you completely remove the old instance before creating the new Oracle
Database 10g instance.
C:\> net stop oracleservicefinance
The OracleServiceFINANCE service is stopping
The OracleServiceFINANCE service was stopped successfully.
C:\> oradim -delete -sid finance
Instance deleted.
C:\>
C:\>oradim -new -sid finance -intpwd finance1 -startmode auto –
pfile c:\oracle\product\10.1.0\Db_1\database\initfinance.ora
Instance created.
C:\>
Start Up the New Database

Start up the database under the new Oracle Database 10g Home, after making sure
that the updated init.ora parameter file is in its default location.
Make sure you start up the Oracle Database 10g in the following manner, to start
the upgrade process. Note the use of the new startup upgrade command. You
must use this command, or the upgrade won’t start. Using the startup upgrade
command tells Oracle to automatically modify certain parameters, including
initialization parameters that cause errors otherwise (for example, it sets the job_
que_processes parameter to zero).
C:\> sqlplus /nolog

SQL*Plus: Release 10.1.0.2.0 - Production on Wed Apr 14 11:13:25 2004
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> connect / as sysdba
Connected to an idle instance.

SQL> startup upgrade
ORACLE instance started.
Total System Global Area 310378496 bytes
Fixed Size 788268 bytes
Variable Size 309328084 bytes
Database Buffers 0 bytes
Redo Buffers 262144 bytes
Database mounted.
Database opened.
SQL>
Create the SYSAUX Tablespace

After you start up the database with the startup upgrade command, first create
the new mandatory SYSAUX tablespace, as recommended by the Upgrade Information
Tool. Here’s an example:
SQL> CREATE TABLESPACE sysaux DATAFILE 'sysaux01.dbf'
SIZE 500M REUSE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;
At this point, the database is technically converted into a Oracle 10g version,
although you yet have to run the main upgrade script.The following query
demonstrates this:
SQL> select * from v$version;
BANNER
––––––––––––––––––––––––––––––––
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 – Prod
PL/SQL Release 10.1.0.2.0 – Production
CORE 10.1.0.2.0 Production
TNS for 32-bit Windows: Version 10.1.0.2.0 – Production
NLSRTL Version 10.1.0.2.0 – Production
SQL>
Run the Upgrade Script

Although the database is opened, and although the query on V$VERSION shows that
your database in now an Oracle 10g version, you still need to run the actual upgrade
script, which is your next task. Each version of Oracle has a separate upgrade script.
Here are the various versions of Oracle you can directly upgrade to Oracle 10g, and
the corresponding upgrade script for each.
■ 8.0.6: u0800060.sql
■ 8.1.7: u0801070.sql
■ 9.0.1: u0900010.sql
■ 9.2: u0902000.sql
Since I am upgrading a 8.1.7 database, I choose the u08010870.sql upgrade script,

which is located in the $ORACLE_HOME/rdbms/admin directory.
SQL> @c:\oracle\product\10.1.0\Db_1\rdbms\admin\u0801070.sql
The u0801070.sql upgrade script calls several other scripts to manage the upgrade
process. The upgrade script will call various Oracle SQL scripts, as shown here:
call i0801070.sql:
This loads all tables that are necessary to perform basic sql commands.
call utlip.sql to invalidate views, procedures, packages
call c0801070.sql:
This performs all necessary dictionary upgrades to bring the db from 8.1.7 to
the new release.
call a0801070.sql:
This performs all necessary upgrade using anonymous blocks.
call cmpdbmig.sql
This calls the upgrade scripts for all of the components that have been loaded
into the database. The script uses procedures from the DBMS_REGISTRY package
to execute various component upgrades.
Verify the Existence of Invalid Objects

During the upgrade process, Oracle will create, drop, and alter several database tables
and other objects. Thus, it’s only natural that several internal Oracle packages and
procedures will become invalidated during the course of the upgrade. Once the
upgrade script finishes, you can verify the existence of invalid objects by running the
following script:
SQL> select count(*) from dba_objects
2 where status = 'INVALID';
COUNT(*)
–––––––
16742
1 row selected.
SQL>
Recompile and Validate the Invalidated PL/SQL and Java Code

Wow! A large number of procedures and packages have been invalidated, but not to
worry! Just run the Oracle utlrp.sql script, which will automatically recompile and
validate all the invalidated PL/SQL and Java code in your database. Of course, even
if you don’t recompile all the invalidated packages and procedures in this way, Oracle
will validate each object at run time, when a user accesses the object. However, this
might lead to a deterioration in run-time performance, so you’re better off recompiling
all the objects during the upgrade process itself. Note that the utlrp.sql script actually
calls another script—the utlprp.sql script, which is a wrapper based on the UTL_
RECOMP package.
SQL> @C:\oracle\product\10.1.0\Db_1\rdbms\admin\utlrp.sql
TIMESTAMP
–––––––––––––––––––––––––––––-
COMP_TIMESTAMP UTLRP_BGN 2004-04-14 19:03:37
1 row selected.
PL/SQL procedure successfully completed.
TIMESTAMP
–––––––––––––––––––––––––––––-
COMP_TIMESTAMP UTLRP_END 2004-04-14 19:39:36
1 row selected.
SQL>
Just to make sure that there aren’t any more invalid objects left, run the following
query again:
SQL> select count(*) from dba_objects
2 where status = 'INVALID';
COUNT(*)
–––––
0
1 row selected.
SQL>
Besides validating all remaining invalidated database objects, the utlrp.sql script
also checks for the validity of each individual component in the database. As you
have seen earlier in this chapter, the DBA_SERVER_REGISTRY view will contain
information about all the component entries. The utlrp.sql script will update DBMS_
SERVER_REGISTRY after it runs, to let Oracle know that it has validated all objects.
You can also revert back manually to the older database by using the DB_
Name_restore.bat file (under Windows). To restore your old database using
either of the two methods mentioned here requires that you enabled the
DBUA to perform a backup of your database (with the RMAN). If you chose
not to have the DBUA perform a pre-upgrade backup, you can still revert to
your old pre-Oracle 10g version database by simply restoring from your own
backups. The key here is to ensure that you have a backup, either made by
you or created by the DBCA, before you start the upgrade process.
Run the Post-Upgrade Status Tool

Once you complete the upgrade process, run the following script, which works as the
Post-Upgrade Status Tool.
SQL> @utlu101s.sql TEXT
The Post-Upgrade Status Tool provides a summary of the upgrade process, as

shown in the following listing from my upgrade process (Note that the utlu101s.sql
script is followed by the word TEXT, to enable the printing of the following output):
SQL> @c:\oracle\product\10.1.0\Db_1\rdbms\admin\utlu101s.sql TEXT
Oracle Database 10.1 Upgrade Status Tool 13-APR-2004 03:21:22
–> Oracle Database Catalog Views Normal successful completion
–> Oracle Database Packages and Types Normal successful completion
–> JServer JAVA Virtual Machine Normal successful completion
–> Oracle XDK Normal successful completion
–> Oracle Database Java Packages Normal successful completion
–> Oracle interMedia Normal successful completion
–> Spatial Normal successful completion
–> Oracle Text Normal successful completion
No problems detected during upgrade
SQL>
Where does the Upgrade Status Tool get its information about the various
components? The tool simply queries the DBA_SERVER_REGISTRY table to
determine the upgrade status of each individual component. You can get the same
output as that produced by the utlu101s.sql script, by running the following query:
SQL> select comp_id, comp_name, version, status
from dba_server_registry;
Based on the outcome of your database upgrade, the Upgrade Status Tool will
tell you one of the following: all the database components have been successfully
upgraded (Normal Successful Completion), or some of the components haven’t been
cleanly upgraded. If a component hasn’t been cleanly upgraded, the Upgrade Status
Tool will tell you the corrective action to take to fix the problem, as shown in the
following example.
SQL> @C:\oracle\product\10.1.0\Db_1\rdbms\admin\utlu101s.sql TEXT
Oracle Database 10.1 Upgrade Status Tool 14-APR-2004 04:59:46
–> Oracle Database Catalog Views Normal successful completion
–> Oracle Database Packages and Types Problem(s) detected
WARNING: ––> component status is not valid
––> version is correct
––> check upgrade log file for errors
––> script="re-run base update "u" script"
–> JServer JAVA Virtual Machine Normal successful completion
–> Oracle XDK Normal successful completion
–> Oracle Database Java Packages Normal successful completion
–> Oracle interMedia Normal successful completion
–> Spatial Normal successful completion
–> Oracle Text Normal successful completion
SQL>
Don’t try to start your newly upgraded database under your old Oracle Home
for any reason—this will corrupt your database.
After the Upgrade

You have now successfully upgraded your database to the Oracle Database 10g
(10.1.0.2.0) version. Of course, at this point, all your old application code, as well
database features, are strictly at the Oracle8i or Oracle9i level, depending on what
your pre-upgrade database version was. Now, you can check out the various new
features of Oracle Database 10g, as well as most of the Oracle database features, see
which ones are useful to you. The rest of this book focuses on explaining all the new
database administration features in Oracle Database 10g.
INSIDE THE EXAM
The exam contains questions about tracking You must understand the COMPATIBLE
Oracle Database 10g feature usage. Pay initialization parameter accurately for the test.
particular attention to tracking feature usage The exam tests your knowledge of the DBCA
through OEM as well as the DBA_FEATURE_ tool in creating a new database. Please look at
USAGE_STATISTICS view. Something else the various DBCA screens carefully. What
that the test might focus on are the high-water management options does the DBCA enable
mark statistics for various database objects. you to configure?
Which database objects does Oracle collect The exam will include a question or
high-water mark statistics for? two about the upgrade process. You must
The test expects you to know the new understand how to use the Pre-Upgrade
Oracle Policy Framework. How do you Information Tool and the Post_Upgrade
prioritize policy violations along various Status Tool. What scripts start these tools?
categories? The test may include a question You must also understand the role of the
about the new Database Cloning Tool DBA_SERVER_REGISTRY during a
(OEM Database Cloning wizard). What are database upgrade. How do you recompile
the various features of the source and target invalid objects?
databases during a cloning operation?
CERTIFICATION SUMMARY
This chapter provided you with a summary of Oracle 10g’s innovations in the software
installation and database upgrade areas. First, you looked at the support of new installation
features in Oracle 10g. These included the changes to the Oracle Enterprise Manager
(OEM) tool. You learned the difference between local and central installation of the
OEM. Other installation new features include the file storage options and backup and
recovery options. You also learned about the changes in the response file installation,
as well as the new irreversibility factor relating to the COMPATIBLE initialization
parameter.
You saw how you now perform an Oracle database installation from a single CD,
with minimal hardware requirements. You then looked at how Oracle 10g provides
you both pre-installation and post-installation support tools to ensure easy software
installation. Next, you learned about the new easier and cleaner Oracle software
deinstallation process.
The Database Creation Assistant (DBCA) has many changes, and this chapter
reviewed all of them. These include the mandatory creation of the SYSAUX
tablespace, the creation of the flash recovery area, and the Automatic Storage
Management (ASM) storage option. Management options include a choice between
the OEM Database Control and the OEM Grid Control. You also saw how the OEM
can now be used to link with OracleMetaLink service, perform database cloning, and
enforce a predetermined policy-based configuration framework.
An interesting new feature is how you can track database feature usage and high-
water mark (HWM) statistics. This chapter demonstrated how to use this feature
both manually as well as through the OEM Database Control.
In the database upgrade section, you first reviewed the supported upgrade paths
to the new Oracle Database 10g version. I then took you step-by-step through both
a manual and a DBUA database upgrade. You learned about the Oracle pre-upgrade
checks and the post-upgrade validation as well.
✓ TWO-MINUTE DRILL
❑ You have more management choices than with previous versions if you decide
to let Oracle create the starter database.
❑ The Oracle Universal Installer (OUI) now performs a series of pre-installation
checks before the installation process can start.
❑ You have a choice between two types of Oracle Enterprise Manager (OEM):
local management using the OEM Database Control or central management
using the OEM Grid Control. With the Database Control, you can manage
only a single database. With the Grid Control, you can manage several nodes
at once.
❑ The OEM Database Control comes with the Oracle 10g software installation.
You need to install the OEM Grid Control separately, using a separate CD.
❑ The default port number for the OEM Database Control is 5500.
❑ The installer enables you to configure default backup strategies.
❑ The installer gives you three storage choices: traditional UNIX/Windows file
systems, Automatic Storage Management (ASM), and raw devices.
❑ You need to specify database user (SYS and SYSTEM, for example) passwords
during database creation time.
❑ You can invoke the OUI from any node on a cluster that is part of an
installation.
❑ The Oracle 10g installer supports the installation of Cluster Ready Services
(CRS).
❑ You can use the OEM Grid Control to perform enterprise-wide configuration
changes.
❑ There are several changes in the response file creation, enabling a truly
“silent” installation. These changes include the following:
❑ New header formats
❑ No need to specify X server
❑ No need to specify the DISPLAY variable
❑ No instantiation of GUI classes
Two-Minute Drill 49
Performance Enhancements to the Installation Process

❑ Performance enhancements include a single CD Oracle software installation.
Companion CDs contain documentation, client software, demos, and the
OEM Grid Control components.
❑ Minimal hardware requirements are now necessary for Oracle 10g installation.
❑ The OUI performs most of the automatic pre-installation checks. It checks
for the correct operating system version, kernel parameters, patches, disk
space, and so on.
❑ Oracle also provides a new post-installation tool called the Upgrade Status
Tool. You can invoke the Upgrade Status Tool by running the script
$ORACLE_HOME/rdbms/admin/utlu101s.sql.
❑ Oracle 10g enables a cleaner software deinstallation process, wherein it
removes all the necessary files automatically as well as performing the
necessary Registry changes in Windows systems.
❑ Due to the new irreversible file compatibility feature, you cannot revert to
a lower compatibility value after you create a new Oracle 10g database.
❑ The minimum value of the compatibility setting is 9.2.0.
❑ The default setting of the compatibility setting is 10.0.0. This is also the
maximum value for the COMPATIBLE initialization parameter under Oracle
Database 10g Release 10.1.
❑ You now need a new mandatory tablespace, called the SYSAUX tablespace,
to store database metadata relating to various tools like the LOGMNR. This
brings the number of minimum tablespaces in an Oracle database to two;
SYSTEM is the other mandatory tablespace.
❑ The Database Configuration Assistant (DBCA) automatically creates the
SYSAUX tablespace for you.
❑ The flash recovery area is space that is dedicated to all backup and recovery-
related activities and files. The DBCA automatically creates this for you.
❑ You can now link OEM directly to the OracleMetaLink service. This enables
the automatic tracking of new software patches.
❑ You can now use the OEM to clone databases, provided you use RMAN to
back up the source databases. You can do this by selecting Maintenance |
Deployments | Clone Database from the OEM home page.

❑ To simplify basic instance configuration, Oracle now divides initialization
parameters into two groups: basic and advanced.
❑ There are about 25 to 30 basic initialization parameters (I saw the precise
figure of 28 initialization parameters in one Oracle Corporation white paper).
❑ There are several enhancements in the DBCA, which enables you to
configure the following:
❑ SYSAUX tablespace
❑ Flash recovery area
❑ Automatic Storage Management (ASM)
❑ You can now link the OEM directly to the OracleMetaLink service.
❑ You can automatically download patches through OracleMetaLink now.
❑ Using the OEM, it is easy to clone databases now.

❑ You can now view database feature usage statistics for various Oracle features
like auditing through the OEM Database Control. You can also view the
feature usage by querying the view DBA_FEATURE_USAGE_STATISTICS.
❑ You can view high-water mark (HWM) statistics for objects like tables,
indexes, and datafiles. The new view that you can use to check HWM
statistics is called DBA_HIGH_WATER_MARK_STATISTICS.
❑ You can now track whether your database is following predetermined
database configuration policies, and record all policy violations. Again, you
can use the OEM to perform this task.

❑ You can directly upgrade to the Oracle 10g (10.1.0) version only if you are
currently using the 8.0.6, 8.1.7, 9.0.1, or a 9.0.2 version database.
❑ You can upgrade to Oracle 10g by using the Database Upgrade Assistant
(DBUA) or by using a manual method.
Two-Minute Drill 51
Using New Utility to Perform Pre-Upgrade Validation Checks

❑ Use the new Upgrade Information Tool to gather pre-upgrade information.
You invoke this tool by running the utl101i.sql script located in the
$ORACLE_HOME/rdbms/admin directory.

❑ During a database upgrade, Oracle will now consult a new internal table
called the DBA_SERVER_REGISTRY. This table contains names of all the
components you are going to be upgrading, as well as their post-upgrade status.
❑ Oracle recommends that you use the DBUA to perform all database upgrades,
in order to reduce mistakes and make the process a lot simpler.
❑ The DBUA performs pre-upgrade checks including the following:
❑ Changes the ORACLE_HOME settings
❑ Changes the /etc/oratab entries
❑ Automatically deletes all obsolete initialization parameters
❑ Checks for adequate physical space for the upgrade
❑ Checks for any desupported character sets, invalid data types, and so on
❑ The DBUA will also provide you with a choice to back up your old database.
❑ Following are the upgrade steps using the DBUA:
❑ Start the DBUA by typing the command dbua in UNIX/Linux systems.
In Windows systems, click the Database Upgrade Assistant button under
the Oracle Programs list.
❑ Select the database to be upgraded from the list provided by the DBUA.
❑ Allow the DBUA to create the mandatory SYSAUX tablespace.
❑ Choose automatic recompiling of all objects after the upgrade process.
❑ Choose either the OEM Database Control or Grid Control under
management options.
❑ Choose a flash recovery area, where Oracle will store all backup and
recovery-related files.
❑ Approve the upgrade process after looking at the summary provided by
the DBUA.
❑ If you choose to revert to the pre-upgrade version after the upgrade

process, you can do so by clicking the Restore button in the final DBUA
Upgrade Results screen.
Starting Up the Database Using a New Mode When Upgrading

❑ Following is a summary of the steps in a manual upgrade process:
❑ Adjust the tablespace and redo log sizes if necessary.
❑ Remove any deprecated or obsolete parameters and add any necessary
new parameters.
❑ Back up your current database.
❑ Copy the present init.ora file after you modify it, to the new Oracle 10g
default init.ora location.
❑ Under a Windows system, make sure the existing instance is stopped
and deleted using the oradim utility. Create a new instance using the
same utility.
❑ Start the database from the new Oracle 10g Home.
❑ Begin the upgrade process by issuing the command startup upgrade.
❑ Create the SYSAUX tablespace.
❑ Run the appropriate upgrade script for your database version (for example,
u0801070.sql for an 8.1.7 version database).
❑ Once the upgrade script finishes running, compile any invalid objects by
running the utlrp.sql script.
❑ Check to make sure there aren’t any invalid objects.
❑ Invoke the Upgrade Status Tool by running the utlu101s.sql script from
the $ORACLE_HOME/rdbms/admin directory. Remember that you can
get this information by querying the DBA_SERVER_REGISTRY table
directly.
❑ If the Upgrade Status Tool indicates “Normal Successful Completion” for
all the database components, your upgrade is successful.
❑ For a successful upgrade, the query on the DBA_SERVER_REGISTRY
view should indicate “valid” under the status column for all the database
components in the new Oracle Database 10g.
Self Test 53
SELF TEST
The following questions will help you measure your understanding of the material presented in this
chapter. Read all the choices carefully because there might be more than one correct answer. Choose
all correct answers for each question.

1. Which of the following sets of tablespaces is mandatory for any Oracle 10g database?
A. SYSTEM, SYSAUX, and UNDOTBS
B. SYSTEM and UNDOTBS
C. SYSAUX and UNDOTBS
D. SYSTEM and SYSAUX
2. What does a DBA need to do for Oracle to perform the automatic pre-installation
requirements check, when you start installing the Oracle Database 10g Server software?
A. Run the Upgrade Information Tool manually.
B. Do nothing—Oracle will automatically perform the pre-installation checks.
C. Use the upgrade database command to open the database.
D. Execute the utls10x.sql script.
3. What does the Enterprise Configuration Management Tool do?
A. Helps you configure enterprise-wide configuration through the OEM Grid Control
B. Helps you configure enterprise-wide configuration through the OEM Database Control
C. Helps you configure the Oracle Database Control tool
D. Collects only database information, not host information

4. During a response file-based “silent” Oracle installation, what do you need to do?
A. Specify an X server while performing installations in a character mode console.
B. You don’t need to specify an X server while performing database installation in a character
mode console.
C. Set a DISPLAY variable on UNIX systems.
D. Use no header formats in the response file.
5. When you deinstall a Windows Oracle server installation, which of the following is true?
A. Oracle will automatically clean up the Windows Registry for you.
B. You must manually clean up the Windows Registry.
C. The Windows Registry doesn’t need to be changed.
D. The Windows operating system automatically cleans up the Windows Registry for you.
6. When you complete the Oracle software installation, which of the following products does
Oracle launch for you?
A. OEM Management Agent
B. OEM Database Control
C. OEM Grid Control
D. OEM Management Agent and OEM Database Control

7. Which one of the following initialization parameters would belong to the basic group
of parameters?
A. SHARED_POOL
B. CURSOR_SPACE_FOR_TIME
C. DB_NAME
D. CURSOR_SHARING
8. If you use the DBCA to create your new database, when is the creation of the new flash
recovery area mandatory?
A. Always
B. Only if you configure automatic backup using the OEM
C. Only if you configure user-managed backups
D. Only if you run your database in the archive log mode
9. Which of the following is a new initialization parameter for Oracle Database 10g?
A. UNDO_SUPPRESS_ERRORS
B. PARALLEL_AUTOMATIC_TUNING
C. RESUMABLE_TIMEOUT
D. SHARED_SERVER
Self Test 55

10. Where are database usage and high-water mark statistics stored?
A. Flash recovery area
B. Automatic Workload Repository
C. RMAN Repository
D. In the bit map area of the datafiles
11. Which two of the following are examples of an Oracle database high-water mark statistic?
A. SGA size
B. Number of named users
C. Size of the largest data segment
D. Maximum number of concurrent sessions
12. You have just upgraded your 8.1.7 release Oracle database to the new 10.1.0 version. You
did not specify a value for the COMPATIBLE initialization parameter. After using the new
database for a while, you decide you need to revert to your 8.1.7 database. Which one of the
following is true under these circumstances?
A. You cannot return to the 8.1.7 version.
B. Just add COMPATIBLE=8.1.7 to your initialization parameters. You should then be able
to go back to the 8.1.7 version.
C. Use the ALTER DATABASE RESET COMPATIBILITY command to go back to the
8.1.7 version.
D. You cannot go back to a time before the upgrade, unless you do a point-in-time recovery.

13. Which of the following Oracle versions is not an approved version for a direct upgrade to
Oracle 10g (10.1.0)?
A. 8.0.6
B. 8.1.7
C. 9.0.1
D. 8.1.6
14. In which of the following modes can you upgrade your current database to the Oracle
Database 10g version?
A. Database Upgrade Assistant
B. Oracle Data Migration Assistant
C. Export and import

D. Manual upgrade

15. What is the name of the Oracle-supplied script that runs the pre-upgrade validation checks?
A. utlu101i.sql
B. utl101i.sql
C. utlu101x.sql
D. utlu101s.sql
16. If you are using the DBCA to upgrade your database to the Oracle Database 10g version, which
of the following is true in relation to the Upgrade Information Tool?
A. You don’t need to run the utlu101u.sql script.
B. You must run the utl101u.sql script.
C. You must run the utlu101s.sql script.
D. You must choose the Pre-Upgrade Information Tool option while using the DBCA.
17. The Upgrade Information Tool provides information about which of the following?
A. Optimal SGA allocation to the various components of SGA, for example, the shared pool
B. Optimal performance features of Oracle Database 10g
C. Recommendations for additional space for tablespaces
D. A time estimate for the upgrade

18. You are using the DBUA to upgrade your database. One of the steps during the use of the
DBUA is a choice regarding the recompilation of invalid objects. Telling the DBUA to
recompile all invalid database objects after the upgrade is the same as running which script?
A. utlrpt.sql
B. utlu101i.sql
C. utlu101x.sql
D. utlrp.sql
19. You have just finished an Oracle Database 10g upgrade using the DBUA tool. You have chosen
most of the default settings, including letting the DBUA perform a pre-upgrade backup for
you. You are at the very end of the process, when the Upgrade Summary screen shows you the
Lab Questions 57
upgrade details. You suddenly realize that you made a mistake, and you would like to revert to
the previous software version, which is an Oracle 8.1.7.3 database. What can you do?
A. Just start up the new database from the old Oracle 8.1.7.3 Home.
B. Just click the Restore button on the update summary screen of the DBUA.
C. You need to start fresh by manually restoring your 8.1.7.3 database.
D. There is no way to restore to 8.1.7.3 at this point.

20. When you start up your database just prior to running the upgrade script, you need to use
which of the following commands?
A. startup mount
B. startup nomount
C. startup open
D. startup upgrade
21. Once you upgrade your database to the Oracle Database 10g version, which of the following
is true?
A. You can always start it either under the old Oracle Home or the new Oracle Home.
B. You will corrupt the database if you try to start it under the old Oracle Home.
C. You can start it under the old Oracle Home, as long as your compatibility is set to the old
database version level.
D. You can start it in either Oracle Home, as long as the compatibility level is set to 10.0.0.
LAB QUESTIONS
Lab 1
Using the OEM Database Control, find the locations of the following:
■ Tablespaces
■ Flash recovery area
Lab 2
Using the OEM Database Control, how do you find out the initialization parameters for the instance?
Lab 3
Manually create a SYSAUX tablespace with a size of 1GB.
Lab 4
Show all the command-line steps necessary to access the OEM Database Control (assume that no
OEM-related process is currently running on your server).
Lab 5
Show the steps necessary to clone a database, and explain the cloning process in detail.
Self Test Answers 59
SELF TEST ANSWERS

1. þ D. SYSTEM and SYSAUX are the two mandatory tablespaces, without which you cannot
create an Oracle Database 10g database.
ý A, B, and C are incorrect, since they include UNDOTBS, which isn’t a mandatory
tablespace in Oracle Database 10g. Remember that you still can use manually configured
rollback segments, in which case you won’t need an undo tablespace.
2. þ B. Oracle will automatically perform the pre-installation checks for you when you start
installing the software. There are no scripts to run.
ý A is wrong because the Upgrade Information Tool is used only for upgrades, not for
installations. It is the same case with option C as well. D is wrong since the utls101x.sql script
performs a post-upgrade check, not a pre-installation check.
3. þ A. The Enterprise Configuration Management Tool, as its name indicates, helps you make
enterprise-wide configuration changes, using the OEM Grid Control.
ý B is wrong since, by definition, you cannot perform enterprise-wide changes using the
OEM Database Control. C is wrong because the Oracle Database Control tool is configured
when you install the database software. D is wrong since the Enterprise Configuration Tool
collects database and host information across the enterprise.

4. þ B. Oracle Database 10g makes the response file-based “silent” installations easier, and one
of the ways is by not forcing you to specify an X server in a character mode console.
ý A and C are incorrect because they are not true in the Oracle 10g version. D is wrong, as
you still need header formats in the response file, although the newer header formats are a lot
easier to edit.
5. þ A. The Oracle Universal Installer will automatically clean up the Windows Registry for
you as part of the software deinstallation process.
ý B is wrong because you don’t need to perform a manual cleanup of the Windows Registry
anymore in the Oracle 10g database. C is incorrect since the Registry changes are necessary
after a software deinstallation. D is wrong since the Windows operating system doesn’t
automatically clean up the Registry after an Oracle deinstallation.
6. þ A, B, and D. Oracle launches both the OEM Management Agent and the OEM Database
Control automatically after installation.
ý C is wrong because the Oracle Universal Installer never launches the OEM Grid Control
is as part of Oracle server installation.

7. þ A and C. Both SHARED_POOL and DB_NAME belong to the basic set of initialization
parameters, which should be sufficient in most cases. The parameters in the advanced list are
necessary only under some special conditions.
ý You can easily see that B and D refer to initialization parameters that belong to the
advanced group, not the basic group of parameters.
8. þ B. The creation of the flash recovery area is mandatory only if you configure automatic
backups using the OEM.
ý A is clearly wrong, since the flash recovery area is not mandatory under all circumstances.
C is wrong because configuring user-managed backups doesn’t have anything to with the flash
recovery area. D is wrong as well, since the archive log mode in which the database is running
has no bearing on the flash recovery area.
9. þ C. RESUMABLE_TIMEOUT is a new Oracle Database 10g initialization parameter.
ý A, B, and D refer to initialization parameters that have become obsolete in Oracle
Database 10g.

10. þ B. The MMON process periodically collects database usage and high-water mark statistics
and stores them in the Automatic Workload Repository.
ý A is wrong since the flash recovery area is free space reserved for recovery-related
activities. C is wrong since the RMAN repository is used to store backup-related data. D is
clearly wrong, as bit maps in datafiles are used mostly for storage-related purposes.
11. þ C and D. The size of the largest data segment shows the “high point” of resource usage
for that data segment, and thus it captures a high-water mark statistic. The same is true of the
maximum number of concurrent sessions statistics.
ý A and B refer to statistics that aren’t part of the high-water mark statistics attributes.
12. þ D. This is a tough question. Once you used the database for a while, you cannot set the
compatibility back to a lower version. The compatibility level can be set only higher, not
lower. You just can’t start the new database with a lower level of compatibility. If you are
prepared to lose all the changes made since the upgrade, of course, you can always perform
a point-in-time recovery to a time that precedes the upgrade.
ý A is wrong since it implies there is no way you can go back to the previous version of
the software. B is wrong since you cannot set compatibility to a lower level compared to the
existing level. C is wrong since the alter database reset compatibility
command is obsolete in Oracle Database 10g.

13. þ A, B, and C. These answers all represent database versions that permit a direct upgrade
to Oracle Database 10g.
ý D. 8.1.6 belongs in the group of database versions that you cannot directly upgrade to
Oracle Database 10g.
14. þ A, C, and D. You can use either the DBUA or manual upgrade procedure to perform
an identical upgrade. Export and import also enable an upgrade to Oracle Database 10g.
ý B. The Oracle Data Migration Assistant is the predecessor to the DBUA in previous
versions of Oracle databases.

15. þ A. The utlu101i.sql script located in the $ORACLE_HOME/rdbms/admin directory is the
correct script to run the Upgrade Information Tool.
ý B misspells the correct script name. C refers to the wrong script. D is wrong because you
use this script for post-upgrade verification.
16. þ A. It is true that if you use the DBCA, you don’t need to run the utlu101is.ql manually.
The DBCA runs this for you, so it can provide you with vital upgrade-related information.
ý B is wrong, since you don’t need to run any scripts yourself, if you are using the DBCA.
The same reasoning applies to choice C. D is wrong because the Upgrade Information Tool
isn’t presented as an option to you by the DBCA; it automatically uses the tool before each
database upgrade, by invoking the utlu101i.sql script.
17. þ C and D. Both recommendations about additional space for tablespaces and upgrade time
estimates are part of the Upgrade Information Tool information.
ý A and B are invalid answers since the Upgrade Information Tool doesn’t give you any
performance-related information. Its goal is to ensure that you can perform the upgrade
successfully.

18. þ D. The utlrp.sql script will recompile all invalid objects in your database.
ý A misspells the correct answer. B and C both refer to pre-upgrade information scripts,
not scripts that you run after an upgrade.
19. þ B. As long as you have backed up the database using the DBUA, you can easily revert
to the pre-upgrade version of the database by clicking the Restore button after the upgrade
is completed.
ý A is wrong because you’ll end up corrupting your database if you start the upgraded
database from its old Oracle Home location. C is wrong because you don’t need to manually
restore the database—as long as you let it perform a backup beforehand, the DBUA will
perform the restore for you. D is incorrect because you can restore to 8.1.7 either through
the DBA or through a manual restore, if necessary.

20. þ D. You start a database with the new startup upgrade command prior to running
your upgrade scripts. Oracle will issue an error otherwise!
ý A, B, and C are incorrect, since they don’t use the keyword upgrade.
21. þ B. Once you upgrade your database to the Oracle Database 10g version, you must start it
under the new Oracle Database 10g Home. If you start it up under the old Oracle Home, you
may corrupt the database.
ý A and D are incorrect, since you cannot start the upgraded database from its old Oracle
Home. C is wrong since there is now no way (in Oracle 10g) to go to a lower level of database
compatibility.
LAB ANSWERS
Lab 1
To find out which tablespaces exist in your database:
1. From the Database Control home page, click the Administration link.
2. From the Administration page, click Tablespaces.
To find out the size and location of the flash recovery area:
1. From the Database Control home page, click the Maintenance link.
2. From the Maintenance page, click Configure Recovery Settings.
3. Go to the flash recovery area settings.
Lab 2
To find the initialization parameters for the instance:
1. Go to the Database Control home page.

2. Click the Administration link.
3. Click the Initialization Parameters link in the Instance section.
Lab Answers 63
Lab 3
To manually create a SYSAUX tablespace with a size of 1GB:
SQL> CREATE TABLESPACE sysaux DATAFILE 'sysaux01.dbf'
SIZE 1000M REUSE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;
Lab 4
The command-line steps to access the OEM Database Control are as follows:
1. Check whether the dbconsole process is running. (Make sure your database is up as well.
If it isn’t, there isn’t anything to manage!)
2. If the dbconsole process isn’t running, start it up by using the following command:
$> emctl start dbconsole
3. Once the dbconsole process starts up, you can access the Database Control using the
following URL in your web browser:
http://hostname:5500/em
5500 is the default HTTP port number, and it may be different in your case. Make sure you
log in as the SYS user or some other user with SYSDBA privileges.
Lab 5
You must use RMAN to perform backups. You can use the Clone Database wizard (also referred to
as the Clone Database Tool) to create a clone of an existing database. Following is a brief summary
of the cloning process:
■ The source database must be kept open.

■ The source database must belong to an Oracle 8.1.7 or higher version.
■ The Clone Database Tool (Clone Database wizard) will back up the source database files and
copy them to the target location.
■ The backup files are used to start up the new instance (in the OPEN mode), which has the
same initialization files as the source database.
Using the OEM, this is how you clone a database:
1. From the Database Control home page, click the Maintenance link.
2. Click the Clone Database link under the Deployments section.
Blind Folio 2:1
2
Loading and
Unloading Data
2.01 Introduction to the Data Pump 2.05 Defining Your External Table Properties
Architecture
2.06 Transporting Tablespaces Across
2.02 Using Data Pump Export and Import Different Platforms
2.03 Monitoring a Data Pump Job ✓ Two-Minute Drill
2.04 Creating External Tables for Q&A Self Test
Data Population
Monday, August 30, 2004 2:09:40 PM
2 Chapter 2: Loading and Unloading Data
A lmost every Oracle DBA is familiar with the traditional Oracle data-loading utilities:
export and import. In Oracle Database10g, you now have a newer and more
refined version of the old export and import utilities, called the Data Pump export
and import utilities. The old export and import utilities continue to be available under Oracle
Database 10g, but Oracle would prefer you to use the Data Pump technology, because it offers
you more sophisticated features than the old export/import technology.
While the Data Pump export and import utilities look quite similar to the traditional
export and import utilities, the new technology is vastly superior in many ways. For
example, you can now interrupt export/import jobs in the middle, and then resume
them. You can even restart failed export and import jobs. You can also remap object
attributes to modify the objects. You can easily monitor your Data Pump jobs from a
different session, and you can even modify job attributes on the fly, during the course
of a job. It is easy now to move massive amounts of data quickly, using parallelization
techniques. Because Oracle provides you the Application Programming Interfaces
(APIs) for the Data Pump technology, you can now easily incorporate export/import
jobs within PL/SQL programs.
The Data Pump export and import jobs need more startup time than the
old export and import utilities. Therefore, you may still want to use the old
export and import utilities for small jobs.
In this chapter, you’ll also look at the new features related to transportable tables,
as well as enhancements in the external tables feature, which was first introduced in
Oracle9i. In Oracle Database 10g, you can now write to external tables, instead of being
merely be able to read from them.
■ Introduction to the Data Pump architecture

■ Using Data Pump export and import
■ Monitoring a Data Pump job
■ Creating external tables for data population
■ Defining external table properties
■ Transporting tablespaces across different platforms
Let’s start this very important chapter with a brief introduction to the new Data
Pump technology.
Introduction to the Data Pump Architecture 3
Introduction to the Data Pump Architecture

The new Oracle Data Pump facility enables DBAs to transfer large amounts of data
and metadata at very high speeds compared to the older export/import technology.
Data Pump manages multiple, parallel streams of data to achieve maximum throughput.
Oracle claims that Data Pump enables you to decrease total export time by more than
two orders of magnitude in most data-intensive export jobs. Imports are supposed to
run 15 to 30 times faster than with the original import utility. Both of the above estimates
are for single-thread operations; parallel threads will make the operations even faster.
Oracle Data Pump is a complete superset of the original export and import utilities.
In addition to all the old capabilities of the export and import utilities, Data Pump
also lets you estimate job times, perform fine-grained object selection, monitor jobs
effectively, and directly load one database from a remote instance.
For compatibility purposes, Oracle still includes the old export and import utilities
in Oracle Database 10g. Thus, you can continue to use your export and import scripts
as usual, without any changes. Oracle Corporation recommends that you use the
Oracle Database10g Data Pump export and import, even though the older export
and import utilities are still available to you, because of the superior performance
provided by the newer tools. Oracle will support the original import utility forever.
This means that you’ll always have a way of importing dump files from earlier versions
of Oracle. However, Oracle will eventually deprecate the original export utility.
The new Data Pump technology lets you export data only to disk. You cannot
use a tape drive when performing a Data Pump export.
Oracle Data Pump technology consists of two components: the Data Pump export
utility, to unload data objects from a database, and the Data Pump import utility, to
load data objects into a database. You access the two Data Pump utilities through a
pair of clients called expdp and impdp. As their names indicate, the first of these
corresponds to the traditional export utility and the latter to the import utility. You
can control both Data Pump export and import with the help of several parameters.
Here’s how you invoke the two utilities:
$ expdp username/password (various parameters here)
$ impdp username/password (various parameters here)
I’m sure you are quite familiar with the interactive mode of using the traditional
export and import utilities. In this mode, you enter your choices in response to various
prompts. The parameters are the same for the interactive and command-line modes,
although you can use only a limited set of export and import parameters during an
interactive operation. Unlike in the old export and import utilities, Data Pump
utilities have a set of parameters you can use at the command line and a set of special
commands you can use only in an interactive mode. I’ll explain the main parameters,
commands, and the important features of the Data Pump toolset in the following
sections. You can also get a quick summary of all Data Pump parameters and commands
by simply typing expdp help=y or impdp help=y at the command line.
The Data Pump export utility will unload data into operating system files known
as dump files. It writes to these files in a proprietary format, which only the Data Pump
import utility can understand while loading the data in the dump files into the same
or another Oracle database. You can take Data Pump export dump files from an
operating system and import them into a database running on a different type of
platform, as is the case with the older export/import utilities.
The original export and Data Pump dump files aren’t compatible. You can’t
read export dump files with Data Pump and vice versa. The new features of
Oracle Database 10g aren’t supported in the original export utility, which
you’ll still have access to in Oracle Database 10g.
In addition to expdp and impdp, you can have other clients perform Data Pump
export and import as well, by using the Data Pump API. The database uses the Oracle-
supplied package DBMS_DATA PUMP to implement the Data Pump API. Through
this package, you can programmatically access the Data Pump export and import
utilities. This means that you can create powerful custom data-movement utilities
using the Data Pump technology.
The traditional export utility is a normal user process that writes data to its local
disks. The old export utility fetches this data from a server process as part of a regular
session. By contrast, the Data Pump expdp user process launches a server-side process
that writes data to disks on the server node, and this process runs independently of
the session established by the expdp client.
The Data Pump technology is remarkably different from the traditional export
and import utilities. In the following sections, you’ll learn about those differences
as we cover the following topics:
■ Benefits of Data Pump technology
■ Data Pump components
■ Data-access methods
■ Data Pump files
■ The mechanics of a Data Pump job
Benefits of Data Pump Technology

Data Pump technology offers several benefits over the traditional export
and import data utilities. The following are the main benefits of the Data
Pump technology:
■ Ability to restart data pump jobs You can now easily restart jobs that either
have stalled due to lack of space or have failed for various reasons. You may
also voluntarily stop and restart jobs.
■ Parallel execution capabilities By simply specifying a value for the
PARALLEL parameter, you can now choose the number of active execution
servers for each export job.
■ Ability to attach to running jobs You now have the amazing capability to
attach to a running Data Pump job from a different screen or location. This
enables you to monitor jobs, as well as to modify certain parameters interactively.
The jobs continue to run while you are attaching to and detaching from them.
Data Pump is an integral part of the Oracle Database server, and as such, it
doesn’t need a client to run once it starts a job.
■ Network mode of operation Once you create database links between two
databases, you can perform exports from a remote database straight to a dump
file set. You can also perform direct imports via the network using database
links, without using any dump files. The network mode is a means of transferring
data from one database directly into another database via SQLNET with the
help of database links, without needing to stage it on disk at all.
■ Fine-grained data import capability Oracle9i offered only one parameter
that gave you the ability to perform data loads at a fine-grained level. This
parameter was QUERY, which enabled you to specify that the export utility
extract only a specified portion of a table’s rows. Now with Data Pump, you
have access to a vastly improved fine-grained options arsenal, thanks to new
parameters like INCLUDE and EXCLUDE.
■ Remapping capabilities During a data pump import, you now have the
ability to remap schemas and tablespaces, as well as filenames, by using the
new REMAP_ * parameters. Remapping capabilities enable you to modify
objects during the process of importing data, by changing old attributes to
new values. For example, the REMAP_SCHEMA parameter enables you to
map all of user HR’s schema to a new user, OE. The REMAP_SCHEMA
parameter is similar to the TOUSER parameter in the old import utility.
■ Ability to estimate space requirements In a Data Pump job, you can now
estimate the space requirements of a job by using either the ESTIMATE or
the ESTIMATE_ONLY parameter.
Data Pump Components

On the surface, expdp and impdp, the clients for the Data Pump export and Data
Pump import utilities, respectively, are quite similar to the exp and imp commands.
However, while they are syntactically similar to the Data Pump clients, exp and imp
are absolutely ordinary user processes that use SQL SELECT, CREATE, and INSERT
commands. In contrast, the new utilities are more like control processes that initiate jobs.
The new Data Pump technology is based entirely on the server; all data movement
occurs on the server. The older export and import utilities acted as clients through
which all the data movement took place. In Data Pump export and import, the
database instance handles the Data Pump utilities.
You can look at the Data Pump technology as consisting of three major components:
■ The DBMS_DATA PUMP package

■ The DBMS_METADATA package
■ The command-line clients, expdp and impdp
The DBMS_DATAPUMP package contains the guts of the Data Pump technology,
in the form of procedures that actually drive the data loading and unloading jobs.
The contents of this package perform the work of both the Data Pump export and
import utilities. In traditional export/import, Oracle uses normal SQL to take the
data in the export dump files and inserts it sequentially into the database tables
during the import process. In the Data Pump technology, the DBMS_DATA PUMP
package performs the export and import of data.
The DBMS_DATA PUMP is the main engine for driving data loading and unloading.
To extract and modify data dictionary metadata, Oracle provides the DBMS_METADATA
package, which has been available since the Oracle9i version. In traditional export
and import utilities, the metadata of the objects is included in the export dump file.
In Data Pump technology, you need to use the DBMS_METADATA package to extract
the appropriate metadata.
Note that both the packages—DBMS_DATA PUMP and DBMS_METADATA—
act as APIs, in the sense that you can use either of them directly in your programs
to load and unload data, without accessing the expdp and impdp clients.
Data-Access Methods
A Data Pump import or export job can access table data in either of two ways,
depending on which one is faster for the specific case:
■ Direct path This access uses the Direct Path API. Direct path exports and
imports lead to improved performance, since the direct path internal stream
format is the same format as the data stored in Oracle dump files. This leads
to a reduced need for data conversions.
■ External tables The external tables feature lets Oracle read data from and
write data to operating system files that lie outside the database.
Since direct-path access doesn’t support intra-partition parallelism,

external tables are used for very large data loading or unloading jobs.
It is up to Oracle to decide which access method it will employ for a given job.
Oracle always tries to first use the direct-path method to load or unload data. Under
some conditions, such as the following, it may not able to use the direct method:
■ Clustered tables
■ Presence of active triggers in the tables
■ Export of a single partition in a table with a global index
■ Presence of referential integrity constraints
■ Presence of domain indexes on LOB columns
■ Tables with fine-grained access control enabled in the insert mode
■ Tables with BFILE or opaque type columns
In all these cases, the structure of the table and/or the indexes precludes the use
of direct-path access, so Data Pump will use external tables. On the other hand, if
your table has any LONG data, you must use the direct-path access.
The datafile format is can easily export data with one method
identical in external tables and the and import it with the other method,
direct-access method. Therefore, you if you wish.
Data Pump Files

As in the case of the traditional export and import utilities, Data Pump uses dump files
and other log files, but there are significant differences. You’ll use three types of files
for Data Pump operations:
■ Dump files These hold the data for the Data Pump job.
■ Log files These are the standard files for logging the results of Data Pump
operations.
■ SQL files Data Pump import uses a special parameter called SQLFILE,
which will write all the Data Definition Language (DDL) statements it will
execute during the import job to a file. Data Pump doesn’t actually execute
the SQL, but merely writes the DDL statements to the file specified by the
SQLFILE parameter. You use SQL files only to hold the output of the SQLFILE
command during a Data Pump import job. This parameter is discussed in the
“Data Pump Import Parameters” section later in this chapter.
In Data Pump, you use directories and directory objects, unlike in the export and
import utilities. The following sections explain how to use directory objects.
Using Directory Objects

Recall that the Data Pump technology is server-based, not client-based. This means
that a Data Pump job creates all its dump files on the server, not on the client machine
where a job may have originated. Oracle background processes are responsible for all
dump file set I/O, on behalf of the privileged user ORACLE. This means that for security
reasons, you can’t let any user be able to specify an absolute file path on the server. In
addition to a possible violation of security, there is the matter of safety, as you can
unwittingly overwrite a server file if you are given the power to write dump files anywhere
on the system. To avoid these problems, Data Pump uses directory objects.
Directory objects are named objects that Data Pump maps to a specific operating
system directory. For example, a directory object named dpump_dir1 can point to
the /u01/app/oracle/admin/export directory on the server. You can then access the
export directory by simply using the dpump_dir1 directory object name. Here’s how
you create a directory object:
SQL> CREATE DIRECTORY dpump_dir1 as 'c:/oracle/product/10.1.0/oradata/export';

Directory created.
To create a directory, a user must have the DBA role or have the CREATE ANY
DIRECTORY privilege.
In order for a user to use a specific directory, the user must have access privileges
to the directory object. For example, in order to grant user SALAPATI privileges on
the new directory dpump_dir1, you need to grant the following privileges:
SQL> grant read, write on directory dpump_dir1 to salapati

Grant succeeded.
SQL>
You’ll need the write privilege on all files for Data Pump export. During an
import, you’ll need read access to the export dump file. You’ll also need write
privileges on the directory for import, so that you can write to the log file.
Once you create a directory and grant the necessary rights, all Data Pump export
and import jobs can use the DIRECTORY parameter to specify the name of the
directory object (DIRECTORY=dpump_dir1). This way, the DIRECTORY
parameter will indirectly point to the actual operating system directories and files.
Here’s an example:
$ expdp salapati/password dumpfile=dpump_dir1.testexp01.dmp
You can create a specified as the value for DATA_PUMP_

default directory with the name DIR. Data Pump will write all dump files,
DATA_PUMP_DIR, and then not need SQL files, and log files to the directory
to specify the DIRECTORY parameter in specified for DATA_DUMP_DIR.
your export and import commands. Oracle Nonprivileged users cannot use this
will automatically look for the directory default DATA_PUMP_DIR directory.
Specifying Directory Objects

In order for the Data Pump utilities to know where to place or get data for their export
and import jobs, you need to specify location information when you use the expdp and
impdp clients. As you know by now, you can’t use absolute directory path location for
Data Pump jobs; you must always use a directory object. However, there is more than
one way to specify this directory object name during an actual job, as explained in the
following sections.
Using the DIRECTORY Parameter Earlier in this section, you learned how to
create a directory object. During a Data Pump export job, you can specify the directory
object by using the DIRECTORY parameter, as shown in the following example.
$ expdp hr/hr DIRECTORY=dpump_dir1 …
Using the DIRECTORY:FILE Notation You may also specify the directory
object without using the DIRECTORY parameter. You can do this by specifying the
directory object’s name as part of the value for a specific Data Pump file (the dump
file, log file, or SQL file). You may then use the specific directory object for a log file
in the following manner:
$ expdp LOGFILE=dpump_dir2:salapati.log …
Note that the colon (:) separates the directory and filenames in the log file
specification. In this example, dpump_dir2 is the name of the directory object.
The Data Pump filename is salapati.log.
Using the DATA_DUMP_DIR Environment Variable You can also use

the environment variable DATA_DUMP_DIR to point to a file location. In order to
use the DATA_DUMP_DIR environment, you must have first created a specific directory
object on the server. In this example, it is the dpump_dir1 directory described
earlier. Once you have this directory, you can then use the DATA_DUMP_DIR
environment variable on the client to point to the directory object on the server.
In the following example, I first create a new directory object on the server, using the
variable DATA_DUMP_DIR. I then use the export command to save the value of the
DATA_DUMP_DIR variable in the operating system environment. Once I do that, I can
just specify a dump file for my export job, without specifically stating the directory location.
SQL> create_directory dump_dir2 AS '/usr/apps/dumpfiles2';
$export DATA_PUMP_DIR dump_dir2
$expdp salapati/password TABLES=employees DUMPFILE=employees.dmp
Once you have made the DATA_DUMP_DIR variable part of your operating system
environment, you don’t need to specify the actual directory name (dump_dir2)
explicitly (by using the DIRECTORY parameter) when you invoke a Data Pump
export, as shown in the previous example. You merely need to specify the name, not
the location, for the DUMPFILE parameter.
Understanding the Order of Precedence for File Locations

Now that we have reviewed the various ways you can specify a directory object
for a Data Pump job, you may wonder how Oracle knows which location to use in
case there is a conflict. You can have a situation where you muight have specified a
DATA_DUMP_DIR environment variable, but you then also specify a DIRECTORY
parameter for the export job. Which directory will Oracle choose to use? Here’s the
order of precedence for directory objects:
1. Oracle will look to see if a directory name is used as part of a file parameter
(for example, the LOGFILE parameter). Remember that in these cases, the
directory object is separated from the filename by a colon (:).
2. Oracle’s second choice would be to use the directory objects assigned to the
DIRECTORY parameter during the export or import job. If you explicitly
specify the DIRECTORY parameter, you don’t need to use the directory
name as part of the file parameter.
3. Finally, Oracle looks to see if there is a default server-based directory object
named DATA_PUMP_DIR. You must have explicitly created this directory
object beforehand. Note that the default DATA_DUMP_DIR object is
available only to DBAs and other privileged users.
The directory object name resolution simply means that Oracle knows which
directory it should be using to read or write datafiles. However, you must have
already granted the database read/write privileges at the operating system level,
in order to enable the database to actually use the operating system files.
The Mechanics of a Data Pump Job

The Data Pump export and import utilities use several processes to perform their jobs,
including the key master and worker processes, as well as the shadow process and client
processes. Let’s look at these important Data Pump processes in detail.
The Master Process

The master process, or more accurately, the Master Control Process (MCP),
has a process name of DMnn. The full master process name is of the format
<instance>_DMnn_<pid>.
There is only one MCP for each job, and this process controls the execution
and sequencing of the entire Data Pump job. More specifically, the master process
performs the following tasks:
■ Creates jobs and controls them

■ Creates and manages the worker processes
■ Monitors the jobs and logs the progress
■ Maintains the job state and restart information in the master table
■ Manages the necessary files, including the dump file set
The master process uses a special table called the master table to log the location
of the various database objects in the export dump file. The master table is at the
heart of every Data Pump export and import job. The master process maintains the
job state and restart information in the master table. Oracle creates the master table
in the schema of the user who is running the Data Pump job at the beginning of every
export job. The master table contains various types of information pertaining to the
current job, such as the state of the objects in the export/import job, the location
of the objects in the dump file set, the parameters of the job, and the status of all
worker processes.
The master table has the same name as the export job, such as SYS_EXPORT_
SCHEMA_01.
The master process uses the master table only for the duration of the export. At
the very end of the export, as the last step in the export job, it writes the contents
of the master table to the export dump file and automatically deletes the master
table from the database. The deletion of the master table will occur automatically,
as long as the export completed successfully (or if you issue the KILL_JOB command).
However, if you use the STOP_JOB command to stop a job or the export fails for
some reason, the master table isn’t deleted from the database. (Data Pump job
commands are described in the “Data Pump Export Parameters” section later in
this chapter.) When you restart the export job, it will then use the same master
table. Since the master table tracks the status of all the objects, Data Pump can
easily tell which objects are in the middle of an export and which have been
successfully exported to the dump files.
The master process will re-create the master table saved by the export utility in the
dump file, in the schema of the user who is performing the import. This is the first step
in any Data Pump import job. (Note that you don’t need to create any tables, because
the import utility will automatically do this for you.) The Data Pump import utility
reads the contents of the master
table to verify the correct
sequence in which it should
import the various exported
database objects. As in the case The master table contains
of Data Pump export, if the all the necessary information to restart
import job finishes successfully, a stopped job. It is thus the key to Data
Oracle will automatically Pump’s job restart capability, whether the
delete the master table. job stoppage is planned or unplanned.
The Worker Process

The worker process is the process that actually performs the heavy-duty work of loading
and unloading data, and has the name DWnn (<instance>_DWnn_<pid>). The
MCP (DMnn) creates the worker process. The number of worker processes that the
master process will create depends on the degree of parallelism of the job. If you choose
the PARALLEL option for a load, Oracle splits up the worker processes into several
parallel execution coordinators.
The worker processes maintain the object rows of the master table. As the worker
processes export or import various objects, they update the master table with information
about the status of the various jobs: completed, pending, or failed.
Shadow Process
When a client logs in to an Oracle server, the database creates an Oracle foreground
process to service Data Pump API requests. This shadow process creates the job consisting
of the master table as well as the master process. Once a client detaches, the shadow
process automatically disappears.
Client Processes
The client processes call the Data Pump’s API. You perform export and import with the
two clients, expdp and impdp. Later in this chapter, you’ll learn about the various
parameters you can specify when you invoke these clients.
Using Data Pump Export and Import

The Data Pump export utility corresponds to the traditional export utility, and you
invoke it with the client expdp. The Data Pump import utility corresponds to the old
import utility, and you invoke it with the client impdp. In this section, you will learn
how to use both Data Pump utilities.
Data Pump export will load row data from database tables as well as object metadata
into dump file sets in a proprietary format that only the Data Pump import utility can
read. The dump file sets, which are operating system files, will contain data, metadata,
and control information. Dump file sets usually refer to a single file, such as the default
export dump file expdat.dmp.
Quite a few of the Data Pump import utility’s features are mirror images of the
Data Pump export utility. However, there are some features that are exclusive to
the new Data Pump Import utility.
In the following sections, we’ll look at Dump Pump export and import types,
modes, and parameters, as well as some examples.
Data Pump Export Types

By Data Pump export types, I simply mean the various ways in which you can run the
Data Pump utility. You can interface with the Data Pump export and import utilities
through the command line, using a parameter file, or interactively.
Using the Command Line

You can use the Data Pump export utility from the command line in a manner similar
to the traditional export utility. Here’s a simple example:
$ expdp system/manager directory=dpump_dir1 dumpfile=expdat1.dmp
As you can see, the command-line option would quickly get tiring if you were
doing anything but the simplest type of exports.
Using a Parameter File

Rather than specifying the export parameters on the command line, you can put them
in a parameter file. You then simply invoke the parameter file during the actual export.
When you use parameter files, you don’t need to retype the same parameters.
Using Data Pump Export and Import 15
For example, you could create a small file called myfile.txt, with the following
export parameters:
userid=system/manager
directory=dpump_dir1
dumpfile=system1.dmp
The file myfile.txt will be your export parameter file. Now, all you need to do in
order to export the system schema is invoke expdp with just the PARFILE
parameter, as follows:
$ expdp parfile=myfile.txt
You can use all command- parameter file. The only exception is
line export parameters in an export the parameter PARFILE itself!
Using Interactive Data Pump Export

Since this is a certification upgrade book, I assume you have experience with previous
versions of the export and import utilities. You also must be quite familiar with the
interactive feature of the export and import utilities. All you need to do during an
interactive export or import is merely type exp or imp at the command line, and
Oracle will prompt you for the rest of the information. Interactive Data Pump export
is quite different from the interactive mode of the older utilities. As you’ll see in the
following sections, Data Pump interactive mode isn’t meant to be used in the same
way as the exp/imp interactive mode.
In Data Pump export, you use the interactive method for one purpose only:
when you decide you need to change some export parameters midstream, while the
job is still running. The way to get into the interactive mode is by pressing the
CONTROL-C combination on your keyboard, which interrupts the running job and
lets you participate in the export job in an interactive fashion. When you press
CONTROL-C during an export job, the running job will pause, and you’ll see the
export prompt (Export>) displayed on your screen. At this point, you can deal
interactively with the export utility, with the help of a special set of interesting
commands, which I’ll explain later in this chapter, in the “Interactive Mode Export
Parameters” section. As you’ll see, you can also enter the interactive mode of operation
by using the ATTACH command.
In Data Pump, the import) prompt. You can enter the special
interactive mode means that the export interactive commands at this point. Note
or import job stops logging its progress that the export or import job keeps running
on the screen and displays the export (or throughout, without any interruption.
You can also perform Data Pump export and import operations easily through
the OEM Database Control interface. To use this feature, start the Database Control
and go to the Maintenance | Utilities page. On that page, you can see the various
choices for performing export and import of data.
You cannot start an interactive job using Data Pump export (or import).
You can use the interactive mode only to intervene during a running job.
Data Pump Export Modes

As in the case of the regular export utilities, you can perform Data Pump export in
several modes. The following four modes in which you can perform an export do not
differ from the traditional modes of operation using the older export utility:
■ Full export mode You use the FULL parameter when you want to export
the entire database in one export session. You need the EXPORT_FULL_
DATABASE role to use this mode.
■ Schema mode If you want to export a single user’s data and/or objects only,
you must use the SCHEMA parameter.
■ Tablespace mode By using the TABLESPACES parameter, you can export
all the tables in one or more tablespaces. If you use the TRANSPORT_
TABLESPACES parameter, you can export just the metadata of the objects
contained in one or more tablespaces. You may recall that you can export
tablespaces between databases by first exporting the metadata, copying the
files of the tablespace to the target server, and then importing the metadata
into the target database.
■ Table mode By using the TABLES parameter, you can export one or tables.
The TABLES parameter is identical to the TABLES parameter in previous
versions of Oracle.
Data Pump Export Parameters

Some of the Data Pump export commands are familiar to you from the traditional
export utility. Others are quite new. Here, I’ll briefly run through the set of Data
Pump export parameters, providing detailed explanations for only the new and
unfamiliar parameters. For this discussion, the parameters are grouped into the
following categories:
■ File- and directory-related parameters

■ Export mode-related parameters
■ Export filtering parameters
■ Estimation parameters
■ The network link parameter
■ Interactive mode export parameters
■ Job-related parameters
You can use all the following parameters at the command line or in parameter
files, except those listed in the “Interactive Mode Export Parameters” section.
File- and Directory-Related Parameters

You can specify several file- and directory-related parameters during a Data Pump
export job. Let’s look at these parameters in the following sections.
DIRECTORY The DIRECTORY parameter specifies the location of the

dump and other files. A detailed discussion of how you can use this parameter
was presented in the “Using Directory Objects” section earlier in this chapter.
DUMPFILE The DUMPFILE parameter provides the name of the dump file to
which the export dump should be written. The DUMPFILE parameter replaces the
FILE parameter in the old export utility. You can provide multiple dump filenames
in several ways:
■ You can create multiple dump files by specifying the %U substitution variable.
■ You can provide multiple files in a comma-separated list.
■ You can specify the DUMPFILE parameter multiple times for a single
export job.
If you specify the %U notation to indicate multiple dump files, the number
of files you can create is equal to the value of the PARALLEL parameter.
If you don’t specify the DUMPFILE parameter, Oracle will use the default name
expdat.dmp for the export dump file, just as it does when you use the traditional
export utility.
FILESIZE The FILESIZE parameter is purely optional, and it specifies the size
of the dump file. If you don’t specify this parameter, the dump file has no limits on
its size. If you use the FILESIZE parameter by specifying, say 10MB as the maximum
dump file size, your export will stop if your dump file reaches its size limit, and you
can restart it after correcting the problem.
PARFILE The PARFILE parameter stands for the same thing it did in
traditional export utility: the parameter file, wherein you can specify export
parameters in a file, instead of entering them directly from the command line.
LOGFILE and NOLOGFILE You can use the LOGFLE parameter to specify
a log file for your export jobs. Here’s what you need to remember regarding this
parameter:
If you just specify the parameter without the directory parameter, Oracle will
automatically create the log file in the location you specified for the DIRECTORY
parameter.
■ If you don’t specify this parameter, Oracle will create a log file named
export.log. A subsequent export job will overwrite this file, because Oracle
always names the default log file simply export.log.
■ If you specify the parameter NOLOGFILE, Oracle will not create its log file
(export.log). You’ll still see the progress of the export job on the screen, but
Oracle suppresses the writing of a separate log file for the job.
Export Mode-Related Parameters

The export mode-related parameters are the FULL, SCHEMAS, TABLES,
TABLESPACES, TRANSPORT_TABLESPACES, and TRANSPORT_FULL_CHECK
parameters. You’ve already seen all these parameters except the last one, in the “Data
Pump Export Modes” section. The TRANSPORT_FULL_CHECK parameter simply

checks to make sure that the tablespaces you are trying to transport meet all the
conditions to qualify for the job.
Export Filtering Parameters

There are several new parameters related to export filtering. Some of them are
substitutes for old export parameters, and others offer new functionality. Let’s look
at these important parameters in detail.
CONTENT By using the CONTENT parameter, you can filter what goes into the
export dump file. The CONTENT parameter can take three values:
■ ALL exports both table data and table and other object definitions
(metadata).
■ DATA_ONLY exports only table rows.
■ METADATA_ONLY exports only metadata.
$ expdp system/manager dumpfile=expdat1.dmp content=data_only
Note that the CONTENT=METADATA_ONLY option is equivalent to the rows=n

option in the original export utility. However, there is no equivalent to the CONTENT=
DATA_ONLY option in Data Pump.
EXCLUDE and INCLUDE The EXCLUDE and INCLUDE parameters are

two mutually exclusive parameters that you can use to filter various kinds of objects.
Remember how in the old export utility you used the CONSTRAINTS, INDEXES,
GRANTS, and INDEXES parameters to specify whether you wanted to export
those objects? Using the EXCLUDE and INCLUDE parameters, you now can
include or exclude many other kinds of objects besides the four objects you
could previously.
Simply put, the EXCLUDE parameter helps you omit specific database object types
from an export or import operation. The INCLUDE parameter, on the other hand,
enables you to include only a specific set of objects. Following is the format of the
EXCLUDE and INCLUDE parameters:
EXCLUDE=object_type[:name_clause]
INCLUDE=object_type[:name_clause]
For both the EXCLUDE and INCLUDE parameters, the name clause is optional.
As you know, several objects in a database—such as tables, indexes, packages,
and procedures—have names. Other objects, such as grants, don’t have names.
The name clause in an EXCLUDE or an INCLUDE parameter lets you apply a
SQL function to filter named objects.
Here’s a simple example that excludes all tables that start with EMP:
EXCLUDE=TABLE:"LIKE 'EMP%'"
In this example, "LIKE 'EMP%'" is the name clause.

The name clause in an EXCLUDE or INCLUDE parameter is optional. It’s purely
a filtering device, allowing you finer selectivity within an object type (index, table,
and so on). If you leave out the name clause component, all objects of the specified
type will be excluded or included.
In the following example, Oracle excludes all indexes from the export job, since
there is no name clause to filter out only some of the indexes.
EXCLUDE=INDEX
You can also use the EXCLUDE parameter to exclude an entire schema, as shown
in the following example.
EXCLUDE=SCHEMA:"='HR'"
The INCLUDE parameter is the precise opposite of the EXCLUDE parameter: it

forces the inclusion of only a set of specified objects in an export. As in the case of
the EXCLUDE parameter, you can use a name clause to qualify exactly which objects
you want to export. Thus, you have the ability to selectively choose objects at a fine-
grained level.
The following three examples show how you can use the name clause to limit the
selection of objects.
INCLUDE=TABLE:"IN ('EMPLOYEES', 'DEPARTMENTS')"
INCLUDE=PROCEDURE
INCLUDE=INDEX:"LIKE 'EMP%'"
The first example is telling the Data Pump job to only include two tables: employees
and departments. In the second example, the INCLUDE parameter specifies that
only procedures should be
included in this export job.
The third example shows
how you can specify that
The EXCLUDE and
only those indexes that
INCLUDE parameters are mutually
start with EMP should be
exclusive. You can use one or the other,
part of the export job.
not both simultaneuously in the same job.
QUERY The QUERY parameter stands for the same thing as it does in traditional
export: it lets you selectively export table row data with the help of a SQL statement.
However, the parameter is enhanced for Oracle Database 10g by permitting you to
qualify the SQL statement with a table name, so that it applies only to a particular
table. Here’s an example:
QUERY=OE.ORDERS: "WHERE order_id > 100000"
In this example, only those rows in the orders table where the order_id is greater than
100000 are exported.
Estimation Parameters
Two interesting parameters enable you to estimate how much physical space your
export job will consume. Let’s look at both these parameters in detail.
ESTIMATE The ESTIMATE parameter will tell you how much space your new
export job is going to consume. The space estimate is always in terms of bytes. By
default, Oracle will always estimate the space requirements in terms of blocks. It
simply takes your database block size and multiplies it with the amount of blocks all
the objects together will need. Here is an example of what you’ll see in your log file
(and on the screen):
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 654 KB
Since the space estimation in terms of blocks is the default behavior, you don’t
need to specify the ESTIMATE parameter during the export. However, if you have
analyzed all your tables recently, you can ask the Data Pump export utility to
estimate the space requirements by using the statistics the database has already
calculated for each of the tables. In order to tell the database to use the database
statistics (rather than use the default BLOCKS method), you need to specify the
ESTIMATE parameter in the following manner:
ESTIMATE=statistics
Here’s what you’ll see in your log file when you use the ESTIMATE=statistics
parameter:
Estimate in progress using STATISTICS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. estimated "SYSTEM"."HELP" 35.32 KB
Total estimation using STATISTICS method: 65.72 KB
ESTIMATE_ONLY While the ESTIMATE parameter is operative only

during an actual export job, you can use the ESTIMATE_ONLY parameter
without starting an actual export job. Here’s an example:
C:\>expdp system/manager estimate_only=y
Export: Release 10.1.0.2.0 - Production on Saturday, 17 April, 2004 14:30
…
Total estimation using BLOCKS method: 288 KB
Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at 14:30
Although the log indicates that the export job “completed successfully,” all the
job really did was to estimate the space that you will need for the export job.
The Network Link Parameter

The expdp utility provides you with a way to initiate a network export. Using the
NETWORK_LINK parameter, you can initiate an export job from your server and have
Data Pump export data from a remote database to dump files located on the instance
from which you initiate the Data Pump export job.
Here’s an example that shows you how to perform a network export:
expdp hr/hr DIRECTORY=dpump_dir1 NETWORK_LINK=finance@prod1
DUMPFILE=network_export.dmp LOGFILE=network_export.log
In the example, the NETWORK_LINK parameter must have a valid database link as its
value. This means that you must have created the database link ahead of time. You are
exporting data from the finance database on the prod1 server.
You can’t use Data Pump in the normal way to export data from a read-only
database. This is because Data Pump can’t create the necessary master table
or create external tables on a read-only tablespace. Using the network mode,
however, you can export data from a read-only database on server A to dump
files on server B, where Data Pump is running.
Interactive Mode Export Parameters

As I mentioned earlier in this chapter, the interactive mode of Data Pump is quite
different from the interactive export and import mode that you know. Traditionally, the
interactive mode gave you the chance to enter a limited set of export/import parameters
at the command line in response to the queries made by the export or import utility.
You use the interactive mode in the new Data Pump technology only to intervene in
the middle of a running job, to either suspend the job or modify some aspects of it.
You can enter the interactive mode of Data Pump export in either of two ways:
■ You can use the CONTROL-C keyboard combination during a Data Pump
export job, if you want to enter the interactive mode from the same session
where you are running the Data Pump job.
■ You can either use a separate session or even a separate server to “attach”
yourself to a running session by using—what else?—the ATTACH command.
(You can also attach to a stopped job.) When you successfully attach yourself
to a job, you’ll be able to use specific export parameters in an interactive mode.
In the Data Pump export opening another session and “attaching”

(and import), the only way to get into yourself to that session. You cannot start
an interactive mode of operation is by an interactive Data Pump session from the
using the CONTROL-C sequence or by command line.
Let’s examine when you might use the interactive mode in Data Pump export.
Suppose that you started a job in the evening at work and left for home. At midnight,
you check the status of the job and find that it’s barely moving. You can easily start
another session, and then “connect” to the running job and monitor it by simply
using the ATTACH command. When you do this, the running job does not pause.
Instead, it opens an interactive window into the running session, so you can change
some parameters to hasten the crawling export job by running one of a special set
of interactive Data Pump export commands. Here’s an example of the usage of the
ATTACH parameter:
C:\>expdp salapati/sammyy1 attach=SALAPATI.SYS_EXPORT_SCHEMA_01
Export: Release 10.1.0.2.0 - Production on Saturday, 17 April, 2004 11:47
…
State: EXECUTING
…
Export>
You may attach multiple clients to a single job.
Once you attach yourself to a running job by using the ATTACH command or
by using the CONTROL-C sequence on the server where the job is actually running,
you get the interactive export prompt (Export>), indicating that Data Pump is
awaiting your interactive commands. From the interactive prompt, you can use
several interesting parameters to influence the progress of the currently executing
Data Pump job. Here are some examples of interactive commands:
Export> parallel=4
Export> kill_job
Export> stop_job
Export> continue_client
I’ll explain these and other interactive

You must be a DBA, or Data Pump parameters in the following
must have EXP_FULL_DATABASE or IMP_ sections, grouped in the categories of
FULL_DATABASE roles, in order to attach client-related parameters, job-related
and control Data Pump jobs of other users. parameters, and other parameters.
Client-Related Interactive Parameters The CONTINUE_CLIENT

parameter will take you out of the interactive mode and resume the running
export job. Your client connection will still be intact, and you’ll continue to
see the export messages on your screen. However, the EXIT_CLIENT parameter
will stop the interactive session, as well as terminate the client session. In both of
these cases, the actual Data Pump export job will continue to run unhindered.
Job-Related Interactive Parameters You can use several job-related parameters

from any interactive session you open with an export session using the ATTACH
command. You can use the STOP_JOB command to stop the export job in an orderly
fashion. To stop it at once, use the STOP_JOB=immediate command. You can
choose to resume any export jobs you’ve stopped in this manner, with the help of
the START_JOB parameter.
If you decide that you don’t really want to continue the job you’ve just attached
to, you can terminate it by using the KILL_JOB parameter. Unlike the EXIT_
CLIENT parameter, the KILL_JOB parameter terminates the client as well as the
export job itself for good.
To summarize, the job-related interactive parameters work as follows:
■ STOP_JOB stops running Data Pump jobs.

■ START_JOB resumes stopped jobs.
■ KILL_JOB kills both the client and the Data Pump job.
You can restart any job or due to a system crash, as long as you
that is stopped, whether it’s stopped have access to the master table and an
because you issued a STOP_JOB command uncorrupted dump file set.
Other Interactive Parameters From the interactive prompt, you can use
the ADD_FILE parameter to add a dump file to your job. You can also use the HELP
and STATUS parameters interactively, and both of these parameters function the
same way as their command-line counterparts.
Job-Related Parameters
Several Data Pump export parameters can be classified as job-related parameters.
I’ll briefly discuss the important ones here.
JOBNAME You can use the JOBNAME parameter to provide your own job
name for a given Data Pump export/import job (for example, JOBNAME=myjob1).
The JOBNAME parameter is purely optional, however. If you don’t use it, Data
Pump will generate a unique system name, of the format <USER>_<OPERATION>_
<MODE>_%N. For example, if the user SYSTEM is performing an export of the
database (FULL mode), the automatically generated job name will be SYSTEM_
EXPORT_FULL_01. In this job name, SYSTEM is the user that is performing the
Data Pump job. EXPORT tells you it’s an export, not an import job. FULL indicates
that this is full database export. The last part of the job name is a number, indicating
the sequence number of the job. This was my first job in a new database, so my job
number happens to end with 01.
Remember that Oracle gives the master table, which holds critical information
about your export job, the same name as the name of the job.
STATUS The STATUS parameter is useful while you’re running long jobs, as it
provides you with an updated status at intervals that you can specify. The parameter
takes integer values that stand for seconds. For example, an anxious DBA (like me)
might want to get an update every minute regarding an ongoing Data Pump export
job. Here’s what you need to do to get your reassuring minutely updates:
$ expdp system/manager status=60 …
…
Worker 1 Status:
State: EXECUTING
Object Schema: SYSTEM
Object Name: SYS_EXPORT_SCHEMA_01
Object Type: SCHEMA_EXPORT/TABLE/TABLE_DATA
Completed Objects: 1
Total Objects: 65
. . exported "SYSTEM"."REPCAT$_SITES_NEW"
Job: SYS_EXPORT_SCHEMA_01
Operation: EXPORT
Mode: SCHEMA
State: EXECUTING
Bytes Processed: 69,312
Percent Done: 99
Current Parallelism: 1
Job Error Count: 0
Dump File: C:\ORACLE\PRODUCT\10.1.0\ADMIN\EXPORT\EXPDAT6.DMP
bytes written: 1,748,992
…
The STATUS parameter shows the overall percentage of the job that is
completed, the status of the worker processes, and the status of the current
data objects being processed.
PARALLEL PARALLEL is the mighty parameter that lets you specify more
than a single active execution thread for your export job. Note that the Data Pump
PARALLEL parameter has nothing to do with the other Oracle parallel features,
but they can work together. The default value of the PARALLEL parameter is 1,
meaning a single thread export operation writing to a single dump file. If you specify
anything more than 1 as the value for the PARALLEL parameter, you also should
remember to specify the same number of dump files, so the multiple execution threads
can simultaneously write to the multiple dump files. Here’s an example that shows
how you can set the level of parallelism to 3, forcing the export job to write in
parallel to three dump files:
expdp system/manager DIRECTORY=dpump_dir1 DUMPFILE=par_exp%u.dmp PARALLEL=3
If you specify the PARALLEL parameter, make sure you allocate the same
number of dump files as the degree of parallelism. The higher the degree
of parallelism, the higher will be the memory, CPU, and network bandwith
usage as well.
In the previous example, the DUMPFILE parameter uses the substittion varable %u
to indicate that multiple files should be generated, of the format par_expNN.dmp,
where NN is a two-character integer starting with 01. Since the PARALLEL parameter
is set to 3, the substitution variable will create three files with the following names:
par_exp01.dmp, par_exp02.dmp, and par_exp03.dmp.
Note that you don’t need to use the %u substition variable to generate multiple
dump files when you choose a value of greater than 1 for the PARALLEL parameter.
You could simply use a comma-separated list of values, as follows:
expdp system/manager DIRECTORY=dpump_dir1 PARALLEL 3
DUMPFILE=(par_exp01.dmp,par_exp02.dmp,par_exp03.dmp)
If you don’t have sufficient I/O bandwidth, you may actually experience a
degradation in Data Pump performance with the PARALLEL parameter.
Data Pump Export Examples

Let’s look at some simple Data Pump export job specifications that demonstrate some
of the new concepts you’ve learned in this chapter. The next example creates an
export dump file of just two tables: employees and jobs.
expdp hr/hr TABLES=employees,jobs DUMPFILE=dpump_dir1:table.dmp NOLOGFILE=y
The following example shows how to use a parameter file, as well as how to
use the CONTENT and EXCLUDE parameters. The CONTENT=DATA_ONLY
specification means you are exporting just rows of data and excluding all object
definitions (metadata). The EXCLUDE parameter requries that the countries,
locations, and regions tables be omitted from the export. The QUERY parameter
stipulates that all the data in the employees table, except that belonging to
location_id 20, be exported. The parameter file, exp.par, has the following
information:
DIRECTORY=dpump_dir1
DUMPFILE=dataonly.dmp
CONTENT=DATA_ONLY
EXCLUDE=TABLE:"IN ('COUNTRIES', 'LOCATIONS', 'REGIONS')"
QUERY=employees:"WHERE department_id !=20 ORDER BY employee_id"
You can then issue the following command to execute the exp.par parameter file:
$ expdp hr/hr PARFILE=exp.par
The following example illustrates a schema mode export. You don’t see any
mention of the SCHEMA parameter; that’s because Data Pump will export a schema
(of the exporting user) by default.
$ expdp hr/hr DUMPFILE=dpump_dir1:expschema.dmp
LOGFILE=dpump_dir1:expschema.log
By default, Data Pump export will run the export in the schema mode.
Here’s an interesting Data Pump export example, showing how to use the
PARALLEL, FILESIZE, and JOB_NAME parameters. It also illustrates the use
of the DUMPFILE parameter when there are multiple dump files.
$ expdp hr/hr FULL=y DUMPFILE=dpump_dir1:full1%U.dmp, dpump_dir2:full2%U.dmp
FILESIZE=2G PARALLEL=3 LOGFILE=dpump_dir1:expfull.log JOB_NAME=expfull
Now that you’ve seen how the Data Pump export utility works, you’re ready to
look at the Data Pump import features.
Data Pump Import Types and Modes

As in the case of exporting data, you can perform a Data Pump import job from the
command line or use a parameter file. Interactive access to the import utility is
available, but it is different from what you are used to when working with the
traditional export/import utilities. The interactive framework is analogous to the

interactive access to the Data Pump export utility, as you’ll see shortly.
You can use Data Pump import in the same modes as Data Pump export:
table, schema, tablespace, and full modes. In addition, you can also employ the
TRANSPORTABLE_TABLESPACES parameter to import the metadata necessary
for implementing the transportable tablespaces feature.
You must have the IMPORT_FULL_DATABASE role in order to perform one of
the following:
■ Full database import

■ Import of a schema You’ll need the IMPORT_
other than your own FULL_DATABASE role to perform an
■ Import of a table that import if the dump file for the import
you don’t own was created using the EXPORT_FULL_
DATABASE role.
Data Pump Import Parameters

As in the case of the Data Pump export utility, you control a Data Pump import
job with the help of several parameters when you invoke the impdp utility. For
this discussion, the import parameters are grouped as follows:
■ File- and directory-related parameters

■ Filtering parameters
■ Job-related parameters
■ Import mode-related parameters
■ Remapping parameters
■ The network link parameter
■ The transform parameter
■ The flashback time parameter
File- and Directory-Related Parameters

The Data Pump import utility uses the PARFILE, DIRECTORY, DUMPFILE,
LOGFILE, and NOLOGFILE commands in the same way as the Data Pump export
utility. However, SQLFILE is a file-related parameter unique to the import utility.
The SQLFILE parameter is similar to the old import utility’s INDEXFILE
parameter. When you perform a Data Pump import, you may sometimes wish to
extract the DDL from the export dump file. The SQLFILE parameter enables
you to do this easily, as shown in the following example.
$ impdp salapati/sammyy1 DIRECTORY=dpump_dir1 DUMPFILE=finance.dmp
SQLFILE=dpump_dir2:finance.sql
In this example, the SQLFILE parameter instructs the Data Pump import job to write
the DDL to the finance.sql file, located in the directory dpump_dir2. Of course, you
must have created dpump_dir2 prior to this, using the CREATE DIRECTORY AS
command. The DIRECTORY=dpump_dir1 parameter value tells Data Pump import
where to find the dump file finance.dmp. This example also shows how you can use
multiple directories in a single Data Pump job.
It’s important to remember that the SQLFILE parameter just extracts the SQL
DDL to the specified file—no actual data import whatsoever takes place. By using
this parameter, you can extract a SQL script with all the DDL from your export
dump file. The DDL in SQLFILE lets you peek at what the import job will execute.
The other import file-related parameter is the new REUSE_DATAFILES
parameter. This parameter tells Data Pump whether it should use existing datafiles
for creating tablespaces during an import. If you specify REUSE_DATAFILES=y,
the import utility will write over your existing datafiles.
Filtering Parameters
You use the CONTENT parameter, as in the case of a Data Pump export, to determine
whether you’ll load just rows (CONTENT=DATA_ONLY), rows and metadata
(CONTENT=ALL), or just metadata (CONTENT=METADATA_ONLY).
The EXCLUDE and INCLUDE parameters have the same meaning as in an export,
and they are mutually exclusive. If you use the CONTENT=DATA_ONLY option, you
cannot use either the EXCLUDE or INCLUDE parameter during an import.
You can use the QUERY parameter during import as well, in order to filter data
during an import. In the older export/import utilities, you could use the QUERY
parameter only during an export. You can use the QUERY parameter to specify an
entire schema or a single table. Note that if you use the QUERY parameter during
import, Data Pump will use only the external table data method, rather than the
direct-path method, to access the data.
What will Data Pump import do if there is a table creation script in the export
dump file, but the table already exists in the target database? You can use the
TABLE_EXISTS_ACTION parameter to tell Data Pump what to do when a table
already exists. You can provide four different values to the TABLE_EXISTS_
ACTION parameter:
■ With SKIP (the default), Data Pump will skip a table if it exists.
■ The APPEND value appends rows to the table.
■ The TRUNCATE value truncates the table and reloads the data from the
export dump file.
■ The REPLACE value drops the table if it exists, re-creates, and reloads it.
Job-Related Parameters
The JOB_NAME, STATUS, and PARALLEL parameters carry identical meanings
as their Data Pump export counterparts. Note that if you have multiple dump files,
you should specify them either explicitly or by using the %u notation, as shown in
the Data Pump import section.
Import Mode-Related Parameters

You can perform a Data Pump import in various modes, using the TABLE, SCHEMAS,
TABLESPACES, and FULL parameters, just as in the case of the Data Pump export
utility. You can use the TRANSPORTABLE_TABLESPACES parameter when you
wish to transport tablespaces between databases.
Remapping Parameters
The remapping parameters are brand-new features in the Oracle Database 10g Data
Pump import utility, and they clearly mark the superiority of this utility over the
traditional import utility. Let’s briefly discuss each of these three parameters: REMAP_
SCHEMA, REMAP_DATAFILE, and REMAP_TABLESPACE.
REMAP_SCHEMA Using the REMAP_SCHEMA parameter, you can move

objects from one schema to another. You need to specify this parameter in the
following manner:
$ impdp system/manager dumpfile=newdump.dmp REMAP_SCHEMA=hr:oe
In this example, HR is the source schema, and Data Pump import will import all of
user HR’s objects into the target schema OE. The import utility can even create the
OE schema, if it doesn’t already exist in the target database. Of course, if you want to
just import one or more tables from the HR schema and import them into the OE
schema, you can do that as well, by using the TABLES parameter.
The REMAP_SCHEMA parameter provides the same functionality as the

FROMUSER/TOUSER capability in the old export and import utilities.
REMAP_DATAFILE When you are moving databases between two different

platforms, each with a separate filenaming convention, the REMAP_DATAFILE
parameter comes in handy to change file system names. The following is an example
that shows how you can change the file system from the old Windows platform to
the new UNIX platform. Whenever there is any reference to the Windows file system
in the export dump file, the import utility will automatically remap the filename to
the UNIX file system.
$ impdp hr/hr FULL=y DIRECTORY=dpump_dir1 DUMPFILE=db_full.dmp
REMAP_DATAFILE='DB1$:[HRDATA.PAYROLL]tbs6.f':'/db1/hrdata/payroll/tbs6.f'
REMAP_TABLESPACE Sometimes, you may want the tablespace into which

you are importing data to be different from the tablespace in the source database.
The REMAP_TABLESPACE parameter enables you to move objects from one
tablespace into a different tablespace during an import, as shown in the following
example. Here, Data Pump import is transferring all objects from the tablespace
example_tbs to the tablespace new_tbs.
$ impdp hr/hr REMAP_TABLESPACE='example_tbs':'new_tbs'
DIRECTORY=dpump_dir1
PARALLEL=2 JOB_NAME=cf1n02 DUMPFILE=employees.dmp NOLOGFILE=Y
The Network Link Parameter

Using the new NETWORK_LINK parameter, you can perform an import across the
network, without using dump files. The NETWORK_LINK parameter enables import to
connect directly to the source database and transfer data to the target database. Here’s
an example:
$ impdp hr/hr TABLES=employees DIRECTORY=dpump_dir1
NETWORK_LINK=finance@prod1 EXCLUDE=CONSTRAINT
In this example, finance@prod1 is the network link. It is a valid database link, created
by you beforehand using the CREATE DATABASE LINK command. Thus, the database
shown in the database link is your source for the import job. Data Pump will import
the table employees from the remote database finance to your instance where you
run the Data Pump import job. In a network import, the Metadata API executes on
the remote instance, and extracts object definitions and re-creates necessary objects
in your local instance. It then fetches data from the remote database tables and loads
them in your local instance, using the INSERT AS SELECT command, as follows:
insert into employees(emp_name,emp_id) … select (emp_name,emp_id) from
finance@remote_service_name
Note that a Data Pump network import doesn’t involve a dump file, as Data Pump
will import the table from the source to the target database directly.
EXERCISE 2-1
Using the NETWORK_LINK Parameter

Using the following information as your guidelines, perform an an import using the
NETWORK_LINK parameter.
SQL> create database link L1
connect to system identified by oracle
using 'db_name';
SQL> create directory d1 as 'e:\tmp';
E:\> impdp userid=system/oracle tables=hr.regions network_link=L1
remap_schema=HR:OE directory=D1
The TRANSFORM Parameter

Suppose you are importing a table from a different schema or even a different database.
Let’s say you want to make sure that you don’t also import the objects’ storage attrributes
during the import—you just want to bring in the data that the table contains. What
can you do? The new TRANSFORM parameter lets you specify that your Data Pump
import job should not import certain storage and other attributes. Using the TRANSFORM
parameter, you can exclude the STORAGE and TABLESPACE clauses, or just the
storage clause, from a table or an index.
During a Data Pump (or traditional) import, Oracle creates objects using the DDL
that it finds in the export dump files. The TRANSFORM parameter instructs the Data
Pump import job to modify the DDL that creates the objects during the import job.
The TRANSFORM parameter has the following syntax:

TRANSFORM = transform_name:value[:object_type]
Here’s an example to help you understand the TRANSFORM parameter:

impdp hr/hr TABLES=hr.employees \
DIRECTORY=dpump_dir1 DUMPFILE=hr_emp.dmp \
TRANSFORM=SEGMENT_ATTRIBUTES:n:table
The TRANSFORM parameter syntax elements correspond to the following items

in the example:
■ Transform name You can modify two basic types of an object’s

characteristics using TRANSFORM: segment attributes and storage. Segment
attributes include physical atttributes, storage attributes, tablespaces, and
logging. The transform name represents exactly which of these two object
attributes you want to modify during the import job. In the example, the
TRANSFORM=SEGMENT_ATTRIBUTES specification indicates that you
want the import job to modify all the segment (the employees table in the
HR schema) attributes.
■ Value The value of the TRANSFORM parameter can be Y (yes) or N (no).
By default, the value is set to Y. This means that, by default, Data Pump
imports an object’s segment attributes and storage features. If you assign a
value of N as your choice, you specify not to import the original segment
attributes and/or the storage attributes.
■ Object type The object type specifies which types of objects should be
transformed. Your choices are limited to TABLE and INDEX. You may omit
this part of the TRANSFORM parameter specification, in which case Data
Pump import will transform both tables and indexes.
The Flashback Time Parameter

The FLASHBACK_TIME parameter enables you to import data consistent as of the
flashback time you specify in your import job. For example, look at the following
import statement:
$ impdp system/manager flashback_time=2004-06-01 07:00
The import job will ensure that the data is consistent as of the time you specified.
Note that the FLASHBACK_TIME parameter does the same thing as the old
CONSISTENT parameter in the traditional import utility.
Monitoring a Data Pump Job 35
Monitoring a Data Pump Job

There are two new views—DBA_DATA PUMP_JOBS and DBA_DATA PUMP_
SESSIONS—which are crucial for monitoring Data Pump jobs. In addition, you
can also use the V$SESSION_ LONGOPS view and the old standby V$SESSION,
to obtain session information. In most cases, you can join two or more of these
views to gain the necessary information about job progress. Let’s look at some
of the important data dictionary views that help you manage Data Pump jobs.
Viewing Data Pump Jobs

The DBA_DATA PUMP_JOBS view shows summary information of all currently
running Data Pump jobs. It has the following structure:
SQL> desc dba_data pump_jobs
Name Null? Type
---------------------------------------------
OWNER_NAME VARCHAR2(30)
JOB_NAME VARCHAR2(30)
OPERATION VARCHAR2(30)
JOB_MODE VARCHAR2(30)
STATE VARCHAR2(30)
DEGREE NUMBER
ATTACHED_SESSIONS NUMBER
Since the dynamic DBA_DATA PUMP_JOBS view shows only the active jobs, you
can easily find the JOB_NAME value for any job that is running right now. As you
know, you’ll need to know the job name for a job if you want to attach to a running
job in midstream.
Because the name of the master table is the same as the JOB_NAME value, you
can thus determine the name of the master table through this view.
The JOB_MODE column can take the values FULL, TABLE, SCHEMA, or
TABLESPACE, reflecting the mode of the curently executing export or the import job.
The STATE column can take the values UNDEFINED, DEFINING, EXECUTING,
and NOT RUNNING, depending on which stage of the export or import you execute
your query. The Data Pump job enters the NOT RUNNING state immediately before
it completes the import or export. Of course, when there aren’t any active jobs running,
the view DBA_DATA PUMP_JOBS returns no rows whatsoever.
Viewing Data Pump Sessions

The DBA_DATA PUMP_SESSIONS view identifies the user sessions currently
attached to a Data Pump export or import job. You can join the SADDR column
in this view with the SADDR column in the V$SESSION view to gain useful
information about user sessions that are currently attached to a job. The following
query shows this:
SQL> select sid, serial#
from v$session s, dba_data pump_sessions d
where s.saddr = d.saddr;
Viewing Data Pump Job Progress

The V$SESSION_LONGOPS dynamic performance view is not new to Oracle Database
10g. In Oracle 9i, you could use use this view to monitor long-running sessions.
In the V$SESSION_LONGOPS view, you can use the columns TOTALWORK,
SOFAR, UNITS, and OPNAME to monitor the progress of an export/import job.
This is what these four key columns represent:
■ TOTALWORK shows the total estimated number of megabytes in the job.
■ SOFAR shows the megabytes transferred thus far in the job,
■ UNITS stands for megabytes.
■ OPNAME shows the Data Pump job name.
Here’s a typical SQL script that you can run to show how much longer it will take
for your Data Pump job to finish:
SQL> select sid, serial#, sofar, totalwork
from v$session_longops
where opname = 'MY_EXPORTJOB1'
Creating External Tables for Data Population

External tables are tables that do not reside in the database itself, and they can have
any format defined by an access driver. An external table is merely a representation of
external data in a file—data that’s never actually loaded into an Oracle table. In some
Creating External Tables for Data Population 37
ways, external tables are like a view, but the data physically exists in a flat file outside
the database.
External tables aren’t a new feature of Oracle Database 10g. Oracle9i first introduced
the concept of external tables. However, in Oracle9i, you could only read from
external tables. Now, in Oracle Database 10g, you can also to write to external tables.
We’ll look at the following areas regarding external table creation in the following
sections:
■ An overview of external table population features

■ The process for creating external tables
■ How to load and unload data
■ Parallel population of external tables
Features of External Table Population Operations

In reality, an external table isn’t really a table, but rather an interface to an external
datafile. However, you may query this external table like a virtual table, just as you would
query any regular Oracle table, which makes it a very powerful tool for data warehouse
extraction, transformation, and loading (ETL) activities. You can query external tables
or join them with regular tables, without ever loading the external data into your
database. In addition, you may create other regular tables or views from the external
tables, so this feature comes in very handy during the population of data warehouses.
You can’t perform all the normal table Data Manipulation Language (DML)
actions on an external table. You can query the external table data, but you can’t
perform an update, delete, or an insert on an external table. You also can’t build
an index on external tables.
Prior to Oracle Database 10g, you could use external tables to load data into
a database from external flat files. Now, for the first time, you can unload data
from an Oracle database into an external table. That is, whereas you could only
read from an external table before, now you can write to an external table as
well. The technique simply
uses the CREATE TABLE AS
SELECT (CTAS) command to
populate external tables with The same limitations
data that actually resides in in earlier versions—inability to create
operating system text files and indexes and perform DML on the external
not in regular datafiles. tables—still apply to all external tables.
When you create an external table, you can use the TYPE attribute to select
between two types of external tables: the ORACLE_LOADER type and the
ORACLE_DATAPUMP type. Each of these external tables comes with its own
access driver. In Oracle9i, you used the ORACLE_LOADER access driver to create
external tables; however, the ORACLE_LOADER access driver can load data only
into an external table; that is, it can extract data from external flat files to load an
Oracle (external) table. The ORACLE_LOADER access driver is the default access
driver in Oracle Database 10g.
The ORACLE_DATAPUMP access driver is new to Oracle Database 10g. The
ORACLE_DATA PUMP access driver can load as
well extract data; that is, it can both load an
external table from a flat file and extract data
If you want to create from a regular database table to an external flat
indexes on a staging table, you are better file. This external flat file data is written in a
off using the SQL*Loader utility to load proprietary format, which only the ORACLE_
data into the table. You cannot index an DATA PUMP access driver can read. You can then
external table! use this newly created file to create an external
table in the same database or a different database.
Here’s a summary of the main features of external table population operations:
■ You can use the ORACLE_LOADER or ORACLE_DATA PUMP access drivers
to perform data loads. You can use only the new ORACLE_DATA PUMP
access driver for unloading data (populating external tables).
■ No DML or indexes are possible for external tables.
■ You can use the datafiles created for an external table in the same database
or a different database.
The new Oracle unload. The older ORACLE_LOADER access

Database10g ORACLE_DATA PUMP access driver can only load an external table using
driver can perform a data load as well as an data in operating system text files.
Creating External Tables

In this section, I’ll briefly describe the mechanics of creating an external table. This
basic background will help you to understand the enhancements in this area in Oracle
Database 10g. The three main steps—create the datafile, create the directory object,
and then create the external table—are demonstrated in the following sections.
Create the Datafile

Create a flat file with some data that you’ll load into your external table. Let’s call this
datafile dept.dmp. Later, you’ll be defining this flat file as an external table. The file
will always remain in the operating system directories, and you may edit it as you wish.
Here’s the datafile structure:
10000001,nina,FINANCE,04-APR-2000
10000002,nicholas,FINANCE,04-APR-2000
10000007,shannon,HR,02-FEB-1990
10000008,valerie,HR,01-JUN-1998
Create the Directory Object

Create a directory object to hold the external datafiles, as shown here:
SQL> CREATE OR REPLACE DIRECTORY employee_data AS 'C:\employee_data';
Directory created.
Create the External Table

Use the CREATE TABLE … ORGANIZATION EXTERNAL statement to create your
external table, as follows:
SQL> CREATE TABLE employee_ext
(
empid NUMBER(8),
emp_name VARCHAR2(30),
dept_name VARCHAR2(20),
hire_date date
)
ORGANIZATION EXTERNAL
(
TYPE ORACLE_LOADER
DEFAULT DIRECTORY employee_data
ACCESS PARAMETERS
(
RECORDS DELIMITED BY NEWLINE
FIELDS TERMINATED BY ','
MISSING FIELD VALUES ARE NULL
)
LOCATION ('emp.dat')
)
REJECT LIMIT UNLIMITED;
Table created.
SQL>
There are several important components of this CREATE TABLE statement that
you need to be aware of:
■ ORGANIZATION EXTERNAL Indicates to Oracle that the table you are

creating is an external table, not a regular database table.
■ TYPE Specifies the type of access loader: ORACLE_LOADER or ORACLE_
DATA PUMP. The default type is ORACLE_LOADER. However, only the
ORACLE_DATA PUMP access loader can perform a data unload. Both access
drivers can perform a data load. The records delimited by newline
clause indicates that each line in the datafile is a new row in the external
table. The fields terminated by ',' clause tells Oracle that each
column is seperated by a comma in the datafile. If there are missing values,
the clause missing field values are null instructs Oracle to treat
them as null.
■ DEFAULT DIRECTORY Allows you to specify a file system as the directory,
by first using the CREATE DEFAULT DIRECTORY AS statement.
■ ACCESS PARAMETERS Describes the structure of the external data. The
access parameters ensure that the data from the data source is processed
correctly to match the definition of the external table.
■ LOCATION Refers to the actual dump file location. You must specify a
dump filename at least. In addition, you may specify an optional directory
name as well. If you furnish just a dump filename and no directory name,
Oracle will automatically place the dump file in the default dump directory.
Note that both of the following location specifications are valid:
LOCATION(‘dept_xt.dmp')
LOCATION(dept_xt_dir.dep_xt.dmp)
■ REJECT LIMIT UNLIMITED Specifies that there is no limit on the

number of errors that occur during the querying of the external tables.
Loading and Unloading Data

The terms loading and unloading in the context of external tables can be confusing, so
let’s pause and make sure you undertand these terms without any ambiguity. When
you deal with external tables, this is what these terms mean:
■ Loading data means reading data from an external table and loading it into
a regular Oracle table. Oracle first reads the data stream from the files you
specify. Oracle will then convert the data from its external representation to
an Oracle internal datatype and pass it along to the external table interface.
■ Unloading data means reading data from a regular Oracle table and putting it
into an external table. You couldn’t do this in the Oracle9i database.
As I explained earlier, only the ORACLE_DATA PUMP access driver can perform an
external table population (unloading data). Why is the new functionality (unloading
data into external tables) important? Following are some of the benefits of this new
Oracle Database 10g feature:
■ Loading table data into flat files means that you can now store data or move
it to different databases easily. If you want to move large volumes of data
across platforms, external tables provide a means of doing so, since the
external files are platform-independent.
■ During the population of data warehouses, there are many situations where
you need to perform complex ETL jobs. You can use SQL transformations to
manipulate the data in the external tables before reloading them into the
same or other databases.
■ Once you create an external table and populate it using the CTAS
statement, you can move the text files containing data and create new
external tables in the same or a different database.
Note that when you talk about to writing to external tables, you are really referring
to writing to an external file. You use a SELECT statement to extract table data to
this operating sytem file. The ORACLE_DATA PUMP access driver writes data to this
file in a binary Oracle-internal Data Pump format. You can then use this file to load
another external table on a different database.
The following example shows how you can create an external table and populate it
with data from an external flat file. The only difference between this example and the
preceding external table creation statement is that it uses the ORACLE_DATAPUMP
access driver rather than the ORACLE_LOADER driver.
SQL> CREATE TABLE inventories_xt2
2 (
3 product_id NUMBER(6),
4 warehouse_id NUMBER(3),
5 quantity_on_hand NUMBER(8)
6 )
7 ORGANIZATION EXTERNAL
8 (
9 TYPE ORACLE_DATA PUMP
10 DEFAULT DIRECTORY def_dir1
11 LOCATION ('inv_xt.dmp')
12 );
Table created.
SQL>
The CREATE TABLE … ORGANIZATION EXTERNAL statement creates an external

table. There is no data in this table at this point. The external table inventories_xt2
is then populated using the flat file inv_xt.dmp, located in the directory def_dir1.
You could do all this in Oracle9i. The feature shown in the next example—writing
to an external table—is a brand-new Oracle Database 10g external tables enhancement.
SQL> CREATE TABLE dept_xt
3 (
5 DEFAULT DIRECTORY ext_tab_dir1
6 LOCATION ('dept_xt.dmp')
7 )
8* AS SELECT * FROM scott.DEPT
SQL> /
Table created.
Remember that when you …SELECT clause. When you populate an

load an Oracle table from an external table external table using Oracle table data, you
(data loading), you use the INSERT INTO use the CREATE TABLE AS SELECT clause.
If you now go look in the location specified for the default directory (ext_tab_
dir1), you’ll see a dump file named dept_xt.dmp, which contains the data from the
DEPT table. You can then use this dump file in the same database or a different
database to load other tables. Note that you must create the default directory ext_
tab_dir1 beforehand for this external table creation statement to succeed. You are
creating the external table dept_xt as an external table. The table structure and
data both come from the regular Oracle DEPT table. The CTAS method of table
creation will load the data from the DEPT table into the new external table dept_xt.
Where will the data for the dept_xt be located? You’ll be wrong if you answer
something like “in a table segment”! Since the dept_xt table is defined as an external
table, the CTAS command simply stores the table data in the external file called
dept_xt_dmp. Thus, the external table is really composed of proprietary format,
operating system-independent flat files.
When you use the external metadata using external tables. If you wish
tables feature to extract table data to a file, to extract the metadata for any object, just
you export only the data. You can’t export use DBMS_METADATA, as shown here:
SET LONG 2000

SELECT DBMS_METADATA.GET_DDL('TABLE','EXTRACT_CUST') FROM DUAL;
Parallel Population of External Tables

Since external tables can be quite frequently very large, it’s nice to know that you can
load external tables in a parallel fashion, simply by using the keyword PARALLEL
when creating the external table. Here’s the catch with the PARALLEL command
while creating an external table: your use of the PARALLEL parameter will make
sense only if you have more than one file specified as values for the LOCATION
variable. Otherwise, the PARALLEL command really can’t do anything in parallel
(the degree of parallelism defaults to 1)! The reason for this is that Oracle will allocate
exactly only one parallel execution server for each file. If you specify PARALLEL=4
and specify two datafiles for Oracle to write to, your degree of parallelism is automatically
lowered to 2. Thus, the degree of parallelism is constrained by the number of dump
files you specify under the LOCATION parameter.
Here’s an example of how to use the PARALLEL command while creating
external tables:
SQL> CREATE TABLE inventories_xt
3 (
5 DEFAULT DIRECTORY def_dir1
6 LOCATION ('inv_xt.dmp1',’inv_xt.dmp2’,inv_xt.dmp3’)
)
7 PARALLEL
8 AS SELECT * FROM inventories;
Defining External Table Properties

The data dictionary view DBA_EXTERNAL_TABLES describes features of all external
tables in your database:
SQL> desc dba_external_tables
Name Null? Type
----------------------------------------- -------- ---------------
OWNER NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)
TYPE_OWNER CHAR(3)
TYPE_NAME NOT NULL VARCHAR2(30)
DEFAULT_DIRECTORY_OWNER CHAR(3)
DEFAULT_DIRECTORY_NAME NOT NULL VARCHAR2(30)
REJECT_LIMIT VARCHAR2(40)
ACCESS_TYPE VARCHAR2(7)
ACCESS_PARAMETERS VARCHAR2(4000)
PROPERTY VARCHAR2(10)
Pay particular attention the last three columns in the DBA_EXTERNAL_

TABLES view:
■ The ACCESS_TYPE column refers to whether you have BLOB or CLOB

type of access parameters for your external table.
■ The ACCESS_PARAMETERS column shows all the access parameters
you used in creating the external table.
■ The PROPERTY column, which refers to the property of the projected
columns, could take two values: REFERENCED or ALL.
The default value for the PROPERTY column for all external tables is ALL. This
tells the access driver to always process all the columns of an external table, not just
some. This means that, regardless of which columns you select in a query, the access
driver will process all column values. The access driver will validate only those columns
without data errors. The access driver will also eliminate any rows that have erroneous
column values, even if those columns aren’t a part of the SELECT query.
If the PROPERTY column shows the value REFERENCED, this means that only
those columns referenced by a SQL statement are processed (parsed and converted)
by the Oracle access driver. When would you want to specify the REFERENCED
Transporting Tablespaces Across Different Platforms 45
property? You do this when you are quite sure about the quality of your data fields
and expect no data rejections due to data format errors. For example, you may have
a column called emp_id, which you define as a number(5) column. When Oracle
encounters a row in the datafile where the emp_id has six digits, it would normally
reject this row, since the default value for the property is ALL. This means that even
if you issue a query that selects a different column, say social_security_num from the
employee table, Oracle will reject all rows that have bad data in the emp_id column.
How do you change the default ALL property value for an external table to
REFERENCED? Say that you want to change this property for your external table
dept_xt, which now has the default ALL property.
SQL> select table_name,property from dba_external_tables;
TABLE_NAME PROPERTY
------------------------------ ----------
DEPT_XT ALL
To do this, you use the ALTER TABLE command in the following manner.
SQL> alter table dept_xt
2 project column referenced;
Table altered.
SQL> select table_name,property from dba_external_tables;
TABLE_NAME PROPERTY
------------------------------ ----------
DEPT_XT REFERENCED
SQL>
Changing the PROPERTY column to REFERENCED is a good idea if you know

your data is clean, because it provides better performance, since only the projected
columns are parsed and converted. If your data is clean, flagging an external table as
REFERENCED will provide better performance when you query only a subset of the
columns.The default ALL property projects all columns and will guarantee consistent
results, but all of the data is queried for every type of query, thus hindering performance.
Transporting Tablespaces Across Different Platforms

Suppose you need to move a large amount of data between two databases. What’s the
fastest way to do this? You can use the Data Pump export and import utilities, of
course, to perform the job. However, there is a much faster way to perform the data
transfer: use transportable tablespaces. Transportable tablespaces simply involve moving
tablespaces from one database to another. All you really need to do is to copy the
datafiles (containing tables, indexes, and other Oracle database objects) that comprise
the tablespace, from the target to the source server (if the two databases reside on
different servers) and just import the metadata of the objects in the tablespace to the
target database.
Transportable tablespaces are ideal for moving large amounts of data quickly
between two databases. The transportable tablespaces feature, of course, has been
available for a while now, but both the source and target databases needed belong
to the same operating system platform. In Oracle Database 10g, for the first time,
you can transport tablespaces between different platforms. Now the onerous requirement
of identical operating system platforms is gone, and you can easily transport a
tablespace from pretty much any platform to any other. This is a great feature, as
it enables you to take tablespaces from a data warehouse and plug them into data
marts, even though your data warehouse runs on an UNIX platform and the data
marts are located on smaller Windows servers. As you have probably already figured
out, the key here is Oracle Database 10g’s ability to convert one set of datafiles from
one operating system format to another, so the target database can read the source
database files.
Transportable tablespaces are a good way to migrate a database between

different platforms.
Transporting a Tablespace Between Identical Platforms

Although the procedure of transporting tablespaces hsn’t really changed in Oracle
Database 10g, let’s recap the steps involved in transporting tablespaces, so you can
understand the new changes better. Transporting a tablespace from one database to
another when both databases belong to the same platform consists of the following steps:
1. Ensure that the tablespaces are self-contained.

2. Make the tablespaces read-only.
3. Export the metadata using Data Pump export.
4. Copy the datafiles over to the target system.
5. Use Data Pump import to import the metadata.
Following are the general requriements for transporting tablespaces between two
databases:
■ Both platforms should use the same character sets.

■ Both databases must be using Oracle8i or a higher version, but the database
version does not need to be identical.
■ You cannot transport the SYSTEM tablespaces or any objects owned by the
user SYS.
■ If you want to transport a partitioned table, all the partitions must be
included in the transportable table set. If you are transporting indexes, you
also need to transport the tablespaces containing the respective tables as well.
■ You can transport tablespaces to a target database only if it has the same or
higher compatiblity setting than the source database.
If either the source or the 10.0.0, you cannot transform a tablespace

target database compatibility level is less than across different operating sytem platforms.
Determining the Supported Platforms

Note that you can’t transport tablespaces between all operating system platforms
automatically, even in Oracle Database 10g. How do you know which platforms are
supported for cross-platform tablespace transport? All you need to do to get this
information is to query the new V$TRANSPORTABLE_PLATFORM view:
SQL> col platform_name format a30
SQL> select * from v$transportable_platform;
PLATFORM_ID PLATFORM_NAME ENDIAN FORMAT
----------- ------------------------------ --------------
1 Solaris[tm] OE (32-bit) Big
7 Microsoft Windows IA (32-bit) Little
10 Linux IA (32-bit) Little
6 AIX-Based Systems (64-bit) Big
3 HP-UX (64-bit) Big
5 HP Tru64 UNIX Little
4
HP-UX IA (64-bit) Big
11
Linux IA (64-bit) Little
15
HP Open VMS Little
8
Microsoft Windows IA (64-bit) Little
9
IBM zSeries Based Linux Big
13
Linux 64-bit for AMD Little
16
Apple Mac OS Big
12
Microsoft Windows 64-bit for A Little
MD
15 rows selected.
SQL>
The V$TRANSPORTABLE_
PLATFORM view shows all
platforms supported for
transporting tablespaces. The In order to transport
PLATFORM_NAME column tablespaces across different platforms,
shows all the platforms that are the character sets in both databases
eligible for transporting across should be identical.
platforms. If both your source
and target platforms are in this list, you can conduct the transportable tablespaces
operation between the databases running on those platforms.
You can find out your own platform name, in case you aren’t sure, by running the
following simple query:
SQL> select platform_name from v$database;
PLATFORM_NAME
----------------------------------------
Microsoft Windows IA (32-bit)
SQL>
If you need to transport read-only tablespaces to ensure that your datafile headers
can identify the operating system platform, you must first make the datafile read/
write at least once (after setting the database compatibility level at 10.0.0 or higher).
If your source database is operating at a 9.2.0 compatibility level, for example, you
need to first advance the compatibility level to 10.0.0 before you can transport any
tablespaces for this database.
Converting to Match Datafile Endian Formats

Even if your source and target operating system platforms are identical, you may
still not be able to perform a tablespace transport directly. Remember that the most
time-consuming job during a tablespace transport is the copying of the files that
belong to the tablespace. If the endian format of two operating system platforms is
different, you need to perform a conversion of the datafiles, either before or after
you copy the files to the target system.
What does the ENDIAN FORMAT column, which you can see in the following
query, stand for?
SQL> select * from v$transportable_platform;
PLATFORM_ID PLATFORM_NAME ENDIAN FORMAT
----------- ------------------------------ --------------------------
7 Microsoft Windows IA (32-bit) Little
10 Linux IA (32-bit) Little
SQL>
Endian format refers to byte ordering in the datafiles of a given platform. Byte
ordering affects the way data is written and read in different platforms. There are
only two types of endian formats: little or big. In order for the datafiles between
two compatible platforms to be transported directly from one another, their endian
format (also known as endianness) should be the same. Both the source and target
platforms should have an identical endian format—either both are in the big format
or both are in the little format.
If you have two platforms that are in the compatible list for transporting tablespaces,
but their endian formats are different, you need to convert the datafiles belonging
to the tablespaces that you are exporting, using the RMAN utility.
Being compatible for isn’t the same thing as having identical

the purpose of transporting tablespaces endian formats.
Transporting a Tablespace Across Platforms

The steps for transporting tablespaces across platforms are the same as for transporting
tablespaces across identical platforms, with an additional step if the source and target
database file endian format are different. The following sections provide an example of
these steps.
Ensure the Tablespaces Are Self-Contained

Ensure that the tables you want to transport all are placed in their own separate
tablespaces. To ensure that your tablespaces are self-contained, you need to use the
TRANSPORT_SET_PROCEDURE in the Oracle-supplied package DBMS_TTS.
Make the Tablespaces Read-Only

Alter the tablespace to make it read-only. Once you complete the export of the
metadata in the next step, you can make the tablespace read/write again.
Export the Metadata Using Data Pump Export

Export the metadata describing the objects in the tablespace(s), by using the
TRANSPORTABLE_TABLESPACES parameter.
Convert the Datafiles to Match Endian Format

If your platforms are compatible, but the endian formats are different, you need to
convert the datafiles. You may perform the conversion before transporting the tablespace
set or after finishing the transport. You can convert the datafiles before transporting
the tablespaces, using the following CONVERT TABLESPACE command in the RMAN:
RMAN> convert tablespace finance_tbs01
2> to platform 'HP-UX (64-bit)'
3> format '/temp/%U';
Starting backup at 09-MAY-04
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00011 name=C:\ORACLE\TEST02.DBF
converted datafile=C:\TEMP\DATA_D-FINANCE_I-2343065311_TS-TODAY_FNO-11_05FLAUM6
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:17
Finished backup at 09-MAY-04

RMAN> exit
Recovery Manager complete.
In this example, I show how you can use the FORMAT parameter to tell Oracle
what format the newly converted file should be and in which directory to put it. But
as you can see, Oracle gives the file a name. If you want to specify the datafile name
youself, perform the conversion using the DB_FILE_NAME_CONVERT clause, as
follows. (Remember that you use the following command when you convert the files
directly on the source system, before transporting them.)
RMAN> convert tablespace today
2> to platform 'HP-UX (64-bit)'
3> db_file_name_convert = 'c:\oracle\test02.dbf','c:\temp\test02.dbf';
Starting backup at 10-MAY-04
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=151 devtype=DISK
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00011 name=C:\ORACLE\TEST02.DBF
converted datafile=C:\TEMP\TEST02.DBF
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:16
Finished backup at 10-MAY-04
RMAN>
The DB_FILE_NAME_CONVERT clause performs the following functions for you:
■ Takes a given filename and converts it to any filename you specify

■ Places the converted file in the location you specify
Copy the Files to the Target System

At this point, you need to copy both the converted datafile that is part of the tablespace
(finance_tbs01 in this example) as well as the expdp dump file, sales2003.dmp, over
to the target server where your target database is running.
If you chose to transport the tablespaces (the datafiles that constitute the tablespaces)
first, you must convert the datafiles on the target platform at this point, before trying
to perform the import of the metadata in the tablespace. Here’s an example that
shows how you can take a datafile that belongs to the HP-UX operating system
platform and convert it into a Windows platform:
RMAN> convert datafile
2> 'c:\audit_d01_01.dbf'
3> to platform 'Microsoft Windows IA (32-bit)'
4> from platform='HP-UX (64-bit)'
5> FORMAT '\export';
As in the previous case where you performed the file conversion on the source
sytem, you may use the DB_FILE_NAME_CONVERT clause when performing the
data file conversion on the target system. Your datafile conversion statement would
then have the format CONVERT DATAFILE …FROM PLATFORM …DB_FILE_
NAME_CONVERT = ….
By default, Oracle places the converted files in the Flash Recovery Area,
without changing the datafile names.
Use Data Pump Import to Import the Metadata

Once you move the converted files files over to the target system (or move the files
over first and convert them later), use the Data Pump import utility as follows to
import the metadata into the target database—that is, just plug in the tablespaces and
use the Data Pump import to integrate the datafiles and their metadata (found in the
test.dmp file):
impdp system/manager TRANSPORT_TABLESPACE=y
DATAFILES='/u01/app/oracle/data01.dbf'
TABLESPACES=test FILE=test.dmp
Understanding Exceptions to File Conversions

There is an important exception to the file conversions that the RMAN performs for
you in order to enable the transporting of tablespaces between two platforms with
different endian formats. RMAN doesn’t automatically convert CLOB data for you
during file conversion. Here’s what you need to know about CLOBs and file conversion
for transportable tablespaces:
■ If your CLOBs were created in an operating system with the big-endian

format, you don’t need to convert the CLOB data.
■ If you are transporting little-endian CLOB data to a big-endian system, a
conversion must be done. But even here, Oracle can automatically convert
the CLOB data to the big-endian format dynamically, whenever a user

accesses the data. However, if you wish to do all the conversion yourself,
you may do so by re-creating the table on the target database.
Here’s the reasoning for the variation in the treatment of CLOB data in big-
endian and little-endian systems: prior to Oracle Database 10g, CLOBs were stored
in the UCS2 format, which is endian-dependent, but Oracle Database 10g stores
them as AL16UTF16, which is endian-independent. However, big-endian UCS2
is the same as AL16UTF16. So if your source system was big-endian, there isn’t any
difference. If it wasn’t, Oracle will convert the datafiles on demand.
INSIDE THE EXAM
The exam will test your knowledge of the new Path API. You can expect some questions
Data Pump import and export parameters. You on the DBMS_DATAPUMP and the DBMS_
must understand the new parameters like the METADATA packages. You must understand
remapping parameters of Data Pump import. the importance of the master table.
What are the different levels at which you can There will be questions on the external
perform transformations during an import? Pay table population feature. You must remember
particular attention to the new parameters like the syntax for performing an external table
ESTIMATE, ESTIMATE_ONLY, NETWORK_ population (CREATE TABLE AS SELECT).
LINK, INCLUDE, and EXCLUDE. You must Review the parallel feature, putting special
know the levels at which you can perform emphasis on the relationship between the degree
Data Pump import and export. of parallelism and the number of dump files.
You can expect questions on the interactive The test will contain questions on the new
import and export commands. How do you features related to transportable tablespaces.
attach to a running job? What happens to a What is an endian format, and what role does
job and a client session when you stop a job? it play in transporting tablespaces across
Review the Data Pump dictionary views like platforms? You must remember the RMAN
DBA_DATAPUMP_JOB_STATISTICS and commands to convert the endian formats of
DBA_DATAPUMP_JOBS. files. What is the difference in the file
There will be a question on the Data Pump conversion commands when you convert files
architecture. You must know the difference on the target platform and when you convert
between the External Table API and Direct them on the source platform?
This chapter introduced you to the new Data Pump technology in Oracle Database 10g.
You saw how Data Pump offers sophisticated new features to run large export and import
jobs faster, while offering exceptional data-filtering techniques. You also learned about
the powerful interactive Data Pump features. You learned how to monitor your Data
Pump jobs.
You learned how to populate external tables. You also saw how the new options
you have in Oracle Database10g regarding external table properties. You learned
how to transport tablespaces across server platforms, even when the file semantics
are different between two operating sytem platforms.
Two-Minute Drill 55
❑ The new Data Pump technology is a much more efficient way of moving large
amounts of data than the old export/import utilities.
❑ You can still continue to use the traditional export and import utilties in
❑ Data Pump technology is entirely server-based; all work takes place on the server.
❑ The Data Pump export utility exports data out of the database, and the Data
Pump import utility imports data into a database.
❑ There are two kinds of parameters: a set of command-line parameters and a
special set of interactive commands in both the Data Pump import and
export utilities.
❑ The Oracle-supplied package DBMS_DATA PUMP is used to implement the
Data Pump API.
❑ The clients for the Data Pump export and import utilities are expdp and
impdp, respectively.
❑ DBMS_METADATA, an older Oracle-provided package, is used to extract and
modify data dictionary metadata.
❑ Data Pump export can access data in two ways: direct-path access using the
Direct Path API or through external tables. Data Pump itself makes the
decision as to the access choice, based on which will be faster in a given case.
❑ Direct-path access is the first method Oracle will try to use. Under some
conditions, Oracle cannot use the direct-path method, and it must use the
external tables access method.
❑ You can export data using either direct path or external tables and import the
data back with either of the two methods.
❑ There are three types of Data Pump files: dump files, log files, and SQL files.
❑ Data Pump export dump files are created on the server, using directory objects.
❑ Directory objects are named objects that are mapped to an operating system
directory.
❑ Once you create a directory, you can access that file system by simply
referring to the dirctory name.
❑ In order to create a directory, you must have the DBA role. In order to use a
directory, you must have the appropriate read and/or write privileges on the
directory.
❑ DATA_PUMP_DIR is the default directory object for Data Pump jobs. Only
privileged users can use this default directory object.
❑ The order of precedence for file locations is the following: the directory name
as part of a file parameter name, the value assigned to the DIRECTORY
parameter, the directory name specified by DATA_PUMP_DIR environemnt
variable, and finally, the default value for the DATA_PUMP_DIR object.
❑ All Data Pump jobs consist of a master and several worker processes. The
master process controls jobs and the worker processes as well. The master
process is also responsible for monitoring the progress of jobs.
❑ The master process uses the master table to store the database object location.
The master table is created during the export process. If the job completes
successfully, the master table is automatically deleted from the database.
❑ During Data Pump import, the master table is consulted to verify the correct
sequencing of objects during import.
❑ If you choose the PARALLEL option, the worker processes become parallel
execution coordinators.
❑ The benefits of the Data Pump technology include the ability to restart jobs,
parallel execution capabilities, ability to attach to a running job, ability to
estimate space requirements, fine-grained export and import capabilities, and
remapping capabilities.
❑ You can perform both network mode exports and imports.
❑ You can perform Data Pump export/import from the command line or with
the help of parameter files.
❑ In Data Pump export/import, you use the interactive mode to intervene
during a running job. There are several special commands you can use in
this interactive mode.
❑ You can start the interactive mode either by using the CONTROL-C
combination or by using the ATTACH command from a different session.

❑ You can perform Data Pump export and import in full, tablespace, table, or
schema modes. You can also perform Data Pump jobs in the transportable
tablespaces mode.
Two-Minute Drill 57
❑ The CONTENT parameter can take the values ALL, DATA_ONLY, or

METADATA_ONLY. The ALL parameter enables the export of both data and
metadata. The DATA_ONLY parameter lets you export data only. The
METADATA_ONLY option enables the export of only the object definitions.
❑ The EXCLUDE parameter forces the exclusion of specific objects, and the
INCLUDE parameter requries the inclusion of specified objects.
❑ The EXCLUDE and INCLUDE parameters are mutually exclusive.
❑ You use the QUERY parameter to filter table row data with the help of a
SQL statement.
❑ The ESTIMATE parameter provides an estimate of the size of the export job. It
uses BLOCKS by default. You can specify ESTIMATE=STATISTICS to make
the parameter use database statistics instead of the default blocks method.
❑ The ESTIMATE_ONLY parameter just gives you a size estimate, without
performing an export.
❑ You can connect to a running export or import job by using the ATTACH
command.
❑ The CONTINUE_CLIENT parameter takes you out of the interactive mode
but keeps the job running. The EXIT_CLIENT command will terminate the
interactive session and the client session. The KILL_JOB command will
terminate the export or import job in addition. The STOP_JOB command
stops running Data Pump jobs.
❑ The STATUS parameter will provide you with periodic job progress updates.
❑ The default value of the PARALLEL parameter is 1. In practice, it is limited
by the number of dump files you provide for the export job.
❑ By default, a Data Pump export job will export the entire schema of the user
running it.
❑ The SQLFILE parameter is used during a Data Pump Import to extract DDL
to a specified file, without conducting an import of the data in the export
dump file.
❑ If you specify REUSE_DATAFILES=Y, Data Pump will overwrite your
existing datafiles.
❑ Remapping parameters are used during a Data Pump import job to remap
database objects. You can remap datafiles, tablespaces, and entire schemas.
❑ The NETWORK_LINK parameter enables you to import data directly from as

target database, without using any dump files. You must first create a database
link before performing a network import.
❑ The TRANSFORM parameter enables you to modify storage and
tablespace clauses during an import.
Monitoring a Data Pump Job

❑ You can monitor Data Pump jobs with the help of the views DBA_DATA
PUMP_JOBS, DBA_DATA PUMP_SESSIONS, and V$SESSION_
LONGOPS.
❑ The DBA_DATAPUMP_JOBS view shows all active Data Pump jobs.
❑ The DBA_DATAPUMP_SESSIONS view shows all the user sessions attached
to an import or export job.
❑ The V$SESSION_LONGOPS view tells you how far a Data Pump job has
progressed.

❑ You can now populate external tables by using the ORACLE_DATA PUMP
access loader.
❑ The main parameters you need to specify in the creation of external tables are
type, default_directory, location, and access_parameters.
❑ Loading data refers to reading data from external tables. Unloading data refers
to populating external tables.
❑ You use the CREATE TABLE AS SELECT (CTAS) statement to populate
external tables.
❑ The ORACLE_LOADER access driver permits only the loading of external
tables.
❑ The ORACLE_DATAPUMP access loader will permit both the loading and
the unloading of data (reading as well as writing to external tables).
❑ You can load external table creation faster by using the PARALLEL
parameter. If you use the PARALLEL parameter, you must specify more than
one datafile for writing the data. The degree of parallelism is limited by the
number of datafiles you provide.
Two-Minute Drill 59

❑ External tables could have either of two values for the PROPERTY column:
ALL or REFERENCED.
❑ The default value fo the PROPERTY column is ALL.
❑ If your data is known to be clean (no data formatting errors), you should use
the REFERENCED value for the PROPERTY column, for better performance.
❑ You can use the ALTER TABLE command to change the PROPERTY
column of an external table.

❑ You can now transport tablespaces across different operating system
platforms.
❑ In order to qualify for a cross-platform tablespace transport, both platforms
should set to the compatibility equal to 10.0.0, use an identical character set,
and be in the compatible platforms list.
❑ The view V$TRANSPORTABLE_PLATFORM will let you know if a pair of
operating system platforms are compatible.
❑ The endian format of an operating system platform refers to the byte-ordering
format of the files on that platform.
❑ If the endian format of two compatible platforms is the same, you don’t need
to convert the datafiles for transporting them across different platforms.
❑ If the endian format of two compatible platforms is different, you must
convert the datafiles either before or after you physically transport the
tablespaces.
❑ You use the DB_FILE_NAME_CONVERT option to convert file formats from
one endian format to another.
❑ If your CLOBs were created in an operating sytem with the big-endian
format, you don’t need to convert the CLOB data.
❑ If you are transporting little-endian CLOB data to a big-endian system, you
must convert the data.
SELF TEST
The following questions will help you measure your understanding of the material presented in
this chapter. Read all the choices carefully because there might be more than one correct answer.
Choose all correct answers for each question.

1. Which of the following are part of the new Data Pump technology?
A. DBMS_METADATA, DBMS_DATA PUMP, Direct Path API
B. DBMS_METADATA, DBMS_DATA PUMP, Indirect Path API
C. DBMS_METADATA, DBMS_DATA PUMP, SQL Loader API
D. DBMS_METADATA, DBMS_DATA PUMP, Export API
2. What is the DBMS_METADATA package used for?
A. Transport tablespaces between two databases
B. Load and unload metadata
C. Perform a cross-platform transport of tablespaces
D. Load external tables
3. Assume the following is the first import job you are performing in your database:
$ impdp system/manager parfile=imp.par
What would be the default name of your master table?

A. IMPORT_FULL_01
B. SYS_IMPORT_FULL_01
C. SYSTEM_IMPORT_FULL_01
D. DATA PUMP_JOB_FULL_01
4. Which of the following statements is correct?
A. The master table is created during a Data Pump export job and written to the dump file at
the very beginning of the export job.
B. The master table is created during a Data Pump export job and written to the dump file at
the very end of the export job.
C. The master table is created during a Data Pump import job and written to the dump file at
the very beginning of the import job.
D. The master table is created during a Data Pump import job and written to the dump file at
the very end of the import job.
Self Test 61

5. The DBA has just performed a full database Data Pump export. She must now perform a full
database import using the dump file set created by the export job. Which one of the following
statements would be correct under the circumstances?
A. impdp system/manager dumpfile=expdata.dmp FULL=Y
B. impdp system/manager dumpfile=expdata.dmp
C. impdp system/manager FULL=Y
D. impdp system/manager dumpfile=expdata.dmp FROMUSER=TOUSER
6. Which of the following parameters enables you to perform a data-only unloading of data?
A. EXCLUDE
B. INCLUDE
C. CONTENT
D. DATA_ONLY
7. Which of the following statements is correct?
A. If you stop a job using the STOP_JOB command, the master table is retained for use in
restarting the job.
B. If you stop a job using the KILL_JOB command, the master table is dropped and the job
cannot be restarted.
C. If you stop a job using the KILL_JOB command, the master table is retained and you can
restart the job later.
D. If a job terminates unexpectedly, the master table is dropped automatically.
8. Which of the following occurs when you start an interactive session with Data Pump?
A. The currently running export job is interrupted briefly.
B. The current job continues normally.
C. The current job is stopped and you need to restart it later.
D. You cannot start an interactive session when a Data Pump job is running.
Monitor a Data Pump Job

9. How can you see the amount of work performed so far by your Data Pump import job?
A. Query the V$JOB_STATUS view
B. Query the V$SOFAR view
C. Query the V$SESSION_LONGOPS view
D. Query the DBA_DATAPUMP_JOBS view
10. Which is the sequence of commands you must use if you want to suspend and then resume your
Data Pump job?
A. START_JOB, ATTACH, CONTINUE_CLIENT
B. ATTACH, KILL_SESSION, CONTINUE_CLIENT
C. ATTACH, STOP_JOB, START_JOB
D. STOP_JOB, ATTACH, CONTINUE_CLIENT
11. What information do you need to supply to attach to a running job from a different session?
A. The location of the dump file
B. Username and password, job name
C. Username and password onl
D. Username and password, master table name
12. What does the column SOFAR in the monitoring view V$SESSION_LONGOPS tell you?
A. How many megabytes have been transferred thus far in the job
B. What percentage of the job has been completed thus far
C. What percentage of the job remains to be done
D. The estimated number of megabytes left to be transferred

13. Which two of the following statements is true?
A. You use the ORGANIZATION EXTERNAL clause during an external table unloading
operation.
B. You use a CREATE TABLE AS SELECT statement during an external table loading
operation.
C. You use a CREATE TABLE AS SELECT from statement during an external table
unloading operation.
D. You use the ORGANIZATION EXTERNAL clause only for reading data into an external
table from an operating system file.
14. What does unloading of data refer to?
A. The reading of data from external datafiles into external tables.
B. The writing of data from Oracle tables to external datafiles.
C. The writing of data from external datafiles into external tables.
D. The reading of data from Oracle tables into external datafiles.
Self Test 63
15. Why should you use the NETWORK_LINK export parameter when you perform a Data Pump
export of a read-only database?
A. You can’t write to a read-only database.
B. The export is faster if you use the NETWORK_LINK parameter.
C. You don’t need to use export dump files when you use the NETWORK_LINK parameter
during export
D. You can’t use the traditional export utility to export a read-only database.
16. If the number of files in the LOCATION clause is different from the degree of parallelism that
you specify, which two statements below would be correct?
A. Oracle will ignore the PARALLEL parameter.
B. Oracle will perform the table population with the same degree of parallelism as the number
of files.
C. Oracle ignores any extra files (files greater than the degree of parallelism) that you may
specify.
D. You can instruct the parallel execution server to write to multiple files simultaneously.

17. The DBA knows that the database may reject certain columns in an external table, due to data
format errors. In this case, what should the DBA do to get consistent query results?
A. Clean up the data so the rows with data format errors are taken out of the table.
B. Alter the external table to set the PROJECT COLUMN attribute to ANY.
C. Alter the external table to set the PROJECT COLUMN attribute to ALL.
D. Alter the external table to set the PROJECT COLUMN attribute to REFERENCED.
18. Which of the following is true in Oracle Database 10g?
A. The default value for an external table PROJECT COLUMN attribute projects all columns.
B. The default value for an external table PROJECT COLUMN attribute projects no
columns.
C. The default value for an external table PROJECT COLUMN attribute projects only
columns with no data errors.
D. The default value for an external table PROJECT COLUMN attribute projects only
columns with data errors.
19. Which of the following is true if your data is clean (without any formatting errors)?
A. Using the ALL value for the PROJECT COLUMN attribute always provides the same
results.
B. Using the REFERENCED value for the PROJECT COLUMN attribute always provides the
same results.
C. Using the default value for the PROJECT COLUMN attribute always provides the same
results.
D. Using the ALL value for the PROJECT COLUMN attribute always provides different
results.
20. Of the following, which statement is true of the external table properties?
A. REFERENCED is better because you need to parse and convert only some columns.
B. ALL is better because you need to parse and convert only some columns.
C. ALL is better because you need to parse and convert all columns.
D. REFERENCED is better because you need to parse and convert all columns.

21. Which of the following interfaces can you use to convert your database files when the endian
formats are incompatible between a source and a target database?
A. SQL*Plus
B. RMAN
C. OEM Database Control
D. Oracle PL/SQL procedures and packages
22. Which of the following do you need to do when the endian formats of the target and source
database files are different?
A. Convert the source files on the source system, copy them to the target system, and import
the metadata.
B. Convert the source files on the source system, copy them to the target system, and export
the metadata.
C. Copy the source files to the target system, convert the datafiles, and export the metadata.
D. Copy the source files to the target system, convert the datafiles, and import the metadata.
Lab Question 65
23. To find out if two databases are cross-transportable compliant, which data dictionary view do
you need to use?
A. V$TRANSPORTABLE_PLATFORM
B. V$ENDIAN FORMAT
C. V$PLATFORM
D. V$COMPATIBILITY_LEVEL
24. Which of the following can you do if you find both the target and source operating system
platforms in the V$TRANSPORTABLE_TABLESPACES view?
A. Automatically transport tablespaces between the two platforms
B. Transport tablespaces only after you perform a mandatory file conversion first
C. Transport tablespaces between the two platforms only if their endian format is different
D. Transport tablespaces between the two platforms, provided you always perform a file
conversion first if the file endian formats are different
LAB QUESTION
Start a Data Pump export job as the user SYSTEM. Export the entire database. Show the commands
you would enter to perform the following actions:
■ Start an interactive session by using the ATTACH command.
■ Find out the name of the master table.
■ Parallelize the export (four streams).
■ Resume the export job.
SELF TEST ANSWERS

1. þ A. The DBMS_METADATA and DBMS_DATAPUMP packages are the main Oracle
PL/SQL packages that the Data Pump technology uses. The Direct Path API is a part of
Data Pump as well.
ý B, C, and D all contain the name of an invalid API.
2. þ B. As the name of the package indicates, DBMS_METADATA is used to load and unload
metadata.
ý A and C are not correct because the package doesn’t play a role in transporting
tablespaces. D is wrong because the package isn’t related to external tables.
3. þ C. The default name of the master table is of the format: USERNAME_OPERATION_
TYPE_N. In this case, since you know user SYSTEM is performing a full import, it shouldn’t
be that hard to pick this answer.
ý A and D are wrong since they don’t have either user’s name. B is wrong since it contains
the username SYS instead of SYSTEM.
4. þ B. The master table is created during an export job. The creation of the master table is the
last thing that the Data Pump export utility does, before finishing the job.
ý A is wrong since it says that the master table is created at the beginning of the export job.
C and D are incorrect since they state that the master table is created during the import job.

5. þ A. This answer provides all the necessary parameters: username, dump filename, and the
FULL parameter to perform the full import.
ý B is wrong because it is missing the FULL parameter—the default mode for import is the
schema level, not a full database import. C is wrong because it is missing the dump filename.
D is incorrect because there isn’t a FROMUSER/TOUSER option in Data Pump.
6. þ C. This is a slightly tricky question. The CONTENT parameter offers the option of
exporting just the data in the tables, by using DATA_ONLY as the value for the parameter.
ý A and B are incorrect since these parameters enable you to specify only the type of objects
you want to include or exclude. D is wrong since DATA_ONLY is not an export parameter—
it’s an option for the CONTENT parameter.
7. þ A and B. A is correct because using the STOP_JOB command doesn’t drop the master
table. B is correct because using the KILL_JOB command terminates the job and drops the
master table.
ý C is incorrect since the use of the KILL_JOB command removes the master table. D is
incorrect since an unexpected termination of a job doesn’t automatically drop the master table.
8. þ B. You can start an interactive session in Data Pump only when an export job is already
running. Thus, when you log interactively in to a Data Pump job using either the CONTROL-C
sequence or the ATTACH command, the job is already running.
ý A and C are wrong since the export job is neither interrupted nor stopped when you log in
interactively. D is wrong since the Data Pump job must be running for you to log in interactively.
Monitor a Data Pump Job

9. þ C. The SOFAR column in the V$SESSION_LONGOPS view tells you how much of Data
Pump job (in megabytes) has been completed thus far.
ý A, B, and D cannot tell you anything about the progress of your Data Pump jobs.
10. þ C. First, you need to use the ATTACH command to attach to the interactive session. To
suspend the job, you should use the STOP_JOB command. The START_JOB command will
resume the job.
ý A, B, and D provide various wrong sequences of commands.
11. þ B. You need to provide both the username/password and the job name before you can
attach to a running job.
ý A is wrong because you don’t need to specify the dump file location. C is wrong because
the username/password is inadequate to attach to a session. D is wrong because you don’t need
the master table’s name to attach to a Data Pump session.
12. þ A. The SOFAR column tells you how many megabytes have been transferred thus far.
ý B and C are incorrect because the SOFAR column doesn’t deal with the percentage of
work—it deals with the work in terms of megabytes. D is wrong because it talks about work
still to be done, not work already completed by the job.

13. þ A and C. A is correct because you must use the ORGANIZATION EXTERNAL clause
whether you are loading or unloading data. C is correct because you have to use the CREATE
TABLE AS SELECT (CTAS) clause when you populate an external table.
ý B is incorrect because you don’t need to use the CTAS statement during external table
loading. D is incorrect since you need the ORGANIZATION EXTERNAL clause for both
reading from and writing to external tables.
14. þ B. Unloading of data is the writing of Oracle table data to external datafiles, in the
form of external tables.
ý A and D are clearly wrong since unloading of data involves writing of data, not reading
of data. C is wrong since it states the opposite of what’s true.
15. þ A is correct because you can’t use Data Pump export if you are exporting a read-only
database, since you can’t create the master table in a read-only database. The NETWORK_
LINK parameter provides a way to solve this problem.
ý B is wrong because this isn’t the reason why you need to use the NETWORK_LINK
parameter. C is incorrect because you do need to create an export dump file, no matter what
parameters you specify. D is wrong because you can export a read-only database using the
traditional export utility.
16. þ B and C. B is correct because Oracle will set the degree of parallelism to the number of
files. C is correct because when the number of datafiles is more than the degree of parallelism,
Oracle will ignore the extra files.
ý A is incorrect since Oracle doesn’t ignore the PARALLEL parameter if the number of files
is different from the degree of parallelism. B is incorrect since Oracle doesn’t adjust the degree
of parallelism to match the number of datafiles. D is wrong since the parallel execution server
will not write to multiple files simultaneously.

17. þ C. The DBA should make sure that the PROJECT COLUMN attribute value is set to
ALL, which is the default value for the column as well.
ý A is incorrect since the DBA isn’t responsible for cleaning up the data format errors in
the data. B is wrong since there isn’t a value of ANY for the PROJECT COLUMN. D is
wrong since setting the column value to REFERENCED will give you inconsistent query
results, depending on the columns you specify in each query.
18. þ A. The default value for the PROJECT COLUMN attribute is ALL, which means Oracle
will project all columns out.
ý B is wrong since the default behavior, as answer A shows, is to project out all columns.
C and D are wrong since the projection of the columns has nothing to do with whether the
columns have data errors or not.
19. þ A, B, and C. If your data is clean, it doesn’t make a difference if the PROJECT COLUMN
attribute has the value ALL or REFERENCED, since the results are going to be consistent with
either value.
ý D is incorrect since the use of the ALL column will produce the same results for any query,
if your data doesn’t have any formatting errors.
Lab Answer 69
20. þ A. REFERENCED is better because you need to parse and convert only the selected
columns in the query, not all the columns in the table.
ý B is incorrect because you need to parse and convert all columns, not just some, if you
choose the ALL value for the PROPERTY column. C is incorrect since ALL forces the parsing
and conversion of all columns; it isn’t better than using the REFERENCED value for the
PROPERTY column. D is incorrect since REFERENCED means that Oracle doesn’t parse
and convert all columns.

21. þ B. You need to use the RMAN interface to convert database files when the endian
formats are different between platforms.
ý A, C, and D are wrong since you can’t use any of these interfaces or tools to convert
your datafiles.
22. þ A and D. You may convert the datafiles either on the source or on the target system,
and perform a Data Pump import afterwards.
ý B and C are incorrect since they mention exporting of the metadata instead of importing.
23. þ A. The V$TRANSPORTABLE_PLATFORM view shows you all the platforms that are
compatible with each other. You join this view with the V$DATABASE view to determine
platform compatibility.
ý B, C, and D are incorrect since there are no such views.
24. þ D. You can transport tablespaces across platforms even if the endian formats are different,
as long as you convert the datafiles during the transport process.
ý A is wrong since you can’t automatically transport tablespaces between two platforms if
they both are in the V$TRANSPORTABLE_TABLESPACES view. If the endian formats of
the two platforms vary, you need to perform a file conversion first. B is incorrect because file
conversions aren’t mandatory for transporting tablespaces—you need to convert datafiles only
if the file semantics (endian formats) are different between the two platforms, since the endian
formats cannot be different for implementing transportable tablespaces. C is incorrect because
the opposite is true—you can automatically transport tablespaces across platforms if the endian
formats are identical.
LAB ANSWER
■ You can start an interactive session and attach to a running export job by using the following
command at the expdp prompt:
$ expdp salapati/sammyy1 attach=SALAPATI.SYS_EXPORT_SCHEMA_01
To stop the running job, you issue the following command at the expdp prompt (if you want
an immediate rather than an orderly stoppage of the export job, you can use the command
STOP_JOB=IMMEDIATE):
expdp> STOP_JOB
■ The name of the master table is always the same as the job name. In this case, it is
SYS_EXPORT_SCHEMA.
■ Once you attach to the running export session, you can issue various comamnds at the
operating system prompt. To make your export session perform an export to four dump
files simultaneously, you issue the following command:
expdp> PARALLEL=4
■ To resume your export job after making the changes, you issue the following command:
expdp> START_JOB
The START_JOB command doesn’t “start” a new job—it resumes a job you stopped by attaching
to it first. If you have both the dump file and the master table (which is in the export dump file),
you can always resume a stopped export job without any data loss or corruption of data.
Blind Folio 3:1
3
Automatic
Database
Management
3.01 Use Automatic Database Diagnostic 3.03 Use Automatic Optimizer Statistics
Monitor Collection
3.02 Use Automatic Shared Memory 3.04 Use Automatic Undo Retention Tuning
Management
Q&A Self Test
2 Chapter 3: Automatic Database Management
Y ou have probably heard a lot of talk about Oracle Database 10g being a self-managing
database. Far from being hype, Oracle Database 10g offers you a dazzling array of
self-managing features that will help you perform difficult tuning chores effortlessly.
Not only that, the database now provides you with ways to implement your performance fixes.
As practicing Oracle DBAs, we all know how difficult it can be to figure out what is causing
a performance problem. Accurate and quick diagnosis of performance issues is critical to the
success of any Oracle database professional. Oracle DBAs routinely undertake tuning exercises
that involve running SQL scripts, poring over extended trace results, using the EXPLAIN PLAN
statement, using the TKPROF utility, and/or employing other tuning aids.
For the first time, Oracle Database 10g helps you automatically diagnose performance
problems. Diagnosing and fixing performance problems may be as simple as going
to the OEM Database Control and selecting one or more of the recommendations.
Often, it is hard for you to reproduce a performance problem after it has already
occurred. Do you recall how often the OracleMetaLink service asks you to see if you
can “reproduce” a performance problem? In Oracle Database 10g, the database collects
and saves all the statistical data you need for a performance diagnosis in the Automatic
Workload Repository (AWR).
A new diagnosis tool, the Automatic Database Diagnostic Monitor (ADDM) analyzes
this data regularly, to provide you with detailed information about the root cause of
performance problems, as well as recommendations for how to fix the problem. The
ADDM relies on years of Oracle Corporation’s performance methods, thus making
it a sort of an expert system or a self-diagnostic engine that is built right into Oracle
Database 10g. Since the performance statistics collection mechanism relies on the
Oracle System Global Area (SGA), it is very accurate and efficient. The ADDM
uses a new statistics collection method, where statistics are read directly from the
SGA structures by a new background process called the Manageability Monitor
process (MMON). Hence, there is none of the performance overhead of a session
populating a V$ view.
Previous versions of Oracle provided you with ways to manage the critical SGA
on a dynamic basis. The ability to dynamically modify SGA component sizes means
that you don’t need to restart an instance after you make the changes. Now, Oracle
has gone a step further and provides you with the option of using Automatic Shared
Memory Management. With automatic SGA management, you can realize the twin
tasks of conserving memory while improving database performance by automatically
provisioning SGA memory based on database workload, not tedious guesswork.
Using the Automatic Database Diagnostic Monitor (ADDM) 3
Practicing Oracle DBAs know how critical it is to collect timely database statistics
so the Oracle optimizer performs efficiently. In Oracle Database 10g, there is a new
feature, the automatic optimizer statistics collection, in which Oracle itself automatically
schedules the statistics collection, using the new database Scheduler feature. DBAs
have always been beset with the problem of which tables to analyze and how often.
Now, in Oracle Database 10g, you simply trust Oracle to decide for you.
In Oracle9i, you first encountered Automatic Undo Management (AUM). In Oracle
Database 10g, there are enhancements to this feature, including the interesting new
option of guaranteed undo retention. Using this new undo feature, you can virtually
rule out any ORA-1555 (snapshot too old) errors.
In this chapter, our focus is on the exciting automatic management features
introduced in the Oracle Database 10g Server. Let’s start our discussion of Oracle
Database 10g’s automatic management features with a description of the ADDM
feature.
■ Using the Automatic Database Diagnostic Monitor (ADDM)

■ Using Automatic Shared Memory Management
■ Using automatic optimizer statistics collection
■ Using automatic undo retention tuning
Using the Automatic Database

Diagnostic Monitor (ADDM)
As an Oracle DBA, you know how difficult it is sometimes to figure out why your database
performance isn’t up to par. You may need to hunt down the causes, but too often, you
are likely to mistake the symptoms for the causes. Correctly diagnosing performance
problems is the key to efficient performance tuning.
Traditionally, organizations have spent considerable amounts of effort on performance
tuning, which usually tends to be quite laborious and not an exact science. Oracle
Database 10g changes all that. It provides you with very powerful and accurate automatic
performance-tuning capabilities. The heart of the new automatic performance tuning

is the new statistics collection facility, the Automatic Workload Repository (AWR),
which automatically saves crucial performance information in the new mandatory
SYSAUX tablespace.
By default, the AWR collects new performance statistics in the form of a snapshot
on an hourly basis and saves the snapshots for seven days before purging them. These
snapshots of database activity include resource-intensive SQL statements. The
Automatic Database Diagnostic Monitor (ADDM) runs automatically every hour,
after the AWR takes a new snapshot. The ADDM uses the AWR performance
snapshots to locate the root causes for poor performance and provides recommendations
for improving performance.
The AWR saves all historical performance data, so you don’t need to worry about
being able to reproduce a performance problem. Every time the AWR takes a snapshot
of the database, which is hourly by default, the ADDM runs automatically and analyzes
the key data gathered by the AWR. You can then go to the OEM Database Control
to view the results, or even view them from a SQL*Plus session with the help of an
Oracle-supplied SQL script.
The ADDM runs automatically, although you
can also manually invoke the tool to investigate
The results of the AWR problems that occur in between the scheduled
statistics collection, including the snapshots, snapshots. As the DBA, you are relieved of
are stored in the SYSAUX tablespace. Oracle the responsibility of catching a problem at the
stores the ADDM analyses in the same right time to collect statistic, since the ADDM
tablespace as well. automatically analyzes performance data for you.
The Goal of the ADDM

The entire rationale behind the work of the ADDM is to reduce a key database metric
called DB time, which stands for database time (in microseconds) spent actually processing
user’s requests. DB time is the total time the database is spending on processing user
requests.
The DB Time Variable

The DB time variable includes only the cumulative amount of time spent on actual
database calls (at the user level) and doesn’t include time spent on background processes.
DB time includes both the wait time and processing time (CPU time). DB time doesn’t
include the idle time incurred by your processes. For example, if you spend 30 minutes
connected to the database and you’re idle for 28 of those minutes, then DB time is
only 2 minutes.
If a problem is contributing to inappropriate or excessive DB time, the ADDM
automatically flags it as an issue that needs your attention. If there is a problem
in your system, but it doesn’t contribute significantly to the DB time variable, the
ADDM will simply ignore the problem. Thus, the entire functioning of the ADDM
revolves around the single mantra: reduce DB time. By relentlessly focusing on the
reduction of database time (DB time), the ADDM’s aim is to increase the throughput
of your database, thus serving more users with the same amount of resources.
Problems That the ADDM Diagnoses

The ADDM analyzes the AWR snapshots periodically and comes up with performance
recommendations, usually quantified in terms of expected benefit of various actions.
Following are some of the key problems that the ADDM diagnoses:
■ Configuration issues
■ Improper application usage
■ Expensive SQL statements
■ I/O performance issues
■ Locking issues
■ Excessive parsing
■ CPU bottlenecks
■ Undersized memory allocation
■ Connection management issues, such as excessive logon/logoff statistics
You may be wondering why you shouldn’t just use the well-known STATSPACK
utility to gather performance-related data. For one thing, STATSPACK has too
much information, not all of which is critically important to fixing critical performance
problems that are occurring right now. The ADDM uses a sophisticated, new time
statistics model in Oracle Database 10g, which is highly effective in determining
where time is spent in the database. This new time statistics model enables Oracle to
focus on only the most critical performance problem areas. DB time is the key metric
against which the ADDM judges all performance problems. If a problem exceeds the
threshold for DB time, the ADDM tags it as a top performance issue; otherwise, it
leaves it alone as nonproblem area.
The New Time Model

The ADDM bases most of its performance recommendations on the basis of time model
statistics, the most important of which is the new DB time statistic. The DB time statistic,
as I explained in the previous section, represents the true workload of your database,
because it shows the total time spent in making database calls. In addition to DB time,
time model statistics also provide timings relating to logon statistics and parse activity.
Using decades of its performance-tuning expertise, Oracle has come up with a new and
more accurate time model to accurately diagnose performance issues.
Two new database views, V$SESS_TIME_MODEL and V$SYS_TIME_MODEL,
help you to manage these new time-based performance statistics.
The V$SYS_TIME_MODEL view provides the accumulated time statistics for various
operations in the entire database. This view shows time in terms of the number of
microseconds the database has spent on a specific operation. The following query
demonstrates the kind of operations for which the V$SYS_TIME_MODEL view
holds statstics.
SQL> select stat_name ,value from V$SYS_TIME_MODEL
STAT_NAME VALUE
---------------------------------------------------------------- ----------
DB time 3175312459
DB CPU 473486465
background elapsed time 7152613400
background cpu time 445371822
sequence load elapsed time 2780225
parse time elapsed 1003246942
hard parse elapsed time 969141891
sql execute elapsed time 2921215454
connection management call elapsed time 49093303
failed parse elapsed time 278729
failed parse (out of shared memory) elapsed time 0
hard parse (sharing criteria) elapsed time 7446158
hard parse (bind mismatch) elapsed time 3152674
PL/SQL execution elapsed time 327980460
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 267986126
Java execution elapsed time 0
17 rows selected.
SQL>
The V$SESS_TIME_MODEL view is similar to the V$SYS_TIME_MODEL view

and provides the same types of time statistics, but at a session level, instead of the
system level.
Benefits Provided by the ADDM

The ADDM bases its recommendations on a holistic approach, with time spent on
database activities as its main focus. Here are some of the important benefits of using
the ADDM:
■ It identifies the root causes of performance problems, instead of merely

focusing on the symptoms. The ADDM will automatically capture highly
resource-intensive SQL statements.
■ It produces automatic performance diagnostic reports at periodic intervals.
■ You’ll experience very little performance overhead when using the tool.
A typical ADDM analysis takes only three or four seconds.
■ The ADDM points out nonproblem areas, so you don’t waste your efforts
poking around in areas with little bang for the buck.
■ Performance diagnosis is based on decades’ worth of Oracle’s expert tuning
knowledge.
Types of ADDM Recommendations

The ADDM may propose several recommendations for the same performance
problem. The recommendations may include the following:
■ Hardware changes ADDM may recommend that you add more CPUs to
your system. It may also recommend that you change the way you configure
your I/O subsystem.
■ Database and application changes The ADDM may find, for example, that
your database is performing an excessive amount of parses due to the failure
to use bind variables. In a case like this, it may recommend that you change
your initialization parameter CURSOR_SHARING to a setting of FORCE,
rather than rewrite your application code. In some other cases, the ADDM
may recommend that you go ahead and rewrite the application code so you
use bind variables.
■ Space configuration changes The ADDM may sometimes make
recommendations like switching to the new Automatic Storage Management
(ASM) to fix certain performance problems.
■ Using management advisors The ADDM may recommend several changes
that you can implement immediately to improve database performance.
However, in some cases, it may recommend that you use a management

advisor—like the SQL Tuning Advisor, Undo Advisor, or Segment Advisor—
to gain an in-depth knowledge of the performance problems. For example,
the ADDM may tag certain high-load SQL statements as candidates for
automatic SQL tuning, using the Automatic Tuning Optimizer (I’ll explain
this in Chapter 5).
Automatic Management of the ADDM

Oracle manages the ADDM with the help of a brand-new background process in Oracle
Database 10g databases: the MMON. The MMON process schedules the automatic
running of the ADDM. Each time the AWR takes a snapshot (every 60 minutes, by
default), the MMON process asks the ADDM to analyze the interval between the last
two snapshots it gathered. This is the default behavior of the ADDM performance analysis.
Where does the ADDM store its analysis results? Not surprisingly, the ADDM
stores the results in the AWR itself. You can use the OEM Database Control to
view the ADDM’s performance analysis and action recommendations.
Configuring the ADDM

It might surprise you to find out that you don’t need to go through an arduous setup or
configuration exercise for using the amazingly powerful ADDM feature. Oracle enables
the ADDM feature by default. Your only task is to make sure that the initialization
parameter STATISTICS_LEVEL is set to TYPICAL or ALL, in order for the AWR
to gather its cache of performance statistics. If you set STATISTICS_LEVEL to
You must set the TIMED_STATISTICS parameter to TRUE

initialization parameter STATISTICS_ in order to collect timed performance
LEVEL to TYPICAL or ALL in order to use statistics. Oracle strongly recommends the
the ADDM. If you set STATISTICS_LEVEL use of the TYPICAL setting, which it deems
to BASIC, you cannot use the ADDM. In sufficient for all your day-to-day needs.
addition, you won’t be able to use several BASIC cripples your tuning efforts, while
other important Oracle diagnostic features. ALL will have a performance impact on
For example, if STATISTICS_LEVEL is set your system.
to BASIC, you must explicitly set the
BASIC, you can still manually use the AWR to collect statistics by using the DBMS_
WORKLOAD_REPOSITORY package. However, you will not be able to collect several
important types of performance statistics.
You can control the amount of statistics collected by the AWR by adjusting either
or both of two variables:
■ Snapshot interval The default snapshot interval is 60 minutes, and Oracle

recommends that you use the default interval for your everyday needs. Remember
that flushing statistics involves a performance hit, however minor. Oracle’s
assumption is that once an hour is frequent enough for diagnosis and infrequent
enough not to influence performance. The DBA must decide whether he or
she agrees with this assumption.
■ Snapshot-retention period The snapshot-retention period is the length of
time for which the AWR retains all snapshots. The default retention period
is 7 days. After the snapshot-retention period expires, Oracle will automatically
purge the outdated snapshots from the AWR.
You can modify the length of the snapshot interval and snapshot retention by using
the INTERVAL and the RETENTION parameters of the MODIFY_SNAPSHOT_
SETTINGS of the DBMS_WORKLOAD_REPOSITORY package. Chapter 4 provides
examples showing you how to manage AWR historical data retention by modifying
the INTERVAL and RETENTION parameters.
The ADDM runs automatically after each AWR snapshot. If you don’t like the
default (60-minute) interval, you can change it.
Determining Optimal I/O Performance

How does the ADDM know what is optimal I/O performance? If your I/O system performs
at a certain speed, your system can read a database block in a specific number of
milliseconds. The ADDM makes the critical assumption that the average time to
read a database block is 10 milliseconds. The DBIO_EXPECTED parameter (not
an initialization parameter) indicates your I/O performance, and by default, Oracle
assumes this parameter’s value is 10 milliseconds.
You can find out the current value of the DBIO_EXPECTED parameter by querying
the DBA_ADVISOR_DEF_PARAMETERS view in the following way:
SQL> select parameter_value
2 from dba_advisor_def_parameters
where advisor_name='ADDM'
4* AND parameter_name='DBIO_EXPECTED';
PARAMETER_VALUE
----------------
10000
SQL>
What do you do if you think your I/O subsystem is fast, and performs a database
block in only 6 milliseconds, or is slow and takes longer? You can use the DBMS_
ADVISOR package to change the default value of the DBIO_EXPECTED parameter,
as I’ll explain later in this chapter, in the “Using the DBMS_ADVISOR Package to
Manage the ADDM” section.
Running the ADDM

The new Oracle background process, MMON, schedules the ADDM to run every time
the AWR collects its most recent snapshot. Thus, Oracle will automatically generate
ADDM reports throughout the day.
You can also perform an ad hoc ADDM analysis any time, to find out details
about a performance problem that’s currently occurring in the database. Remember
that the AWR will be taking periodic snapshots of database performance statistics
throughout the day. You can request that the ADDM analyze the data that falls
between any two snapshots. Note that the two beginning and ending snapshots
don’t need to be consecutive. The only requirements regarding the selection of
the AWR snapshots are the following:
■ The snapshots must be clean, without any errors.

■ There shouldn’t be a database shutdown during the two snapshots.
The easiest way to view the ADDM’s findings is to use the OEM Database Control.
You can get to the ADDM by clicking the Advisor Central link first, and then choosing
ADDM. Once you reach the ADDM page, you can view the latest performance findings
or start a new ADDM task.
Oracle runs the ADDM choose. You may want to run the ADDM
automatically every hour, following the manually either because an alert recommends
AWR snapshot collection. You may, that you do so or because you want an
however, run it manually whenever you ADDM analysis across multiple snapshots.
You can also obtain complete ADDM reports by running the Oracle-provided
SQL script addmrpt.sql, which you’ll find in your ORACLE_HOME/rdbms/admin
directory. As explained earlier, the AWR will take snapshots of database performance
at specified intervals. Assuming the default of one-hour intervals, you’ll have as
many snapshots in the AWR as the number of hours since you started the database
instance.
In the following example, the database was started sometime after 10:00 A.M.
and there are four consecutive hourly snapshots in the system. Note that there is a
snapshot captured at 9:57 A.M., but I brought down the database after that. You can
compare two snapshots only if you don’t shut down the database in between. Why
is this so? The AWR holds only cumulative database statistics. Obviously, once you
shut down the database, all the cumulative data will lose its meaning.
In this example, I show how to get the ADDM report for the period between
10:00 A.M. and 1:00 P.M. To do so, I need to specify the snapshot numbers pertaining
to the 10:00 A.M. and 1:00 P.M. snapshot collection times. The addmrpt.sql script
provides this information. In the script, notice that the snapshot IDs 258 (captured
at 10:00 A.M.) and 261 (captured at 1:00 P.M.) will contain the performance statistics
for the period between 10:00 AM and 1:00 PM. Therefore, I provide the snapshot IDs
258 and 261 in response to the prompts for the beginning and ending snapshot IDs.
SQL> @c:\oracle\product\10.1.0\Db_1\RDBMS\ADMIN\addmrpt.sql
DB Id DB Name Inst Num Instance
----------- ------------ -------- ------------
877021568 NINA 1 nina
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.
Listing the last 3 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
nina NINA 257 21 Apr 2004 09:27 1
258 21 Apr 2004 10:00 1
259 21 Apr 2004 11:00 1
260 21 Apr 2004 12:00 1
261 21 Apr 2004 13:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 258
Begin Snapshot Id specified: 258
Enter value for end_snap: 261
End Snapshot Id specified: 261
Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is addmrpt_1_258_261.txt. To use this name
press <return> to continue, otherwise enter an alternative.
Enter value for report_name:
Using the report name addmrpt_1_258_261.txt
Running the ADDM analysis on the specified pair of snapshots ...
For space reasons, I am not showing the entire ADDM report. The textual report
that the addmprt.sql generates is identical to the detailed report that you can get
using the OEM Database Control’s ADDM page. You’ll see this report later in this
chapter, in the section “Viewing Detailed ADDM Reports.”
The ADDM doesn’t always offer you a direct recommendation for a performance
problem that it encounters. A key aspect of an ADDM analysis is that. In many
cases, it recommends that you use one of Oracle’s built-in advisors, like the
SQL Tuning Advisor, to analyze a complex performance situation.
The ADDM Analysis

The ADDM presents the results of its analysis to you in a standard format each time.
Each ADDM analysis finding consists of the following four components:
■ The definition of the problem itself

■ The root cause of the performance problem
■ Recommendation(s) to fix the problem
■ The rationale for the proposed recommendations
By navigating to the Performance Details page of the ADDM using the OEM
Database Control, you can see all the problems and the recommendations for fixing
them. For each problem in the report, ADDM displays each of its performance findings
in the form of three columns: the Impact column, the Finding column, and the
Recommendations column.
The Impact column lists the performance problems in the order of their impact on
their system. The Impact column is thus very important, because you can start working
on fixing the most serious problem that is affecting current database performance. You
may think parsing issues are more serious than, say I/O-related issues, but if the Impact
column ranks I/O problems as number one, you should attend to the I/O problems first.
Oracle enables the ADDM by default, as long as you set the STATISTICS_
LEVEL parameter to TYPICAL or ALL. You can shut the ADDM down by simply
setting the STATISTICS_LEVEL parameter to BASIC. However, remember
that this step will also disable many automatic performance tuning and statistics
gathering activities of Oracle Database 10g.
Let’s look at a typical ADDM problem analysis and list of recommendations. This
analysis is from the OEM Database Control’s ADDM page.
Problem Recommendation
The buffer cache was Increase SGA target by increasing the value of parameter SGA_TARGET
undersized causing significant by 256M.
additional read I/O.
The throughput of the I/O Consider increasing the throughput of the I/O subsystem. Oracle’s recommended
subsystem was significantly solution is to stripe all datafiles using the same methodology. You might also
lower than expected. need to increase the number of disks for better performance. Alternatively,
consider using Oracle’s ASM solution.
Hard parsing of SQL Here, the ADDM did not make any recommendations. By clicking the
statements was consuming Additional Information button, I found that ADDM didn’t see any reason
significant database time. to tinker with the parsing issue, for the following reasons:
Hard parses due to cursor environment mismatch were not consuming
significant database time.
Hard parsing SQL statements that encountered parse errors was not consuming
Parse errors due to inadequately sized shared pool were not consuming
Hard parsing due to cursors getting aged out of shared pool was not consuming
Hard parses due to literal usage and cursor invalidation were not consuming
Database writers (DBWR) Consider increasing the number of database writers (DBWR) by setting the
were unable to keep up with parameter DB_WRITER_PROCESSES.
the demand for free buffers.
Time spent on the CPU by Tune the PL/SQL block with SQL_ID “2b064ybzkwf1y.” Refer to the
the instance was responsible “Tuning PL/SQL Applications Chapter of Oracle’s “PL/SQL User’s Guide
for a substantial part of and Reference.”
database time.
Viewing Detailed ADDM Reports

If you want to view a Detailed ADDM Report for any given ADDM task, all you need
to do is click the View Report button on the ADDM main page in the Database Control.
You can then view the results, or if you wish, save the results to a file or print the report.
Note that in addition to the information about impact, problem, and recommendations
that you can gain from the main ADDM page, the detailed report includes a listing
of the symptoms that led to each particular finding. In addition, for some problems,
the ADDM report also includes a Rationale section that details the reasoning for its
action recommendations.
Here is an example of a detailed report:
DETAILED ADDM REPORT FOR TASK 'ADDM:877021568_1_259' WITH ID 1052
-----------------------------------------------------------------
Analysis Period: 21-APR-2004 from 10:00:08 to 11:00:40
Database ID/Instance: 877021568/1
Database/Instance Names: NINA/nina
Host Name: NTL-ALAPATISAM
Database Version: 10.1.0.2.0
Snapshot Range: from 258 to 259
Database Time: 357 seconds
Average Database Load: .1 active sessions
-----------------------------------------------------------------------------
FINDING 1: 87% impact (311 seconds)
-----------------------------------------------------------------------------
The throughput of the I/O subsystem was significantly lower than expected.
RECOMMENDATION 1: Host Configuration, 87% benefit (311 seconds)
ACTION: Consider increasing the throughput of the I/O subsystem.
Oracle's recommended solution is to stripe all data file using the
SAME methodology. You might also need to increase the number of disks
for better performance. Alternatively, consider using Oracle's
Automatic Storage Management solution.
SYMPTOMS THAT LED TO THE FINDING:
Wait class "User I/O" was consuming significant database time. (100%
impact [467 seconds])
Notice that Recommendation 1 is shown as providing an “87% benefit.” Benefit

here refers to the reduction in DB time due to the recommendation’s implementation.
Thus, the ADDM is telling you that you can save a maximum of up to 87 percent of
the total DB time by following the proposed solution.
At the end of the Detailed ADDM Report, you’ll see a section called Additional
Information, which usually shows insignificant wait information. Here is a typical
list of findings under the Additional Information heading:
Wait class "Administrative" was not consuming significant database time.

Wait class "Application" was not consuming significant database time.
Wait class "Cluster" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Concurrency" was not consuming significant database time.
Using the DBMS_ADVISOR Package to Manage the ADDM

The new DBMS_ADVISOR package helps you manage the attributes of the ADDM
tool, as well as perform jobs like creating tasks and retrieving ADDM reports using SQL.
The DBMS_ADVISOR package is part of the Server Manageability Suite of advisors,
which is a set of rule-based expert systems that identify and resolve performance problems
of several database components. This set of advisors helps you manage performance
issues relating to various database components in Oracle Database 10g. The ADDM
is one of this set of advisors, and you’ll learn more about the other advisors in later
chapters.
The DBMS_ADVISOR package requires the ADVISOR privilege.
The following are a few of the main procedures and functions of the DBMS_
ADVISOR package. Note that these program components apply not just to the
ADDM, but also to all the other database advisors.
■ You use the CREATE_TASK procedure to create a new advisor task.

■ The SET_DEFAULT_TASK procedure helps you modify default values
of parameters within a task.
■ The DELETE_TASK procedure deletes a specific task from the repository.
■ The EXECUTE_TASK procedure executes a specific task.
■ The GET_TASK_REPORT displays the most recent ADDM report.
■ The SET_DEFAULT_TASK_PARAMETER procedure modifies a default
task parameter.
You can use the SET_DEFAULT_TASK procedure to modify default values of

ADDM parameters like DBIO_EXPECTED (discussed earlier in the “Determining
Optimal I/O Performance” section). The following example illustrates the technique:
SQL> sho user
USER is "SYS"
SQL> exec DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(-
> 'ADDM', 'DBIO_EXPECTED', 6000);
The GET_TASK_REPORT procedure in the DBMS_ADVISOR package enables

you to get XML, text, or HTML reports for a specified task, including an ADDM
task. Here is the structure of the GET_TASK_REPORT procedure:
DBMS_ADVISOR.GET_TASK_REPORT (
task_name IN VARCHAR2,
type IN VARCHAR2 := 'TEXT',
level IN VARCHAR2 := 'TYPICAL',
section IN VARCHAR2 := 'ALL',
owner_name IN VARCHAR2 := NULL)
RETURN CLOB;
The possible values for the TYPE parameter are TEXT, XML, and HTML. The
possible values for the LEVEL parameter, which stands for the initialization
parameter STATISTICS_LEVEL, are TYPICAL, ALL, and BASIC. Remember
that setting the STATISTICS_LEVEL parameter to BASIC will mean that you
can’t use the ADDM tool.
Here’s an example that shows how to use the GET_TASK_REPORT procedure to
obtain an ADDM report (I am abbreviating the ADDM report shown in the output;
it is the same report you saw earlier through the OEM Database Control and the use
of SQL scripts):
SQL> select DBMS_ADVISOR.GET_TASK_REPORT('ADDM:877021568_1_252')
2 from dba_advisor_tasks
3 where task_id = (select max(t.task_id)
4 from dba_advisor_tasks t,
5 dba_advisor_log l
6 where t.task_id = l.task_id AND
7 t.advisor_name='ADDM' AND
8* l.status='COMPLETED');
DBMS_ADVISOR.GET_TASK_REPORT('ADDM:877021568_1_252')
----------------------------------------------------------------------------
DETAILED ADDM REPORT FOR TASK 'ADDM: 877021568_1_252' WITH ID 1002
----------------------------------------------------------------------------
Analysis Period: 14-APR-2004 from 05:00:37 to 06:00:07
Database ID/Instance: 877021568/1
The analysis of I/O performance is based on the default assumption that the
average read time for one database block is 10000 micro-seconds.
DBMS_ADVISOR.GET_TASK_REPORT('ADDM:877021568_1_252')
SQL>
To produce this ADDM report, you don’t need to specify any snapshots. How
then, does Oracle know which snapshots it should consider for preparing its report?
Well, when you use the DBMS_ADVISOR package to produce an ADDM report,
Oracle will always use the data that it collects between the two most recent snapshots.
Using Automatic Shared Memory Management 17
Remember that there are (by running the addmrpt.sql script), or the
three ways to retrieve an ADDM analysis DBMS_ADVISOR package (by running
report: you can use the OEM Database the GET_TASK_REPORT procedure).
Control interface, the SQL*Plus interface
Using ADDM-Related Dictionary Views

Following are some of the new views that’ll help you in dealing with the ADDM:
■ The DBA_ADVISOR_RECOMMENDATIONS view shows the results of analyzing

all the recommendations in the database.
■ The DBA_ADVISOR_FINDINGS view shows the findings of all the advisors
in your database.
■ The DBA_ADVISOR_RATIONALE view shows the rationale behind all the
recommendations.
Using Automatic Shared Memory Management

Every DBA knows how hard it is sometimes to adjust the SGA, which is the memory
that Oracle assigns to every instance to hold data and control information. You may
have a situation where online transaction processing (OLTP) transactions dominate
the database all day, and you run heavy-duty batch jobs during the night. In cases like
this, you may need more allocation for the buffer cache during the daytime and an
increase in the large pool component of the SGA for the nightly batch jobs.
You can, of course, dynamically change several SGA components, as well as use
scripts to change SGA allocations before and after batch jobs, but the fact remains
that it is you, the DBA, who is directly responsible for adjusting the SGA components
to match the needs of the database instance. Problems like the ORA-4031 (out of
shared pool memory) error are all too common, forcing you to juggle with the manual
tuning parameters. You may also face a situation where you might be assigning too
much SGA memory, thus wasting precious resources, or too little memory, which
affects database performance.
In Oracle Database 10g, TARGET parameter to 0 or the WORKAREA_

the database enables the Automatic PGA SIZE_POLICY parameter to MANUAL,
Memory Management feature by default. Oracle doesn’t use Automatic PGA Memory
However, if you set the PGA_AGGREGATE_ Management.
In Oracle Database 10g, for the first time, you can make the often-tricky issue of
shared memory management completely automatic. This is one of the more significant
enhancements of Oracle Database 10g, and it contributes significantly to Oracle’s
goal of automatic database self-management. Oracle will automatically allocate and
deallocate memory for each of the memory pools, based on changing database workloads.
Oracle will use internal views and statistics to decide on the best way to allocate
memory among the SGA components. Automatic Shared Memory Management
provides you the following benefits:
■ Less chance of running out of shared pool memory

■ Optimal use of available memory
■ Significant performance improvement because memory allocation keeps step
with fluctuations in the database workload
Before we delve into the new Automatic Shared Memory Management feature of
Oracle Database 10g, let’s quickly review the manual memory management feature,
which is still available for you to use.
Manual Shared Memory Management

Oracle will still let you manage the shared memory components manually. Under
traditional shared memory management, you need to set several initialization parameters
for the various components of the SGA. These dynamic memory parameters are DB_
CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL, JAVA_POOL_SIZE, and
STREAMS_POOL_SIZE.
You can limit the size of the total amount of memory used by Oracle by setting
the SGA_MAX_SIZE parameter in your initialization file. When you do this, Oracle
will limit the sum of the various components of the SGA to the value you specify. If
you don’t specify an explicit SGA_MAX_SIZE parameter, it defaults to the sum of
All SGA automatic You must, therefore, make sure to increase

components behave the same as in the size of the SHARED_POOL_SIZE
previous versions, except the shared parameter when you are upgrading to
pool component, which you set with the Oracle Database 10g. You can find the
initialization parameter SHARED_POOL_ appropriate value of your new SHARED_
SIZE. In Oracle Database 10g, the value POOL_SIZE parameter before the upgrade
of the SHARED_POOL_SIZE parameter by using the following query:
includes the internal overhead allocations
Select SUM(bytes)/1024/1024 from V$SGASTAT
for metadata such as the various data Where pool = 'shared pool';
structures for sessions and processes.
the actual size of all the SGA components. If you set the SGA_MAX_SIZE to a
value smaller than the sum of all the SGA components, Oracle will automatically
bump up the SGA_MAX_SIZE parameter’s value to the sum of the memory assigned
to all the components.
Automatic Memory Management

In the manual memory management model, you need to calibrate the individual
components of the SGA. To let Oracle automatically manage the memory allocations
to the individual components of the SGA, you need to set the new initialization
parameter SGA_TARGET. By default, the SGA_TARGET parameter is set to zero.
Once you provide a nonzero value for the SGA_TARGET parameter, Automatic
Shared Memory Management is enabled.
In order to use Automatic Shared Memory Management, you should first

set the initialization parameter STATISTICS_LEVEL to its default value of
TYPICAL or ALL. Oracle doesn’t populate the V$SHARED_POOL_ADVICE
and the V$DB_CACHE_ADVICE views if the STATISTICS_LEVEL parameter
is set to BASIC.
The new Oracle Database 10g background process MMAN performs all the memory
resizing necessary for the Automatic Shared Memory Management feature. The MMAN
process constantly monitors the workload of the database and adjusts the size of the
individual memory components accordingly.
Two Sets of SGA Parameters

As you know, Oracle’s SGA is not one big chunk of memory. Rather, it consists of several
specific components like the buffer cache and shared pool. When you use Automatic
Shared Memory Management by setting the SGA_TARGET parameter to a nonzero
value, the database doesn’t manage all of the shared memory components. Although
we call it Automatic Shared Memory Management, the SGA has both an automatic
and a manual set of components.
Under Automatic Shared Memory Management, the database manages the
following four major components of the SGA, also known as the auto-tuned SGA
parameters:
■ Buffer cache (DB_CACHE_SIZE)

■ Shared pool (SHARED_POOL_SIZE)
■ Large pool (LARGE_POOL_SIZE)
■ Java pool (JAVA_POOL_SIZE)
It is important to understand that even under Automatic Shared Memory

Management, you still need to configure any SGA component other than the four
auto-tuned components. Following are the manually sized components of the SGA:
■ Redo Log Buffer

■ The KEEP and RECYCLE buffer caches (if specified)
■ The nonstandard block size buffer caches (if specified)
■ The new Streams pool SGA component
■ The new Oracle Storage Management (OSM) buffer cache, which is meant
for the optional ASM instance
Note that in addition to the automatic and manual components, Oracle also assigns
a certain amount of memory to the fixed SGA, which contains database and instance
state information useful to the background processes. The fixed SGA doesn’t contain
any user data.
It is important to understand that the SGA_TARGET parameter shows the sum
of all SGA components, not just the automatically managed memory components.
Interestingly, even under Automatic Shared Memory Management, the manually
sized components get the first crack at the SGA allocated by the SGA_TARGET
parameter. Oracle will first subtract the total value of all the manually sized memory
components from SGA_TARGET, and then allocate the remainder of the memory
among the four auto-tuned memory

components—shared pool, default buffer
cache, large pool, and Java pool. Let’s use a
Know that the SGA_ simple example to demonstrate this extremely
TARGET parameter includes the entire important point.
memory of the SGA, including the “overhead Let’s say that you set the SGA_TARGET
component”—memory for the internal and parameter to 1000MB. You want to use multiple
fixed SGA. block sizes in your database, so you then set the
following values (both of these parameters
belong to the manually sized group of SGA parameters) for the DB_nK_CACHE_
SIZE parameters:
DB_4K_CACHE_SIZE=100MB
DB_8K_CACHE_SIZE=200MB
In this case, you’ll have a total of 700MB (SGA_TARGET – (DB_4K_CACHE_

SIZE + DB_8K_CACHE_SIZE)) left for Oracle to automatically allocate among
the four auto-tuned SGA parameters.
Once you set the SGA_TARGET variable to a nonzero value, the database will
automatically manage shared memory (only the four automatically tuned components).
But how does Oracle know how much memory to allocate for each of the four auto-
tuned memory components? Well, the default values for these four components
begin at zero. Oracle uses an internal memory-tuning algorithm, based on database
workload, to allocate memory to each of the auto-tuned memory components.
Oracle will gradually increase the memory allocated to each component as necessary
over time, eventually stabilizing their level at an optimal allocation. Oracle recommends
that you try not to set a minimum for any these components, since that would interfere
with the database’s ability to allocate memory optimally.
If Oracle is automatically managing your SGA, can you influence the sizes of the
automatically tuned SGA components? If you know that you will have serious problems
if you start your database instance with a zero-valued shared pool, for example, you
can set specific sizes for any of the four auto-tuned components. Oracle will ensure
that the memory allocation to these components will never fall below the minimum
allocations you made. For example, if you set the BUFFER_CACHE parameter to 100M
and the SHARED_POOL parameter to 400M, Automatic Shared Memory Management
will then use these two values as minimum levels for the two parameters.
For example, let’s say you assign the following values in the init.ora (or SPFILE):
SGA_TARGET=900M and SHARED_POOL_SIZE=400M. Then Oracle will never
allocate less than 400MB of memory for the shared pool. Oracle will have 500MB
(900 – 400) of SGA left for the other three auto-tuned parameters (of course, if you
assign any memory for the manually tuned parameters, you’ll be left with even less
than 500MB of SGA).
In summary, the two sets of SGA parameters work as follows:
■ Oracle may assign more, but not less than, the minimum values you assign
for the auto-tuned parameters.
■ Oracle cannot change the values of the manually sized components.
SGA_TARGET Parameter Size Limits

You set the initial size of the SGA_TARGET parameter in the initialization file. If this
is the first time you are using Automatic Shared Memory Management, you can quickly
arrive at a good approximation for the SGA_TARGET parameter by summing the value
of all the SGA components using the V$SGA view, as shown here:
SQL> select sum(value) from v$sga;
SUM(VALUE)
------------------
184549376
SQL>
Once you start the instance with a certain value for SGA_TARGET, you can
increase or decrease its size dynamically by using the alter system command:
SQL> alter system set sga_target=600M;
System altered.
SQL>
How high can you raise the SGA_TARGET parameter? The SGA_MAX_SIZE
parameter sets an upper bound on the value of the SGA_TARGET parameter. If
you haven’t specified an SGA_MAX_SIZE value, you can increase the value of the
The new SGA_TARGET minor component, which is the small

initialization parameter has two amount of SGA memory Oracle provides
major components: the automatically for internal allocations like fixed SGA (you
sized components and the manually sized can consider this an overhead component).
components. In addition, you have a third
SGA_TARGET parameter up to the maximum your particular operating system will

allow. Note that you may set the value of the SGA_TARGET parameter greater than
SGA_MAX_SIZE at startup time. In this case, Oracle automatically raises the value
of the SGA_MAX_SIZE parameter to match the higher value of the SGA_TARGET
parameter.
What is the minimum allowable value for the SGA_TARGET parameter? If you
set any of the manually sized components, you can lower the SGA_TARGET value
to the sum of the manually size parameters plus the sizes(s) of any auto-tuned parameters
for which you may have set minimum values. In addition, Oracle takes into account
factors like the number of CPUs on your server to arrive at the minimum allowable
value for the SGA_TARGET parameter.
Once you start your instance with a specific SGA_TARGET value, you can
dynamically switch to a manual memory management mode by simply setting the
value of the SGA_TARGET parameter to zero using the alter system command.
When you do this, the size of the four auto-tuned shared memory components will
remain at their present levels. Even if you had started the instance with a specific
value for some of the auto-tuned components, the current values are the ones that
the database will continue to assign to those parameters, once you decide to set
SGA_TARGET to zero. Of course, if you restart the instance, Oracle will assign
the component values that you specify in the init.ora or the SPFILE.
Although the SGA_MAX_SIZE value acts as the upper limit of the SGA_TARGET
parameter, not all operating systems are alike in this regard. On several UNIX platforms
that don’t support dynamic shared memory, Oracle recommends you do not set the
SGA_MAX_SIZE parameter, since those platforms use the entire physical memory
specified by SGA_MAX_SIZE immediately after instance startup. In these cases, it
doesn’t make any sense to set the SGA_TARGET to a value smaller than the value
specified for the SGA_MAX_SIZE parameter. In other platforms (Oracle specifies
SUN Solaris and Windows as examples), you can limit the total physical SGA use
to the value set by the SGA_TARGET parameter.
Oracle recommends that you do not manually set any of the (four)
automatically sized components, since it reduces the database’s ability
to adapt to database workload changes.
Let’s say you have the following situation:

SGA_MAX_SIZE=1024M
SGA_TARGET=512M
DB_CACHE_SIZE=128M
You can raise the SGA_TARGET setting up to a maximum of 1024M. You can
lower the SGA_TARGET value, but the DB_CACHE_SIZE value cannot go below
128M, since that is the minimum value for this parameter. That is, you can reduce
the SGA_TARGET value until one or more of the auto-tuned SGA components
reach their minimum size.
The SGA_TARGET Parameter and the SGA Components

When you change the value of the SGA_TARGET parameter, say increase it from
600M to 700M, all the manually configured SGA components will retain their old
values. Any changes you make to the SGA_TARGET parameter will affect only the
automatically configured SGA components.
The setting of the SGA_TARGET parameter influences the size of the various
SGA components. If you set the SGA_TARGET to zero explicitly, or just omit this
parameter altogether from your init.ora or SPFILE file, you must then configure the
four auto-tuned components yourself—in fact, these components aren’t auto-tuned
anymore! You specify sizes for these components in the init.ora (or SPFILE) file, and
you can use the alter system command to adjust their values after the instance
starts up.
Under Automatic Shared Memory Management, Oracle allocates minimum
values for all four auto-tuned memory components when the instance starts and
adjusts them as necessary. For example, suppose that you set SGA_TARGET to 125M
and you don’t manually size any auto-tuned or manually tuned memory components.
You can use the V$SGA_DYNAMIC_COMPONENTS view to see the values Oracle
currently assigns to the auto-tuned components.
SQL> select component,current_size
2* from v$sga_dynamic_components
COMPONENT CURRENT_SIZE
---------------------------------------------------------------- ------------
shared pool 37748736
large pool 4194304
java pool 4194304
DEFAULT buffer cache 75497472
KEEP buffer cache 0
RECYCLE buffer cache 0
DEFAULT 2K buffer cache 0
streams pool 0
OSM Buffer Cache 0

13 rows selected.
SQL>
As you can see, Oracle assigns initial values for all four auto-tuned parameters
using the SGA_TARGET value of 125M. You can also see that all manually sized
components have a value of zero (since no allocations have been made for these
components in the example).
Oracle doesn’t recommend that you set any of the auto-tuned parameters,
as it reduces the ability of Oracle to optimally allocate the SGA among the
various components.
If you look in the V$PARAMETER view, you may see different values for the auto-
tuned parameters. The values shown in that view are the minimum values of these
parameters, not the actual current values.
Let’s briefly review the important points regarding setting the sizes of the SGA_
TARGET parameter and the components of the SGA when you use Automatic
Shared Memory Management.
■ You can increase the size of the SGA_TARGET parameter until you reach
the SGA_MAX_SIZE parameter’s value.
■ If you increase the size of SGA_TARGET, you can allocate the additional
memory only among the auto-tuned parameters.
■ If you decrease the size of SGA_TARGET, Oracle will reduce the size of one
or more of the auto-tuned parameters. Oracle will not change the size of the
manually tuned SGA components.
■ You can reduce the SGA_TARGET parameter’s size until you reach the minimum
size for any of the auto-tuned components. You may specify this minimum size,
or Oracle may specify it based on the number of CPUs and other factors.
■ If you dynamically disable automatic SGA management (by setting SGA_
TARGET=0), the value of the auto-tuned parameters will not be set to zero.
These parameters will retain their current values. If the current values are
higher than any manually set minimums, the current values, not the minimum
values set in the initialization files, will prevail.
■ If you assign a minimum value for the auto-tuned components, that will act
as the lower bound for the SGA_TARGET parameter.
■ If you don’t specify a minimum value for an auto-tuned SGA component,

you’ll see zero values for this parameter in the V$PARAMETER view. The
default value of the four auto-tuned parameters is zero. In addition, the value
of the ISDEFAULT column will be TRUE.
■ If you specify a minimum value for any auto-tuned parameter, you’ll see that
value in the V$PARAMETER view.
■ If you decrease the size of any manually tuned component, Oracle will give
the additional memory released to one or more auto-tuned components.
■ If you increase the size of any manually tuned components, memory is reduced
from one or more auto-tuned components.
■ If you dynamically increase the size of one of the auto-tuned parameters, the
component’s size goes up immediately; the additional memory comes from
one of the other auto-tuned components. On the other hand, if you decrease
the size of one of the auto-tuned components, the component’s size will not
go down. The component’s size stays at the current level and will go down
only if Oracle deems it is good to lower the size later on.
SPFILE and Automatic Memory Management

You can store your initialization parameters in the traditional init.ora file or the newer
parameter file, SPFILE. Oracle recommends that you use the SPFILE because of the
inherent benefits that come with its use. Automatic Shared Memory Management is
a good example of why the SPFILE is a superior way of managing your initialization
parameters, compared to the init.ora file.
Under Automatic Shared Memory Management, the database determines the
ideal allocations of memory for the four automatic components. It does this with
the help of internal algorithms that continually analyze the nature of the database
workload. After you first incorporate Automatic Shared Memory Management,
Oracle doesn’t know the ideal levels for these components. It arrives at these after
a period of gradual calibration based on the nature of your workload.
What happens if you shut down the database instance? Well, if you are using the
init.ora file for specifying your initialization parameters, Oracle must go through the
laborious process of analyzing the workload again. If you use the SPFILE instead,
Oracle remembers the sizes of the four auto-tuned parameters across the instance
shutdown. Thus, when you restart the instance, you won’t start from scratch; Oracle
will start with the values the auto-tuned memory parameters had before you shut down
the instance.
Use the SPFILE (rather than the init.ora file) if you want Oracle to remember
the sizes of the automatically tuned memory components across an instance
shutdown.
Automatic SGA Management with OEM Database Control

You can use the OEM Database Control to configure Automatic Shared Memory
Management in your database, using the following steps:
1. Click the Administration link in the Database Control home page.

2. Under the Instance heading, click the Memory Parameters button.
3. Select Enable as your choice for the Automatic Shared Memory Management
option.
Figure 3-1 shows the Database Control page for modifying the SGA management
options.
FIGURE 3-1 Using the Database Control for specifying SGA management options
Using Automatic Optimizer Statistics Collection

In an Oracle database, the query optimizer plays a critical role in executing SQL statements
in the most efficient manner, using the least resources. You can execute a given SQL
statement in several ways, and it is the query optimizer’s job to provide the database
with the fastest and most efficient way to perform a database query.
To arrive at the “best” plan of execution for any SQL statement, the optimizer first
looks at the available access paths, join orders, and so on, and selects several candidate
execution plans for the query. Next, it figures out the cost of the alternative execution
plans, based on their usage of I/O, CPU, and memory. For this step, the optimizer
uses optimizer statistics—crucial statistics that tell the optimizer about the data
distribution and storage characteristics of tables and indexes in the database. Finally,
it compares the cost of the alternative plans and picks the one with the least cost.
Oracle recommends that you let the database collect optimizer statistics
automatically.
The optimizer relies on details about various objects to figure out the best plan
of execution, which usually is the execution plan with the least cost (I/O and CPU
cost mostly). The statistics that the Oracle optimizer relies on are called optimizer
statistics, which include the following items:
■ Table statistics, like the number of rows in a table and the average row length
■ Column statistics, like distinct values in a column and data distribution patterns
■ Index statistics include the number of levels in the index B-Trees
■ System statistics, including CPU and I/O performance
Oracle stores all of these optimizer statistics in its data dictionary for the optimizer’s
use. Since tables and indexes may change constantly in terms their data and other
properties, it is essential that you regularly refresh the optimizer statistics so they do
not become stale, and thus misleading.
Prior to Oracle8i, DBAs relied on the analyze table statements to gather
statistics for the Oracle optimizer. In Oracle8i, you had access to the new DBMS_STATS
package, which made the job of collecting statistics easier and more comprehensive.
Using Automatic Optimizer Statistics Collection 29
You used the DBMS_STATS package to collect the latest statistics for cost-based
optimization. Even with the availability of the DBMS_STATS package, it was still
your responsibility, as a DBA, to schedule the statistics collection jobs.
As you are aware, the Oracle optimizer cannot function correctly if you don’t feed
it correct and up-to-date statistics. Poor statistics mean nonoptimal execution plans,
leading to degradation in query performance. In Oracle Database 10g, for the first
time, you can automate the optimizer statistics collection process by allowing Oracle
to collect the statistics for you.
Before we go into the details of how automatic statistics collection works, remember
that statistics collection is just one part of query optimization. The choices you make
regarding the optimizer mode and any optimizer hints that you may use have a
significant bearing on the query optimizer’s
behavior. Thus, you need to focus on three
things—the optimizer mode, optimizer hints,
If you set the initialization and the collection of optimizer statistics—in
parameter STATISTICS_LEVEL to BASIC, order to set up efficient query optimization.
you disable the monitoring feature, and Let’s first quickly review the concepts of optimizer
thus turn off the automatic collection of mode and optimizer hints, before going on to
optimizer statistics. discuss how Oracle automatically collects the
optimizer statistics for you.
Optimizer Mode and Hints

In Oracle Database 10g, you can set the following goals for the query optimizer, using
the initialization parameter OPTIMIZER_MODE:
■ ALL_ROWS This is the default value. Using the ALL_ROWS goal will
ensure the best throughput, which means it will minimize resource use.
When you use the ALL_ROWS setting, Oracle uses a cost-based strategy
for all SQL statements in the session, regardless of the presence of statistics.
The ALL_ROWS setting will lead to the selection of an execution plan that
will return the full result set quickly.
■ FIRST_ROWS_n This value will ensure the minimization of response time
for returning the first n rows in the query output. Oracle uses a cost-based
approach regardless of the presence of optimizer statistics.
FIRST_ROWS_n will get something back quickly, although it may take longer
to retrieve the full set of data. Therefore, the FIRST_ROWS setting will favor
the use of indexes.
■ FIRST_ROWS If you use this value, Oracle will use a combination of

heuristics (rules of thumb) and a cost-based approach to get you the first
few rows in the query output. Note that the FIRST_ROWS setting exists
only for backward compatibility. Oracle recommends that you use the
FIRST_ROWS_n setting instead.
The OPTIMIZER_MODE settings determine the way the query optimizer will
perform optimization throughout the database. However, at times, due to lack of
accurate statistics, the optimizer can be mistaken in its estimates, leading to poor
execution plans. In cases like this, you can override this database optimization
setting at the individual SQL statement level, by using optimizer hints. Oracle
Database 10g also provides the new SQL profile feature, which enables you to collect
auxiliary information using sampling and partial execution techniques, thereby avoiding
the use of optimizer hints. Chapter 5 discusses the SQL profile feature in detail.
Now that we have reviewed optimizer modes and optimizer hints, let’s turn to a
discussion of the last factor that determines how a query optimizer works—optimizer
statistics collection.
How Automatic Optimizer Statistics Collection Works

Remember that regular collection of statistics is vital for the Optimizer to produce
correct and efficient execution plans. Oracle Database 10g introduces automatic
optimizer statistics collection, and Oracle recommends that you let the database
automatically gather the statistics rather than manually collect statistics yourself.
It’s very easy to enable automatic statistics collection in Oracle Database 10g—
Oracle automatically starts collecting statistics when you create the database. All
you need to do to make sure the automatic statistics collection process works is to
ensure that the STATISTICS_LEVEL initialization parameter is set to TYPICAL
or ALL. Oracle will use the DBMS_STATS package to collect optimizer statistics
on an automatic basis.
We’ll look at how Oracle sets up the automatic statistics collection process in
the following sections.
Using the Scheduler to Run DBMS_GATHER_STATS_JOB

Oracle automatically creates a database job called GATHER_STATS_JOB at database
creation time. You can verify that this automatic statistics collection job exists by running
the following query:
SQL> select job_name
2 from dba_scheduler_jobs
3* where job_name like 'GATHER_STATS%';
JOB_NAME
-----------------------------------------
GATHER_STATS_JOB
SQL>
Oracle schedules the GATHER_STATS_JOB job for automatic execution using

the new Scheduler tool. In Oracle Database 10g, the Scheduler replaces and enhances
the old job scheduling capability that used the DBMS_JOBS package, and I explain
it in detail in Chapter 7.
The Oracle Scheduler has two default operation windows:
■ The weeknight window covers the time between 10:00 P.M. and 6:00 A.M.,
Monday through Friday.
■ The weekend window covers the time between 12:00 A.M. Saturday and
12:00 A.M. Monday.
Together, the weeknight and the weekend windows are known as the maintenance
window. Of course, you can change the default timings of the maintenance window
as necessary. Oracle automatically schedules the GATHER_STATS_JOB job to run
when the maintenance window opens. Even if the job doesn’t complete before the
maintenance window is over, the job will run to completion.
If you want to stop the automatic gathering of statistics, you may do so by disabling
GATHER_STATS_JOB, as shown here:
SQL> begin
2 dbms_scheduler.disable('gather_stats_job');
3 end;
4 /
SQL>
The GATHER_STATS_JOB job calls the procedure DBMS_STATS.GATHER_

DATABASE_STATS_JOB_PROC to gather the optimizer statistics. The job collects
statistics only for objects that fall into one of the following classes:
■ Objects with missing statistics

■ Objects with stale statistics
The GATHER_DATABASE_STATS_JOB_PROC procedure is similar to the

GATHER_DATABASE_STATS procedure of the DBMS_STATS package. The
significant difference is that GATHER_DATABASE_STATS_JOB_PROC sets
priorities based on the DML activity in each table. The procedure will analyze the
objects that have had the most DML first, so that even if it doesn’t finish before
the window closes, the tables that require new statistics the most will have been
analyzed.
Using the Database Control to Manage

the GATHER_STATS_JOB Schedule
You can use the OEM Database Control to change the current schedule of the GATHER_
STATS_JOB schedule. Here are the steps:
1. From the Database Control home page, click the Administration tab.
2. Go to the Scheduler Group and click the Windows Link
3. Click the Edit button. You’ll then be able to edit the weeknight or the
weekend window timings.
Figure 3-2 shows the Scheduler Windows page of the Database Control, where
you can modify your operating windows for the Scheduler utility.
Remember that the have become stale. Oracle considers

GATHER_STATS_JOB job collects statistics statistics as being stale when the database
for an object only if there are no statistics modifies a significant proportion, usually 10
for that object or if the collected statistics percent of a table’s rows.
FIGURE 3-2 The Scheduler Windows page of the OEM Database Control
Table Monitoring
Oracle Database 10g uses an automatic table-monitoring mechanism (enabled by
default when STATISTICS_LEVEL is set to TYPICAL or ALL) to determine
whether a database object needs fresh statistics. Suppose that there are no changes
in any table data in your database over a certain period. In this case, all the previously
collected table statistics are still up-to-date, and you don’t need to collect statistics
again for this table. On the other hand, if a table is going through numerous update,
insert, and/or delete operations after the statistics are collected, the statistics are said
to become stale, since they don’t represent the true distribution of data in the table.
You cannot use the ALTER_DATABASE_TAB_MONITORING and ALTER_
SCHEMA_TAB_MONITORING procedures of the DBMS_STATS package to turn table
monitoring on and off at the database and schema level, respectively, because these
subprograms are deprecated in Oracle Database 10g. Oracle now automatically performs
the functions previously taken care of by these subprograms.
Manual Collection of Optimizer Statistics

Oracle Database 10g also allows you to gather statistics manually using the DBMS_
STATS package. The following are some situations when you must use manual rather
than automatic methods of collecting statistics:
■ When you use external tables

■ When you need to collect system statistics
■ To collect statistics on fixed objects, such as the dynamic performance tables
(for dynamic tables, you should use the GATHER_FIXED_OBJECTS_STATS
procedure to collect optimizer statistics)
■ Immediately after you run a bulk load job, since this will make your automatically
collected statistics unrepresentative
Let’s look at how you can use the DBMS_STATS package to perform several tasks
involving the collection and management of optimizer statistics.
Using the DBMS_STATS Package

The DBMS_STATS package helps you view, collect, and modify optimizer statistics.
The DBMS_STATS package has the following important procedures:
■ GATHER_TABLE_STATS collects all table statistics.

■ GATHER_INDEX_STATS collects all index statistics.
■ GATHER_SCHEMA_STATS collects statistics for all objects in a schema.
■ GATHER_DATABASE_STATS collects statistics for all database objects.
■ GATHER_DICTIONARY_STATS collects statistics for all data dictionary
objects.
■ GATHER_SYSTEM_STATS collects system statistics.
Here’s a simple example showing how to use the DBMS_STATS package to collect
an entire schema’s statistics:
EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS ('SALAPATI', DBMS_STATS.AUTO_SAMPLE_SIZE);
In the example, the AUTO_SAMPLE_SIZE parameter instructs Oracle to determine

the ideal sample size for each object, based on its size and other characteristics. By
setting the OPTIONS parameter (not shown in this example) to GATHER_STALE
or GATHER_AUTO, you can ensure that Oracle collects new statistics whenever it
encounters stale statistics for objects. (Note that GATHER_AUTO is the same as
GATHER_EMPTY plus GATHER_STALE.)
You can also use the DBMS_STATS package to delete, import, restore, and set
optimizer statistics that you have previously collected.
How often should you execute the DBMS_STATS package to collect statistics?
If your database performs only a small amount of DML activities, you may collect
statistics at relatively longer intervals, say weekly or monthly. However, if your
database objects go through constant change on a daily basis, you need to schedule
the statistics collection jobs much more frequently, say daily or even more often.
One of the best Oracle Database 10g new features is that with the combination of
GATHER_AUTO, AUTO_SAMPLE_SIZE, and scheduled GATHER_DATABASE_
STATS_JOB procedure, you can just let Uncle Oracle decide what and how much
to analyze, analyzing the important objects first.
Handling Volatile Tables by Locking Statistics

Let’s say you have a table that is truncated a few times during the day, each time
getting new rows by way of fresh data insertions. Also, let’s suppose you have another
table that is subject to numerous deletions throughout the day. Let’s assume you have
a nightly Scheduler job that performs automatic statistics collection. Clearly, in the
cases I just described, the nightly statistics collection for these tables would be, in all
likelihood, somewhat unrepresentative. What do you do under such circumstances?
Oracle Database 10g’s solution is to let you “lock” optimizer statistics for tables
and schemas—in essence, freezing the most representative optimizer statistics, so
the optimizer always uses these, rather than the
unrepresentative statistics caused by excessive
insert and delete operations. When you lock
When you lock a table’s statistics in this manner, you prevent the
statistics, Oracle automatically locks all automatic collection of statistics for the locked
the related statistics, such as column objects or schema. Thus, the statistics you’ve
statistics and index statistics, as well. locked will always be seen as the true statistics
for the table, regardless of data changes.
Use the following procedures in the DBMS_STATS package to lock and unlock
table and schema statistics.
■ LOCK_TABLE_STATISTICS
■ UNLOCK_TABLE_STATISTICS
■ LOCK_SCHEMA_STATISTICS
■ UNLOCK_SCHEMA_STATISTICS
Here’s an example where I lock the statistics for the test table in my schema:
SQL> execute DBMS_STATS.LOCK_TABLE_STATS('salapati','test');
SQL
If you have a volatile table without any statistics, you can lock the statistics.
You can lock a table with statistics or without statistics, using the LOCK_TABLE_
STATS procedure in both cases. You can also override statistics locking if necessary.
Locking Tables Without Statistics You can lock a table without any statistics,
by setting the statistics of a table to NULL. To set the statistics to NULL, you need to
first delete any existing statistics, and then lock the table. Here’s how to do this:
BEGIN
DBMS_STATS.DELETE_TABLE_STATS('HR','EMPLOYEES');
DBMS_STATS.LOCK_TABLE_STATS('HR',' EMPLOYEES');
END;
/
The LOCK* procedures either freeze the current statistics in place or keep the
statistics NULL (no collection of statistics will take place after deleting the
current statistics).
Locking Tables with Statistics Instead of setting statistics to NULL when

you lock a table, you can always save the same set of statistics, regardless of any
table row insert or delete operations. If you have a set of statistics that you consider
representative of the table when it’s fully loaded, you can lock the table with these
statistics in place, thus preventing the excessive insertions and deletions from
skewing the optimizer statistics. In this case, use just the LOCK_TABLE_STATS
procedure, as shown in the following example.
BEGIN
DBMS_STATS.LOCK_TABLE_STATS('HR',' EMPLOYEES');
END;
Overriding Statistics Locking In some cases, you may want Oracle to override
any existing locks you have imposed on the optimizer statistics. You can do so by using
the new FORCE argument with several procedures in the DBMS_STATS package.
For the following procedures, the default is FORCE=FALSE. When you set FORCE=
TRUE, they will behave as follows:
■ DELETE_SCHEMA_STATS will delete the statistics even if they are locked.

■ IMPORT_SCHEMA_STATS will ignore the statistics lock and import
statistics anyway.
■ RESTORE_SCHEMA_STATS will restore statistics even if they are locked.
■ SET_SCHEMA_STATISTICS will set the values even if the statistics
are locked.
Restoring Historical Optimizer Statistics

Suppose your newly collected optimizer statistics disappoint you, and you think an older
version of the statistics was giving you a lot better performance. What do you do under
such circumstances?
Fortunately, Oracle lets you automatically save all old statistics whenever your
refresh the statistics. Thus, it’s a simple matter to ask Oracle to revert to using an
older set of “good” statistics. You can restore any type of statistics by using the
appropriate RESTORE_*_STATS procedure.
For example, the RESTORE_TABLE_STATS
procedure is used to restore table statistics.
You can’t restore any Similarly, the RESTORE_DICTIONARY_
statistics you collect using the analyze STATS procedure helps you restore an older
command. You also can’t restore any user- version of the dictionary table statistics. Oracle
defined statistics. also has procedures for restoring statistics at the
schema, database, and system levels.
Two database views are critically useful when you want to restore older statistics:
DBA_OPTSTAT_OPERATIONS and DBA_TAB_STATS_HISTORY. The DBA_
OPTSTAT_OPERATIONS view contains a history of all optimizer statistics collections,
as shown in the following query:
SQL> select operation,end_time
2 from dba_optstat_operations;
OPERATION END_TIME
gather_database_stats(auto) 19-APR-04 10.04.59.321000 PM -05:00
set_system_stats 19-APR-04 01.44.53.098000 PM -05:00
SQL>
The DBA_TAB_STATS_HISTORY view contains a record of all changes made to

table statistics. By default, the DBA_TAB_STATS_HISTORY view saves the statistics
history for 31 days. Therefore, you can restore statistics to any time within the previous
31 days.
How long can you retain old statistics? As just stated, by default, Oracle will
save your statistics for a period of 31 days. However, by using the ALTER_STATS_
HISTORY_RETENTION procedure of the DBMS_STATS package, you can change
the default value of the statistics history retention interval.
If you have set your STATISTICS_LEVEL parameter to TYPICAL or ALL, Oracle
will automatically purge the old statistics. To perform a manual purge of the statistics,
you need to use the PURGE_STATS procedure of the DBMS_STATS package.
Using Automatic Undo Retention Tuning

Oracle databases use undo records to save the actions of transactions. Oracle refers
to the records collectively as undo. Oracles uses the undo information to roll back, or
undo, a transaction if necessary. For example, you may have inserted or deleted data,
but now you want to roll back the changes to return the database to how it was before
you made the change.
Undo data can help you perform key tasks like the following:
■ Perform a rollback when you don’t want to commit changes

■ Provide read consistency, by preserving the before image of data so a user sees
a consistent view of data, even when another user is changing the same data
■ Aid during a database recovery process, by undoing any uncommitted
changes applied to datafiles by the redo logs
■ Facilitate the flashback features that rely on undo information to function
Using Automatic Undo Retention Tuning 39
Until the Oracle9i database, Oracle used rollback segments to manage undo
information. Rollback segments are complex to administer, with segments encountering
the dreaded ORA-1555 (snapshot too old) errors on a regular basis during long
transactions. While Oracle Database 10g still enables you to use traditional rollback
segments, that feature has been deprecated in this version. In Oracle Database 10g,
you can use either a manual mode of undo
management (involving rollback segments), or
Automatic Undo Management (AUM). Oracle
If you don’t specify the recommends, however, that you use the AUM
mode of undo management, you will be feature, wherein Oracle will be in charge of
using manual undo management, with maintaining the undo segments. You don’t have
the help of rollback segments. This is the headaches of managing rollback segments
because the default undo management anymore. In addition, you can now control the
mode is manual. amount of time the database retains important
undo information before it overwrites the data.
Automatic Undo Management Configuration

To enforce Automatic Undo Management, you need to configure the following
initialization parameters:
■ UNDO_MANAGEMENT The default value for this parameter is MANUAL,

which means you are going to use the traditional rollback segments to
manage undo. If you want to use Automatic Undo Management, you need
to specify AUTO as the value for this parameter.
■ UNDO_TABLESPACE If you choose Automatic Undo Management, you
should specify a separate tablespace to hold the undo information by using
this parameter. If you don’t do this, the undo will be stored in the SYSTEM
tablespace.
■ UNDO_RETENTION This parameter specifies the duration of time for
which the database should retain the undo information. The default for
this parameter is 900 seconds.
The UNDO_RETENTION and UNDO_TABLESPACE parameters are crucial for

managing your undo data. On a simple level, it is easy to see what factors will
determine how you set these parameters. If you have a large amount of undo
(because of a large amount of database changes like insert and delete operations),
you’ll need a correspondingly large undo tablespace to hold all the undo information.
If you have several long-running SQL queries, your undo retention time should be
correspondingly long.
The Undo Advisor

The easiest way to manage undo activity is to access the Undo Advisor from the
OEM Database Control. You can get to the Undo Advisor page by clicking the Undo
Management link on the Advisor Central page of the OEM Database Control. Once
you are on the Undo Management page, you can set parameters for undo management.
You can perform the following undo management tasks from the Database Control
interface:
■ Enable/disable Automatic Undo Management

■ Specify/modify undo tablespaces
■ Ask for undo tablespace size recommendations
■ Ask for undo retention period recommendations
■ Experiment with alternative undo retention period settings
You can use the Undo Advisor to help you configure the optimal undo retention
time and your undo tablespace size. The Undo Advisor bases its undo management
recommendations on the following criteria:
■ Longest running query (in minutes)

■ Average undo generation rate (KB/minute)
■ Maximum undo generation (KB/minute)
Undo Tablespace and Undo Retention Management

Undo management involves managing the undo tablespace and undo retention issues.
Let’s look at these undo management issues in the following sections.
Managing the Undo Tablespace

Oracle provides you two ways of making sure you don’t run out of room for undo in
your undo tablespace.
■ Oracle alerts you when your undo tablespace is going to run out of space,
just as it alerts you about space problems in other tablespaces (for more on
tablespace and other alerts, see Chapter 4).
■ Oracle alerts you if your system has long-running queries that may result in
the ORA-1555 (snapshot too old) error.
Managing Undo Retention

Oracle automatically tunes the undo retention period by constantly collecting statistics
on query length as well as undo generation rate. As noted earlier, the default value of
the UNDO_RETENTION parameter is 900 seconds. So, even if you don’t explicitly ask
Oracle to retain undo information for a specific period, once you specify the UNDO_
MANAGEMENT=AUTO parameter, Oracle will automatically start retaining your undo
data for 15 minutes (900 seconds).
Here is how undo retention actually works in practice (assume that you left the
undo retention interval at the default value of 900 seconds):
■ If your undo tablespace has enough space, Oracle will retain undo data for
at least 900 seconds.
■ If your undo tablespace doesn’t have enough free space, Oracle may choose
not to retain the undo information for 900 seconds; that is, Oracle will let
new undo records write over the older records, even before the older records
are 900 seconds old.
Why does Oracle behave in this way? It will shorten the retention interval when
there are new DML operations in the database and there isn’t enough free space in the
undo tablespace to accommodate these new DML operations. Rather than cause the
DML operations to fail due to the lack of undo space, Oracle simply chooses the “lesser
evil” of overwriting some of the old redo information.
Using the Retention Guarantee Option

If you want to absolutely, positively guarantee that Oracle retains the undo information
for the length of time you chose by specifying the UNDO_RETENTION parameter’s
value, you can do so by using a new Oracle Database 10g feature: retention guarantee. By
default, Oracle disables the retention guarantee feature. You can enable the guarantee
feature at database creation time, at the undo tablespace creation time, or by using the
alter tablespace command.
You can check the current retention setting for your undo tablespace by issuing
the following query:
SQL> select tablespace_name,retention
2 from dba_tablespaces;
TABLESPACE_NAME RETENTION
-------------------------------------------
SYSTEM NOT APPLY
UNDOTBS1 NOGUARANTEE
SYSAUX NOT APPLY
…
SQL>
The NOGUARANTEE value under the retention column for the UNDOTBS1
tablespace shows the default value of the UNDO_RETENTION parameter. By default,
there is no guarantee of undo retention. You can guarantee undo retention for the
UNDOTBS1 tablespace by using the following command:
SQL> alter tablespace UNDOTBS1 retention guarantee;
Tablespace altered.
SQL>
If you wish to enforce the retention guarantee feature right from the beginning,
you can create your undo tablespace with this feature built in, as shown here:
SQL> create undo tablespace new_undo
datafile ‘C:\oracle\product\10.1.0\data\new_iundo_01.dbf'
size 10M autoextend on
retention guarantee;
Does Automatic Undo only way to eliminate this error is to use

Management mean that you don’t need to the RETENTION GUARANTEE clause, which
worry about the usual ORA-1555 (snapshot guarantees that Oracle will never overwrite
too old) errors, because Oracle reuses undo any undo data that is within the undo
segments with unexpired undo data? Well, retention period. One of the main reasons
it all depends on how much space there is why you may use the retention guarantee
in your undo tablespace. If the available feature is to enable the success of flashback
free space is the undo tablespace isn’t features in your database, which depend
enough for your transaction-activity levels, critically on the retention of necessary undo
Oracle may overwrite unexpired undo data, information.
causing the snapshot too old errors. The
INSIDE THE EXAM
In the Automatic Shared Memory Management understand the new time model and the
section, you must clearly understand which are importance of the DB time metric. What
the automatically tunable and the manually are the different ways in which you can get
tunable SGA components. You must also know an ADDM report? How do you get ADDM
the background process that coordinates the reports for custom intervals? What does an
sizing of the memory components. What is ADDM report contain?
the difference between the behavior of the Expect a question regarding the automatic
SHARED_POOL_SIZE component in collection of optimizer statistics by Oracle.
Oracle Database 10g and in the older How does Oracle prioritize its statistics
versions of Oracle? collection? What procedure do you use
There will be a couple of questions to restore older optimizer statistics?
on the AWR and the ADDM. You must
If you specify the RETENTION GUARANTEE clause, you run the risk of your
DML operations failing due to lack of undo space. Therefore, don’t use this
clause unless you must guarantee the availability of undo data (for example,
for the flashback query feature).
In this chapter, you first learned about the AWR and how it collects database
performance statistics in the form of regular snapshots. Then you learned how the
ADDM uses these snapshots to automatically analyze database performance and
make recommendations to improve it if necessary.
The chapter introduced you to the new Automatic Shared Memory Management
feature and the use of the SGA_TARGET initialization parameter. You learned about
how Oracle can automatically manage the four auto-tuned parameters.
You learned about how Oracle Database 10g can automatically gather key optimizer
statistics for you. You reviewed the Automatic Undo Management feature and learned
the role of the parameters UNDO_TABLESPACE and UNDO_RETENTION. Finally,
you learned about the new undo retention guarantee feature, which lets you ensure
the retention of undo data.
Using the Automatic Database Diagnostic Monitor (ADDM)
❑ The Automatic Workload Repository (AWR) collects database performance
statistics on a regular basis and stores them in the SYSAUX tablespace.
❑ By default, the AWR collects its snapshots on an hourly basis and stores them
for a period of seven days.
❑ The ADDM uses the new time statistics model to analyze database performance.
❑ The V$SYS_TIME_MODEL and V$SESS_TIME_MODEL views show the
time statistics on a system and session level, respectively.
❑ The key time model metric, DB time, covers the actual time spent processing
user database calls.
❑ The main goal of the ADDM tool is to reduce the DB time metric.
❑ The ADDM addresses the root causes of performance problems, not just
symptoms.
❑ The AWR automatically purges the old snapshots after the default interval
of seven days.
❑ The ADDM may recommend changes in I/O or memory, as well as database
and application configuration.
❑ The ADDM may also recommend the invocation of other management
advisors in order to analyze a problem in depth.
❑ The MMON background process helps manage the ADDM and schedules
the ADDM.
❑ Oracle enables ADDM by default. Just make sure to set the STATISTICS_
LEVEL initialization parameter to TYPICAL or ALL.
❑ By adjusting either or both of two variables—snapshot interval and data
retention period—you can control the amount of data that AWR maintains.
❑ The DBIO_EXPECTED parameter indicates how fast your I/O system performs.
❑ You may use the DBMS_ADVISOR package to change the default value of the
DBIO_EXPECTED parameter.
❑ You can view the ADDM analysis reports in three different ways: through the
Database Control, through SQL statements, and with the help of database
packages.
Two-Minute Drill 45
❑ The easiest way to view the ADDM reports is through the OEM Database
Control.
❑ You can obtain ADDM reports by using the SQL script addmrpt.sql.
❑ The ADDM reports have three main components: impact, findings, and
recommendations.
❑ You need the ADVISOR privilege to use the DBMS_ADVISOR package,
which helps you manage the ADDM.
❑ The GET_TASK_REPORT procedure of the DBMS_ADVISOR package
enables you to produce ADDM reports.

❑ To use the Automatic Shared Memory Management feature, you must set
the STATISTICS_LEVEL parameter to TYPICAL or ALL.
❑ There are two sets of SGA parameters: auto-tuned and manually sized.
❑ The auto-tuned set of parameters consists of the buffer cache, shared pool,
large pool, and Java pool.
❑ The default value of the SGA_TARGET parameter is zero.
❑ To automate SGA management, set the SGA_TARGET to a value greater
than zero.
❑ Oracle subtracts the value of the manually sized parameter (and the fixed
SGA) from the SGA first. It allocates the remainder of the SGA to the
four auto-tuned parameters.
❑ The default values of all four auto-tuned parameters are zero.
❑ You can dynamically increase or decrease the value of the SGA_TARGET
parameter.
❑ The SGA_MAX_SIZE parameter sets the limit on how high you can set
SGA_TARGET.
❑ Even under automatic SGA management, you can set the sizes for the four
individual auto-tuned parameters.
❑ Oracle recommends that you don’t set any auto-tuned parameters yourself.
❑ Use the SPFILE if you want Oracle to remember the sizes of auto-tuned
parameters across instance shutdowns.

❑ Oracle enables automatic optimizer statistics collection by default.
❑ You must set the STATISTICS_LEVEL parameter to TYPICAL or ALL
to use Oracle’s automatic optimizer statistics collection capability.
❑ Oracle uses the GATHER_STATS_JOB job to run the automatic statistics
collection process.
❑ The GATHER_STATS_JOB job collects statistics only if they are stale or
not available.
❑ The Scheduler runs the GATHER_STATS_JOB job during the maintenance
window.
❑ The database uses the table-monitoring feature to decide whether it should
collect new statistics.
❑ You can lock table and schema statistics using the LOCK_TABLE_
STATISTICS and LOCK_SCHEMA_STATISTICS procedures from
the DBMS_STATS package.
❑ If you lock a table’s statistics, Oracle locks all associated statistics
automatically as well.
❑ You can lock a table without statistics, by setting the statistics to NULL.
❑ Use the FORCE argument to override any locks on statistics.
❑ You can restore any old statistics by using the RESTORE_*_ procedures
of the DBMS_STATS package.
❑ By default, Oracle saves optimizer statistics for 31 days.

❑ Oracle uses manual undo management by default.
❑ Set UNDO_MANAGEMENT=AUTO to use Automatic Undo Management.
❑ The default value for the UNDO_RETENTION parameter is 900 seconds.
❑ If you run out of fresh room in the undo tablespace, Oracle writes over
unexpired undo data.
❑ Use the undo RETENTION GUARANTEE clause to ensure Oracle retains
undo information for the time set by the UNDO_RETENTION parameter.
❑ Your DML operations may fail on occasion if you choose to use the undo
RETENTION GUARANTEE clause.
Self Test 47
SELF TEST

1. Where does the ADDM save its analysis results?
A. In the OEM repository
B. In the ADDM tablespace
C. In the SYSTEM tablespace
D. In the SYSAUX tablespace
2. What is the key goal of the ADDM?
A. To reduce DB time
B. To reduce DB idle time
C. To reduce DB active time
D. To reduce throughput
3. In response to a performance bottleneck, what will the ADDM do?
A. Always recommend the use of management advisors
B. Always suggest its own recommendations
C. Sometimes recommend the use of management advisors
D. Propose a single recommendation to fix the problem
4. If your disk read time is 2000 microseconds, what will you need to do?
A. Use the DBMS_ADVISOR package to lower the value of the DBIO_EXPECTED parameter
B. Use the DBMS_ADVISOR package to raise the value of the DBIO_EXPECTED parameter
C. Use the DBA_ADVISOR package to lower the value of the DBIO_EXPECTED parameter
D. Use the Database Control to lower the value of the DBIO_EXPECTED parameter
5. To retrieve the ADDM reports using SQL, what do you need to do?
A. Run the addmrpt.sql SQL script
B. Use the DBA_ADDM view
C. Use the DBA_ADVISOR view
D. Use the DBMS_ADDM package

6. To enable Automatic Shared Memory Management, what does the DBA need to do?
A. Set the STATISTICS_LEVEL parameter to BASIC
B. Set the STATISTICS_LEVEL parameter to TYPICAL or ALL and set SGA_TARGET_
SIZE to a nonzero value
C. Set the STATISTICS_LEVEL parameter to TYPICAL or ALL and remove the SGA_
TARGET parameter
D. Set the STATISTICS_LEVEL parameter to TYPICAL or ALL and set SGA_TARGET
to zero
7. If you set the value of the SGA_TARGET parameter higher than the value of the SGA_MAX_
SIZE parameter at instance startup, what will happen?
A. The instance will not start.
B. SGA_TARGET will become equal to the SGA_MAX_SIZE value.
C. The database will ignore the SGA_TARGET parameter.
D. SGA_MAX_SIZE is automatically raised, so it is equal to the SGA_TARGET value.
8. In order to turn off automatic SGA management, what should the DBA do?
A. Set the SGA_MAX_SIZE parameter to zero
B. Set the SGA_TARGET parameter to zero
C. Set the SGA_TARGET parameter equal to the SGA_MAX_SIZE parameter
D. Remove the SGA_MAX_SIZE parameter
9. You are using automatic SGA management, with SGA_TARGET set at 500M. If you set
the DB_KEEP_CACHE_SIZE to 100M, approximately how much of the SGA memory
can Oracle assign to the auto-tuned parameters?
A. 500MB
B. 600MB
C. 400MB
D. Oracle cannot assign any memory to the auto-tuned parameters under the given circumstances.
10. If you set the sizes of all four auto-tuned parameters, which of the following is true?
A. You can’t use the Automatic Shared Memory Management feature.
B. Oracle can raise the sizes of the parameters under Automatic Shared Memory Management.
C. Oracle can lower the sizes of the parameters under Automatic Shared Memory
Management.
D. Oracle can raise the sizes of the parameters under manual shared memory management.
Self Test 49

11. How do you verify that the automatic statistics collection job is running?
A. Query the DBA_JOBS view
B. Query the DBA_SCHEDULER_JOBS view
C. Query the DBA_SCHEDULER view
D. Query the GATHER _DATABASE_STATS_JOB_PROC view
12. When should the DBA consider locking table statistics?
A. When the table’s data is extremely stable
B. When the table’s data is extremely volatile
C. When the table’s data changes by less than 10 percent on a regular basis
D. When the table is never truncated
13. In order to override the locking of statistics, what should you use?
A. DBMS_STATS.DELETE_STATS procedure
B. DBMS_STATS.IMPORT_SCHEMA_STATS procedure
C. DBMS_STATS.DELETE_STATS procedure with the OVERRIDE option
D. DBMS_STATS.DELETE procedure with the FORCE option
14. By default, the DBA_TAB_STATS_HISTORY view saves statistics history for how long?
A. 31 days
B. 30 days
C. 1 hour
D. 7 days
15. What does the LOCK_* procedure of the DBMS_STATS package help you do?
A. Lock current statistics
B. Make current statistics NULL
C. Override current statistics with the latest statistics
D. Lock statistics from a previous period

16. If you use the retention guarantee feature, you are guaranteeing that the database will never
do what?
A. Overwrite unexpired undo data
B. Overwrite expired undo data
C. Overwrite data older that the undo retention period

D. Overwrite data more recent than the undo retention period
17. To ask Oracle to retain undo information for a specific period, what must you do?
A. Use the manual undo management mode
B. Specify a certain value for the UNDO_RETENTION parameter
C. Use the RETENTION GUARANTEE clause
D. Use the RETENTION NO GUARANTEE clause
17. If you wish to use Automatic Undo Management, you must do which of the following?
A. Specify an undo tablespace
B. Use the retention guarantee feature
C. Specify the UNDO_RETENTION parameter
D. Set the value of the UNDO_MANAGEMENT parameter to AUTO
18. By default, Oracle retains your undo information for how long?
A. 31 days
B. 15 minutes
C. 30 minutes
D. 7 days
20. By default, how does Oracle handle undo?
A. Disables the retention guarantee feature
B. Enables the retention guarantee feature
C. Enables the Automatic Undo Management feature
D. Enables the retention guarantee feature for the flashback query feature
LAB QUESTION
You are currently using manual shared memory management. Your init.ora parameter file looks like this:
db_cache_size=80M
java_pool_size=10M
large_pool_size=10M
shared_pool_size=100M
What do you need to do to switch to Automatic Shared Memory Management? Ensure that your
SGA allocation is the same size as before. Show the answer using the manual SQL*Plus method.
SELF TEST ANSWERS

1. þ D. The ADDM facility stores all its analysis reports in the SYSAUX tablespace, just as
the AWR facility does.
ý A, B, and C provide wrong destinations for the ADDM reports.
2. þ A. Reducing the DB time metric is the fundamental goal of the ADDM.
ý B and C are misleading answers. D is wrong because the ADDM’s goal is exactly the
opposite.
3. þ C. When ADDM encounters performance problems, it may propose several recommendations
that you can directly implement, in addition to making the optional recommendation to run
other management advisors.
ý A is wrong because the ADDM doesn’t necessarily ask you to invoke a management
advisor. B is wrong since the ADDM may also suggest that you use management advisors.
D is wrong since the ADDM doesn’t limit itself to providing a single solution for a
performance problem.
4. þ A. By default, ADDM assumes that your DBIO_EXPECTED parameter has a value of
10000 microseconds. Since your system disk reading speed is actually lower than this, you
must reset this parameter by lowering the value of the DBIO_EXPECTED parameter.
ý B is wrong because you need to lower, not raise, the value of the DBIO_EXPECTED
parameter. C is wrong since you can’t use the DBA_ADVISOR package to adjust the DBIO_
EXPECTED parameter. D is wrong since you can’t use the Database Control to adjust the
DBIO_EXPECTED parameter.
5. þ A. To retrieve the ADDM report, you must use the Oracle-supplied addmrpt.sql script.
ý B is wrong because there is no DBA_ADDM view. C is wrong because the DBA_ADVISOR
view can’t help you produce an ADDM report. D is wrong because there is no PL/SQL package
named DBMS_ADDM.

6. þ B. You must set the STATISTICS_LEVEL parameter to TYPICAL or ALL and set the
SGA_TARGET parameter to a nonzero value in order for automatic SGA management to come
into force.
ý A is wrong since setting the STATISTICS_LEVEL parameter to BASIC ensures that you
won’t have automatic SGA management in your database. C and D are wrong since removing
the SGA_TARGET parameter or explicitly setting it to zero mean the same thing, and the default
value of the parameter is zero anyway. Setting the SGA_TARGET parameter to zero means you
can’t use Automatic Shared Memory Management.
7. þ D. The value of the SGA_MAX_SIZE parameter will be bumped up to the value of the
SGA_TARGET parameter.
ý A is incorrect since the instance will start without any problem. B is incorrect because it
implies that the value of the SGA_TARGET parameter will be lowered to match the size of the
SGA_MAX_SIZE parameter. Actually as answer D indicates, it’s the other way around—the
SGA_MAX_SIZE parameter’s value will be raised to match the SGA_TARGET parameter’s
value. C is incorrect since the database doesn’t ignore the higher SGA_TARGET parameter
value, but uses it.
8. þ B. If you set the SGA_TARGET parameter value to zero, you’ll disable automatic memory
management.
ý A, C, and D have no bearing on Automatic Shared Memory Management.
9. þ C. When you use Automatic Shared Memory Management, Oracle will first deduct the
sum of manually sized parameters from the SGA_TARGET parameter. Oracle can assign only
the remaining memory to the auto-tuned parameters.
ý A and B are wrong, based on the analysis for the correct answer. D is wrong because you
won’t prevent Oracle from assigning memory to the auto-tuned parameters when you set the
size of one or more manually tuned memory parameters.
10. þ B. Even under Automatic Shared Memory Management, you can set the sizes of the
individual auto-tuned components. Oracle will treat this as the minimum values for these
parameters, and can raise them, but won’t be able to lower them.
ý A is wrong because you can use Automatic Shared Memory Management, even when you
set the sizes for one or more auto-tuned parameters. C is wrong because, as the correct answer
explains, Oracle can only raise, not lower, any values you set for the auto-tuned parameters.
D is wrong because Oracle cannot change any of the shared memory components when you
use manual shared memory management.

11. þ B. The new Scheduler facility runs the GATHER_DATABASE_STATS_JOB_PROC
procedure, belonging to the DBMS_STATS package, to gather optimizer statistics. The job
name is GATHER_STATS_JOB, which Oracle lists in the DBA_SCHEDULER_JOBS view.
The new DBA_SCHEDULER_JOBS view is similar to the old DBA_JOBS view, and it provides
information about all scheduled jobs in the database. You can query this view to see if the
GATHER_DATABASE_STATS_JOB_PROC procedure is scheduled for running. The DBA_
JOBS view exists in the Oracle Database 10g, but it won’t tell you anything about the
automatically scheduled jobs.
ý C and D are wrong because there are no such views. A is wrong because the DBA_JOBS
view will not have any information about the new Scheduler facility.
12. þ B. You should consider locking down a table’s statistics when a table’s data is extremely
volatile.
ý A, C, and D are all reasons why you won’t need to lock down a table’s statistics.
13. þ D. Any time you need to override any statistics, you should use the FORCE argument for
the relevant DBMS_STATS package. Therefore, you can figure out that D is the right answer,
since it’s the only one that uses the FORCE option.
ý A, B, and C are wrong since none of these alternatives use the FORCE option.
14. þ A. By default, Oracle saves optimizer statistics for 31 days before purging them. You can
always change this default duration.
ý B, C, and D provide the wrong period.
15. þ A. All the LOCK_* procedures enable you to lock current statistics.
ý B is wrong since the LOCK_* procedures don’t make the statistics NULL. C is wrong since
the procedures don’t override current statistics. D is wrong because the procedures lock the
current statistics, not those from a previous period.
16. þ A and D. A is correct because the RETENTION GUARANTEE clause guarantees that you’ll
never overwrite unexpired data in the undo segments. D is correct because you won’t overwrite
data more recent than the undo retention period.
ý B is wrong because Oracle may very well overwrite expired undo data, whether or not you
use the RETENTION GUARANTEE clause. C is wrong because there is no guarantee that Oracle
won’t overwrite data older than the data retention period.

17. þ B. UNDO_RETENTION isn’t really a mandatory parameter when you use Automatic Undo
Management. Even when you don’t specify this parameter, Oracle will automatically use a
default value for the parameter. However, if you wish the database to retain undo information
for a specific length of time, you must use the UNDO_RETENTION parameter.
ý A is wrong since using manual undo management isn’t necessary to retain undo information
for a specific period. C and D are invalid since the retention guarantee and the
RETENTION NO GUARANTEE options aren’t necessary to ask Oracle to retain undo information
for a specific period, the UNDO_RETENTION parameter will suffice for this purpose.
18. þ D. You must set the UNDO_MANAGEMENT parameter to AUTO if you want Oracle to
manage the undo information.
ý A, B, and C are incorrect since you don’t need to specify anything other than the
UNDO_MANAGEMENT=AUTO parameter to use Automatic Undo Management. As important

as they are, all these alternatives mention factors that are optional, not mandatory for Automatic
Undo Management.
19. þ B. By default, Oracle retains undo data for 600 seconds (15 minutes).
ý A, C, and D provide incorrect values.
20. þ A. Oracle disables the retention guarantee feature by default. You can enable it by using
the alter system command, as demonstrated in this chapter.
ý B is wrong since Oracle disables the option by default. C is wrong since Oracle enables manual
undo management by default. D is incorrect since Oracle doesn’t enable the retention guarantee
feature by default for any purpose. Oracle recommends that you use the retention guarantee
feature sparingly, such as only when you use the flashback query feature.
LAB ANSWER
First, find out the current SGA size using the following command:
SQL> select sum(value) from v$sga;
SUM(VALUE)
------------------
218103808
Next, issue the following command, to switch to Automatic Shared Memory Management:
SQL> alter system set SGA_TARGET=218103808;
System altered.
SQL>
Although you are now technically using Automatic Shared Memory Management, since you have
set minimum values for all four auto-tuned SGA parameters in your init.ora file, Oracle can’t modify
the sizes of the components. You therefore must set the sizes of all four auto-tuned parameters to zero,
by issuing the following set of commands:
SQL> alter system set db_cache_size=0;
System altered.
SQL> alter system set shared_pool_size=0;
System altered.
SQL> alter system set java_pool_size=0;
System altered.
SQL> alter system set large_pool_size=0;
System altered.
SQL>
Blind Folio 4:1
4
Manageability
Infrastructure
4.01 Types of Oracle Statistics 4.05 The Automated Tasks Feature

4.02 The Automatic Workload Repository 4.06 The Management Advisory Framework
(AWR)
4.03 Active Session History
Q&A Self Test
4.04 Server-Generated Alerts
2 Chapter 4: Manageability Infrastructure
O racle Corporation has devoted a substantial amount of effort to making Oracle

Database 10g a truly self-managing database. Self-managing capabilities rely on a
manageability infrastructure. This chapter explores several important parts of the
new manageability infrastructure.
In this chapter, you’ll learn more about the Automatic Workload Repository
(AWR), which lies at the foundation of Oracle Database 10g’s self-management
capabilities. You’ll learn how to manage the AWR, by managing the AWR snapshots.
In previous versions of Oracle, you had access to the OEM alert system. Now, in
Oracle Database 10g, you have an altogether new server-generated alert mechanism
to help you manage the database. These server-generated alerts include both
threshold-based and event-based warnings.
The chapter also discusses the new automated tasks feature. You’ll also get an
introduction to the new set of management advisors that comes with the Oracle
Database 10g. The advisory framework is a new approach to managing the database.
Now you can turn to these advisors for advice on configuring crucial factors like
memory, space, and SQL statement tuning.
The chapter contains the following major sections:
■ Types of Oracle Statistics

■ The Automatic Workload Repository (AWR)
■ Active Session History (ASH)
■ Server-Generated Alerts
■ The Automated Tasks Feature
■ The Management Advisory Framework
Types of Oracle Statistics

Oracle DBAs regularly collect several types of performance statistics in order to
analyze database bottlenecks and other performance issues. In Oracle Database 10g,
DBAs now have access to several new types of performance statistics. Besides database
Types of Oracle Statistics 3
statistics at the system and session levels (wait statistics, segment usage statistics, and
so on), these statistics include operating system statistics (CPU statistics, disk usage
statistics, and memory usage statistics) and network statistics as well.
All performance statistics, regardless of their origin—database, operating system,
or network—can be classified into several types according to the basis on which you
collect the statistics. Let’s briefly look at the various types of performance statistics
you can collect in Oracle Database 10g.
Cumulative Statistics
Cumulative statistics are the accumulated total value of a particular statistic since
instance startup. The statistic total logons, for example, is a cumulative statistic. Oracle
collects cumulative statistics for just about every variable for which it collects statistics.
Oracle collects several types of cumulative statistics, including statistics for segments
and SQL statements, as well as session- and system-wide statistics. By comparing the
delta values—the rates of change of the cumulative statistics between a beginning and
an ending period—Oracle analyzes database performance during a specific interval
of time.
You are familiar with the important dynamic performance views V$SYSSTAT
and V$SESSSTAT. These two views hold many of the important cumulative
statistics for the Oracle database. Dynamic performance views are very useful in
judging database performance, but unfortunately, when you shut down the database,
the data in the dynamic performance views disappears completely! If you wish to
track database performance over time, or if you wish to compare the performance
impact of database changes, you need to store the performance data in a repository.
This is where the Automatic Workload Repository (AWR) comes in.
The AWR takes the difference between the cumulative data between two periods
and stores this information in its repository. This difference between two periods is
called an AWR snapshot. By default, the database will take a performance snapshot
every hour, but you can customize this interval.
Database Metrics
Database metrics are another important type of Oracle performance statistics. You can
define metrics as statistics that measure the rate of change in a cumulative performance
statistic.
In previous Oracle versions, you needed to compute metrics for various performance
statistics by collecting data at various periods, to calculate the rate of change of various
statistics. Now, Oracle places precomputed metrics at your fingertips. For example,
you may be interested in a metric like the number of transactions per second during
peak time. Dynamic performance views hold these metrics, and the AWR can also
store them in its repository. All the Oracle management advisors use database
metrics for diagnosing performance problems and making tuning recommendations.
You can look at statistics such as the number of user transactions and the number
of physical reads in the system as the base statistics from which you derive database
metrics. Thus, database metrics are derived statistics. The background process MMON
(Manageability Monitor) updates metric data on a minute-by-minute basis, after
collecting the necessary fresh base statistics.
Sample Data
The new Automatic Session History (ASH) feature now automatically collects session
sample data, which represents a sample of the current state of the active sessions. ASH
collects the data in memory, where you can view it with the help of V$ views. The
AWR helps save the ASH data permanently, by collecting it as part of its regular
snapshots. I discuss the ASH feature in detail later in this chapter, in the “Automatic
Session History” section.
MMON is a brand-new history information for the Automatic

Oracle Database 10g background process. Session History (ASH) feature under some
This process performs mostly management- circumstances. For example, the MMNL
related tasks, including issuing database process will flush ASH data to disk if the
alerts and capturing statistics for recently ASH memory buffer fills up before the one-
modified database objects. The MMON hour interval that would normally cause
process transfers the memory version of MMON to flush it. (Note that although
AWR statistics to disk on a regular basis (in Oracle calls MMNL the Manageability
the form of snapshots). The Manageability Monitor Light, this process shows up as
Monitor Light (MMNL) process performs Manageability Monitor Process 2 when
lightweight manageability tasks, including you query the V$BGPROCESS view.)
computing metrics and capturing session
The Automatic Workload Repository (AWR) 5
Baseline Data
A good way to evaluate database performance is by comparing database performance
statistics from two periods, if you know that the first period reflects “good” performance.
The statistics from the period where the database performed well are called baseline
data. By comparing the current performance with the base period’s performance, you
can see if the database is faring better or worse. You could also compare individual
statistics to see which database component may be the source of your problems.
The STATISTICS_LEVEL initialization parameter is the key determinant

of exactly what type of statistics the AWR collects. You can determine the
types of statistics collected by using various values for this parameter. If you
use BASIC as the value for this parameter, the AWR turns off its statistics
collection completely. Choosing TYPICAL as the value for this parameter
will collect what Oracle deems it typically needs for monitoring database
behavior. If you set STATISTICS_LEVEL=ALL, the AWR collects all available
statistics. Oracle recommends that you use the default STATISTICS_LEVEL
=TYPICAL setting. The ALL setting may be too comprehensive most of the
time, and if you use the BASIC setting, you won’t be able to use many of
Oracle Database 10g’s automatic performance tuning features.
The Automatic Workload Repository (AWR)

The AWR is Oracle Database 10g’s brand-new feature for the automatic collection of
performance statistics in the database, and it lies at the heart of the new self-tuning
capabilities of the Oracle database. The AWR stores its data in the new SYSAUX
tablespace and, in fact, is one of the major users of that tablespace. AWR provides
performance statistics in two distinct formats:
■ A temporary in-memory collection of statistics in the SGA, which you can

access with the help of the dynamic performance (V$) views. You can also
view these statistics through the OEM interface.
■ A persistent type of performance data in the form of regular AWR snapshots,

which you access either through data dictionary views (DBA_*) or the
OEM Database Control. You can use the AWR snapshots for historical
comparisons of performance. The new MMON background process performs
the transfer of the data from memory to disk.
Oracle DBAs traditionally have needed to maintain special database tables to

collect historical performance data. The AWR automatically collects performance
statistics for you and maintains historical data for analysis. You can view the data in
the snapshots with the help of the V$ views or create reports to examine the data
in detail. Various database components and features use the data from these AWR
snapshots to monitor and diagnose performance issues. For example, as you saw in
Chapter 3, the ADDM relies on these snapshots for the diagnosis of performance
problems.
Types of Data Collected by AWR

The AWR facility collects a large number of performance statistics, including the
following:
■ Base statistics that are also collected in the V$SYSSTAT and V$SESSSTAT
views
■ New SQL statistics that aid in the identification of resource-intensive SQL
statements
■ Database object usage statistics that inform you about how the database is
currently accessing various objects
■ Time statistics, which tell you how much time each database activity is
taking
■ Wait statistics, which provide information about session waits (in previous
versions, you needed to join the V$SESSION view with the V$SESSION_
WAIT view to gather information on session waits; now several columns have
been added to the V$SESSION view, so you can query the view directly)
■ Active Session History (ASH) statistics, which are flushed to the AWR on
a regular basis
■ Database feature usage statistics that tell you if and how intensively your
database is utilizing various features
■ The results of various management advisory sessions like the Segment

Advisor and the SQL Access Advisor
■ Operating system statistics like disk I/O and memory usage within the
database
It is important to understand that the AWR isn’t a repository where Oracle stores
all the data for the various performance indicators that it covers. The AWR stores
only a part of the statistics that it collects in memory. Whenever AWR collects a
snapshot, it transfers part of the huge amount of data it holds in memory (SGA)
to disk.
AWR Data Handling

AWR automatically generates snapshots to collect performance statistics. A snapshot
is simply the performance data that is captured at certain point in time. As you recall
from the previous chapter, each time the AWR generates a snapshot, the ADDM
will analyze the period corresponding to the last two snapshots. You may also create
snapshots manually if necessary. By comparing the difference in statistics between
snapshots, the AWR knows which SQL statements are contributing significantly to
your system load. It will then focus on these SQL statements. AWR stores its data in
the SYSAUX tablespace. The space used by AWR depends on the following:
■ Data-retention period The longer the retention period, the more space used
■ Snapshot interval The more frequent the snapshots are taken, the more
space used
■ Number of active sessions The higher the number of user sessions, the
more data collected by the AWR
By default, the AWR saves the data for a period of seven days, but you can modify
this period. Oracle recommends that you retain the AWR data to cover at least one
complete workload cycle.
Managing the AWR

Managing the AWR really means managing the regular snapshots that AWR collects
from your database. By default, the AWR collects its snapshots every 60 minutes. If
you think this isn’t an appropriate length of time for your purposes, you can change
the default snapshot interval easily by changing the INTERVAL parameter.
Snapshots provide you sequence numbers called snap IDs. The

values for key performance statistics default interval for snapshot collection
at a given point in time. By comparing is 60 minutes, and the minimum interval
snapshots from different periods, you is 10 minutes. You can change the interval
can compute the rate of change of a between snapshots by adjusting the
performance statistic. Most of the Oracle INTERVAL parameter. You can take
advisors depend on these AWR snapshots manual snapshots of the system any time
for their recommendations. You identify a you wish. You can combine manual and
given snapshot by its unique snapshot automatic snapshots as well.
In order to use the AWR feature well, you need to select a truly representative
baseline, which is a pair or range of AWR snapshots. When database performance is
slow, you can compare the baseline snapshot statistics with current performance
statistics and figure out where the problems lie.
You can manage the AWR snapshots either with the help of the OEM Database
Control or with the Oracle-supplied DBMS_WORKLOAD_REPOSITORY package.
Let’s first look at how you can use this package to manage AWR snapshots.
Using the DBMS_WORKLOAD_REPOSITORY Package to

Manage AWR Snapshots
You can use the DBMS_WORKLOAD_REPOSITORY package to create, drop, and
modify snapshots, as well as to create and drop snapshot baselines.
The AWR automatically generates snapshots, but you can create a snapshot
manually, if you want to collect snapshots in between those scheduled by the AWR.
You can do this by using the CREATE_SNAPSHOT procedure, as follows.
begin
dbms_workload_repository.create_snapshot ();
end;
In order to drop a range of snapshots, use the DROP_SNAPSHOT procedure.

When you drop a set of snapshots, Oracle automatically purges the AWR data that
is part of this snapshot range. The following example drops all snapshots whose snap
IDs fall in the range of 40 to 60.
begin
dbms_workload_repository.drop_snapshot_range (low_snap_id => 40,
high_snap_id => 60, dbid => 2210828132);
end;
If you set the snapshot interval to 0, the AWR will stop collecting
snapshot data.
Using the Database Control to Manage AWR Snapshots

You can manage AWR snapshots using the AWR page of the OEM Database Control,
shown in Figure 4-1. To access this page, from the Database Control home page, click
the Administration link, and go the Workload group. Then click the Automatic
Workload Repository link. This page has two main sections: the General section and
the Manage Snapshots and Preserved Snapshot Sets section.
FIGURE 4-1 The main AWR page
If you want to change the general settings of the AWR, you can do so by clicking
the Edit button in the General section. This will take you to the Edit Settings page,
where you can modify the following:
■ Snapshot retention intervals

■ Snapshot collection intervals
■ Snapshot collection levels (Typical or All)
Click the Manage Snapshots and Preserved Snapshot Sets button to get to
the Manage Snapshots page. The Manage Snapshots page lists all the snapshots
in the AWR. You can click an individual snapshot to view complete details about
it, including the capture time and the collection level. If you have established a
baseline, you’ll also see whether a particular snapshot falls within that baseline.
From the Manage Snapshots page, you can do the following:
■ Create a snapshot spontaneously (use the Create button)

■ View a list of snapshots collected over a specific period
■ Establish a range of snapshots to use as a baseline (use the Create Preserved
Snapshot Set button)
■ Delete a defined range of snapshots from the list of snapshots collected over
a period of time (use the Delete Snapshot Range button)
The range of snapshots you use for a baseline is the same as a preserved
snapshot set.
Creating and Deleting AWR Snapshot Baselines

The purpose of using snapshot baselines is to have a valid measuring stick for acceptable
database performance, as well as to have a reference point for various system statistics.
When you say database performance is bad, you must know that it’s bad compared to
something you clearly know to be good performance.
You define a snapshot baseline on a pair of snapshots, when you know that the
period covered by the snapshots represents typical “good” database performance.
The baselines will then serve as a valid representative sample to compare with
current system database performance. Whenever you create a baseline by defining
it over any two snapshots (identified by their snap IDs), the AWR retains the
snapshots indefinitely (it won’t purge these snapshots after the default period
of seven days), unless you decide to drop the baseline itself.
You can create a new snapshot baseline by using the CREATE_BASELINE

procedure of the DBMS_WORKLOAD_REPOSITORY package. The snap ID
uniquely identifies each snapshot time sequentially. You can get the snap IDs you
need to create baselines from the DBA_HIST_SNAPSHOT view. The following
example creates a snapshot baseline named peak_time baseline:
begin
dbms_workload_repository.create_baseline (start_snap_id => 125,
end_snap_id => 185, baseline_name => 'peak_time baseline',
dbid => 2210828132);
end;
If you don’t specify a name for the baseline, Oracle will assign a system-generated
identifier.
You can drop a snapshot baseline by using the DROP_BASELINE procedure of
the DBMS_WORKLOAD_REPOSITORY package:
begin
dbms_workload_repository.drop_baseline (baseline_name => 'peak_time
baseline',
cascade => FALSE, dbid => 2210828132);
end;
The CASCADE parameter is FALSE by default. By setting this parameter to

TRUE, you can drop the actual snapshots as well.
Purging AWR Snapshots

As you’ve learned, by default, the AWR runs every hour, and Oracle saves AWR
statistics for a default period of seven days. After the seven-day period, Oracle removes
the snapshots, starting with the oldest ones first. Oracle estimates that if you have ten
concurrent sessions, it will take between 200MB and 300MB of disk space to store the
data that it saves over the standard seven-day period. You must therefore ensure that
your SYSAUX tablespace has at least this much free space, if you want Oracle to retain
the AWR data for the standard default period of seven days. The number of user
sessions is a key determinant of the space necessary for the AWR statistics.
If your SYSAUX tablespace runs out of space, Oracle will automatically delete
the oldest set of snapshots, to make room for new snapshots.
In addition to the number of active user sessions, two parameters affect the total
statistics retained in the SYSAUX tablespace:
■ RETENTION As you know, the default retention period for AWR statistics
is seven days. The minimum retention period is one day. The longer the
retention period, the more space the AWR will need in the SYSAUX
tablespace.
■ INTERVAL By default, the AWR collects data every 60 minutes and the
minimum interval value is 10 minutes. You can’t collect statistics more
frequently than in 10-minute intervals. The more frequently you schedule
the AWR, the more data the AWR will collect. And the more infrequent the
AWR snapshots, the greater the chance that you may miss short bursts in disk
or memory usage that may occur in your database.
You can use the DBMS_WORKLOAD_REPOSITORY package to modify the

snapshot settings, as shown here:
begin
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,
interval => 30, dbid => 3310949047);
end;
Oracle recommends that you make the retention period the same as your database
workload cycle. If your database is like many typical OLTP databases, you probably
have OLTP transactions throughout the weekdays, with batch jobs scheduled during
nights and weekends. If this is the case, your workload is considered to span a week,
in which case, the default AWR retention period of seven days is just fine.
Note that Oracle deletes older snapshots in chronological order. In addition,
AWR always retains baseline snapshots until you remove the baselines themselves.
The default period of fact will override all other retention

retention for AWR data is seven days and settings. Oracle will start deleting
the minimum is one day. However, if there snapshots, by first overwriting the
is no room in the SYSAUX tablespace, that oldest ones with new data.
If you set the value of the RETENTION parameter to zero, you disable
the automatic purging of the AWR. If you set the value of the INTERVAL
parameter to zero, you disable the automatic capturing of AWR snapshots.
Creating AWR Reports

Oracle provides a script named awrrpt.sql (located in the $ORACLE_HOME/rdbms/
admin directory) to generate summary reports about the statistics collected by the
AWR facility. Don’t confuse this report with the ADDM report (created by running
addmrpt.sql) that you learned about in Chapter 3. The AWR report doesn’t give you
recommendations, as does an ADDM report. Rather, it provides information about
the various kinds of performance statistics in the repository. The AWR report looks
remarkably similar to the traditional STATSPACK reports.
The awrrpt.sql actually calls another script, the awrrpt1.sql script, to generate the
AWR report for you. Note that you must have the SELECT ANY DICTIONARY
privilege in order to run the awrrpt.sql script.
When you run the awrrpt.sql script, Oracle will ask you to make the following
choices for your reports:
■ Choose between an HTML or plain text report

■ Specify the beginning and ending snap IDs
■ Specify the number of days of snapshots to choose from
The AWR reports include the following types of information:
■ Load profile
■ Instance efficiency percentages (target 100 percent)
■ Top-five timed events
■ Wait events and latch activity
■ Time model statistics
■ Operating system statistics
■ SQL ordered by elapsed time
■ Tablespace and file I/O statistics
■ Buffer pool and PGA statistics and advisories
Managing AWR Statistics with Data Dictionary Views

You can manage AWR statistics through the following data dictionary views:
■ The DBA_HIST_SNAPSHOT view shows all snapshots saved in the AWR.

■ The DBA_HIST_WR_CONTROL view displays the settings to control the AWR.
■ The DBA_HIST_BASELINE view shows all baselines and their beginning
and ending snap ID numbers.
Active Session History (ASH)

The AWR snapshots are very useful, but Oracle takes these snapshots only every 60
minutes. If you are interested in analyzing a performance problem that happened 10
minutes ago, the AWR snapshots aren’t of any help to you. However, you do have a
way to get that information. Oracle Database 10g now collects the new Active Session
History (ASH) statistics (mostly the wait statistics for different events) for all active
sessions every second, and stores them in a circular buffer in the SGA. Thus, ASH
records very recent session activity (within the past five or ten minutes).
Note that not all the extra statistics in Oracle Database 10g described in this
chapter will have a detrimental affect on performance, since the statistics
mostly come directly from the SGA, via background processes. The ASH
feature uses about 2MB of SGA memory per CPU.
Current Active Session Data

As you are aware, the V$SESSION view holds all the session data for all current
sessions. The V$SESSION view contains 72 columns of information, so it’s unwieldy
when you are trying to analyze session data. That’s why ASH samples the
V$SESSION view and gets you the most critical wait information from it. Oracle
provides the new V$ACTIVE_SESSION_HISTORY view, which enables you to
Active Session History (ASH) 15
access the ASH statistics. The view contains one row for each active session that ASH
samples and returns the latest session rows first.
V$ACTIVE_SESSION_HISTORY is where the database stores a sample of
all active session data. What is an active session? In the V$ACTIVE_SESSION_
HISTORY view, there is a column called SESSION_STATE, which indicates whether
a session is active. The SESSION_STATE column can take two values: ON CPU
or WAITING. A session is defined as an active session in the following cases:
■ The session state is ON CPU, meaning that it is actively using the CPU to
perform a database chore.
■ The session state is WAITING, but the EVENT column indicates that the
session isn’t waiting for any event in the IDLE class.
Note that the ASH is really a rolling buffer in the SGA; it is an in-memory active
session history. Thus, in a busy database, older information is frequently overwritten,
since ASH collects data every second from the V$SESSION view. ASH stores its
data in V$ACTIVE_SESSION_HISTORY, but this view will contain only session
samples of the most recent active sessions, because the ASH statistics are
overwritten in memory.
Older Active Session History

The new data dictionary view DBA_HIST_ACTIVE_SESSION_HISTORY provides
historical information about recent active session history. In other words, this view
is nothing but a collection of snapshots from the V$ACTIVE_SESSION_HISTORY
view. To put it in simple terms, the DBA_HIST_ACTIVE_SESSION_HISTORY view
samples the V$ACTIVE_SESSION_HISTORY view, which itself is a sample of active
session data.
How does the database populate the DBA_HIST_ACTIVE_SESSION_
HISTORY view? There are two ways to populate the view:
■ During the course of the regular (by default, hourly) snapshots performed
by the AWR, the MMON background process flushes the ASH data to the
AWR. By default, the MMON process performs this data transfer on an
hourly basis.
■ Oracle may also need to transfer data to the DBA_HIST_ACTIVE_HISTORY

view in between the regular snapshots, if the memory buffer is full and you
can’t write new session activity data to it. In this case, the new MMNL
background process will perform the flushing of data from the memory buffer
to the data dictionary view.
Server-Generated Alerts
Oracle DBAs generally use SQL scripts to alert them when abnormal conditions
occur. Oracle Database 10g now has a built-in system of alerts, formally called server-
generated alerts. The Oracle Database 10g Server automatically alerts you when certain
problems occur in the database.
Oracle Database 10g uses a set of indicators called metrics, which show you the
rate of change of a cumulative statistic. A typical example of an Oracle metric is
the number of database calls per second. Once a metric crosses a certain threshold,
Oracle sends an alert to notify you that the target has a problem. Since database
metrics are an important part of server-generated alerts, let’s first take a look at how
you monitor database metrics.
Introduction to Metrics
Metrics are indicators of the health of various database targets. The set of metrics
depends on the target you are measuring. For example, key metrics help you decide if
the host is healthy and if resources like CPU, memory, and I/O are performing at an
acceptable level.
The OEM Database Control’s All Metrics page, shown in Figure 4-2, offers an
excellent way to view the various metrics. To access this page, from the Database
Control home page, click All Metrics under the Related Links heading. From here,
you can view all the metrics in your database. For details, click the Expand All link
in the left corner of the page. If you want the drill down to the details of any specific
metric, just click it.
Server-Generated Alerts 17
FIGURE 4-2 The All Metrics page of database control
Table 4-1 lists the basic metric groups in Oracle Database 10g.
TABLE 4-1 Oracle Database 10g Metric Groups
Metric Description
Event Class Metrics Metrics collected on the wait event class level; for example, DB_TIME_
WAITING
Event Metrics Metrics collected on various wait events
File Metrics Long Duration Metrics collected at the file level; for example, AVERAGE_FILE_WRITE_
TIME
Service Metrics Metrics collected at the service level; for example, CPU_TIME_PER_CALL
Session Metrics Short Metrics collected at the session level; for example, BLOCKED_USERS
(Long) Duration
System Metrics Short Metrics collected at the system level
(Long) Duration
Tablespace Metrics Long Metrics collected at the tablespace level; for example, TABLESPACE_
Duration PCT_FULL.
Viewing In-Memory Metrics

The new MMON background process collects database metrics continuously and
automatically saves them in the SGA for one hour. You can view all the system-
related metrics saved in memory by using views like V$SYSMETRIC_HISTORY and
V$SYSMETRIC. Here, for example, are the typical kinds of system metrics maintained
in the V$SYSMETRIC view:
■ Buffer Cache Hit Ratio

■ CPU Usage Per Sec
■ Database CPU Time Ratio
■ Database Wait Time Ratio
■ Disk Sort Per Sec
■ Hard Parse Count Per Sec
■ Host CPU Utilization (%)
■ Library Cache Hit Ratio
■ SQL Service Response Time
■ Shared Pool Free %
The V$SERVICEMETRIC and V$SERVICEMETRIC_HISTORY views, on the

other hand, provide details about service-level metrics. The V$SERVICEMETRIC
view, for example, contains the ELAPSEDPERCALL and the CPUPERCALL
columns for each service, including the database service. V$SERVICEMETRIC
lists the metrics for the last minute (a few over the last 15 seconds), and
V$SERVICEMETRIC_HISTORY gives them per minute over the last hour.
Viewing Saved Metrics

The only way Oracle will save the metric information that is continuously placed in
its SGA by the MMON process is through the AWR’s snapshot mechanism. As you
know, the AWR takes its snapshots every 60 minutes by default. The AWR’s data-
collection facility includes data pertaining to metrics. The metric data that AWR
collects with the help of the MMON background process is permanently stored in
the DBA_HIST_* views, such as DBA_HIST_SERVICE_NAME and DBA_HIST_
SESSMETRIC_HISTORY.
You can view the current values of any metric by using the V$ views, such as the
V$METRICNAME and V$SERVICEMETRIC views. The MMON process regularly
computes these metrics for you. However, the various performance metrics
stay in the SGA for only an hour. MMON will automatically flush the metric
data from the SGA to the DBA_HISTORY_* views on disk. These history views
maintain a permanent record of the various metrics. Examples of the history
views are DBA_HIST_SUMMARY_HISTORY, DBA_HIST SYSMETRIC_HISTORY,
and DBA_HIST_METRICNAME. Each of these views contains snapshots of the
corresponding V$ view. For example, the DBA_HIST_SYSMETRIC_HISTORY
view contains snapshots of the V$SYSMETRIC_HISTORY view.
Database Alerts
A database alert tells you that there is a potential problem in your database. The potential
problem can occur when a threshold value for a monitored metric is crossed or a database
target simply becomes unavailable. For example, an undo tablespace may trigger the
Long Query Warning alert, thus alerting the DBA about a long-running query that
may fail because the system is running out of free space in the undo tablespace. Oracle
calls the threshold alerts stateful alerts. Oracle calls the types of alerts issued when a
target becomes unavailable stateless alerts.
Threshold-Based Alerts and Problem Alerts

You can set threshold values at two different levels: warning and critical. Thus, there
are three situations when a database can send an alert:
■ A monitored metric crosses a critical threshold value

■ A monitored metric crosses a warning threshold value
■ A service or target suddenly becomes unavailable
We can refer to the first two types of the alerts as threshold-based alerts and the
third type as problem alerts. Problem alerts report problems that occur in the database,
such as an ORA-1555 (snapshot too old) error. Problem alerts are based on a certain
predetermined event (usually bad) occurring in the database.
Threshold-based alerts are based on thresholds for certain objects or events in the
database; for example, a tablespace may be reaching 95 percent of its total allocated
space. Threshold-based alerts thus are dependent on metrics, not events. The
threshold itself could be an internally set level, or you, the DBA, can set your own
alert threshold levels. When a metric crosses a threshold, Oracle automatically
generates an alert to you. In addition, the database can undertake remedial action
to fix the problem (or potential problem), if you specify a response action.
When you use threshold-based alerts, Oracle further makes a distinction between
a warning type alert (severity level 5) and a critical (severity level 1) alert. For
example, by default, the database will send you a warning alert when any tablespace
hits an 85 percent space use threshold. When the usage reaches the 97 percent level,
you get a critical alert.
Default Server-Generated Alerts

Even if you don’t explicitly set any alerts in your database, there are several alerts that
Oracle enables by default when you create an Oracle Database 10g database. These
default server-generated alerts may be either problem alerts or threshold alerts. The
server-generated alerts are very similar to the OEM alerts in prior versions of the
Oracle database.
The following are the default, or out-of-the-box, server-generated alerts:
■ Any snapshot too old errors

■ Tablespace space usage (warning alert at 85 percent usage; critical alert at 97
percent usage)
■ Resumable session suspended
■ Recovery session running out of free space
In addition, Oracle automatically set thresholds on all metrics with the object
type SYSTEM.
The new database alert database cannot write an alert to the alert
system has really nothing to do with the queue, in which case, it records this
alert log of the database. The only time exception in the alert log.
the alert log may be involved is when the
Tablespace usage alerts are space usage for a warning alert and 97
based on the default values of 85 percent percent space usage for a critical alert.
How the Server-Generated Alert Mechanism Works

As you are probably aware, the OEM enables the notification of various types of alerts.
So, what is this new server-generated alert concept? Well, under the old OEM alert
notification system, the OEM was responsible for gathering the metrics and generating
the alerts. In the new Oracle Database 10g server-generated alert system, it is not the
OEM, but rather the database itself that collects the metrics that underlie all alerts.
The new MMON process checks all the available metrics to see if any metric
crosses a preset threshold. When a database reaches a threshold for one of the
monitored variables, Oracle will send you an alert. For example, the Database
Control can alert you, using e-mail or a pager notification, when the database
reaches any tablespace thresholds.
As described in the previous section, your database comes with a set of default
alerts already configured. In addition, you can choose to have other alerts. You may
also change the thresholds for the default alerts. You can perform these tasks with
the help of the OEM Database Control or with Oracle-supplied PL/SQL packages.
Using the Database Control, you can set up notification rules; for example, you
can specify a blackout period for the alerts. When the database issues an alert, you
can see that in the Database Control alert window. In addition, you’ll receive a
notification, if you’ve configured the system to send you one. The alerts usually
are accompanied by a recommendation to fix the problem as well.
Make sure you set the a PL/SQL package to manage system-

STATISTICS_LEVEL parameter to generated alerts. In addition, you can
TYPICAL or ALL, in order to user the display alerts directly by subscribing to
server-generated alerts feature. You can the alert queue (ALERT_QUE).
use either the OEM Database Control or
Managing Alerts
Several new data dictionary views aid in managing both database metrics and server-
based alerts. The following sections explain using the various methods to manage
alerts. Let’s first look at how you can use the OEM Database Control for this purpose.
Using the Database Control to Manage Server Alerts

If you’ve used the Oracle9i OEM, you’re familiar with the Enterprise Manager alerts,
wherein you can configure OEM to alert you when it encounters certain errors in the
database, using a pager or e-mail. Server-generated alerts work in a similar fashion. In
addition to the capability to send alerts, now you can configure alert thresholds as well.
Setting Alert Thresholds It is very easy to set your own warning and critical
thresholds for any database metric. To set alert thresholds, from the Database
Control home page, click the Manage Metrics link, which you’ll find under the
Related Links group. On the Manage Metrics page, click the Edit Thresholds
button. You’ll see the Edit Thresholds page, as shown in Figure 4-3. For each
metric on the Edit Thresholds page, you can set the following:
■ A warning and critical threshold You can set an arbitrary threshold or

compute a threshold based on a set of baselines for a metric. For example, you
may specify that the database should generate a threshold alert if a resource
use is 15 percent higher than its normal baseline values. You may also specify
multiple thresholds.
■ A response action This action can be a SQL script or an operating
system command. Oracle will automatically execute this response action
immediately when the alert is generated. Make sure that you provide the
complete path to the SQL script or operating system command, so the OEM
Management Agent can find it.
Setting Notification Rules When the database needs to send you an alert, it
follows any notification rules that you’ve set up. Notification rules enable you to
choose the conditions under which you want to receive a message from the OEM.
For example, you many not want to be woken up at 2:00 A.M. just because a
tablespace with 100GB allocated space has reached an 80 percent usage level.
On the other hand, you would surely want to know immediately when a 200MB
tablespace has crossed the critical 97 percent usage level.
FIGURE 4-3 Using the Database Control to set alert thresholds
You can use the Database Control to set notification rules. These rules are set
through Preferences. From the Database Control home page, click the Preferences
link (at the very bottom of the page) to go to the Preferences page. Then click the
Rules link in the Notification section. Select any metric, such as Listener Availability,
and click the Edit button. Then you can set notification rules for the selected event,
such as the following:
■ The precise conditions under which you want receive a notification

■ The metrics for which you would like to receive alerts
■ The severity conditions (critical and warning levels) under which you
would like to receive notification
■ The notifications you want to be sent
■ E-mail notification or an advanced notification method, if you’ve
configured one
Using the DBMS_SERVER Package to Manage Alerts

Although the OEM Database Control interface provides an easy way to manage
database alerts, there may be times when you need to incorporate certain changes
inside a PL/SQL program. At times like this, you can use the Oracle-supplied PL/SQL
package DBMS_SERVER_ALERT to set up and modify thresholds on various database
metrics. The DBMS_SERVER_ALERT package has two main procedures: GET_
THRESHOLD and SET_THRESHOLD.
You use the SET_THRESHOLD procedure to define threshold settings for a
database metric. This procedure has the following structure:
SQL> desc dbms_server_alert.set_threshold
PROCEDURE dbms_server_alert.set_threshold
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
METRICS_ID BINARY_INTEGER IN
WARNING_OPERATOR BINARY_INTEGER IN
WARNING_VALUE VARCHAR2 IN
CRITICAL_OPERATOR BINARY_INTEGER IN
CRITICAL_VALUE VARCHAR2 IN
OBSERVATION_PERIOD BINARY_INTEGER IN
CONSECUTIVE_OCCURRENCES BINARY_INTEGER IN
INSTANCE_NAME VARCHAR2 IN
OBJECT_TYPE BINARY_INTEGER IN
OBJECT_NAME VARCHAR2 IN
SQL>
Here’s an example that sets up an automatic alert monitoring of CPU use by each
user in the instance:
DBMS_SERVER_ALERT.SET_THRESHOLD(
DBMS_SERVER_ALERT.CPU_TIME_PER_CALL, DBMS_SERVER_ALERT.OPERATOR_GE, '8000',
DBMS_SERVER_ALERT.OPERATOR_GE, '10000', 1, 2, 'prod1',
DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE,
'main.regress.rdbms.dev.us.oracle.com');
This SET_THRESHOLD procedure example specifies that a warning alert is issued

when CPU time exceeds 8000 microseconds for each user call, and a critical alert is
issued when CPU time exceeds 10,000 microseconds for each user call. The other
key arguments are as follows:
■ CPU_TIME_PER_CALL specifies the metric identifier.

■ The observation period is set to 1 minute. Oracle issues the alert after the
threshold is crossed for 1 minute.
■ The number of consecutive occurrences is set to 2. This is the number of

times the metric value crosses the threshold values before Oracle generates
the alert.
■ The name of the instance is set to prod1.
■ The constant DBMS_ALERT.OBJECT_TYPE_SERVICE specifies the
object type on which the threshold is set. Here, the service name is
main.regress.rdbms.dev.us.oracle.com.
You use the GET_

THRESHOLD procedure to
find out the current threshold
If you don’t want Oracle
settings for any database
to send any metric-based alerts, simply set
metric. You can discover both
the the warning value and the critical value
the warning and critical
to NULL when you execute the DBMS_
thresholds by using this
SERVER_ALERT.SET_THRESHOLD
procedure.
procedure.
Using the Alert Queue

Earlier, you learned how you can view and change threshold settings for the server
alert metrics using the SET_THRESHOLD and GET_THRESHOLD procedures of the
DBMS_SERVER_ALERTS PL/SQL package. Of course, you may also use the OEM
Database Control to manage alerts. In addition, you can use procedures from the
DBMS_AQ and DBMS_AQADM packages for directly accessing and reading alert
messages in the alert queue. The SYS user account owns the alert queue and by
default, the Database Control is the only user of the alert queue. However, Oracle
provides the new DBMS_AQADM package, which consists of various procedures that
help you directly access the alerts stored in the alert queue (ALERT_QUE).
Using the DBMS_AQADM package procedures, you can subscribe to the ALERT_
QUE, set thresholds for alerts, and display alert notifications. Here are some of the
main procedures of the DBMS_AQADM package that help you manage database
alerts:
■ Use the GRANT_SYSTEM_PRIVILEGE procedure to grant AQ system

privileges to users and roles.
■ Use the ADD_SUBSCRIBER procedure to add a default subscriber to a
queue.
■ Use the CREATE_AQ_AGENT procedure to register an agent.
■ Use the ENABLE_DB_ACCESS procedure to grant an AQ Agent-specific

database user’s privileges.
In addition to the DBMS_AQADM package, Oracle also offers the DBMS_AQ

package, which provides a direct interface to the Oracle Streams Advanced
Queuing (AQ) feature. You can use the DBMS_AQ procedure to manage alert
notifications. Here are some of the important procedures of the DBMS_AQ
database package.
■ Use the REGISTER procedure to register for message notifications.

■ Use the DEQUEUE procedure to remove a message from a queue.
Using Data Dictionary Views to Manage Metrics and Alerts

The OEM Database Control is your first stop in the managing of database alerts and the
metrics associated with them. There are also several new data dictionary views that
provide information about database metrics and alerts. I’ve already mentioned the
V$METRICNAME, V$SYSMETRIC, V$SERVICEMETRIC, and V$SYSMETRIC_
HISTORY views earlier in this chapter. Following is a list of some of the other key views:
■ V$ALERT_TYPES displays information about server alert types.

■ DBA_HIST_SYSMETRIC_HISTORY contains snapshots of
V$SYSMETRIC_HISTORY.
■ DBA_ALERT_HISTORY provides a history of alerts that are no longer
outstanding; that is, all alerts that you have already resolved.
■ DBA_OUTSTANDING_ALERTS contains all the stateful (threshold) alerts
that have yet to be resolved.
■ DBA_THRESHOLDS shows the name as well as the critical and warning
values for all thresholds in the database.
I’ll describe a couple of the important views in more detail in the following
sections.
The DBA_OUTSTANDING_ to be resolved. The DBA_ALERT_HISTORY

ALERTS view shows all alerts that have yet view is where all cleared alerts are moved.
V$ALERT_TYPES The V$ALERT_TYPES view provides information about

all system alert types. Three columns in this view are noteworthy:
■ STATE Holds two possible values: stateful or stateless. Stateful alerts are
those alerts that clear automatically when the alert threshold that prompted
the alert is cleared. The database considers all the nonthreshold alerts as
stateless alerts. A stateful alert first appears in the DBA_OUTSTANDING_
ALERTS view and goes to the DBA_ALERT_HISTORY view when it is
cleared. A stateless alert goes straight to DBA_ALERT_HISTORY.
■ SCOPE Classifies alerts into database wide and instance wide. The only
database-level alert is the one based on the Tablespace Space Usage metric.
All the other alerts are at the instance level.
■ GROUP_NAME Oracle aggregates the various database alerts into some
common groups. Here are the common alert groups:
■ Space, such as a suspended session, snapshot too old, or tablespace

out of space
■ Performance, such as elapsed time or CPU time exceeds set thresholds
■ Configuration-related database alerts
DBA_THRESHOLDS The DBA_THRESHOLDS view provides the current

threshold settings for all alerts. This view is useful when you want to find out the
current threshold settings for any alert. Here is a simple example of how to use
the view:
SQL> select metrics_name, warning_value, critical_value,
consecutive_occurrences
from DBA_THRESHOLDS
where metrics_name LIKE '%CPU Time%';
EXERCISE 4-2
Use the DBMS_SERVER_ALERT Package to Set Alert

Thresholds
In the following exercise, you will define a small tablespace and then attempt to create
a large table in it. The database will alert you because you’ll be crossing a threshold
setting for the free space in the tablespace. The example will show you how to set,
view, and clear an alert.
1. Create a test the tablespace using the following command:

SQL> create tablespace test datafile 'test01.dbf' size 1M
extent management local uniform size 200K;
Tablespace created.
2. Set your tablespace alert thresholds as follows (warning alert at 75% full and
critical at 90% full):
SQL> exec dbms_server_alert.set_threshold(-
> dbms_server_alert.tablespace_pct_full,dbms_server_
alert.operator_ge,'75',-
> dbms_server_alert.operator_ge,'90',1,1,null,-
> dbms_server_alert.object_type_tablespace,'TEST');
SQL>
3. When you create a new table using the following SQL statement, you will
set off an alert (because the ‘minextents 4’ clause for the new table will cause
the tablesapce to cross its warning threshold of 75% space full):
SQL> create table test_table (name varchar2(30))
tablespace test
storage (minextents 4);
Table created.
SQL>
4. You can verify the tablespace alert in the following way:

SQL> select reason from dba_outstanding_alerts;
REASON
-----------------------------------------------------
Tablespace [TEST] is [78 percent] full
SQL>
The Automated Tasks Feature 29
5. You can clear the alert by increasing the size of the datafile that is part of the
tablespace named small and see what happens to the alert by querying the
DBA_OUTSTANDING_ALERTS view. You’ll find that the alert is gone from
that view, since it has been cleared.
SQL> alter tablespace test add datafile 'test02.dbf' size 2M;
Tablespace altered.
SQL>
SQL> select reason from dba_outstanding_alerts;
no rows selected
SQL>
6. Where do cleared alerts go? All cleared alerts will show up in the DBA_
ALERT_HISTORY. You can verify that the cleared tablespace alert is in that
view, by using the following query.
SQL> select reason,resolution from dba_alert_history;
REASON RESOLUTION
-------------------------------------------------------------------
Tablespace [TESTNEW] is [13 percent] full cleared
SQL>
The Automated Tasks Feature

Most Oracle DBAs are familiar with using the UNIX crontab feature or the Windows
AT facility to manage their regularly scheduled jobs. Although you can schedule the
jobs, you still must decide when to run these automated tasks. Now, in Oracle
Database 10g, the database itself will perform some of the routine tasks all by itself,
using the new automated tasks feature. For example, in Chapter 3, you learned how
the database now collects its own optimizer statistics, using the Scheduler facility. In
Chapter 1, I also explained how the DBCA lets you automate the maintenance of
backup jobs while you are creating the database.
The new Oracle Scheduler—with its concepts of jobs, job classes, programs, and
operation windows—lies at the heart of the automated tasks feature. Therefore, let’s
start our discussion of the automated tasks feature by briefly looking at the
Scheduler.
An Introduction to the Job Scheduler

The Scheduler can perform very complex scheduling tasks for you, unlike a normal
crontab-based program. The Scheduler is nothing but a set of PL/SQL functions and
procedures, which together provide a facility to schedule and manage database and
operating system jobs. You may run PL/SQL and Java stored procedures and functions,
C functions, regular SQL scripts, and UNIX or Windows scripts using the Scheduler.
The Scheduler consists of the following four important concepts:
■ Program A Scheduler program consists of metadata about what task the

Scheduler will run. A program consists of a specific action, along with
specific arguments to run the task. A task is any executable program, which
you may reuse. You can create several named tasks and store them in the
database.
■ Job A job is a user-defined task that you schedule for running one or more
times. A job class is a group of similar jobs. You create job classes so you can
prioritize the jobs in an orderly way, when you are allocating database
resources.
■ Schedule A schedule indicates when a job should be run. A schedule tells
the database the date, time, and frequency of execution for a job. Schedules
have a start date, an end date, and a repeat interval.
■ Window A window is a time-duration for which you may specify certain
resource allocations. A window has a start date, an end date, and a duration
that specifies how long the window will be open each time it opens. A
window is usually associated with a resource plan (created using the Database
Resource Manager), which specifies how resources should be allocated among
groups of jobs (called job classes). The Scheduler comes with a default
maintenance window group as you saw in Chapter 3. These include the
weeknight window (10:00 P.M. to 6:00 A.M., Monday through Friday) and
the weekend window (12:00 A.M. Saturday to 12:00 A.M. Monday). Oracle
automatically configures these two Scheduler windows when you create any
Oracle Database 10g database.
The Automated Tasks Feature 31
You may use the DBMS_SCHEDULER package to manage various scheduling

activities. You can create and drop jobs, job classes, programs, and windows using
this package. The Scheduler and the DBMS_SCHEDULER package are discussed in
detail in Chapter 7.
Managing Automated Tasks

Oracle schedules several maintenance tasks, including the automatic optimizer
statistics collection job, during the maintenance window (MAINTENANCE_WINDOW_
GROUP). Every Oracle Database 10g database comes with the default program
GATHER_STATS_PROG, the default job GATHER_STATS_JOB, and default job
class AUTO_TASKS_JOB_CLASS.
As you know from Chapter 3, the job GATHER_STATS_JOB executes the
DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedure in order to
collect optimizer statistics for the database. Oracle defines this job on the program
GATHER_STATS_PROG. The job runs in the AUTO_TASKS_JOB_CLASS job
class.
You can use the DBMS_SCHEDULER package to create a new job and add it to
the automated task schedule. You must first create the SQL or PL/SQL code that
will perform the task functions. You can then use the CREATE_JOB procedure to
add this task to the automated task list. Here’s an example:
begin
dbms_scheduler.create_job
(
job_name => 'DAILY_BACKUP_JOB_01',
job_type => 'STORED PROCEDURE',
program_name => 'DAILY_BACKUP_PROGRAM',
schedule_name => 'DAILY_BACKUP_WINDOW'
);
end;
/
You can also use the Database Control interface to manage all aspects of the
Oracle Scheduler, including creating, deleting, and modifying jobs, job classes,
and windows.
The Management Advisory Framework

Oracle Database 10g provides you with several server advisors to provide you with
automatic performance details about various subsystems of the database. For example,
the Undo Advisor tells you what the optimal undo tablespace size might be for your
database. Each of these advisors bases its actions on a specific Oracle PL/SQL package
like the DBMS_ADVISOR package.
The management advisory framework offers you a uniform interface for all Oracle
advisors. Some of these advisors, like the PGA Advisor, have been around since
Oracle9i. What is new is that Oracle has built a Common Manageability Structure
in Oracle Database 10g to make it easy to manage the advisors. This allows you to
use a similar method to invoke all the advisors, and the advisors provide their
reports in a consistent fashion as well. All the advisors get their raw data from the
AWR. They also store their analysis results in the AWR itself.
The advisory framework’s primary function is to help the database improve its
performance. The ADDM recommends using the management advisors on an ad
hoc basis, whenever a performance problem needs a deeper analysis. DBAs can also
use the advisors for performing what-if analyses.
The Advisors
We can group the automatic advisors into the following groups: memory-related,
tuning-related, and space-related. In later chapters, you’ll see a complete discussion
of several of the management advisors. Let’s briefly look at the advisors that fall into
these three groups.
Memory-Related Advisors
Of the three memory-related advisors, two provide information about the SGA and
one provides PGA advice. The following are the memory-related advisors:
■ Buffer Cache Advisor This advisor tells you the benefits in increasing or
decreasing the memory allocation to the BUFFER_CACHE parameter. The
advisor shows the benefit as a decrease in disk I/O.
Obviously, if you are using Automatic Shared Memory Management, you don’t
need the Buffer Cache Advisor or the Library Cache Advisor to tell you how
to size these memory components. Oracle itself will do that for you.
The Management Advisory Framework 33
■ Library Cache Advisor This advisor shows you the impact of changing the
shared pool component of the SGA.
■ PGA Advisor This advisor provides recommendations on optimal allocation
of Program Global Area (PGA) memory, based on your database workload.
Space-Related Advisors
The two space-related advisors are new to Oracle Database 10g:
■ Segment Advisor This advisor allows you to perform growth trend analyses
on various database objects. This advisor also helps you perform object
shrinkage, thus helping you reclaim unused space in your database.
■ Undo Advisor This advisor bases its activities on system usage statistics,
including the length of the queries as well as the rate of undo generation. The
Undo Advisor facilitates Oracle’s Automatic Undo Management feature. It
helps you to correctly size your undo tablespace. It also helps you choose the
correct undo retention parameters.
Tuning-Related Advisors
The ADDM, of course is the most important all-round tuning advisor in the database.
Apart from the ADDM itself, there are two purely SQL tuning-related and
performance-related advisors:
■ SQL Tuning Advisor This advisor analyzes complex SQL statements and
recommends ways to improve performance. The SQL Tuning Advisor bases
all its work on internal statistics and may include suggestions to collect new
statistics as well as SQL code restructuring.
■ SQL Access Advisor This advisor mainly provides you advice on creating
new indexes, materialized views, or materialized view logs. You provide the
advisor a representative workload in order to get the advice.
Most of the database alert messages in the OEM also contain a link to
specific management advisors. Thus, you can invoke a management advisory
directly from the alert message itself.
Managing the Advisory Framework

You can manage all aspects of the management advisory framework easily, using the
Database Control interface. You can also use the DBMS_ADVISOR package to create
and manage tasks for each of the management advisors.
Using the DBMS_ADVISOR Package

You can invoke any of the management advisors through the OEM interface, using
various wizards like the SQL Access Advisor Wizard. However, you may also run any
of the advisors using the DBMS_ADVISOR package. Before a user can use any of the
advisors, you must grant the user the ADVISOR privilege, as shown here:
SQL> grant advisor to oe;
Grant succeeded.
SQL>
The following are the steps you must follow in order to use the DBMS_ADVISOR
package to manage various advisors:
■ Create a task
■ Adjust task parameters
■ Perform the analysis
■ Review the advisor recommendations
These steps are described in the following sections.
Creating a Task The first step in using an advisor is creating a task. A task is
where the advisor stores all its recommendation-related information. You create a
task using the CREATE_TASK procedure, as shown here:
VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
EXECUTE :task_name := 'TEST_TASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK ('SQL Access Advisor', :task_id,
:task_name);
Defining the Task Parameters After you create a new task, the next step is
to set the parameters for this task. The task parameters control the recommendation
process. The parameters you can modify belong to four groups: workload filtering,
task configuration, schema attributes, and recommendation options.
Use the DBMS_ADVISOR purposes. These steps are creating

package to manage any modules in the a task, adjusting task parameters,
advisory framework. You follow identical performing the analysis, and reviewing
steps to use any advisor for tuning the recommendations of the advisor.
Here is an example showing how you can set various task parameters using the
SET_TASK_PARAMETER procedure:
SQL> EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
'TEST_TASK', 'VALID_TABLE_LIST', 'SH.SALES, SH.CUSTOMERS');
In this example, the VALID_TABLE_LIST parameter belongs to the workload

filtering group of parameters. You are instructing the advisor (the SQL Access
Advisor) to exclude all tables from the analysis, except the sales and customers
tables, from the SH schema.
The following example uses the STORAGE_CHANGE parameter from the
recommendation options group to add 100MB of space to the recommendations.
SQL> EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER('TEST_TASK','STORAGE_CHANGE',-
100000000);
Generating the Recommendations To generate a set of recommendations

by any advisor, you execute the task that you created earlier, using the EXECUTE_
TASK procedure of the DBMS_ADVISOR package. The EXECUTE_TASK
procedure will generate recommendations, which consist of one or more actions.
For example, excuting the SQL Access Advisor may provide a recommendation to
create a materialized view and a materialized view log. Here’s how you execute a task
named TEST_TASK:
SQL> EXECUTE DBMS_ADVISOR.EXECUTE_TASK('TEST_TASK');
Viewing the Recommendations You can view the recommendations of the

advisor task by using the GET_TASK_REPORT procedure. You may also use the
DBA_ADVISOR_RECOMMENDATIONS view to check the recommendations, as
shown in the following example:
SQL> select rec_id, rank, benefit
from DBA_ADVISOR_RECOMMENDATIONS WHERE task_name = 'TEST_
TASK’;
REC_ID RANK BENEFIT
---------- ---------- ----------
1 2 2754
2 3 1222
3 1 5499
4 4 594
In this example, the RANK column shows how the four recommendations stack
up against each other. The BENEFIT column shows the decrease in the execution
cost for each of the four recommendations.
Using the Database Control to Manage the Advisory Framework

The best way to use the management advisors is through the OEM Database Control.
All you need to do is to click the Advisor Central link on the Database Control home
page. From the Advisor Central page, shown in Figure 4-4, you can select any of the
management advisors in your database.
Using Dictionary Views to Manage the Advisory Framework

Several new data dictionary views provide information about managing tasks, as well
recommendations made by the various advisors. Here are the main advisor-related
dictionary views:
■ DBA_ADVISOR_TASKS
■ DBA_ADVISOR_PARAMETERS
■ DBA_ADVISOR_FINDINGS
■ DBA_ADVISOR_RECOMMENDATIONS
■ DBA_ADVISOR_ACTIONS
■ DBA_ADVISOR_RATIONALE
FIGURE 4-4 The Advisor Central page in OEM Database Control
INSIDE THE EXAM
The test looks at your knowledge of the add subscriber, and so on). The exam tests
Automatic Workload Repository (AWR) in your knowledge of the types of events that
depth. You must be aware of the in-memory set off server-generated alerts. What are the
and persistent portions of the AWR and the default tablespace usage alert settings? What
mechanism that records the AWR statistics on are the various nonthreshold, or stateless,
disk. How do you create an AWR report? alerts?
What are the options during the report The exam tests you on your knowledge
creation process? Be aware that the Active of the PL/SQL interface for alert threshold
Session History (ASH) is a component of the settings, which is the DBMS_SERVER_ALERT
AWR, and that it focuses on current session package. You must know exactly what each
activity. You must also understand the role of of the SET_THRESHOLD parameters stands
the background processes MMON and MMNL for. How do you set the critical and warning
clearly. thresholds to NULL? You must also know the
You must know all the default settings, like different components of the DBMS_ADVISOR
how long the AWR retains information and package that help you in creating an advisor
how often AWR snapshots occur. How do you tuning session (create task, adjust task
change these settings? parameters, perform analysis, and review the
You must be aware of the various pages of results). The test checks your knowledge of
the Database Control that you must traverse in important data dictionary views like DBA_
order to manage the automatic alerts in your OUTSTANDING_ALERTS (where outstanding
database. You can expect a question (or more) alerts are stored) and DBA_ALERT_HISTORY
about custom configuration of alerts using the (where cleared alerts go).
DBMS_AQADM package (create AQ Agent,
This chapter introduced the new AWR feature, which is central to Oracle Database
10g’s performance tuning. You reviewed the different kinds of data stored in the AWR
and how to manage the AWR by using the DBMS_WORKLOAD_REPOSITORY package.
You learned how to create and manage AWR snapshots and baselines. The chapter
also explained the ASH statistics, which are a key part of the AWR.
In the server-generated alerts section, you saw how Oracle generates automatic
alerts. You learned how to use the Database Control to manage server alerts. The
chapter showed you how to set alerts using the DBMS_SERVER_ALERT package.
The chapter introduced you the Oracle’s automated tasks feature using the
Scheduler. You also learned about the various Oracle management advisors.
You reviewed the use of the DBMS_ADVISOR package to manage the advisory
framework.
Two-Minute Drill 39
❑ Oracle collects database statistics at the system and session level, as well as
operating system statistics.
❑ Cumulative statistics are totals of various statistics since the startup of the
instance.
❑ Both the V$SYSSTAT and V$SESSTAT views show cumulative
performance statistics.
❑ Database metrics measure the rate of a change in a cumulative statistic.
❑ Database metrics are statistics that are derived from base statistics.
❑ The MMON background process issues database alerts and captures statistics
for recently modified objects.
❑ The MMNL background process captures ASH history data when the
memory buffer is full.
❑ ASH data is a sample of the most recent session data for all active sessions.
❑ Baseline data helps you to make meaningful comparisons of database
performance between two periods.
❑ If you set the STATISTICS_LEVEL parameter to BASIC, the AWR turns
off its statistics collection.
❑ If you set the STATISTICS_LEVEL parameter to ALL, the AWR collects
all available statistics.
❑ If you set the STATISTICS_LEVEL to TYPICAL, the AWR collects what
Oracle considers is a typically needed amount of statistics.
Automatic Workload Repository (AWR)

❑ The AWR lies at the heart of the Oracle Database 10g self-management
framework.
❑ The AWR collects statistics in a temporary in-memory format, as well as
a persistent component in the form of regular AWR snapshots.
❑ The MMON background process performs the AWR snapshots.
❑ By default, the AWR collects new snapshots every 60 minutes, but you can
change this interval.
❑ You can also collect manual snapshots yourself.
❑ You uniquely identify a snapshot by its snap ID sequence number.
❑ The AWR collects base, database feature, and object usage; ASH; operating
system; and other statistics.
❑ Managing the AWR snapshots enables you to manage the AWR.
❑ You can view AWR snapshot data through V$ views or the
Database Control interface.
❑ The Manage Snapshots section of the AWR page in the Database Control
lets you manage snapshots.
❑ You can use the DBMS_WORKLOAD_REPOSITORY package to create and
drop snapshots, as well as to change the settings of the RETENTION and
INTERVAL parameters.
❑ A snapshot baseline consists of any pair of AWR snapshots.
❑ A preserved snapshot set shows the range of snapshots you use for an AWR
baseline.
❑ You can create and drop baselines using the DBMS_WORKLOAD_
REPOSITORY package’s CREATE_BASELINE and DROP_BASELINE
procedures.
❑ By default, the AWR retains snapshot data for seven days, before
automatically purging the data. You may modify this default behavior.
❑ The minimum retention period for AWR data is one day.
❑ The minimum interval value for AWR data collection is ten minutes.
❑ If the SYSAUX tablespace fills up, Oracle will automatically purge the oldest
set of AWR snapshots.
❑ The longer the AWR retention period, the larger you should make your
SYSAUX tablespace.
❑ The shorter the AWR snapshot interval, the larger you should make your
SYSAUX tablespace.
❑ Oracle recommends that you set your retention period according to the
length of your database workload cycle.
Two-Minute Drill 41
❑ If you set the value of the RETENTION parameter to zero, you disable the
automatic purging of the AWR.
❑ If you set the INTERVAL parameter to zero, you disable the automatic
snapshot collection by the AWR.
❑ Use the $ORACLE_HOME/rdbms/admin/awrrpt.sql script to produce AWR
reports.
❑ The AWR reports are very similar to the old STATSPACK reports.

❑ The ASH collects active session statistics and stores them in the SGA.
❑ The V$SESSION view is sampled every second, and the samples are saved to
the V$ACTIVE_SESSION_HISTORY view.
❑ A database session is termed active, if either it is ON CPU or it is WAITING
for an event that isn’t from the IDLE class.
❑ The DBA_HIST_ACTIVE_SESSION _HISTORY view maintains a
permanent record of a sample of the ASH data in the V$ACTIVE_
SESSION_HISTORY view.
❑ The background process MMON is responsible for flushing ASH data to disk
periodically.
❑ If the memory buffer for the ASH is full, the ASH data is flushed to disk by
the MMNL background process.
❑ Database metrics are the foundation for all Oracle alerts.
❑ The set of metrics for each alert depends on the targets that are covered.
Threshold alerts are prompted when a database metric crosses a preset
threshold value.
❑ Threshold alerts are also called stateful alerts.
❑ Error or problem alerts, which are issued because a service or target becomes
unavailable, are also called stateless alerts.
❑ When you fix the problems that prompted an alert, the alert is cleared
automatically.
❑ Threshold-based alerts are divided into warning and critical types.
❑ Default server-generated alerts may be problem alerts or threshold alerts.

❑ Oracle automatically sets thresholds on all metrics with the object type
SYSTEM.
❑ The MMON process computes metrics and decides when a threshold has
been crossed for a database metric.
❑ Set the STATISTICS_LEVEL parameter to TYPICAL if you want
to use the server-generated alerts feature.
❑ You can display alerts directly by subscribing as a consumer to the
ALERT_QUE.
❑ You can view current threshold settings by using the GET_THRESHOLD
procedure from the DBMS_SERVER_ALERT package.
❑ You can set thresholds by using the SET_THRESHOLD procedure.
❑ You can prevent any database alert from firing, by setting the critical or
warning threshold values to NULL.
❑ The procedures in the DBMS_AQADM package enable you to access the alerts
in the ALERT_QUE.
❑ The REGISTER, DEQUEUE, and other procedures of the DBMS_AQ
package help you manage alert notifications.
❑ Database metrics history is maintained by the DBA_HIST_* dictionary
views.
❑ The DBA_THRESHOLD dictionary view provides current threshold settings
for all alerts.
❑ The DBA_OUTSTANDING_ALERTS view stores information about all
pending alerts, and the DBA_ALERT_HISTORY view provides a history
of all resolved alerts.
Two-Minute Drill 43

❑ The Oracle Scheduler is at the heart of the automated tasks feature.
❑ A program consists of metadata about a task.
❑ A job is any executable program.
❑ A schedule sets the execution time and frequency for a job.
❑ A window is a time period during which you schedule a job.
❑ By default, Oracle comes with a maintenance window, the GATHER_
STATS_PROG program, the GATHER_STATS_JOB job, and the AUTO_
TASKS_JOB_CLASS job class.

❑ The management advisory framework provides performance details about
various subsystems of the database.
❑ All management advisors get their raw data from the AWR repository and
store their analysis in the AWR as well.
❑ The main advisors are the ADDM, Buffer Cache Advisor, Library Cache
Advisor, SQL Access Advisor, SQL Tuning Advisor, Segment Advisor,
and Undo Advisor.
❑ You can use the DBMS_ADVISOR package to run any of the advisors.
❑ To use an advisor, you create a task, define the task parameters, execute the
task, and view the recommendations.
SELF TEST

1. What type of statistic is total logons?
A. Cumulative statistic
B. Baseline statistic
C. Database metric
D. Type of sample data
2. Which of the following statements is true?
A. Base statistics are derived from database metrics.
B. Metrics are derived from base statistics.
C. The number of physical reads in the database is a metric.
D. Cumulative statistics are derived from database metrics.
3. Which of the following Oracle background processes is responsible for updating metric
statistics?
A. MMAN
B. MMNL
C. MMON
D. MMMN

4. What is the persistent portion of the AWR represented by?
A. The statistics stored in the SGA by the AWR
B. Statistics shown by the V$ dynamic performance views
C. The AWR snapshots
D. Active Session History data
5. Which is the following is true about snapshots belonging to a baseline?
A. They are retained permanently in the database (never deleted).
B. They are deleted when you drop the underlying baselines, provided you specify the
CASCADE=>TRUE option.
Self Test 45
C. They are deleted immediately after you use them.

D. They are deleted when you create any new snapshots.
6. Your SYSAUX tablespace is under space pressure. The AWR currently has data ranging from
snap ID 101 to 322.Which of the following scenarios is the likeliest outcome?
A. Oracle will delete everything from the SYSAUX tablespace except the information for the
snap ID range 101 to 322.
B. Oracle will delete snapshot 101.
C. Oracle will delete snapshot 322.
D. Oracle will send an error message saying that it can’t create any more new AWR snapshots.

7. Which of the following two statements regarding the V$ACTIVE_SESSION_HISTORY and
DBA_HIST_ACTIVE_SESS_HISTORY views are correct?
A. The V$ACTIVE_SESSION_HISTORY is a collection of snapshots from the DBA_HIST_
ACTIVE_SESS_HISTORY view.
B. The DBA_HIST_ACTIVE_SESS_HISTORY view is a collection of snapshots from the
V$ACTIVE_SESSION_HISTORY view.
C. The V$ACTIVE_SESSION_HISTORY view shows only the current active session history.
D. The V$ACTIVE_SESSION_HISTORY view shows recent active session history.
8. Which of the following statements regarding how ASH data is flushed are true?
A. The MMON process flushes ASH data to disk whenever the rolling buffer in memory
is full.
B. The MMNL process flushes ASH data to disk whenever the rolling buffer in memory is full.
C. The MMON process flushes ASH data to disk automatically every 60 minutes.
D. The MMNL process flushes ASH data to disk automatically every 60 minutes.
9. What will the AWR save?
A. All the ASH data
B. A part of the ASH data
C. All the active session ASH data
D. All the inactive session ASH data
10. Stateful alerts are those alerts that pertain to thresholds. Stateless alerts pertain to problem
alerts. Which of the following two statements are true?
A. Stateful alerts are first logged in the DBA_ALERT_HISTORY view.
B. Stateful alerts are first recorded in the DBA_OUTSTANDING_ALERTS view.

C. Stateless alerts are never recorded in the DBA_OUTSTANDING_ALERTS view.
D. Stateful alerts are never recorded in the DBA_OUTSTANDING_ALERTS view.
11. Threshold alerts are stateful alerts. What happens when these occur?
A. Oracle will automatically clear the alert when you take care of the alert condition.
B. You need to manually clear the alert after you take care of the alert condition.
C. The alert can’t be cleared automatically or manually.
D. The alert is automatically recorded in the DBA_ALERT_HISTORY view.
12. Which three of the following statements are correct?
A. The snapshot too old alert is a stateful alert.
B. The snapshot too old alert is a stateless alert.
C. The snapshot too old alert is an out-of-the-box server-generated alert.
D. All stateless alerts are recorded directly in the DBA_ALERT_HISTORY view.

13. Which two of the following statements are correct?
A. The MMON background process saves metrics in the SGA.
B. The AWR snapshot mechanism saves the in-memory metrics to disk.
C. The AWR snapshots save metrics in the SGA.
D. The MMON background process flushes metrics to the disk every hour.
14. You can set up thresholds on metrics using which view?
A. V$SYSMETRIC
B. V$DBMS_SERVER
C. DBA_SERVER
D. V$DBMS_SERVER_ALERT
14. When is subscribing to the ALERT_QUE necessary?
A. If you wish to use the server-generated alert system of the OEM Database Control
B. If you wish to set up a notification system for server-generated alerts
C. If you wish to set up your own tool to display alerts, instead of using the OEM Database
Control interface
D. For only critical alerts
Lab Question 47
16. Which response best describes a resource plan?

A. Mandatory for every Job Scheduler window
B. Optional for any Job Scheduler window
C. Can’t be used with the Job Scheduler
D. Can only be used if you also use a Job Class item

17. Which of the following can you use to manage the database advisory framework?
A. DBA_ADVISOR
B. DBMS_ADVISOR
C. V$ADVISOR
D. DBMS_MANAGEMENT_ADVISORY
18. What is the first step in using PL/SQL packages to manage the advisory framework?
A. Create a task report
B. Create an advisory task
C. Execute the advisory task
D. Set the task parameters
19. What privilege do you need to execute any advisor procedures?
A. EXECUTE ANY ADVISOR
B. SELECT_ANY_CATALOG
C. ADVISOR
D. SCHEMA OWNER
20. Which of the following two statements are true regarding the SQL Access Advisor?
A. It advises about the use of indexes and materialized views.
B. It provides SQL tuning advice.
C. It provides both SQL tuning and object access advice.
D. It can be called by the ADDM.
LAB QUESTION
Use the manual method to get the ADDM results for a pair of snapshots gathered by the AWR.
After the ADDM analysis, show how you would get the report. (Hint: Use the DBMS_ADVISOR
package.)
SELF TEST ANSWERS

1. þ A. The number of total logons is a cumulative statistic, because it counts all the logons
since you started the instance.
ý B, C, and D are wrong answers, since none of them is a cumulative statistic.
2. þ B. Metrics are derived statistics, and their source is the base statistics.
ý A is wrong because base statistics aren’t derived from database metrics; it’s the other way
around. C is wrong because the number of physical reads is a cumulative statistic, not a metric,
which measures the rate of change, not the absolute size of a statistic. D is wrong because
cumulative statistics are derived from base statistics.
3. þ C. The MMON process updates the metric statistics.
ý A, C, and D point to the wrong or a nonexistent background processes.

4. þ C. AWR snapshots capture the persistent portion of the AWR data.
ý A is wrong because statistics stored in the SGA aren’t persistent. B is wrong because the
V$ views show only the in-memory statistics. D is wrong because ASH data represents only
temporary, in-memory data.
5. þ B. The set of snapshots belonging to a baseline are automatically deleted when you drop
that baseline.
A is wrong because snapshots can be deleted. C is wrong because there is no automatic
mechanism to drop the snapshots after using them. D is wrong because there is no connection
between creating new snapshots and dropping old ones.
6. þ B. When you are under space pressure, Oracle ignores the default retention policy and
deletes the oldest snapshots first, to make room for new data. Snap ID 101 happens to be the
oldest in this example.
ý A is wrong because Oracle deletes only the old snapshots first, not other data from the
SYSAUX tablespace. C is wrong because the snapshot with the ID 322 is the most recent, not
the oldest snapshot in the AWR. D is wrong because while Oracle sends an error message, the
message is to inform you that there is a space problem in the SYSAUX tablespace.

7. þ B and D. B is correct because the DBA_HIST_ACTIVE_SESS_HISTORY view shows a
sample of the contents of the V$ACTIVE_SESSION_HISTORY view. D is correct because
the V$ACTIVE_SESSION_HISTORY view shows recent active session history.
ý A is wrong because the V$ACTIVE_SESSION_HISTORY view is the source for the
DBA_HIST_ACTIVE_SESS_HISTORY view, not the other way around. C is wrong since the
view shows only recent, not current active session history.
8. þ B and C. The MMNL process flushes AWR data only when the memory buffers are full. C
is correct because the MMON background process is responsible for automatic flushing of ASH
data every 60 minutes, by default.
ý A is wrong since it is the MMNL process, not MMON, that flushes data to disk when the
memory buffers are full. D is wrong because the MMNL doesn’t flush on schedule to disk—it is
the MMON process that performs the periodic flushing to disk.
9. þ B. The AWR saves only a sample of the ASH data.
ý A is wrong because the AWR doesn’t store all of the ASH data. C is wrong because this is
similar to A. D is wrong because the ASH facility doesn’t capture inactive session data.
10. þ B and C. B is correct because all stateful (problem) alerts are recorded in the DBA_
OUTSTANDING_ALERTS view first. C is correct because the same isn’t true for stateless
alerts—they aren’t recorded in the DBA_OUTSTANDING_ALERTS view.
A is wrong because stateful alerts go into the DBA_ALERT_HISTORY view only after
they are resolved, not when they are first reported. D is wrong since B is correct.
11. þ A. When you clear a stateful (problem) error, Oracle will clear the alert automatically.
B is wrong since you don’t need to manually clear alerts. C is wrong because the alerts are
cleared automatically. D is wrong because the alerts are recorded in the DBA_
OUTSTANDING_ALERTS view first, not the DBA_ALERT_HISTORY view.
12. þ B, C, and D. B and C are correct because the snapshot too old alert is an out-of-the-box,
server-generated alert and is considered stateless. D is correct because stateless alerts are directly
written to the DBA_ALERT_HISTORY view.
A is wrong because the error is stateless.
13. þ B and D. The AWR snapshots are the means through which the MMON process flushes
metrics to disk on an hourly basis.
A is wrong because the MMON process isn’t responsible for in-memory statistics. C is
wrong because the AWR doesn’t save metrics in the SGA—it saves them on disk.

14. þ D. The DBMS_SERVER_ALERT view enables you to set up thresholds on metrics, using
the SET_THRESHOLD procedure.
ý A, B, and C point to the wrong views.
15. þ C. You must use the ALERT_QUE mechanism only if you want to set up your own tool to
display alerts.
ý A is wrong because you don’t need to subscribe to the ALERT_QUE mechanism if you
wish to use server-generated alerts through the Database Control. The OEM Database Control
is already a registered for the ALERT_QUE. B is wrong because you don’t need to set up alert
notification. D is wrong because the ALERT_QUE doesn’t have anything to do with critical
alerts.
16. þ B. A resource manager is usually associated with a window, but a window doesn’t have to
use it.
ý A is wrong because resource plans aren’t mandatory. C is wrong because you can use
resource plans with the Scheduler. D is wrong since you don’t have to specify a Job Class in
order to use a resource plan with the Scheduler.

17. þ B. You must use the DBMS_ADVISOR package to manage the advisory framework.
ý B, C, and D point to wrong or nonexistent views and packages.
18. þ B. The first step in using the DBMS_ADVISOR package, which helps you manage the
advisory framework, is to create an advisory task.
ý A, C, and D present the various steps in the wrong sequence.
19. þ C. You must have the ADVISOR privilege to execute any advisor privileges in the
database.
ý A, B, and D provide wrong or nonexistent privileges.
Lab Answer 51
20. þ A and D. A is correct because the SQL Access Advisor advises you about the best access
to objects, including using indexes. D is correct since the ADDM can call any of the
management advisors to provide an in-depth analysis of a performance problem.
ý B is wrong since the SQL Access Advisor doesn’t provide any direct SQL tuning advice.
C is wrong for the same reason that B is a wrong answer.
LAB ANSWER
First, define the bind variables:
SQL> VARIABLE taskname VARCHAR2(40)
SQL> VARIABLE taskid NUMBER
Next, create the advisory task:

SQL> exec dbms_advisor.create_task('ADDM', :taskid, :taskname);
Then set the task parameters:

SQL> exec dbms_advisor.set_taskparameter(:taskname, 'START_
SNAPSHOT',20);
SQL> exec dbms_advisor.set_task_parameter():taskname, 'END_
SNAPSHOT',24);
Execute the task:

SQL> exec dbms_advisor.execute_task(:taskname);
Finally, get the analysis results:

SQL> select dbms_advisor.get_task_report(:taskname)
from dba_advisor_tasks t
where t.task_name=:taskname AND
t.owner=SYS_CONTEXT('USERENV', 'SESSION_USER');
Blind Folio 5:241
5
Application Tuning
5.01 Using the New Optimizer Statistics 5.05 Indexing Enhancements

5.02 Using the SQL Tuning Advisor ✓ Two-Minute Drill
5.03 Using the SQL Access Advisor Q&A Self Test
5.04 Using the Performance Pages of the
Database Control
Tuesday, September 14, 2004 3:23:17 PM
242 Chapter 5: Application Tuning
O racle DBAs spend a considerable amount of their time tuning resource-guzzling SQL
statements, so they can reduce the load on their databases and increase throughput.
The new Automatic Database Diagnostic Monitor (ADDM) makes the identification
of these offending SQL statements considerably easier, basing its sophisticated recommendations
on the performance data gathered by the Automatic Workload Repository (AWR).
This chapter introduces you to the new SQL Tuning Advisor, which helps you
perform the new art of SQL profiling, whereby you help the Oracle optimizer generate
better-tuned execution plans.
There are several changes in the way you can collect optimizer statistics, and this
chapter explain these in detail. You’ll learn how to use the new SQL Access Advisor
to define better access structures like indexes. Finally, you’ll learn how to use the
Performance pages of the OEM Database Control to effortlessly perform your SQL
tuning exercises.
In the new database, there are several enhancements regarding the ability to skip
unusable indexes, and to create and maintain hash-partitioned global indexes. The
final part of this chapter discusses these and other issues, such as specifying storage
characteristics for index partitions.
Let’s start this important chapter with a summary of the changes in optimizer
statistics in Oracle Database 10g.
Using the New Optimizer Statistics

There are several interesting changes in the area of optimizer collection and the optimizer
modes. Oracle supports only the cost-based query optimizer. The rule-based optimizer is
finally obsolete in Oracle Database 10g, although it remains as an unsupported feature.
This means that the CHOOSE and RULE values are no longer supported as OPTIMIZER_
MODE initialization parameters, although, technically, you can still use them. The same
is true of the CHOOSE and RULE hints as well.
Following are the important enhancements and changes in the optimizer’s behavior
and statistics collection areas.
Using the New Optimizer Statistics 243
Automatic Statistics Collection

As you learned in the previous chapter, Oracle
The default value for automatically collects optimizer statistics for
the OPTIMIZER_MODE initialization you now, using the GATHER_STATS_JOB job.
parameter is ALL_ROWS. The ALL_ROWS Oracle uses the GATHER_DATABASE_STATS_
mode optimizes the throughput of the JOB_PROC procedure to collect optimizer
system, which means that it will minimize statistics on an automatic basis. Oracle identifies
the resource cost for executing the entire the objects whose optimizer statistics it needs to
SQL statement and returning all the rows. refresh by using the information stored in AWR.
It uses the Scheduler to run the statistics collection
task in the predefined “maintenance window.”
GATHER_DATABASE_STATS_JOB_PROC procedure collects statistics for all
objects that have no prior statistics or have stale statistics, because a large proportion
of the rows (more than 10 percent) have been modified.
You can still use the DBMS_STATS.GATHER_DATABASE_STATS procedure
(with the GATHER AUTO option) to gather similar statistics yourself. However, the
big difference is that Oracle prioritizes its optimizer collection, ensuring that it collects
statistics for objects that have stale or outdated statistics before the maintenance
window is up.
The Cost Model

The default cost model in Oracle Database 10g is CPU+IO. The computing of both
CPU as well as I/O usage gives the optimizer a good idea of the true cost of SQL
statements. Oracle captures the CPU information when you start the instance.
Changes in the
DBMS_STATS Package
The DBMS_STATS package has several changes,
The automatic statistics including changes in the key GATHER_
gathering feature is enabled by default. If DATABASE_STATS and GATHER_SCHEMA_
you wish to disable it, you can do so by STATS procedures. There are new values for
executing the following: the GRANULARITY argument in both of these
DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB'); procedures. The GRANULARITY argument is
pertinent only if the underlying table is partitioned.
AUTO is the default value for this argument. If you specify AUTO as the granularity
level, Oracle collects global-, partition-, and subpartition-level statistics, if you use
the LIST subpartitioning method (otherwise, it skips the subpartition-level statistics).

If you specify GLOBAL and PARTITION as the options, Oracle doesn’t collect
subpartition-level statistics.
You have the option of running statistics collection serially or in parallel. The
DEGREE parameter of the DBMS_STATS package determines the degree of parallelism.
The argument now has a new value called AUTO_DEGREE, which means that Oracle
will automatically determine the degree of parallelism. It could be 1, which implies
serial, not parallel execution, or DEFAULT_DEGREE, which is system default degree
of parallelism, based on the initialization parameters pertaining to parallelism. Oracle
recommends that you let it select the degree of parallelism based on size of the object,
number of CPUs, and cetain parallelism-related initialization parameters.
Dynamic Sampling
You may, on occasion, encounter situations where you have database objects whose
statistics are suspect or are missing altogether. In cases like this, the database will
calculate if it is advantageous to estimate statistics using a small sample of the object’s
data. This feature is called dynamic sampling, and it has been available since Oracle9i.
If you execute a query numerous times or if the query is very time-consuming, dynamic
sampling may benefit that SQL statement, by yielding superior execution plans.
If you want to use automatic dynamic sampling in your database, set the
OPTIMIZER_DYNAMIC_SAMPLING initialization parameter to at least 2 (the
default value). If you set the level to zero, Oracle won’t perform dynamic sampling.
If you set it too high, you’ll be imposing an unacceptable burden on your database.
Table Monitoring
If you use either the GATHER AUTO or STALE settings when you use the DBMS_STATS
package, you don’t need to explicitly enable table monitoring in Oracle Database 10g;
Table monitoring tracks the number of DML changes to a table since the last statistics
collection. In previous versions, you had to specify the MONITORING keyword in the
CREATE (or ALTER) TABLE statement in order to enable the DBMS_STATS package
to automatically gather statistics for a table. In Oracle Database 10g, the MONITORING
and NO MONITORING keywords are deprecated. Oracle uses the DML change information
logged in the DBA_TAB_MODIFICATIONS view to determine which objects have
stale statistics. Just make sure that you set the STATISTICS_LEVEL parameter to
either the default TYPICAL or ALL setting.
Using the New Optimizer Statistics 245
If you use the GATHER_ database objects that have changed enough
DATABASE_STATS or GATHER_DATABASE_ to warrant fresh statistics. Make sure you
STATS procedure of the DBMS_STATS haven’t set the STATISTICS_LEVEL
package with OPTIONS set to GATHER parameter to BASIC, because this turns
AUTO, you’ll be analyzing only those off the default table monitoring feature.
Statistics Collection for Dictionary Objects

Oracle Database 10g allows you to collect optimizer statistics on data dictionary tables
to enhance performance. Oracle has two basic types of dictionary objects (dictionary
tables): fixed and real. All dynamic performance tables are fixed tables, since you can’t
alter or remove them. The real dictionary tables belong to the SYS, SYSTEM, and
other schemas that own the various Oracle components.
Collecting Statistics for Fixed Objects

Oracle recommends that you gather statistics for fixed objects only once for every
database workload. Typically, a workload is a week for most OLTP databases. You can
gather fixed object statistics by using the GATHER_DATABASE_STATS procedure
and setting the GATHER_FIXED argument to TRUE (the default is FALSE).
You can also gather statistics for all fixed objects by using the new GATHER_FIXED_
OBJECTS_STATS procedure of the DBMS_STATS package, as shown here:
SQL> sho user
USER is "SYS"
SQL> exec dbms_stats.gather_fixed_objects_stats('ALL');
You must have the SYSDBA or ANALYZE ANY DICTIONARY system privilege
to analyze any dictionary objects or fixed objects.
If you wish, you can collect statistics for an individual fixed table by using the
standard DBMS_STATS procedures that enable table-level statistics collection. Then
you can collect statistics for a fixed table just as would for any regular database table.
Collecting Statistics for Other Dictionary Objects

You can collect statistics for the real dictionary tables by using one of the following
methods:
■ Use the DBMS_STATS.GATHER_DATABASE_STATS (or GATHER_

SCHEMA_STATS) procedure, by setting the GATHER_SYS argument to TRUE.
Alternatively, you can use the GATHER_SCHEMA_STATS ('SYS') option.
■ Use the DBMS_STATS.GATHER_DICTIONARY_STATS procedure.
Using the SQL Tuning Advisor

Let’s say you ask the ADDM to look into some performance problem, and you finally
find out what ails your database: not surprisingly, poor SQL statements are slowing
down the database again. What do you do? Normally, this is where your troubles begin,
because you now embark on a journey that could be highly frustrating and time-
consuming. Oracle Database 10g has a much better option for you. When you need
to fix bad SQL, just turn the new SQL Tuning Advisor loose. The advisor will tell
you the following:
■ How to improve the execution plan

■ Why it recommends a certain fix
■ Estimated benefits if you follow its advice
■ How to implement its recommendations (this may be the best part, as the
advisor even gives you the actual commands necessary to tune the offending
SQL statements)
Providing SQL Statements to the SQL Tuning Advisor

Where does the SQL Tuning Advisor get the highly resource-intensive SQL statements
to conduct its analysis? You can feed the advisor SQL statements that you may gather
from the following sources:
■ You may create a new SQL statement or set of statements as an input for
the SQL Tuning Advisor. Especially if you are working with a development
database, this may be your best source of questionable SQL statements.
Using the SQL Tuning Advisor 247
■ The ADDM may often recommend high-load statements.

■ You can choose a SQL statement that’s stored in the AWR.
■ You may choose a SQL statement from the database cursor cache.
If you have a set of SQL statements that you want the advisor to tune, you can
create a SQL Tuning Set (STS), which is a set of multiple SQL statements, along
with their execution information like the average elapsed time and bind values.
Isolated SQL statements sometimes fail to capture the characteristics of your database
workload realistically. An STS not only captures a database workload’s information
effectively, but also simplifies the tuning of several large SQL statements at once.
Note that you can also use one or more STSs as the basis for a new STS.
How the SQL Tuning Advisor Works

Once you hand the SQL Tuning Advisor a SQL statement or an STS to analyze, the
advisor invokes the Oracle optimizer in a new mode, called the tuning mode. As you
recall, the optimizer always tries to find the best execution plan for a statement.
Unfortunately, since it needs to do this live, in production conditions, it can’t take
more than an extremely short period to devise its solution. Thus, the optimizer resorts
to heuristics and other similar techniques to come up with its best estimate of a good
plan. This is the normal mode of the optimizer, where it quickly generates optimal
execution plans for SQL statements.
What if you give the optimizer enough time to conduct a full-blown analysis of
access paths, object characteristics, and so on?
In Oracle Database 10g, you can invoke the optimizer in the new tuning mode,
wherein the optimizer conducts an in-depth analysis to improve its execution plans.
Instead of mere seconds, in tuning mode, the optimizer may take several minutes to
come up with a set of recommendations, rather than an optimal SQL execution plan.
These recommendations are intended to help you optimize the execution plan, along
with the rationale for them and the expected benefit if you follow the recommendations.
Since it sometimes takes several minutes for the optimizer to work through its
analysis in the tuning mode, use it for fixing only your highly resource-intensive
SQL statements.
When you use the Oracle optimizer in the tuning mode, it’s referred to as the
Automatic Tuning Optimizer (ATO). In this mode, you aren’t really using the
optimizer to develop quick execution plans. Your goal is to see if the ATO can
improve on the usual optimizer execution plans. The ATO lies at the heart of the
SQL Tuning Advisor’s capability to tune SQL statements for you. Through the advisor,
you can now use the Oracle optimizer in the tuning mode (the ATO) to improve
SQL performance.
The ATO performs the following four tuning tasks:
■ Statistics analysis
■ SQL profiling
■ Access path analysis
■ SQL structure analysis
These tasks are described in the following

sections, along with the types of recommendations
The ATO performs four that the SQL Tuning Advisor makes.
types of analysis: statistics analysis, SQL
profiling, access path analysis, and Statistics Analysis
SQL structure analysis. As its first task, the ATO ensures that statistics
exist for all the objects in the SQL statement and
that those statistics are representative—that is, not stale. Accurate and up-to-date
statistics are essential for generating efficient execution plans. When it finds any tables
with missing or stale statistics, the ATO recommends collecting new statistics for
them. The ATO will also collect auxiliary information to fill in the missing statistics.
If an object’s statistics are stale, it corrects them, using adjustment factors.
SQL Profiling
The ATO collects auxiliary information to improve the execution plans. The ATO’s
goal at this stage is to verify that its own estimates of factors like column selectivity
and cardinality of database objects are valid. It may use the following three verification
or validation methods to test to verify its initial estimates:
■ Dynamic data sampling Using a sample of the data, the ATO can check its
own estimates of various factors like cost and cardinality for the statement in
question. The ATO may decide to apply correction factors to the data, if the
sampling process reveals that its estimates are significantly off the mark.
■ Partial execution The ATO may partially execute a SQL statement, so it
can check if its original estimates are good enough. It compares the run-time
performance with the expected performance (based on the execution plan).
This feature is a bold attempt to go beyond normal collection of object statistics.

Object statistics aren’t always enough; an optimizer may need more information
to get the right plan. So the ATO partially runs statements to gather statement-
execution statistics to use in addition to the object statistics. Therefore, what
it is checking is not whether the estimates of column selectivity and other
factors are correct, but whether a plan derived purely from inspection of those
statistics is actually the best plan.
■ Past execution history statistics The ATO may also use any existing
history of the SQL statement’s execution to determine appropriate
settings for parameters like OPTIMIZER_MODE.
If there is sufficient auxiliary information

from either the statistics analysis or the SQL
profiling phase, the ATO builds a SQL profile.
The ATO may use dynamic Although we say that the ATO will “build a
sampling, partial statement execution, or SQL profile,” in reality, it simply recommends
historical SQL execution statistics to validate that you create a SQL profile. A SQL profile
its initial estimates of cost, selectivity, and is simply a set of auxiliary or supplementary
cardinality for a SQL statement. information about a SQL statement.
Once you accept the recommendation of the
SQL Tuning Advisor to create a SQL profile in the tuning mode, Oracle will store
that SQL profile in the data dictionary. The Oracle optimizer, even while running in
its normal mode, will use it, along with the statistics that you’ve already collected, to
produce better execution plans. Whenever you use the same SQL statement in the
future, Oracle will automatically apply the SQL profile that you’ve created for it.
As long as you have minor changes in table
and index data and normal growth of objects,
the SQL profile continues to be relevant. Over
A SQL profile isn’t the time, you may want to refresh or replace the
same as a stored execution plan. SQL profile for a statement by running the
ATO again.
One of the biggest advantages of SQL profiles is that they provide you an
effective way to tune “code that you can’t touch.” Packaged applications are
usually hard to tune for DBAs, since there are limitations on accessing and
modifying code. Since the SQL profiles are saved in the data dictionary, you
can use them to tune even packaged applications.
Access Path Analysis

The ATO analyzes the potential impact of using improved access methods, such as
additional or different indexes. As you know, addition of a critical index can speed up
a query substantially. But what if the new index you create affects other SQL statements
adversely? The SQL Advisor is aware of this possibility, and thus makes its index-related
recommendations in the following way:
■ If an index is very effective, it may recommend creating it immediately.

■ It may recommend running the SQL Access Advisor (described later in
this chapter) to make a comprehensive impact analysis of the addition
of the new index.
SQL Structure Analysis

The ATO may also make recommendations
to modify the structure, both the syntax and
The ATO will identify badly semantics, in your SQL statements. Oracle will
constructed SQL statements, but it doesn’t look at typical problems like the following:
automatically rewrite the queries for you. In
the final analysis, you know your application ■ Design mistakes, such as a Cartesian product
better than the optimizer, and therefore ■ Use of inefficient SQL constructs; for example,
Oracle only provides advice. the NOT IN construct is known to be very slow
compared to the NOT EXISTS construct
SQL Tuning Advisor Recommendations

The SQL Tuning Advisor can recommend that you do the following:
■ Create indexes to speed up access paths

■ Accept a SQL profile, so you can generate a better execution plan
■ Gather optimizer statistics for objects with no or stale statistics
■ Rewrite queries based on the advisor’s advice

You can use the SQL Tuning Advisor with the help of Oracle database packages or with
the OEM Database Control interface. The following sections describe both techniques.
Using the DBMS_SQLTUNE Package

The DBMS_SQLTUNE package is the main Oracle Database 10g interface to tune SQL
statements. Let’s first look at how you can use the package to create and manage
SQL statement tuning tasks.
To use the DBMS_SQLTUNE package, you must have the ADVISOR privilege.
Performing Automatic SQL Tuning Following are the main steps in using
the DBMS_SQLTUNE package to tune SQL statements.
1. Create a task. You can use the CREATE_TUNING_TASK procedure to

create a task to tune either a single statement or several statements.
2. Execute the task. You start the tuning process by running the EXECUTE_
TUNING_TASK procedure.
3. Get the tuning report. By using the REPORT_TUNING_TASK procedure,
you can view the results of the SQL tuning process.
EXERCISE 5-1
Use the DBMS_SQLTUNE Package

Use the DBMS_SQLTUNE package to create a simple tuning task and view the tuning
report. Your exercise can use the following structure:
SQL> declare
2 tname varchar2(30);
3 begin
4 tname:=
5 dbms_sqltune.create_tuning_task(
6 sql_text=>'select count(*) from hr.employees,hr.dept');
7 end;
8 /
Check to make sure that your task was created by using the following query:
SQL> select task_name from user_advisor_log;
Get a task report by using the following statement:
SQL> select dbms_sqltune.report_tuning_task('TASK_NAME') from dual;
Managing SQL Profiles Use the DBMS_SQLTUNE.ACCEPT_SQL_PROFILE

procedure to create a SQL profile based on the recommendations of the ATO.
You must have the CREATE_ANY_PROFILE privilege in order to create the

SQL profile.
Managing SQL Tuning Categories Suppose you have several profiles, all
somewhat different, for a SQL statement. How does Oracle know which profile to
use in a given case? All SQL profiles that you create for various SQL statements belong
to specific SQL tuning categories. When a user logs in to the database, Oracle assigns
each user to a specific tuning category, based on the value of the initialization parameter
SQLTUNE_CATEGORY. Thus, the category name qualifies the lookup of SQL profiles
by Oracle during the execution of a SQL statement.
The default value of the SQLTUNE_CATEGORY parameter is DEFAULT. Thus,
any SQL profiles that belong to the default category will apply to all users who log in
to the database. After the user logs in, you can change the SQL tuning category for
all the users by using an ALTER SYSTEM command, or you can change a session’s
tuning category by using an ALTER SESSION command. For example, suppose that
you have already created the categories PROD and DEV. You can change the SQL
tuning category for all users with the following command:
SQL> alter system set SQLTUNE_CATEGORY = PROD;
To change a session’s tuning category, use the following command:

SQL> alter session set SQLTUNE_CATEGORY = DEV;
Oracle will now apply all profiles under the category DEV, until you log out from that
session. When you log in again, the default tuning category will again determine the
profiles available to your session.
The ATO will build a create a SQL profile. Once you create a
SQL profile only if it generates auxiliary new SQL profile, Oracle automatically
information during the statistics analysis applies that profile to the SQL statement
and SQL profiling steps. If it builds a SQL when you next execute it.
profile, it will recommend that you actually
Using the SQL Access Advisor 253
A session can change its SQL tuning category by using the ALTER SESSION
statement shown in this section. You may also use the DBMS_SQLTUNE.ALTER_
SQL_PROFILE procedure to change the SQL tuning category.
Using the Database Control to Run the SQL Tuning Advisor

To manage the SQL Tuning Advisor from the Database Control, click the Advisor
Central link under the Related Links group, and then click the SQL Tuning Advisor
link. You will see the main SQL Tuning Advisor page, where you can select the source
for the SQL statements that you want the SQL Advisor to analyze. You have a choice
of two main kinds of SQL statements:
■ Top SQL These SQL statements could

be current top SQL statements from the
cursor cache or saved high-load SQL
There are several possible
statements from the AWR.
sources for the tuning advisor’s STS input,
including high-load SQL statements ■ SQL Tuning sets You can create an
identified by the ADDM, statements in the STS from a set of SQL statements that
cursor cache, statements from the AWR, you provide. They could be brand-new
a custom workload, or another STS. statements, or you could get them from
AWR snapshots or baselines.
Once you click any of the four links, you’ll be taken to the data source you selected.
From there, you can launch the SQL Tuning Advisor. Follow the instructions to view
the advisor report and analyze the recommendations.
Using the SQL Access Advisor

The SQL Access Advisor is another useful component of the Advisory Framework. The
SQL Access Advisor primarily provides advice regarding the creation of indexes,
materialized views, and materialized view logs, in order to improve query performance.
The advisor recommends both bitmap indexes and B-Tree indexes. It also recommends
the optimization of materialized views so you can “fast refresh” them and thus take
advantage of general query rewriting.
Providing Input for the SQL Access Advisor

As in the case of the SQL Tuning Advisor, you can provide the input for the SQL
Access Advisor’s analysis from the SQL cache, the AWR, or new SQL statements
you’ve created for testing purposes. No matter the source of the SQL workload, the
SQL Access Advisor can recommend indexes and materialized views that can improve
the performance of the entire workload. Often, a well-written SQL statement may
perform poorly due to the lack of the right index or a materialized view. The advisor
will suggest appropriate indexes and view and provides you the rationale for those
recommendations. The advisor can take into account multiple combinations of
actions to arrive at the best tuning strategy.
Here are the four main sources of a SQL Access Advisor’s workload:
■ Current and recent SQL activity, which includes statements from the SQL
cache (from the V$SQL view)
■ An STS stored in the AWR
■ A user-defined workload, which enables you to test a workload before an
application goes into production
■ An hypothetical workload you’ve created from specific schemas and tables
The three types of database materialized view logs. There are four
objects that the SQL Access Advisor may main sources of input for the advisor: SQL
recommend that you create, drop, or retain cache, user-defined workload, hypothetical
are indexes, materialized views, and workload, and STS from the AWR.
How the SQL Access Advisor Works

The goal of the SQL Access Advisor is to reduce the processing time of SQL statements,
by creating additional structures like indexes and/or materialized views. You can choose
to have the advisor recommend just indexes, just materialized views, or both.
The SQL Access Advisor takes into account user-defined constraints by supporting
the following:
■ Storage constraints
■ Refresh time constraints
■ Full or partial workloads
Using the SQL Access Advisor 255
Modes of Operation
You can operate the SQL Access Advisor in two modes:
■ Limited (partial) In the limited mode, which is more or less a reactive

mode of tuning, the advisor will concern itself with only problematic or high-
cost SQL statements. In these situations, the advisor makes recommendations
that affect only the current statement or statements. Limited mode returns
quickly after processing the statements with the highest cost, potentially
ignoring statements with a cost below a certain threshold.
■ Comprehensive (full) Comprehensive analysis is more like a proactive type
of analysis. It will perform a complete and exhaustive analysis of all SQL
statements in a representative set of SQL statements, after considering the
impact on the entire workload, not just a few SQL statements. For example,
a particular index may help a certain query, but may be quite detrimental
for the entire workload’s point of view. Thus, a comprehensive analysis
enables the advisor to provide better global tuning advice, but, of course,
it takes a lot of time to complete.
You can also use workload filters to specify which kinds of SQL statements the
SQL Access Advisor should select for analysis, from the workload it has in front of
it. For example, you may use filter options like top resource using SQL statements,
specific users or tables, and so on. The workload filters enable the reduction of the
scope of the SQL statements in the workload. The advisor applies these filters to
focus its tuning efforts, say, limiting its analysis to only those statements that touch
a certain set of tables.
SQL Access Advisor Recommendations

Following are some of the specific types of recommendations made by the SQL Access
Advisor:
■ Add new indexes or materialized views.

■ Add a new materialized view log.
■ Modify indexes or materialized views by adding columns.
■ Change an index type.
■ Drop an unused index or materialized view.
Managing the SQL Access Advisor

You can manage the SQL Access Advisor either through the OEM Database Control
or by using the DBMS_ADVISOR package. Both techniques are described in the
following sections.
Using the DBMS_ADVISOR Package

Following is a brief summary of the steps involved in using the DBMS_ADVISOR package:
1. Create and manage a task, by using a SQL workload object and a SQL
Access task.
2. Specify task parameters, including workload and access parameters.
3. Using the workload object, gather the workload.
4. Using the SQL workload object and the SQL Access task, analyze the data.
You can also use the QUICK_TUNE procedure of the DBMS_ADVISOR package
to quickly analyze a single SQL statement, without needing to go through all these
steps. You can create tasks, prepare workloads for the SQL statement, execute the
task, save the results, and finally implement the recommendations as well. Here’s a
quick example of using the QUICK_TUNE procedure:
VARIABLE task_name VARCHAR2(255);
VARIABLE sql_stmt VARCHAR2(4000);
EXECUTE :sql_stmt := 'SELECT COUNT(*) FROM customers
WHERE cust_region=''TX''';
EXECUTE :task_name := 'MY_QUICKTUNE_TASK';
EXECUTE DBMS_ADVISOR.QUICK_TUNE(DBMS_ADVISOR.SQLACCESS_ADVISOR, -
:task_name, :sql_stmt);
Using the Database Control

to Run the SQL Access Advisor
To manage the SQL Access Advisor from the
Oracle creates the new Database Control, click the Advisor Central link
indexes in the schema and tablespaces under the Related Links group, and then click
of the table on which they are created. the SQL Access Advisor link. You will see the
If a user issues a query that leads to a main SQL Access Advisor page.
recommendation to create a materialized First, choose the access method—materialized
view, Oracle creates the materialized view view or an index—that you would like the
in that user’s schema and tablespace. advisor to evaluate. You can use the Advanced
Options section to specify the following options:
Using the Performance Pages of the Database Control 257
■ Space Restrictions These options include setting space size limits that the
advisor’s recommendations can’t exceed. You may also limit the number of
indexes that the advisor can create.
■ Tuning Options These options prioritize the advisor’s access recommendations
by items like buffer gets, CPU time, disk reads, and elapsed time.
■ Default Storage Locations These options enable you to override the default
locations defined for the schema and the tablespaces.
Using the Performance Pages

of the Database Control
As you’ve seen in prior chapters, the ADDM and the server-generated alerts provide
you with proactive database management support. The OEM Database Control is an
essential part of the push by Oracle to automate most of the DBA’s job functions in
Oracle Database 10g. Using the Database Control, you can analyze these important
components of both the database as well as system performance.
In the following sections, we’ll look at two Database Control pages that highlight
the OEM performance management features: the Database Home page and the
Performance page.
The Database Home Page

The Oracle Database Home page allows you to view the current state of the database
by displaying various metrics that portray the overall health of the database. The Oracle
Database Home page, shown in Figure 5-1, provides a launching point for performance
tuning, as well as other management activities.
Here are some of the statistics the Database
Home page shows you (in addition to the ADDM
The three major tuning findings):
areas that the OEM Database Control will
show you are CPU and wait classes, top ■ CPU usage
SQL statements, and top sessions in the ■ Database waits
instance.
■ Top SQL statements
■ Top user sessions

■ SQL response time
The Database Performance Page

The Database Performance page shows you the overall status of the database and helps
you quickly identify causes of performance bottlenecks. Figure 5-2 shows the three main
items on the Performance page:
■ Host
■ Sessions waiting and working
■ Instance throughput
Host Performance Data

The Host part of the page shows two important graphs dealing with resource use on
the host:
■ Average Run Queue This shows how hard the CPU is running. A high run
queue indicates that there is contention for CPU time. The run queue tells
you how many processes are ready to run but are unable to do so, due to a
CPU bottleneck.
■ Paging Rate This shows the rate at which the host server is writing memory
pages to the swap area on disk. Paging slows down your system because of the
extra I/O, and it indicates that your system is memory-bound.
Sessions Performance Data

The sessions graph shows which active sessions are on the CPU and which are waiting
for resources like locks, disk I/O, and so on. By clicking specific boxes, you can drill down
to any wait that seems serious.
Oracle recommends that you start investigating waits if the level of waits is at
twice the Maximum CPU line in the sessions graph.
Instance Throughput Performance Data

If your instance throughput is decreasing, along with an increasing amount of contention
within the database, you should start looking into tuning your database.
Using the Performance Pages of the Database Control 259
FIGURE 5-1 The Database Control Database Home page
FIGURE 5-2 The Database Control Database Performance page
Indexing Enhancements
There are several index-related enhancements in Oracle Database 10g. Primary among
them are the following:
■ Skipping unusable indexes

■ Creating and maintaining hash-partitioned global indexes
■ Using the new UPDATE INDEXES clause
Let’s start our discussion in this section with a look at enhancements in the skipping
of unusable indexes.
Skipping Unusable Indexes

In previous versions of Oracle, modification of any partitions of a table using the SPLIT
or MERGE command, for example, left the indexes in an unusable state. In Oracle9i,
the SKIP_UNUSABLE_INDEXES=TRUE parameter enabled you to avoid the indexes
that were rendered unusable. In Oracle Database 10g, the default value of this parameter
is TRUE. Thus, you can guarantee that the optimizer will always ignore the unusable
indexes at parse time.
When you use the SKIP_UNUSABLE_
INDEXES=TRUE specification, the database
may skip an index that it would have used
In Oracle Database 10g, otherwise, thus leading to suboptimal execution
the default value of SKIP_UNUSABLE_ plans. That’s why the database records this
INDEXES parameter is TRUE. information regarding the presence of unusable
indexes in the alert log.
The SKIP_UNUSABLE_INDEXES parameter could be quite dangerous in

practice. The Oracle Database 10g default means that your SQL will always
run, but it may be running very badly because of broken indexes. With previous
releases, you would always know about the problem immediately.
Indexing Enhancements 261
Using Hash-Partitioned Global Indexes

Until Oracle Database 10g, you could create only range-partitioned global indexes on
tables. Now you can create hash-partitioned global indexes as well. As with the global
range partitioning, you can use a maximum of 32 columns in the global index. Oracle’s
hash functions determine the values in each partition now, instead of a range of values
in a range-partitioned global index. Oracle Database 10g assigns rows to the partitions
using a hash function on values in the partitioning key columns.
Benefits of Hash-Partitioned Global Indexes

You can hash-partition indexes on tables, partitioned tables, and index-organized tables.
This feature provides higher throughput for applications with large numbers of concurrent
insertions. In some applications, new insertions into indexes are biased heavily toward
the right side of the index. This is usually the case when you have an index on a column
that is a monotonically increasing sequence number. You can’t avoid heavy contention
for the index resources in such a situation, in addition to causing potential node splitting.
Since the partitioning key (and the number of partitions in the index) is the primary
determinant of in which partition the index entries are placed, it isn’t likely that a
monotonically increasing sequence number would cause contention on one side of the
index. Hash-partitioned global indexes thus improve concurrency and raise throughput
in OLTP systems.
For monotonically increasing key situations, range partitioning will cause contention
on the right edge of the highest range partition. Reverse keying the index will spread
the activity, but only across the highest partition. Hash partitioning will distribute the
workload across all the index partitions, but still with contention at each index’s
right edge; reverse-key hash partitioning will not only distribute the activity across
all the partitions, but also spread it within each partition. Oracle also has more options
available to it for parallel query and DML operations.
As with the hash-partitioned table, you can specify only the tablespace for the
hash-partitioned indexes as part of the storage attribute.
One of the advantages of range-partitioned indexes is that you can perform partition
pruning, which makes it easy to skip irrelevent partitions. However, hash-partitioned
global indexes overcome this disadvantage by being able to access all partitions in
the index in parallel. If you have queries with range predicates, for example, hash-
partitioned indexes perform better than range-partitioned indexes.
Hash-Partition Management
When you create a hash-partitioned index, you can specify each partition its own
tablespace, or you can specify the total number of partitions and use the STORE IN
clause to allocate the hash partitions among the available number of tablespaces. If you
skip the STORE IN clause, Oracle will place the hash partition in the user’s default
tablespace. All partitions in a hash-partitioned global index share identical physical
and storage attributes.
You use the following statement for creating a hash partitioned global index, if
you wish to specify each hash partition individually:
SQL> create index sales_hash
on sales_items (sales_id) global
partition by hash (sales_id) (
partition p1 tablespace tbs_1,
partition p2 tablespace tbs_2,
partition p3 tablespace tbs_3
partition p4 tablespace tbs_4);
You can also create a hash partitioned global index by specifying the number of hash
partitions (4 in our example) with the optional STORE IN clause, as shown here:
SQL> create index sales_hash
on sales_items (sales_id) global
partition by hash (sales_id)
partitions 4
store in (tbs_1,tbs_2,tbs_3,tbs_4);
You can’t perform the following operations on hash-partitioned global indexes:

ALTER INDEX REBUILD, ALTER TABLE SPLIT INDEX PARTITION, ALTER
TABLE MERGE INDEX PARTITITON, and ALTER INDEX MODIFY PARTITION.
Using the New UPDATE INDEXES Clause

In previous versions of Oracle, when your performed DDL actions, such as adding, moving,
or merging table partitions, you couldn’t explicitly specify the storage characteristics for
the associated local index. Oracle created the local indexes either in the default tablespace
or in the same tablespaces as the underlying table
partitions. The DDL on the table partitions also
left the local indexes in an unusable state, forcing
Using the new UPDATE you to rebuild them.
INDEXES clause during a partitioned In Oracle Database 10g, you can now specify
table DDL command will help you do two storage attributes, as well as keep you local
things: specify storage attributes for the indexes from being rendered unusable, with the
corresponding local index segments and help of a single new clause. By using the UPDATE
have Oracle automatically rebuild them. INDEXES clause during a partitioned table DDL
statement, you can avoid making your local
Wednesday, September 15, 2004 1:09:29 PM
Indexing Enhancements 263
indexes unusable by making Oracle automatically rebuild them, thus increasing the
availability of your database. Here’s an example of the usage of the UPDATE
INDEXES clause during partitioned table DDL:
SQL> alter table MY_PARTS
2 MOVE PARTITION my_part1 tablespace new_tbsp
3 UPDATE INDEXES
4 (my_parts_idx
5 (PARTITION my_part1 TABLESPACE my_tbsp);
Note that if you don’t specify the index name in the preceding statement, Oracle
will rebuild the indexes to put them back into a usable state.
The MOVE operation is actually implemented as two separate DDL statements:

first, Oracle moves the table, and then it rebuilds the index. So even though it
is slow, you do end up with an efficient index.
INSIDE THE EXAM
You must be aware of the role of the GATHER_ On the exam, don’t be surprised to see a
STATS_JOB Scheduler job as well as the couple of questions about using the OEM
proper settings of the STATISTICS_LEVEL Database Control to manage database
parameter for optimizer statistics collection. performance. You must know the basic
The certification exam tests you knowledge of approach of the Database Control regarding
the SQL Access Advisor and the SQL Tuning performance management (CPU and waits,
Advisor rather thoroughly. You must know top SQL, and top sessions). You must practice
the particular types of Oracle objects about using the Database Control to locate statistics
which the SQL Access Advisor will make about CPU and waits, SQL, and sessions.
recommendations. You must remember all the What’s on the Database Control Database
possible sources of data for both of these advisors. Home page? What are the three sections of the
The exam focuses on the Automatic Tuning Database Performance page? How do you drill
Optimizer (ATO). What is the difference down to various contention areas? Where and
between the regular Oracle optimizer and the what are the Top Waiting SQL and the Top
ATO? You must understand each type of analysis Waiting Sessions charts? How do you drill down
the ATO performs as part of the SQL tuning to the Top SQL by Waits chart?
process. Review all four types of analyses Expect a question testing your knowledge of
carefully, paying attention to the various kinds the SKIP_UNUSABLE_INDEXES and/or the
of verification methods in the SQL profiling UPDATE INDEXES clause, both concerning
phase of the analysis. Know how to create a SQL Oracle Database 10g enhancements to the
profile, as well as how Oracle uses it. When does partitioning option. Review the benefits of
the ATO recommend a SQL profile? hash-partitioned global indexes.
This chapter started with an overview of the enhancements and changes in the
optimizer statistics collection in Oracle Database 10g. You learned about the automatic
statistics collection process. The SQL Tuning Advisor takes away the drudgery involved
in tuning complex SQL code, and you learned how to manage this advisor using
PL/SQL packages as well as the Database Control.
You learned about the SQL Access Advisor and how you can get advice about
proper indexes and materialized views in your database.
You saw how you could use the Database Control’s Performance page to drill
down into any performance issue of interest. You learned about the innovations in
the skip unusable indexes feature. You saw how you could specify storage characteristics
for index partitions in the course of DDL statements. You were introduced to the
new hash-partitioned global indexes, which can reduce index contention in some
special circumstances.
Two-Minute Drill 265
❑ Rule-based optimization is now obsolete.
❑ The CHOOSE and RULE values for the OPTIMIZER_MODE parameter are
not supported in Oracle Database 10g, although you can still continue to
use them.
❑ The default value for the OPTIMIZER_MODE parameter is ALL_ROWS.
❑ Oracle prioritizes its automatic statistics collection, with preference given
to objects with stale or no statistics.
❑ The default cost model for the optimizer is CPU+I/0.
❑ The default value for the GRANULARITY argument is AUTO.
❑ If you specify GLOBAL and PARTITION options, Oracle doesn’t collect
subpartition-level statistics.
❑ The DEFAULT setting for the DEGREE argument means that you’ll use a
system-based degree of parallelism.
❑ Use the OPTIMIZER_DYNAMIC_SAMPLING parameter to use automatic
dynamic sampling.
❑ Table monitoring is automatic in Oracle Database 10g.
❑ Oracle recommends that you collect optimizer statistics for data dictionary
tables, both fixed and real.

❑ You can use the AWR data or the ADDM recommendations, or create your
own SQL statements to input to the SQL Tuning Advisor.
❑ A SQL Tuning Set (STS) is a set of SQL statements that you would like to
tune together.
❑ There are two modes for the optimizer now: normal mode and tuning mode.
❑ Use the optimizer in the tuning mode only for highly resource-intensive
statements.
❑ The fours steps of a SQL Tuning Advisor job are statistics analysis, SQL
profiling, access path analysis, and SQL structure analysis.
❑ You can manage the SQL Tuning Advisor by using the DBMS_SQLTUNE
package.
❑ You can create a new profile by using the ACCEPT_SQL_PROFILE procedure.
❑ All SQL profiles belong to a specific SQL tuning category.
❑ The default value of the SQLTUNE_CATEGORY parameter is DEFAULT.

❑ The SQL Access Advisor provides advice on creating indexes, materialized
views, and materialized view logs.
❑ The SQL Access Advisor may also recommend the dropping of unused indexes.
❑ You can use the SQL Access Advisor in a limited or comprehensive mode.
❑ You can manage the SQL Access Advisor through the DBMS_ADVISOR
package.
❑ You can use the QUICK_TUNE procedure of the DBMS_ADVISOR package
to analyze a single SQL statement.
Using the Database Control for Performance Tuning

❑ Using the Database Control, you can monitor CPU, waits, top SQL, and top
sessions.
❑ The three main sections on the Database Performance page are Host, Sessions
Waiting and Working, and Instance Throughput.
❑ The Host section shows the average run queue and the paging rate.
❑ The session graphs show which sessions are on CPU and which sessions are
waiting for resources.
❑ Oracle recommends investigating waits if the level of waits is at twice the
Maximum CPU line in the sessions graph.
Two-Minute Drill 267
❑ The default value of SKIP_UNUSABLE_INDEXES is TRUE.
❑ You can now use hash-partitioned global indexes.
❑ Oracle assigns rows to various partitions using a hash function on the
partitioning key column.
❑ Hash-partitioned global indexes increase concurrency, especially if the index
is on monotonically increasing sequence numbers.
❑ You can’t perform certain index maintenance operations on hash-partitioned
global indexes.
❑ You can use the UPDATE_INDEXES clause to set storage attributes as well as
to keep local indexes from being made unusable during a DDL operation.
SELF TEST
this chapter. Read all the choices carefully, because there might be more than one correct answer.

1. What is the default value for the OPTIMIZER_MODE initialization parameter?
A. FIRST_ROWS
B. ALL_ROWS
C. CHOOSE
D. COST
2. If you are using LIST subpartitioning and you specify the value of the GRANULARITY
argument as AUTO, what statistics will Oracle collect?
A. Global statistics only
B. Global and partition statistics only
C. Global, partition, and subpartition statistics
D. No partitioned table statistics
3. How can you collect statistics for fixed data dictionary tables?
A. By using the DBMS_STATS.GATHER_DICTIONARY_STATS procedure
B. By using the DBMS_STATS.GATHER_FIXED_OBJECTS_STATS procedure
C. By using GATHER_SCHEMA_STATS with the SYS option
D. By using the statement EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_
STATS('USER');

4. What can you create a SQL Tuning Set (STS) from?
A. Several SQLs statements from the AWR
B. One or more other STSs
C. A single SQL statement
D. Only the most high-load SQL statements in your database
Self Test 269
5. Which of the following is true about the SQL Tuning Advisor?

A. It automatically collects statistics if they are missing.
B. It only makes recommendations to collect statistics.
C. It ignores optimizer statistics completely.
D. It uses only the available statistics and nothing else.
6. If you create a SQL profile, when can you use it?
A. In the tuning mode of the optimizer only
B. In the normal mode of the optimizer
C. In neither the tuning nor the normal mode of the optimizer
D. Along with existing statistics, to get better SQL execution plans
7. How do you create a new SQL profile?
A. With the ACCEPT_SQL_PROFILE procedure
B. With the CREATE_SQL_PROFILE procedure
C. With both the ACCEPT_SQL_PROFILE and CREATE_SQL_PROFILE procedures
D. A SQL profile is automatically created each time you execute a new SQL statement.

8. Which of the following is true about the SQL Access Advisor?
A. It will not recommend the creation of an index until it completes a full, comprehensive
analysis.
B. It can recommend the dropping of an index during a limited mode of operation.
C. It can recommend the dropping of an index during a comprehensive mode of operation.
D. It can change an index type under certain conditions.
9. How can you manage the SQL Access Advisor?
A. Through the DBMS_SQLTUNE package
B. Through the DBMS_ADVISOR package
C. Through the SQL_TUNE package
D. Through the DBA_ADVISOR package

10. Oracle recommends that you start investigating database waits when what occurs?
A. The level of waits is the same as the Maximum CPU line in the sessions graph.
B. The level of waits is smaller than the Maximum CPU.
C. The level of waits is at twice the Maximum CPU line.
D. The level of waits is slightly higher than the Maximum CPU line.
11. A high paging rate indicates that your system is what?
A. CPU-bound
B. Memory-bound
C. I/O-bound
D. SGA-bound
12. Which three major tuning areas does Database Control provide information about?
A. CPU and wait classes
B. Most-used objects
C. Top SQL statements
D. Memory usage
E. Top sessions affecting the instance
13. What does the Database Control Performance Page show?
A. Host information
B. Memory usage
C. CPU usage
D. User activity
E. Throughput information
14. When you have a monotonically increasing sequence number as an indexed column, which of
the following is true?
A. Hash-partitioned global indexes are useful.
B. Range-partitioned global indexes are better.
C. Hash-partitioned local indexes are better.
D. Range-partitioned local indexes are better.
Lab Question 271
15. What is the benefit of using the UPDATE INDEXES clause in an ALTER TABLE statement?
A. You can keep your indexes form being rendered unusable.
B. You can specify storage attributes.
C. You can update statistics on your indexes.
D. You can keep your index nodes from splitting excessively.
LAB QUESTION
Use the DBMS_SQLTUNE package to do the following:
■ Create a tuning task.
■ Execute the tuning task.
■ View the tuning results.
■ Create a SQL profile, if one is recommended by the SQL Tuning Advisor.
SELF TEST ANSWERS

1. þ B. The default optimizer mode in Oracle Database 10g is ALL_ROWS.
ý A, C, and D are not the correct default optimizer alternatives in Oracle Database 10g.
2. þ C. If you’re using the LIST partitioning method, Oracle will collect all statistics, down to
the lowest level of granularity—the subpartition.
ý A, B, and D point to the wrong alternatives.
3. þ B. The GATHER_FIXED_OBJECTS_STATS procedure lets you collect statistics for the
fixed data dictionary tables.
ý A is wrong because the GATHER_DICTIONARY_STATS procedure collects only the
nonfixed data dictionary tables. C is wrong as well, for the same reason as answer A. D seems
correct, but you must specify ALL, not USER, in order to gather statistics for all the fixed tables.

4. þ A and B. An STS is created from any set of SQL statements, including those you get
from the AWR. B is correct because you can create a STS from either a set of individual SQL
statements or from other STSs.
ý C is wrong because a single SQL statement isn’t enough to create an STS. D is wrong
because there is no requirement that only high-load SQL statements can be included in
an STS.
5. þ B. The SQL Tuning Advisor only makes recommendations to collect statistics. It might
perform sampling or collect auxiliary information to help derive a SQL profile, but it doesn’t
automatically start the statistics collection process.
ý A is wrong because the advisor only recommends that you collect statistics. C is wrong
because the advisor never ignores statistics. D is wrong as well, since the advisor does use
quite a bit of information in addition to pure optimizer statistics.
6. þ B and D. B is correct since you can use the SQL profiles only in the normal mode of
the optimizer. D is also correct since Oracle uses the SQL profiles along with the available
statistics.
ý A is wrong because you don’t use the SQL profile in the tuning mode only. C is wrong
because you can use the SQL profiles in the normal mode by the optimizer.
7. þ A. When the SQL Tuning Advisor recommends a SQL profile, you can create the profile
by using the ACCEPT_SQL_PROFILE procedure.
ý B is wrong because there is no such procedure. C is wrong because of the same reasons as B.
D is wrong since Oracle doesn’t automatically create a SQL Profile.

8. þ C and D. C is correct because the SQL Access Advisor can recommend dropping an index
only if you use it in the full (comprehensive) mode. D is correct because the advisor recommends
the changing of the index type under some conditions.
ý A is wrong because you don’t need a full analysis for the advisor to recommend indexes.
B is wrong because a limited mode of operation cannot recommend dropping of indexes and
materialized views.
9. þ B. You can manage the SQL Access Advisor by using the DBMS_ADVISOR package.
ý A, C, and D point to wrong or nonexistent packages.

10. þ C. Oracle recommends that you investigate database waits if the level of waits in the
Database Control graphs is at twice the Maximum CPU line.
ý A, B, and D specify the wrong information.
11. þ B. Paging is related to memory.
ý A, C, and D are wrong because they really don’t have a direct bearing on paging rates.
12. þ A, C, and E. The three major tuning areas that the Database Control focuses on as part of
its performance management approach are CPU and wait classes, top SQL statements, and top
sessions affecting instance.
ý B is wrong since the Database Control doesn’t track object usage. D is wrong since memory
usage isn’t a major tuning area in the Database Control performance management approach.
13. þ A, D, and E. The Database Control Performance Page contains three sections displaying
host information, user activity, and throughput information.
ý B and C are wrong since memory and CPU usage information aren’t shown on the
Performance Page.
14. þ A. When you have monotonically increasing indexed column, hash-partitioned global
indexes are ideal, because they spread the column values more or less uniformly among the
partitions.
ý B is wrong since range-partitioned global indexes are the worst choice for this type of
indexed columns. C and D refer to local indexes, which aren’t really better than the global
indexes in this case.
15. þ A and B. By using the UPDATE INDEXES clause, you can specify storage attributes as
well as keep your indexes from being rendered unusable.
ý C and D have nothing to do with the UPDATE INDEXES clause.
LAB ANSWER
First, create three bind variables, to hold your query string and the task name, as shown here:
SQL> variable test_query varchar2(1000)
SQL> variable test_task varchar2(1000)
SQL> variable test_profile varchar2(1000)
Now insert your query into the bind variable test_query.

SQL> begin
2 :test_query:='SELECT CHANNEL_ID FROM SH.SALES WHERE PROD_ID=146;';
3 end;
4 /
SQL> begin
:test_task := DBMS_SQLTUNE.create_tuning_task (
sql_text => :test_query,
bind_list => SQL_BINDS(anydata.ConvertNumber(100)),
user_name => 'SAM',
scope => 'COMPREHENSIVE',
time_limit => 60,
task_name => 'test_tuning_task',
description => 'Query on SALES table');
end;
/
Execute the task using the EXECUTE_TUNING_TASK procedure, as follows:

SQL> begin
dbms_sqltune.execute_tuning_task (TASK_NAME=>:test_task);
end;
View the tuning report, using the REPORT_TUNING_TASK function, as follows:
SQL> select dbms_sqltune.report_tuning_task
task_name=>:test_task)
from dual;
Create the SQL profile, if one is recommended by the SQL Tuning Advisor, by using the ACCEPT_
SQL_PROFILE function, as shown here:
SQL> begin
:test_profile := dbms_sqltune.accept_sql_profile
(task_name => 'test_tuning_task');
end;
/
Blind Folio 6:1
6
Space and Storage
Management
Enhancements
6.01 Proactive Tablespace Management 6.05 Using Sorted Hash Clusters

6.02 Reclaiming Unused Space 6.06 Copying Files Using the Database Server
6.03 Using the Undo and Redo Logfile Size ✓ Two-Minute Drill
Advisors
Q&A Self Test
6.04 Tablespace Enhancements
Friday, September 03, 2004 10:44:53 AM
2 Chapter 6: Space and Storage Management Enhancements
I n Chapter 4, you learned about the new automatic database alerts. In this chapter, you’ll
see how you can reduce space-related errors by proactively managing tablespace usage.
Undo space management is tricky sometimes, especially when you run long transactions.
You can use tablespace usage alerts to manage normal tablespaces as well as the undo tablespace.
A major problem for many Oracle DBAs is how to reclaim unused space in the
database. You need to run SQL scripts to find out the amount of free space, and
possibly move or re-create database objects to recover the excess space. Due to the
time these database-reorganizing efforts consume, quite often, the free space is never
reclaimed. In Oracle Database 10g, you can shrink segments in line and in place.
Thus, you can reclaim unused space without affecting database availability.
In this chapter, you’ll learn about the new Segment Advisor, which helps you
isolate candidates for shrinking and to track segment growth over time, so you
can plan your space requirements correctly. You’ll next learn how to use the Undo
Advisor and the Redo Logfile Size Advisor. This chapter also introduces you to the
new data structure called the sorted hash cluster, which helps you store data sorted
by nonprimary key columns.
You read about the new SYSAUX tablespace in Chapter 1. In this chapter, you’ll
get the details of creating and managing the SYSAUX tablespace. You’ll learn about
temporary tablespaces and assigning temporary tablespace groups to users. You’ll also
look at topics like renaming tablespaces and creating a default temporary tablespace.
Large databases need large datafiles. The new bigfile tablespaces address this need by
enabling the creation of large tablespaces with just a single data file. This chapter
concludes by showing you how to copy files using the database server.
Let’s start with a quick look at the new concept of proactive tablespace management
in Oracle Database 10g.
Proactive Tablespace Management

In Oracle Database 10g, by default, all tablespaces have built-in alerts that notify you
when the free space in the tablespace goes below a certain predetermined threshold
level. There are two default alert thresholds: critical and warning. The new background
process, MMON, is responsible for monitoring tablespace free space and sending out
alerts. Oracle issues an alert each time the database crosses either one (warning or
critical) of the alert thresholds. When you clear the proactive alert by assigning
Proactive Tablespace Management 3
more space to the tablespace, Oracle issues

another alert to acknowledge the fixing of the
problem.
If you are migrating to By default, Oracle sends out a warning alert
Oracle Database 10g, Oracle turns off the when your tablespace is 85 percent full and a
automatic tablespace alerting mechanism critical alert when the tablespace is 97 percent
by default. You can use the DBMS_SERVER_ full. You may change these default settings, or
ALERT package to set the alert thresholds. even turn the entire alerting mechanism off,
if you so desire. The DBA_THRESHOLDS view
will provide information about the thresholds in your database.
The proactive tablespace alerts come with some caveats:
■ You can’t set alerts for dictionary-managed tablespaces. You can set alerts
only for locally managed tablespaces.
■ When you take a tablespace offline or make it read-only, you must turn
the alerting mechanism off (using the DBMS_SERVER_ALERT package).
You can turn the alerts back on after you change the status of the
tablespaces again.
■ For the undo tablespace, the active and unexpired extents together
constitute the used space in that tablespace. The same default warning
and critical thresholds (97 percent and 85 percent, respectively) apply
to the undo tablespace as well.
You can manage the tablespace usage alerts by setting or modifying the alert
thresholds. You can do this with the OEM Database Control or by using the PL/SQL
package DBMS_SERVER_ALERT. Let’s first learn how to manage the tablespace
space usage alert using Database Control.

to Manage Thresholds
You can use the OEM Database Control to
If you get a snapshot
set database-wide default thresholds. Here is
too old alert warning, you may need to
a summary of the steps you need to follow to
increase the size of your undo tablespace.
use the Database Control for this purpose:
In addition, you may consider increasing
the length of the undo retention period. 1. From the Database Control home page,
Note that you’ll get a maximum of only click the Manage Metrics link.
one undo alert during any 24-hour period.
2. In the Manage Metrics page, click the Edit
Thresholds button
3. From the Edit Thresholds page, you can set thresholds for the Tablespace
Usage metric. Click the Specify Multiple Thresholds button. This will bring
you to the Specify Multiple Thresholds: Tablespace Used page. You can set
thresholds for a specific tablespace from here.
Using the DBMS_SERVER_ALERT Package

You can also use the DBMS_SERVER_ALERT package to manage database thresholds.
In Chapter 4, you were introduced to two of the package’s procedures: SET_THRESHOLD
and GET_THRESHOLD. Using these procedures, you can perform the following tasks:
■ Set warning and critical thresholds

■ Set database-wide default values for tablespace space usage
■ Find out the levels of the current default tablespace usage thresholds
■ Turn off the space-usage tracking mechanism for any tablespace
Reclaiming Unused Space

A segment’s high-water mark (HWM) shows the highest point of space usage ever
reached by that segment. If you have used 80 percent of a table segment’s space by
inserting rows into that segment, for example, the HWM for that segment will be
at 80 percent. Later on, even if you delete half the rows, the table’s HWM remains at
80 percent. This has a detrimental effect on full-table scans and index scans, as Oracle
will scan the table all the way to the HWM, even if currently there is very little data
in the table due to deletions over time.
A table segment with large number of deletions will thus be sparsely populated,
with the deletions leading to fragmentation of the space, leaving several gaps below
its HWM level. Oracle will move the HWM lower only when you truncate all the
table rows. The only way for you to reclaim the space you allotted to a table is to
drop the table altogether or truncate it.
In segments using Automatic Segment Storage Management (ASSM), you

don’t really have an HWM. Instead, there is the high HWM, above which no
blocks are formatted, and the low HWM, below which all blocks are formatted.
Reclaiming Unused Space 5
The segment-shrinking shrinking operation. The operation is in

capability is termed an on line and in place place because you don’t need any duplicate
operation. It’s on line because users can or temporary database space during the
continue to access the tables during the segment-shrinking operations.
In previous versions of Oracle, the only way to compact the unused pockets of space
in table or index segments was to move the object or redefine it. These reorganizations
sometimes could be very time-consuming.
In Oracle Database 10g, you can now use the new segment-shrinking capability to
make sparsely populated segments give their space back to their parent tablespace.
You can reduce the HWM, thus compacting the data within the segments. In Oracle
Database 10g, you can shrink the following types of segments:
■ Tables, including index-organized tables (IOTs)

■ Partitions and subpartitions of a table
■ Indexes
■ Materialized views and materialized view logs
Oracle handles the shrinking operation internally as an insert/delete operation.

Note that any triggers on the tables will not fire when you perform the insertions
and deletions, since you are only moving the data around, not changing it. Each
batch of insertions/deletions constitutes one transaction. When you shrink a table
to compact space, the indexes on the table remain intact and are in a usable state
after the shrinking operation.
Restrictions on Shrinking Segments

The following are some restrictions that apply to shrinking segments:
■ You can’t shrink any segment that uses free lists. This means that you can
only shrink segments that use Automatic Segment Space Management.
■ You must enable row movement (for heap-organized segments). Enabling
row movement lets you specify whether Oracle can move a table row to
a different location. Oracle may need to move a row, for example, during
table compression or an update operation on partitioned data. During a
segment-shrinking operation, ROWIDs may

change, thus necessitating the enabling of
row movement.
The following objects can’t
be shrunk: clustered tables, tables with ■ Even with ASSM-based segments, you
LONG columns, tables with on-commit can’t shrink tables that are part of a cluster,
materialized views, tables with ROWID- tables with LONG columns, certain types
based materialized views, LOB segments, of materialized views, and certain types of
IOT mapping and overflow segments, and IOTs. You also can’t shrink tables with
tables with function-based indexes. function-based indexes.
Manual Segment Shrinking

You can use simple SQL commands to shrink segments. However, there is a
prerequisite to running the command. You must first enable row movement for any
segment that you want to shrink. You can enable row movement by using the ENABLE
ROW MOVEMENT clause of the ALTER TABLE
command, as shown here:
SQL> alter table test ENABLE ROW MOVEMENT;
You must enable row
movement before shrinking segments Of course, if you’ve already specified the
because the segment-shrinking operation ENABLE ROW MOVEMENT clause at table
may cause the ROWIDs in heap-organized creation time, you won’t need to issue any
segments to change. commands to enable row movement before
starting the segment-shrinking operation.
By default, row movement is disabled at the segment level.
The segment-shrinking operation compacts fragmented space in the segments and

optionally frees the space.
There are two phases in a segment-shrinking operation:
■ Compaction phase During the compaction phase, the rows in a table are
compacted and moved toward the left side of the segment. You thus make
the segment dense, but the HWM remains where it was. The recovered space
is not yet released to the tablespace. During this phase, you can issue DML
statements and queries on a segment while it is being shrunk. Oracle holds
locks on packets of the rows involved in the DML operations. If you have
any long-running queries, Oracle can read from all the blocks that have
technically been reclaimed during the shrinking operation. Of course, this
capability is dependent on the time interval you specified for your undo
retention parameter.
■ Adjustment of the HWM/releasing space phase During the second phase,
Oracle lowers the HWM and releases the recovered free space under the old
HWM to the parent tablespace. Oracle locks the object in an exclusive mode.
This implies that you can’t issue any INSERT, UPDATE, and DELETE
DML statements against the segment. During this phase, Oracle invalidates
any cursors referencing the segment as well. This second phase lasts for a very
short period.
During the compacting phase, the object is online and available, but during
the second phase, the object becomes unavailable, albeit very briefly.
The basic statement to shrink segments performs both phases of the segment-
shrinking operation (first compacting, then resetting the HWM and releasing the
space) in sequence. Here’s the statement:
SQL> alter table test SHRINK SPACE;
Once you issue the ALTER TABLE table SHRINK SPACE command,
Oracle will first compact the segment, and then reset the HWM level and yield
the freed space to the tablespace.
To avoid disruption of DML activity and cursor invalidation problems,

perform just the compact operations during peak levels of activity.
Since the second phase, the resetting of the HWM, will affect DML operations,
you may not want to use it when a large number of users are connected to the database.
Instead, you may want to issue the following command, which compacts only the
space in the segment:
SQL> alter table test SHRINK SPACE COMPACT;
This way, during peak hours, the database will merely compact the space in the
segment. During off-peak hours, you can issue the ALTER TABLE test SHRINK
SPACE command, and this will finish the shrinking process by performing the
second phase.
If you use the CASCADE option during a

segment-shrinking operation, all the dependent
segments will be shrunk as well. For example,
If you use the ALTER if you shrink a table, all the dependent index
TABLE table_name SHRINK SPACE segments will be automatically shrunk. Here’s
command to shrink a table, Oracle will how you specify the CASCADE option:
compact the space, adjust the HWM, and
SQL> alter table test SHRINK SPACE CASCADE;
release the space. If you add the COMPACT
clause, Oracle will only compact the space
in the table segment. Shrinking Segments
You can easily perform all segment-shrinking operations using the OEM Database
Control interface. First, make sure that you have row movement enabled for the
segment you wish to shrink. You can enable row movement using the Database
Control, by following the links Schema, Tables, Edit Tables, then Options. Here,
you can enable row movement by choosing that option for your segment.
You can shrink a table segment by first choosing the Tables link under the Schema
listing. On the Tables page, select Shrink Segments from the Actions field and click
Go. This takes you to the Shrink Segment page, shown in Figure 6-1. On this page,
you can choose to shrink a segment in the two ways described in the previous section:
■ Compact segments and release space

■ Compact segments
Using the Segment Advisor

How do you know which of your segments is a good candidate for shrinking? How do
you find out which objects have unused space that they won’t be needing in the future?
Using the new Segment Advisor, you can easily identify the segments that are
good candidates for shrinking. The Segment Advisor bases its recommendations on
the amount of fragmentation within an object. It determines whether objects have
enough space to be reclaimed, taking into account the future space requirements.
It bases its estimates of the future space requirements of an object on historical
trends. Besides helping you select candidates for shrinking, the Segment Advisor is
also helpful in sizing new database objects. The following sections describe how to
use the advisor for both purposes.
FIGURE 6-1 The Database Control Shrink Segment page
Choosing Candidate Objects for Shrinking

You can invoke the Segment Advisor at either the individual segment level or tablespace
level. You can call the Segment Advisor from the Database Control’s Advisor Central
page (from the Database Home page, click Advisor Central in the Related Links section,
and then click Segment Advisor), Tablespaces page, or Schema Object page. Figure 6-2
shows the main Segment Advisor page.
You can run the Segment Advisor in two modes:
■ Comprehensive analysis The Segment Advisor will perform an analysis

regardless of whether there are prior statistics. If there aren’t any prior
statistics, the Segment Advisor will sample the objects before generating
its recommendations. This analysis is more time-consuming.
■ Limited analysis This analysis is based strictly on the statistics collected
on the segment. If there aren’t any statistics or an object, the advisor won’t
perform any analysis.
FIGURE 6-2 The Database Control Segment Advisor page
Where does the Segment Advisor get the data for its recommendations? The
Automatic Workload Repository (AWR) collects all space-usage statistics during
its regular snapshot collection. The Segment Advisor, to estimate future segment
space needs, uses the growth trend report based on the AWR space-usage data.
The growth trend report predicts future segment growth patterns as well as traces
past growth trends. The Segment Advisor stores its results in the AWR as well.
You must use locally managed tablespaces if you want the database to produce
growth trend reports.
Estimating Object Size

When you create a new database, it is customary to use spreadsheets to help you figure
out how much space to allocate to new database objects like tables and indexes. You
can now use the Segment Advisor to determine your future segment resource usage.
You provide the structure of your table (column data types, column sizes, and the
PCTFREE parameter’s size) or index and the number of rows, and the advisor will
tell you how much space you need.
Using the Undo and Redo Logfile Size Advisors 11
In order to use the segment resource estimation feature, follow these steps:
1. From the Database Control home page, click the Administration tab.
2. Under the Storage section, click the Tables link.
3. Click the Create button to create a new table.
4. You’ll now be on the Create Table page. Under the Columns section, specify
your column data types. Then click the Estimate Table Size button.
5. On the Estimate Table Size page, specify the estimated number of rows in the
new table, under Projected Row Count. Then click the Estimated Table Size
button. This will show you the estimated table size.
Using the Undo and Redo Logfile Size Advisors

The Segment Advisor is not the only space-related advisor in Oracle Database 10g.
You can also use the Undo Advisor and the Redo Logfile Size Advisor to help you
manage the undo and redo activity in your database. Let’s look at how to use these
advisors.
The Undo Advisor

The Undo Advisor helps you perform the following tasks:
■ Set the undo retention period

■ Set the size of the undo tablespace
You can access the Undo Advisor through the Database Control, as follows:
1. From the Database Control home page, click Administration.

2. Click the Undo Management button, which is under the Instance list.
3. From the main Undo Management page, click the Undo Advisor button in
the right corner.
The AWR collects statistics on undo activity in the database. In Oracle Database 10g,
the database uses this AWR information to decide on the appropriate number of
undo segments to bring online when you start the instance. Oracle uses the same
AWR data to decide on the number of undo segments to bring online when you
switch undo tablespaces. In both cases, the ramp-up time for the database to bring
undo segments online is much lower than in previous versions.
The Redo Logfile Size Advisor

You can control database recovery time by setting the appropriate size for the mean time
to recover (MTTR) from a crash. The FAST_START_MTTR_TARGET initialization
parameter determines instance recovery time after a crash.
In order to be of the optimal size, your redo log files should be set just large enough
that the database isn’t performing more checkpoints than that required by the value
of your FAST_START_MTTR_TARGET parameter. Small log file sizes may mean that
the database writer will be performing incremental checkpointing more frequently
than what is dictated by your MTTR value. As you know, frequent log switching
will tend to drive the incremental checkpoint activity, causing the database writer
to perform excessive disk I/O. Ideally, this activity should be driven by the MTTR
target rather than by log switching. So, too small a size for the redo log files could
result in excessive checkpointing, which in turn, increases disk activity, which is
detrimental to system performance. However, if you set the redo log file size too
large, there isn’t enough checkpointing, which makes it harder to meet your MTTR
requirements.
The Redo Logfile Size Advisor is enabled only if you set the FAST_START_
MTTR_TARGET parameter.
The Redo Logfile Size Advisor will make recommendations about the smallest online
redo log files you can use. This advisor recommends that you size your redo log files
to at least the recommended minimum size. A new column in the V$INSTANCE_
RECOVERY view, OPTIMAL_LOGFILE_SIZE, shows you the optimal size of the
redo log file for your FAST_START_MTTR_TARGET setting.
You can access the Redo Logfile Size Advisor through the Database Control,
as follows:

2. Under the Storage section, choose Redo Log Groups.
Tablespace Enhancements 13
3. Select any redo log group, and then choose the Sizing Advice option from
the Action drop-down list.
4. Click Go to get the redo log file size advice.
Tablespace Enhancements
Oracle Database 10g includes several interesting enhancements pertaining to tablespaces.
These enhancements involve the management the SYSAUX tablespace, default
permanent tablespaces, temporary tablespace groups, and bigfile tablespaces. Let’s start
our discussion with the management of the new SYSAUX tablespace.
Managing the SYSAUX Tablespace

Oracle Database 10g mandates the creation of the SYSAUX tablespace, which serves
as an auxiliary to the SYSTEM tablespace.
Until now, the SYSTEM tablespace was the default location for storing objects
belonging to components like the Workspace Manager, Logical Standby, Oracle
Spatial, Logminer, and so on. The more features the database offered, the greater
was the demand for space in the SYSTEM tablespace. In addition, several features
had to be accommodated in their own repositories, like the Enterprise Manager and
its Enterprise Manager repository, and the Oracle Text feature with its DRSYS location.
On top of all this, you had to create a special tablespace for the STATSPACK repository.
To alleviate this pressure on the SYSTEM tablespace and to consolidate all the
repositories for the various Oracle features, Oracle Database 10g offers the SYSAUX
tablespace as a centralized, single storage location for various database components.
Using the SYSAUX tablespace offers the following benefits:
■ You have fewer tablespaces to manage, because you don’t need to create
a separate tablespace for many database components. You just assign the
SYSAUX tablespace as the default location for all the components.
■ There is reduced pressure on the SYSTEM tablespace, which is used as
the default tablespace for several features.
■ If you are using Real Application Clusters (RAC) with raw devices, you’ll
have fewer raw devices to manage, since every tablespace under RAC requires
at least one raw device.
The size of the SYSAUX tablespace depends on the size of the database components
that you’ll store in it. Therefore, you should base your SYSAUX tablespace sizing
on the components and features that your database will use. Oracle recommends
that you create the SYSAUX tablespace with a minimum size of 240MB.
Creating the SYSAUX Tablespace

If you use the Oracle Database Configuration Assistant (DBCA), you can automatically
create the SYSAUX tablespace when you create a new database, whether it is based
on the seed database or is a completely new, built from scratch, user-defined database.
During the course of creating a database, the DBCA asks you to select the file location
for the SYSAUX tablespace. When you upgrade a database to Oracle Database 10g,
the Database Upgrade Assistant (DBUA) will similarly prompt you for the file information
for creating the new SYSAUX tablespace.
You can create the SYSAUX tablespace
manually during database creation time. Here’s
The SYSAUX tablespace the syntax for creating the SYSAUX tablespace
is mandatory, whether you create a new (showing only the relevant parts of the CREATE
tablespace or migrate to Oracle Database 10g. DATABASE statement):
Create database mydb

user sys identified by abc1def
user system identified by uvw2xyz
...
sysaux datafile '/u01/oracle/oradata/mydb/sysaux01.dbf' size 500M reuse
...
;
You can set only the datafile location when you create the SYSAUX tablespace
during database creation, as shown in the preceding example. Oracle sets all the
What happens if you omit Files (OMF), the datafile location will
the SYSAUX creation clause from the be dependent on the OMF initialization
CREATE DATABASE statement? Oracle parameters. If you include the DATAFILE
will create the SYSAUX tablespace anyway. clause for the SYSTEM tablespace, you
Oracle will create both the SYSTEM and must use the DATAFILE clause for the
SYSAUX tablespaces automatically, with SYSAUX tablespace as well, unless you
their datafiles in system-determined default are using OMF.
locations. If you are using Oracle Managed
other attributes, which are mandatory. You cannot later change the location or other
attributes with the ALTER TABLESPACE command.
Oracle requires that the SYSAUX tablespace have the following attributes:
■ Permanent
■ Read/write
■ Locally managed
■ Automatic segment space management
Altering the SYSAUX Tablespace

If you have the SYSDBA system privilege, you can alter the SYSAUX tablespace, using
the same ALTER TABLESPACE command that you use for your other tablespaces.
SQL> alter tablespace sysaux add datafile
'/u01/app/oracle/prod1/oradata/sysaux02.dbf' size 500M;
Usage Restrictions for the SYSAUX Tablespace

Although the use of the ALTER TABLESPACE command may make it seem like the
SYSAUX tablespace is similar to the other tablespaces in your database, several usage
features set the SYSAUX tablespace apart. Here are the restrictions:
■ You can’t drop the SYSAUX tablespace by using the DROP TABLESPACE
command during normal database operation.
■ You can’t rename the SYSAUX tablespace during normal database operation.
■ You can’t transport a SYSAUX tablespace.
Relocating SYSAUX Occupants

As you recall, the purpose behind the creation of the SYSAUX tablespace is the need
for storing data belonging to the large number of database components in Oracle
Database 10g. What happens if you later decide that you want to move components
out of the SYSAUX tablespace to a different tablespace? You may want to do this in
response to a severe space pressure on the SYSAUX tablespace, for example.
You can monitor space usage of the SYSAUX tablespace occupants by using the
new data dictionary view V$SYSAUX_OCCUPANTS. Here’s the structure of this view:
SQL> desc v$sysaux_occupants
Name Null? Type
----------------------------------------- -------- --------------
OCCUPANT_NAME VARCHAR2(64)
OCCUPANT_DESC VARCHAR2(64)
SCHEMA_NAME VARCHAR2(64)
MOVE_PROCEDURE VARCHAR2(64)
MOVE_PROCEDURE_DESC VARCHAR2(64)
SPACE_USAGE_KBYTES NUMBER
The SPACE_USAGE_KBYTES column will tell you how much of the SYSAUX
tablespace’s space each of its occupants is currently using. The MOVE_PROCEDURE
column tells you the specific procedure you must use in order to move a given
occupant out of the SYSAUX tablespace.
Let’s say that you decide to move an occupant
of the SYSAUX tablespace into a new tablespace.
You can move occupants You must first find out which procedure you must
into and out of the SYSAUX tablespace. In use to move this occupant, since each of the
order to perform the move operation, you occupants of the SYSAUX tablespace may need
must have the SYSDBA privilege and ensure a separate procedure to allow this.
that tablespace is online. For each user of Here’s a simple query that demonstrates how
the SYSAUX tablespace, there is a specific to find out which procedure to employ for moving
move procedure to effect the move. an occupant of the SYSAUX tablespace:
SQL> select occupant_name, move_procedure
2* from v$sysaux_occupants
OCCUPANT_NAME MOVE_PROCEDURE
---------------------------------------------------------------- ---------------
LOGMNR SYS.DBMS_LOGMNR_D.SET_TABLESPACE
LOGSTDBY SYS.DBMS_LOGSTD BY.SET_TABLESPACE
STREAMS
AO DBMS_AW.MOVE_AWMETA
XSOQHIST DBMS_XSOQ.Olapi MoveProc
SM/AWR
SM/ADVISOR
SM/OPTSTAT
SM/OTHER
STATSPACK
ODM MOVE_ODM
SDO MDSYS.MOVE_SDO
WM DBMS_WM.move_proc
ORDIM
ORDIM/PLUGINS
ORDIM/SQLMM
EM emd_maintenance.move_em_tblspc
TEXT DRI_MOVE_CTXSYS
ULTRASEARCH MOVE_WK
JOB_SCHEDULER
20 rows selected.
SQL>
Once you find out the name of the correct procedure to employ in order to
move a SYSAUX occupant, you can perform the move itself, using the appropriate
procedure. For example, you can move the
occupant named WM in the following manner:
SQL> exec dbms_wm.move_proc('DRSYS')
You can’t relocate the
following occcupants of the SYSAUX This preceding MOVE statement will move
tablespace: STREAMS, STATSPACK, JOB_ the user WM from the SYSAUX tablespace
SCHEDULER, ORDIM, ORDIM/PLUGINS, to the DRSYS tablespace.
ORDIM/SQLMM, and SMC.
Renaming Tablespaces
In previous versions of Oracle, a major limitation concerning tablespaces was that you
couldn’t rename a tablespace once you created it. In Oracle Database 10g, you can rename
tablespaces easily by using a simple command (from users to users_new in this example):
SQL> alter tablespace users rename TO users_new;
The ability to rename tablespaces saves substantial amounts of administrative time

and effort. You can rename permanent as well as temporary tablespaces.
You can now transport a tablespace even if the target database contains identically
named tablespaces as the source. You just need to rename the identically named
tablespaces in the target database before you start the transport of the tablespaces.
Oracle advises you not to use tablespace names as part of the filenames, since
Oracle will not rename the datafiles as part of the tablespace-renaming procedure.
If you perform recovery on a datafile whose header contains the old tablespace
name, once you recover past the tablespace renaming point, the datafile header will
replace the old tablespace name with its new name.
There are some restrictions and requirements, however, in renaming tablespaces:
■ Your compatibility level must be set to 10.0 or higher.

■ You can’t rename the SYSTEM or SYSAUX tablespace, or offline tablespaces.
■ Tablespace identifiers remain the same.
■ If the renamed tablespace is the default tablespace for any user before the
renaming, it will continue being the default after renaming.
■ If the tablespace is read-only, the datafile headers aren’t updated, although
the control file and the data dictionary are.
For an undo tablespace, the name change has different implications, based on
whether you used the init.ora file or the SPFILE to start the instance. If you are
using the init.ora file, Oracle writes a message stating that you should change the
value (location) of the UNDO_TABLESPACE parameter in the init.ora file. If you
used the SPFILE to start the instance, Oracle will automatically write the new name
for the undo tablespace in your SPFILE, provided you specified the tablespace name
as the undo tablespace name in your SPFILE.
Default Permanent Tablespaces

Every user in an Oracle database has a default permanent tablespace, which is where
the objects created by that user will be placed by default. For example, if the user
doesn’t specify a tablespace in a CREATE TABLE statement, that table will go into
the user’s default tablespace.
What happens when you don’t specify a default tablespace for a user? Well, in
previous versions of Oracle, the SYSTEM tablespace automatically became the
default permanent tablespace for that user. That’s not exactly a smart thing, since
you don’t want just any user to start creating objects in the SYSTEM tablespace.
In Oracle Database 10g, if you don’t specify a default tablespace during user creation,
the user isn’t automatically expected to use the SYSTEM tablespace as the default
tablespace. You can now create a default
permanent tablespace that all users will use as
the default permanent tablespace, when you
The users SYS, SYSTEM, don’t specifically assign a permanent tablespace
and OUTLN continue to use the SYSTEM during user creation.
tablespace as their default permanent You can use the Database Control or SQL
tablespace. All the other users must use statements (ALTER DATABASE) to designate
the new default permanent tablespace. a default permanent tablespace. You can also
specify a default permanent tablespace during
database creation time. In the following sections, we’ll look at the different ways
to designate the default permanent tablespace.
You can’t drop a default permanent tablespace without attending to some

preliminaries first. You must first assign a different tablespace as the default
tablespace for all the users, and only then proceed to dropping the current
default tablespace.
Specifying the Default Tablespace During Database Creation

You can specify a default permanent tablespace during database creation by using the
new DEFAULT TABLESPACE clause. Here’s a (partial) database creation statement
showing how to use the DEFAULT TABLESPACE clause to specify a default permanent
tablespace named deftbs for all users in the database:
SQL> create database mydb
user SYS identified by abc1def
user SYSTEM identified by uvw2xyz
default tablespace deftbs datafile …
…;
The DEFAULT TABLESPACE clause isn’t mandatory. If you don’t use one, Oracle
will still create the database, with the SYSTEM tablespace set as the default tablespace,
as in previous versions. However, Oracle recommends that you specify the DEFAULT
TABLESPACE clause explicitly, so your users aren’t forced to use the SYSTEM
tablespace as their default tablespace.
Using the Database Control to Specify the Default Tablespace

You can use the OEM Database Control to quickly assign and change the default
permanent tablespace for your database. Here’s the procedure for designating a
default permanent tablspace using the Database Control:

2. From the Storage Section, choose the Tablespaces link.
3. Click the tablespace you want to designate as the default permanent tablespace.
If the tablespace doesn’t exist, first create it before you proceed any further.
4. From the Edit Tablespace page, select the Set As Default Permanent
Tablespace option in the Type section. Then click Apply.
Using SQL to Specify the Default Tablespace

You can designate any tablespace as the default permanent tablespace after database
creation by using the ALTER TABLESPACE command, as follows:
SQL> alter database default tablespace new_tbsp;
When you designate a default tablespace in this manner, all current users will
be assigned to the new default permanent tablespace. New users are automatically
allotted this tablespace as their default permanent tablespace as well.
Viewing Default Tablespace Information

To find out what the name of your current default permanent tablespace is, simple
execute the following query, which uses the view DATABASE_PROPERTIES:
SQL> select property_value from database_properties
2 where property_name='DEFAULT_PERMANENT_TABLESPACE';
PROPERTY_VALUE
---------------------------
USERS
SQL>
Temporary Tablespace Groups

Large transactions may sometimes run out of temporary space. Large sort jobs, especially
on tables with many partitions, strain temporary tablespaces. Oracle Database 10g
introduces the concept of a temporary tablespace group, which actually represents a list
of temporary tablespaces. Using a tablespace group, a user can utilize multiple temporary
tablespaces simultaneously in different sessions.
Using temporary tablespace groups, rather than the usual single temporary tablespace,
provides several benefits, including the following:
■ SQL queries are less likely to run out of sort space, because the query can
now use several temporary tablespaces for sorting.
■ You can now specify multiple default temporary tablespaces at the database
level.
■ Parallel execution servers in a parallel operation will efficiently utilize
multiple temporary tablespaces.
■ A single user can simultaneously use multiple temporary tablespaces in
different sessions.
How does one go about creating a temporary tablespace group? Well, interestingly,
you don’t explicitly create a temporary tablespace group. When you assign the first
temporary tablespace to a tablespace group, you automatically create the temporary
tablespace group.
Characteristics of Temporary Tablespace Groups

Here are some of the main characteristics of a temporary tablespace group:
■ There is a minimum of one tablespace in a temporary tablespace group.

There is no explict maximum number of tablespaces.
■ If you delete all members from a temporary tablespace group, the group is
automatically deleted as well.
■ A temporary tablespace group has the same namespace as tablespaces.
■ You can’t name a temporary tablespace the
same as the name of any tablespace group.
■ When you need to assign a temporary
Just as a temporary
tablespace to a user, you can just use the
tablespace group is created when you assign
temporary tablespace group name, instead
the first temporary tablespace to it, the
of the actual temporary tablespace. This
group is also deleted when you remove the
principle also applies when you create the
last temporary tablespace from the group.
default temporary tablespace for the database.
Creating a Temporary Tablespace Group

You implicitly create a temporary tablespace group when you specify the TABLESPACE
GROUP clause in a CREATE TABLESPACE statement, as shown here:
SQL> create temporary tablespace temp_old tempfile

'/u01/oracle/oradata/temp01.dbf'
size 500M
tablespace group group1;
The preceding SQL statement will create a new temporary tablespace, temp_now,
along with the new tablespace group named group1. Oracle creates the new tablespace
group since the temporary tablespace temp_old is the first tablespace assigned to it.
You can also create a temporary tablespace group by specifying the same TABLESPACE
GROUP clause in an ALTER TABLESPACE command, as shown here:
SQL> alter tablespace temp_old
2 tablespace group group1;
Tablespace altered.
SQL>
In the preceding statement, since there wasn’t a prior temporary tablespace group
named group1, Oracle will create a new group with that name.
Creating Temporary Tablespaces Not Belonging to a Group

To tell Oracle not to allocate a temporary tablespace to a tablespace group, specify
a pair of quotation marks ('')—for the tablespace group name. Here’s an example:
SQL> create temporary tablespace temp_new tempfile 'temp_new1.f'
SIZE 500m TABLESPACE GROUP '';
The preceding statement creates a temporary tablespace called temp_new, which is like the
traditional temporary tablespaces and doesn’t belong to a temporary tablespace group.
Use the TEMPFILE clause, not the DATAFILE clause, when you allocate
space to a temporary tablespace.
If you completely omit the TABLESPACE GROUP clause, you’ll create just a regular
temporary tablespace, which is not part of any temporary tablespace group, as shown in
the following example.
SQL> create temporary tablespace temp_new2
2 tempfile 'c:\oracle\tmp3.f' size 5M;
Tablespace created.
SQL>
Adding a Tablespace to
Temporary Tablespace Group
You add a temporary tablespace to group by using
If you specify the NULL
the ALTER TABLESPACE statement. You can
tablespace group (for example, CREATE
also change the group a temporary tablespace
TEMPORARY TABLESPACE GROUP …
belongs to in the same way. For example, you
GROUP ''), it is equivalent to the normal
can specify that your new tablespace temp_new
temporary tablespace creation statement
belong to the group named group1 by issuing the
(without any groups).
following command:
SQL> alter tablespace temp_new tablespace group group1;
Note that the database would create a new group with the name group1 if that
group did not already exist.
Setting a Group As the Default

Temporary Tablespace for the Database
You can use a temporary tablespace group as your mandatory default temporary
tablespace for the database. If you issue the following command, all users without a
default tablespace can use both the temp_old and temp_new tablespaces (assuming
that they are part of the group group1) as their default temporary tablespaces.
SQL> alter database default temporary tablespace group1;
Database altered.
SQL>
This assigns all the tablespaces in group1 as the default temporary tablespaces for the
database.
Using a Temporary Tablespace Group

When You Create and Alter Users
When you create new users, you can now assign users to a temporary tablespace group,
instead of the usual single temporary tablespace. Here’s an example:
SQL> create user sam identified by sam
2 DEFAULT TABLESPACE users
3* TEMPORARY TABLESPACE group1;
User created.
SQL>
Once you create a user, you can also use the ALTER USER statement to change
the temporary tablespace group of the user. Here’s the SQL statement to do this:
SQL> alter user sam temporary tablespace group2;
Viewing Temporary Tablespace Group Information

You can use the new data dictionary view DBA_TABLESPACE_GROUPS to manage
the temporary tablespace groups in your database. Here is a simpley query on the view
that shows the names of all tablespace groups:
SQL> select group_name, tablespace_name
2 from dba_tablespace_groups;
GROUP_NAME TABLESPACE_NAME
----------------------------------
GROUP1 TEMP01
SQL>
You can also use the DBA_USERS view to find out which temporary tablespaces
or temporary tablespace groups are assigned to each user. Here’s an example:
SQL> select username, temporary_tablespace from dba_users;
USERNAME TEMPORARY_TABLESPACE
------------------------------ -----------------------------
SYS TEMP
SYSTEM TEMP
SAM GROUP1
SCOTT TEMP
. . .
SQL>
Bigfile Tablespaces
Oracle Database 10g can contain up to 8 exabytes (8 million terabytes) of data. Don’t
panic, however, thinking how many milions of datafiles you need to manage in order
to hold this much data. You now have the option of creating really big tablespaces,
called, appropriately, bigfile tablespaces. A bigfile tablespace (BFT) contains only one
very large file. Depending on the block size, a bigfile tablespace can be as large as 128
terabytes.
In previous versions, you always had to juggle with the distinction between datafiles
and tablespaces. Now, using the bigfile concept, Oracle has made a tablespace logically
equal to a datafile, by creating the new one-to-one relationship between tablespaces
and datafiles. With Oracle Managed Files, datafiles are completely transparent to
you when you use a bigfile tablespace, and you can directly deal with the tablespace
itself in many kinds of operations.
Here’s a summary of the many benefits
offered by using bigfile tablespaces:
The traditional tablespaces ■ You need to create only as many datafiles

are now referred to as smallfile tablespaces. as there are tablespaces. Fewer datafiles
Smallfile tablespaces are the default mean that you can use a smaller setting for
tablespaces in Oracle Database 10g. the DB_FILES initialization parameter.
You can have both smallfile and bigfile (The DB_FILES parameter determines
tablespaces in the same database. the maximum number of datafiles that can
be open.)
■ You don’t need to constantly add datafiles to your tablespaces.
■ You have simplified datafile management in large databases, because you deal
with tablespaces directly, not many datafiles.
■ The database has a significant increase in storage capacity, because you don’t
reach the maximum files limitation quickly when you use bigfile tablespaces.
■ You can set the CREATE DATABASE clause MAXDATAFILES to a lower
size, and thus reduce the size of the control file. The MAXDATAFILES
parameter specifies the control file’s initial space allocation to datafile
information.
Restrictions on Using Big File Tablespaces

There are few restrictions on using bigfile tablespaces. You can use bigfile tablespaces
only if you use a locally managed tablespace with ASSM. Oracle also recommends that
you use bigfile tablespaces along with a Logical Volume Manager (LVM) or the Automatic
Storage Management (ASM) feature, which support striping and mirroring. Otherwise,
you can’t really support the massive datafiles that underlie the bigfile tablespace concept.
Both parallel query execution and RMAN backup parallelization would be adversely
impacted if you used bigfile tablespaces without striping.
To avoid creating millions of extents when you use a bigfile tablespace in a very
large (greater than a terabyte) database, Oracle recommends that you change the
default extent allocation policy (AUTOALLOCATE) to UNIFORM and set a very high
extent size. In databases that aren’t very large, Oracle recommends that you stick to
the default AUTOALLOCATE policy and simply let Oracle take care of the extent sizing.
Locally managed undo and temporary tablespaces can be bigfile tablespaces,

even if you don’t use ASSM.
Making Bigfile the Default Tablespace Type

You can now specify bigfile as the default tablespace type during database creation.
If you don’t explicitly specify bigfile as your default tablespace type, your database
will have smallfile tablespaces as the default. Smallfile tablespaces are nothing but
the normal traditional tablespaces that you use currently in Oracle databases. Here’s
a portion of the CREATE DATABASE statement showing how you specify a bigfile
tablespace as the default:
create database test
set default bigfile tablespace
…
You can also dynamically change the default tablespace type to bigfile (or smallfile),
thus making all tablespaces you subsequently create that type. Here’s an example
that shows how to set the default tablespace type in your database to bigfile from
now on:
SQL> alter database set default bigfile tablespace;
Once you set the default type of your tablespace, all the tablespaces you subsequently
create will be of the bigfile type, unless you manually override the default setting, as
shown in the next section.
Creating a Bigfile Tablespace Explicitly

Irrespective of which default type you choose—bigfile or smallfile—you can always create
a bigfile tablespace by specifying the type explicitly in the CREATE TABLESPACE
statement, as shown here:
create bigfile tablespace bigtbs
datafile '/u01/oracle/data/bigtbs_01.dbf' size 100G
...
In the preceding statement, the explicit specification of the BIGFILE clause

will overrirde the default tablespace type, if it was a smallfile type. Note that if your
default tablespace type was bigfile, then you can use the keyword SMALLFILE to
override the default type when you create a tablespace.
When you specify the CREATE BIGFILE TABLESPACE tablespace_
name clause, Oracle will automatically create a locally managed tablespace with
ASSM. You can specify the datafile size in kilobytes, megabytes, gigabytes, or
terabytes.
Creating bigfile tablespaces on operating system platforms that don’t support

large files will limit tablespace capacity to the maximum file size that the
operating system can support.
Migrating Database Objects

You can migrate database objects from a smallfile tablespace to a bigfile tablespace or
vice versa, if you are planning to change your tablespace type. You can migrate the
objects using the ALTER TABLE … MOVE or the CREATE TABLE AS SELECT
command. Alternatively, you may use the Data Pump export and import tools to move
the objects between the two types of tablespaces, as described in Chapter 2.
Altering a Bigfile Tablespace’s Size

You can use the RESIZE and AUTOEXTEND clauses in the ALTER TABLESPACE
statement to modify the size of a bigfile tablespace.
The RESIZE clause lets you resize a bigfile tablespace directly, without using the
DATAFILE clause, as shown here:
SQL> alter tablespace bigtbs resize 120G;
The AUTOEXTEND clause enables automatic file extension, again without referring
to the datafile. Here’s an example:
SQL> alter tablespace bigtbs autoextend on next 20G;
Note that both these space extension clauses can be used directly at the tablespace
level, not the file level. Thus, both of these clauses provide datafile transparency—you
deal directly with the tablespaces and ignore the underlying datafiles.
Viewing Bigfile Tablespace Information

You can gather information about the bigfile tablespaces in your database by using the
following data dictionary views:
■ DBA_TABLESPACES
■ USER_TABLESPACES
■ V$TABLESPACE
All three views have the new column BIGFILE, whose value indicates whether
a tablespace is of the bigfile type (YES) or smallfile type (NO).
You can also use the following query to determine the default tablespace type for
your database:
SQL> select property_value
2 from database_properties
3* where property_name='DEFAULT_TBS_TYPE';
PROPERTY_VALUE
--------------
SMALLFILE
SQL>
The following query helps in finding out which of your tablespaces have bigfile
tablespaces:
SQL> select tablespace_name, bigfile FROM dba_tablespaces;
TABLESPACE_NAME BIG
----------------- --------
SYSTEM NO
RBS NO
USERS NO
TEMP NO
TOOLS NO
INDX NO
DRSYS NO
SYSAUX NO
BIG_TBS YES
9 rows selected.
SQL>
Bigfile Tablespaces and ROWID Formats

Bigfile tablespaces use the extended ROWID format, and the only supported way to
extract the ROWID components is by using the DBMS_ROWID package. The DBMS_
ROWID package lets you create and extract the components of ROWIDs. Smallfile and
bigfile tablespaces have different formats; therefore, you must specify the tablespace
type when you use the DBMS_ROWID package. You can specify the tablespace type by
using the new parameter TS_TYPE_IN, which can take the values BIGFILE and
SMALLFILE.
For bigfile tablespaces, there is only a single file, with the relative file number always
set to 1024. The encoded block number consists of a concatenation of the datafile
number and the data block that contains the row. For smallfile tablespaces, the
ROWIDs are in the format Object# - File# - Block# - Row#. For bigfile tablespaces,
the format is Object# - Block# - Row#.
The encoded block number for bigfile tablespaces can be much larger than those
for traditional smallfile tablespaces. Bigfile tablespace block numbers are relative to
the tablespace the rows belong to, and are unique as well.
If you are using bigfile tablespaces to construct an internal or external

ROWID string, use the ROWID_CREATE function of the DBMS_ROWID
package. The relative file number (RELATIVE_FNO) will always be 1024
for bigfile tablespaces.
Using Sorted Hash Clusters 29
You can use the DBMS_ROWID package to get the ROWID formats of a bigfile
tablespace, as shown here:
SQL> select distinct DBMS_ROWID.ROWID_RELATIVE_FNO
(ROWID,'BIGFILE ')
FROM test_rowid;
Since the ROWID formats are different for bigfile and smallfile tablespaces, the
database needs to know the tablespace type when it is creating and extracting ROWIDs.
Several parameters belonging to the package DBMS_ROWID need to use the new
input parameter TS_TYPE_IN, which informs Oracle whether the tablespace type
is bigfile or smallfile. The TS_TYPE_IN parameter can take the values BIGFILE
or SMALLFILE. It is a part of the DBMS_ROWID procedures ROWID_INFO, ROWID_
BLOCK_NUMBER, and ROWID_RELATIVE_FNO.
Using Sorted Hash Clusters

Suppose you have a query that requires that the rows be returned in a specific order.
You can’t specify that Oracle save the table data in the same order as the query might
require it to be output. Oracle bases its row placement in the table purely on storage
conditions. To guarantee a specific row order, you must use an ORDER BY clause.
The ORDER BY clause will return the rows in a guaranteed order, but often involves
a substantial use of memory and CPU time. Oracle Database 10g introduces the new
sorted hash cluster storage scheme, which can help you retrieve sorted data faster and
with much less resource usage.
What Is a Sorted Hash Cluster?

When you are dealing with a set of tables that share common columns and are frequently
used together in queries, it is better to create a table cluster. A table cluster is a group of
tables that Oracle physically stores together in the same data blocks.
For example, suppose that your employees and departments table share the
department_id column. When you cluster the employees and departments tables,
Oracle stores all rows for each department from both the employees and departments
tables in the same physical location (same data blocks). A cluster key value is the
value of the cluster key columns for a particular row. In our example, department_id
is your cluster key. Since you store related rows physically together, your disk I/O will
be less and disk-access times will be faster. You might gain substantially by clustering
tables that you frequently join in many of your queries.
A hash cluster groups data according to a hash function it applies to the cluster
key value of each row. Oracle then stores all rows with identical cluster key values
together on disk. Hash clusters are recommended when you frequently use equality
queries (for example, return all rows for dept_id=20). Oracle hashes the cluster key
value, and the hashed key value will point directly to the area on disk where the
rows are stored.
In a sorted hash cluster, rows corresponding to
individual values of the hash function are sorted
on specific columns. The rows are organized as
The selection of the order lists of sorted rows, with each list corresponding
key column for a sorted hash cluster to a separate value of the hash key column. Each
is important, since you would need list will then have its rows sorted in the order
additional sorting when you use an specified by the sort key columns. In other words,
ORDER BY clause on a suffix of the the table’s rows are already presorted by the sort
sort key columns. The same is true key column.
when you use nonsorted key columns. Here are some of the main features of sorted
hash clusters:
■ You can create indexes on sorted hash clusters.

■ You must use the cost-based optimizer, with up-to-date statistics on the
sorted hash cluster tables.
■ You can insert row data into a sorted hash clustered table in any order, but
Oracle recommends inserting them in the sort key coumn order, since it’s
much faster.
Defining Sort Hash Clusters

In order to define a sorted hash cluster, you must first create the cluster itself, and then
create the actual table or tables that are part of the cluster. Let’s look at both of these steps.
Using Sorted Hash Clusters 31
Creating the Cluster

When you create a regular hash cluster, you
need to specify only the cluster key. To create a
For a given cluster key sorted hash cluster, you must specify an additional
value, the cluster can return the rows in sort key as well. Thus, the sort hash cluster has
ascending or descending order. If you want two keys: the cluster key and the sort key. Here’s
to retrieve rows in ascending order, the the statement that creates a cluster called
ORDER BY clause isn’t mandatory. message_cluster:
SQL> create cluster call_cluster
2 (call_number NUMBER
3 , call_timestamp NUMBER SORT
4 , call_duration NUMBER SORT)
5 hashkey 10000
6 single table hash is order_number
7 size 50;
Cluster created.
SQL>
In the call_cluster cluster, the cluster key is call_number, and the combination of
call_time and call_duration is the sort key. SIZE indicates the space in bytes that is
necessary to store the cluster key metadata.
Creating Cluster Tables

In order to define a table as part of the sorted hash cluster, you must use the CLUSTER
clause when you create the table. You must also ensure that the table’s cluster key
columns and sort key columns are specified in the same order as in the parent cluster.
Here’s a simple example, showing the creation of the calls table, based on the call_
cluster cluster created in the previous section.
SQL> create table calls
2 (call_number NUMBER
3 , call_timestamp NUMBER
4 , call_duration NUMBER
5 , call_info VARCHAR2(50))
6 CLUSTER call_cluster
7 (origin_number,call_timestamp,call_duration);
Table created.
SQL>
The calls table is linked to the call_cluster cluster with the keyword CLUSTER.
This table stores the call records for a company, with the origin_number column
representing the originating telephone number. The calls from each originating
number are processed during the preparation of customer bills. The idea is that by
storing them in a sorted hash cluster, it is easy to process the bills on a first-in, first-
out basis, if they are already sorted on the sort key, consisting of the call_timestamp
and call_duration columns.
In our example, if you wanted to query the orders table for a certain order_number
(the cluster key), the cluster key value is hashed to its metadata entry in the sorted
hash cluster segment. This provides the sorted list of rows for that particular hash
key column.
Copying Files Using the Database Server

You normally use UNIX or Windows utilities to copy or move binary files. Oracle
Database 10g introduces a new way to copy files using the database server itself.
By using this new file-copy method, you bypass the operating system altogether.
The DBMS_FILE_TRANSFER package helps you copy binary files to a different
location on the same server or transfer files between Oracle databases.
Both the source and destination files should be of the same type, either
operating system files or ASM files.
File Copy Requirements

There are a few prerequisites that you must satisfy in order to use the DBMS_FILE_
TRANSFER package to copy files locally or remotely:
■ The maximum file size is 2 terabytes, and the file must be in multiples of 512
bytes.
■ You can’t perform any character set conversion during the copy process.
■ All nonprivileged users of the database must have explicit privileges before
they can access a file created by using DBMS_FILE_TRANSFER.
Copying Files Using the Database Server 33
Let’s see how you can use the DBMS_FILE_TRANSFER package to perform
various types of file-copy procedures.
Copying Files on a Local System

In order to copy files on a local file system, you must use the COPY_FILE procedure
of the DBMS_FILE_TRANSFER package. In the following example, a file named
exm_old.txt is being copied from the /u01/App/Oracle directory to the /u01/App/
Oracle/Example directory on the same server. In the process of copying the file, its
name is changed to exm_new.txt.
First, you must first create the necessary directories: one for the source and the
other for the destination directory. You can use the following commands to create
the directories:
create directory source_dir as '/u01/app/oracle';
create directory dest_dir as '/u01/app/oracle/example';
Once you create the directories, you must run the DBMS_TRANSFER.COPY_
FILE procedure to copy the file from the source to the destination directory. Here’s
the code:
begin
dbms_file_transfer.copy_file(
source_directory_object => 'SOURCE_DIR',
source_file_name => 'exm_old.txt',
destination_directory_object => 'DEST_DIR',
destination_file_name => 'exm_new.txt');
end;
A user other than the SYSTEM user must have the READ privilege on the
source directory and the WRITE privilege on the destination directory in
order to execute the DBMS_TRANSFER.COPY_FILE procedure.
Transferring a File to a Different Database

In the previous section, you saw how you can copy files on a local system. You can also
transfer files to make copies of local files on a remote file system. You use the PUT_
FILE procedure of the DBMS_FILE_TRANSFER package to perform this remote file
transfer.
Let’s use a simple example to demonstrate this interserver file-transfer capability.

As when you copy files on a local system, you first need to create the source and
destination directories. Then execute the PUT_FILE procedure as follows:
begin
dbms_file_transfer.put_file(
source_directory_object => 'SOURCE_DIR',
source_file_name => 'exm_old.txt',
destination_directory_object => 'DEST_DIR',
destination_file_name => 'exm_new.txt'
destination_database => 'US.ACME.COM');
end;
The preceding example uses the DESTINATION_DATABASE clause, which

enables you to transfer datafiles from your local server to another database. In order
to transfer a file the other way around, you must replace the PUT_FILE procedure
with the GET_FILE procedure.
You can monitor the progress of all your file-copy operations using the V$SESSION_
LONGOPS view. You may also use the Oracle Scheduler to schedule the file-copy
operations.
This chapter started with a review of proactive tablespace alerts. You then learned
about the new feature that allows you to reclaim space by shrinking segments. Next,
you saw how to use the Segment Advisor to estimate the size of database objects as
well as perform other useful tasks. You also quickly reviewed the two space-related
advisors: the Redo Logfile Size Advisor and the Undo Advisor.
The major portion of this chapter was spent discussing several interesting tablespace-
related features, including the ability to rename tablespaces, the mandatory SYSAUX
tablespace, the use of temporary tablespace groups, and default permanent tablespaces.
You also learned how the new bigfile tablespaces can make your job a lot easier when
you are dealing with very large databases.
Next, the chapter discussed sorted hash clusters, which reduce the need to sort data.
Lastly, you were introduced to the new Oracle Database 10g feature that enables you
to copy files directly through the database server.
Copying Files Using the Database Server 35
INSIDE THE EXAM
The certification exam asks you several questions temporary tablespace groups, as well as assign
about the new tablespace enhancements in and deassign temporary tablespaces to temporary
Oracle Database 10g. Expect at least one tablespace groups. Expect a question on the
question on the new SYSAUX tablespace, new bigfile tablespace type. Specifically, you
probably about the process of relocating must be aware of what the Oracle Database
occupants in and out of that tablespace. 10g default tablespace type is and how to
What are the special features (restrictions) change it.
of a SYSAUX tablespace, compared with a You must remember that you can now create
normal tablespace (you can’t rename, drop, a default permanent tablespace in Oracle
or transport a SYSAUX tablespace). Database 10g. The test may examine your
You must understand how to use the advisor understanding of the DEFAULT TABLESPACE
that will help you perform segment shrinking command to create a permanent default
(the Segment Advisor). You must also know tablespace during database creation. How do you
the prerequisites for a segment-shrinking alter the current default permanent tablespace?
operation. Of course, you are going to see a What is the default permanent tablespace when
question or two testing your knowledge of you create a new database using the Database
the difference between the SHRINK SPACE Configuration Assistant (DBCA)?
command with and without the COMPACT The tablespace renaming feature is new
option. When does Oracle compact space, and in Oracle Database 10g, and the exam may
when does it adjust the high-water mark and test your understanding of when you can and
release space held by a compacted object? cannot rename tablespaces. What are the best
The test focuses on the new temporary practices for tablespace renaming?
tablespace group concept. The test expects you You must also understand how to use the
to know the properties of temporary tablespace Redo Logfile Size Advisor to configure optimal
groups. You must also know how to create online redo log file sizes.
❑ All Oracle Database 10g tablespaces have built-in alerts.
❑ The warning tablespace alert is when the tablespace is 85 percent full,
and the critical alert is at 97 percent full.
❑ Use the DBMS_SERVER_ALERT package to set alert thresholds.
❑ Use the SET_THRESHOLD and GET_THRESHOLD procedures to manage
database thresholds.
❑ You can set alert thresholds for only locally managed tablespaces.

❑ The high-water mark (HWM) is the highest point of space usage ever
reached by a segment.
❑ You can use the new segment-shrinking capability to make segments release
space that is fragmented or empty.
❑ You can shrink tables, indexes, partitions, subpartitions, materialized views,
and materialized view logs.
❑ Segment shrinking in Oracle Database 10g is on line and in place.
❑ After a table-shrinking operation, the indexes are intact and in a usable state.
❑ You can shrink only segments in ASSM managed tablespaces
❑ You must first enable row movement before you can shrink a table, because
ROWIDs could change during a shrinking operation.
❑ By default, row movement is disabled at the segment level.
❑ You perform a segment-shrinking operation in two stages: compacting data
and releasing the space.
❑ DML statements can continue during the first stage, but not during the
second stage of shrinking a segment.
❑ Oracle recommends that you don’t perform the second stage of a segment-
shrinking operation during busy periods.
❑ Use the CASCADE option to shrink all the dependent objects of a segment.
Two-Minute Drill 37
❑ You can run the Segment Advisor in the comprehensive or limited mode.
❑ To estimate future space needs, the Segment Advisor uses the growth trend
reports.

❑ The Undo Advisor helps you set the undo retention period.
❑ You can also set the size of the undo tablespace with the help of the Undo
Advisor.
❑ The FAST_START_MTTR_TARGET parameter sets the instance recovery time.
❑ Too small redo log files relative to the MTTR setting lead to excessive
checkpointing.
❑ If the redo log files are too large, there isn’t enough checkpointing.
❑ You have optimally sized redo logs when the database isn’t performing any
more checkpointing than that required by the FAST_START_MTTR_
TARGET parameter.
❑ The SYSAUX tablespace is auxiliary to the SYSTEM tablespace and holds
data belonging to various Oracle components.
❑ The SYSAUX tablespace is mandatory in Oracle Database 10g.
❑ If you don’t create a SYSAUX tablespace, Oracle will create one by default.
❑ The SYSAUX tablespace keeps the pressure low on the SYSTEM tablespace
and makes it easier to manage the various database components.
❑ A SYSAUX tablespace must be read/write, permanent, locally managed, and
use ASSM.
❑ You can’t drop or rename the SYSAUX tablespace during normal tablespace
operations.
❑ You must use a specific “move procedure” to move an occupant of the SYSAUX
tablespace to a different tablespace.
❑ You can rename a tablespace by using the ALTER TABLESPACE command.
❑ You can’t rename the SYSTEM, SYSAUX, and offline tablespaces.
❑ You may specify a default permanent tablespace during database creation.
❑ You can use multiple temporary tablespaces simultaneously in various sessions,

by using the temporary tablespace group concept.
❑ You create a temporary tablespace group automatically when you assign a
temporary tablespace to it.
❑ A user can use multiple temporary tablespaces in different sessions.
❑ A bigfile tablespace consists of only a single large file.
❑ In a bigfile tablespace, there is a one-to-one relationship between a datafile
and a tablespace.
❑ If you use bigfile tablespaces, you can reduce the value of the MAXDATAFILES
clause during database creation and use a smaller setting for the DB_FILES
initialization parameter.
❑ Oracle recommends using bigfile tablespaces with file systems that support
striping and mirroring.
❑ You can have bigfile and smallfile tablespaces together in the same database.
❑ The default tablespace for a database continues to be the traditional smallfile
tablespace.
❑ You use the DBMS_ROWID package to extract the ROWID components of
bigfile tablespaces.
❑ You must use a new parameter called TS_TYPE_IN in the DBMS_ROWID
procedures. The new parameter will help you determine the tablespace type.
❑ The encoded block number in the ROWIDs can be much larger for bigfile
tablespaces.

❑ Sorted hash clusters enable the retrieval of sorted data faster than using an
ORDER BY clause.
❑ A hash cluster groups data according to a hash function it applies to the
cluster key value of each row.
❑ The table rows are organized as lists of sorted rows, with each row corresponding
to a separate value of the hash column.
❑ You would still need to use an ORDER BY clause on a suffix of the sort key
columns.
Two-Minute Drill 39
❑ Before you can create the tables that are part of a cluster, you must create the
cluster itself.
❑ If you want to retrieve data in ascending order, the ORDER BY clause isn’t
mandatory.
❑ Oracle recommends inserting hash cluster table data in the sort key column
order.

❑ You can use the DBMS_FILE_TRANSFER package to transfer files between
two databases or two different servers.
❑ Both the source and destination files should be of the same type.
❑ Use the COPY_FILE procedure to copy files on a local system.
❑ Use the PUT_FILE and GET_FILE procedures to perform file transfers
to and from a database on a remote file system.
❑ You can use the Scheduler facility to schedule file-transfer operations.
SELF TEST
chapter. Read all the choices carefully, because there might be more than one correct answer. Choose

1. For which two types of tablespaces can you set proactive tablespace alerts?
A. Locally managed
B. Dictionary-managed
C. Read-only
D. Online
2. Which of the following is true about alerts?
A. You’ll get a maximum of one undo alert per every 12-hour period.
B. You’ll get a maximum of one undo alert during a 24-hour period.
C. You’ll get a maximum of one tablespace alert during a 124-hour period.
D. You’ll get a maximum of one tablespace alert during a 24-hour period.
3. Which one of the following is responsible for sending out tablespace alerts?
A. DBMS_SERVER_ALERT package
B. MMON background process
C. Database Control
D. Scheduler

4. Which of the following segments cannot be shrunk?
A. Heap-organized table segments
B. Index-organized table segments
C. Index segments
D. Undo segments
5. The DBA issues the following command:
SQL> alter table test SHRINK SPACE
Which of the following would be the result of this statement?
Self Test 41
A. There would be immediate release of the free space.

B. There would be only a compacting of the data, not a release of data.
C. There would be no impact on DML operations in the database.
D. There would be an impact on the DML operations in the database.
6. What is the first step before you start shrinking a segment?
A. Make sure there are indexes on all the table segments.
B. Enable row movement for any segment you want to shrink.
C. Disable row movement for any segment you want to shrink.
D. Issue the ALTER TABLE … COMPACT command.

7. What does the Undo Advisor help you do?
A. Set the undo retention period
B. Set the undo interval
C. Set the size of the undo tablespace
D. Figure out the number of undo segments you must create
8. What does the initialization parameter FAST_START_MTTR_TARGET determine?
A. The instance recovery time
B. The database restore time
C. The number of redo log groups
D. The undo retention period
9. Which of the following is true of optimally sized redo log files?
A. They should perform very frequent checkpointing.
B. They should perform very infrequent checkpointing.
C. The amount of checkpointing isn’t related to the size of the redo log file.
D. They should perform just the right amount of checkpointing as that required by your MTTR.
10. If you don’t explicitly specify the SYSAUX tablespace during database creation, what happens?
A. The database creation will fail.
B. Oracle will create a default SYSAUX tablespace.
C. Oracle will create a default SYSTEM tablespace.

D. Oracle will let you create a SYSAUX tablespace later on.
11. Which one of the following is true when you rename a default permanent tablespace for a user?
A. You’ll need to create a new default tablespace for the user before you can do anything.
B. The tablespace will continue to be the default tablespace after you rename it.
C. You must first remove all the current users from the tablespace.
D. You can’t rename a default permanent tablespace.
12. Which of the following statements is true when you are considering dropping the current
default permanent tablespace for the database?
A. You’ll first need to first reassign another tablespace as the new default (permanent)
tablespace for the database.
B. The original tablespace will continue to be the default tablespace.
C. You must first remove all the current users from the tablespace.
D. You can’t drop a default permanent tablespace.
13. Which one of the following is true regarding tablespace types?
A. If you create a database with bigfile set as the default tablespace type, you can’t convert
later to smallfile tablespaces.
B. If you create a database with smallfile set as the default tablespace type, you can’t convert
later to bigfile tablespaces.
C. It doesn’t matter what default type of tablespace you create a database with; you can change
the default tablespace type anytime you wish.
D. You can’t switch the tablespace type once you create a database.
14. To avoid a large number of extents for bigfile tablespaces in very large databases, which of the
following does Oracle recommend that you do?
A. Use the UNIFORM clause for allocating new extents and set a very high extent size.
B. Use the AUTOALLOCATE clause and simply let Oracle take care of the extent sizing.
C. Use the AUTOALLOCATE clause for allocating new extents and set a very high extent size.
D. Use the UNIFORM clause and simply let Oracle take care of the extent sizing.

15. Which of the following is true regarding creating tables for a sorted hash cluster?
A. You must first create the hash cluster before you create the member tables.
B. You must create the member tables before you create the cluster.
Lab Questions 43
C. You create the tables and the cluster together, in the same SQL statement.
D. Once you create the clusters, the tables that are part of the cluster are created automatically
by Oracle.
16. What happens if you use an ORDER BY clause on a suffix of the sort key columns?
A. You won’t need to perform any sorting if you use an ORDER BY clause.
B. You’ll need to perform additional sorting when you use an ORDER BY clause.
C. You’ll perform the same amount of sorting as when there is no suffix on the sort key
columns.
D. You cannot use an ORDER BY clause on a suffix of the sort key column.

17. Which one of the following statements is true when you use the DBMS_FILE_TRANSFER
package to transport files?
A. If the source file is a UNIX file, the destination file can be an ASM file.
B. If the destination file is a UNIX file, the source file can be a UNIX file.
C. If the destination file is a UNIX file, the source file can be an ASM file.
D. If the source file is an ASM file, the destination file can be an ASM file.
18. If you want to transfer a file using the DBMS_FILE_TRANSFER package, what do you
need to do?
A. You must use the COPY_FILE procedure to copy files to a different server.
B. You must use the COPY_FILE procedure to copy files to a local database.
C. You must use the PUT_FILE procedure to copy files to a different server.
D. You must use the GET_FILE procedure to copy files to a different server.
LAB QUESTIONS
1. On the USERS tablespace, set a warning threshold of 80 percent and a critical threshold of 95
percent.
2. How do you check the database-wide threshold values for the USERS tablespace?
3. How do you turn off the space-usage tracking for the USER tablespace?
4. How do you reset the database-wide threshold values of the USERS tablespace to the default
database values?
5. How do you check the status of your threshold?
SELF TEST ANSWERS

1. þ A and D. A is correct because you can provide alerts only in locally managed tablespaces.
D is correct, since you can’t provide alerts in an offline tablespace.
ý B is wrong since dictionary-managed tablespaces aren’t eligible for proactive tablespace
alerts. C is a wrong answer because you can’t provide alerts for read-only tablespaces.
2. þ B. You will get a maximum of one undo tablespace alert during a 24-hour period.
ý A, C, and D provide wrong time intervals.
3. þ B. The MMON background process monitors the tablespace thresholds and is responsible
for sending proactive alerts.
ý A, C, and D don’t send out any alerts.

4. þ D. You cannot shrink undo segments belonging to the undo tablespace.
ý A, B, and D are wrong answers since they all point to eligible candidates for segment
shrinking.
5. þ D. The release of the space would have an impact on DML operations.
ý A, B, and C are wrong since the command would compact the data first and then release
it, meanwhile impacting the DML operations going on in the database.
6. þ B. You must ensure that row movement is enabled, since the shrinking process could alter
some ROWIDs in a heap-organized table.
ý A, C, and D point out the wrong requirement.

7. þ A and C. The Undo Advisor helps you set the undo retention period, as well as the size of
the undo tablespace.
ý B is wrong since there is no such thing as an undo interval. D is wrong because when you
use Automatic Undo Management, you don’t create the undo segments—Oracle does this.
8. þ A. The FAST_START_MTTR_TARGET initialization parameter sets the mean time to
recovery (MTTR) following an instance crash.
ý B, C, and D are wrong since the FST_START_MTTR_TARGET deals with instance
recovery rather than database restore, number of redo log groups, or undo management.
9. þ D. Optimally sized redo log files should be the smallest consistent with keeping the
checkpointing to a minimum amount.
ý A, B, and C aren’t logically correct answers, since they ignore the MTTR target.
10. þ B. Oracle will create the SYSAUX tablespace in a default location, even if you fail to
specify it. The same is true of the SYSTEM tablespace.
ý A is wrong since database creation will succeed even when you don’t specify a SYSTEM
or SYSAUX tablespace. If you issue the CREATE DATABASE statement with no other clauses,
Oracle will create a database with datafiles for the SYSTEM and SYSAUX tablespaces in system-
determined default locations. C is wrong since Oracle doesn’t create a SYSTEM tablespace in
lieu of the SYSAUX tablespace. D is wrong since you can’t create the SYSAUX tablespace
after database creation—the SYSAUX tablespace is always created at database creation.
11. þ B. When you rename a default permanent tablespace, nothing really changes—the old
default permanent tablespace continues to be the default permanent tablespace, with a new
name.
ý A is wrong since you don’t need to create a new default permanent tablespace for the
users. C is wrong since the users continue to be assigned to the same permanent tablespace
throughout. D is wrong since you can rename a permanent tablespace.
12. þ A. You must ensure that there is always a default tablespace for all the users in the database,
before you can drop an old one.
ý B is wrong since the original default permanent tablespace will be replaced by the new
default permanent tablespace. C is wrong since you don’t remove any users from the tablespace.
D is wrong since you can drop a default permanent tablespace after making sure you have an
alternative default permanent tablespace for all the users.
13. þ C. It doesn’t matter what type of tablespace you create the database with. You can always
change back and forth between the two types of tablespaces: smallfile and bigfile.
ý A, B, and D are wrong, since they contradict C.
14. þ A. Oracle recommends that you set the extent size yourself, by using the UNIFORM clause
and selecting a very large extent size.
ý B is wrong because you use the AUTOALLOCATE for normal sized, not very large databases.
C is wrong for the same reason as B. Besides, you can’t choose extent sizes when you use
AUTOALLOCATE. D specifies the correct option, UNIFORM, but turns out to be the wrong
answer, since it states that you should let Oracle choose the extent sizes.

15. þ A. The hash cluster must exist before you can create any member tables.
ý B is wrong because you must first create the cluster and then the tables that are part of
the cluster. C is wrong since you need to create the hash cluster first. D is wrong since Oracle
doesn’t automatically create the tables that are part of a cluster.
16. þ B. If you use an ORDER BY clause on a suffix of the sort key columns or nonsort key
columns, additional sorting is required, assuming there are no indexes on the table.
ý A is wrong since you’ll need to perform sorting even with the ORDER BY clause. C is
wrong since you’ll perform more sorting than before. D is wrong since you can use an ORDER
BY clause on a suffix of the sort key column.

17. þ B and D. The source and destination files must be of the same type—UNIX or ASM.
ý A and C are wrong, since the file systems don’t match in both cases.
18. þ B and C. B is correct because the COPY_FILE procedure is meant for local file copies.
C is correct because you must use the PUT_FILE procedure to transfer files to a remote
database server.
ý A is wrong because you can only make copies from a local server with the COPY_FILE
procedure. D is wrong since the GET_FILE procedure helps you bring files from a remote
server to your local server, not the other way around, as the answer indicates.
LAB ANSWERS
1. On the USERS tablespace, use the following to set a warning threshold of 80 percent and
a critical threshold of 95 percent:
SQL> begin
dbms_server_alert.set_threshold (
dbms_server_alert.tablespace_pct_full,
dbms_server_alert.operator_ge, 80,
dbms_server_alert.operator_ge, 95, 1, 1, NULL,
dbms_server_alert.object_type_tablespace, 'USERS');
end;
You can use the NULL value to return to the database-wide default values.
Lab Answers 47
2. Check the database-wide threshold values for the USERS tablespace as follows:
SQL> select warning_value, critical_value
from dba_thresholds
whre metrics_name = 'Tablespace Space Usage' AND
object_name = 'USERS'
/
3. Turn off the space-usage tracking for the USER tablespace as follows:
SQL> begin
dbms_server_alert.operator_do_not_check, '0',
dbms_server_alert.operator_do_not_check, '0', 1, 1, NULL,
end;
4. Reset the database-wide threshold values of the USERS tablespace to the default database
values as follows:
SQL> begin
NULL, NULL, NULL, NULL, 1, 1, NULL,
end;
5. Check the status of your threshold as follows:

SQL> select reason, resolution
from dba_alert_history
where object_name = 'USERS';
SQL> select reason, message_level
from dba_outstanding_alerts
where object_name = 'USERS';
Blind Folio 7:1
7
The Oracle
Scheduler and
the Database
Resource Manager
7.01 Simplifying Management Tasks Using 7.04 Viewing Information About the Scheduler
the Scheduler
7.05 Database Resource Manager
7.02 Managing the Basic Scheduler Enhancements
Components
7.03 Managing Advanced Scheduler
Components
Q&A Self Test
2 Chapter 7: The Oracle Scheduler and the Database Resource Manager
O racle DBAs and developers frequently use the DBMS_JOB package to schedule
database jobs. The package is a commonly used scheduling utility that has been
around for a number of years. However, Oracle databases suffered from not having
a real scheduling facility, especially when compared to the Microsoft SQL Server database.
Oracle Database 10g provides you with the terrific new scheduling feature, aptly named the
Scheduler. In this chapter, you’ll learn first about the Scheduler framework and then how to
manage this brand-new Oracle 10g feature.
In the latter part of this chapter, you’ll learn about the Oracle Database 10g
enhancements to the Database Resource Manager. These include using the Resource
Manager to impose idle session limits, returning sessions automatically to their initial
consumer groups after their top call is over, creating mapping between sessions and
resource consumer groups, and using new methods of CPU allocation among resource
plans and resource groups.
Let’s start with an introduction to the new Scheduler and see how you can simplify
management tasks by using it.
Simplifying Management Tasks

Using the Scheduler
The set of functions and procedures in the DBMS_SCHEDULER package form the
backbone of the new Scheduler facility. The Scheduler helps you schedule jobs within
the database or in the server that hosts the database. Using the Scheduler vastly simplifies a
database administrator’s tasks relating to the running of regular database jobs. The most
important architectural feature of the Scheduler is its modular approach to managing
tasks: it breaks down each task into location, time, and database object, thus simplifying
management. The modular approach helps different users to reuse similar jobs, with
minor modifications. The Scheduler works closely with the Database Resource Manager
and utilizes the resource consumer group and resource plan concepts not only to schedule
jobs according to a timetable, but also to allocate scarce server resources according to
organizational needs and priorities. This focus on resource allocation marks the Scheduler
as a much more sophisticated and powerful scheduling tool than the DBMS_JOBS
package.
Simplifying Management Tasks Using the Scheduler 3
A severe limitation of the DBMS_JOBS package is that it can only schedule

PL/SQL-based jobs. You can’t use it to schedule operating system scripts or an
executable. To run these non-database-type jobs, you must use a scheduling feature
like crontab in UNIX or the AT facility in Windows servers. You may even have
to use a third-party tool to get the job done. The Oracle Database 10g Scheduler
feature offers you the capability to perform not only PL/SQL jobs, but also operating
system shell scripts, Java programs, and native binary executables.
Basic Scheduler Components

The Scheduler consists of three basic components—jobs, programs, and schedules.
You are familiar with the concept of an Oracle job from using the DBMS_JOB package
in the previous versions. However, the other two components, programs and schedules,
are new in the Scheduler. The concepts of a program and a schedule lead to a modular
approach to the management of tasks. For example, several users can perform similar
tasks, with minor changes in the time and resource usage, by simply using similar schedules
and programs.
Let’s look at the three main components of the Scheduler in the following sections.
Jobs
A job is a task that you schedule to run one or more times. A job contains information
about what it should execute and time of execution. A Scheduler job can execute a
PL/SQL block of code, a native binary executable, a Java application, or a shell script.
You can create a new job by either specifying all the details, such as the code the job
should execute and the time and frequency of the execution, or you can simply use
saved programs and schedules, to facilitate the creation of a job.
When you create a new job, Oracle adds an entry to the job table. There is one
job table for each database. When you execute a job, the database makes an entry in
the job log.
Schedules
A schedule is a specification of when and how frequently the database should execute a
job. The important thing to note here is that you can use the same schedule for several
jobs. Schedules are like any other database entities, and you store them just as you do
the other objects. Users can share schedules.
The schedule and program components of the Scheduler are purely optional.
Programs
A program contains information about the code, script, or executable that’s to be
executed as part of a job. The information contains a program name, the program
action (PL/SQL code or a UNIX shell script, for example), and other similar items.
As with schedules, several jobs can share the same program.
You can combine the three main components of the Scheduler—jobs, schedules,
and programs, to create and run scheduled jobs in your database, as you’ll see in later
sections of this chapter.
Advanced Scheduler Components

In addition to jobs, schedules, and programs, the Scheduler also uses several advanced
concepts: job classes, windows, and resource groups. These advanced features set apart
the Scheduler from its predecessor, the DBMS_JOBS package, in the matter of scheduling
database jobs. These advanced concepts enable the prioritizing of jobs in the database
and the allocation of resources in accordance with your priorities. Let’s look at these
components in the following sections.
Job Classes
A job class groups similar jobs into one large entity. The jobs that are part of a job class
share common characteristics like resource requirements. By helping you to classify
several jobs into related groups on the lines of functionality or shared attributes, job
classes facilitate the calibration of limited resources among different groups of jobs in
your database.
Job classes group jobs with common characteristics. The main purpose of
using a job class is to manage resource allocation among jobs. A job can
belong to only one job class.
After grouping jobs into classes on the functionality (marketing, administration,

finance, and so on), you can use the concept of a job class to do the following:
■ Assign the job priority level for an individual job, with the priority values ranging
from 1 to 5. A higher-priority job always starts before a lower-priority job.
■ Specify common attributes such as the frequency of log purging.
Windows
A window represents an interval of time during which you can schedule jobs. The purpose
behind using a window is to change resource allocation during a time period. For example,
a “maintenance window” may last from Friday night to Sunday evening. Each window
is associated with a specific resource plan (created with the help of the Database Resource
Manager). By using a window in which to schedule a job, you ensure that the job will
only run during a certain time interval, when a certain resource plan associated with
that window is active. The concept of resource plan–based windows enables you to
ensure optimal use of your scarce resources.
Windows can overlap, and when they do, Oracle chooses the window with
the higher priority. The window with the higher priority opens, and the other
window will close.
Window Groups
Window groups are simply a collection of similar windows. Once you create a window
group, you can then specify that a job will run during a window group. For example,
you can create a window for your weekends and a window for your holidays. You can
then group both these windows into a single maintenance window, if you wish. The
key idea here is that a window group comprises windows with similar characteristics.
You have the choice of specifying a window or window group as the schedule for a job.
Resource Allocation Among Jobs

The Scheduler and the Database Resource Manager are tightly integrated in Oracle
Database 10g, thus making it easy to prioritize your jobs and assign the right level
of resources to jobs. You can use the Resource Manager feature to control resource
allocation in your database. The important thing to note here is that the Scheduler
doesn’t allocate resources at the individual job level—it does so at the job class level.
Oracle assigns each job class to a specific resource consumer group. If you don’t specify
a resource consumer group for any job class, that job class will by default be assigned to
the default consumer group.
The resource consumer group that a job class belongs to will determine the
allocation of resources to that job class. Thus, you can use the Database Resource
Manager to prioritize Scheduler jobs.
Scheduler Architecture
The Scheduler architecture consists primarily of the job table, job coordinator, and the
job workers (or slaves). Let’s look at each of these components in the following sections.
The Job Table

The job table contains information about the jobs, such as the job name, program
name, and job owner. You can examine the job table by using the DBA_SCHEDULER_
JOBS view.
The Job Coordinator

When you create a new job or execute a job, a background process (cjqNNN)
automatically wakes up and starts coordinating the running of the job. The Scheduler
sleeps when there aren’t any jobs to execute. The job coordinator regularly looks in the
job table to find out what jobs to execute. The job coordinator creates and manages
the job worker processes that execute the job.
The Job Workers

When the job coordinator instructs a job worker to execute a job, the worker process
starts a database session and starts a transaction. It then starts executing the job, and
once the job completes, it commits and ends the transaction and terminates the
database session.
It is the job of the job workers to
■ Update the job table, to indicate that the job has been completed
■ Update the job log table
■ Update the run count
Scheduler Privileges
Jobs, schedules, and programs are like any other database object when it comes to
ownership and privileges. Oracle creates all jobs, programs, and schedules in the current
user’s schema. However, Oracle creates all the advanced Scheduler components, like
job classes, windows, and window groups, at the database level, not the schema level,
and their owner is the SYS schema.
The MANAGE SCHEDULER system privilege lets you do the following:
■ Create, drop, and alter job classes, windows, and window groups. (You still
can’t create a job in a job class you create, unless you have a separate EXECUTE
privilege on that job class.)
■ Stop any job.
■ Start and stop windows prematurely.
By default, all Scheduler objects are in uppercase, unless you wrap the lowercase
names in double quotes, as in “test_job”.
You must have the CREATE JOB privilege to create the basic job, schedule, and
program components. In order to use the advanced Scheduler components like
windows, window groups, and job classes, you need the MANAGE SCHEDULER
system privilege.
Once you create a job or some other Scheduler component, it will be a part of
your own schema. You can assign other users the right to use one of your components
like a job, schedule, or program by giving them EXECUTE privileges on that
component. For example, you can grant the EXECUTE privileges for a certain
program or for a certain job class. Note that
■ The EXECUTE ANY PROGRAM privilege lets a user execute any program
under any schema.
■ The EXECUTE ANY CLASS privilege lets you assign a job to any job class.
In order for a user to modify a Scheduler component, you must grant the user the
following privilege (you use the appropriate component):
SQL> grant alter on <job, program or schedule> to scott;
When you create a job, as you are aware, you can use programs, schedules, job
classes, and windows. Once you have the CREATE JOB privilege, you can start
creating your job, with the following restrictions:
■ To create the job itself, you must have the CREATE JOB privilege.
■ If you specify a program that you happen to own, you don’t need any
privileges to specify the program.
■ If you specify a program owned by a different user, you must have the EXECUTE
privilege on that program, or the EXECUTE ANY PROGRAM system privilege.
■ You can specify a schedule, whether owned by you or a different user, without
any privileges.
■ You don’t need any special privileges to specify a window or windows group.
However, since all of these objects are in the SYS schema, you must fully
qualify these components when you use them in your CREATE JOB or any
other statement.
■ If you wish to assign your new job to a job class, you must either have the
EXECUTE privilege on that class, or the more powerful EXECUTE ANY
CLASS system privilege.
The SCHEDULER_ADMIN role contains all the Scheduler system privileges,

with the WITH ADMIN OPTION clause. The DBA role contains the SCHEDULER_
ADMIN role.
Managing the Basic Scheduler Components

The basic Scheduler components—jobs, programs, and schedules—have several common
manageability features. For example, you follow a similar procedure to create, alter, and
drop all three components. Similarly, you can use the SET_ATTRIBUTES procedure
of the DBMS_SCHEDULER package to change the attributes of all three components.
Let’s start with managing Scheduler jobs in the next section.
All Scheduler objects are of the form [schema].name. All Scheduler names are
in uppercase, unless you surround them with double quotes.
Managing Jobs
Creating and managing jobs, of course, is at the heart of the Scheduler facility. As you’ll
learn, you can create and run jobs independently, or you can create a job using schedules
and programs. Use of saved programs and schedules enables you to eliminate the
redefinition of the program or schedule each time you create a new job. This reusability
of the Scheduler components is a highly useful feature, since users can customize schedules
and programs to meet their needs. Let’s start with the creation of Scheduler jobs.
Managing the Basic Scheduler Components 9
Creating Jobs
You create a job using the CREATE_JOB procedure
of the DBMS_SCHEDULER package. You can
The parameter values you specify all the job execution details directly using
specify when you create a job will override the CREATE_JOB procedure. Programs and
the default values for the saved programs schedules, as you’ve seen earlier, are saved database
and schedules. objects that contain information pertaining to
jobs, like the job type and the start and end times.
Later, you’ll see how to use programs and schedules to make the creation of jobs easy to
manage. Here’s a simple example that shows how to create a basic Scheduler job. Note
that there aren’t any programs or schedules in this job—this is the most straightforward
way to specify a job, with all pertinent information specified in the job creation statement
itself. More sophisticated examples later on show you how to embed most of the repetitive
information within saved schedules and windows.
SQL> begin
2 dbms_scheduler.create_job(
3 job_name => 'test_job1',
4 job_type => 'PLSQL_BLOCK',
5 job_action => 'DELETE FROM persons WHERE sysdate=sysdate-1',
6 start_date => '28-JUNE-04 07.00.00 PM Australia/Sydney',
7 repeat_interval => 'FREQ=DAILY;INTERVAL=2',
8 end_date => '20-NOV-04 07.00.00 PM Australia/Sydney',
9 comments => 'TEST JOB');
10* end;
SQL> PL/SQL procedure successfully completed.
SQL>
Your new job, test_job1, isn’t ready to be used yet, since by default, all new jobs
are disabled when they are created. You need to enable a job in order to use it.
Note how similar the preceding job creation

statement is to using the traditional DBMS_JOB
package to create a new job. Incidentally, you
You’ll be the owner of a can still use the DBMS_JOB package in Oracle
job if you create it in your own schema. Database 10g, since it’s left there for backward-
However, if you create it in another schema, compatibility purposes. Let’s look at the various
that schema user will be owner of the job. components of our CREATE_JOB procedure.
Thus, the fact that you create a job doesn’t
mean that you are necessarily the owner
job_name This parameter provides a way to
of that job.
specify a name for your job.
job_type This parameter tells the Scheduler what type of job—a PL/SQL block,
a stored procedure, a shell script, or a Java program—that the job must execute.
job_action This parameter specifies the exact procedure, command, or script

that the job will execute.
start_date and end_date These parameters specify the date that a new job
should start and end. (Many jobs may not have an end_date parameter, since
they are ongoing jobs.)
repeat_interval This attribute tells the Scheduler how often it should execute
the job. In our example, the repeat interval is 'FREQ=DAILY;INTERVAL=2',
which means that you run the job every other day. You can specify a repeat interval
in one of two ways:
■ Use a PL/SQL date/time expression.

■ Use a database calendaring expression.
If you omit the repeat_interval attribute, a job will run only once.
Note that a big feature of the Scheduler tool is its ability to run operating system
scripts and executables in addition to PL/SQL code. Here’s an example that shows
how you can schedule a job on your server. The job runs the check_freespace.ksh
UNIX script every half an hour.
begin
dbms_scheduler.create_job(
job_name => 'CHECK_FREE_SPC',
job_type => 'EXECUTABLE',
job_action => '/u01/app/oracle/admin/dba/scripts/check_freespace.sh',
repeat_interval => 'FREQ=MINUTELY; INTERVAL=30',
enabled => true,
comments => 'Check free space in tablespaces');
end;
/
The script will run every 30 minutes ('FREQ=MINUTELY; INTERVAL=30'),

and the job_type parameter shows that it’s an executable program. The job_
action parameter tells the Scheduler which OS script to execute.
Let’s briefly look at how you can set your repeat interval using calendaring expressions
and PL/SQL date/time expressions.
■ Using a calendaring expression Calendaring expressions generate the next

date of execution for a job. A calendaring expression is a straightforward,
English-like expression consisting of the following three components:
■ Frequency A mandatory component of a calendaring expression,
represented by the keyword FREQ. Possible values are YEARLY, MONTHLY,
WEEKLY, DAILY, HOURLY, MINUTELY, and SECONDLY.
■ Repeat interval Refers to how often the database must repeat the job.
The keyword INTERVAL shows the repeat interval.
■ Specifiers Provides detailed information about when a job should
be run. Possible values are BYMONTH, BYWEEKNO, BYYEARDAY,
BYMONTHDAY, BYDAY, BYHOUR, BYMINUTE, and BYSECOND.
Of these three components, specifiers are optional, but the repeat interval
and frequency are mandatory. You’ll need specifiers only when you need to
specify complex repeat intervals. Here are some examples of using the three
components to provide values for the repeat_interval attribute of the
CREATE_JOB procedure:
FREQ=DAILY; INTERVAL=10 executes a job every 10 days
FREQ=HOURLY; INTERVAL=2 executes a job every other hour
FREQ=WEEKLY; BYDAY=FRI executes a job every Friday.
FREQ=WEEKLY; INTERVAL=2; BYDAY=FRI executes a job every other Friday.
FREQ=MONTHLY; BYMONTHDAY=1 executes a job on the last day of the month
FREQ=YEARLY; BYMONTH=DEC; BYMONTHDAY=31 executes a job on the 31st of December.
FREQ=MONTHLY; BYDAY=2FRI executes a job every second Friday of the month
In the preceding set of examples, the BY* clause is the optional specifier
component, which provides additional information that the frequent and
repeat interval components can’t provide.
■ Using a PL/SQL expression You can also create more complex repeat
intervals than what the calendaring expressions enable you to do by using
PL/SQL expressions, with the proviso that all such expressions must evaluate
to a date or a timestamp datatype. When you use a date/time expression for
specifying the repeat interval, you end up with a date/time datatype as the
value of the interval. Look at the following example:
repeat_interval => 'SYSTIMESTAMP + INTERVAL '10' MINUTE'
The repeat_interval specification in the preceding example shows the

use of a PL/SQL expression. The expression states that Oracle will execute
the job every ten minutes. Each time a job executes, Oracle evaluates the
repeat_interval clause to compute the next scheduled execution time
of the job—in this case, ten minutes into the future.
Administering Jobs
You can use the DBMS_SCHEDULER package to perform all the administrative tasks
associated with jobs. Let’s look at some of the main job-related administrative tasks in
the following sections.
Enabling and Disabling Jobs All jobs are disabled by default when you create
them. You must explicitly enable them in order to activate and schedule them. You
can enable a job by issuing the following command:
SQL> exec dbms_scheduler.enable ('TEST_JOB1');
You can disable a job by issuing the following command:

SQL> exec dbms_scheduler.disable ('TEST_JOB1');
Dropping a Job You can drop a job by using the DROP_JOB procedure,
as shown here:
begin
dbms_scheduler.drop_job (
job_name => 'test_job1');
end;
/
Running and Stopping a Job You can run a job manually (at other than the
regularly scheduled times) by using the RUN_JOB procedure, as shown here:
SQL> exec dbms_scheduler.run_job('TEST_JOB1');
You may want to run a job manually to test it before scheduling on a regular basis,
or to correct some errors in a job that already ran. When you run a job manually, it
runs in your own session, and the job coordinator and the job slave don’t enter the
picture.
You can stop a job immediately by using the STOP_JOB procedure, as shown here:
SQL> exec dbms_scheduler.stop_job('TEST_JOB1');
In both the STOP_JOB and currently running. By setting FORCE=TRUE,

RUN_JOB procedures, there is a FORCE you can stop or drop a job immediately by
argument, which is set to false by default. using the appropriate procedure. You must
The FORCE attribute determines whether have the MANAGE SCHEDULER system
the job can be stopped or dropped if it is privilege to use the FORCE setting.
EXERCISE 7-1
Creating a Job to Perform an Online Backup

Create a simple job, which will execute a script at a scheduled time. Here’s a sample
job creation code:
begin
dbms_scheduler.create_job (
job_name => 'EXECUTABLE',
job_action =>
'/U01/APP/ORACLE/DBA/SCRIPT/PROD1_ONLINE_BKP.sh',
start_date => '05-JUL-04 11.00.00 PM',
repeat_interval => 'FREQ=DAILY;INTERVAL=2', /* every other day */
comments => Alternate day online backup');
end;
/
Managing Programs
A program contains metadata, including the name and type of the program, and what
a job will execute, whether it is a PL/SQL procedure, a script, or an executable. When
you use programs, you can alter the job task, or what the job will actually do, without
directly modifying the job definition itself. Programs enable you to control the run-
time behavior of the job task. Different jobs can pick the same program from a library
of programs, thus helping you avoid having to specify all the details of a program in
your job creation statement.
Let’s start by looking at how you can create programs. Later you’ll learn about
program-related administrative tasks.
Creating a Program
To create a new Scheduler program, use the CREATE_PROGRAM procedure of the
DBMS_SCHEDULER package, as shown here:
SQL> begin
2 dbms_scheduler.create_program(
3 program_name => 'TEST_PROGRAM',
4 program_action => 'SCOTT.UPDATE_SCHEMA_STATS',
5 program_type => 'STORED_PROCEDURE',
6 enabled => TRUE);
7* end;
SQL> /
SQL>
By default, Oracle creates a program in the creator’s schema. If you want to

create the program in a different user’s schema, you must qualify the program
name with the schema name.
The program component has all the job details. Once you create a program in the
manner shown here, you can simplify your job creation statement for the job TEST_
JOB1 by replacing the job_type and job_action attributes with the name
of the program (TEST_PROGRAM) that already contains the specification of these
attributes. The program_type and program_action will provide the information
that the three job attributes provided in your first job creation statement. You can
begin to see why this type of a modular approach is beneficial—different jobs can
use the same program, thus simplifying the specification and creation of jobs.
Let’s re-create our TEST_JOB1 job, using the program component this time.
Here’s the much simpler job creation statement:
SQL> begin
3 job_name => 'TEST_JOB1',
5 repeat_interval=> 'FREQ=DAILY;BYHOUR=12',
6 ENABLED => TRUE;
ENABLED => TRUE);
7* end;
SQL> /
SQL>
In the preceding example, the use of a program (TEST_PROGRAM) lets you avoid
specifying the job_type and job_action parameters in the CREATE_JOB
statement. You thus have a choice between specifying all job attributes directly in
the CREATE_JOB statement itself, or using a stored program to supply some of the
job attributes.
Administering Programs
You can enable, disable, drop, and modify Scheduler programs using various procedures
from the DBMS_SCHEDULER package.
Enabling and Disabling Programs You can enable a program in the following
manner, using the ENABLE procedure:
SQL> exec dbms_scheduler.enable('TEST_PROGRAM');
You can disable a program in the following manner, using the DISABLE procedure:
SQL> exec dbms_scheduler.disable('TEST_PROGRAM');
Dropping a Program You can drop a saved program by using the DROP_
PROGRAM procedure, as shown here:
SQL> exec dbms_scheduler.drop_program('TEST_PROGRAM');
SQL>
Managing Schedules
Let’s say you have a number of jobs, all of which use similar execution time schedules.
In cases like this, the Scheduler makes it easy for you to use a common schedule. If you
need to modify some aspect of the schedule, all the jobs that use the schedule can
automatically inherit those changes. Let’s start by looking at how you create a schedule.
Creating a Schedule
You use the CREATE_SCHEDULE procedure of the DBMS_SCHEDULER package to
create a schedule, as shown here:
SQL> begin
2 dbms_scheduler.create_schedule(
3 schedule_name => 'TEST_SCHEDULE',
4 start_date => SYSTIMESTAMP,
5 end_date => SYSTIMESTAMP + 30,

6 repeat_interval => 'FREQ=HOURLY;INTERVAL= 12',
7 comments => 'Every 12 hours');
8* end;
SQL> /
PL/SQL procedure successfully completed
SQL>
The TEST_SCHEDULE schedule states that a job with this schedule will be
executed immediately and then be reexecuted every 12 hours, for a period of 30
days. Note the following things about the creation of the TEST_SCHEDULE
schedule:
■ The CREATE_SCHEDULE procedure has three important parameters

(there is also an optional comment parameter).
■ The start and end times are always precise to a second.
■ You specify the start and end times using the TIMESTAMP WITH TIME
ZONE datatype. The Scheduler also supports all NLS_TIMESTAMP_TZ_
FORMAT settings.
■ You must use a calendering expression to create the repeat interval.
Once you create the schedule TEST_SCHEDULE, you can simplify the job creation
process even further. Now you can use both TEST_PROGRAM and TEST_SCHEDULE
to simplify job creation, as shown here:
SQL> begin
3 job_name => 'TEST_JOB02',
5 schedule_name => 'TEST_SCHEDULE');
6 end;
7 /
SQL>
As you can see, TEST_JOB02 is really easy to create, since you are using both
a saved program as well as a saved schedule. The use of the saved schedule means
that you don’t have to specify the start_date, end_date, and the repeat_
interval attributes while creating TEST_JOB02, since TEST_SCHEDULE
already has all that information.
Administering Schedules
A schedule states when and how often a job should be run. You can save a schedule
as a database object and share it with other users. Let’s look at some of the basic
administrative tasks concerning schedules.
Creating a Schedule You create a schedule using the CREATE_SCHEDULE

procedure. You can create a schedule in your own or some other schema. You’ve
learned how to use the CREATE_SCHEDULE procedure in the previous section.
The most important attributes of a schedule
are the start and end dates and the frequency
of execution, which is set by the repeat_
When you create a interval attribute. You can alter the
schedule, Oracle provides access to various attributes of a schedule by using the
PUBLIC. Thus, all users can use your SET_ATTRIBUTE procedure of the DBMS_
schedule, without any explicit grant SCHEDULER package. You may alter all
of privileges to do so. attributes except schedule_name.
EXERCISE 7-2
Creating a Schedule
Create a simple schedule on the lines of the following example. In the example, the
repeat_interval attribute specifies that a job will execute every five minutes.
SQL> begin
dbms_scheduler.create_schedule (
scheduler_name => 'TEST_SCHEDULE',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=MINUTELY;INTERVAL=5',
comments => 'A test schedule.');
end;
/
Dropping a Schedule You can drop a schedule with the DROP_SCHEDULE

procedure, but there are some interesting things to note in this regard. For example,
if you have any jobs or windows that use the schedule you want to drop, your
procedure will fail, as shown here:
SQL> begin
2 dbms_scheduler.drop_schedule(schedule_name => 'TEST_SCHEDULE');
3 end;
4 /
begin
ERROR at line 1:
ORA-27479: Cannot drop "SAM.TEST_SCHEDULE" because other objects depend on it
ORA-06512: at "SYS.DBMS_ISCHED", line 615
ORA-06512: at "SYS.DBMS_SCHEDULER", line 1070
ORA-06512: at line 2
SQL>
In our example, TEST_JOB03 uses the schedule TEST_SCHEDULE, and therefore,

your attempt to drop the schedule results in an error. You can override this default
behavior by using the FORCE attribute and setting it to true, as shown here:
SQL> begin
2 dbms_scheduler.drop_schedule(schedule_name => 'TEST_SCHEDULE',
3 force => TRUE);
4 end;
5 /
SQL>
When you drop a schedule by using the FORCE=TRUE attribute, you’ll drop the
schedule, even if there are jobs and windows that use the schedule. The Scheduler
first disables the dependent jobs/windows before dropping the schedule itself.
Managing Advanced Scheduler Components

In the previous section, you learned how to manage the basic Scheduler components—
jobs, programs, and schedules. In this section, let’s look at how to manage the advanced
Scheduler components—job classes and windows (and window groups). You’ll also
learn how the Scheduler makes good use of the Database Resource Manager features,
such as resource consumer groups and resource plans, to efficiently allocate scarce OS
and database resources. Too often, heavy batch jobs run past their window of opportunity
Managing Advanced Scheduler Components 19
and spill over into the daytime, when OLTP transactions demand the lion’s share of
the resources. Prioritizing jobs to ensure that they are guaranteed adequate resources to
perform along accepted lines is an essential requirement in production databases. The
Scheduler uses the concepts of job classes and windows to prioritize jobs.
Job Classes
You can create and schedule a job all by itself, or you can manage it as part of a job class.
Although both types of jobs will perform the same actions, you can’t really allocate
resources when you run a job as an entity by itself. Job classes group all jobs with similar
characteristics and common resource requirements together. Using job classes helps
you prioritize jobs by allocating resources differently among the various jobs.
The Scheduler associates each job class with a resource consumer group, which lets
the Scheduler group jobs according to common resource requirements. Depending
on the resource consumer group a job class belongs to, the Scheduler will determine
the appropriate resource allocation. This ability to associate job classes with resource
consumer groups provides an efficient way to prioritize jobs in the database.
You use the CREATE_JOB_CLASS procedure of the DBMS_SCHEDULER to create
a job class. Unlike a job, a job class can’t be created in a user’s schema—no matter
who creates it, all job classes are created in the SYS schema. You can create a job
class only if you have the MANAGE SCHEDULER privilege.
All jobs must belong to default resource consumer group, the

a job class. There is a default job class, DEFAULT_CONSUMER_GROUP, to which
DEFAULT_JOB_CLASS, to which all jobs a job class will map if you don’t expressly
will belong if you don’t explicitly assign assign that job class to a user-created
them to a job class. Similarly, there is a resource consumer group.
Creating a Job Class

You create a job class by using the CREATE_JOB_CLASS procedure of the DBMS_
SCHEDULER package, as shown here:
begin
dbms_scheduler.create_job_class (
job_class_name => 'admin_jobs',
resource_consumer_group => 'admin_group',

logging_level => dbms_scheduler.logging_off
logging_history => 30);
);
end;
Let’s look at the parameters of the CREATE_JOB_CLASS procedure in the

preceding example:
■ Job_class_name is the name of the job class.

■ Resource_consumer_group tells us that all the jobs that are members of
our new class will have the admin_group as their resource consumer group.
■ The logging_level parameter, which is set to LOGGING_OFF, can take
the following three values:
■ Logging_off There is no logging of any kind for the jobs.
■ Logging_runs For each run of a job in the job class, there will be
a detailed entry in the job log.
■ Logging_full For each run of a job in the job class, there will be
a detailed entry in the job log. In addition, the Scheduler logs all operations
performed on the other jobs in the job class. These operations include the
creation, dropping, altering, enabling, or disabling of the other jobs.
The default logging level is to log all job runs (LOGGING_RUNS option).
The LOGGING_FULL option gives you the most information about jobs.
■ Logging_history specifies the number of days (30 in this case) that the
database will retain the logs before purging them. Oracle will automatically
create a daily job called the PURGE_LOG, which cleans the log entries. The
following query shows that this job exists:
SQL> select job_name
2 from dba_Scheduler_jobs;
JOB_NAME
------------------------------
GATHER_STATS_JOB
PURGE_LOG
…
SQL>
If you want to clear the logs manually, you can do so by using the DBMS_
SCHEDULER.PURGE_LOG procedure.
When you create the ADMIN_JOBS job class, Oracle will automatically store it in
the SYS schema, and the same is true of any other job class that you might create
in the database. Any user in the database can create a job in the ADMIN_JOBS job
class, provided they have the EXECUTE privilege on that specific job class, or they
have the EXECUTE ANY JOB CLASS privilege.
The PURGE_LOG procedure enables you to specify whether you want to

of the DBMS_SCHEDULER package takes purge job or window logs. For example, to
two important parameters—log_history purge all job logs more than seven days old,
and which_log. You use the log_ you use the statement:
history parameter to specify the number exec dbms_scheduler.purge_log(log_history=7,
of days to keep logs before the Scheduler which_log =>'JOB_LOG')
purges them. The which_log parameter
Altering a Job Class

After you create a job class, you can alter all of its attributes except the job_name
attribute. You can use the ALTER_ATTRIBUTES procedure to change a job class’s
attributes, as shown in the following code. You can change the START_DATE, END_
DATE, and other logging-related attributes as well. In the example, the attribute
you are changing is START_DATE. The VALUE clause holds the new value of the
START_DATE attribute.
SQL> begin
2 dbms_scheduler.set_attribute(
3 name => 'ADMIN_JOBS',
4 attribute => 'START_DATE',
5 value => '01-JAN-2005 9:00:00 PM US/Pacific');
6* end;
SQL>
You can’t change any attributes of the default job class, which is named, well,
the DEFAULT_JOB_CLASS.
Dropping a Job Class

You can drop a job class by executing the DROP_JOB_CLASS procedure, as shown here:
begin
dbms_scheduler.drop_job_class('TEST_CLASS');
end;
If you want to drop a job and moved to the default job class in your
class with jobs in it, you must specify the database. If the job is already running when
FORCE=TRUE option in your DROP_JOB_ you drop its job class, the job will run to
CLASS procedure. When you do this, the completion anyway.
jobs in the dropped job class are disabled
Review of the Database Resource Manager

Much of the Scheduler’s power comes from its ability to interact with the Database
Resource Manager to allocate resources among the various scheduled jobs. In order to
fully comprehend this interaction, it pays to quickly review the concepts of the Database
Resource Manager. Let’s take a brief detour to do that in this section.
Using the Database Resource Manager, you can allocate percentages of your server
CPU to contending applications and users. You can also limit operations that you
think are going to run too long, as well as control the degree of parallelism used by
various jobs. You may also terminate long-running sessions and guarantee minimum
processing resources to certain users, regardless of the system load.
You can fully use the resource controlling power of the Database Resource Manager
by creating the basic components and modifying them over time. The four main
components are the resource consumer group, resource plan, resource allocation
method, and resource plan directive.
Resource Consumer Group A group of users or sessions that have identical

processing and resource requirements is known as a resource consumer group. You
can manually assign users to resource consumer groups or let the database assign the
user sessions to specific groups based on the value of various user session attributes.
You may dynamically reassign a session to a different consumer group.
Resource Plan How you allocate resources among the various resource consumer
groups is your resource plan. For example, a resource plan may allocate 50 percent
of the CPU resources to the Finance Group, 30 percent to the Sales Group, and
20 percent to the Administration Group of users.
Resource Allocation Method You can choose the method, or policy, of

allocation of resources among the various resource consumer groups.
Resource Plan Directive You can assign a resource consumer group to a resource
plan, thus deciding what resources each resource consumer group gets. Plan directives
also enable you to specify the parameters for each resource allocation method. For
example, you may limit the degree of parallelism of all users in the Administrative
Group to 2, instead of using the default value, which is an unlimited number of
parallel sessions.
With this brief review of the Database Resource Manager behind us, let’s move on
to see how you can use the concept of a time window to activate different resource
plans at different times.
Working with Scheduler Windows

Although the Scheduler works in tandem with the Database Resource Manager to
allocate resources in an optimal way to all the jobs scheduled for running, you will
want to allocate different amounts of resources at different times. This is where the
concept of the Scheduler window serves as a handy device. Windows enable the
automatic changing of resource plans based on a schedule.
The basic purpose of a window is to switch the active resource plan during a
certain time frame. All jobs that run during this window will be controlled by
the resource plan that’s in effect during that window. Without windows, you’ll
have to manually switch the resource manager plans.
A window is an interval with a specific begin and end time, for example, “from 12
midnight to 6:00 A.M.” However, a window is not merely a chronological device like
a schedule, specifying when a job will run; every window is associated with a resource
plan. When you create a window, you specify a resource plan as a parameter. This
ability to activate different resource plans at different times is what makes a window
a special scheduling device that enables you to set priorities.
A Scheduler window consists of the following

three major attributes:
All windows, like job classes, ■ Schedules, which are the times when the
are created in the SYS schema, no matter window is in effect
which user creates them. To create a ■ Duration, which determines the length
window, you must have the MANAGE of time a window stays open
SCHEDULER system privilege. ■ Resource plan, which determines the resource
priorities among the job classes
Note that schedules and duration are part of all Scheduler schedules; the resource
plan sets a Scheduler window apart from a simple schedule. Each time a window is
open, a specific active resource plan is associated with it. Thus, the same job will be
allocated different resources if it runs under different windows.
You can specify what resources you want to allocate to various job classes during
a certain time period (say midnight to 6:00 A.M.) by associating a resource plan
with the window you create for this period. When the window opens, the database
automatically switches to the associated resource plan, which becomes the active
resource plan. The systemwide resource plan associated with the window will control
the resource allocation for all jobs and sessions that are scheduled to run within this
window.When the window finishes, there will be another switch to the orginal resource
plan that was in effect, provided no other window is in effect at that time.
If a window is open and the Resource Manager is not turned on, the window won’t
be able to switch the resource plans. In this case, the window will continue to open
as scheduled and run the jobs that have been assigned for that window. Thus, the
window in this case serves only as a basic schedule component.
You can see which window is currently active and the resource plan associated with
that window by using the following query:
SQL select window_name, resource_plan from dba_scheduler_windows
where active='TRUE';
WINDOW_NAME RESOURCE_PLAN
------------------------------ --------------------------
TEST_WINDOW TEST_RESOURCEPLAN
SQL>
The V$RESOURCE_PLAN provides information on currently active resource

plans in your database. If you want to view the active resource plan when there
is no window open, you can use the following query:
SQL> select * from v$resource_plan;
Creating a Window
You create a window by using the CREATE_WINDOW procedure. Let’s look at two
examples using this procedure, one with an inline specification of the start and end
times and the repeat interval, and the other where you use a saved schedule instead
to provide these three scheduling attributes. In the first example, the window creation
statement specifies the schedule for the window.
begin
dbms_scheduler.create_window (
window_name => 'TEST_WINDOW',
start_date => '01-JAN-05 12:00:00AM',
repeat_interval => 'FREQ=DAILY',
resource_plan => 'TEST_RESOURCEPLAN',
duration => interval '60' minute,
end_date => '31-DEC-05 12:00:00AM',
window_priority => 'HIGH',
comments => 'Test Window');
end;
/
Let’s look at the individual attributes of a window in TEST_WINDOW:
■ Resource_plan tells us that while this window is open, resource allocation

to all the jobs that run in this window will be guided by the resource plan
directives in the resource plan TEST_RESOURCEPLAN.
■ Window_priority is set to HIGH. The default priority level is LOW.
These are the only two values possible. If two windows overlap, the window
with the high priority level has precedence. Since only one window can be
open at a given time, when they overlap, the high-priority window will open
and the lower-priority window doesn’t open.
■ Start_date indicates that your window first becomes active at 12:00 A.M.
on January 1, 2005. You can also say that the window will open at this time.
■ The duration attribute shows that the window will remain open for a period
of 60 minutes, after which it will close.
■ Repeat_interval tells us the next time the window will open again.
In our case, it is 12:00 A.M. on January 2, 2005.
■ End_date tells us that this window will open for the last time on December
31, 2005, after which it will be disabled and closed.
Since the Scheduler doesn’t check to make sure that there are prior windows
for any given schedule, you have the possibility of overlapping windows. Note
that Oracle doesn’t recommend overlapping windows.
In the second example, shown here, you see how you can create a window using
a saved schedule. Obviously, it is much simpler to create a window this way.
begin
dbms_scheduler.create_window (
window_name => 'TEST_WINDOW',
schedule_name => 'TEST_SCHEDULE',
resource_plan => 'TEST_RESOURCEPLAN',
duration => interval '160' minute,
comments => 'Test Window');
end;
/
In the preceding CREATE_WINDOW procedure, the use of the schedule TEST_

SCHEDULE lets you avoid specifying the start_date, end_date, and repeat_
interval parameters.
A window is automatically enabled upon its creation.
Once you create a window, you must associate it with a job or job class, so the
jobs can take advantage of the automatic switching of the active resource plans.
Managing Windows
You can open, close, alter, enable/disable, or drop a window using the appropriate
procedure of the DBMS_SCHEDULER package. You need the MANAGE SCHEDULER
privilege to perform any of these tasks. Note that since all windows are created in the
SYS schema, you must always use the [SYS].window_name syntax when you reference
any window.
Opening a Window When a window opens, there will be a switch in the

resource plan, and all jobs that are currently running will see a change in their
resource allocation, as specified by the particular resource plan associated with the
window that just opened. A window is designed to open at a certain time (start_
time) and stay open for a fixed length of time (duration). The rest of the time,
the window stays closed.
A window will automatically open at a time specified by its start_time

attribute. Only one window can be open at any given time.You can also open a
window manually anytime you wish, by using the OPEN_WINDOW procedure. Even
when you manually open a window prematurely, that window will still open at its
regular open time specified by its interval. Here’s an example that shows how you
can open a window manually:
dbms_scheduler.open_window (
window_name =>'BACKUP_WINDOW',
duration => '0 12:00:00');
Look at the duration attribute in the preceding statement. When you specify
the duration, you can specify days, hours, minutes, seconds, in that order. Thus, the
setting means 0 days, 12 hours, 0 minutes, and 0 seconds.
Manually opening a window doesn’t affect the regular schedule of the

window.
Note that you can open an already open window. If you do this, the duration of
the window will last a time period equal to its duration attribute. That is, if you
open a window that has been running for 30 minutes and its duration is 60 minutes, your
window will last a total of the initial 30 minutes plus an additional 60 minutes, for a
total of 90 minutes.
You must have the MANAGE SCHEDULER system privilege in order to open,
close, disable, or drop a window.
Closing a Window To close a window, you use the CLOSE_WINDOW procedure,

as illustrated by the following example:
dbms_scheduler.close_window('BACKUP_WINDOW');
If a job is running when you close a window, the job will continue to run to its
completion. However, a running job may close upon the closing of its window if
you create a job with the attribute STOP_ON_WINDOW_CLOSE set to TRUE.
You can alter all attributes except the window_name attribute by using the
SET_ATTRIBUTES procedure.
Disabling a Window To disable a window, you use the DISABLE procedure,

as shown here:
dbms_scheduler.disable (name => 'BACKUP_WINDOW');
You can only disable a window if no job uses that window or if the window isn’t
open. If the window is open, you can disable it by using the DISABLE program with
the FORCE=TRUE attribute.
Dropping a Window When you drop a window, you automatically remove it

from its window group.You can drop a window by using the DROP_WINDOW procedure.
By using the FORCE=TRUE attribute, you can do the following:
■ Disable all the jobs that use that window

■ Drop an open window
If a job associated with a window is running, a DROP_WINDOW procedure will

continue to run through to completion and is disabled after it completes. If you set
the STOP_ON_WINDOW_CLOSE attribute to TRUE, however, the job will immediately
stop when you drop an associated window. If you use the FORCE=TRUE setting,
you’ll disable all jobs that use that window.
Prioritizing Jobs
As you are aware, all database jobs are collected into job classes. You then map each
job class to a specific resource consumer group. A resource plan is assigned to a resource
consumer group and thus indirectly to each job class as well, by the Database Resource
Manager. The active resource plan (as determined by the currently open window) will
apportion resources to groups, thus giving different levels of resources to different jobs,
based on their job class.
The Scheduler works closely with the Resource Manager to ensure proper resource
allocation to the jobs. The Scheduler will start a job only if there are enough resources
to run.
To see which resource consumer group a session belongs to, you can use the
following query:
SQL> select sid, serial#,username,resource_consumer_group from v$session;
Within each Scheduler window, you can have several jobs running, with varying
degrees of priority. You can prioritize jobs at two levels—class and job. The prioritization
at the class level is based on the resources allocated to each resource consumer group
by the currently active resource plan. For example, the FINANCE_JOBS class might
rank higher than the ADMIN_JOBS class, based on the resource allocations dictated
by its active resource plan.
Within the FINANCE_JOBS and ADMIN_JOBS classes, there will be several
individual jobs. Each of these jobs has a job priority, which can range from 1 to 5,
with 1 being the highest priority. You can use the SET_ATTRIBUTES procedure
to change the job priority of any job, as shown here:
begin
dbms_scheduler.set_attribute (
name => 'test_job',
attribute => 'job_priority',
value => 1);
end;
The default job priority for a job is 3, which you can verify with the following query:
SQL> select job_name, job_priority from dba_Scheduler_jobs;
JOB_NAME JOB_PRIORITY
------------------------------ ------------
ADV_SQLACCESS1523128 3
ADV_SQLACCESS5858921 3
GATHER_STATS_JOB 3
PURGE_LOG 3
TEST_JOB03 3
TEST_JOB1 3
6 rows selected.
SQL>
When you have more than one job within the same class scheduled for the same
time, the job_priority of the individual jobs determines which job starts first.
Please take time to therefore, a low-priority job belonging to a

distinguish between interclass priority levels high-priority class wll run ahead of a high-
and intraclass job priority levels. Be aware priority job in a low-priority class.
that job priority is only within a class, and
Window Priorities
Since windows might have overlapping schedules, you may frequently have more than
one window open at the same time, each with its own resource plan. At times like this,
the Scheduler will close all windows except one, using certain rules of precedence.
Here is a summary of the windows precedence rules:
■ If two windows overlap, the window with the higher priority opens and the
window with the lower priority closes.
■ If two windows of the same priority overlap, the active window remains open.
■ If you are at the end of a window and you have other windows defined for
the same time period, the window that has the highest percentage of time
remaining will open.
Window Groups
A window group is a collection of windows, and is part of the SYS schema. Window
groups are optional entities, and you may make a window a part of a window group
when you create it, or add windows to the group at a later time.You can specify either
a single window or a window group as the schedule for a job.
As explained earlier in this chapter, you may take two or more windows that have
similar characteristics—for example, some night windows and a holiday window—
and club them together to create a “downtime window group.” The concept of a
window group is for convenience only, and its use is purely optional.
Managing Scheduler Attributes

In earlier sections in this chapter, you’ve seen how you can use the procedure SET_
ATTRIBUTE to modify various components of the Scheduler. Attributes like JOB_
NAME and PROGRAM_NAME are unique to the job and program components.
You can retrieve the attributes of any Scheduler component with the GET_
SCHEDULER_ATTRIBUTE procedure of the DBMS_SCHEDULER package.
Unsetting Component Attributes

Use the SET_ATTRIBUTE_NULL procedure to set a Scheduler component’s attributes
to NULL. For example, to unset the comments attribute of the program TEST_
PROGRAM, you can use the following code:
execute dbms_scheduler.set_attribute_null('TEST_PROGRAM', 'COMMENTS');
Altering Common Component Attributes

There are some attributes that are common to all Scheduler components. The procedure
SET_SCHEDULER_ATTRIBUTE lets you set these common, or global level, attribute
values, which affect all Scheduler components. Let’s discuss these common attributes
in the following sections.
default_timezone If jobs and windows

specifications use the calendering syntax but omit
Oracle recommends the start date, the Scheduler derives the time
that you set the default_timezone zone from the default_timezone attribute.
attribute to a region’s name instead of
absolute time zone offset, in order to log_history This attribute refers to the number
ensure that daylight saving adjustments of days the Scheduler will retain job and window
are being taken into account. logs. The default retention period is 30 days.
max_job_slave_processes The Scheduler determines the optimal number of

job slave processes, based on your processing requirements. However, you can set a
limit on the number of job slave processes using the max_job_slave_processes
attribute, whose default value is NULL, and the range is from 1 to 999.
Viewing Information About the Scheduler

You can use a set of data dictionary views to manage the Scheduler. Let’s take a brief
look at the important Scheduler-related data dictionary views.
DBA_SCHEDULER_JOBS This view provides the status and general information

about scheduled jobs in your database. Here’s a simple query using the view:
SQL> select job_name, program_name from
dba_scheduler_jobs;
JOB_NAME PROGRAM_NAME
-----------------------------------------------------
ADV_SQLACCESS1523128 ADV_SQLACCESS5858921
GATHER_STATS_JOB GATHER_STATS_PROG
PURGE_LOG PURGE_LOG_PROG
TEST_JOB03
…
SQL>
DBA_SCHEDULER_RUNNING_JOBS This view provides you with

information regarding currently running jobs.
DBA_SCHEDULER_JOB_RUN_DETAILS This view provides information

about status and the duration of execution for all jobs in your database, as the following
example shows.
SQL> select job_name, status, run_duration
from dba_Scheduler_job_run_details;
JOB_NAME STATUS RUN_DURATION
---------------------------------------------------
GATHER_STATS_JOB SUCCEEDED +000 00:09:37
ADV_SQLACCESS5858921 FAILED +000 00:00:03
SQL>
DBA_SCHEDULER_SCHEDULES This view provides information on all

current schedules in your database, as shown in the following query:
SQL> select schedule_name, repeat_interval
2* from dba_Scheduler_schedules;
SCHEDULE_NAME REPEAT_INTERVAL
------------------------------------------------------------------------
DAILY_PURGE_SCHEDULE freq=daily;byhour=3;byminute=0;bysecond=0
SQL>
DBA_SCHEDULER_JOB_LOG This view

enables you to audit job management activities
in your database. The data that this view will
The DBA_SCHEDULER_ contain depends on how you set the logging
JOB_RUN_DETAILS view provides parameters for your jobs and job classes.
information about the status and duration In order to set the logging level at the job class
of execution for all Scheduler jobs. level, you need to use the DBMS_SCHEDULER
procedure’s LOGGING_FULL and LOGGING_
RUNS when you create your job class, as shown in the earlier section “Creating a
Job Class.”
In order to set the logging levels at the individual job level, you use the SET_
ATTRIBUTE procedure of the DBMS_SCHEDULER. In the SET_ATTRIBUTE
procedure, you can set the attribute logging_level to two different values:
DBMS_SCHEDULER.LOGGING_FULL
DBMS_SCHEDULER.LOGGING_RUNS
The LOGGING_RUNS option will merely record the job runs, while the LOGGING_
FULL option turns on full job logging. Here is an example showing how you can turn
on full job logging at the job level:
execute dbms_scheduler.set_attribute ('TESTJOB',
'LOGGING_LEVEL', dbms_Scheduler.LOGGING_FULL);
As a DBA, you can set turn off logging at the job level, yet the
logging at the job class level in order to Scheduler will log the job run information.
audit Scheduler jobs. Once you set the A user, however, can increase the logging
logging at the class level, an individual user level to LOGGING_FULL for a job, thus
can only increase the amount of logging. raising the level of logging from the LOGGING_
For example, if you set LOGGING_RUNS at RUNS level you set to a higher logging level.
the job class level, the creator of a job may
Purging Job Logs

By default, once a day, the Scheduler will purge all window logs and job logs that are
older than 30 days. As long as the Scheduler is active, it runs the PURGE_JOB job to
perform this automatic purging of the logs. You can also manually purge the logs by
executing the procedure yourself, as shown here:
execute dbms_scheduler.purge_log (
log_history => 1,
job_name => 'TEST_JOB1');
You can modify the retention period (the default is 30days) of the logs for a job
class by using the SET_ATTRIBUTE procedure, as shown here:
dbms_scheduler.set_attribute(
'TEST_JOB_CLASS', 'log_history', '7');
In the preceding example, the log_history attribute resets the log retention
period to seven days.
The log_history 0 and 999. If you set it to 0, it means that

attribute specifies the number of days to you want to purge all log entries daily.
keep the logs. It can take a value between
In order to clear all window and job logs, use the following command:
execute dbms_scheduler.purge_log();
Database Resource Manager Enhancements

The Database Resource Manager helps you to effectively manage your server resources.
There are several important enhancements in the Resource Manager tool in Oracle
Database 10g. Using the idle_time resource plan, you can set limits on idle time for
user sessions that are blocking other sessions. You can specify that a session is returned
to its original consumer group automatically, after a top call. You can now use consumer
group mappings to assign priorities to consumer groupings. There is also a new CPU
allocation method in the DBMS_RESOURCE_MANAGER package.
Let’s start our discussion of the Resource Manager enhancements by looking at the
new ways you can set idle time-outs in Oracle Database 10g.
Setting Idle Time-Outs

You can now limit the maximum idle time for a session as well as the maximum time
an idle session can block another session. Until now, the only way to limit session idle
time was by setting the value of the IDLE_TIME attribute while creating or altering a
database profile.
You set the new idle time limits using the CREATE_PLAN_DIRECTIVE procedure
of the Database Resource Manager. The new argument MAX_IDLE_TIME determines
the maximum idle time of a session. The other new argument, MAX_IDLE_BLOCKER_
TIME, determines the maximum amount of time an idle session can block another
session. Here is an example:
exec dbms_resource_manager.create_plan_directive
(plan => 'new_plan', -
group_or_subplan => 'sales',
comment => 'sales group', -
cpu_p1 => 60,
parallel_degree_limit_p1_P1 => 4
max_idle_time => 600,
max_idle_blocker_time => 300);
The default value for both the MAX_IDLE_TIME and MAX_IDLE_BLOCKER_

TIME is NULL, which implies that the idle time is unlimited.
Database Resource Manager Enhancements 35
In the preceding example, the maximum time a session can remain idle is capped
at 600 seconds by the MAX_IDLE_TIME attribute. After this time, if a session continues
to sit idle, without executing or waiting for I/O, the PMON process kills the session
and cleans up after it. The MAX_IDLE_BLOCKER_TIME ensures that the PMON
also kills any session that is idle for more than 300 seconds and is blocking another
session. The PMON process grabs the offending sessions during its regular database
checks, which it conducts on a minutely basis.
Automatic Switching Back to Initial Consumer Groups

When you create plan directives for the Database Resource Manager using the CREATE_
PLAN_DIRECTIVE procedure of the DBMS_RESOURCE_MANAGER package, you
can use several switch parameters to stipulate the action to be taken after a specified
time period. The SWITCH_TIME parameter specifies the length of time that a session
can continue to execute before a certain action is taken.
In Oracle Database 10g, you now have a new switch parameter called SWITCHTIME_
IN_CALL. Like the SWITCH_TIME parameter, this parameter also specifies the time
that a session can execute before a certain action is taken. However, the SWITCH_
TIME_IN_CALL parameter has only one specific purpose: if you specify a value
for this parameter, say 600 seconds; after that interval passes, at the end of the call,
Oracle will switch the consumer group of that session to its initial consumer group.
The initial consumer group you started with is specified by the SWITCH_GROUP
attribute in the CREATE_PLAN_DIRECTIVE procedure that you use to implement
the Database Resource Manager. Unlike SWITCH_TIME, the SWITCH_TIME_IN_
CALL parameter will only downgrade your session to a lower priority group for that
one call, whereas SWITCH_TIME will downgrade you permanently.
You cannot specify both SWITCH_TIME and SWITCH_TIME_IN_CALL plan

directives for a single consumer group.
The ability to switch sessions back to their initial consumer group at the end of
their top call is a huge enhancement because it means that you can now use the
Resource Manager in the web environment, with connection pooling from the
middle tier. Previously, if you downgraded a connection because one web client
issued a horrific statement, it would stay downgraded for any subsequent jobs, even
if they came from other web clients.
Creating Mappings to Assign Priorities to Resource Groups

At any given time, a user session can belong to only one resource consumer group.
You can now configure the Database Resource Manager to assign consumer groups
to sessions by mapping various session attributes to consumer groups. The ability to
map session attributes and consumer groups enables you to do two things:
■ Assign sessions to consumer groups

■ Assign priorities to indicate which mappings have precedence
Let’s first look at how you can assign consumer groups to sessions.
Creating Mapping Between Sessions and Consumer Groups

There are two types of session atrributes—login attributes and run-time attributes. When
a user first logs into the database, the Resource Manager looks at the login attributes in
order to evaluate to which consumer group it should assign the session. The run-time
attributes are useful when an already logged in user’s session needs to be assigned to
another consumer group. Let’s look at the individual session atrributes in more detail,
in the following section.
The ability to create session mappings is another enhancement that strengthens

the use of the Database Resource Manager in managing web applications. In
earlier versions of Oracle, the ORACLE_USER attribute was the only mapper
available, and all your web clients were likely to use the same ORACLE_USER
attribute through a connection pool. But in Oracle Database 10g, the Database
Resource Manager can map sessions to groups according to what they are doing.
Session Attributes These are the key elements in the mapping of sessions and
consumer resource groups. As mentioned in the previous section, there are two types
of session attributes—run-time and login. Following are the login attributes:
■ ORACLE_USER The standard Oracle Database username

■ CLIENT_OS_USER The operating system name of the user
■ CLIENT_MACHINE The name of the machine from which the user is
connecting to Oracle
■ CLIENT_PROGRAM The name of the program the user is employing to
log into the database, for example, a SQL*Plus session
■ SERVICE_NAME The name used by the user to log into the database
There are five session attributes:
■ MODULE_NAME The module name in the application that is currently

executing in the database
■ MODULE_NAME_ACTION The current module name and action being
performed by the session
■ SERVICE_MODULE A combination of the service and the module name
■ SERVICE_MODULE_ACTION A combination of the service name, module
name, and action name
■ EXPLICIT An explicit mapping requested by the client
Creating the Mappings You map a session’s attributes to a consumer group by

using the SET_CONSUMER_GROUP_MAPPING procedure of the DBMS_RESOURCE_
MANAGER package. You create an explict mapping between each session attribute
and the resource group pair, as shown here:
execute dbms_resource_manager.set_consumer_group_mapping (
DBMS_RESOURCE_MANAGER.ORACLE_USER, 'scott', 'dev group');
In the previous listing, a user with the operating system name SAM can log in as
the Oracle user SCOTT, and will be assigned to the “dev” consumer resource group.
Notice that the ORACLE_USER attribute is being mapped to the resource group
‘dev group’. In the following example, I map user SAM to the ‘prod group’, based
on the CLIENT_OS_USER attribute.
execute dbms_resource_manager.set_consumer_group_mapping -
(DBMS_RESOURCE_MANAGER.CLIENT_OS_USER, 'SAM', 'prod_group');
Automatic Consumer Group Switching Oracle will follow an automatic

consumer group switching policy based on the specific mapping in force at any given
time. Here’s a summary of the switching policy:
■ When you first log in, you are mapped to the initial resource group based on
the attribute being mapped.
■ If you change a run-time attribute later, you are switched automatically to a
different consumer group.
■ It is possible to be switched to the same consumer group you are currently in.
Assigning Mapping Priorities As you can surmise, a single session can be

mapped to several consumer resource groups, because you can map each session
attribute to a consumer group. You may, for example, map a resource group based
on the value of a session’s MACHINE_NAME, CLIENT_OS_USER, MODULE_NAME,
CLIENT_NAME, SERVICE_NAME_ACTION, or some other login or run-time
attribute. Naturally, there is room for a conflict or ambiguity regarding which resource
group to assign to a session, since there are multiple attributes to each session, and
each of them may be assigned to a different resource group. The Database Resource
Manager uses priority levels to resolve such ambiguities. Let’s look at how you can
assign priorities among session attributes.
You set session attribute mapping priorities by
using the SET_CONSUMER_GROUP_MAPPING_
PRI procedure of the DBMS_RESOURCE_
A session must be a member MANAGER package. This procedure helps
of a particular resource group in order to be you prioritize session mappings. In order to
switched to it—a mere mapping between a establish priorities among the various attributes,
session attribute and that group won’t suffice you assign each session attribute a priority level
to switch resource groups. that ranges from 1 to 10, with 1 being the
highest and 10 the lowest. Here’s an example:
SQL> dbms_resource_manager.set_consumer_group_mapping_pri (
(explicit => 1,
client_machine => 2,
module_name => 3,
oracle_user => 4,
service_name => 5,
client_os_user => 6,
client_program => 7,
module_name_action => 8,
service_module => 9,
service_module_action => 10);
All the priority levels you see in the preceding listing are the default priority
levels of each of the session attributes, which you may change with the SET_
CONSUMER_GROUP_MAPPING procedure.
In the preceding example, the session attribute ORACLE_USER has a priority

level of 4. Thus, even if the ORACLE_USER and the CLIENT_OS_USER attributes
are mapped to different consumer resource groups, Oracle will assign the user to the
group mapped to the ORACLE_USER session attribute because its priority level (4)
is higher than the priority level of the CLIENT_OS_USER attribute (6).
The MODULE_NAME and MODULE_NAME_

ACTION attributes offer you powerful capabilities
when you are using web applications. Typically,
Application developers middle-tier applications use a single username
may also set the MODULE_NAME and for all the users, but use different MODULE_
MODULE_NAME_ACTION through the NAME and MODULE_NAME_ACTION attributes
use of the DBMS_APPLICATION_INFO to distinguish between the type of work performed
package. The SERVICE_NAME attribute is by individual users. The resource manager can
the connect string that you specify in your now detect what application module a session
tnsnames.ora file. is actually invoking at any given moment, and
assign resources appropriately (by associating the
session to the appropriate resource consumer group), independently of the DB logon
(which is probably pooled from a middle tier).
New Database Resource Manager Allocation Methods

In Oracle Database 10g, you have new methods of allocating CPU resources. When
you use the CREATE_CONSUMER_GROUP procedure, you can now set the CPU_MTH
attribute to a RUN_TO_COMPLETION setting. When you use the CREATE_PLAN
procedure to create a resource plan, you have a new setting called RATIO, for the
CPU_MTH variable. Let’s take a quick look at both of these changes in the following
sections.
The RUN_TO_COMPLETION Allocation Method When you create a

consumer group using the CREATE_CONSUMER_GROUP procedure, the CPU_MTH
option provides the method to distribute your CPU among the sessions in the consumer
group. The default value for the CPU_MTH option is ROUND_ROBIN. The new
RUN_TO_COMPLETION method specifies that the session with the largest active
time should be scheduled ahead of other sessions. Here’s an example:
exec dbms_resource_manager.create_consumer_group (
consumer_group => 'sales',
cpu_mth => 'RUN TO COMPLETION',
comment => 'this is the new 10g cpu_mth option');
Usually, you would give batch and large data warehouse-type jobs a low priority
to avoid impacting your OLTP operations. But the RUN_TO_COMPLETION
CPU allocation method accords top priority to large jobs run by a particular
group.
The Ratio Allocation Method Previously, in Oracle9i, when you created

a new resource plan, the CPU_MTH (the CPU resource allocation method) could
only take a single value—EMPHASIS. In Oracle 10g, you can now use a new
CPU allocation method when you create a resource plan, called RATIO. The RATIO
allocation method is meant for single-level resource plans that use ratios to specify
the allocation of CPU. EMPHASIS remains as the default CPU allocation method,
and it is for multilevel plans that use percentages to specify how CPU is allocated
among various resource groups. Following is an example that shows how to specify
RATIO as a resource plan’s CPU allocation method.
dbms_resource_manager.create_plan
(plan => 'service_level_plan',
cpu_mth -> 'RATIO',
comment => 'service level plan');
Once you choose the new RATIO allocation policy by specifying it as the CP_
MTH value in the CREATE_PLAN statement, you aren’t quite ready to use the ratio
method. You must also use the CREATE_PLAN_DIRECTIVE procedure and set the
CPU_P1 directive to actually set the ratios for the CPU allocation. Here is an example:
SQL> dbms_resource_manager.create_plan_directive
group_or_subplan => 'GOLD_CG',
comment => 'Gold service level customers',
cpu_p1 => 10);
dbms_resource_manager.create_plan_directive
group_or_subplan => 'SILVER_CG',
comment => 'Silver service level customers',
cpu_p1 => 5);
group_or_subplan => 'BRONZE_CG',
comment => 'Bronze service level customers',
cpu_p1 => 2);
group_or_subplan => 'OTHER_GROUPS',
comment => 'Lowest priority sessions',
cpu_p1 => 1);
In the preceding example, there are four consumer groups—Gold_CG, Silver_

CG, Bronze_CG, and the default OTHER_GROUPS. The CPU is allocated using the
RATIO method. For every 18 units, the ratio of CPU allocation would be 10:5:2:1 for
You must understand that consumer groups. The RATIO and the old
the RUN_TO_COMPLETION and the old EMPHASIS allocation methods, on the other
ROUND_ROBIN allocation methods are hand, are used with the CREATE_PLAN
part of the CREATE_CONSUMER_GROUP procedure and apply to resource plans.
procedure, and they apply to resource
the GOLD_CG, SILVER_CG, BRONZE_CG, and OTHER_GROUPS consumer groups,

respectively. If at times you only have sessions for the first two groups—GOLD_CG and
SILVER_CG—then these two groups would split the CPU resources in a 10:5 ratio.
INSIDE THE EXAM
The exam has questions that test your expressions that set repeat intervals like once
familiarity with the logging and purging of a week and every five minutes.
Scheduler jobs. Know the default purging You must know the DBMS_SCHEDULER
procedure for jobs and the various logging package very well. Understand the different
levels. Which logging level gives you the parameters like start_date, end_date,
most information? repeat_interval, and duration. How
You must remember the names and and which Scheduler attributes can you set at
functions of the basic and advanced the global level? The exam will test your
Scheduler components. What is the knowledge of the DBA_SCHEDULER_JOB_
purpose of using advanced components like RUN_DETAILS and DBA_SCHEDULER_
job classes, windows, and window classes? JOB_LOG views.
What privileges do you need to manage each The exam tests your knowledge of the new
of these components? The test will most likely resource allocation methods when you use the
probe your knowledge of job priorities. Know DBMS_RESOURCE_MANAGER package. What
the difference between inter-job class and do the RATIO and the RUN_TO_COMPLETION
intra-job class priorities. When windows resource allocation methods do? Know how to
overlap, how does the Scheduler determine assign priorities using the DBMS_RESOURCE_
window priorities? MANAGER package, and how mappings are
You must know how to set repeat intervals created between session attributes and specific
for jobs. Pay particular attention to calendaring consumer resource groups.
expressions. Practice with calendaring
The chapter started with an introduction to the all-new Oracle Scheduler feature.
You learned about the basic building blocks of the Scheduler—jobs, programs, and
schedules. You also learned how to create and administer these basic components.
You were introduced to the main features of the advanced Scheduler components,
including job classes and windows. You saw how you can associate job classes with
resource consumer groups. You also learned how you can control resource allocation
by associating resource plans with Scheduler windows.You learned how to query the
main data dictionary view concerning the Scheduler.
In the last part of this chapter, you learned about the advancements in the Database
Resource Manager feature. These include the new idle time-outs for consumer groups,
automatic switching of consumer groups at the end of the top call, and the automatic
assignment of sessions to consumer groups through the mapping of session attributes.
You then learned how to utilize the new CPU_MTH methods for allocating CPU—
the RUN_TO_COMPLETION and RATIO methods.
Two-Minute Drill 43
Simplifying Management Tasks by Using the Scheduler
❑ The Scheduler replaces DBMS_JOB as the main scheduling facility in
❑ Use the DBMS_SCHEDULER package to manage the Scheduler.
❑ You can schedule PL/SQL programs, Java programs, native binary
executables, and shell scripts.
❑ Jobs, programs, and schedules are the basic Scheduler components.
❑ A job is a task you run one or more times.
❑ You can run a job by itself or with a saved program and/or a saved schedule.
❑ A schedule tells you when and how frequently you should run a job.
❑ A program contains metadata about a job.
❑ A job class groups several similar jobs into one large entity.
❑ In a job class, the priority levels range from 1 to 5.
❑ A higher-priority job always starts before a lower-priority job.
❑ A window represents a time during which you can schedule a job.
❑ A window always has a resource plan associated with it.
❑ A window group is a collection of windows.
❑ The Scheduler assigns each job class to a specific resource consumer group.
❑ The default resource consumer group is the DEFAULT_CONSUMER_GROUP.
❑ The default job class is the DEFAULT_JOB_CLASS.
❑ The job table records information about all the jobs run by the Scheduler.
❑ The background process cjqNNN automatically starts and monitors the
running of a job.
❑ The job slaves start database sessions and execute the job.
❑ Jobs, programs, and schedules are created in the current user’s schema.
❑ Job classes, windows, and windows groups are created in the SYS schema.
❑ To create the basic components, you need the CREATE JOB privilege.
❑ To use the advanced Scheduler components, you must have the MANAGE
SCHEDULER system privilege.
❑ The EXECUTE ANY PROGRAM privilege lets a user execute a program

under any schema.
❑ The SCHEDULER_ADMIN role contains all the Scheduler system privileges.

❑ All Scheduler objects are of the form [schema].name.
❑ When you create a job, the parameter values you specify will override the
default values for programs and schedules.
❑ You create a job using the CREATE_JOB procedure.
❑ You can run a PL/SQL block, a Java program, a shell script, or a native binary
executable as part of your job.
❑ You can use a PL/SQL date/time expression or a calendaring expression for
setting the repeat_interval parameter.
❑ Calendaring expressions have three components: frequency, repeat interval,
and any optional specifiers.
❑ You must have the MANAGE SCHEDULER privilege in order to use the
FORCE setting when you stop or drop a job.

❑ The Scheduler uses job classes, windows, and window classes to prioritize jobs
in the database.
❑ Each job class is associated with a resource consumer group.
❑ The logging level when you create a job class can take the values LOGGING_
OFF, LOGGING_RUNS, or LOGGING_FULL.
❑ The default logging level is LOGGING_RUNS.
❑ The purpose of a window is to automatically switch resource plans during
certain periods.
❑ Windows consist of three basic components: schedules, duration, and
resource plan.
❑ Window priorities can take the values LOW or HIGH.
❑ You can have overlapping windows, since the Scheduler doesn’t check before
creating new windows.
❑ You can use the SET_ATTRIBUTES procedure to change the job priority
of a job.
Two-Minute Drill 45
❑ Window priorities are resolved by checking which window has the higher
priority level, or whichever window opened first, if the window priorities are
the same.
❑ You can use the SET_ATTRIBUTE_NULL procedure to set a Scheduler
component’s attributes to NULL.

❑ The DBA_SCHEDULER_JOBS view provides information about the status
and general information about scheduled jobs.
❑ The DBA_SCHEDULER_RUNNING_JOBS view provides information about
currently running jobs.
❑ The DBA_SCHEDULER_JOB_RUN_DETAILS view provides information
about the status and the duration of execution for all jobs.
❑ The DBA_SCHEDULER_SCHEDULES view provides information on all
saved schedules.

❑ You can now set idle time limits using the CREATE_PLAN_DIRECTIVE
procedure of the DBMS_RESOURCE_MANAGER package.
❑ You can use the MAX_IDLE_TIME parameter to limit idle sessions. You can
use the MAX_IDLE_BLOCKER_TIME to limit idle sessions that are blocking
other sessions.
❑ The new SWITCH_TIME_IN_CALL parameter automatically returns a
session to its original resource consumer group, after the database completes
the top call.
❑ You can create mappings between session attributes and resource consumer
groups.
❑ You can create as many mappings as there are session attributes.
❑ You can assign session attribute mapping priorities by using the DBMS_
RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRI
procedure.
❑ You can now set the CPU_MTH attribute to the new RUN_TO_
COMPLETION setting.
❑ You can now use the new CPU allocation method RATIO, which uses ratios
to specify the allocation of CPU resources among various resource groups.
SELF TEST
this chapter. Read all the choices carefully because there might be more than one correct answer.

1. Whose job is it to update the job table and the log table?
A. The worker (slave) process
B. The SYS user
C. The Database Resource Manager
D. The cjqNNN background process
2. Which of the following do you need to specify a stored schedule that’s owned by
a different user?
A. You must have the EXECUTE ANY SCHEDULE privilege.
B. You don’t need any privileges to use a stored schedule.
C. You need the MANAGE SCHEDULER privilege.
D. You need the EXECUTE ANY JOB privilege.
3. Which of the following is true when you are using saved schedules and programs as part of a
new job?
A. If you explicitly use parameters that are also in the schedules or programs, the parameter
values you specify will override the values specified for the parameters in the schedules and
programs.
B. If you explicitly use parameters that are also in the schedules or programs, the parameter
values you specify will be overridden by the values specified for the parameters in the
schedules and programs.
C. You can’t use separate parameter values in a job creation statement if they are already part
of a schedule or a program.
D. You cannot use saved schedules and programs with a new job.
4. If you create a job in user SCOTT’s schema, who will be the owner of the job?
A. SCOTT will be the owner of the job.
B. SYS will be the owner of the job.
C. You will be the owner of the job.
D. PUBLIC will be the owner of the job.
Self Test 47

5. What is the correct syntax to create a schedule that executes every second?
A. FREQ=SECONDLY; INTERVAL=1/60
B. FREQ=SECONDLY; INTERVAL=1
C. FREQ=SECONDLY
D. FREQ=HOURLY; INTERVAL=1/60
6. Regarding your ability to combine the various components of the Scheduler, which of the
following are possible?
A. Use a job by itself all the time.
B. Use a job and a program together.
C. Use a job, schedule, and a program together.
D. Use a program and a schedule together.
7. What is the priority level for a job in a job class?
A. From 1 to 5
B. From 1 to 999
C. From 1 to 10
D. A job can only take a value of HIGH or LOW.
8. Scheduler job table information can be seen in which view?
A. DBA_RESOURCE_MANAGER view
B. DBA_JOBS view
C. DBA_SCHEDULER_JOBS view
D. DBA_SCHEDULER view

9. You create a new job class and name it my_job_class. Where will this job class be saved?
A. In your schema.
B. In the SYS schema.
C. In all schemas that are part of the database.
D. Job classes aren’t saved under any one schema.
10. You create a job class and set the LOGGING_RUNS option for the LOGGING_LEVEL
parameter. What will be the result?
A. The database will not perform any logging for individual jobs.
B. The database will not perform a detailed logging of the job runs.
C. The database will perform a detailed logging of the job runs.
D. For each run of a job, there will just be a mention of the job only in the job log.
11. The DBA wishes to drop an existing job class. The DBA notices that a job from the job class
she wants to drop is currently running. Which of the following scenarios would be true?
A. You cannot drop the jobs along with the job class definition.
B. If you use the FORCE=TRUE option, the running jobs will stop immediately and the job
class will be removed as well.
C. Just use the DROP_JOB_CLASS with no options to drop the job class and kill any running
jobs right away.
D. If you use the FORCE=TRUE option, the running jobs will continue to completion anyway,
but the job class and its jobs will be removed.
12. What important attribute does a window have, that a schedule doesn’t?
A. A program
B. An interval
C. A resource plan
D. A resource consumer group

13. To see which Scheduler jobs are currently running, which view would you use?
A. DBA_SCHEDULER_RUNNING_JOBS view
B. DBA_SCHEDULER_JOB_RUN_DETAILS view
C. DBA_SCHEDULER_SCHEDULES view
D. DBA_SCHEDULER_JOBS view
14. Using the SET_ATTRIBUTE procedure, you can set the logging_level attribute to which
two values?
A. LOGGING_NONE and LOGGING_RUNS
B. LOGGING_DEFAULT and LOGGING_RUNS
Self Test 49
C. LOGGING_DETAILED and LOGGING_RUNS

D. LOGGING_FULL and LOGGING_RUNS
15. What will the command EXECUTE DBMS_SCHEDULER.PURGE_LOG(); do?
A. Purge only all the window logs
B. Purge only all the job logs
C. Purge all window and job logs
D. Purge only yesterday’s job logs
16. Where can you find the status and duration of execution of all jobs in your database?
A. DBA_SCHEDULER_JOB_RUN_DETAILS
B. DBA_SCHEDULER_RUNNING_JOBS
C. DBA_SCHEDULER_SCHEDULES
D. DBA_SCHEDULER_JOBS

17. Which procedure of the DBMS_RESOURCE_MANAGER package enables the DBA to set idle
time limits?
A. DBMS_RESOURCE_MANAGER.create_plan_directive
B. DBMS_RESOURCE_MANAGER.create_resource_plan
C. DBMS_RESOURCE_MANAGER.create_resource_group
D. DBMS_RESOURCE_MANAGER.idle_time
18. In the context of using the DBMS_RESOURCE_MANAGER package to set mapping priorities,
what kind of attribute is MODULE_NAME?
A. Run-time session attribute
B. Neither a run-time nor a login session attribute
C. Login attribute
D. Could be either a run-time attribute or a login session attribute
19. What is the default value for the CPU_MTH option when you are creating a consumer group?
A. ROUND_ROBIN
B. RATIO
C. RUN_TO_COMPLETION
D. DEFAULT
20. When you create a mapping between consumer groups and session attributes, how many
consumer resource groups can a single session map to?
A. Only one consumer resource group
B. At most two resource consumer groups
C. As many resource consumer groups as there are session attributes
D. A unique consumer resource group each time you log in again
LAB QUESTIONS
Lab 1
Use the Database Resource Manager to ensure that all idle sessions will not last more than 20 minutes.
Also ensure that you kill all idle sessions that have been around for more than a minute and are blocking
other user sessions.
Lab 2
Create a schedule, a program, and a job to gather data at five-minute intervals in your database.
SELF TEST ANSWERS

1. þ A. The worker (slave) process updates the job table and log table.
ý B and C are wrong since neither the SYS user nor the Database Resource Manager play
any role in updating the log and the job tables. D is wrong since the cjqNNN background
process identifies the job coordinator, who doesn’t execute any chores directly, but rather
hands them to the slave (worker) processes. These jobs include updating the Scheduler job
and log tables.
2. þ B. You don’t need any privileges to use any of the saved schedules in the database.
ý A, C, and D are wrong since you don’t need any specific privileges to use a saved schedule.
3. þ A. If you use separate parameter values for any schedule- or program-related parameters
while creating a job, those values will override the values for these parameters specified in any
schedules or programs that you may be using in the job creation statement.
ý B is wrong because it states the opposite of the correct answer. C is wrong since you can
specify parameter values for the parameters specified in a schedule or a program. D is wrong
since you can use saved programs and schedules when you create a new job.
4. þ A. The creator of a job need not be the owner of a job. User Scott will be the owner of
the job since you’re creating the job in Scott’s schema.
ý B, C, and D are incorrect since a job is owned by the user in whose schema you create
the job.

5. þ B and C. B is correct since FREQ=SECONDLY will help you execute a schedule that
will execute on a minutely basis. Answer C will also execute the schedule every second.
ý A is wrong since it states that the program will execute 60 times in one second! D is
wrong since it will execute the job every minute, not every second.
6. þ A, B, and C are all correct. You can use a job all by itself or with either or both of the
optional objects—schedule and program.
ý D is wrong since you can’t use the Scheduler without a job.
7. þ A. The priority level for a job can range from 1 to 5.
ý B, C, and D are the wrong priority levels.
8. þ C. The DBA_SCHEDULER_JOBS view captures the data in the Scheduler job table.
ý A, B, and D refer to the wrong views.

9. þ B is correct because all job classes are saved in the SYS schema.
ý A and C are wrong since they point to the wrong schemas. D is wrong since it says that
job classes can’t be saved in any schema.
10. þ C. LOGGING_RUNS means there will be a detailed log of all job runs.
ý A is wrong since there will be logging. B is wrong since there will be detailed logging of
all job runs. D is wrong since the logging isn’t merely limited to the mention of the job—there
will be a detailed logging for each job.
11. þ D is correct since using the FORCE=TRUE option will remove the job class, but any
currently running jobs will continue to completion.
ý A is wrong since you can drop a job along with its job class. However, note that when you
drop a job class, its jobs aren’t really dropped, but disabled. B is wrong since the FORCE=TRUE
option won’t stop a running job before it completes. C is wrong since you can’t kill running jobs
while dropping a job class.
12. þ C. A window always has a resource plan, but a schedule doesn’t have one.
ý A and B are wrong since both windows and schedules have a program and interval. D is
wrong since you don’t have to specify the resource consumer group for either a window or a
schedule.

13. þ A. The DBA_SCHEDULER_RUNNING_JOBS view shows you details about all currently
running jobs.
ý B is wrong since the DBA_SCHEDULER_JOB_RUN_DETAILS view shows you the status
and duration of execution of all jobs in your database. C is wrong because the DBA_SCHEDULER_
SCHEDULES view provides information on all schedules in your database. D is wrong because
the DBA_SCHEDULER_JOBS view shows the status and general information for all your
scheduled jobs.
14. þ D. LOGGING_FULL and LOGGING_RUNS options are valid.
ý A, B, and C are wrong since they contain a nonexistent logging option.
15. þ C. The command will purge all window and job logs.
ý A is wrong since the command will also purge all job logs. B is wrong because the command
will also purge all window logs. D is wrong because the command will purge all window and
job logs, not just yesterday’s logs.
Lab Answers 53
16. þ A. The DBA_SCHEDULER_JOB_RUN_DETAILS view provides the status and duration

of execution of all jobs.
ý B, C, and D point to the wrong data dictionary views. Please refer to the explanation for
Question 13 for more details on why these are incorrect answers.

17. þ A. The CREATE_PLAN_DIRECTIVE procedure lets you specify idle time limits for sessions.
ý B is wrong since the CREATE_RESOURCE_PLAN directive helps you specify resource
plans. C is a wrong choice since the CREATE_RESOURCE_GROUP is only useful for specifying
the members of a resource consumer group. D refers to a nonexistent procedure.
18. þ A. The MODULE_NAME attribute belongs to the group of run-time session attributes.
ý B, C, and D are wrong because MODULE_NAME is a run-time attribute.
19. þ A. The old ROUND_ROBIN method is still the default method.
ý B, C, and D aren’t default values for the CPU_MTH option.
20. þ C. You can map a single session to as many resource consumer groups as there are session
attributes, since you can map each of the attributes to a separate resource consumer group.
ý A, B, and D provide the wrong alternatives.
LAB ANSWERS
Lab 1
To kill idle sessions that go over a set idle time limit, use the DBMS_RESOURCE_MANAGER package
in the following way, and set the MAX_IDLE_TIME and MAX_IDLE_BLOCKER_TIME parameters.
(Note that you must create the pending area before you can create the following plan.)
SQL> begin
dbms_resource_manager.create_plan_directive (
plan => 'TEST_PLAN',
group_or_subplan => 'TEST_GROUP',
comment => 'Limit user idle time',
max_idle_time => 600,
max_idle_blocker_time => 300);
end;
Lab 2
1. Create the program.
SQL> begin
dbms_scheduler.create_program (
program_name => 'DAILY_GATHERING',
program_action => 'DAILY_DATA_GATHERING',
program_type => 'STORED_PROCEDURE',
enabled => 'TRUE');
end;
2. Create the schedule.

SQL> begin
job_name => 'DAILY_GATHERING_JOB',
start_date => 'TRUNC(SYSDATE+1)+22/24',
repeat_interval => 'TRUNC(SYSDATE+1)+22/24',
comments => 'Daily Data Gathering Job.');
end;
SQL> begin
dbms_scheduler.create_schedule (
schedule_name => 'TEST_SCHEDULE',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=MINUTELY;INTERVAL=5',
comments => 'A test schedule.');
end;
3. Create the job using the program and schedule you created in the previous two steps.
SQL> begin
job_name => 'DAILY_GATHERING_JOB',
schedule_name => 'TEST_SCHEDULE');
end;
Blind Folio 8:1
8
Backup and
Recovery
Enhancements
8.01 Using the Flash Recovery Area 8.04 Miscellaneous Backup and Recovery
Enhancements
8.02 Using Incremental Backups
8.03 Enhanced RMAN Commands
Q&A Self Test
2 Chapter 8: Backup and Recovery Enhancements
O racle Database 10g contains several interesting innovations in the backup and recovery
area. You can now store all recovery-related files, such as archive logs and database
backups, in a unified location on disk. This unified storage location is the new flash
recovery area, and it enables DBAs to simplify file management for all recovery-related files.
Cheaper and faster modern disk storage means that you can recover more quickly from a disk-
based recovery strategy than from a tape-based backup strategy.
The RMAN can now help you recover image copies using incremental backup
files. Oracle Database 10g contains new methods for making faster incremental
backups. This chapter also looks at several changes in the RMAN backup commands,
including the deprecation of the COPY command. You’ll also learn how to perform
a hot recovery without needing to restore backup files first, by using the SWITCH
DATABASE command. This capability will enable you to implement a faster database
recovery.
You can also create compressed backup sets in Oracle Database 10g to save on
storage space. You’ll learn about simplified database recovery after using RESETLOGS,
without needing the usual full backup. You’ll learn how to drop a database using the
DROP DATABASE command. You’ll review the new features that let you specify limits
on your backup windows.
Let’s start with a detailed look at the interesting and very useful flash recovery
area feature.
Using the Flash Recovery Area

The flash recovery area serves as the default storage area for all files related to backup
and restore operations. You can use an Oracle-managed directory, an operating system
file system, or an Automatic Storage Management (ASM) disk group for your flash
recovery area. Traditionally, Oracle DBAs have needed to manage the backup-related
storage areas, making sure that there was enough storage space to save their backup-
related files. Oracle recommends that you now let the database take care of these chores,
by using the new strategy of automatic disk-based backup and recovery.
Using the Flash Recovery Area 3
To enable this feature, you simply designate sufficient disk space as the flash
recovery area, specify the area’s maximum size, and let Oracle know how long you
want to retain the backup-related information. Oracle will then manage the backup
of related files, including archive log files, control files, and other files. Oracle will
delete the files that your database no longer needs because the files have become
obsolete or they have been backed up to tape. Thus, your main tasks will be provisioning
adequate space for the flash recovery area and selecting the appropriate retention
period for keeping the related files.
Once you create the flash recovery area, you can direct all you backup files, including
the archived redo log files, to that area. Oracle will manage these files for you,
deleting the files that either are backed up to tape or are older than the backup
retention interval. In order to automatically delete unwanted files, the flash recovery
area concept relies on the Oracle Managed Files (OMF) system. OMF automates file
management in Oracle databases by automatically creating and managing the operating
system files that you allocate for your database. All you need to do to get an OMF
file system going is to configure a couple of OMF-related initialization parameters:
DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n. As you
are aware, OMF has the capability to automatically create and delete Oracle files,
without the DBA’s intervention. The RMAN capitalizes on this capability of the
OMF file system to perform its backup- and recovery-related functions through using
the flash recovery area.
You can also use a flash recovery area on top an ASM file system (see Chapter 10
for a discussion of ASM file systems). ASM file systems consolidate disks into easily
manageable disk groups, and provide striping and mirroring capabilities based on the
Oracle database itself.
The flash recovery area provides the following benefits:
■ Single storage location for all recovery-related files

■ Automatic management of recovery-related disk space
■ Faster backup and restore operations, since
you don’t need to restore tape backups
■ Increased reliability of backups, since disks
Several databases can
are generally safer storage devices than tapes
share a central flash recovery area.
What’s in the Flash Recovery Area?

You keep all the files you need for media recovery in the flash recovery area. Ideally,
your flash recovery area must hold a complete backup of all your datafiles, any incremental
backups you may have, control file backups, and all the archived redo logs that are
necessary for media recovery. You can also use the flash recovery area as a disk cache
for tape.
All files that you need to by using the files in the flash recovery area.
recover from a media failure are part of In addition to these recovery files, you may
your flash recovery area. You should be also store other database files in the flash
able to completely recover your database recovery area.
The flash recovery area may contain the following files:
■ Datafile copies You can make copies of the database datafiles using the new
RMAN command BACKUP AS COPY. You can use this command to create
image copies of all datafiles, which the RMAN will automatically store in the
flash recovery area.
■ Control file autobackups The flash recovery area serves as the default
location for all control file autobackups made by the RMAN. The database
places any control file backups it generates in the flash recovery area.
■ Archived redo log files Since Oracle automatically deletes all obsolete files
and files that have been transferred to tape, the flash recovery area is an ideal
location for archived redo log files. You don’t need to manually delete the old
archived redo log files, because Oracle will automatically delete the files if
you store them in the flash recovery area.
■ Online redo log files Oracle recommends that you save a multiplexed copy
of your online redo log files in the flash recovery area. Oracle will generate its
own names for the online redo log files. The default size of an online redo file
that’s created in the flash recovery area is 100MB. The following statements
can create online redo logs in the flash recovery area: CREATE DATABASE,
ALTER DATABASE ADD LOGFILE, ALTER DATABASE ADD STANDBY
LOGFILE, and ALTER DATABASE OPEN RESETLOGS.
■ Current control files Oracle also recommends that you store a multiplexed
current control file in the flash recovery area.
■ RMAN files If you specify a location for the flash recovery area by using
the DB_RECOVERY_FILE_DEST initialization parameter, the RMAN
will, by default, use the flash recovery area for storing its backup-related files.
Oracle will also automatically use OMF files and will generate the filenames.
As noted, Oracle saves all control file backups and autobackups made by the
RMAN in the flash recovery area as well.
■ Flashback logs Oracle stores all flashback logs in the flash recovery area. If you
enable the flashback database feature (discussed in Chapter 9), Oracle copies
images of each altered block in every datafile into flashback logs stored in the
flash recovery area. The database will use these flashback logs to reconstruct
the datafile contents as of any moment at which it captured the logs.
Oracle calls the multiplexed redo log files and control files in the flash recovery
area permanent files, since they should never be deleted and are part of the live
database. Oracle terms all the other files in the flash recovery area (recovery-
related files) transient files, since Oracle will delete them eventually after they
have become obsolete or have already been copied to tape.
The background process Archiver (ARCn) automatically creates a copy of all

archived redo logo files in the flash recovery area if you specify the flash recovery
area as the archive log destination. You can specify the flash recovery area as the
destination for your archived redo log files by using the LOG-ARCHIVE_DEST_10
parameter. If you create a flash recovery area and do not set any other local archiving
destinations, LOG_ARCHIVE_DEST_10 is implicitly set to the USE_DB_RECOVERY_
FILE_DEST. (That is, archived redo log files will be sent automatically to the flash
recovery area location.)
If you’ve also configured other archive log locations by using the LOG_ARCHIVE_
DEST_n parameter, Oracle will also place copies of archived redo logs in those other
locations. In the following example, I turned on archiving for the database nina without
configuring an explicit archive log location. On issuing the ARCHIVE LOG LIST
command, this is what I got:
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 825
Next log sequence to archive 827
Current log sequence 827
SQL>
I am using a flash recovery area for the database nina. The USE_DB_RECOVERY_
FILE_DEST location for the archive logs points to the flash recovery area for the
database, which is the C:\Oracle\Product\10.1.0\flsh_recovery_area\nina\ directory
on my Windows XP server.
Sizing the Flash Recovery Area

How large should your flash recovery area be? Oracle recommends that your flashback
area size be equal to the sum of the size of your database, any incremental backups that
you may have made, and all the archived redo logs on disk. If you have a 100GB sized
database, and you have about forty 0.5GB sized redo logs on disk, your flash recovery
area needs more than 120GB of space. Your flash recovery area should be large enough
for you to save a set of the following files:
■ A copy of all datafiles

■ Incremental backups
■ Online redo logs
■ Archived redo logs not yet backed up to tape
■ Control files
■ Control file autobackups (these will include copies of the control file
and the SPFILE)
Note that this list includes both online redo log files and control files. Oracle
recommends that you save both a duplexed redo log file and a current control file in
your flash recovery area, along with all the other recovery-related files (database file
copies and the archived redo log files).
At the minimum, Oracle recommends that you keep the archived logs not yet
saved to tape in the flash recovery area.
The size of your database, of course, will be the main determinant of the size
of the flash recovery area. The size of the flash recovery area also depends on the
following factors:
■ Your RMAN backup retention policy

■ The type of storage device you are using for your backups (tape and disk or
just a disk device)
■ The amount of data block changes in your database
Creating a Flash Recovery Area

You can create a flash recovery area in several ways:
■ You can configure the flash recovery area during database creation using the
Database Creation Assistant (DBCA).
■ You need to configure two initialization parameters to configure a flash
recovery area. Since these initialization parameters are dynamic, you can
also create a flash recovery area while the database is running.
■ Of course, you can also use the OEM Database Control to configure a flash
recovery area.
Configuring a Flash Recovery Area

You use the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_
SIZE initialization parameters to configure a flash recovery area in your database.
The DB_RECOVERY_FILE_DEST parameter specifies the location of the flash
recovery area, such as the /u01/App/Oracle/flsh_rcv directory.
When you use the DB_ destination. Oracle will actually let you use
RECOVERY_FILE_DEST parameter to a file server device for the flash recovery
specify the destination of your flash area, provided that it is one that has
recovery area, you can use a directory, been verified by the Oracle Storage
file system, or ASM disk group as your Compatibility Program.
The DB_RECOVERY_FILE_DEST_SIZE parameter specifies the maximum size

of the flash recovery area. Note that the database isn’t going to assign or allocate this
space to the flash recovery area immediately. If you assign a 2GB chunk of file space
to the flash recovery area, Oracle will use this space when it needs to store new files
in it. If no files are stored in the flash recovery area, all the space allocated to it
remains under the control of the operating system, although the space is technically
assigned to the flash recovery area.
You must first specify the DB_RECOVERY_FILE_DEST_SIZE parameter

before you can specify the DB_RECOVERY_FILE_DEST parameter.
Dynamically Defining the Flash Recovery Area

You can dynamically create or modify the flash recovery area using the two initialization
parameters DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE
in the following manner:
SQL> alter system set
2* db_recovery_file_dest_size = 2G scope=both
System altered.
2 db_recovery_file_dest = 'C:\oracle\recovery_area' scope=both;
System altered.
SQL>
You must always specify the size parameter, DB_RECOVERY_FILE_DEST_SIZE,

before specifying the location parameter, DB_RECOVERY_FILE_DEST. Also, make
sure that you first create the specific flash recovery area directory (in this example,
it is the recovery_area directory) before using the DB_RECOVERY_FILE_DEST
parameter.
The SCOPE=BOTH clause ensures that any changes you make will be applicable
immediately, in addition to being written permanently to your SPFILE.
The flash recovery area and DB_RECOVERY_FILE_DEST location are

synonymous.
Disabling the Current Flash Recovery Area

You can disable the current flash recovery area by setting the DB_RECOVERY_FILE_
DEST parameter to blank (''), which has the effect of unsetting the current destination
for the flash recovery area files. Note that you can use the V$RECOVERY_FILE_
DEST view to check the location of the flash recovery area. The following example
illustrates how you can disable your flash recovery area.
SQL> select name from v$recovery_file_dest;
NAME
---------------------------
C:\oracle\recovery_area
2 db_recovery_file_dest = '';
System altered.
SQL> select name from v$recovery_file_dest;
NAME
---------------------------
SQL>
Note that even after you disable the flash recovery area, the RMAN will continue
to access the files located in the flash recovery area for backup and recovery purposes.
However, the RMAN won’t have access to the automatic space management features
of the flash recovery area.
Default File Location and the Flash Recovery Area

Using the flash recovery area implies that you are using OMF. If you are configuring
a flash recovery area in your database, you can’t use the usual LOG_ARCHIVE_DEST
and LOG_ARCHIVE_DUPLEX_DEST parameters to specify redo log archive destinations.
You must instead use the newer LOG_ARCHIVE_DEST_n parameters. When you use
OMF files, Oracle determines the default location for the datafiles, control files, and
redo log files, based on the values of the initialization parameters DB_CREATE_FILE_
DEST and DB_CREATE_ONLINE_LOG_DEST_n, which determine the location of
all OMF files. When you create the flash recovery area on top of the OMF files, the
default location of the control files and redo log files will be based on your choice among
the two initialization parameters, as well as a third parameter that specifies the location
of the flash recovery area. This additional parameter is the new DB_RECOVERY_FILE_
DEST parameter.
Thus, the three important initialization parameters—DB_CREATE_FILE_DEST,
DB_CREATE_ONLINE_LOG_DEST_n, and DB_RECOVERY_FILE_DEST—
determine where and how many control files and redo log files Oracle will create when
you use a flash recovery area built on top of an OMF-based file system. I summarize the
various possibilities in the following sections.
Oracle Corporation recommends that your DB_RECOVERY_FILE_DEST

location not be the same as the DB_CREATE_FILE_DEST location or any
of the DB_CREATE_ONLINE_LOG_DEST_n locations.
Control Files
If you set the CONTROL_FILE parameter manually in your initialization file before
starting the instance to create a new database, Oracle will create the control files in
that location. If you haven’t set the CONTROL_FILES parameter, Oracle will create
the control files in various default locations, according to the following rules:
■ If you specify the DB_CREATE_ONLINE_LOG_DEST_n parameter, Oracle

will create an OMF-based control file in n number of locations, with the first
directory holding the primary control file.
■ If you specify the DB_CREATE_FILE_

DEST and DB_RECOVERY_FILE_DEST
parameters, Oracle will create an OMF-
If the database creates an
based control file in both of these locations.
OMF control file, and it is using a server
parameter file, then the database sets the ■ If you just specify the DB_RECOVERY_
CONTROL_FILES initialization parameter FILE_DEST parameter, Oracle will create
in the server parameter file. an OMF-based control file in the flash
recovery area only.
■ If you omit all three of the initialization parameters, Oracle will create a non-
OMF-based control file in the system-specific default location.
Redo Log Files

If you omit the LOGFILE clause during database creation, Oracle will create the redo
log files according to the following rules:
■ If you specify the DB_CREATE_ONLINE_LOG_DEST_n parameter, Oracle

will create an online redo log member in n number of locations, up to the
MAXLOGMEMBERS limit for the database.
■ If you specify the DB_CREATE_FILE_DEST and DB_RECOVERY_FILE_
DEST parameters only, Oracle will create an online redo log member in both
of these locations up to the MAXLOGMEMBERS limit for the database.
■ If you just specify the DB_RECOVERY_FILE_DEST parameter, Oracle will
create an online redo log member in the flash recovery area only.
■ If you omit all three initialization parameters, Oracle will create a non-OMF
online redo log file in the system-specific default location.
Backing Up the Flash Recovery Area

When you configure the flash recovery area, the RMAN will automatically place its
backup files in that area. Oracle will use the OMF files and automatically generate the
filenames itself. Before going further, let’s clarify the difference between the two ways
you can store database backups using RMAN:
■ Image copies These are identical to your normal operating system file copies.
Image copies are byte-by-byte copies of Oracle database files. However, the
big difference between the copies made by the operating system and the RMAN
image copies is that the RMAN records information about its image copies
in the RMAN repository. Since you can’t use a backup unless it is part of
the RMAN recovery catalog, you can’t use normal operating system backup
copies inside RMAN.
■ Backup sets These are logical entities, consisting of individual components
(files) called backup pieces. Backup pieces store the contents of one or several
Oracle database files. You can’t access the backup pieces on an individual
basis; you must access them as part of a backup set.
You can back up the flash recovery area itself by using simple RMAN backup
commands. In order for the commands to work, you must set CONFIGURE BACKUP
OPTIMIZATION to ON. You can back up the flash recovery area only to a tape
device using these backup commands.
The RMAN command BACKUP RECOVERY AREA backs up all flash recovery
files in the current or previous flash recovery area destinations. This command will
back up only those files that have never been backed up to tape before. The files
that the command will back up include full backups, incremental backups, control
file autobackups, archive logs, and datafile copies.
The RMAN command BACKUP RECOVERY FILES command backs up all the
files that the BACKUP RECOVERY AREA command does, but from all areas on your
file system, not just from the flash recovery area.
Neither of the two area, such as the current control file and
commands, BACKUP RECOVERY AREA or the current redo log file. These commands
BACKUP RECOVERY FILES, will back up will also not back up the flashback logs.
any permanent files in the flash recovery
You can use the RMAN command BACKUP RECOVERY FILE DESTINATION
to move disk backups created in the flash recovery area to tape.
Managing the Flash Recovery Area

There really isn’t a whole lot you need to do in the way of managing the flash recovery
area. You must take care to size the flash recovery area large enough so there is no space
pressure in that area. Let’s first discuss how the flash recovery area manages its space,
and then see the dictionary view that helps you manage the flash recovery area.
Space Management
Once you create the flash recovery area, Oracle will start storing recovery-related files
in that area, until it uses up all the space you allocated to the flash recovery area.
Whenever you add a new file to the flash recovery area, Oracle automatically updates
its list of backup files that are candidates for deletion. This list consists of those files
that either have been backed up to tape or are obsolete as per your retention rules.
Oracle automatically deletes files on this list when it needs space for incoming new
recovery-related files.
When the flash recovery area runs low on space and it can’t delete any files to
relieve the space pressure, Oracle issues an automatic warning alert, once the flash
recovery are is 85 percent full. When the area uses up 97 percent of its space, Oracle
will send a critical alert. Oracle sets these warning and critical thresholds, and you
can’t change them.
Oracle will add entries to both your alert log file and the DBA_OUTSTANDING_
ALERTS view to mark any flash recovery area space alerts. Oracle will continue to
place new recovery-related files in the flash recovery area, until it hits the 100 percent
space usage barrier, at which point it will issue an error stating that your flash recovery
area is out of room.
If you ever receive the out-of-space warning and critical alerts because of space
pressure in you flash recovery area, you have the following options:
■ Consider changing your backup retention and archive log retention policies.
■ Increase the size of the DB_RECOVERY_FILE_DEST_SIZE parameter to
allocate more space to your current flash recovery area.
■ Use the BACKUP RECOVERY AREA command in the RMAN to back up the
contents of the flash recovery area to a tape device.
■ Use the RMAN to delete unnecessary backup files. The RMAN commands
CROSSCHECK and DELETE EXPIRED come in handy during this deletion
process.
Note that if the database can’t archive any redo log files because the flash
recovery area is full, the database will hang, as it always does when your traditional
archive destination fills up.
Data Dictionary Views

The V$RECOVERY_FILE_DEST view is the main source to help you manage the
flash recovery area. This view contains information about the flash recovery area.
Here’s its structure:
SQL> desc v$recovery_file_dest

Name Null? Type
----------------------------------------- -------- ---------------------
NAME VARCHAR2(513)
SPACE_LIMIT NUMBER
SPACE_USED NUMBER
SPACE_RECLAIMABLE NUMBER
NUMBER_OF_FILES NUMBER
SQL>
In the v$recovery_file_dest view, the SPACE_LIMIT column tells you

how much space has been allocated to the flash recovery area (by the DB_RECOVERY_
FILE_DEST_SIZE parameter). The SPACE_RECLAIMABLE column tells you
how much space you can reclaim by getting rid of obsolete and redundant files in
the flash recovery area.
A new column, named IS_RECOVERY_DEST_FILE, has been added to the
V$LOGFILE, V$CONTROLFILE, V$ARCHIVED_LOG, V$DATAFILE_COPY,
and V$BACKUP_PIECE views. The column can take a value of YES or NO. If the
column value is YES, that means that the respective file in that view is in the flash
recovery area.
Moving the Flash Recovery Area

If you need to move your flash recovery area to a different location, you can do so by
using the DB_RECOVERY_FILE_DEST initialization parameter, as in this example:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/u01/app/oracle/new_
area' SCOPE=BOTH;
Oracle will immediately start creating all the new flash recovery area files in your
new flash recovery area location.
You can leave the permanent files (control files and online redo log files), flashback
logs, and transient files in their original location. Eventually, Oracle will delete all
the transient files from the previous flash recovery area location, when each of them
become eligible for deletion. However, if you want to move your current permanent
files, transient files, or flashback logs to the new flash recovery area, you can do so by
using the standard file-moving procedures.
Using Incremental Backups

A full backup includes every block in the datafiles. Incremental backups capture only
those data blocks that have changed since the last backup. Incremental backups help
you avoid spending huge amounts of time and resources that you’ll need for performing
frequent full database backups. The RMAN can perform an incremental backup at
the database, tablespace, or datafile level. In Oracle Database 10g, there are several
enhancements pertaining to incremental backups. The main enhancements are the
ability to recover with incrementally updated backups and the fast incremental backup
capability. Let’s first look at how you can reduce recovery time by using incrementally
updated backups.
Recovering with Incrementally Updated Backups

Oracle Database 10g gives you the ability to recover databases using incrementally
updated backup files. Currently, the standard operating procedure is for you to apply
archived redo logs to your datafile backup copies in order to perform a media recovery.
For example, if your database needs a recovery on Friday and your last backup was done
on Sunday night, you must apply all the archive logs that your database generated
since Sunday night.
In Oracle Database 10g, you can apply incremental backups to your datafile image
copies when you use the RMAN. This application of incremental backups to image
copies enables you to roll forward or recover the image copy to a specified point in
time. Here’s how this efficient recovery strategy works:
1. Apply the incremental backups to datafile image copies. Use the RECOVER
COPY OF DATAFILE command of the RMAN to perform the recovery. This
will update all of your datafile image copies, all the way up to the system change
number (SCN) in the latest incremental backup. The RMAN will treat this
updated datafile image copy as a normal datafile image copy.
2. Then apply the archive logs since the last incremental backup only. Apply
these archive logs to the updated datafile image copies. Note that here is where
the incrementally updated backups provide their value, since you don’t need
to apply all the archive logs since the last backup, but only those logs since the
last incremental backup! You don’t need to perform a full image copy after
incrementally restoring your database files.
Using Incremental Backups 15
Incremental backups help only data block changes, and that is always
restore datafiles by applying changes at the much faster than applying individual
database block level. Archived redo logs transactions. Thus, Oracle prefers that
apply changes at the transaction level. you use incremental backups over archived
Incrementally updated backups lead to a logs during a recovery, whenever you have
faster recovery, since you need to apply a choice.
If you have incremental backups available, along with the archived redo logs,
the RMAN will always choose incremental backups over archived redo logs during
recoveries, because it is a much faster way to recover your database. However, note
that for a level 0 incremental backup, Oracle may not choose incremental backups
over the archived redo logs.
Oracle recommends that you make whole backups of your database regularly,
and make daily (or more frequent) incremental backups. You must retain all
of these backups on disk. You can then perform a quicker full database or
point-in-time recovery using the incrementally updated backup approach,
and make minimal use of the slower archived log-based recovery technique.
Thus, during a recovery, the incremental backups will have already been applied,
and the only archive logs needed will be those since the last incremental backup.
You can always restart the recovery process, if the process fails while it is applying
the incremental backup files to the datafile image copies. If you have multiple versions
of an image copy in the RMAN catalog, the RMAN will automatically use the latest
version. If there are overlapping incremental backups, the RMAN will choose the one
covering the longer period.
Fast Incremental Backups

During an incremental backup, Oracle must scan the entire datafile, even if only a
very small part of the file has changed. This makes for unnecessarily long incremental
backup times. Oracle Database 10g contains enhancements that help you make much
faster incremental backups.
Oracle Database 10g maintains a new file, the change tracking file, to track the
physical location of all database changes. The RMAN simply reads this file to
find out which data blocks to read and copy during an incremental backup process.
Thus, RMAN avoids needing to read entire datafiles during incremental backups,
and your backup times are dramatically shorter than before.
A new background process, the change tracking writer (CTWR), is in charge of

writing the block change information to the change tracking file. The size of the
change tracking file will depend on the size of the database, the amount of DML
activity, the number of old backups maintained by the change tracking file, and
the number of active instances, if you are using Real Application Clusters (RAC).
Oracle recommends that you place the change tracking file on the same disks
as the datafiles.
Enabling Block Change Tracking

Oracle Database 10g doesn’t track block changes by default. You must explicitly enable
the feature, by using the following command:
SQL> alter database
2 enable block change tracking
3 using file 'C:\ORACLE\RECOVERY_AREA\CHANGETRACK.LOG';
Database altered.
SQL>
If you store the change tracking file along with you database files, the file will be
deleted automatically when you disable block change tracking. You can rename or
relocate a change tracking file by using the ALTER DATABASE RENAME FILE
command, as shown here:
SQL> alter database rename file
2 'C:\ORACLE\RECOVERY_AREA\CHANGETRACK.LOG'
3* to 'C:\ORACLE\NEWCHANGE.LOG';
You must make sure that your database is in the mount stage before you can
rename the change tracking file.
You may disable block change tracking by using the following command:
SQL> alter database disable block change tracking;
Database altered.
SQL>
The change tracking file increments. The file’s size depends on your
contains the physical location of all database size, number of instances in an
database changes. The minimum size is RAC, and the number of old backups the
10MB. Oracle creates the file automatically file maintains.
and allocates additional space in 10MB
Enhanced RMAN Commands 17
Monitoring Block Change Tracking

You can monitor the block change tracking feature in your database (as noted in the
previous section, this feature is turned off by default) by using the V$BLOCK_CHANGE_
TRACKING and V$BACKUP_CONTROLFILE views.
The V$BLOCK_CHANGE_TRACKING view shows the name, size, and status of
your change tracking file, as shown in this example:
SQL> select filename, status, bytes
2 from v$block_change_tracking;
FILENAME STATUS BYTES
-----------------------------------------------------------------
C:\ORACLE\RECOVERY_AREA\CHANGETRACK.LOG ENABLED 11599872
SQL>
You can use the V$BACKUP_DATAFILE view to see how the block change
feature is helping you minimize the file scanning done by the incremental backup
process. You can use the ratio between the value of the BLOCKS_READ column
and the DATAFILE_BLOCKS column to figure out the percentage of blocks Oracle
is reading in order to perform its incremental backups. If the BLOCKS_READ/
DATAFILE_BLOCKS ratio is too high, you may need to take more frequent
incremental backups to reduce the ratio.
Enhanced RMAN Commands

Oracle Database 10g has several new RMAN commands, and some older commands
have been deprecated. You’ll also find some enhancements in the RMAN scripting
feature. Let’s review these changes, starting with the BACKUP AS COPY command.
Using the BACKUP AS COPY Command

The RMAN COPY command has been deprecated in Oracle Database 10g. The new
command that replaces it is BACKUP AS COPY. In the older backup commands, when
you created a backup set, you needed to use RMAN later on to extract individual
datafiles from the backup set. The new BACKUP AS COPY command creates image
copies, so you don’t need to extract them from a backup set. Using a single BACKUP
AS COPY command, you can now copy all of the following:
■ A database
■ One or multiple tablespaces
■ One or multiple datafiles
■ One or more multiple archived redo logs
■ One or more control files
You can use the BACKUP AS COPY command to create image copies of datafiles,
as shown here:
RMAN> BACKUP AS COPY DATABASE;
If you want RMAN to create image copies by default, use the following RMAN
configuration command:
RMAN> configure device type disk
2> backup type to copy;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1;
new RMAN configuration parameters are successfully stored
released channel: ORA_DISK_1
RMAN>
To create a backup set, rather than an image copy, you can use the following
command:
RMAN> backup as backupset database;
Performing Backups
You can back up various database elements as follows:
■ Entire database backup You can now perform an image file backup of the
entire database, by using the following command:
RMAN> backup database;
■ Previous database image copy If you wish to back up a previous image copy
of all the database files and control files in your database, use the following
command:
RMAN> backup copy of database;
■ Tablespace You can back up all datafiles belonging to a tablespace by using

the following command (USERS is the tablespace in this example and the
next one):
RMAN> backup tablespace users;
■ Previous tablespace image copy If you want to make a backup of a previous

image copy or a backup set of a tablespace, you can do so by using the following
command:
RMAN> backup copy of tablespace users;
■ Single datafile You use the following command to perform a backup of a

single datafile (datafile 10 in this example):
RMAN> backup datafile 10;
■ Previous datafile backup The following command backs up a previously

backed up datafile:
RMAN> backup copy of datafile 10;
■ Current control file To back up a current control file, use the following
command (equivalent to the SQL command ALTER DATABASE BACKUP
CONTROLFILE):
RMAN> backup current controlfile;
■ Previous control file copies In order to copy all the previously made control
file copies, use the following command.
RMAN> backup controlfilecopy all;
The output of a backup command may be an image copy or a backup set,

depending on whether your CONFIGURE DEVICE TYPE DISK BACKUP TYPE
parameter is set to COPY or BACKUPSET.
Using the CATALOG Command

In Oracle Database 10g, you can issue the CATALOG command to make the RMAN
start cataloging backup files immediately. You can use the command when you are
searching for new files or when you want to let the RMAN know that you are using
a new backup directory.
The CATALOG command has the following syntax:
RMAN> catalog backuppiece 'filename';
Instead of the keyword BACKUPPIECE, you can use the keyword DATAFILECOPY, if you
are cataloging an image copy of a datafile instead of a backup piece from a backup set.
Here is an example of the use of the CATALOG command:
RMAN> catalog datafilecopy “C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\
NINA\DATAFILE\01_MF_SYSAUX_OGOGDVDC_.DBF”;
catalogued datafile copy
datafile copy
filename= C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\
NINA\DATAFILE\01_MF_SYSAUX_OGOGDVDC_.DBF recid=4 stamp=530016304
RMAN>
You can also use the reverse command, UNCATALOG, to get rid of a backup piece
from the RMAN catalog, as shown here:
RMAN> change backuppiece 'file_name' uncatalog;
The following example uncatalogs the datafile copy cataloged in the previous
example:
RMAN> change datafilecopy
"C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\
NINA\DATAFILE\01_MF_SYSAUX_OGOGDVDC_.DBF" UNCATALOG;
Uncatalogued datafile copy
datafile copy
filename= C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\
NINA\DATAFILE\01_MF_SYSAUX_OGOGDVDC_.DBF recid=4 stamp=530016304
Uncatalogued 1 objects
RMAN>
Let’s say you suspect that there are some

backup files in various directories that aren’t
yet a part of the RMAN catalog. Some of the
If you eliminate all backup filenames may be hard to remember, since they
pieces from the RMAN catalog, the RMAN may be OMF-based files. Instead of worrying
will remove the backup set information about where all the backup files might be, you
as well. can simply ask the RMAN to search in a certain
directory for all backup files that aren’t part of
the catalog already. You use the CATALOG START WITH command to perform this
job, as shown in the following example.
RMAN> catalog start with
2> "C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\NINA\DATAFILE";
searching for all files that match the pattern C:\ORACLE\PRODUCT\10.1.0\
FLASH_RECOVERY_AREA\NINA\DATAFILE
List of Files Unknown to the Database
=====================================
File Name: C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\NINA\DATAFILE\
O1_MF_SYSAUX_0G0GDVDC_.DBF
Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\NINA\DATAFILE\
O1_MF_SYSAUX_0G0GDVDC_.DBF
RMAN>
The CATALOG START WITH command comes in very handy if you happen to
lose your RMAN recovery catalog. In earlier releases, there was no way to tell the
RMAN about a backup set. This was a complete showstopper for many DBAs. If
your recovery catalog was destroyed, even though all the backup sets were perfect
and you knew exactly where they were and what was in them, there was no way to
tell a newly created catalog to use them. Now you can just point it at the tape library
and let it find everything. This is an important and long overdue enhancement.
Enhancements in RMAN Scripts

There are two important enhancements in the RMAN scripting feature. The first is the
convertibility of text files into stored scripts and vice versa. The second is the shareability
of RMAN scripts among databases.
Convertibility of RMAN Scripts

The RMAN lets you use scripts to perform backups and recovery, to save you the drudgery
of typing the commands in repeatedly, using the command line. RMAN offers you two
kinds of scripts: stored scripts and text scripts. Stored scripts are stored in the RMAN
recovery catalog, and the text scripts are kept in regular text files. Stored scripts offer
the advantage that any user who logs in to RMAN can access them easily, comparing
to accessing the text files, which may be stored anywhere.
In previous versions of Oracle, you couldn’t convert a text script into a stored
script and vice versa. In Oracle Database 10g, this limitation goes away: you can
now change a stored script into a text script and a text script to a stored script.
Here’s an RMAN command that sends the contents of a stored script to a text file:
RMAN> print script full_backup to file 'my_script_file.txt';
Global RMAN Scripts

In previous Oracle versions, you could execute a stored script only if you were connected
to the target database where the script was originally created, thus making the scripts
local in nature. Oracle Database 10g enhances stored scripts by providing the new
concept of global scripts, which you can execute against any database registered in the
recovery catalog, as long as your RMAN client is connected to the recovery catalog
and a target database simultaneously.
Multiple databases can share the same RMAN scripts, provided the databases
connect to the database with the RMAN catalog. Of course, you must use the RMAN
recovery catalog in order to use this feature.
The following two statements show the syntax for creating a local and a global
script, respectively.
RMAN> create script full_backup
{
backup database plus archivelog;
delete obsolete;
}
RMAN> create global script global_full_backup
{
backup database plus archivelog;
delete obsolete;
}
The EXECUTE SCRIPT command will let you execute a global or local script,
as shown here:
RMAN> run { execute script full_backup; }
The following PRINT SCRIPT command prints out your global scripts.
RMAN> print global script full_backup;
Miscellaneous Backup and Recovery Enhancements

This section briefly covers miscellaneous enhancements in the database backup and
recovery area. Some of the enhancements apply to the RMAN interface only, and
some apply to both the RMAN and user-performed backup and recovery.
Miscellaneous Backup and Recovery Enhancements 23
Using the Database Control to Configure Backups

To use the OEM Database Control to configure your backup procedures, on the
Database Control home page, click the Maintenance tab. In the Backup/Recovery
region of the Maintenance page, choose Configure Backup Settings. You can use
one of the following choices to tell RMAN where to place its target files:
■ In the location you specify for the FORMAT option in a backup command
■ In the location you specify with the CONFIGURE CHANNEL FORMAT option
■ In the location you specify for the DB_RECOVERY_FILE_DEST (flash
recovery area) parameter
If you don’t use any of these alternatives, the backup files will go into an operating
system-specific default directory.
Automatic Channel Failover

If one of the channels on which the RMAN is performing a backup fails, the RMAN
will automatically try to use an alternative channel, provided you are using multiple
channels. The backup process will continue without a hitch, although the RMAN
reports the channel problem in the log files and saves the information in the V$RMAN_
OUTPUT view.
Implementing Fast Recovery

During a normal recovery process in previous versions, you needed to restore the
backup files first, before starting the recovery process. In Oracle Database 10g, you can
use the backup files directly during a recovery process, instead of needing to restore
them first. You can still perform the traditional restore/recovery in the RMAN, by
using the RESTORE DATABASE command. However, for those special times when
you really need a fast recovery, Oracle Database 10g offers the SWITCH DATABASE
command.
The SWITCH DATABASE command doesn’t restore your backup files from the
backup location. The RMAN simply adjusts the pointers for the datafiles in the
control file, so they now point to the backup files in your flash recovery area. Thus,
RMAN will convert the backup files into the current datafiles, and then start the
recovery process with these files.
You must use image copies rather than backups sets in order to utilize the
fast recovery process with the SWITCH DATABASE command.
The SWITCH DATABASE command is straightforward:

RMAN> switch database to copy;
Since you don’t need to copy any files, only rename the recovery files, the recovery
process is very fast. However, it comes with a price: you need to make sure that you
have additional backups made as soon as possible, to make up for the fact that you have
used up one of your backups to recover your database.
Recovering Datafiles Without Backups

If you lose a datafile and it turns out that you don’t have a backup, you can still use
the RMAN to recover that datafile. You must, however, have a copy of the control
file with references to the lost datafile, since RMAN needs the information from the
control file to recover the datafile. In addition, you must have all the archived redo
log files from the time the datafile was lost, up to the time you want to recover.
The ability to recover a file that has never been backed up has always been available
from SQL*Plus, with the help of the CREATE DATAFILE X AS Y statement. Now,
in Oracle Database 10g, you can create the lost file as part of an RMAN RESTORE
DATABASE command.
Compressed Backups
Oracle Database 10g lets you compress RMAN backups to save on storage. However,
there is a cost to the compression feature: your recovery times will be longer when you
use compressed backup sets, since there is now the additional step of uncompressing the
backup sets before starting the recovery. Nevertheless, all recovery procedures remain
the same when you use a compressed backup set. The compression factor will depend
on the nature of the data in your datafiles. Oracle recommends using this in preference
to an external compression utility, and you certainly shouldn’t use both utilities together.
You can compress only a to a minimum of 10.0.0. You can’t compress

database that’s using the Oracle Database an image copy; you can compress a backup
10g version server software. You must set only if you are using backup sets.
the COMPATIBLE initialization parameter
Here is the RMAN command that lets you compress a backup set:
RMAN> backup as compressed backupset database;
RMAN disables backup compression by default. If you want to make backup

compression the default mode, you may do so by using the following command.
RMAN> configure device type disk parallelism 4
2> backup type to compressed backupset;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters are successfully stored
released channel: ORA_DISK_1
RMAN>
The V$BACKUP_FILES view contains information on backup filenames and file

sizes, and will also tell you about the compression status of the files. Here’s a simple
query that shows the size of a file, as well as whether RMAN will compress the file
during a backup:
SQL> select fname, compressed, backup_type
from v$backup_files;
Simplified Recovery Through RESETLOGS

When you perform an incomplete recovery or a recovery using a backup control file,
you must open the database with the RESETLOGS option. The RESETLOGS option
reinitializes the redo log files, and thus changes the database incarnation. You’ll start
a new sequence of redo logs after using the RESETLOGS option to open the database.
In previous versions of Oracle, this meant that you couldn’t use any backups from the
previous incarnations (before the RESETLOGS operation) to recover the database. This
is why you needed to perform a whole database backup immediately after a RESTLOGS
operation.
In Oracle Database 10g, you can use backups taken before an incomplete recovery
operation; that is, you can use backups from older incarnations of the database. So,
you don’t need to make a full backup after you use the RESETLOGS option. You can
perform an incomplete recovery with the RESETLOGS option and immediately open
the database, thereby substantially reducing your downtime following a media problem.
Since you can use older archived redo logs created prior to using the RESETLOGS
option, you may now end up with situations where there may be multiple archived
logs from various database incarnations with identical sequence numbers. In order to
distinguish the archived redo logs from several database incarnations, Oracle
Database 10g uses a new format for the archived redo log files. The initialization
parameter LOG_ARCHIVE_FORMAT uses a text string and a set of variables to
specify the default archive log format. Oracle applies the string generated by using
this format to the string generated from the LOG_ARCHIVE_DEST parameter to
come up with the complete path and filename for archived redo log files.
Previously, you used the following format for the LOG_ARCHIVE_FORMAT
parameter to specify the archived redo log format:
LOG_ARCHIVE_FORMAT="log%t_%s.arc"
In this format specification, the variable t stands for thread number, and the variable
s stands for the log sequence number.
The new archive redo log format in Oracle Database 10g is of the following form:
LOG_ARCHIVE_FORMAT="log%t_%s_%r.arc"
In the new archive log format, there is an

additional variable r, which stands for the
RESETLOGS identifier.
The change in the LOG_
The V$DATABASE view contains several
ARCHIVE_FORMAT initialization parameter
additional columns to help you manage information
enables the new feature of a recovery
regarding all RESETLOGS operations. These
through RESETLOGS.
columns include RESETLOGS_CHANGE#,
RESETLOGS_TIME, and RESETLOGS_ID.
The V$LOG_HISTORY and V$OFFLINE_RANGE views provide information about
redo logs belonging to different database incarnations. Here’s a simple query on the
V$LOG_HISTORY view:
SQL> select sequence#, resetlogs_change#,
2* resetlogs_time from v$log_history;
SEQUENCE# RESETLOGS_CHANGE# RESETLOGS
---------- ----------------- ---------
831 318842 23-MAR-04
832 318842 23-MAR-04
833 318842 23-MAR-04
…
454 rows selected.
SQL>
Dropping a Database
Sometimes, you may want to drop test database or drop your old database after you
successfully migrate to a new version of Oracle. It’s very easy to drop an Oracle
Database 10g database. You can use the new command DROP DATABASE to remove
a database, in both the RMAN as well as the SQL*Plus interface. You may also use
the DBCA to drop the database.
Here is how you drop a database in the RMAN:
RMAN> drop database;
In SQL*Plus, you use an identical command:

SQL> drop database;
Your database must be mounted EXCLUSIVE and not be open in order to use
the DROP DATABASE command, whether you’re using the RMAN or SQL*Plus
interface to drop a database. In addition, you must have SYSDBA privileges.
The DROP DATABASE Oracle automatically drops only the control

command is irrevocable—you can’t roll fields and datafiles, not the archived redo
back the command. Also, remember that log files and backup files.
Here are some features of the DROP DATABASE command:
■ Oracle will drop all control files and datafiles automatically, whether you use
the SQL*Plus, RMAN, or DBCA interface to drop a database.
■ Oracle doesn’t remove archived redo logs and backups.
■ If you are using an SPFILE, Oracle will remove it automatically.
After you drop a database, database, you need to use the following
no matter which one of the three methods RMAN command to wipe out all traces
you use (RMAN, SQL*Plus, or DBCA), of the dropped database from the RMAN
the RMAN catalog continues to list the registry:
dropped database information. Regardless
RMAN> unregister database;
of which method you use to drop a
The DROP DATABASE command removes all datafiles and control files. Oracle
doesn’t remove any backups or archived redo log files when you drop a database.
To make the RMAN remove all database backup copies as well as the archived redo
log files, you can add the INCLUDING BACKUPS clause to your DROP DATABASE
command in the RMAN, as shown here:
RMAN> drop database including backups;
Specifying Limits for Backup Duration

Sometimes, a DBA may run into a situation where a nightly backup is interfering with
the performance of a critical database job. In order to avoid major spikes in resource
use, you can dictate the database to “take it easy,” by taking a longer time to finish the
backup. The new DURATION command in the
RMAN provides this capability.
You can use the DURATION command as
The DURATION option an option for your regular backup commands,
during backups replaces the old RATE and such as BACKUP AS COPY, to specify the time
READRATE options used to modulate the (in hours and minutes) a backup job can take.
RMAN file-reading speed. You specify the DURATION clause in the backup
command in the following manner.
DURATION <hrs>:<mins> [PARTIAL] [MINIMIZE {TIME|LOAD}]
In the DURATION clause, the options work as follows:
■ PARTIAL Normally, when your database backup jobs run past the time
interval you specify through the DURATION parameter, the RMAN job errors
out and the backup is canceled. This is the RMAN’s default behavior when
it runs past any specified duration. You can override this default behavior by
specifying the PARTIAL clause, which will prevent the issuing of any RMAN
error messages.
■ MINIMIZE TIME This option tells the RMAN to “hurry up” and finish as
fast as it can.
■ MINIMIZE LOAD This option tells the RMAN to “slow down” if it is well
within its allotted time for a backup job.
You must use disks if you want to use the MINIMIZE TIME option, since you
generally want a tape backup to end as quickly as possible.
Here is a simple example illustrating the use of this very interesting clause during
a database backup:
RMAN> backup as copy

2> duration 02:00
3> minimize time database;
This BACKUP AS COPY command example specifies the following:
■ Limit the backup time to two hours (DURATION 02:00)

■ Run the backup at full speed, enabling it to possibly finish under the two-
hour limit (MINIMIZE TIME)
■ Back up the entire database (DATABASE)
Remember that the limit. The MINIMIZE TIME option gets the
DURATION clause’s PARTIAL option leads job done the fastest. The MINIMIZE LOAD
to an error if the backup exceeds its time option minimizes resource use.
Placing All Datafiles in Backup Mode

Oracle Database 10g allows you to place all datafiles in a backup mode during an online
database backup. It also enables you to take all the datafiles out of the backup mode at
the same time. Let’s look at the new backup commands for performing these tasks.
Starting the Online Backup

Previously, during an online (hot) database backup, you needed to place each tablespace
into the backup mode separately by using the BEGIN BACKUP TABLESPACE command.
In Oracle Database 10g, you don’t need to specify tablespaces individually during an
online backup. You can use the ALTER DATABASE command to specify that all datafiles
in the entire database be placed in the backup mode simultaneously. Your database
must be open and in the ARCHIVELOG mode in order to use this command. Here’s
the syntax of the command:
SQL> alter database begin backup;
You need to place the datafiles in an online backup mode only if you are
performing a user-managed recovery, in order to guarantee that any fractured
blocks can be recovered (assure consistency). You don’t need this command in
the RMAN, since an RMAN backup does not contain any fractured blocks.
If the backup process encounters any nonexistent, read-only, or offline files, Oracle
skips them, and the backup will continue. No errors are issued.
If you encounter any of the following situations, your attempt to start an online
backup will fail, with a “cannot start online backup error” message.
■ A user-managed online backup is in progress.

■ An RMAN online backup is in progress.
■ A file is in the process of being made a read-only file.
■ A file fails verification.
Ending the Online Backup

You must use the ALTER DATABASE END BACKUP command to end the online
backup. You can issue this command when the database is in a mounted or an open
state. The status of a datafile determines how the database treats that file. Here is a
summary of the relationship between file status and the END BACKUP command:
■ Offline files will cause a warning message, but the END BACKUP command
itself will complete successfully.
■ Read-only files are skipped by the database.
■ Nonexistent datafiles are also skipped.
■ You can’t use the END BACKUP command while the database is going through
an RMAN backup.
Automatic Auxiliary Instance Creation

Oracle Database 10g, like its predecessors, lets you perform a tablespace point-in-time
recovery (TSPITR) to recover from certain database errors. You may specify the previous
point in time you want to revert to by using a sequence number or an SCN.
The biggest headache in the previous Oracle versions while performing a TSPITR
was that you had to create an auxiliary database instance and remove it after finishing
the TSPITR process. Setting up the auxiliary instance was complex, making this
method of recovery unappetizing to many DBAs. In Oracle Database 10g, you don’t
need to create the auxiliary instance. Oracle will now create the auxiliary instance
and remove it after the recovery is over.
Since you are creating your auxiliary instance in the same location as your
primary database, you need to be aware of the possibility of some performance
degradation during the TSPITR operation.
You must provide the locations for all files of the auxiliary instance to the RMAN, so it
can create the instance. Here are the various ways in which you can submit the auxiliary
file location to the RMAN, ranked from the most important to the least important:
■ AUXILIARY DESTINATION
■ SET NEWNAME FOR DATAFILE
■ CONFIGURE AUXNAME FOR DATAFILE
■ DB_FILE_NAME_CONVERT
Oracle recommends that you must use the AUXILIARY DESTINATION argument
to provide the file locations for a RECOVER TABLESPACE operation.
INSIDE THE EXAM
The exam will certainly query your knowledge Expect a question on the new recovery
of the flash recovery area. You must know the technique that uses incrementally updated
relevant initialization parameters for creating backups. What command do you use to
the flash recovery area and the kinds of files recover with an incrementally updated
you can store in it. What are the differences backup? Expect some questions on the new
between recovery-related files and other files fast incremental backup feature and how you
in the flash recovery area? You may also see a enable it (by enabling block change tracking).
question on how control file and redo log file What is the change tracking file? What does
placement will depend on the combination the new CTWR background process do?
of the flash recovery area and the OMF file Know the details of the new compressed backups
destination parameters (DB_CREATE_ feature. You most certainly will face questions
ONLINE_DEST_n and DB_CREATE_ on using the simplified recovery process through
FILE_DEST). RESETLOGS. What changes in the initialization
You must understand the new RMAN parameters make this possible? You must
commands like BACKUP AS COPY and remember the commands that enable you to
RECOVER COPY OF DATAFILE. What is implement a fast recovery (SWITCH DATABASE
the new RMAN command to back up an TO COPY).
entire database? What is the command to Know the steps in dropping a database.
implement a fast recovery using RMAN? What files are removed by Oracle when you
What do the DURATION clause and issue the DROP DATABASE command?
the PARTIAL, MINIMIZE LOAD, and
MINIMIZE TIME options mean during
a backup command?
This chapter dealt with several interesting enhancements related to backup and recovery.
You were introduced to the new flash recovery area concept, which helps centralize
all your recovery-related storage efforts. You then looked at the new techniques to
reduce your incremental backup times. You also learned how to recover faster by
applying incremental backups to datafile image copies.
Several new RMAN commands were explained in this chapter, including the
BACKUP AS COPY and CATALOG commands. You also learned about the new
scripting enhancements in the RMAN.
You learned about the new SWITCH DATABASE command, which helps you cut
back on restore/recovery times in a crisis. You also learned how to compress your
RMAN backups. You learned about the enhancements that let you avoid needing
to back up your databases after a RESETLOGS operation. You also learned how you
can use archived redo logs from a previous database incarnation. You learned how to
drop the database with the DROP DATABASE command. You saw how you could use
the DURATION option to control backup windows during certain times. You also saw
how Oracle Database 10g can help you during a TSPITR operation, by automatically
creating and removing the auxiliary instance.
Two-Minute Drill 33
❑ The flash recovery area is the default storage location for all recovery-related
files.
❑ You may use an Oracle-managed directory, operating system file system, or an
ASM disk group for your flash recovery area.
❑ Oracle automatically deletes obsolete files and files that have been backed up
to tape.
❑ If you don’t use OMF files, Oracle can’t automatically delete unnecessary
recovery files from the flash recovery area.
❑ The flash recovery area contains datafile copies, control file autobackups,
archived redo log files, RMAN backup files, and flashback logs.
❑ Oracle recommends that you store a duplexed copy of the online redo log
files and the current control file in your flash recovery area.
❑ The size of the flash recovery area should be greater than the sum of the
database size, any incremental backups, and all the archived logs on disk.
❑ The size of the flash recovery area also depends on your RMAN retention
policy.
❑ You use the two initialization parameters DB_RECOVERY_FILE_DEST and
DB_RECOVERY_FILE_DEST_SIZE to configure the flash recovery area.
❑ Both the flash recovery area initialization parameters are dynamic.
❑ You must first set the DB_RECOVERY_FILE_DEST_SIZE parameter before
you can set the DB_RECOVERY_FILE_DEST parameter.
❑ You can disable the flash recovery area by using the DB_RECOVERY_FILE_
DEST parameter and setting it to a null location.
❑ You can back up the flash recovery area by using the command BACKUP
RECOVERY AREA, using the RMAN interface.
❑ The BACKUP RECOVERY FILES command in the RMAN backs up all
recovery files, irrespective of their location.
❑ Oracle sends you both warning and critical alerts when the flash recovery
area space starts to fill up.
❑ The V$RECOVERY_FILE_DEST view is your main source for information
regarding the flash recovery area.

❑ In Oracle Database 10g, you can apply incremental backups to image copies
of datafiles.
❑ Oracle prefers using the incremental backup approach to using archived logs.
❑ Oracle Database 10g maintains a change tracking file, where the change
tracking writer (CTWR) background process writes information about block
changes.
❑ The change tracking file is automatically deleted when you disable block
change tracking.
❑ The ratio between the value of the BLOCKS_READ column and the
DATAFILE_BLOCKS column, shown in the V$BACKUP_DATAFILE
view, will tell you if you should make more frequent incremental backups.

❑ The RMAN COPY command is deprecated in Oracle Database 10g.
❑ The BACKUP AS COPY command creates image copies of the database,
tablespaces, and datafiles.
❑ The CATALOG command helps you search for new files that need to be
cataloged.
❑ The UNCATALOG command lets you uncatalog items from the RMAN
recovery catalog.
❑ The CATALOG START WITH command lets you specify a directory for
RMAN to search for recovery-related files.
❑ You can convert RMAN stored scripts into text file-based scripts and vice
versa.
❑ The global scripts feature lets several databases use common scripts. You must
use a recovery catalog for this feature to work.

❑ If an RMAN channel fails during a backup, the RMAN will automatically
switch over to an alternative channel, provided you have configured multiple
channels.
Two-Minute Drill 35
❑ Using the SWITCH DATABASE command, you can recover directly from
backup files, without restoring them first.
❑ You can recover a datafile even if you don’t have a backup for it, as long as
you can get the pertinent information from the relevant control file.
❑ The RMAN lets you compress backup sets to save on space requirements.
❑ You can now recover through a RESETLOGS operation, because backups/
archives from previous incarnations are usable.
❑ The new LOG_ARCHIVE_FORMAT parameter contains a new RESETLOGS
identifier to help identify the redo logs from different database incarnations.
❑ You can now drop a database using either the RMAN or SQL*Plus interface,
with the command DROP DATABASE.
❑ When you drop a database, Oracle will remove datafiles, control files, and the
SPFILE automatically.
❑ Oracle doesn’t automatically remove the archived redo logs and backup files
when you drop a database.
❑ No matter which method you use to drop the database, you must use the RMAN
command UNREGISTER DATABASE to remove database information from the
RMAN catalog.
❑ Using the DURATION clause, you can set limits on your backup job duration.
❑ The PARTIAL option of the DURATION clause prevents errors when you
cross the time interval for a backup.
❑ The MINIMIZE TIME option of the DURATION clause will speed up your
backups.
❑ The MINIMIZE LOAD option of the DURATION clause may slow down
your backups.
❑ You can put all datafiles in the backup mode simultaneously with the command
ALTER DATABASE BEGIN BACKUP.
❑ The RMAN can now automatically create and remove the auxiliary instance
necessary during a TSPITR operation.
SELF TEST

1. Which of the following items are stored in the flash recovery area?
A. Datafiles
B. Undo segments
C. Datafile copies
D. Archived redo log files
2. When can you create a flash recovery area?
A. At database creation time
B. Anytime, since you can create it using dynamic initialization parameters
C. Only after you shut down the database and start it up in the mount state
D. Only if the database is already running
3. The DBA is running low on space and can provide only the least possible space to the flash
recovery area. The DBA should, at a minimum, have enough space in the flash recovery area
to store which of the following items?
A. Archived logs not yet saved to tape
B. Online redo log files and current control files
C. Datafile copies and archived redo log files
D. Archived redo log files
4. What happens once the DBA disables the flash recovery area?
A. The RMAN will continue to be able to access the files in the flash recovery area.
B. The RMAN will be unable to access the files in the flash recovery area.
C. The RMAN will be unable to access the automatic space management features of the flash
recovery area.
D. The RMAN can use only the automatic space management features of the flash recovery area.
5. If the DBA specifies the DB_CREATE_FILE_DEST and the DB_RECOVERY_FILE_DEST
parameters at database creation time, what will Oracle do?
Self Test 37
A. Create an OMF control file in both locations specified by the two parameters
B. Create an OMF control file in the flash recovery area only
C. Create an OMF control file in the system-specified default location
D. Create an OMF control file in the location specified by the DB_RECOVERY_FILE_DEST
parameter only

6. What does using incrementally updated backups involve?
A. The updating of archived redo log files with incremental backups
B. The direct updating of datafiles with incremental backups
C. The updating of image copies of datafiles with incremental backups
D. The updating of the control files with incremental backups
7. To apply incremental backups, which of the following commands must you use?
A. RECOVER BACKUP OF DATABASE
B. RECOVER DATAFILE
C. RECOVER COPY OF DATAFILE
D. RECOVER COPY OF DATABASE
8. Incremental backups apply changes at what level?
A. Transaction level
B. Oracle block level
C. Operating system block level
D. Datafile level
9. What does the CTWR process do?
A. Updates the incremental backups
B. Updates the change tracking file
C. Applies the database block changes
D. Checks for space in the flash recovery area
10. To enable block change tracking in your database, what must you do?
A. Use the ENABLE BLOCK CHANGE TRACKING command
B. Do nothing, since Oracle enables block change tracking by default
C. First create the change tracking file in the default location
D. First restart the database in the mount state, before creating the change tracking file

11. What can you do using the new BACKUP AS COPY command?
A. Extract image copies directly from backup sets
B. Make image copies without needing to extract them from backup sets
C. Make copies at all levels except the database level
D. Make an image copy of only a single file at a time
12. Which of the following commands backs up the entire database?
A. BACKUP DATABASE
B. BACKUP COPY OF DATABASE
C. BACKUP ALL
D. BACKUP BACKUPSET DATABASE
13. What does the RMAN CATALOG command do?
A. Helps you create image copies of datafiles
B. Helps you create image copies of current control files
C. Helps you catalog any new files that aren’t a part of the recovery catalog
D. Helps you catalog only the old files
14. What does the RMAN BACKUP CONTROLFILECOPY ALL command do?
A. Backs up all previously made control file copies
B. Backs up all control files that were never backed up before
C. Makes a copy of all current control files
D. Stores the backed up control file copies on tape
15. What happens when you uncatalog all the metadata about backup pieces from the RMAN
catalog?
A. The RMAN automatically removes the catalog.
B. The RMAN removes the backup set information from the catalog as well.
C. You can’t remove all of the backup pieces from the catalog.
D. The RMAN replaces the backup sets with image copies.

16. The DBA needs to recover the production database in the shortest time possible. What is the
DBA’s best choice?
Lab Questions 39
A. Use the RESTORE DATABASE command

B. Use the RECOVER DATABASE command
C. Use the SWITCH BACKUP command
D. Use the SWITCH DATABASE command
17. Which of the following backups can you compress?
A. Only backup sets
B. Only image copies
C. Both image copies and backup sets
D. Only single datafile copies
18. Which of the following is true about using the RESETLOGS option?
A. You don’t need to back up the database.
B. You must back up the database right away.
C. You can use archive redo logs from an older incarnation of the database.
D. You can’t use archive redo logs from an older incarnation of the database.
19. What happens when you use the DROP DATABASE command?
A. Only the datafiles, control files, and archived redo logs are removed.
B. Only the datafiles, control files, and backups are removed.
C. Only the datafiles, control files, and online redo log files are removed.
D. Only the datafiles, archived redo log files, and backups are removed.
20. Which of the following commands tells the database to slow down if it is within its allotted
time for a database backup?
A. MINIMIZE PARTIAL
B. MAXIMIZE LOAD
C. MINIMIZE TIME
D. MINIMIZE LOAD
LAB QUESTIONS
1. Show how you would drop a database using the RMAN. Show the step-by-step procedures
in detail.
2. Show how you would catalog all the files in a disk location using the RMAN.
SELF TEST ANSWERS

1. þ C and D. Oracle stores datafile copies and archived redo log files in the flash recovery
area.
ý A is incorrect since Oracle doesn’t store datafiles in the flash recovery area—it stores
datafile copies. B is incorrect since there are no undo-related files in the flash recovery area. All
undo-related information is stored in the undo tablespace.
2. þ A and B. A is correct since you can choose the flash recovery area option during database
creation when you use the DBCA tool. B is correct as well, because the initialization
parameters DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE are
dynamic parameters.
ý C is wrong since you don’t need to restart the database to create a flash recovery area. D is
incorrect because, while you can configure the flash recovery area with dynamic initialization
parameters, it doesn’t imply that you can configure the area only when the database is running.
3. þ A. Oracle recommends that, at a minimum, you must keep the archived logs not yet saved
to tape in the flash recovery area.
ý B, C, and D offer invalid recommendations.
4. þ A and C. A is correct because, even after you disable the flash recovery area, the RMAN
continues to be able to access any recovery-related files it stored in the flash recovery area. C is
correct because you’ll be unable to access the automatic space management features of the flash
recovery area if you disable the feature.
ý B is incorrect since you continue to be able to access the files even after the flash recovery
area is disabled. D is wrong since you can’t use any automatic features of the flash recovery area
after you disable it.
5. þ A. Oracle will create an OMF-based control file in both the locations.
ý B, C, and D identify the wrong locations.

6. þ C. Incrementally updated backups involve the updating of image copies of datafiles with
incremental backups.
ý A is incorrect since you never update the archived redo logs with incremental backups.
B is wrong since you never update datafiles with incremental backups—you update datafile
copies. D is wrong because you don’t update any control files with incremental backups.
7. þ C and D. To apply incremental backups, you use the RECOVERY COPY OF DATAFILE or
RECOVERY COPY OF DATABASE command.
ý A and B offer the wrong commands.
8. þ B. Incremental changes apply changes to datafiles at the Oracle block level.
ý A is wrong because it is the archived redo logs that apply changes at the transaction level.
In fact, this is why the application of block changes is much faster during a recovery. C is
wrong since it is the Oracle block level, not the operating system block level, that Oracle
applies changes to the datafiles. D is wrong since changes aren’t applied at the granularity
of a datafile, but at the granularity of an Oracle data block.
9. þ B. The CTWR process writes block change information to the change tracking file.
ý A is wrong since the CTWR process doesn’t update the incremental backups. C is wrong
since the CTWR process doesn’t apply block level changes—it merely records them. D is
wrong because the CTWR isn’t in charge of checking for space in the flash recovery area.
10. þ A. To enable block change tracking in your database, you must enable it explicitly, by
using the ENABLE BLOCK CHANGE TRACKING command.
ý B is wrong since Oracle disables block change tracking by default. C and D are wrong
because you don’t need to create any files to enable block change tracking. It is the job of
Oracle to create the change tracking file automatically when you enable block change
tracking.

11. þ B. The BACKUP AS COPY command enables you to make direct image copies of files,
without needing to extract them from backup sets as before.
ý A is wrong since you don’t need to extract image copies from backup sets anymore, once
you use this command. C is wrong because the command will make image copies at all levels,
including the database level. D is wrong since the command can make copies of one or a set of
files simultaneously.
12. þ A. The BACKUP DATABASE command backs up the entire database.
ý B is wrong since the BACKUP COPY OF DATABASE command will back up a previous
image copy of all the database and control files. C is wrong because the command is made up
to mislead you. D is wrong since the command given there has a syntax error.
13. þ C. The CATALOG command helps you recatalog the recovery area in search of new files.
ý A and B are wrong since the command doesn’t help you make copies, it only catalogs
them. D is wrong because the command isn’t limited to cataloging old files.
14. þ A. The BACKUP CONTROLFILE ALL command backs up all previously made control file
copies.
ý B and C are wrong since the command doesn’t back up the current control files, even if
they have never been backed up before. D is wrong because the command has nothing to do
with tape backup.
15. þ B. When you remove all backup pieces for a backup set, the RMAN will remove the
backup set as well from its recovery catalog.
ý A is wrong since RMAN never removes the catalog automatically. C is wrong because you
can remove all the backup pieces from the catalog. D is wrong since RMAN doesn’t replace
any backup sets with image copies.

16. þ D. The SWITCH DATABASE commands lets you recover in the shortest time possible,
because all you do is simply point the control file to the backup files instead of the old
datafiles. You can immediately start the recovery process, since there is no real restore process
involved.
ý A will perform a database restore and start the recovery process but is very time consuming
and therefore will not be the fastest way to recover. B is wrong because the RECOVER
DATABASE command needs a restore of the database files from your backup location before
you start the recovery. Thus, it takes much longer to recover with this method. C is incorrect
since it points to a nonexistent command.
17. þ A. You can compress only a backup set, not an image copy.
ý B and C are wrong because they state that you can compress image copies, which isn’t
true. D is wrong since there is no limitation that states that you can compress only single
datafile copies; you may copy entire backup sets.
18. þ A and C. A is correct since in Oracle Database 10g, you don’t need to back up your
database after a RESETLOGS operation. C is correct because you can use older archive logs
from a different incarnation.
ý B is wrong because you don’t need to back up your database after a RESTLOGS operation
in Oracle Database 10g. D is wrong since you can use older archive logs from a different
database incarnation.
19. þ B. When you use the DROP DATABASE command, all datafiles, current control files, and
backups are removed.
ý A, C, and D list the wrong sets of files that the DROP DATABASE command will cause to
be removed from your server.
Lab Answers 43
20. þ D. The MINIMIZE LOAD option tells the database to slow down if it appears that its
going to make its target interval of time.
ý A and B are wrong since MINIMIZE PARTIAL and MAXIMIZE LOAD are nonexistent
options. C is wrong because MINIMIZE TIME tells the database to work harder.
LAB ANSWERS
1. To drop a database using the RMAN, follow this procedure:
Connect to the target database through the RMAN, making sure you are using the recovery
catalog:
rman target/catalog rman/rman@testdb
Catalog all the database backups, both in the flash recovery area and in other locations:
RMAN> catalog start with '/u01/app/oracle/rcv_area'; # flash recovery
area
RMAN> catalog start with '/u09/app/oracle/arch_dest2'; # second archive
dest
Delete all backups and copies associated with the database:

RMAN> delete backupset; # deletes all backups
RMAN> delete copy; # delete all image copies (including archived logs)
Finally, drop the database and automatically unregister it from the recovery catalog:
RMAN> drop database;
2. To catalog all files in a disk location, first connect to the target database as before and provide
the RMAN with the names of the directories you want it to catalog:
RMAN> catalog start with '/u01/app/oracle/datafiles/';
The following command will catalog all files in the recovery area:
RMAN> catalog recovery area;
Color profile: Disabled
Blind Folio 9:1
9
Flashback
Technology
Enhancements
9.01 General Flashback Technology 9.04 Flashback Table

Considerations
9.05 Row Level Flashback Features
9.02 Flashback Database
9.03 Flashback Drop
Q&A Self Test
2 Chapter 9: Flashback Technology Enhancements
T his chapter reviews Oracle’s flashback technology, which operates at many levels,
serving a varied list of objectives. The flashback features of Oracle let you undo
logical corruptions or user errors by retrieving data from a past time period. The
rationale behind flashback technology is to enable quick recovery from logical errors without
having to resort to time-consuming point-in-time recovery strategies using backups and archived
redo logs. Several of the flashback recovery features rely on the familiar undo data, since they
all need information from the past to recover from logical errors. In Oracle Database 10g, a
new type of recovery log, called a flashback log, enables the flashback database feature. You can
use the flashback features of Oracle Database 10g to perform queries that return past data, to
perform queries that show the history of changes to table data, to undo undesirable changes to
table data, and to recover table(s) or even an entire database to a previous point in time.
Flashback technologies are superior to traditional recovery methods like point-in-time

recovery, which have become prohibitively slow in larger databases. Flashback techniques
hold an advantage over the use of the LogMiner tool as well. Flashback techniques are
faster because they focus purely on specific items of the changed data—there is no
need to parse entire redo log files to glean information about a single bad transaction.
Oracle indexes all the changes, both on a row as well as transaction basis, for fast access.
The flashback commands are simple as well. Thus, flashback techniques provide you
with a fast and efficient way to recover from logical (or user made) data errors. In
Oracle Database 10g, you can use the flashback technology at the database, table,
and transaction levels, as summarized here:
■ Flashback database enables you to take the entire database to a past point in
time (using flashback logs). Example: useful when you drop a user accidentally,
truncate a large table, or a batch job applies partial changes only.
■ Flashback drop lets you retrieve accidentally dropped tables and indexes (using
the recycle bin). Example: useful when you accidentally drop a table. This
feature also lets you restore a table to an earlier state in the event of an error.
■ Flashback table lets you recover a table to a time in the past (using undo data).
Example: useful in situations when you update a table with the wrong WHERE
clause.
■ Flashback query lets you query and restore data rows to a point in time (using
undo data). Examples: you want to compare current data against past data, or
you want to undo the effect of incorrectly run DML statements.
General Flashback Technology Considerations 3
Most flashback features relies on the new flashback logs. The

(flashback transaction query, flashback flashback drop (table) feature relies on
versions query, flashback table) rely on the new concept of a recycle bin.
undo data. The flashback database feature
Although all the recovery features in this chapter are called flashback features,
not all of them rely on the flash recovery area or the new flashback logs. Only
the flashback database feature uses the flash recovery area and flashback logs.
The flashback drop feature relies on the new recycle bin concept. All the
flashback query features rely on undo data.
We’ll look at the various Oracle Database 10g flashback features in detail in this
chapter. Let’s start with a review of the building blocks that enable Oracle to offer
you all the amazing and painless recovery techniques.
General Flashback Technology Considerations

Before we delve into the various flashback features, let’s review Oracle’s undo management,
which is at the heart of several of the new features. Let’s see how the concept of guaranteed
undo retention turns out to be critical for the functioning of the flashback technology.
If you have a damaged disk drive, or if there is physical corruption (not logical
corruption due to application or user errors) in your database, you must still
use the traditional methods of restoring backups and using archived redo logs
to perform the recovery.
Guaranteed Undo Retention

Oracle automatically collects undo data and stores it in the undo segments. Undo data
records the effects of individual transactions in changing table row data. Traditionally,
Oracle has used undo data to provide read consistency for queries, to roll back unneeded
transactions, and to recover terminated transactions. Starting with the Oracle9i version,
Oracle has been using undo data for even farther-reaching purposes—to query past data
and recover from logical errors in the data. In Oracle Database 10g, use of undo data
has been extended to flashback entire tables to a past time, as well as perform transaction
auditing.
The initialization parameter UNDO_RETENTION enables you to specify the length
of time Oracle must retain undo information in the undo segments. Oracle Database 10g
automatically tunes undo information by collecting statistics on the longest-running
queries and the undo generation rate in your database. If you don’t set the UNDO_
RETENTION parameter, or you specify a zero value for the parameter, Oracle
automatically tunes undo, using 900 seconds as the default value for the parameter.
By setting a much higher value than the default of 900 seconds, you can go back
further in the past. Since many flashback features in Oracle Database 10g depend on
having enough undo data, you should set the UNDO_RETENTION parameter much
higher than the default value. (In addition to enabling more effective flashback features,
this will also reduce the occurrence of the old snapshot too old errors.)
In previous chapters, you learned about the new guaranteed undo retention concept
in Oracle Database 10g. Guaranteed undo retention simply means that Oracle will
keep undo information in the undo segments for the entire length of the undo retention
period you specify (using the UNDO_RETENTION parameter), no matter what. That
is, if you specify half an hour as the undo retention interval, Oracle will retain all undo
segments for half an hour in the undo tablespace, even if there is space pressure in
the undo segments. If there were no room for
saving undo information for the new transactions,
any new DML transactions would fail, since Oracle
By default, Oracle doesn’t won’t able to store the undo information for
guarantee undo retention. When you do those changes. Thus, if you don’t size your undo
choose to guarantee undo retention, the tablespace correctly, there is a trade-off between
default interval is 900 seconds (15 minutes). guaranteeing undo information and the potential
failure of some DML statements.
You can specify undo guarantee in several ways: You can specify undo guarantee
for the undo tablespace when you create the database. You can also specify guaranteed
undo retention by using the RETENTION GUARANTEE clause when you create a new
undo tablespace, as shown here:
General Flashback Technology Considerations 5
SQL> create undo tablespace test1

datafile ‘c:\oracle\product\10.1.0\oradata\undotbs_01.dbf’
size 100M autoextend on
Tablespace created.
SQL>
You can also use the ALTER TABLESPACE command to tell Oracle to guarantee
undo retention in your database, as shown here:
SQL> alter tablespace test1
Tablespace altered.
SQL>
You can use the RETENTION NOGUARANTEE clause to turn off the guaranteed
retention of undo information.
Use Oracle’s Undo Advisor to get approximate undo parameter values as well
as suggestions regarding the sizing of your undo tablespace to successfully
support flashback for a specified time.
Time Mapping Granularity

Oracle gives you a choice between using either clock time or the system change number
(SCN) to specify exactly what time in the past you want to go back to. Oracle uses an
internal mapping between clock times and SCNs. Thus if you specify a certain clock
time, Oracle will pick an SCN time that’s within three seconds of the clock time you
specify.
Oracle retains the mapping between your clock time and SCNs for a period that
is as long as your UNDO_RETENTION initialization parameter.
Two new SQL functions convert SCNs to a corresponding timestamp value and
vice versa. Let’s review these functions in the following sections.
SCN_TO_TIMESTAMP
The SCN_TO_TIMESTAMP SQL function lets you convert an SCN to a calendar
time (TIMESTAMP) value. Here’s an example:
SQL> SELECT current_scn, SCN_TO_TIMESTAMP(current_scn)
2 FROM v$database;
CURRENT_SCN SCN_TO_TIMESTAMP(CURRENT_SCN)
------------- -----------------------------------
5956956 03-JUL-04 09.37.16.000000000 AM
SQL>
TIMESTAMP_TO_SCN
The TIMESTAMP_TO_SCN function is the inverse of the SCN_TO_TIMESTAMP
function. It converts a timestamp to its corresponding SCN.
Flashback Database
When you discover a major logical corruption in your database, the usual recourse is
to perform a point-in-time recovery. This type of recovery involving the use of datafile
backup copies and archived redo logs is very cumbersome and time consuming. Flashback
database does the same job as a traditional point-in-time recovery: it takes the database
back to a specific point in time or system change number (SCN). The big difference,
of course, is that you don’t need to restore any backup datafiles, and you may need, at
the most, just a fraction of the archived redo log information. Consequently, a flashback
database operation lets you recover from logical corruptions much faster than with the
usual point-in-time incomplete database recoveries.
You must understand that flashing back a database is possible only when there is
no media failure. If you lose a datafile, you’ll have to recover using a restored datafile
from backups. You must have all the datafiles and they must all be uncorrupted in
order to conduct a flashback database operation.
The critical thing to note is that no matter what the extent of the logical corruption,
traditional point-in-time recoveries require the restoration of datafiles and application
of archived redo logs. With flashback database, the extent of time taken for recovery
directly depends on the amount of changes that you need to undo. Thus, the size of
the error, not the size of the database, determines the time it takes to recover.
How Flashback Database Works

Once you enable the flashback database feature (I show how to do this in upcoming
sections), at regular intervals, the database copies images of each altered block in the
Flashback Database 7
datafiles from memory (flashback buffer) to the new flashback logs. Oracle logs
flashback data at infrequent intervals to reduce the I/O and CPU overhead. Oracle
stores these flashback logs in the flashback recovery area. That’s why the first step in
turning the flashback database feature on is to make sure you have configured a flash
recovery area.
The new memory buffer, flashback buffer, logs images of all altered data blocks in
the database. You can use these before images of data blocks to reconstruct a datafile
so you can back out any changes made after a specified target time and turn the file
back to a time in the past. In reality, however, the flashback database logs are used to
recover to a time just before the target time. Oracle uses traditional archive logs to
write changes for the short gap in time between the target recovery point in time
and the actual recovery time. A new background process, RVWR (Recovery Writer),
starts up automatically when you enable the flashback database feature. The RVWR
process writes the contents of the flashback buffer to the flashback database logs.
The flashback database logs are somewhat similar to the traditional Oracle redo logs.
Indeed, both logs are written to from a buffer area. However, the big difference is
that there are no archived flashback database logs! Oracle stores all the flashback
database logs in the flash recovery area.
When you want to restore a database to a past target time using the flashback
database feature, Oracle will restore each data block to its state at the time immediately
before the target time that the flashback logs were written. For example, if you want
to flashback to 8:00 A.M., it may turn out that the flashback logs nearest to the target
time were written at 7:56 A.M. To cover this gap, you must apply the changes from
archived or online redo log files pertaining to that period. This is the reason why,
although you aren’t doing a traditional point-in-time recovery using backup files and
archived redo log files, you must have redo logs available for the entire time period
spanned by the flashback logs.
Traditional point-in-time incomplete recovery involves the restoration of backup
data files first. After the restore, you apply the archive redo logs to advance the database
forward. In flashback database, you don’t use any backup data files. You simply apply
the flashback database logs to take the database back in time.
Oracle recommends that you set your redo log buffer for large databases to
at least 8MB. The flashback buffer size will be at least log_buffer times two,
thus ensuring that Oracle allocates the typical maximum memory possible
for your flashback buffer, which is about 16MB.
The time taken to flashback have a heavy DML-based database, you’ll

a database strictly depends on how far back have more data block changes than if the
you want to flashback and the amount of database was mainly supporting queries.
data block changes in the meantime. If you
Always remember that Oracle doesn’t guarantee that you can flashback your
database to the flashback retention target that you set by using the FLASHBACK_
RETENTION_TARGET init parameter. Oracle stores the flashback logs you need for
a flashback database operation in the flash recovery area. If Oracle is running low on
free space in the flash recovery area for newly arriving archived redo log files, it will
remove some flashback logs to make room. That’s why it is absolutely essential to
monitor the flash recovery area size to ensure you don’t lose any critical flashback
logs necessary to recover your database.
Flashback Database Considerations

There are several considerations that you must be aware of when you use the flashback
Database feature. Here’s a summary:
■ All commands of the Flashback Database feature work the same in RMAN
as well as SQL*Plus. The only difference is that RMAN will automatically
retrieve the necessary archived redo logs.
■ If you’ve lost a datafile or for some reason can’t use a datafile, you can’t use
Flashback Database to recover. You must have all the datafiles to flashback
your database to a past period.
■ If a datafile was resized during the time span covered by the Flashback Database
operation, you can’t flashback that datafile. Instead, you must offline that
particular datafile before you start the flashback database operation.
■ If a control file has been restored or re-created during the time span you want
to flashback over, you can’t use the Flashback Database feature.
■ For good performance, Oracle recommends using fast file systems that don’t
use operating system file caching. Large flashback database logs add to your
overhead when using operating system file caching.
■ To increase disk throughput, Oracle recommends using multiple disk spindles,

with small stripe sizes (128K) for flash recovery areas.
If you want to undo the forward. Flashback Database rolls back the
effects of a Flashback Database operation, database. To undo it, you therefore must
you must recover the database by rolling it roll forward the database.
■ You can’t flashback a database to before a RESETLOGS operation.

■ You can’t flashback a datafile that was dropped during the time span covered
by the flashback table operation.
■ You can’t flashback a datafile that was shrunk during the time span covered
by the flashback table operation.
Configuring Flashback Database

You need to perform a set of operations before you can use the Flashback Database
feature. Let’s review these operations here:
1. Ensure that your database is in the archivelog mode.

2. Your database must be using the flash recovery area. (See Chapter 8 for details
on configuring the flash recovery area.) If you haven’t configured the flash
recovery area, you must do so before you can proceed further.
3. You must use the new initialization parameter DB_FLASHBACK_RETENTION_
TARGET to set your flashback retention target. The flashback retention target
specifies how far back you can flashback your database. The value of the DB_
FLASHBACK_RETENTION_TARGET parameter determines how much
Flashback Database log data your database will store in the flashback recovery
area. Of course, you must have enough space in your flash recovery area to
contain these Flash Database logs. Here’s an example that shows how to set
your flashback target to 1 day (1440 minutes):
SQL> ALTER SYSTEM SET
2 DB_FLASHBACK_RETENTION_TARGET=1440;
System altered.
SQL>
4. Shut down the database and restart in the MOUNT EXCLUSIVE mode.
(If you are using a single instance, the simpler MOUNT command will do.)
SQL> SHUTDOWN IMMEDIATE;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup mount;
Database mounted.
SQL>
5. Turn the flashback database feature on with the following command:

SQL> alter database flashback on;
Database altered.
SQL>
6. Use the ALTER DATABASE OPEN command to open the database. To confirm
whether the flashback database feature is enabled, issue the following query:
SQL> select flashback_on from v$database;
FLA
---
YES
SQL>
You can find out if the finally, use the ALTER DATABASE FLASHBACK
flashback feature is enabled by querying ON command. You can turn the feature off
the V$DATABASE view. The three things by using the ALTER DATABASE FLASHBACK
you must do to configure the flashback OFF command. Make sure you restart the
database are as follows: configure the flash database in the MOUNT EXCLUSIVE mode
recovery area, set the DB_FLASHBACK_ before using this command.
RETENTION_TARGET parameter, and
When you disable the flashback database feature, Oracle deletes all flashback
database logs in the flash recovery area.
Configuring Flashback Database Using Database Control

If you want to take the easy way out, you can use the OEM Database Control tool to
configure flashback logging in your database. Here are the steps you must follow.
(Make sure you have archive logging turned on.)
1. From the Home page, click on the Maintenance tab.

2. Go to the Backup/Recovery section and click on Configure Recovery Settings.
3. Under the Flash Recovery Area section, first specify the flash recovery area
destination and size.
4. Check the box next to “Enable flashback logging for fast database point-in-
time recovery,” as shown in Figure 9-1.
FIGURE 9-1 Configuring Flashback Database using Database Control
Flashback Storage Issues

Flashback database logs (stored in the flash recovery area) make it possible for you to
perform a flashback database operation. The flash recovery area is primarily meant as a
storage location for recovery-related files like datafile copies, incremental backups, and
archived redo logs. The database accords priority to storing these recovery-related files
over retaining flashback database logs. Accordingly, the database will delete flashback
database logs if it needs the flash recovery area space to accommodate new recovery-
related files. Therefore, you must ensure that you have allocated sufficient space to
your flash recovery area to hold all your flashback database logs.
The value of the DB_FLASHBACK_RETENTION_TARGET parameter (1440
minutes in our example) determines how much flashback data the database should
retain in the form of flashback database logs in the flash recovery area. In order to
estimate the space you need to add to your flash recovery area for accommodating
the flashback database logs, first run the database for a while with the flashback
database feature turned on. Then run the following query:
SQL> select estimated_flashback_size, retention_target,
flashback_size from v$flashback_database_log;
ESTIMATED_FLASHBACK_SIZE RETENTION_TARGET FLASHBACK_SIZE
------------------------ ---------------- ----------------------
126418944 1440 152600576
SQL>
If there isn’t sufficient data to perform a flashback all the way back to where
you want to take the database, you can use standard recovery procedures to
recover the database.
The V$FLASHBACK_DATABASE_LOG view provides information that helps you

estimate the amount of flashback data needed for your current database workload
level of DML activity (since queries don’t produce any flashback data). Let’s understand
the three key columns in the V$FLASHBACK_DATABASE_LOG view:
■ RETENTION_TARGET shows you the target retention time in minutes.
■ ESTIMATED_FLASHBACK_SIZE shows you the estimated size of flashback
data needed to satisfy the value you specified for the RETENTION_TARGET
parameter. Oracle bases its flashback data estimates on either the DML changes
in the database since the instance started, or the most recent interval of time
equal to your retention target. Oracle chooses the shorter of these two choices
to prepare its flashback data estimate.
■ FLASHBACK_SIZE column shows the current size, in bytes, of the
flashback data.
Although the query on the V$FLASHBACK_DATABASE_LOG view enables you

to come up with an estimate of the disk space for the flashback database logs, that
isn’t a guarantee that the space will meet your needs. To really know how far back
you can flashback your database at any given time, you must query the V$FLASHBACK_
DATABASE_LOG in the following manner:
SQL> select oldest_flashback_scn,
oldest_flashback_time
from v$flashback_database_log;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_
-------------------- -----------------
5964669 07-03-04 12:22:37
SQL>
If the query results indicate that you can’t wind back your database as far as you
would like, you must increase the size of your flash recovery area. You do this so the
flash recovery area can hold a larger amount of flashback database logs.
Just because you have set satisfy the retention target. If the flashback
your retention target at a high value recovery area gets full, Oracle will remove
doesn’t ensure that Oracle will guarantee the flashback database logs to make room
the retaining of flashback database logs to for new recovery files.
The database incurs an I/O overhead while logging the flashback data. The view
V$FLASHBACK_DATABASE_STATS helps you monitor the I/O overhead of
logging flashback data. Here’s the structure of the V$FLASHBACK_DATABASE_
STATS view:
SQL> desc v$flashback_database_stat;
Name Null? Type
----------------------------------------- -------- ----------
BEGIN_TIME DATE
END_TIME DATE
FLASHBACK_DATA NUMBER
DB_DATA NUMBER
REDO_DATA NUMBER
ESTIMATED_FLASHBACK_SIZE NUMBER
SQL>
Let’s take a closer look at the elements in the V$FLASHBACK_DATABASE_

STAT view:
■ BEGIN_TIME and END_TIME stand for the beginning and ending hourly
time intervals for which the view’s statistics were collected. Oracle collects
flashback data on an hourly basis for a maximum of 24 hours. If you issue a
query on the table, however, it may return 25 rows, the 25th row being for the
most recent fraction of time after the last (24th) row was logged in the view.
■ FLASHBACK_DATA stands for the number of bytes of flashback data written
during the interval.
■ DB_DATA stands for the number of bytes of database data read and written
during the interval.
■ REDO_DATA stands for the number of bytes of redo data written during
the interval.
■ ESTIMATED_FLASHBACK_SIZE is identical to the value of
the ESTIMATED_FLASHBACK_SIZE column in the V$FLASHBACK_
DATABASE_LOG view.
The V$FLASHBACK_DATABASE_STAT view helps you monitor how your

flashback data generation is changing across a day’s time. You can adjust either or
both of your retention target and flash recovery area size based on the statistics
provided by this view.
If you don’t want certain tablespaces to be part of your flashback operations, you
can specify that Oracle not log any flashback database data for these tablespaces.
You can specify turning off the flashback database feature at the tablespace level
when creating the tablespace itself, or later on, by using the ALTER TABLESPACE
command. Here is an example:
SQL> alter tablespace users flashback off;
Tablespace altered.
SQL>
When you turn the tablespace offline. Otherwise, Oracle will

flashback database feature off for a issue an error when you try to use the
tablespace, as shown in the previous FLASHBACK DATABASE command.
example, make sure that you take the
Flashback Database Examples

When you issue the FLASHBACK DATABASE statement, Oracle will first check that
all the archived and online redo log files spanning the entire flashback period are available.
It automatically reverts all the currently online datafiles to the SCN or time you specify
in the FLASHBACK DATABASE statement.
Let’s look at a few examples to illustrate the use of the FLASHBACK DATABASE
command. In the first example, I first create a table called persons and load it with
some test data. I then use the flashback database feature to effortlessly get back to a
specified SCN. The example follows.
First, I check for the number of rows in the persons table.
SQL> select count (*) from persons;
COUNT(*)
----------
32768
I note what the current SCN of the database is with the following SQL command:
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
5965123
I then double the number of rows in our test table, persons, I check the current
number of rows, and I get the following answer:
SQL> select count (*) from persons;
COUNT(*)
----------
65536
My goal is to get back to the time when the row count in the persons table was
32768. I can do this easily by flashing back to the SCN 5965123. To use any flashback
feature, I must restart the database in the MOUNT (exclusive) mode, as shown here:
SQL> startup mount;
…
Database mounted.
I can now turn the flashback database feature on by using the following command:
SQL> flashback database to SCN 5964663;

Flashback complete.
Note that TO SCN takes the database back to its state at that SCN. You can also
take a database back to its state just before an SCN by using the TO BEFORE SCN
clause. Alternatively, you may use the TO_TIMESTAMP or TO BEFORE TIMESTAMP
to revert the database to a specified timestamp, or one second before the specified
timestamp.
In order to query the persons table, I must first open the database, which I try to
do here:
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
I then use the ALTER DATABASE OPEN RESETLOGS command to open the
database. In order to have a write access to the database that I just flashed back,
I must reopen the database with an ALTER DATABASE OPEN RESETLOGS statement.
To make sure that you have indeed used the current SCN or target time, you may
first want to use the ALTER DATABASE OPEN READ ONLY statement. Once you
confirm that you have flashed the database back to the correct point in time or
the correct SCN, you can finalize matters by using the ALTER DATABASE OPEN
RESETLOGS statement. If after the initial check (in the read-only mode), you
decide to go back further in time, you can flashback the database again. If you
determine that you flashed back too far into the past, you can use redo logs to roll
forward. The ALTER DATABASE OPEN RESETLOGS statement should be used
only after you are finally satisfied about the correctness (timewise)of the data.
SQL> alter database open resetlogs;
Database altered.
You can verify that your database has been flashed back by using the following
query on the persons table:
SQL> select count(*) from persons;
COUNT(*)
-----------
32768
Flashback Drop 17
In the previous example, I used an SCN to tell the database how far back it
should flashback. However, you may use an archived log sequence, or a prior time as
well, to specify the flashback point. Here are some examples using time and log
sequence numbers:
SQL> flashback database to sequence 12345; /* will flashback
the database to the log sequence numbered 1234) */
SQL> flashback database to timestamp (SYSDATE -1/24); /* will flashback the database to an hour ago */
Once you flashback the the database forward, after the flashback
database to a certain point in time, you can operation. If you want to completely undo
flashback the database to a different time the effects of the flashback database
if you think you used the wrong flashback operation, just use the command RECOVER
target time the first time around. If you DATABASE to perform a complete recovery
want, you can perform a recovery to roll of the database.
EXERCISE 9-1
Using the Flashback Database Feature

List the contents of your flash recovery area. Configure the flashback database feature
in your database. Check the current SCN of your database. What is the oldest SCN
you can flashback your database to?
Flashback Drop
One of the biggest occupational hazards of a DBA’s job is the fact that you could
inadvertently drop a key production table. There are countless stories of how DBAs
have dropped or truncated the wrong table in the wrong database, with disastrous
consequences, at an organizational as well as a personal level. Well, Oracle Database 10g

finally takes this hazard away, since you can’t mistakenly drop a table anymore! When
you drop a table by using the command DROP TABLE PERSONS, for example, the
persons table doesn’t go away immediately, as before. If you change your mind or realize
you’ve made a mistake, you don’t have to perform a database point-in-time recovery.
You simply use the following magical command to get your “lost” table back:
SQL> FLASHBACK TABLE persons TO BEFORE DROP;
In an Oracle 10g database, when you drop a table, Oracle doesn’t automatically drop
the space allocated to the table. It simply renames and stores the table and its dependent
objects in the database’s recycle bin. Using the Flashback Drop operation as shown in
the previous example, you then recover the dropped table from the recycle bin.
How the Flashback Drop Feature Works

In previous versions of Oracle, when you used the DROP TABLE command, Oracle
immediately dropped the table and all its dependent objects. The database also released
all the space in that table segment back to the database. In Oracle Database 10g, when
you drop a table, the table is gone in name only—the table itself, with all its rows, is
merely renamed and stays in the same location as before. If you query the DBA_FREE_
SPACE view, you’ll see additional space, indicating that the table segment has given
up its space. However, this additional free space is merely the potential free space you
can possibly reclaim, if you really get rid of the table later on. Thus, when you drop a
table or an index, the space occupied by the objects is not reclaimable immediately by
the database, although you can see the space as free space in the DB_FREE_SPACE
view. Oracle reclaims the space only if it experiences space pressure. Oracle’s goal here
is to retain the dropped objects for the maximum time possible.
As stated earlier, when you issue the DROP TABLE command, Oracle merely
renames the table and moves it to a recycle bin. The recycle bin is not an area on
disk, unlike your flash recovery area. The recycle bin is merely a data dictionary
table that maintains information about dropped tables, such as their original names
and the new names that Oracle gives them when it temporarily renames them and
places them in the recycle bin.
All objects that you drop will first sit in the recycle bin and continue to take up
their original space allocation in their tablespaces. Oracle will permanently remove
Flashback Drop 19
them from the recycle bin—and therefore, from the database—when either a user
purges them or Oracle automatically reclaims the space. To summarize:
■ You remove a table permanently with a PURGE command. You can use the
PURGE command as an option with the DROP TABLE (or INDEX) command.
You may also use the command to drop an object currently saved in the
recycle bin.
Or
■ Oracle automatically removes the dropped objects in the recycle bin because
of space pressure. Space pressure is said to occur when there isn’t enough free
space in a tablespace when you need to create a new object or extend more space
to an existing object. Oracle first allocates all the available free space in the
tablespace to the new object. When it runs out of available free space, Oracle
will start automatically purging the occupants of the recycle bin to make room
in the tablespace.
Querying the Recycle Bin

When you drop a table, Oracle lists the object in the recycle bin, which is a data dictionary
table named RECYCLEBIN$. You can view the contents of the recycle bin by using
either the DBA_RECYCLEBIN (database level) view or the USER_RECYCLEBIN
(user level) view. The DBA_RECYCLEBIN shows all dropped database objects, provided
they are still in the recycle bin. Here is an example that shows how to retrieve information
about any dropped objects in your database:
SQL> select owner,original_name,object_name,
2 ts_name,droptime
3* from dba_recyclebin;
OWNER ORIGINAL_NAME OBJECT_NAME TS_NAME
--------------------------------------------------------------------
sam PERSONS BIN$xTMPjHZ6SG+1xnDIaR9E+g==$0 USERS
There could be several about the recycle bin owned by the current
recycle bins, each owned by the person user. The DBA_RECYCLEBIN view displays
who dropped an object. The USER_ information about all recycle bins in the
RECYCLEBIN view displays information database.
The DBA_RECYCLEBIN (and the USER_RECYCLEBIN) view shows details

about objects in all recycle bins in the database. Two important columns of the view
are the CAN_UNDROP and CAN_PURGE columns, which tell you whether you
can undrop and purge an object, respectively.
You can also use the command SHOW RECYCLEBIN to view the contents of the
recycle bin, as shown here:
SQL> show recyclebin
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ -------------
PERSONS BIN$xTMPjHZ6SG+1xnDIaR9E+g==$0 TABLE 2004-07-
04:12:08:57
SQL>
The SHOW RECYCLEBIN command shows only those objects that you can
undrop.
When Oracle moves a dropped table to the recycle bin it assigns the table a system-
generated name, which is usually 30 characters long. If you look in the DBA_TABLES,
DBA_OBJECTS, and DBA_SEGMENTS views, you are still listed as the owner of the
table. The reason is that as long as the dropped table is still in the recycle bin, you
can recover it by using the FLASHBACK TABLE command.
How can you tell by looking at the DBA_TABLES view which of your tables are
in the recycle bin with system given names, and which are not? A simple query on
DBA_TABLES will resolve this issue, as shown here:
SQL> select table_name, dropped from dba_tables;
Any table that was dropped and is still in

the recycle bin will show a YES value for the
DROPPED column, and NO otherwise.
The recycle bin helps you If you wish, you can query tables in the
recover dropped tables only. If you truncate recycle bin. Understand that the recycle bin
a table, you can’t recover it using the recycle knows your table by its system-generated name
bin. If you truncate a large table, you might only—therefore, your query must include not
want to use the flashback database feature. the original name of the dropped table, but the
new name given it while it is temporarily stored
in the recycle bin. Here’s an example that shows you how to query the dropped table
persons. (Make sure you enclose the system name of the dropped table in double quotes.)
Flashback Drop 21
SQL> select * from "BIN$ksisyyg0TxKnt18rqukpQA==$0";

NAME
--------------------
Valerie alapati
sam alapati
nina alapati
nicholas alapati
shannon alapati
SQL>
You can use the SELECT bin. You can’t use INSERT, UPDATE, and
command to query the objects in the recycle DELETE commands on these objects.
Oracle renames all objects system-generated names. You may want to

in the recycle bin, including the dependent rename these objects to names that follow
objects like indexes, triggers, and constraints. your organization’s object naming conventions
When you flashback a table, Oracle will after you complete the flashback table
recover the dependent objects as well, operation.
but they’ll continue to have their cryptic
Restoring Dropped Tables

The amazing power of the Flashback Drop feature lies in its ability to effortlessly recover
dropped tables and indexes. In order to restore a dropped table, you use the FLASHBACK
TABLE …TO BEFORE DROP command, after making sure that your table is listed as
part of the recycle bin. You can use either the original name of the table you dropped
or the new system-generated name when you recover a table and its dependent objects
from the recycle bin. Here is an example using the original name of the table to restore it.
(In the example, I first dropped the persons table, which had 10240 rows.)
SQL> flashback table persons
2* to before drop;
Flashback complete.
If you wish, you may use the system-generated name for the flashback table operation,
as shown here:
SQL> flashback table "BIN$ksisyyg0TxKnt18rqukpQA==$0"
2 to before drop;
Flashback complete.
SQL>
You can also use the flashback operation as an opportunity to rename your dropped
table upon recovery, using the following command. (You may use the same command
with the original name of the table in the first line, instead of the system-generated
name.)
SQL> flashback table "BIN$ksisyyg0TxKnt18rqukpQA==$0"
to before drop
rename to NEW_PERSONS;
You may find this ability to rename a table

within the flashback command very helpful
when you’ve already created a new table with
When you recover a table the same name as the dropped table.
from the recycle bin using the FLASHBACK If you drop and re-create a table with the
TABLE… TO BEFORE DROP command, same name, the recycle bin will have several
Oracle removes the object from the versions of the dropped table, each with a unique
recycle bin. system-generated table name. If you then issue
a FLASHBACK TABLE … TO BEFORE DROP
command, Oracle will simply recover the latest version of the table. If you don’t want
Oracle to do this, you have the following options:
■ In the FLASHBACK TABLE command, provide the specific system-generated

name of the table you want to recover.
■ Keep issuing the FLASHBACK TABLE command until you recover the particular
table you want.
Permanently Removing Tables

What do you do when you are sure that you want to get rid of a table permanently?
When you issue the DROP TABLE command, you can specify the new PURGE option,
which will ensure that Oracle removes the table permanently and immediately, without
moving it to the recycle bin. The PURGE clause comes in especially handy when you
Flashback Drop 23
want to drop a sensitive table and don’t want it to appear in the recycle bin for security
purposes. Here’s how you use the PURGE command:
SQL> drop table persons purge;
Table dropped.
SQL>
The DROP TABLE …PURGE command is the equivalent of the DROP TABLE
command in previous versions of Oracle. Using the PURGE clause is equivalent
to first dropping the table and then purging it from the recycle bin.
Let’s say you drop the persons table from

the tablespace USERS. Now the persons table
becomes a part of the recycle bin. When a user
Once you remove an object creates a new table in the USERS tablespace,
from the recycle bin with the PURGE Oracle assigns free space that doesn’t correspond
command, or if you drop an object with to the dropped persons table. If there isn’t
the PURGE command, you can’t apply the enough free space in the USERS tablespace to
flashback drop feature with those objects create the new table, Oracle will automatically
(or their dependent objects)—the purged purge objects from the recycle bin. If there are
objects are gone forever! several objects in the recycle bin, Oracle first
removes the oldest objects that it had placed
in the recycle bin. If the space pressure continues even after purging tables from
the recycle bin, Oracle may extend the tablespace, provided it is autoextensible.
Here is how you can use the PURGE command to permanently remove various
objects from your recycle bin:
■ PURGE TABLE or INDEX will remove the table or index. You can also use
the DROP TABLE … PURGE command, but that command applies to objects
that aren’t a part of the recycle bin. You may also drop an object by using the
recycle bin name of the object, for example:
SQL> purge table "BIN$Q1qZGCCMRsScbbRn9ivwfA==$0"
Table purged.
SQL>
If you have several tables of the same original name in the recycle bin, the
PURGE command will drop the first table that you originally dropped.
■ PURGE TABLESPACE removes all objects that are part of that tablespace.
Of course, if you remove a table, all of its dependent objects, such as indexes,
will be dropped as well. When you issue the PURGE TABLESPACE command,
the dependent objects of a table that live in other tablespaces will be removed
as well. If you want to remove all objects of a single user, scott, for example,
from the recycle bin, you may use the following command:
SQL> purge tablespace users user scott;
■ If you drop a tablespace with the command DROP TABLESPACE …INCLUDING

CONTENTS, all the tablespace’s objects will be dropped permanently right
away, without being placed in the recycle bin. In addition, any objects belonging
to the tablespace that are part of the recycle
bin are purged immediately. If you use the
DROP TABLESPACE command by itself,
Understand the difference without the INCLUDING CONTENTS
between the DROP USER and DROP USER clause, the tablespace must not have any
…CASCADE command. Similarly, understand objects in it. Otherwise, the command will
the difference between a DROP TABLESPACE fail. In addition, if there are any objects in
and a DROP TABLESPACE …INCLUDING the recycle bin that originally belonged to
CONTENTS command. this tablespace, those objects will be purged
from the recycle bin.
■ If you use the command DROP USER … CASCADE, Oracle immediately
drops the user and all objects owned by the user from the database. Any
objects in the recycle bin that belong to that user are automatically purged.
■ PURGE RECYCLEBIN or PURGE USER_
RECYCLEBIN will remove all objects
belonging to the user issuing the command.
When you drop a user, Oracle
drops all the user’s objects permanently. In ■ PURGE_DBA_RECYCLEBIN will remove
addition, Oracle permanently removes any all objects in the recycle bin. You must have
of the user’s objects that are in the recycle the SYSDBA privilege to purge the entire
bin as well. recycle bin.
EXERCISE 9-2
Using the Flashback Drop Feature

Create a test table with a couple of indexes. Drop the table with the traditional DROP
TABLE command. Re-create the table and drop it again. Repeat this process a few
times. Show the ways in which you can retrieve the very first table you dropped.
Flashback Table 25
Restrictions on Flashback Drop

Certain restrictions apply to the use of the Flashback Drop feature. Let’s look at the
important restrictions here:
■ You can use the Flashback Drop feature on any table that belongs to any non-
SYSTEM, locally managed tablespace.
■ Dependent objects can be in either a locally or dictionary managed tablespace,
to be stored in the recycle bin.
■ The following types of dependent objects aren’t saved in the recycle bin when
you drop a table:
■ Materialized view logs
■ Referential integrity constants
■ Bitmap join indexes
■ You can’t save a table that has fine-grained auditing (FGA) or Virtual Private
Database policies defined on it.
The table that you want the dependent objects of that table can
to flashback must be in a non-SYSTEM, be in a dictionary or locally managed
locally managed tablespace. However, tablespace.
Flashback Table
Oracle’s Flashback Table feature lets you perform an online, point-in-time recovery
on one or more tables. The FLASHBACK TABLE statement lets you restore an earlier
state of a table to recover from human or application errors. For example, you may
need to perform a point-in-time recovery on a table when a user mistakenly applies
an update statement with the wrong WHERE clause. The Flashback Table feature
relies on undo information in the database undo segments to perform the point-in-
time recovery without ever having to restore any data files or apply any archived redo
log files. Ensure that you set your UNDO_

RETENTION parameter to a time interval large
enough to cover the longest span of time for
All indexes and other which you might want to recover a table. You can
dependent objects of a table, such use this feature to roll back any changes made to
as dependent on-commit materialized a table to a past SCN or time. Oracle acquires
views, remain intact during a flashback exclusive DML locks on the table or tables that
table operation. it is recovering, but the tables are online and
available to other users.
How Flashback Table Works

Flashback table technology uses undo information to restore data rows in changed
blocks of tables. The changed information is in the undo segments, and Oracle uses
the undo data to undo or roll back the table data using DML statements like INSERT,
UPDATE, and DELETE. Let’s review the necessary steps to perform a flashback table
operation.
The flashback features aren’t supported for the user SYS.
First, make sure you have all the privileges necessary to perform the Flashback
Table operation. You must have either the FLASHBACK ANY TABLE or the more
specific FLASHBACK object privilege on the table you want to recover. In addition,
you must have the SELECT, INSERT, DELETE, and ALTER privileges on the table.
Second, make sure you enable row movement in the table, since the flashback
operation doesn’t preserve Oracle ROWIDs when it restores rows in the changed
data blocks of the table.
SQL> alter table persons enable row movement;
Table altered.
Once you enable row movement in the table(s), you are ready to flashback the
table to any time in the past, or any SCN in the past. Here’s an example that shows
how to flashback a table to a past SCN:
SQL> flashback table persons to scn 6039341;
Flashback complete.
Flashback Table 27
You may also specify a time to flash back to, using the following command:
SQL> flashback table persons to timestamp to_timestamp
(‘2004-07-04 08:05:00’, ‘YYYY-MM-DD HH24:MI:SS’);
The previous FLASHBACK TABLE command restores the persons table to 8.05 A.M.
on July 4, 2004.
The persons table continues to be online and accessible to users for all queries.
However, Oracle acquires exclusive DML locks on the table during the Flashback
Table operation. The restore is an in-place, online operation and thus doesn’t involve
any offlining of the datafiles or tablespaces, a procedure that’s common during
traditional point-in-time recovery. However, Oracle disables all relevant triggers by
default and reenables them upon completing the table recovery. You may simply
append the ENABLE TRIGGERS clause to your FLASHBACK TABLE command if
you want to override this default behavior. Here’s an example:
SQL> FLASHBACK TABLE person TO TIMESTAMP TO_TIMESTAMP
(‘2004-07-04 08:05:00’, ‘YYYY-MM-DD HH24:MI:SS’)
ENABLE TRIGGERS;
Undoing a Flashback Table Operation

Can you undo a flashback operation? Yes! If it turns out that your flashback table results
aren’t satisfactory, you can use the FLASHBACK TABLE statement again to go back to
just before you were when you issued the first statement. This is why it is important to
note your current SCN before using a Flashback Table operation. That way, if you ever
want to undo a Flashback Table operation, you simply use the FLASHBACK TABLE
… TO SCN statement to roll forward the table to a more recent time.
Restrictions on Flashback Table

Several restrictions apply to the Flashback Table recovery feature. Let’s look at the
important restrictions in this section.
The entire Flashback Table operation executes as a single transaction.
■ You can’t flashback a system or remote table.

■ You can’t flashback a table back to a time preceding any DDL operation that
changes the structure of a table (for example, adding or dropping a column).
■ Either the flashback operation succeeds entirely or it fails; it is a single

transaction. That is, if you have several tables in a FLASHBACK TABLE
command, Oracle will recover all tables or none.
■ If there are any constraint violations during the flashback recovery, Oracle
abandons the recovery process and leaves the tables as they were before the
commencement of the flashback operation.
■ If you shrink a table or otherwise change any of the nonstorage attributes of
a table (other than storage attributes such as PCTFREE, INITTRANS, and
MAXTRANS), you can’t flashback to a time before you made these changes.
■ Oracle doesn’t flashback statistics of the recovered objects. You may, therefore,
wish to collect new statistics for the recovered objects after you complete the
flashback operation.
Row Level Flashback Features

Thus far in this chapter, you’ve seen the application of flashback techniques at a table
or the database level. You can also use the flashback techniques to perform very useful
tasks at the row level. The row level flashback features provide ways to select information
from the past, see all the versions of a row, and change necessary row data. All row
level flashback features rely on undo data. The length of time you can go back for
query purposes depends on the setting of your UNDO_RETENTION initialization
parameter. If you wish to provide your users the ability to flashback queries for a length
of two hours, for example, you must set the UNDO_
RETENTION parameter to 7220. The default
value for this parameter is only 900 seconds
The value of the UNDO_ (15 minutes). There are three types of row
RETENTION parameter determines the level flashback query features—Flashback
length of time your users can flashback Query, Flashback Versions Query, and Flashback
their queries. Transaction Query. Let’s look at these features in
detail in the following sections.
Flashback Query (SELECT…AS OF)

The Flashback Query feature isn’t new to Oracle Database 10g, but I’m reviewing it
briefly here for completeness. This feature retrieves data from a time in the past using
Row Level Flashback Features 29
the AS OF clause of the SELECT statement. The Flashback Query feature enables you
to perform queries on the database at a target time in the past. For example, if a user
accidentally deletes data rows during data entry, you can query the table using Flashback
Query to retrieve the lost rows and reinsert them in the table. All the changes are made
using simple SQL statements, and you don’t need to restore and recover any datafiles.
You may need to query past data in order to undo incorrect changes, verify the
past numbers in a column, or compare present data in a column with its past values.
To query data from the past, simply use the normal SELECT statement with an AS
OF clause. You may use SCN numbers or timestamps for this purpose. The AS OF
clause ensures that Oracle returns the committed data in the table as of a previous
SCN or timestamp. If you omit the AS OF clause, Oracle will retrieve data as of the
current SCN or a specific SCN or clock time if you have specified either one. Here’s
a simple example that illustrates how you can query the past state of a table:
SQL> select * from persons as of timestamp
to_timestamp('2004-07-04 08:05:00', 'YYYY-MM-DD HH:MI:SS')
where name = 'ALAPATI';
After verifying that the rows shown by your SELECT statement will correct the
data entry, you may undo the damage by simply inserting the correct rows, again with
the help of the SELECT … AS OF construct, this time in a subquery, as shown here:
SQL> insert into employee
(SELECT * FROM employee AS OF TIMESTAMP
TO_TIMESTAMP('2004-07-04 08:05:00', 'YYYY-MM-DD HH:MI:SS')
where name = 'ALAPATI');
Flashback Versions Query

The Flashback Versions query feature enables users to query the history of a given row
in a table. For a given interval, the feature enables you to retrieve different versions of
specific rows that existed during that interval.When you issue a SELECT statement
using the VERSIONS clause, Oracle will return the different committed versions of
the same row between two SCNs or two timestamps. You may also use the VERSIONS
clause in subqueries of DML and DDL statements.
Flashback Versions query, to an adequate interval if you want to ensure

like all the other Oracle flashback features, that your SELECT statement returns all the
relies on undo data. You must set your versions you are interested in.
UNDO_RETENTION initialization parameter
The Flashback Versions Query feature enables the retrieval of all committed
versions of the same table row between two time points. If you’ve updated the row
ten different times, the Flashback Versions Query will get you all ten of those rows.
The syntax of the versions query is as follows:
VERSIONS {BETWEEN {SCN | TIMESTAMP} start AND end}
In the preceding syntax statement, you can use the VERSIONS clause as a part
of your normal SELECT statement, with an optional BETWEEN clause appended
to it. Optionally, you can specify the SCN or
TIMESTAMP clauses. You must specify the start
and end expressions, which indicate the start
The Flashback Versions time and end time of the interval for which you
Query feature retrieves only committed are seeking the different row versions.
transactions. Remember that the query The output of a Flashback Versions Query
retrieves both deleted and subsequently is unlike the output of your typical SELECT
reinserted rows. statement. In addition to the column values
you specify in the SELECT statement, for each
version of the row, Oracle will provide you with values for a set of pseudocolumns for
each row version. It is these pseudocolumns that tell you the story of when exactly a
row change took place, and what exactly was done to the row at that time. Here is a
brief explanation of each pseudocolumn that will be part of the flashback versions
query output:
■ VERSIONS_STARTSCN and VERSIONS_STARTTIME This

pseudocolumn tells you the SCN and timestamp when this particular row
was first created.
An index-organized table would show a D for the delete operation

(IOT) will show an update operation as under the VERSIONS_OPERATION
a separate insert and a delete operation. pseudocolumn (explained below), and
Your versions query would produce both the subsequent insert column would
the deleted and inserted rows as two show an I for the same pseudocolumn.
independent versions. The first version
■ VERSIONS_ENDSCN and VERSIONS_ENDTIME These pseudocolumns

tell you when this particular row expired.
■ VERSIONS_OPERATION This pseudocolumn provides you with

information as to the type of DML activity that was performed on the
particualr row. The DML activities are indicated by letters: I stands for
insert, D for delete, and U for an update.
■ VERSIONS_XID This pseudocolumn stands for the unique transaction
identifier of the transaction that resulted in this row version.
If the VERSIONS_STARTSCN VERSIONS_ENDTIME are NULL, this means

and the VERSIONS_STARTTIME are NULL, that this row version is current when you tried
then the row was created before the lower to use the Flashback Versions Query operation,
bound specified by your BETWEEN clause. or the row was part of a delete operation.
If the VERSIONS_ENDSCN and the
Flashback Versions Query Example

Here’s an example of using the Flashback Versions Query feature:
SQL> select versions_xid XID, versions_startscn START_SCN,
versions_endscn END_SCN, versions_operation OPERATION,
empname, salary from hr.emp
versions between scn minvalue and maxvalue
as of scn 113900
where empno = 111;
XID START_SCN END_SCN OPERATION EMPNAME SALARY
---------------- ---------- --------- ---------- ---------- ----------
0004000700000058 113855 I Tom 927
000200030000002D 113564 D Mike 555
000200030000002E 112670 113564 I Mike 555
The example retrieves three versions of a row for empno (employee number) 111.
The AS OF SCN of the query is 113900. That is, you want to know what versions
of the row existed at this SCN. The query asks for the empname, salary and othr
information for emno 111. The empno 111 is orginally to a new employee and if that
employee is deleted, may be reassigned to a different employee. Thus, you may see
different employee names for the same empno valuye over time. Although you see
three versions of rows for empno 111, only one of them still exists at SCN 113900.
Which version is it?
Read the query output from top to bottom. Pay particular attention to the
START_SCN and the END_SCN columns. As you know, the START_SCN
pseudocolumn tells you when a row was created. The END_SCN tells you when
a row expired. All rows will have a START_SCN, but may have a NULL value for
the END_SCN if the version of the row still exists at the current SCN.
The Flashback Versions Query asks to bring all versions as of the SCN 113900.
The first row, which inserted (operation = I) the first_name TOM at 113855, is the
latest version of the row. Since the END_SCN is NULL for the first row, you know
that this row still exists at the SCN 113900. The middle row doesn’t have an END_
SCN either (NULL), so why is this row not the current incarnation of the row? If
you look under the OPERATION column, you
see the letter D, indicating that the middle row
was deleted. The bottom or third row has an
You must know how to tell END_SCN number, so clearly this row expired
the current, or live, version of a row when at SCN 113564.
you use the Flashback Versions Query Note that you could have substituted the
feature. You must understand when a row VERSIONS BETWEEN TIMESTAMP … for
expires and how an END_SCN of NULL the VERSIONS BETWEEN SCN nn AND nn
for a deleted row means that the row no clause, if you decided to use timestamps instead
longer exists. of SCNs to specify the time interval for retrieving
the various versions of the row.
Restrictions and Observations on Flashback Versions Query

The following requirements and limitations apply to the Flashback Versions Query
feature:
■ You can’t use this feature to query a view.

■ Your VERSIONS clause can’t be applied across DDL operations.
■ The query will ignore changes in row data that are purely physical, as is the
case during a segment shrink operation.
■ You can’t use this feature to query external temporary and fixed tables.
If you want to query past data at a precise time, you must use an SCN. If you use
a timestamp, the actual time queried might be up to three seconds earlier than
the time you specify. Internally, Oracle Database uses SCNs, which are mapped
to timestamps, with a granularity of three seconds. This time-to-SCN mapping
gap may throw you off if you’re trying to flashback to an exact time in the past
that’s immediately after a DDL operation. Your entire table might be gone, and
you’ll get a major error instead of the Flashback Versions Query results!
If you omit the AS OF clause clock time or SCN if you have specified
in a Flashback Versions Query, data is either one.
retrieved as of the current SCN, or the
Flashback Transaction Query

Oracle Database 10g provides a new view called Flashback Transaction Query that lets
you identify which transaction or transactions were responsible for certain changes
during a certain interval. A Flashback Transaction Query is a query on the FLASHBACK_
TRANSACTION_QUERY view. Using a Flashback Transaction Query, you can obtain
transaction information, including the necessary SQL statements to undo all the changes
made by a transaction. This feature enables you not only to correct logical errors, but also
conduct transaction audits in your database.
You are probably well aware of the use of Oracle’s LogMiner tool to undo SQL
statements. However, LogMiner has a serious drawback: Oracle must serially read
entire redo log files to get to the necessary information. The Flashback Transaction
Query feature lets you use an indexed access path to quickly get to the necessary
undo data directly, instead of traversing through an entire redo log file. In addition,
you can correct the effects of a single transaction or a set of bad transactions during
an interval of time.
Using the Flashback Transaction Query Feature

The Flashback Transaction Query feature lets you view all database chages at the
transaction level, in order to recover from suer errors or to audit transactions..A new
Oracle 10g view called FLASHBACK_TRANSACTION_QUERY enables you to query
past transactions and correct them, if necessary. Using the Flashback Transaction Query
feature simply means querying the FLASHBACK_TRANSACTION_QUERY view, to
gather information about changes made at the transaction level, as well as to retrieve
the SQL code to undo the changes made by the unwanted transactions.
The FLASHBACK_TRANSACTION_QUERY view contains several useful columns
that let you identify a transaction’s timestamp, the identity of the user that made
the transaction, the type of operations made during the transactions, as well the
undo statements necessary to retrieve the original row. Here’s the structure of the
FLASHBACK_TRANSACTION_QUERY view:
SQL> desc FLASHBACK_TRANSACTION_QUERY
Name Null? Type
----------------------------------------- -------- ----------
XID RAW(8)
START_SCN NUMBER
START_TIMESTAMP DATE
COMMIT_SCN NUMBER
COMMIT_TIMESTAMP DATE
LOGON_USER VARCHAR2(30)
UNDO_CHANGE# NUMBER
OPERATION VARCHAR2(32)
TABLE_NAME
VARCHAR2(256)
TABLE_OWNER VARCHAR2(32)
ROW_ID VARCHAR2(19)
UNDO_SQL
VARCHAR2(4000)
You must have the SELECT ANY TRANSACTION system privilege to query
the FLASHBACK_TRANSACTION_QUERY view.
In the preceding description, the various columns stand for the following items:
■ START_SCN and START_TIMESTAMP tell you when a certain row was

created.
■ COMMIT_SCN and COMMIT_TIMESTAMP provide information about
when a transaction was committed.
■ XID, ROW_ID, and the UNDO_CHANGE# help identify the transaction,
the row, and the undo change number, respectively.
■ OPERATION refers to the type of DML operation—update, insert, or delete .
Sometimes you’ll notice a transaction didn’t have enough undo

value of UNKNOWN under the OPERATION information to correctly identify its
column, instead of an INSERT, DELETE, operation type.
or an UPDATE. This simply means that the
■ LOGON_USER, TABLE_NAME, TABLE_

OWNER columns provide the name of the
user who made the changes, the table’s name,
The Flashback Transaction and its schema, respectively.
Query feature retrieves only committed ■ UNDO_SQL gives you the exact SQL
transactions. The query retrieves the statement to undo a transaction. Here’s an
deleted and subsequently reinserted rows. example of the type of data you would find
under the UNDO_SQL column:
SQL> select undo_sql from flashback_transaction_query
2 where table_owner = 'SAMALAPATI';
UNDO_SQL
------------------------------------------------------------------------
delete from "SAMALAPATI"."PERSONS" where ROWID = 'AAANZ+AAEAAAAIEAAG';
delete from "SAMALAPATI"."PERSONS" where ROWID = 'AAANZ+AAEAAAAIEAAF';
delete from "SAMALAPATI"."PERSONS" where ROWID = 'AAANZ+AAEAAAAIEAAE';
insert into "SAMALAPATI"."PERSONS"("NAME") values ('sam alapati');
insert into "SAMALAPATI"."PERSON"("NAME") values ('nina alapati');
The following Flashback Transaction Query uses the FLASHBACK_VERSIONS_

QUERY view to derive the transaction ID (XID), operation type, the start and commit
SCNs, the user’s name, and the SQL statement to undo the transaction.
SQL> select opEration, start_scn, logon_user,

undo_sql from flashback_transaction_query
where XID = HEXTORAW('0A001A00AD020000');
OPERATION START_SCN LOGON_USER UNDO_SQL
------------------------------------------------------------------
DELETE 6039310 SAMALAPATI insert into
“SAMALAPATI"."PERSONS"("NAME") Values ('nina alapati');
SQL>
In our simple example, there is only a single delete operation that you need to
perform, in case you wish to undo the changes made by this transaction. However,
transactions usually contain several DML statements, in which case you have to apply
the undo changes in the sequence that the query returns them in order to correctly
recover the data to its original state.
Using Flashback Transaction Query and

Flashback Versions Query Together
You’ve learned how you can derive a version history of the changes made to a table
using the Flashback Versions Query feature. This feature provides the various versions
(the what) of a row, along with their unique version IDs and other information such as
the timestamps and SCNs when the row versions were created. However, this feature
doesn’t have all the necessary information to correct the changed row data using
appropriate SQL statements to undo an undesirable change. The Flashback Transaction
Query feature provides you with the necessary information to identify not only the
type of operations performed on each version of a row, but also the necessary undo
SQL (the how) to put the rows back in their original state.
Let’s use a simple example to demonstrate how you can combine the Flashback
Versions Query and the Flashback Transaction Query features to undo undesirable
changes to your data.
First, let’s use the Flashback Versions Query feature to identify all the row versions
in a certain table that have changed in a certain time period. The following query lets
you do this:
SQL> select versions_xid XID, versions_startscn START_SCN,
versions_endscn END_SCN, versions_operation OPERATION,
empname, salary FROM hr.emp
versions between SCN MINVALUE and MAXVALUE
where empno = 111;
XID START_SCN END_SCN OPERATION EMPNAME SALARY
---------------- ---------- --------- ---------- ---------- ----------
0004000700000058 113855 I Tom 927
000200030000002D 113564 D Mike 555
000200030000002E 112670 113564 I Mike 555
3 rows selected
SQL>
In the previous query, let’s say we identified the second row, which indicates a
delete operation (D) as the culprit. By mistake, one of our users has incorrectly deleted
the row. All you need to do in order to extract the correct SQL to undo this delete
operation is to take the transaction ID (XID) from the Flashback Versions Query
shown in the previous section, and search for it in the FLASHBACK_TRANSACTION_
QUERY view. Here’s the query you’ll need to execute:
SQL> select xid, start_scn START, commit_scn commit,
operation op, logon_user user,
undo_sql from flashback_transaction_query
WHERE xid = HEXTORAW('000200030000002D');
XID START COMMIT OP USER UNDO_SQL
---------------- ----- ------ -- ---- ------------------------
000200030000002D 195243 195244 DELETE HR insert into "HR"."EMP"
("EMPNO","EMPNAME","SALARY") values ('111','Mike','655');
000200030000002D 195243 195244 INSERT HR delete from "HR"."DEPT"
where ROWID = 'AAAKD4AABAAAJ3BAAB';
000200030000002D 195243 195244 UPDATE HR update "HR"."EMP"

set "SALARY" = '555' where ROWID = 'AAAKD2AABAAAJ29AAA';
000200030000002D 195243 113565 BEGIN HR
4 rows selected
SQL>
Flashback Transaction Query Considerations

Here are a few cautions and restrictions involving the use of the Flashback Transaction
Query feature:
■ You may want to turn on minimal supplemental logging in order to support

operations involving chained rows and special storage structures such as
clustered tables.
■ If you query a transaction involving an IOT, an update operation is always
shown as a two-step delete/insert operation.
■ If your Flashback Transaction Query involves a dropped table or a dropped
user, it returns object numbers and user IDs instead of the object names and
usernames, respectively.
INSIDE THE EXAM
It is important for you to understand the flashback technique would you use when you
mechanism behind the various flashback drop a table accidentally? Which technique is
features. Understand that you rely on the flash best when you truncate a large table or apply
recovery area (Flashback Database), undo data partial changes in a large table? How about
(Flashback table, Flashback Transaction Query, when you use the wrong WHERE clause to
and Flashback Versions Query). What feature update a table? Know how and why you can
enables you to recover a dropped table (the use the Flashback Transaction Query and the
recycle bin)? Flashback Versions Query features together.
The test will contain questions relating The exam will contain questions relating to
to the flash recovery area. How do you the recycle bin. Know the difference between
configure the flash recovery area? How do the DROP TABLE and DROP TABLE
you monitor and size the flash recovery area? …PURGE commands. The test will probe your
You must know when to use each of the knowledge of the recycle bin object naming
flashback techniques. For example, what conventions. How can you flashback a table
INSIDE THE EXAM
more than once? When does the database flashback operation. Can you roll back a flashback
reclaim the space belonging to a dropped operation?
object? (Either use the PURGE command, The test will contain questions on flashback-
or the database must suffer space pressure.) related views like V$FLASHBACK_DATABASE_
What happens to the recycle bin contents LOG and V$FLASHBACK_DATABASE_STAT.
when you issue commands to drop a tablespace What do these two views help you do? (They
or a user? Know how to query objects in the help you size the flashback area and set the
recycle bin. What commands help you bypass flashback retention target.) How do you find
the recycle bin? out the flashback status for a database?
You must understand why you need
to enable row movement before a certain
CHAPTER SUMMARY
Oracle offers you the point-in-time recovery technologies to help you go back to a past
point in time in the event of a logical error. However, performing a point-in-time
recovery is time consuming, and the new flashback technology offers ways to undo
logical errors by simply “rewinding” the database or a table to a previous time. This
chapter introduced you to the new Oracle Database 10g flashback techniques that
enable you to perform effortless recovery at a row, table, and even the database level.
You first learned how the undo data forms the bedrock of the flashback
technology.You learned how to flashback a database as well as an individual table.
You reviewed the new recycle bin concept, which helps you recover dropped database
tables and their dependent objects.
You also learned how to use the Flashback Versions Query feature to discover all the
versions of a given row. You then learned how to use the Flashback Transaction Query
feature, which enables you to see the changes made by particular transactions and also
to undo any undesirable changes. You can use this feature to audit certain transactions
or to recover from logical errors.
Two-Minute Drill 39
❑ Flashback technology offers you ways of undoing logical errors at the database,
table, and row levels.
❑ The guaranteed undo retention feature is critical to the functioning of several
flashback features that rely on undo data.
❑ If you have a damaged disk or some physical corruption, you must still use the
traditional recovery techniques.
❑ Flashback technology uses undo data to query past data as well as to recover
from logical errors.
❑ Undo retention is the length of time Oracle retains undo data.
❑ By default, Oracle doesn’t guarantee undo retention.
❑ The default undo interval under guaranteed undo retention is 900 seconds.
❑ You can use the RETENTION GUARANTEE clause to institute guaranteed
undo retention, either when you create a tablespace, or later, by using the
ALTER TABLESPACE command.
❑ You can use either a system change number or regular clock time to tell Oracle
the time in the past that you want it to go back to.
❑ Oracle picks an SCN that’s within three seconds of the clock time that you
specify.
❑ The SCN_TO_TIMESTAMP SQL function converts an SCN to a calendar
time.
❑ The TIMESTAMP_TO_SCN function converts a timestamp to its
corresponding SCN.
Flashback Database
❑ The Flashback Database feature lets you take a database to a past point in time.
❑ The flashback Database feature enables point-in-time recoveries without backup
files and archived redo logs.
❑ The size of the logical error, not the size of the database, determines recovery
time when you use the flashback database feature.
❑ The flashback buffer logs images of altered data blocks in the database.
❑ Oracle uses the before images of the data blocks to reconstruct a datafile.
❑ The new background process RVWR is in charge of writing the contents
of the flashback buffer to the flashback database logs.
❑ Oracle stores all Flashback Database logs in the flashback recovery area,
and you can’t archive them.
❑ You can use all Flashback Database commands the same way in both RMAN
and SQL*Plus.
❑ If you’ve lost a datafile, or if you have resized a datafile during the relevant
period, you can’t use the Flashback Database feature.
❑ Since flashing back a database involves the rolling back of data to undo its
effects, you must roll forward the database using redo logs.
❑ To configure the Flashback Database feature, you must first set up your flash
recovery area and then set your retention target using the DB_FLASHBACK_
RETENTION_TARGET parameter. You can then turn the Flashback Database
feature on, with the ALTER DATABASE FLASHBACK ON command.
❑ You can turn the Flashback Database feature off with the ALTER
DATABASE FLASHBACK OFF command.
❑ If you disable the Flashback Database feature, Oracle deletes all the Flashback
Database logs in the flash recovery area.
❑ Oracle gives priority to the storing of recovery-related files (datafile copies,
incremental backups, and archived redo logs) over Flashback Database logs.
❑ The ESTIMATED_FLASHBACK_SIZE column of the V$FLASHBACK_
DATABASE_LOG view provides you with the estimated size of flashback data
needed to satisfy your retention target.
❑ The FLASHBACK_SIZE column of the V$FLASHBACK_DATABASE_LOG
view shows the current size of flashback data.
❑ The V$FLASHBACK_DATABASE_STATS view helps you monitor the I/O
overhead of logging flashback data.
❑ You can turn flashback data collection off for individual tablespaces after taking
the tablespaces offline first.
❑ You can flashback a database using a log sequence number, an SCN, or a time
specified by TIMESTAMP .
Two-Minute Drill 41
Flashback Drop
❑ The DROP TABLE command doesn’t drop a table right away, as in previous
versions.
❑ Oracle saves a table in the recycle bin after you issue the normal DROP TABLE
command.
❑ You can retrieve a dropped table by using the Flashback Drop feature.
❑ The command to retrieve a table is FLASHBACK TABLE table_name TO
BEFORE DROP.
❑ The DBA_FREE_SPACE view shows additional free space when you drop a
table, but Oracle doesn’t actually reclaim this space immediately.
❑ Oracle reclaims the space occupied by an object only after either the user or
the database purges the object permanently from the recycle bin.
❑ Oracle will try to keep dropped objects in the recycle bin as long as possible.
It purges objects automatically only when it’s under space pressure.
❑ You can view the contents of the recycle bin by using the DBA_RECYCLEBIN
and USER_RECYCLEBIN views, or the SHOW RECYCLEBIN command.
❑ The SHOW RECYCLEBIN command only shows those objects that you can
undrop.
❑ You can’t recover a truncated table.
❑ You can issue queries against a dropped table, provided you use the system-
given names.
❑ When you drop any object, Oracle renames all dependent objects that it
stores in the recycle bin.
❑ In the FLASHBACK TABLE … TO BEFORE DROP command, you can give
the original name of the object or its system-given name after it is stored in
the recycle bin.
❑ The PURGE option of the DROP TABLE command will remove a table
permanently from the database or from the recycle bin, if the object is being
stored there after renaming it.
❑ If there are several identically named tables in the recycle bin, the PURGE
command will remove the first table that you dropped.
❑ The PURGE TABLESPACE command removes a tablespace from the recycle bin.
❑ The PURGE TABLESPACE tablespace_name USER user_name

command will remove all objects of a user from the recycle bin.
❑ The DROP TABLESPACE …INCLUDING CONTENTS command drops all
the objects in the tablespace directly, bypassing the recycle bin.
❑ The PURGE RECYCLEBIN and the PURGE USER_RECYCLEBIN commands
remove all objects belonging to a user from the recycle bin.
❑ The PURGE DBA_RECYCLEBIN command will remove all objects from the
recycle bin.
❑ When you drop a user, Oracle permanently drops all of the user’s objects,
thereby bypassing the recycle bin.
❑ You can use the Flashback Drop feature only on non-SYSTEM, locally managed
tablespaces.
❑ Dependent objects of a table can be in either a locally managed or dictionary-
managed tablespace.
❑ Oracle doesn’t store a materialized view log, bitmap join indexes, or referential
integrity constraints in the recycle bin.
❑ You can’t use the Flashback Table feature if a table has fine-grained auditing
or a Virtual Private Database defined on it.
Flashback Table
❑ Using the Flashback Table feature, you can restore a table back to a point
in time.
❑ During a Flashback Table operation, the tables are online and in place.
❑ Oracle acquires exclusive DML locks on the table it is flashing back.
❑ All indexes and other dependent objects of a table that is being flashed back
will remain intact during the operation.
❑ Oracle uses undo data to roll back table data during the flashback operation.
❑ You must have the FLASHBACK ANY TABLE or FLASHBACK object
privileges on the table.
❑ You must also have the ALTER, INSERT, UPDATE, and DELETE privileges
on the table.
❑ You must enable row movement before you can flashback a table.
Two-Minute Drill 43
❑ You can flashback a table using a past SCN or a past time period, using the
TIMESTAMP function.
❑ You can undo a Flashback Table operation by simply using the FLASHBACK
TABLE command again.
❑ You can’t flashback a system or remote table.
❑ The flashback operation is a single transaction, so either the entire operation
succeeds, or the whole operation will fail.
❑ If you shrink a table or change any nonstorage attributes of a table, you can’t
flashback a table to a time before you made these changes.
❑ Oracle doesn’t flashback statistics of recovered tables and indexes.

❑ The Flashback Versions Query feature lets you query the history of a data
row by selecting all versions of a row.
❑ Oracle returns only committed versions of a row.
❑ You can use SCNs or timestamps to indicate the interval for the flashback
versions query feature.
❑ In addition to column values, Oracle will also provide values for the
pseudocolumn for each row version. The VERSIONS_XID pseudocolumn
gives you the unique transaction identifier for a row version.
❑ The VERSIONS_OPERATION pseudocolumn indicates the type of DML
activity that was performed on a particular version of a row.
❑ You can’t use the Flashback Versions Query feature to query a view, external
tables, temporary tables, and fixed tables.
❑ You can’t apply the VERSIONS clause across DDL operations.
❑ The Flashback Versions Query feature ignores purely physical changes like
those that occur during a segment shrink operation.
❑ The Flashback Transaction Query feature focuses on the changes made to
a row during a certain interval.
❑ The Flashback Transaction Query feature enables transaction audits and
the correction of logical errors.
❑ The Flashback Transaction Query operation is faster than the LogMiner

tool, because you use an indexed access path to quickly get to the appropriate
undo data.
❑ You use the Flashback Transaction Query feature by querying the FLASHBACK_
TRANSACTION_QUERY view.
❑ When you see the value UNKNOWN in the OPERATION column of the
FLASHBACK_TRANSACTION_QUERY view, it means that the transaction
didn’t have enough undo information to enable Oracle to correctly identify
its operation type.
❑ The UNDO_SQL column of the FLASHBACK_TRANSACTION_QUERY
view gives you the SQL necessary to undo the DML statement that changed
a row.
❑ You can use the Flashback Versions Query and Flashback Transaction Query
features together, to first identify the correct row version and then undo its
effects.
❑ When you use the Flashback Transaction Query on an IOT, an update operation
is shown as separate delete and insert statements.
❑ If you encounter a dropped user or table, the FLASHBACK_TRANSACTION_
QUERY view will show only the user IDs and object IDs, instead of usernames
and object names.
Self Test 45
SELF TEST
1. What is the purpose of the flashback technology in Oracle Database 10g?
A. Recovery from physical corruption of a data file
B. Recovery from physical and logical corruption of a data file
C. Recovery from logical corruption of a data file
D. Recovery from a problem brought on by a damaged disk drive
2. The initialization parameter UNDO_RETENTION is used for what purpose?
A. To specify the length of time Oracle must retain undo data in the undo tablespace
B. To specify the length of time Oracle must retain undo data in the flash recovery area
C. To specify the length of time Oracle must retain undo data in the data files
D. To specify the length of time Oracle will retain undo data in the flashback database logs
3. Which one (or more) of the following is true?
A. Oracle guarantees undo retention by default.
B. Oracle doesn’t guarantee undo retention by default.
C. The default undo interval is 1440 minutes (1 day).
D. The default undo interval is 900 seconds (15 minutes).
4. Which of the following statements is true? (Please choose more than one answer.)
A. Oracle uses clock times internally, but it maps them to SCN times.
B. Oracle uses SCNs internally, but it maps them to clock times.
C. Oracle will pick an SCN within three seconds of the clock time you specify.
D. Oracle will pick an SCN within one second of the clock time you specify.
Flashback Database
5. Which of the following statements is correct when you use the Flashback Database feature?
A. You don’t need to apply any archived logs at all.
B. You need to apply only one archived log during recovery.
C. You must apply all archived logs produced during the time interval covered by the flash
database operation.
D. You must apply archived logs only for a small amount of time, since the flashback database
logs will recover to a point just before the target time.
6. What should you do before you can turn the flashback database feature on?
A. Start the database with the STARTUP command.
B. Start the database with the STARTUP MOUNT command.
C. Start the database with the STARTUP MOUNT EXCLUSIVE command.
D. Start the database with the STARTUP NOMOUNT command.
7. What happens to the flashback database logs when you disable the flashback database feature?
A. Oracle will delete all the flashback database logs from the flash recovery area.
B. Oracle will archive all the flashback database logs that are currently in the flash recovery
area, and delete them afterwards.
C. Oracle will clear the flashback buffer area.
D. Oracle will leave the flashback database logs in the flash recovery area, and remove them
only when it’s under space pressure.
8. Which of the following views contains the ESTIMATED_FLASHBACK_SIZE column?
A. V$FLASHBACK_DATABASE_LOG view
B. V$FLASHBACK_DATABASE_STATS view
C. Both the V$FLASHBACK_DATABASE_LOG and the V$FLASHBACK_DATABASE_STATS
views have this column.
D. V$FLASHBACK_DATABASE view
Flashback Drop
9. What is the equivalent of the old DROP TABLE command in Oracle Database 10g?
A. DROP TABLE … TO BEFORE DROP
B. DROP TABLE works exactly the way it did in previous versions.
C. DROP TABLE … PURGE
D. DROP TABLE NO PURGE
10. Which one (or more) of the following statements is true?
A. The SHOW RECYCLEBIN command shows all objects that you can undrop.
B. The SHOW RECYCLEBIN command shows all objects that you can undrop and purge.
C. The DBA_RECYCLEBIN view shows all objects that you can undrop and purge.
D. The DBA_RECYCLEBIN only shows items that you can undrop.
11. After you drop a table using the DROP TABLE command,
Self Test 47
A. You can query the table by using its original name only.
B. You can query the table by using its new system-generated name only.
C. You can query the table by using the original or system-generated name.
D. You can’t query a table once you drop it.
12. When you use the command PURGE RECYCLEBIN,
A. Oracle will remove all the objects in the recycle bin that are owned by all users.
B. Oracle will only remove objects from the recycle bin that belong to the current user.
C. Oracle will remove only the tables belonging to the current user.
D. You must ensure that you have the SYSDBA privilege.
Flashback Table
13. The Flashback Table feature is ideal in which of the following situations?
A. When you drop a user
B. When you truncate a table
C. When you drop a table
D. When you update a table with the wrong WHERE clause by mistake
14. What kinds of privilege(s) are necessary for you to use the flashback table feature?
A. ALTER TABLE
B. FLASHBACK ANY TABLE
C. No special privileges are necessary—you must be the owner of the object.
D. FLASHBACK TABLE privilege on the table you are flashing back
15. Which one of the following statements is correct?
A. You must enable row movement in the table you are flashing back, because the flashback
operation doesn’t preserve Oracle ROWIDs.
B. You must disable row movement in the table you are flashing back, because the flashback
operation doesn’t preserve Oracle ROWIDs.
C. You must disable row movement in the table you are flashing back, because the flashback
operation preserves Oracle ROWIDs.
D. You must enable row movement in the table you are flashing back, because the flashback
operation preserves Oracle ROWIDs.
16. What is the most likely outcome if Oracle violates any constraints during a flashback table
operation?
A. The database continues to flashback the database, after logging a warning in the alert log.
B. The database abandons the flashback process and leaves the table in the state it is at that
point in time.
C. The database abandons the flashback process and leaves the tables as they were before the
start of the flashback operation.
D. You have to disable all constraints before you start a flashback database operation. Therefore,
there is no chance of your violating any table constraints.

17. Which row or rows does the flashback versions query generate?
A. All committed versions of a row
B. All committed and uncommitted versions of a row
C. Only the most recent committed version of a row
D. The oldest committed row
18. What do the pseudocolumns of a flashback versions query tell you?
A. When a row version was first created
B. What kind of DML operation was performed on a row
C. The UNDO statement(s) necessary to undo the results of a transaction
D. The REDO statement(s) necessary to undo the results of a transaction
19. Which of the following statement (or statements) is true?
A. The flashback transaction query relies on the FLASHBACK_TRANSACTION_QUERY view.
B. The flashback transaction query relies on the FLASHBACK_TRANSACTION_QUERY
procedure.
C. The flashback transaction query cannot be used together with the flashback versions query
feature.
D. The flashback transaction query can be used together with the flashback versions query
feature.
20. Which of the following statements is true?
A. The VERSIONS_XID column of the FLASHBACK_TRANSACTION_QUERY view maps to
the VERSIONS_XID pseudocolumn shown in the output of a FLASHBACK_VERSIONS_
QUERY select statement.
Lab Question 49
B. The XID column of the FLASHBACK_VERSIONS_QUERY view maps to the VERSIONS_

XID pseudocolumn shown in the output of a FLASHBACK_VERSIONS_QUERY select
statement.
C. The XID column of the FLASHBACK_TRANSACTION_QUERY view maps to the
VERSIONS_XID pseudocolumn shown in the output of a FLASHBACK_VERSIONS_
QUERY select statement.
D. The VERSIONS_XID column of the FLASHBACK_TRANSACTION_QUERY view maps to
the XID pseudocolumn shown in the output of a FLASHBACK_VERSIONS_QUERY select
statement.
LAB QUESTION
Create a table with an index, constraint, primary key, materialized view log, and a trigger. Drop the
table. Recover the table and its objects using the appropriate flashback techniques. Verify the results
to make sure you recovered all the objects of the table.
SELF TEST ANSWERS

1. þ C. The flashback technology is purely meant to address logical corruptions in data due
to user and application errors.
ý A and D are wrong because physical corruption of datafiles means that you must use the
traditional recovery techniques, which involve using backup data files. B is wrong since flashback
technology doesn’t address physical corruption of data.
2. þ A. The UNDO_RETENTION parameter specifies the time period that undo data is saved
in the undo segments, which are located in the undo tablespace.
ý B is wrong because Oracle doesn’t retain undo data in the flash recovery area. C is incorrect
since undo data is not saved in datafiles, but in the undo tablespace. D is wrong since flashback
database logs don’t contain undo data; they contain the changed images of Oracle data blocks.
3. þ B and D. B is correct because Oracle doesn’t guarantee undo retention by default. You
have to enable undo retention explicitly. D is correct because once you enable undo retention,
Oracle will save undo data for a default period of 900 seconds.
ý A is wrong because Oracle doesn’t guarantee undo retention by default. C is wrong because
the default undo interval is 900 seconds.
4. þ A and C. A is correct because Oracle uses clock times internally, but it maps them to SCNs.
C is correct because the time mapping granularity between Oracle’s clock times and SCNs is 3
seconds. Therefore, Oracle will pick an SCN within three seconds of clock time that you specify.
ý B is wrong because Oracle uses clock times internally and maps them to SCNs. D is
incorrect because the time mapping granularity is three seconds, not one second.
Flashback Database
5. þ D. When flashing back a database, the Flashback Dtabase logs you must apply will take
you to a point that’s a little bit before your target time. You must apply archive logs to roll
forward for that point on, to your target time.
ý A is wrong since you most likely will have to use some archived log(s). B is wrong since
there is no guarantee that a single archived log will be sufficient. The number of archived logs
you need will depend on the size of the archived logs and the amount of DML changes in your
database. C is wrong because you don’t have to apply any of the logs produced during the flashback
operation.
6. þ B and C. You must start the database in the MOUNT EXCLUSIVE mode before you can
configure the flashback database feature. If you have a single instance, the STARTUP MOUNT
command is sufficient. If you have a Real Application Cluster, you’ll have to use the analogous
MOUNT EXCLUSIVE command. Since I didn’t specify whether you are dealing with a single
instance or a Real Application Cluster, both B and C would be correct alternatives.
ý A is wrong since you can’t open the database before turning the flashback database feature on.
D is wrong since you have to be in the MOUNT, not in the UNMOUNT state, before turning the
flashback feature on.
7. þ A. Oracle will immediately delete all Flashback Database logs once you disable the flashback
database feature.
ý B is incorrect since Oracle never archives Flashback Database logs. C is wrong because Oracle
doesn’t clear the flashback buffer area when you disable the Dlashback Database feature. D is wrong
because Oracle deletes the Flashback Database logs immediately and doesn’t wait until it is under
space pressure.
8. þ C. Both the V$FLASHBACK_DATABASE_LOG and the V$FLASHBACK_DATABASE_
STATS views contain an identical column, the ESTIMATED_FLASHBACK_SIZE.
ý A and B are only partially correct, since they provide the name of only one of the views
that contains the column ESTIMATED_FLASHBACK_SIZE. D refers to a nonexistent view.
Flashback Drop
9. þ C. The DROP TABLE …PURGE command is the equivalent command to the old DROP
TABLE command, since it immediately drops the table permanently.
ý A is wrong since the command doesn’t drop a table—it recovers it after you drop it. B is
wrong because the Oracle Database 10g DROP TABLE command doesn’t drop a table right
away as in previous versions. D is wrong because it refers to a nonexistent command.
10. þ A and C. A is correct because the SHOW RECYCLEBIN command only shows the objects
you can undrop. C is correct because the DBA_RECYCLEBIN view shows all the objects you
can undrop and purge, under the CAN_UNDROP and CAN_PURGE columns, respectively.
ý B is wrong because the command doesn’t show objects you can purge. D is wrong because
the DBA_RECYCLEBIN also shows items you can purge.
11. þ B. Once you drop a table and it’s in the recycle bin, you can continue to make SELECT
statements against the table (but not the UPDATE, DELETE, and INSERT commands).
However, you’ll have to refer to the table by its system-generated name, since there may be
several tables in the recycle bin with the same original name.
ý A and C are wrong because you can’t address a table in the recycle bin by its original
name. D is wrong since you can query after you drop it, provided it’s in the recycle bin and you
address it by its new, system-generated name.
12. þ B. When you use the PURGE RECYCLEBIN command (or the PURGE USER_RECYCLEBIN
command), you get rid of all objects owned by the current user.
ý A is wrong because Oracle removes only the objects owned by the user issuing the PURGE
RECYCLEBIN command. C is wrong since Oracle removes all objects belonging to the current
user, not just tables. D is wrong because you must have the SYSDBA privilege only to use the
PURGE DBA_RECYCLEBIN command.
Flashback Table
13. þ D. You can use the Flashback Table feature to take the table back to a previous point in
time. Therefore, it is ideal in situations where you’ve updated a table with the wrong WHERE
clause.
ý A is wrong because when you drop a user (and the user’s objects), you need to flashback
the entire database. B is wrong because when you truncate a table, you are better off
performing a flashback database operation. C is incorrect since you can use the flashback drop
feature to bring back a table that you’ve accidentally dropped.
14. þ A, B, and D. A is correct because you must have the INSERT, DELETE, UPDATE,
and ALTER privileges on the table to which you want to apply the Flashback Table feature.
B is correct since the FLASHBACK ANY TABLE system privilege enables you to perform
the operation on any table in any schema. D is also correct since the FLASHBACK TABLE
privilege on the table you are flashing back is adequate to perform the operation.
ý C is wrong because you do need special privileges as explained by alternatives A, B, and D.
15. þ A. You must enable row movement before you perform a flashback database operation
because Oracle doesn’t preserve ROWIDs during the operation.
ý B and C are wrong since you must enable, not disable, row movement. D is wrong since
Oracle doesn’t preserve ROWIDs.
16. þ C. If Oracle encounters any constraint violations, it abandons the flashback process and
leaves the tables as they were before the start of the operation.
ý A is wrong because Oracle stops the flashback operation. B is incorrect since Oracle leaves
the table in its original state, not the current state. D is wrong since you don’t have to disable all
constraints before you start the flashback table operation. You may leave them in an enabled state.

17. þ A. The flashback versions query generates all committed versions of a row.
ý B is wrong because the query doesn’t produce any uncommitted versions of a row. C and D
are wrong since Oracle will output all the versions of a row.
18. þ A and B. The pseudocolumns of a flashback versions query provide information on when a
row version was first created (VERSION_STARTSCN and VERSION_STARTTIME columns)
and what kind of DML operation took place (the VERSIONS_OPERATION column) among
other things.
Lab Answer 53
ý C and D are wrong since the flashback versions query doesn’t provide any information
about undoing changes; it is the flashback transaction query that provides you with the undo
information.
19. þ A and D. A is correct since the flashback transaction query feature relies on the FLASHBACK_
TRANSACTION_QUERY view. D is correct since you can use the two features together to audit
transactions and to correct logical transaction errors.
ý B is wrong since FLASHBACK_TRANSACTION_QUERY is a view, not a procedure. C is
wrong since you can use the two features together.
20. þ C. The XID column belongs to the FLASHBACK_TRANSACTION_QUERY, and it maps
to the VERSIONS_XID pseudocolumn output by the flashback versions query select statement.
ý A, B, and D refer to the wrong source for the XID column and VERSION_XID pseudocolumn.
LAB ANSWER
A user drops a table and you should get it back by using the flashback command.
1. First, connect as sysdba, enable the database flashback, and set a retention time of one day.
SQL> connect sys/password as sysdba
SQL> alter system set db_flashback_retention_target = 1440; -- Ex: for two days.
SQL> alter database flashback on;
2. Next create your table called test_table.

SQL> create table test_table (
c1 number, c2 number, c3 varchar2(50));
Create a simple trigger on test_table.

SQL> create or replace trigger test_trigger
before delete or update or insert on
test_table
begin
null
end;
Add a primary key constraint to your table.
SQL> alter table flashback_table
add constraint pk1flashback_table
primary key (c1);
3. Create an index on the name column.

SQL> create index name_idx
on test_table(name);
4. Create a materialized view log on test_table and perform an insert into your table.
SQL> create a materialized view log on test_table;
SQL> begin
for this in 1..1000 loop
insert into test_table
(this, this + 100, ‘Test flashback…’);
end loop;
commit;
end;
5. Display all the objects and constraints that belong to the user.
SQL> select object_name, object_type
from user_objects
/
SQL> select constraint_name, constraint_type, table_name
from user_constraints
/
6. Now, drop the test table.

SQL> drop table test_table flashback cascade;
7. Again, display all the objects and constraints that belong to you. You can see that all the deleted
objects were renamed and still belong to you. Also, notice that Oracle has dropped and renamed
all of the table’s constraints as well..
SQL> select object_name, object_type
from user_objects ;
SQL> select constraint_name, constraint_type, table_name
from user_constraints;
8. Connect as SYSDBA and use the FLASHBACK TABLE command to recover a table and all its
possible dependent objects from the recycle bin.
SQL> flashback table
test_table to before drop;
9. Check the contents of your recycle bin.

SQL> select original_name, object_name, type, ts_name,
droptime, related, space
from dba_recyclebin
where original_name = ‘TEST_TABLE’;
SQL> flashback table test_table to before drop;
10. Verify that your test_table has been retrieved by using the following statement:
SQL> select count(*) from test_table;
Notice that the materialized view log was not flashed back. All the other objects, including the
constraints, were recovered successfully. The flashback procedures can’t recover materialized view logs.
Blind Folio 10:1
10
Automatic Storage
Management
10.01 Introduction to Automatic 10.04 Managing ASM Files

Storage Management
10.05 Migrating a Database to ASM
10.02 Managing the ASM Instance
10.03 Managing ASM Disk Groups
Q&A Self Test
Tuesday, August 31, 2004 10:17:59 AM
2 Chapter 10: Automatic Storage Management
A utomatic Storage Management (ASM) is one of Oracle Database 10g’s most important
and revolutionary enhancements. The Oracle Managed Files (OMF) feature, which
has Oracle create and name files for you, was introduced a couple of versions ago.
ASM is Oracle’s new feature that lets you finally completely automate your file management
tasks. ASM even enables you to bypass using a third-party Logical Volume Manager, mirroring
and striping your disks directly from within Oracle.
This chapter introduces you to ASM by first exploring its architecture. The
chapter then takes you through the details of administering ASM in your database.
Administering ASM means managing the ASM instance, disk groups, and ASM files.
You’ll also learn how to migrate to an ASM system using the RMAN.
Let’s start with a review of the nature of ASM and its architecture.
Introduction to Automatic Storage Management

Oracle DBAs sometimes maintain hundreds or even thousands of datafiles for each of
the databases they manage. File and I/O management, in fact, is typically one of the
largest consumers of a DBA’s time. Oracle introduces the new Automatic Storage
Management (ASM) system to simplify your management tasks by automating disk
and file management.
Every bit of data you have in Oracle is stored somewhere on a disk. Your job is to
help retrieve that data from disk as quickly as possible. Disk I/O is much slower than
accessing data currently in random access memory (RAM), and it often turns out
to be the single biggest bottleneck for busy OLTP systems. ASM not only simplifies
database storage administration, but it also optimizes the database storage layout for
the best performance. ASM is built on top of OMF, and it takes OMF much further
than simply having Oracle create and name files
for you. ASM acts as Oracle’s own Logical Volume
Manager (LVM), by handling striping and
You can’t use operating mirroring functions previously done by third-
system commands or utilities to access party tools. DBAs spend a lot of time worrying
ASM files. You must use the RMAN to about I/O load balancing. ASM has features that
copy ASM files. automatically perform load balancing for you!
Introduction to Automatic Storage Management 3
You don’t need to move to the new ASM system overnight. Instead, you can
continue using your present file systems and slowly migrate to ASM files over time.
Oracle lets you mingle operating system, OMF, and ASM files together in a single
database.
Benefits of ASM
ASM enables you to manage data by selecting the desired reliability and performance
characteristics for classes of data, rather than interacting with large storage systems on
a per-file basis. ASM file systems offer several benefits, including the following:
■ ASM prevents disk fragmentation, so there won’t be any need to perform

time-consuming relocation of data.
■ You can keep all your datafiles and tablespaces in an ASM storage system.
ASM will manage your datafiles, control files, redo logs, archive logs, RMAN
backup sets, and so on. You can manage database objects such as tablespaces
without needing to specify and track filenames.
■ Your DBA file management duties are simpler, because you’ll be dealing with
a few disk groups, instead of directly handling numerous datafiles. Managing
very large databases becomes simple when you use an ASM system.
■ ASM performs mirroring and striping, thus increasing reliability and
performance. Mirroring is applied on a file basis, rather than on a disk basis,
thus giving you more control over which files you want to protect.
■ ASM automatically balances I/O load in parallel across all available disk drives
to prevent hot spots and maximize performance. When you add new disks,
ASM automatically moves data around to balance I/O load among the
disks. ASM load-balances file activity by uniformly distributing file extents
across all disks in a disk group. This automatic online disk space reorganization
saves you plenty of time.
■ ASM helps you maintain redundant copies
of data to provide fault tolerance. If you
wish, you can build an ASM storage system
You can use an ASM on top of vendor-supplied reliable storage
storage system for any Oracle database mechanisms.
files, including datafiles, control files, ■ ASM is free! You don’t pay anything extra
online redo log files, archived redo logs, for the ASM feature, since it’s part of your
and RMAN backup sets. Oracle Database 10g Server software.
ASM Architecture
ASM has three important components: the ASM instance, disk groups, and ASM
files. ASM runs as a tiny enterprise of its own, with its own instance and background
processes, helping Oracle Database 10g manage its files.
ASM files are at the core of all ASM activity. You use ASM so you can use its
files for your database. Unlike in the case of normal Oracle operating system-based
database files, you don’t directly access ASM files. ASM files are part of larger entities
called ASM disk groups, which act as the default location for all your database files. You
use ASM disk groups to get to the ASM files. When you use ASM files, you don’t need
to refer to your tablespaces by filenames; you use simple disk group names instead.
You don’t need to change the way you manage your Oracle database when you
switch to an ASM storage system. You can even have your current operating system-
based files coexist with new datafiles that you create as ASM files. All your logical
concepts like extents, segments, and tablespaces remain intact in an ASM system.
Here’s a summary of the basic characteristics of an ASM-based storage system:
■ You can store all Oracle database files as ASM files. There is a one-to-one
mapping between an Oracle database file (datafile, control file, and so on)
and an ASM file.
■ An ASM disk group consists of a set of disk drives.
■ A database can have multiple disk groups.
■ An ASM disk group can also contain files from several disk groups.
■ An ASM file is always spread over all the disks in an ASM disk group. An ASM
file can belong to only one disk group.
■ ASM allocates disk space in units called allocation units. All ASM disks are
partitioned in allocation units of 1MB.
In order to use an ASM file system, you must first start an ASM instance, which
is somewhat like a small database instance (without its own database files). The ASM
instance manages the disk groups, and its main purpose is to help the database access
the ASM files. The Oracle database contacts the ASM instance for information
about the ASM datafiles, and then accesses those files directly on its own. Let’s look
at the ASM instance in detail in the following section.
Managing the ASM Instance 5
Managing the ASM Instance

Before you can use the ASM files, you must ensure that the ASM instance is up and
running. You create an ASM instance just as you would create any other Oracle instance.
The big difference is that you have only a handful of initialization parameters to set up
for an ASM instance. In addition, an ASM instance doesn’t mount any Oracle database
files. Its main job is to maintain ASM file metadata, so the database can use it to access
the files directly.
In order to use ASM, you must have an ASM instance running on your server.
Unlike a normal Oracle database,an ASM instance doesn’t have a data dictionary,
making it necessary for you to connect only as an administrator, either through operating
system authentication as SYSDBA or SYSOPER, or by using a password file, if you’re
connecting remotely.
Here’s a summary of the ASM instance’s functions:
■ Manage disk groups

■ Protect disk groups
■ Communicate file metadata to database instances using the ASM files
Creating an Instance
To create an ASM instance, you must have the SYSDBA privilege. You can perform
most managing tasks (except creating the instance and a few others) with just the
SYSOPER privilege. Of course, you must also belong to an operating system group that
has the privileges to connect as a SYSDBA, a group like the typical dba group. If you
connect as a SYSDBA, you’ll have complete administrative privileges in an ASM
instance. If you connect as a user with the SYSOPER privilege, you’ll have the ability
to execute the following commands:
■ STARTUP/SHUTDOWN
You must issue all disk ■ ALTER DISKGROUP CHECK
group management commands from within ■ ALTER DISKGROUP MOUNT/DISMOUNT
an ASM instance. You database has no /REMOUNT
direct connection to ASM disk groups.
■ ALTER DISKGROUP OFFLINE
In addition to the right to execute these commands, a SYSOPER privilege holder

can also use all the data dictionary views associated with an ASM instance. The
SYSDBA privilege lets you perform all the listed commands, as well as the more
powerful CREATE DISKGROUP, ADD DISK, DROP DISK commands and the
RESIZE clause in the ALTER DISKGROUP statement..
An ASM instance takes up about 100MB of space. Most ASM instances should
need no more than 64MB of SGA.
Initialization Parameters for the ASM Instance

You must create an initialization parameter file to create a new ASM instance.
Fortunately, since the ASM instance doesn’t have its own datafiles and the like,
you’ll need to configure only a minimal number of initialization parameters.
If you set only one parameter—INSTANCE_TYPE—correctly (INSTANCE_

TYPE=ASM), Oracle will start up the ASM instance with default values for all
the other parameters.
The following are the key initialization parameters that you must configure for
your ASM instance.
■ INSTANCE_TYPE You must set the
INSTANCE_TYPE parameter to ASM.
■ DB_UNIQUE_NAME You normally won’t
If you don’t explicitly set need to set this parameter, as it applies only
the INSTANCE_TYPE parameter to ASM, to ASM within a cluster or on a node. The
your ASM instance will fail to start. The parameter shows the unique name for a group
default value for this parameter is RDBMS, of ASM instances in a cluster or on a node.
which is applicable to normal Oracle The default value for this parameter is +ASM.
databases. Change this only if you think you’re going to
have more than one ASM instance running
on the same node.
■ ASM_POWER_LIMIT This parameter indicates the maximum speed to be
used by this ASM instance during a disk rebalance operation. When you add
or delete individual disks, ASM moves around an amount of data equal to the
storage you are adding or reducing from a disk group. ASM does this so it can
evenly redistribute the datafiles and balance I/O load across the disks. The
default for this parameter is 1, and the range is 1 to 11 (1 is slowest and 11
fastest). You have the option of specifying the rebalance speed by using the
POWER clause in the disk REBALANCE command, as in this example:
ALTER DISKGROUP dgroup1 REBALANCE POWER 4;
■ ASM_DISKSTRING This parameter sets

the disk location for Oracle to consider during
a disk-discovery process. When you add a
If you leave the ASM_ new disk to a disk group, for example, the
DISKSTRING parameter set as NULL, ASM ASM instance will discover the new disk by
will find all disks to which it has read/write looking up the directories listed in its ASM_
access during a disk-discovery process. DISKSTRING parameter. Thus, by setting
this parameter, you can limit the number of
disks that ASM considers for disk discovery. The default for this parameter is
NULL. It can take a list of values, as shown here:
ASM_DISKSTRING =’/dev/rdsk/*s1’, ‘/dev/rdsk/c1*
■ ASM_DISKGROUPS This parameter lets you specify the name of any disk
group that you want the ASM instance to automatically mount at instance
startup. The default value for this parameter is NULL. If you use an init.ora
text file, you must make sure to add the names of any disk groups that you
want to mount when the instance starts up. On the other hand, if you use an
SPFILE, Oracle will automatically make the necessary additions and deletions
to the SPFILE when you create, add, or drop a disk group.
The ASM instance uses the LARGE_POOL memory buffer. You should allocate
at least 8MB to this parameter, so it can serve the ASM instance effectively.
Creating the ASM Instance

You can either create the ASM instance manually, or use the DBCA to create it. You can
create an ASM instance through an init.ora file, just as you can create database instances
(see Exercise 10-1). An ASM instance usually requires bout 100MB of disk space.
EXERCISE 10-1
Creating an ASM instance

Let’s create an init.ora file with the five key ASM-related initialization parameters.
Here’s our init.ora file:
INSTANCE_TYPE=ASM
DB_UNIQUE_NAME= +ASM
ASM_POWER_LIMIT =1
ASM_DISKSTRING = ‘/dev/rdsk/*s1’, /dev/rdsk/c1*’
ASM_DISKGROUPS = dgroupA, dgroupB

LARGE_POOL_SIZE = 16M
Now, export your new ASM instance name and run the following commands:
$ export ORACLE_SID=ASM
$ sqlplus /nolog
SQL> connect / AS sysdba
SQL> startup
ASM instance started
ASM diskgroups mounted
Using the Database Configuration Assistant (DBCA) makes it very easy to create
an ASM instance. When you create a new Oracle database, as shown in Figure 10-1,
the DBCA offers you three storage options: file systems, raw devices, and ASM.
If you choose file systems or raw devices for storage, and you decide to use an ASM
file system later on, you’ll need to separately create your own ASM instance. However,
if you choose ASM for storage, the DBCA will check to see if an ASM instance aready
exists on your server. If it does, the DBCA will then show you the disk groups being
managed by that ASM instance and ask you to choose the disk groups for your new
Oracle database.
If you choose ASM as your storage mechanism and you haven’t already configured
an ASM instance, the DBCA will automatically create one for you, after asking you
to provide a username and password for the separate SYS user for the ASM instance
(you’ll need this for remote database access).
The DBCA automatically creates an entry in the oratab file on UNIX systems, so
the operating sytem is aware of the new instance. On Windows systems, the DBCA
creates the Oracle service and makes the appropriate Windows Registry entries. The
DBCA also creates a parameter file and a password file for the new ASM instance.
ASM Instance Architecture

An ASM instance has several background processes like the SMON, PMON, and
LGWR processes. In addition, there are two new background processes: ASM Rebalance
FIGURE 10-1 Using the DBCA to configure ASM during database creation
Master (RBAL) and ASM Rebalance (ARBn). Here’s what the two background
processes do:
■ The RBAL process is in charge of coordinating disk activity.

■ The ARBn processes (there could be several of these, like ARB0, ARB1, and
so on) perform the actual rebalancing work like moving the data extents around.
In addition to the ASM instance background processes RBAL and ARBO, any
Oracle database instance that uses an ASM instance will have two new ASM-related
background processes, the RBAL and the ASM Background (ASMB) processes. This
is what these two new database processes do:
■ The RBAL process performs global opens of the disks in the ASM disk groups.
■ The ASMB background process connects as a foreground process into your ASM
instance. Remember that the ASM instance must be in operation in order for
your database to access ASM files. The ASMB

process acts as the link between the ASM
instance and your database instance,
The ASM Rebalance communicating information like datafile
(ARBn) process performs the actual creation, deletion, updating statistics, and
disk rebalancing work. performing instance health checks.
Managing an ASM Instance

You can use the OEM Database Control to manage all aspects of the ASM instance. The
home page of the Database Control shows the status of your ASM instance. From the
ASM home page, you can click the Configuration tab to go the ASM Configuration
page, where, you can modify your current ASM instance parameters. You can also go
to the Automatic Storage Management home page and check on ASM instance
performance issues, like I/O response time and throughput for the disk groups being
managed by your ASM instance.
You can also use manual commands to start up and shut down the ASM instance.
Let’s review the startup and shutdown procedures for ASM instances in the following
sections.
Oracle databases expect ASM instances following a host bootup.

the ASM instance to be always running, so In Windows, for example, you should make
they can access the ASM files. You should the ASM instance an automatically started
set up automatic startup procedures for service.
Starting an ASM Instance

The STARTUP command for an ASM instance is quite similar to the STARTUP
command for your Oracle databases, with a couple of interesting differences. Make
sure you set the INSTANCE_TYPE parameter
to ASM, so Oracle knows it is an ASM instance,
not a regular Oracle database.
When starting an ASM During the mount phase of the normal Oracle
instance, you can use the STARTUP STARTUP command, an Oracle database reads
command with the NOMOUNT, MOUNT, the control file and mounts the file systems
RESTRICT and FORCE options.You specified in the control file. An ASM instance
can’t use the STARTUP OPEN syntax. doesn’t have any file systems to mount. Rather,
an ASM instance mounts the disk groups
specified by the initialization parameter ASM_DISKGROUPS. The NOMOUNT command

works in an analogous way to the way it works in regular Oracle databases: it starts
the ASM instance without mounting any disk groups.
In order to use the the MOUNT mode. There are no datafiles

ASM feature, you must have your ASM to open in an ASM instance, so you don’t
instance running. This, however, means use the OPEN option for the STARTUP
that you just start the ASM instance in command.
When you issue a STARTUP FORCE command, the ASM instance is shut down
with a STARTUP ABORT command before restarting it. If you use the STARTUP
RESTRICT command, it prevents any client Oracle database instances from connecting
to the ASM instance.
If you either start up your ENABLE RESTRICTED SESSION command

ASM instance with the STARTUP RESTRICT in a normal ASM instance, Oracle database
command or issue the ALTER SYSTEM instances can’t connect to the ASM instance.
Shutting Down an Instance

You shut down an ASM instance just as you would shut down a normal Oracle database.
$ sqlplus /nolog
SQL> connect / AS sysdba
Connected.
SQL> shutdown normalOn the Job: If the ASM instance fails, the
database instances connected to it will also shut down. However,
the reverse isn’t true; the failure of a database instance has
no impact on an ASM instance.
There are some caveats, however, in using the SHUTDOWN command in the case
of an ASM instance. The up and down status of all Oracle databases connected to
an ASM instance critically depend on the ASM instance’s status. If you shut down an
ASM instance, all Oracle databases currently connected to it will also shut down. When
you issue a SHUTDOWN command to an ASM instance, it forwards the SHUTDOWN
command, in the same mode, to the Oracle databases that are connected to the ASM
instance.
When an Oracle database instance will also apply, in the same mode,
uses ASM files by connecting to an ASM to all connected databases. For example,
instance, it will stay open only as long if you shut down the ASM instance with |
as its connection to the ASM instance is the SHUTDOWN IMMEDIATE comamnd,
intact. If the connection terminates, the all databases connected to that instance
Oracle instance will terminate as well. Any will also shut down in the SHUTDOWN
SHUTDOWN command you use in the ASM IMMEDIATE mode.
If you shut down an ASM instance in the NORMAL mode (use the SHUTDOWN
NORMAL command or just the SHUTDOWN command), the ASM instance waits for
all connected Oracle database instances to terminate their ASM connections before
shutting down. In the IMMEDIATE (and TRANSACTIONAL) mode, an ASM instance
waits until all currently executing SQL in the dependent databases completes, but
doesn’t wait for the database instances to disconnect.
If you issue the SHUTDOWN ABORT command, the following events occur:
■ The ASM instance instantly aborts.

■ All open connections to the ASM instances are terminated.
■ As a result of connections to the ASM terminating, all dependent Oracle
databases will terminate immediately.
Managing ASM Disk Groups

An ASM disk group is a collection of disks that is somewhat analogous to the logical
volumes created by an LVM from underlying physical disks. You manage the underlying
disks of a disk group indirectly, by managing the disk group. Thus, even if you have a
large number of disks, you can aggregate them into a very small number of disk groups,
which makes life easy for you. When you add storage to your ASM system, you simply
add disks to an ASM disk group. Therefore, if your database is growing at a fast rate,
Managing ASM Disk Groups 13
the total stoarge will increase, but the number of disk groups could remain at a small,
stable number.
Providing Performance and Redundancy with Disk Groups

One of the biggest selling points in switching to ASM file management for Oracle
databases is that it offers you both additional performance and protection, while decreasing
the management overhead, especially for large, mission-critical databases. These benefits
are similar to the benefits offered by LVM tools provided by third-party vendors. However,
the big advantage of ASM over the third-party tools is that the Oracle DBA can take
over most of the disk management tasks when using an ASM-based storage system.
You don’t need to be an expert in file sytems, RAID, or logical volumes to use ASM
files in your database. If you understand how ASM manages disk groups and how Oracle
accesses the database files that are spread over the the ASM disks, you are ready to
use ASM.
ASM can perform both striping and mirroring tasks better than a third-party
LVM, because it understands the Oracle file types and uses an appropriate
strategy for each type.
ASM provides both performance and redundancy, the first through striping and
the second through the mirroring of data on the disk drives. Let’s look at these two
features in the following sections.
ASM Striping
ASM systems use disk groups and disks, with your database files being stored on the ASM
disks. The way you place (or write) your database files over ASM disks plays a critical
role in determining I/O performance. To provide you with optimal I/O performance,
ASM stripes files across all the disks that are part of a disk group. For performance reasons,
you must use disks of the same type and performance capacity in a disk group.
ASM provides two types of data striping, depending on the database file type:
■ Coarse striping The most common striping scheme in an ASM system is

coarse striping, so called because the stripe size is a relatively large 1MB chunk
of file space. You may use coarse striping for all files in an Oracle database,
except the control files, online redo log files, and flashback files.
■ Fine striping Some of your database files, like redo log files, may need faster
access than others. To reduce file latency, ASM provides a fine striping scheme,
where the striping is in smaller chunk sizes of 128KB. If you have 20 disks in
your disk group, ASM would stripe your redo logs in 128KB sized chunks across
all 20 of the disks. Thus, when you perform I/O operations, you can access your
file data in parallel, thus improving performance. You may want to use fine
striping for control files, online redo log files, and flashback files.
ASM Mirroring
Disk mirroring provides data redundancy. If you lose a disk, you can use its mirror disk
to continue operations without missing a beat. ASM mirroring is not the same as an
operating sytem-level mirroring scheme, although the goal of both is to provide
redundancy. Operating system-based LVMs mirror entire disks. ASM mirrors extents.
Whenever ASM allocates an extent (also called the primary extent, as opposed to a
mirrored extent), it simultaneously allocates a mirror copy of the extent to one of the
disks in the same disk group. A disk could have its mirror extents on one or several disks
in the disk group.
When any disk in a disk group fails, ASM reconstructs the failed disk on the fly by
using the mirrored extents from the other disks in the disk group. What’s the advantage
to mirroring extents rather than mirroring disks? When ASM is reconstructing a lost
disk, your storage system will take a smaller I/O hit, because several disks are sharing
the I/O necessary to reconstruct the failed disk device.
Failure Groups You can lose the services of a disk not only when the disk drive
fails, but also if a shared resource such as a disk controller bites the dust. When a
SCSI disk controller fails, all the disks connected to it will be inaccessible. A set of
disks that can all fail because they share a common resource, is called a failure group.
When you are trying to protect your data by introducing redundancy, you do so on
the basis of failure groups. That is, if you want to ensure that you have redundancy,
you must store your mirrored copy in a separate failure group.
ASM never places a primary extent and its mirror copy in the same failure group.
Thus, even if you lose several disks in a failure group, ASM can survive the disaster,
by starting the reconstruction of the lost devices from the mirrored copies of their
extents from disks that are outside the disk’s failure group.
Types of ASM Mirroring ASM supports three types of disk mirroring, each
providing a different level of data redundancy. When you create a new ASM disk
group, you need to decide the level of disk mirroring you need:
■ External redundancy This type really doesn’t provide any mirroring. You
choose this level of mirroring when you are using operating system storage
array protection. Disk groups under this redundancy level don’t have any
failure groups.
■ Normal redundancy This type provides two-way mirroring. Since you mirror
through the creation of failure groups, you must have two failure groups, each
group relying on a separate disk controller. Two-way mirroring means that
when one copy of a file extent is written to a disk in failure group Group A,
a mirrored copy of the file extent is simultaneously written to a disk in failure
group Group B. Thus, to support a normal redundancy level, you must create
at least two failure groups.
■ High redundancy This type provides three-way mirroring, which means you
should have three failure groups, each controlled by a separate disk controller.
When one copy of a file extent is written to a disk in failure group Group A,
a mirrored copy of the file extent is simultaneously written to both a disk in
Group B and a disk in Group C. Thus, to support a normal redundancy level,
you must create at least three failure groups.
Creating a Disk Group

The easiest way to create a disk group is to use the Databae Control’s Disk Group
Adminstration page. You can select the redundancy level, disk group name, and the
list of disks that you want to be part of a disk group.
You can also create a disk group manually by using the CREATE DISKGROUP
command. For example, suppose that you have three SCSI disk controllers and a total
of twelve disks. Disks Diska1 through Diska4 are on a separate SCSI controller from
disks Diskb1 through Diskb4. Similarly, disks Diskc1 through Diskc4 are on yet another
disk controller. You can create three failure groups, each with four disks. The first
four disks, Diska1–a4, will be on disk controller 1; the second four disks, Diskb1–b4, will
be on disk controller 2; and the last four disks, Diskc1–c4, will be on disk controller 3.
First, start the ASM instance in the NOMOUNT mode. (If you want to access
previously created diskgroups, you must use the MOUNT mode.) If none exists, the
instance is ready for you to create a disk group now. Then you can create your
three disk groups to correspond with your three failure groups, using the CREATE
DISKGROUP command, as shown here:
% sqlplus /nolog
SQL> connect / as sysdba
SQL> startup nomount
SQL> create diskgroup test_group1 high redundancy 2 failgroup groupA disk

3 ‘/devices/diska1’,
6 '/devices/diska4',
7 failgroup groupB disk
8 '/devices/diskb1',
11 '/devices/diskb4';
12 failgroup groupC disk
13 ‘/devices/diskc1’,
Oracle uses the search string of the format /devices/diska1 to find the disks
on your system. The use of the FAILGROUP and REDUNDANCY keywords is purely
optional. If you don’t specify the FAILGROUP keyword, each disk in the disk group
will be in its own failure group.
Here are the implications of using the HIGH REDUNDACY setting for the new
disk group, test_group1:
■ There are three failure groups, each defined by the FAILGROUP keyword
(you must have at least three failure groups if you specify high redundancy).
■ Each of the failure groups has four disks.
■ When Oracle writes data to the disks in the first failure group, GroupA, it
also writes those extents to disks in the other two failure groups, GroupB
and GroupC.
When you create a new disk of the disk group in the inita.ora file, Oracle
group, ASM will automatically mount it. will automatically mount it the next time
Don’t forget to add the diskgroup’s name to you start the instance. Of course, if you’re
your init.ora text file, if you don’t already using an SPFILE instead, Oracle will
have it there when you start the database automatically write the new disk group’s
in the NOMOUNT mode. If you put the name name in the SPFILE.
EXERCISE 10-2
Create a Disk Group

Create a disk group with two disk groups with normal redundancy. Notice the two
failure groups that this level of redundancy implies.
SQL> create diskgroup dgroup1 normal redundancy
failgroup controller1 disk
‘/dev/rdsk/c0t0d0s2’ name testdisk size 100G,
‘/dev/rdsk/c0t1d0s2’,
‘/dev/rdsk/c0t2d0s2’
failgroup controller2 disk
‘/dev/rdsk/c1t2d0s2’;
Adding Disks to a Disk Group

You use the ALTER DISKGROUP command to add a new disk to a disk group, as
shown here:
SQL> alter diskgroup test_group1 add disk
'/devices/diska5' name diska5,
'/devices/diska6' name diska6,
There are two interesting points to note in this example:
■ There is neither a FAILGROUP nor a REDUNDANCY specification for the

two new files. When you don’t specify a failure group for a disk, the disk is in
its own failure group.
■ There is a new NAME clause in this example. In the previous example, there
was no NAME clause. There, Oracle would assign its own system-generated
names.
Dropping Disks and Disk Groups

You use the ALTER DISKGROUP command to drop a disk from a disk group, as
shown here:
SQL> alter diskgroup test_group1 drop disk diska5;
You can use the UNDROP clause to keep a pending DROP DISK command from
taking place. If you’ve already dropped the disk, you can’t retrieve it with the UNDROP
clause. If you’ve used the optional FORCE clause when you dropped a disk, or if you’ve
issued a DROP DISKGROUP command, you can’t use the UNDROP clause. Here’s an
example demonstrating how to use the UNDROP clause in an ALTER DISKGROUP
command:
SQL> alter diskgroup test_group1 undrop disks;
This command will cancel the pending drop of all disks from the disk group test_group1.
In order to remove an entire disk group, you use the following command, after
putting the database in the MOUNT state.
SQL> drop diskgroup test_groupA including contents;
Rebalancing Disk Groups

One of the perennial concerns for a DBA is the existence of hot spots in the disk system,
which may lead to I/O bottlenecks. ASM rebalances a disk group automatically and
dynamically, whenever you add or remove a disk from a disk group. ASM strives for a
constant I/O balance across all the disks in a disk group. Thus, when you add new disks
or remove some disks, this I/O balance is disturbed, but ASM sets it right automatically.
It does this by simply moving just enough data around to match the space you added
or removed. For example, if you add a 14GB size disk, ASM will reassign only 14GB
of datafiles to rebalance the disk group.
Since there is some I/O impact on your system during disk group rebalancing
operations, you may be better off consolidating your disk add and remove operations,
so ASM needs to perform fewer rebalancing operations. Here’s an example of the disk
rebalancing command:
SQL> alter diskgroup dgroup1 rebalance power 5;
The POWER clause specifes the parallelization level for the REBALANCE command.
In other words, the POWER clause controls the speed of a rebalance operation. The
higher the POWER clause value, the faster ASM will complete the disk rebalancing
operation. The default for POWER is 1 (the default value for the ASM_POWER_LIMIT
Managing ASM Files 19
parameter). By specifying the POWER clause in a REBALANCE command, you can

override the power value set by the ASM_POWER_LIMIT initialization parameter.
You can increase the speed POWER_LIMIT initialization parameter; using

of a rebalancing operation, and thus minimize a high value for the POWER clause in a disk
the I/O impact of modifying ASM storage (by rebalance operation; or performing all your
adding or deleting disks), by doing any of the disk adding, resizing, and dropping operations
following things: raising the value of the ASM_ at the same time.
Managing ASM Files

ASM doesn’t create any datafiles like the datafiles you create when using operating
system files. When you use ASM file management, any datafile you create will become
an ASM file. You simply specify an ASM disk group, instead of a file or disk, when you
want to create a new datafile, redo log file, or control file. For example, you may create
a new tablespace called test_tbsp with the following command, if you’re using ASM
disk groups:
SQL> create tablespace test_tbsp datafile ‘+test_group1’;
You can’t use ASM to create alert, trace, binary, and password files.
In the previous command, the DATAFILE clause specifies a file type, indicating
that the file is going to be used as a datafile (rather than as a control file or online
redo log file, for example). The CREATE TABLESPACE command addresses a disk
group (test_group1), not a specific disk in the group. Indeed, there is no reference
to any specific datafile either.
ASM does create a datafile, but it is meaningless to compare it with datafiles that
you now use in your Oracle databases. The new ASM datafile will be spread over all the
disks in the disk group test_group1. Thus, you can’t back up a single disk to copy
the datafile. Unlike conventional database files, Oracle always creates every ASM file
with a specfic redundancy level and striping policy. These redundancy and striping
policies are set permanently for the files, and you specify the attributes when you create
disk groups, as you’ve seen earlier in this chapter.
Any database files that considers them ready for deletion), since they
you create by providing a user alias aren’t aren’t deemed OMF files. Only files created
automatically deleted by ASM (when Oracle by ASM will be automatically deleted.
All ASM files are OMF files, and Oracle will automatically delete them when you
don’t need them any longer. However, if you specify a user alias for an ASM file, that
file in’t considered an OMF file, so Oracle can’t automatically delete that file.
Let’s look at some special ASM file management issues in the following sections.
Types of ASM Filenames

In an ASM file system, you never need to know a filename when assigning that file
to a tablespace or some other object. You just refer to a disk group—that’s it! ASM
automatically generates the filenames. When you use ASM for an Oracle database file,
the operating system can’t see these files, but the RMAN and Oracle’s other tools can
view them.
To administer the files, you don’t need to know their individual names; you just
need to know the name of the disk group that contains the file. Of course, if you issue
a command like ALTER DATABASE BACKUP CONTROLFILE TO TRACE, you’ll see
the actual name of the ASM files in the output. If ASM uses a fully qualified name for
a datafile, you can see it in views like V$DATAFILE and V$LOGFILE.
You can’t use an ASM file system for administrative files like trace files, audit
files, alert logs, backup files, export files, tar files, and core files. Oracle stores
the ASM filenames in the control files and the RMAN recovery catalog, just as
it does with regular operating system-based files or OMF-based files.
You can name an ASM file in several ways, depending on whether you are creating
a file or referencing an already existing file. The naming convention may also depend
on whether you creating a single files or multiple files at once. The four main ASM
filenaming conventions are fully qualified ASM filenames, numeric ASM filenames,
alias ASM filenames, and incomplete ASM filenames. Here is an overview of how
they work:
■ You use fully qualified ASM filenames only for referencing existing ASM files.
■ You use numeric ASM filenames only for referencing existing ASM files.
■ You use alias ASM filenames for creating new ASM files, as well as referring
to existing ASM files. You use alias filenames with templates only for creating
new ASM files.
■ You use incomplete filenames (with or without an alias) only for file creation
operations.
The following sections describe the filename types in more detail.
Fully Qualified ASM Filenames

When ASM creates a file, it always uses a fully qualified filename. You use this fully
qualified name for referencing existing ASM files. Here’s the syntax of an ASM file using
a fully qualified filename:
+group/dbname/file_type/tag.file.incarnation
where:
■ group is the disk group name.

■ dbname is the name of the database to which the Oracle file belongs.
■ file_type shows the ASM file type, which maps to an Oracle file type. For
example, the ASM file type controlfile maps to an Oracle control file.
Similary, the ASM datafile and online_log file types map to Oracle
datafiles and online redo logs, respectively.
■ tag is type-specific information about the file, such as the tablespace name for
a datafile. A control file, for example, is mapped to the ASM tag CF (or BCF,
if it’s a backup control file). A datafile’s tag is always of the format ts_name>_
<file#>. An online redo log is mapped to the tag log_<thread#>.
■ file.incarnation is the file/incarnation number pair, used to ensure
uniqueness.
You can’t supply a fully qualified ASM filename while creating a new file.
Here’s an example of a fully qualified ASM filename:

+dgroup1/proddb/controlfile/CF.257.1
Realize that no matter what naming convention you use for an ASM file, Oracle will
always automatically generate a fully qualified ASM filename when you create a file.
Oracle also refers to a fully qualified ASM filename as a system alias. This is
because ASM will create and maintain these aliases, and you can’t modify them.
Numeric ASM Filenames

ASM derives numeric filenames from fully qualified ASM filenames and uses them to
refer to existing files. ASM doesn’t use numeric filenames in file creation and doesn’t
use these names while reporting file information to you. However, you can use these
abridged names to refer to any file. Here’s the form of a numeric filename:
+group.file.incarnation
Here is an example of a numeric ASM filename (the file number is 251 and the
incarnation number is 8675309).
+dgroup2.251.8675309
Alias ASM Filenames

You can use ASM alias files both when creating new ASM files and when referring to
existing files. The only thing common to alias ASM filenames and the previous two
types of ASM filenames is the disk group name.
In an alias ASM filename, once you first provide
the disk group name, you can provide your own
Make sure you understand name string to complete the filename. You can
that alias ASM filenames mean that the easily tell an alias ASM filename from the
files aren’t OMF-managed files. Thus, Oracle previously defined filenaming conventions
won’t automatically remove these files when because there aren’t any dotted pairs of numbers
it doesn’t have any further need for them. at the end of an alias ASM filename. Here’s an
example of an alias ASM filename:
+dgroup1/myfiles/control_file1
+dgroup2/mydir/second.dbf
Incomplete ASM Filenames

You can use an incomplete ASM filename only when creating files. Incomplete filenames
include just the group name and nothing else. Here’s an example of an incomplete ASM
filename:
+dgroup1
You may also use a template while using an incomplete ASM filename, as shown
in the following example.
+dgroup1(datafile)
In this example, the template, DATAFILE, is within the parentheses.
A template determines the attributes to be applied to a file when you create

a new file.
When you use an incomplete and striping characteristics for that file. For
ASM filename, the use of a template is example, when creating a datafile for a
optional. However, if you omit the template, tablespace, ASM will use the default template
ASM will use the default system template for a datafile file type if you don’t provide
for that file type to decide the redundancy a specific template in the filename.
Alias Filename Management

When you review the ASM files later in this chapter, you’ll see how Oracle automatically
generates fully qualified names for all the ASM files you create in your database. Alias
ASM filenames provide the capability to employ user-friendly filenames to substitute
for the cryptic system-generated filenames.
Creating Disk Group Directories for Alias Filenames

Oracle maintains a hierarchical directory structure for all the fully qualified filenames
in each disk group (along with any file aliases you may create, as shown later in this
chapter). If you intend to use alias ASM filenames, you must first create a directory
structure to support your alias filenaming conventions. For example, the following
statement creates a hierarchical directory for disk group dgroup1.
alter diskgroup dgroup1 add directory '+dgroup1/mydir';
Once you create the directory dgroup1/mydir as shown in the example, you can use
it to create alias ASM filenames, such as +dgroup1/mydir/control_file1
for a control file.
Using Templates with Aliases

You can also use a template to create an alias ASM filename. You can use template-based
ASM filenames only for creating new files. Here’s the syntax of a template-based alias ASM
filename:
dgroup(template_name)/alias
Here’s an example of an alias ASM filename with a template (where the template
name is SPFILE):
+dgroup1(spfile)/config1
Adding Aliases
If you don’t use an alias for a file at the file creation time, you can always modify a
filename later to add an alias for the file. You can add a filename alias or rename an
existing alias name, using the ADD ALIAS or RENAME ALIAS clause of the ALTER
DISKGROUP statement. Here’s an example that shows how you can replace a fully
qualified ASM filename with your own alias ASM filename:
alter diskgroup dgroup1 add alias '+dgroup1/mydir/second.dbf'
for '+dgroupA/sample/datafile/mytable.342.3';
You can also delete an alias by using the DROP ALIAS clause of the ALTER
DISKGROUP statement.
Dropping Files and Aliases from a Disk Group

Although ASM files are usually OMF files, there may be times when you use your own
aliases for some ASM files. As mentioned earlier, if you use your own aliases for ASM
files, those files won’t be automatically deleted by Oracle. In situations like this, you’ll
then need to use the DROP FILE command to drop those files and aliases.
Here is an example of dropping an alias name:
alter diskgroup dgroup1 drop file '+dgroup1/payroll/compensation.dbf';
The following is an example of using a system-generated filename to drop a

datafile:
alter diskgroup dgroup1
drop file '+dgroupA/sample/datafile/mytable.342.372642';
If you just drop a file alias, Oracle won’t drop the file. If you drop a file using
the DROP FILE command, however, Oracle drops both the file and its alias.
ASM Filename Usage

You have seen how you can use several forms of ASM filenames. You’ve also learned
how you can use different filenames for the same file. When do you use a particular form
of a filename? The correct form of the ASM filename you should use depends on the
context in which you are using the filename. Here’s a brief summary of when you should
use a particular type of ASM filename:
■ For referring to an existing file, you can use a fully qualified filename, a numeric
filename, or an alias filename (but not an alias name with a template or an
incomplete filename with or without a template).
■ For creating a single file, you can use any kind of filename, with the exception
of a fully qualified filename.
■ For creating multiple files, you use only an incomplete filename or an incomplete
filename with a template.
Since the very purpose in using ASM is to eliminate the need to specify filenames
when managing database files, you must avoid using the ASM filenames as much as
possible, even though most SQL commands will let you use them just like normal
filenames. For example, when you re-create a control file with the RESETLOGS option,
you may use the ASM filenames, as shown in the following example:
create controlfile reuse database "TEST" resetlogs archivelog
maxlogfiles 16
maxlogmembers 2
maxdatafiles 30
maxinstances 1
maxloghistory 226
logfile
group 1 ('+DGROUP1','+DGROUP2') size 100M,
group 2 ('+DGROUP1','+DGROUP2') size 100M
datafile
'+DGROUP1/db/datafile/system.260.3' size 500M,
'+DGROUP1/db/datafile/sysaux.259.3' size 500M
In the previous example, note that the datafiles already exist, so you can use
the fully qualified ASM filenames for the datafiles. As you know, fully qualified ASM
filenames can’t be used to create an ASM file—they can be used only to refer to
ASM files. The RESETLOGS option will re-create (reinitialize) the redo log files, so
you can use the incomplete ASM filename format for the redo log files. You can use
incomplete filenames only to create new ASM files, as shown earlier in this chapter.
ASM File Templates

You can’t create all ASM files with the same file attributes. File attributes in this context
refer to attributes like the redundancy level (external, normal, or high) and the striping
format (fine or coarse). For example, ideally, the file attributes of an online redo log
file must be different from those of datafiles. Oracle makes it easy for you to specify file
attributes by letting you use templates to specify the attributes when you are creating
files. These templates are applied to the individual files, but they are associated with
the disk group in which the files are created.
Whenever you create a disk group, Oracle establishes a set of initial system default
templates for that disk group. Each of the system templates will contain a set of specific
file attributes. When you create files under this disk group, you can choose from among
these Oracle-provided system templates. Table 10-1 shows some system templates and
the file attributes they imply.
An example will make the use of ASM file templates clear. Let’s say you want
to create a new tablespace called test_tbsp in an ASM file system. You know that
the tablespace will use datafiles (not online logs or control files). You thus use the
DATAFILE template for your tablespace:
SQL> create tablespace test_tbsp datafile ‘+test_group1’;
Your tablespace datafile will then inherit the default attributes of a DATAFILE
template (such as the coarse striping level).
You may alter the attributes of a default system template or create you own unique
templates, if you wish. However, you may not delete the default system templates.
The following example shows how you can create your template, called
PRODUCTION, using the ALTER DISKGROUP command.
SQL> alter diskgroup test_group1 add template production attributes (mirror fine)
TABLE 10-1 ASM Default File Group Templates
Template External Normal High

Name File Type Redundancy Redundancy Redundancy Striped
CONTROL Control files Unprotected 2-way mirror 3-way mirror Fine
DATAFILE Datafiles and copies Unprotected 2-way mirror 3-way mirror Coarse
ONLINELOG Online logs Unprotected 2-way mirror 3-way mirror Fine
ARCHIVELOG Archive logs Unprotected 2-way mirror 3-way mirror Coarse
Migrating a Database to ASM 27
Once you create the production template, you can create an ASM datafile using
that template. The datafile you create will inherit the attributes you specified for your
new PRODUCTION template (two-way mirroring and fine striping). Here’s how you
would create your new datafile using the PRODUCTION template (the disk group
test_group1 creates files based on the PRODUCTION template):
SQL> create tablespace test_tbsp2 datafile ‘+test_group1’;
If you want to drop a template, you may do so with the following command:
SQL> alter diskgroup test_group1 drop template production;
A template’s main once you create it using a certain

function is to simplify ASM file creation. template. If you wish to change an ASM
Templates are associated with a disk file’s attributes, you must use the RMAN
group, but they are applied to individual to copy the file into a new file with the
files. You can’t change a files’s attributes attributes you want.
Migrating a Database to ASM

Migrating your database to an ASM disk group-based storage system database is one of
the Oracle Database 10g upgrade certification objectives. Before we get to the actual
database migration procedures, let’s look at the necessary ASM-related initialization
parameter changes.
Setting Instance Parameters

You need to focus on the following initialization parameters when you create an ASM-
based Oracle database:
■ INSTANCE_TYPE When you create the ASM instance, the INSTANCE_

TYPE parameter is set to ASM. However, for normal databases, you can either
set this to RDBMS or leave it out, since the default value for this parameter is
RDBMS.
■ DB_BLOCK_SIZE The value of the DB_BLOCK_SIZE parameter must be

set to one of the standard block sizes: 2KB, 4KB, 8KB, 16KB, or 32KB.
■ LOG_ARCHIVE_FORMAT If you set the LOG_ARCHIVE_FORMAT to an
incomplete ASM filename (such as +dgroupA), Oracle will ignore it. If you
set it to an ASM directory, Oracle will use the directory and create non-OMF
files in that directory.
You must use incomplete ASM filenames (or incomplete ASM filenames with
a template) as the destination for the following initialization parameters:
■ DB_CREATE_FILE_DEST_n
■ DB_CREATE_FILE_DEST
■ DB_RECOVERY_FILE_DEST
■ CONTROL_FILES
■ LOG_ARCHIVE_DEST_n
■ LOG_ARCHIVE_DEST
■ STANDBY_ARCHIVE_DEST
Creating an ASM-Based Database

By specifying the following parameters, you can create an ASM disk group-based Oracle
database:
DB_CREATE_FILE_DEST = '+dgroup1'
DB_RECOVERY_FILE_DEST = '+dgroup2'
DB_RECOVERY_FILE_DEST_SIZE = 100G
The database creation statement is very simple, as shown here:

SQL> CREATE DATABASE test;
Oracle will create a SYSTEM tablespace and a SYSAUX tablespace in the disk
group dgroup1. An undo tablespace will also be created in dgroup1, if you’ve configured
automatic undo space management. A multiplexed redo file log group and a control
file will be created in both group1 and group2.
Adding datafiles is very easy in an ASM-based Oracle database, since you don’t
need to specify the datafiles. In the test database, you can use the following commands
to create a tablespace and add a new redo log file, respectively:
create tablespace test_tbsp;
alter database add logfile;
Migrating Your Database to ASM

The RMAN can help you migrate your current database to an ASM storage system. If
you want to migrate your current database to ASM disk groups, you may do so by using
the following steps (this example uses an SPFILE):
1. Shut down the database in a consistent mode (not SHUTDOWN ABORT).

2. Make the necessary changes to your SPFILE, so your database can use OMF
files. Set the OMF destinations for the initialization parameter you reviewed in
the previous section to their appropriate ASM destinations (ASM disk groups).
3. Delete the control file parameter from your SPFILE, since Oracle will
automatically create new control files by restoring them from the non-ASM
instance control files.
4. Start up the database using the command STARTUP NOMOUNT, and then
execute the following commands (as an RMAN script):
restore controlfile from ‘/u01/test/c1.ctl’;
alter database mount;
backup as copy database format ‘+dgroup1’;
switch database to copy;
SQL “alter database rename ‘/u01/test/log1’ to ‘+dgroup1’ “; -- for
each redo log member
SQL> “alter database open resetlogs”;

SQL ”alter tablespace temp add tempfile” –- for each temporary tablespace
SQL “alter database tempfile ‘/u01/temp1’ drop”;
5. The RMAN script will back up the database and switch current datafiles
to the backups. The script also renames all current online redo log files
and re-creates all temporary files for the temporary tablespace.
6. Delete all the old Oracle database files.
When you migrate to an rename the existing redo log files and
ASM database, Oracle will automatically re-create all the temporary files for
create the control files for you. Oracle will the temporary tablespace.
Using the Data Dictionary to Manage ASM

There are several new data dictionary views in Oracle 10g to help you manage
Automatic Storage Mangement. Let’s briefly review these new views (the first three
views have rows for both the ASM instance as well as your database instances).
V_ASM_DISKGROUP
■ In an ASM instance, this view provides information about a disk group. In
a database instance, this view contains one row for every ASM disk group
mounted by the ASM instance.
V_ASM_CLIENT
■ In an ASM instance, this view identifies all the client databases using various
disk groups. In a Database instance, the view contains one row for the ASM
instance if the database has any open ASM files.
V$ASM_DISK
■ In an ASM instance, this view contains one row for every disk discovered by
the ASM instance. In a database instance, the view will only contain rows for
disks in use by that database instance.
V$ASM_FILE
■ The V$ASM_FILE view contains one row for every ASM file in every disk
group mounted by the ASM instance.
V$ASM_TEMPLATE
■ This view contains one row for every template present in every disk group
mounted by the ASM instance.
V$ASM_OPERATION
■ The V$ASM_OPERATION view provides information about any active
long-running operations in the ASM instance. Several ASM commands like
REBALANCE and RESIZE, take considerable time to complete. The command
prompt may return right away when you use these commands, however. You
can use the V$ASM_OPERATION view to monitor these types of long-running
operations.
INSIDE THE EXAM
The exam concentrates evenly on all aspects an ASM instance? Rebalancing of disks in
of using ASM. From a conceptual point of a disk group is a significant ASM detail,
view, you need to understand the relationship and expect a question regarding rebalancing
between ASM files and disk groups on one operations or parameters.
hand, and Oracle database files on the other. You must understand how to refer to ASM
You must be able to answer questions on what files in different situations (for example, while
types of Oracle files you can store in an ASM creating a new control file). File aliases and
storage system. Pay particular attention to the file templates are also bound to show up in one
ASM instance parameter file and know the or more questions. Know how you use different
importance of each of the initialization filenaming syntax for various purposes (creating
parameters. The test focuses on the new and referring to files). What are file templates,
background processes in ASM-based systems, what do you define them on, and why do you
as well as the relationship between disk groups use them?
and failure groups. The test may also contain questions regarding
The test will probe into your knowledge migrating your current database to an ASM-
of the various startup and shutdown commands based system. You must clearly understand the
in an ASM-based system. Know the relationship steps of the migration process. Important points
between shutting down an ASM instance to remember are how Oracle handles the control
and the running of the connected Oracle file redo log files and datafiles for the newly
instances. For example, what happens to converted database. In other words, how does
the connected Oracle instances if you abort the database create the new files?
CHAPTER SUMMARY
This chapter reviewed the new Automatic Storage Management (ASM) feature of
Oracle Database 10g. ASM builds on the OMF files concept and now makes it possible
to manage large databases without needing to worry about naming database files. The
chapter showed you how managing disk groups is a far more efficient way of managing
storage than handling storage at the operating system file level.
You also learned how ASM rebalances files automatically when you add or remove
disks from disk groups. You learned how to configure and manage an ASM instance.
You then learned how to create and manage disk groups. ASM files use special naming
conventions, and you learned about the various types of ASM filenames in this chapter.
Toward the end of this chapter, you saw how to create ASM-based databases. You also
learned how to migrate your current databases to an ASM-based storage system.
Two-Minute Drill 33
❑ ASM automates and optimizes database storage for optimal performance.
❑ ASM is built on top of OMF files.
❑ You need to use the RMAN to copy ASM files.
❑ You can mingle ASM, OMF, and operating system files together.
❑ ASM simplifies storage management because you deal with only a few disk
groups, not a large number of disks and datafiles.
❑ ASM automatically balances I/O load.
❑ ASM helps you maintain redundant copies of data to provide fault tolerance.
❑ You access ASM files by accessing ASM disk groups.

❑ You must have the SYSOPER privilege to create an ASM instance.
❑ The ASM instance doesn’t mount files. It mounts disk groups.
❑ The ASM instance’s main job is to maintain ASM file metadata.
❑ The ASM instance is in charge of communicating file metadata to the
database instances.
❑ In order to use ASM, the ASM instance must be running.
❑ Your database never connects directly to ASM disk groups.
❑ You must issue all disk group management commands from an ASM instance.
❑ The only initialization parameter that you must provide for an ASM instance
is the INSTANCE_TYPE parameter.
❑ The INSTANCE_TYPE parameter must be set to ASM for starting an ASM
instance.
❑ The ASM_POWER_LIMIT parameter determines the speed of a rebalance
operation.
❑ The ASM_DISKSTRING parameter limits the disk-discovery process.
❑ The ASM instance uses the LARGE_POOL memory.
❑ The ASM instance has two new background processes: RBAL and ARBn.
❑ The Oracle instance using ASM will have two new processes: RBAL and
ASMB.
❑ The ASMB process is the link between the Oracle database instance and
the ASM instance.
❑ You can’t use the STARTUP OPEN command for an ASM instance.
❑ If the ASM instance shuts down, all Oracle databases connected to the
instance will terminate as well.

❑ AN ASM disk group is a collection of disks.
❑ ASM provides redundancy through disk mirroring.
❑ ASM provides performance through disk striping.
❑ You can stripe your disks at a coarse or fine level.
❑ ASM mirrors extents, not entire disks.
❑ A set of disks that can all fail because they are connected to a common
resource is called a failure group.
❑ There are three levels of ASM redundancy: external, normal, and high.
❑ Normal redundancy involves two-way mirroring, and high redundancy
involves three-way mirroring.
❑ The number of failure groups determines the degree of redundancy.
❑ You can create disk groups with the CREATE DISKGROUP command. You
can alter them with the ALTER DISKGROUP command and drop them with
the DROP DISKGROUP command.
Managing ASM Files

❑ Oracle automatically deletes any unnecessary files only if they are OMF-
based files.
❑ When you create a tablespace, you don’t need to specify a datafile. Just use
a disk group’s name instead.
❑ You can see fully qualified filenames in the V$LOGFILE and
V$DATAFILE views.
❑ ASM uses fully qualified filenames to refer to a file.
Two-Minute Drill 35
❑ A fully qualified filename is also called a system alias.

❑ ASM derives numeric filenames from fully qualified filenames and uses them
to refer to existing files.
❑ You can use alias ASM filenames to create as well as refer to ASM files.
❑ You use incomplete filenames only to create files, not to refer to them.
❑ You must create disk group directories if you want to use alias filenames.
❑ You can drop a file and its alias using the DROP FILE clause in the ALTER
DISKGROUP command.
❑ ASM file templates let you specify file attributes when you are creating a file.
❑ You can alter the default system templates, but you can’t drop them.
❑ You can’t change a file’s attributes once you create it.
Migrating to ASM
❑ If you set your LOG_ARCHIVE_FORMAT initialization parameter to an
incomplete ASM filename, Oracle will ignore it.
❑ You must use incomplete ASM filenames, with or without a template, for
all initialization parameters that require a destination (except log files).
❑ You can use the RMAN to migrate your database to ASM.
❑ You can use the V$ASM_OPERATIONS view to monitor long-running ASM
operations.
SELF TEST

1. Which of the following statements about ASM instances is true?
A. ASM instances need to be open before Oracle can access ASM database files.
B. ASM instances need to be mounted before Oracle can access ASM database files.
C. ASM instances must be started, but in an unmounted state, before Oracle can access ASM
database files.
D. ASM instances need to be shut down before Oracle can access ASM database files.
2. You must use which type of commands to copy ASM files?
A. RMAN commands
B. OMF commands
C. Operating system commands
D. Logical Volume Manager commands
3. Which types of files can you use in a single database?
A. Either ASM or OMF files
B. OMF, ASM, and operating system files
C. OMF and ASM files
D. ASM and Logical Volume Manager-based operating system files
4. ASM performs load balancing by distributing which items?
A. File extents across all disks in a disk group
B. ASM disks across ASM disk groups
C. File extents across all disks in all disk groups
D. Heavily used tables uniformly across all disks in a disk group

5. What are the functions of an ASM instance?
A. Managing disk groups and communicating file metadata to the Oracle database using
ASM files
Self Test 37
B. Managing database files and communicating file metadata to the ASM instance using
ASM files
C. Managing disk groups and communicating file metadata to the RMAN
D. Protecting disk groups
6. What is the only initialization parameter that you absolutely must set to create an ASM instance?
A. DB_UNIQUE_NAME
B. INSTANCE_TYPE
C. ASM_POWER_LIMIT
D. ASM_DISKSTRING
7. What happens if you don’t set the ASM_DISKSTRING parameter for an ASM instance?
A. Your ASM instance won’t start.
B. Your Oracle database won’t be able to communicate with the ASM instance.
C. The disk-discovery process may take a longer time when you add a disk to a disk group.
D. ASM won’t perform disk discovery when you add a new disk to a disk group.
8. What does the ARBn background process do in an ASM instance?
A. Coordinates disk activity
B. Performs disk rebalance work
C. Coordinates disk rebalance work
D. Manages the RBAL process
9. When you start an ASM instance in the MOUNT mode, what does the instance mount?
A. Oracle database files
B. Individual ASM disks that belong to a particular database
C. Disk groups specified by the ASM_DISKGROUPS parameter
D. The instance doesn’t have any database files, so it doesn’t mount anything

10. What do ASM disk groups provide?
A. Redundancy through striping
B. Performance through mirroring
C. Redundancy through mirroring
D. Performance through striping
10. What does ASM stripe?

A. Database files across all the disk groups
B. ASM disks across all the disk groups
C. ASM disk groups across all the database files
D. Database files across all the disks in a disk group
12. What does ASM mirror?
A. Disks
B. Files
C. Extents
D. Disk groups
13. For two-way mirroring, how many failure groups do you need at a minimum?
A. None (two-way mirroring doesn’t need any failure groups)
B. One failure group
C. Two failure groups
D. Three failure groups
Managing ASM Files

14. Which of the following types of files will the database automatically delete?
A. All unnecessary files
B. All unnecessary ASM files without aliases
C. All unnecessary ASM files with aliases
D. All unnecessary ASM files with and without aliases
15. When can you use a fully qualified name?
A. Only to create a new ASM file
B. Only to refer to an ASM file
C. To create and to refer to an ASM file
D. For only ASM system files
16. What are incomplete filenames used for?
A. Referring to multiple files
B. Creating single files
C. Creating multiple files
D. Creating ASM system files
Lab questions 39
17. Which of the following is true about changing an ASM file’s attributes?
A. You must use the ALTER DISKGROUP command to alter the template.
B. You must use the ALTER DISKGROUP command to alter the file attributes directly.
C. You must use a new file alias for the file before altering its attributes.
D. You can’t change a file’s attributes after you create it.
Migrating to ASM
18. If you set the LOG_ARCHIVE_FORMAT initialization parameter to an ASM directory, what
will Oracle do?
A. Oracle will use the directory and create non-OMF files in that directory.
B. Oracle will use the directory and create OMF files in that directory.
C. Oracle will not use that directory, unless the online redo log files are also in an ASM directory.
D. Oracle will use the directory only if you use an incomplete ASM filename.
19. When you migrate your current database to ASM-based storage, what should you do with your
redo log files?
A. Rename them to ASM disk groups
B. Reinitialize the current online redo logs
C. Oracle will automatically copy them when you migrate to an ASM-based database
D. Copy them from their present locations to the ASM disk directly
20. What is the most important thing that the V$ASM_OPERATION view helps you do?
A. Monitor the success or failure of disk-balancing operations
B. Monitor long-running operations
C. Monitor the migration to an ASM instance
D. Monitor all disk groups to see if disk rebalancing is necessary
LAB QUESTIONS
1. Show how you would add a disk to an existing disk group.
2. Show how you would remove an existing disk group.
3. Show how you would undo the pending disk removal operation.
4. Show all your ASM disks using a data dictionary view.
5. Show all your ASM files using a data dictionary view.
6. Create a tablespace using an ASM disk group.
SELF TEST ANSWERS

1. þ B. The ASM instance must be mounted before Oracle can access the ASM database files.
When you start the ASM instance in the MOUNT mode, the instance mounts all the ASM disk
groups. Without accessing the disk groups, you can’t access the ASM datafiles that are on the
ASM disks.
ý A is wrong because an ASM instance cannot ever be opened like an Oracle database
instance. C is wrong because if the ASM instance isn’t mounted, you can’t access the ASM disk
groups. D is wrong since the ASM instance must be running for Oracle to access its ASM-based
database files.
2. þ A. You can copy ASM files only with RMAN commands.
ý B is wrong because there are no OMF commands to copy files. C is wrong since the
operating system doesn’t “see” ASM files, so it can’t manage them. D is wrong because you
don’t need a Logical Volume Manager to use with your ASM files.
3. þ B. You can use all three types of files—OMF, ASM, and operating system files—in the
same database.
ý A, C, and D specify the wrong combinations of files.
4. þ A. ASM performs I/O load balancing by distributing file extents uniformly across all disks
in a disk group.
ý B is wrong since ASM doesn’t perform load balancing through distributing disks across
disk groups. C is wrong because the file extents are spread only across disks in the same disk
group. D is wrong because ASM doesn’t deal with database tables in any way.

5. þ A and D. The key job of the ASM instance is to manage disk groups. It also communicates
information about the disk group to the Oracle database using ASM files. Another key task
managed by the ASM instance is protecting disk groups .
ý B is wrong because ASM doesn’t manage database files directly—that job falls to the
database. C is wrong because ASM doesn’t communicate file metadata to the RMAN.
6. þ B. The only ASM initialization parameter that you must set is the INSTANCE_TYPE
parameter. You must set it to a value of ASM to indicate to the Oracle executable that you are
starting an ASM instance, not a regular Oracle database instance.
ý A, C, and D are wrong because none of these parameters are necessary to start an ASM
instance. The instance can use the default values for all three parameters in order to start.
7. þ C. The ASM_DISKSTRING parameter specifies the location of the ASM disk groups. If
you don’t specify a value for this parameter, the disk-discovery process undertaken by ASM
instance will take a longer time, since it will look in all directories to which the ASM instance
has read/write access.
ý A is wrong because the ASM instance will start, even when you don’t specify a value for
the ASM_DISKSTRING parameter. B is wrong because the ASM instance will communicate
normally with the Oracle database. D is wrong because ASM will perform the disk-discovery
process, but it may take a longer time to do so if you omit the ASM_DISKSTRING parameter.
8. þ B. The ARBn background process performs the actual disk rebalancing work in an ASM
instance.
ý A and C are wrong since it is the RBAL background process that coordinates the disk
activity, not the ARBn process. D is wrong because the RBAL process manages the ARBn process,
not the other way around.
9. þ C. When you mount an ASM instance, the instance mounts the disk groups you specify
by using the ASM_DISKGROUPS initialization parameter.
ý A is wrong because ASM instances don’t mount Oracle database files. B is wrong since an
ASM instance mounts disk groups, not individual disks that are part of the disk group. D is wrong
since the ASM instance does mount disk groups.

10. þ C and D. Mirroring provides redundancy, and striping enhances performance.
ý A and B are wrong since they mix up the functions of mirroring and striping.
11. þ D. ASM stripes database files across all the disks in a disk group.
ý A is wrong because ASM doesn’t stripe database files across multiple disk groups. B and C
are wrong since ASM doesn’t stripe disks or disk groups—it stripes database files.
12. þ C. ASM mirroring is different from operating system mirroring in that it mirrors individual
extents, not disks.
ý A, B, and D refer to the wrong unit for ASM mirroring.
13. þ C. You need two failure groups at a minimum for two-way mirroring.
ý A is wrong because you do need failure groups for any mirroring. B is wrong because a single
failure group doesn’t ensure protection of any kind. D is wrong because three failure groups
provide three-way mirroring.
Managing ASM Files

14. þ B. The database will automatically delete all ASM files without aliases, because they are
considered OMF files.
ý A is wrong because the database will automatically delete only the OMF files, not all the
unnecessary files. B and D are wrong since Oracle considers files with aliases non-OMF files,
and therefore, it won’t automatically delete them.
15. þ B. You can use a fully qualified name only to refer to an ASM file.
ý A and C are wrong since you can’t use fully qualified names to create files. D is wrong since
you can use fully qualified names for nonsystem files.
16. þ C. Incomplete ASM filenames are used only for creating multiple files.
ý A is wrong because incomplete filenames can’t be used to merely refer to files. B is wrong
because incomplete filenames are not limited to creating single files. D is wrong since incomplete
filenames aren’t limited to system files.
17. þ D. You can’t change a file’s attributes once you create it.
ý A, B, and C are wrong since you can’t change a file’s attributes after creating it.
Migrating to ASM
18. þ A and D. A is correct because Oracle will create non-OMF files in that directory. D is
correct because Oracle will use the directory only if it has an incomplete ASM filename.
ý B is wrong since Oracle will create non-OMF files in that directory. C is wrong since Oracle
will use that directory.
19. þ A. When you migrate your database to ASM files, you must individually rename each of
your online redo log files to ASM disk groups.
ý B is wrong since you don’t reinitialize your online redo log files, as this would clear them.
C is wrong since Oracle will not automatically copy your online redo log files. D is wrong since
you copy the files to disk groups, not directly to the underlying disks.
20. þ B. The most important function of the V$ASM_OPERATION view is to help you monitor
long-running ASM operations.
ý A, C, and D are wrong since the V$ASM_OPERATION doesn’t help you monitor any of
these things.
Lab Answers
1. To add a disk to an existing disk group, use the following:
SQL> alter diskgroup dgroup1
add failgroup controller1
‘/dev/rdsk/c0t3d0s2’ NAME a5;
2. Remove an existing disk group as follows:

SQL> drop diskgroup dgroup1 including contents;
3. You can undo a pending disk removal operation with this command:
SQL> alter diskgroup dgora1 undrop disks;
4. To show all your ASM disks using a data dictionary view, use the following:
SQL> select name, failgroup, bytes_read, bytes_written
from v$asm_disk;
5. To show all your ASM files using a data dictionary view, use the following:
SQL> select group_number, file_number, bytes, type, striped
from v$asm_file;
6. Create a tablespace using an ASM disk group as follows:

SQL> create tablespace test_tbsp
datafile ‘+dgroup1’ size 500M
Blind Folio 11:1
11
Enhancements in
Analytical SQL and
Materialized Views
11.01 Enhancements in the MERGE Statement 11.04 Materialized View Enhancements

11.02 Using Partitioned Outer Joins ✓ Two-Minute Drill
11.03 Using the SQL MODEL Clause Q&A Self Test
Tuesday, August 31, 2004 1:57:46 PM
2 Chapter 11: Enhancements in Analytical SQL and Materialized Views
T his chapter deals with analytical SQL enhancements to support data warehousing
applications and enhancements to several materialized view features. You’ll start off
with a review of the analytical SQL enhancements in Oracle Database 10g. The MERGE
statement is now enhanced, with support for conditional statements. The new partitioned
outer joins help in the densification of data, which will yield better calculation performance for
several analytical queries, especially those dealing with time-series data. The brand-new MODEL
SQL clause provides spreadsheet-like array computations that are highly scalable, directly from
within your Oracle database.
Oracle Database 10g presents several improvements to the management of

materialized views, which are critical in data warehousing environments. Oracle
supports fast refresh for materialized join views under even more conditions now.
You can use the new procedure TUNE_MVIEW of the DBMS_ADVISOR package to
enhance the fast refresh and query rewrite capabilities of your materialized views.
You’ll also review several new materialized view enhancements like improvements
to the partition change tracking feature and materialized view refresh when you’re
using trusted, instead of enforced, constraints.
Let’s start the chapter with a discussion of the enhancements to the powerful
MERGE statement.
Enhancements in the MERGE Statement

The MERGE statement is primarily of value when you’re moving vast amounts of data
in a data warehousing application. When you are extracting data from a source system
into a data warehouse, not all of the data will be completely new. You may find that some
of the table rows are new, while others are modifications of existing data. Therefore, you’ll
need to insert some of the new data and also update some existing data with the new
data from the source. For example, if a sales transaction is completely new, you’ll insert
that row into the data warehouse table. If that particular transaction already exists, you’ll
merely update the necessary columns.
Oracle9i made available the highly useful MERGE statement, which enables you
conveniently perform both inserts and updates in a single SQL statement. You can
perform an UPDATE-ELSE-INSERT operation using a MERGE statement. Oracle
Enhancements in the MERGE Statement 3
has enhanced the MERGE statement in Oracle Database 10g. Let’s review the MERGE
statement prior to Oracle Database 10g, and then cover its new capabilities in the
following sections.
The Basic MERGE Statement

The basic MERGE statement has the following structure:
merge <hint> into <table_name>
using <table_view_or_query>
on (<condition>)
when matched then <update_clause>
when not matched then <insert_clause>;
Here’s a simple example of a basic MERGE statement, as of the Oracle9i version:

SQL> merge into sales s using new_sales n
on (s.sales_transaction_id = n.sales_transaction_id)
when matched then update
s_quantity = s_quantity + n_quantity, s_dollar = s_dollar + n_dollar
when not matched then insert (sales_quantity_sold, sales_dollar_amount)
values (n.sales_quantity_sold, n.sales_dollar_amount);
The ON condition (s.sales_transaction_id = n.sales_transaction_

id) determines if an update or an insert operation will take place. The previous
statement will update a row in the new_sales table, if that row already exists (the
sales_transaction_id column identifies the row). If there is no such row, Oracle will
insert a new row with values for the sales_quantity_sold and sales_dollar_amount
columns.
Conditional UPDATE and INSERT Statements

Rather than an unconditional insertion or updating of all the table rows, you may want
to insert or update data only when certain conditions are met. In Oracle Database 10g,
the MERGE statement has been enhanced to allow you to conditionally insert or delete
data. Now, Oracle allows you to use a WHERE clause in a MERGE statement’s UPDATE
or INSERT clause to conditionally update or insert data.
Here’s an example that shows how you can conditionally insert and update data
using a MERGE statement (note the USING clause in the MERGE statement):
SQL> merge using product_cChanges s -- Source table
into products p -- Destination table
on (p.prod_id = s.prod_id) -- Search/Join condition

when matched then update -- Update if join
set p.prod_list_price = s.prod_new_price
where p.prod_status <> “EXPIRED” -- Conditional update
when not matched then
insert -- Insert if not join
set p.prod_list_price = s.prod_new_price
where s.prod_status <> “EXPIRED” -- conditional insertNote that Oracle
will skip the insert or update operation if the statement doesn’t satisfy the
WHERE condition. Both the insert and the update operations would occur only if
the product is not an expired item. (where s.prod_status <> “EXPIRED”).
The DELETE Clause with the MERGE Statement

You can now use the MERGE statement with an optional DELETE clause in a MERGE
statement. However, you can’t use the DELETE clause independently in a MERGE statement,
as with the UPDATE or INSERT clause. You must embed the DELETE statement inside
the UPDATE statement. This means that the DELETE statement isn’t a “global” clause,
but rather works in the confines of the data affected by the UPDATE clause of the MERGE
statement. The following example shows how the DELETE clause is embedded within
the UPDATE clause.
SQL> merge using product_changes s
into products p on (d.prod_id = s.prod_id)
when matched then
update set d.prod_list_price = s.prod_new_price,
d.prod_status = s.prod_new_status
delete where (d.prod_status = “OLD_ITEM”)
when not matched then
insert (prod_id, prod_list_price, prod_status)
values (s.prod_id, s.prod_new_price, s.prod_new_status);
The preceding MERGE statement will first update the prod_list_price and the
prod_status columns of the product table wherever the join condition is true. The
join condition (d..prod_id = s.prod_id) joins the two tables, product (the source
table) and product_changes (the destination table).
Here are a couple of considerations when using the DELETE statement:
■ The DELETE clause affects only the rows that were updated by the MERGE
statement.
■ The MERGE statement will delete only the rows included in the join condition
specified by the ON clause.
Using Partitioned Outer Joins 5
When you use this MERGE statement, the

UPDATE clause fires first, and it may set some
of the prod_new_status values to expired. The
The DELETE clause in a DELETE clause will then remove all the rows
MERGE operation will evaluate only the whose prod_new_status value was set to expired
updated values (values updated by the by the UPDATE clause.The DELETE clause will
UPDATE clause) and not the original values not remove any other rows with the expired
that were evaluated by the UPDATE clause. status, unless they are part of the join defined
in the ON clause.
Using Partitioned Outer Joins

Oracle provides a rich set of analytical functions to help you in business reporting.
Using these functions, you can avoid the need to program tedious user-defined functions
and formulas. Prior to Oracle Database 10g, you had access to the following analytical
functions:
■ Ranking and percentile functions include cumulative distributions, percentile

ranks, and N-tiles.
■ Moving window calculations provide the capacity to compute sums and averages.
■ Lag/lead functions help you compute period-to-period changes.
■ First/last functions help you figure out the first and last values in an ordered
group.
■ Linear-regression functions help you calculate linear regression and other
related statistics.
Oracle Database 10g provides an extension of the SQL outer join concept to
improve the performance of analytical functions when they encounter data with
missing values for some combinations of dimension values. In the following sections,
I’ll introduce you to some basic data warehousing concepts and analytical processing
features, before explaining how to use partitioned outer joins to handle problems
caused by sparse data (data with missing values).
Fact Tables, Measures, and Dimensions

Fact tables contain the business data of an organization. Sales and inventory items are
two common examples of the type of data captured in a fact table. Of course, fact tables
contain facts, but the data is also referred to as a measure. Thus, sales in a sales fact
table and inventory in an inventory fact table are the measures. Literally, a measure
denotes what it is that you are measuring.
Fact tables often contain links to several entities like time, product, and market
region. For example, the fact table might tell you what a firm’s total sales are for the
year 2005. However, you are more likely to want the data to answer more meaningful
questions like, “What are our sales for dish detergents in the New York area during
the first quarter of 2005?” To answer questions like this, you use the concept of
dimensions.
A dimension is a means of dividing your data into meaningful categories. Using
dimensions, you can turn your raw facts into meaningful data. For example, for the
sales fact table, the correct dimensions may be time (year and quarters), product, and
region. It is customary in data warehousing applications to create small tables, called
dimension tables, to describe the various dimensions. These dimension tables serve as
the reference, or lookup, tables. The combination of several dimension values helps
you answer detailed analytical questions. For example, using the time, region, and
product dimension values, you can easily answer complex business questions like the
question posed in the previous paragraph.
The use of a central fact table and a number of dimension tables linked to it through
foreign keys is called a star schema in data warehousing circles. The primary key of
the fact table is usually a composite key that is made up of all of its foreign keys.
Dimension tables are usually organized along a hierarchical basis. Thus, the
detailed data in a dimension, which is normally collected at the lowest possible
level, is aggregated into more useful aggregates. When you move up a hierarchy, it
is called rolling up. Conversely, when you move down a hierarchy of a dimension,
it is called drilling down. For example, in the customers dimension, customers may
roll up to a city. The cities may be rolled up into a division. The division may be rolled
up into a region. Regions may, in turn, be rolled up into a country.
How Analytical Functions Process Data

Analytical SQL functions efficiently deliver complex summary, aggregation, and other
analytical results. In order to produce these results, analytical functions follow a methodical
processing order. Analytical processing usually follows a three-step sequence:
■ Grouping In the preliminary grouping step, Oracle performs the various

joins, WHERE, GROUP BY, and similar grouping operations.
■ Calculation (analysis) In this middle stage of analytical processing, the
result sets from the grouping step are divided into sets of rows called partitions.
The result set from the previous step could be broken into one, a few, or many
partitions. Oracle then hands the result set of the grouping process from the
previous step to the analytical functions. The middle stage is at the heart of
analytical function usage, since this where the analytical functions process
the rows of each of the partitions.
■ Output ordering Finally, Oracle hands you the output in the precise order
specified by any ORDER BY clause that you may specify at the end of your
query.
Data Densification
The concept of data densification has to do with the fact that you may view your
data in two different forms:
■ Dense data is when you have rows for all possible combinations of dimension
values, even when you don’t have any data (facts) for certain combinations.
■ You have sparse data when you don’t show any values for certain combinations of
dimension values, if you don’t have any data (facts) for those combinations.
In real life, data is usually sparse.
To understand why dense data is better, let’s say that you are dealing with time-
series data. If you have sparse data, you’ll have the problem of an inconsistent number
of rows for groups of dimensions. This makes it harder for you to use some SQL
analytical functions such as the lag and lead functions, which help you compute
period-to-period changes. These functions perform slowly, and the report formatting
would be uneven. Performance takes a big hit when you don’t have a row for each
combination of the dimensions.
Partitioned outer joins help turn sparse data into
dense data, thus helping you avoid the drawbacks
of using sparse data for analytical computations.
The partitioned outer join When you use a partitioned outer join, Oracle
is ideal for time dimensions, but it can be replaces the missing values along any dimensions.
used for any kind of dimensions. You thus have faster performance and a better
reporting format when you use partitioned outer joins. We’ll look at how partitioned
outer joins work after a quick review of Oracle’s join methods.
A Review of Oracle Join Methods

Let’s quickly review Oracle’s join methods before plunging into the partitioned outer
join concepts. Join queries combine rows from two or more tables, views, or materialized
views. Oracle performs a join whenever multiple tables appear in the query’s FROM
clause. The query’s SELECT list can select any columns from any of these tables.
The WHERE clause, also called the join condition, compares two columns, each from a
different table. To execute the join, Oracle combines pairs of rows, each containing
one row from each table for which the join condition evaluates to TRUE.
Oracle joins are of the following types:
■ Natural joins A natural join is based on all columns that have the same
name in the two tables. It selects rows from the two tables that have equal
values in the relevant columns.
■ Inner joins An inner join (also called a simple join) is a join of two or more
tables that returns only those rows that satisfy the join condition. An inner
join is the default join type for a join operation.
■ Outer joins An outer join extends the result of an inner join. An outer join
returns all rows that satisfy the join condition and also returns some or all of
those rows from one table for which no rows from the other satisfy the join
condition.
■ A left outer join performs an outer join of tables A and B and returns all
rows from table A. For all rows in table A that have no matching rows in
table B, Oracle returns NULL for any SELECT list expressions containing
columns of table B.
■ A right outer join performs an outer join of tables A and B and returns all
rows from table B. For all rows in table B that have no matching rows in
table A, Oracle returns NULL for any SELECT list expressions containing
columns of table A.
■ A full outer join performs an outer join and returns all rows from A and B,
extended with NULLs if they do not satisfy the join condition.
Partitioned Outer Joins

A partitioned outer join is nothing but an extension of an Oracle outer join. You use
partitioned outer joins to fill the gaps in sparse data. In order to use a partitioned outer
join, you add the PARTITION BY clause to the outer join clause. The PARTITION
BY clause partitions the rows in your query output on the basis of the expression you
provide within the clause.
Here’s the syntax of a partitioned outer join:
select .....
from table_reference
partition by (expr [, expr ]... )
right outer join table_reference
and
select .....
from table_reference
left outer join table_reference
partition by {expr [,expr ]...)
For example, suppose your SELECT list consists of three columns: product, time_
id, and quantity. The logical partitioning can be done on the basis of the following
condition:
partition by product order by time_id
The query output will be partitioned into groups by the product column. If there were
two products—bottles and cans—there would be two partitions. Once Oracle logically
partitions the query output, it applies the outer join to each of the logical partitions.
You can thus view the output of a partitioned outer join as a UNION of several outer
joins, consisiting of a join of each of the logical partitions with the other table in the
join. In the example, the bottle and can partitions are joined to the other table by
using the time_id column.
Sparse Data
Let’s look at a typical set of sparse data by using the following example, which shows the
weekly and year-to-date sales for the same set of 11 weeks in two years (2004 and 2005).
Select substr(p.prod_Name,1,15) product_name, t.calendar_year year,
t.calendar_week_number week, SUM(amount_sold) sales
from sales s, times t, products p
where s.time_id = t.time_id and s.prod_id = p.prod_id AND

p.prod_name in ('Bounce') and
t.calendar_year in (2004,2005) and
t.calendar_week_number between 20 and 30
group by p.prod_name, t.calendar_year, t.calendar_week_number;
PRODUCT_NAME YEAR WEEK SALES

--------------- ---------- ---------- ----------
Bounce 2004 20 801
Bounce 2004 21 4062.24
Bounce 2004 22 2043.16
Bounce 2004 23 2731.14
Bounce 2004 24 4419.36
Bounce 2004 27 2297.29
Bounce 2004 28 1443.13
Bounce 2004 29 1927.38
Bounce 2004 30 1927.38
Bounce 2005 20 1483.3
Bounce 2005 21 4184.49
Bounce 2005 22 2609.19
Bounce 2005 23 1416.95
Bounce 2005 24 3149.62
Bounce 2005 25 2645.98
Bounce 2005 27 2125.12
Bounce 2005 29 2467.92
Bounce 2005 30 2620.17
We should normally have a total of 22 rows (11 weeks for each year) of sales data.
However, we have a set of sparse data, with only 18 rows. Four rows are missing,
because we have no data for weeks 25 and 26 in the year 2004 and weeks 26 and 28
in the year 2005.
Making the Data Dense

Using the query with the partitioned outer join produces the following output, which
gets rid of the sparse data we had in the earlier query output. Instead of blanks, we now
have zero values. In the following query, let’s call our original query v, as we select
data from the table times, which we’ll refer to as t. Note that all 22 rows are retrieved
this time, leaving no gaps in our time series.
select product_name, t.year, t.week,
NVL(sales,0) dense_sales from

(select substr(p.prod_name,1,15) product_name,
t.calendar_year year, t.calendar_week_number week,
SUM(amount_sold) sales
from sales s, times t, products p
where s.time_id = t.time_id and s.prod_id = p.prod_id and
p.prod_name in ('Bounce') and
t.calendar_year in (2004,2005) and
t.calendar_week_number between 20 and 30
group by p.prod_name, t.calendar_year, t.calendar_week_number) v
partition by (v.product_name)
right outer join
(select distinct calendar_week_number week, calendar_year year
from times
where calendar_year IN (2004, 2005) and
calendar_week_number between 20 AND 30) t
on (v.week = t.week AND v.Year = t.Year)
order by t.year, t.week;
PRODUCT_NAME YEAR WEEK DENSE_SALES
--------------- ---------- ---------- -----------
Bounce 2004 20 801
Bounce 2004 21 4062.24
Bounce 2004 22 2043.16
Bounce 2004 23 2731.14
Bounce 2004 24 4419.36
Bounce 2004 25 0
Bounce 2004 26 0
Bounce 2004 27 2297.29
Bounce 2004 28 1443.13
Bounce 2004 29 1927.38
Bounce 2004 30 1927.38
Bounce 2005 20 1483.3
Bounce 2005 21 4184.49
Bounce 2005 22 2609.19
Bounce 2005 23 1416.95
Bounce 2005 24 3149.62
Bounce 2005 25 2645.98
Bounce 2005 26 0
Bounce 2005 27 2125.12
Bounce 2005 28 0
Bounce 2005 29 2467.92
Bounce 2005 30 2620.17
For the four added rows that had no sales data, the NVL function transformed the
NULL values to 0. This is how partitioned outer joins convert sparse data into a
dense form. You may also choose to replace the NULL values with the most recent
non-NULL values. To do this, you can add the IGNORE NULLS clause to the Oracle
LAST_VALUE and FIRST_VALUE functions.
Using the SQL MODEL Clause

It is common for Oracle users to process data using third-party tools, since Oracle SQL
has traditionally lacked sophisticated modeling capabilities to produce complex reports.
A basic example is the use of spreadsheets, which apply formulas to transform data into
new forms. In previous versions of Oracle, in order to produce these spreadsheet-like
reports, you needed to either download data into spreadsheet programs like Microsoft
Excel or use dedicated multidimensional online analytical processing (OLAP) servers
such as Oracle Express. For example, you might use Excel to convert your business
data into rule-based business models, with the help of various macros. But third-party
spreadsheet tools are cumbersome to use, and you need to expend considerable effort
and time to constantly import updated Oracle data into the spreadsheet programs.
Oracle Database 10g offers the extremely powerful MODEL clause, which enables the
use of SQL statements to categorize data and apply sophisticated formulas to produce
fancy reports directly from within the database itself. You can now produce highly
useful Oracle analytical queries, overcoming several drawbacks of Oracle SQL. With
the new MODEL clause, you can use normal SQL statements to create multidimensional
arrays and conduct complex interrow and interarray calculations on the array cells.
Here, you’ll learn how the MODEL clause produces its powerful results.
How the MODEL Clause Works

Oracle professionals commonly make heavy use of multiple table joins and unions when
dealing with complex data warehousing data. These techniques help you peform very
complex computations, but they are usually slow and computationally expensive. The
MODEL enhancement enables you to perform complex enterprise-level computations.
The MODEL clause provide interrow calculation functionality by enabling you to
create multidimensional arrays of your query data and letting you randomly access
the cells within the arrays. The way the MODEL clause addresses individual cells is
called symbolic cell addressing. The MODEL clause also performs symbolic array computation,
by transforming the individual cells using formulas, which it calls rules.
The MODEL clause enables you to apply business models to your existing data.
When you use the MODEL clause as part of a query, Oracle feeds the data retrieved
by the query to the MODEL clause. The MODEL clause rearranges the data into a
Using the SQL MODEL Clause 13
multidimensional array and applies your business rules to the individual elements of
the array. From the application of various user-specified business rules, Oracle derives
updated as well as newly created data. However, you won’t actually see an array as
your final form of the output, since Oracle will format the new and updated data
into a row format when it delivers the MODEL clause’s output to you.
The first step in a MODEL-based query is the creation of the multidimensional array.
The following section explains the basis of the arrays created by the MODEL clause.
Creating the Multidimensional Arrays

The MODEL clause creates the multidimensional arrays that are at the heart of its
functionality by mapping all the columns of the query that contains a MODEL clause
into the following three groups.
■ Partitions These are similar to the analytical function partitions described

earlier in this chapter. Basically, a partition is a result handed to the MODEL
clause by previous grouping operations. The MODEL clause is always
separately applied to the data within each partition.
■ Dimensions These are the same dimensions that you saw earlier in this
chapter; for example, they might be time, region, and product.
■ Measures Measures are the fact table data on which you are modeling your
report, such as sales or inventories. You can look at the aggregate measure as
consisting of a bunch of measure cells, with each of the cells identified by a
unique combination of dimensions. For example, if sales is your measure, then
the sales of detergents for the third quarter of 2004 in the New York region is
one cell of the measure, since you can have only one such unique combination
of your three dimensions: product (detergents), time (third quarter of 2004),
and region (New York region).
The next section looks at how the MODEL feature uses rules to modify your
multidimensional array data.
Transforming Array Data with Rules

A rule in the context of the MODEL clause is any business rule or formula you want
to apply to the array data created by the MODEL clause. You may, for example, use a
formula to forecast next year’s sales on the basis of the preceding two years’ sales data.
You create a simple forecasting formula that expresses your business reasoning, and
then pass it along to the MODEL clause as a rule.
You use the keyword RULES to indicate that you are specifying the rules that the
MODEL clause must apply to its multidimensional array data. For example, you could
specify a simple rule as follows:
MODEL
…
RULES
…
(sales['Kleenex', 2005] = sales['Kleenex', 2003] + sales['Kleenex', 2004]
…
This rule specifies that the sales of Kleenex for the year 2005 would be the sum of the
sales of Kleenex in the years 2003 and 2004.
When you specify the RULES keyword, you may also want to indicate whether the
rules you are specifying will be transforming existing data or inserting new rows of
data. By default, the RULES keyword operates with the UPSERT specification. That
is, if the measure cell on the left hand of a rule exists, Oracle will update it. Otherwise,
Oracle will create a new row with the measure cell values. Here’s an example:
MODEL
…
RULES UPSERT
sales (‘Kleenex, 2005) = sales (‘Kleenex, 2003’) + sales (‘Kleenex, 2004)
…
(MORE RULES HERE)
In this rules specification, if there is already a table or view row that shows the sales for
Kleenex in the year 2005, Oracle will update that row with the values derived from
applying the rule formula. If there is no such row, Oracle will create a new row to show
the forecasted sales of Kleenex for the year 2005.
If you don’t want Oracle to insert any new rows, but just update the existing rows,
you can change the default behavior of the RULES clause by specifying the UPDATE
option for all the rules, as shown here:
MODEL
…
RULES UPDATE
Sales (‘Kleenex, 2005) = sales (‘Kleenex, 2003’) + sales (‘Kleenex, 2004)
…
(MORE RULES HERE)
The previous two examples demonstrated how to apply different rule options at
the MODEL clause level. You may also specify rule options at the individual rule
level, as shown here:
RULES
(UPDATE sales (‘Kleenex, 2005) = sales (‘Kleenex, 2003’) + sales (‘Kleenex, 2004)
Using the SQL MODEL Clause 15
When you specify a rule option at the individual rule level as shown in this example,
the use of the RULES keyword is optional.
If you specify a rule option level, the MODEL level option applies to all
at the rule level, it will overrirde the RULES the rules. If you don’t specify an option
specification at the MODEL clause level. If at the MODEL level, the default UPSERT
you don’t specify a rule option at the rule option will prevail.
You can specify that Oracle should evaluate the rules in either of the following
two ways:
■ sequential order Oracle will evaluate a rule in the order it appears

in the MODEL clause.
■ automatic order Rather than evaluating a rule based on its order
of appearance in a list of several rules, Oracle will evaluate the rule on the
basis of the dependencies between the various rules in the MODEL clause.
If rule A depends on rule B, Oracle will evaluate rule B first, even though
rule A appears before rule B in the list of rules under the RULES keyword.
Sequential order is the default order of processing rules in a MODEL clause.
Producing the Final Output

As its output, the MODEL clause will give the results of applying your rules to the
multidimensional arrays it created from your table data. A MODEL-based SQL analytical
query typically uses an ORDER BY clause at the very end of the query to precisely order
its output.
You can use the optional RETURN UPDATED ROWS clause after the MODEL keyword
to specify that only the new values created by the MODEL statement should be returned.
These new values may either be updated values of a column or newly created rows.
When I say that the MODEL doesn’t update or insert rows into the table
clause will create or update rows, I strictly or views. To change the base table data, you
mean that the changes are shown in the must use the traditional INSERT, UPDATE,
MODEL clause output. The MODEL clause or MERGE statements.
A MODEL Clause Example

Let’s look at a simple SQL example that demonstrates the capabilities of the MODEL
clause. Here’s the query:
SQL> select country, product, year, sales
from sales_view
where country in ('Mexico', 'Canada')
MODEL
partition by (country) DIMENSION BY (product, year)
measures (sale sales)
rules
(sales['Kleenex', 2005] = sales['Kleenex', 2004] + sales['Kleenex',2003],
sales['Pampers', 2005] = sales['Pampers', 2004],
sales['All_Products', 2005] = sales['Kleenex', 2005] + sales['Pampers',2005])
order by country, product, year;
Sales units are the measure in this example. The query partitions the data by country
and form the measure cells consists of product and year combinations. The three rules
specify the following:
■ Total sales of Kleenex in 2005 are forecast as the sum of Kleenex sales in
the years 2003 and 2004.
■ Total sales of Pampers in the year 2005 are forecast to be the same as the
sales in 2004.
■ Total product sales in 2005 are computed as the sum of the Kleenex and
Pampers sales in 2005.
Here’s the output generated by using the preceding SQL statement with the MODEL
clause (the new data created by the MODEL clause is shown in boldface here):
COUNTRY PRODUCT YEAR SALES
-------------------- --------------- ---------- ----------
Mexico Kleenex 2002 2474.78
Mexico Pampers 2002 15215.16
Mexico All_Products 2005 90387.54
Materialized View Enhancements 17
Canada Kleenex 2002 2961.3

Canada Pampers 2002 22161.91
Canada All_Products 2005 101071.96
The SELECT clause first retrieves the product, year, and sales data for the two
countries (Mexico and Canada) and feeds it into the MODEL clause. The MODEL
clause takes this raw data and rearranges it into a multidimensional array, based on
the values of the PARTITION BY (country) and DIMENSION BY (product and
year) clauses. After the MODEL clause creates the array, it applies the three formulas
listed under the RULES clause to the data. It finally produces the resulting row data,
after ordering it by country, product, and year.
Note that the MODEL clause shows the original table or view data, as well as the
new data that the MODEL clause has calculated from the three rules supplied in the
MODEL clause. The MODEL clause applies the rules within each partition of data.
Materialized View Enhancements

Materialized views have storage structures like regular Oracle tables, and they are used
to hold aggregate or summary data. One of the biggest advantages of materialized views
is that you can use them to precompute joins on commonly used tables, called the detail
tables. Expensive joins and aggregates are precomputed and stored by Oracle in materialized
views, also referred to as summaries. These materialized views are transparent to the end
users, who still address the detailed base tables in their queries. The Oracle optimizer
knows when a materialized view would offer superior results compared with addressing
the base tables directly. Oracle uses the query-rewriting mechanism behind the scenes
to automatically rewrite a user’s query if it thinks that using a materialized view would
give faster results.
A materialized view can include aggregations like SUM, COUNT(*), MAX, MIN,
and any number of joins. You may index materialized views as well. If you aren’t sure
which materialized view to create, you can use the SQL Access Advisor to help you
design and evaluate materialized views.
Once you create a materialized view, you have two main concerns:
■ Refreshing the materialized views so they contain the latest data

■ Ensuring that your query rewrite mechanism will use the materialized view
to rewrite queries
In the next two sections, we’ll look at the fast refresh feature and query rewriting
mechanisms, and then look at the new Oracle Database 10g procedure that helps
you optimize your materialized views.
Materialized View Fast Refresh Feature

Data in the base (detail) tables of a materialized view changes over time, due to various
DML operations. Thus, a materialized view should be refreshed frequently to keep up with
the changes in the underlying tables. There are several ways to refresh a materialized view.
One of the best ways is to use the fast refresh method, which applies incremental changes
to refresh materialized views. The fast refresh method of updating materialized views
relies on the use of materialized view logs. Materialized view logs are created on the
underlying base tables, not on the materialized views themselves.
Here is a basic materialized view log creation statement:
SQL> CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID
(prod_id, cust_id, time_id, channel_id, promo_id, quantity_sold, amount_sold)
INCLUDING NEW VALUES;
The following are some of the important

restrictions on using the fast refresh method
(note that some restrictions are general; others
For fast refresh of
are specific to the type of materialized view—
materialized views, the definition of
whether it is based on aggregates or joins):
the materialized view logs must normally
specify the ROWID clause. ■ The materialized view must not use SYSDATE,
ROWNUM, RAW, or LONG datatypes.
■ A materialized view can’t have GROUP BY clauses.
■ You must include the ROWIDs of all the tables in the FROM list in the
SELECT list of the query.
■ You must have materialized view logs with ROWIDs for all the base tables.
The Query Rewrite Feature

Automatic query rewriting is the key feature that makes materialized views a faster means
of processing complex data warehousing-type queries compared to the direct use of the base
tables. Oracle takes your query against the base tables and rewrites it to use the underlying
materialized views, if Oracle’s query optimizer decides it’s a faster way to return the query
results. However, query rewriting is not guaranteed, and Oracle fails to rewrite queries on
occasion. When this happens, Oracle can’t use the underlying materialized views.
In order to ensure a query rewrite, a query must meet the following conditions:
■ QUERY_REWRITE_ENABLED = TRUE (the default value in Oracle

Database 10g)
■ The underlying materialized views must be enabled for query rewrite, by
using the ENABLE QUERY REWRITE clause. You can specify this clause
either with the ALTER MATERIALIZED VIEW statement or when you
create the materialized view.
■ You must set the query rewrite integrity level appripriately by specifying
the relevant value for the QUERY_REWRITE_INTEGRITY parameter.
For example, if a materialized view is not fresh you set query rewrite integrity
to ENFORCED, then Oracle won’t use the materialized view. To enable
query rewrite in this situation and cases where you have constraints that
haven’t been validated, you need to set the integrity level to a less restrictiv
level of granularity such as TRUSTED or STALE_TOLERATED.
■ The database must be able to drive either all or part of the results requested
by the query from the precomputed result stored in the materialized view.
In Oracle Database 10g, ENABLE initialization parameter is set to

the ENABLE_QUERY_REWRITE parameter 10.0.0 or higher. The QUERY_REWRITE_
is TRUE by default. You must, however, INTEGRITY initialization parameter still
ensure that the OPTIMIZER_FEATURES_ has the same default value (ENFORCED).
Here’s a brief list of the important restrictions on using the query rewrite feature:
■ You can’t refer to any RAW or LONG RAW datatypes and object REFs.
■ You can’t use any nonrepeatable expressions like SYSDATE and ROWNUM.
■ If you include a column or expression in the GROUP BY clause, it must also
be a part of the SELECT list.
The SQL Access Advisor can help you by suggesting ideal materialized views for
the detail tables in a query, and this advisor can also help you create the materialized
views. Once you create the materialized views, you can use various procedures of
the DBMS_MVIEW package to optimize your materialized views. Here is a summary
of the two key procedures of the DBMS_MVIEW package that help in understanding
the capabilities of materialized views and potential materilaized views, especially
concerning rewrite availability:
■ EXPLAIN_MVIEW This procedure tells you what kinds of query rewrites

are posible. It will also tell you why a certain materialized view isn’t fast
refreshable.
■ EXPLAIN_REWRITE This procedure tells you why a query failed to
rewrite. If the query rewrites, the procedure will tell you which materialized
views will be used
The DBMS_ADVISOR package offers you the
new procedure TUNE_MVIEW, which you can
use in the SQL Access Advisor. ?This is a new
The DBMS_ADVISOR Oracle Database 10g procedure that helps you
.TUNE_MVIEW procedure recommends alter a materialized view to ensure query rewriting
materialized views with optimized defining wherever it is possible. The procedure will let
queries, decomposition of nonrefreshable you decompose a materialized view into two
materialized views, and fixes for materialized or more materialized views or to restate the
view log problems. materialized view in a way that is more conducive
to a fast refresh and query rewrite.
The DBMS_ADVISOR.TUNE_MVIEW procedure will optimize the materialized
view in such a way that it can use several types of query rewrites. This procedure will
also provide you with the necessary statements to ensure a fast refresh. Let’s look at
the DBMS_ADVISOR.TUNE_MVIEW procedure in detail in the following section.
Materialized View Optimization

with the TUNE MVIEW Procedure
The new Oracle Database 10g TUNE_MVIEW procedure of the DBMS_ADVISOR
package helps you in fixing problematic materialized views, where either a fast refresh
or a query rewrite is not happening as you would like. The procedure takes a CREATE
MATERIALIZED VIEW as its input and performs the following materialized view
tuning functions:
■ Redefine materialized views so they refresh fast as well as use query rewrite, if
the materialized views are currently not using these features for some reason.
■ Fix materialized view log problems that may be keeping the view from using
the fast refresh mechanism. These problems include verifying that a materialized
view log exists in the first place. If the materialized view log exists, it may have
problems, like missing columns, which prevent its use by a materialized view.
■ If a materialized view turns out to be nonrefreshable, break it up into
submaterialized views that are eligible for a fast refresh. The parent materialized
view can then reference the submaterialized views, thus getting around its
inability to refresh fast.
If a materialized view isn’t fast refreshable, the data in the materialized view will
become stale, thus making your queries progressively worthless. When you find that
a materialized view isn’t fast refreshable, it’s usually because one or more of the fast
refresh restrictions aren’t satisfied. The DBMS_ADVISOR.TUNE_MVIEW procedure
provides you with the necessary SQL statements that you need to implement to ensure
that you can fast refresh your materialized views.
The DBMS_MVIEW.EXPLAIN_MVIEW procedure tells you why you can’t refresh

a materialized view. The DBMS_ADVISOR.TUNE_MVIEW procedure tells you
how to make the materialized view eligible for a fast refresh. In addition, the
DBMS_ADVISOR.TUNE_MVIEW procedure also makes recommendations to
enable a query rewrite.
You use the DBMS_ADVISOR.TUNE_MVIEW procedure as follows, either before

creating a new materialized view or when you are tuning an existing materialized view:
begin
dbms_advisor.tune_mview (:task_name,
‘CREATE MATERIALIZED VIEW test_mv
REFRESH FAST WITH ROWID ENABLE QUERY REWRITE
AS SELECT DISTINCT prod_name, prod_type
From products’);
end;
The preceding code will populate the new DBA_TUNE_MVIEW view, which you must
query to see how you can change your materialized view to make it fast refreshable as
well as capable of using query rewrite. The DBA_TUNE_MVIEW view has the following
structure:
SQL> desc dba_tune_mview
Name Null? Type
----------------------------------------- -------- -------------
OWNER VARCHAR2(30)
TASK_NAME VARCHAR2(30)
ACTION_ID NOT NULL NUMBER
SCRIPT_TYPE VARCHAR2(14)
STATEMENT CLOB
SQL>
You use the TASK_NAME column value to identify and query a particular TUNE_
MVIEW recommendation. (Make sure you provide a value for the TASK_NAME
variable that I highlighted in the previous PL/SQL code block.) The ACTION_ID
column shows the command order number. The SCRIPT_TYPE column can take
values of CREATE or DROP (or UNKNOWN). The CREATE value is for the new
materialized view recommendation. The DROP value shows the materialized view
that the TUNE_MVIEW procedure wants you to drop. The STATEMENT column of
the view shows the recommended materialized view changes that make your materialized
view eligible for a fast refresh and a query rewrite. If you wish, you can use the DBMS_
ADVISOR.GET_TASK_SCRIPT procedure to output the recommendations to a
text file.
Here’s the basic syntax of a query on the DBA_TUNE_MVIEW view:
SQL> select statement
from dba_tune_mview
where task_name = :task_name
order by script_type, action_id;
If the original materialized view statement isn’t eligible for fast refresh, the DBMS_
ADVISOR.TUNE_MVIEW procedure suggests an alternate way of defining your
materialized view. In this case, the DBMS_ADVISOR.TUNE_MVIEW procedure
might recommend the following changes to make your materialized view eligible
for a fast refresh of its materialized view logs. (Note that the new materialized view
recommendation replaces the DISTINCT clause in the original materialized view
with the COUNT(*) and GROUP BY clauses.)
SQL> create materialized view test_mv

refresh fast with rowid enable query rewrite
as select prod_type t,
prod_name p, count(*)
from products
group by prod_type, prod_name
Let’s look at a couple of examples that illustrate how you can use the DBMS_
ADVISOR.TUNE_MVIEW procedure to enable the fast refresh of a recalcitrant
materialized view.
Creating Materialized View Logs

As you know, one of the restrictions on the fast refresh feature is that you must include
the ROWIDs of all tables that are in the FROM list in your SELECT list. Thus, if a
certain statement fails due to noninclusion of the ROWIDs of the tables in the FROM
list, the DBMS_ADVISOR.TUNE_MVIEW procedure will suggest the inclusion of the
ROWIDs, as shown in the following example.
SQL> create materialized view test_mv
build immediate refresh fast enable query rewrite
as select e.ROWID r1, d.ROWID r2,
e.first_name, d.department_name
from departments d, employees e
where e.department_id = d.department_id;
The third line shows how you can use the ROWIDs to modify the materialized
view. This materialized view will now be eligible for query rewrite, as long as you
make sure that you create the following pair of materialized view logs, one for each
of the tables in the materialized view.
SQL> create materialized view log onemployees
with sequence, rowid
including new values;
SQL> create materialized view log on departments
with sequence, rowid including new values
Decomposing Materialized Views

Sometimes, a materialized view isn’t fast refreshable because it violates one of the
restrictions for a fast refresh, like having an unflattenable inline view. In cases like
this, the TUNE_MVIEW procedure helps you by making recommendations for the
decomposition of the materialized view into two nested submaterialized views.
The parent materialized view will refer to the submaterialized view that you create.
Again, you must create materialized view logs on each of the tables in the materialized
view in order to make it eligible for the fast refresh feature. The following types of situations
call for a materialized view decomposition:
■ A subquery in the WHERE clause

■ Use of set operations like UNION, UNION ALL, INTERSECT, and MINUS
■ Use of inline views
Partition Change Tracking Enhancements

You generally use materialized views in a data warehouse setting. Thus, it’s no surpise
that many materialized views will have partitioned base tables, since data warehouse
tables are large, and hence, usually partitioned. Oracle’s partition change tracking (PCT)
feature lets you figure out which rows of a materialized view are affected by a change in
a base table’s partitioning. Why is this ability important? Well, Oracle doesn’t perform
a query rewrite on a materialized view it considers stale, and it considers a materialized
view stale if the base table partitioning has changed.
The PCT feature, by maintaining links to table partitions and materialized view
rows, helps the materialized views handle the aftermath of a partitioning change in
the base tables. By enabling Oracle to consider only a part of a materialized view as
stale, PCT will enable the use of the query rewrite feature by letting it use those rows
that are still fresh, provided you use the QUERY_REWRITE_INTEGRITY=ENFORCED
or TRUSTED mode.
Any time you change a base table’s partition scheme, the relevant
materialized view rows become stale.
In Oracle Database 10g, there are several

enhancements with regard to the PCT feature.
A PCT-based materialized Let’s briefly review these enhancements in the
view refresh will minimize the amout of following sections.
refreshes and maximize the use of the
query rewrite feature. List-Partitioning Scheme
In previous versions, you could use the PCT
feature only for partitioned base tables using the range and range-hash partitioning
schemes. Now, you can also use it for detail tables using the list-partitioning scheme.
ROWID Columns as Partition Markers

Materialized view joins sometimes make ROWID references in their defining queries
You can now use a ROWID column as a PCT column in order to help identify table
partitions during a PCT refresh.
Join Dependency
You can now use a PCT-based refresh if your MV
Oracle Database 10g contains a join-dependent expression of one of its
extends the use of PCT to list-partitioned tables. A table is a join-dependent table if you
tables, enables the use of ROWID columns equijoin it with a partitioned base table on its
as partition markers, and lets you use a partioning key column. An expression consisting
PCT refresh if a materialized view contains of columns from the resulting equijoin is a join-
a join-dependent expression. dependent expression.
Truncating Materialized View Partitions

In previous versions, PCT used DELETE statements to remove materialized views. In
Oracle Database 10g, the database truncates materialized view partitions, as long as the
following conditions apply:
■ You are limited to range partitioning only (for both the base tables and
the materialized view), and the partitioning bounds must be the same for the
materialized view and its base tables.
■ There should be a one-to-one relationship between the two sets of partitions
(base table paritions and the materialized view partitions).
■ You must partition the materialized view on its single PCT key column.
■ You shouldn’t refresh on the basis of atomic transactions.
Forcing a Refresh
The PCT feature automatically refreshes your materialized view when there are partition
maintenance operations in the underlying base tables. However, you may sometimes wish
to manually use a PCT-based refresh, even in the absence of any base table partitioning
scheme modifications. The DBMS_MVIEW.REFRESH procedure has a new option, P,
to indicate a forced PCT-based refresh. Here’s the syntax:
execute dbms_mview.refresh(mview_name, method =>’P’)
Other Materialized View Enhancements

In addition to the introduction of the TUNE_MVIEW procedure to help with the fast
refresh and query rewrite features, and improvements to the PCT feature, Oracle
Database 10g provides several other enhancements related to materialized views.
I summarize these enhancements in the following sections.
Materialized View Execution Plans

In Oracle Database 10g, both the plan tableused by the explain plan feature and the
V$SQL_PLAN view will show you if a particular query is using a materialized view.
In Oracle Database 10g, you can find out if a materialized view was accessed directly
or if Oracle rewrote the query in order to use the materialized view. The new feature
here is that now you can clearly tell if Oracle is
using a materialized view as a result of a query
rewrite or because the programmer specified it.
The explain plan feature Here’s an example that shows an execution
shows you whether a materialized view plan that indicates how a materialized view is
is being accessed as a result of a query being used as result of the query rewrite. If you
rewrite or because you specified direct don’t see the keyword REWRITE, it means that
materialized view access. the materialized view was accessed directly.
Query Plan
SELECT STATEMENT
SORT ORDER BY
MATERIALIZED VIEW REWRITE ACCESS FULL EMP_INFO
The REWRITE_OR_ERROR Hint

If a planned query rewrite doesn’t take place,
The REWRITE_OR_ Oracle will end up running the original query.
ERROR hint stops the execution of a SQL Since the whole point of rewriting the query was
statement if a query doesn’t rewrite. to make a slow query fast, you may not want this
to happen. Oracle Database 10g contains a new
optimizer hint called REWRITE_OR_ERROR, which forces a query to error out if it
can’t rewrite the query:
select /*+ REWRITE_OR_ERROR */
Instead of running the original query, the hint throws the following error and
stops the execution of the SQL statement.
ORA-30393: A query block in the statement did not rewrite
New Columns in the REWRITE_TABLE

In the previous section, you saw how a REWRITE_OR_ERROR hint will stop the
execution of a query that failed to rewrite. In cases like this, you can use the DBMS_
MVIEW.EXPLAIN_REWRITE procedure to find out why the query failed to rewrite
(the procedure also tells you which materialized view will be used if the query does
rewrite). Using the output from the execution of this procedure, you can find out
what you need to do in order to make the query rewrite, if that is at all possible.
Following is the syntax for using the EXPLAIN_REWRITE procedure. Note that
this version is for when you want to create a table to hold the procedure’s output.
You can also use a VARRAY instead of a table if you want to access the procedure’s
output directly.
dbms_mview.explain_rewrite (
query IN [VARCHAR2 | CLOB],
mv IN VARCHAR2,
statement_id IN VARCHAR2;
To obtain the output into a table, you must run the utlxrw.sql script (located
in the $ORACLE_HOME/rdbms/admin directory) before calling EXPLAIN_
REWRITE. This script creates a table named REWRITE_TABLE in the current
schema.
In order to view the results of the EXPLAIN_REWRITE procedure, first create

the REWRITE_TABLE table, using the utlxrw.sql script, as shown here:
SQL> @c:\oracle\product\10.1.0\Db_1\RDBMS\ADMIN\utlxrw.sql
Table created.
SQL>
Here’s the structure of the REWRITE_TABLE:

SQL> desc rewrite_table
Name Null? Type
----------------------------------------- -------- -----------------------
STATEMENT_ID VARCHAR2(30)
MV_OWNER VARCHAR2(30)
MV_NAME VARCHAR2(30)
SEQUENCE NUMBER(38)
QUERY VARCHAR2(2003)
MESSAGE VARCHAR2(512)
PASS VARCHAR2(3)
MV_IN_MSG VARCHAR2(30)
MEASURE_IN_MSG VARCHAR2(30)
JOIN_BACK_TBL VARCHAR2(30)
JOIN_BACK_COL VARCHAR2(30)
ORIGINAL_COST NUMBER(38)
REWRITTEN_COST NUMBER(38)
FLAGS NUMBER(38)
RESERVED1 NUMBER(38)
RESERVED2 VARCHAR2(10)
Four REWRITE_TABLE columns are new in Oracle Database 10g:
■ JOIN_BACK_TBL provides the name for the table with which a join back
operation was performed in the materialized view.
■ JOIN_BACK_COL provides the name of the column involved in the join
back operation.
■ ORIGINAL_COST shows the cost of the prematerialized view query.
■ REWRITTEN_COST is the cost of the rewritten query, if there was one.
If not, this column will be zero.
The MESSAGE column shows the EXPLAIN_REWRITE procedure error

message. If it contains multiple materialized views, you’ll see a separate row for
each materialized view.
The REWRITTEN_COST show a zero if there was no rewrite of a

column of the REWRITE_TABLE shows the query or if a diffent materialized view was
cost for any materialized view that was used, even if there was a query rewrite.
used in a query rewrite. The column will
Materialized Join View Enhancements

Oracle Database 10g contains enhancements to materialized join views (MJVs), which
contain only joins (and not aggregates). In Oracle Database 10g, you can now conduct
a fast refresh of a materialized join view, under the following conditions:
■ If the materialized join view contains a self join in its FROM clause, you must
include the ROWID columns for each instance in the SELECT list. The
materialized join view log must contain all the ROWID coumns as well.
■ If the materialized join view has an inline view (or a named view), the
database must be able to perform complete view merging. Once the view
merging is done, the SELECT list must have the ROWID columns for all the
tables in the FROM clause.
■ If you are dealing with remote tables in materialized join views, make sure
that all of the tables are on the same site. The SELECT list must have the
ROWID columns for all the tables in the FROM clause.
For a fast refresh of each of the base tables. The materialized

materialized join views—whether they use view logs must also contain the ROWID
self joins, inline views, or remote tables— column.
you must create materialized view logs on
Partition Maintenance Operations

In previous versions of Oracle, when dealing with partitioned materialized views, you
needed to perform partition maintenance operations by using the ALTER TABLE
commands against the materialized view container tables, rather than the materialized
views themselves. In Oracle Database 10g, you can issue commands that truncate,
exchange, or drop partitions by using the ALTER MATERIALIZE VIEW statement.
For example, you can drop a partition from a partitioned materialized view in the
following manner:
alter materialized view <mv_name>
drop partition <partition_name>
Materialized View Refresh Using Trusted Constraints

Oracle doen’t enforce functional dependencies in dimensions. Similarly, it doesn’t
enforce primary key and foreign key relationships that are RELY constraints. As a
result of this behavior, when you refresh a materialized view, you may end up with
inconsistent results.
When you create a materialized view, you can specify the policy that Oracle
should adopt when it encounters constraints during a materialized view refresh.
If you use the ENFORCED option, Oracle won’t refresh any materialized view with
constraint violations. If you use the TRUSTED constraints option, on the other
hand, Oracle will perform a materialized view
refresh. However, Oracle will set the new column
UNKNOWN_TRUSTED_FD in the DBA_
If you use the TRUSTED MVIEWS view to a value of Y following the
option, the resulting materialized views refresh. This indicates that the materialized view
are in an unknown state, and you can use is now in an unknown state, because it used
them for a query rewite in a TRUSTED or trusted functional dependencies that were not
a STALE_TOLERATED mode only. enforced by Oracle during the refresh process.
INSIDE THE EXAM
The exam will test your knowledge of the The MODEL clause is too important not to
enhancements to the DBMS_ADVISOR be touched by the exam. You must thoroughly
package. You must understand how the new understand the concepts of partitions, measures,
TUNE_MVIEW procedure helps fast refresh and dimensions. What role do rules play in a
and query rewrite when you use materialized MODEL clause? What are the default semantics
views. You must remember the specific ways of rules in a MODEL clause (UPSERT)? What
in which the TUNE_MVIEW procedure can is the difference between sequential order and
help in tuning materialized views (decomposition automatic order when you are evaluating a set
of nonwritable materialized views, for example). of rules?
Under what conditions is it good to decompose Expect a question about the PCT feature
a materialized view? How does the TUNE_ on the exam. What enhancements has Oracle
MVIEW procedure contributein promoting introduced for PCT in Oracle Database 10g?
a fast refresh of a query? You must also be What are the preconditions for using the
conversant with the important procedures of TRUNCATE PARTITION command when
the DBMS_MVIEW package. What does the you are performing PCT operations?
EXPLAIN_MVIEW procedure help you do? You must know how to enable the automatic
The exam will test your knowledge of the query rewriting feature in Oracle Database 10g
MERGE statement enhancements. Exactly (hint: it is automatic!). What hint will stop
what rows will the DELETE clause delete in query execution if the query fails to rewrite?
a MERGE statement? Expect a query on materialized join views as
You most likely are going to encounter a well. What are the conditions under which
question on the new partitioned outer join Oracle supports fast refresh for materialized
feature. Know that it is simply an extension join views?
of the outer join feature in previous versions.
CHAPTER SUMMARY
This chapter started by reviewing the two new enhancements to the MERGE command
in a SQL statement. You then learned about the difference between dense and sparse
data, and how to densify data using the new partitioned outer join enhancement.
The SQL MODEL clause offers you tremendous analytical capabilities when dealing
with interrow calculations in a data warehouse setting. This chapter provided a basic
review of the MODEL clause enhancement, after first reviewing some essential data
warehousing concepts.
There are several important Oracle Database 10g enhancements pertaining to

materialized views. Important among these is the new TUNE_MVIEW procedure of
the DBMS_ADVISOR package. You saw how you can ensure (almost!) a fast refresh
of materialized views, as well as increase query rewrites using the DBMS_ADVISOR
.TUNE_MVIEW procedure. You also reviewed materialized join view enhancements,
materialized view refreshing using trusted constraints, and PCT enhancements.
❑ The MERGE statement enables you to perform conditional update and insert
operations when loading data from a source table into another table.
❑ In Oracle Database 10g, you can use a WHERE clause in a MERGE statement’s
UPDATE or INSERT clause to conditionally update or insert data.
❑ In addition to the INSERT and UPDATE clauses, you can now use a DELETE
clause in a MERGE statement.
❑ The DELETE clause in a MERGE statement will delete only rows included in
join condition (specified by the ON clause).
❑ The DELETE clause of the MERGE statement evaluates only the post-updated
values of rows.

❑ The partitioned outer join is an extension of the Oracle SQL outer join concept.
❑ Fact tables contain the data of an organization, and dimension tables contain
descriptions of the dimensions you use to categorize data into meaningful entities.
❑ Dimension tables are organized on a hierarchical basis, enabling you to perform
roll up and drill down operations.
❑ The analytical process follows a processing order consisting of the grouping,
calculation (analysis), and output ordering steps.
❑ Dense data doesn’t contain gaps in any of the dimensional cells.
❑ Sparse data is data that contains no values for some combinations of dimension
values.
❑ Sparse data presents analytical and report formatting problems.
❑ Dense data leads to better-performing analytical queries, especially when you’re
dealing with time-series data.
❑ Partitioned outer joins help turn sparse data into dense data by replacing missing
values in the data.
❑ You create a partitioned outer join by adding the PARTITION BY clause to
the outer join clause.
Two-Minute Drill 33

❑ The SQL MODEL clause provides you with spreadsheet-like output capabilities.
❑ The MODEL clause provides interrow and interarray analytical capabilities.
❑ The MODEL clause enables you to perform symbolic cell addressing and symbolic
array computations.
❑ The MODEL clause doesn’t change table data, unless you explicitly use a
separate UPDATE, INSERT, or MERGE statement to modify table data with
the MODEL clause’s output.
❑ The MODEL clause first creates multidimensional arrays from the raw data
derived from using the initial SELECT statement.
❑ Oracle uses partitions, measures, and dimensions to derive the multidimensional
data arrays from table data.
❑ The MODEL clause then applies simple or complex business rules to the array
data, using rules that you can specify.
❑ A rule is any business rule or formula that you apply to the array data derived
by the MODEL clause.
❑ A rule can update or insert data. The default rule semantics at the MODEL
level use the UPSERT operation.
❑ You can use UPDATE instead of the default UPSERT rule semantics.
❑ If you specify a rule level option, it will override an option specified at the
rules level.
❑ You can specify sequential order or automatic order for evaluating multiple
rules in a MODEL clause.
❑ Sequential order is the default rule processing order.
❑ The RETURN UPDATED ROWS clause will return only any new values created
by the MODEL clause.
❑ The MODEL clause output shows both the original data and the data that the
MODEL clause has inserted or updated.

❑ Oracle Database 10g enables query rewriting by default.
❑ The DBMS_MVIEW.EXPLAIN_REWRITE procedure tells you why Oracle
isn’t rewriting a query to take advantage of an existing materialized view.
❑ The DBMS_ADVISOR.TUNE_MVIEW procedure helps fast refresh a materialized

view, as well as enhance query rewriting.
❑ The DBMS_ADVISOR.TUNE_MVIEW procedure helps in fixing problems
with materialized view logs.
❑ The DBMS_ADVISOR.TUNE_MVIEW procedure also can suggest breaking
up a materialized view into submaterialized views to ensure a fast refresh of
the parent materialized view.
❑ The DBA_TUNE_MVIEW view contains the results of executing the TUNE_
MVIEW procedure.
❑ The STATEMENT column of the DBA_TUNE_MVIEW view shows the
recommended materialized view changes.
❑ The DBMS_ADVISOR.TUNE_MVIEW procedure can suggest that you include
the ROWIDs of all tables in the SELECT list of a materialized view.
❑ A materialized view decomposition into parent and submaterialized views
may be called for when you have subqueries in the WHERE clause or use an
inline view which you can’t flatten.
❑ The EXPLAIN PLAN statement will now show you if the materialized view
use is because of a query rewrite or developer specification.
❑ The new REWRITE_OR_ERROR hint stops the execution of a SQL statement
if query rewriting doesn’t take place.
❑ There are four new columns in the REWRITE_TABLE to help you figure out
the cost of an original and rewritten query.
❑ Once you create materialized view logs with a ROWID column, you can now
conduct a fast refresh of a materialized view join that contains self joins, inline
views, or remote tables.
❑ You can directly use the ALTER MATERIALIZED VIEW statement to perform
partitioning maintenance operations on partitioned materialized views.
❑ Oracle will conduct a fast refresh when dealing with trusted constraints, but it
will put the materialized view into an unknown state.
❑ You must use the TRUSTED or STALE_TOLERATED mode when dealing
with materialized views that are in an unknown state due to the use of trusted
functional dependencies and constraints.
Two-Minute Drill 35
❑ The partition change tracking (PCT) feature is now applicable to list-partitioned

tables or when your materialized view contains join-dependent expressions.
❑ PCT operations truncate data now, instead of deleting it.
❑ You can now manually use a PCT-based refresh, even in the absence of partition
operations, by specifying the new option when executing the DBMS_MVIEW
.REFRESH procedure.
SELF TEST
chapter. Read all the choices carefully because there might be more than one correct answer.

1. What does the MERGE statement do if an identical row already exists in the table?
A. It deletes the existing row first.
B. It inserts the duplicate row.
C. The MERGE operation fails with an error message.
D. It performs an update, although there won’t be any difference in the row ultimately.
2. When using the MERGE statement, what will the DELETE clause delete?
A. All rows that satisfy the DELETE clause’s WHERE condition
B. All rows that satisfy the DELETE clause’s WHERE condition, provided they have been
updated by the UPDATE clause
C. All rows that satisfy the DELETE clause’s WHERE condition, provided they have been
newly inserted by the INSERT clause
D. All rows that fail to satisfy the UPDATE clause
3. Which one of the three clauses—INSERT, DELETE, and UPDATE—fires first in a MERGE
statement if all three of them are present?
A. INSERT clause
B. DELETE clause
C. UPDATE clause
D. Depends on the order in which you specify the three operations
4. Which rows will the DELETE clause in a MERGE statement delete?
A. Rows modified by the UPDATE clause
B. Rows inserted by the INSERT clause
C. Rows neither updated nor inserted by the MERGE statement
D. Rows selected by the WHERE clause embedded inside the INSERT clause
Self Test 37

5. The partitioned outer join is especially beneficial for which type of data?
A. Time-series data
B. Cross-section data
C. Summary data
D. Analytical data
6. What can the output of a partitioned outer join be considered as?
A. UNION of several outer joins, each join being between a partition and the other table(s) in
the join
B. UNION of several equijoins, each join being between a partition and the other table(s) in
the join
C. UNION of several self joins, each join being between a partition and the other table(s) in
the join
D. UNION of several inner joins, each join being between a partition and the other table(s) in
the join
7. Which of the following is true when you densify sparse data by using partitioned outer joins?
A. The missing data must be filled in by zeros.
B. You can use the IGNORE NULLS clause with the LAST_VALUE function to replace the
missing values with the most recent non-NULL value in that column.
C. The missing data must be filled in by NULLs.
D. You must provide the missing data by updating the column with the missing values.
8. What will the PARTITION BY clause in a partitioned outer join statement do?
A. Partition the underlying table, using Oracle’s partitioning option
B. Partition the output rows into equal segments
C. Partition the table into equal subpartitions
D. Partition the rows in the output based on the expression your provide within the clause

9. What is symbolic cell addressing?
A. The way the MODEL clause makes statistical calculations
B. The way the MODEL clause addresses statistical symbols
C. The way the MODEL clause addresses the individual cells of an array
D. The way the MODEL clause addresses the rules
10. What can you derive by using a MODEL clause?
A. Both updated and deleted data
B. Both updated and newly created data
C. Only updated data
D. Only newly changed data
11. By default, the RULES keyword operates with which specification?
A. UPDATE specification
B. INSERT specification
C. UPDATE and UPSERT specifications
D. UPSERT specification
12. What will the RETURN UPDATED ROWS keyword in a MODEL clause do?
A. Return only the new rows, not the updated rows
B. Return only the updated rows, not the new rows
C. Return both the updated and the new rows
D. Return all rows that are going to be deleted

13. What does the fast refresh method of updating materialized views always use?
A. Incremental changes
B. Decomposed submaterialized views
C. Query rewrite
D. Materialized view logs
14. Under some conditions, for fast refresh to occur, which of the following must be true?
A. Materialized view logs must specify the ROWID clause.
B. The materialized view must use GROUP BY clauses.
C. The materialized view must use ROWIDs.
D. The materialized view must use ROWNUMs.
15. Which of the following will tell you why a certain materialized view isn’t fast refreshable?
Self Test 39
A. EXPLAIN_REWRITE procedure
B. TUNE_MVIEW procedure
C. MVIEW_EXPLAIN procedure
D. EXPLAIN_MVIEW procedure
16. What does the TUNE_MVIEW procedure do?
A. Automatically creates any necessary materialized view logs
B. Recommends the creation of any necessary materialized view logs
C. Automatically creates the materialized view
D. Automatically conducts a fast refresh of a materialized view
17. What does the DBA_TUNE_MVIEW view show?
A. The results of executing the TUNE_MVIEW procedure
B. The output of the CREATE_MVIEW procedure
C. The output of the EXPLAIN_MVIEW procedure
D. The output of both the TUNE_MVIEW and EXPLAIN_MVIEW procedures
18. Which of the following helps you identify your statement in the DBA_TUNE_MVIEW view?
A. The STATEMENT variable
B. The STATEMENT_ID column
C. The VIEW_ID column
D. The TASK_NAME variable
19. What does the REWRITE_OR_ERROR hint do?
A. Rewrites the query if it doesn’t lead to any errors
B. Stops executing a query if it can’t rewrite it
C. Sends out a report of all the rewrite errors
D. Enforces a query rewrite even if it leads to an error
20. In Oracle Database 10g, which of the following is true regarding the partition change tracking
feature?
A. It has been extended to Oracle partitions.
B. It has been extended to rule partitioning.
C. It has been extended to hash partitioning.
D. It has been extended to list partitioning.
LAB QUESTION
Compare the results of a regular outer join with the new partitioned outer join. For this lab exercise,
you need to use the SH schema in the sample schemas supplied by Oracle as part of your Oracle
software.
1. Create a small table with sales data for various years for two products.
2. Create another table with just time data, so you can join the first table with this one.
3. Use a traditional outer join and check the results.
4. Use a partitioned outer join and compare its results with those from step 3.
SELF TEST ANSWERS

1. þ D. The MERGE statement will perform the update, but the row will not change its values.
ý A is wrong because the MERGE statement always performs an UPDATE operation first. B is
wrong because the INSERT statement doesn’t fire. C is wrong because the existence of an identical
row will not lead to any errors.
2. þ B. The DELETE clause in a MERGE statement will delete all rows that meet the WHERE
condition, subject to the important provision that these rows must have been updated by the
UPDATE clause in the MERGE statement.
ý A is wrong because the DELETE clause will not delete all rows that satisfy the WHERE
clause, but only those that have been updated prior to the DELETE operation. C and D
indicate the wrong rows.
3. þ C. In a MERGE statement, the UPDATE operation always takes place first.
ý A, B, and C are wrong because the UPDATE operation is performed first.
4. þ A. The DELETE clause in a MERGE statement will delete only those rows that are modified
by the UPDATE clause.
ý B and D are wrong because the DELETE clause will not delete any rows that are inserted
as a result of the INSERT operation. C is wrong because the DELETE clause will lead to the
deletion of only those rows that have been updated because of the UPDATE operation.

5. þ A. Partitioned outer joins help you transform sparse data into dense data. Since having
dense data is very important for time-series based data, this is the right answer.
ý Although you can use partitioned outer joins with the data mentioned in B, C, and D,
they are most useful for time-series data. Alternative D could confuse some, since you might
argue that analytical data includes time-series data.
6. þ A. You could view the output of a partitioned outer join as a union of several smaller
outer joins between each of the partitions and the other table(s) in the join operation.
ý B, C, and D are wrong since they refer to equijoins, self joins, and inner joins, whereas
the partitioned outer join performs only outer joins.
7. þ B. You can use the IGNORE NULLS clause with the LAST_VALUE function to replace
the missing values with the most recent non-NULL value in that column.
ý A and C are wrong because you are not required to use zeros or NULLs to fill in missing
values. D is wrong because you don’t provide the values for the missing data—you use the
partitioned outer joins to do that job for you.
8. þ D. The PARTITION BY clause will partition the rows in the output based on the
expression you provide inside the PARTITION BY clause.
ý A and C are wrong because the PARTITION BY clause doesn’t actually partition the
tables. B is wrong because the output isn’t partitioned into equal segments, but rather is
partitioned on the basis of the expression you provide within the PARTITION BY clause.

9. þ C. Symbolic cell addressing is the way the MODEL clause handles the individual cells of
a multidimensional array.
ý A, B, and D are wrong because symbolic cell addressing deals only with addressing cells
within the array.
10. þ B. Using a MODEL clause, you can derive both updated and new data.
ý A is wrong since you don’t see and deleted data in the output produced by the MODEL
clause. C and D are wrong since you can derive both updated and new data when you use
the MODEL clause.
11. þ D. By default, the RULES keyword operates with the UPSERT specification.
ý A, B, and C offer the wrong specifications.
12. þ C. The RETURN UPDATED ROWS clause ensures that the MODEL clause outputs both the
updated and the new rows.
ý A and B are wrong since you drive both updated as well as new data. D is wrong since the
MODEL clause doesn’t delete data.

13. þ A and D. A is correct since a fast refresh is accomplished by using incremental changes.
D is also correct, since the materialized view logs hold the incremental change data.
ý B is wrong because the fast refresh method doesn’t depend on decomposing your materialized
views. C is wrong since the fast refresh method is a method of freshening the data and doesn’t
have anything to with query rewriting.
14. þ A and C. Under some conditions, both the materialized views and the materialized view
logs must use ROWIDs to ensure a fast refresh.
ý B is wrong because a GROUP BY operation is something you must avoid in order to force
a fast refresh. D is wrong because ROWNUM don’t force a fast refresh either.
15. þ D. The EXPLAIN_MVIEW procedure tells you why a materialized view isn’t fast refreshable.
ý A is wrong because the EXPLAIN_REWRITE procedure tells you if a materialized view
will or won’t rewrite a query. B is wrong because the TUNE_MVIEW procedure helps you in
making a materialized view fast refreshable. C is wrong because it refers to a nonexistent procedure.
16. þ B. The TUNE_MVIEW procedure only makes recommendations, including the creation of
necessary materialized view logs, to make a query fast refreshable.
ý A, B, and D are wrong since the TUNE_MVIEW procedure doesn’t automatically create
any views, logs, or a fast refresh of a materialized view. It’s a purely advisory view. You can
implement the changes recommended by the view.
17. þ A. The DBA_TUNE_MVIEW view holds the output of the TUNE_MVIEW procedure.
ý B, C, and D are wrong since they refer to the wrong procedures as the source of the view.
18. þ D. The TASK_NAME variable helps you identify your query in the DBA_TUNE_MVIEW
view (WHERE TASKNAME = :TASK_NAME).
ý A, B, and C refer to the wrong variables or columns.
19. þ B. The REWRITE_OR_ERROR hint will stop any query that fails to rewrite and issues an
automatic error.
ý A is wrong because the hint doesn’t rewrite the query if it doesn’t have errors. C is wrong
since the hint doesn’t send a report of the errors—it merely sends a single error message when
a query fails to rewrite. D is wrong since the hint does not force a query rewrite when there are
errors—it terminates the execution of the query when the query fails to rewrite and issues an error.
20. þ D. In Oracle Database 10g, the PCT feature has been extended to materialized views based
on list-partitioned tables.
ý A is wrong because you could use the PCT feature with partitioned tables in earlier versions
of Oracle. Similarly, B and C are wrong since you could use the PCT feature in both rule- and
hash-partitioned tables.
Lab Answer
1. Create the tables to show sales data for two products and check the data in the new table,
as in this example:
SQL> create table s1 as
2 select distinct time_id, prod_id, quantity_sold
3 from sales
4 where time_id between '02-JAN-2005'
5 and '05-JAN-2005'
6* and prod_id < 15;
Table created.
SQL> select * from s1;

TIME_ID PROD_ID QUANTITY_SOLD
----------- ---------- -------------
02_JAN-2005 13 1
02_JAN-2005 14 1
03_JAN-2005 14 1
04_JAN-2005 13 1
2. Create a second table with four rows in it, one for each day of January 2005, and check the
data in the table after creating it, as in this example:
SQL> begin
2 for i in 0..3 loop
3 insert into t1 values (to_date('02-JAN-2005') + i);
4 end loop;
5* end;
SQL> select * from t1;
TIME_ID
-----------
02_JAN-2005
03_JAN-2005
04_JAN-2005
05_JAN-2005
3. Create a regular outer join between tables s1 and t1. The following example uses the Oracle
function CUMULATIVE, to produce cumulative values for each day, from the quantity_sold
column values. The regular outer join will show a day, even if there aren’t any matching values
for it in the s1 table. This query shows a row for the 05-Jan-2005 date, even though there are
no product sales for that date (shown in table s1).
SQL> select prod_id, time_id, quantity_sold,
2 sum(quantity_sold) over
3 (partition by prod_id
4 order by time_id)
5 as cumulative
6 from s1
7 right outer join t1
8 using (time_id)
9 order by prod_id, time_id;
PROD_ID TIME_ID QUANTITY_SOLD CUMULATIVE
---------- ----------- ------------- ----------
13 02_JAN-2005 1 1
13 04_JAN-2005 1 2
14 02_JAN-2005 1 1
14 03_JAN-2005 1 2
05_JAN-2005
4. Finally, use a partitioned outer join, to see how you can improve over the results obtained with
just a regular outer join. The partitioned outer join in this example partition-joins the data by
the prod_id column, and shows rows for each day one of the products wasn’t sold. Product ID 13
didn’t sell on the third and fifth of January 2005. Product ID 14 didn’t sell on the fourth and
fifth. However, the partitioned outer join ensures that you see rows for both the products, for
all the days.
SQL> select prod_id, time_id, quantity_sold,
2 sum(quantity_sold) over
3 (partition by prod_id
4 order by time_id)
5 as cumulative
6 from s1
7 partition by (prod_id)
8 right outer join t1
9 using (time_id)
10* order by prod_id, time_id;
PROD_ID TIME_ID QUANTITY_SOLD CUMULATIVE
---------- ----------- ------------- ----------
13 02_JAN-2005 1 1
13 03_JAN-2005 1
13 04_JAN-2005 1 2
13 05_JAN-2005 2
14 02_JAN-2005 1 1
14 03_JAN-2005 1 2
14 04_JAN-2005 2
14 05_JAN-2005 2
8 rows selected
SQL>
Blind Folio 12:1
12
Miscellaneous
New Features
12.01 VPD and Auditing Enhancements 12.04 Miscellaneous Enhancements

12.02 Enhancements in Managing ✓ Two-Minute Drill
Multitier Environments
Q&A Self Test
12.03 SQL and PL/SQL Enhancements
2 Chapter 12: Miscellaneous New Features
T he first part of this chapter deals with enhancements in Oracle’s VPD (Virtual Private
Database) feature. You’ll learn about new VPD features like applying column-level
security policies, static and nonstatic policies, and sharing VPD functions. You’ll also
review the concept of a unified audit trail and the use of fine-grained auditing for DML statements.
The latter part of this chapter deals with miscellaneous new features of Oracle
Database 10g, including some new SQL enhancements and new PL/SQL packages.
You’ll look at the aggregation of meaningful statistics across a multitier environment.
These new statistics help you perform end-to-end tracing of Oracle sessions. The
exciting new topic of regular expressions provides POSIX-like regular expression
capabilities that help you write more powerful SQL search statements. You’ll also
learn about the new linguistic and sorting methods in Oracle Database 10g SQL.
Let’s start this final chapter by reviewing the enhancements in the Virtual Private
Database and auditing areas.
VPD and Auditing Enhancements

Oracle8i and Oracle9i introduced the concepts of fine-grained access control (FGAC)
and Secure Application Contexts. Oracle calls the combination of these two features
Virtual Private Database (VPD). Fine-grained access policies use the application
attributes defined in an application context, helping you enforce security policies at
the row level. VPD lets you implement security
policies at a fine level of granularity by attaching
your security policy to the data objects themselves
VPD policies apply to tables, (tables, views, and synonyms). These security
views, and synonyms. You can apply VPD policies contain directives to transparently change
policies toSELECT, INSERT, DELETE, a user’s statement whenever a user accesses a table,
UPDATE, and any INDEX statements. view, or synonym that’s part of a VPD security
policy.
You can apply VPD policies to index maintenance operations that you may perform
with any CREATE INDEX and ALTER INDEX statements. You may want to apply
VPD policies to these operations because you need full table access to create an index.
Thus, if you can create and rebuild an index, you can view all the table’s data.
VPD and Auditing Enhancements 3
You can use an application context independently of FGAC.
Column-Level VPD
Oracle Database 10g introduces the capability to enforce security at the column level.
VPD can apply fine-grained access control (which you define with the help of policy
functions) only when you access certain security-relevant columns. For example, if you
define salary as a security-relevant column in table emp, then employees can continue
to freely access information in all the other columns. However, Oracle will dynamically
modify any SQL statements that refer to the salary
column in order to protect sensitive data. Since
Oracle already provides row-level access control
A column-level VPD policy (FGAC), this new column-level access control
applies only to tables and views and not to extends access control to the individual data item
synonyms. You may apply a policy function level in a table. Note that Oracle will rewrite a
to queries as well as DML statements. SQL statement only if a SQL query accesses the
security-relevant columns.
Types of Behavior
You apply the column-level VPD to tables and views with the help of the DBMS_
RLS.ADD_POLICY procedure. You specify the security-relevant column names with
the sec_relevant_cols parameter of this package. When you use column-level
VPD, you have a choice of two types of behavior by the policy—default behavior and
column-masking behavior. Default behavior will restrict the number of rows returned by
any query that contains the security-relevant columns(s). Column-masking behavior, on
the other hand, will return all the rows, but show null values for the security-relevant
columns in those rows.
Creating a Column-Level Policy

In order to create a column-level security policy, you must have EXECUTE privileges
on the DBMS_RLS package. You must first create a policy function that will implant
your VPD policy. You then use the DBMS_RLS package to apply your policy to a table
or view. Here’s an example of how you create a column-level policy:
begin
dbms_rls.add_policy (object_schema=>'scott',
object_name=>'emp',
policy_name=>'test_policy',
function_schema=>'test_schema',
policy_function=>'test_function’,
statement_type=’insert,update’
sec_relevant_cols=>'salary,commission');
end;
Example of a Column-Level VPD

In the preceding column-level policy, the salary and commission columns in table emp
are the security-relevant columns. The VPD predicate will apply to all INSERT and
UPDATE statements that include either or both the salary and commission columns.
Normally, a VPD policy is applied to an entire row. A column-level VPD policy will
restrict the rows retrieved by a query if the query references any of the security-relevant
columns. The following example shows how to create VPD with a column-level security
policy.
Creating the Policy Function First create a new policy function, test_function,
which will restrict access to the salary and commission columns if an employee is not
part of department 5.
create or replace function test_function (objowner IN 2, varchar2
objname IN varchar2)
return varchar2 as
con varchar2 (200);
begin
con := 'deptno = 5';
return (con);
end test_function;
/
Create the VPD Once you create the test_function policy function, you
can create the VPD by applying it to a table, as shown here:
begin
dbms_rls.add_policy (object_schema => 'scott',
object_name => 'emp',
policy_name => 'test_policy',
function_schema => 'scott',
policy_function => 'test_function',
sec_relevant_cols => 'salary,commission');
end;
/
If you reference either or both of the security-relevant columns, salary and

commission, the rows in the output are restricted, as shown in the following example:
SQL> select deptno, empno, ename, job, sal, comm from emp;
DEPTNO EMPNO ENAME JOB SAL COMM
---------- ---------- --------- ---------- ----------
5 7369 SMITH CLERK 10000
5 7566 JONES MANAGER 2975
5 7788 SCOTT ANALYST 3000
5 7876 ADAMS CLERK 1100
5 7902 FORD ANALYST 3000
5 rows selected.
You can implement column-masking behavior by using the sec_relevant_

cols_opt => DBMS_RLS.ALL_ROWS parameter. This allows you to display all
rows but hide the values of the specified columns for the restricted rows. Here’s an
example:
begin
dbms_rls.add_policy (object_schema => 'scott',
object_name => 'emp',
policy_name => 'sp_job',
function_schema => 'scott',
policy_function => 'pf_job',
sec_relevant_cols => 'sal,comm',
sec_relevant_cols_opt => DBMS_RLS.ALL_ROWS);
end;
/
Once you choose the column-masking behavior by using the DBMS_RLS.ALL_

ROWS option, your query will return all rows, but it will show the salary and commission
values for only those employees that belong to department 5.
SQL> select deptno,empno, ename, job, sal, comm from emp;
DEPTNO EMPNO ENAME JOB SAL COMM
-----------------------------------------------------------
5 7369 SMITH CLERK 10000
10 7499 ALLEN SALESMAN
10 7521 WARD SALESMAN
5 7566 JONES MANAGER 2975
2 7654 MARTIN SALESMAN
1 7698 BLAKE MANAGER
8 7782 CLARK MANAGER
5 7788 SCOTT ANALYST 3000
2 7839 KING PRESIDENT
1 7844 TURNER SALESMAN
5 7876 ADAMS CLERK 1100
4 7900 JAMES CLERK
5 7902 FORD ANALYST 3000
2 7934 MILLER CLERK
You can grant the privilege GRANT EXEMPT ACCESS POLICY to a user
so that he or she may bypass a security policy, as shown here:
SQL> grant exempt access policy to hr;

Grant succeeded.
New Policy Types

By default, all Oracle VPD policy functions are dynamic in nature. That is, Oracle will
execute the security policy statement each time a DML statement refers to it. This leads
to the expenditure of valuable system resources due to the constant need to reexecute
and evaluate security policies. Each time Oracle reparses a SQL statement or executes it,
it reexecutes any policy function that the statement might have. Oracle Database 10g
introduces new policy types designed to improve server performance by avoiding the
need for reexecution and by allowing the sharing of policies across multiple database
objects. Let’s look at these new policy types in the following sections.
Static Policies
Oracle Database 10g lets you configure static policies. The database executes a static
policy function just once, and caches the predicate resulting from the policy evaluation
in the SGA. It then applies this predicate to all queries accessing the protected objects.
If you think that all queries, regardless of which user issues them, need the same policy
predicate, you might want to configure a static policy.
A static policy is one that will always return the same WHERE clause, such as
deptno=something so that even though the “something” may be different for
each statement executed against the table, the actual SQL doesn’t change (a bit like
a bind variable). But a dynamic policy is one that could generate a different WHERE
clause. For instance, the function could query usercontext and, depending on the
result, generate different WHERE clauses. Thus, some users would get deptno=…,
and others would get mgr=…, for example. So flagging a policy as static is simply
telling Oracle that the function can only return one value (possibly containing a
variable) no matter who executes it, whereas a dynamic policy is based on a function
that has several different return values. If you tell Oracle that the policy will always
get the same return value, then Oracle doesn’t have to repeatedly generate it.
You can add a static policy using the DBMS_RLS.ADD_POLICY procedure, as
shown here:
begin
object_name=>'emp',
statement_type=’select,insert,update’
policy_type => dbms_rls.static
sec_relevant_cols=>'salary , commission');
end;
In the preceding example, the highlighted line shows how you specify a static policy
type. The default policy type in Oracle Database 10g is dynamic.
If you want to allow the sharing of the same static policy function over different
database objects, you can set the POLICY_TYPE parameter to the following value:
POLICY_TYPE => DBMS_RLS.SHARED_STATIC
The default Oracle policy the same business policy over several
type in Oracle Database 10g is dynamic, database objects, you can do so by
but you can configure static and context- sharing either a static or a context-
sensitive policies. If you want to enforce sensitive policy.
Context-Sensitive Policies
You may sometimes want to configure a policy such that it will change based on
any session context changes. That is, each time certain context attributes within a user’s
session change, you want the policy function to automatically change as well. In cases
like this, you can use the new context-sensitive policies. When you use a context-sensitive
function, Oracle will evaluate the policy function when it first parses the statement.
Thereafter, Oracle will evaluate the policy function each time there is a local application
context change. Here’s our DBMS_RLS example, this time with a context-sensitive
policy type.
Context-sensitive VPD policies are particularly useful in a web-based application

with connection pooling, where a session needs to change its behavior depending
on the CLIENT_IDENTIFIER of the user using the session at any given moment.
begin
object_name=>'emp',
statement_type=’select,insert,update’
policy_type => dbms_rls.context_sensitive
sec_relevant_cols=>'sal,comm');
end;
If you want to allow the sharing of the same context-sensitive policy function over
different database objects, you can set the POLICY_TYPE parameter to the following
value when you use the DBMS_RLS.ADD_POLICY procedure:
POLICY_TYPE => DBMS_RLS.SHARED_CONTEXT_SENSITIVE
You now have five different SENSITIVE and SHARED_CONTEXT_

policy types, with DYNAMIC being the default SENSITIVE. The purpose behind having
type. There are two static policy types— several types of policies is aimed at reducing
STATIC and SHARED_STATIC. There are the number of executions of policy functions,
two context-sensitive policies—CONTEXT_ which sometimes cripple performance.
Auditing Enhancements
Oracle databases provide several auditing mechanisms. You have the option to audit
database activity based on data content by attaching audit policies directly to objects.
Oracle calls this feature fine-grained auditing (FGA).When you use FGA, Oracle creates
audit records based on the specific query and the data that the SQL statement accesses.
In Oracle Database 10g, enhancements to auditing features include uniform audit
trails for standard auditing and FGA, enhanced auditing of enterprise users, and several
FGA enhancements. Let’s review Oracle Database 10g auditing enhancements by
looking at uniform audit trails for standard and fine-grained auditing.
Uniform Auditing Trails

Oracle Database 10g helps you audit database activities in a uniform manner by using
a new uniform audit trail for both standard and fine-grained audit log records. Both the
standard audit trail and FGA audit trail track similar audit fields in Oracle Database 10g.
You can view the new uniform audit trail by using the DBA_COMMON_AUDIT_
TRAIL view. In the following text, the variables in the parentheses are columns
of this view.
Standard auditing now collects the following

additional information:
■ System change numbers (SCN)

You can view the new SCN
and SQL text/bind variable information ■ Bind variable information (SQL_BIND)
only if you use the new AUDIT_TRAIL= and the exact SQL text (SQL_TEXT) in
DB_EXTENDED specification in your the audited statement
initialization parameter file.
In Oracle Database 10g, FGA collects the following additional information:
■ Serial number of audit records (ENTRYID)

■ Statement numbers that help you identify which audit entries belong to a SQL
statement (STATEMENTID)
In addition, the following attributes are common to both standard and FGA audit
trails:
■ Global timestamp (GLOBAL_UID)

■ A unique instance number for Real Application Cluster instances (INSTANCE_
NUMBER)
■ A transaction identification number to trace individual records to a transaction
(TRANSACTIONID)
Enterprise User Auditing

When you use an LDAP-compliant directory like the Oracle Internet Directory, your
users are known as enterprise users. Oracle Database 10g lets you audit the activities of
the enterprise users in the database. Enterprise users can map to either an exclusive or
a shared schema in your database. If the enterprise user maps to an exclusive schema in
your database, the database username and the enterprise user are identical. In shared
schemas, the database username and the enterprise users are different. Let’s see how
Oracle enhances enterprise user auditing in both types of user mapping.
Exclusive Schemas If the enterprise user accesses the database by mapping to

an exclusive schema, in both standard and fine-grained auditing, the GLOBAL_UID
column shows the user’s global identity. In standard auditing, the USERNAME column
shows the user’s identity in the database, and in fine-grained auditing, the DB_USER
column shows the user’s identity in the database.
Shared Schemas If the enterprise user accesses the database by mapping to a

shared schema, in both standard and fine-grained auditing, the GLOBAL_UID column
shows the user’s global identity. In standard auditing, the USERNAME column shows
the shared schema, and in fine-grained auditing, the DB_USER column shows the
shared schema.
Fine-Grained Auditing Enhancements

In previous versions of Oracle, fine-grained auditing supported only SELECT statements.
Oracle Database 10g provides the following fine-grained auditing enhancements:
■ You can auditSELECT, INSERT, UPDATE, DELETE, and MERGE statements.

■ You can provide more than one relevant column for fine-grained auditing.
■ You can now use NULL fine-grained auditing policy predicates.
■ Since fine-grained auditing imposes significant SQL information overhead,
you can avoid the writing of SQL text and SQL bind information to LOBs.
FGA and DML Statements

Oracle Database 10g’s FGA features deal with DML statements of all types, but there
are some important provisions that you must remember. Here’s a summary of new DML
statement considerations:
■ Oracle Database 10g will audit a DML statement with an FGA policy defined
on it if the data rows (old and new) qualify under the policy predicate.
■ If you have a relevant column(s) in the security policy, the DML statement will
be audited only if it references the column(s) and the data meets the FGA
policy requirements.
■ Oracle always audits a qualified DELETE statement, regardless of whether
you have specified relevant columns or not.
Enhancements in Managing Multitier Environments 11
Oracle’s FGA feature statements. If there are applicable

audits MERGE statements by viewing FGA policies for the INSERT or UPDATE
the INSERT and DELETE statements statement, Oracle will audit the
in the MERGE statement as individual MERGE statement.
Enhancements in Managing Multitier Environments

Debugging of performance problems in multitier environments is difficult, since you can’t
easily track a client across different database sessions. Oracle Database 10g introduces
new statistical attributes that help you perform end-to-end tracing. Let’s look at these new
attributes in the following sections.
New Dimensions for Statistics Collection and Tracing

Previous versions of Oracle enabled statistics collection only at the individual SQL
statement, session, or instance level. Most DBAs are very familiar with session-based
tracing. These three levels are adequate in most cases for simple database configurations.
However, when you are dealing with complex multitier architectures using connection
pooling and shared server architectures, these simple statistical aggregation levels are
simply inadequate in monitoring performance problems. Realizing this, Oracle Database 10g
provides you with several new dimensions for collecting statistics, as follows:
■ Client identifier
■ Service name
■ Combinations of service name, module name, and action name
These three new dimensions for collecting statistics offer you new and powerful
means of monitoring problems in multitier architectures. The new statistics focus on
the clients and services, rather than database sessions and SQL statements. With the
help of metrics and statistics for these new dimensions, you can improve performance
monitoring of clients and services, as well as manage your workload more efficiently.
One of the most difficult problems in a multitier environment is the inability to
trace a client’s work on an end-to-end basis. The middle tier would frequently transfer
the same client to different sessions, making tracing of the client extremely difficult.
In Oracle Database 10g, the new variable CLIENT_IDENTIFIER enables you to trace
the same client from the time the user logs into the system until the user logs off,
regardless of how many different sessions the client switches to through the application
server.
You can see the value of the CLIENT_IDENTIFIER variable in two ways. You can
use the V$SESSION view (CLIENT_IDENTIFIER column) or use the following
query, which makes use of the system context.
SQL> select sys_context('USERENV', 'CLIENT_IDENTIFIER')
2 from dual;
SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')
------------------------------------------
salapati
SQL>
Besides enabling the tracing of individual

client sessions, end-to-end tracing also enables
you to track a transaction using hierarchical
By default, waits and combinations of the the service, module, and
binds aren’t traced. action names. You can find out what traces are
currently enabled in your database by using the
DBA_ENABLED_TRACES view.
Enabling the Collection of Client and Service Statistics

You use the DBMS_MONITOR package to enable client- and service-level statistics
aggregation. The procedures you can use to enable and disable the tracing and collection
of the new statistics are summarized next.
Client-Level Statistics
You use the CLIENT_ID_STAT_ENABLE procedure to enable the collection of
statistics for a client identifier, as shown here:
SQL> execute dbms_monitor.client_id_stat_enable(<client_id>);
Enhancements in Managing Multitier Environments 13
You can disable the collection of client-level statistics by using the CLIENT_ID_
STAT_DISABLE procedure.
Service-Level Statistics
You use the SERV_MOD_ACT_STAT_ENABLE procedure to enable the collection of
statistics for a client identifier, as shown here:
SQL> execute dbms_monitor.serv_mod_act_stat_enable(<service_name,
<module_name>, <action_name>);
You can disable the collection of client-level statistics by using the SERV_MOD_
ACT_STAT_DISABLE procedure.
Tracing Clients and Services

You can use the new client identifier (CLIENT_ID) and the combination of service,
module, and action names to trace sessions on both a global and session level. Let’s
first see how you enable and disable tracing.
Enabling and Disabling Tracing

You can enable and disable tracing by using various procedures of the DBMS_MONITOR
package. Here’s a summary of how to enable and disable tracing.
Client Identifier Tracing You use the following procedures to enable and disable
tracing for client identifiers:
■ CLIENT_ID_TRACE_ENABLE Enable global (database-wide) tracing of

a client identifier
■ CLIENT_ID_TRACE_DISABLE Disable client identifier tracing
Service, Module, and Action Tracing You use the following procedures to
enable and disable tracing for combinations of service names, module names, and
action names on a global basis.
■ SERVICE_MOD_ACT_TRACE_ENABLE Enable global (database-wide)

tracing
■ SERVICE_MOD_ACT_TRACE_DISABLE Disable global (database-wide)
tracing (module and service names are optional)
You may want to refer to the DBMS_APPLICATION_INFO package to see

how to set both a module name and action name so that you have a module
and an action to trace after enabling their tracing with the SERVICE_MOD_
ACT_TRACE_ENABLE procedure. The DBMS_APPLICATION_INFO has two
procedures, SET_MODULE and SET_ACTION, which allow programmers to
specify module and action names. The SET_MODULE procedure sets the name
of the current application or module. The SET_ACTION procedure sets the
name of the current action within the current module.
Using the TRCSESS Tool to Analyze Trace Files

When there are several trace files from a given session, it is hard to combine the output
of all the traces into a unified format. You can use Oracle’s TRCSESS command-line
utility to consolidate the information from all your trace files into a single output file.
Once you consolidate the trace files, you can use the familiar TKPROF utility to format
the trace file output into a readable format. Here’s the general syntax for using the
TRCSESS tool:
$ trcsess output=<user.trc> clientid=<user_name> *.trc
Viewing the New Statistics

Once you have enabled the collection of the new client identifier, service, module, and
action names statistics, you can view them by using Database Control. There are also
several new views that help you track these important statistics. Here are some of the
important new views:
■ DBA_ENABLED_AGGREGATIONS Displays information about enabled

statistics aggregation
■ DBA_ENABLED_TRACES Shows all enabled traces in the system
■ V$CLIENT_STATS Displays statistics on a client level (CLIENT_
IDENTIFIER based)
■ V$SERVICE_STATS Displays basic performance statistics
■ V$SERV_MOD_ACT_STATS Displays statistics for a combination of serve
/module/action names.
SQL and PL/SQL Enhancements 15
SQL and PL/SQL Enhancements

There are several SQL and PL/SQL enhancements in Oracle Database 10g, and you’ve
already seen some of them, like the MODEL clause, in earlier chapters. In the following
sections, I’ll review some of the more important enhancements from the point of view
of an Oracle DBA.
UTL_COMPRESS Package
Oracle Database 10g provides the new UTL_COMPRESS package to compress and
uncompress data, with the compressed output compatible with the output of the familiar
GZIP and GUNZIP compression utilities. You may want to compress data to save on
storage space. You can choose betweeen compression speed and the quality of compression.
Quality of compression refers to the reduction in size due to compressing data. There is
an inverse relationship between speed and quality of the compression job.
UTL_MAIL Package
In previous versions, Oracle provided the UTL_SMTP package to send email. However,
this isn’t an intuitive package to understand and is quite unwieldy for sending simple
email notes. In addition, you had to understand the underlying SMTP protocol features
to use it. In Oracle Database 10g, you have access to a new utility for sending email,
the UTL_MAIL package. You can now send programmatically composed emails using
simple PL/SQL API. You use simple parameters to specify email components such as
sender, receiver, copies, blind copies, subject, and so on.
In order to use the UTL_MAIL package to send email, you must first execute the
utlmail.sql script located in your ORACLE_HOME/rdbms/admin directory.You must
also execute the prvtmail.plb script located in the same directory. Here’s a simple
example that shows how to send an email using the UTL_MAIL package:
SQL> execute utl_mail.send -
> (sender => 'salapati@netbsa.org', -
> recipients => 'mpotts@netbsa.org', -
> subject => 'testing 10g Packages',
> message => 'No attachements with this note');
Regular Expressions
Oracle provides several operators to help you with string manipulation and searching.
Operators such as the SQL LIKE, REPLACE, SUBSTRING and INSTRING are old
standbys in many a search expression. However, these older operators have serious
limitations when it comes to searching and manipulating complex patterns in data. You
would have to write numerous lines of SQL and PL/SQL code to search for complex
expressions. Oracle Database 10g enhances your ability to perform convenient searches
and string manipulation by adding regular expression support to both SQL and PL/SQL
programming. Oracle’s regular expression features follow the syntax and semantics
of the operators defined by the POSIX regular expression standards. You use special
regular expression functions that parallel the traditional search operators such as LIKE,
INSTRING, SUBSTRING, and REPLACE.
A regular expression searches for patterns in a character string, which is the source for
the search value. The source character string can be one of the CHAR, VARCHAR2,
NCHAR, or NVARCHAR2 datatypes. The regular expression function can be one
of the following:
REGEXP_LIKE
REGEXP_REPLACE
REGEXP_INSTRING
REGEXP_SUBSTRING
The REGEXP_LIKE function evaluates strings using characters as defined by the

input character set. The regular expression function will search for a certain pattern
in a regular expression, indicated by the source_string parameter in the function.
The expression represented by the pattern variable is the regular expression. A regular
expression is usually a text literal and can be any of the datatypes CHAR, VARCHAR2,
NCHAR, or NVARCHAR2. Regular expressions can be long if you wish, with a
maximum size of 512 bytes. In addition to the search pattern indicated by source_
string, you can use an optional matching condition (match parameter) to modify
the default matching behavior. For example, a value of ‘i’ specifies case-insensitive
matching, and a value of ‘c’ specifies case-sensitive matching.
Here’s the generic syntax of the REGEXP_LIKE function:
The SQL operator REGEXP_LIKE is useful in searching for regular expressions.
If you want to perform string manipulation tasks, you can use the built-in functions
REGEXP_INSTR, REGEXP_REPLACE, and REGEXP_SUBSTR. You can use these
regular expression functions as extensions of their normal SQL counterparts like INSTR,
REPLACE, and SUBSTR. For example, the REGEXP_LIKE function is similar to the
SQL and PL/SQL Enhancements 17
LIKE condition, except that REGEXP_LIKE will perform regular expression matching
instead of the simple pattern matching performed by the LIKE function.
To match characters and to indicate the beginning and end of lines, regular
expression features use characters such as ., *, ^, and $, which are common in UNIX
and Perl programming. The character ^, for example, tells Oracle that the characters
following it should be at the beginning of the line. Similarly, the character $ indicates
that a character or a set of characters must be at the very end of the line. Here’s an
example using the REGEXP_LIKE function. (The query picks up all names with
consecutive vowels in their names.)
SQL> select last_name
from employees
where regexp_like (last_name, '([aeiou])\1', 'i');
LAST_NAME
-----------
De Haan
Greenberg
Khoo
Gee
Lee
……
EXERCISE 12-1
Using a regualr expression in a query

Use the appropriate regular expression built-in function to search for all employees
that were hired in the years 1996 and 1997. (Use the table employees in the sample
schema HR.)
SQL> SELECT last_name,first_name, salary,
2 TO_CHAR(hire_date,'yyyy') year_of_hire
3 FROM hr.employees
4* WHERE REGEXP_LIKE (TO_CHAR (hire_date, 'yyyy'), '^199[6-7]$');
LAST_NAME FIRST_NAME SALARY YEAR
------------------------- -------------------- ---------- ----
Alapati Nina 4800 1997
Chen John 8200 1997
Sciarra Ismael 7700 1997
Baida Shelli 2900 1997
Tobias Sigal 2800 1997
Wilson Shannon 8000 1996
Case-Insensitive and Accent-Insensitive Query and Sort

Oracle Database 10g provides support for case-insensitive queries and sorts, allowing
users to search and sort their data whatever the case and accent of the characters might
be. You use the NLS_SORT parameter to specify the lingusitic sort name and whether
it is a case-insensitive or accent-insensitive sort.
When you use the NLS_SORT parameter, you can use the optional suffixes AI or
CI to specify whether the sort is accent insensitive (AI) or case insensitive (CI). Here’s
the general syntax of the NLS_SORT parameter and an example of its usage:
NLS_SORT = <NLS_sort_name>[_AI| _CI]
NLS_SORT = FRENCH_M_AI.
In the previous example, the name of the NLS_SORT is FRENCH_M. The optional
suffix AI indicates this is an accent-insensitive (and case-sensitive) sort.You can
indicate a case-insenstitive sort by using the suffix CI.
CLOB and NCLOB Implicit Conversions

The maximum size of an LOB datatype (BLOB, CLOB, and NCLOB) in Oracle
Database 10g is much larger than the old limit of 4GB. You can now have LOBs that
can be sized in terabytes, with the maximum size being about 128TB.
Oracle Database 10g also provides implicit conversion between CLOB and NCLOB
datatypes. Before this version, you had to explicitly convert CLOBs into NCLOBs and
vice versa, using the TO_CLOB and TO_NCLOB functions. International applications
supporting multiple language characters required the deployment of function calls to
convert these kinds of data.
Oracle Database 10g introduces the implicit conversion between LOBs and NCLOBs.
Oracle now supports implicit conversion in SQL IN/OUT bind variables, PL/SQL
function and procedure parameter passing, and PL/SQL variable assignment.
User-Specified Quoting Characters

In prior versions of Oracle, programmers had to use quotation strings in character string
literals. Oracle Database 10g lets you choose any convenient delimiter and define it
dynamically as the quoting character. You can choose any single or multibyte character,
or paired characters like [], {}, (), and <>. You may even choose a single quotation mark
as your delimiter.
Miscellaneous Enhancements 19
You use the new quote operator q to provide your own quotation mark delimiters.
Here’s a simple example that illustrates how you can use the new quote operator to
avoid using escape characters for single quotation marks in text literals:
SQL> select cust_address FROM oe.customers
where cust_last_name = q'X 'John's Bait Shop' X'
Miscellaneous Enhancements
There are several enhancements in Oracle Database 10g that don’t fit within the topics
of any of the earlier chapters in this book. I summarize these enhancements in the
following sections.
Easy Connect Naming Method

Oracle DBAs can now simplify client configuration by using the new easy connect
naming method. Your database clients can now connect to Oracle Database 10g database
services without any configuration fields or name lookup services. All that your clients
will need to connect to the database server is the host name and the optional port number
and service name of the database.
The only condition for using the easy connect naming method is that you should
have support for the TCP/IP protocol on both the client and the server. You don’t have
to configure a tnsnames.ora file. You can look at this new connecting method as an
extension of the host naming method introduced in Oracle9i. Here’s the general syntax
of this new connecting method :
$ sqlplus /nolog
connect username/password@[//]host[:port][/service_name]
In the new easy connect method, there are four different things you need to focus
on: host, the // notation, port number (default port = 1521), and service name. Of
these four things, only the host name is mandatory. For example, you can connect to
the dev1 database located on the server hp50 with the following connect identifier
(note that I’m connecting directly from the operating system prompt, so I replace the
keword CONNECT with SQLPLUS):
C:\>sqlplus appowner/password@hp50:1521/dev1
When you install an Oracle database, Oracle will configure your sqlnet.ora file to
use the new configuration-less client connect method. The NAMES.DIRECTORY_
PATH parameter in the sqlnet.ora file shows all connect methods. The new easy connect
method is referred to as EZCONNECT in a sqlnet.ora file. Look at the following
sqlnet.ora file:
# sqlnet.ora Network Configuration File:
C:\oracle\product\10.1.0\Db_1\network\admin\sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DEFAULT_DOMAIN = netbsa.org
SQLNET.AUTHENTICATION_SERVICES = (NTS)
NAMES.DIRECTORY_PATH = (TNSNAMES,EZCONNECT)
The last line shows you the connect methods that Oracle Net will use to resolve
connect identifiers to connect descriptors. In this example, TNSNAMES is the first
option, so Oracle NET will use the tnsnames.ora file first by default. If it can’t connect
using the tnsnames.ora file, it will then use the EZCONNECT connecting method.
If you want Oracle Net to use the EZCONNECT method first, you can use Oracle
Net Manager to reconfigure the sqlnet.ora file so your NAMES.DIRECTORY_PATH
will be as follows. (You may manually change the sqlnet.ora file as well.)
NAMES.DIRECTORY_PATH = (EZCONNECT, TNSNAMES)
Simplified Shared Server Configuration

Oracle Database 10g is shared server aware, meaning that you don’t have to configure
any shared server parameters. A dispatcher will start automatically when you start a
database instance, but no shared server process will start. If you want to start a shared
server while your instance is running, you can do so by setting a non-zero value for the
SHARED_SERVER initialization parameter, as shown here:
SQL> alter system set shared_servers=4
System altered.
SQL>
Enabling Resumable Space Allocation

Oracle Database 10g introduces a new initialization parameter, RESUMABLE_TIMEOUT
to enable resumable statements at the system or the session level. To set the resumable
time-out to three hours, for example, you’d specify RESUMABLE_TIMEOUT=10800
(3x60x60) in your initialization parameter file. The default for this initialization
parameter is zero, meaning that resumable space allocation is disabled for all database
sessions. You can dynamically use the parameter in the following way to enable resumable
space allocation at the instance level:
SQL> alter system

2 set resumable_timeout=7200;
System altered.
SQL>
You can dynamically change the RESUMABLE_TIMEOUT parameter at an individual

session level as well, by using the ALTER SESSION command. The old method of
enabling resumable statements at the session level by using the command ALTER
SESSION ENABLE RESUMABLE still works in Oracle Database 10g.
Flushing the Buffer Cache

When you are testing SQL statements on a development system, there are times when
you wish that you could wipe out the data in your buffer cache in order to accurately
compare the output from various iterations of your queries. Previously, you could only
flush the shared pool to remove any cached SQL statements from the SGA. You can flush
the database buffer cache in Oracle Database 10g by using the following command:
SQL> alter system flush buffer cache;
System altered.
SQL>
LogMiner Enhancements
There are three important changes in the LogMiner tool. Let me summarize the changes
briefly here.
Automatic Adding of Redo Log Files

You can now simply specify a time or SCN, and LogMiner will automatically add the
necessary redo log files by scanning the control files for the log information. You must
use the DBMS_LOGMNR.CONTINUOUS_MINE procedure to facilitate this automatic
gathering of redo log files for mining purposes.
Disabling Generation of ROWIDs

You can disable the generation of physical ROWIDs by using the NO_ROWID_IN_STMT
option when you use the DBMS_LOGMNR package.
Easier Removal of Redo Log Files

To remove redo log files, you can now use the new REMOVE_LOGFILE procedure with
the DBMS_LOGMNR package.
Real-Time Transaction Monitoring

Oracle Database 10g introduces enhancements to the V$FAST_START_SERVERS
and the V$FAST_START_TRANSACTIONS views to enable real-time monitoring of
normal transaction rollback and transaction recovery by the SMON background process.
You can also make better estimations of your transaction recovery time by calculating
more accurate rollback times during transaction recoveries. Let’s review the changes in
real-time transaction monitoring in Oracle Database 10g.
The V$FAST_START_SERVERS View

This view provides information about all the recovery servers performing (or that
have performed) parallel transaction recovery. In Oracle Database 10g, you have a
new column, XID, that gives you the transaction ID of the transaction that a recovery
server is working on.
The V$FAST_START_TRANSACTIONS View

This view shows information about the progress of the transactions that Oracle is
currently recovering. The STATE column shows the value RECOVERING for all
transactions that are being recovered right now.
In addition, the view stores historical recovery
information until the next shutdown of the
The enhancements in instance. The transactions already recovered by
transaction rollback monitoring help you Oracle have the value RECOVERED under the
set the FAST_START PARALLEL_ STATE column. If any transaction has yet to be
ROLLBACK initialization parameter at an recovered, the STATE column will show the value
appropriate level. TO BE RECOVERED.
Oracle Database 10g has added the following
new columns to the V$FAST_START_TRANSACTIONS view to enhance your
ability to keep track of the progress of transaction recovery:
■ XID Stands for the transaction ID.

■ PXID Parent transaction ID.
■ RCVSERVERS Number of servers used in the last recovery. If SMON
is doing the recovery, the value of this parameter is always 1.
Automatic Checkpoint Tuning

DBAs have to consider the trade-off between a quick recovery time and I/O overhead
when trying to figure out the appropriate checkpoint interval. In Oracle9i, you had
access to the FAST_START_MTTR_TARGET initialization parameter, which enabled

you to specify the mean time for a crash recovery.
In Oracle Database 10g, there is no need for you to set the FAST_START_MTTR_
TARGET parameter because Oracle itself will automatically tune the checkpointing
process. Automatic checkpoint tuning means that Oracle will write out the dirty buffers
while incurring the least amount of impact in the way of physical I/Os.
You can enable automatic checkpoint tuning by simply setting the FAST_START_
MTTR_TARGET parameter to any non-zero value. Oracle automatically tunes
checkpointing even if you completely leave out the FAST_START_MTTR_TARGET
parameter. However, by explicitly setting the parameter to zero, you can disable Oracle’s
automatic checkpoint tuning.
INSIDE THE EXAM
You can expect some type of question on the The exam will test your knowledge of the new
new column-level VPD policies. The exam CLIENT_IDENTIFIER, SERVICE_NAME,
tests your expertise in customized VPD policy MODULE_NAME, and ACTION_NAME
types. What are the five VPD policy types, and attributes. What are these attributes useful for?
when do you use them? Be sure to understand Please look up the DBMS_MONITOR package and
how to use shared policy functions. The exam study the CLIENT_ID_TRACE_ENABLE
will contain questions on the new auditing and the SERV_MOD_ACT_TRACE_ENABLE
features. Understand what the new AUDIT_ procedures. Also look up the procedures that
TRAIL=DB_EXTENDED specification will enable and disable statistics collection for the
help you do. You must be familiar with the new attributes. You must know how to enable
DBA_COMMON_AUDIT_TRAIL view and and disable end-to-end tracing using the new
its important columns. attributes.
You are going to see questions on fine- Among the miscellaneous SQL and PL/SQL
grained auditing enhancements, including topics, focus on regular expressions and the new
topics like support for DML statements (and packages to send email and compress data. Know
the MERGE statement), multicolumn FGA the Oracle Database 10g enhancements in
policies, and NULL FGA policy predicates. CLOB to NCLOB conversions, the new quote
How does Oracle audit MERGE statements? operator, and how to perform case- and accent-
Look up the DBMS_FGA package and study insensitive querying and sorting. The exam
the ADD_POLICY procedure carefully, also may have questions on the new resumable
with particular emphasis on the AUDIT_ statement parameter, the easy connect naming
COLUMN, AUDIT_COLUMN_OPTS, method, and the easy configuration of shared
and the AUDIT_TRAIL columns. servers.
CHAPTER SUMMARY
You reviewed the new column-level VPD policies in this chapter. You learned how to
create a VPD with security-relevant columns.You also learned about the new static and
context-sensitive policies and how you can share them across objects.The chapter
covered the Oracle Database 10g enhancements in the auditing area, including the new
uniform audit trail for standard and fine-grained auditing .You learned about the new
enterprise user auditing enhancements as well as other FGA enhancements.
The new attributes—client identifier, service name, module name, and action
name—enhance your ability to perform end-to-end tracing as well as monitor your
database workload. You learned how to enable and disable client- and service-level
tracing and statistics collection.
The chapter introduced you to the new UTL_MAIL and the UTL_COMPRESS
PL/SQL packages. You had an introduction to the powerful regular expressions feature.
The chapter also reviewed the new case- and accent-insensitive sorting techniques
as well as user-specified delimiters.
Under miscellaneous enhancements, you briefly reviewed the new easy connect
naming method, simpler shared server configuration, the new resumable space
allocation initialization parameter, and enhancements to the LogMiner tool and real-
time transaction monitoring.
Two-Minute Drill 25
❑ Oracle Database 10g introduces the new column-level security mechanisms
(VPD).
❑ You can now assign certain columns as security-relevant columns.
❑ You can apply a column-level VPD policy to tables and views, but not
to synonyms.
❑ You can apply policy functions to queries as well as DML statements.
❑ You implement the column-level VPD policies with the help of the DBMS_
RLS.ADD_POLICY procedure.
❑ Default behavior will restrict the number of rows returned.
❑ Column-masking behavior will return all rows, but show NULL for the
security-relevant columns.
❑ You implement column-masking behavior by using the sec_relevant_
cols_opt => DBMS_RLS.ALL_ROWS parameter when using the ADD_
POLICY procedure.
❑ By default, all Oracle VPD policy functions are dynamic.
❑ A static policy is only executed once and reused for all subsequent queries.
❑ A context-sensitive policy changes with session context changes.
❑ Both static and context-sensitive policies can be shared or nonshared policies.
❑ You have a new uniform audit trail for both standard and FGA audit log records.
❑ You have to set the AUDIT_TRAIL=DB_EXTENDED parameter value in order
to see bind variables and the complete SQL text of the audited statements.
❑ There are several enhancements in the enterprise user auditing in Oracle
Database 10g.
❑ You can audit queries and DML statements (including the MERGE statement)
in the course of fine-grained auditing.
❑ You can provide multiple columns for FGA as well as use NULL FGA auditing
policy predicates.
❑ Oracle will always audit a qualified DELETE statement under FGA.
❑ Oracle’s FGA feature audits MERGE statements by viewing them as consisting
of individual UPDATE and INSERT statements.

❑ New dimensions for collect statistics include client identifier, service name,
and combinations of service name, module name, and action name.
❑ The CLIENT_IDENTIFIER attribute facilitates end-to-end tracing.
❑ You use procedures from the DBMS_MONITOR package to enable and disable
statistics collection and to trace the new client- and server-related attributes.
❑ The new TRCSESS tool helps you analyze the output of multiple trace files.

❑ The UTL_COMPRESS package lets you compress and uncompress data.
❑ The UTL_MAIL package offers you a simpler alternative to the UTL_SMTP
package for sending email.
❑ Regular expressions provide powerful means of searching and manipulating
complex patterns.
❑ You can use the regular expression equivalents of the LIKE, REPLACE,
SUBSTR, and INSTR functions.
❑ You can now specify accent-insensitive and case-insensitive sorting when you
use the NLS_SORT parameter.
❑ You can now implicitly convert CLOB and NCLOB datatypes.
❑ Users can choose custom delimiters and define them as a quoting character.
❑ The new EZCONNECT client connection method cuts down on client
configuration work.
❑ Shared server configuration is simpler now, and you only have to configure the
SHARED_SERVER parameter. The dispatcher process starts automatically
with instance startup.
❑ The new initialization parameter RESUMABLE_TIMEOUT enables the
resumable statements feature at the system or session level.
❑ You can now flush the buffer cache by using ALTER SYSTEM command.
❑ The LogMiner tool allows the easy addition and removal of redo log files.
❑ Changes to the V$FAST_START_SERVERS and the V$FAST_START_
TRANSACTIONS views enhance real-time monitoring of transaction rollback
and recovery.
❑ In Oracle Database 10g, you can let the database automatically tune database
checkpointing.
Self Test 27
SELF TEST
1. Which of the following does a column-level VPD policy apply to?
A. Tables
B. Synonyms
C. Views
D. Materialized views
E. Indexes
2. Which of the following type of SQL statements may you apply a policy function to?
A. DDL statements
B. SELECT statements only
C. Queries and DML statements
D. INSERT and DELETE statements only
E. INSERT, DELETE, and UPDATE statements
3. Which of the following statements regarding column-level VPD are true?
A. Default behavior will return all columns.
B. Default behavior will restrict the number of rows returned.
C. Column-masking behavior will return all rows.
D. Column-masking behavior will restrict the number of rows returned.
4. Which of the following is the default policy type in Oracle Database 10g?
A. POLICY_TYPE=DBMS_RLS.STATIC
B. POLICY_TYPE=DBMS_RLS.DYNAMIC
C. POLICY_TYPE=DBMS_RLS.SHARED
D. POLICY_TYPE=DBMS_RLS.CONTEXT_SENSITIVE
5. How does Oracle Database 10g audit a MERGE statement?
A. It audits only the UPDATE part of the MERGE statement.
B. It audits only the DELETE part of the MERGE statement.
C. It audits the MERGE statement with the underlying INSERT or UPDATE statements.
D. It doesn’t audit MERGE statements.

6. What are the two ways in which you can find out the value of the new attribute, CLIENT_
IDENTIFIER?
A. V$INSTANCE
B. V$SESSION
C. DBA_USERS
D. SYS_CONTEXT
7. How do you enable tracing for all calls for a given application client?
A. EXEC DBMS_MONITOR.client_id_trace_enable
B. EXEC DBMS_MONITOR.client_id_stat_enable
C. EXEC DBMS_MONITOR.client_identifier_trace_enable
D. EXEC DBMS_MONITOR.serv_mod_act_trace_enable
8. What do you use the SERV_MOD_ACT_TRACE_ENABLE procedure for?
A. To trace a client session throughout its life
B. To enable SQL tracing for a combination of client ID, service name, and module name
C. To enable SQL tracing for a combination of username, service name, and module name
D. To enable SQL tracing for a combination of service name, action name, and module name
9. What does the TRCSESS utility do?
A. Help you enable a sessionwide trace
B. Help you interpret end-to-end tracing output
C. Consolidate information from several trace files into a single output
D. Stress the system to see how much load it can handle when you introduce new SQL
statements in the database.
10. What are the three benefits of using the new statistics aggregation dimensions in Oracle
Database 10g (client identifier, service name, module name, and action name)?
A. Monitoring performance of individual clients
B. Managing the workload
C. Setting threshold-based alerts
D. Providing correct input to ADDM

11. Which of the following are new Oracle Database 10g enhancements regarding conversion
between CLOB and NCLOB datatypes?
Self Test 29
A. Implicit conversion of SQL IN and OUT bind variables in queries and DML statements
B. Explicit conversion of SQL IN and OUT bind variables in queries and DML statements
C. Implicit conversion of SQL IN and OUT bind variables in queries only
D. Implicit conversions of SQL IN and OUT bind variables in DML statements only, but not
in queries
12. Which of the following is not an Oracle regular expression function?
A. REGEXP_LIKE
B. REGEXP_BETWEEN
C. REGEXP_REPLACE
D. REGEXP_SUBSTR
13. Which of the following shows a correct specification of a regular expression?
A. REGEXP_LIKE (source_string, pattern, match_option)
B. REGEXP_LIKE (source_string, match_option, pattern)
C. REGEXP_LIKE (pattern, source_string, match_option)
D. REGEXP_LIKE (match, pattern, match_option)
14. Which two of the following are enhancements to the NLS_SORT function?
A. Case-insensitive functionality
B. Case-sensitive functionality
C. Accent-sensitive functionality
D. Accent-insensitive functionality
15. The output of the UTL_COMPRESS compressed data is compatible with which of the
following?
A. GZIP only
B. GZIP and GUNZIP
C. GUNZIP only
D. Neither GZIP nor GUNZIP
16. Which two of the following statements will work if your goal is to enable resumable statements
in Oracle Database 10g?
A. ALTER SESSION SET RESUMABLE STATEMENTS=TRUE
B. ALTER SESSION SET RESUMABLE =TRUE
C. ALTER SESSION SET RESUMABLE_TIMEOUT=3600
D. RESUMABLE TIMEOUT=3600
17. In Oracle Database 10g, which of the following do you have to do in order to start a shared
server?
A. ALTER SYSTEM SET SHARED_SERVERS=8
B. ALTER SYSTEM SET DISPATCHERS=2
C. ALTER SYSTEM ENABLE SHARED SERVER
D. ALTER SYSTEM START DISPATCHER
18. Which two of the following will ensure automatic checkpoint tuning by Oracle?
A. Set the FAST_START_MTTR_TARGET parameter to a positive value.
B. Set the FAST_START_MTTR_TARGET parameter to zero.
C. Don’t set the FAST_START_MTTR_TARGET parameter.
D. Set the FAST_START_MTTR_TARGET to a value of TRUE.
19. Which of the following is mandatory when you are using the easy connect naming method?
A. Host name
B. Database name
C. Service name
D. Port number
20. Which DBMS_LOGMNR feature facilitates the automatic adding of redo log files for mining?
A. REMOVE_LOGFILE
B. CONTINUOUS_MINE
C. NO_ROWID_IN_STMT
D. AUTOMATIC_LOGFILE
LAB QUESTION
Given the following statement, use regular expressions to search for a comma followed by a space. You
must then have zero or more characters that are not commas, and include another comma in the end.
'first child, second child , third child',
SELF TEST ANSWERS

1. þ A and C. Column-level VPD policies apply only to tables and views.
ý B, D, and E are wrong since column-level VPD policies don’t apply to these objects.
2. þ C. You may apply a policy function to anySELECT, INSERT, UPDATE, or DELETE
statement.
ý A, B, and D are wrong since they either point out the wrong type (DDL statements)
or leave out some DDL statements that are allowed.
3. þ B and C. B is correct because the default behavior under a column-level VPD will restrict
their rows returned to only those that meet the VPD column-level restrictions. C is correct since
the column-masking behavior will always return all rows, but will have NULL values for the
columns to which the column-level VPD policy applies.
ý A and D are wrong since the actions they represent are exactly opposite to the actual
behavior of Oracle, as explained above for the correct answers.
4. þ B. The default policy type in Oracle Database 10g is dynamic.
ý A, C, and D are wrong since dynamic policy type is the default.
5. þ C. Oracle will treat a MERGE statement as individual UPDATE and INSERT statements,
and will audit those statements on an individual basis.
ý A and B are wrong since Oracle audits both UPDATE and INSERT statements. D is wrong
since Oracle does audit MERGE statements.

6. þ B and D are correct since you find out the value of the CLIENT_IDENTIFIER attribute
by querying the V$SESSION view, or by using SYS_CONTEXT.
ý A and C are wrong since neither the V$INSTANCE nor the DBA_USERS view has any
information on the CLIENT_IDENTIFIER attribute.
7. þ A. You use the client_id_trace_enable procedure to enable tracing of the CLIENT_
IDENTIFIER attribute, which enables end-to-end tracing of all calls for a database client.
ý B is wrong because the procedure enables you to collect statistics, not trace sessions. C is
wrong because it refers to CLIENT_IDENTIFIER instead of CLIENT_ID. D is wrong because
this procedure is for tracing a combination of service name, module name, and action names.
8. þ D. The SERV_MOD_ACT_TRACE procedure enables SQL tracing for a combination of

service name, action name, and module name.
ý A, B, and C are wrong because the SERV_MOD_ACT_TRACE procedure doesn’t help with
tracing client activities directly.
9. þ C. The TRCSESS utility consolidates output from several tracing sessions into a single
output, so you can trace a session more effectively.
ý A is incorrect because the TRCSESS utility doesn’t help you with enabling a trace. B is
wrong because it’s the TKPROF utility that helps interpret the output of a trace. D is wrong
because the TRCSESS session isn’t a stress testing tool.
10. þ A, B, and C. The new statistics aggregation dimensions help you monitor individual client
performance, manage the workload, and set threshold-based alerts.
ý D is wrong because the ADDM tool doesn’t get any data based on the new statistics
aggregation dimensions.

11. þ A. Oracle now implicitly converts SQL IN and OUT bind variables in both queries and
DML statements when they involve CLOB and NCLOB datatypes.
ý B is wrong since you had do the conversion explicitly in Oracle9i, not Oracle Database 10g.
C and D are wrong since the implicit conversion happens in both queries and DML statements.
12. þ B. The REGEXP_BETWEEN is not a valid Oracle regular expression function.
ý A, C, and D are wrong since all of these are valid Oracle regular expression functions.
13. þ A. All regular expression specification must first provide the source string, after which comes
the pattern (regular expression) and finally, any optional match options.
ý B and C are wrong since they present the right components in the wrong order. D is wrong
since it includes a nonexistent component (match).
14. þ A and D. Oracle Database 10g provides both case-insensitive and accent-insensitive
functionality through the NLS_SORT function.
ý B and C are wrong since you already have these features in Oracle9i.
15. þ B. The output of the UTL_COMPRESS utility is compatible with the output of the GZIP
and GUNZIP utilities.
ý A, C, and D are wrong alternatives since the UTL_COMPRESS utility’s output is compatible
with output from both the GZIP and GUNZIP utilities.
Lab Answer 33
16. þ C and D. C is correct since this statement was valid in Oracle9i and continues to work the
same way in Oracle Database 10g. D shows how you can enable resumable statements with the
new RESUMABLE TIMEOUT initialization parameter.
ý A and B are wrong because they present statements with the wrong syntax.
17. þ A. In Oracle Database 10g, you only need to set the number of shared servers by using the
ALTER SYSTEM SET SHARED SERVERS command to start the shared server.
ý B, C, and D are wrong since they are all nonexistent commands.
18. þ A and C. You let Oracle automatically tune checkpointing by either setting the FAST_
START_MTTR_TARGET to a non-zero value or leaving it out completely.
ý B is wrong since setting the FAST_START_MTTR_TARGET to zero will disable automatic
checkpoint tuning. D refers to a nonexistent option.
19. þ A. Host name is the only item that’s mandatory in the new easy connect naming method.
ý B, C, and D are wrong since none of these is mandatory under the new naming method.
20. þ B. If you specify the CONTINUOUS_MINE option, and specify a STARTSCN or STARTTIME
parameter value, Oracle will automatically add the redo logs by default.
ý A is wrong because this option helps you remove redo log files, not add them automatically.
C is wrong since this option is used for generating reconstructed statements without a ROWID.
D refers to a spurious procedure name.
LAB ANSWER
The following regular expression-based query will get you the result you have been asked to produce.
Notice the use of the pattern ', [^,]*,' in the query.
SQL> select regexp_substr('first child, second child , third child',
2 ', [^,]*,')
3* from dual;
REGEXP_SUBSTR('F
-------------------
, second child ,
SQL>
Blind Folio 1:1
Glossary
P:\010Comp\CertPrs8\862-4\glossary.vp
Composite Default screen CertPrs8 / OCP Oracle Database 10g Exam Guide / Alapati / 225862-4 / Glossary
2 Glossary
accent-insensitive sort An accent-insensitive sort is a new sorting option in

Oracle Database 10g. You can use the session parameter NLS_SORT to specify the
linguistic sort name. The _AI value is suffixed to a sort name to indicate an accent-
insensitive sort.
Active Session History (ASH) Active Session History (ASH) consists of

recent session activity. ASH is actually a rolling buffer in memory, and you can view
the statistics using the V$ACTIVE_SESSION_HISTORY view. The Manageability
Monitor (MMON) process flushes ASH data to disk every 60 minutes.
ADDM See Automatic Database Diagnostic Monitor.
advisory framework The advisory framework consists of a set of server-based

advisors that are designed around a common infrastructure. Automatic Database
Diagnostic Monitor (ADDM) is part of the advisory framework, as are the SQL
Tuning Advisor and other advisors. All the advisors have a uniform interface and
a common data source: the Automatic Workload Repository (AWR).
ALERT_QUE You can subscribe to the ALERT_QUE and read the ALERT_QUE
if you wish to create your own tool to display database alerts, rather than using the
Oracle Database 10g Database Control.
ALL_ROWS ALL_ROWS is the default value for the OPTIMIZER_MODE

initialization parameter. The optimizer uses a cost-based approach for all SQL
statements in the session, regardless of the presence of statistics, and optimizes with
a goal of best throughput (minimum resource use to complete the entire statement).
ARBn ARBn is an Automatic Storage Management (ASM) background process

that performs the rebalancing of data extents. You can have multiple ARB processes,
named ARB1, ARB2, and so on.
ASH See Active Session History.
ASM See Automatic Storage Management.
ASM_DISK_GROUPS The ASM_DISK_GROUPS initialization parameter

specifies the list of names of disk groups to be mounted by an ASM instance at
instance startup or when you issue the ALTER DISKGROUP ALL MOUNT statement.
ASM_POWER_LIMIT 3
ASM_DISKSTRING The ASM_DISKSTRING initialization parameter specifies

an operating system-dependent value used by ASM to limit the number of disks
considered for discovery. When a new disk is added to a disk group, the ASM instance
will discover the new disk using the value of ASM_DISKSTRING. If you omit this
parameter, the ASM instance will find all disks to which it has read/write access.
ASM file aliases Automatic Storage Management (ASM) alias filenames

provide a more intuitive way of referring to ASM files, rather than using the fully
qualified names (system aliases) that ASM generates when it creates new files.
ASM file templates Automatic Storage Management (ASM) files are named
collections of attributes that you apply to a file during its creation. Templates simplify
file creation. Templates are applied to a file, but are actually associated with a disk group.
ASM filenames Automatic Storage Management (ASM) filenames can be of

the following forms: fully qualified, numeric, alias, alias with template, incomplete,
and incomplete with template. The correct filenaming form depends on the context
in which you intend to use the file. The three different contexts are referencing an
existing file, creating a single new file, and creating multiple new files.
ASM files Automatic Storage Management (ASM) files are Oracle database files
stored in ASM disk groups. All ASM files are Oracle Managed Files (OMF), and you
must back up them with the Recovery Manager (RMAN). ASM doesn’t manage
binary files, alert logs, trace files, or password files.
ASM instance An Automatic Storage Management (ASM) instance is the

special instance you need to start in order to use ASM in your database. ASM
instances are unique in the sense that they don’t mount databases, but merely make
ASM files available to regular database instances. Databases communicate with an
ASM instance to get information about the ASM file layouts.
ASM_POWER_LIMIT The ASM_POWER_LIMIT initialization parameter

pertains to an ASM instance, and it controls the speed of a disk-rebalancing
operation. The range is 1 to 11, with 1 as the default and 11 providing the fastest
rebalancing when you add or remove disks from an ASM disk storage system. The
higher the limit, the faster rebalancing will complete. Lower values will take longer,
but they consume fewer processing and I/O resources.
4 Glossary
ASMB ASMB is a background process that exists in each database that uses
Automatic Storage Management (ASM). When you start the database, the ASMB
process connects to the ASM process and a foreground process, and conducts all
communication between the database and the ASM instance.
ATO See Automatic Tuning Optimizer.
AUDIT_TRAIL The AUDIT_TRAIL initialization parameter enables or

disables database auditing. AUDIT_TRAIL can take the values db or true, os,
and db_extended. The db_extended value enables database auditing and sends
audit records to the database audit trail (the SYS.AUD$ table). It also populates the
SQLBIND and SQLTEXT CLOB columns of the SYS.AUD$ table.
automatic channel failover When you backup your database with the
Recovery Manager (RMAN), one of the channels may fail during the process.
Automatic channel failover is the new feature whereby RMAN will attempt to
complete the backup on another channel.
automatic checkpoint tuning Oracle Database 10g automatically tunes

checkpointing activity to minimize recovery time while reducing the impact of
checkpointing on performance. You don’t need to set any checkpoint-related
parameters. You can either enable automatic checkpoint tuning by setting a
nonzero value for the FAST_START_MTTR_TARGET initialization parameter
or omit it from your init.ora or SPFILE file.
Automatic Database Diagnostic Monitor (ADDM) The Automatic

Database Diagnostic Monitor (ADDM) is a self-diagnostic engine that is part of
Oracle Database 10g. ADDM helps the database diagnose its performance and
determine how to resolve problems. ADDM runs automatically after each Automatic
Workload Repository (AWR) statistics capture and performs analysis on a proactive
basis. ADDM diagnoses the performance of the system, using time as a common
currency between components.
automatic maintenance tasks The automatic maintenance tasks

infrastructure enables Oracle Database 10g to automatically perform routine
administrative tasks such as collecting optimizer statistics during a predefined
maintenance window. By default, the maintenance window starts at 10 P.M. every
night and lasts until 6 A.M. the next morning, and also includes the entire weekend.
You can customize attributes of the maintenance window, including start and end
time, frequency, and days of the week.
automatic undo retention tuning 5
automatic optimizer statistics collection Oracle Database 10g fully

automates optimizer statistics collection. The Oracle Scheduler comes with a built-
in job called GATHER_STATS_JOB, which executes the DBMS_STATS.GATHER_
DATABASE_STATS_JOB_PROC procedure to automatically collect the statistics.
All you need to do is ensure that the STATISTICS_LEVEL initialization parameter
is set to TYPICAL or ALL (not BASIC). Oracle automatically gathers statistics for
all database objects that have stale or missing statistics.
Automatic Shared Memory Management Automatic Shared Memory

Management simplifies System Global Area (SGA) memory management by
automatically allocating memory among the four auto-tuned parameters: database
buffer cache (default pool), shared pool, large pool, and Java pool. To use Automatic
Shared Memory Management, set the SGA_TARGET initialization parameter to a
nonzero value and set the STATISTICS_LEVEL initialization parameter to
TYPICAL or ALL.
automatic shared server configuration The automatic shared server

configuration helps you to easily switch between shared server and dedicated server
configurations without needing to start a dispatcher.
Automatic Storage Management (ASM) Automatic Storage Management

(ASM) is an integration of the file system and a built-in volume manager for Oracle
database files. It extends the concept of stripe and mirror everything (SAME)
principles to optimize disk performance. ASM simplifies the optimal layout of
datafiles, control files, and log files. Database files are automatically distributed
across all available disks, and database storage is rebalanced whenever storage
configuration changes.
Automatic Tuning Optimizer (ATO) The SQL Tuning Advisor calls the
Automatic Tuning Optimizer (ATO) to perform four types of analysis: statistics
analysis, SQL profiling, access path analysis, and SQL structure analysis.
Automatic Undo Management Automatic Undo Management is the

recommended way to mange the undo in Oracle databases, although you could
still do it manually. Once you specify the automatic undo management mode in
the init.ora (or spfile) file and create an undo tablespace, Oracle will automatically
create and manage the necessary undo segments.
automatic undo retention tuning Oracle Database 10g automatically tunes the
initialization parameter UNDO_RETENTION to control retention of undo information
in rollback segments.
6 Glossary
Automatic Workload Respository (AWR) The Automatic Workload

Repository (AWR) is an embedded, self-managing repository that captures workload
information and performance-related statistics on a routine basis. The database uses
information contained in the repository for self-management activities.
AWR See Automatic Workload Repository.
backup compression If disk space is an issue, or your media-management software

does not support compression, you can use the Recovery Manager (RMAN) backup
compression feature to compress RMAN backup sets.
base statistics Base statistics refer to raw performance statistics, such as the number
of physical reads since instance startup. Metrics are derived from base statistics.
bigfile tablespace A bigfile tablespace is a large tablespace containing just one

file. Oracle Database 10g lets you create both bigfile tablespaces and traditional
tablespaces, now called smallfile tablespaces. The default tablespace type is smallfile.
The bigfile tablespace type makes a tablespace logically equal to a datafile.
block change tracking Oracle tracks the physical location of database changes
in a new file called the change-tracking file. The Recovery Manager (RMAN) uses
the change-tracking file to determine which data blocks to read during an incremental
backup, thus making incremental backups faster by avoiding the reading of entire
datafiles.
calendaring expression A calendaring expression is the primary method

of setting the REPEAT_INTERVAL attribute for a Scheduler job. A calendaring
expression has three attributes: frequency, repeat interval, and an optional specifier.
case-insensitive sort A case-insensitive sort is a new sorting option in Oracle

Database 10g. You can use the session parameter NLS_SORT to specify the linguistic
sort name. The _CI value is suffixed to a sort name to indicate a case-insensitive sort.
CATALOG START WITH The CATALOG START WITH command in the

Recovery Manager (RMAN) will look at all files that are not a part of the catalog
already, starting with the specified directory. This saves you time and effort in
remembering cryptic filenames.
compressed backups 7
change-aware incremental backups By using the new change-tracking file,

the Recovery Manager (RMAN) can avoid scanning the entire datafile during an
incremental backup. Instead, it will scan only the changed blocks of data, thus
reducing backup time.
change-tracking file Oracle tracks the physical location of database changes in

a new file called the change-tracking file. The Recovery Manager (RMAN) uses the
change-tracking file to determine which data blocks to read during an incremental
backup, thus making incremental backups faster by avoiding the reading of entire
datafiles.
Clone Database Tool The Clone Database Tool is an Enterprise Manager

wizard that lets you step through a database cloning operation. With this tool,
which uses RMAN to perform the cloning, you can clone a database to another
Oracle Home while the source database is open.
column-level VPD Virtual Private Database (VPD) is now more fine-grained.

Column-level VPD enables you to enforce row-level security when a security-relevant
column is referenced in a query. You can now enforce VPD rewrite when a query
references a particular column. You thus enforce access control based on the security
columns that are accessed by a user.
column-masking behavior By default, when a query references a security-

relevant column, column-level VPD restricts the number of rows returned. By using
column-masking behavior (using the SEC_RELEVANT_COLS_OPT parameter of
the DBMS_RLS.ADD_POLICY procedure), all rows will be displayed, including
those that reference security-relevant columns.
COMPATIBLE The COMPATIBLE initialization parameter allows you to use a

new release of Oracle, while at the same time guaranteeing backward-compatibility
with an earlier version. The parameter specifies the release with which Oracle must
maintain compatibility.
compressed backups You can now use binary compression to reduce the size
of your backup sets. You must have the compatibility set to at least 10.0.0 and use
the following Recovery Manager (RMAN) command:
BACKUP AS COMPRESSED BACKUPSET DATABASE;
8 Glossary
configurationless client connect Configurationless client connect is a new

connection identifier for SQL clients, which doesn’t depend on any configuration
files and doesn’t require name lookup services. In the client identifier syntax, all you
must have are the host, port, and service name to connect to a database server. This
also known as the easy naming connect method. This method simplifies network
management by enabling a database connection to be made without the need to first
configure a network service name or perform other network configuration on the
client. To configure the easy connect method, you specify the keyword EZCONNECT
in your sqlnet.ora file.
context-sensitive policies A context-sensitive policy changes when certain

session context attributes change within a user’s session. The database reevaluates
the policy function each time there is a context change. The policy predicates will
thus change, based on session context changes.
cross-platform transportable tablespaces Cross-platform transportable

tablespaces are tablespaces that can be transported across diffferent operating system
platforms.
CTWR The CTWR is the new Oracle background process that writes database
change information to the change-tracking file.
Data Pump The Data Pump export and import utilities provide high-speed
movement of data from one database to another. These utilities offer several
advantages over the original Oracle export and import utilities, including the ability
to completely restart export and import jobs, detach and reattach to long-running
jobs, estimate how much disk space an export job would consume, and perform
export and import operations over the network. The Data Pump utilities also
support fine-grained object selection.
DATA_PUMP_DIR DATA_PUMP_DIR is an environment variable that you

can define to specify the directory object name in Data Pump. When you use this
variable, you don’t need to specify the DIRECTORY parameter in a Data Pump job.
Data Pump direct path Direct path is one of two access methods that Data
Pump supports to load and unload table data. If it is possible, Data Pump tries to use
the direct-path access method to load and unload data. The other access method is
external tables.
DBA_DATAPUMP_JOBS 9
Database Control (Enterprise Manager) Database Control is the new

name for the Oracle Enterprise Manager GUI for managing Oracle databases. You
can use the Database Control for managing single databases, and the software comes
with the Oracle Database 10g Server software.
database features usage tracking Oracle Database 10g automatically tracks

usage of various database features. This enables you to evaluate how each feature is
being utilized in the database.
Database Upgrade Assistant (DBUA) The Database Upgrade Assistant

(DBUA) is a GUI-based Oracle tool that simplifies the task of upgrading to Oracle
Database 10g from an older version of Oracle software.
database wait model The database wait model enables you to determine what
sessions are waiting for, keeps a history of waits and wait durations per session, and
maintains wait statistics for SQL statements in a dynamic performance view.
datafile conversion If you are transporting tablespaces across platforms, the

files in both platforms must have the same endian format. If the endian formats are
different, you need to convert the datafiles either before or after you move the
datafiles that belong to the tablespaces you’re transporting.
DB_FLASHBACK_RETENTION_TARGET The DB_FLASHBACK_

RETENTION_TARGET initialization parameter specifies the upper limit (in
minutes) on how far back in time the database may be flashed back. Of course,
how far back you can flashback a database depends on how much flashback data
Oracle has kept in the flash recovery area.
DB_RECOVERY_FILE_DEST The DB_RECOVERY_FILE_DEST

initialization parameter specifies the default location for the flash recovery area.
DB_RECOVERY_FILE_DEST_SIZE The DB_RECOVERY_FILE_DEST_

SIZE initialization parameter specifies (in bytes) the limit on the total space
allocated for the database recovery files created in the flash recovery area.
DBA_DATAPUMP_JOBS The DBA_DATAPUMP_JOBS view displays all

Data Pump jobs in the database.
10 Glossary
DBA_ENABLED_TRACES The DBA_ENABLED_TRACES view displays

information about enabled SQL traces. The view shows the following types of
traces: CLIENT_ID, SERVICE, SERVICE_MODULE, and SERVICE_MODULE_
ACTION.
DBA_OUTSTANDING_ALERTS The DBA_OUTSTANDING_ALERTS

view describes alerts that have yet to be resolved.
DBA_SCHEDULER_JOB_LOG The DBA_SCHEDULER_JOB_LOG view

displays log information for all Scheduler jobs in the database.
DBA_SCHEDULER_JOB_RUN_DETAILS The DBA_SCHEDULER_JOB_

RUN_DETAILS view displays log run details for all Scheduler jobs in the database.
DBA_SERVER_REGISTRY The DBA_SERVER_REGISTRY view displays

information about the components loaded into the database. It helps you determine
the success of your database upgrade process.
DBMS_ADVISOR DBMS_ADVISOR is the database package that is the

foundation for the Server Manageability Suite of advisors (advisory framework)
that identify and resolve performance problems related to the various database
server components.
DBMS_AQADM The DBMS_AQADM package provides procedures to manage

Oracle Streams Advanced Queuing (AQ) configuration and administration information.
DBMS_DATAPUMP The DBMS_DATAPUMP package is used to perform the

Data Pump export and import of data.
DBMS_METADATA The DBMS_METADATA package lets you retrieve

metadata from the database dictionary.
DBMS_MONITOR The DBMS_MONITOR package lets you use PL/SQL for

controlling additional tracing and statistics gathering.
DBMS_MVIEW The DBMS_MVIEW package enables you to understand the

capabilities of materialized views and potential materialized views, including their
rewrite capability. The pacakge also enables you to refresh materialized views and
purge logs.
DURATION 11
DBMS_RLS The DBMS_RLS package contains the procedures to implement

and manage fine-grained access control, which is used to implement Virtual Private
Database (VPD).
DBMS_SCHEDULER The DBMS_SCHEDULER package provides a collection

of functions and procedures that help you manage the Oracle Scheduler facility.
DBMS_SERVER_ALERT The DBMS_SERVER_ALERT package lets you issue

alerts when some threshold has been violated.
DBMS_SQLTUNE The DBMS_SQLTUNE package provides the interface to

tuning SQL statements.
DBUA See Database Upgrade Assistant.
dense data Dense data is data where there is a row for each combination of the
various dimensions.
disk group An Automatic Storage Management (ASM) disk group is a set of

disks managed as a single logical unit. You add or remove storage from a disk group
by adding or removing ASM disks from a disk group. All ASM files are stored in a
disk group.
disk group mirroring Automatic Storage Management (ASM) disk groups

are mirrored at the extent level to protect data. There are three types of mirroring:
external redundancy, normal redundancy, and high redundancy.
disk group rebalancing Automatic Storage Management (ASM) automatically

dynamically rebalances disk groups when you add or remove disks from a disk group.
ASM always keeps I/O balanced by moving around only the amount of data proportional
to the amount of storage that is being added or removed from the disk group.
DROP DATABASE The new DROP DATABASE command drops a database

by deleting all database files, all online logs, control files, and server parameter files
(SPFILES).
DURATION DURATION is a Recovery Manager (RMAN) backup command

option that can take the values PARTIAL, MINIMIZE TIME, and MINIMIZE
LOAD. The DURATION option lets you control the speed and duration of your
backup operations.
12 Glossary
dynamic policies Dynamic policies apply to the Virtual Private Database

(VPD) concept. Dynamic policies change based on certain variables such as the
time of day, thus returning different sets of rows for the same query. Previously,
all VPD policies were dynamic by default, which meant that Oracle executed
the function for each DML statement. You can now use new static policies.
end-to-end application tracing The new end-to-end application tracing

capability simplifies the debugging of performance problems in multitier environments.
It also makes debugging and tracing of applications, which use MODULE and ACTION
name annotation, easier and more efficient.
endian format Endian format is the byte ordering of files. When you transport
tablespaces across platforms, you must ensure that the endian format is identical on
both platforms. If not, you need to convert the datafiles to ensure that they are the
same on the source and target platforms.
ESTIMATE The ESTIMATE parameter is a Data Pump export parameter and

specifies the method that export will use to estimate how much disk space each table
in the export job will consume (in bytes).
ESTIMATE_ONLY The ESTIMATE_ONLY Data Pump parameter estimates

the space that an export or import job would require, without actually performing
the export operation.
EXCLUDE The EXCLUDE Data Pump parameter enables you to exclude a

database object from an export or import operation.
EXPLAIN_MVIEW The EXPLAIN_MVIEW procedure of the DBMS_MVIEW

package tells you whether a materialized view is fast refreshable or eligible for
general query rewrite.
external table access driver Data Pump provides an external table access
driver (ORACLE_DATAPUMP) that reads and writes files to enable high-speed
loading and unloading of database tables.
external table population External table population is the ability to load data
into platform-independent, Oracle proprietary flat files from a database table.
flash recovery area 13
external tables External tables enable you to use external data as a virtual table
that you can view and join to other tables, without needing to load the data in
actual database tables. External tables are read-only (no DML activity is possible).
EZCONNECTt See configurationless client connect.
failure group A failure group is an Automatic Storage Management (ASM)

concept that refers to the set of disks inside a particular disk group that share a
common resource, whose failure must be tolerated. A common example is a set of
disks that connect to a common SCSI controller.
fast incremental backups The fast incremental backups feature speeds up

incremental backups by tracking block changes in the new change-tracking file.
The new background process CTWR writes changed block information to the
change-tracking file, and the Recovery Manager (RMAN) will back up only the
changed blocks.
fast ramp-up Fast ramp-up is the new feature wherein the database uses
Automatic Workload Repository (AWR) statistics to decide the number of undo
segments to bring online when you start an instance or when you switch an undo
tablespace.
fine-grained access control Fine-grained access control enables you to build

applications that enforce security policies at a low level of granularity. (These policies
are also referred to as VPD policies.) You can use it, for example, to restrict an
employee to see only his or her own information in a database table.
FIRST_ROWS You can specify FIRST_ROWS as the value for the

OPTIMIZER_MODE initialization parameter. Under the FIRST_ROWS
setting, Oracle will use a mix of cost and heuristics to find a best plan for
fast delivery of the first few rows.
flash recovery area The flash recovery area is an unified storage location for
backups, archive logs, and any other files needed for Oracle recovery. The backup
files are automatically deleted after they are backed up by the Recovery Manager
(RMAN). The flash recovery area is also the location for saving the Flashback
Database logs.
14 Glossary
Flashback Database The Flashback Database feature lets you quickly bring your
database to a prior point in time by undoing all the changes that have taken place
since that time. You enable the Flashback Database feature after you first configure
a flash recovery area, and then set the retention target with the DB_FLASHBACK_
RETENTION_TARGET initialization parameter. The flashback time interval will
actually depend on the number of flashback database logs stored in the flash
recovery area.
Flashback Database logs Flashback Database logs are a new type of database
log files, which are analogous to redo logs. When you turn on the Flashback Database
feature, Oracle will start logging before images of data blocks that are being changed.
These before images are saved in the Flashback Database logs, which are automatically
created and managed in the flash recovery area. The new background process RVWR
(recovery writer) writes the Flashback Database data from the flashback buffer to the
Flashback Database logs.
Flashback Drop The Flashback Drop feature lets you undo the effects of a
DROP TABLE statement. The dropped tables are saved in the Recycle Bin. The
command you actually use to flashback a table is of the format FLASHBACK TABLE
table-name TO BEFORE DROP.
Flashback Query The Flashback Query feature lets you query a database as of
a certain clock time or a system change number.
Flashback Table The Flashback Table feature lets you recover a table to a point
in time in the past without restoring a backup.
Flashback Transaction Query The Flashback Transaction Query capability

enables you to examine changes to the database at the transaction level. Using the
transaction history, you can diagnose problems, perform analysis, and audit transactions.
FLASHBACK_TRANSACTION_QUERY The FLASHBACK_

TRANSACTION_QUERY view contains all the SQL statements that help you
undo the changes made by specific transactions, using the Flashback Transaction
Query feature.
Flashback Versions Query The Flashback Versions Query feature lets you
view changes to one or more rows, along with all the metadata of the changes.
INSTANCE_TYPE 15
flushing the buffer cache Oracle Database 10g lets you flush the buffer cache
by using the following command:
ALTER SYSTEM FLUSH BUFFER_CACHE;
global scripts Global scripts, an enhanced Recovery Manager (RMAN) feature,

are scripts that can be used by any database connecting to the target database.
grid computing Grid computing is the coordinated use of a large number of

servers and storage acting as one computer. Grid computing lets you automatically
provision for spikes on demand, and you’ll have computing power available when
you need it. Grids are built with low-cost modular components, so you can start
small and preserve your investment as your business needs grow.
Grid Control The Grid Control is the centralized version of Oracle Enterprise
Manager, which lets you manage several databases and hosts simultaneously. You
must install the Grid Control separately from the database.
guaranteed undo retention When you enable guaranteed undo retention by

using the RETENTION GUARANTEE clause either during the creation of the undo
tablespace or by altering it later, the database never overwrites unexpired undo data.
hash-partitioned global indexes In a hash-partitioned global index, each

partition contains the values determined by a hash function, which is based on the
partitioning key and the number of partitions. These indexes improve performance
by spreading contention when the index is monotonically growing, because most of
the index insertions occur only on the right edge of an index.
idle timeouts You can set up maximum idle timeouts for a resource plan using
the DBMS_RESOURCE_MANAGER package. When a session exceeds the MAX_
IDLE_TIME parameter value specified in the CREATE_PLAN_DIRECTIVE
procedure, the Process Monitor (PMON) will kill the session.
INCLUDE The INCLUDE Data Pump parameter lets you require that only
specified object types and objects be included in an export or import job.
INSTANCE_TYPE The INSTANCE_TYPE initialization parameter is used

in connection with an Automatic Storage Management (ASM) instance to specify
whether the instance is a database instance or an ASM instance.
16 Glossary
job A job is a user-defined task that is scheduled to run one or more times. A job
contains information about the task (the action) to be run and when it should run
(the schedule). You can specify the action and schedule when creating the job,
or the job can refer to an existing program and schedule.
job class A job class is a group of jobs that have similar characteristics and
behavior. A job class is a way of grouping jobs into larger entities, thus enabling
you to prioritize among the job classes.
job priority Job priority helps you prioritize the jobs in your database. There are
two levels at which you can prioritize a job: at the class level, using resource plans,
and within the class, using the job priority attribute of the job. The default priority
of a job is 3.
locally managed tablespaces Locally managed tablespaces track all extent

information in the tablespace itself by using bitmaps. The DBMS_SPACE_ADMIN
package provides procedures for administering locally managed tablespaces.
locking statistics You can lock representative statistics when a table’s data
keeps changing continuously. You can lock a table with or without any statistics.
logging level You can set the logging level of the Scheduler by using the
LOGGING_LEVEL parameter. You can set this parameter to either DBMS_
LOGGING_ FULL or DBMS_SCHEDULER.LOGGING_RUNS at either the
job class or the individual job level.
MANAGE SCHEDULER MANAGE SCHEDULER is a Scheduler-associated

system privilege, which lets a user perform all Scheduler administration tasks. The
SCHEDULER_ADMIN role has all the privileges of the MANAGE SCHEDULER
privilege along with the WITH ADMIN OPTION clause. The DBA role includes the
SCHEDULER_ADMIN role by default.
Manageability Monitor (MMON) The Manageability Monitor (MMON)

background process performs various manageability-related background tasks,
including issuing alerts whenever a given metric violates its threshold value and
taking snapshots for the Automatic Workload Repository (AWR) feature. The
MMON wakes up every minute to compute metric values. The MMON also verifies
the thresholds for all the metrics you define and generates the alerts, if necessary.
network mode export 17
materialized view decomposition Materialized view decomposition refers

to the breaking up of a nonrefreshable materialized view into submaterialized views
referenced by the original materialized view. The automatic materialized view
decomposition mechanism handles cases where the materialized view-defining query
has subqueries, set operators, or inline views. Each of the submaterialized views will
be refreshable.
Memory Manager (MMAN) The new Memory Manager (MMAN)

background process manages automatic shared memory. MMAN serves as the
System Global Area (SGA) memory broker and coordinates the sizing of the
individual memory components. It tracks the size of the memory components
and monitors memory-resizing operations.
MERGE The MERGE command performs conditional update and insert operations.
You may also use an optional DELETE clause with a MERGE command.
metrics Metrics are secondary statistics that the database derives from base
statistics. Metrics track the rate of change of a variable. An example of a database
metric is the number of physical reads in the database in the past 60 minutes.
MMAN See Memory Manager.
MMNL The MMNL (Manageability Monitor Process Light; shown as the

Manageability Monitor Process 2 in a query of the V$BGPROCESS view) performs
frequent and lightweight manageability-related tasks, such as session history capture
and metrics computation. If the Automatic Session History (ASH) buffer fills before
MMON flushes it, MMNL will flush the data to disk.
MMON See Manageability Monitor.
MODEL See SQL MODEL clause.
network mode export By using the NETWORK_LINK export parameter, you

can perform a network export, provided you also specify the name of a valid database
link. A network export moves data from a remote database to a dump file set local to
the instance running the Data Pump job.
18 Glossary
network mode import By using the NETWORK_LINK import parameter,

you can initiate a network import. The impdp client will initiate the import
request, and the server contacts the remote source database referenced by source_
database_link. The server retrieves and writes the data directly to the target
database tables. Since the entrie import is directly via the network, dump files aren’t
necessary.
nonthreshold alerts Some server-generated alerts refer to specific database

events such as ORA-1555 (snapshot too old) errors. These are not based on any
thresholds, so they are called nonthreshold alerts, or stateless alerts. These alerts go
directly to the history table, without ever appearing in the DBA_OUTSTANDING_
ALERTS view.
online segment shrink The online segment shrink feature shrinks segments
online and in-place (tables, indexes, and materialized views) that have free space
in them, thereby enhancing efficiency of space utilization.
Partition Change Tracking (PCT) Partition Change Tracking (PCT)

is the ability to identify which rows in a materialized view are affected by a detail
table partition.
partition outer join Partitioned outer joins are extensions to the outer join
syntax, and they are used primarily to improve performance and simplify SQL
queries for time-based calculations.
PCT See Partition Change Tracking.
PCT refresh When a materialized view is partitioned on the partitioning key

column or join-dependent expressions of the detail table, it is better to truncate one
or more partitions during a materialized view refresh, and then populate the partition
with new data. This variant of the fast refresh is known as a PCT refresh.
PLSQL_OPTIMIZE_LEVEL PLSQL_OPTIMIZE_LEVEL specifies the

optimization level that Oracle will use to compile PL/SQL library units. The higher
the setting of this parameter, the more effort the compiler makes to optimize PL/SQL
library units. Oracle claims that setting this parameter to 1 or 2 will make PL/SQL
programs run considerably faster.
projected columns 19
policy framework The policy-based database framework lets you monitor all
targets to see if their configuration conforms to recommended policy configuration
settings. These policies are based on Oracle’s best practice configuration
recommendations. The database configuration framework is built on top of the
configuration and metric collection facility of the Oracle Enterprise Manager.
policy function Fine-grained access control enables you to implement security

policies with policy functions and to associate these policies with tables or views.
The security policy function generates a WHERE condition that is appended to
relevant SQL statements, thereby restricting user access to rows of data in the table
or view.
Post-Upgrade Status Tool The Post-Upgrade Status Tool is invoked by

running the utlu101s.sql script located in the $ORACLE_HOME/rdbms/admin
directory, after you upgrade a database to the Oracle Database 10g release. The script
will tell you if the individual components of the new database have been successfully
upgraded.
POWER The POWER clause is used when you rebalance an Automatic Storage
Management (ASM) disk group and specifies the power level of a disk rebalancing
job. By using the POWER clause in a rebalance disk group command, you can
override the setting of the default speed set by using the initialization parameter
ASM_POWER_LIMIT.
proactive tablespace management The Tablespace Advisor gathers and

reports historical data about each tablespace’s disk space usage and notifies
administrators when tablespaces run low on available space.
program A program is a collection of metadata about what task the Scheduler

will run.
projected columns When dealing with external table files, which contain rows
of data that may be rejected due to errors, the projected column feature enables you
to get a consistent result set, independent of the columns referenced by the SQL
statement accessing the data. Prior to Oracle Database 10g, only the columns referenced
by the SQL statement were projected out by the access driver, and some rows were
rejected due to conversion errors or data format errors.
20 Glossary
PURGE You need to use the PURGE clause when you drop a database table if you
want Oracle to remove the table permanently. Otherwise, Oracle will save the table
in the Recycle Bin. Using the DROP TABLE PURGE command is equivalent to using
the old DROP TABLE command.
RATIO RATIO refers to the new resource allocation method for specifying how
much CPU each consumer group or subplan gets, when you use the Database Resource
Manager. The RATIO method for specifying CPU allocation is for single-level plans
that use ratios to specify how CPU is distributed among consumer groups. EMPHASIS,
the default method, is for multilevel plans that use percentages to specify how CPU
is distributed.
RBAL The RBAL background process coordinates rebalancing activity for disk
groups in an Automatic Storage Management (ASM) instance.
rebalance Rebalance is an Automatic Storage Management (ASM) term that

refers to the automatic rebalancing of disk groups when you add or remove disks.
ASM performs the rebalancing to maintain balanced I/O across all the disks in a
disk group.
Recycle Bin The Recycle Bin is actually a data dictionary table containing
information about dropped objects. Dropped tables and any associated objects—
such as indexes, constraints, and nested tables—are renamed. You can use the
FLASHBACK TABLE … TO BEFORE DROP command to recover a dropped table
from the Recyle Bin.
Redo Logfile Size Advisor The Redo Logfile Size Advisor recommends the
optimal size of redo log files.
remapping Remapping is a Data Pump concept that refers to the ability to

apply transformation during an import operation. You can remap datafiles using
the REMAP_DATAFILE parameter, tablespaces using the REMAP_TABLESPACE
parameter, and schemas using the REMAP_SCHEMAS parameter.
renaming tablespaces Oracle Database 10g provides the ability to rename

tablespaces. You no longer need to create a new tablespace, copy the contents from
the old tablespace, and drop the old tablespace.
segment shrinking 21
RESUMABLE_TIMEOUT The RESUMABLE_TIMEOUT initialization

parameter enables or disables resumable statements. You can also use this parameter
to specify a resumable timeout at the system level.
REWRITE_OR_ERROR The REWRITE_OR_ERROR hint will issue an error if

a query fails to rewrite. Using the REWRITE_OR_ERROR hint in a query causes the
following error if the query failed to rewrite:
ORA-30393: a query block in the statement did not rewrite
RUN_TO_COMPLETION RUN_TO_COMPLETION is a new value that you

can use for the CPU_MTH parameter when you create a resource consumer group. It
specifies that sessions with the largest active time are scheduled ahead of other sessions.
The CPU_MTH parameter specifies the distribution of CPU among sessions in a
consumer group. The default value is ROUND_ROBIN, which uses a round-robin
schedule to ensure that sessions are executed fairly.
schedule A schedule indicates when a job should run. It has a start date that
specifies the date and time when the schedule starts, an end date that indicates the
date and time when the schedule expires, as well as a repeat interval that indicates
how often it will repeat.
Scheduler The Scheduler is Oracle’s new scheduling feature that gives you the
ability to schedule a job to run at a particular date and time. It also provides you the
ability to create libraries of sharable Scheduler objects You can group jobs that share
common characteristics into larger entities called job classes, which can be prioritized
by controlling the system resources allocated to each of them.
Segment Advisor The Segment Advisor gives advice on whether an object

is a good candidate for the new online shrink operation, based on the amount of
fragmentation within segments. The Segment Advisor also reports on the historical
growth trend of segments.
segment resource estimation The new segment resource estimation feature

facilitates space management by giving a size estimate of the size of a new table or
index, so you can ensure that sufficient space is available.
segment shrinking Segment shrinking is the ability to shrink a segment in

order to eliminate fragmentation within the segment. Shrinking a segment can also
lower the high-water mark (HWM) of space usage for that object.
22 Glossary
server-generated alerts Server-generated alerts are alerts that the database

will proactively send to administrators when a problem is anticipated or any of the
user-selected metrics exceeds a defined threshold.
Server Manageability Suite The Server Manageability suite of Advisors is a

set of expert systems that helps you identify and resolve various performance problems
in your database. These expert systems are the SQL Tuning Advisor, the SQL Access
Advisor, the Undo Advisor, the Segment Advisor, and the various memory advisors.
SGA_TARGET The SGA_TARGET initialization parameter specifies the total

size of all SGA components. If SGA_TARGET is specified, the following SGA
memory pools are automatically sized: buffer cache (DB_CACHE_SIZE), shared
pool (SHARED_POOL_SIZE), large pool (LARGE_POOL_SIZE), and Java pool
(JAVA_POOL_SIZE).
shared policies Shared policies apply to Virtual Private Directory (VPD). They
let you apply the same policy to several objects. You can have both shared static and
shared context-sensitive policy types.
SKIP_UNUSABLE_INDEXES The SKIP_UNUSABLE_INDEXES

initialization parameter enables or disables the use and reporting of tables with
unusable indexes or index partitions.
smallfile tablespace In Oracle Database 10g, you can have two types of
tablespaces: bigfile and smallfile. Smallfile is the default tablespace type, and
it is the same as the standard tablespaces used in previous Oracle versions.
snapshot The Automatic Workload Repository (AWR) automatically collects

performance data (by default, on an hourly basis). These statistics are known as
snapshots. You can also manually create snapshots.
snapshot baseline Baselines are defined on a pair of snapshots, and serve to

tag sets of snapshot data to compare performance against. Baselines help you retain
snapshot data belonging to a representative period in the past to compare against
the current database behavior.
sorted hash cluster Sorted hash clusters are new data structures that let you
retrieve data faster in applications where data is requested in the order in which it
was inserted.
SQL Tuning Set (STS) 23
sparse data Sparse data refers to data with gaps, where no row exists for a
certain combination of dimensions.
SQL Access Advisor The SQL Access Advisor identifies and helps resolve
performance problems relating to SQL statement execution by recommending
which indexes or materialized views to create, drop, or retain.
SQL MODEL clause The SQL MODEL clause provides a powerful building block
for complex calculations such as forecasts and budgets. Using the MODEL clause, you
can treat relational tables as n-dimensional arrays and specify interrow references
without complex SQL joins and unions. With the MODEL clause, you can define a
multidimensional array on query results, and then apply sophisticated rules on the
array to calculate new values. By integrating advanced calculations into the database,
performance, scalability, and manageability are enhanced significantly compared to
performing the calculations using external products.
SQL profile The Automatic Tuning Optimizer (ATO) creates profiles of SQL
statements, which are called SQL profiles, consisting of auxiliary statistics specific
to that statement. SQL profiles address the problem of the query optimizer sometimes
using incorrect statistics, by collecting additional information using sampling and
partial execution techniques to verify and, if necessary, adjust the optimizer estimates.
SQL regular expressions Regular expressions enhance search-and-replace

capabilities. This functionality is implemented through new functions that are
regular expression extensions to existing Oracle functions such as LIKE, REPLACE,
and INSTR.
SQL Tuning Advisor The SQL Tuning Advisor is a new database advisor that
eliminates manual tuning of SQL statements. It provides tuning advice in the form
of precise actions along with their expected performance benefit. You can use this
feature for SQL tuning of packaged applications, without requiring any modification
to the application code.
SQL Tuning Set (STS) A SQL Tuning Set (STS) is a new database object used
for capturing SQL workload information and includes one or more SQL statements,
a list of bind values, and basic execution statistics such as elapsed time, CPU time,
and so on. SQL Tuning Sets provide the basic framework for capturing, managing,
and tuning a representative SQL workload. SQL Tuning Sets allow selective, on-
demand tuning of custom workloads. You can capture any SQL statements of
interest and store them in an STS for future tuning without having to build and
maintain SQL scripts for tuning purposes.
24 Glossary
SQLTUNE_CATEGORY The SQLTUNE_CATEGORY initialization parameter

specifies the category name that sessions can use to look up SQL profiles during SQL
compilation. By default, all profiles are created in the default category. This means
that all user sessions where the SQLTUNE_CATEGORY initialization parameter is set
to DEFAULT can use the profile.
STARTUP UPGRADE STARTUP UPGRADE is the new way to start a database

before you run the upgrade script. This command will start the database in the
upgrade mode and sets system initialization parameters to values required to let the
database upgrade scripts run. You need to use this mode only when you first start an
older version of an Oracle database with a newer version (Oracle Database 10g) of
the Oracle Database Server.
static policies Static policies apply to the Virtual Private Database (VPD)
concept. Static policies enforce an unchanging policy. Previously, all VPD policies
were dynamic by default, which meant that Oracle executed the function for each
DML statement. Static policies enforce the same predicate for access control,
regardless of the user, thus ensuring the same policy predicate for all users. The
new static policies improve performance, since they don’t always reexecute policy
functions for each DML statement.
STATISTICS_LEVEL The STATISTICS_LEVEL initialization parameter

specifies the level of collection for database and operating system statistics, which
the database needs for many purposes, including making self-management decisions.
The default value is TYPICAL. The other possible values are BASIC and ALL.
Oracle recommends that you use the default value of TYPICAL to get the statistics
necessary for most database management tasks, including using the various advisors.
SWITCH DATABASE SWITCH DATABASE is a new Recovery Manager

(RMAN) backup command that enables you to perform a fast restore of your
database. Unlike a normal restore, this command doesn’t copy any database files.
Instead, it merely points the datafile pointers in the control file to the backup file
location and begins recovery.
SYSAUX tablespace SYSAUX is a new, mandatory Oracle Database 10g

tablespace. It provides a centralized location for all auxiliary database metadata
that isn’t a part of the SYSTEM tablespace and reduces the number of tablespaces
created by default.
UNCATALOG 25
table monitoring Table monitoring refers to the tracking of changes to tables

to determine if statistics collection is necessary. In Oracle Database 10g, table
monitoring is enabled by default. The database will collect optimizer statistics
automatically by determining which objects have stale statistics or no statistics.
temporary tablespace group A temporary tablespace group lets you use

temporary space from multiple tablespaces. Using a tablespace group helps reduce
the contention for temporary tablespace when the database is performing huge sorts.
threshold-based alerts Server-generated alerts can be threshold-based on

nonthreshold-based. Threshold-based alerts include alerts for events like CPU time
per service call, for which you might specify warning and critical thresholds. You
can use the SET_THRESHOLDS procedure of the DBMS_SERVER package to set
thresholds for various events.
time model statistics Time model statistics indicate the amount of DB time
associated with a process from the V$SESS_TIME_MODEL and V$SYS_TIME_
MODEL views. Time model statistics help the database keep track of the time spent
in performing internal operations such as parse, execute, input/output, and so on.
The database uses this information for making self-tuning decisions and to diagnose
performance problems.
TRANSFORM The TRANSFORM parameter applies to Data Pump import. It

lets you change the DDL statements for an object, by letting you exclude either or
both segment attributes, as well as the storage clauses of objects.
trcsess The trcsess command-line utility consolidates information from

several trace files into a single file, to enable meaningful, session-based tracing.
TUNE_MVIEW The TUNE_MVIEW procedure of the DBMS_ADVISOR package

shows you how to optimize your materialized view creation statements. It also suggests
ways to ensure a fast refresh and general query rewrite of materialized views.
UNCATALOG You use the UNCATALOG command in the Recovery Manager

(RMAN) to remove backup pieces from the recovery catalog, as shown here:
RMAN> change backuppiece 'file_name' UNCATALOG;
26 Glossary
Undo Advisor The Undo Advisor is part of the advisory framework. It helps
database administrators in sizing the undo tablespace and in setting the size of the
UNDO_RETENTION parameter.
UNDO_RETENTION The UNDO_RETENTION parameter specifies (in

seconds) the minimum time for which Oracle retains undo information.
uniform audit trail Oracle tracks a set of identical fields for both standard and
fine-grained auditing to enable you to easily analyze database activity. This tracking
of identical information is called the uniform audit trail. There is a new audit trail
view, DBA_COMMON_AUDIT_TRAIL, which combines standard and fine-grained
audit records.
Upgrade Information Tool The new Upgrade Information Tool, invoked by

running the utlu101i.sql script, provides information before a database upgrade by
performing some preliminary checks on the existing database. For example, it checks
whether there is enough space and whether there are any obsolete initialization
parameters.
user-specified quoting character Database programmers can now choose

any convenient delimiter and define it as the quoting character, using the new quote
operators.
UTL_COMPRESS The UTL_COMPRESS package provides a set of data

compression utilities that have the familiar functionality of the zip and unzip (gzip
and gunzip) utilities in a PL/SQL environment. This package also handles LOBs and
has features to add and later extract several pieces into a single archive.
UTL_MAIL The UTL_MAIL package is a utility for managing e-mail. It includes

commonly used e-mail features, such as attachments, CC, BCC, and return receipt.
VPD See Virtual Private Database.
Virtual Private Database Virtual Private Database (VPD) enables you to

enforce fine-grained security by applying security policies directly to tables, views,
or synonyms. When a user accesses a table, view, or synonym that is protected with
a VPD policy, the database dynamically modifies the user’s SQL statement, using
any condition that can be expressed in or returned by a function. You can apply
VPD policies to SELECT, INSERT, UPDATE, INDEX, and DELETE statements.
window priority 27
window A window is a time duration for which you can specify certain resource
allocations. Like a schedule, it has a start date when the window becomes active or
opens and a duration that specifies how long the window will be open, as well as an
end date. It may also have a repeat interval that specifies how often the window will
open. You generally associate a resource plan with a window in order to specify how
resources should be allocated among the job classes.
window group A window group represents a list of windows and facilitates

management of windows. For example, you can combine the weekend and holiday
windows into a single downtime window group.
window priority Window priorities are relevant when you are dealing with
overlapping windows. If two windows with the same priority overlap, the active
window stays open. If two windows with different priorities overlap, the higher
priority window will open, and the lower priority window will close.

Mcgraw Hill Osborne Ocp Oracle Database 10G New Features For Administrators Exam Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mcgraw Hill Osborne Ocp Oracle Database 10G New Features For Administrators Exam Guide

Hochgeladen von

Copyright:

Verfügbare Formate

Color profile: Generic CMYK printer profile

2 Chapter 1: Installation, Server Configuration, and Database Upgrades

O racle Corporation has ambitiously positioned Oracle Database 10g as a

Several new manageability-enhancing features, along with revamped older features,

Installation New Features Support 3

CERTIFICATION OBJECTIVE 1.01

Installation New Features Support

■ Database management choices

4 Chapter 1: Installation, Server Configuration, and Database Upgrades

Database Management Choices

Installation New Features Support 5

6 Chapter 1: Installation, Server Configuration, and Database Upgrades

The Database Configuration Assistant (DBCA) can automatically configure the

Automatic Pre-Install Checks

Pre-Installation Checks Performed

Installation New Features Support 7

Methods for Performing Pre-Installation Checks

■ As part of an actual installation process

New File Storage Options

■ Automatic Storage Management (ASM) This option offers a way to easily

8 Chapter 1: Installation, Server Configuration, and Database Upgrades

Backup and Recovery Options

■ Do not enable automatic backups

Database User Password Specification

Installation New Features Support 9

Cluster Ready Services

Enterprise Configuration Management Tool

■ Collect necessary host and database configuration information.

10 Chapter 1: Installation, Server Configuration, and Database Upgrades

Collecting Host and Database Configuration Information

■ Memory, CPU, and I/O configuration on the host

Monitoring and Managing Enterprise Configuration

■ View and compare the hardware and software configurations of individual

Installation New Features Support 11

■ Clone Oracle Homes and database instances.

Using OEM Database Control to

1. On the OEM Database Control home page, click Setup.

12 Chapter 1: Installation, Server Configuration, and Database Upgrades

Oracle Software Cloning

Performance Enhancements to the Installation Process 13

CERTIFICATION OBJECTIVE 1.02

14 Chapter 1: Installation, Server Configuration, and Database Upgrades

Minimal Hardware Requirements

Easier and Cleaner Deinstallation

Performance Enhancements to the Installation Process 15

To deinstall your Oracle 10g software, follow these steps:

3. Start the OUI.

Automatic Launching of Software

Response File Improvements

16 Chapter 1: Installation, Server Configuration, and Database Upgrades

CERTIFICATION OBJECTIVE 1.03

Simplified Instance Configuration

Let’s start with a discussion of the enhancements in the DBCA tool.

Database Configuration Assistant (DBCA) Enhancements

Simplified Instance Configuration 17

Creating a New Database Manually

There are several important DBCA enhancements in Oracle Database 10g,

18 Chapter 1: Installation, Server Configuration, and Database Upgrades

The SYSAUX Tablespace

Flash Recovery Area

The flash recovery area is mandatory if you wish to configure automatic

Simplified Instance Configuration 19

■ All control files

Automatic Storage Management (ASM)