RE: backup best practices
- From: "Johnson, George" <GJohnson@xxxxxxx>
- To: "'Mark.Bobak@xxxxxxxxxxxxxxx'" <Mark.Bobak@xxxxxxxxxxxxxxx>, swhite@xxxxxxxxxxxxx, Oracle-L@xxxxxxxxxxxxx
- Date: Fri, 7 Oct 2005 16:49:58 +0100
I would mention what a previous poster said about an O/S. It's good to
bounce every so often to check that if you needed to, you can do it in an
emergency, you know the system can auto-recover by itself. The number of
times we have left systems up while changes have been made, then we bounce
'em only to find that such and such a service never started or the DB never
started 'cos the pfile got changed and never tested. The spfile goes some
way to helping by stopping people who don't know what they are doing, from
simply editing a text pfile and messing the format up.
Personally I would leave 'em up 24/7, that's what archives and hot
backups are for, but I get voted down every time I raise it at my shop! So
we are stuck circa 1995, one guaranteed cold backup once a week of all
databases, without fail!
-----Original Message-----
From: Bobak, Mark [mailto:Mark.Bobak@xxxxxxxxxxxxxxx]
Sent: 07 Oct 2005 15:51
To: swhite@xxxxxxxxxxxxx; Oracle-L@xxxxxxxxxxxxx
Subject: RE: backup best practices
Well, part of this will depend on whether you're running a "real" O/S...;-)
I'll let folks decide for themselves what a "real" O/S is or is not....;-)
Seriously, though, in my opinion, a production database in archivelog mode
should almost never need to be bounced. I see no reason for scheduled
bounces or outages. Since 9i, when you can set SGA_MAX_SIZE and dynamically
adjust many, many parameters, there are fewer and fewer reasons to need to
bounce. A properly implemented hot backup strategy should be able to
provide for recovery from any type of media failure. I can't think of any
scenario where a cold backup is "better" than a hot backup. I can't think
of any reason to bounce a instance. All you do is thrash the buffer cache
and library cache.
My two cents,
-Mark
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Susan White
Sent: Friday, October 07, 2005 10:38 AM
To: 'Oracle-L@xxxxxxxxxxxxx'
Subject: backup best practices
Should off-line backups (RMAN or otherwise) be a part of a standard backup
strategy? In the "old" days, cold backups were recommended for consistency -
or at least that's how I understood it. Now, it seems that these are not
deemed essential. What is the recommended best practice for off-line/on-line
backups?
Related to this: Should the DB be "bounced" occasionally? In my last
oracle class, this was implied, although not stated. Any thoughts
Thanks
Susan White
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
****************************************************************************
Other related posts:
