Backing Up Archived Logs Needed To Recover An Online Backup

Backing Up Archived Logs Needed to Recover an Online Backup
Suppose you are taking your database backup while it is open. And users are doing normal activities on
it. Now, you want to back up only those archived redo logs required to recover this online backup.
In this case you have two solutions.
1)The recommended solution is run the backup as,
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

2)You can also manually determine which archived logs are required and back them up, using the
following procedure.
i) In SQL*plus archive all unarchived logs, including the current log:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
ii)Determine the log sequence number of the current redo log,

SQL> SELECT SEQUENCE# FROM V$LOG WHERE STATUS = 'CURRENT';
SEQUENCE#
----------
10
iii)Backup database with RMAN.
RMAN>BACKUP DATABASE;
iv)Archive all unarchived logs, including the current log.

RMAN>SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
v)Determine the log sequence number of the current redo log.
SQL> SELECT SEQUENCE# FROM V$LOG WHERE STATUS = 'CURRENT';

SEQUENCE#
----------
13
vi)Back up the logs beginning with the first sequence number that you queried, and ending with the last
sequence number minus 1.
RMAN>BACKUP ARCHIVELOG FROM SEQUENCE 10 UNTIL SEQUENCE 12;
Basic Steps of RMAN media Recovery

Step 1: Place the database in mount stage when you like to perform whole database recovery or open the
database and offline the specified tablespace offline when performing tablespace recovery.
Step 2: Use SET UNTIL clause to perform incomplete recovery, that is recovery terminated up to the
past time,SCN,restore point or log sequence number. Also you can use UNTIL clause with RESTORE
and RECOVER command to perform incomplete recovery.
Step 3: Restore the files with RESTORE command.
Step 4: Recover the data files with RECOVER command.
Step5: Place the database in open stage if you did operation in MOUNT stage , or make the intended
tablespace online if you placed tablespaces offline.
Backup Database in Noarchivelog mode
To take backup in noarchivelog mode you must aware of several things.
1)Don't skip any online tablespace to take backup. If you do exclude an online tablespace to take backup
then whenever you restore the backup that tablespace will be lost.
2)You must take a cold backup of your database while taking database backup. Cold backup means your
database will be either in mount stage or the instance will be not running.
In next steps I gave an example of how we can take incremental level 0 backup in noarchivelog mode.
1)See the current log mode and Shut down the database.
SQL> SELECT LOG_MODE FROM V$DATABASE;

LOG_MODE
------------
NOARCHIVELOG
SQL> SHUTDOWN IMMEDIATE
2)Connect to RMAN.
SQL> !rman target /
3)Mount the database.

RMAN> STARTUP MOUNT
4)Take incremental level 0 backup.

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE TAG 'LEVEL_0_BACKUP';
In this example a tag is assigned to level 0 incremental backup.
5)Open the database to use for all.

RMAN> ALTER DATABASE OPEN;
The situations which must undergo Media Recovery:
•You restore a backup of a datafile.
•You restore a backup control file (even if all datafiles are current).
•A datafile is taken offline (either by you or automatically by the database) without the OFFLINE
NORMAL option.
Condition for Media Recovery for a Data file:

•Database must not be open or the specific datafile must be offline, if database is open.
•The datafile that needs media recovery cannot be brought online until media recovery has been
completed.
•A database cannot be opened if any of the online datafiles needs media recovery.
Block Media Recovery with RMAN ORA-01578: ORA-01110:
Suppose in the alert.log, or trace files, or a media management interface you got the following output.
ORA-01578: ORACLE data block corrupted (file # 4, block # 45)

ORA-01110: data file 4: '/oradata2/users01.dbf'
In this case you can use the BLOCKRECOVER command to restore and recover individual datablocks
within a datafile. Here datafile 4 and block 45. You should keep in mind that if you want to
BLOCKRECOVER command you had to have a previous backup of the datafile or database.
Block media recovery is not useful in cases where the extent of data loss or corruption is not known; in
this case, use datafile recovery instead.
Suppose if I got above error message data block corrupted then I can use BLOCKRECOVER as
following,
1)$rman TARGET /
RMAN>BLOCKRECOVER DATAFILE 4 BLOCK 45;
2)If you want from backup set or image copy then use,
RMAN>BLOCKRECOVER DATAFILE 4 BLOCK 45 FROM BACKUPSET;

RMAN>BLOCKRECOVER DATAFILE 4 BLOCK 45 FROM IMAGECOPY;
3)From a Specified backup,
RMAN>BLOCKRECOVER DATAFILE 4 BLOCK 45 FROM TAG level0;
4)Limiting to a certain point,

RMAN>BLOCKRECOVER DATAFILE 4 BLOCK 45 RESTORE UNTIL 'SYSDATE-2';
RMAN>BLOCKRECOVER DATAFILE 4 BLOCK 45 RESTORE UNTIL SCN 1111;
Remember if you use UNTIL clasue then RMAN must perform more recovery on the blocks, and the
recovery phase must scan all logs for changes to the specified blocks.
Whenever you use BACKUP command to BACKUP your database or use BACKUP VALIDATE
command Use RMAN to Validate Backup the V$DATABASE_BLOCK_CORRUPTION view is
populated. Set MAXCORRUPT to continue backup or backup validate and thus continue populate the
V$DATABASE_BLOCK_CORRUPTION view.
If you want to recover all marked corrupt block in the V$DATABASE_BLOCK_CORRUPTION view
then just use,
BLOCKRECOVER CORRUPTION LIST RESTORE UNTIL TIME 'SYSDATE-2';

Use RMAN to Validate Before and After taking backup
If you want to verify whether there any physical or logical corruptions in database file before taking
backup you can use the VALIDATE option of the BACKUP command.When performing a BACKUP...
VALIDATE, RMAN reads the files to be backed up in their entirety, as it would during a real backup. It
does not, however, actually produce any backup sets or image copies.
If the backup validation discovers corrupt blocks, then RMAN updates the
V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions.
Also with RMAN RESTORE ... VALIDATE before restore database or any datafile you can verify
whether database can successfully restored or not.
An example:Before Performing Backup Check Any Physical or Logical Corruption:

SQL> !rman target /
Recovery Manager: Release 10.2.0.1.0 - Production on Wed Apr 23 17:15:24 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: DATA1 (DBID=2547250380)
RMAN> backup validate database;
Starting backup at 23-APR-08
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 23-APR-08
After Backup Check if they can be Restored Successfully Using Validate BackupSet
RMAN> validate backupset 4;
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece
/oracle/app/oracle/product/10.2.0/db_1/dbs/05jei8qh_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle/app/oracle/product/10.2.0/db_1/dbs/05jei8qh_1_1 tag=TAG20080423T165857
channel ORA_DISK_1: validation complete, elapsed time: 00:00:25
Using RESTORE .. VALIDATE

RMAN> restore database validate;
Starting restore at 23-APR-08
channel ORA_DISK_1: starting validation of datafile backupset
/oracle/app/oracle/product/10.2.0/db_1/dbs/0bjeiams_1_1
piece handle=/oracle/app/oracle/product/10.2.0/db_1/dbs/0bjeiams_1_1 tag=TAG20080423T173108
channel ORA_DISK_1: validation complete, elapsed time: 00:00:04
Finished restore at 23-APR-08
You can also validate single tablespace or datafile or any other like,
RMAN> restore datafile 1 validate;
RMAN> restore tablespace system validate;
RMAN> restore controlfile validate;
RMAN> restore spfile validate;
How to create recovery catalog and use it
Recovery Catalog Concepts:
Recovery catalog holds the RMAN repository information(i.e backup information) in a separate
database schema in addition to control files. Though you can use target database as a recovery catalog
database(The database where recovery catalog resides) but you will not do that because recovery catalog
must be protected in the event of the loss of target database.
Before proceed it is good to understand about recovery catalog that recovery catalog is nothing but a
schema that owns a list of tables. SYS user can't be owner of recovery catalog.
How to Create Recovery Catalog:
Creating a recovery catalog is a three steps process.They are,
A)Configure Recovery Catalog Database.

B)Create the Recovery Catalog owner.
C)Create Recovery Catalog itself.
A)Configure Recovery Catalog Database:

1)Choose any database to select as recovery catalog database rather than target database(where you will
perform backup).
2)Create a tablespace where recovery catalog information will be populated.

SQL> SELECT NAME,DBID FROM V$DATABASE;
NAME DBID
--------- ----------
ARJU 2869417476
SQL> CREATE TABLESPACE catalog_tbs DATAFILE '/oradata2/catalog01.dbf' SIZE 100M;

Tablespace created.
B)Create the Recovery Catalog owner.
1)Create a user in the recovery catalog database who actually owns the recovery catalog schema. Also
assign default tablespace catalog_tbs to this user.

NAME DBID
--------- ----------
ARJU 2869417476
SQL> CREATE USER catalog_user IDENTIFIED BY catalog_pwd TEMPORARY

