問題タブ [table-locking]

トランザクションでいくつかのテーブルの更新を行う Java スレッドがあり、読み取り専用 transaction でテーブルを読み取る別のスレッドがあります。テーブルを読み取るスレッドは待機しており、結果を返さず、他のスレッドが更新を行った後にのみ戻ります。

DB が mysql で、更新とクエリが並行して行われ、待機がない場合は状況が異なります。MS SQL 側で何か不足していますか。並列にするために何をする必要がありますか。これは、MS Sql Server のテーブル ロックが原因で発生していますか。

MS Sql サーバーの休止状態の設定:

db.driverClassName = com.microsoft.sqlserver.jdbc.SQLServerDataSource

db.dialect = org.hibernate.dialect.SQLServer2008Dialect

休止状態のバージョン: v4.3.6.Final

接続プール: HikariCP-java6 - v2.2.5

必要なすべての cronjob の全体を保持する cronjobs という MySQL テーブルがあります (たとえば、古い電子メールの削除、プロファイルの年齢の更新など)。すべての cronjob には、cronjob の期限が来た場合に実行される定義済みのコード ブロックがあります (異なる cronjobs に対して異なる間隔を取得しました)。

due cronjobs の実行のために、UNIX crontab によって毎分実行される PHP スクリプトを取得しました (「php -f /path/to/file/execute_cronjobs_due.php」を呼び出す execute_cronjobs_due.sh を呼び出します)。

execute_cronjobs_due.php を実行すると、すべての cronjobs が実行されることがマークされるため、execute_cronjobs_due.php の別の呼び出しによって、同じ cronjobs が既に実行されている並列実行が発生することはありません。

ここでの問題: 実行に 60 秒以上かかる場合がありますが、crontab プログラムは 60 秒後に execute_cronjobs_due.sh を呼び出しません。実際に起こることは、execute_cronjobs_due.sh が、前の crontab の実行の実行の直後に呼び出されることです。また、実行に 120 秒以上かかる場合は、次の 2 つの実行が同時に初期化されます。

タイムライン：

2015-06-15 10:00:00: execute_cronjobs_due.sh の実行 (140 秒かかります)

2015-06-15 10:02:20: execute_cronjobs_due.sh の 2 つの同時実行

正確に同時に実行されるため、selects（実際にはマークされた1回を除外する必要があります）がまったく同時に実行されるため、実行中のcronjobをマークする必要はありません。そのため、更新は、両方が予定されている cronjobs を既に選択した直後に行われます。

cron ジョブが同時に実行されないようにするには、どうすればこの問題を解決できますか? MySQL テーブルロックを使用できますか?

事前にご連絡いただき、誠にありがとうございました。

フレデリック

SQL Server 2008 R2 でこの手順を書いています。

このクエリと後続の ID の再シードを実行している間、挿入のためにテーブルをロックするのは正しい方法ですか? また、私が上でやっていることに問題があるかどうか知りたいですか? これは、カスタム レプリケーション環境で使用されます。

ティア

発生したテーブル ロックに関する情報を監視、キャプチャ、および (テーブルなどに) 書き込むことができる何らかのメカニズムがあるかどうかを尋ねたいと思います。

私がこれまでに見つけたのは、手動または定期的に実行できるストアド プロシージャはほとんどありません。実際に必要なのは、挿入の前/内でそれらをキャッチし (更新の可能性が高い)、別のテーブルに保存できるようにすることです。

データベースのいずれかのテーブルのデータを更新するストアド プロシージャがあり、通常は 30 ～ 50 ミリ秒で実行されるため、この質問をします。しかし、時折奇妙なことが起こり、同じデータと同じサーバー構成を使用して、同じ手順を実行するのに最大 90 秒かかります。

これにはトリガーを使用する必要がありますか？はいの場合、どのトリガーで設定する必要がありますか? 特定のテーブルのテーブル ロックのみが必要です。私が理解していることから、共有ロックは挿入/更新を許可しないため、あらゆる種類のロックをキャプチャする必要があります。

前もって感謝します

Oracle 11gR2 の使用:

特定のテーブルから、指定された保持日を過ぎたレコードを削除することで、特定のテーブルをクリーンアップするプロセスが既にあります (レコードの処理が終了したときのタイムスタンプと保持日の比較に基づきます)。現在、このプロセスが失敗した場合にチームに警告するコードを作成しています。このプロセスが失敗する可能性があることを確認できる唯一の方法は、クリーンアップしようとしている特定のテーブルで DELETE が無効になっている場合です。

アラートをテストして、プロセスを失敗させてアラートが機能し、正しく表示されることを確認したいと考えています。テーブルを一時的に排他的にロックすると、DELETE が無効になり、レコードを削除する手順が失敗しますか? それとも、DDL 操作を無効にするだけですか? これを行うより良い方法はありますか？

