Comments
Transcript
IBM System p上での Oracle Real Application Clusters 10g
IBM System p 上での Oracle Real Application Clusters 10g 性能検証 1 1. はじめに ここ近年の情報システムに対する意識として、特にコスト削減が課題として取 り上げられることが多くなっています。企業が成長するに従い拡張するサービス や増大し続ける負荷に対応するためのシステム投資コスト、多くの既存システム の運用コストや管理コストなどをいかに削減できるかが求められています。 これら IT コストを削減するためのアプローチは、初期コストを削減し、拡張コ ストを削減し、運用・管理コストを削減することです。そして、それを実現する 一つの解が Oracle GRID と IBM の Unix/Linux サーバーIBM System p の仮想化機能 によるソリューションです。 Oracle のグリッド技術と IBM の仮想化技術を利用することで、小さいシステム 構成から開始し、負荷に合わせてリソースを柔軟に拡張していくことができます。 そして、これらリソースを仮想化して一つのグリッド環境として構成することで、 システム管理者は一元的にシステムを管理することが可能となり、運用管理コス トを大幅に削減することができます。 従来の企業システムでは、システムごとに個別に最適化させて構築することが 主流でした。この手法ではシステムが増えるに従って運用管理が煩雑となり、そ の結果コストが跳ね上がってしまう問題が起こります。 この問題を解決するために、複数のシステムを一つのグリッド上で構築するこ とが考えられます。システム構成をシンプルにすることで、運用管理コストを削 減することができます。また、グリッドの高い拡張性や柔軟性により、経営環境 の変化に合わせたシステムの変更を迅速に行うことが可能になります。リソース は仮想化され共有されるため、使われなくなったアプリケーションはリソースを 解放し、新しく開始されるサービスに対してリソースを割り当てます。これによ り、ハードウェア資産の無駄を極小化し、投資コストを抑えられます。 日本アイ・ビー・エム株式会社と日本オラクル株式会社は、Oracle GRID Center において様々な検証を通じてグリッドの持つ可能性の実証や、システム構築を行 う上でのベストプラクティスを提供しています。本ホワイトペーパーでは、Oracle GRIC Center で実施された IBM System p 上での Oracle GRID 性能検証の結果につい て報告します。 2 2. 目次 1. はじめに .................................................................................................................... 2 2. 目次............................................................................................................................ 3 3. Executive Summary ................................................................................................. 4 4. Oracle GRID ............................................................................................................. 7 データベース・サーバーの仮想化 ................................................................................ 8 ストレージの仮想化...................................................................................................... 8 グリッド管理................................................................................................................. 9 5. IBM System p ......................................................................................................... 10 ロジカル・パーティショニング .................................................................................. 10 Hardware Management Console(HMC) ................................................................... 10 Simultaneous Multi-Threading(SMT) ...................................................................... 11 6. 検証概要 .................................................................................................................. 12 6-1 使用ハードウェア ................................................................................................ 12 6-2 使用ソフトウェア ................................................................................................ 13 6-3 システム構成........................................................................................................ 13 6-4 ストレージ構成 .................................................................................................... 14 6-5 検証プログラム .................................................................................................... 16 6-6 データベース・スキーマ...................................................................................... 16 6-7 処理概要............................................................................................................... 17 6-8 使用パラメーター ................................................................................................ 19 6-9 サービス構成........................................................................................................ 20 7. 検証結果 .................................................................................................................. 22 7.1 コネクション・プーリング想定構成 .................................................................... 22 7.2 大量接続想定構成................................................................................................. 23 7.3 SCN伝播スキーム ................................................................................................. 25 7.4 Oracle GRID & IBM仮想化技術検証 ................................................................... 28 7.4.1 Oracle RACとSMP環境の組み合わせ ............................................................... 29 7.4.2 CPU数の違う混合RAC構成 ............................................................................... 30 8. まとめ ...................................................................................................................... 33 9. 付録.......................................................................................................................... 34 9-1 Oracle Database初期化パラメータ ...................................................................... 34 3 3. Executive Summary 日本アイ・ビー・エム株式会社と日本オラクル株式会社は、2006 年 11 月に開 設された Oracle GRID Center において、共同で Oracle のグリッド技術と IBM のハ ードウェア仮想化技術を組み合わせた技術検証を実施しています。本ホワイトペ ーパーでは、それらの検証のうち、Oracle のグリッド基盤の一つである「Oracle Real Application Clusters(以下 Oracle RAC)」と IBM の高信頼性サーバーである「IBM System p」を組み合わせた性能検証結果について紹介します。 次のグラフは、IBM System p 上で Oracle RAC を稼動させたスケーラビリティ検 証の結果です。 9.00 9.00 8.00 7.80 スループット比 レスポンスタイム比 8.00 7.00 7.00 6.00 6.00 5.00 5.00 3.90 4.00 4.00 3.00 3.00 1.95 2.00 1.00 1.00 1.00 1.02 2.00 1.02 1.11 1.00 0.00 0.00 1ノード 2ノード 4ノード 8ノード 図 3-1 Oracle RAC スケーラビリティ検証結果スループットとレスポンスタイム (思考時間 0ms) この結果は、Oracle RAC を構成するノード数が 1 ノード、2 ノード、4 ノード、 8 ノードと変更した時のそれぞれのスループットとレスポンスタイムを比較した ものです。1 ノード構成でのスループットを 1.00 とした場合のスループットの比 率は 2 ノードでは 1.95、4 ノードでは 3.90、8 ノードでは 7.80 となり、ノード数 の増加に比例して性能が向上することが確認できました。トランザクションあた りのレスポンスタイムはノード数が増えてもほとんど変化しない結果となり、負 4 荷の増大に合わせてハードウェアを増強しても安定したサービス・レスポンスが 提供できることが示されました。 この結果は、Oracle RAC が Oracle のグリッド技術を支えるコアコンポーネント として最適であることを意味しています。Oracle GRID では、ハードウェア・リソ ースを仮想化し柔軟に構成を変更することができます。その際の評価の一つであ る高い拡張性が実証され、サービスの拡張、リソースの増強に対して高い応答性 を示す結果が得られました。 また、リソースの増強に関しては IBM のハードウェア仮想化技術の一つである ロジカル・パーティショニング（以下 LPAR:Logical PARtitioning）を利用すること で、更なる柔軟性を享受することができます。LPAR により、IBM System p 上で 稼動する OS について割り当てるハードウェア・リソースを柔軟に構成すること ができます。 次のグラフは、Oracle RAC と LPAR を組み合わせて実施した性能検証の結果で す。 10 ノード8 8 スループット比 ノード7 ノード6 6 ノード5 ノード4 4 ノード3 ノード2 2 ノード1 0 2CPU×8ノード 2CPU,2CPU,4CPU,8CPU 4ノード 図 3-2 CPU 数の違うノードの RAC スケーラビリティ比較 (思考時間 0ms、Lamport 方式) このグラフは、1 ノードあたり 2CPU が搭載された 8 ノード構成 RAC のスルー プットと、2CPU・2CPU・4CPU・8CPU がそれぞれ搭載された 4 ノードのスルー プットを比較したものです。この検証結果では、両者において全く同等のスルー 5 プットが得られました。この結果は、Oracle GRID を構築する上で Oracle RAC と IBM System p5 が最適であることを示しており、様々な要件に対して柔軟に対応す ることが可能であることが実証されました。 6 4. Oracle GRID IT システムの基盤をグリッド・コンピューティング技術を使用して構築するこ とは、様々なメリットをもたらします。Oracle GRID の基盤は、Oracle Database 10g、 Oracle Application Server 10g、Oracle Enterprise Manager 10g によって提供されてい ます。Oracle GRID を採用することで、ストレージ層、データベース・サーバー層、 アプリケーション・サーバー層を仮想化することができます。仮想化を利用する ことで、個々のリソースがプールされ、アプリケーションは抽象化されたリソー スを使用できるようになります。アプリケーションから抽象化されたリソースに アクセスすると、自動的に最適なリソースが割り当てられます。物理的にどのリ ソースが使用されるかを、アプリケーション開発者や実行者が意識する必要はあ りません。 グリッド・コンピューティング技術を使用することは、次のようなメリットを もたらします。 リソースが集約化されることにより、管理を一元化することができます。 リソースにアクセスするための権限をポリシーに基づき一元的に設定する ことができるため、セキュリティが強化されます。 リソースがプールされ、必要に応じて割り当てることにより、個別に最適 化されたシステムで起こっていたリソースの偏りを防ぐことができます。 Oracle GRID では、システム全体でリソース割り当てを最適化するため、 個々のピークに合わせる必要がなく、コストを抑えることができます。 プールされた複数のリソースが物理的に分散されることにより、コンポー ネントが冗長化され、高い可用性を実現することができます。個々のコン ポーネントに障害が発生しても、システム全体ではサービスを継続するこ とが可能になります。 Oracle GRID における特長を更に詳しく説明します。 7 データベース・サーバーの仮想化 Oracle Database 10g の機能である Oracle RAC により、データベース・サーバー が仮想化されます。データベースを複数のサーバーで運用することにより、デー タベース・サーバーを冗長化することができます。また、シングル・サーバーで はハードウェアの制限で搭載できる CPU 数やメモリー量に上限が存在しますが、 複数のハードウェアをつなげることでその制限を取り払い、高い拡張性を実現し ます。 ストレージの仮想化 Oracle Database 10g の機能である Oracle Automatic Storage Management（以下 ASM）により、ストレージ層を仮想化することができます。Oracle Database から は複数のディスクを一つのディスク・グループとしてアクセスすることができる ようになります。従って、既存のデータ設計や構成を変更することなくディスク を動的に追加・削除することが可能になり、データベース設計者や開発者はディ スクの物理的な構成を意識する必要がありません。ASM により、パフォーマンス とディスクの利用率が最適になるよう自動的にデータが配置されます。 8 グリッド管理 Oracle Enterprise Manager 10g Grid Control を利用することで、複数のサーバーや ディスクを一元的に管理することができます。Oracle Enterprise Manager 10g は Web ベースのアーキテクチャを採用しているため、管理者は Web ブラウザがあればど こからでも管理を行うことが可能となります。 管理者は、Web ブラウザから HTML ベースの画面を通じてグリッド内のリソー スを監視し、構成を変更することができます。 9 5. IBM System p IBM System p では、ハードウェアの仮想化技術を提供します。 ロジカル・パーティショニング サーバー内を複数のパーティション(区画)に論理的に分割できる機能です。サー バーのプロセッサーやメモリー、I/O などのリソースを、論理区画(LPAR)に分割し、 それぞれを独立して動作させることを可能にします。各 LPAR では Linux や IBM の UNIX である AIX 5L、および i5/OS などを稼働させることができ、一台のサー バーで複数のオペレーティング環境を実現します。アドレス・マッピング・メカ ニズムで論理的に区画を分割する LPAR は、物理的な制約を受ける PPAR（フィジ カル・パーティショニング）と異なり、プロセッサー、メモリー、アダプターな どをより柔軟に構成することができます。 LPAR には、プロセッサーの割り当て方法によって、専有プロセッサー論理区 画と共有プロセッサー論理区画の 2 つのタイプがあります。専有プロセッサー論 理区画は物理 CPU を一つの LPAR で専有して使用します。共有プロセッサー論理 区画は、Micro-Partitioning 機能により、物理 CPU を複数の区画で共有して使用す ることができ、一つの物理 CPU で最大 10 個の LPAR を動作させることが可能で す。 Hardware Management Console(HMC) Hardware Management Console（以下 HMC）は、システムの仮想化に関する機能 を制御する専用端末です。1 台の HMC で複数のサーバーを操作することが可能で す。以下のような機能を提供します。 ・LPAR の管理 ・パーティションの起動／停止／リセット／状態表示 ・システムまたはパーティションのコンソールアクセスの提供 ・LPAR プロファイル（各 LPAR を構成するプロセッサー、メモリー、I/O 資源 の割り当ての定義情報）の作成／保存 ・予備リソースの活動化／非活動化 ・問題判別やサービスサポートの為のツールの提供 ・アナログ電話線を介して行う Call Home 機能やエラーログ通知機能等 10 Simultaneous Multi-Threading(SMT) Simultaneous Multi-Threading（以下 SMT）は、POWER5 プロセッサーより実装 された機能です。SMT では、あるひとつのスレッドが命令を実行中に、その１ク ロック・サイクルで使用されない演算ユニットを、独立した別のスレッドに開放 して、使用することを可能にする機能です。SMT 機能を使用すると、1 クロック・ サイクル内で複数のスレッドが実行ユニットへのアクセスを共用できるため、シ ステム・レベルでのパフォーマンス、使用率、およびスループットが向上します。 SMT 機能のオン/オフは各 LPAR レベルで設定でき、Linux OS では OS 起動時のオ プションで指定します。IBM System p 上にインストールされる OS は、デフォル トで SMT 機能が有効に設定されています。 11 6. 検証概要 本検証では、IBM System p 上で Oracle RAC を稼動させたときの性能を検証して います。本検証は、2006 年 11 月より Oracle GRID Center で実施していた「大規模 Linux システムにおける Oracle Database 10g on IBM System p5 の性能」検証（以下 「大規模 SMP 検証[2]」）を Oracle RAC で実施したものです。従って、使用してい るハードウェア、ソフトウェア、検証アプリケーションは全て SMP 検証と同様の 環境で検証を実施しています。 6-1 使用ハードウェア 今回の検証で使用したハードウェアは以下のとおりです。 DB サーバー IBM System p5 モデル 570 (以下 p5 570) CPU ：POWER5+ 2.2GHz 16Way メモリー ：64GB アダプター ： 4 ポート 10/100/1000Base イーサネットアダプター 4 ギガビット・ファイバー・チャネル・アダプター 高速 73.4GB ULTRA320 SCSI ディスク・ドライブ × 16 枚 × 16 枚 × 32 ドライブ ストレージ コントローラ：IBM System Storage DS4800 (1815-82A) 拡張筐体：DS4000 EXP810 ストレージ拡張ユニット(1812-81A) 146.8GB/15K 4Gbps FC ドライブ × 16 ドライブ SAN スイッチ IBM TotalStorage SAN16B-2 × クライアントマシン × 1台 8台 CPU ：Intel Xeon quadcore 2.66GHz メモリー ：4GB アダプター ：10/100/1000Base イーサーネット × 2 ポート ネットワークスイッチ Dell PowerConnect 2724 24 ports × 2台 12 その他機器 Hardware Management Console ：p570 ハードウェア管理端末(以下 HMC) 6-2 使用ソフトウェア 今回の検証で使用したソフトウェアは以下のとおりです。 データベース・サーバー Red Hat Enterprise Linux Version4 Update3 Advanced Server (Kernel 2.6.9-34.EL) Oracle Clusterware 10g Release2 (10.2.0.2) Oracle Database 10g Release2 (10.2.0.2) IBM XL C/C++ Advanced Edition V7.0 for Linux Runtime Environment Component(Oracle Database Server 前提) [5] IBM System Storage DS4000 Linux RDAC multipath driver package version 09.01.B5.31 クライアント Red Hat Enterprise Linux Version4 Advanced Server 検証用カスタム・アプリケーション 6-3 システム構成 今回使用したシステムの概要を図 6-1 に示します。データベースサーバーは、 p5 570 上に構成した LPAR を使用します。各 LPAR に割り当てられる CPU 数は 2、 4、8 のいずれかです。今回使用している p5 570 上には総計 16 の CPU が搭載され ているので、2CPU で区切ると 8 ノードで構成された Oracle RAC、4CPU で区切る と 4 ノードで構成された Oracle RAC、8CPU で区切ると 2 ノードで構成された Oracle RAC で検証を実施することができます。 各 LPAR からは 3 つのイーサネット・ポートを利用しています。一つはクライ アントと結ぶパブリック LAN 用に、次に Oracle RAC のノード間通信に使われる プライベート LAN 用に、そして、システム管理用のために HMC LAN が構成され ています。 各 LPAR から外部ストレージ装置(DS4800)へは、ファイバーケーブル 1 本を SAN 13 スイッチに接続しています。SAN スイッチ上では、LPAR 側のポートと、ストレ ージの各コントローラへのパスとでそれぞれゾーニングを行い、RDAC ドライバ によりコントローラの振り分けを行っています。 Client クライアント Interconnect IBM System p5 model 570 POWER5+ 2.2GHz x 16CPU 64GB DDR2 Memory 73.4GB HDD x 16 4Gbps Fibre x 16 4Port Gigabit Ether x 16 LPAR1～8 (CPU数に応じて変更) CPU : 2～8 (動的変更） Memory : CPU数×4GB 内蔵 DISK :73.4GB HDD(OS) 4GbpsFibre x 1 4Port Gigabit Ether x 1 N/Wスイッチ Bonding ×8台 Gigabit Ethernet Network N/Wスイッチ N/Wスイッチ cascade OS : RHEL4U3 Oracle Database 10gR2 N/Wスイッチ (HMC LAN用) 4Gigabit Fibre Channel SAN スイッチ HMC IBM System Storage DS4800 2controller (4GB cache) DS4000 EXP810 拡張ユニット 146GB/15K x 16 図 6-1 システム構成図 6-4 ストレージ構成 図 6-2 に外部ストレージ装置の構成図を示します。EXP810 に搭載されている 16 本の物理ドライブの内、8 本の物理ドライブを使用し、3 つの RAID Array を作 成しました。1 つ目は Oracle のデータ領域として、4 物理ドライブで RAID5 の RAID Array を構成し、その上に 20GB の論理ドライブを 10 個作成しました。2 つ目は制 御ファイル用の領域として、2 本の物理ドライブで RAID0 の RAID Array を構成し、 100MB の論理ドライブを 1 つ作成しました。3 つ目は REDO、UNDO 用の領域と して、2 本の物理ドライブで RAID0 のアレイを構成し、10GB の論理ドライブを 2 つ作成しました。作成された論理ドライブの優先パスは、DS4800 上の 2 つのコン トローラ(コントローラ A、B)それぞれに分散するように割り当てを行い、コント ローラの負荷分散を行っています。 14 LPAR 4Gigabit Fibre Channel SANスイッチ16B Controller A ControllerB 2GB cache 2GB cache 物理ドライブ：146.8GB x 32 Control用 100MB x 1個 DATA用 20GB DATA用 20GB ・ ・ ・ DS4800 (コントローラ部) EXP810 (拡張筐体部) REDO用 10GB x 8個 10個 UNDO用 10GB x 8個 DATA用 20GB RAID5 RAID0 RAID0 図 6-2 ストレージ構成図 作成された、各論理ドライブは Linux からは 1 つの物理ディスクとして認識さ れます。これらを Oracle の自動ストレージ管理（Automatic Storage Management： ASM）を利用して、以下のディスクグループを作成しました。 論理ドライブ名 OS 上デバイス名 RAW デバイス名 所属ディスクグループ 用途 DATA01～20 /dev/sdb～sdu /dev/raw/raw1～20 DATA データ用 CONTROL01 /dev/sdv /dev/raw/raw21 RAC_CONTROL 制御ファイル用 REDO01～-08 /dev/sdz /dev/raw/raw25～32 RAC_REDO01～08 REDO 用 UNDO01～08 /dev/sdaa /dev/raw/raw33～40 RAC_UNDO01～08 UNDO 用 データ領域と制御ファイルを格納するディスク・グループの設計は、「大規模 SMP 検証[2]」と同様です。本検証ではシングル・データベースから Oracle RAC 環境へ移行するため、Oracle RAC の各インスタンスごとの REDO 領域と UNDO 領域を作成しています。I/O 競合による性能差が発生することを避けるために、イ ンスタンスごとに REDO と UNDO の I/O が分散されるよう、それぞれ別の物理デ ィスクにディスク・グループを割り当てています。 15 6-5 検証プログラム データベースに対して負荷をかけるアプリケーションは、カスタム・アプリケ ーション（日本オラクル社作成）を利用しています。このアプリケーションは Java 言語で記述され、Oracle JDBC OCI Driver 10g を利用して Oracle インスタンスに接 続します。接続する同時セッション数、SQL を実行する間隔(Think Time)を調整し て任意の SQL を実行することが可能で、SQL 実行後のスループットとレスポンス タイムを計測することができます。 データベース・スキーマと SQL、は Web ショッピングサイトを想定した汎用的 な OLTP 処理を実装しました。今回の検証では、Spring Framework[1]で提供されて いるサンプルアプリケーションの JPetStore を利用しています。データベース・ス キーマは、JPetStore で提供されているスクリプトを利用して作成しています。そ して、JPetStore で実行されるアクセスパターンとその SQL を上記のカスタム・ア プリケーションを使って再現させています。 JPetStore のスキーマを利用したことには二つの意図があります。一つ目は、ベ ンチマークに特化したアプリケーションではなく、一般的に使われる SQL を使う ということです。JPetStore は J2EE アプリケーションで、データベース・スキーマ は Oracle に特化して設計されていない汎用的なものです。このようなスキーマを 利用することで、よりリアルなアプリケーションを使った性能検証を行うことを 目的としています。二つ目は、今後アプリケーション・サーバー層を含めた 3 階 層アーキテクチャでの性能試験を見据えていることです。3 階層アーキテクチャ での試験でも、JPetStore を含めた一般的な Web アプリケーションを使用したいと 考えています。また、データベース単体での性能情報を取得することで、データ ベース・レイヤーでの性能特性をあらかじめ把握することも目的としています。 6-6 データベース・スキーマ JPetStore で提供されているサンプル・スキーマ作成スクリプトを修正し、次の とおり、いくつかのテーブル・サイズを増加させています。 テーブル名 件数 サイズ 概要 ACCOUNT 1,000,000 133MB SIGNON 1,000,000 30MB ユーザーID とパスワードを格納 PROFILE 1,000,000 38MB プロフィール表。ユーザーの設定情報を格納。 160,000,000 15.8GB PRODUCT アカウント表。ユーザー情報を格納。 商品表。商品 ID、商品名、概要等を格納。 16 ITEM 800,000,000 42.0GB 商品 ID に紐づいた項目で、注文で選択される もの。アイテム ID 等を格納。 INVENTORY 800,000,000 19.1GB 在庫管理表。商品アイテム ID に紐づいて、そ れぞれのアイテムの在庫数を格納。 それぞれのテーブルに作成された索引のサイズは以下のとおりです。 テーブル名 索引名 ACCOUNT PK_ACCOUNT 39MB 主キー用索引 SIGNON PK_SIGNON 39MB 主キー用索引 PROFILE PK_PROFILE 39MB 主キー用索引 PRODUCT PK_PRODUCT 136MB 主キー用索引 PRODUCT_NAME 4.6GB PRODUCT_DESCN 13.2GB PRODUCT_CATEGORY ITEM INVENTORY サイズ 3.3GB 概要 商品名(商品検索用) 商品概要(商品検索用) 商品カテゴリー(商品検索用) PK_ITEM 20.5GB 主キー用索引 ITEMPROD 23.1GB PRODUCTID 列 PK_INVENTORY 20.5GB 主キー用索引 トランザクションが発生すると、以下のテーブルに注文データが挿入されます。 今回利用したアプリケーションは、トランザクションごとに、以下の表に示すテ ーブルにそれぞれ 1 行ずつデータを挿入します。 テーブル名 概要 ORDERS 注文データの元表。注文 ID、注文者情報等を管理。 ORDERSTATUS 注文日時、注文状況を管理。 LINEITEM 注文数や注文単価を管理。 6-7 処理概要 JPetStore は、Web ショッピングを想定した J2EE Web アプリケーションです。 あるユーザーがサイト上で商品を検索し、特定の商品を選択し商品カートに追加 します。その後注文を確定します。具体的には以下のシナリオでアプリケーショ ンを作成しています。 17 ①ユーザー・サインオン 任意のユーザーID をランダムに選択し、ユーザー情報を検索。 select … from account, profile, signon where account.userid=? and signon.password = ? and …; ②商品検索 ランダムに商品検索用のキーワードを生成し、商品を検索。検索結果が平均で 100 件になるように調整。 select … from category where catid = ?; select … from product where(lower(name) like ?); ③商品選択 検索してヒットした商品の中から一つのアイテムを選択。 select … from item, product where i.itemid = ? and … ④在庫数チェック 選択したアイテムの在庫数をチェック。 select … from inventory where itemid = ? ⑤注文 指定した商品の注文データを発行。 insert into orders …; insert into orderstatus …; insert into lineitem …; 注文した商品アイテムを在庫管理表から注文数の在庫数を減らす。 Update inventory set qty=qty-1 where itemid = ?; ⑥注文確定 commit; 上記で特筆すべきことは、単一行検索だけではなく、「②商品検索」にあるよう に 100 件のデータをフェッチするような複数行検索を含んでいることです。また、 更新文も INSERT 文が 3 つ、UPDATE 文が 1 つで構成されており、トランザクシ ョンとしては適度な重さであるといえます。 18 6-8 使用パラメーター 本検証では、「大規模 SMP 検証[2]」の結果からいくつかのパラメータを流用し ています。 CPU 数・ノード数 本検証で使用している IBM System p に搭載されている総 CPU 数は 16 です。こ れを、LPAR の機能を使用して複数の LPAR に分割します。分割された LPAR の数 が Oracle RAC におけるノード数となります。 今回使用した CPU 数とノード数の組み合わせは以下のとおりです。 ノードあたり CPU 数とノード数の組み合わせにおける総 CPU 数の関係 ノード数 ノードあたり CPU 数 2 ノードあたり CPU 数 4 ノードあたり CPU 数 8 1 2 CPU 4 CPU 8 CPU 2 4 CPU 8 CPU 16 CPU 4 8 CPU 16 CPU 8 16 CPU メモリーサイズ 割り当てられる物理的なメモリーサイズは、分割する LPAR 数に依存していま す。本検証で使用している IBM System p5 に搭載されているメモリー量は 64GB で、 これを LPAR の数に割ります。Oracle インスタンスに割り当てられる SGA サイズ は、物理メモリーの半分としました。 LPAR 数と LPAR あたりの割り当てられるメモリーサイズの関係は以下のとお りです。 分割 LPAR 数 LPAR あたり CPU 数 LPAR あたりメモリーサイズ LPAR あたり SGA サイズ 2 LPAR 8 CPU 32 GB 16 GB 4 LPAR 4 CPU 16 GB 8 GB 8 LPAR 2 CPU 8 GB 4 GB 同時接続プロセス数 「大規模 SMP 検証[2]」では、思考時間（Think Time）が 0ms と 250ms の 2 パタ ーンで計測を行いました。Oracle RAC 検証においても、この思考時間を使用して います。 19 また、それぞれの思考時間を設定した際に、データベース・サーバーに対して CPU リソースを使い切ることのできる同時接続数は、思考時間が 0ms の場合 1CPU あたり 8 同時接続プロセス数となります。例えば、ノードあたりの CPU 数が 2CPU の場合、1 ノードあたりは 16 同時接続プロセスの負荷がクライアントからかけら れます。同様に思考時間が 250ms の場合は 1CPU あたり 80 同時接続プロセス数と なります。これらの関係を以下にまとめます。 1CPU あたり 8 同時接続プロセスにおけるノードごとの同時接続プロセス数 ノード数 ノードあたり CPU 数 2 ノードあたり CPU 数 4 ノードあたり CPU 数 8 1 16 32 64 2 32 64 128 4 64 128 8 128 1CPU あたり 80 同時接続プロセスにおけるノードごとの同時接続プロセス数 ノード数 ノードあたり CPU 数 2 ノードあたり CPU 数 4 ノードあたり CPU 数 8 1 160 320 640 2 320 640 1,280 4 640 1,280 8 1,280 6-9 サービス構成 グリッド環境では多くのリソースをアプリケーションから見たときに仮想的な 一つのコンピュータとして使用することができ、サービスという概念によって論 理的に分割することができます。論理的に分割されたそれぞれのサービスは、物 理的には別のマシンリソースを利用することも同じマシンリソースを利用するこ ともできます。運用性や管理の容易性を重要視するのであれば全てのサービスが 同じリソースを利用するように構成し、性能に重点を置くのであればあるサービ スとそのサービスを稼動させるリソースを意識した構成を行います。Oracle GRID では、グリッド内のリソースを自動的に効率よく管理させることができるため、 これらは決してトレードオフとなる選択肢であるわけではありません。 本検証では、次の２つの理由により、１つのノード上に１つのサービスを稼動 20 させる構成を採用しました。 Oracle RAC のスケーラビリティを確認するための性能試験であること システム統合などのシナリオを想定した、多サービス構成であること 最大 8 ノードの構成において、それぞれのノードに次のサービスを定義しまし た。 ノード＃ サービス名 1 IBMLOP1 2 IBMLOP2 3 IBMLOP3 4 IBMLOP4 5 IBMLOP5 6 IBMLOP6 7 IBMLOP7 8 IBMLOP8 また、JPetStore の表のうち、PRODUCT、ITEM、INVENTORY、ORDERS、 ORDERSTATUS、LINEITEM 表は Oracle Database の機能であるレンジ・パーティ ショニングを適用し、それぞれの表を 8 つのパーティションに分割しています。 さらに、それぞれのパーティションとサービスが対応するようにクライアントを 構成しています。例えば、クライアントからサービス”IBMLOP1”に接続した場 合には、それぞれの表の 1 つ目のパーティニングのデータをアクセスします。ク ライアントからサービス”IBMLOP5”に接続した場合には、それぞれの表の 5 つ 目のパーティニングのデータをアクセスします。 21 7. 検証結果 次より、Oracle RAC を IBM System p5 上で稼動させた際の性能検証結果につい て報告します。 7.1 コネクション・プーリング想定構成 クライアントから負荷をかける思考時間(Think Time)を 0ms とし、クライアント からは待機することなくデータベースに対してトランザクションを発行し続けま す。思考時間としての待機がないため、データベースに対しては少ない接続数で CPU リソースを最大限まで使用させることができます。アプリケーション・サー バーのコネクション・プーリング等のように、データベースに対する物理的接続 を制限した構成で効率よく負荷がかかるシステムを想定した検証です。 本検証では、「大規模 SMP 検証[2]」の結果から思考時間 0ms における最適同時 接続プロセス数を CPU あたり 8 としています。最適同時接続プロセス数とは、デ ータベース・サーバーに対して最も高いスループットと安定したレスポンス・タ イムを出すことのできるクライアントからの負荷量を意味します。 9.00 9.00 8.00 7.80 スループット比 レスポンスタイム比 8.00 7.00 7.00 6.00 6.00 5.00 5.00 3.90 4.00 4.00 3.00 3.00 1.95 2.00 1.00 1.00 1.00 2.00 1.02 1.02 1.11 1.00 0.00 0.00 1ノード 2ノード 4ノード 8ノード 図 7-1 Oracle RAC スケーラビリティ検証結果スループット (思考時間 0ms) 22 図 7-1 のグラフより、1 ノードにおけるスループットを 1.00 としたときの 2 ノ ードにおけるスループットは 1.95、4 ノードにおけるスループットは 3.90、8 ノー ドにおけるスループットは 7.80 となりました。この結果は、Oracle RAC の高い拡 張性を示しており、増加するノード数に比例してスループットが向上することが 確認されました。 1 ノードのスループットと比べて 2 ノードのスループットが 0.05 下がった点は、 シングル環境からクラスタ環境へと環境が変わったことによるオーバーヘッドと 考えられます。しかし、2 ノード以降のスループットの向上はノード数の増加数 と完全に比例しています。8 ノードのスループット 7.80 は、2 ノードのスループ ット 1.95 の 4.00 倍となっており、非常に高い拡張性であることが示されています。 本検証では最大 8 ノードの試験まで実施していますが、更にノードを追加するこ とで性能を拡張できることが期待される結果となりました。 また、ノード数とスループットおよびレスポンスタイムの関係に着目すると、 ノード数の増加に従ってスループットが向上していきますが、レスポンスタイム はノード数に依存せず一定に推移していることを示しています。この結果は、 Oracle GRID においてリソースを増加させた際にそれまでと変わらぬサービス・レ スポンスを提供することができることを意味します。 7.2 大量接続想定構成 クライアントから発行されるトランザクションに思考時間を設定した検証です。 思考時間を 250ms とし、トランザクションを発行するたびに待機します。クライ アントからの一つあたりの接続がデータベースにかける負荷は「7-1 コネクショ ン・プーリング想定構成」よりも低くなりますが、その分多くの接続により負荷 をかけることができます。 なお、250ms という思考時間は現実世界を考えると非常に短いものですが、本 環境においては、物理メモリーの半分を Oracle のシステム・グローバル領域（SGA） として確保し、残りのメモリー領域を使い切らない程度に接続できる最大接続数 を決定し、その接続数で CPU リソースを使い切るように調整した結果として 250ms という思考時間を選択しました。 以下に、本検証の結果を示します。 23 14 12.31 80プロセス / ノード 12 11.46 スループット比 120プロセス / ノード 10 160プロセス / ノード 7.93 8 6.11 6 5.73 3.10 4 2 0 0 3.97 2.87 1.99 1.82 1.49 1.00 2 4 6 8 10 ノード数 図 7-3 Oracle RAC スケーラビリティ検証結果スループット(思考時間 250ms) 図 7-3 のグラフは、1 ノードあたりの同時接続プロセス数が 80 における 1 ノー ド上でのスループットを 1.00 としたときの各テストパターンのスループットの比 較を示しています。本環境においては、1 ノードあたりの同時接続プロセス数が 80 のときのデータベースサーバーの平均 CPU 使用率は約 50%、1 ノードあたりの 同時接続プロセス数が 120 では約 80%、そして 1 ノードあたりの同時接続プロセ ス数が 160 では約 100%でした。従って、上記結果からは、CPU リソースに約半 分の空きがある条件から CPU リソースに全く余裕がないときまでの性能の推移を 比較することができます。どのパターンにおいても、ノード数の増加に比例して スループットが向上することが確認できます。 それぞれのパターンでの、クライアントからデータベースへの総同時接続プロ セス数の関係は以下のとおりです。 ノード数 ノ ー ド あ た り同時接続 ノードあたり同時接続 ノードあたり同時接続 プロセス数 80 プロセス数 120 プロセス数 160 1 80 120 160 2 160 240 320 4 320 480 640 8 640 960 1,280 24 7.3 SCN 伝播スキーム 「7.1」および「7.2」までの検証結果は、Oracle RAC における SCN 伝播スキー ムを Lamport 方式に設定していました。Lamport 方式とは、他インスタンスへのト ランザクションの実行と SCN の伝播が非同期で行われる方式で、Oracle RAC 10g Release1 までデフォルトで選択される方式でした。トランザクションのコミット が発行されると、Oracle インスタンスは自身の管理する SCN を増加させます。 Lamport 方式では、コミット時にインスタンス間の SCN の同期をとりません。し かし、SCN は Oracle インスタンス間の全てのメッセージに含まれているため、多 くの場合では SCN 伝播が遅れるという問題にはなりません。Oracle インスタンス が何もしていない場合はインスタンス間通信が発生しないため、最大 3 秒の遅延 で SCN の同期が行われます。 Oracle RAC では、Oracle インスタンス間での SCN の同期をコミット時にも行う Broadcast on Commit 方式を選択できます。これは Oracle RAC 10g Release2 でのデ フォルトの方式です。Broadcast on Commit 方式では、コミット時に Oracle インス タンス間で SCN を同期するため、Lamport 方式で説明した問題は発生しません。 ただし、コミット時に SCN の同期をとるオーバーヘッドが多少発生します。以下 では SCN 伝播スキームを Lamport 方式から Broadcast on Commit 方式に変更した際 の検証結果を示します。 8 7 6.13 スループット比 6 5 4 3.47 3 2 1.90 1 1.00 0 0 2 4 6 8 10 ノード数 図 7-4 コネクション・プーリング想定構成におけるスケーラビリティ検証結果 （思考時間 0ms、ノードあたり同時接続プロセス数 16、Broadcast on Commit 方式） 25 図 7-4 の結果は、SCN 伝播方式として Broadcast on Commit 方式を選択した際の スループットの推移を示したものです。1 ノードにおけるスループットを 1.00 と したときの 2 ノードにおけるスループットは 1.90、4 ノードにおけるスループッ トは 3.47、8 ノードにおけるスループットは 6.13 となりました。以上から、ノー ド数が増加するに従ってスループットが向上することが示されましたが、Lamport 方式を選択した際のスループットの推移と比較するとその値は低くなっており、 Broadcast on Commit 方式におけるオーバーヘッドとして現れています。 次に、ノードあたりの同時接続プロセス数が多いパターンでの検証結果を示し ます。 14 12 スループット 10 80プロセス / ノード 12.18 120プロセス / ノード 11.06 160プロセス / ノード 7.89 8 6.57 6 5.75 3.48 4 2 0 0 3.98 2.93 1.98 1.84 1.48 1.00 2 4 6 8 10 ノード数 図 7-5 大量接続型構成におけるスケーラビリティ検証結果 （思考時間 250ms、ノードあたり同時接続プロセス数 80/120/160、 Broadcast on Commit 方式） 図 7-5 のグラフは、1 ノードあたりの同時接続プロセス数が 80 における 1 ノー ド上でのスループットを 1.00 としたときの各テストパターンのスループットの比 較を示しています。本検証結果は、コネクション・プーリング想定構成での検証 結果と比べて、Lamport 方式とのスループットの差があまりありませんでした。特 に、平均 CPU 使用率が 50%程度の 1 ノードあたり同時接続プロセス数が 80 のパ 26 ターンでは、1 ノード上でのスループットを 1.00 としたときの 8 ノード上でのス ループットは 7.89 と非常に高いものとなりました。さらに、1 ノードあたり同時 接続プロセス数 120、160 においてもノード数が増加するごとにスループットが向 上しており、非常に高いスケーラビリティを示しています。 コネクション・プーリング型の検証結果と比較すると、大量接続型の構成にお いては Broadcast on Commit 方式におけるオーバーヘッドが緩和されているように 見受けられます。これらは、Oracle RAC がとりわけ多数の接続から大量トランザ クションをさばかなければならないシチュエーションにおいて真価を発揮するも のであると言えます。なぜ、大量接続型においてはオーバーヘッドが大きくなら ないのかについては、SCN を伝播するノード間のメッセージ数を比較することで 説明できます。 次のグラフは、2 ノード、4 ノード、8 ノード構成における Lamport 方式と Broadcast on Commit 方式での 1 ノードあたりの GCS/GES メッセージ数を比較したものです。 GCS とは Global Cache Service、GES とは Global Enqueue Service の略で、これらを 合わせてインスタンス間でやり取りされるメッセージ数を意味します。 12 GCS/GESメッセージ数 比率 10 16プロセス/ノード 80プロセス/ノード 120プロセス/ノード 160プロセス/ノード 8 6 4 2 0 2ノード Lamport 2ノード Broadcast on Commit 4ノード Lamport 4ノード Broadcast on Commit 8ノード Lamport 8ノード Broadcast on Commit 図 7-6 GCS/GES メッセージ数の比較 27 図 7-6 のグラフは、Broadcast on Commit 方式での 1 ノードあたり同時接続プロ セス数 80 の 2 ノードにおけるメッセージ数を 1.00 としたときのそれぞれのメッ セージ数の比率を表しています。メッセージ数は、それぞれのテストパターンに おいて、計測期間中の Statspack レポートより「Global Cache Load Profile」セクシ ョンの「GCS/GES messages received」と「GCS/GES messages sent」の値を合計した ものです。 まずグラフから確認できるのは、2 ノード、4 ノード、8 ノード構成におけるど のテストパターンでも、Broadcast on Commit 方式と比べて Lamport 方式の方がメ ッセージ数が少ない点です。Broadcast on Commit 方式ではトランザクションが完 了するタイミングでリアルタイムに SCN を伝播するのに対して、Lamport 方式で はそれよりは長い期間で非同期に SCN を伝播するため、その差がメッセージ数の 違いとして現れています。なお、GCS/GES メッセージ数のうち、SCN 伝播におけ るメッセージ数については統計情報の「acks for commit broadcast(actual)」および 「broadcast msgs on commit(actual)」から確認することができます。 次に、Broadcast on Commit 方式におけるメッセージ数に注目します。まず、1 ノードあたりの同時接続プロセス数 16 の場合が最もメッセージ数が多くなって おり、次いで 1 ノードあたりの同時接続プロセス数 120、80、160 の順に少なくな っています。1 ノードあたりの同時接続プロセス数が増加するに従いスループッ トが向上しているのに対して、メッセージ数は 1 ノードあたりの同時接続プロセ ス数が 80、120 までは増加していますが 160 では減少しています。このことは、 スループット、つまりデータベースに対する負荷や、もしくは同時接続プロセス 数と SCN 伝播のメッセージ数が比例関係にないことを示しています。以上から、 Oracle RAC では SCN を伝播する際に、同じタイミングで完了しているトランザク ションがあれば、まとめて一つのメッセージで SCN を伝播していることがわかり ます。このような効率よい動作が実装されていることにより、高負荷時において も安定したパフォーマンスを実現することができると考えられます。 7.4 Oracle GRID & IBM 仮想化技術検証 これまでの検証結果は、Oracle RAC における性能検証のものでした。IBM System p のハードウェア機能の一つである LPAR を使用すると、各ノード上で実行される OS の使用する CPU 数を柔軟に変更することが可能です。 Oracle のグリッド基盤である Oracle RAC と IBM の仮想化機能の一つである LPAR を組み合わせることで、負荷の増大に対応するための選択肢として、ノード を追加していくスケールアウトとノードあたりの CPU を追加するスケールアップ の両方を組み合わせることができます。これは、顧客からの要求に対する対応の 28 柔軟性が高まることを意味します。 以下では、Oracle RAC と LPAR を組み合わせたときの性能の推移について説明 します。 7.4.1 Oracle RAC と SMP 環境の組み合わせ 9 2CPU×Nノード 8 4CPU×Nノード スループット比 7 8CPU×Nノード 6 5 4 3 2 1 0 0 2 4 6 8 10 12 14 16 18 総CPU数 図 7-7 CPU 数の違うノードの RAC スケーラビリティ比較 (思考時間 0ms、Lamport 方式) 図 7-7 のグラフは、1 ノードあたりの CPU 数を 2、4、8 と変えたときの、それ ぞれの総 CPU 数を軸としたときのスループットを比較したものです。1 ノードあ たりの CPU 数と、ノード数における総 CPU 数の関係は以下の表のとおりです。 例えば、1 ノードあたりの CPU 数 4 における 2 ノード時のスループットは、総 CPU 数 8 の値を見て確認できます。 1 ノード 1 ノードあたりの 2 ノード 4 ノード 8 ノード 2 4 8 16 4 8 16 － CPU 数 2 1 ノードあたりの CPU 数 4 29 1 ノードあたりの 8 16 － － CPU 数 8 それぞれ、1 ノードあたりの CPU 数 2 における 1 ノード上(総 CPU 数 2)でのス ループットを 1.00 としたときのスループットの比率を表しています。 図 7-7 のグラフを見ると、1 ノードあたり 2CPU 構成 Oracle RAC、4CPU 構成 Oracle RAC、8CPU 構成 Oracle RAC の 3 本の線がどれもほとんど重なっているこ とが確認できます。これは、どのノード構成であっても総 CPU 数が同じ環境であ ればほぼ同じスループットが出ていたことを示しています。例えば、総 CPU 数が 16 の値について見てみると、1 ノードあたりの CPU 数 2 で総 CPU 数が 16 という ことは、このときのノード構成は 2CPU×8 ノードです。同様に、1 ノードあたり の CPU 数 4 の場合には 4CPU×4 ノード、1 ノードあたりの CPU 数 8 の場合には 8CPU×2 ノードとなります。これらの構成におけるスループットがほぼ同等であ ったという点より、Oracle RAC がノード数や CPU 数の組み合わせに依存すること なく、全ての CPU リソースを有効に使うことができることが示された結果となり ました。 7.4.2 CPU 数の違う混合 RAC 構成 「7.4.1 Oracle RAC と SMP 環境の組み合わせ」検証結果より、Oracle のグリッ ド環境において、IBM System p の LPAR と組み合わせることにより、スケールア ウトとスケールアップの両面で適用可能な高い柔軟性を実証しました。 従来、Linux の分野においては、UNIX の分野と比較するとハードウェアに搭載 される CPU 数が比較的低いものが主流であったため、負荷の増大に対応するため にはスケールアウトによるノードの拡張を採用することが一般的で、Oracle RAC によるノード追加と高い親和性がありました。しかし、ハードウェアとして IBM System p を選択することにより、大規模な SMP を Linux で構築することができま す。そのため、Linux において大規模 SMP とグリッドを組み合わせることも選択 肢の一つとなります。 通常、Oracle のグリッドではハードウェア・リソースが仮想化され、その上で 稼動するサービスへのリソース割り当てを動的に変更することが可能ですが、要 件によっては、この割り当てを静的に固定化したいことがあるかもしれません。 例えばあるサービスはノード A に固定化したいが CPU 数は 8 必要で、別のサービ スはノード B に固定化したいが CPU 数は 2 で足りるという場面です。 次の検証では、CPU 数の異なるノードを組み合わせた RAC 構成における性能 30 の推移を示します。 10 ノード8 8 スループット比 ノード7 ノード6 6 ノード5 ノード4 4 ノード3 ノード2 2 ノード1 0 2CPU×8ノード 2CPU,2CPU,4CPU,8CPU 4ノード 図 7-8 CPU 数の違うノードの RAC スケーラビリティ比較 (思考時間 0ms、Lamport 方式) 図 7-8 のグラフは、1 ノードあたり 2CPU 構成 RAC の 8 ノード時のスループッ トと、2CPU・2CPU・4CPU・8CPU のノードで構成された 4 ノード時のスループ ットを比較したものです。それぞれ積み上げグラフとなっており、グラフを構成 している棒がそれぞれのノードのスループットを表しています。スループットは 比率で表されており、2CPU×8 ノードにおける 1 ノード目のスループットを 1.00 としています。 それぞれの結果は、どちらも総 CPU 数が 16 の時のものです。そして、「7.4.1 Oracle RAC と SMP 環境の組み合わせ」検証の結果と同様に、CPU 数が異なるノ ードが混在している環境においても、2CPU×8 ノードと全く同じ性能が出る結果 となりました。 CPU 数の違うハードウェアによる Oracle RAC が、安定してスループットを提供 できるということは、Oracle RAC がグリッド環境での最適なプロダクトであるこ とを示唆します。グリッド環境では、複数のリソースを仮想的にプールされたリ 31 ソースとして見せることができますが、組み合わせるそれぞれの物理的なリソー スはスペックが全く同等でない可能性があります。例えば、すでに構築したグリ ッド環境を増強させるために、既存のハードウェアよりもスペックの良い最新の ハードウェアを新たに追加することがあるかもしれません。その場合にも、Oracle RAC を利用することで、新たに追加するハードウェアのスペックを最大限に使う ことができ、非常に柔軟な構成を採用できることが示されています。 32 8. まとめ 本検証により、System p 上における Oracle RAC の高いスケーラビリティを実証 しました。これは、小さいシステムから始めて、負荷の増大に合わせてシステム を大きくしていくことができることを示しています。 そして、Oracle RAC と IBM System p により、スケールアップによる性能向上と スケールアウトによる拡張性・可用性の向上を、要件に合わせて柔軟に組み合わ せることが可能であることを確認しました。特に Linux の分野においては大規模 な SMP を構成しても高い信頼性と性能を得られるのが IBM System p の大きな特 徴です。このメリットを活かしながら、さらに Oracle RAC の導入により、冗長性 とハードウェアの制限を越えた性能向上が可能となります。 グリッド・コンピューティングは、これからの IT 社会を支える非常に重要な技 術の一つです。グリッド技術は登場から既に何年もの年月が経過し、一般的認知 度が向上し、製品も成熟してきています。これまでは特定の分野に使われていた グリッド技術も、今は正に一般に使われようとしています。 特に、システム統合という形で複数のシステムを効率よく稼動させるためには、 グリッド技術は非常に有効です。リソースをプールして有効活用するという仕組 みは、複数のシステムを稼動させる上で威力を発揮します。本検証を通じて、グ リッド技術の実現性と、Oracle RAC と IBM System p の選択が性能面でも大きなメ リットがあることが実証されました。 今後、日本アイ・ビー・エム株式会社と日本オラクル株式会社は、Oracle Application Server 10g を活用し、ミドルウェア層までを含めたシステム基盤のグリ ッド化による検証を実施します。この検証結果を通じて、将来的にはデータベー ス層からアプリケーション層までのリソースをプールして柔軟に活用できるよう になることを実証する予定です。 33 9. 付録 9-1 Oracle Database 初期化パラメータ 本検証で設定された Oracle 初期化パラメータは以下のとおりです。 _gc_affinity_time _gc_undo_affinity _immediate_commit_propagation _in_memory_undo audit_file_dest background_dump_dest cluster_database cluster_database_instances compatible control_files core_dump_dest db_block_size db_create_file_dest db_domain db_file_multiblock_read_count db_name instance_number job_queue_processes open_cursors processes remote_login_passwordfile service_names sessions sga_max_size sga_target spfile undo_management undo_tablespace user_dump_dest 0 FALSE FALSE FALSE /opt/oracle/admin/ibmlop/adump /opt/oracle/admin/ibmlop/bdump TRUE 8 10.2.0.1.0 +DATA/ibmlop/controlfile/current. /opt/oracle/admin/ibmlop/cdump 8192 +DATA jp.oracle.com 16 ibmlop 1 10 1000 2000 EXCLUSIVE ibmlop.jp.oracle.com, ibmlop1 2205 4G 4G +DATA/ibmlop/spfileibmlop.ora AUTO UNDOTBS1 /opt/oracle/admin/ibmlop/udump 上記は、1 ノードあたり 2CPU 構成における RAC での設定です。sga_max_size および sga_target の値は CPU 構成に依存して変更しています（「6-8 使用パラメー ター」参照）。 _immediate_commit_propagation は、SCN 伝播スキームを Lamport 方式にするた めの設定です。Broadcast on Commit 方式の試験ではこのパラメータを使用しませ ん。 undo_tablespace は イ ン ス タ ン ス ご と に 別 の UNDO 表 領 域 (UNDOTBS1 ～ UNDOTBS8)を指定しています。 34 参考 URL [1] Spring Framework http://www.springframework.org [2]「大規模 Linux システムにおける Oracle Database 10g on IBM System p5 の性能」 http://www-06.ibm.com/systems/jp/p/solutions/oracle/img/whitepaper.pdf 35 日本オラクル株式会社 Copyright © 2007 Oracle Corporation Japan. All Rights Reserved. 無断転載を禁ず この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されるこ とがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、 本書の内容に関連したいかなる損害についても責任を負いかねます。 Oracle は米国 Oracle Corporation の登録商標です。文中に参照されている各製品名及び サービス名は米国 Oracle Corporation の商標または登録商標です。その他の製品名及びサ ービス名はそれぞれの所有者の商標または登録商標の可能性があります。 36