Mat Stephen's SQL Server WebLog : Performance Top Tips

SQL 2005 - UPSERT: In nature but not by name; but at last!

Mat_Stephen — Wed, 31 Aug 2005 12:34:00 GMT

SQL Server has long been criticised for not having an UPSERT command, well now in SQL 2005 we have some good news, we have two new TSQL set operators that give us the complex insert/update logic that constitute an UPSERT. These are INTERSECT and EXCEPT

e.g.

-- UPDATE Destination FROM (Source INTERSECT Destination)

-- INSERT INTO Destination FROM (Source EXCEPT Destination)

These statements obviate the need to construct complex correlated sub-queries or WHERE EXISTS logic.

And what's more, these operators deliver high performance by exposing core engine functions.

SQL Server Performance Top Tip: SQL Server User Mode Scheduler (UMS) – understanding it can explain some odd performance

Mat_Stephen — Fri, 11 Feb 2005 01:51:00 GMT

When performing batch jobs where you wish to run processes in parallel it is important to understand how the scheduler works.

You can get a description of what the scheduler does by looking under the title ‘SQL Server Task Scheduling’ in Books on Line. However what you need to know is not at all obvious from reading this description. What you need to know are these five facts.

When an application talks to SQL Server it gets assigned a System Process ID (SPID)

1) SPID gets assigned to a UMS

2) There is one UMS per processor

3) A UMS schedules across Processors

4) A SPID stays on UMS for life of thread

5) Two busy SPIDS may fight on the same UMS

You now have the five essential facts, but do you have a useful conclusion? I’m not going to tease you, I shall merely illustrate the implied gotcha.

You have a 4 processor box and a bcp job to run. The job takes 10 processor minutes to run – how long does it take 4 bcp processes (each bound to a separate UMS) to process the job? Pretty easy isn’t it - 2.5 minutes (were obviously in an ideal world here).

So now imagine you’re a very enthusiastic DBA and realize the processors aren’t working to the max. You decide next time you’ll set everything up so that you can run five bcp processes and hopefully make better use of your processes. How long do you think the job will take with five bcp processes? Two minutes? Nope, more like 4 minutes.

Why? Well two of the bcp processes are going to get permanently stuck on one processor. Thus if the work is divided between each spid this will give two minutes of work to each spid. The two spids sharing one processor are now only going to get half the processor time, therefore it will take them twice as long to run – four minutes. QED, five spids thus take considerably longer to run than four

To get a deep understanding of the UMS have a look at the following:

http://msdn.microsoft.com/SQL/sqlarchitecture/default.aspx?pull=/library/en-us/dnsqldev/html/sqldev_02252004.asp?frame=true

Microsoft SQL Server Performance Top Tip: Degrees of Parallelism and a Degree of Uncertainty

Mat_Stephen — Tue, 08 Feb 2005 17:50:00 GMT

Max degree of parallelism is an advanced configuration option in SQL Server about which many question have been asked and much written. In this blog entry I hope to offer some insight and certainty as to what this option does and how it should be used.

Firstly, I must dispel any idea you might have, that this setting has anything to do with how many processors SQL Server can use when trying to service more than one connection (or user) – it hasn’t. If SQL Server has access to four idle processors and it has four processes to run, it will use all four processors – regardless of the max degree of Parallelism.

So what does this option do? This option sets the maximum number of processors SQL Server can use for one query. If SQL Server has to bring back a lot of data (lots of rows) for a query it sometimes makes sense to break the query down into a number of smaller queries, each query returning a subset of the total rows. This way SQL Server can make use of more than processor and hence on multi processor boxes it can potentially return a lot of rows more quickly, for a given query, than it can on a single processor box.

There are a number of criteria that have to be met before SQL Server will invoke ‘Intra Query Parallelism’ (breaking the query down into more than one stream), there’s no point in detailing them here you can find them in BOL under ‘Degree of parallelism’. Suffice to say the decision is based on the available memory on the box and most importantly the availability of the processors.

So why do we need to think about this option – well because leaving it on the default (letting SQL Server decide) can sometimes give you undesirable effects. These effects are:

Queries may go slower with parallelism.
Query time for a particular query may become non-deterministic and this can annoy users. The time may vary because:
1. The query may sometimes go parallel and sometimes it may not.
2. The query may get blocked by a parallel query in front of it hogging the processors.

Before we go on, I don’t think there’s any real benefit in diving into the internals of parallelism, if you’re interested you can look at ‘Parallel Query Processing’ in Books on Line for more detailed information. I think there are only two important things to know about the internals of parallelism:

1. Parallel queries may spawn many more threads than specified in the Max degree of parallelism option. DOP 4 could allow for 12+ threads, four for the query and the extra threads being used for sorts, threads, aggregates and gathering etc.

2. Parallel queries can cause spids to wait with a waittype of CXPACKET or 0X0200

