タグ付けされた質問 「deadlock」

非常にトラフィックの多いWebサイトを使用しており、毎時間数千の新しいレコードが挿入される可能性があります。 この1つのエラーがサイトに障害をもたらしています。 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 

システムに負荷がかかっているときにデッドロックする2つのストアドプロシージャがあります。プロシージャBが同じテーブルに挿入している間に、プロシージャ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に3つのクラスター化列ストアインデックス（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以外の別のインデックスを使用する場合、デッドロックは発生しません。 3つのテナントフィルターのうち2つを削除しても、デッドロックしません。 トップ32以下を選択しても、デッドロックは発生しません。 OPTION（MAXDOP 1）を追加しても、デッドロックは発生しません。 スクランブルされたPRODレプリカ、PROD読み取り専用セカンダリ、およびPROD自体でこれを再現できます。 この動作をDEVまたはINTで再現できません。 3つのテーブル結合すべてにWITH（NOLOCK）を追加すると、依然としてデッドロックが発生します クエリ自体がデッドロックします。他にアクティブなプロセスがない場合はデッドロックします。 並列処理のないクエリプランはデッドロックしない デッドロックxmlはこちら PRODバージョン： …

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

この2つの挿入クエリにはデッドロックがあります。 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コンテンツデータベース内の使用率の高い1つのテーブルに対して、多数のSELECT / INSERTデッドロックが発生しています。関連するリソースを絞り込みました。両方のプロセスで非クラスター化インデックスのロックが必要です。INSERTはSELECTリソースでIXロックを必要とし、SELECTはINSERTリソースでSロックを必要とします。デッドロックグラフは、3つのリソースを示しています。1）SELECT（プロデューサー/コンシューマーパラレルスレッド）からの2つ、および2）INSERTです。確認のためにデッドロックグラフを添付しました。これはMicrosoftのコードとテーブルの構造であるため、変更を加えることはできません。 ただし、MSFT SPサイトで、MAXDOPインスタンスレベルの構成オプションを1に設定することを推奨していることを確認しました。このインスタンスは他の多くのデータベース/アプリケーション間で共有されているため、この設定を無効にすることはできません。 したがって、私はこれらのSELECTステートメントが並列にならないようにすることを試みました。これは解決策ではなく、トラブルシューティングに役立つ一時的な変更であることがわかっています。そのため、ワークロードが変更されていない（SELECT / INSERTが頻繁に発生する）にもかかわらず、デッドロックがなくなったにもかかわらず、「並列処理のコストしきい値」を標準の25から40に増やしました。私の質問はなぜですか？ SPID 356 INSERTは、非クラスター化インデックスに属するページにIXロックを持っています SPID 690 SELECT実行ID 0は、同じ非クラスター化インデックスに属するページにSロックを持っています 今 SPID 356はSPID 690リソースのIXロックを要求しますが、SPID 690がSPID 690によってブロックされているため、それを維持 できません。 1はSPID 356によってブロックされており、デッドロックが発生しています。 実行計画は私のSkyDriveにあります 完全なデッドロックの詳細はここにあります 誰かが私になぜそれを本当に感謝するか理解するのを手伝ってくれるなら。 EventReceiversテーブル。 Id uniqueidentifier no 16 Name nvarchar no 512 SiteId uniqueidentifier no 16 WebId uniqueidentifier no 16 HostId uniqueidentifier no 16 HostType …

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関数を導入すると、このような問題がどのように発生するのか理解できません。参考までに、元のスカラーUDF定義と、C＃の置換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コースの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 CONSTRAINT …

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 

デッドロックのシナリオに遭遇しています。デッドロックの唯一の関係者は、単一のテーブルと、そのテーブルから削除する単一のストアドプロシージャであるように見えます。エラーログのトレースを解読するガイドラインとして以下のMSDNの記事を使用して、これらのデッドロックのいくつかの時点でのSQLエラーログの私の分析に基づいて、その結論を導き出しました。 テーブルDEXTableとストアドプロシージャClearDEXTableRowsを以下に定義します。DEXTableに行を挿入する別のストアドプロシージャInsertDEXTableRowがありますが、そのプロシージャはSQLエラーログのエントリに基づくデッドロックに関与していないようです。 DEXTableには約830万行があり、着実に成長する傾向があります。回答者のテーブルも大きく、着実に成長する傾向があります。 ClearDEXTableRowsとInsertDEXTableRowをすばやく連続して頻繁に呼び出すページがある、トラフィック量の多いWebサイトからアクセスされます。 デッドロックは、過去10日間、1日あたり0〜9回発生しました。 1222のSQLトレースを有効にし（DBCC TRACEON 1222を使用）、最近フラグ1204を有効にしました。デッドロックの検出と終了に関するこれらのフラグの出力については、適切な説明があります 私の質問は： この1つのストアドプロシージャClearDEXTableRowsだけがデッドロックの原因であることは理にかなっていますか？ もしそうなら、誰もがこれがどのように起こり得るかの良い説明を提供し、それを修正する方法を勧めることができますか？ 私の疑いは、DELETEステートメントが頻繁に再構築する必要があるDEXTableのPKで競合を引き起こしていることです。 そうでない場合、デッドロックの原因をさらに掘り下げるには、どのような追加のトレースを有効にする必要がありますか？（私はここで学びたいです） -- 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 

私たちのデータベースの1つに、複数のスレッドによって集中的に同時にアクセスされるテーブルがあります。スレッドはを介して行を更新または挿入しますMERGE。行を時々削除するスレッドもあるので、テーブルデータは非常に不安定です。アップサートを実行するスレッドは時々デッドロックに悩まされます。この問題は、この質問で説明されている問題に似ています。ただし、違いは、私たちの場合、各スレッドが1行だけを更新または挿入することです。 簡略化されたセットアップは次のとおりです。テーブルは、2つの一意の非クラスター化インデックスを持つヒープです。 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 

同様に構成された2つの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レポートは取得されません。 私の人生では、この違いの理由はまったくわかりません。私はこれを広範囲にグーグルで調べ、これらのトレースフラグに関するMSドキュメントを読んだ（そして再度読んだ）ので、このような動作のレポートも、何が原因であるかについてのヒントも見つかりません。近づく唯一のことは、どちらのトレースフラグも機能していないという時折の主張ですが、これらはすべて、有効化コマンドにタイプミスがあった場合のケースであることが判明しました。DBCC TRACESTATUSを使用して確認しているため、これは当てはまりません。 そのため、トレースフラグ1222 のみが機能しない原因となる可能性のある原因、および/またはそれを修正する方法についての洞察は、高く評価されます。 さて、ここに興味深い展開があります。自分でデッドロックを生成するたびに（このコードを使用：https : //stackoverflow.com/questions/7813321/how-to-deliberately-cause-a-deadlock）、両方のトレースレポートがエラーログに記録されます。デッドロックレポートの1つのみをトリガーするように見えるのは、アプリケーションから数日ごとに発生する「自然な」デッドロックだけです。これが役立つかどうかはわかりませんが、トレース1222が1204と同じデッドロック状態のすべてについて報告しないと考える理由はありますか？

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