1. SQL Server Configuration Options and Trace Flag Secrets
Kevin Kline
SQL Sentry, Director of Engineering Services
@KEKline on Twitter, FB, LI
Blogs at and

2. Free swag FROM sql sentry!
Free Plan Explorer download:
Free query tuning consultations:
Free new ebook (regularly $10) to attendees. Send request me:
SQL Server educational videos, scripts, and slides:
Tuning blog:
Monthly eNews tips and tricks:

3. Agenda Quick Tips for Bare Metal and Windows Server OS
CPU
MEMORY
STORAGE
Special Tempdb Considerations
Settings Inside the Engine
High-end Testing with HammerDB
Trace Flags
Resources & Wrap up
Up to April 17, 2013:

4. Bare metal tuning - The Full StackDB
I/O Controller / HBA
Cabling
Array
Cache
Windows
CPU
PCI Bus
Spindle
SQL Serv.
Key Takeaway: Maximum performance is NOT going to be easy…
I/Os travel between CPUs/memory and disk media through a chain of I/O components, forming a path or multiple paths.
Not just a LUN or a drive letter.
Each component may have its own cache.
Each component may manage its own queue.

5. Why ‘Bare Metal’ Tuning?
‘Throwing more money/hardware at the problem’ has its limitations.
Different workloads require different hardware configurations.
Large number of performance problems caused by ignorance of hardware design.
Segregation of job duties often precludes much learning about hardware.
Why teach this session? Not only the reasons listed here but also because I was constantly getting asked “I only have budget for either the fastest chip with a smaller cache or a slower chip with a bigger cache. Which should I choose?”

6. Non-IO Bottlenecks – Scaling Example
Interesting shape, what’s causing it?
Add a disk RAID
Add a controller
Backplane limit
110
140
140
Interesting Shape, what’s causing it?

7. CPU – Speed & Bandwidth CPU speed Multiple CPUs CPU cache
In general, expect a 6.5% increase in performance per 10% of added CPU speed.
Multiple CPUs
Each added CPU adds processing power on a declining curve, starting at about a 40% boost an declining curve to about an average 16% boost >= 8 cpus.
Keep in mind that many SQL Server operations are single-threaded and do not benefit from multiple cores
CPU cache
Best CPU reference material?
Glenn Berry at
Since SQL Server 2012 uses core-based licensing, you really want to get the most performance possible from each physical core that you buy a SQL Server core license for. Our testing lab didn’t facilitate any tests of memory bandwidth.
Hyperthreading
Hyperthreaded CPUs are about 33-50% as effective as a real CPU on a good multi-core CPU
Intel says 10-30% boost, our testing averaged 35% at 1000 user load and 46% at 500 user load. Hyperthreading - To put these gains into perspective, you'd need to increase the core frequency of the CPUs by greater than 1GHz to match these results using nonhyperthreading processors. We were not able to take this testing to the next logical level of testing using various values for the Max DOP setting.

8. CPU – Power Default Windows Server CPU power settings are _______.
Balanced power is _____________.
stupid
the [stupid] default
AMD CPUs
Intel E7 CPUs
From
Please also see an earlier article published in regards to per CPU thread performance and throughput performance, which can be found here: 
For extreme latency sensitive instances, change the default settings to the ‘High Performance’ mode. E.g. see: 
Some processors also offer the capability of ‘turbo’ frequencies that are above the nominal processor frequencies. However those are only chosen when there is enough power to spare. Or in other words, not all the logical processors would be in use to give the processor/socket enough headroom in power. With some processors, Windows Processor Clocking Control also can influence the choice of turbo frequency.
Windows Power Mode Management (PMM) has very detailed and very technical documentation of Windows Server 2008R2 PPM can be found here:

9. Memory More is better (usually) Default settings may hurt you:
Specify mix/max ram helps performance on systems dedicated to SQL Server because it can reduce paging
Parallelized queries consume more memory than non-parallel queries
Still seeing AWE in use in 64-bit environments
Windows OS setting Lock Pages in Memory Controversy and Access Check Cache (v2008 R2 and later)
Everything old is new again
Do you know the workload?
Is it as simple as more memory is better?
The AWE Enable switch doesn’t typically play well with other applications and it will attempt to consume all resources it is aware of.
Lock Pages in Memory is at
When database objects are accessed by Microsoft SQL Server, the access check is cached in an internal structure that is called the "access check result cache." In rare circumstances, you may experience performance issues if the access check result cache size is too large or too small. Access cache details are at Was called TokenAndPermUserStore cache store in SQL Server 2005 and required use of T4610 and T4618 to modify the caches for versions < 2005 SP2. For versions >= 2005 SP3, you could use T4621 to modify caches. But SQL2008 now has configuration settings under Access Cache options.

