Selftest 1Z0-043 - StudyGuide

1Z0-043
Oracle Database 10g: Administration II

Oracle 1Z0-043 Study Guide
© 2006 Self Test Software, a Kaplan IT Company. All rights reserved. No part of this
study guide may be used or reproduced in any manner whatsoever without written
permission of the copyright holder. The information contained herein is for the personal
use of the reader and may not be incorporated in any commercial programs, other books,
databases, or any kind of software without written consent of the publisher. Making
copies of this study guide or any portion for any purpose other than your own is a
violation of United States Copyright laws.
Information has been obtained by Self Test Software from sources believed to be
reliable. However, because of the possibility of human error by our sources, Self Test
Software, or others, Self Test Software does not guarantee the accuracy, adequacy, or
completeness of any information in this study guide and is not responsible for any errors
or omissions or the results obtained from use of such information.
Oracle® is a registered trademark of Oracle in the United States and/or other countries.
Self Test Software

500 Northridge Road
Suite 240
Atlanta, Georgia 30350
800-244-7330 (US & Canada)
678-277-3240
www.selftestsoftware.com
2
Contents
Contents......................................................................................................................... 3
Pass the Exam with the Self Test Study Guide ............................................................................................ 5
Understanding Globalization Support: Oracle 10g Administration II ....................... 6
Introducing Globalization Support................................................................................................................. 7
Using Datetime Data Types ........................................................................................................................ 24
Using Linguistic Sorts and Searches .......................................................................................................... 28
Review Checklist: Understanding Globalization Support: Oracle 10g Administration II ............................. 33
Configuring and Using Recovery Manager: Oracle 10g Administration II ............. 34
Configuring Recovery Manager .................................................................................................................. 35
Using Recovery Manager............................................................................................................................ 41
Review Checklist: Configuring and Using Recovery Manager: Oracle 10g Administration II..................... 49
Database Recovery: Oracle 10g Administration II.................................................... 50
Introducing Database Recovery.................................................................................................................. 51
Recovering Control Files............................................................................................................................. 53
Performing Incomplete Recovery................................................................................................................ 56
Review Checklist: Database Recovery: Oracle 10g Administration II ........................................................ 65
Understanding Flashback Database and Database Corruption: Oracle 10g
Administration II .......................................................................................................... 66
Understanding Flashback Database........................................................................................................... 67
Understanding Database Corruption .......................................................................................................... 77
Review Checklist: Understanding Flashback Database and Database Corruption: Oracle 10g
Administration II .......................................................................................................................................... 82
Recovering from Non-Critical Losses and User Errors: Oracle 10g Administration
II .................................................................................................................................... 83
Recovering from Non-Critical Losses ......................................................................................................... 84
Recovering from User Errors ...................................................................................................................... 89
Review Checklist: Recovering from Non-Critical Losses and User Errors: Oracle 10g Administration II... 95
Understanding Automatic Database, Storage, and Memory Management: Oracle
10g Administration II................................................................................................... 96
Understanding Automatic Database Management ..................................................................................... 97
Understanding Automatic Storage Management ...................................................................................... 120
Understanding Automatic Memory Management......................................................................................133
Review Checklist: Understanding Automatic Database, Storage, and Memory Management: Oracle 10g
Administration II ........................................................................................................................................ 137
Managing Resources and Automating Tasks: Oracle 10g Administration II ....... 138
Managing Resources Using the Database Resource Manager................................................................ 139
Automating Tasks Using the Scheduler.................................................................................................... 154
Review Checklist: Managing Resources and Automating Tasks: Oracle 10g Administration II............... 175
Understanding Diagnostic Resources and Securing the Listener: Oracle 10g
Administration II ........................................................................................................ 176
Understanding Diagnostic Resources....................................................................................................... 177
Securing the Listener ................................................................................................................................ 181
Review Checklist: Understanding Diagnostic Resources and Securing the Listener: Oracle 10g
Administration II ........................................................................................................................................ 192
3
Monitoring and Managing Storage: Oracle 10g Administration II......................... 193

Understanding Resumable Space Allocation............................................................................................ 194
Using Segment Shrink and the Segment Advisor..................................................................................... 199
Understanding Special Storage Options................................................................................................... 210
Understanding Index Space Usage and Managing Tablespace Usage ................................................... 216
Optimizing Redo Log File Space .............................................................................................................. 223
Review Checklist: Monitoring and Managing Storage: Oracle 10g Administration II................................ 228
Taking the Test Strategies ........................................................................................................................ 229
Thank You and Good Luck on your Exams! ............................................................................................. 232
4
Pass the Exam with the Self Test Study Guide

As a certification candidate, you’re on the lookout for as many test preparation resources as possible, but your time is
at a premium. So, we put together the Study Guide with your study goals and busy schedule in mind.
Create a study plan – and stick to it. Don’t try to cram. Set aside specific study times so you can thoroughly
prepare for your exam. In our experience, following a disciplined prep schedule leads to success on Exam Day. To
thoroughly gain the benefits of our Study Guide, we recommend that you start preparing about six weeks prior to
taking your exam.
Use all the prep tools in your Study Guide. Your Guide contains a full suite of products to help you thoroughly
prepare for your exam. Each one is designed with a specific study purpose in mind. Here’s how we recommend you
use the products together:
1. Perform a baseline checkup. Set your personal baseline by taking the Self Test Practice Test in
Certification Mode. It is a timed test that simulates the real exam. Objective-based scoring shows you the
areas you are relatively strong in, and those you need to devote additional time to.
2. Concentrate your studies by objective. Since your study time has to be in chunks, use the exam’s
structure by objective to help you organize your study sessions. Use each product to study at the objective
level with particular emphasis on the objectives where you did not score 100% in your baseline checkup.
• Study Guide. Read the Study Guide by objective to familiarize yourself with the exam content. The
Study Guide is objective-driven and contains a Scope and Focused Explanation for each objective. At
the end of each major objective is a Review Checklist that lists the key points covered in this area of the
exam.
• Self Test Flash Cards. Drill through the Flash Cards by objective to be sure you know the fundamental
concepts. Make Personal Study Notes with these cards to supplement your learning.
• Self Test Practice Test. Use the Practice Test in Learning Mode by objective. Answer the questions,
read the tutorials, and use the Personal Study Notes to supplement your learning and/or highlight items
that you’ll want to review before the exam.
• References. Use your favorite references (books, web references, etc.) to get additional materials on
more complex subject matter.
3. Track your progress. You’ve completed your objective-driven study plan. Now you’re ready to see how
you’ve progressed. Take the Self Test Practice Test in Certification Mode again. Did you score 100%? If not,
go back to your objective study plan and focus on your weaknesses. Keep checking yourself, highlighting
objectives that you’ll need to study, until you consistently score 100%.
Do your final preparation. Print the Review Checklists from the Study Guide and the Personal Study Notes from the
Self Test Practice Test and Flash Cards. Use these as your condensed final review before taking the real exam. And,
before taking the real exam, read the Test-Taking Strategies at the end of this guide to get specific techniques on
approaching the different question types you may encounter.
Finally, some last words of advice. During your studies and practice test drills, concentrate on the process - not totally
on performance. What matters most is that you are using a disciplined approach that covers the materials on the
exam and you know what to expect on exam day. Stay the course of your study plan and you will be ready to PASS
THE EXAM!
5
Understanding Globalization
Support: Oracle 10g Administration II
6
Introducing Globalization Support

Scope
• Describe globalization support.
• Describe how to use National Language Support (NLS) parameters.
Focused Explanation
Overview of Globalization Support
In Oracle 10g, globalization support refers to a collection of features that enable you to store, retrieve,
and process data in multiple native languages in the same database instance. Globalization support
ensures that date, time, monetary, numeric, and calendar data formats follow the conventions specified in
a native language and locale. A locale is a linguistic environment in which a program is running.
Globalization support translates error messages and messages in database utilities into a native
language.
Features of Globalization Support
Globalization support helps develop multilingual applications and software products that you can access
from any region in the world. The following are the features of globalization support:
• Language support – Enables you to store, process, and retrieve data in native languages.
• Territory support – Enables you to follow the standard conventions to view default local time, date
formats, and numeric and monetary conventions according to different geographical locations.
• Linguistic sorting and searching – Enables you to use case conversion, sorting, and searching for
all languages supported by Oracle. Globalization support enables you to search and sort
character strings based on the rules of a language instead of the order in which characters are
encoded in a character set.
• Character set support – Enables you to use various single-byte, multibyte, and fixed-length
encoding schemes based on national, international, and vendor-specific standards. For example,
Unicode is a universal character set provided by Oracle 10g that supports all the known written
languages.
• Character semantics – Enables you to specify the storage requirements for multibyte strings with
varying widths, in terms of characters.
• Calendars – Enables you to use different calendar systems according to different geographic
locations. Oracle 10g supports seven different calendar systems, which include Gregorian, ROC
Official, Japanese Imperial, Persian, Thai Buddha, English Hijrah, and Arabic Hijrah.
• Calendar and locale data customization – Enables you to customize locale data, such as
character set, territory, and language. This feature also enables you to customize calendars using
the NLS Calendar Utility.
7
• Unicode support – Enables you to use Unicode characters in the following two ways:
o by creating a Unicode database, which enables you to store UTF-8 encoded characters
as the CHAR data type
o by using Unicode data types, such as NCHAR and NCLOB, to define the data types of the
columns of a table
• Date and time formats – Enables you to view dates and times in various formats, such as DD-
MON-YYYY and YYYY-MM-DD.
• Monetary and numeric formats – Enables you to view currency, credit, and debit symbols in
various formats.
Using NLS Parameters

You can use globalization support by setting the values of various NLS parameters. NLS parameters
determine the globalization support behavior on clients and server. You can specify NLS parameters at
the following levels:
• Specifying the initialization parameters in the initialization parameter file on a database server:
Specifies that the value of the specified NLS parameter will be applicable to all the sessions in the
current database instance. The value of an NLS parameter on a database server does not affect
the values of the NLS parameters on the clients.
• Specifying the environment variables on a client: Specifies that the value of the specified NLS
parameter will be applicable only to a client and will override the value of the NLS parameter in
the initialization parameter file.
• Using the ALTER SESSION statement: Specifies that the value of the NLS parameter will be
applicable to a session. The specified value will override the value of the NLS parameter set on a
client using the environment variable and the value of the NLS parameter specified in the
initialization parameter file.
• Using NLS parameters in SQL functions: Specifies that the value of an NLS parameter will be
applicable only to the current SQL function. The specified value will override the value of the NLS
parameter specified in the initialization parameter file, the value of the NLS parameter set using
the environment variable on a client, and the value of the NLS parameter specified using the
ALTER SESSION statement.
Specifying the Globalization Support Behavior
You can specify the globalization support behavior either by specifying the value of the NLS_LANG
parameter or by specifying the value of the different NLS parameters individually.
8
Using the NLS_LANG Parameter
NLS_LANG is an environment variable that defines the language, character set, and territory of a client.
You specify the NLS_LANG parameter in the format language_territory.charset. The format of the
NLS_LANG parameter contains the following three arguments:
• language – Specifies the language used to display Oracle messages, sorting, and month and
day names. The language argument specifies the default values of the charset and
territory arguments. The default value of the language argument is AMERICAN.
• territory – Specifies the conventions for the default date, monetary, and numeric formats. If
you do not specify the value of the territory argument, its default value is derived from the
language argument.
• charset – Specifies the character set, such as US7ASCII or JA16EUC, used by a client
application. If you do not specify the value of the charset argument, its default value is derived
from the language argument.
The following code fragments show how to specify the value of the NLS_LANG parameter:
• NLS_LANG=AMERICAN_AMRICA.US7ASCII
• NLS_LANG=JAPANESE_JAPAN.JA16EUC
• NLS_LANG=FRENCH_CANADA.WE8ISO8859P1
You can specify the value of the NLS_LANG parameter by setting it as an environment variable. For
example, use the following commands at the command prompt to specify the value of the NLS_LANG
parameter as FRENCH_FRANCE.WE8ISO8859P1:
SET NLS_LANG=FRENCH_FRANCE.WE8ISO8859P1
To analyze the effect of setting the value of the NLS_LANG parameter, type the following statement at the
SQL prompt to retrieve the data from the employee table, which stores the name, salary, and hire date of
the employees in the WonderWeb company:
SQL> SELECT name,sal,hire_date FROM employee;
9
This statement can produce the following output:
NAME SAL HIRE_DATE

---------- ---------- --------
John 1200,45 10/01/03
Smith 1400,67 10/03/05
The output of this statement shows that the date and number formats follow the conventions specified by
the NLS_LANG parameter. In this case, date is specified in the DD/MM/YY format in the HIRE_DATE
column.
You can also specify all the arguments of the NLS_LANG parameter individually, but you need to follow
the following conventions:
• The territory argument must be preceded by an underscore.
• The charset argument must be preceded by a period.
For example, to set the territory argument to AMERICA and the charset argument to
WE8ISO8859P1, insert the following code fragment in the initialization parameter file:
NLS_LANG=_AMERICA
NLS_LANG=.WE8ISO8859P1
Using Different NLS Parameters
The NLS parameters are placed into the following categories:
• Language and Territory parameters
• Date and Time parameters
• Calendar parameters
• Numeric and List parameters
• Monetary parameters
• Length Semantics parameters
10
Using Language and Territory Parameters
You can specify the language and territory of an Oracle database instance by using the NLS_LANGUAGE
and NLS_TERRITORY parameters. The NLS_LANGUAGE parameter specifies the default conventions used
to display the following characteristics:
• Language used to display the day and month names and their abbreviations
• Symbols used to display date and time attributes such as AM, PM, AD, and BC
• Language used to display database server messages
• Default sorting sequence for character data, when you specify the ORDER BY clause in SQL
statements
• Language used to display affirmative and negative response strings, such as YES and NO,
respectively
The NLS_TERRITORY parameter specifies the default conventions used to display the following
characteristics:
• Date format
• Decimal character
• Group separator
• ISO currency symbol
• Local currency symbol
• Dual currency symbol
• First day of the week
• Credit and debit symbols
• List separator
• ISO week flag
You can specify the values of the NLS_LANGUAGE and NLS_TERRITORY parameters on a database
server by specifying their values in the initialization parameter file. For example, to set the value of the
NLS_LANGUAGE parameter to FRENCH and the NLS_TERRITORY parameter to FRANCE, insert the
following code fragment into the initialization parameter file:
NLS_LANGUAGE=FRENCH
NLS_TERRITORY=FRANCE
11
To set the value of the NLS_LANGUAGE parameter for a client session to FRENCH, type the following
statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_LANGUAGE=FRENCH;
Similarly, to set the value of the NLS_TERRITORY parameter for a client session to FRANCE, type the
following statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_TERRITORY=FRANCE;
Using Date and Time Parameters
You can specify the date format using the NLS_DATE_FORMAT and NLS_DATE_LANGUAGE parameters.
You can specify the values of both of these parameters in the initialization parameter file on the database
server, as environment variables, or using the ALTER SESSION statement.
Using Date Parameters
The NLS_DATE_FORMAT parameter defines the default display format for dates. The value of the
NLS_DATE_FORMAT parameter can be a valid date format such as MM/DD/YYYY or DD-RM-YYYY. For
example, to set the value of the NLS_DATE_FORMAT parameter to DD-RM-YYYY on a database server,
insert the following code fragment in the initialization parameter file:
NLS_DATE_FORMAT=DD-RM-YYYY
When you insert this code fragment in the initialization parameter file, months are displayed in Roman
numerals. For example, after setting this parameter, type the following statement at the SQL prompt to
retrieve the current date:
SQL> SELECT TO_CHAR(SYSDATE) AS ROMAN_OUTPUT FROM DUAL;
The output of this SELECT statement would display the month in Roman numerals and the date format in
DD-RM-YYYY format, similar to the example below:
ROMAN_OUTPUT
------------
05-V -2005
To set the value of the NLS_DATE_FORMAT parameter as an environment variable, type the following
statements at the command prompt:
SET NLS_DATE_FORMAT='MM/DD/YYYY'
12
You can change the value of the NLS_DATE_FORMAT parameter for a session using the ALTER SESSION
statement. For example, to set the NLS_DATE_FORMAT parameter to DD/MM/YYYY, type the following
SQL> ALTER SESSION SET NLS_DATE_FORMAT='MM/DD/YYYY';
The NLS_DATE_LANGUAGE parameter defines the language used to display the month and day names.
You can specify the value of this parameter in SQL functions. This parameter overrides the value
specified in the NLS_LANGUAGE parameter. The value of the NLS_DATE_LANGUAGE parameter can be
any valid language. The NLS_DATE_LANGUAGE parameter specifies the conventions used to display the
following characteristics:
• month and day names and their abbreviations, displayed by the TO_CHAR and TO_DATE functions
• month and day abbreviations used by the default date format specified by the
NLS_DATE_FORMAT parameter
• abbreviations used to display date and time attributes such as AM, PM, AD, and BC
To set the value of the NLS_DATE_LANGUAGE parameter to ITALIAN on a database server, insert the
following code fragment in the initialization parameter file:
NLS_DATE_LANGAUGE=ITALIAN
To set the value of the NLS_DATE_LANGUAGE parameter as an environment variable, type the following
SET NLS_DATE_LANGUAGE=ITALIAN
To set the value of the NLS_DATE_LANGUAGE parameter to ITALIAN for a session, type the following
SQL> ALTER SESSION SET NLS_DATE_LANGUAGE=ITALIAN;
After executing the above ALTER SESSION statement, type the following statement at the SQL prompt to
view the current date:
SQL> SELECT TO_CHAR(SYSDATE,'Day:Dd Month YYYY') AS ITALIAN_DATE FROM DUAL;
In the output of the above statement, the current date is displayed in the Italian language and is in the
Day:Dd Month YYYY format, similar to the example below:
ITALIAN_DATE
---------------------------
Giovedi :05 Maggio 2005
13
When you specify the value of the NLS_DATE_LANGUAGE parameter in a SQL function, the scope of the
NLS_DATE_LANGUAGE parameter is limited to the SQL function only. For example, type the following
statement at the SQL prompt to view the current date in Italian in the DD/MON/YYYY format, with the
format only being modified for the scope of this SELECT statement:
SQL> SELECT TO_CHAR(SYSDATE,'DD/MON/YYYY','NLS_DATE_LANGUAGE=ITALIAN')

2 AS ITALIAN_OUTPUT FROM DUAL;
The above statement can produce the following output:
ITALIAN_OUTPUT
-----------
05/MAG/2005
Using Time Parameters
You can specify time formats using the NLS_TIMESTAMP_FORMAT and NLS_TIMESTAMP_TZ_FORMAT
parameters. The NLS_TIMESTAMP_FORMAT and NLS_TIMESTAMP_TZ_FORMAT parameters are used to
set the default format of the TIMESTAMP and TIMESTAMP WITH LOCAL TIME ZONE data types. You can
specify the values of both of these parameters in the initialization parameter file on a database server, as
environment variables, or using the ALTER SESSION statement.
To set the value of the NLS_TIMESTAMP_FORMAT parameter on a database server, insert the following
code fragment in the initialization parameter file:
NLS_TIMESTAMP_FORMAT='MM-YYYY-DD HH:MI:SS.FF'
To set the value of the NLS_TIMESTAMP_FORMAT parameter as an environment variable, type the
following statements at the command prompt:
SET NLS_TIMESTAMP_FORMAT='MM/YYYY/DD HH:MI:SS.FF'
To set the value of the NLS_TIMESTAMP_FORMAT parameter for a session, type the following statement
at the SQL prompt:
SQL> ALTER SESSION SET NLS_TIMESTAMP_FORMAT='MM/YYYY/DD HH:MI:SS.FF';
The NLS_TIMESTAMP_TZ_FORMAT parameter helps specify the time zone format. For example, to set the
value of the NLS_TIMESTAMP_TZ_FORMAT parameter on a database server, insert the following code in
the initialization parameter file:
NLS_TIMESTAMP_TZ_FORMAT='MM-YYYY-DD HH:MI:SS.FF TZH:TZM'
To set the value of the NLS_TIMESTAMP_TZ_FORMAT parameter as an environment variable, type the
SET NLS_TIMESTAMP_TZ_FORMAT='MM-YYYY-DD HH:MI:SS.FF TZH:TZM'
14
To set the value of the NLS_TIMESTAMP_TZ_FORMAT parameter for a session, type the following
SQL> ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT='MM/YYYY/DD HH:MI:SS.FF

TZH:TZM';
Using Calendar Parameter
You can use the NLS_CALENDAR parameter to specify the calendar used by Oracle 10g. The default
value of this parameter is Gregorian. You can specify the value of this parameter in the initialization
parameter file on a database server, as an environment variable, using the ALTER SESSION statement,
or in SQL functions.
To set the value of the NLS_CALENDAR parameter to Persian on a database server, insert the following
code fragment in the initialization parameter file:
NLS_CALENDAR=Persian
To set the value of the NLS_CALENDAR parameter as an environment variable, type the following
SET NLS_CALENDAR='Persian'
To set the value of the NLS_CALAENDAR parameter for a session, type the following statement at the SQL
prompt:
SQL> ALTER SESSION SET NLS_CALENDAR='Persian';
When you specify the value of the NLS_CALENDAR parameter in a SQL function, the scope of the
NLS_CALENDAR parameter is limited to the SQL function only. For example, type the following statement
at the SQL prompt to view the current date according to the Persian calendar:
SQL> SELECT TO_CHAR(SYSDATE,'DD/MON/YYYY','NLS_CALENDAR=Persian')

2 FROM DUAL;
Using Numeric and List Parameters
Numeric and list parameters define the number-formatting conventions used to display numbers. You can
specify the number-formatting conventions using the NLS_NUMERIC_CHARACTERS and
NLS_LIST_SEPARATOR parameters. The NLS_NUMERIC_CHARACTERS parameter defines the
conventions used to display decimal and group separator characters. The decimal character separates
the decimal and integer parts of a number. The group separator character separates integer groups in a
number to display the number segregated in units of thousands and millions.
You can specify a single-byte character as a decimal or group separator character. These two characters
must be different and must not be numeric characters. You cannot specify the +, -, <, or > symbol as a
decimal or group separator character. The decimal and group separator characters are represented by
the letters D and G, respectively. You can specify the value for the NLS_NUMERIC_CHARACTERS
15
parameter in the initialization parameter file on a database server, as an environment variable, using the
ALTER SESSION statement, or in SQL functions.
You must specify the decimal character before the group separator character. To set the value of the
NLS_NUMERIC_CHARACTERS parameter on a database server, insert the following code fragment in the
initialization parameter file:
NLS_NUMERIC_CHARACTERS=",."
This code fragment sets the comma (,) character as the decimal character and the period (.) character
as the group separator character.
To set the value of the NLS_NUMERIC_CHARACTERS parameter as an environment variable, type the
SET NLS_NUMERIC_CHARACTERS=",."
To set the value of the NLS_NUMERIC_CHARACTERS parameter for a session, type the following
SQL> ALTER SESSION SET NLS_NUMERIC_CHARACTERS=",.";
For example, to represent 6000 using the decimal and group separator defined by the value of
NLS_NUMERIC_CHARACTERS, type the following statement at the SQL prompt:
SQL> SELECT TO_CHAR(6000, '9G999D99') AS NLS_NUMERIC_OUTPUT FROM DUAL;
With the NLS_NUMERIC_CHARACTERS value of ",.", the above SELECT statement would produce the
following output:
NLS_NUMERIC_OUTPUT
---------
6.000,00
When you specify the value of the NLS_NUMERIC_CHARACTERS parameter in a SQL function, the scope
of the NLS_NUMERIC_CHARACTERS parameter is limited to the SQL function only. For example, type the
following statement at the SQL prompt to represent 6000 using a period as the decimal separator and a
comma as the group separator, but only for the scope of this SELECT statement:
SQL> SELECT TO_CHAR(6000,'9G999D99','NLS_NUMERIC_CHARACTERS=.,') AS

2 NLS_NUMERIC_OUTPUT FROM DUAL;
16
NLS_NUMERIC_OUTPUT
---------
6,000.00
The NLS_LIST_SEPARATOR parameter specifies the character used to separate numbers or characters
in a list of numbers or characters, respectively. For example, you can represent a list of numbers from 1
to 5 as 1,2,3,4,5 or 1.2.3.4.5. The default value of the NLS_LIST_SEPARATOR parameter is derived from
the NLS_TERRITORY parameter. You can specify a single-byte character as a list separator character.
This character cannot be the same as the numeric or monetary character. You cannot specify the +, -, <,
or > symbol as a list separator character. You can specify the value of the NLS_LIST_SEPARATOR
parameter only as an environment variable on a client.
Using Monetary Parameters
The NLS_CURRENCY and NLS_ISO_CURRENCY parameters are commonly used parameters to specify the
currency format for displaying currency. The NLS_CURRENCY parameter specifies the character string
displayed by the L format mask. You can specify the values of the NLS_CURRENCY parameter in the
initialization parameter file on a database server, as an environment variable, using the ALTER SESSION
statement, or in SQL functions.
To set the value of the NLS_CURRENCY parameter on a database server, insert the following code
fragment in the initialization parameter file:
NLS_CURRENCY=$
To set the value of the NLS_CURRENCY parameter as an environment variable, type the following
SET NLS_CURRENCY=$
To set the value of the NLS_CURRENCY parameter for a session, type the following statement at the SQL
prompt:
SQL> ALTER SESSION SET NLS_CURRENCY ='$';
After setting this parameter, you can represent 123.56 in the USD currency format by typing the following
SQL> SELECT TO_CHAR(123.56,'9G999G999D99L') AS USD_CURRENCY FROM DUAL;
17
USD_CURRENCY
-----------------------
123.56$
When you specify the value of the NLS_CURRENCY parameter in a SQL function, the scope of the
NLS_CURRENCY parameter is limited to the SQL function only. For example, type the following statement
at the SQL prompt to represent 123.56 in the USD currency format, but only for the scope of this SELECT
statement:
SQL> SELECT TO_CHAR(123.56,'9G999G999D99L','NLS_CURRENCY=$')

2 FROM DUAL;
The NLS_ISO_CURRENCY parameter specifies the ISO currency symbols, which define unique currency
symbols for various territories. The NLS_ISO_CURRENCY parameter specifies the character string
displayed by the C format mask and prevents ambiguity when using local currency symbols. For example,
a local currency symbol of $ is used to represent currency for both the Australian dollar and the American
dollar. However, the ISO currency symbol allows for each territory to have a unique representation. The
ISO currency symbol for the US dollar is USD and for the Australian dollar is AUD. You can specify the
value of the NLS_ISO_CURRENCY parameter in the initialization parameter file on a database server, as
an environment variable, using the ALTER SESSION statement, or in SQL functions.
To set the value of the NLS_ISO_CURRENCY parameter on a database server to FRANCE, insert the
following code fragment in the initialization parameter file:
NLS_ISO_CURRENCY=FRANCE
To set the value of the NLS_ISO_CURRENCY parameter as an environment variable, type the following
SET NLS_ISO_CURRENCY=FRANCE
To set the value of the NLS_ISO_CURRENCY parameter for a session, type the following statement at the
SQL prompt:
SQL> ALTER SESSION SET NLS_ISO_CURRENCY=FRANCE;
After executing this ALTER SESSION SET statement, you could represent 123.14 in the EUR currency
format by typing the following statement at the SQL prompt:
SQL> SELECT TO_CHAR(123.14,'9G999G999D99C') AS EUR_CURRENCY FROM DUAL;
18
The output of the above SELECT statement would be:
EUR_CURRENCY
--------------------
123.14EUR
When you specify the value of the NLS_ISO_CURRENCY parameter in a SQL function, the scope of the
NLS_ISO_CURRENCY parameter is limited to the SQL function only. For example, type the following
statement at the SQL prompt to represent 123.14 in the EUR currency format, but only for the scope of
this SELECT statement:
SQL> SELECT TO_CHAR(123.14,'9G999G999D99C', 'NLS_ISO_CURRENCY=FRANCE')

2 AS NLS_ISO_OUTPUT FROM DUAL;
NLS_ISO_OUTPUT
--------------------
123.14EUR
Using Length Semantics Parameters
The method of calculating the length of character strings in bytes is byte semantics. The method of
calculating the length of character strings in characters character semantics. These two methods are
collectively known as length semantics. A single-byte character set uses one byte to store one character
in memory. A multibyte character set, such as Unicode, may use one or more bytes to store one
character. The NLS_LENGTH_SEMANTICS parameter specifies the method used to calculate the length of
strings. If the database supports a multibyte character set, you need to specify the width of the character
data type columns to allow the maximum number of bytes to be stored by the character data type
columns. You can overcome this problem by setting the value of the NLS_LENGTH_SEMANTICS
parameter to CHAR. The default value of the NLS_LENGTH_SEMANTICS parameter is BYTE.
To set the value of the NLS_LENGTH_SEMANTICS parameter as an environment variable, type the
SET NLS_LENGTH_SEMANTICS=CHAR
To set the value of the NLS_LENGTH_SEMANTICS parameter for a session, using the ALTER SESSION
statement, type the following statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR;
19
You can also specify character semantics used to store a column when creating a table. To set the value
of the NLS_LENGTH_SEMANTICS parameter while creating a table, table1, type the following statement
at the SQL prompt:
SQL> CREATE TABLE table1(name VARCHAR2(25 CHAR));
The above statement creates a table, table1, which contains the name column with the VARCHAR2 data
type. The CHAR qualifier specifies that the character semantics store the name column.
If the database character set requires three bytes to store a single character, 25 characters can be stored
in the name column. If you set the value of the NLS_LENGTH_SEMANTICS parameter to BYTE, only eight
characters can be stored in the name column.
Note: The NCHAR, NVARCHAR2, CLOB, and NCLOB data type columns are always stored using character
semantics. The tables in the SYS and SYSTEM tablespaces are not affected by the value of the
NLS_LENGTH_SEMANTICS parameter.
Using NLS Views

The data dictionary stores information related to the NLS parameter settings. This information contains
the values of the NLS parameters at the session, instance, and database level. You can query the
following views to retrieve the information about NLS parameters:
• NLS_SESSION_PARAMETERS
• NLS_INSTANCE_PARAMETERS
• NLS_DATABASE_PARAMETERS
• V$NLS_VALID_VALUES
The NLS_SESSION_PARAMETERS View
The NLS_SESSION_PARAMETERS view displays the values of various NLS parameters for the current
session. To query the NLS_SESSION_PARAMETERS view and display the NLS parameters for the current
session, type the following statement at the SQL prompt:
SQL> SELECT * FROM NLS_SESSION_PARAMETERS;
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CALENDAR GREGORIAN
20
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
17 rows selected.
The NLS_INSTANCE_PARAMETERS View
The NLS_INSTANCE_PARAMETERS view displays the values of the NLS parameters for the current
database instance. These values are set explicitly either using the initialization parameters or the ALTER
SYSTEM statement. To query the NLS_INSTANCE_PARAMETERS view, type the following statement at the
SQL prompt:
SQL> SELECT * FROM NLS_INSTANCE_PARAMETERS;
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_SORT
NLS_DATE_LANGUAGE
NLS_DATE_FORMAT
NLS_CURRENCY
NLS_NUMERIC_CHARACTERS
NLS_ISO_CURRENCY
NLS_CALENDAR
NLS_TIME_FORMAT
NLS_TIMESTAMP_FORMAT
NLS_TIME_TZ_FORMAT
NLS_TIMESTAMP_TZ_FORMAT
NLS_DUAL_CURRENCY
NLS_COMP
17 rows selected.
21
The output shows the values of various NLS parameters for the current database instance. The NLS
parameters that are not explicitly displayed, derive their value from the higher-level parameters. For
example, the NLS_DATE_LANGUAGE and NLS_TIME_FORMAT parameters derive their values from the
NLS_TERRITORY parameter.
The NLS_DATABASE_PARAMETERS View
The NLS_DATABASE_PARAMETERS view displays the values of the NLS parameters for the database. To
query the NLS_DATABASE_PARAMETERS view and display the values of NLS parameters that were set at
the time the database was created using the CREATE DATABASE statement, type the following statement
at the SQL prompt:
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS;
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8MSWIN1252
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 10.1.0.2.0
20 rows selected.
22
The V$NLS_VALID_VALUES View
The V$NLS_VALID_VALUES dynamic view displays the values of the NLS_LANGUAGE, NLS_SORT,
NLS_TERRITORY, and NLS_CHARACTERSET parameters. To query the V$NLS_VALID_VALUES view to
display the values of NLS parameters for the German language, type the following statement at the SQL
prompt:
SQL> SELECT * FROM V$NLS_VALID_VALUES WHERE VALUE LIKE '%GER%';
Parameter value
---------------------------------------------------------------- ----------
LANGUAGE GERMAN
LANGUAGE GERMAN DIN
TERRITORY GERMANY
TERRITORY ALGERIA
SORT GERMAN
SORT XGERMAN
SORT GERMAN_DIN
SORT XGERMAN_DIN
23
Using Datetime Data Types

Scope
• Describe the DATE data type.
• Describe the TIMESTAMP data type.
• Describe the TIMESTAMP WITH TIME ZONE data type.
• Describe the TIMESTAMP WITH LOCAL TIME ZONE data type.
Focused Explanation
Introducing Datetime Data Types
Datetime data types in Oracle 10g help store date and time information about transactions across
databases. Oracle 10g provides the following datetime data types:
• DATE
• TIMESTAMP
• TIMESTAMP WITH TIME ZONE
• TIMESTAMP WITH LOCAL TIME ZONE
Using the DATE Data Type
The DATE data type stores date and time information related to an event such as the hire date of an
employee in a company. Oracle 10g stores century, year, month, date, hour, minute, and second using
the DATE data type. To create a table, employee, which stores the name and hire date of the employees
in the WonderWeb company, type the following statement at the SQL prompt:
SQL> CREATE TABLE employee(name VARCHAR2(10), hire_date DATE);
You can specify the value of a column of the DATE data type by using literals or the TO_DATE function.
When you insert values into DATE data type columns using literals, you can insert values either using the
format specified in the NLS_DATE_FORMAT parameter or using an ANSI literal.
For example, if the value of the NLS_DATE_FORMAT parameter is MM-DD-YYYY, type the following
statement at the SQL prompt to insert a row into the employee table:
SQL> INSERT INTO employee VALUES('John','12-14-2005');
An ANSI date literal does not contain a time element. The format of an ANSI date literal is DATE 'YYYY-
MM-DD'. To insert a row into the employee table using an ANSI date literal, type the following statement
at the SQL prompt:
SQL> INSERT INTO employee VALUES('Salan', DATE '2005-10-09');
24
The TO_DATE function converts a text string to a DATE data type based on the format specified in the
argument passed to the TO_DATE function. For example, to insert a row into the employee table using
the TO_DATE function, type the following statement at the SQL prompt:
SQL> INSERT INTO employee VALUES('Smith',TO_DATE('03-Jan-2005 12:45','DD-MM-

YYYY HH24:MI'));
The above statement inserts the date as well as time information into the hire_date column. If you do
not specify the time when inserting a value into the hire_date column, the midnight time, 00:00 is
stored as the default time in the hire_date column. If you do not specify a date when inserting values
into a DATE data type column, the DATE data type column accepts the default date, which is the first day
of the current month.
Using the TIMESTAMP Data Type
The TIMESTAMP data type stores fractional seconds, in addition to the information stored by the DATE
data type. By default, the TIMESTAMP data type stores fractional seconds up to six digits of precision.
You can change the precision by specifying a number between 0 and 9 in parentheses after the
TIMESTAMP keyword. To create a table, migration, which stores the names of employees and the
immigration date of the employees in the WonderWeb company, type the following statement at the SQL
prompt:
SQL> CREATE TABLE migration(name VARCHAR2(10), mgrdate TIMESTAMP(4));
You can insert values into a TIMESTAMP data type column using the TO_TIMESTAMP function. To insert
values into the migration table, type the following statement at the SQL prompt:
SQL> INSERT INTO migration VALUES('John', TO_TIMESTAMP('01-JAN-2005

15:45:24:12', 'DD-MON-YYYY HH24:MI:SS:FF'));
Alternatively, you can insert values into a TIMESTAMP data type column using the value of the
NLS_TIMESTAMP_FORMAT parameter for a session. For example, if the value of the
NLS_TIMESTAMP_FORMAT parameter is set to DD-MON-YY HH:MI:SSXFF, type the following statement
at the SQL prompt to insert the values into the migration table:
SQL> INSERT INTO migration VALUES('John','01-FEB-2005 15:45:24');
Type the following statement at the SQL prompt to retrieve all the rows from the migration table:
SQL> SELECT * FROM migration;
NAME MGRDATE
---------------------------------------------------------------------------
John 01-JAN-05 03.45.24.1200 PM
25
Using the TIMESTAMP WITH TIME ZONE Data Type
The TIMESTAMP WITH TIME ZONE data type stores time zone offset or time zone region name in addition
to the information stored by the TIMESTAMP data type. Time zone offset specifies the difference between
the local time and Coordinated Universal Time (UTC) in hours and minutes. To create a table, bank,
which stores the names of customers of a bank and the time at which the customers of the bank make
transactions, type the following statement at the SQL prompt.
SQL> CREATE TABLE bank(name VARCHAR2(10),stamp TIMESTAMP WITH TIME ZONE);
You can insert values into a TIMESTAMP WITH TIME ZONE data type column in the format that is
specified in the NLS_TIMESTAMP_TZ_FORMAT parameter. To set the value of the
NLS_TIMESTAMP_TZ_FORMAT parameter for a session, type the following statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT='MON-DD-RR HH:MI:SSXFF AM TZR';
You must also set the value of the TIME_ZONE parameter before inserting values in a TIMESTAMP WITH
TIME ZONE data type column. To set the value of the TIME_ZONE parameter, type the following
SQL> ALTER SESSION SET TIME_ZONE='-8:00';
To insert values into the bank table, type the following statement at the SQL prompt:
SQL> INSERT INTO bank VALUES('John','JAN-03-2005 2:00:00 AM');
Type the following statement at the SQL prompt to retrieve the time at which John made a transaction
from the bank table:
SQL> SELECT stamp FROM bank WHERE NAME='John';
STAMP
---------------------------------------------------------------------------
JAN-03-05 02:00:00.000000 AM -08:00
26
Using the TIMESTAMP WITH LOCAL TIME ZONE Data Type
The TIMESTAMP WITH LOCAL TIME ZONE data type stores the same information as the TIMESTAMP
WITH TIME ZONE data type. The data you store in a TIMESTAMP WITH LOCAL TIME ZONE data type
column is normalized to the database time zone. The time zone part of data is not stored as a part of the
column data. When you retrieve data from a TIMESTAMP WITH LOCAL TIME ZONE data type column,
Oracle returns the local session time zone of the Oracle user. You must use a TIMESTAMP WITH LOCAL
TIME ZONE data type column, when original time zone of a location is not important. To create a table,
localtime, which stores the name of customers of a bank and the time at which the customers of the
bank make transactions, contains a TIMESTAMP WITH LOCAL TIME ZONE data type column, type the
SQL> CREATE TABLE localtime(name VARCHAR2(10), trans_time TIMESTAMP(8) WITH

LOCAL TIME ZONE);
You can insert values into a TIMESTAMP WITH LOCAL TIME ZONE data type column using the
TIMESTAMP WITH TIME ZONE literal. To insert the values in the localtime table, type the following
SQL> INSERT INTO localtime VALUES('Salan',TIMESTAMP '2005-03-05 2:00:00');
Type the following statement at the SQL prompt to retrieve the time, from the localtime table, at which
Salan made a transaction:
SQL> SELECT trans_time FROM localtime WHERE name='Salan';
TRANS_TIME--------------------------------------------------------------------
-------
05-MAR-05 02.00.00.00000000 AM
27
Using Linguistic Sorts and Searches

Scope
• Describe linguistic sorts.
• Describe types of linguistic sorts.
• Describe linguistic sort parameters.
• Describe case-insensitive and accent-insensitive linguistic searches.
Focused Explanation
Different languages use different rules, known as sort orders, when sorting character data. Sort order can
be case-sensitive or case-insensitive. Sort order can also be diacritic-sensitive or diacritic-insensitive
searches. A diacritic is a combination of characters or a symbol through or near a character, which
indicates a different sound than the sound of the character without the diacritic. A diacritic of a character
is also known as the accent of a character. To support different sorting rules, Oracle provides two types of
sorting, binary and linguistic. Binary sorts sort character data based on the encoded value of the
characters in a character set. Binary sorts cannot sort character data in Asian languages. Linguistic sorts
sort character data based on the rules of specific languages.
Introduction to Linguistic Sorts
Linguistic sorts sort character data irrespective of the numeric value of the characters in a character set.
The following are the various features of linguistic sorts:
• Base letters – Are the individual letters upon which other characters are based. The base letter
table maps each letter in a language to its base letter. For example, a, A, and ä are mapped to
the same base letter, a.
• Ignorable characters – Are characters that can be ignored when sorting character data using
linguistic sorts. For example, the – character is an ignorable character. For example, the word e-
mail is same as email when sorting because the – character is ignored.
• Contracting characters – Represent two or more characters that are treated as a single character
when sorting character data using linguistic sorts. For example, in Spanish the ch string is a
contracting character and is treated as a single character when sorting data using linguistic sorts.
• Expanding characters – Represent characters that must be sorted as character strings. For
example, in German, ß is sorted as the string, SS.
• Context-sensitive characters – Represent characters that affect the sorting order based on their
relationship with other characters in the character strings being sorted. For example, in Japanese,
a length mark, -, affects the sorting order. The sorting order depends on the vowel that precedes
a length mark. For example, in Japanese, if the – length mark is inserted after the character ki,
28
the – length mark is treated as the character i. If the – length mark is inserted after the character
ka, the – length mark is treated as the character a.
• Canonical equivalence – Specifies that some characters and character strings in a Unicode
character set are considered to be equivalent when sorting. For example, the character ö and the
string ő represent canonical equivalence.
• Reverse secondary strings – Specifies that the character strings containing diacritics are sorted
first from left to right on the basis of base characters, and then from right to left on the basis of
diacritics. For example, the word, résume, appears before the word, resumé. Both of these
words are same on the basis of base characters. When these words are compared on the basis
of diacritics, résume appears before resumé because the minor value of the é character is
greater than the minor value of the letter e.
• Character rearrangement – Specifies that some characters in Thai and Lao languages must
switch places with the following characters before sorting. For example, when there are two
characters in character data representing vowel sounds, and the second character is a
consonant, the character representing the vowel sound is replaced with the consonant.
Types of Linguistic Sorts
The sorting method followed by Oracle when sorting character data depends on the number of languages
used. Oracle 10g provides the following types of linguistic sorts:
• Monolingual linguistic sorts – Enable you to sort character strings in which characters belong to a
single language.
• Multilingual linguistic sorts – Enable you to sort character strings in which characters belong to
more than on language.
When Oracle sorts character strings in a single language, a two-step process is followed to sort the
character strings. In the first step, Oracle compares major values of the character strings. In the second
step, the minor values of the character strings are compared. The major and minor values of characters
are defined by Oracle. The letters with the same appearance are assigned the same major values, but
different minor values. For example, the major value of the letters a, A, and Ä is 15, but the minor values
of these letters are 5, 10, and 20, respectively. When major values of the characters in the character
strings to be sorted are the same, the minor values of the characters determine the sort order. The major
and minor values of characters are stored in the major and minor tables, respectively.
Multilingual linguistic sorts in Oracle 10g help you to sort data in more than one language in one sorting
operation. For example, if a table stores the names of employees in both the English and Spanish
languages, you can use multilingual sorts to sort the names in the table. Oracle 10g sorts multilingual
data at three levels: primary, secondary, and tertiary.
Primary level sorting sorts character strings based on the values assigned to the base letters in the
character strings. The primary level sort ignores the diacritic and case of the characters in the character
strings to be sorted. The ignorable characters are also ignored in the primary level sort and assigned a
29
primary level weight of zero. For example, at the primary level, the characters strings, resume and
Resume are the same.
Secondary level sorting first sorts character strings based on the values assigned to base letters and then
on the basis of diacritics. For example, the letter á has the same value as the letter A when sorted at the
primary level. At the secondary level, both the characters are different because they have different
diacritics.
Tertiary level sorting sorts the character strings first on the base letters, next on the basis of diacritics, and
then on the basis of casing of characters in the character strings to be sorted. For example, the letters a
and A are the same at primary and secondary sorting levels but differ at the tertiary level because the
casing of the letters is different.
Using Linguistic Sort Parameters
Oracle 10g provides two parameters, NLS_SORT and NLS_COMP, to specify the characteristics of sorting.
The NLS_SORT parameter specifies the type of sorting, such as binary or linguistic, to be used for sorting
operations in SQL statements. The default value of the NLS_SORT parameter is derived from the value of
the NLS_LANGUAGE parameter. For example, if the value of the NLS_LANGUAGE parameter is AMERICAN,
the default value of the NLS_SORT parameter is BINARY, which specifies that the character data will be
sorted by using a binary sort. The value of the NLS_SORT parameter affects various SQL clauses
including WHERE, START WITH, IN/OUT, BETWEEN, CASE WHEN, HAVING, and ORDER BY. You need to
use the NLSSORT function to compare character data in a SQL statement, in which the WHERE clause is
specified.
You can specify the values of the NLS_SORT parameter as the initialization parameter file, as an
environment variable, as the ALTER SESSION statement, or as an SQL function. The syntax to specify
the value of the NLS_SORT parameter is as follows:
NLS_SORT=BINARY|sort_name
In the above syntax, sort_name specifies the name of the sort to be used when sorting character data.
To set the value of the NLS_SORT parameter to GERMAN for a session using the ALTER SYSTEM
statement, type the following statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_SORT=GERMAN;
You can use the NLS_COMP parameter to avoid the use of the NLSSORT function in SQL statements when
you want to compare character strings using the linguistic comparison instead of the binary comparison.
The NLS_COMP parameter works in conjunction with the NLS_SORT parameter. If you set the value of the
NLS_COMP parameter to ANSI, the clauses that use linguistic sorting are ORDER BY, BETWEEN, CASE
WHEN, HAVING, IN/OUT, START WITH, and WHERE.
30
You can specify the values of the NLS_COMP parameter as the initialization parameter file, as an
environment variable, or as the ALTER SESSION statement. To set the value of the NLS_COMP parameter
for a session, type the following statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_COMP=ANSI;
Case-Insensitive and Accent-Insensitive Linguistic Searches
Oracle 10g supports case-insensitive and accent-insensitive linguistic searches when sorting multilingual
character strings. You must set the value of the NLS_COMP parameter to ANSI to perform case-insensitive
and accent-insensitive linguistic searching. To set the value of the NLS_COMP parameter to ANSI for a
session, type the following statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_COMP=ANSI;
To specify case-insensitive linguistic searching, you must set the value of the NLS_SORT parameter to
searchname_CI value, where searchname specifies the linguistic searching method. For example, to
set the value of the NLS_SORT parameter to GERMAN_DIN_CI for specifying the multilingual searching
method, type the following statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_SORT=GERMAN_DIN_CI;
For example, a table, sort_test contains the following values in the name column:
Grünhornlücke
grünhornlücke
Finsterhutte
finsterhttüe
Issue the following statement at the SQL prompt to search values in the sort_test table using case-
insensitive multilingual searching:
SQL> SELECT * FROM sort_test WHERE name='Grünhornlücke';
Grünhornlücke
grünhornlücke
In the output, the casing of letters is ignored.
To specify accent-insensitive linguistic searching, you must set the value of the NLS_SORT parameter to
searchname_AI value, where searchname specifies the linguistic searching method. For example, to
set the value of the NLS_SORT parameter to GERMAN_DIN_AI for specifying the multilingual searching
method, type the following statement at the SQL prompt:
SQL> ALTER SESSION SET NLS_SORT=GERMAN_DIN_AI;
31
Issue the following statement at the SQL prompt to search values in the sort_test table using accent-
insensitive multilingual searching:
SQL> SELECT * FROM sort_test WHERE name='Finsterhutte';
Finsterhutte
finsterhttüe
In the output, the casing as well as accent of letters is ignored.
32
Review Checklist: Understanding Globalization Support: Oracle 10g

Administration II
Describe globalization support.
Describe how to use National Language Support (NLS) parameters.
Describe the DATE data type.
Describe the TIMESTAMP data type.
Describe the TIMESTAMP WITH TIME ZONE data type.
Describe the TIMESTAMP WITH LOCAL TIME ZONE data type.
Describe linguistic sorts.
Describe types of linguistic sorts.
Describe linguistic sort parameters.
Describe case-insensitive and accent-insensitive linguistic searches.
33
Configuring and Using Recovery

Manager: Oracle 10g Administration II
34
Configuring Recovery Manager

Scope
• Introduce Recovery Manager (RMAN).
• Describe how to start RMAN and connect to a target database using RMAN.
• Describe channel allocation methods.
• Learn how to configure persistent settings for RMAN.
• Describe how to configure default settings for RMAN.
• Learn how to configure retention policy.
• Describe how to configure control file autobackups.
Focused Explanation
Introducing RMAN
RMAN is a command-line and Enterprise Manager-based tool that helps to back up and recover Oracle
databases. When you start RMAN, the RMAN environment is started. This environment contains utilities
and databases to perform backup and recovery. The RMAN environment contains at least two
components:
• Target database – Specifies the database that is being backed up and/or recovered using RMAN.
• RMAN client – Is a command-line database client that enables you to issue SQL statements and
commands to back up and recover databases.
The RMAN environment may also contain the following components:
• RMAN repository – Stores metadata and information about the backup and recovery of a target
database. The RMAN repository data is stored in a control file of the target database. The
CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the time period for
which the information about the database backups is retained in the RMAN repository.
• Flash recovery area – Manages disk space and files related to database backup and recovery.
You can specify the location of the flash recovery area by using the DB_RECOVERY_FILE_DEST
initialization parameter.
• Recovery catalog – Stores the RMAN-stored scripts. The scripts are sequences of RMAN
commands used for backup and recovery. The information in the recovery catalog is stored in the
form of tables.
• Media managers – Control sequential media devices, such as tapes, during the backup and
recovery of a database.
35
Storing RMAN Repository Data
You can store RMAN repository data in the control file of a target database and in an optional recovery
catalog. The data in the control file of the target database is stored in two reusable sections: circular
reuse records and noncircular reuse records. Circular reuse records store noncritical information that can
be overwritten. Noncircular reuse records contain datafiles and redo log files. A recovery catalog provides
more space to store information about backup and recovery than the control file of the target database. A
recovery catalog can support multiple Oracle databases simultaneously. To use a recovery catalog, you
must be granted the CONNECT and RESOURCE privileges and the RECOVERY_CATALOG_OWNER role.
Starting RMAN and Connecting to a Target Database

You can start RMAN by running the rman command. You can start RMAN with or without connecting to a
database. You can connect to three types of databases when starting RMAN: target, recovery catalog,
and auxiliary.
Starting RMAN Without Connecting to a Target Database
To start RMAN without connecting to a database, run the following command at the command prompt:
rman
After RMAN is started, the RMAN prompt is displayed.
Connecting to a Target Database
You can connect to a target database with or without connecting to a recovery catalog. You can connect
either from the command prompt or from the RMAN prompt.
Connecting to a Target Database Without Connecting to a Recovery Catalog
To start RMAN and connect to a target database from the command prompt without connecting to a
recovery catalog, run the following command at the command prompt:
rman TARGET / NOCATALOG
Alternatively, you can connect to a target database when starting RMAN, without connecting to a
recovery catalog. This can be done by running the following command at the command prompt:
rman TARGET /
To connect to a target database from the RMAN prompt without connecting to a recovery catalog, first
start RMAN by running the following command at the command prompt:
rman NOCATALOG
After starting RMAN, connect to the target database by running the following command at the RMAN
prompt:
RMAN> CONNECT TARGET
36
Connecting to a Target Database and Recovery Catalog
You can connect to both a target database and a recovery catalog, either from the command prompt or
the RMAN prompt. The following is the syntax to connect to a target database and a recovery catalog
from the command prompt:
rman TARGET / CATALOG user_name/password@service_name
In the above syntax:
• user_name – Specifies the name of the owner of a recovery catalog.
• password – Specifies the password that is required to access a recovery catalog.
• service_name – Specifies the name of the net service that is used to access a recovery
catalog.
To connect to a target database and a recovery catalog from the RMAN prompt, you must start RMAN by
running the rman command at the command prompt. After starting RMAN, run the following command at
the RMAN prompt to connect to the target database:
RMAN> CONNECT TARGET
The syntax to connect to a recovery catalog from the RMAN prompt is as follows:
CONNECT TARGET user_name/password@service_name
Allocating Channels
A channel is a connection to a server session on a target database. A server session is used to back up,
restore, and recover a database. At least one channel must be allocated to back up or recover a
database. Allocating a channel enables you to use RMAN to back up a target database. Channels can be
allocated manually or automatically. You can manually allocate channels for a RMAN session by running
the ALLOCATE CHANNEL command within a RUN block. When you allocate channels manually, you must
specify the type of I/O device that a server session will use to back up, restore, or recover a database.
The following is the syntax to allocate a channel manually:
RUN
{
ALLOCATE CHANNEL channel_name DEVICE TYPE sbt|DISK;
}
In the above syntax:
• channel_name – Specifies the name of the channel to be allocated.
• sbt – Indicates that the I/O device used to back up, restore or recover a database is a tape.
• DISK – Indicates that the I/O device used to back up, restore, or recover a database is a disk.
37
Automatic channel allocation helps to preconfigure channels for all the RMAN sessions. You can
automatically allocate channels to a disk or a tape by using the CONFIGURE CHANNEL command. By
default, a disk channel is preconfigured to back up and recover a database to a disk. The channel
allocated using the CONFIGURE CHANNEL command overrides a preconfigured channel. If you do not run
the ALLOCATE CHANNEL command, RMAN allocates channels according to the values of the parameters
in the following CONFIGURE commands:
• CONFIGURE DEFAULT DEVICE TYPE – Enables you to specify a default device, such as a
disk or a tape that is used to store database backups.
• CONFIGURE CHANNEL n DEVICE TYPE – Enables you to specify a channel for a specific
device. The n parameter is an integer that specifies the number of the channel that is used to
create a database backup. The value of n can range from 1 to 255.
• CONFIGURE CHANNEL DEVICE TYPE – Enables you to specify a device, such as a disk or a
tape, to store database backups.
• CONFIGURE DEVICE TYPE ... PARALLELISM – Enables you to specify the number of
channels that RMAN uses for a specified device type.
Configuring Persistent Settings for RMAN

Persistent settings are permanent settings that apply to all the RMAN commands and are not modified
when you restart RMAN. You must configure the following persistent settings for RMAN:
• disks
• tapes
• retention policy
• control file backups
Configuring Disks
By default, RMAN stores database backups on disk. If the flash recovery area on a disk is configured, it is
used as the default destination to store database backups. You must run the CONFIGURE CHANNEL
command to use the flash recovery area as the default destination for storing database backups. Run the
following command at the RMAN prompt to use the flash recovery area as the default destination:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT CLEAR;
If the flash recovery area is not configured, you can use a directory to store database backups. To store
database backups to a directory, /ora1/temp, run the following command at the RMAN prompt:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT 'ora1/temp/%U';
In the above command, %U is a format specifier that is replaced by file names that are generated by the
operating system. The files for which names are generated are used to store database backups.
38
Configuring Tapes
You can also configure tapes to store database backups. To configure tapes as the destination to store
database backups, run the following command at the RMAN prompt:
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=mml_env_settings';
To create backups of multiple databases, you can also configure multiple channels for tapes
simultaneously. For example, to allocate three channels to create backups of three databases
simultaneously, run the following command at the RMAN prompt:
RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
Configuring Retention Policy
Retention policy determines the time for which database backups are retained in the destination and are
available for recovery. You can specify the retention policy by specifying the recovery window, which
determines the retention period to retain the database backup. Retention period specifies the time period
up to which you can recover a database using the database backup. For example, if you want to limit the
retention period to five days, run the following command at the RMAN prompt:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAYS;
RMAN does not delete the backups made obsolete by recovery window. The obsolete backups are
marked OBSOLETE.
You can also specify the retention policy in terms of a redundancy value. This value determines the
number of backups or copies of a database that should be retained and available to recover the
database. You can specify the redundancy value by using the REDUNDANCY clause in the CONFIGURE
RETENTION POLICY command. For example, to retain five backups or copies of a database, run the
following command at the RMAN prompt:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 5;
Configuring Control File Autobackups
You can configure RMAN to automatically back up a control file after each backup operation. The process
of configuring RMAN to back up a control file automatically is called control file autobackup. RMAN can
recover a database from the backup of a control file if the control file is lost or corrupted. To configure
RMAN to automatically back up the control file, run the following command at the RMAN prompt:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
39
By default, RMAN generates names for the autobackup files of a control file and stores them in the flash
recovery area. You can also configure RMAN to generate names of autobackup files in a specific format,
and store these files in a specific location. For example, to store autobackup files in the \tmp directory,
run the following command at the command prompt:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO

'\tmp\cf%F';
In the above command, the format string, cf%F, generates a unique name for the file, in which the
backup of the control file will be stored.
Configuring Default Settings for RMAN

Default settings for RMAN include settings related to default devices, such as disk or tape, to store
database backups. Default settings also specify the backup type, such as backup set or image copy, for
database backups. You can configure the default device where RMAN will store database backups by
running the CONFIGURE DEFAULT DEVICE TYPE command. To configure a disk as the default device
type, run the following command at the RMAN prompt:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
To configure a tape as the default device type, run the following command at the RMAN prompt:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
You can also configure the default backup type for a disk or a tape. To configure an image copy as the
default backup type for a disk, run the following command at the RMAN prompt:
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
To configure a backup set as the default backup type for a disk, run the following command at the RMAN
prompt:
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUP SET;
To configure an image copy as the default backup type for a tape, run the following command at the
RMAN prompt:
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COPY;
To configure a backup set as the default backup type for a tape, run the following command at the RMAN
prompt:
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUP SET;
40
Using Recovery Manager

Scope
• Describe methods to create backup sets and image copies.
• Describe methods to create compressed backup sets.
• Learn how to create incremental backups.
• Describe how to enable block change tracking.
• Describe various backup options.
• Learn how to monitor backups by using the LIST and REPORT commands.
Focused Explanation
RMAN backs up all the datafiles required to recover a database. The following are the various types of
files that RMAN can back up:
• archived redo logs
• control files
• datafiles and their image copies
• the current server parameter file
• backup pieces containing backups created by RMAN, which are operating system files that
contain backed up datafiles, control files or archived redo logs
Creating Backup Sets and Image Copies

You can store RMAN backups in two formats, backup sets and image copies. A backup set consists of
one or more backup pieces. By default, a single backup piece is stored in a single backup set. An image
copy is an image of a single control file, datafile, or the archived log file that you can use for recovery.
Backup sets are stored in an RMAN-specific format, while image copies are not stored in the RMAN-
specific format. As a result, you do not need to use RMAN to recover a database from an image copy.
However, you do need RMAN to recover a database from a backup set.
Creating Backup Sets
You can create backups sets by running the RMAN BACKUP command. To create backup sets, run the
following RMAN script at the RMAN prompt:
RMAN> RUN
{
ALLOCATE CHANNEL c1 TYPE DISK;
BACKUP DATABASE FORMAT 'db_%u_%d_%s;
41
BACK FORMAT 'log_t%t_s%s_p%p'

(ARCHIEVELOG ALL);
}
Creating Compressed Backup Sets
In order to reduce disk space required to create backups, RMAN provides binary compression for backup
sets. You must set the value of the COMPATIBLE initialization parameter to 10.0.0.0.0 or 10.1.0.2.0
in order to create compressed backup sets. The COMPATIBLE initialization parameter enables you to use
the new version of Oracle and maintain backward-compatibility with the earlier versions installed on your
computer, simultaneously. You can use the AS COMPRESSED BACKUPSET option with the BACKUP
RMAN command to create compressed backup sets.
You should use compressed backup sets in the following situations:
• when creating disk-based backups with limited disk space
• when creating backup sets across a network with limited network bandwidth
• when creating backup sets to tapes, CDs or DVDs in situations where hardware compression is
unavailable
For example, to create a compressed backup set of a database, run the following command at the RMAN
prompt:
RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE;
Creating Image Copies
You can create an image copy of a database by using the RMAN BACKUP AS COPY command. To create
an image copy of a database, you must configure the default backup type for a disk as image copy. To
create the image copy of an entire database, run the following RMAN script at the RMAN prompt:
RMAN> BACKUP AS COPY;
Creating Incremental Backups

Incremental backups back up only those data blocks that have been modified since the last backup.
RMAN can create incremental backups of tablespaces, datafiles, and entire databases. Incremental
backups have the following advantages over full backups:
• When backing up data over a network, incremental backups use less network bandwidth than full
backups.
• Incremental backups occupy less space than full backups because with an incremental backup
only the modified data blocks are backed up.
RMAN can create incremental backups at two levels, 0 and 1. The Level 0 backup acts as a base for
subsequent incremental backups and backs up all the data blocks containing data. The Level 1 backup
42
backs up only those data blocks that have been modified since the last backup. A Level 1 backup can be
one of two types: a differential backup or a cumulative backup. A differential backup backs up only those
data blocks that have been modified since the last incremental backup, irrespective of the level of backup.
A cumulative backup backs up all the data blocks that have been modified since the last incremental
backup at level 0.
Enabling Block Change Tracking
You can enable block change tracking to create incremental backups. Block change tracking stores
information about the database blocks modified since the last backup. This information is stored in the
change tracking file. RMAN uses this information to create incremental backups. By default, block change
tracking is disabled. You can enable block change tracking by using the ALTER DATABASE statement. To
enable block change tracking and use the /oradata/change01.LOG file to record the changes, type
the following statement at the SQL prompt:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE

2 '/oradata/change01.LOG';
You can view the current location, status, and number of bytes used by the change tracking file by
querying the V$BLOCK_CHANGE_TRACKING view. To query this view, type the following statement at the
SQL prompt:
SQL> SELECT * FROM

2 FROM V$BLOCK_CHANGE_TRACKING;
The output of the above statement might be:
STATUS FILENAME BYTES

------------------------------------------------------
ENABLED C:\oradata\change01.LOG 1156782345
Creating Differential Incremental Backups
You can create differential incremental backups by using the RMAN BACKUP INCREMENTAL command.
To create a differential incremental backup at level 0, run the following command at the RMAN prompt:
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
To create a differential incremental backup at level 1, run the following command at the RMAN prompt:
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
Note: You cannot create a differential incremental backup at level 1 directly. First, you must create a
differential incremental backup at level 0.
43
Creating Cumulative Incremental Backups
You can create cumulative incremental backups by using the RMAN BACKUP INCREMENTAL command.
To create a cumulative incremental backup, run the following command at the RMAN prompt:
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
Backup Options
You can provide various options, such as FORMAT and RATE, with the RMAN commands used to back up
databases. These options help you to control:
• the names of files in which backed up databases are stored.
• the backup performance.
• the size of the backups.
The following are the common options used with the RMAN commands:
• FORMAT – Used to specify the name of the files in which you want to store the database backups.
The most common FORMAT options are as follows:
o %d – Specifies the name of a database.
o %M – Specifies the month, in which a database backup is created, in the MM format, in the
Gregorian calendar.
o %N – Specifies the name of the tablespace that is currently being backed up.
o %t – Specifies a backup set timestamp.
o %T – Specifies the year, month and day in the Gregorian calendar when a database
backup is created.
o %U – Specifies the operating system-generated unique name for the file that will store the
backup.
o %p – Specifies the number of backup pieces in a backup set.
• RATE – Prevents RMAN from using all the resources of a database server during backup.
• MAXSETSIZE – Controls the size of the files that can be backed up per backup set.
• MAXPIECESIZE – Controls the size of a backup piece in a backup set that is to be backed up.
44
Monitoring Backups
You can use the RMAN LIST and REPORT commands to query and retrieve information about the
database backups that are stored in the RMAN repository.
Using the LIST Command
The LIST command provides two options to view information about the database backups: LIST BACKUP
and LIST COPY. The LIST BACKUP command provides information about the database backups. The
LIST COPY command provides information about the datafile copies listed in the RMAN repository. The
following are the commonly used options for the LIST BACKUP command:
• BY FILE – Specifies that the output of the LIST BACKUP command is arranged according to
the files in the backup sets. To arrange the output according to the files in the backup sets, run
the following command at the RMAN prompt:
RMAN> LIST BACKUP BY FILE;
The above command can produce the following output:
List of Controlfile Backups

===========================
CF Ckp SCN Ckp Time BS Key S #Pieces #Copies Compressed Tag

---------- --------- ------- - ------- ------- ---------- ---
791388 13-MAY-05 1 A 1 1 NO
TAG20050513T170124
List of SPFILE Backups

======================
Modification Time BS Key S #Pieces #Copies Compressed Tag

----------------- ------- - ------- ------- ---------- ---
06-MAY-05 1 A 1 1 NO
TAG20050513T170124
The output shows the information about the backups of control files and SPFILE arranged
according to files in the backup set.
• BY BACKUP – Specifies that the output of the LIST BACKUP command is arranged according to
the backup sets. To arrange the output according to backup sets, run the following command at
the RMAN prompt:
RMAN> LIST BACKUP OF DATABASE BY BACKUP;
• SUMMARY – Specifies that the output of the LIST BACKUP command is in the summarized form.
Run the following command at the RMAN prompt to view the summarized output of the LIST
BACKUP command:
RMAN> LIST BACKUPSET BY BACKUP SUMMARY;
45
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed
Tag
------- -- -- - ----------- --------------- ------- ------- ----------
---
1 B F A DISK 13-MAY-05 1 1 NO
TAG200505
13T170124
The output shows the information about the database backup in the summarized form.
The following are the commonly used options for the LIST BACKUP and LIST COPY commands:
• EXPIRED – Displays the names of inaccessible files, based on the output of the CROSSCHECK
command. The CROSSCHECK command determines whether the files managed by RMAN, such
as datafile copies, archived redo logs, and backup pieces, still exist on disks or tapes. To
display the names of inaccessible files, run the following command at the RMAN prompt:
RMAN> LIST EXPIRED COPY;
• RECOVERABLE – Displays the datafile backups or datafile copies in the current database
incarnation that you can restore and recover. A database incarnation is a version of a database
that is created when you open the database with the RESETLOGS option. To display the datafile
backups or datafile copies in the current database incarnation, run the following command at
the RMAN prompt:
RMAN> LIST BACKUP RECOVERABLE;
List of Backup Sets

===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ---------------
1 Full 2M DISK 00:00:05 13-MAY-05
BP Key: 1 Status: AVAILABLE Compressed: NO Tag:
TAG20050513T170124
Piece Name:
D:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\NORACLE\BACKUPS
ET\2005_05_13\O1_MF_NCSNF_TAG20050513T170124_18940L10_.BKP
Controlfile Included: Ckp SCN: 791388 Ckp time: 13-MAY-05
SPFILE Included: Modification time: 06-MAY-05
The output shows the various files along with their backup sets that you can recover and restore.
46
Using the REPORT Command
The REPORT command is used to query the RMAN repository and obtain information about obsolete
backups, database schema, performance of unrecoverable operations on files, and the files that need a
backup. The following are the commonly used options for the REPORT command:
• OBSOLETE – Displays backups that are obsolete according to the current retention policy. To
display backups that are obsolete, run the following command at the RMAN prompt:
RMAN> REPORT OBSOLETE;
• NEED BACKUP – Displays files that need to be backed up according to the current retention
policy. To display files that need to be backed up, run the following command at the RMAN
prompt:
RMAN> REPORT NEED BACKUP DATABASE;
MAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 1
Report of files with less than 1 redundant backups
File #bkps Name
---- ----- -----------------------------------------------------
1 0 D:\ORACLE\PRODUCT\10.1.0\ORADATA\NORACLE\SYSTEM01.DBF
2 0 D:\ORACLE\PRODUCT\10.1.0\ORADATA\NORACLE\UNDOTBS01.DBF
3 0 D:\ORACLE\PRODUCT\10.1.0\ORADATA\NORACLE\SYSAUX01.DBF
4 0 D:\ORACLE\PRODUCT\10.1.0\ORADATA\NORACLE\USERS01.DBF
5 0 D:\ORACLE\PRODUCT\10.1.0\ORADATA\NORACLE\EXAMPLE01.DBF
• UNRECOVERABLE – Displays those files on which unrecoverable operations have been

performed. To display files on which unrecoverable operations have been performed, run the
following command at the RMAN prompt:
RMAN> REPORT UNRECOVERABLE;
• SCHEMA – Displays the datafiles and tablespaces present in a database at any point of time. To
display the datafiles and tablespaces currently present in the database, run the following
command at the RMAN prompt:
RMAN> REPORT SCHEMA;
Report of database schema

File Report K-bytes Tablespace RB segs Datafile Name
---- ---------- -------------------- ------- -------------------
1 460800 SYSTEM ***
D:\ORACLE\PRODUCT\10.1.0\ORADATA\NO
RACLE\SYSTEM01.DBF
47
2 30720 UNDOTBS1 ***

RACLE\UNDOTBS01.DBF
3 266240 SYSAUX ***
RACLE\SYSAUX01.DBF
4 5120 USERS ***
RACLE\USERS01.DBF
5 153600 EXAMPLE ***
RACLE\EXAMPLE01.DBF
48
Review Checklist: Configuring and Using Recovery Manager: Oracle

10g Administration II
Introduce Recovery Manager (RMAN).
Describe how to start RMAN and connect to a target database using RMAN.
Describe channel allocation methods.
Learn how to configure persistent settings for RMAN.
Describe how to configure default settings for RMAN.
Learn how to configure retention policy.
Describe how to configure control file autobackups.
Describe methods to create backup sets and image copies.
Describe methods to create compressed backup sets.
Learn how to create incremental backups.
Describe how to enable block change tracking.
Describe various backup options.
Learn how to monitor backups by using the LIST and REPORT commands.
49
Database Recovery: Oracle 10g

Administration II
50
Introducing Database Recovery

Scope
• Describe server-managed recovery.
• Describe user-managed recovery.
Focused Explanation
Server-Managed Recovery
When RMAN is used to recover a database, the recovery is called a server-managed recovery. The
following are the steps to perform a server-managed recovery:
1. Start the database you want to recover in the MOUNT mode by running the following command at
the SQL prompt:
SQL> STARTUP MOUNT;
2. Start RMAN and run the following RMAN script at the RMAN prompt to restore and recover a
database by using the database backup:
RMAN> RUN
2 {
3 ALLOCATE CHANNEL C1 TYPE DISK;
4 RESTORE DATABASE;
5 RECOVER DATABASE;
6 ALTER DATABASE OPEN;
7 }
In the above RMAN script, first, the C1 channel is allocated to recover a database. Next, the
database is restored and recovered by using the RESTORE and RECOVER commands,
respectively. Finally, the database is reopened by using the ALTER DATABASE command.
User-Managed Recovery
When you manage the database files that are required to recover a database manually, the recovery is
called a user-managed recovery. In a user-managed recovery, you use operating system commands to
restore the files that are required to recover a database from a tape or disk. You must identify the
datafiles that must be restored to recover a database. To recover a database by using the user-managed
recovery, perform the following steps:
1. Start the database you want to recover by running the following command at the SQL prompt:
SQL> STARTUP;
ORACLE instance restarted.
51
Total System Global Area 88043512 bytes

Fixed Size 785678 bytes
Variable Size 76734032 bytes
Database Buffers 8388980 bytes
Redo Buffers 245177 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 – see DWTR trace file
ORA_01110: data file 4: 'c:\oradata\user02.dbf'
The output of the above command indicates that the user02.dbf file is missing, and
consequently, the database cannot be opened.
2. Restore the user02.dbf file by copying it from the backup directory to the disk where the last
database backup was stored. To copy the user02.dbf file, run the following command at the
command prompt:
c:\oradata> COPY \backup\user02.dbf;
In the above command, \backup is the backup directory where the last database backup was
stored, and c:\oradata is the directory to which you want to copy the user02.dbf file.
3. Start the database in the MOUNT mode by running the following command at the SQL prompt:
SQL> STARTUP MOUNT;
4. Recover the database by running the following command at the SQL prompt:
SQL> RECOVER DATABASE;
5. Open the database by typing the following statement at the SQL prompt:
SQL> ALTER DATABASE OPEN;
52
Recovering Control Files

Scope
• Describe how to recover a control file by using the control file autobackup.
• Describe how to recover a control file by re-creating that control file.
Focused Explanation
A control file is a binary file that stores the physical structure of a database. A control file is used when
mounting a database and stores the following information about the database:
• the name of a database
• the names and locations of the datafiles and redo log files of the database
• the timestamp at which the database was created
• the current log sequence number
• information about checkpoints
If you have deleted the control file and it copies accidentally or if the control file and its copies have been
corrupted, you can recover the control file either by using the control file autobackup created by RMAN or
by re-creating a control file.
Recovering a Control File by Using Control File Autobackup
You can configure RMAN to automatically back up a control file after each backup operation. The process
of configuring RMAN to back up a control file automatically is called control file autobackup. To recover a
control file by using the control file autobackup, you must first configure the RMAN settings. To configure
the RMAN settings, connect to the target database and run the following command at the RMAN prompt:
RMAN> CONFIGURE CONTROL FILE AUTOBACKUP ON;
To recover a control file by using the control file autobackup, perform the following steps:
1. Run the following RMAN script at the RMAN prompt to back up a database:
RMAN> RUN
2 {
3 BACKUP DATABASE;
4 BACKUP(ARCHIVELOG ALL);
5 }
2. Delete the control file and its copies to simulate a situation in which all the control files have been
deleted and need to be recovered by running the following command at the command prompt;
% DELETE *.ctl
53
3. Start the database in the NOMOUNT mode by running the following command at the SQL prompt:
SQL> STARTUP NOMOUNT;
4. Start RMAN and connect to the target database by running the following command at the
command prompt:
% rman CONNECT / TARGET
5. Specify the Database Identifier (DBID) of the database at the RMAN prompt. The syntax to
specify the DBID is as follows:
SET DBID dbid
Note: The DBID of a target database is displayed when you connect to the target database.
6. Restore the control file by running the following command at the RMAN prompt:
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
7. Mount the database by running the following command at the RMAN prompt:
RMAN> ALTER DATABASE MOUNT;
8. Recover the database by running the following command at the RMAN prompt:
RMAN> RECOVER DATABASE;
9. Open the database by running the following command at the RMAN prompt:
RMAN> ALTER DATABASE OPEN RESETLOGS;
Recreating a Control File
You can create a control file by running the ALTER DATABASE BACKUP statement. This statement creates
the control file in the ASCII format. You can use the control file in the ASCII format to recreate the control
file in a binary format. The binary format is required to store the information of a database. To recreate a
control file, perform the following steps:
1. To create the control file in the ASCII format, type the following statement at the SQL prompt:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
2. Search for the created control file in the \UDUMP directory and view the contents of the control
file. This file contains two sections, Set #1. NORESETLOGS case and Set #2. RESETLOGS
case.
3. Copy the Set #1. NORESETLOGS case section to a new text file, backup_noreset.txt. This
text file represents the recreated control file.
54
4. Run the script for the backup_noreset.txt file by running the following command at the SQL
prompt:
SQL> @backp_noreset.txt ;
55
Performing Incomplete Recovery

Scope
• Describe how to perform incomplete recovery by using RMAN.
• Describe how to perform incomplete recovery by using SQL commands.
• Describe how to perform incomplete recovery by using Enterprise Manager Database Control.
• Describe how to perform incomplete recovery using the RESETLOGS option.
Focused Explanation
Performing Incomplete Recovery
Incomplete recovery is the process of recovering an entire database to a previous specific time, a System
Change Number (SCN), or a log sequence number. This process is called incomplete recovery because it
does not use all the archive log files and redo log files to recover a database. Incomplete recovery is also
called database point-in-time recovery (DBPITR).
Note: A log sequence number is a number that uniquely identifies a set of redo records in a redo log file.
When you recover a database to a specific time in the past, it is called time-based recovery. When you
recover a database to a specific log sequence number, it is called sequence-based recovery.
Note: You cannot perform incomplete recovery if the database you want to recover is open in the
NOARCHIVELOG mode because you must use archive redo log files to perform incomplete recovery.
Performing Incomplete Recovery by Using RMAN
You can perform time-based, sequence-based, and SCN-based recovery by using the RECOVER
command at the RMAN prompt.
Performing Time-Based Recovery by Using RMAN
The following are the two ways in which you can perform time-based recovery using the RECOVER
command:
• by specifying the UNTIL TIME clause along with the RECOVER command
• by specifying the SET UNTIL TIME clause prior to the RECOVER command
When you specify a date up to which you want to perform a time-based recovery in the UNTIL TIME or
SET UNTIL TIME clause, the date can only be in one of the following two formats:
• a literal string in the format specified in the NLS_DATE_FORMAT initialization parameter
• a SQL expression such as 'SYSDATE-8' or TO_DATE('04-JAN-2004','DD-MON-YYYY'),

which evaluates to the DATE data type
56
To perform a time-based recovery using RMAN, perform the following steps:
1. Specify the value of the NLS_DATE_FORMAT initialization parameter by running the following
command at the command prompt:
% SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'
Note: You can also specify any other date format for the value of the NLS_DATE_FORMAT initialization
parameter.
2. Start the target database in the MOUNT mode by running the following command at the SQL prompt:
SQL> STARTUP MOUNT;
3. Start RMAN and connect to the target database by running the following command at the command
prompt:
4. Run the following RMAN script at the RMAN prompt to recover the target database to January 1,
2005:
RMAN> RUN
2 {
3 SET UNTIL TIME '01-JAN-2005';
4 RESTORE DATABASE;
5 RECOVER DATABASE;
6 }
Performing Sequence-Based Recovery by Using RMAN
The following are two ways to perform a sequence-based recovery using the RECOVER command:
• specifying the UNTIL SEQUENCE clause with the RECOVER command
• specifying the SET UNTIL SEQUENCE clause prior to the RECOVER command
To perform a sequence-based recovery by using RMAN, you must first query the V$LOG_HISTORY view
to find the log sequence number and its corresponding thread, up to which you want to recover the
database. To perform a sequence-based recovery by using RMAN, perform the following steps:
1. Query the V$LOG_HISTORY view by running the following statement at the SQL prompt:
SQL> SELECT SEQUENCE#,THREAD#,FIRST_TIME FROM V$LOG_HISTORY;
57
SEQUENCE# THREAD# FIRST_TIM

---------- ---------- ---------
23 1 08-JUN-05
24 1 08-JUN-05
25 1 08-JUN-05
26 1 08-JUN-05
27 1 08-JUN-05
28 1 08-JUN-05
29 1 08-JUN-05
30 1 08-JUN-05
You can use the FIRST_TIME column of the V$LOG_HISTORY view to find the log sequence number
up to which you want to recover the database.
2. Start the database that you want to recover in the MOUNT mode.
3. Start RMAN and connect to the target database.
4. Run the following RMAN script at the RMAN prompt to recover the target database to a specified log
sequence number:
RMAN> RUN
2 {
3 SET UNTIL SEQUENCE 23 THREAD 1;
4 RESTORE DATABASE;
5 RECOVER DATABASE;
6 }
The above RMAN script recovers the database only up to the log sequence number 23 and thread 1,
without including the log sequence 23.
Recovering a Database to a Specified SCN
To recover a database to a specified SCN, you must know the SCN up to which you want to recover the
database. To recover a database to a specified SCN by using RMAN, perform the following steps:
1. Start the database in the MOUNT mode.
2. Start RMAN and connect to the target database.
3. Run the following RMAN script to recover the database to a specified SCN:
58
RMAN> RUN
2 {
3 RESTORE DATABASE;
4 RECOVER DATABASE UNTIL SCN 1800;
5 }
This RMAN script recovers the database to SCN 1800, not including SCN 1800.
4. Open the database with the RESETLOGS option.
Performing Incomplete Recovery by Using SQL Commands
You can perform the following three types of incomplete recoveries by using SQL commands:
• Time-Based – Enables you to recover a database to a specified time.
• Change-Based – Enables you to recover a database to a specified SCN.
• Cancel-Based – Enables you to randomly terminate the recovery of a database by using the
CANCEL command.
Note: Incomplete recovery by using SQL commands is also known as user-managed incomplete
recovery.
Performing Time-Based Recovery Using SQL Commands
You can perform a time-based recovery by using the RECOVER command along with the UNTIL TIME
clause. You must specify the time up to which you want to recover a database, in the YYYY-MM-
DD:HH24:MI:SS format, in the UNTIL TIME clause. To perform a time-based recovery, perform the
following steps:
1. Shut down the database you want to recover by running the following command at the SQL
prompt:
SQL> SHUTDOWN IMMEDIATE;
2. Restore all the datafiles of the database by copying the datafiles from the backup directory on the
disk where the last database backup is stored. To copy all the datafiles, run the following
command at the command prompt:
c:\oradata> COPY \backup\*.dbf;
In the above command, \backup is the backup directory in which the last database backup is
stored and c:\oradata is the directory to which you want to copy the datafiles.
4. Run the following command at the SQL prompt to perform a time-based recovery:
SQL> RECOVER DATABASE UNTIL TIME '01-FEB-2005:00:00:00';
59
The above command recovers the database to 01-FEB-2005:00:00:00.
Performing Change-Based Recovery Using SQL Commands
You can perform a change-based recovery by using the RECOVER command along with the UNTIL
CHANGE clause. The following are the steps to perform a change-based recovery:
1. Shut down the database that you want to recover.
2. Restore all the datafiles of the database.
4. Query the CHANGE# column of the V$RECOVER_FILE view to identify the SCN up to which you
want to recover the database by issuing the following statement at the SQL prompt:
SQL> SELECT CHANGE# FROM V$RECOVER_FILE;
5. Run the following command at the SQL prompt to perform a change-based recovery, performing
a recovery up to SCN 999:
SQL> RECOVER DATABASE UNTIL CHANGE 1000;
Performing Cancel-Based Recovery by Using SQL Commands
In a cancel-based recovery, you are prompted with suggested file names of the archived log files. The
recovery stops when you run the CANCEL command or when all the redo log files have been applied to
the datafiles. The following are the steps to perform a cancel-based recovery:
1. Shut down the database that you want to recover.
2. Restore all the datafiles of the database.
4. Start a cancel-based recovery by running the following command at the SQL prompt:
SQL> RECOVER DATABASE UNTIL CANCEL;
5. Stop the recovery by running the following command at the SQL prompt:
SQL> CANCEL;
60
Performing Incomplete Recovery Using Enterprise Manager Database Control
The Enterprise Manager Database Control helps to perform incomplete recovery of an entire database.
The following are the steps to perform incomplete recovery of a database by using the Enterprise
Manager:
1. Type http://server_name:port_number/em/ in the address bar of the Web browser. The

Login to Database: oracle page is displayed.
2. Type sys as the user name in the User name text box.
3. Type the password for the sys user in the Password text box.
4. Select the SYSDBA option from the Connect As combo box.
5. Click the Login button to log on to the Enterprise Manager. The Database: oracle page is
displayed.
6. Click the Maintenance tab. The Maintenance tab page is displayed.
7. Click the Perform Recovery link. The Perform Recovery: Type page is displayed.
8. Select the Whole Database option from the Object Type drop-down list box.
9. Type the name of a user with administrator privileges in the Username text box.
10. Type the administrative user's password in the Password text box.
11. Click the Next button to continue. The Recovery Wizard page is displayed.
12. You must wait for the database that you are recovering to shut down. After the database is shut
down, click the Refresh button. The Database: oracle page is displayed.
13. Click the Perform Recovery button. The Perform Recovery: Credentials page is displayed.
14. Type the host credentials in the Username and Password text boxes under the Host
Credentials section.
15. Type the database credentials in the Username and Password text boxes under the Database
16. Click the Continue button to continue. The Perform Recovery: Type page is displayed again.
Figure 3-1 shows the Perform Recovery: Type page.
61
Figure 3-1: The Perform Recovery: Type Page
17. Click the Next button to continue. The Perform Recovery: Point-in-time page is displayed. This
page displays the following two options:
• Recover to the current time – Helps to recover a database to the present time.
• Recover to a prior point-in-time – Helps to recover a database to a specified time in the

past, a specified SCN, or a specified log sequence number.
The Recover to the current time option is selected by default.
18. Select the Recover to a prior point-in-time option.
19. Type the date up to which you want to recover the database in the Date text box.
20. Click the Next button to continue. The Perform Recovery: Rename page is displayed. This page
displays the options available to restore the datafiles of the database to the default location or a
new location. Figure 3-2 shows the Perform Recovery: Rename page.
62
Figure 3-2: The Perform Recovery: Rename Page
21. Select the No. Restore the files to the default location option.
22. Click the Next button to continue. The Perform Recovery: Review page is displayed. This page
displays the RMAN script to recover the database.
23. Click the Submit button to start recovering the database. When recovery is complete, the
Operation Succeeded page, which indicates that the database is recovered, is displayed.
Performing Incomplete Recovery Following the RESETLOGS Option
In versions prior to Oracle 10g, whenever you performed an incomplete recovery of a database, you were
required to open a database with the RESETLOGS option. The RESETLOGS option resets the redo log
sequence for the Oracle database and creates a new incarnation of the database. This process
invalidates the use of database backups created prior to the use of the RESETLOGS option. After
incomplete recovery and opening the database with the RESETLOGS option, you were required to back up
the database. In addition, if you used the RMAN catalog for database backups, you were required to run
the following command at the RMAN prompt:
RMAN> RESET DATABASE
63
In Oracle 10g, you are not required to back up a database after the incomplete recovery. You are also not
required to back up a database under the following conditions:
• When you perform a recovery by using a backup control file and open the database with the
RESETLOGS option after performing the recovery
• When you re-instantiate a database following a failover
The following are the advantages of the simplified recovery performed by using the RESETLOGS option:
• You do not need to create a full backup of a database after incomplete recovery.
• You do not need to recreate a new standby database after a failover.
• You can create incremental backups based on full backups of a previous incarnation by using
RMAN.
In Oracle 10g, you are not required to create a backup after incomplete recovery because Oracle 10g has
introduced a new format specification for the archived log files. This new format prevents overwriting of
the archived redo log files with the same redo log sequence number, across different database
incarnations. You can view the new format for the archived redo log files by running the following
command at the SQL prompt:
SQL> SHOW PARAMETER LOG_ARCHIVE_FORMAT;
NAME TYPE VALUE

---------------------------- ----------- ------------
log_archive_format string ARC%S%R.%T
In the output, %R format specifier represents the resetlog id and ensures that a unique name is generated
for the archived redo log file.
64
Review Checklist: Database Recovery: Oracle 10g Administration II

Describe server-managed recovery.
Describe user-managed recovery.
Describe how to recover a control file by using control file autobackup.
Describe how to recover a control file by re-creating a control file.
Describe how to perform incomplete recovery using RMAN.
Describe how to perform incomplete recovery using SQL commands.
Describe how to perform incomplete recovery using the Enterprise Manager Database Control.
Describe how to perform incomplete recovery followed by the RESETLOGS option.
65
Understanding Flashback Database

and Database Corruption: Oracle 10g
Administration II
66
Understanding Flashback Database

Scope
• Introduce Flashback Technology and its features.
• Configure the flash recovery area.
• Describe how to use the flash recovery area.
• Back up the flash recovery area.
• Describe how to configure Flashback Database.
• Know how to use and monitor the Flashback Database.
Focused Explanation
Overview of Flashback Technology
Flashback Technology enables you to view and recover data in a database at a prior point in time. Using
the Flashback Technology, you can view past versions of schema objects, query historical data, and
detect and repair logical corruptions. The following are the various features that utilize Flashback
Technology:
• Flashback Database – Enables you to recover an entire database from logical data corruptions
and user errors. Flashback Database is an efficient alternative to database point-in-time recovery.
• Flashback Version Query – Enables you to retrieve all versions of a row in a table as they existed
between two timestamps or System Change Numbers (SCNs). This feature enables you to
retrieve metadata about different versions of a row. This metadata includes the start time, end
time, operation, and transaction ID of the transaction that created a particular version of a row.
• Flashback Transaction Query – Enables you to view the changes made to the database by a
single transaction or by all the transactions in the database. Flashback Transaction Query uses
the FLASHBACK_TRANSACTION_QUERY view to retrieve the information related to transactions.
The FLASHBACK_TRANSACTION_QUERY view displays the SQL statements to undo the changes
made to a table by a specific transaction.
• Flashback Table – Enables you to recover a table from a point of failure, using a timestamp or
SCN. When you recover a table by using the Flashback Table feature, all the table’s dependent
objects are also recovered.
• Flashback Drop – Enables you to restore a dropped table with the database online, while
maintaining dependent objects and referential integrity. When you drop tables, they are stored in
the recycle bin. The recycle bin is a logical tablespace structure that stores dropped objects and
their objects dependents. Flashback Database recovers the dropped tables from the recycle bin.
67
Managing the Flash Recovery Area

The flash recovery area is a file system, directory, or Automatic Storage Management (ASM) disk group
that stores files related to the recovery of a database. The flash recovery area stores various types of files
such as control files, archived redo log files, flashback logs, RMAN backup sets, SPFILE autobackups,
and datafile copies.
Configuring a Flash Recovery Area
You must configure a flash recovery area before using it. You can configure the flash recovery area by
specifying the values of the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE
initialization parameters. The DB_RECOVERY_FILE_DEST initialization parameter specifies the location
where all the flash recovery area files are stored. The DB_RECOVERY_FILE_DEST_SIZE initialization
parameter specifies the total space limit, in bytes, for the flash recovery area. To specify the value of the
DB_RECOVERY_FILE_DEST_SIZE initialization parameter, type the following statement at the SQL
prompt:
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=10M SCOPE = BOTH;
In the above statement, the value of the DB_RECOVERY_FILE_DEST_SIZE initialization parameter is set
to 10M, indicating that the size of the flash recovery area is 10 MB. The BOTH value of the SCOPE
parameter specifies that the value of the DB_RECOVERY_FILE_DEST_SIZE initialization parameter is set
in both the server parameter file and in memory.
To specify the value of the DB_RECOVERY_FILE_DEST initialization parameter, type the following
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST =

'ORACLE_HOME\oradata\flash_recovery\ora':
In the above statement, the location of the flash recovery area is specified as
C:\oradata\flash_recovery\ora.
You can view information, such as the location and current space usage, about the flash recovery area by
querying the V$RECOVERY_FILE_DEST view. The following columns are in the
V$RECOVERY_FILE_DEST view:
• NAME – Indicates the location path of the flash recovery area.
• SPACE_LIMIT – Indicates the maximum size, in bytes, of the flash recovery area.
• SPACE_USED – Indicates the space currently used, in bytes, by flash recovery area files.
• SPACE_RECLAIMABLE – Indicates the space, in bytes, occupied by obsolete and redundant data.
You can delete redundant and obsolete data to free space in the flash recovery area for reuse.
• NUMBER_OF_FILES – Indicates the number of files that exist in the flash recovery area.
68
Using the Flash Recovery Area
You can use the flash recovery area as a destination to store database backup files. You must specify the
flash recovery area as the default destination to store database backup files by running the CONFIGURE
CHANNEL command and then you can back up a database by running the BACKUP or BACKUP AS COPY
command. To use the flash recovery area as the destination to store database backup files and to back
up a database, perform the following steps:
1. Start RMAN and connect to the target database by issuing the following command at the
command prompt:
2. Run the following command at the RMAN prompt to use the flash recovery area as the default
destination:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT CLEAR;
3. Run the following command at the RMAN prompt to back up the database:
RMAN> BACKUP AS COPY DATABASE;
4. Run the following statement at the SQL prompt to view the space used by the database backup
files in the flash recovery area:
SQL> SELECT space_used FROM v$recovery_file_dest;
SPACE_USED
----------
581181440
Backing Up the Flash Recovery Area
You must back up the flash recovery area because it contains the information required to recover
databases. You can back up either the entire flash recovery area or the files in the flash recovery area. To
back up the entire flash recovery area, connect to the target database and run the following command at
the RMAN prompt:
RMAN> BACKUP RECOVERY AREA;
To back up the files in the flash recovery area, connect to the target database and run the following
command at the RMAN prompt:
RMAN> BACKUP RECOVERY FILES;
69
Flashback Database
You can use Flashback Database to recover a database to its state at a previous specified point in time.
Flashback Database allows you to undo different types of logical errors, such as erroneous truncation of a
table or accidental dropping of a user account. Flashback Database allows you to recover from logical
corruptions faster than the incomplete recovery process because the mean time to recovery (MTTR)
using the incomplete recovery process depends on the size of the database that you want to recover.
With Flashback Database, the MTTR depends on the number of changes that need to be reversed to
recover a database. In addition, Flashback Database uses flashback logs to recover from logical errors.
Flashback logs store the images of altered blocks. These images can be used to reconstruct datafiles to
recover from logical errors. The incomplete recovery process requires you to restore datafiles from
backup to recover from logical errors.
Note: You must configure the flash recovery area before enabling Flashback Database.
Configuring Flashback Database Using SQL Commands
You must configure Flashback Database before using it. To configure Flashback Database, you must
shut down and restart the database, in MOUNT EXCLUSIVE mode, for which you want to configure
Flashback Database. To shut down the database, run the following command at the SQL prompt:
To restart the database in MOUNT EXCLUSIVE mode, run the following command at the SQL prompt:
SQL> STARTUP MOUNT EXCLUSIVE;
After restarting the database, to configure Flashback Database, perform the following steps:
1. Specify the value of the DB_FLASHBACK_RETENTION_TARGET initialization parameter. The

DB_FLASHBACK_RETENTION_TARGET initialization parameter specifies the maximum time in
minutes up to which a database may be flashed back.
To set the value of the DB_FLASHBACK_RETENTION_TARGET initialization parameter, type the

SQL> ALTER SYSTEM SET

2 DB_FLASHBACK_RETENTION_TARGET=30
3 SCOPE=BOTH;
In the above statement, the value of the DB_FLASHBACK_RETENTION_TARGET initialization

parameter is set to 30, which specifies that the database can be flashed back up to 30 minutes in
the past. The BOTH value of the SCOPE parameter specifies that the value of the
DB_FLASHBACK_RETENTION_TARGET initialization parameter is set in both the server parameter
file and in memory.
70
2. Enable Flashback Database for the database by using the ALTER DATABASE FLASHBACK ON
statement. To enable Flashback Database, type the following statement at the SQL prompt:
SQL> ALTER DATABASE FLASHBACK ON;
Configuring Flashback Database by Using Enterprise Manager Database Control
You can also configure Flashback Database by using Enterprise Manager Database Control. To
configure Flashback Database, perform the following steps:
1. Open Enterprise Manager Database Control in a Web browser.
2. Click the Maintenance tab.
3. Click the Configure Recovery Settings link. The Configure Recovery Settings page is
displayed. Figure 4-1 shows the Configure Recovery Settings page.
Figure 4-1: The Flash Recovery Area Section of the Configure Recovery Settings Page
71
The Flash Recovery Area section on the page contains the following text boxes:
• Flash Recovery Area Location – Enables you to specify the location of the flash recovery
area.
• Flash Recovery Area Size – Enables you to specify the size of the flash recovery area.
• Flashback Retention Time – Specifies the retention period for the flash recovery area files.
• Enable flashback logging for fast database point-in-time recovery – Allows you to
enable or disable flashback logging.
4. Select the Enable flashback logging for fast database point-in-time recovery check box.
5. Type the retention period for the flash recovery area files in the Flashback Retention Time text
box.
6. Click the Apply button to apply the changes in Flashback Database.
Using Flashback Database with RMAN
You can use Flashback Database with RMAN to perform time-based, sequence-based, and SCN -based
recovery. You can query the V$FLASHBACK_DATABASE_LOG view to identify the time, sequence, or SCN,
up to which you can flash back a database. To flash back a database to a specified SCN by using RMAN,
perform the following steps:
1. Type the following statement at the SQL prompt to query the V$FLASHBACK_DATABASE_LOG
view:
SQL> SELECT oldest_flashback_scn, oldest_flashback_time

2 FROM v$flashback_database_log;
OLDEST_FLASHBACK_SCN OLDEST_FL
-------------------- ---------
767771 19-MAY-05
The output indicates the SCN and the time in the past, up to which you can flash back the current
database.
2. Shut down the database by running the following command at the SQL prompt:
3. Start the database in MOUNT mode by running the following command at the SQL prompt:
SQL> STARTUP MOUNT;
72
command prompt:
5. Run the following command at the RMAN prompt to flash back a database to a specified SCN, for
example, to SCN 456388:
RMAN> FLASHBACK DATABASE TO SCN = 456388;
6. Open the database by running the following statement at the SQL prompt:
SQL> ALTER DATABASE OPEN RESETLOGS;
To flash back a database to a specified log sequence number or a time in the past, you must use
the TO TIME or TO SEQUENCE clause with the FLASHBACK DATABASE command, respectively.
Using Flashback Database with Enterprise Manager Database Control
After you have configured Flashback Database using Enterprise Manager Database Control, you can use
Enterprise Manager Database Control to flash back a database. To flash back a database using
Enterprise Manager Database Control, perform the following steps:
2. Click the Maintenance tab.
3. Click the Perform Recovery button. The Perform Recovery: Type page is displayed.
4. Click the Whole Database option in the Object Type drop-down list box.
5. Type the name of a user having administrator privileges in the Username text box.
6. Type the password in the Password text box.
7. Click the Next button to continue. The Recovery Wizard page is displayed.
8. You must wait until the database you are recovering is shut down. After the database is shut
down, click the Refresh button. The Database: <database_name> page is displayed.
9. Click the Perform Recovery button. The Perform Recovery: Credentials page is displayed.
10. Type the host credentials in the Username and Password text boxes under the Host
11. Type the database credentials in the Username and Password text boxes under the Database
12. Click the Continue button. The Perform Recovery: Type page is displayed again. Figure 4-2
shows the Perform Recovery: Type page.
73
Figure 4-2: The Perform Recovery: Type Page
The Perform Recovery: Type page displays the following options:
• Object Type – Enables you to recover an entire database, datafiles, or tables in a

database.
• Operation Type – Includes the following suboptions:
o Recover to the current time or a previous point-in-time – Enables you to

recover the entire database to the current time or a previous time.
o Restore all datafiles – Enables you to recover all the datafiles of a database.
o Recover from previously restored datafiles – Enables you to recover the

entire database from the previously-restored datafiles.
13. Click the Next button to continue. The Perform Recovery: Point-in-time page is displayed. This
page displays the following options:
• Recover to the current time – Used to recover a database to the current time.
• Recover to a prior point-in-time – Used to recover a database to a specified time in the

past, a specified SCN, or a specified log sequence number.
The Recover to the current time option is selected by default.
74
14. Select the Recover to a prior point-in-time option.
15. Select the SCN option.
16. Type the SCN to which you want to recover the database, in the SCN text box.
17. Click the Next button to continue. The Perform Recovery: Flashback page is displayed. This
page displays the options to use Flashback Database or the point-in-time recovery method to
flash back a database.
18. Select the Yes, use flashback to bring the database back to the specified point-in-time
option.
19. Click the Next button to continue. The Perform Recovery: Review page is displayed. This page
displays the RMAN script to flash back the database.
20. Click the Submit button to start recovering the database. After the recovery is complete, the
Operation Succeeded page that indicates that the database is flashed back is displayed.
Monitoring Flashback Database Using SQL Commands
You can monitor Flashback Database to view information such as the status of Flashback Database and
the space available and used for flashback data. You can monitor Flashback Database by querying the
following dynamic views:
• V$DATABASE – Allows you to check whether Flashback Database is enabled for a database. The
V$DATABASE view displays the Database Identifier (DBID) and the name of the current database,
and also contains the FLASHBACK_ON column that has a YES or NO value indicating whether or
not Flashback Database is enabled for the database.
• V$FLASHBACK_DATABASE_LOG – Allows you to view information about flashback data. You can
view the time, SCN, and log sequence number up to which you can flash back a database by
using this view. The columns available in this view are as follows:
o OLDEST_FLASHBACK_SCN – Identifies the oldest SCN to which you can flash back the
database.
o OLDEST_FLASHBACK_TIME – Identifies the earliest time to which you can flash back the
database.
o RETENTION_TARGET – Identifies the target retention time, in minutes.
o FLASHBACK_SIZE – Indicates the size, in bytes, of data currently stored in the flash
recovery area.
o ESTIMATED_FLASHBACK_SIZE – Indicates the estimated size, in bytes, of data needed

in the flash recovery area to recover the database within the current target retention time.
75
• V$FLASHBACK_DATABASE_STAT – Allows you to view the statistics used to monitor the I/O
overhead of logging flashback data. The columns available in this view are as follows:
o BEGIN_TIME – Indicates the time when flashback data logging starts.
o END_TIME – Indicates the time when flashback data logging ends.
o FLASHBACK_DATA – Indicates the number of bytes of flashback data written during the
time between BEGIN_TIME and END_TIME.
o DB_DATA – Indicates the number of bytes of database data written during the time
between BEGIN_TIME and END_TIME.
o REDO_DATA – Indicates the number of bytes of redo data written during the time between
BEGIN_TIME and END_TIME.
o ESTIMATED_FLASHBACK_SIZE – Indicates the number of bytes of redo data written

during the time between BEGIN_TIME and END_TIME.
Monitoring Flashback Database with Enterprise Manager Database Control
To monitor Flashback Database using Enterprise Manager Database Control, perform the following steps:
2. Click the Maintenance link.
3. Click the Configure Recovery Settings link. The Configure Recovery Settings page is
displayed. This page enables you to monitor Flashback Database. This page displays the size of
the flashback logs in Megabytes and the SCN and the time up to which you can flash back a
database. This page also displays the following options:
• Flashback Retention Time – Specifies the retention period for the flash recovery area
files.
• Enable flashback logging for fast database point-in-time recovery – Allows you to
enable or disable flashback logging.
76
Understanding Database Corruption

Scope
• Describe data block corruption.
• Detect database corruptions by using the ANALYZE utility.
• Detect database corruptions by using the DBVERIFY utility.
• Detect database corruptions by enabling the DB_BLOCK_CHANGING initialization parameter.
• Describe the procedures in the DBMS_REPAIR package to detect and repair database corruptions.
• Describe how to repair database corruptions by using the block media recovery feature of RMAN.
Focused Explanation
Introducing Data Block Corruption
Data block corruption occurs when one or more data blocks become unreadable or inconsistent, and the
data contained in the data blocks becomes unusable. A data block may become corrupted due to human
errors. You can view various types of logs, such as application and operating system logs, to identify
block corruption. These logs can be present at the operating system, application, and database levels.
Logs on the operating system level vary from one operating system to another. For example, in Windows,
you can view the operating system logs by using the Event Viewer utility. To access the Event Viewer
utility, click Start -> Control Panel -> Administrative Tools -> Computer Management. In Unix, the
SYSLOG file contains the operating system logs. This file is stored at the /var/adm/syslog location.
The application logs indicate that there is a problem in the process or procedure being used in an
application. The database logs are stored in the ALERT.LOG file and in the associated trace files present
in the UDUMP or BDUMP directory.
Detecting Database Corruptions

You can detect database corruptions by using the DBVERIFY utility, the ANALYZE statement, the
DBMS_REPAIR package, and by enabling the DB_BLOCK_CHECKING initialization parameter.
Using the DBVERIFY Utility
The DBVERIFY utility is used to detect corruptions in a particular datafile. This utility is typically used to
detect corruptions in the backup of a database or in the offline state of the database. The output of the
DBVERIFY utility displays the following information:
• Index and data blocks that have been processed with and without errors
• Total number of blocks processed
• Total number of empty blocks
77
• Total number of blocks that have already been marked as corrupted
You can use the DBVERIFY utility by running the dbv command at the command prompt. The following
are the commonly used parameters for the dbv command:
• FILE – Specifies the datafile that you want to analyze by using the DBVERIFY utility. This
parameter has no default value.
• START – Specifies the starting block of a datafile identifying where you want to start analyzing
the datafile. The default value of this parameter is the first block in the datafile.
• END – Specifies the ending block of a datafile identifying where you want to stop analyzing the
datafile. The default value of this parameter is the last block in the datafile.
• BLOCKSIZE – Specifies the block size of the database. The value of this parameter should be
the same as the value of the DB_BLOCK_SIZE initialization parameter in the initialization
parameter file. The default value of the BLOCKSIZE parameter is 8192.
• LOGFILE – Specifies the name of the file that is used to store the results of the dbv command.
• FEEDBACK – Displays the progress of the DBVERIFY utility.
• PARFILE – Specifies the name of the parameter file that is used to store the values for different
parameters of the dbv command. This parameter is used if you do not want to specify
parameters at the command line. You can pass this parameter file as an argument to the dbv
command.
• USERID – Specifies the name of the user and the password.
• SEGMENT_ID – Specifies the segment identifier.
You can view the parameters of the dbv command and the description of these parameters by running
the following command at the command prompt:
% ORACLE_HOME\oradata\oracle dbv HELP=Y
The output of the above command might be:
Keyword Description (Default)

----------------------------------------------------
FILE File to Verify (NONE)
START Start Block (First Block of File)
END End Block (Last Block of File)
BLOCKSIZE Logical Block Size (8192)
LOGFILE Output Log (NONE)
FEEDBACK Display Progress (0)
PARFILE Parameter File (NONE)
USERID Username/Password (NONE)
SEGMENT_ID Segment ID (tsn.relfile.block) (NONE)
78
You can run the DBVERIFY utility with or without specifying the LOGFILE parameter. For example, to run
the DBVERIFY utility without specifying a file, run the following command at the command prompt:
dbv BLOCKSIZE=8192 FILE=ORACLE_HOME\oradata\oracle\users01.dbf
In the above command, the value of the BLOCKSIZE parameter must match the block size of the
database you want to analyze.
To run the DBVERIFY utility by specifying a file, run the following command at the command prompt:
% ORACLE_HOME\oradata\oracle dbv BLOCKSIZE=8192 FILE=

ORACLE_HOME\oradata\oracle\users01.dbf LOGFILE=c:\users01.log
The output of the above command will be stored in the users01.log file.
You can view the results of the above command by running the following command at the command
prompt:
% ORACLE_HOME\oradata\oracle EDIT users01.log
Using the ANALYZE Statement
You can use the ANALYZE statement to verify the integrity of the structure of an index or table. The
ANALYZE TABLE...VALIDATE STRUCTURE statement is used to analyze a table. The ANALYZE
INDEX...VALIDATE STRUCTURE statement is used to analyze an index created on a table. These
statements return errors if the table or index that you want to analyze is corrupted. For example, to
analyze a table, TABLE1, run the following statement at the SQL prompt:
SQL> ANALYZE TABLE table1 VALIDATE STRUCTURE;
To analyze an index, INDEX1, run the following statement at the SQL prompt:
SQL> ANALYZE INDEX index1 VALIDATE STRUCTURE;
Using the DBMS_REPAIR Package
The DBMS_REPAIR package provides procedures that enable you to detect and repair corrupted data
blocks in tables and indexes. The following procedures are present in the DBMS_REPAIR package:
• CHECK_OBJECT – Detects and displays corrupted data blocks in tables and indexes.
• FIX_CORRUPT_BLOCKS – Marks corrupted data blocks identified by the CHECK_OBJECT

procedure.
• DUMP_ORPHAN_KEYS – Reports index entries that point to the rows in corrupted data blocks.
• REBUILD_FREELISTS – Rebuilds the free lists of database objects to ensure that the blocks
following the corrupted block can be accessed by the free lists.
• SEGMENT_FIX_STATUS – Enables you to fix a corrupted bitmap entry.
79
• SKIP_CORRUPT_BLOCKS – Enables you to ignore data blocks that are marked as corrupted
when scanning tables and indexes.
• ADMIN_TABLES – Enables you to perform administrative functions, such as creating and

dropping tables, to repair corrupted tables.
Using the DB_BLOCK_CHECKING Initialization Parameter
You can detect block corruption at the database level by enabling the DB_BLOCK_CHECKING initialization
parameter. You can assign one of two values, TRUE or FALSE, to this initialization parameter. When this
parameter is set to TRUE, the database automatically checks each block for corruption, each time the
block is modified. When this parameter is set to FALSE, the database does not check blocks in the user
tablespaces. The database checks blocks only in the SYSTEM tablespace. The default value of this
parameter is TRUE for the SYSTEM tablespace. For other tablespaces, the default value of this parameter
is FALSE. You can edit the value of this parameter by editing the initialization parameter file. For example,
to open an initialization parameter file, initora101.ora, run the following command at the command
prompt:
% ORACLE_HOME\oradata\oracle EDIT initora101.ora
You can also specify the value of the DB_BLOCK_CHECKING parameter dynamically, by running the
SQL> ALTER SYSTEM SET DB_BLOCK_CHECKING=TRUE;
Repairing Database Corruptions
RMAN provides the block media recovery feature that is used to recover an individual corrupted data
block or a group of corrupted data blocks. The advantage of using the block media recovery feature to
recover data blocks is that only the corrupted data blocks are detected and recovered instead of the
entire datafile. You can also use the block media recovery feature while a database is running. To use
block media recovery, first identify the corrupted data block and the datafile in which the corrupted data
block is present. The data block corruptions are typically reported at the following location:
• Alert log file
• User trace file
• Output of the ANALYZE utility
• Output of the DBVERIFY utility
For example, you can view the ALERT.LOG file to identify the corrupted data block, and the datafile in
which the corrupted data block is present. The content of the ALERT.LOG file might be:
ORA-01578: ORACLE data block corrupted (file # 7, block # 8)

ORA-01110: data file 7: 'c:\oradata\users01.dbf'
80
After identifying the datafile and the corrupted data block, you must run the BLOCKRECOVER command at
the RMAN prompt to recover the corrupted data block. To recover from the loss of a data block
corruption, perform the following steps:
command prompt:
2. Run the following command at the RMAN prompt to recover the corrupted data block:
RMAN> BLOCKRECOVER DATAFILE 7 BLOCK 8;
81
Review Checklist: Understanding Flashback Database and Database

Corruption: Oracle 10g Administration II
Describe Flashback Technology and its features.
Configure the flash recovery area.
Describe how to use the flash recovery area.
Back up the flash recovery area.
Configure Flashback Database.
Describe how to use Flashback Database.
Monitor Flashback Database.
Describe data block corruption.
Detect database corruptions by using the ANALYZE utility.
Detect database corruptions by using the DBVERIFY utility.
Detect database corruption by using the DB_BLOCK_CHANGING initialization parameter.
Describe the procedures in the DBMS_REPAIR package to detect and repair database
corruptions.
Repair database corruptions by using the block media recovery feature.
82
Recovering from Non-Critical Losses

and User Errors: Oracle 10g
Administration II
83
Recovering from Non-Critical Losses

Scope
• Recover a temporary tablespace.
• Recover a redo log group member.
• Recover an index tablespace.
• Recover a read-only tablespace.
• Re-create a password file.
Focused Explanation
Introducing Non-Critical Losses
Non-critical losses in a database refer to the events that fail due to the loss of non-critical files. A non-
critical file refers to a database file that does not impact the database operations if the database file is lost
or corrupted. The types of non-critical database files are as follows:
• Temporary tablespaces – Tablespaces used to perform sorting operations such as creating

indexes on a table. You can create a new temporary tablespace to recover from the errors
caused due to the loss of a temporary tablespace.
• Redo log files – Database files that store information about all database transactions performed.
A set of identical copies of a redo log file is called a redo log group. Each copy in a redo log group
is called a redo log member. Loss of a redo log member is a non-critical loss because you can
recover a redo log member without impacting database operations. However, loss of a redo log
group is a critical loss.
• Index tablespaces – Refers to the tablespaces that store database indexes. Loss of an index
tablespace may slow down the data access process in a database. Loss of an index tablespace
is a non-critical loss because you can recreate indexes on tables.
• Read-only tablespaces – Refers to the tablespaces that contain static information. You cannot
perform data modification operations on read-only tablespaces. To recover a read-only
tablespace, you must only restore the datafiles associated with the read-only tablespace.
• Password files – Refers to the files that contain the passwords for privileged administrative
database users such as SYSDBA and SYSOPER. You can use password files to connect to a
database instance remotely and perform administrative functions on the database. You can
recreate password files to recover from their loss.
84
Recovering a Temporary Tablespace

You can use the following recovery methods to recover a temporary tablespace:
• Create a new temporary tablespace.
• Start a database with a missing tempfile.
• Change the default temporary tablespace for a database.
Creating a New Temporary Tablespace
You may be required to create a new temporary tablespace to recover from the errors that occur due to
the unavailability of a temporary tablespace. A temporary tablespace can be unavailable due to media
failure such as disk failure or controller failure. Unavailability of a temporary tablespace leads to failure in
actions that perform sorting operations such as creating database indexes and executing SELECT
statements. You must drop the existing temporary tablespace before creating a new temporary
tablespace. Dropping the existing temporary tablespace removes the datafiles and references to the
existing temporary tablespace from the data dictionary. Run the following statement at the SQL prompt to
create a temporary tablespace, TEMP_2, when a database is running:
SQL> CREATE TEMPORARY TABLESPACE temp_2

2 TEMPFILE 'C:\oracle\oradata\ora101t\temp_01.dbf' SIZE 500 M
3 EXTENT MANAGEMENT LOCAL
4 UNIFORM SIZE 10M;
Starting a Database with a Missing Tempfile
A tempfile refers to a specific datafile of a locally-managed tablespace. Starting a database with a missing
tempfile enables you to recover the database when a datafile of the temporary tablespace of the
database is missing or corrupted. To start a database with a missing tempfile, complete the following
steps:
1. Run the following command at the command prompt without logging on to the database with a
missing tempfile:
C:\>sqlplus /nolog
2. Run the following commands at the SQL prompt to connect to the database as the SYSDBA user
and start the database in MOUNT mode:
SQL> CONNECT / AS SYSDBA

SQL> STARTUP MOUNT
3. Run the following statement at the SQL prompt to drop the tablespace in which the missing
tempfile was initially stored:
SQL>DROP TABLESPACE temp_2 INCLUDING CONTENTS;
85
4. Run the following statement at the SQL prompt to create a temporary tablespace, TEMP_2:

2 TEMPFILE 'C:\oracle\oradata\ora101t\temp_01.dbf' SIZE 500M
4 UNIFORM SIZE 10M;
Changing the Default Temporary Tablespace for a Database
To recover from the loss of an existing temporary tablespace in a database, you can specify a new
tablespace to work as the default temporary tablespace for the database. You can change the temporary
tablespace to a new default temporary tablespace by running the ALTER DEFAULT TEMPORARY
TABLESPACE statement. To change the default temporary tablespace of a database, perform the
following steps:
1. Run the following statement at the SQL prompt to create a new temporary tablespace, TEMP_2:

2 TEMPFILE 'C:\oracle\oradata\ora101t\temp_01.dbf' SIZE 500M
4 UNIFORM SIZE 10M;
2. Run the following statement at the SQL prompt to specify TEMP_2 as the new default temporary
tablespace:
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_2;
Recovering a Redo Log Group Member

To recover a redo log group member, perform the following steps:
1. View the trace file and the alert log to identify the lost or corrupted redo log member. To view the
trace file and the alert log, open the files by using a text editor such as Notepad.
2. Remove the lost redo log file member from the data dictionary of the database. Run the following
statement at the SQL prompt to remove the REDO002.log redo log from the data dictionary:
SQL> ALTER DATABASE prod DROP LOGFILE MEMBER

2 'C:\ORACLE\ORADATA\prod\REDO002.LOG';
3. Use the ALTER DATABASE ADD LOGFILE MEMBER statement to re-create the lost redo log
member. To add the redo log group member to a redo log group, run the following statement at
the SQL prompt:
SQL> ALTER DATABASE prod

2 ADD LOGFILE MEMBER 'C:\ORACLE\ORADATA\prod\REDO002.LOG' TO
GROUP 2;
86
Recovering an Index Tablespace
To recover an index tablespace, you must recreate the index tablespace and rebuild the indexes in the
recreated index tablespace.
Recreating an Index Tablespace
To recreate an index tablespace, complete the following steps:
1. Run the following command at the command prompt without logging on to the database:
C:\>sqlplus /nolog
2. Run the following commands at the SQL prompt to connect to the database as the SYSDBA user
and to start the database in MOUNT mode:
SQL> CONNECT / AS SYSDBA
SQL> STARTUP MOUNT
3. Drop the tablespace to be recreated. For example, run the following statement at the SQL prompt
to drop the INDEXES index tablespace:
SQL> DROP TABLESPACE indexes INCLUDING CONTENTS;
4. Run the following statement at the SQL prompt to recreate the INDEXES index tablespace:
SQL> CREATE TABLESPACE indexes

2 DATAFILE 'C:\ORACLE\ORADATA\prod\INDEX01.DBF' SIZE 20M;
Rebuilding the Indexes
After recreating an index tablespace, you must rebuild the indexes in the recreated index tablespace. To
rebuild the indexes, you can create a script to recreate the index. The following example shows how to
write the my_index_pk script to create an index:
CREATE UNIQUE INDEX my_index_pk ON example_table

(column_one,
column_two,
column_three,
column_four)
PCTFREE 10
INITRANS 2
MAXRANS 255
TABLESPACE INDEXES
STORAGE (
INITIAL 1M
NEXT 1M
PCTINCREASE 0
MINEXTENT 1
87
MAXEXTENT 8192)
NOLOGGING
PARALLEL (DEGREE 4)
/
Run the following command at the SQL prompt to run the my_index_pk script to create the index:
SQL> @create_my_index_pk
Recovering a Read-Only Tablespace

The following scenarios describe the types of read-only tablespace recovery:
• Recovering a read-only tablespace from a read-only backup – You have a read-only backup of
the read-only tablespace to be recovered. No changes were made to the tablespace after the
backup. Recovery of a read-only tablespace in this scenario is a non-critical process because you
must only restore the datafiles of the read-only tablespace to perform this recovery.
• Recovering a read-only tablespace from a read/write backup – You have a read/write backup of
the read-only tablespace to be recovered. Recovery of a read-only tablespace in this scenario is
a critical recovery process because to perform this recovery, you must run the RECOVER
command and you must have the redo logs.
• Recovering a tablespace that has been changed from read-only to read/write, from a read-only
backup – You have a read-only backup of the tablespace that has been changed from a read-
only tablespace to a read/write tablespace. You need to recover the tablespace. Recovery of a
tablespace in this scenario is a critical recovery process because to perform this recovery, you
must run the RECOVER command and you must have the redo logs.
Recovering a Password File

You can recreate a password file by using the ORAPWD utility. You must run this utility while the database
is closed. Before recreating a password file, you must know the content and the users of the password
file. Complete the following steps to re-create a password file:
1. Shut down the database for which the password file must be recovered by running the following
command at the SQL prompt:
2. Run the ORAPWD utility to recreate a password file. The following example shows how to run the
ORAPWD utility to recreate a password file:
ORAPWD FILE=D:\oracle\dbs\orapwdora01.pwd password=nik ENTRIES=8
The above example recreates the password file, orapwdora01.pwd, at the location specified by
the keyword FILE. The keyword password in above example specifies the password for logging
into the database as SYS. The keyword ENTRIES specifies the number of user entries allowed for
the password file.
88
Recovering from User Errors

Scope
• Recover a dropped table by using the Flashback Drop feature.
• Describe the recycle bin.
• Use the Flashback Table feature to recover tables to a state the tables were in at a specific time in
the past.
• Use the Flashback Version Query feature to retrieve all the versions of a row in a table.
• Use the Flashback Transaction Query feature to identify changes made to a database at the
transaction level.
Focused Explanation
Using Flashback Drop
Flashback Drop in Oracle 10g allows you to recover dropped tables. When you drop tables, they are
stored in the recycle bin. The recycle bin is a logical tablespace structure that stores dropped objects and
their dependent objects. Flashback Database recovers the dropped tables from the recycle bin.
Working with the Recycle Bin
When you drop objects, such as tables and indexes, they are assigned unique names in the recycle bin to
avoid name conflicts. Name conflicts may occur in the following situations:
• if a database user drops a table, creates a table with the same name as the dropped table, and
then drops the second table
• if two database users create two tables with the same name, and then drop these tables
The names assigned to the dropped objects are in the format BIN$$global_UID$version. The
global_UID parameter is a 24-character identifier used to uniquely identify a dropped object. The
version parameter is a version number assigned by a database to a dropped object.
Viewing the Recycle Bin
To view the objects in the recycle bin, run the following command at the SQL prompt:
SQL> SHOW RECYCLEBIN;
You can also query the following two views to display information about the dropped objects:
• USER_RECYCLEBIN – Enables database users to view the objects dropped they dropped.
• DBA_RECYCLEBIN – Enables administrators to view the objects dropped by all database users.
89
Recovering a Dropped Table from the Recycle Bin
You can recover a dropped table from the recycle bin by running the FLASHBACK TABLE...TO BEFORE
DROP statement. When you use Flashback Drop to recover a dropped table, you can either use the
original name of the dropped table or the name assigned to the dropped table in the recycle bin. For
example, to recover the EMPLOYEE table, run the following statement at the SQL prompt:
SQL> FLASHBACK TABLE employee TO BEFORE DROP;
Note: Flashback Drop does not use point-in-time recovery. Point-in-time recovery was required in earlier
versions of Oracle to recover dropped tables.
Purging the Objects from the Recycle Bin
The recycle bin stores the dropped tables and their dependent objects until they are either automatically
or explicitly purged from the recycle bin.
The time period after which dropped tables and their dependent objects are purged automatically from the
recycle bin is not fixed. The minimum time for which the dropped tables and their dependent objects are
retained in the recycle bin is called the retention period. Dropped tables and their dependent objects are
not purged from the recycle bin until new extents are allocated to new objects in the current tablespace.
This condition is called space pressure. Space pressure may arise if the space limit allocated to a
database user in the current tablespace is exhausted. When space pressure arises, a database purges
the dropped objects from the recycle bin on a first-in, first-out basis. A table’s dependent objects, such as
indexes and constraints, are purged before purging the dropped table.
You run the following statement at the SQL prompt to explicitly purge the table DEPARTMENT and its
dependent objects from the recycle bin:
SQL> PURGE TABLE department;
If you do not want to recover a table, you can drop the table permanently and delete the table from the
recycle bin by using the PURGE clause with the DROP TABLE statement. For example, to drop the table
EMPLOYEE permanently, run the following statement at the SQL prompt:
SQL> DROP TABLE EMPLOYEE PURGE;
You can purge all the objects from the recycle bin allocated to you by running the PURGE RECYCLEBIN
statement. An administrator can purge objects from the recycle bin for all database users by running the
PURGE DBA_RECYCLEBIN statement.
90
Using Flashback Table

Flashback Table in Oracle 10g allows you to recover tables to a state they were in at a specific time or
SCN in the past, even when a database is online. When you recover a table by using Flashback Table, all
the dependent objects of the table are also recovered. For example, if a database user accidentally
deletes some rows from a table, you can use Flashback Table to recover the deleted rows. Flashback
Table uses data in the undo tablespace to recover tables. To use Flashback Table:
• You must have either the FLASHBACK ANY TABLE system privilege or the FLASHBACK object
privilege on the table you want to recover.
• You must have INSERT, SELECT, DELETE, and ALTER privileges on the table you want to
recover.
• You must enable row movement on the table you want to recover.
• The undo tablespace must contain the information necessary to recover a table to a state it was
in at a specific time or SCN in the past.
Recovering a Table by Using Flashback Table
To recover a table by using Flashback Table, you must enable row movement on the table you want to
recover. For example, to enable row movement on the EMPLOYEE table, issue the following statement at
the SQL prompt:
SQL> ALTER TABLE employee ENABLE ROW MOVEMENT;
After enabling row movement on the table, you can use the TO SCN and TO TIMESTAMP clauses with the
FLASHBACK TABLE statement to recover the table to a specific SCN or time in the past, respectively.
For example, the EMPLOYEE table lists the salaries of the employees of WonderWeb. You have modified
the table by updating the salary of an employee, John, in the SAL column at 12:30 P.M. on January 1,
2005. After this update, you want to restore the EMPLOYEE table to its previous state using Flashback
Table. To use Flashback Table, run the following statement at the SQL prompt:
SQL> FLASHBACK TABLE employee TO TIMESTAMP

2 TO_TIMESTAMP('2005-01-JAN 12:30:00', 'YYYY-DD-MON HH24:MI:SS');
To restore the EMPLOYEE table to the SCN 23451, run the following statement at the SQL prompt:
SQL> FLASHBACK TABLE employee TO SCN 23451;
91
When you are in the process of recovering a table by using Flashback Table, the database disables the
triggers on the table by default. After you use Flashback Table, triggers on the table return to the state in
which they existed before Flashback Table was used. To enable the triggers on the EMPLOYEE table
while recovering the table, issue the following statement at the SQL prompt:
SQL> FLASHBACK TABLE employee TO SCN 23451 ENABLE TRIGGERS;
Using Flashback Version Query

Flashback Version Query in Oracle 10g enables you to retrieve all the versions of the rows in a table
between two timestamps or SCNs. A new version of a row is created for every committed operation on
the row. The syntax to use Flashback Version Query is as follows:
SELECT [pseudo_columnlist] FROM table_name

VERSIONS BETWEEN
{SCN|TIMESTAMP {expr|MINVALUE} AND {expr|MAXVALUE}
WHERE condition
In the above syntax, you can include the following columns in the pseudo_columnlist variable:
• VERSIONS_STARTSCN – Specifies the SCN at which the current version of a row was created.
• VERSIONS_STARTTIME – Specifies the timestamp that indicates the time at which the current
version of a row was created.
• VERSIONS_ENDSCN – Specifies the SCN at which a specific row was deleted.
• VERSIONS_ENDTIME – Specifies the timestamp that indicates the time at which a specific row
was deleted.
• VERSIONS_XID – Specifies the transaction ID of the transaction that created the current version
of a specific row.
• VERSIONS_OPERATION – Specifies the operation performed by the current transaction.
Consider a scenario in which you have updated John’s salary three times in the SAL column of the
EMPLOYEE table after midnight. You want to retrieve all the previous values of the SAL column before it
was updated. Issue the following statement at the SQL prompt to retrieve all the previous values of the
SAL column:
SQL> SELECT sal, versions_operation_versions_xid

2 FROM employee
3 VERSIONS BETWEEN TIMESTAMP
3 TO_TIMESTAMP('2005-05-05 00:00:00','YYYY-MM-DD HH24:MI:SS')
4 AND TO_TIMESTAMP('2005-05-07 00:00:00','YYYY-MM-DD HH24:MI:SS')
5 WHERE empname = 'John';
The above statement retrieves the following information related to John:
92
• the operations performed on the SAL column from May 1, 2005 to May 7, 2005
• the values in the SAL column after every update performed on the SAL column
• transaction IDs of the transactions that updated John’s salary
Using Flashback Transaction Query

You can use Flashback Transaction Query to view the transactions that have made changes to a table.
For example, you can view information on the transactions that changed the salary of a particular
employee in the EMPLOYEE table by using Flashback Transaction Query.
First, you can use Flashback Version query to identify the transaction IDs that have made changes to a
table. Then, you can use Flashback Transaction query to retrieve more information about these
transactions. Flashback Transaction Query uses the FLASHBACK_TRANSACTION_QUERY view to retrieve
the information related to transactions. The FLASHBACK_TRANSACTION_QUERY view displays the SQL
statements that you can use to undo the changes made to a table by a specific transaction. To query this
view, you must be assigned the SELECT ANY TRANSACTION privilege. The columns of the
FLASHBACK_TRANSACTION_QUERY view are as follows:
• XID – Specifies the transaction ID of the transaction that resulted in changes to a table.
• START_SCN – Specifies the SCN for the first Data Manipulation Language (DML) statement in a
transaction.
• START_TIMESTAMP – Specifies the timestamp that indicates the time at which the first DML
statement in a transaction was run.
• COMMIT_SCN – Specifies the SCN at which the transaction was committed.
• COMMIT_TIMESTAMP – Specifies the timestamp that indicates the time at which the transaction
was committed.
• LOGON_USER – Specifies the name of the user who owns the transaction.
• UNDO_CHANGE# – Specifies the undo SCN.
• OPERATION – Specifies DML operations such as DELETE, INSERT, or UPDATE, in a transaction.
• TABLE_NAME – Specifies the name of the table that was changed by a DML statement.
• TABLE_OWNER – Specifies the owner of the table that was changed by a DML statement.
• ROW_ID – Specifies the table row that was changed by a DML statement.
• UNDO_SQL – Specifies the SQL statement to undo the changes made by a DML statement.
For example, assume that transaction ID 04000900BE1D0000 made changes to John's salary in the
EMPLOYEE table. To trace the database user who updated John’s salary in the EMPLOYEE table, run the
93
SQL> SELECT logon_user, operation, table_nameE

2 FROM flashback_transaction_query
3 WHERE xid = HEXTORAW(‘04000900BE1D0000’);
The above statement retrieves the following information:
• the name of the user who updated John’s salary

• the operations performed on the SAL column
• the name of the table in which changes were made for by transaction ID 04000900BE1D0000
94
Review Checklist: Recovering from Non-Critical Losses and User

Errors: Oracle 10g Administration II
Recover a temporary tablespace.
Recover a redo log group member.
Recover an index tablespace.
Recover a read-only tablespace.
Recreate a password file.
Recover a dropped table by using the Flashback Drop feature.
Describe how to use the recycle bin.
Recover tables to a state the tables were in at a specific time in the past using the Flashback
Table feature.
Use the Flashback Version Query feature to retrieve all the earlier versions of a row in a table.
Use the Flashback Transaction Query feature to identify changes made to a database at the
transaction level.
95
Understanding Automatic Database,

Storage, and Memory Management:
Oracle 10g Administration II
96
Understanding Automatic Database Management

Scope
• Describe the Automatic Workload Repository (AWR).
• Describe how use Active Session History (ASH).
• Manage server-generated alerts. Use automatic optimizer statistics collection.
• Use Automatic Database Diagnostic Monitor (ADDM).
• Explain undo retention tuning.
• Describe the advisory framework.
• Describe SQL Tuning Advisor.
Focused Explanation
Oracle 10g provides Common Manageability Infrastructure (CMI) to automatically perform database
management activities such as space management, storage management, and system resource
management. CMI provides self-managing and self-tuning capabilities to an Oracle 10g database. CMI
contains various components such as Automatic Workload Repository (AWR), server-generated alerts,
Active Session History (ASH), and the advisory framework. The components of CMI automatically provide
information about performance, space management, and resource allocation issues in an Oracle 10g
database. In addition, the components of CMI can provide suggestions on how to resolve these types of
issues.
Working with Automatic Workload Repository

The AWR collects and stores performance statistics for an Oracle 10g database. All other components of
CMI use the AWR as the data source of these statistics for self-tuning and problem detection in an Oracle
database. The following are the two components of the AWR that collect and store performance statistics
for an Oracle 10g database:
• Statistics collection facility – Collects dynamic performance statistics for a database.
• Workload repository – Refers to a persistence storage area that stores the performance statistics
collected for a database using the statistics collection facility.
Statistics Collection Facility

The statistics collection facility of the AWR collects dynamic performance statistics for a database.
Dynamic performance statistics refer to statistics that are initialized when you start a database and are
lost when the database instance is shut down. These dynamic performance statistics enable you to
measure the performance of a database over a period of time. Dynamic performance statistics are stored
in dynamic performance tables, called fixed tables. Fixed tables refer to memory structures that emulate
97
tables that contain dynamic performance statistics that can be queried. These tables can be used to
create views of the collected dynamic performance statistics.
The following are the categories of database performance statistics that the statistics collection facility
component of the AWR collects:
• Cumulative values – Refer to the statistics that accumulate over a period of time through
continuous updating of information about database activities. Cumulative statistics are created for
all the sessions, SQL statements, database segments, and database services of a database.
• Metrics – Refer to statistics that represent the rate of change in cumulative values during
specified time periods and between database calls or database transactions. Metrics statistics are
calculated by the Manageability Monitor (MMON) process.
• Sampled data – Refer to samples of statistics collected for all user connections of a database. A
database collects sampled data through the ASH sampler.
The following are some dynamic performance statistics of a database that the statistics collection facility
component of the AWR collects:
• Object statistics – Specify access and usage statistics of segments in a database.
• Time model statistics – Specify statistics of total elapsed or Central Processing Unit (CPU) time of
database operations for a database.
• System statistics – Specify cumulative statistics of a database instance since the startup of the
database instance.
• Session statistics – Specify cumulative statistics of a session since the beginning of the session.
• Oracle optimizer statistics – Refer to the statistics used by Oracle 10g to self-tune a database.
• Operating system statistics – Specify system utilization statistics of the operating system on
which an Oracle database is running.
• ASH statistics – Refer to the statistics of recent sessions of a database.
• Wait statistics – Refer to the statistics on activities, such as Input Output operations, CPU
concurrency, COMMIT statements, and scheduler waits.
The following are some dynamic performance views that can be queried to retrieve information about
dynamic performance statistics:
• V$SYS_TIME_MODEL – Displays time model statistics.
• V$SYSSTAT – Displays system statistics.
• V$SESSTAT – Displays session statistics.
• V$OSSTAT – Displays operating system statistics.
98
• V$SERVICE_STATS – Displays wait statistics.
Workload Repository
The workload repository component of the AWR provides tables to store the collected performance
statistics. You need to store the collected statistics to make them persistent and accessible to other
components of CMI. This element of the AWR also works as a repository to store persistence data of
other CMI components. The MMON process periodically saves the cumulative statistics of a database to
the tables of the workload repository. The workload repository ensures that the historical statistics of a
database are available to perform baseline comparison, trend analysis, and troubleshooting.
The workload repository tables are owned by the SYS user. These tables are stored in the SYSAUX
tablespace, and the names of these tables start with WR. To view all the workload repository tables, run
SQL> SELECT tablespace_name

2 FROM dba_tables
3 WHERE tablespace_name = 'SYSAUX'
4 AND SUBSTR(TABLE_NAME,1,2 ) = 'WR';
Enabling AWRs
To enable the AWR for a database, you must set the value of the STATISTICS_LEVEL initialization
parameter to TYPICAL or ALL. The TYPICAL value is the default value of this initialization parameter.
You can view the current value of the STATISTICS_LEVEL initialization parameter by querying the
V$STATISTICS_LEVEL view. To query this view, run the following statement at the SQL prompt:
SQL> SELECT statistics_name, activation_level

2 FROM v$statistics_level;
STATISTICS_NAME ACTIVAT
---------------------------------------------------------------- -------
Buffer Cache Advice TYPICAL
MTTR Advice TYPICAL
Timed Statistics TYPICAL
Timed OS Statistics ALL
Segment Level Statistics TYPICAL
PGA Advice TYPICAL
Plan Execution Statistics ALL
Shared Pool Advice TYPICAL
Modification Monitoring TYPICAL
Longops Statistics TYPICAL
Bind Data Capture TYPICAL
Ultrafast Latch Statistics TYPICAL
Threshold-based Alerts TYPICAL
Global Cache Statistics TYPICAL
Cache Stats Monitor TYPICAL
Active Session History TYPICAL
99
Undo Advisor, Alerts and Fast Ramp up TYPICAL
17 rows selected.
If the value of the STATISTICS_LEVEL initialization parameter is set to BASIC, the AWR does not collect
the database statistics automatically. You can use the DBMS_WORKLOAD_REPOSITORY package to
manually collect the database statistics.
Creating, Modifying, and Dropping Snapshots

The AWR stores performance statistics and workload information about a database in the form of
snapshots. Oracle uses the AWR to take a snapshot of a database at specific intervals, called snapshot
intervals. The default snapshot interval of a database is 60 minutes. The AWR retains snapshot statistics
for a specific time period, called the retention period, and purges the snapshot statistics automatically
after the retention period. The default retention period of the AWR is seven days.
You can view the current settings of the snapshot interval and the retention period by using the
DBA_HIST_WR_CONTROL view. To view the current settings of the snapshot interval and the retention
period, run the following statement at the SQL prompt:
SQL> SELECT snap_interval, retention

2 FROM dba_hist_wr_control;
SNAP_INTERVAL RETENTION
------------------- -------------------
+00000 01:00:00.0 +00007 00:00:00.0
Creating Snapshots
Oracle creates default snapshots of a database using the statistics collection facility component of the
AWR. You also can create snapshots manually by using the CREATE_SNAPSHOT procedure in the
DBMS_WORKLOAD_REPOSITORY package. To create a snapshot manually, run the following command at
the SQL prompt:
SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
Each snapshot has as unique ID in the database. To create a snapshot and return the ID of the snapshot
you created, run the following statement at the SQL prompt:
SQL> SELECT dbms_workload_repository.create_snapshote() FROM DUAL;
100
You can query the DBA_HIST_SNAPSHOT view to retrieve information, such as the beginning and end
time of a snapshot interval. To query the DBA_HIST_SNAPSHOT view for all snapshots, run the following
SQL> SELECT snap_id, begin_interval_time, end_interval_time

2 FROM dba_hist_snapshot
3 ORDER BY snap_id;
SNAP_ID BEGIN_INTERVAL_TIME END_INTERVAL_TIME

-------- ------------------------- -------------------------
16 03-JUN-05 10.30.56.750 PM 03-JUN-05 11.30.21.984 PM
17 03-JUN-05 11.30.21.984 PM 04-JUN-05 12.30.48.890 AM
Modifying Snapshots Settings
You can modify the snapshot settings, such as the interval at which the snapshots of relevant data are
taken and the time period for which snapshots are stored in the AWR. You can view the current snapshot
settings by querying the DBA_HIST_WR_CONTROL view. To query the DBA_HIST_WR_CONTROL view, run
SQL> SELECT * FROM DBA_HIST_WR_CONTROL;
To modify the retention period and the interval at which snapshots are taken, run the following statement
at the SQL prompt:
SQL> BEGIN
2 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
3 retention => 21600,
4 interval => 30);
5 END;
In the above statement:
• retention – Specifies the retention period in minutes. The value of this argument can range
from 1440 to 52,560,000. If you specify the value of this argument as NULL, the value that you
specified earlier is retained.
• interval – Specifies the interval in minutes, at which snapshots are taken. The value of this
argument can range from 10 to 5,256,000. If you specify the value of this argument as NULL,
the value that you specified earlier is retained.
You can also modify snapshot settings using Enterprise Manager Database Control. To modify the
snapshot settings using Enterprise Manager Database Control, perform the following steps:
2. Click the Administration tab.
101
3. Click the Automatic Workload Repository link. The Automatic Workload Repository page
displays the current retention period and the interval at which snapshots are taken.
4. Click the Edit button. Figure 6-1 shows the Edit Settings page.
Figure 6-1: The Edit Settings Page
The Edit Settings page displays the following two options:
• Snapshot Retention – Used to alter the retention period.
• Snapshot Collection – Used to alter the interval at which snapshots are taken.
5. Modify the snapshot settings as required.
6. Click the OK button.
102
Dropping Snapshots
If you do not require snapshots, you can drop the snapshots using the DROP_SNAPSHOT_RANGE
procedure in the DBMS_WORKLOAD_REPOSITORY package. This procedure accepts two arguments,
low_snap_id and high_snap_id. To drop all snapshots with snapshot IDs ranging from 200 to 250,
issue the following statement at the SQL prompt:
SQL> BEGIN
2 DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(
3 low_snap_id => 200,
4 high_snap_id => 250);
5 END;
Creating Baselines
A baseline is a pair of snapshots that represent a period of database usage. You can use baselines to
compare database performance statistics. You can create a baseline using the CREATE_BASELINE
procedure in the DBMS_WORKLOAD_REPOSITORY package. To create a baseline named baseline1,
which includes snapshots from 150 to 250, issue the following statement at the SQL prompt:
SQL> BEGIN
2 DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (
3 start_snap_id => 150,
4 end_snap_id => 250,
5 baseline_name =>'baseline1');
6 END;
You can view the baseline by querying the DBA_HIST_BASELINE view. To query the
DBA_HIST_BASELINE view, run the following statement at the SQL prompt:
SQL> SELECT baseline_name, start_snap_time, end_snap_time

2 FROM dba_hist_baseline;
BASELINE_NAME START_SNAP_TIME END_SNAP_TIME

-------------- -------------------------- -------------------------
baseline1 03-JUN-05 04.04.46.843 PM 03-JUN-05 05.30.24.421 PM
103
Dropping Baselines
You can drop baselines using the DROP_BASELINE procedure in the DBMS_WORKLOAD_REPOSITORY
package. This procedure accepts two arguments, baseline_name and cascade. The baseline_name
argument specifies the name of the baseline that you want to drop. The cascade argument specifies a
TRUE or FALSE value indicating whether or not the snapshots associated with the specified baseline are
dropped when you drop the baseline. This procedure accepts an optional argument, dbid. This argument
specifies the database identifier (DBID) of the database, in which you want to drop the baseline. The
default value of this attribute is local DBID. To drop the baseline1 baseline and all the snapshots
associated with the baseline, run the following command at the SQL prompt:
SQL> EXEC DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE ('baseline1', TRUE);
Viewing AWR Reports by Running SQL Scripts
AWR reports provide information that is stored in AWR. You can view the AWR reports by running the
awrrpt.sql or awrrpti.sql SQL scripts. The awrrpt.sql SQL script generates an HTML or text
report that displays database performance statistics for a range of snapshot IDs. The awrrpti.sql SQL
script generates an HTML or text report that displays database performance statistics for a specified
database and instance. To run the awrrpt.sql or awrrpti.sql SQL scripts, you must have the DBA
role. To run the awrrpt.sql SQL script, perform the following steps:
1. Run the following statement at the SQL prompt:
SQL> @ORACLE_HOME/rdbms/admin/awrrpt
2. Type HTML or text at the prompt to specify whether you want to generate an HTML or text
report.
3. Type the number of days for which you want to list the snapshots at the prompt.
4. Type the beginning snapshot ID for the AWR report at the prompt.
5. Type the ending snapshot ID for the AWR report at the prompt.
6. Type a name for the AWR report that you want to generate at the prompt. The AWR report is
generated.
To run the awrrpti.sql SQL script, perform the following steps:
1. Run the following statement at the SQL prompt:
SQL> @ORACLE_HOME/rdbms/admin/awrrpti
2. Type HTML or text at the prompt to specify whether you want to generate an HTML or text
report.
When you specify the type of the AWR report, a list of database IDs and instance numbers is
displayed.
104
3. Type the database ID for which you want to generate the AWR report at the prompt.
4. Type the database instance number at the prompt.
5. Type the number of days for which you want to list the snapshots at the prompt.
6. Type the beginning snapshot ID for the AWR report at the prompt.
7. Type the ending snapshot ID for the AWR report at the prompt.
8. Type a name for the AWR report that you want to generate at the prompt. The AWR report is
generated.
AWR Views
You can view the performance statistics collected in the AWR by querying various data dictionary views.
The following are some of the views that you can query to view the information stored in the AWR:
• V$ACTIVE_SESSION_HISTORY – Displays information about the active session activity.
• DBA_HIST_BASELINE – Displays information about the baselines captured on the current

database.
• DBA_HIST_DATABASE_INSTANCE – Displays information about the database environment.
• DBA_HIST_SNAPSHOT – Displays information about the snapshots in the current database.
• DBA_HIST_SQL_PLAN – Displays SQL execution plans.
• DBA_HIST_WR_CONTROL – Displays the settings to control the AWR.
Working with Active Session History (ASH)

The ASH provides statistics on the activities of active sessions in an Oracle database instance. The ASH
of an Oracle database instance is stored in the System Global Area (SGA). The size of the ASH of an
Oracle database instance is the number of processors in the computer on which the Oracle database
instance is running multiplied by 2 MB of memory, or five percent of the size of the shared pool in the
Oracle database instance, whichever is less.
You can increase the ASH of an Oracle database instance by increasing either the number of processors
in the computer on which the Oracle database instance is running or the size of the shared pool in the
Oracle database instance.
Note: A System Global Area is a shared memory area that stores data and controls information of an
Oracle instance.
Every second, the ASH collects unique sets of statistics, called samples, on the activities of active
sessions in an Oracle database instance. To collect the statistics, the ASH directly accesses the Oracle
internal memory structures. The following are the various types of data stored in a sample:
105
• SQL_ID – Specifies a unique identification of a SQL statement in a database instance.
• SID – Specifies a unique identification for a database instance.
• Client ID – Specifies a unique identification for a client of a database instance.
• Service ID – Specifies a unique identification of a service present in a database instance.
• Program – Refers to the information about a program of an activity of an active session in a

database instance.
• Module – Refers to the information about a module of an activity of an active session in a

database instance.
• Action – Refers to the information about an action of an activity of an active session in a database
instance.
• Object – Refers to the information about all objects involved in an activity of an active session.
• File – Refers to the information about all files involved in an activity of an active session.
• Block – Refers to the information about all database blocks involved in an activity of an active
session.
• Wait event number – Refers to the identification number of a wait event, if an active session is in
the wait state.
• Actual wait time – Refers to the time period of a wait event, if an active session is in the wait
state.
You can view the information about the ASH of a database instance by querying the
V$ACTIVE_SESSION_HISTORY view. To query the V$ACTIVE_SESSION_HISTORY view, issue the
SQL> SELECT session_state, event

2 FROM v$active_session_history;
Oracle stores some of the statistics collected by the ASH in the workload repository of the AWR. The
following are the two methods that Oracle uses to store the statistics in the workload repository:
• using the MMON process – Flushes the buffers of the ASH after every 30 minutes. The MMON
process filters some of the data to the AWR.
• using the Memory Monitor Light (MMNL) process – Flushes out a portion of the ASH, if the
memory of the ASH is full before 30 minutes. This process filters a part of the flushed data to the
AWR.
106
Managing Server-Generated Alerts

Server-generated alerts are notifications that the Oracle database server generates automatically, when it
detects a problematic situation in an Oracle database. A server-generated alert contains the description
of a detected problem and suggestions to resolve the problem. For example, a server-generated alert is
generated by default when the space usage of a tablespace exceeds 85 percent. These alerts may also
contain a proposed solution to the problem identified by the server-generated alert. Server-generated
alerts can be either based on a threshold value or on an event, such as occurrence of the Snapshot
Too Old error.
Threshold-based server-generated alerts occur at threshold warning and critical levels. For example, a
threshold-based alert on tablespace usage can be generated if the tablespace space usage exceeds a
certain limit. Event-based server-generated alerts can be generated if a particular event occurs.
Examples of event-based server-generated alerts include Recovery Area Space Usage, Snapshot
Too Old, and Resumable Session Suspended.
When the Oracle database server discovers a condition that can generate an alert, it generates an alert
that includes the following information:
• the name of the database entity on which the alert was generated
• a description of the problem for which the alert was generated
• a remedial action
After creating an alert, the Oracle database server sends an alert message to a predefined queue,
ALERT_QUEUE, owned by the SYS user. The Enterprise Manager Database Control reads this queue and
provides notifications about the alert.
Note: The queue ALERT_QUEUE is automatically purged by the Oracle database system at regular
intervals.
Some server-generated alerts are enabled by default. These alerts include Tablespace Space Usage,
Snapshot Too Old, Recovery Area Low On Free Space, and Resumable Session Suspended.
Setting Alert Thresholds
You can set alert thresholds using Enterprise Manager Database Control or PL/SQL. To change the alert
thresholds using Enterprise Manager Database Control, perform the following steps:
2. Click the Manage Metrics link under the Related Links section. The Manage Metrics tab
page displays the current thresholds.
3. Click the Edit Threshold button.
4. Set the threshold for different metrics.
107
5. Click the OK button to apply the changes in the thresholds. The Manage Metrics page is
displayed again and the update message is displayed on this page.
Viewing Information about Server-Generated Alerts
You can view information about server-generated alerts using various views. Some of these views are as
follows:
• DBA_THRESHOLDS – Displays the threshold settings for the current database instance.
• DBA_OUTSTANDING_ALERTS – Displays information about the outstanding alerts in a database.
• DBA_ALERT_HISTORY – Displays the history of alerts that have been resolved.
• V$ALERT_TYPES – Displays information about the types of alerts.
• V$METRICNAME – Displays information about the names and identifiers of system metrics.
• V$METRIC and V$METRICHISTORY – Display system-level metrics.
Using Automatic Database Diagnostic Monitor

Automatic Database Diagnostic Monitor (ADDM) is a self-diagnostic engine provided by Oracle that helps
identify and diagnose performance problems of an Oracle database. An Oracle 10g database
automatically collects and stores information in the AWR, in the form of snapshots, about the database
state and workload. By default, this information is collected once every hour and stored in the AWR for a
week thereafter. ADDM analyzes the snapshots stored in the AWR to identify the performance problems
of an Oracle database. ADDM then generates reports based on the analysis of these snapshots, and
stores these reports in the AWR. ADDM also recommends solutions to identified performance problems.
Note: The MMON process triggers the ADDM analysis process when a snapshot is stored in the AWR.
Viewing ADDM Results
You can view the results of the analysis performed by ADDM by using either data dictionary views or
Enterprise Manager Database Control. To view the results using Enterprise Manager Database Control,
perform the following steps:
1. Open Enterprise Manager Database Control in the Web browser.
2. Click the Advisor Central link. The Advisor Central tab page is displayed.
3. Click the ADDM link. The Create ADDM Task page is displayed. This page helps you create
snapshots.
4. Click the OK button. The Automatic Database Diagnostic Monitor (ADDM) page is displayed.
5. Click the View Report button. The View Report page is displayed. This page displays the ADDM
report.
108
6. Click the Save to File button if you want to save the report to a file.
Querying the ADDM Dictionary Views
You can also query the DBA_ADVISOR_FINDINGS and DBA_ADVISOR_TASKS dictionary views to
retrieve the results of the analyses performed by ADDM. For example, to view the number and type of
results analyzed by ADDM during the last 24 hours, run the following statement at the SQL prompt:
SQL> SELECT type, COUNT(*)

2 FROM dba_advisor_finidings
3 NATURAL JOIN dba_advisor_tasks
4 WHERE created BETWEEN SYSDATE-1 AND SYSDATE
5 GROUP BY type;
TYPE COUNT(*)
----------- ----------
INFORMATION 15
PROBLEM 10
Changing ADDM Parameters
You can view the ADDM parameters, such as DBIO_EXPECTED and DB_ID, by using the
DBA_ADVISOR_DEF_PARAMETERS view. These parameters control the analyses that ADDM performs.
You can also modify these parameters using the SET_DEFAULT_TASK_PARAMETER procedure in the
DBMS_ADVISOR package. To query the DBA_ADVISOR_DEF_PARAMETERS view, run the following
SQL> SELECT parameter_name, parameter_value

2 FROM dba_advisor_def_parameters
3 WHERE advisor_name = 'ADDM';
PARAMETER_NAME PARAMETER_VALUE
--------------------- ---------------------
ANALYSIS_TYPE PERIOD
DBIO_EXPECTED 10000
DB_ELAPSED_TIME 0
DB_ID 0
HISTORY_TABLE UNUSED
SCOPE_TYPE UNUSED
SCOPE_VALUE UNUSED
7 rows selected.
109
If the data transfer speed of the hard disk of your computer is slow, you can change the DBIO_EXPECTED
parameter of ADDM by running the following command at the SQL prompt:
SQL> EXEC DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER (

2 'ADDM','DBIO_EXPECTED', 16000);
Automatic Optimizer Statistics Collection

Optimizer statistics represent a collection of information about a database and database objects. These
statistics include the following information:
• Table statistics – Display the number of rows and memory blocks occupied by a table, and the
average length of a row of the table.
• Column statistics – Display the number of distinct values, number of NULL values, and data
distribution in a column of a table.
• Index statistics – Display the number of leaf blocks and levels used to store an index, and the
clustering factor of the index.
• System statistics – Display the I/O and CPU performance and utilization.
Optimizer statistics should be updated regularly because the objects in a database are created, updated,
and deleted regularly. Oracle 10g maintains optimizer statistics automatically. However, you can also
maintain the optimizer statistics manually.
Gathering Optimizer Statistics Automatically
Oracle 10g gathers and maintains optimizer statistics using the GATHER_STATS_JOB job. This job is
automatically created when you create a database. The GATHER_STATS_JOB job is managed by the
Scheduler, which runs this job when the MAINTENANCE_WINDOW_GROUP window group is opened. This
window group is created at the time you create a database and contains two windows, WEEKEND_WINDOW
and WEEKNIGHT_WINDOW. By default, the WEEKNIGHT_WINDOW window opens every weekday, Monday
through Friday, at 10:00 P.M. for eight hours, and the WEEKEND_WINDOW window opens all day each
weekend day, Saturday and Sunday.
The GATHER_STATS_JOB job calls the GATHER_DATABASE_STATS_JOB_PROC procedure in the

DBMS_STATS package to gather optimizer statistics. The GATHER_DATABASE_STATS_JOB_PROC
procedure collects statistics on a database object in two scenarios:
• when the database object has no previously-gathered statistics
• when the gathered statistics for the database object are stale because more than 10 percent of
the rows in the database object have been modified
To gather optimizer statistics automatically, the value of the STATISTICS_LEVEL initialization parameter
must be set to TYPICAL or ALL.
110
Automatic gathering of optimizer statistics is enabled by default when you create a new database or
upgrade an existing database from a prior release. To disable automatic gathering of optimizer statistics,
run the following command at the SQL prompt:
SQL> EXEC DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
Gathering Optimizer Statistics Manually
You should gather optimizer statistics manually if the data in a database is frequently updated. This
ensures that optimizer statistics represent the current state of a database. You must gather optimizer
statistics manually in the following conditions:
• when a table is bulk loaded, because bulk loading often increases the size of a table by 10
percent or more
• when using external tables for data storage or retrieval
• when collecting system statistics
• when collecting statistics on fixed objects, such as dynamic performance tables
You can gather optimizer statistics manually by using the following procedures in the DBMS_STATS
package:
• GATHER_INDEX_STATS – Used to collect optimizer statistics for indexes.
• GATHER_TABLE_STATS – Used to collect optimizer statistics for tables, and the columns in and
indexes on the tables.
• GATHER_SCHEMA_STATS – Used to collect optimizer statistics for all the objects in a schema.
• GATHER_DICTIONARY_STATS – Used to collect optimizer statistics for all dictionary objects.
• GATHER_DATABASE_STATS – Used to collect optimizer statistics for all the objects in a database.
• GATHER_FIXED_OBJECTS_STATS – Used to collect optimizer statistics on fixed objects.
Managing Optimizer Statistics
Managing optimizer statistics includes locking and restoring the previous optimizer statistics. You can lock
optimizer statistics for a table, or for all tables of a schema, if you do not want to change the optimizer
statistics for them. You cannot change the locked optimizer statistics until you unlock them.
Locking Optimizer Statistics
You can lock optimizer statistics for a table using the LOCK_TABLE_STATS procedure of the
DBMS_STATS package. When you lock the optimizer statistics for a table, all the optimizer statistics that
are dependent on the table, such as column and index statistics, are also locked. The
LOCK_TABLE_STATS procedure accepts two arguments, ownname and tabname. The ownname
argument specifies the name of the owner of the table for which the optimizer statistics will be locked. The
111
tabname argument specifies the name of the table for which you want to lock the optimizer statistics. To
lock the optimizer statistics for the TABLE1 table owned by the SCOTT user, run the following command at
the SQL prompt:
SQL> EXEC DBMS_STATS.LOCK_TABLE_STATS ('SCOTT','table1');
You can unlock the optimizer statistics for a table using the UNLOCK_TABLE_STATS procedure. To unlock
the optimizer statistics for the TABLE1 table, run the following command at the SQL prompt:
SQL> EXEC DBMS_STATS.UNLOCK_TABLE_STATS ('SCOTT','table1');
You can lock optimizer statistics for all the tables of a schema using the LOCK_SCHEMA_STATS procedure
in the DBMS_STATS package. This procedure accepts the owner name of the schema you want to
optimize and locks the optimizer statistics for all the tables of the specified schema. To lock the optimizer
statistics for all the tables in the HR schema, run the following command at the SQL prompt:
SQL> EXEC DBMS_STATS.LOCK_SCHEMA_STATS ('HR');
You can unlock optimizer statistics for all the tables of a schema using the UNLOCK_SCHEMA_STATS
procedure in the DBMS_STATS package. To unlock the optimizer statistics for all the tables of the HR
schema, issue the following command at the SQL prompt:
SQL> EXEC DBMS_STATS.UNLOCK_SCHEMA_STATS ('HR');
You can view the database objects for which optimizer statistics have been locked by querying the
DBA_TAB_STATISTICS view. To query the DBA_TAB_STATISTICS view, run the following statement at
the SQL prompt:
SQL> SELECT owner, table_name

2 FROM dba_tab_statistics
3 WHERE stattype_locked = 'ALL';
OWNER TABLE_NAME
------------------------------ ------------------------------
HR REGIONS
HR COUNTRIES
HR LOCATIONS
HR DEPARTMENTS
HR JOBS
HR EMPLOYEES
HR JOB_HISTORY
7 rows selected.
112
Restoring Optimizer Statistics
When optimizer statistics in the data dictionary are modified, Oracle 10g saves the previous optimizer
statistics for future reference. The previous optimizer statistics are useful when the new optimizer
statistics affect the performance of SQL queries and the query optimizer generates sub-optimal query
execution plans to execute these SQL queries. You can restore optimizer statistics using the RESTORE
procedures of the DBMS_STATS package. Each RESTORE procedure accepts a timestamp as an
argument and restores the optimizer statistics to the specified timestamp. The following are the
procedures of the DBMS_STATS package to restore various types of optimizer statistics:
• RESTORE_DATABASE_STATS – Restores the statistics of all the tables in a database to a

specified timestamp.
• RESTORE_DICTIONARY_STATS – Restores the statistics of all the dictionary tables to a specified

timestamp.
• RESTORE_FIXED_OBJECTS_STATS – Restores the statistics of all the fixed tables in a database

to a specified timestamp.
• RESTORE_SCHEMA_STATS – Restores the statistics of all the tables of a schema to a specified

timestamp.
• RESTORE_SYSTEM_STATS – Restores the system statistics to a specified timestamp.
• RESTORE_TABLE_STATS – Restores the statistics of a particular table and indexes and columns
associated with the table to a specified timestamp.
You can also view the time when optimizer statistics were modified. The following are the views that
display the time of modifications made to optimizer statistics:
• DBA_OPTSTAT_OPERATIONS – Displays the history of statistics operations performed at the

database and schema levels by using the DBMS_STATS package.
• DBA_TAB_STATS_HISTORY – Displays the optimizer statistics at the table level.
For example, to query the DBA_TAB_STATS_HISTORY view to display the time when the statistics for the
TABLE1 table were modified, run the following statement at the SQL prompt:
SQL> SELECT stats_update_time

2 FROM dba_tab_stats_history
2 WHERE ownder = 'SCOTT' AND table_name = 'TABLE1';
You can also view the oldest timestamp for which optimizer statistics are available. To view the oldest
timestamp, run the following command at the SQL prompt:
SQL> EXEC DBMS_STATS.GET_STATS_HISTORY_AVAILABILITY;
113
By default, optimizer statistics are purged from the AWR every 31 days. The period after which optimizer
statistics are purged from the AWR is called the retention period. You can view the current retention
period by executing the GET_STATS_HISTORY_RETENTION procedure. To view the current retention
period, run the following statement at the SQL prompt:
SQL> SELECT DBMS_STATS.GET_STATS_HISTORY_RETENTION FROM DUAL;
You can also change the retention period using the ALTER_STATS_HISTORY_RETENTION procedure.
This procedure accepts an integer value that specifies the retention period in days. To set the retention
period to sixty days, run the following command at the SQL prompt:
SQL> EXEC DBMS_STATS.ALTER_STATS_HISTORY_RETENTION(60);
Automatic Undo Retention Tuning

Oracle maintains the information to roll back the changes made to a database when database users
perform database transactions on the database. This information is called undo and is stored in an undo
tablespace. The information about the committed transactions is deleted from the undo tablespace and is
overwritten by the information about the new transactions that are not committed. However, you may
need the old undo information for long-running queries to undo the changes made by these queries. Undo
retention refers to the period of time that old undo information in an undo tablespace for long running
queries is retained.
Oracle 10g provides the ability to tune the undo retention period by collecting database usage statistics
and estimating the undo space required to successfully recover if a problem occurs.
You can change the retention period of undo information by modifying the value of the UNDO_RETENTION
parameter. This parameter specifies the lowest retention period, in seconds, for which the undo
information is retained in an undo tablespace. The default value of this parameter is 900. To change the
value of the UNDO_RETENTION parameter to 1800 seconds, run the following statement at the SQL
prompt:
SQL> ALTER SYSTEM SET UNDO_RETENTION = 1800;
If you set the value of the UNDO_RETENTION parameter to 0, Oracle 10g automatically tunes the undo
retention period of the current undo tablespace using 900 seconds as the retention period.
Retention Guarantee
Oracle 10g automatically tunes undo retention to avoid the Snapshot Too Old errors, but when you
perform resource-intensive Data Manipulation Language (DML) operations, undo retention is not ensured.
You can ensure undo retention by using the RETENTION GUARANTEE clause. You can use this clause
when you create the undo tablespace by using the CREATE UNDO TABLESPACE or CREATE DATABASE
statement.
You can also use the RETENTION GUARANTEE clause when you alter an undo tablespace using the
ALTER TABLESPACE statement. You can check whether or not undo retention is ensured for a tablespace
114
by querying the DBA_TABLESPACES view. To query this view, run the following statement at the SQL
prompt:
SQL> SELECT tablespace_name, retention

2 FROM dba_tablespaces;
TABLESPACE_NAME RETENTION
------------------------------ -----------
SYSTEM NOT APPLY
UNDOTBS1 NOGUARANTEE
SYSAUX NOT APPLY
TEMP NOT APPLY
USERS NOT APPLY
EXAMPLE NOT APPLY
6 rows selected.
After viewing the retention information, you can ensure undo retention for a tablespace, such as
UNDOTBS1, by running the following statement at the SQL prompt:
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
Understanding Advisory Framework

The advisory framework consists of server components, called advisors, which provide information about
the performance and resource utilization of an Oracle database. The following are the components of the
advisory framework:
• Automatic Database Diagnostic Monitor – Analyzes a database instance to identify the database
performance problems in the database instance.
• SQL Tuning Advisor – Provides advice for executing SQL statements using the best execution
plans.
• Segment Advisor – Provides recommendations on space-related issues.
• Undo Advisor – Helps determine undo retention and optimal size of an undo tablespace.
• Program Global Area (PGA) Advisor – Tunes PGA memory allocated to server processes. The
PGA advisor recommends the optimal value of the PGA_AGGREGATE_TARGET parameter.
• Memory Advisor – Determines the optimum size of the buffer cache and optimal shared pool of a
database instance.
• SQL Access Advisor – Analyzes a schema for a given workload and recommends indexes and
materialized views that can improve performance.
115
The DBMS_ADVISOR Package
The DBMS_ADVISOR package helps you to manage all the advisors in the advisory framework. The
following are the various procedures in the DBMS_ADVISOR package:
• CREATE_TASK – Creates a new advisor task.
• DELETE_TASK – Deletes an advisor task.
• EXECUTE_TASK – Executes a specified advisor task.
• CANCEL_TASK – Cancels the currently-executing advisor task.
• INTERRUPT_TASK – Stops the currently-executing advisor task.
• RESUME_TASK – Resumes an interrupted advisor task.
• RESET_TASK – Resets an advisor task to its original state.
• UPDATE_TASK_PARAMETERS – Changes the parameters of an advisor task.
• SET_TASK_PARAMETERS – Modifies a specified parameter passed by a database user to an

advisor task.
• MARK_RECOMMENDATION – Accepts, rejects, or ignores a recommendation.
• CREATE_FILE – Creates an external file from a Character Large Object (CLOB) variable.
• QUICK_TUNE – Analyzes and generates recommendations for a single SQL statement.
Note: You must have the ADVISOR privilege to use the procedures in the DBMS_ADVISOR package.
Advisor Views
You can view information about advisors using various views. Some of these views are as follows:
• DBA_ADVISOR_ACTIONS – Displays information about the actions associated with

recommendations in an Oracle database.
• DBA_ADVISOR_COMMANDS – Displays information about the statements used by all the advisors
to specify recommended actions for the problems generated in a database.
• DBA_ADVISOR_FINDINGS – Displays the results of analyses by all the advisors.
• DBA_ADVISOR_OBJECTS – Displays information about the database objects currently referenced

by all the advisors.
• DBA_ADVISOR_PARAMETERS – Displays the parameters, and their values, for the tasks related to
advisors.
• DBA_ADVISOR_USAGE – Displays usage information for each type of advisor.
116
• DBA_ADVISOR_TASKS – Displays information about the advisor tasks in a database.
SQL Tuning Advisor

The SQL Tuning Advisor feature of Oracle 10g optimizes the SQL statement tuning process
automatically. The SQL Tuning Advisor operates in two modes, normal and tuning. In normal mode, the
SQL Tuning Advisor compiles SQL statements and generates the execution plan in less than one second.
The SQL Tuning Advisor may not generate the optimal execution plan to optimize a SQL statement.
In tuning mode, the SQL Tuning Advisor takes several minutes to analyze a single SQL statement. The
tuning mode is used only for SQL statements that require large amounts of resources for execution. The
tuning mode generates a series of actions, along with their rationales and expected benefits, to produce a
significantly superior execution plan. The tuning mode provides recommendations that help improve the
performance of SQL statements.
Note: The SQL Tuning Advisor is called Automatic Tuning Optimizer (ATO) when it operates in tuning
mode.
The SQL Tuning Advisor accepts one or more SQL statements and provides suggestions to improve the
execution plan of SQL statements considering various factors such as CPU usage, I/O usage, and
temporary space usage. The input sources of the SQL Tuning Advisor are as follows:
• High-load SQL statements – Specify SQL statements that require a large amount of resources for
execution.
• ADDM – Acts as a primary input source for the SQL Tuning Advisor.
• Cursor cache – Provides the capability to identify and tune high-load SQL statements for the
statistics that are not yet available in the AWR.
• SQL Tuning Set – Consists of a set of user-defined SQL statements.
Types of Analyses of the SQL Tuning Advisor
The SQL Tuning Advisor performs the following four types of analyses to gather statistics and
recommend suggestions:
• Statistics analysis – Verifies every object in a SQL statement for missing and stale statistics and
recommends how to gather updated statistics. The gathered information is stored in a SQL
Profile.
• SQL profiling – Stores the statistics that ATO uses to generate an optimal execution plan for a
SQL statement. The SQL profiling creates a profile for a SQL statement using sampling, partial
execution, and execution history for the SQL statement. This analysis stores the profile for a SQL
statement in the data dictionary. When the SQL statement is executed again, the ATO includes
the profile of the SQL statement to create an optimal execution plan.
117
• Access path analysis – Analyzes one SQL statement at a time. The access path analysis also
provides statistics to ATO to determine whether or not creating one or more indexes can improve
the performance of the SQL statement.
• SQL structure analysis – Determines syntactic, semantic, or design problems related to a SQL
statement that may generate a poor execution plan. The SQL structure analysis also suggests
alternative coding methods for the SQL statement.
Implementing SQL Tuning Advisor Using Enterprise Manager Database Control
You can use the SQL Tuning Advisor to analyze a SQL statement before it is executed. Enterprise
Manager Database Control allows you to identify and tune the SQL statements using SQL Tuning
Advisor. To use SQL Tuning Advisor with Enterprise Manager Database Control, perform the following
steps:
2. Click the Performance tab.
3. Click the Top SQL link on the Performance page.
4. Click the Period SQL tab on the Top SQL page to display the Period SQL page. The Period
SQL page displays period SQL statements.
Note: Period SQL statements are SQL statements that are monitored for resources for a specific
time period.
5. Click the link for the SQL statement you want to analyze on the Period SQL page.
6. Click the Execution Plan tab on the SQL Details page to view the execution plan that will be
used to execute the specified SQL statement.
7. Click the Run SQL Tuning Advisor button to schedule an advisor job. The following are the
options on the Schedule Advisor page:
• Limited – Takes less than one second to complete the analysis process. The limited
scope does not include a SQL Profile in the analysis. The limited scope focuses only on
the high-load SQL statements.
• Comprehensive – Takes a longer time to finish the analysis process, depending on the
workload of a SQL statement. The comprehensive scope uses SQL Profile statistics to
analyze a SQL statement.
8. Select the Comprehensive option and click the OK button on the Schedule Advisor page to
submit the schedule for analysis. The Recommendations for SQL ID page is displayed after the
analysis is complete.
118
9. Click the Implement button to implement the selected recommendation. The SQL Tuning
Results Page is displayed. This page displays the confirmation message that the specified SQL
statement is tuned.
Implementing SQL Tuning Advisor Using the DBMS_SQLTUNE Package
You can also implement the SQL Tuning Advisor using PL/SQL procedures. The DBMS_SQLTUNE
package provides procedures to implement the SQL Tuning Advisor at the command-line interface. You
must have the ADVISOR privilege and the DBA role to use the DBMS_SQLTUNE package. The
DBMS_SQLTUNE package provides procedures for tuning a SQL statement. The commonly-used
procedures to implement the SQL Tuning Advisor are as follows:
• CREATE_TUNING_TASK – Creates a tuning task.
• EXECUTE_TUNING_TASK – Executes an existing tuning task.
• REPORT_TUNING_TASK – Displays the results of an executed tuning task.
• ACCEPT_SQL_PROFILE – Accepts and creates a SQL Profile recommended by a tuning task.
The DBMS_SQLTUNE package can also be used to manage SQL Profiles. To use the DBMS_SQLTUNE
package to manage SQL Profiles, you must have the CREATE ANY SQL_PROFILE, DROP ANY
SQL_PROFILE, or ALTER ANY SQL_PROFILE privileges.
119
Understanding Automatic Storage Management

Scope
• Describe Automatic Storage Management (ASM).
• Create an ASM instance.
• Start up and shut down an ASM instance.
• List the initialization parameters for an ASM instance.
• Describe different types of ASM filenames and how to execute SQL commands with ASM file names.
• Create and delete disk groups. Alter disk groups.
• Use RMAN to migrate a database to ASM.
Focused Explanation
Automatic Storage Management
Automatic Storage Management (ASM) is a storage management feature of Oracle 10g that helps you to
manage Oracle database files and simplify the database administration process. ASM distributes various
types of database files such as control files, datafiles, and log files, across groups of storage devices,
called disk groups. A disk group consists of multiple physical disks that are controlled by ASM as a single
unit. These physical disks are called ASM disks, and the files stored on these ASM disks are called ASM
files.
ASM files are created with names defined by ASM. You can also give alias names to ASM files, but you
must maintain a hierarchical directory structure for alias names. ASM also supports the use of failure
groups that store redundant copies of files stored in a disk group. A failure group consists of one or more
disks within a disk group that share a resource such as a disk controller. These failure groups are used to
provide fault tolerance.
Characteristics of an ASM Instance
The following are the characteristics of an ASM instance:
• Contains memory ranging from 60 MB to 100 MB.
• Contains the initialization parameter and password files.
• Uses operating system authentication. You can connect to an ASM instance by using the
SYS and SYSTEM user accounts and operating system authentication.
• Manages disk groups using the CREATE DISKGROUP, ALTER DISKGROUP, and
DROP_DISKGROUP statements.
120
An ASM instance does not have a data dictionary. Therefore, only users with the SYSDBA or SYSOPER
privileges can access the ASM instance. Users with the SYSDBA privileges can perform all operations,
such as creating disk groups, deleting disk groups, and adding and removing the disks from disk groups.
Users with the SYSOPER privileges can perform a limited set of operations. These operations are as
follows:
• starting and shutting down an ASM instance
• mounting and dismounting a disk group
• altering the status of a disk group to ONLINE or OFFLINE
• rebalancing a disk group
• performing integrity checking on a disk group
• accessing V$SAM_* dynamic performance views
Initialization Parameters for an ASM Instance
The following are the initialization parameters specific to an ASM instance:
• INSTANCE_TYPE – Specifies whether an instance is an ASM instance or a database instance.

This initialization parameter can accept one of the two values, ASM or RDBMS. The default value of
this initialization parameter is RDBMS, which indicates that the instance is a database instance.
You must set the value of this initialization parameter to ASM for an ASM instance.
• DB_UNIQUE_NAME – Specifies the unique name for a group of ASM instances in a cluster or on a
computer. The default value of the DB_UNIQUE_NAME initialization parameter is +ASM.
• ASM_POWER_LIMIT – Specifies an integer value that represents the speed for disk rebalancing.
The minimum value of this initialization parameter is 1, which represents the lowest speed for
disk rebalancing. The maximum value of this initialization parameter is 11, which represents the
highest speed for disk rebalancing. The default value of this initialization parameter is 1.
• ASM_DISKSTRING – Specifies one or more operating system-dependent strings, separated with

commas, which specify the disks that can be used to create disk groups. The default value of this
initialization parameter is NULL, which specifies that all the disks in an operating system-specific
location can be used to create disk groups.
• ASM_DISKGROUPS – Specifies the list of disk groups, separated with commas, to be mounted
automatically when an ASM instance is started. The default value of the ASM_DISKGROUPS
parameter is NULL, which specifies that no disk groups will be mounted automatically when the
ASM instance is started.
121
Creating and Connecting to an ASM Instance
To create and connect to an ASM instance on a Unix server, perform the following steps:
1. Create an init+ASM.ora file in the /tmp folder. The init+ASM.ora file contains the following
code fragment:
INSTANCE_TYPE=ASM
2. Run the following command at the Unix prompt to export the Oracle database System Identifier
(SID):
% EXPORT ORACLE_SID=+ASM
3. After the Oracle database SID is exported successfully, issue the following command at the SQL
prompt to connect to an Oracle database:
SQLPLUS / AS SYSDBA
4. Create a server parameter file (SPFILE) file by issuing the following statement at the SQL
prompt:
SQL> CREATE SPFILE FROM PFILE='/tmp/init+ASM.ora';
Starting Up and Shutting Down an ASM Instance
To start an ASM instance, the value of the INSTANCE_TYPE initialization parameter must be set to ASM.
You can use the STARTUP command along with the MOUNT option to start an ASM instance in the MOUNT
mode. The other options that you can use with the STARTUP command are as follows:
• NOMOUNT – Starts an ASM instance, but no ASM group is mounted at startup.
• FORCE – Restarts an ASM instance after shutting down the currently-running ASM instance.
Note: When you start up an ASM instance in the MOUNT mode, ASM disk groups, which are specified in
the ASM_DISKGROUPS initialization parameter, are mounted instead of a database.
If you do not specify any option with the STARTUP command, the ASM instance is started up in the MOUNT
mode.
You can shut down an ASM instance using the SHUTDOWN command. The options that you can use with
the SHUTDOWN command are as follows:
• NORMAL – Shuts down an ASM instance, but waits for all other connected ASM instances to
disconnect before shutting down the ASM instance.
• IMMEDIATE – Shuts down an ASM instance, but waits for any SQL statement that is being
currently executed to complete before shutting down the ASM instance. This mode does not wait
for any connected database instances to disconnect.
122
• TRANSACTIONAL – Shuts down an ASM instance, but waits for any transaction that is being
currently executed to complete before shutting down the ASM instance. This mode does not wait
for any connected database instances to disconnect.
• ABORT – Shuts down an ASM instance immediately without waiting for the connected database
instances to disconnect.
ASM File Types
ASM supports various types of files that may be required by a database, except the operating system-
executable files and administrative files. The administrative files not supported by ASM include trace, alert
log, backup, export, tar, audit, and core files.
Table 6-1 lists the types of files, and their default templates, supported by ASM:
File Type Default Templates
Archive log backup pieces BACKUPSET
Archive log files ARCHIVELOG
Auto backup AUTOBACKUP
Change tracking file CHANGETRACKING
Control files CONTROLFILE
Data Pump dumpset DUMPSET
Datafile backup pieces BACKUPSET
Datafile copy DATAFILE
Datafile incremental backup pieces BACKUPSET
Datafiles DATAFILE
Disaster recovery configurations DATAGUARDCONFIG
Flashback logs FLASHBACK
Redo log files ONLINELOG
SPFILE PARAMETERFILE
Temporary files TEMPFILE
Table 6-1: ASM File Types
123
ASM Filenames
ASM filenames can be in various formats. Some of these formats are used to refer to existing ASM files
and some are used to create new ASM files. The various formats of ASM filenames are as follows:
• fully-qualified ASM filename
• numeric ASM filename
• alias ASM filename
• alias ASM filename with template
• incomplete ASM filename
• incomplete ASM filename with template
Note: Templates are used to store the attributes of ASM files created in disk groups. Templates map
complex attribute specifications to a single name. For example, the ONLINELOG template provides the
striping and file redundancy attributes for all the redo log files.
Fully-Qualified ASM Filename
You can use a fully qualified ASM filename to reference existing ASM files. This filename is generated
automatically when you create an ASM file. The format for the fully-qualified ASM filename is as follows:
+diskgroup/databasename/file_type/tag.file.incarnation
The parameters in the above format are as follows:
• +diskgroup – Specifies the name of a disk group.
• databasename – Specifies the value of the DB_UNIQUE_NAME initialization parameter for the
database to which the current file belongs.
• file_type – Specifies the type of ASM file. This parameter can accept any one of the ASM file
types, which are:
o CONTROLFILE
o DATAFILE
o ONLINELOG
o ARCHIVELOG
o TEMPFILE
o BACKUPSET
o PARAMETERFILE
124
o DATAGUARDCONFIG
o FLASHBACK
o CHANGETRACKING
o DUMPSET
o XTRANSPORT
o AUTOBACKUP
• tag – Specifies the type-specific information about the current file. For example, if the value of
the file_type parameter is CONTROLFILE, the type-specific information will specify whether
the control file is a current control file or a backup control file.
• file.incarnation – Ensures the uniqueness of the name of the current file.
An example of a fully-qualified ASM filename is as follows:
+dbgroup1/example/datafile/ctf.234.1
Numeric ASM Filename
You can use a numeric ASM filename to reference existing files. The numeric ASM filename is derived
from a fully-qualified ASM filename. The format for a numeric ASM filename is as follows:
+diskgroup.file.incarnation
An example of a numeric ASM filename is as follows:
+dbgroup1.345.12
Alias ASM Filename
You can use an alias ASM filename to reference existing files and create new ASM files. An alias ASM
filename starts with the disk group name to which the file belongs. You can specify a string after the disk
group name to indicate the rest of the alias ASM filename. An example of an alias ASM filename is as
follows:
+dbgroup1/dir1/myfile.dbf
Alias Filename with Template
You can use an alias filename with template to create ASM files. The format for the alias filename with
template is as follows:
+diskgroup(template)/alias
125
In the above format, the parameters are as follows:
• +diskgroup – Specifies the name of a disk group.
• template – Specifies the name of the ASM file template.
• alias – Specifies the alias name of the ASM filename.
Incomplete ASM Filename
You can use an incomplete ASM filename to create ASM files. ASM uses a default template to determine
the attributes of an ASM file, when you specify an incomplete filename while creating the ASM file. The
format for the incomplete ASM filename is as follows:
+diskgroup
An example of an incomplete ASM filename is as follows:
+dbgroup1
Incomplete ASM Filename with Template
You can use an incomplete ASM filename with template to create ASM files. When you specify an
incomplete ASM file name while creating an ASM file, ASM uses the template specified with the filename
instead of a default template to determine the attributes of the ASM file. The format of the incomplete
ASM filename with template is as follows:
+diskgroup(template)
An example of an incomplete ASM filename with template is as follows:
+dbgroup1(datafile)
Using ASM Filenames in SQL Statements
You can use ASM filenames in the file specification clause of SQL statements. For example, to create a
tablespace using an incomplete ASM filename, run the following statement at the SQL prompt:
SQL> CREATE TABLESPACE ts1 DATAFILE '+dbgroup1' SIZE 100M;
In the above statement, a tablespace, TS1, is created. The datafile in the ts1 tablespace belongs to the
dbgroup1 disk group. The size of the datafile of the ts1 tablespace is 100 MB.
Working with Disk Groups

You can use ASM to manage files in a database by creating, deleting, and altering disk groups in the
database. You can also add or drop disks from a disk group even when a database is running.
126
Creating Disk Groups
You can create a disk group by using the CREATE DISKGROUP statement. While creating a disk group,
you must assign a name to the disk group that you want to create and specify the disks that you want to
be included in the disk group. ASM creates the names of the disks in a disk group that you can use in
SQL statements to refer to the disks. However, you can also specify names for the disks in a disk group
by specifying the NAME clause with the CREATE DISKGROUP statement.
While creating a disk group, you can specify the failure groups to which the disks in the disk group
belong, and the redundancy level for the disk group. You can specify one of the following three levels of
redundancy:
• NORMAL REDUNDANCY – Requires at least two failure groups and provides two-way mirroring to a
disk group.
• HIGH REDUNDANCY – Requires at least three failure groups and provides three-way mirroring to
a disk group.
• EXTERNAL REDUNDANCY – Does not provide any mirroring for the disks that are implemented
using the Redundant Array of Independent Disks (RAID) or hardware mirroring.
ASM automatically determines the size of each disk in a disk group. However, you can also specify the
amount of space used on each disk by specifying the SIZE clause with the CREATE DISKGROUP
statement.
Run the following statement at the SQL prompt to create a disk group, DISK_GP1, with two failure
groups:
SQL> CREATE DISKGROUP disk_gp1 NORMAL REDUNDANCY

2 FAILGROUP fail_gp1 DISK
3 '/dev/disk_a1' NAME da1,
5 FAILGROUP fail_gp2 DISK
6 '/dev/disk_b1' NAME db1,
7 '/dev/disk_b2' NAME db2;
In the above statement, the DISK_GP1 disk group is created, with four disks and two failure groups. The
above statement assumes that the value of the ASM_DISKSTRING initialization parameter is set to
'/dev/*'.
You can view the created disk group using the V$ASM_DISKGROUP view. This view displays the new disk
group along with the existing disk groups. To view the disk groups, run the following statement at the SQL
prompt:
SQL> SELECT group_number,name

2 FROM V$ASM_DISKGROUP;
127
You can view the names of the disks, the disk groups of the disks, and the failure groups assigned to the
disks in a disk group by querying the V$ASM_DISK view. Run the following statement at the SQL prompt
to query the V$ASM_DISK view:
SQL> SELECT group_number, disk_number, name, failgroup, create_date, path

2 FROM v$asm_disk;
Altering Disk Groups
You can alter a disk group without recreating the disk group by using the ALTER DISKGROUP statement.
You can alter a disk group by adding a new disk to the disk group, deleting a disk from the disk group, or
resizing the disks in the disk group.
Adding Disks to a Disk Group
You can use the ADD clause of the ALTER DISKGROUP statement to add disks to a disk group. You can
also add a failure group to a disk group by using the ADD clause. Run the following statement at the SQL
prompt to add two disks to the disk_gp1 disk group:
SQL> ALTER DISKGROUP disk_gp1 DISK

3 '/dev/disk_a4' NAME da4;
Alternatively, you can add the DA3 and DA4 disks to the DISK_GP1 disk group by running the following
SQL> ALTER DISKGROUP disk_gp1 DISK

2 '/dev/disk_a*';
One disk can only be a member of one disk group. However, you can force a disk in one disk group to be
moved to another disk group that you are creating by using the FORCE clause. To perform this operation,
the original disk group must not be mounted, and the disk that you want to move from one disk group to
another must have a header. For example, to move a disk, DA3, which is already a member of the
DISK_GP1 disk group, to the DISK_GP2 disk group, run the following statement at the SQL prompt:
SQL> ALTER DISKGROUP disk_gp2 ADD DISK da3 FORCE;
Resizing Disks in Disk Groups
You can use the RESIZE clause of the ALTER DISKGROUP statement to resize the disks in a disk group.
You can resize all the disks in a disk group, resize specific disks in a disk group, or resize all the disks in
a specific failure group by using the RESIZE clause.
128
For example, to change the size of the DA1 disk in the DISK_GP1 disk group, run the following statement
at the SQL prompt:
SQL> ALTER DISKGROUP disk_gp1

2 RESIZE DISK da1 SIZE 120G;
Run the following statement at the SQL prompt to resize all the disks in the DISK_GP1 disk group:

2 RESIZE ALL SIZE 150G;
Run the following statement at the SQL prompt to resize all the disks in the FAIL_GP1 failure group of the
DISK_GP1 disk group:

2 RESIZE DISKS IN FAILGROUP fail_gp1 SIZE 100G;
Undropping Disks from Disk Groups
You can use the UNDROP DISKS clause of the ALTER DISKGROUP statement to cancel pending drops of
disks from a disk group. Pending drops refer to the SQL statements that are currently executing to drop
disks from a disk group. The UNDROP DISKS clause cannot undrop a disk if the disk has already been
completely dropped or a disk has been dropped using the FORCE clause. Run the following statement to
cancel pending drops of disks from the DISK_GP1 disk group:
SQL> ALTER DISKGROUP disk_gp1 UNDROP DISKS;
Rebalancing a Disk Group
ASM maintains the I/O balance by moving files from existing disks to the new disk, whenever a new disk
is added to a disk group. When you delete a disk from a disk group, ASM maintains the I/O balance by
moving files from the disk that you delete to other existing disks in the disk group. This process of
maintaining the I/O balance is called rebalancing. Whenever you add or drop a disk from a disk group, the
rebalancing process starts automatically. You can also rebalance disk groups manually using the
REBALANCE clause of the ALTER DISKGROUP statement. To rebalance a disk group, disk_gp1,
manually, issue the following statement at the SQL prompt:
SQL> ALTER DISKGROUP disk_gp1 REBALANCE POWER 8;
In the above statement, 8 represents the speed of the rebalancing process.
The speed of the rebalancing process, specified by using the REBALANCE clause, overrides the speed
specified by using the ASM_POWER_LIMIT initialization parameter. The speed of the rebalancing process
cannot exceed the speed specified by using the ASM_POWER_LIMIT initialization parameter.
129
You can monitor the progress of the rebalancing process by querying the V$ASM_OPERATION view. Run
the following statement at the SQL prompt to view the status of the rebalancing process:
SQL> SELECT group_number, operation, state, power, actual, sofar, est_work,

2 est_rate, est_minutes
3 FROM v$asm_operation;
Deleting a Disk from a Disk Group
You can use the DROP DISK clause of the ALTER DISKGROUP statement to delete a disk from a disk
group. To delete the DA3 disk from the DISK_GP1 disk group, run the following statement at the SQL
prompt:
SQL> ALTER DISKGROUP disk_gp1 DROP DISK da3;
Mounting Disk Groups
When an ASM instance starts up, the disk groups specified in the ASM_DISKGROUPS initialization
parameter are automatically mounted. These disk groups are automatically dismounted when the ASM
instance shuts down. You can also mount disk groups manually using the MOUNT clause of the ALTER
DISKGROUP statement. To mount the DISK_GP1 disk group manually, run the following statement at the
SQL prompt:
SQL> ALTER DISKGROUP disk_gp1 MOUNT;
Dismounting Disk Groups
You can dismount disk groups manually using the DISMOUNT clause of the ALTER DISKGROUP
statement. To dismount the DISK_GP1 disk group manually, run the following statement at the SQL
prompt:
SQL> ALTER DISKGROUP disk_gp1 DISMOUNT;
To dismount all the disk groups that are currently mounted for an ASM instance, run the following
SQL> ALTER DISKGROUP ALL DISMOUNT;
Checking Internal Consistency of Disk Groups
Internal consistency of disk groups refers to the uniformity of metadata information in various disk groups.
You can use the CHECK clause of the ALTER DISKGROUP statement to check the internal consistency of
disk groups. You can check the internal consistency for specific files, disks, or failure groups in a disk
group. When errors are detected in files, ASM tries to rectify those errors by default. You can also prevent
ASM from rectifying the errors by specifying the NOREPAIR clause with the ALTER DISKGROUP
statement.
130
For example, to check the internal consistency in all the disks in the DISK_GP1 disk group, run the
SQL> ALTER DISKGROUP disk_gp1 CHECK ALL;
Deleting Disk Groups
You can delete a disk group by using the DROP DISKGROUP statement. You can delete the files on a disk
group along with the disk group by specifying the INCLUDING CONTENTS clause with the DROP
DISKGROUP statement. The default clause of the DROP DISKGROUP statement is EXCLUDING CONTENTS,
which prevents you from deleting a disk group if the disk group contains any files. The following
conditions must be met to delete a disk group:
• The ASM instance, in which the disk group is present, must be mounted.
• The disk group must be mounted and all the files on the disk group must be closed.
To delete the DISK_GP1 disk group, run the following statement at the SQL prompt:
SQL> DROP DISKGROUP disk_gp1 INCLUDING CONTENTS;
Migrating a Database to ASM
You must migrate a database to ASM to use the features of ASM for the database. You can use
Recovery Manager (RMAN) to migrate a database to ASM. To migrate a database to ASM, perform the
following steps:
1. Run the following statement at the SQL prompt to disable change tracking:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
2. Run the following command at the SQL prompt to shut down the database you want to migrate to
ASM in the IMMEIDIATE mode:
SQL> SHUTDOWN IMMEDIATE
3. Modify the parameter files of the target database as follows:
• Set the DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n initialization

parameters to the required ASM disk groups.
• Remove the CONTROL_FILES initialization parameter from the SPFILE file.
4. Run the following command at the RMAN prompt to start the database in NOMOUNT mode:
RMAN> STARTUP NOMOUNT
5. Restore the control file to the new ASM disk location from the old location by running the
RESTORE CONTROLFILE command at the RMAN prompt. The syntax to restore the control file is
as follows:
131
RESTORE CONTROLFILE FROM old_control_file_name;
6. Run the following statement at the RMAN prompt to mount the database:
RMAN> ALTER DATABASE MOUNT;
7. Run the following command at the RMAN prompt to create a backup copy of the database in the
DISK_GP1 disk group:
RMAN> BACKUP AS COPY DATABASE FORMAT 'disk_gp1';
8. Run the following command at the RMAN prompt to transfer all the datafiles from the old location
to the new ASM location:
RMAN> SWITCH DATABASE TO COPY;
9. After all the datafiles from the old database location are migrated to the new ASM location, run
the following statement at the RMAN prompt to open the database:
RMAN> ALTER DATABASE OPEN;
10. Delete the old redo log files and create the new redo log files in ASM by running the ALTER
DATABASE ADD LOGFILE statement at the SQL prompt. The syntax to create new redo log files
is as follows:
ALTER DATABASE ADD LOGFILE GROUP group_number(name_redologfile)SIZE

size
In the above syntax, the parameters are as follows:
• group_number – Specifies the number of the ASM disk group to be created. This ASM
group contains the redo log file to be created.
• name_redologfile – Specifies the name of the redo log file you want to create.
• size – Specifies the size of the new redo log file. You must add the K or M suffix to this
parameter to specify the size of the new redo log file in KB or MB, respectively.
11. Run the following statement at the SQL prompt to enable change tracking:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
132
Understanding Automatic Memory Management

Scope
• Describe the components of the System Global Area (SGA).
• Use Automatic Shared Memory Management (ASMM) to configure the SGA.
• Describe Program Global Area (PGA).
• Implement Automatic PGA Memory Management (APMM) by using the PGA_AGGREGATE_TARGET

Focused Explanation
Components of System Global Area
The System Global Area (SGA) represents a set of memory blocks that are shared among all the users
connected to an Oracle database. Memory is allocated to the SGA when an Oracle instance is initiated
and de-allocated when the Oracle instance shuts down. The components of the SGA are as follows:
• Shared pool – Represents the memory area that stores data dictionary cache and library cache.
The data dictionary cache contains structural and data information such as the names of data
files and segments, the location of extents, and the description of tables and privileges. The
library cache stores the execution plan of a SQL query and a parse tree of commonly-used SQL
statements. The shared pool is a required component of the SGA.
• Database buffer cache – Represents the memory area that caches the most recently-used
datafiles. This component is a required component of the SGA. The database buffer cache
contains three types of buffers:
o dirty buffers – Contain data that has been modified but not written to the disk.
o free buffers – Contain data that has been read from the disk.
o pinned buffers – Represent the buffer blocks that are currently being accessed.
o cleaned buffers – Represent the buffers that are currently not being accessed .
• Redo log buffer – Represents the memory area that stores information about database
transactions. This component of the SGA contains information about the changes made to data in
a database. The information in this component is used for database recovery. The redo log buffer
is a required component of an Oracle instance.
• Java pool – Represents an optional component of the SGA that stores information about the most
recently-used application code and objects of Java. The Java pool is used when you work with a
Java application that interacts with an Oracle database.
133
• Large pool – Represents an optional component of the SGA that caches information for database
operations such as database backup and restore. This component of the SGA also caches
message buffers for parallel queries.
• Streams pool – Represents an optional component of the SGA that stores information about
queued message requests when the advanced queuing option of Oracle is used to process
message requests.
Note: Oracle uses the Least Recently Used (LRU) algorithm to mange the shared pool and database
buffer cache. This algorithm identifies the least recently-used SQL statements or data blocks and uses
their space to store new SQL statements or data blocks.
Using Automatic Shared Memory Management

Oracle 10g provides the Automatic Shared Memory Management (ASMM) feature to resize the SGA
components that affect the performance of an Oracle database. To enable the ASMM feature for an
Oracle 10g database, you must set the value of the SGA_TARGET initialization parameter to a value other
than its default value of NULL.
ASMM automatically sizes the database buffer cache, shared pool cache, large pool, and Java pool
components of the SGA. These components of the SGA are known as auto-tuned components. If ASMM
for an Oracle 10g database is not enabled, auto-tuned components of the SGA are sized according to the
values of the DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, and JAVA_POOL_SIZE
initialization parameters, respectively. If ASMM is enabled, the values of these initialization parameters
specify the minimum size of the auto-tuned SGA components.
You can also configure ASMM for an Oracle 10g database by using Enterprise Manager Database
Control. To configure ASMM by using Enterprise Manager Database Control, perform the following steps:
1. Open Enterprise Manager Database Control in the Web browser.
3. Click the Memory Parameters link on Administration tab page.
4. Click the SGA tab on the Memory Parameters page.
5. Click the Enable button to enable ASMM. The Enable Automatic Shared Memory
Management page is displayed.
6. Specify the size of the SGA in the Total SGA Size for Automatic Shared Memory
Management text box.
7. Click the OK button to make the changes effective.
134
Introducing Program Global Area

A Program Global Area (PGA) is a nonshared memory area that stores data and control information
about a server process. A PGA is created for a server process when the server process starts. Only the
server process for which the PGA is created can access the PGA. A PGA is divided into two parts:
• Private SQL area – Stores runtime memory structures and information about bind variables in
SQL and PL/SQL statements. There is a separate private SQL area for each session in a
database. The private SQL area is divided into two parts:
o Persistent area – Represents the memory area that contains information about bind
variables. This area is freed when the cursor using the bind variables is closed.
o Run-time area – Represents the area that is freed when the execution of SQL statements
is complete.
• SQL work areas – Represent the memory areas in which complex SQL operations, such as
sorting and joining of tables, are performed. For example, when you sort the data in a table, a
specific SQL work area, called a sort work area, is used for sorting.
Using Automatic PGA Memory Management

The Automatic PGA Memory Management (APMM) feature of Oracle 10g enables you to specify a single
memory area allocation for an Oracle database instance. In an Oracle database instance, APMM
allocates memory to SQL work areas of sessions. Oracle uses the PGA_AGGREGATE_TARGET
initialization parameter to configure the APMM functionality for an Oracle 10g database instance. APMM
is enabled by default for an Oracle 10g database instance.
Note: The default value of the PGA_AGGREGATE_TARGET initialization parameter of an Oracle 10g
database instance is 10MB, or 20 percent of the SGA size of the database instance, whichever is larger.
Prior to Oracle 10g, Oracle used the values of the SORT_AREA_SIZE, HASH_AREA_SIZE,
BITMAP_MERGE_AREA_SIZE, and CREATE_BITMAP_AREA_SIZE initialization parameters for allocating
memory to PGA. In Oracle 10g, these historical PGA parameters are used in conjunction with the
WORKAREA_SIZE_POLICY initialization parameter to define the working of APPM. The following are the
two values of the WORKAREA_SIZE_POLICY initialization parameter that define the working of APPM:
• AUTO – Allows APPM to allocate memory for SQL work areas of sessions as needed and does
not use historical PGA parameters. AUTO is the default value of the WORKAREA_SIZE_POLICY
• MANUAL – Allows APPM to allocate memory for SQL work areas of sessions according to values
of historical PGA parameters.
135
You can change the value of the PGA_AGGREGATE_TARGET initialization parameter in the initialization
parameter file. You can also use the ALTER SYSTEM statement to change the value of the
PGA_AGGREGATE_TARGET initialization parameter. For example, issue the following statement at the SQL
prompt to change the value of the PGA_AGGREGATE_TARGET initialization parameter to 2 GB:
SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET=2G;
136
Review Checklist: Understanding Automatic Database, Storage, and

Memory Management: Oracle 10g Administration II
Describe the purpose of AWR.
Use the ASH.
Manage server-generated alerts.
Use automatic optimizer statistics collection.
Describe how to use ADDM.
Describe undo retention tuning.
Describe the advisory framework.
Describe the SQL Tuning Advisor.
Describe ASM.
Create an ASM instance.
Start up and shut down an ASM instance.
List the initialization parameters for an ASM instance.
Describe different types of ASM filenames and how to execute SQL commands with ASM
filenames.
Create and delete disk groups.
Alter disk groups.
Use RMAN to migrate a database to ASM.
Describe the components of the SGA.
Use ASMM to configure the SGA.
Describe the PGA.
Implement APMM by using the PGA_AGGREGATE_TARGET initialization parameter.
137
Managing Resources and Automating

Tasks: Oracle 10g Administration II
138
Managing Resources Using the Database Resource Manager

Scope
• Introduce and configure the Database Resource Manager.
• Create and manage resource consumer groups.
• Describe how to create and manage resource plans.
• Create and manage resource plan directives.
Focused Explanation
The Database Resource Manager is a tool that allocates and manages resources in the Oracle database.
The Database Resource Manager ensures that system resources, such as CPU and memory resources,
are appropriately allocated to the users of the database, regardless of the database load. The elements of
the Database Resource Manager are as follows:
• Resource consumer groups
• Resource plans
• Resource plan directives
Configuring the Database Resource Manager
Before creating and activating any element of the Database Resource Manager, you must configure the
Database Resource Manager by creating a pending area. A pending area is an area in a database in
which you can define, alter, and validate the modifications made to the elements of the Database
Resource Manager.
Creating a Pending Area
You can create a pending area by using the CREATE_PENDING_AREA procedure. To create a pending
area, run the following statement at the SQL prompt:
SQL> EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
Validating Modifications
You can validate the modifications, such as creation or modification of an element of the Database
Resource Manager, in the pending area by using the VALIDATE_PENDING_AREA procedure. The
VALIDATE_PENDING_AREA procedure checks whether or not all the changes made to the pending area
are valid. To validate the modifications made to the pending area, run the following statement at the SQL
prompt:
SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA;
139
Activating Modified Elements of the Database Resource Manager
You must activate the modified elements of the Database Resource Manager before using the modified
elements. You can activate the modified elements of the Database Resource Manager by using the
SUBMIT_PENDING_AREA procedure. To activate the modified elements of the Database Resource
Manager, run the following statement at the SQL prompt:
SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA;
Clearing a Pending Area
You can clear the pending area to remove the changes to the elements of the Database Resource
Manager by using the CLEAR_PENDING_AREA procedure. To clear the pending area, run the following
SQL> EXEC DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA;
Working with Resource Consumer Groups

A resource consumer group refers to a group of database users or sessions that consume similar
resources. You can create, update, and delete resource consumer groups by using the procedures of the
DBMS_RESOURCE_MANAGER package.
Creating Resource Consumer Groups
You can create resource consumer groups by using the CREATE_CONSUMER_GROUP procedure in the
DBMS_RESOURCE_MANAGER package. The commonly used attributes of the CREATE_CONSUMER_GROUP
procedure are as follows:
• CONSUMER_GROUP – Specifies the name of the resource consumer group to be created.
• CPU_MTH – Specifies the method used to allocate CPU resources to the sessions in a resource
consumer group. The CPU_MTH attribute accepts one of the two values ROUND_ROBIN or
RUN_TO_COMPLETION. The ROUND_ROBIN value, which is the default value of the CPU_MTH
attribute, specifies that the CPU resources are allocated to the sessions in a round-robin
schedule. A round-robin schedule allocates CPU resources to the sessions for equal intervals of
time. The RUN_TO_COMPLETION method specifies that the active sessions in a resource
consumer group are allocated the CPU resources before they are allocated to inactive sessions.
• COMMENT – Stores a resource consumer group description.
The following is an example of creating a resource consumer group by using the

CREATE_CONSUMER_GROUP procedure. To create the rc1 resource consumer group, which uses the
round-robin schedule to allocate CPU resources among sessions, run the following statement at the SQL
prompt:
140
SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
3 CONSUMER_GROUP => 'rc1',
4 CPU_MTH => 'ROUND_ROBIN'
5 COMMENT => 'This procedure creates a consumer group');
6 END;
Updating a Resource Consumer Group
You can update the values of the CPU_MTH and COMMENT attributes of a resource consumer group by
using the UPDATE_CONSUMER_GROUP procedure. The following attributes apply to the
UPDATE_CONSUMER_GROUP procedure:
• CONSUMER_GROUP – Specifies the name of the resource consumer group to be updated
• NEW_CPU_MTH – Specifies the new allocation method used to allocate the CPU resources to
sessions or database users of a resource consumer group
• NEW_COMMENT – Stores a description of the resource consumer group modification
The following is an example of updating a resource consumer group by using the

UPDATE_CONSUMER_GROUP procedure. To update the allocation method used to allocate the CPU
resources to sessions or database users of the RC1 resource consumer group, run the following
statements at the SQL prompt:
SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.UPDATE_CONSUMER_GROUP(
3 CONSUMER_GROUP => 'rc1',
4 NEW_CPU_MTH =>'RUN_TO_COMPLETION');
5 END;
Deleting a Resource Consumer Group
You can delete a resource consumer group by using the DELETE_CONSUMER_GROUP procedure. This
procedure accepts the name of the resource consumer group to be deleted as an attribute. For example,
to delete the RC1 resource consumer group, run the following statement at the SQL prompt:
SQL> EXEC DBMS_RESOURCE_MANAGER.DELETE_CONSUMER_GROUP('rc1');
Assigning Resource Consumer Groups to Sessions
You must assign a resource consumer group to a session to enable the session to utilize the resources
available to the resource consumer group. You can configure the Database Resource Manager to
automatically assign resource consumer groups to a session. To assign resource consumer groups to a
session, you must set the values of the session attributes. There are two types of session attributes, login
and run-time. The login attributes are valid at the session login time. Login attributes determine the initial
resource consumer group assigned to a session. The run-time attributes are valid after the database user
has logged in to the database. After logging in to the database, based on the run-time attributes, you can
change the resource consumer group assigned to a session.
141
To configure the Database Resource Manager so that it automatically assigns resource consumer groups
to sessions, you must create mappings that map the resource consumer groups to the session attributes.
These mappings are called consumer group mappings.
Creating Consumer Group Mappings
You can create consumer group mappings by using the SET_CONSUMER_GROUP_MAPPING procedure.
The commonly used attributes of the SET_CONSUMER_GROUP_MAPPING procedure are as follows:
• CONSUMER_GROUP – Specifies the name of the resource consumer group for which consumer
group mappings are being created.
• ATTRIBUTE – Specifies the login or run-time session attribute that is being mapped. The
ATTRIBUTE attribute can accept one of the following values:
o CLIENT_MACHINE – Specifies the name of the computer from which a client has
logged on to the database.
o CLIENT_OS_USER – Specifies the operating system user name of the client that is
logged on to the database.
o CLIENT_PROGRAM – Specifies the name of the client program used to log in to the
database.
o MODULE_NAME – Specifies the name of the module in the application currently being
executed.
o MODULE_NAME_ACTION – Specifies the current module and the action being

performed by the current database user.
o SERVICE_NAME – Specifies the name of the service used by a client to establish a

connection with the database.
o ORACLE_USER – Specifies the user name that enables a database user to log in to the
database.
o SERVICE_MODULE – Specifies the name of the service used by a client to establish a

connection with the database and the name of the module that runs in the current
application. This attribute is specified in the SERVICE_NAME.MODULE_NAME format.
For example, if the service name is oracle and the module name is increase, the
SERVICE_MODULE name will be oracle.increase.
o SERVICE_MODULE_ACTION – Specifies the name of the service used by a client to

establish a connection to the database, the module that runs in the current application,
and the action performed by the database user. This attribute uses the
SERVICE_NAME.MODULE_NAME.ACTION_NAME format. For example, if the service
name is ora1, the module name is calculate, and the action name is multiply,
142
the SERVICE_MODULE_ACTION name will be specified as

ora1.calculate.multiply.
Note: You must prefix all the values of the ATTRIBUTE attribute with
DBMS_RESOURCE_MANAGER while assigning a resource consumer group to a session.
• VALUE – Specifies the value of the login or run-time attribute being mapped.
The following is an example of assigning a resource consumer group to a session using the
SET_CONSUMER_GROUP_MAPPING procedure. To assign the rc1 resource consumer group to a session
that corresponds to the user name, JOHN, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (
3 ATTRIBUTE => DBMS_RESOURCE_MANAGER.ORACLE_USER,
4 VALUE => 'John',
5 CONSUMER_GROUP => 'rc1');
6 END;
Switching Resource Consumer Groups Using the DBMS_RESOURCE_MANAGER Package
An administrator may need to switch the resource consumer group of the session of a user that is using
excessive CPU resources. Instead of terminating the session of that database user, the administrator can
switch the resource consumer group of the session to the resource consumer group that is allocated less
CPU resources. The DBMS_RESOURCE_MANAGER package is equipped with two procedures,
SWITCH_CONSUMER_GROUP_FOR_SESS and SWITCH_CONSUMER_GROUP_FOR_USER, to switch the
resource consumer groups that have been assigned to active sessions.
You can switch a resource consumer group assigned to a specific session by using the
SWITCH_CONSUMER_GROUP_FOR_SESS procedure. The commonly used attributes of the
SWITCH_CONSUMER_GROUP_FOR_SESS procedure are as follows:
• SESSION_ID – Specifies the session identifier of the session for which the assigned resource
consumer group is being switched
• SESSION_SERIAL – Specifies the serial number of the session for which the assigned resource
consumer group is being switched
• CONSUMER_GROUP – Specifies the new resource consumer group that will be assigned to the
active session
The following is an example statement to switch the resource consumer group assigned to a session:
SQL> EXEC DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS('17', '12345',

'rc2');
This statement assigns the rc2 resource consumer group to a session with the session identifier 17 and
the serial number 12345 attributes.
143
You can use the SWITCH_CONSUMER_GROUP_FOR_USER procedure to switch the resource consumer
groups for all the sessions corresponding to a given user name. This procedure accepts two attributes,
USER and CONSUMER_GROUP. The USER attribute specifies the name of the user for which the resource
consumer group is being switched. The CONSUMER_GROUP attribute specifies the resource consumer
group to which an active session will be switched. For example, to switch the resource consumer group
for the user JOHN to the RC2 resource consumer group, run the following statement at the SQL prompt:
SQL> EXEC DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER('John', 'rc2');
Switching Resource Consumer Groups Using the DBMS_SESSION Package
Database users can switch from the current resource consumer groups to other resource consumer
groups by using the SWITCH_CURRENT_CONSUMER_GROUP procedure in the DBMS_SESSION package.
The SWITCH_CURRENT_CONSUMER_GROUP procedure enables database users to switch from the current
resource consumer groups to only those resource consumer groups for which they have the switch
privilege. The commonly used attributes of the SWITCH_CURRENT_CONSUMER_GROUP procedure are as
follows:
• NEW_CONSUMER_GROUP – Specifies the resource consumer group to which a database user

is required to switch.
• OLD_CONSUMER_GROUP – Is an output parameter that stores the name of the old resource
consumer group from which a database user has switched.
• INITIAL_GROUP_ON_ERROR – Enables a database user to switch back to the old resource

consumer group. The INITIAL_GROUP_ON_ERROR attribute raises an error if a problem
occurs while switching to the new resource consumer group. This attribute accepts one of
two values, TRUE or FALSE. The value TRUE indicates that the database user is automatically
switched back to the old resource consumer group if a problem occurs while switching. The
value FALSE indicates that only an error is raised if a problem occurs while switching.
The SWITCH_CURRENT_CONSUMER_GROUP procedure returns the name of the resource consumer group
from which a user has been switched. For example, the following statements call the
SWITCH_CURRENT_CONSUMER_GROUP procedure from a PL/SQL block:
DECLARE
old_consumer_group VARCHAR3(10);
BEGIN
DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP('rc2', 'old_consumer_group',
FALSE);
END;
In the above statements, the SWITCH_CURRENT_CONSUMER_GROUP procedure switches the current

resource consumer group of a database user to the RC2 resource consumer group. The
SWITCH_CURRENT_CONSUMER_GROUP procedure stores the name of the resource consumer group from
which a database user has switched in the old_consumer_group variable. You can use the value
stored in this variable to switch back to the old resource consumer group.
144
Working with Resource Plans

A resource plan contains resource plan directives that specify how resources are allocated to resource
consumer groups. There are two types of resource plans, simple and complex. In a simple resource plan,
you create resource plan directives and resource consumer groups by using a single procedure. In a
complex resource plan, the resource plan directives and the resource consumer groups are created using
separate procedures. A complex resource plan can also be used to nest resource plans. The nested
plans are called subplans. A complex resource plan that contains nested resource plans is called a
multilevel plan.
A resource plan enables you to allocate resources to resource consumer groups by using two methods,
EMPHASIS and RATIO. The EMPHASIS allocation method allocates resources to resource consumer
groups as specific percentages of the total available resources. In the EMPHASIS allocation method, the
percentage of resources allocated depends on the priority of the resource consumer groups. The RATIO
allocation method allocates resources to resource consumer groups as specific ratios of the total
available resources. The RATIO allocation method does not specify the priority of the resource consumer
groups while allocating the available resources.
Note: A simple resource plan always uses the EMPHASIS allocation method to allocate resources to
resource consumer groups mentioned in the resource plan. A complex resource plan can use any one of
allocation methods to allocate resources to resource consumer groups.
Creating a Simple Resource Plan
You can create a simple resource plan by using the CREATE_SIMPLE_PLAN procedure. By using a
simple resource plan, you can allocate only CPU resources such as CPU time to resource consumer
groups. Use the SIMPLE_PLAN attribute with the CREATE_SIMPLE_PLAN procedure to specify the name
of the resource plan to be created. This procedure accepts the names of the resource consumer groups
indicated in the resource plan. These attributes are specified by CONSUMER_GROUP1 through
CONSUMER_GROUP8. This procedure also accepts the percentage of CPU resources to be allocated to the
resource consumer groups as attributes, which are specified as GROUP1_CPU through GROUP8_CPU.
Note: A simple resource plan can allocate CPU resources to a maximum of eight resource consumer
groups.
The following is an example of creating a simple resource plan using the CREATE_SIMPLE_PLAN
procedure. To create a simple resource plan, RP1, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(
3 SIMPLE_PLAN =>'rp1',
4 CONSUMER_GROUP1 =>'rc1',
5 GROUP1_CPU =>50,
6 CONSUMER_GROUP2 =>'rc2',
7 GROUP2_CPU =>20,
8 END;
145
The RP1 resource plan allocates CPU resources to two resource consumer groups, RC1 and RC2. The
RC1 resource consumer group is allocated 50 percent of the CPU resource and the RC2 resource
consumer group is allocated 20 percent of the CPU resources.
Creating a Complex Resource Plan
You can create a complex resource plan by using the CREATE_PLAN procedure. The commonly used
attributes of the CREATE_PLAN procedure are as follows:
• PLAN – Specifies the name of the complex resource plan to be created.
• COMMENT – Specifies the description of the complex resource plan.
• CPU_MTH – Specifies the resource allocation method that is used to distribute CPU resources
among the resource consumer groups or subplans included in the complex resource plan. The
CPU_MTH attribute can accept one of two values, EMPHASIS or RATIO.
• ACTIVE_SESS_POOL_MTH – Specifies the method that is used to distribute active session pool
resources among resource consumer groups. This attribute limits the number of sessions that
can be active at a time. The ACTIVE_SESS_POOL_MTH attribute accepts only the
ACTIVE_SESS_POOL_ABSOLUTE value, which is the default value of the attribute.
• PARALLEL_DEGREE_LIMIT_MTH – Specifies the resource allocation method that is used to limit

the degree of parallelism for an operation. The PARALLEL_DEGREE_LIMIT_MTH method is used
by a database user to execute the operation. The PARALLEL_DEGREE_LIMIT_MTH attribute
accepts only the PARALLEL_DEGREE_LIMIT_ABSOLUTE value, which is the default value of this
attribute.
• QUEUEING_MTH – Specifies the order in which queued inactive sessions are executed.
The following is an example of creating a complex resource plan using the CREATE_PLAN procedure. To
create a complex resource plan, CRC1, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.CREATE_PLAN(
3 PLAN =>'crc1',
4 COMMENT =>'This procedure creates a complex resource plan');
5 END;
Creating Subplans
You can create a subplan using the same method that you employed to create a resource plan. Resource
plans constitute subplans. Resources allocated to subplans are derived from the resources allocated to
the resource plans.
146
Updating Resource Plans
You can update resource plans by using the UPDATE_PLAN procedure. The following attributes typically
apply to the UPDATE_PLAN procedure:
• PLAN – Specifies the name of the resource plan to be updated
• NEW_COMMENT – Specifies the description of the updated resource plan
• NEW_CPU_MTH – Specifies new methods to distribute CPU resources among subplans and
resource consumer groups of the updated resource plan
To update the RC1 resource plan, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.UPDATE_PLAN
3 PLAN => 'rc1',
4 NEW_COMMENT =>'This is updated resource plan');
5 END;
Deleting Resource Plans
You can delete a resource plan along with the resource plan directives by using the DELETE_PLAN
procedure. For example, to delete the RC1 resource plan along with its resource plan directives, run the
SQL> EXEC DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN => 'rc1');
You can use the DELETE_PLAN_CASCADE procedure to delete a resource plan along with the resource
plan directives, subplans, and resource consumer groups. For example, to delete the RC1 resource plan
along with the resource plan directives, subplans, and resource consumer groups, run the following
SQL> EXEC DBMS_RESOURCE_MANAGER.DELETE_PLAN_CASCADE(PLAN => 'rc1');
Working With Resource Plan Directives

Resource plan directives assign resource consumer groups to resource plans and specify methods to
allocate resources to resource consumer groups and subplans.
The resource plan directives in a resource plan use the Oracle predefined resource allocation methods to
allocate resources to resource consumer groups and subplans. Some of the predefined resource
allocation methods are as follows:
• CPU – Defines methods to allocate CPU resources to all the resource consumer groups and
subplans within a resource plan. To allocate CPU resources, this method assigns a priority level,
which can vary from one to eight, to each resource consumer group and subplan in a resource
plan. A resource consumer group or subplan corresponding to priority level one is assigned the
147
highest priority for CPU resources. On the contrary, a resource consumer group or subplan with
priority level eight is assigned the lowest priority for CPU resources.
• Active session pool with queuing – Limits the number of concurrent active sessions for a resource
consumer group. If the number of concurrent sessions for a resource consumer group reaches its
upper limit, a new request for a session is placed in a queue. The new request for a session waits
in the queue until an active session of the resource consumer group is completed.
• Degree of parallelism limit – Defines the maximum degree of parallelism that can be used by an
operation in a resource consumer group.
• Automatic resource consumer group switching – Allows you to switch the resource consumer
group assigned to a session to another resource consumer group if the session exceeds the
specified execution time.
• Canceling of SQL and terminating sessions – Defines the execution time threshold to terminate
long-running SQL queries and sessions.
• Execution time limit – Defines the maximum estimated execution time allowed for an operation.
This method estimates the execution time for an operation before the operation begins. If the
estimated execution time is greater than the maximum estimated execution time of the operation,
the execution time limit method terminates the operation.
• Undo pool – Places a limit on the amount of undo space consumed by a resource consumer
group. If a resource consumer group exceeds this limit, this method terminates the current Data
Manipulation Language (DML) operation. This method does not allow members of a resource
consumer group to perform DML operations until the undo space is freed.
• Idle time limit – Defines the maximum time for which a session of a resource consumer group can
remain idle. This method terminates a session if the session exceeds the maximum idle time limit.
Note: All methods, except the CPU method, apply only to resource consumer groups assigned to a
resource plan.
Creating Resource Plan Directives
You can create a resource plan directive by using the CREATE_PLAN_DIRECTIVE procedure. The
commonly used attributes of the CREATE_PLAN_DIRECTIVE procedure are as follows:
• PLAN – Specifies the name of the resource plan for which you are creating the resource plan
directive.
• GROUP_OR_SUBPLAN – Specifies the name of the resource consumer group or subplan in the
resource plan for which you are creating the resource plan directive.
• COMMENT – Describes the resource plan.
• CPU_P1 – Specifies the percentage of CPU resources used by the resource consumer group of a
resource plan at the first level if the resource plan uses the EMPHASIS allocation method. This
148
parameter specifies the weight of CPU usage for a resource consumer group or subplan if the
resource plan uses the RATIO allocation method. The default value of the CPU_P1 parameter is
NULL.
• CPU_Pn (where n is 2 through 8) – Specifies the percentage of CPU resources used by the
resource consumer group of a resource plan at the nth level if the resource plan uses the
EMPHASIS allocation method. This parameter is not applicable to the RATIO allocation method.
The default value of this parameter is NULL.
• ACTIVE_SESS_POOL_P1 – Specifies the maximum number of sessions that can remain active
simultaneously in a resource consumer group. The default value of this parameter is NULL, which
indicates that there can be an unlimited number of active sessions in a resource consumer group.
• QUEUEING_P1 – Specifies a time limit after which a job waiting for execution will time out. The
default value of this parameter is NULL, which specifies that the job will never time out.
• PARALLEL_DEGREE_LIMIT_P1 - Specifies the limit on the degree of parallelism defined for an

operation. The default value of this parameter is NULL, which allows an unlimited degree of
parallelism.
• SWITCH_GROUP – Specifies a resource consumer group to which the session of another resource
consumer group is switched if the other resource consumer group session exceeds the specified
execution time limit. The default value of this parameter is NULL. If the value of this parameter is
CANCEL_SQL, a query running in the session of a resource consumer group is canceled when the
query exceeds the specified execution time limit. If the value of this parameter is KILL_SESSION,
the session of a resource consumer group is terminated when the session exceeds the specified
execution time limit.
• SWITCH_TIME – Specifies the number of seconds for which a session can execute an operation
before a switch to another resource consumer group occurs. The default value of this parameter
is NULL, which specifies unlimited time.
• SWITCH_ESTIMATE – Specifies a Boolean value. If the value of this parameter is TRUE, Oracle
estimates the execution time for an operation before the operation starts. The
SWITCH_ESTIMATE parameter terminates an operation if the estimated execution time of the
operation is greater than the value of the SWITCH_TIME parameter. The default value of this
parameter is FALSE.
• MAX_EST_EXEC_TIME – Specifies the maximum time period, in seconds, required to execute an

operation in a session. This parameter directs Oracle to estimate the execution time for an
operation in a session. If the estimated time for the operation exceeds the value of this
parameter, the operation is not started and an ORA-07455 error is issued. The default value of
this parameter is NULL.
• UNDO_POOL – Specifies the limit on the amount of undo space, in kilobytes, consumed by a
resource consumer group. The default value of this parameter is NULL. The NULL value specifies
that a resource consumer group can consume an unlimited amount of undo space.
149
• MAX_IDLE_TIME – Specifies the time limit, in seconds, for which a session can remain idle. The
default value of this parameter is NULL.
• MAX_IDLE_BLOCKER_TIME – Specifies the number of seconds for which a session can remain
idle while blocking a resource that is needed by another session. The default value for this
parameter is NULL.
• SWITCH_TIME_IN_CALL – Specifies the time, in seconds, for which a session of a resource

consumer group can be executed before a switch to another resource consumer group occurs.
The following is an example of creating a resource plan directive using the CREATE_PLAN_DIRECTIVE
procedure:
SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
3 PLAN => 'Plan_1',
4 COMMENT => 'This is first plan',
5 GROUP_OR_SUBPLAN => 'Plan_2',
6 PARALLEL_DEGREE_LIMIT_P1 => '4');
7 END;
Creating Resource Subplan Directives
A resource subplan directive allocates resources to a subplan in a resource plan. To create a resource
subplan directive for a subplan, you must create a resource plan directive for the resource plan that
contains the subplan. For example, to create a subplan directive for a subplan, PLAN_2, in the PLAN_1
resource plan, run the following statements at the SQL prompt:
SQL> BEGIN
3 PLAN => 'Plan_1',
4 COMMENT => 'Plan_2 is a subplan',
6 CPU_P2 => 50);
7 END;
The above statements create a resource subplan directive that allocates 50 percent of the CPU resources
to the PLAN_2 subplan in the PLAN_1 resource plan.
Creating Resource Multiplan Directives
A resource multiplan directive enables you to prioritize the allocation of CPU resources to resource
consumer groups and subplans in a resource plan. You can use the CPU_1 to CPU_8 parameters to
define the level at which CPU resources are allocated to a resource consumer group or subplan.
Resource consumer groups or subplans at the CPU_1 level are assigned the highest priority for CPU
resources whereas resource consumer groups or subplans at the CPU_8 level are assigned the lowest
priority for CPU resources. A resource consumer group or subplan at level one uses CPU resources
150
based on the values of the CPU_1 parameter. A resource consumer group or subplan at level two uses
the CPU resources that have not been used at level one, and so on. Allocation of CPU resources on a
particular level cannot exceed 100 percent. The following is an example of creating a resource multi-plan
directive:
SQL> BEGIN
3 PLAN => 'Plan_1',
4 COMMENT => 'Plan_2 is a subplan',
6 CPU_P1 => 100);
7 END;
SQL> BEGIN
3 PLAN => 'Plan_1',
4 COMMENT => 'Plan_3 is a subplan at level 2',
6 CPU_P2 => 50);
7 END;
SQL> BEGIN
3 PLAN => 'Plan_1',
6 CPU_P2 => 50);
7 END;
SQL> BEGIN
3 PLAN => 'Plan_1',
6 CPU_P3 => 100);
7 END;
In the above statements, four resource plan directives have been created for the PLAN_1 resource plan.
These resource directives are as follows:
• Resource directive for PLAN_2 – Allocates 100 percent CPU resources to the PLAN_2 subplan of
the PLAN_1 resource plan at level one.
the PLAN_1 resource plan at level two.
151
the PLAN_1 resource plan at level two.
the PLAN_1 resource plan at level three.
Creating Automatic Resource Consumer Group Switching Resource Plan Directives
You can create resource plan directives that automatically switch resource consumer groups for sessions
that exceed the defined thresholds. For example, a resource plan directive can indicate that a session
executing an operation for more than 10 minutes should be automatically switched to a lower priority
resource consumer group.
To create a resource plan directive that automatically switches to another resource consumer group, you
must assign values to the PLAN, GROUP_OR_SUBPLAN, SWITCH_TIME, and SWITCH_GROUP attributes of
the CREATE_PLAN_DIRECTIVE procedure.
For example, to create a resource plan directive that automatically cancels operations that take over an
hour to execute, run the following statements at the SQL prompt:
SQL> BEGIN
3 PLAN =>'Plan_1',
4 GROUP_OR_SUBPLAN =>'Plan_2',
5 SWITCH_GROUP =>'CANCEL_SQL',
6 SWITCH_TIME => 3600);
7 END;
Updating Resource Plan Directives
You can update a resource plan directive by using the UPDATE_PLAN_DIRECTIVE procedure. The
attributes of the UPDATE_PLAN_DIRECTIVE procedure are the same as that of the
CREATE_PLAN_DIRECTIVE procedure. However, the UPDATE_PLAN_DIRECTIVE procedure has the
NEW_ prefix added to the names of the attributes. You can modify all the attributes of a resource plan
directive, except the PLAN and GROUP_OR_SUBPLAN attributes. For example, to update the percentage of
CPU resources allocated to the RC1 resource consumer group of the PLAN_1 resource plan, run the
SQL> DBMS_RESOURCE_MANAGER.UPDATE_PLAN(PLAN=> 'Plan_1',GROUP_OR_SUBPLAN

=>'rc1',NEW_CPU_P1=>16);
Deleting Resource Plan Directives
152
You can delete a resource plan directive by using the DELETE_PLAN_DIRECTIVE procedure. This
procedure accepts two attributes, PLAN and GROUP_OR_SUBPLAN. For example, to delete the RC1
resource consumer group, run the following statement at the SQL prompt:
SQL>
DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN=>'Plan_1',GROUP_OR_SUBPLAN=>'rc1');
153
Automating Tasks Using the Scheduler

Scope
• Introduce the concept of the Scheduler.
• Create and manage jobs in the Scheduler.
• Create and manage programs in the Scheduler.
• Create and manage schedules in the Scheduler.
• Create and manage job classes in the Scheduler.
• Create and manage windows in the Scheduler. Manage logs in the Scheduler.
• Describe the Scheduler views.
Focused Explanation
Introducing the Scheduler
The Scheduler is a collection of procedures and functions in the DBMS_SCHEDULER package. The
Scheduler enables you to control the execution of various tasks such as tasks related to database
administration and data warehousing. The Scheduler also enables you to specify when a particular task
should be performed in a database. For example, you can schedule and monitor database maintenance
jobs, such as backups and data warehousing tasks, using the Scheduler. The Scheduler enables you to
manage the database by breaking a task into manageable components, called jobs.
Introducing Scheduler Components
The Scheduler consists of two types of components, basic and advanced. The basic components of the
Scheduler are as follows:
• Program – Specifies the tasks to be performed by the Scheduler. A program is a reserve of

metadata information about each task performed by the Scheduler. The metadata information
includes the name, the type, and the arguments of the program. Program types can be either
anonymous PL/SQL blocks, stored procedures, or executable operating systems.
• Schedule – Specifies the time and frequency for the execution of a job. When you create a
schedule, you can schedule jobs to run immediately or at a later time. You can also specify the
end date and time for the jobs to be executed. The end date and time specifies the date and time
when the job will expire.
• Job – Specifies a user-defined set of actions that is scheduled to run. A job specifies the actions
to be performed and the date and time when these actions will be performed. You can create a
job either by using an inline schedule and program or by using an existing schedule and program.
Note: An inline schedule or program is a part of the job definition and is specified when you create a job.
154
The advanced components of the Scheduler are as follows:
• Job class – Specifies a group of jobs with common resource requirements. A job can belong to
only one job class and one resource consumer group.
• Window – Represents a time interval during which you can change the resources allocated to a
job. A window is defined by a specific start and end time. You can activate only one window at a
time. You can also assign priorities to windows while creating them. If the time interval of two or
more windows overlaps, the window with the higher priority is used.
• Window group – Represents a group of related windows.
Scheduler Architecture
The architecture of the Scheduler contains the following elements:
• The job table – A table that stores information, such as the name of the owner and the logging
level of a job, related to all the jobs in the database. You can view the information stored in the
job table by querying the *_SCHEDULER_JOBS views.
• The job coordinator – A background process that is started when a new job is executed or a new
window is opened. The job coordinator places the jobs specified in the job table in the memory
cache. This ensures that the jobs are not accessed from the disk every time the jobs are
referenced. The job coordinator automatically enters sleep mode when no jobs are scheduled to
run.
• Job slaves – Processes used to run the submitted jobs. Job slaves are activated by the job
coordinator when a job is to be run. Job slaves collect metadata about a job from the job table.
To run a job, a job slave creates a new session when the owner of the job starts a transaction
within the job. When the job is complete, the job slave commits the transaction and closes the
session.
Working with Programs

You must have the CREATE JOB privilege to create a program in your own schema and the CREATE ANY
JOB privilege to create programs in the schema of other database users. You must grant the EXECUTE
privilege on the programs that you create for other database users to run these programs.
Creating Programs
You can create programs in the Scheduler by using the CREATE_PROGRAM procedure. The commonly
used attributes of the CREATE_PROGRAM procedure are as follows:
• PROGRAM_NAME – Specifies the name of the program to be created. The name of the program
must be unique in the SQL namespace.
Note: The SQL namespace is defined as a set of names given to database objects accessible to you at a
specified point of time.
155
• PROGRAM_TYPE – Specifies the type of program. You can assign the following values to the
PROGRAM_TYPE attribute:
o PLSQL_BLOCK – Specifies a PL/SQL code block.
o STORED_PROCEDURE – Specifies a stored procedure.
o EXECUTABLE – Specifies an operating system executable.
• PROGRAM_ACTION – Specifies a PL/SQL code block, the name of a stored procedure, or the
name of an operating system executable, depending on the value specified for the
PROGRAM_TYPE attribute.
• NUMBER_OF_ARGUMENTS – Specifies the number of arguments to be passed to the stored

procedure or operating system executable specified in the PROGRAM_ACTION attribute.
• ENABLED – Specifies whether or not a program should be enabled. You must enable a program
before using it.
• COMMENTS – Stores a description of the program.
Programs are created by default in the schema of the database user that creates the programs. To create
programs in the schema of another database user, you must specify the name of the program along with
the schema name of the database user. For example, to create the PROGRAM1 program in your own
schema, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.CREATE_PROGRAM(
3 PROGRAM_NAME =>'program1',
4 PROGRAM_ACTION =>'/samplescript.sh',
5 PROGRAM_TYPE =>'EXECUTABLE',
6 COMMENTS =>' ‘This program executes the script samplescript',
7 ENABLED =>TRUE);
8 END;
The above statements create the PROGRAM1 program, which executes a script named
samplescript.sh.
Passing Arguments to Programs
You can also pass arguments to the programs created in the Scheduler. For example, to create a
program that executes the PROCEDURE2 stored procedure that accepts two attributes, run the following
SQL> BEGIN
2 DBMS_SCHEDULER.CREATE_PROGRAM(
4 PROGRAM_ACTION =>'procedure2',
5 PROGRAM_TYPE =>' STORED_PROCEDURE',
156
6 NUMBER_OF_ARGUMENTS =>2,
7 COMMENTS =>'This program executes a stored procedure,
procedure2, which accepts two arguments');
8 END;
You can define the arguments to be passed to a program by using the DEFINE_PROGRAM_ARGUMENT
procedure. The commonly used attributes of the DEFINE_PROGRAM_ARGUMENT procedure are as follows:
• PROGRAM_NAME – Specifies the name of the program for which arguments are being defined.
• ARGUMENT_NAME – Specifies the name of the argument to be defined.
• ARGUMENT_POSITION – Specifies the position of an argument when you pass the argument to a
program. The ARGUMENT_POSITION attribute can accept values ranging from 1 to the value of
the NUMBER_OF_ARGUMENTS attribute defined while creating the program.
• ARGUMENT_TYPE – Specifies the data type of the argument.
• DEFAULT_VALUE – Specifies the default value of the argument. If you do not pass the argument
to a program, the program accepts the value assigned to the DEFAULT_VALUE parameter as an
argument.
The following is an example of defining arguments using the DEFINE_PROGRAM_ARGUMENT procedure.

For example, run the following statements at the SQL prompt to define two VARCHAR2 arguments,
ARGUMENT1 and ARGUMENT2, to be passed to the PROGRAM2 program:
SQL> BEGIN
2 DBMS_SCHEDULER.DEFINE_PROGRAM_ARGUMENT(
4 ARGUMENT_NAME =>'argument1',
5 ARGUMENT_POSITION =>1,
6 ARGUMENT_TYPE =>'VARCHAR2',
7 DEFAULT_VALUE =>'x');
8 DBMS_SCHEDULER.DEFINE_PROGRAM_ARGUMENT(
10 ARGUMENT_NAME =>'argument2',
11 ARGUMENT_POSITION =>2,
12 ARGUMENT_TYPE =>'VARCHAR2',
13 DEFAULT_VALUE =>'y');
14 END;
In the above statements, the default value of the ARGUMENT1 argument is x and the default value of the
ARGUMENT2 argument is y.
157
Enabling Programs
You must enable a program before a job can use that program. You can enable a program by using the
ENABLE procedure. The ENABLE procedure accepts the name of the program to be enabled as an
attribute. You can also enable multiple programs simultaneously by providing a comma-delimited list of
program names as an attribute to the ENABLE procedure. For example, to enable the PROGRAM1 and
PROGRAM2 programs, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.ENABLE('program1,program2');
3 END;
Altering Programs
You can alter a program by using the SET_ATTRIBUTE procedure. You can alter all the attributes, except
the PROGRAM_NAME attribute, of a program. When you alter a program, the currently running jobs that are
using the program are not affected. Currently running jobs will use the altered program the next time they
are performed. For example, to alter the PROGRAM1 program and set the value of the
NUMBER_OF_ARGUMENTS attribute to 3, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.SET_ATTRIBUTE(
3 NAME => 'program1',
4 ATTRIBUTE => 'NUMBER_OF_ARGUMENTS',
5 VALUE => '3');
6 END;
Disabling Programs
You can disable a program by using the DISABLE procedure. The DISABLE procedure accepts two
attributes, NAME and FORCE. The NAME attribute specifies the name of the program to be disabled. The
FORCE attribute disables a program that has jobs associated with it. You can also disable multiple
programs simultaneously by providing a comma-delimited list of program names as an attribute to the
DISABLE procedure.
Note: When a program is disabled, the jobs associated with the program will not be performed.
For example, to disable the PROGRAM1 and PROGRAM2 programs, run the following statements at the SQL
prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.DISABLE('program1,program2');
3 END;
Note: No error is generated if you disable a program that does not exist.
158
Dropping Programs
You can drop a program by using the DROP_PROGRAM procedure. When you drop a program, the
currently running jobs that are using the program are not affected. The DROP_PROGRAM procedure
accepts two attributes, PROGRAM_NAME and FORCE. The PROGRAM_NAME attribute specifies the name of
the program to be dropped. The FORCE attribute specifies whether the program will be dropped if a job
uses the program. The default value of the FORCE attribute is FALSE, which specifies that the program will
not be dropped if a job uses the program. If the value of the FORCE attribute is TRUE, the program will be
dropped and the jobs using the program will be disabled. When a program is dropped, all the argument
values set for the program are also dropped.
The following is an example of dropping programs using the DROP_PROGRAM procedure. To drop the
PROGRAM1 and PROGRAM2 programs and disable the jobs associated with the PROGRAM1 and PROGRAM2
programs, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.DROP_PROGRAM('program1,program2',TRUE);
3 END;
Dropping Program Arguments
You can also drop the arguments of a program by using the DROP_PROGRAM_ARGUMENT procedure.
When you drop the arguments of a program, the currently running jobs that are using the program are not
affected. The DROP_PROGRAM_ARGUMENT procedure accepts two attributes, PROGRAM_NAME and either
ARGUMENT_POSITION or ARGUMENT_NAME. The PROGRAM_NAME attribute specifies the name of the
program whose arguments are being dropped. The ARGUMENT_POSITION attribute specifies the position
of the argument to be dropped while creating the program. The ARGUMENT_NAME attribute specifies the
name of the argument being dropped. For example, to drop the ARGUMENT1 argument in the PROGRAM1
program, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.DROP_PROGRAM_ARGUMENT(
3 PROGRAM_NAME => 'program1',
4 ARGUMENT_NAME => 'argument1');
5 END;
Working with Schedules

A schedule defines the start and stop time or date to execute a job or open a window. A schedule also
defines an interval called repeat interval to repeat a job. A schedule defines the repeat interval by using
either a PL/SQL expression or a calendaring expression.
159
Creating Schedules in the Scheduler
You can create schedules in the Scheduler by using the CREATE_SCHEDULE procedure. You must have
the CREATE JOB privilege to create a schedule in your own schema and the CREATE ANY JOB privilege to
create schedules in the schemas of other database users. The commonly used attributes of the
CREATE_SCHEDULE procedure are as follows:
• SCHEDULE_NAME – Specifies the name of the schedule to be created. The name of the schedule
must be unique in the SQL namespace.
• START_DATE – Specifies the date on which a schedule becomes active. The default value of this
attribute is NULL.
• END_DATE – Specifies the date on which a schedule becomes inactive. The value of the
END_DATE attribute must be NULL or greater than the value of the START_DATE attribute. The
default value of the END_DATE attribute is NULL, which specifies that the job using the current
schedule will run indefinitely.
• REPEAT_INTERVAL – Specifies the frequency for running a job by using the specified schedule.
The REPEAT_INTERVAL attribute is specified as a calendaring expression that includes the
frequency and time for running a job.
• COMMENTS – Stores a description of the schedule.
The following is an example of creating a schedule using the CREATE_SCHEDULE procedure. Run the
following statements at the SQL prompt to create the SCHEDULE1 schedule to run every four weeks:
SQL> BEGIN
2 DBMS_SCHEDULER.CREATE_SCHEDULE(
3 SCHEDULE_NAME =>'schedule1',
4 START_DATE =>'SYSTIMESTAMP',
5 END_DATE =>NULL,
6 REPEAT_INTERVAL =>'FREQ=WEEKLY;INTERVAL=4',
7 COMMENTS =>'Every 4 weeks');
8 END;
Altering Schedules
You can alter a schedule by using the SET_ATTRIBUTE procedure. While you are altering a schedule, the
currently running jobs that are adhering to the schedule are not affected. Currently running jobs will
adhere to the altered schedule the next time the jobs are run. You can alter all the attributes of a schedule
except its name. For example, to alter the SCHEDULE1 schedule and change the value of the
START_DATE attribute to 01 JAN 2005, run the following statements at the SQL prompt:
SQL> BEGIN
3 NAME => 'schedule1',
4 ATTRIBUTE => 'START_DATE',
5 VALUE => '01-JAN-2005 12:00:00 AM');
160
6 END;
Dropping Schedules
You can drop a schedule by using the DROP_SCHEDULE procedure. The DROP_SCHEDULE procedure
accepts two attributes, SCHEDULE_NAME and FORCE. The SCHEDULE_NAME attribute specifies the name
of the schedule to be dropped. The FORCE attribute specifies whether or not the schedule will be dropped
if it is being used by a job. The default value of the FORCE attribute is FALSE, which specifies that the
schedule will not be dropped if a job uses the schedule. If you set the value of the FORCE attribute to
TRUE, the jobs using the schedule will be disabled before the schedule is dropped. For example, to drop
the SCHEDULE1 and SCHEDULE2 schedules, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.DROP_SCHEDULE('schedule1,schedule2');
3 END;
Working with Jobs

Jobs refer to specific programs that the Scheduler runs in the database at a specified time or date.
Creating Jobs in the Scheduler
You can create jobs in the Scheduler by using the CREATE_JOB procedure. You must have the CREATE
JOB privilege to create a job in your own schema and the CREATE ANY JOB privilege to create jobs in the
schemas of other database users. The commonly used attributes of the CREATE_JOB procedure are as
follows:
• JOB_NAME – Specifies the name of the job to be created.
• PROGRAM_NAME – Specifies the name of the program that is to be used by the job.
• SCHEDULE_NAME – Specifies the name of the schedule that is to be used by the job.
• JOB_CLASS – Specifies the class with which the current job is associated. If you do not set the
value of the JOB_CLASS attribute, the job is associated with the DEFAULT_JOB_CLASS job class.
• AUTO_DROP – Specifies that a job should be automatically dropped when the job is completed.
The default value of this attribute is TRUE. If the value of the AUTO_DROP parameter of a
repeating job is set to TRUE, the repeating job is dropped when the entire job is completed.
• COMMENTS – Stores a description of the job.
You can use the following options to create a job:
• a previously created program and schedule
• a previously created program and an inline schedule
• a previously created schedule and an inline program
161
Note: A schedule or program is called inline when you create the schedule or program while creating a
job.
You must use the following attributes in place of the SCHEDULE_NAME attribute when you are creating a
job that does not use a previously created schedule:
• START_DATE – Specifies the date on which a job will run.
• END_DATE – Specifies the date on which a job will be deactivated. The value of the END_DATE
attribute must be greater than the value of the START_DATE attribute.
• REPEAT_INTERVAL – Specifies the frequency of repeating a job. If you do not specify the
REPEAT_INTERVAL attribute for a job, the job runs only once on the date specified by the
START_DATE attribute. The value of the REPEAT_INTERVAL attribute is specified as a
calendaring expression that includes the frequency and time for running a job.
When you create a job that does not use a previously created program, you must use the following
attributes in place of the PROGRAM_NAME attribute:
• JOB_TYPE – Specifies the type of job. The JOB_TYPE attribute is equivalent to the
PROGRAM_TYPE attribute. You can assign the PLSQL_BLOCK, STORED_PROCEDURE, or
EXECUTABLE values to the JOB_TYPE attribute.
• JOB_ACTION – Specifies the action performed by a job. The JOB_ACTION attribute is equivalent
to the PROGRAM_ACTION attribute. The values assigned to this attribute can be PLSQL_BLOCK,
STORED_PROCEDURE, or EXECUTABLE.
• NUMBER_OF_ARGUMENTS – Specifies the number of arguments passed to a stored procedure or

an operating system executable when it is executed by a job. The number of arguments a job can
accept ranges from 0 to 255, the default number being 0.
For example, to create the INC_SALARY job, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.CREATE_JOB(
3 JOB_NAME =>'INC_SALARY',
4 JOB_TYPE =>'PLSQL_BLOCK',
5 JOB_ACTION =>'UPDATE EMP SET sal=sal+1000; ',
6 START_DATE =>'10-JUN-05 12:00:00 AM',
7 END_DATE =>'10-DEC-07 12:00:00 AM',
8 REPEAT_INTERVAL =>'FREQ=YEARLY;INTERVAL=1',
9 COMMENTS =>'Increment salary of the employees every year');
10 END;
The INC_SALARY job does not use a previously created program or schedule. The program and schedule
are both specified inline as part of the job definition. The INC_SALARY job runs every year and
increments the values in the SAL column of the EMP table by 1000 every year. This job will run until
December 10, 2007.
162
Specifying Calendaring Expressions
Oracle 10g provides calendaring expressions to specify the value of the REPEAT_INTERVAL attribute
when you are creating jobs or schedules in the Scheduler. A calendaring expression consists of the
following three elements:
• Frequency – Specifies the frequency type to run a job. You can use the FREQ keyword to specify
the frequency type of the job while creating a schedule for the job. The FREQ keyword can be one
of the following values:
o YEARLY – Specifies that a job will run after the specified number of years
o MONTHLY – Specifies that a job will run after the specified number of months
o DAILY – Specifies that a job will run after the specified number of days
o HOURLY – Specifies that a job will run after the specified number of hours
o MINUTELY – Specifies that a job will run after the specified number of minutes
o SECONDLY – Specifies that a job will run after the specified number of seconds
• Interval – Specifies how often a job will run based on the specified frequency of the job. For
example, if a job runs yearly and the value of the interval element is 2, the job runs every two
years. The value of the interval element is an integer and can range from 1 to 999. The default
value of the interval element is 1.
• Specifier – Specifies detailed information about the execution of a job. By using the specifier
element along with the interval and frequency elements, you can determine the days and hours
for which a job will run. The possible values of the specifier element for a job are as follows:
o BYMONTH – Specifies the month on which a job should run. The value of BYMONTH can
range from 1 to 12 or from JAN to DEC.
o BYWEEKNO – Specifies the week of the year on which a job should run. The value of
BYWEEKNO can range from 1 to 53.
o BYYEARDAY – Specifies the day of the year on which a job should run. The value of
BYYEARDAY can range from 1 to 366.
o BYMONTHDAY – Specifies the day of the month on which a job should run. The value of
BYMONTHDAY can range from 1 to 31. You can also specify negative values for
BYMONTHDAY. For example, the value, –1, indicates the last day of the specified month.
o BYDAY – Specifies the day of the week on which a job should run. The value of BYDAY
can range from MON to SUN.
o BYHOUR – Specifies the hour of the day at which a job should run. The value of BYHOUR
can range from 0 to 23.
163
o BYMINUTE – Specifies the minute of the hour at which a job should run. The value of
BYMINUTE can range from 0 to 59.
o BYSECOND – Specifies the second of the minute at which a job should run. The value of
BYSECOND can range from 0 to 59.
The following example shows how to specify a calendaring expression. For example, the calendaring
expression to run a job every 10 days at 8:15 A.M. is as follows:
FREQ=DAILY;INTERVAL=10;BYHOUR=8;BYMINUTE=15;BYSECOND=0;
Enabling Jobs
Jobs are disabled by default. Therefore, you must enable jobs before running them. You can enable jobs
by using the ENABLE procedure. For example, to enable the JOB1 and JOB2 jobs, run the following
SQL> BEGIN
2 DBMS_SCHEDULER.ENABLE('job1,job2');
3 END;
Running Jobs
You can run an enabled job by using the RUN_JOB procedure. The RUN_JOB procedure accepts two
attributes, JOB_NAME and USE_CURRENT_SESSION. The JOB_NAME attribute specifies the name of the
job to be run, and the USE_CURRENT_SESSION attribute specifies whether the job will run in the current
user session or in the background. The USE_CURRENT_SESSION attribute is optional and its default value
is TRUE. If the value of the USE_CURRENT_SESSION attribute is TRUE, a job runs in the current session.
For example, to run the JOB1 job in the background, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.RUN_JOB('job1',FALSE);
3 END;
Stopping Jobs
You can stop currently running jobs by using the STOP_JOB procedure. This procedure uses an interrupt
mechanism process to stop a job that is currently running. The STOP_JOB procedure accepts two
attributes, JOB_NAME and FORCE. The JOB_NAME attribute specifies the name of the jobs being stopped.
The FORCE attribute indicates that a running job is stopped forcefully if the interrupt mechanism is not
able to stop the running job. The default value of the FORCE attribute is FALSE. For example, to forcefully
stop the currently running the JOB1 and JOB2 jobs, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.STOP_JOB('job1,job2',TRUE);
3 END;
164
Disabling Jobs
You can disable a job by using the DISABLE procedure. A job can also be disabled if the job class, the
program, or the schedule being used by the job is dropped. When a job is disabled, the job table stores
the state of the job as DISABLED. For example, to disable the JOB1 and JOB2 jobs, run the following
SQL> BEGIN
2 DBMS_SCHEDULER.DISABLE('job1,job2');
3 END;
Dropping Jobs
You can drop a job by using the DROP_JOB procedure. The DROP_JOB procedure accepts two attributes,
JOB_NAME and FORCE. The JOB_NAME attribute specifies the name of the job being dropped or the
name of a job class whose jobs are being drop. The FORCE attribute is an optional attribute that is used to
drop a job being executed currently. Dropping a job removes the job from the job table and the
*_SCHEDULER_JOBS views. When a job is dropped, subsequent execution of the job is stopped and all
the argument values set for the job are also dropped. For example, to drop the JOB1 and JOB2 jobs, run
the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.DROP_JOB('job1,job2');
3 END;
To drop a job that is currently executing, you must set the FORCE attribute of the DROP_JOB procedure to
TRUE. For example, to drop the JOB2 job by using the FORCE attribute, run the following statements at the
SQL prompt:
|
SQL> BEGIN
2 DBMS_SCHEDULER.DROP_JOB('job2',TRUE);
3 END;
Copying Jobs
You can use the COPY_JOB procedure to copy the attributes of one job to another. The COPY_JOB
procedure creates a new job containing the attributes of the old job. By default, the new job is disabled
and the state of the original job remains unchanged. The COPY_JOB procedure accepts two attributes,
OLD_JOB and NEW_JOB. For example, to copy the attributes of an existing job, JOB1, to a new job, JOB2,
run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.COPY_JOB('job1','job2');
3 END;
165
Altering Jobs
You can alter all the attributes of a job, except its name. If you alter an enabled job, the Scheduler first
disables it, alters it, and then re-enables it. The currently running instance of the job that you are altering
is not affected by the changes made to the job. You can alter a job by using the SET_ATTRIBUTE
procedure. The SET_ATTRIBUTE procedure accepts the following attributes:
• NAME – Specifies the name of the job to be altered
• ATTRIBUTE – Specifies the attribute of the job to be altered
• VALUE – Specifies the new value for the attribute of the job to be altered
The following is an example of altering a job using the SET_ATTRIBUTE procedure. To alter the job1
job and set the JOB_CLASS attribute of the JOB1 job to JOBCLASS2, run the following statements at the
SQL prompt:
SQL> BEGIN
3 NAME => 'job1',
4 ATTRIBUTE => 'job_class',
5 VALUE => 'jobclass2');
6 END;
Note: You cannot use the SET_ATTRIBUTE procedure to set the value of an attribute to NULL. If you
need to set the value of an attribute to NULL, you must use the SET_ATTRIBUTE_NULL procedure.
Working with Job Classes

To create a job class, you must have the MANAGE SCHEDULER privilege. To create jobs that belong to a
particular job class, you must have the EXECUTE privilege on that job class. All the job classes that you
create in the Scheduler belong to the SYS schema.
Creating Job Classes
You can create job classes in the Scheduler by using the CREATE_JOB_CLASS procedure. The
commonly used attributes of the CREATE_JOB_CLASS procedure are as follows:
• JOB_CLASS_NAME – Specifies the name of the job class to be created.
• RESOURCE_CONSUMER_GROUP – Specifies the name of the resource consumer group associated

with the job class. If you do not specify the RESOURCE_CONSUMER_GROUP attribute, the job class
is associated with the DEFAULT_CONSUMER_GROUP resource consumer group.
• SERVICE – Specifies the name of the service to which the job class belongs.
• COMMENTS – Specifies the description of the job class.
166
The following is an example of creating a job class using the CREATE_JOB_CLASS procedure. For
example, to create the jJOBCLASS1 job class, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.CREATE_JOB_CLASS(
3 JOB_CLASS_NAME =>'jobclass1',
4 RESOURCE_CONSUMER_GROUP =>'SYS_GROUP');
5 END;
Altering Job Classes
You can alter all the job classes, except the default job class, in the Scheduler. You can alter all the
attributes of a job class, except its name. When you alter a job class, the currently running jobs that are
using the job class are not affected. You can use the SET_ATTRIBUTE procedure to alter a job class. For
example, to change the job class of the JOB1 job to JOBCLASS2, run the following statements at the SQL
prompt:
SQL> BEGIN
3 NAME => 'job1',
4 ATTRIBUTE => 'job_class',
5 VALUE => 'jobclass2');
6 END;
Dropping Job Classes
You can drop a job class by using the DROP_JOB_CLASS procedure. The DROP_JOB_CLASS procedure
accepts two attributes, JOB_CLASS_NAME and FORCE. The JOB_CLASS_NAME attribute specifies the
name of the job class being dropped. The FORCE attribute specifies whether or not a job class is dropped
if a job uses the job class. The default value of the FORCE attribute is FALSE, which specifies that a job
class is not dropped if it is being used by a job. If you set the value of the FORCE attribute to TRUE, the
jobs associated with the job class are disabled and the job class of these jobs is altered to the default job
class. For example, to drop the JOBCLASS1 job class and disable all the jobs in JOBCLASS1, run the
following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.DROP_JOB_CLASS(
3 JOB_CLASS_NAME => 'jobclass1',
4 FORCE => TRUE);
5 END;
Working with Windows

Windows enable you to activate different resource plans at different times. When a window is opened, the
resource plan associated with the window is activated to allocate resources to all running or scheduled
jobs. The SYS user owns all the windows you create.
167
Creating Windows
To create windows, you must have the MANAGE SCHEDULER privilege. You can create windows using the
CREATE_WINDOW procedure. The commonly used attributes of the CREATE_ WINDOW procedure are as
follows:
• WINDOW_NAME – Specifies the name of the window to be created.
• RESOURCE_PLAN – Specifies the name of the resource plan associated with the current window.
You can associate only one resource plan with a window.
• SCHEDULE_NAME – Specifies the name of the schedule associated with the current window.
• DURATION – Specifies the time interval for which a window will be open.
• WINDOW_PRIORITY – Specifies a priority value that determines the window that will be open
when two or more windows overlap. You can assign one of the two values to the
WINDOW_PRIORITY attribute, HIGH or LOW. The default value of the WINDOW_PRIORITY attribute
is LOW.
• COMMENTS – Stores a description of the window.
You can create windows in the Scheduler either using a previously created schedule or by specifying a
schedule while creating the window. You must replace the SCHEDULE_NAME attribute with the
START_DATE, END_DATE, and REPEAT_INTERVAL attributes if you do not create a window using a
previously created schedule.
The following is an example of creating a window using the CREATE_WINDOW procedure. For example, to
create the WINDOW1 window, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.CREATE_WINDOW(
3 WINDOW_NAME =>'window1',
4 RESOURCE_PLAN =>NULL,
5 START_DATE =>SYSTIMESTAMP,
6 DURATION =>INTERVAL '60' MINUTE,
7 REPEAT_INTERVAL =>'FREQ=DAILY;BYHOUR=8',
8 WINDOW_PRIORITY =>'HIGH',
9 COMMENTS =>'This is my first window');
10 END;
The WINDOW1 window will remain open for 60 minutes on the current date and will reopen everyday after
every eight hours.
168
Opening Windows
When you open a window, the Scheduler switches to the resource plan associated with the window. A
window will open based on the schedule specified when the window was created or manually by using
the OPEN_WINDOW procedure.
You can open a window by using the OPEN_WINDOW procedure. You can specify the duration for which
the window is open by using the DURATION attribute. This duration overwrites the duration specified while
creating the window. The OPEN_WINDOW procedure opens a window irrespective of its schedule. By
default, if you open a window when another window is open, the Scheduler generates an error. You can
set the FORCE attribute to TRUE if you are using the OPEN_WINDOW procedure to open a window when
another window is open. In this case, the Scheduler automatically closes the open window even if the
open window is assigned the HIGH priority. For example, to open a new window named window1 when
another window is open, run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.OPEN_WINDOW(
3 WINDOW_NAME => 'window1',
4 FORCE => TRUE);
5 END;
Note: If you try to open a window that does not exist, the Scheduler generates an error.
Enabling Windows
You can enable a window by using the ENABLE procedure. The ENABLE procedure accepts the name of
the window as an attribute. You can also enable multiple windows simultaneously by providing a comma-
delimited list of window names as an attribute of the ENABLE procedure. To enable windows, you must
add the SYS prefix to the names of the windows. For example, to enable the WINDOW1 window, run the
SQL> BEGIN
2 DBMS_SCHEDULER.ENABLE('SYS.window1');
3 END;
Altering Windows
You can alter all the attributes of a window except the name of the window. You can alter a window by
using the SET_ATTRIBUTE procedure. When you alter the attributes of a window while the window is
open, the altered attributes do not affect the window. For example, to alter the WINDOW1 window and
change its RESOURCE_PLAN attribute to RESOURCEPLAN2, run the following statements at the SQL
prompt:
SQL> BEGIN
3 NAME => 'window1',
4 ATTRIBUTE => 'RESOURCE_PLAN',
5 VALUE => 'resourceplan2');
6 END;
169
Closing a Window
You can close a window according to the schedule specified when the window was created or by using
the CLOSE_WINDOW procedure. Closing a window does not affect the currently running jobs that are using
the window. A window is closed either when its duration is over or when you manually close the window
by using the CLOSE_WINDOW procedure.
For example, to manually close the WINDOW1 window using the CLOSE_WINDOW procedure, run the
SQL> BEGIN
2 DBMS_SCHEDULER.CLOSE_WINDOW(
3 WINDOW_NAME => 'window1');
4 END;
Note: If you try to close a window that is not open or does not exist, the Scheduler generates an error.
Disabling Windows
You can disable a window by using the DISABLE procedure. When you disable a window, the currently
running jobs using that window are not affected. The DISABLE procedure accepts two attributes, NAME
and FORCE. The NAME attribute specifies the name of the window to be disabled. To disable a window
that is open or currently being used by a job, you must set the FORCE attribute to TRUE. To disable
windows, you must add the SYS prefix to the names of the windows. For example, to disable the
unopened WINDOW1 window which is not being used by any job, run the following statements at the SQL
prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.DISABLE('SYS.window1');
3 END;
Dropping a Window
You can drop a window by using the DROP_WINDOW procedure. The DROP_WINDOW procedure accepts
two attributes, WINDOW_NAME and FORCE. The WINDOW_NAME attribute specifies the window to be
dropped. To drop an open window or a window that is referenced by a currently running job, you must set
the FORCE attribute to TRUE. When you drop a window, all the metadata information for the window is
removed from the *_SCHEDULER_WINDOWS views. Dropping a window does not affect the currently
running jobs that are using the window.
For example, to drop the WINDOW1 window run the following statements at the SQL prompt:
SQL> BEGIN
2 DBMS_SCHEDULER.DROP_WINDOW('window1');
3 END;
170
Job and Window Logs

Job and window logs maintain information about jobs, job runs, and windows. A new entry is inserted into
the respective logs whenever a job or a window-related event, such as altering or dropping a job or
window, occurs.
Job Logs
An entry is inserted into the job log whenever you create, alter, enable, disable, run, or drop a job. You
can query the DBA_SCHEDULER_JOB_LOG view to retrieve the contents of the job log. To query the
DBA_SCHEDULER_JOB_LOG view, run the following statement at the SQL prompt:
SQL> SELECT log_date, job_name, owner, operation

2 FROM dba_scheduler_job_log;
You can also query the DBA_SCHEDULER_JOB_RUN_DETAILS view to view the log details maintained for
all Scheduler jobs in the database. For example, to view the information about a particular job run for the
job1 job, run the following statement at the SQL prompt:
SQL> SELECT log_id, log_date, owner, job_name, status

2 FROM dba_scheduler_job_run
3 WHERE job_name = 'job1';
Logging Levels for Jobs
You can also control the level of logging that the Scheduler performs on a job. The three logging levels
are as follows:
• DBMS_SCHEDULER.LOGGING_OFF – Specifies that the Scheduler will not perform logging for jobs
• DBMS_SCHEDULER.LOGGING_RUNS – Specifies that the Scheduler will maintain detailed

information regarding all the runs for each job in a specific job class
• DBMS_SCHEDULER.LOGGING_FULL – Specifies that the Scheduler will maintain information

regarding all the operations performed for all the jobs in a specific job class
While creating a job class, you can specify the logging level for a job class by setting the
LOGGING_LEVEL attribute to the required logging level. You can also specify the LOGGING_LEVEL
attribute for an individual job. To specify the DBMS_SCHEDULER.LOGGING_FULL level for the job1 job,
run the following statement at the SQL prompt:
SQL> EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('job1', 'LOGGING_LEVEL',

2 DBMS_SCHEDULER.LOGGING_FULL);
171
Window Logs
An entry is inserted into the window log for every window operation, such as creating, dropping, closing,
and enabling. You can query the DBA_SCHEDULER_WINDOW_LOG view to retrieve the contents of the
window log. To query the DBA_SCHEDULER_WINDOW_LOG view, run the following statement at the SQL
prompt:
SQL> SELECT LOG_DATE, WINDOW_NAME,OPERATION FROM

2 DBA_SCHEDULER_WINDOW_LOG;
You can also query the DBA_SCHEDULER_WINDOW_DETAILS view to view the log details maintained for
all Scheduler windows in the database. For example, to view the information about a particular window,
window1, run the following statement at the SQL prompt:
SQL> SELECT log_id, log_date, window_name, window_duration

2 FROM dba_scheduler_window_details
3 WHERE window_name = 'window1';
The DBA_SCHEDULER_WINDOW_LOG view contains the LOG_ID column which maintains a log ID for each
Scheduler window. The rows corresponding to each value of the LOG_ID column contains specific
information regarding the Scheduler windows that are open.
Purging Logs
By default, the Scheduler runs daily and purges the window and job logs based on the value specified by
the LOG_HISTORY attribute. The value of the LOG_HISTORY attribute specifies the number of days that
you need to retain the window and the job log entries. The default value of the LOG_HISTORY attribute is
30, indicating that window and job log entries older than 30 days are purged. You can override this
default setting to specify the time required to retain the log entries using the
SET_SCHEDULER_ATTRIBUTE procedure and setting a new value for the LOG_HISTORY attribute. You
can specify the new value for the LOG_HISTORY attribute in the ATTRIBUTE attribute. The VALUE
attribute specifies the value of the LOG_HISTORY attribute. For example, to change the number of days
for window and job log retention to 40, run the following statement at the SQL prompt:
SQL> EXEC DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('LOG_HISTORY', '40');
You can set the value of the LOG_HISTORY attribute for an individual job class by using the
SET_ATTRIBUTE procedure. For example, to specify that the job and window log entries associated with
the jobclass1 job class should be retained for 90 days, run the following statement at the SQL prompt:
SQL> EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('jobclass1', 'LOG_HISTORY', '90');
You can also manually purge the entries from the window and job logs by using the PURGE_LOG
procedure. The PURGE_LOG procedure accepts three attributes: LOG_HISTORY, WHICH_LOG, and
JOB_NAME. The LOG_HISTORY attribute specifies the number of days for which log entries should be
retained. The WHICH_LOG attribute specifies the type of log being purged. The WHICH_LOG attribute
accepts either the JOB_LOG, WINDOW_LOG, or JOB_AND_WINDOW_LOG values. The value of the
172
JOB_NAME attribute specifies a job name or class or a comma-delimited list of job names or job classes to
purge log entries specific to particular jobs. To use the PURGE_LOG procedure to purge all job and window
log entries, run the following statement at the SQL prompt:
SQL> EXEC DBMS_SCHEDULER.PURGE_LOG();
To purge the entries of the job logs that are older than five days, run the following statement at the SQL
prompt:
SQL> EXEC DBMS_SCHEDULER.PURGE_LOG(LOG_HISTORY=>5,WHICH_LOG=>'JOB_LOG');
To purge the entries from both the job and window logs that are older than five days, run the following
SQL> EXEC DBMS_SCHEDULER.PURGE_LOG(LOG_HISTORY=>5,JOB_NAME='job1,

2 SYS.jobclass1');
The above statement purges the job and window logs for the job1 job of the jobclass1 job class.
Using Scheduler Views

You can query various views to retrieve information about the components of the Scheduler. Table 7-1
displays some of the views that are used to query information regarding the components of the
Scheduler:
Views Description
DBA_SCHEDULER_PROGRAMS Displays information about Scheduler programs.
ALL_SCHEDULER_PROGRAMS
USER_ SCHEDULER_PROGRAMS
DBA_SCHEDULER_PROGRAMS_ARGUMENTS Displays information about the arguments of Scheduler
ALL_SCHEDULER_PROGRAMS_ARGUMENTS programs.
USER_SCHEDULER_PROGRAMS_ARGUMENTS
DBA_SCHEDULER_JOBS Displays information about Scheduler jobs.
ALL_SCHEDULER_ JOBS
USER_SCHEDULER_JOBS
DBA_SCHEDULER_JOBS_ARGUMENTS Displays information about the arguments of Scheduler
ALL_SCHEDULER_JOBS_ARGUMENTS jobs.
USER_SCHEDULER_JOBS_ARGUMENTS
DBA_SCHEDULER_JOB_CLASSES Displays information about Scheduler job classes.
ALL_SCHEDULER_JOB_CLASSES
DBA_SCHEDULER_GLOBAL_ATTRIBUTES Displays information about the global attributes of the
ALL_SCHEDULER_GLOBAL_ATTRIBUTES Scheduler.
DBA_SCHEDULER_WINDOWS Displays information about Scheduler windows.
ALL_SCHEDULER_WINDOWS
DBA_SCHEDULER_WINDOW_GROUPS Displays information about Scheduler window groups.
ALL_SCHEDULER_WINDOW_GROUPS
173
Views Description
DBA_SCHEDULER_WINGROUP_MEMBERS Displays information about the members of all the
ALL_SCHEDULER_WINGROUP_MEMBERS window groups.
DBA_SCHEDULER_RUNNING_JOBS Displays information about currently executing jobs.
ALL_SCHEDULER_RUNNING_JOBS
USER_SCHEDULER_RUNNING_JOBS
DBA_SCHEDULER_SCHEDULES Displays information about Scheduler schedules.
ALL_SCHEDULER_ATTRIBUTES
Table 7-1: The Scheduler Views
174
Review Checklist: Managing Resources and Automating Tasks:

Use the Database Resource Manager.
Configure the Database Resource Manager.
Create and manage resource consumer groups.
Create and manage resource plans.
Create and manage resource plan directives.
Use the Scheduler.
Create and manage jobs in the Scheduler.
Create and manage programs in the Scheduler.
Create and manage schedules in the Scheduler.
Create and manage job classes in the Scheduler.
Create and manage windows in the Scheduler.
Manage logs in the Scheduler.
Query the Scheduler views.
175
Understanding Diagnostic Resources

and Securing the Listener: Oracle
10g Administration II
176
Understanding Diagnostic Resources

Scope
• Introduce the alert log.
• View the alert log.
• Use trace files.
• Control the location and size of trace files.
Focused Explanation
Oracle 10g provides two diagnostic resources, the alert log and trace files. These diagnostic resources
enable you to diagnose and troubleshoot database-related problems, such as errors in background
processes and corruption of a database block.
The Alert Log
The database alert log maintains logs and timestamps of events that occur in the database. The alert log
is automatically created for the Oracle database. The default name of the alert log is alert_SID.log,
where SID is the System Identifier (SID) for the database. The alert log maintains logs and timestamps
for the following database events:
• Administrative events – database events that occur when you issue CREATE, ALTER, or DROP
statements
• Redo log switches – database events that occur when the database switches from one redo log
file to another
• Checkpoints – database events that occur when data stored in redo log buffers is sent to online
redo log files
• Recovery operations – events that occur while recovering the database
• Database startup and shutdown – events that occur when you issue commands to start up or
shut down a database instance
• ALTER SYSTEM operations – events that occur when you alter a database instance
• Database internal errors – events that occur when a database error occurs
• Startup of background processes – an event that occurs when background processes start up
Note: The alert log is stored in the location specified by the BACKGROUND_DUMP_DEST initialization
parameter.
177
Viewing the Alert Log
The alert log stores detailed information about the events that occur in a database. You can view the alert
log by using a text editor, Enterprise Manager Database Control, or by querying external tables.
Note: External tables enable you to query the data that is stored outside the database in flat files.
To view the alert log of a database using Enterprise Manager Database Control, perform the following
steps:
2. Click the Alert Log Content link under the Related Links section. The content of the alert log is
displayed.
You can also view the alert log using external tables. To view the alert log using the external table
feature, perform the following steps:
1. Create a directory object that references the location at which the alert log is stored. An example
of the statement to create the directory object is shown below:
SQL> CREATE DIRECTORY bdump as '/data/admin/ora1/bdump';
2. Create a table, ALERT_LOG, which references the directory object. Issue the following statement
at the SQL prompt to create the ALERT_LOG table:
SQL> CREATE TABLE ALERT_LOG (LOG_LINE VARCHAR2(100))

2 ORGANIZATION EXTERNAL (
3 TYPE ORACLE_LOADER
4 DEFAULT DIRECTORY bdump
5 ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE)
6 LOCATION ('alert_ora1.log')))
Trace Files
A trace file is generated whenever a problem occurs in a background or server process. The trace files for
background and server processes contain the details about the problems generated and the state of the
background and server processes when a problem occurred. You can view the trace file by using a text
editor such as Notepad.
178
Controlling the Location and Size of Trace Files
The following initialization parameters are specified in the initialization parameter file of a database to
control the location and size of trace files:
BACKGROUND_DUMP_DEST – Specifies the path where the trace files for background processes
are stored. The following example specifies that the trace files for background processes will be
stored in the c:\ora\oradata directory:
BACKGROUND_DUMP_DEST='c:\ora\oradata'
• USER_DUMP_DEST – Specifies the path where the trace files for server processes are stored. The
following example specifies that the trace files for server processes will be stored in the
c:\ora\ora1 directory:
USER_DUMP_DEST='c:\ora\ora1'
• MAX_DUMP_FILE_SIZE – Specifies the number of operating system blocks a trace file can use to
store the details of the problems and the state of the background and server processes. The
default value of this initialization parameter is UNLIMITED, which specifies that the size of trace
files is unlimited. You can also specify the value of this initialization parameter in kilobytes or
megabytes by suffixing the numeric value of the initialization parameter with K and M,
respectively. The following example specifies that the size of the trace file is set to 2000 MB:
MAX_DUMP_FILE_SIZE= 2000M
Naming Conventions of Trace Files
The name of a trace file is automatically generated by Oracle. The name of a trace file for a process takes
one of the following two formats, depending on whether the process is a background process or a server
process:
• SID_PROCESSNAME_PID.trc – Represents the naming convention for the trace files of

background processes
• SID_ORA_PID.trc – Represents the naming convention for the trace files of server processes
The following are the parameters in the naming formats of a trace file:
• SID – Represents the system identification number of the Oracle database instance in which the
process is running
• PID – Represents the process identification number of the process
• PROCESSNAME – Represents the name of the process for which the trace file is created
179
The following is an example of the name of a trace file for a background process:
nt78_smon_1234.trc
The following is an example of the name of a trace file for a server process:
vc12_ORA_1246.trc
180
Securing the Listener

Scope
• Understand the purpose of the listener.
• Manage the listener remotely. Secure the listener using a password.
• Secure the listener by controlling database access, by enabling listener logging, by removing entries
for external procedures from the listener.ora file, and by creating a separate listener for external
procedures.
Focused Explanation
Introduction to Listener
The listener is a server-based process that receives connection requests from clients and establishes
connections between the clients and a database server. The listener can receive a connection request
from a client either on a remote computer or on the computer on which the listener is running. The listener
receives the connection request on the specified port on the database server. A connection request from
a client contains a user name, a password, and an SID or a service name to establish the connection.
When the listener receives a request to establish the connection on the specified port of the listener, the
listener performs the following tasks:
1. Checks whether or not the listener is configured to listen for the SID or service name specified in
the connection request.
2. Forwards the login information to the database instance corresponding to the SID or service
name in the connection request if the listener is configured to listen to that SID or service name.
3. Redirects the communication between the client and the database instance to another port where
the request is processed. The specified port of the listener is freed and able to receive new
incoming connection requests.
Invoking the Listener
You can invoke the listener by using the Listener Control utility. This utility provides the lsnrctl program
and various options to start and administer the listener. The lsnrctl program is stored in the
$ORACLE_HOME/bin directory on the UNIX platform and the $ORACLE_HOME\bin directory on the
Windows platform. When you start the listener, the listener reads the contents of the listener.ora file
to identify the services for which the listener needs to listen. The listener.ora file is a configuration file
that stores the following information about the listener:
• a unique name for the listener
• the protocol addresses on which the listener accepts connection requests
• the services for which the listener needs to listen
181
Note: The listener.ora file is stored in the $ORACLE_HOME/network/admin directory on the UNIX
platform and the $ORACLE_HOME\network\admin directory on the Windows platform.
Managing the Listener Remotely

In some situations, you may need to manage the listener remotely because the listener provides an
interface between database users and the services running on a remote database server. You can
manage the listener remotely by using the lsnrctl program. To set up a computer to manage the
listener remotely, perform the following steps:
1. Install Oracle on the remote computer from which the listener is to be managed.
2. Configure the listener.ora file on the remote computer to enable the listener.ora file to
resolve the Internet Protocol (IP) address of the remote database server. Insert the following
parameter and values in the listener.ora file to configure:
REMOTE_LISTENER =
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.168.0.245)
(PORT=1521)
)
)
REMOTE_LISTENER specifies the alias name of the listener and 192.168.0.245 specifies the IP
address of the remote database server.
3. Run the lsnrctl program on the remote computer by issuing the following command at the
command prompt:
lsnrctl REMOTE_LISTENER
After running the lsnrctl program, you can issue various commands to manage the listener
from the remote computer.
Securing the Listener Using a Password
You need to secure the listener because if you do not secure the listener, a malicious user having access
to the listener can either stop the listener or obtain information about the listener and modify the listener
settings. You can secure the listener by setting a password for the listener by editing the listener.ora
file or by using the CHANGE_PASSWORD command.
182
To set a password for the listener by using the listener.ora file, perform the following steps:
1. Open the listener.ora file by issuing the following command at the command prompt:
% EDIT listener.ora
2. Insert the following parameter and value in the listener.ora file to set the password for the
listener:
PASSWORDS_LISTENER = password
The password argument specifies the password to be set for the listener.
3. Save the listener.ora file, and restart the listener by issuing the following command at the
LSNRCTL> program prompt:
LSNRCTL> RELOAD
The drawback of setting the password for the listener by editing the listener.ora file is that the
password is not stored in an encrypted form. A database user having access to the listener.ora file
can edit the password.
You can also set and change the listener password by using the CHANGE_PASSWORD command. When
you set the password using the CHANGE_PASSWORD command, the password is stored in an encrypted
form. To set the password using the CHANGE_PASSWORD command, perform the following steps:
1. Issue the following command at the LSNRCTL> program prompt:
LSNRCTL> CHANGE_PASSWORD
You are prompted to enter the password for the listener.
2. Type the old password for the listener if you had previously set a password. Press the Enter key
if you have not set the password.
3. Type and confirm the password for the listener.
183
After you have set or changed the password for the listener, you must save the password. If you do not
save the password, the password will be applicable for only the current listener session. To save the
password, perform the following steps:
1. Issue the following command at the LSNRCTL> program prompt:
LSNRCTL> SET PASSWORD
You are prompted to type the password for the listener.
2. Issue the following command at the LSNRCTL> program prompt to save the new password to
the listener.ora file:
LSNRCTL> SAVE_CONFIG
The above command stores the password for the listener in an encrypted form.
Securing the Listener by Controlling Database Access
You can configure the listener to accept or deny connection requests from specific IP addresses. This
process is called valid node checking. By implementing valid node checking, you can control access to
the database. Valid node checking allows only application servers to access the database.
You can implement valid node checking by editing the sqlnet.ora file. The sqlnet.ora file is stored
in the $ORACLE_HOME\network\admin\ directory. You should add the following parameters to the
sqlnet.ora file to implement valid node checking:
• TCP.VALIDNODE_CHECKING – Specifies whether or not valid node checking should be

enabled. The YES parameter value specifies that valid node checking is enabled. The NO
parameter value specifies that valid node checking is disabled.
• TCP.INVITED_NODES – Specifies the IP addresses or host computer names from which the
listener should accept connection requests. The IP addresses or host computer names are
separated by commas.
• TCP.EXCLUDED_NODES – Specifies the IP addresses or host computer names to which the

listener should deny connection requests. The IP addresses or host computer names are
separated by commas.
Note: The TCP.INVITED_NODES and TCP.EXCLUDED_NODES parameters are mutually exclusive.

Wildcard characters are not allowed in the IP addresses or host computer names.
For example, to configure the listener to accept connection requests from an IP address,
192.0.186.254 and a host computer, John, insert the following parameters and values in the
sqlnet.ora file:
TCP.VALIDNODE_CHECKING=YES
TCP_INVITED_NODES=( 192.0.186.254,John)
184
Note: You must restart the listener after editing the sqlnet.ora file to make the changes effective.
Securing the Listener Using Listener Logging
You can also secure the listener by enabling the listener logging feature. The listener logging feature of
Oracle 10g creates and maintains a log file. The listener log file records all listener activities such as
incoming connection requests and the administrative commands issued to administer the listener. You
can scan the listener log file regularly to secure the listener against unauthorized attempts to manage the
listener. For example, if an unauthorized attempt is made to access the listener by using a wrong
password, the listener log file will contain a TNS-01169 error. You can also use a shell script to scan the
listener log file periodically. The shell script generates an alert if the number of failed attempts exceeds
the threshold limit defined in the shell script.
Enabling Listener Logging Using the lsrnctl Program
You can enable the listener logging feature by using the lsnrctl program. You need to set the following
parameters to enable the listener logging feature:
• LOG_DIRECTORY – Allows you to specify the location of the listener log file created for listener
logging. By default, the listener log file is stored in the $ORACLE_HOME\network\log directory.
To set the value of the LOG_DIRECTORY parameter, issue the following command at the
LSNRCTL program prompt:
LSNRCTL> SET LOG_DIRECTORY /oralogs
• LOG_FILE – Allows you to specify the name of the listener log file. The default value of this
parameter is listener_name.log, where listener_name specifies the name of the listener.
To set the value of the LOG_FILE parameter, issue the following command at the LSNRCTL
program prompt:
LSNRCTL> SET LOG_FILE listener_log.log
• LOG_STATUS – Allows you to enable and disable listener logging. This parameter can accept one
of two values, ON or OFF. The ON value enables listener logging, and the OFF value disables
listener logging. To set the value of the LOG_STATUS parameter to ON, issue the following
command at the LSNRCTL program prompt:
LSNRCTL> SET LOG_STATUS ON
After setting the values of the LOG_DIRECTORY, LOG_FILE and LOG_STATUS parameters, you must
save the changes made to these parameters by issuing the following command at the LSNRCTL program
prompt:
LSNRCTL> SAVE_CONFIG
Note: The SAVE_CONFIG command is used to save all runtime configuration changes such as changes in
the password to the listener.ora file.
185
Enabling Listener Logging Using Enterprise Manager Database Control
You can also enable listener logging using Enterprise Manager Database Control. To enable listener
logging by using Enterprise Manager Database Control, perform the following steps:
2. Click the link corresponding to the listener, for which the listener logging has to be enabled,
under the General section. The Listener Home page is displayed.
3. Click the Edit button. The Edit Listener: LISTENER page is displayed.
4. Click the Logging and Tracing tab. The Logging and Tracing tab page is displayed. Figure
8-1 displays the Logging and Tracing tab page.
Figure 8-1: The Logging and Tracing Tab Page
The Logging and Tracing tab page contains the following options:
• Logging Disabled – Disables listener logging
• Logging Enabled – Enables listener logging
• Log File – Specifies the location of the log file for the listener
186
5. Select the Logging Enabled option.
6. Click the OK button to enable listener logging. You are prompted to restart the listener.
7. Click the OK button to restart the listener.
Securing the Listener by Removing Entries for External Procedures
An external procedure refers to a procedure or function written in a third-generation language and called
from a PL/SQL block. For example, a PL/SQL block can call a function written in C. When an application
calls an external procedure, the listener starts an external procedure agent, extproc. The extproc
agent executes the external procedure and returns the results generated by the external procedure to the
application.
Oracle maintains entries in the listener.ora file to identify and execute the external procedures. A
malicious database user may attempt to modify and use entries in the listener.ora file to execute
malicious external code. Therefore, you should remove the entries that Oracle stores in the
listener.ora file to identify and execute external procedures. The following parameters and values are
the default content of the listener.ora file that contains the entries corresponding to the execution of
external procedures:
LISTENER=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=rd02)(PORT=1521))
(ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(GLOBAL_DBNAME=ora1.acme.com)
(ORACLE_HOME=/oracle)
(SID_NAME=ora1))
(SID_DESC=
(SID_NAME=plsextproc)
(PROGRAM=extproc)))
You should remove the entries for external procedures from the listener.ora file to secure the listener. The
following parameters and values represent the contents of the listener.ora file after you remove the
entries for external procedures:
LISTENER=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=rd02)(PORT=1521))))
SID_LIST_LISTENER=
(SID_LIST=
187
(SID_DESC=
(GLOBAL_DBNAME=ora1.acme.com)
(SID_NAME=ora1)))
Securing the Listener by Creating a Separate Listener for External Procedures
You can also create a separate listener for external procedures rather than removing the entries for
external procedures from the listener.ora file of the current listener. Creating a separate listener for
external procedures enables you to secure the current listener while executing external procedures. You
can use the separate listener to secure the current listener for external procedures by using the following
two methods:
• execute the listener using a database user account having limited operating system privileges
• limit the libraries from which external procedures can be called and executed by the listener
Executing the Listener Using a Database User Account Having Limited Operating System
Privileges
When an external procedure is called by an application, the listener starts an extproc agent process.
The extproc process inherits all the operating system privileges available to the user account that calls
the external procedure. Therefore, executing the listener using a database user account having limited
operating system privileges minimizes the security threat. The user account that executes the listener to
call an external procedure should not have permissions to perform read and write operations on the
address space and files of the Oracle database server. The user should have only read access to the
listener.ora file so that the user does not modify the entries in the listener.ora files that are used
to execute external procedures.
Limiting the Libraries from which External Procedures Can be Called and Executed by the
Listener
You can also create a new listener that you can use to limit the libraries from which external procedures
can be called and executed. By default, the extproc agent can execute external procedures stored in
the following directories:
• the lib directory at the location specified by the ORACLE_HOME environment variable on the
UNIX platform
• the bin directory at the location specified by the ORACLE_HOME environment variable on the
Windows platform
188
To limit the libraries from which external procedures can be called, you should modify the following
settings in the listener.ora file:
• PROGRAM – Specifies the name of the external procedure agent to which the listener starts to
execute an external procedure. An external procedure agent is an executable program that the
listener starts to execute an external procedure.
• ENVS – Defines environment variables, such as EXTPROC_DLLS, ORACLE_HOME, and

ORACLE_SID, required by the external procedure agent to execute an external procedure.
The ENVS setting specifies an environment variable, EXTPROC_DLLS, which enables you to limit the
libraries of external procedures that the listener can access. The following are the various methods you
can use to specify the value of the EXTPROC_DLLS environment variable of the ENVS setting in the
listener.ora file:
• Using a colon-separated list – Specifies the path of the libraries that can be accessed by the
listener. The paths of the libraries are specified in a colon-separated list. In addition to these
libraries, the listener can access the libraries available by default.
• Using the ONLY directive – Limits the listener to access only specific libraries. You use a colon-
separated list starting with the ONLY keyword to specify the complete path of the libraries that can
be accessed by the listener. When the ONLY directive is used, the listener cannot access the
libraries available by default.
• Using the ANY directive – Allows the listener to access any library from which external procedures
can be called.
The following example shows how to set the ENVS settings:
ENVS=(”EXTPROC_DLLS=ONLY:/usr/libjava.so:usr/lib/libsql.so,
ORACLE_SID=orcl,PATH=$PATH:/usr/bin:/usr/sql”)
Creating a New Listener Using Enterprise Manager Database Control
To create and configure a new listener that can listen to the requests from the database users, who have
limited operating system privileges, perform the following steps:
2. Click the link for the default listener of the database under the General section. The Serviced
Databases page is displayed.
3. Click the Net Services Administration link under the Related Links section. The Net Services
Administration page is displayed.
4. Select the Listeners option in the Administer drop-down list.
5. Click the Go button. The Listeners page is displayed.
189
6. Click the Create button. The Create Listener page is displayed. Figure 8-2 shows the Create
Listener page.
Figure 8-2: The Create Listener Page
7. Type the name of the new listener in the Listener Name text box.
8. Click the Add button to continue. The Add Address page is displayed. This page displays the
default value of protocol as TCP/IP in the Protocol drop-down list box and name of the host
computer in the Host text box.
9. Select the IPC option from the Protocol drop-down list box.
10. Type 1522 as the port number in the Port text box.
11. Click OK to continue. The Create Listener page is displayed again.
12. Click the OK button to continue. The Creation Message page is displayed.
13. Click the Other Services tab. The Other Services tab page is displayed.
14. Click the Add button. The Create Other Services page is displayed. Figure 8-4 shows the
Create Other Services page.
190
Figure 8-4: The Create Other Services Page
15. Click the Add Another Row button under the Environment Variables section. A page is
displayed where you can specify the name and value of an environment variable.
16. Type EXTPROC_DLLS in the Name text box to specify the environment variable for accessing
libraries of external procedures.
17. Specify the path and the file name of the libraries from which the listener can access external
procedures in the Value text box.
18. Click the OK button to continue. The Create Listener page is displayed.
19. Click the OK button to continue. The listener is added to the Listeners page. This listener can
listen to the requests from the database users who enjoy limited operating system privileges.
191
Review Checklist: Understanding Diagnostic Resources and Securing

the Listener: Oracle 10g Administration II
Know the purpose of the alert log.
Know how to view the alert log.
Know the purpose of the trace files.
Control the location and size of trace files.
Know the purpose of the listener.
Manage the listener remotely.
Secure the listener using a password.
Secure the listener by controlling database access.
Secure the listener by enabling listener logging.
Secure the listener by removing entries for external procedures from the listener.ora file.
Secure the listener by creating a separate listener for external procedures.
192
Monitoring and Managing Storage:

193
Understanding Resumable Space Allocation

Scope
• Introduce the resumable space allocation feature.
• Enable and disable resumable space allocation.
• Use the DBMS_RESUMABLE package to control resumable space allocation.
• Use the AFTER SUSPEND system event and trigger.
• View information about resumable statements.
Focused Explanation
Oracle 10g provides resumable space allocation that prevents failure of long running database operations
from space-related errors in the database.
Resumable Space Allocation

The execution of long running database operations can fail due to errors related to space limits. The
resumable space allocation feature of Oracle 10g enables you to first suspend and later resume the
execution of long running database operations. As a result, errors in long running database operations
can be corrected and the failure of long running database operations can be prevented. After you correct
the errors using resumable space allocation, the suspended operations are resumed.
Resumable Operations and Statements
The operations that are affected due to resumable space allocation are called resumable operations. The
resumable operations are suspended if any one of the following conditions occurs:
• The tablespace used by a long running operation runs out of space. This condition is called the
out of space condition. For example, one of the following errors is generated when the out of
space condition occurs:
ORA-01654 unable to extend index...in tablespace...
ORA-01653 unable to extend table...in tablespace...
• The maximum number of extents specified for a database object, such as a table or an index, is
already allocated to the database object, and no further extents can be allocated. This condition
is called the maximum extents reached condition. For example, one of the following errors is
generated when the maximum extents reached condition occurs:
ORA-01631 max # extents...reached in table...
ORA-01632 max # extents...reached in index...
194
• The space quota assigned to the database user who is executing a long running operation is
exhausted. This condition is called the space quota exceeded condition. The following error is
generated when the space quota exceeded condition occurs:
ORA-01536 space quota exceeded for tablespace 'tablespace_name'
The statements that are contained in the long running operations and are affected due to resumable
space allocation are called resumable statements. The different types of resumable SQL statements and
operations are as follows:
• The SELECT statements issued to perform sorting operations that run out of space due to
exhaustion of space
• The INSERT, UPDATE, DELETE, INSERT INTO...SELECT statements
• The statements used to import or export a database or database objects
• The following Data Definition Language (DDL) statements:
o CREATE TABLE...AS SELECT
o CREATE INDEX
o CREATE MATERIALIZED VIEW
o CREATE MATERIALIZED VIEW LOG
o ALTER INDEX...REBUILD
o ALTER TABLE...MOVE PARTITION
o ALTER TABLE...SPLIT PARTITION
o ALTER INDEX...REBUILD PARTITION
o ALTER INDEX...SPLIT PARTITION
The execution of a resumable statement is suspended if any of the conditions that lead to the suspension
of the resumable statement is satisfied. When the execution of a resumable statement is suspended, the
following tasks are performed:
• An error is inserted into the alert log.
• Oracle generates the Resumable Session Suspended alert. This alert specifies that the execution
of a resumable statement is suspended.
• If a database user has defined a trigger to be executed when the resumable statement is
suspended, the trigger is executed.
195
Enabling and Disabling Resumable Space Allocation
You must enable resumable space allocation before using it. You can enable and disable resumable
space allocation either by using the RESUMABLE_TIMEOUT initialization parameter or by issuing the
ALTER SESSION statement.
Using the RESUMABLE_TIMEOUT Initialization Parameter
The RESUMABLE_TIMEOUT initialization parameter allows you to enable and disable resumable space
allocation for all the sessions in the database. This initialization parameter specifies the timeout period.
The timeout period specifies that if you do not correct the error generated within a specified time period,
the transaction containing the resumable statement is aborted and rolled back. For example, to enable
resumable space allocation for all the sessions, insert the following parameter and value in the database
initialization parameter file:
RESUMABLE_TIMEOUT = 3000
The above parameter and value enables resumable space allocation and sets the timeout period to 3000
seconds.
To disable resumable space allocation, set the value of the RESUMABLE_TIMEOUT parameter to 0 by
inserting the following parameter and value in the database initialization parameter file:
RESUMABLE_TIMEOUT = 0
Using the ALTER SESSION Statement
The ALTER SESSION statement allows you to enable resumable space allocation at the session level. To
enable resumable space allocation at the session level, issue the following statement at the SQL prompt:
SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 3000;
The above statement enables resumable space allocation and sets the timeout period to 3000 seconds.
You can name the statements used to enable resumable space allocation by using the NAME clause of
the ALTER SESSION statement. Naming the statements enables you to refer to the names assigned to
the statements while querying various data dictionary views. Naming the statements also enables you to
retrieve information about these statements. For example, to name the above ALTER SESSION
statement, issue the following statement at the SQL prompt:
SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 3000 NAME 'Insert statement';
If you do not specify a name for a statement that is used to enable resumable space allocation, Oracle
generates a unique name for the resumable statement.
To disable resumable space allocation at the session level by using the ALTER SESSION statement, issue
SQL> ALTER SESSION DISABLE RESUMABLE;
196
Controlling Resumable Space Allocation Using the DBMS_RESUMABLE Package
The DBMS_RESUMABLE package provides various procedures and functions to control resumable space
allocation. For example, you can control the timeout period of resumable space allocation for the current
session by using the SET_SESSION_TIMEOUT procedure in the DBMS_RESUMABLE package. The
commonly-used procedures and functions of the DBMS_RESUMABLE package are as follows:
• ABORT(sessionID) – Cancels the execution of a suspended resumable statement. The

sessionID parameter specifies the session ID of the session in which the resumable statement
is executing.
• GET_SESSION_TIMEOUT(sessionID) – Returns the timeout period of resumable space

allocation for the session with the sessionID session ID. If the session with the specified
session ID does not exist, this function returns -1. The timeout period is specified in seconds.
• SET_SESSION_TIMEOUT(sessionID,timeout) – Sets the timeout period of resumable space

allocation for the session with the sessionID session ID. If the session with the specified
session ID does not exist, no error is generated.
• GET_TIMEOUT() – Returns the current timeout period of resumable space allocation for the
current session.
• SET_TIMEOUT(timeout) – Sets the timeout period of resumable space allocation for the
current session.
The following is an example of a statement issued to retrieve the timeout period of resumable space
allocation for the current session from the DUAL table:
SQL> EXEC DBMS_RESUMABLE.GET_TIMEOUT() FROM DUAL;
Note: DUAL is a table, which is created with the Oracle database data dictionary. This table is accessible
to every user. The DUAL table contains a single column, DUMMY.
Using the AFTER SUSPEND System Event and Trigger
Whenever a resumable statement is suspended and a correctable error is generated, Oracle generates
the AFTER SUSPEND system event. You can create a trigger for the AFTER SUSPEND system event to
automatically correct the error. The trigger created for the AFTER SUSPEND system event is called the
AFTER SUSPEND trigger and is executed after a SQL statement is suspended. You can insert SQL
statements in this trigger to correct the error. In addition, you can insert a statement to increase the
timeout period of resumable space allocation to ensure that the suspended statement is not aborted for a
long time.
The following example illustrates the creation of an AFTER SUSPEND trigger:

CREATE OR REPLACE resumable_timeout
AFTER SUSPEND ON DATABASE
BEGIN
DBMS_RESUMABLE.SET_TIMEOUT(28800);
197
END;
Viewing Information about Resumable Statements
You can use two data dictionary views, DBA_RESUMABLE and USER_RESUMABLE, to retrieve information
such as the name, owner, and status of resumable statements. The DBA_RESUMABLE view displays
information such as session ID, name, and status of all the currently executing or suspended resumable
statements in all sessions. The commonly used columns of the DBA_RESUMABLE view are as follows:
• USER_ID – Specifies the user ID of the owner of a resumable statement.
• SESSION_ID – Specifies the session ID of the resumable statement.
• STATUS – Specifies the status of the resumable statement. This column can contain one of the
following values:
o RUNNING – Specifies that the resumable statement is executing
o SUSPENDED – Specifies that the resumable statement is suspended
o TIMEOUT – Specifies that the timeout period of the resumable statement is exhausted
o ERROR – Specifies that an error is generated during the execution of the resumable
statement
o ABORTED – Specifies that the execution of the resumable statement is aborted
• TIMEOUT – Specifies the timeout period of the resumable statement.
• START_TIME – Specifies the time when the resumable statement started executing.
• SUSPEND_TIME – Specifies the time when the resumable statement was last suspended.
• RESUME_TIME – Specifies the time when the resumable statement was last resumed.
• NAME – Specifies the name of the resumable statement.
The USER_RESUMABLE view displays information, such as session ID, name, and status of all the
currently executing or suspended resumable statements, in the current session. The USER_RESUMABLE
view contains all the columns present in the DBA_RESUMABLE view, except the USER_ID column.
198
Using Segment Shrink and the Segment Advisor

Scope
• Define the purpose of the segment shrink.
• Shrink segments using SQL statements and the Enterprise Manager Database Control.
• Identify the purpose of the Segment Advisor.
• Use the Segment Advisor with the Enterprise Manager Database Control and the DBMS_ADVISOR
package.
Focused Explanation
Using Segment Shrink
The Oracle 10g segment shrink feature enables the management and compression of segments in a
tablespace. This feature reduces the number of I/O cycles required to access a segment. The segment
shrink feature can also move the High Water Mark (HWM) to free the unused space for other segments
on the disk.
Shrinking Segments
You can shrink the segments in a tablespace by automatic segment space management. You can shrink
segments in the following database objects:
• Heap-organized and index-organized tables
• Indexes
• Partitions and subpartitions in tables and indexes
• Materialized views and materialized view logs
You can shrink segments either by using SQL statements or by using the Enterprise Manager Database
Control.
Shrinking Segments Using SQL Statements
Before shrinking segments by using SQL statements, you must enable row movement in the database
object that will shrink. For example, to enable row movement in the EMPLOYEE table, issue the following
SQL> ALTER TABLE employee ENABLE ROW MOVEMENT;
199
You can shrink the segments in a table by using the ALTER TABLE statement with the SHRINK SPACE
clause. For example, to shrink segments in the EMPLOYEE table, issue the following statement at the SQL
prompt:
SQL> ALTER TABLE employee SHRINK SPACE;
You can shrink index-organized tables, indexes, materialized views, or materialized view logs by using
the ALTER INDEX, ALTER MATERIALIZED VIEW, or ALTER MATERIALIZED VIEW LOG statements,
respectively, with the SHRINK SPACE clause.
You can use two optional clauses, COMPACT and CASCADE, with the SHRINK SPACE clause. The
COMPACT clause enables you to divide the segment shrinking process into two phases. In the first phase,
Oracle defragments the segment space. In the second phase, Oracle resets the HWM and reallocates the
defragmented segment space. The COMPACT clause helps long running database operations to access
data from the blocks that are reclaimed during the first phase of the segment shrinking process. For
example, to shrink the segments in the EMPLOYEE table by using the COMPACT clause and to complete
the first phase, issue the following statement at the SQL prompt:
SQL> ALTER TABLE employee SHRINK SPACE COMPACT;
You can complete the second phase of the shrinking process by issuing the following statement:
SQL> ALTER TABLE employee SHRINK SPACE;
The CASCADE clause enables you to shrink the segments in a database object, along with its dependent
objects. For example, to shrink the EMPLOYEE table along with its dependent objects, issue the following
SQL> ALTER TABLE employee SHRINK SPACE CASCADE;
If you do not specify the CASCADE clause, you must identify the objects that are dependent on the
database object and shrink the segments in the dependent objects individually.
Shrinking Segments Using the Enterprise Manager Database Control
To shrink the segments in a table by using the Enterprise Manager Database Control, adhere to the
following steps:
1. Open the Enterprise Manager Database Control in a Web browser.
200
3. Click the Tables link under the Schema section. Figure 9-1 shows the Tables page.
Figure 9-1: The Tables Page
The Tables page contains the following sections:
• Search – Used to search for the database object to shrink. This section contains the
following options:
o Object Type – Used to specify the type of database object to shrink, such as a
table or index
o Schema – Used to specify the name of the schema associated with the
specified database object
o Object Name – Used to specify the name of the database object
• Results – Used to view the results of the search operation specified in the Search
section
4. Type the name of the table to be shrunk in the Object Name text box.
5. Click the Go button to search the table. The search results are displayed in the Results section.
6. Select the required table in the Results section.
201
7. Select the Shrink Segment option from the Actions drop-down list box.
8. Click the Go button to continue. The Shrink Segment: Options page is displayed. Figure 9-2
shows the Shrink Segment: Options page.
Figure 9-2: The Shrink Segment: Options Page
The Shrink Segment: Options page contains the following options:
• Compact Segments and Release Space – Used to compress segments in database

objects and release the recovered space to the segments’ tablespace
• Compact Segments – Used to compress segments without releasing the recovered

space
• Shrink <tablename> only – Shrinks only the segments in the specified table
• Shrink <tablename> and All Dependent Segments – Shrinks the segments in the
specified table and the table’s dependent objects, such as indexes and views
9. Click the Continue button to start shrinking the segments in the specified table.
202
Using the Segment Advisor

The Segment Advisor analyzes a database object to determine whether the database object has space
available to reclaim, based on the level of fragmentation within the object. The Segment Advisor can
analyze an entire database object.
Invoking the Segment Advisor
You can invoke the Segment Advisor by using either the Enterprise Manager Database Control or the
procedures in the DBMS_ADVISOR package. To invoke the Segment Advisor, you must have the
EXECUTE object or ADVISOR system privilege. When you invoke the Segment Advisor, an advisor task is
created. An advisor task is a procedure used to analyze a segment in a tablespace.
Note: Before invoking the Segment Advisor, you must enable row movement in the database objects to
be analyzed. Segment advisors move the rows in the database object to reclaim the space used by the
objects.
Invoking the Segment Advisor Using the Enterprise Manager Database Control
To invoke the Segment Advisor for a tablespace using the Enterprise Manager Database Control, perform
the following steps:
1. Click the Segment Advisor link. Figure 9-3 shows the Segment Advisor page.
3. Click the Advisor Central link.
203
Figure 9-3: The Segment Advisor Page
The Segment Advisor page displays the following options:
• Tablespaces – Requests feedback as to whether or not you should shrink an entire

tablespace
• Schema Objects – Requests feedback as to whether or not you should shrink

individual database objects
• Complete Analysis of All Segments (Comprehensive) – Samples the available

statistics for the database objects to be analyzed and generates recommendations
• Analysis based on Available Statistics (Limited) – Analyzes the segments of

database objects based on the available statistics about the segments
4. Click the Continue button to continue. The Segment Advisor: Tablespaces page displays
the tablespaces you can analyze by using the Segment Advisor.
5. Select the option corresponding to the tablespace, such as USERS, to be analyzed.
6. Click the Next button to continue. The Segment Advisor: Options page is displayed. The
Segment Advisor: Options page contains the following options:
• Time Limit for Analysis – Specifies the time for which the USERS tablespace should be
analyzed. This option contains the following suboptions:
o Unlimited – Specifies that a tablespace should be analyzed for unlimited time
204
o Limited – Specifies a time limit for which a tablespace should be analyzed
• Advisory Results Retention (days) – Specifies the time for which the result of analysis of
a tablespace should be retained.
7. Click the Next button to continue. The Segment Advisor: Schedule page is displayed. The
Segment Advisor: Schedule page contains the following options:
• Task Name – Used to specify the name of an advisor task that is created to analyze a
tablespace
• Task Description – Used to specify the description of the advisor task
• Schedule Type – Used to specify the type of schedule that is used by the Segment
Advisor to analyze the tablespace
• Repeat – Used to specify whether or not the advisor task should be repeated
8. Type Task1 as the name of the task in the Task Name text box.
9. Select the required scheduling options.
10. Click the Next button to continue. The Segment Advisor: Review page is displayed. This
page allows you to view the scheduling options before applying them.
11. Click the Submit button. The advisor task is submitted to the Segment Advisor for execution.
The Advisor Central page is displayed after the Segment Advisor completes the analysis of
the specified tablespace.
12. Click the name of the advisor task to view the results of the analysis of a database object. The
Segment Advisor Task: Task1 page is displayed. You can perform the tasks recommended
by the Segment Advisor in the Recommendations column to reclaim the fragments in the
USERS tablespace.
Invoking the Segment Advisor Using the DBMS_ADVISOR Package
The DBMS_ADVISOR package includes the following procedures to invoke the Segment Advisor:
• CREATE_TASK
• CREATE_OBJECT
• SET_TASK_PARAMETER
• EXECUTE_TASK
205
The CREATE_TASK Procedure
You can use the CREATE_TASK procedure to create an advisor task. The commonly-used attributes of
the CREATE_TASK procedure are as follows:
• advisor_name – Specifies the name of the advisor used to analyze database objects.
• task_id – Specifies the unique number generated to identify the advisor task. The number is
an output attribute and is returned to the database user executing the advisor task.
• task_name – Specifies the name of the advisor task being created.
The CREATE_OBJECT Procedure
You can use the CREATE_OBJECT procedure to identify the database object to be analyzed. This
procedure accepts five input attributes: OBJECT_TYPE, ATTR1, ATTR2, ATTR3, and ATTR4. The values of
these attributes depend on the type of database object being analyzed. Table 9-1 shows the input
attributes of the CREATE_OBJECT procedure and their corresponding values for different database
objects.
Database OBJECT_TYPE ATTR1 ATTR2 ATTR3 ATTR4

Object
Tablespace TABLESPACE tablespace_name NULL NULL NULL
Table TABLE schema_name table_name NULL NULL
Index INDEX schema_name index_name NULL NULL
Table TABLE schema_name table_name tablepartition_n NULL

partition PARTITION ame
Index INDEX schema_name index_name indexpartition_n NULL

partition PARTITION ame
Table TABLE schema_name table_name table_subpartiti NULL

subpartition SUBPARTITIO on_name
N
Index INDEX schema_name index_name index_subpartiti NULL

subpartition SUBPARTITIO on_name
N
Table 9-1: The Parameters of the CREATE_OBJECT Procedure
206
The SET_TASK_PARAMETER Procedure
The SET_TASK_PARAMETER procedure enables you to specify the type of advice that must be generated
by the Segment Advisor. The attributes of the SET_TASK_PARAMETER procedure are as follows:
• MODE – Specifies the data used by an advisor task to analyze a segment. This attribute can
accept one of two values, LIMITED or COMPREHENSIVE. The LIMITED value specifies that only
the statistics available in the Automatic Workload Repository (AWR) are used for the analysis.
The COMPREHENSIVE value specifies that both sampling and statistics available in the AWR are
used for the analysis.
• TIME_LIMIT – Specifies the time interval, in seconds, for which the Segment Advisor should run.
The default value of this attribute is UNLIMITED, which specifies that the Segment Advisor runs
for an unlimited interval of time.
• RECOMMEND_ALL – Specifies whether or not the Segment Advisor should generate

recommendations for all the segments. You can assign the TRUE or FALSE values to this
parameter. The TRUE value specifies that recommendations are generated for all the segments
you specified for the analysis. The FALSE value specifies that recommendations are generated
only for shrinkable segments.
The EXECUTE_TASK Procedure
You can use the EXECUTE_TASK procedure to execute an advisor task. This procedure accepts the name
of the advisor task to be executed as an attribute.
Analyzing Tables Using the Segment Advisor
You can use the CREATE_TASK, CREATE_OBJECT, and SET_TASK_PARAMETER procedures of the
DBMS_ADVISOR package to analyze a table. For example, to analyze a table, SCOTT, in the HR schema
by using the procedures in the DBMS_ADVISOR package, issue the following statements at the SQL
prompt:
SQL>DECLARE
2 l_object_id NUMBER;
3 BEGIN
4 -- Create a segment advisor task for the SCOTT.EMP table.
5 DBMS_ADVISOR.create_task (
6 advisor_name => 'Segment Advisor',
7 task_name => 'EMP_SEGMENT_ADVISOR',
8 task_desc => 'Segment Advisor For SCOTT');
9 DBMS_ADVISOR.create_object (
10 task_name => 'SCOTT_SEGMENT_ADVISOR',
11 object_type => 'TABLE',
12 attr1 => 'HR',
13 attr2 => 'SCOTT',
14 attr3 => NULL,
15 attr4 => 'NULL',
16 attr5 => NULL,
207
17 object_id => l_object_id);

18 DBMS_ADVISOR.set_task_parameter (
19 task_name => 'EMP_SEGMENT_ADVISOR',
20 parameter => 'RECOMMEND_ALL',
21 value => 'TRUE');
22 DBMS_ADVISOR.execute_task(task_name => 'EMP_SEGMENT_ADVISOR');
23 END;
You can view the task ID generated by the CREATE_TASK procedure to identify and implement the
recommendations generated by the Segment Advisor. You can view the task ID generated by the
CREATE_TASK procedure by issuing the PRINT command at the SQL prompt, as follows:
SQL> PRINT task_id
TASK_ID
-------------
670
By using the task ID, 670, generated by the PRINT command, you can query the
DBA_ADVISOR_FINDINGS view to view the results of the analysis completed by the Segment Advisor.
The commonly-used columns of the DBA_ADVISOR_FINDINGS view are as follows:
• OWNER – Specifies the name of the owner of an advisor task
• TASK_ID – Specifies the task ID of the advisor task
• MESSAGE – Specifies the message that describes the results generated by the Segment Advisor
• MORE_INFO – Specifies additional information about the analysis conducted by the Segment
Advisor
To query the DBA_ADVISOR_FINDINGS view and to retrieve the results of the analysis completed by the
Segment Advisor for the task ID 670, issue the following statement at the SQL prompt:
SQL> SELECT owner, message, more_info

2 FROM dba_advisor_findings
3 WHERE task_id = 670;
In the output of the above statement, the MESSAGE column indicates that you must enable row movement
in the SCOTT table before reclaiming the free space.
208
After retrieving the results of the analysis completed by the Segment Advisor, you must shrink the SCOTT
table to reclaim free space. You can identify the command to shrink the SCOTT table by querying the
DBA_ADVISOR_ACTIONS view. This view displays the information about the actions associated with all
the recommendations in the database. The commonly-used columns of the DBA_ADVISOR_ACTIONS
view are as follows:
• OWNER – Specifies the name of the owner of an advisor task
• TASK_ID – Specifies the task ID of the advisor task
• TASK_NAME – Specifies the name of the advisor task
• COMMAND – Specifies the command to implement a recommendation generated by the Segment

Advisor
• ATTR1 – Specifies the parameters of the command to implement a recommendation generated

by the Segment Advisor
For example, to query the DBA_ADVISOR_ACTIONS view and identify the command to implement the
recommendations for the SCOTT table, issue the following statement at the SQL prompt:
SQL> SELECT task_name, command, attr1

2 FROM dba_advisor_actions
3 WHERE task_id = 670;
After viewing the statement to shrink the SCOTT table, issue the recommended statement at the SQL
prompt as follows:
SQL> ALTER TABLE “HR”.”SCOTT” SHRINK SPACE;
209
Understanding Special Storage Options

Scope
• Introduce index-organized tables.
• Describe how to create index-organized tables.
• Describe how to view information about index-organized tables.
• Introduce clustered tables and describe various types of clustered tables.
• Describe how to create the different types of clustered tables.
Focused Explanation
Index-Organized Tables
An index-organized table allows you to store index and table data in a single table. Index-organized
tables provide faster access to a table when the table is accessed by using the primary key. The data of
an index-organized table is stored in a B-tree in a primary key sorted order. For an index-organized table,
each index entry in the B-tree stores non-key columns of the index-organized table and the primary key
column of the index-organized table. The storage of non-key columns along with the primary key column
provides faster access to the index-organized table. In addition, no physical ROWID is assigned to a row
in an index-organized table. Rows are identified by the logical ROWIDs in the index-organized table. As a
result, you can create secondary indexes on the index-organized table. The secondary indexes on an
index-organized table provide faster access to the data when the table is accessed by using a non-key
column.
Note: Non-key columns are columns other than the primary key columns of a table.
Creating an Index-Organized Table
You can create an index-organized table by using the ORGANIZATION INDEX clause with the CREATE
TABLE statement. You must specify the primary key when you create the index-organized table. For
example, to create an index-organized table, SALES_SUMMARY, which stores the sales records of an
organization, issue the following statement at the SQL prompt:
SQL> CREATE TABLE sales_summary(

2 sales_date DATE,
3 dept NUMBER,
4 tot_sales NUMBER(10),
5 CONSTRAINT sales PRIMARY KEY(sales_date, dept))
6 ORGANIZATION INDEX
7 TABLESPACE users;
210
The above statement creates the SALES_SUMMARY table and a primary key constraint, SALES, on the
SALES_DATE and DEPT columns of the SALES_SUMMARY table.
Index-Organized Tables with Row Overflow Storage Area
The B-tree for an index-organized table stores the primary key as well as the non-key column data. As a
result, the space required to store the primary key as well as the non-key column data may not be
sufficient. To resolve this problem, Oracle enables you to create an area called the row overflow storage
area. The data in the B-tree is stored in the form of B-tree leaf blocks. This data is divided into the
following parts:
• The index entry part - consists of the primary key columns and a physical ROWID. The physical
ROWID points to the data stored in the row overflow area. The index entry may also contain
nonkey columns.
• The overflow part - consists of the remaining nonkey columns that are not stored with the index
entry part.
If the space that stores data in a B-tree leaf block is exhausted, the additional data to be stored in the B-
tree leaf block is moved to the row overflow storage area.
Creating a Row Overflow Storage Area
The row overflow storage area of a table is created while you are creating the table. You can create the
row overflow storage area by using the OVERFLOW clause with the CREATE TABLE statement. You can
use the PCTTHREHOLD and INCLUDING clauses with the OVERFLOW clause. These clauses determine
whether the data stored in a B-tree leaf block should be stored in parts. If the data is stored in parts, the
clauses determine at which non-key column the data should be divided into parts. The PCTTHREHOLD
clause enables you to specify a threshold value as a percentage of the leaf block size. If the space to
store all the data of the non-key columns does not exceed the space limit specified by the threshold
value, the data is not divided into parts. Otherwise, starting with the first non-key column that cannot be
stored in the threshold limit, the rest of the non-key columns are stored in the row overflow storage area.
The INCLUDING clause enables you to specify a column. After specifying the column, all the non-key
columns appearing after the specified column are stored in the row overflow storage area.
To create the row overflow storage area for a table, you must create an overflow tablespace that stores
the created row overflow storage area. For example, to create the row overflow storage area for the
SALES_SUMMARY table, issue the following statement at the SQL prompt:
SQL> CREATE TABLE sales_summary(

2 sales_date DATE,
3 dept NUMBER,
4 tot_sales NUMBER(10),
5 CONSTRAINT sales PRIMARY KEY(sales_date, dept))
6 ORGANIZATION INDEX
7 TABLESPACE USERS
8 PCTTHRESHOLD 25
211
9 OVERFLOW TABLESPACE users2;
Viewing Information about Index-Organized Tables
You can view information about an index-organized table by querying the DBA_INDEXES and
DBA_SEGMENTS views. These views display information such as the name of the row overflow storage
area associated with an index-organized table, the name of the index-organized table, and the name of
the index associated with the index-organized table. The DBA_INDEXES view displays information about
all the indexes in the database. The commonly-used columns of the DBA_INDEXES view are as follows:
• OWNER – Specifies the name of the owner of the index that is associated with an index-organized
table
• INDEX_NAME – Specifies the name of the index associated with the index-organized table
• TABLE_NAME – Specifies the name of the index-organized table
• TABLE_OWNER – Specifies the name of the owner of the index-organized table
• TABLESPACE_NAME – Specifies the name of the tablespace associated with the index-organized
table
For example, to display the name of the tablespace and the index associated with the SALES_SUMMARY
index-organized table, issue the following statement at the SQL prompt:
SQL> SELECT index_name, tablespace_name

2 FROM dba_indexes;
The DBA_SEGMENTS view displays information about the segments associated with an index-organized
table and the associated row overflow storage area. The commonly-used columns of the DBA_SEGMENTS
view are as follows:
• OWNER – Specifies the name of the owner of the segment that stores either an index-organized
table or the row overflow storage area associated with an index-organized table
• SEGMENT_NAME – Specifies the name of the segment that stores either the index-organized
table or the row overflow storage area associated with the index-organized table
• TABLESPACE_NAME – Specifies the name of the tablespace containing the segment that stores
either the index-organized table or the row overflow storage area associated with the index-
organized table
• BYTES – Specifies the size of the segment in bytes
For example, to query the name of the segment that stores the row overflow storage area for the
SALES_SUMMARY table, issue the following statement at the SQL prompt:
SQL> SELECT segment_name, tablespace_name

2 FROM dba_segments
212
3 WHERE segment_name LIKE '%_IOT_%'

4 AND segment_name = 'SALES';
Clustered Tables
A cluster is a group of one or more tables that use the same data blocks to store columns. The tables are
grouped together by common columns and are queried by using joins. The tables stored in a cluster are
called clustered tables. Clustered tables provide an alternative to the ordinary heap-based tables, help to
increase the I/O performance, and optimize disk space usage.
For example, there are two tables, EMPLOYEE and DEPARTMENT, which store information about the
employees of BankTech. The tables share a common column, DEPT_ID, which stores each employees’
department number. The common column in the tables allows you to store the tables in a cluster.
Note: A column or a group of columns that is common in more than one table is called a cluster key.
Advantages of Clusters
The advantages of clusters over ordinary heap-based tables are as follows:
• Disk I/O is reduced because a query may require the reading of a single data block for clusters,
compared to at least two data blocks for a join.
• The disk space required to store the tables is reduced for clusters because the value of each
cluster key is stored only once.
Cluster Types
Oracle provides two types of clusters, index and hash. An index cluster uses B-tree index structures to
store and determine the location of rows in the cluster. A hash cluster uses a hash function to store and
determine the location of rows in the cluster. The hash function is applied on the cluster key of a table.
The value generated after applying the hash function is called hash key value. In a hash cluster, all the
rows with the same hash key value are stored together.
Creating Clustered Tables
To create clustered tables, you must first create clusters. To create clusters in your own schema, you
must have the CREATE CLUSTER and UNLIMITED TABLESPACE privileges. To create clusters in the
schema of other database users, you must have the CREATE ANY CLUSTER and UNLIMITED
TABLESPACE privileges.
Creating Index Clusters
You can create an index cluster in the following situations:
• The tables are usually queried together.
• The data is not updated, deleted, or inserted frequently.
213
You can create an index cluster by using the CREATE CLUSTER statement. For example, to create the
INDEX_CLUSTER index cluster, which stores the EMPLOYEE and DEPARTMENT tables, issue the following
SQL> CREATE CLUSTER index_cluster(dept_id number)

2 SIZE 300
3 TABLESPACE users;
The tables in this cluster are clustered by the DEPT_ID column. The SIZE clause in this statement
specifies the amount of space, in bytes, required to store all the rows of the EMPLOYEE and DEPARTMENT
tables with the same cluster key value. The TABLESPACE clause specifies that the INDEX_CLUSTER
index cluster is created in the USERS tablespace.
Creating Index-Clustered Tables
Index-clustered tables refer to the tables created in an index cluster. To create index-clustered tables in
an index cluster, you must first create an index on the index cluster. For example, to create the
CLUS_INDEX index on the INDEX_CLUSTER index cluster, issue the following statement at the SQL
prompt:
SQL> CREATE INDEX clus_index

2 ON CLUSTER index_cluster;
After creating the index on the index cluster, you can create tables in this index cluster. For example, to
create the EMPLOYEE table in the INDEX_CLUSTER index cluster, issue the following statement at the
SQL prompt:
SQL> CREATE TABLE employee(

2 empname VARCHAR2(10),
3 emp_id NUMBER(6),
4 dept_id NUMBER)
5 CLUSTER index_cluster(dept_id);
Creating Hash Clusters
You can create a hash cluster in the following situations:
• The queries issued against the tables use the equality operator to retrieve specific rows.
• The data is updated, deleted, or inserted infrequently.
You can create a hash cluster by using the CREATE CLUSTER statement. For example, to create the
hash_cluster hash cluster which stores the ORDER and ORDER_ITEM tables, issue the following
SQL> CREATE CLUSTER hash_cluster

2 (order_number NUMBER(10)) SIZE 300
3 HASH IS order_number HASHKEYS 150
214
4 TABLESPACE users;
The tables in this cluster are clustered by the order_number column, which is the common column in
the ORDER and ORDER_ITEM tables. The SIZE clause in the above statement specifies the amount of
space, in bytes, used to store all the rows with the same hash value. The TABLESPACE clause specifies
that the HASH_CLUSTER hash cluster is created in the USERS tablespace. The HASHKEYS clause
specifies the number of unique hash values.
Creating Hash-Clustered Tables
The tables created in a hash cluster are called hash-clustered tables. You can create a hash-clustered
table using the same method by which you create an index-clustered table.
215
Understanding Index Space Usage and Managing Tablespace Usage

Scope
• Monitor index space usage.
• Rebuild indexes.
• Describe index usage.
• Describe tablespace space usage.
• Manage thresholds for tablespaces by using the Enterprise Manager Database Control and the
DBMS_SERVER_ALERT package.
Focused Explanation
The Segment Advisor enables you to analyze a table along with its indexes. You can also analyze
indexes individually by using querying data dictionary views.
Monitoring Index Space Usage

If an index is updated frequently, the space usage efficiency of the index may decrease over time. You
can monitor the efficiency of an index in terms of space usage by first analyzing the index using the
ANALYZE INDEX statement and then by querying the PCT_USED column of the INDEX_STATS view. The
PCT_USED column indicates the percentage of space usage for an index. If over time, the value in the
PCT_USED column associated with a specific index starts decreasing, you can rebuild the index or drop
and recreate the index. The decreasing value of the PCT_USED column specifies that the percentage
space usage of the specified index has decreased. For example, to analyze the EMP_INDEX index, issue
the following statement at the SQL statement:
SQL> ANALYZE INDEX emp_index VALIDATE STRUCTURE;
The INDEX_STATS view displays information about an index obtained from the execution of the last
VALIDATE STRUCTURE statement. To query the INDEX_STATS view and find the percentage space
usage in the EMP_INDEX index, issue the following statement at the SQL prompt:
SQL> SELECT pct_used

2 FROM index_stats
2 WHERE name = 'EMP_INDEX';
216
Rebuilding Indexes
Rebuilding an index removes the fragments generated by frequent updating of the index from the space
allocated to the index. Rebuilding the index may move the index to a new tablespace. You can rebuild an
index by using the ALTER INDEX...REBUILD statement. For example, to rebuild the EMP_INDEX index,
issue the following statement at the SQL statement:
SQL> ALTER INDEX emp_index REBUILD;
You can also rebuild an index that is currently being used by a database user by using the ONLINE
clause with the ALTER INDEX...REBUILD statement. For example, to rebuild the EMP_INDEX index that
is being used by a database user, issue the following statement at the SQL prompt:
SQL> ALTER INDEX emp_index REBUILD ONLINE;
Monitoring Index Usage
You can monitor an index to determine whether the index is being used by any database users. If an
index is not being used, you can drop that index. You can start monitoring an index by using the ALTER
INDEX...MONITORING USAGE statement. For example, to start monitoring the EMP_INDEX index, issue
SQL> ALTER INDEX emp_index MONITORING USAGE;
You can query the V$OBJECT_USAGE view to display the result of the ALTER INDEX...MONITORING
USAGE statement and determine whether or not an index has been used. The columns in the
V$OBJECT_USAGE view are as follows:
• INDEX_NAME – Specifies the name of the index being monitored
• TABLE_NAME – Specifies the name of the table on which the index is created
• MONITORING – Specifies whether or not the index is being monitored
• USED – Specifies whether or not the index is being utilized
• START_MONITORING – Specifies the time when monitoring of the index started
• END_MONITORING – Specifies the time when monitoring of the index ended
For example, to query the V$OBJECT_USAGE view and determine whether the EMP_INDEX index has
been used, issue the following statement at the SQL prompt:
SQL> SELECT index_name, table_name, start_monitoring, used

2 FROM v$object_usage
3 WHERE index_name = 'EMP_INDEX';
217
The following is a possible output of the above statement:
INDEX_NAME TABLE_NAME
------------------------------ ------------------------------
START_MONITORING USE
------------------- ---
EMP_INDEX EMPLOYEE
06/15/2005 17:14:42 NO
Proactively Managing Tablespace Usage

Oracle 10g uses two methods, reactive and proactive, to manage tablespace space usage. In the reactive
method, Oracle 10g notifies database users by sending an alert whenever the tablespace space usage
exceeds a specified limit, called the threshold limit. In the proactive method, you can increase the
tablespace space before the threshold is exhausted.
Oracle 10g defines two threshold alert levels, warning level and critical level. By default, the warning level
of tablespace usage is set to 85 percent and the critical level is set to 97 percent. The warning level and
the critical level alerts are triggered when the tablespace space usage exceeds the specified thresholds.
An alert message is generated when the tablespace space usage exceeds the thresholds and the
tablespace space usage is below the thresholds.
Note: When a tablespace is offline or read-only, the tablespace space usage will not change. As a result,
alerts are not generated when the tablespace is read-only or offline. Dictionary-managed tablespaces do
not support alerts.
For auto extensible tablespaces, the tablespace size automatically increases when the space allocated
for the tablespace is completely utilized. In Oracle 10g, the thresholds for the auto extensible tablespaces
are computed either by using the maximum size for a datafile specified while the tablespace was created
or by using the maximum size for a datafile specified by the operating system.
Managing Thresholds for Tablespace Space Usage
You can manage thresholds for tablespace space usage by using either the Enterprise Manager
Database Control or the DBMS_SERVER_ALERT package.
Managing Thresholds Using the Enterprise Manager Database Control
You can manage thresholds either for all the tablespaces simultaneously or for each tablespace
individually. To manage thresholds for all the tablespaces simultaneously, perform the following steps:
3. Click the Tablespaces link. The Tablespaces page displays all the tablespaces in the Results
section.
218
4. Select the option corresponding to the USERS tablespace to be analyzed in the Select column.
5. Click the Edit button. The Edit Tablespace: USERS page is displayed.
6. Click the Thresholds tab.
7. Click the Modify Database Defaults button to modify the default thresholds for all the
tablespaces. The Modify Database Defaults page contains the following options:
• Specify Thresholds, by percent used – Used to specify the warning and critical
thresholds for all tablespaces. This option contains the following suboptions:
o Warning (%) – Used to specify warning thresholds, in percentage
o Critical (%) – Used to specify critical thresholds, in percentage
• Disable Thresholds – Used to disable the thresholds for all tablespaces
8. Click the OK button to apply the changes made to the default thresholds.
To manage thresholds for an individual tablespace, perform the following steps:
2. Click the Manage Metrics link under the Related Links section. The Manage Metrics page
shows default thresholds for all database metrics.
3. Click the Edit Thresholds button. The Edit Thresholds page allows you to edit the thresholds
for database alerts.
4. Select the Tablespace Space Used (%) option in the Metric column to edit the thresholds for all
the tablespaces.
5. Click the Specify Multiple Thresholds button. Figure 9-4 shows the Specify Multiple
Thresholds: Tablespace Space Used (%) page.
219
Figure 9-4: The Specify Multiple Thresholds: Tablespace Space Used (%) Page
The Specify Multiple Thresholds: Tablespace Space Used (%) page contains the following
options:
Tablespace Name – Used to specify the name of the tablespace for which you are required to
manage the threshold.
Comparison Operator – Used to compare the current tablespace space usage with the warning
and critical thresholds.
Warning Threshold – Used to specify the warning threshold for the tablespace. The warning
threshold is specified in percentage.
Critical Threshold – Used to specify the critical threshold for the tablespace. The critical
threshold is specified in percentage.
Response Action – Used to specify the action that is triggered when the tablespace space
usage exceeds the thresholds.
6. Select the option corresponding to the USERS tablespace in the Select column.
7. Type the values of the warning and critical thresholds for the USERS tablespace in the Warning
Threshold and Critical Threshold columns, respectively.
220
8. Click the OK button to apply the changes to the warning and critical thresholds.
Managing Thresholds Using the DBMS_SERVER_ALERT Package
The DBMS_SERVER_ALERT package includes the following procedures to manage the thresholds for
various metrics, such as tablespace space usage and CPU time usage. The procedures in the
DBMS_SERVER_ALERT package are as follows:
• SET_THRESHOLD
• GET_THRESHOLD
The SET_THRESHOLD Procedure
You can use the SET_THRESHOLD procedure to set the thresholds for a specific metric. The attributes of
the SET_THRESHOLD procedure are as follows:
• METRIC_ID – Defines the name of the metric for which you are required to specify the threshold.
Only one metric, TABLESPACE_PCT_FULL, is available for the tablespaces. The metric is used
to monitor the tablespace space usage.
• WARNING_VALUE – Specifies the warning threshold for a tablespace. The default value of the
WARNING_VALUE attribute is NULL, which specifies that the warning threshold does not exist.
• WARNING_OPERATOR – Specifies a relational operator used to compare the current value of the
tablespace space usage with the warning threshold specified by the WARNING_VALUE attribute.
• CRITICAL_VALUE – Specifies the critical threshold for a tablespace. The default value of the
CRITICAL_VALUE attribute is NULL, which specifies that the critical threshold does not exist.
• CRITICAL_OPERATOR – Specifies a relational operator to compare the current value of the

tablespace space usage with the critical threshold specified by the CRITICAL_VALUE attribute.
• OBSERVATION_PERIOD – Specifies the time interval, in minutes, after which the current value of
the specified metric is compared with the thresholds. The value of the OBSERVATION_PERIOD
attribute can range from 1 to 60.
• CONSECUTIVE_OCCURENCES – Specifies the number of times the tablespace space usage is

allowed to exceed the threshold limit before an alert is generated.
• INSTANCE_NAME – Specifies the name of a database instance on which the specified thresholds
apply.
• OBJECT_TYPE – Specifies the type of object for which the threshold is being set. For tablespace
space usage, the value of the OBJECT_TYPE attribute is OBJECT_TYPE_TABLESPACE.
• OBJECT_NAME – Specifies the name of the tablespace for which you are required to set the
threshold.
221
For example, issue the following statements at the SQL prompt to set the warning and critical thresholds
of the USERS tablespace by using the SET_THRESHOLD procedure:
SQL> BEGIN
2 DBMS_SERVER_ALERT.SET_THRESHOLD (
3 DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL,
4 DBMS_SERVER_ALERT.OPERATOR_GE,'90',DBMS_SERVER_ALERT.OPERATOR_GE,
5 '99', 1,1,'ORACLE', DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE,
6 'USERS');
7 END;
The above statements set the value of the warning and critical thresholds for the USERS tablespace to 90
percent and 99 percent, respectively.
The GET_THRESHOLD Procedure
The GET_THRESHOLD procedure retrieves the values of previously defined alerts. The GET_THRESHOLD
procedure accepts the same attributes as the SET_THRESHOLD procedure. For example, to retrieve the
thresholds set for the USERS tablespace, issue the following statements at the SQL prompt:
SQL> DECLARE
2 WARN_OPERATOR BINARY_INTEGER;
3 WARN_VALUE VARCHAR2(60);
4 CRITIC_OPERATOR BINARY_INTEGER;
5 CRITIC_VALUE VARCHAR2(60);
6 OBSER_PERIOD BINARY_INTEGER;
7 CONSE_OCCURRENCES BINARY_INTEGER;
8 BEGIN
9 DBMS_SERVER_ALERT.GET_THRESHOLD (
10 DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL,
11 WARN_OPERATOR,WARN_VALUE,CRITIC_OPERATOR,CRITIC_VALUE,
12 OBSER_PERIOD,CONSE_OCCURRENCES,'ORACLE',
13 DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE,'USERS');
14 DBMS_OUTPUT.PUT_LINE(CRITIC_VALUE);
15 DBMS_OUTPUT.PUT_LINE(WARN_VALUE);
16 END;
222
Optimizing Redo Log File Space

Scope
• Introduce redo log files.
• Describe a log switch.
• Multiplex redo log files.
• Describe the Redo Logfile Sizing Advisor.
Focused Explanation
Redo Log
The redo log of a database contains two or more files that store all the changes made to the database by
transactions. The information stored in the redo log is used to recover a database instance from a media
failure. Every database instance is associated with one redo log. The information in the redo log files is
stored in the form of redo records that are made up of groups of change vectors. A change vector stores
the changes made to a single block in the database instance. When you recover the database instance
from a media failure, Oracle reads the change vectors in the redo records and applies the changes to
relevant blocks.
Redo records are buffered in the redo log buffer of the System Global Area (SGA). When a transaction is
committed, the Log Writer (LGWR) background process writes the redo records of the transaction into
one of the redo log files. LGWR assigns a System Change Number (SCN) to the committed transaction to
identify the redo records for the committed transactions. LGWR can also write redo records to a redo log
file when the redo log buffer is full. When the space in the current redo log file is exhausted, LGWR writes
the redo records to the next available redo log file. The redo log file that is being currently written to by
LGWR is called the current redo log file. The redo log files that are required to recover a database are
called the active redo log files. The other redo log files are called inactive redo log files.
Describing a Log Switch
A log switch refers to the process in which the LGWR stops writing redo records to one redo log file and
starts writing to the next redo log file. A log switch occurs when the current redo log file is completely full.
When a log switch occurs, Oracle assigns a new log sequence number to the new redo log file before
writing to it. You can force log switches to occur at regular intervals. Forcing a log switch makes the
currently active redo log files inactive. You can make the currently active redo log files available for redo
log maintenance operations. You can force a log switch by issuing the ALTER DATABASE SWITCH
LOGFILE statement at the SQL prompt.
223
Multiplexing Redo Log Files
You can create multiple copies of a redo log file of a database instance to allow database recovery even if
the original redo log file crashes. The process of creating copies of redo log files is called multiplexing. If
you multiplex the redo log file, LGWR writes the same redo log information to all the copies of the redo
log file. All the copies of a redo log file are known as a group. In a group, each copy of a redo log file is
called a member of the group and is identified by an integer value. When you multiplex redo log files, you
should store the members of a group on different disks. This ensures that if one disk fails, the other
members are available for recovery. If LGWR cannot write to a member of a group, the database marks
that member as INVALID and inserts a message into the LGWR trace file and the alert log.
You can multiplex redo log files while creating the database. For example, to create a database, issue the
SQL> CREATE DATABASE prod

2 LOGFILE
3 GROUP 1 ('/ora/oradata/prod/redo011.log',
4 '/ora/oradata/prod/redo012.log') SIZE 10M,
5 GROUP 1 ('/ora/oradata/prod/redo021.log',
6 '/ora/oradata/prod/redo022.log') SIZE 10M
7 MAXLOGFILES 3
8 MAXLOGMEMBERS 4;
This statement creates a database that contains two redo log groups with two members each. The
MAXLOGFILES clause specifies the maximum number of groups that you can create for a database. The
MAXLOGMEMBERS clause specifies the maximum number of members that you can create in a group.
Creating New Groups
You can create and add new groups to a database to increase the redo log availability by using the
ALTER DATABASE statement. To create a new group, you must have the ALTER DATABASE privilege. For
example, to add a new group, GROUP 3, to an existing database, issue the following statement at the
SQL prompt:

2 ADD LOGFILE
3 GROUP 3('/ora/oradata/prod/redo031.log',
4'/ora/oradata/prod/redo032.log')
5 SIZE 10M;
224
Adding Members to Groups
You can add new members to an existing group by using the ALTER DATABASE statement with the ADD
LOGFILE MEMBER clause. For example, to add a new member to the GROUP 3 group, issue the following

2 ADD LOGFILE MEMBER '/ora/oradata/prod/redo033.log' TO GROUP 3;
Alternatively, you can identify the group to which you are adding a member by specifying the name of all
the members in the group. For example, to add a new member to the GROUP 3 group, issue the following
statement that specifies all the existing members at the SQL prompt:

2 ADD LOGFILE MEMBER '/ora/oradata/prod/redo033.log' TO
3 ('/ora/oradata/prod/redo031.log','/ora/oradata/prod/redo032.log');
Dropping Groups
You can drop a redo log group. To drop a group, you must have the ALTER DATABASE privilege. The
following conditions must be met to drop a group:
• There should be at least two remaining groups in the database after deleting the group. A
database requires at least two groups for recovery. If one group crashes or is corrupted, the
other is available for recovery.
• The group to be dropped must be inactive.
• The group to be dropped must be archived if the database is in ARCHIVELOG mode.
You can drop a group by using the ALTER DATABASE statement with the DROP LOGFILE clause. For
example, to drop the GROUP 2 group, issue the following statement at the SQL prompt:
SQL> ALTER DATABASE DROP LOGFILE GROUP 2;
When you drop a group, the operating system files for the group are not deleted. After dropping the
group, you must manually delete the operating system files.
Dropping Members
To drop a member of a group, you must have the ALTER SYSTEM privilege. The following conditions must
be met to drop a group:
• The member to be dropped should not be a member of an active group.
• There are only two groups in the database instance and the member to be dropped is not the
last member of a group.
225
• The member to be dropped belongs to an archived group if the database is in ARCHIVELOG

mode.
You can drop a member by using the ALTER DATABASE statement with the DROP LOGFILE MEMBER
clause. For example, to drop the /ora/oradata/prod/redo033.log member, issue the following
SQL> ALTER DATABASE PROD

2 DROP LOGFILE MEMBER '/ora/oradata/prod/redo033.log';
When you drop a member, the operating system file for the member is not deleted. After dropping the
member, you must manually delete the operating system file.
Clearing a Redo Log File
You must clear a redo log file when the redo log file is corrupted because a corrupted redo log file
terminates all database activities. You can clear redo log files in a group by using the ALTER DATABASE
statement with the CLEAR LOGFILE GROUP clause. For example, to clear the redo log files in the GROUP
3 group, issue the following statement at the SQL prompt:
SQL> ALTER DATABASE prod CLEAR LOGFILE GROUP 3;
Using the Redo Logfile Sizing Advisor

The Redo Logfile Sizing Advisor recommends an optimal size for the redo log files for the database
instance. If the size of a redo log file is too small, checkpoints occur frequently and the database
response time may be adversely affected. If the size of a redo log file is too large, disk space is wasted.
The recommended size of the redo log file depends on the number of changes in the database and the
value of the FAST_START_MTTR_TARGET initialization parameter. The FAST_START_MTTR_TARGET
initialization parameter indicates the estimated time the recovery process requires to recover a database
instance from a crash. The Redo Logfile Sizing Advisor will recommend the optimal size of the redo log
files only if this initialization parameter is set to a nonzero value.
You can view the size of redo log files recommended by the Redo Logfile Sizing Advisor by the using
Enterprise Manager Database Control or by querying the OPTIMAL_LOGFILE_SIZE column in the
V$INSTANCE_RECOVERY view.
To use the Redo Logfile Sizing Advisor with the Enterprise Manager Database Control, follow these
steps:
2. Click the Administration link.
3. Click the Redo Log Groups link under the Storage section. Figure 9-5 shows the Redo Log
Groups page.
226
Figure 9-5: The Redo Log Groups Page
4. Select the Sizing Advice option from the Actions drop-down list box to generate the
recommendation for resizing the redo log files.
5. Click the Go button to continue. The Update Message section on the Redo Log Groups
page indicates the recommended size of the redo log files.
To view the recommended size of the redo log files by querying the V$INSTANCE_RECOVERY view, issue
SQL> SELECT optimal_logfile_size

2 FROM v$instance_recovery;
227
Review Checklist: Monitoring and Managing Storage: Oracle 10g

Administration II
Introduce the resumable space allocation feature.
Enable and disable resumable space allocation.
Use the DBMS_RESUMABLE package to control resumable space allocation.
Understand the purpose of and how to use the AFTER SUSPEND system event and trigger.
View information about resumable statements.
Identify and define index-organized tables.
Create index-organized tables.
View information about index-organized tables.
Identify and define clustered tables.
Describe various types of clustered tables and methods to create them.
Introduce segment shrink.
Shrink segments using SQL statements and Enterprise Manager Database Control.
Introduce the Segment Advisor.
Use the Segment Advisor with Enterprise Manager Database Control and the DBMS_ADVISOR
package.
Monitor index space usage.
Rebuild indexes.
Describe index usage.
Describe tablespace space usage.
Manage thresholds for tablespaces using Enterprise Manager Database Control and the
DBMS_SERVER_ALERT package.
Understand the purposed of the redo log files.
Describe a log switch.
Multiplex the redo log files.
Describe the Redo Logfile Sizing Advisor.
228
Taking the Test Strategies
The Oracle Certified Associate, Professional, and Master credentials identify a standard of competence
for entry-level and professional job roles that use Oracle products. Oracle's certification program is a
recognized credential that signifies a proven level of knowledge and ability. With each level of
certification, a higher benchmark of ability is set for greater opportunities and higher pay.
The 1Z0-043 exam is a proctored exam, which may be taken at an Oracle University Training Center or
an authorized Prometric testing center.
Oracle Certification Roadmap
The 1Z0-043 Oracle Database 10g: Administration II exam is required to acquire your Oracle 10g DBA
OCP certification.
For more information on this certification, visit http://education.oracle.com/pls/web_prod-plq-

dad/db_pages.getpage?page_id=47&p_org_id=1001&lang=US#1 .
For details on the 1Z0-043 exam, see the objectives for the exam at
http://education.oracle.com/pls/web_prod-plq-
dad/db_pages.getpage?page_id=41&p_org_id=1001&lang=US&p_exam_id=1Z0_043
An Oracle candidate should combine training with on-the-job experience. Many of the exam questions are
based on real-world scenarios so hands-on experience with the software is vital.
Registering for the Exam
To register for the exam:
http://education.oracle.com/web_prod-plq-
dad/plsql/show_desc.redirect?dc=D20040&p_org_id=&lang=&source_call=
Or
http://www.prometric.com
Resources
Because the exam is based on the Oracle Database 10g: Administration Workshop II instructor-led
training, attending this course is the best preparation. However, if you are unable to attend this class or
do not have access to the materials, you can use the Oracle 10g documentation on the OTN to prepare
for the exam:
http://download-west.oracle.com/docs/cd/B14117_01/nav/portal_3.htm
229
Test Day Strategies
The most important test day strategy is be thoroughly prepared for the exam beforehand. You must know
the material. Cramming the day of the exam is not a good strategy to use for any type of test, especially
certification exams.
General Tips
• Schedule your exam only after you are confident that you have mastered the subject matter.
• Schedule your exam for a time of day when you perform at your best.
• Eliminate all distractions from your testing area.
• Allow four hours to complete the registration and exam.
• Eat a light meal beforehand.
• Review the number of questions and the question types carefully before starting the exam. Be careful
not to bypass this option because you are in a hurry to finish.
• Everything you do has time limitations, so do not let the pressure overwhelm you.
Oracle Database 10g: Administration II - Specific Tips
• Before starting the exam, review your short stack of reserved flash cards and personal study notes to
remind yourself about terms, topics, and syntax that are likely to appear on the exam.
• Determine how much time you are allotted to answer the questions. Do not spend too much time on a
given question during your first pass through the exam.
Test Item Types
The 1Z0-043 exam contains only multiple-choice items. While knowing the technical content for this exam
is important to pass the exam, understanding the methodology of the item type and following a strategy of
how to answer each type can mean the difference between passing and failing.
Multiple-Choice
Read each multiple-choice item with the intention of answering the item without the alternatives that
follow. Focusing on finding an answer without the help of the alternatives will increase your concentration
and help you read the question more clearly.
Understand that multiple-choice items with round radio buttons require a single response, and multiple-
choice items with square radio buttons require one or more responses. If more than one response is
required, pay special attention to the “directive” sentence of the question (“Choose two. Each correct
answer…..”). This will indicate whether the different responses are independent or corresponding, for
example:
230
“Choose two. Each correct answer represents a portion of the solution.”
When this directive is given, each of the correct responses, when taken together, will provide the desired
result. Sometime each response will be a different, independent answer:
“Choose two. Each correct answer represents a unique solution.”
When this directive is given, each response can be used independently to provide the desired solution. In
other words, there are two ways to achieve the same result.
Use the process of elimination when you do not know the answer for sure. If the question has a single
answer and four options are listed, eliminate two of these options quickly and make the decision between
the two that remain. This increases your probability to 50/50. Another helpful methodology is to identify a
likely false alternative and eliminate it. This elimination method is particularly helpful when the item
requires more than one answer.
When two very similar answers appear, it is likely that one of them is the correct choice. Test writers often
disguise the correct option by giving another option that looks very similar.
You can download a free demo, from our Web site, that mimics the types of questions that will appear on
the exam. Sample questions do not cover all the content areas on the exam.
231
YOU’RE ALREADY SMART, WE HELP YOU BE SMARTER.
Thank You and Good Luck on your Exams!
Thank you for purchasing a Self Test Software certification exam preparation product.
Self Test helps you figure out what you know and helps you learn what you don’t – it’s
the best way to prepare for your certification exams.
For your upcoming exam and throughout your IT career, Self Test is the only tool you
need to improve your IT IQ and succeed on exam day.
The Self Test Software Team

Selftest 1Z0-043 - StudyGuide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Selftest 1Z0-043 - StudyGuide

Uploaded by

Copyright:

Available Formats

1Z0-043

Oracle Database 10g: Administration II

Oracle 1Z0-043 Study Guide

Self Test Software

Monitoring and Managing Storage: Oracle 10g Administration II......................... 193

Pass the Exam with the Self Test Study Guide

Introducing Globalization Support

• Describe how to use National Language Support (NLS) parameters.

Features of Globalization Support

Using NLS Parameters

Specifying the Globalization Support Behavior

Using the NLS_LANG Parameter

SQL> SELECT name,sal,hire_date FROM employee;

This statement can produce the following output:

NAME SAL HIRE_DATE

• The territory argument must be preceded by an underscore.

• The charset argument must be preceded by a period.

Using Different NLS Parameters

The NLS parameters are placed into the following categories:

• Language and Territory parameters

• Date and Time parameters

• Numeric and List parameters

• Length Semantics parameters

Using Language and Territory Parameters

• Language used to display database server messages

• ISO currency symbol

• Local currency symbol

• Dual currency symbol

• First day of the week

• Credit and debit symbols

• ISO week flag

SQL> ALTER SESSION SET NLS_LANGUAGE=FRENCH;

SQL> ALTER SESSION SET NLS_TERRITORY=FRANCE;

Using Date and Time Parameters

Using Date Parameters

SQL> SELECT TO_CHAR(SYSDATE) AS ROMAN_OUTPUT FROM DUAL;

SQL> ALTER SESSION SET NLS_DATE_FORMAT='MM/DD/YYYY';

SQL> ALTER SESSION SET NLS_DATE_LANGUAGE=ITALIAN;

SQL> SELECT TO_CHAR(SYSDATE,'Day:Dd Month YYYY') AS ITALIAN_DATE FROM DUAL;

SQL> SELECT TO_CHAR(SYSDATE,'DD/MON/YYYY','NLS_DATE_LANGUAGE=ITALIAN')

The above statement can produce the following output:

Using Time Parameters

SET NLS_TIMESTAMP_FORMAT='MM/YYYY/DD HH:MI:SS.FF'

SQL> ALTER SESSION SET NLS_TIMESTAMP_FORMAT='MM/YYYY/DD HH:MI:SS.FF';

NLS_TIMESTAMP_TZ_FORMAT='MM-YYYY-DD HH:MI:SS.FF TZH:TZM'

SET NLS_TIMESTAMP_TZ_FORMAT='MM-YYYY-DD HH:MI:SS.FF TZH:TZM'

SQL> ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT='MM/YYYY/DD HH:MI:SS.FF

Using Calendar Parameter

SQL> ALTER SESSION SET NLS_CALENDAR='Persian';

SQL> SELECT TO_CHAR(SYSDATE,'DD/MON/YYYY','NLS_CALENDAR=Persian')

Using Numeric and List Parameters

SQL> ALTER SESSION SET NLS_NUMERIC_CHARACTERS=",.";

SQL> SELECT TO_CHAR(6000, '9G999D99') AS NLS_NUMERIC_OUTPUT FROM DUAL;

SQL> SELECT TO_CHAR(6000,'9G999D99','NLS_NUMERIC_CHARACTERS=.,') AS

This statement can produce the following output:

Using Monetary Parameters

SQL> ALTER SESSION SET NLS_CURRENCY ='$';

SQL> SELECT TO_CHAR(123.56,'9G999G999D99L') AS USD_CURRENCY FROM DUAL;

This statement can produce the following output:

SQL> SELECT TO_CHAR(123.56,'9G999G999D99L','NLS_CURRENCY=$')

SQL> ALTER SESSION SET NLS_ISO_CURRENCY=FRANCE;

SQL> SELECT TO_CHAR(123.14,'9G999G999D99C') AS EUR_CURRENCY FROM DUAL;

The output of the above SELECT statement would be: