IBM Power Systems™ 上での Oracle
Data Guard SQL 適用における性能検証
Maximum Availability Architecture (MAA)
ベスト・プラクティスの適用
Creation Date: Feb 10, 2009
はじめに
近年、IT システムに求められる可用性はますます高くなる一方、ミッションクリティカ ルなシステムは、オープン環境へダウンサイジングを行うシステムが急速に増えています このような非常に高い可用性を求められるシステムでは、様々な高可用性テクノロジー を組み合わせることで複雑なアーキテクチャになってしまうことが問題となっています。 Oracle 社では、このようなシステムのインフラ設計をする際のベスト・プラクティスと して Maximum Availability Architecture(MAA)のブループリントを提供しています。 MAA では高可用性システムを設計する際の複雑さや憶測を排除した実証済みのアーキテ クチャを提供することで、より低コストで可用性の高いシステムを実現します。同様に、IBMのUNIXTMサーバー、IBM Power Systemsは優れた拡張性・柔軟性・信頼
性を持ち、Oracle Database 及びMAAのベスト・プラクティスに基づいた環境をPower Systems上に構築することで可用性に優れたシステムを構築することが可能です。
Oracle Data Guard (Data Guard)は、MAA のキーコンポーネントです。Data Guard は
本番データベースに対して 1 つ以上のスタンバイ・データベースを構築し、データを保護
します。これによってシステムの計画停止/計画害停止時のダウンタイムを最小限にします。 本検証では、IBM Power Systems 上に Data Guard のロジカル・スタンバイを構築した 環境で基本性能を測定し、計画停止を想定した本番と待機システムを切り替える時間や障 害が発生した場合に待機システムを本番システムに昇格する時間を極小化するための最適 な構成を評価しました。
目次
はじめに...2 目次...3 Executive Summary ...5 ロジカル・スタンバイの基礎検証...5 データベースの切り替え時間...5 検証環境...6 H/W構成の概要...7 DB構成の概要...7 OS...7 共有ディスク...7 DB ...8 負荷アプリについて...8 表と索引の構成...8 検証項目...9 チューニングの実施前と後の環境...9 ロジカル・スタンバイの基本性能検証...9 適用の遅延...9 SQL適用の最大適用性能 ... 10 ロジカル・スタンバイの切り替え処理... 10 切り替え時間の定義... 10 チューニング・ポイント... 11 検証結果... 11 ロジカル・スタンバイの基本性能検証... 11 適用の遅延... 11 SQL適用の最大適用性能 ... 13 ロールの切り替え... 15 総括... 15 スイッチオーバー/フェイルオーバーの切り替え時間 ... 15 スイッチオーバーにおける切り替え時間... 15 フェイルオーバーの切り替え時間... 15 β環境の考察... 16 負荷量の違いによる切り替え時間への影響... 17 SQL適用におけるベスト・プラクティス ... 18 補足事項... 19 スタンバイREDOログの設計指針 ... 19まとめ... 20 謝辞... 21 補足 – 試験環境詳細... 22 H/W構成... 22 マシン情報... 22 ストレージ... 23 ネットワーク... 23 OS (AIX)関連 ... 23 nmon ... 23 参考資料... 24 マニュアル：Oracle Database ... 24 高可用性関連マニュアル... 24
Oracle MAA Best Practices ... 24
Data Guard 構築関連ベスト・プラクティス ... 24
Data Guard スイッチオーバー／フェイルオーバー関連ベスト・プラクティス.... 24
Data Guard 転送／適用パフォーマンス関連ベスト・プラクティス ... 24
Real Application Clusters関連ベスト・プラクティス ... 24
Executive Summary
本検証の結果、IBM®のUNIXオペレーティングシステムAIXTMを稼動するIBM Power
Systems上に構築された Oracle Database 10g Release 2 (10.2.0.3)での Oracle Real Application Clusters (以降 RAC)とData Guard (以降 DG)の構成は、柔軟でかつ高い可用 性を提供できる構成であることを確認しました。 また、MAA のベスト・プラクティスと今回の検証で確認したチューニングを適用するこ とで、切り替え時間を極小化できることを確認しました。具体的に確認した内容は以下で す。 1. 9MB/s の SQL 性能 2. プライマリ・データベースの REDO はロジカル・スタンバイに 1 秒以内で適用され 参照可能 3. 1 秒以内でのフェイルオーバーが可能 4. 5 秒以内でのスイッチオーバーが可能
ロジカル・スタンバイの基礎検証
本検証の環境では本番システムから毎秒 5MBのREDOが生成される環境でも待 機システムには更新データを 1 秒以内に適用され、ロジカル・スタンバイから参 照可能であることを確認しました。 このことにより、切り替えの作業を迅速に行うことが可能になります。 本検証環境のロジカル・スタンバイでは最大で 9MB/secのSQL適用を実行でき ることを確認しました。これは本番システムが一時的に高負荷な状態になっても、 待機システムは短期間で本番システムと同期できることを示しています。また、 待機システムではREDOを適用するインスタンスにCPUリソースを動的に割り当 てるIBM Power Systems の仮想化機能（Power VM™ ）であるダイナミックLPAR（動 的論理区画）機能を利用することで、更なる適用性能の向上が望めます。データベースの切り替え時間
計画停止を想定した本番システムと待機システムの切り替えを行うスイッチオ ーバーの実行時間はチューニングによって最短で 5 秒以内に実行できることを確 認しました。また、本番システムで障害が発生した際には待機システムを本番シ ステムへ昇格するフェイルオーバーの実行時間は 1 秒未満で実行できることを確 認しました。スイッチオーバーによる切替時間（単位：秒） 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 α β S->P 2.00 23.50 P->S 2.67 8.50 α β α = チューニング前の結果 β = チューニング後の結果 S->P = スタンバイからプライマリに切り替える時間 P->S プライマリからスタンバイに切り替える時間 ※ REDO生成量が512KB/secの負荷環境で3回のテストを実施した平均値
検証環境
高可用性システムを提供するために、IBM Power Systems のリソースを 4 つの論理パ
ーティションで分割し、ノード障害に備えて2 ノードの RAC を本番用システムとして構成
します。
更に障害範囲がクラスタ全体に拡大した際や計画的なメンテナンス時間を極小化するた
めに、待機システムとしてDG のロジカル・スタンバイを 2 ノードの RAC で構成します。
補足 – 試験環境詳細」の章を参照下さい。
H/W 構成の概要
サーバー ： IBM Power Systems 570 CPU = POWER5 2.2GHz 16Way
Memory = 64GB Network = 4port 1Gbps Ethernet * 16
I/O = 4Gb FC Adapter * 16 Disk = 73.4GB ULTRA320 SCSI Disk Drive * 16 drive
ストレージ ： IBM System Storage DS4800 146.8GB/15K 4Gbps FC Drive * 16drive
Primary Standby
LPAR#1 LPAR#2 LPAR#3 LPAR#4
DBF Arch DBF Arch • 4cpu 14GB mem 4cpu 14GB mem 4cpu 14GB mem 4cpu 14GB mem prm1 prm2 stb1 stb2 Workload client ASM ASM
DB 構成の概要
OS AIX 5L™ 共有ディスクOracle の Automatic Storage Management(ASM)を利用し、RAID-5(8 本)で構成され たボリュームに対してデータベース用のディスクグループを構成
ープを構成 DB Oracle Database 10g (10.2.0.3) 各インスタンスの構成 DB_CACHE_SIZE = 4GB SHARED_POOL_SIZE = 2GB LOG_BUFFER = 32MB オンラインREDOログファイル 1 = 100MB × 2 メンバー × 6 グループ × 2 スレッド スタンバイREDOログファイル 2 = 100MB × 1 メンバー × 7 グループ × 2 スレッド
負荷アプリについて
検証で使用する負荷アプリケーションは Oracle 社が検証用に作成した JDBC を 使ってデータベースに接続する Java のアプリケーションを使用します。 このアプリケーションが実行する SQL 文は 10 億件のテスト表に対して、ラン ダムな 1 行を更新する UPDATE 文とランダムな 10 万件の範囲検索を行う SELECT 文です。いずれの SQL 文も索引を使ったアクセスを行います。表と索引の構成
本検証で使用した表と索引構成を以下に示します。 SQL> desc RAC_TEST_TAB1Name Null? Type
--- --- --- EMPNO NOT NULL NUMBER(12) 主キー制約 UPDATABLE NOT NULL NUMBER(12) B*Tree索引 ENAME VARCHAR2(16)
JOB VARCHAR2(20)
SAL NUMBER(8) B*Tree索引 DEPTNO NUMBER(3)
DMY VARCHAR2(80)
GRIDCenter_SQLApply_PowerSystems_jp.doc
検証項目
ロジカル・スタンバイの基礎検証と本番(プライマリ)と待機(スタンバイ)の切り替え時間 についての検証を行います。チューニングの実施前と後の環境
本ドキュメントでは、チューニングが施される前の環境を「α環境」と呼び、 後述する切り替え時間を極小化するためのチューニングが施された環境を「β環 境」と呼ぶことにします。ロジカル・スタンバイの基本性能検証
β環境における適用の遅延（適用ラグ）と SQL 適用の最大適用性能を計測しま す。 ロジカル・スタンバイでは、スタンバイが受信した REDO を SQL 文に変換して 適用する機能を SQL 適用と呼びます。 適用の遅延 プライマリから送信された REDO がスタンバイに適用されるまでの時 間を同期転送と非同期転送で確認します。 SQL 適用の最大適用性能 スタンバイにためた未適用の REDO データを適用が完了するまでの時 間を測定することで、SQL 適用の最大適用性能を確認します。 適用の遅延 プライマリにかける負荷の量を変化させながら、プライマリで実行された更新 処理が、スタンバイでどの程度遅れて適用されているのかを確認します。 また、同期転送(LGWR SYNC 転送)と非同期転送(LGWR ASYNC 転送)において 測定を行い、その変化を確認します。 負荷の単位にはプライマリに負荷を実行するクライアントの「セッション数」 を使用し、50、100、200 と増やした際の性能変化を確認します。 遅延の測定には、別途測定用アプリケーションを使用します。遅延測定用アプ リケーションはタイムスタンプを格納する遅延測定用テーブル（1 行）を、プライ 2 プライマリのオンラインREDOのサイズ変更に合わせて1GBから100MBに変更、またグループ数を4 から7に変更マリにおいて 1 秒間隔で現在のタイムスタンプに UPDATE して、スタンバイでそ の適用を検索することによって遅延を確認します。スタンバイではリアルタイム 適用を使用しています。
SQL 適用の最大適用性能
IBM Power Systemsの仮想化機能、PowerVMTMの一つである、分割された論理パ ーティションに対してCPUリソースを動的に配分するダイナミックLPARの技術に より、スタンバイの適用インスタンスに割り当てるCPUを動的に変化させながら、 SQL適用の性能を確認します。 負荷の単位には「プライマリで１秒あたりに生成される REDO 量(MB)」を使用 します。 以下の手順で検証を実施します。 1. スタンバイで SQL 適用を停止 2. プライマリ側で負荷処理を 5 分間実行し、スタンバイで未適用の REDO を ため込む 3. ため込まれた REDO 量が一定であることを確認 4. スタンバイの SQL 適用を再開し、適用が完了するまでの処理性能を計測 適用した REDO の量と適用にかかった時間を計測し、1 秒間に適用した REDO の量を導出します。
ロジカル・スタンバイの切り替え処理
計画停止時に行うスイッチオーバーとプライマリで障害が発生した際に行うフ ェイルオーバーの実行時間を測定します。 切り替え時間の定義 本検証における切り替え時間とは、「システム内でプライマリ・データベースが 存在しない時間」と定義します。 切り替え方式 定義 フェイルオーバー （計画外停止を想定） スタンバイでプライマリへ昇格処理を開始してから完了するまで。（受信しているREDO の最終適用時間を含む） プライマリの障害検知時間は含みません。 スイッチオーバー （計画停止を想定） 現行プライマリでのスタンバイ降格コミット文開始から、現行スタンバイでのプライマリ昇 格コミット文完了まで。 両コマンド間の実行間隔はゼロであるとします。GRIDCenter_SQLApply_PowerSystems_jp.doc チューニング・ポイント 参考資料に挙げたホワイトペーパーを基にした設定を施し、スイッチオーバー、 およびフェイルオーバーを実施します。この結果をチューニング前の値(＝α)とし ます。 その後、一定の負荷をかけた環境で個別のチューニングを施し、最適なチュー ニング項目を検討します(＝β)。ここで導出された設定に対し、負荷を変化させて 切り替え時間の変化を確認します。 チューニング・ポイントを以下にまとめます。 チューニング検討項目 説明 ホワイトペーパーを基にした設定を施し、スイッチオーバー、およびフェイルオ ーバーを実施します。 基本設定 Oracle NetでSDUの値およびOSのネットワークのパケットサイズを変更しま す。 (A) ネットワーク (B) REDO転送・SQL適 用 プライマリ側のREDO転送関連パラメータ(net_timeout)、およびスタンバイ側 のSQL適用の最大プロセス数を変更します。 (C1) H/W （仮想イーサネット） プライマリ～スタンバイ間のREDO転送に仮想イーサネットを使用します。 (C2) H/W （CPU割り当て変更） ダイナミックLPARによりCPUリソースを非適用インスタンスから適用インスタン スに動的に割り当てます。 ※スタンバイ側の適用（切り替え）処理実行ノードの性能向上を目的とします。 (D) その他 上記のチューニング以外で検証中に判明した項目 REDOログファイルのサイズ チェックポイントのチューニング
検証結果
検証結果とその考察について説明します。ロジカル・スタンバイの基本性能検証
本章は Data Guard に関する基礎性能値の計測結果を説明します。 適用の遅延 概要・機能説明Data Guard が提供する REDO の転送方式は、大きく 2 つの方式から選択するこ とができます。 転送方式 転送設定 説明 同期転送 SYNC-AFFIRM プライマリDBでのコミットは、Data GuardによるスタンバイDBのスタ ンバイREDOログファイルへの書き込み完了が確認されるまで完了 しません。 プライマリDBとスタンバイDBのデータ同一性を優先します。
転送方式 転送設定 説明 非同期転送 ASYNC-NOAFFIRM プライマリDBでのコミットはスタンバイDBの構成・処理に影響を受け ることなく、独立して完了します。 プライマリDBでの処理速度を優先します。 今回の検証ではクライアントのセッション数を50～200まで変化させ、適用の遅延を測定しました。 SYNC-AFFRIMの試験では、最大可用性モードを選択し、検証中はv$databaseのprotection_level 列を使ってスタンバイ側へのREDO転送が同期モードで行われていることを監視しています。 ASYNC-NOAFFIRMの試験は、最大パフォーマンスモードで行います。 なお、最大パフォーマンスモードでは、転送方式の制限がなくなるため、通常 時はデータ保護を目的として LGWR SYNC 転送を使用し、大量のデータをロード するような場合など、あらかじめ REDO の大量転送が予想される場合には一時的 に LGWR ASYNC 転送に変更し、終了後に戻す運用も可能です。 検証結果 今回の検証では、SYNC-AFFIRM設定による、プライマリDBにおけるスループ ットへの影響は、実質的に確認されませんでした。3 また、SYNC-AFFIRM、ASYNC-NOAFFIRM ともに適用まで含めた処理が１秒以 内に終了しており、スタンバイでの遅延状況の差は確認されませんでした。 転送方式 負荷 （セッション数 [REDO生成量]） 検証結果 （遅延：秒） 50 [約256KB/sec] 1秒未満 100 [約512KB/sec] 1秒未満 SYNC-AFFIRM 200 [約1024KB/sec] 1秒未満 50 [約256KB/sec] 1秒未満 ASYNC-NOAFFIRM 200 [約1024KB/sec] 1秒未満 結論・補足 同じクライアント・セッション数でかけた負荷は同期転送と非同期転送で生成 される REDO 生成量に変化はありませんでした。これは同期転送と非同期転送で 同量のトランザクションが実行できていることを示しています。今回の検証では、 ローカルのネットワーク環境で転送遅延が低く抑えられることやスタンバイ
GRIDCenter_SQLApply_PowerSystems_jp.doc
REDO ログの I/O 性能が十分だったことで、REDO を同期転送するオーバーヘッド がプライマリの待機時間の中で影響が出なかったためであると考えられます。 今回の負荷レベル（200 セッションで REDO 生成量は 940 KB/Sec）では同期転 送と非同期転送の双方で REDO 適用の遅延は認められませんでした。 非同期転送においてはプライマリから送信される REDO がプライマリのトラン ザクションに影響を与えない範囲で 1 秒以内に転送されていることが分かります。 以上より、本検証においてロジカル・スタンバイデータベースが十分な適用性能 を持つことと、データ保護を同期転送においても性能劣化がなかったことがいえ ます。 補足として、同期/非同期転送にかかわらずクライアントとデータベース間の通 信への影響をなくすため、クライアントの処理を受け付けるネットワークとは別 に REDO 転送用のネットワークを構成することを推奨します。 SQL 適用の最大適用性能 概要・機能説明 スタンバイが RAC 構成の場合、REDO の受信は全てのインスタンスに分散させ ることができますが、適用はいずれかの 1 つのインスタンス上で行います。 検証結果 CPU 数の割り当てを以下の 3 パターンで変化させて検証を実施したところ、適 用ノードの CPU 数が 2 の場合では CPU がボトルネックとなり、適用処理が頭打ち となりました。 適用インスタンスの CPU 数を 4 に増加させることで CPU ボトルネックが解消 され、適用処理の性能向上が確認できました。 CPU割り当て (適用ノード割り当て数) cpu_counｔ パラメータ 適用プロセス数 CPU使用率 （最大％） 適用性能 （TPS） 適用性能 (KB/Sec) 適用時間 (mm:ss) 2 4 15 100% 3708 6150 6:03 4 8 27 98.6% 5472 9069 3:38
・cpu_count がCPU割り当て数の倍になっているのは POWER5プロセッサのSimultaneous Multi-threading(SMT)機能を有効にしているためです。
・適用プロセス数は数式「cpu_count + 3 」により算出。出典は「 Data Guard 転送／適用パフォーマンス関連」を参照下さい。
2CPUs 4CPUs 上のグラフは、検証時の適用ノードにおけるCPU使用率を表しています。検証の時系列とは異なり、 左から適用ノードのCPU割当数の順番（「2」「4」）です。 結論・補足 検証結果より、スタンバイでの適用遅延のボトルネックが CPU である場合、CPU リソースの追加が処理能力に適切に反映される（有効である）ことが確認できま した。また、スタンバイ側で適用以外にも読み取り専用のアプリケーションなど を実行する際には、ダイナミック LPAR を使ってスタンバイに動的に CPU リソー スを割り当てることで柔軟なシステムが構築できると考えられます。 スタンバイのCPU数考慮点 スタンバイの CPU 数見積もりには、一律の基準はありませんが、CPU 数の見積 もりにおいては以下の点を考慮した上で、総合的に決定する必要があります。 プライマリ DB における検索と更新処理の比率。更新処理の比率が高ければ スタンバイ DB 側での適用処理量が多くなるため、より多くのリソースが必 要になります。 スイッチオーバー後の縮退率の考え方 スタンバイ DB 側での参照業務要件 ダイナミック LPAR のような仮想化技術の利用可否
GRIDCenter_SQLApply_PowerSystems_jp.doc
ロールの切り替え
本章では、本番と待機システムのデータベースを切り替える実行時間を最小化する方法 を確認します。総括
スイッチオーバー/フェイルオーバーの切り替え時間 本検証のα環境で測定したスイッチオーバーの実行時間は 30 秒程度でした。 α環境における実測値を基準としてチューニングの効果をスイッチオーバーの 切り替え時間で確認します。次にフェイルオーバーによる切り替え時間を確認し てその効果を確認します。 スイッチオーバーにおける切り替え時間 本検証のα環境では 30 秒程度を要しましたが、チューニングを施した環境では 最短で約 5 秒まで短縮できることを確認しました。 最も効果的なチューニング項目は、REDO ログファイルを適切なサイズまで小 さくし、REDO ログファイルのグループ数を 5 グループ以上に構成することであ ることが確認されました。 スイッチオーバーによる切替時間（単位：秒） 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 α β S->P 2.00 23.50 P->S 2.67 8.50 α β このグラフは512KB/secの負荷がある環境でスイッチオーバーの切り替え時間を3回測定した結果の平均 値です。 P->S = プライマリDBがスタンバイ・ロールに切り替わるまでの時間[秒] S->P = スタンバイDBがプライマリ・ロールに切り替わるまでの時間[秒] オンラインREDOログファイルを小さくすると、ログスイッチの頻度が上がり性能へ影響を与える場合が ありますので、小さくしすぎないように注意してください。 フェイルオーバーの切り替え時間 α環境において、切り替え時間は 1 秒以下で達成できることを確認し、β環境 でも同様の結果を得ました。、フェイルオーバーの切り替え時間に関しては、どち らの環境でも最適化されているといえます。フェイルオーバーによる切替時間 （単位：秒） 0 0.5 1 1.5 2 2.5 α β 3 S->P 0.56 0.52 α β このグラフは512KB/secの負荷がある環境でフェイルオーバーの切り替え時間を2回測定した結果の平均 値です。SQL*Plusで実行したSQL文の実行時間を測定しています。 S->Pはスタンバイ・ロールがプライマリ・ロールに切り替わる時間を表しています。
β環境の考察
MAAベスト・プラクティスの「SQL適用のベスト・プラクティス」、「ネットワーク転送のベスト・プラクティ ス」およびH/Wの機能を利用したチューニング環境に加えて以下のチューニングを実施しました。 適切なREDOログファイルのサイズ スイッチオーバー中に、新プライマリとなるデータベースでスタンバイREDOログファイルのアーカイブ が実行される時間を削減させるため、1GBのREDOログファイルを100MBに変更した環境でテストを 実施しました。 REDOログファイルのサイズ変更による効果 （単位：秒） 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 1GB 100MB S->P 5.40 23.50 P->S 4.80 8.50 1GB 100MB このグラフは512KB/secの負荷がある環境でスイッチオーバーの切り替え時間を3回測定した結果の平均 値です。 オンラインREDOログファイルおよびスタンバイREDOログファイルのサイズを変更することで、大きな 時間の短縮が確認できました。特にスタンバイ側で実行されるCOMMIT TO SWITCHIOVER TO PRIMARYコマンド大きく改善されています。 チェックポイントのチューニングGRIDCenter_SQLApply_PowerSystems_jp.doc スイッチオーバー中は内部的にログスイッチが実行され、REDOログのサイズを変更した (D)の環境 では1秒以内に3回のログスイッチが実施されることから、下記にあげたチェックポイントのチューニング を施し、チェックポイントにかかる時間を短縮することでその効果を確認します。 オンラインREDOログのグループ数を2グループ追加し計6グループに変更 _FAST_START_INSTANCE_RECOVERY_TARGET を5に変更 本検証ではFAST_START_MTTR_TARGETの代わりに_FAST_START_INSTANCE_RECOVERY_TARGETパラメーター を使用します。
このパラメーターの詳細につきましては、参考資料として紹介しているOracle MAA Best Practicesの 「Optimizing Availability During Unplanned Outages Using Oracle Clusterware and RAC」をご確 認ください。 チェックポイントのチューニングによる効果 （単位：秒） 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 α (D) (E) S->P 2.00 6.33 23.50 P->S 2.67 4.33 8.50 α (D) (E) このグラフは512KB/secの負荷がある環境でスイッチオーバーの切り替え時間を3回測定した結果の平均 値です。 上記の通り、チェックポイントをチューニングすることによって、切り替え処理をより短時間で実施できる ことが確認されました。 負荷量の違いによる切り替え時間への影響 β環境において、負荷量を変えて切り替え時間への影響を確認しました。 負荷量の違いによる切替時間への影響 （単位：秒） 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 0KB/sec 256KB/sec 512KB/sec 1024KB/sec S->P 2.00 2.00 2.67 4.40 P->S 2.33 2.67 2.33 1.00 0KB/sec 256KB/sec 512KB/sec 1024KB/sec 最大で1MB/Secまでの負荷をかけた状態でスイッチオーバー処理を実行しましたが、負荷量によら ず、切り替え時間は5秒程度であることを確認しました。
SQL 適用におけるベスト・プラクティス 本検証の結果から次の構成(＝β)で切り替え時間が最短になることを確認しました。 また、本検証では実際にその効果が確認できなかった点も含まれていますが、少なくとも悪影響は及 ぼさなかった点と将来的な負荷の増加があった場合を想定して予防的な措置としてベスト・プラクティ スに含めています。 以下でSQL適用におけるベスト・プラクティスをまとめます。 構成におけるベスト・プラクティス H/Wの構成 動的に適用インスタンスへ十分なCPUリソースを配置 ダイナミックLPAR 最小限のネットワーク・ラウンド・トリップを実現する高速なREDOログ転送経路の確保 (仮 想イーサネット) プライマリ・データベースの構成 適切なオンラインREDOログファイルのサイズ オンラインREDOログファイルを6グループ以上で構成 スループットに影響のない範囲でチェックポイント間隔を短縮 最大可用性モード4 LGWR SYNC AFFIRM転送 ロジカル・スタンバイの構成(スイッチオーバー時はプライマリDBも同様の構成) リアルタイム適用 [適用の遅延] で説明する通り、本検証環境のようにスタンバイ側の適用遅延が最小 限で完了していることが重要です。 1メンバーのスタンバイREDOログファイル サイズはプライマリのオンラインREDOログファイルと同じ グループ数はスレッドごとにプライマリのオンラインREDOログファイルのグループ数 +1 SQL適用の最適化 SQL適用のプロセス数 = cpu_count×3+3 十分なLCRキャッシュ 本検証では、上限（共有プールの4分の1・・・512MB）まで拡張 4最適なスイッチオーバー/フェイルオーバー時間を実現するための追加情報として、MetaLink Note
GRIDCenter_SQLApply_PowerSystems_jp.doc 運用およびアプリケーションのベスト・プラクティス スイッチオーバーコマンドの実行前にプライマリ・スタンバイ双方で、手動でログスイッチを実行 フェイルオーバーコマンドの実行前は、プライマリ・ロールで有効になるREDOログの送信宛先 (=log_archive_dest_N)のステータスをDEFERにする 短いトランザクション 長時間実行されるトランザクションはスイッチオーバーの開始時間を遅らせる要因となりま す。 切り替え時間の極小化が最優先事項であるシステムにおいては、あらかじめ、RAC構成のスタ ンバイDBは、1ノードのみ起動した状態にしておく
補足事項
スタンバイ REDO ログの設計指針 スタンバイ REDO ログファイルの設計においては、一般的な設計指針として、 下記の情報を参考にしてください。 プライマリ・データベース、スタンバイ・データベースそれぞれに ・グループ数 : オンラインREDOログファイルより 1つ多い ・メンバ数 : 1 ・サイズ : オンラインREDOログと同じサイズ ・配置 : 十分にストライピングされたディスクグループ上に配置まとめ
Oracle 社の提唱する MAA を IBM Power Systems 上に構築することで堅牢かつ柔軟な 高可用性システムを構築することが可能であることが確認できました。具体的には、プラ イマリ・データベースから毎秒5MB の REDO が生成される環境でもロジカル・スタンバ イ・データベースには更新データを 1 秒以内に適用できることや、チューニングによって 待機システムへの切り替えも非常に短い時間（スイッチオーバー：約 1 秒、フェイルオー バー：約5 秒）で行えることが確認できました。最新バージョンである Oracle Database 11g では、フィジカル・スタンバイを一時的にロジカル・スタンバイに変換することで停止時 間を極小化したデータベース・バージョンのアップグレードやパッチセットの適用（ロー リング・アップグレード）が可能になります。そのため、Oracle Data Guard 構成におい
てロジカル・スタンバイでのSQL 適用性能や切り替え時間は非常に重要な要素であるとい
えます。また、IBM Power Systems による動的なリソース割り当てによって、SQL 適用 性能の最適化が容易に行えることも確認できました。 今回の検証で確認できた点はミッションクリティカルなシステムに求められる可用性要件 を検討するうえで重要な要素であるといえます。 本検証では本番と同じサイト内にスタンバイを構成した環境を構築して高速に本番と待 機システムを切り替えることによって可用性の高いシステムを構築できることを確認しま した。地震や火災、テロといったサイト障害からもデータを保護するためには、更に災害 サイトを遠隔地に構築することでそのシステムの可用性は最大となると考えられます。
謝辞
2006 年 11 月、日本オラクル株式会社は日本アイ・ビー・エム株式会社やグリッド戦略パ ートナー各社と協業体制を確立し、企業のシステム基盤の最適化を実現する次世代のビジ ネス・ソリューションを構築するため、先鋭の技術を集結した「Oracle GRID Center（オラ クル・グリッド・センター）」( http://www.oracle.co.jp/solutions/grid_center/index.html )を開設 しました。本稿は、Oracle GRID Centerの趣旨にご賛同頂いたシスコシステムズ合同会社の ハードウェア・ソフトウェアのご提供および技術者によるご支援などの多大なるご協力を 得て作成しております。協賛企業各社およびご協力頂いた技術者に深く感謝いたします。
補足 – 試験環境詳細
H/W 構成
マシン情報 本検証で使用したサーバおよびクライアントマシンのスペックは下記の通りで す。 DBサーバ 筐体IBM Power Systems 570 CPU/Memory 情報
Item Value
Processor(s) 4 Processor(s) Installed
[01]: PowerPC_POWER5 2198 MHz [02]: PowerPC_POWER5 2198 MHz [03]: PowerPC_POWER5 2198 MHz [04]: PowerPC_POWER5 2198 MHz Total Physical Memory 14336 MB
Swap: Max Size 3072 MB
クライアント 筐体
IBM BladeCenter CPU/Memory 情報
Item Value
Processor(s) 4 Processor(s) Installed
[01]: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz [02]: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz [03]: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz [04]: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz Total Physical Memory 3946 MB
GRIDCenter_SQLApply_PowerSystems_jp.doc
ストレージ
ストレージ構成は下記の通りです。 ストレージ装置
IBM DS4800 1815-82A×1 台（プライマリ RAC, スタンバイ RAC で別のボリュームを作成） 4GB キャッシュ ホスト接続ポート数（LC）×8（4Gbps） 146.8GB - 15KRPM ディスク本数 各DB に 16 本ずつ RAID-5： 8 本 データ領域 （データファイル、制御ファイル、REDO ログ、スタンバ イREDO ログ） RAID-0： 7 本（下記、各用途に 1 本ずつ） オンラインREDO ログのアーカイブ先 スタンバイREDO ログのアーカイブ先 ネットワーク ネットワーク構成は以下の通りです。 クライアントアクセス用のパブリック・ネットワーク インターコネクト用のプライベート・ネットワーク REDO 転送用には、2 種類を用意 通常のLAN – Gigabit 仮想イーサネット
OS (AIX)関連
nmon OS レベルのリソース状況を記録するために、nmon を使用します。 nmon を使用することで Excel との連携、グラフ化などを簡単に行うことができ、 分析効率の向上に役立ちます。 本検証では、nmon12_beta44 -s 5 -c 1000 –f を取得しています。 http://www.ibm.com/developerworks/aix/library/au-analyze_aix/index.html※ 注意事項 nmon は、IBM 社の製品ではありません。
参考資料
マニュアル：Oracle Database
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/index.htm 高可用性関連マニュアル データベースの全般的な高可用性については、下記のマニュアルに記述があります。 Oracle Database 高可用性概要 10gリリース2（10.2）B19206-02 Oracle Database 高可用性ベスト・プラクティス 10gリリース2（10.2）B31489-01Oracle MAA Best Practices
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm#Database
Data Guard 構築関連ベスト・プラクティス
MAA 10g Setup Guide: Creating a RAC Physical Standby Database for a RAC Primary Database
Setup Guide: Creating a RAC Logical Standby Database for a RAC Primary Database
Data Guard スイッチオーバー／フェイルオーバー関連ベスト・プラクティス Data Guard Switchover and Failover
Data Guard 転送／適用パフォーマンス関連ベスト・プラクティス Data Guard SQL Apply
Data Guard Redo Transport & Network Configuration
Real Application Clusters 関連ベスト・プラクティス
GRIDCenter_SQLApply_PowerSystems_jp.doc
日本オラクル コンサルティングサービスについて
この文書は、Oracle GRID Center での検証プロジェクトによって作成されました。また、 当検証プロジェクトには、プロジェクトのリーディングおよび検証計画・検証作業の一部 をコンサルティングサービス部門のコンサルタントも参画しています。
日本オラクルのコンサルティングサービス部門（Oracle Consulting Service Japan [OCSJ]）の中で、テクノロジーコンサルティング本部では、約 200 名5のコンサルタントが 年間 約 200 プロジェクトでテクノロジー製品全般に関する支援を行っています。支援対象 のシステムには、本書で想定しているような高度なチューニングが必要なシステムの他、 高可用性、高拡張性、ハイパフォーマンスなど高いサービルレベルの要求されるシステム、 大規模システム、新機能実装システムなどが数多く含まれており、これらシステムの実践 的な構築スキルやノウハウを日々蓄積しています。企業システムにおける最適な戦略の企 画・策定から、迅速なインプリメンテーション、安定稼働まで、日本オラクルのコンサル ティングサービスは、お客様特有のニーズを満たしたサービスを提供します。 日本オラクルのコンサルティングサービスに関するお問い合わせは、Oracle Direct （http://www.oracle.com/lang/jp/direct/index.html）まで。 5 2008年12月現在
日本オラクル株式会社
Copyright © 2008 Oracle Corporation Japan. All Rights Reserved. 無断転載を禁ず
この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されるこ とがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、 本書の内容に関連したいかなる損害についても責任を負いかねます。
Oracle、JD Edwards、PeopleSoft、及び Siebel は、米国オラクル・コーポレーション 及びその子会社、関連会社の登録商標です。その他の名称は、各社の商標または登録商標 です。
文中に参照されている各製品名及びサービス名は米国 Oracle Corporation の商標また は登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商 標の可能性があります。
