| restore database failure [message #146435] |
Thu, 10 November 2005 07:19  |
horstborscht
Messages: 13
Registered: April 2005
|
Junior Member |
|
|
Hi all,
I'm trying to simulate a disaster recovery of a 10g Database server.
I made a full database backup to disk of our production database via OEM
(image copies of SPfile,controlfiles,datafiles and archivelog files)
The backup was not stored to the default db_recovery_file_dest
but to a different directory, say D:\Backup.
On a test server i tried the following:
created directory structure for database files
with oradim:
created a new instance with the same SID as the production DB
with rman:
set DBID to the same DBID as the production DB
restored spfile from backup
restored controlfiles from backup
all this worked just fine...
now i tried to issue 'restore database' and I'm stuck with the following error:
RMAN> restore database;
Starting restore at 10.11.05
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=160 devtype=DISK
creating datafile fno=1 name=D:\DATABASE\OLAV\SYSTEM01.DBF
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 11/10/2005 13:02:35
ORA-01180: can not create datafile 1
ORA-01110: data file 1: 'D:\DATABASE\OLAV\SYSTEM01.DBF'
These are my RMAN configuration parameters:
RMAN> show all;
using target database controlfile instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT 'D:\Backup\%U';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'D:\ORACLE\DATABASE\SNCFOLAV.ORA'; # default
has anyone got an idea what I'm missing here?
Thanks in advance
Horst Borscht
|
|
|
|
|
|
| Re: restore database failure [message #147042 is a reply to message #146651] |
Tue, 15 November 2005 08:23  |
horstborscht
Messages: 13
Registered: April 2005
|
Junior Member |
|
|
Thanks for your answer Sunilkumar,
Sorry, i was just too stupid...
I found out that the files i recovered from a tape backup
were actually not in the right directory, so they couldn't be found
when i issued the "restore database" command...
(the original backup was made to a directory "D:\RMAN_Backup",
not as i assumed: "D:\Backup")
Now the restore works fine...
when i went on to recover database i noticed that your proposal
to have additional archive logs created on a standby server really makes sense...
Unfortunately right now we have only our testing box to replace the production server in case of a disaster scenario...so this is not a real standby database actually and it seems that i have to do a restore from a tape backup of the production DB on the testing server before i can apply the archive logs...
But I would like to have the production archive logs transferred to the testing box anyway...so how can i achieve this?
Can i just set log_archive_dest_2 to a mapped network drive?
Or do i risk to bring the production database down when the connection to the testserver is lost?
Thanks again
Horst Borscht
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
in it when our primary db is creating archive log file the one copy of that file is also created at stantby database server ... so when primary database is down we have to switch over standby database & there we have to do revoery of database without restoring any thing as we have all the thing at standby database server note :- recovery is doen with help of archive log file.