Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Error while recovering database files

Status
Not open for further replies.

v1nsr

Technical User
Oct 4, 2012
50
QA
We are trying to recover files getting error
rmon script being used


I can do some operations that communicate with Legato on the DR server but when I try to restore database files, it refuses to do it:
ORA-01180: can not create datafile 1
ORA-01110: data file 1: '/oradb1/PARISLIV/dbf/system01.dbf'

Is there any options in Legato that need ticking such as 'this legato installation can restore backups taken on another server' (I seem to remember this from a long time ago.

Any suggestions would be fruitful to fix this issue.
 
Where did your controlfile comes from ?
Did you restore it first ?
Without a valid database controlfile or a recovery catalog database rman and networker cannot restore oracle dbs.

 

I have attached all the steps performed below , please share your views on this.

Third Day :

There has been a bit more progress here.

It appears that the Legato media manager was not running on the DR site and this tied in with the errors we were seeing.

I have now managed to perform crosscheck and this now seems to be working (see below).


oracle,PARISLIV [/scc/oracle/admin/rman_DR]>rman target / cmdfile=ph_crosscheck.rcv

Recovery Manager: Release 11.1.0.6.0 - Production on Thu Dec 13 15:30:19 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: PARISLIV (DBID=2934680327, not open)

RMAN> allocate channel for maintenance type 'SBT_TAPE' parms 'ENV=(NSR_SERVER=svr-blk-legato1,NSR_CLIENT=svr-unx-hscare,NSR_DATA_VOLUME_POOL=DataDomain)';
2> crosscheck backup;
3>
4>
5>
using target database control file instead of recovery catalog
allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: SID=112 device type=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: NMDA Oracle v1.1.0

crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_798691697.3140 RECID=3046 STAMP=798691736
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_798705963.3141 RECID=3047 STAMP=798706008
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_798706453.3142 RECID=3048 STAMP=798706497
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121107-00 RECID=3049 STAMP=798706964
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_798759076.3152 RECID=3058 STAMP=798759116
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_798787776.3153 RECID=3059 STAMP=798787817
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_798788802.3154 RECID=3060 STAMP=798788843
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121108-00 RECID=3061 STAMP=798789731
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_798846492.3164 RECID=3070 STAMP=798846532
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_798860761.3165 RECID=3071 STAMP=798860803
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_798861489.3166 RECID=3072 STAMP=798861529
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121109-00 RECID=3073 STAMP=798862415
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_798955061.3176 RECID=3082 STAMP=798955101
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_798967687.3177 RECID=3083 STAMP=798967726
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_798968141.3178 RECID=3084 STAMP=798968180
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121110-00 RECID=3085 STAMP=798968585
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_799205175.3204 RECID=3110 STAMP=799205216
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799230449.3205 RECID=3111 STAMP=799230496
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799230858.3206 RECID=3112 STAMP=799230903
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121113-00 RECID=3113 STAMP=799231383
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_799282774.3216 RECID=3122 STAMP=799282820
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799290440.3217 RECID=3123 STAMP=799290486
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799290731.3218 RECID=3124 STAMP=799290773
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121114-00 RECID=3125 STAMP=799291182
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_799359037.3222 RECID=3134 STAMP=799359080
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799374563.3229 RECID=3135 STAMP=799374605
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799375070.3230 RECID=3136 STAMP=799375112
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121115-00 RECID=3137 STAMP=799376179
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_799444593.3234 RECID=3146 STAMP=799444653
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799461297.3241 RECID=3147 STAMP=799461341
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799461587.3242 RECID=3148 STAMP=799461635
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121116-00 RECID=3149 STAMP=799461854
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_799560007.3252 RECID=3158 STAMP=799560049
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799581509.3253 RECID=3159 STAMP=799581551
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799581956.3254 RECID=3160 STAMP=799582000
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121117-00 RECID=3161 STAMP=799582438
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_799814613.3298 RECID=3204 STAMP=799814654
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799828949.3299 RECID=3205 STAMP=799828996
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799829172.3300 RECID=3206 STAMP=799829215
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121120-00 RECID=3207 STAMP=799829485
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_799891783.3310 RECID=3216 STAMP=799891824
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799900111.3311 RECID=3217 STAMP=799900154
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799900319.3312 RECID=3218 STAMP=799900358
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121121-00 RECID=3219 STAMP=799900583
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_799961341.3316 RECID=3228 STAMP=799961398
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799987872.3323 RECID=3229 STAMP=799987913
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_799988829.3324 RECID=3230 STAMP=799988870
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121122-00 RECID=3231 STAMP=799989609
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=db_PARISLIV_800048249.3328 RECID=3240 STAMP=800048301
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_800064130.3335 RECID=3241 STAMP=800064172
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=arch_PARISLIV_800064718.3336 RECID=3242 STAMP=800064761
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-2934680327-20121123-00 RECID=3243 STAMP=800065270
Crosschecked 52 objects



When I try to restore a single file I am now getting a different error. This suggests to me that it may just be the tape not being available.

RMAN> run {
2> allocate channel t1 type 'SBT_TAPE'
3> parms 'ENV=(
4> NSR_SERVER=svr-blk-legato1,
5> NSR_CLIENT=svr-unx-hscare,
6> NSR_DATA_VOLUME_POOL=DataDomain)';
7> #
8> #
9> restore spfile to '/scc/oracle/admin/rman_DR/phtest.sp' ;
10> }
11>
using target database control file instead of recovery catalog
allocated channel: t1
channel t1: SID=111 device type=SBT_TAPE
channel t1: NMDA Oracle v1.1.0

