I might check out this book for "how to be a dba" type stuff and what the life of a dba is like:

</code> http://www.amazon.com/gp/product/1590594517/qid=1134657097/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/102-9215732-4456915?n=507846&s=books&v=glance <code>

I have it and I really like it so far.

Tom,

Great advice!!!

Thanks for beating that 'dead horse' some more!

Have you heard anything about the abovementioned book?

Thanks,

Robert.

I have Sam R. Alapati's 9i Administration Book and it is
one of my favorites.

Hey Tom -

I got an email from Bookpool.com a couple of days ago, and apparently your book was the best-selling book over there that day! It's #2 today. Anyway, so far it has been a great read, I'm glad I bought it. My favorite chapter so far has been the one on locking and latches. The chapter on datatypes was very informative too though. Which reminds me of a quick question I had if you don't mind, should hashes such as the MD5 hash be stored in a RAW column too? I think that's what you were implying in one of the paragraphs about storing binary data. I've always stored them in VARCHAR2 fields, but then I haven't had to deal with multibyte character sets either...

</code> http://www.bookpool.com/.x/SSSSSS_C561S671089D0512131417/bs <code>

Kashif

I just checked the DBA_USERS table and I noticed that Oracle stores the hashed userid password in a VARCHAR2(30) column. I wonder why... Anyway, thanks Tom.

Kashif

The book is pretty weak containing lots of generalization.

I will sell you my copy if you'd like.

Hi Tom,

You stress so much on recovery and why dont you write a book on Backup and Recovery like expert one to one
I am sure it will be a big hit like your earlier books

Regds
Girish

Tom has given a nice answer as usual :).

I would add more things, like never underestimate their currect strategies for the Oracle Database Administration. Suppose if they are not using the RMAN, there might be some good reason for that, same for not using the Partitioning, RAC etc. And as new DBAs get older in the company, then they come to know, why this all is happening.

But practise various recovery scenarios, so you have an idea what to do in each case - often the pressure is on and you don't always have the time to think things through as thoroughly as you would like. I found the following web document very useful when I first started, though I offer no guarantees for it:-

</code> http://www.uaex.edu/srea/bkupreco.htm <code>

In recovery situations you need to do 1 thing first - back up the damaged database before you start recovery so that you can at least get back to the start point if your recovery goes wrong. Then you need to establish what state the database is in, and decide what point you want to get back to.

Tom,
You always say that practice backup and recovery. The problem is that practice will teach me how to recover but not necessarily the fundamental behind what I am doing. I can follow a set of steps to recover. I might be able to recover perfectly but still may not know why I did what I did.

You know so much about the concepts behind backup and recovery. If you write a book (maybe a small handbook) which details various failure scenarios, what needs to be done to recover in those scenarios and most importantly, the reasoning behind those recovery steps, it will be great.

Maybe if all your followers request, you might consider doing it?

Thanks

"The problem is that practice will teach me how to recover but not necessarily the fundamental behind what I am doing. I can follow a set of steps to recover. I might be able to recover perfectly but still may not know why I did what I did."

In my experience, what will happen is that as you practice, you'll get it wrong. By getting it wrong, you learn. I've found that the reason people understand so little about recovery is that you don't get to *do it* often enough in many companies. That's why a backup and recovery course is a rewarding experience - you get to play around, make mistakes and learn. The same applies to regular recovery tests.

Even if someone filled your head with every single concept behind backup and recovery, you wouldn't truly understand it until you've done it yourself.

Just my 2 cents, pence or whatever your currency of choice.

I find that I am doing recoveries all the time. When managing large enviroments, with multiple projects, you get all the practice you can handle. There are howerver, still times when things go wrong. I find that because I do it all the time, getting around difficulties becomes easier.

It is a great feeling KNOWING that you can survive any failure.

...and I believe that all of you who practiced recovery did so without reading any concepts manual or without referring to any documentation at all? I am amazed that everyone is up in arms against me. If concepts are so unimportant, why have we seen Tom advise numerous times to to readers to go through the concepts manual? Tom, you have a lucid style of explaining things with examples and experience that make understanding so easy. Oracle documentation is about as much fun as reading 1040 instructions (yeah it is tax time). If backup and recovery are practiced with concepts explained by Tom Kyte, it would make better DBAs. However, if you don't want to write in this area, that is fine. It was just a suggstion, no offense.

To a Reader ....

I wasn't going to bother following up, but ....

"...and I believe that all of you who practiced recovery did so without reading any concepts manual or without referring to any documentation at all?"

I read the documentation and practiced. There were no other concepts guides about backup and recovery at the time as far as I know. I learnt the most important and persistent lessons when I made mistakes.

"I am amazed that everyone is up in arms against me."

Well as there are only a couple of comments after your comment and one of them is mine I'll assume I'm part of 'everyone'. I don't see how you can describe the comments as being up in arms against you. Actually, I was trying to be helpful by saying that practice was an essential part of learning about backup and recovery and that I've found a lot of people find a good course helpful in this area.

"If concepts are so unimportant, why have we seen Tom advise numerous times to to readers to go through the
concepts manual?"

They are essential. That's why there's a manual explaining them

</code> http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14192/toc.htm <code>

Whether the manual or a commercial book is the easiest way to learn is down to the individual but my own opinion is that both approaches require some practice to work best. I've seen people do recovery exercises on courses who have read books a little, been DBAs for a year or two and watched as the concepts finally made some sense to them.

"Tom, you have a lucid style of explaining things with examples and experience that make understanding so easy. Oracle documentation is about as much fun as reading 1040 instructions (yeah it is tax time). If backup and
recovery are practiced with concepts explained by Tom Kyte, it would make better DBAs."

There was no problem with asking if Tom would be writing a book on the subject and I'm sure it would be excellent if he was interested in it. I was just trying to help you by suggesting that the best book in the world wouldn't take away the need to practice a lot. Fair enough, you don't like the suggestion which is your choice. Sorry if that offended you in some way!

To Jeff

"When managing large enviroments,
with multiple projects, you get all the practice you can handle."

It definitely depends on the kind of site you work at. In some roles, particularly more development-orientated or with *tons* of databases, you never seem to *stop* doing recovery ;-) But some production DBAs managing a couple of dozen databases often don't get enough recovery opportunities if their managers don't feel that practice is important enough.

Here is course of action which I believe has helped me.

1. Read the Backup and Recovery manual(s).
2. Set up a small 'test' database.
3. Take a cold backup of it and store this backup somewhere 'safe'. (include the controlfile).
4. Now make a list of every type of backup/recovery scenario you can think of (e.g.: lost datafile, lost controlfile, missing archivelog, full recovery, partial recovery to a point in time, recovery using backup controlfile to a previous incarnation, etc.... whatever you can think of).
5. Now take hot backup(s) of database ...And try to recovery in each scenario you listed. Add or modify scenarios as you get feedback from your experience... Make them as complicated as you like.
6. WHEN YOU GET STUCK... Try to find answers to your problem in the manuals, on AskTom, on Metalink, etc.
7. Whenever you get things messed up beyond fixing... then restore from the cold backup and start over again.

Do this for both RMAN and manual backup/recovery.
Keep doing this until you feel comfortable with each scenario.

This approach has helped me to feel more confident in my backup/recovery skills.

Regards,

Robert.

We would like to know how to take oracle hot backup and recovery in windows machine briefly step by step