How to recover without REDO logs?

[rsuri]

I want to ask this question first without digging into my other sources hoping I can get the solution faster -
a fellow moved database (datafiles) to another location and got rid of the old filesystem (HP-UX - Oracle 8.1.7.4 enterprise). No he's trying to bring up the database by updating the controlfile (to point to the new location) and just realized that he hadn't copy the redo logs.
This is a Development system but a lot of work will be lost if not recoverd.
What are our options?
The full backup is quite old (again losing work for a few days)
How can I recover the database without the redo logs (so that all I lose was just the redo information)
Thanks,
-Rajeev

[rsuri]

just wanted to add...the database was not running in Archive log mode.

[gandolf989]

IF you don't have access to all of the online redo logs. I don't think that there is a way to recover the database in its current form. If we were in archivelogmode and have all of the archive logs since the last full backup. Then you could restore your old logs and apply the archive logs from then until now. Because you aren't in archivelog mode, you can only do a point in time recover with your last good full backup, i.e. athe one from a few days ago.

Mybe someone else has some trick I'm not aware of.

[LKBrwn_DBA]

You could try:

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "MYDB" RESETLOGS...

Seems to have worked for a friend of mine.

[rsuri]

Thanks for the help. He did find a backup from 2 days old and restored the database...of course losing couple of days work.
-Rajeev

[stecal]

Do you have a version of Oracle that relies on redo logs to keep things current re: media recovery and cold backup? I don't think so. How is this situation any different than restoring from a cold backup (of which, copying redo logs is not necessary)? How could you have lost two days of work? That sounds nonsensical. But it's not if you don't understand what you are doing or what redo logs are for. You lost two days of work by using an older backup - which you didn't need to do. There was nothing wrong with what you had after moving the datafiles. For all intensive purposes, you could have pretended that your media recovery situation was based on losing all of your redo logs (because they were all on the same disk). Do you think there was data pending (unwritten blocks/dirty blocks/uncommitted changes) hanging around for a few hours in the redo logs? (Say "No.").

[svk]

If the db was not running in archivelog mode, how was it moved ? Was a move of all datafiles with the db shut down ? If yes, then you don't really need redo logs. As was suggested above, RESETLOGS should work just fine. And, with the database running in NOARCHIVELOG mode, resetting the log sequence # shouldn't be a big deal at all.

And, if the database was not moved while it was down, well...

[adrianomp]

And, if the database was not moved while it was down, well...

In that case, just use the 2-day old backup, swear yourself that it was the best effort possible, get some beers and pretend that nothing wrong happened.

[cruser3]

Like stecal said how is this different from the scenario as loss of online redo since you're in noarch. mode? The only way is from last full consistent backup, akaik..

but have made sure your dba has:
..done a recover until cancel/resetlogs &
..taken a full backup after the recovery ?

If not, further trouble looms down the way after your next disaster..

[stecal]

A "fellow" did it, not necessarily a DBA, but the person who posted the question is an OCP 8i. If any study material had been used for the OCP prep, like Sybex or Exam Cram, the media recovery scenario would have been easy to look up ("Oh yeah, I remember that in the Backup and Recovery chapters/book. It was in the section about the different types of errors - media, user, process/system, etc."). If a BrainCramp cheatsheet had been used, well, what scenario? All the user has is questions and answers to remember, hence, in a simple recovery scenario, panic is in no short supply.