Oracle Database 19c: Backup and Recovery: Activity Guide D106548GC10
Oracle Database 19c: Backup and Recovery: Activity Guide D106548GC10
Activity Guide
D106548GC10
Sean Kim This document contains proprietary information and is protected by copyright and other
intellectual property laws. You may copy and print this document solely for your own use
in an Oracle training course. The document may not be modified or altered in any way.
Technical Contributors Except where your use constitutes "fair use" under copyright law, you may not use, share,
and Reviewers download, upload, copy, print, display, perform, reproduce, publish, license, post,
transmit, or distribute this document in whole or in part without the express authorization
Mark Fuller of Oracle.
James Spiller
The information contained in this document is subject to change without notice and is not
Jim Womack warranted to be error-free. If you find any errors, please report them to us in writing.
Trademark Notice
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All
SPARC trademarks are used under license and are trademarks or registered trademarks
of SPARC International, Inc. AMD, Epyc, and the AMD logo are trademarks or registered
trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open
Group.
This documentation may provide access to or information about content, products, and
services from third parties. Oracle Corporation and its affiliates are not responsible for and
expressly disclaim all warranties of any kind with respect to third-party content, products,
and services unless otherwise set forth in an applicable agreement between you and
Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or
damages incurred due to your access to or use of third-party content, products, or
services, except as set forth in an applicable agreement between you and Oracle.
Table of Contents
For product-specific credentials used in this course, see the following table:
Overview
In these practices, you learn how to configure your database to enable recovery from various
losses. You verify the control file configuration, the fast recovery area (FRA), redo log groups,
ARCHIVELOG mode, and redundant archive log destinations.
How to configure your database for recovery:
Ensure redundancy of control files. If a control file is damaged or lost, recovery is
easier if you have another copy.
Review the fast recovery area configuration.
Ensure that there are at least two redo log members in each group. If a redo log
member is damaged or lost, recovery is easier when you have an additional member in
Overview
In this practice, you verify that the control file is multiplexed.
A control file is a small binary file that describes the structure of the database. It must be
available for writing by the Oracle server whenever the database is mounted or opened. Without
this file, the database cannot be mounted, and recovery or re-creation of the control file is
required. Your database should have a minimum of two control files on different storage devices
to minimize the impact of a loss of one control file. The loss of a single control file causes the
instance to fail because all control files must be available at all times. However, recovery can be
a simple matter of copying one of the other control files. The loss of all control files is slightly
more difficult to recover from, but is not usually catastrophic.
Time Estimate
It should take approximately 15 minutes to complete this practice.
Tasks
1. Open a terminal window and use the oraenv script to set the environment variables for the
orclcdb container database.
$ . oraenv
ORACLE_SID = [orclcdb] ?
The Oracle base remains unchanged with value /u01/app/oracle
$
2. Start SQL*Plus and connect to the CDB root as the SYS user with the SYSDBA privilege.
$ sqlplus / AS SYSDBA
…
Connected to an idle instance.
SQL>
3. If the database instance is not started, start the instance and open the database.
SQL> startup
ORACLE instance started.
…
Database mounted.
Database opened.
SQL>
NAME
----------------------------------------------------------------
/u01/app/oracle/oradata/ORCLCDB/control01.ctl
/u01/app/oracle/fast_recovery_area/ORCLCDB/control02.ctl
SQL>
When the CDB was created, DBCA created two control files. When you use the CREATE
DATABASE command in SQL*Plus to create a database, you configure the
NAME TYPE
---------------------------------------------------- -------
VALUE
--------------------------------------------------------
control_files string
/u01/app/oracle/oradata/ORCLCDB/control01.ctl,
/u01/app/oracle/fast_recovery_area/ORCLCDB/control02.ctl
SQL>
6. Create a parameter file (PFILE) from the server parameter file (SPFILE).
SQL> CREATE PFILE FROM SPFILE;
File created.
SQL>
7. Shut down the database instance in IMMEDIATE mode.
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
8. Exit SQL*Plus.
SQL> EXIT
SQL>
14. Start the database instance.
SQL> STARTUP
ORACLE instance started.
…
Database mounted.
Database opened.
SQL>
NAME TYPE
------------------------------------ -----------
VALUE
------------------------------
control_files string
/u01/app/oracle/oradata/ORCLCDB/control01.ctl,
/u01/app/oracle/fast_recovery_area/ORCLCDB/control02.ctl
SQL>
Question: Why does the CONTROL_FILES parameter still show only two control files?
SQL>
File created.
SQL>
18. Start the database instance.
SQL> STARTUP
ORACLE instance started.
…
Database mounted.
Database opened.
NAME TYPE
------------------------------------ -----------
VALUE
------------------------------
control_files string
/u01/app/oracle/oradata/ORCLCDB/control01.ctl,
/u01/app/oracle/fast_recovery_area/ORCLCDB/control02.ctl,
/u01/app/oracle/controlfiles_dir/ORCLCDB/control03.ctl
SQL>
20. Query the V$CONTROLFILE view to confirm the number of control files. The result indicates
that three control files are defined.
SQL> SELECT name FROM v$controlfile;
NAME
----------------------------------------------------------------
/u01/app/oracle/oradata/ORCLCDB/control01.ctl
/u01/app/oracle/fast_recovery_area/ORCLCDB/control02.ctl
/u01/app/oracle/controlfiles_dir/ORCLCDB/control03.ctl
SQL>
Overview
In this practice, you review the fast recovery area (FRA) configuration and change its size to 12
GB.
Assumptions
You are logged in to SQL*Plus from the previous practice.
Time Estimate
It should take approximately 5 minutes to complete this practice.
NAME TYPE
------------------------------------ -----------
VALUE
------------------------------
db_recovery_file_dest string
/u01/app/oracle/fast_recovery_area
db_recovery_file_dest_size big integer
14970M
SQL>
Question: Is the fast recovery area enabled?
Answer: Yes. The DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE
parameters values are not null, indicating that the fast recovery area is enabled.
Question: What changes can you make to the fast recovery area?
Answer: You can change the location and size of the fast recovery area.
System altered.
SQL>
Note: If the archived redo log file destination fills up or cannot be written to, the database
Overview
Ensure that there are at least two redo log members in each group. If you are using file system
storage, then each member should be distributed on separate disks or controllers so that no
single equipment failure impacts an entire log group. The loss of an entire current log group is
one of the most serious media failures because it can result in data loss. The loss of a single
member of a multi-member log group does not affect database operation (other than causing an
alert to be published in the alert log). One set of members should be stored in the FRA.
Assumptions
You are logged in to SQL*Plus from the previous practice.
Tasks
1. Query V$LOGFILE to determine the configuration (number of members) for each redo log
group. The result shows that there are currently three log groups (1, 2, and 3) and only one
member in each group.
SQL> SELECT group#, status, member FROM v$logfile;
SQL>
Question: Why is it recommended to have three groups when two would be sufficient?
Answer: The Oracle Database server treats the online redo log groups as a circular buffer
in which to store transaction information, filling one group and then moving on to the next.
After all groups have been written to, the Oracle Database server begins overwriting
information in the first log group. If the database is configured in ARCHIVELOG mode, the
LGWR cannot overwrite data in the first log group if it has not been archived.
Question: Can multiplexing redo logs impact database performance?
Answer: Multiplexing redo logs may heavily influence database performance because a
commit cannot complete until the transaction information has been written to the logs by
LGWR. You must place your redo log files on your fastest disks served by your fastest
controllers. If possible, do not place any other database files on the same disks as your
redo log files. Because only one group is written to at a given time, there is no performance
impact in having members from several groups on the same disk.
Database altered.
Database altered.
Database altered.
SQL>
3. Verify that the redo log files are now multiplexed. The query result shows that each group
has two members, and therefore, the redo log files are multiplexed. Observe the INVALID
status of the newly added redo log members. This status is expected because the new
members have not yet been written to by LGWR. When a log switch occurs and the group
containing the new member becomes CURRENT, the new member's status will change to
null.
SQL> SELECT group#, status, member FROM v$logfile ORDER BY 1, 3;
1
/u01/app/oracle/oradata/ORCLCDB/redo01.log
2 INVALID
/u01/app/oracle/fast_recovery_area/ORCLCDB/redo02b.log
2
/u01/app/oracle/oradata/ORCLCDB/redo02.log
3
/u01/app/oracle/oradata/ORCLCDB/redo03.log
6 rows selected.
SQL>
4. Switch the log files and observe the changes.
a. Find out which log group is the current log group. In this example, the query result
shows that group 1 is the current group. Your current group may be different.
System altered.
System altered.
System altered.
SQL>
GROUP# STATUS
------ -------
MEMBER
----------------------------------------------------------------
1
/u01/app/oracle/fast_recovery_area/ORCLCDB/redo01b.log
2
/u01/app/oracle/fast_recovery_area/ORCLCDB/redo02b.log
2
/u01/app/oracle/oradata/ORCLCDB/redo02.log
3
/u01/app/oracle/fast_recovery_area/ORCLCDB/redo03b.log
3
/u01/app/oracle/oradata/ORCLCDB/redo03.log
6 rows selected.
SQL>
d. Query the V$LOG view again to learn which log group is now the current group. In this
example, the results show that the LGWR is writing to group 1. Your group may be
different. Your statuses may be different too. An INACTIVE status means the log group
is no longer needed for database instance recovery.
SQL> SELECT group#, members, archived, status FROM v$log;
System altered.
SQL>
f. Query the V$LOG view again. The current group has changed to group 2, and the
former current group's status is now ACTIVE. Your current group may be different. An
ACTIVE status means that the log group is active, but it’s not the current log group. It is
needed for crash recovery. It may be in use for block recovery.
SQL> SELECT group#, members, archived, status FROM v$log;
System altered.
SQL>
h. Query the V$LOG view again. The current group has changed again to group 3, and the
status of both the other groups is now ACTIVE. Your current group may be different.
SQL> SELECT group#, members, archived, status FROM v$log;
SQL>
Question: Can the LGWR background process write to only one member of the CURRENT
group in case the other members are missing or damaged?
Answer: Yes, it can. As long as there is one member left in the CURRENT group, LGWR
can work.
GROUP# STATUS
---------- ----------------
1 ACTIVE
2 ACTIVE
3 CURRENT
SQL>
Database altered.
System altered.
SQL>
c. Drop the member in the next group and then perform a log switch.
SQL> ALTER DATABASE DROP LOGFILE MEMBER
'/u01/app/oracle/fast_recovery_area/ORCLCDB/redo03b.log';
Database altered.
System altered.
SQL>
Database altered.
System altered.
SQL>
e. Verify that each group now has only one member.
SQL>
f. Exit from SQL*Plus.
SQL> exit
…
$
g. Remove the physical files from the operating system.
$ rm /u01/app/oracle/fast_recovery_area/ORCLCDB/redo*.log
$
h. Verify that the redo log files have been removed.
$ ls /u01/app/oracle/fast_recovery_area/ORCLCDB
archivelog control02.ctl onlinelog
$
Overview
In this practice, you configure your database for ARCHIVELOG mode so that redo logs are
archived.
Assumptions
You are logged in as the oracle user.
Time Estimate
It should take approximately 10 minutes to complete this practice.
Database altered.
SQL>
Database altered.
SQL>
4. Exit from SQL*Plus.
SQL> EXIT
…
$
Overview
In these practices, you will verify the default backup destination, set the RMAN display data and
time format, verify that control file autobackup is configured, and verify the backup retention
policy.
Overview
In this practice, you determine the default backup destination setting and create a backup in the
default location.
Assumptions
You have a terminal window open with the environment variables set for the ORCLCDB database
instance.
Timing Estimate
It should take approximately 5 minutes to complete this practice.
SQL> exit
$
2. Log in to RMAN, execute the BACKUP DATABASE command, and then exit RMAN.
$ rman target "'/ as sysbackup'"
…
RMAN> BACKUP DATABASE;
Starting backup at 18-JUN-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
…
Finished backup at 18-JUN-19
…
Finished Control File and SPFILE Autobackup at 18-JUN-19
RMAN> exit
Overview
In this practice, you set the date/time format that RMAN uses for displaying time stamps. The
default date format does not include the time of day information. You will be performing several
backups and recoveries in the same day, and in some cases, you will need to determine which
backup to use.
Assumptions
You completed Practice 3-1.
You have a terminal window open with the environment variables set for the ORCLCDB database
instance.
Tasks
1. Set the NLS_LANG and NLS_DATE_FORMAT variables so that RMAN includes time
information in any time stamp values.
Use the editor of your choice (vi, gedit) and add the following two lines to the end of the
~oracle/.bashrc file:
export NLS_LANG=american_america.al32utf8
export NLS_DATE_FORMAT="yyyy-mm-dd:hh24:mi:ss"
a. In a terminal window, invoke your editor. This example uses the gedit editor.
$ gedit ~oracle/.bashrc
b. Copy and paste by using the mouse buttons and icons in the editor, save your changes,
and then close the gedit window.
Note: If you are not copying and pasting the variables, double-check that the
NLS_LANG value is written correctly with a letter “l”, not a digit “1”.
c. View the modified file by using the cat command and apply the new settings.
$ cat ~oracle/.bashrc
# .bashrc
…
export NLS_LANG=american_america.al32utf8
export NLS_DATE_FORMAT="yyyy-mm-dd:hh24:mi:ss"
$ . .bashrc
$
RMAN>
a. List the backups and note the time stamp format. The output shows the most recent
backups.
RMAN> list backup;
using target database control file instead of recovery catalog
RMAN>
3. Tip: Because the output of the RMAN commands can be quite long, consider using the
RMAN SPOOL LOG TO <file> command to direct the output to your specified file.
a. Optionally, enter SPOOL LOG TO /tmp/test.log in your RMAN window.
Repeat the previous LIST BACKUP command.
Overview
In this practice, you configure or confirm RMAN settings for the following tasks:
To back up the control file and server parameter file (SPFILE) each time RMAN takes a
backup of anything in the orclcdb database
To ensure that one redundant backup is kept
Then you perform a tablespace backup to verify these settings.
Assumptions
You completed Practice 3-2.
Timing Estimate
It should take approximately 5 minutes to complete this practice.
Tasks
1. While still logged in to an RMAN session as SYSBACKUP, verify that control file autobackup
is enabled.
RMAN> show controlfile autobackup;
RMAN>
2. View the current retention policy setting to verify that it is set to 1.
RMAN> show retention policy;
RMAN>
3. Determine which data file belongs to the USERS tablespace in ORCLPDB1.
RMAN> REPORT SCHEMA;
Report of database schema for database with db_unique_name
ORCLCDB
RMAN>
5. Exit RMAN.
RMAN> exit
Overview
In these practices, you will create a script file that can be used to re-create the control file. You
will also create a whole database backup and a partial database backup.
Overview
In this practice, you back up your control file to a trace file and then create a file of SQL
commands that can be used to re-create the control file.
Tip
The loss of a single control file causes the database instance to fail because all control files
must be available at all times. However, recovery can be a simple matter of copying one of the
other control files. The loss of all control files is slightly more difficult to recover from, but is not
usually catastrophic as long as you created a copy of the control file by backing it up to a trace
file.
Timing Estimate
It should take approximately 10 minutes to complete this practice.
Tasks
1. Open a terminal window and use the oraenv script to set the environment variables for the
ORCLCDB database.
$ . oraenv
ORACLE_SID = [orclcdb] ?
The Oracle base remains unchanged with value /u01/app/oracle
$
2. Use the dbstart.sh script to start the database and listener. If your database is currently
running, you will see ORA-01081, which you can safely ignore.
$ dbstart.sh
…
SQL> ORA-01081: cannot start already-running ORACLE - shut it
down first
…
$
3. Start SQL*Plus and connect to the CDB root as the SYS user with SYSDBA privileges.
$ sqlplus / as sysdba
…
SQL>
NAME
----------------------------------------------------------------
/u01/app/oracle/oradata/ORCLCDB/control01.ctl
/u01/app/oracle/fast_recovery_area/ORCLCDB/control02.ctl
/u01/app/oracle/controlfiles_dir/ORCLCDB/control03.ctl
SQL>
5. Back up the control file to a trace file.
SQL> ALTER DATABASE BACKUP controlfile TO trace;
SQL>
6. Exit SQL*Plus.
SQL> EXIT
…
$
7. Navigate to the directory that contains the alert log file and trace files.
$ cd /u01/app/oracle/diag/rdbms/orclcdb/orclcdb/trace
[trace]$
8. List the files in this directory. Notice that the directory contains the alert log
(alert_orclcdb.log) and many trace files (.trc).
[trace]$ ls
alert_orclcdb.log orclcdb_ora_8708.trc
orclcdb_dia0_12061_base_1.trc orclcdb_ora_8708.trm
…
[trace]$
9. View the end of the alert log and make note of the last trace file created as a backup for the
control file. In this example, it is orclcdb_ora_8708.trc. Your file name will be different.
[trace]$ tail alert_orclcdb.log
…
alter database backup controlfile to trace
2019-06-20T13:24:51.885054+00:00
Backup controlfile written to trace file
/u01/app/oracle/diag/rdbms/orclcdb/orclcdb/trace/orclcdb_ora_870
8.trc
Completed: alter database backup controlfile to trace
…
Question: Are the data files, temp files, and control files that structure the ORCLCDB
database included in the SQL script?
Answer: Yes, they are included. All data and temp files of the different containers (the CDB
root, CDB seed, PDB1, and so on) and the multiplexed redo log files are present.
Question: Why are there two cases—Set #1. NORESETLOGS and Set #2. RESETLOGS?
Answer: The first case from the STARTUP NOMOUNT to the ALTER SESSION SET
CONTAINER = CDB$ROOT provides a script to execute a complete database recovery. Use
this only if the current versions of all online logs are available. The second case provides a
script to execute an incomplete database recovery. Use this only if online logs are
damaged. The contents of online logs will be lost, and all backups will be invalidated.
Question: When would you have to regenerate the trace file from the current control files?
Answer: Because the control file changes after each data file or redo log file change
(adding, removing, resizing) or database attribute change (ARCHIVELOG), you would have
to redo the backup of your control file to a trace file.
Overview
In this practice, you use Recovery Manager (RMAN) to configure automatic backups of the
control file and server parameter file (SPFILE) when a backup of the database is made and
when there is a structural change to the database.
Assumptions
You are logged in to the compute node as the oracle user.
Timing Estimate
Tasks
1. Start Recovery Manager and connect to the CDB root (target database) as the SYS user.
$ rman target /
…
connected to target database: ORCLCDB (DBID=2778750799)
RMAN>
2. Show all RMAN settings. Notice the CONFIGURE CONTROLFILE AUTOBACKUP ON;
setting.
RMAN> SHOW ALL;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name
ORCLCDB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO
BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; #
default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; #
default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
Overview
In this practice, you use Recovery Manager to back up your entire database, including the
archived redo log files, the SPFILE, and the control files. The backup should be the base for an
incremental backup strategy.
Assumptions
You are logged in as the oracle user.
Timing Estimate
It should take approximately 30 minutes to complete this practice.
RMAN>
2. View the structure of the CDB in terms of PDBs, tablespaces, and data files (permanent
and temporary). Your file numbers will differ from those shown below.
RMAN> REPORT schema;
Report of database schema for database with db_unique_name
ORCLCDB
RMAN>
3. Back up the whole database. Your results will be different from the results shown below; for
example, the piece handle names will be different.
RMAN> BACKUP DATABASE;
RMAN>
Question: How can hot backups (inconsistent backups) be used in complete database
recovery?
Question: Did the backup include the SPFILE and control files?
Answer: Yes. This is the last operation completed at the end of the backup command.
…
Starting Control File and SPFILE Autobackup at 2019-06-
20:15:47:32
piece
handle=/u01/app/oracle/fast_recovery_area/ORCLCDB/autobackup/201
9_06_20/o1_mf_s_1011455252_gjqbno6q_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2019-06-
20:15:47:33
RMAN>
5. Exit RMAN.
RMAN> EXIT
6. Verify that the files are stored on disk in the FRA.
$ cd /u01/app/oracle/fast_recovery_area/ORCLCDB
$ ls -ltR
…
./8857B36632797E5CE0536210ED0ADAC7:
./8857B36632797E5CE0536210ED0ADAC7/backupset:
total 8
drwxr-x--- 2 oracle oinstall 4096 Jun 20 15:47 2019_06_20
drwxr-x--- 2 oracle oinstall 4096 Jun 18 19:39 2019_06_18
./8857B36632797E5CE0536210ED0ADAC7/backupset/2019_06_20:
total 588196
-rw-r----- 1 oracle oinstall 602308608 Jun 20 15:47
o1_mf_nnndf_TAG20190620T154656_gjqbmzl3_.bkp
./8857B36632797E5CE0536210ED0ADAC7/backupset/2019_06_18:
total 1305840
-rw-r----- 1 oracle oinstall 66494464 Jun 18 19:39
o1_mf_nnndf_TAG20190618T193903_gjlhgq5r_.bkp
-rw-r----- 1 oracle oinstall 602128384 Jun 18 19:29
o1_mf_nnndf_TAG20190618T192926_gjlgx5j1_.bkp
-rw-r----- 1 oracle oinstall 66494464 Jun 18 18:04
o1_mf_nnndf_TAG20190618T180429_gjl9xfgb_.bkp
-rw-r----- 1 oracle oinstall 602054656 Jun 18 17:22
o1_mf_nnndf_TAG20190618T172148_gjl7g5kp_.bkp
./onlinelog:
total 0
$
Question: Where are the backups of control files and SPFILE located?
Answer: They are created in the autobackup subdirectory.
Question: How are backups deleted?
RMAN>
b. Issue the SHOW RETENTION POLICY command. The policy is REDUNDANCY 1.
RMAN>
Question: How does Oracle determine when files are obsolete?
Answer: There are two retention policy parameters that are mutually exclusive:
If a retention policy is enabled with RECOVERY WINDOW OF 5 DAYS, the window
stretches from the current time (SYSDATE) to the point of recoverability, which is the
earliest date to which you want to recover. The point of recoverability is SYSDATE -
integer days in the past.
If a retention policy is enabled with REDUNDANCY r, then RMAN skips backups only if
at least n backups of an identical file exist on the specified device, where n=r+1
(default is 1).
RMAN automatically deletes obsolete backup sets and copies in the FRA when space is
needed.
8. Manually delete obsolete files by issuing the DELETE OBSOLETE command. If there are
obsolete files, respond YES when prompted. Your results will differ from this example.
RMAN> delete obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
Deleting the following obsolete backups and copies:
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ -----------------
Backup Set 2 2019-06-18:17:22:22
RMAN>
9. Back up the database and archive logs as image copies. At the same time, free space in
the FRA by deleting the archive log files once they are backed up.
a. Perform the backup.
RMAN> BACKUP AS COPY DATABASE PLUS ARCHIVELOG DELETE INPUT;
RMAN>
Question: What would you do if an error such as the following occurs?
RMAN-00571:
===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS
===============
RMAN-00571:
Overview
In this practice, you use Recovery Manager to back up ORCLPDB1, including the archived redo
log files. You also back up a specific tablespace in ORCLPDB2.
Assumptions
You are logged in as the oracle user.
Time Estimate
It should take approximately 20 minutes to complete this practice.
RMAN>
2. Back up ORCLPDB1, including the archived redo log files.
RMAN> BACKUP PLUGGABLE DATABASE ORCLPDB1 PLUS ARCHIVELOG;
Starting backup at 2019-06-20:17:57:57
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=37 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=36 RECID=11
STAMP=1011456318
input archived log thread=1 sequence=37 RECID=13
STAMP=1011456386
input archived log thread=1 sequence=38 RECID=14
STAMP=1011463077
channel ORA_DISK_1: starting piece 1 at 2019-06-20:17:57:58
channel ORA_DISK_1: finished piece 1 at 2019-06-20:17:57:59
piece
handle=/u01/app/oracle/fast_recovery_area/ORCLCDB/backupset/2019
_06_20/o1_mf_annnn_TAG20190620T175758_gjql96rc_.bkp
tag=TAG20190620T175758 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2019-06-20:17:57:59
Overview
In this practice, you will configure Block Change Tracking (BCT). Although BCT is optional, it
reduces the time required for an incremental backup from the time to scan all the blocks in the
database to a time proportional to the number of blocks that have changed since the last
backup.
The BCT file can contain only 8 bitmaps, so the backup cannot be optimized if there have been
more than 8 incremental backups since the parent level backup that the new incremental will be
based on. Consider the 8-bitmap limit when developing your incremental backup strategy. For
example, if you make a level 0 database backup followed by 7 differential incremental backups,
the block change tracking file now includes 8 bitmaps. If you then make a cumulative level 1
Assumptions
You have a terminal window open with variables set for the ORCLCDB database instance.
Time Estimate
It should take approximately 5 minutes to complete this practice.
Tasks
1. Configure block change tracking to place the BCT file in the default data file creation
destination.
a. Start SQL*Plus and connect to your ORCLCDB database with administrator privileges.
$ sqlplus / as sysdba
…
SQL>
b. Set the DB_CREATE_FILE_DEST initialization parameter to
/u01/app/oracle/oradata/ORCLCDB.
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST =
'/u01/app/oracle/oradata/ORCLCDB';
System altered.
SQL>
Database altered.
SQL>
Note: In another practice, you will disable block change tracking again, because it is
not required for the practice environment.
2. Exit SQL*Plus.
SQL> exit
…
$
Overview
In this practice, you create an image copy of the target database for use as a base for an
incremental backup strategy. You perform an incremental level 1 backup, and apply the
incremental to the level 0 backup.
Note: Applying the incremental backup to the level 0 image copies makes the level 0 backup
the same as if you had taken a level 0 instead of level 1.
Assumptions
You have two terminal windows open. Environment variables in both windows are set for the
ORCLCDB database instance.
Tasks
1. Perform the following steps to check if the ORCLPDB1 pluggable database is open, and
open it if it is not.
a. Log in to SQL*Plus as SYSDBA.
$ sqlplus / as sysdba
…
SQL>
b. Check the open mode of the PDBs. If ORCLPDB1 is open in READ WRITE mode, exit
from SQL*Plus and proceed to step 2.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 ORCLPDB1 READ WRITE NO
4 ORCLPDB2 READ WRITE NO
SQL>
c. Optionally, if ORCLPDB1 is MOUNTED, open the PDB and then verify the change.
SQL> alter pluggable database orclpdb1 open;
RMAN> run {
ALLOCATE CHANNEL "ch1" DEVICE TYPE DISK FORMAT
"/home/oracle/backup/orclcdb/%U";
BACKUP AS COPY TAG 'BASE01' INCREMENTAL LEVEL 0 DATABASE;
}
using target database control file instead of recovery catalog
allocated channel: ch1
channel ch1: SID=262 device type=DISK
RMAN>
As the backup is performed, notice where the backup files are created.
4. Open a new terminal window and start a workload that updates your database by executing
the DBMod_Backup_workload.sh script.
$ cd /home/oracle/labs/DBMod_Backup
$ ./DBMod_Backup_workload.sh
…
SQL>
Session altered.
SQL> Connected.
SQL> SQL> SQL> SQL> SQL> 2 3 4
2190 rows updated.
SQL>
Commit complete.
…
$
Note: The script updates over 2000 rows.
RMAN>
Note: The time of the incremental data file backup is faster than the original level 0 and
some data files do not need to be backed up at all.
6. Apply the incremental backups to the existing level 0 backup. Notice the recovery of the
data file copy and the restore operation.
RMAN> run {
ALLOCATE CHANNEL "ch1" DEVICE TYPE DISK FORMAT
"/home/oracle/backup/orclcdb/%U";
RECOVER COPY OF DATABASE WITH TAG 'BASE01';
}
…
Starting recover at 2019-06-20:21:12:44
no copy of datafile 5 found to recover
no copy of datafile 6 found to recover
no copy of datafile 8 found to recover
channel ch1: starting incremental datafile backup set restore
channel ch1: specifying datafile copies to recover
recovering datafile copy file number=00001
name=/home/oracle/backup/orclcdb/data_D-ORCLCDB_I-2778750799_TS-
SYSTEM_FNO-1_1ju4jnpc
RMAN>
Statement processed
RMAN>
8. Exit RMAN and remove your test data by executing the
DBMod_Backup_cleanupINVENTORY.sh script.
RMAN> exit
…
$ ./DBMod_Backup_cleanupINVENTORY.sh
$
9. Optionally, use your other terminal window to view the output in the /tmp/cleanup.log
file while the DBMod_Backup_cleanupINVENTORY.sh script is executing.
$ cat /tmp/cleanup.log
10. Use the RMAN DELETE OBSOLETE command to delete obsolete backups. Be sure to
respond YES when prompted.
$ rman target "'/ as sysbackup'"
…
connected to target database: ORCLCDB (DBID=2778750799
RMAN>
Note: Your output may be different depending on the repetition of practices.
11. Optionally, crosscheck all data file copies of the ORCLCDB database.
RMAN> crosscheck datafilecopy all;
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
RMAN>
12. Exit RMAN.
RMAN> exit
$
13. Close the second terminal window if you have not already done so.
Overview
In this practice, you create backups of important database files that are not part of the default
backup set.
Assumptions
You are using a terminal window with environment variables pointing to the ORCLCDB database
instance.
Time Estimate
It should take approximately 10 minutes to complete this practice.
Database altered.
SQL>
c. Exit from SQL*Plus.
SQL> exit
…
$
d. View the trace file. What can you learn from its content?
Note: The trace file requires some editing before it can be used.
$ cat /home/oracle/backup/orclcdb/control.sql
…
-- the database with the NORESETLOGS option and should be used
only if
-- the current versions of all online logs are available. The
second
-- set opens the database with the RESETLOGS option and should
be used
Overview
In this practice, you will use RMAN to create an archival backup.
Overview
In this practice, you create an archival backup, that is, a backup that is not under your normal
retention policies and it is not in your normal fast recovery area (FRA) destination. This KEEP
FOREVER database backup could be used for recovery if some of your later hands-on activities
were to require it. Archival backups can be created with an open or a mounted database.
You must use a recovery catalog to be able to create an archival backup of an OPEN database.
Without a recovery catalog, you must put the database in a MOUNTED state.
Assumptions
You are using a terminal window as the oracle OS user, with environment variables pointing to
Timing Estimate
It should take approximately 20 minutes to complete this practice.
Tasks
1. Log in to RMAN.
$ rman target "'/ as sysbackup'"
…
connected to target database: ORCLCDB (DBID=2778750799)
RMAN>
2. Shut down and then restart the database instance in MOUNT mode so you can create a
backup copy of the entire database in a mounted state.
RMAN> SHUTDOWN IMMEDIATE;
RMAN>
Question: Why did the backup command fail?
Answer: It failed because a backup with the KEEP FOREVER option requires the use of a
recovery catalog. A recovery catalog is required when KEEP FOREVER is specified because
backup records will eventually age out of the control file.
4. Attempt to make an archival backup of your ORCLCDB database that will be kept for 365
days.
RMAN> BACKUP AS COPY DATABASE KEEP UNTIL TIME 'SYSDATE+365';
RMAN>
RMAN>
6. Open the database.
RMAN> alter database open;
Statement processed
RMAN>
7. Delete obsolete backups. Be sure to respond YES to the prompt.
RMAN> delete obsolete;
RMAN>
Overview
In these practices, you will monitor an RMAN backup job.
Overview
In this practice, you will monitor an RMAN backup job by using the V$SESSION_LONGOPS view.
Assumptions
You are logged in as the oracle user.
It is assumed that the database and listener are running. You can use the pgrep -lf smon
command to verify that the database is started and the pgrep -lf tns command to verify
that the listener is started. If you need to restart the database and listener, use the dbstart.sh
script.
Tasks
1. Log in to SQL*Plus. See Course Practice Environment: Security Credentials for password
information.
$ sqlplus system/<password>
…
SQL>
2. Open a new terminal window and set the environment variables for the ORCLCDB database.
$ . oraenv
ORACLE_SID = [orclcdb] ?
The Oracle base remains unchanged with value /u01/app/oracle
$
3. In the same terminal window, start Recovery Manager and connect to the CDB root (target
database) as the SYS user.
$ rman target /
…
connected to target database: ORCLCDB (DBID=2778750799)
RMAN>
4. Create a whole database backup.
RMAN> BACKUP DATABASE;
…
Starting backup at 2019-06-21:18:52:23
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=277 device type=DISK
RMAN>
SQL> /
SQL> /
no rows selected
SQL>
Question: How can you use this query to determine if there is something wrong with the
backup job?
Answer: If you execute the query at intervals of 2 minutes or more and the %_COMPLETE
column does not increase, then it is likely that RMAN is encountering a problem.
6. Return to your RMAN session. After the backup completes, log out of RMAN.
RMAN> exit
…
$
Overview
In these practices, you will perform the following one-time setup tasks:
Create a recovery catalog owner.
Create a recovery catalog.
Overview
In this practice, you create a user and grant appropriate privileges.
Assumptions
You are in a terminal window with the environment variables pointing to the RCATCDB database
instance.
Timing Estimate
It should take approximately 10 minutes to complete this practice.
SQL>
b. Start the instance.
SQL> startup
ORACLE instance started.
…
Database opened.
SQL>
c. Exit from SQL*Plus.
SQL> exit
…
$
3. Create a tablespace named RCATTBS for the recovery catalog.
a. Use SQL*Plus to log in to the RCATPDB PDB as the SYS user with the SYSDBA role.
Refer to the Course Practice Environment: Security Credentials document for the
correct password.
Tablespace created.
SQL>
4. Create a user that will own the recovery catalog data. Name the user RCATOWNER. The
default tablespace should be the RCATTBS tablespace, and the user should have unlimited
quota on that tablespace. Refer to the Course Practice Environment: Security Credentials
document for the correct password to replace <password>.
SQL> CREATE USER rcatowner IDENTIFIED BY <password> DEFAULT
TABLESPACE rcattbs QUOTA unlimited on rcattbs;
User created.
SQL>
5. Grant the RECOVERY_CATALOG_OWNER role to the RCATOWNER user and exit from
SQL*Plus.
SQL> GRANT recovery_catalog_owner TO rcatowner;
Grant succeeded.
SQL> exit
…
$
Overview
In this practice, you use RMAN to create the recovery catalog in the RCATPDB pluggable
database.
Assumptions
A terminal window is open with the environment variables pointing to the RCATCDB database
instance.
Timing Estimate
It should take approximately 5 minutes to complete this practice.
RMAN>
2. Create the recovery catalog. This command may take a few minutes to complete. When
you see the RMAN> prompt, exit the RMAN session.
RMAN> create catalog;
RMAN> exit
…
$
Overview
In these practices, you will perform the following one-time setup tasks:
Register the ORCLCDB database in the recovery catalog.
Overview
In this practice, you use RMAN to register the ORCLCDB database in the recovery catalog that
you created in a previous practice.
Assumptions
A terminal window is open.
Timing Estimate
It should take approximately 5 minutes to complete this practice.
RMAN>
3. Register the database in the catalog.
RMAN> register database;
RMAN>
Overview
Your organization determined that if the recovery catalog is lost or damaged, it needs to be
restored quickly and completely.
In this practice, you configure the retention policy for the recovery catalog (retaining two
backups), configure the fast recovery area for RCATCDB, enable archive log mode, and back up
your RCATCDB database.
You back up the recovery catalog to implement a backup strategy of incremental backups
applied to image copies. This provides a method of fast restore by switching to the image copy
rather than copying the backups back to the original location.
Timing Estimate
It should take approximately 25 minutes to complete this practice.
Tasks
1. Configure the retention policy with at least redundancy 2.
a. Set your environment variables to point to the RCATCDB database.
$ . oraenv
ORACLE_SID = [orclcdb] ? rcatcdb
The Oracle base remains unchanged with value /u01/app/oracle
$
b. Start RMAN and use the recovery catalog database (RCATCDB) as the target, with no
catalog specified. Refer to the Course Practice Environment: Security Credentials
document for the correct password.
Note: The recovery parameters are configured at the CDB level.
$ rman target sys
…
target database Password: ********
connected to target database: RCATCDB (DBID=2073894879)
RMAN>
c. Make sure that the retention policy for the recovery catalog is set to redundancy
greater than 1. If it is not, set it to at least 2.
RMAN> show retention policy;
RMAN>
d. Exit RMAN.
System altered.
SQL>
3. Verify that the recovery catalog database is in ARCHIVELOG mode.
a. Check whether RCATCDB is in ARCHIVELOG mode.
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 5
Current log sequence 7
SQL>
SQL>
c. Put the database in ARCHIVELOG mode and then open the database.
Database altered.
Database altered.
SQL>
d. Verify that the database is now in ARCHIVELOG mode.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 5
Next log sequence to archive 7
Current log sequence 7
SQL>
e. Verify that RCATPDB is open.
SQL> show pdbs
SQL>
g. Exit from SQL*Plus.
RMAN>
b. Back up the recovery catalog database as an image copy and a base for incremental
backups. Review the output and find the data file for the tablespace that you created
for the recovery catalog.
RMAN> BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE;
RMAN>
c. Exit RMAN.
RMAN> exit
…
$
Overview
In these practices, you will create and execute a stored script.
Overview
In this practice, you create a stored script.
Assumptions
You have a terminal window open.
Timing Estimate
It should take approximately 10 minutes to complete this practice.
Tasks
RMAN>
3. Display the names of the stored scripts.
RMAN> LIST SCRIPT NAMES;
List of Stored Scripts in Recovery Catalog
RMAN>
RMAN>
5. List the contents of the script you created.
RMAN> PRINT SCRIPT db_arch_bkup;
RMAN>
6. Modify the db_arch_bu script so that it also deletes obsolete archived log files.
RMAN> REPLACE SCRIPT db_arch_bkup
2> {
3> BACKUP DATABASE PLUS ARCHIVELOG;
4> DELETE OBSOLETE;
5> }
RMAN>
7. Once again list the contents of the script.
RMAN> PRINT SCRIPT db_arch_bkup;
RMAN>
Overview
In this practice, you execute a stored script.
Assumptions
You have a terminal window. You successfully completed the practice to create a stored script
named db_arch_bkup.
Timing Estimate
It should take approximately 10 minutes to complete this practice.
RMAN>
3. Execute the db_arch_bkup script. Be sure to respond YES when prompted to delete the
obsolete backups.
RMAN> run
2> {
3> EXECUTE SCRIPT db_arch_bkup;
4> }
RMAN>
4. Verify that your script created a full database backup.
RMAN> list backup;
RMAN>
5. Exit RMAN.
RMAN> exit
Overview
In these practices, you will create a virtual catalog and use the virtual catalog when taking a
backup of ORCLPDB1.
114 Practices for Lesson 12: Creating and Using Virtual Private Catalogs
Practice 12-1: Enabling the Virtual Private Database (VPD)
Functionality
Overview
In this practice, you enable the Virtual Private Database (VPD) functionality.
RMAN uses the VPD functionality to implement virtual private catalogs. The VPD functionality is
not enabled by default when the RMAN base recovery catalog is created. You need to explicitly
enable the VPD model for a base recovery catalog by running the
$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql script.
Assumptions
Timing Estimate
It should take approximately 15 minutes to complete this practice.
Tasks
1. Set the environment variables for the recovery catalog database (RCATCDB).
$ . oraenv
ORACLE_SID = [orcldb] ? rcatcdb
The Oracle base remains unchanged with value /u01/app/oracle
$
2. Invoke SQL*Plus and log in to RCATPDB as the SYSDBA user. Refer to the Course Practice
Environment: Security Credentials document for the correct password.
$ sqlplus sys@rcatpdb as sysdba
…
Enter password: ********
…
SQL>
3. Execute the $ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql script to enable the
VPD model for all the virtual private catalogs of the base catalog schema, RCATOWNER.
SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rcatowner
Checking the operating user... Passed
========================================
VPD SETUP STATUS:
Practices for Lesson 12: Creating and Using Virtual Private Catalogs 115
VPD privileges granted successfully!
Connect to RMAN base catalog and perform UPGRADE CATALOG.
$
4. Upgrade the recovery catalog.
a. Invoke RMAN and connect to the recovery catalog database. Refer to the Course
Practice Environment: Security Credentials document for the correct password.
$ rman catalog rcatowner@rcatpdb
…
recovery catalog database Password:
RMAN>
b. Execute the UPGRADE CATALOG command. Be sure to enter the command a second
time when prompted.
RMAN> upgrade catalog;
RMAN>
c. Exit from RMAN.
RMAN> exit
…
$
116 Practices for Lesson 12: Creating and Using Virtual Private Catalogs
Practice 12-2: Creating a Virtual Private Catalog
Overview
In this practice, you create a new user and create a virtual private catalog.
Assumptions
Timing Estimate
It should take approximately 15 minutes to complete this practice.
Tasks
1. Invoke SQL*Plus and connect to the recovery catalog database with administrator
Tablespace created.
SQL>
3. Create a new user who will own the virtual private catalog. Refer to the Course Practice
Environment: Security Credentials document for the correct password.
SQL> CREATE USER vpcowner IDENTIFIED BY <password>
2 DEFAULT TABLESPACE vpctbs
3 QUOTA UNLIMITED ON vpctbs;
User created.
SQL>
Practices for Lesson 12: Creating and Using Virtual Private Catalogs 117
4. Grant the CREATE SESSION privilege to the new user who owns the virtual private catalog.
SQL> GRANT CREATE SESSION TO vpcowner;
Grant succeeded.
SQL>
5. Exit SQL*Plus.
SQL> exit
…
$
6. Invoke RMAN and connect to the recovery catalog database as the base recovery catalog
owner. Refer to the Course Practice Environment: Security Credentials document for the
RMAN>
7. Grant access to the metadata for the ORCLPDB1 PDB to the virtual private catalog owner.
RMAN> GRANT CATALOG FOR PLUGGABLE DATABASE orclpdb1 TO vpcowner;
Grant succeeded.
RMAN>
8. Exit RMAN.
RMAN> exit
…
$
118 Practices for Lesson 12: Creating and Using Virtual Private Catalogs
Practice 12-3: Backing Up a PDB
Overview
In this practice, you will connect to the virtual private catalog and back up the ORCLPDB1 PDB.
Assumptions
You have an open terminal window.
Timing Estimate
It should take approximately 15 minutes to complete this practice.
Tasks
RMAN>
c. Connect to recovery catalog database, RCATPDB, as the VPCOWNER user. Refer to the
Course Practice Environment: Security Credentials document for the correct password.
RMAN> CONNECT CATALOG vpcowner@rcatpdb;
RMAN>
2. Perform a backup of the ORCLPDB1 PDB.
RMAN> backup pluggable database orclpdb1;
Practices for Lesson 12: Creating and Using Virtual Private Catalogs 119
channel ORA_DISK_1: SID=38 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00010
name=/u01/app/oracle/oradata/ORCLCDB/orclpdb1/sysaux01.dbf
input datafile file number=00012
name=/u01/app/oracle/oradata/ORCLCDB/orclpdb1/users01.dbf
input datafile file number=00009
name=/u01/app/oracle/oradata/ORCLCDB/orclpdb1/system01.dbf
input datafile file number=00011
name=/u01/app/oracle/oradata/ORCLCDB/orclpdb1/undotbs01.dbf
channel ORA_DISK_1: starting piece 1 at 2019-07-01:18:31:43
channel ORA_DISK_1: finished piece 1 at 2019-07-01:18:31:58
RMAN>
3. List the backups in the virtual private catalog.
RMAN> list backup;
120 Practices for Lesson 12: Creating and Using Virtual Private Catalogs
11 Full 3470037 2019-06-21:14:57:43 NO
/u01/app/oracle/oradata/ORCLCDB/orclpdb1/undotbs01.dbf
12 Full 3470037 2019-06-21:14:57:43 NO
/u01/app/oracle/oradata/ORCLCDB/orclpdb1/users01.dbf
RMAN>
4. Exit RMAN.
RMAN> exit
…
$
5. Now connect as the recovery catalog owner and list the backups.
a. Connect to RMAN. Refer to the Course Practice Environment: Security Credentials
document for the correct password.
$ rman target "'/ as sysbackup'" catalog rcatowner@rcatpdb
…
connected to target database: ORCLCDB (DBID=2778750799)
recovery catalog database Password:
connected to recovery catalog database
Practices for Lesson 12: Creating and Using Virtual Private Catalogs 121
RMAN>
b. List the backups in the recovery catalog.
RMAN> list backup;
122 Practices for Lesson 12: Creating and Using Virtual Private Catalogs
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse
Name
---- -- ---- ---------- ------------------- ----------- ------
9 Full 3470037 2019-06-21:14:57:43 NO
/u01/app/oracle/oradata/ORCLCDB/orclpdb1/system01.dbf
10 Full 3470037 2019-06-21:14:57:43 NO
/u01/app/oracle/oradata/ORCLCDB/orclpdb1/sysaux01.dbf
11 Full 3470037 2019-06-21:14:57:43 NO
/u01/app/oracle/oradata/ORCLCDB/orclpdb1/undotbs01.dbf
12 Full 3470037 2019-06-21:14:57:43 NO
/u01/app/oracle/oradata/ORCLCDB/orclpdb1/users01.dbf
Practices for Lesson 12: Creating and Using Virtual Private Catalogs 123
12 Full 3515990 2019-07-01:18:31:43 NO
/u01/app/oracle/oradata/ORCLCDB/orclpdb1/users01.dbf
RMAN>
c. Exit RMAN.
RMAN> exit
…
$
6. Close the terminal window opened for this practice.
124 Practices for Lesson 12: Creating and Using Virtual Private Catalogs
Oracle Internal & Oracle Academy Use Only
Practices for Lesson 13:
Restore and Recovery
Concepts
Practices for Lesson 13
Overview
In these practices, you will use the Data Recovery Advisor to diagnose database failure.
Overview
In this practice, you will use Data Recovery Advisor via the RMAN client interface to diagnose
and repair the loss of a data file.
Assumptions
You have two terminal windows open in which $HOME/labs/DBMod_Recovery is the current
directory, and environment variables point to the orclcdb database instance.
Tasks
1. Open a terminal window and execute the rec_config.sh script from the
SQL> startup
ORACLE instance started.
...
SQL> exit
$
5. Use the Data Recovery Advisor to list the database failure. Note: You might see one or
more failure IDs.
$ rman target "'/ as sysbackup'"
…
RMAN> LIST FAILURE;
RMAN>
6. Use the Data Recovery Advisor to obtain advice on how to repair the failure. Note: During a
manual recovery, if you see more than one optional manual action, you would focus on the
one that references bar91tbs01.dbf, the missing file.
RMAN> ADVISE FAILURE;
Database Role: PRIMARY
...
RMAN>
Statement processed
RMAN> exit
…
$
9. Confirm that ORCLPDB1 is open.
$ sqlplus / as sysdba
…
SQL> show PDBS
SQL> exit
$
10. Return to the first terminal window. Clean up the environment following this practice by
executing the cleanup_02_01.sh. script. You can view the script output in the
/tmp/cleanup.log file.
$ ./cleanup_02_01.sh
$
11. Close the second terminal window.
Overview
In these practices, you will initiate a recovery operation by using RMAN commands. You will use
the Data Recovery Advisor to recover a datafile.
Overview
In this practice, you recover your CDB after the data file for the SYSTEM tablespace (in the CDB
root) has been inadvertently removed.
Tip
Because you use several windows at the same time in this practice, you may find it helpful to
change the name of each of them in their banner at the top.
To set a title for a terminal window:
1. In the terminal window's menu, select Terminal and then Set Title. A Set Title dialog box is
displayed.
Assumptions
You are logged in as the oracle user.
You have configured the database for recovery.
It is assumed that the database and listener are running. You can use the pgrep -lf
smon command to verify that the database is started and the pgrep -lf tns
command to verify that the listener is started. If you need to restart the database and
listener, use the dbstart.sh script.
Tasks
SQL> EXIT
b. Perform the backup to the default location.
$ rman target /
...
connected to target database: ORCLCDB (DBID=2778750799)
...
Window 1
1. Use the same terminal window as Window 1.
2. Execute the $HOME/labs/DBMod_Recovery/RMAN_crash.sh shell script to remove the
data file of the SYSTEM tablespace in the CDB root.
Note: This script may end with an error showing that data file system01.dbf cannot be
opened.
$ $HOME/labs/DBMod_Recovery/RMAN_crash.sh
System altered.
$
3. Attempt an administrative task, such as creating a user.
a. Start SQL*Plus and connect to the CDB root as the SYSTEM user. Refer to Course
Practice Environment: Security Credentials for the password value.
Note: At this point, any SQL statement gives an error.
$ sqlplus system/<password>
…
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-01116: error in opening database file 1
ORA-01110: data file 1:
'/u01/app/oracle/oradata/ORCLCDB/system01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00604: error occurred at recursive SQL level 2
ORA-01116: error in opening database file 1
Enter user-name: ^C
$
4. Consider your recovery options.
a. Question: Which type of recovery is possible in this case?
Answer: A complete recovery is possible as long as you have all available backups
RMAN>
Statement processed
RMAN>
4. Open all PDBs.
RMAN> ALTER PLUGGABLE DATABASE ALL OPEN;
Statement processed
RMAN>
5. Exit RMAN.
RMAN> EXIT
System altered.
System altered.
RMAN>
7. Window 1: Start the database instance in MOUNT mode.
RMAN> STARTUP MOUNT;
database mounted
…
RMAN>
8. Window 1: Use the LIST FAILURE command to determine the error. The value in the
Summary column tells you that system01.dbf is missing.
RMAN> LIST FAILURE;
RMAN>
RMAN>
RMAN>
11. Window 1: Use the REPAIR FAILURE command to repair database failures identified by
the Data Recovery Advisor. When prompted, enter YES to execute the repair. When
prompted to open the database, enter YES.
RMAN> REPAIR FAILURE;
RMAN>
12. Window 1: Open all the PDBs.
RMAN> ALTER PLUGGABLE DATABASE ALL OPEN;
RMAN>
13. Window 1: Exit RMAN.
RMAN> EXIT
Overview
In this practice, you recover a PDB data file that has been inadvertently removed.
Assumptions
You are logged in as the oracle user.
orclcdb and the listener are started.
Tasks
1 row created.
Commit complete.
$
2. Start RMAN and connect to the CDB root as the SYS user.
$ rman target /
…
connected to target database: ORCLCDB (DBID=1500451933)
RMAN>
3. Back up ORCLPDB1.
RMAN> BACKUP PLUGGABLE DATABASE ORCLPDB1;
RMAN>
4. Exit RMAN.
RMAN> EXIT
System altered.
System altered.
Session altered.
SQL>
c. Create a table named ODR.TEST. and insert a row into the table.
SQL> CREATE TABLE odr.test (c NUMBER);
Table created.
RMAN>
7. Recover the database. Notice the line "starting media recovery." If you had tried to restore
and recover just the data file or just the tablespace, you might have encountered media
recovery errors for other data files in the tablespace.
RMAN> RECOVER DATABASE;
RMAN>
8. Start ORCLPDB1.
RMAN> STARTUP
database opened
RMAN>
Session altered.
SQL>
no rows selected
Note: The table was not created because the table definition exists in the SYSTEM
System altered.
System altered.
$
2. Create an application table and try to insert data into it.
a. Connect to the CDB root as the SYS user with the SYSDBA privilege.
$ sqlplus / AS SYSDBA
…
SQL>
Session altered.
SQL>
c. Show the open mode of ORCLPDB1. The result shows that ORCLPDB1 is still open.
SQL> SHOW PDBS
RMAN>
5. Execute the REPAIR command. This command restores and recovers the data file.
RMAN> REPAIR PLUGGABLE DATABASE ORCLPDB1;
RMAN>
6. Open ORCLPDB1.
RMAN> ALTER PLUGGABLE DATABASE ORCLPDB1 OPEN;
Statement processed
RMAN>
7. Exit RMAN.
RMAN> EXIT
1 row created.
SQL>
Commit complete.
SQL>
d. Exit SQL*Plus.
SQL> EXIT
…
$
Overview
In these practices, you will perform a point-in-time (also known as incomplete) recovery of the
database. You will also recover a table from a backup set without affecting other objects in the
tablespace or schema.
Overview
In this practice, you set up a scenario that requires an incomplete recovery. Then you perform
the steps that are needed when an archive log is missing after the last backup (and transactions
exist that cannot be re-created); therefore, complete recovery is not possible.
Assumptions
A full backup exists and the archive log files from the time of the backup to the current time are
available.
You have two terminal windows open in which $HOME/labs/DBMod_Recovery is the current
directory, and environment variables point to the orclcdb database instance.
Tasks
1. Verify that the rcatcdb and rcatpdb are open.
a. Set the environment for the rcatcdb database.
$ . oraenv
ORACLE_SID = [orclcdb] ? rcatcdb
The Oracle base remains unchanged with value /u01/app/oracle
b. Verify that the rcatpdb is open, then exit SQL*Plus.
$ sqlplus / as sysdba
…
SQL> SHOW PDBS
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 RCATPDB READ WRITE NO
SQL> EXIT
2. Synchronize the catalog with the database.
a. Set the environment for the orclcdb database instance
$ . oraenv
ORACLE_SID = [rcatcdb] ? orclcdb
The Oracle base remains unchanged with value /u01/app/oracle
RMAN>
4. Back up ORCLPDB1.
Note: A database backup should be taken after every recovery.
RMAN> BACKUP PLUGGABLE DATABASE ORCLPDB1;
RMAN>
5. Exit RMAN.
RMAN> EXIT
SQL> startup
…
Database mounted.
Database opened.
RMAN>
12. Use the RMAN ADVISE FAILURE command to determine if mandatory manual actions
exist, and if automated recovery is available. You may see one or more failures listed.
RMAN> ADVISE FAILURE;
SQL>
Note: If you attempt to query the CURRENT_SCN column of the V$DATABASE view for
orclpdb1, you will get a value of 0 (zero), and not the last "current" SCN. For example:
SQL> ALTER SESSION SET CONTAINER=ORCLPDB1;
Session altered.
SQL> exit
…
$
Note: The SCN was displayed in the RMAN error message, but the first time that this
archive log was used, it was not displayed.
Also note that the V$ARCHIVED_LOG view contains historic information of prior database
incarnations. The NAME column of the active database incarnation contains the path and
name of the archive log; historic incarnations have a null value. The status A is for archived
logs, D is for deleted ones.
database closed
database dismounted
Oracle instance shut down
RMAN>
b. Restore the control file from the autobackup.
RMAN> restore controlfile from autobackup;
RMAN>
RMAN>
18. Restore the entire database from a backup that was taken before the missing archive log
file with the RESTORE DATABASE UNTIL SEQUENCE nn command.
RMAN> RESTORE DATABASE UNTIL SEQUENCE 6; /*enter your missing
log number*/
RMAN>
19. Recover the database through your last available log file.
Note: If incremental backups are available they will be applied first, and then the archive
logs. The number of log files that need to be applied may vary from the example shown.
RMAN> recover database until sequence 6; /*enter your missing
log number*/
Statement processed
Session altered.
SQL>
RMAN> exit
…
$
23. Because the break_04_01.sh script removed an archive log to create an issue for your
RMAN>
Note: Your number of objects might be different.
SALARY
----------
SQL> exit
…
$
26. Execute the cleanup_04_01.sh script from the $HOME/labs/DBMod_Recovery
directory to remove the new user and tablespace created in this practice. The script saves
its output in the /tmp/cleanup.log file.
$ ./cleanup_04_01.sh
$
27. Back up the database. You have a new incarnation of the database and the older backups
are obsolete, although there are certain cases where the older backups can be used. A new
Assumptions
You have two terminal windows open in which you are logged in as the oracle OS user,
$HOME/labs/DBMod_Recovery is the current directory, and environment variables point to
the orclcdb database instance.
Tasks
1. Prepare for this practice by executing the setup_04_02.sh script from the
$HOME/labs/DBMod_Recovery directory. This script:
Creates a new tablespace and user
As the new user, creates a table and populates it
Saves its output in the /tmp/setup.log file.
$ ./setup_04_02.sh
$
2. Start a SQL*Plus session and verify your test configuration.
a. Log in as the SYS user.
$ sqlplus / as sysdba
…
SQL>
b. Confirm that the database is in ARCHIVELOG mode.
SQL> SELECT NAME, LOG_MODE, OPEN_MODE FROM V$DATABASE;
Session altered.
SQL> @lab_04_02a.sql
SQL> COL TABLE_NAME FORMAT A30
SQL> COL TABLESPACE_NAME FORMAT A15
SQL> COL OWNER FORMAT A10
SQL>
SQL> SELECT TABLE_NAME, TABLESPACE_NAME, STATUS
2 FROM DBA_TABLES
3 WHERE OWNER = 'BAR'
4 /
SQL>
RMAN>
NAME CURRENT_SCN
--------- -----------
ORCLCDB 10631091
Be sure to note the SCN value displayed in the CURRENT_SCN column. You will use it
for recovery!
RMAN>
7. In your SQL*Plus session, create the need to recover a table by purging it. Optionally, view
your SCN before and after the DROP TABLE command.
SQL> SELECT NAME, CURRENT_SCN FROM V$DATABASE;
NAME CURRENT_SCN
--------------- -----------
ORCLCDB 10631264
NAME CURRENT_SCN
--------------- -----------
ORCLCDB 10631475
SQL>
8. Optionally, view the current tables that the BAR user owns. The TEST_TABLE should not be
displayed.
SQL> SELECT table_name FROM dba_tables WHERE owner = 'BAR';
SQL>
9. In your RMAN session, recover your test table to YOUR SCN that you recorded in Step 5.
Provide the following input with the RECOVER command:
Names of tables or table partitions to be recovered
SCN (or point in time) to which the tables or table partitions need to be recovered
Whether the recovered tables or table partitions must be imported into the target
database (default is Yes.)
Auxiliary destination '/u01/app/oracle/backup/test'.
First, confirm that the directory of the auxiliary destination is empty and then execute your
RECOVER command. The recover command takes approximately 4 minutes.
RMAN> HOST "ls /u01/app/oracle/backup/test/*";
RMAN>
RMAN>
RMAN> exit
…
$
SQL> exit
…
Overview
In these practices, you will use the Data Recovery Advisor to diagnose database failure.
Overview
In this practice, you will use the Data Recovery Advisor to set up, discover, and repair a
corrupted block in a data file.
Assumptions
You have a terminal window open in which $HOME/labs/DBMod_Recovery is the current
directory, and environment variables point to the orclcdb database instance.
Tasks
1. Prepare for this practice by executing the setup_05_01.sh script. This script creates
FILE_NO BLOCK_NO
---------- ----------
18 129
System altered.
RMAN>
4. Use the RMAN ADVISE FAILURE command and view the suggested repair strategy.
RMAN> ADVISE FAILURE;
Database Role: PRIMARY
RMAN>
5. Use the RMAN REPAIR FAILURE command to recover the corrupted blocks.
RMAN> REPAIR FAILURE;
Strategy: The repair includes complete media recovery with no
data loss
Repair script:
/u01/app/oracle/diag/rdbms/orclcdb/orclcdb/hm/reco_3585523541.hm
RMAN>
7. Exit RMAN.
RMAN> exit
…
Note: This script may end with an error showing that data file system01.dbf cannot be
opened.
8. Verify that the corrupt block has been recovered by running a full table scan on
bc.bccopy.
$ sqlplus / as sysdba
…
SQL> alter session set container = orclpdb1;
Session altered.
Overview
In these practices, you will recover from a number of different database failures. It is highly
recommended to complete those that you start, because earlier ones affect practices that follow.
Overview
In this practice, you will create an issue by deleting the initorclcdb.ora parameter file. After
creating the issue, you must restore the parameter file.
Assumptions
A full backup of the database exists. Autobackup of the control file and SPFILE is assumed to
be configured in the fast recovery area.
You have two terminal windows open in which you are logged in as the oracle OS user,
$HOME/labs/DBMod_Recovery is the current directory, and environment variables point to
Tasks
1. Prepare for this practice by executing the setup_06_01.sh script from the
$HOME/labs/DBMod_Recovery directory. This script:
Creates a new tablespace and user
As the new user creates a table and populates it
Performs a backup of the tablespace and then updates the table
Saves its output in the /tmp/setup.log file
$ ./setup_06_01.sh
$
2. Cause a failure in the database by executing the break_06_01.sh script from the
$HOME/labs/DBMod_Recovery directory. The script saves its output in the
/tmp/break.log file.
$ ./break_06_01.sh
$
3. Attempt to start the database instance. Notice the error messages. Exit from SQL*Plus.
$ sqlplus / as sysdba
…
Connected to an idle instance.
SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file
'/u01/app/oracle/product/18.3.0/dbhome_1/dbs/initorclcdb.ora'
SQL> exit
…
$
RMAN> startup;
startup failed: ORA-01078: failure in processing system
parameters
LRM-00109: could not open parameter file
'/u01/app/oracle/product/19.3.0/dbhome_1/dbs/initorclcdb.ora'
RMAN>
Note: The database has been started with a dummy parameter file to allow the SPFILE to
be restored.
5. Restore the SPFILE. Because the database has been started with a dummy parameter file,
the location of the autobackup must be specified. In this case, you are using the recovery
area and DB_NAME options to specify where the autobackups can be found.
RMAN> restore spfile from autobackup recovery area
'/u01/app/oracle/fast_recovery_area' db_name 'orclcdb';
RMAN>
6. Shut down the database instance and restart it with the restored SPFILE.
RMAN> shutdown;
RMAN> startup;
RMAN> exit
…
$
Overview
In this practice, you first create an issue for recovery by deleting the control02.ctl control
file. After creating the issue, you must restore this single "lost" control file.
Assumptions
A full backup of the database is available. Autobackup of the control file and SPFILE to the fast
recovery area is configured.
You have two terminal windows open in which you are logged in as the oracle OS user,
$HOME/labs/DBMod_Recovery is the current directory, and environment variables point to
the orclcdb database instance.
SQL> startup
ORACLE instance started.
…
ORA-00205: error in identifying control file, check alert log
for more info
SQL> exit
…
$
1: diag/rdbms/dummy/orclcdb
2: diag/rdbms/orclcdb/orclcdb
RMAN>
b. Run the ADVISE FAILURE command.
RMAN> ADVISE FAILURE;
RMAN>
c. Run the REPAIR FAILURE PREVIEW command.
RMAN> REPAIR FAILURE PREVIEW;
RMAN>
7. Restore the control file. You can either execute the commands via the RMAN command
line, or use the REPAIR FAILURE command to perform the task for you.
Note: Any existing copy of the control file can be used to restore the missing copy.
Enter Y or YES when prompted to execute the repair and to open the database.
RMAN> REPAIR FAILURE;
RMAN>
8. Use the LIST FAILURE command to verify that the failure has been repaired.
RMAN> list failure;
RMAN>
9. In your second terminal window, clean up the practice environment by running the
cleanup_06_02.sh script. The script saves its output in the /tmp/cleanup.log file.
$ ./cleanup_06_02.sh
$
Overview
In this practice, you create an issue by removing control files. After creating the issue, you must
restore the control files.
Assumptions
A full backup of the database is available. Autobackup of the control file and SPFILE is
configured.
You have two terminal windows open in which you are logged in as the oracle OS user,
$HOME/labs/DBMod_Recovery is the current directory, and environment variables point to
Tasks
1. Prepare for this practice by executing the setup_06_03.sh script from the
$HOME/labs/DBMod_Recovery directory. This script creates a new tablespace and user.
As the new user, the script creates a table and populates it. The script creates a backup of
the tablespace, and then updates the table.
The script saves its output in the /tmp/setup.log file. You can view this log file while the
script executes.
$ ./setup_06_03.sh
$
2. Cause a failure in the database by executing the break_06_03.sh script from the
$HOME/labs/DBMod_Recovery directory. The script saves its output in the
/tmp/break.log file.
$ ./break_06_03.sh
$
3. Log in to SQL*Plus and attempt to start the database. Notice the error message. Exit from
SQL*Plus.
$ sqlplus / as sysdba
…
Connected to an idle instance.
SQL> startup
ORACLE instance started.
…
ORA-00205: error in identifying control file, check alert log
for more info
RMAN>
RMAN>
9. Attempt to open the database.
RMAN> ALTER DATABASE OPEN;
RMAN>
Question: Why is RESETLOGS necessary?
Answer: RESETLOGS is required because the SCN in the restored control file does not
match the SCN recorded in the data files.
10. Attempt to open the database with the RESETLOGS option.
RMAN> ALTER DATABASE OPEN RESETLOGS;
RMAN-00571: ====================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ============
RMAN-00571: ====================================================
RMAN-03002: failure of sql statement command at 07/02/2019
14:48:39
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1:
'/u01/app/oracle/oradata/ORCLCDB/system01.dbf'
RMAN>
Question: Why did the database open still fail with the RESETLOGS option?
Answer: The SCN in the control file is older than the SCN in the data files and the data files
have not been restored with the UNTIL cause. The database needs to be recovered so that
the control file can be synchronized with the data files.
RMAN>
12. Open the database with RESETLOGS.
RMAN> ALTER DATABASE OPEN RESETLOGS;
Statement processed
Statement processed
13. Use the LIST FAILURE command to verify that the failure has been repaired.
RMAN> list failure;
RMAN>
14. In your second terminal window, optionally log in to SQL*Plus and query V$DATABASE to
view the values of DBID and CURRENT_SCN of both orclcdb and orclpdb1. Exit
SQL*Plus when finished.
$ sqlplus / as sysdba
…
SQL> SELECT NAME, DBID, CURRENT_SCN, LOG_MODE, OPEN_MODE FROM
V$DATABASE;
Session altered.
SQL> exit
…
$
15. Clean up the practice environment by using the cleanup_06_03.sh script from the
$HOME/labs/DBMod_Recovery directory. The script saves its output in the
/tmp/cleanup.log file.
$ ./cleanup_06_03.sh
RMAN> exit
…
$
Overview
In this practice, you recover from the loss of the database password file. The database
password is required for remote access to the database by SYSDBA privileged users.
Assumptions
A full backup of the database is available.
You have two terminal windows open in which you are logged in as the oracle OS user,
$HOME/labs/DBMod_Recovery is the current directory, and environment variables point to
the orclcdb database instance.
Enter user-name: ^C
$
Note: The remote connection requires the use of a password file.
3. Check if the password file exists. The name of the orclcdb database password file for
Linux and UNIX systems is $ORACLE_HOME/dbs/orapworclcdb.
$ ls $ORACLE_HOME/dbs/orapw*
/u01/app/oracle/product/19.3.0/dbhome_1/dbs/orapwrcatcdb
$
The orapworclcdb.ora should not be listed because it was deleted by the
break_06_04.sh script.
Note: It is critically important to the security of your system that you protect your password
file and the environment variables that identify the location of the password file. Any user
with access to these could potentially compromise the security of the connection.
Note: When you exceed the allocated number of password entries, you must create a new
password file. To avoid this necessity, allocate more entries than you think you will ever
need.
6. Test the remote SYSDBA login. Now it should be successful. Use the password specified for
this step in the “Course Practice Environment: Security Credentials” document. Replace
<password> with the correct password.
$ sqlplus sys@orclcdb as sysdba
…
Enter password: <password> <<< Not displayed
…
SQL>
7. Optionally, review the V$PWFILE_USERS view.
SQL> desc V$PWFILE_USERS
Name Null? Type
------------------------- -------- ----------------------------
USERNAME VARCHAR2(128)
SYSDBA VARCHAR2(5)
SYSOPER VARCHAR2(5)
SYSASM VARCHAR2(5)
USERNAME
----------------------------------------------------------------
SYSDB SYSOP SYSAS SYSBA SYSDG SYSKM ACCOUNT_STATUS
----- ----- ----- ----- ----- ----- ----------------------------
PASSWORD_PROFILE
----------------------------------------------------------------
LAST_LOGIN
----------------------------------------------------------------
LOCK_DATE EXPIRY_DATE
------------------- -------------------
EXTERNAL_NAME
----------------------------------------------------------------
AUTHENTI COM CON_ID
-------- --- ----------
SYS
TRUE TRUE FALSE FALSE FALSE FALSE OPEN
PASSWORD YES 0
SQL>
Overview
In these practices, you will configure your database for the use of flashback technologies. You
will then use flashback technologies to restore a dropped table and reverse the actions of a
transaction.
Overview
In this practice, you will configure the database to use the flashback transaction and flashback
table features.
Assumptions
You have two terminal windows open in which you are logged in as the oracle OS user and
/home/oracle/labs/DBMod_Flashback is the current directory. Each terminal window is
connected to the orclpdb1 instance.
Tasks
TUNED_UNDORETENTION
-------------------
900
SQL>
Question: What does the value of the TUNED_UNDORETENTION time represent?
Answer: The number of seconds the data is being retained in the database at any given
time. Undo retention is not guaranteed by default. If the system needs more space, the
Oracle Database server can overwrite unexpired undo with more recently generated undo
data.
System altered.
SQL>
b. Determine the name of the undo tablespace.
Tablespace altered.
SQL>
d. Find the names of the data files associated with the UNDOTBS1 tablespace. Note the
FILE_ID value.
SQL> select file_name, file_id from dba_data_files where
tablespace_name like '%UNDO%';
FILE_NAME FILE_ID
------------------------------------------------------- --------
/u01/app/oracle/oradata/ORCLCDB/orclpdb1/undotbs01.dbf 11
SQL>
Database altered.
SQL>
Question: What happens if undo retention is guaranteed and no more space is available
for active undo records (either because the undo tablespace has filled, reached the
maximum size, or there is no more space left on the storage device [disk])?
SQL> exit
…
$
Overview
In this practice, you will recover a table that has been dropped.
Assumptions
The RECYCLEBIN parameter is set to ON (which you confirmed in Practice 2-1 Step 4).
You have two terminal windows open in which you are logged in as the oracle OS user and
/home/oracle/labs/DBMod_Flashback is the current directory. Each terminal window is
connected to the orclpdb1 instance.
Tasks
ORIGINAL_NAME
----------------------------------------------------------------
OBJECT_NAME
----------------------------------------------------------------
DROPTIME
-------------------
BAR102
BAR102
BIN$jNKlrSHhInLgU6YR7Qqg/Q==$0
2019-07-04:02:22:19
BAR101
BIN$jNKlrSHmInLgU6YR7Qqg/Q==$0
2019-07-04:02:22:19
SQL>
Note: In the preceding output, you see the same object dropped twice at different
points in time. With the time stamp, you determine which version of the table you really
want to restore.
c. Determine which object contains the column of interest. Your object names will be
different. Use your own values from the previous step.
Hint: Select the column from the tables, the one which does not report an error is the
one you want.
Note: The object name from the recycle bin must be in double quotation marks
because it may contain special characters.
SQL> SELECT location_id
FROM BAR."BIN$jNKlrSHcInLgU6YR7Qqg/Q==$0"
WHERE rownum = 1;
Select location_id
*
ERROR at line 1:
ORA-00904: "LOCATION_ID": invalid identifier
LOCATION_ID
-----------
SQL>
d. Restore the object that has the correct columns. Use the correct object name that you
found in the previous step.
SQL> FLASHBACK TABLE BAR."BIN$jNKlrSHhInLgU6YR7Qqg/Q==$0" TO
BEFORE DROP RENAME TO BAR102A;
SQL>
4. Confirm that the BAR.BAR102A table has been restored by selecting the first row. Then exit
SQL*Plus.
Note: It does not matter which row is displayed from the query.
SQL> select * from BAR.BAR102A where rownum = 1;
Overview
In this practice, you will use flashback table to reverse a transaction.
Assumptions
Practice 2-1 has been completed.
You have two terminal windows open in which you are logged in as the oracle OS user and
/home/oracle/labs/DBMod_Flashback is the current directory. Each terminal window is
connected to the orclpdb1 instance.
Tasks
SYSDATE
-------------------
2019-07-04:03:00:25
SQL>
3. Open a new terminal window and execute the break_02_03.sh script. This simulates a
transaction that scrambles the data in the BARCOPY and BARDEPT tables. There is a foreign
key constraint between BARCOPY and BARDEPT. The script saves its output in the
/home/oracle/labs/DBMod_Flashback/break.log file.
$ cd /home/oracle/labs/DBMod_Flashback
$ ./break_02_03.sh
$
Table altered.
Flashback complete.
Flashback complete.
SQL>
5. Check that you have correctly restored the tables. The results of the following query should
match yours, although the row order may be different. Then exit SQL*Plus.
SQL> @check_02_03.sql
11 rows selected.
SQL> exit
…
$
6. Clean up the practice environment by running the cleanup_02_03.sh script.
$ ./cleanup_02_03.sh
$
Overview
In these practices, you will enable flashback logging and perform flashback database.
Overview
In this practice, you will enable flashback logging.
Assumptions
You have two terminal windows open in which you are logged in as the oracle OS user and
/home/oracle/labs/DBMod_Flashback is the current directory. Each terminal window is
connected to the orclpdb1 instance.
Tasks
1. Determine whether flashback logging is enabled while still connected to the container
FLASHBACK_ON
------------------
NO
SQL>
2. Enable flashback logging and verify.
SQL> ALTER DATABASE FLASHBACK ON;
Database altered.
3. In preparation for the next practice, back up your orclpdb1 database, remove obsolete
backups, and ensure that no failures are listed. Then exit RMAN.
SQL> host
$ rman target "'/ as sysbackup'"
…
RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
…
RMAN> delete noprompt obsolete;
…
RMAN> exit
Session altered.
FLASHBACK_ON
------------------
YES
SQL>
5. Keep the terminal windows open for the next practice.
Overview
In this practice, you will flash back your pluggable database after some incorrect updates to the
database. This practice is for learning purposes. If you had a scenario similar to this in a
production environment, you would probably choose a different solution to limit your flashback
to the affected objects, rather than choose a flashback of the entire pluggable database.
Assumptions
You have completed practice 3-1.
You have two terminal windows open in which you are logged in as the oracle OS user and
/home/oracle/labs/DBMod_Flashback is the current directory. Each terminal window is
Tasks
1. There are several ways in which you can perform a flashback database operation. You can
use a guaranteed restore point, SCN, time value, threads, and so on. This example uses
the SCN, but you could also use the RP1 restore point you created in the Practice 3-1 Step
5.
Determine your current SCN. You will need to use it in a later practice step.
SQL> SELECT current_scn FROM v$database;
CURRENT_SCN
-----------
3285954
SQL>
2. View HR data. You will use this information for comparison during this practice.
a. Determine the sum of the SALARY column in the HR.EMPLOYEES table.
SQL> SELECT sum(salary) FROM hr.employees;
SUM(SALARY)
-----------
691416
SQL>
COUNT(*)
----------
3
SQL>
3. Execute the lab_03_02_03.sql script to update tables in the HR schema. It creates
issues from which you will “recover” by flashing back the database in this practice.
SQL> @lab_03_02_03.sql
SQL> update hr.employees
5 rows updated.
SQL>
4. Commit your data and determine the current SCN.
SQL> COMMIT;
Commit complete.
CURRENT_SCN
-----------
32886103
SQL>
SUM(SALARY)
-----------
679092.4
SQL>
b. Determine the total number of employees in department 90, and then exit SQL*Plus.
SQL> SELECT count(*) FROM hr.employees where department_id=90;
SQL> exit
…
$
6. You need to restore the pluggable database so that the data is as it was when you started
this practice. For training purposes, use Flashback Database for this operation.
a. Close the pluggable database orclpdb1.
$ sqlplus / as sysdba
…
SQL> alter pluggable database orclpdb1 CLOSE;
Flashback complete.
c. Attempt to open the pluggable database orclpdb1.
SQL> alter pluggable database orclpdb1 open;
alter pluggable database orclpdb1 open
*
ERROR at line 1:
ORA-01113: file 12 needs media recovery
Session altered.
SUM(SALARY)
-----------
691416
COUNT(*)
----------
3
SQL>
7. Drop the RP1 guaranteed restore point. Then exit SQL*Plus.
SQL> DROP RESTORE POINT rp1;
SQL> exit
…
$
8. Close all terminal windows open for this practice.
Overview
In these practices, you will duplicate an active container database.
Overview
In this practice, you learn how to duplicate an active database. ORCLCDB is the active database
that will be duplicated or cloned as DBTEST. The tasks include the following:
Prepare the destination for the future DBTEST database with Oracle Net connectivity,
password file, and a minimal initialization parameter file (initdbtest.ora).
Confirm source database configuration settings.
Duplicate the ORCLCDB database by using RMAN.
Test access to the cloned database.
$ ls
admin backup checkpoints diag
fast_recovery_area product
audit cfgtoollogs controlfiles_dir donttouch oradata
$ mkdir dbtest_fra
$ ls -l
total 48
drwxr-x--- 6 oracle oinstall 4096 Oct 12 11:06 admin
drwxr-x--- 4 oracle oinstall 4096 Jun 27 2019 audit
drwxr-xr-x 4 oracle oinstall 4096 Oct 12 10:15 backup
drwxr-x--- 4 oracle oinstall 4096 May 8 2019 cfgtoollogs
drwxr-xr-x 2 oracle oinstall 4096 May 8 2019 checkpoints
drwxr-xr-x 3 oracle oinstall 4096 Oct 9 12:18 controlfiles_dir
drwxr-xr-x 2 oracle oinstall 4096 Oct 12 14:35 dbtest_fra
drwxrwxr-x 23 oracle oinstall 4096 May 8 2019 diag
drwxr-xr-x 2 oracle oinstall 4096 Oct 12 10:13 donttouch
drwxr-x--- 4 oracle oinstall 4096 Jun 27 2019
fast_recovery_area
drwxr-x--- 4 oracle oinstall 4096 Jun 27 2019 oradata
$ cd dbtest_fra
$ mkdir orclcdb
$ cd ../oradata
$ ls
ORCLCDB RCATCDB
$ mkdir dbtest
$
3. Prepare Oracle Net connectivity by using the Oracle Net Manager utility. Add a service
named dbtest to the tnsnames.ora file.
a. Launch the Oracle Net Manager utility.
$ netmgr
b. Expand Local in the navigation pane, click Service Naming, then click +.
c. Enter dbtest in the Net Service Name field and click Next.
d. Select TCP for the protocol and click Next.
e. Enter your host's fully qualified domain name (for example,
edvmr1p0.us.oracle.com) in the Host name field and click Next.
f. Enter dbtest in the Service Name field, click the Connection Type pull down list and
choose Dedicated. Click Next, then Finish.
g. Click Listeners in the navigation pane, then click +. Select LISTENER from the list.
Choose Database Services from the pull down list, then click Add Database and enter
dbtest in the Global Database Name field and dbtest in the SID field. Click File and
select Save Network Configuration.
h. Exit Net Manager utility.
…
DBTEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =
...
$ lsnrctl reload
...
$ lsnrctl status
...
Service "dbtest" has 1 instance(s).
Instance "dbtest", status READY, has 1 handler(s) for this
service...
...
SQL> exit
…
$
8. Confirm the ORCLCDB source database configuration settings in SQL*Plus.
a. Set your environment variables to point to orclcdb, and then log in to SQL*Plus as
SYSBDA.
$ . oraenv
ORACLE_SID = [dbtest] ? orclcdb
The Oracle base remains unchanged with value /u01/app/oracle
SQL>
b. Confirm your backup location and size. If the FRA is smaller than 20G, enlarge it by
using the following command:
ALTER SYSTEM SET db_recovery_file_dest_size = 20G SCOPE=BOTH;
SQL> show parameter recovery_f
NAME TYPE VALUE
------------------------------------ ----------- ---------------
db_recovery_file_dest string
/u01/app/oracle/fast_recovery_area
db_recovery_file_dest_size big integer 15G
remote_recovery_file_dest string
System altered.
SQL>
c. Check and see if the database is in ARCHIVELOG mode. If not, place it in ARCHIVELOG
mode
SQL> ARCHIVE LOG LIST
Database log mode Archive Mode
SQL> exit
…
$
9. Use RMAN to duplicate the ORCLCDB database as the DBTEST database.
Note that for the target and catalog connections, the service names are used, but NOT for
the auxiliary connection. So you must set the environment variables for the dbtest
instance. Refer to the "Course Practice Environment: Security Credentials" document for
the passwords for this step.
$ . oraenv
ORACLE_SID = [orclcdb] ? dbtest
ORACLE_HOME = [/home/oracle] ?
/u01/app/oracle/product/19.3.0/dbhome_1
The Oracle base remains unchanged with value /u01/app/oracle
$ echo $ORACLE_SID
dbtest
Overview
In this practice, you will clone ORCLPDB1 from ORCLCDB into DBTEST by using the RMAN
DUPLICATE command without the use of a fresh auxiliary instance. Duplicate ORCLPDB1 as
DBTESTPDB1 in DBTEST.
Tasks
1. Before duplicating ORCLPDB1, check that the HR.REGIONS table contains rows.
$ . oraenv
ORACLE_SID = [dbtest] ? orclcdb
$ sqlplus hr@ORCLPDB1
Enter password: password
REGION_ID REGION_NAME
---------- -------------------------
1 Europe
2 Americas
3 Asia
4 Middle East and Africa
SQL> EXIT
$
2. In the destination CDB, set the initialization parameter REMOTE_RECOVERY_FILE_DEST to
restore foreign archive logs. Create the directory for the new PDB data files.
$ . oraenv
ORACLE_SID = [orclcdb] ? dbtest
ORACLE_HOME = [/home/oracle] ?
/u01/app/oracle/product/19.3.0/dbhome_1
The Oracle base remains unchanged with value /u01/app/oracle
$ sqlplus / AS SYSDBA
System altered.
$ mkdir /u01/app/oracle/oradata/DBTEST/dbtestpdb1
$
3. Start RMAN and connect to the source ORCLCDB CDB root.
$ rman
RMAN>
5. Duplicate ORCLPDB1 as DBTESTPDB1 in DBTEST.
RMAN> DUPLICATE PLUGGABLE DATABASE ORCLPDB1 AS DBTESTPDB1
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT
('/u01/app/oracle/oradata/ORCLCDB/orclpdb1/',
'/u01/app/oracle/oradata/DBTEST/dbtestpdb1/');
...
RMAN> EXIT
$
Observe that the REMOTE_RECOVERY_FILE_DEST initialization parameter was used to
restore foreign archive log.
Session altered.
REGION_ID REGION_NAME
---------- -------------------------
1 Europe
2 Americas
3 Asia
4 Middle East and Africa
SQL>
7. Drop DBTESTPDB1 by using the
@$HOME/labs/DBMod_Duplicate/drop_pdb1_in_dbtest.sql script.
SQL> CONNECT / AS SYSDBA
Connected.
SQL> @$HOME/labs/DBMod_Duplicate/drop_pdb1_in_dbtest.sql
…
$