Showing posts with label RMAN. Show all posts
Showing posts with label RMAN. Show all posts

Sunday, August 2, 2015

Oracle RMAN Active Database Duplication example

Introduction

Oracle RMAN Active Database Duplication is a new feature introduced in Oracle 11g R1. This option helps perform database copies without the need for relying on the source database backup. Oracle RMAN makes a copy of the source database (active database) at run time without the need of using its backup for the duplicate exercise. This option is very attractive when one is tasked with a “test database” to “test database” copy exercise (cloning exercise) as source test databases do not usually have backup jobs scheduled. Though it can be used for “production database” to “test database” copies as well, this method is not recommended because the RMAN duplicate command channels are launched on the source database host, thereby causing high load on the production database server.

Because the active database duplicate option does not rely on a backup, it cannot be used to perform Database Point-in-Time Recovery (“DBPITR”). Additionally, the source database must be in archive log mode if the duplication has to be performed without causing a downtime to the source database. Otherwise, the source database must be shutdown immediate and then startup mount.

Prerequisites

1) The source database must be in archivelog mode if one wants to duplicate it without shutting it down

2) If source database were a test database and enabling archive log mode is not necessary, then shutdown immediate and startup mount the source database.

3) When RMAN is connected to the auxiliary instance (destination to-be-duplicated instance), it must be provided with a net service name of it. This requirement applies even if the auxiliary instance is on the local host. Therefore, please add the tns entry  of the destination to-be-duplicated instance in the tnsnames.ora of the source database.

4) The source database and auxiliary instances must use the same SYS user password, which means that both instances must have password files.

5) The dynamic service registration cannot be used for the destination database while the RMAN active duplicate command is being executed. Hence only static service registration will work for the RMAN active duplicate to be successful.

6) Firewall access must be opened from source database server to destination database server  on the destination database's listener port number. (if they are on two different servers)

Assumptions

1) sys password is sys on both source and destination (to-be-duplicated) databases.
2) SRCDB and DESTDB are the names of the respective source and destination databases.
3) SRCDB has an spfile (server parameter file).

Prepare destination database (to-be-duplicated database)

1)  Login to oracle@target database server.

2) Create new directories on this server that exactly matches the source database's dignostic_dest folder and fast recovery area folder as the RMAN active database duplicate command in the next section specifically looks for the exact directory name on destination server too.

3)  Start the listener process.
4)   cd  $ORACLE_HOME/dbs
5)   rm  -f  orapwDESTDB     (Let us remove any existing password file. Replace DESTDB with the actual destination database name).

6)  orapwd  password=sys   file=orapwDESTDB     (Replace DESTDB with the actual destination database name).

7) cd $ORACLE_HOME/dbs

8) Remove  any spfile or pfile for the destination database (if exists)

9) Create a new initDESTDB.ora with just one parameter. ( (Replace DESTDB with the actual destination database name).

db_name = DESTDB

10) sqlplus   ‘/   as   sysdba’
11) startup   nomount;
12) exit;

Run the active database duplication command on source database server

1) Login to oracle@source database server
2) cd  $ORACLE_HOME/dbs

3) orapwd  password=sys   file=orapwSRCDB (If it does not exist already)
4) sqlplus   ‘/   as  sysdba’
5) alter   user   sys  identified  by  sys;
6) exit;

Note:  Please replace  DESTDB with the actual destination database name in the active duplicate command below.

7) tnsping   DESTDB   (make sure that the destination database listener can be accessible through SQL*Net from the source database server.  If not add an entry in tnsnames.ora and also make sure its listener is started on the destination server).
8) rman
9) connect   target   sys/sys@SRCDB;
10) connect   auxiliary   sys/sys@DESTDB;    
11)

run
{
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
allocate auxiliary channel a1 type disk;
allocate auxiliary channel a2 type disk;
set newname for database to '/u01/data/DESTDB/%b';
set newname for tempfile 1 to '/u01/data/DESTDB/temp01.tmp';
DUPLICATE TARGET DATABASE
  to DESTDB
  FROM ACTIVE DATABASE
  PASSWORD FILE
  SPFILE
  PARAMETER_VALUE_CONVERT 'SRCDB','DESTDB'
  SET CONTROL_FILES='/u01/data/DESTDB/c1.ctl'
  LOGFILE
  GROUP   1  ('/u01/data/DESTDB/redo1.log')   SIZE    50M,
  GROUP   2  ('/u01/data/DESTDB/redo2.log')   SIZE    50M ;
}


12) exit;

Wednesday, July 17, 2013

