RMAN, new configuration parameters in 11g

Configuration parameters define the overall environmental behavior of rman. You can set these parameters to automate things as well as define bevaviors with repect to different commands. In 11g there are two new parameters which are basically two new features. You can use the following command to list all configuration parameters with their default values.

RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
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 ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_orcl.f'; # default

I have highlighted both the new parameters. First one, as you may have guessed RMAN now allows you to compress the backup sets generated via rman. The configuration allows you to set the default compression algorithm which you want to use while taking backups. By default it is set to basic which you can change depending on your requirement. To see the list of algorithms available you can use the following command. Note the description column which states which algorithm is suited for what situations.

SQL> select algorithm_name,algorithm_description,is_default
  2  from V$RMAN_COMPRESSION_ALGORITHM;
ALGORITHM_NAME       ALGORITHM_DESCRIPTION  IS_
------------------------------ -------------------------------------------------- ---
BZIP2       good compression ratio  NO
BASIC       good compression ratio  YES
LOW       maximum possible compression speed  NO
ZLIB       balance between speed and compression ratio  NO
MEDIUM       balance between speed and compression ratio  NO
HIGH       maximum possible compression ratio  NO

6 rows selected.

You can change the value of parameter using the following command.

RMAN> configure compression algorithm "low";
new RMAN configuration parameters:
CONFIGURE COMPRESSION ALGORITHM 'low' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;
new RMAN configuration parameters are successfully stored
RMAN> 

The other parameter allows you to set the archivelog deletion policy. As name suggests that this setting when set will cause automatic deletion of archivelogs. This is a very handsome feature in itself and will require another post for full details.

Enough to state is that you can set policy like delete archivelogs after two backups. RMAN will delete archive logs which have been backed up twice. 

Difference between normal and standby database duplication

RMAN is a wonderful tool and has gone distances from being just another backup and recovery option. It simplifies a lot of things and has a lot of role to play in technologies like RAC, Data Guard etc. 

To setup a data guard environment the first thing you need is the another copy of your production database. RMAN duplication is the best way to get this done.

However normal duplication is not what you require. As you are using duplication for a standby database which means that your end database will still be dependent on your production database. This requires changes in how database is structured. As database structure will be different, so will be the control file. You can create a copy of control file for standby, backup it and register with RMAN so that RMAN can use it using one single command.

RMAN> backup current controlfile for standby;

Once you are done with that you can do all other things like creating pfile, instantiating instance and creating directories etc like you would do for normal duplication. Your target database will be your primary instance and auxiliary database will be your standby instance. Connect to both of them and issue the following command to start the duplication process.

RMAN> duplicate target database for standby dorecover;

The above command will duplicate database, recover it to the latest SCN and then will bring it up in mounnt state. It will not open the database and neither it is required because nature of database will be standby. 

DBCA could not detect the database

If you have created the database manually or you have duplicated the database using RMAN duplication, you may have encountered this error. Apparently there won't be any errors anyway. You will be able to connect to your database using SQL*PLUS or any other client tool and perform all the normal operations. But DBCA and other graphical tools like DBUA won't be able to detect that database exists.

Another problem caused by this is that you won't be able to configure database for EM control. Not appearing in DBCA also means that you cannot delete the database completely in one go and configure several other options. 

Enough problems....

But the reason and solution is simple. Every database not created using DBCA will not be registered in "oratab" file. The file is located in "/etc" folder and is used by database startup and shutdown scripts. But it is also used by GUI tools to locate what database services are running. So just add an entry for your database in the file and save it. Run the DBCA again and all will be OK.

Typical entry in /etc/oratab entry will look like the following.

ORCL:/u01/app/oracle/product/11.2.0/dbhome_1:N

RMAN, creating recovery catalog

Recovery catalog is oracle's recommendation to use with rman. If you don't use recovery catalog then all database backup/recovery related information will be stored inside the control file of your database. However it is strongly recommended that you use recovery catalog and take regular backups of catalog as well. Here is how you can create recovery catalog. The example assumes that you are creating recovery catalog schema inside your target database.

The process is simple. You will create a tablespace to hold catalog information, a user who will own the recovery catalog and then create the catalog while logging into that schema through rman client.

Here is the process in practice.  


SQL> create tablespace ts_catalog
  2  datafile '/u01/app/oracle/oradata/VSTDB01/catalog.dbf'
  3  size 100M
  4  autoextend on
  5  maxsize 400M;

Tablespace created.

SQL> create user rman identified by rman
  2  default tablespace ts_catalog;

User created.

SQL> grant connect,resource,recovery_catalog_owner to rman;

Grant succeeded.

$ rman catalog rman/rman@VSTDB01

Recovery Manager: Release 11.2.0.1.0 - Production on Sun Jan 20 13:57:58 2013

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

connected to recovery catalog database

RMAN> create catalog tablespace ts_catalog;

recovery catalog created

RMAN> connect target /

connected to target database: VSTDB01 (DBID=2542636510)

RMAN> register database;

database registered in recovery catalog

starting full resync of recovery catalog

full resync complete

RMAN connect to Auxiliary Fails With ORA-01031: INSUFFICIENT PRIVILEGES

If you are getting this error when you are trying to connect like this

$ rman auxiliary /

then it may be because your OS user is not added to either DBA or OINSTALL system groups. This is easy to resolve. But if you are getting this error while doing the below

$ rman auxiliary sys/oracle@AUX1

and you know that you have configured everything like Listener and TNSNAMES etc then the resolution is a bit tricky. The auxiliary database is mostly used when you are duplicating a database or something. There are situations where you must connect to your auxiliary database using service name like when you are duplicating from active database without any backup.

In these situations you can't change your password file using SQL*PLUS because database will be in no-mount state. Here is the two step solution.

1. Copy your target database's password file and rename it so that the instance names are replaced.
2. Make sure that instance and service names are same in the following locations and files. They must be same and at the same time all of them must be in UPPER case

Here are the locations where you need to verify and check the instance and service names.

• The db_name parameter in parameter file (init.ora)
• Instance name in Password file's name
• SID_NAME in Sid description section of Listener.ora
• Service name in tnsnames.ora entry

$ rman auxiliary sys/oracle@AUX1 

will work now.