Loading...

ナレッジセンター


SQL Server Management Studio を使用する ePO 4.x データベースの推奨されるメンテナンス プラン
技術的な記事 ID:  KB67184
最終更新:  2013/12/23
評価:


環境

McAfee ePolicy Orchestrator 4.6
McAfee ePolicy Orchestrator 4.5
McAfee ePolicy Orchestrator 4.0

Microsoft SQL Server 2005
Microsoft SQL Server 2008

概要

この記事では、SQL Server Management Studio を使用する ePolicy Orchestrator (ePO) 4.x データベースの推奨メンテナンス プランを説明します。

解決策 1

重要: これらのルーチン タスクには、データを維持してエンジンのパフォーマンスを十分なレベルに保つだけでなく、データをバックアップして障害時のリカバリーを補助する SQL Server メンテナンスの作業が含まれます。本情報は、データベース (DBA) および ePO 管理者のみを対象としています。次の手順は自己責任で実行してください。McAfee では、以下の手順により発生した損害に対して責任を負いません。

バックグラウンド:
SQL Server では、ログ先行書き込みの概念を使用しています。これは、各データの修正操作 (挿入、更新、削除およびインデックス再構築や再編成などその他の操作) がまずメモリ (バッファー プール) からのトランザクション ログ (.LDF)に書き出され、CheckPoint プロセスの一環として定期的にディスク データ ファイル (.MDF) にフラッシュされます。トランザクション ログを使用する主な理由の 1 つとして、ハードウェアの故障や人的ミスなどの障害発生時に大きなデータ損失を起こさずにデータベースを以前の状態に復元できるようにすることが挙げられます。


完全復旧モデル:

完全復旧モデルでは、完全復旧モデルを使用してトランザクション ログのバックアップが実行されると、SQL Server はバックアップしたレコードが「非アクティブ」としてマークされます (ログの切り捨てとも呼ばれます)。このように、新しい操作がトランザクション ログに記録されるときに非アクティブ エントリを上書きすることでスペースを再利用できます。これにより、ログのサイズが大きくなるのを防ぎます。

トランザクション ログのバックアップを定期的に行わないと、利用可能なディスク空き容量をすべて消費するまでトランザクション ログのサイズが増加し続けます。そのため、ePO データベースで完全復旧モデルを使用するように設定する場合は、定期的にトランザクション ログのバックアップを行い、ログのサイズを抑制することが重要です。


単純復旧モデル:

単純復旧モデルでは、CheckPoint が実行されてレコードがディスクにフラッシュされると、SQL Server でトランザクション ログが切り捨てられます。これにより、トランザクション ログ ファイル内のスペースが解放されます。そのため、現在進行中のトランザクション用に十分な利用可能スペースが存在する場合は、事実上、トランザクション ログのサイズは大きくなりません。

これは、単純復旧モデルではトランザクション ログのバックアップという概念は使用されずに、ePO データベースの定期的な完全バックアップのみが行われることを意味しています。障害発生時に実行できるのは、最新の完全バックアップに復旧する方法のみです。最新の完全バックアップ以降に行われた変更はすべて失われます。

多くの Enterprise カスタマーにとって、ePO データベースのトランザクション ログを頻繁にバックアップするという管理のオーバーヘッドが発生する完全復旧モデルよりも、単純復旧モデルを使用する方が適したソリューションとなります (障害発生時に失われる最新の完全バックアップ以降のデータはほとんどがイベント情報であるため)。

このような理由から、ePO データベースには単純復旧モデルを使用することをお勧めしています。

完全復旧モデルを選択する場合は、ePO データベースおよびトランザクション ログの両方の適切なバックアップ計画を策定するようにしてください。SQL Server データベースの「バックアップ計画」についての情報は、この KnowledgeBase の記事には記載されていません。詳細については、SQL Server オンライン ブック(http://msdn.microsoft.com/ja-jp/library/ms130214.aspx) を参照してください。

注意: 複数のデータベースで異なる復旧モデルを使用している場合、復旧モデルごとに異なるデータベース メンテナンス プランを作成できます。この方法で、単純復旧モデルを使用しないデータベースにのみ、トランザクション ログをバックアップする手順を組み込むことができます。


ePO データベース復旧モデルを「単純」に設定する

復旧モデルを「単純」に設定するには、SQL Server Management Studio を開き、以下の手順を実行します。

  1. すべてのプログラム]、[Microsoft SQL Server 2005]、[SQL Server Management Studio]の順にクリックします。
  2. 接続情報を指定して、SQL Server Management Studio にログインします。
  3. ePO4_<サーバー名>]を右クリックして、ePO データベースで利用可能なエントリのリストを開きます。
  4. プロパティ]を選択します。[ePO4_<サーバー名>]のプロパティが表示されます。
  5. オプション]をクリックします。
  6. 復旧モデル]の右にあるドロップダウンの矢印をクリックします。
  7. 単純]を選択します。

