How not to be a cranky dba

How Not to be a Cranky DBA
Tips for Bringing Sanity to Your SQL Server Environment

Mike Hillwig
 AKA The Cranky DBA

 SQL Server DBA

 Working with SQL Server since SQL 7

 Contract 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

Mike Hillwig
 Avid Cook

 Lover of Blue Cheese

 And Bacon

 Geek at Heart

 Owned by Two Pugs

Obligatory Social Networking Slide
 crankydba.com

 sqlserverpedia.com

 twitter.com/mikehillwig

 SQL Saturday Waltham – 5/19/2012

 SQL Saturday Providence – 9/15/12

 SQL Saturday Nashua – 10/20/12

 Call for speakers in Providence and
Nashua still open

No Need for Notes
Blog post and slide deck will be available later tonight

What Makes a DBA Cranky
 Fixing Unnecessary Mistakes

 Lack of Sleep

 Answering Redundant Questions

 Repeating Manual Processes

 Performance Problems

 Waiting

 Unnecessary Emergencies

We Would Rather
 Spend time with our
families

 Read

 Sleep

 Play Angry Birds

 Eat Bacon

 Anything other than work

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

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 the
night

 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 service
account 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 that
alone.

 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

More
Blog Post at crankydba.com/go/nesql

How not to be a cranky dba

More Related Content

What's hot (9)

Similar to How not to be a cranky dba (20)

More from Mike Hillwig (9)

Recently uploaded (20)

How not to be a cranky dba

Editor's Notes