1. Top 10 DBA Mistakes on SQL Server

2. The One Platform for Physical, Virtual, and Cloud Performance.
SentryOne™ empowers Microsoft data professionals to monitor, diagnose, and optimize performance across physical, virtual, and cloud resources. The SentryOne platform delivers seamless integration for all of our solutions, enabling users to determine the true cause of performance issues, and reduce consumption and infrastructure costs.

3. The One Platform for Physical, Virtual, and Cloud Performance.
Free Resources
The One Platform for Physical, Virtual, and Cloud Performance.
Free e-books
In these books, you will find useful, hand-picked articles that will help give insight into some of your most vexing performance problems. These articles were written by several of the SQL Server industry's leading experts, including Aaron Bertrand, Paul White, Paul Randal, Jonathan Kehayias, Erin Stellato, Glenn Berry, and Joe Sack.
Websites SQLPerformance.com provides innovative and practical solutions for improving SQL Server performance. Answers.SQLPerformance.com is a question and answers site where you can upload query plans directly from Plan Explorer and have questions answered from execution plan analysis expert Paul White, among others. SQLSentry.TV offers an inside look into the world of SentryOne with videos on query tuning and product demos. Blogs.SentryOne.com is where you can find all of our team members’ blogs as well as important information about the latest updates to SentryOne software, SQL Server and server performance issues.

4. Kevin Kline Technical Evangelist for SentryOne Your Presenter
Microsoft Data Platform MVP
Contact Info
Twitter
Blog :
LinkedIn :

5. Other Top SQL Server Mistakes
Excludes SQL Server mistakes that are primarily development or design in nature:
Inadequate normalization and database design
Unknown scalability requirements
No baselines or benchmarks
Indexing issues
Query tuning ignorance

6. 10. Storage – Thinking space but not performance
Frequently think about disk subsystems only in terms of disk space, not IO load.
Without this knowledge, the following problems occur:
Inadequate fault tolerance
Insufficient IO:
OLTP requires high transactions/sec
OLAP requires high MB transfers/sec
Poor choice of RAID type, controllers, channels
Not enough disk spindles
SSD is a game changer for IO!

7. What is checkpoint? Lazywriter?
9. Business Ignorance
As the IT professional, you should know how SQL Server works at an “internals” level.
What is checkpoint? Lazywriter?
How is TempDB used? What’s in the plan cache?
The DBA is the guardian of the corporate data assets.
As the liaison between business and IT, you should know how and in what ways your servers are used.
Who cares if this app is down? How much does the downtime cost the company?
What are the business cycles?
When are the best downtimes?
Baseline? Benchmarks? What is normal?
For more tech info:
SQLPASS.org
SQLPerformance.com

8. Bonus Blunder: Not Asking
…for help:
Forums vs Support: know the value
#sqlhelp and Twitter

9. 8. No Troubleshooting Methodology
When the chips are down, the DBA needs a strong, step-by-step methodology for root-cause analysis. Without one, you get:
Missed errors and problems
Errors resulting data loss and catastrophic failure
Poor response times and breached SLAs
Lost credibility
Don’t have a methodology? Check out End-to-End Troubleshooting on:
SQL Server Troubleshooting Guide by J. Kehayias on:
Mention the book “Checklist Manifesto”, site examples like nurses routines on checklist reducing 47% errors when medicating patients.
Where to start
How to use the native troubleshooting tools:
Error logs & automated error notification
SQL Profiler and server-side traces
PerfMon
Query plans

10. Bonus Blunder: Reactive not proactive
In the SQL Server Management Studio, select the Instance >> SQL Server Agent >> Alerts >> Rt-click New Alert >> Type in an alert name >> Select the Severity Radio Button >> Choose the appropriate severity level from the drop-down list.
Note that you can also create performance alerts, such as “alert me when buffer cache hit ratio drops below 80%”. However, you have to know what PerfMon counter and what value of that counter you want SQL Server Agent to watch for.
Once you’ve created the alert, you then want to set the response. Typically, your response will be to a first responder, such as the DBA, though you could also execute a T-SQL job.