RMAN-06054 during rman restore and recovery

Introduction

You may encounter the "RMAN-06054: media recovery requesting unknown archived log ..." error when performing an incomplete database restore and recovery from an RMAN backup.  This error is not a cause of concern under normal circumstances when you use the simple rman restore and recovery commands without a point-in-time recovery such as an UNTIL_TIME recovery.

This blog post assumes that you have already restored/recreated the spfile/pfile and control file respectively and now ready to execute the restore and recovery commmands.

Errors

connect target /

RMAN> connect target /

connected to target database: HRDB (DBID=673562734533, not open)

RMAN> run
2> {
3> restore database;
4> recover database;
5> }

channel ORA_DISK_1: piece handle=/orabackup/databases/fast_recovery_area/HRDB/backupset/2013_05_09/o1_mf_nnndf_TAG20130509T181942_8ueyeiss_.bkp tag=TAG20130509T181942
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 10:14:12
Finished restore at 09-MAY-13

Starting recover at 09-MAY-13
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 1 is already on disk as file /orabackup/databases/fast_recovery_area/HRDB/archivelog/2013_05_09/o1_mf_1_1_8kr5hjek_.arc
archived log for thread 1 with sequence 2 is already on disk as file /orabackup/databases/fast_recovery_area/HRDB/archivelog/2013_05_09/o1_mf_1_2_8pejwkdi4_.arc
archived log file name=/orabackup/databases/fast_recovery_area/HRDB/archivelog/2013_05_09/o1_mf_1_1_8kr5hjek_.arc thread=1 sequence=1
archived log file name=/orabackup/databases/fast_recovery_area/HRDB/archivelog/2013_05_09/o1_mf_1_2_8pejwkdi4_.arc thread=1 sequence=2
unable to find archived log
archived log thread=1 sequence=3
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/09/2013 23:14:12
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 3 and starting SCN of 6945324467766 know.  

Solution

Oracle does not stop the recovery at the last available archive log in the database backupsets as per the restored control file.  Instead it keeps on requesting for the "next available archive log sequence" number.  But in reality, as per the above example, there is no log sequence 3.  So the database is already consistent after applying log sequence 2 (final archive log sequence as per the restored control file) and hence the recovery is in fact successful. Just try to open the database with the resetlogs option.  It should work.

rman>exit
sqlplus '/ as sysdba'
sql>alter database open resetlogs
You should get the "Database altered" message which indicates that the database was opened successfully.

Conclusion

If you know about a command or option that lets rman automatically stop the recovery at the last archive log sequence in the backupset, then please comment on our post below.  Such an option will help avoid getting the error in the first place.


Tuesday, July 16, 2013

Oracle RMAN backup based duplication example

Introduction

One of the new features of Oracle 11g R2 is the RMAN backup-based duplication.  One can clone an Oracle database using the source database backup without actually making a connection to it.  This provides a traditional database cloning like experience (relying on just the backups alone) with the ease of RMAN. In this blog post, I want to write about certain points that you may not be aware of the backup-based duplication

RMAN configuration settings are not duplicated

If the source database has special RMAN configuration settings such as retention policy, archivelog deletion policy, controlfile autobackup etc.,  all these settings are reset (lost) in the duplicated database.  So one has to manually enable these settings if one wants to retain them in the destination (new) database.  This blog post assumes that one is not using the recovery catalog (catalog mode)

Source database

RMAN> show all;
using target database control file instead of recovery catalog
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAYS; 
CONFIGURE CONTROLFILE AUTOBACKUP ON; 
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK; 



Destination database (built using the backup-based duplication)

RMAN> show all;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

Some init parameter values still contain source database references

If one uses a basic init parameter file  for the destination database (to be duplicated database) that includes file system paths such as  audit_file_dest,diagnostic_dest,utl_file_dir etc.,  then these are overwritten by the RMAN duplicate command with the spfile option and one may be suprised to see source database paths again in the destination database's init parameter file.  One should not forget to update them manually with the correct destination file system paths.

Some init parameter values contain a prefix containing both source and destination database names

After a successful backup-based duplication, one may be surprised to see a majority of the memory related initialization parameters containing two entries, one each containing the source database name and destination database name prefix.  If that is the case, then one has to manually delete init parameters containing the source database name prefix.  A below is one example

SOURCEDB.__db_cache_size=350000000
DESTDB.__db_cache_size=360000000
SOURCEDB.__java_pool_size=34567890
DESTDB.__java_pool_size=17534567

