nec sigmablade-m と oracle real application clusters 10g を
TRANSCRIPT
NEC SIGMABLADE-M と
Oracle Real Application Clusters 10g を使用した
データウェアハウスシステム拡張性の検証
第 1.0 版 2008.1.25
1
目次
1. はじめに ..................................................................................................................................................................... 3
2. 概要.............................................................................................................................................................................. 4
2.1. システム概要.................................................................................................................................................. 4
2.2. 使用したハードウェア.................................................................................................................................. 4
2.3. 使用したソフトウェア.................................................................................................................................... 6
2.4. ネットワーク構成 ........................................................................................................................................... 6
2.5. スキーマ構成.................................................................................................................................................. 7
2.6. 検証内容.......................................................................................................................................................... 8
3. Oracle機能紹介 ....................................................................................................................................................10
3.1. Internode Parallel Query (IPQ)..............................................................................................................10
3.2. COMPRESS...................................................................................................................................................11
3.3. Oracle Real Application Clusters (RAC) ...........................................................................................12
3.4. Oracle Partitioning .....................................................................................................................................12
3.5. Oracle Enterprise Manager 10g ............................................................................................................12
3.6. Automatic Storage Management (ASM) ............................................................................................13
3.7. 外部表.............................................................................................................................................................13
3.8. BIGFILE表領域............................................................................................................................................13
4. 検証で使用したHW/SW .....................................................................................................................................14
4.1. SIGMABLADE-M.........................................................................................................................................14
4.2. iStorage D3-10...........................................................................................................................................14
4.3. WebSAM SigmaSystemCenter...............................................................................................................15
5. 考察・チューニング...............................................................................................................................................16
5.1. 全体..................................................................................................................................................................16
5.2. チューニングポイント .................................................................................................................................18
6. Tips.............................................................................................................................................................................21
6.1. Internode Parallel Query (IPQ) に関連する初期化パラメータ.................................................21
6.2. パラレルクエリに関連する動的パフォーマンス・ビュー...............................................................22
7. まとめ.........................................................................................................................................................................23
2
1. はじめに
2006 年 7 月、NEC は、次世代 IT 基盤を実現するため、IT プラットフォーム製品の開発指針および
ロードマップを策定し、IT プラットフォームビジョン「REAL IT PLATFORM」を発表しており、この
「REAL IT PLATFORM」では、NEC の仮想化技術、高信頼技術、統合化技術とシンプルな運用技
術を利用し、「柔軟」「安心」「快適」システムをお客様に提供することを目指している。
一方、日本オラクル株式会社は、10g を発表した数年前よりグリッドコンピューティングを実現する
「Oracle GRID」技術を提供している。さらに、2006 年 11 月、グリッドをベースとした次世代のビジネ
ス・ソリューション構築を目的に、世界最大級規模の検証施設「Oracle GRID Center」を設立した。
NEC と日本オラクル株式会社は、20 年に渡る協業関係を基盤とし、次世代 IT インフラ基盤の実現
に向けた開発レベルでの戦略協業（STA：Strategic Technology Alliance）を推進しており、この度、
NEC は「REAL IT PLATFORM」の具現化を強化するために、「Oracle GRID Center」に参画した。
本検証は、「Oracle GRID Center」での共同検証として、両社での初の成果であり、NEC のブレー
ドサーバシステムを用いたスケールアウト構成の大規模グリッド環境データウェアハウス(DWH)シ
ステムにおいて、検索性能のリニアな向上を業界で初めて実証した。ここに検証成果を報告する。
3
2. 概要
2.1. システム概要
本検証のシステム構成の概要は以下の通りである。
図 2-1. システム構成図
.2. 使用したハードウェア
検証で使用したサーバ、ストレージは以下の通りである。
データベースサーバ
レードシステム SIGMABLADE-M
2
本
・
ブ
CPU ブレード Express5800 120Bb-6 × 8 ブレード
CPU デュアルコア インテル(R)Xeon(R)プロセッサー 5160
3GHz 2 ソケット/CPU ブレード
メモリ 8GB/CPU ブレード
表 2-1. 使用したデータベースサーバ
BLADE
L2 SWITCH
FC SWITCH
L2 SWITCH
BLADE
BLADE
BLADE
BLADE
BLADE
BLADE
BLADE
FC SWITCH
Storage
Storage
Storage
WebSAMSigmaSystemCenter
Oracle Enterprise Manager 10g Grid Control
管理サーバ DB管理サーバ
ブレードシステム：SIGMABLADE-M
ブレードシステム：SIGMABLADE-M
iStorage D3-10iStorage D3-10
CPUブレード: Express5800 120Bb-6
4
・ ストレージ
デル名 iStorage D3-10 × 3
モ
ホストインタフェース 400MB/s）× 2 /ストレージ ファイバチャネル（最大
キャッシュメモリ 4GB/ストレージ
ディスクドライブ SAS 147GB(15,000rpm) × 12/ストレージ
表 2-2. 使用し
torage D3-10 の 3 台のストレージにおいて、147GB のハードディスクの 10 台構成で RAID50 グ
racle を構成するデータファイル、REDO ログファイル等はすべてこのディスク・グループ
たストレージ
FCスイッチ
図 2-2. ストレージ構成図
iS
ループを構成している。そして 3 つある RAID50 グループの中では、1GB、212GB×5 の計 6 つの
LUN を構成している。1GB の LUN は、Oracle Real Application Clusters の管理領域に使用し、
212GB×4×3 ストレージの LUN を使用し、Oracle の自動ストレージ管理（Automatic Storage
Management：ASM）の 1 つのディスク・グループ(ORA_DG)としている。残りの 212GB×1×3 ストレ
ージの LUN は未使用である。
O
(ORA_DG)内に作成し、全て ASM で管理している。
RAIDエンジン
CPUコア
CPUコア
キャッシュメモリ
アレイコントローラ #0
RAIDエンジン
CPUコア
CPUコア
キャッシュメモリ
アレイコントローラ #１
SAS (Wide Link)
RAID50 ローディング用
RAIDエンジン
CPUコア
CPUコア
キャッシュメモリ
アレイコントローラ #0
RAIDエンジン
CPUコア
CPUコア
キャッシュメモリ
アレイコントローラ #１
SAS (Wide Link)
RAID50 ローディング用
RAIDエンジン
CPUコア
CPUコア
キャッシュメモリ
アレイコントローラ #0
RAIDエンジン
CPUコア
CPUコア
キャッシュメモリ
FCスイッチ
アレイコントローラ #１
SAS (Wide Link)
RAID50 ローディング用
5
図 2-3. LUN の構成とストレージの使用用途
.3. 使用したソフトウェア
検証で使用したソフトウェアは以下の通りである。
S Red Hat Enterprise Linux Version4 Update5 Advanced
2
本
O
Server（Kernel 2.6.9-55.EL）
データベース 2 (10.2.0.3) Oracle Database 10g Release
WebSAM SigmaSystemCenter 1.1 運用管理ソフトウェア
ontrol(10.2.0.3) Oracle Enterprise Manager 10g Grid C
表 2-3. 使用し
.4. ネットワーク構成
検証では以下のネットワークを構成している。
たソフトウェア
2
本
212GB 212GB 212GB 212GB 212GB
RAIDグループ(RAID50)
ストレージ1
212GB 212GB 212GB 212GB 212GB
RAIDグループ(RAID50)
ストレージ2
212GB 212GB 212GB 212GB 212GB
RAIDグループ(RAID50)
ストレージ3
1GB
OCR、Voting用
1GB
1GB
未使用
ASM用(DBオブジェクト1TB、Temp1.5TB)
6
BLADE
L2 SWITCH#0
Public LAN(eth0): 1000Base-TX×1Private LAN(eth1,2): 1000BaseTX×2(Act-Standbyでbonding)
BLADE
BLADE
BLADE
BLADE
BLADE
BLADE
BLADE
管理サーバ DB管理サーバ
WebSAM SigmaSystemCenterOracle Enterprise Manager 10g
Grid Control
L2 SWITCH#1L2 SWITCH#2
図 2-4. ネットワーク構成
SIGMABLADE に搭載した 8 台の CPU ブレードには、ネットワーク・インターフェースが 4 つずつあ
り、SIGMABLADE 筐体に内蔵されている 4 台の L2 スイッチに内部的に接続されている。初期状態
で、4 つある NIC がスイッチに連結されており、今回は 1 枚の NIC(eth0)をパブリックネットワークと
して使用し、2 枚の NIC(eth1、eth2)を Active-Standby で bonding し、Oracle Real Application
Clusters で使用するプライベートネットワークとしている。
2.5. スキーマ構成
本検証のスキーマ構成は以下の通りである。
・・・・
PARTKEY
・・・・
PARTKEY
・・・・
SUPPKEY
PARTKEY
・・・・
SUPPKEY
PARTKEY
・・・・
NATIONKEY
CUSTKEY
・・・・
NATIONKEY
CUSTKEY
・・・・
NATIONKEY
SUPPKEY
・・・・
NATIONKEY
SUPPKEY
・・・・
REGIONKEY
NATIONKEY
・・・・
REGIONKEY
NATIONKEY
・・・・
REGIONKEY
・・・・
REGIONKEY
・・・・
SUPPKEY
PARTKEY
ORDERKEY
・・・・
SUPPKEY
PARTKEY
ORDERKEY
・・・・
CUSTKEY
ORDERKEY
・・・・
CUSTKEY
ORDERKEY
PART200,000,000行
SUPPLIER10,000,000行
PARTSUPP800,000,000行
CUSTOMER800,000,000行
NATION25行
LINEITEM6,000,000,000行
REGION5行
ORDERS1,500,000,000行
図 2-5. 検証で使用したスキーマ
7
2.6. 検証内容
本検証では、ブレードシステム「SIGMABLADE-M」に搭載される 8 台の CPU ブレード
「Express5800/120Bb-6」上に、Oracle Real Application Clusters 10g を使用し、Grid 環境のデータ
ベースを構築した。
構築したデータベースに対して、「2.5 スキーマ構成」の通り表を作成している。その後、1TB のデ
ータをローディングし、検証用の大規模 DWH 環境を準備した。
検証では、構築した DWH 環境に対して、クエリを発行しそのレスポンスタイムを測定する。大規模
DWH システムをグリッド環境へ適用した場合のスケールアウトを検証するために、クエリを処理す
るノード数を 1～8 まで変更させ、ノード数に比例したパラレル度を指定し（n ノードのときパラレル
度は 4×n）、レスポンスタイムを測定した。
1.sql を 3 ノードで実行する例：
SQL> ALTER SYSTEM SET PARALlEL_INSTANCE_GROUP=‘GROUP3’
SCOPE=MEMORY SID=‘GRIDDB1’
SQL> ALTER SESSION FORCE PARALLEL QUERY PARALLEL 12;
SQL> @1.sql
※ここで、GROUP3 は、3 インスタンス(＝3 ノード)からなる INSTANCE_GROUP を示す。
クラスタウェア
alter session文でクエリが発行された際に、nノードで処理するように指定しクエリを発行
処理中 処理中 処理中
例. 3ノード(n=3) のとき
図.2-6 検証の手順
なお今回の検証ではクライアント自身の負荷は非常に低いため、クエリを発行するクライアントマ
シンは、8 ノード RAC を構成するサーバマシンの中の 1 台を利用している。
検証に使用したクエリは、TPC-H で使用されるクエリを参考にし、DWH システムで使用が想定さ
8
れる以下のクエリである。
クエリ番号 クエリの内容
q#1 まだ配送されていない注文をプライオリティの高い順(収益の高い順)に上位 10 件を表示する
q#2 全期間内に、ある条件を満たす受注がどれだけの顧客から何件発生したかを集計し、
件数の少ない順に表示する
q#3 全期間内を対象に 1 ヶ月ごとの注文数をカウントする
表 2-4. 検証に使用したクエリ
9
3. Oracle 機能紹介
今回の検証で使用した Oracle の代表的な機能を以下に紹介する。大規模 DWH 環境には効果的
で重要な機能である。
3.1. Internode Parallel Query (IPQ)
はじめに、Parallel Query とは、ひとつの SQL の処理を、複数プロセスに分割し、並列実行する機
能である。レスポンスタイムの短縮が期待できる。Parallel Query を RAC 環境において複数ノード
で並列実行したものが Internode Parallel Query である。
処理の分割は Oracle 内部で行われるため、ユーザが意識する必要はない。
1つのSQLを複数ノードで並列実行し高速化
ＳＱＬ
内部で並列化して実行
ＳＱＬ
内部で並列化して実行
図 3-1. Internode Parallel Query(IPQ)の処理イメージ
Parallel Query では、問合せを制御し、最終的な問合せ結果をユーザ・プログラムに送る、クエリコ
ーディネータプロセス(QC)と、QC から命令を受けてパラレル処理を実行するパラレルスレーブプ
ロセスが存在する。
それぞれのスレーブプロセスが担当するデータの範囲は、QC が決定する。このパラレル化された
操作の分割を、「グラニュル」と呼び、以下の 2 種類がある。どちらの方針で行うかの決定は内部
的に行われるため、特定のグラニュル方針を規定する方法はない。
A. ブロック範囲グラニュル
ブロック範囲グラニュルは、パーティション表においても、ほとんどのパラレル操作の基本単位
である。つまり、Oracle Database では、ほとんどのパラレル操作において、並列度はパーティシ
ョンの数に関係しない。パーティション数とパラレル度を別々に考えられるという Oracle のメリッ
トである。
10
ブロック範囲グラニュルは、表の物理ブロックの範囲で分割する。グラニュルの数とサイズは
Oracle Database により実行中に動的に計算され、すべてのスレーブプロセスの作業分散が最
適化され、均衡化されるよう計算される。スレーブプロセスのリソースを生かし効率の良いスキ
ャンとなるよう工夫されている。
B. パーティショングラニュル
パーティショングラニュルは、パーティション表・パーティション索引の特定の場合に選択される、
パーティションベースのグラニュルである。
具体的には、パラレル索引レンジ・スキャン、問合せオプティマイザによってパーティションワイ
ズジョインの使用が選択されている場合の 2 つの同一レベル・パーティション表の間のジョイン、
パーティション索引の複数パーティションを変更するパラレル操作（パーティション索引のパラレ
ル作成など）の基本単位である。これらの操作には、パーティション索引のパラレル作成および
パーティション表のパラレル作成が含まれる。
パーティショングラニュルの場合は、パラレル度の最大値はパーティション数となる。
今回の検証で使用したのは、SELECT 文のみであるが、パラレル実行が可能な処理として、他に、
DDL(CREATE TABLE AS SELECT, CREATE INDEX, REBUILD INDEX な ど ) や 、
DML(INSERT/UPDATE/DELETE など)、SQL*Loader や外部表を用いたパラレルローディング、
DBMS_STATS による統計収集などがある。
Parallel Query では、Oracle が自動的に決定したパラレル度、または、ユーザが指定したパラレル
度でクエリを実行することができる。Oracle がパラレル度を自動的に決定する場合は、他のユー
ザのクエリ実行状況に応じて、自動的にパラレル度を減少させる機能を有する。Internode Parallel
Query では、プロセス間の通信にインターコネクトを利用する。パラレル度が低く設定されると、ク
エリを実行するノード数が削減し、結果、インターコネクトのトラフィックを減少させることができる。
3.2. COMPRESS
データの圧縮によって、データ格納効率の向上(ディスク使用量の削減)と高い検索性能を実現す
る機能である。表やパーティション単位で圧縮することができる。
データを検索する場合、圧縮済みのデータをディスク上から読み込むため、物理 I/O 量は削減さ
れるため、物理 I/O 量の多い大規模 DWH 環境では COMPRESS 機能を使用することで高い性能
を得ることができる。
なお、Oracle Database 10g までの COMPRESS 機能では、COMPRESS 属性を指定していても、実
際にデータが圧縮されるのはバルク INSERT やバルクロード時のみである。具体的には以下の通
りである。
11
• SQL*Loader のダイレクト・パス・モード
• ダイレクト・ロード INSERT
• パラレル INSERT
• CREATE TABLE <table_name> COMPRESS AS SELECT ...
3.3. Oracle Real Application Clusters (RAC)
RAC は、高可用性とリニアなスケーラビリティを両立させた、共有ディスク・クラスタ型のクラスタデ
ータベースである。グリッドコンピューティングを実現するためのワークロード管理機能が実装され
ている。これは、アプリケーションをサービスとして定義し、処理リソースを必要に応じて割り当てる
ことが可能である。また、データの再配置やアプリケーションの変更無しに、クラスタのノード追加
が可能であり、システムの成長に合わせて、処理能力を拡張させることができる。Oracle Grid
Computing を支える基盤技術である。
3.4. Oracle Partitioning
パーティションとは、ひとつの表を、データベース内部で分割して管理する機能である。性能向上
と、管理性向上の 2 つのメリットがある。
表のある列をキーに、分割を行うが、分割手法として、レンジ(キー値の範囲による分割)、ハッシュ
(キー値をハッシングして分割)、リスト(キー値のリストによる分割)、コンポジット(前述の 3 つを組み
合わせた 2 段階のパーティション化方法。Oracle Database 10g R2 では、レンジ－リスト、レンジ－
ハッシュの組み合わせが可能)がある。
パーティション表における性能面でのメリットを以下に示す。
パーティションプルニングとは、検索時に、不要なパーティションにアクセスしない機能である。例
えば、表が、salesdate 列をキーに月ごとにレンジパーティション化されている場合、where
salesdate =2007 年 2 月 なら、「2007 年2 月」以外のパーティションにはアクセスしないことを指す。
これにより、表全体のデータが増加しても、必要なデータが存在するパーティションにのみ、アクセ
スを絞ることが可能である。
パーティションワイズジョイン(PWJ)とは、2 つの表を JOIN するときに、パーティション単位でジョイ
ンを行う機能であり、ジョイン時の負荷を軽減することが可能である。PWJ には、ジョインする両方
の表の、同じ手法・数でパーティション化されたキーにより JOIN するフルパーティションワイズジョ
インと、片側の表がパーティション化されている場合に、もう片側の表を動的にパーティション化す
るパーシャルパーティションワイズジョインの 2 種類がある。
3.5. Oracle Enterprise Manager 10g
Oracle Enterprise Manager 10g Grid Control を利用すると、Oracle Database のみならず、Oracle
Application Server などのオラクル製品、更にはホストのハードウェア、OS、ネットワーク機器など、
12
システムに関わるさまざまなコンポーネントを、Web ブラウザベースの単一の管理コンソールから
管理することが可能である。今回の検証では、データベースや OS のリソース状況の把握に役立
った。
3.6. Automatic Storage Management (ASM)
ASM は、Oracle データベース専用に開発されたストレージ管理の機能である。ASM を用いること
で、ディスク領域の管理の自動化による管理作業の軽減、最適な配置、データの冗長化による信
頼性の向上と、ストライピングによる高いパフォーマンスを実現する。
3.7. 外部表
外部表とは、Oracle データベース外部に置かれた、ファイルシステム上のファイル上のデータを表
のデータとすることができる機能である。外部表に対する SELECT 結果をデータベースに取り込む
(例：CREATE TABLE … AS SELECT …FROM 外部表)ことで、データのローディングが実行できる。
アクセスドライバとして、ORACLE_LOADER と、ORACLE_DATAPUMP ドライバの 2 種類があるが、
以下、ORACLE_LOADER について紹介する。
テキストファイルのロードは、古くから、SQL*Loader によるローディングが一般的であった。外部
表の機能では、アクセスドライバ部分は SQL*Loader と同じ仕組みでありながら、SQL*Loader で
は実現できなかった、データを変換しながらのロードが行える。
3.8. BIGFILE 表領域
Oracle Database 10g で新しく導入されたアドレッシング・スキームを持つ表領域である。従来の
SMALLFILE 表領域と比較し、BIGFILE 表領域では、1 つの表領域は、１つのデータファイルのみと
いう制限があるが、1 データファイルの最大サイズが拡張された。OS によるサイズ制限を受けな
い限り、BIGFILE 表領域の場合、1 データファイルの最大サイズは、DB_BLOCK_SIZE=32KB で
128TB となる。一方、SMALLFILE 表領域では 128GB である(厳密にはそれぞれ 1 ブロックサイズ
引いた値となる)。
13
4. 検証で使用した HW/SW
今回の検証で使用した HW および SW について以下に紹介する。
4.1. SIGMABLADE-M
NEC ブレードシステム「SIGMABLADE（シグマブレード）」は、高密度実装を重視したモジュラーア
ーキテクチャの採用により、サーバ増設が容易で、必要な時に必要な枚数を簡単に追加すること
が可能である。
また、電源や FAN、メディアなどのデバイスを全て共通化することにより部品数を削減し、低消費
電力化を実現するとともに、各種スイッチモジュール（FibreChannel 及び LAN）が内蔵可能で、省
スペース化を実現している。
分散していたシステムをひとつにするサーバ統合に最適なプラットフォームとして、IT 管理業務の
簡素化と高次元の可用性を実現できる。
4.2. iStorage D3-10
iStorage D3-10 は、ハイエンドストレージの先進技術を投入し、高性能・高信頼でありながら、リー
ズナブルな価格設定と専門知識のいらない簡単な導入・運用性を実現している。
以下の特徴がある。
- シンプルでミスのない導入設定
ストレージ装置を設置してから、サーバで利用するまでのプロセスが徹底的に簡素化されてお
り、専門の知識がなくても、初期設定ウィザードに沿って必要項目を入力していくことで設定でき
る。
- 冗長化による高信頼設計
可用性にこだわりすべてのコンポーネントを冗長化している。
- ビジュアルな表示画面で一元管理・操作
Web ブラウザ画面で、ストレージの容量情報やディスクの負荷状況、システムの稼働状況など
を一元的に監視したり、レプリケーション設定などを操作できる。初めてストレージを利用する方
でも理解しやすく、操作ミスを防ぐことができる。
- オンライン業務に影響を与えないバックアップシステム
変更のある部分(更新差分)だけを効率よく保持するスナップショット機能、無停止で業務ボリュ
ームの完全複製を作成するレプリケーション機能を使用できる。
また、無停止バックアップシステムの構築に対して、対象リソースの自動検出機能や、わかりや
すい対話形式のスクリプト作成機能などのサポートで、従来と比べ容易に無停止バックアップシ
14
ステムを構築できる。
4.3. WebSAM SigmaSystemCenter
SigmaSystemCenter (シグマシステムセンター) は、プラットフォームの統合管理ソフトウェアであり、
サーバ、ストレージ、ネットワークの統合管理を実現する。マルチプラットフォーム、マルチ OS を同
一の管理画面・同一の操作性で簡単に管理することができ、システム管理者の TCO 削減に役立
つ。以下の特徴を持っている。
- ソフトウェアの一括配布
OS やアプリケーションをネットワーク経由で一括リモートインストールできる。
煩雑なパッチ適用なども管理コンソールから一元管理でき、導入時に大きな負担となる OS
やアプリケーションのインストール、各種設定の手間を大幅に軽減する。
本検証においても、8 ノード RAC を構築する際には、8 台のサーバに対してホスト名のマシン固有
情報以外は全て同一の環境を配布する必要があり、本ソフトウェアの使用により環境構築にかか
る工数が大幅に減少した。
- 可用性向上とコスト削減を両立
複数台の業務サーバに対して、最少 1 台の予備サーバを用意しておけば、障害時に予備サーバ
により自律復旧できる。低コストで可用性の高いシステムを構築することが可能である。
- リソースの効率運用
GUI からの簡単な操作で、サーバの構成を変更できる。
また、スケジュール運転による計画変更も可能なため、繁忙期にあわせたシステム構成の
変更も容易。リソースの効率活用とシステム管理者の負担軽減を同時に実現できる。
- システム内のサーバを統合管理
Windows、Linux、HP-UX などのサーバ OS のほか、クライアント OS として WindowsXP にも対応し
ている。また、SIGMABLADEだけでなく既存サーバ環境、さらにネットワークやストレージの構成ま
で管理できる。高度な機能でシステム基盤を統合的に管理し、運用の効率化を実現できる。
15
5. 考察・チューニング
5.1. 全体
検証では、大規模 DWH システムをグリッド環境へ適用した場合のスケールアウトを検証するため
に、クエリを処理するノード数を 1～8 まで変更させ、レスポンスタイムを測定した。ノード数の指定
は、Oracle の機能である Internode Paralell Query 関連のパラメータを設定した。
計測したレスポンスタイムは以下の通りである。
図 5-1. クエリごとのレスポンスタイム
体的な傾向として、ノード数増加に伴い、レスポンスタイムが向上している。
も大幅な性能向上
に、本検証の目的である大規模 DWH 環境でのスケールアウトを実現するために、以下の点に
A. Internode Parallel Query(IPQ)の動作
. Internode Parallel Query(IPQ)の動作
Parallel Query では、Oracle が自動的に決定したパラレル度、または、ユーザが指定したパラレ
本検証では、PARALLEL_INSTANCE_GROUP で IPQ に参加するノードと、ALTER SESSION 文で
全
特に q#2 ではレスポンスタイムが 1→8 ノード時に 7.69 倍向上した。q#1、q#3 で
が確認できた。
次
ついての検証結果を考察する。
B. Interconnect の帯域使用状況
C. サーバ数増加に伴う性能向上
A
ル度でクエリを実行することができる。そのため、Oracle RAC へノードを追加し、システム構成
を変更した場合においても、状況に応じてパラレル度を選択することができる。
参加ノード数に比例したパラレル度(n ノードのときパラレル度は 4×n)を指定している。
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
レス
ポン
スタ
イム
ノード追加に伴うレスポンスタイム(q#1)
1node
2node
3node
4node
5node
6node
7node
8node
1.92倍
6.60倍 7.12倍
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
レス
ポン
スタ
イム
ノード追加に伴うレスポンスタイム(q#2)
1node
2node
3node
4node
5node
6node
7node
8node
ノード追加に伴うレスポンスタイム(q#3)
1node
2node
2.40倍
3.75倍
7.69倍
3node
4node
5node
6node
7node
8node
1.89倍
3.56倍
5.96倍
16
検証の結果、Internode Parallel Query(IPQ) として PARALLEL_INSTANCE_GROUP で指定した
ス)の数は、全ノードでほぼ偏り無く起
. Interconnect の帯域使用状況
Oracle Real Application Clusters では、Interconnect は以下の 3 つのデータ通信で使用される。
- Oracle Clusterware の heartbeat 通信
uery におけるクエリコーディネータプロセス(QC)とパラレルスレーブ
今回、上記 3 つは同じ通信経路を使用している。この内、Oracle Clusterware の heartbeat 通信
- キャッシュフュージョン
証において、ほとんどのクエリでは、Parallel Query により、SGA を介さない direct path read
- IPC
検証においてキャッシュフュージョンはほとんど発生しなかったため、Interconnect を使用する
クを使用しておらず、q#2, q#1はネットワーク帯域の使
増加に伴い、1 ノード当たりのネットワーク通信量が増加する、という状況にな
. サーバ数増加に伴う性能向上
ノード間にまたがって処理されていることが確認できた。
また、パラレル実行サーバプロセス(以下、スレーブプロセ
動していることも確認した。
B
- キャッシュフュージョン
- IPC(Internode Parallel Q
プロセスやパラレルスレーブプロセス同士のプロセス間でのデータ送受信)
は、ほかの 2 つと比較してデータ送受信量が小さいため、ネットワーク性能にほとんど影響を与
えない。
検
で直接ディスクからデータを読む込むため、キャッシュフュージョンはほとんど発生しなかった。
キャッシュフュージョンによるブロック転送量は、最大でも対象オブジェクトの総ブロック数の
0.0047% であることを確認した。
通信はほとんど IPC によるものである。
3個のクエリ中、q#3はほとんどネットワー
用が見られた。
また、ノード数の
っていないことを確認した。ネットワーク帯域を多く使用することが問題となる場合は、対策とし
てクエリを変更して対象となる行数を減らす、もしくはフルパーティションワイズジョインできない
かを検討する、または PARALLEL_INSTANCE_GROUP パラメータを調節して、1 ノード内で処理
をするように変更することが考えられる。
C
17
Oracle RAC へノードを追加することにより、追加したノードのリソース(CPU、メモリ)を新たに使
- CPU リソースの増加
1 ノードのとき、CPU 使用率がほぼ 100%となっていた q#3 において、1→2 ノード時に約 1.9 倍
- メモリリソースの増加メモリリソースの増加により、Oracle Database で使用できるメモリ領域も
スについては、以下のマニュアルを参照のこと。
.2. チューニングポイント
用できるようになる。リソース不足により時間がかかっていた処理は、ノード追加に応じて性能
向上することが期待できる。具体的には、システム全体での CPU リソースと Oracle で利用でき
るメモリが増える。検証において増加したリソースと、その使用状況を確認した。
のレスポンスタイム向上となっている。しかし、ノード数が増えるに従い、CPU ネックが解消さ
れる時間帯が増え、その時間帯は I/O リソース不足の状態になった。その結果、ノード数を増
やしてもレスポンスタイムの向上が緩やかになっている。
図 5-2. q#3 のノード数ごとの CPU 使用率
増加する。一般的に、DWH システムでは、大量のデータを取り扱うため、ソートやジョインで多くの
PGAの領域を使用するが、今回の検証では、q#1、q#2において、メモリリソースの増加により性能
が向上することを確認した。
Oracle で利用するメモリリソー
Oracle Database 概要 10g リリース 2（10.2）
第 II 部 Oracle データベース・アーキテクチャ
8. メモリー・アーキテクチャ
5
CPU使用率(q#3 1node)
0
20
40
60
80
100
Time
% n0c-11
CPU使用率(q#3 2node)
0
20
40
60
80
100
Time
% n0c-11
n0c-12
CPU使用率(q#3 3node)
0
20
40
60
80
100
Time
%
n0c-11
n0c-12
n0c-13
CPU使用率(q#3 4node)
0
20
40
60
80
100
Time
%
n0c-11
n0c-12
n0c-13
n0c-14
CPU使用率(q#3 5node)
0
20
40
60
80
100
Time
%
n0c-11
n0c-12
n0c-13
n0c-14
n0c-15
CPU使用率(q#3 6node)
0
20
40
60
80
100
Time
%
n0c-11
n0c-12
n0c-13
n0c-14
n0c-15
n0c-16
CPU使用率(q#3 7node)
0
20
40
60
80
100
Time
%
n0c-11
n0c-12
n0c-13
n0c-14
n0c-15
n0c-16
n0c-17
CPU使用率(q#3 8node)
0
20
40
60
80
100
Time
%n0c-11
n0c-12
n0c-13
n0c-14
n0c-15
n0c-16
n0c-17
n0c-18
18
全体的に、パラレル化の並列度を上げていくことにより、徐々に I/O ネックとなり、並列度を上げる
とによる性能向上の度合いが鈍っていく傾向があった。主に、I/O 量を減らすためのチューニン
、前章で述べたとおり、データを圧縮して格納することで、必要な I/O 量が削減し、
索性能が向上する機能である。COMPRESS 対象の表について、圧縮率を以下に示す。
こ
グを実施した。
- COMPRESS
COMPRESS は
検
サイズ(単位：MB)
オブジェクト名 COMPRESS 無（①）
比
(②/①*100) 種類 COMPRESS 有（②）
CUSTOMER 2 23,042.0 85.4 表 6,968.0
LINEITEM 表 894,722.0 455,612.0 50.9
ORDERS 1 197,749.0 43,932.0 72.8 表
SUPPLIER 1,664.0 1,536.0 92.3 表
PART 29,698.0 16,384.0 55.2 表
表 5-1. COMP /無の表サイ
上記の通り、最大の圧縮率に 圧縮されている。また表に
示していないが、今回検証で使用した非圧縮のオブジェクトを含めて、ユーザデータ全体では、
圧縮することでレスポンスタイムが向上することを確認した。
ARALLEL_EXECUTION_MESSAGE_SIZE は、Parallel Query実行時のテーブルキューのサイズで
の 3 パターンで測定したが、メッセージサイズの変更
ンとパラレルクエリ
パーティションと、レンジ-ハッシュのコンポジットパーティション
使用した。レンジは 1 月ごとのレンジで区切り、ハッシュパーティションの数は 64 にした(64 = 8 ノ
RESS 有 ズ
なった LINEITEM 表は、サイズが 50.9%へ
は
サイズが 64.9%になった。
COMPRESS を使用し、表を
- PARALLEL_EXECUTION_MESSAGE_SIZE
P
ある。今回は、2152(デフォルト), 4304, 8608
はレスポンスタイムへ与えた影響は限定的であった。差異が微少であるため、メッセージサイズ変
更による Oracle 動作の違い、または違うことによるレスポンスタイムへの影響については特定で
きていない。
- パーティショ
今回、大規模な表に対し、ハッシュ
を
ード × 4 コア × 2 で算出。また、ハッシュパーティションの数はデータを均等に分散するため
に、2 の累乗が良い)。
19
Parallel Query で、パラレル化のグラニュル単位は、Oracle Database によって自動的に決定され
が、ブロック範囲グラニュルが、ほとんどのパラレル操作の基本単位である。つまり、ほとんどの
ーティションプ
ニングの効果を期待し、ハッシュパーティションはデータが均等に分散されることで、Parallel
指定して検索する q#1 では、パーティションプ
ニングにより、必要なパーティションにのみアクセスしており、レンジパーティションの効果が確
コントローラの増強
がボトルネックとなる場合がある。
のような場合は、iStorage D3 の上位モデルである、iStorage D8 を使用することにより、ストレー
加して処理性能を増やして
しそれに伴いストレージへの I/O 量も増大していくことが予想されるため、D8
グを行った。
db_file_multiblock_read_count を 32 に設定
る
パラレル操作において、パーティションの数とパラレル度とは、関係がない。ただし、パーティション
ワイズジョインなどの場合は、パラレル化のグラニュル単位がパーティションとなり、パラレル度の
最大がパーティション数となる。(詳細は 3.1. Internode Parallel Query (IPQ)を参照)
一般的には、レンジパーティションは値の範囲でパーティション化しているため、パ
ル
Query での、パーティショングラニュルとなるような操作が高速になることを期待する場合が多い。
このため、ハッシュパーティションの数は、Parallel Query の挙動を理解した上で、パーティション数
を選択することを推奨する。もちろん、コンポジットパーティション(レンジ-ハッシュ)は、これら両方
の特長を兼ね備えたパーティション化手法となる。
今回の検証では、パーティションキーに対し、期間を
ル
認できた。
- ストレージ
一般的にストレージのコントローラ
こ
ジ層において、I/O リソースが不足した場合に、コントローラを随時追
いくことができる。
本検証では、このストレージ層の Grid 化は評価対象外であるが、DWH 系システムでは、将来にわ
たりデータ量が増大
のような拡張性のあるストレージも検討すべきである。
- そのほかのチューニング
そのほかに以下のチューニン
・メモリのチューニング
・
・非同期 I/O
・Direct I/O
20
6. Tips
6.1. Internode Parallel Query (IPQ) に関連する初期化パラメータ
instance_groups, parallel_instance_group の 2 つのパラメータは、IPQ を実行する際に各ノードが所
属するグループと、実際に IPQ が実行されるときに使用されるグループを指定する。
instance_groups では、このパラメータを設定しているノードが所属するグループ名を設定する。複
数のグループ名を設定可能。動的変更(データベースの再起動を伴わない変更)は不可である。
parallel_instance_group では、このパラメータを設定しているノードで IPQ を実行した際に使用され
るグループ名を指定する。動的変更が可能である。
今回の検証では、使用する可能性のあるすべてのグループ名を 全て事前に instance_groups に
設定しておき、検証時に使用したいノードが含まれるグループ名を parallel_instance_group で設定
した。
alter system set instance_groups='G1','G2','G3','G4','G5','G6','G7','G8' scope=spfile sid='griddb1';
alter system set instance_groups='G2','G3','G4','G5','G6','G7','G8' scope=spfile sid='griddb2';
alter system set instance_groups='G3','G4','G5','G6','G7','G8' scope=spfile sid='griddb3';
alter system set instance_groups='G4','G5','G6','G7','G8' scope=spfile sid='griddb4';
alter system set instance_groups='G5','G6','G7','G8' scope=spfile sid='griddb5';
alter system set instance_groups='G6','G7','G8' scope=spfile sid='griddb6';
alter system set instance_groups='G7','G8' scope=spfile sid='griddb7';
alter system set instance_groups='G8' scope=spfile sid='griddb8';
alter system set parallel_instance_group='G8' scope=spfile sid='griddb1';
alter system set parallel_instance_group='G8' scope=spfile sid='griddb2';
alter system set parallel_instance_group='G8' scope=spfile sid='griddb3';
alter system set parallel_instance_group='G8' scope=spfile sid='griddb4';
alter system set parallel_instance_group='G8' scope=spfile sid='griddb5';
alter system set parallel_instance_group='G8' scope=spfile sid='griddb6';
alter system set parallel_instance_group='G8' scope=spfile sid='griddb7';
alter system set parallel_instance_group='G8' scope=spfile sid='griddb8';
なお、Oracle Database 11g では、IPQ でスレーブプロセスが起動するインスタンスの範囲は、デフ
ォルトではユーザが接続したサービス(Oracle Clusterware が管理する、RAC 上のサービス)の範
囲に連動させることができるよう、機能拡張されている。その場合は、上の設定は不要。
(parallel_instance_group を指定し、デフォルトの設定を上書きすることは可能)
21
6.2. パラレルクエリに関連する動的パフォーマンス・ビュー
パラレルクエリに関連する動的パフォーマンス・ビューを以下に紹介する。詳しくは、マニュアル
「Oracle Database リファレンス 10g リリース 2（10.2）」も参考のこと。
V$PQ_TQSTAT
このビューは、パラレル実行操作の統計情報を示す。この統計情報は、問合せが完了した後でコ
ンパイルされ、そのセッションの間のみ有効になる。このビューは、問合せの実行で発生する偏り
の問題の判別に有効である。
V$PQ_SESSTAT
このビューは、パラレル問合せについてのセッション統計情報を示す。問合せまたは DML 操作の
実行後に V$PQ_SESSTAT の情報を使用すると、使用されたスレーブプロセス数、セッションおよ
びシステムのその他の情報を表示できる。
その他、インスタンス上のアクティブ・パラレル実行サーバごとの統計情報を示す V$PQ_SLAVE、
パラレル問合せについてのシステム統計情報を示す V$PQ_SYSSTAT がある。
22
7. まとめ
大規模 DWH システムを構築するにあたり、NEC Blade Server「SIGMABLADE」、ストレージ
「iStorage」上に、Oracle GRID 環境を構築することで、高い拡張性が得られることが実証できた。
本検証では、q#2 において 1 ノードから 8 ノードへノード数増加時に 7.69 倍のレスポンスタイムの
向上を確認した。また、q#1 においても 7 倍以上レスポンスタイムが向上する結果となっており、
Internode Parallel Query(IPQ)が適切に機能し、処理がほぼ均等に分散することでスケールアウト
を実現できることを確認した。ただし、どのようなパターンのクエリでも性能向上するのか、さらに、
同時セッション数が増えた場合の影響についての検討は、今後の課題である。
また DWH システムでは以下のチューニングが有効であることを確認できた。
DWH システムでは、規模に依存して、大量の I/O リソースを使用するため、I/O チューニングを
必ず行っておく必要がある。特に COMPRESS 機能による表の圧縮では、検証では巨大な表を
50%程度のサイズまで圧縮できており、この I/O 負荷軽減がダイレクトに性能向上につながって
いることが確認できた。なお、Partitioning を実施することで、パーティションプルニングによりフ
ルスキャン対象を絞ることができるため、I/O 量を大幅に削減することが期待できる。
ストレージ側でコントローラを増強することで I/O 処理能力を向上させることも有効である。デー
タ量増加に伴い I/O リソースが増加していく DWH システムにおいては、本検証の評価対象外で
あるが、「iStorage D8(本検証で使用した iStorage D3 の上位モデル)」の特徴である動的なリソ
ース追加機能が非常に有効である
またキャッシュフュージョンはほとんど発生していないことを確認した(Parallel Query では SGA を介
さずディスクからデータを読む込むため)。またIPQの各スレーブプロセス間の通信によるIPCのた
めにネットワーク帯域を使用していたが、レスポンスタイムへの影響はなく、ボトルネックにはなっ
ていないこと、また、ノード数増加に伴い、1 ノードあたりのネットワーク通信量が増加していないこ
とを確認した。ただし、例えば同時セッション数の増加などにより、ネットワーク帯域が圧迫される
ことで性能が劣化する場合は、bonding 等でネットワーク帯域増加を検討するべきである。
なお、本検証においては、ノードを変更しクエリを実行する際に、IPQ に参加するノードとノード数
に比例したパラレル度を指定するだけで、ノード数に応じた性能向上を得ることができた。つまり、
システムの変更(ノード追加など)が行われた場合に、ノード追加作業以外の作業を必要とせず、
自動的に、環境に応じた性能を得られるということである。
これらより、Grid 環境で DWH システムを構築する場合、導入当初は必要なサーバ数で開始し、デ
ータ量・処理の増加に伴い、サーバ数を増やしていくことができることを確認した。
23
この構成は、従来までの高価な DWH 専用機や大規模な SMP サーバを用いた DWH システムに比
べて、中小規模から大規模の DWH システムまで、システム規模に応じた対応が容易に可能となり、
高い投資対効果も実現できる。
24
日本オラクル株式会社 日本電気株式会社
〒102-0094 東京都千代田区紀尾井町4-1 〒108-8001東京都港区芝5-7-1
ニューオータニガーデンコート NEC本社ビル
Copyright © 2008 Oracle Corporation Japan. All Rights Reserved.
Copyright © 2008 NEC Corporation. All Rights Reserved
無断転載を禁ず
このドキュメントは単に情報として提供され、内容は予告なしに変更される場合があります。このド
キュメントに誤りが無いことの保証や、商品性又は特定目的への適合性の黙示的な保証や条件
を含め明示的又は黙示的な保証や条件は一切無いものとします。日本オラクル株式会社は、こ
のドキュメントについていかなる責任も負いません。また、このドキュメントによって直接又は間接
にいかなる契約上の義務も負うものではありません。このドキュメントを形式、手段（電子的又は
機 械的）、目的に関係なく、日本オラクル株式会社の書面による事前の承諾なく、複製又は転載
することはできません。
Oracle、JD Edwards、PeopleSoft、及び Siebel は、米国オラクル・コーポレーション及びその子
会社、関連会社の登録商標です。 その他の名称は、各社の商標または登録商標です。
25