長時間 SQL ジョブ：VPN が切れても動かし続ける

インデックス再構築の開始から二十分後に VPN が切れて SQL クライアントは切断された接続を表示し、その当然の疑問にこのエラーは答えを持っていません。文は完了したのか、ロールバックしたのか、それともあなたなしで動き続けたのか。再接続して再送信するのは、一つの不確かな結果を二つの可能性に変えてしまうため、三つの選択肢の中で最悪です。次の作業ウィンドウの前に、作業を永続的な所有者を持つものへ移してください。

接続エラーが教えてくれないこと

クライアント側のエラーが説明するのはクライアントです。ソケットが閉じたことを報告するだけで、サーバーがトランザクションをどう扱ったかは分かりません。文はまだ実行中かもしれず、回線が切れる直前にコミットされたかもしれず、セッションが片付けられたときにロールバックされたかもしれません。どれもノート PC には同じメッセージを出します。

決着をつけられるのはサーバーの状態だけです。何かを決める前に、そこを見てください。

作業をサーバー側の所有者に渡す

人の見張りが要らない作業は、データベースのホストに実行を所有させてください。SQL Server Agent は要求時またはスケジュールでジョブを実行し、実行のたびに記録を残すので、ジョブのライフサイクルは VPN セッションから独立します。タスクが必要とする権限だけをジョブの ID に与え、管理者の完全な対話型コンテキストは与えません。そうすればノート PC は作業を開始して結果を読む役になり、作業を生かし続けるプロセスではなくなります。

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Agent が使えるかどうかは、導入したエディションとサービス次第です。これがどこにでもあると決めつけず、自分のプラットフォームが実際に提供する仕組みを使ってください。

データベースの近くのジャンプ ホストは経路を短くし、あるに越したことはありませんが、所有の話は変わりません。ネットワークが終わればセッションも終わります。観察に使い、作業を生かし続けるものにしないでください。

次のセッションが読める記録を残す

ジョブ名か識別子、対象データベース、期待する結果を書き留めてください。その記録があるからこそ、別のセッションや別の人が、エラーには答えられなかった問いに答えられます。なければ、更新のあいまいな記憶だけが残り、確認する手段がありません。

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

履歴は手順ごとの結果と時刻を示すので、単一の成功フラグより役に立ちます。データを変えるタスクには、行数、チェックサム、ジョブが書き込むステータス行といったアプリ側の検証も加えてください。独立した二つの記録があって初めて再試行が安全になり、記録されたジョブ履歴がその一つ目です。

再送信の前に突き合わせる

観察していた接続が消えたら、別の実行を始める前に既存の実行を見つけてください。その手順の結果を読み、作業がコミットされたのか、一部だけ完了したのか、まったく開始されなかったのかを判断します。やみくもな再送信はロードを二重にしたり二度目も途中で失敗したりするため、それから初めてワークフローが定める再試行のルールを適用してください。

永続的な所有者と検査できる結果を保てば、短いアクセス障害は推測ではなく手間になります。それが設計の目的そのものであり、作業はそれを要求した接続より長く生きるべきなのです。