NT striping dangerous with Oracle 7 or 8?
bdur...@ccci.org
I have been told that it is dangerous to use NT striping with Oracle on NT
4.0. This person told us that NT buffers some Oracle writes in memory and if
the server is turned off at the wrong time the data could be corrupted. I
find this hard to believe, but I wanted to post this question just to be sure.
Is there a problem using NT striping and oracle 7 or 8 server?
Thanks,
Bobby Durrett
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Adrian Shepherd
This would be true of Software striping , but not of a hardware / raid 1/2/5
stripe.
bdur...@ccci.org wrote in message <6d6l3i$ema$1...@nnrp1.dejanews.com>...
Kevin P. Fleming
This would also be true of a hardware RAID implementation unless the RAID
controller contains battery-backed memory and can hold those final disk
writes until the drives are powered up again.
NT striping is no more dangerous that any other implementation. Whether
Oracle is writing directly to the disks (in RAW mode), or going through a
non-buffering operating system, or using the operating system's software
RAID implementation, it makes no difference. There will always, always be
cases where if power is lost at the wrong time data will be corrupted.
Most SCSI hard disk drives nowadays have largeish on-board caches anyway, so
even getting the data to the drive doesn't guarantee that it will be put
onto the media if power is lost at exactly the right moment.
Uday Bikkasani
NT striping is always dangerous. Try the Raid striping at the hardware
level. Also make sure that you have battery backups on the raid controllers.
If power is lost there are many points of failure even if make sure that you
have battery backups. Make sure you have a good backup strategy implemented.
uday
Michel Kergoat
What about the fiability of a commit statement ?
IMO, the commit statement should take care of physical write on disk. What you
said
sounds like "striping driver says to process that data is wrote, but it is not
really wrote".
When writing on disk, it is not a matter of commit response quickness, but sure
the
trustness of a driver's response.
I think that you talk about write caching, rather than disk striping.
And this is the same on any OS, isn't it ?
Couldn't the write caching of the striping driver be turned off ?
MK :-)
Matthias Gresz
On Fri, 27 Feb 1998 18:37:35 -0500, "Uday Bikkasani" <ud...@mindspring.com> wrote:
Hi,
battery backups are always dangerous. Do you know wehter after 3 years your batteries still have the capacity to do their work? turn on write through and you're save. OK, this may lead to performance
loss, but it's better than loosing db-consistency.
>NT striping is always dangerous. Try the Raid striping at the hardware
>level. Also make sure that you have battery backups on the raid controllers.
>
>If power is lost there are many points of failure even if make sure that you
>have battery backups. Make sure you have a good backup strategy implemented.
>
>uday
>
>bdur...@ccci.org wrote in message <6d6l3i$ema$1...@nnrp1.dejanews.com>...
>>I have been told that it is dangerous to use NT striping with Oracle on NT
>>4.0. This person told us that NT buffers some Oracle writes in memory and
>if
>>the server is turned off at the wrong time the data could be corrupted. I
>>find this hard to believe, but I wanted to post this question just to be
>sure.
>>Is there a problem using NT striping and oracle 7 or 8 server?
>>
>>Thanks,
>>Bobby Durrett
>>
>>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>>http://www.dejanews.com/ Now offering spam-free web-based newsreading
>
>
--
Regards
Matthias Gresz :-)
Gr...@T-online.de
bdur...@ccci.org
>
> This would also be true of a hardware RAID implementation unless the RAID
> controller contains battery-backed memory and can hold those final disk
> writes until the drives are powered up again.
>
> NT striping is no more dangerous that any other implementation. Whether
> Oracle is writing directly to the disks (in RAW mode), or going through a
> non-buffering operating system, or using the operating system's software
> RAID implementation, it makes no difference. There will always, always be
> cases where if power is lost at the wrong time data will be corrupted.
>
> Most SCSI hard disk drives nowadays have largeish on-board caches anyway, so
> even getting the data to the drive doesn't guarantee that it will be put
> onto the media if power is lost at exactly the right moment.
Wow, so you are saying that you really can't protect your database from
losing data? If you lose writes to the redo log and to a data file wouldn't
you really be sunk? i.e. You couldn't even recover in that case. If you were
doing a lot of heavy updating and commiting transactions and the power went
out you could lose a bunch of stuff.
But this is not NT specific I suppose. A Sun or HP unix box would have the
same issues, correct?
- Bobby
bdur...@ccci.org
>
> NT striping is always dangerous. Try the Raid striping at the hardware
> level. Also make sure that you have battery backups on the raid controllers.
>
> If power is lost there are many points of failure even if make sure that you
> have battery backups. Make sure you have a good backup strategy implemented.
Thanks for your reply. Our plan is to use hardware mirroring and NT striping
over the mirrored drives. The HP Netraid cards we are using will not allow us
a hardware mirrored and striped array big enough so we are trying a
combination of hardware and software raid. I guess the "engineer" we were
talking to thought NT would write cache the NT writes if we used striping. A
person from Oracle confirmed that Oracle doesn't cache writes.
I am concerned about the trustworthyness of our battery backups and whether we
should set the cards to write-back instead of write-through to speed writes.
Eugen Nyffeler
bdur...@ccci.org wrote:
<snip>
> losing data? If you lose writes to the redo log and to a data file wouldn't
> you really be sunk? i.e. You couldn't even recover in that case. If you were
> doing a lot of heavy updating and commiting transactions and the power went
> out you could lose a bunch of stuff.
>
> But this is not NT specific I suppose. A Sun or HP unix box would have the
> same issues, correct?
Yeap,
Any system which has no battery buffer will loos data which is only in
the
cache at this moment. Any system i know has this problem (Unix, NT,
etc.).
Steve Phelan
I sorta lost with the reasoning here, because you'd still be buggered when
the battery backup ran out... OK, you may have warning alarms, etc., but in
the middle of the night you might not be there to hear them.
Surely a 'write through cache' is the only real solution?
Steve Phelan.
Eugen Nyffeler wrote in message <34FBDB7C...@ubs.com>...
Eugen Nyffeler
Steve Phelan wrote:
>
> I sorta lost with the reasoning here, because you'd still be buggered when
> the battery backup ran out... OK, you may have warning alarms, etc., but in
> the middle of the night you might not be there to hear them.
>
> Surely a 'write through cache' is the only real solution?
>
> Steve Phelan.
>
It depends on the implementation. A battery backup should only be used
to
do a clean shutdown during power failure. In this cases the system goes
down, but
the data is saved to the discs.
If a system must run during power failure, then there should be a
generator,
which can supplie the required power during "out time" and the battery
is used
to in the time between power failure and automatic start of the
generator.
Thats the 2 implementation of battery powered system i saw till now and
which
make sens to me. The 'write through cache' is cheaper (i think), but the
clean shutdown is in this case missing.
Hope with this my prev. msg makes sense
eugen
bdur...@ccci.org
I think you are right Steve. Our new building is supposed to have a UPS and a
generator to backup up our system, so that would theoretically prevent the
battery backup from running out. But if the power went out on a weekend and
things didn't work with the generator we would still be toast when the battery
backup ran out.
I checked into the post about disk drives write caching and I found out it was
also true, but ours are set up with "write-through" type writing by default.
So if we set our raid controller to write through we should be okay.
We can still lose the data currently being written, but with database logging
Oracle can recover it.
- Bobby
>
> I sorta lost with the reasoning here, because you'd still be buggered when
> the battery backup ran out... OK, you may have warning alarms, etc., but in
> the middle of the night you might not be there to hear them.
>
> Surely a 'write through cache' is the only real solution?
>
> Steve Phelan.
>
> Eugen Nyffeler wrote in message <34FBDB7C...@ubs.com>...
> >bdur...@ccci.org wrote:
> ><snip>
> >> Wow, so you are saying that you really can't protect your database from
> >> losing data? If you lose writes to the redo log and to a data file
> wouldn't
> >> you really be sunk? i.e. You couldn't even recover in that case. If you
> were
> >> doing a lot of heavy updating and commiting transactions and the power
> went
> >> out you could lose a bunch of stuff.
> >>
> >> But this is not NT specific I suppose. A Sun or HP unix box would have
> the
> >> same issues, correct?
> >
> >Yeap,
> >Any system which has no battery buffer will loos data which is only in
> >the
> >cache at this moment. Any system i know has this problem (Unix, NT,
> >etc.).
>
>
Steve Phelan
The other issue I have with battery backup is that it only covers crashes
from the "Whoops, I've lost power..." point of view.
You also have to consider hardware failure inside the server - disks,
memory, network cards, disk controllers, CPUs, internal power-supplies and
so on. I've put together a few systems for large Banks where we've basically
ended up mirroring everything - and I mean everything. Remember, a chain is
only as strong as it's weakest link, and that includes a lot more than just
the power supply...
It's worth pushing your vendor really hard on these issues, along with
potential disaster scenarios - because it's suprising just how many
'misunderstandings' you can manage to pick out of their PR stuff in the
sales brochures (and that includes Oracle).
Just my thoughts (again!) :-)
Steve Phelan.
bdur...@ccci.org wrote in message <6djknn$uu$1...@nnrp1.dejanews.com>...
Joel Garry
In article <6djknn$uu$1...@nnrp1.dejanews.com>, <bdur...@ccci.org> wrote:
>I think you are right Steve. Our new building is supposed to have a UPS and a
>generator to backup up our system, so that would theoretically prevent the
>battery backup from running out. But if the power went out on a weekend and
>things didn't work with the generator we would still be toast when the battery
>backup ran out.
I worked in a place once that had just installed a huge UPS and Detroit
Diesel generator. One day, the alarm on the ups went off. My boss kept
resetting it, and it kept going off. Finally, he put a piece of tape over the
alarm reset button. I had a feeling if the thing was complaining, something
was wrong, so I went for a little walk, and saw the diesel was running.
Turned out the thing had a swimming-pool style timer, set to turn the thing
on once a week. But of course, no one set it to turn off, so both line
voltage and generator voltage were being fed into the UPS. Unlike line
voltage, the frequency of the generator voltage varied by several Hz, so
no wonder the UPS was screaming... as two times 220V went in and out of
phase...
--
These opinions are my own and not necessarily those of Information Quest
jga...@eiq.com http://www.informationquest.com
http://ourworld.compuserve.com/homepages/joel_garry
"See your DBA?" I AM the @#%*& DBA!