Multitenant Backup and Recovery of A Con

Multitenant : Backup and Recovery of a Container Database
(CDB) and a Pluggable Database (PDB) in Oracle Database

12c Release 1 (12.1)
The multitenant option brings with it a number of changes to the way we approach backup and recovery.
This article provides a top-level view of what is available for basic backup and recovery of CDBs and
PDBs.
This article does not include any mention of Flashback Database or general RMAN new features, which
will be covered in a separate articles.
 RMAN Connections
 Backup
o Container Database (CDB) Backup
o Root Container Backup
o Pluggable Database (PDB) Backup
 Complete Recovery
o Tablespace and Datafile Backups
o Container Database (CDB) Complete Recovery
o Root Container Complete Recovery
o Pluggable Database (PDB) Complete Recovery
o Tablespace and Datafile Complete Recovery
 Point In Time Recovery (PITR)
o Container Database (CDB) Point In Time Recovery (PITR)
o Pluggable Database (PDB) Point In Time Recovery (PITR)
o Table Point In Time Recovery (PITR) in PDBs
Related articles.
 RMAN Table Point In Time Recovery (PITR) in Oracle Database 12c Release 1 (12.1)
 Multitenant : Flashback of a Container Database (CDB) in Oracle Database 12c Release 1 (12.1)
RMAN Connections
Unless stated otherwise, this article assumes connections to RMAN are using OS authentication. This
means you are connecting to the root container in the CDB with "AS SYSDBA" privilege.
$ export ORAENV_ASK=NO
$ export ORACLE_SID=cdb1
$ . oraenv
The Oracle base remains unchanged with value /u01/app/oracle
$ export ORAENV_ASK=YES
$ rman target=/
Recovery Manager: Release 12.1.0.1.0 - Production on Sun Dec 22 17:03:20 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
connected to target database: CDB1 (DBID=797615285)

RMAN>
When connecting to a PDB to perform backup and recovery operations, the RMAN connection will look
like the following. Notice the password prompt as no password was entered on the command line.
$ rman target=sys@pdb1
Recovery Manager: Release 12.1.0.1.0 - Production on Mon Dec 23 11:08:35 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
target database Password:

connected to target database: CDB1 (DBID=797615285)
RMAN>
Backup
Container Database (CDB) Backup
Backup of a Container Database (CDB) is essentially the same as a non-Container Database. The main
thing to remember is, by doing a full backup of the CDB you are also doing a full backup of all PDBs.
Connect to RMAN using OS authentication and take a full backup using the following command. This
means you are connecting to the root container with "AS SYSDBA" privilege.
$ rman target=/
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
A section of the output from the above backup command is shown below. Notice how the datafiles
associated with the CBD (cdb1) and all the PDBs (pdb1, pdb2, pdb$seed) are included in the backup.
Starting backup at 22-DEC-13