今日は言葉が難しいので、あなたが私を助けてくれるように、これをはっきりと書き留めようとしています. いくつかのやり過ぎが ymmv の下に存在します。

table1 から約 48m のレコードを table2 に移行しています。どちらも InnoDB です。user_id を介して table1 からカリングされるレコードを特定できます (「user_id=3 によって入力されたレコードは、table1 から table2 に移動します」)。複数のコンシューマーを介してジョブを実行できるように、AMQP サーバーを介して移行プロセスを実行できるように拡張する必要がある、単一インスタンスのセットアップでコードを動作させるための最初のパスがあります (つまり、コンシューマーを実行しています)。コンシューマーがすべて同時に実行されているラウンド ロビン設定で、同時に同じジョブの 2 つのインスタンスで並行して /jobs を実行します。ジョブをすばやくノックアウトするために 10 人程度の消費者にスケールアップできるようにしたいと考えています。それ以外の場合は、単一のインスタンスがジョブを完了するのに約 15 日かかります。

このコードは、実行ごとにクエリ条件に一致する最も古い 2000 レコードを選択します。問題は、コードを実行してレコードを選択する 2 つのインスタンスがある場合、instance1 が ID の 1-2000 を取得し、ほぼ同時に開始された instance2 も 1-2000 を取得することです。 table1 から 0-2000 の移動が完了し、それらの ID は table1 に引き続き存在します。

わかりました、問題ありません。除外するレコードを記録するコントロール テーブルを追加します。これにより、instance1 が「レコード 1 ～ 2000 を持っています」と言うことができるため、instance2 が起動してクエリに行くと、「どの ID を除外する必要がありますか?」と表示されます。インスタンス 2 が ID の 2001 から 4001 を取得し、コントロール テーブルを更新して、インスタンス 2 の ID が 2001 から 4001 であることを知らせるように、「次の 2000 レコードをくれ」の一部としてコントロール テーブルを照会することに基づいています。 instance3 の場合、次の 2k レコードを要求する起動時に、ID の 1 から 4001 を省略する必要があることがわかります。

インスタンスがロックされた制御テーブルにエントリを書き込むとき、それは「[first_id_found] and [last_id_found]」または「5671 and 7671」として書き込まれます。テキストが sql BETWEEN 句に入るので、' and ' を使用します。

id が 1565 から 1567 の間でなく、id が 1568 から 1570 の間でなく、created_by=3 である table1 から ID を選択します。id asc limit 0、2000 で並べ替えます。

問題：

ロックが必要なテーブルはコントロール テーブルだけです。そのため、インスタンスがコントロール テーブルにアクセスできるようになると、除外するレコードを見つけることも、独自の除外レコードを書き込むこともできるようになります。ロックが解放されると、テーブルにアクセスする次のインスタンスは、control最新のデータを見つけます。

ただし、クエリが終了するまでロックをそのままにしておく必要がありますtable1。結果セットの最初と最後の ID を特定できるので、これらをcontrolテーブルに追加して、次に起動するインスタンスが何を除外するかを知ることができます。

制御ファイルはどちらtable1でもないことに注意してください。また、どちらもロックする必要がないためortable2を指定していないことに注意してください。また、他のプロセスがテーブルにアクセスしており、妨げたくないため、 or も必要ありません。他の実行中のプロセスからまたはへのアクセス。table1table2table1table2

したがって、疑似コードは次のようになります。

table1 にクエリを実行すると、レコードが返されません。不正解です。4,800 万件のレコードがあります。errorInfo() をチェックすると、次のエラー状態が表示されます。

「テーブル 'table1' は LOCK TABLES でロックされていませんでした」

ロックしたくないのですtable1が、LOCK TABLES が配置された後control、UNLO​​CK TABLES の前にクエリが実行されたため、使用するすべてのテーブルが必要なある種のトランザクション モードになっているようです。割り当てられたロック レベル。WTF、ドキュメントにはこれについて何も表示されません。

table1ロック範囲内にないのに、なぜこの問題が発生するのですか? 私はこの戦略と結婚していません。同じ機能をもたらす別のパターンがあれば、私はゲームだと思います。回避策？提案？

Oracle データベースでデッドロックの問題が発生している状況があります。

私はおそらくいくつかのテーブルロックにロックする必要があると言いました.

彼の言っていることは本当ですか？

以下は、受信した電子メールの一部です。

PHP でエラーが発生した場合 (try/catch)、テーブルのロック解除を管理する必要がありますか? または、ロックはスクリプトの最後で PDO オブジェクトによって自動的に解放されますか?