私は次の状況にあります：ストアドプロシージャは断続的に2つのテーブルを使用します。このspを同時に実行する必要があります（同時に50のように）。これにより、約33％のケースでデッドロックが発生します。問題は、ここでsp_getapplockを使用するのが適切かどうかです。私がするのは追加することだけです：
exec sp_getapplock @Resource = 'resource_name', @LockMode = 'exclusive',@LockTimeout = '60000', @DbPrincipal = 'dbo'
トランザクションの最初のコマンドとして、すべてが機能しているようです。並行性を除いて、それは大丈夫です。不安なのは、データベースが実際に行うべきことを実行しようとしていることです。おそらく、このアプローチにはより良い代替案や深刻な欠点がありますか？
あなたはおそらくこれを今解決しました、しかしそれが助けになる場合に備えて。負荷がかかっている大規模で複雑なデータベースでは、ほぼ確実にデッドロックが発生することがあります。プロセスの後半でリソースの競合が発生するかどうかを判断するために必要な範囲をデータベースが先読みすることは非常に困難です。デッドロックを最小限に抑えるためにできることはたくさんあります。たとえば、適切なインデックス、適切に構造化されたテーブルアクセスなど、さまざまな情報があります。ただし、デッドロックを回避するような方法でコードを構造化できず、それを利用できない場合もあります。sp_getapplock間違いなく悪いことではありません。お気づきのように、並行性がなくなったため、ボトルネックが発生します。しかし、デッドロックを排除することの利点は、おそらくパフォーマンスの面でそれを補う以上のものです。残念ながら、私は自分のSPの1つで同様のことを試しましたが、への呼び出しsp_getapplock自体がデッドロックを引き起こしているため、常に問題を解決できるとは限りません。
基本的に、それはあなたが達成しようとしていることに帰着します。ただし、使用しているデータベースが複雑であるほど、データベースの側面を手動で調整する必要がある可能性が高くなります。すべてを実行できるわけではありません。そのため、優れたデータベースの専門家が依然として求められています。SPをシングルスレッドにするという特定の要件がない限りsp_getapplock、問題を解決するための最初の試みは使用しないでください。私は3回程度しか使用していません。しかし、あなたの状況を考えると、それはあなたの問題を解決し、SPの複雑な内部を理解する必要がなく、おそらく悪い副作用がないので、私は間違いなくそれを使います。最も可能性が高いのは、速度が低下する可能性があることですが、気付いたようには聞こえませんか？