You can enable and disable trace flags either globally or per-session in SQL Server.
This makes it seem like perhaps if you enable optimization trace flag 4199 globally for all sessions, you might be able to disable it per-session.
But that’s NOT how it works.
Here’s a great recent question that I got about query tuning and index use:
Assuming that the documented levels of data type precedence in SQL Server are true as of SQL 2016, why does a bigint value not force an index scan when compared against an int column?
I recently received a question from a vendor about databases created by software vendors.
Short answer: the SQL Server optimizer will know that the table was truncated, but statistics might not update when you expect.
For the long answer, let’s walk through an example using the WideWorldImporters sample database.
You’ve got an important stored procedure that you think needs index help– but it runs in environment with lots of other queries. How do you focus in and discover exactly what indexes need tuning for that procedure?
Today’s question is about why a query might be slow at first, then fast the next time you run it.
I recently got a fantastic question from a reader regarding lock usage in SQL Server:
One of my production databases has a total lock count around 25,000 (select count(*) from sys.dm_tran_locks). The configuration setting for locks is set to the default of zero. This lock count is due to multiple procedures which frequently run and use the same 2-3 tables, repeatedly taking out and releasing locks. Do I need to change the configuration for locks or look into the SP’s so they can finish more quickly, rather than creating locks?
Should you always index your foreign keys? What if you index them, and then the index never gets used?
I recently mapped out my thought process for how I approach a new instance of SQL Server when it comes to index tuning.
SQL Server’s “index usage stats” dynamic management view is incredibly useful– but does it tell you what you THINK it tells you?
I explain the quirks of how sys.dm_db_index_usage_stats works and why the information is so valuable.
Psssttt – I have an updated blog post on this called the Learner’s Guide to SQL Server Performance Tuning
The SQL Server is slow, what should you do? I answer a reader question and share my strategy for performance troubleshooting.
Recently I got a fun question about an “upsert” pattern as a “Dear SQL DBA” question. The question is about TSQL, so it lent itself to being answered in a blog post where I can show repro code and screenshots.
Learn why SQL Server’s table partitioning feature doesn’t make your queries faster– and may even make them slower.
Never, ever, disable backups to fix a performance problem.
If you’re not having a performance crisis, you might look at that sentence and say, “Wow, that’s super dumb! Who would ever do that?”
Well, a lot of people, actually. It’s pretty common.
Hindsight is everything. I was lucky to be trained by a great team of DBAs back when I first started with SQL Server. But it’s hard to know exactly what you really need to know, particularly as new tools are becoming available.
Wednesday, May 4, 2016 Liverpool Exhibition Centre One day session* **£349 until April 9, 2016. £399 thereafter – This training day has sold out!*
I will be presenting this session in a Training Day at the SQLBits conference in Liverpool, UK. Reserve your seat for this one day session here.
Update: improved/more recent version of queries for this are here.
It can be pretty difficult to manage statistics in data warehouses, or even OLTP databases that have very large tables.