using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00003
name=/u01/app/oracle/oradata/cdb1/sysaux01.dbf
name=/u01/app/oracle/oradata/cdb1/system01.dbf
name=/u01/app/oracle/oradata/cdb1/undotbs01.dbf
name=/u01/app/oracle/oradata/cdb1/users01.dbf
channel ORA_DISK_1: starting piece 1 at 22-DEC-13
channel ORA_DISK_1: finished piece 1 at 22-DEC-13
piece
handle=/u01/app/oracle/fast_recovery_area/CDB1/backupset/2013_12_22/o1_mf_nnn
df_TAG20131222T163015_9cg4wr40_.bkp tag=TAG20131222T163015 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:15
name=/u01/app/oracle/oradata/cdb1/pdb1/sysaux01.dbf
name=/u01/app/oracle/oradata/cdb1/pdb1/system01.dbf
name=/u01/app/oracle/oradata/cdb1/pdb1/pdb1_users01.dbf
piece
handle=/u01/app/oracle/fast_recovery_area/CDB1/E45393F0DE5F1A8AE043D200A8C00D
FC/backupset/2013_12_22/o1_mf_nnndf_TAG20131222T163015_9cg4z3so_.bkp
tag=TAG20131222T163015 comment=NONE
name=/u01/app/oracle/oradata/pdb2/sysaux01.dbf
name=/u01/app/oracle/oradata/pdb2/system01.dbf
name=/u01/app/oracle/oradata/pdb2/pdb2_users01.dbf
piece
handle=/u01/app/oracle/fast_recovery_area/CDB1/E4B0CA84B47E6183E043D200A8C0A8
06/backupset/2013_12_22/o1_mf_nnndf_TAG20131222T163015_9cg50766_.bkp
name=/u01/app/oracle/oradata/cdb1/pdbseed/sysaux01.dbf
name=/u01/app/oracle/oradata/cdb1/pdbseed/system01.dbf
piece
handle=/u01/app/oracle/fast_recovery_area/CDB1/E453004B82C71772E043D200A8C08E
C5/backupset/2013_12_22/o1_mf_nnndf_TAG20131222T163015_9cg51bmg_.bkp
Finished backup at 22-DEC-13
Root Container Backup
A backup of the root container is a backup of the CDB, excluding any of the PDBs.
Connect to RMAN using OS authentication and backup the root container using the following command.
This means you are connecting to the root container with "AS SYSDBA" privilege.
$ rman target=/
RMAN> BACKUP DATABASE ROOT;
A section of the output from the above backup command is shown below. Notice how the datafiles
associated with the CBD (cdb1) are included, but all the PDBs (pdb1, pdb2, pdb$seed) are not included
in the backup.

name=/u01/app/oracle/oradata/cdb1/sysaux01.dbf
name=/u01/app/oracle/oradata/cdb1/system01.dbf
name=/u01/app/oracle/oradata/cdb1/undotbs01.dbf
name=/u01/app/oracle/oradata/cdb1/users01.dbf
piece
df_TAG20131223T112413_9cj7bxtg_.bkp tag=TAG20131223T112413 comment=NONE
Pluggable Database (PDB) Backup
There are two ways to back up pluggable databases. When connected to RMAN as the root container,
you can backup one or more PDBs using the following command.
$ rman target=/
RMAN> BACKUP PLUGGABLE DATABASE pdb1, pdb2;
You can see this includes the datafiles for both referenced PDBs.

piece
FC/backupset/2013_12_23/o1_mf_nnndf_TAG20131223T113119_9cj7r8lp_.bkp
name=/u01/app/oracle/oradata/pdb2/sysaux01.dbf
name=/u01/app/oracle/oradata/pdb2/system01.dbf
name=/u01/app/oracle/oradata/pdb2/pdb2_users01.dbf
piece
06/backupset/2013_12_23/o1_mf_nnndf_TAG20131223T113119_9cj7sfbx_.bkp
Alternatively, connect to a specific PDB and issue the following command.
RMAN> BACKUP DATABASE;
Being connected to the PDB, this limits the scope of the backup command to the current PDB only, as
shown in the output below.

using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=237 device type=DISK
piece
FC/backupset/2013_12_23/o1_mf_nnndf_TAG20131223T113504_9cj7z9kb_.bkp
Tablespace and Datafile Backups
Multiple PDBs in the same CDB can have a tablespace with the same name, for example SYSTEM,
SYSAUX and USERS, so tablespace backups must be performed when connected to the appropriate
PDB, to remove this ambiguity. Once RMAN is connected to the PDB, the tablespace backup commands
is unchanged compared to previous versions.
RMAN> BACKUP TABLESPACE system, sysaux, users;
Datafiles have unique file numbers and fully qualified names, so they can be backed up from the root
container or the individual PDB.
$ rman target=/
# Or
RMAN> BACKUP DATAFILE 8, 9, 10;
If you are connecting to a PDB, only the files belonging to that PDB can be backed up. So for example,
when connected as PDB1, we get an error if we try to backup the SYSTEM datafile from the root
container.
RMAN> BACKUP DATAFILE 1;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 12/23/2013 11:49:35
RMAN-20201: datafile not found in the recovery catalog
RMAN-06010: error while looking up datafile: 1
RMAN>
Complete Recovery
Container Database (CDB) Complete Recovery
Restoring a CDB is similar to restoring a non-CDB database, but remember restoring a whole CDB will
restore not only the root container, but all the PDBs also. Likewise a Point In Time Recovery (PITR) of the
whole CDB will bring all PDBs back to the same point in time.
Connect to RMAN using OS authentication and restore the whole CDB using the following restore script.
This means you are connecting to the root container with "AS SYSDBA" privilege.
$ rman target=/
RUN {
SHUTDOWN IMMEDIATE; # use abort if this fails
STARTUP MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;
}
A section of the output from the above restore script is shown below. Notice the datafiles from the CDB
(cdb1) and all the PDBs (pdb1, pdb2 and pdb$seed) are all considered during the restore. The seed PDB
is not actually restored because it is read-only and RMAN can see a restore is not necessary.
Starting restore at 22-DEC-13

