Troubleshooting restore Oracle database on to same server
Our production system is - Window 2008 R2 x64, Oracle 10G, Backup Exec 13
We use Backup Exec to backup out Databases on a regular basis.
We wanted to be familier with the process of restore (and recover) of the database.
So, we created a test environment with the same - Window and Oracle.
And try to run the restore from the Backup Exec.
After some tests that failed, we receive a link to - http://seer.entsupport.symantec.com/docs/303911.htm
we followed the instructions and still it fail.
Followong are some of the log we got...
Microsoft Windows [Version 6.1.7600]
(c) Корпорация Майкрософт (Microsoft Corporation), 2009. Все права защищены.
ora.ora password=123
Oracle instance shut down
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor
Variable Size 318770176 bytes
Database Buffers 922746880 bytes
Redo Buffers 14708736 bytes
go to server Symantec Backup Exec and create restore job...
RMAN on server Symantec Backup Exec:
Recovery Manager: Release 10.2.0.4.0 - Production on Fri Apr 2 14:21:45 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
# -----------------------------------------------------------------
# RMAN command section
# -----------------------------------------------------------------
RUN {
ALLOCATE CHANNEL ch0
TYPE 'SBT_TAPE';
SEND 'BSA_SERVICE_HOST=172.17.4.12,NBBSA_TOTAL_STREAMS=1,NBBSA_JOB_COOKIE={F4C81D4C-3FF9-4FD1-A100-F086D6A14BFB},NBBSA_DB_DEVICE_NAME=Oracle-Win::\\LAB-ORACLE\LABORA';
RESTORE CONTROLFILE FROM 'BE_11la49e1_1_1';
ALTER DATABASE MOUNT;
RESTORE
DATABASE;
RECOVER
DATABASE;
RELEASE CHANNEL ch0;
alter database open resetlogs;
}
connected to target database: LABORA (not mounted)
using target database control file instead of recovery catalog
allocated channel: ch0
channel ch0: sid=154 devtype=SBT_TAPE
channel ch0: Symantec/BackupExec/1.1.0
sent command to channel: ch0
Starting restore at 02-APR-10
channel ch0: restoring control file
channel ch0: restore complete, elapsed time: 00:00:37
output filename=C:\ORACLE\ORADATA\LABORA\CONTROL01.CTL
output filename=C:\ORACLE\ORADATA\LABORA\CONTROL02.CTL
output filename=C:\ORACLE\ORADATA\LABORA\CONTROL03.CTL
Finished restore at 02-APR-10
database mounted
Starting restore at 02-APR-10
channel ch0: starting datafile backupset restore
channel ch0: specifying datafile(s) to restore from backup set
restoring datafile 00001 to C:\ORACLE\ORADATA\LABORA\SYSTEM01.DBF
restoring datafile 00002 to C:\ORACLE\ORADATA\LABORA\UNDOTBS01.DBF
restoring datafile 00003 to C:\ORACLE\ORADATA\LABORA\SYSAUX01.DBF
restoring datafile 00004 to C:\ORACLE\ORADATA\LABORA\USERS01.DBF
channel ch0: reading from backup piece BE_0ula498l_1_1
channel ch0: restored backup piece 1
piece handle=BE_0ula498l_1_1 tag=TAG20100402T135637
channel ch0: restore complete, elapsed time: 00:04:25
Finished restore at 02-APR-10
Starting recover at 02-APR-10
released channel: ch0
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/02/2010 14:26:56
ORA-19698: C:\ORACLE\ORADATA\LABORA\REDO01.LOG is from different database: id=3301204057, db_name=LABORA
Recovery Manager complete.
go to server Oracle and return CMD...
RMAN> Alter database open resetlogs; RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of alter db command at 04/02/2010 14:29:18 ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: 'C:\ORACLE\ORADATA\LABORA\SYSTEM01.DBF' RMAN>
How to resolve this issue?
Comments 2 Comments • Jump to latest comment
http://support.veritas.com/docs/294882
1. Bring the database to nomount state.
If this response answers your concern, please mark it as a "solution"
Thank you very much!!!
Would you like to reply?
Login or Register to post your comment.