目次


これだけはおさえたい DB2 の運用

DB2 運用管理の概要編

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: これだけはおさえたい DB2 の運用

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:これだけはおさえたい DB2 の運用

このシリーズの続きに乞うご期待。

DB2 を動かすための運用

ここでは、DB2 を利用する上で必ず発生する作業である起動・停止や、ログの管理についてご紹介します。

起動・停止

DB2 を稼働させるためには、当然ながらプロセスを起動する必要があります。DB2 では、「インスタンス (プロセス)」が起動と停止の単位となっており、インスタンスの管理ユーザーから操作します。インスタンスの配下には、表をまとめた管理の単位であるデータベースが一つもしくは複数存在します。DB2 でデータを管理する際は、データベースが基本単位になります。
データベースが、SQL を処理するためのメモリーやトランザクション・ログを初期化することを活動化と呼びます。データベースは最初の接続をきっかけに自動的に活動化されます。しかし、データベースの活動化は負荷が高く、応答時間にも影響するので、以下で紹介している手順のように、本番業務を行う環境では DB2 の起動時に ACTIVATE DATABASE コマンドを使用して事前にデータベース活動化を行っておくことをおすすめします。

【起動手順】

  1. OS 起動
  2. DB2 インスタンスの起動 (db2start)
  3. DB2 データベースの活動化 (db2 activate database <DBNAME>)

【停止手順】

  1. クライアント・アプリケーションの停止
  2. 残存している接続の切断 (db2 force applications all) (※)
  3. DB2 データベースの非活動化 (db2 deactivate database <DBNAME>)
  4. DB2 インスタンスの停止(db2stop)

(※) クライアント・アプリケーションからの接続が残存していて、強制切断しても問題が無いことを確認の上で実施する。

DB2 が出力するログのメンテナンス

DB2 は、稼働に伴っていくつかの種類のログを出力します。これらのログの中には容量が増加していき、自動ではメンテナンスされないものもあるため、定期的なログ・メンテナンスの対象としてください。

DB2 を運用する際にメンテナンスするべきログ・ファイルについては、IBM サポートの FAQ「[DB2 LUW] メンテナンスが必要な DB2 関連のログ・ファイル」としてまとめられていますので、リンク先を参照してください。

障害回復のためのバックアップ・リカバリー

バックアップの必要性

データベースにはビジネスに必要なデータが保管されており、万一データが失われてしまうと深刻な影響が生じます。
データが失われる原因には、ディスク障害などの物理障害や、人的ミスやアプリケーションのバグなどの論理障害があります。
さまざまな障害からデータをリカバリーするために、データベースやトランザクション・ログの定期的なバックアップが必要となります。

図 1. バックアップの必要性

リカバリーの基本

DB2 では、アプリケーションが行なうデータの挿入、更新、削除など、データベースへの変更内容をトランザクション・ログと呼ばれるファイルに記録します。トランザクション・ログは、変更されるデータよりも、必ず先にディスクに書き出されます。ある時点のデータ (バックアップ・イメージ) とトランザクション・ログがあれば、データベース・サーバーがダウンした場合でも、データベースを一貫性のある状態に回復することができます。

図 2 は、バックアップ・イメージとトランザクション・ログを用いたリカバリーを理解するためのイメージ図です。
トランザクション 1~4 はコミットが完了し、トランザクション 5 は実行中 (未コミット)、というタイミングで障害が発生して、データベースが破損しています。
この場合、バックアップ・イメージをリストアして、さらに、すべてのトランザクション・ログを適用 (ロールフォワード) していくと、データベースを障害発生直前の状態にリカバリーすることができます。リカバリーされたデータベースには、トランザクション 1~4 の処理は反映されますが、実行中 (未コミット) だったトランザクション 5 の処理は反映されません。
このように、バックアップとトランザクション・ログを用いたリカバリーによって、データベースはデータの整合性を保証しています。

図 2. リカバリーによるデータ整合性の維持

本シリーズ「障害回復のためのバックアップ・リカバリー」の記事では、「具体的にどのようなコマンドでバックアップを取得できるのか」とか「どのようにデータを復元するのか」といった手順について詳しく紹介します。
用語などバックアップ・リカバリーに関わる基礎知識については、developerWorks 記事「簡単! DB2 の運用: 第 5 回 ログと回復管理」をご参照ください。

パフォーマンスの維持

システムがサービスインする時点では、開発作業の一環としてデータベースの応答時間が良好であることを確認します。しかし、時間の経過に伴い、挿入、更新、削除を繰り返すと、応答時間が悪化することがあります。
DB2 ではパフォーマンスを維持するために、以下の運用を行います。

  • 統計情報取得 (RUNSTATS)
  • 再編成 (REORG)

統計情報取得 (RUNSTATS)

統計情報の収集は、データ・アクセスの最適化を行なうための運用作業です。DB2 では、RUNSTATS コマンドを使用して、表データや索引データに関する統計を収集します。収集された統計情報は、システム・カタログ表に格納されます。収集される統計には、表や索引の使用ページ数、表内の行数、列の種類や頻度など、さまざまな種類があります。
SQL ステートメントが実行されると、オプティマイザーはこれらの統計情報を使用して、データにアクセスするにはどのパスを使用したらよいかを判断します。そのため、オプティマイザーが正確な統計情報に基づいてアクセス・プランを選択できるように、統計情報を最新のものに維持することが大切です。統計情報が長期に渡って取得されていない、もしくは一度も取得されていない場合、実際のデータ状況と統計の間の乖離が大きくなり、オプティマイザーが決定するアクセス・プランが適切でない状況が起こりえます。

