この記事はAndy RivenesによるQuestions You Asked: What is CELLMEMORY, and how do I know if it is being used?を日本語に翻訳したものです。
2023年12月05日
列形式データは、Oracle Databaseリリース12.1.0.2のExadata Smart Flash Cacheで初めて導入されました。 この最初の形式では、HCCオブジェクトをサポートしています。“…Flash Cache内のHCC形式ブロックの1MBチャンクを純粋な列形式に書き換えました。 これにより、必要な列の I/O のみを実行できるようになりました。また、必要に応じて元のブロックを再作成することもできます。 [1]
Oracle Databaseリリース12.2では、列指向形式でデータをExadata Smart Flash Cacheに格納する2つ目の形式が導入され、Database In-Memoryのすべての最適化が機能するようになりました。 これはCELLMEMORYと呼ばれるもので、Oracle Exadata System Software 18c (18.1.0)でさらに拡張され、非HCCオブジェクトもサポートされるようになりました。 詳細については、私の投稿Database In-Memory Columnar Format in Exadata Flashを参照してください。
これ以降、この記事では最初のバージョンをHCC列型キャッシュと呼び、2番目のバージョンをCELLMEMORYと呼びます。
この記事の目的は、Exadata Flashで列型キャッシュ形式を実際に使用したかどうか、使用している場合はどれを使用したかを判断する方法を詳しく説明することです。 同僚のMarkus Kisslingが2018年8月に How to Determine if Columnar Format on Exadata Flash Cache is Being Usedという記事を書いています。それ以降、Oracle Databaseには多くの変更と新しい統計値が追加されているため、 更新するにはいい機会だと思いました。
初めに背景を説明します。列型キャッシュは、Exadata Smart Flash Cacheの一部であり、スマートI/O最適化です。 これは基本的に列型キャッシュにはSmart Scanを利用してアクセスする必要があることを意味します。 Exadata Smart Scanは、データの検索および取得処理をExadataストレージサーバーにオフロードします。 Smart Scanの詳細については、 System Software User’s Guide for Exadata Database Machineを参照してください。
Smart Scanの重要な点は、述語と列のフィルタリングを最適化することです。つまり、データのアクセス中にWHERE句からのフィルタ条件を評価することができます。 また、全ての列ではなく、要求された列のみを返すように列をフィルタリングすることもできます。 他にも実行可能な機能はありますが、HCC列型キャッシュやCELLMEMORYが使用されたかどうかを見分ける方法を検討する際に、この2つの基本的な機能を理解しておくことが重要です。
Smart Scanを使用したかどうか知るには？最初の前提条件は、実行計画にTABLE ACCESS STORAGE FULLオペレーションが含まれていることです。以下に例を示します。
---------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 28288 (100)| | | 1 | SORT AGGREGATE | | 1 | 6 | | | | 2 | TABLE ACCESS STORAGE FULL| LINEORDER | 11M| 68M| 28288 (15)| 00:00:02 | ----------------------------------------------------------------------------------------------
スマートI/O操作が実行されない理由はたくさんあるため、これはSmart Scanが実施されることを保証するものではありません。 詳細については、System Software User’s Guide for Exadata Database Machineを参照ください。 ただし、TABLE ACCESS STORAGE FULLが表示された場合には、クエリーのセッション・レベル統計を確認することで、列型キャッシュが使用されたかどうかの詳細を知ることができます。
下記の表では、次の表は、Smart Scanが利用されたかどうか、および列型キャッシュがアクセスされたかどうかを評価する際に重要な関連統計値を示しています。 これらの統計値とその意味は、System Software User’s Guide for Exadata Database MachineとOracle Database Referenceにも記載されています。 これらの統計値をセッションまたはシステムレベルで評価する際に、重要なことは(a)表/セグメントがストレージ上でどれだけ領域を利用しているか(b)HCC列型キャッシュまたはCELLMEMORYのデータ形式を利用してFlashにキャッシュにどれだけ領域を利用しているか。です。
統計値の一部が元の統計値のサブセットであることを示すために、統計値の一部を字下げしています。また、統計の意味をより明確にするために、説明の一部を変更しています。
| Statistic | Meaning |
|---|---|
| cell physical IO bytes eligible for predicate offload | 述語のオフロード対象となるディスク上のバイト数 |
| cell physical IO bytes eligible for smart IOs | 述語のオフロード対象となる実際のバイト数。たとえば、列型キャッシュを使用する場合、これはディスク上のサイズではなく列型キャッシュのサイズ |
| cell physical IO bytes saved by storage index | ストレージ索引を利用して節約されたバイト数 |
| HCC scan cell CUs pruned | HCCオブジェクトで、最小/最大値チェックに基づいてプルーニングされた圧縮単位の数 |
| cell physical IO bytes saved by columnar cache | 列型キャッシュで列がスキップされて(つまり、列のフィルタリング)、読まれなかったバイト数 |
| cell physical IO bytes processed for no memcompress | HCC列型キャッシュ形式で読まれたバイト数 |
| cell physical IO bytes processed for IM capacity | memcompress for capacity形式(デフォルト)を利用したCELLMEMORYで読まれたバイト数 |
| cell physical IO bytes processed for IM query | memcompress for query形式を利用したCELLMEMORYで読まれたバイト数 |
| cell scan CUs pcode aggregation pushdown* | プッシュダウンによって集計やグループ化の恩恵を受けたCUの数 |
| cellmemory IM scan column CUs format dict* | 最適なインメモリディクショナリ形式のCU数 |
| cellmemory IM scan column CUs format rle dict* | 最適なインメモリランレングス符号化ディクショナリ形式のCU数 |
| cell physical IO interconnect bytes returned by smart scan | Smart Scan操作のためにCELLによって返されたI/Oバイト数 |
* – CELLMEMORYの機能強化
CELLMEMORY の使用状況を評価する場合、注目すべき重要な統計は、”cell physical IO bytes processed for IM capacity”と”cell physical IO bytes eligible for smart IO”です。 IM capacityまたは圧縮レベルを利用している場合はqueryの統計値がスマートIO統計の対象となるバイトの割合が大きい時には、データセットの大部分でCELLMEMORYが使用されたことを意味し、最大の性能が得られる。
またMEMCOMPRESS統計値の下に3つのCELLMEMORY統計があり、Smart Scan中にIn-Memoryの恩恵を得たかを示します。 他にもたくさんありますが、この3つはCELLMEMORYでIn-Memory最適化が使用されたかどうかを知る最大の手がかりとなります。
では、例を見てみましょう。 以下は、Database In-Memoryの例で使用しているSSBスキーマの一部であるLINEORDER表だけをスキャンし、2つのWHERE句フィルタ条件で最も高価な注文を探す単純なクエリです。 実行計画とセッションレベルの統計も表示されます。また、一貫した結果が得られることを確認するために、このクエリを数回実行しました。
SQL> select max(lo_ordtotalprice) most_expensive_order From LINEORDER
2 where lo_shipmode = 'SHIP' and lo_orderpriority = '5-LOW';
MOST_EXPENSIVE_ORDER
--------------------
53060444
SQL>
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------
SQL_ID 1805gvxmtb2r8, child number 2
-------------------------------------
select max(lo_ordtotalprice) most_expensive_order From LINEORDER where
lo_shipmode = 'SHIP' and lo_orderpriority = '5-LOW';
Plan hash value: 2609824775
----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 32344 (100)| |
| 1 | SORT AGGREGATE | | 1 | 33 | | |
|* 2 | TABLE ACCESS STORAGE FULL| LINEORDER | 78559 | 2531K| 32344 (26)| 00:00:02 |
----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - storage(("LO_SHIPMODE"='SHIP' AND "LO_ORDERPRIORITY"='5-LOW'))
filter(("LO_SHIPMODE"='SHIP' AND "LO_ORDERPRIORITY"='5-LOW'))
NAME VALUE
------------------------------------------------------------ --------------------
cell physical IO bytes eligible for predicate offload 729382912
cell physical IO bytes eligible for smart IOs 513335296
cell physical IO bytes processed for IM capacity 299892736
cell physical IO bytes saved by columnar cache 57540608
cell physical IO interconnect bytes returned by smart scan 33492480
cell scan CUs pcode aggregation pushdown 635
cell scan CUs pcode pred evaled 1270
cell scan rows pcode aggregated 269537
Predicate Informationに以下が表示されていることに気がついたかもしれません。
storage(("LO_SHIPMODE"='SHIP' AND "LO_ORDERPRIORITY"='5-LOW'))
これは2つのフィルタ条件がSmart Scanにプッシュダウンまたはオフロードされることを示します。
統計セクションには、上記の統計表からゼロ以外の統計値だけを含めました。 私の目的は、Smart Scanが発生したこと(つまり、cell physical IO bytes eligible for smart IOs)とCELLMEMORYが使用されたこと(つまり、cell physical IO bytes processed for IM capacity）を見分ける方法を示すことでした。 “cell physical IO bytes saved by columnar cache”に示されているようにSmart ScanはLINEORDER表の不要な列を読み込み込みを回避することもできました。 最後に、下部にある3つの”pcode”統計で、CELLMEMORYの最適化をさらに活用したことがわかります。
- cell scan CUs pcode aggregation pushdown – プッシュダウンによって集計やグループ化の恩恵を受けたCUの数
- cell scan CUs pcode pred evaled – 述語のプッシュダウンのために評価されたCU数
- cell scan rows pcode aggregated – 述語を通過して集計された行の数
要するに、CELLMEMORYが使用されただけでなく、フィルタリング(WHERE句のフィルタ条件)と集計(MAXファンクション)のためのIn-Memory最適化もSmart Scan中に使用されたことがわかります。
これは大変な作業と思うかもしれないが、すべてのSQLクエリーを調べて、CELLMEMORYが使用されているか確認したいと思う人はいないでしょう。ほとんどの場合、その通りだと思います。 使用状況を評価するために統計情報を使用しているため、これらの統計情報はAutomatic Workload Repository(AWR)にデータベース・レベルで集約されます。 特定の期間のAWRレポートを見て、CELLMEMORY統計が増加していることを確認し、CELLMEMORYを利用していることを認識するだけで済みます。 個々のSQL文を確認する主な理由は、特定のパフォーマンス上の懸念があるかどうか、または列型キャッシュの使用に関する学習を深めるための演習としてです。
[1] SmartScan: What’s New in 12.2 CELLMEMORY, Part 1