もっと危機的なトランザクションログの拡張エラーが発生した（ファイル管理トラブル）：SQL Serverトラブルシューティング（26）（2/2 ページ）

[内ヶ島暢之，ユニアデックス株式会社]

解決方法

　では、再発防止のために、どのように根本的な対策していくべきでしょうか。今回のトラブルは、システムの再起動でひとまず緊急対処できました。しかし、安易に再起動してしまったがために、それ以外のセッションも強制終了することになり、結果として業務システム全般にまで影響を及ぼしてしまいました。

　それでは、どう対処すればよかったのでしょうか。ここからは根本的な原因追及と、「実際には、こうすべきだった」具体的な対策手段を説明します。

　前述した原因追及のタスクで、システムテーブルであるsys.databasesから、トランザクションログのバックアップを阻害していた原因が分かりました。しかし、どのセッションが実際の原因だったのかまでは追求できていません。実際の原因がどのセッションだったかを突き止めるには、「dbcc opentran」と「sys.sysprocesses」の結果を確認します（図19-4）（図19-5）。

図19-4　障害発生中の「dbcc opentran」の結果

図19-5　障害発生中の「sys.sysprocesses」の結果

　図19-4のdbcc opentranの結果から、トランザクションログのバックアップを阻害していたセッションID（SPID）を確認できます。SPIDが「57」のセッションのようです。このSPIDの値を、sys.sysprocessesのspid列から探します。ここから、SPID＝57は「SQL Server Management Studioを使っている」ことが分かりました。

　続いて、判別したアプリケーション／サービスの担当者もしくは業務担当者に、このセッションを強制終了したときの影響範囲を確認します。影響範囲を確認した上で了承を得られたならば、該当するセッションをkillコマンドによって終了させます。

　つまり、（1）該当するセッションの重要度を測り、（2）それを切断可能と確認できた段階で終了し、（3）トランザクションログのバックアップを取得する、という手順になります。なお、今回のトラブル例では、テスト的に実行されていたプログラムのトランザクションが閉じられていなかったことが根本の原因でしたので、結果としては「再起動までは必要なかった」ことになります。

　では、再発防止のための根本的対策として、どんなことを上層部へ報告すべきでしょう。

　まず対策案の軸は、「業務オンライン時間内に原因となったプログラムを実行させない」、もしくは「実行させても、必ず終了させるロジックをアプリケーション側に実装する」となるでしょう。

　過去、筆者が携わったトラブル対策事例では、原因となったアプリケーションが業務担当者の多くが使う「Microsoft Office」だったこともあります。業務担当者がデータ分析業務を行うために、データベースソフトウェアのMicrosoft AccessからSQL Serverに接続して業務を進める、といったシーンです。昨今、リアルタイムなデータ活用やセルフサービスBI（Business Intelligence）が普及してきている背景もあり、上記のように業務担当者自身が業務を進める、あるいはこのように進めたいと考える担当者や企業は珍しくないはずです。

　こういったシーンも踏まえ、データベース／システム管理者としては、業務担当者のPCから直接基幹データベースに接続していることの危険性を指摘し、そのリスクを把握して業務担当者と共有されていなければなりません。最終的には、ネットワークの分離や会社としてのルールをあらためて整える必要もあるでしょう。当然ですが自身としても、SQL Server側のセッション監視を行うようにするといった改善が必要です。

　ちなみに、上記の「危険性を指摘する」とは、止まってはならない基幹データベースのレコードを担当者が直接閲覧／編集できてしまうことに由来する「データ損失のリスク」と、持ち出してしまう、あるいは持ち出されてしまう「データ漏えいの危険性」のことです。今回のトラブル例のように不測の事態を引き起こすリスクと、その対応策も併せて報告し、そして対策していくことが重要です。

「もっと危機的なトランザクションログの拡張エラーが発生した」の場合の解決手順

1. 安易に再起動せず、まずログ／システム情報を取得する。ここでは「sys.databases」と「sys.sysprocesses」「dbcc opentran」を取得すること
2. トランザクションログバックアップを阻害しているセッションを把握し、killコマンドで強制終了する
3. トランザクションログのバックアップを取得する
4. 肥大してしまったトランザクションログファイルを圧縮し、あるべきサイズへ変更（縮小）する
5. （2）で特定したセッションがなぜ原因だったかを分析し、根本的な対処を行う

→この他のファイル管理に関連するトラブルの実例を見る

本トラブルシューティングの対応バージョン：SQL Server 全バージョン

筆者紹介

内ヶ島 暢之（うちがしま のぶゆき）

ユニアデックス株式会社所属。Microsoft MVP Data Platform（2011〜 ）。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を行っていた。2016年4月よりIoTビジネス開発の担当となり、新しい仕事に奮闘中。ストレッチをして柔らかい身体を手に入れるのが当面の目標。

椎名 武史（しいな たけし）

ユニアデックス株式会社所属。入社以来 SQL Serverの評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。