Enhancements in Oracle 12c Data Guard & Recovery

O

r

a

c

l

e

1

2

c

D

a

t

a

G

u

a

r

d

&

B

a

c

k

u

p

a

n

d

R

e

c

o

v

e

r

y

W

o

r

k

s

h

o

p

Q

u

e

s

t

i

o

n

•

Can you please recap the main new features introduced in Oracle 12c Release 2

for the Broker as well as Data Guard – what has changed compared to say Oracle

11g ?

Data Guard New Features

Oracle 12c Release 1 and Release 2

S

Y

S

D

G

A

d

m

i

n

i

s

t

r

a

t

i

v

e

P

r

i

v

i

l

e

g

e

f

o

r

O

r

a

c

l

e

D

a

t

a

G

u

a

r

d

O

p

e

r

a

t

i

o

n

s

•

Oracle Data Guard-specific administration privilege

•

Enforcing better separation of duty

•

Perform standard administration duties for an Oracle Data Guard environment

•

Earlier on required SYSDBA privilege

•

STARTUP,SHUTDOWN, ALTER DATABASE, SELECT ANY DICTIONARY, CREATE

RESTORE POINT etc

•

No access to application data either via DML or DDL operations

R

e

a

l

-

t

i

m

e

C

a

s

c

a

d

e

d

S

t

a

n

d

b

y

•

Cascaded redo transport destination receives redo from primary database

indirectly from another standby database (cascading standby) rather than directly

from a primary database

•

The cascaded standby is referred to as the terminal destination

•

Offloads the overhead associated with redo transport from primary database of

having to ship redo to multiple standby destinations

•

Real-time cascading requires a license for the Oracle Active Data Guard option

•

Cascading standby database can cascade primary database redo to up to 30

terminal destinations

•

Multiple standby destinations – one for Disaster Recovery and others for real-

time reporting

F

a

r

S

y

n

c

F

a

r

S

y

n

c

I

n

s

t

a

n

c

e

C

o

m

p

o

n

e

n

t

s

O

n

l

i

n

e

r

e

l

o

c

a

t

i

o

n

o

f

p

r

i

m

a

r

y

d

a

t

a

b

a

s

e

d

a

t

a

f

i

l

e

•

Prior to Oracle 12c file had to be taken offline or database was not open

•

Online move of datafile to different physical location while database is open

•

ALTER DATABASE MOVE DATAFILE

•

Standby database is not affected when the primary database datafile is moved

•

Also move datafile on ADG enabled standby database while redo apply and

recovery is in progress

D

M

L

o

p

e

r

a

t

i

o

n

s

o

n

A

c

t

i

v

e

S

t

a

n

d

b

y

•

DML operations allowed on Global Temporary tables on Active Data Guard

enabled standby database

•

Undo on Global Temporary tables stored in temp tablespace and not undo

tablespace

•

Redo-less changes to Global Temporary tables

•

Read-mostly reporting applications as opposed to only read-only reporting

applications

R

e

s

u

m

e

a

s

w

i

t

c

h

o

v

e

r

a

f

t

e

r

a

f

a

i

l

u

r

e

•

If switchover fails because of a configuration issue, the Data Guard Broker reports

any problems it encounters in the alert log files or in the broker log files

•

Review log files and fix the problem (if possible)

•

Retry the switchover operation

V

A

L

I

D

A

T

E

D

a

t

a

b

a

s

e

•

Performs a comprehensive set of database checks prior to a role change

•

Will report if a database is ready for either a Switchover or Failover

•

Provides a summary of the database

•

Reports and errors or warnings that are detected

•

Obtains information from both Data Guard related dictionary views a well as

Automatic Diagnostic Repository (ADR)

•

Checks if temp datafiles exist, adequate groups of standby redo log files, block

corruptions, system or user data files are offline or corrupted as well as flashback

database status

D

a

t

a

G

u

a

r

d

a

t

t

h

e

P

l

u

g

g

a

b

l

e

D

a

t

a

b

a

s

e

L

e

v

e

l

•

 Prior to Oracle Database 12c Release 2 Data Guard was configured either for all

pluggable databases in a container database or for none

•

ENABLED_PDBS_ON_STANDBY initialization parameter

•

Specify a subset of pluggable databases (PDB’s) in a container database with a

corresponding physical standby database

•

Database role defined at the pluggable database level and not the container level

•

 If the parameter is not specified, then all PDBs in the CDB are created on the

standby

I

n

-

M

e

m

o

r

y

C

o

l

u

m

n

S

t

o

r

e

o

n

s

t

a

n

d

b

y

d

a

t

a

b

a

s

e

•

Supported in an Active Data Guard environment

•

Offload reporting workloads to standby

•

Also offload analytical query type workload to standby

•

In-Memory column store can exist on both Primary and Standby database

•

In-Memory column store can also exist exclusively on the Standby database

•

INMEMORY_SIZE=0 on Primary

•

INMEMORY_SIZE=10G on Standby

A

u

t

o

m

a

t

i

c

P

a

s

s

w

o

r

d

F

i

l

e

C

h

a

n

g

e

P

r

o

p

a

g

a

t

i

o

n

•

Prior to 12.2 password files had to be manually synchronized between the

primary and standby databases

•

ORA-16191: Primary log shipping client not logged on standby type errors if

password was changed

•

Password file changes done on the primary database are now automatically

propagated to standby databases

•

Password file updates on primary now included in redo stream

•

Redo apply on standby updates password file on standby

K

e

e

p

i

n

g

P

h

y

s

i

c

a

l

S

t

a

n

d

b

y

S

e

s

s

i

o

n

s

C

o

n

n

e

c

t

e

d

D

u

r

i

n

g

R

o

l

e

T

r

a

n

s

i

t

i

o

n

•

Prior to 12.2, Data Guard role transitions like switchover would disconnect user

sessions

•

Standby database can be used for reporting purposes (ADG)

•

User sessions connected would not be disrupted during a role transition from

standby to primary

•

STANDBY_DB_PRESERVE_STATES initialization parameter

•

NONE, ALL or SESSION

•

NONE is default and no sessions retained during switchover or failover

•

SESSION or ALL - user sessions are retained when a read-only physical standby

database is converted to primary

U

s

i

n

g

O

r

a

c

l

e

D

i

a

g

n

o

