6 Exadataの監視
6.1 Exadataの監視ツールおよび情報ソースの概要
Exadataシステムのパフォーマンスは、様々なツールおよび情報ソースを使用して監視できます。次の各トピックでは、Exadataの主要なパフォーマンス監視ツールおよび情報ソースを紹介して比較します。
- 自動ワークロード・リポジトリ(AWR)
AWRは、Oracle Databaseに組み込まれている統合パフォーマンス診断ツールです。AWRには、Exadataストレージ・サーバーの構成、正常性および統計情報が含まれます。 - データベース統計および待機イベント
Oracle Databaseは、一連の動的パフォーマンス・ビュー(V$ビューとも呼ばれる)でパフォーマンス情報を提供します。 - Exadataメトリック
Exadataメトリックは、Exadataシステム・ソフトウェアに関連する重要なプロパティまたは値の観測データを記録したものです。 - Exadata Alerts
アラートは、潜在的な問題、実際の問題および管理者が関心を持つその他のイベントに対する注意を喚起します。 - リアルタイム・インサイト
リアルタイム・インサイト機能を使用して、Exadataシステムをリアルタイムで監視できます。 - ExaWatcher
ExaWatcherは、主にオペレーティング・システムおよびネットワーク・インタフェースに焦点を当てて、非常に詳細なシステム統計を収集します。
親トピック: Exadataの監視
6.1.1 自動ワークロード・リポジトリ(AWR)
AWRは、Oracle Databaseに組み込まれている統合パフォーマンス診断ツールです。AWRには、Exadataストレージ・サーバーの構成、正常性および統計情報が含まれます。
AWRは、様々なデータベース動的パフォーマンス・ビューから定期的に情報を収集します。各データ収集は、AWRスナップショットです。AWRレポートには、2つのAWRスナップショット間で取得された統計が表示されます。
AWRは、V$SYSSTAT、V$SYSTEM_EVENT、V$SEGMENT_STATISTICS、V$SQLからのデータベース統計や待機イベントなど、Oracle Databaseに関連する多くの統計データを収集してレポートします。
Oracle Databaseリリース12.1.0.2以上では、AWRはExadataストレージ・サーバーからパフォーマンス統計も収集し、AWRレポートのHTMLバージョンに含めます。したがって、AWRは、Oracle Database統計とExadata Statistics、ストレージ・メトリック、およびすべてのストレージ・サーバーからのアラートを含む包括的で統一されたパフォーマンス情報を提供します。
ノート:
Exadataセクションは、AWRレポートのHTMLバージョンでのみ使用できます。
AWRレポートには、次のExadata固有のセクションが含まれます。
主な利点には、次のものがあります。
- AWRは、Oracle DatabaseメトリックとExadataストレージ・メトリック、およびすべてのストレージ・サーバーからのアラートを含む包括的で統一されたパフォーマンス情報を提供します。
- AWRにより、単純な外れ値（Outlier）の検出および分析が可能になります。
- AWR情報の粒度はカスタマイズ可能で、AWR収集間隔(デフォルトでは1時間ごと)に基づいています。
Exadataストレージ・サーバー統計はストレージ・サーバーによって収集および保持されるため、情報は特定のデータベースまたはデータベース・インスタンスに制限されないことに注意してください。したがって、AWRのストレージ関連の統計には、ストレージ・サーバーで実行されているすべてのデータベースのI/Oが含まれますが、データベース統計はAWRをホストしている特定のインスタンスまたはデータベースに関連しています。
コンテナ・データベース(CDB)を使用している場合、AWRレポートのExadata固有のセクションはルート・コンテナでのみ使用できます。
Oracle Databaseの一部として、AWRは新しい統計および分析で継続的に拡張されています。特定のセクションまたは統計の利用可否は、使用しているOracle Databaseのバージョンによって決まります。
Exadata Server Configuration
AWRレポートのExadata Server Configurationセクションには、関連付けられているすべてのストレージ・サーバーの構成情報(セル・ディスク、グリッド・ディスク、ASMディスク・グループおよびIORM Objective、モデル情報、ソフトウェア・バージョンおよびストレージ情報など)が示されます。この情報を調べることで、システムの動作やパフォーマンスに影響を与える可能性のあるストレージ・サーバー間の構成の違いを簡単に確認できます。
次の例は、Exadata Server Configurationセクションの一部を示しています。この例は、14台のX8-2大容量ストレージ・サーバーを備えたシステムに基づいています。この例では、すべてのサーバーのソフトウェア・バージョンが同じです。ただし、ストレージ情報では、1つのセルには2つのフラッシュ・セル・ディスクが含まれ、他のすべてのセルには4つのフラッシュ・セル・ディスクが含まれていることが示されています。
Exadata Server Health Report
AWRレポートのExadata Server Health Report・セクションには、オフライン・ディスクおよびオープン・ストレージ・サーバーのアラートに関する情報が示されます。
ディスクがオフラインの場合、I/O帯域幅の合計が減り、I/Oパフォーマンスに影響する可能性があります。
アラートは、ストレージ・サーバーの機能およびパフォーマンスに影響する可能性のある重要なイベントを表します。open alertsは、管理者が調査済としてマークしていないアラートです。詳細は、Exadata Alertsを参照してください。
次の例に示すように、AWRレポートにopen alertsがないことが理想です。
次の例は、オフロード・サーバーを起動できなかったことを示すExadata Alertsの詳細を示しています。これは、システムのスマート・スキャンのパフォーマンスに影響します。
Exadata Statistics
AWRには、様々なExadataストレージ・サーバー・コンポーネントの統計(スマートI/O、スマート・フラッシュ・キャッシュ、スマート・フラッシュ・ログ、XRMEMキャッシュ、XRMEMログ、IOリソース・マネージャなど)が含まれます。これには、オペレーティング・システムとセル・サーバー・ソフトウェアの両方のI/O統計が含まれ、これらのI/O統計に対して単純な外れ値分析を実行します。通常、ExadataはI/O操作をすべてのセルおよびすべてのディスクに均等に分散するため、外れ値は潜在的な問題を示している可能性があり、さらに調査する必要があります。いずれかのセルまたはディスクの動作が異なる場合や、より多くの作業を実行している場合は、システム全体のパフォーマンスが低下する可能性があります。
AWRレポートのExadata Statisticsセクションには、次のサブセクションが含まれます。
- Performance Summary
- Exadataリソース統計
- Exadata外れ値サマリー
- Exadata OS統計の外れ値
- Exadataセル・サーバー統計の外れ値
- Exadata外れ値詳細
- Exadata OS統計の上位
- Exadataセル・サーバー統計の上位
- Exadata Smart Statistics
- Smart IO
- Flash Log
- XRMEMログ
- Flash Cache
- XRMEMキャッシュ
- Exadata IO Reasons
- Top IO Reasons by Requests
- Top IO Reasons by MB
- Internal IO Reasons
- Exadata Top Database Consumers
- Top Databases by Requests
- Top Databases by Requests - Details
- Top Databases by Throughput
- Top Databases by Requests per Cell
- Top Databases by Requests per Cell - Details
- Top Databases by Throughput per Cell
- Exadata IO Latency Capping
- Cancelled IOs - Client
- Cancelled IOs - Cells
- Exadata Flash Wear
主なExadata Statisticsの詳細は、Oracle Exadata System Softwareのコンポーネントの監視の対応するトピックを参照してください。
6.1.2 データベース統計および待機イベント
Oracle Databaseは、一連の動的パフォーマンス・ビュー(V$ビューとも呼ばれる)でパフォーマンス情報を提供します。
動的パフォーマンス・ビューには、多くのデータベース統計および待機イベントが含まれます。データベース管理者は、動的パフォーマンス・ビューを使用して、個々のSQL操作およびデータベース・セッションに対して詳細でカスタマイズされた監視を実行できます。動的パフォーマンス・ビューは、自動ワークロード・リポジトリ(AWR)およびその他のOracle Database監視ツール(SQLモニターなど)の主要な情報ソースでもあります。
次の各項では、Exadata固有の情報を含む主な動的パフォーマンス・ビューについて説明します。
- V$SYSSTAT
- V$SESSION
- V$SESSION_EVENT
- V$SYSTEM_EVENT
- V$ACTIVE_SESSION_HISTORY
- V$SQL
- V$SEGMENT_STATISTICS
V$SYSSTAT
V$SYSSTATには、Exadataストレージ・サーバーに関連するI/O統計など、現在のデータベース・インスタンスに関連する様々なシステム全体の統計が含まれます。
たとえば、次の問合せを使用して、Exadataストレージ・サーバーに関連するI/O統計を表示できます。
SQL> SELECT name, value
FROM v$sysstat
WHERE name like '%cell%' or name like 'physical%'
ORDER BY name;これらの統計は、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションにもあります。
V$SESSION
V$SESSIONには、現在アクティブなデータベース・セッションの様々な統計および待機イベントが含まれます。
たとえば、次の問合せを使用して、現在セル・イベントを待機しているセッションの数を示すサマリーを表示できます。
SQL> SELECT event, count(*)
FROM v$session
WHERE event like 'cell%'
AND wait_time = 0 -- session currently waiting
GROUP BY event
ORDER BY count(*) desc;次の問合せは、現在セル・イベントを待機しているセッションのイベント詳細を表示します。
SQL> SELECT event, p1, p2, p3
FROM v$session
WHERE event like 'cell%'
AND wait_time = 0;V$SESSIONのセル待機イベントの場合:
P1列は、セルのハッシュ番号を識別します。V$CELLビューを使用して、セルのハッシュ番号からセルを識別できます。P2列は、ディスクのハッシュ番号を識別します。V$ASM_DISKビューを使用して、ディスクのハッシュ番号からディスク名を識別できます。
V$SESSION_EVENT
V$SESSION_EVENTは、セッション別のイベントの待機情報を示します。
たとえば、次の問合せを使用して、現在のセッションの待機イベントのサマリーを表示できます。この問合せの出力を調べることで、Exadataストレージ・サーバー・イベントの待機時間と、データベース内の他のイベントの待機時間を比較できます。
SQL> SELECT event, total_waits, time_waited_micro, time_waited_micro/decode(total_waits, 0, null, total_waits) avg_wait_time
FROM v$session_event
WHERE wait_class != 'Idle'
AND sid = userenv('SID')
ORDER BY time_waited_micro desc;V$SYSTEM_EVENT
V$SYSTEM_EVENTは、イベントの待機合計に関するシステム全体の情報を示します。
次の問合せを使用して、現在のデータベース・インスタンスの起動以降の待機イベントのサマリーを表示できます。
SQL> SELECT event, total_waits, time_waited_micro, time_waited_micro/decode(total_waits, 0, null, total_waits) avg_wait_time
FROM v$system_event
WHERE wait_class != 'Idle'
ORDER by time_waited_micro desc;V$SYSTEM_EVENTの情報は、AWRレポートの待機イベント統計セクションに含まれています。
V$ACTIVE_SESSION_HISTORY
V$ACTIVE_SESSION_HISTORYは、システム上のアクティブ・セッションの履歴を保持します。ここでのアクティブの定義は、CPUを使用しているか、アイドル状態でない待機イベントを待機していることです。セッションごとに、V$ACTIVE_SESSION_HISTORYには、SQL実行計画や待機イベントの詳細(Exadataストレージの相互作用に関する情報など)など、セッションの実行内容に関する多くの情報が含まれます。
たとえば、次の問合せを使用して、過去5分間のレイテンシが10ミリ秒を超えるセル・ブロックの読取りを表示できます。
SQL> SELECT sample_time, p1, p2, time_waited
FROM v$active_session_history
WHERE event = 'cell single block physical read'
AND wait_time = 0 -- currently waiting
AND sample_time > sysdate - 5/1440 -- past 5 minutes
AND time_waited > 10000
ORDER by time_waited desc;AWRレポートのアクティブ・セッション履歴(ASH)レポート・セクションは、V$ACTIVE_SESSION_HISTORYに基づいています。Oracle Databaseには、より詳細なアクティブ・セッション履歴(ASH)レポートも用意されています。
V$SQL
V$SQLおよび関連ビュー(V$SQLAREA、V$SQLAREA_PLAN_HASH、V$SQLSTATS、V$SQLSTATS_PLAN_HASHなど)には、データベース・インスタンスで処理されたSQL文の情報および統計が含まれます。
V$SQLおよび関連ビューには、Exadataストレージの相互作用に関する情報を含む次の列が含まれます。
PHYSICAL_READ_BYTES— SQLによって読み取られたバイト数PHYSICAL_READ_REQUESTS— SQLによって発行された読取りリクエスト数PHYSICAL_WRITE_BYTES— SQLによって書き込まれたバイト数PHYSICAL_WRITE_REQUESTS— SQLによって発行された書込みリクエスト数IO_CELL_OFFLOAD_ELIGIBLE_BYTES— Exadataストレージ・サーバーへの条件のオフロードの対象となるバイト数IO_CELL_OFFLOAD_RETURNED_BYTES— スマート・スキャンによって返されたバイト数IO_INTERCONNECT_BYTES— データベースとストレージ・サーバーの間で交換されたバイト数IO_CELL_UNCOMPRESSED_BYTES— 読み取られた非圧縮バイト数(非圧縮バイトは解凍後のサイズ)OPTIMIZED_PHY_READ_REQUESTS— Exadata Smart Flash Cacheで対応された読取りリクエスト数、またはストレージ索引または列キャッシュのために回避された読取りリクエスト数
次の例は、Exadataのオフロード処理のパフォーマンス・データを表示する問合せを示しています。この出力は、SALES表をスキャンする問合せに焦点を当てています。この出力は、SALES表のすべてのデータ(約5 GB)がオフロード処理の対象であったことを示しています。この場合、オフロード処理により、問合せで5385.75 MBのI/Oが実行されたにもかかわらず、ネットワークを介して417.65 MBのデータのみがデータベース・ホストに送信されました。
SQL> SELECT sql_text,
io_cell_offload_eligible_bytes/1024/1024 offload_eligible_mb,
io_cell_uncompressed_bytes/1024/1024 io_uncompressed_mb,
io_interconnect_bytes/1024/1024 io_interconnect_mb,
io_cell_offload_returned_bytes/1024/1024 cell_return_bytes_mb,
(physical_read_bytes + physical_write_bytes)/1024/1024 io_disk_mb
FROM v$sql
WHERE UPPER(sql_text) LIKE '%FROM SALES%';
SQL_TEXT OFFLOAD_ELIGIBLE_MB IO_UNCOMPRESSED_MB IO_INTERCONNECT_MB CELL_RETURN_BYTES_MB IO_DISK_MB
---------------------------- ------------------- ------------------ ------------------ -------------------- –---------
select count(*) from sales 5283.06 5283.06 520.34 417.65 5385.75V$SQLの情報は、AWRレポートのSQL統計セクションに表示されます。
V$SEGMENT_STATISTICS
V$SEGMENT_STATISTICSには、セグメントごとの統計が含まれます。セグメント・レベルの統計は、Exadataストレージから最適化読取りを実行中の表または索引などの特定のオブジェクトの検出に使用できます。
optimized physical readセグメント統計は、Exadata Smart Flash Cacheから読み取られたオブジェクトの読取りリクエスト数、またはストレージ索引や列キャッシュを使用して回避された読取りの読取りリクエスト数を記録します。optimized physical writes統計は、Exadata Smart Flash Cacheに最初に送信されたオブジェクトの書込みリクエスト数を記録します。このような書込みリクエストは、後でレイジー方式でディスクに同期し、キャッシュ領域を解放できます。
次の例の問合せは、Exadataストレージからの1000を超える最適化読取りに関連付けられているオブジェクトを表示します。同様の問合せを使用して、ごく少数の最適化読取りに関連付けられているオブジェクトを特定できます。
SQL> SELECT object_name, value
FROM v$segment_statistics
WHERE statistic_name='optimized physical reads'
AND value>1000
ORDER BY value;V$SEGMENT_STATISTICSの情報は、AWRレポートのセグメント統計セクションに表示されます。
親トピック: Exadataの監視ツールおよび情報ソースの概要
6.1.3 Exadataメトリック
Exadataメトリックは、Exadataシステム・ソフトウェアに関連する重要なプロパティまたは値の観測データを記録したものです。
Exadataメトリックには、ほとんどのExadataコンポーネントの詳細な統計が含まれます。ほとんどのメトリックは、ストレージ・サーバーとそのコンポーネント(Flash Cache、セル・ディスク、グリッド・ディスクなど)に関連しています。ストレージ・サーバーのメトリックを使用すると、Exadataストレージ・サーバーのパフォーマンスを詳細に監視できます。
メトリックには次のタイプがあります。
-
累積メトリックは、メトリックが作成されてから、またはサーバーが再起動されてから一定期間累積される統計です。
たとえば、
CL_IO_RQ_NODATAは、データを返さなかったI/Oリクエストの合計数です。 -
即時メトリックには、メトリックの観測時点の現在の値が含まれます。
たとえば、
CL_MEMUTは、サーバー上の現在使用されている合計物理メモリーの割合です。 -
率メトリックは、値を経時的に観測する、計算された統計です。
たとえば、
N_NIC_KB_TRANS_SECは、サーバーのイーサネット・インタフェースを介して転送される1秒当たりのKB数です。
一部のメトリックでは、Small IOとLarge IOが区別されます。このようなメトリックの場合、Small IOは、サイズが128 KB以下のI/Oを意味します。Large IOは、サイズが128 KBを超えるものです。
デフォルトでは、メトリック収集は1分間隔で実行されます。デフォルト収集のメトリック観測データは、最初にメモリーに記録され、後でディスクベースのリポジトリに書き込まれます。ほとんどのメトリックについては、デフォルトで、メトリック観測が7日間保持されます。ただし、一部のキー・メトリックは、最長で1年間保持されます。どの場合でも、サーバーでストレージ領域不足が検出されると、履歴メトリック観測が自動的にパージされます。
Oracle Exadata System Software 22.1.0以降では、オプションでファイングレイン・メトリックを構成できます。ファイングレイン・メトリックを有効にするには、1から60秒までの収集間隔を指定する必要があります。ファイングレイン収集に含めるメトリックを選択することもできます。ファイングレイン・メトリック収集は、リアルタイム・メトリック・ストリーミングの基盤です。そのため、外部のメトリック収集およびビジュアライゼーション・プラットフォームへの効率的なストリーミングをサポートするために、ファイングレイン・メトリックはメモリーにのみ記録されます。
Exadataのメトリック観測データを表示するための基本的な方法としてCellCLIのLISTコマンドを使用できます。メトリックの表示を参照してください。ただし、Exadataのメトリックは各Exadataサーバー内で管理されるため、システム全体のビューを取得するには、その他の方法でメトリック観測データを収集して相互に関連付ける必要があります。
関連項目
親トピック: Exadataの監視ツールおよび情報ソースの概要
6.1.4 Exadataアラート
アラートは、潜在的な問題、実際の問題および管理者が関心を持つその他のイベントに対する注意を喚起します。
アラートには、情報アラート、警告アラート、クリティカル・アラートの3つのタイプがあります。
メトリックの観測データは、格納されているしきい値と自動的に比較されます。メトリックが指定したしきい値を超えると、アラートが自動的に生成されます。メトリックは、警告およびクリティカルのしきい値に関連付けることができます。メトリック値が警告のしきい値を超えると、警告アラートが生成されます。メトリックがクリティカルのしきい値を超えると、クリティカル・アラートが生成されます。
Exadata管理者は、ほとんどのメトリックに対して警告およびクリティカルのしきい値を指定できます。事前設定されたしきい値もいくつかあります。たとえば、環境温度の組込みのしきい値があります。温度が低すぎる場合や高すぎる場合は、アラートが自動的に生成されます。
一部のシステム条件および状態の変更により、情報アラートが生成されることがあります(サーバー・シャーシが開いているなど)。より深刻なシステム・エラーおよび状態の変更により、警告アラートまたはクリティカル・アラートが生成されることもあります(ハード・ディスク・デバイスのディスク・エラーが報告されているなど)。
このしきい値およびアラートのシステムを使用すると、管理者は、他の関心のあるイベントに対する認識を維持しながら、最も重要なイベントに集中できます。
CellCLIコマンドを使用して、Exadata Alertsおよびしきい値を管理および表示できます。また、電子メールおよびSNMPを使用してアラート通知を構成することもできます。アラート情報はAWRレポートにも含まれます。
Exadataメトリックと同様に、アラートは各サーバーで個別に管理されます。
関連項目
親トピック: Exadataの監視ツールおよび情報ソースの概要
6.1.5 リアルタイム・インサイト
リアルタイム・インサイト機能を使用して、Exadataシステムをリアルタイムで監視できます。
Oracle Exadata System Software 22.1.0以降では、リアルタイム・インサイトにより、インフラストラクチャで次のことが可能になります:
-
特定のメトリックをファイングレインとして分類し、ファイングレイン・メトリックを毎秒収集できます。
-
プッシュ(アップロード)またはプル(ダウンロード)伝送モデルを使用して、ユーザー定義の場所にリアルタイムでメトリック観測データをストリーミングします。
関連項目
親トピック: Exadataの監視ツールおよび情報ソースの概要
6.1.6 ExaWatcher
ExaWatcherは、主にオペレーティング・システムおよびネットワーク・インタフェースに焦点を当てて、非常に詳細なシステム統計を収集します。
ExaWatcherは各サーバーで個別に実行され、オペレーティング・システム・ツールおよびユーティリティ(iostat、vmstat、mpstat、topなど)を使用してサーバーおよびネットワーク関連のデータを収集します。また、cellsrvstatを使用してストレージ・サーバー統計を収集します。
この情報は非常に詳細で、ほとんどのオペレーティング・システム統計が5秒間隔で収集されます。分析のためにExaWatcherから統計を抽出するには、GetExaWatcherResults.shスクリプトを使用できます。GetExaWatcherResults.shの出力には、主要統計の小さいサブセットのチャートも含まれます。
ExaWatcherは通常、詳細なデバッグに使用されます。したがって、比較のためにExaWatcherデータのベースラインを保持することをお薦めします。
6.2 Exadataの監視に関するガイドライン
情報ソースに関係なく、ワークロードの重要な期間(ピーク期間、月末または年末の処理、パッチ適用またはアップグレードの前など)をカバーする様々なパフォーマンス・データ・ソースのベースライン収集を保持することをお薦めします。
ベースライン情報により、パフォーマンスの低下が発生したときに既知の正常な状態と比較できます。このような比較は、変更を特定し、さらに分析を進めるのに役立ちます。
ベースライン・データには、AWRデータ(AWRエクスポートまたはAWRベースラインを使用)、ExadataメトリックおよびExaWatcherの収集を含める必要があります。スマート・スキャンに依存するデータ・ウェアハウス・ワークロードについては、主要なSQL文に対するSQLモニター・レポートの収集も保持することをお薦めします。
親トピック: Exadataの監視
6.3 Oracle Exadata System Softwareのコンポーネントの監視
- Exadata Smart Flash Cacheの監視
- XRMEMキャッシュの監視
- PMEM Cacheの監視
- Exadata Smart Flash Logの監視
- XRMEMログの監視
- PMEM Logの監視
- スマートI/Oの監視
- I/Oリソース管理(IORM)の監視
- セル・ディスクI/Oの監視
- グリッド・ディスクの監視
- ホスト・インターコネクトのメトリックの監視
ホスト・インターコネクトのメトリックは、セル・ストレージにアクセスするホストのI/O転送に関する情報を提供します。
親トピック: Exadataの監視
6.3.1 Exadataスマート・フラッシュ・キャッシュの監視
Exadata Smart Flash Cacheでは、アクセス頻度の高いデータがフラッシュ・ストレージに保持される一方、ほとんどのデータはコスト効率に優れたディスク・ストレージに保持されます。キャッシングは自動的に発生し、ユーザーや管理者による作業は必要ありません。Exadata Smart Flash Cacheでは、データの使用状況、アクセス・パターンおよびアクセスされるデータのタイプを示すデータベースからのヒントに基づいて、キャッシュすることが最も有益なデータをインテリジェントに決定できます。
Exadata Smart Flash Cacheは、ライトスルー・モードまたはライトバック・モードで動作できます。ライトスルー・モードでは、データベース書込みは最初にディスクに対して行われ、その後Flash Cacheに移入されます。Exadata Smart Flash Cacheがライトスルー・モードで動作している状態でフラッシュ・デバイスに障害が発生した場合、データはすでにディスク上にあるため、データが失われることはありません。
ライトバック・モードでは、データベース書込みは最初にフラッシュ・キャッシュに対して行われ、その後ディスクに対して行われます。ライトバック・フラッシュ・キャッシュの内容は再起動後も保持されるため、キャッシュへの移入に必要なウォームアップ時間が不要になります。書込み中心のアプリケーションは、フラッシュによって提供される高速レイテンシを利用することで、ライトバック・キャッシングのメリットを得ることができます。同じブロックへの複数の書込みが、ディスクへの書込みの前にキャッシュに吸収された場合にも、ディスクI/Oの量が減少します。ただし、ライトバック・モードの使用中にフラッシュ・デバイスで障害が発生した場合、ディスクにまだ永続化されていないデータは失われるため、ミラー・コピーからリカバリする必要があります。このため、データベース・ファイルを保護するために高冗長性(3方向ミラー化)とともにライトバック・モードを使用することをお薦めします。
Exadata Smart Flash Cacheでは、頻繁にアクセスされるデータ・ブロックに高速I/Oを提供することでOLTPパフォーマンスを向上させます。また、頻繁にスキャンされるデータおよび一時セグメントを自動的にキャッシュし、列キャッシュ・ストレージを提供し、大量分析問合せおよび大量ロードのパフォーマンスを最適化するその他の機能を有効にすることで、意思決定支援システム(DSS)のパフォーマンスを向上させます。
Extreme Flash (EF)ストレージ・サーバーでは、すべてのデータがフラッシュに存在します。したがって、通常のキャッシュにはExadata Smart Flash Cacheは必要ありません。ただし、この場合、それでもExadata Smart Flash Cacheではデータを列形式でキャッシュし、様々な分析問合せを最適化する列キャッシュをホストするために使用されます。
Exadata Smart Flash Cacheに関連するパフォーマンスの問題では、通常、データベースでcell single block physical readのレイテンシが増加します。ただし、cell single block physical readに関連して不定期の長いレイテンシがあることは、必ずしもExadata Smart Flash Cacheのパフォーマンスの問題を示すわけではなく、単に読取りリクエストがExadata Smart Flash Cacheを使用して対応されなかったことを示す場合があります。
6.3.1.1 AWRを使用したExadataスマート・フラッシュ・キャッシュの監視
自動ワークロード・リポジトリ(AWR)には、Exadata Smart Flash Cacheに関連する多くの情報が含まれています。Exadata Smart Flash Cacheに関する情報を含むAWRレポートの主要なセクションの説明と例を次に示します。管理者は、AWRレポートのこれらのセクションを確認することで、Exadata Smart Flash Cacheの動作状況を把握できます。
Flash Cache ConfigurationおよびFlash Cache Space Usage
Flash Cache Configurationセクションには、キャッシング・モード(ライトスルーまたはライトバック)、ステータスおよび全体のサイズなどのサマリー情報が含まれます。Flash Cache Space Usageセクションには、Exadata Smart Flash Cacheの領域使用量に関するサマリー統計が表示されます。
次の例は、Exadataスマート・フラッシュ・キャッシュがすべてのセルにライトバック・モードで構成されており、そのサイズが各セルに約24 TBであることを示しています。この例では、フラッシュ・キャッシュ領域使用量セクションに次の情報が表示されます。
-
実質的に、すべてのExadataスマート・フラッシュ・キャッシュ領域が各セルで使用されています。
-
割り当てられた領域の約70%がOLTPに使用されています。OLTPは通常、ブロック・モード読取りを使用してデータベース・バッファ・キャッシュに読み取られるデータです。OLTPデータは、さらに次のように分類されます。
-
クリーン・データは、キャッシュへの読取り後に変更されていないデータです。出力例では、各キャッシュ内の領域の約26%にクリーンなOLTPデータが含まれています。
-
キャッシュされたOLTPデータが更新され、更新がプライマリ・ストレージ(通常はハード・ディスク・ドライブ)に書き込まれる場合、データは同期済として分類されます。出力例では、各キャッシュ内の領域の約23%にクリーンなOLTPデータが含まれています。
-
キャッシュされたOLTPデータが更新されたが、更新がプライマリ・ストレージに書き込まれていない場合、データはフラッシュされていないと分類されます。出力例では、各キャッシュ内の領域の約22%にフラッシュされていないOLTPデータが含まれています。
-
-
キャッシュ領域の約20%が大量の書込みを吸収するために使用されています。
-
キャッシュの約6%がスキャン操作をサポートしています。
-
キャッシュの約2%が列キャッシュのサポートに使用されています。
-
この場合、キープ・オブジェクトによってキャッシュ領域は占有されません。キープ・オブジェクトは、
CELL_FLASH_CACHEstorage句オプションをKEEP設定とともに使用してExadata Smart Flash Cacheのデフォルトのキャッシュ・ポリシーをオーバーライドするデータベース・セグメント(表、パーティションなど)です。
図6-4 AWRレポート: フラッシュ・キャッシュ構成およびフラッシュ・キャッシュ領域使用量
Flash Cache User Reads
Flash Cache User Readsセクションには、データベース・クライアントからの読取りリクエスト、読取りスループットおよび読取り効率に関する情報が表示されます。この統計には、Exadata Smart Flash Cacheの様々な領域に対するI/Oが表示されます。
- OLTP - ブロック・リクエストに関連します
- Scan - スキャン・リクエストに関連します
- Columnar - 列キャッシュ・リクエストに関連します
- Keep - KEEPプールに対する読取りリクエストに関連します
図6-5 AWRレポート: フラッシュ・キャッシュのユーザー読取り
Flash Cache User Writes
Flash Cache User Writesセクションには、ライトバック・モードのExadata Smart Flash Cacheの書込みリクエストおよび書込みスループットに関する情報が表示されます。
このセクションで、First WritesはExadata Smart Flash Cacheに書き込まれる新しいデータを示し、OverwritesはExadata Smart Flash Cacheで上書きされるデータを示します。First Writesでは、追加のFlash Cache・メタデータの書込みも必要です。Overwritesは、ライトバック・モードでExadata Smart Flash Cacheを使用することにより回避されたディスク書込みを表します。
図6-6 AWRレポート: フラッシュ・キャッシュのユーザー書込み
Flash Cache User Writes - Large Writes
Flash Cache User Writes - Large Writes セクションには、ライトバック・モードのExadata Smart Flash Cacheによって吸収および拒否されたLarge Writesリクエストに関する情報が表示されます。
図6-7 AWRレポート: フラッシュ・キャッシュのユーザー書込み - 「大規模の書込み」
Flash Cache Internal Reads
Flash Cache Internal Readsセクションには、Oracle Exadata System Softwareによって実行されるExadata Smart Flash Cacheからの読取りが表示されます。これらの統計は、Exadata Smart Flash Cacheがライトバック・モードの場合に移入されます。
ディスク・ライターIO詳細列は、Exadataスマート・フラッシュ・キャッシュからハード・ディスク・デバイスにデータを永続化するために実行される内部I/Oに関連しています。これらの列には、フラッシュからの読取りおよびハード・ディスクへの様々なカテゴリの書込みが表示されます。
図6-8 AWRレポート: フラッシュ・キャッシュの内部読取り
Flash Cache Internal Writes
Flash Cache Internal Writesセクションには、Oracle Exadata System Softwareによって実行されるExadata Smart Flash Cacheへの書込みが表示されます。内部書込みは、キャッシュ読取りミスに応じてExadata Smart Flash Cacheに移入されるI/Oです。
この統計には、Exadata Smart Flash Cacheがライトバック・モードのときに発生したメタデータ書込みも含まれます。メタデータ書込みは、キャッシュラインを使用して新しいデータをキャッシュするときに発生します。
図6-9 AWRレポート: フラッシュ・キャッシュの内部書込み
親トピック: Exadata Smart Flash Cacheの監視
6.3.1.2 データベース統計および待機イベントを使用したExadataスマート・フラッシュ・キャッシュの監視
次の表では、Exadata Smart Flash Cacheの監視に役立つ様々なデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
cell flash cache read hits |
キャッシュで対応された読取りリクエストの数 |
cell flash cache read hits for smart IO |
キャッシュで対応されたスマートIOに対する読取りリクエストの数 |
cell flash cache read hits for temp IO |
キャッシュで対応された一時IOに対する読取りリクエストの数 |
cell flash read hits for controlfile reads |
キャッシュで対応されたデータベース制御ファイルに対する読取りリクエストの数 |
cell overwrites in flash |
ディスクに書き込まれていなかったExadataスマート・フラッシュ・キャッシュの既存のキャッシュラインを上書きした書込みリクエストの合計数。実際には、ライトバック・モードを使用して保存されるディスクI/Oの量です。この統計はミラー書込みが1回行われるたびに増分されます。 |
cell partial writes in flash |
Exadataスマート・フラッシュ・キャッシュとディスクの両方に書き込まれた書込みリクエストの合計数。データの一部はフラッシュに書き込まれ、残りはディスクに書き込まれました。この統計はミラー書込みが1回行われるたびに増分されます。 |
cell writes to flash cache |
Exadataスマート・フラッシュ・キャッシュに完全に書き込まれた書込みリクエストの合計数。この統計はミラー書込みが1回行われるたびに増分されます。 |
cell writes to flash cache for temp IO |
Exadataスマート・フラッシュ・キャッシュによって吸収された一時セグメントに対する書込みリクエストの数 |
physical read IO requests |
データベースによって発行された物理読取りリクエストの数。 |
physical read requests optimized |
Exadataスマート・フラッシュ・キャッシュを使用して対応された読取りリクエストと、ストレージ索引または列キャッシュを使用することによって回避された読取りリクエストの合計数。 |
physical read total bytes |
読取りがストレージ・サーバーにオフロードされたかどうかに関係なく、データベースによって発行された読取りの合計I/Oバイト数。 |
physical read total bytes optimized |
Exadataスマート・フラッシュ・キャッシュから読み取られたバイト数と、ストレージ索引または列キャッシュを使用して回避されたバイト数の合計。 |
physical read total IO requests |
すべてのアクティビティ(アプリケーション、バックアップ、リカバリおよびその他のユーティリティを含む)に対してデータベースによって発行された読取りリクエストの合計数。 |
physical write IO requests |
データベースによって発行された物理書込みリクエストの数。 |
physical write total bytes |
すべてのアクティビティに対してデータベースによって発行された書込みの合計IOバイト数。 |
physical write total bytes optimized |
Exadataスマート・フラッシュ・キャッシュに書き込まれた合計バイト数。これらの書込みはレイジー方式でディスクに同期されます。 |
physical write total IO requests |
すべてのアクティビティ(アプリケーション、バックアップ、リカバリおよびその他のユーティリティを含む)に対してデータベースによって発行された書込みリクエストの合計数。 |
次の表では、Exadata Smart Flash Cacheの監視に役立つデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
cell single block physical readイベントのレイテンシは、通常、読取りがExadata Smart Flash Cacheで対応されたかどうかを示します。レイテンシが長ければ長いほど、リクエストがExadata Smart Flash Cacheで対応されなかった可能性が高くなります。
| 待機イベント | 説明 |
|---|---|
cell list of blocks physical read |
この待機イベントは、リカバリ中またはバッファのプリフェッチ中(複数の単一ブロック読取りの実行ではない)に発生します。これは、リカバリの一環として変更する必要があり、データベースに対してパラレルで読み取られるデータベース・ブロックを監視するために使用されます。
この待機イベントは、セルの |
cell list of blocks read request |
これは |
cell multiblock physical read(セルの複数ブロックの物理読込み) |
この待機イベントは、マルチブロック・データベース読取りのすべてのI/Oの実行に要した時間を表します。
この待機イベントは、セルの |
cell multiblock read request |
これは |
cell single block physical read(セルの単一ブロックの物理読込み) |
この待機イベントは、単一ブロック・データベースI/Oの実行に要する時間を表します。
この待機イベントは、セルの 2022年5月のOracle Databaseリリース更新以降(バージョン19.15.0.0.220419、21.6.0.0.220419以降)、この待機イベントには、Exadataスマート・フラッシュ・キャッシュからのI/Oやリモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用したデータベースI/Oは含まれなくなりました。 |
cell single block physical read: flash cache |
この待機イベントは、Exadata Smart Flash Cacheから単一ブロック・データベースI/Oの実行に要する時間を表します。
この待機イベントは、2022年5月のOracle Databaseリリース更新で導入され、Oracle Databaseバージョン19.15.0.0.220419、21.6.0.0.220419以降に存在します。以前は、 |
cell single block read request |
これは、単一ブロック・データベースI/Oに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示されます。待機イベントが終了すると、プレースホルダは適切な待機イベント(通常は |
cell interconnect retransmit during physical read |
この待機イベントは、単一ブロック読取りまたはマルチブロック読取りのI/Oの再転送中に表示されます。 |
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。
親トピック: Exadata Smart Flash Cacheの監視
6.3.1.3 Exadataメトリックを使用したExadataスマート・フラッシュ・キャッシュの監視
Exadata Smart Flash Cacheに関連するExadataメトリックは、Exadataストレージ・サーバーの、objectType=FLASHCACHEであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
例6-1 フラッシュ・キャッシュのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なFlash Cacheのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = FLASHCACHE
FC_BYKEEP_DIRTY "Number of megabytes unflushed for keep objects on FlashCache"
FC_BYKEEP_OLTP "Number of megabytes for OLTP keep objects in flash cache"
FC_BYKEEP_OVERWR "Number of megabytes pushed out of the FlashCache because of space limit for keep objects"
FC_BYKEEP_OVERWR_SEC "Number of megabytes per second pushed out of the FlashCache because of space limit for keep objects"
FC_BYKEEP_USED "Number of megabytes used for keep objects on FlashCache"
FC_BY_ALLOCATED "Number of megabytes allocated in flash cache"
FC_BY_ALLOCATED_DIRTY "Number of megabytes allocated for unflushed data in flash cache"
FC_BY_ALLOCATED_OLTP "Number of megabytes allocated for OLTP data in flash cache"
FC_BY_DIRTY "Number of unflushed megabytes in FlashCache"
FC_BY_STALE_DIRTY "Number of unflushed megabytes in FlashCache which cannot be flushed because cached disks are not accessible"
FC_BY_USED "Number of megabytes used on FlashCache"
FC_COL_BYKEEP_USED "Number of megabytes used for keep objects in Columnar FlashCache"
FC_COL_BY_USED "Number of megabytes used in Columnar FlashCache"
FC_COL_IO_BYKEEP_R "Number of megabytes read from Columnar FlashCache for keep objects"
FC_COL_IO_BYKEEP_R_SEC "Number of megabytes read per second from Columnar FlashCache for keep objects"
FC_COL_IO_BY_R "Number of megabytes that were read from Columnar FlashCache"
FC_COL_IO_BY_R_ELIGIBLE "Number of megabytes eligible to read from Columnar FlashCache"
FC_COL_IO_BY_R_ELIGIBLE_SEC "Number of megabytes per second eligible to read from Columnar FlashCache"
FC_COL_IO_BY_R_SEC "Number of megabytes per second that were read from Columnar FlashCache"
FC_COL_IO_BY_SAVED "Number of megabytes saved by reads from Columnar FlashCache"
FC_COL_IO_BY_SAVED_SEC "Number of megabytes saved per second by reads from Columnar FlashCache"
FC_COL_IO_BY_W_POPULATE "Number of megabytes that are population writes into Columnar FlashCache due to read miss"
FC_COL_IO_BY_W_POPULATE_SEC "Number of megabytes per second that are population writes into Columnar FlashCache due to read miss"
FC_COL_IO_RQKEEP_R "Number of requests read for keep objects from Columnar FlashCache"
FC_COL_IO_RQKEEP_R_SEC "Number of requests read per second for keep objects from Columnar FlashCache"
FC_COL_IO_RQ_R "Number of requests that were read from Columnar FlashCache"
FC_COL_IO_RQ_R_ELIGIBLE "Number of reads eligible for Columnar FlashCache"
FC_COL_IO_RQ_R_ELIGIBLE_SEC "Number of reads per second eligible for Columnar FlashCache"
FC_COL_IO_RQ_R_SEC "Number of requests per second that were read from Columnar FlashCache"
FC_COL_IO_RQ_W_POPULATE "Number of requests that are population writes into Columnar FlashCache due to read miss"
FC_COL_IO_RQ_W_POPULATE_SEC "Number of requests per second that are population writes into Columnar FlashCache due to read miss"
FC_IO_BYKEEP_R "Number of megabytes read from FlashCache for keep objects"
FC_IO_BYKEEP_R_SEC "Number of megabytes read per second from FlashCache for keep objects"
FC_IO_BYKEEP_W "Number of megabytes written to FlashCache for keep objects"
FC_IO_BYKEEP_W_SEC "Number of megabytes per second written to FlashCache for keep objects"
FC_IO_BY_DISK_WRITE "Number of megabytes written from flash cache to hard disks"
FC_IO_BY_DISK_WRITE_SEC "Number of megabytes per second written from flash cache to hard disks"
FC_IO_BY_R "Number of megabytes of small reads (OLTP) from flash cache"
FC_IO_BY_R_ACTIVE_SECONDARY "Number of megabytes for active secondary reads satisfied from flash cache"
FC_IO_BY_R_ACTIVE_SECONDARY_MISS "Number of megabytes for active secondary reads not satisfied from flash cache"
FC_IO_BY_R_ACTIVE_SECONDARY_MISS_SEC "Number of megabytes per second for active secondary reads not satisfied from flash cache"
FC_IO_BY_R_ACTIVE_SECONDARY_SEC "Number of megabytes per second for active secondary reads satisfied from flash cache"
FC_IO_BY_R_DISK_WRITER "Number of megabytes read from flash cache by disk writer"
FC_IO_BY_R_DISK_WRITER_SEC "Number of megabytes per second read from flash cache by disk writer"
FC_IO_BY_R_DW "Number of megabytes of large reads (DW) from flash cache"
FC_IO_BY_R_DW_SEC "Number of megabytes of large reads (DW) per second from flash cache"
FC_IO_BY_R_MISS "Number of megabytes of small reads (OLTP) from disks because some of the requested data was not in flash cache"
FC_IO_BY_R_MISS_DW "Number of megabytes of large reads (DW) from disks because some of the requested data was not in flash cache"
FC_IO_BY_R_MISS_DW_SEC "Number of megabytes of large reads (DW) per second from disks because some of the requested data was not in flash cache"
FC_IO_BY_R_MISS_SEC "Number of megabytes of small reads (OLTP) per second from disks because some of the requested data was not in flash cache"
FC_IO_BY_R_SEC "Number of megabytes of small reads (OLTP) per second from flash cache"
FC_IO_BY_R_SKIP "Number of megabytes read from disks for IO requests that bypass FlashCache"
FC_IO_BY_R_SKIP_FC_THROTTLE "Number of megabytes read from disk for IO requests that bypass FlashCache due to heavy load on FlashCache"
FC_IO_BY_R_SKIP_FC_THROTTLE_SEC "Number of megabytes read per second from disk for IO requests that bypass FlashCache due to heavy load on FlashCache"
FC_IO_BY_R_SKIP_LG "Number of megabytes read from disk for IO requests that bypass FlashCache due to the large IO size"
FC_IO_BY_R_SKIP_LG_SEC "Number of megabytes read per second from disk for IO requests that bypass FlashCache due to the large IO size"
FC_IO_BY_R_SKIP_NCMIRROR "Number of megabytes read from disk for IO requests that bypass FlashCache as the IO is on non-primary, non-active secondary mirror"
FC_IO_BY_R_SKIP_SEC "Number of megabytes read from disks per second for IO requests that bypass FlashCache"
FC_IO_BY_W "Number of megabytes written to FlashCache"
FC_IO_BY_W_DISK_WRITER "Number of megabytes written to hard disks by disk writer"
FC_IO_BY_W_DISK_WRITER_SEC "Number of megabytes per second written to hard disks by disk writer"
FC_IO_BY_W_FIRST "Number of megabytes that are first writes into flash cache"
FC_IO_BY_W_FIRST_SEC "Number of megabytes per second that are first writes into flash cache"
FC_IO_BY_W_LG_CHINT "Number of megabytes used for large writes to flash cache due to cache hint"
FC_IO_BY_W_LG_DTAGE "Number of megabytes used for data aging large writes to flash cache"
FC_IO_BY_W_LG_MRCV "Number of megabytes used for media recovery large writes to flash cache"
FC_IO_BY_W_METADATA "Number of megabytes that are flash cache metadata writes"
FC_IO_BY_W_METADATA_SEC "Number of megabytes per second that are flash cache metadata writes"
FC_IO_BY_W_OVERWRITE "Number of megabytes that are overwrites into flash cache"
FC_IO_BY_W_OVERWRITE_SEC "Number of megabytes per second that are overwrites into flash cache"
FC_IO_BY_W_POPULATE "Number of megabytes that are population writes into flash cache due to read miss"
FC_IO_BY_W_POPULATE_SEC "Number of megabytes per second that are population writes into flash cache due to read miss"
FC_IO_BY_W_SEC "Number of megabytes per second written to FlashCache"
FC_IO_BY_W_SKIP "Number of megabytes written to disk for IO requests that bypass FlashCache"
FC_IO_BY_W_SKIP_FC_THROTTLE "Number of megabytes written to disk for IO requests that bypass FlashCache due to heavy load on FlashCache"
FC_IO_BY_W_SKIP_FC_THROTTLE_SEC "Number of megabytes written per second to disk for IO requests that bypass FlashCache due to heavy load on FlashCache"
FC_IO_BY_W_SKIP_LG "Number of megabytes written to disk for IO requests that bypass FlashCache due to the large IO size"
FC_IO_BY_W_SKIP_LG_SEC "Number of megabytes written per second to disk for IO requests that bypass FlashCache due to the large IO size"
FC_IO_BY_W_SKIP_NCMIRROR "Number of megabytes written to disk for IO requests that bypass FlashCache as the IO is on non-primary, non-active secondary mirror"
FC_IO_BY_W_SKIP_SEC "Number of megabytes written to disk per second for IO requests that bypass FlashCache"
FC_IO_ERRS "Number of IO errors on FlashCache"
FC_IO_RQKEEP_R "Number of read requests for keep objects from FlashCache"
FC_IO_RQKEEP_R_MISS "Number of read requests for keep objects which did not find all data in FlashCache"
FC_IO_RQKEEP_R_MISS_SEC "Number of read requests per second for keep objects which did not find all data in FlashCache"
FC_IO_RQKEEP_R_SEC "Number of read requests per second for keep objects from FlashCache"
FC_IO_RQKEEP_R_SKIP "Number of read requests for keep objects that bypass FlashCache"
FC_IO_RQKEEP_R_SKIP_SEC "Number of read requests per second for keep objects that bypass FlashCache"
FC_IO_RQKEEP_W "Number of requests for keep objects which resulted in FlashCache being populated with data"
FC_IO_RQKEEP_W_SEC "Number of requests per second for keep objects which resulted in FlashCache being populated with data"
FC_IO_RQ_DISK_WRITE "Number of requests written from flash cache to hard disks"
FC_IO_RQ_DISK_WRITE_SEC "Number of requests per second written from flash cache to hard disks"
FC_IO_RQ_R "Number of small reads (OLTP) satisfied from the flash cache"
FC_IO_RQ_REPLACEMENT_ATTEMPTED "Number of requests attempted to find space in the flash cache"
FC_IO_RQ_REPLACEMENT_DW_FAILED "Number of times that client DW IOs failed to find a replacement buffer"
FC_IO_RQ_REPLACEMENT_DW_SUCCEEDED "Number of times that client DW IOs succeeded in finding a replacement buffer"
FC_IO_RQ_REPLACEMENT_FAILED "Number of requests failed to find space in the flash cache"
FC_IO_RQ_REPLACEMENT_OLTP_FAILED "Number of times that client OLTP IOs failed to find a replacement buffer"
FC_IO_RQ_REPLACEMENT_OLTP_SUCCEEDED "Number of times that client OLTP IOs succeeded in finding a replacement buffer"
FC_IO_RQ_R_ACTIVE_SECONDARY "Number of requests for active secondary reads satisfied from flash cache"
FC_IO_RQ_R_ACTIVE_SECONDARY_MISS "Number of requests for active secondary reads not satisfied from flash cache"
FC_IO_RQ_R_ACTIVE_SECONDARY_MISS_SEC "Number of requests per second for active secondary reads not satisfied from flash cache"
FC_IO_RQ_R_ACTIVE_SECONDARY_SEC "Number of requests per second for active secondary reads satisfied from flash cache"
FC_IO_RQ_R_DISK_WRITER "Number of requests read from flash cache by disk writer"
FC_IO_RQ_R_DISK_WRITER_SEC "Number of requests per second read from flash cache by disk writer"
FC_IO_RQ_R_DW "Number of large reads (DW) satisfied from the flash cache"
FC_IO_RQ_R_DW_SEC "Number of large reads (DW) per second satisfied from the flash cache"
FC_IO_RQ_R_MISS "Number of small reads (OLTP) that did not find all data in flash cache"
FC_IO_RQ_R_MISS_DW "Number of large reads (DW) that did not find all data in flash cache"
FC_IO_RQ_R_MISS_DW_SEC "Number of large reads (DW) per second that did not find all data in flash cache"
FC_IO_RQ_R_MISS_SEC "Number of small reads (OLTP) per second that did not find all data in flash cache"
FC_IO_RQ_R_SEC "Number of small reads (OLTP) per second satisfied from the flash cache"
FC_IO_RQ_R_SKIP "Number of requests read from disk that bypass FlashCache"
FC_IO_RQ_R_SKIP_FC_THROTTLE "Number of requests read from disk that bypass FlashCache due to heavy load on FlashCache"
FC_IO_RQ_R_SKIP_FC_THROTTLE_SEC "Number of requests read from disk per second that bypassed FlashCache due to heavy load on FlashCache"
FC_IO_RQ_R_SKIP_LG "Number of requests read from disk that bypass FlashCache due to the large IO size"
FC_IO_RQ_R_SKIP_LG_SEC "Number of requests read from disk per second that bypass FlashCache due to the large IO size"
FC_IO_RQ_R_SKIP_NCMIRROR "Number of requests read from disk that bypass FlashCache as the IO is on non-primary, non-active secondary mirror"
FC_IO_RQ_R_SKIP_SEC "Number of requests read from disk per second that bypass FlashCache"
FC_IO_RQ_W "Number of requests which resulted in FlashCache being populated with data"
FC_IO_RQ_W_DISK_WRITER "Number of requests written to hard disks by disk writer"
FC_IO_RQ_W_DISK_WRITER_SEC "Number of requests per second written to hard disks by disk writer"
FC_IO_RQ_W_FIRST "Number of requests that are first writes into flash cache"
FC_IO_RQ_W_FIRST_SEC "Number of requests per second that are first writes into flash cache"
FC_IO_RQ_W_LG_CHINT "Number of large writes to flash cache due to cache hint"
FC_IO_RQ_W_LG_DTAGE "Number of data aging large writes to flash cache"
FC_IO_RQ_W_LG_MRCV "Number of media recovery large writes to flash cache"
FC_IO_RQ_W_METADATA "Number of requests that are flash cache metadata writes"
FC_IO_RQ_W_METADATA_SEC "Number of requests per second that are flash cache metadata writes"
FC_IO_RQ_W_OVERWRITE "Number of requests that are overwrites into flash cache"
FC_IO_RQ_W_OVERWRITE_SEC "Number of requests per second that are overwrites into flash cache"
FC_IO_RQ_W_POPULATE "Number of requests that are population writes into flash cache due to read miss"
FC_IO_RQ_W_POPULATE_SEC "Number of requests per second that are population writes into flash cache due to read miss"
FC_IO_RQ_W_SEC "Number of requests per second which resulted in FlashCache being populated with data"
FC_IO_RQ_W_SKIP "Number of requests written to disk that bypass FlashCache"
FC_IO_RQ_W_SKIP_FC_THROTTLE "Number of requests written to disk that bypass FlashCache due to heavy load on FlashCache"
FC_IO_RQ_W_SKIP_FC_THROTTLE_SEC "Number of requests written to disk per second that bypass FlashCache due to heavy load on FlashCache"
FC_IO_RQ_W_SKIP_LG "Number of requests written to disk that bypass FlashCache due to the large IO size"
FC_IO_RQ_W_SKIP_LG_SEC "Number of requests written to disk per second that bypass FlashCache due to the large IO size"
FC_IO_RQ_W_SKIP_NCMIRROR "Number of requests written to disk that bypass FlashCache as the IO is on non-primary, non-active secondary mirror"
FC_IO_RQ_W_SKIP_SEC "Number of requests written to disk per second that bypass FlashCache"次の追加詳細に注意してください。
-
Exadata Smart Flash Cacheの領域は、キャッシュラインと呼ばれるチャンクで内部的に管理されます。
FC_BY_ALLOCATEDは、Flash Cache内のキャッシュラインに割り当てられている領域の量(MB)を表します。値がFlash Cacheのサイズに近い場合、Flash Cacheは満杯です。 -
FC_BY_USEDは、Flash Cache内のデータが占有している領域の量(MB)を表します。OLTPなどのワークロードについて、OLTP書込みではキャッシュラインのごく一部しか使用されないため、FC_BY_USED値をFC_BY_ALLOCATEDよりもずっと小さい値にすることができます。OLTPキャッシュラインで使用される合計量は、FC_BY_ALLOCATED_OLTPによって追跡されます。 -
_DWで終わる名前を持つ様々なFlash Cache・メトリックは、大規模な読取り操作を追跡します。これらの操作は通常、データ・ウェアハウス・ワークロードに関連付けられています。これらの各メトリックには、通常OLTP操作に関連付けられているSmall Reads操作を追跡する対応するメトリックがあります。合計数を取得するには、大きい読取りメトリック値を対応する小さい読取りメトリック値に追加します。たとえば、Flash Cacheで対応された読取りの合計数を取得するには、
FC_IO_RQ_R_DWをFC_IO_RQ_Rに追加します。
親トピック: Exadata Smart Flash Cacheの監視
6.3.1.4 Exadataスマート・フラッシュ・キャッシュを監視する際の注意事項
読取りレイテンシの増加
Exadata Smart Flash Cacheに関連して発生する可能性のある問題は、特にcell single block physical read待機イベントで、データベースの読取りレイテンシの増加として示される傾向があります。通常、レイテンシが増加するのは、読取りがExadata Smart Flash Cacheで対応されず、ハード・ディスクに対して発行された場合です。
次の場合は、読取りリクエストがExadata Smart Flash Cacheで対応されないことがあります。
-
必要なデータがExadata Smart Flash Cacheにない場合。
この場合、リクエストはFlash Cache missesとして記録され、このことはAWRレポートのFlash Cache User ReadsセクションにMissesの増加として示されます。この場合には、通常、移入書込みも増加し、このことはAWRレポートのFlash Cache Internal Writesセクションで示されます。
データベースでは、
physical read IO requestsまたはphysical read total IO requestsと比較して、cell flash cache read hitsの数が減少する場合があります。 -
そのデータがExadata Smart Flash Cacheの対象でない場合。
キャッシュ効率を最大化するために、I/Oリクエストがデータベースからストレージ・サーバーに送信されるとき、データをExadata Smart Flash Cacheにキャッシュする必要があるかどうかを示すヒントが含められます。
データがキャッシングの対象でない場合は、AWRレポートのFlash Cache User Reads - Skips・セクションに、対応するI/Oと、読取りが対象でなかった理由が表示されます。考えられる理由には、次のものがあります。
- グリッド・ディスクのキャッシング・ポリシーが
noneに設定されています。 - データベース・セグメントが、
CELL_FLASH_CACHE NONEストレージ・オプションを使用して構成されています。 - I/Oタイプおよび状況によって、キャッシュが妨げられています。たとえば、I/OがRMANバックアップ操作に関連し、かつ、ハード・ディスクがビジーでないためなどです。このことが発生する頻度が高い場合は、AWRレポートの上位IO理由セクションでそれがわかります
- グリッド・ディスクのキャッシング・ポリシーが
場合によっては、Exadata Smart Flash Cacheの動作に明らかな違いがなくても、cell single block physical readのレイテンシが増加することがあります。これは、特にハード・ディスクでのI/O負荷の増加が原因である可能性があります。
cell single block physical readで不定期の長いレイテンシがある(通常はcell single block physical readヒストグラムにロング・テールとして表示される)ことは、必ずしもExadata Smart Flash Cacheの問題を示すわけではなく、単にデータがハード・ディスクから読み取られたことを示すことがあります。
スキップ書込み
ライトバック・モードでExadata Smart Flash Cacheを使用している場合、ほとんどのデータベース書込みリクエストはキャッシュによって吸収されます。ただし、一部の書込みリクエストではキャッシュをスキップする場合があります。キャッシュをスキップする最も一般的な理由は、一時ソートなどのために1回のみ読み取られる大量のデータがリクエストによって書き込まれた場合や、またはバックアップやアーカイブなど、将来予測できる範囲で読取りが発生しないことが想定される場合です。
Large Writesをスキップする一般的な理由として、Disk Not Busyもあります。これは、通常、ハード・ディスクには書込みリクエストを処理するための十分な容量があるため、Exadata Smart Flash Cacheを使用するメリットがないことを意味します。
Large WritesでExadata Smart Flash Cacheをスキップするとパフォーマンスの問題が発生する場合は、通常、データベースのdirect path writeまたはdirect path write temp待機イベントの対応するレイテンシが長くなることでそのことがわかります。
Large Writesを拒否した理由は、AWRレポートのFlash Cache User Writes - Large Write Rejections セクションに表示されます。
データベース・ワーキング・セット・サイズ
データベース・ワーキング・セットとは、データベース内で最も一般的にアクセスされる情報のサブセットを指します。ほとんどの場合、データベース・ワーキング・セットはかなり安定しています。ただし、なんらかの理由でワーキング・セットがExadata Smart Flash Cacheに収まらない場合は、次の症状が示されることがあります。
- キャッシュ・ミスの増加。データがExadata Smart Flash Cacheにないことを示しています。このことは、AWRレポートのFlash Cache User Readsセクション、または
FC_IO_RQ_R_MISS_SECセル・メトリックに示されます。 - Exadata Smart Flash Cacheにないデータを移入する移入アクティビティの増加。このことは、AWRレポートのFlash Cache Internal Writesセクション、または
FC_IO_[BY|RQ]_W_POPULATE_SECセル・メトリックに示されます。 - Disk Writer・アクティビティの増加。キャッシュラインを再利用して他のデータをキャッシュできるように、ダーティ・キャッシュラインをディスクに書き込む必要があることを示しています。Disk Writer・アクティビティは、AWRレポートのFlash Cache Internal Readsセクション、または
FC_IO_[RQ|BY]_[R|W]_DISK_WRITER_SECセル・メトリックに示されます。 - First Writesの増加。新しいデータがExadata Smart Flash Cacheに書き込まれていることを示しています。First Writesが多数ありOverwritesがほとんどない場合は、新しいデータがExadata Smart Flash Cacheに書き込まれていることを意味します。このことは、AWRレポートのFlash Cache User Writesセクション、または
FC_IO_[RQ|BY]_W_FIRST_SECセル・メトリックに示されます。
この場合は、次のようにします。
- データベース・アクセス・パターンを確認して、アクセスされるデータの量を減らすチューニングの機会を見つけます。
- Exadata Smart Flash Cache用の領域を増やすために、使用可能なストレージ・サーバーの数を増やすことを検討します。
- Exadata Smart Flash CacheのI/Oリソース管理(IORM)割当て制限を確認し、最も必要な場所に領域を割り当てます。
- Extreme Flashストレージ・サーバーを使用してディスクI/Oを排除することを検討します。
その他の問題
cell single block physical readのレイテンシの増加は、セルのパフォーマンスによるものではなく、ネットワークの競合やデータベース・サーバーのCPUリソースの競合など、IOパスにおける別のものが原因である場合があります。
cell single block physical readのヒストグラム、およびSmall Reads Histogramは、AWRレポートのExadata Statistics→Performance SummaryセクションのSingle Block Readsセクションと Small Read Histgram - Details セクションにあります。cell single block physical readヒストグラムはOracle Databaseによって測定されたレイテンシを示し、Small Reads Histogramはストレージ・サーバーで測定されたレイテンシを示します。
不定期の長いレイテンシが多数あるヒストグラムは、ロング・テールがあると言われます。cell single block physical readヒストグラムおよびSmall Reads Histogramにロング・テールがある場合は、ストレージ・サーバーの読取りが低速であることを示すため、他のI/Oパフォーマンス統計をさらに調査する必要があります。セル・ディスクI/Oの監視を参照してください。
cell single block physical readヒストグラムに、Small Reads Histogramには存在しないロング・テールがある場合は、通常、ストレージ・サーバーではなく、ネットワークのボトルネックやコンピュート・ノードのCPUの競合など、I/Oパスにおける別のものが原因です。
6.3.2 XRMEMキャッシュの監視
Exadata RDMAメモリー・キャッシュ(XRMEMキャッシュ)では、リモート・ダイレクト・メモリー・アクセス(RDMA)を使用してストレージ・サーバー・メモリーに直接アクセスできるため、読取りレイテンシが短縮され、レスポンス時間が速くなります。データベース・クライアントがXRMEMキャッシュから読み取ると、クライアント・ソフトウェアはキャッシュされたデータのRDMA読取りを実行します。これにより、ストレージ・サーバー・ソフトウェアがバイパスされ、読取りレイテンシが大幅に短縮されます。
XRMEMキャッシュは、Exadataスマート・フラッシュ・キャッシュと連携します。使用可能な場合は、XRMEMキャッシュにないデータをExadataスマート・フラッシュ・キャッシュから取得できます。
XRMEMキャッシュの統計は、他のExadataコンポーネントと比較すると若干異なります。クライアントはRDMA I/OをXRMEMキャッシュに直接発行するため、リクエストはcellsrvに送信されず、ストレージ・サーバーはRDMA I/Oを考慮できません。このため、XRMEMキャッシュのI/Oのセル・メトリックはありません。かわりに、Oracle Databaseの統計ではRDMAを使用して実行されるI/Oが考慮されます。
XRMEMキャッシュに関連するパフォーマンスの問題により、通常、Oracle Databaseのcell single block physical read待機イベントのレイテンシが増加します。ただし、それでもExadataスマート・フラッシュ・キャッシュを使用してリクエストを処理できること、およびExadataスマート・フラッシュ・キャッシュからのリクエストは一般的にXRMEMキャッシュに比べて読取りレイテンシが長くなるものの、リクエストはフラッシュによって提供される高速I/Oのメリットを得られることに留意してください。
6.3.2.1 AWRを使用したXRMEMキャッシュの監視
自動ワークロード・リポジトリ(AWR)には、XRMEMキャッシュに関連する情報が含まれます。XRMEMキャッシュに関する情報を含むAWRレポートの最も一般的に使用されるセクションの説明と例を次に示します。管理者は、AWRレポートのこれらのセクションを確認することで、XRMEMキャッシュの操作を把握できます。
ストレージ・サーバーはRDMA I/Oを考慮できないため、XRMEMキャッシュの使用状況を把握するにはOracle Database統計が重要です。AWRレポートのExadata固有のセクションのXRMEMキャッシュ統計には、cellsrvによって処理されるI/O (RDMA I/Oではない)のみが含まれます。
データベースIO
データベースIOのサマリーは、AWRレポートの単一ブロック読取りセクションにあります。このサマリーには、XRMEMキャッシュの有効性に関する情報が含まれます。単一ブロック読取りセクションは、AWRレポートのExadata統計→パフォーマンス・サマリーの下にあります。
次の例では、すべての読取りI/Oリクエストの大部分(約88%)がXRMEMキャッシュに対するRDMA読取り(cell RDMA reads)を使用して、176,000/秒を超える速度で処理されます。残りのほぼすべては、非RDMAのXRMEMキャッシュ読取り(cell xrmem cache read hits)を使用して対応されますが、残りの読取りはExadataスマート・フラッシュ・キャッシュ(cell flash cache read hits)を使用して処理されます。それぞれのI/Oタイプのスループットは大きく異なっており、このことは、XRMEMキャッシュおよびRDMAの能力を示しています。
図6-10 AWRレポート: データベースIO
XRMEMキャッシュ構成およびXRMEMキャッシュ領域使用量
XRMEMキャッシュ構成セクションには、キャッシング・モード(ライトスルーまたはライトバック)および全体のサイズなどのサマリー情報が含まれます。XRMEMキャッシュ領域使用量セクションには、XRMEMキャッシュの領域使用量に関するサマリー統計が表示されます。
次の例は、XRMEMキャッシュがすべてのセルにライトスルー・モードで構成されており、その合計サイズが約1509 GBであることを示しています。
図6-11 AWRレポート: XRMEMキャッシュ構成
次のXRMEMキャッシュ領域使用量セクションの例では、172 GBのXRMEMキャッシュが3つのセルに均等に分散されていることを示しています。
図6-12 AWRレポート: XRMEMキャッシュの領域使用量
XRMEMキャッシュ・ユーザー読取り
XRMEMキャッシュ・ユーザー読取りセクションには、読取りリクエスト、読取りスループットおよび読取り効率に関する情報が表示されます。ストレージ・サーバーはRDMA I/Oを考慮できないため、統計はcellsrvによって処理される非RDMA読取りにのみ関連しています。ヒットはXRMEMキャッシュを使用して対応されたI/Oに対するもので、ミスはデータがXRMEMキャッシュになかったことを示しています。
図6-13 AWRレポート: XRMEMキャッシュのユーザー読取り
XRMEMキャッシュ内部書込み
XRMEMキャッシュ内部書込みセクションには、Oracle Exadata System Softwareによって実行されるXRMEMキャッシュへの書込みが表示されます。内部書込みは、XRMEMキャッシュに移入するI/Oです。
図6-14 AWRレポート: XRMEMキャッシュの内部書込み
親トピック: XRMEMキャッシュの監視
6.3.2.2 データベース統計および待機イベントを使用したXRMEMキャッシュの監視
ノート:
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。
次の表では、XRMEMキャッシュの監視に役立つデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
cell RDMA reads |
RDMAを使用して成功したXRMEMキャッシュ読取りリクエスト数 |
cell RDMA reads eligible |
RDMAの基本的な適格基準を満たすデータベース読取り数 |
cell RDMA read hash table probes |
XRMEMキャッシュでのデータの存在を判断するために発行されたRDMAハッシュ表プローブ合計数。通常、適格な各読取りはハッシュ表プローブに関連付けられます。 |
cell RDMA reads issued |
XRMEMキャッシュからデータを取得するために発行されたRDMA読取り合計数。通常、RDMA読取りはハッシュ表プローブが成功するたびに発行されます。 |
|
|
失敗したRDMAハッシュ表プローブ合計数。各統計は、特定の障害理由をカバーします。 これらの障害合計は、ほとんどが XRMEMキャッシュ初期化中のいくつかのRDMAハッシュ表プローブの障害は正常です。ただし、頻繁に発生する障害や多数の障害は、さらに調査が必要な問題を示している可能性があります。 |
|
|
失敗したRDMA読取り合計数。各統計は、特定の障害理由をカバーします。 これらの障害合計は、ほとんどが 通常、いくつかのRDMA読取り障害が発生することがあります。ただし、頻繁に発生する障害や多数の障害は、さらに調査が必要な問題を示している可能性があります。 |
cell RDMA reads rejected - ineligible |
RDMAの基本的な適格基準を満たさないデータベース読取り数 |
cell xrmem cache read hits |
XRMEMキャッシュ・ヒットが発生するcellsrvによって処理された非RDMA読取りリクエストの数
|
次の表では、XRMEMキャッシュの監視に役立つデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
| 待機イベント | 説明 |
|---|---|
cell list of blocks physical read |
この待機イベントは、リカバリ中またはバッファのプリフェッチ中(複数の単一ブロック読取りの実行ではない)に発生します。これは、リカバリの一環として変更する必要があり、データベースに対してパラレルで読み取られるデータベース・ブロックを監視するために使用されます。
この待機イベントは、セルの |
cell list of blocks read request |
これは |
cell multiblock physical read(セルの複数ブロックの物理読込み) |
この待機イベントは、マルチブロック・データベース読取りのすべてのI/Oの実行に要した時間を表します。
この待機イベントは、セルの |
cell multiblock read request |
これは |
cell single block physical read(セルの単一ブロックの物理読込み) |
この待機イベントは、セルの この待機イベントには、Exadataスマート・フラッシュ・キャッシュからのI/O、XRMEMキャッシュからのI/O、またはリモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用したデータベースI/Oは含まれません。
|
cell single block physical read: RDMA |
この待機イベントは、リモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用して単一ブロック・データベースI/Oの実行に要する時間を表します。
この待機イベントは、2022年5月のOracle Databaseリリース更新で導入され、Oracle Databaseバージョン19.15.0.0.220419、21.6.0.0.220419以降に存在します。以前は、 |
cell single block physical read: xrmem cache |
この待機イベントは、XRMEMキャッシュから単一ブロック・データベースI/Oの実行に要する時間を表します。 XRMEMキャッシュを効果的に使用すると、この待機イベントのレイテンシが非常に短くなります。これは、RDMAを使用する操作では一般的です。
|
cell single block read request |
これは、単一ブロック・データベースI/Oに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示されます。待機イベントが終了すると、プレースホルダは適切な待機イベント(通常は |
cell interconnect retransmit during physical read |
この待機イベントは、単一ブロック読取りまたはマルチブロック読取りのI/Oの再転送中に表示されます。 |
親トピック: XRMEMキャッシュの監視
6.3.2.3 Exadataメトリックを使用したXRMEMキャッシュの監視
XRMEMキャッシュに関連するExadataメトリックは、Exadataストレージ・サーバーの、objectType=XRMEMCACHEであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
XRMEMキャッシュからの読取りは主にOracle DatabaseからのRDMAコールを使用して実行されるため、XRMEMキャッシュI/Oを集計するExadataメトリックはないことに注意してください。
例6-2 XRMEMキャッシュのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なXRMEMキャッシュのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = XRMEMCACHE
XRM_BY_ALLOCATED "Number of megabytes allocated in XRMEM cache"次の追加詳細に注意してください。
-
XRM_BY_ALLOCATEDはXRMEMキャッシュに割り当てられているMB数を表し、XRMEMキャッシュで使用されているキャッシュラインの数を追跡します。値がXRMEMキャッシュのサイズに近い場合、XRMEMキャッシュは満杯です。このメトリックは、データベースごと(
DB_XRM_BY_ALLOCATED)およびPDBごと(PDB_XRM_BY_ALLOCATED)に使用することもできます。
親トピック: XRMEMキャッシュの監視
6.3.2.4 XRMEMキャッシュを監視する際の注意事項
データベース・ワーキング・セット
データベース・ワーキング・セット全体がXRMEMキャッシュに収まる場合、パフォーマンスが最大化されます。ただし、XRMEMキャッシュはExadataスマート・フラッシュ・キャッシュより小さく、データベース・ワーキング・セット、またはその中で最も頻繁にアクセスされる部分であってもXRMEMキャッシュに存在しない可能性があります。
ワーキング・セットのサイズの増大に伴い、XRMEMキャッシュではなく、Exadataスマート・フラッシュ・キャッシュまたはハード・ディスクによって対応される読取りの増加が観測される場合があります。これは、データのアクセス・パターンがよりランダムな場合に増えます。したがって、特にcell single block physical read待機イベントで読取りレイテンシの増加が観測される場合があります。
非RDMA読取り
XRMEMキャッシュは、RDMAとともに使用すると最も効果的です。ただし、それでも、様々な状況において、cellsrvへのリクエストがXRMEMキャッシュを使用して対応される場合があります。このような場合、関連付けられた読取りは、cell RDMA readsではなくcell xrmem cache read hitsとして表示されます。
非RDMA読取りは、次の理由で発生することがあります。
- 読み取られるデータのタイプによっては、Oracle DatabaseがRDMA読取りを実行できない場合があります。この例として、直接読取りおよびOracle Database制御ファイルからの読取りがあります。原因を特定するには、他の統計または待機イベントと相互に関連付ける必要がある場合があります。たとえば、制御ファイルに対する重要なアクティビティは、通常、
control file sequential read待機イベントが伴うか、AWRレポートのファイル・タイプ別のIOStatセクションに示されます。 - Oracle Databaseクライアントで、バッファがRDMAに登録されていない可能性があります。これは通常、クライアント・プロセスの開始直後またはXRMEMキャッシュへの移入中に発生します。
- XRMEMキャッシュ内で、RDMAハッシュ表に必要なメタデータが含まれていない可能性があります(または無効としてマークされている可能性があります)。これは通常、XRMEMキャッシュへの移入中に発生します。
- RDMA読取りは、デフォルトのリース時間(20ミリ秒)を超えるとタイムアウトします。
- メモリーの制限により、RDMAに必要なメモリー構造を作成できません。
- RDMA読取りエラーが発生した場合。
親トピック: XRMEMキャッシュの監視
6.3.3 PMEMキャッシュの監視
ノート:
このトピックは、23.1.0より前のOracle Exadata System Softwareリリースにのみ適用されます。それ以外の場合は、「XRMEMキャッシュの監視」を参照してください。
永続メモリー(PMEM)キャッシュを使用すると、リモート・ダイレクト・メモリー・アクセス(RDMA)を使用してストレージ・サーバー上の永続メモリーに直接アクセスできるため、読取りレイテンシが短縮され、レスポンス時間が速くなります。PMEMは、選択したExadata X8MおよびX9Mストレージ・サーバー・モデルでのみ使用できます。データベース・クライアントがPMEMキャッシュから読み取ると、クライアント・ソフトウェアはキャッシュされたデータのRDMA読取りを実行します。これにより、ストレージ・サーバー・ソフトウェアがバイパスされ、読取りレイテンシが大幅に短縮されます。
PMEM Cacheは、Exadata Smart Flash Cacheと連携します。使用可能な場合は、PMEM CacheにないデータをExadata Smart Flash Cacheから取得できます。同様に、PMEM Cacheからデータが書き出されると、ライトバック・モードの使用時にExadata Smart Flash Cacheに書き込まれます。
PMEMキャッシュの統計は、他のExadataコンポーネントと比較すると若干異なります。クライアントはRDMA I/OをPMEMキャッシュに直接発行するため、リクエストはcellsrvに送信されず、ストレージ・サーバーはRDMA I/Oを考慮できません。このため、PMEMキャッシュのI/Oのセル・メトリックはありません。かわりに、Oracle Databaseの統計ではRDMAを使用して実行されるI/Oが考慮されます。
PMEM Cacheに関連するパフォーマンスの問題により、通常、Oracle Databaseのcell single block physical read待機イベントのレイテンシが増加します。ただし、それでもExadata Smart Flash Cacheを使用してリクエストを処理できること、およびExadata Smart Flash Cacheからのリクエストは一般的にPMEM Cacheに比べて読取りレイテンシが長くなるものの、リクエストはフラッシュによって提供される高速I/Oのメリットを得られることに留意してください。
6.3.3.1 AWRを使用したPMEMキャッシュの監視
ノート:
Oracle Exadata System Softwareリリース23.1.0以降をサポートするOracle Databaseバージョンでは、PMEMキャッシュへのすべての参照の名前がXRMEMキャッシュ(Exadata RDMAメモリー・キャッシュ)に変更されます。ただし、基礎となるOracle Exadata Storage ServerにPMEMキャッシュが含まれている場合、AWRレポートのこれらの部分は引き続きPMEMキャッシュに対応しています。
自動ワークロード・リポジトリ(AWR)には、PMEM Cacheに関連する情報が含まれます。PMEM Cacheに関する情報を含むAWRレポートの最も一般的に使用されるセクションの説明と例を次に示します。管理者は、AWRレポートのこれらのセクションを確認することで、PMEM Cacheの操作を把握できます。
ストレージ・サーバーはRDMA I/Oを考慮できないため、PMEM Cacheの使用状況を把握するにはOracle Database統計が重要です。AWRレポートのExadata固有のセクションのPMEM Cache統計には、cellsrvによって処理されるI/O (RDMA I/Oではない)のみが含まれます。
AWRレポートには、後述のセクション以外に、PMEM Cache User WritesセクションおよびPMEM Cache Internal Readsセクションも含まれます。これらのセクションは、ライトバック・モードでのPMEM Cacheの使用に関連しているため、詳細には説明されていません(通常はお薦めしません)。
Database IOs
Database IOsのサマリーは、AWRレポートのSingle Block Readsセクションにあります。このサマリーには、PMEM Cacheの有効性に関する情報が含まれます。Single Block Readsセクションは、AWRレポートのExadata Statistics→Performance Summaryの下にあります。
次の例では、すべての読取りI/Oリクエストの大部分(約88%)がPMEMキャッシュに対するRDMA読取り(cell RDMA reads)を使用して、176,000/秒を超える速度で処理されます。残りのほぼすべては、非RDMAのPMEMキャッシュ読取り(cell xrmem cache read hitsまたはcell PMEM cache read hits)を使用して対応されますが、残りの読取りはExadataスマート・フラッシュ・キャッシュ(cell flash cache read hits)を使用して処理されます。それぞれのI/Oタイプのスループットは大きく異なっており、このことは、PMEMキャッシュおよびRDMAの能力を示しています。
図6-15 AWRレポート: データベースIO
PMEM Cache ConfigurationおよびPMEM Cache Space Usage
PMEM Cache Configurationセクションには、キャッシング・モード(ライトスルーまたはライトバック)および全体のサイズなどのサマリー情報が含まれます。PMEM Cache Space Usageセクションには、PMEM Cacheの領域使用量に関するサマリー統計が表示されます。
次の例は、PMEM Cacheがすべてのセルにライトスルー・モードで構成されており、その合計サイズが約1509 GBであることを示しています。
図6-16 AWRレポート: PMEMキャッシュ構成
次のPMEM Cache Space Usageセクションの例では、172 GBのPMEM Cacheが3つのセルに均等に分散されていることを示しています。
図6-17 AWRレポート: PMEMキャッシュの領域使用量
PMEM Cache User Reads
PMEM Cache User Readsセクションには、読取りリクエスト、読取りスループットおよび読取り効率に関する情報が表示されます。ストレージ・サーバーはRDMA I/Oを考慮できないため、統計はcellsrvによって処理される非RDMA読取りにのみ関連しています。HitsはPMEM Cacheを使用して対応されたI/Oに対するもので、MissesはデータがPMEM Cacheになかったことを示しています。
図6-18 AWRレポート: PMEMキャッシュのユーザー読取り
PMEM Cache Internal Writes
PMEM Cache Internal Writesセクションには、Oracle Exadata System Softwareによって実行されるPMEM Cacheへの書込みが表示されます。内部書込みは、PMEM Cacheに移入するI/Oです。
図6-19 AWRレポート: PMEMキャッシュの内部書込み
親トピック: PMEM Cacheの監視
6.3.3.2 データベース統計および待機イベントを使用したPMEMキャッシュの監視
ノート:
-
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。
-
Oracle Exadata System Softwareリリース23.1.0以降をサポートするOracle Databaseバージョンでは、PMEMキャッシュに関連するすべてのデータベース統計および待機イベントの名前がXRMEMキャッシュ(Exadata RDMAメモリー・キャッシュ)に変更されます。ただし、基礎となるOracle Exadata Storage ServerにPMEMキャッシュが含まれている場合、これらのデータベース統計および待機イベントは引き続きPMEMキャッシュに対応しています。
次の表では、PMEM Cacheの監視に役立つデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
cell RDMA reads |
RDMAを使用して成功したPMEMキャッシュ読取りリクエスト数 |
cell RDMA reads eligible |
RDMAの基本的な適格基準を満たすデータベース読取り数 |
cell RDMA read hash table probes |
PMEMキャッシュでのデータの存在を判断するために発行されたRDMAハッシュ表プローブ合計数。通常、適格な各読取りはハッシュ表プローブに関連付けられます。 |
cell RDMA reads issued |
PMEMキャッシュからデータを取得するために発行されたRDMA読取り合計数。通常、RDMA読取りはハッシュ表プローブが成功するたびに発行されます。 |
|
|
失敗したRDMAハッシュ表プローブ合計数。各統計は、特定の障害理由をカバーします。 これらの障害合計は、ほとんどが PMEMキャッシュ初期化中のいくつかのRDMAハッシュ表プローブの障害は正常です。ただし、頻繁に発生する障害や多数の障害は、さらに調査が必要な問題を示している可能性があります。 |
|
|
失敗したRDMA読取り合計数。各統計は、特定の障害理由をカバーします。 これらの障害合計は、ほとんどが 通常、いくつかのRDMA読取り障害が発生することがあります。ただし、頻繁に発生する障害や多数の障害は、さらに調査が必要な問題を示している可能性があります。 |
cell RDMA reads rejected - ineligible |
RDMAの基本的な適格基準を満たさないデータベース読取り数 |
cell RDMA writes |
RDMAを使用して成功したPMEMキャッシュ書込みリクエスト数 |
|
|
PMEMキャッシュ・ヒットが発生する Oracle Exadata System Softwareリリース23.1.0以降をサポートするOracle Databaseバージョンでは、統計の名前は |
|
|
PMEMキャッシュ書込みが発生する Oracle Exadata System Softwareリリース23.1.0以降をサポートするOracle Databaseバージョンでは、統計の名前は |
次の表では、PMEM Cacheの監視に役立つデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
| 待機イベント | 説明 |
|---|---|
cell list of blocks physical read |
この待機イベントは、リカバリ中またはバッファのプリフェッチ中(複数の単一ブロック読取りの実行ではない)に発生します。これは、リカバリの一環として変更する必要があり、データベースに対してパラレルで読み取られるデータベース・ブロックを監視するために使用されます。
この待機イベントは、セルの |
cell list of blocks read request |
これは |
cell multiblock physical read(セルの複数ブロックの物理読込み) |
この待機イベントは、マルチブロック・データベース読取りのすべてのI/Oの実行に要した時間を表します。
この待機イベントは、セルの |
cell multiblock read request |
これは |
cell single block physical read(セルの単一ブロックの物理読込み) |
この待機イベントは、セルの 2022年5月のOracle Databaseリリース更新(バージョン19.15.0.0.220419、21.6.0.0.220419以降)以降では、この待機イベントには、Exadata Smart Flash CacheのI/O、PMEM CacheのI/O、またはリモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用したデータベースのI/Oが含まれなくなりました。この変更により、別の待機イベント( 2022年5月のOracle Databaseリリース更新前は、PMEMキャッシュを効果的に使用すると、この待機イベントのレイテンシが非常に短くなります。これは、RDMAを使用する操作では一般的です。
|
|
|
この待機イベントは、PMEM Cacheから単一ブロック・データベースI/Oの実行に要する時間を表します。 PMEMキャッシュを効果的に使用すると、この待機イベントのレイテンシが非常に短くなります。これは、RDMAを使用する操作では一般的です。 この待機イベントは、2022年5月のOracle Databaseリリース更新で導入され、Oracle Databaseバージョン19.15.0.0.220419、21.6.0.0.220419以降に存在します。以前は、 Oracle Exadata System Softwareリリース23.1.0以降をサポートするOracle Databaseバージョンでは、待機イベントの名前は
|
cell single block read request |
これは、単一ブロック・データベースI/Oに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示されます。待機イベントが終了すると、プレースホルダは適切な待機イベント(通常は |
cell interconnect retransmit during physical read |
この待機イベントは、単一ブロック読取りまたはマルチブロック読取りのI/Oの再転送中に表示されます。 |
親トピック: PMEM Cacheの監視
6.3.3.3 Exadataメトリックを使用したPMEMキャッシュの監視
PMEM Cacheに関連するExadataメトリックは、Exadataストレージ・サーバーの、objectType=PMEMCACHEであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
PMEM Cacheからの読取りは主にOracle DatabaseからのRDMAコールを使用して実行されるため、PMEM Cache I/Oを集計するExadataメトリックはないことに注意してください。
例6-3 PMEMキャッシュのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なPMEM Cacheのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = PMEMCACHE
PC_BY_ALLOCATED "Number of megabytes allocated in PMEM cache"次の追加詳細に注意してください。
-
PC_BY_ALLOCATEDはPMEM Cacheに割り当てられているMB数を表し、PMEM Cacheで使用されているキャッシュラインの数を追跡します。値がPMEM Cacheのサイズに近い場合、PMEM Cacheは満杯です。このメトリックは、データベースごと(
DB_PC_BY_ALLOCATED)およびPDBごと(PDB_PC_BY_ALLOCATED)に使用することもできます。
親トピック: PMEM Cacheの監視
6.3.3.4 PMEMキャッシュを監視する際の注意事項
データベース・ワーキング・セット
データベース・ワーキング・セット全体がPMEM Cacheに収まる場合、パフォーマンスが最大化されます。ただし、PMEM CacheはExadata Smart Flash Cacheよりもはるかに小さく、データベース・ワーキング・セット、またはその中で最も頻繁にアクセスされる部分ですらPMEM Cacheに存在しない可能性があります。
ワーキング・セットのサイズの増大に伴い、PMEM Cacheではなく、Exadata Smart Flash Cacheまたはハード・ディスクによって対応される読取りの増加が観測される場合があります。これは、データのアクセス・パターンがよりランダムな場合に増えます。したがって、特にcell single block physical read待機イベントで読取りレイテンシの増加が観測される場合があります。
非RDMA読取り
PMEMキャッシュは、RDMAとともに使用すると最も効果的です。ただし、それでも、様々な状況において、cellsrvへのリクエストがPMEMキャッシュを使用して対応される場合があります。このような場合、関連付けられた読取りは、cell RDMA readsではなくcell xrmem cache read hitsまたはcell pmem cache read hitsとして表示されます。
非RDMA読取りは、次の理由で発生することがあります。
- 読み取られるデータのタイプによっては、Oracle DatabaseがRDMA読取りを実行できない場合があります。この例として、直接読取りおよびOracle Database制御ファイルからの読取りがあります。原因を特定するには、他の統計または待機イベントと相互に関連付ける必要がある場合があります。たとえば、制御ファイルに対する重要なアクティビティは、通常、
control file sequential read待機イベントが伴うか、AWRレポートのファイル・タイプ別のIOStatセクションに示されます。 - Oracle Databaseクライアントで、バッファがRDMAに登録されていない可能性があります。これは通常、クライアント・プロセスの開始直後またはPMEM Cacheへの移入中に発生します。
- PMEM Cache内で、RDMAハッシュ表に必要なメタデータが含まれていない可能性があります(または無効としてマークされている可能性があります)。これは通常、PMEM Cacheへの移入中に発生します。
- RDMA読取りは、デフォルトのリース時間(20ミリ秒)を超えるとタイムアウトします。
- メモリーの制限により、RDMAに必要なメモリー構造を作成できません。
- RDMA読取りエラーが発生した場合。
親トピック: PMEM Cacheの監視
6.3.4 Exadataスマート・フラッシュ・ログの監視
Exadata Smart Flash Logにより、パフォーマンスに依存するREDOログ書込みI/O操作の平均レイテンシが短縮されるため、低速のREDOログ書込みが原因で発生する可能性のあるパフォーマンスのボトルネックが解消されます。Exadata Smart Flash Logでは、2つのメディア・デバイスへのREDOログ書込みを同時に実行することで、レイテンシ・スパイクを排除します。いずれかのメディア・デバイスへのFirst Writesが完了するとすぐにREDO書込みが確認されます。
当初、Exadata Smart Flash Logは、ディスクとフラッシュ・ストレージへの同時書込みを実行するために使用されていました。ただし、Oracle Exadata System Softwareリリース20.1では、ディスク・ストレージではなくExadata Smart Flash Cacheをライトバック・モードで使用する、Smart Flash Log・ライトバックと呼ばれる最適化がさらに追加されています。
6.3.4.1 AWRを使用したExadataスマート・フラッシュ・ログの監視
AWRレポートのFlash Log統計セクションの説明と例を次に示します。管理者は、AWRレポートのこれらのセクションを確認することで、Exadata Smart Flash Logの操作を把握できます。
Flash Log
Flash Logセクションには、Exadata Smart Flash Logへの書込みの数、Exadata Smart Flash Logによって回避された外れ値の数、Exadata Smart Flash Logがスキップされた回数など、Exadata Smart Flash Logの操作に関するサマリー統計が含まれます。
Flash Logセクションの例を次に示します。例に示すように、Exadata Smart Flash Logが最適に動作する場合、I/Oはすべてのセルに均等に分散され、スキップはありません。
図6-20 AWRレポート: フラッシュ・ログ
Skip Countsがゼロより大きい場合、Flash Log Skip Detailsセクションには、Exadata Smart Flash Logをスキップする理由が含まれます。
Redo Write Histogram
Redo Write Histogram・セクションには、データベースからのlog file parallel writeのレイテンシおよびストレージ・サーバーからのredo write request completionのレイテンシを示すヒストグラムが表示されます。データベースとセルのレイテンシ・ヒストグラムを比較することで、高いレイテンシの外れ値がストレージ・サーバーの処理ボトルネックに関連しているかどうかを判断できます。
図6-21 AWRレポート: REDO書込みヒストグラム
親トピック: Exadata Smart Flash Logの監視
6.3.4.2 データベース統計および待機イベントを使用したExadataスマート・フラッシュ・ログの監視
次の表では、REDO書込みおよびExadata Smart Flash Logのパフォーマンスの監視に役立つ様々なデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
|
|
REDO書込みサイズがカッコで示されたサイズより小さいREDO書込みの数。たとえば、 |
|
|
Oracle Databaseログ・ライター(LGWR)プロセスによるREDOログ・ファイルへの書込みの合計数。 |
次の表では、REDO書込みおよびExadata Smart Flash Logのパフォーマンスの監視に役立つデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
| 待機イベント | 説明 |
|---|---|
log file parallel write |
Oracle Databaseログ・ライター(LGWR)プロセスは、REDOログ・ファイルへの書込みの完了を待機しているときに、このイベントを待機します。 Exadata Smart Flash Logが効率的に使用されていることは、このイベントの待機時間が比較的短いことで示されます。 |
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。
親トピック: Exadata Smart Flash Logの監視
6.3.4.3 Exadataメトリックを使用したExadataスマート・フラッシュ・ログの監視
Exadata Smart Flash Logに関連するExadataメトリックでは、1秒当たりの書込みMB数など、Flash Logの使用率に関する情報が提供されます。Flash Logのメトリックは、objectType=FLASHLOGであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
例6-4 フラッシュ・ログのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なFlash Logのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = FLASHLOG
FL_ACTUAL_OUTLIERS "The number of times redo writes to flash and disk both exceeded the outlier threshold"
FL_BY_KEEP "The amount of redo data saved on flash due to disk I/O errors"
FL_DISK_FIRST "The number of times redo writes first completed to disk"
FL_DISK_IO_ERRS "The number of disk I/O errors encountered by Smart Flash Logging"
FL_EFFICIENCY_PERCENTAGE "The efficiency of Smart Flash Logging expressed as a percentage"
FL_EFFICIENCY_PERCENTAGE_HOUR "The efficiency of Smart Flash Logging over the last hour expressed as a percentage"
FL_FLASH_FIRST "The number of times redo writes first completed to flash"
FL_FLASH_IO_ERRS "The number of flash I/O errors encountered by Smart Flash Logging"
FL_FLASH_ONLY_OUTLIERS "The number of times redo writes to flash exceeded the outlier threshold"
FL_IO_DB_BY_W "The number of MB written to hard disk by Smart Flash Logging"
FL_IO_DB_BY_W_SEC "The rate which is the number of MB per second written to hard disk by Smart Flash Logging"
FL_IO_FL_BY_W "The number of MB written to flash by Smart Flash Logging"
FL_IO_FL_BY_W_SEC "The rate which is the number of MB per second written to flash by Smart Flash Logging"
FL_IO_TM_W "Cumulative latency of all redo log writes"
FL_IO_TM_W_RQ "Average latency of all redo log writes"
FL_IO_W "The number of writes serviced by Smart Flash Logging"
FL_IO_W_SKIP_BUSY "The number of redo writes that could not be serviced by Smart Flash Logging because too much data had not yet been written to disk"
FL_IO_W_SKIP_BUSY_MIN "The number of redo writes during the last minute that could not be serviced by Smart Flash Logging because too much data had not yet been written to disk"
FL_IO_W_SKIP_DISABLED_GD "The number of redo writes that could not be serviced by Smart Flash Logging because it was disabled for the redo log's grid disk"
FL_IO_W_SKIP_IORM_LIMIT "The number of redo writes that could not be serviced by Smart Flash Logging because the IORM limit had been reached for the redo log's grid disk"
FL_IO_W_SKIP_IORM_PLAN "The number of redo writes that could not be serviced by Smart Flash Logging because it was disabled by the IORM plan"
FL_IO_W_SKIP_LARGE "The number of large redo writes that could not be serviced by Smart Flash Logging because the size of the data was larger than the amount of available space on any flash disk"
FL_IO_W_SKIP_LOG_ON_FLASH "The number of redo writes that could not be serviced by Smart Flash Logging because the redo log resided on flash"
FL_IO_W_SKIP_NO_BUFFER "The number of redo writes that could not be serviced by Smart Flash Logging because of lack of available buffers"
FL_IO_W_SKIP_NO_FL_DISKS "The number of redo writes that could not be serviced by Smart Flash Logging because there were no available Flash Log disks"
FL_PREVENTED_OUTLIERS "The number of times redo writes to disk exceeded the outlier threshold; these would have been outliers had it not been for Smart Flash Logging"
FL_RQ_TM_W "Cumulative latency of all redo log write requests (includes network and other processing overhead)"
FL_RQ_TM_W_RQ "Average latency of all redo log write requests"
FL_RQ_W "The number of redo log write requests serviced (includes requests which were not handled by Smart Flash Logging)"
FL_SKIP_OUTLIERS "The number of times redo writes to disk exceeded the outlier threshold when Smart Flash Logging was not used"次の追加詳細に注意してください。
-
FL_RQ_TM_Wは、REDOログ書込みリクエストの累積レイテンシ(ネットワーキングおよびその他のオーバーヘッドを含む)を追跡します。オーバーヘッド・コンポーネントを特定し、ネットワークや処理などの要因によるレイテンシ・オーバーヘッドを取得するには、FL_RQ_TM_WからのFL_IO_TM_Wの減算を使用できます。 -
FL_SKIP_OUTLIERSは、REDOログ書込みでFlash Logの使用がスキップされたときの外れ値の数を追跡します。外れ値は0.5秒を超えたREDOログ書込みです。Flash Logの使用は、
FL_IO_W_SKIP_DISABLED_GD、FL_IO_W_SKIP_IORM_LIMIT、FL_IO_W_SKIP_IORM_PLAN、FL_IO_W_SKIP_LOG_ON_FLASHまたはFL_IO_W_SKIP_NO_FL_DISKSに関連する理由によってスキップされる可能性があります。 - ディスクとフラッシュ・ストレージに同時に書き込むとき、ディスク・コントローラの書込みキャッシュは、フラッシュよりも高速に一部の書込みを吸収できます。そのため、ディスクへのREDOログ書込み操作のかなりの部分がフラッシュよりも前に完了するのは正常です。場合によっては、
FL_DISK_FIRSTの値がFL_FLASH_FIRSTの値を超えることがあります。ただし、このことは、Exadataスマート・フラッシュ・ロギング機能が効果がないことや不要であることを意味しません。
親トピック: Exadata Smart Flash Logの監視
6.3.4.4 Exadataスマート・フラッシュ・ログを監視する際の注意事項
一般的なパフォーマンス
REDOロギングに関連するパフォーマンスの問題として、通常、Oracle Databaseユーザー・フォアグラウンド・プロセスでのlog file sync待機イベントのレイテンシが長い場合に、それに対応して、Oracle Databaseログ・ライター(LGWR)プロセスでのlog file parallel writeのレイテンシが長くなります。REDOログ書込みのパフォーマンス・クリティカルな性質のため、log file parallel writeの平均待機時間が許容される場合でも、log file parallel writeに不定期の長いレイテンシがあることで、データベース・パフォーマンスが変動することがあります。
これらのいずれかが発生している場合は、Exadata Smart Flash Logのパフォーマンスに問題があることを示している可能性があります。
Redo Write Histogram
log file parallel write待機イベントは、データベースがREDOログ書込みを待機する時間を示します。log file parallel writeヒストグラムは、指定された時間範囲内にREDO書込みが完了した回数を示します。同様に、redo log write completions統計は、ストレージ・サーバーがREDO書込みリクエストの処理に費やした時間を示し、redo log write completionsヒストグラムは、指定された時間範囲内にREDO書込みリクエストが完了した回数を示します。両方のヒストグラムは、AWRレポートのRedo Write Histogram・セクションに表示されます。
不定期の長いレイテンシが多数あるヒストグラムは、ロング・テールがあると言われます。AWRレポートのRedo Write Histogram・セクションの両方のヒストグラムにロング・テールがある場合は、ストレージ・サーバーでの書込みが低速であることを示すため、他のI/Oパフォーマンス統計をさらに調査する必要があります。セル・ディスクI/Oの監視を参照してください。
log file parallel writeヒストグラムに、redo log write completionsヒストグラムに存在しないロング・テールがある場合、原因は通常、ストレージ・サーバーではなく、ネットワークのボトルネックやコンピュート・ノードCPUの競合など、I/Oパスの別のものです。
スキップ
REDO書込みレイテンシの増加は、Exadata Smart Flash Logがスキップされ、REDO書込みがディスクに対してのみ行われる場合にも発生する可能性があります。AWRレポートとストレージ・サーバー・メトリックの両方に、Exadata Smart Flash LogをスキップしたREDOログ書込み数が表示されます。Exadata Smart Flash Logにまだディスクに書き込まれていないデータが大量にある場合、スキップが発生することがあります。
REDO書込みでExadata Smart Flash Logがスキップされる可能性のある要因はいくつかあります。
-
書込みレイテンシが長いフラッシュ・ディスク。
このことは、AWRレポートのExadata Resource Statisticsセクションにある様々なIO Latency表およびExadataの
CELLDISKメトリックで観測できます。これは、FL_FLASH_ONLY_OUTLIERSメトリックをチェックすることによっても識別できます。メトリック値が大きい場合、これはフラッシュ・ディスクのパフォーマンスに問題があることを示しています。 -
レイテンシが長いまたは使用率の高いハード・ディスク。
Oracle Exadata System Softwareリリース20.1より前では、REDOログ書込みはExadata Smart Flash Logとハード・ディスクの両方に書き込まれます。ハード・ディスクのレイテンシが長い場合や使用率が高い場合は、REDOログの書込みパフォーマンスに影響する可能性があります。
このことは、AWRレポートのExadata Resource Statisticsセクションにある様々なIO Latency表およびExadataの
CELLDISKメトリックで観測できます。これは、AWRレポートのFlash LogセクションのOutliers列、またはFL_PREVENTED_OUTLIERSストレージ・サーバー・メトリックをチェックすることによっても識別できます。抑制された外れ値の数が多い場合は、ハード・ディスクの書込みに時間がかかっていることを示している可能性があります。この場合、Exadata Smart Flash Logは外れ値を抑制しますが、ディスクに書き込む必要があるREDOログ・データのキューが原因で全体的なスループットが制限される可能性があります。
Oracle Exadata System Softwareリリース20.1では、ディスク・ストレージではなくExadata Smart Flash Cacheをライトバック・モードで使用する、Smart Flash Log・ライトバックと呼ばれる最適化がさらに追加されているため、潜在的なパフォーマンスのボトルネックとしてハード・ディスクが排除されます。システムのワークロードによっては、この機能により、ログ書込みの全体的なスループットが最大250%向上する可能性があります。
親トピック: Exadata Smart Flash Logの監視
6.3.5 XRMEMログの監視
ノート:
Oracle Exadata System Softwareリリース23.1.0では、Exadata RDMAメモリー(XRMEM)が導入されています。XRMEMは、リモート・ダイレクト・メモリー・アクセス(RDMA)を使用したストレージ・サーバー・メモリーへの直接アクセスを提供するExadataソフトウェア・テクノロジの集合を表し、レスポンス時間の短縮と読取りレイテンシの削減を実現します。このリリースでは、以前はPMEMログと呼ばれていた永続メモリー・コミット・アクセラレータがXRMEMログと呼ばれるようになりました。
REDOログの書込みは重要なデータベース操作であり、負荷の急増や停止を防ぐために適切なタイミングで完了する必要があります。Exadataスマート・フラッシュ・ログは、REDO書込みレイテンシの外れ値を抑制するように設計されています。XRMEMログは、永続メモリー(PMEM)およびリモート・ダイレクト・メモリー・アクセス(RDMA)を使用することにより、REDOログの書込みレイテンシをさらに短縮するのに役立ちます。XRMEMログは、選択したExadata X8MおよびX9Mストレージ・サーバー・モデルでのみ使用できます。
XRMEMログを使用すると、データベース・クライアントはRDMAを使用してストレージ・サーバー上のPMEMにI/Oバッファを直接送信するため、転送レイテンシが短縮されます。その後、セル・サーバー(cellsrv)はREDOをExadataスマート・フラッシュ・ログ(有効な場合)およびディスクに書き込みます。
REDOログの書込みレイテンシが短縮されるとOLTPのパフォーマンスが向上し、トランザクションのスループットが向上します。XRMEMログがバイパスされる場合でも、Exadataスマート・フラッシュ・ログを使用できます。
6.3.5.1 データベース統計および待機イベントを使用したXRMEMログの監視
次の表では、XRMEMログのパフォーマンスの監視に役立つデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
|
|
XRMEMログを使用したREDOログ書込みリクエストの数 Oracle Exadata System Softwareリリース23.1.0以降をサポートするOracle Databaseバージョンでは、統計の名前は |
次の表では、XRMEMログのパフォーマンスの監視に役立つデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
| 待機イベント | 説明 |
|---|---|
log file parallel write |
Oracle Databaseログ・ライター(LGWR)プロセスは、REDOログ・ファイルへの書込みの完了を待機しているときに、このイベントを待機します。 XRMEMログが効率的に使用されていることは、このイベントの待機時間が比較的短いことで示されます。 |
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。
親トピック: XRMEMログの監視
6.3.5.2 XRMEMログを監視する際の注意事項
一般的なパフォーマンス
REDOロギングに関連するパフォーマンスの問題として、通常、Oracle Databaseユーザーおよびフォアグラウンド・プロセスでのlog file sync待機イベントのレイテンシが長い場合に、それに対応して、Oracle Databaseログ・ライター(LGWR)プロセスでのlog file parallel writeのレイテンシが長くなります。REDOログ書込みのパフォーマンス・クリティカルな性質のため、log file parallel writeの平均待機時間が許容される場合でも、log file parallel writeに不定期の長いレイテンシがあることで、データベース・パフォーマンスが変動することがあります。
これらのいずれかが発生している場合は、XRMEMログのパフォーマンスに問題があることを示している可能性があります。
XRMEMログのバイパス
XRMEMログがバイパスされると、XRMEMログの使用時にREDO書込みレイテンシが増加する可能性があります。XRMEMログがバイパスされると、リクエストはcellsrvに送信され、Exadataスマート・フラッシュ・ログが引き続き使用されます(使用可能な場合)。ただし、バイパス・リクエストが送信された場合は、以前のXRMEMログ・リクエストと競合していないことを確認する必要があります。XRMEMログのスキャンを必要とするこの競合チェックにより、バイパス書込みの処理コストが高くなり、REDOログの書込みレイテンシが予想よりも長くなる可能性があります。
バイパスされるXRMEMログの数が少なくなる原因としていくつか考えられます。通常の状況では、バイパスの数はXRMEMログ・リクエストの合計数の1%未満である必要があります。XRMEMログのバイパス数が多い場合は、RoCEネットワーク・ファブリックでの輻輳など、別の問題の症状である可能性があります。
親トピック: XRMEMログの監視
6.3.6 PMEMログの監視
ノート:
このトピックは、23.1.0より前のOracle Exadata System Softwareリリースにのみ適用されます。それ以外の場合は、「XRMEMログの監視」を参照してください。
REDOログの書込みは重要なデータベース操作であり、負荷の急増や停止を防ぐために適切なタイミングで完了する必要があります。Exadata Smart Flash Logは、REDO書込みレイテンシの外れ値を抑制するように設計されています。PMEM Logは、永続メモリー(PMEM)およびリモート・ダイレクト・メモリー・アクセス(RDMA)を使用することにより、REDOログの書込みレイテンシをさらに短縮するのに役立ちます。PMEMログは、選択したExadata X8MおよびX9Mストレージ・サーバー・モデルでのみ使用できます。
PMEM Logを使用すると、データベース・クライアントはRDMAを使用してストレージ・サーバー上のPMEMにI/Oバッファを直接送信するため、転送レイテンシが短縮されます。その後、セル・サーバー(cellsrv)はREDOをExadata Smart Flash Log(有効な場合)およびディスクに書き込みます。
REDOログの書込みレイテンシが短縮されるとOLTPのパフォーマンスが向上し、トランザクションのスループットが向上します。PMEM Logがバイパスされる場合でも、Exadata Smart Flash Logを使用できます。
6.3.6.1 データベース統計および待機イベントを使用したPMEMログの監視
次の表では、PMEM Logのパフォーマンスの監視に役立つデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
|
|
PMEMログを使用したREDOログ書込みリクエストの数 Oracle Exadata System Softwareリリース23.1.0以降をサポートするOracle Databaseバージョンでは、統計の名前は |
次の表では、PMEM Logのパフォーマンスの監視に役立つデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
| 待機イベント | 説明 |
|---|---|
log file parallel write |
Oracle Databaseログ・ライター(LGWR)プロセスは、REDOログ・ファイルへの書込みの完了を待機しているときに、このイベントを待機します。 PMEM Logが効率的に使用されていることは、このイベントの待機時間が比較的短いことで示されます。 |
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。
親トピック: PMEM Logの監視
6.3.6.2 PMEMログを監視する際の注意事項
一般的なパフォーマンス
REDOロギングに関連するパフォーマンスの問題として、通常、Oracle Databaseユーザーおよびフォアグラウンド・プロセスでのlog file sync待機イベントのレイテンシが長い場合に、それに対応して、Oracle Databaseログ・ライター(LGWR)プロセスでのlog file parallel writeのレイテンシが長くなります。REDOログ書込みのパフォーマンス・クリティカルな性質のため、log file parallel writeの平均待機時間が許容される場合でも、log file parallel writeに不定期の長いレイテンシがあることで、データベース・パフォーマンスが変動することがあります。
これらのいずれかが発生している場合は、PMEM Logのパフォーマンスに問題があることを示している可能性があります。
PMEM Logのバイパス
PMEM Logがバイパスされると、PMEM Logの使用時にREDO書込みレイテンシが増加する可能性があります。PMEM Logがバイパスされると、リクエストはcellsrvに送信され、Exadata Smart Flash Logが引き続き使用されます(使用可能な場合)。ただし、バイパス・リクエストが送信された場合は、以前のPMEM Log・リクエストと競合していないことを確認する必要があります。PMEM Logのスキャンを必要とするこの競合チェックにより、バイパス書込みの処理コストが高くなり、REDOログの書込みレイテンシが予想よりも長くなる可能性があります。
バイパスされるPMEM Logの数が少なくなる原因としていくつか考えられます。通常の状況では、バイパスの数はPMEM Log・リクエストの合計数の1%未満である必要があります。PMEM Logのバイパス数が多い場合は、RoCEネットワーク・ファブリックでの輻輳など、別の問題の症状である可能性があります。
親トピック: PMEM Logの監視
6.3.7 スマートI/Oの監視
Exadataスマート・スキャンは、データ検索および取得処理をExadataストレージ・サーバーにオフロードします。特に大規模な問合せおよび特定のクラスの一括データ処理では、ストレージ・サーバー上のデータベース条件を評価して効率とパフォーマンスを最適化できます。
また、スマート・スキャンは、ストレージ・サーバー上で自動的に管理されるストレージ索引を使用して、不要なI/Oを排除することでフィルタリングをさらに最適化します。
列キャッシュは、別のスマートI/O最適化です。列キャッシュは、データを列形式で格納するExadata Smart Flash Cacheのセクションです。列キャッシュは、スマート・スキャンの実行時にストレージ・サーバーによって自動的に移入および管理されます。
6.3.7.1 AWRを使用したスマートI/Oの監視
スマート・スキャンのサマリーは、AWRレポートのパフォーマンス・サマリー・セクションの一部です。この領域には、スマートI/Oに関連する主要な統計の概要が含まれます。次の例では、進行中のオンライン暗号化のために一部のアクティビティがブロックI/Oに戻った状況を強調表示します。
図6-22 AWRレポート: パフォーマンス・サマリー - スマート・スキャンのサマリー
AWRレポートのスマートIO統計セクションには、システム全体および各ストレージ・サーバーでのスマートI/O操作の統計情報のより詳細なサマリーが表示されます。特に、スマート・スキャンを使用した最適化の対象となるI/Oの量、ストレージ索引および列キャッシュの使用による節約、Exadataスマート・フラッシュ・キャッシュ内のデータの量、およびデータベース・サーバーに転送せずにストレージ・サーバーによってフィルタ処理されるデータの量を追跡します。また、関連するデータベース統計と、ストレージ・サーバーが条件評価を実行できない状況(パススルーとも呼ばれる)に関する詳細情報も表示されます。
図6-23 AWRレポート: スマートIO統計
親トピック: スマートI/Oの監視
6.3.7.2 データベース統計および待機イベントを使用したスマートI/Oの監視
次の表では、スマートI/O操作の監視に役立つ様々なデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
cell IO uncompressed bytes |
セルで処理された非圧縮データの合計サイズ。 Exadataハイブリッド列圧縮を使用して圧縮されたセグメントに対する操作の場合、この統計が解凍後のデータのサイズになります。 |
cell num bytes in block IO during predicate offload |
クライアントがブロックI/Oモードであったためにオフロードされなかったバイト数。 |
cell num bytes in filter passthru due to low mem |
セルに対するメモリー不足が原因でオフロードされず、処理のためにデータベースに返されたバイト数。 |
cell num bytes in filter passthru due to subheap size limit exc |
セルに対するメモリー制限が原因でオフロードされず、処理のためにデータベースに返されたバイト数。 |
cell num bytes in passthru due to quarantine |
セルに対する検疫が原因でオフロードされず、処理のためにデータベースに返されたバイト数。 |
cell num bytes in passthru during predicate offload |
オフロードされず、処理のためにデータベースに返されたバイト数。 |
cell num smart IO sessions in rdbms block IO due to big payload
|
大きすぎるメタデータが原因でブロックI/Oモードになっている(オフロードされない)セッション数。 |
cell num smart IO sessions in rdbms block IO due to no cell mem |
ストレージ・サーバーのメモリー不足が原因でブロックI/Oモードになっている(オフロードされない)セッション数。 |
cell num smart IO sessions in rdbms block IO due to online encr |
進行中のオンライン暗号化操作が原因でブロックI/Oモードになっている(オフロードされない)セッション数。 |
|
|
セルへの接続のオープンの失敗が原因でブロックI/Oモードになっている(オフロードされない)セッション数。 |
|
|
ユーザー設定が原因でブロックI/Oモードになっている(オフロードされない)セッション数。 |
cell num smart IO sessions using passthru mode due to cellsrv |
CELLSRVの問題が原因でパススルー・モードになっている(オフロードされない)セッション数。 |
|
|
データベース・タイムゾーン・アップグレード操作の進行中が原因でパススルー・モードになっている(オフロードされない)セッション数。 |
cell num smart IO sessions using passthru mode due to user |
ユーザー設定が原因でパススルー・モードになっている(オフロードされない)セッション数。 |
cell physical IO bytes added to storage index |
スマート・スキャン中にストレージ索引に追加されたバイト数。これは、ストレージ索引が作成中であることを示します。 |
cell physical IO bytes eligible for predicate offload |
条件のオフロードの対象となるディスク上のバイト数。 |
cell physical IO bytes eligible for smart IOs |
条件のオフロードの対象となる実際のバイト数。 たとえば、列キャッシュを使用する場合、これはディスク上のサイズではなく列キャッシュのサイズです。 |
cell physical IO bytes processed for IM capacity |
列キャッシュからmemcompress for capacity形式で読み取られたバイト数。
|
cell physical IO bytes processed for IM query |
列キャッシュからmemcompress for query形式で読み取られたバイト数。
|
cell physical IO bytes processed for no memcompress |
列キャッシュからno memcompress形式で読み取られたバイト数。
|
cell physical IO bytes saved by columnar cache |
列キャッシュによって保存されたバイト数。つまり回避された読取りバイト数。 |
cell physical IO bytes saved by storage index |
ストレージ索引によって保存されたバイト数。 |
cell physical IO bytes saved during optimized file creation |
ファイル作成操作をセルにオフロードして、データベース・ホストで保存されたI/Oバイト数。この統計は、最適化されたファイル作成操作の利点を示します。 |
cell physical IO bytes saved during optimized RMAN restore |
RMANのファイル・リストア操作をセルにオフロードして、データベース・ホストで保存されたI/Oバイト数。この統計は、最適化されたRMANのファイル・リストア操作の利点を示します。 |
cell physical IO bytes sent directly to DB node to balance CPU usage |
ストレージ・サーバーのCPU使用率が高いためにデータベース・サーバーに処理のために返されたI/Oバイト数。 |
cell physical IO interconnect bytes |
インターコネクト(データベース・ホストとセルの間)で交換されたI/Oバイト数。 |
cell physical IO interconnect bytes returned by smart scan |
スマート・スキャン操作のためにセルによって返されたI/Oバイト数。他のデータベースI/Oのバイト数は含まれません。 |
次の表では、スマートI/O操作の監視に役立つデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
| 待機イベント | 説明 |
|---|---|
cell external table smart scan |
この待機イベントは、セルで外部表スキャンを待機しているときに表示されます。
|
cell smart file creation(セルのスマート・ファイル作成) |
この待機イベントは、セルでファイル作成が完了するのをデータベースが待機しているときに表示されます。
|
cell smart incremental backup(セルのスマート増分バックアップ) |
この待機イベントは、セルで増分バックアップが完了するのをデータベースが待機しているときに表示されます。
|
cell smart index scan(セルのスマート索引スキャン) |
この待機イベントは、索引高速フル・スキャンを待機しているときに表示されます。
|
cell smart index scan: db timezone upgrade |
この待機イベントは、データベース・タイムゾーンのアップグレードが進行中のためにセルがオフロードできないときに表示されます。 |
cell smart index scan: disabled by user |
この待機イベントは、ユーザー設定が原因でセルがオフロードできないときに表示されます。 |
cell smart index scan: pass through |
この待機イベントは、セルがスマート・スキャンをオフロードできないときに表示されます。 |
cell smart index scan request |
これは 待機イベントが終了すると、プレースホルダは通常 |
cell smart restore from backup(バックアップからのセルのスマート・リストア) |
この待機イベントは、セルでバックアップからのリストアのファイル初期化が完了するのをデータベースが待機しているときに表示されます。
|
cell smart table scan(セルのスマート表スキャン) |
この待機イベントは、セルでスマート・スキャンが完了するのをデータベースが待機しているときに表示されます。
|
cell smart table scan: db timezone upgrade |
この待機イベントは、データベース・タイムゾーンのアップグレードが進行中のためにセルがオフロードできないときに表示されます。 |
cell smart table scan: disabled by user |
この待機イベントは、ユーザー設定が原因でセルがオフロードできないときに表示されます。 |
cell smart table scan: pass through |
この待機イベントは、セルがスマート・スキャンをオフロードできないときに表示されます。 |
cell smart table scan request |
これは 待機イベントが終了すると、プレースホルダは通常 |
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。
親トピック: スマートI/Oの監視
6.3.7.3 SQLモニターを使用したスマートI/Oの監視
Oracle Databaseには、動的パフォーマンス・ビューおよび待機イベントに加えて、個々のSQL文の実行を監視できるSQLモニターが用意されています。
SQLモニター・レポートには、スマートI/O操作に関する追加情報を含む、行ソースの詳細な統計が含まれます。行ソース統計は、行ソースの双眼鏡をクリックすることで、Enterprise ManagerのアクティブなSQLモニター・レポートに表示できます。たとえば:
図6-24 SQLモニター・レポート: スマートI/O行ソース統計
次の表では、スマートI/Oの監視に役立つ、SQLモニターによって提供される様々な行ソース統計について説明します。
| 統計 | 説明 |
|---|---|
Filtered bytes |
セルによって返されたバイト数。 |
Cell passthru IO bytes |
オフロードされず、処理のためにデータベースに返されたバイト数。 |
Cell passthru IO bytes due to quarantine |
セルに対する検疫が原因でオフロードされず、処理のためにデータベースに返されたバイト数。 |
Eligible bytes for smart IO |
条件のオフロードの対象となる実際のバイト数。 たとえば、列キャッシュを使用する場合、これはディスク上のサイズではなく列キャッシュのサイズです。 |
SI saved bytes |
ストレージ索引によって保存されたバイト数。つまり読み取る必要がなかったバイト数。 |
Columnar cache saved bytes |
列キャッシュによって保存されたバイト数。つまり読み取る必要がなかったバイト数。 |
Partial flash cache and disk bytes |
Exadataスマート・フラッシュ・キャッシュとディスクの両方から読み取られたバイト数。 |
Flash cache bytes |
Exadataスマート・フラッシュ・キャッシュから読み取られたバイト数。 |
IM Capacity bytes |
列キャッシュからmemcompress for capacity形式で読み取られたバイト数。
|
IM Query bytes |
列キャッシュからmemcompress for query形式で読み取られたバイト数。
|
No memcompress bytes |
列キャッシュからno memcompress形式で読み取られたバイト数。
|
Bytes added to storage index |
スマート・スキャン中にストレージ索引に追加されたバイト数。これは、ストレージ索引が作成中であることを示します。 |
cell IORM IO requests on flash |
フラッシュ・ストレージに対する物理I/Oリクエスト数。 |
cell IORM wait time on flash (us) |
IORMがフラッシュ・リクエストをキューに入れた時間(マイクロ秒)。
|
cell IORM IO requests on disk |
ディスク・ストレージに対する物理I/Oリクエスト数。 |
cell IORM wait time on disk (us) |
IORMがディスク・リクエストをキューに入れた時間(マイクロ秒)。
|
Block IO bytes |
ブロックI/Oモードのバイト数。 |
|
|
データベース・コンピュート・ノードからセルに送信された問合せメタデータのサイズ。 |
Eligible bytes |
条件のオフロードの対象となるディスク上のバイト数。 |
特定の統計の可用性は、使用しているOracle Databaseのバージョンによって決まります。
6.3.7.4 SQL実行計画を使用したスマートI/Oの監視
SQL EXPLAIN PLANコマンドは、SQL実行計画のスマートI/O最適化に関する情報を表示します。
EXPLAIN PLANコマンドを使用すると、ストレージ・サーバーにオフロードできるSQL問合せの一部を識別できます。SQL実行計画のスマートI/O最適化を表示するには、EXPLAIN PLANコマンドのデータベース・パラメータCELL_OFFLOAD_PLAN_DISPLAYをAUTOまたはALWAYSに設定する必要があります。
例6-5 SQL実行計画を使用したスマートI/Oの監視
この例は、EXPLAIN PLANコマンドを使用して、SQL実行計画のスマートI/O最適化を表示する方法を示しています。
問合せ計画では、TABLE ACCESS STORAGE FULL操作は、対応する全表スキャンがストレージ・サーバーにオフロードされることを示します。条件情報には、ストレージ・サーバーにオフロードされる問合せ条件の詳細が示されます。
SQL> ALTER SESSION SET CELL_OFFLOAD_PLAN_DISPLAY = ALWAYS;
Session altered.
SQL> EXPLAIN PLAN FOR
SELECT t.prod_id, v.exp1, t2_prod_id, t2_amount_sold
FROM sales t, v1 v
WHERE t.prod_id = v.prod_id AND t.cust_id = v.cust_id
AND t.prod_id != 45
AND v.amount_sold * v.quantity_sold > 10000;
Explained.
SQL> SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------
Plan hash value: 2267424675
--------------------------------------------------
| Id | Operation | Name |
--------------------------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | HASH JOIN | |
|* 2 | HASH JOIN | |
|* 3 | TABLE ACCESS STORAGE FULL| SALES |
|* 4 | TABLE ACCESS STORAGE FULL| SALES |
|* 5 | TABLE ACCESS STORAGE FULL | SALES |
--------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("T"."CUST_ID"="T2"."CUST_ID" AND
"T1"."PROD_ID"="T2"."PROD_ID" AND "T1"."CUST_ID"="T2"."CUST_ID")
2 - access("T"."PROD_ID"="T1"."PROD_ID")
3 - storage("T1"."PROD_ID"<200 AND
"T1"."AMOUNT_SOLD"*"T1"."QUANTITY_SOLD">10000 AND "T1"."PROD_ID"<>45)
filter("T1"."PROD_ID"<200 AND
"T1"."AMOUNT_SOLD"*"T1"."QUANTITY_SOLD">10000 AND "T1"."PROD_ID"<>45)
4 - storage("T"."PROD_ID"<200 AND "T"."PROD_ID"<>45)
filter("T"."PROD_ID"<200 AND "T"."PROD_ID"<>45)
5 - storage("T2"."PROD_ID"<200 AND "T2"."PROD_ID"<>45)
filter("T2"."PROD_ID"<200 AND "T2"."PROD_ID"<>45)
親トピック: スマートI/Oの監視
6.3.7.5 Exadataメトリックを使用したスマートI/Oの監視
スマートI/Oのメトリックは、objectType=SMARTIOであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
cumulativeメトリックの場合は、様々なcollectionTime期間から値を減算することにより、特定の期間のメトリック値を算出できます。
例6-6 スマートI/Oのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なスマートI/Oのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = SMARTIO
SIO_IO_EL_OF "Cumulative number of megabytes eligible for smart IO offload"
SIO_IO_EL_OF_SEC "Number of megabytes per second eligible for smart IO offload"
SIO_IO_OF_RE "Cumulative number of interconnect megabytes returned by smart IO"
SIO_IO_OF_RE_SEC "Number of interconnect megabytes per second returned by smart IO"
SIO_IO_PA_TH "Cumulative number of megabytes of passthru IOs by smart IO"
SIO_IO_PA_TH_SEC "Number of megabytes per second of passthru IOs by smart IO"
SIO_IO_RD_FC "Cumulative number of megabytes read from flash cache by smart IO"
SIO_IO_RD_FC_HD "Cumulative number of megabytes read from both flash cache and hard disk by smart IO"
SIO_IO_RD_FC_HD_SEC "Number of megabytes per second read from both flash cache and hard disk by smart IO"
SIO_IO_RD_FC_SEC "Number of megabytes per second read from flash cache by smart IO"
SIO_IO_RD_HD "Cumulative number of megabytes read from hard disk by smart IO"
SIO_IO_RD_HD_SEC "Number of megabytes per second read from hard disk by smart IO"
SIO_IO_RD_RQ_FC "Cumulative number of read IO requests from flash cache by smart IO"
SIO_IO_RD_RQ_FC_HD "Cumulative number of read IO requests from both flash cache and hard disk by smart IO"
SIO_IO_RD_RQ_FC_HD_SEC "Number of read IO requests per second from both flash cache and hard disk by smart IO"
SIO_IO_RD_RQ_FC_SEC "Number of read IO requests per second from flash cache by smart IO"
SIO_IO_RD_RQ_HD "Cumulative number of read IO requests from hard disk by smart IO"
SIO_IO_RD_RQ_HD_SEC "Number of read IO requests per second from hard disk by smart IO"
SIO_IO_RV_OF "Cumulative number of megabytes sent to DB node to balance CPU by smart IO"
SIO_IO_RV_OF_SEC "Number of megabytes per second sent to DB node to balance CPU by smart IO"
SIO_IO_SI_SV "Cumulative number of megabytes saved by storage index"
SIO_IO_SI_SV_SEC "Number of megabytes per second saved by storage index"
SIO_IO_WR_FC "Cumulative number of megabytes of flash cache population writes by smart IO"
SIO_IO_WR_FC_SEC "Number of megabytes per second of flash cache population writes by smart IO"
SIO_IO_WR_HD "Cumulative number of megabytes written to hard disk by smart IO"
SIO_IO_WR_HD_SEC "Number of megabytes per second written to hard disk by smart IO"
SIO_IO_WR_RQ_FC "Cumulative number of IO requests for flash cache population writes by smart IO"
SIO_IO_WR_RQ_FC_SEC "Number of IO requests per second for flash cache population writes by smart IO"
SIO_IO_WR_RQ_HD "Cumulative number of write IO requests to hard disk by smart IO"
SIO_IO_WR_RQ_HD_SEC "Number of write IO requests per second to hard disk by smart IO"列キャッシュ・メトリックは、name like 'FC_COL.*'を持つものとして識別されます
例6-7 列キャッシュのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能な列キャッシュのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE NAME LIKE 'FC_COL.*'
FC_COL_BYKEEP_USED "Number of megabytes used for keep objects in Columnar FlashCache"
FC_COL_BY_USED "Number of megabytes used in Columnar FlashCache"
FC_COL_IO_BYKEEP_R "Number of megabytes read from Columnar FlashCache for keep objects"
FC_COL_IO_BYKEEP_R_SEC "Number of megabytes read per second from Columnar FlashCache for keep objects"
FC_COL_IO_BY_R "Number of megabytes that were read from Columnar FlashCache"
FC_COL_IO_BY_R_ELIGIBLE "Number of megabytes eligible to read from Columnar FlashCache"
FC_COL_IO_BY_R_ELIGIBLE_SEC "Number of megabytes per second eligible to read from Columnar FlashCache"
FC_COL_IO_BY_R_SEC "Number of megabytes per second that were read from Columnar FlashCache"
FC_COL_IO_BY_SAVED "Number of megabytes saved by reads from Columnar FlashCache"
FC_COL_IO_BY_SAVED_SEC "Number of megabytes saved per second by reads from Columnar FlashCache"
FC_COL_IO_BY_W_POPULATE "Number of megabytes that are population writes into Columnar FlashCache due to read miss"
FC_COL_IO_BY_W_POPULATE_SEC "Number of megabytes per second that are population writes into Columnar FlashCache due to read miss"
FC_COL_IO_RQKEEP_R "Number of requests read for keep objects from Columnar FlashCache"
FC_COL_IO_RQKEEP_R_SEC "Number of requests read per second for keep objects from Columnar FlashCache"
FC_COL_IO_RQ_R "Number of requests that were read from Columnar FlashCache"
FC_COL_IO_RQ_R_ELIGIBLE "Number of reads eligible for Columnar FlashCache"
FC_COL_IO_RQ_R_ELIGIBLE_SEC "Number of reads per second eligible for Columnar FlashCache"
FC_COL_IO_RQ_R_SEC "Number of requests per second that were read from Columnar FlashCache"
FC_COL_IO_RQ_W_POPULATE "Number of requests that are population writes into Columnar FlashCache due to read miss"
FC_COL_IO_RQ_W_POPULATE_SEC "Number of requests per second that are population writes into Columnar FlashCache due to read miss"親トピック: スマートI/Oの監視
6.3.7.6 スマートI/Oを監視する際の注意事項
スマートI/Oが期待どおりに実行されない
スマートI/O操作は、通常、行ソースで全表スキャンまたは索引高速フル・スキャンが実行された場合に発生します。スマートI/O操作が期待どおりに機能しない場合、問合せの経過時間が著しく増加する傾向があります。場合によっては、データベースでcell smart table scanの待機時間の増加が示されます。ただし、cell smart table scanのかわりにcell multiblock physical readやdirect path readなどの待機イベントが存在する場合、これはスマートI/O操作が実行されていないことを示しています。
スマートI/O操作が期待どおりに実行されない原因を説明する症状と理由を次に示します。
-
直接読取りはスマート・スキャンの前提条件です。直接読取りなしでスマート・スキャンを実行することはできません。
cell multiblock physical read待機イベントは、ブロックがバッファ・キャッシュに読み込まれるときに発生します。直接読取りを使用しないでバッファ・キャッシュに読み込む一般的な理由は、セグメントのサイズです。小さいセグメントの場合、オプティマイザは直接読取りよりバッファ・キャッシュを優先します。また、設計上、Oracle Database共有サーバー・セッションではダイレクト読取りを使用しません。そのため、共有サーバー・セッションによって発行されたシリアル問合せはスマート・スキャンの対象になりません。共有サーバー・セッションで発行されたパラレル問合せの場合、パラレル・ワーカー・プロセスで直接読取り(およびスマート・スキャン)を使用できますが、共有サーバーは問合せの全期間中、問合せによりブロックされます。
-
direct path read待機イベントは、直接読取りが実行されたが、条件がストレージ・サーバーにオフロードされない場合に発生します。このことは、ストレージ・サーバーのリソースが不足している場合に発生することがあります。たとえば、システムでの多数の同時パラレル問合せが原因でメモリー不足が発生する場合があります。このようなリソース不足は、通常、
ExaWatcherデータからわかります。特に、cellsrvstatのNumber of low memory threshold failuresやNumber of no memory threhsold failuresなどの統計を確認できます。ExaWatcherには、ストレージ・サーバーでメモリーがどのように消費されているかを示すcellmem収集も含まれ、これはGetExaWatcherResults.shを使用して生成されたExaWatcherチャートに表示されます。この問題に対処するには、パラレル問合せの使用について確認し、アクティブなパラレル問合せサーバーの数を減らすことができます。
-
コミットされていないデータがある場合、条件のオフロードはできません。このことは、通常、大規模なバッチ操作によってデータが変更され、大量のコミットされていないデータに対して大規模な問合せを実行しようとすると問題になります。
スマート・スキャンがコミットされていないデータを検出した場合、条件フィルタリングをストレージ・サーバーにオフロードできず、追加データをデータベース・サーバーに転送して戻す必要があり、これによりスマート・スキャンによって返されたバイト数が増加するように見えます。また、読取り一貫性のあるデータのコピーを作成するには、データベース・サーバーで追加の処理が必要になります。これは、次の方法で示されます。
- 最良のシナリオでは、読取り一貫性のあるデータのコピーを作成するために、追加の
buffer getsまたはsession logical readsが必要です。 - UNDOバッファが別のデータベース・インスタンスに存在する場合は、Oracle RAC関連の待機イベントも観測されることがあります。Oracle RAC関連の待機イベントには、接頭辞
gcが付きます。 - UNDOブロックがどのデータベース・インスタンスのバッファ・キャッシュにも存在しない場合、読取り一貫性のために必要な単一ブロックI/Oとともに、追加の
cell single block physical read待機が観測されます。追加のI/Oは、操作のパフォーマンスに大きく影響する可能性があります。
- 最良のシナリオでは、読取り一貫性のあるデータのコピーを作成するために、追加の
-
ストレージ・サーバーのCPU使用率が高い場合、ストレージ・サーバーは、条件評価を実行するためにストレージ・サーバーのCPUをさらに消費するのではなく、処理のためにデータベースにデータを送信します。これは逆オフロードと呼ばれます。
このことが発生した場合は、AWRレポートのSmart IOセクションの
Reverse Offload列およびデータベース統計cell physical IO bytes sent directly to DB node to balance CPU usageでそれがわかります。ストレージ・サーバーのCPU使用率が高いのは、オフロードされる条件のタイプが原因である可能性があります。たとえば、大/小文字を区別しない検索や
REGEXP_LIKEの使用では、単純な条件よりも多くのCPUが使用されます。ストレージ・サーバーのCPUおよびI/O負荷の増加は、データベースでのSQL実行計画の変更が原因である場合もあります。この場合、実行計画を確認し、影響を受けるSQL文をチューニングすると、問題を解決できることがあります。
-
ストレージ・サーバーが条件評価を実行できない場合、処理のためにデータをデータベースに送信します。これはパススルーとも呼ばれます。次のすべてのことは、パススルーが発生していることを示しています。
- 対象となるバイトと比較して、AWRレポートのSmart IOセクションの
Passthru列の値が大きい。 cell physical IO bytes eligible for smart IOと比較して、データベース統計cell num bytes in passthru during predicate offloadの値が大きい。Eligible bytes for Smart IO値と比較して、SQLモニターの行ソース統計Cell passthru IO bytesの値が大きい。
考えられる原因には、次のものがあります。
-
検疫 — 確認するには、データベース統計
cell num bytes in passthru due to quarantineまたはSQLモニターの行ソース統計Cell passthru IO bytes due to quarantineを確認します。 - データベース・タイムゾーンのアップグレード — データベース・タイムゾーンのアップグレードが進行中の場合、スマート・スキャンは無効になります。AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションのデータベース統計
cell num smart IO sessions using passthru mode due to timezoneを確認するか、Smart IOセクションのパススルー理由を確認します。データベース・リリースに応じて、cell smart table scan: db timezone upgradeまたはcell smart index scan: db timezone upgrade待機イベントが観測されることもあります。 - ユーザー設定 — ユーザーまたはアプリケーションにより、スマート・スキャンを無効にする
cell_offload_processing=falseが設定されている可能性があります。確認するには、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションのデータベース統計cell num smart IO sessions using passthru mode due to userを確認するか、Smart IOセクションのパススルー理由を確認します。データベース・リリースに応じて、cell smart table scan: disabled by userまたはcell smart index scan: disabled user待機イベントが観測されることもあります。 - 操作をオフロードできない — ストレージ・サーバーが条件のオフロードを実行できない他の理由があります。この発生のインスタンスは、データベース統計
cell num smart IO sessions using passthru mode due to cellsrv、待機イベントcell smart table scan: passthroughまたはcell smart index scan: passthroughに示されます。次の項では、その理由について詳しく説明します。
- 対象となるバイトと比較して、AWRレポートのSmart IOセクションの
-
状況によっては、スマートI/Oを使用して通常実行される操作のOracle DatabaseがブロックI/Oモードに戻ります。これが発生すると、データベース統計
cell num bytes in block IO during predicate offloadで明らかになります。基礎となる原因に関するインサイトを提供する追加の関連統計があります。これらの統計には、
cell num smart IO sessions in rdbms block IO due toで始まる名前が付いています。たとえば、cell num smart IO sessions in rdbms block IO due to online encrは、スマートI/Oの使用を妨げる進行中のオンライン暗号化操作が原因でブロックI/Oモードに戻されるセッションをカウントします。
操作がオフロードされない
次の場合、スマートI/O操作はExadataストレージ・サーバーにオフロードできません。
- クラスタ表でスキャンが実行される場合
- 索引構成表でスキャンが実行される場合
- 逆キー索引で高速全スキャンが実行される場合
- 表で行の依存性が有効になっている場合や、
rowscnがフェッチされている場合 - オプティマイザでスキャンを実行して
ROWIDの順で行を返す場合 - コマンド
CREATE INDEXでnosortを使用する場合 LONG列を選択または問合せ中の場合。- 問合せに圧縮または表外の
LOBが含まれている場合。表外のLOBには、他の行データとは別にLOBデータが格納されます。通常は4KBを超えるサイズです。 - 表で
SELECT ... VERSIONS問合せを実行する場合 - 255を超える列が参照される問合せで、ヒープ表が圧縮されていないか、基本圧縮またはOLTP圧縮である場合。ただし、Exadataハイブリッド列圧縮を使用して圧縮された表に対するこのような問合せはオフロードされます。
- 表領域が暗号化されており、
CELL_OFFLOAD_DECRYPTIONパラメータがFALSEに設定されている場合。Oracle Exadata System Softwareで復号化を実行するには、Oracle Databaseからストレージ・サーバーに復号化キーを送信する必要があります。ネットワークを介してストレージ・サーバーにキーを送信することに関してセキュリティ上の懸念がある場合、通常、この機能は無効にします - 表領域がOracle Exadata Storage Serverに完全に格納されない場合。
- 条件評価が仮想列にある場合。
- オフロードはほとんどのSQL演算子および関数でサポートされていますが、Oracle Exadata System Softwareでは一部のSQL演算子および関数のオフロードがサポートされていません。動的パフォーマンス・ビュー
V$SQLFN_METADATAには、オフロードがSQL演算子または関数でサポートされているかどうかに関する情報が含まれます。OFFLOADABLE列にYESが含まれる場合、対応する演算子または関数でオフロードがサポートされています。NOは、対応する演算子または関数でオフロードがサポートされていないことを示します。
ストレージ索引が期待どおりに実行されない
ストレージ索引はストレージ・サーバー・メモリーに存在します。永続ストレージ索引機能(Oracle Exadata System Softwareリリース21.2.0で導入)より前は、cellsrvを停止するたびにストレージ索引が失われるため、cellsrvの起動後に再構築する必要がありました。したがって、永続ストレージ索引機能が有効になっていないシステムでは、cellsrvが起動するたびにストレージ索引をすぐに使用できるわけではありません。
永続ストレージ索引機能を有効にしたシステムでは、ストレージ索引は共有メモリーに存在し、cellsrvを再起動しても保持されます。さらに、ストレージ索引データは、サーバーの正常な停止時に永続ストレージに自動的に保存されます。サーバーの再起動中、ストレージ索引は自動的にリストアされますが、リストア・プロセス中は使用できません。また、ストレージ・サーバーで異常な停止(停電やカーネル・パニックなど)が発生した場合は、ストレージ索引が失われるため、完全に再構築する必要があります。
暗号化されていない表領域のセグメントでは、DMLが発生したときにストレージ索引は保持されます。一方、暗号化された表領域のセグメントでは、DMLにより、変更された各データ・チャンク(1 MB)に関連付けられているストレージ索引の部分が無効化されます。無効化されたチャンクは、セグメントの次回のスキャン中に再構築されます。ただし、一部が無効になっていますが、ストレージ索引の全体的な効率は最適ではありません。
ストレージ索引のパフォーマンスを監視するには、次のものを監視します。
-
AWRレポートのスマートIOセクションの
ストレージ索引列。 -
データベース統計
cell physical IO bytes saved by storage index。 -
SQLモニターの行ソース統計
SI saved bytes。
ストレージ索引がまだ構築(または再構築)されていない場合は、ストレージ索引の保存が減少して表示されることがあります。ストレージ索引の作成中に、データベース統計cell physical IO bytes added to storage indexおよびSQLモニターの行ソース統計Bytes added to storage indexが増加することがわかります。
列キャッシュが期待どおりに実行されない
ストレージ索引と同様に、列キャッシュがまだ構築(または再構築)されていない場合は、列キャッシュに関連付けられている保存が減少して表示されることがあります。列キャッシュのパフォーマンスを監視するには、AWRレポートのColumnar Cache セクション、データベース統計cell physical IO bytes saved by columnar cacheまたはSQLモニターの行ソース統計Columnar cache saved bytesを監視します。
ストレージ索引と同様に、列キャッシュはcellsrvが起動するたびに再構築されます。したがって、列キャッシュは、cellsrvの起動直後に操作のメリットを得ることはできません。
列キャッシュは、スマート・スキャンの実行時にストレージ・サーバーによって自動的に移入および管理されます。非圧縮セグメント、OLTP圧縮を使用して圧縮されたセグメントおよびExadataハイブリッド列圧縮を使用して圧縮されたセグメントに対するスマート・スキャン操作の場合、データはスマート・スキャンの一部として列キャッシュ形式(no memcompress)に自動的に変換されます。
ただし、Oracle Database In-Memoryを使用している場合、データはバックグラウンド・プロセスを使用してOracle Database In-Memoryの列形式(memcompress for queryまたはmemcompress for capacity)にリライトされます。したがって、そのデータに対する操作には、キャッシュが再移入されるまで、Oracle Database In-Memoryの最適化の効果がありません。移入ジョブの詳細は、AWRレポートのColumnar Cache Populationセクションに示されます。
列キャッシュからの読取りが少ない場合は、データベース統計の値(cell physical IO bytes processed for IM Query、cell physical IO bytes processed for IM Capacityまたはcell physical IO bytes processed for no memcompress)が小さくなることで、それがわかります。これに相当するSQLモニターの行ソース統計は、IM Query bytes、IM Capacity bytesおよびNo memcompress bytesです。
親トピック: スマートI/Oの監視
6.3.8 I/Oリソース管理(IORM)の監視
Exadata I/Oリソース管理(IORM)では、複数のデータベースおよびプラガブル・データベース(PDB)で同じストレージを共有できるだけでなく、システムを共有する様々なデータベースにI/Oリソースを適切に割り当てることができます。これにより、1つのデータベースでI/O帯域幅全体を使用して他のデータベースのパフォーマンスが低下することがなくなります。また、IORMは、Oracle Database Resource Managerと連携して、単一データベース内の複数のコンシューマ・グループ間のI/Oリソースを管理します。
6.3.8.1 AWRを使用したI/Oリソース管理(IORM)の監視
AWRレポートには、Exadataシステムで実行中の上位データベースに関する情報が含まれます。この情報を使用すると、AWRレポートをホストするデータベースに関係なく、システム全体のI/Oリソース使用量を監視できます。また、AWRレポートにはセルごとの統計が含まれているため、セル間のI/Oリソース使用率に偏りがあるかどうかを簡単に判断できます。
AWRレポートには次のものが含まれます。
-
Top Databases by IO Requests — すべてのセルでI/Oリクエスト数が最も多いデータベースの統計を提供します。また、リクエストをデバイス・タイプ(フラッシュまたはディスク)別およびサイズ(小または大)別に分類します。
-
Top Databases by Requests - Details — I/Oリクエストに関する追加の統計を提供します。具体的には、I/Oリクエストの平均レイテンシおよび平均キュー時間が表示されます。キュー時間は、I/Oリクエストが関連するI/Oキューに費やす時間です。長いキュー時間は、IORMがI/Oを抑制していることを示しています。
-
Top Databases by IO Requests per Cell — 各セルでI/Oリクエスト数が最も多いデータベースの統計を提供します。また、リクエストをデバイス・タイプ(フラッシュまたはディスク)別およびサイズ(小または大)別に分類します。この情報を使用すると、データベースからのI/Oリクエストを処理するときに、セルの動作が異なっているかどうかを簡単に判断できます。
-
Top Databases by IO Requests per Cell - Details — 各セルのI/Oリクエストに関する追加の統計を提供します。具体的には、各セルのI/Oリクエストの平均レイテンシおよび平均キュー時間が表示されます。この情報を使用すると、セルのIORMの動作が異なっているかどうかを簡単に判断できます。
-
Top Databases by IO Throughput — すべてのセルでI/Oスループットが最大のデータベースの統計を提供します。また、スループットをデバイス・タイプ(フラッシュまたはディスク)別およびリクエスト・サイズ(小または大)別に分類します。
-
Top Databases by Throughput per Cell — 各セルでI/Oスループットが最大のデータベースの統計を提供します。また、スループットをデバイス・タイプ(フラッシュまたはディスク)別およびリクエスト・サイズ(小または大)別に分類します。この情報を使用すると、データベースからのI/Oを処理するときに、セルの動作が異なっているかどうかを簡単に判断できます。
AWRレポートには、Exadataシステムで実行されているすべてのデータベースに関する情報が表示されない場合があります。これは、ストレージ・サーバーの大部分のI/Oを処理するデータベースに焦点を当てるように設計されています。より詳細な情報が必要な場合は、IORMセル・メトリックを使用する必要があります。
マルチテナント・コンテナ・データベース(CDB)の場合、AWRレポートの統計には、データベース(すべてのプラガブル・データベース(PDB)を含む)に関連付けられているすべてのI/Oが含まれます。
次の例は、AWRレポートのTop Databases by IO Requests・セクションおよびTop Databases by Requests - Detailsセクションを示しています。Top Databases by IO Requests・セクションは、DB1データベースによってAWRで取得されたI/Oリクエストの46%が生成されていることを示しています。また、DB1データベースに関連付けられたI/Oリクエストの約10%がディスク・デバイスに対するI/Oリクエストであることも示しています(合計I/Oリクエスト564,616,086のうちディスクI/Oリクエストが51,854,884)。Top Databases by Requests - Detailsセクションには、ほとんどの場合、すべてのデータベースで最小のIORM待機時間(キュー時間 < 1ミリ秒)が表示されます。例外は、DB1データベースのフラッシュに対するLarge IOリクエストで、それぞれの平均キュー時間は9.12ミリ秒です。
図6-25 AWRレポート: IOリクエスト別の上位データベース
親トピック: I/Oリソース管理(IORM)の監視
6.3.8.2 データベース統計を使用したI/Oリソース管理(IORM)の監視
次の表では、I/Oリソース管理(IORM)の監視に役立つデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
Session total flash IO requests |
フラッシュに対する物理I/Oリクエストの合計数。 |
Session IORM flash wait time |
フラッシュI/OリクエストのIORM待機時間の合計(マイクロ秒)。 フラッシュI/Oリクエストの平均IORM待機時間を算出するには、 |
PDB total disk IO requests |
ディスクに対する物理I/Oリクエストの合計数。 |
PDB IORM disk wait time |
ディスクI/OリクエストのIORM待機時間の合計(マイクロ秒)。 ディスクI/Oリクエストの平均IORM待機時間を算出するには、 |
特定の統計の可用性は、使用しているOracle Databaseのバージョンによって決まります。
親トピック: I/Oリソース管理(IORM)の監視
6.3.8.3 Exadataメトリックを使用したI/Oリソース管理(IORM)の監視
Oracle Exadata System Softwareのメトリックを使用すると、I/Oリソース管理(IORM)を監視できます。
IORMではデータベース識別子ではなくデータベースの一意名を使用して、統計を収集し、出力を表示します。Oracle Exadata System Softwareリリース19.1.0以降、データベースで使用されるOracle Automatic Storage Management (Oracle ASM)クラスタにASMを有効範囲にしたセキュリティを構成した場合、データベース名の先頭にOracle ASMクラスタ名が付きます。
- データベース・メトリックを使用したIORMの監視
データベース・メトリックは、IORMデータベース間プランにリストされた各データベースからのI/O負荷に関する情報を提供します。 - PDBメトリックを使用したIORMの監視
プラガブル・データベース(PDB)メトリックは、IORMデータベース間プランにリストされたコンテナ・データベース(CDB)によってホストされる各PDBからのI/O負荷に関する情報を提供します。 - コンシューマ・グループ・メトリックを使用したIORMの監視
コンシューマ・グループ・メトリックは、データベース・リソース・プランで指定した各コンシューマ・グループからのI/O負荷に関する情報を提供します。 - カテゴリ・メトリックを使用したIORMの監視
カテゴリ・メトリックは、現在のIORMカテゴリ・プランで指定した各カテゴリからのI/O負荷に関する情報を提供します。 - IORM使用率の監視
メトリックを使用してIORM使用率を監視できます。
親トピック: I/Oリソース管理(IORM)の監視
6.3.8.3.1 データベース・メトリックを使用したIORMの監視
データベース・メトリックは、IORMデータベース間プランにリストされた各データベースからのI/O負荷に関する情報を提供します。
データベース・メトリックは、objectType=IORM_DATABASEであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
例6-8 カテゴリのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なデータベース・メトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = IORM_DATABASE
DB_FC_BY_ALLOCATED "Number of megabytes allocated in flash cache for this database"
DB_FC_IO_BY_SEC "Number of megabytes of I/O per second for this database to flash cache"
DB_FC_IO_RQ "Number of IO requests issued by a database to flash cache"
DB_FC_IO_RQ_LG "Number of large IO requests issued by a database to flash cache"
DB_FC_IO_RQ_LG_SEC "Number of large IO requests issued by a database to flash cache per second"
DB_FC_IO_RQ_SEC "Number of IO requests issued by a database to flash cache per second"
DB_FC_IO_RQ_SM "Number of small IO requests issued by a database to flash cache"
DB_FC_IO_RQ_SM_SEC "Number of small IO requests issued by a database to flash cache per second"
DB_FD_IO_BY_SEC "Number of megabytes of I/O per second for this database to flash disks"
DB_FD_IO_LOAD "Average I/O load from this database for flash disks"
DB_FD_IO_RQ_LG "Number of large IO requests issued by a database to flash disks"
DB_FD_IO_RQ_LG_SEC "Number of large IO requests issued by a database to flash disks per second"
DB_FD_IO_RQ_SM "Number of small IO requests issued by a database to flash disks"
DB_FD_IO_RQ_SM_SEC "Number of small IO requests issued by a database to flash disks per second"
DB_FD_IO_TM "The cumulative latency of reading or writing blocks by a database from flash disks"
DB_FD_IO_TM_LG "The cumulative latency of reading or writing large blocks by a database from flash disks"
DB_FD_IO_TM_LG_RQ "The rate which is the average latency of reading or writing large blocks per request by a database from flash disks"
DB_FD_IO_TM_RQ "The rate which is the average latency of reading or writing blocks per request by a database from flash disks"
DB_FD_IO_TM_SM "The cumulative latency of reading or writing small blocks by a database from flash disks"
DB_FD_IO_TM_SM_RQ "The rate which is the average latency of reading or writing small blocks per request by a database from flash disks"
DB_FD_IO_UTIL "Percentage of flash resources utilized by this database"
DB_FD_IO_UTIL_LG "Percentage of flash resources utilized by large requests from this database"
DB_FD_IO_UTIL_SM "Percentage of flash resources utilized by small requests from this database"
DB_FD_IO_WT_LG "IORM wait time for large IO requests issued to flash disks by a database"
DB_FD_IO_WT_LG_RQ "Average IORM wait time per request for large IO requests issued to flash disks by a database"
DB_FD_IO_WT_SM "IORM wait time for small IO requests issued to flash disks by a database"
DB_FD_IO_WT_SM_RQ "Average IORM wait time per request for small IO requests issued to flash disks by a database"
DB_FL_IO_BY "The number of MB written to the Flash Log"
DB_FL_IO_BY_SEC "The number of MB written per second to the Flash Log"
DB_FL_IO_RQ "The number of I/O requests issued to the Flash Log"
DB_FL_IO_RQ_SEC "The number of I/O requests per second issued to the Flash Log"
DB_IO_BY_SEC "Number of megabytes of I/O per second for this database to hard disks"
DB_IO_LOAD "Average I/O load from this database for hard disks"
DB_IO_RQ_LG "Number of large IO requests issued by a database to hard disks"
DB_IO_RQ_LG_SEC "Number of large IO requests issued by a database to hard disks per second"
DB_IO_RQ_SM "Number of small IO requests issued by a database to hard disks"
DB_IO_RQ_SM_SEC "Number of small IO requests issued by a database to hard disks per second"
DB_IO_TM_LG "The cumulative latency of reading or writing large blocks by a database from hard disks"
DB_IO_TM_LG_RQ "The rate which is the average latency of reading or writing large blocks per request by a database from hard disks"
DB_IO_TM_SM "The cumulative latency of reading or writing small blocks by a database from hard disks"
DB_IO_TM_SM_RQ "The rate which is the average latency of reading or writing small blocks per request by a database from hard disks"
DB_IO_UTIL_LG "Percentage of disk resources utilized by large requests from this database"
DB_IO_UTIL_SM "Percentage of disk resources utilized by small requests from this database"
DB_IO_WT_LG "IORM wait time for large IO requests issued to hard disks by a database"
DB_IO_WT_LG_RQ "Average IORM wait time per request for large IO requests issued to hard disks by a database"
DB_IO_WT_SM "IORM wait time for small IO requests issued to hard disks by a database"
DB_IO_WT_SM_RQ "Average IORM wait time per request for small IO requests issued to hard disks by a database"
DB_XRM_BY_ALLOCATED "Number of megabytes allocated in XRMEM cache for this database"次の追加詳細に注意してください。
-
メトリックを表示するデータベースは、
METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName属性で指定されます。 -
I/O負荷に関連するメトリック(
DB_FD_IO_LOADやDB_IO_LOADなど)については、CD_IO_LOADに関連する追加情報を参照してください。 -
Oracle Exadata System Softwareリリース19.1.0以降、データベースで使用されるOracle Automatic Storage Management (Oracle ASM)クラスタにASMを有効範囲にしたセキュリティを構成した場合、データベース名の先頭にOracle ASMクラスタ名が付きます。
-
cumulativeメトリックの場合は、様々な
collectionTime期間から値を減算することにより、特定の期間のメトリック値を算出できます。 -
rateメトリックの場合は、メトリック値の期間は直前の1分間になります。
-
メトリックの説明では、Small IOリクエストは128 KB以下で、Large IOリクエストは128 KBを超えるものです。
-
すべてのデータベースの累積メトリックは、カテゴリ、IORMまたはデータベース・リソースのプランが変更されるとゼロにリセットされます。
-
データベース間プランのデータベース・メトリックの履歴を表示するには、次のCellCLIコマンドを使用します。
CellCLI> LIST METRICHISTORY WHERE objectType = 'IORM_DATABASE' AND metricValue != 0 ATTRIBUTES name, metricObjectName, metricValue, collectionTime - マルチテナント・コンテナ・データベース(CDB)の場合、データベース・メトリックの観測データには、データベース(関連付けられているすべてのプラガブル・データベース(PDB)を含む)に関連付けられているすべてのI/Oが含まれます。たとえば、
DB_FC_IO_BY_SECの値には、CDBによってホストされるすべてのPDBのPDB_FC_IO_BY_SECの値の合計が含まれます。 -
Oracle ASMおよびデータベース間プランにリストされていない他のすべてのデータベースの観測データは、
metricObjectName値として_OTHER_DATABASE_を使用してグループ化されます。
6.3.8.3.2 PDBメトリックを使用したIORMの監視
プラガブル・データベース(PDB)メトリックは、IORMデータベース間プランにリストされたコンテナ・データベース(CDB)によってホストされる各PDBからのI/O負荷に関する情報を提供します。
PDBメトリックは、objectType=IORM_PLUGGABLE_DATABASEであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
例6-9 PDBのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なPDBメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = IORM_PLUGGABLE_DATABASE
PDB_FC_BY_ALLOCATED "Number of megabytes allocated in flash cache for this pluggable database"
PDB_FC_IO_BY_SEC "Number of megabytes of I/O per second for this pluggable database to flash cache"
PDB_FC_IO_RQ "Number of IO requests issued by this pluggable database to flash cache"
PDB_FC_IO_RQ_LG "Number of large IO requests issued by this pluggable database to flash cache"
PDB_FC_IO_RQ_LG_SEC "Number of large IO requests issued by this pluggable database to flash cache per second"
PDB_FC_IO_RQ_SEC "Number of IO requests issued by this pluggable database to flash cache per second"
PDB_FC_IO_RQ_SM "Number of small IO requests issued by this pluggable database to flash cache"
PDB_FC_IO_RQ_SM_SEC "Number of small IO requests issued by this pluggable database to flash cache per second"
PDB_FD_IO_BY_SEC "Number of megabytes of I/O per second for this pluggable database to flash disks"
PDB_FD_IO_LOAD "Average I/O load from this pluggable database for flash disks"
PDB_FD_IO_RQ_LG "Number of large IO requests issued by this pluggable database to flash disks"
PDB_FD_IO_RQ_LG_SEC "Number of large IO requests issued by this pluggable database to flash disks per second"
PDB_FD_IO_RQ_SM "Number of small IO requests issued by this pluggable database to flash disks"
PDB_FD_IO_RQ_SM_SEC "Number of small IO requests issued by this pluggable database to flash disks per second"
PDB_FD_IO_TM "The cumulative latency of reading or writing blocks by this pluggable database from flash disks"
PDB_FD_IO_TM_LG "The cumulative latency of reading or writing large blocks by this pluggable database from flash disks"
PDB_FD_IO_TM_LG_RQ "The rate which is the average latency of reading or writing large blocks per request by this pluggable database from flash disks"
PDB_FD_IO_TM_RQ "The rate which is the average latency of reading or writing blocks per request by this pluggable database from flash disks"
PDB_FD_IO_TM_SM "The cumulative latency of reading or writing small blocks by this pluggable database from flash disks"
PDB_FD_IO_TM_SM_RQ "The rate which is the average latency of reading or writing small blocks per request by this pluggable database from flash disks"
PDB_FD_IO_UTIL "Percentage of flash resources utilized by this pluggable database"
PDB_FD_IO_UTIL_LG "Percentage of flash resources utilized by large requests from this pluggable database"
PDB_FD_IO_UTIL_SM "Percentage of flash resources utilized by small requests from this pluggable database"
PDB_FD_IO_WT_LG "IORM wait time for large IO requests issued to flash disks by this pluggable database"
PDB_FD_IO_WT_LG_RQ "Average IORM wait time per request for large IO requests issued to flash disks by this pluggable database"
PDB_FD_IO_WT_SM "IORM wait time for small IO requests issued to flash disks by this pluggable database"
PDB_FD_IO_WT_SM_RQ "Average IORM wait time per request for small IO requests issued to flash disks by this pluggable database"
PDB_IO_BY_SEC "Number of megabytes of I/O per second for this pluggable database to hard disks"
PDB_IO_LOAD "Average I/O load from this pluggable database for hard disks"
PDB_IO_RQ_LG "Number of large IO requests issued by this pluggable database to hard disks"
PDB_IO_RQ_LG_SEC "Number of large IO requests issued by this pluggable database to hard disks per second"
PDB_IO_RQ_SM "Number of small IO requests issued by this pluggable database to hard disks"
PDB_IO_RQ_SM_SEC "Number of small IO requests issued by this pluggable database to hard disks per second"
PDB_IO_TM_LG "The cumulative latency of reading or writing large blocks by this pluggable database from hard disks"
PDB_IO_TM_LG_RQ "The rate which is the average latency of reading or writing large blocks per request by this pluggable database from hard disks"
PDB_IO_TM_SM "The cumulative latency of reading or writing small blocks by this pluggable database from hard disks"
PDB_IO_TM_SM_RQ "The rate which is the average latency of reading or writing small blocks per request by this pluggable database from hard disks"
PDB_IO_UTIL_LG "Percentage of disk resources utilized by large requests from this pluggable database"
PDB_IO_UTIL_SM "Percentage of disk resources utilized by small requests from this pluggable database"
PDB_IO_WT_LG "IORM wait time for large IO requests issued to hard disks by this pluggable database"
PDB_IO_WT_LG_RQ "Average IORM wait time per request for large IO requests issued to hard disks by this pluggable database"
PDB_IO_WT_SM "IORM wait time for small IO requests issued to hard disks by this pluggable database"
PDB_IO_WT_SM_RQ "Average IORM wait time per request for small IO requests issued to hard disks by this pluggable database"
PDB_XRM_BY_ALLOCATED "Number of megabytes allocated in XRMEM cache for this pluggable database"次の追加詳細に注意してください。
-
メトリックを表示するPDBは、
METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName属性で指定されます。PDB名は、CDB名とPDB名を連結した名前です。 -
I/O負荷に関連するメトリック(
PDB_FD_IO_LOADやPDB_IO_LOADなど)については、CD_IO_LOADに関連する追加情報を参照してください。 -
Oracle Exadata System Softwareリリース19.1.0以降、データベースで使用されるOracle Automatic Storage Management (Oracle ASM)クラスタにASMを有効範囲にしたセキュリティを構成した場合、データベース名の先頭にOracle ASMクラスタ名が付きます。
-
cumulativeメトリックの場合は、様々な
collectionTime期間から値を減算することにより、特定の期間のメトリック値を算出できます。 -
rateメトリックの場合は、メトリック値の期間は直前の1分間になります。
-
メトリックの説明では、Small IOリクエストは128 KB以下で、Large IOリクエストは128 KBを超えるものです。
6.3.8.3.3 コンシューマ・グループ・メトリックを使用したIORMの監視
コンシューマ・グループ・メトリックは、データベース・リソース・プランで指定した各コンシューマ・グループからのI/O負荷に関する情報を提供します。
コンシューマ・グループ・メトリックは、objectType=IORM_CONSUMER_GROUPであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
例6-10 コンシューマ・グループのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なコンシューマ・グループのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = IORM_CONSUMER_GROUP
CG_FC_IO_BY_SEC "Number of megabytes of I/O per second for this consumer group to flash cache"
CG_FC_IO_RQ "Number of IO requests issued by a consumer group to flash cache"
CG_FC_IO_RQ_LG "Number of large IO requests issued by a consumer group to flash cache"
CG_FC_IO_RQ_LG_SEC "Number of large IO requests issued by a consumer group to flash cache per second"
CG_FC_IO_RQ_SEC "Number of IO requests issued by a consumer group to flash cache per second"
CG_FC_IO_RQ_SM "Number of small IO requests issued by a consumer group to flash cache"
CG_FC_IO_RQ_SM_SEC "Number of small IO requests issued by a consumer group to flash cache per second"
CG_FD_IO_BY_SEC "Number of megabytes of I/O per second for this consumer group to flash disks"
CG_FD_IO_LOAD "Average I/O load from this consumer group for flash disks"
CG_FD_IO_RQ_LG "Number of large IO requests issued by a consumer group to flash disks"
CG_FD_IO_RQ_LG_SEC "Number of large IO requests issued by a consumer group to flash disks per second"
CG_FD_IO_RQ_SM "Number of small IO requests issued by a consumer group to flash disks"
CG_FD_IO_RQ_SM_SEC "Number of small IO requests issued by a consumer group to flash disks per second"
CG_FD_IO_TM "The cumulative latency of reading or writing blocks by a consumer group from flash disks"
CG_FD_IO_TM_LG "The cumulative latency of reading or writing large blocks by a consumer group from flash disks"
CG_FD_IO_TM_LG_RQ "The rate which is the average latency of reading or writing large blocks per request by a consumer group from flash disks"
CG_FD_IO_TM_RQ "The rate which is the average latency of reading or writing blocks per request by a consumer group from flash disks"
CG_FD_IO_TM_SM "The cumulative latency of reading or writing small blocks by a consumer group from flash disks"
CG_FD_IO_TM_SM_RQ "The rate which is the average latency of reading or writing small blocks per request by a consumer group from flash disks"
CG_FD_IO_UTIL "Percentage of flash resources utilized by this consumer group"
CG_FD_IO_UTIL_LG "Percentage of flash resources utilized by large requests from this consumer group"
CG_FD_IO_UTIL_SM "Percentage of flash resources utilized by small requests from this consumer group"
CG_FD_IO_WT_LG "IORM wait time for large IO requests issued to flashdisks by a consumer group"
CG_FD_IO_WT_LG_RQ "Average IORM wait time per request for large IO requests issued to flash disks by a consumer group"
CG_FD_IO_WT_SM "IORM wait time for small IO requests issued to flashdisks by a consumer group"
CG_FD_IO_WT_SM_RQ "Average IORM wait time per request for small IO requests issued to flash disks by a consumer group"
CG_IO_BY_SEC "Number of megabytes of I/O per second for this consumer group to hard disks"
CG_IO_LOAD "Average I/O load from this consumer group for hard disks"
CG_IO_RQ_LG "Number of large IO requests issued by a consumer group to hard disks"
CG_IO_RQ_LG_SEC "Number of large IO requests issued by a consumer group to hard disks per second"
CG_IO_RQ_SM "Number of small IO requests issued by a consumer group to hard disks"
CG_IO_RQ_SM_SEC "Number of small IO requests issued by a consumer group to hard disks per second"
CG_IO_TM_LG "The cumulative latency of reading or writing large blocks by a consumer group from hard disks"
CG_IO_TM_LG_RQ "The rate which is the average latency of reading or writing large blocks per request by a consumer group from hard disks"
CG_IO_TM_SM "The cumulative latency of reading or writing small blocks by a consumer group from hard disks"
CG_IO_TM_SM_RQ "The rate which is the average latency of reading or writing small blocks per request by a consumer group from hard disks"
CG_IO_UTIL_LG "Percentage of disk resources utilized by large requests from this consumer group"
CG_IO_UTIL_SM "Percentage of disk resources utilized by small requests from this consumer group"
CG_IO_WT_LG "IORM wait time for large IO requests issued to hard disks by a consumer group"
CG_IO_WT_LG_RQ "Average IORM wait time per request for large IO requests issued to hard disks by a consumer group"
CG_IO_WT_SM "IORM wait time for small IO requests issued to hard disks by a consumer group"
CG_IO_WT_SM_RQ "Average IORM wait time per request for small IO requests issued to hard disks by a consumer group"次の追加詳細に注意してください。
-
メトリックを表示するコンシューマ・グループおよびデータベースは、
METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName属性で指定されます。名前の書式は、データベース名の後にピリオド(.)、コンシューマ・グループ名を続ける書式で指定します。たとえば、データベース名がPRODUCTIONDBでコンシューマ・グループ名がOLTPの場合、metricObjectNameはPRODUCTIONDB.OLTPになります。 -
I/O負荷に関連するメトリック(
CG_FD_IO_LOADやCG_IO_LOADなど)については、CD_IO_LOADに関連する追加情報を参照してください。 -
Oracle Exadata System Softwareリリース19.1.0以降、データベースで使用されるOracle Automatic Storage Management (Oracle ASM)クラスタにASMを有効範囲にしたセキュリティを構成した場合、データベース名の先頭にOracle ASMクラスタ名が付きます。
-
cumulativeメトリックの場合は、様々な
collectionTime期間から値を減算することにより、特定の期間のメトリック値を算出できます。 -
rateメトリックの場合は、メトリック値の期間は直前の1分間になります。
-
メトリックの説明では、Small IOリクエストは128 KB以下で、Large IOリクエストは128 KBを超えるものです。
-
すべてのコンシューマ・グループの累積メトリックは、カテゴリ、IORMまたはデータベース・リソースのプランが変更されるとゼロにリセットされます。
-
コンシューマ・グループの現在のメトリックを表示するには、次のCellCLIコマンドを使用します。
CellCLI> LIST METRICCURRENT WHERE objectType = 'IORM_CONSUMER_GROUP' AND metricValue != 0 ATTRIBUTES name, metricObjectName, metricValue, collectionTime -
Oracle ASMおよびそれ以外のすべてのデータベースでは、メトリックはBACKGROUNDおよびOTHERコンシューマ・グループで提供されます。BACKGROUNDコンシューマ・グループは次のとおりです。
-
_ORACLE_BACKGROUND_GROUP_: Oracle Databaseバックグラウンド・プロセスからの優先度の高いI/Oリクエスト -
_ORACLE_MEDPRIBG_GROUP_: Oracle Databaseバックグラウンド・プロセスからの優先度が中位のI/Oリクエスト -
_ORACLE_LOWPRIBG_GROUP_: Oracle Databaseバックグラウンド・プロセスからの優先度の低いI/Oリクエスト
-
6.3.8.3.4 カテゴリ・メトリックを使用したIORMの監視
カテゴリ・メトリックは、現在のIORMカテゴリ・プランで指定した各カテゴリからのI/O負荷に関する情報を提供します。
カテゴリ・メトリックは、objectType=IORM_CATEGORYであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
メトリックを表示するカテゴリは、METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName属性で指定されます。
cumulativeメトリックの場合は、様々なcollectionTime期間から値を減算することにより、特定の期間のメトリック値を算出できます。rateメトリックの場合は、メトリック値の期間は直前の1分間になります。
例6-11 カテゴリのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なカテゴリ・メトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = IORM_CATEGORY
CT_FC_IO_BY_SEC "Number of megabytes of I/O per second for this category to flash cache"
CT_FC_IO_RQ "Number of IO requests issued by an IORM category to flash cache"
CT_FC_IO_RQ_LG "Number of large IO requests issued by an IORM category to flash cache"
CT_FC_IO_RQ_LG_SEC "Number of large IO requests issued by an IORM category to flash cache per second"
CT_FC_IO_RQ_SEC "Number of IO requests issued by an IORM category to flash cache per second"
CT_FC_IO_RQ_SM "Number of small IO requests issued by an IORM category to flash cache"
CT_FC_IO_RQ_SM_SEC "Number of small IO requests issued by an IORM category to flash cache per second"
CT_FD_IO_BY_SEC "Number of megabytes of I/O per second for this category to flash disks"
CT_FD_IO_LOAD "Average I/O load from this category for flash disks"
CT_FD_IO_RQ_LG "Number of large IO requests issued by an IORM category to flash disks"
CT_FD_IO_RQ_LG_SEC "Number of large IO requests issued by an IORM category to flash disks per second"
CT_FD_IO_RQ_SM "Number of small IO requests issued by an IORM category to flash disks"
CT_FD_IO_RQ_SM_SEC "Number of small IO requests issued by an IORM category to flash disks per second"
CT_FD_IO_TM "The cumulative latency of reading or writing blocks for this category from flash disks"
CT_FD_IO_TM_LG "The cumulative latency of reading or writing large blocks for this category from flash disks"
CT_FD_IO_TM_LG_RQ "The rate which is the average latency of reading or writing large blocks per request for this category from flash disks"
CT_FD_IO_TM_RQ "The rate which is the average latency of reading or writing blocks per request for this category from flash disks"
CT_FD_IO_TM_SM "The cumulative latency of reading or writing small blocks for this category from flash disks"
CT_FD_IO_TM_SM_RQ "The rate which is the average latency of reading or writing small blocks per request for this category from flash disks"
CT_FD_IO_UTIL "Percentage of flash resources utilized by this category"
CT_FD_IO_UTIL_LG "Percentage of flash resources utilized by large requests from this category"
CT_FD_IO_UTIL_SM "Percentage of flash resources utilized by small requests from this category"
CT_FD_IO_WT_LG "IORM wait time for large IO requests issued to flash disks by an IORM category"
CT_FD_IO_WT_LG_RQ "Average IORM wait time per request for large IO requests issued to flash disks by an IORM category"
CT_FD_IO_WT_SM "IORM wait time for small IO requests issued to flash disks by an IORM category"
CT_FD_IO_WT_SM_RQ "Average IORM wait time per request for small IO requests issued to flash disks by an IORM category"
CT_IO_BY_SEC "Number of megabytes of I/O per second for this category to hard disks"
CT_IO_LOAD "Average I/O load from this category for hard disks"
CT_IO_RQ_LG "Number of large IO requests issued by an IORM category to hard disks"
CT_IO_RQ_LG_SEC "Number of large IO requests issued by an IORM category to hard disks per second"
CT_IO_RQ_SM "Number of small IO requests issued by an IORM category to hard disks"
CT_IO_RQ_SM_SEC "Number of small IO requests issued by an IORM category to hard disks per second"
CT_IO_TM_LG "The cumulative latency of reading or writing large blocks for this category from hard disks"
CT_IO_TM_LG_RQ "The rate which is the average latency of reading or writing large blocks per request for this category from hard disks"
CT_IO_TM_SM "The cumulative latency of reading or writing small blocks for this category from hard disks"
CT_IO_TM_SM_RQ "The rate which is the average latency of reading or writing small blocks per request for this category from hard disks"
CT_IO_UTIL_LG "Percentage of disk resources utilized by large requests from this category"
CT_IO_UTIL_SM "Percentage of disk resources utilized by small requests from this category"
CT_IO_WT_LG "IORM wait time for large IO requests issued to hard disks by an IORM category"
CT_IO_WT_LG_RQ "Average IORM wait time per request for large IO requests issued to hard disks by an IORM category"
CT_IO_WT_SM "IORM wait time for small IO requests issued to hard disks by an IORM category"
CT_IO_WT_SM_RQ "Average IORM wait time per request for small IO requests issued to hard disks by an IORM category"次の追加詳細に注意してください。
-
メトリックの説明では、Small IOリクエストは128 KB以下で、Large IOリクエストは128 KBを超えるものです。
- 待機メトリックの測定単位はミリ秒です。待機メトリックのメトリック名は、
CD_IO_WT_で始まります。 -
I/O負荷に関連するメトリック(
CT_FD_IO_LOADやCT_IO_LOADなど)については、CD_IO_LOADに関連する追加情報を参照してください。 -
すべてのカテゴリの累積メトリックは、カテゴリ、IORMまたはデータベース・リソースのプランが変更されるとゼロにリセットされます。
-
データベース間のプランのカテゴリ・メトリックの履歴を表示するには、次のCellCLIコマンドを使用します。
CellCLI> LIST METRICHISTORY WHERE objectType = 'IORM_CATEGORY' AND metricValue != 0 ATTRIBUTES name, metricObjectName, metricValue, collectionTime -
カテゴリ・メトリックは、内部生成および自動的に管理される次のカテゴリでも提供されます。
-
_ASM_: Oracle ASM関連のI/O -
_ORACLE_BG_CATEGORY_: Oracle Databaseバックグラウンド・プロセスで発行される優先度の高いI/O -
_ORACLE_MEDPRIBG_CATEGORY_: Oracle Databaseバックグラウンド・プロセスで発行される優先度が中位のI/O -
_ORACLE_LOWPRIBG_CATEGORY_: Oracle Databaseバックグラウンド・プロセスで発行される優先度の低いI/O
-
6.3.8.3.5 IORM使用率の監視
メトリックを使用してIORM使用率を監視できます。
OLTPワークロードとDSSワークロードがOracle Exadata Storage Serverを共有する場合は、短いレイテンシまたは高スループットのいずれに対して最適化するかがIORMにより決定されます。低レイテンシに対して最適化するには、Large IOリクエストの同時実行を減らしてI/O帯域幅が飽和しないようにします。高スループットに対して最適化するには、各Oracle Exadata Storage Serverで多くの大きい同時I/Oリクエストを処理し、最適化アルゴリズムの適用中にストレージをフルに使用できるようにする必要があります。ただし、セルに多くの大きい同時I/Oリクエストがある場合は、各I/Oは他のI/Oの後でキューに入れられるため、平均レイテンシが増加することがあります。
データベース、プラガブル・データベース(PDB)またはコンシューマ・グループからのI/Oリクエストの使用率メトリックは、データベース、PDBまたはコンシューマ・グループがストレージ・サーバーを使用した時間に対応します。Large IOリクエストは、Small IOリクエストよりも多くのストレージ・サーバーを使用します。次は、IORM最適化を決定する使用率メトリックを示したものです。
CG_IO_UTIL_LGCG_IO_UTIL_SMPDB_IO_UTIL_LGPDB_IO_UTIL_SMCT_IO_UTIL_LGCT_IO_UTIL_SMDB_IO_UTIL_LGDB_IO_UTIL_SM
データベース管理者は、I/Oリソース使用量とI/Oリソース割当てを比較することで、IORMをレイテンシまたはスループットに対してチューニングする必要があるかどうか、またはバランス調整するアプローチが最適かどうかを判断できます。IORMメトリックIORM_MODEは、IORMのモードを示しています。メトリック値は1から3の範囲内です。値の定義は次のとおりです。
ノート:
現在のプランでIORM属性objectiveがBASICに設定されている場合、IORM_MODEには意味がなく無視されます。
- 1はセルのIORM目標が
low_latencyに設定されていることを示します。 - 2はセルのIORM目標が
balancedに設定されていることを示します。 - 3はセルのIORM目標が
high_throughputに設定されていることを示します。
1から2の間または2から3の間の値は、IORMの目標がメトリック期間中に変更されたことを示し、正確な値は指定目標への近接度を示します。ワークロードの組合せが絶えず変化することも示しています。
6.3.8.4 I/Oリソース管理(IORM)を監視する際の注意事項
I/Oレイテンシ
IORMに問題がある場合は、通常、I/Oレイテンシが増加します。これは通常、cell single block physical readデータベース待機イベントおよび場合によってはcell smart table scanデータベース待機イベントのレイテンシが長くなるという特徴があります。これらのデータベース待機イベントが重要で、フラッシュまたはディスク・デバイスに関連付けられているストレージ・サーバーに対応するレイテンシがない場合、これはIORMがワークロードを抑制していることを示している可能性があります。
IORMスロットルが発生していることを確認するには:
- AWRレポートのTop Databases by Requests - Detailsセクションで、キュー時間列を確認します。この列には、IORMがデータベースのIOリクエストの抑制に費やした平均時間が表示されます。
- IORM待機時間のセル・メトリック(
DB_IO_WT_SM_RQ、DB_IO_WT_LG_RQ、PDB_IO_WT_SM_RQ、PDB_IO_WT_LG_RQおよびCG_IO_WT_SM_RQ)を確認します。
IORMデータベース統計およびAWRレポートを使用すると、I/Oワークロード全体を把握できます。Exadataメトリックを使用して、各カテゴリ、データベースまたはコンシューマ・グループ別のI/O使用量をさらに把握できます。統計およびメトリックを分析することで、カテゴリ、データベース、プラガブル・データベース(PDB)またはコンシューマ・グループの中で、リソース割当てを使用していないものや、リソース割当てを超えているものを把握できます。
待機時間が短いかゼロの場合は、プラン割当てで十分です。待機時間が長い場合、プラン割当ては不十分です。I/Oレイテンシが長いために待機時間が許容できないパフォーマンスになる場合は、IORMプランを調整して割当てを増やすか、必要なI/Oリソースを提供するために追加のストレージ・サーバーが必要になる場合があります。
iostatの使用
iostat (ExaWatcherによって収集される)を使用して監視されるデバイス使用率およびI/Oサービス時間統計は信頼できません。
次に、iostatのLinuxのmanページを示します。
svctm - The average service time (in milliseconds) for I/O requests that were issued to the device. Warning! Do not trust this field any more. This field will be removed in a future sysstat version. 使用率計算はI/Oサービス時間に依存するため、これも信頼できません。
セル・ディスク、データベース、プラガブル・データベースまたはコンシューマ・グループの実際のI/O使用率を監視するには、対応するIORMメトリックを使用します。
親トピック: I/Oリソース管理(IORM)の監視
6.3.9 セル・ディスクI/Oの監視
データベース・パフォーマンスの問題がExadataストレージ・サーバーのI/O負荷に関連する場合は、通常、I/O関連の待機イベントのレイテンシが増加し、User I/OまたはSystem I/OのWait Classのデータベース時間が増加します。データベース・レイテンシの増加がExadataストレージ・サーバーのパフォーマンスによるものである場合、増加したレイテンシもセル側の統計に示されます。システムが適切に実行されている期間の包括的なベースライン統計がある場合は、ベースライン統計を他の観測データと比較して差異を特定し、状況を明らかにできます。
たとえば、Oracle Databaseでcell single block physical readのレイテンシが増加したと報告された場合は、ストレージ・サーバーの統計をチェックし、それらをベースラインと比較して、原因がフラッシュ・デバイスのレイテンシの増加か、ディスクI/Oの増加か、またはその他の原因かを判断できます。統計にディスクI/Oリクエストの増加が示されている場合は、Exadata Smart Flash Cacheの変更に関連している可能性があるため、Exadata Smart Flash Cacheの統計を確認するよう求められます。一方、統計にフラッシュからの小さい読取りのレイテンシの増加が示されている場合は、I/Oパターンの変更が原因である可能性があります。増加したI/Oのタイプ(Small Reads、Small Writes、Large Reads、Large Writes)を把握すると、さらに調査を進める際に役立ちます。
通常、Exadata環境では、すべてのセルおよびすべてのディスクにワークロードを均等に分散することが期待されます。1つのセルまたは1つのディスクが他のセルまたは他のディスクよりも多くの作業を行っている場合は、そのセルまたはディスクがシステム全体の速度を低下させる可能性があるため、さらに調査する必要があります。
6.3.9.1 AWRを使用したセル・ディスクI/Oの監視
自動ワークロード・リポジトリ(AWR)レポートの次の各セクションは、ExadataのI/O負荷を把握するのに特に役立ちます。
多くの場合、I/O負荷に関する特性をさらに理解するために、これらのセクションの統計をAWRレポートの他のセクションと相互に関連付けることができます。
Disk Activity
Disk Activity・セクションには、Disk Activityの潜在的なソースの概要が表示されます。Disk Activity・セクションは、AWRレポートのExadata Statistics→Performance Summaryの下にあります。
図6-26 AWRレポート: ディスク・アクティビティ
I/O負荷が高いか、Disk Activityのパターンが大きく変化している場合は、さらに調査が求められることがあります。考えられる原因には、次のものがあります。
- Redo log writes — REDOがディスクに書き込まれるときにディスク書込みが発生します。Exadata Smart Flash Logを使用する場合、REDOはExadata Smart Flash LogとオンラインREDOログ・ファイルの両方に書き込まれることに注意してください。また、Oracle Exadata System Softwareリリース20.1では、ディスク・ストレージではなくExadata Smart Flash Cacheをライトバック・モードで使用する、Smart Flash Log・ライトバックと呼ばれる最適化がさらに追加されています。詳細は、AWRレポートのデータベースREDOアクティビティおよびFlash Logを確認してください。
- Smart Scans — Exadata Smart Flash Cacheを使用して対応されないリクエストのためのディスク読取りが発生します。通常、これらはLarge Readsです。詳細は、AWRレポートのSmart IOを確認してください。
- Flash Cache misses — リクエストされたデータがExadata Smart Flash Cacheに存在しない場合、ディスク読取りが発生します。通常、これらはSmall Readsです。詳細は、AWRレポートのFlash Cache missesを確認してください。
- Flash Cache read skips — リクエストされたデータがExadata Smart Flash Cacheの対象でない場合は、ディスク読取りが発生します。詳細は、AWRレポートのFlash Cache User Reads - Skipsを確認してください。
- Flash Cache write skipsまたはFlash Cache LW rejections — データがExadata Smart Flash Cacheの対象でない場合は、ディスク書込みが発生します。詳細は、AWRレポートのFlash Cache User Writes - SkipsおよびFlash Cache User Writes - Large Write Rejections を確認してください。
- Disk writer writes — ライトバック・モードのExadata Smart Flash Cacheのデータがディスクに永続化されるときに、ディスク書込みが発生します。詳細は、AWRレポートのFlash Cache Internal Writesを確認してください。
- Scrub IO — Oracle Exadata System Softwareがハード・ディスクを自動的に検査および修復するときに発生します。Scrub IOはハード・ディスクがアイドル状態のときに定期的に実行され、ほとんどの場合大規模のディスク読取りが発生し、ディスクがI/Oバウンドになると自動的に抑制されます。
このセクションにリストされている具体的な原因は、使用しているOracle Databaseのバージョンによって異なります。
Exadata Resource Statistics
Exadata Resource Statisticsセクションには多くの統計が含まれ、複数のサブセクションに編成されています。主に、統計には、ストレージ・サーバーのオペレーティング・システム(OS)およびOracle Exadata System Softwareからの情報を使用して、ストレージ・サーバーで発生したI/Oが列挙されます。OSの場合は、I/O数/秒(IOPS)、スループット、使用率、サービス時間および待機時間に関連する統計が含まれます。これらの統計は、iostatコマンドで表示される統計と同等です。Oracle Exadata System Softwareの場合は、IOPS、スループットおよびレイテンシに関連する統計が含まれます。これらも、Small Reads、Small Writes、Large ReadsおよびLarge Writes別に分類されます。これらの統計は、セル・ディスク・メトリックに基づいています。
これらの統計は、デバイス・タイプ別に集計された後、セルまたはディスク別に集計されます。デバイス・タイプが異なるとパフォーマンス特性が異なることが予想されるため、確実に同じデバイス・タイプ間で比較するには、デバイス・タイプの集計を使用します。これらの統計は2つの方法で表示されます。まず、外れ値分析を実行できるように表示されます。また、特定の統計の上位Nのセルまたはディスクを表示するように編成されています。
外れ値分析表示を使用すると、すべてのストレージ・サーバーで集計された統計を、セル別およびディスク別にすばやく表示できます。この表示には、統計平均値、標準偏差および標準範囲も含まれます。標準範囲は、観測された下限値と上限値ではなく、平均値と標準偏差に基づいています。セルの場合、標準範囲は、平均値の±1の標準偏差の値の範囲です。ディスクの場合、標準範囲は、平均値の±3の標準偏差の値の範囲です。標準範囲外のセルまたはディスクがある場合、それらは外れ値としてレポートされます。この単純な外れ値分析は、さらに調査する領域を強調表示するように設計されています。ただし、使用中のセルまたはディスクの数と標準偏差の値によっては、外れ値分析で外れ値が識別されない場合があります。
Top Nの表示では、単に、特定の統計の上位ランクのセルまたはディスクが表示されます。この表示では、他のセルまたはディスクよりも多くの作業または少ない作業を実行するセルまたはディスクを識別できます。この表示を使用すると、外れ値分析で識別されない外れ値を識別できる可能性があります。また、これらのセクションで強調表示されているのは、デバイスの予想される最大IOPSまたはデバイスの予想される最大スループットを超えるセルまたはディスクです。
次のリストは、AWRレポートのExadata Resource Statisticsセクションのサブセクションの概要を示しています。
- Exadata Outlier Summary — 様々な外れ値サブセクションで識別される外れ値のサマリーが表示されます。
- Exadata OS Statistics Outliers — IOPS、スループット(MB/秒)、使用率、サービス時間、待機時間、セル当たりのCPU使用率など、OS統計に基づいたセルおよびディスクの外れ値サブセクションが含まれます。
- Exadata Cell Server Statistics — IOPS、スループット(MB/秒)、レイテンシなど、セル・ディスク・メトリックに基づいたセルおよびディスクの外れ値サブセクションが含まれます。これらの統計は、I/Oタイプ(Small Reads、Small Writes、Large Reads、Large Writes)でさらに分類されます。
- Exadata Outlier Details — 識別された外れ値の詳細情報と、外れ値に関連するその他の統計が表示されます。
- Exadata OS Statistics Top — IOPS、レイテンシ、CPU使用率など、OS統計に基づいたセルおよびディスクの上位Nサブセクションが含まれます。
- Exadata Cell Server Statistics Top — IOPS、スループット(MB/秒)、レイテンシなど、セル・ディスク・メトリックに基づいたセルおよびディスクの上位Nサブセクションが含まれます。これらの統計は、I/Oタイプ(Small Reads、Small Writes、Large Reads、Large Writes)でさらに分類されます。
次の例は、AWRレポートの2つのExadata Cell Server Statistics Outliersサブセクションを示しています。この例では、ハード・ディスクのスループット(IOPS)が予想される最大値を超えていること、および特定のディスクが明らかに他のディスクよりも多くのSmall Readsを実行していることが強調表示されています。
図6-27 AWRレポート: Exadataセル・サーバーIOPS統計の外れ値
Exadata IO Reasons
データベースがI/OリクエストをExadataに送信すると、そのリクエストにはI/Oの理由を含む情報がタグ付けされます。この情報は、AWRレポートのExadata IO Reasonsセクションに集約され、I/Oを実行する理由を把握できます。
AWRレポートには、Top IO Reasons by RequestsおよびTop IO Reasons by MB(スループット)を表示するサブセクションが含まれます。AWRレポートの新しいバージョンでは、Top IO Reasons by Requestsがさらに分類され、フラッシュからの読取りリクエスト、フラッシュへの書込みリクエスト、ディスクからの読取りリクエストおよびディスクへの書込みリクエストが分類されます。
次の例は、Top IO Reasons by Requestsを示しています。この出力例は、スマート・スキャンに関連付けられたI/Oの割合が高く、すべてのストレージ・サーバーで類似したI/Oプロファイルを持つ、パフォーマンスの高いシステムの典型的なものです。
図6-28 AWRレポート: リクエスト別の上位IO理由
Internal IO Reasons
報告された上位IO理由の中に内部IOがある場合、AWRレポートにはInternal IO Reasonsを要約したセクションが含められます。
図6-29 AWRレポート: 内部IO理由
内部I/Oの考えられる原因には、次のものがあります。
- Disk Writer reads — Disk Writerがライトバック・モードでExadata Smart Flash Cacheから読み取り、データをディスクに永続化するときに、フラッシュ読取りが発生します。詳細は、AWRレポートのFlash Cache Internal Readsを確認してください。
- Disk writer writes — Disk Writerがライトバック・モードでExadata Smart Flash Cacheからディスクにデータを永続化するときに、ディスク書込みが発生します。詳細は、AWRレポートのFlash Cache Internal Readsを確認してください。
- Polulation — リクエストされたデータがExadata Smart Flash Cacheに読み込まれるときに、フラッシュ書込みが発生します。データがディスクから読み取られると、Exadata Smart Flash Cacheにも移入されます。多くの場合、これはFlash Cache missesと相関関係があります。詳細は、AWRレポートのFlash Cache User ReadsおよびFlash Cache Internal Writesを確認してください。
- Metadata — 新しいデータがライトバック・モードでExadata Smart Flash Cacheに書き込まれるときに、フラッシュ書込みが発生します。多くの場合、これはFirst Writesが原因で発生します。詳細は、AWRレポートのFlash Cache User Writesを確認してください。
このセクションにリストされている具体的な原因は、使用しているOracle Databaseのバージョンによって異なります。
親トピック: セル・ディスクI/Oの監視
6.3.9.2 データベース統計および待機イベントを使用したセル・ディスクI/Oの監視
次の表では、セル・ディスクI/Oの監視に役立つ様々なデータベース統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
physical read IO requests |
データベースによって発行された物理読取りリクエストの数。 |
physical read requests optimized |
Exadataスマート・フラッシュ・キャッシュを使用して対応された読取りリクエストと、ストレージ索引または列キャッシュを使用することによって回避された読取りリクエストの合計数。 |
physical read total bytes |
読取りがストレージ・サーバーにオフロードされたかどうかに関係なく、データベースによって発行された読取りの合計I/Oバイト数。 |
physical read total bytes optimized |
Exadataスマート・フラッシュ・キャッシュから読み取られたバイト数と、ストレージ索引または列キャッシュを使用して回避されたバイト数の合計。 |
physical read total IO requests |
すべてのアクティビティ(アプリケーション、バックアップ、リカバリおよびその他のユーティリティを含む)に対してデータベースによって発行された読取りリクエストの合計数。 |
physical write IO requests |
データベースによって発行された物理書込みリクエストの数。 |
physical write total bytes |
すべてのアクティビティに対してデータベースによって発行された書込みの合計IOバイト数。 |
physical write total bytes optimized |
Exadataスマート・フラッシュ・キャッシュに書き込まれた合計バイト数。これらのバイトはレイジー方式でディスクに同期されます。 |
physical write total IO requests |
すべてのアクティビティ(アプリケーション、バックアップ、リカバリおよびその他のユーティリティを含む)に対してデータベースによって発行された書込みリクエストの合計数。 |
追加のデータベースI/O統計は、AWRレポートのIOStatセクションでも使用される次のV$IOSTATビューにも含まれます。
V$IOSTAT_FILE— データベース・ファイル(データ・ファイル、一時ファイル、および他のタイプのデータベース・ファイルを含む)のディスクI/O統計に関する情報を示します。V$IOSTAT_FUNCTION— データベース関数のディスクI/O統計(LGWRやDBWRなど)を示します。V$IOSTAT_FUNCTION_DETAIL— データベース関数のディスクI/O統計をファイル・タイプ別に示します。
次の表では、セル・ディスクI/Oの監視に役立つデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
| 待機イベント | 説明 |
|---|---|
cell list of blocks physical read |
この待機イベントは、リカバリ中またはバッファのプリフェッチ中(複数の単一ブロック読取りの実行ではない)に発生します。これは、リカバリの一環として変更する必要があり、データベースに対してパラレルで読み取られるデータベース・ブロックを監視するために使用されます。
この待機イベントは、セルの |
cell list of blocks read request |
これは |
cell multiblock physical read(セルの複数ブロックの物理読込み) |
この待機イベントは、マルチブロック・データベース読取りのすべてのI/Oの実行に要した時間を表します。
この待機イベントは、セルの |
cell multiblock read request |
これは |
cell single block physical read(セルの単一ブロックの物理読込み) |
この待機イベントは、単一ブロック・データベースI/Oの実行に要する時間を表します。
この待機イベントは、セルの 2022年5月のOracle Databaseリリース更新以降(バージョン19.15.0.0.220419、21.6.0.0.220419以降)、この待機イベントには、Exadataスマート・フラッシュ・キャッシュからのI/Oやリモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用したデータベースI/Oは含まれなくなりました。 |
cell single block physical read: flash cache |
この待機イベントは、Exadata Smart Flash Cacheから単一ブロック・データベースI/Oの実行に要する時間を表します。
この待機イベントは、2022年5月のOracle Databaseリリース更新で導入され、Oracle Databaseバージョン19.15.0.0.220419、21.6.0.0.220419以降に存在します。以前は、 |
|
|
この待機イベントは、XRMEMキャッシュから単一ブロック・データベースI/Oの実行に要する時間を表します。
Oracle Exadata System Softwareリリース23.1.0以降をサポートするOracle Databaseバージョンでは、待機イベントの名前は |
cell single block physical read: RDMA |
この待機イベントは、リモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用して単一ブロック・データベースI/Oの実行に要する時間を表します。
この待機イベントは、2022年5月のOracle Databaseリリース更新で導入され、Oracle Databaseバージョン19.15.0.0.220419、21.6.0.0.220419以降に存在します。以前は、 |
cell single block read request |
これは、単一ブロック・データベースI/Oに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示されます。待機イベントが終了すると、プレースホルダは適切な待機イベント(通常は |
cell interconnect retransmit during physical read |
この待機イベントは、単一ブロック読取りまたはマルチブロック読取りのI/Oの再転送中に表示されます。 |
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。
親トピック: セル・ディスクI/Oの監視
6.3.9.3 Exadataメトリックを使用したセル・ディスクI/Oの監視
セル・ディスクのメトリックでは、セル・ディスクからの大きいブロック読取り数など、セル・ディスクのI/O負荷に関する情報が提供されます。
セル・ディスクのメトリックは、objectType=CELLDISKであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
メトリックを表示するセル・ディスクは、METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName属性で指定されます。
累積メトリックの場合は、様々なcollectionTime期間から値を減算することにより、特定の期間のメトリック値が算出されます。rateメトリックの場合は、メトリック値の期間は直前の1分間になります。
例6-12 セル・ディスクのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なセル・ディスクのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = CELLDISK
CD_BY_FC_DIRTY "Number of unflushed megabytes cached in FLASHCACHE on a cell disk"
CD_IO_BY_R_LG "Number of megabytes read in large blocks from a cell disk"
CD_IO_BY_R_LG_SEC "Number of megabytes read in large blocks per second from a cell disk"
CD_IO_BY_R_SCRUB "Number of megabytes read from a cell disk by the scrubbing job"
CD_IO_BY_R_SCRUB_SEC "Number of megabytes read per second from a cell disk by the scrubbing job"
CD_IO_BY_R_SM "Number of megabytes read in small blocks from a cell disk"
CD_IO_BY_R_SM_SEC "Number of megabytes read in small blocks per second from a cell disk"
CD_IO_BY_W_LG "Number of megabytes written in large blocks to a cell disk"
CD_IO_BY_W_LG_SEC "Number of megabytes written in large blocks per second to a cell disk"
CD_IO_BY_W_SM "Number of megabytes written in small blocks to a cell disk"
CD_IO_BY_W_SM_SEC "Number of megabytes written in small blocks per second to a cell disk"
CD_IO_ERRS "Number of IO errors on a cell disk"
CD_IO_ERRS_MIN "Number of IO errors on a cell disk per minute"
CD_IO_ERRS_SCRUB "Number of IO errors hit by the scrubbing job on a cell disk"
CD_IO_LOAD "Average I/O load for the cell disk"
CD_IO_RQ_R_LG "Number of requests to read large blocks from a cell disk"
CD_IO_RQ_R_LG_SEC "Number of requests to read large blocks per second from a cell disk"
CD_IO_RQ_R_SCRUB "Number of requests to read from a cell disk by the scrubbing job"
CD_IO_RQ_R_SCRUB_SEC "Number of requests to read per second from a cell disk by the scrubbing job"
CD_IO_RQ_R_SM "Number of requests to read small blocks from a cell disk"
CD_IO_RQ_R_SM_SEC "Number of requests to read small blocks per second from a cell disk"
CD_IO_RQ_W_LG "Number of requests to write large blocks to a cell disk"
CD_IO_RQ_W_LG_SEC "Number of requests to write large blocks per second to a cell disk"
CD_IO_RQ_W_SM "Number of requests to write small blocks to a cell disk"
CD_IO_RQ_W_SM_SEC "Number of requests to write small blocks per second to a cell disk"
CD_IO_ST_RQ "Average service time per request for small IO requests to a cell disk"
CD_IO_TM_R_LG "Cumulative latency of reading large blocks from a cell disk"
CD_IO_TM_R_LG_RQ "Average latency of reading large blocks per request to a cell disk"
CD_IO_TM_R_SM "Cumulative latency of reading small blocks from a cell disk"
CD_IO_TM_R_SM_RQ "Average latency of reading small blocks per request from a cell disk"
CD_IO_TM_W_LG "Cumulative latency of writing large blocks to a cell disk"
CD_IO_TM_W_LG_RQ "Average latency of writing large blocks per request to a cell disk"
CD_IO_TM_W_SM "Cumulative latency of writing small blocks to a cell disk"
CD_IO_TM_W_SM_RQ "Average latency of writing small blocks per request to a cell disk"
CD_IO_UTIL "Percentage of disk resources utilized for the cell disk"
CD_IO_UTIL_LG "Percentage of disk resources utilized by large requests for the cell disk"
CD_IO_UTIL_SM "Percentage of disk resources utilized by small requests for the cell disk"次の追加詳細に注意してください。
-
CD_IO_LOADは、セル・ディスクの平均I/O負荷を表します。I/O負荷によってディスク・キューの長さが決まります。これはiostatの
avgqu-szに似ていますが、I/O負荷はディスクのタイプ応じて重みが付けられた値です。- ハード・ディスクの場合、大きなI/Oの重みは小さなI/Oの3倍です。
- フラッシュ・ディスクの場合、大きなI/Oと小さなI/Oの重みは同じです。
対応するメトリックは、各データベース(
DB_IO_LOAD)、プラガブル・データベース(PDB) (PDB_IO_LOAD)、IORMカテゴリ(CT_IO_LOAD)およびコンシューマ・グループ(CG_IO_LOAD)でも使用できます。 -
CD_IO_ST_RQは、フラッシュ・デバイスには使用できません(iostatの使用を参照)。 -
CD_IO_UTILは、ハード・ディスクのiostatの%utilに似ていますが、iostatの使用で説明されているようにフラッシュ・デバイスには使用できません。フラッシュ・デバイスの場合、これは製品データ・シートで指定された、システムの最大I/O帯域幅の割合です。このメトリックはIORMによって計算されるため、データベース、PDBおよびコンシューマ・グループごとに使用することもできます。
- レイテンシ・メトリックの測定単位はマイクロ秒です。レイテンシ・メトリックのメトリック名は、
CD_IO_TM_で始まります。
親トピック: セル・ディスクI/Oの監視
6.3.9.4 セル・ディスクI/Oを監視する際の注意事項
不均衡
Exadata環境では、すべてのセルまたはディスクに負荷を均等に分散することが期待されます。ただし、状況によっては不均衡が発生する場合があります。
負荷の不均衡は、次のようなワークロードの特性によって発生する可能性があります。
-
小さい表のスキャンの繰返し — これは多くの場合、ネステッド・ループ結合の右側の表が原因で発生します。小規模の表は少数のディスクまたはセルにのみ存在する可能性があるため、繰返しアクセスは、小さいデバイス・セット(データがExadata Smart Flash Cacheに存在する場合はフラッシュ・デバイス)からの読取りを意味します。不均衡に対処するために、影響を受けるSQL文を特定し、その実行計画を確認できます。また、影響を受けるセグメントの物理組織を考慮することもできます。
-
制御ファイルの読取りの繰返し — 制御ファイルの読取りは、一部のデータベース動的パフォーマンス・ビューに対する問合せが原因で発生する場合があります。制御ファイルは小さく、少数のディスクまたはセルにのみ存在する可能性があるため、繰返しアクセスは、小さいデバイス・セット(通常はフラッシュ)からの読取りを意味します。制御ファイルの読取りが繰り返されていることは、AWRレポートのファイル・タイプ別のIOStatセクションの
control file sequential read待機イベントからわかります。制御ファイルの読取りが繰り返される原因を把握するには、AWRレポートのExadata IO Reasonsセクションを使用して、多数の制御ファイルの読取りを処理するセルを識別し、これを上位データベース・セクションの統計と相互に関連付けて、制御ファイルの読取りを発行するデータベースを識別します。また、アクティブ・セッション履歴(ASH)を確認して、
control file sequential readの待機が発生しているSQL文を特定することもできます。負荷の軽いシステムでは、制御ファイルの読取りにより、不均衡な少量のI/Oが発生する場合があることに注意してください。この場合、不均衡は無視して問題ありません。
-
LOBセグメントなどの小さいセグメントの読取りの繰返し — このような不均衡に対処するには、セグメントのデータベース統計を確認するか、ASHを調べて原因となるSQLコマンドを特定します。次に、SQLおよび周囲のアプリケーション・ロジックを調べて、繰返し読取りを回避できるかどうかを確認します。
-
ASMメタデータへのアクセスの繰返し — これは多くの場合、ASMメタデータへのアクセスが必要な、領域使用量に関連するデータベース問合せが原因です。ASMメタデータは小さく、少数のディスクまたはセルにのみ存在する可能性があるため、繰返しアクセスは不均衡として表示される場合があります。これは、AWRレポートのExadata IO Reasonsセクションに、ASMの接頭辞(ASM CACHE IOなど)が付いた理由とともに表示される場合があります。Exadata IO Reasonsセクションを使用して影響を受けるセルを識別し、これを上位データベース・セクションの統計と相互に関連付けて、ASMをI/Oのソースとして確認できます。不均衡に対処するには、メタデータにアクセスするASM領域使用量問合せの必要性と頻度を確認します。
ワークロード関連の原因とは別に、不均衡の原因として次のことが考えられます。
- 不均等なデータ分散 — 一部のディスクに含まれるデータが他のディスクよりも多いまたは少ない場合、ホット・スポットが発生することがあります。データ分散が均等であるかをチェックするには、大規模な全表スキャンを含むSQL問合せの実行前後に
V$ASM_DISK_IOSTATビューを問い合せます。この場合、read列とread_bytes列の統計は、ディスク・グループ内のすべてのディスクでほぼ同じである必要があります。また、My Oracle Supportのドキュメント367445.1で入手できるスクリプトを使用して、データ分散が均等であるかをチェックすることもできます。 - 非対称のグリッド・ディスク構成 — グリッド・ディスクのサイズがセルごとに異なる場合は、各セルのデータ量が異なる可能性があるため、不均等なデータ分散が原因で不均衡になります。このため、システム内のすべてのストレージ・サーバーで対称な構成をお薦めします。
- 障害または障害からのリカバリ — 一部の処理では、残りのディスクまたはセルに均等に分散できません。たとえば、フラッシュ・カードに障害が発生した場合、そのカードを含むセルのFlash Cache領域は少なくなり、Flash Cache統計が他のセルと比較されると不均衡として表示されることがあります。
不均衡は、多くの場合、AWRレポートの様々な統計に表示されます。AWRレポートの様々なセクションを相互に関連付けることで、不均衡をより深く理解できます。
高I/O負荷
データベース・パフォーマンスの問題がExadataストレージ・サーバーのI/O負荷に関連する場合は、通常、I/O関連の待機イベントのレイテンシが増加し、User I/OまたはSystem I/OのWait Classのデータベース時間が増加します。高I/O負荷を処理する場合は、まずI/O負荷の構成を理解します。I/O負荷の構成に基づいて、より深く理解するために別の統計に誘導されます。
AWRレポートでは、Disk Activity・セクションから始めることをお薦めします。このセクションには、Disk Activityの潜在的なソースの概要が表示されます。Disk Activity・セクションは、AWRレポートのExadata Statistics→Performance Summaryの下にあります。Disk Activityを参照してください。
内部I/O
AWRレポートでは、上位IO理由の中に内部I/Oが報告されている場合は、Internal IO Reasonsを要約したセクションも含められます。このセクションを使用して、内部I/Oの構成を理解します。内部I/O負荷の構成に基づいて、より深く理解するために別の統計に誘導されます。Internal IO Reasonsを参照してください。
親トピック: セル・ディスクI/Oの監視
6.3.10 グリッド・ディスクの監視
グリッド・ディスクのメトリックでは、グリッド・ディスクからの大きいブロック読取り数など、グリッド・ディスクのI/O負荷に関する情報が提供されます。
グリッド・ディスクのメトリックは、objectType=GRIDDISKであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
メトリックを表示するグリッド・ディスクは、METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName属性で指定されます。
累積メトリックの場合は、様々なcollectionTime期間から値を減算することにより、特定の期間のメトリック値が算出されます。rateメトリックの場合は、メトリック値の期間は直前の1分間になります。
例6-13 グリッド・ディスクのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なグリッド・ディスクのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = GRIDDISK
GD_BY_FC_DIRTY "Number of unflushed megabytes cached in FLASHCACHE for a grid disk"
GD_IO_BY_R_LG "Number of megabytes read in large blocks from a grid disk"
GD_IO_BY_R_LG_SEC "Number of megabytes read in large blocks per second from a grid disk"
GD_IO_BY_R_SCRUB "Number of megabytes read from a grid disk by the scrubbing job"
GD_IO_BY_R_SCRUB_SEC "Number of megabytes read per second from a grid disk by the scrubbing job"
GD_IO_BY_R_SM "Number of megabytes read in small blocks from a grid disk"
GD_IO_BY_R_SM_SEC "Number of megabytes read in small blocks per second from a grid disk"
GD_IO_BY_W_LG "Number of megabytes written in large blocks to a grid disk"
GD_IO_BY_W_LG_SEC "Number of megabytes written in large blocks per second to a grid disk"
GD_IO_BY_W_SM "Number of megabytes written in small blocks to a grid disk"
GD_IO_BY_W_SM_SEC "Number of megabytes written in small blocks per second to a grid disk"
GD_IO_ERRS "Number of IO errors on a grid disk"
GD_IO_ERRS_MIN "Number of IO errors on a grid disk per minute"
GD_IO_ERRS_SCRUB "Number of IO errors hit by the scrubbing job on a grid disk"
GD_IO_RQ_R_LG "Number of requests to read large blocks from a grid disk"
GD_IO_RQ_R_LG_SEC "Number of requests to read large blocks per second from a grid disk"
GD_IO_RQ_R_SCRUB "Number of requests to read from a grid disk by the scrubbing job"
GD_IO_RQ_R_SCRUB_SEC "Number of requests to read per second from a grid disk by the scrubbing job"
GD_IO_RQ_R_SM "Number of requests to read small blocks from a grid disk"
GD_IO_RQ_R_SM_SEC "Number of requests to read small blocks per second from a grid disk"
GD_IO_RQ_W_LG "Number of requests to write large blocks to a grid disk"
GD_IO_RQ_W_LG_SEC "Number of requests to write large blocks per second to a grid disk"
GD_IO_RQ_W_SM "Number of requests to write small blocks to a grid disk"
GD_IO_RQ_W_SM_SEC "Number of requests to write small blocks per second to a grid disk"
GD_NVM_READ_RETRIES "Number of read retries for a non-volatile memory (NVM) grid disk"
GD_SP_BY_ALLOCATED "Allocated physical space for grid disk in bytes"
GD_SP_IO_BY_PARTIAL "Bytes returned by partial IOs"
GD_SP_IO_BY_PARTIAL_SEC "Bytes returned by partial IOs per second"
GD_SP_IO_BY_REDIRECTED "Sparse bytes redirected to original data block"
GD_SP_IO_BY_REDIRECTED_SEC "Sparse bytes redirected to original data block per second"
GD_SP_IO_RQ_PARTIAL "Number of IO requests that returned partial data"
GD_SP_IO_RQ_PARTIAL_SEC "Number of IO requests that returned partial data per second"
GD_SP_PRCT_ALLOCATED "Allocated physical space for grid disk by percentage"次の追加詳細に注意してください。
-
GD_SP_PRCT_ALLOCATEDは、グリッド・ディスクに割り当てられた物理領域を追跡し、これは割合として表示されます。デフォルトでは、領域使用量が95%を超えると警告アラートが生成され、領域使用量が99%に達するとクリティカル・アラートが生成されます。領域使用量を減らすには、グリッド・ディスクのサイズを増やすか、グリッド・ディスク上のデータの一部を削除します。
6.3.11 ホスト・インターコネクトのメトリックの監視
ホスト・インターコネクトのメトリックは、セル・ストレージにアクセスするホストのI/O転送に関する情報を提供します。
ホスト・インターコネクトのメトリックは、objectType=HOST_INTERCONNECTであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクトで識別されます。
メトリックのホスト・インターコネクトは、METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName属性で指定されます。cumulativeメトリックの場合は、様々なcollectionTime期間から値を減算することにより、特定の期間のメトリック値を算出できます。rateメトリックの場合は、メトリック値の期間は直前の1分間になります。
例6-14 ホスト・インターコネクトのメトリック定義の表示
この例は、Oracle Exadata System Softwareで使用可能なホスト・インターコネクトのメトリック定義を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = HOST_INTERCONNECT
N_MB_DROP "Number of megabytes droped during transmission to a particular host"
N_MB_DROP_SEC "Number of megabytes droped during transmission per second to a particular host"
N_MB_RDMA_DROP "Number of megabytes dropped during RDMA transmission to a particular host"
N_MB_RDMA_DROP_SEC "Number of megabytes dropped during RDMA transmission per second to a particular host"
N_MB_RECEIVED "Number of megabytes received from a particular host"
N_MB_RECEIVED_SEC "Number of megabytes per second received from a particular host"
N_MB_RESENT "Number of megabytes resent to a particular host"
N_MB_RESENT_SEC "Number of megabytes resent per second to a particular host"
N_MB_SENT "Number of megabytes transmitted to a particular host"
N_MB_SENT_SEC "Number of megabytes transmitted per second to a particular host"
N_RDMA_RETRY_TM "Latency of the retry actions during RDMA transmission to a particular host"6.4 Exadataの監視オブジェクトの使用
- メトリックの表示
CellCLIのLISTコマンドを使用すると、セル・オブジェクトのメトリックを表示および監視できます。 - アラートの監視
アラートの通知を監視および受信できます。 - アクティブ・リクエストの表示
ストレージ・サーバーのアクティブ・リクエストを表示するには、LIST ACTIVEREQUESTコマンドを使用します。 - リアルタイム・インサイトの使用
リアルタイム・インサイト機能を使用すると、外部のメトリック収集プラットフォームを使用してExadataシステムをリアルタイムで監視できます。
親トピック: Exadataの監視
6.4.1 メトリックの表示
CellCLIのLISTコマンドを使用すると、セル・オブジェクトのメトリックを表示および監視できます。
LISTコマンドを使用して、メトリック定義、現在のメトリック、およびメトリック履歴を表示できます。
- メトリックの定義の表示
ストレージ・サーバーのメトリック定義を表示するには、LIST METRICDEFINITIONコマンドを使用します。 - 現在のメトリックの表示
ストレージ・サーバーの現行のメトリック値を表示するには、LIST METRICCURRENTコマンドを使用します。 - メトリック履歴の表示
ストレージ・サーバーのメトリック履歴を表示するには、LIST METRICHISTORYコマンドを使用します。
親トピック: Exadataの監視オブジェクトの使用
6.4.1.1 メトリック定義の表示
ストレージ・サーバーのメトリック定義を表示するには、LIST METRICDEFINITIONコマンドを使用します。
メトリック定義のリストには、メトリックの構成が表示されます。
例6-15 メトリック定義の表示
この例は、METRICDEFINITIONオブジェクトの属性を表示する方法を示しています。
CellCLI> LIST METRICDEFINITION CL_CPUT DETAIL
CellCLI> LIST METRICDEFINITION WHERE objectType = 'GRIDDISK'
CellCLI> LIST METRICDEFINITION WHERE name LIKE 'CD_IO_RQ.*' -
ATTRIBUTES name, metricType, description
親トピック: メトリックの表示
6.4.1.2 現在のメトリックの表示
ストレージ・サーバーの現行のメトリック値を表示するには、LIST METRICCURRENTコマンドを使用します。
現在のメトリックのリストには、各メトリックの現在値の観測データのセットが表示されます。
例6-16 現在のメトリック値の表示
この例は、METRICCURRENTオブジェクトの属性を表示する方法を示しています。
CellCLI> LIST METRICCURRENT CL_TEMP DETAIL
name: CL_TEMP
alertState: normal
collectionTime: 2009-12-17T15:32:25-08:00
metricObjectName: abcd2x3
metricType: Instantaneous
metricValue: 48.0 C
objectType: CELL
CellCLI> LIST METRICCURRENT WHERE objectType = 'CELLDISK' AND -
metricValue != 0 ATTRIBUTES name, metricObjectName, -
metricValue, collectionTime
CD_IO_BY_R_LG CD_00_abcd2x3 1.9 MB 2009-12-17T15:46:52-08:00
CD_IO_BY_R_LG CD_01_abcd2x3 1.0 MB 2009-12-17T15:46:52-08:00
CD_IO_BY_R_LG CD_02_abcd2x3 4.1 MB 2009-12-17T15:46:52-08:00
CD_IO_BY_R_LG CD_03_abcd2x3 9.5 MB 2009-12-17T15:46:52-08:00
CD_IO_BY_R_LG CD_04_abcd2x3 0.1 MB 2009-12-17T15:46:52-08:00
CD_IO_BY_R_LG CD_05_abcd2x3 0.4 MB 2009-12-17T15:46:52-08:00
...
親トピック: メトリックの表示
6.4.1.3 メトリック履歴の表示
ストレージ・サーバーのメトリック履歴を表示するには、LIST METRICHISTORYコマンドを使用します。
メトリック履歴のリストは、すべてのメトリック値の過去の各観測データを収集したものです。
ほとんどのメトリック履歴ファイルの保存期間は、metricHistoryDaysセル属性で指定します。デフォルトの保存期間は7日です。この設定は、CellCLIのALTER CELLコマンドで変更できます。
metricHistoryDaysセル属性で管理されるメトリックに加え、一部のキー・メトリック観測は、最長で1年間保持されます。どの場合でも、サーバーでストレージ領域不足が検出されると、履歴メトリック観測が自動的にパージされます。
例6-17 メトリック履歴の値の表示
この例は、様々なLIST METRICHISTORYコマンドを示しています。
次のコマンドは、メトリックがcriticalアラート状態であったときの、CD_IO_RQ_R_LGメトリックのメトリック履歴の観測データを表示します。この出力には、すべてのメトリック属性が含まれます。
CellCLI> LIST METRICHISTORY CD_IO_RQ_R_LG WHERE alertState='critical' DETAIL次のコマンドは、セル・ディスクに関連付けられているすべてのメトリック観測データのメトリック属性のサブセットを表示します。この出力は、指定した時間の後に観測されたゼロ以外のメトリック値を持つ観測データに限定されます。
CellCLI> LIST METRICHISTORY WHERE objectType = 'CELLDISK' AND metricValue != 0 -
AND collectionTime > '2009-08-12T09:10:51-07:00' ATTRIBUTES name, -
metricObjectName, metricValue, collectionTime次のコマンドは、指定したオブジェクト・タイプに関連付けられている、指定した期間内のすべてのメトリック観測データを表示します。
CellCLI> LIST METRICHISTORY WHERE objectType LIKE 'CELLDISK|FLASHCACHE|FLASHLOG|SMARTIO|IORM_DATABASE' -
AND collectionTime > '2020-07-15T08:00:00-07:00' -
AND collectionTime < '2020-07-15T09:00:00-07:00'6.4.2 アラートの監視
アラートの通知を監視および受信できます。
アラートは、セル内で発生した重要なイベントを表します。通常、アラートはExadataサーバーの機能が損なわれているか、または障害が発生する危険性があることを示します。
通知を受信するには、ALTER CELLコマンドを使用します。
- アラート定義の表示
ストレージ・サーバーのアラート定義を表示するには、LIST ALERTDEFINITIONコマンドを使用します。 - アラート通知の受信
Oracle Exadata System Softwareの管理者は、電子メールまたはSimple Network Management Protocol (SNMP)トラップ・アラートによってアラート通知を受信できます。 - アラート履歴の表示
セルで発生したアラートの履歴を表示するには、LIST ALERTHISTORYコマンドを使用します。 - アラート履歴の変更
セルのアラート履歴を更新するには、ALTER ALERTHISTORYコマンドを使用します。
関連項目
親トピック: Exadataの監視オブジェクトの使用
6.4.2.1 アラート定義の表示
ストレージ・サーバーのアラート定義を表示するには、LIST ALERTDEFINITIONコマンドを使用します。
アラート定義では、ストレージ・サーバーで生成可能なすべてのアラートの定義が提供されます。
例6-18 アラート定義属性の表示
この例は、アラートADRAlertの属性の詳細リストを表示する方法を示しています。
CellCLI> LIST ALERTDEFINITION ADRAlert DETAIL
name: ADRAlert
alertShortName: ADR
alertSource: "Automatic Diagnostic Repository"
description: "Incident Alert"例6-19 アラート定義名および説明の属性の表示
アラート定義の指定した属性のリストを表示できます。この例は、アラート名、メトリック名および説明を表示する方法を示しています。メトリック名では、アラートの基準となるメトリックを識別します。ADRAlert、HardwareAlert、Stateful_HardwareAlertおよびStateful_SoftwareAlertはメトリックに基づいていないため、メトリック名はありません。
CellCLI> LIST ALERTDEFINITION ATTRIBUTES name, metricName, description
ADRAlert "Incident Alert"
HardwareAlert "Hardware Alert"
MetricAlert "Threshold Alert"
SoftwareAlert "Software Alert"
StatefulAlert_CD_IO_ERRS_MIN CD_IO_ERRS_MIN "Threshold Alert"
StatefulAlert_CG_IO_RQ_LG CG_IO_RQ_LG "Threshold Alert"
StatefulAlert_CG_IO_RQ_LG_SEC CG_IO_RQ_LG_SEC "Threshold Alert"
StatefulAlert_CG_IO_RQ_SM CG_IO_RQ_SM "Threshold Alert"
StatefulAlert_CG_IO_RQ_SM_SEC CG_IO_RQ_SM_SEC "Threshold Alert"
StatefulAlert_CG_IO_WT_LG CG_IO_WT_LG "Threshold Alert"
StatefulAlert_CG_IO_WT_LG_RQ CG_IO_WT_LG_RQ "Threshold Alert"
StatefulAlert_CG_IO_WT_SM CG_IO_WT_SM "Threshold Alert"
StatefulAlert_CG_IO_WT_SM_RQ CG_IO_WT_SM_RQ "Threshold Alert"
StatefulAlert_CL_FSUT CL_FSUT "Threshold Alert"
StatefulAlert_CL_MEMUT CL_MEMUT "Threshold Alert"
StatefulAlert_CT_IO_RQ_LG CT_IO_RQ_LG "Threshold Alert"
StatefulAlert_CT_IO_RQ_LG_SEC CT_IO_RQ_LG_SEC "Threshold Alert"
StatefulAlert_CT_IO_RQ_SM CT_IO_RQ_SM "Threshold Alert"
StatefulAlert_CT_IO_RQ_SM_SEC CT_IO_RQ_SM_SEC "Threshold Alert"
StatefulAlert_CT_IO_WT_LG CT_IO_WT_LG "Threshold Alert"
StatefulAlert_CT_IO_WT_LG_RQ CT_IO_WT_LG_RQ "Threshold Alert"
StatefulAlert_CT_IO_WT_SM CT_IO_WT_SM "Threshold Alert"
StatefulAlert_CT_IO_WT_SM_RQ CT_IO_WT_SM_RQ "Threshold Alert"
StatefulAlert_DB_IO_RQ_LG DB_IO_RQ_LG "Threshold Alert"
StatefulAlert_DB_IO_RQ_LG_SEC DB_IO_RQ_LG_SEC "Threshold Alert"
StatefulAlert_DB_IO_RQ_SM DB_IO_RQ_SM "Threshold Alert"
StatefulAlert_DB_IO_RQ_SM_SEC DB_IO_RQ_SM_SEC "Threshold Alert"
StatefulAlert_DB_IO_WT_LG DB_IO_WT_LG "Threshold Alert"
StatefulAlert_DB_IO_WT_LG_RQ DB_IO_WT_LG_RQ "Threshold Alert"
StatefulAlert_DB_IO_WT_SM DB_IO_WT_SM "Threshold Alert"
StatefulAlert_DB_IO_WT_SM_RQ DB_IO_WT_SM_RQ "Threshold Alert"
StatefulAlert_GD_IO_ERRS_MIN GD_IO_ERRS_MIN "Threshold Alert"
Stateful_HardwareAlert "Hardware Stateful Alert"
Stateful_SoftwareAlert "Software Stateful Alert"
6.4.2.2 アラート通知の受信
Oracle Exadata System Softwareの管理者は、電子メールまたはSimple Network Management Protocol (SNMP)トラップ・アラートによってアラート通知を受信できます。
ALTER CELLコマンドを使用してアラート通知属性を設定することで、通知電子メール・メッセージまたはSNMPトラップ・アラートを送信するようにOracle Exadata Storage Serverを構成できます。
ノート:
SNMPアラートは、Oracle Exadata System Softwareの各インストールに含まれているMIB (管理情報ベース)に準拠しています。Oracle Exadata Storage ServerのMIBファイルは、/opt/oracle/cell/cellsrv/deploy/config/cell_alert.mibにあります。
関連項目
親トピック: アラートの監視
6.4.2.3 アラート履歴の表示
セルで発生したアラートの履歴を表示するには、LIST ALERTHISTORYコマンドを使用します。
アラート履歴エントリは、最大で100日間保持されます。アラート履歴エントリの数が500を超えると、アラート履歴エントリは7日間のみ保持されます。ステートフル・アラートがクリアされると(つまり、基礎となるメトリック、ハードウェアまたはソフトウェアの状態がnormalに戻ると)、そのステートフル・アラートは、アラート履歴エントリの数に応じて100日間または7日間保持されます。クリアされていないステートフル・アラートは、経過期間にかかわらず保持されます。
例6-20 アラート履歴属性の表示
この例は、severity属性がcriticalに設定され、examinedBy属性が設定されていないアラート履歴エントリの属性の詳細リストを表示する方法を示しています。
CellCLI> LIST ALERTHISTORY WHERE severity = 'critical' AND examinedBy = '' DETAIL
6.4.2.4 アラート履歴の変更
セルのアラート履歴を更新するには、ALTER ALERTHISTORYコマンドを使用します。
例6-21 アラート履歴属性の変更
この例は、アラートを確認した管理者のユーザーIDをexaminedBy属性に設定する方法を示しています。
CellCLI> ALTER ALERTHISTORY 1671443714 examinedBy="jdoe"
examinedBy属性は、変更可能な唯一のALERTHISTORY属性です。
親トピック: アラートの監視
6.4.3 アクティブ・リクエストの表示
ストレージ・サーバーのアクティブ・リクエストを表示するには、LIST ACTIVEREQUESTコマンドを使用します。
ACTIVEREQUEST属性を表示するには、DESCRIBE ACTIVEREQUESTコマンドを使用します。
例6-22 アクティブ・リクエスト属性の表示
この例は、指定したリクエストのI/Oタイプの属性の詳細リストを表示する方法を示しています。
CellCLI> LIST ACTIVEREQUEST WHERE IoType = 'predicate pushing' DETAIL
6.4.4 リアルタイム・インサイトの使用
リアルタイム・インサイト機能を使用すると、外部のメトリック収集プラットフォームを使用してExadataシステムをリアルタイムで監視できます。
- ファイングレイン・メトリックの使用
- 収集プラットフォームへのメトリック観測データのアップロード
- Exadataサーバーからのメトリック観測データのダウンロード
- メトリック観測データのタグ付け
- メトリック・ストリーム形式の理解
親トピック: Exadataの監視オブジェクトの使用
6.4.4.1 ファイングレイン・メトリックの使用
従来、Exadataメトリックの収集は1分間隔で実行されていました。しかしながら、リアルタイム監視には、よりタイムリーなメトリックが必要です。Oracle Exadata System Software 22.1.0以降では、ファイングレイン・メトリック収集を構成できます。
ファイングレイン・メトリック収集は、リアルタイム・インサイト機能の基盤です。ファイングレイン・メトリック収集は、外部のメトリック収集プラットフォームと連携して機能します。このプラットフォームで、ファイングレイン・メトリック観測データが収集され、可視化のために処理されます。ファイングレイン・メトリック観測データは、サーバー・メモリーにのみ存在し、サーバー上には保持されません。そのため、ファイングレイン・メトリックの履歴は各サーバー上に保持されません。
6.4.4.1.1 ファイングレイン・メトリック収集の制御
metricFGCollIntvlInSec属性により、ファイングレイン・メトリック収集を制御します。
-
ファイングレイン・メトリック収集を有効にするには、収集間隔を1から60秒までの値に設定する必要があります。
たとえば:
CellCLI> ALTER CELL metricFGCollIntvlInSec=1metricFGCollIntvlInSec設定は、metricStreamIntvlInSec属性で指定された自動アップロード頻度に関連しています。自動メトリック・アップロードとファイングレイン収集の両方が有効な場合(metricStreamIntvlInSec>0とmetricFGCollIntvlInSec>0)、metricStreamIntvlInSecはmetricFGCollIntvlInSecの5から30倍である必要があります。たとえば、metricStreamIntvlInSec=60の場合、metricFGCollIntvlInSecは2から12までにする必要があります。 -
サーバーでファイングレイン・メトリック収集を無効にするには、
metricFGCollIntvlInSec=0に設定します。たとえば:
CellCLI> ALTER CELL metricFGCollIntvlInSec=0ファイングレイン・メトリック収集を無効にできるのは、自動メトリック・アップロードが無効(
metricStreamIntvlInSec=0)であるか、自動アップロード頻度が5分から30分(metricStreamIntvlInSecが300から1800の間)の場合のみです。
親トピック: ファイングレイン・メトリックの使用
6.4.4.1.2 ファイングレイン・メトリック収集のカスタマイズ
デフォルトで、ファイングレイン収集に対して自動的に一連のキー・パフォーマンス・メトリックが有効になります。ただし、特定のメトリックを有効または無効にすることで、ファイングレイン・メトリック収集をカスタマイズできます。
-
メトリックのファイングレイン収集を有効にするには、
ALTER METRICDEFINITIONコマンドを使用してfinegrained=enabledを指定します。たとえば:CellCLI> ALTER METRICDEFINITION N_NIC_KB_TRANS_SEC finegrained=enabledCellCLI> ALTER METRICDEFINITION N_MB_SENT,N_MB_RECEIVED finegrained=enabledCellCLI> ALTER METRICDEFINITION finegrained=enabled WHERE name LIKE 'N_NIC.*' -
メトリックのファイングレイン収集を無効にするには、
ALTER METRICDEFINITIONコマンドを使用してfinegrained=disabledを指定します。たとえば:CellCLI> ALTER METRICDEFINITION N_MB_SENT finegrained=disabled -
ファイングレイン収集が有効になっているメトリックを表示するには、次のコマンドを使用します。これはいつでも実行できます。
CellCLI> LIST METRICDEFINITION WHERE finegrained=enabled -
各メトリックの説明や、そのメトリックのファイングレイン収集が有効になっているかどうかなど、メトリック定義の詳細をすべて表示するには、次のコマンドを使用します。これはいつでも実行できます。
CellCLI> LIST METRICDEFINITION DETAIL
親トピック: ファイングレイン・メトリックの使用
6.4.4.2 収集プラットフォームへのメトリック観測データのアップロード
Exadataサーバーによってメトリック観測データが外部のメトリック収集プラットフォームに自動的にアップロード(プッシュ)されるようにできます。
6.4.4.2.1 自動メトリック・アップロード頻度の制御
metricStreamIntvlInSec属性により、metricStreamEndPoint属性で指定されたメトリック・ストリーミング・エンドポイントへの自動アップロードのアップロード間隔(秒)を設定します。
-
自動メトリック・アップロードを有効にするには、
metricStreamIntvlInSec属性をゼロ以外の値に設定します。たとえば:
CellCLI> ALTER CELL metricStreamIntvlInSec=25metricStreamIntvlInSec設定は、metricFGCollIntvlInSec属性で指定されたファイングレイン収集頻度に関連しています。-
自動メトリック・アップロードとファイングレイン収集の両方が有効な場合(
metricStreamIntvlInSec>0とmetricFGCollIntvlInSec>0)、metricStreamIntvlInSecはmetricFGCollIntvlInSecの5から30倍である必要があります。たとえば、metricFGCollIntvlInSecが5に設定されている場合、metricStreamIntvlInSecは25から150までにする必要があります。 -
自動メトリック・アップロードが有効で、ファイングレイン収集が無効になっている場合(
metricStreamIntvlInSec>0およびmetricFGCollIntvlInSec=0)、自動アップロード頻度は5分から30分の間である必要があります(metricStreamIntvlInSecは300から1800の間である必要があります)。
-
-
自動メトリック・アップロードを無効にするには、
metricStreamIntvlInSec=0を設定します。たとえば:
CellCLI> ALTER CELL metricStreamIntvlInSec=0
6.4.4.2.2 メトリック・ストリームのカスタマイズ
デフォルトでは、ストリーミングに対して自動的に一連のキー・パフォーマンス・メトリックが有効になります。ただし、特定のメトリックを有効または無効にすることで、メトリック・ストリームをカスタマイズできます。
-
メトリック・ストリームにメトリックを含めるには、
ALTER METRICDEFINITIONコマンドを使用し、streaming=enabledを指定します。たとえば:CellCLI> ALTER METRICDEFINITION N_NIC_KB_TRANS_SEC streaming=enabledCellCLI> ALTER METRICDEFINITION N_MB_SENT,N_MB_RECEIVED streaming=enabledCellCLI> ALTER METRICDEFINITION streaming=enabled WHERE name LIKE 'N_NIC.*' -
メトリック・ストリームからメトリックを削除するには、
ALTER METRICDEFINITIONコマンドを使用してstreaming=disabledを指定します。たとえば:CellCLI> ALTER METRICDEFINITION N_MB_SENT streaming=disabled -
メトリック・ストリームに含まれているメトリックを表示するには、次のコマンドを使用します。これはいつでも実行できます。
CellCLI> LIST METRICDEFINITION WHERE streaming=enabled -
各メトリックの説明や、メトリックがメトリック・ストリームに含まれているかどうかなど、メトリック定義の詳細をすべて表示するには、次のコマンドを使用します。これはいつでも実行できます。
CellCLI> LIST METRICDEFINITION DETAIL
6.4.4.2.3 自動メトリック・アップロードのエンドポイントの構成
metricStreamEndPoint属性を次のように設定すると、メトリック・ストリームを1つ以上の収集エンドポイントに自動的にアップロード(プッシュ)できます。
metricStreamEndPoint[+]=((host="endpoint-URL"[,type="stream-format"][,token="authentication-token"][,{httpProxy|httpsProxy}="proxy-server"])
[,(host="endpoint-URL"[,type="stream-format"][,token="authentication-token"][,{httpProxy|httpsProxy}="proxy-server"])]...)metricStreamEndPoint定義の内容:
-
host: 収集エンドポイントのURLを指定します。このURLでは、HTTPまたはHTTPSを使用できます。 -
type: オプションで、ストリームの形式を指定します。サポートされている値は次のとおりです。-
json: ストリームをJSON形式で提供します。 -
plaintext: ストリームをプレーン・テキスト形式で提供します。
デフォルト値は
jsonです。 -
-
token: オプションで、収集エンドポイントの認証トークンを指定します。トークンの生成の詳細は、メトリック収集プラットフォームを参照してください。 -
httpProxyまたはhttpsProxy: オプションで、収集エンドポイントへのネットワーク接続を容易にするためのプロキシ・サーバーを指定します。Exadataシステムと収集エンドポイントの間にファイアウォールが存在する場合は、プロキシ・サーバーが必要です。
オプションの+=演算子を使用すると、収集エンドポイントを既存のmetricStreamEndPoint定義に追加できます。それ以外の場合は、=演算子を使用すると前の属性値が上書きされます。
例6-23 JSONストリームの設定
この例では、JSONストリームを設定する方法を示します。この例のコマンドでは、hostおよびtokenの値が収集プラットフォームから取得されます。ネットワーク接続は、指定されたプロキシを介していると想定しています。
CellCLI> ALTER CELL metricStreamEndPoint=((host="https://ingest.stream.example.com/v2/datapoint",type="json",token="wcfA_**********Z58QpKg",httpProxy="www-proxy.example.com:80"))例6-24 プレーン・テキスト・エンドポイントの追加
この例では、プレーン・テキスト・エンドポイントを既存のmetricStreamEndPointに追加する方法を示します。この例のコマンドでは、hostおよびtokenの値が収集プラットフォームから取得されます。また、ネットワーク・プロキシを必要としない企業ネットワーク内に収集プラットフォームがあると想定しています。
CellCLI> ALTER CELL metricStreamEndPoint+=((host="http://idbsrv.example.com:8086/api/v2/write?org=Exadata&bucket=Metrics&precision=ns",type="plaintext",token="6unif**********rOXwtfkG0gWGENyePd6uN6OLR_deTZL4IuG9VTfDWwvpB-QvJcCcFs_NVjmpsyANz0Q8psA=="))6.4.4.3 Exadataサーバーからのメトリック観測データのダウンロード
指定したRESTエンドポイントを使用することでExadataサーバーからメトリック・ストリームをダウンロード(プル)できます。これには、システムでファイングレイン・メトリック収集が有効になっているか、システムが自動メトリック・アップロード用に構成されているかに関係なく、ストリーミングが有効になっているすべてのメトリック(streaming=enabled)が含まれます。
各ストレージ・サーバーでは、RESTエンドポイントのURLは次のようになります。
https://server-name/metricstream/list?stream=true各データベース・サーバーでは、エンドポイントによってポート7879が使用されます。そのため、URLは次のようになります。
https://server-name:7879/metricstream/list?stream=true効率を最大にするには、ダウンロード間隔をメトリック収集間隔の倍数にする必要があります。サーバーでファイングレイン・メトリック収集が有効(metricFGCollIntvlInSec>0)になっている場合は、ファイングレイン収集間隔でダウンロード頻度を調整します。それ以外の場合は、標準の1分の収集間隔でダウンロード頻度を調整します。
メトリック・ストリームへのアクセスを容易にするために、ストリームへのアクセス権のみを持つ専用ユーザー・アカウントを使用する必要があります。CellCLIで次のコマンド・シーケンスを使用するとユーザー・アカウントを適切に構成できます。これは後でRESTエンドポイントへの認証に使用できます。このコマンド・シーケンスにおいては、自分のユーザー名とロール名に置き換えます。
CREATE ROLE metric_collector_role
GRANT PRIVILEGE LIST ON METRICSTREAM ALL ATTRIBUTES WITH ALL OPTIONS TO ROLE metric_collector_role
CREATE USER metric_collector PASSWORD=<password>
GRANT ROLE metric_collector_role TO USER metric_collector親トピック: リアルタイム・インサイトの使用
6.4.4.4 メトリック観測データのタグ付け
各Exadataデータベース・サーバーおよびストレージ・サーバーで、メトリック・ストリームのすべての観測データに含める、一連のメトリック・タグを定義できます。これらのタグは、多数のExadataサーバーによって生成された観測データを整理およびグループ化するために役立ちます。
メトリック・タグを構成するには、metricStreamTags属性を、次のような、タグと値のペアを含む有効なJSON文字列に設定します。
metricStreamTags='{"tag1":"value1"[,"tag2":"value2"]...}'たとえば:
CellCLI> ALTER CELL metricStreamTags='{"application":"personnel","department":"HR"}'親トピック: リアルタイム・インサイトの使用
6.4.4.5 メトリック・ストリーム形式の理解
リアルタイム・メトリック観測データには、中心的な一連の属性が含まれています。ただし、メトリック・ストリームの形式は、アクセスのモードによって異なります。
メトリック・ストリームをメトリック収集プラットフォームに自動的にアップロードする場合は、メトリック・エンドポイント構成でメトリック・ストリーム形式を指定できます。使用可能な形式は、JSONまたはプレーン・テキストです。
次に、JSON形式の例を示します。
json: {
"gauge": [{
"metric": "OS_NET_RX_BY_SEC",
"value": "0.0012989044189453125",
"timestamp": 1652473286000,
"unit": "MB/sec",
"dimensions": {
"server": "celadm09.example.com",
"objectName": "eth0",
"nodeType": "STORAGE",
"fleet": "example-fleet",
"pod": "dbm01",
"cluster": "c01"
}
}, {
"metric": "SIO_IO_RD_FC_HD_SEC",
"value": "0.0",
"timestamp": 1652473286000,
"unit": "MB/sec",
"dimensions": {
"server": "celadm09.example.com",
"objectName": "SMARTIO",
"nodeType": "STORAGE",
"fleet": "example-fleet",
"pod": "dbm01",
"cluster": "c01"
}
}
]
}プレーン・テキスト形式には、基本的に、JSONストリームと同じ情報が含まれています。ただし、プレーン・テキスト形式では、各メトリック観測データが別々の行で示されます。次に、プレーン・テキスト形式の例を示します。
metrics,name=OS_NET_RX_BY_SEC,objectName=eth0,server=celadm09.example.com,unit=MB/sec,nodeType=STORAGE,fleet=example-fleet,pod=dbm01,cluster=c01 value=9.441184615324398E-4 1652473456000000000
metrics,name=OS_NET_RX_BY_SEC,objectName=eth0,server=celadm09.example.com,unit=MB/sec,nodeType=STORAGE,fleet=example-fleet,pod=dbm01,cluster=c01 value=0.002647613311980988 1652473457000000000指定したRESTエンドポイントを使用することでメトリック・ストリームをダウンロードする場合、データはプレーン・テキスト・アップロード形式に似た形式で示され、各メトリック観測データが別々の行で示されます。次に、ダウンロード形式の例を示します。
DS_CPUT{objectName="dbadm05",unit="%",server="dbadm05.example.com",nodeType="KVMHOST",fleet="example-fleet",pod="dbm01",cluster="c01"} 23.10906363831155 1652485449597
DS_MEMUT{objectName="dbadm05",unit="%",server="dbadm05.example.com",nodeType="KVMHOST",fleet="example-fleet",pod="dbm01",cluster="c01"} 99 1652485449597
DS_MEMUT_MS{objectName="dbadm05",unit="%",server="dbadm05.example.com",nodeType="KVMHOST",fleet="example-fleet",pod="dbm01",cluster="c01"} 0.12396045794483294 1652485449597次のリストでは、メトリック・ストリームに含まれる属性を説明します。
-
メトリック名は、次のように特定します。
-
JSONアップロード形式では、メトリック名は
metricタグの後に続きます。 -
プレーン・テキスト・アップロード形式では、メトリック名は、
name=の後に続く値です。 -
ダウンロード形式では、メトリック名は、各行の最初の要素であり、左中カッコ(
{)の前にあります。
-
-
メトリック値は、次のように見つけます。
-
JSONアップロード形式では、メトリック値は
valueタグの後に続きます。 -
プレーン・テキスト・アップロード形式では、メトリック値は
value=の後に続きます。 -
ダウンロード形式では、メトリック値は、各行の最後から2番目の要素であり、右中カッコ(
})の後に続きます。
-
-
メトリック観測の時間は、次のように見つけます。
-
JSONアップロード形式では、タイムスタンプは
timestampタグの後に続きます。タイムスタンプは、1970年1月1日のグリニッジ標準時(GMT) 00:00:00からのミリ秒数(1 x 10-3秒)で表されます。 -
プレーン・テキスト・アップロード形式では、タイムスタンプは各行の最後の要素です。タイムスタンプは、1970年1月1日のグリニッジ標準時(GMT) 00:00:00からのナノ秒数(1 x 10-9秒)で表されます。
-
ダウンロード形式では、タイムスタンプは各行の最後の要素です。タイムスタンプは、1970年1月1日のグリニッジ標準時(GMT) 00:00:00からのミリ秒数(1 x 10-3秒)で表されます。
-
-
unit値では、メトリック観測の測定単位が示されています。 -
server値には、メトリック観測データを生成したExadataサーバーの名前が含まれています。 -
objectName値には、メトリックに関連付けられているExadataオブジェクトの名前が含まれています。 -
nodeType値には、メトリック観測データを生成したExadataサーバーのタイプが含まれています。 -
fleet、podおよびcluster属性は、ユーザーが定義したメトリック・タグの例であり、多数のExadataサーバーによって生成された観測データを整理およびグループ化するために使用できます。メトリックにタグ付けするには、metricStreamTagsのCELL属性を設定します。
関連項目
親トピック: リアルタイム・インサイトの使用