Documente Academic
Documente Profesional
Documente Cultură
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,
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.
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.
2)Connect to RMAN.
SQL> !rman target /
•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.
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,
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,
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.
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
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,
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.
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.
1)Through RMAN connect to the database that will contain the catalog as the catalog owner.
RMAN>CREATE CATALOG;
recovery catalog created
You can also create catalog in other tablespace like USERS if you specify that just like below,
In our example we created catalog tablespace catalog_tbs so our command will be,
RMAN>CREATE CATALOG TABLESPACE catalog_tbs;
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.
For example in target Database dbase , you want to use recovery catalog created of ARJU database.
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.
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.
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.
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,
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;
You can override this exclusion feature by explicitly issuing keyword NOEXCLUDE in order to take
whole database backup.
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,
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.
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
You can also change CONTROL_FILES parameter and then perform RESTORE CONTROLFILE to
change location.
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
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
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
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 .
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.
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.)
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.
VERSION
------------
10.02.00.00
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.
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
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: ARJU (DBID=2869417476)
I have seen that this format works when we set specifically/explicitly configure as
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
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;
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.
bash-3.00$ strings
/oradata2/arju/flash_recovery_area/ARJU/datafile/o1_mf_undotbs1_41zwjtx6_.dbf |grep
MAXVALUE
2869417476, MAXVALUE
3)From physical data file you can also follow the same method.
4)From whole database backup you can also follow same method.
RMAN> BACKUP DATABASE;
Starting backup at 06-MAY-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=145 devtype=DISK
..
piece handle=/oradata2/arju/flash_recovery_area/ARJU/backupset/
2008_05_06/o1_mf_nnndf_TAG20080506T015705_41zwskgv_.bkp
.
2869417476, MAXVALUE,
database opened
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
database closed
database dismounted
Oracle instance shut down
#sysctl kernel.hostname=new_name
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)
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';
database mounted
released channel: ORA_DISK_1
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/redo02.log
2 /oradata2/data1/dbase1/undotbs01.dbf
3 /oradata2/data1/dbase1/redo03.log
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.
cataloged backuppiece
backup piece handle=/oradata2/o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp
recid=33 stamp=65398295
RMAN> list backup;
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';
8> set newname for datafile 7 to '/oradata2/DBase1/after_02.dbf';
9> set newname for datafile 8 to '/oradata2/DBase1/after_03.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> }
database opened.
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.
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.
3386862614, MAXVALUE,
We got DBID here 3386862614. For more details please visit How to Discover DBID
E)Restore spfile
G)Restore controlfile.
RMAN> restore controlfile from autobackup;
database mounted
released channel: ORA_DISK_1
I)Restore Database.
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.
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.
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.
Alternatively you can create script from a text file. To create local script from text file in '/oradata2' just
use,
RUN{
EXECUTE GLOBAL SCRIPT global_query_backup;
}
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,
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
catalog_user/catalog_pwd@saturn:1521/ARJU.SATURN.ARJUBD.COM
Recovery Manager: Release 10.2.0.1.0 - Production on Thu May 8 01:14:36 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to recovery catalog database
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.
•RMAN Backups: All the RMAN backups by default stored in flash recovery area if you have
configured.
•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.
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';
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.
In normal restore point Flashback logs are deleted in response to space pressure.
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.
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'
So archived log destination is DB_RECOVERY_FILE_DEST. You can see the exact destination in OS
by,
SQL> show parameter db_recover
To do this,
$rman target /
RMAN>backup format '/oradata2/%U' archivelog all delete input database;
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;
•RMAN Backups: All the RMAN backups by default stored in flash recovery area if you have
configured.
•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.
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.