RAID Caching and SQL Server 2008 R2

  • Quick background:

    I have set up three Dell Poweredge 1950's for me to practice setting up an SSRS Scale Out Deployment. In doing so, I set up the RAID controller on each. Everytime the system boots, I get the following error message: "The battery hardware is missing or malfunctioning, or the battery is unplugged. If you continue to boot the system, the battery-backed cache will not function. Please contact technical support for assistance."

    I think I can solve that error by going into the (<ctrl>+<r>) and checking the option for "Force WB with no battery". But, I would like to understand this a little more before doing it.

    My SR DBA has asked me a few questions: 1. What is default caching options for SQL Server? 2. What are the two caching options available with the RAID controller and SQL Server.

    I have been trying my best to research these questions, so that I can intelligently speak about them. I believe the answer to the first question is Write Ahead Logging and I believe the answer to the second question is Read and Write. But both of those can go deeper, for write you can write back or write through. For read, you can have read ahead, adaptive read ahead or No read ahead.

    Where I am confused is, how does checking "Force WB with no battery" relate to WAL? And how does WAL relate to write back or write through caching? Is one of those a nickname for WAL?

    I have read a lot of articles about this today and I am still not clear on what it all means. I hoping one of the guru's on this site can make this make sense to me.

  • I think I am getting things confused here...I am talking about Transaction Logs (WAL) and what I care about is what SQL Server prefers with caching on the RAID controller. I also think my answer is going to be in figuring out what the difference is between Write back and Write through.

  • SQL has no knowledge whatsoever about RAID caching. It assumes when it issues a read that the read comes from disk and it assumes that when it issues a write that the write goes to disk, not cache.

    If you have a write cache that is not battery backed, you need to disable that cache or risk database corruption when there's a hard shutdown.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Thank You Gail for the reply...

    So then the answer to my question is Write Through? In the event of a failure and no battery-backup cache, I will not lose any data due to the event, but my caveat is a decrease in performance. Is this correct?

    Thanks Again Gail!

  • Sounds right, but check with a sysadmin.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply