FIX: Application performance issue when a query references temporary tables that are created in a session in SQL Server 2008 and in SQL Server 2008 R2

Consider the following scenario:

• An application runs a query that references some temporary tables in Microsoft SQL Server 2008 and in Microsoft SQL Server 2008 R2. The temporary tables are created in a session instead of in a stored procedure.
• The query plan is cached.
• Many users run the same query in a highly concurrent environment.
  
  For example, many users use an application that runs the following query:
  

  create table #x (col1 int)
  go
  insert into #x values (1)
  go
  select * from #x where col1 = 1
  go

In this scenario, the application encounters performance issues.

Note For more information about how to identify this issue, see the "More information" section.

This issue occurs because the same query plans are inserted into cache in the same hash bucket for each user when the query text is the same.

When a large number of plans are hashed to the same bucket (also known as a hash chain), the time to look up a plan in the cache increases significantly, and the performance issues may occur. Additionally, worker threads may encounter severe spinlock contention, and other threads are affected when these worker threads do not perform the correct scheduler yields.

Note Only the update for SQL Server 2008 R2 is currently available. For SQL Server 2008, see the "Workaround" section to work around this issue.

Cumulative update information

SQL Server 2008 R2 Service Pack 1

The fix for this issue was first released in Cumulative Update 1 for SQL Server 2008 R2 Service Pack 1. For more information about how to obtain this cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2008 R2 fix release. We recommend that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

SQL Server 2008 R2

The fix for this issue was first released in Cumulative Update 7. For more information about how to obtain this cumulative update package for SQL Server 2008 R2, click the following article number to view the article in the Microsoft Knowledge Base:Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2008 R2 fix release. We recommend that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

To work around this issue in SQL Server 2008 and in SQL Server 2008 R2, move any references of temporary tables to inside stored procedures.

For more information about how to create and modify table basics, visit the following MSDN website:

Spinlock contention can be identified from the sys.dm_os_spinlock_stats dynamic management view (DMV) that has a high contention rate on the SOS_CACHESTORE spinlock.

To identify this issue, run a query that resembles the following:
If the following conditions are true when you run this query, you may encounter the performance issues:

• This query generates the same query text.
• The count for the same bucketid is large.
  
  Note A large count for the same bucketid is usually over 1000.
• The queries reference temporary tables