TABLESPACE TEMP DEFAULT TABLESPACE catalog_tbs QUOTA UNLIMITED ON
catalog_tbs;
User created.
2)Grant the RECOVERY_CATALOG_OWNER role to the schema owner. This role provides the user
with all privileges required to maintain and query the recovery catalog.
SQL> GRANT RECOVERY_CATALOG_OWNER TO catalog_user;

Grant succeeded.
C)Create Recovery Catalog itself:
At this stage you have only a tablespace and a user in recovery catalog database. There is no objects in
the recovery catalog schema.
NAME DBID
--------- ----------
ARJU 2869417476
SQL> conn catalog_user/catalog_pwd

Connected.
SQL> select * from user_tables;

no rows selected
Now you have to populate tables in the schema. To do this,
1)Through RMAN connect to the database that will contain the catalog as the catalog owner.
SQL> !rman CATALOG catalog_user/catalog_pwd
Recovery Manager: Release 10.2.0.1.0 - Production on Wed May 7 05:51:44 2008

connected to recovery catalog database
2)Run the CREATE CATALOG command to create the catalog.
RMAN>CREATE CATALOG;
recovery catalog created
You can also create catalog in other tablespace like USERS if you specify that just like below,
RMAN>CREATE CATALOG TABLESPACE USERS;
In our example we created catalog tablespace catalog_tbs so our command will be,
RMAN>CREATE CATALOG TABLESPACE catalog_tbs;
3)Check the recovery catalog tables, objects, view, package etc.
SQL> SELECT COUNT(*) FROM USER_OBJECTS;

COUNT(*)
----------
195
Now the next step is how to use it. It is discussed in How to Use Recovery Catalog
How to Use Recovery Catalog
You have already created recovery catalog described in How to Create Recovery Catalog. Now you
want this recovery catalog for your target database.
To do so you have to follow the following steps.
1)-Make sure that the recovery catalog database is open,

-Connect RMAN to the target database and recovery catalog database.
For example in target Database dbase , you want to use recovery catalog created of ARJU database.
SQL> SELECT NAME, DBID FROM V$DATABASE;

NAME DBID
--------- ----------
DBASE 1509380669
SQL> !rman target / catalog

catalog_user/catalog_pwd@saturn:1521/ARJU.SATURN.ARJUBD.COM

connected to target database: DBASE (DBID=1509380669)
2)Register the target database in the connected recovery catalog:
By REGISTER DATABASE RMAN creates rows in the catalog tables to contain information about the
target database, then copies all pertinent data about the target database from the control file into the
catalog, synchronizing the catalog with the control file.
RMAN> REGISTER DATABASE;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
c)Be sure that you are in RECOVERY CATALOG schema.
Some commands need to be in recovery catalog schema like,

RMAN> report schema at time 'SYSDATE-1';
Report of database schema
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 470 SYSTEM YES /oradata2/data1/dbase/system01.dbf
2 25 UNDOTBS1 YES /oradata2/data1/dbase/undotbs01.dbf
3 240 SYSAUX YES /oradata2/data1/dbase/sysaux01.dbf
4 5 USERS YES /oradata2/data1/dbase/users01.dbf
Registering Multiple Databases in a Recovery Catalog
You can register multiple databases in a recovery catalog; that means you can keep multiple database
repository information in a single recovery catalog. But one restriction is each database DBID must be
different as RMAN distinguish one database from another by DBID.
So whenever you just copy one database with user managed copy or by RMAN restore and recover then
both database DBID is same. So they can't be register in same recovery catalog. In that case if you want
to do so you have to change DBID. The method of changing DBID is described here Change DBID.
Unregistering a Target Database from the Recovery Catalog

To unregister a target database from the recovery catalog, just follow the procedure.
1)Connect to Recovery Catalog database.
-bash-3.00$ rman target / CATALOG

2)issue UNREGISTER DATABASE command.
RMAN> UNREGISTER DATABASE;

database name is "DBASE" and DBID is 1509380669
Do you really want to unregister the database (enter YES or NO)? YES
database unregistered from the recovery catalog
But remember when a database is unregistered from the recovery catalog, all RMAN repository records
in the recovery catalog are lost. The database can be registered again, but the recovery catalog records
for that database are then based on the contents of the control file at the
time of re-registration. Records older than the CONTROLFILE_RECORD_KEEP_TIME setting in the
target database control file are lost.
Resynchronizing the Recovery Catalog

RMAN performs resynchronizations automatically as needed when you execute certain commands,
including BACKUP. If you want to manually resynchronize issue RESYNC CATALOG command. In
case of resynchronization RMAN compares the recovery catalog to either the current control file of the
target database or a backup control file and updates the recovery catalog with information that is missing
or changed.
RMAN> RESYNC CATALOG;

starting full resync of recovery catalog
full resync complete
How to exclude a tablespace from whole database backup
Everyday you take your backup whole database. Suppose in a tablespace the data don't change open or
the tablespace contains test data only. Then you might change will backup strategy of your database to
exclude certain tablespace. In order to exclude a tablespace you have to issue,
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE users;
Now if you backup your database by,
RMAN> BACKUP DATABASE;
then then RMAN backs up all tablespaces in the database except users tablespace.
You can see which tablespace is excluded from your backup strategy by issue,
RMAN> SHOW EXCLUDE;
In order to skip two tablespaces or more issue command in RMAN twice or more like,
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE DATA01;
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE DATA02;
Here tablespace DATA01, DATA02 will be excluded from backup.
You can override this exclusion feature by explicitly issuing keyword NOEXCLUDE in order to take
whole database backup.
RMAN>BACKUP DATABASE NOEXCLUDE;
You can disable the exclusion feature for users tablespace as follows:
RMAN>CONFIGURE EXCLUDE FOR TABLESPACE users CLEAR;
In order to skip READONLY and OFFLINE tablespace you can issue backup database command as,
RMAN>BACKUP DATABASE SKIP READONLY, SKIP OFFLINE;
Wednesday, August 27, 2008

How to restore an Spfile from autobackup older than 7 days
Whenever we issue in RMAN, RMAN> restore spfile from autobackup; then restoring from
autobackup stops at seven days and then it arises message channel ORA_DISK_1: no autobackup in 7
days found. For example,
RMAN> restore spfile from autobackup;

Starting restore at 31-AUG-08
channel ORA_DISK_1: looking for autobackup on day: 20080831

channel ORA_DISK_1: no autobackup in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/31/2008 01:31:12
RMAN-06172: no autobackup found or specified handle is not a valid copy or piece
Whenever you give RMAN to RESTORE SPFILE FROM AUTOBACKUP or RESTORE

CONTROLFILE FROM AUTOBACKUP, RMAN begins the search on the current day or on the day
specified with the SET UNTIL caluse. If no autobackup is found in the current or SET UNTIL day,
RMAN checks the previous day. In this way RMAN by default checks for 7 days autobackup from the
current or SET UNTIL day.
However if you want to extend your searching of autobackup more than 7 then you have to use
MAXDAYS option with the RESTORE command.
For example,
RMAN>restore spfile from autobackup maxdays 30;
or
RMAN>restore controlfile from autobackup maxdays 30;
In these cases autobackup searches will be performed up to 30 days from the current or SET UNTIL
day.
How to Restore spfile from backup

1.Connect to target Database with RMAN.
i)If you have lost your spfile while your database is running then,
RMAN>CONNECT TARGET /
ii)If your database is not up and you don't use recovery catalog then use,
RMAN>CONNECT TARGET /
RMAN>SET DBID 3386862614
2)Start the instance with dummy parameter file.

RMAN>STARTUP FORCE NOMOUNT
3)Restore server parameter file.

To restore in default location,
RMAN> RESTORE SPFILE FROM AUTOBACKUP;
To restore in another location,
RMAN> RESTORE SPFILE TO 'new_location' FROM AUTOBACKUP;
If you want to restore to a pfile then use,

RMAN> RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';
4)Start the instance.

RMAN>STARTUP;
How to Restore the Controlfile from Backup.
If you loss or if your all copies of control file is corrupted and if you have backup of your control file
then it is required to restore your control file from your backup.
Restore control file to default location:

----------------------------------------------
The default location is defined by CONTROL_FILES parameter of pfile/spfile. If you don't specify any
location while restoring your control file then the control file will be restored to the location set by
CONTROL_FILES parameter. TO determine DBID check http://arjudba.blogspot.com/2008/05/how-to-
discover-find-dbid.html

RMAN> RUN {
RESTORE CONTROLFILE FROM AUTOBACKUP;
}
Restore of the Control File from Control File Autobackup
-------------------------------------------------------------
If you are not using a recovery catalog, you must restore your control file from an autobackup. The
database must be in a NOMOUNT state. And you have to set DBID. RMAN uses the autobackup format
and DBID to determine where to find for the control file autobackup.

RMAN> RUN {
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE CONTROLFILE FROM AUTOBACKUP;
}
Restore of the Control File When Using a Flash Recovery Area

---------------------------------------------------------------------
Suppose you restored a backup of the control file. Now in that control file the backup information may
not updated/full. May be it contains only current backup information of that session while taking
backup. If you use flash recovery area then RMAN automatically catalog the backups in the flash
recovery area. As a result the restored control file has a complete and accurate record of all backups in
your flash recovery area and any other backups that were known to the control file at the time of the
backup.
Restoring a Control File When Using a Recovery Catalog

