selftest 1z0-043_studyguide

232
1Z0-043 Oracle Database 10g: Administration II

Upload: ugurcan77

Post on 10-Apr-2015

1.065 views

Category:

Documents


3 download

DESCRIPTION

Selftest software OCP 1z0-043 exam study guide.Oracle OCP exam.Babbies are not terorist,Stop the war in Gazze.http://rapidshare.com/files/186554631/1Z0-043_StudyGuide.pdf

TRANSCRIPT

Page 1: selftest 1Z0-043_StudyGuide

1Z0-043 Oracle Database 10g: Administration II

Page 2: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

2

www.selftestsoftware.com

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

Page 3: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

3

www.selftestsoftware.com

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

Page 4: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

4

www.selftestsoftware.com

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

Page 5: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

5

www.selftestsoftware.com

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!

Page 6: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

6

www.selftestsoftware.com

Understanding Globalization Support: Oracle 10g Administration II

Page 7: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

7

www.selftestsoftware.com

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.

Page 8: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

8

www.selftestsoftware.com

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

Page 9: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

9

www.selftestsoftware.com

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;

Page 10: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

10

www.selftestsoftware.com

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

Page 11: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

11

www.selftestsoftware.com

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

Page 12: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

12

www.selftestsoftware.com

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'

Page 13: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

13

www.selftestsoftware.com

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 statement at the SQL prompt: 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 statements at the command prompt:

SET NLS_DATE_LANGUAGE=ITALIAN

To set the value of the NLS_DATE_LANGUAGE parameter to ITALIAN for a session, type the following statement at the SQL prompt:

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

Page 14: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

14

www.selftestsoftware.com

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 following statements at the command prompt:

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

Page 15: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

15

www.selftestsoftware.com

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='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 statements at the command prompt:

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

Page 16: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

16

www.selftestsoftware.com

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 following statements at the command prompt:

SET NLS_NUMERIC_CHARACTERS=",."

To set the value of the NLS_NUMERIC_CHARACTERS parameter for a session, type the following statement at the SQL prompt:

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;

Page 17: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

17

www.selftestsoftware.com

This statement can produce the following output: 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 statements at the command prompt:

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 statement at the SQL prompt:

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

Page 18: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

18

www.selftestsoftware.com

This statement can produce the following output: 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 statements at the command prompt:

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;

Page 19: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

19

www.selftestsoftware.com

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;

This statement can produce the following output: 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 following statements at the command prompt:

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;

Page 20: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

20

www.selftestsoftware.com

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;

The above statement can produce the following output: PARAMETER VALUE ------------------------------ ---------------------------------------- NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CALENDAR GREGORIAN

Page 21: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

21

www.selftestsoftware.com

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;

The above statement can produce the following output: PARAMETER VALUE ------------------------------ ---------------------------------------- NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA 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 NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE 17 rows selected.

Page 22: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

22

www.selftestsoftware.com

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;

The above statement can produce the following output: PARAMETER VALUE ------------------------------ ---------------------------------------- NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA 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_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_RDBMS_VERSION 10.1.0.2.0 20 rows selected.

Page 23: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

23

www.selftestsoftware.com

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%';

The above statement can produce the following output: Parameter value ---------------------------------------------------------------- ---------- LANGUAGE GERMAN LANGUAGE GERMAN DIN TERRITORY GERMANY TERRITORY ALGERIA SORT GERMAN SORT XGERMAN SORT GERMAN_DIN SORT XGERMAN_DIN

Page 24: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

24

www.selftestsoftware.com

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');

Page 25: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

25

www.selftestsoftware.com

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;

The above statement can produce the following output: NAME MGRDATE --------------------------------------------------------------------------- John 01-JAN-05 03.45.24.1200 PM

Page 26: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

26

www.selftestsoftware.com

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 statement at the SQL prompt:

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';

The above statement can produce the following output: STAMP --------------------------------------------------------------------------- JAN-03-05 02:00:00.000000 AM -08:00

Page 27: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

27

www.selftestsoftware.com

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 following statement at the SQL prompt:

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 statement at the SQL prompt:

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';

The above statement can produce the following output: TRANS_TIME--------------------------------------------------------------------------- 05-MAR-05 02.00.00.00000000 AM

Page 28: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

28

www.selftestsoftware.com

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,

Page 29: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

29

www.selftestsoftware.com

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

Page 30: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

30

www.selftestsoftware.com

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.

