Oracle Database 11g Release 2 In-Memory Parallel … Database 11g Release 2 In-Memory Parallel Queryによる NEC Express5800/スケーラブルHAサーバ上でのData Warehouseシステム全体の性能向上

オラクル・ホワイトペーパー

2010年 3月

Oracle Database 11g Release 2 In-Memory Parallel Queryによる NEC Express5800/スケーラブルHAサーバ上での Data Warehouseシステム全体の性能向上

Oracle Database 11g Release 2 In-Memory Parallel Queryによる NEC Express5800/スケーラブルHAサーバ上でのData Warehouseシステム全体の性能向上

はじめに

日本電気株式会社（以降、NEC）は2006年7月に、次世代IT基盤を実現するためのITプラットフォ

ームビジョン「REAL IT PLATFORM」を発表しその指針に沿って「柔軟」「安心」かつ「快適」

なIT基盤を実現する製品群を提供してきました。

2009年10月には従来のビジョンを元に、今後クラウド・コンピューティングによって変化する企業

のビジネスニーズに対して、的確に対応するため「REAL IT PLATFORM Generation2」としてさら

に進化させました。「REAL IT PLATFORM Generation2」においては、「高効率インフラストラク

チャ」「サービス実行基盤」「システムサービス管理」の3領域の製品およびサービスを強化して

います。

一方、日本オラクル株式会社（以降、日本オラクル）は、Oracle Database 10gを発表した数年前よ

りグリッドコンピューティングを実現する「Oracle GRID」技術を提供しています。

さらに、2006年11月にはグリッドをベースとした次世代のビジネス・ソリューション構築を目的と

して各協賛ベンダーとの共同の検証施設「Oracle GRID Center」を設立しました。

NECと日本オラクルは20年に渡る協業関係を基盤とし、次世代ITインフラ基盤の実現に向けた開発

レベルでの戦略協業（STA：Strategic Technology Alliance）を推進しており、NECは「REAL IT

PLATFORM Generation2」の具現化を強化するために「Oracle GRID Center」に参画し、共同検証を

実施しております。

Oracle GRID Centerでは2009年11月のOracle Database 11g Release 2 のリリースに向けて、協賛パー

トナーとともに新機能の事前検証プログラムを実施し、事前検証による検証結果を製品へフィード

バックすることで製品を改善、さらに検証を通してリリース前段階から新機能について熟知するこ

とでリリースと同時に有効な使用法を提案可能になる活動を実施しました。本文書は、NECとの活

動での成果物になります。


概要 ........................................................................................................................3

Oracle製品機能紹介 ...............................................................................................3

In-Memory Parallel Query ..................................................................................3

Oracle Partitioning..............................................................................................5

Oracle Databaseの表圧縮機能...........................................................................7

プラットフォーム紹介 ...........................................................................................8

Express5800/スケーラブルHAサーバ ................................................................8

検証環境 .................................................................................................................9

検証モデル ...........................................................................................................10

検証1: 従来のPQとIn-Memory PQの比較............................................................12

検証2: In-Memory PQが適用可能な検索範囲の拡大 ............................................17

検証2-1: NEC Express 5800/A1160のボックス追加による適用範囲の拡大....17

検証2-2:Oracle Databaseの表圧縮機能による適用範囲の拡大 .......................18

検証3: In-Memory Parallel QueryによるDWHシステム全体の高速化..................20

まとめ ..................................................................................................................24


Copyright © 2010. Oracle and NEC All Rights Reserved 3

概要

企業を取り巻く環境の変化はこれまでにないほど急速であり、意思決定者はより迅速な経営判断や

業務改善が求められています。その迅速な意思決定にあたって、将来の予測分析や過去データの参

照に使用するのがデータ・ウェアハウス（Data Warehouse：以降、DWH）であり、データ提供に

高い性能が求められています。従来から、Oracle Database では SQL 実行を並列処理することで、

ディスク I/O 性能と CPU リソースを大限活用した高速処理を実現してきました。

しかし近年では、グローバル化や事業の複雑化などにより企業が抱えるデータ量が増加し、ストレ

ージに対して求められるディスク I/O 性能が増してきています。一方、ディスクドライブの大容量

