目次


DB2 UDB Stingerとオートノミック・コンピューティング

Comments

はじめに

オートノミック・コンピューティングは、IBM® オンデマンド・ビジネス・モデルの鍵となる分野です。IBM DB2® Universal DatabaseTM (DB2) V8.1では、機能豊富なツールやモニターが数多く実装され、DB2データベースがデータベース管理者(DBA)に依存することなく自己のヘルス状態をモニターすることが可能になりました。DB2 "Stinger"(この記事の公開時点ではwww.ibm.com/db2/stingerからオープン・ベータ版として入手可能)では、ツールセットの再設計、モニターの改良、新しいヘルス・データ検索インターフェースなどにより、現行のオートノミック機能がさらに強化、拡張されています。

この記事は、DB2ヘルス・モニター・センターに慣れ親しんでおり、DB2 Stingerで搭載された新機能を確認しておく価値がある方、これまで試す機会がなかったものの、DB2 V7.2の保守サービス終了が迫っているという事情でやむなくDB2 V8.1へのマイグレーションを検討している方、ならびにIBMが開発を進めてきたオートノミック機能が実際の製品にどのような形で実装されているかについて興味がある方を対象にしています。関心事を問わず、この記事はDB2の現状と今後、およびオートノミック・コンピューティングに対するIBMの基本的な考え方を把握する上で役に立つはずです。

DB2とオートノミック・コンピューティング・イニシアチブ

この記事の目的は、オートノミック・コンピューティングの詳細を網羅することではなく、DB2 Stingerのヘルス・モニターの一部である新しいオートノミック機能といくつかの既存機能について取り上げることです。とはいえ、簡単な背景情報として、あるいは復習の意味でオートノミック・コンピューティングの概要について少し触れておきます。新規および既存のオートノミック機能の有効性を理解するには、オートノミック・コンピューティングを理解することが重要です。それらの機能は、決してDBAに取って代わろうというものではありません(これは本当の話です。ともかく、オートノミック機能に不安を持つDBAの方も、まずは気持ちを楽にしてこれらの新機能を試してみてください)。

オートノミック・コンピューティングの概念は、人間の神経系がどのようにして自己の環境を監視し、調節するのかを考えれば最も理解しやすいでしょう。我々人間は運動を大いに好みますが、折しもこの人体と運動の関係は、オートノミック・コンピューティングの概念を非常によく表しています。

一走りしようとするときは通常、まず早足で歩き始めます。人体は、この時点で動作の活発化を感知し始め、筋肉への酸素供給量を増やすよう要求します。これはもちろん、血流量の増加によって行われます。ゆっくり走り始めると、人体は体温の上昇を抑えるために発汗し始めます。これは、人体が環境がさらに活発化したことを感知し、それを考慮してパラメーター(呼吸数、体温など)を調節しているということです。そして、全速力で走っている間、肺はこのプロセス全体への供給に間に合う速度で酸素を取り込みます。しばらくして走りを止めてしまう人もいますが、これはオートノミックスとは無関係です(「オートノミック・コンピューティング」ではなく、「良識」によるものです)。

上記の例で言いたかったのは、呼吸数の増加や発汗は我々が体に(さらに言えば相互に)命令して行われるのではなく、動的環境に反応して行われるということです。人体が「オートノミック」である(また、それによって人生が楽になっている)ことはこれでおわかりいただけたと思いますが、もしこれらの特性がデータベースの一部であったとしたらどれほど仕事が楽になるか想像してみてください。オートノミック・コンピューティングについてもっと総体的に知りたい方は、この記事の最後にある「参考文献」のセクションに挙げた記事をチェックしてください。

例えば、ソート・ヒープがディスクにスピルするほどの量のソートが行われた場合、パフォーマンスは低下します。ここで、ソートの大部分がディスクにスピルしていることを感知し、その問題をデータベース管理者(DBA)に知らせることができるほどの賢さがデータベースに備わっていたとしたらどうでしょうか。さらに言えば、ディスクへのヒープのスピルがさらに続いた場合には(DBAがセットアップした)スクリプトを起動して、ヒープに割り当てるメモリー量を動的に変更したり、あまりアクティブでないヒープからメモリーを一時的にスチールしたり(DB2 Stingerの新機能)することができたとしたらどうでしょうか。まさにそれがオートノミック・コンピューティングなのです。