Page 31: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

31

www.selftestsoftware.com

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';

The above statement can produce the following output: 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;

Page 32: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

32

www.selftestsoftware.com

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';

The above statement can produce the following output: Finsterhutte finsterhttüe

In the output, the casing as well as accent of letters is ignored.

Page 33: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

33

www.selftestsoftware.com

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.

Page 34: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

34

www.selftestsoftware.com

Configuring and Using Recovery Manager: Oracle 10g Administration II

Page 35: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

35

www.selftestsoftware.com

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.

Page 36: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

36

www.selftestsoftware.com

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

Page 37: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

37

www.selftestsoftware.com

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.

Page 38: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

38

www.selftestsoftware.com

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.

Page 39: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

39

www.selftestsoftware.com

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;

Page 40: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

40

www.selftestsoftware.com

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;

Page 41: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

41

www.selftestsoftware.com

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;

Page 42: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

42

www.selftestsoftware.com

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

Page 43: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

43

www.selftestsoftware.com

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.

Page 44: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

44

www.selftestsoftware.com

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.

Page 45: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

45

www.selftestsoftware.com

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;

Page 46: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

46

www.selftestsoftware.com

The above command can produce the following output: 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; The above command can produce the following output: 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.

Page 47: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

47

www.selftestsoftware.com

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; The above command can produce the following output:

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; The above command can produce the following output: 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

Page 48: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

48

www.selftestsoftware.com

2 30720 UNDOTBS1 *** D:\ORACLE\PRODUCT\10.1.0\ORADATA\NO RACLE\UNDOTBS01.DBF 3 266240 SYSAUX *** D:\ORACLE\PRODUCT\10.1.0\ORADATA\NO RACLE\SYSAUX01.DBF 4 5120 USERS *** D:\ORACLE\PRODUCT\10.1.0\ORADATA\NO RACLE\USERS01.DBF 5 153600 EXAMPLE *** D:\ORACLE\PRODUCT\10.1.0\ORADATA\NO RACLE\EXAMPLE01.DBF

Page 49: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

49

www.selftestsoftware.com

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.

Page 50: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

50

www.selftestsoftware.com

Database Recovery: Oracle 10g Administration II

Page 51: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

51

www.selftestsoftware.com

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; The above command can produce the following output: ORACLE instance restarted.

Page 52: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

52

www.selftestsoftware.com

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;

Page 53: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

53

www.selftestsoftware.com

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

Page 54: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

54

www.selftestsoftware.com

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.

Page 55: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

55

www.selftestsoftware.com

4. Run the script for the backup_noreset.txt file by running the following command at the SQL prompt:

SQL> @backp_noreset.txt ;

Page 56: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

56

www.selftestsoftware.com

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

Page 57: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

57

www.selftestsoftware.com

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:

% rman CONNECT / TARGET

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 }

5. Open the database by running the following command at the RMAN prompt:

RMAN> ALTER DATABASE OPEN RESETLOGS;

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;

The above statement can produce the following output:

Page 58: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

58

www.selftestsoftware.com

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.

5. Open the database by running the following command at the RMAN prompt:

RMAN> ALTER DATABASE OPEN RESETLOGS;

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:

Page 59: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

59

www.selftestsoftware.com

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.

3. Start the database that you want to recover in the MOUNT mode.

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';

Page 60: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

60

www.selftestsoftware.com

The above command recovers the database to 01-FEB-2005:00:00:00.

5. Open the database with the RESETLOGS option.

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.

3. Start the database that you want to recover in the MOUNT mode.

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;

6. Open the database with the RESETLOGS option.

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.

3. Start the database that you want to recover in the MOUNT mode.

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;

6. Open the database with the RESETLOGS option.

Page 61: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

61

www.selftestsoftware.com

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 Credentials section.

16. Click the Continue button to continue. The Perform Recovery: Type page is displayed again. Figure 3-1 shows the Perform Recovery: Type page.

Page 62: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

62

www.selftestsoftware.com

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.

Page 63: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

63

www.selftestsoftware.com

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

Page 64: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

64

www.selftestsoftware.com

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;

The above command can produce the following output: 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.

Page 65: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

65

www.selftestsoftware.com

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.

Page 66: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

66

www.selftestsoftware.com

Understanding Flashback Database and Database Corruption: Oracle 10g

Administration II

Page 67: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

67

www.selftestsoftware.com

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.

Page 68: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

68

