Data Guard REDO転送とネットワークのベスト・プラクティス：Oracle Database 10g Release 2

Transcription

1 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 Oracle Maximum Availability Architecture ホワイト ペーパー 2007 年 1 月 Maximum Availability Architecture Oracle Best Practices for High Availability

2 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 はじめに... 3 概要... 3 本番データベースのパフォーマンスに与える影響の最小化... 3 最高レベルのデータ保護... 4 スイッチオーバーとフェイルオーバーの高速化... 4 REDO 転送のベスト プラクティス... 4 十分な帯域幅について... 5 ARCH REDO 転送... 6 LGWR ASYNC REDO 転送... 6 LGWR SYNC REDO 転送... 7 すべての REDO 転送... 7 ネットワーク チューニングのベスト プラクティス... 8 Oracle Net のセッション データ ユニット (SDU) サイズ... 8 TCP ソケットのバッファ サイズ... 9 ネットワーク デバイスのキュー サイズ スタンバイ I/O チューニングのベスト プラクティス REDO 転送サービスのパフォーマンス チューニング 本番データベースのパフォーマンス評価 Data Guard に関連する待機イベント LGWR SYNC チューニングの例 LGWR ASYNC チューニングの例 ARCH パフォーマンスの最適化 ネットワーク パフォーマンス問題の診断 付録 A - REDO 転送の拡張 LGWR ASYNC の拡張 ARCH の拡張 ネットワーク送信サイズの拡張 付録 B REDO 転送のパフォーマンス テスト ネットワーク送信サイズ - ネットワーク利用率の向上 ARCH 転送 - リモート アーカイブの迅速化 LGWR ASYNC - 本番データベースのオーバーヘッドの軽減 LGWR ASYNC - データ保護の強化 LGWR SYNC - ネットワークの待機時間による影響 付録 C - COMMIT NOWAIT と COMMIT WAIT の比較 参考資料 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 2

