| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: RE: Recovery Help?
eeew.
Question: by the mount point name, it appears that this datafile has only indexes. Is that true for all the datafiles on u02?
If so (and you should be able to bring up the SYSTEM tablespace with most of the other tablespaces offline to investigate), then maybe you can dodge this bullet by using offline drop to get rid of the tablespaces containing only indexes. I'm guessing folks who don't have any DBAs didn't venture into IOTs, but be careful. Before you do the offline drop including contents so you don't need the lost files any more, you'd need to use one of the many fine write sql using sql on the dictionary scripts or tools unless you have a source from which to re-create the indexes that will be missing after the drop. Hmm. Unless maybe export indexes only doesn't really need the tablespaces on line to work -- I never tried that.
Anyway, if and only if you have no clusters, tables (including iots), or user defined objects containing source data in the tablespaces you need to drop, you might be able to work this out without the archive(s) that take the backup from fuzzy to consistent.
good luck. oh, and luck will be increased by getting a copy of everything you currently have, including the controlfiles and on line redo logs, before you touch anything more. at least then you can re-try additional resurrection experiments if some efforts fail. Open resetlogs is definitely a trap door unless you've got the onlines from before the reset to restore.
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of
rstevenson_at_cobblesoft.com
Sent: Thursday, August 19, 2004 8:05 AM
To: oracle-l_at_freelists.org
Subject: RE: RE: Recovery Help?
Thanks for the replies Ian and Ruth.
Ruth's suggestion below results in the following:
SVRMGR> recover using backup controlfile until cancel;
ORA-00279: change 3668927078 generated at 07/02/2004 02:42:41 needed for
thread 1
ORA-00289: suggestion : /u06/archive/SDS0000166990.ARC
ORA-00280: change 3668927078 for thread 1 is in sequence #166990
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error
below
ORA-01194: file 3 needs more recovery to be consistent
ORA-01110: data file 3: '/u02/oraindex/sds/usrindex01.dbf'
SVRMGR>
Mount U02 is the drive that was lost and now has the newer dated db files...
Any ideas from here ?
Thanks.
Have they tried: 'recover using backup controlfile until cancel;' and cancelling when it asks for the archivelog from July 2.
Just a thot!
Ruth
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of
rstevenson_at_cobblesoft.com
Sent: Thursday, August 12, 2004 8:01 PM
To: oracle-l_at_freelists.org
Subject: Recovery Help?
I'm seeking help/advice from the list on behalf of a client that no longer has a DBA - and has a production DB utterly screwed up - hope you can help me point them in the right direction.... I've tried the basics ... but then I'm only knowledgeable enough in this area to be dangerous!
Situation: Remote DB (Linux/8.1.7) - they lost a drive/mount point - and then lost the frame relay for best part of 3 weeks (thanks to Sprint efficiency). The system tried to perform automated disk-to-disk backups (cold, via crontab) then to tape, but failed when it hit the bad drive - each day!
Result: Their DB is mostly at July 14 - with the restore of the bad drive at Aug 3rd (includes a System datafile, 1 data and an index datafile). When I try to recover for them, it calls for archive logs dated July 2nd - and they only have ones going back to July 3rd..... Their backup cycle is a 7-day cycle (with no secure copy archived off) - so they have no good consistent backup to restore from...
At this stage, they'd be real happy just to get a db back, even if several weeks old. My viewpoint at this stage is that there are no options ... but then I'm hoping for them that maybe one of you knows differently???
Thanks for thoughts ...
Richard
 |
 |