Re: Simple archive question

Comments embedded

utkanbir wrote:
> Hi Arun ,
>
> These are the steps and error message:
>
> Starting form the beginning:
>
> 1. shutdown immediate
> 2. copy all files to a backup location . (al files including control
> redo undo)
> 3. startup and create some tables insert data commit.
> 4. archive log all;
> 4. shutdown immediate.
>
> at this state , select * from v$log says the current log seq is 295 ,
> it is not archived . Log 294 is inactive and archived . These are the
> only logs defined since this is my laptop.
>
> now i start recovery:
>
> 1. copy files back to the original location apart from redo logs.
> 2. startup mount
> 3. recover database using backup controlfile;

You have to understand what the 'using backup controlfile' actually means: You're telling Oracle that the SCN that's recorded in the controlfile(s) are not indicating until which point in time the recovery has to proceed, so the only one able know when the recovery is done is you.

>
> It returns with error :
>
> ora-00279 and ora-00289 . In ora-00289 it says it needs arc295.001:
>
> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
>
> This log is the current log and it is in redo log files not archived .
> At this
> point i choose <ret> option but since the log is not archived i got
> the same error and recovery fails.

So tell oracle the location of the redolog - it's asking for it, isn't it?
>
>
> Since seq 295 is not archived and inside the redo log files , why does
> the recovery ask the archived location?
Because oracle does not know that it's not archived because you said it's a backup controlfile so oracle just doesn't trust the control files content.
>
> These are the steps . I still havent understood the point i missed .
Just give the names of the redologs, then type CANCEL to stop the recovery and finally you're forced to alter database open resetlogs. All of which is quite unnecessarily complicated because you still have the controlfiles and the most important rule in a recovery scenario is this:

        ONLY RESTORE WHAT YOU HAVE LOST. And only what you restored is what you recover.

I don't know if you're responsible for a production database, but if you are, please learn as much about backup and recovery as you can. Google around and read everything what you can find that was written by Howard J. Rogers, as he used to go very detailed into the whole subject, in fact, I've got to admit that I learned less from the documentation than I learned from his contributions to this NG. This does not mean that you shouldn't read the documentation, but that's how I started off.

Practice as much recovery scenarios (the most important ones are in the documentation, e.g. RMAN User Guide, 9i Backup and Recovery Concepts).

HTH
Holger Received on Mon Mar 14 2005 - 09:38:25 CST