Oracle Database 10gにおけるOracle Data GuardでのRecovery Managerの使用

Transcription

1 Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 オラクル ホワイト ペーパー 2005 年 9 月

2 Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 概要... 3 はじめに... 4 セットアップの前提条件... 5 構成設定と注意事項... 7 Oracle データベースの推奨構成... 7 RMAN の推奨設定... 9 バックアップ手順 ケース 1: ディスクをテープ バックアップのキャッシュとして使用する プライマリ データベース バックアップ手順 スタンバイ データベース バックアップ手順 ケース 2: テープにバックアップを直接書き込む プライマリ データベース バックアップ手順 スタンバイ データベース バックアップ手順 アーカイブ ログ管理 リカバリ手順 スタンバイ データベース上での消失データファイルのリカバリ プライマリ データベース上での消失データファイルのリカバリ スタンバイ データベース上での消失制御ファイルのリカバリ プライマリ データベース上での消失制御ファイルのリカバリ スタンバイ データベースへのフェイルオーバー 新しい制御ファイルの作成 バックアップ制御ファイルを使用したリカバリ 消失したオンライン ログのリカバリ データベースのブロック メディア リカバリ データベースの不完全リカバリ スイッチオーバー / フェイルオーバー後の手順や構成の変更点 アーカイブ ログ バックアップの注意事項 RMAN によるスタンバイ データベースのインスタンス化 RMAN によりスタンバイ データベースをインスタンス化する代替方法 結論 参照資料 付録 発信元ホストで取ったバックアップが使用できない場合 アーカイブ ログ リポジトリとして構成されたスタンバイ データベース スタンバイ データベース ファイル名がプライマリ データベースと異なる場合 Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 2

3 Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 概要 高可用性の全般的な方針には 十分な裏付けのある実証済システムおよびソフトウェア リカバリ計画が不可欠です Oracle Data Guard の使用により Oracle DBA はストレージ サブシステムの故障 サイト全体の障害 災害などの場合でも連続稼働を提供します Data Guard は 管理 監視 自動化のためのソフトウェア インフラストラクチャで 1 つ以上のスタンバイ データベースを作成 メンテナンスおよび監視して 企業データを故障 災害 エラー 破損などから保護します 同様に DBA は Oracle Recovery Manager(RMAN) を使用して 制御ファイル データファイル アーカイブ ログ ファイルをディスクやテープにバックアップする一方 ファイル システムやメディアが消失した場合 これらのファイルを効率的にリカバリできます RMAN は データベース バックアップおよびリカバリを行う Oracle のユーティリティです 本番データベースへの影響を最小限に抑えながら すべてのデータをバックアップし 個々のファイルでもデータベース全体でも その消失を迅速にリカバリします Oracle Database 10g では RMAN は Data Guard 構成に対して次のような新機能を提供します フラッシュ リカバリ領域 バックアップやアーカイブ ログなどのデータベース リカバリ関係のファイルを編成および管理する単一のファイル システム または Automatic Storage Management(ASM) ディスク グループ スタンバイ データベース サーバー固有の永続構成 チャネル デバイス バックアップ最適化 制御ファイル自動バックアップ設定などを含みます プライマリおよびスタンバイ データベース サーバー固有の構成 リモート スタンバイ宛先に適用されたアーカイブ ログを自動削除できます アーカイブ ログの自動削除 新しいファイルに対してフラッシュ リカバリ領域でスペースが必要な場合に実行されます このホワイト ペーパーでは Oracle Database 10g 環境で Data Guard が管理するフィジカル スタンバイ データベースをセットアップおよびバックアップする RMAN 手順を概説します プライマリ データベースのリカバリには フィジカル スタンバイ データベースからのバックアップのみが使用可能です 概説する手順は次のとおりです プライマリ データベースおよびスタンバイ データベースで RMAN 永続設定を構成 Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 3

4 プライマリ データベースまたはスタンバイ データベースのリカバリに使用できるスタンバイ データベースで データベース バックアップを作成 スタンバイ データベースで作成されたバックアップを使用して プライマリ データベースまたはスタンバイ データベースでデータファイルをリカバリこのホワイト ペーパーでは Data Guard 構成でバックアップを管理する RMAN 手順に関心のある DBA IT システム管理者を対象としています Data Guard および RMAN の概念と手順を理解していることを前提とします 注意 : Oracle9i Database 構成でのRMAN 手順については Using Recovery Manager (RMAN) with Oracle Data Guard in Oracle9i [1] を参照してください はじめに Data Guard は Oracle データベースが身近にあっても遠く離れていても 障害時リカバリ ソリューションの管理を可能にし 自動化します Data Guard は 本番データベース ( プライマリ データベースとも呼ばれる ) と 本番データベースのトランザクション一貫性コピーである 1 つ以上のスタンバイ データベースで構成されます プライマリ データベースでトランザクションが発生すると REDO データが生成され ローカル REDO ログに書き込まれます Data Guard は この REDO データをスタンバイ サイトに自動的に転送し スタンバイ データベースに適用してプライマリ データベースと同期させます RMAN は Oracle データベースと統合されたツールで 高いパフォーマンスと管理性を備えたバックアップおよびリカバリの需要に応えます RMAN は サーバーと緊密に連動するように設計されており バックアップとリストアの実行中にブロック レベルの破損を検出します RMAN は ファイル多重化と圧縮により バックアップ中のパフォーマンスと領域消費量を最適化します また 付属の Media Management Library(MML)API により最新のバックアップ ソフトウェア システムでも動作します RMAN は オンライン バックアップ 増分バックアップ ブロック メディア リカバリ バックアップ管理タスクの自動化 サード パーティ メディア管理システムの Data Guard 構成への統合など 豊富な機能を備えています RMAN と Data Guard は 統合された Oracle 高可用性テクノロジ群の一部として RMAN バックアップをフィジカル スタンバイ データベースにシームレスにオフロードできるため 障害時リカバリ投資の価値が一層高まります バックアップは 通常の Data Guard 処理に影響を与えません スタンバイ データベースがリカバリ モードまたは読取り専用モードのときにバックアップすることができます バックアップは プライマリ データベース サーバーまたはスタンバイ データベース サーバーのリカバリにも使用できます Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 4

5 クライアント クライアント プライマリ サイト スタンバイ サイト データ変換 プライマリ データベース Data Guard ブローカ スタンバイ データベース RMAN バックアップ カタログ サーバー RMAN バックアップ フラッシュ リカバリ領域 RMAN カタログ バックアップ フラッシュ リカバリ領域 テープ 図 1: Data Guard と RMAN の構成 Data Guard と RMAN は いずれも Oracle データベース アーキテクチャを念頭に置いて設計されました この 2 つが一緒になって 非常に信頼性が高く緊密に統合されたソリューションを提供し ミッション クリティカルなアプリケーションをサポートする高レベルの Oracle データベース可用性を達成します Data Guard と RMAN は いずれも Oracle Database Enterprise Edition の機能を完全にサポートします (RMAN は Oracle Database Standard Edition でも提供されています ) 後述のセクションでは 次について説明します RMAN と Data Guard の構成設定 プライマリおよびスタンバイをディスクとテープにバックアップする手順 プライマリとスタンバイでのリカバリ シナリオ スタンバイ データベースの RMAN ベースのインストール セットアップの前提条件 このセットアップの前提条件は次のとおりです スタンバイ データベースはフィジカル スタンバイ データベースであり スタンバイ データベースでのみバックアップが実行されます プライマリ データベースとスタンバイ データベースの両方でバックアップを行う場合 手順の変更については 付録 を参照してください Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 5

6 プライマリ データベースとスタンバイ データベースのディレクトリ構造は同じです そのため 使用しているホストに関係なく RMAN バックアップとリカバリの処理が簡素化されます あるデータベース サーバーで取られたバックアップを他のデータベース サーバーにリストアするためには RMAN リカバリ カタログが必要です プライマリ データベースはスタンバイ データベースで行われたバックアップに関する情報を持っていないため RMAN リポジトリとして制御ファイルを使用するだけでは不十分です RMAN リカバリ カタログは バックアップ履歴や他のリカバリ関係のメタデータを一元管理します リカバリ カタログはデータベース内に構成され バックアップ メタデータをメンテナンスします リカバリ カタログには制御ファイルの領域制限がないため バックアップに関する大量の履歴データを保管できます Data Guard 構成では カタログ サーバーをプライマリ サイトやスタンバイ サイトから物理的に独立させ いずれかのサイトで障害が発生した場合でも最新のバックアップのリカバリに影響が及ばないようにすることをお薦めします 構成におけるすべてのデータベースで Oracle Database 10g Release 1 を使用します プライマリ データベースはOracle Managed Files(OMF) を使用しません OMFを使用すると スタンバイ データベース ファイル名がプライマリでのファイル名と異なることがあります そのリストア手順の変更については 付録 を参照してください サード パーティ メディア管理ソフトウェアでは RMAN がテープにバックアップを作成するように構成されます 注意 : 付録 では 次の 3 つの代替構成における変更点を説明しています 発信元ホストからバックアップにアクセスできないために バックアップがプライマリおよびスタンバイ両方のデータベース サイトで作成される場合 スタンバイ データベースがアーカイブ ログ リポジトリとして構成される場合 スタンバイ データベース ファイル名がプライマリでのファイル名と異なる場合 Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 6

7 構成設定と注意事項 Data Guard 構成では データファイルとアーカイブ ログをバックアップするプロセスをスタンバイ システムにオフロードし 本番システムに対するバックアップ処理の影響を最小限にできます これらのバックアップは プライマリ データベースまたはスタンバイ データベースのリカバリに使用できます RMAN と Oracle データベースに対して次の設定をすると バックアップとリカバリの処理が簡単になります これらの設定は データファイルとアーカイブ ログのバックアップをスタンバイ データベース サーバーの 1 つで行うことを前提としています Oracle データベースの推奨構成プライマリ データベースおよびスタンバイ データベースでは 次のようにします フラッシュ リカバリ領域を構成します フラッシュ リカバリ領域は ファイル システム上の単一のストレージ場所または Automatic Storage Management(ASM) ディスク グループであり リカバリに必要なすべてのファイルが置かれます これらのファイルには 制御ファイル アーカイブ ログ オンライン ログ コピー フラッシュバック ログ RMAN バックアップが含まれます 新しいバックアップとアーカイブ ログがフラッシュ リカバリ領域で作成されるとき 古いファイル ( 保存期間を経過したもの または第 3 のストレージにバックアップされたもの ) は自動的に削除され 新しいファイルに対してスペースが割かれます また フラッシュ リカバリ領域のスペース消費量が事前定義された限界に近づいた場合 DBA にアラートを発行する通知機能をセットアップできるため DBA はリカバリ領域スペース制限の増加 ディスク ハードウェアの増設 保存期間の短縮などの対応策を取ることができます 次の init.ora パラメータを設定して フラッシュ リカバリ領域を構成します DB_RECOVERY_FILE_DEST = <mount point or ASM Disk Group> DB_RECOVERY_FILE_DEST_SIZE = <disk space quota> システム パラメータ ファイル (SPFILE) を使用して Data Guard 構成で任意のデータベースを使用できるようにします これにより 別のデータベースで取ったバックアップから SPFILE をリストアできます プライマリ データベースおよびスタンバイ データベースでFlashback Databaseを有効にします Flashback Databaseが有効の場合 Oracleはフラッシュ リカバリ領域でフラッシュバック ログを管理します このログの使用により 完全なリストアを実行しなくても データベースを過去のある時点まで 巻戻し できます 詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド の Oracle Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 7

8 Flashback Database: Point-in-Time リカバリの代替方法 [2] を参照してくだ さい Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 8

9 RMAN の推奨設定 次の CONFIGURE コマンドは プライマリ データベースとリカバリ カタログ の接続後に発行する必要があります CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <n> DAYS このコマンドは プライマリ データベース制御ファイルを更新後 ただちにカタログに記録されます カタログに接続されると スタンバイ データベースはこの保存期間ポリシーを使用します スタンバイ制御ファイルには一部のプライマリ制御ファイルのレコードを含むため このコマンドは必ずプライマリ データベースでのみ実行します スタンバイ データベース上のすべてのバックアップ ファイルとアーカイブ ログは 少なくとも <n> 日間保存されます フラッシュ リカバリ領域は 新しいファイル用のスペースを再生するため 期限切れのファイルやテープにバックアップしたファイルを必要に応じて自動的に削除します CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY この構成をプライマリ データベースで設定することにより プライマリ データベース上にあり リモート スタンバイ宛先に適用されたアーカイブ ログを自動削除できます この構成はデフォルトで 1 つ以上のリモート宛先の設定が必須です 注意 : スタンバイ宛先に到達できない場合 必須スタンバイ宛先がプライマリ データベースに影響することがあります 必須スタンバイ宛先を使用せずにこの機能を有効にするには Metalink Note (RMAN backups in Max Performance/Max Availability Data Guard Environment) を参照してください CONFIGURE CONTROLFILE AUTOBACKUP ON 制御ファイルと SPFILE の自動バックアップを有効にします CONFIGURE CHANNEL DEVICE TYPE SBT PARMS <channel parameters> メディア管理ソフトウェアに必要なチャネル パラメータをセットアップします バックアップが行われるスタンバイ データベース サーバーとリカバリ カタログに接続後 次のコマンドを発行する必要があります CONFIGURE CONTROLFILE AUTOBACKUP ON 制御ファイルとSPFILEの自動バックアップを有効にします バックアップはフラッシュ リカバリ領域に書き込まれます CONFIGURE BACKUP OPTIMIZATION ON 保存期間内の有効なバックアップが存在するデータベース ファイルについては バックアップをスキップします Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 9

10 CONFIGURE CHANNEL DEVICE TYPE SBT PARMS <channel parameters> メディア管理ソフトウェアに必要なチャネル パラメータをセットアップします CONFIGURE ARCHIVELOG DELETION POLICY TO NONE 新しいバックアップまたはアーカイブ ログに対して追加スペースが必要な場合 スタンバイ データベース ( バックアップが取られるデータベース ) 上にあり 保存期間の過ぎたアーカイブ ログまたはテープにバックアップされたアーカイブ ログの自動削除を有効にします その他のスタンバイ データベース サーバーとリカバリ カタログに接続後 次のコマンドを発行する必要があります CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY この構成を他の各スタンバイ データベース ( バックアップを取らないデータベース ) で設定することにより このスタンバイ データベース上にあり 他のすべてのリモート スタンバイ宛先に適用されたアーカイブ ログの自動削除が有効になります この構成はデフォルトで 1つ以上のリモート宛先の設定が必須です 新しいファイルのためにフラッシュ リカバリ領域でスペース再生が必要な場合 アーカイブ ログが削除されます 注意 : スタンバイ宛先に到達できない場合 必須スタンバイ宛先がプライマリ データベースに影響することがあります 必須スタンバイ宛先を使用せずにこの機能を有効にするには Metalink Note (RMAN backups in Max Performance/Max Availability Data Guard Environment) を参照してください スイッチオーバーまたはフェイルオーバーが発生した場合 データベース ロールが変わるため 適切なCONFIGUREコマンドを新しいプライマリ データベースおよびスタンバイ データベースで再実行する必要があります その他の変更については スイッチオーバー / フェイルオーバー後の手順や構成の変更点 を参照してください バックアップ手順 このセクションでは Data Guard 構成で Oracle データベースをバックアップする RMAN スクリプトと手順を詳しく説明します オラクル社のMaximum Availability Architecture(MAA) ベスト プラクティスでは 二重停止の場合のMTTR( 平均リカバリ時間 ) を減少させ スイッチオーバー / フェイルオーバー後の新サイトでの作業を避けるため プライマリ データベースとスタンバイ データベースの両方でバックアップを取ることをお薦めしています その場合の一般的手順の変更については 付録 を参照してください Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 10

11 ケース 1: ディスクをテープ バックアップのキャッシュとして使用する このシナリオでは スタンバイ データベースのフラッシュ リカバリ領域をテープ バックアップのためのディスク キャッシュとして使用します ディスクは テープが提供する長期のアーカイブ ストレージとともに バックアップのためのプライマリ ストレージとして使用されます 完全バックアップは毎週 増分バックアップは毎日実行されます プライマリ データベース バックアップ手順プライマリ データベース制御ファイルと SPFILE の自動バックアップは ( ターゲット データベースとしてプライマリ データベース ) とリカバリ カタログに接続後 次の RMAN コマンドを使用してテープにバックアップする必要があります BACKUP DEVICE TYPE SBT BACKUPSET ALL; このコマンドの実行時 既存のディスク バックアップは ( バックアップ計画から ) テープに置かれます このバックアップの実行頻度はリカバリ期間により決まります リカバリ時には 古いバックアップ制御ファイルより新しいバックアップ制御ファイルの方が 最新状態に保つために必要な REDO 適用回数が少ないため 所要時間も短くなります プライマリ データベース制御ファイルは 少なくとも週に 1 回テープにバックアップすることをお薦めします スタンバイ データベース バックアップ手順日次バックアップ スクリプトお薦めするバックアップ方針は Oracle 推奨方針 で 増分的に更新されるバックアップの利点を活用します この機能により データファイルのイメージ コピーを最新の増分バックアップを使用してロール フォワードできるため 常にデータファイルの最新のイメージ コピーが提供されます RMAN は 結果のイメージ コピーを その SCN で取得された完全イメージ コピーを使用しているかのようにメディア リカバリに使用します これにより データベースの完全イメージ コピーを毎日実行するオーバーヘッドを回避できます このイメージ コピーは最新のブロック変更で更新され 必要最小限の REDO ログでデータベースを最新状態に戻せるため リカバリ時間も短縮されます Oracle 推奨方針 では 完全データベース バックアップは初日のみ実行され 2 日目は増分バックアップが行われます アーカイブされた REDO ログを使用して 任意の日の任意の時点にデータベースをリカバリできます 3 日目以降は 前日の増分バックアップがデータファイル コピーとマージされ 最新の増分バックアップが取られるため 過去の任意の時点に高速でリカバリでき また REDO ログを使用して当日の任意の時点にデータベースをリカバリできます ( ターゲット データベースとして ) スタンバイ データベースとリカバリ カタログに接続後 次のコマンドを実行できます Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 11

12 1. RECOVER COPY OF DATABASE WITH TAG OSS ; 前日に取られたレベル 1 の増分を適用することにより データベースのレベル 0 コピーをロール フォワードします 次のスクリプト例では 前日のレベル 1 の増分に OSS というタグを付けました この増分は 手順 2 で BACKUP コマンドにより生成されます スクリプトを最初に実行する日には レベル 1 の増分がないため ロール フォワードはありません 手順 2 でレベル 0 の増分が作成されます 2 日目もレベル 0 の増分のみであるため ロール フォワードはありません OSS というタグを付けたレベル 1 の増分が手順 2 で作成されます 3 日目以降は 前日に作成された OSS というタグの付いたレベル 1 の増分を使用して ロール フォワードされます 2. BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG OSS DATABASE; レベル 1 の新しい増分を作成します スクリプトを最初に実行する日は レベル 0 の増分です 2 日目以降はレベル 1 の増分になります 3. BACKUP ARCHIVELOG ALL NOT BACKED UP TO SBT; BACKUP BACKUPSET ALL; このスクリプトを最初に実行する日は このコマンドの実行時に既存のディスク バックアップが ( バックアップ計画から ) テープに置かれます 翌日からは リカバリ領域のアーカイブ ログと増分バックアップがテープにバックアップされます 完全なコマンド シーケンスは次のとおりです RECOVER COPY OF DATABASE WITH TAG OSS ; BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG OSS DATABASE; BACKUP ARCHIVELOG ALL NOT BACKED UP TO SBT; BACKUP BACKUPSET ALL; 制御ファイル自動バックアップが有効なため バックアップ処理の最後にスタンバイ制御ファイルが自動的にバックアップされます 週次バックアップ スクリプト ディスク上のすべてのリカバリ領域ファイルは 次のコマンドにより週に 1 回テープにバックアップされます BACKUP RECOVERY FILES; Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 12

13 これにより ディスク上のすべての最新の増分バックアップ イメージ コピー バックアップおよびアーカイブ ログ バックアップがテープにバックアップされます ケース 2: テープにバックアップを直接書き込む ( ターゲット データベースとして ) スタンバイ データベース サーバーとリカバリ カタログに接続後 次の RMAN コマンドによりデフォルト デバイス タイプをテープに設定します CONFIGURE DEFAULT DEVICE TYPE TO SBT; このシナリオでは スタンバイ データベースで 完全バックアップは毎週 増分バックアップは毎日実行されます プライマリ データベース バックアップ手順 ( ターゲット データベースとして ) プライマリ データベースとリカバリ カタログに接続後 次の RMAN コマンドを使用して 制御ファイルと SPFILE 自動バックアップをテープにバックアップします BACKUP BACKUPSET ALL; このバックアップの頻度は 制御ファイル バックアップが実行される頻度 古いバックアップ制御ファイルの使用が必要な場合に REDO が失われる危険性などのリカバリ要件によって決まります プライマリ データベース制御ファイルは 少なくとも週に 1 回テープにバックアップすることをお薦めします スタンバイ データベース バックアップ手順日次バックアップ スクリプト ( ターゲット データベースとして ) スタンバイ データベースとリカバリ カタログに接続後 次のコマンドを実行します すべてのアーカイブ ログを含めて データベースのレベル 1 の増分バックアップを作成します これを最初に実行する日にはレベル 0 のバックアップがないため レベル 0 バックアップが作成されます BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG; 制御ファイル自動バックアップが有効であるため バックアップ処理の最後にスタンバイ制御ファイルが自動的にバックアップされます Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 13

14 週次バックアップ スクリプト ( ターゲット データベースとして ) 週に 1 回 スタンバイ データベースとリカバリ カタログに接続後 次の RMAN コマンドを実行します すべてのアーカイブ ログを含め レベル 0 のデータベース バックアップを作成します BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG; アーカイブ ログ管理 いずれのスタンバイ サーバーでも自動アーカイブ ログ削除が構成されていない場合 ( または NONE に設定されている場合 ) BACKED UP <n> TIMES TO DEVICE TYPE SBT オプションを付けた RMAN DELETE コマンドを使用することにより 少なくとも <n> 個のコピーがテープにバックアップされたアーカイブ ログを明示的に削除できます BACKED UP オプションを使用すると アーカイブ ログの削除前にバックアップが存在することを確実にします 新しいファイルのためにフラッシュ リカバリ領域のディスク領域がさらに必要な場合 フラッシュ リカバリ領域は保存期間の過ぎたアーカイブ ログ またはテープにバックアップされたアーカイブ ログを自動的に削除します DELETE コマンドは 追加スペースをただちに再生することが必要な場合に便利です たとえば 次に示すコマンドは 7 日以上前に生成されたアーカイブ ログと 少なくとも 2 個のバックアップ コピーがテープにあるアーカイブ ログをすべて削除します DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO SBT COMPLETED BEFORE SYSDATE-7 ; リカバリ手順 次のリカバリ スクリプトでは プライマリ ホストとスタンバイ ホストが同一のディレクトリ パス名を持つものとします パス名が異なる場合 必要な構文については スタンバイ データベース ファイル名がプライマリ データベースと異なる場合 を参照してください スタンバイ データベース上での消失したデータファイルのリカバリ管理されたリカバリ プロセス (MRP: managed recovery process) は アーカイブ REDO ログからの情報をスタンバイ データベースに適用します Real Time Apply が有効な場合 MRP はスタンバイ REDO ログから直接適用します スタンバイ データベースでデータファイルをリストアおよびリカバリする場合 MRP を行うディスク上でアーカイブ ログを使用できることが重要です スタンバイ データベースとリカバリ カタログ データベースの両方に接続する必要があります スタンバイ データベース データファイルのリカバリには 次の手順が必要です Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 14

15 1. MRP を停止します 2. スタンバイ データベースの現在の SCN を調べます SQL> SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY WHERE RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE# FROM V$DATABASE); UNTIL_SCN RMAN を使用してデータファイルをリストアします RESTORE DATAFILE <n,m...>; # ここで n, m はデータファイルの番号または名前 4. スタンバイ データベースの現在の SCN まで RMAN を使用してデータファイルをリカバリします アーカイブ ログがディスクにない場合 RMAN はバックアップから自動的にアーカイブ ログをリストアしてリストア データファイルに適用します RECOVER DATABASE UNTIL SCN ; 5. MRP を再起動します プライマリ データベース上での消失したデータファイルのリカバリプライマリ データベースのデータファイルをリストアおよびリカバリするには 次の RMAN コマンドを実行します ( ターゲット データベースとして ) プライマリ データベースxとリカバリ カタログに接続する必要があります これらのスクリプトでは リカバリされるデータファイルがオフラインであると仮定しています RESTORE DATAFILE <n,m...>; # ここで n, m はデータファイルの番号または名前 RECOVER DATAFILE <n,m...>; Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 15

16 プライマリ データベースで表領域をリストアおよびリカバリするには 次の RMAN コマンドを実行します ターゲット データベースとして ) プライマリ データベース ( とリカバリ カタログに接続する必要があります RESTORE TABLESPACE <tbs_name1, tbs_name2,...> RECOVER TABLESPACE <tbs_name1, tbs_name2,...> スタンバイ データベース上での消失した制御ファイルのリカバリ 1 つの制御ファイルが消失した場合 Oracle では スタンバイ制御ファイルを多重化することができます スタンバイ制御ファイルが多重化されているか確認するには 次の SQL を使用して CONTROL_FILES 初期化パラメータをチェックします SHOW PARAMETER CONTROL_FILES NAME TYPE VALUE control_files string <cfilepath1>,<cfilepath2> 多重化されたスタンバイ制御ファイルの 1 つが消失した場合 またはアクセス不能な場合 Oracle はそのインスタンスを停止し 次のメッセージをアラート ログに書き込みます ORA-00210: cannot open the specified controlfile ORA-00202: controlfile: '/../oracle/dbs/scf3_2.f' ORA-27041: unable to open file 1 つの制御ファイルの消失をリカバリするには 次のようにします 他の制御ファイルの 1 つを 破損または消失した位置のディレクトリ (CONTROL_FILES 初期化パラメータにより指定される ) にコピーします 使用可能な制御ファイルのみを使用するようにCONTROL_FILES 初期化パラメータを編集し スタンバイ データベースを再起動します 詳細は Oracle Data Guard 概要および管理 でスタンバイ データベースの再起動手順 [3] を参照してください すべてのスタンバイ データベース制御ファイルが消失した場合すべてのスタンバイ制御ファイルが消失した場合 RMAN を使用してスタンバイ サーバーで取られたバックアップ制御ファイルをリストアします 1. ( ターゲット データベースとして ) スタンバイ データベースとリカバリ カタログに接続します Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 16

17 2. バックアップ制御ファイルをリストアします RESTORE STANDBY CONTROLFILE; 3. 最後のアーカイブ ログ バックアップ以降に生成されたすべてのアーカイブ ログは アーカイブ ログ バックアップの注意事項 で説明するように 手動でカタログ化することが必要です スタンバイ サーバーのバックアップ制御ファイルを使用できない場合 プライマリ データベースから新しい制御ファイルを作成する必要があります その手順は次のとおりです 1. プライマリ データベースから新しいスタンバイ制御ファイルを作成します 2. SPFILE に指定されているように スタンバイ データベースの多重化されたすべての位置に新しい制御ファイルをコピーし スタンバイ データベースをマウントします 3. MRP を再起動します 4. RMAN で ( ターゲット データベースとして ) スタンバイ データベースとリカバリ カタログに接続します 5. 最後のアーカイブ ログ バックアップ以降に生成されたすべてのアーカイブ ログを アーカイブ ログ バックアップの注意事項 で説明するように 手動でカタログ化します プライマリ データベース上での消失した制御ファイルのリカバリ Oracleでは プライマリ データベース上の制御ファイルを多重化できます プライマリ データベースで制御ファイルの 1 つを更新できない場合 そのプライマリ データベース インスタンスは自動的に停止されます スタンバイ データベースでの消失した制御ファイルのリカバリ で説明した手順と同様 制御ファイルの正常なコピーを壊れたコピー上にコピーすることで リストアやリカバリを行わずにインスタンスを再起動できます すべての制御ファイルが消失した場合 プライマリですべての制御ファイルが消失した場合 許容可能な停止時間に応じて 次の 3 つの選択肢があります 1. スタンバイ データベースへのフェイルオーバーこの選択肢は停止時間が最小です 古いプライマリ データベースが無傷で残っている場合 フェイルオーバー SCN すなわち古いスタンバイ データベースが新しいプライマリ データベースになる SCN に簡単にフラッシュバックができます フェイルオーバー SCN は 次の SQL コマンドを使用して調べることができます SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE; Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 17

18 フラッシュバックが完了すると 新しいスタンバイ データベースは 新しいプライマリ データベースから自動的にREDOを取り戻します フラッシュバックの手順 [4] は Oracle Data Guard 概要および管理 を参照してください 古いプライマリ データベースに問題がある またはリカバリできない場合 新しいプライマリ データベースのバックアップから再作成し 新しいスタンバイ データベースとして戻す必要があります 新しいスタンバイ データベースを再作成する手順 [5] は Oracle Data Guard 概要および管理 を参照してください その他の詳細は Oracle Data Guard 概要および管理 のフィジカル スタンバイ データベース フェイルオーバーの手順 [6] を参照してください 2. 新しい制御ファイルの作成この選択肢は フェイルオーバーと比較して停止時間が長くなります 新しい制御ファイルは NORESETLOGS オプションを使用して作成でき その後にメディア リカバリを実行します 次の SQL をスタンバイ データベース インスタンスで実行することにより トレース ファイルを生成できます ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS; 結果のトレース ファイルには NOMOUNT 状態のプライマリ データベースで制御ファイルの再作成に使用できる SQL スクリプトが入ります 再作成された制御ファイルでは 制御ファイル作成時より前に生成されたアーカイブ ログに関する情報がすべて失われます アーカイブ ログ バックアップをプライマリ データベースで実行する場合 最後のアーカイブ ログ バックアップ以降に生成されたすべてのアーカイブ ログを アーカイブ ログ バックアップの注意事項 で説明するように再カタログする必要があります 3. バックアップ制御ファイルを使用したリカバリ前述の手順で制御ファイルを作成できない場合 プライマリ データベースからバックアップ制御ファイルを使用して完全リカバリを実行し RESETLOGS を指定してオープンします 制御ファイルをリカバリし プライマリ データベースを使用できるようにするには ( ターゲット データベースとして )NOMOUNT のプライマリ データベースとリカバリ カタログに接続後 次の RMAN コマンドを使用します RESTORE CONTROLFILE; ALTER DATABASE MOUNT; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 18

19 前述の RESETLOGS オプションにより作成された新しい REDO ブランチからのアーカイブ ログをスタンバイ データベースが受け取ると スタンバイ データベースは自動的にその新しい REDO ブランチを登録し MRP を終了します スタンバイ データベース サーバーで MRP を再起動すると スタンバイ データベースは自動的に新しい REDO ブランチを追跡します Oracle Database 10g で導入された RESETLOGS 機能による新しいリカバリにより 管理者は 前の REDO ブランチで取ったバックアップからプライマリ データベースとスタンバイ データベースをリカバリできます ( インカネーション ) したがって RESETLOGS 処理後にデータベースの完全バックアップを行う必要はありません これは最も時間のかかる選択肢ですが フェイルオーバーまたはスタンバイから制御ファイルを再作成できない場合に残された唯一の手段です 消失したオンライン ログのリカバリオンライン ログ グループのすべてのメンバーが消失すると Oracleはそのインスタンスを終了します ログ ファイル グループのいずれかのメンバーに書き込みができない場合 そのメンバーはアクセス可能になるまで使用されません オンライン ログ グループの一部または全部が消失した場合のリカバリ手順 [7] は Oracle 高可用性アーキテクチャおよびベスト プラクティス を参照してください データベースのブロック メディア リカバリプライマリまたはスタンバイのデータベースでブロック破損が発生した場合 ブロック メディア リカバリ (BMR) を使用して 不良ブロックを迅速に修復できます このタイプのリカバリは 広範囲のデータファイル破損ではなく 少数のブロックが破損または消失した場合に最も有効です バックアップまたはリストア処理されたすべてのブロックで 物理的破損がチェックされ オプションで論理的破損もチェックされます RMAN VALIDATE コマンドも ブロック破損のチェックに使用できます BMR は 識別済の破損ブロックを最新のバックアップから有効なブロックに置き換えることで機能し 影響を受けたブロックに対してのみ必要なアーカイブ ログを使用してメディア リカバリを実行します BMR がプライマリ データベースまたはスタンバイ データベースのどちらで実行されても すべてのバックアップとアーカイブ ログにアクセスできることが必要です プライマリ データベースでは データベースがオンラインで動作している状態で BMR を実行できます スタンバイ データベースでは BMR の使用前に MRP を停止し 処理後に再起動する必要があります ブロック メディア リカバリの実行方法の詳細は バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 19

20 データベースの不完全リカバリポイント イン タイム リカバリは 通常 プライマリ データベースが論理的に破損した場合 ( ユーザーまたはアプリケーションにより ) あるいは表領域またはデータファイルがデータベースから誤って削除された場合に行われます これらのエラーからリカバリするオプションを実行しやすい順に示します 論理的破損がスタンバイ データベースに伝播していない場合 プライマリ データベースを論理的破損前の状態にフラッシュバックし プライマリ データベースで RESETLOGS をオープンし スタンバイ データベースで REDO 適用を再起動します プライマリ データベースでフラッシュバックが構成されていない場合は スタンバイ データベースでポイント イン タイム リカバリを実行して論理的破損前の状態に戻し フェイルオーバーを実行して スタンバイ データベースを新しいプライマリ データベースとして起動します 旧プライマリ サイトで新しいスタンバイ データベースの再作成が必要です 論理的破損がスタンバイ データベースに伝播している場合 プライマリ データベースとスタンバイ データベースを論理的破損前の状態にフラッシュバックし プライマリ データベースで RESETLOGS をオープンして スタンバイ データベースで適用を再起動します 1 つのスタンバイ データベース サーバーでのみフラッシュバックが構成されている場合 そのサーバーでフラッシュバックを実行して論理的破損前の状態に戻し スタンバイ データベースを新しいプライマリ データベースとして起動します 他のすべてのスタンバイ データベースを 新しい REDO ブランチを追跡する新しいスタンバイ データベースとして再作成する必要があります これらの手順 [8] は Oracle Data Guard 概要および管理 で詳しく説明しています スイッチオーバー / フェイルオーバー後の手順や構成の変更点 スイッチオーバーまたはフェイルオーバーが発生した場合 データベース ロールが変わるため RMAN 構成設定も変更する必要があります 新しいプライマリ データベース バックアップが行われる新しいスタンバイ データベースおよび他のスタンバイ データベースについて 適切な構成の設定は RMANの推奨構成 を参照してください アーカイブ ログ バックアップの注意事項スタンバイ データベースで 最後のアーカイブ ログ バックアップ後に受け取ったアーカイブ ログを RMAN に明示的に知らせる必要がある すなわち再カタログが必要な場合 2 つのケースがあります これは 次の場合に発生します Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 20

21 プライマリ制御ファイルまたはスタンバイ制御ファイルが再作成された スイッチオーバーまたはフェイルオーバーの処理後にデータベース ロールがスタンバイまたはプライマリに変わったたとえば スイッチオーバーまたはフェイルオーバーでは 新しいプライマリ データベースに接続し 次の RMAN コマンドを実行します CATALOG ARCHIVELOG <archived log filename 1>, <archived log filename 2>, etc. ; <Archived log filename 1>, etc は 最後のアーカイブ ログ バックアップ後に生成されたアーカイブ ログを参照します たとえば 通常のバックアップ ジョブを毎日午前 10 時に開始して午前 11 時に終了する場合 午前 11 時からスイッチオーバーの時点までに生成されたすべてのアーカイブ ログをカタログ化する必要があります これらのアーカイブ ログは 次回の通常バックアップ ジョブの際にバックアップされます 注意 : スタンバイ インスタンスが受け取ったアーカイブ ログのみをスタンバイ サイトでバックアップできます スタンバイのインスタンス化前に作成されたアーカイブ ログは プライマリ データベースでバックアップする必要があります RMAN によるスタンバイ データベースのインスタンス化 次の手順で RMAN を使用してスタンバイ データベースをインスタンス化する典型的な方法を概説します RMAN の DUPLICATE コマンドは バックアップ セットからデータファイルをリストアし データベースを現在または UNTIL に指定された時刻 /SCN にリカバリします ( 増分バックアップおよびアーカイブ ログ バックアップを適用 ) この手順は Data Guard 構成をセットアップする メディア障害後または災害後にスタンバイ データベースをリカバリする またはフェイルオーバー処理後に旧プライマリ データベースを新しいスタンバイ データベースとして再インスタンス化するなどの場合に使用できます 1. スタンバイ サーバーに Oracle データベースをインストールします 2. スタンバイ データベース用の初期化パラメータ ファイルを作成します SPFILE は RMAN RESTORE SPFILE コマンドを使用してバックアップからリストアできます 3. SPFILE を使用して NOMOUNT でスタンバイ インスタンスを開始します 4. スタンバイ データベース ホストへの接続に必要な Oracle Net セットアップを実行します Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 21

22 5. 次の RMAN コマンドを実行することにより 制御ファイルのバックアップを BACKUP CURRENT CONTROLFILE FOR STANDBY; 6. 制御ファイル バックアップおよびデータファイルとアーカイブ ログの既存のバックアップを使用して 新しいスタンバイ データベースをインスタンス化します RMAN がプライマリ データベース カタログ データベースおよびスタンバイ データベース インスタンスに接続されていることを確認してください AUXILIARY キーワードを使用し NOMOUNT 状態でスタンバイ インスタンスに接続します > RMAN TARGET <primary_db> CATALOG <catalog_db> AUXILIARY <new_standby_db> 次の RMAN コマンドを実行し 現在の時刻 /SCN で新しいスタンバイ データベースを作成します DUPLICATE TARGET DATABASE FOR STANDBY; RMAN によりスタンバイ データベースをインスタンス化する代替方法 生成します ( ターゲットとして ) プリイマリ データベースとリカバリ カタログに接続することが必要です 前述の手順は自動的にスタンバイ データベースを作成するため スタンバイ サイトですべてのバックアップ セットが使用可能な場合に正しく機能します ファイルのサイズ上の理由から ( テラバイト規模のデータベースなど ) すべてのバックアップ セットをネットワークを介してスタンバイ サイトに転送することが事実上不可能な場合 次の手順でもスタンバイ データベースをインスタンス化できます このシナリオでは 完全バックアップはテープでスタンバイ サイトに送付されますが 増分バックアップはネットワークを介して送信されます 1. スタンバイ サーバーに Oracle データベースをインストールします 2. インスタンス パラメータ ファイル (SPFILE) をスタンバイ サーバーにコピーし その SPFILE を使用して NOMOUNT でスタンバイ データベース インスタンスを開始します 3. プライマリ データベースからスタンバイ制御ファイルを作成し それをスタンバイ データベース サーバーにコピーし スタンバイ データベースをマウントします 4. 完全バックアップをプライマリ サイトからスタンバイ サイトにテープで送付します Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 22

23 5. 完全バックアップのテープの送付中やスタンバイ サーバーへのリストア中も プライマリ データベースで増分バックアップおよびアーカイブ ログ バックアップを継続的に取り 毎日ネットワークを介して送信できます (FTP など ) 6. スタンバイ サーバーでテープにアクセス可能になれば 完全バックアップからのデータファイルをリストアできます リカバリ カタログと ( ターゲット データベースとして ) スタンバイ データベースに接続後 データファイルをリストアします RESTORE DATAFILE <n,m>; 7. すべてのデータファイルがリストアされ すべてのアーカイブ ログ バックアップがスタンバイ サイトにある場合 アーカイブ ログと増分バックアップを適用します RECOVER DATABASE; 8. アーカイブ ログの一部がスタンバイ サイトになくても増分バックアップがある場合は 増分バックアップのみを適用できます RECOVER DATABASE NOREDO; 9. MRPを再起動します FAL_SERVERパラメータとFAL_CLIENTパラメータがすでにセットアップ済の場合 消失したアーカイブ ログが自動的にフェッチされ スタンバイ データベースに適用されます そうでない場合 消失したアーカイブ ログを手動でスタンバイ データベースにコピーし アーカイブ ログ バックアップの注意事項 で説明したように再カタログしてから適用する必要があります 結論 Oracle Data Guard は 拡張管理機能や監視機能などにより Oracle データ資産を障害から非常に幅広く保護します データベースにインストールされる設定不要のバックアップおよびリカバリ ツールである Oracle Recovery Manager(RMAN) と併用することで プライマリまたはスタンバイ データベース サイトでメディア消失が発生しても Oracle データベースを完全にリカバリできます スタンバイ データベースの作成と再インスタンス化も RMAN を使用して実行できます これらの手順をリカバリ計画に組み入れ 徹底的に検証することにより Data Guard 構成におけるメディア リカバリ停止に対して効率的で広範なテクニックを獲得することができます Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 23

24 参照資料 1. Using Recovery Manager (RMAN) with Oracle Data Guard in Oracle9i( 英語 ) _wp.pdf 2. Oracle Flashback Database: Point-in-Time リカバリの代替方法 Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド : tm 3. フィジカル スタンバイ データベースの起動と停止 Oracle Data Guard 概要および管理 : tm 4. フェイルオーバー後のフラッシュバック データベースの使用 Oracle Data Guard 概要および管理 : tm 5. フィジカル スタンバイ データベースの作成 Oracle Data Guard 概要および管理 : tm 6. フィジカル スタンバイ データベースが関与するフェイルオーバー Oracle Data Guard 概要および管理 : tm 7. 実行するリカバリ処置の決定 Oracle 高可用性アーキテクチャおよびベスト プラクティス tm 8. OPEN RESETLOGS 文を使用したリカバリ Oracle Data Guard 概要および管理 : tm Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 24

25 付録発信元ホストで取ったバックアップが使用できない場合 環境によっては 地理的位置 ファイアウォールなどの要因により プライマリ データベース サイトとスタンバイ データベース サイト間でバックアップを共有できないことがあります このような場合 このホワイト ペーパーで説明したバックアップ手順およびリカバリ手順で RMAN TAG 機能を使用する必要があります また プライマリ データベースとスタンバイ データベースの完全バックアップが必要です 次の点を変更することにより このホワイト ペーパーで説明した一般的方針を使用できます RMAN により作成されたバックアップ ファイルにローカル システム名の入ったタグを付け リストア時にはそのタグを使用して RMAN がリモート ホストで取ったバックアップを選択しないように制限します BACKUP コマンドではバックアップの作成に TAG <server name> オプションを RESTORE コマンドでは FROM TAG <server name> オプションを RECOVER コマンドでは FROM TAG <server name> ARCHIVELOG TAG <server name> オプションを それぞれ使用する必要があります スタンバイ データベースの再インスタンス化では TAG 構文が必要です スタンバイ データベースを再インスタンス化する手順は次のとおりです 1. スタンバイが動作していた同じパラメータ ファイルを使用して NOMOUNT 状態でスタンバイ インスタンスを開始します SPFILE から PFILE の現在のコピーを取得するには 次の SQL を使用できます CREATE PFILE= <filename> FROM SPFILE; 2. 次の SQL を使用して プライマリ インスタンスでスタンバイ制御ファイルを作成します ALTER DATABASE CREATE STANDBY CONTROLFILE AS <file name> ; 3. 新しい制御ファイルを使用して スタンバイ インスタンスをマウントします Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 25

26 4. 次の RMAN コマンドを実行して データベース ファイルをリストアおよびリカバリします RESTORE DATABASE FROM TAG <server name used in BACKUP command> ; RECOVER DATABASE FROM TAG <server name used in BACKUP command> ARCHIVELOG TAG <server name used in BACKUP command> ; 5. MRP を再起動します アーカイブ ログ リポジトリとして構成されたスタンバイ データベース スタンバイ データベースは アーカイブ ログのためのリモート バックアップとして機能するアーカイブ ログ リポジトリとして構成できます リポジトリにはデータファイルがありません リポジトリは 消失したアーカイブ ログを取り出すために他のスタンバイ データベースが使用できます この構成の詳細は Oracle Data Guard 概要および管理 を参照してください バックアップ手順 のセクションに示したスクリプトは アーカイブ ログ リポジトリのバックアップにも使用できます ただし データファイルがないため データファイルをバックアップするRMANコマンドは省略してください また MRPは実行されません スタンバイ データベース ファイル名がプライマリ データベースと異なる場合 このセクションでは プライマリ データベースとスタンバイ データベースでファイル名が異なる場合に そのいずれかをリストアおよびリカバリする方法を説明します RMAN がリカバリ カタログにデータベースを登録する場合 RMAN は制御ファイルから分かるデータファイル名を記録します Data Guard 構成で RMAN を使用している場合 データファイル名はプライマリ データベース制御ファイルに基づいてリカバリ カタログに記録されます この動作のため RESTORE コマンドと RECOVER コマンドは このホワイト ペーパーで前述したものとは少し異なります たとえば プライマリ データベース バックアップからスタンバイ データベースをリストアする場合 スタンバイ データベースの実際のデータファイル名は V$DATAFILE ビューから取得でき すべてのデータファイルについて 次のように SET NEWNAME オプションで名前を指定する必要があります Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 26

27 RUN { SET NEWNAME FOR DATAFILE 1 TO <existing file location for file#1 from V$DATAFILE> ; SET NEWNAME FOR DATAFILE 2 TO <existing file location for file#2 from V$DATAFILE> ; SET NEWNAME FOR DATAFILE n TO <existing file location for file#n from V$DATAFILE> ; RESTORE {DATAFILE <n,m, > TABLESPACE <tbs_name_1, 2, DATABASE}; SWITCH DATAFILE ALL; RECOVER DATABASE {NOREDO}; } 同様に RMAN DUPLICATE の実行前にも SET NEWNAME を使用してスタンバ イ データベース作成中に新しいファイル名を指定する必要があります Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 27

28 Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 2005 年 9 月著者 : Anand Beldalker, Timothy Chien 寄稿者 : Steven Wertheimer, Antonio Romero, Ashish Ray, Lawrence To, Douglas Utzig, Tammy Bednar, Joe Meeks, Larry Carpenter Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファックス : Copyright 2005, Oracle. 無断転載を禁ず この文書はあくまで参考資料であり 掲載されている情報は予告なしに変更されることがあります オラクル社は 本ドキュメントの無謬性を保証しません また 本ドキュメントは 法律で明示的または暗黙的に記載されているかどうかに関係なく 商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません オラクル社は 本書の内容に関していかなる保証もいたしません また 本書により 契約上の直接的および間接的義務も発生しません 本書は 事前の書面による承諾を得ることなく 電子的または物理的に いかなる形式や方法によっても再生または伝送することはできません Oracle JD Edwards PeopleSoft は Oracle Corporation および関連会社の登録商標です 他の製品名は それぞれの所有者の商標です