s

t

i

c

P

a

c

k

t

o

T

u

n

e

O

r

a

c

l

e

A

c

t

i

v

e

D

a

t

a

G

u

a

r

d

S

t

a

n

d

b

y

s

•

Active Data Guard standby is open in read-only mode

•

Being used for supporting real-time queries and read-only reporting applications

•

Also can be used for storing In-Memory columnar data

•

Ability to identify and tune costly SQL being executed on ADG standby

•

Capture performance data to the Automatic Workload Repository (AWR) for an

Oracle Active Data Guard standby

•

Run Automatic Database Diagnostic Monitor (ADDM) analysis on the AWR data

M

u

l

t

i

p

l

e

o

b

s

e

r

v

e

r

s

f

o

r

F

a

s

t

-

S

t

a

r

t

F

a

i

l

o

v

e

r

•

If one observer fails, backup observer takes over automatically so configuration is

never in an unobserved state

•

Register up to three observers to monitor a single Data Guard broker

configuration

•

At any given time only one Observer is active and designated as the master

•

START OBSERVER <NAME>

•

SET MASTEROBSERVER TO <NAME>

C

r

e

a

t

e

S

t

a

n

d

b

y

D

a

t

a

b

a

s

e

v

i

a

D

B

C

A

[oracle@host02 dbs]$ 

dbca -silent -createDuplicateDB -gdbName amer -

primaryDBConnectionString host01:1521/amer -sid amer -createAsStandby -

dbUniqueName amer_sb

Enter SYS user password:

Listener config step

33% complete

Auxiliary instance creation

66% complete

RMAN duplicate

100% complete

Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/amer_sb/amer1.log" for further

details.

D

a

t

a

G

u

a

r

d

B

r

o

k

e

r

M

i

s

c

e

l

l

a

n

e

o

u

s

1

2

.

2

N

e

w

F

e

a

t

u

r

e

s

•

DGMGRL @ command allows you to run DGMGRL command scripts

•

VALIDATE DATABASE DATAFILE command performs validation of data files across

both the primary database and standby databases which will include detecting

any lost writes

•

SHOW DATABASE VERBOSE command shows the locations of the Oracle alert log

file and of the broker log file

•

SPOOL command is available to record the output of the commands issued on the

DGMGRL console

•

/ (slash) command available which repeats the last command entered on the

DGMGRL console.

Part Two

Backup and Recovery

W

h

y

B

a

c

k

u

p

a

n

d

R

e

c

o

v

e

r

y

•

Protect the database against media failure, site failure, human error, natural

disaster, terrorism etc

•

In the event of a loss reconstruct or recover the database

•

Objective is to recover as fast as possible (RTO or Recovery Time Objective)

•

Objective is to recover with minimum data loss (RPO or Recovery Point Objective)

T

y

p

e

s

o

f

F

a

i

l

u

r

e

s

•

Media Failures

•

Failure to read or write to a database file located on disk

•

User or Human errors

•

Data in database is changed incorrectly – by mistake or wilfully

•

Application error

•

Application logic or code error has adverse effect on data in the database

•

Software malfunction or logical errors

B

a

c

k

u

p

r

e

l

a

t

e

d

D

B

A

a

c

t

i

v

i

t

i

e

s

a

n

d

d

u

t

i

e

s

•

Planning a backup strategy

•

Backup strategy should have minimum impact to the business

•

Configuring a backup schedule

•

Monitoring the backup environment

•

Testing recovery from different failure scenarios

•

Data archival

•

Data transfer

P

h

y

s

i

c

a

l

B

a

c

k

u

p

a

n

d

L

o

g

i

c

a

l

B

a

c

k

u

p

•

Physical backups are physical copies of database files – data files, control files,

archive redo log files, parameter and password files

•

Physical copy is taken to disk or offline media like tape library or Oracle Recovery

Appliance (Zero Data Loss Appliance)

•

Foundation for any sound backup and recovery strategy

•

Logical backups supplement physical backups

•

Data pump export of tables, subset of tables or schema level

•

Data pump export of stored procedures and packages

•

Database backups are physical backups

U

s

e

r

-

m

a

n

a

g

e

d

b

a

c

k

u

p

s

a

n

d

R

M

A

N

•

Cold backups or ‘hot’ backups

•

Copy files at the O/S level after database has been shutdown in a consistent

manner via SHUTDOWN IMMEDIATE/NORMAL/TRANSACTIONAL option

•

Or after tablespace to be backed up is taken offline

•

User has to ensure backup is taken at transactionally consistent database

checkpoint SCN

•

Online backup requires BEGIN BACKUP and END BACKUP

•

ALTER TABLESPACE BEGIN|END BACKUP

•

ALTER DATABASE BEGIN|END BACKUP

•

V$BACKUP view has information about which data file is in ‘hot’ backup mode

R

M

A

N

C

o

m

p

o

n

e

n

t

s

•

RMAN client 

connects to target database using Oracle Net

•

Target database 

is the database that the RMAN client connects to for backup or restore

operations

•

Recovery Catalog 

database or schema is a separate database/schema which contains the

metadata required by RMAN for backup and recovery operations. Recovery catalog can

contain backup metadata for not just one but numerous databases

•

In the absence of a Recovery Catalog RMAN will use 

database control file 

to obtain

required metadata

•

Fast Recovery Area 

disk-based location for storing RMAN backups and recovery-related

files like control files, online and archive redo log files, flashback log files.

•

Media Management Software 

enables vendor-specific backup application to integrated

with RMAN for backup to storage systems like tape media

C

o

n

n

e

c

t

i

n

g

w

i

t

h

R

M

A

N

•

rman target '"/ as sysdba“’

•

rman target '"/ as sysbackup“’

•

rman target /

•

rman target bkupoper@pdb1

•

RMAN> connect catalog rco@catdb

•

 rman target / auxiliary sys@aux

R

M

A

N

C

o

m

m

a

n

d

s

,

s

c

r

i

p

t

s

,

s

u

b

s

t

i

t

u

t

i

o

n

v

a

r

i

a

b

l

e

s

•

RMAN> CONNECT TARGET

•

RMAN> BACKUP DATABASE;

•

rman TARGET / @cmdfile1

•

RMAN> @cmdfile1

•

Make backup scripts dynamic using SQL*PLUS like substitution variables

