- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Very bad ORACLE recovery scenario .....
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2002 07:33 AM
тАО01-21-2002 07:33 AM
Very bad ORACLE recovery scenario .....
here is the plot:
My customer has lost (means overwritten) some tapes from his backup software (Omniback). Oracle is running in SAP environment 8.0.5 64 Bit. Total size is around 250 GB. Backup is going to two tapes, protection for the tapes is 10 days (ya, they are going to change that now....).
Now the problem:
- due to programming error we need to recover to 2001/12/31 06:00
- due to overwritten tapes, we need to restore from several diffrent backups, but we will not be able to restore ALL files.
- redologs are available as far as backups go back
- I have a binary backup of the controlfile from 2001/12/30 14:00
- when all is going well, I will have in the end 9 files missing, of which I can create 4 with CREATE DATAFILE, as they are quite new.
Basicly I need some data from two tables, both located in the same
tablespace. The tablespace consists of 30 2GB files. I miss file #3 and file #13 of this tablespace. The tables are unlikey to have major updates, and esp. the rows I need are suspected to be in datafiles bigger than #20 (this is gambling, but anyway...)
Now I tracked some queries, to extract the data I need from a sample database from a tablespace with an offline datafile. Did work quite ok.
When my restore is finished, I hopefully will have:
- all datafiles of the system tablespace
- all datafiles of the index tablespace corresponding to the tablespace with two missing datafiles
My approach will be to set the missing datafiles offline, recover the database (... using backup controlfile until 'timestamp').
I tend to comment out all rollback-segments from the init.ora, because one of the missing datafiles belongs to the rollback-TS.
With this, I'd like to "open resetlogs" the database.
### Is there a chance that this will work ??? ###
When I am that far, I am pretty sure, I'll manage to get some data, but I have two big question marks:
- "recover database" with offline datafiles
- "open reset logs" with offline datafiles
I know this is far beyond any standard recovery, but will the be a chance (with luck of course) to access some data from those tables ?
Any feedback welcome,
even wishes for luck :-)
Volker
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2002 03:07 AM
тАО01-22-2002 03:07 AM
Re: Very bad ORACLE recovery scenario .....
Haven't been down that road (yet), but as far as I know this is the case:
As long as you have some version of all your old datafiles and ALL archived redologs since, the recover database command should succeed.
But;
if you have recreated some of the tablespaces due to the lack of backupfiles, these would not be able to recieve data from the redologs, as these are NEW datafiles as far as Oracle knows (I think).
Good luck!
Sorry I can't be of much help!
Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-22-2002 04:24 AM
тАО01-22-2002 04:24 AM
Re: Very bad ORACLE recovery scenario .....
Volker, you have a good chance, if your database is in archivelog mode.
If you restore the database, you should have the offline redo log files available from that date on.
Restore only the datafiles you need ( no logfiles, no controlfiles ), then do the recover until time. That should restore all the data before the moment of the crash.
If you overwrite the controlfile, you might loose the correct timestamp.
If you need more help, contact me.
alexander_ermes@web.de
Rgds
Alexander M. Ermes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2002 12:09 AM
тАО01-23-2002 12:09 AM
Re: Very bad ORACLE recovery scenario .....
The real problem is:
- since I need to do a point in time recovery, I need to restore ALL datafiles (but I do not have them all!)
- there is no problem to recover the database with a backup controlfile, even without having some datafiles. These can be created with CREATE DATAFILE, if the controlfile knows them already and you have all redologs (been there, done that).
The problem is, I do not have ALL files and for the files missing, I do not have all redologs. I need to do the recovery with some files offline and then "open resetlos" the database.
Regards
Volker
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2002 01:02 AM
тАО01-23-2002 01:02 AM
Re: Very bad ORACLE recovery scenario .....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2002 01:28 AM
тАО01-23-2002 01:28 AM
Re: Very bad ORACLE recovery scenario .....
There is a parameter you can set in the init.ora file to force Oracle to startup even tough files are missing / need recovery.
This will give a inconsistant database, but it will anyway be more than you have today.
Unfortunately I haven't been able to recall or lookup this parameter but will continue to search my mind and notes for it.
Anyone else know this?
Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2002 01:37 AM
тАО01-23-2002 01:37 AM
Re: Very bad ORACLE recovery scenario .....
_allow_corruption
_offline_rollback_segments, and _corrupted_rollback_segments
From Oracle Note: 94114.1 (Metalink)
h) Recovery with corrupted/missing rollback segments.
If a rollback segment is missing or corrupted, you will not be able to open the
database. The first step is to find out what object is causing the rollback to
appear corrupted. If we can determine that, we can drop that object.
If we can't we will need to use the hidden parameters _allow_corruption.
If in fact the rollback segment itself is corrupted, we should see if we can
restore from a backup. However, that isn't always possible, there may not be a
recent backup etc. In this case, we have to force the database open with the
unsupported, hidden parameters
_offline_rollback_segments, and _corrupted_rollback_segments.
Please note, that this is potentially dangerous!
Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2002 06:31 AM
тАО01-23-2002 06:31 AM
Re: Very bad ORACLE recovery scenario .....
And how far back to have archives files available?
If you have missing files and you create empty files you will have to have the archives as far back as the first time the file was created to even have a chance.
If they are only keeping the backup for 10 days how long are they keeping the archives?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2002 09:01 AM
тАО01-23-2002 09:01 AM
Re: Very bad ORACLE recovery scenario .....
isn't it possible for you to recover (part of) the database to another location/server. As maybe 99.9% of the current DB is still OK, it would be pitty to loose it.
Afterwards you can compare and/or copy data from the backup with the current DB.
The bad thing about this is that you need diskspace.
I once used this trick to get some table data from an older backup after "one" table got corrupted. I was able to restore system, temp, rollback and the one datafile (was whole tablespace) I needed, and ignored all other datafiles (did not have space for them anyway), and was able to export/import the required data to the production DB.
good luck,
Thierry.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-24-2002 02:38 AM
тАО01-24-2002 02:38 AM
Re: Very bad ORACLE recovery scenario .....
right now we managed to get nearly all the files. Right now, we only miss one datafile of an index tablespace, which does not contain any data we need to access.
I am pretty confident now, that we will be able to get everything we need. Nevertheless, if I have some spare time, I'll try this in a test environment (with a small database), as this scenario seems extremly interesting.
Right now recovery is on the way.
I'll let you know later how it turned out.
Thanks
Volker
PS:
Andreas: yes, I found those parameters also. I am not sure, if there would be need to uses them. May be it would have been necessary to use them, if a file of the rollback tablespace is missing (which in the begining was the case).
Ron: They use 10 days protection in Omniback. Since Omniback releases the tapinformation when the tape is overwritten, it may be, that you can go back further that the protection period.
Thierry: This is in fact what we are doing.