IBM Power Systems 上での Oracle Data Guard SQL適用における性能検証

Transcription

1 IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 Maximum Availability Architecture (MAA) ベスト プラクティスの適用 Creation Date: Feb 10, 2009 Version: 1.0

2 はじめに 近年 IT システムに求められる可用性はますます高くなる一方 ミッションクリティカルなシステムは オープン環境へダウンサイジングを行うシステムが急速に増えていますこのような非常に高い可用性を求められるシステムでは 様々な高可用性テクノロジーを組み合わせることで複雑なアーキテクチャになってしまうことが問題となっています Oracle 社では このようなシステムのインフラ設計をする際のベスト プラクティスとして Maximum Availability Architecture(MAA) のブループリントを提供しています MAA では高可用性システムを設計する際の複雑さや憶測を排除した実証済みのアーキテクチャを提供することで より低コストで可用性の高いシステムを実現します 同様に IBMのUNIX TM サーバー IBM Power Systemsは優れた拡張性 柔軟性 信頼性を持ち Oracle Database 及びMAAのベスト プラクティスに基づいた環境をPower Systems 上に構築することで可用性に優れたシステムを構築することが可能です Oracle Data Guard (Data Guard) は MAA のキーコンポーネントです Data Guard は本番データベースに対して 1 つ以上のスタンバイ データベースを構築し データを保護します これによってシステムの計画停止 / 計画害停止時のダウンタイムを最小限にします 本検証では IBM Power Systems 上に Data Guard のロジカル スタンバイを構築した環境で基本性能を測定し 計画停止を想定した本番と待機システムを切り替える時間や障害が発生した場合に待機システムを本番システムに昇格する時間を極小化するための最適な構成を評価しました

3 目次 はじめに...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

4 まとめ...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 日本オラクルコンサルティングサービスについて IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 4

5 Executive Summary 本検証の結果 IBM のUNIXオペレーティングシステムAIX TM を稼動するIBM Power Systems 上に構築された Oracle Database 10g Release 2 ( ) での 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 秒未満で実行できることを確認しました

6 スイッチオーバーによる切替時間 ( 単位 : 秒 ) α β β S->P P->S α α = チューニング前の結果 β = チューニング後の結果 S->P = スタンバイからプライマリに切り替える時間 P->S プライマリからスタンバイに切り替える時間 REDO 生成量が 512KB/sec の負荷環境で 3 回のテストを実施した平均値 検証環境 高可用性システムを提供するために IBM Power Systems のリソースを 4 つの論理パーティションで分割し ノード障害に備えて 2 ノードの RAC を本番用システムとして構成します 更に障害範囲がクラスタ全体に拡大した際や計画的なメンテナンス時間を極小化するために 待機システムとして DG のロジカル スタンバイを 2 ノードの RAC で構成します 以下で検証環境の概要を説明します 詳細につきましては - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 6

7 補足 試験環境詳細 の章を参照下さい 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 DS GB/15K 4Gbps FC Drive * 16drive Primary Standby LPAR#1 LPAR#2 LPAR#3 LPAR#4 4cpu 14GB mem 4cpu 14GB mem Workload client 4cpu 14GB mem 4cpu 14GB mem prm1 prm2 stb1 stb2 DBF Arch DBF Arch ASM ASM DB 構成の概要 OS AIX 5L 共有ディスク Oracle の Automatic Storage Management(ASM) を利用し RAID-5(8 本 ) で構成されたボリュームに対してデータベース用のディスクグループを構成他に RAID-0(7 本 ) で構成された別のボリュームに REDO ログ用のディスクグル

8 ープを構成 DB Oracle Database 10g ( ) 各インスタンスの構成 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_TAB1 Name 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) 1 検証中にサイズを 1GB から 100MB に変更 またグループ数を 3 から 6 に変更 - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 8