•

Invoke substitution variables via USING command

U

s

i

n

g

S

u

b

s

t

i

t

u

t

i

o

n

V

a

r

i

a

b

l

e

s

testbkp.rcv

connect target sys/oracle

run{

backup incremental level &1

database

tag &2;

}

bkp_db.sh

#! /bin/ksh

export level=$1

export tag=$2_`date +%d%b%y`

rman @testbkp.rcv using $level $tag

$ ./

bkp_db.sh 1 inc_lev1

R

M

A

N

C

o

n

f

i

g

u

r

i

n

g

E

n

v

i

r

o

n

m

e

n

t

•

RMAN out of the box default values may be adequate in most environments

•

Can override default parameters

•

SHOW or SHOW ALL to view default parameters

•

CONFIGURE to change defaults

•

Configure backup retention policy, encryption, default destinations for backups,

tape backups

R

M

A

N

C

o

n

f

i

g

u

r

a

t

i

o

n

SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

CONFIGURE BACKUP OPTIMIZATION ON;

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP ON; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default

CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default

R

M

A

N

C

o

n

f

i

g

u

r

a

t

i

o

n

•

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

•

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default

•

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

•

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_DEVICE=tape1)';

•

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

•

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

•

CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

•

CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR

LOAD TRUE ; # default

•

CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default

•

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

•

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; #

default

R

M

A

N

R

e

t

e

n

t

i

o

n

P

o

l

i

c

i

e

s

•

How long to retain backups

•

Would depend on SLAs related to data recovery

•

REDUNDANCY-based retention policy

•

RECOVERY WINDOW-based retention policy

•

Defined via CONFIGURE RETENTION POLICY command

•

Redundancy based retention policy specifies how many full or level 0 backups of

data file and control file which RMAN will retain

•

Default is 1

•

If number of full or level 0 backups for specific data file or control file is exceeded

then RMAN considers additional backups as OBSOLETE

•

OBSOLETE backups can be deleted by RMAN automatically

R

E

D

U

N

D

A

N

C

Y

-

b

a

s

e

d

r

e

t

e

n

t

i

o

n

p

o

l

i

c

y

•

CONFIGURE RETENTION POLICY TO REDUNDANCY 2

•

 Full backups are performed every Monday, Tuesday, Wednesday, and Thursday

•

As part of Friday backup, Monday and Tuesday backups become obsolete

•

Run DELETE OBSOLETE command to remove redundant backups

W

I

N

D

O

W

-

b

a

s

e

d

r

e

t

e

n

t

i

o

n

p

o

l

i

c

y

•

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS

•

Recovery window is a period that begins with the current time and extends

backward in time to the earliest time a point-in-time recovery is possible in the

event of a media failure

•

Full backups and required incremental backups and archived logs are retained by

RMAN so that the database can be recovered up to 7 days in the past

•

Backups taken outside of the recovery window (later than 7 days) may be

required to satisfy the point-in-time recovery objective

R

M

A

N

C

h

a

n

n

e

l

s

•

An RMAN channel is a connection to a database server session

•

CONFIGURE CHANNEL command to configure options for disk or tape-based

backup channels

•

Override and specify one-time options with the ALLOCATE CHANNEL command

•

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /backup/%U;

•

CONFIGURE DEVICE TYPE sbt PARALLELISM 2;

•

ALLOCATE CHANNEL c1 DEVICE TYPE DISK;

•

ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE DISK;

A

r

c

h

i

v

e

d

R

e

d

o

L

o

g

D

e

l

e

t

i

o

n

P

o

l

i

c

y

•

CONFIGURE ARCHIVELOG DELETION POLICY command to specify when archived redo log

files are eligible for deletion

•

Archived redo logs can be deleted automatically by the database or via user-initiated

RMAN commands

•

Archive log files in the fast recovery area can be deleted automatically by the database

under situation of space pressure

•

By default archive redo log policy is set to NONE

•

Archived redo log files in the recovery area are eligible for deletion if they have been

backed up at least once to disk or SBT

•

CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP 2 TIMES TO DEVICE TYPE

•

CONFIGURE ARCHIVELOG DELETION POLICY TO 

APPLIED ON STANDBY

•

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY

A

d

v

a

n

c

e

d

C

o

n

f

i

g

u

r

a

t

i

o

n

•

Configuring Backup Duplexing

•

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2

•

Configuring Tablespaces for Exclusion from Whole Database Backups

•

CONFIGURE EXCLUDE FOR TABLESPACE example;

•

C

onfigure backup compression

•

CONFIGURE COMPRESSION ALGORITHM 'BASIC’;

•

CONFIGURE COMPRESSION ALGORITHM ‘HIGH’;

•

Configuring Backup Encryption

•

CONFIGURE ENCRYPTION FOR DATABASE ON;

•

CONFIGURE ENCRYPTION ALGORITHM TO 'AES256';

B

a

c

k

u

p

O

p

t

i

m

i

z

a

t

i

o

n

•

BACKUP command skips backing up a particular file when the identical file has

already been backed up to the specified device type

•

CONFIGURE BACKUP OPTIMIZATION ON

•

Data file is considered identical if it has the 

same DBID 

or 

checkpoint SCN 

as the

data file already backed up

•

Archived log file is considered identical if it has the 

same DBID

, 

thread number

,

sequence number 

and 

RESETLOGS SCN

R

M

A

N

B

a

c

k

u

p

s

•

RMAN> BACKUP DATABASE;

•

RMAN uses the configuration settings stored in the control file or recovery

catalog and the records of previous backups to determine an efficient set of steps

for the backup

•

D

etermines the destination device type and backup location as well as any

advanced options like encryption or compression

•

RMAN> BACKUP DEVICE TYPE DISK DATABASE;

•

RMAN> BACKUP AS COPY DEVICE TYPE DISK DATABASE;

•

R

MAN> 

BACKUP DATABASE FORMAT "/backup/bkp_full_%U";

R

M

A

N

B

a

c

k

u

p

S

e

t

a

n

d

B

a

c

k

u

p

P

i

e

c

e

s

•

Backup data stored by RMAN in a logical structure called a backup set

•

S

mallest unit of an RMAN backup

•

A backup set contains the data from one or more data files, archived redo logs,

control files, or server parameter file

•

A backup set contains one or more binary files in an RMAN-specific format called

