Elective-Database Administration – CSIT 7th Semester

Unit-4: Database Backup, Restore, and Recovery

Backup and Recovery Overview:

What is Backup and Recovery?

In general, backup and recovery refers to the various strategies and procedures
involved in protecting your database against data loss and reconstructing the
database after any kind of data loss.

What are Physical Backups and Logical Backups?

A backup is a copy of data from your database that can be used to reconstruct that
data. Backups can be divided into physical backups and logical backups.

Physical backups are backups of the physical files used in storing and recovering
your database, such as datafiles, control files, and archived redo logs. Ultimately,
every physical backup is a copy of files storing database information to some other
location, whether on disk or some offline storage such as tape.

Logical backups contain logical data (for example, tables or stored procedures)
exported from a database with an Oracle export utility and stored in a binary file,
for later re-importing into a database using the corresponding Oracle import utility.

Physical backups are the foundation of any sound backup and recovery strategy.
Logical backups are a useful supplement to physical backups in many
circumstances but are not sufficient protection against data loss without physical
backups. Unless otherwise specified, the term "backup" as used in the backup and
recovery documentation refers to physical backups, and to back up part or all of
your database is to take some kind of physical backup. The focus in the backup and
recovery documentation set will be almost exclusively on physical backups.

Purpose of Backup and Recovery:

As a backup administrator, your principal duty is to devise, implement, and
manage a backup and recovery strategy. In general, the purpose of a backup and
recovery strategy is to protect the database against data loss and reconstruct the
database after data loss. Typically, backup administration tasks include the
following:

By Lec. Pratik Chand, Page 1

 Elective-Database Administration – CSIT 7th Semester

 Planning and testing responses to different kinds of failures

 Configuring the database environment for backup and recovery
 Setting up a backup schedule
 Monitoring the backup and recovery environment
 Troubleshooting backup problems
 Recovering from data loss if the need arises

As a backup administrator, you may also be asked to perform other duties that are
related to backup and recovery:

 Data preservation, which involves creating a database copy for long-term

storage
 Data transfer, which involves moving data from one database or one host to
another

Errors and Failures Requiring Recovery from Backup:

While there are several types of problem that can halt the normal operation of an
Oracle database or affect database I/O operations, only two typically require DBA
intervention and media recovery: media failure, and user errors.

Other failures may require DBA intervention to restart the database (after an
instance failure) or allocate more disk space (after statement failure due to, for
instance, a full datafile) but these situations will not generally cause data loss or
require recovery from backup.

Understanding User Error:

User errors occur when, either due to an error in application logic or a manual
miss-step, data in your database is changed or deleted incorrectly. Data loss due to
user error includes such miss-steps as dropping important tables or deleting or
changing the contents of a table. While user training and careful management of
privileges can prevent most user errors, your backup strategy determines how
gracefully you recover the lost data when user error does cause data loss.

By Lec. Pratik Chand, Page 2

 Elective-Database Administration – CSIT 7th Semester

Understanding Media Failure:

A media failure is the failure of a read or write of a disk file required to run the
database, due to a physical problem with the disk such as a head crash. Any
database file can be vulnerable to a media failure. The appropriate recovery
technique following a media failure depends on the files affected and the types of
backup available.

Oracle Backup and Recovery Solutions:

For performing backup and recovery based on physical backups, we have two
solutions available:

 Recovery Manager (RMAN) Backup

 User-Managed Backup

Recovery Manager (RMAN) Backup: A tool (with command-line client and

Enterprise Manager GUI interfaces) that integrates with sessions running on the
Oracle server to perform a range of backup and recovery activities, as well as
maintaining a repository of historical data about your backups

The traditional user-managed backup and recovery: Where you directly

manage the files that make up your database with a mixture of host operating
system commands and SQL*Plus backup and recovery-related capabilities

Both methods are supported by Oracle Corporation and are fully documented.
Recovery Manager is, however, the preferred solution for database backup and
recovery. It can perform the same types of backup and recovery available through
user-managed methods more easily, provides a common interface for backup tasks
across different host operating systems, and offers a number of backup techniques
not available through user-managed methods.

Most of the backup and recovery documentation set will focus on RMAN-based
backup and recovery. Whether you use RMAN or user-managed methods, you can
supplement your physical backups with logical backups of schema objects made
using data export utilities. Data thus saved can later be imported to re-create this
data after restore and recovery. However, logical backups are for the most part
beyond the scope of the backup and recovery documentation.

By Lec. Pratik Chand, Page 3

 Elective-Database Administration – CSIT 7th Semester

Database backup, restoration and recovery:

Introduction to Backup

A backup is a copy of data. This copy can include important parts of the database,
such as the control file and datafiles. A backup is a safeguard against unexpected
data loss and application errors. If you lose the original data, then you can
reconstruct it by using a backup.

Backups are divided into physical backups and logical backups. Physical
backups, which are the primary concern in a backup and recovery strategy, are
copies of physical database files. You can make physical backups with either the
Recovery Manager (RMAN) utility or operating system utilities. In contrast,
logical backups contain logical data (for example, tables and stored procedures)
extracted with an Oracle utility and stored in a binary file. You can use logical
backups to supplement physical backups.

Types of Backups:

Consistent Backups:
When the data files in database are taken backup by completely shutdown of
database is called consistent backup this is also called “Cold Backup”. In another
word backup is taken when the oracle database is shutdown is called consistent
backup, this is also called static backup or offline backup. In this backup no data
can add and removed from database. For the large company which can’t shutdown
the database even a while can’t implement the consistent backup technique.

A consistent backup is one in which the files being backed up contain all changes
up to the same system change number (SCN). This means that the files in the
backup contain all the data taken from a same point in time.

A consistent backup of a database or part of a database is a backup in which all

read/write datafiles and control files are checkpointed with the same SCN.

The only way to make a consistent whole database backup is to shut down the
database with the NORMAL, IMMEDIATE, or TRANSACTIONAL options and
make the backup while the database is closed. If a database is not shut down

By Lec. Pratik Chand, Page 4

 Elective-Database Administration – CSIT 7th Semester

cleanly, for example, an instance fails or you issue

a SHUTDOWN ABORT statement, then the database's datafiles are always
inconsistent unless the database is a read-only database.

Oracle makes the control files and datafiles consistent to the same SCN during a
database checkpoint. The only tablespaces in a consistent backup that are allowed
to have older SCNs are read-only and offline normal tablespaces, which are still
consistent with the other datafiles in the backup because no changes have been
made to them.

Inconsistent Backups:
An inconsistent backup is a backup of one or more database files that can take
while the database is running or in archive log mode this is also called “Hot
Backup”. It is also take the backup after the database has shut down abnormally.
This is also called online backup. This backup technique is used for large database
which should run continuously without shutdown.

Note: Archive and No-archive log mode:

Redo log files: These files are created during data base creation and a database
has minimum two redo log files. Redo log files holds all the history of change made
in your database.

No-archive log mode: by default oracle database is in no-archive log mode. When
your database is in no-archive log mode it starts overriding the redo log files when
they are fill instead of archiving them. It permanently lose the previous data this
can become complicate during the data recovery of old data, that is why always
recommend to run your database in archive log mode.

Archive log mode: in archive log mode database make copies of all the online
redo log files after they fill and these copies are called archive redo logs.

In this backup the files being backed up do not contain all the changes made at all
the SCNs. In other words, some changes are missing. This means that the files in
the backup contain data taken from different points in time. This can occur because
the datafiles are being modified as backups are being taken. Oracle recovery makes
inconsistent backups consistent by reading all archived and online redo logs,

By Lec. Pratik Chand, Page 5

 Elective-Database Administration – CSIT 7th Semester

starting with the earliest SCN in any of the datafile headers, and applying the
changes from the logs back into the datafiles.

If the database must be up and running 24 hours a day, seven days a week, then
you have no choice but to perform inconsistent backups of the whole database. A
backup of online datafiles is called an online backup. This requires that you run
your database in ARCHIVELOG mode.

If you run the database in ARCHIVELOG mode, then you do not have to back up
the whole database at one time. For example, if your database contains seven
tablespaces, and if you back up the control file as well as a different tablespace
each night, then in a week you will back up all tablespaces in the database as well
as the control file. You can consider this staggered backup as a whole database
backup. However, if such a staggered backup must be restored, then you need to
recover using all archived redo logs that were created since the earliest backup was
taken.

Whole Database Backups:

A whole database backup is a backup of every datafile in the database, plus the
control file. Whole database backups are the most common type of backup.

Whole database backups can be taken in

either ARCHIVELOG or NOARCHIVELOG mode. Before performing whole
database backups, however, be aware of the implications of backing up
in ARCHIVELOG and NOARCHIVELOG modes.

Figure bellow illustrates the valid configuration options given the type of backup
that is performed.

By Lec. Pratik Chand, Page 6

 Elective-Database Administration – CSIT 7th Semester

Fig: Whole database backup options

A whole database backup is either a consistent backup or an inconsistent backup.

Whether a backup is consistent determines you need to apply redo logs after
restoring the backup.

Tablespace Backups:
A tablespace backup is a backup of the datafiles that constitute the tablespace. For
example, if tablespace users contains datafiles 2, 3, and 4, then a backup of
tablespace users backs up these three datafiles.

Tablespace backups, whether online or offline, are valid only if the database is
operating in ARCHIVELOG mode. The reason is that redo is required to make the
restored tablespace consistent with the other tablespaces in the database.

Datafile Backups:
A datafile backup is a backup of a single datafile. Datafile backups, which are not
as common as tablespace backups, are valid in ARCHIVELOG databases. The
only time a datafile backup is valid for a database in NOARCHIVELOG mode is
if:

 Every datafile in a tablespace is backed up. You cannot restore the database
unless all datafiles are backed up.
 The datafiles are read only or offline-normal.

By Lec. Pratik Chand, Page 7

 Elective-Database Administration – CSIT 7th Semester

Control File Backups:

Backing up the control file is a crucial aspect of backup and recovery. Without a
control file, you cannot mount or open the database.

You can instruct RMAN to automatically backup the control file whenever you run
backup jobs. The command is CONFIGURE CONTROLFILE AUTOBACKUP.
Because the autobackup uses a default filename, RMAN can restore this backup
even if the RMAN repository is unavailable. Hence, this feature is extremely
useful in a disaster recovery scenario.

You can make manual backups of the control file by using the following methods:

 The RMAN BACKUP CURRENT CONTROLFILE command makes a

binary backup of the control file, as either a backup set or an image copy.
 The SQL statement ALTER DATABASE BACKUP CONTROLFILE
makes a binary backup of the control file.
 The SQL statement ALTER DATABASE BACKUP CONTROLFILE TO
TRACE exports the control file contents to a SQL script file. You can use
the script to create a new control file. Trace file backups have one major
disadvantage: they contain no records of archived redo logs, and RMAN
backups and copies. For this reason, binary backups are preferable.

Archived Redo Log Backups:

Archived redo logs are essential for recovering an inconsistent backup. The only
way to recover an inconsistent backup without archived logs is to use RMAN
incremental backups. To be able to recover a backup through the most recent log,
every log generated between these two points must be available. In other words,
you cannot recover from log 100 to log 200 if log 173 is missing. If log 173 is
missing, then you must halt recovery at log 172 and open the database with
the RESETLOGS option.

Because archived redo logs are essential to recovery, you should back them up
regularly. If possible, then back them up regularly to tape.

You can make backups of archived logs by using the following methods:

 The RMAN BACKUP ARCHIVELOG command

By Lec. Pratik Chand, Page 8

 Elective-Database Administration – CSIT 7th Semester

 The RMAN BACKUP ... PLUS ARCHIVELOG command

 An operating system utility

Restoration and Recovery:

Let’s assume that we have already taken a backup of our database in Oracle, and
later, due to some reason, we lost our original data.

In this scenario, even if we have a backup, it won’t do any good to us until we

know how to recover and restore the backup. So, let’s understand how we can
recover and restore databases in Oracle.

Before we dive into restoring and recovering databases, let’s first understand under
what circumstances we might need to recover a database, and what are the
different ways in which a database can fail?

Hardware failures/firmware issues:

 User errors
 Bad code
 Loss of a file, control file, redo log, or datafile
 Corrupt blocks
 Upgrade issues
 Bad changes
 Disasters

Oracle provides various options for recovery, such as rolling back a query or
returning to a point before a change.

Reconstructing the contents of all or part of a database from a backup typically

involves two phases:

 Retrieving a copy of the datafile from a backup

 Reapplying changes to the file since the backup from the archived and
online redo logs

These phases are used to bring the database to a desired SCN (System Chain
Number) since the backup (usually, the present).

By Lec. Pratik Chand, Page 9

 Elective-Database Administration – CSIT 7th Semester

To restore a datafile or control file from backup is to retrieve the file onto disk
from a backup location on tape, disk or other media, and make it available to the
database server.

To recover a datafile (also called performing recovery on a datafile), is to take a

restored copy of the datafile and apply to it changes recorded in the database's redo
logs. To recover a whole database is to perform recovery on each of its datafiles.

Figure bellow illustrates the basic principle of backing up, restoring, and
recovering a database.

Fig: Process of Restoration and Recovery of Database

In this example a full backup of a database (copies of its datafiles and control file)
is taken at SCN 100. Redo logs generated during the operation of the database
capture all changes that occur between SCN 100 and SCN 500. Along the way,
some logs fill and are archived. At SCN 500, the datafiles of the database are lost
due to a media failure. The database is then returned to its transaction-consistent
state at SCN 500, by restoring the datafiles from the backup taken at SCN 100,
then applying the transactions captured in the archived and online redo logs and
undoing the uncomitted transactions.

