11g New Features For Administrators Student Guide-8

SQL Access Advisor: Schedule and Review
9 - 28 Copyright © 2007, Oracle. All rights reserved.
SQL Access Advisor: Schedule and Review

You can then schedule and submit your new analysis by specifying various parameters to the
scheduler. The possible options are shown on the above screen shots.
Oracle Database 11g: New Features for Administrators 9 - 28

SQL Access Advisor: Results

From the Advisor Central page you can retrieve the task details for your analysis. By selecting the
task name in the Results section of the Advisor Central page, you can get to the Results for Task
Summary page from where you can see an overview of the Access Advisor findings. The page
presents charts and statistics that provide overall workload performance and query execution time
potential improvement for the recommendations. You can use the page to show statement counts
and recommendation action counts.


To see other aspects of the results for the Access Advisor task, choose one of the three other tabs
on the page, Recommendations, SQL Statements, or Details.
On the Recommendation page, you can drill down to each of the recommendations. For each of
them, you can important information in the Select Recommendations for Implementation table.
You can then select one or more recommendations and schedule their implementation.
If you click on the ID for a particular recommendation, you are taken to the Recommendation
page that displays all actions for the specified recommendation and optionally to modify the
tablespace name of the statement. When you complete any changes, choose OK to apply the
changes. From that page, you can view the full text of an action by choosing the link in the Action
field for the specified action. You can view the SQL for all actions in the Recommendations by
clicking Show SQL.

SQL Access Advisor: Recommendation Implementation

Most of these recommendations can be executed on a production system using simple SQL DDL
statement. For those cases, SQL Advisor will produce executable SQL statements. In some
instances, for example repartitioning existing partitioned tables, or existing dependent indexes,
simple SQL is not sufficient. SQL Advisor will then generate a script calling external packages
such as DBMS_REDEFINITION in order to enable the user to implement the recommended
change.
In the above example, the SQL Access Advisor makes the recommendation to partition table
SH.CUSTOMERS on CUST_CREDIT_LIMIT column. The recommendation uses the
INTERVAL partitioning scheme, and define the first range of values as been less than 1600.
Interval partitions are partitions based on a numeric range or date time interval. They extend range
partitioning by instructing the database to create partitions of the specified interval automatically
when data inserted into the table exceeds all of the range partitions.


The SQL Statements page shows you a chart and a corresponding table that list SQL statements
initially ordered by the largest cost improvement. The top SQL statement will be improved the
most by implementing its associated recommendation.


The Details page shows you the workload and task options that were used when the task was
created. This page also gives you all journal entries that were logged during the task execution.

SQL Access Advisor: PL/SQL Procedure Flow
Step 3
ADD_STS_REF
Step 1
DELETE_STS_REF
CREATE_TASK EXECUTE_TASK
UPDATE_TASK_ATTRIBUTES INTERRUPT/CANCEL_TASK
DELETE_TASK MARK_RECOMMENDATION
QUICK_TUNE UPDATE_REC_ATTRIBUTES
GET_TASK_REPORT
Task-dependent GET_TASK_SCRIPT
SQL
Access Advisor
Advisor-dependent task
Report/Scripts
SET_TASK_PARAMETER
RESET_TASK
Step 2
SQL Access Advisor: PL/SQL Procedure Flow

The graphic shows the typical operational flow of the SQL Access Advisor procedures from the
DBMS_ADVISOR package. You can find a complete description of each of these procedures in
the Oracle Database PL/SQL Packages and Types Reference guide.
• Step 1: Create and manage tasks and data. This step uses a SQL Access Advisor task.
• Step 2: Prepare tasks for various operations. This step uses SQL Access Advisor parameters.
• Step 3: Prepare and analyze data. This step uses SQL Tuning Sets and SQL Access Advisor
tasks. With Oracle Database 11g R1, GET_TASK_REPORT can report back using HTML or
XML in addition to just text.
Note: The DBMS_ADVISOR.QUICK_TUNE procedure is a shortcut that performs all the
necessary operations to analyze a single SQL statement. The operation creates a task for which all
parameters are defaulted. The workload is constituted by the specified statement only. Finally, the
task is executed and the results are saved in the repository. You can also instruct the procedure to
implement the final recommendations.

SQL Access Advisor: PL/SQL Example
BEGIN 1
dbms_advisor.create_task(dbms_advisor.sqlaccess_advisor,'MYTASK');
END;
BEGIN
dbms_advisor.set_task_parameter('MYTASK','ANALYSIS_SCOPE','ALL');
2
dbms_advisor.set_task_parameter('MYTASK','MODE','COMPREHENSIVE');
END;
BEGIN 3
dbms_advisor.add_sts_ref('MYTASK','SH','MYSTS');
dbms_advisor.execute_task('MYTASK');
dbms_output.put_line(dbms_advisor.get_task_script('MYTASK'));
END;
SQL Access Advisor: PL/SQL Example

Matching the order shown on the previous slide, the above examples shows you a possible SQL
Access Advisor tuning session using PL/SQL code.
The first PL/SQL block creates a new tuning task called MYTASK. This task is uses the SQL
Access Advisor.
The second PL/SQL block sets SQL Access Advisor parameters for MYTASK. In the example,
we set ANALYSIS_SCOPE to ALL which means to generate recommendations for indexes,
materialized views and partitions. Then, we set MODE to COMPREHENSIVE to include all SQL
statements that are part of the SQL Tuning Set associated to a future task.
The third PL/SQL block associates a workload to MYTASK. Here, we use an existing SQL
Tuning Set called MYSTS. We can now execute the tuning task. After its execution completes,
you can generate corresponding recommendation scripts as shown with the third example on the
slide.
Note: For a complete list of SQL Access Advisor parameters (around 50), refer to the Oracle
Database PL/SQL Packages and Types Reference guide.