9 検証項目 ロジカル スタンバイの基礎検証と本番 ( プライマリ ) と待機 ( スタンバイ ) の切り替え時間 についての検証を行います チューニングの実施前と後の環境本ドキュメントでは チューニングが施される前の環境を α 環境 と呼び 後述する切り替え時間を極小化するためのチューニングが施された環境を β 環境 と呼ぶことにします ロジカル スタンバイの基本性能検証 β 環境における適用の遅延 ( 適用ラグ ) と SQL 適用の最大適用性能を計測します ロジカル スタンバイでは スタンバイが受信した REDO を SQL 文に変換して適用する機能を SQL 適用と呼びます 適用の遅延 プライマリから送信された REDO がスタンバイに適用されるまでの時間を同期転送と非同期転送で確認します SQL 適用の最大適用性能 スタンバイにためた未適用の REDO データを適用が完了するまでの時間を測定することで SQL 適用の最大適用性能を確認します 適用の遅延プライマリにかける負荷の量を変化させながら プライマリで実行された更新処理が スタンバイでどの程度遅れて適用されているのかを確認します また 同期転送 (LGWR SYNC 転送 ) と非同期転送 (LGWR ASYNC 転送 ) において測定を行い その変化を確認します 負荷の単位にはプライマリに負荷を実行するクライアントの セッション数 を使用し と増やした際の性能変化を確認します 遅延の測定には 別途測定用アプリケーションを使用します 遅延測定用アプリケーションはタイムスタンプを格納する遅延測定用テーブル (1 行 ) を プライ 2 プライマリのオンラインREDOのサイズ変更に合わせて1GBから100MBに変更 またグループ数を4 から7に変更 - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 9

10 マリにおいて 1 秒間隔で現在のタイムスタンプに UPDATE して スタンバイでそ の適用を検索することによって遅延を確認します スタンバイではリアルタイム適用を使用しています SQL 適用の最大適用性能 IBM Power Systemsの仮想化機能 PowerVM TM の一つである 分割された論理パーティションに対してCPUリソースを動的に配分するダイナミックLPARの技術により スタンバイの適用インスタンスに割り当てるCPUを動的に変化させながら SQL 適用の性能を確認します 負荷の単位には プライマリで1 秒あたりに生成される REDO 量 (MB) を使用します 以下の手順で検証を実施します 1. スタンバイで SQL 適用を停止 2. プライマリ側で負荷処理を 5 分間実行し スタンバイで未適用の REDO をため込む 3. ため込まれた REDO 量が一定であることを確認 4. スタンバイの SQL 適用を再開し 適用が完了するまでの処理性能を計測適用した REDO の量と適用にかかった時間を計測し 1 秒間に適用した REDO の量を導出します ロジカル スタンバイの切り替え処理 計画停止時に行うスイッチオーバーとプライマリで障害が発生した際に行うフェイルオーバーの実行時間を測定します 切り替え時間の定義 本検証における切り替え時間とは システム内でプライマリ データベースが存在しない時間 と定義します 切り替え方式 フェイルオーバー ( 計画外停止を想定 ) スイッチオーバー ( 計画停止を想定 ) 定義 スタンバイでプライマリへ昇格処理を開始してから完了するまで ( 受信しているREDO の最終適用時間を含む ) プライマリの障害検知時間は含みません 現行プライマリでのスタンバイ降格コミット文開始から 現行スタンバイでのプライマリ昇格コミット文完了まで 両コマンド間の実行間隔はゼロであるとします - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 10

11 チューニング ポイント参考資料に挙げたホワイトペーパーを基にした設定を施し スイッチオーバー およびフェイルオーバーを実施します この結果をチューニング前の値 (=α) とします その後 一定の負荷をかけた環境で個別のチューニングを施し 最適なチューニング項目を検討します (=β) ここで導出された設定に対し 負荷を変化させて切り替え時間の変化を確認します チューニング ポイントを以下にまとめます チューニング検討項目 基本設定 (A) ネットワーク (B) REDO 転送 SQL 適用 (C1) H/W ( 仮想イーサネット ) (C2) H/W (CPU 割り当て変更 ) (D) その他 説明 ホワイトペーパーを基にした設定を施し スイッチオーバー およびフェイルオーバーを実施します Oracle NetでSDUの値およびOSのネットワークのパケットサイズを変更します プライマリ側のREDO 転送関連パラメータ (net_timeout) およびスタンバイ側のSQL 適用の最大プロセス数を変更します プライマリ~スタンバイ間のREDO 転送に仮想イーサネットを使用します ダイナミックLPARによりCPUリソースを非適用インスタンスから適用インスタンスに動的に割り当てます スタンバイ側の適用 ( 切り替え ) 処理実行ノードの性能向上を目的とします 上記のチューニング以外で検証中に判明した項目 REDOログファイルのサイズチェックポイントのチューニング 検証結果 検証結果とその考察について説明します ロジカル スタンバイの基本性能検証 本章は Data Guard に関する基礎性能値の計測結果を説明します 適用の遅延概要 機能説明 Data Guard が提供する REDO の転送方式は 大きく 2 つの方式から選択することができます 転送方式転送設定説明 同期転送 SYNC-AFFIRM プライマリ DB でのコミットは Data Guard によるスタンバイ DB のスタンバイ REDO ログファイルへの書き込み完了が確認されるまで完了しません プライマリ DB とスタンバイ DB のデータ同一性を優先します - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 11

