Wednesday, November 2, 2011

Rman encryption and other techniques

Today I will demonstrate Recovery Manager features, especially encryption and some other techniques.

First of all let me note about RMAN backup encryption. Staring from Oracle 10g RMAN now creates encrypted backups that cannot be restored by unauthorized people.
There are 3 modes of backup encryption:

* Transparent encryption
* Password encryption
* Dual-mode encryption using either transparent or password encryption

All RMAN backups are not encrypted but you can encrypt any RMAN backup in the form of a backup set.
In this tutorial I will show you how to configure Password encryption.


Let`s finish talking and start to demonstrate.


check parameters with "SHOW ALL" command, by default encryption is OFF

RMAN> show all;

RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
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 ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/home/oracle/oracle/product/10.2.0/db_1/dbs/snapcf_mydb.f'; # default

RMAN>


Here I choosed on tablespace for encryotion, for example : Users tablespace;
But you can encrypt entire database too: CONFIGURE ENCRYPTION FOR DATABASE OFF; # default




 Now, take users tablespaces`s backup and restore it



So, now check this encryption while restore

For simulate we can drop datafile of tablespace or just take tablespace offline. In this example I will use second option.


Upssssssssss, exception, it is impossible!

there are several RMAN and ORA exceptions.

So, we need to decrypt it.


Yes, as you see, successfully restored.

Now, recover it and bring tablespace to online



Check tablespace`s status

An other tutorial is about Skipping Tablespaces when Backing Up a Database and Limiting the Size of Backup Pieces

I have created several tablespaces with seeral statuses. You can see it above screen shot.
We can exclude offline and readonly tablespaces while backing up.

To back up the database while skipping offline and read-only tablespaces, you can run the following command:

RMAN> BACKUP DATABASE
        SKIP READONLY
        SKIP OFFLINE;

Another way to persistently skip tablespaces across RMAN sessions is to issue the CONFIGURE EXCLUDE command for each tablespace that you always want to skip.
For example, you may always want to skip the example tablespace, which has been made read-only. You can then issue:


Then, whenever you run BACKUP DATABASE, RMAN skips this tablespace.
You do not have to specify a SKIP clause on the BACKUP command.
You can override this behavior and include the example tablespace as follows:

RMAN> BACKUP DATABASE NOEXCLUDE;

That`s all.


As source please refer to:
http://mohamedazar.com
http://download.oracle.com/docs/cd/B19306_01/server.102/b14214/chapter1.htm
http://download.oracle.com/docs/cd/B12037_01/server.101/b10734/rcmbackp.htm

4 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Hi Ulfet,
    Do we need to set a Password for this encryption of tablespace/database ?
    Also does it require any Oracle licensing to do RMAN backup encryption.

    ReplyDelete
  3. Hi Ulfet,
    Do we need to set a Password for this encryption of tablespace/database ?
    Also does it require any Oracle licensing to do RMAN backup encryption.

    ReplyDelete

Cannot access dba_directories inside procedure

 Recently I faced one of familiar Oracle error ORA -00942 : table or view does not exist   I got it in while compiling procedure, becaus...