オートノミック・コンピューティング・イニシアチブにおけるIBMの目標は、自動化、インテリジェントなアドバイス、学習などを利用してコンピューター・システムへの人間の介入の回数や複雑さを減らすことにより、それらの介入の効果を高めるテクノロジーを提供し、その結果、全体的なTCO(総所有コスト)削減と業務の生産性向上を実現することです。

図1は、オートノミック・コンピューティングの発展段階を示したものです。

図1. オートノミック・コンピューティングの発展段階
図1. オートノミック・コンピューティングの発展段階
図1. オートノミック・コンピューティングの発展段階

個々のソフトウェア・アプリケーションやネットワークであろうと、システム全体であろうと、すべてのコンピューター・リソースが手動制御から自律管理に段階的に発展します。オートノミック・コンピューティングの成熟レベルおよび各レベルの特性についてさらに詳しく知りたい方は、「参考文献」のセクションを参照してください。

現在、DB2のオートノミックスは「予測(Predictive)」(レベル3)の段階にあると言えます。つまり、DB2ヘルス・モニターによってシステムをモニターし、修正を推奨しますが、スクリプトがセットアップされている場合(その場合、DB2はレベル4のオートノミック・システムのように働きます)を除き、例外が見つかっても自動的に対処するわけではありません。

DB2の目標は、ビジネス・ニーズとITインフラストラクチャーをエミュレートした一連の定義済みポリシーにより、DBAがシステムに対して制約と目標を指定できるようにすること、そして最終的には自ら検知して対処するDB2システムを構築することです。

重要な側面の1つとして、オートノミック・コンピューティングはDBAに取って代わるためのイニシアチブではないということを理解しておかなければなりません。断じてそのようなことは起こりません。IBMがこの革新的テクノロジーで行おうとしていることは、DBAが絶えず情報を探すというやり方を変え、DB2が自己監視し、問題の発生をDBAに知らせるようにすることです。率直に言って、DBAはすでにあまりにも多くの仕事を抱えており、将来のデータ・パーシスタンス要件を考えると、この状態を続けることは到底できません。保存/分析/測定の対象となるデータの量が増え続ける中、DBAが一日にこなすべき仕事はすでに山ほどあります。DBAは、その力をイネーブルメント、設計、モデル化などに集中すべきであり、IBMはDB2によってそれを可能にしようとしているのです。

先ほどの走りの例に戻りますが、我々は外出時に体温や足のまめをチェックし続けているわけではありません。もしそれらの状態に異常があれば、何らかの方法で体が警告を発してくれるはずです。

つまり、DB2のシステム・ヘルス診断モデルは、DBAがその時々で各種モニターを実行し、大量のデータを分析して異常の徴候を探すことによって潜在的な問題や既存の問題を見つける(スキル・レベルや直感力はそれぞれ異なるため一貫性がまったくない)というものから、DB2がヘルス状態をモニターし、潜在的な問題や既存の問題が見つかった場合にのみ担当者に通知するというものに変わったということです。

DB2の例外による管理モデルは、ヘルス・モニターによって実装されています。ヘルス・モニターは、モニター環境のセットアップ方法を把握し、モニター対象項目、データの意味、データを関連付ける方法などを知らなければならないというDBAの負担をなくします。モニター対象項目、モニターするタイミング、評価方法、問題の解決方法、可能なアクションはヘルス・モニターが知っています。例外が発生した場合、DBAに通知し(SMTPサーバー、Eメール、ポケットベル、管理通知ログのエントリー、NET SENDメッセージなどにより)、対処方法を指示します。DBAは、DB2 UDB V8をインストールしておくだけで、DB2 UDBによって通知されるまで他の重要な活動を続けることができます。これはすべてTCO削減に役立ちます。

DB2のヘルス・インディケーター