www.selftestsoftware.com

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 statement at the SQL prompt:

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.

Page 69: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

69

www.selftestsoftware.com

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:

% rman CONNECT / TARGET

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; The output of the above statement might be: 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;

Page 70: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

70

www.selftestsoftware.com

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:

SQL> SHUTDOWN IMMEDIATE;

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 following statement at the SQL prompt:

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.

Page 71: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

71

www.selftestsoftware.com

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

Page 72: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

72

www.selftestsoftware.com

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;

The output of the above statement might be: 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:

SQL> SHUTDOWN IMMEDIATE;

3. Start the database in MOUNT mode by running the following command at the SQL prompt:

SQL> STARTUP MOUNT;

Page 73: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

73

www.selftestsoftware.com

4. Start RMAN and connect to the target database by running the following command at the command prompt:

% rman CONNECT / TARGET

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:

1. Open Enterprise Manager Database Control in a Web browser.

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 Credentials section.

11. Type the database credentials in the Username and Password text boxes under the Database Credentials section.

12. Click the Continue button. The Perform Recovery: Type page is displayed again. Figure 4-2 shows the Perform Recovery: Type page.

Page 74: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

74

www.selftestsoftware.com

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.

Page 75: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

75

www.selftestsoftware.com

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.

Page 76: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

76

www.selftestsoftware.com

• 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:

1. Open Enterprise Manager Database Control in a Web browser.

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.

Page 77: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

77

www.selftestsoftware.com

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

Page 78: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

78

www.selftestsoftware.com

• 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)

Page 79: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

79

www.selftestsoftware.com

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.

Page 80: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

80

www.selftestsoftware.com

• 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 following statement at the SQL prompt:

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'

Page 81: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

81

www.selftestsoftware.com

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:

1. Start RMAN and connect to the target database by running the following command at the command prompt:

% rman CONNECT / TARGET

2. Run the following command at the RMAN prompt to recover the corrupted data block:

RMAN> BLOCKRECOVER DATAFILE 7 BLOCK 8;

Page 82: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

82

www.selftestsoftware.com

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.

Page 83: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

83

www.selftestsoftware.com

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

Administration II

Page 84: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

84

www.selftestsoftware.com

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.

Page 85: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

85

www.selftestsoftware.com

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;

Page 86: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

86

www.selftestsoftware.com

4. Run the following statement at the SQL prompt to create a temporary tablespace, TEMP_2: SQL> CREATE TEMPORARY TABLESPACE temp_2 2 TEMPFILE 'C:\oracle\oradata\ora101t\temp_01.dbf' SIZE 500M 3 EXTENT MANAGEMENT LOCAL 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: SQL> CREATE TEMPORARY TABLESPACE temp_2 2 TEMPFILE 'C:\oracle\oradata\ora101t\temp_01.dbf' SIZE 500M 3 EXTENT MANAGEMENT LOCAL 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;

Page 87: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

87

www.selftestsoftware.com

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

Page 88: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

88

www.selftestsoftware.com

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:

SQL> SHUTDOWN IMMEDIATE;

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.

Page 89: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

89

www.selftestsoftware.com

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.

Page 90: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

90

www.selftestsoftware.com

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.

Page 91: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

91

www.selftestsoftware.com

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;

Page 92: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

92

www.selftestsoftware.com

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:

Page 93: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

93

www.selftestsoftware.com

• 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 following statement at the SQL prompt:

Page 94: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

94

www.selftestsoftware.com

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

Page 95: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

95

www.selftestsoftware.com

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.

Page 96: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

96

www.selftestsoftware.com

Understanding Automatic Database, Storage, and Memory Management:

Oracle 10g Administration II

Page 97: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

97

www.selftestsoftware.com

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

Page 98: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

98

www.selftestsoftware.com

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.

Page 99: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

99

www.selftestsoftware.com

• 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 the following statement at the SQL prompt: 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; The above statement can produce the following output: 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

Page 100: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

100

www.selftestsoftware.com

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;

The above statement can produce the following output: 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;

Page 101: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

101

www.selftestsoftware.com

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 statement at the SQL prompt: SQL> SELECT snap_id, begin_interval_time, end_interval_time 2 FROM dba_hist_snapshot 3 ORDER BY snap_id;

The above statement can produce the following output: 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 the following statement at the SQL prompt:

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:

1. Open Enterprise Manager Database Control in a Web browser.

2. Click the Administration tab.