3 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 はじめに Oracle Data Guard 構成[1] のパフォーマンス チューニングを行う際に考慮すべき領域が 2 つあります 1 つは 本番データベースで生成されたREDOデータを ローカルまたはリモートのスタンバイ データベースに送信する REDO 転送サービスです もう 1 つは REDOデータをスタンバイ データベースに適用する ログ適用サービスです この Maximum Availability Architecture (MAA) [2] ホワイト ペーパーでは REDO 転送サービスのパフォーマンスを最適化するためのベスト プラクティスに焦点を当てます REDO Apply [3] を使用したフィジカル スタンバイ データベースへのログ適用サービスと SQL Apply [4] を使用したロジカル スタンバイ データベースへのログ適用サービスのベスト プラクティスについては 別のMAAホワイト ペーパーで説明します MAAホワイト ペーパーは Oracle Technology Network (OTN: および OTN-Japan ( から入手できます また このホワイト ペーパーでは オラクルの MAA テストの結果を記載しています テスト結果は 構成を正しくチューニングすれば パフォーマンスが向上できることを示しています 以前のリリースの Data Guard を使い慣れているユーザーには Oracle Data Guard 10g Release 2 ( ) で導入された REDO 転送の拡張機能についての説明が含まれています 注 : このホワイト ペーパーでは 読者がOracle Data GuardのREDO 転送サービスに精通しており Oracle Data Guard 概要および管理 [5] について把握していることを前提としています 概要 Oracle Data Guard 10g Release 2 では さまざまなネットワーク環境とアプリケーション ワークロードにおいて リカバリ ポイント目標とリカバリ時間目標が大幅に強化されました オラクルの Maximum Availability Architecture (MAA) 開発チームが実施したテスト ( 後述 ) では 以下のメリットが明らかになりました 本番データベースのパフォーマンスに与える影響の最小化 以下は MAA テスト結果に基づいた十分なネットワーク帯域幅がある現実的な構成のシナリオです Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 3

4 同期転送モードを使用した ニューヨークとモントリオール間 ( 最大距離 330 マイル RTT10ms) の Data Guard 環境で 最大 4MB/ 秒の速度で REDO データを生成する本番データベースに与えるパフォーマンスの影響を最小限に抑えて (5% 未満 ) データ損失ゼロを実現することが可能 非同期転送モードを使用した ボストンとロンドン間 ( 最大距離 3,300 マイル RTT10ms) の Data Guard 環境で 最大 20MB/ 秒の速度で REDO データを生成する本番データベースに与えるパフォーマンスの影響を 5% 未満に抑えることが可能 最高レベルのデータ保護データベース パフォーマンスへの影響を最小化することで ユーザーは Data Guard を使用してデータ保護レベルを飛躍的に向上させることができます さまざまなアプリケーション ワークロードや 本番サイトとスタンバイ サイトの距離が最大数百マイルに及ぶネットワーク トポロジに対して 同期型のデータ損失ゼロの保護を利用できます より長距離の環境や ネットワークの待機時間がさらに長い Data Guard 環境では 非同期転送モードが利用できます たとえば REDO 速度 2MB/ 秒 ( 高スループットのアプリケーション標準 ) の非同期転送モードを香港とシンガポール間で使用した場合 データ損失の危険性を 3 秒未満に抑えることができます ( 最大距離 1,600 マイル RTT50ms) ARCH REDO 転送の機能強化によって 拡張ネットワークやスタンバイ システムの停止が発生した後の本番データベースとスタンバイ データベース間の再同期速度が向上しました たとえば ARCH を使用した 1GB のログ ファイル転送に必要な時間は 最大 55% 短縮されています 本番データベースとスタンバイ データベースを迅速に再同期することによって 重要なデータを素早く保護状態に戻します スイッチオーバーとフェイルオーバーの高速化 Oracle Data Guard 10g Release 2 では 非同期モードの機能強化によって スタンバイ データベースへのデータの転送および適用に必要な時間が短縮されます スタンバイ データベースと本番データベースの同期がより頻繁に実行されるため スタンバイ データベースから本番データベース ロールへのロール移行は数秒で完了します [6] ここからは ネットワークとシステム環境に最高レベルのデータ保護を実現する Oracle Data Guard の REDO 転送とネットワークのベスト プラクティスについて詳しく説明していきます REDO 転送のベスト プラクティス Oracle Data Guard では REDO 転送を行う方法として ARCH LGWR ASYNC および LGWR SYNC の 3 つがあげられます [5] 次の項では それぞれの REDO 転送方法に適用するネットワーク要件と構成のベスト プラクティスの決定における検討事項について説明します Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 4

5 十分な帯域幅についてすべての Data Guard 構成における目的は リカバリ時間目標とリカバリ ポイント目標を達成する速度で リモートの障害リカバリ サイトへの REDO データ転送を行うことにあります 必要な容量を処理するための帯域幅が不足していれば どんなにチューニングを行ってもこの目的を達成することはできません 必要な帯域幅を知るために 本番データベースで生成される REDO データの量を見積もることから開始します データ量を測定できる既存の本番アプリケーションかテスト環境で実行されるアプリケーションがあれば理想的です REDO データ量についてのアプリケーション スループットを決定するためのもっとも簡単な方法は 通常のワークロードとピークのワークロードにおける AWR レポートを収集して 本番データベースが生成する REDO データの 1 秒あたりのバイト数を測定することです たとえば ピーク時にアプリケーションが 3MB/ 秒の REDO データを生成する場合 プライマリ データベースとスタンバイ データベース間のネットワーク リンクには 最低でも 3MB/ 秒の送信ネットワーク帯域幅が必要です ネットワーク帯域幅は メガビット / 秒 (Mbps) で表されます 変換すると 3MB/ 秒は 25.2Mbps のネットワーク スループットになります (1MB = バイト 1 バイト = 8 ビット 100 万ビット = 1 メガビットであるため 25.2Mbps になります ) この容量は T1/DS1 リンクの処理能力 ( 帯域幅 1.544Mbps) を超えており T3/DS-3 リンク ( 帯域幅 44.7Mbps) の範囲になります また 実際に達成されるスループットに影響を及ぼす ネットワークや基盤となる TCP/IP プロトコルのさまざまな特性について考慮する必要があります これらには ネットワークの肯定応答や ネットワークの待機時間 その他の要因によって発生するオーバーヘッドが含まれます これらの影響はそれぞれのワークロードやネットワークによって異なり 達成可能な実際のネットワーク スループットを低下させます 注 : 通常 待機時間と距離には直接的な相関関係があり 一般的な目安としては 33 マイル (53km) あたり 1 ミリ秒のRTTになります この数字は目安であり ネットワーク構成によって異なります 距離 ( 伝播遅延 ) は待機時間に影響を与え 待機時間はネットワークのRTTに影響を与えます ただし リピーターの数 ネットワーク トラフィック 貧弱なシステム パフォーマンス ネットワークの混雑など ネットワークのRTTに影響を及ぼす要因は他にもあります したがって このホワイト ペーパーに含まれるMAAテスト結果では 距離に対するネットワーク待機時間の比率ではなく ネットワークのRTTを使用しています ネットワークRTTは Trace Route ユーティリティを使用して簡単に測定でき ネットワークRTTの基準値が他の環境と比較する際の基盤となります 帯域幅要件を決定するための追加の考慮事項として 使用する Data Guard の保護モードと転送サービスがあげられます たとえば Data Guard の LGWR SYNC 同期転送は REDO データの生成速度に対応できる十分な帯域幅がない場合 本番データベースのパフォーマンスに影響を与えます ( これは すべての同期転送方式に該当します ) Data Guard の LGWR ASYNC 転送では オンラインの REDO ログを使用してピーク時の REDO 生成をバッファに格納することで 本番データベースのパフォーマンスに影響を与えることなく 一時的にネットワークの最大スループットを越えられるようにします Data Guard の ARCH 転送では ローカ Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 5

6 ル アーカイブ ログをバッファとして使用することによって同様の結果をもたらします ( ただし 潜在的なデータ損失の危険性は LGWR ASYNC より高くなります ) このホワイト ペーパーの説明に従って REDO データ量とネットワーク帯域幅の初期評価を行うことを推奨します 取得したデータを出発点として 期待される本番環境を代表する環境 ( システム リソースとネットワーク リソース ネットワークの待機時間 Data Guard の保護モード ) でワークロードをテストします テストでは このホワイト ペーパーで説明するチューニングの推奨事項とベスト プラクティスを必ず実装してください プライマリ データベースとスタンバイ データベースの間に必要な帯域幅を決定したら それぞれの転送タイプごとに以下のベスト プラクティスを実装します ARCH REDO 転送 ARCn プロセスの数を増やすことを検討します データベース作成時の ARCn プロセスの数は デフォルトで 2 です 初期化パラメータ LOG_ARCHIVE_MAX_PROCESSES によって ARCn プロセスの最大数が制御されます Oracle Database 10g Release 2 では このパラメータは最大で 30 まで設定できます 以前のリリースでの最大値は 10 でした ARCn プロセスの数を増やすと 拡張ネットワークやスタンバイ データベースの停止中に発生するアーカイブ ログのギャップを迅速に解消できます また ARCn プロセスに大きい数字を指定することによって リモートのアーカイブ並列処理がサポートされます これは 次の項で説明する MAX_CONNECTIONS 属性を使用して有効にできます 注 :LOG_ARCHIVE_MAX_PROCESSESに高い値を設定すると 同じネットワーク リソースを使用する他のアプリケーションとの競合が増加する場合があります したがって LOG_ARCHIVE_MAX_PROCESSESに最適な値を決定する場合 他のアプリケーションへの影響を考慮してください 最適値は それぞれの環境で 大きなアーカイブ ログのギャップを含むシナリオをテストすることによってのみ決定できます すべての宛先に対して MAX_CONNECTIONS 属性を 2 以上に設定します (LOG_ARCHIVE_DEST_n 初期化パラメータを使用 ) これによって リモートのアーカイブ並列処理が有効になり アーカイブ ログの転送に必要な時間が大幅に短縮できます MAX_CONNECTIONS に設定できる最大値は 5 です LGWR ASYNC REDO 転送 Oracle Database 10g Release 2 から LNS が本番データベース上のオンライン REDO ログを読み取る I/O に 十分な I/O 帯域幅を確保する必要があります どのくらい読取りが増加するかはワークロードによって異なるため パフォーマンス テストを実施して判断してください Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 6

7 LGWR SYNC REDO 転送 NET_TIMEOUT 属性の値を減らすことによって ネットワークの停止が本番データベースのパフォーマンスに与える影響を軽減します この属性によって 本番データベース上の LGWR がリクエストに対する Oracle Net Services からの応答を何秒待つかを指定できます Oracle Database 10g Release 2 では NET_TIMEOUT のデフォルト値は 180 秒です [5] 最小値として 1 を設定できますが スタンバイ データベースの不要な切断を避けるため 最小値は 10 秒を推奨します 注 : この値を 10 秒より低く設定する場合は ご使用の環境を理解してから最適値を決定してください たとえば この値を 2 秒に設定し 3 秒間の一時停止がたびたび発生するネットワークをご使用の場合 タイムアウトが頻発し データ保護レベルに影響を及ぼします LGWR SYNC を使用する場合 トランザクションの REDO がローカルのプライマリ データベースとリモートのスタンバイ データベースに書き込まれるまで コミットはフォアグラウンドに返されません オプションの COMMIT NOWAIT パラメータを使用すると REDO がディスクに書き出されるのを待つことなく コミットがアプリケーションに返されます したがって アプリケーションやトランザクションで COMMIT NOWAIT を利用すると デフォルトの COMMIT WAIT を利用した場合と比較して 応答時間とデータベースのスループットが飛躍的に向上します 詳しくは このホワイト ペーパーの付録 C を参照してください すべての REDO 転送 スタンバイの REDO ログの I/O をチューニングして効率化します これによって 本番データベース上の送信プロセス (LNS と ARCH) 速度を低下させることなく RFS プロセスはスタンバイ データベースへの書込みを行うことができます RFS は スタンバイ データベース上の Data Guard プロセスであり REDO データを受け取って スタンバイの REDO ログに書き込みます スタンバイの I/O サブシステムをチューニングするための代表的な領域には次が含まれます ストレージ アレイの単一 I/O リクエストとして 1MB の I/O が発行されるようにシステムを設定します Linux の構成についての詳細は Best Practices for Creating a Low-Cost Storage Grid for Oracle Databases [7] を参照してください スタンバイの REDO ログが 高速ディスク グループ内に正しく配置されていることを確認します スタンバイの REDO ログを多重化しないでください 余分な書込みを避けるため 追加のスタンバイ REDO ログ メンバーを削除します Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 7

8 ネットワーク チューニングのベスト プラクティス この項では すべての REDO 転送方法にあてはまり Data Guard の REDO 転送パフォーマンスを飛躍的に向上させる可能性のあるネットワーク チューニングについて説明します オラクルの MAA テストで測定されたパフォーマンス向上の例については 後述します 次の項以降に示すサンプル コマンドは Linux 向けであり プラットフォームによって異なります 詳しくは後述しますが 一般に ネットワーク チューニングには以下が含まれます スタンバイ ロケーションに転送する REDO データの量に十分対応できる帯域幅であることを確認します Oracle Net の RECV_BUF_SIZE と SEND_BUF_SIZE パラメータを 帯域幅遅延積 (BDP) の 3 倍に設定します これによって ネットワーク スループットの伸び率を最大にできます Oracle Net のセッション データ ユニット (SDU) サイズを に設定します ネットワーク デバイスに設定された送信キューと受信キューのデフォルト サイズを増やします Linux の場合 ifconfig コマンドを使用して送信側の TXQUEUELENGTH インタフェース オプションを増やし 受信側では NET_DEV_MAX_BACKLOG カーネル パラメータを増やします 将来のロール移行への事前対策として 本番データベースとすべてのスタンバイ データベースで両方のパラメータを変更しておくことを推奨します Oracle Net の TCP_NODELAY パラメータが YES( デフォルト値 ) に設定されていることを確認します Oracle Net のセッション データ ユニット (SDU) サイズネットワーク上にデータを送信する際 Oracle Net はセッション データ ユニット (SDU) で指定されたサイズのユニットごとに データをバッファに格納します 大量のデータを送信する場合やメッセージ サイズが一貫している場合 SDU バッファのサイズを増やすことでパフォーマンスとネットワークの利用効率を向上させることができます SDU サイズは Oracle Net の接続記述子内で設定することも sqlnet.ora を使用してグローバルに設定することも可能です [8] Oracle Data Guard Broker の構成においては sqlnet.ora ファイルの DEFAULT_SDU_SIZE パラメータを設定してください DEFAULT_SDU_SIZE=32767 Oracle Data Guard Broker 以外の接続記述子を使用する構成においては プライマリ データベースの sqlnet.ora ファイルで現在の設定を変更できます 接続記述子を使用して SDU サイズを設定する場合 動的なサービス登録は DEFAULT_SDU_SIZE で定義されたデフォルトの SDU サイズを使用するため 静的 SID を使用する必要があります 接続記述子の記述リストに SDU パラメータを指定します sales.us.acme.com= Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 8

9 (DESCRIPTION= (SDU=32767) (ADDRESS=(PROTOCOL=tcp) (HOST=sales-server) (PORT=1521)) (CONNECT_DATA= (SID=sales.us.acme.com)) ) スタンバイ データベースでは listener.ora ファイルの SID_LIST で SDU を 設定します SID_LIST_listener_name= (SID_LIST= (SID_DESC= (SDU=32767) (GLOBAL_DBNAME=sales.us.acme.com) (SID_NAME=sales) (ORACLE_HOME=/usr/oracle))) TCP ソケットのバッファ サイズ TCP ソケットのバッファ設定によって ネットワーク回線上で使用できる帯域幅に関係なく 使用可能なネットワーク帯域幅が制御されます 使用可能な帯域幅の利用効率を向上させるには ソケットのバッファ サイズをデフォルト値から増やす必要があります ネットワークの待機時間が高い値を示す場合 ソケットのバッファ サイズを増やしてネットワーク帯域幅を十分に活用する必要があります 最適なソケット バッファ サイズは 帯域幅遅延積 (BDP) の 3 倍です BDP を算出するには リンクの帯域幅とネットワークのラウンド トリップ時間 (RTT) が必要です RTT は ネットワーク通信が本番データベースからスタンバイ データベースへ伝わり さらに元へ戻るために必要な時間であり ミリ秒 (ms) で測定されます 次の例では 25 ミリ秒の RTT を持つギガビット ネットワーク リンクを想定しています BDP= 1,000 Mbps * 25msec (.025 sec) 1,000,000,000 * ,000,000 Megabits / 8 = 3,125,000 bytes この例では 送信および受信ソケットの最適なバッファ サイズは以下のとおりに計算されます ソケット バッファ サイズ = 3 帯域幅 遅延 = 3,125,000 * 3 = 9,375,000 バイトソケットのバッファ サイズは オペレーティングシステム レベルまたは Oracle Net レベルで設定できます ソケットに必要なバッファ サイズは非常に大きくなることがあるため ( ネットワークの状態による ) Oracle Net レベルでの設定を推奨します [8] そうすることで telnet などの通常の TCP セッションで余分なメモリが使用されることを回避します すべての送信および受信ソケット バッファの最大サイズを指定するパラメータが含まれているオペレーティングシステム Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 9

10 があることに注意してください Oracle Net でより大きいソケット バッファ サ イズを使用できるように これらの値を調整する必要があります Oracle Data Guard Broker または Oracle Enterprise Manager の構成では sqlnet.ora ファイルを使用して 必要な送信および受信バッファ サイズを指 定します 例 : RECV_BUF_SIZE= SEND_BUF_SIZE= Oracle Data Guard Broker 以外の接続記述子を使用する構成において 特定のプロ トコル アドレスまたは記述に対してバッファ領域パラメータを指定します 次の例では 送信および受信ソケットのバッファ サイズを クライアント側の sqlnet.ora ファイル内で特定の接続記述子の記述属性として指定しています standby = (DESCRIPTION= (SEND_BUF_SIZE= ) (RECV_BUF_SIZE= ) (ADDRESS=(PROTOCOL=tcp) (HOST=hr1-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=standby))) ソケット バッファ サイズは Data Guard 構成内すべてのサイトで設定する必要があります スタンバイ データベースでは sqlnet.ora ファイルまたは listener.ora ファイルを使用して指定できます listener.ora ファイルでは 特定のプロトコル アドレスまたは記述に対して バッファ領域パラメータを指定できます LISTENER= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp) (HOST=sales-server)(PORT=1521) (SEND_BUF_SIZE= ) (RECV_BUF_SIZE= ))) ネットワーク デバイスのキュー サイズカーネル ネットワーク サブシステムと ネットワーク インタフェース カードのドライバとの間のキュー サイズを調整できます すべてのキューには ローカル バッファのオーバーフローによる損失を発生させないようなサイズを指定する必要があります したがって それぞれのネットワーク接続に最適なキュー サイズを設定するには 慎重にチューニングを行う必要があります 高帯域幅のネットワークの場合は特に注意が必要です ローカル キューに損失が発生すると TCP が混雑制御を始めることによって TCP の送信速度が制限されるため これらの設定は 特に TCP にとって重要です Linux の場合 インタフェース送信キューとネットワーク受信キューの 2 つのキューについて考慮する必要があります 送信キューのサイズは ネットワーク インタフェース オプションの txqueuelen を使用して設定します ネットワーク受信キューのサイズは カーネル パラメータの netdev max_backlog を使用して設定します 例 : Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 10

