SQL Server Advice: Unexplained

Sometimes you should just take my word for it:

– Put data and log files on different disks, yes even in a SAN

– Limit SQL Server memory, leave at least 2 GB to the OS. Yes, even if SQL Server is the only thing you run on the server

– Virtualize, it’s good

– Use full recovery model unless you can explain why you should not

– Remember to backup both data and log

– If you don’t test your backups, you don’t have backups

– Learn more about SQL Server licensing, because you’r worth it

– Don’t give out more permissions than strictly needed to users and applications

– Consolidate or get ruined

– For performance, choose Enterprise Edition

– Express Edition is more useful than you think, and free

– Check you databases for inconsistencies and fragmentation regularly

– There is a better way of writing your favorite query

– One size does not fit all, and sometimes one size does’nt even fit one

– Good enough is good enough

– Your application vendor is not a database authority, even if its name is Microsoft

– Select permissions to one table for the wrong app or user can be enough to overload your server

– Never put anything else than SQL Server on a SQL Server server.

– Buy more memory, sell a CPU

– If a query runs slower than it takes you to look up the answer in a book, something’s wrong

– The coolest technical solution is not always the best, simple is good

– If your users come to you and tell you that the database is slow, you should already know

– The next version is better, but maybe not for you

– The old version you are running, upgrade it now

– Restarting your server is not a solution to a database problem

– If in doubt, ask

– Remember that end users just want the database to work, don’t bore them with technical details

– Cursors are evil, really

– FAST(1) means SLOW(N-1)

– There are 3 kinds of lies: Lies, Damn Lies and Statistics

– The errorlog should be checked for non-errors

– If you ALTER stuff in SSMS, script it out to see what it ACTUALLY does

– There is a reason why some people test their T-SQL before it goes in to production, and it is NOT that they write the worst code

– Review your Indexes more often

– Run a supported version of SQL Server

– If a job fails, you want to know

– Dynamic T-SQL isn’t all that dynamic

– Today’s fast is tomorrow’s slow, keep watching that performance

– There are many features in SQL Server that you have paid for, but you don’t even know they exist

– Know your DMV’s

– C: is a bad place for databases