backup piece

•

B

ackup multiple files into one backup set with one backup piece

•

S

ECTION SIZE parameter of BACKUP command will produce multiple backup

pieces

•

Backup a large file in parallel with multiple channels each producing an individual

backup piece

I

m

a

g

e

C

o

p

y

•

An image copy is an exact copy of a database file

•

Not stored in RMAN format

•

Similar to making a copy using operating system commands

•

RMAN BACKUP AS COPY command

•

Image copies are chosen over backupsets because of the additional overhead of reading

through an entire backupset trying to identify the file which is needed to be restored

•

Can perform a SWITCH DATAFILE TO COPY command to use the image copies already

existing on disk as a replacement for the datafile which needs to be restored followed by

a recovery of the data file copy

•

No need to perform a restore of data file first before performing a recovery

•

Control file is updated with new location of the data file

M

u

l

t

i

s

e

c

t

i

o

n

B

a

c

k

u

p

•

Multisection backup enables backups  of large data files to be divided into

sections

•

Sections backed up in parallel across multiple channels

•

Faster backup performance and better recovery times

•

N

ew in 12c  is Multisection Incremental Backups

•

BACKUP INCREMENTAL LEVEL 1 SECTION SIZE 1024M DATAFILE

‘/u01/app/oracle/users01.dbf';

M

u

l

t

i

p

l

e

x

e

d

R

M

A

N

B

a

c

k

u

p

S

e

t

s

•

RMAN can simultaneously read multiple files from disk and then write their blocks into the same

backup set

•

I

mage copies of files are not multiplexed

•

M

ultiplexing based on FILESPERSET and MAXOPENFILES

•

FILESPERSET parameter of the BACKUP command determines how many data files to put in each

backup set as well as how many files are read by a channel  - 

d

efault is 64

•

M

AXOPENFILES defines how many data files RMAN can read from simultaneously – default is 8

•

The level of multiplexing is the minimum of MAXOPENFILES and the number of files in each

backup set

•

If FILESPERSET is lower then the level of multiplexing, then multiplexing will be FILESPERSET value

•

Backup 12 data files with one channel when FILEPERSET is set to 4.

•

The level of multiplexing is the lesser of this number and 8

•

The channel simultaneously writes blocks from 4 data files into each backup piece

 RMAN can simultaneously read multiple files from disk and

then write their blocks into the same backup set

P

a

r

a

l

l

e

l

i

z

i

n

g

a

d

a

t

a

b

a

s

e

b

a

c

k

u

p

RUN

{

  ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT ‘/u01/%d_backups/%U';

  ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT ‘/u02/%d_backups/%U';

  ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT ‘/u03/%d_backups/%U';

  BACKUP AS COPY DATABASE;

}

F

u

l

l

b

a

c

k

u

p

s

•

Perform a complete database backup when database is either mounted or open

•

Issue BACKUP DATABASE command

•

Can exclude certain tablespaces from backup (maybe read-only tablespaces)

•

SKIP READONLY clause

•

Can also backup archive log files along with data files

•

BACKUP DATABASE PLUS ARCHIVELOG

•

Performs a log switch and archives current redo log file which is also included in

the full backup

I

n

c

r

e

m

e

n

t

a

l

b

a

c

k

u

p

s

•

Incremental backup copies only data file blocks that have changed since a

specified previous backup

•

Cumulative

 incremental backup or a 

Differential

 incremental backup

•

BACKUP DATABASE and BACKUP INCREMENTAL LEVEL 0 DATABASE are different

•

A full backup is not usable as part of an incremental strategy

•

 Level 0 incremental backup is the basis of an incremental strategy

I

n

c

r

e

m

e

n

t

a

l

b

a

c

k

u

p

s

•

Avoid daily full backups reducing disk space requirements for backup storage

•

Reduced network traffic caused by transmitting backup data

•

Faster daily backups if combined with Block Change Tracking

•

Faster recovery times

•

Synchronize a physical standby database with the primary database in case of a

lag on the standby via BACKUP INCREMENTAL FROM SCN command

I

n

c

r

e

m

e

n

t

a

l

b

a

c

k

u

p

s

•

Differential Backup 

•

RMAN looks for last level 1 or level 0 backup and only captures those data block

changes that were made after those backups at the same level

•

I

s the default

•

B

ACKUP INCREMENTAL LEVEL 1 DATABASE

•

C

umulative Backup

•

RMAN backups up all data block changes that are made after a level 0 backup or

level 1 backup at the same or lower level

•

B

ACKUP INCREMENTAL LEVEL 1 CUMULATIVE  DATABASE

C

u

m

u

l

a

t

i

v

e

I

n

c

r

e

m

e

n

t

a

l

B

a

c

k

u

p

D

i

f

f

e

r

e

n

t

i

a

l

I

n

c

r

e

m

e

n

t

a

l

B

a

c

k

u

p

C

o

m

p

a

r

i

s

o

n

b

e

t

w

e

e

n

C

u

m

u

l

a

t

i

v

e

a

n

d

D

i

f

f

e

r

e

n

t

i

a

l

•

Recovery speed

•

Cumulative backups are faster to restore from than differential backups because fewer

incremental backups need to be applied during recovery

•

Backup speed

•

 Differential backups run faster than cumulative backups because it does not duplicate the

work done by previous backups

•

Disk space usage

•

 Cumulative backups take more disk space because they duplicate the work done by previous

backups

R

M

A

N

B

a

c

k

u

p

T

a

g

•

Useful way to indicate the purpose of the backup

•

Tags are often used to distinguish a series of backups created as part of a single

backup strategy – level 0 incremental backup, level 1 incremental backup

•

B

ACKUP INCREMENTAL LEVEL 0 DATABASE TAG weekly_incr

•

T

ag format is TAGYYYYMMDDTHHMMSS if tag name is not explicitly set

•

L

IST BACKUP OF DATABASE TAG weekly_incr

B

a

c

k

u

p

A

r

c

h

i

v

e

L

o

g

F

i

l

e

s

•

BACKUP DATABASE PLUS ARCHIVELOG ;

•

BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES;

•

BACKUP ARCHIVELOG ALL;

•

BACKUP DEVICE TYPE sbt ARCHIVELOG ALL DELETE ALL INPUT;

•

B

