Oracle Database には、データベース/アプリケーションの高可用性を実現するための様々な機 能が実装されています 本セ シ ンでは その中でも O l D t G d と O l
能が実装されています。本セッションでは、その中でも Oracle Data Guard と Oracle
Recovery Manager の2つのコンポーネントについて、11g R2での機能拡張や変更点について 説明します。
一般的にデータベースの可用性を向上させるための方法としては、ディスクの冗長化（Oracle ではASM [A t ti St M t] を提供）による耐障害性の向上 クラスタリング ではASM [Automatic Storage Management] を提供）による耐障害性の向上、クラスタリング （OracleではRAC [Real Application Clusters] を提供）によるデータベースサーバーの対障害 性向上、そしてスタンバイデータベース（Oracleでは、Oracle Data Guardを提供）によるデータ ベース全体の対障害性向上の3つが挙げられます。スタンバイデータベースは、データベースを 構成する全ての要素において本番データベースと切り離されるため、より広範囲な障害にも対 応可能です。例えば、スタンバイデータベースを本番データベースから遠隔地に配置することで、 地震や火災などのデータセンター全体に影響が及ぶ障害が発生した場合もデータベースの可 用性を維持することができます。
Oracle Data Guard（以降、Data Guard） は、Oracle Databaseのスタンバイデータベース機能 です。本番データベース（プライマリ・データベースと呼びます）のコピーとしてスタンバイ・データ ベースを作成し、そのメンテナンス、管理および監視など、一連の包括的なサービスを提供しま す。スタンバイ・データベースはプライマリ・データベースとトランザクション一貫性のあるコピー として作成され、作成後はプライマリ・データベースから送信される REDO を適用することによ って、プライマリ・データベースの変更に追従します。プライマリ・データベースが計画的または 計画外の停止によって使用不可能になった場合は、スタンバイ・データベースをプライマリ・デ ータベースに切り替えることで 停止時間を最小限にできます Oracle Data Guard は ータベースに切り替えることで、停止時間を最小限にできます。Oracle Data Guard は Oracle Database Enterprise Edition が提供する機能です。
スタンバイ･データベースを導入する際の課題の一つとして、通常運用時にスタンバイ側が遊休 リソースになってしまう点が挙げられます。Data Guardでは、この課題を解決するために、スタ ンバイ側を検索用途で使用可能にするロジカル･スタンバイやActive Data Guard Option が提 供されています。
Data Guardには、フィジカルスタンバイとロジカルスタンバイの2種類があります。それぞれにス ライドに記述された特徴があります
Oracle Database 11g Release 2 の Data Guardでは、様々な機能拡張がされています。以降 は スライドの3点のポイントからそれぞれの機能拡張について説明します
Data Guard はOracle Database の更新ログであるREDOをスタンバイ･データベースに転送 することで デ タを保護します D t G dでは 即時性（最新のデ タを保護） 性能（アプ することで、データを保護します。Data Guardでは、即時性（最新のデータを保護）、性能（アプ リケーションに影響をあたえない）、コスト（低コストなネットワーク構成）という観点で、リリースを 重ねるごとにREDO転送関連の機能を強化してきました。11g R2 においても様々な機能拡張 が行われています。
Data GuardはREDO転送によってデータを保護します。データファイル等、REDOログ以外の フ イル の更新を転送する必要はありません 転送するデ タが少量で済む分 帯域幅など ファイルへの更新を転送する必要はありません。転送するデータが少量で済む分、帯域幅など を抑えてより安価なネットワークで強力なデータ保護を実現できます。これはコスト面で大きなメ リットが言えます。 スライドは、REDO転送の仕組みや関連バックグラウンド･プロセスを図に示したものです。 REDO転送には、同期と非同期と2種類の転送方式があります。それぞれ、プライマリ･データ ベースのNSS（同期）プロセスまたはNSA（非同期）プロセスがREDOログ･バッファからスタン バイ・データベースのRFS（Remote File System）プロセスへREDOを転送します。（NSS/NSA
プ プ ず プロセスは 11g R1以前はLNSというプロセス名で起動されていました）この仕組みにはまず、 REDOのみの転送であるためデータ･ブロックの破損をスタンバイに伝播しないというメリットが あります。また、メモリ間の通信であるため余分なDisk I/O が発生することもなく、アプリケーシ ョンの性能に与える影響を低減できるという点もメリット言えます。 ネットワークの一時的な障害などによりREDOを転送できない時間が発生した場合、Data GuardはアーカイブREDOログの単位でそのギャップを自動解決します。
スライドは非同期REDO転送の仕組みを示しています。トランザクションのコミットが発生すると、 LGWRプロセスはオンラインREDOログにREDOを書き込みレスポンスを戻します その動作と LGWRプロセスはオンラインREDOログにREDOを書き込みレスポンスを戻します。その動作と は非同期にNSAプロセスはREDOログ･バッファからREDOを読み出し、スタンバイのRFSに転 送します。非同期であるため、基本的にアプリケーションのレスポンス時間に影響を与えること はほとんどありません。この動作は 11g R1からのものです。 大規模な更新処理で大量のREDOが生成される場合や、REDO生成量に対して転送ネットワ ークの帯域が足りない場合、ログ･バッファからREDOがフラッシュされる速度に対してREDO転 送が追いつかなくなる場合があります。このような場合、NSAはオンラインREDOログから バ 転送 転送 ズ グ バ 転 REDOを読み出し、スタンバイに転送します。REDO転送量の総サイズとログ･バッファから転 送されたサイズは以下のOracle統計情報から参考情報を得ることができます。
redo k-bytes read total by LNS （全体のREDO転送量）
スライドは同期REDO転送の仕組みを示しています。11g R2 では同期REDO転送の仕組みが 変更されました トランザクシ ンのコミ トが発生すると LGWRプロセスのオンラインREDOロ 変更されました。トランザクションのコミットが発生すると、LGWRプロセスのオンラインREDOロ グへのREDO書き込みとNSSプロセスのREDO転送が同時に発生します。スタンバイのRFSプ ロセスはスタンバイREDOログへのREDO書き込みが完了したらプライマリ側に通知します。全 ての動作が完了するとトランザクションにレスポンスが返ります。
スライドの図にあるように、従来のリリースにおける同期REDO転送では、オンラインREDOロ グへのREDO書込みが完了後にREDO転送が開始し スタンバイREDOログへの書込みが完 グへのREDO書込みが完了後にREDO転送が開始し、スタンバイREDOログへの書込みが完 了後にレスポンスを返すという処理順序でした。11g R2 ではオンラインREDOログへのREDO 書き込みとスタンバイへのREDO転送の処理が同時に開始するため、最終的なレスポンス時 間が短縮されます。いずれのケースでも、レスポンス時間は以下の3つの処理時間に依存しま す。
(1) オンラインREDOログへのI/O時間 (Disk I/O性能に依存)
(2) REDO転送と完了通知時間 (ネットワークRTT [Round Trip Time] に特に依存) (3) スタンバイREDOログへのI/O時間 (Disk I/O性能に依存)
( ) タン イ グ の 時間 ( 性能に依存) 例えば遠隔地にスタンバイ・データベースを配置した場合、RTTが長くなり、その結果REDO転 送時間が長くなることが予想されます。このようなケースでは 11g R2の仕組みであっても同期 REDO転送待ちによるオーバーヘッドが大きくなる可能性があります。 一方、近距離やローカルにスタンバイ･データベースを配置しており、RTTが短く、かつスタンバ イREDOログへのI/Oボトルネックもないような時は、11g R2のパラレル転送の仕組みによって 同期REDO転送待ちによるオーバーヘッドがほとんどない場合もあります。 (1) – (3) の3つの処理を最適化させるためのチューニング手法については、Oracle
Technology Network(OTN)より入手可能なホワイトペーパー 「Data Guard REDO転送とネッ トワークのベスト・プラクティス 」をご参照ください。
同期 / 非同期転送に関わらず、最新のデータをスタンバイ･データベースに保護し続けるには、 最低限 REDO生成量を上回るREDO転送ネ トワ クの帯域幅が必要です しかし 遠隔地 最低限、REDO生成量を上回るREDO転送ネットワークの帯域幅が必要です。しかし、遠隔地 へのREDO転送ネットワークを構成する場合、プライマリ – スタンバイ間の距離が離れ、確保す る帯域幅が広くなる程コストが高くなります。遠隔ネットワークは通信事業者からレンタルし、ラ ンニングコスト（月額×××万円等）になる場合も多く、システム全体のコストに大きな影響を及 ぼす可能性があります。このようにネットワークの帯域に関連する問題に対応するため、Data Guardでは転送時にREDOを圧縮する機能を提供します。11g R1 では、ギャップ解決と非同期 転送設定時（※）に圧縮機能を使用することが可能でしたが、11g R2 では同期転送を含む全 ての転送方式で圧縮機能を有効にすることが可能です。圧縮処理はREDO転送を担当する プ ライマリのNSS / NSAプロセスで実行され、伸張処理はスタンバイのRFSプロセスで実行され ライマリのNSS / NSAプロセスで実行され、伸張処理はスタンバイのRFSプロセスで実行され ます。圧縮 / 伸張 の処理によってCPUリソースが追加で消費されます。このオーバーヘッドは REDO転送量や圧縮率に依存します。
REDO圧縮機能の設定は 初期化パラメータ log_archive_dest_n 内の compression 属性で 指定します。
[設定例]
alter system set log_archive_dest_2='service=standby sync _ _ _ valid_for=(online_logfile,primary_role) db_unique_name=standby
compression=enable';
※11g R1 における非同期転送での圧縮設定については、My Oracle Support Note 729551.1 をご参照ください。
また11g R1にREDO圧縮については、 Oracle Technology Network (OTN)より入手可能なホ ワイトペーパー「ディザスタ･リカバリ構成におけるバッチ処理適用の検討」も合わせてご参照く ださい。
Mount状態プライマリ･データベースでALTER SYSTEM FLUSH REDOコマンドを実行すると、 カレントのオンラインREDOログを含む全ての未転送REDOがスタンバイ デ タベ スに転送 カレントのオンラインREDOログを含む全ての未転送REDOがスタンバイ・データベースに転送 されます。この機能によって、スタンバイ･データベースへのフェイルオーバーを実施する際にプ ライマリ･データベースがMount可能であれば、非同期REDO転送を設定している場合でも、デ ータロスのないフェイルオーバーが可能になります。 実行時のアラート･ログ･ファイル（プライマリ） ======
ALTER SYSTEM FLUSH REDO TO wonder CONFIRM APPLY [Process Id: ALTER SYSTEM FLUSH REDO TO wonder CONFIRM APPLY [Process Id: 8541] (stievie)
. .
Flush End-Of-Redo Log thread 1 sequence 36 has been fixed Flush Redo: Primary highest seen SCN set to 3837279:0 .
Flush End-Of-Redo Log thread 1 sequence 36 .
LOG_ARCHIVE_DEST_2 is a potential synchronized target LOG_ARCHIVE_DEST_2 has also applied all redo from primary
Active, synchronized target has been identified that has applied all the redo from the primary.
Flush Redo: Primary redo moved to standby
Flush Redo: Complete - Database shutdown required (stievie) ======
Database Filesystem（DBFS）は、Oracle Databaseの表領域をLinux OSからファイルシステ ムとしてマウントし アクセスすることを可能にする機能です DBFSを使用することで OSの ムとしてマウントし、アクセスすることを可能にする機能です。DBFSを使用することで、OSの cp コマンドでファイルをコピーし、エディタを使用してファイルを直接編集するような操作も可能です。 DBFSに配置されたデータは実際にはLOB(Secure Files)としてデータベース内に格納されま す。
DBFSによるファイルシステム・アクセスはLinux用の3rd partyソフトウェアである FUSEの機能 を内部的に使用して実現しています。そのため、DBFSを使用するためには、FUSEおよび Oracle DatabaseまたはOracleClientが導入されたLinux環境が必要です。
DBFSの詳細および導入手順については、マニュアル「SecureFiles and Large Objects Developer‘s Guide 11g Release 2 (11.2) 」をご参照ください。
DBFSを使用するメリットの一つとして、ファイルシステム領域に対して圧縮や暗号化などの O l D t b の機能を活用できるという点が上げられます D t G dと組み合わせれ Oracle Databaseの機能を活用できるという点が上げられます。Data Guardと組み合わせれ ば、Data Guardでファイルシステムのデータを保護することが可能になります。
Oracleデータ・ブロックの破損（論理破壊）は、OSやI/Oスタックなどの障害などによって起こりう
る現象です 破損ブロ クが表領域に配置された場合は ザ がそのブロ クにアクセスし
る現象です。破損ブロックが表領域に配置された場合は、ユーザーがそのブロックにアクセスし たときに初めて障害として検出されます。具体的にはSQL実行時にORA-1578エラーが返りま す。この現象を復旧するには、リストア / リカバリ、データの再ロード / インポートなどが必要に なります。Recovery Manager (RMAN)で取得したバックアップが存在すれば、オンラインでの ブロック・メディア・リカバリも可能です。また、スタンバイ･データベースが存在すれば、フェイル オーバーすることによる復旧が可能です。
11g R2 では、データブロックの破損を検出した場合、読み取り専用オープンでREDO適用が開 始されているフィジカル スタンバイ（A ti D t G d）が存在すれば フィジカル スタンバイ 始されているフィジカル･スタンバイ（Active Data Guard）が存在すれば、フィジカル･スタンバイ からプライマリ･データベースへ自動的に正常ブロックが転送され最新の状態までブロック・メデ ィア･リカバリが実行されます。この一連動作は発行されたSQLに対して透過的に起こるため、 SQLにエラーが返ることはありません。
[ 自動ブロック･メディア･リカバリ実行時のアラート･ログ･ファイルの出力 ]
=====
Hex dump of (file 7 block 261) in trace file Hex dump of (file 7, block 261) in trace file
/u01/app/oracle/diag/rdbms/stievie/stievie/trace/stievie_ora_6599 .trc
Corrupt block relative dba: 0x01c00105 (file 7, block 261) Completely zero block found during multiblock buffer read
Reading datafile '/u01/app/oracle/oradata/stievie/app01.dbf' for corruption at rdba: 0x01c00105 (file 7, block 261)
Reread (file 7, block 261) found same corrupt data Reread (file 7, block 261) found same corrupt data Starting background process ABMR
Thu Oct 15 11:19:38 2009
ABMR started with pid=44, OS id=6602 Auto BMR service is active.
Requesting Auto BMR for (file# 7, block# 261)
Waiting Auto BMR response for (file# 7, block# 261) Auto BMR successful
Active Data Guardによる自動ブロック･メディア･リカバリ以外にも、Oracle Databaseは様々な ブロ ク メディア リカバリ機能を提供しています 前述したとおり RMANでは手動でブロ ク ブロック･メディア･リカバリ機能を提供しています。前述したとおり、RMANでは手動でブロック･ メディア･リカバリを実行することが可能ですが、リストア元としては、RMANで取得したバックア ップだけでなく、フィジカル･スタンバイやFlashback Databaseまたは保証付きリストアポイント を設定時に生成されるフラッシュバック･ログも使用可能です。 ストレージ・レイヤでASMのミラーリングを使用している場合は、もしブロック破損がミラーの片 側のみであれば、SQLによるアクセス時に自動復旧されます。この場合もActive Data Guard 同様、エラーが返ることはありません。
[ RMANでの手動ブロック･メディア･リカバリ ]
======
RMAN> recover datafile 7 block 261;
recoverが開始されました(開始時間: 09-10-15)
リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=15 デバイス・タイプ=DISK スタンバイの検索が終了し、1ブロックをリストアしました メディア・リカバリを開始しています
メディア・リカバリが完了しました。経過時間: 00:00:01 ======
従来のフィジカル・スタンバイではプライマリ・データベースから転送されたREDOの適用中（ス ライド左上）は検索処理を行えず 検索処理を行う場合には REDO適用を停止する必要があ ライド左上）は検索処理を行えず、検索処理を行う場合には、REDO適用を停止する必要があ りました。ここでまず運用管理が複雑になるというデメリットがあります。 REDO適用を停止した状態（スライド左下）に注目すると、プライマリから転送されたREDOがた まっていくことになります。この時点でもし障害が発生すると、切り替え前にたまったREDOを全 て適用する必要があるため、ダウンタイムが長くなってしまいます。
Oracle Active Data Guard ではログ適用中のデータ参照が可能なので 複雑な運用管理やダ Oracle Active Data Guard ではログ適用中のデータ参照が可能なので、複雑な運用管理やダ ウンタイムが長くなるといったリスクを負うことなく、スタンバイを有効活用できます。
Active Data Guardではフィジカル･スタンバイは読み取り専用オープン状態であるため、基本 的には参照（SELECT文）の処理のみを行うことができます 但し 業務としては参照のみのア 的には参照（SELECT文）の処理のみを行うことができます。但し、業務としては参照のみのア プリケーションであっても、レポーティング・ツールにおけるメタデータの操作やフラグの更新な ど、データベースへの処理としてはごく一部に更新処理を含む可能性も考えられます。Active Data Guardではこのようなアプリケーションに対応するために、あらかじめプライマリ･データベ ースを参照するデータベース･リンクを作成し、フィジカル･スタンバイに対して更新処理（DML 文）が発行された場合はデータベース･リンク経由でプライマリ･データベースを更新する仕組み をベストプラクティスとして公開しています。この手順は Oracle Technology Network （OTN）よ り入手可能なホワイトペーパー「Oracle Active Data Guard Oracle Data Guard 11g Release 1 ホワイトペーパー 」より参照可能です。
1 ホワイト パ 」より参照可能です。
また、この手法を利用して、フィジカル･スタンバイをオラクル社のBusiness Intelligence（BI）ツ ールである、Business Intelligence Enterprise Edition（BIEE）のための環境として使用するた めの手順も公開されています。詳細はOTNより入手可能なホワイトペーパー「Oracle Active Data Guardを使用するためのOracle BI EE Serverの構成 ホワイトペーパー」をご参照くださ い。
Active Data Guardでは、スタンバイの活用方法によってはデータの鮮度（最新の状態であるか どうか）が非常に重要になります どうか）が非常に重要になります。 例えば、日次の集計バッチをスタンバイにオフロードするような使い方では、バッチ処理開始前 に日中業務の処理が全て反映されていることさえ確認できれば、比較的簡単に処理を適用でき ると考えられます。しかし、リアルタイム性の高いデータ分析の用途でスタンバイを使用する場 合、スタンバイにはプライマリの最新の更新データが確実に反映されていることを保証する必要 があります。Active Data Guardでは、プライマリ-スタンバイの間でのSCNの差（※）や、スタン バイ側で v$dataguard_statsビューを参照することで、プライマリとの時間差（適用ラグ）を確認 することができますが、これらの処理をアプリケーションに組み込むためには追加の工数が必 要になってしまいます。
※実行例（プライマリ・データベースで実行）
SELECT scn_to_timestamp((SELECT current_scn FROM V$DATABASE)) -scn_to_timestamp((SELECT current_scn FROM V$DATABASE@<db_link>)) FROM DUAL
11g R2より新たに提供されたセッション・パラメータ STANDBY_MAX_DATA_DELAYでは、プ ライマリとスタンバイの適用ラグの許容値を定め それ以上の適用ラグ発生した場合には エラ ライマリとスタンバイの適用ラグの許容値を定め、それ以上の適用ラグ発生した場合には、エラー を返すという設定を行うことが可能です。この機能はQuery SLAとも呼ばれます。 スライドに示したようなログオン･トリガーを作成することで、データベース・ユーザーに対して任意 の許容値を指定することが可能です。 11g R2のフィジカル･スタンバイでは、プライマリ - スタンバイ間の適用ラグをほぼリアルタイムで 確認可能な仕組みを提供しています 従来のリリースでは v$dataguard statsビューより確認可 確認可能な仕組みを提供しています。従来のリリースでは、v$dataguard_statsビューより確認可 能な適用ラグは60秒に1回の更新でしたが、11g R2では、v$dataguard_statsを検索したそのタ イミングで適用ラグを取得されます。Query SLAはこの仕組みを使用しています。 [11g R2での v$dataguard_stats検索例]
SQL> SELECT name, value, datum_time, time_computed 2 FROM V$DATAGUARD_STATS WHERE name like 'apply lag';
NAME VALUE DATUM TIME TIME COMPUTED
NAME VALUE DATUM_TIME TIME_COMPUTED
--- --- - ---apply lag +00 00:00:00 09/25/2009 13:14:11 09/25/2009 13:14:11
また、適用ラグの傾向を確認するためのv$standby_event_histogramビューも新たに提供 されています。
SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM 2 WHERE NAME = 'apply lag' AND COUNT > 0; NAME TIME UNIT COUNT LAST_TIME_UPDATED --- --- --- ---apply lag 0 seconds 48612 09/25/2009 13:20:02 apply lag 1 seconds 102 09/25/2009 13:15:09 apply lag 2 seconds 16 09/25/2009 12:20:58 apply lag 3 seconds 4 09/25/2009 11:15:56 apply lag 3 seconds 4 09/25/2009 11:15:56
それぞれのビューに関する詳細はマニュアル「Reference 11g Release 2 (11.2)」をご参照くだ さい。
ALTER SESSION SYNC WITH PRIMARY はプライマリとフィジカル･スタンバイを明示的に 同期し フ ジカル スタンバイから最新デ タを参照する際に使用します この マンドは同期 同期し、フィジカル･スタンバイから最新データを参照する際に使用します。このコマンドは同期 REDO転送設定時のみ指定可能です。コマンドの実行時に、もしもスタンバイREDOログに書き 込み済みで、適用されていないREDOがあった場合に適用を行います。
ロジカル・スタンバイでは、これまで制限によって使用できなかった複数の機能に 11g R2より新 たに対応しています
RMANはOracle Databaseに標準で付属するバックアップおよびリカバリのツールです。 RMANはスライドにあるように様々な機能を提供します
RMANはスライドにあるように様々な機能を提供します。
テープへのバックアップの取得にはOracle Secure Backupが使用可能です。Oracle Secure Backupでは、モジュールを追加することでAmazon S3にバックアップを保存することも可能で す。
スライドはRMANを使用した日次バックアップ運用の典型的なケースを示しています。 ・1日目 データベースの構築が完了したら、まずフルバックアップ（イメージコピー）を取得します。 ・2日目 2日目以降は増分バックアップを取得します。Oracle Database 10gより使用可能な高速増分 バックアップを使用すれば、バックアップサイズの節約だけでなく、バックアップ取得時間の短縮 が可能になります。これでフルバックアップに加え増分バックアップを1つ取得している状態にな ります。 ・3日目 1日目に取得したバックアップに2日目に取得した増分バックアップの内容を反映させます。この 機能を増分更新バックアップと言い、Oracle Database 10gから提供されている機能です。その 後、2日目同様に高速増分バックアップを取得します。これで、1日前のフルバックアップと当日 の増分バックアップを保持している状態になり 2日目と同じ状態になります の増分バックアップを保持している状態になり、2日目と同じ状態になります。 4日目以降は3日目と同じ操作を行い、必要に応じて再度フルバックアップを取得します。この運 用方法はOracle Enterprise Manager推奨バックアップ方式として事前定義されており、簡単に ジョブを作成することが可能です。 基本的に、フルバックアップを取得するタイミング以外は高速増分バックアップなので、高速な 縛アップ取得が可能です また 増分更新バックアップによって 保持しているバックアップが常 縛アップ取得が可能です。また、増分更新バックアップによって、保持しているバックアップが常 に同じ状態（フルバックアップ + 増分1つ）になります。このようにRMANだけでもバックアップ運 用をシンプルかつ効率的にすることが可能です。
・表領域Point-in-timeリカバリの機能拡張
表領域Point-in-timeリカバリは特定の表領域だけをある時点に戻す機能で、表領域レベルの 論理障害に対応します。11g R2では、表領域自体を削除した場合の復旧に対応します。 [ 削除された表領域のリカバリの実行例 ]
RMAN> run {
2> sql 'alter system archive log current';
3> recover tablespace 'TEST02' until scn 867420 auxiliary destination = '/u02/app/oracle/aux';
4> backup tablespace 'TEST02';
5> sql 'alter tablespace "TEST02" online'; 6> } ・データベース複製（Duplicate）の機能拡張 デ タベ スの複製機能には バックアップから複製する方法と起動中のデ タベ スから複 データベースの複製機能には、バックアップから複製する方法と起動中のデータベースから複 製する方法があります。従来のリリースではバックアップから複製する場合であっても、複製元 のデータベース（ターゲット・データベース）への接続が必要でしたが、11g R2より、リカバリ･カ タログへのアクセスが可能であれば、ターゲット・データベースへの接続が必須ではなくなりまし た。また、11g R2 では何らかの原因でDuplicateに失敗した場合、同じコマンドオプションでリト ライすると、コピー完了済みのデータファイルのリストアをスキップして再開することが可能にな りました。
11g R2では、RMANでのバックアップ取得時に設定可能な圧縮方式が追加され、全部で4つの 方式から選択できるようになりました 特に MEDIUMとLOWではサイズの節約だけでなく バ 方式から選択できるようになりました。特に、MEDIUMとLOWではサイズの節約だけでなく、バ ックアップ取得の高速化も期待できます。前述した高速増分バックアップ + 増分更新バックアッ プに加え、11g R2ではこれらの圧縮機能もバックアップ運用の効率化のポイントになる機能と いえます。
11g R2 ではデータベース・ロール（プライマリ / フィジカル･スタンバイ / スナップショット･スタン バイ / ロジカル スタンバイ）に紐付いたサ ビスの登録をO l Cl t に対して行うこと バイ / ロジカル･スタンバイ）に紐付いたサービスの登録をOracle Clusterwareに対して行うこと が可能です。また、インスタンス起動時にサービスも自動起動させるという設定も可能です。 ・ロールベースのサービスの作成例
srvctl add service -d <db_unique_name> -s <service_name> [-l [PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY]
[,SNAPSHOT_STANDBY]] [-y {AUTOMATIC | MANUAL}] [ y {AUTOMATIC | MANUAL}]
-l : ロールの指定
Client Failover はData Guard構成においてフェイルオーバーやスイッチーバーによるロール 変更が発生した場合に デ タベ スにアクセスするアプリケ シ ンからの接続もその変更に 変更が発生した場合に、データベースにアクセスするアプリケーションからの接続もその変更に 追従させる機能です。Client Failover を実現するための技術要素としては、以下が必要になり ます。 - Data Guardの切り替え（フェイルオーバー）を自動化する機能 - 新プライマリ･データベースでのサービスの自動起動 - フェイルオーバー完了をアプリケーション側に通知する機能 - アプリケーションから旧プライマリ･データベースへの無効なコネクションをクリーンアップ し 新プライマリに接続を切り替える機能 し、新プライマリに接続を切り替える機能
Client Failoverは、10g R2 以降のリリースであれば構成可能（※）ですが、11g R2 でその設 定方法がよりシンプルで簡単なものにな ています スライドの表で 11 R2 と従来のリリ ス 定方法がよりシンプルで簡単なものになっています。スライドの表で 11g R2 と従来のリリース を比較します。
※従来のリリースにおける Client Failover についての詳細はOracle Technology Networkよ り参照可能なホワイトペーパー「高可用性Oracle Databaseでのクライアント・フェイルオーバー のベスト・プラクティス」をご参照ください。
11g R2では、SCANを使用することにより、個別のデータベース･サーバーのIPアドレス等を意 識することなく RACデ タベ スへの接続の設定をすることが可能です SCANは D t 識することなく、RACデータベースへの接続の設定をすることが可能です。SCANは Data GuardのREDO転送でも使用可能です。
・設定例
ALTER SYSTEM SET
log_archive_dest_2='service="scan_dm1000_02:1521/osaka" async valid_for=(online_logfile,primary_role) db_unique_name=osaka';
REDO転送用にPrivate Networkを使用する場合、VIPの複数サブネット対応の機能強化を活 用できます この機能を使用することで REDO転送のネ トワ クがP bli でない場合も 用できます。この機能を使用することで、REDO転送のネットワークがPublicでない場合も、 Oracleリスナーのロードバランス機能（サーバー･サイド･ロード･バランシング）を使用できます。 これによってインスタンス障害時の迅速な接続切り替えが可能になります。
Data GuardのREDO転送におけるネットワークチューニングの考え方および手法については、 O l T h l N t k(OTN)より入手可能なホワイトペ パ 「D t G d REDO転 Oracle Technology Network(OTN)より入手可能なホワイトペーパー 「Data Guard REDO転 送とネットワークのベスト・プラクティス 」をご参照ください。
