SQL Server: SQL Server 専門家が教える SQL Server 管理の極意トップ 10
SQL Server 環境の管理作業は、困難になることがあります。この記事では、複雑な管理作業を最小限に抑えて、ストレスを軽減する 10 の方法を紹介します。
Paul S. Randal
多くの企業では、ここ数年の間に IT 部門の規模を縮小しています。その結果、多くのデータベース管理者 (DBA) は、多数の SQL Server データベースを管理しなければならなくなりました。さらに悪いことには、DBA という役割を持った人がいない場合もあります。このような場合は、だれかが不本意ながら DBA の役割を引き受けることになります。また、DBA が消防車のように、危機的な状況に次から次へと対応せざるを得ない状況に陥っていることもあります。このような環境を管理することは、困難で、問題が発生しやすく不安定です。常時ストレスにさらされたり、作業を中断せざるを得ない状況に置かれることを好む人はいないでしょう。
このような状況から抜け出す 1 つの方法は、SQL Server 環境の整備に少し時間を費やして、SQL Server 環境を理解および管理しやすくすることです。私の SQL Server に関するコンサルティングの経験から、SQL Server の DBA が、SQL Server 環境の主導権を握って、危機的な状況が発生する可能性を低減する 10 の方法を紹介します。この一覧は、大まかに言うと重要度が低いものから順に記載してあります。
10. インベントリを実施する
存在すること自体を把握していないデータベースに破損したデータを復元して欲しいという要請を受けたことは何回ありますか。SQL Server データベースは、社内で無造作かつ不規則に増殖します。そのため、DBA チームは、社内にあるデータベースを追跡しきれず、管理されていない状態の SQL Server のインスタンスが発生します。この結果、バックアップが作成されず、修正プログラムが適用されず、セキュリティが適切に確保されず、他の必要な管理タスクのホストで存在が把握されていないデータベースが存在します。
社内に存在していて、あなたの管理下にある SQL Server のインスタンスとデータベースの最新のインベントリを保持することは重要です。SQL Server のインスタンスとデータベースを適切に管理し、必要に応じて統合し、投影とアップグレードの範囲を適宜判断して計画するためには、インベントリの実施が必要不可欠です。インベントリを実施すると、既知のインスタンス (つまり、あなたが管理を引き受けることを認めたインスタンス) の一覧を公開し、社内のさまざまなチームから、その一覧に対して合意を得ることで責任の範囲を限定するのにも役立ちます。また、既知のインスタンスに関するサポート ポリシーを定義して、構成ガイドに従わない限り、新しいインスタンスがサポート対象にならないことを宣言できます。
SQLPing3 や SQLRecon などの単純なツールから、Microsoft Assessment and Planning Toolkit や Quest Discovery Wizard など高度な機能を備えたツールに至るまで、SQL Server のインベントリを作成するのに役立つツールは多数存在します。
9. 構成を標準化する
管理している SQL Server のデータベースとインスタンスの数が絶えず増加している場合は、使用される構成の数も同様に増加していることはご存じでしょう。インスタンスごとに構成の詳細を把握する必要がある場合、複数のインスタンスを効率的に管理するのは非常に困難です。
この場合の問題解決策は、ドライブ文字、サーバーの構成オプション、データベースの設定、データベース メンテナンス、セキュリティ設定などの観点から、可能な範囲で構成を標準化することです。SQL Server 2008 では、ポリシーを定義して施行するのに役立つポリシー ベースの管理機能が導入されました。マイクロソフトの SQL Server テクノロジ スペシャリストである Lara Rubbelke 氏は、Enterprise Policy Management (EPM) Framework を開発しました。このフレームワークを使用すると、SQL Server 2005 と SQL Server 2000 のインスタンスの機能を簡単に拡張できます。EPM Framework は CodePlex から入手できます。図 1 に、EPM Framework のサンプル レポートを示します。
.jpg)
図 1 Enterprise Policy Management Framework のレポート
8. I/O サブシステムを理解する
I/O サブシステムには、SQL Server のインスタンスに影響を及ぼす可能性のある要素がいくつかあります。このような要素とこれらが与えるおそれのある影響は認識しておく必要があります。
- 読み取り/書き込みのスループットとディスク領域の観点から見た I/O サブシステムのキャパシティ。ピーク時のワークロードの要求に対応しながら、システムを拡張することなく、データ ボリュームを拡張できる余裕が必要です。I/O のボトルネックを特定して、データとログ ファイルを別の I/O サブシステムに移動することで、負荷を均等に分散できるようになります。
- RAID のレベルと分割ミラー バックアップやミラーリング/レプリケーション (SQL Server レベルではなく I/O サブシステム レベルで) が可能かどうかという観点から見た I/O サブシステムの冗長性。データとログ ファイルはドライブ障害や他の潜在的な問題から保護する必要があります。多くの場合、これがトレードオフになります。RAID-10 では、RAID-5 より高い冗長性が確保されますが、コストが高くなります。詳細については、ホワイト ペーパー「物理的なデータベース ストレージの設計 (英語)」を参照してください。
- RAID のストライプ サイズ、NTFS アロケーション ユニット/クラスター サイズ、およびパーティション アラインメントの観点から見て、I/O サブシステムが正しく構成されていること。詳細については、ブログ記事「Are your disk partition offsets, RAID stripe sizes, and NTFS allocation units set correctly? (ディスク パーティション オフセット、RAID ストライプ サイズ、および NTFS アロケーション ユニットは正しく設定されていますか、英語)」を参照してください。
7. 独自のメンテナンス プランを作成する
データベース メンテナンスについての講義をするときには、まずはじめに、「データベースを運用環境に配置して放置しないでください」ということを伝えています。インデックスでは時間の経過と共に断片化が進み、その結果、パフォーマンスが低下します。統計は古くなり、不適切なクエリ プランとパフォーマンス低下の原因になります。I/O サブシステムは破損することがあるため、バックアップは、必ず作成する必要があります。
このすべての問題には、ご使用の環境にあるデータベースに適した総合的なメンテナンス プランを作成することで対処できます。カスタマイズしたプランは、ご使用の環境のニーズに十分対応していない汎用的なプランよりもはるかに適切です。私が 2008 年 8 月号の TechNet マガジンで執筆した特集記事「効果的なデータベース メンテナンスのヒント」では、適切なメンテナンス プランの作成方法を紹介しています。独自のメンテナンス プランを作成する出発点としては、Ola Hallengren (英語) で無料で提供されている包括的なスクリプトを使用することをお勧めします。私のクライアントにも、ここのスクリプトを勧めています。
6. システムのセキュリティを確保する
セキュリティの問題を積極的に検出するために時間を費やすことは、事故を回避して、後で事故に対応しなくて済むようにするために必要不可欠です。私が執筆した TechNet マガジンの別の特集記事「SQL Server でよく発生するセキュリティ上の問題とその解決方法」では、最も一般的な 10 個のセキュリティ上の問題とその問題を回避する方法を紹介しています。それから、脆弱性を見つけたら、システムに更新プログラムを適用することもお忘れなく。
5. 開発者と良好な関係を築く
IT 部門は、DBA チームと開発チームの関係に大きな不安を抱えています。多くの場合、この 2 つのチームは、開発納期から SQL Server の設計に関する決定事項に至るまで、お互いの優先順位と懸念事項を理解していません。一般的に、動作とパフォーマンスの問題、展開とサポートに関する責任の範囲について意見の相違が見られます。
開発チームを積極的かつ生産的に巻き込むことで、自分の仕事をスムーズに進められるようになります。相互のニーズを伝える場を設けることもお勧めします (この際、お互いを非難しないようにすることが重要です)。設計のレビュー時には DBA チームのメンバーにも同席してもらい、(チーム間の関係を悪化させるエラーを事前に回避できることを期待して) 運用環境に配置する前にコードのテストを十分に行います。
4. 総合的な障害回復戦略を作成する
インフラストラクチャがどれだけ強固でも、障害発生時には代替計画が必要になります。データの破損、電源異常、火災、事故によるデータの紛失など、さまざまな潜在的な問題を予測することはできません。ですから、このような問題に対処して、正常な状態を回復するためのプランが必要になります。
データベースのダウンタイムとデータの損失に関するソフトウェア使用許諾契約書を定義し、さまざまな種類のデータの損失からデータを回復する方法を計画し、データベースとすべての SQL Server インスタンスが会社のビジネス継続性プランにどのように影響を与えるのかということについて経営陣と話し合います。すべてのデータベースと SQL Server インスタンスの相対的な重要度を特定して、障害回復時の優先順位を付けます。
ページ チェックサム、整合性チェック、SQL エージェントの警告、System Center Operations Manager の警告など、問題が発生したことを把握するのに役立つテクノロジを実装する必要もあります。この障害回復インフラストラクチャは、バックアップ、ログ配布、レプリケーション、データベース ミラーリングなどの機能を使用してデータを保護するのに役立ちます。また、データベース ミラーリングまたはフェールオーバー クラスタリングにより、冗長システムにフェールオーバーできます。マイクロソフトが提供しているホワイト ペーパー「SQL Server 2008 で高可用性を実現する (英語)」および「高可用性と障害回復を実現するための実証済み SQL Server アーキテクチャ (英語)」は、この作業に役立ちます。
3. 定期的にバックアップを作成してテストする
どんなに適切な高可用性と障害回復のプランを用意していても、データベースのバックアップを定期的に作成する作業を避けて通ることはできません。データベースが破壊されたり、致命的な破損が発生した場合にデータベースを復旧する唯一の手段は、前回のバックアップからデータベースを復元することです。ですから、バックアップを作成していないと、重大な結果を引き起こすことになります。バックアップは作成するだけでなく、作成したバックアップを定期的に復元して、必要なときに、バックアップが問題なく機能することを確認しておく必要があります。
詳細については、私が 2009 年に執筆した 2 つの TechNet マガジンの記事「SQL Server のバックアップについて」と「バックアップを使用して障害から復旧する」を参照してください。
2. パフォーマンスを監視して維持する
DBA は、パフォーマンスの調整に多くの時間を費やしていますが、この作業を効率化する方法は多数あります。
- パフォーマンスが変化したかどうかを見極められるようにパフォーマンスの基準を設定します。
- システムを基本要素に分割し、不確定な外部要因の影響を受けることなく、パフォーマンスを測定できるようにします。
- 待機とキューの手法を使用して、パフォーマンスに関する問題を迅速に特定します。
- システムの基本要素、パフォーマンス カウンター、および待機の統計を使用してパフォーマンスを監視します。このようにパフォーマンスを監視すると、パフォーマンスが低下し始めた時点を特定できます。SQL Server 2008 のパフォーマンスのデータ コレクタ機能を使用します。SQL Server 2005 の場合は Performance Dashboard Reports を使用します。
- メンテナンス プランを作成します。
- データベース エンジン チューニング アドバイザー (DTA) を使用したり、動的管理ビュー (DMV) で不足しているインデックスとインデックスの使用状況を確認して、インデックス戦略を綿密に計画および実行します。
1. 情報を得られる場所を把握する
To Do リストの項目は際限なく出てくるので、自力で解決することを諦めて助けを求めるタイミングを見極めることが重要です。自分の限界を認識して、SQL Server のすべてを把握するのは無理だということを受け入れる必要があります。あなたが抱えているタスクや問題を解決するのに手を差し伸べてくれる人がいるときに無理なことに貴重な時間を費やす意味はありません。
SQL Server に関する情報源の最有力候補は SQL Server オンライン ブックです。オンライン ブックはダウンロードしてローカルにインストールすることも、MSDN サイトでオンライン検索することもできます。SQL Server オンライン ブックは、構文を調べるのには最適ですが、複雑な手順に関する質問があったり、特定の問題のトラブルシューティングに取り組んだりしている場合は、オンライン フォーラムに質問を投稿することをお勧めします。MSDN サイトには多数の SQL Server フォーラムがありますが、SQL Server Central (英語) など、人気のコミュニティ サイトもあります。
すぐにサポートを得られる方法としては、Twitter で SQL Server コミュニティにアクセスする方法もあります。私を含む、多くの SQL Server の専門家が監視している #sqlhelp ハッシュタグを付けて質問を投稿してください。
それから、毎年開催されている PASS Community Summit、隔年で開催されている SQL Server Connections、もっと頻繁に開催されている SQL Saturdays など、SQL Server を対象としたカンファレンスに、ぜひ参加してください。SQL Server の専門家が運営しているブログは多数ありますが、そのうちのいくつかのブログにも定期的にアクセスしてみてください。私と同様に MVP 保有者である Thomas LaRock 氏が管理しているブログのランキングから、頻繁に更新されているブログや定期的にアクセスする価値のあるブログを判断することもできます。
この記事で提供した情報量の多さに圧倒されているかもしれませんが、これらの提案に対応するための努力を惜しまなければ、大きなメリットがもたらされます。あなたが管理しているシステムは、よりスムーズに実行されるようになり、自分自身が混沌とした状態から抜け出して、これまでよりも心穏やかな日々を送れるようになります。また、DBA としての熟練度も上げることができます。
.jpg)
Paul S. Randal は SQLskills.com の代表取締役であり、Microsoft Regional Director でもあり、SQL Server MVP でもあります。1999 年から 2007 年までは、マイクロソフトの SQL Server ストレージ エンジン チームに所属していました。また、SQL Server 2005 では DBCC CHECKDB/repair コードを記述し、SQL Server 2008 の開発時にはコア ストレージ エンジンを担当していました。Paul は障害回復、高可用性、およびデータベース メンテナンスの専門家であり、世界中のカンファレンスで定期的に講演を行っています。彼のブログは、SQLskills.com/blogs/paul (英語) で公開しており、Twitter は Twitter.com/PaulRandal (英語) でフォローできます。