11 echo > /proc/sys/net/core/netdev_max_backlog echo 1 > /proc/sys/net/ipv4/route/flush ifconfig eth0 txqueuelen txqueuelen のデフォルト値である 100 は 長距離の高スループット ネットワーク回線には不十分です たとえば 待機時間が 100 ミリ秒であるギガビット ネットワークの場合 txqueuelen に少なくとも を指定する必要があります 待機時間に応じたキュー サイズの設定については オペレーティングシステムのベンダーに問い合わせてください 次の表に MAA テストにおける TCP ソケットのバッファ サイズとネットワーク デバイスのキュー サイズを調整することで得られたネットワークの改善結果を示します 表 1:TCP/IP のチューニング効果 テスト段階 テスト時間 ( 秒 ) 転送データ量 達成されたネット ワーク スループッ ト ( メガビット / 秒 ) 変化率 チューニング前 MB 10.8Mbps 該当なし ネットワーク ソケットのバッファ サイズを デフォルトの 16K から 3 BDP に変更した後上記の調整を行った上で デバイス キューの長さをデフォルトの 100 から 1,000 に増やした後 GB 731.0Mbps チューニング前のベースラインに対して 665% の改善 GB 937.0Mbps 28% の改善 スタンバイ I/O チューニングのベスト プラクティス REDO データは スタンバイで受信された後にディスクに書き込まれます 構成によっては REDO を受信した肯定応答をプライマリに送り返す前に ディスクへの書込みを行う必要があります したがって スタンバイの I/O を最適化することが重要です スタンバイの I/O パフォーマンスを向上させるには 以下のベスト プラクティスを検討してください 1. Oracle データベースが ASYNC I/O を利用できることを確認します Oracle データベースは デフォルトで非同期 I/O を使用するように設定されています また オペレーティングシステム Host Bus Adapter(HBA) ドライバ およびストレージ アレイを正しく設定する必要があります 2. I/O スタックのすべてのレイヤーで I/O 書込みサイズを最大化します レイヤーには次のうちの 1 つ以上が含まれます オペレーティングシステム ( 非同期書込みサイズを含む ) デバイス ドライバ ストレージ ネットワーク転送サイズ ディスク アレイ 3. SRL を配置する ASM ディスク グループには プライマリのオンライン Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 11

12 REDO ログのある ASM ディスク グループと同じ またはそれ以上のディスクを備えてください 4. スタンバイの REDO ログを多重化しないでください 5. 通常 RAID5 構成の RAID コントローラは ミラーリング構成の場合と比べて 書込みのパフォーマンスが低下します SRL への書込みプロセスがボトルネックになっている場合は RAID 構成の変更を検討してください REDO 転送サービスのパフォーマンス チューニング 上述のとおり Data Guard 構成のパフォーマンスに影響を及ぼす要因には 保護モード 選択した転送オプション ネットワークの帯域幅と待機時間 およびオンライン REDO ログとスタンバイ REDO ログに対する I/O パフォーマンスが含まれます この項では これらの要因が本番データベースのパフォーマンスに影響を与える可能性を評価する方法と この影響を最小限に抑えるための設定のチューニング方法を示します 本番データベースのパフォーマンス評価すべてのパフォーマンス チューニング作業における第一歩は 良いベースラインを集めることです Data Guard の転送サービスを実装する前に 通常時ワークロードとピーク時ワークロードについての AWR レポートを収集します AWR の自動スナップショット間隔を 10~20 分に短く設定して ストレス テスト中のパフォーマンス ピークやピーク ロードを取得します 通常の運用では 60 分間隔で十分です 本番データベースのスループットやパフォーマンスの良い指標を得るための ベースラインとなる AWR レポート内で調査すべき主な項目は 以下のとおりです REDO データ量 - このレポート中に生成された REDO データのバイト数 トランザクション - レポートに対する TPS REDO 書込み数 - このレポート中に実行された REDO の書込み数 'REDO データ量 ' を 'REDO 書込み数 ' で割った数が REDO 書込みサイズの平均バイト数になります 分析しているパフォーマンスが LGWR SYNC または LGWR ASYNC ( 後述 ) を使用している場合 これは重要な基準値になります AWR レポートから得られたデータの使用に加えて V$SYSMETRIC_HISTORY ビューを調べることで 本番データベースの応答時間を測定できます このビューに含まれる情報は ユーザー クエリーへの応答時間の良い指標となります このビューを調べる場合 次の基準値について検討してください トランザクションあたりの応答時間 - トランザクションに対する応答時間 SQL サービス応答時間 - ユーザー コールあたりの応答時間 ( センチ秒 ) 1 秒あたりのデータベース時間 - DB 時間 ( センチ秒 )/ 経過時間 ( 秒 ) 適切なベースラインを得た後で Data Guard 機能を有効にして 通常運用とピーク運用における AWR レポートを収集します これらの AWR レポートをベースラインと比較することで Data Guard 機能を有効にした場合の本番データベースのパ Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 12