Summary
In this lesson, you should have learned how to:

• Implement the new partitioning methods
• Employ Data Compression
• Create SQL Access Advisor analysis session using
Enterprise Manager
• Create SQL Access Advisor analysis session using
PL/SQL
• Setup a SQL Access Advisor analysis to get partition
recommendations

Using RMAN Enhancements
Copyright © 2007, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to:

• Describe Oracle Database 11g new and enhanced
RMAN features
• Configure archivelog deletion policies
• Duplicate active databases by using the Oracle network
(without backups)
• Back up large files in multiple sections
• Create archival backups for long-term storage
• Manage recovery catalog, for example, merge multiple
catalog versions

RMAN News
Improved archive log management:

• Enhanced configuration of deletion policies **
Recovery/cloning enhancements:
• Duplicating a database across the network **
• Improved block media recovery performance
TCP/IP
Note: The features and tasks marked with ** are discussed in more detail in this lesson.
RMAN News
Enhanced configuration of deletion policies
Archived redo logs are eligible for deletion only when not needed by required consumers such as
Data Guard, Streams, Flashback Database, and so on. When you CONFIGURE an archived log
deletion policy, the configuration applies to all archiving destinations, including the flash
recovery area. Both BACKUP ... DELETE INPUT and DELETE... ARCHIVELOG use this
configuration, as does the flash recovery area. When you back up the recovery area, RMAN can
fail over to other archived redo log destinations if the archived redo log in the flash recovery area
is inaccessible or corrupted.
Active Database Duplication
You can use the "network-aware" DUPLICATE command to create a duplicate or standby
database over the network without a need for pre-existing database backups.
Improved block media recovery performance
You can use the RECOVER command (formerly the BLOCKRECOVER command) to recover
individual data blocks. If flashback logging is enabled and contains older, uncorrupted blocks,
then RMAN can use these blocks, thereby speeding up block media recovery.

RMAN News
Faster and optimized backup through:

• Parallel backup and restore for very large files **
• Fast incremental backup on physical standby
• Configuring backup compression
RMAN News
Parallel backup and restore for very large files
Backups of large data files now use multiple parallel server processes to efficiently distribute the
workload for each file. This features improves the performance of backups. Look for more details
later in this section.
Fast incremental backups on physical standby database
You can enable block change tracking on a physical standby database ( use the existing ALTER
DATABASE ENABLE/DISABLE BLOCK CHANGE TRACKING SQL statement). RMAN then
will track changed blocks during standby managed recovery. This allows the off loading of block
tracking to the standby database and allows the same fast incremental backups the use the change
tracking file that have been available on the primary. This feature enables faster incremental
backups on a physical standby database than in previous releases.
Configuring backup compression
You can use the CONFIGURE command to choose between the BZIP2 and ZLIB compression
algorithms for RMAN backups.
Note: For more details about the RECOVER, VALIDATE and CONFIGURE commands, see the
Oracle Database Backup and Recovery Reference.

RMAN News
Other enhancements:
• Archival backups for long-term storage **
• Improved block corruption detection
Recovery catalog enhancements
• Merging catalogs **
• Restricting DBA backup catalog access to owned
databases
Integration enhancements:
• Automatic Network File System (NFS)
• RMAN Integration with VSS-enabled applications
RMAN News
Archival backups for long-term storage
Long-term backups, created with the KEEP option, no longer require all archived logs to be
retained, when the backup is online. Instead, archive logs needed to recover the specified data
files to a consistent point in time are backed up (along with specified data files and a control file).
This functionality reduces archive log backup storage needed for online, long-term KEEP
backups, and simplifies the command by using a single format string for all the files needed to
restore and recover the backup.
Improved block corruption detection
Several database components and utilities, including RMAN, can now detect a corrupt block and
record it in the V$DATABASE_BLOCK_CORRUPTION view. The Oracle database automatically
updates this view when block corruptions are detected or repaired. The VALIDATE command is
enhanced with many new options such as VALIDATE ... BLOCK and VALIDATE
DATABASE.

RMAN News
Merging Catalogs
The new IMPORT CATALOG command allows one catalog schema to be merged into another,
either the whole schema or just the metadata for specific databases in the catalog. This simplifies
catalog management for you by allowing separate catalog schemas, created in different versions,
to be merged into a single catalog schema.
Restricting DBA backup catalog access to owned databases
The owner of a recovery catalog can grant or revoke access to a subset of the catalog to database
users. This subset is called a "virtual private catalog". See the lesson Security New Features for
more details.
Automatic Network File System (NFS)
The NFS client is implemented as part of Oracle kernel in ODM library. This improves the ease-
of-use and stability of accessing NAS storage systems, as well as increasing the availability across
different platforms while maintaining a consistent interface. For more details see the General
Database Enhancements eStudy.
Integration with VSS-enabled applications
The Volume Shadow Copy Service (VSS) is an infrastructure on Windows. The Oracle VSS
Writer is integrated with VSS-enabled applications. So you can use VSS-enabled software and
storage systems to back up and restore an Oracle database. A key benefit is the ability to make a
shadow copy of an open database. You can also use the BACKUP INCREMENTAL LEVEL 1 ...
FROM SCN command in RMAN to make an incremental backup of a VSS shadow copy. For more
details see the Windows eStudy.

