Ken,
I'm guessing when you say RAID, you mean RAID5. This is notoriously
slow for writes, particularly in a RDBMS environment.
You have noticed that it is too slow without the write cache, but
essentially you have a poor I/O capacity device helped by the cache and if
there were any problem with the drive and cache or cache battery or
configuration then you would indeed have missing data. Is this a worthwhile
risk bearing in mind that if you write enough data to saturate the cache,
you will still be at the mercy of the slow disk writes.
RAID5 is more cost effective then some better performing RAID levels
but for write intensive applications it is a false economy.
There that's got it off my chest.
- Mike.
Mike Jenner
Database Administrator
-----Original Message-----
From: Ken Nickels [mailto:[Email Address Removed] 14 August 2002 17:43
To: '[Email Address Removed] Write caching
I think that what happens is the disk controller will tell sql server that
the data is written to disk even though it is only pending. Sql server is
happy with this. It thinks it is complete. In the event of a real disk
failure the battery holds the transaction and (this is the important part)
and the controller will commit it to disk after the problem is fixed and the
operating system boots, soft of like unfinished business. This will
necessarily happen before Sql server starts up and recovers so
(theorectically) it should not be marked suspect.
This is the way battery backup on RAID was explained to me. We have write
cacheing turned on for all our RAID controllers. It is too slow without it.
Knock on wood, we never had a failure.
Ken Nickels
Gemini Voice Solutions
You can lose transactions in event of a crash.
SQL server will have thought it had written the trx when, in fact, its still
sitting in the controllers cache.
When SQL svr restarts it looks in the db log file for uncommitted trx and
it wont find them
or will find part of one. Now your DB will probably be marked as 'Suspect'.
At best you'll be missing data at worse you'll be missing data AND the db
will be corrupt.
Fun stuff
---------------------------------------------------------------------
To unsubscribe, e-mail: mssqldba-[Email Address Removed] additional commands, e-mail: mssqldba-[Email Address Removed]MS Sql Server LazyDBA home page