データベースの起動に時間がかかる（起動トラブル）：SQL Serverトラブルシューティング（12）

トラブルの実例：データベースサーバでハードウェア障害が発生したので、メンテナンスを行った後で再起動した。データベースのプロセスが立ち上がったことは確認できたが、アプリケーション接続でエラーが発生してしまう（図7-1）。

図7-1　接続エラーメッセージの状況。ここではSQL ServerのCLI管理ツールである「sqlcmd」を利用した

トラブルの原因を探る

　SQL Serverのエラーログを見ると、「エラー18456」が記録されていました。

　エラー18456は、ユーザーがログインに失敗したときに発生するエラーです。その下に、Applicationデータベースのリカバリーが「12％まで完了」した旨のメッセージを確認できることから、「データベースの復旧処理が完了していない」ために発生しているようです（図7-2）。

図7-2　現象発生時のエラーログには、「エラー18456」とデータベースが復旧中である旨の内容が記述されていた

　つまりこのトラブルは、データベースの復旧に時間がかかっており、その時点では復旧処理が完了していないために、「ユーザーからのアプリケーション接続が許可されなかった」ということになります。なお、データベースシステムの仕組み上、前回仕掛かり中のトランザクションが残っていたならば、それらが正常にロールバックされるまで新規ユーザーセッションの受け入れは開始されません。

解決方法

　起動時のデータベースの復旧処理は、データベースシステムとしてデータの整合性を保つために必要なので、省略はできません。最も簡単な対処方法は、SQL Serverの復旧処理が終わるまで待つことです。

　このトラブルは、バッチ処理など大量のデータ処理を1つのトランザクションで実行している最中に、何らかの原因でデータベースが止まってしまった場合によく発生します。これを防ぐには、「バッチ処理の単位を適宜分割して、長時間のトランザクションにならないようにする」ことです。

　この他に、SQL Server 2012以降に実装されている「間接チェックポイント（Indirect Checkpoint）」（*1）の機能を使うことで復旧処理時間を短くできることもあります。ただし、間接チェックポイントを構成すると、通常実行されているトランザクションの性能が落ちる場合があるので少し注意が必要です。「間接チェックポイントを構成してもパフォーマンステストに問題のないことを確認できた場合」、あるいは「再起動時のデータベース復旧処理時間をトランザクション性能より優先したい場合」に利用を検討してください（図7-3）。

図7-3　間接チェックポイントの設定画面。ターゲットの復旧時間を「0」以外に設定すると間接チェックポイントが有効となり、復旧時間の改善に向けてチェックポイントを内部調整するようになる