skipping datafile 5; already restored to file

/u01/app/oracle/oradata/cdb1/pdbseed/system01.dbf
skipping datafile 7; already restored to file
/u01/app/oracle/oradata/cdb1/pdbseed/sysaux01.dbf
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to
/u01/app/oracle/oradata/cdb1/system01.dbf
/u01/app/oracle/oradata/cdb1/sysaux01.dbf
/u01/app/oracle/oradata/cdb1/undotbs01.dbf
/u01/app/oracle/oradata/cdb1/users01.dbf
channel ORA_DISK_1: reading from backup piece
/u01/app/oracle/fast_recovery_area/CDB1/backupset/2013_12_22/o1_mf_nnndf_TAG2
0131222T163015_9cg4wr40_.bkp
channel ORA_DISK_1: piece
df_TAG20131222T163015_9cg4wr40_.bkp tag=TAG20131222T163015
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:56
/u01/app/oracle/oradata/cdb1/pdb1/system01.dbf
/u01/app/oracle/oradata/cdb1/pdb1/sysaux01.dbf
/u01/app/oracle/oradata/cdb1/pdb1/pdb1_users01.dbf
/u01/app/oracle/fast_recovery_area/CDB1/E45393F0DE5F1A8AE043D200A8C00DFC/back
upset/2013_12_22/o1_mf_nnndf_TAG20131222T163015_9cg4z3so_.bkp
FC/backupset/2013_12_22/o1_mf_nnndf_TAG20131222T163015_9cg4z3so_.bkp
tag=TAG20131222T163015
/u01/app/oracle/oradata/pdb2/system01.dbf
/u01/app/oracle/oradata/pdb2/sysaux01.dbf
/u01/app/oracle/oradata/pdb2/pdb2_users01.dbf
/u01/app/oracle/fast_recovery_area/CDB1/E4B0CA84B47E6183E043D200A8C0A806/back
upset/2013_12_22/o1_mf_nnndf_TAG20131222T163015_9cg50766_.bkp
06/backupset/2013_12_22/o1_mf_nnndf_TAG20131222T163015_9cg50766_.bkp
tag=TAG20131222T163015
Finished restore at 22-DEC-13
Starting recover at 22-DEC-13

starting media recovery

media recovery complete, elapsed time: 00:00:10
Finished recover at 22-DEC-13
Statement processed
Root Container Complete Recovery
Rather than recovering the whole CDB, including all PDBs, the root container can be recovered in
isolation.
Connect to RMAN using OS authentication and restore the root container using the following restore
script. This means you are connecting to the root container with "AS SYSDBA" privilege.
$ rman target=/
RUN {
STARTUP MOUNT;
RESTORE DATABASE ROOT;
RECOVER DATABASE ROOT;
# Consider recovering PDBs before opening.
ALTER DATABASE OPEN;
}
The following section of the output from the restore script shows only the root container datafiles are
restored and recovered.
Starting restore at 23-DEC-13


