RE: Re[2]: JUST CURIOUS WHAT ANSWERS I WILL GET ...

RE: Re[2]: JUST CURIOUS WHAT ANSWERS I WILL GET ...

 

  

Does someone has a step to step plan how to create a RAC instance.




"Kerber Andrew "
<oracledba-ezmlmshield-x69749662.[Email address protected]
03/29/2005 09:00 AM

To
"LazyDBA Discussion" <[Email address protected]
cc

Subject
RE: Re[2]: JUST CURIOUS WHAT ANSWERS I WILL GET ...






We use a combination of both hot backups and exports. We are not in a RAC
environment. To restore data from backup typically you take the users
off. We dont like to do this since we have a large number of users using
many different applications. Our most common recovery need is restoring
data that has been changed or deleted accidently. We can use daily
exports to selectively reload tables from the previous day while still
maintaining maximum availability.

-----Original Message-----
From: Paul Murgatroyd
[mailto:oracledba-ezmlmshield-x51561844.[Email address protected]
Sent: Tuesday, March 29, 2005 07:47
To: LazyDBA Discussion
Subject: Re[2]: JUST CURIOUS WHAT ANSWERS I WILL GET ...


There is a lot of misinformation floating around here which may give
people the wrong impression about why you would use certain types of
backups.

1) Whether a database is backed up as hot or cold makes no difference at
all from a recovery perspective. All the data is there and you can recover
to the point of failure.

2) "Only" doing hot backups implies that hot backups are somehow
incomplete and that you need some other form of backup, such as exports,
to make them reliable. This is totally untrue, and I would go as far as
saying that exports are effectively useless for Database Recovery as they
will always contain only a snapshot of the data at a given point in time.
On a large database you would want to ensure it is a "Consistent" mode
export, and depending on transaction volumes and database size, this may
prove difficult unless you have lots of undo space available.

3) Cloning from a Hot backup is pretty straight forward as it is, but use
the RMAN Duplicate Feature and it is pretty much an automated process.

4) Shutdown and startup of a database has little to do with backups and
more to do with procedures. If you shut down an Oracle DB with active
application transactions, Oracle must wait for them complete before the DB
will close (unless you use shutdown abort). This can cause what appears to
be a database "hang". Shutdown "immediate" does not mean "shutdown right
now" - I have seen shutdown immediate commands that have taken 2 days to
finish.

Regards,

Paul

*********** ORIGINAL MESSAGE ***********

On 28/03/2005 at 10:09 AM Michael Porter wrote:

I don't think there is necessarily a right or a wrong but, what makes
sense for your environment. If you are a 24x7 shop, cold backups no
matter how valuable (perception or otherwise) are out of the question.
If you are only doing hot's, I would do exports (full if possible or by
schema if not) and test test test your hot backups by creating a
database from the hots' on a routine basis..

Many shops are NOt 24x7 and have the luxury of doing colds. Nothing
beats a copy of your WHOLE server (while oracle is down) from a disaster
recovery perspective. Cold's also provide for easy cloning, exports
of schema/tables, building partial databases to restore/recover
portions of a db, etc. This can always be done from a hot too, it's
just a little more effort in my eyes...

Shutdown/startup do introduce potential issues but, I've also found
problems this way so I can't say for sure whether there is any more
inherit risk by doing such (if there is, ORacle needs to address)...





--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these terms:
http://www.lazydba.com/legal.html



--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these terms:
http://www.lazydba.com/legal.html



Oracle LazyDBA home page