津島博士のパフォーマンス講座 indexページ▶▶

津島博士のパフォーマンス講座 
第69回 Oracle Exadata Database Machineについて

■津島博士による解説が動画でも! セミナー動画公開中です。
津島博士のパフォーマンス講座「パフォーマンス問題はなぜ起きるのか」  【WMV】 【MP4】 【PDF

皆さんこんにちは、寒さもだいぶ厳しくなってきましたが、体調に気を付けて今年のやり残しがないようにしましょう。
今回は、これまであまり説明していなかったOracle Exadata Database Machine(Exadata)を取り上げようと思います。いろいろな機能が拡張されて分かりづらくなっていますので、その整理も含めてExadataの良さを説明します。最後に、Exadataのパフォーマンス統計についても説明していますので、参考にしてください。

1. Exadataの基本機能
まずは、Exadataの基本機能から説明します。
Exadataで優れているのは、Oracleデータベースを効果的に使用することができる、第26回で少し触れたExadata Storage Server Software(Exadata Storage)になります。主な機能としては、データウェアハウス(DWH)用のフル・スキャン性能改善機能、OLTP用のFlashキャッシュ機能、Consolidation(統合)用のI/O Resource Managerがあります。それぞれの効果の確認方法は、「3.Exadataの統計」を参照してください。

(1)DWH関連の機能
DWHで多く使用するフル・スキャンは、システム性能のボトルネックになりやすい処理です。そのI/Oを効果的にするExadataの機能として、以下が提供されています。フル・スキャンが速いので、難しい索引設計を行わなくても使用できるのが、Exadataの最大のメリットと言えます。

  • ・Smart Scan(Exadata Storage Serverにオフロードする)
  • ・Storage Index(不要なI/Oを削減する)
  • ・Hybrid Columnar Compression(表サイズをより小さくする)

(a)Smart Scan(スマート・スキャン)
Smart Scanは、SQLの一部をExadata Storage Server(CELLサーバー)にオフロードすることで、データベース・サーバーとCELLサーバー間のI/O量を最小限にする機能です。オフロードされる処理には、行のフィルタリング(WHERE句の条件)、ハッシュ結合のフィルタリング(ブルーム・フィルター)、列のフィルタリング、そして暗号データの復号化などがあります。ただし、以下のような条件ではオフロードされないので注意してください。

  • ・ダイレクト・パス・リードを行っていない(動作条件は第44回の「2.ダイレクト・リード」を参照)
  • ・ヒープ表(通常の表)でない(クラスタ表/索引構成表である)
  • ・LOB、LONG型のデータが参照されている(インラインLOBはExadata Storage 12.1.1.1/Oracle12.1.0.2から可能)
  • ・圧縮型索引または逆キー索引でIndex Fast Full Scan(索引高速フル・スキャン)が実行されている(圧縮型索引はExadata Storage 12.2.1.1/Oracle12.2.0.1から可能)
  • ・Hybrid Columnar Compression表圧縮以外のときに255を超える列を参照している
  • ・行連鎖している(マルチ・ブロック読取りと単一ブロック読取りになる)
  • ・仮想列に対する条件である
  • ・ROWDEPENDENCIES属性の指定やORA_ROWSCN疑似列がフェッチされている
  • ・フラッシュバックVERSION問合せを実行している

これ以外にもWHERE句の条件に関数などを使用すると、オフロードされないものがあります(オフロードされる式や関数は、以下のSQLで確認することができます)。

SQL> SELECT name FROM v$sqlfn_metadata WHERE offloadable = 'YES';

オフロードされる条件の確認は、初期化パラメータCELL_OFFLOAD_PLAN_DISPLAYがAUTO(デファルト)だと、以下の左側のように、実行計画の述語情報(Predicate Information)に"Storage(フィルター)"として出力されるので、これでも行うことができます。ただし、Smart Scanを行うかは、実行時に決定するので、実際にSmart Scanが動作しないときでも、出力される場合があるので注意してください。

SQL> SELECT * FROM tab02 WHERE c2 = 1;

-------------------------------------------
| Id  | Operation                 | Name  |
-------------------------------------------
|   0 | SELECT STATEMENT          |       |
|*  1 |  TABLE ACCESS STORAGE FULL| TAB02 |
-------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - storage("C2"=1)
       filter("C2"=1)
SQL> SELECT /*+OPT_PARAM('cell_offload_processing' 'false')*/ *
  2    FROM tab02 WHERE c2 = 1;

-------------------------------------------
| Id  | Operation                 | Name  |
-------------------------------------------
|   0 | SELECT STATEMENT          |       |
|*  1 |  TABLE ACCESS STORAGE FULL| TAB02 |
-------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("C2"=1)

また、通常のブルーム・フィルター以外に、Oracle Database 11gR2(Oracle11gR2)からシリアル・ハッシュ結合のフィルターもオフロードされるようになっています。

(b)Storage Index(ストレージ索引)
ストレージ索引は、Smart Scanを行ったときに、WHERE句の条件から行セット(1Mバイトごと)の最小値/最大値を使用して、パーティション・プルーニングのように、CELLサーバーで必要ない行セットの削除を行う処理(必要ないI/Oを回避する処理)になります。行セットの削除には、条件フィルターとブルーム・フィルターがあり、比較条件に等価 (=)、不等価(<>または!=)、以下(<=)、以上(>=)、IS NULL、IS NOT NULLを使用した問合せで動作します。ストレージ索引は、最大8列まで自動的に作成され、Hybrid Columnar Compressionとは関係なく動作します。Exadata Storage 12.2.1.1からは、24列までの列情報を格納するよう拡張されています。

(c)Hybrid Columnar Compression(ハイブリッド列圧縮)
Hybrid Columnar Compression(HCC)は、圧縮効率の良い列型形式と行アクセスを両立する圧縮形式で、Smart ScanのときにはCELLサーバーで解凍も行います。CU(Compression Unit)単位に、行データが完結するように格納されているので、効率的な行アクセスが維持されます。ただし、OLTPのような、行アクセスがメインになるような処理には向きません(詳細は第28回の「(2)ウェアハウス圧縮とアーカイブ圧縮」を参照してください)。HCCは、最初はExadataだけ使用できましたが、Oracle Database EE 11.2.0.3からOracleストレージ(Pillar Axiom、ZFSSA、FS1)もサポートするように拡張されています。

(2)OLTP関連の機能
フル・スキャンを行わないOLTPでは、Smart Scanの効果がありません。そこで、以下のFlashテクノロジーを使用して、安定した高いIOPS(1秒当たりのI/O回数)を実現することで性能を向上しています。

  • ・Exadata Smart Flash Cache
    Flashをストレージ・キャッシュとして使用することで物理I/Oを削減します(Exadata Storage 11.2.3.2から第26回で説明したWrite-Backモードが可能になっています)。自動的にキャッシュするのは、単一ブロック読取り(索引スキャン)だけになるので、フル・スキャンはKEEP指定する必要がありましたが、Exadata Storage 11.2.3.3からフル・スキャンも有効なときに自動的にキャッシュします(ただし、単一ブロック読取りが優先されるのは変わりません)。Exadata X3とX4では、Smart Flash Cache 圧縮(Flash上で自動的に圧縮と解凍を行う)がありましたが、Exadata X5以降からはなくなっています。
  • ・Exadata Smart Flash Logging
    OLTP性能に影響するRedoログ書込みを、Flashとディスクに同時に書込みを実行して、いずれかが完了したときに、データベースに対して即座に処理の完了を通知します。これにより、ディスク・コントローラ・キャッシュの書込みが低速になるときも、FlashによりRedoログ書込みを高速化することができます。

(3)Consolidation(統合)用のI/O Resource Manager
Exadataは、データベースの統合にも効果的に使用することができます。ただし、フル・スキャンは、ストレージ・リソースを多く使用するので、同時実行が多いとストレージ性能が限界になりやすいです(ストレージ索引でリソースをあまり使用しないようにはしていますが、すべての場合で効果的とは限りません)。ストレージ・リソースの制御は簡単ではありませんが、Oracleデータベースと連携しているI/O Resource Managerを使用することで、Oracleデータベースのリソース・マネージャのコンシューマ・グループ間でストレージのワークロードも制御することができます。

2. Exadataの機能拡張
次に、Exadataがどのように拡張されてきたかを説明します。
Exadataは、より効果的に使用できるように、いろいろな機能が拡張されています。その中から性能に関係する代表的な機能をいくつか取り上げます(以下はOracle12c以降の代表的な機能になります)。

  • ・HCC Row Level Locking(Oracle12cから)
  • ・HCC Compression for Array Inserts(Oracle12cR2から)
  • ・Columnar Flash Caching(Exadata Storage 12.1.2.1から)
  • ・In-Memory Columnar Caching(Exadata Storage 12.2.1.1から)

(1)HCC Row Level Locking(HCCの行レベル・ロック)
HCCでは、CU単位のロックを行うため、DML操作の同時実行性が良くありませんでしたが、Oracle12cからは行レベルでのロックが可能になりました(指定は、以下のように行います)。ただし、Advanced Compression Optionが必要になるので、デフォルトは"NO ROW LEVEL LOCKING"です。

CREATE TABLE … COLUMN STORE COMPRESS FOR [<HCC圧縮タイプ>] [ROW LEVEL LOCKING | NO ROW LEVEL LOCKING]

行レベル・ロックは、ITL以外にCUヘッダーに行レベルのロック情報(ロックビット)を格納して行います(CU内で最大255行までになります)。これまでのHCCよりDML操作に優れていますが、行レベルのOLTP表圧縮(Oracle12cからAdvanced Row Compression)に変換する必要があるのは変わりません(データの更新では、行の削除とOLTP表圧縮ブロックへの挿入を行います)。
また、HCCで索引スキャンするときは、CU単位に解凍してアクセスする必要があるので、索引範囲スキャンで多くの行をランダムにアクセスすると、同一CUを何回も解凍することになります。そのため、Oracle12cからは、ROWIDのデータ・ブロック・アドレス(同一CUは同じアドレス)でソートすることで、同一CU内の行を1回の解凍でアクセスできるようにしました(動作したときの実行計画は、以下のように「SORT CLUSTER BY ROWID」や「SORT CLUSTER BY ROWID BATCHED」が出力されます)。

SQL> SELECT /*+ INDEX(t2) */ id FROM t2 WHERE n1 = 50;

-----------------------------------------------------
| Id  | Operation                           | Name  |
-----------------------------------------------------
|   0 | SELECT STATEMENT                    |       |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| T2    |
|   2 |   SORT CLUSTER BY ROWID BATCHED     |       |
|*  3 |    INDEX RANGE SCAN                 | T2_I1 |
-----------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("N1"=50)

HCCは、行の管理をCUレベルで行うため、行レベルで行うトランザクション処理には向いていません。そのため、索引スキャンが少ない表(フル・スキャンがメインの表)で使用するようにしてください。

(2)HCC Compression for Array Inserts(配列挿入のHCC圧縮)
HCC表の作成には、ダイレクト・パス操作を行う必要がありましたが、PLSQL/Oracle Call Interface(OCI)などの挿入ループ操作は、多くの場合に特別な配列挿入を実行します。また、ダイレクト・パス操作では、表ロックを使用するので、行えない場合もありました。そのため、Oracle12cR2から配列挿入(非ダイレクト・パス操作)でもHCC表にすることが可能になっています。これでNOAPPENDヒントのINSERT SELECTやAPPENDヒント無しのシリアルINSERT SELECTでもHCC表にすることができます。
また、OLTP表圧縮でも配列挿入が改善されているので、参考のために載せておきます。OLTP表圧縮では、ダイレクト・パス操作でないと、ブロック内のしきい値になると何度も圧縮される場合がありましたが、Oracle12cR2から配列挿入でダイレクト・パス操作のように、一度の圧縮で行うことが可能になっています(OLTP表圧縮は、第28回の「(1)基本表圧縮とOLTP表圧縮の違い」を参照してください)。

(3)Columnar Flash Caching
Exadata Storage 12.1.2.1(Oracle12.1.0.2)からのColumnar Flash Cachingにより、Smart Scanを行うと、CELLサーバーのFlash上で、HCCからPure Columnar Format(純粋な列形式)に同じサイズで自動的に変換を行います(Smart Scanでなければ、HCCでロードされるので、デュアル・フォーマットで格納することができます)。HCCは、効果的な行アクセスを維持するようになっているため、列アクセスに対して最適とは言えませんでした(必要な列だけのアクセスはできませんでした)。HCCを「純粋な列形式」に変換することで、指定された列だけのアクセス(列単位のI/O)が可能になるので、FlashのI/OとCELLサーバーのCPUを低減することができます。Exadata Storage 12.2.1.1からは、暗号化表領域でも可能になりました。

(4)In-Memory Columnar Caching
Exadata Storage 12.2.1.1(Oracle12.2.0.1)からのIn-Memory Columnar Cachingにより、CELLサーバーのFlashに、第53回のIM列型形式で格納できるようになりました。ただし、Oracle Database In-Memory Optionが必要です。使用するには、IM列ストアを有効にして(初期化パラメータINMEMORY_SIZEを100Mバイト以上に設定して)、HCC表に対して以下のように圧縮タイプだけの指定を行います(デフォルトはCAPACITY LOWです)。

