9

（エラーがスローされたときや開発中だけでなく）本番環境で実行されるロギング/監査コードを書いています。Coding Horrorのデッドロックとロギングの経験を読んだ後、私はアドバイスを求めるべきだと決めました。（「ログに記録しない」というJeffのソリューションは私には機能しません。これは、法的に義務付けられているセキュリティ監査です）

競合とデッドロックを最小限に抑えるための適切な分離レベルはありますか？挿入ステートメントまたはストアドプロシージャに追加できるクエリヒントはありますか？

私は、監査テーブルを除くすべてのトランザクションの整合性に深く関心を持っています。非常に多くのログが記録されるため、いくつかのエントリが失敗しても問題はありません。ロギングが他のトランザクションを停止した場合、それは悪いことです。

データベースまたはファイルにログを記録できますが、ファイルへのログ記録は、結果を何らかの方法で表示できる必要があるため、あまり魅力的ではありません。ただし、ファイルにログを記録すると、ログが他のコードに干渉しないことが（ほぼ）保証されます。

4

4 に答える 4

5

通常のトランザクション (つまり、READ COMMITTED) の挿入では、既に「最小限の」ロックが行われています。挿入が集中するアプリケーションは、挿入が他の操作と混在する順序に関係なく、挿入でデッドロックすることはありません。最悪の場合、集中的な挿入システムにより、挿入が発生するホット スポットでページ ラッチの競合が発生する可能性がありますが、デッドロックは発生しません。

ジェフが説明したようにデッドロックを引き起こすには、次のいずれかのように、さらに多くのことが必要です。

  • システムはより高い分離レベルを使用しています (彼らはそれを実現し、それに値するものでした)
  • トランザクション中にログテーブルから読み取っていました (したがって、「追加専用」ではなくなりました)。
  • デッドロック チェーンには、アプリケーション層のロック (つまりlock、log4net フレームワークの .Net ステートメント) が関係しており、その結果、検出不能なデッドロック (つまり、アプリケーションのハング) が発生しました。問題を解決するためにプロセス ダンプを確認する必要があったことを考えると、これが彼らが抱えていたシナリオだと思います。

したがって、READ COMMITTED 分離レベル トランザクションにログのみを挿入する限り、安全です。SO が持っていたと私が疑うのと同じ問題 (つまり、アプリケーション層のロックを伴うデッドロック) が予想される場合、別のトランザクションまたは別の接続にログオンしたとしても、問題が依然として現れる可能性があるため、データベースの魔法の量はあなたを救うことはできません。

于 2009-06-13T08:16:04.900 に答える
1

監査テーブルのトランザクションの整合性は気にしないので、トランザクションの外部 (つまり、トランザクションの完了後) でロギングを実行できることは明らかです。これにより、トランザクションへの影響が最小限に抑えられます。

また、ロックを最小限に抑えたい場合は、できるだけ多くのクエリ ワークロードが非クラスター化インデックスをカバーするようにする必要があります。(SQL Server 2005 以降ではINCLUDE、NC インデックスでステートメントを使用すると大きな違いが生じる可能性があります)

于 2009-06-13T05:41:40.110 に答える