12 転送方式転送設定説明 非同期転送 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 ともに適用まで含めた処理が1 秒以内に終了しており スタンバイでの遅延状況の差は確認されませんでした 転送方式 負荷 ( セッション数 [REDO 生成量 ]) 検証結果 ( 遅延 : 秒 ) SYNC-AFFIRM ASYNC-NOAFFIRM 50 [ 約 256KB/sec] 100 [ 約 512KB/sec] 200 [ 約 1024KB/sec] 50 [ 約 256KB/sec] 200 [ 約 1024KB/sec] 1 秒未満 1 秒未満 1 秒未満 1 秒未満 1 秒未満 結論 補足 同じクライアント セッション数でかけた負荷は同期転送と非同期転送で生成される REDO 生成量に変化はありませんでした これは同期転送と非同期転送で同量のトランザクションが実行できていることを示しています 今回の検証では ローカルのネットワーク環境で転送遅延が低く抑えられることやスタンバイ 3 但し 本番システムに導入する場合は事前検証を行うことを推奨します - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 12

13 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_count パラメータ 適用プロセス数 CPU 使用率 ( 最大 %) 適用性能 (TPS) 適用性能 (KB/Sec) 適用時間 (mm:ss) % : % :38 cpu_count が CPU 割り当て数の倍になっているのは POWER5 プロセッサの Simultaneous Multi-threading(SMT) 機能を有効にしているためです 適用プロセス数は数式 cpu_count + 3 により算出 出典は Data Guard 転送 / 適用パフォーマンス関連 を参照下さい - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 13

14 2CPUs 4CPUs 上のグラフは 検証時の適用ノードにおける CPU 使用率を表しています 検証の時系列とは異なり 左から適用ノードの CPU 割当数の順番 ( 2 4 ) です 結論 補足検証結果より スタンバイでの適用遅延のボトルネックが CPU である場合 CPU リソースの追加が処理能力に適切に反映される ( 有効である ) ことが確認できました また スタンバイ側で適用以外にも読み取り専用のアプリケーションなどを実行する際には ダイナミック LPAR を使ってスタンバイに動的に CPU リソースを割り当てることで柔軟なシステムが構築できると考えられます スタンバイのCPU 数考慮点スタンバイの CPU 数見積もりには 一律の基準はありませんが CPU 数の見積もりにおいては以下の点を考慮した上で 総合的に決定する必要があります プライマリ DB における検索と更新処理の比率 更新処理の比率が高ければスタンバイ DB 側での適用処理量が多くなるため より多くのリソースが必要になります スイッチオーバー後の縮退率の考え方 スタンバイ DB 側での参照業務要件 ダイナミック LPAR のような仮想化技術の利用可否 - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 14

15 ロールの切り替え 本章では 本番と待機システムのデータベースを切り替える実行時間を最小化する方法を確認します 総括スイッチオーバー / フェイルオーバーの切り替え時間本検証のα 環境で測定したスイッチオーバーの実行時間は 30 秒程度でした α 環境における実測値を基準としてチューニングの効果をスイッチオーバーの切り替え時間で確認します 次にフェイルオーバーによる切り替え時間を確認してその効果を確認します スイッチオーバーにおける切り替え時間本検証のα 環境では 30 秒程度を要しましたが チューニングを施した環境では最短で約 5 秒まで短縮できることを確認しました 最も効果的なチューニング項目は REDO ログファイルを適切なサイズまで小さくし REDO ログファイルのグループ数を 5 グループ以上に構成することであることが確認されました スイッチオーバーによる切替時間 ( 単位 : 秒 ) α β β S->P P->S α このグラフは 512KB/sec の負荷がある環境でスイッチオーバーの切り替え時間を 3 回測定した結果の平均値です P->S = プライマリ DB がスタンバイ ロールに切り替わるまでの時間 [ 秒 ] S->P = スタンバイ DB がプライマリ ロールに切り替わるまでの時間 [ 秒 ] オンライン REDO ログファイルを小さくすると ログスイッチの頻度が上がり性能へ影響を与える場合がありますので 小さくしすぎないように注意してください フェイルオーバーの切り替え時間 α 環境において 切り替え時間は 1 秒以下で達成できることを確認し β 環境でも同様の結果を得ました フェイルオーバーの切り替え時間に関しては どちらの環境でも最適化されているといえます - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 15

