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

システムに負荷がかかっているときにデッドロックする2つのストアドプロシージャがあります。プロシージャBが同じテーブルに挿入している間に、プロシージャAはテーブルから選択しています。ロックグラフは、Proc AがProc BがIXモードロックを必要とするSモードページロックを持っていることを示していますが、Proc Aは、Proc BがすでにIXモードページロックを持っている別のページのSモードページロックを待機しています。 明らかに、両方のクエリがテーブル内のページを同じ順序でロックすることを確実にすることによってこれを整理することができますが、その方法を理解できません。 私の質問は、SQL ServerはどのようにINSERTとSELECTを実行しているときにページをロックする順序を決定し、この動作をどのように変更できるかを教えてください。

10 sql-server  locking  deadlock 

IsolationLevel.ReadUncommittedを使用すると、クエリでロックが発行されないはずです。しかし、これをテストすると、次のロックが表示されました。 Resource_Type：HOBT Request_Mode：S（共有） HOBTロックとは何ですか？HBT（ヒープまたはバイナリツリーロック）に関連する何か？ なぜまだSロックを取得するのですか？ 分離レベルのスナップショットオプションをオンにせずにクエリを実行するときに、共有ロックを回避するにはどうすればよいですか？ SQLServer 2008でこれをテストしていますが、スナップショットオプションはオフに設定されています。クエリは選択のみを実行します。 SQL Serverがロッククエリでそれを表示していないようですが、Sch-Sが必要であることがわかります。それでも共有ロックが発行されるのはなぜですか？による： トランザクション分離レベルの設定（Transact-SQL） READ UNCOMMITTEDレベルで実行中のトランザクションは、他のトランザクションが現在のトランザクションによって読み取られたデータを変更するのを防ぐために、共有ロックを発行しません。 だから私は少し混乱しています。

10 sql-server  sql-server-2008  locking  isolation-level 

メンテナンスプランを実行しようとすると、次のエラーが表示されます。 クエリ ""の実行が次のエラーで失敗しました： "ページレベルロックが無効になっているため、テーブル" "のインデックス" "（パーティション1）を再編成できません。" 現在、このインデックスで行レベルのロックが有効になっています。ページレベルのロックを有効にすることはできますが、どのような影響があるのか​​わかりません。 私の質問は次のとおりです。2つのロックスキームの違いは何ですか、そして実際の（運用中の）結果は何ですか？

10 sql-server  maintenance  locking 

SQL Server 2000を実行していると、これらのエラーのいくつかが毎晩発生します。 Could not continue scan with NOLOCK due to data movement このエラーをスローするクエリは、1ダースを超えるテーブルを結合する大きく複雑なクエリです。基礎となるデータは頻繁に更新できます。 文化的な「ベストプラクティス」は、過去にNOLOCKヒントを導入することでパフォーマンスが向上し、同時実行性が向上したことです。このクエリは100％正確である必要はありません。つまり、ダーティリードなどを許容します。しかし、これらすべてのロックヒントがあるにもかかわらず、データベースがこのエラーをスローする理由を理解するのに苦労しています。 誰もがこれにいくつかの光を当てることができます-穏やかに、私は実際にはプログラマーであり、DBAではありません:) PS：以下の修正を以前に適用しました：http : //support.microsoft.com/kb/815008

10 sql-server-2000  locking  database-tuning  nolock 

ALTER TABLE数時間前にクエリを開始しましたpg_stat_activityが、ロックを待機していることが（を介して）最近認識されました。変更したいテーブルをロックしていて、それを手放さない他のクエリを発見しました。 このクエリは（列のデータ型を変更する）「単純な」クエリですが、大規模なテーブルで実行されています。 ロックを保持しているプロセスを強制終了するのではなく、を強制終了することにしましたALTER TABLE。 トランザクションでラップしませんでしたALTER TABLE。 私の理解する限り、クエリがロックを待機しているという事実は、常にロックを待機していて、何も変更していないことを意味します。 これは本当ですか？ALTER TABLEクエリを完全にキャンセルしても安全ですか？または、クエリがすでに何かを変更していて、それをキャンセルすると、データベースが何らかの中間状態になる可能性がありますか？ PS：を使用してキャンセルする予定ですSELECT pg_cancel_backend(pid);。これが悪い考えであるなら、私に知らせてください。

10 postgresql  locking  alter-table  waits 

各行にカウンター（整数値のみ）があるテーブルでは、現在の値を取得し、同時にそれを増やす必要があります。 効果的に、私はこれをしたいです： SELECT counter FROM table WHERE id=123 UPDATE table SET counter=counter+1 WHERE id=123 ただし、2つのクエリがスレッドセーフではないため、これを行うことは明らかにスレッドセーフではありません。（同じ行で）同じことを行う複数のプロセスが同じカウンター値を取得する場合があります。すべて一意にする必要があるので、各プロセスで実際の現在値を取得し、1つ増やします。 行ごとに手動ロックを実装する構成を考えることができますが、これを行う簡単な方法はあるのでしょうか。

10 mysql  locking 

