The document discusses some of the common tensions that exist between database administrators (DBAs) and developers, and provides guidance on how the two groups can work together more effectively as part of the same team. It outlines key responsibilities of DBAs related to security, availability, integrity, recoverability and performance of the database. It also provides tips for developers on interacting with DBAs during planning, design, development, deployment and ongoing support to help ensure projects run smoothly.

1. …and be a happy team
DBA & dev’s, let’s get along

2. • Constant struggle
• Immediacy vs Security
• Urgency vs Availability
For whatever reason one constant has always been the conflict
between DBA's and developers. It may not be as open a conflict in
every place, but there is always an undeniable tension between the
two groups. Following some simple guidelines can bring everyone
together for a more pleasant work experience.
Lets check on how you can keep your DBA's happy, work all together
as a team and therefore, keep the business running smoothly.
Why are we talking about this?
This doesn’t help me learn SQL Server; does it?

3. DBA BEFOREOMG!!! OH! NO again and NO once again!

4. DBA AFTER

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

6. • we’re on the same team
• It’s all about the data
• he can help tuning your tsql code
• he can turn down code
changes/releases if it affects
production (Security! Availability!)
Why does the DBA matter?
Do you even have to ask?

7. • It can do anything
• It can house any data
• ….BUT…
Interaction
When do (should) developers and DBAs come together?
MS SQL Server is a multi-purpose, multi-database RDMS
That doesn't mean that the defaults for EVERYTHING are
good for EVERYONE and EVERY database

8. • Planning
• Design
• Development
• Deployment
• Support
Interaction
When do (should) developers and DBAs come together?

9. • 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.

10. • Optimal database construction
• Keys and indexes
• Performance pitfalls
• Things you can’t possibly know
– systems interactions
– maintenance schedules
– process priority
Design
They can help!

11. • DBA’s can really 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

12. • 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?

13. 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

14. • Availability
– If you really want things to go as smoothly as possible,
be there to help things along, and communicate
– If you want the best, fastest resolution, be available to
help
• 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

15. • Back-out/Rollback scripts
– Along with the deployment script, provide
another script that will undo every single change
that the deployment script did (ROLLBACK script)
Hint: Providing your DBA with a rollback of a
deployment gone bad will imprint a fond memory of
you in their mind.
Deployment
Most development shops fall short here

16. • Trustworthiness
– Trying to hi-jack sysadmin rights is bad
– Sliding undocumented changes into
deployment scripts, also bad
Support
An ongoing commitment

17. Support
An Ongoing Commitment
• Do not deflect into databases
– Auto-blaming the database server for poor
performance doesn’t help anyone (and usually are
not the guilty ones ;)
• 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??!!

18. Support
An Ongoing Commitment
• BEGIN TRAN..COMMIT/ROLLBACK TRAN
– When troubleshooting code wrap UPDATES / DELETE
statements in a transaction, and always rollback.
• Take care when troubleshooting
– Poorly written test queries run in SSMS can add to the
problem

19. Support
An Ongoing Commitment
tSQL tuning/optimization is a wide subject.
• lot of information/recommendations but take
those recommendations with a grain of salt
• Each environment/workload is different
• before jumping to code and applying that brand
new amazing optimization technique be sure
you have tested and really tested it on a pre-
production or staging environment

20. 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”.
– Check this article by Grant Fritchey on Execution Plan Basics
http://www.simple-talk.com/sql/performance/execution-plan-basics/
– 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.
http://www.sqlsentry.net/plan-explorer/sql-server-query-view.asp

21. Support
An ongoing commitment
Execution plans screen captures (comparison)

22. Quiz time!
1. When I’ve a hard problem: One point for each
2. When someone has a complaint…
1. 0 pts
2. 0 pts
3. 0 pts
4. 5 pts
3. Being woken at 4am
1. 0 pts
2. 5 pts
3. 5 pts
4. A DBA job might kill you, zero points
4. After you fix something…
1. 0 pts
2. 5 pts
3. 5 pts
4. DBA are too sarcastic to celebrate, 0 pts
5. You must write a troubleshooting guide
1. 5 pts
2. 0 pts
6. Have you ever done any of these?
• One point for each
7. There’s a new dev project
1. 0 pts
2. 5 pts
3. 5 pts
8. A server is repeatedly crashing
1. 0 pts
2. 0 pts
3. 5 pts
4. 0 pts

23. Quiz time!
Scoring your quiz:
0 – 25: sql might not be the right path for you
26 – 39: pretty darn good fit for a heavily
oriented sql related job
40: what are you doing here? You’re a DBA ;)

24. References:
• Jason Hall: jhall@sqlsentry.net
• jasonhall.blogs.sqlsentry.net
• http://goo.gl/u6YO9f
• Kendra Little: Should you be a SQL Server DBA?
http://goo.gl/ggIXVg
• Brent Ozar: Watch Brent Tune Servers
http://goo.gl/bR06vL
• Aaron Bertrand’s series: Bad habits to kick