What You Already Know
Oracle Data Guard Terminology
Primary Standby
database Redo transport database
Oracle Net
Flash
Recovery
Area
Database Database copy
Oracle Data Guard Terminology

Oracle Data Guard is a management, monitoring, and automation software infrastructure that
works with a production database and one or more standby databases to protect your data against
failures, errors, and corruptions that might otherwise destroy your database. It protects critical
data by providing facilities to automate the creation, management, and monitoring of the
databases and other components in a Data Guard configuration. It automates the process of
maintaining a copy of an Oracle production database (called a standby database) that can be used
if the production database is taken offline for routine maintenance or becomes damaged.
In a Data Guard configuration, a production database is referred to as a primary database. A
standby database is a synchronized copy of the primary database. Using a backup copy of the
primary database, you can create from one to nine standby databases. The standby databases,
together with the primary database, make up a Data Guard configuration. Each standby database
is associated with only one primary database.
Note: You can use the Cascaded Redo Log Destinations feature to incorporate more than nine
standby databases in your configuration.
Configuring standby redo log files is highly recommended on all standby databases in a Data
Guard configuration, including the primary database to aid in role reversal.

Improved Archive Log Management
Primary Standby
database database
Redo transport
Flash
Recovery
Area
Redundant Standby
local copy redo log files
Improved Archive Log Management

Prior to Oracle Database 11g, when the flash recovery area is backed up, the archived logs outside
flash recovery area are not considered. If an archived log has a corrupt block or is missing in the
flash recovery area, then the backup job fails.
In Oracle Database 11g, archive log failover uses another copy of the archived log to continue
writing the backups, when an archived log is found missing or has a corrupt block. This
improvement is transparent.
An optional local archive log destination together with the flash recovery area and new RMAN
configuration options enables you to recover from the loss of the flash recovery area.
In general, the Oracle server and RMAN keep archived logs as long as possible in the flash
recovery area. When space is needed, RMAN first ensures that the user-defined flashback
retention time is met, before proceeding to automatically deleting the archived logs. In Oracle
Database 11g, you can configure archive log deletion based on:
• Shipped configuration (all archived log files are transferred to specified remote locations)
• Number of backups available on a specific device type
RMAN deletes archived logs outside the flash recovery area, when the BACKUP command with
the DELETE INPUT option or the DELETE ARCHIVELOG command is executed.

Configuring Archivelog Deletion Policies
Configuring Archivelog Deletion Policies

You can set your archive log deletion policy in Enterprise Manager for all databases.
Choose from the following options:
• Delete archivelogs that are backed up to tertiary device and are obsolete based on the
retention policy.
• Delete archivelogs after they are applied to the standby database. - The APPLIED ON
STANDBY archive log deletion policy is enhanced to apply to all standby destinations instead
of only mandatory remote destinations. In other words, an archived log is not deleted from
the database node, until all the dependent destinations have consumed it.
• Delete archivelogs after they are shipped to all standby databases.- The logs become eligible
for deletion from the local archive log destination, as soon as they are shipped to all remote
destinations.
Note: If you specify the DELETE command with the FORCE keyword, the RMAN ignores the
policy settings, deletes specified files (whether or not they exist on the media), removes repository
records, and displays the number of deleted objects at the end of the job.
BETA Note: The screenshot does not yet show all new options. For example, RMAN has the
BACKED UP <n> TIMES TO DEVICE TYPE <device_type> option with the log
deletion configuration.

Deleting Backed Up Files
1)
1 Configuring a deletion policy:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2
TIMES TO DEVICE TYPE sbt;
2) Deleting archive logs:

2
DELETE NOPROMPT ARCHIVELOG ALL;
Different example: 3 BACKUP ARCHIVELOG LIKE '/arch%'

DELETE ALL INPUT;
Deleting Backed Up Files

1. Assume that you have an archived redo log deletion policy as shown in step 1.
2. The DELETE ... ARCHIVELOG command deletes all archived logs that meet the
requirements of the configured deletion policy, which specifies that they must be backed up
twice to tape. The DELETE INPUT and DELETE OBSOLETE commands work in the
same way.
3. The third example assumes that you have two archiving destinations set: /arch1 and /arch2.
The command backs up one archived redo log for each unique sequence number. For
example, if archived redo log 1000 is in both directories, RMAN only backs up one copy of
this log. The DELETE INPUT clause with the ALL keyword specifies that RMAN should
delete all archived redo logs from both archiving directories after the backup.With the
configuration in step 1 the DELETE INPUT clause will not delete a archived redo log until
it has been backed up twice to tape.

Duplicating a Database
• With network (no backups required)

