RMAN :: Encryption / Decryption When Using RMAN To Duplicate / Clone?
May 8, 2013
Given facts:
rman is used to backup database A to disk
rman is used to put those disk backups to tape
rman is used to duplicate database A to database B on another host
the duplicate process worked fine before we started testing encryption
the duplicate process worked fine with database A having an encrypted column in one table in a non-encrypted tablespace
Now, database A has an encrypted tablespace with nothing currently in it. The duplicate process now ultimately fails with ORA-19913, unable to decrypt backup.
I am not using encrypted backups, not specifying encrypt or decrypt anywhere in the duplication process. The only thing that is encrypted is the one tablespace in database A. I have the same wallet files on Host A (database A) and Host B (database B). Wallets are open. So why does the duplication process fail because the backup cannot be decrypted?
I am cloning my prod db to test with the rman active clone command. I can successfully clone my DB, but after a few hours or so I see messages in the alert log that I have corrupted blocks in several datafiles. Note, i dont see these messages in my PROD DB therefore I think that DB has no corruption. I have few questions:
1) I was reading tha having tables or indexes set with the NOLOGGING option can cause objects to be unrecoverable. Would this affect my active clone?
2) I know you can either change a DB or tablespace to force logging. Is there a query I can use to determine if the DB is in force logging mode.
ALTER TABLESPACE tablespace_name FORCE LOGGING; ALTER DATABASE FORCE LOGGING;
3) Lastly how to check as why my clone DB would have corrupted blocks.
Here is the clone command I am using.
rman catalog=rman/rman@proddb target=sys/sys@proddb << EOT connect auxiliary sys/sys@clonedb duplicate target database to clonedb from active database nofilenamecheck pfile=/u01/app/oracle/product/11g/dbs/initclonedb.ora ; exit EOT
I'd like to confirm whether its possible to clone a database instance from a RAC cluster to a single server, with an additional issue that the RAC cluster is running Oracle 10g and the single server is running 11g. Can I do that directly or do I need an intermediate step to upgrade the database instace to 11g? Or can I even use exp/imp on RAC?
We have a script which uses the duplicate functionality of RMAN. It was designed for a standalone database. Now I need to make it work for a cluster DB (RAC installation).
1. Does RMAN support this? 2. Do I need to make separate executions for both the nodes of the cluster?
We are currently blocked because we have no way of getting our system running without this! ******************************8 First attempt:
3808 11:52:49 ----- Starting Cloning Procedure ----- 3808 11:52:50 INFO: Client host 'sf25' says, it is 'sf25'. 3808 11:52:51 Getting Original DB Name on the source host (referred by ADVFRW_sf25 TNS-name)... ... 3808 RMAN: GROUP 8 ( '/export/home/oracle/dev/ADVFRW/ADVFRW.redo181' ) SIZE 134217728 REUSE 3808 RMAN: DATAFILE 3808 RMAN: '/export/home/oracle/dev/ADVFRW/ADVFRW.system' 3808 RMAN: CHARACTER SET WE8ISO8859P1 [code]....
5548 12:27:05 ----- Starting Cloning Procedure ----- 5548 12:27:06 INFO: Client host 'sf25' says, it is 'sf25'. 5548 12:27:07 Getting Original DB Name on the source host (referred by ADVFRW_sf25 TNS-name)... 5548 12:27:07 Original DB is 'ADVFRW' 5548 12:27:08 INFO: BGROUP=Srv [code].......
Now we have contrary error messages. Target DB name ADVFRW does not work, because on the target nodes there are configuration files for the node specific DB names (ADVFRW1.ora on first node resp. ADVFRW2.ora on second node). But with the node specific DB name the script fails, because it does not match with the DB name of the source system.
I tried to clone a 2 node rac database to single instance non rac database using existing backup. I have not used connectivity to target or catalog. rman duplicate finished with below messages:
rman auxiliary sys/******@dbracdup RMAN> duplicate database to dbrac spfile backup location '/oracle/backup'; ... ... Finished recover at 25-JUL-12 Segmentation fault
And the database was in mount stage, and when i tried to open database it failed with below error:
SQL> alter database open; alter database open * ERROR at line 1: ORA-19838: Cannot use this control file to open database .
Performing backups on the physical standby via RMAN. We need to restore our test database, and right now it is equivalent to the production. The DUPLICATE command seemed the best bet. We have controlfile and SPFile both on Auto-backup, and the RMAN on a six day retention with weekly 0 level backups and nightly level 1 cumulative backups.
However, when I run the DUPLICATE it chokes being unable to find a current controlfile nor one in backup, even though we have six days worth of supposedly good (validated) backups. We are not using a catalog, rather the DB controlfile.
The solution to this error is reopen the database and try again. however, the physical standby cannot be opened. It is the standby. What if we move the last backup to the primary database, "register" it there, and try this DUPLICATE?
I have seen nothing on this in my searches, and the Oracle documentation does not address this, though it recommends backup from the Physical Standby.
I want to duplicate a prod database in to a dev db.I am using catalog database to connect to target and auxiliary datbase.I copied all backupsets to the local disk on Dev env in the correct path.For RMAN duplicate ,does the backuppeices need to be present on PROD filesystem as well or just DEV filesystem or both.
on 11g R2 on Win 2008, I want to duplicate my target DB which is on a a remote server using RMAN backups. The destination is on local server. I will run RMAN on local server.
In initnewdb.ora, I should add :
# Convert file names to allow for different directory structure if necessary. #DB_FILE_NAME_CONVERT=(/u01/app/oracle/oradata/DB11G/,/u01/app/oracle/oradata/NEWSID/) #LOG_FILE_NAME_CONVERT=(/u01/app/oracle/oradata/DB11G/,/u02/app/oracle/oradata/NEWSID/)
my questions :
1-In my case would it be :
# Convert file names to allow for different directory structure if necessary. #DB_FILE_NAME_CONVERT=(\remoteserver:/u01/app/oracle/oradata/DB11G/,/u01/app/oracle/oradata/NEWSID/) #LOG_FILE_NAME_CONVERT=(\remoteserver:/u01/app/oracle/oradata/DB11G/,/u02/app/oracle/oradata/NEWSID/)
2- should we keep the convert parameters in init.ora file after duplication for always ?
I try to use rman duplicate database to bring entire databse form Windows XP system to another Windows XP. I have been trying to use rmain duplicate database without success.
I failed on "startup force nomount......". The system always prompt me an error as "ORA-12514: TNS:listener does not currently know of service requested in connect descriptor" and following by TNSLSNR.exe has encountered a problem and need to be close......"
I have tried to re-install the oracle multiple times and failed at the same problem as above. So, I am thinking of using imp and exp to do the work. Is it possible? If yes, how to do it.
i am trying to duplicate database on another oracle server. i am getting following errors when i use command in rman orapwd was created on original /source/ db and transferred to destination server.
rman auxiliary sys/pwd@ORA
Recovery Manager: Release 11.2.0.1.0 - Production on Tue Oct 2 02:37:51 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to auxiliary database: ORA (not mounted) RMAN> duplicate database to "ora" backup location "O:ackup"; Starting Duplicate Db at 02-OCT-12
contents of Memory Script: { sql clone "create spfile from memory"; } executing Memory Script
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of Duplicate Db command at 10/02/2012 02:38:36 RMAN-03015: error occurred in stored script Memory Script RMAN-04006: error from auxiliary database: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
RMAN>
when i try to reconnect to rman it throws:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00554: initialization of internal recovery manager package failed RMAN-04006: error from auxiliary database: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
i have to startup in nomount again
ORARCLE_SID is set to ora
backup of db was created from source db by:
RMAN> run{ 2> configure controlfile autobackup format for device type disk to 'd:/backup/%F'; 3> configure controlfile autobackup on; 4> allocate channel d1 type disk; 5> backup tag FULL_DB format 'd:/backup/db_%t_%s.bk' (database); 6> release channel d1; 7> }
able to utilize "RMAN Restore of Backups as Part of a Database Upgrade [ID 790559.1]" and duplicate an 11.1 PRD DB to another server that only has the 11.2 software. When I attempted this, I got an error since the target DB is a earlier version than the rman client - "RMAN-06429: TARGET database is not compatible with this version of RMAN".
I tried to avoid connecting to the target database & just use the following syntax (duplicate 'prd' DBID 123456789 to 'dev') to let rman know about the backups it would need from NetBackup.
That also got an error - RMAN-01009: syntax error: found "single-quoted-string": expecting one of: "database, for, target, to". I tried other variations, but also got errors.
I may try this from a disk based backup, but have to wait to get a large enough NFS mount to be able to complete this. The following syntax was in the 11.2 rman docs:
DUPLICATE DATABASE 'PROD' dbid 8675309 to 'TEST' UNTIL TIME "to_date('11/01/2007', 'MM/DD/YYYY')" BACKUP LOCATION '/backups' NOFILENAMECHECK PFILE='?/dbs/inittest.ora' db_file_name_convert='prod','test';
Our goal is to not have to install the 11.1 software on our new servers. Also, trying to avoid restoring with the same name & then renaming the DB so that ASM would have multiple directories for the DB.
OS: RHEL 6.3 for target host OS: RHEL 5.9 for target host Target DB: 11.1.0.7.12 - PRD Auxiliary DB: 11.2.0.3.5 - DEV
I am able to duplicate (from active database) 12.1.0.1 database to destination server successfully,however when I add either compressed backupset and/or section size to duplicate commandrecovery at the end of the operation fails due to missing archive log (which is at source server)
******************************************failed duplication****************************************** [oracle@r121 ~]$ rman target sys/sys_pwd@t12 auxiliary sys/sys_pwd@c12Recovery Manager: Release 12.1.0.1.0 - Production on Fri Sep 6 11:30:09 2013 Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved. connected to target database: T12 (DBID=1222223202)connected to auxiliary database: T12 (not mounted) RMAN> duplicate target database to c12 from active databasesection size 2gspfileparameter_value_convert 't12', 'c12'set db_file_name_convert 't12', 'c12'set log_file_name_convert 't12', 'c12'nofilenamecheck;2> 3> 4> 5> 6> 7>Starting Duplicate Db at 06-SEP-13using target
How can we tune our RMAN Duplicate as it was taking 10+ hours to finish. Current production database size is 800GB. Approx duration of rman online backup (FULL, including archived logs) is 4 to 5 hours.
Here's the rman backup script we used: sql 'alter system archive log current'; list archivelog all; run { show all; report schema; backup database plus archivelog delete all input; } exit
Here's the rman duplicate command we used: run { set until time "to_date(to_char(sysdate,'Mon DD YYYY') || ' 02:30:00', 'Mon DD YYYY HH24:MI:SS')"; allocate auxiliary channel ch1 type disk; duplicate target database to testdb; } exit
While cloning using RMAN DUPLICATE command, one can convert all files from various locations to new locations by using DB_FILE_NAME_CONVERT. One can also retain the same locations with no conversion by using NOFILENAMECHECK. My question is what if I want to convert some, and not convert others?
Previously it is working fine but today when i am trying to duplicate a database using rman not getting exactly error but the o/p is as below
C:Usersdbadmin>rman target sys/tiger@na Recovery Manager: Release 11.2.0.1.0 - Production on Thu Jun 27 15:33:33 2013 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: NA (DBID=1572981579) RMAN> connect auxiliary sys/tiger@da connected to auxiliary database: NOIDA (DBID=1572981579, not open)
It is correct that the rman is connected to the db with name na but not with db da Previously i am able to connect both the instance.
I want to remove matching dbid's from the rman catalog without compromising te integrity of the catalog. I do however know a single way of removing them and its using the dbid and db_key which in my case are not not unique. The funny thing is they've running normally for a year now.
Oracle 10.2.0.5Linux 5I am creating a duplicate database using RMAN based on Oracle's documentation. I was successful up to running the duplicate command.Here is my command:DUPLICATE TARGET DATABASE vlab pfile='/<complete path of pfile>'; When I run the command, it tries to read from the backup files on production database - which is on anotehr node.Before then, I had backup piece copied to the node with the duplicate database.I ran this command to catalog the backup piece:catalog start with '/<complete path to backuppiece>'Error: no files to be unknown to the database On the other hand, when I run the command without cataloging the backuppiece, I get this error:
Partial view of error- restoring datafile 00021 to /oraappl/pca/vptch/vlabdata/staff101.dbf restoring datafile 00022 to /oraappl/pca/vptch/vlabdata/staff201.dbf restoring datafile 00023 to /oraappl/pca/vptch/vlabdata/tools01.dbf restoring datafile 00024 to /oraappl/pca/vptch/vlabdata/vol01.dbf restoring datafile 00025 to /oraappl/pca/vptch/vlabdata/volsup101.dbf restoring datafile 00026 to /oraappl/pca/vptch/vlabdata/volsup201.dbf channel ORA_AUX_DISK_1: reading from backup piece /oraappl/pca/backups/weekly/vproddat ackupset/2013_08_27/o1_mf_nnndf_TAG20130827T083750_91s7dz0r_.bkp ORA-19870: error reading backup piece /oraappl/pca/backups/weekly/vproddata/rman/VPROD 3_08_27/o1_mf_nnndf_TAG20130827T083750_91s7dz0r_.bkp ORA-19505: failed to identify file "/oraappl/pca/backups/weekly/vproddata/rman/VPROD/b
I have a RUN file within a script to duplicate a database. As part of this RUN file I also run the command configure controlfile autobackup off; as part of this RUN file. However, this command has turned off backup of the control file on the AUXILLARY database (i.e. production) as well as the TARGET database (test). Is this supposed to happen?
My run file is:
rman TARGET sys/XXXX@${DB}-SOURCE AUXILIARY / RUN { allocate AUXILIARY channel a1 type disk; allocate AUXILIARY channel a2 type disk; allocate AUXILIARY channel a3 type disk; allocate AUXILIARY channel a4 type disk;
In DR site. i have to clone the database from pshysical standby database and clone db will be normal db not standby. Is it possible to do rman duplicate from active dataguard? will it support the duplicate database from active database or i have to take the rman backup of standby database and duplicate from backup piece.
I have oracle 11.2.0.3.0 in Windows 2008 server R2 64 bit version. I have installed database ASMDB with ASM ... Now i have another one machine , I want to clone my database in that machine with Non ASM file system .. Can any one tell me step by step document to do it ?
Can i keep the database name as ASMDB in another Machine ?
In my catalog for the "source" database (rman target db), I have the backupsets for a full database backup ended at Feb. 7, 03:43:37. These are online backups. So, there are archived redo logs being generated while it runs and the following archived redo logs finished at Feb. 7, 04:00:24.
We duplicate databases all the time. So, this is not a new concept for us. The one thing that has changed is that we now back up to disk (using the flashback recovery area) and then later on, initiate a backup to tape. Prior to this go-live, we did all of our backups directly to tape. The catalog does not seem confused. It knows it needs to go to tape because it's beyond the retention for disk backups. The only problem is that it is going to the backup prior to the backupset I want, only for a couple of files.
In the past, when all went directly to tape, we would do a set until time 'Feb. 7, 03:43:37' and it would automatically restore the backupset that finished then and apply archived redo logs as necessary to make a consistent copy. Now, if I use the same model, it's going to a backup set from the prior date for 3 particular files. If I change the time to when the archived redo logs ended their backup, 04:00, it still goes back to the day before, but only for 2 files.
I can list a backup of each specific file and see that the file is in the backupset for which I expect RMAN to pull. How can I figure out a date/time to go back to if not using the method of reviewing the catalog entries and timestamps?
We are doing RMAN Duplicate set until time to refresh daily our test database for our developers and it taking long time to finish. We noticed on the restore log that RMAN was using a day old old backup pieces to refresh the test database and don't immediately use the latest backup pieces instead.
For additional details here's the rman duplicate command we are using which we run daily(mon-sat) at 4am once daily full backup on production completed.
RMAN Duplicate commands: run { set until time "to_date(to_char(sysdate,'Mon DD YYYY') || ' 04:00:00', 'Mon DD YYYY HH24:MI:SS')"; allocate auxiliary channel ch1 type disk; duplicate target database to testdb; } exit
Is there a way on how to let RMAN use the latest backup pieces instead?
The script has successfully created on standby db all controlfiles and also has copied 2 data files DATA01.DBF and DATA02.DBF into the correct location. Then the errors above kicked in and stopped the rman dup process.
