スマート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に示されます。次の項では、その理由について詳しく説明します。
状況によっては、スマート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です。