化により容量を基準にしてディスク本数を設計すると、性能の面ではディスク本数が不足する傾向

があります。その結果、ストレージのディスク I/O 性能がボトルネックになり CPU や物理メモリ

のリソースが使いきれず、DWH システム全体の性能が制限されているケースが増えてきています。

この課題を解決するために、Oracle Database 11g Release2（以降、Oracle Database 11g R2）では、デ

ータを物理メモリ上にキャッシュし並列処理する In-Memory Parallel Query（以降、In-Memory PQ）が実装されました。

本文書では、大容量メモリを持つサーバ NEC Express5800/スケーラブル HA サーバ上で In-Memory PQ を採用することで DWH システムのハードウェアリソースが効率的に使用されるようになり、

システム全体の性能向上を実現するソリューションを紹介します。

Oracle製品機能紹介

In-Memory Parallel Query

大量データを扱う従来の Parallel Query（以降、PQ）では、データベース・バッファ・キャッシュ

（以降、バッファ・キャッシュ）を経由しないでディスクから直接読み込む Direct Path Read でデ

ータにアクセスしていました。もちろん、ディスクから読み込むよりもメモリ（バッファ・キャッ

シュ）から読み込む方が高速ですが、一昔前は大容量の物理メモリは非常に高価でありサーバに搭

載可能な物理メモリも少なかったことから、大量データをすべてキャッシュさせる為には、バッフ

ァ・キャッシュのサイズが不十分な環境がほとんどでした。もしそのような環境で、通常の数件の

小さなデータを扱うクエリと同様にバッファ・キャッシュ経由でデータへアクセスした場合、ディ

スクから読み込んでバッファ・キャッシュにキャッシュしても、次々とディスクから読み込まれる

別のデータによって追い出されるため、キャッシュされたデータが再利用されることが期待できま

せん。さらに、再利用できないデータのためのキャッシュ管理のオーバーヘッドがクエリのレスポ

ンスタイムを劣化させます。このような理由から、従来より Oracle Database における大量データ

を扱う PQ では、Direct Path Read でデータにアクセスする適化された方式を採用していました。

しかしながら、近年では大容量な物理メモリを搭載したサーバが普及してきました。本検証で使用

した NEC Express5800/スケーラブル HA サーバでは、大構成で 1024GB（256GB×4 ボックス）

の物理メモリを搭載することができます。このように、大量データを扱う PQ でもバッファ・キャ

ッシュ上のデータを利用する In-Memory PQ を適用し易い環境が整ってきました。



図 1 Direct Path ReadとIn-Memory PQ

In-Memory PQ はデータ（表や索引等のデータベース・セグメント）をバッファ・キャッシュ上に

キャッシュして PQ を実施する機能であり、検索対象のデータがバッファ・キャッシュ上にある状

態ではストレージ性能の限界よりもはるかに高速な処理を実現します。さらに、物理メモリ以上の

データを扱う場合を想定し、バッファ・キャッシュの約 80%よりも大きなデータの際は、SQL の

実行計画作成時に Direct Path Read が実行されるよう自動判別される仕組みが実装されています

（図 2）。



図 2 In-Memory PQ設定時の検索対象のデータサイズによる動作形式の判別フロー

In-Memory PQ の設定は、初期化パラメータ PARALLEL_DEGREE_POLICY=AUTO を設定すること

でアプリケーションの変更無しに適用することができます。デフォルトの設定である MANUAL の

場合は従来と同様 Direct Path Read で動作します。

また、In-Memory PQ は次に説明する Oracle Partitioning や Oracle Database の表圧縮機能との併用が

有効です。この点につきまして以下の各機能説明で紹介します。

Oracle Partitioning

Oracle Partitioning は、大きな表や索引をデータベース内部で複数の領域（パーティション）に分割

して管理する機能です。ユーザーからは、通常通り 1 つの表としてアクセス可能で、アプリケーシ

ョンの変更なしに適用することができます。

分割手法として、レンジ（キー値の範囲による分割）、ハッシュ（キー値をハッシュ関数で分割）、

リスト（キー値による分割）、およびそれらを 2 つ組み合わせたコンポジット・パーティションを

選択可能です。次の表 1 に、組み合わせ可能なコンポジット・パーティションとそれが可能にな