By Lec. Pratik Chand, Page 10

 Elective-Database Administration – CSIT 7th Semester

Forms of Data Recovery:

Datafile Media Recovery:

Datafile media recovery (often simply called media recovery) is the most basic
form of user-initiated data recovery. It can be used to recover from a lost or
damaged current datafile, SPFILE or control file. It can also recover changes that
were recorded in the redo logs but not in the datafiles for a tablespace that went
offline without the OFFLINE NORMAL option. Datafile media recovery can be
performed whether you use Recovery Manager or user-managed backup and
recovery.

Several situations force you to perform media recovery:

 You restore a backup of a datafile.

 You restore a backup control file (even if all datafiles are current).
 A datafile is taken offline (either by you or automatically by the database)
without the OFFLINE NORMAL option.

For a datafile to be available for media recovery, one of two things must be true:

 The database that the datafile belongs to must not be open; or

 The specific datafile needing recovery must be offline, if the database is
open.

A datafile that needs media recovery cannot be brought online until media
recovery has been completed. A database cannot be opened if any of the online
datafiles needs media recovery.

Complete, Incomplete and Point-In-Time Recovery

Complete recovery is recovering a database to the most recent point in time,
without the loss of any committed transactions. Generally, the term "recovery"
refers to complete recovery.

Occasionally, however, you need to return a database to its state at a past point in
time. For example, to undo the effect of a user error, such as dropping or deleting
the contents of a table, you may want to return the database to its contents before
the delete occurred.

By Lec. Pratik Chand, Page 11

 Elective-Database Administration – CSIT 7th Semester

In incomplete recovery, also known as point-in-time recovery, the goal is to restore

the database to its state at some previous target SCN or time. Point-in-time
recovery is one possible response to a data loss caused by, for instance, a user error
or logical corruption that goes unnoticed for some time.

Point-in-time recovery is also your only option if you have to perform a recovery
and discover that you are missing an archived log covering time between the
backup you are restoring from and the target SCN for the recovery. Without the
missing log, you have no record of the updates to your datafiles during that period.
Your only choice is to recover the database from the point in time of the restored
backup, as far as the unbroken series of archived logs permits, then perform an
OPEN RESETLOGS and abandon all changes in or after the missing log. (If you
discover that you have lost archived logs and your database is still up, you should
do a full backup immediately.)

Automatic Recovery after Instance Failure: Crash Recovery

The crash recovery process is a special form of recovery, which happens the first
time an Oracle database instance is started after a crash (or SHUTDOWN
ABORT). In crash recovery, the goal is to bring the datafiles to a transaction-
consistent state, preserving all committed changes up to the point when the
instance failed.

Like crash recovery, datafile media recovery is intended to restore database

integrity. However, there are a number of important differences between the two:

 Media recovery must be explicitly invoked by a user. The database will not
run media recovery on its own.
 Media recovery applies needed changes to datafiles that have been restored
from backup, not to online datafiles left over after a crash.
 Media recovery must use archived logs as well as the online logs, to find
changes reaching back to the time of the datafile backup.

Unlike the forms of recovery performed manually after a data loss, crash recovery
uses only the online redo log files and current online datafiles, as left on disk after
the instance failure. Archived logs are never used during crash recovery, and
datafiles are never restored from backup.

By Lec. Pratik Chand, Page 12

 Elective-Database Administration – CSIT 7th Semester

Database Instance and Mounting:

In Oracle, a database is a collection of datafiles, online redo logs, and control files.
A database persists (remain) across shutdowns. When you terminate Oracle, the
data persists in the database, in the files on the server.

Before you can access the database's contents, you must start Oracle. The
Oracle instance is the collection of memory and processes running which give you
access to the database. If the database server abnormally terminates, the instance
will die. But the data still survives in the database. After the server is up and
running again, one needs to start the instance before they can access the data.

When you start an instance, there are three stages the instance goes through:

1. NOMOUNT – In this mode, only the parameter file is accessed. Typically, this
mode is only used to modify the parameter file's contents or to create the database.

2. MOUNT – In mount mode, the control files are accessed for the first time.
Certain maintenance operations require the database to be in MOUNT mode.
Mount mode is when the instance acquires memory and spawns the various
background processes required for the Oracle instance.

3. OPEN – This mode is the first mode to touch the datafiles and online redo logs.
Once Oracle has contacted these files, Oracle lets users connect to the instance so
as to interact with the data.

When you issue a normal STARTUP command, the instance proceeds from
NOMOUNT to MOUNT to OPEN. You can STARTUP MOUNT the instance, in
which case the instance goes from NOMOUNT to MOUNT mode, but does not get
to OPEN mode.

Inconsistence Backup using RMAN:

Login database with sysdba user or user with all the privilege to do the required
operation.

After successful login, go to RMAN for backup and recovery operation. Here we
will perform inconsistence backup and recovery using RMAN prompt.

By Lec. Pratik Chand, Page 13

 Elective-Database Administration – CSIT 7th Semester

To perform Inconsistence Backup using RMAN database should be in archive

mode.

First check archive log by following command.

archive log list;

If archive log is disable then first enable it. Follow the following procedure.

Step 1: Check archive mode

SQL> archive log list;

Database log mode No Archive Mode

Automatic archival Disabled

Archive destination C:\Oracle_19c_Base\Oracle_19c_Home\RDBMS

Oldest online log sequence 17

Current log sequence 19

Step 2: Shut down database

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

Step 3: Start database in mount mode

SQL> startup mount;

ORACLE instance started.

Total System Global Area 2550133384 bytes

By Lec. Pratik Chand, Page 14

 Elective-Database Administration – CSIT 7th Semester

Fixed Size 9269896 bytes

Variable Size 603979776 bytes

Database Buffers 1929379840 bytes

Redo Buffers 7503872 bytes

Database mounted.

Step 4: Alter database in archive mode

SQL> alter database archivelog;

Database altered.

Step 5: Alter database in open mode

SQL> alter database open;

Database altered.

Step 6: Again check archive mode

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination C:\Oracle_19c_Base\Oracle_19c_Home\RDBMS

Oldest online log sequence 17

Next log sequence to archive 19

Current log sequence 19

By Lec. Pratik Chand, Page 15

 Elective-Database Administration – CSIT 7th Semester

Note: you can disable archive mode

Step 1: shutdown database by following command

shutdown immediate;

step 2: Start database in mount mode by following command

startup mount;

Step 3: Alter database in noarchive mode by following command

alter database noarchivelog;

Now backup the database or tablespace:

// Show some database details

SQL> select tablespace_name from dba_tablespaces;

TABLESPACE_NAME

------------------------------

SYSTEM

SYSAUX

UNDOTBS1

TEMP

USERS

SQL> show con_name;