/u01/app/oracle/oradata/cdb1/system01.dbf
/u01/app/oracle/oradata/cdb1/sysaux01.dbf
/u01/app/oracle/oradata/cdb1/undotbs01.dbf
/u01/app/oracle/oradata/cdb1/users01.dbf
/u01/app/oracle/fast_recovery_area/CDB1/backupset/2013_12_23/o1_mf_nnndf_TAG2
0131223T112413_9cj7bxtg_.bkp
df_TAG20131223T112413_9cj7bxtg_.bkp tag=TAG20131223T112413
Finished restore at 23-DEC-13
Starting recover at 23-DEC-13

starting media recovery

media recovery complete, elapsed time: 00:00:04
Finished recover at 23-DEC-13
It is probably a very bad idea to restore and recover just the root container without doing the same for the
PDBs. Any difference in metadata between the two could prove problematic.
Pluggable Database (PDB) Complete Recovery
There are two ways to restore and recover PDBs. From to root containers, you can restore and recover
one or more PDBs using the following script.
$ rman target=/
RUN {
ALTER PLUGGABLE DATABASE pdb1, pdb2 CLOSE;
RESTORE PLUGGABLE DATABASE pdb1, pdb2;
RECOVER PLUGGABLE DATABASE pdb1, pdb2;
ALTER PLUGGABLE DATABASE pdb1, pdb2 OPEN;
}
When connected directly to a PDB, you can restore and recover the current PDB using a local user with
the SYSDBA privilege, as shown in the following script.
$ sqlplus sys@pdb1 as sysdba
CREATE USER admin_user IDENTIFIED BY admin_user;

GRANT CREATE SESSION, PDB_DBA, SYSDBA TO admin_user;
EXIT;
$ rman target=admin_user@pdb1
SHUTDOWN IMMEDIATE;
RESTORE DATABASE;
RECOVER DATABASE;
STARTUP;
Note. In the current release, the RMAN commands will not work in a "run" script without producing errors.
Tablespace and Datafile Complete Recovery
Due to potential name clashes, restoring a tablespace must be done while connected to the PDB.
RUN {
ALTER TABLESPACE users OFFLINE;
RESTORE TABLESPACE users;
RECOVER TABLESPACE users;
ALTER TABLESPACE users ONLINE;
}
Datafile recoveries can be done while connected to the container or directly to the PDB.
$ rman target=/
# Or
RUN {
ALTER DATABASE DATAFILE 10 OFFLINE;
RESTORE DATAFILE 10;
RECOVER DATAFILE 10;
ALTER DATABASE DATAFILE 10 ONLINE;
}
Point In Time Recovery (PITR)
Container Database (CDB) Point In Time Recovery (PITR)

Point In Time Recovery (PITR) of a CDB is the same as that of non-CDB instances. Just remember, you
are performing a PITR on the CDB and all the PDBs at once.
$ rman target=/
RUN {
STARTUP MOUNT;
SET UNTIL TIME "TO_DATE('23-DEC-2013 12:00:00','DD-MON-YYYY HH24:MI:SS')";
RESTORE DATABASE;
RECOVER DATABASE;
# Should probably open read-only and check it out first.
ALTER DATABASE OPEN RESETLOGS;
}
Pluggable Database (PDB) Point In Time Recovery (PITR)
Point In Time Recovery (PITR) of a PDB follows a similar pattern to that of a regular database. The PDB
is closed, restored and recovered to the required point in time, then opened with the RESETLOGS option.
In this case, the RESETLOGS option does nothing with the logfiles themselves, but creates a new PDB
incarnation.
$ rman target=/
RUN {
ALTER PLUGGABLE DATABASE pdb1 CLOSE;
SET UNTIL TIME "TO_DATE('23-DEC-2013 12:00:00','DD-MON-YYYY HH24:MI:SS')";
RESTORE PLUGGABLE DATABASE pdb1;
RECOVER PLUGGABLE DATABASE pdb1;
ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;
}
The simplicity of PITR of PDBs hides a certain amount of complexity. For a start, a PDB shares the root
container with other PDBs, so a PITR of the root container must be performed. This is done in the fast
recovery area (FRA) provided it is configured. If the FRA is not configured, an AUXILIARY
DESTINATION must be specified.
Aside from the FRA space requirement, one other important restriction is relevant. If a point in time
recovery of a PDB has been done, it is not possible to directly flashback the database to a time before the
PDB point in time recovery. The workaround for this is discussed in this article.
Table Point In Time Recovery (PITR) in PDBs
Oracle 12c includes a new RMAN feature which performs point in time recovery of tables using a single
command. You can read about this feature and see examples of it's use in the following article.
 RMAN Table Point In Time Recovery (PITR) in Oracle Database 12c Release 1 (12.1)