ACKUP ARCHIVELOG FROM TIME ‘SYSDATE-1’;

•

B

ACKUP ARCHIVELOG FROM TIME ‘SYSDATE-(1/24)’;

•

B

ACKUP ARCHIVELOG SEQUENCE 2;

•

B

ACKUP ARCHIVELOG SEQUENCE BETWEEN 2 AND 5;

I

n

c

r

e

m

e

n

t

a

l

l

y

U

p

d

a

t

i

n

g

B

a

c

k

u

p

s

•

Also know as OSS or Oracle Suggested Strategy

•

Reduced backup disk footprint

•

Minimize time required for media recovery of your database

•

Create a full image copy backup of all data files of a database with a specified tag

•

At regular intervals make a level 1 differential incremental backup of the data files

and use the same tag as the base data file copy

•

Apply the incremental backup to the most recent backup with the same tag

•

Rolls forward the backup to the time when the last level 1 incremental backup

was made

I

n

c

r

e

m

e

n

t

a

l

l

y

U

p

d

a

t

i

n

g

B

a

c

k

u

p

s

RUN

{

  RECOVER COPY OF DATABASE

    WITH TAG ‘oss_bkp';

  BACKUP

    INCREMENTAL LEVEL 1

    FOR RECOVER OF COPY WITH TAG ‘oss_bkp'

    DATABASE;

}

BACKUP

•

Day One

•

Level 0 backup is performed since no level 0 image copy exists

•

Day Two

•

Level 1 incremental backup is performed containing blocks changed since level 0

backup

•

Day Three

•

Level 1 incremental backup is performed containing blocks changed since last

level 1 backup

RECOVER

•

Day One

•

Because no incremental backup or data file copy exists, the command generates a

message

•

D

ay Two

•

A database copy now exists, but no incremental level 1 backup exists with which

to recover it. The RECOVER command has no effect

•

D

ay Three

•

The level 1 incremental backup made on Day Two is applied to the database copy

bringing the copy up to the checkpoint SCN of the level 1 incremental backup

R

M

A

N

A

u

t

o

b

a

c

k

u

p

•

Configure RMAN to automatically back up the control file and server parameter

file

•

CONFIGURE CONTROLFILE AUTOBACKUP ON

•

Autobackup occurs whenever a backup record is added as part of a full or

incremental backup

•

In addition, if the database runs in ARCHIVELOG mode, then an autobackup is

also taken whenever the database structure which is maintained in the control

file changes

•

RMAN can recover the database even if the current control file, recovery catalog

or database parameter file are los

B

a

c

k

u

p

t

a

b

l

e

s

p

a

c

e

s

,

c

o

n

t

r

o

l

f

i

l

e

,

S

P

F

I

L

E

•

BACKUP TABLESPACE users, appdata;

•

BACKUP DEVICE TYPE sbt DATAFILE 1,2,3,4;

•

Manual control file backup

•

BACKUP CURRENT CONTROLFILE;

•

Manual parameter file backup

•

BACKUP DEVICE TYPE sbt SPFILE;

B

l

o

c

k

C

h

a

n

g

e

T

r

a

c

k

i

n

g

•

Use block change tracking feature for incremental backups

•

I

mproves backup performance (speed) for incremental backups

•

R

ecords changed blocks for each data file

•

B

y reading the bitmap file to determine which blocks have changed does not

have to scan entire data file to detect changed blocks

•

B

enefit is large when relatively small percentage of blocks are change between

backups

•

T

urned off by default

B

l

o

c

k

C

h

a

n

g

e

T

r

a

c

k

i

n

g

•

First level 0 incremental backup will scan the entire data file

•

Subsequent incremental backups will use the block change tracking file to scan

only the blocks that have been marked as changed since the last incremental

backup

•

L

evel 0 backup needs to be taken after block change tracking is enabled

•

O

ne block change tracking file per database

•

S

pace required for block change tracking file is very low compared to database

disk size footprint

•

Space required for block change tracking for a single instance is approximately

1/30,000 the size of the number of data blocks to be tracked

B

l

o

c

k

C

h

a

n

g

e

T

r

a

c

k

i

n

g

•

DB_CREATE_FILE_DEST is set

•

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

•

If DB_CREATE_FILE_DEST is not set

•

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE

‘/u01/app/oradata/blk_chng_trk.dbf’;

•

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

•

V

iew  V$BLOCK_CHANGE_TRACKING to check if enabled

F

a

s

t

R

e

c

o

v

e

r

y

A

r

e

a

•

Earlier referred to as Flash Recovery Area 

•

Location or area on disk where the database can create and manage a variety of

files related to backup and recovery

•

d

b_recovery_file_dest and 

d

b_recovery_file_dest_size database parameters

•

Fast recovery area can contain control files, online redo logs, archived redo logs,

flashback logs as well as RMAN backups

•

S

pace is managed by the database and generated file names are maintained in

Oracle Managed Files (OMF) format

•

Files located in the recovery area can be permanent or transient in nature

F

a

s

t

R

e

c

o

v

e

r

y

A

r

e

a

•

Permanent files are active files used by the database instance – control and redo

log files

•

Transient files can be deleted after they become obsolete under the backup

retention policy or have been backed up to tape – archive log files, flashback log

files, backupsets

•

FRA should be large enough to contain the control files, online redo logs, archived

redo logs, and flashback logs

•

 It should be able to contain a full image copy of all data files in the database and

the incremental backups used

•

DB_FLASHBACK_RETENTION_TARGET also considered when allocating space for

FRA

•

D

BCA in 12c will require FRA to be twice the size of allocated database size

F

a

s

t

R

e

c

o

v

e

r

y

A

r

e

a

•

BACKUP command without the FORMAT clause will create the backup pieces or

image copies in the FRA with names in OMF format

•

Separate FRA location from disk location for database files

•

Separate ASM disk group for FRA (+RECO)

•

Monitor FRA space usage via V$RECOVERY_AREA_USAGE

•

 Indicates the percentage of disk quota used by different type of files, and the

percentage of space that can be reclaimed by deleting files that are either

obsolete, redundant, or backed up to tape

R

e

c

o

v

e

r

y

C

a

t

a

l

o

g

•

Schema in a database used by RMAN to store backup related metadata of one or

more Oracle databases

•

RMAN metadata is stored in the control file

•

