| Oracle Enterprise Manager SNMPサポート・リファレンス・ガイド 10gリリース2（10.2） E05922-01 |
|
 戻る |
 次へ |
MIB変数は、2つの異なる用途に使用できます。障害管理に使用する場合、データベース管理者は、短期間における1つの変数の値や比率に表れる大きな変化に注目します。データベース管理者がその変化に気付いた場合は、原因を究明し、必要に応じて訂正できます。MIB変数は、パフォーマンスのチューニングに使用することもできます。この場合は、適切な変数または比率で測定されるベンチマーク・パフォーマンスを設定することが目的です。
パフォーマンス・チューニングにMIB変数を使用する場合は、ある程度確実なパフォーマンスを測定するために、1つの変数について十分な数のインスタンスを集計してください。この章で説明するデータベース・インスタンスのパフォーマンス率の場合は、個別に1,000の統計を集計すれば十分です。これらの比率のグラフ表示を設計する場合、チューニング率の計算に使用された変数の個別のインスタンスが1,000未満のときには、ユーザーに警告することを検討してください。
一般的に、ユーザーの最大の関心は、一定期間におけるパフォーマンス率の変化を監視することにあります。したがって、時間に対するこれらの比率の値の変化を描画する基本的な時系列グラフが、非常に有効です。
データベース・パフォーマンスを測定するMIB変数（およびこれらの変数に基づいた比率）のスカラー値は、データベース・アプリケーションのタイプ、データベースにアクセスするユーザー数および処理されるデータの量によって、著しく変動する可能性があります。これは、この情報を表示する管理アプリケーションの開発者にとっては難題です。スカラー値の全域が収まるように作成されたグラフ要素では、範囲内の低レベルでスカラー値を表示すると、誤解を招く場合があります。データベースのサイズの割に大きな変化であっても、他のデータベースで達成可能なはるかに大きい値に対応するように設計されたグラフに描画すると、わずかな変化に見えるためです。
データ範囲の両端のユーザーに対応するための良策の1つが、データ表示の動的なスケール変更です。このためには、データが特定の値に達したときに、データを測定するグラフのスケールを調整する必要があります。たとえば、ジェット機が離陸してから巡航高度に達するまでの速度を時系列のグラフに描画する場合、離陸時には時速200マイルを上限に設定します。このしきい値に達すると、上限を動的に時速400マイルに調整し、時速400マイルと時速600マイルのしきい値に達した時点で、さらに2回調整するようにします。
今日では処理能力が著しく向上し、Oracleデータベースのサイズの上限が膨大になったため、実際に一部のMIB変数の値が、SNMPで定義された32ビット・カウンタ値の上限と、整数値の上限（4294967295）を超える（ラップアラウンドする）ことがあっても意外ではありません。管理アプリケーションの設計者は、常にインスタンス起動時間（applUpTime）をユーザーに示して、ラップアラウンドが発生しているかどうかを判断するために十分な頻度で変数の値をポーリングするように薦めることで、この問題を適切に回避できます。ラップアラウンドの候補については、30分に最低1回ポーリングすることをお薦めします。
カウンタ変数の値が減少した場合は、データベース・インスタンスが引き続き実行されていても、その値は範囲の上限にラップアラウンドしていると考えられます。ただし、値の変化量が範囲の理論上の上限よりも小さいことを確認するために十分な頻度でポーリングを実行する必要があります。これによって、ラップアラウンドが考慮された値と比率をユーザーに提示できます。
この項では、Oracleデータベース・インスタンスのパフォーマンス・チューニングにおける最も有効な比率について説明します。これらは、Oracleデータベース用の管理アプリケーションの使用を考えている顧客にとって最も関心のあるパフォーマンスの指標です。各比率は、プライベートOracle Database MIBの変数に基づいています。これらの比率は、重要度の順ではなく、アルファベット順に記載されています。
これらの比率の詳細は、使用しているシステムに固有の『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。これらの比率の計算に使用されるMIB変数の詳細は、付録B「Oracle Database MIBの変数の解釈」を参照してください。
トランザクション当たりのブロック変更回数
この比率によって、各トランザクションで実行されるデータ操作言語（DML）の量が測定されます。索引を作成または削除すると、索引ブロックの変更によって増分するため、この値に影響を与えます。
oraDbSysDbBlockChanges / oraDbSysUserCalls
この比率によって、ブロックの読取り率が決まります。ブロック読取り率は、アプリケーション・システムがデータベースを参照する比率の基本的な指標です。通常、この比率で使用される時間単位は1秒です。
(oraDbSysConsistentGets + oraDbSysDbBlockGets)/ time unit
この比率によって、各トランザクションに課されるワーク・データベースの負荷が測定されます。この比率が単独で変動する場合は、アプリケーションの作業負荷に変化があったことをはっきりと示しています。
(oraDbSysDbBlockGets + oraDbSysConsistentGets) / oraDbSysUserCommits
この比率によって、バッファ・キャッシュの効果が測定されます。標準の許容域は、70〜85%です。
(oraDbSysConsistentGets + oraDbSysDbBlockGets - oraDbSysPhysReads) / (oraDbSysConsistentGets + oraDbSysDbBlockGets)
この比率によって、そのインスタンスに対するすべてのワーク・ソースからの作業要求の比率が測定されます。ただし、タイム・ループ構成の行が操作セットとして記録された、あるいはその逆のバージョン変更が加えられたアプリケーション・システム間では、この比率を直接比較できないことに注意してください。配列インタフェースを使用した場合も、この比率に影響を与えます。
(oraDbSysRecursiveCalls + oraDbSysUserCalls)/ time unit
この比率によって、トランザクション当たりのクライアント要求の数が測定されます。トランザクション当たりのコール数は、アプリケーションにおける変化またはアプリケーションの使用方法の変化を検出するために使用できます。この値は、非定型の問合せが増加するにつれて急激に上昇する可能性があります。
oraDbSysUserCalls / oraDbSysUserCommits
この比率によって、データベース・アプリケーション内の問合せとDMLの間のバランスが測定されます。この比率の変化は、索引付けまたはアプリケーションの使用方法に変更があったことを示し、変更の量がわかる場合があります。
oraDbSysDbBlockChanges / (oraDbSysDbBlockGets + oraDbSysConsistentGets)
この比率によって、アプリケーションで読取り一貫性メカニズムを実行する必要のある範囲が測定されます。この接続では、UPDATEまたはDELETE（あるいはその両方）の操作の問合せ処理の部分が読取り一貫性の対象となることを認識しておくことが重要です。
oraDbSysConsistentChanges / oraDbSysConsistentGets
この比率は、長いLONG列を処理するアプリケーション以外では、ほとんどゼロに近くなります。この比率が一定期間に増加した場合は、通常、1つ以上の表でPCTFREEが低すぎる値に設定されています。
oraDbSysTableFetchContinuedRow / (oraDbSysTable FetchRowid + oraDbSysTableScanRows)
この比率が上昇し始めると、リソース使用率も増加することが予想されます。ライブラリ・キャッシュ・ミス率の上昇は、アプリケーションの機能の使用範囲が広がり、以前よりも多くのSQL文とストアド・プロシージャがアクティブになることが原因と考えられます。
oraDbLibraryCacheReloads) / oraDbLibraryCachePins
Oracleバージョン7およびOracleバージョン8では、この比率の変化は、アプリケーションの変化を反映しているか、または共有プールのサイズ調整が必要であることを示している場合があります。また、DDLロード内のマーク変更も、この比率に影響を与えます。
oraDbSysRecursiveCalls / oraDbSysUserCalls
この比率によって、メモリー割当てが測定されます。この比率が1 / 5,000よりも大きい場合は、REDOログ空き領域待機率の低下が止まるまで、REDOログ・バッファを増加する必要があります。
oraDbSysRedoLogSpaceRequests / oraDbSysRedoEntries
この比率によって、全表スキャンから取り出されたすべての行の割合が測定されます。この割合が0（ゼロ）より大幅に上昇し始めた場合は、すぐに他の統計の解釈を見直すことをお薦めします。
oraDbSysTableScanRows / (oraDbSysTableFetchRowid + oraDbSysTableScanRows)
oraDbSysSortsDisks / (oraDbSysSortsMemory + oraDbSysSortsDisks)が、ソート・オーバーフロー率です。この比率によって、一時セグメントを使用しているソート数の割合が算出されます。標準サイズのソートが圧倒的に多い場合の制限環境下では、ソート領域サイズを拡大すると効率がよくなる可能性があります。
oraDbSysSortsDisks / (oraDbSysSortsMemory + oraDbSysSortsDisks)
トランザクション率は、アプリケーション作業の基本的な指標であり、1秒当たりのトランザクション（tps）単位で基準的なOLTPベンチマークに対して測定されます。管理者は、接続ユーザー数の増加に伴ってこの値が減少した場合、またはその逆の場合に、特に注意する必要があります。アプリケーション構造や作業パターンの変化も、この数値に影響を与える場合があります。
oraDbSysUserCommits
この比率によって、インスタンスのもとで実行中のクライアント側のアプリケーションによる作業要求率が測定されます。ただし、クライアントからサーバーにコードが移動した、あるいはその逆のバージョン変更が加えられたアプリケーション・システム間では、この比率を直接比較できないことに注意してください。
oraDbSysUserCalls
この比率は、アプリケーションがそのコンテキスト領域をどの程度効率的に管理しているかを示します。この比率が変化した場合、アプリケーションの変更がその原因である可能性が最も高くなります。使用パターンが変化し、ユーザーが1つのモジュールから他のモジュールへ移動する頻度が増加または減少していることを示している可能性もあります。
共有SQL領域では、この比率を最大に活用することが、Oracleの以前のバージョンほど重要ではなくなりました。それでもこの比率を上げることによってリソース使用を軽減できます。
oraDbSysUserCalls / oraDbSysParseCount
oraDbSysUserRollbacks / (oraDbSysUserCommits + oraDbSysUserRollbacks)が、ユーザー・ロールバック率です。ユーザー・ロールバック率は、アプリケーションのトランザクションが失敗する率を示します。トランザクションのロールバックにはかなりのリソースが使用され、トランザクションの実行に費やされたリソースはすべて無駄になったように見えます。
oraDbSysUserRollbacks / (oraDbSysUserCommits + oraDbSysUserRollbacks)