• Including customized SPFILE
• Via Enterprise Manager or RMAN command line
Destination or
AUXILIARY database
TCP/IP
Active source or
TARGET database
Duplicating a Database
Prior to Oracle Database 11g, you could create a duplicate database with RMAN for testing or for
standby. It required the source database, a backup copy on the source or on tape, a copy of the
backup on the destination system, and the destination database itself.
Oracle Database 11g greatly simplifies this process. You can instruct the source database to do
online image copies and archived log copies directly to the auxiliary instance, by using Enterprise
Manager or the FROM ACTIVE DATABASE clause of the RMAN DUPLICATE command.
The database files are coming from a TARGET or source database. They are copied via an inter-
instance network connection to a destination or AUXILIARY instance. RMAN then uses a
“memory script” (one that is contained only in memory) to complete recovery and open the
database.

Active Database Duplication:
Select Source

Usage Notes for Active Database Duplication:
• Oracle Net must be aware of the source and destination databases. The FROM ACTIVE
DATABASE clause implies network action.
• If the source database is open, it must have archive logging enabled.
• If the source database is in mounted state (and not a standby), the source database must have
been shutdown cleanly.
• Availability of the source database is not be affected by active database duplication. But the
source database instance provides CPU cycles and network bandwidth.
Enterprise Manager Interface
In Enterprise Manager select Data Movement > Clone Database.

Active Database Duplication: Select Destination

Usage Notes for Active Database Duplication
Password files are copied to the destination. The destination must have the same SYS user
password as the source. In other words, at the beginning of the active database duplication
process, both databases (source and destination) must have password files.
When duplicating a standby database, the password file from the primary database overwrites the
current (temporary) password file on the standby database. When you use command line and do
not duplicate for a standby database, then you need to use the PASSWORD clause (with the FROM
ACTIVE DATABASE clause of the RMAN DUPLICATE command).

Choose Destination Options
See
next screenshot
Choose Destination Options

Note how the information you enter, is used for the new database.

Customize Destination Options
Customize Destination Options

Prior to Oracle Database 11g, the SPFILE parameter file was not copied, because it requires
alterations appropriate for the destination environment. You had to copy the SPFILE into the
new location, edit it, and specify it when starting the instance in NOMOUNT mode or on the
RMAN command line to be used before opening the newly copied database.
With Oracle Database 11g you provide your list of parameters and desired values and the system
sets them. The most obvious parameters are those whose value contains a directory specification.
All parameter values that match your choice (with the exception of the
DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters) are placed.
Note the case-sensitivity of parameters: The case must match for
PARAMETER_VALUE_CONVERT. With the FILE_NAME_CONVERT parameters, pattern
matching is OS specific.
This functionality is equivalent to pausing the database duplication after restoring the SPFILE and
issuing ALTER SYSTEM SET commands to modify the parameter file (before the instance is
mounted).
The example shows how to clone a database on the same host and in the same Oracle Home, with
the use of different top-level disk locations. The source directories are under u01, the destination
under u31. - You need to confirm your choice.

Activating the Job: Schedule
Activating the Job: Schedule

Following the steps of the wizard, you can now schedule the job.

Activating the Job: Review
Activating the Job: Review

Finally, review the information of the source and target databases.

Activating the Job: Submit
Activating the Job: Submit

Scroll down to review more details and submit the job.

Database Duplication: Job Run
Database Duplication: Job Run

The example of the Job Run page shows the following steps:
1. Source Preparation
2. Create Control File
3. Destination Directories Creation
4. Copy Initialization and Password Files
* Skip Copy or Transfer Controlfile
5. Destination Preparation
6. Duplicate Database
* Skip Crating Standby ControlfIle
* Skip Switching Clone Type
7. Recover Database
8. Add Temporary Files
9. Add EM Target
10. Cleanup Source Temporary Directory

The RMAN DUPLICATE Command
DUPLICATE TARGET DATABASE

TO aux
FROM ACTIVE DATABASE
SPFILE PARAMETER_VALUE_CONVERT '/u01', '/u31'
SET SGA_MAX_SIZE = '200M'
SET SGA_TARGET = '125M'
SET LOG_FILE_NAME_CONVERT = '/u01','/u31'
DB_FILE_NAME_CONVERT '/u01','/u31';
The RMAN DUPLICATE Command

The example assumes you have previously connected to both the source or TARGET and the
destination or AUXILIARY instance, which have a common directory structure but different top
level disks. The destination instance uses automatically configured channels.
• This RMAN DUPLICATE command duplicates an open database.
• The FROM ACTIVE DATABASE clause indicates, that you are not using backups (it implies
network action), and that the target is either open or mounted.
• The SPFILE clause indicates that the SPFILE will be restored and modified prior to
opening the database.
• The repeating SET clause essentially issues an ALTER SYSTEM SET param = value
SCOPE=SPFILE command. You can provide as many of these as necessary.
Prerequistes:
The AUXILIARY instance
• Is at the nomount state having been started with a minimal pfile.
• The pfile requires only DB_NAME and REMOTE_LOGIN_PASSWORFILE parameters.
• The password file must exist and have the same SYS user password as the target.
• The directory structure must be in place with the proper permission.
• Connect to AUXILIARY using net service name as the SYS user.

Duplicating a Standby Database
DUPLICATE TARGET DATABASE

FOR STANDBY
FROM ACTIVE DATABASE
SPFILE PARAMETER_VALUE_CONVERT '/u01', '/u31'
SET "DB_UNIQUE_NAME"="FOO"
SET SGA_MAX_SIZE = "200M"
SET SGA_TARGET = "125M"
SET LOG_FILE_NAME_CONVERT = '/u01','/u31'
DB_FILE_NAME_CONVERT '/u01','/u31';
Duplicating a Standby Database

