World of Oracle DBA

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

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

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;

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;

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; Starting backup at 06-MAY-08 using channel ORA_DISK_1 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

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; Starting backup at 06-MAY-08 using channel ORA_DISK_1 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

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 recove

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 recove

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 Recovery Manager: Release 10.2.0.1.0 - Production on Wed May 7 06:16:05 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: DBASE (DBID=1509380669) connected to recovery catalog database 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 databa

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 Recovery Manager: Release 10.2.0.1.0 - Production on Wed May 7 06:16:05 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: DBASE (DBID=1509380669) connected to recovery catalog database 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 databa

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'

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 catalog_user/catalog_pwd@satur

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'

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 catalog_user/catalog_pwd@satur

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 Determin

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 Determin

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.

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.

Before going any production upgrade to database we can make a guaranteed restore point to database and if any wrong then we can get back to the restore point state. Guaranteed restore point always ensure that we can get back data to our restore point creation time. Suppose before upgradation to database I have made an guaranteed restore point to database like, SQL> create restore point before_upgrade guarantee flashback database; Restore point created. SQL> conn shaik/shaik Connected. SQL> select count(*) from user_tables; COUNT(*) ---------- 4 SQL> create table after_restore_point (col1 number); Table created. SQL> desc after_restore_point; Name Null? Type ----------------------------------------- -------- ---------------------------- COL1 NUMBER Now I want to perform flashback database to get back database at the time of creating restore point. To do it follow the following steps, 1. Determine the desired SCN, restore point or point in time for the FLASHB

Before going any production upgrade to database we can make a guaranteed restore point to database and if any wrong then we can get back to the restore point state. Guaranteed restore point always ensure that we can get back data to our restore point creation time. Suppose before upgradation to database I have made an guaranteed restore point to database like, SQL> create restore point before_upgrade guarantee flashback database; Restore point created. SQL> conn shaik/shaik Connected. SQL> select count(*) from user_tables; COUNT(*) ---------- 4 SQL> create table after_restore_point (col1 number); Table created. SQL> desc after_restore_point; Name Null? Type ----------------------------------------- -------- ---------------------------- COL1 NUMBER Now I want to perform flashback database to get back database at the time of creating restore point. To do it follow the following steps, 1. Determine the desired SCN, restore point or point in time for the FLASHB

We know that backup of a database can be taken through OS command or by using RMAN. Most people want to use RMAN or feel more flexible to use RMAN. The features that make RMAN better than other backup methodology are as follows. 1)RMAN came with oracle and it is free to use. 2)RMAN becomes simpler day by day. The simply BACKUP DATABASE will backup the database. 3)When use RMAN you are 100% sure that database is backed up. 4)With RMAN you can validate a database before backup and also validate a database after taking backup. 5)RMAN maintains a central repository where backup information is kept. So we manually get rid to remember the backup information of database. 6)RMAN is the only tool that supports incremental backup. 7)RMAN improve performance in time while taking backup and restore database. 8)RMAN encrypt data and also use compression of backup. 9)Can take backup parallelly and also restore operation can be done by parallel. 10)Various reports and querying facility thr

We know that backup of a database can be taken through OS command or by using RMAN. Most people want to use RMAN or feel more flexible to use RMAN. The features that make RMAN better than other backup methodology are as follows. 1)RMAN came with oracle and it is free to use. 2)RMAN becomes simpler day by day. The simply BACKUP DATABASE will backup the database. 3)When use RMAN you are 100% sure that database is backed up. 4)With RMAN you can validate a database before backup and also validate a database after taking backup. 5)RMAN maintains a central repository where backup information is kept. So we manually get rid to remember the backup information of database. 6)RMAN is the only tool that supports incremental backup. 7)RMAN improve performance in time while taking backup and restore database. 8)RMAN encrypt data and also use compression of backup. 9)Can take backup parallelly and also restore operation can be done by parallel. 10)Various reports and querying facility thr

