Why Your DBA Wishes You Harm
Download as PPTX, PDF0 likes339 views
This document provides advice for developers on how to have a good working relationship with their database administrator (DBA). It emphasizes that uptime, performance, and process are most important to a DBA. The DBA can help with tasks like performance tuning, testing environments, and code reviews to ensure quality and avoid issues. Developers should follow best practices, document their work, and see the DBA as being on the same team rather than as a judge.
Why Your DBA Wishes You Harm
- 1. Why Your DBA Wishes You Harm Or How to Get Along With Your DBA Mike L Gardner @DataProMike
- 2. Mike Gardner Data Architect/DBA Sybase/SAP (ASE, HANA, IQ) SQL Server and a little bit of Oracle and MySQL
- 3. What’s Important to a DBA Uptime Performance Process Consistency Predictability
- 4. Uptime is THE Most Critical Component Part of DBA’s performance metrics DBA’s get the call/blame when problems occur Untested code or under-tested code is a threat to uptime
- 5. Performance matters - just not how you think Your code doesn’t have to be great, good is fine Avoiding bad code is better than writing great code Do some performance testing on your code
- 6. Process - The DBA Security Blanket Document your code Follow a consistent release cycle Use source control Have Patience
- 7. How the DBA will Help You Sizing and Scalability Configuration and Architecture Test/Dev or QA environments Testing Environment Don’t have one - enlist the DBA to make your case
- 8. Performance Index Tuning Covering Indexes Highlight columns used in queries to save some work for the DBA Query Tuning Execution Plans Database Tuning
- 9. Process Documentation Code Reviews / Diagram Reviews DBA may be able to offer hints and insight Gives DBA a share of ownership in the code
- 10. Code Review - Is the DBA Judging Me? YES! The DBA’s primary thought is ‘Will this code cause problems for me?’
- 11. Things to Avoid Select (*) or count(*) (NOLOCK) WHERE 1=1 select ... from ( select ... from ( select ... from… ORDER BY (Every column in the statement)
- 12. Things to avoid (cont) DECLARE CURSOR Implicit Conversions / Inappropriate Data Types Asking for Admin Changing column order between releases BLAME
- 13. Same Team: Same Fight DBA’s and Developers have aligned interests Take care of each other
Editor's Notes
- #7: DBA’s prefer slow and predictable change. They are much more attuned to the impact of downtime, so be patient.
- #8: They understand the load that users will create Dashboards to keep people from pestering them with questions DBA can be a strong voice to support test and development environments
- #12: select * or select count(*) --Developer is being lazy, or sloppy (NOLOCK) -- Attempt to increase performance, but points to potential issues in query - duct tape WHERE 1=1 -- Looks like test code that was forgotten ORDER BY (complete result set) -- 2 - 3 columns max - can be expensive
- #13: Too many nested select statements -- Probably could be represented more efficiently DECLARE CURSOR -- Shows row based thinking, as opposed to set based which is more efficient Implicit Coversions and Inappropriate data types -- Make sure you are using the right data type in your table - best fit Asking for Administrative privileges on production -- Don’t take it personal, remember who will be called in during off hours should a problem occur BUT… Changing column order between releases -- ESPECIALLY if you are doing any sort of data migration as a result Blame -- You are responsible for your code, even after it moves to production. Step up when your code is at fault, and the DBA will appreciate it and likely return the favor in the future -- If your application stops working, ensure you eliminate other possibilities (network, application server) before blaming the DBA.