Recommended to use a recovery catalog to provide redundancy from loss of

control file

•

Recovery catalog can store metadata history for periods longer than control file

•

Store scripts in a central repository which can be used by any database registered

in the catalog

•

Backup and restore operation data first propagated to database control file and

from there to recovery catalog – this flow is called Catalog Resynchronization

•

Can manually resynchronize catalog via command RESYNC CATALOG

R

e

c

o

v

e

r

y

C

a

t

a

l

o

g

•

Separate dedicated recovery catalog database

•

Or dedicated schema in an existing  database shared with other applications

•

Grant RECOVERY_CATALOG_OWNER privilege to catalog owner

•

Run CREATE CATALOG RMAN command

•

Run REGISTER DATABASE command to register databases with the recovery

catalog

•

rman TARGET / CATALOG rco@rcat

•

Include recovery catalog database as part of enterprise backup strategy

•

UNREGISTER DATABASE and DROP CATALOG

•

UPGRADE CATALOG

S

t

o

r

i

n

g

s

c

r

i

p

t

s

i

n

R

e

c

o

v

e

r

y

C

a

t

a

l

o

g

•

Store frequently used scripts in central catalog as opposed to file systems on

different servers

•

Local and Global scripts

•

A local script is associated with the target database to which RMAN is connected

to when the script is created

•

Can only be executed when connected to that paricular target database

•

A global stored script can be run against any database registered in the recovery

catalog

S

t

o

r

i

n

g

s

c

r

i

p

t

s

i

n

R

e

c

o

v

e

r

y

C

a

t

a

l

o

g

CREATE SCRIPT full_backup

{

  BACKUP DATABASE PLUS ARCHIVELOG;

  DELETE OBSOLETE;

}

CREATE GLOBAL SCRIPT global_full_backup

{

  BACKUP DATABASE PLUS ARCHIVELOG;

  DELETE OBSOLETE;

}

RUN

{

  EXECUTE SCRIPT full_backup;

}

RUN

{

  EXECUTE GLOBAL SCRIPT global_full_backup;

}

R

M

A

N

R

e

s

t

o

r

e

•

    Database

•

    Tablespaces

•

    Control files

•

    Archived redo logs

•

    Server parameter file

R

M

A

N

R

E

S

T

O

R

E

•

Restore to original destination which is the default

•

Restore to new location

•

Use SET NEWNAME to specify new location for files which are restored

•

Followed by SWITCH command

•

SWITCH command updates control file with the new restore location

•

RMAN uses restore optimization to avoid files already restored

•

Examines header of the file to determine if file is already present in the correct

location

•

Useful if restore of a large database was unexpectedly interrupted

•

Override via FORCE option of the RESTORE command

A

r

c

h

i

v

e

l

o

g

f

i

l

e

s

r

e

s

t

o

r

e

•

RMAN restores archived redo log files needed for recovery operations  from

backup automatically

•

Can also manually restore archive log files to disk before performing restore and

recovery operation especially in those cases where backups are stored on tape

•

Can restore archive log files to a new location in case of space issues in current

LOG_ARCHIVE_DEST_

n

 location

•

Use  SET ARCHIVELOG DESTINATION to specify the new location for the restored

archived redo logs

•

By default RMAN restores archived redo logs to the fast recovery area during a

recovery

•

 Automatically deletes the restored logs after they have been applied

R

M

A

N

R

e

c

o

v

e

r

y

•

Complete recovery

•

Point-in-time recovery or incomplete recovery

•

Tablespace point-in-time recovery (TSPITR)

•

Block media recovery

U

s

i

n

g

t

h

e

R

E

S

E

T

L

O

G

S

o

p

t

i

o

n

•

Complete recovery does not require the use of RESETLOGS

•

Point-in-time recovery or recovery using the backup of the control file requires

use of RESETLOGS

•

Creates a new database incarnation

•

Starts a new redo stream and creates online redo log files if they do not exist

•

Resets redo log sequence to 1

•

Updates RESETLOGS SCN in control file and all data file headers

•

Now possible to restore a backup taken before a RESETLOGS operation

D

a

t

a

R

e

c

o

v

e

r

y

A

d

v

i

s

o

r

•

Identifying the failure and deciding the appropriate recovery action which is

needed to be performed as well the right sequence can be a challenging task

under pressure

•

Oracle supplied tool which:

•

Automatically diagnoses a data failure

•

 Determines and presents appropriate repair options

•

Generates a repair script

•

 Executes repair script at the user's request

•

LIST FAILURE followed by ADVISE FAILURE and REPAIR FAILURE

•

Data Recovery Advisor is not supported for pluggable databases and RAC

databases

V

a

l

i

d

a

t

i

n

g

B

a

c

k

u

p

s

•

 Check for corrupt blocks and missing files

•

Checks for physical or logical block corruption

•

Determine whether backups which have been taken can be restored

•

VALIDATE DATABASE

•

VALIDATE BACKUPSET #

•

VALIDATE DATAFILE # BLOCK #

•

Run BACKUP VALIDATE to check for both corruption as well as ensuring files ar e

in the correct location while performing the backup

•

BACKUP VALIDATE CHECK LOGICAL to check for logical corruption

•

RESTORE VALIDATE to check if RMAN can restore specific files without actually

performing a restore operation

C

o

m

p

l

e

t

e

D

a

t

a

b

a

s

e

R

e

c

o

v

e

r

y

•

All or some of the data files are lost or damaged

•

Control files and online redo log files are not affected

•

All archive log files and incremental backups required for recovery are available

•

Identify files needing media recovery via RMAN or SQL*PLUS

•

VALIDATE DATABASE and REPORT SCHEMA command in RMAN

•

RECOVER column of V$DATAFILE_HEADER view

•

V$RECOVER_FILE also lists files requiring media recovery

•

STARTUP MOUNT

•

RESTORE DATABASE

•

RECOVER DATABASE

•

ALTER DATABASE OPEN

T

a

b

l

e

s

p

a

c

e

R

e

c

o

v

e

r

y

•

If the database is open, then take the non-system tablespace requiring recovery

offline

•

ALTER TABLESPACE users OFFLINE IMMEDIATE

•

Restore the tablespace

•

RESTORE TABLESPACE users

•

Recover the tablespace

•

RECOVER TABLESPACE USERS

•

