One tip for presenting: have a conversation

I like public speaking, but I haven’t always liked it. It started when I read Dale Carnegie’s book on public speaking, “The Art of Public Speaking,” while in college. If you’re interested, google search for a pdf on it, I believe at this point it’s available for free.

What I want to emphasis from this book

The whole book is 285 pages. That’s a lot of information, so I’ll summarize what I found to be the most useful.

Treat public speaking like a conversation with one person

I don’t recommend having a specific script with words that have to be said on each slide. I also don’t memorize the slides. If you’re reciting a script word-for-word, your presentation might come off as a textbook.

If you approach public speaking like a conversation between you and the entire audience (representing one singular entity), you can talk to them just like you talk to people every day.

If you mispoke in a 1-1 conversation, would it bother you?

I guess it depends on what you said, but I don’t think it would be a big deal. React the same way in your presentation. Mistakes happen, and the audience will understand if you correct yourself.

If you enjoyed this post or found it useful, please read some of the book. It seriously changed how I felt about public speaking.

Thanks for reading! Stay tuned.


Query memory grants part 1: Where does the memory go?

Let’s talk about how queries use memory, specifically in the execution plan. One of the query operators that use memory is sorting. To emphasize this, I’ll write a query with an order by clause, and look at the execution plan.

Query that will request a memory grant

Using StackOverflow2010 (Thanks to Brent Ozar and the Stack Overflow team for their data dump):

SELECT Id, Type
FROM dbo.PostTypes
ORDER BY Type

Here’s the results if you’re curious.

We want to look at the execution plan.

First, let’s look at the properties of the SELECT operator.

This is the memory grant for the entire query. Since we know that the Sort operator uses memory, let’s take a look at that operator and confirm that it used memory.

Where does the memory grant go?

We can confirm that the sort operator was requesting memory by looking at the operator’s memory fractions.

It gets harder from here. The execution plan is very useful for determining where the memory grants are coming, but once there’s multiple operators requesting memory grants, it gets much more complex.

For example, memory grants can be reused between operators in execution plans (source).

I want to continue this series and talk more about query memory usage. For those posts, please stay tuned!

Query Store max size limit is not a hard limit

If you’re on SQL Server 2016 or above, maybe you’re thinking about using the Query Store. That’s good! It’s an incredibly useful tool for performance tuning, and it can help you scale to handle performance on many servers.

There’s one thing I think you should know. The max size limit for the Query Store is not a hard limit.

Controlling Query Store size

There’s a couple settings you can change to control the Query Store size. First, you want to set the Query Capture Mode to Auto, especially if you have an ad-hoc workload. There’s a great post by Erik Darling on BrentOzar.com about this setting. In summary, I recommend Auto to control the speed at which the Query Store grows.

Second, you can set the max size. You can do this in the database properties or with T-SQL, like so:

ALTER DATABASE [DBA]  
SET QUERY_STORE (MAX_STORAGE_SIZE_MB = 100);  

But the MAX_STORAGE_SIZE_MB is not a hard limit

I’ve seen this occur in production systems with heavy ad-hoc workloads. As the Query Store gathers data, there seems to be a point where the writes are queued up. When they are written to disk, the max size can be exceeded.

Anecdotally, I’ve seen a production systems where the max size has been vastly exceeded. But let me show you an example on a small scale on my demo machine.

Bad Query Store settings to reproduce this issue

To make this demo easy on my machine, I’m going to set the settings to the opposite of what I just recommended. Don’t use the settings below, this is just for the test.

Bad settings!

And now I need some ad-hoc bad queries to write to the Query Store. Here’s what I came up with. I ran the output of this query, and pretty much instantly over-filled the Query Store.

SELECT top 10000 
	N'SELECT N''' + REPLACE(text,N'''',N'') 
	+ N''' FROM sys.messages WHERE severity > 1 and text = ''' 
	+ REPLACE(text,N'''',N'') + N'''' 
FROM sys.messages

Now let’s look at the Query Store properties.

22 MB used of 5 MB max size.

Will this happen to my production system?

If you’re asking yourself if this will happen to you, I can’t answer that. First, make sure you have the right settings. Erin Stellato at SQL Skills has great advice on how to setup the Query Store.

I think this scenario is very unlikely in your system, unless you have very massive queries ad-hoc queries, and the Query Store setup incorrectly.

Make sure your nonclustered indexes are enabled

I know this post might sound obvious. This is a very rare problem. But this actually happened to me, and it might happen to you!

Suddenly, all queries on a test system were running slowly

One morning, I was called into a system where every single query was running slowly. System resources like CPU and memory were over-utilized, and it looked like the entire system was struggling to keep up.

I checked wait statistics, PerfMon, and sp_WhoIsActive. These just further reinforced the idea that the system was experiencing a heavier workload than normal.

How it was discovered

There’s actually a really simple query to find out if your indexes are disabled.

USE [Your-database-here]
GO
SELECT name from sys.indexes WHERE is_disabled = 1

Unfortunately, enabling indexes isn’t as easy

Here’s the snippet from SQL Server Management Studio on disabling/enabling indexes:

That’s right, in order to re-enable an index, you have to rebuild it. Ouch.

How did the indexes become disabled?

Well, to disable an index, you have to run an alter index script on each index. In my situation, a script that disabled indexes ran on the wrong environment.

Thanks for reading! Hopefully this rare issue doesn’t occur to you. Stay tuned!


Be cautious when using: OPTION(RECOMPILE)

This is one dangerous query hint. I wish I knew that when I started query tuning. I’ve used it before without fully understanding the impact.

What happens when a statement has OPTION(RECOMPILE)

SQL Server will compile an execution plan specifically for the statement that the query hint is on. There’s some benefits, like something called “constant folding.” To us, that just means that the execution plan might be better than a normal execution plan compiled for the current statement.

It also means that the statement itself won’t be vulnerable to parameter sniffing from other queries in cache. In fact, the statement with option recompile won’t be stored in cache.

The downsides

I have a few reasons why this hint is dangerous. First, compiling queries isn’t free. Using option recompile will use extra cpu and memory every time the statement compiles.

There’s also the fact that the hint applies strictly to the statement level, not the entire query. Let’s take a look at an example.

Reduce, reuse, recycle

I’m going to re-use the stored procedure from this post on parameter sniffing and using the estimated execution plan. Except for this example, I can’t use the estimated execution plan because there’s a temp table.

CREATE OR ALTER PROCEDURE [dbo].[QueryPostType_TempTable] (@PostType INT) as
BEGIN

SELECT PostTypeId, Tags,Body 
INTO #TempExample
FROM Posts where PostTypeId = @PostType


SELECT PostTypeId, Tags, Body
FROM #TempExample 
WHERE PostTypeId = @PostType
OPTION(RECOMPILE)

DROP TABLE #TempExample

END

GO

This stored procedure has OPTION(RECOMPILE) on only one statement

I’ll run the stored procedure with the value of 3, first.

exec [QueryPostType_TempTable] 3

Then, I’ll get the actual execution plan for post type 4.

exec [QueryPostType_TempTable] 4

Each “query” in this example is a separate statement. To prove that, I’ll right-click on the top SELECT INTO and view the properties.

Okay, but what about the cost of compilation?

To see the cost of compilation, just use statistics time. First, let’s create a simpler procedure.

CREATE OR ALTER PROCEDURE [dbo].[QueryPostType_OptionRecompile] (@PostType INT) as
BEGIN
SELECT PostTypeId, Tags,Body FROM Posts
JOIN Users as U on Posts.OwnerUserId = U.Id 
JOIN Users as U2 on Posts.LastEditorUserId = U2.Id
WHERE PostTypeId = @PostType
OPTION(RECOMPILE)
END
GO

And then execute.

SET STATISTICS TIME ON;
EXEC [QueryPostType_OptionRecompile] 4;
/*
SQL Server parse and compile time: 
   CPU time = 5 ms, elapsed time = 5 ms.
*/

Every time that statement runs, it will be compiled again, costing those 5 ms of CPU time.

Summary of the downsides

Each statement with option recompile consumes extra cpu and memory and doesn’t store the execution plan in cache, preventing performance tuners from seeing metrics like total execution count, or total worker time in dm_exec_query_stats.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close