Exadataスマート・フラッシュ・キャッシュの手動移入

デフォルトでは、Exadataスマート・フラッシュ・キャッシュは、ディスクからデータを読み取るときに自動的に移入されます。これは、ほとんどのアプリケーション・シナリオに最適な方法です。ただし、アプリケーションが初期ディスク読取りのI/Oレイテンシの増加に敏感である場合は、Exadataスマート・フラッシュ・キャッシュを手動で移入できます。このトピックでは、Exadataスマート・フラッシュ・キャッシュを手動で移入する方法および考慮事項について説明します。

データのスキャン

Exadataスマート・フラッシュ・キャッシュがいっぱいでない場合は、通常は全表スキャンを介して必要なデータにアクセスするだけで、データをキャッシュに読み取ることができます。

Exadataスマート・フラッシュ・キャッシュに使用可能な領域があるかどうかを確認するには、FC_BY_ALLOCATEDメトリックをeffectiveFlashCacheSize属性と比較します。たとえば、次の出力は、各セルに約4TBの使用可能領域が含まれることを示しています。

# FC_BY_ALLOCATED shows that each cell contains approximately 19 TB of data allocated
$ dcli -g cell_group cellcli -e list metriccurrent where name\=\"FC_BY_ALLOCATED\"
db01celadm01: FC_BY_ALLOCATED        FLASHCACHE      19,313,940 MB
db01celadm02: FC_BY_ALLOCATED        FLASHCACHE      19,311,784 MB
db01celadm03: FC_BY_ALLOCATED        FLASHCACHE      19,311,688 MB

# effectiveCacheSize shows that each cell contains approximately 23 TB of flash cache space
$ dcli -g cell_group cellcli -e list flashcache attributes effectiveCacheSize detail
db01celadm01: effectiveCacheSize:     23.28692626953125T
db01celadm02: effectiveCacheSize:     23.28692626953125T
db01celadm03: effectiveCacheSize:     23.28692626953125T

次の問合せを使用して、必要なデータがExadataスマート・フラッシュ・キャッシュに移入されているかどうかを確認できます。

select name,value
  from v$statname n,
       v$mystat s
  where s.statistic# = n.statistic#
    and name in ('physical read IO requests','physical read requests optimized')
  order by name;

次に例を示します:

-- get session statistics
SQL> select name,value
  2    from v$statname n,
  3         v$mystat s
  4    where s.statistic# = n.statistic#
  5      and name in ('physical read IO requests','physical read requests optimized')
  6    order by name;

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
physical read IO requests                                                 5
physical read requests optimized                                         11

// run the desired workload...

-- get session statistics again
SQL> select name,value
  2    from v$statname n,
  3         v$mystat s
  4    where s.statistic# = n.statistic#
  5      and name in ('physical read IO requests','physical read requests optimized')
  6    order by name;

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
physical read IO requests                                            45,193
physical read requests optimized                                     23,140

前の例では、45188回の物理読取りリクエスト(45193 - 5)を実行したワークロードのうち、23129 (23140 - 11)が最適化されています。この場合、22059 (45188 - 23129)回の最適化されていない(ディスク)読取りが実行されています。

ワークロードを繰り返す場合、すべての読取りを最適化する必要があります(physical read IO requests = physical read requests optimized)。これは、必要なすべてのデータがExadataスマート・フラッシュ・キャッシュに移入されることを示します。

flashCacheMinの使用

Exadataスマート・フラッシュ・キャッシュが統合環境で完全に移入されている場合は、I/Oリソース管理(IORM) flashCacheMin設定を使用して領域を解放し、必要なデータをキャッシュに読み取ることができます。この場合、flashCacheMin設定は、必要なデータを追加するための十分な領域を持つデータベースによって占有されている現在の領域よりも大きくする必要があります。

ノート:

コンテナ・データベース(CDB)を使用する場合、CDBにプラガブル・データベース(PDB)が1つのみ存在する場合でも、各PDBへのリソース割当てを管理するためにCDBリソース・プランが必要です。

各データベースの現在のExadataスマート・フラッシュ・キャッシュ領域割当てを確認するには、DB_FC_BY_ALLOCATEDメトリックを確認します。次に例を示します:

$ dcli -g cell_group cellcli -e list metriccurrent where name\=\"DB_FC_BY_ALLOCATED\"
db01celadm01: DB_FC_BY_ALLOCATED     ASM                     0.000 MB
db01celadm01: DB_FC_BY_ALLOCATED     DBCDB1              1,694,241 MB
db01celadm01: DB_FC_BY_ALLOCATED     DBCDB2              4,851,611 MB
db01celadm01: DB_FC_BY_ALLOCATED     DBCDB3              4,638,129 MB
db01celadm01: DB_FC_BY_ALLOCATED     DBCDB4              2,157,755 MB
db01celadm01: DB_FC_BY_ALLOCATED     DBCDB5              9,509,356 MB
db01celadm01: DB_FC_BY_ALLOCATED     _OTHER_DATABASE_      365,790 MB
db01celadm02: DB_FC_BY_ALLOCATED     ASM                     0.000 MB
db01celadm02: DB_FC_BY_ALLOCATED     DBCDB1              1,629,001 MB
db01celadm02: DB_FC_BY_ALLOCATED     DBCDB2              4,761,316 MB
db01celadm02: DB_FC_BY_ALLOCATED     DBCDB3              4,495,902 MB
db01celadm02: DB_FC_BY_ALLOCATED     DBCDB4              2,106,805 MB
db01celadm02: DB_FC_BY_ALLOCATED     DBCDB5              9,848,567 MB
db01celadm02: DB_FC_BY_ALLOCATED     _OTHER_DATABASE_      377,023 MB
db01celadm03: DB_FC_BY_ALLOCATED     ASM                     0.000 MB
db01celadm03: DB_FC_BY_ALLOCATED     DBCDB1              1,664,919 MB
db01celadm03: DB_FC_BY_ALLOCATED     DBCDB2              4,872,123 MB
db01celadm03: DB_FC_BY_ALLOCATED     DBCDB3              4,459,631 MB
db01celadm03: DB_FC_BY_ALLOCATED     DBCDB4              2,096,412 MB
db01celadm03: DB_FC_BY_ALLOCATED     DBCDB5              9,750,586 MB
db01celadm03: DB_FC_BY_ALLOCATED     _OTHER_DATABASE_      315,181 MB

前の例では、DBCDB1は各セルで約1.6 TBのキャッシュ領域を消費しています。各セルのDBCDB1割当てを2 TBに増やす最小のIROMプランを作成するには、次のコマンドを使用します。

$ dcli -g cell_group cellcli -e alter iormplan dbplan=\(\(name=DBCDB1, flashCacheMin=2T\)\)

Exadataスマート・フラッシュ・キャッシュが統合環境に完全に移入されている場合は、IORM flashCacheMinを使用して、1つのデータベースの割当てを増やすことで、他のすべてのデータベースの領域を効果的に奪います。このような場合、キャッシュ領域はすぐに転送されず、必要なデータをキャッシュに入れるためにスキャンが複数回実行される可能性があります。

CELL_FLASH_CACHE KEEPの使用

他の方法に加えて、CELL_FLASH_CACHEセグメント・ストレージ・オプションをKEEPに設定すると、データが使用されていない場合でも、セグメントの優先度を高め、セグメント・データをExadataスマート・フラッシュ・キャッシュに保持できます。

次に例を示します:

SQL> CREATE TABLE t1 (c1 number, c2 varchar2(200)) STORAGE (CELL_FLASH_CACHE KEEP);

SQL> ALTER TABLE t2 STORAGE (CELL_FLASH_CACHE KEEP);

Oracle Exadata System Softwareリリース24.1.0以降、Oracle Database 23aiとの組合せでは、この設定のセグメントはExadataスマート・フラッシュ・キャッシュに自動的に移入されます。以前は、セグメントの読取り時にセグメント・データが移入されていました。

手動で移入するオブジェクトの識別

AWRレポートの「Segments by UnOptimized Read」セクションを使用して、キャッシュされていないオブジェクトを識別できます。

この情報は、physical readsをV$SEGMENT_STATISTICSおよびV$SEGSTATのoptimized physical readsと比較することによっても使用可能です。

その他の考慮事項

手動移入が実行されると、小さいセグメントがダイレクト・パス読取りの対象ではなくなり、最終的にデータベース・バッファ・キャッシュに移入される可能性があります。これを回避するには、パラレル問合せを使用してスキャンを実行します。
表およびそれらに関連付けられた索引のデータをキャッシュに移入するには、スキャンを複数回実行する必要があります。キャッシュに索引ブロックを移入するには、INDEX FAST FULL SCANを使用します。