CON_NAME

------------------------------

CDB$ROOT

By Lec. Pratik Chand, Page 16

 Elective-Database Administration – CSIT 7th Semester

SQL> select file_name from dba_data_files;

FILE_NAME

--------------------------------------------------------------------------------

C:\ORACLE_19C_BASE\ORADATA\TESTDB\SYSTEM01.DBF

C:\ORACLE_19C_BASE\ORADATA\TESTDB\SYSAUX01.DBF

C:\ORACLE_19C_BASE\ORADATA\TESTDB\UNDOTBS01.DBF

C:\ORACLE_19C_BASE\ORADATA\TESTDB\USERS01.DBF

// Create a tablespace with datafiles

SQL> create tablespace tbs2 datafile 'E:\db_backup\tbs2_01.dbf' size 100k;

Tablespace created.

SQL> alter tablespace tbs2 add datafile 'E:\db_backup\tbs2_02.dbf' size

100k;

Tablespace altered.

SQL> alter tablespace tbs2 add datafile 'E:\db_backup\tbs2_03.dbf' size

100k;

Tablespace altered.

SQL> select file_id, file_name, tablespace_name from dba_data_files where

tablespace_name = 'TBS2';

FILE_ID

----------

FILE_NAME

--------------------------------------------------------------------------------

By Lec. Pratik Chand, Page 17

 Elective-Database Administration – CSIT 7th Semester

TABLESPACE_NAME

------------------------------

16

E:\DB_BACKUP\TBS2_01.DBF

TBS2

17

E:\DB_BACKUP\TBS2_02.DBF

TBS2

FILE_ID

----------

FILE_NAME

--------------------------------------------------------------------------------

TABLESPACE_NAME

------------------------------

18

E:\DB_BACKUP\TBS2_03.DBF

TBS2

// Now formatting the table in proper way

SQL> column file_name for a40

SQL> column tablespace_name for a20

SQL> /

By Lec. Pratik Chand, Page 18

 Elective-Database Administration – CSIT 7th Semester

FILE_ID FILE_NAME TABLESPACE_NAME

---------- ---------------------------------------- --------------------

16 E:\DB_BACKUP\TBS2_01.DBF TBS2

17 E:\DB_BACKUP\TBS2_02.DBF TBS2

18 E:\DB_BACKUP\TBS2_03.DBF TBS2

// Now go to RMAN prompt

SQL> host rman

Recovery Manager: Release 19.0.0.0.0 - Production on Sat Nov 5 18:50:28 2022

Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

// Connect to the RMAN target

RMAN> connect target/

connected to target database: TESTDB (DBID=2897623644)

// Now look the available schemas or files in database which we want to backup

RMAN> report schema;

using target database control file instead of recovery catalog

Report of database schema for database with db_unique_name TESTDB

List of Permanent Datafiles

===========================

By Lec. Pratik Chand, Page 19

 Elective-Database Administration – CSIT 7th Semester

File Size(MB) Tablespace RB segs Datafile Name

---- -------- -------------------- ------- ------------------------

1 910 SYSTEM YES

C:\ORACLE_19C_BASE\ORADATA\TESTDB\SYSTEM01.DBF

3 780 SYSAUX NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\SYSAUX01.DBF

4 65 UNDOTBS1 YES
C:\ORACLE_19C_BASE\ORADATA\TESTDB\UNDOTBS01.DBF

5 260 PDB$SEED:SYSTEM NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\PDBSEED\SYSTEM01.DBF

6 280 PDB$SEED:SYSAUX NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\PDBSEED\SYSAUX01.DBF

7 5 USERS NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\USERS01.DBF

8 100 PDB$SEED:UNDOTBS1 NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\PDBSEED\UNDOTBS01.DBF

9 270 TESTPDB:SYSTEM NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\TESTPDB\SYSTEM01.DBF

10 320 TESTPDB:SYSAUX NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\TESTPDB\SYSAUX01.DBF

11 100 TESTPDB:UNDOTBS1 NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\TESTPDB\UNDOTBS01.DBF

12 5 TESTPDB:USERS NO
C:\ORACLE_19C_BASE\ORADATA\TESTDB\TESTPDB\USERS01.DBF

13 0 TBS1 NO E:\DB_BACKUP\TBS1_01.DBF

14 0 TBS1 NO E:\DB_BACKUP\TBS1_02.DBF

15 0 TBS1 NO E:\DB_BACKUP\TBS1_03.DBF SISE 100K

By Lec. Pratik Chand, Page 20
 Elective-Database Administration – CSIT 7th Semester

16 0 TBS2 NO E:\DB_BACKUP\TBS2_01.DBF

17 0 TBS2 NO E:\DB_BACKUP\TBS2_02.DBF

18 0 TBS2 NO E:\DB_BACKUP\TBS2_03.DBF

List of Temporary Files

=======================

File Size(MB) Tablespace Maxsize(MB) Tempfile Name

---- -------- -------------------- ----------- --------------------

1 131 TEMP 32767

C:\ORACLE_19C_BASE\ORADATA\TESTDB\TEMP01.DBF

2 36 PDB$SEED:TEMP 32767
C:\ORACLE_19C_BASE\ORADATA\TESTDB\PDBSEED\TEMP012022-09-
01_22-33-32-428-PM.DBF

3 128 TESTPDB:TEMP 32767

C:\ORACLE_19C_BASE\ORADATA\TESTDB\TESTPDB\TEMP01.DBF

// these all are the file in database which we can backup

// Now take backup of tablespace TBS2 recently we created.

// Before to do that check the backups available or not

RMAN> list backup;

RMAN> backup tablespace tbs2;

Starting backup at 05-NOV-22

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=267 device type=DISK

By Lec. Pratik Chand, Page 21

 Elective-Database Administration – CSIT 7th Semester

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00016 name=E:\DB_BACKUP\TBS2_01.DBF

input datafile file number=00017 name=E:\DB_BACKUP\TBS2_02.DBF

input datafile file number=00018 name=E:\DB_BACKUP\TBS2_03.DBF

channel ORA_DISK_1: starting piece 1 at 05-NOV-22

channel ORA_DISK_1: finished piece 1 at 05-NOV-22

piece
handle=E:\DB_BACKUP\TESTDB\BACKUPSET\2022_11_05\O1_MF_NNNDF
_TAG20221105T190326_KPDRO2JM_.BKP tag=TAG20221105T190326
comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 05-NOV-22

Starting Control File and SPFILE Autobackup at 05-NOV-22

piece
handle=E:\DB_BACKUP\TESTDB\AUTOBACKUP\2022_11_05\O1_MF_S_111
9985407_KPDRO42T_.BKP comment=NONE

Finished Control File and SPFILE Autobackup at 05-NOV-22

// Run the list backup command

RMAN> list backup;

// And go to the backup location you can see the backedup data.

By Lec. Pratik Chand, Page 22

 Elective-Database Administration – CSIT 7th Semester

Note: We can change the backup directory as following

First exit from the database by executing command

exit;
Then connect as sysdba by command

conn /as sysdba;

SQL> show parameter db_recover

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_recovery_file_dest string

db_recovery_file_dest_size big integer 0

// here the db_recovery_file_dest_size is zero, we have to allocate space here

// if you already allocated the space for backup no need to allocate again, but
space must have to be allocated.

SQL> alter system set db_recovery_file_dest_size = 1G scope = both;

System altered.

// here we allocated the size as 1GB

SQL> show parameter db_recover

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_recovery_file_dest string

db_recovery_file_dest_size big integer 1G

By Lec. Pratik Chand, Page 23

 Elective-Database Administration – CSIT 7th Semester

// Now set the data backup destination location

SQL> alter system set db_recovery_file_dest = 'E:\db_backup';

System altered.

// then go back to RMAN prompt

SQL> host rman

Recovery Manager: Release 19.0.0.0.0 - Production on Mon Oct 31 21:56:37 2022

Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

RMAN> connect target /

connected to target database: TESTDB (DBID=2897623644)

// Run the backup command

// Now we can see the backup file in the location E:\DB_BACKUP\

// you can backup control file by command

// Lets backup some other files

RMAN> backup current controlfile;

// we can take backup of particular datafile with its id.

RMAN> backup datafile 16;

// we can take image copy of datafile with its id

RMAN> backup as copy datafile 17;

// we can see the list of backup and copy as

RMAN> list backup of datafile 16;

By Lec. Pratik Chand, Page 24
 Elective-Database Administration – CSIT 7th Semester

RMAN> list copy of datafile 17;

Now Recover the data from backup

Let’s create a scenario, shutdown the database and corrupt the datafiles and try to
restart the database.

First shut down the database

RMAN> exit

Recovery Manager complete.

SQL> conn/ as sysdba

Connected.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

// now go to backup file and corrupt the data by editing the file

// try to restart the database

SQL> startup;

ORACLE instance started.

Total System Global Area 2550133384 bytes

Fixed Size 9269896 bytes

Variable Size 603979776 bytes

Database Buffers 1929379840 bytes

By Lec. Pratik Chand, Page 25

 Elective-Database Administration – CSIT 7th Semester

Redo Buffers 7503872 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 16 - see DBWR trace file

ORA-01110: data file 16: 'E:\DB_BACKUP\TBS2_01.DBF'

// this shows that datafile 16 is not found so we have to recover it first.

// list the files which we need to recover

SQL> select * from v$recover_file;

// Now go to RMAN prompt

SQL> host rman

Recovery Manager: Release 19.0.0.0.0 - Production on Sat Nov 5 20:22:39 2022

Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

RMAN> connect target/

connected to target database: TESTDB (DBID=2897623644, not open)

// check backup of datafile 16 is available or not?

RMAN> list backup of datafile 16;

using target database control file instead of recovery catalog

List of Backup Sets

===================

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ---------------

14 Full 152.00K DISK 00:00:00 05-NOV-22

By Lec. Pratik Chand, Page 26
 Elective-Database Administration – CSIT 7th Semester

BP Key: 14 Status: AVAILABLE Compressed: NO Tag:

TAG20221105T190326

Piece Name:
E:\DB_BACKUP\TESTDB\BACKUPSET\2022_11_05\O1_MF_NNNDF_TAG2
0221105T190326_KPDRO2JM_.BKP

List of Datafiles in backup set 14

File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name

---- -- ---- ---------- --------- ----------- ------ ----

16 Full 3732031 05-NOV-22 NO

E:\DB_BACKUP\TBS2_01.DBF

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ---------------

16 Full 72.00K DISK 00:00:01 05-NOV-22

BP Key: 16 Status: AVAILABLE Compressed: NO Tag:

TAG20221105T191604

Piece Name:
E:\DB_BACKUP\TESTDB\BACKUPSET\2022_11_05\O1_MF_NNNDF_TAG2
0221105T191604_KPDSDRW8_.BKP

List of Datafiles in backup set 16

File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name

---- -- ---- ---------- --------- ----------- ------ ----

16 Full 3733771 05-NOV-22 NO

E:\DB_BACKUP\TBS2_01.DBF

By Lec. Pratik Chand, Page 27

 Elective-Database Administration – CSIT 7th Semester

// this shows backup is available. Now restore it.

RMAN> restore datafile 16;

// then recover it

RMAN> recover datafile 2;

// now try to open the database again

RMAN> alter database open;

RMAN-00571:
===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS

===============

RMAN-00571:
===========================================================

RMAN-03002: failure of sql statement command at 11/05/2022 20:25:19

ORA-01157: cannot identify/lock data file 17 - see DBWR trace file

ORA-01110: data file 17: 'E:\DB_BACKUP\TBS2_02.DBF'

// this shows data file 17 is not found. Now Recover it.

// check for backup

RMAN> list backup datafile 17;

RMAN-00571:
===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS

===============

By Lec. Pratik Chand, Page 28

 Elective-Database Administration – CSIT 7th Semester

RMAN-00571:
===========================================================

RMAN-00558: error encountered while parsing input commands

RMAN-01009: syntax error: found "datafile": expecting one of: "backed, by,
completed, controlfile, device, for, guid, like, of, recoverable, summary, tag, ;"

RMAN-01007: at line 1 column 13 file: standard input

// here backup not found

// now check for image copy

RMAN> list copy of datafile 17;

List of Datafile Copies

=======================

Key File S Completion Time Ckp SCN Ckp Time Sparse

------- ---- - --------------- ---------- --------------- ------

5 17 A 05-NOV-22 3733833 05-NOV-22 NO

Name:
E:\DB_BACKUP\TESTDB\DATAFILE\O1_MF_TBS2_KPDSHJW3_.DBF

Tag: TAG20221105T191732

// image copy of datafile 17 is available.

// now first switch that image copy and recover it

RMAN> switch datafile 17 to copy;

datafile 17 switched to datafile copy

"E:\DB_BACKUP\TESTDB\DATAFILE\O1_MF_TBS2_KPDSHJW3_.DBF"

By Lec. Pratik Chand, Page 29

 Elective-Database Administration – CSIT 7th Semester

RMAN> recover datafile 17;

// now try to open database

RMAN> alter database open;

RMAN-00571:
===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS

===============

RMAN-00571:
===========================================================

RMAN-03002: failure of sql statement command at 11/05/2022 20:29:11

ORA-01157: cannot identify/lock data file 18 - see DBWR trace file

ORA-01110: data file 18: 'E:\DB_BACKUP\TBS2_03.DBF'

// data file 18 is not found. We need to recover it

// Check for backup

RMAN> list backup datafile 18;

RMAN-00571:
===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS

===============

RMAN-00571:
===========================================================

RMAN-00558: error encountered while parsing input commands