13 フォーマンスを導き出します このプロセスの詳細については後述します Data Guard に関連する待機イベント本番データベースからスタンバイ データベースへの REDO データ送信にかかる時間は 主にネットワークを横断する時間とスタンバイ ホスト上のディスクに書き込む時間の 2 つに分類されます 合計時間を収集する待機イベントは本番データベース上で取得しますが I/O にかかる時間はスタンバイ データベース上で参照します 以下の待機イベントは ARCH もしくは LGWR(SYNC または ASYNC) プロセスを使用して 本番データベースからスタンバイ データベースへ REDO データを送信するプロセスで発生するイベントです これらの待機イベントは 本番データベースから取得されます 表 2: プライマリ データベース上の主要な Data Guard 待機イベント イベント名プロセス説明 ARCH wait on ATTACH ARCH wait on SENDREQ ARCH wait on DETACH LNS wait on ATTACH LNS wait on SENDREQ LNS wait on DETACH LGWR wait on LNS LNS wait on LGWR LGWR-LNS wait on channel ARCH ARCH ARCH LGWR LGWR LGWR LGWR LGWR LGWR この待機イベントは すべてのアーカイバ プロセスが新しい RFS 接続を作成するために費やす時間を監視します この待機イベントは すべてのアーカイバ プロセスがローカル ディスクとリモートにアーカイブ ログを書き込むために費やす時間を監視します この待機イベントは すべてのアーカイバ プロセスが RFS 接続を削除するために費やす時間を監視します この待機イベントは すべての LNS プロセスが新しい RFS 接続を作成するために費やす時間を監視します この待機イベントは すべての LNS プロセスが受信 REDO をディスクに書き込む時間と リモートのアーカイブ REDO ログの開いて閉じる時間を監視します この待機イベントは すべての LNS プロセスが RFS 接続を削除するために費やす時間を監視します この待機イベントは ログ ライター (LGWR) プロセスが LNS プロセスからのメッセージを受信するために待機する時間を監視します この待機イベントは LNS プロセスがログ ライター (LGWR) プロセスからのメッセージを受信するために待機する時間を監視します この待機イベントは ログ ライター (LGWR) プロセスまたは LNS プロセスがメッセージを受信するために待機する時間を監視します Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 13

14 プライマリ データベースで監視する必要のある 重要な I/O 関連の待機イベン トには次が含まれます 表 3:Data Guard に関連する主要なデータベース待機イベント イベント名プロセス説明 Log File Sync Log File Parallel Write DB File Sequential Read LGWR LGWR Foreground フォアグラウンドでトランザクションがコミットされてから LGWR がフォアグラウンドにコミットの完了を通知するまでの待機時間 ユーザー セッションがコミットされたら セッションの REDO 情報は REDO ログ ファイルに書き込まれる必要があります ユーザー セッションは ログ バッファを REDO ログ ファイルに書き込むよう LGWR に通知します LGWR は 書込みが終了するとユーザー セッションに通知します LGWR の I/O がコミットの書込みを完了するために費やす時間 REDO レコードはパラレルで書き込まれますが 最後の I/O がディスク上に保存されるまで完了しません データベースからの順次読取りが実行される間のセッション待機時間 このイベントは 制御ファイルの再作成 データファイル ヘッダーのダンプ およびデータベース ファイル ヘッダーの取得にも使用されます ログ転送サービスに関連するスタンバイの I/O 待機イベントの参照は スタンバイ上で実行します I/O 待機イベントは フィジカル スタンバイとロジカル スタンバイの両方で変わりませんが 収集方法は異なります スタンバイがロジカル スタンバイである場合 AWR レポートを使用して待機イベントを参照します スタンバイがフィジカル スタンバイである場合 SQL クエリーを使用して情報を取得します フィジカル スタンバイでは 次のクエリーを使用できます SQL> SELECT EVENT, TOTAL_WAITS, ROUND(TIME_WAITED/100) "TIME(S)", AVERAGE_WAIT*10 "AVG(MS)", TO_CHAR(SYSDATE, 'DD-MON-YYYY HH:MI:SS') TIME FROM V$SYSTEM_EVENT 次の待機イベントは スタンバイ上で I/O の実行に費やされる時間を示します 表 4: スタンバイ データベース上の主要な Data Guard 待機イベント イベント名プロセス説明 RFS Write RFS スタンバイ REDO ログまたはアーカイブ ログへの書込みに費やされる時間と REDO ブロックのチェックサム検証など I/O 以外の処理に費やされる時間 RFS random i/o RFS スタンバイの REDO ログへの書込みに費やされる時間 RFS sequential i/o RFS アーカイブ ログへの書込みに費やされる時間 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 14

15 上記の待機イベントに費やされる時間は 平均的な書込みサイズとストレージ アレイの I/O 容量に依存します チューニングに関するアドバイスについては このホワイト ペーパーの " スタンバイ I/O チューニングのベスト プラクティス " の項を参照してください LGWR SYNC チューニングの例 Data Guard に関するドキュメント [5] で説明されているとおり LGWR SYNC の REDO 転送は同期プロセスであり 以下のアクションが完了するまで ユーザー コミットに対するデータベースの肯定応答は送られません 1. LGWR によって 本番データベースのオンライン REDO ログに REDO が書き込まれる (LGWR SYNC が使用されていない場合は この手順が完了すると ユーザー コミットに肯定応答が返されます ただし 付録 C に説明されている COMMIT NOWAIT パラメータが使用されている場合を除きます ) 2. 本番データベース上の Data Guard LNS プロセスが スタンバイ データベース上の Data Guard RFS プロセスにネットワーク送信を実行する REDO 書込みサイズが 1MB を超える場合 LNS はスタンバイ上の RFS プロセスに複数のネットワーク送信を発行します 3. RFS プロセスが LNS によって送信された REDO を受信し スタンバイの REDO ログへの I/O を完了する 4. REDO が受信され ディスクに書き込まれたことを知らせる肯定応答が RFS プロセスから LNS に送り返される 5. スタンバイですべての REDO が正しく受信され ディスクに書き込まれたことが LNS から LGWR に通知される 本番データベース上で手順 1 にかかる時間は "Log File Parallel Write" 待機イベントで示されます 手順 2~5 にかかる時間は 待機イベント "LNS wait on SENDREQ" で示されます "LNS wait on SENDREQ" 待機イベントは スタンバイ上で取得される "RFS write" 待機イベントの時間を差し引くと ネットワーク時間と RFS の I/O 時間に分割できます これらの待機イベントをスタンバイ上で算定するには 上述の "Data Guard に関連する待機イベント " の項に説明されているクエリーを使用するか ( フィジカル スタンバイの場合 ) AWR レポートを使用します ( ロジカル スタンバイの場合 ) "RFS write" 待機イベントは I/O と RFS 処理の実行に必要な時間を示します 実際の RFS I/O 時間は "RFS random i/o" 待機イベントを調べることで算定できます 次の LGWR SYNC チューニングの例は 待機時間が 10 ミリ秒のギガビット ネットワークを使用して 1 秒あたり 152KB の REDO を生成する OLTP アプリケーションに基づいたものです ベースラインとなる AWR レポートを取得した後に フィジカル スタンバイが作成され 本番データベースは LGWR SYNC AFFIRM を使用してスタンバイに REDO を転送するよう設定されました 注 :AFFIRMでは スタンバイ データベースでREDOが受信されて スタンバイ REDOログへの書込みが終了するまで RFSは本番データベースへ肯定応答を送信しません これはLGWR SYNCのデフォルト設定です Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 15