Page 102: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

102

www.selftestsoftware.com

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.

Page 103: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

103

www.selftestsoftware.com

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; The above statement can produce the following output: 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

Page 104: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

104

www.selftestsoftware.com

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.

Page 105: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

105

www.selftestsoftware.com

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:

Page 106: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

106

www.selftestsoftware.com

• 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 following statement at the SQL prompt: 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.

Page 107: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

107

www.selftestsoftware.com

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:

1. Open Enterprise Manager Database Control in a Web browser.

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.

Page 108: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

108

www.selftestsoftware.com

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.

Page 109: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

109

www.selftestsoftware.com

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; The above statement can produce the following output: 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 statement at the SQL prompt: SQL> SELECT parameter_name, parameter_value 2 FROM dba_advisor_def_parameters 3 WHERE advisor_name = 'ADDM'; The output of the above statement might be: 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.

Page 110: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

110

www.selftestsoftware.com

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.

Page 111: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

111

www.selftestsoftware.com

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

Page 112: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

112

www.selftestsoftware.com

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';

The above statement can produce the following output: OWNER TABLE_NAME ------------------------------ ------------------------------ HR REGIONS HR COUNTRIES HR LOCATIONS HR DEPARTMENTS HR JOBS HR EMPLOYEES HR JOB_HISTORY 7 rows selected.

Page 113: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

113

www.selftestsoftware.com

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;

Page 114: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

114

www.selftestsoftware.com

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

Page 115: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

115

www.selftestsoftware.com

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;

The above statement can produce the following output: 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.

Page 116: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

116

www.selftestsoftware.com

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.

Page 117: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

117

www.selftestsoftware.com

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

Page 118: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

118

www.selftestsoftware.com

• 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:

1. Open Enterprise Manager Database Control in a Web browser.

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.

Page 119: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

119

www.selftestsoftware.com

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.

Page 120: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

120

www.selftestsoftware.com

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.

Page 121: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

121

www.selftestsoftware.com

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.

Page 122: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

122

www.selftestsoftware.com

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.

Page 123: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

123

www.selftestsoftware.com

• 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

Page 124: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

124

www.selftestsoftware.com

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

Page 125: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

125

www.selftestsoftware.com

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

Page 126: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

126

www.selftestsoftware.com

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.

Page 127: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

127

www.selftestsoftware.com

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, 4 '/dev/disk_a2' NAME da2, 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;

Page 128: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

128

www.selftestsoftware.com

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 2 '/dev/disk_a3' NAME da3, 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 statement at the SQL prompt: 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.

Page 129: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

129

www.selftestsoftware.com

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: SQL> ALTER DISKGROUP disk_gp1 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: SQL> ALTER DISKGROUP disk_gp1 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.

Page 130: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

130

www.selftestsoftware.com

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 statement at the SQL prompt:

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.

Page 131: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

131

www.selftestsoftware.com

For example, to check the internal consistency in all the disks in the DISK_GP1 disk group, run the following statement at the SQL prompt:

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:

Page 132: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

132

www.selftestsoftware.com

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;

Page 133: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

133

www.selftestsoftware.com

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 initialization parameter.

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.

Page 134: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

134

www.selftestsoftware.com

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

2. Click the Administration tab.

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.

Page 135: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

135

www.selftestsoftware.com

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 initialization parameter.

• MANUAL – Allows APPM to allocate memory for SQL work areas of sessions according to values of historical PGA parameters.

Page 136: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

136

www.selftestsoftware.com

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;

Page 137: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

137

www.selftestsoftware.com

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.

Page 138: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

138

www.selftestsoftware.com

Managing Resources and Automating Tasks: Oracle 10g Administration II

Page 139: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

139

www.selftestsoftware.com

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;

Page 140: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

140

www.selftestsoftware.com

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 statement at the SQL prompt:

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:

Page 141: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

141

www.selftestsoftware.com

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.

Page 142: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

142

www.selftestsoftware.com

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,

Page 143: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

143

www.selftestsoftware.com

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.

Page 144: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

144

www.selftestsoftware.com

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.

Page 145: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

145

www.selftestsoftware.com

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;

Page 146: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

146

www.selftestsoftware.com

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.

Page 147: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

147

www.selftestsoftware.com

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 following statement at the SQL prompt:

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 statement at the SQL prompt:

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

Page 148: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

148

www.selftestsoftware.com

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

Page 149: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

149