Starting restore at 13-DEC-12


List of remote backup files
============================
Handle: c-2934680327-20121123-00 Media: FIE250
released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 12/13/2012 15:33:01
RMAN-20507: some targets are remote - aborting restore

Recovery Manager complete.



RMAN> list backup tag TAG20121123T002026;


List of Backup Sets
===================


BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3243 Full 14.00M SBT_TAPE 00:00:48 23-NOV-12
BP Key: 3243 Status: AVAILABLE Compressed: NO Tag: TAG20121123T002026
Handle: c-2934680327-20121123-00 Media:
SPFILE Included: Modification time: 22-NOV-12
SPFILE db_unique_name: PARISLIV
Control File Included: Ckp SCN: 1363133826 Ckp time: 23-NOV-12



=============================================================================================================================================
Second Day :
I have just tried few more commands.

Firstly I have tried listing backups while allocating an SBT_TAPE channel. As you can see below this works ok.

oracle,PARISLIV [/scc/oracle/admin/rman_DR]>rman target / cmdfile=ph_list_backups.rcv

Recovery Manager: Release 11.1.0.6.0 - Production on Thu Dec 13 13:38:57 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: PARISLIV (DBID=2934680327, not open)

RMAN> allocate channel for maintenance type 'SBT_TAPE' parms 'ENV=(NSR_SERVER=svr-blk-legato1,NSR_CLIENT=svr-unx-hscare,NSR_DATA_VOLUME_POOL=DataDomain)';
2> list backup of database summary device type 'SBT_TAPE' completed after '20-jan-10';
3>
4>
5>
using target database control file instead of recovery catalog
allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: SID=113 device type=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: NMDA Oracle v1.1.0


List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
3046 B F A SBT_TAPE 07-NOV-12 1 1 NO TAG20121107T024816
3058 B F A SBT_TAPE 08-NOV-12 1 1 NO TAG20121107T213115
3070 B F A SBT_TAPE 09-NOV-12 1 1 NO TAG20121108T214811
3082 B F A SBT_TAPE 10-NOV-12 1 1 NO TAG20121110T035740
3110 B F A SBT_TAPE 13-NOV-12 1 1 NO TAG20121113T012615
3122 B F A SBT_TAPE 14-NOV-12 1 1 NO TAG20121113T225933
3134 B F A SBT_TAPE 15-NOV-12 1 1 NO TAG20121114T201036
3146 B F A SBT_TAPE 16-NOV-12 1 1 NO TAG20121115T195632
3158 B F A SBT_TAPE 17-NOV-12 1 1 NO TAG20121117T040006
3204 B F A SBT_TAPE 20-NOV-12 1 1 NO TAG20121120T024332
3216 B F A SBT_TAPE 21-NOV-12 1 1 NO TAG20121121T000942
3228 B F A SBT_TAPE 22-NOV-12 1 1 NO TAG20121121T192900
3240 B F A SBT_TAPE 23-NOV-12 1 1 NO TAG20121122T193728

Recovery Manager complete.
oracle,PARISLIV [/scc/oracle/admin/rman_DR]>cat


I have then tried to run a command to crosscheck backups. As you can see below this is failing with the same error as when we try the restore.

"ph_crosscheck.rcv" 4 lines, 171 characters
oracle,PARISLIV [/scc/oracle/admin/rman_DR]>rman target / cmdfile=ph_crosscheck.rcv

Recovery Manager: Release 11.1.0.6.0 - Production on Thu Dec 13 13:45:24 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: PARISLIV (DBID=2934680327, not open)

RMAN> allocate channel for maintenance type 'SBT_TAPE' parms 'ENV=(NSR_SERVER=svr-blk-legato1,NSR_CLIENT=svr-unx-hscare,NSR_DATA_VOLUME_POOL=DataDomain)';
2> crosscheck backup;
3>
4>
5>
using target database control file instead of recovery catalog
allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: SID=113 device type=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: NMDA Oracle v1.1.0

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of crosscheck command on ORA_MAINT_SBT_TAPE_1 channel at 12/13/2012 13:45:31
ORA-27191: sbtinfo2 returned error
Additional information: 3335

Recovery Manager complete.

My conclusion with this is that we need to check the basic functionality of the Legato system here.

===============================================================================================================================================
First Day

I have made a few attempts at restoring from Legato this morning. All of them have been unsuccessful.

In order to try and simplify the problem I thought we would start by seeing if we could restore a single file.


In order to prove the theory I tested the following command. In this example I have restored a backup of an spfile from TIVOLI on one of our other systems. The purpose of this was simply to check the syntax of the command that we were using. As you can see the command was successful.


RMAN> run {
2> allocate channel c1 device type sbt_tape parms 'ENV=(TDPO_OPTFILE=/home/oradev/TSM/tdpo.opt_SMCOGDEV)' ;
3> restore spfile to '/home/oradev/PHTMP/RMAN_TEST/ph_sp_bkup3';
4> }

allocated channel: c1
channel c1: SID=198 device type=SBT_TAPE
channel c1: Data Protection for Oracle: version 5.4.1.0

Starting restore at 13-DEC-12

channel c1: starting datafile backup set restore
channel c1: restoring SPFILE
output file name=/home/oradev/PHTMP/RMAN_TEST/ph_sp_bkup3
channel c1: reading from backup piece sp_DLY_43nsnbll_1_1
channel c1: piece handle=sp_DLY_43nsnbll_1_1 tag=TAG20121212T234804
channel c1: restored backup piece 1
channel c1: restore complete, elapsed time: 00:03:35
Finished restore at 13-DEC-12
released channel: c1


I have then used the following command to try the same thing on the Southampton system using Legato. The results from this are as follows:

oracle,PARISLIV [/scc/oracle/admin/rman_DR]>rman target / debug trace=ph_debug2.log cmdfile=ph_test_rest2.rcv

Recovery Manager: Release 11.1.0.6.0 - Production on Thu Dec 13 13:23:00 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

RMAN-06568: connected to target database: PARISLIV (DBID=2934680327, not open)

RMAN> run {
2> allocate channel c1 type 'SBT_TAPE' parms 'ENV=(NSR_SERVER=svr-blk-legato1,NSR_CLIENT=svr-unx-hscare,NSR_DATA_VOLUME_POOL=DataDomain)';
3> restore spfile to '/scc/oracle/admin/rman_DR/phtest.sp' ;
4> }
5>
RMAN-06009: using target database control file instead of recovery catalog
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: SID=40 device type=SBT_TAPE
RMAN-08526: channel c1: NMDA Oracle v1.1.0

RMAN-03090: Starting restore at 13-DEC-12

RMAN-08031: released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 12/13/2012 13:23:07
RMAN-03009: failure of IRESTORE command on c1 channel at 12/13/2012 13:23:07
ORA-27191: sbtinfo2 returned error
Additional information: 3335

