Questions tagged «deadlock»

我的网站访问量很高，每小时可能会插入数千条新记录。 这个错误使网站瘫痪： PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {location_instance} (nid, vid, uid, genid, lid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => 1059 [:db_insert_placeholder_1] => 1059 [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] => cck:field_item_location:1059 [:db_insert_placeholder_4] => 1000 ) 如果MySQL无法处理这种类型的负载，我将感到非常惊讶。那么，我的问题是，这是数据库问题吗？如何配置MySQL以处理这么大的流量？ …

10 mysql  performance  innodb  deadlock  insert 

当系统处于负载状态时，我有两个存储过程处于死锁状态。当Proc B插入同一张表时，Proc A从表中选择。锁定图显示Proc A具有Proc B希望为其IX模式锁定的S模式页面锁定，但是Proc A正在等待针对Proc B已经具有IX模式页面锁定的另一页面的S模式页面锁定。 。 显然，可以通过确保两个查询以相同的顺序锁定表中的页面来解决此问题，但是我不知道该怎么做。 我的问题是：SQL Server如何确定在执行INSERT和SELECT时锁定页面的顺序，以及如何修改此行为？

10 sql-server  locking  deadlock 

我在SQL Server 2016中拥有三个群集列存储索引（CCI）表。所有这些CCI都基于租户ID处于同一分区方案中。最近，而且前后矛盾，我在从联接到这些表的简单选择语句中陷入僵局。死锁的示例查询： SELECT TOP 33 r.tenantid FROM Table_r r INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey WHERE r.TenantId = 69 AND pe.TenantId = 69 AND cm.TenantId = 69 错误信息： 事务（进程ID 56）与另一个进程在通用的可等待对象资源上处于死锁状态，并且被选择为死锁牺牲品。重新运行事务。 线索： 如果查询使用CCI以外的其他索引，则不会死锁。 如果删除三个tenantid过滤器中的两个，则不会死锁。 如果我选择前32位或更低，则不会死锁。 如果添加OPTION（MAXDOP 1），则不会死锁。 我可以在混乱的PROD副本，PROD只读次要副本和PROD本身中对此进行复制。 我无法在DEV或INT中复制此行为。 如果我将WITH（NOLOCK）添加到所有3个表联接中，它仍然会死锁 查询自身会死锁。当没有其他活动进程时，它将死锁。 没有并行性的查询计划不会死锁 死锁XML在这里 我们的PROD版本： …

10 sql-server  sql-server-2016  partitioning  deadlock  columnstore 

对于这两个插入查询，我有一个死锁： insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.596', 180, 4, 181, 561) insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.611', 180, 4, 181, 563) 这是InnoDB状态： ------------------------ LATEST DETECTED DEADLOCK ------------------------ 2014-12-23 15:47:11 1f4c *** (1) TRANSACTION: TRANSACTION 19896526, ACTIVE …

10 mysql  innodb  deadlock 

此实例承载SharePoint 2007数据库（SP）。我们一直在针对SP内容数据库中一个频繁使用的表遇到许多SELECT / INSERT死锁。我缩小了涉及的资源，这两个过程都需要对非聚集索引进行锁定。INSERT在SELECT资源上需要IX锁，而SELECT在INSERT资源上需要S锁。死锁图描述了三个资源：1。SELECT中的两个（生产者/消费者并行线程）和2.）INSERT。我附上了死锁图供您查看。因为这是Microsoft代码和表结构，所以我们无法进行任何更改。 但是，我已经在MSFT SP站点上阅读了他们建议将MAXD​​OP实例级别的配置选项设置为1。由于此实例在许多其他数据库/应用程序之间共享，因此不能禁用此设置。 因此，我决定尝试防止这些SELECT语句并行执行。我知道这不是解决方案，而是临时的修改，以帮助进行故障排除。因此，这样做后，我将“并行计算的成本阈值”从我们的标准25提高到了40，即使工作负载没有改变（SELECT / INSERT频繁发生），死锁也消失了。我的问题是为什么？ SPID 356 INSERT在属于非聚集索引的页面上具有IX锁 SPID 690 SELECT执行ID 0在属于同一非聚集索引的页面上具有S锁 现在 SPID 356希望在SPID 690资源上获得IX锁，但由于SPID 356被SPID 690执行ID 0阻止而无法获得IX锁 SPID 690执行ID 1希望在SPID 356资源上获得S锁，但由于SPID 690执行ID无法获得它SPID 356阻止了1，现在我们陷入僵局。 执行计划可以在我的SkyDrive上找到 完整的死锁详细信息可以在这里找到 如果有人可以帮助我理解为什么我会非常感激。 EventReceivers表。 id uniqueidentifier否16 名称nvarchar否512 SiteId uniqueidentifier否16 WebId uniqueidentifier否16 HostId uniqueidentifier否16 HostType int否4 ItemId int否4 DirName nvarchar否512 LeafName nvarchar否256 …