SQLite FAQから私はそれを知っていました： 複数のプロセスが同じデータベースを同時に開くことができます。複数のプロセスが同時に実行できますSELECT。ただし、いつでもデータベースに変更を加えることができるプロセスは1つだけです。 だから、これまで私は私ができる理解限り：1）複数のスレッドからの読み取りデシベル（SELECT複数のスレッド（から）2）リードデシベルSELECTシングルスレッドから）と書き込み（CREATE、INSERT、DELETE） しかし、リーダーはライターをブロックせず、ライターはリーダーをブロックしないため、同時実行性が向上する先行書き込みロギングについて読みました。読み取りと書き込みは同時に実行できます。 最後に、指定されたとき、私はそれを見つけたときに完全に混乱しました： SQLITE_LOCKEDエラーが発生するその他の理由は次のとおりです。 しようとしCREATEたりDROPしながら、テーブルやインデックスSELECTの文はまだ保留されています。 SELECT同じテーブルでがアクティブなときにテーブルに書き込もうとしています。 SELECTsqliteがそのように設定されていない場合に、マルチスレッドアプリケーションで同じテーブルに対して同時に2つを実行しようとする。 DBファイルのfcntl（3、F_SETLK呼び出しが失敗します。これは、たとえばNFSロックの問題が原因である可能性があります。この問題の1つの解決策は、DBを移動してコピーし、新しいInode値を持つようにコピーすることです。 だから、私は明確にしたいのですが、ロックを回避する必要がありますか？2つの異なるスレッドから同時に読み書きできますか？ありがとう。

10 locking  sqlite 

これに名前の付いたパターンがあるのか​​、それともひどい考えなのでないのかわかりません。しかし、アクティブ/アクティブの負荷分散された環境で動作するサービスが必要です。これはアプリケーションサーバーのみです。データベースは別のサーバーに配置されます。テーブル内の各レコードのプロセスを実行する必要があるサービスがあります。このプロセスには1〜2分かかる場合があり、n分ごとに繰り返されます（構成可能、通常は15分）。 この処理を必要とする1000レコードのテーブルと、この同じデータセットに対して実行される2つのサービスで、各サービスに処理するレコードを「チェックアウト」させたいと思います。一度に1つのサービス/スレッドのみが各レコードを処理していることを確認する必要があります。 過去に「ロックテーブル」を使用していた同僚がいます。他のテーブルのレコードを論理的にロックするためにレコードがこのテーブルに書き込まれ（他のテーブルはかなり静的で、非常に時々新しいレコードが追加されます）、削除されてロックが解放されます。 新しいテーブルが常に削除を挿入するのではなく、いつロックされ、現在ロックされているかを示す列があるとよいのではないかと思います。 誰かがこの種のことについてのヒントを持っていますか？長期的な論理ロックの確立されたパターンはありますか？一度に1つのサービスのみがロックを取得するようにするためのヒントはありますか？（私の同僚はTABLOCKXを使用してテーブル全体をロックしています。）

10 sql-server  sql-server-2008-r2  locking 

編集：セッションレポートがブロックされているがPAGELATCH_*、LCK_M_関連する待機タイプではなく、で待機しているのはなぜですか？ 以前は、SQLサーバーはブロッキングセッションのみをblocking_session_Id列で報告すると想定していました。ブロックされたセッションが論理ロックを待機していて、などのほかのものがなかった場合PAGELATCH_*。

9 sql-server  sql-server-2014  optimization  locking  wait-types 

私はこのような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 

どちらの形式のロックでも、レコードが別のプロセスで現在使用されている場合、プロセスはレコードの正しいコピーを待機します。悲観的ロックの場合、ロックメカニズムはDB自体（ネイティブロックオブジェクト）から取得されますが、楽観的ロックの場合、ロックメカニズムは、レコードが「古くなった」かどうかを確認するタイムスタンプのような行バージョン管理の一種です。 ただし、どちらも2番目のプロセスがハングします。だから私は尋ねます：なぜ楽観的ロックは一般的に悲観的ロックよりも速く/優れていると考えられていますか？また、楽観よりも悲観が優先されるユースケースはありますか？前もって感謝します！

9 performance  locking  rdbms 

私の上級DBAは、デフォルトではSQLクエリを実行してもテーブルはロックされないと言っていました。 SQL Server Reporting Services（SSRS）レポートにいくつかの問題がありましたが、ロックおよびいくつかのエラーが発生しているようです。 私はググリングをしましたが、何も見つけることができませんでした。 SSRSレポートは、クエリ対象のテーブルをロックしますか？ この動作を具体的に文書化したMSDNドキュメントはありますか？

9 sql-server-2008  locking 

次のような状況です。 私はRACを持っています。両方のノードにロックがあります。 最初のノード SID EVENT USERNAME BLOCKING_SESSION ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID STATUS 1 102 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFA958 5f4bzdg49fdxq ACTIVE 2 111 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFAC98 5f4bzdg49fdxq ACTIVE セッション情報をブロックしています SID EVENT USERNAME ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID …

9 oracle  locking  wait-types 

SQL Server 2008 R2には、トランザクションを含むデータベース変更のタイムアウトを引き起こす方法はありますか？アプリケーションコードがハングまたは例外をスローし、ロールバックまたはコミットの実行に失敗するシナリオがあります。これにより、トランザクションが完了するまで他のセッションがハングします。

9 sql-server-2008-r2  locking  transaction 

SQL Server 2008 R2のテーブルで一部の削除、更新、および挿入を実行する長時間実行トランザクション（たとえば、T1と呼ばれます）があります。同時に、別のプロセスが定期的にこのテーブルの選択ステートメントを実行します。 デフォルトの分離設定（READ COMMITTEDだと思いますか？）では、T1は、トランザクションがコミットまたはロールバックされるまで、selectステートメントの実行をブロックします。 私が見たいのは、トランザクションが進行中でも、selectステートメントが一貫したデータで機能することです。スナップショット分離が役立つと思いますが、正しい方向に進んでいるかどうかはわかりません。これは、このアプリケーションに最適な分離レベルでしょうか？ 次に、selectステートメントを呼び出しているプロセスを制御することはできませんが、T1を呼び出す.NETアプリケーションを制御します。selectステートメントとT1の両方で分離レベルの変更が必要ですか、それともT1だけを別の分離レベルとしてマークするだけで十分でしょうか？

9 sql-server  transaction  locking  isolation-level