った Oracle Database のバージョンを示します。



表 1 選択可能なコンポジット・パーティション

サブ

レンジリストハッシュ

レンジ 11gR1 9iR2 8i メインリスト 11gR1 11gR1 11gR1

SQL 文による検索や DML 処理の実行、管理操作などをパーティション単位で実施することができ

ることで、SQL 処理の性能向上、管理性の向上、および可用性が向上するメリットがあります。

本文書では、性能面でのメリットのうち、特に DWH 系クエリで効果の高いパーティション・プル

ーニングについて解説します。

パーティション・プルーニングとは、必要なデータが存在するパーティションにのみ自動的にアク

セスを絞って検索する機能です。例えば、Sales 表から 2009 年 10 月のデータを検索する場合、

where 句に’200910’を指定して SELECT 文を実行します。非パーティション表の場合は、表全体を

検索する全件検索が実施されますが、パーティション表の場合、2009 年 10 月のパーティションの

みの検索となり、データアクセス範囲が絞られるため高速な処理が可能になります（図 3）。

図 3 パーティション・プルーニング



また、パーティション表は In-Memory PQ との併用が有効です。クエリで処理するデータが、必要

なパーティションのみに絞られることでバッファ・キャッシュ上にキャッシュされやすくなります。

大規模な DWH に対する PQ の場合、表単位ではデータのサイズが大きすぎてキャッシュできない

ような PQ も必要なパーティションのみに絞ることで In-Memory PQ が有効になる可能性がありま

す（図 4）。

図 4 パーティションとIn-Memory PQの併用

Oracle Database の表圧縮機能

Oracle Database の表圧縮機能とは、Oracle データベース・ブロック（以降、ブロック）内のデータ

を重複排除し、1 ブロックあたりに格納可能な行数を増やすことで表データのサイズを圧縮する機

能です。本機能を活用することで、同じ行数を取り出すために必要なデータ量が減少するため、特

えに大量データを扱う DWH 系のクエリにおいては、ストレージのディスク I/O 時間が削減され、

レスポンスタイムの改善が期待できます。さらにバッファ・キャッシュ上には、圧縮された状態で

キャッシュされるため、In-Memory PQ が適用可能な検索範囲が拡大されることを期待できます

（図 5）。

図 5 圧縮によるIn-Memory PQが適用可能なデータサイズの範囲の拡大



プラットフォーム紹介

Express5800/スケーラブル HA サーバ

NEC のスケーラブルサーバである「Express5800/スケーラブル HA サーバ」は、メインフレームや

スーパーコンピュータで培った NEC の技術を投入した高性能サーバです。Express5800/スケーラブ

ル HA サーバは、 4U のボックス（筐体）に 4 プロセッサを搭載したエントリモデル

「 Express5800/A1040 」と、大 16 プロセッサまで拡張可能なスケーラブルモデル

「Express5800/A1160」の 2 製品をラインナップしております。1 プロセッサに 6 コア搭載可能なイ

ンテル® Xeon®プロセッサ搭載しており、使用するプロセッサやコア数を大で 16 プロセッサ、

96 コアまで増やすことが可能です。

図 6 Express5800/スケーラブルHAサーバの拡張

さらに、「EXPRESSSCOPE®エンジン SP」とマネージメントソフトウェア「ESMPRO」により、

システムが停止している状態であっても、リモート管理サーバからの遠隔操作や状態確認が可能と

なります。また、サーバ監視機能や通報機能はもちろん、WEB のリモートコンソールから設定情

報、ログ情報の参照ができ、信頼ある運用環境を実現します。

図 7 リモートからの遠隔操作や状態確認



検証環境

本検証で使用したシステム構成は次の通りです。

Express5800/A1160 上に Oracle Database 11g Release 2 をインストールし、4Gbps の Fibre Channel（以降、FC）4 本で接続された iStorage D3 上にデータベースを配置しました。本検証では総計約

1TB のデータベースを使用し、スキーマには実際の販売管理 DWH を想定したものを用いました。

データベース・クライアント：Express5800/R120a-2

CPU インテル®Xeon® プロセッサ X5570（2.93GHz）[コア数：4]×2