一般的には、以下のタイミングで実施をおすすめします。

  • データがロードされた後
  • 索引が作成された後
  • 表のデータが再編成 (REORG) された後
  • 表および索引のデータの 10-20%が挿入、更新、削除された後
  • アプリケーションをバインドする前

再編成 (REORG)

再編成は、データベースに格納されたデータの挿入、更新、削除により発生する表データ、索引データのフラグメンテーションを解消するための運用作業です。DB2 では、REORG コマンドを使用して、再編成を行ないます。
フラグメンテーションの解消によって、データ・アクセスの処理効率を向上させ、使用されるディスク・スペースの削減を行なうことができます。表、索引データのフラグメンテーションが多く発生していると、データがまとまって格納された状態ではないため、ディスクの格納効率が下がります。データ・アクセスの際には、本来必要とされるページ数よりも、多くのページを読み込んでしまいます。さらに、表の REORG では、特定の索引順に表データを並び替えることができます。表データが索引順にまとまって格納された状態であると、その索引を使用した範囲検索が行われる場合に、データ・アクセスの効率が良くなり、照会のパフォーマンスが向上します。
表、索引に対して再編成が必要かどうかを検査するには、REORGCHK コマンドを使用します。このコマンドを使用すると、統計情報を基に、再編成を推奨する/しないの結果が出力されます。出力の REORG 列に*が多い表や索引ほど、再編成が推奨されます。

「具体的にどのようなコマンドで RUNSTATS や REORG を実行できるのか」などの詳細については、本シリーズ「パフォーマンス維持のための運用 (REORG と RUNSTATS)」の記事で紹介します。

モニタリング

モニタリングとは、稼働監視や性能情報の収集など、DB2 がどのように稼働しているかを把握するための運用です。例えば稼働監視の一環として、DB2 のプロセスの存在チェックをするスクリプトを定期的に実行することで、データベース処理に不可欠な DB2 のサーバー・プロセスが正常に稼働しているかどうかを自動的にチェックする運用などが挙げられます。もしも、DB2 プロセスの監視を行わないと、データベースに障害が発生しても管理者が把握できず、ユーザーからの問合せで始めて障害の発生がわかるなど、障害への対応が遅れることにつながります。そのため、重要度の高いサービスで利用しているデータベースでは、適切なモニタリングを行うことが非常に重要です。

DB2 のモニタリングは、大きく 2 つのカテゴリーに分けられます。一つ目がデータベースの稼働監視で、このカテゴリーには検知したら何らかの対応が必要になるイベントが分類されます。二つ目は性能情報を中心としたデータベース稼働情報の収集で、こちらはキャパシティ計画や、問題が発生したときの分析に使用します。

データベースの稼動監視

データベースの稼働監視では、データベース・サーバー (筐体) そのものや、DB2 プロセスの障害、重要なリソース (メモリー、ストレージ、トランザクション・ログ) の枯渇などを対象とします。たとえば、DB2 が停止していないかどうかを確認するには、db2sysc プロセスを監視します。
そのほかに、OS やデータベースの重要なイベントを検知できるように、エラーメッセージの監視を行う必要があります。OS の状況・問題については、syslog や errpt (AIX の場合) を監視し、DB2 については管理通知ログを対象とするのが一般的です。

性能情報を中心としたデータベース稼働情報の収集

データベースの稼働情報とは、OS や DB2 がデータベース処理のために行っている、さまざまなアクティビティの詳細を把握するための情報です。CPU やメモリーの使用率のようにリソースの使用傾向を把握するための情報や、SQL の応答時間のような性能情報、DB2 プロセス内部のセッション数のような DB エンジンの活動状況を表す情報など、その内容は多岐にわたります。
これらの情報は、稼働監視のように即時の対応を行うためではなく、長期的なシステムの傾向を把握するために収集します。たとえば、SQL の応答時間が悪化した場合に、過去に収集した正常時のデータと比較することで、現在の状態を正確に評価することができます。また、リソースの使用傾向を長期間にわたって蓄積することで、将来的なリソース拡張の必要性を判断するための基礎資料になります。
OS の稼働情報は Unix/Linux プラットフォームであれば nmon や sar で、Windows プラットフォームであればパフォーマンス・モニターのようなツールで収集するのが一般的です。DB2 の稼働情報は、性能情報を収集するためのモニター表関数と DB2 の活動状況を取得する db2pd コマンドを組み合わせて収集します。「具体的にどのようなコマンドで収集できるのか」とか「見るべきなのはどの項目か」といった実際にモニタリングを設計する上での指針は、本シリーズ「DB2 を "見える化" するためのモニタリング運用」の記事で詳しく紹介します。

GUI ツール:Data Studio のご紹介

DB2 の運用には、通常 DB2 の提供するコマンドを使用しますが、Data Studio を使用することもできます。Data Studio は Eclipse をベースとして GUI でデータベース操作を行うことができるツールです。DB2 10.1 で廃止されたコントロール・センターに置き換わるデータ管理やアプリケーション開発のための環境を提供します。Data Studio のインストールイメージは Web 上で無償公開され、自由にダウンロードして利用することができます。データベース、表スペース、バッファープール、表、索引など各種データベース・オブジェクトの作成や、DB データの参照、投入などの操作を行うことができます。

図 3. IBM Data Studio – 運用管理パースペクティブ画面例

まとめ

この記事では、「これだけはおさえたい DB2 の運用」シリーズの第 1 回として、DB2 の運用において必要な作業の全体像をご説明しました。それぞれの運用作業の詳細については、本シリーズの後続記事にて紹介していきます。
本シリーズが、DB2 システム運用に携わる皆さまのお役に立てると幸いです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=981841
ArticleTitle=これだけはおさえたい DB2 の運用: DB2 運用管理の概要編
publish-date=09052014