Monday, March 30, 2020


ORA-28007: the password cannot be reused


SQL> SELECT USERNAME, PROFILE, ACCOUNT_STATUS FROM DBA_USERS;

SQL> alter user ifsapp profile default;

SQL> select RESOURCE_NAME,LIMIT from dba_profiles where PROFILE='DEFAULT' and           RESOURCE_NAME Like 'PASS%'

PASSWORD_LIFE_TIME
PASSWORD_REUSE_TIME
PASSWORD_REUSE_MAX
PASSWORD_VERIFY_FUNCTION
PASSWORD_LOCK_TIME
PASSWORD_GRACE_TIME

Change all the profile limit to unlimited including PASSWORD_VERIFY_FUNCTION which should be set to null.

SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME unlimited;

SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_REUSE_TIME unlimited;

SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_REUSE_MAX unlimited;

SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_GRACE_TIME unlimited;

SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL;

SQL> alter user ifsapp identified by SHLtst$123;





Monday, March 2, 2020

How to Restore Oracle Database using RMAN (with Examples)

So, it is essential for all admins to understand how to restore oracle database from backup.
Typically, DBAs will use Oracle RMAN utility to take a hot backup of the database.
This tutorial provides an introduction on how to restore an Oracle database from the RMAN backup.
If you are new to RMAN, you should first understand how to backup oracle database using RMAN.
For the impatient, here is a quick snippet of one particular rman restore scenario. Change this accordingly for your scenario. Read below to understand more details about these commands.
RMAN> SET DBID 12345;

RMAN> STARTUP NOMOUNT;

RMAN> RESTORE CONTROLFILE FROM "/backup/rman/ctl_c-12345-20141003-03"; 

RMAN> RESTORE DATABASE;

RMAN> RECOVER DATABASE;

RMAN> ALTER DATABASE OPEN RESETLOGS;

Verify Backup Location

Before the restore, verify the current RMAN configuration on the server where you’ll be performing the restore.
To connect to RMAN, execute the following rman command, which will take you to the RMAN> prompt. From here, you can execute all RMAN commands.
$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Mon Nov 17 11:17:11 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
connected to target database: DEVDB (DBID=821773)
RMAN>
Execute “show all”, which will display all current RMAN configuration. As you see below, the current RMAN backup is located under “/backup/rman” directory.
RMNAN> SHOW ALL;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/rman/ctl_%F';
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/data/rman-backup/full_%u_%s_%p' MAXPIECESIZE 4096 M;
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF;
CONFIGURE ENCRYPTION ALGORITHM 'AES128';
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/backup/rman/snapcf_med.f';
On a high-level, the following three steps are performed in recovering the database from RMAN backup.
  1. Restore controlfile from backup
  2. Restore the databse
  3. Recover the database
WARNING: Execute rman restore commands only on a test instance. If you try these restore commands in a production instance, and if something goes wrong, you’ll lose your production data.

Step 1: Restore ControlFile from Backup

First, you may want to restore the control file from the backup before you start the restore.
This step is required only if you are restoring the backup on a new server where the control file doesn’t exist. Or, if the control file on the system you are restoring is corrupted or missing.
RMAN> SET DBID 12345;

RMAN> STARTUP NOMOUNT;

RMAN> RESTORE CONTROLFILE FROM "/backup/rman/ctl_c-12345-20141003-03"; 

RMAN> ALTER DATABASE MOUNT;
Before you start the RMAN restore process, do the following:
  • Set the DBID. You can get the dbid from the name of the control file. This is the number that comes after “ctrl_c-” and the next hyphen. Please note that this depends on the controlfile format that was set on your system. Do a show all to view the format. For this example, the format was: “ctl_%F”
  • Startup the database in nomount option
  • Restore the controlfile form the backup. In this example, the RMAN backup is located under /backup/rman directory. Under this directory, you may have multiple control files. Based on the tiemstamp pick the appropriate one for which you have the full backup.
  • After restoring the control file, mount the database.
