Re: database revovery issue(my system is down)

"utkanbir" <hopehope_123_at_yahoo.com> wrote in message news:f6c90ebe.0310290402.88da023_at_posting.google.com...
> Hi Howard,
> Thanx for your help.
>
> > You should have "decided" to restore the two datafiles that were
reported as
> > problematic, and recovered the *datafiles*, not the database. The
database
> > isn't at fault here, only two specific data files.
>
> I have realized it.
>
> > Let's see if I got this right. You are building a data warehouse RAC on
a
> > machine for which you have no reliable and functioning backup software
and
> > for which you have no backup medium capable of storing the stuff you
> > actually care about -namely your data. Are you quite sure this is the
> > direction you want to be going in??
>
> Of course it is not. I am not the architect of this system .

You mean they actually had an architect for it??!

Or was it just that EMC, Linux and Itanium sounded quite sexy, so they decided to throw the lot together without a lot of thought for such minor details as data integrity, safety etc etc? My money's on the latter.

> If i
> would , sure things would be better now. Although i am new with oracle
> , i know how to treat a database system . The company has already
> started the project and purchased the system when i started the job.
> Thats why i have 4 unknowns at my hands , itanium,linux,rac,emc.
> Legato has not released a version on itanium yet , the emc box has not
> enough disks for backups .

Rule out RAC as an unknown, in the sense that you back it up exactly as you would a non-RAC Oracle database. There is only one database, after all... just multiple instances, which don't complicate the issue any.

> > I think so. You report corruption in SYSTEM and USER, and you state you
have
> > backups for system.dbf and user.dbf. Since you only need to restore
those
> > two files, then you should be able to do the resotre. Can you then do
the
> > recovery? So long as you have all the archived redo logs produced since
the
> > time of those files' backups, and the online redo logs, yes.
> >
>
> i will try this. I have already suggested this to the one who supposed
> to do the restore but could not insist since i am new with oracle.

My point was that it is already too late, probably. By issuing the other recover commands, you have modified the data files to a point where it is difficult to know whether they will now work happily when you re-restore and re-recover. Usually, they don't (but since I wasn't watching at the time, I can't know for sure). Usually, when you perform a recovery, it makes sense to have a precautionary (and extra) backup of (at the least) the control files and online redo logs, so that you can replace them for a re-try (along with the datafiles from backup... but you don't even have all of those). It really isn't looking too good.

>
> > 'recover database using backup controlfile'
> >
> > Oh, why do people "experiment" with recovery commands.
>
> No i did not experiment it.It was the command that oracle dbas run.

I didn't say *you* experimented. Just "people". Your oracle dbas experimented. Someone else experimented about four weeks ago in this very forum, and lost data as a result, too. It happens too often.

> >
> > Did you restore a binary version of the controlfile? No?? Then why in
> > Heaven's name would you even think you need the 'using backup control
file'
> > command?
> >
> i will ask this .
>
> > And why are you restoring the undo tablespace? Did dbverify report that
to
> > be corrupt?? Not according to your post it didn't. So why are you
restoring
> > things that don't need restoring??
> >
> Yes , undo tablespace has also corrupted blocks.
>

Not what you wrote, but no matter.

> > Your mistake is to blunder about, issuing inappropriate restore and
recovery
> > commands, and hoping you'll muddle through somehow.
>
> > So many questions. Learn about backup and recovery, and the answers will
be
> > obvious to you. You've royally stuffed things up by throwing ad hoc
recovery
> > commands at a database that didn't need them. You should just have
restored
> > the two datafiles that dbv reported to be corrupt, and said 'recover
> > datafile 'system.dbf', followed by 'recover datafile user.dbf', rollowed
by
> > 'alter database open'. End of story. Once you start restoring other
things,
> > and issuing recover commands that aren't needed, Lord knows what state
your
> > database is in, and since you don't have a complete database backup you
> > can't reverse the process to find out.
> >
> > Bye-bye database.
> >
>
> I understand your point but believe me it is not my style to deal with
> a serious system like this. Although i am new with with oracle ,i have
> strong experience with database systems.

All of which you can now throw out of the door for this particular problem. Oracle isn't just another database system, at least as far as backup and recovery is concerned. You, your dba's, "people" need to know how *Oracle* works, otherwise it becomes just a matter of blundering around and hoping. Funny thing is, recovery is really quite easy, so long as you know the (about) five basic principles.

>I restored lots of database
> server systems only difference is they were not oracle, and i trained
> lots of people about data archive procedures , rules , check-lists
> ,etc. Suggested them same things that you suggested to me , and posted
> messages to people who played with their system like a toy in order to
> make them understand the value of their system. So , again i know your
> point.But my point is , i am new with this job , large database ,
> missing procedures , and actions taken by whom are considered
> experienced with their job. i agree with you that i am asking so many
> questions , but i am not blindly playing with the gigabytes server .

What I wrote wasn't intended as a go at you personally. Just amazement in general that people ask for help *after* they've already 'had a go' (and thus changed things irrevocably, and beyond the point at which help and advice is usually much good).

Also astonishment at how many people report losing data from an Oracle database when the guarantee is desperately simple: you will not lose committed data from an Oracle database. Provided one knows what one is doing, has a complete backup to hand, and don't lose archive and online redo logs.

Regards
HJR Received on Wed Oct 29 2003 - 13:07:32 CST