ヘルス・インディケーターは、ヘルス・モニターの基本的な構成要素です。各インディケーターは、特定のオブジェクト(インスタンス、データベース、表スペースなど)のデータベースのヘルス面を示します。

DB2 Stingerでは、3つのタイプのヘルス・インディケーターにより、DB2がモニターするオブジェクト・レベルが4種類(図2を参照)に拡張されています。

図2. DB2がモニターするオブジェクト・レベル
図2. DB2がモニターするオブジェクト・レベル
図2. DB2がモニターするオブジェクト・レベル

DB2 Stingerには、次の3種類のヘルス・インディケーターがあります。

  • 状態ベースのインディケーター: このタイプのインディケーターは、2つ以上の状態を示し、1つは正常、その他はすべて異常を表します。このタイプのインディケーターは、DB2 V8ですでに搭載されています。
  • 集合状態ベースのインディケーター: このタイプのインディケーターはDB2 Stingerの新機能で、異常状態を示すアテンション・アラート(実際は情報状態)を生成します。一連のデータベース・オブジェクトの集合状態を示し、1つは正常、その他はすべて異常を表します。このタイプのインディケーターの例は、特定の表を再編成する必要がある、統計が古くなっている、または連合ニックネームが無効であることの通知などです。

    DB2は、影響を受けるすべてのオブジェクトに関してアラートを生成するのではなく、1つのアラートのみを発行し、そのアラートの状態にあるオブジェクトのリストを別に保存します(それによってメモリー消費を削減します)。
  • しきい値ベースのインディケーター: このタイプのインディケーターは、特定のオブジェクトの統計を評価する公式に基づいており、警告またはアラームしきい値によってそれらの公式の結果を制限します。警告アラートは重大でない状態(システムが最適な状態でないこと)を示します。一方、アラーム・アラートは即時のアクションが必要とされる重大な状態を示します。もちろん、これらの値はDBAが定義することもDB2のデフォルト値を使用することもできます。

DB2 Stingerのほとんどのインディケーターはしきい値ベースであり、図3に示すように、システムのヘルスに関する上限値または下限値に関連付けられています。

図3. しきい値ベースのインディケーター
図3. しきい値ベースのインディケーター
図3. しきい値ベースのインディケーター

例えば、ログ使用率は上限値インディケーターの例です。このタイプのインディケーターは、値が大きくなるにつれて正常から警告、アラームへと状態が変化します。下限値インディケーターは、値が低下するにつれて異常とみなされます(キャッシュ・ヒット率インディケーターなど)。

DB2 Stingerは、いくつかの新しいヘルス・カテゴリー・インディケーターを装備しています(以下に記載)。DB2 Stingerのインディケーターは、全体ではしきい値ベースが18種類、状態ベースが6種類、集合状態ベースが4種類用意されており、11個のカテゴリーに分類されています(これらのヘルス・インディケーターはすべて、『DB2 System Monitor Guide and Reference』に詳述されています)。

  • アプリケーション並行性(デッドロック率など)
  • DBMS(インスタンス操作状態など)
  • データベース(データベース操作状態など)
  • ロギング(ログ使用率など)
  • メモリー(モニター・ヒープ使用率など)
  • パッケージ・キャッシュ、カタログ・キャッシュ、およびワークスペース(パッケージ・キャッシュ・ヒット率など)
  • ソート(ソート・オーバーフロー率など)
  • 表スペース・ストレージ(表スペース使用率など)
  • データベース保守(データベース・バックアップの必要性の識別など。DB2 Stingerで追加されたカテゴリー)
  • 高可用性災害時リカバリー(HADRログ遅延など。DB2 Stingerで追加されたカテゴリー)
  • 連合(ニックネーム状況など。DB2 Stingerで追加されたカテゴリー)

ヘルス・センター、コマンド行プロセッサー(CLP)、またはCベースのAPIにより、オブジェクト・レベルのデフォルトまたは特定のオブジェクトのヘルス・インディケーター設定を構成することができます。例えば、どの方法でも次のようなことを構成することができます。

  • しきい値(警告およびアラーム・レベル)
  • 感度(値が「アラート可能」な状態になってから警告、アラーム、またはアテンション・アラートを生成するまでに要求される最低限の時間。この設定により、使用率などの一時的なスパイクに対してアラートを生成しないようにすることができます。これはDB2 Stingerで追加されたパラメーターです)
  • インディケーターを評価するか、無視するか
  • 警告、アラーム、またはアテンション・アラートに対して実行するアクション(このアクションにはタスクや、DB2またはオペレーティング・システム・ベースのスクリプトを含めることができます)
  • 警告、アラーム、またはアテンション・アラートが生成されたときにスクリプトまたはタスクを実行するかどうか

ヘルス・センター構成インターフェースは、DB2 Stingerの開発に際して、ユーザビリティー・テストが行われ、関連するヘルス・オブジェクトがより適切に分類されるように改良を加えており、より容易に設定が行えるようになりました(図4を参照)。

図4. ヘルス・インディケーター構成ランチパッド
図4. ヘルス・インディケーター構成ランチパッド
図4. ヘルス・インディケーター構成ランチパッド

DB2 Stingerでは、ヘルス・インディケーター構成ランチパッドを使って、ヘルス・インディケーター設定のドリルダウン表示や変更を行うことができます。

図5. ヘルス・インディケーター設定
図5. ヘルス・インディケーター設定
図5. ヘルス・インディケーター設定

通知の構成もヘルス・センター、CLP、またはCベースのAPIで行うことができます。DB2 Stingerでは通知トラブルシューターが追加されており、アラートの生成前に通知が適切に設定され、正しく動作することを確認することができます。

DB2のヘルス関連情報の収集方法

DB2は、構成不可能な事前定義インターバルでヘルス関連情報を収集します(ただし、情報の更新頻度はヘルス・センターで構成できます)。インターバル・レベルになると、ヘルス・モニターは基本スナップショット・モニター(設定は特に必要ありません)、ネイティブ・オペレーティング・システムAPI(ファイル・システム関連インディケーターの場合)、表に保存された統計などを使用してシステムのヘルスを評価します。このデータをリトリーブするとすぐに、収集されたメトリックをヘルス構成設定と比較します。

状態ベースのインディケーターを分析し、結果が異常である場合、アテンション・アラートが生成され、構成されたアクションが実行されます。しきい値ベースのアラートの場合、適切な警告またはアラームのアクションまたはアラート(あるいはその両方)が実行されます。

インターバル・レベルを超えるとヘルス・モニターは「スリープ」状態になり、次のインターバルに達するとウェイクアップします。前のインターバルですでに識別されたアラートが次のインターバルになっても続いている場合、それに対するアラートやアクションのスクリプトは実行されません。しかし、しきい値が警告状態からアラーム状態になった場合、アラーム構成で設定された適切なアクションが正しく実行されます。同様に、アラートがアラーム状態から警告状態に戻った場合もアクションは実行されます。なお、インターバルで警告とアラームの両方のしきい値に違反するような値が返された場合、アラームしきい値のアクションのみが実行されることになります。

図6に、しきい値の違反の結果として実行するアクションをセットアップする場合に使用する新しいDB2 Stingerのインターフェースを示します。新しいインターフェースだけでなく、警告またはアラームのしきい値の違反によって起動できる一連のアクションを定義するための新しいオプションにも注目してください。

図6. しきい値の違反の結果として実行するアクションのセットアップ
図6. しきい値の違反の結果として実行するアクションのセットアップ
図6. しきい値の違反の結果として実行するアクションのセットアップ

どのインディケーターも、一連のヘルス関連データがDB2によって記録されます。一般的なヘルス情報セットは以下のとおりです。

  • 記録値
  • 評価のタイムスタンプ
  • アラートの状態
  • 記録値の決定および最終的にモニター対象オブジェクトのヘルスの決定に使用された公式
  • その他のインディケーター情報(DB2が正常と判断したものなど)
  • 以前に生成されたアラートの履歴

図7は、db2.mon_heap_utilインディケーターの例です。

図7.モニター・ヒープ使用率のインディケーター
図7.モニター・ヒープ使用率のインディケーター
図7.モニター・ヒープ使用率のインディケーター

