DBA Maestro - Helpful DBA tips

RMAN-05001: auxiliary file name <file_name> conflicts with a file used by the target database I ran into an issue where I was trying to clone a new copy of non-production database (using production database as the source) by leveraging the RMAN clone via active database to save me some time and work.   I ran into the error where I couldn't successfully clone the database.  I made sure that my environment, pfile, RMAN script were configured correctly.  After much time of troubleshooting, I figured out the issue. After remembering that the source database had a DG environment, it occurred to me that was what was  causing  the error.  Reason being, the source had log_file_name_convert and db_file_name_convert configured which was being "carried over" onto my auxiliary instance hence causing the error mentioned above.  So all I needed to do was simply reset those two parameters within my RMAN script (as seen below) and I was able to suc...

I recently experienced some type of a network hiccup of some sort resulting in a failed duplicate database using active database methodology for Oracle 11g.  The below error was the one I received for several datafile copies which is the first steps in the duplicate with active database process.  Some were missed/didn't get copied over for some reason. RMAN-03009: failure of backup command on prm2 channel at 05/01/2011 04:50:02 ORA-17629: Cannot connect to the remote database server ORA-17629: Cannot connect to the remote database server continuing other job steps, job failed will not be re-run This resulted in the below error: RMAN-03009: failure of backup command on prm4 channel at 05/01/2011 23:20:53 ORA-17629: Cannot connect to the remote database server ORA-17629: Cannot connect to the remote database server Here is how I manually completed the clone after the failure occurred: 1. Copy over the missing datafiles from primary via RMAN. connect target sys/passwor...

I found a great blog entry around cloning a database from an 11g physical standby.  I decided to complete the steps myself. The method basically entails turning your physical standby into a snapshot standby database via dgmgrl (11g only). For 11gR2, flashback logging is not a requirement.  Otherwise, flashback logging being enabled is a requirement as converting physical standby into snapshot standby requires a guaranteed restore point to be created; this allows the snapshot standby to be converted back into physical standby. Setting db_recovery_file_dest and db_recovery_file_dest_size are configured is the only caveat. 1. Startup clone instance with startup nomount. SQL*Plus: Release 11.2.0.1.0 Production on Wed May 11 13:06:12 2011 Copyright (c) 1982, 2009, Oracle.  All rights reserved. Connected to an idle instance. SQL> startup nomount ORACLE instance started. Total System Global Area  217157632 bytes Fixed Size        ...