Also, a different matter is that the actual memory values are not exactly identical. One has to manually update the destination database init parameter values for memory if required.

Conclusion

The backup-based duplication is an excellent new feature in Oracle 11g R2 release for cloning databases. By following the above notes, one may avoid surprises after such a cloning exercise.

Saturday, September 22, 2012

datafile migration from filesystem to ASM

Introduction

Oracle has a standard procedure in the RMAN Backup and Recovery guide to migrate all the datafiles (full database) from a file system storage to ASM storage including redo logfiles too.  But sometimes a database may continue to have datafiles in the traditional file system storage as well as in ASM diskgroups.  The reason could be due to a lack of free space in the ASM disk groups and hence the need to store datafiles in filesytem.

This post explains how to clone or restore such a database (having datafiles both in a filesystem as well as ASM disks) into a destination host with datafiles only in ASM disks.

Steps

Let the filesystem location for the datafiles in source database be '/data/filesystem' with 10 datafiles in this directory and let the  destination ASM diskgroup be '+ASMDG' 

1)  On the source  database, prepare a simple select statement to generate output as below.

select 'set newname for datafile '||''''||file_name||''''||' to +'||''''||'ASMDG'||''''||';'
from dba_data_files
where file_name not like '%+%';


2) On the destination host, use the above generated output in the RMAN run block. For example, if the data to be restored is until Sep 06 2012, the below syntax can be used.

run
{
set until time "to_date('Sep 06 2012 08:00:00','Mon DD YYYY HH24:MI:SS')";
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
set newname for datafile '/data/filesystem/file1.dbf' to '+ASMDG';

set newname for datafile '/data/filesystem/file2.dbf' to '+ASMDG';
set newname for datafile '/data/filesystem/file3.dbf' to '+ASMDG';  
set newname for datafile '/data/filesystem/file4.dbf' to '+ASMDG';
set newname for datafile '/data/filesystem/file5.dbf' to '+ASMDG';
set newname for datafile '/data/filesystem/file6.dbf' to '+ASMDG'; 
set newname for datafile '/data/filesystem/file7.dbf' to '+ASMDG';
set newname for datafile '/data/filesystem/file8.dbf' to '+ASMDG';
set newname for datafile '/data/filesystem/file9.dbf' to '+ASMDG';  
set newname for datafile '/data/filesystem/file10.dbf' to '+ASMDG';
restore database;
SWITCH DATAFILE ALL;

}

Note 

The main goal of this post is to explain how to easily generate a "set name for datafile" command output from the source database and use the commands in the RMAN run block for the destination database.  Other RMAN commands for restore/cloning can be different based upon the actual situation.


Wednesday, June 27, 2012

RMAN Duplicate UNTIL TIME



If one uses RMAN to perform database backups, then the RMAN Duplicate command can be used to create new databases from these backups (also called clones or copies or duplicates of the source database).  If no additional options are provided in the RUN block of the RMAN interface, Oracle will build the new database as an exact duplicate of the source database upto the current time.

But sometimes IT application teams request for a copy that contains data "only until a time in the past".  In the user-managed backup and recovery strategy, we call it the "Time Based Recovery". One can achieve the same results with the RMAN DUPLICATE command also using the "set until time" option just before specifying the auxiliary channels.

The following is an example that creates a new database called PRODTEST which contains the same data present in PRODDB at "Jul 07 2012 08:00:00"