DB2 Stingerでは、新しい集合状態ベースのインディケーターに対応するために、オブジェクト名、状態、アラートのタイムスタンプ、明細などの集合固有のデータを含む新しいヘルス・データ・セットが追加されています。

DB2 Stingerはまた、アラートの分類に関しても洗練されています。インスタンス、データベース、および表スペースのアラートは「最高重大度ロールアップ」アルゴリズムによって表示され、ヘルス・インディケーターまたはその子オブジェクトのヘルス・インディケーターの既存のアラートのうち、重大度が最も高いものが一目でわかります。

ヘルス・データへのアクセス

アラートやヘルス情報の表示および対処は、様々なインターフェースを使って行うことができます。具体的には、次のものが使用できます。

  • ヘルス・センター
  • Webヘルス・センター
  • コマンド行プロセッサー(CLP)
  • SQLベースの関数
  • CAPI

それでは、それぞれについて見ていきましょう。

ヘルス・センター
ヘルス・センター(図8)は、収集されたDB2ヘルス情報へのフロントエンドとなるグラフィック・インターフェースです。ヘルス・センターは、データベース環境の全般的な状態と現在のアラートをすべて表示します。ヘルス・センターは例外による管理ツールであるため、アラート状態にあるヘルス・インディケーターのみ表示可能です(問題でないもののためにDBAの貴重な労力を割くことにあまり意味があるとは思えません)。

図8.ヘルス・センター
図8.ヘルス・センター
図8.ヘルス・センター

DB2 V8.1.3のヘルス・センターでは、ツールの起動時にすべてのモニター対象インスタンスの接続が強制的に行われるのではなく、左ペインのツリー・ビューでインスタンスのヘルス情報をドリルダウンしたときに接続が行われるように改良されました。また、赤、黄、および緑のフィルターによって問題のないオブジェクトを除去する機能もあります(これらはDB2 V8.1.2で追加された機能です)。

さらに、DB2 Stingerでは、このヘルス・センターに大規模なユーザビリティー・テストを実施した上で、最適な解決策に導く新しい基本インターフェースとより高度なテクノロジーによって書き直されています(これらの新機能については、また後で説明します)。

最も重要な機能強化の1つは、Recommendation Advisorの採用です。DB2 Stingerより前の修正アクションの推奨は、「重み付け」がなく(ある一連のアクションが他より適切なオプションとして推奨されないという点で)、図9に示すように特定のアラートの明細の一部でした。

図9.Stingerより前の修正アクションの推奨
図9.Stingerより前の修正アクションの推奨
図9.Stingerより前の修正アクションの推奨

慣れないDBAの場合、この状況でヘルス・アラートに対処する際にジレンマに陥りかねないことがおわかりになると思います。つまり、ソート・ヒープを増加させる場合とワークロードをチューニングする場合のどちらが良い結果をもたらすのかまでは判断できません。

DB2 Stingerでは、新しいRecommendation Advisorが一連の質問とプリファレンスにより、最適な一連のアクションを推奨することができます。概要パネルでは、生成されたアラートの明細が要約されます。図10を見ればわかるように、アテンション、アラーム、または警告の明細および情報が表示されます。また、例外履歴を表示するオプションもあります。

図10.Recommendation Advisor
図10.Recommendation Advisor
図10.Recommendation Advisor

要件パネルでは、生成されたアラートに関する一連の質問が表示されます(図11は、スピルしたソートのアラートに関する質問がすべて見られるように編集したものです)。

図11.スピルしたソートのアラートの例
図11.スピルしたソートのアラートの例
図11.スピルしたソートのアラートの例

Recommendation Advisorは、質問に対するDBAの回答を考慮に入れて、この問題を解決するのに役立つ一連のアクションを提案します。

図12を見ればわかるように、DB2 Stingerでは、可用性や過去のチューニング操作(例えばDesign Advisorの実行)などの特性に対するDBAのプリファレンスを考慮して、例外を解決するための一連のアクションの形でランク付けされて推奨が提示されます。