16 ネットワークと I/O のチューニングを実行する前に アプリケーションが実行され AWR レポートが収集されました AWR レポートを分析した後で このホワイト ペーパーで説明されたチューニングの推奨事項が実行され 再度 AWR レポートが収集されました LGWR SYNC を有効にして行ったそれぞれのテストにおけるロード プロファイルは 以下のとおりです 表 5:LGWR SYNC でのロード プロファイル ロード プロファイル Data Guard 非使用時 Data Guard 使用時 REDO 速度 152,057 バイト / 秒 145,993 バイト / 秒 REDO 書込み数 REDO 書込みサイズ 1,109 バイト 1,280 バイト 次の表に テストの各段階における重要な待機イベントを示します I/O とログ ファイルの同期は アプリケーション パフォーマンスの良い指標となるので重要です 表 6:LGWR SYNC の待機イベント 待機イベント Data Guard 非使用時 Data Guard 使用時 log file sync db file sequential read log file parallel write 1 1 LNS wait on SENDREQ 該当なし 13 RFS random i/o 該当なし 2 注 : 待機イベントは ミリ秒で表示されています LNS wait on SENDREQ 待機イ ベントとRFS random i/o 待機イベントは Data Guard 機能が有効でない場合のベー スラインとしては適していません log file sync 待機イベントは よく調べる必要のある重要な待機イベントです log file sync(lfsy) 待機イベントは REDO がフラッシュされてコミットが永続的 になるまでの フォアグラウンドが待つ時間です log file sync 待機イベントは 以下に分かれます 1. LGWR のウェイクアップ ( アイドル状態にある場合 ) 2. LGWR による 書き込み対象の REDO の収集と I/O の発行 3. ログ書込み I/O の完了にかかる時間 4. LGWR I/O の後処理 5. LGWR からフォアグラウンドへの書込み完了通知 6. フォアグラウンドのウェイクアップ Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 16

17 手順 2 および手順 3 は "REDO 書込み時間 " 統計情報に累積されます 手順 3 は "log file parallel write" 待機イベントです システム負荷が増加すると 手順 5 および手順 6 の値は非常に大きくなります これは フォアグラウンドに通知が送られた後も OS が実行をスケジューリングするのに時間がかかる場合があるからです log file sync 待機イベントに高い値が確認される場合 合計待機時間を個々のコンポーネントに分類してから 時間のかかるコンポーネントのチューニングを行ってください 同時実行性の高いアプリケーションの場合 ネットワークの待機時間が長くなってもデータベース全体のスループットに与える影響はごくわずかですが 個別のトランザクションの応答時間は増加する場合があります 同時実行性の高いアプリケーションの待機時間が増加すると LGWR の平均書込みサイズも増加すると考えられます チューニングを実行した後 本番データベースのスループットに与える影響は 4% にまで下がりました 実行したチューニングには 以下の項目が含まれます スタンバイ システム上で /proc/sys/fs/aio-max-size を デフォルトの から に増加 スタンバイのログ ファイル グループから 2 番目のログ ファイル メンバーを削除 スタンバイ上の ASM ディスク グループにディスクを追加 RECV_BUF_SIZE および SEND_BUF_SIZE を帯域幅遅延積の 3 倍に設定 ネットワーク インタフェースに付随するデバイス キュー サイズをデフォルトの 100 から 10,000 に増加この例では REDO 書込みサイズが小さかったため ネットワークの送信および受信バッファ サイズを増加しても LNS のスループットへの大幅な効果は得られませんでした バッファ サイズの増加が効果を発揮するのは REDO 書込みサイズを増やしている場合です REDO 書込みサイズが小さい場合 もっとも大きいチューニングのメリットは スタンバイ上の I/O の最適化から得られます また LGWR SYNC が発行するスタンバイへのネットワーク送信の最大サイズは REDO 書込みサイズには関係なく デフォルトで 1MB であることに注意が必要です これによって REDO 書込みサイズが 1MB を超えるアプリケーションでは ネットワークのラウンド トリップが複数発生します この動作は Oracle Database 10g ( ) で変更されており 1MB より大きい REDO 書込みサイズに対応するよう変更されました Oracle Database 10g ( ) より以前のバージョンを使用していて REDO 書込みサイズが 1MB を超える場合 バージョンごとの最適化方法に関する詳細は MetaLink ノート を参照してください LGWR SYNC による本番データベースのパフォーマンスへの影響を大幅に軽減する必要がある場合 アプリケーションまたはその一部で COMMIT NOWAIT または非永続コミットが利用できるかどうかを確認します COMMIT NOWAIT IMMEDIATE を使用している場合 フォアグラウンド プロセスは LGWR にログ I/O の実行を通知しますが REDO が書き込まれるまで待つことはありません COMMIT NOWAIT BATCH の場合 フォアグラウンドはそのままアプリケーションに返されます 両方のケースにおいて フォアグラウンドはローカルの LGWR 書込みの完了や スタンバイでの REDO の受信を待たずに処理を再開できます Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 17

18 LGWR SYNC を有効にした場合 Oracle Real Application Clusters を使用したサンプルの OLTP ワークロードにおいて COMMIT NOWAIT BATCH を使用すると デフォルトの COMMIT IMMEDIATE WAIT と比較して次の結果が確認されました 10~35% の本番 REDO 速度の向上 10~35% のユーザー コール速度の向上 10~33% の本番トランザクション速度の向上 92% のユーザー コール応答時間の短縮 90% のトランザクション応答時間の短縮インスタンスまたはデータベースの障害時に非永続コミットを容認できる場合は この選択肢が最適です このようなタイプのアプリケーションの例には ショッピング カート アプリケーションがありますが 購入トランザクション 動向のサンプリング / 追跡システム データ ウェアハウス アプリケーションやデータ マート アプリケーションには適していません 詳しくは 付録 C を参照してください LGWR ASYNC チューニングの例 LGWR ASYNC は REDO がリモートに送信されるのを待つことなく ユーザー コミットを実行できる非同期転送サービスです LGWR ASYNC を効率的にチューニングするには 以下について考慮してください 1. LGWR が 本番データベースのオンライン REDO ログに REDO を書き込む 2. 本番データベース上の Data Guard LNS プロセスが オンライン REDO ログを読み取り スタンバイ データベース上の Data Guard RFS プロセスにネットワーク送信を実行する 3. RFS プロセスが LNS によって送信された REDO を受信する 4. RFS プロセスが REDO が受信されたことを知らせる肯定応答を LNS に送り返す 5. RFS プロセスが スタンバイの REDO ログに REDO を書き込む 手順 2~4 は 本番データベース上の待機イベント "LNS wait on SENDREQ" で示されます 手順 5 は 上述のクエリーを使用してスタンバイから取得された "RFS write" で示されます 実際の RFS 書込み時間は "RFS random i/o"( スタンバイの REDO ログへの書込み ) または "RFS sequential i/o"( アーカイブ ログ ファイルへの書込み ) で示されます "RFS write" 待機イベントは I/O と追加の RFS 処理の実行に必要な時間を表します これらの待機イベントをスタンバイ上で算定するには 上述の "Data Guard に関連する待機イベント " の項に説明されているクエリーを使用するか ( フィジカル スタンバイの場合 ) AWR レポートを使用します ( ロジカル スタンバイの場合 ) 次の LGWR ASYNC チューニングの例は 1 秒あたり 5.5MB を超える REDO を生成する OLTP アプリケーションです ベースラインとなる AWR レポートを取得した後に フィジカル スタンバイが作成され 本番データベースは LGWR ASYNC を使用してスタンバイに REDO を転送するよう設定されました ネットワークや Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 18

19 I/O のチューニングを実行する前に アプリケーションが実行され 新しい AWR レポートが収集されました 次に このホワイト ペーパーで説明されたチューニングの推奨事項が実行され 再度 AWR レポートが収集されました LGWR ASYNC を有効にして行った 3 つのテストにおけるロード プロファイルは 以下のとおりです 表 7:LGWR ASYNC でのロード プロファイル ロード プロファイル Data Guard 非使用時 Data Guard 使用時 REDO 速度 5.66MB/ 秒 5.49MB/ 秒 REDO 書込み数 上の表が示すとおり LGWR ASYNC を有効にしたことによる影響は約 4% でした この影響は 本番データベース上のオンライン REDO ログで LNS が追加のディスク読取りを実行したことに起因すると考えられます 実行したチューニングには 以下の項目が含まれます スタンバイ上で /proc/sys/fs/aio-max-size をデフォルトの から に増加 スタンバイのログ ファイル グループからログ ファイル メンバーを削除 スタンバイ上の ASM ディスク グループにディスクを追加 RECV_BUF_SIZE および SEND_BUF_SIZE を帯域幅遅延積の 3 倍に設定 ネットワーク インタフェースに付随するデバイス キュー サイズを増加 LGWR ASYNC を使用した場合 本番データベースのオーバーヘッドとチューニングによる影響はごくわずかに見えますが スタンバイへのネットワーク転送を効率化して REDO 転送における遅延を防止することは重要です これによって データ損失が発生する可能性を最小限に抑えます ネットワーク チューニングのメリットは 以下の表に示す待機イベントについて調べると より明らかになります 表 8:LGWR ASYNC の待機イベント 待機イベント Data Guard 非使用時 Data Guard 使用時 LNS wait on SENDREQ 該当なし 179 ミリ秒 RFS random i/o 該当なし 21 ミリ秒 注 : 待機イベントの平均値は ミリ秒で表示されています Data Guardが有効では ないので ベースラインとしては適さない待機イベントもあります 上の表が示すとおり LNS がネットワーク送信を実行するのに必要な時間は ス タンバイ上の I/O とネットワーク ソケットのバッファ サイズによって大幅に 影響を受けます LNS によって送信されるデータ量は ワークロードによって異 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 19

