それでは“ダメ”な「トラブル対応例」：SQL Serverトラブルシューティング（1）（1/2 ページ）

連載バックナンバー

　長年「Microsoft SQL Server（以下、SQL Server）」の運用、システム構築、サポートに携わってきた筆者にとって、SQL Serverは「設計や運用でエンジニアに大きな負担が掛からないよう考慮されている」と評価しています。しかし、さまざまな原因でトラブルが発生することもよくあります。

　本連載では、そんなSQL Serverの管理者やエンジニアが「今すぐ解決できる」を主目的に、これまでの経験を生かした「トラブルシューティング」テクニックを余すところなく紹介していきます。なお、本連載で取り上げる項目は、特定のバージョンに依存しないものがほとんどです。最新バージョンであるSQL Server 2016を新たに使う人も、従来のバージョンを運用している方にも隔てなく活用できるノウハウを紹介していく予定です。本連載によって、自身のスキルアップや「トラブルが起きないシステム作り」の一助になれば大変幸いです。

　第1回目の今回は、具体的なSQL Serverのトラブル解決ノウハウを紹介する前に、「“トラブルを適切に対応するため”の心得」を復習することにします。

それでは“ダメ”な「トラブル対応例」

　一般的に、システムトラブルの対応は、「原因追及」「問題対処」「設計」「運用実施」のサイクルを回して実施します（図1）。

図1　トラブル発生から対処までのサイクル

　さらにトラブル発生後の作業の流れを細分化すると、以下のようになります（図2）。

図2　トラブル発生後の対応の仕方

　現場では運用における「問題対処」だけが注目されがちです。しかし、トラブルシューティングは既に「設計段階」から始まっています。トラブルの発生後はユーザーや担当者へのヒアリングやログのチェックを行ってから、対処を検討します。また、その結果を広く共有し、同じ問題でシステムを止めないよう心掛けることが肝心です。

問題がある／それで済ませてはならない「NG対応例」

　「問題のある対応例」を以下に示します。

　現場でのトラブルシューティングは、限られた、しかも短い時間の中で手を打たなければならないシーンが多々あります。短期的に打つ対応策として効果があるものもありますし、直ったならばそれでよいかもしれません。

　しかし、真の原因を理解して対策しなければ、再度発生する可能性があります。問題を先送りにしただけで、リスクは残ったままです。基幹業務で使われるデータベースシステムならば、次はもっと危機的なトラブルに見舞われるかもしれません。

　つまり、トラブルシューティングは「“恒久な対策につながること”を考えて対策する」ことが肝要です。