------------------------------------------------------------------
The recovery catalog contains a complete record of your backups, including backups of the control
file. Therefore, you do not have to specify your DBID or control file autobackup format.
Just use,
$rman TARGET / CATALOG catdb/catdb

RMAN> RESTORE CONTROLFILE;
Restore of the Control File From a Known Location

-----------------------------------------------------
If you know the backuppiece of controlfile or any copy then simply you can use,
RMAN> RESTORE CONTROLFILE from 'filename';
Restore of the Control File to a New Location

---------------------------------------------------
In prior cases RMAN restore the control file to the location specified by CONTROL_FILES parameter
of the spfile or pfile.
If you want to restore the control file to another location use,

RMAN>RESTORE CONTROLFILE TO 'give_here_new_location';
You can also change CONTROL_FILES parameter and then perform RESTORE CONTROLFILE to
change location.
Limitations When Using a Backup Control File

------------------------------------------------
After you restore your database using a backup control file, you must run RECOVER DATABASE and
perform an OPEN RESETLOGS on the database.
How to skip a tablespace for restore operation

Sometimes we want to restore full database except a certain tablespace. That is we need to skip a
tablespace for restore operation. May be that the tablespace only contains tempoarary data and hence not
useful for us. Or we are performing some database point in time recovery operation and we want to omit
a big tablespace as the tablespace does not contain data needed for our requirement. In this way we can
minimize our restore operation time.
With the RESTORE DATABASE command we perform all datafiles restore operation except those that
are offline or read-only.
Note that RESTORE DATABASE does not work same as BACKUP DATABASE. With command
BACKUP DATABASE, RMAN backs up datafiles along with controlfiles and spfile. But with
RESTORE COMMAND operation, RMAN only restores datafiles.
To omit a certain tablespace for restore operation use RESTORE DATABASE SKIP TABLESPACE
tablespace_name. Suppose I want to omit restore of indexed tablespace INDX01,INDX02 and
INDX01_16K . Then my restore command will be,
RMAN>RESTORE DATABASE SKIP TABLESPACE INDX01,INDX02,INDX01_16K;
If you specify SKIP FOREVER TABLESPACE, then RMAN specifies the DROP option of ALTER
DATABASE DATAFILE ... OFFLINE when taking the datafiles that belong to the tablespace offline
before the restore. The DROP option indicates that RMAN does not intend to recover these files and
intends to drop their tablespaces from the database after the database is opened again. In other words,
FOREVER indicates that RMAN never intends to do anything with the skipped tablespaces again.
Suppose you want to skip forever to restore tablespace EXAMPLE,INDX01 and INDX02 then your
command will be,
RMAN>RESTORE DATABASE SKIP FOREVER TABLESPACE EXAMPLE, INDX01,
INDX02;
How to Schedule or Automate Backup through Crontab
Schedule or Automate Backup is a needed thing almost in all environment. We can do automate or
scheduling tasks through two ways, one is DBMS_SCHEDULER packager which will be discusses in
another topic and another is OS scheduler. If you think about OS scheduler then on unix box use crontab
and on windows box use scheduling jobs.
In this topic I have shown how we can take automate backup through crontab tool.
To avoid error Verify that ORACLE_HOME is set properly error like as below
Message file RMAN.msb not found
Verify that ORACLE_HOME is set properly
set proper ORACLE_HOME and ORACLE_SID in your backup file.

So I created my backup_job.sh as below.
bash-3.00$ vi backup_job.sh
#!/bin/bash
export ORACLE_HOME=/oracle/app/oracle/product/10.2.0/db_1
export ORACLE_SID=dbase
/oracle/app/oracle/product/10.2.0/db_1/bin/rman target sys/a@neptune:1522/dbase
cmdfile=/oradata1/
backup/backup_job2.sh
If you don't set $ORACLE_HOME and don't give full path of rman then possibly in the output file you
get rman:not found error.
/oradata1/backup/backup_job.sh: rman: not found
In the script I provided full path of rman.
The actual backup script are in backup_job2.sh and from backup_job.sh it will be called through rman.
bash-3.00$ vi backup_job2.sh
backup database format '/oradata1/backup/%U';
If you don't make these script executable or don't change permission to 777 then you likely get error in
the output file as,
sh: /oradata1/backup/backup_job.sh: cannot execute
So change the permission as
bash-3.00$ chmod 777 backup_job.sh

bash-3.00$ chmod 777 backup_job2.sh
To write contents within crontab in vi editor issue,
bash-3.00$export EDITOR=vi
bash-3.00$ crontab -e
35 06 * * * /oradata1/backup/backup_job1.sh > /oradata1/backup/backupdata.log
By default cron jobs sends a email to the user account executing the cronjob. If this is not needed put the
following command At the end of the cron job line .
48 06 * * * /oradata1/backup/backup_job.sh > /oradata1/backup/backupdata.log 2>&1

Now I will discuss some aspects of cronjob.
Crontab Restrictions
-You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow.
-If that file does not exist, you can use crontab if your name does not appear in the file
/usr/lib/cron/cron.deny.
-If only cron.deny exists and is empty, all users can use crontab.
-If neither file exists, only the root user can use crontab.
-The allow/deny files consist of one user name per line.
Crontab Commands
Before invoking crontab use export EDITOR=vi ;to specify a editor to open crontab file.
Now open crontab as below
-crontab -e :Edit your crontab file, or create one if it doesn't already exist.
-crontab -l :Display your crontab file.
-crontab -r :Remove your crontab file.
-crontab -v :Display the last time you edited your crontab file. (This option is only available on a few
systems.)
Crontab syntax option

MINUTE HOUR DAY_OF_MONTH MONTH DAY_OF_WEEK USER COMMAND
for any field multiple value could assign, where they are separated by comma.
MINUTE accept value from 00 to 59

HOUR accept value from 00 to 23
DAY_OF_MONTH accept value from 01 to 31
MONTH accept value from 01 to 12
DAY_OF_WEEK accept value from 0 to 6 [0 for sunday, 1 for monday, ...]
--USER means that who will execute the command (optional/not common)
COMMAND the command for execution
Know how many database register in Recovery Catalog Views

All of the information that we can see in RMAN prompt by SHOW, LIST or REPORT command can
also be easily seen by query recovery catalog views. Recovery catalog views are prefixed by RC_.
Most of the catalog views have a corresponding dynamic performance view (or V$view) in the database
server. For example, RC_BACKUP_PIECE corresponds to V$BACKUP_PIECE. The primary
difference between the recovery catalog view and corresponding server view is that each catalog view
contains information about all the databases registered in the catalog, whereas the database server
view contains information only about itself.
How to Find DB_KEY and DBID from Recovery Catalog View?

------------------------------------------------------------
SQL> conn catalog_user/catalog_pwd@netservice_name_of_recovery_catalog
Connected.
SQL> SELECT DB_KEY,DBID,NAME,RESETLOGS_TIME FROM RC_DATABASE;
DB_KEY DBID NAME RESETLOGS
---------- ---------- -------- ---------
88 1509380669 DBASE 06-MAY-08
Determining the Schema Version of the Recovery Catalog

------------------------------------------------------------
SQL> SELECT * FROM rcver;
VERSION
------------
10.02.00.00
You can query

RC_BACKUP_SET,RC_BACKUP_CONTROLFILE,RC_BACKUP_DATAFILE,RC_BACKUP_COR
RUPTION, RC_STORED_SCRIPT,RC_BACKUP_FILES views as of your interest.
How to Discover find DBID

We need DBID whenever we lost our all database files, or whenever we need to restore spfile or control
file.
After some analysis on discovering DBID I got several ways to find DBID. I will try to demonstrate the
procedure.
A)If the database is up: You can query V$database and get the DBID and record it in somewhere.
or,if the database is down and you have control file then you can mount the database and query from
V$SATABASE.
SQL> SELECT DBID FROM V$DATABASE;

DBID
----------
2869417476
B) If you log the RMAN backup or if you preserve output of RMAN session then you can get DBID
from that output.
$rman TARGET /
Recovery Manager: Release 10.2.0.1.0 - Production on Tue May 6 01:25:48 2008
connected to target database: ARJU (DBID=2869417476)
C)If you have configured AUTOBACKUP ON,
RMAN> SHOW CONTROLFILE AUTOBACKUP;

RMAN configuration parameters are:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
Now we take BACKUP DATAFILE 4,

RMAN>BACKUP DATAFILE 4;
.
.
Starting Control File and SPFILE Autobackup at 06-MAY-08
piece handle=/oracle/app/oracle/product/10.2.0/db_1/dbs/c-2869417476-20080506-04
The autobackup format is by default c-IIIIIIIIII-YYYYMMDD-QQ,(when it is %F) where:
IIIIIIIIII stands for the DBID.

