Here's what the user sent to me:
contents of Memory Script:
{
sql clone "alter system set db_name =
''ASFD'' comment=
''Reset to original value by RMAN'' scope=spfile";
sql clone "alter system reset db_unique_name scope=spfile";
shutdown clone immediate;
}
executing Memory Script
sql statement: alter system set db_name = ''ASFD'' comment= ''Reset to
original value by RMAN'' scope=spfile
sql statement: alter system reset db_unique_name scope=spfile
Oracle instance shut down
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/30/2015 00:47:38
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06024: no backup or copy of the control file found to restore
On Thu, Oct 1, 2015 at 9:42 AM, Andrew Kerber <andrew.kerber@xxxxxxxxx>
wrote:
Can we get the full output? Sometimes that simply means the pfile needs
to be updated with the new control file name.
On Thu, Oct 1, 2015 at 12:36 PM, Maureen English <
maureen.english@xxxxxxxxxx> wrote:
We have a client where they routinely recreate test databases by running
an
RMAN duplicate database script. This has worked for years...until they
lost
the drives on their test system where all of the test databases existed.
They
don't backup their test databases because the belief is that we can just
recreate
them with the RMAN duplicate database script.
The script is currently failing, saying it can't find any controlfiles.
Here are the two
main commands we're using in the script.
$ORACLE_HOME/bin/rman target sys/$sys_pass@$source auxiliary /
duplicate target database to $target nofilenamecheck;
I was under the impression that the nofilenamecheck parameter means that
it doesn't
look for any files for the test database that it is going to create.
Could the error be that it can't find the production backup files to use
to run the duplicate
database command? The mount points exist, and I can see the production
files from the
test server, but it's completely possible that some link didn't get
recreated correctly....
Any thoughts?
- Maureen
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