The same mechanism is available for recovering tables in PDBs, with a few minor changes. For the
feature to work with a PDB, you must log in as a root user with SYSDBA or SYSBACKUP privilege.
$ rman target=/
Issue the RECOVER TABLE command in a similar way to that shown for a non-CDB database, but include
the OF PLUGGABLE DATABASE clause, as well as giving a suitable AUXILIARY DESTINATION location
for the auxiliary database. The following command also uses the REMAP TABLE clause to give the
recovered table a new name.
RECOVER TABLE 'TEST'.'T1' OF PLUGGABLE DATABASE pdb1

UNTIL SCN 5695703
AUXILIARY DESTINATION '/u01/aux'
REMAP TABLE 'TEST'.'T1':'T1_PREV';
Alternatively, you can just stop at the point where the recovered table is in a data pump dump file, which
you can import manually at a later time. The following example uses the DATAPUMP DESTINATION,
DUMP FILE and NOTABLEIMPORT clauses to achieve this.
RECOVER TABLE 'TEST'.'T1' OF PLUGGABLE DATABASE pdb1

UNTIL SCN 5695703
AUXILIARY DESTINATION '/u01/aux'
DATAPUMP DESTINATION '/u01/export'
DUMP FILE 'test_t1_prev.dmp'
NOTABLEIMPORT;

Multitenant Backup and Recovery of A Con

Загружено:

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

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

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

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

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

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

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

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

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

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

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

Multitenant Backup and Recovery of A Con

Загружено:

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

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

Multitenant : Backup and Recovery of a Container Database

(CDB) and a Pluggable Database (PDB) in Oracle Database

connected to target database: CDB1 (DBID=797615285)

target database Password:

Container Database (CDB) Backup

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Starting backup at 22-DEC-13

Root Container Backup

RMAN> BACKUP DATABASE ROOT;

Starting backup at 23-DEC-13

Pluggable Database (PDB) Backup

RMAN> BACKUP PLUGGABLE DATABASE pdb1, pdb2;

Starting backup at 23-DEC-13

Alternatively, connect to a specific PDB and issue the following command.

RMAN> BACKUP DATABASE;

Starting backup at 23-DEC-13

Tablespace and Datafile Backups

RMAN> BACKUP TABLESPACE system, sysaux, users;

RMAN> BACKUP DATAFILE 8, 9, 10;

RMAN> BACKUP DATAFILE 1;

Starting backup at 23-DEC-13

Container Database (CDB) Complete Recovery

Starting restore at 22-DEC-13

skipping datafile 5; already restored to file

Starting recover at 22-DEC-13

starting media recovery

Finished recover at 22-DEC-13

Root Container Complete Recovery

Starting restore at 23-DEC-13

channel ORA_DISK_1: starting datafile backup set restore

Starting recover at 23-DEC-13

starting media recovery

Finished recover at 23-DEC-13

Pluggable Database (PDB) Complete Recovery

$ sqlplus sys@pdb1 as sysdba

CREATE USER admin_user IDENTIFIED BY admin_user;

Tablespace and Datafile Complete Recovery

Point In Time Recovery (PITR)

Container Database (CDB) Point In Time Recovery (PITR)

Pluggable Database (PDB) Point In Time Recovery (PITR)

Table Point In Time Recovery (PITR) in PDBs

RECOVER TABLE 'TEST'.'T1' OF PLUGGABLE DATABASE pdb1

RECOVER TABLE 'TEST'.'T1' OF PLUGGABLE DATABASE pdb1

Вам также может понравиться