The example assumes that you are connected to the target and auxiliary instances and that the two
environments have the same disk and directory structure.
The FOR STANDBY clause initiates the creation of a standby database without using backups.
The example uses "u01" as the disk of the source and "u31" as the top-level destination
directory. All parameter values that match your choice (with the exception of the
DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters) are replaced in the
SPFILE.

RMAN Multi-Section Backups Overview
Multi-Section backups:
• Created by RMAN
• With your specified size value
• Processed independently (serial or in parallel)
• Producing multi-piece backup sets
RMAN Multi-Section Backups Overview

Oracle data files can be up to 128TB in size. In prior versions, the smallest unit of RMAN backup
is an entire file. This is not practical with such large files. In Oracle Database 11g, RMAN can
break up large files into sections and backup and restore these sections independently, if you
specify the SECTION SIZE option.
Each file section is a contiguous range of blocks in a file. Each file section can be processed
independently, either serially or in parallel. Backing up a file in separate sections can improve
both the performance and allows large file backups to be restarted.
A multi-section backup job produces a multi-piece backup set. Each piece contains one section of
the file. All sections of a multi-section backup, except perhaps for the last section, are the same
size. There are a maximum of 256 sections per file.
Tip: You should not apply large values of parallelism to backup a large file that resides on a small
number of disks.
This feature is built into RMAN. No installation is required beyond the normal installation of the
Oracle Database 11g. COMPATIBLE must be set to at least 11.0, because earlier releases cannot
restore multi-section backups.
In Enterprise Manager select Availability > Backup Settings > Backup Set (tabbed page).

Using RMAN Multi-Section Backups
BACKUP and VALIDATE DATAFILE command option:
SECTION SIZE <integer> [M | K | G]
Using RMAN Multi-Section Backups

The BACKUP and VALIDATE DATAFILE commands accept a new option:
SECTION SIZE <integer> [M | K | G].
Specify your planned size for each backup section. The option is both a backup-command and
backup-spec level option, so that you can apply different section sizes to different files in the
same backup job.
Viewing meta-data about your multi-section backup
• The V$BACKUP_SET and RC_BACKUP_SET views have a MULTI_SECTION column, that
indicates whether this is a multi-section backup or not.
• The V$BACKUP_DATAFILE and RC_BACKUP_DATAFILE views have a
SECTION_SIZE column, that specifies the number of blocks in each section of a multi-
section backup. Zero means a whole-file backups.

Creating Archival Backups with EM
Creating Archival Backups with EM

If you have business requirements to keep records for a long time, you can use RMAN to create
an self contained archival backup of the database or tablespaces. RMAN does not apply the
regular retention policies to this backup. Place your archival backup in a different long-term
storage area, other than in the flash recovery area.
To keep a backup for a long time, perform the following steps in Enterprise Manager:
1. Select Availability > Schedule Backup > Schedule Customized Backup.
2. Follow the steps of the Schedule Customized Backup wizard until you are on the Settings
page.
3. Click Override Current Settings > Policy. In the Override Retention Policy section you can
select to keep a backup for a specified number of days. A restore point is generated based on
the backup job name.
RMAN Syntax:
KEEP {FOREVER|UNTIL TIME 'SYSDATE + n'}
RESTORE POINT <restore_point_name>
Backups created with the KEEP option includes the spfile, control files, and archive redo log files
required to restore this backup. This backup is a snapshot of the database at a point in time, and
can be used to restore the database to another host.

Creating Archival Backups with RMAN
Specifying the KEEP clause, when the database is online

includes both data file and archive log backup sets
KEEP {FOREVER | UNTIL TIME [=] ' date_string '}
NOKEEP
[RESTORE POINT rsname]
Creating Archival Backups with RMAN

Prior to Oracle Database 11g, if you needed to preserve an online backup for a specified amount
of time, RMAN assumed you might want to perform point in time recovery for any time within
that period and RMAN retained all the archived logs for that time period unless you specified
NOLOGS. However, you may have a requirement to simply keep the backup (and what is
necessary to keep it consistent and recoverable) for a specified amount of time, for example, for
two years.
With Oracle Database 11g you can use the KEEP option to generate archival database backups,
that satisfy business or legal requirements. The KEEP option is an attribute of the backup set (not
individual of the backup piece) or copy. The KEEP option overrides any configured retention
policy for this backup. You can retain archival backups, so that they are considered obsolete after
a specified time (KEEP UNTIL) or never (KEEP FOREVER). The KEEP FOREVER clause
requires the use of a recovery catalog. The RESTORE POINT clause creates a restore point in the
control file that assigns a name to a specific SCN that can be restored from this backup.
RMAN includes the data files, archived log files (only those needed to recover an online backup),
and the relevant autobackup files. All these files must go to the same media family (or group of
tapes) and have the same KEEP attributes.

Managing Archival Database Backups
1)
1 Archiving a database backup:
CONNECT TARGET /
CONNECT CATALOG rman/rman@catdb
CHANGE BACKUP TAG 'consistent_db_bkup'
KEEP FOREVER;
2) Changing the status of a database copy:

2
CHANGE COPY OF DATABASE CONTROLFILE NOKEEP;
Managing Archival Database Backups

The CHANGE command changes the exemption status of a backup or copy in relation to the
configured retention policy. For example, you can specify CHANGE ... NOKEEP, to make a
backup that is currently exempt from the retention policy eligible for the OBSOLETE status.
The first example changes a consistent backup into an archival backup, which you plan to store
offsite. Because the database is consistent and therefore requires no recovery, you do not need to
save archived redo logs with the backup.
The second example specifies that any long-term image copies of data files and control files
should lose their exempt status and so become eligible to be obsolete according to the existing
retention policy:
Deprecated clauses: KEEP [LOGS | NOLOGS]
Preferred syntax: KEEP RESTORE POINT <rsname>
Note: The RESTORE POINT option is not valid with CHANGE.
You cannot use CHANGE ... UNAVAILABLE or KEEP for files stored in the flash recovery
area.

Managing Recovery Catalogs
Managing recovery catalogs:

1. Create the recovery catalog.
2. Register your target databases in the recovery catalog.
3. If desired, merge recovery catalogs. NEW
4. If needed, catalog any older backups.
5. If needed, create virtual recovery catalogs for specific
users. NEW
6. Protect the recovery catalog.
Managing Recovery Catalogs

1. Create the recovery catalog.
2. Register your target databases in the recovery catalog. This step enables RMAN to store
metadata for the target databases in the recovery catalog.
3. If desired, you can also use the IMPORT CATALOG command to merge recovery catalogs.
4. If needed, catalog any older backups, whose records are no longer stored in the target
control file.
5. If needed, create virtual recovery catalogs for specific users and determine the metadata to
which they are permitted access. For more details, see the lesson Security New Features for
details.
6. Protect the recovery catalog by including it in your backup and recovery strategy.
The recovery catalog contains metadata about RMAN operations for each registered target
database. The catalog includes the following types of metadata:
• Datafile and archived redo log backup sets and backup pieces
• Datafile copies
• Archived redo logs and their copies
• Tablespaces and data files on the target database
• Stored scripts, which are named user-created sequences of RMAN commands
• Persistent RMAN configuration settings

Managing Recovery Catalogs (continued)
The enrolling of a target database in a recovery catalog for RMAN use is called registration. The
recommended practice is to register all of your target databases in a single recovery catalog. For
example, you can register the prod1, prod2, and prod3 databases in a single catalog owned
by the catowner schema in the catdb database.
The owner of a centralized recovery catalog, which is also called the base recovery catalog, can
grant or revoke restricted access to the catalog to other database users. All metadata is stored in
the base catalog schema.
Each restricted user has full read-write access to his own metadata, which is called a virtual
private catalog.
The recovery catalog obtains crucial RMAN metadata from the control file of each registered
target database. The resynchronization of the recovery catalog ensures that the metadata that
RMAN obtains from the control files is current.
You can use a stored script as an alternative to a command file for managing frequently used
sequences of RMAN commands. The script is stored in the recovery catalog rather than on the file
system. A local stored script is associated with the target database to which RMAN is connected
when the script is created, and can only be executed when you are connected to this target
database. A global stored script can be run against any database registered in the recovery
catalog.
You can use a recovery catalog in an environment in which you use or have used different
versions of the database. As a result, your environment can have different versions of the RMAN
client, recovery catalog database, recovery catalog schema, and target database. You can now
merge one recovery catalog (or metadata for specific databases in the catalog) into another
recovery catalog for ease of management.

Managing Catalogs: Using EM
2 3
Managing Catalogs: Using EM

In Enterprise Manager, select Availability > Recovery Catalog Settings and then the activity you
want to perform.

The IMPORT CATALOG Command NEW
1)
1 Connecting to destination recovery catalog:
CONNECT CATALOG cat111/oracle@destdb;
2) Importing metadata for all registered databases:

2
IMPORT CATALOG cat102/oracle@srcdb;
3)
3 Importing metadata for two registered databases:
IMPORT CATALOG cat92/oracle@catdb DBID=1423241, 1423242;
4) Importing metadata from multiple catalogs:

4
IMPORT CATALOG cat102/rman@srcdb;
IMPORT CATALOG cat101/rman@srcdb;
IMPORT CATALOG cat92/rman@srcdb NO UNREGISTER;
The IMPORT CATALOG Command

With the IMPORT CATALOG command you import the metadata from one recovery catalog
schema into a different catalog schema. If you created catalog schemas of different versions to
store metadata for multiple target databases, then this command enables you to maintain a single
catalog schema for all databases.
1. RMAN must be connected to the destination recovery catalog, for example the cat111
schema, which is the catalog into which you want to import catalog data. This is the first step
in all examples above.
IMPORT CATALOG <connectStringSpec>
[DB_ID = <dbid> [, <dbid>,…]]
[DB_NAME=<dbname>[, <dbname,…]]
[ NO UNREGISTER ];
<connectStringSpec> is the source recovery catalog connect string. The version of the
source recovery catalog schema must be equal to the current version of the RMAN executable. If
needed, upgrade the source catalog to the current RMAN version.
DB_ID: Your can specify the list of database id whose metadata should be imported from the
source catalog schema. When not specified, RMAN merges metadata for all database IDs from
the source catalog schema into the destination catalog schema. RMAN issues an error if the
database whose metadata is merged is already registered in the recovery catalog schema.

The IMPORT CATALOG Command (continued)
DB_NAME: You can specify the list of database names whose metadata should be imported. If the
database name is ambiguous RMAN issues an error.
NO UNREGISTER: By default, the imported database ids are unregistered from the source
recovery catalog schema after a successful import. By using the NO UNREGISTER option, you
can force RMAN to keep the imported database ids in the source catalog schema.
Import Examples continued:
2. In this example, the cat102 user owns an RMAN catalog (version 10.2) in the srcdb
database. You want RMAN to import all registered databases and unregister them in the
source catalog.
3. The cat92 user owns an RMAN catalog (version 9.2) in the srcdb database. You want
RMAN to import the databases with the DBID 1423241 and 1423242, and unregister
them in the source catalog.
4. The srcdb database contains three different recovery catalogs. RMAN imports metadata for
all database ids (registered in these catalogs) into the cat111 schema in the destdb
database. All imported target databases are unregistered from their source catalogs except for
the databases registered in the cat92 schema.
Additional usage details:
• Ensure that no target database is registered in both the source catalog schema and destination
catalog schema. If a target database is registered in both schemas, then unregister this
database from source catalog and retry the import.
• If the operation fails in the middle of the import, then the import is rolled back. There is
never a state of partial import.
• When stored scripts in the source and destination catalog schemas have name conflicts,
RMAN renames the stored script of the source catalog schema.

Summary
In this lesson, you should have learned how to:

• Describe Oracle Database 11g new and enhanced
RMAN features
• Configure archivelog deletion policies
• Duplicate active databases by using the Oracle
network (without backups)
• Back up large files in multiple sections
• Create archival backups for long-term storage
• Manage recovery catalog, for example, merge multiple
catalog versions

Practice 10 Overview:
Using RMAN New Features
This practice covers the following topics:

• Duplicating an active database
• Merging catalogs
Note: Insert practice number (#) in the slide title following the word Practice.

Using Flashback and LogMiner
Copyright © 2007, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to:

• Describe transactions and undo
• Describe undo backup optimization
• Prepare your database for flashback
• Create, change and drop a flashback data archive
• View flashback data archive metadata
• Setup flashback transaction prerequisites
• Query transactions with and without dependencies
• Choose back-out options and flash back transactions
• Using EM LogMiner
• Review transaction details

New and enhanced features in the Oracle Database 11g:

• Optimized undo backup
• Flashback Data Archive
• Flashback Transaction or Job Backout
• Browser-Based Enterprise Manager Integrated Interface
for LogMiner

Transactions produce undo data. In Oracle Database 11g, undo data that is not needed for
transaction recovery (for example, for committed transactions), is not backed up.
Flashback Data Archive provides the ability to automatically track and store all transactional
changes to a record for the duration of its lifetime. You no longer need to build this intelligence
into the application. This feature also provides seamless access to historical data with "as of"
queries. You can use Flashback Data Archive for compliance reporting, audit reports, data
analysis and decision support.
Oracle Database 11g allows you to flashback selected transactions and all the dependent
transactions. This recovery operation utilizes undo data to create and execute the corresponding
compensating transactions that revert the affected data back to its original state. Flashback
Transaction increases availability during logical recovery by easily and quickly backing out a
specific transaction or set of transactions, and their dependent transactions, with one command,
while the database remains online.
Enterprise Manager Database Control now has an interface for LogMiner. In prior releases,
administrators were required to install and use the standalone Java Console for LogMiner. With
this new interface, administrators have a task-based, intuitive approach to using LogMiner.

What You Already Know and
What Is New
Transactions and Undo
Original
data in
buffer cache
Undo "old" data

DML operations in undo tablespace
Transactions and Undo

When a transaction starts, it is assigned to an undo segment. Throughout the life of the
transaction, when data is changed, the original "old" values are copied into the undo segment. You
can see which transactions are assigned to which undo segments by checking the
V$TRANSACTION dynamic performance view.
Undo segments are specialized segments that are automatically created by the instance as needed
to support transactions. Like all segments, undo segments are made up of extents, which, in turn,
consist of data blocks. Undo segments automatically grow and shrink as needed, acting as a
circular storage buffer for their assigned transactions.
Transactions fill extents in their undo segments until a transaction is completed or all space is
consumed. If an extent fills up and more space is needed, the transaction acquires that space from
the next extent in the segment. After all extents have been consumed, the transaction either wraps
around back into the first extent or requests a new extent to be allocated to the undo segment.
Note: Parallel DML operations can actually cause a transaction to use more than one undo
segment. To learn more about parallel DML execution, see the Oracle Database Administrator’s
Guide.

What You Already Know and
What Is New
Guaranteeing Undo Retention
SELECT statements If a transaction generates

running 15 minutes or less more undo than there is space
are always satisfied. in the undo tablespace, it will
fail.
Guaranteeing Undo Retention

The default undo behavior is to overwrite committed transactions that have not yet expired rather
than to allow an active transaction to fail because of lack of undo space. (So in case of conflict,
transactions have precedence over queries.)
This behavior can be changed by guaranteeing retention. With guaranteed retention, undo
retention settings are enforced even if they cause transactions to fail. (So in case of conflict,
queries have precedence over transactions.)
RETENTION GUARANTEE is a tablespace attribute rather than an initialization parameter. This
attribute can be changed only with SQL command-line statements. The syntax to change an undo
tablespace to guarantee retention is:
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
To return a guaranteed undo tablespace to its normal setting, use the following command:
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;
Backup Optimization
Prior to Oracle Database 11g, RMAN has two ways of eliminating blocks from the backup piece,
which only applies to full backups:
• Null block compression: Never used blocks are not backed up.
• Unused block compression: Currently not used blocks are not backed up.

Guaranteeing Undo Retention (Continued)
In Oracle Database 11g, undo data that is not needed for transaction recovery (for example, for
committed transactions), is not backed up.
The benefit is reduced overall backup time and storage by not backing up undo that applies to
committed transactions. This optimization is automatically enabled.

Preparing Your Database for Flashback
• Creating an undo tablespace

• Enabling Automatic Undo Management
• Specifying versus guaranteeing undo retention
Default database initialization parameters:

— UNDO_MANAGEMENT='AUTO'
— UNDO_TABLESPACE='UNDOTBS1'
— UNDO_RETENTION=900
Preparing Your Database for Flashback

To enable flashback features for an application, you must perform these tasks:
• Create an undo tablespace with enough space to keep the required data for flashback
operations.
The more often users update the data, the more space is required. The database administrator
usually calculates the space requirement. If you are uncertain about your space requirements,
you can start with an automatically extensible undo tablespace, observe it through one
business cycle (for example, 1 or 2 days), collect undo block information with the
V$UNDO_STAT view, calculate your space requirements, and use them to create an
appropriately sized fixed undo tablespace. (The calculation formula is in the Oracle Database
Administrator's Guide.)
• By default, Automatic Undo Management is enabled. If needed, enable Automatic Undo
Management, as explained in the Oracle Database Administrator's Guide.
• For a fixed-size undo tablespace, the Oracle database automatically tunes the system to give
the undo tablespace the best possible undo retention.
• For an automatically extensible undo tablespace (default), the Oracle database retains undo
data to satisfy at a minimum, the retention periods needed by the longest running query and
the threshold of undo retention, specified by the UNDO_RETENTION parameter.

Preparing Your Database for Flashback (Continued)
You can query V$UNDOSTAT.TUNED_UNDORETENTION to determine the amount of time for
which undo is retained for the current undo tablespace. Setting the UNDO_RETENTION
parameter does not guarantee, that unexpired undo data is not overwritten. If the system needs
more space, the Oracle database can overwrite unexpired undo with more recently generated undo
data.
• Specify the RETENTION GUARANTEE clause for the undo tablespace to ensure that
unexpired undo data is not discarded.
• Grant flashback privileges to users, roles, or applications that need to use flashback features.
To satisfy long retention requirements, create a flashback data archive.

11g New Features For Administrators Student Guide-8

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

11g New Features For Administrators Student Guide-8

Загружено:

Авторское право:

Доступные форматы

SQL Access Advisor: Schedule and Review

9 - 28 Copyright © 2007, Oracle. All rights reserved.

SQL Access Advisor: Schedule and Review

Oracle Database 11g: New Features for Administrators 9 - 28

9 - 29 Copyright © 2007, Oracle. All rights reserved.

SQL Access Advisor: Results

Oracle Database 11g: New Features for Administrators 9 - 29

9 - 30 Copyright © 2007, Oracle. All rights reserved.

SQL Access Advisor: Results

Oracle Database 11g: New Features for Administrators 9 - 30

SQL Access Advisor: Recommendation Implementation

Oracle Database 11g: New Features for Administrators 9 - 31

9 - 32 Copyright © 2007, Oracle. All rights reserved.

SQL Access Advisor: Results

Oracle Database 11g: New Features for Administrators 9 - 32

9 - 33 Copyright © 2007, Oracle. All rights reserved.

SQL Access Advisor: Results

Oracle Database 11g: New Features for Administrators 9 - 33

9 - 34 Copyright © 2007, Oracle. All rights reserved.

SQL Access Advisor: PL/SQL Procedure Flow

Oracle Database 11g: New Features for Administrators 9 - 34

9 - 35 Copyright © 2007, Oracle. All rights reserved.

SQL Access Advisor: PL/SQL Example

Oracle Database 11g: New Features for Administrators 9 - 35

In this lesson, you should have learned how to:

9 - 36 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 9 - 36

Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 10 - 1

After completing this lesson, you should be able to:

10 - 2 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 10 - 2

Improved archive log management:

10 - 3 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 10 - 3

Faster and optimized backup through:

10 - 4 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 10 - 4

10 - 5 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 10 - 5

Oracle Database 11g: New Features for Administrators 10 - 6

Database Database copy

10 - 7 Copyright © 2007, Oracle. All rights reserved.

Oracle Data Guard Terminology

Oracle Database 11g: New Features for Administrators 10 - 7

10 - 8 Copyright © 2007, Oracle. All rights reserved.

Improved Archive Log Management

Oracle Database 11g: New Features for Administrators 10 - 8

10 - 9 Copyright © 2007, Oracle. All rights reserved.

Configuring Archivelog Deletion Policies

Oracle Database 11g: New Features for Administrators 10 - 9

2) Deleting archive logs:

Different example: 3 BACKUP ARCHIVELOG LIKE '/arch%'

10 - 10 Copyright © 2007, Oracle. All rights reserved.

Deleting Backed Up Files

Oracle Database 11g: New Features for Administrators 10 - 10

• With network (no backups required)

10 - 11 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 10 - 11

10 - 12 Copyright © 2007, Oracle. All rights reserved.

Active Database Duplication

Oracle Database 11g: New Features for Administrators 10 - 12

10 - 13 Copyright © 2007, Oracle. All rights reserved.