RE: backup up archivelogs
- From: <Paula_Stankus@xxxxxxxxxxxxxxx>
- To: <cjpengel.dbalert@xxxxxxxxx>
- Date: Wed, 18 May 2005 08:47:51 -0400
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@xxxxxxxxx]
Sent: Tuesday, May 17, 2005 4:39 PM
To: Stankus, Paula G
Cc: RROGERS@xxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx;
onkarnath.tiwary@xxxxxxxxx; rgramolini@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxx]=20
Sent: Tuesday, May 17, 2005 9:42 AM
To: Stankus, Paula G; oracle-l@xxxxxxxxxxxxx;
onkarnath.tiwary@xxxxxxxxx; rgramolini@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx> 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 the
previous 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
<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
<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-l
Other related posts: