Oracle Exadataのスマート・スキャン機能とは?仕組みと検証例を徹底解説

本記事では、Oracle® Exadata®の「スマート・スキャン(Smart Scan)」機能について詳しく掘り下げます。Exadata環境でSQL処理がどのように従来と異なるのかを解説するとともに、実際の使用例もご紹介します。

はじめに

Oracleは2008年、エンジニアード・システム(Engineered System)ファミリーの先駆けとしてExadataを設計・発表しました。ユーザー自身がOSやデータベースの構成、インストール、チューニング、運用管理を行う従来型のデータベース・システムとは異なり、エンジニアード・システムでは、OS・データベース・メモリ・ストレージといった必要なコンポーネントすべてが、ソリューション・プロバイダー(ここではOracle)によって事前にインストール、構成、チューニング、最適化された状態で提供されます。

Exadataマシンは複数のコンポーネントで構成されています。主要なコンポーネントは以下のとおりです。

• データベース・サーバー:データベース・ソフトウェア、自動ストレージ管理(ASM)、またはOracle Grid Infrastructureを実行するエンタープライズクラスのサーバーです。

• ストレージ・サーバー(セル):Exadataストレージ・サーバー・ソフトウェアを実行するサーバーです。データベース・サーバーから送られるI/O要求を管理し、ユーザーへのデータ返却要求を処理します。

• InfiniBandネットワーク:Exadataの内部ネットワークはInfiniBand上に構築されています。InfiniBandはもともと高性能コンピューティング(HPC)環境向けに設計された技術です。

さらに、Exadataには「Exadata Storage Software(ESS)」と呼ばれるソフトウェアが搭載されており、これがデータベースのパフォーマンス向上に大きく貢献します。ESSは各ストレージ・セルにインストールされたストレージ管理サーバーであり、ストレージ・サーバー群を管理するとともに、ストレージ関連の要求についてデータベース・サーバーと通信を行います。

ESSの主な機能

ESSが提供する主な機能は以下のとおりです。

• フラッシュ・キャッシュ(Flash Cache):セル・サーバー上に実装された高性能キャッシュで、最近アクセスされたオブジェクトを保持します。

• フラッシュ・ログ(Flash Log):REDOログの書き込みに対して、高パフォーマンスかつ低レイテンシで信頼性の高い一時格納領域を提供します。

• EHCC(Exadata Hybrid Columnar Compression):最高水準のデータ圧縮を可能にする機能です。EHCCは圧縮ユニット(compression unit)と呼ばれる行の集合単位でデータを整理し、その中でデータを列方向に配置してから圧縮します。

• ストレージ索引(Storage Index):ストレージ・サーバー上のインメモリ構造体で、ディスクからのデータ読み取り時間を削減することを目的としています。

• セル・オフロード(Cell Offloading):従来型のストレージ設計と異なり、Exadataのストレージ・セルは一部のワークロードをストレージ側で内部的に処理するよう設計されており、コンピュート・ノード(データベース・ノード)全体の負荷を軽減します。この仕組みをセル・オフロードと呼びます。

• スマート・スキャン(Smart Scan):SQL処理の大部分をデータベース層ではなくストレージ層で実行できるようにし、問合せパフォーマンスを劇的に改善する機能です。データベース層へ送信されるデータ量を削減できるため、データベース・ノードのCPU使用率も下がります。

SQL処理の流れ

従来、SQL処理はデータベース・サーバー上でのみ行われていました。一方、ExadataではSQL処理が分割され、ストレージ層でも実行されます。

従来のSQL処理

従来のSQL処理は、以下のステップで構成されます(下図参照)。

1. クライアントが問合せを発行します。
2. この操作によりフル表スキャンが発生します。
3. データベースは、スキャン対象の表が含まれるファイルおよび対応するエクステントに要求をマッピングします。
4. フルスキャンと同様に、すべてのブロックを読み込むためのI/O操作が発行されます。
5. 表の対象ブロックがすべてメモリに読み込まれます。
6. プロセスが各ブロックを走査し、述語(条件)を満たす行を検索します。
7. 最後に、要求された行がクライアントに返却されます。

大きな表の場合、その表の全ブロックが読み取られ、ストレージ・ネットワーク経由で転送され、メモリにコピーされることになります。つまり、要求されたSQL操作を完了するために、不要な行まで大量にメモリへ読み込むことになります。この膨大なデータ転送は帯域幅を消費し、レスポンス・タイムに悪影響を与え、データベース層に不要な負担を強いる結果となります。

ExadataにおけるSQL処理

Exadataストレージを使用した場合、データベース・ロジックが組み込まれたExadataストレージ・ソフトウェアによって、SQL処理ははるかに効率的に実行されます。ExadataでのSQL処理は以下のステップで構成されます(下図参照)。

1. クライアントが問合せを発行します。
2. データベース・サーバーは、問合せ条件を含むIntelligent Database(iDB)メッセージを生成し、ラック内のすべてのストレージ・サーバーへ送信します。
3. ESSのcellsrvコンポーネントがデータ・ブロックを走査し、要求条件を満たす一致行および該当列を特定します。
4. 各ストレージ・サーバーが問合せ条件を並列に実行し、インターコネクト経由で関連する行のみ(正味の結果)をデータベース・サーバーへ返します。
5. データベース・サーバーが結果を統合し、行をクライアントへ返却します。

スマート・スキャンの利用要件

スマート・スキャンを利用するには、以下の要件を満たす必要があります。

• スマート・スキャンはフル表スキャンまたはフル索引スキャンに対してのみ有効です。
• 問合せはダイレクト・パス読取り(direct-path read)を実行する必要があります。
• データベース初期化パラメータCELL_OFFLOAD_PROCESSINGをTRUEに設定する必要があります。
• セグメントは、完全にExadataセル上に格納されたディスク・グループに保存する必要があります。
• セグメント・データを格納するASMディスク・グループには、次の属性設定が必要です。
  – compatible.rdbms = 11.2.0.0.0(以降)
  – compatible.asm = 11.2.0.0.0(以降)
  – cell.smart_scan_capable = TRUE

スマート・スキャンの検証例

以下の手順を、スマート・スキャンを無効化した場合と有効な場合の両方で実行し、統計情報への影響を測定してみましょう。

手順1:データベースへの接続

次のコマンドでSQL*Plusを使用してデータベースに接続します。

[oracle@nd01db01 ~]$ sqlplus nd/nd
SQL*Plus: Release 11.2.0.3.0 Production...

手順2:統計情報の確認

次の問合せを実行し、統計情報がゼロ(またはそれに近い値)であることを確認します。

SQL> select a.name, b.value/1024/1024 MB from v$sysstat a, v$mystat b
where a.statistic# = b.statistic# and (a.name in ('physical read total bytes',
'physical write total bytes', 'cell IO uncompressed bytes')
or a.name like 'cell phy%');

NAME	                                                           MB
--------------------------------------------------------------- ---
physical read total bytes	                                       0
physical write total bytes	                                    0
cell physical IO interconnect bytes	                           0
cell physical IO bytes saved during optimized file creation	   0
cell physical IO bytes saved during optimized RMAN file restore	0
cell physical IO bytes eligible for predicate offload	         0
cell physical IO bytes saved by storage index	                  0
cell physical IO bytes sent directly to DB node to balance CPU	0
cell physical IO interconnect bytes returned by smart scan	      0
cell IO uncompressed bytes	                                    0

10 rows selected.

手順3:スマート・スキャンを無効化したSELECT文の実行

スマート・スキャンを無効化するオプティマイザ・ヒント付きで、次のSELECT文を実行します。

SQL> select /*+ OPT_PARAM('cell_offload_processing' 'false') */ count(*)
from sales where time_id between '01-JUN-2017' and '30-OCT-2017'
and amount_sold = 1;

COUNT(*)
----------
134055

手順4:統計情報の再確認

再度、統計情報を確認します。手順3の問合せで処理された全データ(physical read total bytes)が、ストレージ・ネットワーク経由でデータベース・サーバーへ返されている(cell physical IO interconnect bytes)点に注目してください。

SQL> select a.name, b.value/1024/1024 MB from v$sysstat a, v$mystat b
where a.statistic# = b.statistic# and (a.name in ('physical read total bytes',
'physical write total bytes', 'cell IO uncompressed bytes')
or a.name like 'cell phy%');

NAME	                                                           MB
--------------------------------------------------------------- -----------
physical read total bytes	                                       759.429688
physical write total bytes	                                    0
cell physical IO interconnect bytes	                           759.429688
cell physical IO bytes saved during optimized file creation	   0
cell physical IO bytes saved during optimized RMAN file restore	0
cell physical IO bytes eligible for predicate offload	         0
cell physical IO bytes saved by storage index	                  0
cell physical IO bytes sent directly to DB node to balance CPU	0
cell physical IO interconnect bytes returned by smart scan	      0
cell IO uncompressed bytes	                                    0

10 rows selected.

手順5:統計情報のリセット

次のコマンドでセッションをデータベースに再接続し、セッション・レベルの統計情報をリセットします。

[oracle@nd01db01 ~]$ sqlplus nd/nd
SQL*Plus: Release 11.2.0.3.0 Production...

手順6:統計情報の再確認

次の問合せを実行し、統計情報がゼロ(またはそれに近い値)に戻っていることを確認します。

SQL> select a.name, b.value/1024/1024 MB from v$sysstat a, v$mystat b
where a.statistic# = b.statistic# and (a.name in ('physical read total bytes',
'physical write total bytes', 'cell IO uncompressed bytes')
or a.name like 'cell phy%');

NAME	                                                           MB
--------------------------------------------------------------- ---
physical read total bytes	                                       0
physical write total bytes	                                    0
cell physical IO interconnect bytes	                           0
cell physical IO bytes saved during optimized file creation	   0
cell physical IO bytes saved during optimized RMAN file restore	0
cell physical IO bytes eligible for predicate offload	         0
cell physical IO bytes saved by storage index	                  0
cell physical IO bytes sent directly to DB node to balance CPU	0
cell physical IO interconnect bytes returned by smart scan	      0
cell IO uncompressed bytes	                                    0

10 rows selected.

手順7:スマート・スキャンを有効にしたSELECT文の実行

今度は、スマート・スキャンを無効化するオプティマイザ・ヒントを付けずに、同じSELECT文を実行します。

SQL> select count(*) from sales where time_id between '01-JUN-2017'
and '30-OCT-2017'and amount_sold = 1;

COUNT(*)
-------
134055

手順8:統計情報の確認

統計情報を確認します。問合せ自体は手順4と同様に約759MBのI/O(physical read total bytes)を処理しているものの、今回はわずか1.7MBしかDBサーバーへ返されていない(cell physical IO interconnect bytes)点に注目してください。これこそがスマート・スキャンが動作した結果です。このケースでは、「predicate offloadの対象となったcell physical IO bytes」が「physical read total bytes」と等しく、「smart scanによって返されたcell physical IO interconnect bytes」が「cell physical IO interconnect bytes」と等しいため、この問合せに関連するI/Oに対してスマート・スキャンが作用したことが分かります。

SQL> select a.name, b.value/1024/1024 mb from v$sysstat a, v$mystat b where a.statistic# = b.statistic# and (a.name in ('physical read total bytes', 'physical write total bytes','cell IO uncompressed bytes') or a.name like 'cell phy%');

NAME                                                             MB
----------------------------------------------------------------	----------
physical read total bytes	                                       759.429688
physical write total bytes	                                    0
cell physical IO interconnect bytes	                           1.71562805
cell physical IO bytes saved during optimized file creation	   0
cell physical IO bytes saved during optimized RMAN file restore	0
cell physical IO bytes eligible for predicate offload	         759.429688
cell physical IO bytes saved by storage index	                  0
cell physical IO bytes sent directly to DB node to balance CPU	0
cell physical IO interconnect bytes returned by smart scan	      1.71562805
cell IO uncompressed bytes	                                    759.429688

10 rows selected.

まとめ

Exadataのスマート・スキャン機能は、SQL処理をデータベース層ではなくストレージ層で実行することで、問合せパフォーマンスを向上させます。また、データベース層へ送信されるデータ量を削減できるため、データベース・ノードのCPU使用率の低減にもつながります。

コメントやご質問がある場合は、フィードバック・タブをご利用ください。

当社のデータベース・サービスおよびRackspaceアプリケーション・サービスについて、ぜひ詳しくご覧ください。