The following is an example output of the restore controlfile command:
Starting restore at 22-NOV-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=124 devtype=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/u01/oradata/devdb/control01.ctl
output filename=/u02/oradata/devdb/control02.ctl
output filename=/u03/oradata/devdb/control03.ctl
Finished restore at 22-NOV-14
When the RMAN backup was taken, if a tag was specified, you can also restore controlfile based a tag name as shown below.
RMNAN> RESTORE CONTROLFILE FROM TAG 'WEEKLY_FULL_BKUP';
You can also use the autobackup option to restore the controlfile as shown below:
RMNAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

Step 2: Restore the Database

To restore from the RMAN full backup that is located under the /backup/rman directory, execute the following command.
RMAN> RESTORE DATABASE;
Apart from the above straight forward restore database, there are also few variations of this command which are explained in the examples below. Use the one that is appropriate for your situation.
The following is a sample output of the above restore database command:
RMAN>
Starting restore at 22-NOV-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=125 devtype=DISK
...
channel ORA_DISK_2: starting datafile backupset restore
channel ORA_DISK_2: specifying datafile(s) to restore from backup set
restoring datafile 00020 to /u01/oradata/devdb/dev01_1.dbf
restoring datafile 00021 to /u02/oradata/devdb/report_data.dbf
restoring datafile 00022 to /u01/oradata/devdb/analytics01.dbf
channel ORA_DISK_2: reading from backup piece /backup/rman/full_32qakgmpa_123456_1
channel ORA_DISK_4: starting datafile backupset restore
....

Step 3: Recover Database (and ResetLogs)

If you’ve restored the controlfile from the backup, you need to perform this step.
In the last step, recover the database, and then you should open the database with resetlogs options as show below:
RMAN> RECOVER DATABASE;

RMAN> ALTER DATABASE OPEN RESETLOGS;

Restore Specific Tablespace

Instead of restoring the full database, you can also restore only specific tablespace as shown below.
The following will restore only the dev1 tablespace
RMNAN> RESTORE TABLESPACE dev1;
You can also restore more than one tablespace by separating them with commas as shown below. This will restore both dev1 and dev2 tablespace.
RMNAN> RESTORE TABLESPACE dev1, dev2;

Restore Specific Datafiles

You can also restore only a specific datafile from the backup using the restore datafile command as shown below.
The following will restore only the dev1_01.dbf datafile.
RMNAN> RESTORE DATAFILE '/u01/oradata/devdb/dev1_01.dbf'
You can also restore more than one datafile by separating them with commas as shown below. This will restore both dev1_01 and dev1_02 datafiles
RMNAN> RESTORE DATAFILE '/u01/oradata/devdb/dev1_01.dbf', '/u01/oradata/devdb/dev1_02.dbf'
Instead of the datafile name, you can also specify the datafile number.
RMNAN> RESTORE DATAFILE 34, 35
The datafile number (file_id) can be found in the dba_data_files table:
SQL> select file_id, file_name from dba_data_files
   FILE_ID FILE_NAME
---------- -------------------------------
        34 /u01/oradata/devdb/dev1_01.dbf
        35 /u01/oradata/devdb/dev1_02.dbf

Restore the Archived Redo Logs

The following will restore the archive logs to the default location.
RMNAN> RESTORE ARCHIVELOG ALL;
If you want to restore the archive logs to a new directory, do the following:
RMNAN> SET ARCHIVELOG DESTINATION TO '/home/arc_logs_new/';

RMNAN> RESTORE ARCHIVELOG ALL;
The following will restore only specific sequence number of the archive logs that are between 153 and 175.
RMNAN> RESTORE ARCHIVELOG FROM SEQUENCE 153 UNTIL SEQUENCE 175;
You can also restore archivelogs by specifying the starting point of the SCN number as shown below.
RMNAN> RESTORE ARCHIVELOG FROM SCN 56789;
Please note that when you issue the recover database as mentioned in the step 3 above, it will look for all required archive logs from the archive log destination and applies them to the oracle database datafiles.

Recover Specific Tablespace or Datafile

