Let's get along
Download as PPTX, PDF0 likes158 views
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.
Let's get along
- 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