Memory 26GB

OS Red Hat Enterprise Linux 5 Update3 x86-64

データベース・サーバ：Express5800/A1160

1ボックス:インテル® Xeon® プロセッサ E7440（2.4GHz）

[コア数：4]× 4 CPU

2ボックス:インテル® Xeon® プロセッサ E7440（2.4GHz）

[コア数：4]× 8

ECC付きDDR2-667 FB-DIMM

1ボックス:64GB（8GB×8） Memory

2ボックス:128GB（8GB×16）

OS Red Hat Enterprise Linux 5 Update3 EM64T

Oracle Database Oracle Database 11g Enterprise Edition Release 11.2.0.1(Single Instance 構成 ASM使用)



ストレージ：iStorage D3

Hard Disk Drive SAS 300GB（15000rpm）× 36

(本体+ディスクエンクロージャ×2の総数)

Cache Memory 4GB

Host interface Fibre Channel 4Gbps× 4

検証モデル

一般的に、DWH ユーザーは一般ユーザーと経営層ユーザーの 2 つに分けることができます。本文

書では両タイプのユーザーを実際の DWH システムを元に次の仮説でモデル化しました。

一般ユーザーは、営業社員など日々直面する問題を解決するために主に直近のデータを使用し、経

営層ユーザーは、中長期的な計画の策定や検証のために数年間といった長期間のデータを使用する

傾向があります。

それぞれのユーザーが発行するクエリには次の傾向があります。一般ユーザーの発行するクエリは、

多数のユーザーによって実行され、発行頻度が高い傾向があります。一方、経営層ユーザーの発行

するクエリは、極めて少数のユーザーで実行され、発行頻度が低い傾向があります（図 8、表 2）。

図 8 一般ユーザーと経営層ユーザーのユーザー数と検索範囲の違い

表 2 一般ユーザーと経営層ユーザーの発行するクエリの違い

検索範囲ユーザー数

一般ユーザー短期（直近）多い

経営層ユーザー長期少ない



DWH システムでは、両ユーザーのクエリが同時に処理されている状態であり、従来の物理メモリ

の少ないサーバでは、大容量データをキャッシュできないため両ユーザーの PQ とも Direct Path Read で実行されます。この場合、データの供給元がストレージに集中するため、実行中の PQ の

性能がストレージの I/O 帯域の限界で頭打ちになる傾向があります。さらに、直近データにアクセ

スする多数の一般ユーザーは、同じ検索範囲にアクセスするにも関わらず、毎回ディスクから読み

込むためストレージの I/O 帯域を圧迫しやすくなっています（図 9）。

図 9 従来のPQでのハードウェアリソースの使い方

この課題を、大容量メモリを搭載したサーバ（NEC Expres5800/スケーラブル HA サーバ）と

Oracle Database 11g R2 の新機能 In-Memory PQ を組み合わせることでいかに解決できるかを検証し

ます。



検証1: 従来のPQとIn-Memory PQの比較

検証モデルで述べたように、実際の DWH システムでは、複数のユーザーから異なる種類のクエリ

が発行されていますが、ここでは、1 ユーザーが同一クエリを用いた場合の従来の PQ と In-Memory PQ の単純な比較をします。従来の PQ は In-Memory PQ の設定無しとすることで実施しま

す。また、In-Memory PQ 設定有りのとき、検索対象のデータサイズが大きい場合、Direct Path Read が実行されるよう自動判別される仕組みについても確認します。

この検証で実施した検証方法は下記の通りです。

1. 月単位でレンジ・パーティション化されたパーティション表を準備。

2. In-Memory PQの設定有り無しにおいて、同じ検索期間が指定された同一クエリの性能を測定。

3. クエリの指定する月数を増やすことで、検索で使用されるパーティション数を増やし、検索対

象のデータサイズを拡張。

4. 手順2へ戻る。

図 10 検証方法

この検証で使用した検証環境は以下の通りです。

データベース・サーバ Express 5800/A1160

1ボックス(物理メモリ：64GB , 総CPUコア数：16コア)

PGA+SGA 50GB

バッファ・キャッシュ 24.5GB(約80%は19.6GB)

使用したクエリの内容指定した期間のデータを全件検索し合計を集計するクエリ