データベースの圧縮とそれが推奨されない理由:
ePO データベースの圧縮はできるだけ避けてください。実稼動の SQL Server データベースを圧縮すると、論理的な断片化が発生します (インデックスのリーフ レベルでのページの物理的順序が、ページの論理的順序と一致しないようになります)。そのため、ディスク ヘッドのページ読み込みでページを前後に繰り返し移動する必要が発生するため、出入力操作が増えて、事実上パフォーマンスが低下します。

データ ファイルの圧縮を実行すると、このプロセスで発生する断片化の可能性にかかわらず、データ ファイルの最後のページがファイルの最初に移動されます。

イベントを削除して圧縮を実行した後に、ePO データベースのサイズが大きくなる場合は、エージェントが送信するイベントに対するスペースが必要であることを意味しています。そのため、イベント削除後にデータ ファイルを圧縮しても、ファイル サイズが再び大きくなるだけで、さらに断片化も発生します。スペース使用量の問題が疑われる場合は、ePO イベント フィルターを使用して不要なイベントをフィルタリングすることを検討してください。

注意: 新規イベントの格納用スペースを再度使用しないことがわかっている場合、大量のデータの削除操作 (古いイベントの完全削除など) の実行後に、データ ファイルを圧縮してもかまいません。そうでない場合は、最初の段階で不要なデータがキャプチャされないように、定期的にインデックスの単純な再構築を行い、ePO イベント フィルターを使用して不要なイベントをフィルタリングすることをお勧めします。

重要: イベントをフィルタリングすると、そのイベントを利用して生成されるレポートの内容に直接影響を与えます。日常のレポートに不要であるとわかっているイベントのみがフィルタリングで除外されるようにしてください。古いイベントを完全に削除する前に、ePO データベースをバックアップすることをお勧めします。将来参照できるように、ePO データベースのバックアップを新しい名前でリストアして、その期間のレポートを生成できます (いつでも実行可能です)。

EPOEvents テーブルの上位イベントを表示する方法については、KB52116 を参照してください。

インデックスの再構築と再構成などによってデータベースのメンテナンスが適切に実行される限り、ePO データベースのサイズによりクエリーのパフォーマンスが悪化することはありません。ePO のイベントの完全削除サーバー タスクを使用して古いイベント (3 ヶ月以前のイベントすべて) を定期的に完全削除する場合、データベースのサイズは事実上安定します。そのため、データベースのサイズは削除される古いイベントの量までしか上昇しないことになります。

この KnowledgeBase の記事などに記載されているようにデータベースのメンテナンス プランを適切に設定して、ePO データベースが正常に動作するようにすることが重要です。 