16 フェイルオーバーによる切替時間 ( 単位 : 秒 ) α β β S->P α このグラフは 512KB/sec の負荷がある環境でフェイルオーバーの切り替え時間を 2 回測定した結果の平均値です SQL*Plus で実行した SQL 文の実行時間を測定しています S->P はスタンバイ ロールがプライマリ ロールに切り替わる時間を表しています β 環境の考察 MAA ベスト プラクティスの SQL 適用のベスト プラクティス ネットワーク転送のベスト プラクティス および H/W の機能を利用したチューニング環境に加えて以下のチューニングを実施しました 適切な REDO ログファイルのサイズ スイッチオーバー中に 新プライマリとなるデータベースでスタンバイ REDO ログファイルのアーカイブが実行される時間を削減させるため 1GB の REDO ログファイルを 100MB に変更した環境でテストを実施しました REDO ログファイルのサイズ変更による効果 ( 単位 : 秒 ) GB 100MB 100MB S->P P->S GB このグラフは 512KB/sec の負荷がある環境でスイッチオーバーの切り替え時間を 3 回測定した結果の平均値です オンライン REDO ログファイルおよびスタンバイ REDO ログファイルのサイズを変更することで 大きな時間の短縮が確認できました 特にスタンバイ側で実行される COMMIT TO SWITCHIOVER TO PRIMARY コマンド大きく改善されています チェックポイントのチューニング - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 16

17 スイッチオーバー中は内部的にログスイッチが実行され 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 をご確認ください チェックポイントのチューニングによる効果 ( 単位 : 秒 ) α (D) (E) (E) (D) α S->P P->S このグラフは 512KB/sec の負荷がある環境でスイッチオーバーの切り替え時間を 3 回測定した結果の平均値です 上記の通り チェックポイントをチューニングすることによって 切り替え処理をより短時間で実施できることが確認されました 負荷量の違いによる切り替え時間への影響 β 環境において 負荷量を変えて切り替え時間への影響を確認しました 負荷量の違いによる切替時間への影響 ( 単位 : 秒 ) KB/sec 256KB/sec 512KB/sec 1024KB/sec 1024KB/sec 512KB/sec 256KB/sec 0KB/sec S->P P->S 最大で 1MB/Sec までの負荷をかけた状態でスイッチオーバー処理を実行しましたが 負荷量によらず 切り替え時間は 5 秒程度であることを確認しました - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 17

18 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 を合わせてご参照ください - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 18

19 運用およびアプリケーションのベスト プラクティス スイッチオーバーコマンドの実行前にプライマリ スタンバイ双方で 手動でログスイッチを実行 フェイルオーバーコマンドの実行前は プライマリ ロールで有効になる REDO ログの送信宛先 (=log_archive_dest_n) のステータスを DEFER にする 短いトランザクション 長時間実行されるトランザクションはスイッチオーバーの開始時間を遅らせる要因となります 切り替え時間の極小化が最優先事項であるシステムにおいては あらかじめ RAC 構成のスタンバイ DB は 1 ノードのみ起動した状態にしておく 補足事項 スタンバイ REDO ログの設計指針スタンバイ REDO ログファイルの設計においては 一般的な設計指針として 下記の情報を参考にしてください プライマリ データベース スタンバイ データベースそれぞれに グループ数 : オンラインREDOログファイルより 1つ多い メンバ数 : 1 サイズ : オンラインREDOログと同じサイズ 配置 : 十分にストライピングされたディスクグループ上に配置 - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 19

20 まとめ Oracle 社の提唱する MAA を IBM Power Systems 上に構築することで堅牢かつ柔軟な高可用性システムを構築することが可能であることが確認できました 具体的には プライマリ データベースから毎秒 5MB の REDO が生成される環境でもロジカル スタンバイ データベースには更新データを 1 秒以内に適用できることや チューニングによって待機システムへの切り替えも非常に短い時間 ( スイッチオーバー : 約 1 秒 フェイルオーバー : 約 5 秒 ) で行えることが確認できました 最新バージョンである Oracle Database 11g では フィジカル スタンバイを一時的にロジカル スタンバイに変換することで停止時間を極小化したデータベース バージョンのアップグレードやパッチセットの適用 ( ローリング アップグレード ) が可能になります そのため Oracle Data Guard 構成においてロジカル スタンバイでの SQL 適用性能や切り替え時間は非常に重要な要素であるといえます また IBM Power Systems による動的なリソース割り当てによって SQL 適用性能の最適化が容易に行えることも確認できました 今回の検証で確認できた点はミッションクリティカルなシステムに求められる可用性要件を検討するうえで重要な要素であるといえます 本検証では本番と同じサイト内にスタンバイを構成した環境を構築して高速に本番と待機システムを切り替えることによって可用性の高いシステムを構築できることを確認しました 地震や火災 テロといったサイト障害からもデータを保護するためには 更に災害サイトを遠隔地に構築することでそのシステムの可用性は最大となると考えられます