テーブル月単位でパーティション化されたテーブル（1パーティション辺り

約2.5GB）



検索対象のデータサイズを拡張させつつ、In-Memory PQ 設定有り無しのレスポンスタイムを比較

した結果を次の図 11 に示します。

図 11 の相対レスポンスタイムには、検索範囲のデータサイズが約 15GB の In-Memory PQ の設定

無し（Direct Path Read）のレスポンスタイムを基準値 100 とした相対値を使用しています。これ以

降、検証 1 および 2 のレスポンスタイムの表示にはこの相対レスポンスタイムを使用します。

図 11 In-Memory PQ設定有り無しにおける検索範囲のデータサイズとレスポンスタイム比較

In-Memory PQ 設定有りのグラフより、検索範囲のデータサイズがバッファ・キャッシュの約 80%に収まる場合、In-Memory PQ を実施し、それを超えると Direct Path Read で動作する様子が確認で

きます。

次に、従来の PQ である Direct Path Read からキャッシュから読み込む In-Memory PQ になることに

よる性能向上とリソースの使用傾向の違いを確認するため、検索対象のデータサイズがバッファ・

キャッシュの 80%に収まるサイズである約 15GB のデータに注目して調査します。この場合、In-Memory PQ 設定無しでは Direct Path Read、設定有りでは In-Memory PQ として動作します。

検索対象のデータサイズが約 15GB のときの In-Memory PQ 設定有り無しにおける相対レスポンス

タイムの比較を次の図 12 に示します。



図 12 Direct Path ReadとIn-Memory PQのレスポンスタイム比較

この検証では、In-Memory PQ は Direct Path Read に比べて約 5 倍高速であることが確認できました。

ただし、In-Memory PQ はバッファ・キャッシュ上に検索対象のデータがキャッシュされているこ

とが前提となるため、この性能はバッファ・キャッシュ上に検索対象データをキャッシュさせた後

の値となります。検索対象データがキャッシュされていない場合は、キャッシュするオーバーヘッ

ドが発生するため、Direct Path Read に比べて処理時間が長くなります。

次に、Direct Path Read と In-Memory PQ でのディスク I/O の時系列グラフを次の図 13 に示します。

ここで使用した相対 Disk I/O 速度（Read）は、事前に調査したストレージの読み込みのディスク

I/O 性能の大値を基準値 100 とした相対値を使用しています。

図 13 Direct Path ReadとIn-Memory PQのストレージリソース使用傾向比較

Direct Path Read の場合、ストレージ性能の上限値付近までストレージを使用しています。一方、

In-Memory PQ では、ほぼディスク I/O がなくなっていることが確認できます。

また、Direct Path Read と In-Memory PQ での CPU 使用率の時系列グラフの比較を次の図 14に示し

ます。



図 14 Direct Path ReadとIn-Memory PQのCPU使用率比較

Direct Path Read では、CPU 使用率(usr+sys)が高々10%前後になっています。これは、CPU のデー

タ処理速度に対してストレージのデータ供給速度が不足しており、CPU リソースを使いきれてい

ない状態です。一方、In-Memory PQ では、CPU 使用率(usr+sys)が 100%付近まで到達しており、

CPU リソースを限界まで活用しています。

以上より、同じクエリに対して、従来の Direct Path Read と In-Memory PQ の性能を比較した結果、

In-Memory PQ の方が高速であり、かつストレージリソースを消費せず CPU リソースを活用できる

ことが確認できました。

次に、処理対象となるデータサイズがバッファ・キャッシュの約 80%に収まらない場合の検証結

果を示します。この場合、In-Memory PQ 設定有りの場合も Direct Path Read で動作する PQ になり

ます。以下に、検索対象のデータサイズが 20GB（バッファ・キャッシュの 80%=19.6GB）のとき

の In-Memory PQ 設定有り無しのレスポンスタイムの比較を示します。

図 15 バッファ・キャッシュの約80%を超えたときのIn-Memory PQ有り無しのレスポンスタイム比較

In-Memory PQ の設定有りの場合でも Direct Path Read が実行されるため、どちらも同程度のレスポ

ンスタイムであることが確認できます。



以下に In-Memory PQ 設定有り無しにおける Top 5 イベントを示します。

どちらも 90%以上の時間を direct path read のイベントに使用しており、In-Memory PQ 設定有りの

場合も確かに Direct Path Read が実施されていることが確認できます。

以上より、In-Memory PQ 設定有りのとき、検索対象のデータサイズがバッファ・キャッシュの約

80%に収まっている場合、バッファ・キャッシュを利用する高速な PQ を実施し、約 80%よりも大

きくなる場合は Direct Path Read が実施されるように自動判別されることが確認できました。この

ことから、実際の DWH システムでは、直近のクエリを実施する一般ユーザーは In-Memory PQ に

よって高速化され、長期のクエリを実施する経営層ユーザーは Direct Path Read で実行される可能

性が高くなると考えられます。



検証2: In-Memory PQが適用可能な検索範囲の拡大

検証１の結果から推測できるように、In-Memory PQ で実行されているクエリであっても、事業の

複雑化などにより DWH のデータ量がさらに増大するとバッファ・キャッシュの約 80%を超えるよ

うになり、In-Memory PQ が適用されなくなる可能性があります。

このような課題の解決策として、物理メモリを追加してバッファ・キャッシュのサイズを拡張する、

または検索対象データのサイズを縮小することで、In- Memory PQ の適用可能な範囲を拡張する方

法が考えられます。

検証 2-1 では NEC Express 5800/A1160 のボックス追加機能を活用したバッファ・キャッシュのサイ

ズ拡張を、検証 2-2 では Oracle Database の表圧縮機能を活用した検索対象データのサイズを縮小す

る方法を紹介します。

検証 2-1: NEC Express 5800/A1160 のボックス追加による適用範囲の拡大

ここでは、NEC Express 5800/A1160 の機能であるボックス追加を活用してサーバリソースを追加す

ることで、In-Memory PQ の適用範囲を拡大する方法を検証します。ボックスを追加すると物理メ

モリが増加するため、より多くのバッファ・キャッシュを割り当てることが可能となります。

検証では、In-Memory PQ 設定有りで 2 ボックスでの Express 5800/A1160 上で検証 1 と同様の検証

を実施し、検証 1 の結果（1 ボックス）と比較することで、ボックス追加により In-Memory PQ の

適用範囲を拡大できることを確認しました。

この検証で使用した検証環境は次の通りです。


1ボックス(物理メモリ： 64GB ,総CPUコア数：16コア)

2ボックス(物理メモリ：128GB ,総CPUコア数：32コア)

PGA+SGA 1ボックス：50GB

2ボックス：100GB

バッファ・キャッシュ 1ボックス：24.5GB(約80%は19.6GB)

2ボックス：51.8GB(約80%は41.4GB)


対象テーブル月単位でパーティション化されたテーブル（1パーティション辺り

約2.5GB）



Express 5800/A1160 の構成が 1 ボックス時と 2 ボックス時とでの、In-Memory PQ の適用範囲を比

較した検証結果を次の図 16 に示します。

図 16 Express5800/A1160のボックス追加前後におけるIn-Memory PQの適用範囲比較

1 ボックスでは約 20GB の検索範囲のクエリで既に Direct Path Read に切り替わっていますが、ボッ

クスを追加してバッファ・キャッシュのサイズを 2 倍に拡大することで、大約 40GB（1 ボック

ス時の約 2 倍）の検索範囲のクエリでも、In-Memory PQ で動作していることが確認できます。

以上より、NEC Express 5800/A1160 のボックス追加機能を活用することで、In-Memory PQ の適用

範囲の容易な拡張が可能となります。

検証 2-2:Oracle Database の表圧縮機能による適用範囲の拡大

ここでは、Oracle Database の表圧縮機能を活用して検索対象データのサイズを縮小することで、In-Memory PQ の適用範囲を拡張する方法を検証します。表圧縮機能は 1 ブロックあたりにより多く

の行を格納できるため、非圧縮時より大きな検索範囲のデータをバッファ・キャッシュ上にキャッ

シュさせることが可能となります。また、圧縮しても In-Memory PQ が適用されないクエリについ

ても、同じ行数を取り出すために必要なデータ量が減少することでディスク I/O 時間の削減が期待