SQL 2005/2008 における ePO データベース用メンテナンス プランを作成する

  1. すべてのプログラム]、[Microsoft SQL Server 2005]、[SQL Server Management Studio]の順にクリックします。
  2. 接続情報を指定して、SQL Server Management Studio にログインします。
  3. SQL Server Management Studio を使用して、サーバー オブジェクト エクスプローラー ウィンドウの[管理]を展開します。
  4. メンテナンス プラン]を右クリックして、メンテナンス プラン ウィザードを選択します。
  5. メンテナンス プランに名前を付けます (例:  ePO データベース メンテナンス プラン)。
  6. 変更]をクリックしてスケジュールを変更します。
    注意: オフピーク タイムに実行されるようにタスクをスケジュール設定します(例: 毎週土曜日 11:00pm に定期タスクを実行)。
     
  7. メンテナンス タスク]で次のオプションを選択し、[次へ]をクリックします。
    - データベースの整合性確認
    - インデックスの再構築
    - データベースのバックアップ (完全)
     
  8. 次の順序でタスクが実行されるように定義し、[次へ]をクリックします。
    - データベースの整合性確認
    - データベースのバックアップ (完全)
    - インデックスの再構築

    注意: これらのタスクが実行される順序は変更可能です。ただし、インデックスの再構築プロセスの前にデータベースのバックアップを行うことをお勧めします。
    再構築プロセスの際に問題が発生した場合に、使用できるデータベースのバックアップ コピーを確保するためです。
     
  9. データベースの整合性確認]タスクを定義します。
    1. ePO データベース[ePO4_<サーバー名>]を選択します。
    2. インデックスを含める]を選択します。
    3. 次へ]をクリックします。
       
  10. データベースのバックアップ (完全)]タスクを定義します。
    1. ePO データベース[ePO4_<サーバー名>]を選択します。
    2. バックアップ場所のパスを入力します。
    3. 次へ]をクリックします。
       
  11. インデックスの再構築]タスクを定義します。
    1. ePO データベース[ePO4_<サーバー名>]を選択します。
    2. オブジェクトに[テーブルとビュー]を指定します。
    3. ページごとの空き領域の比率を変更する]で 10% を選択します。
    4. 次へ]をクリックします。

      注意: インデックスの再構築タスクにより、統計情報が再構築の一部として更新されます (事実上、フル スキャンも実行されます)。そのため、インデックスの再構築後は、統計の更新タスクは必要ありません。
       
  12. レポート オプションの選択]を定義します。
    1. レポートをテキスト ファイルに書き込む]を選択して、目的のフォルダー場所を入力します。
    2. 次へ]をクリックします。
    3. 完了]をクリックします。
注意: ePO データベースが大きい場合、データベース管理者はメンテナンス タスクを監視して、稼働中にタスクが実行されないようにしてください。

解決策 2

実稼動のデータベースが大きい場合、インデックスの再編成と再構築メンテナンス プラン タスクの代わりに、カスタムのインデックスの再構成と再構築スクリプトを使用することをお勧めしています。

これにより、断片化レベルを無視してすべてのオブジェクトを再構築することなく、再構成が必要なオブジェクトと再構築が必要なオブジェクトごとに柔軟に対応することができます。

SQL Server オンライン ブックに従い、次のようにします。
  • 断片化が < 30% 未満の場合は、再編成してください。
  • 断片化が > 30% より大きい場合は、再構築してください。

sys.dm_db_index_physical_stats 動的管理ビュー (DMV) エントリをクエリーして、インデックスの断片化レベルを確認できます。SQL Server オンライン ブックには、上に掲載されている断片化の比率の実現に使用できるサンプルの SQL スクリプトがあります。以下の該当する SQL Server オンライン ブック ドキュメントのリンクにある sys.dm_db_index_physical_stats のトピックを参照してください。

http://msdn.microsoft.com/ja-jp/library/ms188917(SQL.90).aspx  (SQL Server 2005)
http://msdn.microsoft.com/ja-jp/library/ms188917.aspx (SQL Server 2008)

注意:
オンライン ドキュメントの「使用例の D」にサンプル コードがあります。

インデックスの再構成コマンドを実行したら、統計を更新することが重要です。インデックスの再構築とは異なり、統計はインデックスの再構成の一部として自動的に更新されません。上記の SQL Server オンライン ブックの例を基に更新された RebuildReorganizeIndexes-V2.zip 内のスクリプトは、この記事の「添付ファイル」セクションにあります。このスクリプトには、インデックスの再構築操作の後に統計を更新する手順が追加されています。

スクリプトをさらにカスタマイズして、オンラインでのインデックスの再構築を実行するオプションを含めることができます。オンラインでの再構築を行うと、インデックスの再構築中に多くの並列処理を高速で実行するため、高いリソース消費に対応できます。オンラインでのインデックスの再構築は、SQL Server Enterprise Edition で使用できるオプションです。

添付ファイル 1

RebuildReorganizeIndexes-V3_Includes46.zip
2K • < 1 minute @ 56k, < 1 minute @ broadband


このドキュメントを評価する

この記事によって問題が解決されましたか?

ご意見がありましたら以下にご記入ください

Japan - 日本 (Japanese)
© 2003-2013 McAfee, Inc.