CREATE / ALTER TABLE … [NO] CELLMEMORY [<インメモリ圧縮タイプ>] 

この表にSmart Scanを行うと、自動的にポピュレートを行い使用されます(「純粋な列形式」でFlashに格納した後に、バックグランドでIM列型形式に変換します)。つまり、HCC表をSmart Scanすると、Flash上でIM列ストアが有効だとIM列型形式、無効だと「純粋な列形式」になります。
これによりSmart Scanで、第53回のSIMDベクター処理、ベクターGroup By処理、そして通常のストレージ索引より効果的なインメモリ・ストレージ索引なども使用できるようになります。Exadata Storage 18.1.0からは、HCC表以外に非圧縮表やOLTP圧縮表も可能になりました(これは、Oracle Autonomous Data Warehouse Cloudでも使用されています)。

3. Exadataのパフォーマンス統計
最後に、Exadata専用のパフォーマンス統計について説明します。
以下が代表的なExadataのパフォーマンス統計になります(V$SQLの統計も載せておきます)。Exadataのパフォーマンス統計もAWRやカレント・セッション統計(V$MYSTATなど)から確認できます。

統計名 意味 V$SQLの統計
cell physical IO interconnect bytes DBサーバーとCellの間でやりとりされたIOサイズで、Smart Scan以外も含む(解凍後のサイズ) IO_INTERCONNECT_BYTES
cell physical IO interconnect bytes returned by smart scan Smart ScanによりCellから返されたIOサイズ(解凍後のサイズ) IO_CELL_OFFLOAD_RETURNED_BYTES
cell physical IO bytes eligible for predicate offload Smart Scanの対象となったIOサイズ(physical read total bytesとの違いはSmart Scan以外が含まない) IO_CELL_OFFLOAD_ELIGIBLE_BYTES
cell IO uncompressed bytes cellで処理された非圧縮のデータ・サイズ IO_CELL_UNCOMPRESSED_BYTES
cell physical IO bytes saved by storage index Storage indexによるIO削減サイズ OPTIMIZED_PHY_READ_REQUESTS
cell flash cache read hits Smart Flash Cacheに対するリクエスト回数
physical read total IO requests 物理読込みI/Oリクエスト回数 PHYSICAL_READ_REQUESTS
physical read total Bytes 物理読込みサイズ(バイト) PHYSICAL_READ_BYTES

それぞれのパフォーマンス統計の関連を図にすると以下のようになります(少し分かりづらいのが、圧縮データと解凍データが混在しているためです)。

img-1

このパフォーマンス統計を使用して、Exadataのいろいろな効果を求めることができます。代表的なものを以下に載せておきます。

効果 計算式
SmartScan効果(I/O削減率) (1 - 'cell physical IO interconnect bytes returned by smart scan' / ('cell IO uncompressed bytes' + 'cell physical IO bytes saved by storage index')) * 100
SmartScan効果(SQLごと) (1 - IO_CELL_OFFLOAD_RETURNED_BYTES / IO_CELL_OFFLOAD_ELIGIBLE_BYTES) * 100
SmartScanのI/O比率 'cell physical IO bytes eligible for predicate offload' / 'physical read total bytes' * 100
ストレージ索引のI/O削減率 'cell physical IO bytes saved by storage index' / 'cell physical IO bytes eligible for predicate offload' * 100
Smart Flashキャッシュ・ヒット率 'cell flash cache read hits' / 'physical read total IO requests' * 100
HCCの圧縮率 (1 - ('cell physical IO bytes eligible for predicate offload' - 'cell physical IO bytes saved by storage index') / 'cell IO uncompressed bytes') * 100

オフロード効果(SQLごと)は、V$SQLに「cell physical IO bytes saved by storage index」がないので、IO_CELL_OFFLOAD_ELIGIBLE_BYTESを使用しています(この値は圧縮データのサイズなので、Smart Scanの解凍後サイズと比較することになり多少効果が低くなります)。

4. おわりに
今回はOracle Exadata Database Machineについて説明しましたが、少しは参考になりましたでしょうか。これからも頑張りますのでよろしくお願いします。
それでは、次回まで、ごきげんよう。

津島博士のパフォーマンス講座 indexページ▶▶