So armed you can now identify spids waiting parallel operations as they will have a waittype of CXPACKET in sysprocesses. To help you here you can use the stored procs in my blog CREATE proc track_waitstats & CREATE proc get_waitstats - useful code for diagnosing SQL 2000 performance

So ‘Queries may go slower with parallelism’ how come?

If the system has a very poor data throughput on the disk subsystem(s) then query decomposition is unlikely to go faster.
Possible skew of data, or possible lock in a data range for a cpu, meaning one parallel process is behind, etc.
If there is a missing an index for a predicate that results in a table scan. A parallel query operation may hide the fact that the query would run much faster as a serial plan with an appropriate index.

Consequently it is recommend you test without parallelism (DOP=1) so these issues can be identified.

The other effects of parallelism mentioned above should be self explanatory and should lead you to the idea that intra query parallelism is not really appropriate for OLTP applications. These are apps where varying query time can annoy users and where a server servicing a number of concurrent users is unlikely to choose a parallel plan because of the cpu workload profile.

So if you are going to employ parallelism it is most likely going to be in a data warehouse, decision support or reporting scenario, where there are a low number of high workload queries on a big fat box with plenty of memory.

So you have decided to employ parallelism – what should you set DOP to. Well one guideline that crops up internally is that if you have 8 processors then DOP = 4 is likely to be the optimal setting. However there is no mast and no flag pinned to it here – testing is the only way to be sure. Further to this I have not seen any other figures, but having said all that, my advice would be to never set this figure to anything more than half the number of processors I have. If I have less than 6 processors I would set DOP to 1 - which doesn't allow any parallelism to take place. I might make an exception if I had a database that was only going to support a single user process (some sort of data warehousing or reporting task) – here the exception would be to set DOP to 0 (default) which lets SQL decide.

Before I finish my ramble – beware that parallel index creation will depend on the figure you set for DOP. This means you may want to change it at times to suit what you’re doing and of course you can use the MAXDOP query hint to override the configuration option for those out of hours jobs.

Finally your query may go slower using parallelism due to a bug – make sure you have the latest service pack.

Microsoft SQL Server Performance Top Tip: Multi Processor (SMP) sudden death syndrome.

Mat_Stephen — Wed, 02 Feb 2005 15:26:00 GMT

You’ve been really proud of your nice new multi processor box, its got eight processors and some serious grunt. Everyone has been really pleased with the system’s lightening responsiveness and the big boss thinks you’re a super computer guru – looks like a pay rise is on its way.

Then, one Monday morning you’ve strolled into work only to find everyone wants your blood. Your super new box is going really slow – the application it hosts appears to have died! What’s gone wrong – you decide to take a quick look at the performance of the processors using either Task Manager or System Monitor. To your horror you see exactly the same processor usage you saw when you originally bought the thing; only one processor seems to be hard at work, the others are just idling.

When you witnessed this behavior before you consulted one of my previous Top Tips SQL Server Performance Top Tip: Multi Processor (SMP) Box Doesn’t Use All It’s Processors and that did the trick – but it won’t work this time!

Well my guess is the symptom is the same as before because you are nearly in exactly the same situation as before. My guess is you have had automatic database growth turned on for this database and indeed the database has in fact grown over the weekend. Assuming when you created the database you created it with all the database data files the same size, I would wager at least one of those files has now grown? If this is the case then I think your problem is you’ve lost ‘proportional fill’. Look at the following excerpt from Books OnLine (BOL).

From Books Online:

As data is written to the filegroup, Microsoft® SQL Server™ writes an amount proportional to the free space in the file to each file within the filegroup, rather than writing all the data to the first file until full and then writing to the next file.

As soon as all the files in a filegroup are full, SQL Server automatically expands one file at a time in a round-robin fashion to accommodate more data (provided that the database is set to grow automatically).

You can loose proportional fill because now you only have the one, newly expanded, file to write to; all the others are full! With only one file to write to, you are essentially only able to use one CPU; as per the previous Top Tip.

The moral of this story is: avoid automatic database growth on multi processor systems.

Microsoft SQL Server Performance Top Tip: Multi Processor (SMP) Box Doesn’t Use All It’s Processors

Mat_Stephen — Wed, 02 Feb 2005 13:42:00 GMT

Seen this? You’ve got a nice new sparkling multi processor box, packed with ‘go-faster’ chips but the performance isn’t much better than your old one or two processor box. You take a look at the processor usage, either through task manager or Performance (System) Monitor, and notice only one processor seems to be hard at work, the others are just idling.

Steam comes out of your ears; you’ve just spent all this money and what for? Well before you drop a wobbly have a look at how many files you have for your database out on disk. Is it one .mdf and one .ldf – the default? Yes? Well that’s most likely your problem – you can only write to one file with one thread. Your database has become IO bound as only one processor can write to the database at any one time.

