SQL Server Performance

Disk cache and windows SP3 bug

Discussion in 'Performance Tuning for Hardware Configurations' started by chadiswar, Jun 12, 2003.

  1. chadiswar New Member

    I recently contacted IBM regarding an un-related problem and from our FastT disk array. From the logs they pointed me to a new bug and hotfix regarding Windows and read/write disk cache controllers. I am wondering if anyone has had any experience with this fix and if they are seeing any improvements in performance? the article is located here:


    Thanks in advance.

  2. bradmcgehee New Member

    Thanks for the heads-up on this, it was new to me. I'm sorry I can't offer any experience with it to share.

    Generally, turning off write-caching is recommended for SQL Server in order to enhance fault tolerance and recoverability, although you may suffer a performance hit doing so. I always turn off write-caching on my SQL Servers.

    Brad M. McGehee, MVP
  3. Argyle New Member

    On a clean Windows 2000 cluster with SP3 we had to install the fix you mention (Q332023) to get rid of "Lost Delayed-Write Data" errors. We did not install it for performance reasons. This was on Compaq servers and a MA8000 storage with all latest compaq firmware/patches that was configured with redundant fiber hubs and secure path software.<br /><br />When it comes to dskcache.exe mentioned in the article we have both the write caching and the power protected options as disabled. This is as it should be when you have a shared storage that has it's own cache and battery backup (at least I was told).<br /><br />On a side note we had major issues with the hotfix Q814017. The cluster was unable to do a failover if one node lost power. I would advise against installing it even if you are recommended too <img src='/community/emoticons/emotion-5.gif' alt=';)' /><br /><br />/Argyle
  4. fullbrij New Member

    If you use the /3gb or /PAE switch, you can rum low on page table entries. Using the the /3gb switch reduces the number available, while using /PAE causes each PTE to consume twice as much memory. Watch the counter Free System Page Table Entries, and if it falls below 10,000, then set

    HKLMCCSControlSession ManagerMemory Management

    Systempages to 30000 or so.

    Insufficient PTEs can cause cache manage to perform excessive trimming from active processes, and lead to sluggish performance. Exhausting PTEs under heav IO loads [read SQL] can cause stop errors.

    John Fullbright

Share This Page