By Lec. Pratik Chand, Page 30

 Elective-Database Administration – CSIT 7th Semester

RMAN-01009: syntax error: found "datafile": expecting one of: "backed, by,
completed, controlfile, device, for, guid, like, of, recoverable, summary, tag, ;"

RMAN-01007: at line 1 column 13 file: standard input

// no backup available

// check for image copy

RMAN> list copy of datafile 18;

specification does not match any datafile copy in the repository

// image copy also not available

// in this case we have to re-create datafile 18 as initially we created.

// to do so, exit from RMAN and create datafile

RMAN> exit

Recovery Manager complete.

// we have to create datafile as same name, location and size as initially create.

// if we don’t know the size of data file we can check by command

SQL> select file#, create_bytes from v$datafile;

// this will show the file_id and size of all datafiles

SQL> alter database create datafile 'E:\db_backup\tbs2_03.dbf' as

'E:\db_backup\tbs2_03.dbf' size 150k;

Database altered.

SQL> recover datafile 18;

Media recovery complete.

By Lec. Pratik Chand, Page 31

 Elective-Database Administration – CSIT 7th Semester

// now try to open the database

SQL> alter database open;

Database altered.

// here database opened successfully. Now you can run any query on database.

Backup and Recovery Strategy:

To decide on backup strategies, start with your data recovery requirements and
your data recovery strategy. Each type of data recovery will require that you take
certain types of backup. Failures can run the gamut from user error, datafile block
corruption and media failure to situations like the complete loss of a data center.
How quickly you can resume normal operation of your database is a function of
what kinds of restore and recovery techniques you include in your planning. Each
restore and recovery technique will impose requirements on your backup strategy,
including which features of the Oracle database you use to take, store and manage
your backups.

First of all you have to find the need of data backup and recovery, with these needs
in mind, decide how you can take advantage of features related to backup and
recovery, and look at how each feature meets some requirement of your backup
strategy.

Once you decide which features to use in your recovery strategy, you can plan your
backup strategy.

Planning Data Recovery Strategy

Your data recovery strategy should include responses to any number of database
failure scenarios. The key to an effective, efficient strategy is envisioning failure
modes, matching Oracle database recovery techniques and tools to the failure
modes in which they are useful, and then making sure you incorporate the
necessary backup types to support those recovery techniques.

By Lec. Pratik Chand, Page 32

 Elective-Database Administration – CSIT 7th Semester

We have to make plan to handle the following scenarios:

 Planning Responses to User Error: Point-in-Time Recovery and Flashback

Features
 Planning a Response to Media Failure: Restore and Media Recovery
 Planning a Response to Datafile Block Corruption: Block Media Recovery

Planning Backup Strategy

Your plans for data recovery strategies are the basis of your plans for backup
strategy. After making recovery plan you have to decide when to perform database
backups, which parts of a database you should back up, what tools Oracle provides
for those backups, and how to configure your database to improve its robustness
and make backup and recovery easier. Of course, the specifics of your strategy
must balance the needs of your restore strategy with questions of cost, resources,
personnel and other factors.

Planning of backup strategy should consider the following things:

 Protecting your redundancy set (The set of files needed to recover an Oracle
database from the failure of any of its files a datafile, control file, or online
redo log is called the redundancy set.)
 Deciding whether to use a Flash Recovery Area
 Deciding Between Archivelog and Nonarchivelog Mode
 Deciding whether to use Oracle Flashback Feature and Restore Point
 Choosing a Backup Retention Policy
 Archiving Older Backups
 Determining Backup Frequency
 Performing Backup before and after you make structural change
 Scheduling Backups for Frequently-Updated Tablespaces
 Backing up after NOLOGGING operations
 Exporting Data for added protection and flexibility
 Preventing the Backup of Online Redo Logs
 Keeping records of the Hardware and Software Configuration of the Server

By Lec. Pratik Chand, Page 33

 Elective-Database Administration – CSIT 7th Semester

Validating Your Data Recovery Strategy

Practice backup and recovery techniques in a test environment before and after you
move to a production system. In this way, you can measure the thoroughness of
your strategies and minimize problems before they occur in a real situation.
Performing test recoveries regularly ensures that your archiving, backup, and
recovery procedures work. It also helps you stay familiar with recovery
procedures, so that you are less likely to make a mistake in a crisis.

If you use RMAN, then one option is to run the DUPLICATE command to create
a test database using backups of your production database. If you perform user-
managed backup and recovery, then you can either create a new database, a
standby database, or a copy of an existing database to test your backups.

Using BACKUP... VALIDATE

Using the RMAN BACKUP... VALIDATE command causes RMAN to read all
of the specified database files that would be input for a specific backup task,
without actually producing any backups as output. For example, BACKUP
DATABASE VALIDATE causes RMAN to read all files that would be backed up
in backing up the entire database and ensure that they are intact and not corrupted.
All of the data blocks in the input files are validated, exactly as they are when a
real backup takes place. This process can provide a useful integrity check for your
database.

Validating RMAN Backups: VALIDATE and RESTORE VALIDATE

The RMAN VALIDATE and RESTORE VALIDATE commands should be part
of ongoing testing of your recovery plan. VALIDATE causes RMAN to read
specified backups on disk or tape and report whether they are intact and usable in a
restore operation. RESTORE... VALIDATE causes RMAN to check whether
the set of available backups is sufficient to restore the specified database objects.
For example, RESTORE TABLESPACE TBS_1 VALIDATE selects backups
sufficient to restore the named tablespace, just as RMAN does in a real restore
operation, and reads the backups to ensure that they are present and not corrupted.

By Lec. Pratik Chand, Page 34

 Elective-Database Administration – CSIT 7th Semester

Testing Your Database Restore and Recovery Procedures

You can also test your backups by performing a complete test of your restore and
recovery strategy onto different hardware. Ideally, use a hardware and software
configuration for the test that is as similar as possible to the environment available
to you in a real disaster recovery scenario.

Data Dump:
Data dump file is the data file which contains the schema objects of database. This
is used to migrate the data or whole database from one device to another device.
To dump the data we have to create a dumping directory and its object in database.

Data dumping procedure

Step 1: Create a dumping directory in your system. Eg: E:\dumpdata\

Step 2: go to SQL Plus and login with username/password

Step 3: Create a object of dumping directory

SQL> create directory dmp as 'E:\dumpdata';

Step 4: Go to command prompt and run the following command

C:\>expdp system/password directory=dmp dumpfile=dmpfile.dmp

schema=schemaname;

Now your schema is dumped or exported in to dumpdata directory.

Now you can import this dump file in different system as

Go to command prompt and run the command

C:\>impdp system/password directory=dmp dumpfile=dmpfile.dmp;

Like this you can export and import the specific table or other data form oracle
database. To export table just mention table name.

C:\>expdp system/password directory=dmp dumpfile=dmpfile.dmp

table=tablename;

By Lec. Pratik Chand, Page 35

 Elective-Database Administration – CSIT 7th Semester

User-Managed Restore and Recovery

If you do not use RMAN, then you can restore backups with operating system
utilities and then run the SQL*Plus RECOVER command to recover the database. You
should follow these basic steps:

1. After identifying which files are damaged, place the database in the
appropriate state for restore and recovery. For example, if some but not all
datafiles are damaged, then take the affected tablespaces offline while the
database is open.
2. Restore the files with an operating system utility. If you do not have a
backup, it is sometimes possible to perform recovery if you have the
necessary redo logs dating from the time when the datafiles were first
created and the control file contains the name of the damaged file.
If you cannot restore a datafile to its original location, then relocate the
restored datafile and change the location in the control file.
3. Restore any necessary archived redo log files.
4. Use the SQL*Plus RECOVER command to recover the datafile backups.

High Availability:
Availability is the degree to which an application and database service is available.
Availability is measured by the perception of an application's user. Users
experience frustration when their data is unavailable or the computing system is
not performing as expected, and they do not understand or care to differentiate
between the complex components of an overall solution. Performance failures due
to higher than expected usage create the same disruption as the failure of critical
components in the architecture. If a user cannot access the application or database
service, it is said to be unavailable. Generally, the term downtime is used to refer
to periods when a system is unavailable.

Users who want their systems to be always ready to serve them need high
availability. A system that is highly available is designed to provide uninterrupted
computing services during essential time periods, during most hours of the day,
and most days of the week throughout the year; this measurement is often shown
as 24x365. Such systems may also need a high availability solution for planned
maintenance operations such as upgrading a system's hardware or software.

By Lec. Pratik Chand, Page 36

 Elective-Database Administration – CSIT 7th Semester

Characteristics of Highly availability Solution:

Reliability: Reliable hardware is one component of a high availability solution.

Reliable software including the database, web servers, and applications is just as
critical to implementing a highly available solution.

A related characteristic is resilience. For example, low-cost commodity hardware,

combined with software such as Oracle Real Application Clusters (Oracle RAC),
can be used to implement a very reliable system. The resilience of an Oracle RAC
database allows processing to continue even though individual servers may fail.
For example, the Oracle RAC database allows processing to continue even though
individual servers may fail.

Recoverability: Even though there may be many ways to recover from a failure, it
is important to determine what types of failures may occur in your high availability
1-1 environment and how to recover from those failures quickly in order to meet
your business requirements.

For example, if a critical table is accidentally deleted from the database, what
action should you take to recover it? Does your architecture provide the ability to
recover in the time specified in a service-level agreement (SLA)?

Timely error detection: If a component in your architecture fails, then fast

detection is essential to recover from the unexpected failure. Although you may be
able to recover quickly from an outage, if it takes an additional 90 minutes to
discover the problem, then you may not meet your SLA. Monitoring the health of
your environment requires reliable software to view it quickly and the ability to
notify the database administrator of a problem.

Continuous operation: Providing continuous access to your data is essential when

very little or no downtime is acceptable to perform maintenance activities.
Activities, such as moving a table to another location in the database or even
adding CPUs to your hardware, should be transparent to the user in a high
availability architecture.

By Lec. Pratik Chand, Page 37

 Elective-Database Administration – CSIT 7th Semester

Importance of Availability

The importance of high availability varies among applications. Databases and the
internet have enabled worldwide collaboration and information sharing by
extending the reach of database applications throughout organizations and
communities. This reach emphasizes the importance of high availability in data
management solutions.

Both small businesses and global enterprises have users all over the world who
require access to data 24 hours a day. Without this data access, operations can stop,
and revenue is lost. Users now demand service-level agreements from their
information technology (IT) departments and solution providers, reflecting the
increasing dependence on these solutions. Increasingly, availability is measured in
dollars, euros, and yen, not just in time and convenience.

Enterprises have used their IT infrastructure to provide a competitive advantage,

increase productivity, and empower users to make faster and more informed
decisions. However, with these benefits has come an increasing dependence on that
infrastructure. If a critical application becomes unavailable, then the business can
be in jeopardy. The business might lose revenue, incur penalties, and receive bad
publicity that has a lasting effect on customers and on the company's stock price.

Oracle Data Guard:

Oracle Data Guard ensures high availability, data protection, and disaster recovery
for enterprise data. Oracle Data Guard provides a comprehensive set of services
that create, maintain, manage, and monitor one or more standby databases to
enable production Oracle databases to survive disasters and data corruptions.
Oracle Data Guard maintains these standby databases as transactionally consistent
copies of the primary database. If the primary database becomes unavailable
because of a planned or an unplanned outage, Oracle Data Guard enables you to
switch any standby database to the production role, thus minimizing the downtime
associated with the outage. Oracle Data Guard can be used with traditional backup,
recovery, and cluster techniques, as well as with the Flashback Database feature to
provide a high level of data protection and data availability.

Downtime: Oracle Database unavailable time or delay

By Lec. Pratik Chand, Page 38

 Elective-Database Administration – CSIT 7th Semester

Oracle Data Guard and Broker Configuration

An Oracle Data Guard configuration consists of one primary database and a

combination of up to thirty standby destination databases, far sync instances, and
Zero Data Loss Recovery Appliances that receive redo directly from the primary
database. The members of an Oracle Data Guard configuration are connected by
Oracle Net and may be dispersed geographically. There are no restrictions on
where the members are located as long as they can communicate with each other.

The Oracle Data Guard broker logically groups these members into a broker
configuration that allows the broker to manage and monitor them together as an
integrated unit. You can manage a broker configuration using either Oracle
Enterprise Manager Cloud Control (Cloud Control) or the Oracle Data Guard
command-line interface.

Fig: Oracle Data Guard Configuration

Primary Database:
An Oracle Data Guard configuration contains one production database, also
referred to as the primary database, that functions in the primary role. The primary
database is the database that is accessed by most of your applications. The primary
database can be either a single-instance Oracle database or an Oracle Real
Application Clusters (Oracle RAC) database.

Standby Databases:
A standby database is a transactionally consistent copy of the primary database.

Using a backup copy of the primary database, you can create up to thirty standby
databases and incorporate them into an Oracle Data Guard configuration. Oracle

By Lec. Pratik Chand, Page 39

 Elective-Database Administration – CSIT 7th Semester

Data Guard automatically maintains each standby database by transmitting redo

data from the primary database and then applying the redo to the standby database.
Similar to a primary database, a standby database can be either a single-instance
Oracle database or an Oracle RAC database.

The types of standby databases are as follows:

 Physical standby database: Provides a physically identical copy of the

primary database, with on-disk database structures that are identical to the
primary database on a block-for-block basis. The database schema, including
indexes, are the same. A physical standby database is kept synchronized
with the primary database, through Redo Apply, which recovers the redo
data received from the primary database and applies the redo to the physical
standby database.
 Logical standby database: Contains the same logical information as the