Solution – create a new database with as many data files (all the same size) as you have processors and transfer the data from the old database into this new one – this is to ensure you get an even proportional fill across the files.

PS If this isn't a new box and you used to get good performance see SQL Server Performance Top Tip: Multi Processor (SMP) sudden death syndrome.

SP I promised during TechNet Gig on SQL Performance which will identify blocking spid at top of blocking chain : sp_blocker_pss80

Mat_Stephen — Wed, 26 Jan 2005 23:31:00 GMT

Please follow the link below to the MS KB article containing the above SP.

Note the 'fast' parameter to improve performance by reducing the amount of extra diagnostic info returned.

http://support.microsoft.com/default.aspx?scid=kb;en-us;271509

Hope you find it useful!

CREATE proc track_waitstats & CREATE proc get_waitstats - useful code for diagnosing SQL 2000 performance

Mat_Stephen — Tue, 25 Jan 2005 02:01:00 GMT

For those attending my TechNet SQL 2000 performance tuning session at TVP Reading on Tuesday 25th Jan, here is the code for the track_waitstats and get_waitstats stored procedures I refer to during the presentation.

CREATE proc track_waitstats (@num_samples int=10,@delaynum int=1,@delaytype nvarchar(10)='minutes')

-- T. Davidson

-- This stored procedure is provided "AS IS" with no warranties, and confers no rights.

-- Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

-- @num_samples is the number of times to capture waitstats, default is 10 times. default delay interval is 1 minute

-- delaynum is the delay interval. delaytype specifies whether the delay interval is minutes or seconds

-- create waitstats table if it doesn't exist, otherwise truncate

set nocount on

if not exists (select 1 from sysobjects where name = 'waitstats')

create table waitstats ([wait type] varchar(80),

requests numeric(20,1),

[wait time] numeric (20,1),

[signal wait time] numeric(20,1),

now datetime default getdate())

else truncate table waitstats

dbcc sqlperf (waitstats,clear) -- clear out waitstats

declare @i int,@delay varchar(8),@dt varchar(3), @now datetime, @totalwait numeric(20,1)

,@endtime datetime,@begintime datetime

,@hr int, @min int, @sec int

select @i = 1

select @dt = case lower(@delaytype)

when 'minutes' then 'm'

when 'minute' then 'm'

when 'min' then 'm'

when 'mm' then 'm'

when 'mi' then 'm'

when 'm' then 'm'

when 'seconds' then 's'

when 'second' then 's'

when 'sec' then 's'

when 'ss' then 's'

when 's' then 's'

else @delaytype

end

if @dt not in ('s','m')

begin

print 'please supply delay type e.g. seconds or minutes'

return

end

if @dt = 's'

begin

select @sec = @delaynum % 60

select @min = cast((@delaynum / 60) as int)

select @hr = cast((@min / 60) as int)

select @min = @min % 60

end

if @dt = 'm'

begin

select @sec = 0

select @min = @delaynum % 60

select @hr = cast((@delaynum / 60) as int)

end

select @delay= right('0'+ convert(varchar(2),@hr),2) + ':' +

+ right('0'+convert(varchar(2),@min),2) + ':' +

+ right('0'+convert(varchar(2),@sec),2)

if @hr > 23 or @min > 59 or @sec > 59

begin

select 'hh:mm:ss delay time cannot > 23:59:59'

select 'delay interval and type: ' + convert (varchar(10),@delaynum) + ',' + @delaytype + ' converts to ' + @delay

return

end

while (@i <= @num_samples)

begin

insert into waitstats ([wait type], requests, [wait time],[signal wait time])

exec ('dbcc sqlperf(waitstats)')

select @i = @i + 1

waitfor delay @delay

End

--- create waitstats report

execute get_waitstats

CREATE proc get_waitstats

-- This stored procedure is provided "AS IS" with no warranties, and confers no rights.

-- Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

-- this proc will create waitstats report listing wait types by percentage

-- can be run when track_waitstats is executing

set nocount on

declare @now datetime, @totalwait numeric(20,1)

,@endtime datetime,@begintime datetime

,@hr int, @min int, @sec int

select @now=max(now),@begintime=min(now),@endtime=max(now)

from waitstats where [wait type] = 'Total'

--- subtract waitfor, sleep, and resource_queue from Total

select @totalwait = sum([wait time]) + 1 from waitstats

where [wait type] not in ('WAITFOR','SLEEP','RESOURCE_QUEUE', 'Total', '***total***') and now = @now

-- insert adjusted totals, rank by percentage descending

delete waitstats where [wait type] = '***total***' and now = @now

insert into waitstats select '***total***',0,@totalwait,@totalwait,@now

select [wait type],[wait time],percentage=cast (100*[wait time]/@totalwait as numeric(20,1))

from waitstats

where [wait type] not in ('WAITFOR','SLEEP','RESOURCE_QUEUE','Total')

and now = @now

order by percentage desc