| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Restoring Oracle Control Files
Howard,
Thanx for your detailed reply. Good thing to know that we are restoring the control files correctly. As far as the command I type to start the recovery it is
"restore database using backup controlfile until cancel"
the only reason i cut it in the post was since sybrand had mentioned the whole command in his post. Anyhow sorry for the confusion. You were right about all the files being restored. When restoring the backup I use the overwrite option so that would overwite any files in the database directory. however on taking a close examination of the directory structure where the files are being restored i found that some dbf's (SYSTEM01.dbf, USER01.dbf and INDX01.dbf to be precise) had date stamps which not the same as the one on the other files that had been restored. Dont know why that happens..but then i went into veritas and manully restored those files one by one. after that I try repeat the recovry procedure as i described in my last post but as soon as i try to run the first command to mount the db it gives me this error.
SVRMGR> startup mount
ORACLE instance started.
Total System Global Area 344438812 bytes Fixed Size 75804 bytes Variable Size 103976960 bytes Database Buffers 240308224 bytes Redo Buffers 77824 bytesORA-01991: invalid password file
as far as i know this error has something to do with the password file generated when the database is created. I had faced this error before quite some. if you think there is another reason this error message is coming please let me know. Meanwhile i am going to create a new database and then try both the backup and restore procedures on it and see if get the same ORA-01991 when i try to mount it.
TIA, Jiga
"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<401825ac$0$19707$afc38c87_at_news.optusnet.com.au>...
> "jiggaman" <jiggamanrocks_at_yahoo.com> wrote in message
> news:5374d389.0401281249.58999ccb_at_posting.google.com...
> > Thanx for your post Sybrand. I tried that however still no success.
> >
> > The backup that i am trying to restore is a online backup taking using
> > veritas backup exec 9.0. once i restore its puts all the files into
> > the place except for the control file which is renamed as i mentioned
> > in my previous post. So Shutdown the database, Do the Restore using
> > veritas, and then Following you intructions i Copied the BECF<SID>.bak
> > to 3 seperate files and renamed it CONTROL01.CTL CONTROL02.CTL and
> > CONTROL03.CTL, Then I Use STARTUP MOUNT and then run the Recover
> > database........cancel command after that i type cancel and then i the
> > following
> >
> > ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get
> > error
> > below
> > ORA-01195: online backup of file 1 needs more recovery to be
> > consistent
> > ORA-01110: data file 1: '/oracle/oradata/epitest/system01.dbf'
> >
> > however after getting those messages i still run the alter database
> > open resetlogs and its gives me a message saying that more recovery
> > has to be done to make it consistent .
> >
> > I am not sure where i am going wrong and why the system01.dbf is not
> > correctly being restored. Any Help will be higly appreciated
>
> The error message is spurious, in the sense that it probably isn't file 1
> that's causing the problem all on its own, it just happens to be the first
> file that Oracle notices fails some test or other. The classic cause of
> seeing it is when you fail to restore absolutely every single data file in
> the database before performing an incomplete recovery. That means you leave
> one file at a time ahead of where all the others are going to get rolled
> forward to, and that's an inconsistent database and can't be opened. The
> file you failed to restore from backup prior to recovery might be file 452,
> but the error message will still report it as a problem with file 1, because
> in a sense it is: file 1 is behind file 452, and that's the problem Oracle
> sees. The real problem is that file 452 is ahead of file 1, of course, but
> that's just a different perspective on things, and not one that Oracle
> itself indulges in.
>
> Which is a rather lengthy way of saying 'don't worry about the specifics of
> the error message; the problem is the way you are performing your recovery,
> not a specific issue with file 1'.
>
> Now, clearly, Sybrand's suggestion for the control file backup renaming
> *did* work, because otherwise you wouldn't have been able to get to the
> mount state and begin database recovery. So that's your control files
> restored.
>
> When you get into the mount state, you want to make sure that there are no
> offline data files (you can query from v$datafile in the mount state). If
> there are, online them. Check the checkpoint_change# for all data files,
> too, if you can.
>
> You included elipses ("...") in your reply in precisely the wrong spot!!
> It's your recovery process that is failing, so we need to know *precisely*
> what the recovery command you issued was: "recover database.....cancel"
> misses out just exactly the one bit of information we needed to know!!!!!!
>
> The command should have been "recover database USING BACKUP CONTROLFILE
> until cancel".
>
> Try again, and don't cut things out next time!!
>
> Regards
> HJR
Received on Thu Jan 29 2004 - 08:47:07 CST
 |
 |