SQL Server Performance Forum – Threads Archive

Note for those running SQL Server 2000 64-bit

I don’t know how many folks around here are running 64-bit, but if you are you’ll know that there are quite a few builds over the standard install. Last I saw was around .1007! There are some serious fixes in these builds (buffer latch issues, dynamic procedure cache ‘leak’, checkpoint problem, etc) that need to be applied for 64-bit users. Many of these fixes were done post-SP4, so some of this functionality will have to be RE-APPLIED when SP4 is installed. For that reason, you might not want to jump on SP4 too quickly… Just an FYI for the 64-bit folks! Adam —————–
Adam Hicks
Windows Datacenter Certified Professional
Unisys Corporation
Dallas, TX

Thanks Adam Thats a ton of information for 64-bit world, I appreciate your feedback.
At our end we have only one system running with 64-bit SQL Server and I was never involved in that service, so very limited opportunity to comment on issues. Satya SKJ
Moderator
http://www.SQL-Server-Performance.Com/forum
This posting is provided â€œAS ISâ€ with no rights for the sake of knowledge sharing.

i have been trying to get various post 970 builds from MS (for both 32-bit & 64-bit), but they insist on reporting the specific problem.
so each of my customers are on different post-sp3 builds, making it very hard to correlate problems fixed and anomalous behavior to a specific build i think a serious performance problem was fixed somewhere around build 972,
i would like to take the opportunity to confirm this per your previous post

I can’t speak for all the issues fixed ~972, but I can say there was a pretty serious checkpoint issue fixed in that build… we basically saw all threads halt upon checkpoint operations in the earlier builds… this was causing some serious CPU and disk queuing in two of my customer environments. After 972 this was resolved. I will try to obtain a public readable copy of different issues fixed in the various levels. I just implemented .1001 and .1007 and two different customers sucessfully. Note that if the customer is using dynamic procedure cache, they’ll need something past .1000 to fix a memory leak that will occur regardless of whether or not you’re pinning memory for SQL or using auto. It will basically suck every last bit of memory eventually causing the system to become unresponsive/unstable. Adam —————–
Adam Hicks
Windows Datacenter Certified Professional
Unisys Corporation
Dallas, TX

Thanks for the updates Adam. [<img src=’/community/emoticons/emotion-1.gif’ alt=’

‘ />] It’s nice to see someone on here with some good 64-bit experience. MeanOldDBA [email protected] When life gives you a lemon, fire the DBA.

]]>