YYYYMMDD is a time stamp of the day the backup is generated
QQ is the hex sequence that starts with 00 and has a maximum of FF
I have seen that this format works when we set specifically/explicitly configure as
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
Now in the file from c-2869417476-20080506-04 we get DBID is 2869417476.
D)If you did not set Autobackup on which is by default. After many analysis I found that DBID can be
seen from backup piece or any image copy that holds either SYSTEM or SYSAUX or UNDO datafiles.
Though if you backup your database as backup as compressed then with this method you will not
be able to discover DBID.
If you have SYSTEM datafile or UNDO datafile either as image copy or as backup piece then you can
use,
strings file_name |grep MAXVALUE, (In case of SYSTEM datafile)
strings file_name |grep MAXVALUE (In case of UNDO datafile)
to find DBID.
If you have SYSAUX datafile either as image copy or as backup piece then you can use,
strings file_name |grep DBID= to find DBID.
Examples:
-----------------
Both of these example is based on UNIX scenario.
1)
RMAN> backup datafile 1;
Starting backup at 06-MAY-08

channel ORA_DISK_1: sid=153 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/oradata1/arju/datafiles/ARJU/system01.dbf
channel ORA_DISK_1: starting piece 1 at 06-MAY-08
channel ORA_DISK_1: finished piece 1 at 06-MAY-08
piece handle=/oradata2/arju/flash_recovery_area/ARJU/backupset/
2008_05_06/o1_mf_nnndf_TAG20080506T014702_41zw6p8j_.bkp
.
.
RMAN> exit;
Recovery Manager complete.
bash-3.00$ strings /oradata2/arju/flash_recovery_area/ARJU/backupset/
2008_05_06/o1_mf_nnndf_TAG20080506T014702_41zw6p8j_.bkp |grep MAXVALUE,
.
.
2869417476, MAXVALUE,
So here 2869417476 is the DBID.
2)RMAN> backup as copy datafile 2;

channel ORA_DISK_1: starting datafile copy
input datafile fno=00002 name=/oradata1/arju/datafiles/ARJU/undotbs01.dbf
outputfilename=/oradata2/arju/flash_recovery_area/ARJU/datafile/o1_mf_undotbs1_41zwjtx6_.dbf
bash-3.00$ strings
/oradata2/arju/flash_recovery_area/ARJU/datafile/o1_mf_undotbs1_41zwjtx6_.dbf |grep
MAXVALUE
2869417476, MAXVALUE
Here 2869417476 is the DBID
3)From physical data file you can also follow the same method.
From sysaux datafile,
bash-3.00$ strings /oradata1/arju/datafiles/ARJU/sysaux01.dbf |grep DBID=

connected to target database: ARJU (DBID=2869417476, not open)
Here 2869417476 is the DBID.
4)From whole database backup you can also follow same method.
RMAN> BACKUP DATABASE;
..
piece handle=/oradata2/arju/flash_recovery_area/ARJU/backupset/
2008_05_06/o1_mf_nnndf_TAG20080506T015705_41zwskgv_.bkp
bash-3.00$ strings /oradata2/arju/flash_recovery_area/ARJU/backupset/

2008_05_06/o1_mf_nnndf_TAG20080506T015705_41zwskgv_.bkp |grep MAXVALUE,
.
2869417476, MAXVALUE,
Here 2869417476 is the DBID.

Performing Tablespace Point-in-time Recovery.
With an example I will make you understand RMAN Fully Automated TSPITR. Workaround I will
truncate a table which resides on USERS tablespace and later I will recover the tablespace to get back
my data.
Note that my interaction with the RMAN client is shown as BOLD.
A)Get the rows of my_table.
SQL> select count(*) from my_table;

COUNT(*)
----------
49792
B)Truncate the Table.
SQL> TRUNCATE TABLE MY_TABLE;

Table truncated.
C)Determine the Tablespace which is belong my Dropped Table.
SQL> SELECT TABLESPACE_NAME from DBA_TABLES WHERE

TABLE_NAME='MY_TABLE';
TABLESPACE_NAME
------------------------------
USERS
D)Connect to rman and perform TSPITR operation on USERS Tablespace.
SQL> !rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Thu May 8 04:49:54 2008
RMAN> RECOVER TABLESPACE USERS UNTIL TIME 'SYSDATE-1/24/60*5' AUXILIARY

DESTINATION '/export/home/oracle';
Starting recover at 08-MAY-08

RMAN-05026: WARNING: presuming following set of tablespaces applies to specified point in time
List of tablespaces expected to have UNDO segments

tablespace SYSTEM
tablespace UNDOTBS1
Creating automatic instance, with SID='jDiz'
initialization parameters used for automatic instance:

db_name=DBASE
compatible=10.2.0.1.0
db_block_size=8192
db_files=200
db_unique_name=tspitr_DBASE_jDiz
large_pool_size=1M
shared_pool_size=110M
#No auxiliary parameter file used
db_create_file_dest=/export/home/oracle
control_files=/export/home/oracle/cntrl_tspitr_DBASE_jDiz.f
starting up automatic instance DBASE
Oracle instance started
Total System Global Area 205520896 bytes
Fixed Size 2019576 bytes

Variable Size 146804488 bytes
Database Buffers 50331648 bytes
Redo Buffers 6365184 bytes
Automatic instance created
contents of Memory Script:

{
# set the until clause
set until time "SYSDATE-1/24/60*5";
# restore the controlfile
restore clone controlfile;
# mount the controlfile
sql clone 'alter database mount clone database';
# archive current online log for tspitr to a resent until time
sql 'alter system archive log current';
# avoid unnecessary autobackups for structural changes during TSPITR
sql 'begin dbms_backup_restore.AutoBackupFlag(FALSE); end;';
}
executing Memory Script
executing command: SET until clause
Starting restore at 08-MAY-08

allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=37 devtype=DISK
channel ORA_AUX_DISK_1: starting datafile backupset restore

channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: reading from backup piece
/oradata2/flash_recovery_area/DBASE/backupset/2008_05_07/
o1_mf_ncsnf_TAG20080507T222432_424s4rpy_.bkp
channel ORA_AUX_DISK_1: restored backup piece 1
piece handle=/oradata2/flash_recovery_area/DBASE/backupset/2008_05_07/
o1_mf_ncsnf_TAG20080507T222432_424s4rpy_.bkp tag=TAG20080507T222432
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/export/home/oracle/cntrl_tspitr_DBASE_jDiz.f
Finished restore at 08-MAY-08
sql statement: alter database mount clone database
sql statement: alter system archive log current
sql statement: begin dbms_backup_restore.AutoBackupFlag(FALSE); end;

released channel: ORA_DISK_1
released channel: ORA_AUX_DISK_1

{
# generated tablespace point-in-time recovery script
# set the until clause
set until time "SYSDATE-1/24/60*5";
plsql <<<-- tspitr_2 declare sqlstatement varchar2(512); offline_not_needed exception; pragma
exception_init(offline_not_needed, -01539); begin sqlstatement := 'alter tablespace '|| 'USERS' ||' offline
for recover'; krmicd.writeMsg(6162, sqlstatement); krmicd.execSql(sqlstatement); exception when
offline_not_needed then null; end; >>>;
# set an omf destination filename for restore
set newname for clone datafile 1 to new;
# set an omf destination filename for restore
set newname for clone datafile 2 to new;
# set an omf destination tempfile
set newname for clone tempfile 1 to new;
# set a destination filename for restore
set newname for datafile 4 to
"/oradata2/data1/dbase/users01.dbf";
# rename all tempfiles
switch clone tempfile all;
# restore the tablespaces in the recovery set plus the auxilliary tablespaces
restore clone datafile 1, 2, 4;
switch clone datafile all;
#online the datafiles restored or flipped
sql clone "alter database datafile 1 online";
# make the controlfile point at the restored datafiles, then recover them
recover clone database tablespace "USERS", "SYSTEM", "UNDOTBS1" delete archivelog;
alter clone database open resetlogs;
# PLUG HERE the creation of a temporary tablespace if export fails due to lack
# of temporary space.
# For example in Unix these two lines would do that:
#sql clone "create tablespace aux_tspitr_tmp
# datafile ''/tmp/aux_tspitr_tmp.dbf'' size 500K";
}
executing command: SET until clause
sql statement: alter tablespace USERS offline for recover
executing command: SET NEWNAME
renamed temporary file 1 to /export/home/oracle/TSPITR_DBASE_JDIZ/datafile/

o1_mf_temp_%u_.tmp in control file

allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=39 devtype=DISK
channel ORA_AUX_DISK_1: starting datafile backupset restore

channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /export/home/oracle/TSPITR_DBASE_JDIZ/datafile/
o1_mf_system_%u_.dbf
restoring datafile 00002 to /export/home/oracle/TSPITR_DBASE_JDIZ/datafile/
o1_mf_undotbs1_%u_.dbf
restoring datafile 00004 to /oradata2/data1/dbase/users01.dbf
channel ORA_AUX_DISK_1: reading from backup piece
/oradata2/flash_recovery_area/DBASE/backupset/2008_05_07/
o1_mf_nnndf_TAG20080507T222432_424s30dp_.bkp
channel ORA_AUX_DISK_1: restored backup piece 1
piece handle=/oradata2/flash_recovery_area/DBASE/backupset/2008_05_07/
o1_mf_nnndf_TAG20080507T222432_424s30dp_.bkp tag=TAG20080507T222432
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:36
datafile 1 switched to datafile copy

input datafile copy recid=6 stamp=654151900
filename=/export/home/oracle/TSPITR_DBASE_JDIZ/datafile/
o1_mf_system_425hqsjn_.dbf
datafile 2 switched to datafile copy
input datafile copy recid=7 stamp=654151900
filename=/export/home/oracle/TSPITR_DBASE_JDIZ/datafile/
o1_mf_undotbs1_425hqsjr_.dbf
sql statement: alter database datafile 1 online


using channel ORA_AUX_DISK_1
starting media recovery
archive log thread 1 sequence 3 is already on disk as file

/oradata2/flash_recovery_area/DBASE/archivelog/2008_05_08/o1_mf_1_3_425h5ok9_.arc
archive log thread 1 sequence 4 is already on disk as file
/oradata2/flash_recovery_area/DBASE/archivelog/2008_05_08/o1_mf_1_4_425hqnx5_.arc
archive log
filename=/oradata2/flash_recovery_area/DBASE/archivelog/2008_05_08/o1_mf_1_3_425h5ok9_.arc
thread=1 sequence=3
archive log
filename=/oradata2/flash_recovery_area/DBASE/archivelog/2008_05_08/o1_mf_1_4_425hqnx5_.arc
thread=1 sequence=4
media recovery complete, elapsed time: 00:00:07
Finished recover at 08-MAY-08
database opened

{
# export the tablespaces in the recovery set
host 'exp userid =\"/@$DESCRIPTION=\(ADDRESS=\(PROTOCOL=beq$\
(PROGRAM=/oracle/app/oracle/product/10.2.0/db_1/bin/oracle\)\
(ARGV0=oraclejDiz\)$ARGS=^'\(DESCRIPTION=\(LOCAL=YES$\
(ADDRESS=$PROTOCOL=beq$\)\)^'\)$ENVS=^'ORACLE_SID=jDiz^'$\)$CONNECT_DATA=\
(SID=jDiz$\)\) as sysdba\" point_in_time_recover=y tablespaces=
USERS file=
tspitr_a.dmp';
# shutdown clone before import
shutdown clone immediate
# import the tablespaces in the recovery set
host 'imp userid =\"/@ as sysdba\" point_in_time_recover=y file=
tspitr_a.dmp';
# online/offline the tablespace imported
sql "alter tablespace USERS online";
sql "alter tablespace USERS offline";
# enable autobackups in case user does open resetlogs from RMAN after TSPITR
sql 'begin dbms_backup_restore.AutoBackupFlag(TRUE); end;';
}
Export: Release 10.2.0.1.0 - Production on Thu May 8 04:51:58 2008
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses WE8ISO8859P1 character set (possible charset conversion)
Note: table data (rows) will not be exported
About to export Tablespace Point-in-time Recovery objects...

For tablespace USERS ...
. exporting cluster definitions
. exporting table definitions
. . exporting table DEPT
EXP-00091: Exporting questionable statistics.
. . exporting table EMP
. . exporting table BONUS
. . exporting table SALGRADE
. . exporting table MY_TABLE
. exporting referential integrity constraints
. exporting triggers
. end point-in-time recovery
Export terminated successfully with warnings.
host command complete
database closed
database dismounted
Oracle instance shut down
Import: Release 10.2.0.1.0 - Production on Thu May 8 04:52:19 2008

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Export file created by EXPORT:V10.02.01 via conventional path

About to import Tablespace Point-in-time Recovery objects...
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses WE8ISO8859P1 character set (possible charset conversion)
. importing SYS's objects into SYS
. importing SCOTT's objects into SCOTT
. . importing table "DEPT"
. . importing table "EMP"
. . importing table "BONUS"
. . importing table "SALGRADE"
. importing ARJU's objects into ARJU
. . importing table "MY_TABLE"
. importing SCOTT's objects into SCOTT
. importing SYS's objects into SYS
Import terminated successfully without warnings.
host command complete
sql statement: alter tablespace USERS online

sql statement: alter tablespace USERS offline
sql statement: begin dbms_backup_restore.AutoBackupFlag(TRUE); end;
Removing automatic instance

Automatic instance removed
auxiliary instance file /export/home/oracle/cntrl_tspitr_DBASE_jDiz.f deleted
auxiliary instance file
/export/home/oracle/TSPITR_DBASE_JDIZ/datafile/o1_mf_system_425hqsjn_.dbf deleted
/export/home/oracle/TSPITR_DBASE_JDIZ/datafile/o1_mf_undotbs1_425hqsjr_.dbf deleted
/export/home/oracle/TSPITR_DBASE_JDIZ/datafile/o1_mf_temp_425hs9ot_.tmp deleted
auxiliary instance file /export/home/oracle/TSPITR_DBASE_JDIZ/onlinelog/o1_mf_1_425hs5oy_.log
deleted
auxiliary instance file /export/home/oracle/TSPITR_DBASE_JDIZ/onlinelog/o1_mf_2_425hs6hl_.log
deleted
auxiliary instance file /export/home/oracle/TSPITR_DBASE_JDIZ/onlinelog/o1_mf_3_425hs7kc_.log
deleted
E)Make the backup of Tablespace and make it Online.
RMAN> SQL'ALTER TABLESPACE USERS ONLINE';

sql statement: ALTER TABLESPACE USERS ONLINE
RMAN> exit;
Recovery Manager complete.
F)Check the Objects.
SQL> select count(*) from my_table;
COUNT(*)
----------
49792
August 13, 2008

How to change the hostname in Linux
There are several ways by which we can change the hostname in linux. The process may vary based on
distribution of linux.
To see your system current host name use,

# hostname
# cat /bin/hostname
On debian system you can use,

# uname -n
To see the fully qualified domain name if you have use,
#hostname –fqd
Temporary Change hostname

To change the hostname temporary issue,
#hostname new_name which will change your current hostname to the new_name. You will most
probably need to exit the current shell in order to see the change in your shell prompt. However changes
in this way is not persistent because if the system reboot it will show the hostname values from a
particular field.
Permanently change hostname of Debian Linux

To change the hostname of debian linux distribution edit the file /etc/hostname as debian based systems
use the file /etc/hostname to read the hostname of the system at boot time and set it up using the init
script /etc/init.d/hostname.sh
So, to change it in debian issue,

#vi /etc/hostname
and put a new entry there.
After changing to make it active run the script /etc/init.d/hostname.sh

# /etc/init.d/hostname.sh
Use sysctl to change the hostname both in RHL and debian

This process can be used both debian and red hat linux distribution. In this process use sysctl to change
the variable kernel.hostname.
To read the current hostname issue,

#sysctl kernel.hostname
To change the current hostname to new_name issue,
#sysctl kernel.hostname=new_name
Change the hostname permanently in RHL Linux

This system is avilable for RHL distribution. Not apply for debian distribution. In this system change the
network configuration file /etc/sysconfig/network in RHL.
Edit the /etc/sysconfig/network and change the hostname parameter to the new_name.
#vi /etc/sysconfig/network
HOSTNAME=new-host-name
Restart the network which relied on the hostname. You can perform reboot here.
# service network restart
Or,
#/etc/sysconfig/network-scripts/ifcfg-eth0
You may need to restart your console.

#init 3
#init 5
Restore and Recover database to a new host

In this post I will show how I can restore and recover a database to another host. In this case DBID of
the database will be the same as of original database. But whenever your purpose is to create a new copy
of the database then use RMAN DUPLICATE; this will change the DBID of the new database.
In this example my database name dbase1 and the database dbase1 is running on neptune machine. I like
to take a backup on neptune machine, transfer the backup to saturn machine and perform restore and
recover in saturn machine.
1)In neptune machine(Source)
RMAN> backup database;

channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/oradata2/data1/dbase1/system01.dbf
input datafile fno=00003 name=/oradata2/data1/dbase1/sysaux01.dbf
input datafile fno=00005 name=/oradata2/DBASE1/datafile/o1_mf_tbs2_41vyzfrq_.dbf
input datafile fno=00006 name=/oradata2/DBASE1/datafile/o1_mf_after_on_420r4f9h_.dbf
input datafile fno=00002 name=/oradata2/data1/dbase1/undotbs01.dbf
input datafile fno=00004 name=/oradata2/data1/dbase1/users01.dbf
input datafile fno=00007 name=/oradata2/DBASE1/datafile/o1_mf_after_on_420r675z_.dbf
input datafile fno=00008 name=/oradata2/DBASE1/datafile/o1_mf_after_on_420x2yw8_.dbf
channel ORA_DISK_1: starting piece 1 at 06-MAY-08
channel ORA_DISK_1: finished piece 1 at 06-MAY-08
piece handle=/oradata2/flash_recovery_area/DBASE1/backupset/2008_05_06/
o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp tag=TAG20080506T150716 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:35
Finished backup at 06-MAY-08
Starting Control File and SPFILE Autobackup at 06-MAY-08

piece handle=/oradata2/flash_recovery_area/DBASE1/autobackup/2008_05_06/
o1_mf_s_654016132_421c64vl_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 06-MAY-08
2)Transfer this two backup pieces to target machine(From Neptune)

bash-3.00$ scp /oradata2/flash_recovery_area/DBASE1/backupset/2008_05_06/
o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp oracle@saturn:/oradata2/
Password:
o1_mf_nnndf_TAG20080 100% |***********************************************| 525 MB
00:59
bash-3.00$ scp /oradata2/flash_recovery_area/DBASE1/autobackup/2008_05_06/
o1_mf_s_654016132_421c64vl_.bkp oracle@saturn:/oradata2/
Password:
o1_mf_s_654016132_42 100% |***********************************************| 6976 KB
00:00
3)Determine the DBID of source machine(Neptune here)
SQL> select dbid from v$database;

DBID
----------
3386862614
4)Now perform task on target machine(Saturn here).

First set ORACLE_SID,
-bash-3.00$export ORACLE_SID=dbase1
Then connect to rman,
-bash-3.00$ rman target /
connected to target database (not started)
5)Set DBID and restore spfile to pfile.

RMAN> set dbid 3386862614
executing command: SET DBID
RMAN> startup nomount

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/oracle/app/oracle/product/10.2.0/db_1/dbs/initdbase1.ora'
starting Oracle instance without parameter file for retrival of spfile


RMAN> restore spfile to pfile '/oracle/app/oracle/product/10.2.0/db_1/dbs/initdbase1.ora' from

'/oradata2/o1_mf_s_654016132_421c64vl_.bkp';

channel ORA_DISK_1: autobackup found: /oradata2/o1_mf_s_654016132_421c64vl_.bkp

channel ORA_DISK_1: SPFILE restore from autobackup complete
Open the pfile with an editor file and if you wish change the location
6)start the instance with pfile.
RMAN> STARTUP FORCE NOMOUNT
PFILE='/oracle/app/oracle/product/10.2.0/db_1/dbs/initdbase1.ora';

7)Restore controlfile and mount the database.

RMAN> RESTORE CONTROLFILE FROM '/oradata2/o1_mf_s_654016132_421c64vl_.bkp';
channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/oradata2/DBase1/control01.ctl
RMAN> ALTER DATABASE MOUNT;
database mounted
8)From SQL*Plus determine the data file and redo log file name.
SQL> COLUMN NAME FORMAT a70
SQL> 1 SELECT FILE# AS "File/Grp#", NAME FROM V$DATAFILE
2 UNION
3* SELECT GROUP#,MEMBER FROM V$LOGFILE
File/Grp# NAME
---------- ------------------------------------------------------------
1 /oradata2/data1/dbase1/redo01.log
1 /oradata2/data1/dbase1/system01.dbf
2 /oradata2/data1/dbase1/undotbs01.dbf
3 /oradata2/data1/dbase1/sysaux01.dbf
4 /oradata2/data1/dbase1/users01.dbf
5 /oradata2/DBASE1/datafile/o1_mf_tbs2_41vyzfrq_.dbf
6 /oradata2/DBASE1/datafile/o1_mf_after_on_420r4f9h_.dbf
7 /oradata2/DBASE1/datafile/o1_mf_after_on_420r675z_.dbf
8 /oradata2/DBASE1/datafile/o1_mf_after_on_420x2yw8_.dbf
11 rows selected.
9)Catalog your backuppiece.

RMAN> catalog backuppiece '/oradata2/o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp';
cataloged backuppiece
backup piece handle=/oradata2/o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp
recid=33 stamp=65398295
RMAN> list backup;
List of Backup Sets

===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ ---------------
32 Full 525.67M DISK 00:01:31 06-MAY-08
BP Key: 33 Status: AVAILABLE Compressed: NO Tag: TAG20080506T150716
Piece Name: /oradata2/o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp
List of Datafiles in backup set 32
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 745212 06-MAY-08 /oradata2/data1/dbase1/system01.dbf
2 Full 745212 06-MAY-08 /oradata2/data1/dbase1/undotbs01.dbf
3 Full 745212 06-MAY-08 /oradata2/data1/dbase1/sysaux01.dbf
4 Full 745212 06-MAY-08 /oradata2/data1/dbase1/users01.dbf
5 Full 745212 06-MAY-08 /oradata2/DBASE1/datafile/o1_mf_tbs2_41vyzfrq_.dbf
6 Full 745212 06-MAY-08 /oradata2/DBASE1/datafile/o1_mf_after_on_420r4f9h_.dbf
7 Full 745212 06-MAY-08 /oradata2/DBASE1/datafile/o1_mf_after_on_420r675z_.dbf
8 Full 745212 06-MAY-08 /oradata2/DBASE1/datafile/o1_mf_after_on_420x2yw8_.dbf
10)Make a script by issuing SET NEWNAME if you want different file name other than source.
In the script issue SET UNTIL clause and restore and recover database.
RMAN> @/export/home/oracle/rman
RMAN> run{
2> set newname for datafile 1 to '/oradata2/DBase1/system01.dbf';
3> set newname for datafile 2 to '/oradata2/DBase1/undotbs01.dbf';
4> set newname for datafile 3 to '/oradata2/DBase1/sysaux01.dbf';
5> set newname for datafile 4 to '/oradata2/DBase1/users01.dbf';
6> set newname for datafile 5 to '/oradata2/DBase1/tbs201.dbf';
7> set newname for datafile 6 to '/oradata2/DBase1/after_01.dbf';
10> set newname for datafile 1 to '/oradata2/DBase1/system01.dbf';
11>
12> SET UNTIL SCN 745212;
13> RESTORE DATABASE;
14> SWITCH DATAFILE ALL;
15> RECOVER DATABASE;
16> }
11)Open the Database resetlogs option.

RMAN> alter database open resetlogs;
database opened.
Restore and Recover database in Noarchivelog Mode

Before proceed we need to know while restoring data in noarchivelog mode that,
1)Only cold backups (that is, backups created when the database was shut down normally) can be used
in restoring a database in NOARCHIVELOG mode.
2)Media recovery is not possible, because there are no archived logs.

3)If we exclude any tablespace except read-only or offline from taking database backup then those
tablespaces will be lost.
In this scenario I have lost all the data files, control files, redo log file and spfile. I have also forgot
DBID of the database. The procedure of restore and recovery of database in noarchivelog mode in as
below.
A)Find the DBID of the Database from Backup Piece.

bash-3.00$ strings
/oradata2/flash_recovery_area/DBASE1/backupset/2008_05_06/o1_mf_nnndf_TAG20080506T111
057_420x821v_.bkp |grep MAXVALUE,
3386862614, MAXVALUE,
We got DBID here 3386862614. For more details please visit How to Discover DBID
B)Connect to target database with RMAN
bash-3.00$ rman target /

connected to target database (not started)
C)Set the DBID.
RMAN> set dbid 3386862614
executing command: SET DBID
D)Start the database in nomount stage with dummy Parameter.
RMAN> startup force nomount
startup failed: ORA-01078: failure in processing system parameters

LRM-00109: could not open parameter file '/oracle/app/oracle/product/10.2.0/db_1/dbs/initdbase1.ora'
starting Oracle instance without parameter file for retrival of spfile


Redo Buffers 6369280 byte
E)Restore spfile
RMAN> restore spfile from

'/oradata2/flash_recovery_area/DBASE1/autobackup/2008_05_06/o1_mf_s_653998009_420shstm_
.bkp';

channel ORA_DISK_1: autobackup found:

/oradata2/flash_recovery_area/DBASE1/autobackup/2008_05_06/o1_mf_s_653998009_420shstm_.bkp
channel ORA_DISK_1: SPFILE restore from autobackup complete
F)Mount the Database.
RMAN> startup force nomount;

G)Restore controlfile.
RMAN> restore controlfile from autobackup;

recovery area destination: /oradata2/flash_recovery_area

database name (or database unique name) used for search: DBASE1
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found:
/oradata2/flash_recovery_area/DBASE1/autobackup/2008_05_06/o1_mf_s_654001832_420xbfr6_.bkp
channel ORA_DISK_1: control file restore from autobackup complete
output filename=/oradata2/data1/dbase1/control01.ctl
H)Mount the Database.

RMAN> alter database mount;
database mounted
I)Restore Database.
As we have flash recovery area configured so it automatically cataloged backup sets.

RMAN> restore database;
Starting implicit crosscheck backup at 06-MAY-08
Crosschecked 12 objects
Finished implicit crosscheck backup at 06-MAY-08
Starting implicit crosscheck copy at 06-MAY-08

Finished implicit crosscheck copy at 06-MAY-08
searching for all files in the recovery area

cataloging files...
cataloging done
List of Cataloged Files

=======================
File Name:
/oradata2/flash_recovery_area/DBASE1/autobackup/2008_05_06/o1_mf_s_654001832_420xbfr6_.bkp
channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /oradata2/data1/dbase1/system01.dbf
restoring datafile 00002 to /oradata2/data1/dbase1/undotbs01.dbf
restoring datafile 00003 to /oradata2/data1/dbase1/sysaux01.dbf
restoring datafile 00004 to /oradata2/data1/dbase1/users01.dbf
restoring datafile 00005 to /oradata2/DBASE1/datafile/o1_mf_tbs2_41vyzfrq_.dbf
restoring datafile 00006 to /oradata2/DBASE1/datafile/o1_mf_after_on_420r4f9h_.dbf
restoring datafile 00007 to /oradata2/DBASE1/datafile/o1_mf_after_on_420r675z_.dbf
restoring datafile 00008 to /oradata2/DBASE1/datafile/o1_mf_after_on_420x2yw8_.dbf
_420x821v_.bkp
ORA-19870: error reading backup piece
_420x821v_.bkp
ORA-19612: datafile 1 not restored due to missing or corrupt data
failover to previous backup
channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /oradata2/data1/dbase1/system01.dbf
/oradata2/flash_recovery_area/DBASE1/backupset/2008_05_05/o1_mf_nnnd0_LEVEL_0_BACKUP_4
1yo0jl9_.bkp
piece
handle=/oradata2/flash_recovery_area/DBASE1/backupset/2008_05_05/o1_mf_nnnd0_LEVEL_0_BA
CKUP_41yo0jl9_.bkp tag=LEVEL_0_BACKUP
channel ORA_DISK_1: restore complete, elapsed time: 00:00:56
J)Recover Database:
If the current online logs contain all changes since the last backup , then you can run RECOVER
DATABASE without specifying NOREDO. Otherwise you have to specify RECOVER DATABASE
NOREDO.
RMAN> recover database;

starting media recovery
archive log thread 1 sequence 11 is already on disk as file /oradata2/data1/dbase1/redo01.log

archive log filename=/oradata2/data1/dbase1/redo01.log thread=1 sequence=11
media recovery complete, elapsed time: 00:00:12
K)Open the database with RESETLOGS options.
RMAN> alter database open resetlogs;

database opened.
When to use RMAN TSPITR?

RMAN tablespace point-in-time recovery (abbreviated as TSPITR) enables you to quickly recover one
or more tablespace in an oracle database to a previous time, without affecting the rest of the tablespaces
in your database.
When you can use TSPITR

---------------------------
We need to remember that with RMAN TSPITR the whole data set inside the tablespace will be recover
to an earlier time rather than single object.
In the following cases you might choose to use TSPITR.
1)Erroneously TRUNCATE TABLE statement is execute on a table.

2)Wrong update is done on a table and committed.
3)In a database there is several schema each in different tablespace. Now I want to get back a single
schema to an earlier time.
It is good to remember that if a database run on a NOARCHIVELOG mode then TSPITR can't be
performed. In other word I can say if I don't have archived redo logs then TSPITR can't be performed.
Within RMAN you can save commands and execute it whenever you wish. Stored scripts bring this
facility where we should not bother about OS scripts whether RMAN client has proper permission on it
or not.
Stored Scripts can be two types.
1)Global Stored Scripts:A global stored script can be run against any database registered in the
recovery catalog, if the RMAN client is connected to the recovery catalog and a target database.
2)Local Stored Scripts:A local stored script is associated with the target database to which RMAN is
connected when the script is created, and can only be executed when you are connected to that target
database.
How to Created Stored Script:

---------------------------------
To create local stored script.
CREATE SCRIPT query_backup
{
SHOW ALL;
REPORT NEED BACKUP;
REPORT OBSOLETE;
}
To create global stored with a comment added to it,
CREATE GLOBAL SCRIPT global_query_backup

COMMENT 'This is a sample global script which returns some query'
{
SHOW ALL;
REPORT NEED BACKUP;
REPORT OBSOLETE;
}
Alternatively you can create script from a text file. To create local script from text file in '/oradata2' just
use,
CREATE SCRIPT test_script FROM FILE '/oradata2/my_script_file.txt';
How to run Stored Scripts:

------------------------------
To run stored script use,
RUN{
EXECUTE SCRIPT query_backup;
}
It will first search for local stored script with name query_backup. If not found then will check global
stored script with the name. If you have same name in both local and global script then to run global
script explicitly use,
RUN{
EXECUTE GLOBAL SCRIPT global_query_backup;
}
Displaying a Stored Script:

----------------------------------
PRINT SCRIPT query_backup;
PRINT GLOBAL SCRIPT global_query_backup;
RMAN> PRINT GLOBAL SCRIPT global_query_backup;
printing stored global script: global_query_backup

{SHOW ALL;
REPORT NEED BACKUP;
REPORT OBSOLETE;
}
Listing Stored Scripts:

-----------------------------
To view both global and local, for the currently connected target database use,
LIST SCRIPT NAMES;
To view only global script names use,
LIST GLOBAL SCRIPT NAMES;
To view the names of all scripts stored in the current recovery catalog, including global scripts and local
scripts for all target databases registered in the recovery catalog, use,
LIST ALL SCRIPT NAMES;
Remember that to run LIST SCRIPT NAMES RMAN must be connected to target database.
To run LIST GLOBAL SCRIPT NAMES and LIST ALL SCRIPT NAMES RMAN need not to be
connected to target database.
Example:
---------------
-bash-3.00$ rman CATALOG
Recovery Manager: Release 10.2.0.1.0 - Production on Thu May 8 01:14:36 2008
RMAN> LIST GLOBAL SCRIPT NAMES;

List of Stored Scripts in Recovery Catalog
Global Scripts
Script Name
Description
-----------------------------------------------------------------------
global_query_backup
This is a sample global script which returns some query
Updating Stored Scripts:
-------------------------
To update a script use,
REPLACE [GLOBAL]SCRIPT
{
BACKUP DATABASE PLUS ARCHIVELOG;
}
Here like,
REPLACE SCRIPT query_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
}
If the script does not already exist, then RMAN creates it.
Deleting Stored Scripts
--------------------------------
DELETE SCRIPT query_bakcup;
DELETE GLOBAL SCRIPT global_query_backup;
If you use DELETE SCRIPT without GLOBAL, and there is no stored script for the target database with
the specified name, RMAN will look for a global stored script by the specified name and delete the
global script if it exists.
Contents of Flash Recovery Area.

If you have configured flash recovery area then flash recovery area can contains the following files
automatically.
•RMAN Backups: All the RMAN backups by default stored in flash recovery area if you have
configured.
•Control file Autobackups: If you have settings CONFIGURE CONTROLFILE AUTOBACKUP ON

then database places any backup of controlfile to flash recovery are.
•Flashback logs: If you enable flashback logging of your database then oracle copies images of each
altered block in every datafile into flashback logs stored in the flash recovery area.
•Current Control file: You can store a multiplexed current control file in flash recovery area.
•Online Redo log files: You save a multiplexed copy of your online redo log files in the flash recovery
area.
•Archived Redo log files: You can also store your archived redo log file in the flash recovery are. Rman
automatically will delete the files if it is in space pressure.
The files that can be stored in flash recovery are among them only redo log files and control files are
permanent. Other files are transient. So oracle will delete then whenever they become obsolete or
already backed up to tape.
Set Up a Flash Recovery Area for RMAN
Flash recovery area simplifies the ongoing administration of your database by automatically naming
recovery-related files, retaining them as long as they are needed for restore and recovery activities, and
deleting them when they are no longer needed to restore your database and space is needed for some
other backup and recovery-related purpose.
To see up flash recovery follow below steps.
1)Set up DB_RECOVERY_FILE_DEST_SIZE:
SQL> alter system set db_recovery_file_dest_size=2G;
2)Decide the area from OS where you will place Flash recovery area.
SQL>host mkdir /oradata1/flash_recovery_area
3)Set up DB_RECOVERY_FILE_DEST:
SQL> alter system set db_recovery_file_dest='/oradata1/flash_recovery_area';
The V$RECOVERY_FILE_DEST and V$FLASH_RECOVERY_AREA_USAGE views can help to

find out the current location, disk quota, space in use, space reclaimable by deleting files,total number of
files, the percentage of the total disk quota used by different types of files, and how much space for each
type of file can be reclaimed by deleting files that are obsolete, redundant, or already backed up to tape.
In order to disable flash recovery area issue,

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID='*';
Restore Point and Flashback Database.

Flashback database enables us to get back our database to a prior time.
And with restore point we can make a point before any database upgrade and if there is any problem we
can get back to that point.
Restore point can be two types.
1)Normal Restore point:

---------------------------
Creating a normal restore point assigns the restore point name to a specific point in time or SCN, as a
kind of bookmark or alias you can use with commands that recognize a RESTORE POINT clause as a
shorthand for specifying an SCN.
In normal restore point Flashback logs are deleted in response to space pressure.
To create a restore point simply use,
CREATE RESTORE POINT before_upgrade;
2)Guaranteed Restore Point:

-------------------------------
In guaranteed restore point Flashback logs are not deleted in response to space pressure, if they are
required to satisfy the guarantee.
Guaranteed restore point can be created whether your flashback feature on or off.
If a guaranteed restore point is created when Flashback Database is disabled, then, the first time a
datafile block is modified after the time of the guaranteed restore point, an image of the block before the
modification is stored in the flashback logs but subsequent modifications to the same block do not cause
the block contents to be logged again. In this case you cannot use FLASHBACK DATABASE to reach
points in time between the guaranteed restore points and the current time.
If a guaranteed restore point is created when Flashback Database is enabled, then the database perform
normal flashback operations and create logs. The flash recovery area always retains the flashback logs
required to allow FLASHBACK DATABASE to any time as far back as the earliest
currently defined guaranteed restore point. In this case you can use FLASHBACK DATABASE to reach
points in time between the guaranteed restore points and the current time.
To create a guaranteed restore point use,
CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
You can see your restore points from V$RESTORE_POINT.

To drop a restore point use
SQL> DROP RESTORE POINT before_app_upgrade;
Database Startup fails with error ORA-16038,ORA-19809, ORA-00312

Error Description:
Whenever you try to startup the database it fails with error ORA-16038,ORA-19809, ORA-00312.
SQL> startup
ORACLE instance started.

Database mounted.
ORA-16038: log 3 sequence# 572 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 3 thread 1: '/oradata2/data1/dbase/redo03.log'
Or in mount stage whenever you try to open the database it fails with error ORA-16014, ORA-00312.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-16014: log 3 sequence# 572 not archived, no available destinations
ORA-00312: online log 3 thread 1: '/oradata2/data1/dbase/redo03.log'
Cause of The Problem:

----------------------------------------
There was an attempt to archived the online log 3 but it could not archive the online log in the available
archived log destination. The most common of happening the error is the archive log destination if full.
You have flash recovery area configured and rman retention policy is failed to delete any archived or
incremental backups and so can't archived new online log.
Solution of The Problem:

-------------------------------------------
Solution A:(Enough space on the drive)
1)One more check the alert log. (Not needed though)
An extra check you can do in alert log which is in background_dump_dest/alert_$ORACLE_SID.log
SQL> show parameter background_dump_dest
NAME TYPE VALUE

------------------------------------ ----------- ------------------------------
background_dump_dest string /oracle/app/oracle/product/10.
2.0/db_1/admin/dbase/bdump
$less /oracle/app/oracle/product/10.2.0/db_1/admin/dbase/bdump/alert_dbase.log
You may see the same entry is in the alert log.
2)Check the archive destination.

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 572
Next log sequence to archive 572
Current log sequence 580
So archived log destination is DB_RECOVERY_FILE_DEST. You can see the exact destination in OS
by,
SQL> show parameter db_recover
NAME TYPE VALUE

------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /oradata2/flash_recovery_area
db_recovery_file_dest_size big integer 10G
3)Increase the value of db_recovery_file_dest_size

As archive destination is full so increase the size.
SQL> alter system set db_recovery_file_dest_size=20G;
System altered.
4)Open the database now.

SQL> alter database open;
Database altered.
Solution B: Have not enough space on the drive

If you have not enough space in your disk and you have recent backup of your database and archive log
is not needed then you can issue
$rman target /
RMAN>DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-2';
Solution C: Have not any backup

If you have not any recent backup then backup database to another location and delete archivelogs.
To do this,
$rman target /
RMAN>backup format '/oradata2/%U' archivelog all delete input database;
Solution D: Have recent backup and only need archivelog
In this case backup the archive log to another location and delete archive log from flash recovery area.
You can do this by,
$rman target /
RMAN> backup format '/oradata2/%U' archivelog all delete input;
Contents of Flash Recovery Area.

If you have configured flash recovery area then flash recovery area can contains the following files
automatically.
•RMAN Backups: All the RMAN backups by default stored in flash recovery area if you have
configured.
•Control file Autobackups: If you have settings CONFIGURE CONTROLFILE AUTOBACKUP ON

then database places any backup of controlfile to flash recovery are.
•Flashback logs: If you enable flashback logging of your database then oracle copies images of each
altered block in every datafile into flashback logs stored in the flash recovery area.
•Current Control file: You can store a multiplexed current control file in flash recovery area.
•Online Redo log files: You save a multiplexed copy of your online redo log files in the flash recovery
area.
•Archived Redo log files: You can also store your archived redo log file in the flash recovery are. Rman
automatically will delete the files if it is in space pressure.
The files that can be stored in flash recovery are among them only redo log files and control files are
permanent. Other files are transient. So oracle will delete then whenever they become obsolete or
already backed up to tape.
What is Alert Log?

Each database has a special file named alert_sid.log. The alert log of a database is a chronological log of
messages and errors, and includes the following items:
1)All internal errors (ORA-600), block corruption errors (ORA-1578), and deadlock errors (ORA-60)
that occur.
2)Administrative operations, such as CREATE, ALTER, and DROP statements and STARTUP,
SHUTDOWN, and ARCHIVELOG statements.
3)Messages and errors relating to the functions of shared server and dispatcher processes.
4)Errors occurring during the automatic refresh of a materialized view.
5)The values of all initialization parameters that had nondefault values at the time the database and
instance start.
Oracle Database uses the alert log to record these operations as an alternative to displaying the
information on an operator's console.
The alert log file destination is specified by BACKGROUND_DUMP_DEST.

Backing Up Archived Logs Needed To Recover An Online Backup

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Backing Up Archived Logs Needed To Recover An Online Backup

Cargado por

Copyright:

Formatos disponibles

Backing Up Archived Logs Needed to Recover an Online Backup

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

ii)Determine the log sequence number of the current redo log,

iv)Archive all unarchived logs, including the current log.

v)Determine the log sequence number of the current redo log.

SQL> SELECT SEQUENCE# FROM V$LOG WHERE STATUS = 'CURRENT';

RMAN>BACKUP ARCHIVELOG FROM SEQUENCE 10 UNTIL SEQUENCE 12;

Basic Steps of RMAN media Recovery

Step 3: Restore the files with RESTORE command.

Step 4: Recover the data files with RECOVER command.

SQL> SELECT LOG_MODE FROM V$DATABASE;

SQL> SHUTDOWN IMMEDIATE

3)Mount the database.

4)Take incremental level 0 backup.

5)Open the database to use for all.

The situations which must undergo Media Recovery:

•You restore a backup of a datafile.

Condition for Media Recovery for a Data file:

ORA-01578: ORACLE data block corrupted (file # 4, block # 45)

RMAN>BLOCKRECOVER DATAFILE 4 BLOCK 45 FROM BACKUPSET;

3)From a Specified backup,

RMAN>BLOCKRECOVER DATAFILE 4 BLOCK 45 FROM TAG level0;

4)Limiting to a certain point,

BLOCKRECOVER CORRUPTION LIST RESTORE UNTIL TIME 'SYSDATE-2';

An example:Before Performing Backup Check Any Physical or Logical Corruption:

Using RESTORE .. VALIDATE

A)Configure Recovery Catalog Database.

A)Configure Recovery Catalog Database:

2)Create a tablespace where recovery catalog information will be populated.

SQL> CREATE TABLESPACE catalog_tbs DATAFILE '/oradata2/catalog01.dbf' SIZE 100M;

B)Create the Recovery Catalog owner.

SQL> SELECT NAME,DBID FROM V$DATABASE;

SQL> CREATE USER catalog_user IDENTIFIED BY catalog_pwd TEMPORARY

SQL> GRANT RECOVERY_CATALOG_OWNER TO catalog_user;

SQL> conn catalog_user/catalog_pwd

SQL> select * from user_tables;

Now you have to populate tables in the schema. To do this,

SQL> !rman CATALOG catalog_user/catalog_pwd

Recovery Manager: Release 10.2.0.1.0 - Production on Wed May 7 05:51:44 2008

2)Run the CREATE CATALOG command to create the catalog.

RMAN>CREATE CATALOG TABLESPACE USERS;

3)Check the recovery catalog tables, objects, view, package etc.

SQL> SELECT COUNT(*) FROM USER_OBJECTS;

To do so you have to follow the following steps.

1)-Make sure that the recovery catalog database is open,

SQL> SELECT NAME, DBID FROM V$DATABASE;

SQL> !rman target / catalog

Recovery Manager: Release 10.2.0.1.0 - Production on Wed May 7 06:16:05 2008

2)Register the target database in the connected recovery catalog:

RMAN> REGISTER DATABASE;

Some commands need to be in recovery catalog schema like,

Unregistering a Target Database from the Recovery Catalog

-bash-3.00$ rman target / CATALOG

2)issue UNREGISTER DATABASE command.

RMAN> UNREGISTER DATABASE;

Resynchronizing the Recovery Catalog

RMAN> RESYNC CATALOG;

RMAN> CONFIGURE EXCLUDE FOR TABLESPACE users;

Now if you backup your database by,

RMAN> BACKUP DATABASE;

RMAN> SHOW EXCLUDE;