Amazon RDS for Oracleのスマートフラッシュキャッシュを試してみた

# はじめに
2022/9/14 に 「Amazon RDS for Oracle に、M5d/R5d インスタンス向けの一時テーブルスペース用インスタンスストアおよびデータベーススマートフラッシュキャッシュのサポートを追加」(https://aws.amazon.com/jp/about-aws/whats-new/2022/09/amazon-rds-oracle-instance-store-temporary-tablespace-database-smart-flash-cache-m5d-r5d/) が発表され、それを受けて[インスタンスストアを一時表領域にする方法を試した](https://qiita.com/asahide/items/be714a426ec735658107)。

アップデートの内容としては、インスタンスストアを一時表領域またはスマートフラッシュキャッシュに利用できる、ということだったので、今回はスマートフラッシュキャッシュの利用を試してみた。

スマートフラッシュキャッシュだが、[Oracleのガイド](https://docs.oracle.com/cd/F19136_01/admin/managing-memory.html#GUID-31E0885D-53DB-442D-BC5F-DDE0588C915A)にも説明があるとおり、データベース・バッファ・キャッシュの透過的な拡張領域となる。また、スマートフラッシュキャッシュ自体はEnterprise Editionでのみ設定できるパラメータとなる。

今回はインスタンスストアのスマートフラッシュキャッシュの設定と、設定による効果を確認した。

## スマートフラッシュキャッシュの設定

まず、ガイド（[Configuring an RDS for Oracle instance store](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.advanced-features.instance-store.html#CHAP_Oracle.advanced-features.instance-store.configuring)）に記載のある通り、デフォルトではインスタンスストア領域は全て一時表領域に割り当てられる。

スマートフラッシュキャッシュを利用したい場合には、パラメータグループにて一時表領域の割り当て(rds.instance_store_temp_size)を減らし、スマートフラッシュキャッシュ(db_flash_cache_size)の割り当てを増やす必要がある。現時点では20%ずつ増減させることができる。

- rds.instance_store_temp_size
![temp-06.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/82e74bb0-a8a4-be39-0c25-bb3b329a5f61.png)

- db_flash_cache_size
![flash-cache-4.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/9feeccd4-e0e8-8d8a-e501-ba5b211c806b.png)


今回は rds.instance_store_temp_size を 6/10、db_flash_cache_size を4/10 で設定した。
上記を設定して起動すると、次のように設定され、合計すると 26,849MB 程度となる。
前回確認したとおり、r5d.large インスタンスでは 実容量としては全体で 67,123MB となるため、40% となっていることがわかる。
```SQL:v$flashfilestat
FLASHFILE# NAME                                                    BYTES    ENABLED 
---------- -------------------------------------------------- ---------- ---------- 
         1 /rdslocalstorage/dsfc1.dbf                         3519188828          1 
         2 /rdslocalstorage/dsfc2.dbf                         3519188828          1 
         3 /rdslocalstorage/dsfc3.dbf                         3519188828          1 
         4 /rdslocalstorage/dsfc4.dbf                         3519188828          1 
         5 /rdslocalstorage/dsfc5.dbf                         3519188828          1 
         6 /rdslocalstorage/dsfc6.dbf                         3519188828          1 
         7 /rdslocalstorage/dsfc7.dbf                         3519188828          1 
         8 /rdslocalstorage/dsfc8.dbf                         3519188828          1 
```

#### スマートフラッシュキャッシュへのキャッシング

テーブルの FLASH_CACHE 属性をKEEPにすることで、優先的にキャッシュすることができる。
```SQL:FLASH_CACHE属性
SQL> alter table testusr.test01  storage (flash_cache keep);
Table altered.

SQL> select table_name, flash_cache from dba_tables where table_name = 'TEST01';
TABLE_NAME    FLASH_C
-----------   -------
TEST01        KEEP
```

## スマートフラッシュキャッシュの効果

スマートフラッシュキャッシュを未設定の状態と、設定した状態で大きなテーブルへのSELECT結果を比較した。
結果、スマートフラッシュキャッシュを設定すると物理読み込みが低減され、また、実行時間も若干短くなることが確認できた。
（ただしバッファキャッシュの利用状況等により大きく変わるため、参考程度）

| |スマートフラッシュキャッシュ設定<br>なし | スマートフラッシュキャッシュ設定<br>あり(26,849MB)|
|-|-|-|
|consistent gets|1,309,098| 1,309,118
|physical reads|545,667| 351,486
|SQL実行時間(比率)|1|0.95

※v$sysstat の [phys read, write 辺り](https://docs.oracle.com/cd/F19136_01/refrn/statistics-descriptions-2.html#GUID-2FBC1B7E-9123-41DD-8178-96176260A639)のデータを取るともう少し状況は把握できると思われる


- スマートフラッシュキャッシュ設定なし(EBSの読み込み)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/a87c9774-1a13-a74b-efc3-1b6a9842874e.png)


- スマートフラッシュキャッシュ設定あり(EBSの読み込み)：縦軸注意
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/bf142295-b19e-2692-7b43-c26b506c7954.png)

# まとめ
インスタンスストアをスマートフラッシュキャッシュとして利用することで性能向上、また、物理読み込みの負荷低減が行えることが確認できた。
スマートフラッシュキャッシュが性能に効いてくるワークロードは、 [Oracleのテクニカルペーパ](https://www.oracle.com/technetwork/articles/systems-hardware-architecture/oracle-db-smart-flash-cache-175588.pdf)や[ホワイトペーパ](https://www.oracle.com/assets/wp-vm-flashcache-gridcenter-289792-ja.pdf) にもあるとおり、バッファキャッシュから恒常的にキャッシュアウトするような状況、つまり、バッファキャッシュのヒット率が低い場合に有効となる。
自身のシステムのワークロードに当てはめて、必要な場合には利用すると性能向上が図れると想定される。