Similar to restoring specific tablespace and datafile, depending on the restore operation you did, perform the corresponding recover option. The following are few examples:
RMAN> RECOVER TABLESPACE dev1;
RMAN> RECOVER TABLESPACE dev1, dev2;
RMAN> RECOVER DATAFILE '/u01/oradata/devdb/dev1_01.dbf'
RMAN> RECOVER DATAFILE 34, 35
Note: You can also append “DELETE ARCHIVELOG” option to the recover command, which will delete the restored archive logs from the disk which are not required anymore. For example:
RMNAN> RECOVER TABLESPACE dev1 DELETE ARCHIVELOG;

Preview the Restore

Before restoring the database, if you like to view the details of all the backupsets that will be used along with the SCNs that are part of the backup file, you can append “PREVIEW” to any of the restore databse command. Please note that the preview output will be similar to the rman list summary command output.
This really doesn’t do the restore. This will only provide the report. You can use this before you restore the database.
RMAN> RESTORE DATABASE PREVIEW;
Pelase note that if the output of the above PREVIEW command is too detailed, and you need only the summary, you can execute the following PREVIEW SUMMARY.
RMAN> RESTORE DATABASE PREVIEW SUMMARY;
The following is the sample output of the above preview summary:
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
234587  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
234588  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
234589  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
234580  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
234581  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
..
The following are also valid preview option. You can append SUMMARY to all of the following commands:
RESTORE TABLESPACE dev1 PREVIEW;
RESTORE DATAFILE '/u01/oradata/devdb/dev1_01.dbf' PREVIEW;
RESTORE ARCHIVELOG ALL PREVIEW;
RESTORE ARCHIVELOG FROM SCN 234546 PREVIEW;

Validate the Backup Before Restore (Dry-run)

Before you perform the restore, you might want to really validate the backup to make sure that the backup itself is not corrupted, and all the file required to perform the backup is actually present in the backup directory.
RMAN> RESTORE DATABASE VALIDATE;
Depending on the size of the database this operation might take some time to complete. Technically, this is same as restoring the database except that this doesn’t do the real restore, and it performs only the Dry-run. The validate operation will really read all the blocks in the RMAN backup to make sure they are valid.
The following is a sample output of the restore validate command:
Starting restore at 22-NOV-14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=123 devtype=DISK
...
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_2: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /backup/rman/full_3abcde4po_123456_1
channel ORA_DISK_2: reading from backup piece /backup/rman/full_32qakgmpa_123456_1
channel ORA_DISK_1: restored backup piece 1
...
channel ORA_DISK_2: validation complete, elapsed time: 00:53:11
Finished restore at 22-NOV-14

RMAN Restore Common Error Messages

The following are some of the most common RMAN restore error messages:
Error 1: Start-up mount might give the following RMAN-04014 error:
RMAN> STARTUP NOMOUNT
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 10/03/2014 11:04:19
RMAN-04014: startup failed: ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 9925
Solution 1: Create the audit trial directory. Change the path to match your system.
mkdir -p $ORACLE_BASE/admin/devdb/adump
Error 2: Restore controlfile might give the following RMAN-00558, RMAN-01006, or RMAN-02001 error.
RMAN> RESTORE CONTROLFILE FROM /backup/rman/ctl_c-12345-20141003-03
RMAN-00558: error encountered while parsing input commands
RMAN-01006: error signaled during parse
RMAN-02001: unrecognized punctuation symbol "/"
Solution 2: Make sure to include the whole controlfile patch within quotes as shown below.
RMAN> RESTORE CONTROLFILE FROM "/backup/rman/ctl_c-12345-20141003-03"; 
Error 3: Restore controlfile (or restore database) might give the following RMAN-03002, ORA-19870, or ORA-27040 error along with “Linux-x86_64 Error: 2: No such file or directory”.
RMAN> RESTORE CONTROLFILE FROM "/backup/rman/ctl_c-12345-20141003-03"; 
RMAN-03002: failure of restore command at 10/03/2014 11:12:25
ORA-19870: error while restoring backup piece /backup/rman/ctl_c-12345-20141003-03
ORA-19504: failed to create file "/u01/oradata/devdb/control01.ctl"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory
Solution 3: In most cases it is missing directory. Create the appropriate directories accordingly. You might also get not found messsage for flash_recovery_area directory. So, create them both. Or, create whatever directory the above error message is complaining about.
mkdir -p $ORACLE_BASE/oradata/devdb
mkdir -p $ORACLE_BASE/flash_recovery_area/devdb/
Error 4: When you alter database open resetlogs, you might get the following ORA-01152 error message:
RMAN> ALTER DATABASE OPEN RESETLOGS;
ERROR at line 1:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/oradata/devdb/system01.dbf'
Solution 4: You can try couple of things. First, try to recover database until cancel as shown below. If that doesn’t help, remove the “UNTIL CANCEL” from the following command, and specify the redo log file, when it asks for “Specify log:” during the recover database command:
RMAN> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;

