フラッシュバックとhpdataprotectorを使用した …h50146. ·...
TRANSCRIPT
フラッシュバックとHP Data Protectorを使用した、ProLiantとEVAの組み合わせにおけるOracle 11gのバックアップとリカバリ
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
ソリューションの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Oracleサーバの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Oracleフラッシュバックの概要 . . . . . . . . . . . . . . . . . . . . . . 9テストの方針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10テスト手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10データベース特性化 . . . . . . . . . . . . . . . . . . . . . . . . . 11
オープンソース ツール . . . . . . . . . . . . . . . . . . . . . . 11ディスク パフォーマンス . . . . . . . . . . . . . . . . . . . . 11テープ パフォーマンス . . . . . . . . . . . . . . . . . . . . . 13ユーザー ワークロード ベースライン . . . . . . . . . . . . . . . 14サーバ特性化の結論 . . . . . . . . . . . . . . . . . . . . . 15
フラッシュバック テスト . . . . . . . . . . . . . . . . . . . . . . . . . 16表を20%増加させた後のフラッシュバック表 . . . . . . . . . . . . . . 16フラッシュバック表の結論 . . . . . . . . . . . . . . . . . . . . . 18
削除したデータのリカバリ . . . . . . . . . . . . . . . . . . . . . . . 19削除後のフラッシュバック表 . . . . . . . . . . . . . . . . . . . . 19フラッシュバック データベースを使用した表領域のリカバリ . . . . . . . 19
データベース全体のリカバリ . . . . . . . . . . . . . . . . . . . . . . 20データベースに20%の変更を加えた後のフラッシュバック データベース . . 20
フラッシュバック リカバリ領域を使用したD2Dバックアップ . . . . . . . . . . 21RMANのベースライン バックアップ . . . . . . . . . . . . . . . . . 22OLTPワークロードを使用した場合のRMANバックアップ . . . . . . . . . 22
パフォーマンスの留意事項 . . . . . . . . . . . . . . . . . . . 22RMAN D2Dのリストア . . . . . . . . . . . . . . . . . . . . . . . 22
D2Dリストア パフォーマンス . . . . . . . . . . . . . . . . . . 23フラッシュバック リカバリ領域の管理 . . . . . . . . . . . . . . . . . . 23オンライン バックアップの二次的な場所への移動 . . . . . . . . . . . . . 24フラッシュバック ログのメンテナンス . . . . . . . . . . . . . . . . . . . 25テストの結論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
フラッシュバック リカバリのベスト プラクティス . . . . . . . . . . . . . . . . . 27サーバ/ストレージ管理者 . . . . . . . . . . . . . . . . . . . . . . . 27ITマネージャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29観察結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Oracleフラッシュバック . . . . . . . . . . . . . . . . . . . . . . . 30RMAN/Data Protector . . . . . . . . . . . . . . . . . . . . . . . 30
結論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32お客様のフィードバックは、有効に活用させていただきます . . . . . . . . . 33
付録A 構成の一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34付録B 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Linuxカーネルの構成 . . . . . . . . . . . . . . . . . . . . . . . . . 36Linuxボンディング ドライバ . . . . . . . . . . . . . . . . . . . . . . . 36HP EVA、Oracle ASM、およびOracleデータベースの関係 . . . . . . . . . . 36
ASMディスク グループの説明 . . . . . . . . . . . . . . . . . . . 37Oracleのリストア ポイント . . . . . . . . . . . . . . . . . . . . . . . 37
詳細情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38HPテクニカル リファレンス . . . . . . . . . . . . . . . . . . . . . . . 38HPソリューションおよびトレーニング . . . . . . . . . . . . . . . . . . . 38HP製品サイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Quest Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
概要
はじめに
今日のコア アプリケーションに対する可用性の要件は、予定外のダウンタイムが1か月当たり3時間
未満というものから、1年当たり5分以内というごく短い時間までさまざまです。 したがって、Oracle
データベースのバックアップとリカバリを実行する手法は、データ保護および可用性に関するIT部門
の方針の重要な部分を形成します。 データベース内に格納される情報のサイズは継続的に増加
しているので（現在の合計年間成長率は約30%）、これらの目標を維持するために、パフォーマン
スがより優れたバックアップおよびリカバリの手法が必須です。
Oracle 11gの主要な新機能として、フラッシュバック データ アーカイブ機能の強化を挙げることができ
ます。 これらの新機能からなるパッケージ化されたセットはTotal Recallと呼ばれています。これらの機
能を使用すると、すでにアーカイブされた表データをシームレスに表示できます。
このプロジェクトでは、Oracle 11gの高度な機能をHPのサーバ、アレイ、テープ ライブラリ、および仮想
テープ デバイスと組み合わせて特定の目標時点まで戻す高速リカバリのパフォーマンスに注目しま
す。 HPのこのテストでは、RMANバックアップ用のフラッシュバック リカバリ領域（FRA）を、バックアップ
とリカバリに関する全体的な方針に統合することに注目します。
パフォーマンスを向上させるために、バックアップ/リカバリに使用するブロック サイズを正しくサイズ設
定することが重要です。 バックアップ/リカバリに使用するブロック サイズを正しくサイズ設定すること
により、VLS（Virtual Library System）の場合は最大7%、EML（Enterprise Modular Library）の場合は最
大55%、パフォーマンスを向上させることができます。 EMLの場合は大幅な向上が達成されます。ま
た、4チャネルのEMLに比較すると、8チャネルのVLSは最大9%、12チャネルのVLSは最大29%高速にな
ります。 これらの向上に加えて、フラッシュバック リストアについて考慮してみましょう。これは、テープ
からのリストアに比較して、最大62%の時間短縮をもたらします。
このプロジェクトでは、次の手法に注目します。
• RedHat Linuxを実行しているProLiant、2.5TBの11g RAC DBを構成および構築済みのEVAからなる
Oracle 11g RAC環境を活用する。
• ディスクのバックアップ先として11gのRMANバックアップ用のフラッシュバック リカバリ領域を使
用し、アプリケーションにとって整合性のある時点まで11g DBをリカバリするためのベスト プラ
クティスを策定する。
• この高度な手法に関する計画/運用上の留意事項と利点を、従来型の標準的なテープベースの
バックアップ/リカバリと比較する。
期待される結果は以下のとおりです。
• Oracle 11gフラッシュバック リカバリ領域を使用したバックアップ/リカバリ インフラストラクチャの構
成、導入、運用を効率よく行う方法を知る。
• フラッシュバック リカバリ領域からバックアップを実行するための詳細な一連のベスト プラクティ
スを確立し、どのような状況で古いバックアップをディスクからどのように移行すればよいの
かを確定する。
• アプリケーションにとって整合性のあるリカバリを行うための詳細な一連のベスト プラクティ
スを確立する。
3
ソリューションの構成
このプロジェクトでは、Oracle 11gの高度なバックアップおよびリカバリの機能に関する情報を提供し、
Oracleのフラッシュバック リカバリ テクノロジの使用方法と統合方法について説明します。図1に、複
数のコンポーネントからなるソリューションの構成を示します。
• EVAのストレージ
• 4GbpsのSANインフラストラクチャを利用するProLiantサーバ
• 1Gbpsのネットワーク コンポーネント
図1 ソリューションの構成図
データベースは、ノードが2台あるOracle 11g RACシステムとして構築されています。このシステムは、
RedHat Enterprise Server 5が動作する複数のProLiant DL585 R01サーバで構成されています。各RAC
ノードには、32GBのRAM、オペレーティング システムをインストールするための300GBの内蔵ディスク
領域、4GbpsでSANに接続することを目的とした、Qlogicベースの4GbpsのHBAであるHP FC2243が実
装されています。 ネットワークに接続するために、複数の1Gbps NICを使用します。 この構成では、プ
ライベート相互接続インターフェース専用に、Linuxネットワーク ボンディング ドライバも使用します。
Linuxボンディング ドライバの設定、およびLinux環境でボンディングNICを使用する条件に関するベスト
プラクティスの詳細については、付録B 例を参照してください。
4
図2に、プライベート相互接続用のLinuxボンディング ドライバを使用したネットワーク負荷分散機能
の状況を示します。
図2 RAC相互接続ネットワークの負荷分散
注記：
RedHat Enterprise Linux用のボンディング ドライバは、デフォルトでサーバごとに1つのボンディング インターフェース構成のみをサポートします。 他のLinuxベンダは、複数の構成をサポートすることもあります。
この環境でテストを実施するために、HPでは図3に示すRACデータベースを構成しました。 これらの環
境は、顧客の聞き取り調査に基づいたもので、典型的なOracle RACデータベース環境を示していま
す。 正確なバージョンと製品番号を付録A 構成の一覧に示します。
5
図3 Oracle RACの構成図
RACシステム用のASM（Automatic Storage Management）ディスク グループ構成は、図2でも示します。
この構成では2つのディスク グループを使用し、オンライン データファイルと制御ファイルをRMAN
オンライン バックアップ、フラッシュバック リカバリ ログ、およびアーカイブREDOログから分離しま
す。 各ディスク グループには固有のパフォーマンス特性があり、フラッシュバック リカバリ対象の
データベースを構成するときに考慮に入れる必要があります。
ベスト プラクティス
FRAを含むディスク グループを対象にして、IOPSとスループットに注目してパフォーマンスを測定します。 ディスクツーディスク（D2D）のバックアップ先として使用する場合、このディスク グループのパフォーマンスは非常に重要です。
Oracleデータベース、ASM、およびEVAの関係についての詳細は、付録B 例、および次のHPのWebサイ
トにあるホワイト ペーパー『Best Practices for Oracle 10g ASM and the EVA8000』を参照してください。
http://h71028.www7.hp.com/enterprise/cache/429462-0-0-0-121.html（英語）
この構成で使用したProLiantサーバの種類を表1に、また使用したストレージ コンポーネントの種
類を表2に示します。
6
表1 コンポーネント リスト–サーバ
サーバの種類 サーバの用途
ProLiant DL380 G4 Oracle Grid Control 10g R2
ProLiant DL585 R01 ノード1：Linux Oracle RAC 11g（OLTP）
ノード2：Linux Oracle RAC 11g（OLTP）
ProLiant DL580 G2 Benchmark Factoryサーバ
Data Protector Cell Manager
ProLiant DL360 G4 OpenView Operations Manager for Windows
ProLiant DL360 G3 Command View EVA
ProLiant DL380 G3 System Insight Manager
Oracleサーバの構成
この環境を構成するには、以下の手順を行います。
各種ソフトウェアのインストール
1. 最新のPSPファームウェアCDから起動します。
2. RedHat Enterprise Linux 5 Serverをインストールします。
3. Linuxカーネルのパラメータを変更します（付録B 例を参照）。
4. HP OpenView Performance Agentをインストールおよび構成します。
5. HP ProLiant Support Packをインストールします。
6. 最新のHP Fibreutilsをインストールします。
7. HP/Qlogic SANSurferをインストールします。
8. Oracle Clusterwareをインストールします。
9. Oracle Agentをインストールします。
10. Oracle Enterprise Serverをインストールします。
注記：
簡潔さを考慮して、Oracle Agentをインストールする前にOracle Grid Controlをインストールして環境に合わせて構成する必要があります。
このインストール方法によって、各サーバが同じ構成になります。 RDP（Rapid Deployment Pack）を使
用すると、多数のノードをごく短時間でインストールできます。 詳細情報 に掲載されているRDPに関
する技術資料を参照してください。
ベスト プラクティス
RDPを使用して初期状態のオペレーティング システムを複製した後にOracleソフトウェアをインストールするのが最善です。 ただし、RDPイメージを作成する前に、オペレーティング システムのすべてのコンポーネントを統合する必要があります。
7
各構成コンポーネントには、デバイス タイプごとに最大のパフォーマンス測定値があります。表2に、
パフォーマンスの上限を示します。
表2 コンポーネント リスト–ストレージ
ストレージ コンポーネント
コンポーネントの種類 速度 個数
HBA FC2243デュアルチャネルHBA ポートあたり4Gbps 4
スイッチ Cisco MDS9124 SANスイッチ ポートあたり4Gbps 2
EVA EVA6100ストレージ システム
EVA8100ストレージ システム
ポートあたり4Gbps 1
1
テープ デバイス EML 103eテープ ライブラリ
VLS6510 Virtual Library System
350MB/秒（最高）
750MB/秒（最高）
1
1
8
テスト
Oracleフラッシュバックの概要
Oracle 10gとともにリリースされたOracleフラッシュバック テクノロジ スタックを使用すると、データベー
ス管理者はリカバリを詳細に制御できます。 リカバリが必要になる最も一般的なミスは、ユーザーの
エラーまたはデータの論理的な破損に関わるものであり、この場合はOracleフラッシュバック機能
を活用するのが最善です。
フラッシュバック データベースの構成
1. すべてのRACインスタンスをシャットダウンします。
2. 1つのRACインスタンスをマウント モードで起動します。
3. sysdbaとして接続します。 次のコマンドを入力します。
Alter database flashback enable.
4. RACインスタンスをシャットダウンします。
5. RACを起動します。
FRAのデフォルト設定に対するオプションの変更
1. OEMまたはGrid Controlにログインします。
2. [System]タブを選択し、次に[Recovery]を選択します。
3. 必要に応じて、FRAサイズと保存期間を変更します。
フラッシュバック リカバリ領域の詳細については、詳細情報 の項にあるOracleを参照してください。
フラッシュバック リカバリ機能は、従来のREDOログ、UNDOログ、アーカイブ ログに加えて、フラッシュ
バック ログと呼ばれる新しい一連のログを採用しました。この結果、変更を追跡し、データベースに対
してOracleのフラッシュバック問い合わせを実行できるようになりました。 フラッシュバックが有効になっ
ている場合は、新しいログを書き込むときにデータベースに追加のオーバーヘッドが発生します。 ただ
し、アーカイブ ログ モードでは、認識可能なオーバーヘッドが発生することはなく、データベースの全体
的なパフォーマンスに影響が及ぶこともありません。 新しい一連のログを使用することにより、表の行
またはコミット済みのトランザクション レベルにまで至る、柔軟なPoint-in-Timeリカバリを実行できます。
Oracle 11gでは、Oracle 10gで導入された柔軟なオンラインPoint-in-Timeリカバリ機能を、次の機能
によって改善しています。
• フラッシュバック トランザクション機能
• 新しい情報ライフサイクル管理機能
• フラッシュバック データ アーカイブ
詳細については、次のURLにある『Oracle Database Backup and Recovery User’s Guide 11g Release 1
(11.1)』を参照してください。
http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/title.htm（英語）
9
テストの方針
一連のテストにより、Oracleフラッシュバック リカバリ テクノロジを実装および使用するためのベスト プ
ラクティスを調べます。 データベースに約2.5TBのデータを入力します。 FRAを使用したディスクツー
ディスク（D2D）のバックアップを実行し、パフォーマンス測定値を収集します。
次に、データベースに対して一連の変更を適用します。多くは挿入であり、データベースのサイズ
を約20%大きくします。 変更を加えるたびに、データベースのサイズを記録します。 その後、FRAを
使用して一連のフラッシュバック表操作を実行します。 これらの操作の所要時間とEVAパフォー
マンスも収集します。
さらにテストを繰り返し、フラッシュバック データベース操作を実行します。 テストの所要時間、サーバと
ストレージのパフォーマンス測定値を収集し、後で比較します。 ワークロードをさらに2回にわたって適
用し、データベースに変更を加えます。 一連の変更を加えるたびに、D2Dバックアップを実施し、一部
のアーカイブ ログを更新します。 FRAを更新する目的で、追加のフラッシュバック変更も生成します。
フラッシュバック データベース オプションを使用してデータベースのリカバリを実行します。 トレース ロ
グを観察してRMANを使用した取得が実行されていることを確認し、要求される保存期間を過ぎていな
いすべてのアーカイブ ログを再生します。 前述の一連のテストをもう一度実行します。 RMANとData
Protectorを使用し、セカンダリ ディスクのバックアップをテープ バックアップ デバイスに移動しま
す。 ここでも、システム、データベース、およびすべてのEVAストレージに関するパフォーマンスを
監視します。 Oracle 11gのバックアップ機能全体をテストします。 前回のフラッシュバック リストア
ポイントまでデータベースのリストアとリカバリを実行し、データベースのリストアとリカバリを正しく
実行するためにどのコンポーネントが必要なのか確認します。
テスト手順
このプロジェクトで実施するテストは、3つのフェーズに区分できます。 フェーズ1には、ワークロードの
タイプを把握するためのシステム統計を収集することと、適切な場合はそれ以降のテストの比較対象
として使用するベースラインを提供することが含まれます。 フェーズ2では、Oracleフラッシュバック テク
ノロジの構成と実装、およびOracleのフラッシュバック機能のうち一般的に使用される各機能のパ
フォーマンスについて検討します。 フェーズ3では、フラッシュバック リカバリの使用方法と、既存の
バックアップ プロセスおよびインフラストラクチャに統合するための詳細を示します。
テストのフェーズ
1. データベース特性化テスト： RACノードの動作について理解します。
a. ディスク パフォーマンス テスト
b. テープ パフォーマンス テスト
i. LTO3
ii. VLS
c. ユーザー ワークロード ベースライン テスト
2. フラッシュバック テクノロジ テスト： この機能の動作について理解します。
a. フラッシュバック表 –データ変更後
b. フラッシュバック表 –切り捨て後
c. フラッシュバック データベース –オブジェクト削除後
10
d. フラッシュバック データベース –データ変更後
3. フラッシュバック管理： フラッシュバック リカバリをバックアップ環境に統合できるようにします。
a. フラッシュバック ログのバックアップとリカバリ
b. FRAから他のメディアへのバックアップの移動
c. FRAを使用したD2Dバックアップ/リカバリ
データベース特性化
データベース機能、テープの構成、VLS（Virtual Library System）機能を正しくテストするために、メイン
のテストの実行前に一連のテストを実施してテスト環境の構成を確認し、メインのテスト フェーズ
実行中に発生する可能性のある潜在的な問題を特定します。
オペレーティング システムおよび関連するコンポーネント ソフトウェア（PSP（ProLiant Support Pack）
によって提供されるドライバなど）をインストールした後で最初に実行するテストの1つとして、ディ
スク パフォーマンス テストを挙げることができます。 このテストを実行するために、複数のオープ
ンソース ツールを使用して、この環境で使用するハードウェアとソフトウェアのスタックに関する
正確なベースラインを把握します。
オープンソース ツール
• ディスク複製ユーティリティ（DD）： RAWパフォーマンスのテストと複製を行います。
• スレッド化I/Oベンチマーク ユーティリティ（TIOBench）： RAWディスクとファイルシステムを対象
とします。
• IOZone： 高度に設定可能なベンチマーク ユーティリティであり、広い範囲のファイルシステム パ
フォーマンス テストを実行します。
ディスク パフォーマンス
EVA8100のFCディスク グループから提供されたプライマリの600GB RAID 1 LUNは、シングル スレッ
ドの場合でそれぞれ約212MB/秒の書き込みスループット、95パーセンタイル値のスループット測
定値で306MB/秒を達成します。EVA6100のFATA（Fibre Attached Technology Adapted）ディスク グ
ループから提供された600GB RAID 5 LUNは、シングル スレッドの場合で約141MB/秒の書き込みス
ループット、95パーセンタイル値のスループット測定値で226MB/秒を達成します。図4に、各スレッ
ドのパフォーマンスを表すグラフを示します。
11
図4 ディスク パフォーマンスの特性化
EVAパフォーマンス測定値に加えて、ホストの測定値も監視します。 このテストの実施中に、顕著なホ
スト パフォーマンス特性は観察されませんでした。図5に、最大のリソース使用率の例を示します。
図5 RACノード1のパフォーマンス測定値
注記：
両方のノードでの特性化テストの結果は同一であったため、ノード1だけを示します。
12
テープ パフォーマンス
この環境には、2種類のテープ デバイスがあります。
• VLS 6510、ミッドレンジHP仮想テープ ライブラリ： データ ストレージとしてSATAドライブを構成し
た、4台のMSA30ディスク シェルフを使用します。 このVLSは最大16台のテープ ライブラリと、最
大8種類のテープ ドライブのエミュレーションを行います。 今回のテストでは、LTO-3エミュレー
ションを選択しました。 VLSの主要な利点は、既存のテープ環境に統合できると同時に、ディス
ク ストレージと同等のパフォーマンスを達成できることです。
• 4台のLTO-3ドライブを構成したEML103eエンタープライズ テープ ライブラリ。 各テープ ドライ
ブは約90MB/秒を達成でき、最大構成のEML103eテープ ライブラリは350MB/秒以上のRAWパ
フォーマンスを達成できます。
図6に、各テープ デバイスのパフォーマンスの比較を示します。
図6 テープ パフォーマンスの特性化
これらのテストは、実現可能な最大速度におけるホストのバックアップ実行能力を示します。図7に、各
バックアップ テープに対応するホストのパフォーマンス測定値を示します。
13
図7 RAWバックアップ実行中のRACノード1のホスト パフォーマンス
ユーザー ワークロード ベースライン
ユーザー ワークロード ベースラインは、ワークロードが重い場合のサーバの機能を特性化し、データ
ベースに対してどのようなチューニングが必要とされるのかを示すデータを提供します。 このパフォー
マンス データは、フラッシュバック リカバリ領域の管理で説明するD2Dバックアップ テストを実施すると
きに、比較のために使用します。 OLTPユーザー ワークロードのベースライン トランザクション パ
フォーマンスは、1秒当たりのトランザクション数（TPS）単位で測定します。 このベースラインの平均値
は、66.5TPSです。図8に、ワークロード発生中のホスト パフォーマンスを示します。
14
図8 ユーザー負荷に関するサーバの特性化
サーバ特性化の結論
テスト結果は、データベース サーバには特にリソースの制限がないことを示しています。 RAWディスク
パフォーマンス テストを実施している間、スループットは高く、ホストのCPU、メモリ、スワップの使用率
は最小限です。 テープ パフォーマンス特性化テストでも、ホストの同様の属性が明らかになりました。
CPU、メモリ、スワップの使用率は最小限で、スループットは各デバイスが提供できる最大値に達して
います。 最後に、ワークロード パフォーマンスの結果では、CPU、メモリ、ホスト スワップの使用率は
大きく上昇しましたが、スループットの使用率は低い値にとどまっています。 これらの結果は、今
回のユーザー ワークロードの範囲では、データベース サーバはどのリソースでもボトルネックに
なっていないことを示しています。 この状況でさえ、十分なリソースが利用可能であり、ユーザー パ
フォーマンスに影響を及ぼさずにバックアップを実行できます。
テストを実行している間、システム パフォーマンス特性が維持される一方、パフォーマンスとOLTP
ベースラインは時間の経過とともに向上します。 このようなパフォーマンス向上の理由の1つは、
Oracle 11gが採用した自動メモリ管理機能にあります。 また、パフォーマンスを向上させる目的で一
般的に使用されているASMとEVAのバッファリングも、理由の1つです。 OLTPベースライン テスト
結果の平均値は、66.57TPSです。
一連のテストのうちいずれにおいても、データベースのCPU使用率は50%未満、メモリ使用率は
65%未満、スワップ使用率は0でした。
ベスト プラクティス
Oracle 11gが採用した自動メモリ管理機能を使用すると、SGAのサイズに関わりなく、パフォーマンスを向上させることができます。 詳細については、次のHPのWebサイトにあるホワイト ペーパー『Oracle 11g new features - Automatic memory managementand variable automatic storage management (ASM) extent size』を参照してください。
http://h71028.www7.hp.com/ERC/downloads/4AA1-5662ENW.pdf（英語）
15
以下の項では、フラッシュバック テストによるシナリオ テストと結果について説明します。 D2Dバックアッ
プのシナリオでは、FRAの構成済み領域を使用し、フラッシュバック管理テストを実施しますが、これに
はバックアップとリカバリのシナリオ全体をとおしてフラッシュバック ログを追跡することが含まれます。
フラッシュバック テスト
Oracleフラッシュバック テクノロジのうち、最も一般的に使用される機能を対象とする一連のテスト
は、次のとおりです。
• フラッシュバック表
• フラッシュバック データベース
以下では、テストのパフォーマンス測定値と、該当するユーザーおよび管理者の両方に及ぼす
一般的な影響について説明します。
表を20%増加させた後のフラッシュバック表
このテストではプライマリ データの表に変更を加え、その後、表を元の状態に戻します。その際、定義
されたリストア ポイントまでのフラッシュバック時間を測定します。 変更を元に戻す方法は複数存在し
ます。 コミット済みのトランザクションを除き、通常はUNDO操作を使用しますが、フラッシュバック表操
作は最も簡単に実行できます。 保証付きリストア ポイントが使用されていない場合は、特定のタイム
スタンプまでフラッシュバックを実行できます。図9は、このテストで使用する構文の一例です。
図9 Flashback Tableコマンド
flashback table oltp-table1 to timestamp (systimestamp − interval 10 minute)
図9に示すFlashback Tableコマンドは、指定した表を、現在のタイムスタンプより10分前の状態に戻し
ます。 この種のフラッシュバック操作を完了するための所要時間は、次の要素によって決まります。
• オブジェクトの変更レート
• 生成されたUNDOの量
• 生成されたアーカイブの数
• フラッシュバック リカバリ ログの中に書き込まれたデータの量
図10に、フラッシュバック表操作実行中のホストのパフォーマンスを示します。図11に、フラッシュ
バック表操作実行中のEVAのパフォーマンスを示します。 FRAに関係する公式の計算は、次のURL
にあるOracle Metalink Note 305648.1『What is a Flash Recovery Area and how to configure it』に
掲載されています。
https://metalink.oracle.com/metalink/plsql/ ml2_documents.showDocument?p_data
base_id=NOT&p_id=305648.1（英語）
16
図10 フラッシュバック表がパフォーマンスに及ぼす影響
ユーザー負荷の特性化を実行中のホストのパフォーマンスは、他の特性化テストの実行時のパフォー
マンスを上回っていません。 単一のワークロードのみを適用されたホストには、あらゆるバックアップ
の実行中に使用できる十分なリソースがあります。 詳細については、フラッシュバック リカバリ領域を
使用したD2Dバックアップを参照してください。
図11 フラッシュバック実行中のディスク パフォーマンス
このグラフでは、OLTPワークロードの発生中に、データがEVA8100に対してどのように書き込まれ
たかを示しています。 アーカイブ ログへの書き込みが原因で、EVA6100では100MB/秒より上で多
17
くのスパイクも発生しています。 ただし、アーカイブ ログを書き込む時間は十分短いので、書き込
みの平均はかなり小さくなります。
フラッシュバック表の結論
ホストのCPU使用率は約3%から10%に増加し、この手順を実行するために約2.5時間を要しました。 ホ
スト統計も、フラッシュバック表手順実行時の特徴的なリソース使用率を示します。 他の方式を使用し
てほぼ同等の内容を実行できますが、それらには異なるオーバーヘッドが関係します。 RMANを使用
してデータベース オブジェクトを既知の時点まで戻し、エラーまたは不良データが発生する前の時点ま
でロール フォワードすることにより、表を復旧することが可能です。表3に、RMANを使用して表をリカ
バリするために必要とされる手順を示します。
表3 RMANとテープのリストアを使用した表のリカバリの例
タスク 時間
テープの検索 1時間
データのリストア 2時間以上
特定の時点までの表のリカバリ/データの再挿入 1時間以上
表へのアクセスの再許可 5分
テープの検索と表のリストアに要する時間は、表に対してフラッシュバックを実行する前述の簡単なコ
マンドよりはるかに長くなる可能性があります。 代わりに、表に対してロールバック操作を実行すること
もできますが、これはユーザー セッションの一部として、コミットより前に実行する必要があります。 一
度コミットを実行した後は、元に戻す唯一の方法は、RMANを使用してリストアを実行するか、またはよ
り単純なプロセスとして、特定のオブジェクトをフラッシュバックすることです。
ベスト プラクティス
外部のRMANリカバリ カタログ（RCVCAT）とブロック変更の追跡を使用すると、リカバリ時間を短縮できます。
表4に、フラッシュバックを実行する場合の総所要時間と、リストアと特定の時点までの表のリカバリを
行う場合の総所要時間との比較を示します。
表4 リカバリ時間の比較
タスク 時間 オブジェクトのステータス
フラッシュバック表 2時間31分 オンライン
表のリストア 4時間以上 オフライン
フラッシュバックの利点は、このテストから明らかです。 フラッシュバックに関する唯一の注意点は、フ
ラッシュバック リカバリを使用するときに明らかになりますが、時間の経過に伴ってUNDO_RETENTION
パラメータを変更する必要が生じることです。 続く2つのテストでは、データの削除に関連するフ
ラッシュバック リカバリについて説明します。
ベスト プラクティス
UNDO_RETENTIONパラメータに対して細心の注意を払い、アラート ログの中でUNDOに関するあらゆるメッセージを監視してください。 過度にサイズの小さいUNDO_RETENTIONを指定した場合は、特定の時点までに多数の変更のリカバリを実行する際に、フラッシュバックの有効性が低下する可能性があります。 多くの場合は、単純にUNDOを大きいサイズに再設定し、フラッシュバック操作を繰り返すことにより、この問題に対処できます。
18
削除したデータのリカバリ
誤った表の切り捨て、問い合わせの中で正しくない範囲を指定したデータの削除、意図していない表
の削除などの単純ミスを復元する場合、従来は、管理スタッフ全体に対して多大な負担となり、長時
間にわたってユーザーにも悪影響を及ぼすのが一般的でした。
単純ミスをした場合に備えて、Oracleはフラッシュバック表を導入し、データベース管理者やユーザーが
削除されたデータのリカバリを比較的容易に行えるようにしました。 以下のテストは、フラッシュバック表
の手法により単純ミスからのリカバリを行う方法を示し、フラッシュバック表操作の簡潔さを強調します。
削除後のフラッシュバック表
このテストでは、プライマリ データの表を削除し、定義済みのリストア ポイントまでのフラッシュバック
時間を測定しました。 このテストでは、リカバリにほとんど時間がかかりませんでした。 この操作
では、Oracle内部の表の名前変更操作だけが使用されました。 1つの表全体を削除した場合や、
他のオブジェクトを削除した場合は、ごみ箱が更新され、ユーザーは削除したあらゆるオブジェク
トのステータスをチェックできます。
図12に、表のフラッシュバックに要した時間の例を示します。
図12 削除後のフラッシュバック表の出力
Begin Flashback Tue Jan 15 15:04:38 MST 2008 Flashback complete.Elapsed: 00:00:00.04 Tue Jan 15 15:04:38 MST 2008
このテストでは、リカバリの目的でフラッシュバック ログをほとんど、またはまったく必要とせず、認
識可能なオーバーヘッドをサーバに対して発生させることはありません。 ユーザーに対する影響
も最小限であり、追加コマンドなしでデータを利用できます。 この操作は、必ずしも100%の参照整
合性を保証するものではないので、すべての結果セットが完全に正しいかどうか確認する問い
合わせを実行する必要があります。
ベスト プラクティス
特定の時点までフラッシュバックし、データの整合性や参照整合性を保証するには、代わりにフラッシュバック トランザクション問い合わせを使用することもできます。 または、フラッシュバック データベース操作を実行することもできます。 ただし、これはオフライン操作なので、手軽に使うことはできません。
フラッシュバック データベースを使用した表領域のリカバリ
このテストでは、表領域を削除し、Flashback Databaseコマンドを実行します。 定義済みのリストア ポイ
ントまでデータベースをフラッシュバックさせるためのリカバリ時間を測定します。 テストの結果、こ
の特定のフラッシュバック操作は機能しないことが明らかになりました。 drop tablespaceコマンドを
発行した場合、フラッシュバック リカバリは有効になりません。物理的なディスク オブジェクト、つ
まり表領域を維持しているデータ ファイルが関係するからです。 データ ファイルは削除されます。
フラッシュバック機能についてはOracleのガイドラインがあります。 フラッシュバック データベース
操作を実行すると、表領域とそれに関連するデータベース オブジェクトのように見えるものが復元
されることがあります。 リカバリ手順は存在し、HPはこのシナリオおよび表領域をリカバリする方
法に関するカスタマ アドバイザリを公開済みです。 このカスタマ アドバイザリに関して、次のHPの
WebサイトにあるHP Alertsを参照してください。
19
http://www.hp.com/go/myhpalerts（英語）
ベスト プラクティス
フラッシュバック データベースを使用して表領域をフラッシュバックすることはできません。 代わりに、表領域のメタデータとそれに関連するオブジェクトがリストアされます。 表領域をリカバリするには、オブジェクト全体に対するRMANのリストアを実行する必要があります。
データベース全体のリカバリ
データベースに20%の変更を加えた後のフラッシュバック データベース
このテストでは、データベース内にあるすべての表に対して20%の変更を加え、20人のユーザーを追加
した後、Oracle 11gのデータベースを定義済みのリストア ポイントまで戻すためのリカバリ時間を測定
します。 プライマリの表には多くの制約があるので、表の2番目のセットを使用してデータベース サ
イズを増やします。 テストの実行中にこれらの表を再操作して、必要とされる変更レートを生成し
ます。 テスト手順の要約を以下に示します。
1. リストア ポイントを作成します。
2. すべての稼動テスト用の表に対して、行数の20%を基準にして行を挿入（および再カウント）します。
3. 1つのインスタンスをマウント モードで起動します。
4. フラッシュバック操作を実行します。
5. Open resetlogsを実行します。
6. RACデータベースを開始します。
7. 各表の合計行数を再カウントします。
フラッシュバックの対象となる、結果として得られたデータの総量は、約450GBです。 フラッシュバック
を含めたテストの所要時間はちょうど24時間にわたりましたが、この中にはデータの入力も含まれて
います。 実際のフラッシュバック データベース操作の所要時間は、2時間を多少上回る程度でし
た。 これは、24時間中22時間はデータの変更に費やしたことを意味します。つまり、この環境ではフ
ラッシュバックの所要時間は約10%だったことになります。図13に、フラッシュバック データベース操
作実行中のRACノードの測定値を示します。
20
図13 フラッシュバック実行中のパフォーマンス
全体的なホスト使用率は非常に低いのですが、この手順ではデータベースもオフラインになっていま
す。 フラッシュバック データベース操作には、2つの大きな注意点があります。
• データベースをオフラインにし、マウント モードにする必要がある
• フラッシュバックが完了した後、resetlogsを指定してデータベースを開く
これは、フラッシュバックを実行している間はデータベースが利用できないことを意味します。すべての
オブジェクトが元に戻されるからです。 フラッシュバックが完了した後、resetlogsを指定してデータベー
スを開き、フラッシュバック操作によって指定されたSCNまで戻します。
ベスト プラクティス
resetlogsを指定してデータベースを開いた後、データベースの完全オフライン バックアップを実行してください。
フラッシュバック リカバリ領域を使用したD2Dバックアップ
以下の一連のテストでは、フラッシュバック リカバリ領域（FRA）をD2Dのターゲットとして使用します
が、FRAが構成済みの場合は、RMANのバックアップ先のデフォルトはFRAになります。 このデフォルト
のバックアップ先を永久に変更するか、未構成にするか、そのままにすることができます。 RMANスク
リプトがメディア エージェントに送信されると、バックアップ先がHP Data Protectorによって実行時に変
更されます。 この状況では、実行中のバックアップの種類に対応できる十分な領域がFRAの中に存在
していることが必要になります。 また、バックアップをFRAの中に書き込む場合、Data Protectorはバッ
クアップを取得できない可能性があるので、このバックアップはオンライン リカバリ目的のものになりま
す。 リムーバブル メディアまたはディスクの他の場所をバックアップ先にする必要がある場合は、FRA
に対するバックアップとは別に、バックアップ作業を実行してください。
現時点では、Data Protector 6.0ではバックアップ データをFRAに書き込むことや、FRAをバックアップ
ターゲットとして使用することはできません。 Data ProtectorのR&Dチームが、現在この問題に取り組
21
んでいます。 この問題がData Protector製品の欠陥であることが明らかになった場合は、この問題は
修正され、パッチの形でリリースされる予定です。
RMANのベースライン バックアップ
このテストは、EVA6100上のFRAに対して書き込みを行う、データベースのベースライン バックアッ
プです。 バックアップ期間、ホスト、EVAの測定値を測定します。 このテストでは、OLTPワーク
ロードを使用しません。 このテストの実行中、ホストのCPU使用率は約40%であり、バックアップの
スループットは約220MB/秒であることが観察されました。表5に、この項で説明するバックアップ/
リストア テストの比較を示します。
OLTPワークロードを使用した場合のRMANバックアップ
このテストは、OLTPワークロードの進行中に、EVA6100上のFRAに対して書き込みを行う、データベー
スのバックアップです。 バックアップ期間、ホスト、EVAの測定値、さらにワークロードの進行中にOLTP
に及ぼす影響を測定します。 CPU使用率は約55%に増加し、バックアップ ベースライン テストに比
べると15%上昇したことになります。 バックアップ スループットは約150MB/秒です（バックアップの
ベースラインに比べると、パフォーマンスは70MB/秒低下しました）。 今回はOLTPワークロードを
適用しました。パフォーマンス測定値の比較を表5に示します。
注記：
RMANを使用する各バックアップでは、FRAに対して8つのチャネルを使用しました。
パフォーマンスの留意事項
負荷発生中のバックアップではパフォーマンスがある程度低下しましたが、これはD2Dバックアップ
なので、データのリストアは通常は高速です。 EVA6100上で使用したフラッシュバック ディスク グ
ループに存在していたFATAドライブは、48台のみです。 バックアップ ターゲットに対してさらに物理
ディスクを追加するか、FRAの作成と収容にEVA/ASMディスク グループを関与させると、パフォーマ
ンスを向上させることができます。
ベスト プラクティス
静止状態のデータベースに対してバックアップを実行すると、バックアップのパフォーマンスを向上させ、ユーザーに及ぼす影響を減らすことができます。
ベスト プラクティス
ディスクに対するバックアップを実行する際は、さまざまなRMANチャネル構成をテストして、ワークロードが発生している状況下での最大のパフォーマンスとバランスのとれたI/Oを調べてください。
RMAN D2Dのリストア
このテストは、EVA6100上のFRAに対して書き込んだデータベースのバックアップをリストアし、リス
トア時間を測定します。 整合性を維持するために、リストアの進行中に、ホストとEVAに関する測
定値を収集します。
EVA6100はFATAドライブを使用しているので、FCドライブに比べるとパフォーマンスは低くなります。ま
た、バックアップの実行時に、パフォーマンス コストの大きいRAID 5に対して書き込みを行いました。そ
のため、リストア パフォーマンスはバックアップのベースラインと同程度にとどまると予期する人もいる
でしょう。 このテストでは、FATAテクノロジの利点の1つ、つまり読み取りのパフォーマンスが強調され
22
ます。 リストアの実行中に観察されたパフォーマンスは、ベースライン バックアップの実行中に観察さ
れた値より明らかに高速でした。表5に、この項で説明する結果の比較を示します。
表5 D2Dバックアップとリストアのパフォーマンスの比較
OLTPベースライン
D2Dベースライン D2D負荷あり 変化率（%） D2Dリストア
TPS 66.75 なし 64.5 3% なし
GB/時 なし 840 516 38% 1029
以下のようないくつかの重要な結果が示されています。
• 最初の観察事項—バックアップ実行中にユーザーに及ぼす影響
D2Dバックアップの実行中、OLTPベースラインとのパフォーマンスを基準とした変化は、わずか3%
でした。 この割合がSLAの範囲外である場合は、主要なワークロード発生期間にバックアップ
を実行することは、重大な理由がある場合以外は推奨できません。 ただし、影響という点から
考えると、3%というのは非常に妥当な数値ともいえます。 これは、潜在的にはユーザー ベース
の97%が影響を受けないことを意味します。
• 2番目の観察事項—バックアップ期間の効率
最初のバックアップ期間では、バックアップ パフォーマンスが約840GB/時、つまり3TB近いデータ
ベースで約2時間45分であることが示されています。 一方、OLTPワークロードの発生中は、D2Dバッ
クアップ期間は約40%長い5時間40分近くに達し、パフォーマンスは516GB/時に低下しています。
D2Dリストア パフォーマンス
FRAをD2Dのターゲットとして使用するのは簡単なことです。 FRAを構成した場合は、RMANによるD2D
バックアップのターゲットは、デフォルトでFRAになります。 FRA上のクォータの中には、ディスク グ
ループ内に配置されたあらゆるバックアップが含まれ、FRA内にあるすべてのオブジェクトと、適用され
たクォータ サイズとのあいだに関係が存在します。
結論として、ピーク ワークロードの発生中にバックアップを実行すると、バックアップ期間は長くなりま
すが、ユーザーに及ぼす影響は限定されています。 ワークロードの発生期間にバックアップを実施す
る場合、ユーザーに及ぼす影響を詳細に観察し、バックアップの実行期間全体をとおして起こりう
るあらゆる問題を回避することが最善です。
フラッシュバック リカバリ領域の管理
フラッシュバック リカバリ領域（FRA）には、多くの異なるアイテムが含まれています。 フラッシュバック
を有効にしたOracleデータベースを日常的に使用している場合は、FRAの管理が重要なタスクになりま
す。 デフォルトでFRAに書き込まれるファイルの種類は、以下のとおりです。
• アーカイブREDOログ
• フラッシュバック リカバリ ログ
• D2Dバックアップ
FRA、UNDO_RETENTION期間、FRAに対するクォータ、RMAN、データベースの変更レートの間には、
明確な関係が存在します。 この項では、これらの関係と、Oracleフラッシュバック テクノロジを既存の
バックアップおよびリカバリ環境に統合する方法を説明します。
前述のオブジェクトの間では、簡単な物理的相互作用があります。 FRAを使用する場合、
LOG_ARCHIVE_DESTパラメータはFRAの場所に設定されます。 この動作はデフォルトであり、変更でき
23
ず、変更するべきでもありません。 追加のLOG_ARCHIVE_DEST[N]パラメータを使用することもできま
すが、一度に複数のアーカイブ プロセスが使用される結果になるので、アーカイブ プロセスに対す
るオーバーヘッドが追加されます。 クォータとフラッシュバックの保存期間を過度に小さく設定する
と、フラッシュバックの能力が限定されます。
この問題に対処する簡単な方法は、FRAターゲット内のクォータを大きくするか、保存期間を長くする
か、またはその両方を実行することです。 2番目に、FRAに対してオンライン ディスクベース（D2D）の
バックアップを追加する場合、FRAが過剰使用される可能性があります。 RMANがD2Dバックアップを
実行する場合、デフォルトのターゲットはFRAです。 実効的なクォータの上限に達しつつある場合は、
このことが問題を招く可能性があります。 より多くのアーカイブ ログが生成されるにつれて、保存期間
が短くなる可能性があります。アーカイブ ログは優先順位が高いからです。 また、同じディスク領域の
中に存在するデータベース バックアップを削除することもできません。ディスクに書き込んだ後は、バッ
クアップはOracleカーネルの管理対象ではないからです。 この状況が発生した場合は、アーカイブ ロ
グは引き続き生成され、フラッシュバック プロセスはフラッシュバック ログの数を減らすことにより、保
存期間を短縮します。 この結果、アーカイブ ログまたはデータベース バックアップが多くなるにつれ
て、フラッシュバック ログが上書きされる頻度が高くなります。
解決策は、可能であれば、クォータを増やすか、保存期間を短くすることです。 Oracleは、以下のサイ
ズ要因を考慮に入れてFRAをサイズ設定することを推奨しています。
• 希望のフラッシュバック保存期間の間に生成されるアーカイブのサイズ
• FRAに書き込まれる完全オンライン バックアップのサイズ
• 変更レートとフラッシュバック ログの数/サイズ
ベスト プラクティス
ディスク領域、フラッシュバック保存期間、バックアップのサイズ、生成されるアーカイブ ログのサイズを管理することにより、FRAの正しいサイズ設定が可能になります。
実際の環境で使用しているOracleデータベースのバックアップとリカバリ手順の一部として、FRAサイ
ズ要因の測定、検討、実装を継続的に実行してください。 テープを使用する場合より、リスクを適切に
管理し、成功することがほぼ保証された、より迅速なリカバリの手段を提供することができます。 その
結果、目標復旧時間（RTO）を短縮し、目標復旧時点（RPO）を拡大することができます。
注記：
FRAのサイズ設定が正しくない場合は、リカバリの能力が低下する結果になります。
以下の一連のテストでは、FRAの管理方法と、FRAを導入するときにバックアップおよびリカバリ環境
の安定性を保証する方法についていくつかの答えを提供します。
オンライン バックアップの二次的な場所への移動
バックアップは古くなり、時間の経過とともに有用性が低下しますが、フラッシュバック ログを使用する
場合は特にこのことが当てはまります。 新しいバックアップを作成する必要があります。 FRAのサイズ
に関するOracleの推奨によると、複数のオンライン バックアップを利用することができない場合があり
ます。 つまり、バックアップをアーカイブするかオフサイトに発送する場合、それらのバックアップをFRA
から三次的なリムーバブル ストレージに移動する必要があるということです。
24
現時点では、Data Protector 6.0はASMディスク グループのバックアップを他の場所に移動することが
できません。 バックアップをディスクベースの場所に移動するプロセスを実装することができます。その
後、オフサイトで保管するために、それらのバックアップをリムーバブル メディアに転送できます。 この
ソリューションにより、パッチが適用されていないData Protectorを使用して、FRAに対して書き込まれ
たバックアップを管理することができます。 次の項では、この環境でフラッシュバック ログを使用する
方法について説明し、バックアップの枠組みの中でのフラッシュバック ログの位置付けを特定します。
フラッシュバック ログのメンテナンス
フラッシュバック テクノロジを使用していない場合は、すべてのデータベース オブジェクトに関するバッ
クアップとリカバリが重要です。 FRAを追加すると、フラッシュバック ログのバックアップとリカバリも重
要になります。 フラッシュバック ログのバックアップとリカバリに関して特徴的な観点は、これらの
ログのバックアップとオフサイトでの保管です。 フラッシュバック ログを維持しておかない場合は、
バックアップをリストアした後、Point-in-Timeリカバリは利用できなくなります。 このため、リカバリを
行う方式としてバックアップ以外の唯一の手段がフラッシュバックである場合は、リカバリ機能が失
われ、データが失われる可能性があります。
フラッシュバック ログが存在していない場合は、アーカイブ ログを含めたすべてのデータベース オブ
ジェクトのバックアップとリストアを実行する以外の選択肢はありません。柔軟なPoint-in-Timeリカバリ
は利用できません。 このことは、フラッシュバック リカバリを有効にする場合、柔軟なPoint-in-Timeリ
カバリを利用するには、生成されたフラッシュバック ログを他のすべてのログと同様に維持し、安全に
保つ必要があることを意味します。
Data Protector 6.0は、標準的なバックアップ仕様にフラッシュバック ログを自動的に含めます。 フ
ラッシュバック リカバリ ログのみをバックアップするために、単一のバックアップ仕様を作成する
こともできます。
ベスト プラクティス
フラッシュバックを使用した柔軟なPoint-in-Timeリカバリによる追加の保護を維持するには、個別のジョブでフラッシュバック ログをバックアップする必要があります。
Data Protectorはログをバックアップすることはできますが、フラッシュバック リカバリ機能はフラッ
シュバック操作をする間、バックアップ メディアからフラッシュバック ログを取得することを要求しま
せん。 このことは、ディザスタ リカバリ リストアを実行するときに、フラッシュバック リカバリ機能が
非常に役立つことを意味しています。ディザスタ リカバリ リストアでは、データベースの完全リスト
ア、関連するアーカイブ ログとフラッシュバック ログのリストアがグループとして実行されるからで
す。 本書の範囲外になりますが、フラッシュバック データ アーカイブというOracleのもう1つのフラッ
シュバック オプションが存在し、Oracleの情報ライフサイクル管理（ILM）方針の一部としてフラッシュ
バック操作の実行中にメディアを要求する機能を利用できます。
テストの結論
テストの中で示したように、フラッシュバック リカバリ機能を、稼動しているOracleデータベースの一部
として統合することができます。 本書で実行したテストの要約を以下に示します。
テストの要約
• 環境の特性化
– EVAパフォーマンス
25
– ホスト パフォーマンス
– テープ パフォーマンス
• Oracleフラッシュバック
– フラッシュバック表
– フラッシュバック データベース
• D2Dバックアップ
– ホスト パフォーマンス
– FRAパフォーマンス
• フラッシュバック管理
さらに、環境、FRA、Data Protectorの構成についても説明しました。 以下の項では、テスト全体で使用
し、発見されたベスト プラクティスについて説明します。
26
フラッシュバック リカバリのベスト プラクティス
Oracleフラッシュバック リカバリ テクノロジを、特定のインフラストラクチャを使用した既存のバック
アップの枠組みに統合することは可能です。 多くの状況では、柔軟なPoint-in-Timeリカバリ機能
が役に立ち、必要でもありますが、Oracleフラッシュバック リカバリを採用することによって、この機
能を簡潔に実現できます。
以下の項では、サーバとストレージの各管理者、およびITマネージャ向けに、フラッシュバック リカバリ
の使用に関するベスト プラクティスについて説明します。 多くの管理者は複数の役割を兼ねており、こ
の情報は、ここで記載した範囲より広い意味で適用することも可能です。
最初に記載する一連のベスト プラクティスはサーバ/ストレージ管理者向けであり、バックアップとリカバ
リのソリューションを成功させるためのフラッシュバック リカバリの実装、およびOracleとData Protector
6.0への統合を対象としています。 2番目に記載する一連のベスト プラクティスはITマネージャ向けであ
り、フラッシュバック リカバリを採用および使用する場合に業務に及ぼす影響について説明します。
サーバ/ストレージ管理者
RedHat 5.0、Oracle、Data Protectorとの統合を担当する管理者向けのベスト プラクティスの概略を以
下に示します。
• Linux RACでボンディングNICを使用する
テストの実行中に、RAC相互接続のボトルネックを防止または緩和するために、Linuxボンディ
ング ドライバを使用してRACノードを構成します。 必要な場合は、この方法で最大2Gbpsのス
ループットを達成できます。 この手順はOracleによって推奨されたもので、Metalink Note 434375.1
ではボンディングNICのセットアップ方法、Metalink Note 298891.1 ではこの方法が役立つ理
由をより詳細に説明しています。
• バックアップとワークロードを処理するための十分なRAMがOracleで利用できることを確認する
Linux環境で共有メモリが最大になるように構成を行う場合、Oracle 11gデータベースの特定の
アプリケーションで利用できるRAMの量を正しく選択します。 Oracle 11gが自動メモリ管理機能
（AMM）を採用したことに注意する必要があります。 最初にOracle 10gでSGA_MAX_TARGETパ
ラメータが導入されましたが、その後、PGAとSGAが個別に存在するようになりました。 Oracle
11gは現在、MEMORY_MAXまたはMEMORY_MAX_TARGETパラメータを使用して、より一般化さ
れたメモリ プールをOracleに提供しています。 その場合、OracleはSGA、PGA、バッファ キャッ
シュの間でメモリを内部管理します。
• リストア ポイントと保証付きリストア ポイントを使用する
リストア ポイントは、サイズ要件を別にすると、Oracleフラッシュバック機能を最大限に活用できる
方法です。 コード、アプリケーション、またはデータに変更を加える前にリストア ポイントを作成して
おくと、問題が発生した場合でもそのリストア ポイントを使用して簡単にリカバリする方法が得られ
ます。 sysdbaユーザーとしてリストア ポイントを作成することを、保証付きリストア ポイントと呼びま
す。これは、通常のリストア ポイントとは異なり、自動的に削除または更新されることがないからで
す。 リストア ポイントの詳細については、を参照してください。
• 保存期間にわたってバックアップ、フラッシュバック ログ、アーカイブ ログを格納するための十分な
ディスク領域がFLASH DGにあることを確認する
FRAのサイズ設定が正しくない場合は、フラッシュバックの保存期間が大きな影響を受ける可能性
があります。 これは、特定のデータベースに対してFRAを全面的に使用するには、ある程度の
チューニングが必要であることを意味します。 FRAのサイズ設定の主要な留意事項は、生成される
27
アーカイブ ログの数、オンラインの完全バックアップをFRAの中で維持するかどうか、フラッシュ
バック保存期間、およびフラッシュバック ログのサイズです。 これらの要素の総合計が、通常
使用するFRAで必要とされる合計領域です。
• FRA内で少なくとも1つのオンライン バックアップを維持する
FRA内で1つのバックアップをオンライン状態で維持すると、発生する可能性のあるほぼすべて
のブロック破損に対して、簡単かつ迅速にリカバリを実行できます。 このバックアップをフラッ
シュバック ログと組み合わせると、ほぼすべてのPoint-in-Timeリカバリが利用でき、データ
ベースのアップタイムが20%近く長くなります。
• 表領域のデータをリカバリする目的でフラッシュバック データベースを使用しない
このベスト プラクティスは、メディアベースのすべてのオブジェクトに実際に当てはまります。
Flashback Databaseコマンドは、表領域などメディア オブジェクトのリストア/リカバリを行いません
が、Flashback Databaseコマンドを実行した後、それらのオブジェクトは存在しているように見えま
す。 これに対する解決法は、データをリストアするか、またはファントム オブジェクトを削除す
ることです。 そうしない場合、バックアップが失敗するか、表領域をバックアップしようとしたとき
にエラーが表示されます。
• フラッシュバック データベースは、すべてのオンライン オブジェクトを元に戻す目的で使用する
Flashback Databaseコマンドは、データベース全体を元に戻す必要がある場合に非常に役立つ
ツールです。 それ以外の場合は、フラッシュバック表とフラッシュバック トランザクションを使用
する必要があります。 フラッシュバック データベース操作を実行するにはresetlogsを使用する
必要があり、後で作成したバックアップを完全リストアする場合を除き、フラッシュバック デー
タベース操作を取り消すことはできません。
• 参照整合性を維持するためにフラッシュバック トランザクション問い合わせを使用する
フラッシュバック トランザクション問い合わせを使用すると、データベースにアクセスするアプリケー
ションにとっての参照整合性とデータ整合性が維持されます。 フラッシュバック トランザクション問
い合わせは、オンライン タスクと似た方法で実行されます。 フラッシュバック データベースは、特定
のオブジェクトに対するすべての参照を元に戻す、フラッシュバック トランザクション以外では
唯一の方法ですが、オンラインで実行することはできません。
• Oracle 11gのsection sizeパラメータを使用してbigfileのバックアップを並列化する
Oracle 11gでは、section sizeというRMANの新しいパラメータが追加されました。 この結果、単
一のbigfile表領域に対して複数のチャネルを割り当てることができます。 これにより、bigfile表
領域の並列バックアップと並列リカバリが実行できるようになり、時間の節約とパフォーマンス
の向上が達成できます。
• RMANリカバリ カタログ（RCVCAT）を使用する
RMANが使用されている場合は、RMANリカバリ カタログを構成して使用します。 通常はこのように
すると、カタログを使用する多くの役立つ機能が、使用中の環境に対して提供されます。
• RCVCATを使用するようにData Protectorを構成する
RMANカタログにアクセスできるようにData Protectorを構成すると、すべてのオフライン バックアッ
プ/リストア情報が複数の場所で追跡されることが保証され、環境に対して冗長性と管理可能性
が追加されます。 このベスト プラクティスに対する唯一の注意点は、カタログ データベースの
バージョンが11gとは異なる場合、RMANカタログを収容しているデータベースにアクセスできる
ようにするために、環境内で追加のOracleクライアントをインストールする必要が生じることで
す。 この結果、RMANリカバリ カタログに対するシームレスな操作、移植性、保護が保証され
28
ます。 このクライアントを使用しない場合は、RMANデータベースの完全バックアップなしでは、
RMANカタログの個別のバックアップは容易に作成できません。
• フラッシュバック ログの場合でも、増分バックアップを使用する
増分の方針を使用してフラッシュバック ログのバックアップを実行すると、増分リストアの後、柔軟
なリカバリを行うために必要なリカバリ メディアが作成されます。
• データベースの完全バックアップの直後に、個別のジョブでフラッシュバック ログをバックアップする。
この結果、データベースの完全リストア/リカバリの直後に、適用する必要のある任意の増分バック
アップに加えてフラッシュバックを使用することにより、データまたはオブジェクトの柔軟なリカ
バリを実行できるようになります。
• UNDO領域を綿密に管理する
フラッシュバック リカバリを使用している場合は、UNDO領域がさらに重要になります。システムはフ
ラッシュバック操作の使用を開始します。 フラッシュバック リカバリを使用する場合の課題に対応す
るために、UNDO_SIZEとUNDO_RETENTION_PERIODパラメータの両方を変更する必要が生じます。
フラッシュバック リカバリの実装は、それ自体がベスト プラクティスとして数えることが可能なものです
が、フラッシュバック リカバリを使用する場合は、すべての段階で成功を保証するためにいくつかの事
項が必要になります。 本書では一連の作業をとおしてこのテクノロジをテストしましたが、フラッシュ
バック リカバリを使用する場合は、業務や管理に関連するより多くのベスト プラクティスを考慮する必
要があります。 次の項では、そのようなベスト プラクティスをいくつか説明します。
ITマネージャ
• リカバリ シナリオで、FRAのディスク領域を予算化する
FRAはストレージの予算を増加させる可能性があるので、将来、ストレージ購入の決定を下す際
に、このコストを考慮に入れます。
• FRAを使用することによるRTOとRPOへの影響を比較する
テストの結果、環境でフラッシュバック リカバリを採用するだけでリカバリ時間は大幅に短縮される
ことが示されました。 フラッシュバック リカバリが特定の環境にどのような影響を及ぼすのか理
解するために、分析を実行します。
• リカバリ計画に及ぼす影響を分析する
RTOとRPOの比較が重要であることに加えて、フラッシュバック リカバリを使用した場合にRPOと
RTOの変化が全体のリカバリ計画にどのような影響を及ぼすのかを把握することは、各業務部
門、およびサービス レベル アグリーメントにとって重要な情報となります。
• FRAを使用することによるシステム全体への影響を分析する
フラッシュバック リカバリを使用すると、パフォーマンスにわずかな影響を及ぼす可能性がありま
す。 今回の環境ではパフォーマンスに対する顕著な影響は観察されませんでしたが、フラッシュ
バック リカバリを使用する場合と使用しない場合の、特定の処理能力に対する実際の環境のアプ
リケーションのパフォーマンスを比較してください。
• フラッシュバック リカバリの構成をチューニングする
フラッシュバックの保存期間は、RTOとRPOに直接的な影響を及ぼし、変化を生じさせます。 保存
期間および保存期間が環境に及ぼす影響について理解すると、IT管理部門がSLAが適切に実施
29
されているかを確認するのに役立ちます。 FRAの構成を正しく管理する簡単な方法は、Oracle
Enterprise Managerのリカバリ設定にアクセスすることです。
• ストレージ使用の変化を監視する
特定の環境においてOracleデータベースでフラッシュバック リカバリが広く使用されるようにな
ると、SAN上でI/Oとスループットを使用する理由が増えるため、ストレージの使用に変化が
生じる可能性があります。
• FRAのパフォーマンスを監視する
フラッシュバック リカバリが環境に統合されるにつれて、長い保持時間で使用されると、フラッシュ
バック リカバリのパフォーマンスは時間の経過とともに低下する傾向があります。環境内にある高
いワークロードと組み合わせた場合は、特にこのことが当てはまります。 フラッシュバック リカバリ
を正しくない種類のディスクに配置した場合や、使用するディスク グループの中に十分な台数の
ディスクがない場合は、フラッシュバック リカバリがボトルネックになる可能性もあります。 EVAPerf
を使用して、ASMディスク グループ内のLUNを監視することもできます。
観察結果
テストの実行中に、構成のうちさまざまな部分に対していくつかの観察がなされました。 このセク
ションでは、それらの観察結果に注目します。
Oracleフラッシュバック
フラッシュバックのテストを実行する間に、フラッシュバック リカバリを使用した表領域のリカバリが不
可能であること、ただし表領域と表の構造は維持されることを学びました。 関連するデータ ファイルを
リカバリするには、データベース管理者は表領域をバックアップからリストアする必要があります。
フラッシュバック リカバリは、バックアップを使用しません。 ただし、アーカイブ ログが必要な場合は、
バックアップからリストアすることができます。 バックアップに対して、フラッシュバック ログの要求/リス
トアが自動的に実行されることはありません。 フラッシュバック データ アーカイブは以前のバックアッ
プを使用しますが、この点は今回のプロジェクトで実施したテストの範囲外です。
RMANを使用してフラッシュバック操作を実行する場合、リストアとフラッシュバックをスクリプト化する
ことが多いでしょう。
RMAN/Data Protector
Data ProtectorをOracleに統合すると、FRAをD2Dデバイスとして使用できないことが明らかになりまし
た。 Data Protectorを使用するとバックアップをスクリプト化することができ、バックアップをスケジュー
ル設定することも可能です。 ただし、この種のバックアップに対するData Protectorの管理機能は、
RMANが管理するD2Dバックアップのシナリオ以外では、Data Protectorの管理対象にはなりません。
この中には、FRAから他の場所にバックアップを移動することも含まれます。 今回のテスト結果に基づ
き、現在、Data Protector開発チームがこの問題に取り組んでいます。
もう1つの観察結果は、Data Protectorの現在のバージョンはbigfileを自動的に分割せず、Oracle 11g
の自動分割機能にも対応していないことです。 現時点では、この問題に対する対応策は、バック
アップ対象である各ラージ オブジェクトに対応するバックアップ仕様の中でSECTION_SIZEパラ
メータを指定することです。 今後数か月のうちにData Protectorのパーサに対する公式の変更が
利用可能になる予定です。
堅牢なバックアップ ソリューションにとって、RMANリカバリ カタログ（RCVCAT）を使用することが非常
に重要です。 一方、テストの実行中に観察されたもう1つの事実として、デフォルト構成ではData
30
Protectorはリカバリ カタログをエクスポートできません。 Data Protectorでエクスポートを行うには、
リカバリ カタログを格納しているデータベースのバージョンに適したエクスポート ユーティリティを
インストールする必要があります。 Data ProtectorのGUIでエージェントのインストール チェックが
実行された場合、この要件に関するチェックは実行されません。
観察された最後の問題は、resetlogsオプションを使用してデータベースを開いた後は、Data Protector
のバックアップ カタログにアクセスできないということです。 この状況では、フラッシュバック データ
ベース操作が実行されることが原因で、このような結果になりました。 より完全性の高いリカバリが
必要な場合は、何もリストアできません。 オフライン モードでオブジェクトのバックアップを実行す
ると、resetlogsを使用したデータベースに関する問題がクリアされ、Data Protectorを使用して再び
オブジェクトをリストアできるようになります。
Oracleフラッシュバック リカバリを環境に実装すること自体は簡単なタスクですが、ストレージ予算に関
する計画が必要です。 とはいえ、管理者、マネージャ、業務部門に対して大きな利点がもたらされま
す。 たとえば、管理者は重大な問題を解決したり、他の方法では業務を停止させてしまうような問題に
対してオンラインで対処したりすることができます。その結果、停止や破損の期間が限定され、以前よ
り効果的にSLAを達成することができます。 また、フラッシュバック リカバリをData Protector 6.0と組み
合わせて使用すると、従来は達成できなかったレベルの簡潔さを実現し、柔軟なリカバリ機能を提供
することで、すでに使用されているバックアップとリカバリのソリューションを拡張することができます。
31
結論
本書ではフラッシュバックを使用したOracle 11g環境向けに、完全に機能するHPのサーバ、ストレー
ジ、およびバックアップからなるインフラストラクチャを適切に計画し、成功裏に導入し、効率的に運用
する方法を説明しました。 また、具体的で詳細な例を通して、HP Data Protectorを設定し、Oracle 11g、
RMAN、およびフラッシュバックに統合して、シームレスな導入と運用を保証する方法も示しました。
プランニングの主な留意事項には、次のものがあります。
• 適切なバックアップ タイプを選択し、必要に応じて完全バックアップと増分バックを組み合わせる。
• Oracle 11gが採用した自動メモリ管理機能（AMM）を使用し、SGAのサイズに関わりなく、パ
フォーマンスを向上させる。
• 外部のRMANリカバリ カタログ（RCVCAT）とブロック変更の追跡を使用し、リカバリ時間を短縮する。
• UNDO_RETENTIONパラメータに対して細心の注意を払い、アラート ログの中でUNDOに関す
るあらゆるメッセージを監視する。
– 過度にサイズの小さいUNDO_RETENTIONパラメータを指定した場合は、特定の時点までに
多数の変更のリカバリを実行する際に、フラッシュバックの有効性が低下する可能性があり
ます。 多くの場合は、単純にUNDOを大きいサイズに再設定し、フラッシュバック操作を繰り
返すことにより、この問題に対処できます。
• 特定の時点までフラッシュバックし、データの整合性を保証するには、フラッシュバック トラン
ザクション問い合わせを使用する。
– 代わりに、フラッシュバック データベース操作を実行することもできます。 ただし、これはオフラ
イン操作なので、手軽に使うことはできません。
• フラッシュバック データベースを使用して表領域のフラッシュバックをしない。 表領域ではなく、表
領域のメタデータとそれに関連するオブジェクトがリストアされます。 表領域をリカバリするには、
RMANの完全リストアを実行する必要があります。
– Oracleフラッシュバック リカバリを使用することにより、トランザクション レベルでオンライン
Point-in-Timeリカバリを有効にし、オフライン バックアップにアクセスする必要が生じるこ
とを回避できます。
• resetlogsを指定してデータベースを開いた後、データベースの完全オフライン バックアップを
実行する。
• ディスクに対するバックアップを実行するときに、必要に応じてさまざまなRMANチャネル構成
をテストし、ワークロードが発生している状況下での最大のパフォーマンスと、バランスのと
れたI/Oを見つける。
• ディスク領域、フラッシュバック保存期間、バックアップのサイズ、生成されるアーカイブ ログの
サイズを管理することにより、FRAのサイズ設定を正しく行う。
– FRAのサイズ設定が正しくない場合は、リカバリの能力が低下する結果になります。
• フラッシュバックが提供する柔軟なPoint-in-Timeリカバリによる追加の保護を維持するために、個
別のジョブでフラッシュバック ログをバックアップする。
• バックアップのテストを定期的に実行する。バックアップを他の場所にリストアし、リストアされた
データベースの起動を試みます。
メンテナンスの主な留意事項には、次のものがあります。
32
• Data Protectorの内部データベースを定期的にバックアップする。
• できる限り負荷の少ない時間帯にデータベースのバックアップを実行し、バックアップのパフォーマ
ンスを向上させ、ユーザーに及ぼす影響を減らす。
• RMANカタログ データベースを使用して以下を実行する。
– Data Protectorの内部データベースにおける冗長性の実現
– 制御ファイルの消失に対する保護
– Oracle Data Guardのフィジカル スタンバイ データベースの作成のための、イメージ コピー
のリストア
• RMANとData Protectorの両方を保護する。RMANカタログをバックアップし、別のメディアに冗長
コピーを保持する。
これらすべての主要留意事項の理解と対処方法の正確な把握が、HPのサーバ、ストレージ、バッ
クアップ ソフトウェアを使用するOracle 11g環境でバックアップ インフラストラクチャの導入を成功
させるうえで重要です。 本書で説明されテストで実証された手法は、確実に成功に導く完全な
ガイドとして利用できます。
お客様のフィードバックは、有効に活用させていただきます
お客様の情報ニーズに応える技術資料を作成するために、HPではお客様のフィードバックを必要とし
ています。 お客様が時間を費やしてくださることに感謝し、お客様のご意見を尊重します。 以下のリン
クを使用すると、本書の品質に関する短い調査に回答することができます。
http://hpwebgen.com/Questions.aspx?id=12046&pass=41514（英語）
33
付録A 構成の一覧
製品 個数 バージョン
ストレージ
HP StorageWorks Enterprise Virtual Array 8100（2C12D） 1 6110（CR0ECAxcsp-6110）
HP StorageWorks 300 GB 15K FC HDD
BF300DA47B
168 HP00
HP StorageWorks Enterprise Virtual Array 6100（2C8D） 1 6110（CR0ECAxcsp-6110）
HP StorageWorks 300 GB 15K FC HDD
BF300DA47B
64 HP03
HP StorageWorks 500GB FATA HDD
NB50058855
48 HP03
HP StorageWorks Modular Smart Array 1500cs 1 7.11 A/A
サーバ
ProLiant DL585 − Oracle RACデータベース サーバ 2 R01
HP ProLiant Support Pack 7.91a
Red Hat Enterprise Linux 5 Server 5.0 カーネル2.6.18-8.el5
Oracle 11g Enterprise Edition 11.1.0.6.0
Oracle Clusterware 11.1.0.6.0
HP 300 GB 10K SCSI 3.5インチ ホット プラグ ハード ディスク ドライブ 2
HP DL585 R01 4P USサーバ 2
HP DL585 R01メモリ拡張ボード キット 2
HP 4 GB REG PC2-3200 2×2GB DDRメモリ 8
Qlogic SANSurfer 5.0.0ビルド14
HP Procurveスイッチ2728C 2
HP FC2143 4GbデュアルチャネルPCI-e HBA 3 8.01.06.01-fo 1.09 4.00.23
ProLiant DL380 − HP OpenView Operations for Windowsサーバ 1 G3
HP ProLiant Support Pack 7.91
Microsoft Windows 2003 Enterprise x32 Edition RC2 SP2
Oracle 11g Client Win32 11.1.0.6.0
HP OpenView Operations for Windows 7.50（パッチ213、228を含
む）
HP OpenView Smart Plug-in for Unix OS 7.5072
HP 36GB 15K U320ホットプラグ対応ハードディスク ドライブ 2
インテルX3.00GHz G3プロセッサ 4
HP DL580 R03メモリ拡張ボード 2
HP 2 GB REG PC2-3200 2×1GB DDRメモリ 8
ProLiant DL380 − HP Fabric Managerサーバ 1 G4
HP ProLiant Support Pack 7.91
Microsoft Windows 2003 Enterprise x64 Edition RC2 SP2
HP Fabric Manager 5.3.0
34
HP 36GB 15K U320ホットプラグ対応ハードディスク ドライブ 2
インテルXeon MP X2.85GHz-2MBプロセッサ 4
HPホットプラグ拡張ボード メモリ 2
HP 4096MB PC1600 Reg SDRAMメモリ 8
ProLiant DL380 − Benchmark Factoryサーバ 1 G3
HP ProLiant Support Pack 7.90
Microsoft Windows 2003 Enterprise Edition RC2 SP2
Oracle 11g Client Win32 11.1.0.6.0
Quest Software Benchmark Factory for Databases 5.0.1
HP 36GB 15K U320ホットプラグ対応ハードディスク ドライブ 2
インテルXeon MP X2.85GHz-2MBプロセッサ 4
HPホットプラグ拡張ボード メモリ 2
HP 4096MB PC1600 Reg SDRAMメモリ 8
ProLiant DL360 − HP Command Viewサーバ、およびRapid Deployment Pack
サイトA
1 G5
HP ProLiant Support Pack 7.91
Microsoft Windows 2003 Enterprise x64 Edition RC2 SP2
HP StorageWorks Continuous Access EVA 7.0.0ビルド070606
HP StorageWorks Command View EVA 7.0.0ビルド070606
HP StorageWorks EVAPerf 7.0.0ビルド44
Intel Xeon 3.06GHzプロセッサ 2
HP 72GB 15K U320ホットプラグ対応ハードディスク ドライブ 1
Qlogic SANSurfer 5.0.0ビルド4
Qlogic HP2142ホスト バス アダプタ（HBA） 2 9.1.4.15/1.45
Microsoft Storportドライバ パッチ 916048
HP ProLiant Essentials Rapid Deployment Pack - Windows Edition 3.5（6.8ビルド282 SP1）
HP MPIO Full Featured DSM for MSA Disk Arrays 1.00.01
HP MPIO DSM Manager 2.00.00
SANインフラストラクチャ
HP StorageWorksマルチプロトコル ルータ フル16ポート 2 5.3.0
HP StorageWorks 4/32 SANスイッチ 4 5.3.0
PacketStorm Hurricane II Network Emulator Analyzer 1 14.2v1
35
付録B 例
Linuxカーネルの構成
Linux環境でOracle 11gのインストールと使用を正しく行うには、Oracleソフトウェアをインストールする
前にいくつかのカーネル パラメータを設定する必要があります。 次に、/etc/sysctl.confファイルの中
で設定し、再起動後も持続させる必要のあるカーネル パラメータのリストを示します。
# Controls the maximum shared segment size, in bytes kernel.shmmax =68719476736 # Controls the maximum number of shared memory segments,in pages kernel.shmall = 4294967296 kernel.shmmni = 4096 # Controlsthe number of semaphores kernel.sem = 250 32000 100 128 # Controlsthe number of system-wide open files fs.file-max = 6553600 # Controlsthe available local port ranges allowed to users net.ipv4.ip_local_port_range = 1024 65000 # Controls the network receive buffer configurationnet.core.rmem_default = 4194304 net.core.rmem_max = 4194304# Controls the network write buffer configuration net.core.wmem_default= 262144 net.core.wmem_max = 262144
Linuxボンディング ドライバ
Linux環境でRAC相互接続のスループットを向上させるには、Linuxボンディング ドライバを採用す
る必要があります。 この環境で使用する構成では、サーバごとにNICを2枚のみ使用しましたが、
必要な場合はそれより多くのNICを使用できます。 次に、Linuxサーバ上でのボンディング イン
ターフェース設定の例を示します。
Output From: /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0ONBOOT=yes BOOTPROTO=static TYPE=Ethernet IPADDR=10.10.10.100 NETMASK=255.255.255.0 NETWORK=10.10.10.0 BROADCAST=10.10.10.255
Linux 2.6カーネル システム上で/etc/modprobe.confファイルに変更を加えて、ボンディング ドライバを
ロードする必要があります。 次に、このファイルからの出力を示します。
alias bond0 bonding options bond0 mode=0 miimon=100
ボンディング ドライバを使用する場合の注意点は、それぞれのインターフェースを設定し、ボン
ディング インターフェースにスレーブ デバイスとして含める必要があることです。 次に、この設定
の一例を示します。
Output From: /etc/sysconfig/network-scripts/ifcfg-eth2 # IntelCorporation 82546EB Gigabit Ethernet Controller (Copper) DEVICE=eth2ONBOOT=yes BOOTPROTO=static HWADDR=00:11:0A:59:B3:F2 TYPE=Ethernet MASTER=bond0 SLAVE=yes
Linuxボンディング ドライバの実装の詳細については、次のHP DocumentationのWebサイトを参
照してください。
http://docs.hp.com/en/B9903-90050/ch05s04.html" http://docs.hp.com/en/B9903-90050/
ch05s04.html（英語）
http://docs.hp.com/en/B9903-90050/ch05s04.html" http://docs.hp.com/en/B9903-90050/
ch05s04.html（英語）
HP EVA、Oracle ASM、およびOracleデータベースの関係
Oracleデータベースを、HP Enterprise Virtual Array上のASMと組み合わせて使用する場合は、最高の
パフォーマンスと信頼性を達成するために、ベスト プラクティスに従ってください。 最高のパフォー
36
マンスを達成するために、EVAは、利用可能なすべてのディスクからなる単一のディスク グループ
を使用して構成する必要があります。 領域を節約し、LUNごとのパフォーマンス曲線を確立するた
めに、RAIDレベルを変更することもできます。
ASMとEVAの構成の詳細については、次のHPのCFTホームページにある『Best Practices for Oracle
10g ASM and the EVA8000』を参照してください。
http://www.hp.com/go/hpcft（英語）
ASMディスク グループの説明
ASMディスク グループは、EVAからホストに対して提供されたLUNの集合体です。 たとえば、ホスト
に対して提供されたあらゆるRAID 1のLUNは、プライマリASMディスク グループとして構成できま
す。 これは通常、オンライン ログを含め、最も重要なデータベース ファイルの格納場所として使用
します。 すべてのディスクがあらゆるLUNで使用され、ホットスポットを回避できるので、優れたパ
フォーマンスを達成します。 EVAは必要に応じてデータを移動し、ASMインスタンスも必要に応じ
てデータを移動するので、優れたパフォーマンスを達成します。 プライマリ ディスク グループの
LUNはRAID 1なので、信頼性も維持されます。
RAID 5 LUNは優れた読み取り性能を発揮しますが、書き込みの場合はペナルティが発生します。 こ
のため、RAID 5 LUNによる2番目のASMディスク グループを作成することは、適切な選択肢になりま
す。 アーカイブ ログ、バックアップ、フラッシュバック ログ、さらにtemp領域も、この2番目のASMディス
ク グループに格納するように設定することができます。 これによって、ある程度のパフォーマンス低
下と引き換えに、領域を節約できます。 アーカイブ ログに関しては、通常このことは問題になりま
せんが、複数のRAID 5 LUNからなる単一のASMディスク グループの中に、二重化したオンライン
ログを格納することは推奨されていません。
Oracleのリストア ポイント
リストア ポイントを使用することにより、ほとんどどんな状況でもOracleフラッシュバック リカバリを管理
できます。 次のような2種類のリストア ポイントを設定できます。
• 保証付きリストア ポイント： sysdba権限を持つユーザーによって作成されたもので、制御ファイル
から更新されることはない。 保証付きリストア ポイントは、明示的に削除する必要があります。
• 通常のリストア ポイント： 任意のユーザーによって作成されたもので、フラッシュバック保存期
間の経過後は上書きされる可能性がある。
37
詳細情報
HPテクニカル リファレンス
• Configuring Oracle ASM hidden parameters for EVA8000 knowledge brief
http://h71028.www7.hp.com/enterprise/cache/429462-0-0-225-121.html
• Best Practices for Oracle 10g with automatic storage management and HP StorageWorks Enterprise
Virtual Array white paper
http://h71028.www7.hp.com/enterprise/cache/429462-0-0-225-121.html
• HP StorageWorks Enterprise Virtual Array configuration best practices — white paper
ftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-9140EN.pdf
• HP StorageWorks Continuous Access EVA administrator guide
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01080802/c01080802.pdf
• HP StorageWorks Continuous Access EVA planning guide
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01080818/c01080818.pdf
• HP StorageWorks SAN design reference guide
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00403562/c00403562.pdf
HPソリューションおよびトレーニング
• Customer Focused Testing
http://www.hp.com/go/hpcft
• HP & Oracle alliance
http://h71028.www7.hp.com/enterprise/cache/4281-0-0-0-121.html
• Network Storage Services
http://h20219.www2.hp.com/services/cache/10825-0-0-225-121.aspx
• HP Storage and SAN Education Courses
http://education.hp.com/curr-storsan.htm
HP製品サイト
• Enterprise Class Storage Portfolio
http://h18006.www1.hp.com/storage/enterprisestorage.html
• HP StorageWorks Enterprise Virtual Arrays
http://h18006.www1.hp.com/products/storageworks/eva/index.html
• HP StorageWorks 1500cs Modular Smart Array
http://h18006.www1.hp.com/storage/disk_storage/msa_diskarrays/san_arrays/msa1500cs/
index.html
• HP StorageWorks Command View EVA
38
http://h18006.www1.hp.com/products/storage/software/cmdvieweva/index.html
• HP StorageWorks Continuous Access EVA
http://h18006.www1.hp.com/products/storage/software/conaccesseva/index.html
• HP ProLiant DL Servers
http://h10010.www1.hp.com/wwpc/pscmisc/vac/us/en/ss/proliant/proliant-dl.html
• HP BladeSystem
http://h71028.www7.hp.com/enterprise/cache/80316-0-0-0-121.aspx
• B-Series SAN Switches
http://h18006.www1.hp.com/storage/networking/b_switches/san/index.html
• HP StorageWorks 400 Multi-protocol Router
http://h18006.www1.hp.com/products/storageworks/400mpr/index.html
• Multi-Path Options for HP Arrays
http://h18006.www1.hp.com/products/sanworks/multipathoptions/index.html
• Fibre Channel Host Bus Adapters
http://h18006.www1.hp.com/storage/saninfrastructure/hba.html
• HP OpenView Operations for Windows
http://h20229.www2.hp.com/products/ovowin/index.html
• HP OpenView Performance Manager & Agent
http://h20229.www2.hp.com/products/ovperf/index.html
• HP OpenView Smart Plug-in for Unix
http://h20229.www2.hp.com/products/spi/spi_server/index.html
• HP StorageWorks Fabric Manager
http://h18006.www1.hp.com/products/storageworks/fabricmanager/index.html
• HP ProLiant Essentials Rapid Deployment Pack
http://h18013.www1.hp.com/products/servers/management/rdp.html
• HP ProLiant Essentials ProLiant Support Pack
http://h18013.www1.hp.com/products/servers/management/psp/index.html
Oracle
• Oracle Database Installation Guide 11g Release 1 (11.1) for Linux
http://download.oracle.com/docs/cd/B28359_01/install.111/b32002.pdf
• Oracle Real Application Clusters Installation Guide 11g Release 1 (11.1) for Linux and UNIX
http://download.oracle.com/docs/cd/B28359_01/install.111/b28264.pdf
• Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux
39
http://download.oracle.com/docs/cd/B28359_01/install.111/b28263.pdf
• Oracle Database Backup and Recovery User’s Guide 11g Release 1 (11.1)
http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/title.htm
• Oracle Database SQL Language Reference 11g Release 1 (11.1)
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_6011.html
Quest Software
• Benchmark Factory for Databases（データベース パフォーマンスおよびスケーラビリティ テスト）
http://www.quest.com/benchmark_factory/
© 2008 Hewlett-Packard Development Company, L.P.本書の内容は、将来予告なしに 変更されることがあります。 HP製品、またはサービスの保証は、当該製品、およびサービスに付随する明示的な保証文によってのみ規定されるものとします。 ここでの記載で追加保証を意図するものは一切ありません。 ここに含まれる技術的、編集上の誤り、または欠如について、HPはいかなる責任も負いません。Oracleは、Oracle Corporationおよびその関連会社の登録商標です。4AA1-7713JAP、2008年3月
40