20 なる場合があることに注意してください LNS 送信サイズが分かれば ネットワークと I/O のテストを行って それぞれの段階で費やされた時間が妥当であるかどうかを確認できます LNS のネットワーク送信サイズを決定するには 本番データベース上で次のクエリーを実行します SQL> SELECT OPEN_COUNT, CLOSE_COUNT, WRITE_COUNT, MINIMUM_WRITE, MAXIMUM_WRITE, TOTAL_WRITE, LOGS_SKIPPED,TERMINATIONS FROM X$KCRRASTATS WHERE TOTAL_WRITE > 0; LNS 書込みサイズの平均値を取得するには TOTAL_WRITE を WRITE_COUNT で 割ります ARCH パフォーマンスの最適化どの REDO 転送を選択するかに関係なく 常に 1 つの ARCH プロセスが オンライン REDO ログのローカル アーカイブ用に使用されます (Oracle Data Guard 10g 以上 ) ARCH REDO 転送サービスが設定されている場合 はじめにローカル アーカイブを完了してから 次のロジックを使用して 別の ARCH プロセスによってリモート アーカイブが開始されます 1. ローカル アーカイブ ログから 10MB を読み取り スタンバイ上の RFS プロセスにネットワーク送信を発行する 2. RFS プロセスが ARCH プロセスによって送信された REDO を受信し Data Guard の構成方法に応じて スタンバイの REDO ログまたはアーカイブ REDO ログへの I/O を実行する 3. I/O が完了したら RFS が ARCH へ肯定応答を送り返す 4. ARCH が次の 10MB を読み取り 上記プロセスを繰り返す リモートのアーカイブ先に MAX_CONNECTIONS 属性が設定されている場合 1 つのアーカイブ ログのリモート送信に最大で 5 つの ARCH プロセス ( 設定により異なる ) を使用できます 実際の RFS 書込み時間は "RFS random i/o"( スタンバイの REDO ログへの書込み ) または "RFS sequential i/o"( アーカイブ ログ ファイルへの書込み ) で示されます ARCH wait on SENDREQ 待機イベントを調べて ARCH のパフォーマンスを判断すると 結果を誤る可能性があります これは ARCH の ping メカニズム ( スタンバイの可用性の定期的なチェック ) によるネットワーク アクティビティが この待機イベント内で取得されているため 誤った数字の原因となる場合があるからです ARCH のパフォーマンスを評価する方法としてもっとも信頼性が高いのは log_archive_trace のレベルを 128 に設定して アラート ログに表示される追加メッセージを取得することです タイムスタンプとアーカイブ ログのファイル サイズを使用して 全体的なスループットが算出できます LGWR SYNC または LGWR ASYNC では スタンバイ上のディスク I/O とプライマリのフラッシュ リカバリ領域を効率化するとともに ネットワーク ソケットのバッファ サイズを適切にすることが重要です ASYNC に対して実行したチューニング項目は ARCH に対しても実行する必要があります これらのチューニング項目に加えて リモート宛先の MAX_CONNECTIONS 属性に 5 を設定する必要があります これによって ARCH 転送の並列処理が有効になり 個々のアー Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 20

21 カイブ ログ ファイルの全体的なスループットが改善されます また LOG_ARCHIVE_MAX_PROCESSES 初期化パラメータは最高で 30 に設定することができ 最大で 30 個の ARCH プロセスを有効にします ( ローカル アーカイブ専用に 1 個 ローカルまたはリモートのアーカイブ用に 29 個 ) Oracle Database 10g Release 2 では デフォルト値は 2 です Data Guard を使用する場合 このデフォルト値を増やすことを推奨します ネットワークやスタンバイ データベースの停止によって スタンバイで発生したアーカイブ ログ ギャップが解決されると ARCH プロセスはローカル アーカイブによって消費されます また REDO 転送サービスがアーカイバ プロセスを利用するように設定されている場合は 通常のリモート アーカイブによって消費されます MAX_CONNECTIONS に設定した値に対応するため 最低限の必要な値を LOG_ARCHIVE_MAX_PROCESSES に設定します 追加の REDO ストリームをサポートする帯域幅がある場合 LOG_ARCHIVE_MAX_PROCESSES に ネットワークが対応できる最大値を設定することを検討してください これによって 複数のアーカイブ ログをパラレルで送信できるため ピーク時のワークロードの処理や ネットワークやスタンバイの障害によるログのアーカイブ ギャップの迅速な解決が可能になります ネットワーク パフォーマンス問題の診断はじめに ネットワーク チューニングの項に記載されているすべての項目が対応済みであることを確認します 問題が続く場合 OS レベルの標準的な診断手法を使用して ネットワーク パフォーマンスの問題とボトルネックを調査します OS ユーティリティを使用して 以下の項目について調べます 1. CPU アクティビティ 2. メモリ使用率 3. ネットワークのエラーと衝突 4. iperf などのツールを使用したネットワーク スループット [9] 5. TCP パケットのダンプ (sniffer トレース ) OS レベルのボトルネックを取り除き データベースのアラート ログとデータベースのダンプ出力先である bdump udump cdump を調べて エラーが発生していないことを確認します LGWR SYNC REDO 転送サービスを使用している場合 エラーが頻繁に発生したり スタンバイの RFS プロセスが切断されたりすると 本番データベースのオーバーヘッドが増加する場合があります Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 21

22 付録 A - REDO 転送の拡張 REDO 転送サービスは 本番データベースからローカルまたはリモートのスタンバイ データベースの宛先に REDO データを送信します リモートの送信先には 次のいずれかのタイプが含まれます Data Guard のスタンバイ データベース ( フィジカル スタンバイ データベースおよびロジカル スタンバイ データベース ) アーカイブ REDO ログ リポジトリ Oracle Change Data Capture のステージング データベース Oracle Streams のダウンストリーム取得データベース Oracle Database 10g Release 2 には 以下の REDO 転送サービスの拡張が含まれます LGWR ASYNC の拡張パフォーマンスの向上 :Oracle Database 10g Release 2 より以前のバージョンでは ネットワーク サーバー プロセス (LNSn) は ネットワークI/Oを発行した後 ネットワークI/Oの完了を待っていました それぞれのLNSnプロセスには ユーザー設定可能なメモリ内バッファが含まれ LGWRプロセスから送信 REDOデータを受け入れます LNSnプロセスの処理が追いつかずに ( ピーク時のREDOデータ量が 使用可能なネットワーク帯域幅を超えた場合など ) バッファがFULLになった場合 ネットワーク送信の完了やタイムアウトの発生によって十分なバッファ領域が確保されるまで LGWRプロセスは停止します この一時的な停止は 本番データベースのスループットに影響を与える場合があります Oracle Database 10g Release 2 では 新しいLGWR ASYNCの動作によって 本番データベースを停止させる可能性を排除します LOG_ARCHIVE_DEST_n 初期化パラメータでLGWR 属性とASYNC 属性が指定されている場合 ログ ライター プロセスは ASYNCバッファに書き込むことなく ローカルのオンラインREDOログ ファイルに書込みを行います LGWRがオンライン ログへの書込みを完了すると LSNnプロセスはオンラインREDOログを読み取り スタンバイ データベースに REDOを転送します この方法では LGWRプロセスの書込みはLNSnのネットワーク書込みとは完全に切り離されています LGWRを使用した非同期 REDO 転送は もはや ASYNCバッファ サイズによって制約されることはありません オンラインREDOログ ファイルがいっぱいになると ログの切り替えが発生し 従来どおり アーカイバ プロセスがローカルでログ ファイルをアーカイブします データ保護の拡張 :Oracle Database 10g Release 1 では 上述のようにバッファが FULLになる場合を除いて 潜在的なデータ損失はASYNCバッファ サイズに制約されていました バッファがFULLになると LNSは現在のREDOストリームのスタンバイ データベースへの転送を中止し ARCHプロセスが実行されます この場合 潜在的なデータ損失の危険性は 現在のオンライン ログのサイズ またはData Guardがスタンバイ データベースと再同期してLNSが転送を再開するまでに 遅延していたログ ファイルの数によって決定されます Oracle Database 10g Release 2 で使用されている新しいASYNCモデルでは 潜在的なデータ損失は LNSnプロセスが現在のLGWRプロセスからどれだけ遅れているかによって測定されます LNSnプロセスが完了する前に LGWRが新しいオンライン ログ ファイルに切り替わると LNSnは現在のログ ファイルを引き続きリモートにアーカイブします LNSnプロセスが最初のログ ファイルを処理している間に LGWRがさらに新しいオンラインREDOログ ファイルに切り替わると LNSnプロセスがアーカイブを開始していないログ ファイルは ARCHプロセスに Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 22