Wednesday, February 26, 2020



RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
When we are taking archive log backup with delete then got an error.
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/pac/lci9t1/arch/redo_1_16470_842608348.arc thread=1 sequence=16470
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/pac/lci9t1/arch/redo_1_16471_842608348.arc thread=1 sequence=16471
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

SOLUATION:

Cause: The archive logs seems that it is not yet applied in the standby database.
                        Select sequence# , applied from v$archived_log;

Action: Check the standby database and apply the logs manually and the start the deletion process.
              I can delete the archive logs by force using the below command.


      RMAN > delete noprompt force archivelog all;

But I don't want to delete the archives which are not applied in standby  so i'm changing the configuration
              
RMAN> show all;

Old configuration:
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

Change as Below:
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;

new RMAN configuration parameters:

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;

new RMAN configuration parameters are successfully stored

RMAN-08591: WARNING: invalid archived log deletion policy


Now check the configuration

RMAN> show all;

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;


Now I am able to delete those archivelogs now.


RMAN> delete noprompt archivelog all;

RMAN> crosscheck archivelog all;

Once I deleted those logs, I changed the rman configuration by the default one.


RMAN> CONFIGURE ARCHIVELOG DELETION POLICY CLEAR;
RMAN> Show all;

Tuesday, February 25, 2020

Recovery Manager (RMAN) Database Duplication Enhancements in Oracle Database 12c Release 1 (12.1)

The Recovery Manager (RMAN) DUPLICATE command has been available since at least Oracle 8i, allowing you perform backup-based duplications of database. Oracle 11g introduced the concept of active database duplicates, allowing database duplication without the need for additional backups. This article discusses the new functionality added to the DUPLICATE command in Oracle 12c.
Related articles.

Active Database Duplication using Backup Sets

In previous releases, active duplicates were performed using implicit image copy backups, transferred directly to the destination server. From 12.1 it is also possible to perform active duplicates using backup sets by including the USING BACKUPSET clause. Compared to image copy backups, the unused block compression associated with a backup set can greatly reduce the amount of data pulled across the network for databases containing lots of unused blocks. The example below performs an active duplicate of a source database (cdb1) to a new destination database (cdb2) using backup sets rather than image copy backups.
DUPLICATE DATABASE TO cdb2
  FROM ACTIVE DATABASE
  USING BACKUPSET
  SPFILE
    parameter_value_convert ('cdb1','cdb2')
    set db_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set log_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set audit_file_dest='/u01/app/oracle/admin/cdb2/adump'
    set core_dump_dest='/u01/app/oracle/admin/cdb2/cdump'
    set control_files='/u01/app/oracle/oradata/cdb2/control01.ctl','/u01/app/oracle/oradata/cdb2/control02.ctl','/u01/app/oracle/oradata/cdb2/control03.ctl'
    set db_name='cdb2'
  NOFILENAMECHECK;

Active Database Duplication using Compressed Backup Sets

In addition to conventional backup sets, active duplicates can also be performed using compressed backup sets by adding the USING COMPRESSED BACKUPSET clause, which further reduces the amount of data passing over the network. The example below performs an active duplicate of a source database (cdb1) to a new destination database (cdb2) using compressed backup sets.
DUPLICATE DATABASE TO cdb2
  FROM ACTIVE DATABASE
  USING COMPRESSED BACKUPSET
  SPFILE
    parameter_value_convert ('cdb1','cdb2')
    set db_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set log_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set audit_file_dest='/u01/app/oracle/admin/cdb2/adump'
    set core_dump_dest='/u01/app/oracle/admin/cdb2/cdump'
    set control_files='/u01/app/oracle/oradata/cdb2/control01.ctl','/u01/app/oracle/oradata/cdb2/control02.ctl','/u01/app/oracle/oradata/cdb2/control03.ctl'
    set db_name='cdb2'
  NOFILENAMECHECK;

