RE: Write cache for a SAN

From: Freeman, Donald <dofreeman_at_state.pa.us>
Date: Mon, 3 Nov 2008 15:02:36 -0500
Message-ID: <55264C4C0484A547B34C0B1A28E219EA1952D15C93@ENHBGMBX01.PA.LCL>

Well, I guess it depends on exactly what he did. If the thing was down and had to have the batteries swapped in order to retain the data then you probably lost the data. If it was up and hot swappable he might have set it on fire. If he replaced them and forgot to take the tape off the terminals they probably failed to work at a later date when you really needed it to.

I'm as paranoid as the next guy in this business. I'm worried both about what I know and what I don't know. You definitely have to think things through and reduce your risk to as low a value as possible. The trade off here is performance vs.. data integrity. If you can accept slightly elevated risk to gain some better performance then you'll want to enable write caching. I accept that there can be many good reasons not to do it.

Donald Freeman
Database Administrator II
Commonwealth of Pennsylvania
Department of Health
Bureau of Information Technology
2150 Herr Street
Harrisburg, PA 17103
<mailto:dofreeman_at_state.pa.us>

From: Jared Still [mailto:jkstill_at_gmail.com] Sent: Monday, November 03, 2008 2:09 PM
To: Freeman, Donald
Cc: Oracle-L Freelists
Subject: Re: Write cache for a SAN

On Mon, Nov 3, 2008 at 7:19 AM, Freeman, Donald <dofreeman_at_state.pa.us<mailto:dofreeman_at_state.pa.us>> wrote: We don't disable it. The SAN manufacturers have made this as bullet proof as possible.

Guess what happens when the storage vendor sends out a tech to replace batteries (the batteries that ensure the write cache stays put), and the tech can't be bothered to follow instructions?

What do you think might happen to the write cache?

I'm not saying that the write cache should be disabled, but you need to ensure that the folks that maintain the HW actually know what they are doing.

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Nov 03 2008 - 14:02:36 CST

Original text of this message