Oracle Database 11g Release 2 高可用性とバックアップ（Data Guard Recovery Manager）

Size: px

Start display at page:

Download "Oracle Database 11g Release 2 高可用性とバックアップ（Data Guard Recovery Manager）"

さなえさだい
5 years ago
Views:

1 1

2 2

3 Oracle Database にはデータベース / アプリケーションの高可用性を実現するための様々な機能が実装されています本セッションではその中でも Oracle Data Guard と Oracle Recovery Manager の2つのコンポーネントについて 11g R2での機能拡張や変更点について説明します 3

4 一般的にデータベースの可用性を向上させるための方法としてはディスクの冗長化 (Oracle では ASM [Automatic ti Storage Management] を提供 ) による耐障害性の向上クラスタリング (OracleではRAC [Real Application Clusters] を提供 ) によるデータベースサーバーの対障害性向上そしてスタンバイデータベース (Oracleでは Oracle Data Guardを提供 ) によるデータベース全体の対障害性向上の3つが挙げられますスタンバイデータベースはデータベースを構成する全ての要素において本番データベースと切り離されるためより広範囲な障害にも対応可能です例えばスタンバイデータベースを本番データベースから遠隔地に配置することで地震や火災などのデータセンター全体に影響が及ぶ障害が発生した場合もデータベースの可用性を維持することができます Oracle Data Guard( 以降 Data Guard) は Oracle Databaseのスタンバイデータベース機能です本番データベース ( プライマリデータベースと呼びます ) のコピーとしてスタンバイデータベースを作成しそのメンテナンス管理および監視など一連の包括的なサービスを提供しますスタンバイデータベースはプライマリデータベースとトランザクション一貫性のあるコピーとして作成され作成後はプライマリデータベースから送信される REDO を適用することによってプライマリデータベースの変更に追従しますプライマリデータベースが計画的または計画外の停止によって使用不可能になった場合はスタンバイデータベースをプライマリデータベースに切り替えることで停止時間を最小限にできます Oracle Data Guard は Oracle Database Enterprise Edition が提供する機能ですスタンバイデータベースを導入する際の課題の一つとして通常運用時にスタンバイ側が遊休リソースになってしまう点が挙げられます Data Guard ではこの課題を解決するためにスタンバイ側を検索用途で使用可能にするロジカルスタンバイや Active Data Guard Option が提供されています 4

5 Data Guardにはフィジカルスタンバイとロジカルスタンバイの2 種類がありますそれぞれにスライドに記述された特徴があります 5

6 Oracle Database 11g Release 2 の Data Guardでは様々な機能拡張がされています以降はスライドの 3 点のポイントからそれぞれの機能拡張について説明します 6

7 7

8 Data Guard はOracle Database の更新ログであるREDOをスタンバイデータベースに転送することでデータを保護します Data Guard では即時性 ( 最新のデータを保護 ) 性能 ( アプリケーションに影響をあたえない ) コスト( 低コストなネットワーク構成 ) という観点でリリースを重ねるごとにREDO 転送関連の機能を強化してきました 11g R2 においても様々な機能拡張が行われています 8

9 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 ログの単位でそのギャップを自動解決します 9

10 スライドは非同期 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 k-bytes read (ry) by LNS ( ログバッファから転送されたREDOサイズ ) 10

11 スライドは同期 REDO 転送の仕組みを示しています 11g R2 では同期 REDO 転送の仕組みが変更されましたトランザクションのコミットが発生するとンのコミトが発生すると LGWR プロセスのオンライン REDO ログへのREDO 書き込みとNSSプロセスのREDO 転送が同時に発生しますスタンバイのRFSプロセスはスタンバイREDOログへのREDO 書き込みが完了したらプライマリ側に通知します全ての動作が完了するとトランザクションにレスポンスが返ります 11

12 スライドの図にあるように従来のリリースにおける同期 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 転送とネットワークのベストプラクティスをご参照ください 12

13 同期 / 非同期転送に関わらず最新のデータをスタンバイデータベースに保護し続けるには最低限 REDO 生成量を上回る REDO 転送ネットワークの帯域幅が必要ですしかし遠隔地へのREDO 転送ネットワークを構成する場合プライマリスタンバイ間の距離が離れ確保する帯域幅が広くなる程コストが高くなります遠隔ネットワークは通信事業者からレンタルしランニングコスト ( 月額万円等 ) になる場合も多くシステム全体のコストに大きな影響を及ぼす可能性がありますこのようにネットワークの帯域に関連する問題に対応するため Data Guardでは転送時にREDOを圧縮する機能を提供します 11g R1 ではギャップ解決と非同期転送設定時 ( ) に圧縮機能を使用することが可能でしたが 11g R2 では同期転送を含む全ての転送方式で圧縮機能を有効にすることが可能です圧縮処理はREDO 転送を担当するプライマリの 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 をご参照くださいまた11g R1にREDO 圧縮については Oracle Technology Network (OTN) より入手可能なホワイトペーパーディザスタリカバリ構成におけるバッチ処理適用の検討も合わせてご参照ください 13

14 Mount 状態プライマリデータベースでALTER SYSTEM FLUSH REDOコマンドを実行するとカレントのオンライン REDO ログを含む全ての未転送 REDO がスタンバイデータベースに転送タベスに転送されますこの機能によってスタンバイデータベースへのフェイルオーバーを実施する際にプライマリデータベースがMount 可能であれば非同期 REDO 転送を設定している場合でもデータロスのないフェイルオーバーが可能になります実行時のアラートログファイル ( プライマリ ) ====== 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 :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) ====== 14

15 Database Filesystem(DBFS) は Oracle Databaseの表領域をLinux 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) をご参照ください 15

16 DBFSを使用するメリットの一つとしてファイルシステム領域に対して圧縮や暗号化などの Oracle Database の機能を活用できるという点が上げられます Data Guard と組み合わせれば Data Guardでファイルシステムのデータを保護することが可能になります 16

17 17

18 18

19 Oracleデータブロックの破損 ( 論理破壊 ) は OSやI/Oスタックなどの障害などによって起こりうる現象です破損ブロックが表領域に配置された場合はユーザーがそのブロックにアクセスしがそのブロクにアクセスしたときに初めて障害として検出されます具体的にはSQL 実行時にORA-1578エラーが返りますこの現象を復旧するにはリストア / リカバリデータの再ロード / インポートなどが必要になります Recovery Manager (RMAN) で取得したバックアップが存在すればオンラインでのブロックメディアリカバリも可能ですまたスタンバイデータベースが存在すればフェイルオーバーすることによる復旧が可能です 19

20 11g R2 ではデータブロックの破損を検出した場合読み取り専用オープンでREDO 適用が開始されているフィジカルスタンバイ (Active Data Dt Guard) が存在すればフィジカルスタンバイからプライマリデータベースへ自動的に正常ブロックが転送され最新の状態までブロックメディアリカバリが実行されますこの一連動作は発行されたSQLに対して透過的に起こるため SQLにエラーが返ることはありません [ 自動ブロックメディアリカバリ実行時のアラートログファイルの出力 ] ===== 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 Starting background process ABMR Thu Oct 15 11:19: 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 ===== 20

21 Active Data Guardによる自動ブロックメディアリカバリ以外にも Oracle Databaseは様々なブロックメディアリカバリ機能を提供しています前述したとおり RMAN では手動でブロックメディアリカバリを実行することが可能ですがリストア元としては RMANで取得したバックアップだけでなくフィジカルスタンバイやFlashback Databaseまたは保証付きリストアポイントを設定時に生成されるフラッシュバックログも使用可能ですストレージレイヤで ASM のミラーリングを使用している場合はもしブロック破損がミラーの片側のみであれば SQL によるアクセス時に自動復旧されますこの場合も Active Data Guard 同様エラーが返ることはありません [ RMAN での手動ブロックメディアリカバリ ] ====== RMAN> recover datafile 7 block 261; recover が開始されました ( 開始時間 : ) リカバリカタログのかわりにターゲットデータベース制御ファイルを使用していますチャネル : ORA_DISK_1が割り当てられましたチャネルORA_DISK_1: SID=15 デバイスタイプ =DISK スタンバイの検索が終了し 1ブロックをリストアしましたメディアリカバリを開始していますメディアリカバリが完了しました経過時間 : 00:00:01 ====== 21

22 22

23 従来のフィジカルスタンバイではプライマリデータベースから転送されたREDOの適用中 ( スライド左上 ) は検索処理を行えず検索処理を行う場合には検索処理を行う場合には REDO 適用を停止する必要がありましたここでまず運用管理が複雑になるというデメリットがあります REDO 適用を停止した状態 ( スライド左下 ) に注目するとプライマリから転送された REDO がたまっていくことになりますこの時点でもし障害が発生すると切り替え前にたまった REDO を全て適用する必要があるためダウンタイムが長くなってしまいます Oracle Active Data Guard ではログ適用中のデータ参照が可能なので複雑な運用管理やダウンタイムが長くなるといったリスクを負うことなくスタンバイを有効活用できます 23

24 Active Data Guardではフィジカルスタンバイは読み取り専用オープン状態であるため基本的には参照 (SELECT 文 ) の処理のみを行うことができます但し業務としては参照のみのアプリケーションであってもレポーティングツールにおけるメタデータの操作やフラグの更新などデータベースへの処理としてはごく一部に更新処理を含む可能性も考えられます Active Data Guardではこのようなアプリケーションに対応するためにあらかじめプライマリデータベースを参照するデータベースリンクを作成しフィジカルスタンバイに対して更新処理 (DML 文 ) が発行された場合はデータベースリンク経由でプライマリデータベースを更新する仕組みをベストプラクティスとして公開していますこの手順は Oracle Technology Network (OTN) より入手可能なホワイトペーパー Oracle Active Data Guard Oracle Data Guard 11g Release 1 ホワイトペーパーより参照可能ですまたこの手法を利用してフィジカルスタンバイをオラクル社の Business Intelligence(BI) ツールである Business Intelligence Enterprise Edition(BIEE) のための環境として使用するための手順も公開されています詳細は OTN より入手可能なホワイトペーパー Oracle Active Data Guard を使用するための Oracle BI EE Server の構成ホワイトペーパーをご参照ください 24

25 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; 25

26 11g R2より新たに提供されたセッションパラメータ STANDBY_MAX_DATA_DELAYではプライマリとスタンバイの適用ラグの許容値を定めそれ以上の適用ラグ発生した場合にはエラーを返すという設定を行うことが可能ですこの機能はQuery SLAとも呼ばれますスライドに示したようなログオントリガーを作成することでデータベースユーザーに対して任意の許容値を指定することが可能です 11g R2のフィジカルスタンバイではプライマリ - スタンバイ間の適用ラグをほぼリアルタイムで確認可能な仕組みを提供しています従来のリリースでは 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 TIME_COMPUTED apply lag :00:00 09/25/ :14:11 09/25/ :14:11 (DATUM_TIME : 現時刻 TIME_COMPUTED : 適用ラグが計算された時間 ) 26

27 また適用ラグの傾向を確認するための 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 /25/ :20:02 apply lag 1 seconds /25/ :15:09 apply lag 2 seconds 16 09/25/ :20:58 apply lag 3 seconds 4 09/25/ :15:56 それぞれのビューに関する詳細はマニュアル Reference 11g Release 2 (11.2) をご参照ください 27

28 ALTER SESSION SYNC WITH PRIMARY はプライマリとフィジカルスタンバイを明示的に同期しフィジカルスタンバイから最新データを参照する際に使用しますこのコマンドは同期タを参照する際に使用します REDO 転送設定時のみ指定可能ですコマンドの実行時にもしもスタンバイREDOログに書き込み済みで適用されていないREDOがあった場合に適用を行います 28

29 ロジカルスタンバイではこれまで制限によって使用できなかった複数の機能に 11g R2より新たに対応しています 29

30 30

31 RMANはOracle Databaseに標準で付属するバックアップおよびリカバリのツールです RMAN はスライドにあるように様々な機能を提供しますテープへのバックアップの取得には Oracle Secure Backup が使用可能です Oracle Secure Backup ではモジュールを追加することで Amazon S3 にバックアップを保存することも可能です 31

32 スライドは RMAN を使用した日次バックアップ運用の典型的なケースを示しています 1 日目データベースの構築が完了したらまずフルバックアップ ( イメージコピー ) を取得します 2 日目 2 日目以降は増分バックアップを取得します Oracle Database 10gより使用可能な高速増分バックアップを使用すればバックアップサイズの節約だけでなくバックアップ取得時間の短縮が可能になりますこれでフルバックアップに加え増分バックアップを1つ取得している状態になります 3 日目 1 日目に取得したバックアップに2 日目に取得した増分バックアップの内容を反映させますこの機能を増分更新バックアップと言い Oracle Database 10gから提供されている機能ですその後 2 日目同様に高速増分バックアップを取得しますこれで 1 日前のフルバックアップと当日の増分バックアップを保持している状態になり 2 日目と同じ状態になります 4 日目以降は 3 日目と同じ操作を行い必要に応じて再度フルバックアップを取得しますこの運用方法は Oracle Enterprise Manager 推奨バックアップ方式として事前定義されており簡単にジョブを作成することが可能です基本的にフルバックアップを取得するタイミング以外は高速増分バックアップなので高速な縛アップ取得が可能ですまた増分更新バックアップによって保持しているバックアップが常に同じ状態 ( フルバックアップ + 増分 1つ ) になりますこのようにRMANだけでもバックアップ運用をシンプルかつ効率的にすることが可能です 32

33 33

34 表領域 Point-in-time リカバリの機能拡張表領域 Point-in-time リカバリは特定の表領域だけをある時点に戻す機能で表領域レベルの論理障害に対応します 11g R2 では表領域自体を削除した場合の復旧に対応します [ 削除された表領域のリカバリの実行例 ] RMAN> run { 2> sql 'alter system archive log current'; 3> recover tablespace 'TEST02' until scn auxiliary destination = '/u02/app/oracle/aux'; 4> backup tablespace 'TEST02'; 5> sql 'alter tablespace "TEST02" online'; 6> } データベース複製 (Duplicate) の機能拡張データベースの複製機能にはバックアップから複製する方法と起動中のデータベースから複スから複製する方法があります従来のリリースではバックアップから複製する場合であっても複製元のデータベース ( ターゲットデータベース ) への接続が必要でしたが 11g R2よりリカバリカタログへのアクセスが可能であればターゲットデータベースへの接続が必須ではなくなりましたまた 11g R2 では何らかの原因でDuplicateに失敗した場合同じコマンドオプションでリトライするとコピー完了済みのデータファイルのリストアをスキップして再開することが可能になりました 34

35 11g R2では RMANでのバックアップ取得時に設定可能な圧縮方式が追加され全部で4つの方式から選択できるようになりました特に MEDIUM と LOW ではサイズの節約だけでなくバックアップ取得の高速化も期待できます前述した高速増分バックアップ + 増分更新バックアップに加え 11g R2ではこれらの圧縮機能もバックアップ運用の効率化のポイントになる機能といえます 35

36 36

37 11g R2 ではデータベースロール ( プライマリ / フィジカルスタンバイ / スナップショットスタンバイ / ロジカルスタンバイ ) に紐付いたサービスの登録を Oracle Clusterware に対して行うことが可能ですまたインスタンス起動時にサービスも自動起動させるという設定も可能ですロールベースのサービスの作成例 srvctl add service -d <db_unique_name> -s <service_name> [-l [PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY] [,SNAPSHOT_STANDBY]] [-y {AUTOMATIC MANUAL}] -l : ロールの指定 -y : 起動方法の指定 ( 自動 or 手動 ) 37

38 Client Failover はData Guard 構成においてフェイルオーバーやスイッチーバーによるロール変更が発生した場合にデータベースにアクセスするアプリケーションからの接続もその変更に追従させる機能です Client Failover を実現するための技術要素としては以下が必要になります - Data Guardの切り替え ( フェイルオーバー ) を自動化する機能 - 新プライマリデータベースでのサービスの自動起動 - フェイルオーバー完了をアプリケーション側に通知する機能 - アプリケーションから旧プライマリデータベースへの無効なコネクションをクリーンアップし新プライマリに接続を切り替える機能 38

39 Client Failoverは 10g R2 以降のリリースであれば構成可能 ( ) ですが 11g R2 でその設定方法がよりシンプルで簡単なものになっていますスライドの表で 11g R2 と従来のリリースを比較します従来のリリースにおける Client Failover についての詳細は Oracle Technology Network より参照可能なホワイトペーパー高可用性 Oracle Database でのクライアントフェイルオーバーのベストプラクティスをご参照ください 39

40 11g R2では SCANを使用することにより個別のデータベースサーバーのIPアドレス等を意識することなく 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'; 40

41 REDO 転送用にPrivate Networkを使用する場合 VIPの複数サブネット対応の機能強化を活用できますこの機能を使用することで REDO 転送のネットワークが Public でない場合も Oracleリスナーのロードバランス機能 ( サーバーサイドロードバランシング ) を使用できますこれによってインスタンス障害時の迅速な接続切り替えが可能になります 41

42 Data GuardのREDO 転送におけるネットワークチューニングの考え方および手法については Oracle Technology Network(OTN) より入手可能なホワイトペーパー Data Guard REDO 転送とネットワークのベストプラクティスをご参照ください 42

43 43

44 44

第 3 章メディア障害とバックアップリカバリこの章ではメディア障害の発生に備えたバックアップ方法と障害時の基本的なリカバリ方法について説明します 1. メディアリカバリ概要 2. ファイルの多重化 3. アーカイブモードの設定 4. バックアップ概要 5. 一貫性バックアップ ( オ

第 3 章メディア障害とバックアップリカバリこの章ではメディア障害の発生に備えたバックアップ方法と障害時の基本的なリカバリ方法について説明します 1. メディアリカバリ概要 2. ファイルの多重化 3. アーカイブモードの設定 4. バックアップ概要 5. 一貫性バックアップ ( オはじめにコース概要と目的データベースのバックアップの取得方法障害発生時のリカバリ方法について習得します受講対象者データベース管理者の方前提条件データベースアーキテクチャおよびデータベースマネジメントコースを受講された方または同等の知識をお持ちの方テキスト内の記述について構文 [ ] 省略可能 { A B } A または B のどちらかを選択 n _ 数値の指定デフォルト値