www.selftestsoftware.com

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.

Page 150: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

150

www.selftestsoftware.com

• 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 2 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( 3 PLAN => 'Plan_1', 4 COMMENT => 'Plan_2 is a subplan', 5 GROUP_OR_SUBPLAN => 'Plan_2', 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

Page 151: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

151

www.selftestsoftware.com

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 2 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( 3 PLAN => 'Plan_1', 4 COMMENT => 'Plan_2 is a subplan', 5 GROUP_OR_SUBPLAN => 'Plan_2', 6 CPU_P1 => 100); 7 END; SQL> BEGIN 2 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( 3 PLAN => 'Plan_1', 4 COMMENT => 'Plan_3 is a subplan at level 2', 5 GROUP_OR_SUBPLAN => 'Plan_3', 6 CPU_P2 => 50); 7 END; SQL> BEGIN 2 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( 3 PLAN => 'Plan_1', 4 COMMENT => 'Plan_4 is a subplan at level 2', 5 GROUP_OR_SUBPLAN => 'Plan_4', 6 CPU_P2 => 50); 7 END; SQL> BEGIN 2 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( 3 PLAN => 'Plan_1', 4 COMMENT => 'Plan_5 is a subplan at level 3', 5 GROUP_OR_SUBPLAN => 'Plan_5', 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.

• Resource directive for PLAN_3 – Allocates 50 percent CPU resources to the PLAN_3 subplan of the PLAN_1 resource plan at level two.

Page 152: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

152

www.selftestsoftware.com

• Resource directive for PLAN_4 – Allocates 50 percent CPU resources to the PLAN_4 subplan of the PLAN_1 resource plan at level two.

• Resource directive for PLAN_5 – Allocates 100 percent CPU resources to the PLAN_5 subplan of 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 2 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( 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 following statement at the SQL prompt:

SQL> DBMS_RESOURCE_MANAGER.UPDATE_PLAN(PLAN=> 'Plan_1',GROUP_OR_SUBPLAN =>'rc1',NEW_CPU_P1=>16);

Deleting Resource Plan Directives

Page 153: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

153

www.selftestsoftware.com

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');

Page 154: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

154

www.selftestsoftware.com

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.

Page 155: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

155

www.selftestsoftware.com

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.

Page 156: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

156

www.selftestsoftware.com

• 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 statements at the SQL prompt: SQL> BEGIN 2 DBMS_SCHEDULER.CREATE_PROGRAM( 3 PROGRAM_NAME =>'program2', 4 PROGRAM_ACTION =>'procedure2', 5 PROGRAM_TYPE =>' STORED_PROCEDURE',

Page 157: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

157

www.selftestsoftware.com

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( 3 PROGRAM_NAME =>'program2', 4 ARGUMENT_NAME =>'argument1', 5 ARGUMENT_POSITION =>1, 6 ARGUMENT_TYPE =>'VARCHAR2',

7 DEFAULT_VALUE =>'x'); 8 DBMS_SCHEDULER.DEFINE_PROGRAM_ARGUMENT( 9 PROGRAM_NAME =>'program2', 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.

Page 158: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

158

www.selftestsoftware.com

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.

Page 159: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

159

www.selftestsoftware.com

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.

Page 160: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

160

www.selftestsoftware.com

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 2 DBMS_SCHEDULER.SET_ATTRIBUTE( 3 NAME => 'schedule1', 4 ATTRIBUTE => 'START_DATE', 5 VALUE => '01-JAN-2005 12:00:00 AM');

Page 161: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

161

www.selftestsoftware.com

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

Page 162: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

162

www.selftestsoftware.com

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.

Page 163: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

163

www.selftestsoftware.com

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.

Page 164: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

164

www.selftestsoftware.com

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 statements at the SQL prompt: 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;

Page 165: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

165

www.selftestsoftware.com

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 statements at the SQL prompt: 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;

Page 166: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

166

www.selftestsoftware.com

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 2 DBMS_SCHEDULER.SET_ATTRIBUTE( 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.

Page 167: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

167

www.selftestsoftware.com

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 2 DBMS_SCHEDULER.SET_ATTRIBUTE( 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.

Page 168: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

168

www.selftestsoftware.com

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.

Page 169: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

169

www.selftestsoftware.com

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 following statements at the SQL prompt: 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 2 DBMS_SCHEDULER.SET_ATTRIBUTE( 3 NAME => 'window1', 4 ATTRIBUTE => 'RESOURCE_PLAN', 5 VALUE => 'resourceplan2'); 6 END;

Page 170: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

170

www.selftestsoftware.com

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 following statements at the SQL prompt: 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;

Page 171: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

171

www.selftestsoftware.com

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);

Page 172: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

172

www.selftestsoftware.com

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

Page 173: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

173

www.selftestsoftware.com

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 statement at the SQL prompt: 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 ALL_SCHEDULER_PROGRAMS USER_ SCHEDULER_PROGRAMS

Displays information about Scheduler programs.

DBA_SCHEDULER_PROGRAMS_ARGUMENTS ALL_SCHEDULER_PROGRAMS_ARGUMENTS USER_SCHEDULER_PROGRAMS_ARGUMENTS

Displays information about the arguments of Scheduler programs.

DBA_SCHEDULER_JOBS ALL_SCHEDULER_ JOBS USER_SCHEDULER_JOBS

Displays information about Scheduler jobs.

DBA_SCHEDULER_JOBS_ARGUMENTS ALL_SCHEDULER_JOBS_ARGUMENTS USER_SCHEDULER_JOBS_ARGUMENTS

Displays information about the arguments of Scheduler jobs.

DBA_SCHEDULER_JOB_CLASSES ALL_SCHEDULER_JOB_CLASSES

Displays information about Scheduler job classes.

DBA_SCHEDULER_GLOBAL_ATTRIBUTES ALL_SCHEDULER_GLOBAL_ATTRIBUTES

Displays information about the global attributes of the Scheduler.

DBA_SCHEDULER_WINDOWS ALL_SCHEDULER_WINDOWS

Displays information about Scheduler windows.

DBA_SCHEDULER_WINDOW_GROUPS ALL_SCHEDULER_WINDOW_GROUPS

Displays information about Scheduler window groups.

Page 174: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

174

www.selftestsoftware.com

Views Description DBA_SCHEDULER_WINGROUP_MEMBERS ALL_SCHEDULER_WINGROUP_MEMBERS

Displays information about the members of all the window groups.

DBA_SCHEDULER_RUNNING_JOBS ALL_SCHEDULER_RUNNING_JOBS USER_SCHEDULER_RUNNING_JOBS

Displays information about currently executing jobs.

DBA_SCHEDULER_SCHEDULES ALL_SCHEDULER_ATTRIBUTES

Displays information about Scheduler schedules.

Table 7-1: The Scheduler Views

Page 175: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

175

www.selftestsoftware.com

Review Checklist: Managing Resources and Automating Tasks: Oracle 10g Administration II

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.

Page 176: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

176

www.selftestsoftware.com

Understanding Diagnostic Resources and Securing the Listener: Oracle

10g Administration II

Page 177: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

177

www.selftestsoftware.com

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.

Page 178: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

178

www.selftestsoftware.com

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:

1. Open Enterprise Manager Database Control in a Web browser.

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.

Page 179: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

179

www.selftestsoftware.com

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

Page 180: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

180

www.selftestsoftware.com

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

Page 181: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

181

www.selftestsoftware.com

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

Page 182: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

182

www.selftestsoftware.com

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.

Page 183: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

183

www.selftestsoftware.com

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.

Page 184: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

184

www.selftestsoftware.com

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)

Page 185: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

185

www.selftestsoftware.com

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.

Page 186: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

186

www.selftestsoftware.com

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:

1. Open Enterprise Manager Database Control in a Web browser.

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

Page 187: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

187

www.selftestsoftware.com

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) (ORACLE_HOME=/oracle) (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=

Page 188: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

188

www.selftestsoftware.com

(SID_DESC= (GLOBAL_DBNAME=ora1.acme.com) (ORACLE_HOME=/oracle) (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

Page 189: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

189

www.selftestsoftware.com

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:

1. Open Enterprise Manager Database Control in a Web browser.

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.

Page 190: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

190

www.selftestsoftware.com

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.

Page 191: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

191

www.selftestsoftware.com

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.

Page 192: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

192

www.selftestsoftware.com

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.

Page 193: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

193

www.selftestsoftware.com

Monitoring and Managing Storage: Oracle 10g Administration II

Page 194: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

194

www.selftestsoftware.com

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

Page 195: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

195

www.selftestsoftware.com

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

Page 196: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

196

www.selftestsoftware.com

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 the following statement at the SQL prompt:

SQL> ALTER SESSION DISABLE RESUMABLE;

Page 197: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

197

www.selftestsoftware.com

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);

Page 198: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

198

www.selftestsoftware.com

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.

Page 199: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

199

www.selftestsoftware.com

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 statement at the SQL prompt:

SQL> ALTER TABLE employee ENABLE ROW MOVEMENT;

Page 200: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

200

www.selftestsoftware.com

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 statement at the SQL prompt:

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.

2. Click the Administration tab.

Page 201: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

201

www.selftestsoftware.com

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.

Page 202: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

202

www.selftestsoftware.com

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.

Page 203: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

203

www.selftestsoftware.com

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.

2. Open the Enterprise Manager Database Control in a Web browser.

3. Click the Advisor Central link.

Page 204: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

204

www.selftestsoftware.com

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

Page 205: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

205

www.selftestsoftware.com

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

Page 206: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

206

www.selftestsoftware.com

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

OBJECT_TYPE ATTR1 ATTR2 ATTR3 ATTR4

Tablespace TABLESPACE tablespace_name NULL NULL NULL

Table TABLE schema_name table_name NULL NULL

Index INDEX schema_name index_name NULL NULL

Table partition

TABLE PARTITION

schema_name table_name tablepartition_name

NULL

Index partition

INDEX PARTITION

schema_name index_name indexpartition_name

NULL

Table subpartition

TABLE SUBPARTITION

schema_name table_name table_subpartition_name

NULL

Index subpartition

INDEX SUBPARTITION

schema_name index_name index_subpartition_name

NULL

Table 9-1: The Parameters of the CREATE_OBJECT Procedure

Page 207: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

207

www.selftestsoftware.com

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,

Page 208: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

208

www.selftestsoftware.com

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

The above command can produce the following output: 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.

Page 209: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

209

www.selftestsoftware.com

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;

Page 210: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

210

www.selftestsoftware.com

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;

Page 211: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

211

www.selftestsoftware.com

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

Page 212: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

212

www.selftestsoftware.com

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

Page 213: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

213

www.selftestsoftware.com

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.

Page 214: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

214

www.selftestsoftware.com

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 statement at the SQL prompt: 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 statement at the SQL prompt: SQL> CREATE CLUSTER hash_cluster 2 (order_number NUMBER(10)) SIZE 300 3 HASH IS order_number HASHKEYS 150

Page 215: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

215

www.selftestsoftware.com

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.

Page 216: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

216

www.selftestsoftware.com

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';

Page 217: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

217

www.selftestsoftware.com

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 the following statement at the SQL prompt:

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';

Page 218: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

218

www.selftestsoftware.com

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:

1. Open the Enterprise Manager Database Control in a Web browser.

2. Click the Administration tab.

3. Click the Tablespaces link. The Tablespaces page displays all the tablespaces in the Results section.

Page 219: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

219

www.selftestsoftware.com

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:

1. Open the Enterprise Manager Database Control in a Web browser.

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.

Page 220: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

220

www.selftestsoftware.com

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.

Page 221: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

221

www.selftestsoftware.com

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.

Page 222: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

222

www.selftestsoftware.com

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;

Page 223: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

223

www.selftestsoftware.com

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.

Page 224: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

224

www.selftestsoftware.com

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 following statement at the SQL prompt: 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: SQL> ALTER DATABASE prod 2 ADD LOGFILE 3 GROUP 3('/ora/oradata/prod/redo031.log', 4'/ora/oradata/prod/redo032.log') 5 SIZE 10M;

Page 225: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

225

www.selftestsoftware.com

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 statement at the SQL prompt: SQL> ALTER DATABASE prod 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: SQL> ALTER DATABASE prod 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.

Page 226: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

226

www.selftestsoftware.com

• 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 statement at the SQL prompt:

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:

1. Open Enterprise Manager Database Control in a Web browser.

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.

Page 227: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

227

www.selftestsoftware.com

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 the following statement at the SQL prompt:

SQL> SELECT optimal_logfile_size 2 FROM v$instance_recovery;

Page 228: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

228

www.selftestsoftware.com

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.

Page 229: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

229

www.selftestsoftware.com

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

Page 230: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

230

www.selftestsoftware.com

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:

Page 231: selftest 1Z0-043_StudyGuide

Oracle 1Z0-043 Study Guide

231

www.selftestsoftware.com

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

Page 232: selftest 1Z0-043_StudyGuide

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