Active Database Duplication and Encryption

 Always check the licensing implications of encryption before using it on a real system. Some encryption operations require the advanced security option.
Oracle allows backup sets to be encrypted. Transparent encryption uses a wallet to hold the encryption key and is seamless to the DBA, since backup sets are encrypted and decrypted as required using the wallet. Password encryption requires the DBA to enter a password for each backup and restore operation.
Since Oracle 12c now supports active duplicates using backup sets, it also supports encryption of those backup sets using both methods.
  • If the source database uses transparent encryption of backups, the wallet containing the encryption key must be made available on the destination database.
  • If password encryption is used on the source database, the SET ENCRYPTION ON IDENTIFIED BY <password> command can be used to define an encryption password for the active duplication process. If you are running in mixed mode, you can use SET ENCRYPTION ON IDENTIFIED BY <password> ONLY to override transparent encryption.
The encryption algorithm used by the active duplication can be set using the SET ENCRYPTION ALGORITHM command, where the possible algorithms can be displayed using the V$RMAN_ENCRYPTION_ALGORITHMS view. If the encryption algorithm is not set, the default (AES128) is used.
The example below performs an active duplicate of a source database (cdb1) to a new destination database (cdb2) using password encrypted backup sets.
SET ENCRYPTION ALGORITHM 'AES128';
SET ENCRYPTION ON IDENTIFIED BY MyPassword1 ONLY;

DUPLICATE DATABASE TO cdb2
  FROM ACTIVE DATABASE
  USING BACKUPSET
  SPFILE
    parameter_value_convert ('cdb1','cdb2')
    set db_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set log_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set audit_file_dest='/u01/app/oracle/admin/cdb2/adump'
    set core_dump_dest='/u01/app/oracle/admin/cdb2/cdump'
    set control_files='/u01/app/oracle/oradata/cdb2/control01.ctl','/u01/app/oracle/oradata/cdb2/control02.ctl','/u01/app/oracle/oradata/cdb2/control03.ctl'
    set db_name='cdb2'
  NOFILENAMECHECK;

Active Database Duplication and Parallelism (Multisection)

Active database duplications can take advantage of the multisection backup functionality introduced in Oracle 12c, whether using image copies or backup sets. Including the SECTION SIZE clause indicates multisection backups should be used.
There must be multiple channels available for multisection backups to work, so you will either need to configure persistent channel parallelism using CONFIGURE DEVICE TYPE ... PARALLELISM or use set the parallelism for the current operation by performing multiple ALLOCATE CHANNEL commands.
The example below performs an active duplicate of a source database (cdb1) to a new destination database (cdb2) using multisection backups.
CONFIGURE DEVICE TYPE disk PARALLELISM 4;

DUPLICATE DATABASE TO cdb2
  FROM ACTIVE DATABASE
  USING BACKUPSET
  SPFILE
    parameter_value_convert ('cdb1','cdb2')
    set db_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set log_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set audit_file_dest='/u01/app/oracle/admin/cdb2/adump'
    set core_dump_dest='/u01/app/oracle/admin/cdb2/cdump'
    set control_files='/u01/app/oracle/oradata/cdb2/control01.ctl','/u01/app/oracle/oradata/cdb2/control02.ctl','/u01/app/oracle/oradata/cdb2/control03.ctl'
    set db_name='cdb2'
  NOFILENAMECHECK
  SECTION SIZE 400M;

Multitenant Considerations