10. Max Server Memory
By default, SQL engine will __________ acquire all requested memory upon startup.
Remember to leave headroom when configuring Max Server Memory.
Memory settings applies only to ____________.
NOT
buffer cache
SEAS06 64-bit Solutions on SQL Server 2005

11. TEMPDB Usage Temporary objects, including table variables
Version Store counters
Certain features and operations utilize tempdb (it’s not just used by temporary objects from T-SQL)
Index rebuild with sort in tempdb and online index rebuild
Sevice Broker
RCSI
Internal transaction objects (hash tables)
Related DMVs
sys.dm_db_session_space_usage
sys.dm_db_task_space_usage, sys.dm_exec_requests

12. Special Considerations
Tempdb
Size appropriately!
Autogrown tempdb will reset after restart
Not a bad idea to segregate onto its own array. For example:
Set the size to fill most of the drive
Maybe overkill
Never need to autogrow
No performance disadvantage
Microsoft IT
200GB drive
180GB TempDB

13. Settings inside the Engine

14. Database and Server Configuration
Database Configuration – Autogrowth
Can impact performance and introduce fragmentation
Set fixed MB growth amounts
SQL Server can use Windows 2003 instant file initialization so large MB values are OK
If the service account isn’t a local admin you need to assign it the ‘Performance Volume Maintenance Tasks’ security policy
However, it doesn’t work for Transaction logs so be a bit more conservative
Autogrowth is a last resort, size your database appropriately

15. Reducing allocation contention on Disk
File Configuration
Reducing allocation contention on Disk
¼ to ½ data files per logical cpu
Maximum of 8
One set of allocation pages per file
All the files are equal size:
Proportional fill algorithm balances the load
Round-robin approach to inserted data
Data file improvement is considerable, while log file improvement is _______________.
counter-productive
KB Article for 1118 fix is

16. Database and Server Configuration
Tempdb / UserDB – Allocation contention
TEMPDB
PFS
PFS
64MB
SGAM
SGAM
4GB

17. Overview by Analogy

18. More Tips on Tuning Storage I/O
There’s no benefit in multiple T-log files, but there -IS- a benefit in having multiple data files
If using multiple data files, ensure that they’re all the same size and have the same autogrow settings.
Round-robin, proportional fill algorythm.
Ratio of CPU to database files.
Presize database files, especially the T-log
In SQL Server 2008 and later, data compression works wonders

19. File Space Allocation Proportional Fill in action Free Space File 1
2 GB
0 GB
Case #1:
- single file, fills up
- add another file. Most write I/O goes to new file, along with reads for new data
- add another file. Most write I/O goes to new file, along with reads for new data
Case #2:
- Multiple files, different sizes
- Fill at same rate %; more writes to large file then small one
Case #3:
- Multiple files, same sizes
4 GB

20. File Space Allocation Proportional Fill in action Free Space File 1
2 GB
0 GB
4 GB
Case #1:
- single file, fills up
- add another file. Most write I/O goes to new file, along with reads for new data
- add another file. Most write I/O goes to new file, along with reads for new data
Case #2:
- Multiple files, different sizes
- Fill at same rate %; more writes to large file then small one
Case #3:
- Multiple files, same sizes

21. The Transaction Log – Virtual Log Files (VLFs)8K
VLF(1) 8K 8K 8K 8K 8K
VLF(2)
VLF(3)
VLF(4)
VLF(5)
VLF(6)
LOGBUFFER
<=60K
X 128
When switching to new VLF – it has to be ”formatted” with 8K sync write
While this happens, transactions are blocked
Up to 128 Log Buffers per database
Spawned on demand, will not be released once spawned
Transactions will wait for LOGBUFFER even when no buffer is available
Note that the buffer counts vary by version of SQL Server. In 2008 and above, it is 127
chunks less than 64MB = 4 VLFs
chunks of 64MB and less than 1GB = 8 VLFs
chunks of 1GB and larger = 16 VLFs
Read more:

22. Numbers to Remember - Spindles
Traditional Spindle throughput
10K RPM – IOPs at ‘full stroke’
15K RPM – IOPs at ‘full stroke’
Can achieve 2x or more when ‘short stroking’ the disks (using less than 20% capacity of the physical spindle)
These are for random 8K I/O
Aggregate throughput when sequential access:
Between 90MB/sec and 125MB/sec for a single drive
If true sequential, any block size over 8K will give you these numbers
Depends on drive form factor, 3.5” drives slightly faster than 2.5”
Approximate latency: 3-5ms

23. Scaling of Spindle Count Short vs. Full Stroke
Each 8 disks exposes a single 900GB LUN
RAID Group capacity ~1.1TB
Test data set is fixed at 800GB
Single 800GB for single LUN (8 disks), two 400GB test files across two LUNs, etc…
Lower IOPs per physical disk when more capacity of the physical disks are used (longer seek times)

24. I/O Segregation Hierarchy
Transaction Logs
Most active/recent data onto separate file/ filegroup/ partition:
Indexes
Most active tables
Most recent data
TempDB (…in RAM?)
Boot & OS files, System databases & files
Pagefile
Greater than 10% boost
User database log file
Active data partitions
From 5% to 9% boost
Tempdb
Less than 5% boost
SQL Server executables
Windows executables
Pagefile.sys

25. Rules for Better storage Performance
Put logs and data on separate arrays and, if possible, on independent channels.
Pre-size your data and log files; Don’t rely on AUTOGROW.
Put SQL Server data devices on a non-boot disk.
RAID 1 and RAID10 are much better than RAID5.
Tune TEMPDB separately.
Create data files all the same size per database and in ratio to CPUs.
Add spindles for read speed, controllers for write speed, SSDs for ultimate speed.
Segregation … for the highly stressed database
Monitor, tune, repeat…
    Do not put SQL Server data devices on the boot disk
    Put logs on a RAID 1 on an independent SCSI channel
    Put data on a RAID 5 on an independent SCSI channel
    If read disk queuing is high on your data device (avg 2 or higher per spindle) put non-clustered indexes in a new filegroup on a RAID 5 on an independent SCSI channel
    If tempdb is stressed (consistent blocking in dbid 2 is one common indicator) and you cannot redesign to relieve the stress put tempdb on a RAID 1+0 on an independent SCSI channel and the tempdb log on yet another RAID 1+0 on an independent channel.   
    If your database holds highly sensitive data consider RAID 1+0 over RAID 5.
    Avoid unnecessary complexity (KISS).
With thanks to Bill Wunder and his article on the SIGs at the PASS website (

26. SSD - The Game CHANGER! Some big advantages: Some caveats:
Power consumption often around 20% of traditional drives
Random = Sequential (for reads)!
Extremely low latency on access
There are ”no moving, mechanical parts”
Some caveats:
All SSD devices are not create equal
Beware of non-disk related bottlenecks
Service processors, bandwidth between host/array, etc.

27. Disk I/O – How RAID types test?
Characteristic
7500 rpm SATA
15.000rpm SAS
SSD
NAND Flash
DDR
Seek Latency
8-10ms
3-4.5ms
70-90µs
15µs
Seq. Read Speeds 64KB ?
MB/sec
800MB/sec
3GB/sec
Ran. Read Speed 8KB
1-3 MB/sec
Seq. Write Speeds 64KB
25 MB/sec
>150MB/sec
Ran. Write at 8KB
100MB/sec
Peak Transfer Speed
130MB/sec
Max Size / Drive
1TB
300GB
512GB
N/A
Cost pr GB
Low
Medium
Medium-High
High / Very High
MTTF
1.4M hours
1M hours
2M hours
The commodity platform was RAID5
Extra spindles added 1.4% each over baseline.
RAID1 & RAID10 each provided about a 319% boost over baseline
Extra spindles added 5% each over baseline
SAN was nearly identical to RAID1/10
SAN was a multi-path 2 gigabit fabric
Transaction response times were nearly double (and had lower disk I/O queue lengths) than RAID 10
You can reach a point where adding more hardware doesn’t help because you have, in a sense, shifted your bottleneck some place else.
Newer dual path SANs and multi-path SANs really get rid of the a lot of latency on the I/O. Don’t forget that spindles = performance.
Local array controllers make a big difference, but a well-tuned SAN will outperform them (e.g. bigger caches, 2gb multipaths, etc…).
You add more disks in a stripe to increase read performance for large contiguous reads (fairly cheap).

28. DAS vs. SAN - Summary Feature SAN DAS Cost High
- but may be offset by better utilization
Low
- But may waste space
Flexibility
Virtualization allows online configuration changes
Better get it right the first time!
Skills required
Steep learning curve, can be complex
Simple and well understood
Additional Features
Snapshots
Storage Replication
Thin Provisioning
None
Performance
Contrary to popular belief, SAN is not a performance technology
High performance for small investment
Reliability
Very high reliability
Typically less reliable.
- May be offset by higher redundancy on RAID levels
Clustering Support
Yes No
(special implementations exist)

29. SQL Server View of storage
Tool
Monitors
Granularity
sys.dm_io_virtual_file_stats
Latency, Number of IO’s, Size, Total Bytes
Database files
sys.dm_os_wait_stats
PAGEIOLATCH, WRITELOG
SQL Server Instance level
(cumulative since last start – most useful to analyze deltas over time periods)
sys.dm_io_pending_io_requests
I/O’s currently “in-flight”.
Individual I/O’s occurring in real time.
(io_handle can be used to determine file)
sys.dm_exec_query_stats
Number of …
Reads (Logical Physical)
Number of writes
Query or Batch
sys.dm_db_index_usage_stats
Number of IO’s and type of access (seek, scan, lookup, write)
Index or Table
sys.dm_db_index_operational_stats
I/O latch wait time, row & page locks, page splits, etc.
Xevents
PAGEIOLATCH
Query and Database file

30. SP_Configure Red Herring Settings
Don’t Use These Unless Testing Proves Otherwise
Boost SQL Server Priority
Max Worker Threads
Lightweight Pooling
CPU Affinity
Locks
Query Wait
Query Cost Governor Limit
KB Article for 1118 fix is

31. SP_Configure Settings
Bottom-line Behavior
Min and Max SQL Server Memory and “Lock Pages in Memory”
Fill Factor at 70-80% for OLTP applications
Parallelism is not the boogyman:
No kneejerk reactions – thinking about disabling MaxDOP (set to 1)?
May prefer Cost Threshold for Parallelism, especially for OLTP applications
KB Article for 1118 fix is

32. Proving your hypothesis
High-end Testing
Proving your hypothesis

33. Tools Used to Test IO HammerDB
Microsoft tools: IOMeter.exe, SQLIOSim.exe, SQL Server 2012 Distributed Replay Utility
Quest Software Benchmark Factory
SQLIOStress (deprecated – use SQLIOSim)
Functional correctness
Simulates SQL Server I/O patterns
Microsoft
SQLIOStress and SQLIOSim validate the basic functionality of an I/O subsystem under stress. They attempt to simulate actual SQL Server I/O patterns and check results for correctness. These tools are commonly used by the Microsoft SQL Server support organization to isolate hardware-related corruption problems.
For the purposes of this discussion, SQLIO and IOMeter are the most appropriate tools. SQLIO is a fairly rudimentary tool that can be used to issue a particular type of I/O against one or many test files to measure I/Os per second (IOPs), throughput (MB/s), and latency.
IOMeter is a bit more sophisticated; it enables you to define combinations of I/O patterns, which can be issued concurrently against one or more test files. While this can be advantageous for certain test scenarios, remember that the purpose of testing as described in this white paper is to measure performance and confirm that a particular I/O subsystem is configured correctly. It is misleading to assume that using a tool such as IOMeter allows you to simulate SQL Server I/O patterns just because with it you can define combinations of I/O types. This topic is discussed later in this paper.
With the growing variety of storage solutions in today’s IT organizations, several items should be noted before continuing:
While the information provided in this white paper can be used to performance test any disk subsystem, much of it is directed toward higher end storage arrays (such as those with significant amounts of cache, processing power, and so on). Keep this in mind if you are using or testing a more traditional disk subsystem.
This paper focuses heavily on I/O subsystems with fiber channel connectivity. However, the same concepts can be applied to iSCSI or other traditional direct attach storage systems.

34. TPC-C workload

35. TPC-C schema and ratios

36. TPC-C Transactions Only five transactions:
New-order: receive a new order from a customer: 45%
Payment: update the customers balance to record a payment: 43%
Delivery: deliver orders asynchronously: 4%
Order-status: retrieve the status of customer’s most recent order: 4%
Stock-level: return the status of the warehouse’s inventory: 4%

37. Load generation with hammerdb
Highly efficient & high-performance for multicore processors
Configurable from menus or directly against config.xml
10% utilization on hammerdb can drive 100% CPU utilisation on system under test (SUT)
HammerDB uses ~10MB for the application and 2MB per virtual user, e.g. 64 virtual users use ~138M RAM
Virtual Users:
Enabling Virtual User Show Output increases test latency, but is a lot more informative
Recommendation is to set number of users on a exponential scale (e.g. 2, 4, 8, 16, 32 … n)

38. SUT Requirements Supported against SQL Server 2008 and later
CPU: to stress CPU on SUT, create TPCC database with 5 warehouses X logical cores of SUT
Storage: ~100MB per warehouse plus 50% for additional growth
For example, a SUT with 64 logical cores:
64 * 5 = 320 warehouses
( ) x 100MB = 48GB disk space

39. Demo Let’s play with HammerDB
Download at
Discussion forums and support at

40. Breaking and Bending the Rules
Trace Flags
Breaking and Bending the Rules

41. No legal action complaining if something goes wrong!
What are trace flags?
A trace flag is a directive used to “set specific server characteristics or to enable/disable a particular behaviour”
Enabled at different scopes {Global | Session} and contexts {Startup | Query}
Documentation sources: BOL, KB articles / Service Pack & Cumulative Update “readme”s, White papers, Blogs / user groups / “water cooler”
CAVEATS!
No legal action complaining if something goes wrong!

42. Using Trace flags in t-sql
DBCC { TRACEON | TRACEOFF | TRACESTATUS }
Use -1 to turn on trace flag globally
Within a query using OPTION (QUERYTRACE n)
-T startup flag
Sometime trace flags seem to do “nothing”
DBCC TRACEON (3604): Send output to console
DBCC TRACEON (3605): Send output to ERRORLOG

43. Other ways to set trace flags
Microsoft says that you should do it by modifying the registry
Use –T# separated by semi-colon (;)
SQL Server Configuration Manager
Registry Editor

44. Startup trace flags don’t always startup
Remember that not all trace flags can be enabled using DBCC TRACEON

45. Generally usable trace flags
The following set of trace flags represent trace flags that you might want to implement in a PROD environment
Change default behavior of the product:
Improved performance
Improved troubleshooting
Generally “documented” and “low risk”
Might want to consider enabling them on your “standard build”
No legal action complaining if something goes wrong!

46. TF’inG–A! Safe* in production
T610 speeds up high volume data loads by writing less information to the transaction log for minimally logged inserts into indexed tables.
T834 enables SQL Server, on 64-bit systems, to use large-page allocations for the buffer pool.
T835 enables “lock pages in memory” for Std Ed
-t610 Data Loading Performance Guide white paper at
-t834 Documented: KB920093

47. -T834
Allows SQL Server 2005 on 64-bit systems to use large-page allocations for the buffer pool.
May prevent the server from starting if memory is fragmented and if large pages cannot be allocated
Best suited for servers that are dedicated to SQL Server 2005
Improves performance by increasing the efficiency of the translation look-aside buffer (TLB) in the CPU
Page size varies depending on the hardware platform, from 2 MB to 16 MB.
Startup
Now automatic:
Enterprise / Developer Edition
Requires “Lock Pages in Memory”
>= 8GB RAM, also not recommended when columnstore indexes are in use

48. -T835
Enables “Lock Pages in Memory” support for SQL Server Standard Edition
Enables SQL Server to use AWE APIs for buffer pool allocation
Avoids potential performance issues due to trimming working set
Introduced in:
SQL Server 2005 Service pack 3 Cumulative Update 4
SQL Server 2008 Service Pack 1 Cumulative Update 2
Only applies to 64-bit architecture
Startup
Documented: KB970070

49. -T1118: Blessed by zeus
Tells SQL Server to allocate full extents to each tempdb objects, rather than mixed extents.
Less contention on internal structures such as SGAM pages
Story has improved in subsequent releases of SQL Server
So represents a “edge case”
Documented: KB328551, KB936185
Working with tempdb in SQL Server 2005 white paper
Scope: Global

50. TF’ing Deadlocks
T1204 writes information about deadlocks to the ERRORLOG in a “text format”. T1222 writes information about deadlocks to the ERRORLOG in a “XML format”
Resources
Types of locks
Command affected
Documented: BOL
Scope: Global

51. TF’inG UP LOCKs
T1200 returns locking information in real-time as your query executes
Use during development / testing phase
Great for learning how SQL Server implements locking
T1211 disables lock escalation based on memory pressure or number of locks. T1224 disables lock escalation until 40% of memory is used and then re-enables escalation
When enabled, MSSQL won’t escalate row or page locks to table locks.
T1211 takes precedence over T1224
Microsoft recommends using T1224
Trace flag 1211 prevents escalation in every case, even under memory pressure and may help avoid "out-of-locks" errors when many locks are being used.
Warning! Can generate excessive number of locks, can slow performance, even cause 1204 errors.
T Documented: BOL, Scope: Global | Session
Btw, SQL Server includes the ability to disable lock escalation per-table!! This is a fantastic step forward in concurrency management. Uses ALTER TABLE syntax to specify per-table lock escalation management. See background details on the trade offs:

52. TF’inG Parallelized operations
T2528 disables parallel checking of objects during DBCC CHECKDB, DBCC CHECKFILEGROUP and DBCC CHECKTABLE.
Typically leaves parallel DBCC checks enabled. DBCC operations can dynamically change their degree of parallelism.
T2562 perform the entire set of checks in a single ‘batch’ instead of multiple batches, and increase the efficient of per-thread calls to get a new list of pages to read.
T2549 treats each database file as if it’s on a separate physical drive for the purposes of driving read-ahead for DBCC CHECKDB
Alternatives:
MAXDOP option
Resource Governor
T2528 Documented: BOL , Scope: Global | Local
T2562, T2549  really only apply to DBCC CHECKDB when the WITH_PHYSICAL_ONLY option is used.

53. TF’inG data consistency
T806 enables DBCC audit checks to be performed on pages to test for logical consistency problems.
These checks try to detect when a read operation from a disk does not experience any errors but the read operation returns data that is not valid.
Pages will be audited every time that they are read from disk.
Since page auditing can affect performance, it should only be used in systems where data stability is in question.
Documented: KB841776
“SQL Server I/O Basics, Chapter 2” white paper

54. TF’inG up the Database FILES
T3004 returns more information about instant file initialization (IFI). Useful to see if SQL Server has been configured to take advantage of IFI correctly
T1117 tells SQL Server autogrow all files in a database at the same time
IFI = Instant File Initialization

55. TF’inG up the transaction log
T3422 enables log record auditing to troubleshoot log file corruption
Careful! It introduces overhead to each transaction log record write.
Similarly to trace flag 806, you would only use this to troubleshoot corruption problems
Documented:
“SQL Server I/O Basics, Chapter 2” white paper
There are two trace flags you can use to add some extra auditing – these are documented in the SQL Server 2005 version of the SQL Server IO whitepaper.
Trace flag 806 will cause ‘DBCC-style’ page auditing to be performed whenever a database page is read into the buffer pool. This is useful to catch cases where pages are being corrupted in memory and then written out to disk with a new page checksum. When they’re read back in the checksum will look correct, but the page is corrupt (because of the previous memory corruption). This page auditing goes someway to catching this – especially on non-Enterprise Edition systems that don’t have the ‘checksum sniffer’ I describe above.
Trace flag 3422 will cause auditing of transaction log records as they’re read (during transaction rollback or log recovery). This is useful because there is no equivalent to page checksums for transaction log records and so no way to detect whether log records are being corrupted.

56. TF’inG up CHECKPOInts
T3502 enables detailed tracking of CHECKPOINTs to the ERRORLOG
T3505 disables automatic checkpoints:
Setting trace flag 3505 may increase recovery time and can prevent log space reuse until the next checkpoint is issued.
Make sure to issue manual checkpoints on all read/write databases at appropriate time intervals
Microsoft recommends that you do not change the recovery interval because it may affect data safety and availability.
CHECKPOINT in tempdb does not flush dirty pages to disk.  Just so you know.

57. TF’inG up background processes
T661 disables the ghost record cleanup process.
T8020 disables working set monitoring
T2330 disables all index usage stats gathering
T2371 enables proportional automatic update statistics
T2389 and T2390 enables auto-quick-statistics update for ascending keys, whether known or unknown, respectively
With T2371 ( change the fixed rate of the 20% threshold for update statistics into a dynamic percentage rate. The higher the number of rows in a table, the lower the threshold will become to trigger an update of the statistics. For example, if the trace flag is activated it means an update statistics will be triggered on a table with 1 billion rows when 1 million changes occur. If the trace flag is not activated, then the same table with 1 billion records would need 200 million changes before an update statistics is triggered.
In a table with 10,000,000 or 50,000,000 rows, less than 1% or 0.5% of changes are needed to trigger a statistics update. Or a table with 100,000,000 rows requires only around 0.31% changes to trigger update statistics.
T2389 SQL Server begins to track the nature of columns via subsequent operations of updating statistics.  When the statistics are seen to increase three times the column is branded ascending.  If trace flag 2389 is set, and a column is branded ascending, and a covering index exists with the ascending column as the leading key, then the statistics will be updated automatically at query compile time.  A statement is compiled to find the highest value and a new step is added at the end of the existing histogram to model the recently added data.

58. TF’inG up the Ring BufferS
T818 enables the ring buffer for tracking the last 2,048 successful write operations, not including sort and workfile I/Os.
T8011 disables the ring buffer for Resource Monitor
T8012 disables the ring buffer for schedulers
T8018 disables exception ring buffer
T8019 disables stack collections for the exception ring buffer
Trace flag 8011: Disable the ring buffer for Resource Monitor
Trace flag 8011 disables the collection of additional diagnostic information for Resource Monitor. You can use the information in this ring buffer to diagnose out-of-memory conditions. Trace flag 8011 always applies across the server and has global scope. You can turn on trace flag 8011 at startup or in a user session.Trace flag 8012: Disable the ring buffer for schedulers
SQL Server records an event in the schedule ring buffer every time that one of the following events occurs:A scheduler switches context to another worker.
A worker is suspended.
A worker is resumed.
A worker enters the preemptive mode or the non-preemptive mode.
You can use the diagnostic information in this ring buffer to analyze scheduling problems. For example, you can use the information in this ring buffer to troubleshoot problems when SQL Server stops responding. Trace flag 8012 disables recording of events for schedulers. You can turn on trace flag 8012 only at startup.Trace flag 8018: Disable the exception ring buffer Trace flag 8019: Disable stack collection for the exception ring buffer
The exception ring buffer records the last 256 exceptions that are raised on a node. Each record contains some information about the error and contains a stack trace. A record is added to the ring buffer when an exception is raised.  Trace flag 8018 (Documented: KB826433) disables the creation of the ring buffer, and no exception information is recorded. Trace flag 8019 disables stack collection during the record creation. Trace flag 8019 has no effect if trace flag 8018 is turned on. Disabling the exception ring buffer makes it more difficult to diagnose problems that are related to internal server errors. You can turn on trace flag 8018 and trace flag 8019 only at startup.

59. TF’inG up the optimizer
T652 disables page pre-fetching scans
T4199 enables all fixes that were previously made for the query processor under many trace flags/hot fixes based on “special” policy
T2301 enables advanced optimizations specific for BI and processing very large data sets
T2312 and T9481 enables or disables the new SQL2014 cardinality estimator, respectively
T2861 enables caching trivial plans
T8744 disables pre-fetching ranges for nested loop operations.
T4199 Documented: KB974006
Scope: Session | Global
that:
Any hotfix that could potentially affect the execution plan of a query must be controlled by a trace flag,
Except for fixes to bugs that can cause incorrect results or corruption
Helps avoid unexpected changes to the execution plan.
…Which means that virtually everyone is not necessarily running SQL Server with all the latest query processor fixes enabled
Consider enabling for “pristine” SQL Server deployments?
Microsoft strongly advises not to enable this trace flag unless you are affected
T2301 Integer Modelling
Normally, histogram modelling assumes that values between histogram steps are equally distributed to every numerical double code point.  This modelling extension remembers, for integer base types, that values can only occur on integer code points and this improves cardinality estimates for inequality filters.
Comprehensive Histogram Usage
Normally, histograms are ignored when the cardinality of a relation dropps below the number of steps in a histogram.  This is a heuristic which captures the liklihood that a histogram continues to describe a relation.  This modelling extension applies the histogram in cardinality estimate regardless of the cardinality estimate for the relation.
Base Containment Assumption
Normally, when two relations are joined, we assume that X distinct code points in the same key range on input relation R will join with Y distinct code points in the same key range on input relation S such that MIN(X,Y) will find matches.  This assumption is called Simple Containment.  We assume that the smaller number of distinct code points match with code points from the other side.  This modelling ignores the relative population of distinct code points in the base forms of R and S, and also ignores any filtering that has occured to the base forms for R and S before joining.  Base containment applies the containment assumption only to the base relations and uses probabilistic methods to compute the degree of joining.  In addition, implied filters are modelled correctly since their behavior is very different from orthogonal filters.
Comprehensive Density Remapping
Normally, when columns are CONVERTed only a small number of densities involving such columns are remapped to the new column definitions.  Note that operations like convert rarely change the density of a column.  Density is the measure of the number of duplicate values for each distinct value.  With this modelling extension, all such remappings are applied which makes possible subsequent density matching for the purposes of cardinality estimation.  In some cases, this can lead to excessive use of memory.
Comprehensive Density Matching
Normally, densities are matched when the very same base column is filtered or joined.  With this modelling extension, the notion of equivalence of columns as a result of equi-joins is applied leading to more complete density matching for the purposes of improved cardinality estimation.
T2312 /
< check out DBCC OPTIMIZER_WHATIF>

60. liquid TF’ing awesome
Others for SQL2005 to SQL2012-
7352 : Final query tree  8605 : Converted tree  8606 : Input, simplified, join-collapsed, and normalized trees  8607 : Output tree  8608 : Initial memo  8615 : Final memo  8675 : Optimization stages and times
T8675 shows information on the stages of optimization. Very useful for SQL query debugging and tuning.
T8605 shows query initial tree representation created by SQL Server
T8606 shows additional logical trees used during the optimization process.
T8607 shows the optimization output tree.
T8608 shows the input tree for cost-based optimization when first copied into the Memo structure. Final Memo structure is visible with T8615.
Even more optimizer-related flags, some of which only work on 2012, like:
2373 : Memory before and after deriving properties and rules (verbose)  7357 : Unique hash optimization used  8609 : Task and operation type counts  8619 : Apply rule with description  8620 : Add memo arguments to 8619  8621 : Rule with resulting tree
When using T8615, look for the ‘Good Enough Plan Found’ message.
Trace flags used and documented by Paul White include (all assume 3604 is also active):
7352 : Final query tree  8605 : Converted tree  8606 : Input, simplified, join-collapsed, and normalized trees  8607 : Output tree  8608 : Initial memo  8615 : Final memo  8675 : Optimization stages and times
The above were used in the presentation because they all work from 2005 to 2012.  There are a large number of other optimizer-related flags (some of which only work on 2012).  Some are listed below for people that like this sort of thing:
2373 : Memory before and after deriving properties and rules (verbose)  7357 : Unique hash optimization used  8609 : Task and operation type counts  8619 : Apply rule with description  8620 : Add memo arguments to 8619  8621 : Rule with resulting tree
As usual, these are undocumented, and unsupported (including by me!) and purely for educational purposes.  Use with care at your own risk.
“The statistics used in a query plan are stored in a cached execution plan, and you can see them using the special trace flag 8666 (there is always a traceflag).”
It is also possible to identify which statistics were used in a query plan compilation if you run the query using traceflags 9292 and 9204 as Query Optimizer Guru Paul White (blog|twitter) showed here.
TF2301 = give the optimizer more time?

61. But I WaNT MORE AWESOME! Combine T3604 with DBCC {RULEOFF | RULEON}
DBCC RULEOFF ('GetToScan')
DBCC RULEON ('GetToScan')
DBCC RULEON ('JNtoHS')
DBCC RULEON ('JNtoSM')
Use DBCC {SHOWONRULES | SHOWOFFRULES} to see the access methods chosen by the optimizer.

62. Resources Best blogs: Trace Flags: http://www.victorisakov.com
Trace Flags:
Look on MSDN for:
Storage Top 10 Best Practices
Predeployment I/O Best Practices
SQL Server Physical Database Storage Design
SQLIO Disk Subsystem Benchmark Tool
Bare Metal Tuning facts, for example:
The commodity platform was RAID5
Extra spindles added 1.4% eachover baseline.
RAID1 & RAID1+0 each provided about a 319% boost over baseline
Extra spindles added 5% each over baseline

63. Wrap Up Engage with us on social media.
We’re thankful for your word of mouth promotions and endorsements!
Share your tough SQL Server problems with us:
Download SQL Sentry Plan Explorer for free:
Check out our other award winning tools: