Тупики транзакций базы данных сервера Sql;визуальные студийные процедуры вставки

Question

У меня есть настройка базы данных сервера sql, которая принимает транзакции вставки из приложения Visual Studio, работающего с использованием потоков. Теперь транзакции зашли в тупик, и у меня есть обходной путь: когда код Visual Studio 2010 обнаруживает тайм-аут, он просто попытается вставить данные. Глядя на мои текстовые журналы, которые я настроил, это происходит слишком часто и вызывает проблемы с производительностью. Некоторые из онлайн-ресурсов указывают на обнаружение ошибочной транзакции и ее уничтожение, но если мое приложение зависит от результатов, полученных в базе данных, это может оказаться невозможным. Есть ли предложения, как с этим бороться. Я использую Parallel Taskfactory в Visual Studion 2010, поэтому в любой момент времени выполняется не менее 1000 потоков?

код для просмотра: мой код вставки

Любые идеи действительно ценятся.

Схема таблицы sql

Table PostFeed

 id          int    
 entryid     varchar(100)
 feed        varchar(MAX)
 pubdate     varchar(50)
 authorName  nvarchar(100)
 authorId    nvarchar(100)
 age         nvarchar(50)
 locale      nvarchar(50)
 pic         nvarchar(50)
 searchterm  nvarchar(100)
 dateadded   datetime

 PK - entryid + searchterm     

хранимая процедура для вставки так что он делает целую кучу вставок и опирается на ограничения первичного ключа для проверки дублирования

создание полной таблицы

USE [Feeds]
GO
/****** Object:  Table [dbo].[PostFeed]    Script Date: 09/21/2011 11:21:38 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[PostFeed](
[id] [int] IDENTITY(1,1) NOT NULL,
[entryId] [varchar](100) NOT NULL,
[feed] [varchar](max) NULL,
[entryContent] [nvarchar](max) NULL,
[pubDate] [varchar](50) NOT NULL,
[authorName] [nvarchar](100) NOT NULL,
[authorId] [nvarchar](100) NULL,
[age] [nvarchar](50) NULL,
[sex] [nvarchar](50) NULL,
[locale] [nvarchar](50) NULL,
[pic] [nvarchar](100) NULL,
[fanPage] [nvarchar](400) NULL,
[faceTitle] [nvarchar](100) NULL,
[feedtype] [varchar](50) NULL,
[searchterm] [nvarchar](400) NOT NULL,
[clientId] [nvarchar](100) NULL,
[dateadded] [datetime] NULL,
[matchfound] [nvarchar](50) NULL,
[hashField]  AS ([dbo].[getMd5Hash]([entryId])),
  CONSTRAINT [PK_Feed] PRIMARY KEY CLUSTERED 
 (
[entryId] ASC,
[searchterm] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, 
IGNORE_DUP_KEY = OFF,       ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
 GO SET ANSI_PADDING OFF
 GO

Я попытался экспортировать график взаимоблокировок, но не смог заставить его работать, поэтому вот несколько строк из трассировки

Lock:Timeout    60468       sa  0X01    247 G01 sa  2011-09-   21 16:00:44.750   1:4557807  3463314605  .Net SqlClient Data Provider    0   0XEF8B45000100000000000000070006    22164   7   postFeeds    0  2011-09-21 16:00:44.750 1   G02     0 - LOCK    8 - IX          0   72057594075152384   1 - TRANSACTION 0   6 - PAGE        
Lock:Timeout    60469       sa  0X01    478 G01 sa  2011-09-   21 16:00:44.887  (7bf23fc490ce)  3463299315  .Net SqlClient Data Provider    0   0X3802000000017BF23FC490CE070007    17900   7   postFeeds   0   2011-09-21 16:00:44.887 1   G02     0 - LOCK    5 - X           0   72057594075152384   1 - TRANSACTION 0   7 - KEY     
Lock:Timeout    60470       sa  0X01    803 G01 sa  2011-09-   21 16:00:44.887  (379349b72c77)  3463296982  .Net SqlClient Data    Provider 0   0X380200000001379349B72C77070007    17900   7   postFeeds   0   2011-09-21 16:00:44.887 1   G02     0 - LOCK    5 - X           0   72057594075152384   1 - TRANSACTION 0   7 - KEY     
Lock:Timeout    60471       tdbuser 0X048D73EF643661429B907E6106F78358  93  G01 tdbuser 2011-09-21 16:02:41.333 1:14386936  3463346220  .Net SqlClient Data Provider    0   

Answer 1

Я столкнулся с той же ситуацией, вставляя загрузку записей с параллельными потоками.Чтобы обойти проблему взаимоблокировки, я указал блокировку таблицы при вставке ...

Insert dbo.MyTable WITH(TABLOCKX) (Column1)
Values ( SomeValue);

Я пытался использовать блокировки низкого уровня, но у меня все еще были блокировки.TabLockX несколько замедлил пропускную способность, но все равно он был на тонну быстрее, чем последовательные вставки, и больше не возникало взаимоблокировок.