10 sql-server  deadlock  sharepoint 

在SQL Server 2008 R2中，我得到了几个死锁报告，它们在输入缓冲区中具有“ * password ------------”。它看起来像是攻击，但在那种情况下，我不知道攻击的原因或类型。 （该日志是由专家DBA生成的，他有很多经验，并告诉我，不是我） 有谁知道它是什么？谢谢！ 例： <?xml version="1.0"?> <blocked-process> <process id="process879948" taskpriority="0" logused="0" waitresource="KEY: 5:72057602473263104 (1d69201d0ba6)" waittime="5185" ownerId="88389135" transactionname="SELECT" lasttranstarted="2012-09-25T18:11:02.507" XDES="0x1f7d2a590" lockMode="S" schedulerid="2" kpid="4552" status="suspended" spid="86" sbid="2" ecid="0" priority="0" trancount="0" lastbatchstarted="2012-09-25T18:11:02.507" lastbatchcompleted="2012-09-25T18:11:02.507" lastattention="2012-09-25T18:07:35.740" clientapp=".Net SqlClient Data Provider" hostname="IP-xxxxxxxx" hostpid="4868" loginname="sa" isolationlevel="read committed (2)" xactid="88389135" currentdb="1" lockTimeout="4294967295" …

10 sql-server-2008  deadlock  profiler 

如果死锁图中的锁是表，页面或行级别，有什么方法可以解密？我从图表中获得了我需要的所有信息，包括隔离级别（2），但我也确实想知道这一点。 感谢任何能提供帮助的人！

10 sql-server  deadlock 

我们的应用程序需要与Oracle数据库或Microsoft SQL Server数据库同样良好地工作。为方便起见，我们创建了一些UDF以使查询语法同质。例如，SQL Server具有GETDATE（），而Oracle具有SYSDATE。它们执行相同的功能，但它们是不同的词。我们为两个平台编写了一个名为NOW（）的包装UDF，该包装将相关的平台特定语法包装在一个通用函数名称中。我们还有其他这样的功能，其中一些功能实际上什么也不做，只是为了同质化而存在。不幸的是，这对于SQL Server是有成本的。内联标量UDF严重破坏性能，并完全禁用并行性。作为替代方案，我们编写了CLR汇编函数以实现相同的目标。当我们将其部署到客户端时，他们开始遇到频繁的死锁。这个特定的客户端正在使用复制和高可用性技术，我想知道这里是否存在某种交互。我只是不了解引入CLR函数将如何导致这样的问题。作为参考，我在C＃中包含了原始的标量UDF定义以及替换的CLR定义，并为其提供了SQL声明。如果有帮助，我也可以提供死锁XML。 原始UDF CREATE FUNCTION [fn].[APAD] ( @Value VARCHAR(4000) , @tablename VARCHAR(4000) = NULL , @columnname VARCHAR(4000) = NULL ) RETURNS VARCHAR(4000) WITH SCHEMABINDING AS BEGIN RETURN LTRIM(RTRIM(@Value)) END GO CLR组装功能 [SqlFunction(IsDeterministic = true)] public static string APAD(string value, string tableName, string columnName) { return value?.Trim(); } …

