We are having problems on SQL Server 2012 with contention on tempdb page 2:1:128, which seems to be related with system table sysobjvalues.

We have about 400 sessions waiting on this resourse 2:1:128 with wait type PAGELATCH_EX.

Nothing has changed in our application or on database, so we don't know the reason for this. We've tried to identify the offending query (if there is one) without success.

The problem starts to occur all of a sudden and a couple of hours later it goes away. There are no backups running except for the transaction log backup every 15 minutes taking 1 to 2 minutes.

tempdb is using 8 files, on a 2 CPU x 4 cores machine. Anyway, the latch seems to be unrelated to IO problems.

We have 256Gb of RAM.

CPU is normal on the machine for the load it has (80%), and IO is normal also. The number of transations processed is also normal.

Here is the result of SELECT @@version:

Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64) Dec 28 2012 20:23:12 Copyright (c) Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.2 (Build 9200: )

Any ideas on what is happening or where should we look to find the problem?

  • In the past SELECT ... INTO #TempTable FROM ... would lock tempdb metadata until the insertion completed. Do not know if this behavior persists, since I abandoned the pattern. – RLF Feb 16 '15 at 15:56
  • Are 8 files all exactly the same size? Same autogrowth? Are you using trace flags 1117 and 1118? – Aaron Bertrand Feb 16 '15 at 16:02
  • @RLF, Thank you for your reply. We use table variables with the pattern: DECLARE @TempTable TABLE (...); INSERT @TempTable SELECT ... We do this a lot, but we didn't change our pattern in the last weeks, so we still don't know what triggers the problem. – Renato Ferreira Feb 16 '15 at 16:57
  • @Aaron, thanks for your reply also. We have 8 files, all with the same size, and the same autogrouth. The last time files have grown was last September. We do not use any trace flag. This latch seems to be on the in-memory page, and not IO (that would be PAGEIOLATCH_EX: someone correct me if I'm wrong). – Renato Ferreira Feb 16 '15 at 17:00
  • That's right, pagelatch indicates contention on the pages in memory, but I still suggest trying trace flag 1118 (you should set it as a startup flag). This should reduce contention when a lot of these table variables are created simultaneously. Also are your table variables created with a primary key? How many rows are going into them? – Aaron Bertrand Feb 16 '15 at 17:23

Apparently we were able to solve the problem. There is one particular UDF that is being called thousands of times per second, and it declares 3 table variables. For most of the calls, the UDF returns before declaring the tables, but I did not realize that SQLServer creates them anyway. We separated the second part of the query to a new UDF that is called only when necessary. This way, most of the times, the table variables are not created (obtained from cache to be more precise). By doing this, we were able to significantly reduce the perf index Active Temp Tables, and SQL Server returned to normal behavior.

For those that did not know this: if an ad-hoc query, PROC or UDF declare a table variable (or a temporary table), SQL Server creates the tables, before starting execution. So, an early return does not prevent temp tables from being created. This completely fooled this accidental DBA. I was trying to find the culprit by changing queries one by one, putting a return in the beginning. Because of this behavior (which is understandable), I was failing to find the root cause of the contention on the DB. Live and learn every day!

For those who are now saying that it does not make sense to have a query called so many times, you are right! We are already changing the application to cache the results outside SQL Server.

Thank you Aaron and RTL for your help.

Renato Ferreira

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.