3

私の同僚（同僚だったと約束します！）は、先週の木曜日からメインのSQL Serverで更新プログラムを実行したままにしています（そうです、100時間プッシュしています！）。問題のSQL（1つのトランザクションで追加する可能性があります）は次のとおりです。

update daily_prices  set min_date = (select min(a.date)
   from daily_prices a       
   where a.key = daily_prices.key and       
   a.iid = daily_prices.iid)

（ええ、私は知っています、凶悪です...）

クエリプランの合計コストは22186.7であり、更新する行の推定数は約1億5,100万です。

明らかに、このクエリを何らかの方法で解決する必要があります。クエリを強制終了すると、残忍なロールバックが生成されることに気付きますが、それがどこまで進んだかを知る方法はありません。私たちが知っている唯一のことは、sys.dm_exec_requestsからのこのエントリです。

session_id status query_textcpu_timetotal_elapsed_time読み取り書き込みlogical_reads
52一時停止された更新daily_prices...2328469 408947075 13831137 42458588 151809497

だから私の質問は、私たちの最善の行動方針は何でしょうか？

  1. 待って
  2. それを殺してロールバックし、次の氷河期の前にロールバックすることを願っています
  3. 他に何かありますか？
4

2 に答える 2

2

個人的には、今週終了する可能性がないとはいえ、この段階でのロールバックは、クエリがこれまでよりもはるかに長くかかる可能性がある場合を除いて、それを待ちたいと思います. それが実稼働サーバーである場合、絶対に必要でない限り、オプション 2 を使用して強制終了することはありません。

適切なバックアップがある場合、一部の制御/動作システムを取り戻すという点で、別のデータベースをオンラインにしてバックアップ/ tlog バックアップを復元しますが、トランザクションが開始された時点を超えて復元することは望ましくありません (または、まだロールバックする必要があります)。 .) これにより、少なくとも開発作業を継続できるシステムが得られますが、製品システムにとって理想的な状況になる可能性は低いです。

実稼働サーバーの場合は、実行前にクエリとクエリ プランをテストすることの適切性について、個人と親切な言葉を交わしてください。多くの DBA が、あまり礼儀正しくない指示方法を提案できると確信しています :)

于 2010-07-20T12:43:14.650 に答える
2

そのため、トランザクションが完了するのを待つことにうんざりし (SQL の 1 つの部分で丸 1 週間を過ごした後、誰がそうしないでしょうか?)、それがバックアップ プロセスを妨害していたので、それを殺すことは必要悪であると考えました。

データベースはトランザクションのロールバックを開始しました。

5日が経過しました。

インターネット上の他の場所の投稿で、データベースが再起動されたときに魔法が起こり、トランザクションが「消える」ことがあることを指摘しましたが、これらは一般的に暴かれています*。私たちはそれをやってみました。データベースが復旧モードになることはわかっていましたが、データベースはいずれにせよますます病気になり、現在のロールバック作業以外は何も実行できなくなり、SQL Server がシステム リソースを占有し、必要な場所に転用しないという誤動作を見てきました。仕事をすること。

(* DB が進行中のトランザクションを「忘れる」だけではないことを知るのに十分なデータベース理論も知っていますが、SQL Server エラー ログにスタック ダンプも表示され、SQL Server が取得していることがわかります。実行しなければならなかったロールバックの量にますます不機嫌になります）

そのため、データベースを再起動しました。

案の定、データベースは回復モードになりました。ただし、SQL Server のイベント ログでは、20 秒ごとに更新にかかる時間が更新されていました (ログ メッセージから合計で約 25 時間と計算されていましたが、最終的にはわずか 1 時間でした)。半分 （！））。

この回復/ロールバックの方法がより速いかどうか、私は強く疑います (SQL Server が以前と同じレベルの作業を実行してトランザクションをアンワインドする必要があると予想していたため)、どちらの方法でも 1 時間半以内に終了しました。ロールバックの途中で本番データベースを再起動する習慣をつけたくありません)。バッチ プログラムを作成したことがある人なら誰でも言うように、イベント ログの更新メッセージは天の恵みでした。それらがどれほど不正確であることが判明したとしても - 少なくともそれらは最悪のケースでした.

この製品ボックスを使用するのは 2 人だけという余裕があったため、データベースを復旧モードにすることを選択することはうまくいき、以前のロールバック状態 (または少なくともDBA スキルが不足しているため、何も解釈できませんでした)。将来これを行うことをお勧めしますか？....絶対にありませんが、関係者が教訓を学び、適切な開発サーバーの費用を理事会に請求できることを願っています! (壮大な Joel-Test の失敗!)

于 2010-07-27T08:38:49.970 に答える