23 よってリモートにアーカイブされます LNSn は 最初のログ ファイルのアーカ イブを完了すると LGWR の現在のログ ファイルのアーカイブを開始します ARCH の拡張 Oracle Database 10g Release 2 では 複数のARCnプロセスを使用して 1 つのアーカイブREDOログにネットワーク経由でREDOを送信する機能が導入されました この機能によって 1 つのアーカイブ ログをリモートの宛先に転送するために必要な時間が短縮されます 以前のリリースのOracle Databaseでは 特定のログ ファイルから同時にREDOをアーカイブできるのは 1 つのARCnプロセスのみでした 宛先へのアーカイブをパラレルで実行するために使用するネットワーク接続の最大数は LOG_ARCHIVE_DEST_n 初期化パラメータのMAX_CONNECTIONS 属性を使用して制御されます LOG_ARCHIVE_MAX_PROCESSES 初期化パラメータは 最高で 30 まで設定できます ( 以前の最大値は 10 でした ) REDO 転送サービス LGWR ARCn LNSn のバックグラウンド プロセス 関連する初期化パラメータにおけるそれぞれの詳細は Oracle Data Guard 概要および管理 [3] を参照してください ネットワーク送信サイズの拡張 Oracle Database 10g Release 2 より以前のリリースでは ログ転送サービスは REDO 情報を 1MB に分割してネットワークに送信していました Oracle Database 10g Release 2 では ネットワーク送信サイズは 1MB から 10MB に増加されました このサイズが大きいと 所定量の REDO 転送ごとに RFS のネットワークの確認を待つ時間が全体で短縮されるため ネットワークのアイドル時間が最小限に抑えられます Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 23

24 付録 B REDO 転送のパフォーマンス テスト オラクルでは LGWR ASYNC REDO 転送サービスと最大パフォーマンス モードを使用した 代表的な Data Guard 構成についていくつかの MAA パフォーマンス テストを実施しました このテストでは REDO 転送とネットワーク チューニングのベスト プラクティスを適用することで どの程度 本番データベースのオーバーヘッドを抑え 潜在的なデータ損失を軽減できるかを測定しました 次のパフォーマンス プロファイルについて考慮してください 構成 1:1MB/ 秒をわずかに下回る平均速度でREDOデータを生成するアプリケーション この速度では 500MBのオンライン ログが 8 分ごとに切り替えられます これは 実際に使用されている大部分のアプリケーションを代表するデータ量です スタンバイ データベースは RTTが 25 ミリ秒である広域ネットワーク (WAN) 内に配置されています 影響 : フェイルオーバーが突然発生した場合 本番データベース パフォーマンスへの影響は 5% 未満 潜在的なデータ損失は約 5 秒間分 構成 2:2MB/ 秒の平均速度でREDOデータを生成するアプリケーション この速度では 500MBのオンライン ログ ファイルが 4 分ごとに切り替えられます スタンバイ データベースは RTTが 25 ミリ秒であるWAN 内に配置されています 影響 : フェイルオーバーが突然発生した場合 本番データベース パフォーマンスへの影響は 5% 未満 潜在的なデータ損失は約 7 秒間分 構成 3:20MB/ 秒の非常に高い平均速度でREDOデータを生成するアプリケーション この速度では 500MBのオンライン ログ ファイルが 25 秒ごとに切り替えられます スタンバイ データベースは RTTが 6 ミリ秒であるWAN 内に配置されています 影響 : フェイルオーバーが突然発生した場合 本番データベースへの影響は 10% 未満 潜在的なデータ損失は 40 秒間分 ネットワーク送信サイズ - ネットワーク利用率の向上図 1 では 1GB のアーカイブ REDO ログ ファイルをさまざまなネットワーク待機時間で送信した場合に ネットワーク送信サイズを 1MB から 10MB に増やすことで 経過時間が短縮されることを示しています Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 24

25 ネットワーク送信サイズ 10gR2 vs. 以前のバージョン 1GB のログ ファイルの送信にかかる時間 ( 秒 ) 10gR2 以前のバージョン 10gR2 以前のバージョン ネットワークの待機時間 図 1: ネットワーク送信サイズがネットワークのアイドル時間に与える効果 ARCH 転送 - リモート アーカイブの迅速化 図 2 では MAX_CONNECTIONS 属性の値を 5 まで増やすことで 1GB のログ ファイルの送信にかかる時間が 55% 短縮されることが示されています パラレル アーカイブ 1GB のログ ファイルの送信にかかる時間 ( 秒 ) 時間 MAX_CONNECTIONS の値 図 2: 複数の ARCn ネットワーク接続によるパラレル アーカイブ LGWR ASYNC - 本番データベースのオーバーヘッドの軽減 Oracle Database 10g Release 2 では REDO 速度が上がり ネットワークの待機時間が増加しても 本番データベースへ与える影響は大きくならず 比較的一定のまま維持されます たとえば REDO 速度が 2MB/ 秒以内である場合 RTT が 0 ミリ秒から 100 ミリ秒までのさまざまな待機時間のネットワークにおいて 本番データベースへの影響 ( ベースラインに対する REDO バイト数 / 秒の変化で測定 ) は Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 25

26 5% 未満に抑えられます ワークロードが大幅に増加した場合も 同じ関係が当てはまります 図 3 では 本番データベースの REDO 速度が約 20MB/ 秒に上がった場合 Oracle Database 10g Release 1 と Release 2 で使用される ASYNC モデル間の差異が著しく大きくなることが示されています 注 : テストでは 1GBのネットワークを使用して さまざまな待機時間のシミュレーションが行われました プライマリ データベースへの影響 10gR2 vs. 10gR1 20MB/ 秒の REDO 影響の割合 ネットワークの待機時間 図 3:20MB/ 秒の REDO 速度における本番データベースへのパフォーマンスの影響 LGWR ASYNC - データ保護の強化新しい LGWR ASYNC モデルを使用した場合の Oracle Data Guard 10g Release 2 の拡張による潜在的なデータ損失において 危険性への影響を測定するため MAA のテストを実施しました 最初のテスト シナリオでは 正しくチューニングされたギガビット ネットワーク上で ワークロードを 2MB/ 秒に維持したまま 1GB のオンライン REDO ログ ファイルを使用して さまざまなネットワークの待機時間のシミュレーションが行われました 図 4 に示されているとおり ネットワークの待機時間が最大で 50 ミリ秒までの場合 REDO 転送は 潜在的なデータ損失の危険性を最小限に抑えたままで 本番データベースの REDO 生成速度を維持できることが確認されました Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 26

27 2MB/ 秒の REDO 速度における潜在的なデータ損失の危険性 秒 ネットワークの待機時間 図 4:2MB/ 秒の REDO 速度における潜在的なデータ損失の危険性 図 5 では 2 番目のテストの結果から 20MB/ 秒で REDO データを生成するという非常に高いワークロードにおいて さまざまな待機時間のデータ保護による影響が示されています ネットワーク チューニングは高いワークロード用に最適化されており 最初のテストと同じギガビット ネットワークおよび 1GB のオンライン REDO ログ ファイルの構成が使用されました 図 5 に示されているとおり 20MB/ 秒という非常に高い REDO 速度でも ネットワークの待機時間が増加した場合の潜在的なデータ損失の危険性は比較的低い値に留まっています 20MB/ 秒の REDO 速度における潜在的なデータ損失の危険性 秒 ネットワークの待機時間 図 5:20MB/ 秒の REDO 速度における潜在的なデータ損失の危険性 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 27

28 LGWR SYNC - ネットワークの待機時間による影響図 6 に示されているとおり 同期 REDO 転送の性質によって ネットワークの速度と待機時間 およびスタンバイ サーバーの I/O 帯域幅は 本番データベースのスループットに影響を与えます プライマリ データベースへの影響 LGWR SYNC 4MB/ 秒 影響の割合 ネットワークの待機時間 図 6:LGWR SYNC の本番データベースへの影響 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 28