21 謝辞 2006 年 11 月 日本オラクル株式会社は日本アイ ビー エム株式会社やグリッド戦略パートナー各社と協業体制を確立し 企業のシステム基盤の最適化を実現する次世代のビジネス ソリューションを構築するため 先鋭の技術を集結した Oracle GRID Center( オラクル グリッド センター ) ( ) を開設しました 本稿は Oracle GRID Centerの趣旨にご賛同頂いたシスコシステムズ合同会社のハードウェア ソフトウェアのご提供および技術者によるご支援などの多大なるご協力を得て作成しております 協賛企業各社およびご協力頂いた技術者に深く感謝いたします

22 補足 試験環境詳細 H/W 構成マシン情報本検証で使用したサーバおよびクライアントマシンのスペックは下記の通りです DB サーバ 筐体 IBM Power Systems 570 CPU/Memory 情報 Item Processor(s) Total Physical Memory Swap: Max Size Value 4 Processor(s) Installed [01]: PowerPC_POWER MHz [02]: PowerPC_POWER MHz [03]: PowerPC_POWER MHz [04]: PowerPC_POWER MHz MB 3072 MB クライアント 筐体 IBM BladeCenter CPU/Memory 情報 Item Value Processor(s) 4 Processor(s) Installed [01]: Intel(R) Xeon(R) CPU 2.66GHz [02]: Intel(R) Xeon(R) CPU 2.66GHz [03]: Intel(R) Xeon(R) CPU 2.66GHz [04]: Intel(R) Xeon(R) CPU 2.66GHz Total Physical Memory 3946 MB Swap: Max Size 4031 MB

23 ストレージストレージ構成は下記の通りです ストレージ装置 IBM DS A 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 を取得しています - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 23

24 注意事項 nmon は IBM 社の製品ではありません 参考資料 マニュアル :Oracle Database 高可用性関連マニュアル データベースの全般的な高可用性については 下記のマニュアルに記述があります Oracle Database 高可用性概要 10g リリース 2(10.2)B Oracle Database 高可用性ベスト プラクティス 10g リリース 2(10.2)B Oracle MAA Best Practices 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 関連ベスト プラクティス Optimizing Availability During Unplanned Outages Using Oracle Clusterware and RAC - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 24

25 日本オラクルコンサルティングサービスについて この文書は Oracle GRID Center での検証プロジェクトによって作成されました また 当検証プロジェクトには プロジェクトのリーディングおよび検証計画 検証作業の一部をコンサルティングサービス部門のコンサルタントも参画しています 日本オラクルのコンサルティングサービス部門 (Oracle Consulting Service Japan [OCSJ]) の中で テクノロジーコンサルティング本部では 約 200 名 5のコンサルタントが年間約 200 プロジェクトでテクノロジー製品全般に関する支援を行っています 支援対象のシステムには 本書で想定しているような高度なチューニングが必要なシステムの他 高可用性 高拡張性 ハイパフォーマンスなど高いサービルレベルの要求されるシステム 大規模システム 新機能実装システムなどが数多く含まれており これらシステムの実践的な構築スキルやノウハウを日々蓄積しています 企業システムにおける最適な戦略の企画 策定から 迅速なインプリメンテーション 安定稼働まで 日本オラクルのコンサルティングサービスは お客様特有のニーズを満たしたサービスを提供します 日本オラクルのコンサルティングサービスに関するお問い合わせは Oracle Direct ( まで 年 12 月現在 - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 25

26 日本オラクル株式会社 Copyright 2008 Oracle Corporation Japan. All Rights Reserved. 無断転載を禁ず この文書はあくまでも参考資料であり 掲載されている情報は予告なしに変更されるこ とがあります 日本オラクル社は本書の内容に関していかなる保証もいたしません また 本書の内容に関連したいかなる損害についても責任を負いかねます Oracle JD Edwards PeopleSoft 及び Siebel は 米国オラクル コーポレーション及びその子会社 関連会社の登録商標です その他の名称は 各社の商標または登録商標です 文中に参照されている各製品名及びサービス名は米国 Oracle Corporation の商標または登録商標です その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります - IBM Power Systems 上での Oracle Data Guard SQL 適用における性能検証 - 26