1. Top 10 DBA mistakes that affect the SQL Server performance
Margarita Naumova

2. Our Sponsors

3. Magi Naumova www.SQLMasterAcademy.com
Working with SQL Server from v6.5
MCT from 1998
SQL Server Trainer and Consultant for more than 15 years, having more over 100 projects in Bulgaria, Finland, Germany, UK, Greece..
5 years Senior Consultant in Microsoft
Microsoft Certified Master SQL Server 2008
MVP SQL Server
SolidQ Mentor & Trainer
Now I am running SQL Master Academy training program

4. 10. Playing with tempting settings db_level
Auto-Close
Queries can time out, significant delays occurs
Typically the ON state is coming from SQL Server Express
Should be OFF!
Auto-Shrink
Leads to significant I/Os on a periodic basis
Leads to high amount of logging
Leads to huge fragmentation of clustered indexes

5. demo

6. 9. Playing with tempting settings SQL Server Level
Priority Boost
IO AFFINITY
MAX Worker Threads
Lightweight Pooling (Fiber Mode)
All of them could potentially be harmful
Should be left with their defaults!!

7. 9. Playing with tempting settings
Priority Boost
Deprecated
Dangerous for non-SQL Server threads
could lead to hanging and unresponsive processes incl false failovers,
network connection problems
Should be OFF

8. 9. Playing with tempting settings
IO AFFINITY
Sounds “great” to optimize the I/O, probably licensing or just make it faster
Actually setting it leads to high increasing of context switching and consuming significant amount of CPU resources
Should NOT be configured in vast majority of instances especially on 64bit

9. 9. Playing with tempting settings
Max Worker Threads
Sounds like giving more speed
Sometimes in response to weird error messages
But actually the problems get worse
Instead of playing with Max worker threads better do
Monitor THREADPOOL waits
Blocking
Connection pooling

10. 10. Playing with tempting settings
Lightweight Pooling (Fiber Mode)
Changes the way workers interact with Windows – fibers instead of threads
As a result some features could not work or they may behave erratically, especially when the system is under load (CLR, XP, SQLXML , SQLMail, replication, etc)
High Context switches can occur
Rarely enhances performance or scalability on the typical system
Do not use!

11. 8. Not Optimizing for AdHoc
Plan cache fills up with single use plans each of which 16K as a min
Can cause internal memory pressure as memory is taken from data cache
Usually CMEMTHREAD wait type occurs
Optimize for AdHoc server level setting
Only plan stub is saved (300B)
Should be enabled by default on every Instance

12. 7. Keeping default settings for parallel executions
Max Degree of Parallelism
The max number of threads to use in a branch of a parallel plan
Lots of processes running parallel tasks can cause threat starvation
Performance is severely affected
If a DOP value of 4 is used, the number of estimated threads for executing this query is 4 * 2 = 8.

13. 7. Keeping default settings for parallel executions
Cost Threshold of Parallelism
The cost of a plan above which the QP goes with a parallel execution
Default setting is 5 which is too low
As a result lo of queries go above the default setting, with parallel plan
CXPACKET waits and thread starvations are most likely to occur especially in high concurrent OLTP or mixed workload

14. 7. Keeping default settings for parallel executions
Max Degree of Parallelism
Reduce MaxDOP to allow increase concurrency and throughput of executions -
You can do it per query with OPTION hint
Cost threshold for parallelism
Fix the high used plans to reduce their cost
Raise cost threshold of parallelism from the default of 5
Tuning ‘cost threshold for parallelism’ from the Plan Cache, Jonathan Kehayias
Use sp_blitzcache by Brent Ozar

15. 6. Not configuring Instant File Initialization
Skip initializing files with zeros
As a result the following events performs faster
Large database files creation
Database file growth
Database Restores
Cons
Is not used for transaction log files
Could lead to exposing deleted files on disk
Instant File Initialization should be configured on every instance!

16. 5. Using default settings for files and growth
Database Initial Size – 3MB or 5MB (or the size of the model db, 10MB in 2012)
Database Growth - by 1MB! (or according to msdb settings, 8MB in 2012)
Leaving defaults leads to:
High amount of DB Growth events, which are too “expensive” to be accepted in production environment
Reducing Transactions/data loading performance
Fragmentation on database file (NTFS-level fragmentation)
It DOES affect performance of large scans

17. 4. Not configuring the log
Defaults: Initial size 2MB; growth: 10%
New VLFs are created depending on the Growth Size and the File Chunk rues
File Chunk
Number of VLFS
<64MB
4 VLFs
>=64MB and <1GB
8 VLFs
>=1GB
16 VLFs
Example: If the Tlog needs to grow from 1MB to 1GB:
With 1MB steps it needs 1024 steps*4VLFs each = 4096 VLFs !!!
With 512MB steps it needs 2 steps*8VLFs each = 16 VLFs !!!

18. 5. Not configuring the log
Excessive file auto‐growth causes:
Numerous VLFs to be added – this can negatively affect performance of the log
Synchronous slight pause on auto‐grow operation
New portions of the log are always zero initialized
Windows call to extend a file (may cause file fragmentation)

19. demo

20. 5. Using default settings for files and growth
Recommendations
Manually manage file sizes
Monitor auto‐growth for a limited period of time using Trace (Data File Auto Grow event class) or xEvents in order to know your pattern
Define proper settings. Always have file growth as a fixed amount, not a percentage
Manually growing files allows YOU to decide in advance which files to grow and how much
Auto‐grow should be left enabled ‘just in case’

21. 4. Not configuring the log
Recommendations
Configure the log initial size and growth
Monitor the log for a specific period of time in order to have its pattern and tune settings if needed.
Your goals:
To not allow Log fragmentation (keep VLFs<100)
To not allow dramatic file growths (keep stable log)
You are allowed to play with
Config settings (initial size)
Backup strategy (backup log frequency)
Maintenance strategy (change to bulk mode during the maintenance if appropriate)

22. 3. Keeping defaults on TempDB
Generally thee are 3 common problems with tempdb, all of them are result of misconfiguration
I/O bottleneck i.e. slow tempdb
DDL/allocation contention
Out of space problem
It is always better to configure in advance
Multiple files all with equal size
Enough size in order to avoid autogrowth
Fast drive
T1118

23. 2. Not configuring SQL Server Memory
MAX SERVER MEMORY should not be left default
The Buffer Pool size is calculated based on Target Memory
The Plan cache size and the size of cache stores are calculated based on Target Memory
In case of misconfiguration
External and Internal memory pressure events occur
It affects both Bpool and Plan caches

24. 2. Not configuring SQL Server Memory
There is no separate categorization "Multi-Page allocations"
Multi-Page allocations and CLR allocations are also included in memory limits
Memory configuration and sizing considerations in SQL Server 24

25. 1. No troubleshooting/PTO methodology
You have to have a baseline
Compare with the baseline on a regular basis
Check a list of configurations on multiple servers (PBM works perfectly in this case) and apply policy
Have a list of thinks and tools that you will check first

26. Summary
We manage to increase performance by 40% only by fixing some of those settings
Check your Instances and databases and fix those settings
Learn more at SQL Master Academy:

27. Thank You!