How Not to be a Cranky DBAMike’s Top Ten Rules for Managing a Production Environment
Mike Hillwig AKA The Cranky DBA SQL Server DBA Working with SQL Server since SQL 7
Mike Hillwig Senior DBA at hosting division of a financial software company Working as the lone SQL DBA in an army of Oracle DBAs Resume includes Acme Packet, Shawmut Design and Construction, Equitable Resources
Beware of the Blogs There is some amazing advice out there. But… Anybody can put bad advice on the internet Trust people you know I don’t trust people who say “ALWAYS” or “NEVER” Test everything in your own test environment first.
Don’t enable Auto Shrink. Ever. This is my only exception to “NEVER” advice You can’t control when it runs What you shrink will just grow again Fragments your indexes Instead: Use DBCC Shrinkfile and then rebuild your indexes
Triggers don’t’ send mail Does it need to be now, now, right this very moment, now? Connecting to an outside application is costly for performance If the mail server is down, users get ugly results. What happens if mail XPs get disabled? Instead, write to a queue table and have a SQL Agent job process the queue.
Developers Don’t Touch Production Developers like to “fix” problems. Changes must be tested before moving into production. Every environment needs a gatekeeper/traffic cop You ARE using source control, right?
Ask questions like an auditor “What would Sandra say?” What is our risk exposure? Are there any security concerns? Will this pose any compliance problems? Does this touch anything financial? Don’t be afraid to ask your auditor
Consistency is Key Versions Easier to Troubleshoot Configurations Easier to Remember What’s Where Maintenance Processes Leverage the SQL Agent MSX Server
Master the SQL Agent Easily automate manual tasks Run scripts regularly and have them alert you to conditions Severity alerts are your friend Use Multi-Server Administration
Use Instant File Initialization Prevents waiting for a file to grow Makes RESTOREs run faster Creating new databases is much faster
Plan for when things go bump in thenight And they do go bump in the night Have a regular troubleshooting script for databases and applications for your first-level support Give common errors and how to resolve them Tailor your alerts to indicate which items require immediate attention and which should be flagged for next-day resolution
Set Min and Max RAM Extremely important in virtual environments MIN allows you to be greedy MAX gives the OS breathing room
Your server is not a workstation Avoid Remote Desktop Don’t run SSMS directly from your server Instead: Run from a workstation RUNAS is your friend
Set your file growth increments Defy the defaults! Growth is an ALTER, which is a database lock, which is a performance issue More growths = fragmentation Log growths = high VLFs Better yet, monitor regularly and grow files manually
Test restores. Frequently. Easily automated The worst time to test a restore is when your production server fails It’s good practice for when something does fail Don’t forget to test recovering from long-term storage Test recovering to a specific point in time as well as key business processes
Reserved words are just that,reserved Reserved words as column names make writing queries harder [avoid this] If it turns blue in SSMS, try something else Common offenses: SECURITY STATUS IDENTITY
Limit access to SA and serviceaccount passwords Not everyone needs to connect as SA Why? Why? Why must anyone have it? More hands = less control Does the application really need to connect as SA? Don’t be afraid to fight with the vendor Avoid Mixed Authentication Mode where possible Embrace AD authentication
Database servers are that and thatalone. Databases are the foundation of most critical business applications If the database server is slow, everything else is slow Web servers, SSRS, SSAS, and SSIS go on a different box Keeps server optimized for running databases It’s okay to be greedy with system resources