All the examples shown previously involve multitenant databases, but there are some extra considerations when you are using the multitenant architecture.
If you are building an "initSID.ora" file from scratch, you must remember to include the following parameter.
enable_pluggable_database=TRUE
The previous examples didn't have to do this as the SPFILE was created as a copy of the source SPFILE, which already contained this parameter setting.
The DUPLICATE command includes some additional clauses related to the multitenant option.
Adding the PLUGGABLE DATABASE clause allows you to specify which pluggable databases should be included in the duplication. The following example creates a new container database (cdb2), but it only contains two pluggable databases (pdb1 and pdb2). The third pluggable database (pdb3) is not included in the clone.
DUPLICATE DATABASE TO cdb2 PLUGGABLE DATABASE pdb1, pdb2
  FROM ACTIVE DATABASE
  SPFILE
    parameter_value_convert ('cdb1','cdb2')
    set db_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set log_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set audit_file_dest='/u01/app/oracle/admin/cdb2/adump'
    set core_dump_dest='/u01/app/oracle/admin/cdb2/cdump'
    set control_files='/u01/app/oracle/oradata/cdb2/control01.ctl','/u01/app/oracle/oradata/cdb2/control02.ctl','/u01/app/oracle/oradata/cdb2/control03.ctl'
    set db_name='cdb2'
  NOFILENAMECHECK;
The resulting clone contains the following PDBs.
SELECT name FROM v$pdbs;

NAME
------------------------------
PDB$SEED
PDB1
PDB2

SQL>
Using the SKIP PLUGGABLE DATABASE clause will create a duplicate CDB will all the PDBs except those in the list. The following example creates a container database (cdb2) with a single pluggable database (pdb3). The other two pluggable databases (pdb1 and pdb2) are excluded from the clone.
DUPLICATE DATABASE TO cdb2 SKIP PLUGGABLE DATABASE pdb1, pdb2
  FROM ACTIVE DATABASE
  SPFILE
    parameter_value_convert ('cdb1','cdb2')
    set db_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set log_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set audit_file_dest='/u01/app/oracle/admin/cdb2/adump'
    set core_dump_dest='/u01/app/oracle/admin/cdb2/cdump'
    set control_files='/u01/app/oracle/oradata/cdb2/control01.ctl','/u01/app/oracle/oradata/cdb2/control02.ctl','/u01/app/oracle/oradata/cdb2/control03.ctl'
    set db_name='cdb2'
  NOFILENAMECHECK;
The resulting clone contains the following PDBs.
SELECT name FROM v$pdbs;

NAME
------------------------------
PDB$SEED
PDB3

SQL>
You can also limit the tablespaces that are included in a PDB using the TABLESPACE clause. If we connect to the source container database (cdb1) and check the tablespaces in the pdb1 pluggable database we see the following.
CONN sys/Password1@cdb1 AS SYSDBA
ALTER SESSION SET CONTAINER = pdb1;

SELECT tablespace_name FROM dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
TEMP
USERS
TEST_TS

SQL>
Next, we perform a duplicate for the whole of the pdb2 pluggable database, but just the TEST_TS tablespace in the the pdb1 pluggable database.
DUPLICATE DATABASE TO cdb2 PLUGGABLE DATABASE pdb2 TABLESPACE pdb1:test_ts
  FROM ACTIVE DATABASE
  SPFILE
    parameter_value_convert ('cdb1','cdb2')
    set db_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set log_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set audit_file_dest='/u01/app/oracle/admin/cdb2/adump'
    set core_dump_dest='/u01/app/oracle/admin/cdb2/cdump'
    set control_files='/u01/app/oracle/oradata/cdb2/control01.ctl','/u01/app/oracle/oradata/cdb2/control02.ctl','/u01/app/oracle/oradata/cdb2/control03.ctl'
    set db_name='cdb2'
  NOFILENAMECHECK;
Checking the completed clone reveals both the pdb1 and pdb2 pluggable databases are present, but the pdb1 pluggable database does not include the USERS tablespace.
CONN sys/Password1@cdb2 AS SYSDBA

SELECT name FROM v$pdbs;

NAME
------------------------------
PDB$SEED
PDB1
PDB2

SQL>

ALTER SESSION SET CONTAINER = pdb1;

SELECT tablespace_name FROM dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
TEMP
TEST_TS