図12.ランク付けされた推奨
図12.ランク付けされた推奨
図12.ランク付けされた推奨

DBAは、この推奨パネルから一連のアクションを選択し、問題の解決に取り組みます。図13は、ヘルス・センターによる新しいSORTHEAP値の推奨の例です(推奨についての詳細も表示されます)。

図13.ヘルス・センターによる推奨の例
図13.ヘルス・センターによる推奨の例
図13.ヘルス・センターによる推奨の例

ワークロードをチューニングするオプションを選択した場合、別の一連のアクションが実行されることになり、この場合はDesign Advisorが起動されます(これは、実際には「Show All Recommendations」ボタンがクリックされた場合に表示される推奨の1つです。図11のQuestion 1で、すでにこのツールを使用していることを示したため、この例では表示していません)。

図14.Design Advisorの起動
図14.Design Advisorの起動
図14.Design Advisorの起動

コマンド行が一番使い勝手の良いGUIと思っている方は、図15に示すように、DB2コマンド行プロセッサー(DB2 CLP)でRecommendation Advisorのすべての機能を表示することができます。

図15.DB2 CLPによる推奨の表示
図15.DB2 CLPによる推奨の表示
図15.DB2 CLPによる推奨の表示

CLPによってリトリーブされる情報は、ヘルス・センターに表示される情報と同じです。実際に、推奨は、DB2 Stingerのレコメンデーション・エンジンによってサーバー上で作成され、情報はXML文書として保存されます。ヘルス・センターからこの情報にアクセスした場合、XML文書(CLPが使用するのと同じ文書)が構文解析され、グラフィックに表示されているだけです。

Webヘルス・センター
ヘルス・センターには、DB2 Webツールの一部として提供されるバージョンもあります。これは、ヘルス・センターの「軽量版」と考えることができます。これは、通常はフル機能のヘルス・センターを使用しているユーザーが、通常のアクセス・ポイントから離れているときに使用するためのもので、携帯情報端末(PDA)や携帯電話など、インターネット・ブラウザーに対応したデバイスやメディアで利用することができます。Webヘルス・センターでは、インスタンスとそのデータベース・オブジェクトに関するアラートの表示、アラートの明細とそれに対する推奨の表示、およびCLPベースのコマンドをリモートで入力できるWeb Command Editorへのリンクを行うことができます。

図16.Webヘルス・センター
図16.Webヘルス・センター
図16.Webヘルス・センター

コマンド行プロセッサー(CLP)
ヘルス・ベースの情報は、DB2 CLPでGET HEALTH SNAPSHOTコマンドを使用して検索することもできます。GET HEALTH SNAPSHOTコマンドは、GET SNAPSHOTコマンドとよく似ており、特定のデータベース・パーティション全体に対して使用することができます。このコマンドの構文は、図17に示すとおりです。

図17.GET HEALTH SNAPSHOTの構文
図17.GET HEALTH SNAPSHOTの構文
図17.GET HEALTH SNAPSHOTの構文

ベテランのDBAの多くは、高速で簡単という理由からこの方法でヘルス関連情報を検索します。ヘルス・センターの場合と同じデータが得られますが、それを取得するための構文を知っていなければなりません。

DB2 Stingerでは、このコマンドに新しいキーワードが追加されています。この新しいWITH FULL COLLECTIONオプションを付けた場合、DB2が集合ヘルス・インディケーターに関してモニターしているすべてのオブジェクトに関する情報が、それらのヘルス状態に関係なく返されます。(このオプションを付けない場合、DB2がモニターしている集合オブジェクトが返されるか、あるいは失敗状態となるだけです。)このオプションは、集合ヘルス・インディケーターの唯一の定義レベルであるデータベース・レベルのヘルス・スナップショットのみに有効です。

図18に、このコマンドの出力例を示します。

図18.WITH FULL COLLECTIONオプションを付けた場合のGET HEALTH SNAPSHOTの出力例
図18.WITH FULL COLLECTIONオプションを付けた場合のGET HEALTH SNAPSHOTの出力例
図18.WITH FULL COLLECTIONオプションを付けた場合のGET HEALTH SNAPSHOTの出力例