11. 7. Going with the defaults
SQL Server installation defaults are intended to get the server up and running, but not running optimally:
Auto-grow and Auto-shrink on databases
Auto sizing of auto-growing databases
Default filegroups
Minor issues can become major issues:
MAXDOP
FILLFACTOR
Many server- and database-level configuration settings

12. 6. Security as an afterthought
SQL Injection is the #1 hack on the internet today.
Remarkably, we knew as much about preventing SQL Injection ten years ago as we do today.
Plan ahead of time to minimize issues:
Ensure the least privileges principle for applications running on your servers
How much surface area do your servers expose?
Who has access to your servers?
How do you find out the who, what, and when of a breach?
See my session Understanding & Preventing SQL Injection at

13. 5. Inadequate Automation
Automation is the means by which DBAs work “smarter” instead of “harder”. Ironically, it takes a lot of work at the outset to automate.
Without automation, DBAs must deal with:
Manual processes prone to error, omission, and forgetfulness
Inability to scale environment to multiple servers
Time constraints from fire-fighter and script-pusher modes
Examples of working smarter instead of harder:
Automated error notification
Scheduled jobs
Lots of scripts, not too much GUI
Automation made easy with PowerShell and/or WMI:
PowerGUI
Scriptomatic

14. 4. Wrong feature or technique for the job
DBA’s are the “performance engineer” for their corporation’s IT applications. It’s imperative that the most appropriate feature be applied to each business requirement. Otherwise: Brittle applications Applications complexity Excess resource consumption “Ooooh! Shiny!” Design reflects the current “fad” Axiom: There are no IT projects. There are business projects solved using IT.

15. 3. Apathy about change management
Change management is important! Without it, DBAs face:
Changes that leave things worse than they started
Piecemeal rollbacks that cripple applications
Inconsistent support across applications and servers
Change control versus Change management?
Proper change management means:
Key stakeholders have a say in Go-NoGo (CM board)
Performed at pre-planned times and within a defined time limit
Change is tested and verified to have no effect or positive effect on production environment
Changes are isolated, atomic, and reversible

16. 2. Inadequate Preventative Maintenance
Proper preventative maintenance (PM) helps you:
Catch issue before they become problems
Ensure optimal performance
Perform resource intensive operations with few, if any, users on the system
PM on SQL Server should include:
Database consistency checks (DBCC) and CHECKIDENT
Backups with verification followed by restore checks
Defragmentation, Fill factor, Pad Index
Index and Statistic maintenance
Full app recovery (logins in Master, jobs in MSDB, repl, etc)

17. Bonus Blunder: Reinventing the wheel
Most preventative maintenance tasks have already been written and vetted by others.
Check out:
Ola.hallengren.com

18. 1. Backups <> Recovery
DBAs often don’t test backups or recoveries as they should. Causes lots of problems:
Can you meet your SLA? RTO? RPO?
Not certain that backups are good: verified and available?
Where’s all the data, files, DLLs, etc for recovery?
Got all of the databases that are needed?
Haven’t tested a full, ground-up restore:
What if you have to reinstall everything?
One of the great things about VM recovery!
The importance of recovery: the Lost Job scenario
Can you actually restore older, archived data?
It’s
All About
The Data, All
The Time, Every Time

19. 2. Most DBA blunders are due to process and business issues:
Summary
Let’s connect!
Facebook, LinkedIn, Twitter at KEKLINE. at
More slides at
More videos at
1. Only a few big DBA blunders are due to tech skills:
Disks as space, not IO
No troubleshooting methodology
Going with the defaults
2. Most DBA blunders are due to process and business issues:
Security as an afterthought
Wrong features
Change management
Preventative maint & automation
Backups <> Recovery