Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: backup up archivelogs
Thanks to everyone that responded and their well thought-out answers.
Yes, we are going through a DR exercise and I am eliminating single-points of failure.
I like the idea of having NFS for optional archivelog. Especially since my other colleages are not interested in pursuing Oracle Data Guard and what I need to do is prove/disprove the operational maintenance impact of running that way. In lieu of that writing the archivelogs using NFS works for me.
I love the idea of a matrix describing points of failure. I certainly will do that.
I was given a month to come up with a test. I will document lessons learned and future plans which will include the matrix.
Thanks again for everyone's suggestions.
From: Carel-Jan Engel [mailto:cjpengel.dbalert_at_xs4all.nl]
Sent: Tuesday, May 17, 2005 4:39 PM
To: Stankus, Paula G
Cc: RROGERS_at_galottery.org; oracle-l_at_freelists.org;
onkarnath.tiwary_at_gmail.com; rgramolini_at_tax.state.vt.us
Subject: RE: backup up archivelogs
Paula,
Your site screams for a proper DR risk inventory. IMHO, decisions about HA limitations are the responsibility of your management. Of course, mgmt cannot decide if not provided with the right data, to make their trade-off.
Most important parameters are:
- time to recover - max data loss (measured in time, # of transactions) - possible problems and their connected values of the above - cost of the problems (probably not to be estimated by you) - cost of the countermeasures
I'd start with a risk / countermeasure matrix. The credit for this idea goes to Ally McIntyre, a DBA at a Data Guard customer of mine. Write down any problem you can think of (powerfailure, serverfailure, storage-failure, whatever). These are the rows. Write down your coutermeasures, all of them. For any problem, check the box where the countermeasure helps to overcome the problem. In the last column, write the description how this helps, what the limitations are, etc. When you are finished, start over. I use to have a problem for every solution. Otherwise, Murphy will take care of it. It's all about outsmarting Murphy. In the end, estimate the cost of the countermeasures and the outages/datalosses connected to the problems.
Now management can decide, not you. You will have to explain, to assist, but mgmt. is responsible. Of course there are risks that have to be left open, due to budget restrictions. That's normal. But you better let mgmt. decide about that, in stead of forgetting them. If YOU forget the risks, YOU will be blamed when the accident happens.
Now you are focusing on archive logs, but there are many, many other problems. High Availability should not be technology driven, but requirement driven. Collect the requirements of the business, show them the cost to fulfill them. You're in government, but essentially there's no difference.
My favorite (real-life) example is the site that had UPS's, Generators, Fuel, redundant datacenter, everything. At a major city-wide power aotage everything was fine. UPS did it's work, gemeratir took over, perfect. Until after about an hour the temperature in the server-room raised: it appeared that the airco's weren't connected to the generator. The CEO himself took the windowpanes out their frames, to keep the temperature at an acceptable level.
HTH Best regards,
Carel-Jan Engel
===
If you think education is expensive, try ignorance. (Derek Bok)
===
On Tue, 2005-05-17 at 15:45, Paula_Stankus_at_doh.state.fl.us wrote:
My one concern is this - I know that I can setup optional archive
destinations this way which means to me if there is a problem with the
destination - everything still works. I don't have my primary database
hang waiting to write out online redo logs. However, what if the
optional destination is available but I/O is slower? Will that slow
anything down?
Thanks, Paula -----Original Message----- From: Ron Rogers [mailto:RROGERS_at_galottery.org]=20 Sent: Tuesday, May 17, 2005 9:42 AM To: Stankus, Paula G; oracle-l_at_freelists.org; onkarnath.tiwary_at_gmail.com; rgramolini_at_tax.state.vt.us Subject: RE: backup up archivelogs Paula, That is a valid concern if you loose the archive log destination. How about setting up another destination on a different server or nfs mounted point.=20 Ron >>> <Paula_Stankus_at_doh.state.fl.us> 05/17/05 9:01 AM >>> We have redo members mirrored on multiple file systems. We write the redos to an archive log. We backup the database in full along with archivelogs each night. The problem is that if the entire box goes down or we loose the RAID for archives we would only be able to restore/recover to theprevious night.
I am considering backing up archivelogs to tape immediately as they are
filled up. =3D20
Anyone doing this and their thoughts on gotchas/caveats/best practices?
Thanks, Paula -- http://www.freelists.org/webpage/oracle-l
BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach CanIt if this mail (ID 32665082) is spam: Spam:
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Ds&i=3D32665082&m=3Dfac
d=
<https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Ds&i=3D32665082&m=3Dfa
cd=>
96262 138 Not spam:
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Dn&i=3D32665082&m=3Dfac
d=
<https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Dn&i=3D32665082&m=3Dfa
cd=>
96262 138 Forget vote:
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Df&i=3D32665082&m=3Dfac
d=
<https://dohsmsi01.doh.state.fl.us/canit/b.php?c=3Df&i=3D32665082&m=3Dfa
cd=>
96262 138 ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS -- http://www.freelists.org/webpage/oracle-l
Teach CanIt if this mail (ID 32726411) is spam:
Spam
<https://dohsmsi01.doh.state.fl.us/canit/b.php?c=s&i=32726411&m=d83d1bca
d50c>
Not spam
<https://dohsmsi01.doh.state.fl.us/canit/b.php?c=n&i=32726411&m=d83d1bca
d50c>
Forget previous vote
<https://dohsmsi01.doh.state.fl.us/canit/b.php?c=f&i=32726411&m=d83d1bca
d50c>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 18 2005 - 08:52:36 CDT
![]() |
![]() |