Recovery Manager complete.
oracle,PARISLIV [/scc/oracle/admin/rman_DR]>


I have also attached the trace file from the above command.

 
usually the spfile is saved during autobackup.
To recover it make the following :

In sqlplus make a shutdown immediate.
start rman, connect to the database instance.
rman target /
This empty instance knows absolutely nothing therefore you have to set the dbid.

SET DBID=2934680327;
then make the usual rman commands :
run {allocate channel c1 type 'SBT_TAPE' parms 'ENV=(NSR_SERVER=svr-blk-legato1,NSR_CLIENT=svr-unx-hscare,NSR_DATA_VOLUME_POOL=DataDomain)';
RESTORE SPFILE FROM TO '/tmppath' from autobackup;
}

a release channel is no longer required.


The spfile is a little bit complicated for a restore test.

I would try to recover an archivelog file instead !

rman connect target ...
run {
....

RESTORE ARCHIVELOG FROM LOGSEQ 3141 UNTIL LOGSEQ 3142 THREAD 1;

}

Good luck.
 
Thanks for your views on this , will do the same and relay the outcome.

Cheers
 
Hello,

This time I have tried to restore archive logs.

As before, I have restored the controlfile mounted the database and then performed a list backupset summary. The latest backups are as follows:

3240 B F A SBT_TAPE 23-NOV-12 1 1 NO TAG20121122T193728
3241 B A A SBT_TAPE 23-NOV-12 1 1 NO TAG20121123T000209
3242 B A A SBT_TAPE 23-NOV-12 1 1 NO TAG20121123T000209
3243 B F A SBT_TAPE 23-NOV-12 1 1 NO TAG20121123T002026


I have then listed the 2nd backup piece as this will hold the backed up arch logs.

RMAN> list backup tag TAG20121123T000209;


List of Backup Sets
===================


BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
3241 4.38G SBT_TAPE 00:09:41 23-NOV-12
BP Key: 3241 Status: AVAILABLE Compressed: NO Tag: TAG20121123T000209
Handle: arch_PARISLIV_800064130.3335 Media:

List of Archived Logs in backup set 3241
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 10677 1355167024 17-NOV-12 1355562291 17-NOV-12
1 10678 1355562291 17-NOV-12 1355564412 17-NOV-12
1 10679 1355564412 17-NOV-12 1355564545 17-NOV-12
1 10680 1355564545 17-NOV-12 1355774146 18-NOV-12
1 10681 1355774146 18-NOV-12 1356200388 18-NOV-12
1 10682 1356200388 18-NOV-12 1356400666 18-NOV-12
1 10683 1356400666 18-NOV-12 1356403241 18-NOV-12
1 10684 1356403241 18-NOV-12 1356403243 18-NOV-12
1 10685 1356403243 18-NOV-12 1356403246 18-NOV-12
1 10686 1356403246 18-NOV-12 1356403248 18-NOV-12
1 10687 1356403248 18-NOV-12 1356569560 18-NOV-12
1 10688 1356569560 18-NOV-12 1356736986 19-NOV-12
1 10689 1356736986 19-NOV-12 1357099503 19-NOV-12
1 10690 1357099503 19-NOV-12 1357147612 19-NOV-12
1 10691 1357147612 19-NOV-12 1357191610 19-NOV-12
1 10692 1357191610 19-NOV-12 1357236904 19-NOV-12
1 10693 1357236904 19-NOV-12 1357290410 19-NOV-12
1 10694 1357290410 19-NOV-12 1357333000 19-NOV-12
1 10695 1357333000 19-NOV-12 1357372510 19-NOV-12
1 10696 1357372510 19-NOV-12 1357411170 19-NOV-12
1 10697 1357411170 19-NOV-12 1357442524 19-NOV-12
1 10698 1357442524 19-NOV-12 1357474130 19-NOV-12
1 10699 1357474130 19-NOV-12 1357511256 19-NOV-12
1 10700 1357511256 19-NOV-12 1357566657 19-NOV-12
1 10701 1357566657 19-NOV-12 1357609695 19-NOV-12
1 10702 1357609695 19-NOV-12 1357647961 19-NOV-12
1 10703 1357647961 19-NOV-12 1357692484 19-NOV-12
1 10704 1357692484 19-NOV-12 1357731594 19-NOV-12
1 10705 1357731594 19-NOV-12 1357769660 19-NOV-12
1 10706 1357769660 19-NOV-12 1357808948 19-NOV-12
1 10707 1357808948 19-NOV-12 1357857225 19-NOV-12
1 10708 1357857225 19-NOV-12 1357916296 19-NOV-12
1 10709 1357916296 19-NOV-12 1358028085 19-NOV-12
1 10710 1358028085 19-NOV-12 1358278019 20-NOV-12
1 10711 1358278019 20-NOV-12 1358528790 20-NOV-12
1 10712 1358528790 20-NOV-12 1358646758 20-NOV-12
1 10713 1358646758 20-NOV-12 1358702356 20-NOV-12
1 10714 1358702356 20-NOV-12 1358758733 20-NOV-12
1 10715 1358758733 20-NOV-12 1358811303 20-NOV-12
1 10716 1358811303 20-NOV-12 1358850177 20-NOV-12
1 10717 1358850177 20-NOV-12 1358892760 20-NOV-12
1 10718 1358892760 20-NOV-12 1358938932 20-NOV-12
1 10719 1358938932 20-NOV-12 1358980142 20-NOV-12
1 10720 1358980142 20-NOV-12 1359023889 20-NOV-12
1 10721 1359023889 20-NOV-12 1359063228 20-NOV-12
1 10722 1359063228 20-NOV-12 1359113578 20-NOV-12
1 10723 1359113578 20-NOV-12 1359162303 20-NOV-12
1 10724 1359162303 20-NOV-12 1359206195 20-NOV-12
1 10725 1359206195 20-NOV-12 1359244122 20-NOV-12
1 10726 1359244122 20-NOV-12 1359286807 20-NOV-12
1 10727 1359286807 20-NOV-12 1359329103 20-NOV-12
1 10728 1359329103 20-NOV-12 1359376972 20-NOV-12
1 10729 1359376972 20-NOV-12 1359437605 20-NOV-12
1 10730 1359437605 20-NOV-12 1359550667 20-NOV-12
1 10731 1359550667 20-NOV-12 1359733304 20-NOV-12
1 10732 1359733304 20-NOV-12 1359907214 21-NOV-12
1 10733 1359907214 21-NOV-12 1360177144 21-NOV-12
1 10734 1360177144 21-NOV-12 1360230420 21-NOV-12
1 10735 1360230420 21-NOV-12 1360273434 21-NOV-12

BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
3242 4.22G SBT_TAPE 00:08:26 23-NOV-12
BP Key: 3242 Status: AVAILABLE Compressed: NO Tag: TAG20121123T000209
Handle: arch_PARISLIV_800064718.3336 Media:

List of Archived Logs in backup set 3242
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 10736 1360273434 21-NOV-12 1360311069 21-NOV-12
1 10737 1360311069 21-NOV-12 1360349781 21-NOV-12
1 10738 1360349781 21-NOV-12 1360383651 21-NOV-12
1 10739 1360383651 21-NOV-12 1360422655 21-NOV-12
1 10740 1360422655 21-NOV-12 1360459132 21-NOV-12
1 10741 1360459132 21-NOV-12 1360499776 21-NOV-12
1 10742 1360499776 21-NOV-12 1360534099 21-NOV-12
1 10743 1360534099 21-NOV-12 1360579707 21-NOV-12
1 10744 1360579707 21-NOV-12 1360625800 21-NOV-12
1 10745 1360625800 21-NOV-12 1360667642 21-NOV-12
1 10746 1360667642 21-NOV-12 1360714178 21-NOV-12
1 10747 1360714178 21-NOV-12 1360756221 21-NOV-12
1 10748 1360756221 21-NOV-12 1360794195 21-NOV-12
1 10749 1360794195 21-NOV-12 1360841633 21-NOV-12
1 10750 1360841633 21-NOV-12 1360884148 21-NOV-12
1 10751 1360884148 21-NOV-12 1360917066 21-NOV-12
1 10752 1360917066 21-NOV-12 1360947160 21-NOV-12
1 10753 1360947160 21-NOV-12 1360985617 21-NOV-12
1 10754 1360985617 21-NOV-12 1361022798 21-NOV-12
1 10755 1361022798 21-NOV-12 1361062547 21-NOV-12
1 10756 1361062547 21-NOV-12 1361093220 21-NOV-12
1 10757 1361093220 21-NOV-12 1361194821 21-NOV-12
1 10758 1361194821 21-NOV-12 1361229263 21-NOV-12
1 10759 1361229263 21-NOV-12 1361435630 21-NOV-12
1 10760 1361435630 21-NOV-12 1361528432 22-NOV-12
1 10761 1361528432 22-NOV-12 1361627062 22-NOV-12
1 10762 1361627062 22-NOV-12 1361881448 22-NOV-12
1 10763 1361881448 22-NOV-12 1361933516 22-NOV-12
1 10764 1361933516 22-NOV-12 1361980401 22-NOV-12
1 10765 1361980401 22-NOV-12 1362031461 22-NOV-12
1 10766 1362031461 22-NOV-12 1362068883 22-NOV-12
1 10767 1362068883 22-NOV-12 1362098101 22-NOV-12
1 10768 1362098101 22-NOV-12 1362146987 22-NOV-12
1 10769 1362146987 22-NOV-12 1362181335 22-NOV-12
1 10770 1362181335 22-NOV-12 1362225761 22-NOV-12
1 10771 1362225761 22-NOV-12 1362272851 22-NOV-12
1 10772 1362272851 22-NOV-12 1362321116 22-NOV-12
1 10773 1362321116 22-NOV-12 1362356502 22-NOV-12
1 10774 1362356502 22-NOV-12 1362381951 22-NOV-12
1 10775 1362381951 22-NOV-12 1362417765 22-NOV-12
1 10776 1362417765 22-NOV-12 1362458184 22-NOV-12
1 10777 1362458184 22-NOV-12 1362489864 22-NOV-12
1 10778 1362489864 22-NOV-12 1362529640 22-NOV-12
1 10779 1362529640 22-NOV-12 1362560741 22-NOV-12
1 10780 1362560741 22-NOV-12 1362600284 22-NOV-12
1 10781 1362600284 22-NOV-12 1362643754 22-NOV-12
1 10782 1362643754 22-NOV-12 1362684863 22-NOV-12
1 10783 1362684863 22-NOV-12 1362726910 22-NOV-12
1 10784 1362726910 22-NOV-12 1362773353 22-NOV-12
1 10785 1362773353 22-NOV-12 1362863573 22-NOV-12
1 10786 1362863573 22-NOV-12 1363078005 22-NOV-12
1 10787 1363078005 22-NOV-12 1363116469 23-NOV-12

RMAN>


I have then tried to restore some archivelogs included in the above backup.




Recovery Manager: Release 11.1.0.6.0 - Production on Mon Dec 17 16:06:22 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: PARISLIV (DBID=2934680327, not open)

RMAN> run {
2> allocate channel t1 type 'SBT_TAPE'
3> parms 'ENV=(
4> NSR_SERVER=svr-blk-legato1,
5> NSR_CLIENT=svr-unx-hscare,
6> NSR_DATA_VOLUME_POOL=DataDomain)';
7> #
8> #
9> restore ARCHIVELOG SEQUENCE between 10761 and 10763 THREAD=1;
10> }
11>
using target database control file instead of recovery catalog
allocated channel: t1
channel t1: SID=113 device type=SBT_TAPE
channel t1: NMDA Oracle v1.1.0

Starting restore at 17-DEC-12
Starting implicit crosscheck backup at 17-DEC-12
Crosschecked 148 objects
Crosschecked 28 objects
Finished implicit crosscheck backup at 17-DEC-12

Starting implicit crosscheck copy at 17-DEC-12
Crosschecked 6 objects
Finished implicit crosscheck copy at 17-DEC-12

searching for all files in the recovery area
cataloging files...
no files cataloged



List of remote backup files
============================
Handle: arch_PARISLIV_800064718.3336 Media: FIE250
released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 12/17/2012 16:08:14
RMAN-20507: some targets are remote - aborting restore

Recovery Manager complete.
oracle,PARISLIV [/scc/oracle/admin/rman_DR]>


This is also failing with the same error. Note that the handle a media ( Handle: arch_PARISLIV_800064718.3336 Media: FIE250) match those displayed when the list commands were used. Again, LEGATO is asking for a tape instead of looking at the DataDomain.

Any suggestions on this , as it is still reflecting the same error where it is asking for a tape.

 
First of all you are not communicating directly with networker using rman, you are queriieng the database.
Eith device type "SBT_TAPE" the database gives some control to an external media manager and assumes all external media are Tapes.
So the error messages concerning tapes does not really indicate that networker did not search on the datadomain devices.
But it does indicate that networker gives no backup peace to the database. The reasons can be multiple :
1. Is the required saveset browsable ?
2. Was the saveset backed up to the media Maanger (type SBT) ?
3. which version of nmmo or nmda do you use ? Did you create a link named libobk.so ?
4. show you rman backup script.

Check your rman configuration : rman> show all; an post it.


The trouble shooting gets a little complex at this point if you have a valid service contract with emc or one of its distributors I would advice you to open a call. Alternatively ask Oracle if you have maintenance.

Good luck
 
Example of the RMAN script I have been using is as follows:


RMAN> run {
2> allocate channel t1 type 'SBT_TAPE'
3> parms 'ENV=(
4> NSR_SERVER=svr-blk-legato1,
5> NSR_CLIENT=svr-unx-hscare,
6> NSR_DATA_VOLUME_POOL=DataDomain)';
7> #
8> #
9> restore ARCHIVELOG SEQUENCE between 10761 and 10763 THREAD=1;
10> }
11>
using target database control file instead of recovery catalog
allocated channel: t1
channel t1: SID=113 device type=SBT_TAPE
channel t1: NMDA Oracle v1.1.0

Starting restore at 17-DEC-12
Starting implicit crosscheck backup at 17-DEC-12
Crosschecked 148 objects
Crosschecked 28 objects
Finished implicit crosscheck backup at 17-DEC-12

Starting implicit crosscheck copy at 17-DEC-12
Crosschecked 6 objects
Finished implicit crosscheck copy at 17-DEC-12

searching for all files in the recovery area
cataloging files...
no files cataloged


List of remote backup files
============================
Handle: arch_PARISLIV_800064718.3336 Media: FIE250
released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 12/17/2012 16:08:14
RMAN-20507: some targets are remote - aborting restore

Recovery Manager complete.
oracle,PARISLIV [/scc/oracle/admin/rman_DR]>

Previous examples of ‘list backupset summary’ show the backup was taken to SBTTAPE
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
3240 B F A SBT_TAPE 23-NOV-12 1 1 NO TAG20121122T193728
3241 B A A SBT_TAPE 23-NOV-12 1 1 NO TAG20121123T000209
3242 B A A SBT_TAPE 23-NOV-12 1 1 NO TAG20121123T000209
3243 B F A SBT_TAPE 23-NOV-12 1 1 NO TAG20121123T002026

Pretty sure the symbolic link is in place – I will check for you.
Also, I believe, that the backup sets are browsable.
NB: we may have an explanation for the error.

Please feel free to share your views on this.





 
Sorry for the delay, hollidays ;-)

I would like to have a look at your BACKUP rman script, not your recovery script.
In addition I woukd like to see the output of the rman "show all" command.

The crucial point of your Problem is the media FIE250. If its a networker media then have a look at location and status using mminfo.
Maybe its a oracle disk medium e. g. §´"Flash Recovery Area" but I dont think so. If the medium is unavailable delete it from the networker media database or put all the savesets on the media in the "suspect" state using nsrmm -o and run the rman crosscheck backup command after this.
To make the rman autobackup to a networker device and not to the flash recovery area, which might be broken in case of a disaster, configure rman to make ALL backups to the SBT media manger = networker : CONFIGURE DEFAULT DEVICE TYPE TO sbt

Good luck for 2013
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top