SQL表関数
また、SQL表関数を使用してヘルス・ベースのDB2情報にアクセスすることもできます。SQL表関数は、DB2 V8.1で初めて採用され、DB2 V8.1.2でヘルス・モニターにも拡張されました。基本的に、この関数ではSQLを使用してスナップショット情報をリトリーブし、その結果を表形式で表示することができます。これは、DBAがCベースのAPIまたはJNIラッパーを使用してプログラムで情報をリトリーブする必要がないという点で便利です。

用意された3種類の表関数で、4種類のモニター対象オブジェクト・タイプすべてのヘルス関連情報を返すことができます。これらの関数は、以下のカテゴリーに分類されます。

  • HEALTH_<object type>_INFO: 指定したオブジェクト・タイプのヘルス・スナップショットのヘッダー情報(最高重大度アラート状態を含む)
  • HEALTH_<object type>__HI: 公式を含むすべてのヘルス・インディケーター
  • HEALTH_<object type>__HI_HIS: 上記の表関数でリストされるすべてのヘルス・インディケーターのすべての履歴

ここで、<object type>_はDBM(データベース・マネージャー)、DB(データベース)、TBS(表スペース)、またはCONT(コンテナー)のいずれかです。

以下の例は、SAMPLEデータベースのdb.spilled_sortsヘルス・インディケーター情報をグローバル・スナップショットとして選択する方法を示しています。

SELECT * from table ( HEALTH_DB_HI ( ‘SAMPLE’, -2 ) ) 
  as HEALTH_DB_HI WHERE HI_ID = 1003

DB2 Stingerでは、以下の新しい関数が追加されています。

  • HEALTH_DB_HIC, HEALTH_DB_HIC_HIS: 集合オブジェクトおよび集合オブジェクト履歴をリストします。
  • HEALTH_HI_REC: 推奨をバイナリー・ラージ・オブジェクト(BLOB)として取得します。 HEALTH_HI_REC(IN SCHEMA_VERSION, IN INDICATOR_ID, IN DBNAME, IN OBJTYPE, IN OBJNAME, IN DBPARTITIONNUM, IN CLIENT_LOCALE, OUT REC_DOCUMENT)

以下の例は、SAMPLEデータベースのすべてのパーティションのdb.spilled_sortsに関する推奨を英語で取得する方法を示しています。

CALL HEALTH_HI_REC (8010600, 1003, ‘SAMPLE’, 2, CAST (NULL as VARCHAR), -2, ‘En_US’, ?)

詳細については、DB2 Stingerの資料を参照してください。

Cベースのアプリケーション・プログラミング・インターフェース
さらに、db2GetSnapshot C APIのSQLM_CLASS_HEALTHクラスまたは SQLM_CLASS_HEALTH_WITH_DETAILクラスを使用して、この情報をプログラムで取得することもできます。

とにかくお試しを

この記事では、DB2のオートノミック機能について十分に取り上げることができませんでしたが、DB2で直ちに使用できるいくつかの強力な機能について説明し、それによってDB2 Stingerのいくつかの新機能の概要をご紹介できたのではないかと思います。

モニター機能についてよく寄せられる質問の1つは、「パフォーマンスへの影響はどうか」ということです。私たちの設計目標は、モニターがワークロードに与える影響を1%以下に抑えることでしたが、この目標はほぼ達成されています。実際のところ、そのターゲット範囲を超える可能性のある主なオートノミック機能は、デフォルトでは有効になっておらず、それらの機能を有効にした場合、パフォーマンス低下の可能性についての通知がDBAに返されます(例えば、DB2 StingerのDB2アクティビティー・モニターがそうですが、説明は他の記事に譲ります)。通知とパフォーマンスの間の1%のトレードオフが許容範囲を超えているという場合には、モニターを無効にすることもできます。

実際、DB2のオートノミック機能は、ベテランであろうと初心者であろうと、また所属する会社の規模に関係なく、すべてのDBAのお役に立ちます。


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=326387
ArticleTitle=DB2 UDB Stingerとオートノミック・コンピューティング
publish-date=06112004