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

Our Sponsors

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 www.SQLMasterAcademy.com

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

demo

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!!

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

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

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

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.

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

7. Keeping default settings for parallel executions Max Degree of Parallelism Reduce MaxDOP to allow increase concurrency and throughput of executions - http://support.microsoft.com/kb/2806535 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

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!

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

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 !!!

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)

demo

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’

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)

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

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

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 2012 - http://support.microsoft.com/kb/2663912 24

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

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: Magi.Naumova@SQLMasterAcademy.com www.maginaumova.com www.SQLMasterAcademy.com

Thank You!