9 sql-server  deadlock  sql-clr  functions 

已添加7/11问题是在MERGE JOIN期间由于索引扫描而发生死锁。在这种情况下，一个事务试图在FK父表的整个索引上获得S锁，但是以前另一个事务将X锁置于索引的键值上。 让我从一个小例子开始（使用70-461 cource的TSQL2012 DB）： CREATE TABLE [Sales].[Orders]( [orderid] [int] IDENTITY(1,1) NOT NULL, [custid] [int] NULL, [empid] [int] NOT NULL, [shipperid] [int] NOT NULL, ... ) 列[custid], [empid], [shipperid]是相应的相关参数[Sales].[Customers], [HR].[Employees], [Sales].[Shippers]。在每种情况下，我们在父母表中的引用列上都有一个聚集索引。 ALTER TABLE [Sales].[Orders] WITH CHECK ADD CONSTRAINT [FK_Orders_Customers] FOREIGN KEY([custid]) REFERENCES [Sales].[Customers] ([custid]) ALTER TABLE [Sales].[Orders] WITH CHECK ADD …

9 query-performance  t-sql  foreign-key  deadlock  query-optimization 

我正在运行并发Postgres查询，如下所示： UPDATE foo SET bar = bar + 1 WHERE baz = 1234 每个查询都会影响固定的K个行数，而且我找不到一种方法来强制更新行的顺序，最终导致死锁。当前，我通过手动执行顺序来解决此问题，但这意味着我必须执行比平时更多的查询，同时还将搜索复杂度从O（log N + K）提升到O（K log N）。 有没有一种方法可以提高性能而又不会导致死锁？我怀疑只要Postgres以与扫描行相同的顺序更新行，就可以用(baz)索引替换索引(baz, id)，这是值得追求的方法吗？

9 postgresql  locking  deadlock  update 

我遇到了一个死锁情况，死锁中唯一的参与者似乎是一个表和一个从该表中删除的存储过程。我根据以下几个死锁时对sql错误日志的分析得出了该结论，并使用下面的MSDN文章作为指导来解密错误日志中的跟踪。 表DEXTable和存储过程ClearDEXTableRows在下面定义。还有另一个存储过程InsertDEXTableRow将行插入DEXTable中，但是基于sql错误日志中的条目，该proc似乎不涉及死锁。 DEXTable具有〜830万行，并且趋于稳定增长。受访者表也很大，并且趋于稳定增长。 可从高流量网站访问该页面，该页面上的页面经常快速连续调用ClearDEXTableRows和InsertDEXTableRow。 在过去的10天里，僵局每天发生0到9次。 我已经为1222启用了SQL跟踪（使用DBCC TRACEON 1222），并且最近才启用了标志1204。在检测和结束死锁上有这些标志的输出的详细说明 我的问题是： 仅此一个存储过程ClearDEXTableRows是造成死锁的原因吗？ 如果是这样，谁能提供一个很好的解释，说明如何发生并提出解决方法？ 我的怀疑是DELETE语句导致DEXTable PK上的争用，而DEXTable则需要经常重建。 如果不是，我应该启用什么其他跟踪来更深入地了解死锁的原因？（我想在这里学习） -- Table definition CREATE TABLE [dbo].[DEXTable]( [ExportID] [int] NOT NULL, [RespondentID] [int] NOT NULL, [Exported] [datetime] NOT NULL, CONSTRAINT [PK_DEXTable] PRIMARY KEY CLUSTERED ( [ExportID] ASC, [RespondentID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY …

9 sql-server-2005  primary-key  deadlock  logs  upsert 

在我们的一个数据库中，我们有一个表，该表被多个线程密集并发访问。线程确实通过来更新或插入行MERGE。还有一些线程有时会删除行，因此表数据非常不稳定。进行upsert的线程有时会陷入死锁。该问题看起来类似于此问题中描述的问题。不过，不同之处在于，在我们的例子中，每个线程确实更新或插入一行。 简化的设置如下。该表是堆，上面有两个唯一的非聚集索引 CREATE TABLE [Cache] ( [UID] uniqueidentifier NOT NULL CONSTRAINT DF_Cache_UID DEFAULT (newid()), [ItemKey] varchar(200) NOT NULL, [FileName] nvarchar(255) NOT NULL, [Expires] datetime2(2) NOT NULL, CONSTRAINT [PK_Cache] PRIMARY KEY NONCLUSTERED ([UID]) ) GO CREATE UNIQUE INDEX IX_Cache ON [Cache] ([ItemKey]); GO 典型的查询是 DECLARE @itemKey varchar(200) = 'Item_0F3C43A6A6A14255B2EA977EA730EDF2', @fileName nvarchar(255) …

9 sql-server  execution-plan  deadlock  merge 

当从多个源频繁插入到表中时，我从间隙锁获取死锁。这是我的过程的概述。 START TRANSACTION UPDATE vehicle_image SET active = 0 WHERE vehicleID = SOMEID AND active = 1 Loop: INSERT INTO vehicle_image (vehicleID, vehicleImageFilePath, vehicleImageSplashFilePath ,vehicleImageThumbnailFilePath, vehicleImageMiniFilePath, mainVehicleImage, active) VALUES (%s, %s, %s, %s, %s, %s, 1); END TRANSACTION 的输出SHOW Create table vehicle_image;是： CREATE TABLE `vehicle_image` ( `vehicleImageID` int(11) NOT NULL …

8 mysql  innodb  mysql-5.6  deadlock 

我正在建立一个测试案例，以证明一定的僵局情况，并且需要对正在发生的事情有一些了解。我有一个堆表，方便地称为HeapTable。该表由2个事务类似地更新。 交易1： BEGIN TRAN UPDATE HeapTable SET FirstName = 'Dylan' WHERE FirstName = 'Ovidiu'; WAITFOR DELAY '00:00:15'; UPDATE HeapTable SET FirstName = 'Bob' WHERE FirstName = 'Thierry'; ROLLBACK TRANSACTION 交易2： BEGIN TRAN UPDATE HeapTable SET FirstName = 'Pierre' WHERE FirstName = 'Michael'; ROLLBACK TRAN 我先触发事务1，紧接着触发事务2。正如预期的那样，事务1将要求一些互斥锁以及一些意图互斥锁。事务2将进入并请求在同一RID上进行更新锁定： spid dbid ObjId IndId Type …

8 sql-server  deadlock 

我有一个客户站点，其中有两个配置类似的2008r2 SQL Server“ A”和“ C”。在两台服务器上，启用了跟踪标志1204和1222，并DBCC tracestatus在两台服务器上显示以下内容： TraceFlag Status Global Session 1204 1 1 0 1222 1 1 0 3605 1 1 0 在A上，跟踪标志按预期工作，当发生死锁时，我们在错误日志中同时获取1204和1222死锁报告。但是，在C上，仅显示1204报告，而我们从未获得1222报告。 对于我的一生，我看不出有什么区别。我已经在Google上进行了广泛的搜索，并阅读（并重新阅读了）这些跟踪标志上的MS文档，但找不到任何此类行为的报告，也没有任何提示可能导致这种情况的提示。唯一接近的是偶尔声称没有跟踪标记起作用的情况，但是事实证明，如果它们在启用命令中有错别字。我知道这里不是这种情况，因为我已经使用DBCC TRACESTATUS进行了确认。 因此，对于可能导致仅跟踪标记1222不工作和/或如何修复跟踪标记的任何见解，将不胜感激。 好吧，这是一个有趣的发展。每当我自己生成一个死锁（使用此代码：https : //stackoverflow.com/questions/7813321/how-to-deliberately-cause-a-deadlock）时，我都会在错误日志中获得两个跟踪报告。从应用程序开始每两天就会发生“自然”死锁，似乎只触发其中一个死锁报告。不确定是否有帮助，是否有任何理由相信跟踪1222不会报告与1204相同的所有死锁条件？

8 sql-server  sql-server-2008-r2  deadlock  dbcc  error-log