rman
connect  target sys/*****@PRODDB
connect  auxiliary /
run
{
set until time "to_date('Jul 07 2012 08:00:00','Mon DD YYYY HH24:MI:SS')";
allocate auxiliary channel c1 type disk;
allocate auxiliary channel c2 type disk;
allocate auxiliary channel c3 type disk;
allocate auxiliary channel c4 type disk;
duplicate
target database to PRODTEST
pfile=/sw/app/oracle/product/db_1/dbs/initPRODTEST.ora;
}

Saturday, May 5, 2012

How to drop a database


Introduction

The drop database command is the recommended command to drop an Oracle database. Though one can use operating system commands to remove database files instead of the "drop database" command, the latter is compulsory if one wants to drop a database using Oracle ASM (Automatic Storage Management).


DROP DATABASE command

It may be very rare that one is asked to drop a database. But this is usually the case when one wants to refresh existing test/development databases to clone them again from the latest production database backups. One may have to drop production databases too in the event of say, the front end application is retired/decomissioned  or the existing database data is migrated and merged to a different database etc. One needs to exercise a lot of caution and get the necessary approvals prior to dropping a production database. Furthermore, take a full database backup prior to dropping the database. 

  1. sqlplus '/ as sysdba'
  2. shutdown  immediate;
  3. startup mount restrict;
  4. exit
  5. rman
  6. connect target  /
  7. drop database;


Do you really want to  drop the database (enter YES or NO)?


The drop database commands deletes all the datafiles, tempfiles, online redo logfiles, spfile (server parameter file) and the control files.

DROP DATABASE command restrictions

The drop database command does not completely remove all the dropped database references in the server. Some of the dropped database related files such as the diagnostic files (trace files, alert logfile etc) are not deleted by the drop database command. Additionally, the Flash Recovery area files are not deleted too (incase the dropped database was using the Flash Recovery Area feature). 

DROP DATABASE command is a must for ASM

The operating system remove commands (for example, the rm command in Linux/Unix) can work only in databases that are stored on filesystems, but not for database files that are stored in ASM disks.  When an ASM diskgroup/disk contains database files from multiple databases, the drop database command "selectively" drops only the files associated with the database to be dropped from the ASM disks.

DROP DATABASE command works for ASM and non-ASM based databases

One can use drop database command for all databases which use the traditional filesystem storage as well as the ASM storage.

Dropping (removing) a database using operating system commands

Though drop database command is the recommended approach, one can also drop a database that uses traditional filesystem storage using operating system commands such as the rm command in Linux/Unix. Because this is a manual approach, one has to ensure that all the files that are part of the database are removed manually

  1. Datafiles
  2. Tempfiles
  3. Online redo logfiles
  4. Archived redo logfiles (if any)
  5. Flash Recovery area files(if any)
  6. pfile,spfile (if any)
  7. diagnostic files
  8. control files

Wednesday, December 28, 2011

RMAN Uncatalog using DBMS_BACKUP_RESTORE

Introduction

Most of the Oracle DBAs just rely on the command line RMAN interface ( $ORACLE_HOME/bin/rman ) to perform the rman backup and recovery commands. Every rman backup file (backup piece) generated is also called a backup piece handle. Some of the rman operations can be performed via the little documented DBMS_BACKUP_RESTORE package also and it turns out to be a quite useful in some cases such as when one wants  to uncatalog many RMAN backup pieces at once.

Problem

The other day I was transferring my RMAN backup pieces from one server to another server to create a clone database using rman restore and recovery commands. Due to some transfer issue, all the backup pieces (files) generated on a given day were corrupt during the transfer. Because Oracle Flash Recovery Area (FRA) was used, all the backup pieces were transferred to the FRA area. Some of you already know that FRA has a nicely laid out directory structure with one of the subdirectories containing the date the backup piece was generated.

For e.g /backup/flash_recovery_area/APPSDB/backupset/2011_02_15/o1_mf****_.bkp. Note the date 2011_02_15 in the directory path.

I already cataloged these backup pieces together using the catalog start with '/backup/flash_recovery_area/APPSDB/backupset/2011_02_15/' noprompt command.

Because these files were corrupted during the transfer process, the rman recovery failed. I fixed the problem using the below approach.

1) spool uncatalog_files.sql
2) set lines 200
3)
select 
'exec sys.dbms_backup_restore.deleteBackupPiece('||recid||','||stamp||','''||handle||''','||set_stamp||','||set_count||','||piece#||');'
from v$backup_piece 
where handle like '%2011_02_15%';
4) exit
5) Now run the uncatalog_file.sql file

The above dbms_backup_restore.deleteBackupPiece procedure removes the backup metadata about these corrupted files and also physically removes these files from the disk. Now transfer the backup pieces again from the source server to the destination server, catalog them again and retry your recovery. This time it must be successful.

Conclusion
One can also use the CHANGE backuppiece '#backup piece file name#' UNCATALOG command. But if there are dozens of backup pieces to be uncataloged all at once, the above dynamic generation of the uncatalog commands using dbms_backup_restore.deleteBackupPiece and v$backup_piece can be used.


Friday, April 22, 2011

Flash Recovery Area - Disable during recovery

Introduction

Flash Recovery Area (FRA) is one my favorite features in the Oracle Database. The FRA helps in automatic management of archive log files, RMAN backup pieces, control file autobackups and the flash back log files (if the FLASHBACK DATABASE is turned on). The FRA nicely creates all these files with well defined sub directory structure (based on dates) and also automatically deletes obsolete backup pieces (if the RMAN recovery window is set).

The other day, I was tasked with creating a clone of an Oracle 11g R1 (11.1.0.7) production database using the RMAN restore and recovery commands on the destination host. As usual, i made a copy of the production database's parameter file and edited it as per the new database (clone) settings. I did NOT remove any existing parameters though and retained all parameters including the FRA parameters viz. DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE

Problem

Our RMAN restore was not successful as just before the restore started, Oracle strangely deleted two datafiles (as per the alertlog) and then RMAN first created two empty datafiles with the same name which were deleted and then started the actual restore. These two datafiles were created years ago on the production database and they were online datafiles. Nothing wrong with them.


**FROM THE ALERT LOG***

Thu Mar 24 10:49:24 2011
Deleted Oracle managed file +ORADATA/prod_myhost_db/datafile/fints_index2.1887.709799705
Deleted Oracle managed file +ORADATA/prod_myhost_db/datafile/fints_index2.1906.723204215

**FROM THE RMAN LOG**

creating datafile file number=1630 name=+ORADATA/prod_myhost_db/datafile/fints_index2.1887.709799705
creating datafile file number=1649 name=+ORADATA/prod_myhost_db/datafile/fints_index2.1906.723204215

channel d1: starting datafile backup set restore
channel d1: specifying datafile(s) to restore from backup set
channel d1: restoring datafile 00030 to +ORADATA/prod_myhost_db/datafile/sales.1690.700575591
channel d1: restoring datafile 00063 to +ORADATA/prod_myhost_db/datafile/argus2_index2.263.700567185
channel d1: restoring datafile 00083 to +ORADATA/prod_myhost_db/datafile/bits_index2.1800.700576857
channel d1: restoring datafile 00112 to +ORADATA/prod_myhost_db/datafile/cbo_data2.1826.700576943
....
....
....

Solution

I got this working by disabling the FRA. I commented the two FRA parameters DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE in the destination database's init parameter file. Then I recreated the +ORADATA ASM diskgroup (formatted the ASM disks to remove data from the other files that got restored so far) and restarted the restore. This time the restore was successful.

Conclusion

Turn off the FRA (remove/comment the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE) on the destination database until the cloning process is over (restore and recovery). Once the new database is opened successfully, the FRA can be turned on again.

Thursday, June 3, 2010

Question on restoring SPFILE after a complete database server crash

Introduction

I am posting a database recovery related question asked by one my blog's visitors' last week for restoring an spfile. A few additional steps are necessary if the database is using ASM technology.

[06:19] sunil: i had a catalog db and i m taking the bkp of target db in to tape drive, all of a sudden my target server crashed(means i lost everything includibg spfile,now i want to built a new server and want to restore the bkp from tape drive,how it'll happen.

[06:19] sunil: how i can restore my spfile?

Sunil,

It is not very tough to restore the spfile. Please try the below commands to restore your spfile. For simplicity, I am making the following assumptions.

1) You have used RMAN and a seperate CATALOG database for your backup strategy.
2) You still know the DBID of your "crashed" database. If you don't have your backup logfile, you can still find the DBID by querying the RMAN Catalog. Let it be 123456789
3) You have made the tapes containing your backup accessible to the new server.

A)

rman
connect target /
connect catalog catuser/catuser@catdb
set DBID 123456789
startup force nomount;
exit


B)

rman
connect target /
connect catalog catuser/catuser@catdb
set DBID 123456789
run
{
allocate channel t1 type 'SBT_TAPE';
restore spfile;
}
exit

c)

sqlplus '/ as sysdba'
create pfile from spfile;
shutdown immediate;

D)

Restore CONTROLFILE and update PFILE with new controlfile location

E)
The following additional steps must be performed if you have ASM for your database.
Let +ASMDATA be the diskgroup name for storing the spfile.

sqlplus '/ as sysdba'
create spfile='+ASMDATA' from pfile;
exit

cd $ORACLE_HOME/dbs
mv pfile pfile.old

Create a new pfile with the below contents after verifying the exact name of the restored spfile from v$asm_alias view
SPFILE='+ASMDATA/DBNAME/parameterfile/spfile_name_in_asm_alias_view'

rm the spfile on disk in $ORACLE_HOME/dbs directory.

The below command will startup the database using the above pfile which points to the actual SPFILE


sqlplus '/ as sysdba'
startup mount;

Wednesday, February 10, 2010

RMAN Active Duplicate Advantages

Introduction

We are planning to start upgrading some of our enterprise Oracle databases from 10g to 11g and I am evaluating the new features of Oracle 11g that our organization can be benefited from. A 11g new feature that has caught my attention is the 'ACTIVE Database Duplicate' option in Oracle RMAN. This feature allows a database to be duplicated directly from its live source database instead of using its backup.




Advantages
Instant Database Clones possible (On Demand Cloning)


If one requires a database clone, all one has to do is to run the active database duplicate command after specifying the source and destination databases. I call this Cloning onDemand ! This helps organizations create test database environments in a rapid and simpler fashion.

EMC TimeFinder BCV sync/split is not necessary


Consider an organization relying on BCV sync/split technology to perform database clones. In this case one must take the help of a system administrator to perform the BCV sync/split operation. A database is put in hotbackup mode and the BCV split process is performed. Once the operation is completed, the database is taken out of backup mode. This is all additional work and the Active Database Duplication eliminates all these steps as it performs a direct copy.

Staging ASM Diskgroup is not required



Consider the case when ASM (Automatic Storage Management) is used as the underlying disk management technology for an Oracle database. An ASM-2-ASM database clone always requires a consistent BCV sync/split operation and this during process the ASM disk headers are copied to the destination host. This requires staging (intermediate) ASM Diskgroups on the destination host with the same name as that of the source database's ASM diskgroups. After the consistent BCV sync/split is completed, data is again copied from the staging ASM diskgroups to the clone database's diskgroups(DEV/TEST diskgroup names). Active Database Duplication eliminates the need for staging ASM diskgroups, thus saving a lot of diskspace (equal to the total size of the database being cloned)

No additional space required


In the traditional backup-based database duplication, one has to make the backups accessible to the destination host before the duplication is started. For tape backups, this equates to moving the tape to a drive attached to the destination host or using a network-accessible tape server. For disk backups, this equates to copying the backup to the destination host (additional space). Active Database Duplication does not require backups and hence the additional disk space requirement is no longer needed on the destination host.

Restrictions



Incomplete recovery NOT possible (no SET UNTIL)

Active Database Duplication cannot be used to duplicate a database until a point in time. One has to rely on the backup-based database duplication method if one wants to create a duplicate database until a specific point in time ( a specific time, log sequence or SCN). Furthermore, active duplicate copies data only until the last archived log file in the source database. The contents of the online redologs will not be copied to the duplicate database.

Monday, August 18, 2008

Database and archive log backup in one RUN command

Introduction


We went live with 10.2.0.4 Oracle CRS this weekend, completing the 5 month 9i to 10g database upgrade project. I also verified the first RMAN backup job after the upgrade and it completed successfully. A known issue with the backup job in 9i no longer exists after the 10g upgrade, acting as an additional bonus of the upgrade !

Problem


We take full database backups always without any incremental backups. Though the below run block contains two backup commands, one for the database backup and the other for the archive log backup, the latter never used to get picked up in 9i. In this older version, Oracle always skipped the second backup command in the below run block without reporting any error messages or warnings.

connect rcvcat 'rmanprod/*****@catdb'
connect target '/'


run {
allocate channel t1 type 'SBT_TAPE';
allocate channel t2 type 'SBT_TAPE';
backup
format 'prod_bk_%s_%p_%t'
(database include current controlfile);
# backup all archive logs
backup
skip inaccessible
format 'prod_al_%s_%p_%t'
(archivelog all
delete input);
release channel t1;
release channel t2;
}
allocate channel for maintenance type 'SBT_TAPE';
crosscheck backup of database;
delete expired backup;
release channel;


Solution

Since we have a different backup job to backup only archive logs, we did not pursue this problem with Oracle Support. I am not sure if this is a known issue in 9i version, but pleasantly surprised to find this problem go away in 10g. The first backup job that we run after the 10g upgrade successfully processed both the database backup command and archive log backup command in the same RUN block. The 9i mystery seems to have gone away in 10g. I am interested to know if some of you observed the same issue with 9i before ?

Saturday, June 14, 2008

RMAN DUPLICATE - Not everything is made using the CATALOG alone?

Introduction

We just wrapped up our 10g RMAN testing. To test recovery using our RMAN backup, we have used the RMAN DUPLICATE command to create a duplicate database using this backup. I have noticed something about the DUPLICATE command that i have missed so far: The DUPLICATE command creates the duplicate database's controlfile using information from BOTH the existing target database's controlfile and the backup controlfile, not just the latter alone.

Test Case

1) dev10g is an existing development database that has got upgraded to 10g version
2) dev10g is in noarchivelog mode (like most development databases do)
3) dev10g is converted to archivelog mode to take a RMAN backup including full database and archivelogs backup
4) dev10g archiving is disabled (noarchivelog mode again)
5) dup10g is the proposed new database that will be created using the RMAN backup of dev10g.
6) DUPLICATE command is run on the dup10g database's host.
7) DUPLICATE command fails after restoring the datafiles.

From the logfile.....

contents of Memory Script:
{
set until scn 8321617961105;
recover
clone database
noredo
,
delete archivelog
;
}


..
..
..


RMAN-00571: =======================================
RMAN-00569: ===== ERROR MESSAGE STACK FOLLOWS =====
RMAN-00571: =======================================
RMAN-03002: failure of Duplicate Db command at 06/09/2008 23:41:15
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database:
ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/dbfs/oracle/oradata/dev10g_sys01.dbf'

Problem

The target database dev10g was converted to noarchivelog mode in the 4th step above after the RMAN backup was taken. However, the DUPLICATE command *considers* there are no archivelog files to be applied to dup10g because the target database's controlfile shows the database is in noarchivelog mode. Though dev10g's archivelog files were backed up when the backup commands were run in the 3rd step above, DUPLICATE generates an internal script that forbids the archivelog apply because the target database's current controlfile shows its in noarchivelog mode.

Solution

Enable archiving in the target database when DUPLICATE is running, even though its a development database that does not require archiving. It can be disabled once the duplicate database is created successfully.

One may not encounter this problem when the target database is a production one, because production databases are usually in archivelog mode; however, one may encounter this problem when the target database is a development one when its archiving is disabled after an RMAN backup.

Thursday, June 12, 2008

RMAN debug

RMAN automates Oracle database's backup and recovery processes. If you would like to know what happens inside an RMAN command,(RMAN Internals), then try the debug option. Also, when you have a case opened on any RMAN issue, the debug logfile can help a support analyst quickly locate the source of your RMAN problem.

Its very easy to turn on the debug feature.

/home/oracle/backup_testing> rman log=output.log trace=debug_info.log
RMAN> debug on
RMAN> RMAN Command 1;
RMAN> RMAN Command 2;
....
....
....
RMAN> exit

The debug_info.log contains all the internal details. BTW, you will not find information about this feature in the Oracle Documentation.

Thursday, May 29, 2008

RMAN DUPLICATE - automatic temp files recreation

As part of our 10g upgrade project, we are testing our existing RMAN scripts, especially the DUPLICATE command that we use to clone databases. In one my previous posts, i have already outlined the procedure to clone a database using the DUPLICATE command.

It works fine in 10g too; however, an added benefit in this release is that it recreates the temp files automatically. The temp files for the destination database will be created in the directory specified by the DB_FILE_NAME_CONVERT parameter with file names and file sizes similar to the source database. This eliminates the manual recreation of the temp files after every database clone performed with the DUPLICATE command.

With this new feature in 10g (specifically it is an Oracle 10g R2 new feature) the DUPLICATE command eliminates one more manual step performed during the database cloning process.

Thursday, September 27, 2007

RMAN Duplication to a new host using Veritas Netbackup in Oracle 9i

We use Veritas Netbackup 5.1 as the Media Management Software for creating our production tape backups. Yesterday, I successfully created a RMAN DUPLICATE database on a different host using these tape backups .I am documenting the procedure below

NAMING CONVENTIONS

1)RMAN target = source database of the RMAN backups
2)duplicate database = destination database that needs to be created from the source database backup
3)auxiliary database = duplicate database
6)RMAN repository = separate schema (RMAN catalog) in a separate database that contains source database’s backup details
7)dev7 is the name of the duplicate database to be created
8)Media Manager Server = Netbackup Media Manager Server.
9)Media Manager Client = source database host
10)PROD = source database name
11)DEV = duplicate database name
12)RMANCT = RMAN catalog database name
13)RMANPROD = RMAN catalog repository schema name

CREATE DESTINATION DATABASE osuser and group SIMILAR to SOURCE DATABASE osuser and group

One of the requirements of RMAN duplication using VERITAS NETBACKUP is that the destination database's osuser and group should be similar to what it is in the source database node

e.g If source database ORACLE_HOME owner is oracle:dba, the destination database ORACLE_HOME owner should also be oracle:dba

MAKE BACKUP TAPES accessible to DESTINATION HOST

1)Contact your NETBACKUP system administrators to the source database BACKUP TAPES accessible to DESTINATION HOST

2)Verify by the following command

a) Login oracle@destination_db_host
b) /usr/openv/netbackup/bin/bplist -C source_db_host -t 4 -l -R /

The above bplist command should list all the backup sets that are in the RMAN catalog

Prepare Duplicate database

1)Login oracle@destination_db_host
2)Copy the source database's initSID.ora to the destination host and add a new parameter DB_FILE_NAME_CONVERT. For e.g if the source database files are in /oracle/prod/d1 and /oracle/prod/d2 directories and if the corresponding restoration paths in the destination host are to be /oracle/dev/d1 and /oracle/dev/d2 respectively,

DB_FILE_NAME_CONVERT=(/oracle/prod/d1/,/oracle/dev/d1/,/oracle/prod/d2,/oracle/dev/d2/)

3)sqlplus '/ as sysdba'

4)startup nomount

5)Edit the $TNS_ADMIN/tnsnames.ora and add connection descriptors for the source database PROD and its catalog database RMANCT

Run the DUPLICATE command

RMAN always restores from the latest tape backups by default to create new database with the DUPLICATE command.

1)Login to oracle@destination_host

export NB_ORA_CLIENT=source_host

2)Connect to RMAN

rman LOG=/tmp/client/dev.log
connect target sys/***@prod
connect catalog rmanprod/****@rmanct
connect auxiliary /


3)Issue the Duplicate commands

RUN
{
allocate auxiliary channel t1 type 'SBT_TAPE';
allocate auxiliary channel t2 type 'SBT_TAPE';
SEND 'NB_ORA_SERV=media manager server, NB_ORA_CLIENT=source_host';
duplicate
target database to dev
pfile=/ora_base/oracle/devdb/9.2.0/dbs/initdev.ora
logfile
'/oracle/dev/logs/dev_log1.dbf' size 256M,
'/oracle/dev/logs/dev_log2.dbf' size 256M,
'/oracle/dev/logs/dev_log3.dbf' size 256M
}


4)Verify the dev alert log and the RMAN log /tmp/client/dev.log
5) The whole restore process will happen over the network depending on the network speed and the source database size

Restoration of only archive logs from RMAN

1) Login oracle@destination_host
2) select * from v$instance ( it should show ‘MOUNTED’ status)
3) shutdown immediate
4) Login oracle@source_host
5) Restore the archivelog files with a separate RMAN command.

rman
connect target /
connect catalog rmanprod/****@rmanct
run
{
allocate channel t1 type 'SBT_TAPE';
set archivelog destination to '/home/oracle/';
restore archivelog
from time "to_date('09/24/07 8:00:00', 'mm/dd/yy hh24:mi:ss')" until time "to_date('09/24/07 13:00:00', 'mm/dd/yy hh24:mi:ss')";
}

7)Verify the restored archive logfiles in /home/oracle/
8)Copy them to destination node using rcp or scp command
9)Login to destination node oracle@destination_host
10)Mount the destination database dev and recover manually using the 'recover database until cancel using backup controlfile' command
11)Type ‘cancel’ after applying the necessary archive logfiles to make the destination database consistent
12) alter database open resetlogs
13) Create the temporary tablespace

How to create a duplicate database until a specific time in the RMAN repository

The procedure remains the same except one more ‘set until’ command. The set until time command has to be put in the run block just before the duplicate command to create the duplicate database upto a specific point in time.

set until time= "to_date('mm/dd/yyyy hh24:mi:ss', 'MM/DD/YYYY HH24:MI:SS')";

Affect of Duplicate command on Recovery Catalog

There is no affect of duplication on the recovery catalog. RMAN generates a new DBID for the duplicate database. Unless this DBID is registered in the catalog, RMAN does not create or update any records for the newly created duplicate database.

It is not necessary to register the newly created duplicate database in the RMAN catalog unless the newly created duplicate database wants to use RMAN for its own backups

Tuesday, September 18, 2007

Working on RMAN Duplication to a different host

Since a week i am working on changing our Oracle 11i E-Business Suite Database cloning procedure. In the current method the source database is put in hotbackup mode, data files and the needed archive logfiles are copied to the destination host and the clone/test database is created.

But the problem with this current method is we are not really testing the source database backups. A good DBA should always create test/clone databases from the source database backups instead of copying datafiles in backup mode. Our production database has a full biweekly RMAN tape backup. Though these backups are successful as per their "log files", they have never been used as a source to create for cloning purposes.

The right procedure now is to use these RMAN tape backups and then perform database cloning using the RMAN DUPLICATION feature.

We use VERITAS NETBACKUP as the Media Management Software for the RMAN tape backups. I am working with the Unix system administrator, NETBACKUP administrator but encountering some NETBACKUP errors. We opened a ticket with Veritas and i will blog again once the issue is resolved. I will also detail the issue rootcause and the solution for it.