Pluggable database (PDB) backup
steps
PDB COLD BACKUP STEPS: -
While
connected to the container database, execute the following command:
SQL >
Alter pluggable database PDBTEST close immediate.
After that, you can do a classic cold
backup:
[oracle@sujeet
~]$ rman target sys@local
Recovery
Manager: Release 12.1.0.1.0 - Production on Wed May 14 15:25:19 2014
Copyright
(c) 1982, 2013, Oracle and/or its affiliates.
All rights reserved.
target
database Password:
connected to target database: ORA12C
(DBID=214280212, not open)
RMAN> run
{
allocate
channel c0 device type disk format '/home/oracle/backup%U.bak';
backup
database;
}
Backup
and Recovery of a Container Database (CDB) and a Pluggable Database (PDB) in
Oracle Database 12c Release 1 (12.1)
RMAN Connections
Backup
Container Database (CDB) Backup
Root Container Backup
Pluggable Database (PDB) Backup
Complete Recovery
Tablespace and Datafile Backups
Container Database (CDB) Complete
Recovery
Root Container Complete Recovery
Pluggable Database (PDB) Complete
Recovery
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
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: backup set complete, elapsed time: 00:00:36
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.
Starting
backup at 23-DEC-13
using
channel ORA_DISK_1
Finished
backup at 23-DEC-13
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.
Starting
backup at 23-DEC-13
using
channel ORA_DISK_1
channel
ORA_DISK_1: backup set complete, elapsed time: 00:00:35
Finished
backup at 23-DEC-13
Alternatively,
connect to a specific PDB and issue the following command.
$ rman
target=sys@pdb1
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.
Starting
backup at 23-DEC-13
using target
database control file instead of recovery catalog
allocated
channel: ORA_DISK_1
channel
ORA_DISK_1: backup set complete, elapsed time: 00:00:25
Finished
backup at 23-DEC-13
Tablespace
and Datafile Backups
Multiple PDBs
in the same CDB can have a tablespace with the same name, for example SYSTEM,
SYSAUX and USERS.
One way to
remove that ambiguity is connect to the appropriate PDB. Once RMAN is connected
to the PDB,
the
tablespace backup commands is unchanged compared to previous versions.
$ rman
target=sys@pdb1
RMAN>
BACKUP TABLESPACE system, sysaux, users;
Alternatively,
you can remove the ambiguity by qualifying the PDB name with the tablespace
name when connected to the root container.
$ rman
target=sys@cdb1
RMAN>
BACKUP TABLESPACE pdb1:system, pdb1:sysaux, pdb1:users, pdb2:system;
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
target=sys@pdb1
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;
Starting
backup at 23-DEC-13
using
channel ORA_DISK_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
allocated
channel: ORA_DISK_1
channel
ORA_DISK_1: SID=11 device type=DISK
channel
ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished
restore at 22-DEC-13
Starting
recover at 22-DEC-13
using
channel ORA_DISK_1
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 {
SHUTDOWN IMMEDIATE; # use abort if this fails
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
allocated
channel: ORA_DISK_1
channel
ORA_DISK_1: restore complete, elapsed time: 00:01:26
Finished
restore at 23-DEC-13
Starting
recover at 23-DEC-13
using
channel ORA_DISK_1
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;
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.
$ rman
target=sys@pdb1
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
$ rman
target=sys@pdb1
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 {
SHUTDOWN IMMEDIATE; # use abort if this fails
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 its 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;
Reference link: -
No comments:
Post a Comment