Setting the RETENTION POLICY in RMAN keep track about the backup files and tells the report whether they are obsoleted and whether it is needed to backup the database or datafile. •If you have flash recovery configured then the database automatically deletes unnecessary files from the flash recovery area based on its internal disk quota rules. The disk quota rules are distinct from the backup retention policy rules, but the database will never delete files in violation of the retention policy to satisfy the disk quota. •If you don't have flash recovery configured then the database does not delete any file even they are obsolete. •The configuration parameter RETENTION POLICY can be set by CONFIGURE RETENTION POLICY .... •A backup becomes obsolete based on retention policy, that it is not needed for recovery.A backup becomes expired only when RMAN perform CROSSCHECK and can't find the file. (A most common is file is deleted by OS). Obsolete means "not needed,&qu

Setting the RETENTION POLICY in RMAN keep track about the backup files and tells the report whether they are obsoleted and whether it is needed to backup the database or datafile. •If you have flash recovery configured then the database automatically deletes unnecessary files from the flash recovery area based on its internal disk quota rules. The disk quota rules are distinct from the backup retention policy rules, but the database will never delete files in violation of the retention policy to satisfy the disk quota. •If you don't have flash recovery configured then the database does not delete any file even they are obsolete. •The configuration parameter RETENTION POLICY can be set by CONFIGURE RETENTION POLICY .... •A backup becomes obsolete based on retention policy, that it is not needed for recovery.A backup becomes expired only when RMAN perform CROSSCHECK and can't find the file. (A most common is file is deleted by OS). Obsolete means "not needed,&qu

•An RMAN channel corresponds to one server session and it represents one stream of data to a device type. •When you run a command that requires to use any server session then RMAN automatically allocates channel with the option specified in CONFIGURE command, if you don't explicitly allocate any channel. •In the settings for which RMAN automatically allocate channel are. CONFIGURE DEVICE TYPE ... PARALLELISM CONFIGURE DEFAULT DEVICE TYPE CONFIGURE CHANNEL •You can override automatically allocated channel by explicitly specifying ALLOCATE CHANNEL within run block as follows, RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; BACKUP DATABASE; } •If you have any three above types of CONFIGURE settings then RMAN automatically allocates channel when you perform BACKUP, RESTORE, DELETE command or command within RUN block. •The number of channels allocation is done by CONFIGURE DEVICE TYPE ... PARALLELISM is based on parallelism settings. If setttings is CONFIGURE DEVICE TYPE DISK PAR

•An RMAN channel corresponds to one server session and it represents one stream of data to a device type. •When you run a command that requires to use any server session then RMAN automatically allocates channel with the option specified in CONFIGURE command, if you don't explicitly allocate any channel. •In the settings for which RMAN automatically allocate channel are. CONFIGURE DEVICE TYPE ... PARALLELISM CONFIGURE DEFAULT DEVICE TYPE CONFIGURE CHANNEL •You can override automatically allocated channel by explicitly specifying ALLOCATE CHANNEL within run block as follows, RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; BACKUP DATABASE; } •If you have any three above types of CONFIGURE settings then RMAN automatically allocates channel when you perform BACKUP, RESTORE, DELETE command or command within RUN block. •The number of channels allocation is done by CONFIGURE DEVICE TYPE ... PARALLELISM is based on parallelism settings. If setttings is CONFIGURE DEVICE TYPE DISK PAR

•If we simply use RESTORE command then RMAN directs a server session to restore the file to default location that is overwrite the existing file. •If we use RESTORE command with SET NEWNAME option then RMAN restore the file with specified location. Example: RUN { SET NEWNAME FOR DATAFILE '/oradata/datafile/1.dbf' TO '/tmp/1.dbf'; RESTORE DATAFILE '/oradata/datafile/1.dbf'; } In this case, RMAN restore /oradata/datafile/1.dbf to /tmp/1.dbf •RMAN always restore data file as image copy. •After restoring a datafile to a new location if you want to use that then use the SWITCH command in order to update control file. RMAN SWITCH command is equivalent to SQL statement ALTER DATABASE RENAME FILE command. Example: SWITCH DATAFILE '/oradata/datafile/1.dbf' TO DATAFILECOPY '/tmp/1.dbf'; •RMAN always select the most recent backup while restoring. If two backups are in the same point then RMAN prefers to use image copies over backup sets becaus

•If we simply use RESTORE command then RMAN directs a server session to restore the file to default location that is overwrite the existing file. •If we use RESTORE command with SET NEWNAME option then RMAN restore the file with specified location. Example: RUN { SET NEWNAME FOR DATAFILE '/oradata/datafile/1.dbf' TO '/tmp/1.dbf'; RESTORE DATAFILE '/oradata/datafile/1.dbf'; } In this case, RMAN restore /oradata/datafile/1.dbf to /tmp/1.dbf •RMAN always restore data file as image copy. •After restoring a datafile to a new location if you want to use that then use the SWITCH command in order to update control file. RMAN SWITCH command is equivalent to SQL statement ALTER DATABASE RENAME FILE command. Example: SWITCH DATAFILE '/oradata/datafile/1.dbf' TO DATAFILECOPY '/tmp/1.dbf'; •RMAN always select the most recent backup while restoring. If two backups are in the same point then RMAN prefers to use image copies over backup sets becaus

As a sysdba privilege issue "archive log list" to see your present archival destination settings. SQL> ARCHIVE LOG LIST Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 1 Next log sequence to archive 2 Current log sequence 2 •Based on the destination you can see the physical destination of your archived redo log file in the v$parameter. You can use, SQL> SHOW PARAMETER DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string /oradata2/flash_recovery_area db_recovery_file_dest_size big integer 2G Now a question is for which parameter settings my archived destination affects. In the following I will try to clear the idea. •If you set LOG_ARCHIVE_DEST parameter then this parameter is used to locate the archived redo log destination. •If you set DB_RECOVERY_FILE_DEST and and no LOG_ARCHIVE_

As a sysdba privilege issue "archive log list" to see your present archival destination settings. SQL> ARCHIVE LOG LIST Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 1 Next log sequence to archive 2 Current log sequence 2 •Based on the destination you can see the physical destination of your archived redo log file in the v$parameter. You can use, SQL> SHOW PARAMETER DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string /oradata2/flash_recovery_area db_recovery_file_dest_size big integer 2G Now a question is for which parameter settings my archived destination affects. In the following I will try to clear the idea. •If you set LOG_ARCHIVE_DEST parameter then this parameter is used to locate the archived redo log destination. •If you set DB_RECOVERY_FILE_DEST and and no LOG_ARCHIVE_

To simplify ongoing use of RMAN for backup and recovery, the RMAN lets you set a number of persistent configuration settings for each target database. To view these persistent configuration settings use SHOW ALL within RMAN command prompt. To change these persistent configuration settings use CONFIGURE ... command. If you want to clear anytime these settings to default mode then use, CONFIGURE... CLEAR command. Whenever you set any parameter by CONFIGURE ... these settings is used while backup and recovery strategy whenever you do not specify any other format within Run block or at RMAN prompt. However you can override these settings while taking backup. T he order of precedence is, 1.Set within Run Block. 2.Set at RMAN prompt. 3.Set with CONFIGURE Some Examples: -------------------- This example changes the default backup destination from disk to tape and then again backup to default. RMAN> show default device type; using target database control file instead of recovery catalog RMA

To simplify ongoing use of RMAN for backup and recovery, the RMAN lets you set a number of persistent configuration settings for each target database. To view these persistent configuration settings use SHOW ALL within RMAN command prompt. To change these persistent configuration settings use CONFIGURE ... command. If you want to clear anytime these settings to default mode then use, CONFIGURE... CLEAR command. Whenever you set any parameter by CONFIGURE ... these settings is used while backup and recovery strategy whenever you do not specify any other format within Run block or at RMAN prompt. However you can override these settings while taking backup. T he order of precedence is, 1.Set within Run Block. 2.Set at RMAN prompt. 3.Set with CONFIGURE Some Examples: -------------------- This example changes the default backup destination from disk to tape and then again backup to default. RMAN> show default device type; using target database control file instead of recovery catalog RMA

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 2008Copyright (c) 1982, 2005, Oracle. All rights reserved.connected to target database

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 2008Copyright (c) 1982, 2005, Oracle. All rights reserved.connected to target database