A guide for SQL Server Developers Jason Hall-SQL Sentry, Dir of Client Services Blog-jasonhall.blogs.sqlsentry.net Recipe for a Happy DBA

Constant Struggle In my career, I have been on both sides of the database. Both behind it, and in front of it. One constant has always been the conflict between DBAs and developers. It may not be as open a conflict in every place, but there is always an undeniable tension between the two groups. I believe that following some simple guidelines can bring everyone together for a more pleasant work experience. Why are We Talking About This? This doesn’t help me learn SQL Server; does it?

DBA BEFORE OMG!!! OH NOZ!!!11

DBA AFTER Hakuna Matata!

Recoverability Integrity Security Availability Performance Development Support What is a DBA? A person who is responsible for the environmental aspects of a database

We’re on the same team It’s all about the data One day you will need a favor… Without this person, your code is not getting deployed Why does the DBA Matter? Do you even have to ask?

Planning Design Development Deployment Support Interaction When Do (Should) Developers and DBAs Come Together?

To prepare for increased capacity To conduct proper time management To assess hardware and licensing needs To address budgetary issues Planning They Need to Know The earlier you can let the DBAs know that you are planning something the better. Those responsible for the vital subject matter of any project should never be an after- thought during planning.

Optimal Database Construction Keys and Indexes Performance Pitfalls Example: The “all keys” table Things you can’t possibly know Other systems Maintenance schedules Process priority Design They Can Help!

The DBA Can Help They know performance implications of using different methods They can suggest new features that you may not know of Writing TSQL *is* Development Treat it as you would any other code Tune for performance now, not after deployment (when it’s causing problems). Development Probably What Most of You are Waiting for

Avoid Bad SQL Habits See Aaron Bertrand’s Series: ( ) Read SQL Server Related Blogs Doug BurnsDoug Burns: What use is a Development DBA?What use is a Development DBA? Development Don’t Forget Your Part!

Formatting (or rather not formatting) This alone can move you up on the DBA happy list Use of Poor Aliases Initials, generic letters etc. Use of Meaningless Variable Names For your own benefit, and the DBAs Bad Habits There Had to be Something Technical in this Talk, Right?

Being Case Insensitive No reason not to develop on a CS database SELECT * Readability You don’t always need *everything* Causes Lookups! Using a query designer Keep scripting skills sharp Generates unformatted, messy, chatty code Lots of Cursors and/or RBAR Bad Habits There Had to be Something Technical in this Talk, Right?

Bad Habits There Had to be Something Technical in this Talk, Right? Examples & Comparisons

Availability If you really want things to go as smoothly as possible, be there to help things along, and communicate Script Construction DBAs like to know what is going onto the servers. Provide well documented, well formatted, readable scripts Deployment Most Development Shops Fall Short Here

Back-out Scripts Along with the deployment script, provide another script that will undo every single change that the deployment script did. Providing your DBA with a way out of a deployment gone bad will imprint a fond memory of you in their mind. Deployment Most Development Shops Fall Short Here

Availability Again, if you want the best, fastest resolution, be available to help Trustworthiness Trying to hi-jack sysadmin rights is bad (mmmkay…) Sliding undocumented changes into deployment scripts, also bad Support An Ongoing Commitment

Do Not Deflect Onto Your DBA Auto-blaming the database server for poor performance doesn’t help anyone Reasonable Expectations You can’t restore my 500GB database in 5 minutes? Why? You can’t add change the clustered index to my 40 million row table at 10AM on Monday? What??!!11 Support An Ongoing Commitment

BEGIN TRAN/ROLLBACK TRAN When running troubleshooting code in SSMS or another tool, wrap any update or delete statements in a transaction, and always rollback. You can now test all you like, and change it to commit when you are sure Take Care When Troubleshooting Poorly written test queries run in SSMS can add to the problem Support An Ongoing Commitment

QUERY EXECUTION PLANS Learn how to translate (at least) the more important operations to look for a query execution plans. Not in every case, but in general, some words that should get your attention are “scan”, “sort”, “lookup”. I recommend a great article by Grant Fritchey on Execution Plan Basics I also recommend using the 100% free tool from SQL Sentry called Plan Explorer. It’s going to save you a lot of time over the plan features in SSMS, especially once you are tuning a lot of larger queries. Support An Ongoing Commitment

Plan Explorer A Shameless Plug

Alternative Method Everyone Loves Cookies!

A guide for SQL Server Developers Jason Hall-SQL Sentry, Dir of Client Services Blog-jasonhall.blogs.sqlsentry.net Recipe for a Happy DBA