we have a few long running procedures in the database, that cause an instant Table Lock on our main text storage table, which causes all other requests of the web app to wait (because the table is used in nearly every request).
Setup
- Web Application with ASP.NET, Entity Framework, SQL Server 2008R2
- A lot of Tables (Table per Class Strategie) with data attributes
- ONE Table ("dbo.Translations") for dynamic defined texts (to enable translations).
- No foreign keys to this table
To get the text of the object in the right language, the Object ID is saved to the translation table with the text value
Table Definition
So the Translation Table looks like:
dbo.Translations (ID varchar(36), type varchar(10), lang varchar(5), value varchar(max))
whereas Type is defined for each object and lang is like 'en-GB' (not relevant).
Index
The table has two indexes:
PK_Translations on ID (Clustered, not unique)
UNQ_Translations on all columns (nonclustered, unique)
Problem
The table has to handle two operations:
SELECTS and INSERTS.
Update and delete is not a common use-case.
The table holds nearly 1.000.000 rows and an index over ID,type,lang.
When the web application wants to insert (multiple) records, the operation takes a lot of time and creates an instant table lock. This stops every other request to this table (maybe even to other tables, so sometimes it seems to be a database lock?!) and causes them to wait.
Inserts
The INSERTS of large data is done in the following way:
INSERT INTO Translations
(Id, Typ, lang, value)
SELECT
td.nId,
td.Typ,
td.lang,
td.value
FROM #tempDictionary td
Note: #tempDictionairy is a temporary table
Steps
The following steps where tested and did not improve the situation:
- Start the SELECT transaction with read uncommitted -> no change
- Extend the index sparsity to 50% to ensure that the inserted records can be saved easily -> no change
How can I find out why the SQL Server creates an table / db lock?
Best Answer
Are you 100% sure that this process is escalating to a tablock? You can verify this with Adam Machanic's
sp_whoisactive
. Take a snapshot (execute the proc) while the process is running (and presumably blocking). Collect the locks and the query plan - this will give you information needed to fix this issue. Please note what the spids waiting in the insert are waiting on...If they are waiting on latches -we have a page split situation locks its a blocking/locking issueRemember lock escalation happens when a single statement graps 5K locks on an table or index. (http://technet.microsoft.com/en-us/library/ms184286(v=sql.105).aspx) I have found that using the paglock hint (so you take fewer coarser locks) can be used to avoid tablock escalation.
Take a look at the query plan collected in step 1. What is the cardinality estimate of the row being insert (i.e. the select statement)... Is it much greater than 5K? If it is you might want to code a loop - so that you are only inserting 2500 rows at a time...