29 付録 C - COMMIT NOWAIT と COMMIT WAIT の比較 トランザクションによってデータベースが更新される場合 この更新に対応する REDO エントリが生成されます Oracle Database は トランザクションが完了するまで この REDO をメモリ上のバッファに格納しておきます トランザクションがコミットされたら ログ ライター (LGWR) プロセスは このコミットの REDO をトランザクションでのすべての変更を累積した REDO とともに ディスクに書き込みます Oracle Database は デフォルトで コールがクライアントに戻る前に REDO をディスクに書き込みます アプリケーションは REDO が永続データとしてディスクに書き込まれるまで待機する必要があるため この動作でコミットに待機時間が発生します データベースは多くのアプリケーションをサポートしており データ損失に対する要件はそれぞれ異なるものと考えられます この場合 非常に高いトランザクション スループットを必要とする一方で 潜在的なデータ損失の危険性が容認できるアプリケーションでは COMMIT_NOWAIT を使用します COMMIT NOWAIT パラメータを使用すると REDO がディスクに書き出されるのを待つことなく コミットがアプリケーションに返されます したがって アプリケーションやトランザクションで COMMIT NOWAIT を利用すると デフォルトの COMMIT WAIT を利用した場合と比較して 応答時間とデータベースのスループットが飛躍的に向上します コミットの永続性を得られなくてもコミットの待機時間を短縮したい場合 デフォルトの COMMIT オプションを変更して Oracle Database がオンライン REDO ログにデータを書き込むのを待たないように アプリケーションを設定できます このアプリケーション上でデフォルトの COMMIT オプションを変更しても 同じデータベースを利用している他のアプリケーションに対するデータ損失ゼロの保護に変わりはありません Oracle Database では アプリケーションの要件に応じてコミット REDO の処理を変更できます コミットによる動作を変更するには 次を利用します システム レベルまたはセッション レベルの COMMIT_WRITE 初期化パラメータ COMMIT 文 COMMIT 文のオプションを使用すると 初期化パラメータによる現在の設定を変更します 表 2-1 では 上記のいずれかの方法で設定できる REDO の永続性オプションについて説明します 表 2-1 コミット REDO を管理する初期化パラメータと COMMIT オプション オプション指定する内容... WAIT NOWAIT IMMEDIATE BATCH コミットに対応する REDO がオンライン REDO ログに永続データとして書き込まれるまで コミットは正しく返されません ( デフォルト ) REDO がオンライン REDO ログに書き込まれるのを待つことなく コミットはアプリケーションに返されます ログ ライター プロセスは コミットの REDO をただちに書き込みます ( デフォルト ) つまり このオプションではディスク I/O が強制されます Oracle Database は REDO をバッファに格納します ログ ライター プロセスは 適切なタイミングで REDO をディスクに書き込むことができます Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 29

30 次の例では 初期化パラメータ ファイルで コミット動作を BATCH および NOWAIT に設定する方法を示します COMMIT_WRITE = BATCH, NOWAIT 次の例のように ALTER SYSTEM を実行するとシステム レベルでコミット動作を変更できます ALTER SYSTEM SET COMMIT_WRITE = BATCH, NOWAIT 初期化パラメータを設定した後 オプションを指定しない COMMIT 文は初期化パラメータで指定されたオプションに従います または 次の例のように COMMIT 文でオプションを直接指定すると 初期化パラメータによる現在の設定を変更できます COMMIT WRITE BATCH NOWAIT いずれの場合も ログ ライター プロセスは コミットの REDO をただちにオンライン REDO ログに書き込む必要はなく REDO がディスクに書き込まれたことを確認するまで待つこともないように アプリケーションで指定されています 以下に COMMIT NOWAIT と COMMIT WAIT の比較のサマリーを示します Data Guard を使用しない場合 BATCH-NOWAIT コミットをデフォルトの IMMEDIATE-WAIT コミットと比較すると ユーザー コールの応答時間は 43%( 約 4 ミリ秒から 2 ミリ秒へ ) 短縮され トランザクションの応答時間は 31%( 約 12 ミリ秒から 9 ミリ秒へ ) 短縮されました Data Guard を使用した場合の BATCH-NOWAIT コミットをデフォルトの IMMEDIATE-WAIT コミットと比較した結果は 以下のとおりです 10~35% の REDO 速度の向上 10~33% のトランザクション速度の向上 90% のトランザクション応答時間の短縮 BATCH-NOWAIT コミットの結果は Data Guard を使用しない場合と Data Guard を使用した場合で基本的に一致しました 重要な指標は log file sync 待機がほぼゼロになったことです たとえば コーリング サークル アプリケーションを 5 分間実行した場合 COMMIT WAIT では 56,391 個の log file sync 待機イベントが確認され 合計待機時間は 241 秒でしたが COMMIT NOWAIT で確認された log file sync 待機イベントは 1 つだけであり 待機時間は 1 秒未満でした ユーザーへの影響 :NOWAIT オプションを使用すると 一般に アプリケーションのユーザー コールおよびトランザクションの応答時間が短縮されます 同期転送を使用した Data Guard 環境では NOWAIT オプションによって パフォーマンスとスループットが飛躍的に向上します インスタンスまたはデータベースの障害時に非永続コミットを容認できる場合は この選択肢が最適である場合があります このようなタイプのアプリケーションの例には ショッピング カート アプリケーションがありますが 購入トランザクション 動向サンプリング / 追跡システム Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 30

31 データ ウェアハウス アプリケーションやデータ マート アプリケーションには適していません アプリケーションの例 : Calling Circleアプリケーションの説明 Swingbench 負荷生成ツールを使用して Calling Circle のワークロードが生成されました Calling Circle のワークロードは セルフ サービスの OLTP アプリケーションに相当します このアプリケーションは 電話料金の割引を受けるために 電話会社の顧客が もっともよく電話をかける相手の番号である Calling Circle の登録 更新 照会を行うアプリケーションです このワークロードの I/O サイズは少量です ( 一般的に表領域のブロック サイズ この例では 8K) このアプリケーションは JDBC thin を使用してデータベースに接続し JDBC 接続プール ファスト スタート フェイルオーバー および高速アプリケーション通知 (FAN) を使用します クライアント CC スタンバイ構成コミットの種類スタンバイなし - IMMEDIATE WAIT スタンバイなし - BATCH NOWAIT LGWR SYNC - IMMEDIATE WAIT LGWR SYNC - BATCH NOWAIT KB REDO/ 秒トランザクション / 秒トランザクション応答時間 ( ミリ秒 ) データ Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 31

32 受注アプリケーションの説明受注 - Swingbench 負荷生成ツールを使用して 受注ワークロードが生成されました 受注ワークロードは 受注アプリケーションで使用される代表的な 5 種類のトランザクションで構成されています 顧客の作成 製品の表示 発注 受注処理 および注文の確認です このワークロードの I/O サイズは少量です ( 一般的に表領域のブロック サイズであり この例では 4K) このアプリケーションは JDBC thin を使用してデータベースに接続し JDBC 接続プール ファスト スタート フェイルオーバー および高速アプリケーション通知 (FAN) を使用します 注 : コール応答時間の算定には v$servicemetric.dbtimepercall が使用され トランザクション応答時間の算定には v$sysmetric.metric_name='response Time Per Txn' が利用されました クライアント OE スタンバイ構成コミットの種類スタンバイなし - IMMEDIATE WAIT スタンバイなし - BATCH NOWAIT LGWR SYNC - IMMEDIATE WAIT LGWR SYNC - BATCH NOWAIT KB REDO/ 秒トランザクション / 秒トランザクション応答時間 ( ミリ秒 ) データ Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 32

33 参考資料 1. Oracle Data Guard ataguardoverview.html 2. Oracle Maximum Availability Architecture 3. Redo Apply (physical standby) MAA Best Practices ( 英語 ) 4. SQL Apply (logical standby) MAA Best Practices ( 英語 ) 5. Oracle Data Guard 概要および管理 ( 製品マニュアル ) m 6. Oracle Data Guard 10g Release 2: スイッチオーバーとフェイルオーバーのベスト プラクティス ( 英語 ) 7. Best Practices for Creating a Low-Cost Storage Grid for Oracle Databases ( 英語 ) 8. Oracle Database Net Servicesリファレンス ( 製品マニュアル ) 9. iperf Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 2 33

34 Data Guard REDO 転送とネットワークのベスト プラクティス Oracle Database 10g Release 年 1 月著者 :Michael T. Smith 共著者 :Joseph Meeks Lawrence To Douglas Utzig Robert McGuirk Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファクシミリ : oracle.com Copyright 2007, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle JD Edwards および PeopleSoft は オラクル社およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です