ALTER TABLESPACE users ONLINE

I

n

c

o

m

p

l

e

t

e

R

e

c

o

v

e

r

y

•

Shutdown immediate and then STARTUP MOUNT

•

SET UNTIL TIME ‘Dec 15 2017 09:00:00';

•

SET UNTIL SEQUENCE 1923;

•

SET UNTIL SCN 1024000;

RUN

{

  SET UNTIL SCN 1000;

  RESTORE DATABASE;

  RECOVER DATABASE;

}

•

ALTER DATABASE OPEN RESETLOGS;

R

e

c

o

v

e

r

i

n

g

T

a

b

l

e

s

a

n

d

T

a

b

l

e

P

a

r

t

i

t

i

o

n

s

•

Determine the  backup which contains the tables  that need to be recovered ( based on

the point in time, SCN or Sequence # specified for the recovery)

•

Determines if there is sufficient space on the target host to create the auxiliary instance

that will be used during the table recovery process

•

If the required space is not available, then RMAN displays an error and exits the recovery

operation – new in 12.2

•

Creates an auxiliary database on the target host and recovers the specified tables until

the specified point in time, into this auxiliary database

•

Specify also the location on the target host where the recovered data files are located in

the auxiliary instance

•

Creates a Data Pump export dump file that contains the recovered tables using the

auxiliary instance

•

Imports the Data Pump export dump file into the target instance

•

Optionally rename the recovered tables in the target database

R

E

C

O

V

E

R

T

A

B

L

E

RECOVER TABLE SCOTT.EMP

UNTIL TIME 'SYSDATE-1/24'

AUXILIARY DESTINATION ‘/u01/app/auxdb/'

DATAPUMP DESTINATION ‘/u01/app/export'

DUMP FILE 'emp.dmp’;

RECOVER TABLE DEMO.MYTABLES

OF PLUGGABLE DATABASE PDB1

UNTIL SCN 2861419

AUXILIARY DESTINATION '/home/oracle/auxdb’

;

RECOVER TABLE HR.DEPARTMENTS, SH.CHANNELS

UNTIL TIME 'SYSDATE – 1'

AUXILIARY DESTINATION '/tmp/auxdest'

REMAP TABLE hr.departments:example.new_departments, sh.channels:example.new_channels;

B

L

O

C

K

R

E

C

O

V

E

R

Y

•

Block corruption on a Primary database is automatically repaired by obtaining

good copies of blocks from standby database

•

Standby database must be open  (Read Only Active Standby)

•

Block corruption can be detected internally by database or manually by running

VALIDATE command

•

V$DATABASE_BLOCK_CORRUPTION view displays blocks marked corrupt by

database

•

RECOVER DATAFILE 8 BLOCK 28;

•

RECOVER CORRUPTION LIST;

R

e

s

t

o

r

i

n

g

t

h

e

S

P

F

I

L

E

•

Loss of SPFILE will not affect running instance

•

If instance is restarted then loss of SPFILE will cause failure of instance to start

•

If control file autobackup is configured, then server parameter file is backed up

whenever control file is backed up

•

If recovery catalog is not used then we need to provide the DBID

•

Inside RMAN RUN block issue SET DBID 123456789

•

First start a ‘dummy’ instance via RMAN command STARTUP FORCE NOMOUNT

•

Then restore parameter file to default location via RESTORE SPFILE FROM

AUTOBACKUP command in same RMAN RUN block

•

Shutdown and restart the database using the restored parameter file

R

e

s

t

o

r

i

n

g

t

h

e

C

o

n

t

r

o

l

F

i

l

e

•

If all copies of the current control file are lost or damaged, then restore a backup control

file and mount the instance in NOMOUNT mode

•

Control files are restored to the locations defined in the CONTROL_FILES initialization

parameter

•

Set the DBID if not using a recovery catalog

•

If not using a recovery catalog run RESTORE CONTROLFILE FROM AUTOBACKUP

command

•

Run the RECOVER command even if no data files have been restored

•

Recover the database until the last available archive log sequence

•

RESTORE DATABASE UNTIL SEQUENCE 12345;

•

RECOVER DATABASE UNTIL SEQUENCE 12345;

•

Open the database with RESETLOGS option

R

M

A

N

R

e

p

o

r

t

i

n

g

•

Identify what has or has not been backed up

•

Preview which backups will be restored in case a problem occurs

•

Determine if backups are obsolete and can be thus deleted to free up disk space

•

Historical information about backup jobs

•

RMAN stores metadata about every backup or restore operation in the database

control file as well as an optional recovery catalog location

•

Metadata history retention in the control file is limited by the parameter

CONTROL_FILE_RECORD_KEEP_TIME

•

Use LIST or REPORT command in RMAN

R

M

A

N

R

e

p

o

r

t

i

n

g

•

LIST BACKUP OF DATABASE SUMMARY

•

LIST BACKUP

•

LIST COPY OF DATABASE

•

LIST BACKUP BY FILE

•

LIST BACKUPSET <#>

•

REPORT SCHEMA

•

REPORT OBSOLETE

•

REPORT NEED BACKUP

B

a

c

k

u

p

R

e

p

o

s

i

t

o

r

y

M

a

i

n

t

e

n

a

n

c

e

•

Configure a fast recovery area

•

Configure a backup retention policy

•

Configure an archive log deletion policy

•

Issue the CROSSCHECK command at regular intervals especially if deleting files at

the operating system level outside RMAN

•

Run CATALOG command to add metadata not already available in the repository

•

Run DELETE command to remove obsoleted or expired backupsets or backup

pieces

Recovery Manager New Features

Oracle 12c Release 1 and Release 2

S

Y

S

B

A

C

K

U

P

P

r

i

v

i

l

e

g

e

•

Separation of duties

•

Less powerful than earlier SYSDBA privilege

•

Contains privileges related to backup administrative duties

•

Can shutdown, restart and even flashback the database

•

No SELECT ANY TABLE privilege

•

Has SELECT ANY DICTIONARY privilege

•

Cannot access application table data

B

a

c

k

u

p

M

u

l

t

i

t

e

n

a

n

t

C

o

n

t

a

i

n

e

r

D

a

t

a

b

a

s

e

s

•

Backup entire CDB and all associated PDBs via single BACKUP DATABASE

command

•

Or backup just the root container

•

Or backup individual pluggable databases

•

Or backup specific tablespaces in particular PDB’s

•

BACKUP DATABASE

•

BACKUP PLUGGABLE DATABASE pdb1, pdb2;

•

BACKUP TABLESPACE pdb1:users

F

l

a

s

h

b

a

c

k

P

l

u

g

g

a

b

l

e

D

a

t

a

b

a

s

e

•

Create restore points in pluggable databases

•

Flashback database is now supported for pluggable databases

•

Prior to 12.2, flashback database command was issued at CDB level which

impacted all pluggable databases

•

Now perform a Flashback Database operation for a single PDB without impacting

other PDBs in the container database (CDB)

•

FLASHBACK PLUGGABLE DATABASE pdb1 TO RESTORE POINT grp_pdb1;

•

FLASHBACK PLUGGABLE DATABASE my_pdb TO SCN 24368;

•

Requires Local Undo feature enabled

R

E

C

O

V

E

R

T

a

b

l

e

c

o

m

m

a

n

d

•

Recover one or more tables or table partitions to a specified point in time

without affecting the remaining database tables and objects

•

Alternative to TSPITR (Tablespace Point-in-time Recovery)

•

TSPITR moves all the objects in the tablespace to a specified point in time

•

Flashback Table is not possible because the point-in-time desired to recover the

table to is older than the undo which is available

•

Requires full backup of undo, SYSTEM, SYSAUX along with the tablespace that

contains the table or table partition

R

M

A

N

R

e

c

o

v

e

r

T

a

b

l

e

•

Creates an auxiliary database on the target host

•

Performs recovery of the specific tables or table partition until the required point

in time into the auxiliary database

•

Performs a Data Pump export which create a dump file that contains the rows of

the recovered tables or table partition

•

Imports the Data Pump export dump file into the target instance

•

New in 12.2 - RMAN checks if there is sufficient space on the target host to create

the auxiliary instance that is used during recovery

R

M

A

N

R

e

c

o

v

e

r

T

a

b

l

e

    RECOVER TABLE SCOTT.EMP

    UNTIL TIME 'SYSDATE-1'

    AUXILIARY DESTINATION ‘/u01/app/auxdb/'

    DATAPUMP DESTINATION ‘/u01/app/export'

    DUMP FILE 'emp.dmp’;

D

U

P

L

I

C

A

T

E

D

A

T

A

B

A

S

E

E

n

h

a

n

c

e

m

e

n

t

s

•

In earlier versions the use the RMAN DUPLICATE command created the  duplicate

database and then also opened it in RESETLOGS mode

•

Can now specify that the duplicate database must not be opened using

RESETLOGS after it is created

•

DUPLICATE DATABASE with NOOPEN clause can be used as part of an upgrade

procedure to create a pre-upgradeable copy

•

Issue STARTUP UPGRADE command and run upgrade scripts

A

c

t

i

v

e

D

a

t

a

b

a

s

e

D

u

p

l

i

c

a

t

i

o

n

I

m

p

r

o

v

e

m

e

n

t

s

•

Active database duplication does not require backups of the source database

•

Duplicates ‘live’ source database by copying database files to destination host

over the network to auxiliary instance

•

RMAN can copy the files as backup sets or image copies

•

 Prior to 12c it was ‘push-based’ using image copies

•

Now in 12c it is ‘pull-based’ using backup sets

•

Main duplication workload performed by auxiliary instance

A

c

t

i

v

e

D

a

t

a

b

a

s

e

D

u

p

l

i

c

a

t

i

o

n

I

m

p

r

o

v

e

m

e

n

t

s

•

Reduces resource utilization on source database for the duplication process

•

Backup sets preferred over image copies if there is a lot of unused blocks in

datafiles

•

Can use multi-section backup capability introduced in 12c to parallelize  the

duplication work

•

Can use compression as well as encryption while duplicating the database

•

DUPLICATE TARGET DATABASE to <DB NAME>  FROM ACTIVE DATABASE

command contains either the USING BACKUPSET, USING COMPRESSED

BACKUPSET, or SECTION SIZE

•

The number of auxiliary channels allocated is equal to or greater than the

number of target channels allocated

M

u

l

t

i

s

e

c

t

i

o

n

B

a

c

k

u

p

E

n

h

a

n

c

e

m

e

n

t

s

•

Support for Multisection full backups of databases and data files was introduced

in 11g

•

New in 12c is support for Multisection Incremental backups

•

Multisection incremental backups of level 1 or higher

•

Use the SECTION SIZE clause of the BACKUP command to create multisection

backups

•

The SECTION SIZE clause specifies the size of each backup section

•

BACKUP INCREMENTAL LEVEL 1 SECTION SIZE 100M DATAFILE 1;

•

New in Oracle 12c is multisection full backups that are stored as image copies

   BACKUP AS COPY SECTION SIZE 500M DATABASE;

T

r

a

n

s

p

o

r

t

i

n

g

d

a

t

a

w

i

t

h

R

M

A

N

•

Transport databases, data files and tablespaces across platforms

•

In earlier releases was performed using image copies

•

12c supports cross platform transportable backup sets

•

Reduced downtime for platform migrations of databases

•

Enables use of backupset compression and multisection

•

Cross-Platform transport of tablespaces using inconsistent backups

•

Tablespaces do not have to be in read-only mode

•

Tablespaces being transported are in read-write mode

•

ALLOW INCONSISTENT clause of BACKUP command

T

r

a

n

s

p

o

r

t

i

n

g

d

a

t

a

w

i

t

h

R

M

A

N

•

The first inconsistent backup is a level 0 incremental backup

•

Restore and recover inconsistent level 0 backup on the destination database

•

At this point in time these data files are referred to as foreign data files

•

Destination database is still in mount state

•

Take multiple additional (inconsistent) level 1 incremental backups

•

Restore and recover inconsistent level 1 backups on the destination database

T

r

a

n

s

p

o

r

t

i

n

g

d

a

t

a

w

i

t

h

R

M

A

N

•

Take a final incremental backup with tablespaces on source database now in

read-only mode

•

Create a dump file with the metadata

•

Import metadata on target database

•

Apply final incremental backup (consistent) on the target database

•

Open the target database

Thanks for attending!

Feedback please to:

prosolutions@gavinsoorma.com