できます。

上記のことを確認するために、In-Memory PQ 設定有りで表圧縮機能を用いて約 2.1 倍に圧縮した

パーティション表に対して検証 1 と同様の検証内容を実施し、検証 2-1 の結果（非圧縮）と比較し

ました。

この検証で使用した環境は次の通りです。





PGA+SGA 100GB



対象テーブル月単位でパーティション化されたテーブル

非圧縮（1パーティション辺り約2.5GB）

圧縮（1パーティション辺り約1.2GB）

非圧縮時と圧縮時での In-Memory PQ のレスポンスタイムを比較した検証結果を次の図 17 に示し

ます。

図 17 非圧縮時と圧縮時でのIn-Memory PQのレスポンスタイム比較

図 17 より、非圧縮時では In-Memory PQ が適用される検索範囲のデータサイズが約 40GB であっ

たものが、圧縮することにより大約 85GB（= バッファ・キャッシュの 80%（41.4GB）×圧縮率

（2.1））付近まで拡大していることが確認できます。これは圧縮によってデータサイズが縮小さ

れたため、それだけ多くの行のデータをキャッシュ可能になったことを示しています。また、非圧

縮時のデータサイズが約 85GB 以降においては、非圧縮時も圧縮時も同様に Direct Path Read で動

作する PQ が実施されていますが、圧縮時の方が非圧縮時より約 2.1 倍高速になっています。これ

は圧縮によってディスク I/O が削減された効果です。以上より、DWH システムの一般ユーザーのクエリの処理対象となるデータ量が増大しても Oracle Database の表圧縮機能を活用することで、In-Memory PQ の適用範囲を拡大することが可能となる

ことを確認しました。さらに、経営層ユーザーが実行するような検索範囲が長期であるため、圧縮

しても In-Memory PQ が適用されにくいクエリに対しても、ディスク I/O 時間が削減し高速化され

ることを確認しました。



検証3: In-Memory Parallel QueryによるDWHシステム全体の高速化

一般ユーザーの検索範囲は直近でかつバッファ・キャッシュ上にキャッシュ可能なサイズです。そ

のため、Direct Path Read で実行されていた従来の PQ から In-Memory PQ に置き換わることで、よ

り高速なレスポンスを期待できます。さらに、同じ検索範囲にも関わらず毎回発生していたディス

クアクセスが発生しなくなると考えられます。

一方、経営層ユーザーのクエリは、一般的に検索範囲が長期でバッファ・キャッシュのサイズに比

べて大規模であるため、従来通り Direct Path Read で実施される傾向があります。しかし、同時に

実行されている一般ユーザーのクエリで使用しなくなったストレージの I/O 帯域も利用できるため、

経営層ユーザーのクエリにたいしても高速なレスポンスが期待できます（図 18）。

図 18 In-Memory PQによる使用リソースの変化



ここでは、上記の理由から、In-Memory PQ を設定することによって DWH システム全体が性能向

上することを検証します。

この検証で使用したモデルは次の図 19 の通りです。

図 19 検証で使用したDWHシステムのモデル

一般ユーザーは 9 セッション、経営層ユーザーは 1 セッション、合計 10 セッション使用しました。

すべての一般ユーザーは直近 1 カ月にアクセスするクエリを実行し、経営層ユーザーは直近 1 年に

アクセスするクエリを実行します。また、各セッションから連続的にクエリを発行させることで常

に 10 セッションが同時実行している状態を作ります。この状態を一定時間継続し、両ユーザーの

クエリの平均レスポンスタイムを計測しました。

本検証を実施した環境は以下の通りです。

データベース・クライア

ント Express5800/R120a-2

（物理メモリ：26GB,総CPUコア数：8コア）



PGA+SGA 100GB


使用したクエリの内容

一般ユーザー：

直近1カ月のデータ（約6GB）を全件検索し合計を集計するクエリ

経営層ユーザー：

直近1年間のデータ（約72GB）を全件検索し合計を集計するクエリ

対象テーブル月単位でパーティション化されたテーブル

圧縮（1パーティション辺り約6GB）



In-Memory PQ の設定有り無しにおける、一般ユーザーと経営層ユーザーの平均レスポンスタイム