production database, although the physical organization and structure of the
data can be different. The logical standby database is kept synchronized with
the primary database through SQL Apply, which transforms the data in the
redo received from the primary database into SQL statements and then
executes the SQL statements on the standby database.
 Snapshot Standby Database: A snapshot standby database is a fully
updatable standby database. Like a physical or logical standby database, a
snapshot standby database receives and archives redo data from a primary
database. Unlike a physical or logical standby database, a snapshot standby
database does not apply the redo data that it receives. The redo data received
by a snapshot standby database is not applied until the snapshot standby is
converted back into a physical standby database, after first discarding any
local updates made to the snapshot standby database. A snapshot standby
database is best used in scenarios that require a temporary, updatable
snapshot of a physical standby database.

Far Sync Instances:

An Oracle Data Guard far sync instance is a remote Oracle Data Guard destination
that accepts redo from the primary database and then ships that redo to other
members of the Oracle Data Guard configuration.

By Lec. Pratik Chand, Page 40

 Elective-Database Administration – CSIT 7th Semester

A far sync instance manages a control file, receives redo into standby redo logs
(SRLs), and archives those SRLs to local archived redo logs, but that is where the
similarity with standbys ends. A far sync instance does not have user data files,
cannot be opened for access, cannot run redo apply, and can never function in the
primary role or be converted to any type of standby database.

Far sync instances are part of the Oracle Active Data Guard Far Sync feature,
which requires an Oracle Active Data Guard license.

Zero Data Loss Recovery Appliance:

Zero Data Loss Recovery Appliance (Recovery Appliance) is an enterprise-level
backup solution that provides a single repository for backups of all of your Oracle
databases.

Recovery Appliance offloads most Oracle Database backup and restore processing
to a centralized backup system. It enables you to achieve significant efficiencies in
storage utilization, performance, and manageability of backups.

Flashback Operation:
It sometimes necessary to return some objects in your database or the entire
database to a previous state, following the effects of a mistaken database update.
For example, a user or DBA might erroneously delete or update the contents of one
or more tables, drop database objects that are still needed for a risky operation such
as an update to an application or a large batch update might fail.

In addition to point-in-time restore and recovery of the entire database, Oracle

provides a group of features known as Oracle Flashback Technology, that are often
faster than point-in-time recovery, and less disruptive to database availability.

Oracle Flashback Technology provides several alternatives to a set of features that

support viewing past states of data, and winding data back and forth in time,
without requiring the restore of the database from backup. Depending upon the
changes to your database, Flashback Technology can often reverse the unwanted
changes more quickly and with less impact on the availability of the rest of your
database.

By Lec. Pratik Chand, Page 41

 Elective-Database Administration – CSIT 7th Semester

Oracle Flashback Technology:

Oracle Flashback technology provides a set of features that complements your

physical backup and recovery strategy. Oracle Flashback Technology provides an
additional layer of data protection. Specifically, you can use the various features of
Oracle Flashback to view past states of data and rewind your database without
restoring backups or performing point-in-time recovery.

In general, flashback features are more efficient and less disruptive than media
recovery in most situations in which they apply.

Oracle Flashback Technology enables you to use the following functionality:

 Logical Flashback Features

 Flashback Database

Logical Flashback Features:

The logical-level flashback features of Oracle Database do not depend on RMAN
and are available whether or not RMAN is part of your backup strategy.

Most of the flashback features of Oracle operate at the logical level, enabling you
to view and manipulate database objects. Except for Oracle Flashback Drop, the
logical flashback features rely on undo data, which are records of the effects of
each database update and the values overwritten in the update.

Oracle Database includes the following logical flashback features:

 Oracle Flashback Query: You can specify a target time and run queries
against a database, viewing results as they would appear at the target time.
To recover from an unwanted change like an update to a table, you could
choose a target time before the error and run a query to retrieve the contents
of the lost rows.
 Oracle Flashback Version Query: You can view all versions of all rows
that ever existed in one or more tables in a specified time interval. You can
also retrieve metadata about the differing versions of the rows, including
start and end time, operation, and transaction ID of the transaction that
created the version. You can use this feature to recover lost data values and
to audit changes to the tables queried.
By Lec. Pratik Chand, Page 42
 Elective-Database Administration – CSIT 7th Semester

 Oracle Flashback Transaction Query: You can view changes made by a

single transaction, or by all the transactions during a specific time period.
 Oracle Flashback Transaction: You can reverse a transaction. Oracle
Database determines the dependencies between transactions and in effect
creates a compensating transaction that reverses the unwanted changes. The
database rewinds to a state as if the transaction, and any transactions that
could be dependent on it, had never happened.
 Oracle Flashback Table: You can recover a table or set of tables to a
specified point in time earlier without taking any part of the database offline.
In many cases, Flashback Table eliminates the need to perform more
complicated point-in-time recovery operations. Flashback Table restores
tables while automatically maintaining associated attributes such as current
indexes, triggers, and constraints, and in this way enabling you to avoid
finding and restoring database-specific properties.
 Oracle Flashback Drop: You can reverse the effects of a DROP TABLE
statement.

A flashback data archive enables you to use some logical flashback features to
access data from far back in the past. A flashback data archive consists of one or
more tablespaces or parts of tablespaces. When you create a flashback data archive,
you specify the name, retention period, and tablespace. You can also specify a
default flashback data archive. The database automatically purges old historical
data the day after the retention period expires.

You can turn flashback archiving on and off for individual tables. By default,
flashback archiving is turned off for every table.

Flashback Database:
Flashback Database enables you to revert an Oracle Database to a previous point in
time. At the physical level, Oracle Flashback Database provides a more efficient
data protection alternative to database point-in-time recovery (DBPITR). If the
current data files have unwanted changes, then you can use the RMAN command
FLASHBACK DATABASE to revert the data files to their contents at a past time.
The end product is much like the result of a DBPITR, but is generally much faster

By Lec. Pratik Chand, Page 43

 Elective-Database Administration – CSIT 7th Semester

because it does not require restoring data files from backup and requires less redo
than media recovery.

Flashback Database uses flashback logs to access past versions of data blocks and
some information from archived redo logs. Flashback Database requires that you
configure a fast recovery area for a database because the flashback logs can only be
stored there. Flashback logging is not enabled by default. Space used for flashback
logs is managed automatically by the database and balanced against space required
for other files in the fast recovery area.

Oracle Database also supports restore points along with Flashback Database and
backup and recovery. A restore point is an alias corresponding to a system change
number (SCN). You can create a restore point at any time if you anticipate needing
to return part or all of a database to its contents at that time. A guaranteed restore
point ensures that you can use Flashback Database to return a database to the time
of the restore point.

End of Unit-4

By Lec. Pratik Chand, Page 44