A key principle in  Judo is  to  use  opponents strength  against them . Don’t rely just on brute force (although that can be useful!). We used to spend hours developing a feel for the tipping point, and quite often you could throw an opponent who was much bigger.

What’s the moral of the story? Make the most of the equipment you’ve got. In these days of commodity hardware and write-once run everywhere software development methods – it is easy  to just purchase more processing power and throw more memory at a problem.   This can lead to some poorly written code deployed onto production servers.

Yesterday I found a query using multiple processors to execute a single query in parallel. I spoke to the SQL Developer and he started telling how this query was incredible and could exploit all the processors. I looked at him for awhile – and mentioned there are other services using these processors and when his “incredible” query was running it was causing severe queuing!

These examples ( and many more) highlight the importance of sizing the database server system. Monitor all the workloads requesting resource and make the request for processors,memory etc. Don’t just check a few queries hoping everything will be fine on the night

Memory is also a valuable resource. If code is deployed , and is competing with every other request for all available memory –  you’ve got a problem. Designing systems from the outset with memory in mind can lead to a stress-free existence (not completely , but at least enough to allow some sleep)

As the DBA – the job is all about exploiting the resources available and only when you can prove the need for resource than speak to procurement.

Read More

SQL Server Storage and IO performance - SQL Server DBA

RAID server configuration and disk amounts - SQL Server DBA

Correctness and stress test