Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle 7.3.4 Recovery Question

Re: Oracle 7.3.4 Recovery Question

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Thu, 27 May 2004 12:55:12 +1000
Message-ID: <40b55881$0$31674$afc38c87@news.optusnet.com.au>

"sanar" <sanarx_at_hotmail.com> wrote in message news:bc632bde.0405261733.524d1664_at_posting.google.com...
> Hello all, I have a question regarding database recovery.
>
> We have a 7.3.4 database running on Solaris.
>
> I have a situation where we have to restore this database from a cold
> backup. The problem is that the cold backup is not really a cold
> backup.

Strangely enough, the words 'hot' and 'cold' are mutually exclusive. You either have a hot backup. Or you have a cold one. You can't have one or the other which 'isn't really' either. Unless you're name is William Shakespeare... then you can have 'marv'lously hot ice'. But for mere mortals... no.

> The way the backups were done at this place was to take an image of
> the server overnight onto tape. So the database was not down at the
> time.

Then you have a badly-performed hot backup, and it cannot be used to recover your database.

>However we have the database files, redo-logs, control files
> etc. on that date.
>
> Is it possible to recover the database with reset logs if a copy of
> the files was taken but the database was not closed?

Nope. You've performed a hot backup without following any of the usual steps. You will therefore likely have data files containing blocks from a point in time before the data file header indicates, and you will probably have fractured blocks too.

That aside, why do you ask whether you can do a recovery 'with reset logs'? You only need to do that if you are in need of an incomplete recovery. And whilst you haven't actually explained what has gone wrong with this database such that it needs recovery (apart from not being managed properly in the first place), unless you've lost all your online logs and/or all your control files; or unless you are seeking to reverse a user error; or unless you've suffered media failure that has also deleted some of your archives; then you will want to be doing a complete recovery. Which is just as impossible with your backup strategy as an incomplete recovery, but I just thought I'd mention it.

Unless of course, you aren't actually in archivelog mode at all. In which case, we have a noarchivelog database being backed up hot, but completely incorrectly. Do you sense that maybe your chances are getting slimmer by the moment??!

>If the backup
> consisted of the data files /logs/ control files.

You should never backup online redo logs. But whatever. You should never do hot backups like you've been doing them, either! Especially if you're not in archivelog mode.

> There would have been no transactions taking place at the time the
> server image was taken, but there would have been some delay as to the
> time the individual file were being backed up.
>
> I know it's a long shot but any ideas.

If you genuinely have nothing to lose by having a go, then give it a go. In the absence of a lot of DML, the chances of fractured blocks is low. It is also possible that the data file headers might not have been updated by checkpoints. So try it and see, *provided it can truly do no harm* to do so.

The lack of DML may save you, but it will be pure chance if it does, and your chances are slim. Particularly if you aren't even in archivelog mode to start with.

And presumably you now know to perform backups in a rather more scientific fashion for the future?

Regards
HJR Received on Wed May 26 2004 - 21:55:12 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US