SQL>
Clones always contains a fully functional CDB and functional PDBs. Even when we just ask for the TEST_TS tablespace in pdb1, we also get the SYSTEM, SYSAUX and TEMP tablespaces in the PDB. The TABLESPACE clause can be used on it's own without the PLUGGABLE DATABASE clause, if no full PDBs are to be duplicated.
The SKIP TABLESPACE clause allows you to exclude specific tablespaces, rather than use the inclusion approach. The following example clones all the pluggable databases, but excludes the TEST_TS tablespace from pdb1 during the duplicate.
DUPLICATE DATABASE TO cdb2 SKIP TABLESPACE pdb1:test_ts
  FROM ACTIVE DATABASE
  SPFILE
    parameter_value_convert ('cdb1','cdb2')
    set db_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set log_file_name_convert='/u01/app/oracle/oradata/cdb1/','/u01/app/oracle/oradata/cdb2/'
    set audit_file_dest='/u01/app/oracle/admin/cdb2/adump'
    set core_dump_dest='/u01/app/oracle/admin/cdb2/cdump'
    set control_files='/u01/app/oracle/oradata/cdb2/control01.ctl','/u01/app/oracle/oradata/cdb2/control02.ctl','/u01/app/oracle/oradata/cdb2/control03.ctl'
    set db_name='cdb2'
  NOFILENAMECHECK;
Not surprisingly, the resulting clone contains all the pluggable databases, but the pdb1 pluggable database is missing the TEST_TS tablespace.
CONN sys/Password1@cdb2 AS SYSDBA

SELECT name FROM v$pdbs;

NAME
------------------------------
PDB$SEED
PDB1
PDB2
PDB3

SQL>

ALTER SESSION SET CONTAINER = pdb1;

SELECT tablespace_name FROM dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
TEMP
USERS

SQL>

Appendix

The examples in this article are based on the following assumptions.
  • The source database is a container database (cdb1), with three pluggable databases (pdb1, pdb2 and pdb3).
  • The destination database is called cdb2.
  • Both the source and destination databases use file system storage and do not use Oracle Managed Files (OMF), hence the need for the file name conversions.
  • The basic setup for active duplicates was performed using the same process described for 11g here.
Between every test the following clean-up was performed.
# Set the paths using the source DB.
export ORAENV_ASK=NO
export ORACLE_SID=cdb1
. oraenv
export ORAENV_ASK=YES

# Set the SID for the new clone (destination).
export ORACLE_SID=cdb2

# Stop the clone if it already exists.
sqlplus / as sysdba <<EOF
SHUTDOWN IMMEDIATE;
EXIT;
EOF

# Cleanup any previous clone attemps.
mkdir -p /u01/app/oracle/admin/cdb2/adump
mkdir -p /u01/app/oracle/admin/cdb2/cdump
mkdir -p /u01/app/oracle/oradata/cdb2/
rm -Rf /u01/app/oracle/oradata/cdb2/*
mkdir -p /u01/app/oracle/oradata/cdb2/pdbseed/
mkdir -p /u01/app/oracle/oradata/cdb2/pdb1/
mkdir -p /u01/app/oracle/oradata/cdb2/pdb2/
mkdir -p /u01/app/oracle/oradata/cdb2/pdb3/
rm $ORACLE_HOME/dbs/spfilecdb2.ora
rm $ORACLE_HOME/dbs/initcdb2.ora
rm $ORACLE_HOME/dbs/orapwcdb2

# Recreate an init.ora and password file.
echo "db_name=cdb2" > $ORACLE_HOME/dbs/initcdb2.ora
orapwd file=/u01/app/oracle/product/12.1.0.2/db_1/dbs/orapwcdb2 password=Password1 entries=10

# Mount the clone (auxiliary).
sqlplus / as sysdba <<EOF
STARTUP NOMOUNT;
EXIT;
EOF

# Connect to the target and auxiliary RMAN using the tsnnames.ora entry.
rman target sys/Password1@cdb1 auxiliary sys/Password1@cdb2

At this point the relevant RMAN DUPLICATE command was run.

 RMAN Recovery Catalog About Recovery Catalog RMAN recovery catalog Is another database which is out of your normal databases or which is o...