の比較を次の図 20 に示します。

図 20 In-Memory PQ設定有り無しにおけるユーザータイプ毎の平均レスポンスタイム比較

In-Memory PQ の設定を有りにすることで一般ユーザーのクエリは約 5 倍、経営層ユーザーのクエ

リは約 9 倍高速化し、DWH システム全体の性能が向上することが確認できました。

参考として、In-Memory PQ の設定有り無しにおける CPU 使用率（usr+sys）の時系列グラフを次の

図 21 に示します。



図 21 In-Memory PQ設定有り無しでのCPU使用率比較

In-Memory PQ 設定無しの場合、つまりすべてのクエリが Direct Path Read で動作している状態では、

ディスクの I/O ボトルネックにより、CPU 使用率が 10%付近と低い状態が続いています。これは

ディスクからのデータの供給速度が CPU のデータ処理速度に比べて不足しているため、CPU がデ

ィスクからのデータの供給を待っている状態です。この状態では CPU リソースを有効に活用でき

ません。

一方、In-Memory PQ 設定有りの場合は、一般ユーザーからのデータ供給は物理メモリから、経営

層ユーザーからのデータ供給はストレージから行われ、データの供給元が分散されます。ディスク

からのデータ供給による CPU の I/O ウェイトが起きている間も物理メモリから供給されるデータ

を CPU が効率的に処理することが可能な状態です。このため、高い CPU 使用率を保つことができ、

リソースを有効に活用できていることが確認できます。



まとめ

本検証では、In-Memory PQ を適用することで、ハードウェアリソースが効率的に使用され、DWHシステム全体の性能向上が可能であることを確認しました。

一般的な DWH システムでは、ストレージのディスク I/O 性能がボトルネックになる傾向がありま

すが、In-Memory PQ を適用することで、Direct Path Read から In-Memory PQ の動作に変わったク

エリが、ストレージ性能の限界よりはるかに高速に実行されることを確認しました。さらに、In-Memory PQ の動作になることで解放されたストレージ I/O 帯域を活用し、In-Memory PQ が適用さ

れない大量データを検索するクエリまでも高速化できることを確認しました。

また、In-Memory PQ が適用可能な検索範囲を拡大する方法として、今回検証で使用した NEC Express5800/スケーラブル HA サーバはサーバリソースを追加して物理メモリを拡張できることか

ら、In-Memory PQ と相性が良いことを確認できました。さらに、In-Memory PQ の適用範囲の拡大

には、Oracle Database の表圧縮機能を使用したデータサイズの縮小が有効であることを確認しまし

た。この場合、圧縮してもなお In-Memory PQ が適用されない大量データのクエリに対しても、デ

ィスク I/O 時間の削減により高速化されることが確認できました。

以上より、NEC Express5800/スケーラブル HA サーバと Oracle Database 11g Release 2 の新機能 In-Memory Parallel Query の組み合わせは、近年求められている高性能 DWH システムにとって、適

なソリューションを提供します。


共著者: 正木宏和丸山陽太郎日本電気株式会社東京都港区芝5-7-1

Copyright © 2010 NEC Corporation, All Rights Reserved. 本書の内容の一部または全部を無断で転載および複写することは禁止されています。本書の内容は将来予告なしに変更することがあります。日本電気株式会社は、本書の技術的もしくは編集上の間違い、欠落について、一切責任を負いません。日本電気株式会社は、本書の内容に関し、その正確性、有用性、確実性その他いかなる保証もいたしません。 WebSAM、iStorageManagerは日本電気株式会社の商標および登録商標です。本書に記載のシステム名、会社名、製品名は、各社の登録商標もしくは商標です。

著者: 辻研一郎共著者:荒田圭哉日下部明柴田長日本オラクル株式会社東京都港区北青山2-5-8 オラクル青山センター

Copyright © 2010, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載さ

れる内容は予告なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による

明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および

条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間

接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のた

めにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

Oracleは米国Oracle Corporationおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

Documents

Oracle Database 11g Release 2 In-Memory Parallel … Database 11g Release 2 In-Memory Parallel Queryによる NEC Express5800/スケーラブルHAサーバ上でのData Warehouseシステム全体の性能向上