Zero Data Loss Recovery Appliance

管理者ガイド

リリース12.1

E57735-09(原本部品番号:E37431-28)

2017年2月

Zero Data Loss Recovery Appliance管理者ガイド, リリース12.1

E57735-09

Copyright © 2014, 2017, Oracle and/or its affiliates.  All rights reserved.

原本著者: Terence Buencamino

原本協力著者: Lance Ashdown、Aishwarya Minocha

原本協力者: Andrew Babb、Donna Carver、Tim Chien、Sean Connolly、Donna Cooksey、Bill Fischer、Mahesh Girkar、Ray Guzman、Dah-Yoh Lim、Colin McGregor、Kant Patel、Chris Plakyda、Padmaja Potineni、Kathy Rich、Jony Safi、Toru Sasaki、Lawrence To、Randy Urbano、Steven Wertheimer

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 リカバリ・アプライアンスの概要

- 1.1 従来のデータベース・バックアップ方法

- 1.1.1 週次完全バックアップと日次増分バックアップ

- 1.1.2 増分バックアップとRECOVER COPY

- 1.1.3 サードパーティの重複除外アプライアンスへの完全バックアップ

- 1.1.4 サードパーティの記憶域スナップショット

- 1.2 現在のエンタープライズにおけるデータ保護の課題

- 1.3 Oracleのリカバリ・アプライアンス・ソリューション

- 1.3.1 データ損失の解消

- 1.3.1.1 実行中のトランザクションの保護

- 1.3.1.2 セキュア・レプリケーション

- 1.3.1.3 自律型テープ・アーカイブ

- 1.3.1.4 エンドツーエンド・データ検証

- 1.3.2 最小限のバックアップ・オーバヘッド

- 1.3.2.1 デルタ・プッシュ

- 1.3.2.2 デルタ・ストア

- 1.3.2.2.1 仮想完全バックアップの作成

- 1.3.2.2.2 仮想完全バックアップを使用した高速リカバリ

- 1.3.3 データ保護の総合的な視点の強化

- 1.3.4 クラウド規模の保護

- 1.3.4.1 ポリシーベースのデータ保護管理

- 1.3.4.2 データベース認識領域管理

- 1.3.4.3 スケーラブルなアーキテクチャ

- 1.3.5 最大可用性: Oracle Data Guardと連携するリカバリ・アプライアンス

- 1.4 次に行うこと

2 リカバリ・アプライアンスのアーキテクチャ

- 2.1 リカバリ・アプライアンス環境

- 2.1.1 リカバリ・アプライアンス環境の主要コンポーネント

- 2.1.2 リカバリ・アプライアンス環境のユーザー・アカウント

- 2.1.3 バックアップのライフサイクル: シナリオ

- 2.2 保護データベース

- 2.2.1 リカバリ・アプライアンス・バックアップ・モジュール

- 2.2.2 保護ポリシー

- 2.2.2.1 保護ポリシーの属性

- 2.2.2.2 リカバリ・ウィンドウ

- 2.2.2.3 バックアップ・ポーリング・ポリシー

- 2.2.3 サポートされるOracle Databaseリリース

- 2.3 リアルタイムREDOトランスポート

- 2.4 リカバリ・アプライアンスのメタデータ・データベース

- 2.4.1 デルタ・ストア

- 2.4.2 デルタ・プール

- 2.4.3 自動デルタ・プール領域管理

- 2.4.4 リカバリ・アプライアンス・スキーマ

- 2.4.5 リカバリ・アプライアンス・カタログ

- 2.5 リカバリ・アプライアンスの記憶域

- 2.5.1 リカバリ・アプライアンスの記憶域の場所

- 2.5.1.1 Recovery Applianceの記憶域のメリット

- 2.5.1.2 Oracle ASMおよびRecovery Applianceの記憶域

- 2.5.1.3 DELTA記憶域の場所

- 2.5.2 バックアップ・ポーリングの場所

- 2.5.2.1 バックアップ・ポーリングのステージ

- 2.5.2.2 リカバリ・アプライアンスによるバックアップ・ポーリング・ディレクトリのバックアップの処理方法

- 2.5.3 リカバリ・アプライアンスによる記憶域の管理方法

- 2.5.3.1 リカバリ・ウィンドウ目標

- 2.5.3.2 予約済領域

- 2.5.3.3 コピーの保証

- 2.5.3.4 最長保存期間

- 2.5.3.5 アーカイブ・バックアップと暗号化バックアップ

- 2.6 Oracle Secure Backup

- 2.6.1 テープ・アーカイブ

- 2.6.2 テープ取得

- 2.7 リカバリ・アプライアンス・レプリケーション

- 2.7.1 ダウンストリーム・リカバリ・アプライアンスによるバックアップの処理方法

- 2.7.2 レプリケーションのユースケース

- 2.8 データ暗号化手法

- 2.8.1 本番データベースの表領域での透過的データ暗号化(TDE)

- 2.8.2 Recovery Applianceへのネットワーク転送用のOracle Netセキュリティ

- 2.8.3 LOG_ARCHIVE_DEST_nを使用したREDO暗号化

- 2.8.4 テープ・ドライブベースのハードウェア暗号化

第I部 リカバリ・アプライアンスの管理

3 リカバリ・アプライアンスのワークフロー

- 3.1 リカバリ・アプライアンス管理における職務の分離

- 3.2 リカバリ・アプライアンス管理の前提条件

- 3.3 リカバリ・アプライアンス管理のツール

- 3.4 リカバリ・アプライアンスの計画

- 3.5 リカバリ・アプライアンスの設定と構成

- 3.6 Recovery Applianceのメンテナンス・タスク

4 リカバリ・アプライアンスのためのCloud Controlスタート・ガイド

- 4.1 エンタープライズのすべてのリカバリ・アプライアンスの表示

- 4.2 リカバリ・アプライアンス・ホームページへのアクセス

- 4.3 リカバリ・アプライアンスの記憶域の場所ページへのアクセス

5 リカバリ・アプライアンスでの保護ポリシーの管理

- 5.1 保護ポリシーについて

- 5.1.1 保護ポリシーの目的

- 5.1.2 保護ポリシーの概要

- 5.1.3 保護ポリシーのユーザー・インタフェース

- 5.1.3.1 Cloud Controlの保護ポリシーの作成ページへのアクセス

- 5.1.3.2 保護ポリシーに関連するDBMS_RAプロシージャ

- 5.1.3.3 保護ポリシーのリカバリ・カタログ・ビュー

- 5.1.4 保護ポリシーを管理するための基本タスク

- 5.2 バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)

- 5.3 保護ポリシーの作成

- 5.3.1 Cloud Controlを使用した保護ポリシーの作成

- 5.3.2 DBMS_RAを使用した保護ポリシーの作成

- 5.4 保護ポリシーの更新

- 5.4.1 Cloud Controlを使用した保護ポリシーの更新

- 5.4.2 DBMS_RAを使用した保護ポリシーの更新

- 5.5 保護ポリシーの削除

- 5.5.1 Cloud Controlを使用した保護ポリシーの削除

- 5.5.2 DBMS_RAを使用した保護ポリシーの削除

6 保護されたデータベース・アクセスのためのリカバリ・アプライアンスの構成

- 6.1 保護されたデータベース・アクセスについて

- 6.1.1 保護されたデータベース・アクセスの目的

- 6.1.2 保護されたデータベース・アクセスの概要

- 6.1.3 保護されたデータベース・アクセスを構成するためのユーザー・インタフェース

- 6.1.3.1 Cloud Controlでの保護されたデータベース・ページへのアクセス

- 6.1.3.2 保護されたデータベース・アクセスに関連するDBMS_RAプロシージャ

- 6.1.3.3 保護されたデータベース・アクセスのリカバリ・カタログ・ビュー

- 6.1.4 保護されたデータベース・アクセスを構成するための基本的なタスク

- 6.2 仮想プライベート・カタログ・アカウントの作成

- 6.3 保護されたデータベースの登録

- 6.3.1 Cloud Controlを使用した保護されたデータベースの登録

- 6.3.2 コマンドラインを使用した保護されたデータベースの登録

- 6.3.2.1 DBMS_RAを使用した保護されたデータベースのメタデータの追加

- 6.3.2.2 DBMS_RAを使用したリカバリ・アプライアンス・アカウントへのデータベース・アクセスの付与

- 6.4 保護されたデータベースのプロパティの更新

- 6.4.1 Cloud Controlを使用した保護されたデータベースのプロパティの更新

- 6.4.2 DBMS_RAを使用した別の保護ポリシーへのデータベースの割当て

7 リカバリ・アプライアンスでのテープへのバックアップのコピーについて

- 7.1 リカバリ・アプライアンスでのテープへのバックアップのコピーについて

- 7.1.1 リカバリ・アプライアンスでテープにバックアップをコピーする目的

- 7.1.2 リカバリ・アプライアンスでのテープへのバックアップのコピーの概要

- 7.1.2.1 リカバリ・アプライアンスでのテープ操作について

- 7.1.2.2 テープ操作を管理するためのリカバリ・アプライアンス・コンポーネント

- 7.1.2.3 テープでのバックアップ保存

- 7.1.2.4 テープ・バックアップ操作の一時停止および再開について

- 7.1.2.5 リカバリ・アプライアンスでのOracle Secure Backupの使用について

- 7.1.3 リカバリ・アプライアンスのユーザー・インタフェース

- 7.1.3.1 Cloud Controlでのリカバリ・アプライアンスへのアクセス

- 7.1.3.2 DBMS_RAを使用したリカバリ・アプライアンスへのアクセス

- 7.1.3.2.1 テープ・バックアップ操作のDBMS_RAプロシージャ

- 7.1.3.2.2 テープ操作のリカバリ・カタログ・ビュー

- 7.1.4 リカバリ・アプライアンスでテープにバックアップをコピーするための基本的なタスク

- 7.1.4.1 Cloud Controlを使用したOracle Secure Backupドメインへのアクセス

- 7.2 テープ・バックアップ・ジョブ・コンポーネントの作成

- 7.2.1 メディア・マネージャ・ライブラリの作成

- 7.2.1.1 Cloud Controlを使用したメディア・マネージャ・ライブラリの作成

- 7.2.1.2 DBMS_RAを使用したSBTライブラリの作成

- 7.2.2 属性セットの作成

- 7.2.2.1 Cloud Controlを使用した属性セットの作成

- 7.2.2.2 DBMS_RAを使用したSBT属性セットの作成

- 7.3 テープ・バックアップ・ジョブ・コンポーネントの管理

- 7.3.1 Cloud Controlを使用したメディア・マネージャ・ライブラリの管理

- 7.3.1.1 メディア・マネージャ・ライブラリの編集

- 7.3.1.2 メディア・マネージャ・ライブラリの削除

- 7.3.2 DBMS_RAを使用したSBTライブラリの管理

- 7.3.2.1 SBTライブラリの編集

- 7.3.2.2 SBTライブラリの削除

- 7.3.3 Cloud Controlを使用した属性セットの管理

- 7.3.3.1 属性セットの編集

- 7.3.3.2 属性セットの削除

- 7.3.4 DBMS_RAを使用した属性セットの管理

- 7.3.4.1 SBT属性セットの編集

- 7.3.4.2 SBT属性セットの削除

- 7.4 テープ・バックアップ・ジョブの作成

- 7.4.1 Cloud Controlを使用したテープ・バックアップ・ジョブの作成

- 7.4.2 例: Cloud Controlを使用したテープ・バックアップ・ジョブの作成

- 7.4.3 DBMS_RAを使用したテープ・バックアップ・ジョブの作成

- 7.4.4 例: DBMS_RAを使用したテープ・バックアップ・ジョブの作成

- 7.5 テープ・バックアップ・ジョブの管理

- 7.5.1 Cloud Controlを使用したテープ・バックアップ・ジョブの管理

- 7.5.1.1 テープ・バックアップ・ジョブの編集

- 7.5.1.2 テープ・バックアップ・ジョブの削除

- 7.5.2 DBMS_RAを使用したテープ・バックアップ・ジョブの管理

- 7.5.2.1 SBTジョブの編集

- 7.5.2.2 SBTジョブの削除

- 7.6 テープ・バックアップ・ジョブのスケジューリング

- 7.6.1 Cloud Controlを使用したテープ・バックアップ・ジョブのスケジューリング

- 7.6.2 Oracle Schedulerを使用したテープ・バックアップ・ジョブのスケジューリング

- 7.7 テープ・バックアップ操作の一時停止および再開

- 7.7.1 Cloud Controlを使用したメディア・マネージャ・ライブラリ操作の一時停止および再開

- 7.7.1.1 メディア・マネージャ・ライブラリの一時停止

- 7.7.1.2 メディア・マネージャ・ライブラリの再開

- 7.7.2 DBMS_RAを使用したSBTライブラリの一時停止および再開

- 7.7.2.1 SBTライブラリの一時停止

- 7.7.2.2 SBTライブラリの再開

- 7.8 テープ・バックアップ操作のステータスの表示

- 7.8.1 Cloud Controlを使用したテープ・バックアップ操作のステータスの表示

- 7.8.1.1 メディア・マネージャ・ライブラリのステータスの表示

- 7.8.1.2 テープ・バックアップ・ジョブのステータスの表示

- 7.8.2 DBMS_RAを使用したテープ・バックアップ操作のステータスの表示

- 7.8.2.1 SBTライブラリのステータスの確認

- 7.8.2.2 テープ・バックアップ・ジョブのステータスの確認

- 7.8.2.3 DBMS_RAを使用したSBTジョブ実行のレビュー

- 7.8.2.4 Oracle Schedulerジョブのステータスの確認

8 リカバリ・アプライアンスでのバックアップのレプリケート

- 8.1 リカバリ・アプライアンス・レプリケーションについて

- 8.1.1 リカバリ・アプライアンス・レプリケーションの目的

- 8.1.2 リカバリ・アプライアンス・レプリケーションの概要

- 8.1.2.1 レプリケーションの保護ポリシー

- 8.1.2.2 レプリケーション・トポロジの例

- 8.1.2.2.1 1つのダウンストリーム・リカバリ・アプライアンスへのレプリケーション

- 8.1.2.2.2 複数のダウンストリーム・リカバリ・アプライアンスへのレプリケーション

- 8.1.2.2.3 ダウンストリーム・リカバリ・アプライアンスでの異なるポリシーを使用したレプリケーション

- 8.1.2.2.4 カスケード型レプリケーション

- 8.1.2.3 リカバリ・アプライアンスでのバックアップのレプリケート方法: 基本プロセス

- 8.1.2.4 RMANがレプリケーション環境でバックアップをリストアする方法

- 8.1.3 リカバリ・アプライアンス・レプリケーションのユーザー・インタフェース

- 8.1.3.1 Cloud Controlでのレプリケーション・ページへのアクセス

- 8.1.3.2 レプリケーションに関連するDBMS_RAプロシージャ

- 8.1.3.3 レプリケーションのリカバリ・カタログ・ビュー

- 8.1.4 リカバリ・アプライアンス・レプリケーションを構成するための基本的なタスク

- 8.2 Cloud Controlを使用したリカバリ・アプライアンス・レプリケーションの構成

- 8.3 DBMS_RAを使用したリカバリ・アプライアンスでのレプリケーションの構成

- 8.3.1 レプリケーション例の仮定

- 8.3.2 DBMS_RAを使用したダウンストリーム・リカバリ・アプライアンスでのレプリケーションの構成

- 8.3.3 DBMS_RAを使用したアップストリーム・リカバリ・アプライアンスでのレプリケーションの構成

- 8.3.4 リカバリ・アプライアンス・レプリケーションのための保護されたデータベースの構成

- 8.3.5 リカバリ・アプライアンスのレプリケーション・サーバー構成のテスト

9 追加の高可用性計画の実装

- 9.1 バックアップおよびREDOフェイルオーバー計画を使用した一時的な停止の管理

- 9.1.1 バックアップおよびREDOフェイルオーバー機能の概要

- 9.1.2 バックアップおよびREDOフェイルオーバーの構成

- 9.1.2.1 バックアップおよびREDOフェイルオーバーのためのプライマリ・リカバリ・アプライアンスの構成

- 9.1.2.2 バックアップおよびREDOフェイルオーバーのための代替リカバリ・アプライアンスの構成

- 9.1.2.3 バックアップおよびREDOフェイルオーバーのレプリケーションの構成

- 9.1.2.4 バックアップおよびREDOフェイルオーバーのための保護されたデータベースの構成

10 リカバリ・アプライアンスのモニタリング

- 10.1 リカバリ・アプライアンスのモニタリングについて

- 10.1.1 リカバリ・アプライアンスをモニタリングする目的

- 10.1.2 リカバリ・アプライアンス・モニタリング機能の概要

- 10.1.2.1 Cloud Control

- 10.1.2.2 Oracle Configuration Manager

- 10.1.2.3 自動サービス・リクエスト(ASR)

- 10.1.3 リカバリ・アプライアンスをモニタリングするためのCloud Controlインタフェース

- 10.1.4 リカバリ・アプライアンスをモニタリングするための基本的なタスク

- 10.2 メトリックと収集設定の変更

- 10.3 インシデント・マネージャ・ページの表示

- 10.4 パフォーマンスのモニタリング

- 10.4.1 rastatユーティリティによるパフォーマンス統計の生成

- 10.4.1.1 rastatユーティリティを実行する前提条件

- 10.4.1.2 rastatユーティリティの実行

- 10.4.2 ネットワーク・スループットのテスト

11 リカバリ・アプライアンス・レポートへのアクセス

- 11.1 リカバリ・アプライアンス・レポートについて

- 11.1.1 リカバリ・アプライアンス・レポートの目的

- 11.1.2 リカバリ・アプライアンス・レポートの概要

- 11.1.2.1 事前作成されたBI Publisherレポート

- 11.1.2.2 BI Publisherレポートのスケジューリング

- 11.1.3 Cloud Controlでのリカバリ・アプライアンス・レポート・ページへのアクセス

- 11.1.4 リカバリ・アプライアンス・レポートにアクセスするための基本的なタスク

- 11.2 記憶域容量レポートへのアクセス

- 11.3 リカバリ・ウィンドウ・サマリー・レポートへのアクセス

- 11.4 保護されたデータベースの詳細レポートへのアクセス

- 11.4.1 保護されたデータベース・ページからの詳細レポートへのアクセス

- 11.4.2 リカバリ・アプライアンス・レポート・ページからの保護された詳細レポートへのアクセス

- 11.5 保護されたデータベースのデータ転送レポートへのアクセス

第II部 リカバリ・アプライアンスのリファレンス

12 DBMS_RAパッケージのリファレンス

- 12.1 ABORT

- 12.2 ABORT_RECOVERY_APPLIANCE

- 12.3 ADD_DB

- 12.4 ADD_REPLICATION_SERVER

- 12.5 CONFIG

- 12.6 COPY_BACKUP

- 12.7 COPY_BACKUP_PIECE

- 12.8 CREATE_POLLING_POLICY

- 12.9 CREATE_PROTECTION_POLICY

- 12.10 CREATE_REPLICATION_SERVER

- 12.11 CREATE_SBT_ATTRIBUTE_SET

- 12.12 CREATE_SBT_JOB_TEMPLATE

- 12.13 CREATE_SBT_JOB_TEMPLATE

- 12.14 CREATE_SBT_LIBRARY

- 12.15 CREATE_STORAGE_LOCATION

- 12.16 DELETE_DB

- 12.17 DELETE_POLLING_POLICY

- 12.18 DELETE_PROTECTION_POLICY

- 12.19 DELETE_REPLICATION_SERVER

- 12.20 DELETE_SBT_ATTRIBUTE_SET

- 12.21 DELETE_SBT_JOB_TEMPLATE

- 12.22 DELETE_SBT_LIBRARY

- 12.23 DELETE_STORAGE_LOCATION

- 12.24 GRANT_DB_ACCESS

- 12.25 MIGRATE_TAPE_BACKUP

- 12.26 MOVE_BACKUP

- 12.27 MOVE_BACKUP_PIECE

- 12.28 PAUSE_REPLICATION_SERVER

- 12.29 PAUSE_SBT_LIBRARY

- 12.30 POPULATE_BACKUP_PIECE

- 12.31 QUEUE_SBT_BACKUP_TASK

- 12.32 REMOVE_REPLICATION_SERVER

- 12.33 RENAME_DB

- 12.34 RESET_ERROR

- 12.35 RESUME_REPLICATION_SERVER

- 12.36 RESUME_SBT_LIBRARY

- 12.37 REVOKE_DB_ACCESS

- 12.38 SHUTDOWN

- 12.39 SHUTDOWN_RECOVERY_APPLIANCE

- 12.40 STARTUP

- 12.41 STARTUP_RECOVERY_APPLIANCE

- 12.42 UPDATE_DB

- 12.43 UPDATE_POLLING_POLICY

- 12.44 UPDATE_PROTECTION_POLICY

- 12.45 UPDATE_REPLICATION_SERVER

- 12.46 UPDATE_SBT_ATTRIBUTE_SET

- 12.47 UPDATE_SBT_JOB_TEMPLATE

- 12.48 UPDATE_SBT_LIBRARY

- 12.49 UPDATE_STORAGE_LOCATION

13 リカバリ・アプライアンスのビュー・リファレンス

- 13.1 リカバリ・アプライアンスのビューのまとめ

- 13.2 RA_ACTIVE_SESSION

- 13.3 RA_API_HISTORY

- 13.4 RA_CONFIG

- 13.5 RA_DATABASE

- 13.6 RA_DATABASE_STORAGE_USAGE

- 13.7 RA_DATABASE_SYNONYM

- 13.8 RA_DB_ACCESS

- 13.9 RA_DISK_RESTORE_RANGE

- 13.10 RA_EM_SBT_JOB_TEMPLATE

- 13.11 RA_INCIDENT_LOG

- 13.12 RA_INCOMING_BACKUP_PIECES

- 13.13 RA_POLLING_FILES

- 13.14 RA_POLLING_POLICY

- 13.15 RA_PROTECTION_POLICY

- 13.16 RA_PURGING_QUEUE

- 13.17 RA_REPLICATION_SERVER

- 13.18 RA_RESTORE_RANGE

- 13.19 RA_SBT_ATTRIBUTE_SET

- 13.20 RA_SBT_JOB

- 13.21 RA_SBT_LIBRARY

- 13.22 RA_SBT_RESTORE_RANGE

- 13.23 RA_SBT_TASK

- 13.24 RA_SBT_TEMPLATE_MDF

- 13.25 RA_SERVER

- 13.26 RA_STORAGE_HISTOGRAM

- 13.27 RA_STORAGE_LOCATION

- 13.28 RA_TASK

- 13.29 RA_TIME_USAGE

14 rastatユーティリティのリファレンス

- 14.1 rastatのコマンド構文

- 14.2 オプション

15 リカバリ・アプライアンスのエラー・メッセージ・リファレンス

用語集

索引

図一覧

- 1-1 テープへの完全バックアップと増分バックアップ

- 1-2 ディスクでのRECOVER COPYとテープへのバックアップ

- 1-3 サードパーティの重複除外アプライアンス

- 1-4 サードパーティのcopy-on-writeスナップショット

- 1-5 リカバリ・アプライアンス環境

- 1-6 一方向のレプリケーション

- 1-7 リカバリ・アプライアンスを使用しないテープへのバックアップ

- 1-8 リカバリ・アプライアンスを使用したテープへのバックアップ

- 1-9 デルタ・プッシュとデルタ・ストア

- 1-10 Oracle Data Guardと連携するリカバリ・アプライアンス

- 2-1 サンプル・リカバリ・アプライアンス環境

- 2-2 RASYSとリカバリ・アプライアンス・ユーザー・アカウント

- 2-3 リカバリ・アプライアンス・バックアップ・モジュール

- 2-4 REDOログの送信

- 2-5 リカバリ・アプライアンスのメタデータ・データベース

- 2-6 デルタ・ストアのデルタ・プール

- 2-7 DELTA記憶域の場所

- 2-8 複数の記憶域の場所

- 2-9 バックアップ・ポーリング

- 2-10 リカバリ・アプライアンス・レプリケーションのユースケース

- 2-11 データ暗号化手法

- 4-1 「記憶域の場所」ページ

- 5-1 保護ポリシー

- 5-2 「保護ポリシー」ページ

- 5-3 リカバリ・アプライアンス・ワークフローの保護ポリシー・タスク

- 5-4 「保護ポリシーの作成」ページ

- 6-1 保護されたデータベース・アクセス

- 6-2 「保護対象データベース」ページ

- 6-3 リカバリ・アプライアンス・ワークフローでのデータベース・アクセス構成タスク

- 6-4 「保護されたデータベースの追加」ページ

- 6-5 「保護されたデータベースの追加」ページ

- 7-1 「メディア・マネージャ」ページ

- 7-2 「メディア・マネージャ・ライブラリの編集」画面

- 7-3 「リカバリ・アプライアンスのCopy-to-Tapeジョブ・テンプレートの作成」ページ

- 7-4 テープ・バックアップ・ジョブ例

- 8-1 単純なレプリケーション・トポロジ

- 8-2 1つのリカバリ・アプライアンスへのデータベースのレプリケート

- 8-3 複数のリカバリ・アプライアンスへのデータベースのレプリケート

- 8-4 各リカバリ・アプライアンスの保護ポリシーが異なる場合

- 8-5 各リカバリ・アプライアンスに異なる保護ポリシーがあるカスケード型レプリケーション

- 8-6 「レプリケーション」ページ

- 8-7 レプリケーションのワークフロー

- 8-8 「保護ポリシー」ページ

- 8-9 「保護ポリシーの作成」ページ

- 8-10 「保護されたデータベースの追加」ページ

- 8-11 「レプリケーション・サーバーの作成」ページ

- 8-12 プロシージャ・ステップ

- 8-13 レプリケーションの手動構成の概要

- 10-1 リカバリ・アプライアンス・ワークフローでのモニタリング・タスク

- 11-1 リカバリ・アプライアンス・ワークフローでのレポート・タスク

表一覧

- 2-1 リカバリ・アプライアンス環境のユーザー・アカウント

- 2-2 デフォルト保護ポリシー

- 2-3 保護ポリシーの属性

- 2-4 RMAN暗号化およびRMAN圧縮での永久増分のサポート

- 5-1 DBMS_RA保護ポリシー・プロシージャ

- 5-2 保護ポリシーのリカバリ・カタログ・ビュー

- 6-1 保護されたデータベース・アクセスのDBMS_RAプロシージャ

- 6-2 保護されたデータベース・アクセスのリカバリ・カタログ・ビュー

- 7-1 バックアップをテープにコピーするためのリカバリ・アプライアンス・オブジェクト

- 7-2 テープ・バックアップ操作に関連付けられているDBMS_RAプロシージャ

- 7-3 RA_SBT_LIBRARYのSTATUS列の値

- 8-1 レプリケーションに関連する主なプロシージャ

- 8-2 レプリケーションのビュー

- 12-1 DBMS_RAパッケージのサブプログラム

- 12-2 ADD_DBのパラメータ

- 12-3 ADD_REPLICATION_SERVERパラメータ

- 12-4 CONFIGのパラメータ

- 12-5 COPY_BACKUPのパラメータ

- 12-6 COPY_BACKUP_PIECEパラメータ

- 12-7 CREATE_POLLING_POLICYパラメータ

- 12-8 CREATE_PROTECTION_POLICYパラメータ

- 12-9 CREATE_REPLICATION_SERVERパラメータ

- 12-10 CREATE_SBT_ATTRIBUTE_SETのパラメータ

- 12-11 CREATE_SBT_JOB_TEMPLATEのパラメータ

- 12-12 CREATE_SBT_JOB_TEMPLATEのパラメータ

- 12-13 CREATE_SBT_LIBRARYのパラメータ

- 12-14 CREATE_STORAGE_LOCATIONのパラメータ

- 12-15 DELETE_DBのパラメータ

- 12-16 DELETE_POLLING_POLICYのパラメータ

- 12-17 DELETE_PROTECTION_POLICYのパラメータ

- 12-18 DELETE_REPLICATION_SERVERのパラメータ

- 12-19 DELETE_SBT_ATTRIBUTE_SETのパラメータ

- 12-20 DELETE_SBT_JOB_TEMPLATEのパラメータ

- 12-21 DELETE_SBT_LIBRARYのパラメータ

- 12-22 DELETE_STORAGE_LOCATIONのパラメータ

- 12-23 GRANT_DB_ACCESSのパラメータ

- 12-24 MIGRATE_TAPE_BACKUPパラメータ

- 12-25 MOVE_BACKUPのパラメータ

- 12-26 MOVE_BACKUP_PIECEパラメータ

- 12-27 PAUSE_REPLICATION_SERVERパラメータ

- 12-28 PAUSE_SBT_LIBRARYパラメータ

- 12-29 POPULATE_BACKUP_PIECEパラメータ

- 12-30 QUEUE_SBT_BACKUP_TASKパラメータ

- 12-31 REMOVE_REPLICATION_SERVERパラメータ

- 12-32 RENAME_DBのパラメータ

- 12-33 RESET_ERRORのパラメータ

- 12-34 RESUME_REPLICATION_SERVERパラメータ

- 12-35 RESUME_SBT_LIBRARYパラメータ

- 12-36 REVOKE_DB_ACCESSパラメータ

- 12-37 UPDATE_DBのパラメータ

- 12-38 UPDATE_POLLING_POLICYパラメータ

- 12-39 UPDATE_PROTECTION_POLICYパラメータ

- 12-40 UPDATE_REPLICATION_SERVERパラメータ

- 12-41 UPDATE_SBT_ATTRIBUTE_SETパラメータ

- 12-42 UPDATE_SBT_JOB_TEMPLATEパラメータ

- 12-43 UPDATE_SBT_LIBRARYパラメータ

- 12-44 UPDATE_STORAGE_LOCATIONパラメータ

- 13-1 リカバリ・アプライアンスのビュー

- 14-1 rastatのオプション

はじめに

『Zero Data Loss Recovery Appliance管理者ガイド』へようこそ。

「はじめに」の内容は次のとおりです。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、一般にリカバリ・アプライアンスと呼ばれるZero Data Loss Recovery Applianceを構成および管理するコンピュータ担当者を対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のドキュメントを参照してください。

- 『Zero Data Loss Recovery Applianceオーナーズ・ガイド』

- 『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』

- 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

- 『Oracle Secure Backup管理者ガイド』

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 リカバリ・アプライアンスの概要

クラウド規模のZero Data Loss Recovery Appliance (通常、リカバリ・アプライアンスと呼ばれる)は、エンタープライズ内のすべてのOracleデータベースでデータ損失とバックアップ・オーバーヘッドを劇的に削減するエンジニアド・システムです。Recovery Manager (RMAN)と統合したリカバリ・アプライアンスによって、クラウド規模の耐障害性の高いハードウェアと記憶域を使用し、多数のデータベースに対応する、集中管理された永久的増分バックアップ計画が実現します。リカバリ・アプライアンスでは、継続してバックアップのリカバリ可能性が検証されます。

この章の内容は次のとおりです。

- 従来のデータベース・バックアップ方法

- 現在のエンタープライズにおけるデータ保護の課題

- Oracleのリカバリ・アプライアンス・ソリューション

- 次に行うこと

1.1 従来のデータベース・バックアップ方法

すべての本番Oracleデータベースではデータ保護が必要です。Oracleでは優先バックアップ・ソリューションとしてRMANを提供しています。ほとんどのエンタープライズは、この項で説明する1つ以上のデータベース・バックアップ計画を採用しています。

- 週次完全バックアップと日次増分バックアップ

- 増分バックアップとRECOVER COPY

- サードパーティの重複除外アプライアンスへの完全バックアップ

- サードパーティの記憶域スナップショット

1.1.1 週次完全バックアップと日次増分バックアップ

図1-1に示す一般的なアプローチの1つでは、RMANを使用して、完全バックアップを毎週、増分バックアップを毎日作成します。増分バックアップのパフォーマンスを向上させるには、ブロック変更トラッキングを有効化することをお薦めします。このようなバックアップは、データベースに対するアクティビティが最も少ないときに行われます。

図1-1 テープへの完全バックアップと増分バックアップ

この方法のメリットは、本番サーバーに影響するバックアップ・ウィンドウが、増分バックアップを作成する日には比較的短いことです。デメリットは、複数のグローバル・タイムゾーンに合せて稼働している場合のようにデータベースが継続してアクティブなときには、バックアップ・ウィンドウを設定しにくいことです。

1つのソリューションは、Oracle Data Guardを設定して、スタンバイ・データベースをバックアップすることです。こうすると、バックアップの負荷を本番サーバーから除くことができます。ただし、多くの場合、すべてのデータベースをOracle Data Guardで保護することは実用的ではありません。

1.1.2 増分バックアップとRECOVER COPY

図1-2に示すRMANのアプローチは、増分バックアップを毎日作成し、RECOVER COPYコマンドを使用して、増分変更をデータベース全体のコピーにマージします。こうすると、ディスク上のデータベース・コピーが毎日「ロール・フォワード」されます。

図1-2 ディスクでのRECOVER COPYとテープへのバックアップ

この方法には次のメリットがあります。

- 完全バックアップは最初に1回しか必要ないため、毎週のバックアップ・ウィンドウの合計時間が短縮されます。

- RMAN SWITCHコマンドで制御ファイルにデータベース・コピーを指定できます。これにより、コピーが実際のデータベース・ファイルになり、RESTOREステップが省かれます。

デメリットは次のとおりです。

- データベース全体のコピーをディスクに保持するために十分なディスク領域と、そのリカバリに必要なアーカイブREDOログ・ファイルが必要です。

- データベースの物理コピーが1つしか存在しません。どのポイント・イン・タイムのコピーを保存するかを選択しますが、リカバリできるのはそれ移行のポイント・イン・タイムです。たとえば、過去1週間の任意のポイント・イン・タイムにリストアするには、物理コピーがSYSDATE-7よりも古いことが必要です。デメリットは、次のとおりです。

- データベースのコピーを保存した時点よりも前の時点にはリカバリできません。

- リカバリのポイント・イン・タイムが現在時刻に近くなるほど、リストアしてコピーに適用する必要がある増分バックアップ数が増加します。この方法では、全体のリカバリ時間の目標が延長されます。

- データベース・コピーを圧縮または暗号化できません。

1.1.3 サードパーティの重複除外アプライアンスへの完全バックアップ

RMANによる増分バックアップとテープ・ドライブのかわりに、サードパーティの重複除外アプライアンスを使用してバックアップ・ストリームを処理する場合もあります。図1-3では、集中管理されるサードパーティ・アプライアンスに3つのデータベースが書き込んでいます。

図1-3 サードパーティの重複除外アプライアンス

この方法には次のメリットがあります。

- 一元管理されるバックアップの場所で、環境内のすべてのデータベースを処理します。

- サードパーティ・ソフトウェアが、バイト・レベルおよびサブバイト・レベルでパターンを検索し、バックアップ間の冗長なデータを消去します。たとえば、完全データベース・バックアップが1週間前のバックアップとほぼ同一である場合、ソフトウェアは、受け取るバックアップ・ストリームから冗長ビットを除去しようとします。

- ネットワーク・ロードを抑えるために、ソース側で重複除外を利用することもできます。この場合、バックアップ・ストリームはサードパーティ・アプライアンスではなくデータベース・ホスト上で重複除外されます。通常、この処理ではRMAN SBTプラグインを使用します。

デメリットは次のとおりです。

- これらのサードパーティ・アプライアンスではOracleデータベース・ブロックは認識されず、検証されません。アプライアンスの観点からは、データベース・バックアップはファイル・システムのバックアップと同じバイト・ストリームとして認識されます。

- 重複除外が有効になるのは、冗長性の高い完全データベース・バックアップのみです。多くの場合、増分バックアップを使用する計画では高い重複除外率が達成されることはありません。

- サードパーティ・アプライアンスによって、使用するOracle Databaseの機能が指定されます(逆ではありません)。多くの場合、アプライアンスの要件に従うことは、既存のバックアップ・スクリプトの再作成を意味します。

1.1.4 サードパーティの記憶域スナップショット

サードパーティの記憶域スナップショットは、スナップショットの作成時に存在していた記憶域ブロック(Oracleブロックではない)に対するポインタのセットです。この仮想コピーは、元のデータと同じストレージ・アレイに存在します。図1-4は、サードパーティ・スナップショットの1つであるcopy-on-writeスナップショットです。スナップショットが作成された後で、記憶域ブロックに対する最初の変更が発生すると、アレイは変更前イメージ・ブロック(C)をディスク上の別の場所にコピーし、新しいブロック(C')を元の場所に書き込みます。

図1-4 サードパーティのcopy-on-writeスナップショット

この方法には次のメリットがあります。

- データベースの初期コピーが必要ありません。スナップショットはブロックの物理コピーとして保存されるわけではないためです。したがって、RMAN計画に比べて使用される記憶域が少なくなります。

- スナップショットの処理は非常に高速です。データベースをバックアップ・モードにしてから(記憶域がスナップショット記憶域最適化の要件を満たさない場合を除く)、スナップショットを作成します。スナップショットが物理ブロックを格納する必要があるのはブロックが変更される場合のみです。つまり、変更されていないファイルのバックアップではメタデータしか処理されません。

- スナップショットは記憶域を効率よく使用します。1ブロックしか変更されていないファイルのバックアップでは、格納する必要があるのは該当ブロックのもう1つのバージョンのみです。スナップショットの方法に応じて、ブロックの古いバージョンか新しいバージョンが格納されます。

デメリットは次のとおりです。

- スナップショットは、Oracleデータベース・ブロック構造を認識していないため、Oracleブロックを検証できません。

- スナップショットはソース・データベースと同じストレージ・アレイに存在するため、記憶域の障害やデータ破損に対して脆弱です。アレイにアクセスできない場合、または記憶域にデータ・ブロックの破損が含まれる場合は、スナップショットをリカバリに使用できません。

- その場でスナップショットをリストアすると、そのスナップショットの後で作成されたすべてのスナップショットが無効になります。スナップショットは別の場所に完全にリストアする必要があります。

関連項目:

データベースのサードパーティ・スナップショットを作成するための記憶域スナップショット最適化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

1.2 現在のエンタープライズにおけるデータ保護の課題

現在のビジネスでの情報テクノロジの役割は、大きな転換期を迎えています。この転換を推し進める主な要因は次のとおりです。

- データの増大
多くの組織でデータの急激な増大が止まりません。このため、効率的なデータの管理と保護の必要性が高まっています。数十個のデータベースにふさわしい計画は、数百あるいは数千個のデータベースには適していない場合があります。多くの場合、これらは複数の物理サーバー上の様々なプラットフォームで稼働しています。

- リアルタイム分析
組織は、クリティカルなリアルタイム意思決定を行うためにデータ分析への依存度を増しています。このため、データ整合性を維持しデータ損失を防ぐことが求められています。

- 連続的なグローバル対応の高可用性
多くのデータベースは複数のタイムゾーンに対して24時間/週7日のアクセスを提供しています。つまり、データベースは絶えずアクティブな状態です。

「従来のデータベース・バックアップ方法」で説明した保護計画は、このような転換によって浮上した課題を解決するものではありません。エンタープライズは一貫したバックアップとリカバリの計画が欠けていたことを認識しています。従来のデータベース・バックアップ方法のほとんどまたはすべてに共通する欠点を次に示します。

- データ損失の危険性
データベースをリカバリできるのは、最も新しい有効なバックアップのみですが、それも数時間または数日前に作成されたものです。また、記憶域スナップショットとサードパーティ・アプライアンスは、Oracleデータ・ブロックを検証できず、Oracleブロックレベルの破損も検出できません。

- バックアップ・ウィンドウの長さ
データベースのサイズが大きくなると、バックアップ・ウィンドウも長くなり、本番システムの負荷が大きくなります。クリティカル・データベースは、毎日のバックアップやそれに伴う保守アクティビティにリソースを費やす余裕がありません。

- バックアップの検証の欠如
ほとんどのサードパーティ・バックアップ・スナップショットとリカバリ・アプライアンスには、Oracleに統合されているデータ・ブロックとデータベースのバックアップの検証機能がないため、リストアとリカバリの操作が失敗する可能性が高くなります。このような失敗によって停止時間が延長し、データ損失が拡大することもあります。

- 総合的な視野の欠如
データベースの数が急増すると、管理の容易性は低下します。バックアップ・スクリプトが増加して変化します。新しいDBAは、従来のスクリプトの実行内容の理解に苦労することがあります。特定のデータベースのステータス、バックアップの場所およびリカバリ・ポイントの目標(RPO)に関する質問に回答するのが難しくなります。

従来の方法では、大規模なエンタープライズのOracle環境の要求に応える、包括的で効率の高いOracle統合データ保護ソリューションは提供されません。新しいアプローチが求められています。

1.3 Oracleのリカバリ・アプライアンス・ソリューション

リカバリ・アプライアンスは、エンタープライズ全体のすべてのOracleデータベースを保護するように設計された、クラウド規模のエンジニアド・システムです。データベースのバックアップとリカバリのほとんどの処理は、集中管理されるリカバリ・アプライアンスで実行され、記憶域使用率、パフォーマンスおよびバックアップの管理性が向上します。

リカバリ・アプライアンスは、RMANの永久的増分計画を使用して、複数のOracle Databaseのバックアップを1つの統合ディスク・プールで格納および管理します。リカバリ・アプライアンスは、データベース・ブロック・レベルで継続的にバックアップの圧縮、重複解除および検証を行い、一方ではオンデマンドで仮想完全バックアップを作成します。

仮想完全バックアップは、1つのポイント・イン・タイムでの完全なデータベース・イメージです。リカバリ・アプライアンスによる保護データベースの増分バックアップのインデックス化を通じて、仮想完全バックアップは効率よく管理されます。仮想完全バックアップは、受け取ったどの増分バックアップにも対応できます。

図1-5に、サンプルのリカバリ・アプライアンス環境の概要を示します。

図1-5 リカバリ・アプライアンス環境

図1-5に示すように、保護データベースはデータをリカバリ・アプライアンスにバックアップするクライアント・データベースです。各保護データベースは、バックアップのためにZero Data Loss Recovery Applianceバックアップ・モジュール(リカバリ・アプライアンス・バックアップ・モジュール)を使用します。このモジュールは、RMANがネットワークを介したバックアップ・データのリカバリ・アプライアンスへの転送に使用する、Oracle提供のSBTライブラリです。

リカバリ・アプライアンス・メタデータ・データベース(各リカバリ・アプライアンスに存在する)は、RMANリカバリ・カタログに格納されるメタデータと、リカバリ・アプライアンスの記憶域の場所にあるバックアップを管理します。このカタログは、すべての保護データベースがバックアップをリカバリ・アプライアンスに送信するために必要です。

注意:

データベースは、リカバリ・アプライアンスをバックアップ・リポジトリとしては使用せずに、リカバリ・カタログとして使用できます。

管理者は、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用して環境を管理およびモニタリングします。Cloud Controlでは、バックアップが存在する場所(ディスク、テープまたは別のリカバリ・アプライアンス)にかかわらず、各データベースのバックアップ・ライフサイクル全体を一目で把握することができます。

リカバリ・アプライアンスには、次のメリットがあります。

- データ損失の解消

- 最小限のバックアップ・オーバヘッド

- データ保護の総合的な視点の強化

- クラウド規模の保護

関連項目:

「リカバリ・アプライアンス環境」

1.3.1 データ損失の解消

リカバリ・アプライアンスは様々なメカニズムを使用して、物理ブロック破損も含め、多様なデータ損失からデータを保護します。この項には次のトピックが含まれます:

- 実行中のトランザクションの保護

- セキュア・レプリケーション

- 自律型テープ・アーカイブ

- エンドツーエンド・データ検証

1.3.1.1 実行中のトランザクションの保護

従来のバックアップ方法では、オンラインREDOログが失われると、メディア・リカバリは、使用可能な最新のアーカイブREDOログ・ファイルまたは増分バックアップ以降のすべての変更を失います。従来の方法から導出した1日以上のリカバリ・ポイントの目標(RPO)を許容できないことがあります。

リカバリ・アプライアンスでは、保護されたデータベースからアプライアンスへのREDO変更を継続的に送信することより、RPOの問題を解決します。この操作は、リアルタイムREDOトランスポートと呼ばれています。デルタ・プッシュを使用するため、リカバリ・アプライアンスはOracle Database 11gおよびOracle Database 12cデータベースからの非同期REDOトランスポート・サービスのリモート宛先です。詳細は、「デルタ・プッシュ」を参照してください。

注意:

このテクノロジは、Oracle Data GuardのリアルタイムREDOトランスポート・アルゴリズムに基づいています。保護されたデータベースのパフォーマンスが低下しないようにするために、REDOはリカバリ・アプライアンスに非同期で転送されます。保護されたデータベースが失われると、ほとんどの場合、ゼロから1秒未満のデータ損失が予想されます。

関連項目:

- リアルタイムREDOトランスポートの詳細は、「リアルタイムREDOトランスポート」を参照してください

- Oracle Data GuardのREDOトランスポートの詳細は、『Oracle Data Guard概要および管理』を参照してください

1.3.1.2 セキュア・レプリケーション

サーバーまたはサイトの停電に備えて、あるリカバリ・アプライアンスから別のリカバリ・アプライアンスにバックアップをレプリケートできます。図1-6は、最も単純な形のレプリケーションである一方向リカバリ・アプライアンス・レプリケーションです。ここでは、アップストリーム・リカバリ・アプライアンス(バックアップの送信側)がダウンストリーム・リカバリ・アプライアンス(バックアップの受信側)にバックアップを送信しています。

図1-6 一方向レプリケーション

図1-6では、保護データベースは増分バックアップをリカバリ・アプライアンスに送信し、リカバリ・アプライアンスがそれをダウンストリーム・リカバリ・アプライアンスにレプリケートするためにキューに入れます。アップストリーム・リカバリ・アプライアンスが増分バックアップをダウンストリーム・リカバリ・アプライアンスに送信すると、通常どおりに仮想完全バックアップが作成されます。ダウンストリーム・リカバリ・アプライアンスがリカバリ・カタログにバックアップ・レコードを作成します。アップストリーム・リカバリ・アプライアンスがレコードをリクエストすると、ダウンストリーム・リカバリ・アプライアンスがレコードを伝播します。

ローカルのリカバリ・アプライアンスが仮想完全バックアップのリクエストに応じられない場合、そのリクエストをダウンストリーム・リカバリ・アプライアンスに転送します。そして、ダウンストリーム・リカバリ・アプライアンスが仮想完全バックアップを保護データベースに送信します。DBAは通常どおりRMANを使用します。バックアップ・セットが格納されている場所や方法を理解する必要はありません。

関連項目:

「リカバリ・アプライアンス・レプリケーション」

1.3.1.3 自律型テープ・アーカイブ

堅牢なバックアップ計画により、意図的な攻撃、不注意のユーザー・エラー(ファイル削除など)、ソフトウェアやハードウェアの障害からデータが保護されます。テープ・ライブラリは、このような可能性に対してデータを効率よく保護します。

図1-7に、各ホストにメディア・マネージャがインストールされた、従来のテープ・バックアップの方法を示します。

図1-7 リカバリ・アプライアンスを使用しないテープへのバックアップ

図1-8に、リカバリ・アプライアンスでのテープ・バックアップ方法を示します。これら2つの方法の根本的な違いは、保護データベースではなくリカバリ・アプライアンスがテープにバックアップすることです。リカバリ・アプライアンスは、事前にインストール済のOracle Secure Backupソフトウェアに含まれ、オプションでファイバ・チャネル・カードをサポートします。したがって、保護データベース・ホストにメディア・マネージャをインストールする必要はありません。

図1-8 リカバリ・アプライアンスを使用したテープへのバックアップ

リカバリ・アプライアンスが仮想完全バックアップのcopy-to-tapeジョブを実行するときは、物理バックアップ・セットを作成してから、それらをテープにコピーし、メタデータをリカバリ・カタログに書き込みます。必要であれば、リカバリ・アプライアンスで連続増分バックアップやアーカイブREDOログ・ファイルをテープにコピーすることもできます。リカバリ・アプライアンス上のバックアップが仮想であるのに対して、テープ上のバックアップは仮想ではない完全物理バックアップです。リカバリ・アプライアンスは、テープからバックアップをリストアするリクエストを自動的に処理します。管理者が操作する必要はありません。

リカバリ・アプライアンスのテープ・ソリューションのメリットは次のとおりです。

- リカバリ・アプライアンスが、テープにコピーするためのすべての処理を自動的に実行し、保護データベース・ホストにはパフォーマンス・ロードはかかりません。

- テープのバックアップは最適化されています。リカバリ・アプライアンスは、インテリジェント機能を使用して、テープ用の非仮想完全バックアップの作成に必要なブロックを収集します。

- Oracle Secure Backupが事前にインストール済であるため、サードパーティのメディア・マネージャにコストをかける必要がありません。

注意:

既存のテープ・バックアップ・ソフトウェアおよびプロセスと統合するためにサードパーティ・ベンダーのテープ・バックアップ・エージェントをデプロイしてもかまいません。この構成では、エージェントは専用のメディア・サーバーに接続する必要があり、そのメディア・サーバーはリカバリ・アプライアンスの外部にデプロイする必要があります。

- テープ・ドライブとテープ・ライブラリの効率が向上します。これは、リカバリ・アプライアンスが1つの大きな集中管理システムであり、テープ・ドライブとテープ・ライブラリを完全に制御できるためです。他のテープ・ソリューションでは、数百または数千のデータベースが協調せずにテープ・リソースを競合する可能性があります。

関連項目:

- リカバリ・アプライアンスでのテープへのバックアップのコピー

- 『Oracle Secure Backup管理者ガイド』

1.3.1.4 エンドツーエンド・データ検証

バックアップおよびリカバリの基本原則は、バックアップを正常にリストアできることです。バックアップされたデータ・ブロックに物理的な破損がないことを保証するために、バックアップを定期的に検証する必要があります。検証には通常、RMAN RESTORE VALIDATEジョブの定期的な実行と、別のマシンへの完全リストアおよびリカバリ操作の定期的な実行が含まれます。

リカバリ・アプライアンスによって提供されるエンドツーエンド・ブロック検証は、ワークフローの次のステージで行われます。

- リカバリ・アプライアンス検証
リカバリ・アプライアンスは、バックアップをディスクに書き込む前に、バックアップ収集フェーズでバックアップ・ストリームを自動的に検証します。リカバリ・アプライアンスは、また、リストア・フェーズ中にバックアップを元のまたは代替のデータベース・サーバーに送信する前に、バックアップを検証します。そのため、手動のRESTORE VALIDATEステップは必要ありません。

また、リカバリ・アプライアンスで実行しているバックグラウンド・タスクによって、デルタ・プール内の仮想完全バックアップの整合性が定期的に検証されます(「デルタ・プール」を参照)。このタスクの目標は、保護された各データベースのそれぞれの仮想完全バックアップの各ブロックを確認し、最小アクティビティが発生しているときにバックグラウンドで動作することです。デフォルトで、ディスク上のデータベースのバックアップの現在のセットの検証が最後に完了した後、検証タスクは14日ごとに実行されます。

データ・ファイルのバックアップの場合と同じように、Recovery Applianceは、すべての操作においてREDOログ・ブロックの整合性を検証します。これには、保護されたデータベースからREDOを受信し、これを圧縮されたアーカイブ・ログのバックアップ・セットに格納する処理が含まれます。

- Oracle Automatic Storage Management(ASM)
Oracle ASMはRecovery Applianceのためにバックアップ・データおよびREDOデータを格納します。Oracle ASMのミラー・コピーによって冗長性が実現します(「リカバリ・アプライアンスの記憶域の場所」を参照)。

プライマリ・ミラーで破損したブロックが読み取られた場合、リカバリ・アプライアンスはブロックをミラー・コピーから自動的に修復します。このメカニズムによって、切り離されたブロック破損ケースのほとんどが解決されます。

- テープ・ライブラリ
リカバリ・アプライアンスがブロックを検証するのは、テープにコピーするときと、テープからリストアするときです(「テープ・アーカイブ」を参照)。

- レプリケーション構成のダウンストリーム・リカバリ・アプライアンス
レプリケーションを構成すると、ダウンストリーム・リカバリ・アプライアンスがバックアップ収集フェーズとリストア・フェーズでデータを検証します(「ダウンストリーム・リカバリ・アプライアンスによるバックアップの処理方法」を参照)。

ここで説明したバックアップ検証プロセスはどれも本番データベース・ホストでは行われません。本番リソースはよりクリティカルな操作ワークロードのために解放されます。

注意:

Oracle最大可用性アーキテクチャのベスト・プラクティスでは、定期的な完全データベース・リカバリ・テストを実行して、操作の実践を確認し、メディア・リカバリ中にのみ発生する可能性のある問題を検出することをお薦めしています。

関連項目:

- validate_db_days構成パラメータの詳細は、「CONFIG」を参照してください。

- RA_DATABASE.LAST_VALIDATE列の詳細は、「RA_DATABASE」を参照してください。

1.3.2 最小限のバックアップ・オーバヘッド

「従来のデータベース・バックアップ方法」では、Oracle Databaseホストが処理の大半を実行します。ディスク・バックアップ、テープ・バックアップおよび重複除外のエージェントがすべてそのホストで実行することがあります。さらに、すべてのバックアップ操作(圧縮、検証、削除、マージなど)もデータベース・ホストで実行されます。このようなオーバーヘッドによってデータベースのパフォーマンスが大幅に低下する可能性があります。

リカバリ・アプライアンスによって、保護データベースから負荷のほぼすべてが取り除かれます。ホスト(プライマリ・データベース・ホストまたはスタンバイ・データベース・ホストである場合があります)に求められる唯一のバックアップ操作は、増分バックアップのRecovery Applianceへの送信のみです。永久的増分計画によって、データベース・ホストでのバックアップ・ウィンドウが大幅に短縮されます。リカバリ・アプライアンスが、バックアップ処理、テープ操作、データ整合性チェックおよびルーチン保守を行います。

注意:

リカバリ・アプライアンスは、Oracle Databaseのバックアップのみをサポートし、ファイル・システム・データおよびOracle以外のデータベースはサポートしません。

リカバリ・アプライアンスは、図1-9に示すようにデルタ・プッシュとデルタ・ストアを使用してデータベースの変更部分の管理を最適化します。デルタ・プッシュとデルタ・ストアによって、最終的にバックアップ・ウィンドウの長期化の問題が解消されます。DBAは高速増分バックアップのみを実行し、リカバリ・アプライアンスにバックアップ・ブロックの管理を任せます。

図1-9 デルタ・プッシュとデルタ・ストア

1.3.2.1 デルタ・プッシュ

このソリューションは、各保護データベースで実行される2つの操作で構成されます。永久的増分バックアップ計画とリアルタイムREDOトランスポートです(「データ損失の解消」を参照)。どちらの操作でも、保護データベースが変更部分をリカバリ・アプライアンスにプッシュします。

永久的増分計画では、各保護ファイルの存続期間でリカバリ・アプライアンスへの増分レベル0バックアップが1つのみ必要です。最初のレベル0バックアップには、コミットされたUNDOブロックおよび現在使用されていない内ブロックは含まれません。

注意:

コミットされたUNDOブロックおよび現在使用されていないブロックの除外は、リカバリ・アプライアンスまたはOracle Secure BackupへのSBTフル・バックアップに対してのみサポートされています。その他のバックアップ製品へのSBTバックアップでは使用できません。

通常の操作では、リカバリ・アプライアンスは増分レベル1バックアップごとに次の手順を自動的に実行します。

1. 各保護データベースから、スケジュール設定された増分レベル1バックアップを受け取ります。

2. 受信したバックアップを検証して、物理ブロック破損からデータを保護します。

3. 特別なブロックレベル・アルゴリズムを使用してバックアップを圧縮します。

4. バックアップをリカバリ・アプライアンスの記憶域の場所にあるデルタ・ストアに書き込みます。

永久的増分計画では、バックアップ・ウィンドウとオーバーヘッドが大幅に抑えられます。最初の増分レベル0バックアップの後では完全バックアップが必要ないためです。この計画にリアルタイムREDOトランスポートが含まれる場合、従来のアーカイブ・ログ・バックアップが必要なくなるため、バックアップ・ウィンドウはさらに短縮されます。また、リカバリ・アプライアンスは、検証、重複除外および圧縮の負荷を負担します。

注意:

表またはハイブリッド列圧縮を使用して圧縮したブロックは、RMANバックアップ内およびリカバリ・アプライアンスの収集フェーズ中圧縮されたままとなります。

1.3.2.2 デルタ・ストア

デルタ・ストアは、リカバリ・アプライアンスの主要な処理エンジンです。保護データベースは、データ・ファイルごとに増分レベル0バックアップを1つのみリカバリ・アプライアンスに送信します。最初の完全バックアップの後のすべてのバックアップは、非常に効率的な累積増分バックアップです。

リカバリ・アプライアンスは増分バックアップを受け取ると、インデックスを付けてデルタ・プールに格納します。リカバリ・アプライアンスにバックアップされる各データ・ファイルには、それぞれ独自のデルタ・プール(バックアップ・ブロックのセット)があります。リカバリ・アプライアンスは自動的にデルタ・プールを管理して、多数の仮想完全バックアップを提供できるようにします。

1.3.2.2.1 仮想完全バックアップの作成

仮想完全バックアップを作成するには、リカバリ・アプライアンスが、受け取った増分レベル1バックアップを、仮想の増分レベル0バックアップに変換します。仮想完全バックアップは、リカバリ・カタログでは増分レベル0バックアップとして示されます。ユーザーの観点からは、仮想完全バックアップは非仮想完全バックアップと区別できません。リカバリ・アプライアンスは、仮想バックアップを使用して、頻繁なレベル1バックアップのコストのみで頻繁なレベル0バックアップの保護を実現します。

注意:

リカバリ・アプライアンスによって記憶域サービスが提供されますが、仮想完全バックアップではなくRMAN暗号化バックアップ用です(「アーカイブ・バックアップと暗号化バックアップ」を参照)。これらのバックアップは元の暗号化形式で格納されます。リカバリ・アプライアンスは、暗号化されていないRMANバックアップ・セットと同様にそれらの格納、アーカイブおよび取出しを行うことができます。

1.3.2.2.2 仮想完全バックアップを使用した高速リカバリ

リカバリ・アプライアンスは仮想完全バックアップを使用して、リカバリ対象のデータ容量にかからわらず、任意のポイント・イン・タイムへの高速リカバリを提供します。リカバリ・アプライアンスのオンディスク・リカバリ計画のメリットは、RMANが増分バックアップを適用しないで仮想完全バックアップを任意のポイント・イン・タイムにリカバリできることです。

データベースがリカバリ・アプライアンスによって保護されている場合、RMANが行う必要があるのは、RPOの日の単一のレベル0バックアップをリストアし、リアルタイムREDOトランスポート機能を使用して送信されたREDOログ・ファイルを使用して最新の時点にリカバリすることのみです。たとえば、リカバリ・ウィンドウが7日間で、RPOが5日前の場合、RMANは単一の最新仮想完全バックアップ(レベル0)を5日前にリストアしてから、REDO (レベル1増分バックアップではない)を使用してリカバリできます。

関連項目:

- 「デルタ・ストア」

- 永久的増分バックアップ計画の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

- リカバリ計画の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

- 増分バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

1.3.3 データ保護の総合的な視点の強化

「従来のデータベース・バックアップ方法」では、多くの場合、データベース、メディア・サーバーおよびテープ・ドライブの管理が切り離されています。たとえば、DBAグループがデータベースを管理し、別のバックアップ管理者グループがバックアップを管理し、記憶域グループがディスクおよびテープ・デバイスを管理します。プロセス全体を見通しにくいため、リカバリ要件がそれぞれ異なる、数千に及ぶデータベースのバックアップを管理することは難しくなります。

Cloud Controlを使用すると、リカバリ・アプライアンスによって管理されるバックアップのライフサイクル(RMANバックアップがデータベースで開始されたときから、ディスクやテープに格納されるまで、またはダウンストリーム・リカバリ・アプライアンスにレプリケートされるまで)の全貌を完全に把握できます。Zero Data Loss Recovery Applianceプラグイン(リカバリ・アプライアンス・プラグイン)用のEnterprise Managerインストールによって、リカバリ・アプライアンスのモニタリングと管理が有効になります。

Cloud Controlを使用してリカバリ・アプライアンスを管理すると次のメリットがあります。

- 標準メトリック(バックアップ全体のパフォーマンス、集計またはデータベースごとの領域消費量など)

- バックアップやリカバリ・アプライアンスの問題に関する即時アラート
たとえば、定義されたRPOを満たすバックアップがない場合またはバックアップの破損が検出された場合に、Cloud Controlが管理者にアラートを通知することができます。

- ステータス・レポート(BI Publisherによる)は容量計画に役立ちます。また、リカバリ・ウィンドウ目標を達成できない保護データベースを特定することもできます。
たとえば、リカバリ・アプライアンスの管理者は、領域とネットワーク使用率の履歴に関するレポートを受け取って、バックアップのボリュームとスループットの傾向を確認することができます。これらの傾向に基づいて、既存ラックへのストレージ・サーバーの追加や追加ラックの接続が必要になります。

Cloud Controlはリカバリ・アプライアンス管理の推奨ユーザー・インタフェースですが、コマンドラインから使用できるDBMS_RA PL/SQLパッケージも提供されています(「DBMS_RAパッケージ・リファレンス」を参照)。このマニュアルのほとんどのタスクでは、Cloud ControlとDBMS_RA両方の方法を説明しています。コマンドラインからモニタリングとレポート作成を実行するには、リカバリ・アプライアンスのカタログ・ビューを問い合せてください(「リカバリ・アプライアンスのビュー・リファレンス」を参照)。

関連項目:

リカバリ・アプライアンスのためのCloud Controlスタート・ガイド

1.3.4 クラウド規模の保護

リカバリ・アプライアンスがクラウド・レベルに拡張されると、数十から数百、さらにはデータ・センターの数千のデータベースをサポートするようになります。基本的に、リカバリ・アプライアンスを使用するとエンタープライズ内にプライベートなデータ保護クラウドを作成できます。リカバリ・アプライアンス内の次のテクノロジ・コンポーネントによってこれが可能になります。

- ポリシーベースのデータ保護管理

- データベース認識領域管理

- スケーラブルなアーキテクチャ

1.3.4.1 ポリシーベースのデータ保護管理

リカバリ・アプライアンスは保護ポリシーを使用して管理を単純化します。次の利点があります。

- 保護ポリシーは、リカバリ・アプライアンスまたはテープ・デバイスへのバックアップに関して各データベースに適用されるリカバリ・ウィンドウ目標を定義します。
保護ポリシーを使用すると、リカバリ・サービス階層ごとにデータベースをグループ化できます。たとえば、プラチナ・ポリシーで保護されているデータベースでは、バックアップをリカバリ・アプライアンスで45日間、テープで90日間保持する必要がありますが、これは、経過期間が45日間以下のバックアップはディスクとテープに存在するが、45日間を超えるバックアップはテープにのみ存在することを意味します。ゴールド・ポリシーで保護されるデータベースは、バックアップをローカル・リカバリ・アプライアンスには35日間、テープには90日間保存する必要があります。領域の消費を制限するため、または指定期間を超えてバックアップを保存できないことを規定するサービス・レベル合意に準拠するために、必要に応じて、各ポリシーに最長保存期間を定義することもできます。

- 保護ポリシーは、データベースをグループ分けして管理性を向上させるための手段です。
たとえば、特定の保護ポリシーでリカバリ・アプライアンスのレプリケーションまたはcopy-to-tapeを構成できます。こうすると、このポリシーが関連付けられたすべてのデータベースにその構成が適用されます。データベースをポリシーに追加すると、データベースは自動的にポリシーの構成とスケジュールを継承します。

関連項目:

- 「保護ポリシー」

- リカバリ・アプライアンスでの保護ポリシーの管理

1.3.4.2 データベース認識領域管理

リカバリ・アプライアンスは保護ポリシーを使用し、各保護データベースのリカバリ・ウィンドウ目標に合せて、バックアップ記憶領域を管理します。このきめ細かいデータベース指向の領域管理方法により、サードパーティのアプライアンスで行われているように記憶域ボリューム・レベルで領域を管理する必要がなくなります。

領域が使用可能な場合、リカバリ・アプライアンスはリカバリ・ウィンドウ目標よりも古いバックアップを保存でき、ポイント・イン・タイム・リカバリ期間を効率よく延長できます。領域が不足している場合、リカバリ・アプライアンスは定義済のしきい値を使用してバックアップをパージします。リカバリ・アプライアンスは、各データベースのリカバリ・ウィンドウ目標を満たすように、領域を自動的にプロビジョニングします。

関連項目:

「リカバリ・アプライアンスによる記憶域の管理方法」

1.3.4.3 スケーラブルなアーキテクチャ

「従来のデータベース・バックアップ方法」のアプローチでは、パフォーマンス・ボトルネックや障害点の多重化が発生しがちです。データベース数が増えるにつれ、メディア・サーバー、ディスク・アレイ、テープ・デバイスおよびサードパーティ・アプライアンスの数も増え、全体が複雑になります。「デバイスを追加する」アプローチはスケーラブルではありません。対照的に、リカバリ・アプライアンスは、計算や記憶領域のリソースを単純なモジュラー形式で追加することで、バックアップ・トラフィック、記憶域使用率、データベース数の増加に対応するように拡張できます。

関連項目:

ストレージ・サーバーの追加の詳細は、Zero Data Loss Recovery Applianceオーナーズ・ガイドを参照してください。

1.3.5 最大可用性: Oracle Data Guardと連携するリカバリ・アプライアンス

Oracle Data Guardは、リカバリ・アプライアンスと統合できる高可用性(HA)および障害回復のソリューションのコンポーネントであり、最大限のデータ保護を提供します。Oracle Data Guardは、保護されたデータベースの同期化されたスタンバイ・データベースを維持することによって、サービス中断および生じたデータ損失を最小限に抑えます。プライマリ・システムを使用できない場合、ローカルのリカバリ・アプライアンスへのバックアップを含め、Data Guardのフェイルオーバー操作後、スタンバイ・システムが即座にプライマリ・システムの通常操作を行います。図1-10に、リカバリ・アプライアンスとOracle Data Guardの環境の例を示します。

図1-10 Oracle Data Guardと連携するリカバリ・アプライアンス

図1-10では、プライマリ・データベースとスタンバイ・データベースがそれぞれ、ローカルのリカバリ・アプライアンスに増分バックアップを送信します。プライマリ・データベースはリアルタイムREDO変更をローカルのリカバリ・アプライアンスとフィジカル・スタンバイの両方に送信し、スタンバイ・データベースはREDO変更をリモートのリカバリ・アプライアンスにカスケードします。各リカバリ・アプライアンスには同じデータベースのバックアップおよびREDO情報が存在するため、いずれかのアプライアンスをRMANリストアおよびリカバリ操作に使用できます。

関連項目:

- Oracle Data Guardと連携するリカバリ・アプライアンスの詳細は、http://www.oracle.com/technetwork/database/availability/disaster-recovery-2526839.pdfを参照してください

- Oracle Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照してください。

1.4 次に行うこと

リカバリ・アプライアンスの使用を開始するには、次のトピックを参照してください。

1. 「リカバリ・アプライアンスのアーキテクチャ」を読んで、リカバリ・アプライアンス環境の主なコンポーネントに対する理解を深めます(オプション)。

2. 「リカバリ・アプライアンスのワークフロー」を読んで、基本的なツールとタスクについて学びます。データ保護のためにリカバリ・アプライアンスを使用するには、その前に次のトピックで説明するタスクを実行する必要があります。

a. 「リカバリ・アプライアンスの計画」

b. 「リカバリ・アプライアンスの設定と構成」

c. 「Recovery Applianceのメンテナンス・タスク」

2 リカバリ・アプライアンスのアーキテクチャ

この章では、一般的にリカバリ・アプライアンスと呼ばれるZero Data Loss Recovery Applianceの基本的なアーキテクチャと概念について説明します。

この章の内容は次のとおりです。

- リカバリ・アプライアンス環境

- 保護データベース

- リアルタイムREDOトランスポート

- リカバリ・アプライアンスのメタデータ・データベース

- リカバリ・アプライアンスの記憶域

- Oracle Secure Backup

- リカバリ・アプライアンス・レプリケーション

- データ暗号化手法

2.1 リカバリ・アプライアンス環境

最小のリカバリ・アプライアンス環境は、リカバリ・アプライアンスと1つの保護データベースで構成されます。図2-1に示すサンプル環境は典型的なものです。

図2-1 サンプル・リカバリ・アプライアンス環境

この項には次のトピックが含まれます:

- リカバリ・アプライアンス環境の主要コンポーネント

- リカバリ・アプライアンス環境のユーザー・アカウント

- バックアップのライフサイクル: シナリオ

2.1.1 リカバリ・アプライアンス環境の主要コンポーネント

図2-1に示す典型的なリカバリ・アプライアンス環境の例には、次のコンポーネントが含まれています。

- 複数の保護データベース
各保護データベースは、バックアップとリアルタイムREDOをリカバリ・アプライアンスに送信します(「保護データベース」を参照)。保護データベースは様々なリリースのOracle Database上で稼働できます。たとえば、混在環境に、Oracle Database 10g、Oracle Database 11gおよびOracle Database 12cの保護データベースが含まれることがあります。

- リカバリ・アプライアンス
図2-1の中央のリカバリ・アプライアンスは、増分バックアップとリアルタイムREDOを保護データベースから受信します。リカバリ・アプライアンスにはリカバリ・アプライアンス・メタデータ・データベースが含まれます(「リカバリ・アプライアンスのメタデータ・データベース」を参照)。このデータベースのコンポーネントは、次のとおりです。

- RMANリカバリ・カタログ。これは複数の仮想リカバリ・カタログにさらに分割されます(「リカバリ・アプライアンス・カタログ」を参照)。

- 1つ以上の記憶域の場所(「リカバリ・アプライアンスの記憶域」を参照)。リカバリ・アプライアンスの記憶域にデルタ・ストアが含まれ、ここに複数のデルタ・プールがあります(「デルタ・ストア」を参照)。

図2-1では、中央のリカバリ・アプライアンスが第2リカバリ・アプライアンスにバックアップをレプリケートし、さらに第2リカバリ・アプライアンスが第3リカバリ・アプライアンスにそれらのバックアップを転送しています(「リカバリ・アプライアンス・レプリケーション」を参照)。

- Oracle Enterprise Manager Cloud Control (Cloud Control)
図2-1では、環境内の独立したサーバーでCloud Controlが稼働しています。管理者はCloud Controlを使用して、リカバリ・アプライアンス環境内のすべてのリカバリ・アプライアンス、保護データベースおよびテープ・デバイスを管理できます。

- DBMS_RA PL/SQLパッケージ
これは、リカバリ・アプライアンスのコマンドライン・インタフェースです(「DBMS_RAパッケージ・リファレンス」を参照)。このパッケージは、リカバリ・アプライアンス・メタデータ・データベースに格納され、Cloud Controlの基本的な機能を提供します。

- Oracle Secure Backup
図2-1では、リカバリ・アプライアンスがOracle Secure Backupを使用してバックアップをテープ・ライブラリにアーカイブしています。この図では、ダウンストリーム・リカバリ・アプライアンスも別のテープ・ライブラリにバックアップをアーカイブしています。

2.1.2 リカバリ・アプライアンス環境のユーザー・アカウント

リカバリ・アプライアンス環境の中心コンポーネントは、保護データベース、リカバリ・アプライアンスおよびCloud Controlです。表2-1に、この環境で最も重要なユーザー・アカウントをまとめています。

表2-1 リカバリ・アプライアンス環境のユーザー・アカウント

コンポーネント

アカウント・タイプ

ユーザー名

説明

Cloud Control

Cloud Controlスーパーユーザー

SYSMAN

このアプリケーション・アカウントはデフォルトで存在します。目的は、Cloud Controlそのものの管理です。リカバリ・アプライアンスや保護データベースの管理には直接関係ありません。

Cloud Control

Cloud Control管理者

ユーザー指定

特定の保護データベースまたは特定のリカバリ・アプライアンスの管理に必要な役割と権限を付与されたCloud Controlユーザー・アカウント。ビジネス要件によっては複数のCloud Control管理者アカウントを設定できます。

リカバリ・アプライアンス

リカバリ・アプライアンス・メタデータ・データベース・スーパーユーザー

SYS

SYSはリカバリ・アプライアンスのユーザー・アカウントを作成できます。ただし、通常はそれ以外のリカバリ・アプライアンスの管理には使用されません。

リカバリ・アプライアンス

リカバリ・アプライアンス管理者

RASYS

このデータベース・アカウントは、RMANリカバリ・カタログとDBMS_RA PL/SQLパッケージを含むリカバリ・アプライアンス・スキーマを所有します(「DBMS_RAパッケージ・リファレンス」を参照)。RASYSユーザー名は固定されており、変更できません。RASYSには、データベース・ユーザー・アカウントを作成するために必要な権限はありません。

リカバリ・アプライアンス

リカバリ・アプライアンス・ユーザー・アカウント

ユーザー指定

このアカウントには、リカバリ・アプライアンスに登録されたデータベースのバックアップを送受信し、それらのデータベースのリカバリ・カタログ・メタデータを操作する権限があります。これは、保護されたデータベースからリカバリ・アプライアンスにREDOデータを送信するために使用するアカウントでもあります。RASYSとは異なり、リカバリ・アプライアンス・ユーザー・アカウントには、リカバリ・アプライアンスにおける管理権限はありません。

通常、リカバリ・アプライアンス・メタデータ・データベースには複数のリカバリ・アプライアンス・ユーザー・アカウントが含まれます。これらのアカウントは、保護データベースへのアクセスを構成するときに作成されます(「保護されたデータベース・アクセスのためのリカバリ・アプライアンスの構成」を参照)。

すべてのリカバリ・アプライアンス・ユーザー・アカウントは仮想プライベート・カタログを所有します。カタログ所有者がアクセスして変更できるのは、アクセス権が認められているデータベースに関連するリカバリ・カタログ内の行のみです。これは、RMAN CONNECT CATALOGコマンドで参照されるデータベース・ユーザー名です。

保護データベース

保護データベース・バックアップ管理者

SYSBACKUP (SYSBACKUPがサポートされないリリースではSYSDBA)権限を持つユーザー・アカウント。

このアカウントには、保護データベースのバックアップ、リストアおよびリカバリを行う権限があります。これは、RMAN CONNECT TARGETコマンドで参照されるデータベース・ユーザー名です。

図2-2に、RASYSと2つのリカバリ・アプライアンス・ユーザー・アカウントの関係を示します。この例では、各リカバリ・アプライアンス・ユーザー・アカウントが個別の仮想プライベート・カタログを所有しています。リカバリ・アプライアンス・スキーマの所有者であるRASYSは、RMANリカバリ・カタログの所有者でもあることに注意してください。

図2-2 RASYSとリカバリ・アプライアンス・ユーザー・アカウント

関連項目:

データベース・ユーザー・アカウントの作成方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

2.1.3 バックアップのライフサイクル: シナリオ

この項では、図2-1に示すリカバリ・アプライアンス環境でのバックアップの流れにそって、バックアップのライフサイクルを説明します。このサンプル・シナリオでは、各保護データベースは必須である最初のレベル0増分バックアップをリカバリ・アプライアンスにすでに格納しています。基本的なデータ・フローは次のとおりです。

1. 保護データベース、またはこのデータベースを保護しているスタンバイ・データベースが、レベル1増分バックアップをRecovery Applianceに送信します。
リカバリ・アプライアンスが他のバックアップ・ソリューションと異なる点は、データ・ファイルごとにレベル0バックアップが1つしか必要ないことです。レベル1増分バックアップは、変更時にデータ・ブロックのみがバックアップされるため最も効率的です。

累積レベル1増分バックアップの作成をお薦めします(『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照)。各累積レベル1バックアップでは、ベースラインとして最新の仮想レベル0バックアップが使用されます。通常、この仮想レベル0バックアップは、最新のレベル1バックアップに相当します。

注意:

レベル1累積バックアップをRecovery Applianceに組み込めない場合(記憶域の破損などにより)、次のレベル1バックアップが同じ仮想レベル0ベースラインを持つため、Recovery Applianceは新しいレベル1増分バックアップをシームレスに組み込めます。このため、累積バックアップは、差分バックアップよりも多いオーバーヘッドを持つことはほとんどありません。

2. リカバリ・アプライアンスが増分バックアップを受信します。
受信したバックアップをすぐに取り出すことができますが、リカバリ・アプライアンスがまだインデックスを付けていません。したがって、対応する仮想完全バックアップはまだありません。リカバリ・アプライアンスがインデックスを付ける前に、保護データベースのリカバリにこのバックアップが必要になった場合、RMANは前の仮想完全バックアップを自動的にリストアし、この増分バックアップを適用します。

3. リカバリ・アプライアンスが増分バックアップを処理します。
次の操作は非同期で行われます。

- リカバリ・アプライアンスが、バックアップ収集を実行します。リカバリ・アプライアンスは次のようにバックアップを処理します。

- 保護データベースから送信されたバックアップをスキャンします。

- 少数のブロックからなるグループに分割して、各データ・ファイルのブロックを個別のデルタ・プールに割り当てます(「デルタ・ストア」を参照)

- データベースの保護ポリシ-に応じて、グループを適切な記憶域の場所に書き込みます(「リカバリ・アプライアンスの記憶域の場所」を参照)

- 仮想バックアップ・セットが作成されたら、元のバックアップ・セットを削除します。

注意:

リカバリ・アプライアンスが、仮想バックアップの作成と同時に元のバックアップを削除できない場合があります。このため、元のバックアップと仮想バックアップの両方が、リカバリ・カタログ内で2つのコピーとして短時間同時に存在する可能性があります。

バックアップ収集時に、リカバリ・アプライアンスはバックアップのインデックスを付けます。この処理では、各データ・ブロックの内容と物理的な場所に関する情報をメタデータ・データベースに格納します。リカバリ・アプライアンスは保護データベースのリカバリ・カタログを含むため、これで新たにインデックス付けした仮想完全バックアップをRMANが使用できるようになります(リカバリで必要となる場合)。

- リカバリ・アプライアンス・レプリケーションが構成されている場合、リカバリ・アプライアンスはバックアップをダウンストリーム・リカバリ・アプライアンスに転送します。
多くの異なるレプリケーション構成が可能です(「リカバリ・アプライアンスでのバックアップのレプリケート」を参照)。図2-1には、1対1の構成が示されています。中央のリカバリ・アプライアンスがアップストリーム・リカバリ・アプライアンス(バックアップの送信側)として、ダウンストリーム・リカバリ・アプライアンス(バックアップの受信側)として機能する別のリカバリ・アプライアンスにバックアップを転送します。図2-1には、ダウンストリーム・リカバリ・アプライアンスがバックアップを第3のリカバリ・アプライアンスに転送するカスケード・レプリケーションも示されます。

- 自動のcopy-to-tapeポリシーが有効になっている場合、リカバリ・アプライアンスがバックアップをテープにアーカイブします。
図2-1では、中央のリカバリ・アプライアンスがOracle Secure Backupソフトウェアを使用してテープ・デバイスと通信しています。また、レプリケーション・スキームで最もダウンストリーム側にあるリカバリ・アプライアンスもバックアップをテープにアーカイブしています。この方法には次のメリットがあります。

- 冗長性を実現するために、同一のバックアップが2つのテープ・デバイスに存在します。図2-1では、プライマリ・リカバリ・アプライアンスと最もダウンストリーム側のリカバリ・アプライアンスがテープにアーカイブしています。

- ダウンストリーム・リカバリ・アプライアンスがテープにバックアップすることで、アップストリーム・リカバリ・アプライアンスのテープ・アーカイブ処理の負担を軽減できます。

- Recovery Applianceは、バックアップおよびREDOが有効であることを定期的に確認します。
Recovery Applianceは、ディスクにあるバックアップを、インバウンド・レプリケーションとアウトバウンド・レプリケーション中に自動的に検証します。Recovery Applianceは、テープ・バックアップのクロスチェックを自動的に実行します。データ・ファイルのバックアップの場合と同じように、Recovery Applianceは、すべての操作においてREDOログ・ブロックの整合性を検証します。これには、保護されたデータベースからREDOを受信し、これを圧縮されたアーカイブ・ログのバックアップ・セットに格納する処理が含まれます。RMAN VALIDATEコマンドを手動で実行する必要はありません。

- リカバリ・アプライアンスが、自動デルタ・プール領域管理を実行します。
このフェーズでは、ディスクとテープ両方で不要になったバックアップや期限切れになったバックアップの削除や、デルタ・プールの最適化が行われます(「自動デルタ・プール領域管理」を参照)。

関連項目:

増分バックアップの作成方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2.2 保護データベース

保護データベースは、集中管理されるRMANバックアップおよびリカバリの宛先として、特定のリカバリ・アプライアンスを使用します。図2-1では、集中管理されている1つのリカバリ・アプライアンスに複数の保護データベースがバックアップを送信しています。リカバリ・アプライアンスによって保護される各データベースは、リカバリ・アプライアンス・メタデータ・データベースにあるリカバリ・カタログを使用する必要があります。

保護データベースがバックアップをリカバリ・アプライアンスに送信するには、リカバリ・アプライアンスにアクセスできるように構成する必要があります。構成には、適切なリカバリ・アプライアンス・ユーザーおよび権限の作成、保護された各データベースと保護ポリシーの関連付け、および各データベースへのリカバリ・アプライアンス接続の資格証明の配布が含まれます。

この項には次のトピックが含まれます:

- リカバリ・アプライアンス・バックアップ・モジュール

- 保護ポリシー

- サポートされるOracle Databaseリリース

2.2.1 リカバリ・アプライアンス・バックアップ・モジュール

Zero Data Loss Recovery Applianceバックアップ・モジュール(リカバリ・アプライアンス・バックアップ・モジュール)は、RMANがバックアップ・データをネットワークを介してリカバリ・アプライアンスに転送するために使用する、Oracle提供のSBTライブラリです。SBTライブラリは、バックアップ・デバイスのタイプ(テープ・デバイスまたはリカバリ・アプライアンス)との間でデータをやりとりします。RMANは、このモジュールを使用して、リカバリ・アプライアンスへのすべてのバックアップと完全なバックアップ・セットのすべてのリストアを実行します。

リカバリ・アプライアンス・バックアップ・モジュールは次の場所にインストールする必要があります。

- リカバリ・アプライアンスにバックアップを送信するすべての保護データベースのOracleホーム
たとえば、1つのホストにOracle Database 11g OracleホームとOracle Database 12c Oracleホームがあるとします。各Oracleホームがそれぞれ5つの保護データベースをサポートし、このホストで合計10個のデータベースが実行しています。このケースでは、インストールする必要があるリカバリ・アプライアンスは2つのみ(各Oracleホームに1つずつ)です。

- リカバリ・アプライアンス・レプリケーション環境の場合、ダウンストリーム・リカバリ・アプライアンスにバックアップを送信するすべてのアップストリーム・リカバリ・アプライアンス(「リカバリ・アプライアンスでのバックアップのレプリケート」を参照)

図2-3では、同一のホストでOracle Database 11gとOracle Database 12cの保護データベースが実行しています。各Oracleホームにインストールされたリカバリ・アプライアンス・バックアップ・モジュールがリカバリ・アプライアンスと通信して、バックアップをダウンストリーム・リカバリ・アプライアンスにレプリケートします。

図2-3 リカバリ・アプライアンス・バックアップ・モジュール

関連項目:

- リカバリ・アプライアンス・バックアップ・モジュールのインストール方法の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください

- SBTのチャネルとデバイスの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2.2.2 保護ポリシー

保護ポリシーは、プロパティのコレクションに名前を付けたもので、複数の保護データベースに割り当てることができます。複数のデータベースに1つのポリシーを使用することで、リカバリ・アプライアンスの管理時間を短縮し、1回の操作で複数の保護データベースのプロパティを変更できます。多様なバックアップとリカバリの要件を備えたデータベースに対応するために、必要な数の保護ポリシーを作成します。

リカバリ・アプライアンスのデフォルト・インストールの保護ポリシーを表2-2に示します。

表2-2 デフォルト保護ポリシー

サービス階層

リカバリ・ウィンドウ

追加設定

プラチナ

ディスクに45日間、テープに90日間脚注 1

データベース・バックアップ、リアルタイムREDOトランスポート、レプリケーションおよびテープ・バックアップ。すべての設定が必須です。

ゴールド

ディスクに35日間、テープに90日間

データベース・バックアップ、リアルタイムREDOトランスポート、レプリケーションおよびテープ・バックアップ(テープが使用可能な場合)。

シルバー

ディスクに10日間、テープに45日間

データベース・バックアップ、リアルタイムREDOトランスポートおよびテープ・バックアップ(テープが使用可能な場合)。

ブロンズ

ディスクに3日間、テープに30日間

データベース・バックアップおよびテープ・バックアップ(テープがある場合)。リアルタイムREDOトランスポートはありません。

脚注1

経過期間が45日間以下のバックアップはディスクとテープの両方に存在しますが、経過期間が45日間を超えるバックアップはテープにのみ存在します。リカバリ・アプライアンスは、ディスクのバックアップ後ただちにテープ・バックアップを作成するため、90日間のテープ保存期間は45日間のディスク保存期間と同時に開始します。

関連項目:

- リアルタイムREDOトランスポートの構成方法の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

- Oracle最大可用性アーキテクチャ(MAA)のサービス層の詳細は、http://www.oracle.com/technetwork/database/availability/maa-reference-architectures-2244929.pdfを参照してください

2.2.2.1 保護ポリシーの属性

DBMS_RA.CREATE_PROTECTION_POLICYプロシージャまたはCloud Controlを使用して作成する保護ポリシーは、割り当てられるすべての保護データベースに次の属性を設定します。

表2-3 保護ポリシーの属性

属性

説明

storage_location_name

バックアップを格納するリカバリ・アプライアンスの記憶域の場所

polling_policy_name

オプションのバックアップ・ポーリング・ポリシー。リカバリ・アプライアンスが記憶域の場所をポーリングしてバックアップを探すかどうかを決定します。

recovery_window_goal

保護データベースのディスク・リカバリ・ウィンドウ目標

recovery_window_sbt

保護データベースのSBT保存期間

guaranteed_copy

コピー保証設定。このポリシーで保護されるバックアップの削除が検討される前に、テープにコピーするかレプリケートするかを決定します。

max_retention_policy

この保存ポリシーを使用するデータベースのバックアップをリカバリ・アプライアンスが保存する最長期間

unprotected_window

現在時刻からデータベースをリストアできる最短時刻までの最長許容時間

オプションのレプリケーション・サーバー構成を保護ポリシーに関連付けることができます。レプリケーション構成は、保護ポリシーが関連付けられているすべての保護データベースに適用されます。

関連項目:

- 「DBMS_RAを使用した保護ポリシーの作成」

- 「レプリケーションの保護ポリシー」

- 「CREATE_PROTECTION_POLICY」

2.2.2.2 リカバリ・ウィンドウ

保護ポリシーを作成するときに、期間(通常は日数)を表す次の2つのリカバリ・ウィンドウ属性を定義できます。

- ディスク・リカバリ・ウィンドウ目標
ポリシーに割り当てられるデータベースごとに、リカバリ・アプライアンスは、現在の時刻からさかのぼって、この期間の任意の時点へのポイント・イン・タイム・リカバリをサポートしようとします(「リカバリ・ウィンドウ目標」を参照)。たとえば、リカバリ・ウィンドウ目標が15日間で、現在の日時が4月25日正午の場合、4月10日正午以降の任意の時点にポイント・イン・タイム・リカバリを実行することが目標です。4月26日正午であれば、4月11日正午以降の任意の時点にポイント・イン・タイム・リカバリを実行することが目標になります。

ディスクの場合、この期間は目標であり、保証されるものではありません。ディスク領域が少なくなり、目標が達成できない状況が発生すると、リカバリ・アプライアンスはバックアップをパージすることがあります。各保護データベースの予約済ディスク領域のプロパティを調整して、バックアップの最小数を保証できます(『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照)。

- SBT保存期間
現在の日時からさかのぼって、この期間内の任意の時点へのポイント・イン・タイム・リカバリに対応できるように、割り当てられたデータベースごとのバックアップがテープに保存されます(「テープでのバックアップ保存」を参照)。SBTの場合、この期間は保証されます。

関連項目:

リカバリ・ウィンドウの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2.2.2.3 バックアップ・ポーリング・ポリシー

バックアップ・ポーリング・ポリシーの指定内容は次のとおりです。

- リカバリ・アプライアンスが処理するバックアップを探すためにポーリングする、共有記憶域上のファイル・システム・ディレクトリ(「バックアップ・ポーリングの場所」を参照)

- リカバリ・アプライアンスがポーリングする間隔

- バックアップ・データを正常に処理した後で削除するかどうか

保護ポリシーを使用してバックアップ・ポーリング・ポリシーを保護データベースに割り当てます。必要に応じて、各保護ポリシーが1つのポーリング・ポリシーを参照できます。

関連項目:

「バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)」

2.2.3 サポートされるOracle Databaseリリース

各リリースで使用可能な機能を含め、リカバリ・アプライアンスでサポートされているOracle Databaseリリースの詳細は、My Oracle SupportノートのドキュメントID 1995866.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=1995866.1)を参照してください。

2.3 リアルタイムREDOトランスポート

REDOデータにはデータベースに加えられたすべての変更の記録が格納されるので、データ障害が発生した場合のデータ損失を最小限に抑えるために不可欠です。リカバリ・アプライアンスのリアルタイムREDOトランスポート機能を使用すると、連続するアーカイブREDOログのバックアップ間でデータ損失の危険にさらされる期間が大幅に短くなります。リアルタイムREDOトランスポートを有効にすると、通常のRPOは0から1秒未満の値です。

図2-4に、増分バックアップとREDOログをリカバリ・アプライアンスに送信する保護されたデータベースを示します。

図2-4 REDOログの送信

リアルタイムREDOトランスポートを有効にすると、保護されたデータベースはメモリー内にREDO変更を生成してから、すぐにリカバリ・アプライアンスに転送します。リカバリ・アプライアンスはそれを検証し、ステージング領域に書き込みます。

保護データベースがオンラインREDOログ切替えを実行すると、リカバリ・アプライアンスはREDO変更を変換して、圧縮されたアーカイブREDOログ・ファイル・バックアップにアセンブルしますRecovery Applianceカタログは、リカバリ・カタログ内のこれらのアーカイブREDOログ・バックアップを自動的に追跡します。RMANは、これらのアーカイブREDOログ・バックアップを通常どおりにリストアおよび適用できます。このメリットは次のとおりです。

- REDOストリームが予期せず終了した場合、リカバリ・アプライアンスは、受信中のREDOストリームを終了して、部分的なアーカイブREDOログ・ファイル・バックアップを作成できます。これにより、アプライアンスが受信した直近の変更までトランザクションが保護されます。リカバリ・アプライアンスはREDOストリームの再開を検出した時点で、欠落しているすべてのアーカイブREDOログ・ファイルを保護データベースから自動的に取得します。このように、リカバリ・アプライアンスによってリカバリ・ウィンドウ目標が守られます。

- Recovery Applianceは、リアルタイムREDOログをアーカイブREDOログ・ファイルに自動的に変換するため、アーカイブREDOログ・ファイルをデータベース・ホストからRecovery Applianceにバックアップする必要はありません。

Recovery Applianceは、受信するREDOを、保護されたデータベースによって送信されたバックアップには適用しません。このため、更新された仮想レベル0バックアップの提供を続行するために、Recovery Applianceは新しい増分バックアップをデルタ・ストアに組み込む必要があります。アプライアンスでは、保護されたデータベースが送信したレベル1増分バックアップごとに対応する仮想レベル0バックアップを提供します。リカバリ・シナリオの場合、適切なレベル0バックアップをリストアしてから、REDOログ・ファイルを使用してロール・フォワードします。

関連項目:

リアルタイムREDOトランスポートおよびその有効化方法の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください

2.4 リカバリ・アプライアンスのメタデータ・データベース

リカバリ・アプライアンスの重要なコンポーネントはリカバリ・アプライアンス・メタデータ・データベースです。このデータベースは、すべてのバックアップのメタデータを管理し、RMANリカバリ・カタログも格納します。リカバリ・アプライアンス・メタデータ・データベースは、事前に構成およびチューニングされており、リカバリ・アプライアンスによって管理されます。図2-5に、保護データベースとのやりとりを行うリカバリ・アプライアンス・メタデータ・データベースを示します。

図2-5 リカバリ・アプライアンスのメタデータ・データベース

この項には次のトピックが含まれます:

- デルタ・ストア

- デルタ・プール

- 自動デルタ・プール領域管理

- リカバリ・アプライアンス・スキーマ

- リカバリ・アプライアンス・カタログ

2.4.1 デルタ・ストア

デルタ・ストアは、リカバリ・アプライアンスの記憶域の場所にあるすべての保護データベース・バックアップ・データ全体です。すべてのデータ・ファイルとアーカイブREDOバックアップがデルタ・ストアに含まれます。デルタ・ストアには、すべての保護データベースのすべてのデータ・ファイルためのデルタ・プールがあります。

2.4.2 デルタ・プール

デルタ・ストアはデルタ・プールのコレクションです。リカバリ・アプライアンスは保護データベースからバックアップを受け取ると、インデックスを付けてデルタ・プールに格納します。デルタ・プールはデータ・ファイル・ブロックのセットであり、リカバリ・アプライアンスがこれを元に仮想完全バックアップを作成します。リカバリ・アプライアンスは、受信した任意の増分バックアップに対応する仮想完全バックアップを作成できるように、自動的にデルタ・プールを管理します。

リカバリ・アプライアンスにバックアップが送信される各データ・ファイルには、それぞれ独自のデルタ・プールがあります。たとえば、prod1のデータ・ファイル10は独自のデルタ・プールがあり、データベースprod2のデータ・ファイル1にも独自のデルタ・プールがあります。図2-6に示すように、リカバリ・アプライアンスによって保護されるデータベースのすべてのデルタ・プールがデルタ・ストアに含まれます。

図2-6 デルタ・ストアのデルタ・プール

2.4.3 自動デルタ・プール領域管理

リカバリ・アプライアンスがバックアップを管理する一連の操作は、自動デルタ・プール領域管理と呼ばれます。領域管理では具体的には次の自動タスクが行われます。

- ディスク・リカバリ・ウィンドウ目標とSBT保存ポリシーに基づいて、不要すなわち期限切れになったバックアップの削除(リカバリ・アプライアンスの記憶域の場所とテープの両方)
リカバリ・アプライアンスは、ディスクに格納しておく必要がないバックアップを定期的に判別して、ディスク領域を再利用できるようにします。リカバリ・アプライアンスが、デルタ・プールにあるバックアップを不要と判別するとき、通常、そのバックアップを構成する個々のブロックは、不要ではないブロックと一緒に物理ファイルに配置されています。リカバリ・アプライアンスはそれらの物理ファイルを再書込みして、不要ブロックが占有していた領域をデルタ・プールが再利用できるようにします。

- デルタ・プールを定期的に再編成して、リストア操作のパフォーマンスを改善します
デルタ・プールの自動トラッキングと再編成は、デルタ・プールの最適化と呼ばれます。古いブロックが削除され、更新されたデータ・ファイルに関する新しい増分バックアップが届くと、バックアップ内のブロックの連続性が低下することがあります。この状態によって、リストア操作のパフォーマンスが低下する可能性があります。リカバリ・アプライアンスは、自動的に仮想完全バックアップ・ブロックを再編成して連続性を維持するバックグラウンド・タスクを実行し、これにより、リストア操作の読取りアクセスを最適化します。

関連項目:

「リカバリ・アプライアンスによる記憶域の管理方法」

2.4.4 リカバリ・アプライアンス・スキーマ

リカバリ・アプライアンス・スキーマに含まれるメタデータは、リカバリ・アプライアンスが保護データベースにかわってバックアップを管理するために内部で使用します。RASYSは、リカバリ・アプライアンス・スキーマを所有するリカバリ・アプライアンス管理ユーザーです(「リカバリ・アプライアンス環境のユーザー・アカウント」を参照)。リカバリ・アプライアンス・スキーマにはRMANリカバリ・カタログが含まれます。

2.4.5 リカバリ・アプライアンス・カタログ

リカバリ・カタログの更新は、リカバリ・アプライアンスのインデックス付けと領域管理コレクションの結果を反映します。このような更新は、保護データベースの制御ファイルでは行われません。この理由から、リカバリ・アプライアンスにバックアップを格納する保護データベースはリカバリ・アプライアンス・カタログを使用する必要があります。

注意:

保護データベースは、バックアップ・リポジトリとしてリカバリ・アプライアンスを使用しなくても、リカバリ・アプライアンス内のリカバリ・カタログを使用できます。

RMANは、バックアップおよびリカバリ操作に利用されるのと同じリカバリ・アプライアンス・アカウントを使用してリカバリ・アプライアンス・カタログに接続します。各リカバリ・アプライアンス・ユーザー・アカウントは、仮想プライベート・カタログ・アカウントでもあります。DBMS_RA.GRANT_DB_ACCESSプロシージャは、リカバリ・アプライアンス権限を特定の保護データベースのデータベース・ユーザー・アカウントに付与します。

関連項目:

- 「DBMS_RAを使用したリカバリ・アプライアンス・アカウントへのデータベース・アクセスの付与」

- 「GRANT_DB_ACCESS」

- リカバリ・カタログの管理方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2.5 リカバリ・アプライアンスの記憶域

リカバリ・アプライアンスでは次のタイプの記憶域が使用されます。

- リカバリ・アプライアンスの記憶域の場所
Oracle ASMの場所は、Recovery Applianceディスク上のバックアップのメイン記憶域であり、保護されたデータベースのバックアップの保存先として機能します。「リカバリ・アプライアンスの記憶域の場所」を参照してください。

- バックアップ・ポーリングの場所
共有記憶域上のファイル・システム・ディレクトリ(オプション)。リカバリ・アプライアンスの外部で、保護データベースのバックアップ・ピースやアーカイブREDOログ・ファイルが格納される場所です。リカバリ・アプライアンスは、指定された間隔でディレクトリをポーリングし、バックアップが見つかったら取り出し、処理して格納します。「バックアップ・ポーリングの場所」を参照してください。

- REDOステージング領域
リアルタイムREDOトランスポートに対応するリカバリ・アプライアンス・インストールの場合、保護データベースがリカバリ・アプライアンスに送信するREDOストリームの宛先です。ステージング領域はリカバリ・アプライアンス・ディスク上にあります。リカバリ・アプライアンスはデータをアーカイブREDOログ・ファイルに収集し、圧縮アーカイブREDOログ・バックアップに変換してから、リカバリ・アプライアンスの記憶域の場所に書き込みます。

関連項目:

リアルタイムREDOトランスポートの構成方法の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

2.5.1 リカバリ・アプライアンスの記憶域の場所

リカバリ・アプライアンスの記憶域の場所は、複数の保護データベースが共有できます。リカバリ・アプライアンス管理者が、記憶域のそれぞれの場所を使用するクライアントを決定します。

2.5.1.1 Recovery Applianceの記憶域のメリット

リカバリ・アプライアンスの記憶域の場所のメリットは次のとおりです。

- ディスク使用率の向上
Recovery Applianceは共通記憶域を使用してすべての保護データベースのスパイクに対応するため、割当て過剰な記憶域の合計容量が減少します。従来のRMANバックアップおよびリカバリでは高速リカバリ領域には、リカバリ関連のファイルが格納されます。個々の高速リカバリ領域では、予期される最大のアクティビティ・スパイク(多くの場合、これによって記憶域が浪費されます)に対処するために必要な記憶域容量を各データベースで保持する必要があります。

注意:

Recovery Appliance内のデフォルトの記憶域の場所にもカタログ・バックアップ用の高速リカバリ領域が含まれます。

保護されたデータベースで、ローカルのオンラインおよびアーカイブされたREDOログ・ファイルの記憶域、制御ファイルの自動バックアップ、およびフラッシュバック・ログの高速リカバリ領域を保持し続けることをお薦めします。リカバリ・アプライアンス環境では、RMANバックアップはリカバリ・アプライアンスに格納されるため、高速リカバリ領域の容量要件が小さくなります。

- データベースに合うように最適化されたバックアップの重複除外と圧縮

- 共有ディスク・バックアップ・プール。各データベースのディスク・リカバリ・ウィンドウ目標を定義するデータベース保護ポリシーに基づいて分散されています。

2.5.1.2 Oracle ASMおよびRecovery Applianceの記憶域

Recovery Applianceの記憶域の場所は、Oracle ASMディスク・グループ内の領域を占有します。デフォルトでは、デルタ・プールは、通常の冗長性Oracle ASMディスク・グループ内に格納されます。つまり、Recovery Applianceは、すべてのオンディスク・バックアップのコピーを2つ管理します。1つのディスクまたはストレージ・サーバーが失われても、データベース・バックアップは残ります。ファイルおよびブロックを追跡するRecovery Applianceメタデータ・データベースは、冗長性が高いOracle ASMディスク・グループ内に格納されます。

関連項目:

- 「リカバリ・アプライアンスによる記憶域の管理方法」

- 『Oracle Automatic Storage Management管理者ガイド』

2.5.1.3 DELTA記憶域の場所

デフォルトでは、リカバリ・アプライアンスに構成されるすべてのディスク記憶域は、DELTAと呼ばれる1つの記憶域の場所に割り当てられます。図2-7では、すべての保護データベースがこの記憶域の場所を共有しています。

図2-7 記憶域の場所DELTA

さらに複雑な実装では、拡張や領域割当てなどの理由から、複数の記憶域の場所が必要になることがあります。図2-8に、記憶域の場所(DELTA (デフォルト)とDELTA2 (デフォルト以外))が2つ構成されたリカバリ・アプライアンスを示します。

図2-8 複数の記憶域の場所

2.5.2 バックアップ・ポーリングの場所

「バックアップ・ポーリング・ポリシー」で説明したように、バックアップ・ポーリング・ポリシーによって、ファイル・システム・ディレクトリが定義されます。保護データベースが、リカバリ・アプライアンスと直接やりとりせずに、この場所にバックアップを配置します。バックアップ・ポーリング・ディレクトリはNFSマウント・ポイントであり、リカバリ・アプライアンスのストレージ・サーバーにはありません。

ポーリング・ポリシーでは、記憶域のファイル・システム・パスと新しいバックアップの検索が行われる頻度を定義します。ポーリング・ポリシーはオプションです。ポーリング方法を使用してバックアップがリカバリ・アプライアンスに送信されない場合、作成する必要はありません。

2.5.2.1 バックアップ・ポーリングのステージ

バックアップ・ポーリングは次のステージで実行されます。

1. 保護データベースが、リカバリ・アプライアンスの関与なしにバックアップを書き込みます(バックアップが作成されるときリカバリ・アプライアンスが実行している必要はありません)。

2. 新たに届いたバックアップを探すためにリカバリ・アプライアンスがポーリングします。

3. リカバリ・アプライアンスはポーリングでファイルを検出すると、内容を調査して、保護データベースに関連付けようとします。その後、次のいずれかを行います。

- 登録されている保護データベースにファイルが関連する場合、リカバリ・アプライアンスはそのバックアップを処理します。

- 登録されたどの保護データベースともファイルが関連付けられていない場合、リカバリ・アプライアンスは警告メッセージをログに記録し、ファイルの処理は行いません。

2.5.2.2 リカバリ・アプライアンスによるバックアップ・ポーリング・ディレクトリのバックアップの処理方法

バックアップがリカバリ・アプライアンスの記憶域にコピーされるようにポーリングを設定するには、リカバリ・アプライアンスの記憶域の場所ではないが、リカバリ・アプライアンスがアクセスできるバックアップ・ポーリング・ディレクトリを構成する必要があります。保護データベースは、ポーリング・ポリシーに指定されたポーリング・ディレクトリにバックアップを書き込みます。

リカバリ・アプライアンスは、新たに作成されたバックアップがないかどうかポーリング・ディレクトリをチェックします。バックアップが存在していると、リカバリ・アプライアンスは、ポーリング・ディレクトリにあるバックアップをリカバリ・アプライアンス内部の記憶域の場所にコピーして処理します。リカバリ・アプライアンスがバックアップをコピーするために十分な時間が経過してから、保護データベースがポーリング・ディレクトリからバックアップを削除します。図2-9にこの構成を示します。

図2-9 バックアップ・ポーリング

2.5.3 リカバリ・アプライアンスによる記憶域の管理方法

リカバリ・アプライアンス管理者の重要な役目は、指定された保存ウィンドウとデータベース・サイズに適したディスク容量を計画することです。条件は変化するため、リカバリ・アプライアンスによって、記憶域の場所とデータベースのレベルで領域管理のモニタリングとアラートが提供されます。予測した記憶域のニーズが使用可能な記憶域の容量に近づくと、アラートと警告が生成され、管理者が記憶域の需要に対処する時間を取ることができます。

RA_DATABASEビューでアクセスできる次の属性によって、リカバリ・アプライアンスが記憶域とバックアップの保存を管理する方法が決まります。

- リカバリ・ウィンドウ目標

- 予約済領域

- コピーの保証

- 最長保存期間

「アーカイブ・バックアップと暗号化バックアップ」では、永久的増分計画に含まれないRMANバックアップに適用される特別なアルゴリズムについて説明します。

2.5.3.1 リカバリ・ウィンドウ目標

DBMS_RA.CREATE_PROTECTION_POLICYのrecovery_window_goalパラメータは、現在日時からさかのぼって、ポイント・イン・タイム・リカバリを可能にしておく必要がある期間(通常は日数)を指定します。recovery_window_goalが1日に設定されているとします。8月7日の深夜0時の時点では、現在時刻から8月6日の深夜0時までの任意の時点にリカバリできることが目標です。8月8日の深夜0時であれば、現在時刻から8月7日の深夜0時までの任意の時点にリカバリできることが目標になります。

リカバリ・アプライアンスは、各データベースに定義されたリカバリ・ウィンドウ目標を達成するために十分なバックアップを保存しようとします。たとえば、リカバリ・アプライアンスがデータベースSTORE01、STORE02およびSTORE03を保護しているとします。STORE01のリカバリ・ウィンドウ目標は1日です。8月7日の深夜0時に、STORE01がリカバリ・ウィンドウ目標を達成するためにバックアップ用として624.2GBが必要な場合、リカバリ・アプライアンスは、少なくともこれに相当する領域をSTORE01バックアップに割り当てようとします。

十分な領域が記憶域に存在する場合、リカバリ・ウィンドウ目標よりも前に作成されたバックアップを使用できますが、これは保証されるとはかぎりません。以前のバックアップのパージが不要な場合、リカバリ・アプライアンスはそれらを保持し、効果的にポイント・イン・タイム・リカバリが可能な期間を延長できます。たとえば、8月7日にSTORE01で使用可能な領域が700GB以上あっても、必要となるのは624.2GBのみです。同様の状況がSTORE02とSTORE03でも発生することがあります。

十分な領域が記憶域に存在しない場合、デフォルト(guaranteed_copy=NO)でリカバリ・アプライアンスはバックアップをパージできます。領域を再利用するとき、リカバリ・アプライアンスはまずリカバリ・ウィンドウ要件を優先しようとします。

関連項目:

- 「保護ポリシーの作成」

- 「CREATE_PROTECTION_POLICY」

2.5.3.2 予約済領域

リカバリ・ウィンドウ目標の次に重要なのは、DBMS_RA.ADD_DBおよびDBMS_RA.UPDATE_DBのreserved_spaceパラメータです。予約済領域によって、各保護データベースがリカバリ・ウィンドウ目標を達成するために保証されるディスク領域の容量が定義されます。

注意:

これは、保護ポリシーではなくADD_DBに指定される唯一の記憶域パラメータです。

バックアップで領域が必要なため、バックアップを格納するために必要な領域を予測する必要があります。たとえば、1024GBの予約済領域をDB1124データベースに割り当てるとします。これは、仮にリカバリ・ウィンドウ目標を達成するためにデータベースでこの容量が必要になった場合に、リカバリ・アプライアンスが1024GBをDB1124に保証することを意味します。次の図は、保護されたデータベースの詳細レポートの一部です。

この例で、DB1124のディスク・リカバリ・ウィンドウ目標は3日間で、実際のリカバリ・ウィンドウ(現時点でリカバリ・アプライアンスがリカバリできる期間)は4.59日間です。リカバリ・ウィンドウ目標を達成するには、182.3GBのバックアップ・データが必要です。この容量は、指定された予約済領域設定1024GBの20%未満です。デフォルトでは、任意の時点でデータベースが実際に保持する容量は、指定の予約済領域より少ないことも多いこともあります。

注意:

予約済領域は容量(GB)で計測されますが、リカバリ・ウィンドウ目標は時間で計測されます。

リカバリ・アプライアンスはリカバリ・ウィンドウ目標と予約済領域の設定を使用して、ビジネス要件を満たす記憶域を動的に割り当てます。リカバリ・アプライアンスが、各データベースのリカバリ・ウィンドウ目標を満たした上でできるだけ多くのバックアップ・データをパージし、さらに領域が必要な場合は、各データベースの予約済領域設定を検証します。リカバリ・アプライアンスは、予約済領域の超過率が最も高いバックアップが存在しているデータベースのバックアップをパージし、RA_INCIDENT_LOGビューにメッセージのログを記録します。RA_PURGING_QUEUEビューを問い合せて、次にバックアップをパージするデータベースを判別します。

関連項目:

- 「DBMS_RAを使用した保護されたデータベースのメタデータの追加」

- 「リカバリ・アプライアンス・レポート・ページからの保護された詳細レポートへのアクセス」

- 「CREATE_PROTECTION_POLICY」

- 「ADD_DB」

2.5.3.3 コピーの保証

記憶域管理のポイントとなる質問は、古いバックアップのコピーまたはレプリケートと、新しいバックアップおよびREDOの受入れのどちらが重要かということです。DBMS_RA.CREATE_PROTECTION_POLICYのguaranteed_copyパラメータを次のように設定できます。

- NO (デフォルト)
新しいバックアップの領域を用意するために必要であれば、リカバリ・アプライアンスは、バックアップをテープにコピーしたりレプリケートしたりせずにパージできます。この場合、保護データベースが保持する容量は予約済領域よりも多いことも少ないこともあります。

- YES
コピーの保証が有効になっていると、バックアップがテープにコピーされるかレプリケートされないうちにリカバリ・アプライアンスがバックアップを削除することはありません。また、コピーまたはレプリケートされていないバックアップの合計サイズが、データベースのreserved_space設定を超えることはリカバリ・アプライアンスで許可されません。

リカバリ・アプライアンスが、コピーまたはレプリケートされていないバックアップで予約済領域を使い果たしてしまうと、新しいバックアップまたはREDOを受け入れることができません。この設定は、テープ・システムまたはレプリケート先リカバリ・アプライアンスが長時間使用できない場合に、記憶域管理の動作のみを変更します。

リカバリ・アプライアンスは、永久的増分バックアップ計画の仮想バックアップに対しては別のアルゴリズムを使用します。非仮想バックアップは特定の容量の領域を占有し、テープ・コピーが行われるかどうかは設定によります。仮想バックアップの場合、テープ・スケジュールによって、すべての仮想バックアップのレベル1またはレベル0バージョンがリカバリ・アプライアンスに書き込まれます。また、仮想バックアップの領域計算は複雑です。領域にはバックアップをサポートするために必要なブロックが含まれるためです。これは、バックアップをテープに書き込むために必要な領域とは異なる場合があります。これらの理由から、リカバリ・アプライアンスは、仮想データ・ファイル・バックアップをテープに書き込んだ後で、このバックアップのすべてのバージョンとこのデータ・ファイルの古い仮想バックアップすべてがテープにコピーされた(レプリケートされた)とみなします。

関連項目:

- 「デルタ・プッシュ」

- 「保護ポリシーの作成」

- 「CREATE_PROTECTION_POLICY」

2.5.3.4 最長保存期間

DBMS_RA.CREATE_PROTECTION_POLICYのmax_retention_windowパラメータは、このポリシーを使用するデータベースのバックアップをリカバリ・アプライアンスが保存する最長期間を指定します。nullを指定すると、記憶域の場所の領域不足やユーザー・アクションによって引き起こされないかぎり、バックアップのパージが発生しません。

リカバリ・アプライアンスは、データベースのリカバリ・ウィンドウ目標を維持するために必要な場合のみ、バックアップを保存ウィンドウよりも長く保存します。この設定の効果は、リカバリ・アプライアンスによるバックアップの削除が、設定がない場合よりも早い時点で行われることです。

関連項目:

- 「保護ポリシーの作成」

- 「CREATE_PROTECTION_POLICY」

2.5.3.5 アーカイブ・バックアップと暗号化バックアップ

次のタイプのバックアップは、永久的増分計画に含めたり、仮想完全バックアップの作成に使用したりできません。

- BACKUP ... KEEPコマンドを使用して作成されるRMANアーカイブ・バックアップ

- CONFIGUREまたはSET ENCRYPTIONを使用して作成されるRMAN暗号化バックアップ(「データ暗号化手法」を参照)

リカバリ・アプライアンスは、永久的増分計画のバックアップとは異なる方法でこれらのバックアップを管理します。リカバリ・アプライアンスは、指定されたリカバリ・ウィンドウ目標とは関係なくアーカイブ・バックアップを保存します。ただし、暗号化バックアップはリカバリ・ウィンドウ設定に対応します。

アーカイブ・バックアップが、リカバリ・アプライアンスによる削除対象になるのはKEEPの時間が経過してからのみです。アーカイブ・バックアップを格納する期間を延長する場合は、次のガイドラインに注意してください。

- それらに対応する予約済領域を調整します。アーカイブ・バックアップによって、リカバリ・ウィンドウ目標の達成に使用可能な領域が減少するため、対応する領域を設定する必要があります。

- リカバリ・アプライアンスでは、アーカイブ・バックアップがテープに自動的にコピーされないため、COPY_BACKUPプロシージャを使用して手動でコピーする必要があります。このプロシージャを使用すると、リカバリ・アプライアンスの記憶域の場所の外部にあるディスク上の場所にアーカイブ・バックアップをコピーすることもできます。MOVE_BACKUPプロシージャは、アーカイブ・バックアップをディスクまたはテープにコピーして、記憶域から削除します。

関連項目:

- リカバリ・アプライアンスでのテープへのバックアップのコピー

- アーカイブ・バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- リカバリ・アプライアンスでの長期保存のアーカイブ・バックアップの作成方法の詳細は、My Oracle SupportノートのドキュメントID 2107079.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=2107079.1)を参照してください

2.6 Oracle Secure Backup

Oracle Secure Backupは、リカバリ・アプライアンスのテープ管理コンポーネントです。リカバリ・アプライアンスは、保護データベースからリカバリ・アプライアンスへのテープ・バックアップ操作から解放されます。したがって、保護データベース・ホストではRMAN統合メディア管理ソフトウェア・モジュールが必要ありません。このかわりに、Oracle Secure Backupモジュールのコピーがリカバリ・アプライアンスにインストールされます。リカバリ・アプライアンスは、すべての保護データベースに関してバックアップのテープへのコピーを自動的に管理します。

関連項目:

Oracle Secure Backupの詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。

2.6.1 テープ・アーカイブ

保護データベースはバックアップをリカバリ・アプライアンスに送信し、リカバリ・アプライアンスがそれらをディスク上の指定された記憶域の場所に格納します。ディスク領域を再利用し、トランスポータブル・テープ・バックアップを作成するには、ビジネス要件でテープへのアーカイブが求められることがあります。

テープ・バックアップは、リカバリ・アプライアンスが自動化してバックグラウンド・タスクとして実行する繰返しタスクです。リカバリ・アプライアンス管理者はルールを構成して、リカバリ・アプライアンスがテープ・バックアップを作成する間隔を指定します。保護ポリシーはデータベースの特徴に合ったグループ分けであり、同じ保護ポリシーを共有するデータベースは同じテープ・アーカイブ要件を共有します。

リカバリ・アプライアンスが、バックアップにブロックを提供するすべての完全バックアップまたは増分バックアップの最大互換バージョンと一致する互換バージョンのテープ・バックアップを作成します。リカバリ・アプライアンスがメディア管理レイヤーに送信するデータベースID情報は、データベースがバックアップを送信した場合に送信される情報と同一です。この一致により、バックアップが作成されたデータベースがそのバックアップを使用することが保証されます。

関連項目:

「Oracle Schedulerを使用したテープ・バックアップ・ジョブのスケジューリング」

2.6.2 テープ取得

バックアップは完全なバックアップ・セットとしてテープに格納されます。したがって、リカバリ・アプライアンスの仲介なしにRMANがテープ・バックアップを使用できます。テープのバックアップをリストアするには次の方法があります。

- リカバリ・アプライアンスによる取得
これは、リカバリ・アプライアンスによって作成されたSBTバックアップをリストアする最も簡単な方法です。RMANが、リカバリ・アプライアンスにリストアをリクエストします。その特定のバックアップがテープに移されたことを認識している必要はありません。リカバリ・アプライアンスは、リクエストされたバックアップ・セットがテープにあることを認識し、バックアップをメディア・マネージャからリストアするSBTセッションを開き、ネットワークを介してデータを保護データベース・ホストに送信します。

- 保護データベースによる取得
SBTバックアップはクライアント互換フォーマットとして存在しているため、RMANはリカバリ・アプライアンスと連動せずに、テープからホストにバックアップを直接リストアできます。この場合、RMANはまずバックアップ・ピースをカタログ化してから、テープからリストアする必要があります。また、Oracle Secure Backupライブラリを保護データベース・ホストにインストールすることも必要です。

関連項目:

テープからバックアップをリストアする方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

2.7 リカバリ・アプライアンス・レプリケーション

リカバリ・アプライアンス・レプリケーションでは、1つのリカバリ・アプライアンス(アップストリーム・リカバリ・アプライアンス)が別のリカバリ・アプライアンス(ダウンストリーム・リカバリ・アプライアンス)にバックアップを転送します。最初の構成以降、レプリケーションは完全に自動的に行われます。レプリケーション・トポロジの各リカバリ・アプライアンスは、それぞれの保護ポリシーとポーリング・ポリシーを管理します。

2.7.1 ダウンストリーム・リカバリ・アプライアンスによるバックアップの処理方法

アップストリーム・リカバリ・アプライアンスは、バックアップをダウンストリーム・リカバリ・アプライアンスに転送するために、保護データベースがバックアップの送信に使用するのと同じリカバリ・アプライアンス・バックアップ・モジュールを使用します。バックアップを処理する基本手順は次のとおりです。

1. 保護データベースがリカバリ・アプライアンス・バックアップ・モジュールを使用して、バックアップをリカバリ・アプライアンスに送信します。

2. リカバリ・アプライアンスはバックアップを受信し、通常どおりに処理します(「バックアップのライフサイクル: シナリオ」を参照)。

注意:

ダウンストリーム・リカバリ・アプライアンスは、自らがダウンストリームの役割を果たしていることを認識していません。ダウンストリーム・リカバリ・アプライアンスでのバックアップの受信と処理のロジックは、アップストリーム・リカバリ・アプライアンスでの処理内容とは独立しています。

3. アップストリーム・リカバリ・アプライアンスがバックアップをダウンストリーム・リカバリ・アプライアンスに転送します。

注意:

リアルタイムREDOトランスポートが有効である場合、受信したREDO変更はリカバリ・アプライアンスによってリアルタイムではレプリケートされません。アーカイブREDOログのバックアップが作成されると、Recovery Applianceは、このバックアップをデータ・ファイルのバックアップとともにレプリケートします。

4. ダウンストリーム・リカバリ・アプライアンスがアップストリーム・リカバリ・アプライアンスからバックアップを受信すると、独自のメタデータ・データベースを更新します。

5. アップストリーム・リカバリ・アプライアンスが、ダウンストリーム・メタデータのメタデータ更新をリクエストします。

アップストリーム・リカバリ・アプライアンスは、定期的に、そのすぐダウンストリームにあるリカバリ・アプライアンスにメタデータ更新をリクエストします。ダウンストリーム・リカバリ・アプライアンスは、メタデータ・リクエストを受信するとメタデータ更新をアップストリーム・リカバリ・アプライアンスに送信します。アップストリーム・リカバリ・アプライアンスが自らのリカバリ・カタログを更新します。リカバリ・アプライアンス・レプリケーションで、このプロセスは調整と呼ばれます。

2.7.2 レプリケーションのユースケース

ダウンストリーム・リカバリ・アプライアンスはアップストリーム・リカバリ・アプライアンスに依存せずにバックアップを処理するため、バックアップを格納する各データベースに対してまったく異なるポリシーを持つことができます。このように合せる必要がないため多様なユースケースを構成できます。その一部を図2-10に示します。

図2-10 リカバリ・アプライアンス・レプリケーションのユースケース

図2-10は次のユースケースを示しています。

- 一方向
バックアップ・データがローカル・データベースからアップストリーム・リカバリ・アプライアンスに送信され、アップストリーム・リカバリ・アプライアンスがリモートのダウンストリーム・リカバリ・アプライアンスに転送します。

- 双方向
バックアップがローカル・データベースからローカルのリカバリ・アプライアンスに送信され、さらにリモートのリカバリ・アプライアンスに転送されます。反対に、バックアップがリモート・データベースからリモートのリカバリ・アプライアンスに送信され、さらにローカルのリカバリ・アプライアンスに転送されます。

このケースでは、各リカバリ・アプライアンスがレプリケーション・トポロジのアップストリームとダウンストリーム両方の役割を果たします。すべてのリカバリ・アプライアンスは、一方の保護データベース・セットのプライマリ・バックアップの場所、および他方のセットのセカンダリ・バックアップの場所として使用されます。このように、それぞれのリカバリ・アプライアンスがよく利用され、もう一方のリカバリ・アプライアンスに障害回復サービスを提供します。

- ハブ・アンド・スポーク
一方のデータベース・セットのバックアップがローカル・リカバリ・アプライアンスに送信され、別のデータベース・セットのバックアップが別のローカル・リカバリ・アプライアンスに送信されます。これらのローカル・リカバリ・アプライアンスはバックアップを1つのリモート・リカバリ・アプライアンスに転送し、リモート・リカバリ・アプライアンスがバックアップをテープにアーカイブします。

これらのユースケースのどれでもカスケード・レプリケーションに使用できます。カスケード・レプリケーションでは、ダウンストリーム・リカバリ・アプライアンスがバックアップを第2のダウンストリーム・リカバリ・アプライアンスに転送して、リカバリ・アプライアンスの一方向チェーンを構築します。

関連項目:

リカバリ・アプライアンスでのバックアップのレプリケート

2.8 データ暗号化手法

図2-11に示すように、Recovery Applianceに送信されたバックアップおよびREDOで使用可能な暗号化オプションが各種用意されています。Recovery Applianceではサーバー側の暗号化は行われません。つまり、Recovery Appliance自体がデータを暗号化および復号化することはありません。

図2-11 データ暗号化手法

次のタイプの暗号化がサポートされています。

- 本番データベースの表領域での透過的データ暗号化(TDE)

- Recovery Applianceへのネットワーク転送用のOracle Netセキュリティ

- LOG_ARCHIVE_DEST_nを使用したREDO暗号化

- テープ・ドライブベースのハードウェア暗号化

2.8.1 本番データベースの表領域での透過的データ暗号化(TDE)

データベース内のTDEを有効化し、通常どおり増分バックアップをとることをお薦めします。TDEには、アドバンスト・セキュリティ・オプションが必要です。TDEの利点は、次のとおりです。

- TDEはアプリケーションに対して透過的に行われます。

- 暗号化された表領域のバックアップ、およびこれらの表領域への変更を説明するREDOが暗号化されます。TDEによって暗号化されたデータ・ブロックは、保護されたデータベース、Recovery Applianceの記憶域、テープ・デバイス、レプリケート・アプライアンスで保護されるだけでなく、ネットワーク接続を介して転送される際にも保護されます。

- ソース・データベースでのTDEにより、ダウンストリーム・サーバーでのオーバーヘッドが削減されます。

- この手法は、永久的増分計画および仮想完全バックアップをサポートしています。

注意:

RMAN SETまたはCONFIGURE ENCRYPTIONコマンドを使用してバックアップを暗号化することはお薦めしません。詳細は、「アーカイブ・バックアップと暗号化バックアップ」を参照してください

次の表は、RMAN暗号化またはRMAN圧縮あるいはその両方が、保護されたデータベース・バックアップで使用される場合の永久増分のサポートを示します。

表2-4 RMAN暗号化およびRMAN圧縮での永久増分のサポート

データベースのデータ

バックアップ暗号化なしおよびRMAN圧縮なし

RMAN暗号化

RMAN圧縮

バックアップ暗号化およびRMAN圧縮

暗号化されません

はい

いいえ

はい

いいえ

TDE表領域暗号化

はい

はい

いいえ

いいえ

関連項目:

- TDEの詳細は、『Oracle Database Advanced Securityガイド』を参照してください

- バックアップの暗号化の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

- 圧縮バックアップの作成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

2.8.2 Recovery Applianceへのネットワーク転送用のOracle Netセキュリティ

Oracle Netセキュリティには、LDAP準拠のディレクトリ・サーバー、デジタル証明書およびSecure Sockets Layer (SSL)が含まれます。Oracle Netセキュリティでは、Recovery ApplianceへのバックアップおよびREDOの転送が暗号化されます。この手法では、データベースのTDE暗号化、LOG_ARCHIVE_DEST_nを使用したREDO暗号化、またはRMANバックアップの暗号化からは独立した転送中のネットワークの暗号化を実現します。

関連項目:

- SSLの構成方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- Oracle Netセキュリティの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

2.8.3 LOG_ARCHIVE_DEST_nを使用したREDO暗号化

有効である場合、LOG_ARCHIVE_DEST_nのENCRYPTION属性は、Recovery Appliance上で停止しているREDOと、Recovery Applianceへのネットワーク転送中のREDOの両方を暗号化します。基本的なプロセスは次のとおりです。

1. 保護されたデータベースは、保護されたデータベース上のOracleウォレットに含まれる秘密鍵を使用してメモリー内のREDOを暗号化します。

2. 保護されたデータベースは、ネットワークを介してREDOをRecovery Applianceに転送します。

注意:

Oracle Netセキュリティも有効である場合、REDOはネットワーク転送中に二重に暗号化されます。

3. Recovery Applianceは、Recovery Appliance上でのみ暗号化形式で存在するアーカイブREDOログ・ファイルに暗号化REDOを書き込みます。

リカバリ・シナリオでは、RMANは、(Recovery Appliance上ではなく)保護されたデータベース上のOracleウォレットに格納されている暗号化鍵を使用して、保護されたデータベース上の暗号化REDOログ・ファイルをリストアおよび復号化します。RMANは、メディア・リカバリ中に暗号化REDOログ・ファイルを適用することはありません。

関連項目:

- 暗号化REDOをサポートするOracle Databaseのバージョンの詳細は、My Oracle SupportノートのドキュメントID 1995866.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=1995866.1)を参照してください

- LOG_ARCHIVE_DEST_nを使用したREDO暗号化の詳細は、『Oracle Data Guard概要および管理』を参照してください。

2.8.4 テープ・ドライブベースのハードウェア暗号化

Recovery Applianceは、テープ・ドライブベースのハードウェア暗号化をサポートしています。この場合、テープ・ドライブはソフトウェアではなくデータを暗号化します。

注意:

Oracle Secure Backupは、Recovery Applianceがバックアップ・ピースをテープにコピーする前にこれらを暗号化できます。ただし、ソフトウェアベースの暗号化を使用することをお薦めしません。なぜなら、この場合、パフォーマンスに悪影響が及ぶ可能性があるからです。

鍵の管理については、すべての暗号化鍵を一元的に認証、保護および管理するOracle Key Managerを使用することをお薦めします。Oracle Key Managerは、データの暗号化および復号化時にRecovery ApplianceでCPUを消費しません。

関連項目:

ハードウェアの暗号化の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。

第I部 リカバリ・アプライアンスの管理

第I部は、次の章で構成されています。

- リカバリ・アプライアンスのワークフロー

- リカバリ・アプライアンスのためのCloud Controlスタート・ガイド

- リカバリ・アプライアンスでの保護ポリシーの管理

- 保護されたデータベース・アクセスのためのリカバリ・アプライアンスの構成

- リカバリ・アプライアンスでのテープへのバックアップのコピー

- リカバリ・アプライアンスでのバックアップのレプリケート

- リカバリ・アプライアンスのモニタリング

- リカバリ・アプライアンス・レポートへのアクセス

3 リカバリ・アプライアンスのワークフロー

この章では、Zero Data Loss Recovery Appliance環境を管理するための基本的なワークフローについて説明します。この章では、該当する場合に『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照しています。この章の内容は次のとおりです。

- リカバリ・アプライアンス管理における職務の分離

- リカバリ・アプライアンス管理の前提条件

- リカバリ・アプライアンス管理のツール

- リカバリ・アプライアンスの計画

- リカバリ・アプライアンスの設定と構成

- Recovery Applianceのメンテナンス・タスク

3.1 リカバリ・アプライアンス管理における職務の分離

一般的なリカバリ・アプライアンス環境には、次のロールを持つ個人が含まれます。

- Cloud Control管理者
このロールを持つアプリケーション管理者は、Oracle Enterprise Manager Cloud Control (Cloud Control)を管理します。職務には次が含まれます。

- リカバリ・アプライアンスなどのターゲットの検出

- 1つ以上の保護されたデータベースの管理

- 1つ以上のリカバリ・アプライアンスの管理

- リカバリ・アプライアンス管理者
この管理者はリカバリ・アプライアンスを管理します。一般的な職務には次が含まれます。

- 保護ポリシーの作成

- 保護ポリシーへの保護されたデータベースの割当て

- リカバリ・アプライアンスの領域の管理

- テープおよびレプリケーション操作の構成

- 仮想プライベート・カタログを所有するリカバリ・アプライアンス・ユーザー・アカウントの作成

- リカバリ・アプライアンスのモニタリングとレポートの生成

- 保護データベースの管理者
この管理者は、リカバリ・アプライアンス管理者によって割り当てられた仮想プライベート・カタログ・アカウントを使用して、リカバリ・アプライアンスへのバックアップの構成を担当します。

関連項目:

- 「リカバリ・アプライアンス環境のユーザー・アカウント」

- Enterprise Manager管理者アカウントの作成方法は、Cloud Controlオンライン・ヘルプを参照してください。

- データベース・ユーザー・アカウントの作成方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

3.2 リカバリ・アプライアンス管理の前提条件

Oracleフィールド・エンジニアとともに作業して、リカバリ・アプライアンスをインストールおよび設定する必要があります。

3.3 リカバリ・アプライアンス管理のツール

次のツールを使用して、リカバリ・アプライアンスの管理タスクを実行します。

- Cloud Control
Cloud Controlとは、リカバリ・アプライアンスおよびその保護データベースの管理およびモニタリングに使用できるグラフィカル・ユーザー・インタフェースが含まれたシステム管理ツールです。これはリカバリ・アプライアンスのタスクの推奨UIです。

詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

- SQL*Plus
SQL*Plusは、DBMS_RAプログラム・ユニットの実行やリカバリ・カタログ・ビューの問合せを行うことができるコマンドライン・ツールです。SQL文およびオラクル社が提供するPL/SQLパッケージを使用して、SQL*Plusでこれらのタスクを実行します。

『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

3.4 リカバリ・アプライアンスの計画

次の一般的なタスクを実行する必要があります。

- タスク1: 保護データベースの階層グループ分け

- タスク2: 各データベース階層のリカバリ要件の決定

- タスク3: 各保護データベースのリカバリ要件の決定

- タスク4: リカバリ・アプライアンスのアクセス要件の決定

- タスク5: リカバリ・アプライアンスへのバックアップ移行計画の作成

- タスク6: Cloud Controlのレポート・ツールおよびモニタリング・ツールの確認

タスク1: 保護データベースの階層グループ分け

リカバリ要件に基づいてデータベースをグループ分けします。デフォルトでリカバリ・アプライアンスには、プラチナ、ゴールド、シルバーおよびブロンズの保護ポリシーが含まれます。各ポリシーは、保護のレベルに対応しています。たとえば、ゴールドは、この階層のデータベースにリアルタイムREDOトランスポート保護を提供するのに対し、ブロンズは提供しません。

タスク2: 各データベース階層のリカバリ要件の決定

各データベース階層で次の項目を決定します。

- 潜在的なデータ損失の危険にさらされる最長期間

- ディスク・リカバリ・ウィンドウ目標

- テープのリカバリ・ウィンドウ

- データベース階層のテープ・バックアップのスケジュール、テープ・ボールティングのスケジュール、または暗号化の要件

- リカバリ・アプライアンス・レプリケーションの構成

- バックアップ・ポーリングのディレクトリ(バックアップ・ポーリング・ポリシーを有効にする場合)

- 既存のリカバリ・カタログのリカバリ・アプライアンス・カタログへのインポート

- コピーの保証機能の有効化(領域を再利用するためにリカバリ・アプライアンスのバックアップの削除を検討する前に、バックアップをテープにコピーするかレプリケートする必要がある)

- ディスク上のバックアップの最長保存期間

関連項目:

「保護ポリシーについて」

タスク3: 各保護データベースのリカバリ要件の決定

たとえば、次のタスクを実行します。

- 保護データベースのサイズ、変更率およびリカバリ・ウィンドウ目標に基づいて、予約済領域を計算します。

- リアルタイムREDOトランスポートを実装するかどうかを決定します。

保護データベースの計画に関するその他の考慮事項は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

タスク4: リカバリ・アプライアンスのアクセス要件の決定

データ・センターでリカバリ・アプライアンスのアクセス権を持つユーザーを決定します。たとえば、データベース管理者、記憶域管理者、システム管理者およびバックアップ管理者ではアクセス要件が異なることがあります。1人のユーザーがすべての役割を担当するデータ・センターもあります。

タスク5: リカバリ・アプライアンスへのバックアップ移行計画の作成

このステージでは、従来のRMANバックアップをリカバリ・アプライアンスのバックアップ計画にどのように組み込むかを決定します。リカバリ・アプライアンスを設定した後で、次の計画の1つを選択できます。

- 一定期間、新しいリカバリ・アプライアンスへのバックアップと並行して、従来のディスクとテープへのバックアップを実行しながら、リカバリ・アプライアンスのみのバックアップへの移行を準備します。

- 保護データベースはリカバリ・アプライアンスのみにバックアップし、従来のバックアップは従来のメディアで別に管理します。

どちらのケースでも、全体的なカタログ管理を簡略化するために、最初に従来のRMANリカバリ・カタログをリカバリ・アプライアンス・カタログにインポートすることをお薦めします。

関連項目:

リカバリ・アプライアンス・カタログへのメタデータのインポート方法の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

タスク6: Cloud Controlのレポート・ツールおよびモニタリング・ツールの確認

Cloud Controlはリカバリ・アプライアンスの推奨インタフェースです。「リカバリ・アプライアンスのためのCloud Controlスタート・ガイド」で説明しているように、リカバリ・アプライアンスを構成する前に、主要なCloud Controlページについて理解してください。データベース管理者は、「バックアップ設定」、「バックアップのスケジュール」および「バックアップ・レポート」などのバックアップ関連ページを確認することもできます。

関連項目:

- リカバリ・アプライアンスのモニタリング

- リカバリ・アプライアンス・レポートへのアクセス

3.5 リカバリ・アプライアンスの設定と構成

次の一般的なタスクを実行する必要があります。

- タスク1: Cloud Controlユーザー・アカウントの作成

- タスク2: 各データベース階層の保護ポリシーの作成

- タスク3: リカバリ・アプライアンスでの保護データベースのアクセス権の構成

- タスク4: 保護データベースの構成(DBA向け)

- タスク5: 従来のバックアップのリカバリ・アプライアンスへの移行(DBA向け)

- タスク6: リカバリ要件を満たすcopy-to-tapeスケジュールの作成

- タスク7: リカバリ・アプライアンス・レプリケーションの構成

タスク1: Cloud Controlユーザー・アカウントの作成

「リカバリ・アプライアンス管理における職務の分離」で説明したように、リカバリ・アプライアンス環境では複数の管理アカウントが必要になる場合があります。この手順では、環境で必要なCloud Controlユーザー・アカウントを作成します。

注意:

これらはデータベース・ユーザー・アカウントではなく、アプリケーションレベルのユーザー・アカウントです。

関連項目:

Enterprise Managerユーザー・アカウントの作成方法は、Cloud Controlのヘルプを参照してください。

タスク2: 各データベース階層の保護ポリシーの作成

保護データベースの階層ごとに個別の保護ポリシーを作成します。「保護ポリシーを管理するための基本タスク」でこれらのタスクについて説明します。

1. バックアップ・ポーリングの場所へのアクセス権がリカバリ・アプライアンスにある場合、必要に応じて、バックアップ・ポーリング・ポリシーを作成します。

注意:

Cloud Controlを使用する場合、この手順は保護ポリシーの構成に含まれます。DBMS_RAを使用するときは、別のプロシージャ(CREATE_POLLING_POLICY)を実行する必要があります。

「バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)」でこのタスクについて説明しています。

2. 特定のデータベース階層の保護ポリシーを作成します。
「保護ポリシーの作成」でこのタスクについて説明しています。

タスク3: リカバリ・アプライアンスでの保護データベースのアクセス権の構成

リカバリ・アプライアンスのメタデータ・データベースに仮想プライベート・カタログ所有者を作成し、保護データベースを追加し、保護データベースへのアクセス権をカタログ所有者に付与します。「保護されたデータベース・アクセスを構成するための基本的なタスク」の説明に従って、これらの手順すべてをリカバリ・アプライアンスで実行します。

タスク4: 保護データベースの構成(DBA向け)

保護データベース管理者がこのタスクを実行します。リカバリ・アプライアンスでのDBMS_RAプロシージャの実行は含まれません。クライアント側の構成には次のサブタスクが含まれます。

1. リアルタイムREDOトランスポートなど、バックアップおよびリカバリ設定の構成

2. リカバリ・アプライアンスへのアクセスの有効化(リカバリ・アプライアンス・バックアップ・モジュールのインストールとリカバリ・アプライアンス・ユーザー・アカウントの認証が含まれる)

3. バックアップおよびリストア操作のテスト

保護データベースの構成方法の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

タスク5: 従来のバックアップのリカバリ・アプライアンスへの移行(DBA向け)

保護データベースのDBAがこのタスクを実行します。リカバリ・アプライアンスでのDBMS_RAプロシージャの実行は含まれません。移行では、従来のリカバリ・カタログをリカバリ・アプライアンス・カタログに移行して、ディスクまたはテープ上の物理バックアップにリカバリ・アプライアンスがアクセスできるようにします。

従来のバックアップの移行方法の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

タスク6: リカバリ要件を満たすcopy-to-tapeスケジュールの作成

環境でテープ・デバイスを利用する場合は、SBT属性セットの作成、テープ・ジョブのスケジュール設定、テープ・バックアップ・ステータスのモニタリングなどを行う必要があります。「リカバリ・アプライアンスでテープにバックアップをコピーする場合の基本的なタスク」の説明に従って、これらの手順すべてをリカバリ・アプライアンスで実行します。

タスク7: リカバリ・アプライアンス・レプリケーションの構成

このタスクには、アップストリーム・リカバリ・アプライアンスとダウンストリーム・リカバリ・アプライアンス両方の構成と、保護データベース・ホストでの手順の実行が含まれます。「リカバリ・アプライアンス・レプリケーションを構成するための基本的なタスク」を参照してください。

3.6 Recovery Applianceのメンテナンス・タスク

通常、次のタスクを実行する必要があります。

- タスク1: リカバリ・アプライアンスにおけるアクティビティのモニタリング

- タスク2: バックアップ・ジョブのモニタリング(DBA向け)

- タスク3: リカバリ・アプライアンスにおけるレポートの生成および確認

- タスク4: Recovery Applianceの再起動

タスク1: リカバリ・アプライアンスにおけるアクティビティのモニタリング

Cloud Controlを使用すると、リカバリ・アプライアンスをモニタリングして、ビジネス要件を満たしていることを確認できます。たとえば、次のように操作します。

- アラートまたは警告を確認します。

- 使用可能な領域がすべてのリカバリ・ウィンドウに対応できることを確認します。

- バックアップ・スループットがパフォーマンス要件を満たしていることを確認します。

「リカバリ・アプライアンスをモニタリングするための基本的なタスク」を参照してください。

タスク2: バックアップ・ジョブのモニタリング(DBA向け)

保護されたデータベースの管理者は、バックアップ・ジョブ・レポートでエラーを定期的にモニタリングする必要があります。

『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

タスク3: リカバリ・アプライアンスにおけるレポートの生成および確認

Cloud Controlを使用すると、記憶域使用状況および容量計画のBI Publisherレポートを生成および確認できます。

「リカバリ・アプライアンス・レポートにアクセスするための基本的なタスク」を参照してください。

タスク4: Recovery Applianceの再起動

必要に応じて、オペレーティング・システムのユーティリティおよびDBMS_RAプロシージャを使用してRecovery Applianceを停止および起動します。Recovery Applianceの再起動方法の詳細は、『Zero Data Loss Recovery Applianceオーナーズ・ガイド』を参照してください。

4 リカバリ・アプライアンスのためのCloud Controlスタート・ガイド

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)のリカバリ・アプライアンス用の主要ページへのアクセス方法について説明します。次の項が含まれます。

- エンタープライズのすべてのリカバリ・アプライアンスの表示

- リカバリ・アプライアンス・ホームページへのアクセス

- リカバリ・アプライアンスの記憶域の場所ページへのアクセス

4.1 エンタープライズのすべてのリカバリ・アプライアンスの表示

Cloud Controlにはエンタープライズのすべてのリカバリ・アプライアンスがリスト表示されます。このページで、任意のリカバリ・アプライアンスそれぞれのホームページにアクセスできます。

エンタープライズのすべてのリカバリ・アプライアンスを表示するには、次のようにします。

1. Cloud Controlのログイン・ページで、SYSMANのユーザー名とパスワードを入力します。
Enterprise Manager Cloud Control 12cへようこそページが表示されます。

関連項目:

リカバリ・アプライアンス環境のユーザー・アカウントの詳細は、「リカバリ・アプライアンス環境のユーザー・アカウント」を参照してください

2. 「ターゲット」を選択してから、「リカバリ・アプライアンス」を選択します。
リカバリ・アプライアンス・ページが表示されます。次の図はサンプル・ページのセクションです。

このページには、環境のすべてのリカバリ・アプライアンスの概要が表示されます。一部の列(たとえば「メンバー・ステータス」または「インシデントとイベント」)のリンクをクリックすると、詳細が含まれるページに移動します。

3. リカバリ・アプライアンスの可用性を表す円グラフを表示するには、「エンタープライズ」を選択し、「サマリー」を選択します。
エンタープライズ・サマリー・ページが表示されます。

4. 「概要」セクションの「表示」メニューで「リカバリ・アプライアンス」を選択します。
「ステータス」セクションの円グラフに、使用可能なリカバリ・アプライアンスのパーセンテージが示されます。次のサンプル画面では、モニタリングされている6個のリカバリ・アプライアンスの半数が現在使用可能であることを示しています。

関連項目:

これらのページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

4.2 リカバリ・アプライアンス・ホームページへのアクセス

リカバリ・アプライアンスのホームページは、リカバリ・アプライアンス環境の管理を集中的に行う司令部です。このページで、リカバリ・アプライアンスの記憶域とパフォーマンスを管理し、最近のアクティビティや注意が必要な問題を表示できます。リカバリ・アプライアンスのホームページは次のセクションに分かれます。

- サマリー
このセクションには、保護データベースの数が表示され、それらのヘルス・ステータス、現在のアクティビティおよび過去24時間以内のアクティビティを要約します。詳細は、「操作」列のリンク(「バックアップ」、「Copy-to-Tape」、「レプリケーション」および「リストア」)をクリックします。

- 保護されたデータベースの問題
このセクションでは、特に保護データベースのバックアップおよびリカバリ・ステータスに関連する問題が示されます。「表示」メニューを使用して、主要なカテゴリで情報をフィルタ処理できます。

- 送信/受信したデータ(日次)
このセクションには、過去1週間の毎日のスループットが表示されます。

- パフォーマンス
このセクションでは、データ転送速度と待機中のデータのパフォーマンス統計が図に表示されます。統計は、日、週または月でフィルタ処理できます。

- メディア・マネージャ
このセクションには、copy-to-tape操作のために構成されたメディア・マネージャが表示されます。

- 記憶域の場所
このセクションでは、使用可能な領域の合計と使用率が要約されます。すべてのデータベースのディスク・リカバリ・ウィンドウ目標を達成するために消費された容量や、指定された記憶域の場所へのデータベース・バックアップ用の予約済領域が領域の合計に占めるパーセンテージが示されます(「リカバリ・アプライアンスによる記憶域の管理方法」を参照)。

- レプリケーション
このセクションには、このリカバリ・アプライアンスのレプリケート先のダウンストリーム・リカバリ・アプライアンスと、このリカバリ・アプライアンスがバックアップを受信するアップストリーム・リカバリ・アプライアンスがリスト表示されます(「リカバリ・アプライアンス・レプリケーションについて」を参照)。

- インシデントとイベント
このセクションでは、リカバリ・アプライアンスに関連するすべてのターゲットに対するCloud Controlモニタリングによって生成されたすべての警告とアラートが要約されます。このセクションから問題の詳細にドリルダウンします。

リカバリ・アプライアンス・ホームページにアクセスするには、次のようにします。

1. Cloud Controlのログイン・ページで、SYSMANのユーザー名とパスワードを入力します。

関連項目:

リカバリ・アプライアンス環境のユーザー・アカウントの詳細は、「リカバリ・アプライアンス環境のユーザー・アカウント」を参照してください

2. Cloud Controlの任意のページで、「ターゲット」を選択してから、「リカバリ・アプライアンス」を選択します。
リカバリ・アプライアンス・ページが表示されます。

3. 「名前」列のリカバリ・アプライアンスの名前をクリックします。
選択したリカバリ・アプライアンスのホームページが表示されます。次の図はサンプル・ホームページの一部です。

このページで、リカバリ・アプライアンス全体のスナップショットを確認できます。また、リンクをクリックして特定の内容の詳細を参照できます。

4. 必要に応じて、メイン・メニューにアクセスするには、「リカバリ・アプライアンス」をクリックします。
メニューが表示されます。次の図はメニュー・オプションです。

このメニューから、このリカバリ・アプライアンスの管理、モニタリングおよびレポートに関連するすべてのページに移動できます。

関連項目:

これらのページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

4.3 リカバリ・アプライアンスの記憶域の場所ページへのアクセス

記憶域の場所ページは、リカバリ・アプライアンスのホームページの「記憶域の場所」セクションに示される情報をさらに詳しく説明します。このページには、記憶域に関連する次の情報が表示されます。

- リカバリ・アプライアンスの記憶域の場所にあるOracle ASMディスク・グループ

- 記憶域の場所を使用する保護ポリシーの数

- このリカバリ・アプライアンスで保護されるすべてのデータベースのディスク・リカバリ・ウィンドウ目標を達成するために必要な容量の合計(GB単位)

- このリカバリ・アプライアンスで保護されるすべてのデータベースの合計予約済領域

このページを使用して、既存の記憶域をモニタリングする他に、既存の記憶域の場所に記憶域を追加したり、新しい記憶域の場所を作成したりすることができます。

記憶域の場所ページにアクセスするには、次のようにします。

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 「リカバリ・アプライアンス」メニューで「記憶域の場所」を選択します。
リカバリ・アプライアンスのページに最初にログインするとき、または長い間ブラウザが非アクティブになっていたときは、リカバリ・アプライアンス・ログイン・ページが表示されます。

3. プロンプトが表示されたら、ログイン資格証明を入力して、「ログイン」をクリックします。
記憶域の場所ページが表示されます(図4-1)。

図4-1 記憶域の場所ページ

このページには、記憶域の場所の予約済と未予約の割合が視覚的にわかりやすく表現されます。前のサンプル・ページでは、DELTA記憶域の場所(デフォルト)が、構成されている唯一の記憶域の場所です。

4. 「記憶域の場所の詳細: DELTA」セクションで「リカバリ・ウィンドウ領域」をクリックします(まだ選択されていない場合)。
リカバリ・ウィンドウ領域サブページが表示されます。

図4-1のサンプルでは、必要なリカバリ・ウィンドウ領域の合計サイズは104491.8GBです。たとえば、保護データベース名CUSTOMERにカーソルを重ねると、このデータベースがリカバリ・ウィンドウを達成するために必要な記憶域の容量と、必要な合計記憶域に対するパーセンテージがメッセージとして示されます。

5. 「記憶域の場所の詳細: DELTA」セクションで「予約済領域」をクリックします。
予約済領域サブページが表示されます。

この図では、予約済領域の合計サイズは104491.8GBです。たとえば、保護データベース名CUSTOMERにカーソルを重ねると、このデータベースで必要な予約済領域の容量と、必要な合計記憶域に対するパーセンテージがメッセージとして示されます。

関連項目:

これらのページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

5 リカバリ・アプライアンスでの保護ポリシーの管理

この章では、「リカバリ・アプライアンスの設定と構成」に含まれる保護ポリシーとポーリング・ポリシーの管理方法を説明します。

この章の内容は次のとおりです。

- 保護ポリシーについて

- バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)

- 保護ポリシーの作成

- 保護ポリシーの更新

- 保護ポリシーの削除

5.1 保護ポリシーについて

保護ポリシーは、事前定義されたリカバリ・ウィンドウ目標に基づいてバックアップ記憶域の管理を制御するための中心メカニズムです。DBAの観点では、保護ポリシーの最も重要な要素はディスクとテープのリカバリ・ウィンドウです。

この項には次のトピックが含まれます:

- 保護ポリシーの目的

- 保護ポリシーの概要

- 保護ポリシーのユーザー・インタフェース

- 保護ポリシーを管理するための基本タスク

関連項目:

アーキテクチャの概要については、「保護ポリシー」を参照してください

5.1.1 保護ポリシーの目的

保護ポリシーは、関連付けられるすべてのデータベースの次の項目を指定します。

- ディスク・バックアップのリカバリ・ウィンドウ目標

- テープ・バックアップのリカバリ・ウィンドウ

- バックアップの削除前にリカバリ・アプライアンスがレプリケートまたはテープへのコピーを行う必要があるか

- バックアップに使用されるリカバリ・アプライアンスの記憶域の場所

- バックアップ・ポーリング・ポリシー(オプション)

複数の保護データベースを1つの保護ポリシーに関連付けることができます。リカバリ・アプライアンスは、様々なデータ保護サポート・レベルに対応するために多様な保護ポリシーを使用できます。たとえば、保護ポリシーを一般的なサービス・レベル(ゴールド、シルバーおよびブロンズ)に合せて作成できます。あるいは、保護データベースとアプリケーションの固有の要件に合せることもできます。

5.1.2 保護ポリシーの概要

保護ポリシーは、リカバリ・アプライアンスのメタデータ・データベースに記録される、名前が付けられた論理オブジェクトです。保護データベースをリカバリ・アプライアンスに追加するには、特定の保護ポリシーに関連付ける必要があります。「保護ポリシー」で説明されているように、デフォルトの保護ポリシーは、プラチナ、ゴールド、シルバーおよびブロンズです。

各保護ポリシーは、ディスクおよびテープのリカバリ・ウィンドウに関して異なる値を指定します。これらの値は、ポリシーによって保護される各データベースに適用されます。たとえば、図5-1は、それぞれに異なる保護データベースが割り当てられている3つのデフォルト保護ポリシーを示します。この例では、データベースprod3およびprod11は同じポリシー内にあるため、両方に3日間の同じディスク・リカバリ・ウィンドウ目標があります。

図5-1 保護ポリシー

関連項目:

「保護ポリシー」

5.1.3 保護ポリシーのユーザー・インタフェース

この項には次のトピックが含まれます:

- Cloud Controlの保護ポリシーの作成ページへのアクセス

- 保護ポリシーに関連するDBMS_RAプロシージャ

- 保護ポリシーのリカバリ・カタログ・ビュー

5.1.3.1 Cloud Controlの保護ポリシーの作成ページへのアクセス

Oracle Enterprise Manager Cloud Control (Cloud Control)の保護ポリシーの作成ページは、保護ポリシーを作成するための推奨インタフェースです。

保護ポリシーの作成ページにアクセスするには、次のようにします。

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 「リカバリ・アプライアンス」メニューで「保護ポリシー」を選択します。
リカバリ・アプライアンス・ログイン・ページが表示されます。

3. ログイン資格証明を入力して、「ログイン」をクリックします。
保護ポリシー・ページが表示されます(図5-2の例)。

図5-2 保護ポリシー・ページ

関連項目:

保護ポリシー・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

5.1.3.2 保護ポリシーに関連するDBMS_RAプロシージャ

DBMS_RAパッケージを使用して、保護ポリシーを作成および管理できます。表5-1に、保護ポリシーに関連する主なプログラム・ユニットを示します。

表5-1 DBMS_RA保護ポリシー・プロシージャ

プログラム・ユニット

説明

CREATE_POLLING_POLICY

バックアップ・ポーリング・ポリシーを作成します。

CREATE_PROTECTION_POLICY

保護ポリシーを作成します。

DELETE_PROTECTION_POLICY

保護ポリシーを削除します。

関連項目:

DBMS_RAパッケージのリファレンス

5.1.3.3 保護ポリシーのリカバリ・カタログ・ビュー

リカバリ・アプライアンスのカタログ・ビューを使用して保護ポリシーをモニタリングできます。表5-2に、保護ポリシーとの関連が深いビューをまとめています。

表5-2 保護ポリシーのリカバリ・カタログ・ビュー

ビュー

説明

RA_PROTECTION_POLICY

このビューは、定義済の保護ポリシーを示します。

RA_POLLING_POLICY

このビューは、定義済のバックアップ・ポーリング・ポリシーを示します。

RA_DATABASE

このビューのPOLICY_NAME列に、この保護データベースで使用される保護ポリシーが示されます。

RA_REPLICATION_SERVER

このビューのPROTECTION_POLICY列に、レプリケーションで使用される特定のリカバリ・アプライアンスの保護ポリシーが示されます。

関連項目:

リカバリ・アプライアンスのビュー・リファレンス

5.1.4 保護ポリシーを管理するための基本タスク

この項では、保護ポリシーの管理に含まれる基本的なタスクについて説明します。図5-3は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、保護ポリシーのタスクを強調して示したものです。

図5-3 リカバリ・アプライアンス・ワークフローの保護ポリシー・タスク

通常、保護ポリシーのタスクを実行する順序は次のとおりです。

1. 計画フェーズでは、データベースを階層でグループ分けし、各階層のリカバリ要件を決定します。
「リカバリ・アプライアンスの計画」でこれらのタスクを説明しています。

2. 構成フェーズ(「リカバリ・アプライアンスの設定と構成」を参照)では、各データベース階層に1つの保護ポリシーを作成します。

a. バックアップ・ポーリングの場所へのアクセス権がリカバリ・アプライアンスにあり、コマンドライン・ツールを使用して構成を実行している場合は、必要に応じて、バックアップ・ポーリング・ポリシーを作成します。
「バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)」でこのタスクについて説明しています。

注意:

Cloud Controlを使用すると、ポーリング・ポリシーと保護ポリシーを同じページで構成できます。

b. 特定のデータベース階層の保護ポリシーを作成します。
「保護ポリシーの作成」でこのタスクについて説明しています。

3. 進行中のメンテナンス・フェーズでは(「Recovery Applianceのメンテナンス・タスク」を参照)、必要に応じて保護ポリシーを変更します。一般的な変更タスクには次のものがあります。

- 保護ポリシーの属性を更新します。
「保護ポリシーの更新」でこのタスクについて説明しています。

- 保護ポリシーを削除します。
「保護ポリシーの削除」でこのタスクについて説明しています。

5.2 バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)

オプションのバックアップ・ポーリング・ポリシーによって、保護データベースがリカバリ・アプライアンスと直接やりとりせずにバックアップ・セットを配置するディレクトリが定義されます。バックアップ・ポーリング・ディレクトリは、外部ファイル・システムに作成し、リカバリ・アプライアンスからNFSマウント・ポイントとしてアクセスできるようにしておく必要があります。ポーリング・ポリシーでは、記憶域のファイル・システム・パスと、リカバリ・アプライアンスが新しいバックアップ・セット(イメージ・コピーではない)をチェックする頻度を定義します。保護ポリシー内にポーリング・ポリシー名を指定します。

注意:

バックアップ・ポリシーを作成する個別の手順はCloud Controlでは必要ありません。保護ポリシーの作成ページに含まれています。

バックアップ・ポーリング・ポリシーが役立つのはシナリオは次のとおりです。

- リカバリ・アプライアンスがオフラインになった場合、保護データベースがバックアップ・ポーリングの場所にバックアップの送信を続けられます。リカバリ・アプライアンスがオンラインになったときに、これらの場所でバックアップをポーリングします。

- 記憶域のネットワークがイーサネットよりも高速な場合に、ポーリングの場所をネットワーク記憶域に構成すると、保護データベースがポーリングの場所にバックアップするほうが速くなることがあります。

- 従来のバックアップをリカバリ・アプライアンスに移行するときに、ポーリングの場所を使用できます。

「バックアップ・ポーリングの場所」で説明しているように、バックアップ・ポーリングを使用する保護データベースは、バックアップ・ピースとアーカイブREDOログ・ファイルを共有記憶域に格納します。リカバリ・アプライアンスは、共有記憶域のバックアップを定期的に取得して処理します。

前提条件

メタデータ・データベースにRASYSとしてログインする必要があります。

前提条件

次の要件を満たすポーリング・ポリシーを作成するとします。

- リカバリ・アプライアンスは、/u03/shared/polling1ディレクトリ(リカバリ・アプライアンスとすべての保護データベースからアクセスできる共有ディレクトリ)をポーリングする必要があります。

- リカバリ・アプライアンスが、4時間ごとに共有ディレクトリをポーリングします。

- リカバリ・アプライアンスが、共有ディレクトリのバックアップを処理した後で削除します。

バックアップ・ポーリング・ポリシーを作成するには、次のようにします。

1. SQL*PlusまたはSQL Developerを起動し、RASYSとしてメタデータ・データベースにログインします。

2. DBMS_RA.CREATE_POLLING_POLICYプロシージャを実行します。
たとえば、次のPL/SQL無名ブロックを実行します。

BEGIN
DBMS_RA.CREATE_POLLING_POLICY (
polling_policy_name   => 'nas_polling1',
polling_location      => '/u03/shared/polling1',
polling_frequency     =>  INTERVAL '4' HOUR,
delete_input          =>  TRUE);
END;

3. 必要に応じて、リカバリ・カタログを問い合せてポリシーが作成されたことを確認します。
たとえば、次のようにRA_POLLING_POLICYを問い合せます(出力例も示します)。

COL POLLING_NAME FORMAT a15
COL DEST FORMAT a40
SELECT POLLING_NAME, DEST, DELETE_INPUT,
TO_CHAR(EXTRACT(DAY FROM FREQUENCY),'fm00')||':'||
TO_CHAR(EXTRACT(HOUR FROM FREQUENCY),'fm00')||':'||
TO_CHAR(EXTRACT(MINUTE FROM FREQUENCY),'fm00')||':'||
TO_CHAR(EXTRACT(SECOND FROM FREQUENCY),'fm00')
AS "DD:HH:MM:SS"
FROM   RA_POLLING_POLICY;

POLLING_NAME    DEST                                     DELET DD:HH:MM:SS
--------------- ---------------------------------------- ----- ---------------
NAS_POLLING1    /u03/shared/polling1/                    TRUE  00:04:00:00

関連項目:

- ポーリングの詳細は、「バックアップ・ポーリング・ポリシー」を参照してください

- プロシージャの引数の詳細は、「CREATE_POLLING_POLICY」を参照してください

5.3 保護ポリシーの作成

この項では、Cloud Control (推奨)またはDBMS_RA.CREATE_PROTECTION_POLICYプロシージャを使用して保護ポリシーを作成する方法について説明します。ベスト・プラクティスは、データベースの各階層に別の保護ポリシーを作成することです(「タスク1: 保護データベースの階層グループ分け」を参照)。

5.3.1 Cloud Controlを使用した保護ポリシーの作成

この項では、Cloud Controlの保護ポリシー・ページで保護ポリシーを作成する方法について説明します。

前提条件

次の前提条件を満たしている必要があります。

- RASYSとしてリカバリ・アプライアンスにログインする必要があります。

- 保護ポリシーを、いずれかの保護データベースに関連付ける必要があります。1つ以上のデータベースに関連付けられたポリシーを削除するには、それらのデータベースを別のポリシーに関連付ける必要があります。その後、目的のポリシーを削除できます。

前提条件

開発環境のデータベース階層に対してbronze_devという名前の保護ポリシーを作成します。このポリシーによって保護されるすべてのデータベースの要件は次のとおりです。

- ディスク・リカバリ・ウィンドウ目標は3日間であり、ディスク・バックアップを使用してすべてのデータベースを現在時刻から3日間前までの任意の時点にリカバリできる必要があります。

- バックアップをテープにアーカイブする必要はありません。

- 使用可能な記憶域が不足するために古いバックアップを削除しなければならない場合にも、リカバリ・アプライアンスが新しいバックアップを受信できるようにします(「リカバリ・アプライアンスによる記憶域の管理方法」を参照)。

- バックアップ・ポーリング・ポリシーは有効にしません(「バックアップ・ポーリング・ポリシー」を参照)。

保護ポリシーを作成するには、次のようにします。

1. 「Cloud Controlの保護ポリシーの作成ページへのアクセス」の説明に従って、保護ポリシーの作成ページにアクセスします。

2. 「作成」をクリックします。
保護ポリシーの作成ページが表示されます。

図5-4 保護ポリシーの作成ページ

このページでは、デフォルトのリカバリ・アプライアンスの記憶域の場所DELTAがすでに選択されています。

3. 次の値を入力します。

- 「名前」フィールドに新しい保護ポリシーの名前を入力します。
たとえば、bronze_devを入力します。

- 「説明」フィールドに、新しいポリシーの説明を入力します。
たとえば、「Policy with disk recovery window of 3 days and no tape backup」と入力します。

- 「ディスク・リカバリ・ウィンドウ目標」セクションの「リカバリ・ウィンドウ」フィールドに、リカバリ・アプライアンスがディスク・バックアップを使用したポイント・イン・タイム・リカバリに関して達成する必要があるリカバリ・ウィンドウ目標を指定し、単位を選択します。
たとえば、3を入力して、「日」を選択します。

- 「保護されていないデータ・ウィンドウのしきい値」セクションの「しきい値」フィールドに、データ損失を許容できる最長期間を入力します。
たとえば、5を入力して、「分」を選択します。

- 必要に応じて、「メディア・マネージャ・リカバリ・ウィンドウ・ポリシー」の「リカバリ・ウィンドウ」フィールドに、メディア・マネージャがポイント・イン・タイム・リカバリを実行できるさらに長いウィンドウを指定できます。
たとえば、テープ・バックアップの必要がない場合はこのフィールドを空にしておきます。

- 「最大ディスク・バックアップ保存期間」セクションの「最大保存」フィールドに、リカバリ・アプライアンスがディスク・バックアップを保存する必要がある最大期間を入力します。
たとえば、このフィールドを空にしておくと、明示的にパージする場合や記憶域の場所に領域不足がある場合を除き、リカバリ・アプライアンスによってバックアップがパージされません。

- 必要に応じて、「バックアップのポーリング位置」セクションでバックアップ・ポーリング・ポリシーを定義します(「バックアップ・ポーリングの場所」を参照)。

- 「場所」フィールドに、リカバリ・アプライアンスでアクセスできるディレクトリを指定します。

- 「頻度」フィールドに、間隔を指定し、時間の単位を入力します。

- リカバリ・アプライアンスがバックアップをコピーした後でポーリングの場所からバックアップを削除するように指定するには、「コピー後にバックアップを削除」を選択します。

たとえば、バックアップ・ポーリングを無効にするように指定するには、フィールドを空にしておきます。

- 「バックアップ・コピー・ポリシー」セクションで、リカバリ・アプライアンスがバックアップを削除する前にレプリケートまたはテープへのコピーを行う必要があるかどうかを指定します。
たとえば、「たとえまだテープにコピーまたはレプリケートされていない既存のバックアップを削除する必要があっても、新規のバックアップを常に受け入れます。」を選択します。

4. 「OK」をクリックします。
保護ポリシー・ページが表示され、新たに作成された保護ポリシーがリスト表示されます。

関連項目:

保護ポリシーの作成・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

5.3.2 DBMS_RAを使用した保護ポリシーの作成

保護ポリシーを作成するには、DBMS_RA.CREATE_PROTECTION_POLICYプロシージャを実行します。

前提条件

メタデータ・データベースにRASYSとしてログインする必要があります。

前提条件

開発環境のデータベース階層に対してbronze_devという名前の保護ポリシーを作成します。このポリシーによって保護されるすべてのデータベースの要件は次のとおりです。

- ディスク・リカバリ・ウィンドウ目標は3日間であり、ディスク・バックアップを使用してすべてのデータベースを現在時刻から3日間前までの任意の時点にリカバリできる必要があります。

- バックアップをテープにアーカイブする必要はありません。

- 使用可能な記憶域が不足するために古いバックアップを削除しなければならない場合にも、リカバリ・アプライアンスが新しいバックアップを受信できるようにします(「コピーの保証」を参照)。

- バックアップ・ポーリング・ポリシーは有効にしません(「バックアップ・ポーリング・ポリシー」を参照)。

また、リカバリ・ウィンドウ目標が35日間のポリシーgold_devと10日間のポリシーsilver_devも作成します。さらに、ディスク・リカバリ・ウィンドウ目標が12時間のtest_devという名前のポリシーも作成します。

保護ポリシーを作成するには、次のようにします。

1. SQL*PlusまたはSQL Developerを起動し、RASYSとしてメタデータ・データベースにログインします。

2. DBMS_RA.CREATE_PROTECTION_POLICYプロシージャを実行します。
たとえば、次のPL/SQL無名ブロックを実行します。

BEGIN
DBMS_RA.CREATE_PROTECTION_POLICY (
protection_policy_name => 'bronze_dev',
description            => 'For protected dbs in bronze tier',
storage_location_name  => 'delta',
recovery_window_goal   => INTERVAL '3' DAY,
guaranteed_copy        => 'NO');
DBMS_RA.CREATE_PROTECTION_POLICY (
protection_policy_name => 'silver_dev',
description            => 'For protected dbs in silver tier',
storage_location_name  => 'delta',
recovery_window_goal   => INTERVAL '10' DAY,
guaranteed_copy        => 'NO');
DBMS_RA.CREATE_PROTECTION_POLICY (
protection_policy_name => 'gold_dev',
description            => 'For protected dbs in gold tier',
storage_location_name  => 'delta',
recovery_window_goal   => INTERVAL '35' DAY,
guaranteed_copy        => 'NO');
DBMS_RA.CREATE_PROTECTION_POLICY (
protection_policy_name => 'test_dev',
description            => 'Test policy',
storage_location_name  => 'delta',
recovery_window_goal   => INTERVAL '12' HOUR,
guaranteed_copy        => 'NO');
END;

3. 必要に応じて、リカバリ・カタログを問い合せてポリシーが作成されたことを確認します。
たとえば、次のようにRA_PROTECTION_POLICYを問い合せます(出力例も示します)。

COL POLICY_NAME FORMAT a11
COL DESCRIPTION FORMAT a36
SELECT POLICY_NAME, DESCRIPTION,
TO_CHAR(EXTRACT(DAY FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
TO_CHAR(EXTRACT(HOUR FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
TO_CHAR(EXTRACT(MINUTE FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
TO_CHAR(EXTRACT(SECOND FROM RECOVERY_WINDOW_GOAL),'fm00')
AS "DD:HH:MM:SS"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME LIKE '%DEV'
ORDER BY POLICY_NAME;

POLICY_NAME DESCRIPTION                          DD:HH:MM:SS
----------- ------------------------------------ ---------------
BRONZE_DEV  For protected dbs in bronze_dev tier 03:00:00:00
GOLD_DEV    For protected dbs in gold_dev tier   35:00:00:00
SILVER_DEV  For protected dbs in silver_dev tier 10:00:00:00
TEST_DEV    Test policy                          00:12:00:00

5.4 保護ポリシーの更新

この項では、Cloud Control (推奨)またはDBMS_RA PL/SQLパッケージを使用して保護ポリシーを更新する方法について説明します。

5.4.1 Cloud Controlを使用した保護ポリシーの更新

この項では、Cloud Controlの保護ポリシー・ページで保護ポリシーを更新する方法について説明します。

前提条件

RASYSとしてリカバリ・アプライアンスにログインする必要があります。

前提条件

「Cloud Controlを使用した保護ポリシーの作成」の説明に従って、bronze_devポリシーを作成したと仮定します。ディスク・リカバリ・ウィンドウ目標を3日間から6日間に更新します。

保護ポリシーを更新するには、次のようにします。

1. 「Cloud Controlの保護ポリシーの作成ページへのアクセス」の説明に従って、保護ポリシーの作成ページにアクセスします。

2. 「保護ポリシー」表で、編集する保護ポリシーを選択します。
たとえば、BRONZE_DEVの行を選択します。

3. 「編集」をクリックします。
保護ポリシーの編集ページが表示されます。

4. 必要に応じて値を変更し、「OK」をクリックします。
たとえば、「ディスク・リカバリ・ウィンドウ目標」セクションの「リカバリ・ウィンドウ」フィールドに6を入力します。

保護ポリシー・ページが表示され、新たに更新された保護ポリシーがリスト表示されます。

関連項目:

保護ポリシー・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

5.4.2 DBMS_RAを使用した保護ポリシーの更新

保護ポリシーを更新するには、DBMS_RA.UPDATE_PROTECTION_POLICYプロシージャを実行します。nullのパラメータは既存の値を維持します。たとえば、ある保護ポリシーでguaranteed_copyが現在NOになっている場合にDBMS_RA.UPDATE_PROTECTION_POLICYでこのパラメータにnullを指定すると、値はNOのままです。

前提条件

メタデータ・データベースにRASYSとしてログインする必要があります。「DBMS_RAを使用した保護ポリシーの作成」で作成した保護ポリシーbronze_devが存在する必要があります。

前提条件

bronze_devのディスク・リカバリ・ウィンドウ目標を3日間から6日間に変更するとします。

既存の保護ポリシーの属性を更新するには、次のようにします。

1. SQL*PlusまたはSQL Developerを起動し、RASYSとしてメタデータ・データベースにログインします。

2. DBMS_RA.UPDATE_PROTECTION_POLICYプロシージャを実行します。
たとえば、次のPL/SQL無名ブロックを実行します。

BEGIN
DBMS_RA.UPDATE_PROTECTION_POLICY(
protection_policy_name => 'bronze_dev',
recovery_window_goal   => INTERVAL '6' DAY);
END;

3. 必要に応じて、リカバリ・カタログを問い合せてポリシーが更新されたことを確認します。
たとえば、次のようにRA_PROTECTION_POLICYを問い合せます(出力例も示します)。

COL POLICY_NAME FORMAT a11
COL DESCRIPTION FORMAT a36
SELECT POLICY_NAME, DESCRIPTION,
TO_CHAR(EXTRACT(DAY FROM RECOVERY_WINDOW_GOAL),'fm00')    ||':'||
TO_CHAR(EXTRACT(HOUR FROM RECOVERY_WINDOW_GOAL),'fm00')   ||':'||
TO_CHAR(EXTRACT(MINUTE FROM RECOVERY_WINDOW_GOAL),'fm00') ||':'||
TO_CHAR(EXTRACT(SECOND FROM RECOVERY_WINDOW_GOAL),'fm00')
AS "DD:HH:MM:SS"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME='BRONZE_DEV';

POLICY_NAME DESCRIPTION                          DD:HH:MM:SS
----------- ------------------------------------ ---------------
BRONZE_DEV  For protected dbs in bronze tier     06:00:00:00

5.5 保護ポリシーの削除

この項では、Cloud Control (推奨)またはDBMS_RA PL/SQLパッケージを使用して保護ポリシーを削除する方法について説明します。

5.5.1 Cloud Controlを使用した保護ポリシーの削除

この項では、Cloud Controlの保護ポリシー・ページで保護ポリシーを削除する方法について説明します。

前提条件

RASYSとしてリカバリ・アプライアンスにログインする必要があります。

前提条件

「Cloud Controlを使用した保護ポリシーの作成」の説明に従って、bronze_devポリシーを作成したと仮定します。このポリシーを削除します。

保護ポリシーを削除するには、次のようにします。

1. 「Cloud Controlの保護ポリシーの作成ページへのアクセス」の説明に従って、保護ポリシーの作成ページにアクセスします。

2. 「保護ポリシー」表で、削除する保護ポリシーを選択します。
たとえば、BRONZE_DEVの行を選択します。

3. 「削除」をクリックします。
確認を求めるウィンドウが表示されます。

4. 「はい」をクリックします。
保護ポリシー・ページが表示され、削除された保護ポリシーの表示がなくなっています。

関連項目:

保護ポリシー・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

5.5.2 DBMS_RAを使用した保護ポリシーの削除

保護ポリシーを削除するには、DBMS_RA.DELETE_PROTECTION_POLICYプロシージャを実行します。

前提条件

次の前提条件を満たしている必要があります。

- RASYSとしてメタデータ・データベースにログインする必要があります。

- 保護ポリシーを、いずれかの保護データベースに関連付ける必要があります。1つ以上のデータベースに関連付けられたポリシーを削除するには、それらのデータベースを別のポリシーに関連付ける必要があります。その後、目的のポリシーを削除できます。

前提条件

「保護ポリシーの作成」で作成した保護ポリシーtest_devを削除するとします。

保護ポリシーを削除するには、次のようにします。

1. SQL*PlusまたはSQL Developerを起動し、RASYSとしてメタデータ・データベースにログインします。

2. 削除しようとする保護ポリシーが保護データベースに現在関連付けられていないことを確認します。
たとえば、次のようにしてデータベースに関連付けられていないすべての保護ポリシーを問い合せます。

SELECT POLICY_NAME AS "Currently unused policy"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME NOT IN (SELECT POLICY_NAME FROM RA_DATABASE)
ORDER BY POLICY_NAME;

Currently unused policy
-----------------------
TEST_DEV

3. ポリシーを削除します。
たとえば、次のPL/SQL匿名ブロックを実行すると、保護ポリシーtest_devが削除されます。

BEGIN
DBMS_RA.DELETE_PROTECTION_POLICY(
protection_policy_name => 'test_dev');
END;

4. 必要に応じて、削除を確認します。
たとえば、test_devという名前のポリシーの行をカウントします(出力例も示します)。

SELECT COUNT(*)
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME = 'TEST_DEV';

COUNT(*)
----------
0

6 保護されたデータベース・アクセスのためのリカバリ・アプライアンスの構成

この章の内容は次のとおりです。

- 保護されたデータベース・アクセスについて

- 仮想プライベート・カタログ・アカウントの作成

- 保護されたデータベースの登録

- 保護されたデータベースのプロパティの更新

6.1 保護されたデータベース・アクセスについて

この項には次のトピックが含まれます:

- 保護されたデータベース・アクセスの目的

- 保護されたデータベース・アクセスの概要

- 保護されたデータベース・アクセスを構成するためのユーザー・インタフェース

- 保護されたデータベース・アクセスを構成するための基本的なタスク

関連項目:

「リカバリ・アプライアンスのアーキテクチャ」

6.1.1 保護されたデータベース・アクセスの目的

データベース・バックアップにアクセスできるようになるまで、データベースはリカバリ・アプライアンスによって保護されていません。

6.1.2 保護されたデータベース・アクセスの概要

必要な構成を実行して保護されたデータベースがリカバリ・アプライアンスにバックアップを送信できるようにすることを、データベースの登録と呼びます。登録は、リカバリ・アプライアンスを使用するように保護されたデータベースを初めて設定するときに実行すべき、1回かぎりのタスクです。このタスクでは、リカバリ・アプライアンスと保護されたデータベースの両方での構成が必要となります。

基本的な登録手順は、次のとおりです。

1. データベースの追加
データベースをリカバリ・アプライアンスに追加するプロセスでは、データベースのメタデータをリカバリ・アプライアンスのメタデータ・データベースに追加して、このデータベースを指定した保護ポリシーに割り当てます。DBMS_RA.ADD_DBを実行すると、保護されていないデータベースのステータスが「保護されたデータベース」になります。

2. データベースへのアクセス権をリカバリ・アプライアンス・ユーザー・アカウントに付与
メタデータ・データベースで仮想プライベート・カタログ・アカウント(リカバリ・アプライアンス・ユーザー)を作成した後、リカバリ・アプライアンスでDBMS_RA.GRANT_DB_ACCESSを実行して、このアカウントを保護されたデータベースに関連付けます。

3. データベースを仮想プライベート・カタログに登録
保護されたデータベース・ホストでOracleウォレットを作成し、仮想プライベート・カタログ・アカウントの資格証明を追加します。RMAN REGISTER DATABASEコマンドを使用して、保護されたデータベースをリカバリ・カタログに登録します。

注意:

リアルタイムREDOトランスポートを構成する場合は、保護されたデータベースでいくつかのSQL文を実行する必要があります(『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照)。

図6-1に、保護されたデータベース(CONNECT TARGET)および仮想プライベート・カタログ(CONNECT CATALOG)に接続しているRMANクライアントを示します。バックアップ操作とリストア操作を可能にするには、保護されたデータベース・ホストのOracleウォレットに仮想プライベート・カタログ所有者が存在する必要があります。

図6-1 保護されたデータベース・アクセス

ファイルをリカバリ・アプライアンスにバックアップしなくても、リカバリ・アプライアンス・カタログにデータベースのメタデータを保存できます。この場合、データベースのステータスは保護されたデータベースではないため、リカバリ・アプライアンスには登録されません。仮想プライベート・カタログ所有者がすでに存在し、作成する必要がないため、こうしたデータベースの将来の登録は簡単になります。

6.1.3 保護されたデータベース・アクセスを構成するためのユーザー・インタフェース

この項には次のトピックが含まれます:

- Cloud Controlでの保護されたデータベース・ページへのアクセス

- 保護されたデータベース・アクセスに関連するDBMS_RAプロシージャ

- 保護されたデータベース・アクセスのリカバリ・カタログ・ビュー

6.1.3.1 Cloud Controlでの保護されたデータベース・ページへのアクセス

Oracle Enterprise Manager Cloud Control (Cloud Control)の保護されたデータベース・ページは、データベース登録プロセスを開始するための推奨インタフェースです。

保護されたデータベース・ページには、リカバリ・アプライアンスに直接バックアップされるか、またはダウンストリーム・リカバリ・アプライアンス・レプリケーション用に構成されるかにかかわらず(「リカバリ・アプライアンス・レプリケーションについて」を参照)、このリカバリ・アプライアンスで管理されるすべてのデータベースが一覧表示されます。このページでは、個々のデータベース、複数のデータベースまたは前に定義したEnterprise Managerグループを選択して、保護されたデータベースを追加できます。

保護されたデータベース・ページにアクセスするには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 「リカバリ・アプライアンス」メニューから、「保護されたデータベース」を選択します。
図6-2に示すように、保護されたデータベース・ページが表示されます。

図6-2 保護されたデータベース・ページ

関連項目:

保護されたデータベース・ページの詳細は、Cloud Controlオンライン・ヘルプを参照してください。

6.1.3.2 保護されたデータベース・アクセスに関連するDBMS_RAプロシージャ

DBMS_RAパッケージを使用して、保護されたデータベース・アクセスを構成できます。表6-1で、保護されたデータベースに関連する主なプログラム・ユニットについて説明します。

表6-1 保護されたデータベース・アクセスのDBMS_RAプロシージャ

プログラム・ユニット

説明

ADD_DB

指定したデータベースのメタデータでをリカバリ・アプライアンスに追加して、保護ポリシーをデータベースに割り当てます。reserved_spaceパラメータを設定する必要がある点に注意してください。

DELETE_DB

指定したデータベースのメタデータをリカバリ・アプライアンスから削除します。このデータベースのすべてのメタデータとバックアップが、ディスクとSBTの両方から削除されます。

GRANT_DB_ACCESS

指定したデータベースについて、リカバリ・アプライアンス権限をユーザーに付与します。

REVOKE_DB_ACCESS

指定したデータベースについて、リカバリ・アプライアンス権限をユーザーから取り消します。

UPDATE_PROTECTION_POLICY

既存の保護ポリシーのパラメータを変更します。

関連項目:

DBMS_RAパッケージのリファレンス

6.1.3.3 保護されたデータベース・アクセスのリカバリ・カタログ・ビュー

リカバリ・アプライアンス・カタログ・ビューを使用して、データベース・アクセスをモニターできます。表6-2に、最も関係のあるビューについてまとめます。

表6-2 保護されたデータベース・アクセスのリカバリ・カタログ・ビュー

ビュー

説明

RA_DATABASE

このビューでは、このリカバリ・アプライアンスで保護されているデータベースについて説明します。

RA_DB_ACCESS

このビューでは、特定の保護されたデータベースにアクセスできるユーザー・アカウントについて説明します。

関連項目:

リカバリ・アプライアンスのビュー・リファレンス

6.1.4 保護されたデータベース・アクセスを構成するための基本的なタスク

この項では、保護されたデータベース・アクセスを構成する場合の基本的なタスクについて説明します。図6-3は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、リカバリ・アプライアンスの構成タスクを強調して示したものです。

図6-3 リカバリ・アプライアンス・ワークフローでのデータベース・アクセス構成タスク

一般に、保護されたデータベース・アクセスは次の順序で構成します。

1. 計画フェーズでは、リカバリ・アプライアンスで保護するデータベースを決定します。
このタスクについては、タスク4: 「リカバリ・アプライアンスのアクセス要件の決定」に説明されています。

2. 構成フェーズでは、次を行います(「リカバリ・アプライアンスの設定と構成」を参照)。

a. 仮想プライベート・カタログ・アカウントを作成します。
このタスクについては、「仮想プライベート・カタログ・アカウントの作成」に説明されています。

b. 保護されたデータベースをリカバリ・アプライアンスに登録します。

注意:

Cloud Controlでは、リカバリ・カタログでのデータベースの登録を除き、すべての登録手順を単一のページで実行できます。

このタスクについては、「保護されたデータベースの登録」に説明されています。

3. 進行中のメンテナンス・フェーズでは(「Recovery Applianceのメンテナンス・タスク」を参照)、次を実行できます。

- DBMS_RA.UPDATE_DBを使用して、既存の保護されたデータベースのプロパティを更新します(「保護されたデータベースのプロパティの更新」を参照)。

- DBMS_RA.DELETE_DBを使用して、保護されたデータベースのメタデータをリカバリ・アプライアンスから削除します。

- DBMS_RA.REVOKE_DB_ACCESSを使用して、特定の仮想プライベート・カタログ所有者から特定の保護されたデータベースへのアクセス権を取り消します。

6.2 仮想プライベート・カタログ・アカウントの作成

リカバリ・アプライアンスにバックアップする際は、RMANをリカバリ・アプライアンス・カタログに接続する必要があります。この手順では、特定の保護されたデータベースまたは一連の保護されたデータベースの仮想プライベート・カタログ・ユーザーを作成します。

前提条件

SYSTEMとしてメタデータ・データベースにログインします。

前提条件

次の要件を持つリカバリ・アプライアンス管理者であると想定します。

- データベースorcldをリカバリ・アプライアンスに登録します。

- ravpc1という名前の仮想プライベート・カタログ・アカウントを作成します。orcldをバックアップする際、ravpc1資格証明を使用してCONNECT CATALOGを実行します。

仮想プライベート・カタログ・アカウントを作成するには:

1. SQL*PlusまたはSQL Developerで、SYSTEMとしてリカバリ・アプライアンス・データベースに接続します。

2. 仮想プライベート・カタログを所有するCREATE SESSION権限を持つデータベース・ユーザー・アカウントを作成します。
たとえば、次の文を実行して、CREATE SESSION権限を持つユーザー・アカウントravpc1を作成します。

GRANT CREATE SESSION TO ravpc1 IDENTIFIED BY password;

関連項目:

- データベース・ユーザー・アカウントの作成方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- Cloud Controlを使用してデータベース・ユーザー・アカウントを作成する方法については、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

- 仮想プライベート・カタログについては、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

6.3 保護されたデータベースの登録

この項では、Cloud Control (推奨)またはDBMS_RAコマンドライン・インタフェースを使用して、保護されたデータベースを登録する方法について説明します。

関連項目:

リカバリ・アプライアンスにデータベースを登録する主な前提条件の詳細は、My Oracle SupportノートのドキュメントID 1995866.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=1995866.1)を参照してください

6.3.1 Cloud Controlを使用した保護されたデータベースの登録

この項では、Cloud Controlで保護されたデータベース・ページからデータベース登録プロセスを開始する方法を説明します。

前提条件

リカバリ・アプライアンスに登録するデータベースが、Cloud Controlによってデータベース・インスタンス・ターゲットとして検出されている必要があります。

前提条件

次のビジネス要件があると想定します。

- データベースORCL11およびORCL12を登録します。

- これらのデータベースを、GOLDという保護ポリシーに割り当てます。

- 新たに登録するデータベースにそれぞれ6355 GBの予約済領域(保護されたデータベースそれぞれに保証されるディスク領域の量)を確保します。

保護されたデータベースを登録するには:

1. 「Cloud Controlでの保護されたデータベース・ページへのアクセス」に説明されているとおりに、保護されたデータベース・ページにアクセスします。

2. 「追加」をクリックします。
保護されたデータベースの追加ページが表示されます。

図6-4 保護されたデータベースの追加ページ

3. 「追加」をクリックします。
「ターゲットの選択」ページが表示されます。

4. 「ターゲット・タイプ」で「データベース・インスタンス」を選択します。
ページがリフレッシュされ、データベース・インスタンスのみが表示されます。

5. オプションで、「ターゲット名」および「ホスト上」フィールドに値を入力して、データベース・インスタンスの範囲を絞ります。
この例では、次の手順でデータベースを複数選択できるように、フィールドは空白のままにします。

6. ターゲットの表で、Ctrlキーを押しながら必要なデータベースをクリックします。
たとえば、ターゲット・リストからORCL11とORCL12を選択します。

7. 「選択」をクリックします。
登録するデータベースをリストする保護されたデータベースの追加ページが表示されます。

8. 「保護ポリシー」セクションで、データベースを追加するポリシーをクリックして「次」をクリックします。
たとえば、GOLDをクリックしてから「次」をクリックします。

保護されたデータベースの追加ページが表示されます。

図6-5 保護されたデータベースの追加ページ

9. 保護されたデータベースに必要な属性を設定します。

- 「予約済領域」フィールドに、保護されたデータベースごとに予約するディスク領域の最小量を入力します。

注意:

Cloud Controlを使用してリカバリ・アプライアンスにデータベースを追加すると、リカバリ・アプライアンスはデフォルトの予約領域であるデータベース・サイズの2.5Xを割り当てます。この値を使用することも、変更することもできます。

たとえば、6355と入力して、単位にGBを選択します。

- 「リカバリ・アプライアンス・ユーザー」セクションで、適切な仮想プライベート・カタログ・アカウントの資格証明を入力します。

- 「資格証明アクセス権限受領者」セクションの「Enterprise Managerユーザー」で、リカバリ・アプライアンス・ユーザー資格証明へのアクセスが必要なEnterprise Managerユーザー・アカウントを選択します。
たとえば、「すべて」を選択します。

10. 「OK」をクリックします。
確認を求めるウィンドウが表示されます。

11. 「閉じる」をクリックして、保護されたデータベース・ページに戻ります。
新しく追加したデータベースが、保護されたデータベースの表に表示されます。

この段階では、データベースが追加されてアクセス権が付与されましたが、まだ仮想プライベート・カタログには登録されていません。

12. データベースの登録を完了する方法については、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

関連項目:

保護されたデータベースの追加ページの詳細は、Cloud Controlオンライン・ヘルプを参照してください。

6.3.2 コマンドラインを使用した保護されたデータベースの登録

DBMS_RAコマンドライン・インタフェースを使用してデータベースを登録する場合、次のタスクを実行する必要があります。

1. 「DBMS_RAを使用した保護されたデータベースのメタデータの追加」

2. 「DBMS_RAを使用したリカバリ・アプライアンス・アカウントへのデータベース・アクセスの付与」

3. 保護されたデータベースでのアクセス権の構成(『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照)

6.3.2.1 DBMS_RAを使用した保護されたデータベースのメタデータの追加

保護するデータベースについて、DBMS_RA.ADD_DBを使用してこのデータベースのメタデータをリカバリ・アプライアンスに追加する必要があります。この手順では、既存の保護ポリシーおよびデータベースの予約済領域の量を指定する必要があります。

前提条件

RASYSアカウントでリカバリ・アプライアンスにログインする必要があります。

前提条件

次の要件を持つリカバリ・アプライアンス管理者であると想定します。

- orcldを保護されたデータベースにします。

- このデータベースを既存のbronze保護ポリシーに追加し、200GBの予約済領域を割り当てます。

保護されたデータベースのメタデータをリカバリ・アプライアンスに追加するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてリカバリ・アプライアンス・メタデータ・データベースに接続します。

2. ADD_DBプロシージャを使用して、データベースのメタデータをリカバリ・アプライアンスに追加し、保護ポリシーを割り当てます。
たとえば、次の無名ブロックはデータベースorcldを追加します。

BEGIN
DBMS_RA.ADD_DB (
db_unique_name         => 'orcld',
protection_policy_name => 'bronze',
reserved_space         => '200G');
END;

3. オプションで、新たに追加されたデータベースに関する情報があるかリカバリ・カタログを問い合せます。
たとえば、次の問合せを実行してorcld (出力例も示します)の詳細を表示します。

COLUMN PROT_DB FORMAT a10
COLUMN POLICY_NAME FORMAT a11
SELECT DB_UNIQUE_NAME AS PROT_DB, DB_KEY, DBID, POLICY_NAME
FROM   RA_DATABASE
WHERE  DB_UNIQUE_NAME = 'ORCLD';

PROT_DB        DB_KEY       DBID POLICY_NAME
---------- ---------- ---------- -----------
ORCLD             301 3210984255 BRONZE

注意:

Oracle Data Guard環境では、リカバリ・アプライアンス・カタログに登録したデータベース(プライマリまたはセカンダリ)のdb_unique_nameを追加します。

関連項目:

「ADD_DB」

6.3.2.2 DBMS_RAを使用したリカバリ・アプライアンス・アカウントへのデータベース・アクセスの付与

リカバリ・アプライアンス・ユーザー・アカウント(仮想プライベート・カタログ・アカウントでもあります)に必要な権限を付与して、このアカウントで認証する保護されたデータベースがバックアップ操作とリストア操作を実行できるようにする必要があります。DBMS_RA.GRANT_DB_ACCESSプロシージャは、保護されたデータベースを仮想プライベート・カタログに関連付けます。

前提条件

このタスクには次の前提条件があります。

- RASYSアカウントでリカバリ・アプライアンスにログインする必要があります。

- DBMS_RA.GRANT_DB_ACCESSで指定したリカバリ・アプライアンス・ユーザー・アカウントが存在する必要があります。

- orcldという名前の保護されたデータベースが追加されている必要があります。

前提条件

保護されたデータベースorcldをバックアップする際に、RMANにravpc1としてCONNECT CATALOGを許可するとします。

保護されたデータベースへのアクセス権を仮想プライベート・カタログ・アカウントに付与するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてリカバリ・アプライアンス・データベースに接続します。

2. GRANT_DB_ACCESSプロシージャを実行して、データベースに対するバックアップおよびリストア権限をユーザーに付与します。
次のPL/SQL無名ブロックは、保護されたデータベースorcldへのアクセス権を仮想プライベート・カタログ・アカウントravpc1に付与します。

BEGIN
DBMS_RA.GRANT_DB_ACCESS (
db_unique_name =>  'orcld',
username       =>  'ravpc1');
END;

3. オプションで、データベース・アクセスに関する情報があるかリカバリ・カタログを問い合せます。
たとえば、次の問合せを実行してorcldおよびカタログ所有者ravpc1 (出力例も示します)の詳細を表示します。

COLUMN PROT_DB FORMAT a10
COLUMN POLICY_NAME FORMAT a11
COLUMN USERNAME FORMAT a15
COLUMN DB_KEY FORMAT 999999
SELECT d.DB_UNIQUE_NAME AS PROT_DB, d.DB_KEY,
d.DBID, d.POLICY_NAME, a.USERNAME
FROM   RA_DATABASE d, RA_DB_ACCESS a
WHERE  d.DB_UNIQUE_NAME = 'ORCLD'
AND    a.DB_KEY = d.DB_KEY;

PROT_DB     DB_KEY       DBID POLICY_NAME USERNAME
---------- ------- ---------- ----------- ---------------
ORCLD          301 3210984255 BRONZE      RAVPC1

4. このアカウントを使用して認証する必要のある保護されたデータベースごとに、仮想プライベート・カタログのユーザー名とパスワードをDBAに送信します。

5. 登録手順を完了するには、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

関連項目:

「GRANT_DB_ACCESS」

6.4 保護されたデータベースのプロパティの更新

この項では、Cloud Control (推奨)またはDBMS_RAコマンドライン・インタフェースを使用して、保護されたデータベースのプロパティを更新する方法について説明します。

6.4.1 Cloud Controlを使用した保護されたデータベースのプロパティの更新

この項では、Cloud Controlで保護されたデータベース・ページからデータベースを編集する方法を説明します。

前提条件

次のビジネス要件があると想定します。

- 保護されたデータベースORCL11の保護ポリシーをGOLDからBRONZEに変更します。

- 予約済領域を6355GBから7000GBに変更します。

- この保護されたデータベースに関連付けられているリカバリ・アプライアンス・ユーザー・アカウントをrauser11からrauser12に変更します。

保護されたデータベースのプロパティを更新するには:

1. 「Cloud Controlでの保護されたデータベース・ページへのアクセス」に説明されているとおりに、保護されたデータベース・ページにアクセスします。

2. 「編集」をクリックします。
保護されたデータベースの編集ページが表示されます。

3. 保護されたデータベースの必要な属性を変更して、「OK」をクリックします。

- 「保護ポリシー」セクションで、BRONZEというポリシーの行を選択します。
たとえば、「すべて」を選択します。

- 「予約済領域」フィールドに、この保護されたデータベースに予約するディスク領域の新しい最小量を入力します。
たとえば、7000と入力して、単位にGBを選択します。

- 「リカバリ・アプライアンス・ユーザー」セクションに、データベース・ユーザーrauser12の資格証明を入力します。

新しく更新したデータベースが、保護されたデータベースの表に表示されます。

関連項目:

保護されたデータベースの編集ページの詳細は、Cloud Controlオンライン・ヘルプを参照してください。

6.4.2 DBMS_RAを使用した別の保護ポリシーへのデータベースの割当て

保護されたデータベースのプロパティを更新するには、DBMS_RA.UPDATE_DBプロシージャを使用します。未指定のパラメータは既存の値が保持されます。この項では、別の保護ポリシーを使用するように保護されたデータベースを更新する方法を説明します。

前提条件

RASYSとしてメタデータ・データベースにログインする必要があります。

前提条件

このチュートリアルでは、「DBMS_RAを使用した保護ポリシーの作成」で作成したbronzeという保護ポリシーが存在すると想定しています。目標は、データベースzdlracの保護ポリシーをsilverからbronzeに変更することです。

別の保護ポリシーにデータベースを割り当てるには:

1. SQL*PlusまたはSQL Developerを起動し、RASYSとしてメタデータ・データベースにログインします。

2. 既存の保護ポリシーを問い合せます。
たとえば、次の問合せを実行します(出力例も示します)。

COL POLICY_NAME FORMAT a11
COL DESCRIPTION FORMAT a35
SELECT POLICY_NAME, DESCRIPTION,
TO_CHAR(EXTRACT(DAY FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
TO_CHAR(EXTRACT(HOUR FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
TO_CHAR(EXTRACT(MINUTE FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
TO_CHAR(EXTRACT(SECOND FROM RECOVERY_WINDOW_GOAL),'fm00')
AS "DD:HH:MM:SS"
FROM   RA_PROTECTION_POLICY;

POLICY_NAME DESCRIPTION                         DD:HH:MM:SS
----------- ----------------------------------- ---------------
BRONZE      For protected dbs in bronze tier    01:00:00:00
SILVER      For protected dbs in silver tier    07:00:00:00
GOLD        For protected dbs in gold tier      14:00:00:00

3. どの保護されたデータベースがどの保護ポリシーに関連付けられているかを特定します。
たとえば、次の問合せを実行します(出力例も示します)。

SELECT d.DB_UNIQUE_NAME, d.POLICY_NAME
FROM   RA_PROTECTION_POLICY p, RA_DATABASE d
WHERE  p.policy_name=d.policy_name
ORDER BY d.DB_UNIQUE_NAME;

DB_UNIQUE_NAME                   POLICY_NAME
-------------------------------- -----------
ZDLRA                            BRONZE
ZDLRAC                           SILVER
.
.
.

4. DBMS_RA.UPDATE_DBプロシージャを実行して、データベースを新しいポリシーに関連付けます。
たとえば、次のPL/SQL無名ブロックを実行して、現在のポリシーがsilverのzdlracという名前のデータベースを、bronzeという名前の保護ポリシーに関連付けます。

BEGIN
DBMS_RA.UPDATE_DB(
db_unique_name             => 'zdlrac',
protection_policy_name     => 'bronze');
END;

5. オプションで、データベースが正しいポリシーに関連付けられていることを確認します。
たとえば、次の問合せを実行します(出力例も示します)。

SELECT d.DB_UNIQUE_NAME, d.POLICY_NAME
FROM   RA_PROTECTION_POLICY p, RA_DATABASE d
WHERE  p.POLICY_NAME=d.POLICY_NAME
ORDER BY d.DB_UNIQUE_NAME;

DB_UNIQUE_NAME                   POLICY_NAME
-------------------------------- -----------
ZDLRA                            BRONZE
ZDLRAC                           BRONZE
.
.
.

関連項目:

「UPDATE_DB」

7 リカバリ・アプライアンスでのテープへのバックアップのコピー

この章では、完了したバックアップをテープにコピーして、Zero Data Loss Recovery Applianceでの領域および記憶域リソースの利用を最適化する方法について説明します。

この章の内容は次のとおりです。

- リカバリ・アプライアンスでのテープへのバックアップのコピーについて

- テープ・バックアップ・ジョブ・コンポーネントの作成

- テープ・バックアップ・ジョブ・コンポーネントの管理

- テープ・バックアップ・ジョブの作成

- テープ・バックアップ・ジョブの管理

- テープ・バックアップ・ジョブのスケジューリング

- テープ・バックアップ操作の一時停止および再開

- テープ・バックアップ操作のステータスの表示

7.1 リカバリ・アプライアンスでのテープへのバックアップのコピーについて

この項には次のトピックが含まれます:

- リカバリ・アプライアンスでテープにバックアップをコピーする目的

- リカバリ・アプライアンスでのテープへのバックアップのコピーの概要

- リカバリ・アプライアンスのユーザー・インタフェース

- リカバリ・アプライアンスでテープにバックアップをコピーする場合の基本的なタスク

7.1.1 リカバリ・アプライアンスでテープにバックアップをコピーする目的

「自律型テープ・アーカイブ」で説明したように、堅固なバックアップ戦略によってデータは意図的な攻撃、意図的でないユーザー・エラー(ファイルの削除など)、ソフトウェアまたはハードウェアの不具合から保護されます。テープ・ライブラリは、これらの可能性に対する効果的な保護を提供します。

リカバリ・アプライアンスのテープ・ソリューションのメリットは次のとおりです。

- テープ・バックアップは、長期の保存に適しています。テープは持ち運び可能で、長期にわたって保存するのが容易です。

- テープ・バックアップ操作はすべてリカバリ・アプライアンスによって実行され、保護されたデータベース・ホスト上でパフォーマンス負荷はありません。

- テープのバックアップは最適化されています。リカバリ・アプライアンスは必要なブロックを効率よく収集して、テープの仮想、全体バックアップまたは増分バックアップを作成します。リカバリ・アプライアンス・バックアップは恒久的に増分しますが、週次の全体バックアップと日次の増分バックアップ、または日次の全体バックアップのみなど、テープに対して柔軟なバックアップ戦略を作成できます。

- Oracle Secure Backupが事前にインストールされているため、サードパーティのメディア・マネージャは不要です。

- テープ・ドライブとテープ・ライブラリの効率が向上します。これは、リカバリ・アプライアンスが1つの大きな集中管理システムであり、テープ・ドライブとテープ・ライブラリを完全に制御できるためです。他のテープ・ソリューションでは、数百ものデータベースがばらばらなやり方でテープ・リソースを奪い合う可能性があります。

7.1.2 リカバリ・アプライアンスでのテープへのバックアップのコピーの概要

この項には次のトピックが含まれます:

- リカバリ・アプライアンスでのテープ操作について

- テープ操作を管理するためのリカバリ・アプライアンス・コンポーネント

- テープでのバックアップ保存

- テープ・バックアップ操作の一時停止および再開について

7.1.2.1 リカバリ・アプライアンスでのテープ操作について

リカバリ・アプライアンスが保護されたデータベースから受け取ったバックアップはすべて、まずディスクに保存されます。その後、オプションでリカバリ・アプライアンスはこれらのバックアップをテープにコピーできます。テープへのコピーはすべて自動化されており、ポリシー主導型であり、スケジュール設定されています。

保護ポリシーでは、テープに保存したバックアップの望ましいリカバリ・ウィンドウを定義します。リカバリ・ウィンドウは、30日間などの時間間隔で表されます。バックアップは、現在の時間から遡って、この間隔内にいつでもリカバリができるように十分な期間、テープに保存されます

リカバリ・アプライアンス・バックアップはディスクからテープにコピーできます。このタスクを実行するには、メディア・マネージャ・ライブラリおよびこのジョブを管理する属性セット、保護ポリシーまたはバックアップをコピーする必要のあるデータベースなど、コピー操作のプロパティを定義するテープ・バックアップ・ジョブを作成する必要があります。ジョブ・プロパティを定義した後、このジョブの実行をスケジュールする必要があります。

注意:

- まだテープにコピーされていないバックアップのみ、バックアップが関連付けられている各テープ・バックアップ・ジョブ・テンプレートのテープ・バックアップ操作で処理されます。このため、初期テープ・コピー後の同じバックアップでのテープ・バックアップ操作は無効です。さらに、テープ・バックアップ操作が実行されると、最新のバックアップのみがテープにコピーされます。
テープ上の異なるメディア・ファミリへのコピーなど、同じバックアップのコピーが複数必要な場合、テンプレートのCOPIESパラメータを使用するか、追加コピーに別のテープ・バックアップ・ジョブ・テンプレートを作成します。

- BACKUPコマンドのKEEPオプションで作成した長期アーカイブ・バックアップは、テープに自動的にコピーされません。COPY_BACKUPまたはMOVE_BACKUPプロシージャを使用して、手動でコピーする必要があります。
リカバリ・アプライアンスでの長期保存のアーカイブ・バックアップの作成方法の詳細は、My Oracle SupportノートのドキュメントID 2107079.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=2107079.1)を参照してください。

リストア中、リカバリ・アプライアンスはテープから透過的にバックアップを取得します。

リカバリ・アプライアンスは、RMANでサポートされる形式でテープにバックアップを書き込みます。保護されたデータベースに必要とされるメディア管理ソフトウェア(Oracle Secure Backupなど)がある場合、リカバリ・アプライアンスによってテープに書き込まれたバックアップを直接リストアできます。

7.1.2.2 テープ操作を管理するためのリカバリ・アプライアンス・コンポーネント

リカバリ・アプライアンス設定内の各データベースは、バックアップ記憶域およびリカバリ・ウィンドウ目標のパラメータを指定する保護ポリシーに関連付けられています。テープ操作を管理および制御するには、バックアップをテープにコピーするために選択した保護ポリシー、メディア管理ライブラリ、属性セットによって定義されたプロパティを使用するジョブを作成する必要があります。Oracle Secure Backupとそのコンポーネント(メディア・マネージャ・ライブラリおよび属性セット)はリカバリ・アプライアンスで事前構成されています。

表7-1に、テープ操作を管理するリカバリ・アプライアンス・オブジェクトのロールをまとめます。

表7-1 バックアップをテープにコピーするためのリカバリ・アプライアンス・オブジェクト

Cloud Controlオブジェクト名

コマンドライン・オブジェクト名

説明

保護ポリシー

保護ポリシー

属性とともに、リカバリ・ウィンドウを定義します。このリカバリ・ウィンドウは、保護ポリシーに割り当てられているすべての保護されたデータベースに適用されます。

メディア管理ライブラリ

SBTライブラリ

リカバリ・アプライアンスにインストールされているメディア管理ソフトウェア・ライブラリを示します。

メディア・マネージャ属性セット

SBT属性セット

コピー操作を制御する属性の集合が含まれます。1つの属性は、コピー操作で使用されるライブラリを指定します。他の属性はオプションで、チャネル・パラメータ、メディア管理ソフトウェア・ライブラリ固有のコマンド、メディア・プールIDを含めることができます。複数の属性セットを定義できますが、特定のコピー・ジョブに関連付けられるのは1つの属性セットのみです。

Copy-to-Tapeジョブ・テンプレート

SBTジョブ・テンプレート

テープにコピーするバックアップのプロパティを定義し、コピー操作を制御する属性セットを指定します。一般に、複数のジョブ・テンプレートが「例: Cloud Controlを使用したテープ・バックアップ・ジョブの作成」に説明されているとおりに定義されます。

注意:

表7-1のOracle Enterprise Manager Cloud Control (Cloud Control)のオブジェクト名とコマンドライン名は、それぞれのインタフェース用語で同じテープ・バックアップ・オブジェクトを指しています。

関連項目:

これらのコンポーネントを使用してテープ・バックアップ・ジョブを作成する方法の詳細は、「リカバリ・アプライアンスでテープにバックアップをコピーするための基本的なタスク」を参照してください

7.1.2.3 テープでのバックアップ保存

リカバリ・ウィンドウを指定することで、テープでバックアップ・コピーを保存する期間の長さを制御できます。リカバリ・ウィンドウは、リカバリ・アプライアンスがリカバリ目的でカタログ内にテープ・バックアップを保持する期間の長さを定義します。リカバリ・ウィンドウは、時間数、日数、週数、月数の値で期間として表されます。バックアップは、現在の時間から遡って、この間隔内の任意の時点までリカバリができるように十分な期間にわたって保存されます

注意:

リカバリ・ウィンドウは全体またはレベル0データ・ファイルにのみ直接適用され、ファイル・バックアップを制御します。

リカバリ・アプライアンスでは、テープ・バックアップをパージしません。かわりに、RMAN保存に不要になった部分をメディア・マネージャに知らせます。Oracle Secure Backupをメディア・マネージャとして使用する場合、これらのファイルを明示的には削除せず、カタログを更新します。特定のテープ上のすべてのファイルが不要になると、Oracle Secure Backupはテープの再利用を検討します。

保護ポリシーで値を指定して、バックアップのリカバリ・ウィンドウを設定します。この属性がNULLの場合、リカバリ・アプライアンスはテープからバックアップをパージしません。

関連項目:

- 「CREATE_SBT_JOB_TEMPLATE」

- Cloud Controlを使用してリカバリ・ウィンドウ目標を設定する方法の詳細は、「Cloud Controlを使用した保護ポリシーの作成」を参照してください

- コマンドラインを使用してSBTリカバリ・ウィンドウを設定する方法の詳細は、「DBMS_RAを使用した保護ポリシーの作成」を参照してください

- リカバリ・ウィンドウの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

7.1.2.4 テープ・バックアップ操作の一時停止および再開について

次の理由により、バックアップのテープへのコピーを一時停止することが必要な場合があります。

- 前のバックアップ・コピーの失敗を調査する場合

- テープ・デバイスでメンテナンス操作を実行する場合

対応するメディア・マネージャ・ライブラリを一時停止して、特定のメディア管理ソフトウェア・ライブラリのテープ・バックアップ操作を一時停止します。

メディア・マネージャ・ライブラリを一時停止すると、バックアップ・ピースの進行中のコピーは完了できますが、コピーのためにキューに入っているがまだコピーされていないバックアップ・ピースはライブラリを再開するまで保留になります。ライブラリを一時停止すると、メディア・マネージャ・ライブラリを参照するテープ・バックアップ・ジョブの将来のスケジュール実行は一時停止されます。

注意:

テープ・バックアップ・ジョブは、割り当てられているメディア・マネージャ属性セットを介して間接的にメディア・マネージャ・ライブラリを参照します。

関連項目:

- 「Cloud Controlを使用したメディア・マネージャ・ライブラリ操作の一時停止および再開」

- 「DBMS_RAを使用したSBTライブラリの一時停止および再開」

7.1.2.5 リカバリ・アプライアンスでのOracle Secure Backupの使用について

Oracle Secure Backupは、複数の環境のファイル・システム・データやOracle Databaseファイルを保存することで、信頼性の高いテープ集中管理機能を提供するメディア・マネージャです。Oracle Secure Backupは、リカバリ・アプライアンスのテープ管理コンポーネントです。リカバリ・アプライアンスの構成中に、そのコンポーネントとともにリカバリ・アプライアンスにインストールされます。

事前構成されたOracle Secure Backupコンポーネントには、次が含まれます。

メディア・マネージャ・ライブラリ

インストール中、リカバリ・アプライアンスが構成されている間、Oracle Secure Backupは次のようなデフォルト・パラメータでメディア・マネージャ・ライブラリを作成します。

- ライブラリ名(ROBOT0)

- アクセス可能な最大テープ・ドライブ数

- リストア・ドライブ数

- メディア・マネージャの場所

名前以外に、他のメディア・マネージャ・ライブラリ・パラメータを変更できます。このライブラリは、パラメータ・セットに基づいて、関連付けられているテープ・バックアップ操作を管理します。

メディア・マネージャ属性セット

Oracle Secure Backupのインストールでは、メディア・マネージャ・ライブラリとともに、デフォルトのメディア・マネージャ・ライブラリがアクセスするすべてのテープ・ドライブの属性セットもインストールされます。

これらの属性セットには、コピー操作に必要なメディア・プール番号やストリームなどのパラメータのデフォルト値があります。これらおよびメディア・マネージャ・ベンダーのパラメータおよびコマンドは、変更可能です。デフォルトの属性セットの名前は、メディア・マネージャ・ライブラリによってアクセスされるテープ・ドライブ数によって、DRIVE_COUNT_1、DRIVE_COUNT_2、DRIVE_COUNT_3などとなります。

関連項目:

- Cloud Controlを使用してOracle Secure Backupドメインにアクセスする方法の詳細は、「Cloud Controlを使用したOracle Secure Backupドメインへのアクセス」を参照してください

- サードパーティ・メディア・マネージャ用のメディア・マネージャ・ライブラリおよび属性セットの作成方法の詳細は、「テープ・バックアップ・ジョブ・コンポーネントの作成」を参照してください

- 既存のメディア・マネージャ・コンポーネントの編集および制御方法の詳細は、「テープ・バックアップ・ジョブ・コンポーネントの管理」を参照してください

7.1.3 リカバリ・アプライアンスのユーザー・インタフェース

Cloud Controlまたはリカバリ・アプライアンスのコマンドライン・オプションを使用して、テープ・バックアップ・ジョブ操作を管理および実行できます。

この項には次のトピックが含まれます:

- Cloud Controlでのリカバリ・アプライアンスへのアクセス

- DBMS_RAを使用したリカバリ・アプライアンスへのアクセス

7.1.3.1 Cloud Controlでのリカバリ・アプライアンスへのアクセス

Cloud Controlを使用してリカバリ・アプライアンスにアクセスするには、「リカバリ・アプライアンスのホームページへのアクセス」にリストされている手順を完了します。

7.1.3.2 DBMS_RAを使用したリカバリ・アプライアンスへのアクセス

この項には次のトピックが含まれます:

- テープ・バックアップ操作のDBMS_RAプロシージャ

- テープ操作のリカバリ・カタログ・ビュー

7.1.3.2.1 テープ・バックアップ操作のDBMS_RAプロシージャ

表7-2に、SBTジョブ操作に関連付けられているリカバリ・アプライアンスのDBMS_RAプロシージャをリストします。

表7-2 テープ・バックアップ操作に関連付けられているDBMS_RAプロシージャ

SBTオブジェクト

プロシージャ

SBTジョブ

- CREATE_SBT_JOB_TEMPLATE

- UPDATE_SBT_JOB_TEMPLATE

- DELETE_SBT_JOB_TEMPLATE

SBTライブラリ

- CREATE_SBT_LIBRARY

- UPDATE_SBT_LIBRARY

- PAUSE_SBT_LIBRARY

- RESUME_SBT_LIBRARY

- DELETE_SBT_LIBRARY

SBT属性セット

- CREATE_SBT_ATTRIBUTE_SET

- UPDATE_SBT_ATTRIBUTE_SET

- DELETE_SBT_ATTRIBUTE_SET

保護ポリシー

- CREATE_PROTECTION_POLICY

- UPDATE_PROTECTION_POLICY

- DELETE_PROTECTION_POLICY

バックアップ

- QUEUE_SBT_BACKUP_TASK

- COPY_BACKUP

- MOVE_BACKUP

関連項目:

リカバリ・アプライアンスの他のDBMS_RAプロシージャの詳細は、「DBMS_RAパッケージ・リファレンス」を参照してください

7.1.3.2.2 テープ操作のリカバリ・カタログ・ビュー

この項では、SBTジョブ操作に関連付けられているリカバリ・アプライアンスのリカバリ・カタログ・ビューを示します。

- RA_SBT_JOB

- RA_SBT_LIBRARY

- RA_SBT_ATTRIBUTE_SET

- RA_PROTECTION_POLICY

- RA_EM_SBT_JOB_TEMPLATE

関連項目:

リカバリ・アプライアンスの他のデータ・ディクショナリ・ビューの詳細は、「リカバリ・アプライアンスのビュー・リファレンス」を参照してください

7.1.4 リカバリ・アプライアンスでテープにバックアップをコピーする場合の基本的なタスク

この項では、リカバリ・アプライアンスを使用してデータベース・バックアップをコピーする高レベルな必須手順を示します。

関連項目:

「リカバリ・アプライアンスでのテープへのバックアップのコピーについて」

リカバリ・アプライアンスを使用してバックアップをテープにコピーするには:

1. ジョブ・セットに適用するパラメータを追加することで、メディア管理ソフトウェアのメディア・マネージャ・ライブラリを作成して、すべてのテープ・バックアップ・ジョブを管理します。
リカバリ・アプライアンスでは、Oracle Secure Backupをメディア管理ソフトウェアとして使用します。リカバリ・アプライアンスの設定中に、事前構成されたメディア・マネージャ・ライブラリおよび属性セットとともにOracle Secure Backupがインストールされます。

関連項目:

追加のメディア・マネージャ・ライブラリを作成する方法の詳細は、「メディア・マネージャ・ライブラリの作成」を参照してください

2. メディア・マネージャ・ソフトウェアにさらにジョブ固有のパラメータやコマンドを追加して、テープ・バックアップ・ジョブを詳細に制御するメディア・マネージャ属性セットを作成します。
テープ・バックアップ・ジョブでは、コピー操作の実行時に、メディア・マネージャ・ライブラリ・レベルおよび属性セット・レベルで指定されたパラメータの組合せを使用します。メディア・マネージャ・ライブラリはジョブ・セットに適用するパラメータを定義するのに対し、属性セットは特定ジョブのテープ・バックアップ設定を詳細に定義するのに役立ちます。

Oracle Secure Backupでは、デフォルトのメディア・マネージャ・ライブラリに含まれるすべてのドライブのデフォルトの属性セットも構成します。

関連項目:

追加の属性セットの作成の詳細は、「属性セットの作成」を参照してください

3. テープ・バックアップ・ジョブを作成します。
ジョブ定義には、このジョブに関連付けられているメディア・マネージャ・ライブラリおよび属性セット、テープにコピーする必要があるバックアップのタイプ、このジョブのランタイム・ウィンドウなどのジョブ・プロパティが含まれます。

このジョブを、タスク要件に基づいて指定した時間に実行するようにスケジュールすることもできます。

関連項目:

テープ・バックアップ・ジョブの作成の詳細は、「テープ・バックアップ・ジョブの作成」を参照してください

4. (オプション)必要に応じて、メディア・マネージャ・ライブラリまたはテープ・バックアップ・ジョブを一時停止または再開します。

関連項目:

「テープ・バックアップ操作の一時停止および再開」

5. すべてのメディア・マネージャ・ライブラリおよびテープ・バックアップ操作のステータスを表示して、エラーがあるかどうかを確認します。

関連項目:

「テープ・バックアップ操作のステータスの表示」

バックアップ・プロパティを調整したり、ボールティングをスケジュール設定してテープを管理するために、追加のメディア・ファミリを作成できます。これらのタスクを実行するには、リカバリ・アプライアンスのOracle Secure Backupドメインを使用します。

関連項目:

- 「Cloud Controlを使用したOracle Secure Backupドメインへのアクセス」

- メディア・ファミリの構成の詳細は、Oracle Secure Backup管理者ガイドを参照してください

- ボールティングの詳細は、Oracle Secure Backup管理者ガイドを参照してください

7.1.4.1 Cloud Controlを使用したOracle Secure Backupドメインへのアクセス

Cloud Controlを使用してOracle Secure Backupドメインにアクセスします。(必要に応じて)このドメインを使用して、選択したリカバリ・アプライアンス環境に設定された既存のOracle Secure Backup構成を管理します。

Cloud Controlを使用してOracle Secure Backupドメインにアクセスするには:

1. Cloud Controlのホームページから「ターゲット」を選択します。

2. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。
「すべてのターゲット」ページが表示されます。

3. すべてのターゲット・ページの「検索の絞込み」メニューで、ターゲット・タイプとして「データベース」を選択します。

4. 「データベース」セクションで、「Oracle Secure Backupドメイン」を選択します。
既存のすべてのリカバリ・アプライアンス・ターゲットの、すべてのOracle Secure Backupドメインのリストが表示されます。

5. ターゲットのリストから、Oracle Secure Backupドメインにアクセスするターゲットをクリックします。
選択したリカバリ・アプライアンスのOracle Secure Backupドメインが表示されます。

関連項目:

「リカバリ・アプライアンスでのOracle Secure Backupの使用について」

7.2 テープ・バックアップ・ジョブ・コンポーネントの作成

テープ・バックアップ・ジョブを正常に作成するには、まずそのコンポーネントが存在することを確認する必要があります。メディア・マネージャ・ライブラリとその属性セットは、テープ・バックアップ操作には不可欠です。これらのコンポーネントはテープ・バックアップ・ジョブのパラメータの組合せを定義して、テープに保存する際のジョブの分類をサポートします。

関連項目:

メディア・マネージャ・ライブラリのロールとその属性セットの詳細は、「テープ操作を管理するためのリカバリ・アプライアンス・コンポーネント」を参照してください

この項には次のトピックが含まれます:

- メディア・マネージャ・ライブラリの作成

- 属性セットの作成

7.2.1 メディア・マネージャ・ライブラリの作成

メディア・マネージャ・ライブラリは、アクセス可能なテープ・ドライブの数などのパラメータを定義して、テープ・バックアップ・ジョブのプロパティを設定します。オプションの詳細パラメータには、必要なリストア・ドライブ数およびメディア・マネージャ・パラメータの指定が含まれます。

リカバリ・アプライアンスは、事前構成されたメディア・マネージャとしてOracle Secure Backupに付属しています。リカバリ・アプライアンスの構成中、Oracle Secure Backupに対してもメディア・マネージャ・ライブラリが構成されます(通常、ROBOT0という名前で)。事前構成されたメディア・マネージャ・オブジェクトのみを使用することをお薦めします。複数のライブラリ・オブジェクトが存在すると、作成されたテープ・バックアップ・ジョブとこれらのジョブを処理するメディア・マネージャ・リソースとの間で競合が発生するため、メディア・マネージャ(この場合、Oracle Secure Backup)には1つのメディア・マネージャ・ライブラリのみが含まれるようにする必要があります。

サード・パーティ製メディア管理ソフトウェアを使用している場合、リカバリ・アプライアンス計算サーバーにバックアップ・エージェントをインストールする必要があります。サードパーティ製品を使用してテープ・バックアップ・ジョブをスケジュールするには、LAN経由でバックアップ・アプリケーションのメディア・サーバーに接続されたテープ・デバイスにバックアップするために、新しいメディア・マネージャ・ライブラリを作成してそのメディア・マネージャに適用可能なRMANパラメータを追加する必要があります。このシナリオでは、Oracle Secure Backupに事前構成されたメディア・マネージャ・コンポーネントは使用できず、テープ・デバイスを直接リカバリ・アプライアンスに接続することはできません。

この項では、サード・パーティのメディア・マネージャに追加のメディア・マネージャ・ライブラリを作成する手順について説明します。この付録には、次の項があります。

- Cloud Controlを使用したメディア・マネージャ・ライブラリの作成

- DBMS_RAを使用したSBTライブラリの作成

7.2.1.1 Cloud Controlを使用したメディア・マネージャ・ライブラリの作成

メディア・マネージャ・ライブラリは、バックアップをテープにコピーする際に使用するメディア管理ソフトウェアのパラメータを設定して管理します。

関連項目:

「テープ操作を管理するためのリカバリ・アプライアンス・コンポーネント」

メディア・マネージャ・ライブラリを作成するには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の手順を完了します。
リカバリ・アプライアンスのホームページで、「リカバリ・アプライアンス」メニューから「メディア・マネージャ」を選択します。

図7-1に、デフォルトのOracle Secure Backupライブラリと対応する属性セットが表示されたメディア・マネージャ画面を示します。

図7-1 メディア・マネージャ・ページ

2. メディア・マネージャ・ページで、 「作成」をクリックして新しいメディア・マネージャ・ライブラリを構成します。
「メディア・マネージャ・ライブラリと初期属性セットの作成」ダイアログ・ボックスが表示されます。

3. 「メディア・マネージャ・ライブラリ」セクションに、このライブラリの名前を入力します。

4. 「最大ドライブ数」フィールドで、メディア・マネージャ・ライブラリがアクセスできる最大テープ・ドライブ数を選択します。

5. オプションで、このメディア・マネージャ・ライブラリの「詳細パラメータ」を入力するよう選択できます。

a. 「ドライブのリストア」詳細パラメータ・フィールドで、リストア操作のみに使用するドライブの数を選択します。リストア・ドライブ値を入力しない場合、現在のリストア操作では、すべてのバックアップ操作の完了後に使用可能な最初の空きドライブが使用されます。

b. 「メディア管理ベンダーのパラメータ」で、メディア・マネージャ・ライブラリを定義するパラメータを追加することを選択できます。
たとえば、Oracle Secure Backupのメディア・マネージャ・ベンダー・パラメータには、メディア・マネージャ・ライブラリのパスを指定するSBT_LIBRARYパラメータがデフォルトで含まれます。

サードパーティ製品をメディア・マネージャとして使用している場合は、新しいメディア・ライブラリを作成し、指定したメディア・マネージャの製品固有パラメータを使用します(特にSBT_LIBRARY場所パラメータ)。

6. このライブラリの初期属性セットを追加するには、「Cloud Controlを使用した属性セットの作成」セクションの手順を完了します。
この属性セットの値を入力しない場合、デフォルト値が適用されます。

7. 「OK」をクリックします。

7.2.1.2 DBMS_RAを使用したSBTライブラリの作成

SBTライブラリ・オブジェクトは、リカバリ・アプライアンスにインストールされているメディア管理ソフトウェア・ライブラリを示します。メディア管理ソフトウェアに渡すパラメータが含まれます。

SBTライブラリを作成するには:

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続します。

2. DBMS_RA.CREATE_SBT_LIBRARYプロシージャを実行します。

BEGIN
DBMS_RA.CREATE_SBT_LIBRARY(
lib_name       => 'osbsbt',
drives         => 12,
restore_drives => 2,
parms          => 'SBT_LIBRARY=libobk.so');
END;

この例では、メディア管理ソフトウェアはOracle Secure Backupです。ドライブ引数は、このSBTライブラリがアクセスできる最大テープ・ドライブ数を指定します。restore_drives引数は、リストア操作用に予約されるテープ・ドライブ数を設定します。parms引数の目的と形式は、RMAN ALLOCATE CHANNELコマンドのPARMS句と同じです。通常、少なくともSBT_LIBRARYパラメータが含まれます。この場合、Oracle Secure Backupメディア・ファミリの共有ライブラリを指定します。

関連項目:

プロシージャの引数の説明については、「CREATE_SBT_LIBRARY」を参照してください

7.2.2 属性セットの作成

SBT属性セットは、バックアップをテープにコピーする際に、バックアップをさらにカスタマイズおよび分類するのに役立ちます。メディア・マネージャ・ライブラリに関連付けられているテープ・ドライブごとに、1つの属性セットが作成されます。メディア・プール番号、ストリーム、テープ・バックアップ操作の実行に必要なメディア・マネージャ・コマンドなどのパラメータを指定することで、バックアップをテープに保管する際にバックアップを分類できます。

リカバリ・アプライアンスは、事前構成されたメディア・マネージャとしてOracle Secure Backupに付属しています。テープ・ドライブごとにメディア・マネージャ・ライブラリおよび属性セットのあるOracle Secure Backupコンポーネントも事前構成されています。事前構成された属性セットの名前は通常、既存のテープ・ドライブ数によって、DRIVE_COUNT_1、DRIVE_COUNT_2などとなります。

この項では、サード・パーティのメディア・マネージャ用の追加属性セットを作成する手順について説明します。この付録には、次の項があります。

- Cloud Controlを使用した属性セットの作成

- DBMS_RAを使用したSBT属性セットの作成

7.2.2.1 Cloud Controlを使用した属性セットの作成

メディア・マネージャ・ライブラリの初期属性セットは、メディア・マネージャ・ライブラリ自体を作成している間に作成します。メディア・マネージャ・ライブラリの構成時に初期属性セットのフィールドを空白のままにすると、デフォルト値が使用されます。

関連項目:

「Cloud Controlを使用したメディア・マネージャ・ライブラリの作成」

次の手順を使用して、サードパーティのメディア・マネージャ・ライブラリ用の追加属性セットを作成することもできます。

属性セットを作成するには:

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。
「リカバリ・アプライアンス」メニューから、「メディア・マネージャ」を選択します。

2. 「属性セット」セクションで「作成」をクリックします。
「属性セットの作成」ボックスが表示されます。

3. 「名前」フィールドに、属性セットの名前を入力します。

4. オプションで、「プールID」フィールドに、バックアップ・コピーの保存に使用するメディア・プール番号を入力します。

5. オプションで、「ストリーム」フィールドで、テープ・バックアップ操作の実行に使用する最大ストリーム数を指定します。
値を入力しない場合、使用可能なすべてのストリームが使用されます。

6. オプションで、「メディア管理ベンダーのパラメータ」フィールドを使用して、テープ・バックアップ・ジョブを定義するその他のパラメータを指定します。リカバリ・アプライアンスでは、これらのパラメータとメディア・マネージャ・ライブラリ・パラメータの組合せを使用してテープ・バックアップ・ジョブを完了します。

7. オプションで、「メディア管理ベンダーのコマンド」フィールドに、テープ・バックアップ・ジョブを制御するメディア・マネージャ・ソフトウェアのベンダー固有コマンドを入力します。

8. 「OK」をクリックします。

7.2.2.2 DBMS_RAを使用したSBT属性セットの作成

SBT属性セットはテープ・バックアップ操作を制御する属性の集まりであり、SBTジョブによって参照されます。属性セットは、コピー操作で使用されるSBTライブラリを指定します。SBTチャネル・パラメータおよびメディア管理ソフトウェア・ライブラリに渡すパラメータも指定します。これらのパラメータは、SBTライブラリ・オブジェクトで指定されたパラメータとマージされます。

注意:

すべてのSBT属性セットが同じパラメータ値を共有する場合、各SBT属性セットではなくSBTライブラリ・オブジェクトでそのパラメータを指定できます。

SBT属性セットを作成するには:

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンス・データベースに接続します。

2. 作成するSBT属性セットごとに、DBMS_RA.CREATE_SBT_ATTRIBUTE_SETプロシージャを実行します。

BEGIN
DBMS_RA.CREATE_SBT_ATTRIBUTE_SET(
lib_name             => 'osbsbt',
attribute_set_name   => 'wholedb',
streams              => 10,
parms                => 'ENV=(OB_MEDIA_FAMILY=wholedb_mf)');
END;

やはり、この例では、メディア管理ソフトウェアはOracle Secure Backup (OSB)です。ストリーム引数は、自動バックアップに使用できる最大同時ストリーム数を設定します。parms引数の目的と形式は、RMAN ALLOCATE CHANNELコマンドのPARMS句と同じです。この場合、コピー操作の宛先としてwholedb_mf Oracle Secure Backupメディア・ファミリを指定します。

関連項目:

- プロシージャの引数の説明については、「CREATE_SBT_ATTRIBUTE_SET」を参照してください

- sbt_retention_policy引数の説明については、「テープでのバックアップ保存」を参照してください

7.3 テープ・バックアップ・ジョブ・コンポーネントの管理

テープ・バックアップ・ジョブ・コンポーネントの作成後、ジョブ要件に基づいてプロパティを定期的に変更したり、不要になったときに削除する必要が生じることがあります。

この項には次のトピックが含まれます:

- Cloud Controlを使用したメディア・マネージャ・ライブラリの管理

- DBMS_RAを使用したSBTライブラリの管理

- Cloud Controlを使用した属性セットの管理

- DBMS_RAを使用した属性セットの管理

関連項目:

「テープ・バックアップ・ジョブ・コンポーネントの作成」

7.3.1 Cloud Controlを使用したメディア・マネージャ・ライブラリの管理

この項の内容は次のとおりです。

- メディア・マネージャ・ライブラリの編集

- メディア・マネージャ・ライブラリの削除

7.3.1.1 メディア・マネージャ・ライブラリの編集

テープ・バックアップ・ジョブ要件に基づいて、メディア・マネージャ・ライブラリの既存のプロパティを編集してパラメータを更新します。

メディア・マネージャ・ライブラリを編集するには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の手順を完了します。
リカバリ・アプライアンスのホームページで、「リカバリ・アプライアンス」メニューから「メディア・マネージャ」を選択します。

2. メディア・マネージャ・ページで、編集するメディア・マネージャ・ライブラリを選択して「編集」をクリックします。
メディア・マネージャ・ライブラリの編集画面が既存のライブラリ・パラメータとともに表示されます。

図7-2 メディア・マネージャ・ライブラリの編集画面

3. 最大ドライブの数を変更します。
オプションで、リストア・ドライブ数および 「メディア管理ベンダーのパラメータ」の値を変更することで、詳細パラメータを編集します。

サードパーティのメディア・マネージャを使用している場合は、その特定のメディア・マネージャの必須パラメータを編集します。

4. 「OK」をクリックします。

7.3.1.2 メディア・マネージャ・ライブラリの削除

このメディア・マネージャに関連付けられているすべてのテープ・バックアップ操作が完了し、このライブラリの一部として指定されたパラメータが不要になった後で、既存のメディア・マネージャ・ライブラリを削除できます。

メディア・マネージャ・ライブラリを削除するには:

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。

2. 「リカバリ・アプライアンス」メニューから、「メディア・マネージャ」を選択します。

3. 既存のメディア・マネージャ・ライブラリのリストから、削除するメディア・マネージャ・ライブラリを選択します。

4. 「削除」をクリックします。
このライブラリの削除の確認を求めるメッセージが表示されます。

5. 「はい」をクリックします。

7.3.2 DBMS_RAを使用したSBTライブラリの管理

この項の内容は次のとおりです。

- SBTライブラリの編集

- SBTライブラリの削除

7.3.2.1 SBTライブラリの編集

DBMS_RA PL/SQLパッケージの特定のプロシージャを呼び出すことで、SBTライブラリの1つ以上の属性を変更できます。

SBTライブラリを編集するには:

1. SQL*PlusまたはSQL Developerを使用して、リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続します。

2. 変更するSBTライブラリの名前および属性の新しい値を指定して、UPDATE_SBT_LIBRARYプロシージャを実行します。
プロシージャ・コールから除外された属性は、変更されません。

関連項目:

DBMS_RAパッケージのリファレンス

7.3.2.2 SBTライブラリの削除

DBMS_RA PL/SQLパッケージの特定のプロシージャを呼び出すことで、SBTライブラリを削除できます。

SBTライブラリを削除するには:

1. SQL*PlusまたはSQL Developerを使用して、リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続します。

2. 削除するSBTオブジェクトの名前を指定して、DELETE_SBT_LIBRARYプロシージャを実行します。

例7-1 SBTライブラリの削除

BEGIN
DBMS_RA.DELETE_SBT_LIBRARY(
lib_name => 'OSBSBT');
END;

関連項目:

DBMS_RAパッケージのリファレンス

7.3.3 Cloud Controlを使用した属性セットの管理

この項には次のトピックが含まれます:

- 属性セットの編集

- 属性セットの削除

7.3.3.1 属性セットの編集

メディア・マネージャの属性セットの既存のプロパティを編集し、ジョブ固有のレベルでテープ・バックアップ・ジョブ設定を変更できます。

属性セットを編集するには:

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。

2. 「リカバリ・アプライアンス」メニューから、「メディア・マネージャ」を選択します。

3. 属性セットのリストから、編集する必要のある1つの属性セットを選択します。

4. 「プールID」、「メディア管理ベンダーのパラメータ」および「メディア管理ベンダーのコマンド」の値に必要な変更を加えます。

5. 「OK」をクリックします。

7.3.3.2 属性セットの削除

関連付けられているすべてのテープ・バックアップ・ジョブが完了し、属性セットで指定されたジョブ・パラメータが不要になった後で、既存の属性セットを削除できます。

属性セットを削除するには:

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。

2. 「リカバリ・アプライアンス」メニューから、「メディア・マネージャ」を選択します。

3. 「属性セット」セクションで、削除する属性セットを選択します。

4. 「削除」をクリックします。
この属性セットの削除の確認を求めるメッセージが表示されます。

5. 「はい」をクリックします。

7.3.4 DBMS_RAを使用した属性セットの管理

この項には次のトピックが含まれます:

- SBT属性セットの編集

- SBT属性セットの削除

7.3.4.1 SBT属性セットの編集

DBMS_RA PL/SQLパッケージの特定のプロシージャを呼び出すことで、SBT属性セットの1つ以上の属性を変更できます。

SBT属性セットを削除するには:

1. SQL*PlusまたはSQL Developerを使用して、リカバリ・アプライアンス管理者としてリカバリ・アプライアンス・データベースに接続します。

2. 変更するSBT属性セットの名前および属性の新しい値を指定して、UPDATE_SBT_ATTRIBUTE_SETプロシージャを実行します。
プロシージャ・コールから除外された属性は、変更されません。

関連項目:

DBMS_RAパッケージのリファレンス

7.3.4.2 SBT属性セットの削除

DBMS_RA PL/SQLパッケージの特定のプロシージャを呼び出すことで、SBT属性セットを削除できます。

SBT属性セットを削除するには:

1. SQL*PlusまたはSQL Developerを使用して、リカバリ・アプライアンス管理者としてリカバリ・アプライアンス・データベースに接続します。

2. 削除するSBTオブジェクトの名前を指定して、DELETE_SBT_ATTRIBUTE_SETプロシージャを実行します。

関連項目:

DBMS_RAパッケージのリファレンス

7.4 テープ・バックアップ・ジョブの作成

この項では、選択したデータベースまたは保護ポリシーに関連付けられているデータベースのテープ・バックアップ・ジョブを作成する方法を説明します。テープ・バックアップ・ジョブ・テンプレートで、テープに保存する必要のあるバックアップのプロパティを定義します。メディア・マネージャ・ライブラリとその属性セットで、これらのジョブ設定を管理します。

リカバリ・アプライアンスには、複数の保護されたデータベースからテープにバックアップをコピーするオプションが用意されています。このタスクを実行するには、バックアップをテープにコピーする保護されたデータベースに含まれる保護ポリシーを指定します。指定した単一のデータベースのバックアップをテープにコピーすることもできます。

関連項目:

- メディア・マネージャ・ライブラリの構成の詳細は、「メディア・マネージャ・ライブラリの作成」を参照してください

- 属性セットの構成の詳細は、「属性セットの作成」を参照してください

Cloud Controlまたはコマンドライン・オプションを使用して、テープ・バックアップ・ジョブを作成できます。この項には次のトピックが含まれます:

- Cloud Controlを使用したテープ・バックアップ・ジョブの作成

- 例: Cloud Controlを使用したテープ・バックアップ・ジョブの作成

- DBMS_RAを使用したテープ・バックアップ・ジョブの作成

- 例: DBMS_RAを使用したテープ・バックアップ・ジョブの作成

7.4.1 Cloud Controlを使用したテープ・バックアップ・ジョブの作成

Cloud Controlは、テープ・バックアップ・ジョブの作成に使用できるグラフィカル・ユーザー・インタフェースです。

テープ・バックアップ・ジョブを作成するには、次の手順を実行します。

1. 「リカバリ・アプライアンスのホームページへのアクセス」の手順を完了します

2. リカバリ・アプライアンスのホームページの「リカバリ・アプライアンス」メニューで、「Copy-to-Tapeジョブ・テンプレート」を選択します。
Copy-to-Tapeジョブ・テンプレート・ページが表示されます。

3. 「作成」をクリックして、新規テープ・バックアップ・ジョブを作成します。
図7-3に示すように、Copy-to-Tapeジョブ・テンプレートの作成ページが表示されます。

このページには、ジョブ・プロパティとスケジュール設定が表示されます。

図7-3 リカバリ・アプライアンスのCopy-to-Tapeジョブ・テンプレートの作成ページ

4. 「名前」フィールドに、ジョブの名前を入力します。

5. オプションで、「メディア・マネージャ・ライブラリ」ドロップダウン・リストから、このジョブを管理するメディア・マネージャ・ライブラリを選択します。

6. 「属性セット」ドロップダウン・リストから、このジョブに使用する属性セットを選択します。この属性セットは、テープ・バックアップ・ジョブの設定を定義します。

7. 「スコープ」フィールドで、次のいずれかを追加します。

- 「保護ポリシー」ドロップダウン・リストから、バックアップをテープにコピーするすべてのデータベースを含む保護ポリシーを選択します。

- バックアップをテープにコピーする1つのデータベースを検索し、選択します。

8. 「バックアップのタイプ」フィールドで、コピーするバックアップのタイプを選択します。オプションには「全体バックアップ」、「増分バックアップ」、「アーカイブ・ログ」があります。

9. (オプション)「優先度」フィールドで、このジョブの優先度を選択します。デフォルトのジョブの優先度は「中」です。

10. 「印刷部数」フィールドに、テープにコピーするバックアップに必要な印刷部数を入力します。最大4コピーおよび最小1コピーを選択できます。

注意:

テープにコピーした後に、バックアップの重複コピーを取得することはできません。

11. 「ランタイム・ウィンドウ」フィールドに、このジョブを完了するために許可されている期間を分数、時間数または日数で入力します。指定されたウィンドウ内に開始しなかったジョブは、次に使用可能なウィンドウ・スロットに完了します。

12. 「Fromタグ」フィールドでタグ名を指定して、特定のタグに関連付けられているバックアップのみをテープにコピーします。

13. 「スケジュール」セクションで、このジョブをただちに実行するか、後から指定した時間に実行するかを指定します。

関連項目:

「Cloud Controlを使用したテープ・バックアップ・ジョブのスケジューリング」

14. 「OK」をクリックします。
Cloud Controlに、ジョブ・リクエストが正常に送信されたことを通知するメッセージが表示されます。

メッセージ内のジョブ名をクリックして、このジョブについてキューに入っているバックアップ・イメージを確認できます。

関連項目:

- テープ・バックアップ操作の詳細は、「リカバリ・アプライアンスでのテープへのバックアップのコピーについて」を参照してください

- 「例: Cloud Controlを使用したテープ・バックアップ・ジョブの作成」

7.4.2 例: Cloud Controlを使用したテープ・バックアップ・ジョブの作成

この例では、テープ・バックアップ・ジョブの組合せを使用して、すべてのバックアップのテープへのコピーを管理し、それらが最新であることを保証します。テープ・バックアップ・ジョブの組合せには、テープ上のすべてのバックアップが系統立って格納されており、情報が失われる可能性を削減できます。

この例では、Cloud Controlを使用してすべてのタスクを実行します。

関連項目:

「Cloud Controlを使用したテープ・バックアップ・ジョブの作成」

テープ・バックアップ例のシナリオを作成するには、次の手順を実行します。

1. 最初のテープ・バックアップ・ジョブを作成し、このジョブにTest1という名前を付けます。

2. このジョブに、デフォルトのメディア・マネージャ・ライブラリROBOT0と属性セットDRIVE_COUNT_2を使用します。
メディア・マネージャ・ライブラリおよび属性セットのデフォルト値を編集するには、それぞれ「メディア・マネージャ・ライブラリの編集」および「属性セットの編集」の手順を完了します。

3. このジョブのスコープを保護ポリシーGOLDとして選択します。

4. このジョブのバックアップ・タイプとして「全体」を選択します。
これを選択した場合、GOLDに含まれるデータベースの全体データベース・バックアップすべてがテープにコピーされます。

5. Test1を日曜の10:00amに実行するようにスケジュールし、1週間おきに繰り返すように設定します。

6. 同様に、2番目のテープ・バックアップ・ジョブを作成し、このジョブにTest2という名前を付けます。

7. このジョブがTest1と同じメディア・マネージャ・ライブラリ、保護ポリシー、属性セットを使用するようにします。

8. このジョブの「バックアップのタイプ」ドロップダウン・リストから、「増分」を選択します。

9. Test2を月曜から土曜の12:30pmに実行するようにスケジュールし、毎日繰り返すように設定します。

10. 前述と同じ手順を使用して、3番目のテープ・バックアップ・ジョブを作成し、Test3という名前を付けます。

11. このジョブのバックアップ・タイプとして「アーカイブ・ログ」を選択します。

12. Test3を6時間間隔で実行するようにスケジュールします。

図7-4に、これらのジョブの発行を完了した後のリカバリ・アプライアンスのCopy-to-Tapeテンプレート画面を示します。

図7-4 テープ・バックアップ・ジョブの例

このシナリオでは、リカバリ・アプライアンスは1週間に1回、すべての全体バックアップをテープにコピーします。その後、リカバリ・アプライアンスは最新の変更が反映されたすべての増分バックアップを毎日コピーして、テープ上に更新済のバックアップ・コピーを保持します。同様に、すべてのアーカイブ済REDOログ・ファイルが6時間おきにコピーされ、テープ上にバックアップの有効なコピーとストレージが確保されるようにします。

7.4.3 DBMS_RAを使用したテープ・バックアップ・ジョブの作成

各SBTジョブでは、テープにコピーするバックアップとコピー先のメディア・プールを定義します。SBTジョブを作成した後、その実行をスケジュールする必要があります。

SBTジョブ・テンプレートを作成するには:

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンス・データベースに接続します。

2. 作成するSBTジョブごとに、CREATE_SBT_JOB_TEMPLATEプロシージャを実行します。

注意:

CREATE_SBT_JOB_TEMPLATEは過負荷状態のプロシージャです。1つのプロシージャ署名で、コピーのバックアップを検討する保護されたデータベースのdb_unique_nameを指定します。下に示す他のプロシージャ署名を使用して、保護ポリシー名を指定します。この場合、保護ポリシーに割り当てられているすべての保護されたデータベースが、コピー対象として検討されます。

3. 保護ポリシー名がprotection_policy_nameパラメータで指定されている場合、SBTジョブの実行時に、保護ポリシーに割り当てられているすべての保護されたデータベースのバックアップが、テープへのコピー対象として検討されます。db_unique_nameが指定されている場合、そのデータベースのバックアップのみが、コピー対象として検討されます。

4. attribute_set_nameパラメータを使用して、テープ・バックアップ操作を制御する属性の集まりであるSBT属性セットの名前を指定します。属性セットは、コピー操作で使用されるSBTライブラリを指定します。SBTチャネル・パラメータおよびメディア管理ソフトウェア・ライブラリに渡すパラメータも指定します。これらのパラメータは、SBTライブラリ・オブジェクトで指定されたパラメータとマージされます。

5. backup_typeパラメータを使用して、タイプALL、INCR、ARCHまたはFULLのカンマ区切りリストとして表される、コピーするバックアップのタイプを追加します。たとえば、'INCR,ARCH'を指定すると、すべての増分(レベル1)バックアップと指定されたメディア・マネージャにまだコピーされていないアーカイブ済ログ・ファイルが含められます。

6. priorityパラメータを使用して、このジョブの優先度レベルを入力します。多くのSBTジョブが同時に実行されるようにスケジュールされている場合、ジョブの優先度によって、最初に実行するジョブが決定されます。ジョブの優先度は、同時に実行するようスケジュールされているすべてのジョブを実行できるだけの十分なテープ・ドライブがない場合に必要になります。ジョブの優先度は、次のいずれかの事前定義値として表されます。

- 1000 (SBT_PRORITY_LOW)

- 100 (SBT_PRIORITY_MEDIUM)

- 10 (SBT_PRIORITY_HIGH)

- 1 (SBT_PRIORITY_CRITICAL)

0は優先度がもっとも高いことを示します。小さい値ほど大きい値より優先度が高くなります。デフォルトの優先度は100 (SBT_PRIORITY_MEDIUM)です。

関連項目:

- テープ・バックアップ操作の詳細は、「リカバリ・アプライアンスでのテープへのバックアップのコピーについて」を参照してください

- プロシージャに関連する引数の詳細は、「CREATE_SBT_JOB_TEMPLATE」を参照してください

- SBTジョブを実行する方法の詳細は、「Oracle Schedulerを使用したテープ・バックアップ・ジョブのスケジューリング」を参照してください

- 「例: DBMS_RAを使用したテープ・バックアップ・ジョブの作成」

7.4.4 例: DBMS_RAを使用したテープ・バックアップ・ジョブの作成

この例では、CREATE_SBT_JOB_TEMPLATEプロシージャを使用してSBTジョブを作成する方法を図示します。

BEGIN
DBMS_RA.CREATE_SBT_JOB_TEMPLATE (
template_name           => 'oltp_arch_lastfull',
protection_policy_name  => 'oltp',
attribute_set_name      => 'wholedb',
backup_type             => 'FULL,ARCH',
priority                => DBMS_RA.SBT_PRIORITY_HIGH,
window                  => INTERVAL '4' HOUR);
END;

この例では、SBTジョブはoltp保護ポリシーに割り当てられている保護されたデータベースごとに、すべてのアーカイブ済ログ・ファイルと最新の全体バックアップを選択します。最新の完全バックアップとは、受信した最新のレベル0バックアップか、受信した最新のレベル1バックアップに基づいた仮想全体バックアップのいずれか新しい方です。

SBTジョブは、コピー操作に使用するSBTライブラリを指定し、SBTチャネル・パラメータおよびメディア管理ソフトウェア・ライブラリに渡すパラメータを指定する、wholedb SBT属性セットを参照します。

まだテープにコピーされていない場合、backup_typeパラメータは、まだSBTにコピーされていないすべてのアーカイブ済ログ・ファイルおよび最新の全体バックアップをコピーします。たとえば、「full、arch」のbackup_typeでは、すべてのアーカイブ済ログのバックアップおよび最新の全体バックアップが選択されます。これらは、まだコピーされていない場合、このジョブの実行時にSBTにコピーされるバックアップです。

4時間のウィンドウは、このジョブで生成されるコピー・タスクを開始できる時間の長さを指定します。このウィンドウが過ぎると、このジョブで生成されたがまだ開始されていないSBTコピー・タスクは、次回このSBTジョブがスケジュールされるまで一時停止されます。ウィンドウが過ぎたときにすでに実行中であったコピー・タスクは、完了できます。

表示されていないのは、オプションのcopiesおよびfrom_tag引数です。

7.5 テープ・バックアップ・ジョブの管理

テープ・バックアップ・ジョブの作成後、ジョブ要件に基づいて一部のプロパティを変更したり、不要になったときに削除する必要が生じることがあります。

関連項目:

テープ・バックアップ・ジョブを作成する方法の詳細は、「テープ・バックアップ・ジョブの作成」を参照してください

この章の内容は次のとおりです。

- Cloud Controlを使用したテープ・バックアップ・ジョブの管理

- DBMS_RAを使用したテープ・バックアップ・ジョブの管理

7.5.1 Cloud Controlを使用したテープ・バックアップ・ジョブの管理

この項の内容は次のとおりです。

- テープ・バックアップ・ジョブの編集

- テープ・バックアップ・ジョブの削除

7.5.1.1 テープ・バックアップ・ジョブの編集

テープ・バックアップ・ジョブの作成後、Cloud Controlを使用してそのプロパティを変更できます。ジョブを後から実行するようにスケジュールした場合、そのパラメータおよびスケジュール設定を編集できます。

テープ・バックアップ・ジョブを編集するには、次の手順を実行します。

1. 「Cloud Controlを使用したテープ・バックアップ・ジョブの作成」の手順を完了します。

2. 編集するテープ・バックアップ・ジョブを選択します。

3. 「編集」をクリックして、既存のジョブ・プロパティとスケジュール設定を変更します。

4. 既存のメディア・マネージャ・ライブラリ、属性セット、優先度、コピー、ランタイム・ウィンドウおよびFromタグの値に必要な変更を加えて、ジョブ・プロパティを編集します。

5. 既存のスケジュール・オプションに変更を加えて、ジョブ・スケジュール設定を編集します。

関連項目:

「Cloud Controlを使用したテープ・バックアップ・ジョブのスケジューリング」

6. 「OK」をクリックします。

7.5.1.2 テープ・バックアップ・ジョブの削除

操作が完了し、必要なすべてのバックアップをテープにコピーした後で、既存のテープ・バックアップ・ジョブを削除できます。進行中のテープ・バックアップ・ジョブを削除すると、テープ・バックアップ操作は選択したバックアップのテープへのコピーを停止します。

テープ・バックアップ・ジョブを削除するには、次の手順を実行します。

1. 「リカバリ・アプライアンスのホームページへのアクセス」の手順を完了します。

2. リカバリ・アプライアンスのホームページの「リカバリ・アプライアンス」メニューで、「Copy-to-Tapeジョブ・テンプレート」を選択します。
Copy-to-Tapeジョブ・テンプレート・ページが表示されます。

3. ジョブのリストから、削除するジョブを選択します。

4. 「削除」をクリックします。
このジョブの削除を続行するかどうかを尋ねる確認メッセージが表示されます。「はい」をクリックします。

7.5.2 DBMS_RAを使用したテープ・バックアップ・ジョブの管理

この項には次のトピックが含まれます:

- SBTジョブの編集

- SBTジョブの削除

7.5.2.1 SBTジョブの編集

DBMS_RA PL/SQLパッケージの特定のプロシージャを呼び出すことで、SBTジョブの1つ以上の属性を変更できます。

SBTジョブを編集するには:

1. SQL*PlusまたはSQL Developerを使用して、リカバリ・アプライアンス管理者としてリカバリ・アプライアンス・データベースに接続します。

2. 変更するSBTジョブの名前および属性の新しい値を指定して、UPDATE_SBT_JOB_TEMPLATEプロシージャを実行します。

例7-2 SBTジョブの変更

この例では、oltp_arch_lastfullという名前のSBTジョブの優先度を変更します。CREATE_SBT_JOB_TEMPLATEに存在し、この呼出しでは除外された引数の値は変更されません。

BEGIN
DBMS_RA.UPDATE_SBT_JOB_TEMPLATE(
template_name => 'oltp_arch_lastfull',
priority      => DBMS_RA.SBT_PRIORITY_HIGH);
END;

関連項目:

DBMS_RAパッケージのリファレンス

7.5.2.2 SBTジョブの削除

特定のDBMS_RA PL/SQLパッケージ・プロシージャを呼び出すことで、SBTジョブを削除できます。

SBTジョブを削除するには:

1. SQL*PlusまたはSQL Developerを使用して、リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続します。

2. 削除するSBTジョブの名前を指定して、DELETE_SBT_JOB_TEMPLATEプロシージャを実行します。

関連項目:

DBMS_RAパッケージのリファレンス

7.6 テープ・バックアップ・ジョブのスケジューリング

この項には次のトピックが含まれます:

- Cloud Controlを使用したテープ・バックアップ・ジョブのスケジューリング

- Oracle Schedulerを使用したテープ・バックアップ・ジョブのスケジューリング

7.6.1 Cloud Controlを使用したテープ・バックアップ・ジョブのスケジューリング

この項では、テープ・バックアップ・ジョブのスケジュールを設定するのに必要な手順について説明します。

テープ・バックアップ・ジョブをスケジュールするには、次の手順を実行します。

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。

2. 「スケジュール」セクションで、次のいずれかを選択します。

- 即時: テープ・バックアップ・ジョブをただちに実行します。

- 後で: テープ・バックアップ・ジョブを指定された未来の時間に実行します。ジョブを実行する日時をmm/dd/yyyy hh:mm:ss形式で入力します。このジョブを繰り返す場合、「繰返し」ドロップダウン・リストから頻度を選択し、該当する値を入力します。

3. 「OK」をクリックしてジョブを保存します。
スケジュール設定を編集するには、必要なテープ・バックアップ・ジョブを選択し、「編集」をクリックして必要な変更を加えます。

関連項目:

テープ・バックアップ・ジョブ・プロパティの詳細は、「Cloud Controlを使用したテープ・バックアップ・ジョブの作成」を参照してください

7.6.2 Oracle Schedulerを使用したテープ・バックアップ・ジョブのスケジューリング

SBTジョブを作成した後、その実行をスケジュールする必要があります。通常、Oracle Schedulerなどのスケジューリング・ユーティリティを使用して、定期的に実行するようにジョブをスケジュールします。

SBTジョブの実行時、リカバリ・アプライアンスは指定されたデータベースの指定されたタイプのすべてのバックアップを調べて、まだテープにコピーされていないバックアップを選択します。その後、リカバリ・アプライアンスはそれらのバックアップをテープにコピーするタスクを生成して、キューに入れます。コピーするバックアップ・ピースごとに、タイプBACKUP_SBTの1つのタスクがリカバリ・アプライアンス・タスク・キューに追加されます。

Oracle Schedulerを使用してテープ・バックアップ・ジョブをスケジュールするには、DBMS_RA.QUEUE_SBT_BACKUP_TASKを呼び出すジョブを作成します。このプロシージャは、SBTジョブという名前の単一の引数を取ります。

Oracle Schedulerを使用してSBTジョブをスケジュールするには、次の手順を実行します。

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンス・データベースに接続します。

2. DBMS_SCHEDULER.CREATE_JOBプロシージャを実行します。
たとえば、次のPL/SQL無名ブロックを実行します。

BEGIN
DBMS_SCHEDULER.CREATE_JOB(
template_name   => 'sbtjob1',
job_type        => 'PLSQL_BLOCK',
job_action      => 'dbms_ra.queue_sbt_backup_task(''oltp_arch_lastfull'');',
start_date      => SYSTIMESTAMP,
enabled         => TRUE,
auto_drop       => TRUE,
repeat_interval => 'freq=WEEKLY; BYDAY=MON,WED,FRI; BYHOUR=23');
END;

関連項目:

- SBTジョブを作成する方法の詳細は、「DBMS_RAを使用したテープ・バックアップ・ジョブの作成」を参照してください

- 「QUEUE_SBT_BACKUP_TASK」

- Oracle Schedulerの詳細は、『Oracle Database管理者ガイド』と『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

7.7 テープ・バックアップ操作の一時停止および再開

この項では、進行中のテープ・バックアップ・ジョブまたはメディア・マネージャ操作を一時停止する手順、および後から再開する方法を説明します。

この項には次のトピックが含まれます:

- Cloud Controlを使用したメディア・マネージャ・ライブラリ操作の一時停止および再開

- DBMS_RAを使用したSBTライブラリの一時停止および再開

7.7.1 Cloud Controlを使用したメディア・マネージャ・ライブラリ操作の一時停止および再開

Cloud Controlを使用してメディア・マネージャ操作を一時停止し、必要なときに再開することを選択できます。

この項には次のトピックが含まれます:

- メディア・マネージャ・ライブラリの一時停止

- メディア・マネージャ・ライブラリの再開

7.7.1.1 メディア・マネージャ・ライブラリの一時停止

進行中のメディア・マネージャ・ライブラリ操作を一時停止するのは、現在のメディア・マネージャ・ライブラリを保留状態にして、一定期間後に再開する場合です。

メディア・マネージャ・ライブラリ操作を一時停止するには:

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。

2. 「リカバリ・アプライアンス」メニューから、「メディア・マネージャ」を選択します。

3. メディア・マネージャ・ライブラリのリストから、進行中のすべてのジョブを一時停止するライブラリを選択します。

4. 「一時停止」をクリックします。

7.7.1.2 メディア・マネージャ・ライブラリの再開

一時停止されているメディア・マネージャ・ライブラリの操作を再開して、ライブラリおよび関連付けられているジョブ操作を続行できます。

関連項目:

「メディア・マネージャ・ライブラリの一時停止」

メディア・マネージャ・ライブラリ操作を再開するには:

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。

2. 「リカバリ・アプライアンス」メニューから、「メディア・マネージャ」を選択します。

3. ジョブ操作を再開する、一時停止されているメディア・マネージャ・ライブラリを選択します。

4. 「再開」をクリックします。

7.7.2 DBMS_RAを使用したSBTライブラリの一時停止および再開

この項には次のトピックが含まれます:

- SBTライブラリの一時停止

- SBTライブラリの再開

7.7.2.1 SBTライブラリの一時停止

SBTライブラリを一時停止するには、次の手順を完了します。

SBTライブラリを一時停止するには:

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンス・データベースに接続します。

2. DBMS_RA.PAUSE_SBT_LIBRARYプロシージャを実行します。
たとえば、次のPL/SQL無名ブロックを実行します。

BEGIN
DBMS_RA.PAUSE_SBT_LIBRARY(
lib_name => 'osbsbt');
END;

ビューRA_SBT_LIBRARYのライブラリ・ステータスがPAUSEに変わります。

関連項目:

- 「PAUSE_SBT_LIBRARY」

- 「RA_SBT_LIBRARY」

7.7.2.2 SBTライブラリの再開

一時停止されたSBTライブラリを再開するには、次の手順を完了します。

SBTライブラリを再開するには:

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続します。

2. DBMS_RA.RESUME_SBT_LIBRARYプロシージャを実行します。
たとえば、次のPL/SQL無名ブロックを実行します。

BEGIN
DBMS_RA.RESUME_SBT_LIBRARY(
lib_name => 'osbsbt');
END;

ビューRA_SBT_LIBRARYのライブラリ・ステータスがREADYに戻ります。

関連項目:

- 「RESUME_SBT_LIBRARY」

- 「RA_SBT_LIBRARY」

7.8 テープ・バックアップ操作のステータスの表示

この項では、メディア・マネージャ・ライブラリとテープ・バックアップ・ジョブのステータスを確認し、その操作の進捗状況をモニターする手順について説明します。

この項には次のトピックが含まれます:

- Cloud Controlを使用したテープ・バックアップ操作のステータスの表示

- DBMS_RAを使用したテープ・バックアップ操作のステータスの表示

7.8.1 Cloud Controlを使用したテープ・バックアップ操作のステータスの表示

この項には次のトピックが含まれます:

- メディア・マネージャ・ライブラリのステータスの表示

- テープ・バックアップ・ジョブのステータスの表示

7.8.1.1 メディア・マネージャ・ライブラリのステータスの表示

メディア・マネージャ・ライブラリの現在のステータスを表示して、進行中のテープ・バックアップ操作に影響を与える可能性のあるメディア管理ソフトウェアのエラーがあるかどうかを確認できます。

メディア・マネージャ・ライブラリのステータスを確認するには:

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。

2. 「リカバリ・アプライアンス」メニューから、「メディア・マネージャ」を選択します。
メディア・マネージャ・ページの対応する列に、既存のすべてのメディア・マネージャ・ライブラリのステータスが一覧表示されます。

7.8.1.2 テープ・バックアップ・ジョブのステータスの表示

ジョブの現在のステータスを表示して、進行中のテープ・バックアップ操作にエラーがあるかどうかを確認できます。

テープ・バックアップ・ジョブのステータスを表示するには、次の手順を実行します。

1. 「Cloud Controlでのリカバリ・アプライアンスへのアクセス」の手順を完了します。

2. 「リカバリ・アプライアンス」メニューから、「Copy-to-Tapeジョブ・テンプレート」を選択します。
Copy-to-Tapeジョブ・テンプレート・ページの対応する列に、各テープ・バックアップ・ジョブのステータスが表示されます。

7.8.2 DBMS_RAを使用したテープ・バックアップ操作のステータスの表示

この項の内容は次のとおりです。

- SBTライブラリのステータスの確認

- テープ・バックアップ・ジョブのステータスの確認

- DBMS_RAを使用したSBTジョブ実行のレビュー

- Oracle Schedulerジョブのステータスの確認

7.8.2.1 SBTライブラリのステータスの確認

RA_SBT_LIBRARYビューを問い合せることで、メディア管理ソフトウェアにエラー状態が存在するかどうかを特定できます。SBTライブラリのPAUSE 状態も特定できます。

SBTライブラリのステータスを表示するには:

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続します。

2. 次の問合せを実行します。

SELECT LIB_NAME, LAST_ERROR_TEXT, STATUS
FROM   RA_SBT_LIBRARY;

LIB_NAME            LAST_ERROR_TEXT                                 STATUS
------------------- ----------------------------------------------- ------
OSBSBT                                                              READY

表7-3に、STATUSに使用できる値を示します。

表7-3 RA_SBT_LIBRARYのSTATUS列の値

値

意味

READY

SBTライブラリは適切に作成され、テープI/Oを処理する準備ができています。

PAUSE

SBTライブラリはPAUSE_SBT_LIBRARYで一時停止されました。

ERROR

メディア管理ソフトウェアにエラー状態が存在します。エラーをクリアしてRESUME_SBT_LIBRARYを呼び出すまで、テープ・バックアップ操作は続行できません。last_error_text列で、メディア管理ライブラリから返された最新のエラーについて説明します。エラー・テキストは、影響を受けたバックグラウンドSBTタスクのRA_SBT_TASK行にも表示されます。

関連項目:

「RA_SBT_LIBRARY」

7.8.2.2 テープ・バックアップ・ジョブのステータスの確認

SBTジョブを実行すると、コピーする各バックアップ・ピースのタスクが生成され、キューに入れられます。ビューRA_SBT_TASKに、これらのタスクとその完了状態を示します。

注意:

完了したタスクは、30日後にこのビューから削除されます。

SBTジョブのステータスを確認するには:

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続します。

2. 次の問合せを実行します(サンプル出力を示します)。

SELECT TASK_ID, STATE, DB_UNIQUE_NAME, ERROR_TEXT, BS_KEY, PIECE#
FROM   RA_SBT_TASK
WHERE  SBT_TEMPLATE_NAME = 'SBTJOB1'
ORDER BY DB_UNIQUE_NAME, BS_KEY, PIECE#;

TASK_ID STATE      DB_UNIQUE_NAME ERROR_TEXT           BS_KEY PIECE#
------- ---------- -------------- -------------------- ------ ------
253 COMPLETED  OLTP1                                   89      1
254 COMPLETED  OLTP1                                   95      1
255 COMPLETED  OLTP1                                   99      1
256 COMPLETED  OLTP1                                  117      1
257 COMPLETED  OLTP1                                  141      1

STATEがKILLEDまたはABORTEDの場合、タスクは失敗しました。

7.8.2.3 DBMS_RAを使用したSBTジョブ実行のレビュー

RA_SBT_JOB.LAST_SCHEDULE_TIME列を問い合せることで、SBTジョブが定義済スケジュールに従って実行されているかどうかを判断できます。この列には、SBTジョブの実行がスケジュールされていた最終時間が示されます。

完了したSBTジョブをレビューするには:

1. SQL*PlusまたはSQL Developerで、リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続します。

2. 次の問合せを実行します(サンプル出力を示します)。

SELECT TEMPLATE_NAME, BACKUP_TYPE, LAST_SCHEDULE_TIME
FROM   RA_SBT_JOB;

TEMPLATE_NAME          BACKUP_TYPE          LAST_SCHEDULE_TIME
------------------  -------------------  ----------------------------
OLTP_ARCH_LASTFULL  ARCH, FULL           27-AUG-12 10.53.49 AM -08:00
OLTP_INCR           INCR                 26-AUG-12 10.16.16 AM -08:00

関連項目:

「RA_SBT_LIBRARY」

7.8.2.4 Oracle Schedulerジョブのステータスの確認

SBTジョブを実行するために作成されたOracle Schedulerジョブのステータスを表示するには:

- 次のビューを問い合せます。

- USER_SCHEDULER_JOBS

- USER_SCHEDULER_JOB_LOG

関連項目:

Oracle Schedulerのデータ・ディクショナリ・ビューの詳細は、『Oracle Database管理者ガイド』を参照してください。

8 リカバリ・アプライアンスでのバックアップのレプリケート

この章では、リカバリ・アプライアンス・レプリケーションを構成する方法を説明します。この章の内容は次のとおりです。

- リカバリ・アプライアンス・レプリケーションについて

- Cloud Controlを使用したリカバリ・アプライアンス・レプリケーションの構成

- DBMS_RAを使用したリカバリ・アプライアンスでのレプリケーションの構成

8.1 リカバリ・アプライアンス・レプリケーションについて

この項には次のトピックが含まれます:

- リカバリ・アプライアンス・レプリケーションの目的

- リカバリ・アプライアンス・レプリケーションの概要

- リカバリ・アプライアンス・レプリケーションのユーザー・インタフェース

- リカバリ・アプライアンス・レプリケーションを構成するための基本的なタスク

関連項目:

「セキュア・レプリケーション」および「リカバリ・アプライアンス・レプリケーション」

8.1.1 リカバリ・アプライアンス・レプリケーションの目的

障害回復戦略の一部として、リカバリ・アプライアンスでは他のリカバリ・アプライアンスにバックアップをレプリケートできます。また、テープ・アーカイブをレプリケートされたリカバリ・アプライアンスにオフロードすることで、プライマリ・リカバリ・アプライアンスのリソースを解放できます。レプリケーションは保護ポリシーによって制御されます。すなわち、ポリシーに関連付けられているすべてのデータベースが、初期設定後、完全に自動的にレプリケートされます。

8.1.2 リカバリ・アプライアンス・レプリケーションの概要

図8-1の簡易なレプリケーション・トポロジでは、保護されたデータベースがあるリカバリ・アプライアンスにバックアップを送信し、そのリカバリ・アプライアンスが他のリカバリ・アプライアンスにバックアップを渡します。このトポロジを一方向リカバリ・アプライアンス・レプリケーションと呼びます。1つめのリカバリ・アプライアンスはアップストリーム・リカバリ・アプライアンスで、2つめはダウンストリーム・リカバリ・アプライアンスです。

図8-1 単純なレプリケーション・トポロジ

この項には次のトピックが含まれます:

- レプリケーションの保護ポリシー

- レプリケーション・トポロジの例

- リカバリ・アプライアンスでのバックアップのレプリケート方法: 基本プロセス

- RMANがレプリケーション環境でバックアップをリストアする方法

8.1.2.1 レプリケーションの保護ポリシー

保護されたデータベースのレプリケーションが行われるのは、次の条件が満たされる場合です。

- アップストリーム・リカバリ・アプライアンスで、レプリケーション・サーバー構成によってダウンストリーム・リカバリ・アプライアンスとして動作するリカバリ・アプライアンスが指定されていること(CREATE_REPLICATION_SERVER)。

- アップストリーム・リカバリ・アプライアンスで、保護ポリシーがレプリケーション・サーバー構成に関連付けられていること(ADD_REPLICATION_SERVER)。

- アップストリーム・リカバリ・アプライアンスで、レプリケーション・サーバー構成に関連付けられている保護ポリシーに保護されたデータベースが割り当てられていること(ADD_DB)。

- ダウンストリーム・リカバリ・アプライアンスで、レプリケートされたバックアップの保護ポリシーが存在し(CREATE_PROTECTION_POLICY)、保護されたデータベースがそれに追加されていること(ADD_DB)。

アップストリーム・リカバリ・アプライアンスで保護ポリシーの構成が完了すると、リカバリ・アプライアンスはポリシーで保護されている各データベースの最新の全体バックアップのみをただちにレプリケートします。バックアップとは、受信した最新のレベル0バックアップか、受信した最新のレベル1バックアップに基づいた仮想全体バックアップのいずれか新しい方です。アップストリーム・リカバリ・アプライアンスは、新しいバックアップを受け取るとそれをレプリケートします。

8.1.2.2 レプリケーション・トポロジの例

レプリケーション・トポロジは、必要だけ複雑にすることができます。主な変数は、次のとおりです。

- レプリケーション環境内のリカバリ・アプライアンスの合計数および相互の関係

- 送信レプリケート済バックアップを管理するアップストリーム・リカバリ・アプライアンスの保護ポリシー(CREATE_PROTECTION_POLICY)、および受信レプリケート済バックアップを管理するダウンストリーム・リカバリ・アプライアンスのポリシー

- レプリケーション環境内の各リカバリ・アプライアンスのレプリケーション・サーバー構成(CREATE_REPLICATION_SERVER)

- レプリケーション・サーバー構成と保護ポリシーとの関連付け(ADD_REPLICATION_SERVER)

アップストリーム・リカバリ・アプライアンスが複数のダウンストリーム・リカバリ・アプライアンスにレプリケートし、ダウンストリーム・リカバリ・アプライアンスが複数のアップストリーム・リカバリ・アプライアンスからバックアップを受け取るように、レプリケーションをチェーンすることができます。ダウンストリーム・リカバリ・アプライアンスは、自らの保護されたデータベースとレプリケートされたバックアップの両方からバックアップを受け取ることができます。レプリケーション・トポロジ内のすべてのリカバリ・アプライアンスは、アップストリーム・レプリケーション・ロールとダウンストリーム・レプリケーション・ロールを同時に実行できます。

注意:

リカバリ・アプライアンスがアップストリームとダウンストリームの両方である場合、両方のロールに対して構成する必要があります。

8.1.2.2.1 1つのダウンストリーム・リカバリ・アプライアンスへのレプリケーション

図8-2に、reppolicy_us_bronze保護ポリシー(orcl08、orcl09およびorcl10)に関連付けられている3つのデータベースと、reppolicy_us_gold保護ポリシー(orcl11、orcl12およびorcl13)に関連付けられている3つのデータベースを示します。reppolicy_us_goldのみがus_bost_ds_desmというレプリケーション・サーバー構成に関連付けられています。このトポロジでは、アップストリームZDLRA Bostonはreppolicy_us_goldポリシーによって保護されたデータベースのバックアップのみをダウンストリームZDLRA Des Moinesに転送します。

図8-2 1つのリカバリ・アプライアンスへのデータベースのレプリケート

8.1.2.2.2 複数のダウンストリーム・リカバリ・アプライアンスへのレプリケーション

保護されたデータベースそれぞれに独自の保護ポリシーがあるため、各ポリシーを異なるレプリケーション・サーバー構成に関連付けることができます。たとえば、図8-3では、reppolicy_us_bronzeポリシーは、reppolicy_us_bronze (orcl08、orcl09およびorcl10)によって保護されたデータベースのバックアップをZDLRA San Franciscoというダウンストリーム・リカバリ・アプライアンスにレプリケートするレプリケーション・サーバー構成us_bost_ds_sfに関連付けられています。reppolicy_us_bronzeポリシーは、reppolicy_us_gold (orcl11、orcl12およびorcl13)によって保護されたデータベースのバックアップをZDLRA Des Moinesというダウンストリーム・リカバリ・アプライアンスにレプリケートするレプリケーション・サーバー構成us_bost_ds_desmに関連付けられています。

図8-3 複数のリカバリ・アプライアンスへのデータベースのレプリケート

8.1.2.2.3 ダウンストリーム・リカバリ・アプライアンスでの異なるポリシーを使用したレプリケーション

レプリケーション・スキーマの各ダウンストリーム・リカバリ・アプライアンスでは、保護ポリシーによってディスク・リカバリ・ウィンドウ目標と受け取ったバックアップのテープ保存ポリシーが定義されます。ダウンストリーム構成とアップストリーム構成は完全に独立しています。このため、ダウンストリーム・リカバリ・アプライアンスを長期保存バックアップ・リポジトリとして使用するなど、アップストリーム・リカバリ・アプライアンスよりも多くの記憶域および長いリカバリ・ウィンドウでダウンストリーム・リカバリ・アプライアンスを構成することができます。

図8-4は、アップストリーム・リカバリ・アプライアンスのreppolicy_us_bronzeバックアップが、ZDLRA San Franciscoのreppolicy_ds_bronzeポリシーによって保護されていることを示しています。アップストリーム・リカバリ・アプライアンスのreppolicy_us_bronzeバックアップは、ZDLRA Des Moinesのreppolicy_ds_goldポリシーによって保護されています。

図8-4 各リカバリ・アプライアンスの保護ポリシーが異なる場合

8.1.2.2.4 カスケード型レプリケーション

図8-5に、より複雑なトポロジを示します。データベースorcl11、orcl12およびorcl13は、最も遠いアップストリームであるZDLRA Bostonのreppolicy_us_gold保護ポリシーによって保護されています。reppolicy_us_goldポリシーはこれらのデータベースのバックアップを、すぐ下流のZDLRA Des Moinesにレプリケートします。ただし、ZDLRA Des Moinesには、データベースorcl11およびorcl12を保護するreppolicy_ds_gold1とデータベースorcl13のみを保護するreppolicy_ds_gold2の2つの別個の保護ポリシーがあります。

図8-5 各リカバリ・アプライアンスに異なる保護ポリシーがあるカスケード型レプリケーション

図8-5では、reppolicy_ds_gold2保護ポリシーはレプリケーション・サーバー構成us_desm_ds_laに関連付けられています。その後、ZDLRA Des Moinesはreppolicy_ds_gold2によって保護されている唯一のデータベースorcl13のバックアップを、最も遠いダウンストリーム・リカバリ・アプライアンスであるZDLRA Los Angelesにレプリケートします。ZDLRA Los Angelesにあるorcl13のバックアップは、reppolicy_dds_goldポリシーによって保護されています。3つ以上のリカバリ・アプライアンスがチェーンにリンクされているこの構成を、カスケード型レプリケーションと呼びます。

8.1.2.3 リカバリ・アプライアンスでのバックアップのレプリケート方法: 基本プロセス

保護されたデータベースを永久的増分ポリシーを使用してリカバリ・アプライアンスにバックアップすると想定します。保護されたデータベースが、レプリケーションが構成されたリカバリ・アプライアンスにバックアップを送信すると、次の基本手順が行われます。

1. アップストリーム・リカバリ・アプライアンスはバックアップを収集し、レプリケーション・サーバー構成に関連付けられているかどうか保護ポリシーを確認します。

2. 保護ポリシーのレプリケーション・サーバー構成が存在する場合、アップストリーム・リカバリ・アプライアンスはバックアップをレプリケートします。レプリケーション・プロセスは次のとおりです。

- メタデータ・レコードを作成して、レプリケートされたレコードを追跡

注意:

リアルタイムREDOトランスポートが有効である場合、受信したREDO変更はリカバリ・アプライアンスによってリアルタイムではレプリケートされません。アーカイブREDOログのバックアップが作成されると、Recovery Applianceは、このバックアップをデータ・ファイルのバックアップとともにレプリケートします。

- 指定された各ダウンストリーム・リカバリ・アプライアンスにネットワークを介してデータ・ブロックを転送

3. ダウンストリーム・リカバリ・アプライアンスはバックアップを収集して、仮想バックアップを作成します。

注意:

ダウンストリームの収集フェーズは、手順1で説明した収集フェーズと同じです。このため、ダウンストリーム・リカバリ・アプライアンスもバックアップをレプリケートするように構成されている場合、アップストリーム・リカバリ・アプライアンスのロールを負い、バックアップをすぐ下流のリカバリ・アプライアンスにバックアップします。

4. その後間もなく、アップストリーム・リカバリ・アプライアンスはダウンストリーム・リカバリ・アプライアンスに調整リクエストを送信し、今度はダウンストリーム・リカバリ・アプライアンスがバックアップに関するメタデータをアップストリーム・リカバリ・アプライアンスに送信します。
リカバリ・アプライアンス・レプリケーションでは、調整はリカバリ・アプライアンスがすぐ下流のリカバリ・アプライアンスからメタデータを受信するプロセスです。

このため、バックアップがレプリケートされた後は、アップストリームおよびダウンストリーム・リカバリ・カタログの両方が保護されたデータベースのバックアップのレコードを所持します。

8.1.2.4 RMANがレプリケーション環境でバックアップをリストアする方法

保護されたデータベースをリストアする場合、一般にRMANは当初バックアップを送信した同じリカバリ・アプライアンスにAS CATALOGを接続します。たとえば、図8-2では、RMANがorcl11をリストアする必要がある場合、RMANはアップストリーム・リカバリ・アプライアンス上のカタログに接続します。

バックアップがレプリケーション・スキーマの任意のリカバリ・アプライアンスにある場合、アップストリーム・リカバリ・アプライアンスは他のリカバリ・アプライアンスからバックアップを取得してリストアできます。たとえば、図8-2で、RMANがorcl11をリストアする必要があるが、バックアップがアップストリーム・リカバリ・アプライアンスからパージされている場合、ダウンストリーム・リカバリ・アプライアンスがバックアップをアップストリーム・リカバリ・アプライアンスに提供し、その後にリストアすることができます。

必要に応じて、RMANはダウンストリーム・リカバリ・アプライアンスから直接バックアップをリストアすることもできます。RMANはAS CATALOGをダウンストリーム・リカバリ・アプライアンスに接続してから、バックアップをリストアします。たとえば、図8-2で、RMANがprod3をリストアする必要があるが、アップストリーム・リカバリ・アプライアンスが一時的にアクセス不可である場合、RMANはダウンストリーム・リカバリ・アプライアンス上のカタログに直接接続して、保護されたデータベース・ホストに直接バックアップをリストアできます。

注意:

Oracle Enterprise Manager Cloud Control (Cloud Control)またはコマンドラインを使用している場合、ダウンストリーム・リカバリ・アプライアンスからバックアップをリストアするには追加構成が必要です。『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

8.1.3 リカバリ・アプライアンス・レプリケーションのユーザー・インタフェース

この項には次のトピックが含まれます:

- Cloud Controlでのレプリケーション・ページへのアクセス

- レプリケーションに関連するDBMS_RAプロシージャ

- レプリケーションのリカバリ・カタログ・ビュー

8.1.3.1 Cloud Controlでのレプリケーション・ページへのアクセス

Cloud Controlのレプリケーション・ページは、デリカバリ・アプライアンス・レプリケーションを構成するための推奨インタフェースです。

レプリケーション・ページにアクセスするには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 「リカバリ・アプライアンス」メニューから、「レプリケーション」を選択します。
図8-6に示すように、レプリケーション・ページが表示されます。

図8-6 レプリケーション・ページ

前述の例で、ZDLRA3_REPというレプリケーション・サーバーはすでに構成されています。「ステータス」列に使用可能であることが示されます。

関連項目:

レプリケーション・ページの詳細は、Cloud Controlのヘルプを参照してください。

8.1.3.2 レプリケーションに関連するDBMS_RAプロシージャ

DBMS_RAパッケージを使用して、レプリケーションを作成および管理できます。表8-1で、レプリケーションに関連する主なプログラム・ユニットについて説明します。

表8-1 レプリケーションに関連する主なプロシージャ

プログラム・ユニット

説明

CREATE_REPLICATION_SERVER

このリカバリ・アプライアンスによるバックアップのレプリケート先ダウンストリーム・リカバリ・アプライアンスを指定するレプリケーション・サーバー構成を作成します。

DELETE_REPLICATION_SERVER

レプリケーション・サーバー構成を削除します。

ADD_REPLICATION_SERVER

レプリケーション・サーバー構成を、CREATE_REPLICATION_SERVERプロシージャで作成された保護ポリシーに追加します。

REMOVE_REPLICATION_SERVER

レプリケーション・サーバー構成を、CREATE_REPLICATION_SERVERプロシージャで作成された保護ポリシーから削除します。

ADD_DB

保護ポリシーにデータベースを追加します。

CREATE_PROTECTION_POLICY

保護ポリシーを作成します。このポリシーに割り当てられているデータベースのレプリケーションを有効にするには、ADD_REPLICATION_SERVERを実行して、レプリケーション・サーバー構成をこのポリシーに関連付ける必要があります。

UPDATE_DB

保護されたデータベースのプロパティを更新します。

関連項目:

DBMS_RAパッケージのリファレンス

8.1.3.3 レプリケーションのリカバリ・カタログ・ビュー

リカバリ・アプライアンス・カタログ・ビューを使用して、レプリケーションをモニターできます。表8-2に、レプリケーションに最も有用なビューについてまとめます。

表8-2 レプリケーションのビュー

ビュー

説明

RA_REPLICATION_SERVER

このビューでは、この特定のリカバリ・アプライアンスからレプリケート済バックアップを直接受け取るダウンストリーム・リカバリ・アプライアンスを示します。

たとえば、リカバリ・アプライアンスAはリカバリ・アプライアンスBにレプリケートし、Bはリカバリ・アプライアンスCにレプリケートします。リカバリ・アプライアンスA上のRA_REPLICATION_SERVERビューには、リカバリ・アプライアンスBは表示されますがリカバリ・アプライアンスCは表示されません。リカバリ・アプライアンスBの同じビューには、リカバリ・アプライアンスCのみ表示されます。リカバリ・アプライアンスCの同じビューにはダウンストリームのリカバリ・アプライアンスがないため、行はありません。

RA_DATABASE

このビューのPOLICY_NAME列に、この保護データベースで使用される保護ポリシーが示されます。REPLICATION_USAGE列に、このデータベースについてレプリケートされたディスク領域の累積量(GB単位)を示します。

RA_PROTECTION_POLICY

このビューは、定義済の保護ポリシーを示します。

RC_BACKUP_PIECE_DETAILS

リカバリ・カタログに記録されている使用可能なすべてのバックアップ・ピースに関する詳細情報を表示します。

関連項目:

リカバリ・アプライアンスのビュー・リファレンス

8.1.4 リカバリ・アプライアンス・レプリケーションを構成するための基本的なタスク

図8-7に、レプリケーションを構成するための基本的なワークフローを示します。「リカバリ・アプライアンスの計画」で、データベースの各サービス層のリカバリ要件を決定するワークフロー内のステージについて説明しています。

図8-7 レプリケーションのワークフロー

構成は、Cloud Controlまたはコマンドライン・インタフェースのどちらかを使用して実行できます。手順があまり複雑でないため、Cloud Controlを使用することをお薦めします。

8.2 Cloud Controlを使用したリカバリ・アプライアンス・レプリケーションの構成

この項では、Cloud Controlでレプリケーション・ページを使用してリカバリ・アプライアンス・レプリケーションを構成する方法を説明します。

前提条件

環境が次の前提条件を満たしている必要があります。

- アップストリームおよびダウンストリーム・リカバリ・アプライアンスが、ネットワークを超えて相互にやり取りできること。

- バックアップ・データをレプリケートするすべての保護されたデータベースが、アップストリーム・リカバリ・アプライアンスに登録されていること。

- ダウンストリーム・リカバリ・アプライアンスが起動され、バックアップを受け取るように構成されていること。

前提条件

リカバリ・アプライアンス環境において、次の文がtrueであると想定します。

- 保護されたデータベースorcl11とorcl12をアップストリーム・リカバリ・アプライアンスZDLRA Bostonにバックアップします。

- ZDLRA Bostonをダウンストリーム・リカバリ・アプライアンスZDLRA Des Moinesにレプリケートします。

- repuser_from_bostonというレプリケーション・ユーザー・アカウントがダウンストリーム・リカバリ・アプライアンス(ZDLRA Des Moines)に存在します。

- vpc_boston1という仮想プライベート・カタログ・アカウントがアップストリーム・リカバリ・アプライアンス(ZDLRA Boston)に存在します。

- アップストリーム・リカバリ・アプライアンス (ZDLRA Boston)のデータベース・インストールを所有するオペレーティング・システム・ユーザーの資格証明がわかっています。

リカバリ・アプライアンス・レプリケーションを構成するには:

1. 「Cloud Controlでの保護ポリシーの作成ページへのアクセス」の説明に従って、ダウンストリーム・リカバリ・アプライアンスでRASYSとして保護ポリシーの作成ページにアクセスします。

図8-8 保護ポリシー・ページ

この例では、ダウンストリーム・リカバリ・アプライアンスであるZDLRA Des Moinesの保護ポリシーの作成ページにアクセスします。

2. 「Cloud Controlを使用した保護ポリシーの作成」に説明されているとおりに、レプリケーション保護ポリシーを作成します。

図8-9 保護ポリシーの作成ページ

この例では、reppolicy_ds_goldというポリシーを作成します。

3. 「Cloud Controlを使用した保護されたデータベースの登録」に説明されているとおりに、データベースを追加し、ダウンストリーム・リカバリ・アプライアンス上のレプリケーション・ユーザー・アカウントへのアクセス権を付与します。

注意:

ダウンストリーム・リカバリ・カタログで保護されたデータベースに対してREGISTER DATABASEコマンドを実行する必要はありません(これは登録の最終手順です)。

図8-10 保護されたデータベースの追加ページ

この例では、保護されたデータベースorcl11とorcl12を追加し、これらのデータベースにrepuser_from_bostonアクセスを付与します。

4. アップストリーム・リカバリ・アプライアンスで、リカバリ・アプライアンスのホームページに移動します。

5. レプリケーションの新しい保護ポリシーを作成する場合は、次のサブステップを完了します。それ以外の場合は、手順6にスキップします。

a. 「Cloud Controlでの保護ポリシーの作成ページへのアクセス」の説明に従って、RASYSとして保護ポリシーの作成ページにアクセスします。
この例では、アップストリーム・リカバリ・アプライアンスであるZDLRA Bostonの保護ポリシーの作成ページにアクセスします。

b. 「Cloud Controlを使用した保護ポリシーの作成」に説明されているとおりに、レプリケーション保護ポリシーを作成します。
この例では、reppolicy_us_goldというポリシーを作成します。

6. 「Cloud Controlを使用した保護されたデータベースの登録」に説明されているとおりに、既存の保護ポリシーにデータベースを追加し、アップストリーム仮想プライベート・カタログ・アカウントへのアクセス権を付与します。

この例では、保護されたデータベースorcl11とorcl12を保護ポリシーreppolicy_us_goldに追加し、これらのデータベースにvpc_boston1アクセスを付与します。

7. 「リカバリ・アプライアンス」メニューから、「レプリケーション」を選択します。
リカバリ・アプライアンス・ログイン・ページが表示されます。

8. ログイン資格証明を入力して、「ログイン」をクリックします。
レプリケーション・ページが表示されます。

9. レプリケーション・サーバーの作成をクリックします。

注意:

ダウンストリーム・リカバリ・アプライアンスで保護ポリシーにデータベースを追加してデータベース・アクセスを付与する前に、アップストリーム・リカバリ・アプライアンスでレプリケーション・サーバーを作成すると、レプリケーションは機能しません。

レプリケーション・サーバーの作成ページが表示されます。

図8-11 レプリケーション・サーバーの作成ページ

10. 次のように値を入力して、「OK」をクリックします。

- 「ダウンストリーム・リカバリ・アプライアンス」フィールドで拡大鏡をクリックし、検出されたターゲットのリストからダウンストリーム・ロールで構成するリカバリ・アプライアンスを選択します。
たとえば、ZDLRA Des Moinesを選択します。

- 「ダウンストリーム・リカバリ・アプライアンス・データベース資格証明」セクションで、ダウンストリーム・リカバリ・アプライアンス上の仮想プライベート・カタログ・アカウントの資格証明を指定します。

注意:

このカタログ・アカウントには、レプリケートされたバックアップをダウンストリーム・リカバリ・アプライアンス上で管理する権限が付与されている必要があります。「仮想プライベート・カタログ・アカウントの作成」を参照してください。

たとえば、vpc_des_moines1と入力します。

- 「アップストリーム・リカバリ・アプライアンス・ホスト資格証明」セクションで、アップストリーム・リカバリ・アプライアンスのデータベース・インストールを所有するオペレーティング・システム・ユーザーの資格証明を指定します。

ジョブ発行IDを示す情報メッセージが表示されます。

11. ジョブ・レポートを表示するには、ジョブ発行IDをクリックします。
プロシージャ・アクティビティ・ページが表示されます。

12. 「プロシージャ・ステップ」セクションで、詳細情報を取得するいずれかまたは全部のステップを選択します。
図8-12に、ダウンストリーム・リカバリ・アプライアンス情報ステップが選択されたプロシージャ・ステップ・ページのスニペットを示します。

図8-12 プロシージャ・ステップ

13. リカバリ・アプライアンスのホームページに戻るには、「ターゲット」、「リカバリ・アプライアンス」をクリックしてからアップストリーム・リカバリ・アプライアンスの名前をクリックします。

14. 「リカバリ・アプライアンス」メニューから、「レプリケーション」を選択します。
レプリケーション・ページが表示されます。

15. 手順9で作成したレプリケーション・サーバー構成を選択して、「保護ポリシーの追加」をクリックします。
保護ポリシーの追加ページが表示されます。

16. 手順6で作成したレプリケーション・ポリシーを選択して、「OK」をクリックします。
この例では、reppolicy_us_goldというポリシーを選択します。

レプリケーション・ページに、保護ポリシーがアタッチされたレプリケーション・サーバー構成が表示されます。

関連項目:

レプリケーション・ページの詳細は、Cloud Controlオンライン・ヘルプを参照してください。

8.3 DBMS_RAを使用したリカバリ・アプライアンスでのレプリケーションの構成

この項では、コマンドライン・ツールを使用してレプリケーションを構成する方法について説明します。基本的なワークフローは次のとおりです。

1. 「DBMS_RAを使用したダウンストリーム・リカバリ・アプライアンスでのレプリケーションの構成」の説明に従って、ダウンストリーム・リカバリ・アプライアンスを構成します。

2. 「DBMS_RAを使用したアップストリーム・リカバリ・アプライアンスでのレプリケーションの構成」の説明に従って、アップストリーム・リカバリ・アプライアンスを構成します。

3. 「リカバリ・アプライアンス・レプリケーションのための保護されたデータベースの構成」に説明されているとおりに、レプリケーションに関与する保護されたデータベースを構成します。

4. 「リカバリ・アプライアンスのレプリケーション・サーバー構成のテスト」に説明されているとおりに、レプリケーションをテストします。

図8-13は、構成フェーズを図示したものです。

図8-13 レプリケーションの手動構成の概要

8.3.1 レプリケーション例の仮定

次に続くレプリケーション・タスクでは、次の条件がtrueであると想定します。

- データベースorcl11とorcl12を、アップストリーム・レプリケーション・ロールで構成するZDLRA Bostonというリカバリ・アプライアンスにバックアップします。

- ZDLRA Des Moinesをダウンストリーム・リカバリ・アプライアンスとして使用します。

- ダウンストリーム・リカバリ・アプライアンスで、repuser_from_bostonというリカバリ・アプライアンス・ユーザー・アカウントを作成します。このアカウントは、レプリケーション・ユーザー・アカウントです。

注意:

このアカウントのネーミング規則は、バックアップのレプリケート元のリカバリ・アプライアンス(この場合、ZDLRA Boston)を使用します。この例の保護ポリシーの名前では、アップストリームにus、ダウンストリームにdsを使用します。

- ダウンストリーム・リカバリ・アプライアンスで、reppolicy_ds_golという保護ポリシーを作成します。このポリシーは、レプリケーションでのみ使用します。

- ダウンストリーム・リカバリ・アプライアンスで、vpc_des_moines1という仮想プライベート・カタログ・アカウントを作成します。RMANでは、このアカウントを使用してデータベースorcl11とorcl12をバックアップおよびリストアします。

- アップストリーム・リカバリ・アプライアンスで、reppolicy_us_goldという保護ポリシーを作成します。このポリシーは、レプリケーションでのみ使用します。

- アップストリーム・リカバリ・アプライアンスで、vpc_boston1という仮想プライベート・カタログ・アカウントを作成します。RMANでは、このアカウントを使用してデータベースorcl11とorcl12をバックアップおよびリストアします。

8.3.2 DBMS_RAを使用したダウンストリーム・リカバリ・アプライアンスでのレプリケーションの構成

この項では、ダウンストリーム・リカバリ・アプライアンスの構成方法について説明します。

注意:

リカバリ・アプライアンスにアップストリーム・ロールとダウンストリーム・ロールの両方がある場合、次の手順はダウンストリーム・リカバリ・アプライアンスのロールのみに関係します。

タスク1: ダウンストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントの作成

保護されたデータベースをバックアップまたはリストアする際、RMANはこのアカウントを使用して、ダウンストリーム・リカバリ・アプライアンス上のリカバリ・カタログに接続します。

このタスクでは、ダウンストリーム・リカバリ・アプライアンスでvpc_des_moines1という仮想プライベート・カタログ・アカウントを作成すると想定します。

仮想プライベート・カタログ・アカウントを作成するには:

- 「仮想プライベート・カタログ・アカウントの作成」の手順に従います。
たとえば、次の文を実行して、CREATE SESSION権限を持つユーザー・アカウントvpc_des_moines1を作成します。

GRANT CREATE SESSION TO vpc_des_moines1 IDENTIFIED BY password;

関連項目:

仮想プライベート・カタログの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

タスク2: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション保護ポリシーの作成

このダウンストリームRecovery Applianceにレプリケートしたバックアップのリカバリ・ウィンドウおよびその他のプロパティを指定する保護ポリシーを作成するには、DBMS_RA.CREATE_PROTECTION_POLICYを実行します。

このタスクでは、reppolicy_ds_goldポリシーを作成してorcl11およびorcl12データベースを保護すると想定します。後から、このポリシーをリカバリ・アプライアンスに関連付けます。

レプリケーション保護ポリシーを作成するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてダウンストリーム・リカバリ・アプライアンス・データベースに接続します。

2. DBMS_RA.CREATE_PROTECTION_POLICYプロシージャで保護ポリシーを作成します。
たとえば、次のPL/SQLプログラムを実行します。

BEGIN
DBMS_RA.CREATE_PROTECTION_POLICY (
protection_policy_name => 'reppolicy_ds_gold',
description            => 'For protected dbs in gold tier',
storage_location_name  => 'delta',
recovery_window_goal   => INTERVAL '28' DAY,
guaranteed_copy        => 'NO');
END;

関連項目:

- 「DBMS_RAを使用した保護ポリシーの作成」

- プロシージャの引数の定義については、「CREATE_PROTECTION_POLICY」を参照してください

タスク3: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション・ユーザー・アカウントの作成

保護されたデータベースのバックアップをレプリケートするようダウンストリーム・リカバリ・アプライアンスを構成する場合、アップストリーム・リカバリ・アプライアンスがこのダウンストリーム・リカバリ・アプライアンスへのログインに使用するレプリケーション・ユーザー・アカウントを作成する必要があります。ダウンストリーム・リカバリ・アプライアンス上のユーザーの資格証明はアップストリーム・リカバリ・アプライアンスに格納されています(「タスク5: アップストリーム・リカバリ・アプライアンスでのOracleウォレットの作成」を参照)。

注意:

管理しやすいように、リカバリ・アプライアンス・レプリケーション専用のレプリケーション・ユーザー・アカウントを作成し、各アップストリーム・アプライアンスには別のレプリケーション・ユーザー・アカウントを作成することをお薦めします。

このタスクでは、アップストリーム・リカバリ・アプライアンスがこのリカバリ・アプライアンスに対する認証に使用するrepuser_from_bostonというアカウントを作成すると想定します。

レプリケーション・ユーザー・アカウントを作成するには:

1. SQL*PlusまたはSQL Developerで、SYSTEMとしてまたはDBAロールを持つユーザーとして、ダウンストリーム・リカバリ・アプライアンス・データベースに接続します。

2. レプリケーション・ユーザー・アカウントを作成します。
たとえば、次のSQL文を実行してrepuser_from_bostonデータベース・ユーザー・アカウントを作成し、CREATE SESSION権限を付与します。

GRANT CREATE SESSION TO repuser_from_boston IDENTIFIED BY ********;

注意:
セキュリティを強化するために非常に複雑なパスワードを使用することをお薦めします。このパスワードおよびユーザー名を後続の手順でOracleウォレットに追加します。これらの資格証明をウォレットに保存すると、パスワードを手動で再入力する必要がなくなります。

関連項目:

データベース・ユーザー・アカウントの作成方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

タスク4: ダウンストリーム・リカバリ・アプライアンスでの保護ポリシーへのデータベースの追加

保護されたデータベースをレプリケーション保護ポリシーに追加するには、DBMS_RA.ADD_DBを実行します。保護されたデータベースごとに予約するディスク領域の量も指定する必要があります。

このタスクでは、データベースorcl11およびorcl12を「タスク2: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション保護ポリシーの作成」で作成したreppolicy_ds_gold保護ポリシーに追加し、保護されたデータベースごとに128GBの予約済領域を割り当てると想定します。

保護ポリシーにデータベースを追加するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてダウンストリーム・リカバリ・アプライアンス・データベースに接続します。

2. DBMS_RA.ADD_DBプロシージャを使用して、保護されたデータベースごとにメタデータを追加します。
たとえば、次のPL/SQLプログラムを実行します。

BEGIN
DBMS_RA.ADD_DB (
db_unique_name         => 'orcl11',
protection_policy_name => 'reppolicy_ds_gold',
reserved_space         => '128G');
END;
BEGIN
DBMS_RA.ADD_DB (
db_unique_name         => 'orcl12',
protection_policy_name => 'reppolicy_ds_gold',
reserved_space         => '128G');
END;

関連項目:

- 「DBMS_RAを使用した保護されたデータベースのメタデータの追加」

- 「ADD_DB」

タスク5: ダウンストリーム・リカバリ・アプライアンスでのデータベース・アクセスの付与

DBMS_RA.GRANT_DB_ACCESSを実行して、次のデータベース・アカウントに保護されたデータベース・アクセスを付与します。

- 「タスク1: ダウンストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントの作成」で作成された仮想プライベート・カタログ・アカウント

- 「タスク3: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション・ユーザー・アカウントの作成」で作成されたレプリケーション・ユーザー・アカウント

レプリケーションおよびカタログ・アカウントに保護されたデータベース・アクセスを付与するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてダウンストリーム・リカバリ・アプライアンス・データベースに接続します。

2. このアカウントで認証する必要のあるアップストリーム・リカバリ・アプライアンスにバックアップを送信する保護されたデータベースごとに、レプリケーション・ユーザーに権限を付与します。
次の例では、レプリケーション・ユーザーrepuser_from_bostonに、保護されたデータベースorcl11およびorcl12で必要な権限を付与します。

BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'repuser_from_boston',
db_unique_name => 'orcl11');
END;
BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'repuser_from_boston',
db_unique_name => 'orcl12');
END;

3. このアカウントで認証する必要のある各アップストリーム・リカバリ・アプライアンス上の保護されたデータベースごとに、仮想プライベート・カタログ・アカウントに権限を付与します。
次の例ではリカバリ・カタログ・アカウントvpc_des_moines1に、保護されたデータベースorcl11およびorcl12で必要な権限を付与します。

BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'vpc_des_moines1',
db_unique_name => 'orcl11');
END;
BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'vpc_des_moines1',
db_unique_name => 'orcl12');
END;

関連項目:

- 「DBMS_RAを使用したリカバリ・アプライアンス・アカウントへのデータベース・アクセスの付与」

- 「GRANT_DB_ACCESS」

8.3.3 DBMS_RAを使用したアップストリーム・リカバリ・アプライアンスでのレプリケーションの構成

この項では、アップストリーム・リカバリ・アプライアンスの構成方法について説明します。この項では、「DBMS_RAを使用したダウンストリーム・リカバリ・アプライアンスでのレプリケーションの構成」の手順が完了したと想定します。

注意:

リカバリ・アプライアンスにアップストリーム・ロールとダウンストリーム・ロールの両方がある場合、次の手順はアップストリーム・ロールのみに関係します。

タスク1: アップストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントの作成

保護されたデータベースをバックアップする際、RMANはこのアカウントを使用して、アップストリーム・リカバリ・アプライアンス上のリカバリ・カタログに接続します。

この項では、アップストリーム・リカバリ・アプライアンスでvpc_boston1という仮想プライベート・カタログ・アカウントを作成すると想定します。

仮想プライベート・カタログ・アカウントを作成するには:

1. 「仮想プライベート・カタログ・アカウントの作成」の手順に従います。
たとえば、次の文を実行して、CREATE SESSION権限を持つユーザー・アカウントvpc_boston1を作成します。

GRANT CREATE SESSION TO vpc_boston1 IDENTIFIED BY password;

関連項目:

仮想プライベート・カタログの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

タスク2: アップストリーム・リカバリ・アプライアンスでの保護ポリシーの作成

DBMS_RA.CREATE_PROTECTION_POLICYを実行して、このアップストリーム・リカバリ・アプライアンスへのバックアップのディスク・リカバリ・ウィンドウおよびその他のプロパティを指定する保護ポリシーを作成します。アップストリーム・リカバリ・アプライアンスは、これらのバックアップをダウンストリーム・リカバリ・アプライアンスにレプリケートします。

このタスクでは、reppolicy_us_goldポリシーを作成してorcl11およびorcl12データベースを保護すると想定します。次のタスクでは、この保護ポリシーを保護されたデータベースに関連付けます。

リカバリ・アプライアンス・レプリケーションの保護ポリシーを作成するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてアップストリーム・リカバリ・アプライアンスのメタデータ・データベースに接続します。

2. DBMS_RA.CREATE_PROTECTION_POLICYプロシージャで各保護ポリシーを作成します。
たとえば、次のPL/SQLプログラムを実行します。

BEGIN
DBMS_RA.CREATE_PROTECTION_POLICY (
protection_policy_name => 'reppolicy_us_gold',
description            => 'For protected dbs in gold tier',
storage_location_name  => 'delta',
recovery_window_goal   => INTERVAL '28' DAY,
guaranteed_copy        => 'NO');
END;

関連項目:

- 「DBMS_RAを使用した保護ポリシーの作成」

- プロシージャの引数の定義については、「CREATE_PROTECTION_POLICY」を参照してください

タスク3: アップストリーム・リカバリ・アプライアンスでの保護ポリシーへのデータベースの追加

保護されたデータベースをレプリケーション保護ポリシーに追加するには、DBMS_RA.ADD_DBプロシージャを実行します。保護されたデータベースごとに予約するディスク領域の量も指定する必要があります。

このタスクでは、データベースorcl11およびorcl12を「タスク2: アップストリーム・リカバリ・アプライアンスでの保護ポリシーの作成」で作成したreppolicy_us_gold保護ポリシーに追加し、保護されたデータベースごとに128GBの予約済領域を割り当てると想定します。

保護ポリシーにデータベースを追加するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてアップストリーム・リカバリ・アプライアンスのメタデータ・データベースに接続します。

2. DBMS_RA.ADD_DBプロシージャを使用して、保護されたデータベースごとにメタデータを追加します。
たとえば、次のPL/SQLプログラムを実行します。

BEGIN
DBMS_RA.ADD_DB (
db_unique_name         => 'orcl11',
protection_policy_name => 'reppolicy_us_gold',
reserved_space         => '128G');
END;
BEGIN
DBMS_RA.ADD_DB (
db_unique_name         => 'orcl12',
protection_policy_name => 'reppolicy_us_gold',
reserved_space         => '128G');
END;

関連項目:

- 「DBMS_RAを使用した保護されたデータベースのメタデータの追加」

- 「ADD_DB」

タスク4: アップストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントへのデータベース・アクセスの付与

「タスク1: アップストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントの作成」で作成したアップストリーム・カタログ・アカウントに保護されたデータベース・アクセスを付与するには、DBMS_RA.GRANT_DB_ACCESSを実行します。この手順により、RMANは保護されたデータベースのバックアップまたはリストア時にリカバリ・カタログに接続できるようになります。

仮想プライベート・カタログに保護されたデータベース・アクセスを付与するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてアップストリーム・リカバリ・アプライアンスのメタデータ・データベースに接続します。

2. バックアップをレプリケートする保護されたデータベースごとに、仮想プライベート・カタログ・アカウントに権限を付与します。
次の例ではカタログ・アカウントvpc_boston1に、保護されたデータベースorcl11およびorcl12で必要な権限を付与します。

BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'vpc_boston1',
db_unique_name => 'orcl11');
END;
BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'vpc_boston1',
db_unique_name => 'orcl12');
END;

関連項目:

- 「DBMS_RAを使用したリカバリ・アプライアンス・アカウントへのデータベース・アクセスの付与」

- 「GRANT_DB_ACCESS」

タスク5: アップストリーム・リカバリ・アプライアンスでのOracleウォレットの作成

アップストリーム・リカバリ・アプライアンスで、mkstoreユーティリティを使用してOracle自動ログイン・ウォレットを作成し、「タスク3: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション・ユーザー・アカウントの作成」で作成したレプリケーション・ユーザー資格証明を追加します。アップストリーム・リカバリ・アプライアンスは、ダウンストリーム・アプライアンスへのログイン時にこれらの資格証明が必要となります。格納されている各資格証明には、リカバリ・アプライアンス・ユーザー・アカウントの名前と検証が含まれます。

注意:

既存のウォレットが自動ログイン・ウォレットである(ウォレットにアクセスするたびにパスワードを入力する必要がない)場合、それを使用できます。Oracleのファイル拡張子は*.ssoです。既存のOracleウォレットを使用する場合は、下の手順2をスキップします。

このタスクでは、次のことを想定しています。

- アップストリーム・リカバリ・アプライアンス・ホストの/dbfs_repdbfs/REPLICATIONディレクトリでレプリケーションに使用するOracleウォレットを作成します。

- レプリケーション・ユーザーrepuser_from_bostonの資格証明を追加します。

アップストリーム・リカバリ・アプライアンスでOracleウォレットを作成するには:

1. アップストリーム・リカバリ・アプライアンス・ホストに、リカバリ・アプライアンスをインストールしたオペレーティング・システム・ユーザーまたはそのユーザーのオペレーティング・システム・グループのメンバーとしてログインします。

2. Oracleウォレットを作成するには、次のコマンドを実行します。wallet_locationは、ウォレットを格納するアップストリーム・リカバリ・アプライアンスの既存のディレクトリです。

mkstore -wrl wallet_location -createALO

たとえば、次のコマンドは/dbfs_repdbfs/REPLICATIONディレクトリに自動ログイン・ウォレットを作成します。

mkstore -wrl /dbfs_repdbfs/REPLICATION -createALO

mkstoreユーティリティにより、cwallet.ssoという名前のファイルが指定した場所に作成されます。

3. 資格証明を追加するには、次のコマンドを実行します。

mkstore -wrl wallet_location -createCredential serv_name ds_rep_user pwd

プレースホルダは次のように定義されています。

- wallet_locationは、ウォレットを作成するディレクトリです。ディレクトリは存在している必要があります。

- serv_nameは、Oracleネットワーク上でダウンストリーム・リカバリ・アプライアンスを識別するためにEZ接続記述子で使用するOracleネットワーク・サービス名です。

- ds_rep_userは、ダウンストリーム・リカバリ・アプライアンス上のレプリケーション・ユーザー・アカウントのユーザー名です。

- pwdは、ダウンストリーム・リカバリ・アプライアンス上のレプリケーション・ユーザーのセキュア・パスワードです。

たとえば、次のコマンドは、ポート1522およびデータベース名zdlradsmを使用するネット・サービス名radsm01repl-scan.acme.comと、レプリケーション・ユーザー名repuser_from_bostonの資格証明を追加します。

mkstore -wrl /dbfs_repdbfs/REPLICATION -createCredential \
"radsm01repl-scan.acme.com:1522/zdlradsm" "repuser_from_boston" "pwd"

4. Oracleウォレットに資格証明のリストを表示する次のコマンドを実行して、すべてのユーザーの資格証明が正しく追加されたことを確認します(パスワードまたは検証は表示されません)。

mkstore -wrl wallet_location -listCredential

たとえば、次のコマンドは/dbfs_repdbfs/REPLICATIONに格納されているOracleウォレット内の資格証明のリストを表示します。

mkstore -wrl /dbfs_repdbfs/REPLICATION -listCredential

Oracle Secret Store Tool : Version 12.1.0.1 Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved.
List credential (index: connect_string username)
1: radsm01repl-scan1.acme.com:1522/zdlradsm repuser_from_boston

関連項目:

- tnsnames.oraの場所については、『Oracle Database Net Services管理者ガイド』を参照してください。

- ネット・サービス名の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

タスク6: アップストリーム・リカバリ・アプライアンスでのレプリケーション・サーバー構成の作成

DBMS_RA.CREATE_REPLICATION_SERVERを実行して、このアップストリーム・リカバリ・アプライアンスをレプリケートするダウンストリーム・リカバリ・アプライアンスごとにレプリケーション・サーバー構成を作成します。

注意:

ダウンストリーム・リカバリ・アプライアンスで保護ポリシー(ADD_DB)にデータベースを追加してデータベース・アクセス(GRANT_DB_ACCESS)を付与する前に、アップストリーム・リカバリ・アプライアンスでCREATE_REPLICATION_SERVERを実行すると、ORA-600エラーが発生する可能性があります。

このタスクでは、次のことを想定しています。

- zdlradsm_repというレプリケーション・サーバー構成を作成します。

注意:

レプリケーション・サーバー構成名は任意です。ただし、ダウンストリーム・リカバリ・アプライアンスのサービス名を使用することをお薦めします。これは、データベース名(この例ではzdlradsm)の後に_repを付けたものでもあります。

- アップストリーム・リカバリ・アプライアンスで、レプリケーション・アカウントrepuser_from_bostonを使用してダウンストリーム・リカバリ・アプライアンスにログインします。このアカウントは「タスク3: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション・ユーザー・アカウントの作成」で作成されました。

- 構成では、「タスク5: アップストリーム・リカバリ・アプライアンスでのOracleウォレットの作成」で作成したOracleウォレットに格納されているネット・サービス名radsm01repl-scan.acme.com:1522/zdlradsmを使用します。

- Oracleウォレットは/dbfs_repdbfs/REPLICATIONに格納されています。

- すべてのリカバリ・アプライアンスに事前インストールされているリカバリ・アプライアンス・バックアップ・モジュールのファイル名は/u01/app/oracle/product/12.1.0.2/dbh1/lib/libra.soです。このモジュールは、SBTメディア管理ライブラリとして機能します。RMANは、リカバリ・アプライアンスにバックアップするためのチャネルを割当てまたは構成する際に、このモジュールを参照します(「リカバリ・アプライアンス・レプリケーションのための保護されたデータベースの構成」を参照)。

レプリケーション・サーバー構成を作成するには:

1. SQL*PlusまたはSQL Developerで、RASYSとしてアップストリーム・リカバリ・アプライアンスのメタデータ・データベースに接続します。

2. ダウンストリーム・リカバリ・アプライアンスごとにDBMS_RA.CREATE_REPLICATION_SERVERプロシージャを実行します。
次の例では、ZDLRA Des Moinesというダウンストリーム・リカバリ・アプライアンスにzdlradsm_repというレプリケーション・サーバー構成を作成します。

BEGIN
DBMS_RA.CREATE_REPLICATION_SERVER (
replication_server_name => 'zdlradsm_rep',
sbt_so_name      => '/u01/app/oracle/product/12.1.0.2/dbh1/lib/libra.so',
catalog_user_name       => 'RASYS',
wallet_alias            => 'radsm01repl-scan.acme.com:1522/zdlradsm',
wallet_path             => '/dbfs_repdbfs/REPLICATION');
END;

3. レプリケーション・サーバー構成の作成を確認します。
たとえば、次の問合せを実行します。

SELECT COUNT(*) should_be_one
FROM   RA_REPLICATION_SERVER
WHERE  REPLICATION_SERVER_NAME = 'ZDLRADSM_REP';

SHOULD_BE_ONE
-------------
1

構成が正しく作成された場合、戻り値は1です。

関連項目:

- プロシージャの引数の説明については、「CREATE_REPLICATION_SERVER」を参照してください

- リカバリ・アプライアンス・バックアップ・モジュールの詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

- 有効なクライアント構成ファイル・パラメータとその定義のリストについては、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

タスク7: アップストリーム・リカバリ・アプライアンスの保護ポリシーとの関連付け

レプリケーション・サーバー構成を保護ポリシーに割り当てることで、保護されたデータベースそれぞれをレプリケートするダウンストリーム・リカバリ・アプライアンスを指定します。このタスクが完了すると、リカバリ・アプライアンス・レプリケーションは有効になります。

注意:

1つの保護ポリシーに複数のレプリケーション・サーバー構成を割り当てることができます。

このタスクでは、次のことを想定しています。

- 「タスク6: アップストリーム・リカバリ・アプライアンスでのレプリケーション・サーバー構成の作成」で作成したzdlradsm_repというレプリケーション・サーバー構成を使用します。

- レプリケーション・サーバー構成を、「タスク2: アップストリーム・リカバリ・アプライアンスでの保護ポリシーの作成」で作成した保護ポリシーreppolicy_us_goldに追加します。

レプリケーション・サーバー構成を保護ポリシーに関連付けるには:

1. リカバリ・アプライアンス管理者としてリカバリ・アプライアンスのメタデータ・データベースに接続していることを確認します。

2. 保護ポリシーとレプリケーション・サーバー構成の組合せごとに、DBMS_RA.ADD_REPLICATION_SERVERプロシージャを実行します。
たとえば、次のPL/SQLプログラムを実行します。

BEGIN
DBMS_RA.ADD_REPLICATION_SERVER (
replication_server_name => 'zdlradsm_rep',
protection_policy_name  => 'reppolicy_us_gold');
END;

関連項目:

「ADD_REPLICATION_SERVER」

8.3.4 リカバリ・アプライアンス・レプリケーションのための保護されたデータベースの構成

リカバリ・アプライアンス・レプリケーション環境に参加する保護されたデータベースはそれぞれ、正しく構成する必要があります。たとえば、保護されたデータベースごとに、次を実行する必要があります。

- アップストリームおよびダウンストリーム・リカバリ・アプライアンス上の仮想プライベート・カタログ所有者のOracleウォレット資格証明を、Oracleウォレットに追加します。

注意:

レプリケーション構成では、ダウンストリーム資格証明の追加は要求されません。ただし、アップストリーム・リカバリ・アプライアンスがアクセス不可の場合、およびRMANがダウンストリーム・リカバリ・アプライアンスからバックアップのリストアを試行する場合、RMANはダウンストリーム・リカバリ・アプライアンスで仮想プライベート・カタログに直接接続する必要があります。この場合、Oracleウォレットでダウンストリーム資格証明が必要になります。

- Oracleウォレットの内容を確認します。

- アップストリーム・リカバリ・アプライアンスの仮想プライベート・カタログでデータベースを登録します。

- 保護されたデータベースをバックアップし、RMANチャネルを割り当てる際に正しいOracleウォレットの場所を指定します。

保護されたデータベースの構成方法については、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

8.3.5 リカバリ・アプライアンスのレプリケーション・サーバー構成のテスト

レプリケーション・スキーマに関わる保護されたデータベースごとに、次のプロシージャを使用して、アップストリーム・リカバリ・アプライアンスからすべてのダウンストリーム・リカバリ・アプライアンスへのレプリケーションをテストします。このプロシージャを繰り返して、複雑なレプリケーション・トポロジの各レプリケーション・パスをテストします。

この項では、次のことを前提にしています。

- アップストリーム・リカバリ・アプライアンスZDLRA Bostonからダウンストリーム・リカバリ・アプライアンスZDLRA Des Moinesへのorcl11のバックアップのレプリケーションをテストします。

- ZDLRA Bostonではテープにもバックアップします。

保護されたデータベースのレプリケーションをテストするには:

1. RMANを起動し、保護されたデータベースにTARGETとして接続し、アップストリーム・リカバリ・アプライアンス上の仮想プライベート・カタログにCATALOGとして接続します。

たとえば、システム・プロンプトに次のコマンドを入力して、orcl11にTARGETとして、およびzdlra_bostonにCATALOGとして接続します。

rman TARGET ra_admin@orcl11 CATALOG /@zdlra01bosingest-scan1.acme.com:1521/zdlrabos:dedicated

2. バックアップ・セットのリストを表示し、アップストリームおよびダウンストリーム・リカバリ・アプライアンスにバックアップが存在することを確認します。

たとえば、次のコマンドを実行します(出力例も示します)。

RMAN> LIST BACKUPSET;
.
.
.

BS Key  Size
------- ----------
54746   224.25M

List of Archived Logs in backup set 54746
Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
---- ------- ---------- ------------------- ---------- ---------
1    17854   153525644  2014/07/01 12:59:40 153545145  2014/07/01 13:00:34
1    17855   153545145  2014/07/01 13:00:34 153564529  2014/07/01 13:01:36
1    17856   153564529  2014/07/01 13:01:36 153585644  2014/07/01 13:02:26
1    17857   153585644  2014/07/01 13:02:26 153606722  2014/07/01 13:03:18
1    17858   153606722  2014/07/01 13:03:18 153629480  2014/07/01 13:04:11
1    17859   153629480  2014/07/01 13:04:11 153651278  2014/07/01 13:05:05
1    17860   153651278  2014/07/01 13:05:05 153672263  2014/07/01 13:05:59

Backup Set Copy #1 of backup set 54746
Device Type Elapsed Time Completion Time     Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE    02:52:20     2014/07/01 13:14:46 NO         TAG20140701T131434

List of Backup Pieces for backup set 54746 Copy #1
BP Key  Pc# Status      Media                   Piece Name
------- --- ----------- ----------------------- ----------
54747   1   AVAILABLE   Oracle Recovery Appliance (ZDLRA Boston) 4qpca79s_1_1_DB1211LG

Backup Set Copy #2 of backup set 54746
Device Type Elapsed Time Completion Time     Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE    02:52:20     2014/07/01 16:06:56 NO         TAG20140701T131434

List of Backup Pieces for backup set 54746 Copy #2
BP Key  Pc# Status      Media                   Piece Name
------- --- ----------- ----------------------- ----------
55019   1   AVAILABLE   Oracle Recovery Appliance (ZDLRA Des Moines) RA_SBT_54971_4qpca79s_1_2_54746_1
.
.
.

前述の出力では、バックアップ・セット54746には2つのコピーがあります。コピー#1はアップストリーム・リカバリ・アプライアンスZDLRA Bostonにあり、コピー#2はダウンストリーム・リカバリ・アプライアンスZDLRA Des Moinesにあります。

3. SQL*PlusまたはSQL Developerで、RASYSとしてアップストリーム・リカバリ・アプライアンスに接続します。

4. アップストリーム・リカバリ・アプライアンスのレプリケーション・ステータスが正しいことを確認します。

たとえば、RA_REPLICATION_SERVERを問い合せて、「タスク6: アップストリーム・リカバリ・アプライアンスでのレプリケーション・サーバー構成の作成」で作成したレプリケーション・サーバー構成のRUNNINGの状態を確認します。

SELECT REPLICATION_SERVER_NAME AS "RS_NAME",
REPLICATION_SERVER_STATE AS "RS_STATE",
FROM   RA_REPLICATION_SERVER;

RS_NAME         RS_STATE
--------------- --------
ZDLRADSM_REP RUNNING

前述のすべてのテストで予期した結果が出た場合、アップストリーム・リカバリ・アプライアンスはこの保護されたデータベースのバックアップを正常にレプリケートしています。

9 追加の高可用性計画の実装

レプリケーションに加えて、他の高可用性計画をリカバリ・アプライアンスとともに使用して、特定のシナリオでのデータ損失に対する保護を強化できます。

サイト障害およびシステムの停止に対してアプライアンスを保護するOracle最大可用性アーキテクチャ(MAA)のベスト・プラクティスは、リカバリ・アプライアンス・レプリケーションを使用して障害回復戦略を実装することです。レプリカ・アプライアンスを使用すると、保護されたデータベースのバックアップ、REDOおよびリストア操作は中断されることなく続行され、完全なデータ保護が維持されます。

組織に障害回復戦略がない場合、または既存の障害回復戦略にローカル・システムの高可用性を追加する場合は、リカバリ・アプライアンスのバックアップおよびREDOフェイルオーバー機能を使用できます。この機能は、リカバリ・アプライアンス・ソフトウェア更新12.1.1.1.8から使用可能です。バックアップおよびREDOフェイルオーバーの構成の詳細および手順は、「バックアップおよびREDOフェイルオーバー計画を使用した一時的な停止の管理」を参照してください。

高可用性(HA)および障害回復ソリューションのもう1つのコンポーネントは、Oracle Data Guardです。Oracle Data Guardは、保護されたデータベースの同期化されたスタンバイ・データベースを維持することによって、サービス中断および生じたデータ損失を最小限に抑えます。Oracle Data Guardの詳細は、「最大可用性: Oracle Data Guardと連携するリカバリ・アプライアンス」を参照してください。

関連項目:

リカバリ・アプライアンス・レプリケーションの詳細は、「リカバリ・アプライアンスでのバックアップのレプリケート」を参照してください。

9.1 バックアップおよびREDOフェイルオーバー計画を使用した一時的な停止の管理

バックアップおよびREDOフェイルオーバーは、プライマリ・リカバリ・アプライアンスが停止したとき、または計画メンテナンスが必要なときに、保護されたデータベースがバックアップおよびREDOを一時的に代替リカバリ・アプライアンスに送ることを許可する高可用性機能です。これによって、保護されたデータベースのバックアップおよびREDOは中断することなく続行され、完全なデータ保護を維持できます。また、データベースのローカル・アーカイブ・ログの宛先が一杯になりデータベースに影響を与えることを防止します(代替のバックアップ宛先がない場合はそのようになることがあります)。

9.1.1 バックアップおよびREDOフェイルオーバー機能の概要

バックアップおよびREDOフェイルオーバーが構成されている環境で、保護されたデータベースは、通常の状況ではプライマリ・リカバリ・アプライアンスにバックアップおよびREDOを送信します。そのアプライアンスが使用できない場合、保護されたデータベースは、プライマリのサービスがリストアされるまで、バックアップおよびREDOを代替リカバリ・アプライアンスに送信します。

代替アプライアンスは、受信した一時バックアップから仮想完全バックアップを作成せず、バックアップ・ピースの格納のみを行います(増分バックアップおよびアーカイブ・ログ・バックアップ)。プライマリ・アプライアンスがオンラインに戻って機能するようになると、代替アプライアンスはすべての一時バックアップをプライマリ・アプライアンスに転送し、プライマリ・アプライアンスはそのバックアップを使用して対応する仮想完全バックアップを作成します。すべての仮想完全バックアップが作成されると、保護されたデータベースはプライマリ・アプライアンスへのバックアップおよびREDOの送信を再開します。代替アプライアンスは、プライマリ・アプライアンスに正常に転送して初めて、ローカル記憶域から一時バックアップ・ピースを削除します。

9.1.2 バックアップおよびREDOフェイルオーバーの構成

この項では、バックアップおよびREDOフェイルオーバーを構成する方法について説明します。基本的なワークフローは次のとおりです。

1. 「バックアップおよびREDOフェイルオーバーのためのプライマリ・リカバリ・アプライアンスの構成」の説明に従って、プライマリ・リカバリ・アプライアンスを構成します。

2. 「バックアップおよびREDOフェイルオーバーのための代替リカバリ・アプライアンスの構成」の説明に従って、代替リカバリ・アプライアンスを構成します。

3. 「バックアップおよびREDOフェイルオーバーのためのレプリケーションの構成」の説明に従って、代替リカバリ・アプライアンスからプライマリ・リカバリ・アプライアンスへのレプリケーションを構成します。

4. 「バックアップおよびREDOフェイルオーバーのための保護されたデータベースの構成」の説明に従って、バックアップを送信するために保護されたデータベースを構成します。

9.1.2.1 バックアップおよびREDOフェイルオーバーのためのプライマリ・リカバリ・アプライアンスの構成

バックアップおよびREDOフェイルオーバーのためにプライマリ・リカバリ・アプライアンスを構成するには、レプリケーション・シナリオのダウンストリーム・リカバリ・アプライアンスの設定用タスクの多くを実行します。

タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成

「仮想プライベート・カタログ・アカウントの作成」の手順に従います。

たとえば、次のSQL文を実行して、CREATE SESSION権限を持つVPCユーザーvpcuserおよびレプリケーション・ユーザーrepuser_from_alternateを作成します。

GRANT CREATE SESSION TO vpcuser IDENTIFIED BY password;
GRANT CREATE SESSION TO repuser_from_alternate IDENTIFIED BY password;

タスク2 プライマリ・リカバリ・アプライアンスでの保護ポリシーの作成

「DBMS_RAを使用した保護ポリシーの作成」の手順に従います。store_and_forwardフィールドがNOに設定されていることを確認します。

たとえば、次のPL/SQLプログラムを実行して、primary_brfポリシーを作成します。

BEGIN
DBMS_RA.CREATE_PROTECTION_POLICY (
protection_policy_name => 'primary_brf',
description            => 'For protected dbs on primary',
storage_location_name  => 'delta',
recovery_window_goal   => INTERVAL '28' DAY,
guaranteed_copy        => 'NO',
store_and_forward      => 'NO');
END;

タスク3: プライマリ・リカバリ・アプライアンスでの保護ポリシーへのデータベースの追加

「DBMS_RAを使用した保護されたデータベースのメタデータの追加」の手順に従います。

たとえば、次のPL/SQLプログラムを実行して、orcl12を前のタスクで作成したprimary_brfポリシーに追加します。

BEGIN
DBMS_RA.ADD_DB (
db_unique_name         => 'orcl12',
protection_policy_name => 'primary_brf',
reserved_space         => '128G');
END;

タスク4: プライマリ・リカバリ・アプライアンスでのVPCユーザーおよびレプリケーション・ユーザーへのデータベース・アクセスの付与

「DBMS_RAを使用したリカバリ・アプライアンス・アカウントへのデータベース・アクセスの付与」の手順に従います。

たとえば、次のPL/SQLプログラムを実行して、VPCユーザーvpcuserおよびレプリケーション・ユーザーrepuser_from_alternateに、保護されたデータベースorcl12で必要な権限を付与します。

BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'vpcuser',
db_unique_name => 'orcl12');
END;
BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'repuser_from_alternate',
db_unique_name => 'orcl12');
END;

9.1.2.2 バックアップおよびREDOフェイルオーバーのための代替リカバリ・アプライアンスの構成

代替リカバリ・アプライアンスを構成するには、レプリケーション・シナリオのアップストリーム・リカバリ・アプライアンスの設定に類似したタスクを実行します。

タスク1 代替リカバリ・アプライアンスでのバックアップおよびREDOフェイルオーバーのための保護ポリシーの作成

「DBMS_RAを使用した保護ポリシーの作成」の手順に従います。store_and_forwardフィールドをYESに設定していることを確認します。

たとえば、次のPL/SQLプログラムを実行して、alt_brfポリシーを作成します。

BEGIN
DBMS_RA.CREATE_PROTECTION_POLICY (
protection_policy_name => 'alt_brf',
description            => 'For protected dbs on alternate',
storage_location_name  => 'delta',
recovery_window_goal   => INTERVAL '28' DAY,
guaranteed_copy        => 'NO',
store_and_forward      => 'YES');
END;

タスク2: 代替リカバリ・アプライアンスでの保護ポリシーへのデータベースの追加

「DBMS_RAを使用した保護されたデータベースのメタデータの追加」の手順に従います。

たとえば、次のPL/SQLプログラムを実行して、orcl12を前のタスクで作成したalt_brfポリシーに追加します。

BEGIN
DBMS_RA.ADD_DB (
db_unique_name         => 'orcl12',
protection_policy_name => 'alt_brf',
reserved_space         => '128G');
END;

タスク3: 代替リカバリ・アプライアンスでのVPCユーザーへのデータベース・アクセスの付与

このユーザーは、「タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成」で作成されました。

「DBMS_RAを使用したリカバリ・アプライアンス・アカウントへのデータベース・アクセスの付与」の手順に従います。

たとえば、次のPL/SQLプログラムを実行して、VPCユーザーvpcuserに保護されたデータベースorcl12で必要な権限を付与します。

BEGIN
DBMS_RA.GRANT_DB_ACCESS (
username       => 'vpcuser',
db_unique_name => 'orcl12');
END;

9.1.2.3 バックアップおよびREDOフェイルオーバーのレプリケーションの構成

プライマリ・リカバリ・アプライアンスおよび代替リカバリ・アプライアンスを構成した後、代替アプライアンスからプライマリ・アプライアンスへのレプリケーションの設定に類似したタスクを実行します。このシナリオでは、代替アプライアンスはアップストリーム・ロールを持ち、プライマリ・アプライアンスはダウンストリーム・ロールを持ちます。

タスク1: 代替リカバリ・アプライアンスでのOracleウォレットの構成

代替リカバリ・アプライアンスで、mkstoreユーティリティを使用してOracle自動ログイン・ウォレットを作成し、「タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成」で作成したレプリケーション・ユーザーの資格証明を追加します。代替リカバリ・アプライアンスは、プライマリ・リカバリ・アプライアンスへのログイン時にこれらの資格証明が必要となります。

代替リカバリ・アプライアンスで自動ログイン・ウォレットを構成するには:

1. 次のコマンドを実行して、/dbfs_repdbfs/REPLICATIONディレクトリにOracleウォレットを作成します。

mkstore -wrl /dbfs_repdbfs/REPLICATION -createALO

mkstoreユーティリティにより、cwallet.ssoという名前のファイルが指定した場所に作成されます。

2. 次のコマンドを実行して、レプリケーション・ユーザー資格証明を追加します。

mkstore -wrl wallet_location -createCredential serv_name rep_user pwd

プレースホルダは次のように定義されています。

- wallet_locationは、前の手順でウォレットを作成したディレクトリです。

- serv_nameは、Oracleネットワーク上でプライマリ・リカバリ・アプライアンスを識別するためにEZ接続記述子で使用するOracleネットワーク・サービス名です。

- rep_userは、レプリケーション・ユーザー・アカウントのユーザー名です。

- pwdは、レプリケーション・ユーザーrep_userのセキュア・パスワードです。

たとえば、次のコマンドは、ポート1522およびデータベース名rapriを使用するネット・サービス名rapribrf-scan.acme.comと、レプリケーション・ユーザー名repuser_from_alternateの資格証明を追加します。

mkstore -wrl /dbfs_repdbfs/REPLICATION -createCredential \
"rapribrf-scan.acme.com:1522/rapri" "repuser_from_alternate" "pwd"

3. 次のコマンドを実行して、このユーザーに資格証明が適切に追加されたことを確認します。

mkstore -wrl /dbfs_repdbfs/REPLICATION -listCredential

Oracle Secret Store Tool : Version 12.1.0.1 Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved.
List credential (index: connect_string username)
1: rapribrf-scan.acme.com:1522/rapri repuser_from_alternate

結果にパスワードは表示されません。

タスク2: 代替リカバリ・アプライアンスでのレプリケーション・サーバー構成の作成

DBMS_RA.CREATE_REPLICATION_SERVERを実行して、この代替リカバリ・アプライアンスが停止後にバックアップを転送するプライマリ・リカバリ・アプライアンスにレプリケーション・サーバー構成を作成します。

このタスクでは、次のことを想定しています。

- raprimary_repというレプリケーション・サーバー構成を作成します。

- 代替リカバリ・アプライアンスで、レプリケーション・アカウントrepuser_from_alternateを使用してプライマリ・リカバリ・アプライアンスにログインします。このアカウントは、「タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成」で作成されました。

- 構成では、「タスク1: 代替リカバリ・アプライアンスでのOracleウォレットの構成」で作成したOracleウォレットに格納されているネット・サービス名rapribrf-scan.acme.com:1522/rapriを使用します。

- Oracleウォレットは/dbfs_repdbfs/REPLICATIONに格納されています。

- すべてのリカバリ・アプライアンスに事前インストールされているリカバリ・アプライアンス・バックアップ・モジュールのファイル名は/u01/app/oracle/product/12.1.0.2/dbh1/lib/libra.soです。このモジュールは、SBTメディア管理ライブラリとして機能します。RMANは、リカバリ・アプライアンスにバックアップするためのチャネルを割当てまたは構成する際に、このモジュールを参照します(「リカバリ・アプライアンス・レプリケーションのための保護されたデータベースの構成」を参照)。

レプリケーション・サーバー構成を作成するには:

1. SQL*PlusまたはSQL Developerで、RASYSとして代替リカバリ・アプライアンスのメタデータ・データベースに接続します。

2. プライマリ・リカバリ・アプライアンスに対してDBMS_RA.CREATE_REPLICATION_SERVERプロシージャを実行します。
次の例では、プライマリ・リカバリ・アプライアンスにraprimary_repというレプリケーション・サーバー構成を作成します。

BEGIN
DBMS_RA.CREATE_REPLICATION_SERVER (
replication_server_name => 'raprimary_rep',
sbt_so_name      => '/u01/app/oracle/product/12.1.0.2/dbh1/lib/libra.so',
catalog_user_name       => 'RASYS',
wallet_alias            => 'rapribrf-scan.acme.com:1522/rapri',
wallet_path             => '/dbfs_repdbfs/REPLICATION');
END;

3. レプリケーション・サーバー構成の作成を確認します。
たとえば、次の問合せを実行します。

SELECT COUNT(*) should_be_one
FROM   RA_REPLICATION_SERVER
WHERE  REPLICATION_SERVER_NAME = 'RAPRIMARY_REP';

SHOULD_BE_ONE
-------------
1

構成が正しく作成された場合、戻り値は1です。

タスク3: 代替リカバリ・アプライアンスのバックアップおよびREDOフェイルオーバーの保護ポリシーとの関連付け

レプリケーション・サーバー構成を保護ポリシーに割り当てることで、代替リカバリ・アプライアンスが停止後にバックアップを転送するプライマリ・リカバリ・アプライアンスを指定します。

このタスクでは、次のことを想定しています。

- 「タスク2: 代替リカバリ・アプライアンスでのレプリケーション・サーバー構成の作成」で作成したraprimary_repというレプリケーション・サーバー構成を使用します。

- レプリケーション・サーバー構成を、「タスク1: 代替リカバリ・アプライアンスでのバックアップおよびREDOフェイルオーバーのための保護ポリシーの作成」で作成した保護ポリシーalt_brfに追加します。

レプリケーション・サーバー構成をバックアップおよびREDOフェイルオーバー保護ポリシーに関連付けるには:

1. リカバリ・アプライアンス管理者として代替リカバリ・アプライアンスのメタデータ・データベースに接続していることを確認します。

2. バックアップおよびREDOフェイルオーバー保護ポリシーとレプリケーション・サーバー構成に対して、DBMS_RA.ADD_REPLICATION_SERVERプロシージャを実行します。
たとえば、次のPL/SQLプログラムを実行します。

BEGIN
DBMS_RA.ADD_REPLICATION_SERVER (
replication_server_name => 'raprimary_rep',
protection_policy_name  => 'alt_brf');
END;

関連項目:

「ADD_REPLICATION_SERVER」

9.1.2.4 バックアップおよびREDOフェイルオーバーのための保護されたデータベースの構成

バックアップおよびREDOフェイルオーバーのレプリケーションを構成した後、保護されたデータベースの管理者はこの項のタスクを実行して、保護されたデータベースが通常の状況ではバックアップをプライマリ・リカバリ・データベースに送信し、計画停止または計画外の停止の間は代替リカバリ・アプライアンスに送信できるようにする必要があります。

タスク1: ウォレットの場所を指定するsqlnet.oraの構成

sqlnet.oraファイルに、Oracleウォレットの場所が含まれていることを確認します。

次の例は、ウォレットの場所のエントリがどのように表示されるかを示しています。

SQLNET.WALLET_OVERRIDE = true
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra)
)
)

タスク2: sqlnet.oraで指定した場所での自動ログイン・ウォレットの作成

次の例では、「タスク1: ウォレットの場所を指定するsqlnet.oraの構成」で指定したディレクトリに自動ログイン・ウォレットを作成します。

$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createALO

タスク3: プライマリおよび代替リカバリ・アプライアンスの資格証明のウォレットへの追加

このタスクでは、保護されたデータベースの管理者は、「タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成」で作成したVPCユーザーを使用して、プライマリおよび代替アプライアンスの資格証明をウォレットに追加します。

次の例では、プライマリ・アプライアンスrapribrf-scan.acme.com:1521/rapri:dedicatedおよび代替アプライアンスraaltbrf-scan.acme.com:1521/raalt:dedicatedのvpcuser資格証明を、保護されたデータベース上のウォレットに追加します。

$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createCredential "rapribrf-scan.acme.com:1521/rapri:dedicated" "vpcuser" "pwd"
$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createCredential "raaltbrf-scan.acme.com:1521/raalt:dedicated" "vpcuser" "pwd"

タスク4: データベースの代替リカバリ・アプライアンスへの登録および制御ファイルのバックアップ

このタスクでは、保護されたデータベースの管理者が手順1および2を実行し、リカバリ・アプライアンス管理者が手順3を実行します。

データベースを登録し、制御ファイルをバックアップするには:

1. RMANを使用して、保護されたデータベースにはTARGETとして、代替リカバリ・アプライアンス・カタログにはCATALOGとして接続し、REGISTER DATABASEコマンドを実行します。

2. REGISTER DATABASEコマンドが完了した後、現在の制御ファイルを代替アプライアンスにバックアップします。

BACKUP DEVICE TYPE SBT CURRENT CONTROLFILE;

3. 制御ファイルのバックアップが代替アプライアンスからプライマリ・アプライアンスにレプリケートされたことを確認します。

タスク5: データベースがプライマリ・リカバリ・アプライアンスに登録されていることの確認

この手順では、保護されたデータベースがプライマリ・アプライアンスに登録されていることを確認します。前のタスクでデータベースが代替アプライアンスに登録されるときにレプリケーションが構成されるため、データベースはプライマリ・アプライアンスに自動的に登録される必要があります。

プライマリ・アプライアンスへの登録を確認するには:

1. RMANで、CATALOG接続文字列にプライマリ・アプライアンス資格証明を使用して、データベースに接続します。
rman TARGET / CATALOG /@rapribrf-scan.acme.com:1521/rapri:dedicated

2. REGISTER DATABASEコマンドを実行します。
次のエラーが表示されます。

RMAN-20002: target database already registered in recovery catalog

注意:

- 保護されたデータベースの管理者は、プライマリ・アプライアンスが使用できないときにバックアップを代替リカバリ・アプライアンスに送り、プライマリ・アプライアンスが機能するようになったらバックアップをプライマリ・アプライアンスにリダイレクトする、別のRMANバックアップ・スクリプトを作成する必要もあります。このスクリプトは代替リカバリ・アプライアンス・カタログに接続する必要があり、credential_aliasを代替アプライアンスに設定したCONFIGURE CHANNELまたはALLOCATE CHANNELコマンドが必要です。リカバリ・アプライアンスのRMANバックアップ・スクリプトを作成する方法の例は、Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイドを参照してください。

- プライマリ・アプライアンスの停止中にリアルタイムREDOを代替リカバリ・アプライアンスに送信するには、プライマリ・アプライアンスへの接続に使用するログ・アーカイブ宛先のALTERNATEとして追加のログ・アーカイブ宛先を定義する必要があります。接続文字列は、プライマリ・アプライアンスに必要な接続文字列と同様に、Oracle自動ログイン・ウォレットに定義して、同じVPCユーザー(パスワードは異なる場合がありますが)を使用する必要があります。ALTERNATE属性を使用して代替リモート宛先に自動的にフェイルオーバーする方法の例は、Data Guard概要および管理を参照してください。

10 リカバリ・アプライアンスのモニタリング

この章では、メトリックの構成および構成設定を含め、リカバリ・アプライアンスの基本的なモニタリングを実行する方法について説明します。

10.1 リカバリ・アプライアンスのモニタリングについて

この項には次のトピックが含まれます:

- リカバリ・アプライアンスをモニタリングする目的

- リカバリ・アプライアンス・モニタリング機能の概要

- リカバリ・アプライアンスをモニタリングするためのCloud Controlインタフェース

- リカバリ・アプライアンスをモニタリングするための基本的なタスク

関連項目:

アーキテクチャの概要については、「保護ポリシー」を参照してください

10.1.1 リカバリ・アプライアンスをモニタリングする目的

進行中のリカバリ・アプライアンス管理において、リカバリ・アプライアンスの全体的な健全性を定期的にモニタリングし、保護されたデータベース、バックアップ・ジョブおよびレプリケーション・ジョブ、記憶域使用状況のステータスを確認することは、非常に重要です。

10.1.2 リカバリ・アプライアンス・モニタリング機能の概要

この項では、Oracleで提供されているモニタリング・ツールについて説明します。

10.1.2.1 Cloud Control

リカバリ・アプライアンス管理者の主要なモニタリング・ツールは、Oracle Enterprise Manager Cloud Control (Cloud Control)インシデントおよびイベント通知フレームワークです。プライマリ・インタフェースはリカバリ・アプライアンスのホームページで、警告、アラート、エラーが目立つように表示されます。Cloud Controlに統合されたモニタリング・フレームワークは、問題を管理し、解決するまで追跡する有効な方法です。

領域管理は、リカバリ・アプライアンスの管理において非常に重要です。記憶域需要に対応する十分な時間を確保するには、予測される記憶域ニーズがいつ使用可能な記憶域量の合計に達するかを知っておく必要があります。Cloud Controlには、記憶域使用量の総計に関する警告およびエラー・メッセージが表示されるため、必要な変更を加えるための十分な時間を確保できます。

Cloud Controlでは、管理目標にあわせて設定をカスタマイズできます。たとえば、特定のデータベースのリカバリ・ウィンドウ目標を満たすのに必要な領域が、予約済領域のユーザー定義比率である場合、警告を受信することができます。電子メール・アラートを構成して、システムにログインすることなく、問題の通知をただちに受信することもできます。

関連項目:

Cloud Controlオンライン・ヘルプ

10.1.2.2 Oracle Configuration Manager

Oracle Configuration Managerは構成情報を収集し(デフォルトでは毎日)、Oracle Management Repositoryにアップロードします。サービス・リクエストを記録する場合、構成データがサービス・リクエストに関連付けられます。Oracle Support Serviceは、データを分析してよりよいサービスを提供します。

Oracle Configuration Managerには、次の利点があります。

- サポートの問題を解決する時間の短縮

- 問題を回避するための事前の対策の提供

- ベスト・プラクティスおよびOracleナレッジ・ベースへのアクセスの改善

- 顧客のビジネス・ニーズの理解の向上および一貫したレスポンスとサービスの提供

各OracleホームにはOracle Configuration Managerソフトウェアがインストールされます。一般に、各Oracleホームには、My Oracle Support (MOS)資格証明で情報を収集してアップロードするコレクタが構成されています。配置されているOracleホームおよびコレクタが切断されているか構成されていないOracleホームの情報を収集するセントラル・コレクタも構成できます。

関連項目:

- Oracle Configuration Managerの概要は、『Oracle Configuration Managerインストレーションおよび管理ガイド』を参照してください。

- Oracle Configuration Managerコレクション概要

10.1.2.3 自動サービス・リクエスト(ASR)

自動サービス・リクエスト(ASR)は、特定のリカバリ・アプライアンス・ハードウェアに障害が発生すると自動的にサービス・リクエストを開く機能です。ASRは、ディスク、ファン、電源装など、最も一般的なサーバー・コンポーネントで障害を検出します。ASRはサーバー・コンポーネントのみをモニターし、発生する可能性のあるすべての障害を検出するわけではありません。

ASRは、SMTP、SNMPアラートなど、カスタマ・データ・センター内のその他のモニタリング・メカニズムにかわるものではありません。交換ハードウェアの発送を促進および簡素化する補完メカニズムです。

関連項目:

ASRの設定方法については、『Zero Data Loss Recovery Applianceオーナーズ・ガイド』を参照してください。

10.1.3 リカバリ・アプライアンスをモニタリングするためのCloud Controlインタフェース

リカバリ・アプライアンスをモニタリングするためのプライマリ・インタフェースはリカバリ・アプライアンスのホームページです(「リカバリ・アプライアンスのホームページへのアクセス」を参照)。次の図に示すように、存在する警告とアラートがホームページに表示されます。

ホームページの次のセクションで、モニタリング情報を表示します。

- サマリー
このセクションでは、問題なし、アラートあり、警告ありのデータベースの数を表示します。Cloud Controlでは、アラートは特定のメトリック条件が発生したことを示すインジケータです。たとえば、アラートはメトリックしきい値に達したことを示します。

- メディア・マネージャおよびレプリケーション
これらのセクションでは、copy-to-tapeおよびリカバリ・アプライアンス・レプリケーション・サービスのステータスを表示します。

- 保護されたデータベースの問題
このセクションでは、保護されたデータベースのバックアップ・ステータスの概要を示します。また、影響を受けたデータベースを示すためのカテゴリ・フィルタを使用できます。

- インシデントとイベント
このセクションでは、リカバリ・アプライアンスおよび関連付けられているすべてのターゲットについてレポートされたインシデントとイベントを表示します。ターゲットおよびカテゴリ別にフィルタリングできます。「サマリー」リンクをクリックして、「インシデント・マネージャ」にドリルダウンし、インシデントの詳細情報を表示できます。

注意:

根本にある問題が解決されると、警告は自動的にクリアされます。

関連項目:

リカバリ・アプライアンスのホームページのコンポーネントの詳細は、Cloud Controlオンライン・ヘルプを参照してください。

10.1.4 リカバリ・アプライアンスをモニタリングするための基本的なタスク

この項では、リカバリ・アプライアンスをモニタリングする場合の基本的なタスクについて説明します。次の図は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、モニタリング・タスクを強調して示したものです。

図10-1 リカバリ・アプライアンス・ワークフローでのモニタリング・タスク

通常、モニタリング・タスクを実行する順序は次のとおりです。

1. 構成フェーズでは、メトリック設定を構成します(「リカバリ・アプライアンスの設定と構成」を参照)。たとえば、しきい値を上回った場合に警告を発行するようにリカバリ・アプライアンスを構成できます。
「メトリックと収集設定の変更」で、このタスクについて説明します。

2. 進行中のメンテナンス・フェーズでは(「Recovery Applianceのメンテナンス・タスク」を参照)、必要に応じて保護ポリシーを変更します。一般的な変更タスクには次のものがあります。

- 必要に応じて、インシデントを調査します。
「インシデント・マネージャ・ページの表示」で、このタスクについて説明します。

- 必要に応じて、メトリックを表示します。
「メトリックと収集設定の変更」で、このタスクについて説明します。

10.2 メトリックと収集設定の変更

メトリックと収集設定ページには、ターゲット・メトリック収集のしきい値とスケジュールの詳細が表示されます。このページを使用して、ターゲット・メトリックやその他の収集対象アイテムの警告しきい値とクリティカルしきい値、および収集の時間間隔を編集できます。このページでは、変更可能な設定の場合、「編集」列に鉛筆アイコンが示されます。

前提条件

RASYSとしてリカバリ・アプライアンスのメタデータ・データベースにログインする必要があります。

前提条件

データベースのリカバリ・ウィンドウ目標を満たすのに必要な領域が、予約済領域設定の80%である場合、警告を受信したいと考えています。クリティカルしきい値は95%にします。

メトリックと収集設定を変更するには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 「リカバリ・アプライアンス」メニューから、「モニタリング」をクリックし、「メトリックと収集設定」設定をクリックします。
「メトリックと収集設定」ページが表示されます。

3. 「表示」メニューで「すべてのメトリック」が選択されていない場合は、選択します。
ページがリフレッシュされ、使用可能なすべてのメトリックが表示されます。

4. 「保護されたデータベース」を展開します。

5. 「予約済領域のパーセンテージとしてのリカバリ・ウィンドウ領域」という行が見つかるまで、ページを下にスクロールします。

6. この行に対して、次の値を入力して「OK」をクリックします。

- 「警告のしきい値」列に80と入力します。

- 「クリティカルのしきい値」列に95と入力します。

確認メッセージが表示されます。

注意:

これらのしきい値を上回ったときに生成されるアラート・メッセージのデフォルト・テキストを変更するには、鉛筆アイコンをクリックします。

7. 必要に応じて、他のメトリック設定を変更します。

関連項目:

メトリックと収集設定の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

10.3 インシデント・マネージャ・ページの表示

「インシデントとイベント」セクションには、リカバリ・アプライアンスのすべてのインシデント、イベントおよび警告が表示されます。任意のインシデントをクリックして、インシデント・マネージャ・ページを開きます。インシデント・マネージャを使用すると、環境に影響するインシデントと問題を1か所で検索、表示、管理および解決できます。

前提条件

RASYSとしてメタデータ・データベースにログインする必要があります。

前提条件

このチュートリアルでは、リカバリ・アプライアンスのリカバリ・アプライアンス・ホームページの「インシデントとイベント」セクションに警告が表示されると想定します。詳細を取得できます。

インシデント・マネージャ・ページを表示するには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 可能性のある問題については、「インシデントとイベント」セクションを確認してください。
たとえば、このセクションには次の警告が表示されます。

ORA-64739: RECOVERY_WINDOW_GOAL is lost for database STORE22

3. 関心のあるインシデントのサマリー・リンクをクリックします。
選択した警告のインシデント・マネージャ・ページが、一般サブページが選択された状態で表示されます。

4. サブページをクリックすると、インシデントの詳細情報を取得できます。

関連項目:

インシデント・マネージャの詳細は、Cloud Controlオンライン・ヘルプを参照してください。

10.4 パフォーマンスのモニタリング

リカバリ・アプライアンスには、システムのパフォーマンスを評価する際に役立つユーティリティとして、rastat.plとnetwork_throughput_test.shの2つが付属しています。

10.4.1 rastatユーティリティによるパフォーマンス統計の生成

rastat.plは、リカバリ・アプライアンスに対するテストを実行してパフォーマンス統計を収集するコマンドライン・ユーティリティで、システムのボトルネックを特定する際に便利です。

テストでは、次の統計が生成されます。

- ネットワーク経由でリカバリ・アプライアンスに送信されたバックアップ・データ

- ネットワーク経由でリカバリ・アプライアンスから受信したリストア・データ

- リカバリ・アプライアンスのASMディスク・グループの読取りまたは書込みI/O

- リカバリ・アプライアンスのコンテナ・ファイルの読取りまたは書込みI/O

- リカバリ・アプライアンスのコンテナ・ファイルの割当て率

このユーティリティは、保護されたデータベースまたはアップストリームのリカバリ・アプライアンスであるLinuxまたはUNIXベースのクライアント・マシンから実行できるPerlのスクリプトです。ただし、I/Oテストはリカバリ・アプライアンス・サーバーから直接実行することもできます。

保護された1つ以上のデータベースで複数のテストを並行して実行すれば、実環境をシミュレートできます。それぞれのテスト結果は、個々のクライアントのパフォーマンスを表します。保護された他のデータベースとリカバリ・アプライアンスのテスト中に、バックアップやリストア、または他のテストなど継続中のアクティビティがあると、統計結果に影響する場合があります。

10.4.1.1 rastatユーティリティを実行する前提条件

rastatユーティリティを実行する前に、次の前提条件が満たされていることを確認してください。

- rastatを実行するプラットフォームが、LinuxまたはUNIXであること。

- 保護されたデータベースからユーティリティを実行する場合は、リカバリ・アプライアンス計算サーバーの/opt/oracle.RecoveryAppliance/client/ディレクトリからrastat.plファイルをコピーします。

- 保護されたデータベースをリカバリ・アプライアンスに登録する手順を完了します。「保護されたデータベースの登録」を参照してください。

- ユーティリティを実行する際に、該当するオプションを使用して設定する予定がない場合は、環境変数$ORACLE_HOMEと$ORACLE_SIDが構成されていることを確認します。

10.4.1.2 rastatユーティリティの実行

この項では、rastat.plを実行する方法を説明したうえで、各種のパフォーマンス・テストを実行する方法の例と、その出力サンプルを示します。

注意:

NETBACKUPとNETRESTOREのテストで、標準出力に結果が表示されない場合は、sbtio<pid>.logログ・ファイルを見れば結果を確認できます。

rastatユーティリティを実行するには、次のようにします。

1. 「rastatユーティリティを実行する前提条件」を参照して、ユーティリティを実行するシステムが前提条件を満たしていることを確認してください。

2. コマンド・プロンプト・ウィンドウを開きます。

3. 実行するテストの適切なコマンド構文を入力し、[Enter]キーを押します。
一般的な構文とテストごとのオプションは、「rastatユーティリティのリファレンス」を参照してください。

例1: rastatを実行してバックアップのパフォーマンスをテスト

次の例では、NETBACKUPテストを指定して、バックアップ・ファイルのサイズを2048MBに設定し、リカバリ・アプライアンスのVPCユーザー接続文字列を指定して、--parmsオプションでRMAN構成を設定します。

>$ORACLE_HOME/perl/bin/perl rastat.pl --test=NETBACKUP --filesize=2048M
--catalog=rman/rman@inst2 --parms='SBT_LIBRARY=/u01/oracle/lib/libra.so,
ENV=(RA_WALLET=location=file:/u01/oracle/dbs/ra_wallet
credential_alias=ra-scan:1521/zdlra5:dedicated)'

NETWORK TEST FROM PROTECTED DATABASE TO RECOVERY APPLIANCE

393 MB/s, 2048 MB sent

例2: rastatを実行して、リカバリ・アプライアンスのASMディスク・グループからの読取りI/Oをテスト

次の例では、ASMREADテストを指定して、テスト・ファイルのサイズを2048MBに設定し、リカバリ・アプライアンスのSYSユーザー接続文字列を指定して、読取り元のディスク・グループとして+RCVAREAを指定します。

>$ORACLE_HOME/perl/bin/perl rastat.pl --test=ASMREAD --filesize=2048M
--rasys=admin/admin@inst2 --diskgroup=+RCVAREA

RECOVERY APPLIANCE READ IO TEST FROM DISK

Disk Group: +RCVAREA

2048 MB, 6.06s read IO time, .65s CPU time, 337.99 MB/s, 10.79% CPU usage

PL/SQL procedure successfully completed.

例3: rastatを実行して、リカバリ・アプライアンスのコンテナ・グループからの書込みI/Oをテスト

次の例では、CONTAINERWRITEテストを指定して、テスト・ファイルのサイズを2048MBに設定し、リカバリ・アプライアンスのSYSユーザー接続文字列を指定して、書込み先のディスク・グループとしてBLOCK_POOLコンテナ・グループを指定します。

>$ORACLE_HOME/perl/bin/perl rastat.pl --test=CONTAINERWRITE --filesize=2048M
--rasys=admin/admin@inst2 --diskgroup=/:BLOCK_POOL

RECOVERY APPLIANCE WRITE IO TEST TO CONTAINER FILES

Disk Group: /:BLOCK_POOL

2048 MB, 9.55s write IO time, 3.50s CPU time, 214.35 MB/s, 36.60% CPU usage

PL/SQL procedure successfully completed.

例4: rastatを実行して、リカバリ・アプライアンスのコンテナ・グループへのファイル割当てをテスト

次の例では、CONTAINERALLOCテストを指定して、テスト・ファイルのサイズを2048MBに設定し、リカバリ・アプライアンスのSYSユーザー接続文字列を指定して、書込み先のディスク・グループとしてBLOCK_POOLコンテナ・グループを指定します。

>$ORACLE_HOME/perl/bin/perl rastat.pl --test=CONTAINERALLOC --filesize=2048M
--rasys=admin/admin@inst2 --diskgroup=/:BLOCK_POOL

RECOVERY APPLIANCE CONTAINER FILE ALLOCATION TEST

Disk Group: /:BLOCK_POOL

2048 MB, 6.24s allocation time, 3.69s CPU time, 328.34 MB allocated per second, 59.09% CPU usage

PL/SQL procedure successfully completed.

10.4.2 ネットワーク・スループットのテスト

アプライアンスに付属しているnetwork_throughput_test.shスクリプトを使用すると、リカバリ・アプライアンス環境における理論上のネットワーク・スループットを測定できます。

ユーティリティの詳細と使用方法については、My Oracle SupportノートのドキュメントID 2022086.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=2022086.1)を参照してください。

11 リカバリ・アプライアンス・レポートへのアクセス

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)で事前に作成されたOracle Business Intelligence (BI) Publisherレポートにアクセスする方法について説明します。Cloud Controで保護されたデータベースのバックアップ・レポート・ページにアクセスする方法については、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

この章の内容は次のとおりです。

- リカバリ・アプライアンス・レポートについて

- 記憶域容量レポートへのアクセス

- リカバリ・ウィンドウ・サマリー・レポートへのアクセス

- 保護されたデータベースの詳細レポートへのアクセス

- 保護されたデータベースのデータ転送レポートへのアクセス

11.1 リカバリ・アプライアンス・レポートについて

この項には次のトピックが含まれます:

- リカバリ・アプライアンス・レポートの目的

- リカバリ・アプライアンス・レポートの概要

- Cloud Controlでのリカバリ・アプライアンス・レポート・ページへのアクセス

- リカバリ・アプライアンス・レポートにアクセスするための基本的なタスク

関連項目:

アーキテクチャの概要については、「保護ポリシー」を参照してください

11.1.1 リカバリ・アプライアンス・レポートの目的

リカバリ・アプライアンス管理者の主なタスクは、記憶域容量計画です。リカバリ・アプライアンスは、次の目標を達成するために事前作成されたBI PublisherレポートをBI Publisherを介して提供します。

- リカバリ・アプライアンスに、ニーズを満たすための十分な記憶域領域を確保します
容量レポートを使用することで、追加の記憶域を計画し、リカバリ・アプライアンスに追加する新しい保護されたデータベースの数を削減したり、保護ポリシーを調整してリカバリ・ウィンドウ領域の合計を減らすことができます。

- ネットワークが過負荷でないことを保証します
容量レポートは、リカバリ・アプライアンスがネットワーク容量を最大限に活用しているかどうかも示します。場合によっては、1日を通してネットワーク・トラフィックをより均等に再分散することで、ネットワーク負荷を減らすことができます。ネットワーク・トラフィックが分散されておらず、ネットワーク・ピークがネットワーク帯域幅をほぼ最大限に活用している場合、一部の保護されたデータベースのバックアップ・ウィンドウ時間の調整が必要になる可能性があります。

- システム・パフォーマンスおよびサービス・リクエストに対するアクティビティの適切なビューを提供します

- 任意の保護されたデータベースの簡潔なまたは非常に詳細なステータス・レポートを取得します。これらは、リカバリ・ウィンドウ目標を達成したいないデータベースのトラブルシューティングに役立つことがあります

11.1.2 リカバリ・アプライアンス・レポートの概要

BI Publisherは、レポートおよびその他のドキュメントを作成、管理および配布するためのエンタープライズ・レポート・ソリューションです。

11.1.2.1 事前作成されたBI Publisherレポート

リカバリ・アプライアンスには、事前作成された次のBI Publisherレポートが用意されています。

- 容量計画サマリー
このレポートではリカバリ・アプライアンスの記憶域の概要を示し、容量が使い尽くされる時期を予測できるようにします。特に便利なのがサマリー表で、容量を超過するまでの日数のクイック・ビューが示されます。ネットワーク容量計画サマリーでは、様々な期間にわたるネットワーク・トラフィック合計のビューを提供します。このビューには、ネットワーク・サンプルに基づく平均レートと最大レートの両方が表示されます。

- 容量計画詳細
このレポートは、容量計画のより詳細な情報を提供します。記憶域容量、ネットワーク・スループット、保護されたデータベース・ホストそれぞれのCPU使用率、一定期間におけるディスクおよびフラッシュ・ストレージのI/Oスループットについての情報を提供します。容量計画サマリーとは異なり、詳細レポートにはメモリーおよびIOPSサマリー情報や詳細な日次データも表示されます。

- リカバリ・ウィンドウ・サマリー
このレポートは、リカバリ・ウィンドウ目標を達成していない、または保護されていないウィンドウのしきい値を超えている保護されたデータベースのリストを示します(「CREATE_PROTECTION_POLICY」のunprotected_windowを参照)。このレポートをリカバリ・アプライアンスのリカバリ・ウィンドウおよび保護されていないデータ・ウィンドウに関する問題のクイック・ビューとして使用し、保護されたデータベースの詳細レポートを使用して保護されたデータベースを個別にフォローアップすることができます。

- 保護されたデータベースの詳細
このレポートには、次のサマリーを含め、保護されたデータベースについての広範なステータス情報が含まれます。

- 保護ポリシー

- リカバリ・アプライアンスの記憶域の場所

- ディスク・リカバリ・ウィンドウ目標

- 予約済領域。これは、データベースがディスク・リカバリ・ウィンドウ目標を達成するために予約されている、リカバリ・アプライアンスのディスク領域の最小量です。

- データ損失を排除するリアルタイムREDOトランスポートのステータス。

- バックアップ操作、copy-to-tape操作およびリカバリ・アプライアンス・レプリケーション操作のために一定期間にわたって送受信されたデータ。これらにより、保護されたデータベースとリカバリ・アプライアンスとの間のトラフィックの概要を把握できます。

- データ転送別上位10の保護されたデータベース
このレポートでは、リカバリ・アプライアンスとの間で転送されたバックアップ・データの量に従って、上位10の保護されたデータベースをランク付けします。このレポートでは、毎時または毎日データを集計します。特に、このレポートでは次の量を測定します。

- リカバリ・アプライアンスに送信されたバックアップ・データ

- リカバリ・アプライアンスによって送信されたレプリケーション・データ

- リカバリ・アプライアンスによって送信されたCopy-to-tapeデータ

このレポートは、ランク付けされたデータベースのバックアップによって使用されている領域の量と直接は関係ありません。

前述のレポートには、BI publisherを介してのみアクセスできます。また、Cloud Controlに付属するBI Publisherソフトウェアは、Enterprise Managerリポジトリ内のデータにのみアクセス可能で、リカバリ・アプライアンス・スキーマのデータにはアクセスできません。

注意:

パフォーマンス・データにはV$のSQL問合せおよびリカバリ・カタログ・ビューを介してアクセスできますが、BI Publisherレポートを使用することを強くお薦めします。リカバリ・アプライアンスのCPUおよびその他のリソースには限りがあるため、頻繁にまたは負荷の高いSQL問合せを実行すると、リカバリ・アプライアンスの全体的なパフォーマンスが低下することがあります。

関連項目:

- すべてのリカバリ・アプライアンス・ビューの完全なリストについては、「リカバリ・アプライアンスのビュー・リファレンス」を参照してください

- Oracle Enterprise Managerライセンス情報

11.1.2.2 BI Publisherレポートのスケジューリング

規則的なスケジュール(毎週など)で自動的にレポートを生成するようBI Publisherを構成し、バックアップ管理チームに電子メールでレポートを送信することをお薦めします。この章に説明されている技法を使用して、必要に応じてレポートを生成することもできます。

関連項目:

BI Publisherを使用してレポートをスケジュールする方法については、『Oracle Fusion Middleware Oracle Business Intelligence Publisherユーザーズ・ガイド』を参照してください。

11.1.3 Cloud Controlでのリカバリ・アプライアンス・レポート・ページへのアクセス

この項では、事前作成されたすべてのBI Publisherレポートにリンクしているリカバリ・アプライアンス・レポート・ページにアクセスする方法について説明します。

リカバリ・アプライアンス・レポート・ページにアクセスするには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

2. 「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。
BI Publisher Enterpriseレポート・ページが表示されます。

3. Enterprise Manager Cloud Controlフォルダ、リカバリ・アプライアンス・レポート・サブフォルダの順に展開します。
事前作成されているレポートへのリンクが表示されます。

関連項目:

BI Publisherでレポートを表示する方法については、Cloud Controlオンライン・ヘルプを参照してください。

11.1.4 リカバリ・アプライアンス・レポートにアクセスするための基本的なタスク

この項では、レポートの管理に関する基本的なタスクについて説明します。図11-1は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、レポート・タスクを強調して示したものです。

図11-1 リカバリ・アプライアンス・ワークフローでのレポート・タスク

通常、レポート・タスクを実行する順序は次のとおりです。

1. 計画フェーズでは、Cloud Controlを介して使用できるモニタリング・ツールとレポート・ツールについての理解を深めます。
「リカバリ・アプライアンスの計画」でこれらのタスクを説明しています。

2. 進行中のメンテナンス・フェーズでは(「Recovery Applianceのメンテナンス・タスク」を参照)、必要に応じてレポートをレビューします。一般的なタスクには次のものがあります。

- 容量計画詳細を使用して記憶域容量計画サマリーを毎週レビューし、詳細情報を取得します。
このタスクについては、「記憶域容量レポートへのアクセス」に説明されています。

- 必要に応じて、保護されたデータベース・レポートをレビューします。

- このタスクについては、「リカバリ・ウィンドウ・サマリー・レポートへのアクセス」に説明されています。

- このタスクについては、「リカバリ・アプライアンス・レポート・ページからの保護された詳細レポートへのアクセス」に説明されています。

- このタスクについては、「保護されたデータベースのデータ転送レポートへのアクセス」に説明されています。

11.2 記憶域容量レポートへのアクセス

このチュートリアルでは、リカバリ・アプライアンスの記憶域容量レポートを表示する方法について説明します。

前提条件

リカバリ・アプライアンス環境において、次の文がtrueであると想定します。

- 2週間以上前に、ZDLRA Londonという名前のリカバリ・アプライアンスが設定されました。

- 20の保護されたデータベースをZDLRA Londonにバックアップします。

記憶域容量についてのレポートをレビューするには:

1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。

2. 容量計画サマリーをクリックします。
BI Publisher Enterpriseのページが表示されます。

3. BI Publisherの資格証明を入力して、「サインイン」をクリックします。
容量計画サマリー・ページが表示されます。

4. 「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。
たとえば、ZDLRA Londonを選択します。

5. 「記憶域容量計画サマリー」セクションをレビューして、記憶域増加率および容量を超過するまでの日数を特定します。
たとえば、次の図はZDLRA Londonのサマリーを示しています。

主要なメトリックは、容量を超過するまでの日数の6.85です。1週間以内に、リカバリ・アプライアンスは保護ポリシーの設定に応じて、バックアップをパージするか受信バックアップを拒否します(「コピーの保証」を参照)。

6. 履歴記憶域トレンドを表示します。
たとえば、先週のトレンドを確認します。

前述のチャートは、過去2日間にわたって、すべての保護されたデータベースのリカバリ・ウィンドウ目標を満たすために必要な領域合計が5.2TBから21TBに増加したことを示しています。保護されたデータベースの数は20で安定しています。

7. ネットワーク容量計画サマリーで、ネットワーク・スループットを確認します。
たとえば、先週のネットワーク・スループットを確認します。

前述のチャートは、過去2日間、受信速度が急激に上昇していることを示しています。

ネットワーク容量計画サマリーでは、様々な期間(24時間、7日、30日)にわたるネットワーク・トラフィック合計のビューを提供します。

8. 事前作成されたレポートのページに戻ります。

9. 容量計画詳細をクリックします。
リカバリ・アプライアンス: 容量計画 - 詳細ページが表示されます。

このレポートは、容量計画サマリーよりも詳細な情報を提供します。容量計画レポートとは異なり、詳細レポートにはメモリーおよびIOPS情報も表示されます。

10. 必要なリカバリ・アプライアンスが「リカバリ・アプライアンス」でまだ選択されていない場合は、選択して「適用」をクリックします。

11. レポートの冒頭で「記憶域容量計画詳細」をクリックして、このセクションにジャンプします。

12. 「IO履歴データ」セクションの「セル・ディスクIO」サブセクションにスクロール・ダウンします。
たとえば、次の表に記憶域サーバーごとの15分間隔でのIOPSおよびスループットを示します。

11.3 リカバリ・ウィンドウ・サマリー・レポートへのアクセス

このチュートリアルでは、リカバリ・アプライアンスで保護されているデータベースのリカバリ・ウィンドウ・サマリーを表示する方法について説明します。

前提条件

環境において、次の文がtrueであると想定します。

- ZDLRA Montrealという名前のリカバリ・アプライアンスは、13のデータベースを保護します。

- リカバリ・ウィンドウを満たしていないデータベースがあるかどうかを特定したいと考えています。

リカバリ・ウィンドウ・サマリー・レポートをレビューするには:

1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。

2. 「リカバリ・ウィンドウ・サマリー」をクリックします。
リカバリ・アプライアンス: リカバリ・ウィンドウ・サマリー・ページが表示されます。

3. BI Publisherの資格証明を入力して、「サインイン」をクリックします。
リカバリ・アプライアンス: リカバリ・ウィンドウ・サマリー・ページが表示されます。

4. 「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。
たとえば、ZDLRA Montrealを選択します。

ページがリフレッシュされ、次の例のように上部にサマリーが表示されます。

円グラフは、75%を超えるデータベースがサービス・レベル合意を満たしていないことを示しています。表は、合計13のデータベースのうち、3つのデータベースがリカバリ・ウィンドウ目標を満たしていないことを示しています。また、8つのデータベースが、保護されていないデータしきい値内に入っていません。

5. チャートを下にスクロールすると、リカバリ・ウィンドウ目標を満たしていないデータベースが表示されます。
次の例で、2つのサンプル・レポートを示します。

前述の例は、データベースDB1116とDB1123の両方ともリカバリ・ウィンドウ目標は1日であるが、この目標に何時間も達していないリカバリ・ウィンドウがあることを示しています。DB11242の目標も1日ですが、実際のリカバリ・ウィンドウは1時間未満です。

11.4 保護されたデータベースの詳細レポートへのアクセス

保護されたデータベースの詳細レポートには、リカバリ・アプライアンス・レポート・ページまたは保護されたデータベース・ページからアクセスできます。

11.4.1 保護されたデータベース・ページからの詳細レポートへのアクセス

このアクセス・パスは、「エンタープライズ」メニューを使用してリカバリ・アプライアンス・レポート・ページに移動する代わりの方法です。

保護されたデータベースの詳細ページにアクセスするには:

1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。
たとえば、ZDLRA Montrealのホームページにアクセスします。

2. 「リカバリ・アプライアンス」メニューから、「保護されたデータベース」を選択します。
保護されたデータベース・ページが表示されます。

3. 「保護されたデータベース」表でデータベースを選択します。
たとえば、DB1124を選択します。

ページの下部で、「保護されたデータベースの詳細」セクションがリフレッシュされます。

4. 「保護されたデータベースの詳細」セクションで「ステータス」選択します。
次の例に示すように、「ステータス」サブページが表示されます。

5. 「保護されたデータベースのレポート」をクリックします。
BI Publisherページが表示されます。

6. BI Publisherの資格証明を入力して、「サインイン」をクリックします。
リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます(「リカバリ・アプライアンス・レポート・ページからの保護された詳細レポートへのアクセス」の手順4を参照)。

11.4.2 リカバリ・アプライアンス・レポート・ページからの保護された詳細レポートへのアクセス

このチュートリアルでは、保護されたデータベースの詳細レポートにアクセスする方法について説明します。

前提条件

ZDLRA Philadelphiaという名前のリカバリ・アプライアンスは、12のデータベースを保護するとします。

保護されたデータベースについてのレポートをレビューするには:

1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。

2. 「保護されたデータベースの詳細」をクリックします。
リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます。

注意:

「保護されたデータベース・ページからの詳細レポートへのアクセス」に説明されているように、このレポートには保護されたデータベース・ページから直接アクセスすることもできます。

3. 「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択します。
たとえば、ZDLRA Montrealを選択します。

4. 「保護されたデータベース」でデータベースを選択し、「適用」をクリックします。

たとえば、DB1124を選択します。

リカバリ・アプライアンス: 保護されたデータベースの詳細ページが表示されます。

5. 「バックアップ/リカバリ」セクションにスクロール・ダウンします。
たとえば、次の図にDB1124データベースの統計値を示します。

前の統計は、データベースがリカバリ・ウィンドウ目標を達成するには182.83GBが必要なことを示しています。

6. バックアップ履歴を確認します。
たとえば、次のチャートは、先週DB1124によって送受信されたデータを示しています。

前のチャートは、日次バックアップ・データが8/25 (この日は305.1GB)を除いて毎日31～49GBであったことを示しています。毎日、送信されたレプリケーション・データ量は受信したバックアップ・データよりも若干少ない量でした。

7. 必要なだけ前述の2つの手順を繰り返して、すべての保護されたデータベースのバックアップ・アクティビティを調査します。

11.5 保護されたデータベースのデータ転送レポートへのアクセス

このチュートリアルでは、リカバリ・アプライアンスのデータ転送レポートを表示する方法について説明します。

前提条件

環境において、次の文がtrueであると想定します。

- ZDLRA Montrealという名前のリカバリ・アプライアンスは、10のデータベースを保護します。

- リカバリ・アプライアンスは一部のデータベースについては、バックアップをレプリケートしますがテープにはアーカイブしません。

- 過去1週間にわたって最もデータを転送したデータベースを特定したいと考えています。

データ転送レポートをレビューするには:

1. 「Cloud Controlでのリカバリ・アプライアンス・レポートへのアクセス」に説明されているとおりに、事前に作成されたレポートのページに移動します。

2. データ転送別上位10の保護されたデータベースをクリックします。
BI Publisher Enterpriseのページが表示されます。

3. BI Publisherの資格証明を入力して、「サインイン」をクリックします。
データ転送別上位10の保護されたデータベース・ページが表示されます。

4. 「リカバリ・アプライアンス」でリカバリ・アプライアンスを選択し、「適用」をクリックします。
たとえば、ZDLRA Montrealを選択します。

5. 「バックアップ・データ別上位10のデータベース」をクリックします。
「バックアップ・データ」セクションが表示されます。

6. 「過去7日間(日ごとに集計)」セクションにスクロール・ダウンします。
たとえば、09/08から09/15の期間のデータは次のとおりです。

前のチャートによると、データベースDB12CDBはほとんどのデータを毎日バックアップしました。ピーク転送は09/09で、約1.25TBでした。

7. レポートの上部に戻って「レプリケーション・データ別上位10のデータベース」をクリックします。
「レプリケーション・データ」セクションが表示されます。

8. 「過去7日間(日ごとに集計)」セクションにスクロール・ダウンします。
たとえば、09/08から09/15の期間のデータは次のとおりです。

前のチャートによると、データベースDB12CDBはほとんどのデータを毎日レプリケートしました。ピーク転送は09/11で、約1.7TBでした。

第II部 リカバリ・アプライアンスのリファレンス

第II部は、次の章で構成されています。

- DBMS_RAパッケージのリファレンス

- リカバリ・アプライアンスのビュー・リファレンス

- rastatユーティリティのリファレンス

- リカバリ・アプライアンスのエラー・メッセージ・リファレンス

12 DBMS_RAパッケージのリファレンス

この章では、DBMS_RA PL/SQLパッケージについて詳しく説明します。リカバリ・アプライアンスの管理機能はすべて、DBMS_RAサブプログラムを使用して実行します。

一時に1つのDBMS_RAプロシージャを実行できます。ABORT_RECOVERY_APPLIANCEを除いて、同時に異なるセッションで複数のDBMS_RAプロシージャを実行しようとすると、該当するメッセージが表示されて失敗します。

表12-1に、使用可能なDBMS_RAサブプログラムをまとめます。

表12-1 DBMS_RAパッケージのサブプログラム

サブプログラム

説明

ABORT

ABORT_RECOVERY_APPLIANCEと同義です。

ABORT_RECOVERY_APPLIANCE

このプロシージャは、進行中の操作が完了するのを待機せずにリカバリ・アプライアンスを停止します。

ADD_DB

このプロシージャは、指定されたデータベースをリカバリ・アプライアンスに追加し、保護ポリシーをそのデータベースに割り当てます。このプロシージャを使用すると、保護されていないデータベースを保護されたデータベースの状態にすることができます。

ADD_REPLICATION_SERVER

このプロシージャは、指定されたレプリケーション･サーバー構成を指定された保護ポリシーに追加します。操作が成功すると、このポリシーで保護されるデータベースのバックアップがダウンストリーム・リカバリ・アプライアンスにレプリケートされます。

CONFIG

このプロシージャは、config表の値を更新します。

COPY_BACKUP

このプロシージャは、リカバリ・アプライアンスからユーザー指定のSBT宛先に1つ以上のバックアップ・ピースをコピーします。指定したタグとformatパラメータおよびtemplate_nameパラメータで指定した場所が一致するバックアップ・ピースがすべてコピーされます。

COPY_BACKUP_PIECE

このプロシージャは、リカバリ・アプライアンスからユーザー指定のSBT宛先に単一のバックアップ・ピースをコピーします。

CREATE_POLLING_POLICY

このプロシージャは、バックアップのポーリング・ポリシーを作成します。

CREATE_PROTECTION_POLICY

このプロシージャは、保護ポリシーを作成します。

CREATE_REPLICATION_SERVER

このプロシージャは、リカバリ・アプライアンスのレプリケーション・スキームの一部を形成するダウンストリーム・リカバリ・アプライアンスの構成を定義します。

CREATE_SBT_ATTRIBUTE_SET

このプロシージャは、SBTジョブで使用できるSBT属性セットを作成します。

CREATE_SBT_JOB_TEMPLATE

このプロシージャは、テープへのコピー対象となるバックアップの選択方法を記述するSBTジョブを作成します。この過負荷プロシージャのこの形式は、指定された保護ポリシーに割り当てられた保護されたデータベースすべてに対するバックアップに適用されます。

CREATE_SBT_JOB_TEMPLATE

このプロシージャは、新しいSBTバックアップ・ジョブを作成します。ジョブでは、テープへのコピー対象となるバックアップの選択方法を記述します。この過負荷プロシージャのこの形式は、単一の保護されたデータベースに対するバックアップにのみ適用されますが、前述の形式は特定の保護ポリシーに割り当てられたデータベースすべてに対するバックアップに適用されます。この相違を除いて、このプロシージャとそのパラメータは、このプロシージャの代替形式とまったく同じです。

CREATE_SBT_LIBRARY

このプロシージャは、インストールされたメディア管理ソフトウェア・ライブラリを記述するメタデータを作成します。リカバリ・アプライアンスでは、指定されたライブラリを使用して、内部記憶域からテープまたはこのメディア・マネージャでサポートされる他の3次記憶域にバックアップがコピーされます。

CREATE_STORAGE_LOCATION

このプロシージャは、リカバリ・アプライアンスで使用される記憶域を記述するオブジェクトである、リカバリ・アプライアンスの記憶域の場所を作成します。名前が付けられた記憶域の場所にバックアップがすべて格納されます。

DELETE_DB

このプロシージャは、リカバリ・アプライアンスから指定の保護されたデータベースを削除します。ディスクとSBTの両方から、このデータベースに関連するメタデータおよびバックアップがすべて削除されます。

DELETE_POLLING_POLICY

このプロシージャは、指定されたバックアップのポーリング・ポリシーを削除します。

DELETE_PROTECTION_POLICY

このプロシージャは、指定された保護ポリシーを削除します。

DELETE_REPLICATION_SERVER

このプロシージャは、レプリケーション・サーバー構成を削除します。ダウンストリーム・リカバリ・アプライアンスに関連するメタデータがすべて削除されます。

DELETE_SBT_ATTRIBUTE_SET

このプロシージャは、指定されたSBT属性セットを削除します。

DELETE_SBT_JOB_TEMPLATE

このプロシージャは、指定されたSBTジョブ・テンプレートを削除します。

DELETE_SBT_LIBRARY

このプロシージャは、指定されたSBTライブラリを記述しているメタデータを削除します。

DELETE_STORAGE_LOCATION

このプロシージャは、指定されたリカバリ・アプライアンスの記憶域の場所を削除します。

GRANT_DB_ACCESS

このプロシージャは、指定されたリカバリ・アプライアンス・ユーザー・アカウントに必要な権限を付与し、そのアカウントが指定の保護されたデータベースに関するリカバリ・カタログ・メタデータのバックアップ、リストアおよびアクセスをできるようにします。

MIGRATE_TAPE_BACKUP

このプロシージャは、指定されたSBTライブラリを介してリカバリ・アプライアンスで移行前のテープ・バックアップをアクセスできるようにします。先に、RMAN IMPORT CATALOGコマンドを使用してリカバリ・アプライアンス・カタログにテープ・バックアップに関するメタデータをインポートする必要があります。

MOVE_BACKUP

このプロシージャは、リカバリ・アプライアンスからユーザー指定のSBT宛先に1つ以上の長期アーカイブ・バックアップ・ピースを移動します。

MOVE_BACKUP_PIECE

このプロシージャは、リカバリ・アプライアンスからユーザー指定のSBT宛先に単一の長期アーカイブ・バックアップ・ピースを移動します。

PAUSE_REPLICATION_SERVER

このプロシージャは、指定されたダウンストリーム・リカバリ・アプライアンスへのレプリケーションを一時停止します。

PAUSE_SBT_LIBRARY

このプロシージャは、指定されたSBTライブラリを一時停止します。リカバリ・アプライアンスでは、進行中のバックアップ・ピースのコピーを完了できます。ただし、このSBTライブラリを介したコピー対象のバックアップ・ピースがキューに入れられて、まだコピーされていない場合は、このSBTライブラリを再開するまでそのバックアップ・ピースは保持されます。このライブラリに対して実行される新しいSBTジョブは、ライブラリを再開(RESUME_SBT_LIBRARY)するまで実行できません。

POPULATE_BACKUP_PIECE

このプロシージャは、指定されたバックアップ・ピースをデルタ・ストアにプッシュします。

QUEUE_SBT_BACKUP_TASK

このプロシージャは、指定されたSBTジョブ・テンプレートでテープへのコピー対象に選択されたバックアップ・ピースをキューに入れます。通常、このプロシージャはOracle Schedulerなどのスケジューリング・ユーティリティによってコールされます。

REMOVE_REPLICATION_SERVER

このプロシージャは、指定されたレプリケーション･サーバー構成を指定された保護ポリシーから削除します。操作が成功すると、このポリシーで保護されるデータベースのバックアップがダウンストリーム・リカバリ・アプライアンスにレプリケートされなくなります。

RENAME_DB

このプロシージャは、リカバリ・アプライアンス・メタデータで指定の保護されたデータベースの名前を変更します。

RESET_ERROR

このプロシージャは、指定されたエラー・ログ・エントリのステータスをRESETに変更します。この方式でマークされたエラーによってOracle Enterprise Managerでアラートが発生することはありません。リカバリ・アプライアンスによって問題が依然として発生していると判断されると、リセットされたエラーがACTIVEステータスに変ります。このAPIの主な用途は、一時的なメディア障害などの繰り返し発生しないエラーに対するエラー・ステータスをリセットすることです。

RESUME_REPLICATION_SERVER

このプロシージャは、前のPAUSE_REPLICATION_SERVERのコール後に、指定されたダウンストリーム・リカバリ・アプライアンスへのレプリケーションを再開します。

RESUME_SBT_LIBRARY

このプロシージャは、一時停止しているSBTライブラリを再開します。

REVOKE_DB_ACCESS

このプロシージャは、指定されたリカバリ・アプライアンス・ユーザー・アカウントから単一の保護されたデータベースに対する権限を取り消します。

SHUTDOWN

SHUTDOWN_RECOVERY_APPLIANCEと同義です。

SHUTDOWN_RECOVERY_APPLIANCE

このプロシージャは、リカバリ・アプライアンスの正しい停止を実行します。

STARTUP

STARTUP_RECOVERY_APPLIANCEと同義です。

STARTUP_RECOVERY_APPLIANCE

このプロシージャは、停止または終了した後のリカバリ・アプライアンスを起動します。

UPDATE_DB

このプロシージャは、指定の保護されたデータベースに割り当てられている属性を変更します。

UPDATE_POLLING_POLICY

このプロシージャは、既存のバックアップのポーリング・ポリシーのパラメータを変更します。

UPDATE_PROTECTION_POLICY

このプロシージャは、既存の保護ポリシーのパラメータを変更します。

UPDATE_REPLICATION_SERVER

このプロシージャは、レプリケーション・サーバー構成の設定を変更します。

UPDATE_SBT_ATTRIBUTE_SET

このプロシージャは、指定されたSBT属性セットのパラメータを更新します。

UPDATE_SBT_JOB_TEMPLATE

このプロシージャは、指定されたSBTジョブのパラメータを更新します。

UPDATE_SBT_LIBRARY

このプロシージャは、指定されたSBTライブラリのパラメータを変更します。

UPDATE_STORAGE_LOCATION

このプロシージャは、指定された記憶域の場所に追加領域を割り当てます。記憶域の場所で使用される領域の容量を減らすことはできません。

12.1 ABORT

ABORT_RECOVERY_APPLIANCEと同義です。

構文

PROCEDURE abort;

12.2 ABORT_RECOVERY_APPLIANCE

このプロシージャは、進行中の操作が完了するのを待機せずにリカバリ・アプライアンスを停止します。

このプロシージャを使用すると、リカバリ・アプライアンスにより、開始していて完了していないバックアップ操作、リストア操作およびバックグラウンド操作(検証ジョブ、データ移動ジョブ、テープへのコピー・ジョブなど)が終了します。リカバリ・アプライアンスを再起動すると、バックアップ操作は自動的に再開(再起動)されます。終了したバックアップ操作およびリストア操作は手動で再開する必要があります。正しい停止を実行するには、SHUTDOWN_RECOVERY_APPLIANCEを使用します。

構文

PROCEDURE abort_recovery_appliance;

12.3 ADD_DB

このプロシージャは、指定されたデータベースをリカバリ・アプライアンスに追加し、保護ポリシーをそのデータベースに割り当てます。このプロシージャを使用すると、保護されていないデータベースを保護されたデータベースの状態にすることができます。

リカバリ・アプライアンスにデータベースを登録するには、ADD_DBを使用して保護されたデータベースを追加し、このデータベースへのアクセス権をリカバリ・アプライアンス・ユーザー・アカウントに付与(GRANT_DB_ACCESS)して、仮想プライベート・カタログにこのデータベースを登録する(RMAN REGISTER DATABASEコマンド)必要があります。リカバリ・アプライアンスでバックアップ操作およびリストア操作を処理するには、保護されたデータベースを登録する必要があります。

このプロシージャは、フィジカル・スタンバイ構成でのデータベースの追加には使用できません。このようなデータベースは、リカバリ・カタログの再同期化を実行すると、自動的に認識されます。

構文

PROCEDURE add_db (
db_unique_name IN VARCHAR2,
protection_policy_name IN VARCHAR2,
reserved_space IN VARCHAR2);

パラメータ

表12-2 ADD_DBのパラメータ

パラメータ

説明

db_unique_name

追加するデータベースのDB_UNIQUE_NAME。

protection_policy_name

データベースに割り当てる保護ポリシーの名前。保護ポリシーは存在する必要があります。

reserved_space

保護されたデータベースに使用できることが保証されるディスク領域の容量。

この値の形式は、0-9のみで構成される数字の後に、必要に応じて次の単位指定子のいずれかを付けた文字列です。

K: キロバイト

M: メガバイト

G: ギガバイト

T: テラバイト

P: ペタバイト

E: エクサバイト

Z: ゼッタバイト

Y: ヨタバイト

単位を指定しないと、値はバイト数として解釈されます。

12.4 ADD_REPLICATION_SERVER

このプロシージャは、指定されたレプリケーション･サーバー構成を指定された保護ポリシーに追加します。操作が成功すると、このポリシーで保護されるデータベースのバックアップがダウンストリーム・リカバリ・アプライアンスにレプリケートされます。

「CREATE_REPLICATION_SERVER」を参照してください。

構文

PROCEDURE add_replication_server (
replication_server_name IN VARCHAR2,
protection_policy_name IN VARCHAR2);

パラメータ

表12-3 ADD_REPLICATION_SERVERのパラメータ

パラメータ

説明

replication_server_name

保護ポリシーに関連付けるレプリケーション・サーバー構成の名前。

protection_policy_name

レプリケーション・サーバー構成に関連付ける保護ポリシーの名前。

12.5 CONFIG

このプロシージャは、config表の値を更新します。

構文

PROCEDURE config(
p_name VARCHAR2,
p_value VARCHAR2);

パラメータ

表12-4 CONFIGのパラメータ

パラメータ

説明

p_name

更新するパラメータ。使用可能なパラメータは、次のとおりです。

- check_file_days
Recovery Applianceがメタデータの一貫性チェックをバックグラウンドで実行する頻度。デフォルトの頻度は14日です。

- crosscheck_db_days
Recovery Applianceがテープ・ライブラリまたはダウンストリームRecovery Applianceにアクションを反映するためにリカバリ・カタログの更新をバックグラウンドで実行する頻度。例として、バックアップ・ピースの削除があげられます。デフォルトの頻度は1日です。

- optimize_chunks_days
Recovery Applianceがリストア操作に必要なディスク読取り回数を削減するためにデルタ・ストア内のブロックの並替えをバックグラウンドで実行する頻度。デフォルトの頻度は7日です。

- validate_db_days
Recovery Applianceがバックアップ・ピースの検証をバックグラウンドで実行する頻度。デフォルトの頻度は14日です。

- percent_late_for_warning
Recovery Applianceが不完全なバックグラウンド操作に関する警告を転送する割合のしきい値。たとえば、validate_db_daysが7、percent_late_for_warningが50である場合、Recovery Applianceは、データベースが検証されずに10.5 (つまり、7 + ((50/100)*7))日経過したときに警告をインシデント・ログに記録します。デフォルトは50パーセントです。

- network_chunksize
Recovery ApplianceがRecovery Appliance自体と保護されたデータベース間でのバックアップの転送に使用するメッセージ・サイズ。デフォルトは128MBです。

この値は、バックアップを送信するか読み取る単位サイズを決定するために、保護されたデータベースすべてで使用されます。たとえば、保護されたデータベースのバックアップが1TBである場合、SBTライブラリは、バックアップ・データをnetwork_chunksizeの単位でRecovery Applianceに送信します。障害が発生した際にRecovery Applianceをよりすばやく再起動するには、この手法が最適です。

p_value

パラメータの新しい値。

12.6 COPY_BACKUP

このプロシージャは、リカバリ・アプライアンスからユーザー指定のSBT宛先に1つ以上のバックアップ・ピースをコピーします。指定したタグとformatパラメータおよびtemplate_nameパラメータで指定した場所が一致するバックアップ・ピースがすべてコピーされます。

構文

PROCEDURE copy_backup (
tag IN VARCHAR2,
format IN VARCHAR2,
template_name IN VARCHAR2'
compression_algorithm IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-5 COPY_BACKUPのパラメータ

パラメータ

説明

tag

コピーするバックアップのタグ。リカバリ・アプライアンスにより、このタグと一致するバックアップがすべてコピーされます。

format

作成するバックアップ・ピースのネーミング形式。このパラメータは、RMAN FORMATパラメータと同じルールに従います。

template_name

メディア管理ライブラリ・テンプレート。

リカバリ・アプライアンスにより、SBTテンプレート名で参照されるメディア・プールをコピー先として使用して、バックアップ・ピースがテープにコピーされます。

compression_algorithm

このバックアップのコピー操作に使用する圧縮アルゴリズム。次のいずれかを使用して、SBTジョブ・テンプレートに指定された圧縮アルゴリズムを上書きします。

BASIC: 優れた圧縮率であり、MEDIUMより低速になる可能性があります。

LOW: 速度に対して最適化されており、BASICより低い圧縮率になる可能性があります。

MEDIUM: ほとんどの環境に適しています。圧縮率と速度の優れた組合せが得られます。

HIGH: 制限要素が最大テープ・スループットである低速なネットワークでの操作に最も適しています。

OFF: 圧縮しません。

NULL (デフォルト)は、SBTジョブ・テンプレートに定義されているアルゴリズムを使用する必要があることを示します。

LOW、MEDIUMおよびHIGHは、保護されたデータベースでのリストア操作に対する追加のライセンスが必要なAdvanced Compressionオプションです。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

12.7 COPY_BACKUP_PIECE

このプロシージャは、リカバリ・アプライアンスからユーザー指定のディスクまたはSBT宛先に単一のバックアップ・ピースをコピーします。

構文

PROCEDURE copy_backup_piece (
bp_key IN NUMBER,
format IN VARCHAR2,
template_name IN VARCHAR2,
compression_algorithm IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-6 COPY_BACKUP_PIECEのパラメータ

パラメータ

説明

bp_key

コピーするバックアップ・ピースの一意キー。このキーはRC_BACKUP_PIECEビューから取得します。

format

作成するバックアップ・ピースのネーミング形式。このパラメータは、RMAN FORMATパラメータと同じルールに従います。

template_name

メディア管理ライブラリ・テンプレート。

リカバリ・アプライアンスにより、SBTテンプレート名で参照されるメディア・プールをコピー先として使用して、バックアップ・ピースがテープにコピーされます。

compression_algorithm

このバックアップのコピー操作に使用する圧縮アルゴリズム。次のいずれかを使用して、SBTジョブ・テンプレートに指定された圧縮アルゴリズムを上書きします。

BASIC: 優れた圧縮率であり、MEDIUMより低速になる可能性があります。

LOW: 速度に対して最適化されており、BASICより低い圧縮率になる可能性があります。

MEDIUM: ほとんどの環境に適しています。圧縮率と速度の優れた組合せが得られます。

HIGH: 制限要素が最大テープ・スループットである低速なネットワークでの操作に最も適しています。

OFF: 圧縮しません。

NULL (デフォルト)は、SBTジョブ・テンプレートに定義されているアルゴリズムを使用する必要があることを示します。

LOW、MEDIUMおよびHIGHは、保護されたデータベースでのリストア操作に対する追加のライセンスが必要なAdvanced Compressionオプションです。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

12.8 CREATE_POLLING_POLICY

このプロシージャは、バックアップのポーリング・ポリシーを作成します。

バックアップのポーリング・ポリシーでは、保護されたデータベースによって受信バックアップ・ファイルまたはアーカイブREDOログ・ファイルが格納されるディレクトリを指定します。また、ポーリング位置でバックアップがないか調べられる頻度も指定します。

ポーリングでファイルが検出されると、そのファイルは調査後に、その内容を使用してリカバリ・アプライアンスに登録されている保護されたデータベースに関連付けられます。登録済のどの保護されたデータベースにもファイルを関連付けられない場合は、警告メッセージがログに記録され、ファイルの処理は中止されます。

構文

PROCEDURE create_polling_policy(
polling_policy_name IN VARCHAR2,
polling_location IN VARCHAR2,
polling_frequency IN DSINTERVAL_UNCONSTRAINED DEFAULT NULL,
delete_input IN BOOLEAN DEFAULT FALSE);

パラメータ

表12-7 CREATE_POLLING_POLICYのパラメータ

パラメータ

説明

polling_policy_name

ポーリング・ポリシーのユーザーが割り当てた名前。

polling_location

新しいバックアップがないか定期的に調べられるディレクトリ。このディレクトリ名は、複数のポーリング・ポリシーに指定しないでください。

polling_frequency

新しいバックアップがないか指定されたディレクトリが調べられる頻度。システム・ロードにより、バックアップのポーリングがそれほど頻繁に発生しないことがあります。

INTERVAL '2' DAY (2日)、INTERVAL '4' HOUR (4時間)などのように、有効なINTERVAL DAY TO SECOND式でウィンドウを指定します。

delete_input

削除動作を制御する設定。TRUEの場合、指定されたディレクトリのファイルが記憶域の場所にコピーされた後に削除されます。FALSEの場合、ポーリング位置で検出されたファイルは削除されません。

12.9 CREATE_PROTECTION_POLICY

このプロシージャは、保護ポリシーを作成します。

構文

PROCEDURE create_protection_policy (
protection_policy_name IN VARCHAR2,
description IN VARCHAR2 DEFAULT NULL,
storage_location_name IN VARCHAR2,
polling_policy_name IN VARCHAR2 DEFAULT NULL,
recovery_window_goal IN DSINTERVAL_UNCONSTRAINED,
max_retention_window IN DSINTERVAL_UNCONSTRAINED DEFAULT NULL,
recovery_window_sbt IN DSINTERVAL_UNCONSTRAINED DEFAULT NULL,
unprotected_window IN DSINTERVAL_UNCONSTRAINED DEFAULT NULL,
guaranteed_copy IN VARCHAR2 DEFAULT 'NO',
allow_backup_deletion IN VARCHAR2 DEFAULT 'YES',
store_and_forward IN VARCHAR2 DEFAULT 'NO');

パラメータ

表12-8 CREATE_PROTECTION_POLICYのパラメータ

パラメータ

説明

protection_policy_name

保護ポリシーのユーザーが割り当てた名前。

description

ポリシーの使用法の説明(オプション)。

storage_location_name

保管場所の名前。リカバリ・アプリケーションでは、アクティブに受信された受信バックアップと、この保護ポリシーを共有するすべてのデータベースに対して新たに作成されたバックアップ・ファイルに、この場所が使用されます。

polling_policy_name

バックアップのポーリング・ポリシーの名前。ポーリング・ポリシーでは、この保護ポリシーを使用する保護されたデータベースのバックアップがポーリングされる方法のルールを指定します。nullの場合、この保護ポリシーを使用するデータベースに対してバックアップのポーリングが発生しません。

recovery_window_goal

この保護ポリシーを使用するデータベースのリカバリ・ウィンドウ目標。保護されたデータベースごとに、リカバリ・アプライアンスでは、現在の時間から遡って指定された間隔内の任意の時点までのポイント・イン・タイム・リカバリを、ディスクで最古のバックアップによってサポートできるようにしようとします。

INTERVAL '2' DAY (2日)、INTERVAL '4' HOUR (4時間)などのように、有効なINTERVAL DAY TO SECOND式で目標を指定します。

max_retention_window

この保護ポリシーを使用するデータベースのバックアップをリカバリ・アプライアンスで保持する必要がある最長時間。バックアップが指定の期間より長く保持されるのは、データベースのリカバリ・ウィンドウ目標の保存にそのバックアップが必要な場合のみです。nullの場合、明示的なユーザー・アクションまたは記憶域の場所内での領域不足によって引き起こされないかぎり、バックアップはパージされません。

recovery_window_sbt

この保護ポリシーを使用するデータベースのSBTバックアップのリカバリ・ウィンドウ。保護されたデータベースごとに、リカバリ・アプライアンスでは、現在の時間から遡って指定された間隔内の任意の時点までリカバリが可能であることを保証するのに十分な期間、バックアップがテープ上に保持されます。

このパラメータがnullでない場合、この保護ポリシー用のSBTジョブを作成し、Oracle Schedulerなどのスケジューリング機能を使用してそのジョブをスケジュールする必要もあります。「CREATE_SBT_JOB_TEMPLATE」を参照してください。

INTERVAL '2' DAY (2日)、INTERVAL '4' HOUR (4時間)などのように、有効なINTERVAL DAY TO SECOND式でウィンドウを指定します。

unprotected_window

この保護ポリシーを使用しているデータベースが許容できるデータ損失の最大量。保護されたデータベースが指定のデータ損失量を超えると、RA_INCIDENT_LOGに警告がポストされます。保護された各データベースのリカバリ可能限度である直近の時間がRA_RESTORE_RANGEのHIGH_TIME列に表示されます。

INTERVAL '2' DAY (2日)、INTERVAL '4' HOUR (4時間)などのように、有効なINTERVAL DAY TO SECOND式でウィンドウを指定します。

guaranteed_copy

保証付きコピー機能の設定。NOを指定すると、リカバリ・アプライアンスでは、容量が少ないときに古いバックアップの削除が必要な場合でも、常に新しいバックアップが受け入れられます。このオプションは、古いバックアップをリストアできることよりも、現在受信しているバックアップを正常に処理できることを優先します。

YESを指定すると、バックアップ・データはリカバリ・アプライアンスの記憶域から削除される前に、必ずレプリケートされるか、テープにコピーされます。このオプションは、現在受信しているバックアップを正常に処理できることよりも、古いバックアップをリストアできることを優先します。

YESに設定すると、保護されたデータベースごとに、リカバリ・アプライアンスでは、まだコピーまたはレプリケートされていないバックアップ・データの最大disk_reserve_spaceバイトまでしか保持できません。ハードウェア･エラーまたはネットワーク・エラーによって適切なタイミングでコピーまたはレプリケーションできない場合、disk_reserve_space制限に達すると、その後の新しいバックアップの作成は失敗します。

allow_backup_deletion

この保護ポリシーを使用するデータベースのRMANバックアップを削除できるかどうかを制御する設定です。NOを指定すると、リカバリ・アプライアンスではこれらのバックアップを削除できないことを意味します。デフォルトはYESです。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.7以上でのみ使用可能です。

store_and_forward

バックアップおよびREDOフェイルオーバー機能の設定です。この設定は、このポリシーに関連付けられた保護されたデータベースが、プライマリ・リカバリ・アプライアンスの停止時にバックアップおよびREDOをリダイレクトする代替リカバリ・アプライアンスで定義されている保護ポリシーでのみ使用されます。YESの指定は、代替リカバリ・アプライアンスがこれらのリダイレクトされたバックアップをインデックス化しないことを意味します。かわりに、バックアップはそのまま格納され、停止が終わったときにプライマリ・リカバリ・アプライアンスに送信されます。デフォルトはNOです。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

バックアップおよびREDOフェイルオーバーの機能の詳細は、「バックアップおよびREDOフェイルオーバー計画を使用した一時的な停止の管理」を参照してください。

12.10 CREATE_REPLICATION_SERVER

このプロシージャは、リカバリ・アプライアンスのレプリケーション・スキームの一部を形成するダウンストリーム・リカバリ・アプライアンスの構成を定義します。

このプロシージャは、ダウンストリーム・リカバリ・アプライアンスのメタデータを作成しますが、バックアップをレプリケートしません。ADD_REPLICATION_SERVERプロシージャを使用してダウンストリーム・リカバリ・アプライアンスと1つ以上の保護ポリシーをリンクするため、このようなポリシーに割り当てられた保護されたデータベースのバックアップはダウンストリーム・リカバリ・アプライアンスに送信されます。

構文

PROCEDURE create_replication_server (
replication_server_name IN VARCHAR2,
sbt_so_name IN VARCHAR2,
sbt_parms IN VARCHAR2 DEFAULT NULL,
max_streams IN NUMBER DEFAULT NULL,
catalog_user_name IN VARCHAR2,
wallet_alias IN VARCHAR2,
wallet_path IN VARCHAR2,
proxy_url IN VARCHAR2 DEFAULT NULL,
proxy_port IN NUMBER DEFAULT NULL,
http_timeout IN NUMBER DEFAULT NULL);

パラメータ

表12-9 CREATE_REPLICATION_SERVERのパラメータ

パラメータ

説明

replication_server_name

ダウンストリーム・リカバリ・アプライアンスのユーザーが割り当てた名前。

sbt_so_name

リカバリ・アプライアンス・バックアップ・モジュールの名前およびパス。このモジュールは、SBTデバイスをシミュレートするOracle提供のメディア・ライブラリです。リカバリ・アプライアンスでは、このライブラリを使用してダウンストリーム・リカバリ・アプライアンスと通信します。

sbt_parms

(RA_CLIENT_CONFIG_FILE=file_system_location)形式の、クライアント構成ファイルの名前およびパス。カッコは必須です。クライアント構成ファイルは、少なくとも次のパラメータを指定する必要があるテキスト・ファイルです。

ra_host - host:port形式の、リモート・リカバリ・アプライアンスのホスト名およびポート。

ra_wallet - 認証に使用するOracleウォレットの場所と、使用する資格証明。

クライアント構成ファイルのサンプルの内容を次に示します。

ra_host=oam2.example.com:6498 ra_wallet='location=file:/u01/oracle/wallets credential_alias=repcred1'

max_streams

最大同時レプリケーション・タスク数。各レプリケーション・タスクは単一のバックアップ・ピースを処理します。null (推奨設定)の場合、アップストリーム・リカバリ・アプライアンスにより、ノード数に基づいてレプリケーションに使用するストリーム数が決定されます。

catalog_user_name

必ずRASYSを指定します。

wallet_alias

アップストリーム・リカバリ・アプライアンスでダウンストリーム・リカバリ・アプライアンスによる認証に使用するウォレット内の資格証明を特定する別名。

wallet_path

ローカルOracleウォレットのパス(ウォレット・ファイル名を除く)。

proxy_url

host形式の、必要なプロキシ・サーバーのURL。

proxy_port

プロキシ・サーバーのポート番号。

http_timeout

HTTPタイムアウト間隔(秒)。Oracleサポートによって別の値に設定するよう指示されないかぎり、システム・デフォルトのHTTPタイムアウトを受け入れるように、このパラメータは通常、nullに設定したままにします。

12.11 CREATE_SBT_ATTRIBUTE_SET

このプロシージャは、SBTジョブで使用できるSBT属性セットを作成します。

SBT属性セットとは、SBTジョブの実行を制御する属性のグループです。このような属性を使用すると、宛先メディア・プールやメディア・ファミリなど、メディア管理ライブラリの設定を指定できます。複数のSBT属性セットを定義できます。複数のジョブで単一の属性セットを参照できます。

構文

PROCEDURE create_sbt_attribute_set(
lib_name IN VARCHAR2,
attribute_set_name IN VARCHAR2,
streams IN NUMBER DEFAULT NULL,
poolid IN NUMBER DEFAULT NULL,
parms IN VARCHAR2 DEFAULT NULL,
send IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-10 CREATE_SBT_ATTRIBUTE_SETのパラメータ

パラメータ

説明

lib_name

属性セットに関連付けるSBTライブラリの名前。

attribute_set_name

属性セットのユーザーが割り当てた名前。属性セット名は一意にする必要があります。

streams

自動化されたバックアップに使用される最大同時ストリーム数。同時ストリーム数が、SBTライブラリのdrives属性およびrestore_drives属性で設定された制限を超えることはありません。streamsがnullの場合、使用可能なドライブがすべて使用されます。

poolid

バックアップ・コピーの宛先として使用するメディア・プール番号。このパラメータは、RMAN BACKUPコマンドのPOOLパラメータと同じ形式の値を受け入れます。

parms

バックアップ・コピー操作用のメディア管理ライブラリ固有のパラメータ文字列。この文字列の形式は、RMAN ALLOCATE CHANNELコマンドのPARMSオプションと同じです。この属性のSBTバックアップ操作時に、このパラメータの値は、CREATE_SBT_LIBRARYプロシージャで指定されたPARMSパラメータとマージされます。

send

バックアップ・コピー操作用のメディア管理ライブラリ固有のパラメータを追加送信するために使用される文字列。この文字列の形式は、RMAN ALLOCATE CHANNELコマンドのSENDオプションと同じです。この属性のバックアップ操作時に、このパラメータの値は、CREATE_SBT_LIBRARYプロシージャで指定されたSENDパラメータとマージされます。

12.12 CREATE_SBT_JOB_TEMPLATE

このプロシージャは、テープへのコピー対象となるバックアップの選択方法を記述するSBTジョブを作成します。この過負荷プロシージャのこの形式は、指定された保護ポリシーに割り当てられた保護されたデータベースすべてに対するバックアップに適用されます。

SBTバックアップ・ジョブを作成したら、Oracle Schedulerなどのスケジューリング機能を使用して、そのジョブをスケジュールする必要があります。「QUEUE_SBT_BACKUP_TASK」を参照してください。

構文

PROCEDURE create_sbt_job_template (
template_name IN VARCHAR2,
protection_policy_name IN VARCHAR2,
attribute_set_name IN VARCHAR2,
backup_type IN VARCHAR2,
full_template_name IN VARCHAR2 DEFAULT NULL,
from_tag IN VARCHAR2 DEFAULT NULL,
priority IN NUMBER DEFAULT SBT_PRIORITY_MEDIUM,
copies IN NUMBER DEFAULT 1,
window IN DSINTERVAL_UNCONSTRAINED DEFAULT NULL'
compression_algorithm IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-11 CREATE_SBT_JOB_TEMPLATEのパラメータ

パラメータ

説明

template_name

SBTジョブ・テンプレートのユーザーが割り当てた名前。

protection_policy_name

このSBTジョブが適用される保護ポリシーの名前。この保護ポリシーに割り当てられたすべての保護されたデータベースに対するバックアップがコピーの対象となります。

attribute_set_name

このSBTジョブに使用するSBT属性セットの名前。

backup_type

このSBTジョブでテープへのコピー対象として選択されるバックアップのタイプ。この文字列は、次のタイプのカンマ区切りのリストにする必要があります。

ALL: FULL、INCR、ARCHの省略表現

INCR: 直近の全体バックアップ以降、まだテープにコピーされていない増分ログをすべてコピーします。

ARCH: 直近の全体バックアップ以降、まだテープにコピーされていないアーカイブREDOログ・バックアップをすべてコピーします。

FULL: 直近の全体バックアップがまだテープにコピーされていない場合、それをコピーします。バックアップは、受信された直近のレベル0バックアップか、受信された直近のレベル1バックアップに基づいた仮想全体バックアップのいずれか新しい方です。

full_template_name

このSBTジョブ・テンプレートの完全名。これは、INCRおよびARCHバックアップ・タイプにのみ適用されます。完全名は、全体バックアップとそのリカバリに必要な増分バックアップおよびアーカイブREDOログ・ファイルをリンクします。指定されたテープ・ライブラリに全体バックアップ・テンプレートが1つのみ存在する場合、このパラメータのデフォルトはこのテンプレートの名前に設定されます。つまり、指定する必要がありません。全体バックアップ・テンプレートが複数存在する場合、完全テンプレート名を指定する必要があります。指定するFULLテンプレート名は、INCRまたはARCHジョブと同じSBTライブラリに属する必要があります。backup_typeをFULLまたはALLに設定した場合、full_template_nameはtemplate_nameと同じです。

from_tag

タグ名。指定した場合、テープへのコピーにこのタグを使用しているバックアップのみと見なされます。

関連項目:
TAG文字列の正しい形式については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください

priority

テープ・リソースの使用に関するこのジョブの優先度。優先度の値が低いほど、高い値よりも優先されます。0が最高の優先度です。0(ゼロ)以上の数値を使用できます。事前定義済の値は次のとおりです。

SBT_PRIORITY_LOW: 1000に対応

SBT_PRIORITY_MEDIUM: 100に対応

SBT_PRIORITY_HIGH: 10に対応

SBT_PRIORITY_CRITICAL: 1に対応

デフォルトの優先度はSBT_PRIORITY_MEDIUMです。リストア・ジョブのデフォルトの優先度はSBT_PRIORITY_CRITICALです。

copies

このSBTジョブで作成される各バックアップの別個のコピー数。有効値は1 (デフォルト)から4の範囲です。

window

このジョブでバックアップをテープにコピーできる時間ウィンドウ。指定されたウィンドウ内で開始できないコピー・タスクは、次にスケジュールされているジョブの実行まで待機する必要があります。

compression_algorithm

このSBTジョブに使用する圧縮アルゴリズム。

BASIC: 優れた圧縮率であり、MEDIUMより低速になる可能性があります。

LOW: 速度に対して最適化されており、BASICより低い圧縮率になる可能性があります。

MEDIUM: ほとんどの環境に適しています。圧縮率と速度の優れた組合せが得られます。

HIGH: 制限要素が最大テープ・スループットである低速なネットワークでの操作に最も適しています。

NULL: 圧縮しません。

LOW、MEDIUMおよびHIGHは、保護されたデータベースでのリストア操作に対する追加のライセンスが必要なAdvanced Compressionオプションです。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

12.13 CREATE_SBT_JOB_TEMPLATE

このプロシージャは、新しいSBTバックアップ・ジョブを作成します。ジョブでは、テープへのコピー対象となるバックアップの選択方法を記述します。この過負荷プロシージャのこの形式は、単一の保護されたデータベースに対するバックアップにのみ適用されますが、前述の形式は特定の保護ポリシーに割り当てられたデータベースすべてに対するバックアップに適用されます。この相違を除いて、このプロシージャとそのパラメータは、このプロシージャの代替形式とまったく同じです。

構文

PROCEDURE create_sbt_job_template (
template_name IN VARCHAR2,
db_unique_name IN VARCHAR2,
attribute_set_name IN VARCHAR2,
backup_type IN VARCHAR2,
full_template_name IN VARCHAR2 DEFAULT NULL,
from_tag IN VARCHAR2 DEFAULT NULL,
priority IN NUMBER DEFAULT SBT_PRIORITY_MEDIUM,
copies IN NUMBER DEFAULT 1,
window IN DSINTERVAL_UNCONSTRAINED DEFAULT NULL,
compression_algorithm IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-12 CREATE_SBT_JOB_TEMPLATEのパラメータ

パラメータ

説明

db_unique_name

このSBTジョブが適用される保護されたデータベースのDB_UNIQUE_NAME。このSBTジョブは、指定されたデータベースに属するバックアップのみコピーします。

12.14 CREATE_SBT_LIBRARY

このプロシージャは、インストールされたメディア管理ソフトウェア・ライブラリを記述するメタデータを作成します。リカバリ・アプライアンスでは、指定されたライブラリを使用して、内部記憶域からテープまたはこのメディア・マネージャでサポートされる他の3次記憶域にバックアップがコピーされます。

構文

PROCEDURE create_sbt_library (
lib_name IN VARCHAR2,
drives IN NUMBER,
restore_drives IN NUMBER DEFAULT 0,
parms IN VARCHAR2 DEFAULT NULL,
send IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-13 CREATE_SBT_LIBRARYのパラメータ

パラメータ

説明

lib_name

このSBTライブラリの参照に使用されるユーザー指定の名前。

drives

このSBTライブラリがアクセスできるテープ・ドライブの最大数。リカバリ・アプライアンスでは、このライブラリへのアクセス時に、指定された同時ストリーム数を超えて使用することはありません。

restore_drives

リストア操作用に予約されたテープ・ドライブの数。

指定した場合、リカバリ・アプライアンスでは、バックアップ操作に最大でdrives - restore_drivesドライブを使用するため、常に指定されたドライブ数をリストア操作に使用できるようになります。

指定しない場合、リカバリ・アプライアンスでは、使用可能なドライブすべてをバックアップに使用できるため、リストア操作はドライブが解放されるまで待機することが必要になる場合があります。

parms

このSBTライブラリへのアクセスに使用されるライブラリ固有のパラメータ文字列。この文字列の形式は、RMAN ALLOCATE CHANNELコマンドのPARMSオプションと同じです。この文字列には通常、SBT_LIBRARYパラメータが含まれます。

send

このSBTライブラリにライブラリ固有のパラメータを追加送信するために使用されるパラメータ文字列。この文字列の形式は、RMAN ALLOCATE CHANNELコマンドのSENDオプションと同じです。

12.15 CREATE_STORAGE_LOCATION

このプロシージャは、リカバリ・アプライアンスで使用される記憶域を記述するオブジェクトである、リカバリ・アプライアンスの記憶域の場所を作成します。名前が付けられた記憶域の場所にバックアップがすべて格納されます。

リカバリ・アプライアンスでは、リカバリ・アプライアンスに存在するOracle ASMディスク・グループから記憶域の場所が割り当てられます。

新たに作成された記憶域の場所には、保護ポリシーを使用してその場所を保護されたデータベースに関連付けるまで、どのファイルも格納されません。

構文

PROCEDURE create_storage_location (
storage_location_name IN VARCHAR2,
storage_location_dests IN VARCHAR2);

パラメータ

表12-14 CREATE_STORAGE_LOCATIONのパラメータ

パラメータ

説明

storage_location_name

この記憶域の場所のユーザーが割り当てた名前。

storage_location_dests

この記憶域の場所への領域の割当て元となるOracle ASMディスク・グループのカンマ区切りのリスト。ディスク・グループは存在する必要があります。指定されたディスク・グループの割当て単位サイズは同一である必要があります。複数の記憶域の場所では、同じOracle ASMディスク・グループを使用できません。

このパラメータは、次の形式の文字列を受け入れます。

storage_location_spec [ , storage_location_spec ... ]

各storage_location_specの形式は次のとおりです。

storage_location_name [ ( size [ K | M | G | T | P | E | Z | Y ] ) ]

storage_location_nameは、Oracle ASMディスク・グループの名前です。必要に応じて、ディスク・グループ名の後に、このディスク・グループからこの記憶域の場所に割り当てられる領域の容量を指定できます。サイズの指定がない場合、この記憶域の場所にはディスク・グループ内のすべての空き領域が割り当てられます。

次の例では、ディスク・グループDG1のすべての空き領域を使用する記憶域の場所を指定しています。

+DG1

次の例では、ディスク・グループDG1から20TBの領域、ディスク・グループDG2のすべての空き領域、およびディスク・グループDG3から30TBの領域を使用する記憶域の場所を指定しています。

+DG1(20T),+DG2,+DG3(30T)

12.16 DELETE_DB

このプロシージャは、リカバリ・アプライアンスから指定の保護されたデータベースを削除します。ディスクとSBTの両方から、このデータベースに関連するメタデータおよびバックアップがすべて削除されます。

エラーのため、このデータベースが所有するSBTバックアップを削除できない場合、DELETE_DB操作は失敗します。SBTエラーが発生した場合、指定されたデータベースはリカバリ・アプライアンスから完全には削除されません。DELETE_DBプロシージャ中に発生したエラーはRA_INCIDENT_LOGビューに記録されます。waitパラメータをTRUEと指定した場合、DELETE_DBがコールされるセッションでもこのようなエラーが発生します。SBTエラーを診断して問題を解決すれば、DELETE_DBを再度実行できます。

構文

PROCEDURE delete_db (
db_unique_name IN VARCHAR2,
wait IN BOOLEAN DEFAULT TRUE);

パラメータ

表12-15 DELETE_DBのパラメータ

パラメータ

説明

db_unique_name

削除するデータベースのDB_UNIQUE_NAME。

wait

プロシージャの待機動作。TRUEの場合、指定されたデータベースのバックアップおよびメタデータがリカバリ・アプライアンスから完全に削除されるまで、プロシージャは戻りません。FALSEの場合、プロシージャはすぐに戻り、データベース削除操作はバックグラウンドで続行されます。

12.17 DELETE_POLLING_POLICY

このプロシージャは、指定されたバックアップのポーリング・ポリシーを削除します。

構文

PROCEDURE delete_polling_policy (
polling_policy_name IN VARCHAR2);

パラメータ

表12-16 DELETE_POLLING_POLICYのパラメータ

パラメータ

説明

polling_policy_name

削除するバックアップのポーリング・ポリシーの名前。

12.18 DELETE_PROTECTION_POLICY

このプロシージャは、指定された保護ポリシーを削除します。

指定されたポリシーは、データベースに関連付けられていない必要があります。

構文

PROCEDURE delete_protection_policy (
protection_policy_name IN VARCHAR2);

パラメータ

表12-17 DELETE_PROTECTION_POLICYのパラメータ

パラメータ

説明

protection_policy_name

削除する保護ポリシーの名前。

12.19 DELETE_REPLICATION_SERVER

このプロシージャは、レプリケーション・サーバー構成を削除します。ダウンストリーム・リカバリ・アプライアンスに関連するメタデータがすべて削除されます。

構文

PROCEDURE delete_replication_server (
replication_server_name IN VARCHAR2,
force IN BOOLEAN DEFAULT FALSE);

パラメータ

表12-18 DELETE_REPLICATION_SERVERのパラメータ

パラメータ

説明

replication_server_name

削除するレプリケーション・サーバー構成の名前。

force

保護ポリシーが構成に関連付けられている場合の削除動作。FALSEの場合、レプリケーション・サーバー構成がまだ保護ポリシーに関連付けられている場合、削除は失敗します。この場合、先にREMOVE_REPLICATION_SERVERをコールする必要があります。TRUEの場合、まず、delete_replication_serverによって保護ポリシーからレプリケーション・サーバー構成が削除されます。

12.20 DELETE_SBT_ATTRIBUTE_SET

このプロシージャは、指定されたSBT属性セットを削除します。

構文

PROCEDURE delete_sbt_attribute_set(
attribute_set_name IN VARCHAR2);

パラメータ

表12-19 DELETE_SBT_ATTRIBUTE_SETのパラメータ

パラメータ

説明

attribute_set_name

削除するSBT属性セットの名前。

12.21 DELETE_SBT_JOB_TEMPLATE

このプロシージャは、指定されたSBTジョブ・テンプレートを削除します。

構文

PROCEDURE delete_sbt_job_template (
template_name IN VARCHAR2);

パラメータ

表12-20 DELETE_SBT_JOB_TEMPLATEのパラメータ

パラメータ

説明

template_name

削除するSBTジョブの名前。リカバリ・アプライアンスにより、このジョブに属するタスクがタスク・キューから削除されますが、実行中のタスクは終了しません。

12.22 DELETE_SBT_LIBRARY

このプロシージャは、指定されたSBTライブラリを記述しているメタデータを削除します。

SBTライブラリ・オブジェクトのみが削除され、メディア管理ソフトウェアはアンインストールされません。

このプロシージャは、このSBTライブラリ用に作成されたSBTジョブおよび属性をすべて削除します。

構文

PROCEDURE delete_sbt_library (
lib_name IN VARCHAR2);

パラメータ

表12-21 DELETE_SBT_LIBRARYのパラメータ

パラメータ

説明

lib_name

削除するSBTライブラリの名前。

12.23 DELETE_STORAGE_LOCATION

このプロシージャは、指定されたリカバリ・アプライアンスの記憶域の場所を削除します。

指定された記憶域の場所は空であり、保護ポリシーに関連付けられていない必要があります。この記憶域の場所について記憶域の移動が進行中でない必要があります。記憶域の移動が進行中の場合またはこの記憶域の場所にファイルが存在する場合、このプロシージャはエラーが表示されて失敗します。

構文

PROCEDURE delete_storage_location (
storage_location_name IN VARCHAR2);

パラメータ

表12-22 DELETE_STORAGE_LOCATIONのパラメータ

パラメータ

説明

storage_location_name

削除するリカバリ・アプライアンスの記憶域の場所の名前。

12.24 GRANT_DB_ACCESS

このプロシージャは、指定されたリカバリ・アプライアンス・ユーザー・アカウントに必要な権限を付与し、そのアカウントが指定の保護されたデータベースに関するリカバリ・カタログ・メタデータのバックアップ、リストアおよびアクセスをできるようにします。

構文

PROCEDURE grant_db_access (
username IN VARCHAR2,
db_unique_name IN VARCHAR2);

パラメータ

表12-23 GRANT_DB_ACCESSのパラメータ

パラメータ

説明

username

リカバリ・アプライアンス・ユーザー・アカウントの名前。

db_unique_name

権限が付与されている保護されたデータベース。

12.25 MIGRATE_TAPE_BACKUP

このプロシージャは、指定されたSBTライブラリを介してリカバリ・アプライアンスで移行前のテープ・バックアップをアクセスできるようにします。先に、RMAN IMPORT CATALOGコマンドを使用してリカバリ・アプライアンス・カタログにテープ・バックアップに関するメタデータをインポートする必要があります。

このプロシージャは、既存のテープ・バックアップへのアクセスに必要なメタデータの調整を実行しますが、バックアップを物理的に移動しません。既存のバックアップは、指定されたSBTライブラリによってアクセスできている必要があります。

構文

PROCEDURE migrate_tape_backup(
db_unique_name IN VARCHAR2,
sbt_lib_name IN VARCHAR2);

パラメータ

表12-24 MIGRATE_TAPE_BACKUPのパラメータ

パラメータ

説明

db_unique_name

バックアップを移行する保護されたデータベースのカンマ区切りのリスト。各db_unique_nameをリカバリ・アプライアンス・カタログに登録し、ADD_DBを使用してリカバリ・アプライアンスに追加しておく必要があります。

sbt_lib_name

指定の保護されたデータベースの既存のテープ・バックアップにアクセスするために使用されるSBTライブラリ。「CREATE_SBT_LIBRARY」を参照してください。

12.26 MOVE_BACKUP

このプロシージャは、リカバリ・アプライアンスからユーザー指定のSBT宛先に、1つ以上の長期アーカイブ・バックアップ・ピース(RMAN BACKUP ... KEEPコマンドを使用して作成されたバックアップ)を移動します。

指定したタグとformatパラメータおよびtemplate_nameパラメータで指定した場所が一致するバックアップ・ピースがすべてコピーされます。各バックアップ・ピースは、正常にコピーされると、元の場所から削除されます。

構文

PROCEDURE move_backup (
tag IN VARCHAR2,
format IN VARCHAR2,
template_name IN VARCHAR2,
compression_algorithm IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-25 MOVE_BACKUPのパラメータ

パラメータ

説明

tag

コピーするバックアップのタグ。このタグと一致するバックアップがすべて削除されます。

format

作成するバックアップ・ピースのネーミング形式。このパラメータは、RMAN FORMATパラメータと同じルールに従います。

template_name

メディア管理ライブラリ・テンプレート。

リカバリ・アプライアンスにより、SBTテンプレート名で参照されるメディア・プールをコピー先として使用して、バックアップ・ピースがテープにコピーされます。

compression_algorithm

このバックアップの移動操作に使用する圧縮アルゴリズム。次のいずれかを使用して、SBTジョブ・テンプレートに指定された圧縮アルゴリズムを上書きします。

BASIC: 優れた圧縮率であり、MEDIUMより低速になる可能性があります。

LOW: 速度に対して最適化されており、BASICより低い圧縮率になる可能性があります。

MEDIUM: ほとんどの環境に適しています。圧縮率と速度の優れた組合せが得られます。

HIGH: 制限要素が最大テープ・スループットである低速なネットワークでの操作に最も適しています。

OFF: 圧縮しません。

NULL (デフォルト)は、SBTジョブ・テンプレートに定義されているアルゴリズムを使用する必要があることを示します。

LOW、MEDIUMおよびHIGHは、保護されたデータベースでのリストア操作に対する追加のライセンスが必要なAdvanced Compressionオプションです。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

12.27 MOVE_BACKUP_PIECE

このプロシージャは、リカバリ・アプライアンスからユーザー指定のSBT宛先に単一の長期アーカイブ・バックアップ・ピースを移動します。

指定されたバックアップ・ピースは、formatパラメータとtemplate_nameパラメータで指定された場所にコピーされます。バックアップ・ピースは、正常にコピーされると、元の場所から削除されます。

構文

PROCEDURE move_backup_piece (
bp_key IN NUMBER,
format IN VARCHAR2,
template_name IN VARCHAR2,
compression_algorithm IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-26 MOVE_BACKUP_PIECEのパラメータ

パラメータ

説明

bp_key

移動するバックアップ・ピースの一意キー。このキーはRC_BACKUP_PIECEビューから取得します。

format

作成するバックアップ・ピースのネーミング形式。このパラメータは、RMAN FORMATパラメータと同じルールに従います。

template_name

メディア管理ライブラリ・テンプレート。

リカバリ・アプライアンスにより、SBTテンプレート名で参照されるメディア・プールをコピー先として使用して、バックアップ・ピースがテープにコピーされます。

compression_algorithm

このバックアップの移動操作に使用する圧縮アルゴリズム。次のいずれかを使用して、SBTジョブ・テンプレートに指定された圧縮アルゴリズムを上書きします。

BASIC: 優れた圧縮率であり、MEDIUMより低速になる可能性があります。

LOW: 速度に対して最適化されており、BASICより低い圧縮率になる可能性があります。

MEDIUM: ほとんどの環境に適しています。圧縮率と速度の優れた組合せが得られます。

HIGH: 制限要素が最大テープ・スループットである低速なネットワークでの操作に最も適しています。

OFF: 圧縮しません。

LOW、MEDIUMおよびHIGHは、保護されたデータベースでのリストア操作に対する追加のライセンスが必要なAdvanced Compressionオプションです。

NULL (デフォルト)は、SBTジョブ・テンプレートに定義されているアルゴリズムを使用する必要があることを示します。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

12.28 PAUSE_REPLICATION_SERVER

このプロシージャは、指定されたダウンストリーム・リカバリ・アプライアンスへのレプリケーションを一時停止します。

リカバリ・アプライアンスでは、進行中のバックアップ・ピースのレプリケートを完了できます。このレプリケーション・サーバー構成を使用したレプリケート対象のバックアップ・ピースがキューに入れられて、レプリケートされなかった場合は、RESUME_REPLICATION_SERVERをコールするまでそのバックアップ・ピースは保持されます。このリカバリ・アプライアンスに対して実行されるレプリケーション・タスクは、ダウンストリーム・リカバリ・アプライアンスへのレプリケーションを再開するまで実行できません。

構文

PROCEDURE pause_replication_server  (
replication_server_name IN VARCHAR2);

パラメータ

表12-27 PAUSE_REPLICATION_SERVERのパラメータ

パラメータ

説明

replication_server_name

ダウンストリーム・リカバリ・アプライアンスの名前。

12.29 PAUSE_SBT_LIBRARY

このプロシージャは、指定されたSBTライブラリを一時停止します。リカバリ・アプライアンスでは、進行中のバックアップ・ピースのコピーを完了できます。ただし、このSBTライブラリを介したコピー対象のバックアップ・ピースがキューに入れられて、まだコピーされていない場合は、このSBTライブラリを再開するまでそのバックアップ・ピースは保持されます。このライブラリに対して実行される新しいSBTジョブは、ライブラリを再開(RESUME_SBT_LIBRARY)するまで実行できません。

RA_SBT_LIBRARYビューに既存のSBTライブラリのリストを問い合せます。

構文

PROCEDURE pause_sbt_library(
lib_name IN VARCHAR2);

パラメータ

表12-28 PAUSE_SBT_LIBRARYのパラメータ

パラメータ

説明

lib_name

一時停止するSBTライブラリの名前。

12.30 POPULATE_BACKUP_PIECE

このプロシージャは、指定されたバックアップ・ピースをデルタ・ストアにプッシュします。

このプロシージャを使用して、初めにデルタ・ストアを移入するか、デルタ・ストア内の破損を修正します。デルタ・ストアは、永久的増分バックアップ・ソリューションをサポートしているバックアップ・データです。増分バックアップ(KEEPバックアップではなく)のみ、デルタ・ストアに組み込むことができます。

構文

PROCEDURE populate_backup_piece(
backup_piece_key IN NUMBER);

パラメータ

表12-29 POPULATE_BACKUP_PIECEのパラメータ

パラメータ

説明

backup_piece_key

破損の検出時にリカバリ・アプライアンスによって提供されるバックアップ・ピース・キー、またはデルタ・ストアに挿入するバックアップ・ピース。キーが仮想バックアップ・ピースである場合、デルタ・ストア内の破損を解決するためのバックアップ・ピースが検索されます。キーが仮想バックアップ・ピースでない場合、そのバックアップ・ピースがデルタ・ストアに挿入されます。このバックアップは、KEEPバックアップではない増分バックアップである必要があります。

12.31 QUEUE_SBT_BACKUP_TASK

このプロシージャは、指定されたSBTジョブ・テンプレートでテープへのコピー対象に選択されたバックアップ・ピースをキューに入れます。通常、このプロシージャはOracle Schedulerなどのスケジューリング・ユーティリティによってコールされます。

構文

PROCEDURE queue_sbt_backup_task(
template_name IN VARCHAR2);

パラメータ

表12-30 QUEUE_SBT_BACKUP_TASKのパラメータ

パラメータ

説明

template_name

テープにコピーするバックアップ・ピースを指定するSBTジョブ・テンプレートの名前。「CREATE_SBT_JOB_TEMPLATE」を参照してください。

12.32 REMOVE_REPLICATION_SERVER

このプロシージャは、指定されたレプリケーション･サーバー構成を指定された保護ポリシーから削除します。操作が成功すると、このポリシーで保護されるデータベースのバックアップがダウンストリーム・リカバリ・アプライアンスにレプリケートされなくなります。

構文

PROCEDURE remove_replication_server (
replication_server_name IN VARCHAR2,
protection_policy_name IN VARCHAR2);

パラメータ

表12-31 REMOVE_REPLICATION_SERVERのパラメータ

パラメータ

説明

replication_server_name

削除するレプリケーション・サーバー構成の名前。

protection_policy_name

指定されたレプリケーション・サーバー構成を削除する保護ポリシーの名前。

12.33 RENAME_DB

このプロシージャは、リカバリ・アプライアンス・メタデータで指定の保護されたデータベースの名前を変更します。

保護されたデータベースのDB_UNIQUE_NAMEが変わった場合はこのプロシージャを使用して、リカバリ・アプライアンス・メタデータに正しい名前を反映します。

構文

PROCEDURE rename_db (
db_unique_name_old IN VARCHAR2,
db_unique_name_new IN VARCHAR2);

パラメータ

表12-32 RENAME_DBのパラメータ

パラメータ

説明

db_unique_name_old

変更するDB_UNIQUE_NAME。

db_unique_name_new

新しいDB_UNIQUE_NAME。

12.34 RESET_ERROR

このプロシージャは、指定されたエラー・ログ・エントリのステータスをRESETに変更します。この方式でマークされたエラーによってOracle Enterprise Managerでアラートが発生することはありません。リカバリ・アプライアンスによって問題が依然として発生していると判断されると、リセットされたエラーがACTIVEステータスに変ります。このAPIの主な用途は、一時的なメディア障害などの繰り返し発生しないエラーに対するエラー・ステータスをリセットすることです。

構文

PROCEDURE reset_error(
incident# IN NUMBER);

パラメータ

表12-33 RESET_ERRORのパラメータ

パラメータ

説明

incident#

リセットするエラー・ログ・エントリの一意の識別子。識別子は、RA_INCIDENT_LOGビューから取得します。

12.35 RESUME_REPLICATION_SERVER

このプロシージャは、前のPAUSE_REPLICATION_SERVERのコール後に、指定されたダウンストリーム・リカバリ・アプライアンスへのレプリケーションを再開します。

構文

PROCEDURE resume_replication_server (
replication_server_name IN VARCHAR2);

パラメータ

表12-34 RESUME_REPLICATION_SERVERのパラメータ

パラメータ

説明

replication_server_name

ダウンストリーム・リカバリ・アプライアンスの名前。

12.36 RESUME_SBT_LIBRARY

このプロシージャは、一時停止しているSBTライブラリを再開します。

RA_SBT_LIBRARYを問い合せ、どのSBTライブラリが一時停止している(「PAUSE_SBT_LIBRARY」を参照)かを判別します。

構文

PROCEDURE resume_sbt_library(
lib_name IN VARCHAR2);

パラメータ

表12-35 RESUME_SBT_LIBRARYのパラメータ

パラメータ

説明

lib_name

再開するSBTライブラリの名前。

12.37 REVOKE_DB_ACCESS

このプロシージャは、指定されたリカバリ・アプライアンス・ユーザー・アカウントから単一の保護されたデータベースに対する権限を取り消します。

構文

PROCEDURE revoke_db_access (
username IN VARCHAR2,
db_unique_name IN VARCHAR2);

パラメータ

表12-36 REVOKE_DB_ACCESSのパラメータ

パラメータ

説明

username

権限を取り消すユーザー・アカウントの名前。

db_unique_name

権限を取り消す保護されたデータベース。

12.38 SHUTDOWN

SHUTDOWN_RECOVERY_APPLIANCEと同義です。

構文

PROCEDURE shutdown;

12.39 SHUTDOWN_RECOVERY_APPLIANCE

このプロシージャは、リカバリ・アプライアンスの正しい停止を実行します。

このプロシージャを使用すると、停止前に進行中の操作を完了できます。停止には、時間がかかることがあります。即時停止が必要な場合は、ABORT_RECOVERY_APPLIANCEを使用します。Recovery Applianceの停止方法は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。

構文

PROCEDURE shutdown_recovery_appliance;

12.40 STARTUP

STARTUP_RECOVERY_APPLIANCEと同義です。

構文

PROCEDURE startup;

12.41 STARTUP_RECOVERY_APPLIANCE

このプロシージャは、停止または終了した後のリカバリ・アプライアンスを起動します。

リカバリ・アプライアンスの起動時には、バックアップ・リクエストとリストア・リクエストのみを処理できます。

STARTUP_RECOVERY_APPLIANCEを使用してリカバリ・アプライアンスを起動した場合、およびリカバリ・アプライアンス・メタデータ・データベースのインスタンスを再起動した場合、データベース起動トリガーによってリカバリ・アプライアンスは自動的に再起動されます。唯一の例外は、RESETLOGSオプションを使用してメタデータ・データベースを再起動した場合で、これにはstartup_recovery_applianceプロシージャを実行して破損したメタデータを修復する必要があります。Recovery Applianceの起動方法は、『Zero Data Loss Recovery Applianceオーナーズ・ガイド』を参照してください。

構文

PROCEDURE startup_recovery_appliance;

12.42 UPDATE_DB

このプロシージャは、指定の保護されたデータベースに割り当てられている属性を変更します。

構文

PROCEDURE update_db (
db_unique_name IN VARCHAR2,
protection_policy_name IN VARCHAR2 DEFAULT NULL,
reserved_space IN VARCHAR2 DEFAULT NULL,
db_timezone IN VARCHAR2 DEFAULT NULL,
incarnations IN VARCHAR2 DEFAULT 'CURRENT');

パラメータ

表12-37 UPDATE_DBのパラメータ

パラメータ

説明

db_unique_name

データベースのDB_UNIQUE_NAME。

protection_policy_name

データベースに割り当てる保護ポリシーの名前。保護ポリシーは存在する必要があります。

新しい保護ポリシーによって新しいストレージ操作が制御されます。新旧の保護ポリシーで異なる記憶域の場所を指定している場合、リカバリ・アプライアンスでは、バックグラウンド・タスクを起動して古い記憶域の場所から新しい場所にデータが移動されます。不要になっていないバックアップのみが移動されます。

記憶域の場所の間を移動する必要がある場合、移動が開始されるまで、RA_DATABASEビューには新しい保護ポリシーが表示されません。

リカバリ・アプライアンスでは、より高い優先度の作業を実行する必要がある場合、移動の開始までに数時間かかることもあります。

reserved_space

「ADD_DB」を参照してください。

db_timezone

このデータベースが位置するタイムゾーン。デフォルトでは、保護されたデータベースはリカバリ・アプライアンスと同じタイムゾーンに割り当てられます。保護されたデータベースが異なるタイムゾーンにある場合、このプロシージャを使用してデータベースを正しいタイムゾーンに割り当てます。

incarnations

更新対象となるすべての前のデータベース・インカネーションに対するキーのカンマ区切りのリスト。デフォルトでは、このプロシージャは、現在のインカネーションを更新します。このリストに現在のインカネーション・キーが含まれている場合、保護されたデータベースの管理者がパラメータ・ファイルでタイムゾーンを指定していなければ、このプロシージャはdbinc表とnode表内の現在のインカネーションに対応する行のみを更新します。dbinc表内のエントリが有効な場合、このプロシージャはリスト内の他のすべてのインカネーションに対するエントリを更新します。

12.43 UPDATE_POLLING_POLICY

このプロシージャは、既存のバックアップのポーリング・ポリシーのパラメータを変更します。

NULLのパラメータでは、既存の値が維持されます。

構文

PROCEDURE update_polling_policy (
polling_policy_name IN VARCHAR2,
polling_location IN VARCHAR2 DEFAULT NULL,
polling_frequency IN DSINTERVAL_UNCONSTRAINED DEFAULT NULL,
delete_input IN BOOLEAN DEFAULT NULL);

パラメータ

表12-38 UPDATE_POLLING_POLICYのパラメータ

パラメータ

説明

polling_policy_name

更新するバックアップのポーリング・ポリシーの名前。

polling_location

「CREATE_POLLING_POLICY」を参照してください。

polling_frequency

「CREATE_POLLING_POLICY」を参照してください。

delete_input

「CREATE_POLLING_POLICY」を参照してください。

12.44 UPDATE_PROTECTION_POLICY

このプロシージャは、既存の保護ポリシーのパラメータを変更します。

パラメータがNULLの場合、次に記載されている場合を除き、値は変更されないままです。

構文

PROCEDURE update_protection_policy (
protection_policy_name IN VARCHAR2,
description IN VARCHAR2 DEFAULT NULL,
storage_location_name IN VARCHAR2 DEFAULT NULL,
polling_policy_name IN VARCHAR2 DEFAULT dbms_ra_int.varchar2null('p1'),
recovery_window_goal IN DSINTERVAL_UNCONSTRAINED DEFAULT NULL,
max_retention_window IN DSINTERVAL_UNCONSTRAINED DEFAULT dbms_ra_int.intervalnull('p3'),
recovery_window_sbt IN DSINTERVAL_UNCONSTRAINED DEFAULT dbms_ra_int.intervalnull('p2'),
unprotected_window IN DSINTERVAL_UNCONSTRAINED DEFAULT dbms_ra_int.intervalnull('p4'),
guaranteed_copy IN VARCHAR2 DEFAULT NULL,
allow_backup_deletion IN VARCHAR2 DEFAULT NULL,
store_and_forward IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-39 UPDATE_PROTECTION_POLICYのパラメータ

パラメータ

説明

protection_policy_name

更新する保護ポリシーの名前。

description

「CREATE_PROTECTION_POLICY」を参照してください。

storage_location_name

「CREATE_PROTECTION_POLICY」を参照してください。

この保護ポリシーの記憶域の場所を変更した場合、リカバリ・アプライアンスでは、バックグラウンド・ジョブを起動して古い記憶域の場所から新しい記憶域の場所にデータが移動されます。

polling_policy_name

「CREATE_PROTECTION_POLICY」を参照してください。

このパラメータを指定しない場合、ポリシーでは既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

recovery_window_goal

「CREATE_PROTECTION_POLICY」を参照してください。

max_retention_window

「CREATE_PROTECTION_POLICY」を参照してください。

このパラメータを指定しない場合、古い値が維持されます。指定した場合(NULLと指定した場合も含む)、新しい値が設定されます。

recovery_window_sbt

「CREATE_PROTECTION_POLICY」を参照してください。

このパラメータを指定しない場合、ポリシーでは既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

unprotected_window

このパラメータを指定しない場合、ポリシーでは既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

「CREATE_PROTECTION_POLICY」を参照してください。

guaranteed_copy

「CREATE_PROTECTION_POLICY」を参照してください。

allow_backup_deletion

「CREATE_PROTECTION_POLICY」を参照してください。

このパラメータを指定しない場合、ポリシーでは既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.7以上でのみ使用可能です。

store_and_forward

「CREATE_PROTECTION_POLICY」を参照してください。

このパラメータを指定しない場合(またはnullを指定する場合)、ポリシーでは既存の値が維持されます。値を指定すると、新しい値が設定されます。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

12.45 UPDATE_REPLICATION_SERVER

このプロシージャは、レプリケーション・サーバー構成の設定を変更します。

レプリケーション・サーバーのパラメータの変更に関して、次の制約に注意してください。

構成では、元のCREATE_REPLICATION_SERVERコールのsbt_parms文字列が維持されません。max_streams以外のパラメータを変更する場合、この値を渡す必要があります。

max_streams以外の設定を変更するには、PAUSE_REPLICATION_SERVERをコールして、レプリケーションを一時停止する必要があります。

次のパラメータの説明に記載されている場合を除き、値がnullのsbt_parms以外のパラメータは変更されないままです。

構文

PROCEDURE update_replication_server (
replication_server_name IN VARCHAR2,
sbt_so_name IN VARCHAR2 DEFAULT NULL,
sbt_parms IN VARCHAR2 DEFAULT NULL,
max_streams IN NUMBER DEFAULT dbms_ra_int.number2null('p4'),
catalog_user_name IN VARCHAR2 DEFAULT NULL,
wallet_alias IN VARCHAR2 DEFAULT NULL,
wallet_path IN VARCHAR2 DEFAULT dbms_ra_int.varchar2null('p1'),
proxy_url IN VARCHAR2 DEFAULT dbms_ra_int.varchar2null('p2'),
proxy_port IN NUMBER DEFAULT dbms_ra_int.number2null('p3'),
http_timeout IN NUMBER DEFAULT NULL);

パラメータ

表12-40 UPDATE_REPLICATION_SERVERのパラメータ

パラメータ

説明

replication_server_name

更新するレプリケーション・サーバー構成の名前。

sbt_so_name

「CREATE_REPLICATION_SERVER」を参照してください。

sbt_parms

「CREATE_REPLICATION_SERVER」を参照してください。

max_streams

「CREATE_REPLICATION_SERVER」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

catalog_user_name

「CREATE_REPLICATION_SERVER」を参照してください。

wallet_alias

「CREATE_REPLICATION_SERVER」を参照してください。

wallet_path

「CREATE_REPLICATION_SERVER」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

proxy_url

「CREATE_REPLICATION_SERVER」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

proxy_port

「CREATE_REPLICATION_SERVER」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

http_timeout

「CREATE_REPLICATION_SERVER」を参照してください。

12.46 UPDATE_SBT_ATTRIBUTE_SET

このプロシージャは、指定されたSBT属性セットのパラメータを更新します。

パラメータがnullの場合、次のパラメータの説明に記載されている場合を除き、値は変更されないままです。

構文

PROCEDURE update_sbt_attribute_set(
attribute_set_name IN VARCHAR2,
streams IN NUMBER DEFAULT dbms_ra_int.number2null('p1'),
poolid IN NUMBER DEFAULT NULL,
parms IN VARCHAR2 DEFAULT dbms_ra_int.varchar2null('p2'),
send IN VARCHAR2 DEFAULT dbms_ra_int.varchar2null('p3'));

パラメータ

表12-41 UPDATE_SBT_ATTRIBUTE_SETのパラメータ

パラメータ

説明

attribute_set_name

更新するSBT属性セットの名前。

streams

「CREATE_SBT_ATTRIBUTE_SET」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

poolid

「CREATE_SBT_ATTRIBUTE_SET」を参照してください。

parms

「CREATE_SBT_ATTRIBUTE_SET」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

send

「CREATE_SBT_ATTRIBUTE_SET」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

12.47 UPDATE_SBT_JOB_TEMPLATE

このプロシージャは、指定されたSBTジョブのパラメータを更新します。

パラメータがnullの場合、次のパラメータの説明に記載されている場合を除き、値は変更されないままです。

構文

PROCEDURE update_sbt_job_template (
template_name IN VARCHAR2,
attribute_set_name IN VARCHAR2 DEFAULT NULL,
backup_type IN VARCHAR2 DEFAULT NULL,
from_tag IN VARCHAR2 DEFAULT dbms_ra_int.varchar2null('p1'),
priority IN NUMBER DEFAULT NULL,
copies IN NUMBER DEFAULT NULL,
window IN DSINTERVAL_UNCONSTRAINED DEFAULT dbms_ra_int.intervalnull('p2'),
compression_algorithm IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-42 UPDATE_SBT_JOB_TEMPLATEのパラメータ

パラメータ

説明

template_name

更新するSBTジョブ・テンプレートの名前。

attribute_set_name

「CREATE_SBT_JOB_TEMPLATE」を参照してください。

backup_type

「CREATE_SBT_JOB_TEMPLATE」を参照してください。

from_tag

「CREATE_SBT_JOB_TEMPLATE」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

priority

「CREATE_SBT_JOB_TEMPLATE」を参照してください。

copies

「CREATE_SBT_JOB_TEMPLATE」を参照してください。

window

「CREATE_SBT_JOB_TEMPLATE」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

compression_algorithm

「CREATE_SBT_JOB_TEMPLATE」を参照してください。

このパラメータを指定しない場合、またはNULLを指定する場合、リカバリ・アプライアンスでは既存の値が維持されます。値を指定すると、新しい値が設定されます。

このテンプレートから圧縮アルゴリズムを削除するには、OFFを指定します。これによって、COMPRESSION_ALGORITHMの値がNONEに変更されます。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

12.48 UPDATE_SBT_LIBRARY

このプロシージャは、指定されたSBTライブラリのパラメータを変更します。

パラメータがnullの場合、parmsおよびsendの説明での記載を除き、値は変更されないままです。

構文

PROCEDURE update_sbt_library (
lib_name IN VARCHAR2,
drives IN NUMBER DEFAULT NULL,
restore_drives IN NUMBER DEFAULT NULL,
parms IN VARCHAR2 DEFAULT dbms_ra_int.varchar2null('p1'),
send IN VARCHAR2 DEFAULT dbms_ra_int.varchar2null('p2'));

パラメータ

表12-43 UPDATE_SBT_LIBRARYのパラメータ

パラメータ

説明

lib_name

パラメータを変更するSBTライブラリの名前。

drives

「CREATE_SBT_LIBRARY」を参照してください。

restore_drives

「CREATE_SBT_LIBRARY」を参照してください。

parms

「CREATE_SBT_LIBRARY」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

send

「CREATE_SBT_LIBRARY」を参照してください。

このパラメータを指定しない場合、既存の値が維持されます。値(nullを含む)を指定すると、新しい値が設定されます。

12.49 UPDATE_STORAGE_LOCATION

このプロシージャは、指定された記憶域の場所に追加領域を割り当てます。記憶域の場所で使用される領域の容量を減らすことはできません。

構文

PROCEDURE update_storage_location (
storage_location_name IN VARCHAR2,
storage_location_dests IN VARCHAR2 DEFAULT NULL);

パラメータ

表12-44 UPDATE_STORAGE_LOCATIONのパラメータ

パラメータ

説明

storage_location_name

更新する記憶域の場所の名前。

storage_location_dests

このパラメータは、CREATE_STORAGE_LOCATIONの対応するパラメータと同じ形式の文字列を受け入れます。このパラメータはオプションであり、元のディスク・グループのいずれかを含めることも、いずれも含めないこともできます。

このプロシージャは、storage_location_destsパラメータに指定したディスク・グループごとに、ディスク・グループをこの記憶域の場所に追加し(すでにその場所に組み込まれている場合を除く)、リクエストされた領域の容量を記憶域の場所に追加します。サイズの指定がない場合、この記憶域の場所にはディスク・グループ内のすべての空き領域が割り当てられます。サイズを指定し、そのサイズがこのディスク・グループからすでに割り当てられている領域の容量を上回っている場合、この記憶域の場所には指定した記憶域の容量が割り当てられます。

この記憶域の場所に追加する新しいディスク・グループの割当て単位サイズは、この記憶域の場所にすでに割り当てられているディスク・グループと同じである必要があります。

この記憶域の場所にすでに追加されている既存のディスク・グループはすべて、このプロシージャの実行中に明示的に指定していない場合でも、この場所に割り当てられたままです。

このプロシージャは、記憶域の宛先に対する変更の処理に加えて、記憶域の場所が以前に作成または更新されたときに明示的なサイズなしに指定されたディスク・グループを再調査します。再調査されたディスク・グループのいずれかで追加の空き領域が使用できる場合、その領域が記憶域の場所に割り当てられます。

13 リカバリ・アプライアンスのビュー・リファレンス

リカバリ・アプライアンスの使用可能なビューについて説明します。

13.1 リカバリ・アプライアンスのビューのまとめ

表13-1 リカバリ・アプライアンスのビュー

リカバリ・アプライアンスのビュー

説明

RA_ACTIVE_SESSION

このビューには、リカバリ・アプライアンスで現在実行されているアクティブなクライアント・セッションに関する情報が表示されます。

RA_API_HISTORY

このビューには、ユーザーが発行したAPIコマンドの履歴が表示されます。

RA_CONFIG

このビューには、ユーザー構成設定が表示されます。

RA_DATABASE

このビューには、このリカバリ・アプライアンスによって保護されているデータベースが表示されます。

RA_DATABASE_STORAGE_USAGE

このビューには、保護されたデータベースごとの記憶域使用量が表示されます。

RA_DATABASE_SYNONYM

このビューには、保護されたデータベースとその等価の名前が表示されます。

RA_DB_ACCESS

このビューには、どのリカバリ・アプライアンス・ユーザー・アカウントがどの保護されたデータベースへのアクセス権を持っているかが表示されます。

RA_DISK_RESTORE_RANGE

このリカバリ・アプライアンスのディスク・バックアップからの保護された各データベースのリストア範囲。

RA_EM_SBT_JOB_TEMPLATE

このビューには、Oracle Enterprise Managerに定義済のSBTジョブとそのステータスが表示されます。

RA_INCIDENT_LOG

このビューには、リカバリ・アプライアンスのインシデントが表示されます。

RA_INCOMING_BACKUP_PIECES

このビューには、リカバリ・アプライアンスによって受信されているバックアップ・ピースが表示されます。

RA_POLLING_FILES

このビューには、リカバリ・アプライアンスによってポーリング位置からバックアップされたファイルが表示されます。

RA_POLLING_POLICY

このビューには、定義済のバックアップのポーリング・ポリシーが表示されます。

RA_PROTECTION_POLICY

このビューには、このリカバリ・アプライアンスに定義した保護ポリシーが表示されます。

RA_PURGING_QUEUE

このビューには、領域不足の場合に保護されたデータベースで最古のバックアップが削除される順序が表示されます。

RA_REPLICATION_SERVER

このビューには、レプリケーション・サーバー構成が表示されます。

RA_RESTORE_RANGE

このビューには、このリカバリ・アプライアンスの全バックアップからの保護された各データベースのリストア範囲が表示されます。

RA_SBT_ATTRIBUTE_SET

このビューには、定義済のSBT属性セットが表示されます。

RA_SBT_JOB

このビューには、定義済のSBTジョブ・テンプレートが表示されます。

RA_SBT_LIBRARY

このビューには、定義済のSBTライブラリが表示されます。

RA_SBT_RESTORE_RANGE

このビューには、リカバリ・アプライアンスのSBTバックアップからの各データベースのリストア範囲が表示されます。

RA_SBT_TASK

このビューには、キューに入っているバックグラウンドSBTタスクとその実行ステータスが表示されます。

RA_SBT_TEMPLATE_MDF

このビューには、各SBTテンプレートの欠落しているレベル0データファイル・バックアップが表示されます。

RA_SERVER

このビューには、リカバリ・アプライアンスの現在の設定が表示されます。

RA_STORAGE_HISTOGRAM

このビューには、最近の期間の記憶域の割当て履歴が表示されます。

RA_STORAGE_LOCATION

このビューには、定義済のリカバリ・アプライアンスの記憶域の場所とその割当てが表示されます。

RA_TASK

このビューには、キューに入っているバックグラウンド・タスクとその実行ステータスが表示されます。

RA_TIME_USAGE

このビューには、過去30日間のリカバリ・アプライアンスの経過時間とアイドル時間が表示されます。

13.2 RA_ACTIVE_SESSION

このビューには、リカバリ・アプライアンスで現在実行されているアクティブなクライアント・セッションに関する情報が表示されます。

列

データ型

NULL

説明

INST_ID

NUMBER

このセッションが実行されているリカバリ・アプライアンス・インスタンス番号。

INSTANCE_NAME

VARCHAR2(16)

このセッションが実行されているリカバリ・アプライアンス・インスタンス名。

HOST_NAME

VARCHAR2(64)

このセッションが実行されているリカバリ・アプライアンス・ホスト名。

SID

NUMBER

アクティブ・セッションのセッションID。

SERIAL#

NUMBER

セッション・シリアル番号(セッションのオブジェクトを一意に識別)。

SPID

VARCHAR2(24)

オペレーティング・システムのプロセス識別子。

DB_KEY

NUMBER

リカバリ・カタログ内のこのデータベースに対する主キー。

DB_UNIQUE_NAME

VARCHAR2(30)

一意のデータベース名。

SBT_SID

VARCHAR2(64)

SBTセッション識別子。

CLIENT_IDENTIFIER

VARCHAR2(64)

セッションのクライアント識別子。

MODULE

VARCHAR2(64)

現在実行中のモジュールの名前。

ACTION

VARCHAR2(64)

現在実行中のアクションの名前。

SQL_ID

VARCHAR2(13)

現在実行されているSQL文のSQL識別子。

EVENT

VARCHAR2(64)

セッションが待機しているリソースまたはイベント。

P1

NUMBER

第1待機イベント・パラメータ

P2

NUMBER

第2待機イベント・パラメータ。

P3

NUMBER

第3待機イベント・パラメータ。

WAIT_TIME

NUMBER

待機時間(1/100秒)。詳細は、V$SESSION.WAIT_TIMEの説明を参照してください。

SECONDS_IN_WAIT

NUMBER

待機時間(秒)。セッションが現在待機中の場合、値は現在の待機が開始されるまで待機した時間。セッションが待機中でない場合、値は直近の待機が開始されてからの時間。

STATE

VARCHAR2(19)

待機イベントの状態: WAITING、WAITED UNKNOWN TIME、WAITED SHORT TIME、WAITED KNOWN TIME。詳細は、V$SESSION.STATEの説明を参照してください。

TASK_ID

NUMBER

タスク識別子。

TASK_TYPE

VARCHAR2(30)

タスク・タイプ。

PRIORITY

NUMBER

タスク優先度。

TASK_STATE

VARCHAR2(13)

タスクの処理状態: EXECUTABLE、RUNNING、COMPLETED、TASK_WAIT, FAILEDなど。

JOB_NAME

VARCHAR2(128)

DBMS_SCHEDULERジョブの名前。

13.3 RA_API_HISTORY

このビューには、ユーザーが発行したAPIコマンドの履歴が表示されます。

列

データ型

NULL

説明

RESULTS

VARCHAR2(1000)

このコマンドの実行結果: SUCCESSまたはFAIL。

EXECUTE_TIME

TIMESTAMP(6)WITH TIME ZONE

コマンドの開始時刻。

TASK_NAME

VARCHAR2(30)

タスクの名前。

COMMAND_ISSUED

VARCHAR2(4000)

ユーザーが発行した完全なコマンド。

ELAPSED_SECONDS

NUMBER

タスクの実行経過時間(秒)。

13.4 RA_CONFIG

このビューには、ユーザー構成設定が表示されます。

列

データ型

NULL

説明

NAME

VARCHAR2(30)

NOT NULL

構成変数の名前。変数の定義とデフォルト値については、「RA_CONFIG」を参照してください。

VALUE

VARCHAR2(100)

構成変数の値

13.5 RA_DATABASE

このビューには、このリカバリ・アプライアンスによって保護されているデータベースが表示されます。

列

データ型

NULL

説明

DB_UNIQUE_NAME

VARCHAR2(32)

この保護されたデータベースの一意の名前。

DB_KEY

NUMBER

リカバリ・アプライアンス・メタデータ・データベースでのこのデータベースの主キー。

DELETING

VARCHAR2(7)

YES: このデータベースが現在削除されている場合。

DBID

NUMBER

この保護されたデータベースのDBID。

CREATION_TIME

TIMESTAMP(6)WITH TIME ZONE

このデータベースがリカバリ・アプライアンスに追加された時刻。

POLICY_NAME

VARCHAR2(128)

このデータベースで使用される保護ポリシーの名前。

STORAGE_LOCATION

VARCHAR2(128)

この保護されたデータベースで使用されるリカバリ・アプライアンスの記憶域の場所の名前。

RECOVERY_WINDOW_GOAL

INTERVAL DAY(9) TO SECOND(6)

保護ポリシーに指定されている、ディスク上のバックアップのリカバリ・ウィンドウ目標。

MAX_RETENTION_WINDOW

INTERVAL DAY(9) TO SECOND(6)

ディスク・バックアップを保持する最大時間。このウィンドウより古くなると、ディスク・バックアップが削除されます。ただし、バックアップの削除によってrecovery_window_goal要件が悪影響を受ける場合は、保持期間を長くできます。

RECOVERY_WINDOW_SBT

INTERVAL DAY(9) TO SECOND(6)

保護ポリシーに指定されている、テープ上のバックアップのリカバリ・ウィンドウ。

TIMEZONE

VARCHAR2(64)

保護されたデータベースのタイムゾーン・オフセット。

SPACE_USAGE

NUMBER

この保護されたデータベースで現在使用されているディスク領域の容量(GB)。

KEEP_SPACE

NUMBER

データベースのKEEPバックアップを保持するために使用される領域。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

DISK_RESERVED_SPACE

NUMBER

このデータベースが排他的に使用するために予約されたディスク領域の容量(GB)

GUARANTEED_COPY

VARCHAR2(3)

保証付きコピー設定のステータス: YESは、削除前にバックアップがレプリケートされるか、テープにコピーされることを意味し、NOは、空き領域が少ないため古いバックアップのパージが必要な場合でも、新しいバックアップが受け入れられることを意味します。

CUMULATIVE_USAGE

NUMBER

このデータベース用に予約され、すべてのバックアップに割り当てられたディスク領域の累積容量(GB)。

REPLICATION_USAGE

NUMBER

この保護されたデータベース用にレプリケートされたディスク領域の累積容量(GB)。

SBT_USAGE

NUMBER

この保護されたデータベースからSBTに送信されたディスク領域の累積容量(GB)。

REPLICATION_SETUP_STATUS

VARCHAR2(7)

このデータベースのダウンストリーム・レプリケーション・アプライアンスに対する設定のステータス。

LAST_OPTIMIZE

TIMESTAMP(6)WITH TIME ZONE

直近のデータ配置最適化が完了した時刻。

LAST_VALIDATE

TIMESTAMP(6)WITH TIME ZONE

直近のバックアップ・データの検証が完了した時刻。

LAST_CROSSCHECK

TIMESTAMP(6)WITH TIME ZONE

直近のバックアップ・データのクロスチェックが完了した時刻。

STORAGE_LOCATION_COUNT

NUMBER

このデータベースで使用される記憶域の場所の数。複数の場合、このデータベースについて記憶域の場所の移動操作が進行中です。

STORAGE_MOVEMENT_PHASE

VARCHAR2(18)

この保護されたデータベースに対する記憶域の場所の移動操作のフェーズ。

SIZE_ESTIMATE

NUMBER

保護されたデータベース全体で消費される推定領域(GB)。

RECOVERY_WINDOW_SPACE

NUMBER

リカバリ・ウィンドウ目標を満たすのに必要な推定領域(GB)。

RESTORE_WINDOW

INTERVAL DAY(9) TO SECOND(9)

RECOVERY_WINDOW_SPACEの値の計算に使用される時間範囲。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

DEDUPLICATION_FACTOR

NUMBER

この保護されたデータベースのアプライアンスで実際に消費された領域に対する、仮想完全バックアップの合計サイズの比率。

MINIMUM_RECOVERY_NEEDED

INTERVAL DAY(9) TO SECOND(9)

保護されたデータベースを現在までリストアするのに必要な最小間隔。

UNPROTECTED_WINDOW_THRESHOLD

INTERVAL DAY(9) TO SECOND(6)

保護ポリシーの管理下にある保護されたデータベースのユーザー定義の最大データ損失量。このデータベースの保護されていないウィンドウがこの値を超えると、アラートが生成されます。

UNPROTECTED_WINDOW

INTERVAL DAY(9) TO SECOND(9)

追加REDOが使用できないかぎり、リカバリが不可能になるポイント。

NZDL_ACTIVE

VARCHAR2(3)

YES: リアルタイムREDOトランスポートがアクティブの場合。NO: REDOが最近受信されていない場合。

ALLOW_BACKUP_DELETION

VARCHAR2(3)

この保護ポリシーを使用するデータベースのRMANバックアップを削除できるかどうかを制御する設定です。NOはリカバリ・アプライアンスではこのようなバックアップの削除を許可しないことを表し、YESはこのようなバックアップの削除を許可することを表します。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.7以上でのみ使用可能です。

STORE_AND_FORWARD

VARCHAR2(3)

バックアップおよびREDOフェイルオーバー設定のステータス: YESは、この保護ポリシーに関連付けられたデータベースからバックアップするバックアップおよびREDOフェイルオーバー計画に、リカバリ・アプライアンスが適用されることを意味します。NOは、バックアップおよびREDOフェイルオーバー機能が有効化されず、かわりに、リカバリ・アプライアンスが通常の永久的増分バックアップ計画に適用されることを意味します。

この設定はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

13.6 RA_DATABASE_STORAGE_USAGE

このビューには、保護されたデータベースごとの記憶域使用量が表示されます。

列

データ型

NULL

説明

DB_UNIQUE_NAME

VARCHAR2(30)

保護されたデータベースの一意の名前。

DB_KEY

NUMBER

リカバリ・アプライアンス・メタデータ・データベースでのこの保護されたデータベースの主キー。

STORAGE_LOCATION

VARCHAR2(128)

NOT NULL

この保護されたデータベースで使用されるリカバリ・アプライアンスの記憶域の場所の名前。

USED_SPACE

NUMBER

リカバリ・アプライアンスの記憶域の場所でこのデータベースによって使用される領域の容量(GB)。保護されたデータベースのバックアップは通常、1つの記憶域の場所にのみ存在しますが、移動操作が進行中の場合、2つの場所に存在することがあります。

13.7 RA_DATABASE_SYNONYM

このビューには、保護されたデータベースとその等価の名前が表示されます。

列

データ型

NULL

説明

DB_UNIQUE_NAME

VARCHAR2(512)

保護されたデータベースの一意の名前。

DBID

NUMBER

このデータベースと同等であるすべての保護されたデータベースに対するDBID。

13.8 RA_DB_ACCESS

このビューには、どのリカバリ・アプライアンス・ユーザー・アカウントがどの保護されたデータベースへのアクセス権を持っているかが表示されます。

列

データ型

NULL

説明

USERNAME

VARCHAR2(128)

NOT NULL

リカバリ・アプライアンス・ユーザー・アカウントの名前。

DB_UNIQUE_NAME

VARCHAR2(32)

リカバリ・アプライアンス・ユーザー・アカウントがアクセスする保護されたデータベースの一意の名前。

DB_KEY

NUMBER

リカバリ・アプライアンス・ユーザー・アカウントがアクセスする保護されたデータベースの主キー。

13.9 RA_DISK_RESTORE_RANGE

このリカバリ・アプライアンスのディスク・バックアップからの保護された各データベースのリストア範囲。

列

データ型

NULL

説明

DB_KEY

NUMBER

保護されたデータベースの主キー。

LOW_TIME

DATE

保護されたデータベースのリストアが可能な最も古い時点。

HIGH_TIME

DATE

保護されたデータベースのリストアが可能な最も新しい時点。

LOW_SCN

NUMBER

保護されたデータベースのリストアが可能な最も小さいSCN。

HIGH_SCN

NUMBER

保護されたデータベースのリストアが可能な最も大きいSCN。

LOW_DBINC_KEY

NUMBER

LOW_SCNが属しているターゲット・データベースのインカネーションに対する主キー。

HIGH_DBINC_KEY

NUMBER

HIGH_SCNが属しているターゲット・データベースのインカネーションに対する主キー。

LAST_UPDATED

DATE

この保護されたデータベースのリストア範囲が更新された時刻。

13.10 RA_EM_SBT_JOB_TEMPLATE

このビューには、Oracle Enterprise Managerに定義済のSBTジョブとそのステータスが表示されます。

列

データ型

NULL

説明

TEMPLATE_NAME

VARCHAR2(128)

NOT NULL

SBTジョブ・テンプレートの名前。

FULL_TEMPLATE_NAME

VARCHAR2(128)

NOT NULL

SBTジョブ・テンプレートの完全名。

POLICY_NAME

VARCHAR2(128)

バックアップがコピー対象と見なされている保護されたデータベースを指定している保護ポリシー。

DB_UNIQUE_NAME

VARCHAR2(512)

バックアップがコピー対象と見なされている保護されたデータベースの一意の名前。

ATTRIBUTE_SET_NAME

VARCHAR2(128)

NOT NULL

SBT属性セットの名前。

LIB_NAME

VARCHAR2(128)

NOT NULL

SBTライブラリの名前。

BACKUP_TYPE

VARCHAR2(16)

このジョブでテープにコピーされるバックアップのタイプ: ALL、FULL、INCR、ARCHまたはTAPE_RESERVE。

PRIORITY

NUMBER

このジョブをスケジュールするための優先度。

COPIES

NUMBER

NOT NULL

テープに作成されるコピー数。

WINDOW

INTERVAL DAY(2) TO SECOND(6)

このジョブに対するコピー・タスクの開始に割り当てられた時間。

FROM_TAG

VARCHAR2(32)

このジョブでテープにコピーされるバックアップのタグ。

ERROR_TEXT

VARCHAR2(4000)

失敗したタスク用のエラー・テキスト。

ERROR_LAST_SEEN

TIMESTAMP(6)WITH TIME ZONE

直近にエラーが検出されたときのタイムスタンプ。

EXECUTABLE

NUMBER

実行可能状態のタスクの数。

RUNNING

NUMBER

実行中または再試行中のタスクの数。

COMPLETED

NUMBER

完了したタスクの数。

COMPLETION_TIME

TIMESTAMP(6)WITH TIME ZONE

直近の完了したタスクの時刻。

STATUS

VARCHAR2(5)

SBTライブラリのステータス: READY、PAUSEまたはERROR。

BYTES

NUMBER

これまでの読取りまたは書込みバイト数。

COMPRESSION_ALGORITHM

VARCHAR2(6)

このジョブによって使用される圧縮アルゴリズム: NONE、BASIC、LOW、MEDIUMまたはHIGH。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

13.11 RA_INCIDENT_LOG

このビューには、リカバリ・アプライアンスのインシデントが表示されます。

列

データ型

NULL

説明

INCIDENT_ID

NUMBER

インシデントの一意のID。

ERROR_CODE

NUMBER

インシデントを説明するメッセージのOracleエラー・コード。

PARAMETER

VARCHAR2(1000)

エラー・コードの範囲を限定するパラメータ。

ERROR_TEXT

VARCHAR2(4000)

このエラー状況の最終検出に対するメッセージ・テキスト。

SL_KEY

NUMBER

このインシデントに含まれる記憶域の場所の主キー(ある場合)

SL_NAME

VARCHAR2(128)

このインシデントに含まれるリカバリ・アプライアンスの記憶域の場所の主キー(ある場合)。

DB_KEY

NUMBER

このインシデントに含まれる保護されたデータベースの主キー(ある場合)。

DB_UNIQUE_NAME

VARCHAR2(30)

このインシデントに含まれる保護されたデータベースの一意の名前(ある場合)。

TASK_ID

NUMBER

このインシデントが検出されたタスクのID (ある場合)。

STATUS

VARCHAR2(6)

このインシデントのステータス: ACTIVE、FIXEDまたはRESET。

COMPONENT

VARCHAR2(30)

このインシデントを検出しているリカバリ・アプライアンスのコンポーネント。

SEVERITY

VARCHAR2(47)

リカバリ・アプライアンスの円滑な操作に対するこのインシデントの重要性。

FIRST_SEEN

TIMESTAMP(6)WITH TIME ZONE

NOT NULL

最初にインシデントが検出されたときのタイムスタンプ。

LAST_SEEN

TIMESTAMP(6)WITH TIME ZONE

NOT NULL

直近にインシデントが検出されたときのタイムスタンプ。

SEEN_COUNT

NUMBER

NOT NULL

インシデントが検出された回数。

13.12 RA_INCOMING_BACKUP_PIECES

このビューには、リカバリ・アプライアンスによって受信されているバックアップ・ピースが表示されます。

列

データ型

NULL

説明

SL_KEY

NUMBER

このバックアップ・ピースを格納するリカバリ・アプライアンスの記憶域の場所の主キー。

SL_NAME

VARCHAR2(128)

このバックアップ・ピースを格納するリカバリ・アプライアンスの記憶域の場所の名前。

DB_KEY

NUMBER

このバックアップ・ピースを作成する保護されたデータベースの主キー。

DB_UNIQUE_NAME

VARCHAR2(30)

このバックアップ・ピースを作成する保護されたデータベースの一意の名前。

HANDLE

VARCHAR2(1024)

このバックアップ・ピースに割り当てられたハンドル。

CURRENT_SIZE

NUMBER

このバックアップ・ピースに現在割り当てられているサイズ(GB)。

START_TIME

TIMESTAMP(6)WITH TIME ZONE

バックアップ・ピースがリカバリ・アプライアンスによって最初に確認された時間。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

LAST_UPDATE

TIMESTAMP(6)WITH TIME ZONE

バックアップ・ピースを完全に受信した時刻。

13.13 RA_POLLING_FILES

このビューには、構成済のポーリング位置からリカバリ・アプライアンスによってバックアップされたファイルのセットが表示されます。

このビューはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

列

データ型

NULL

説明

POLL_NAME

VARCHAR2(128)

ポーリング・ポリシーの名前。

POLL_KEY

NUMBER

NOT NULL

ポーリング・ポリシーの一意の識別子。

FILE_NAME

VARCHAR2(512)

構成済のポーリング位置で検出されたファイルの名前。

FILE_SIZE

NUMBER

ポーリング位置で前回スキャンされたときのファイルのサイズ。

STATUS

VARCHAR2(24)

ファイルの処理の現在の状態。

13.14 RA_POLLING_POLICY

このビューには、定義済のバックアップのポーリング・ポリシーが表示されます。

列

データ型

NULL

説明

POLLING_NAME

VARCHAR2(128)

このバックアップのポーリング・ポリシーの名前。

POLLING_KEY

NUMBER

NOT NULL

リカバリ・カタログでのこのバックアップのポーリング・ポリシーに対する主キー。

DEST

VARCHAR2(4000)

NOT NULL

バックアップのポーリング位置に対応するファイル・システム・ディレクトリ。

FREQUENCY

INTERVAL DAY(9) TO SECOND(6)

バックアップのポーリング位置で新しいファイルがスキャンされる間隔。

NEXT_EXECUTE

TIMESTAMP(6)WITH TIME ZONE

ポーリング位置が次にスキャンされる時刻。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

DELETE_INPUT

VARCHAR2(5)

ポーリング位置の削除ポリシー: TRUEの場合は受け入れられるとファイルを削除し、FALSEの場合はすべてのファイルを保持します。

13.15 RA_PROTECTION_POLICY

このビューには、このリカバリ・アプライアンスに定義した保護ポリシーが表示されます。

列

データ型

NULL

説明

POLICY_NAME

VARCHAR2(128)

NOT NULL

保護ポリシーのユーザーが作成した名前。

DESCRIPTION

VARCHAR2(128)

保護ポリシーの説明。

PROT_KEY

NUMBER

NOT NULL

リカバリ・アプライアンス・メタデータ・データベースでのこの保護ポリシーの主キー。

SL_NAME

VARCHAR2(128)

NOT NULL

この保護ポリシーで使用されるリカバリ・アプライアンスの記憶域の場所の名前。

SL_KEY

NUMBER

NOT NULL

この保護ポリシーで使用されるリカバリ・アプライアンスの記憶域の場所の主キー。

POLLING_NAME

VARCHAR2(128)

この保護ポリシーに割り当てられたバックアップのポーリング・ポリシーの名前。

RECOVERY_WINDOW_GOAL

INTERVAL DAY(9) TO SECOND(6)

ディスクに格納されたバックアップをリストアするためのリカバリ・ウィンドウ目標。

MAX_RETENTION_WINDOW

INTERVAL DAY(9) TO SECOND(6)

リカバリ・アプライアンスでディスク・バックアップを保持する必要がある最大時間。

RECOVERY_WINDOW_SBT

INTERVAL DAY(9) TO SECOND(6)

テープに格納されたバックアップをリストアするためのリカバリ・ウィンドウ。

UNPROTECTED_WINDOW

INTERVAL DAY(9) TO SECOND(6)

追加REDOが使用できないかぎり、リカバリが不可能になるポイント。

GUARANTEED_COPY

VARCHAR2(3)

保証付きコピー設定のステータス: YESは、削除前にバックアップがレプリケートされるか、テープにコピーされることを意味し、NOは、空き領域が少ないため古いバックアップのパージが必要な場合でも、新しいバックアップが受け入れられることを意味します。

REPLICATION_SERVER_LIST

VARCHAR2(4000)

この保護ポリシーに関連付けられたレプリケーション・サーバー構成のリスト。

ALLOW_BACKUP_DELETION

VARCHAR2(3)

この保護ポリシーを使用するデータベースのRMANバックアップを削除できるかどうかを制御する設定です。NOはリカバリ・アプライアンスではこのようなバックアップの削除を許可しないことを表し、YESはこのようなバックアップの削除を許可することを表します。

このパラメータはZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.7以上でのみ使用可能です。

STORE_AND_FORWARD

VARCHAR2(3)

バックアップおよびREDOフェイルオーバー設定のステータス: YESは、この保護ポリシーに関連付けられたデータベースからバックアップするバックアップおよびREDOフェイルオーバー計画に、リカバリ・アプライアンスが適用されることを意味します。NOは、バックアップおよびREDOフェイルオーバー機能が有効化されず、かわりに、リカバリ・アプライアンスが通常の永久的増分バックアップ計画に適用されることを意味します。

この設定はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

13.16 RA_PURGING_QUEUE

このビューには、領域不足の場合に保護されたデータベースで最古のバックアップが削除される順序が表示されます。

列

データ型

NULL

説明

SL_NAME

VARCHAR2(128)

NOT NULL

リカバリ・アプライアンスの記憶域の場所の名前。

SL_KEY

NUMBER

リカバリ・カタログでのこのリカバリ・アプライアンスの記憶域の場所に対する主キー。

DB_UNIQUE_NAME

VARCHAR2(30)

バックアップがパージされる保護されたデータベースの一意の名前。

DB_KEY

NUMBER

NOT NULL

バックアップがパージされる保護されたデータベースの主キー。

PURGE_ORDER

NUMBER

この保護されたデータベースがパージ対象となる順序。

NEW_RECOVERY_WINDOW

INTERVAL DAY(9) TO SECOND(6)

パージ後の、この保護されたデータベースのリカバリ・ウィンドウ目標。

NEW_PCT_RECOVERY

NUMBER

パージ後の、この保護されたデータベースに残っているリカバリ・ウィンドウ目標の割合。

PCT_STORAGE

NUMBER

この保護されたデータベースによって消費されている予約領域の割合。

13.17 RA_REPLICATION_SERVER

このビューには、レプリケーション・サーバー構成が表示されます。

列

データ型

NULL

説明

REPLICATION_SERVER_NAME

VARCHAR2(128)

NOT NULL

レプリケーション・サーバー構成のユーザーが割り当てた名前。

REPLICATION_SERVER_STATE

VARCHAR2(21)

ダウンストリーム・リカバリ・アプライアンスのレプリケーション・ステータス: AVAILABLE、CREATING、DELETING、TESTING COMMUNICATIONまたはnull。

PROTECTION_POLICY

VARCHAR2(128)

このレプリケーション・サーバー構成に関連付けられた保護ポリシー。

REP_SERVER_CONNECT_NAME

VARCHAR2(128)

NOT NULL

ダウンストリーム・リカバリ・アプライアンスへの接続に使されるユーザー名。

PROXY_HTTP_ADDRESS

VARCHAR2(519)

proxy_server_http_address:port_of_proxy_server形式のプロキシ・サーバーのアドレス。

PROXY_TIMEOUT

NUMBER

プロキシ・サーバー接続のタイムアウト期間。

SBT_LIBRARY_NAME

VARCHAR2(128)

NOT NULL

このレプリケーション・サーバー構成が関連付けられるSBTライブラリの名前。

SBT_LIBRARY_PARMS

VARCHAR2(1024)

SBTライブラリのパラメータ。

ATTRIBUTE_NAME

VARCHAR2(128)

NOT NULL

SBT属性セット名。

ATTRIBUTE_PARMS

VARCHAR2(1024)

RMANチャネルの割当時に渡されるSBTパラメータ。

WALLET_PATH

VARCHAR2(512)

ローカルOracleウォレットのパス(ウォレット・ファイル名を除く)。

WALLET_ALIAS

VARCHAR2(512)

NOT NULL

ダウンストリーム・リカバリ・アプライアンスへのログインにこのリカバリ・アプライアンスによって使用されるOracleウォレット資格証明を識別する別名。

SERVER_HOST

CLOB

NOT NULL

ダウンストリーム・リカバリ・アプライアンスのサーバー名またはアドレス。

MAX_STREAMS

NUMBER

最大同時レプリケーション・タスク数。各レプリケーション・タスクは単一のバックアップ・ピースを処理します。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

13.18 RA_RESTORE_RANGE

このビューには、このリカバリ・アプライアンスの全バックアップからの保護された各データベースのリストア範囲が表示されます。

列

データ型

NULL

説明

DB_KEY

NUMBER

保護されたデータベースの主キー。

LOW_TIME

DATE

保護されたデータベースのリストアが可能な最も古い時点。

HIGH_TIME

DATE

保護されたデータベースのリストアが可能な最も新しい時点。

LOW_SCN

NUMBER

データベースのリストアが可能な最も小さなSCN。

HIGH_SCN

NUMBER

保護されたデータベースのリストアが可能な最も大きいSCN。

LOW_DBINC_KEY

NUMBER

小さいSCNが属しているターゲット・データベースのインカネーションに対する主キー。

HIGH_DBINC_KEY

NUMBER

大きいSCNが属しているターゲット・データベースのインカネーションに対する主キー。

LAST_UPDATED

DATE

このデータベースのリストア範囲が更新された時刻。

13.19 RA_SBT_ATTRIBUTE_SET

このビューには、定義済のSBT属性セットが表示されます。

列

データ型

NULL

説明

ATTRIBUTE_SET_KEY

NUMBER

NOT NULL

リカバリ・アプライアンス・メタデータ・データベースに設定されたこのSBT属性のキー。

ATTRIBUTE_SET_NAME

VARCHAR2(128)

NOT NULL

SBT属性セット名。

LIB_NAME

VARCHAR2(128)

NOT NULL

この属性セットが関連付けられるSBTライブラリ・オブジェクトの名前。

STREAMS

NUMBER

この属性セットを使用して実行されるジョブに使用可能なパラレル・ストリームの数。

POOLID

NUMBER

メディア・プール識別子。

PARMS

VARCHAR2(1024)

RMANチャネルの割当時に渡されるSBTパラメータ。

SEND

VARCHAR2(1024)

割り当てられたチャネルに渡されるSENDコマンド文字列。

13.20 RA_SBT_JOB

このビューには、定義済のSBTジョブ・テンプレートが表示されます。

列

データ型

NULL

説明

TEMPLATE_KEY

NUMBER

NOT NULL

リカバリ・アプライアンス・メタデータ・データベースでのこのSBTジョブ・テンプレートのキー。

TEMPLATE_NAME

VARCHAR2(128)

NOT NULL

SBTジョブ・テンプレート名。

ATTRIBUTE_SET_NAME

VARCHAR2(128)

NOT NULL

SBT属性セット名。

LIB_NAME

VARCHAR2(128)

NOT NULL

SBTライブラリ名。

POLICY_NAME

VARCHAR2(128)

バックアップがテープへのコピー対象と見なされているデータベースを指定している保護ポリシー。

DB_KEY

NUMBER

バックアップがテープへのコピー対象と見なされている保護されたデータベースの主キー。

DB_UNIQUE_NAME

VARCHAR2(30)

バックアップがテープへのコピー対象と見なされている保護されたデータベースの一意の名前。

BACKUP_TYPE

VARCHAR2(16)

このジョブでテープにコピーされるバックアップのタイプ: ALL、FULL、INCR、ARCHまたはTAPE_RESERVE。

FROM_TAG

VARCHAR2(32)

このジョブでテープにコピーされる、指定されたタグがあるバックアップ。

PRIORITY

NUMBER

このジョブをスケジュールするための優先度。

COPIES

NUMBER

NOT NULL

テープに作成されるコピー数。

LAST_SCHEDULE_TIME

TIMESTAMP(6)WITH TIME ZONE

このSBTジョブの実行がスケジュールされた最終の時刻。

WINDOW

INTERVAL DAY(2) TO SECOND(6)

このジョブに対するコピー・タスクの開始に割り当てられた時間。

COMPRESSION_ALGORITHM

VARCHAR2(6)

このジョブによって使用される圧縮アルゴリズム: NONE、BASIC、LOW、MEDIUM、HIGHまたはOFF。

OFFは、このジョブに対して圧縮が明示的に無効化されたことを示します(SBTジョブ・テンプレートの圧縮設定は無視されました)。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

13.21 RA_SBT_LIBRARY

このビューには、定義済のSBTライブラリが表示されます。

列

データ型

NULL

説明

LIB_KEY

NUMBER

NOT NULL

リカバリ・アプライアンス・メタデータ・データベースでのこのSBTライブラリのキー。

LIB_NAME

VARCHAR2(128)

NOT NULL

SBTライブラリ名。

DRIVES

NUMBER

NOT NULL

このSBTライブラリで使用できるドライブの数。

RESTORE_DRIVES

NUMBER

NOT NULL

リストア操作用に予約されたドライブの数。

PARMS

VARCHAR2(1024)

RMANチャネルの割当時に渡されるSBTパラメータ。

SEND

VARCHAR2(1024)

割り当てられたチャネルに渡されるSENDコマンド文字列。

STATUS

VARCHAR2(5)

SBTライブラリのステータス: READY、PAUSE、ERRORまたはnull。

LAST_ERROR_TEXT

VARCHAR2(4000)

失敗したタスクの最新のエラー・テキスト。

13.22 RA_SBT_RESTORE_RANGE

このビューには、リカバリ・アプライアンスのSBTバックアップからの各データベースのリストア範囲が表示されます。

列

データ型

NULL

説明

DB_KEY

NUMBER

保護されたデータベースの主キー。

LOW_TIME

DATE

データベースのリストアが可能な最も古い時点。

HIGH_TIME

DATE

データベースのリストアが可能な最も新しい時点。

LOW_SCN

NUMBER

データベースのリストアが可能な最も小さなSCN。

HIGH_SCN

NUMBER

データベースのリストアが可能な最も大きなSCN。

LOW_DBINC_KEY

NUMBER

小さいSCNが属しているターゲット・データベースのインカネーションに対する主キー。

HIGH_DBINC_KEY

NUMBER

大きいSCNが属しているターゲット・データベースのインカネーションに対する主キー。

LAST_UPDATED

DATE

この保護されたデータベースのリストア範囲が最終更新された時刻。

13.23 RA_SBT_TASK

このビューには、キューに入っているバックグラウンドSBTタスクとその実行ステータスが表示されます。

列

データ型

NULL

説明

TASK_ID

NUMBER

タスクのID。

STATE

VARCHAR2(47)

タスクの処理状態: EXECUTABLE、RUNNING、COMPLETED、TASK_WAIT, FAILEDなど。

COMPLETION_TIME

TIMESTAMP(6)WITH TIME ZONE

タスク完了のタイムスタンプ。タスクが完了していない場合、この列はnullです。

ELAPSED_SECONDS

NUMBER

タスクの実行経過時間(秒)。

EXECUTE_INSTANCE_ID

NUMBER

タスクを実行する必要があるデータベース・インスタンスのID。どのインスタンスででもタスクを実行できる場合、この列はnullです。

ERROR_COUNT

NUMBER

タスクにエラーが発生した回数。

ERROR_TEXT

VARCHAR2(4000)

失敗したタスク用のエラー・テキスト。

DB_UNIQUE_NAME

VARCHAR2(30)

タスクが実行される保護されたデータベースの一意の名前。

DB_KEY

NUMBER

タスクが実行される保護されたデータベースの主キー。

RESTORE_TASK

VARCHAR2(3)

タスクのタイプ: リストア・タスクの場合はYES、バックアップ・タスクの場合はNO。

BS_KEY

NUMBER

このタスクでアクセスされるバックアップ・セットのキー。

PIECE#

NUMBER

このタスクでアクセスされるバックアップ・ピースの番号。

COPIES

NUMBER

このタスクで作成されるコピーの数。

TEMPLATE_NAME

VARCHAR2(128)

このタスクが属するSBTジョブ・テンプレート。

ATTRIBUTE_SET_NAME

VARCHAR2(128)

このタスクが属するSBT属性セットの名前。

LIB_NAME

VARCHAR2(128)

NOT NULL

このタスクで使用されるSBTライブラリの名前。

REPLICATION

VARCHAR2(3)

タスクのタイプ: レプリケーション・タスクの場合はYES、SBTタスクの場合はNO。

FILENAME

VARCHAR2(513)

読取りまたは書込みが行われているバックアップ・ファイル名。

START_TIME

TIMESTAMP(6)WITH TIME ZONE

このタスクの開始時刻。

BYTES

NUMBER

これまでの読取りまたは書込みバイト数。

TOTAL

NUMBER

読取りまたは書込みバイト数の合計。

COMPRESSION_ALGORITHM

VARCHAR2(6)

このタスクによって使用される圧縮アルゴリズム: NONE、BASIC、LOW、MEDIUM、HIGHまたはOFF。

OFFは、このタスクに対して圧縮が明示的に無効化されたことを示します(SBTジョブ・テンプレートの圧縮設定は無視されました)。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

13.24 RA_SBT_TEMPLATE_MDF

このビューには、各SBTテンプレートの欠落しているレベル0データファイル・バックアップが表示されます。

列

データ型

NULL

説明

TEMPLATE_KEY

NUMBER

NOT NULL

SBTテンプレートを識別するキー。

DB_KEY

NUMBER

NOT NULL

欠落しているファイルが含まれる保護されたデータベースのキー。

DB_UNIQUE_NAME

VARCHAR2(30)

欠落しているデータファイルが含まれるデータベースの一意の名前。

DF_FILE#

NUMBER

欠落しているデータファイルの番号。

DF_TS#

NUMBER

欠落しているデータファイルの表領域番号。

DF_PLUGIN_CHANGE#

NUMBER

欠落しているデータファイルに対するプラグインSCN。

DF_FOREIGN_DBID

NUMBER

欠落しているデータファイルが含まれるデータベースに対する外部DBID。

DF_TABLESPACE

VARCHAR2(30)

欠落しているデータファイルが含まれる表領域。

DF_CREATION_CHANGE#

NUMBER

欠落しているデータファイルに対する作成SCN。

13.25 RA_SERVER

このビューには、リカバリ・アプライアンスの現在の設定が表示されます。

列

データ型

NULL

説明

STATE

VARCHAR2(10)

リカバリ・アプライアンスの状態: リカバリ・アプライアンスが実行中の場合はON、アクティブでない場合はOFF。

NETWORK_CHUNKSIZE

NUMBER

リカバリ・アプライアンスとの通信にリカバリ・アプライアンスのクライアント・モジュールで使用されるネットワーク・メッセージのサイズ(MB)。

SCHEDULERS

NUMBER

リカバリ・アプライアンスで現在実行されている通常のスケジューラの数。この数には、テープ、レプリケーション、purge_immediateまたはリストア操作に使用する特別な目的のスケジューラは含まれていません。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

RESOURCE_WAIT_TASK_LIMIT

VARCHAR2(48)

リソース待機に起因するタスク同時実行性の制限。

13.26 RA_STORAGE_HISTOGRAM

このビューには、最近の期間の記憶域の割当て履歴が表示されます。

列

データ型

NULL

説明

NAME

VARCHAR2(128)

NOT NULL

リカバリ・アプライアンスの記憶域の場所の名前。

SL_KEY

NUMBER

NOT NULL

リカバリ・カタログでのこのリカバリ・アプライアンスの記憶域の場所に対する主キー。

SLOT

NUMBER

ヒストグラムのスロット(サンプリング期間の順)。

USAGE

NUMBER

ヒストグラム・スロットで割り当てられた領域の容量(GB)。

13.27 RA_STORAGE_LOCATION

このビューには、定義済のリカバリ・アプライアンスの記憶域の場所とその割当てが表示されます。

列

データ型

NULL

説明

NAME

VARCHAR2(128)

NOT NULL

リカバリ・アプライアンスの記憶域の場所の名前。

SL_KEY

NUMBER

NOT NULL

リカバリ・カタログでのこのリカバリ・アプライアンスの記憶域の場所に対する主キー。

DISK_GROUPS

VARCHAR2(4000)

記憶域に使用されるOracle ASMディスク・グループの名前のリスト。

MIN_ALLOC

NUMBER

割当て可能な記憶域の最小容量(GB)。

TOTAL_SPACE

NUMBER

リカバリ・アプライアンスの記憶域の場所でバックアップ・データに使用できる記憶域の最大容量(GB)。

USED_SPACE

NUMBER

リカバリ・アプライアンスの記憶域の場所で現在使用されている領域の容量(GB)。

FREESPACE

NUMBER

即時使用可能な領域の容量(GB)。

FREESPACE_GOAL

NUMBER

使用量の履歴に基づいて予測された空き容量の要件(GB)。この目標を満たすためにパージが発生することがあります。

LAST_CHECK_FILES

TIMESTAMP(6)WITH TIME ZONE

ファイルの一貫性チェックが行われた最新時刻。

SYSTEM_PURGING_SPACE

NUMBER

パージ操作用に予約された領域の容量(GB)。

13.28 RA_TASK

このビューには、キューに入っているバックグラウンド・タスクとその実行ステータスが表示されます。

列

データ型

NULL

説明

TASK_ID

NUMBER

タスクのID。

TASK_TYPE

VARCHAR2(30)

タスクで実行される処理のタイプ。

PRIORITY

NUMBER

タスクの実行優先度。

STATE

VARCHAR2(47)

タスクの処理状態: EXECUTABLE、RUNNING、COMPLETED、TASK_WAIT, FAILEDなど。

WAITING_ON

NUMBER

状態がTASK_WAITのとき、このタスクをブロックしているタスクのID。

CREATION_TIME

TIMESTAMP(6)WITH TIME ZONE

タスクの作成時刻。

COMPLETION_TIME

TIMESTAMP(6)WITH TIME ZONE

タスク完了のタイムスタンプ。タスクが完了していない場合、この列はnullです。

ELAPSED_SECONDS

NUMBER

タスクの実行経過時間(秒)。

ERROR_COUNT

NUMBER

タスクにエラーが発生した回数

INTERRUPT_COUNT

NUMBER

タスクが中断された回数。

LAST_INTERRUPT_TIME

TIMESTAMP(6)WITH TIME ZONE

タスクが中断された最新時刻。

EXECUTE_INSTANCE_ID

NUMBER

タスクを実行する必要があるデータベース・インスタンスのID。どのインスタンスででもタスクを実行できる場合、この列はnullです。

LAST_EXECUTE_TIME

TIMESTAMP(6)WITH TIME ZONE

タスクが再起動された最新時刻。

DB_UNIQUE_NAME

VARCHAR2(30)

タスクが実行される保護されたデータベースの一意の名前。

DB_KEY

NUMBER

タスクが実行される保護されたデータベースの主キー。

SL_NAME

VARCHAR2(128)

タスクで使用されるリカバリ・アプライアンスの記憶域の場所の名前。

SL_KEY

NUMBER

タスクで使用されるリカバリ・アプライアンスの記憶域の場所の主キー。

OSPID

VARCHAR2(128)

タスクが現在実行されているプロセスのプラットフォーム固有のID。

INSTANCE_ID

NUMBER

タスクが現在実行されているデータベース・インスタンスのID。

LAST_INCIDENT_ID

NUMBER

現在実行されているタスクによってレポートされた最後のインシデントのID。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

BP_KEY

NUMBER

このタスクでアクセスされるバックアップ・ピースのキー。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

BS_KEY

NUMBER

このタスクでアクセスされるバックアップ・セットのキー。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

DF_KEY

NUMBER

このタスクでアクセスされるデータ・ファイルのキー。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

VB_KEY

NUMBER

このタスクでアクセスされる仮想バックアップのキー。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

HANDLE

VARCHAR2(1000)

このタスクでアクセスされるメディア・マネージャ・ハンドル。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

FILENAME

VARCHAR2(4000)

このタスクでアクセスされるバックアップ・ファイルの名前。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

LIB_KEY

NUMBER

このタスクでアクセスされるSBTライブラリの一意の識別子。

この列はZero Data Loss Recovery Applianceソフトウェア更新12.1.1.1.8以上でのみ使用可能です。

ARCHIVED

CHAR(1)

タスクのアーカイブ・ステータス: アーカイブに移動された場合はY、それ以外の場合はN。

13.29 RA_TIME_USAGE

このビューには、過去30日間のリカバリ・アプライアンスの経過時間とアイドル時間が表示されます。

列

データ型

NULL

説明

TOTAL_TIME

NUMBER

すべてのセッションの経過時間の合計(秒)。

IDLE_TIME

NUMBER

すべてのセッションのアイドル時間の合計(秒)。

14 rastatユーティリティのリファレンス

この章では、rastatユーティリティの詳細について説明します。rastatは、リカバリ・アプライアンスのパフォーマンス評価に役立つ統計を生成する際に使用します。

rastat.plユーティリティは、リカバリ・アプライアンス計算サーバーの/opt/oracle.RecoveryAppliance/client/ディレクトリにあります。

14.1 rastatのコマンド構文

perl rastat.pl --test=<options> --rasys=<string> --catalog=<string>
--filesize=<size>M --chunksize=<size>M --diskgroup=<string> --parms=<string>
--oracle_home=<string> --oracle_sid=<string>

14.2 オプション

表14-1 rastatのオプション

オプション

説明

-h, --help

ヘルプ情報を表示します。

--test

次のアトミック・テストのうち、どれをテストするかを指定します。

[NETBACKUP|NETRESTORE|ASMREAD|ASMWRITE| CONTAINERREAD|CONTAINERWRITE|CONTAINERALLOC|ALL]

NETBACKUP: バックアップのバイト・ストリームをリカバリ・アプライアンスに送信する際の、保護されたデータベースのネットワーク・パフォーマンスを測定します。--catalogが必須、--filesizeはオプションです。--parmsは、RMANクライアントで構成済であればオプションです。

NETRESTORE: バックアップのバイト・ストリームをリカバリ・アプライアンスから受信する際の、保護されたデータベースのネットワーク・パフォーマンスを測定します。--catalogが必須、--filesizeはオプションです。--parmsは、RMANクライアントで構成済であればオプションです。

ASMREAD: リカバリ・アプライアンスがASMディスク・グループから読み取る際のディスクI/Oパフォーマンスを測定します。--diskgroupと--rasysが必須です。--filesizeと--chunksizeはオプションです。

ASMWRITE: リカバリ・アプライアンスがASMディスク・グループに書き込む際のディスクI/Oパフォーマンスを測定します。--diskgroupと--rasysが必須です。--filesizeと--chunksizeはオプションです。

CONTAINERREAD: リカバリ・アプライアンスがコンテナ・ファイルから読み取る際のディスクI/Oパフォーマンスを測定します。--diskgroupと--rasysが必須です。--filesizeと--chunksizeはオプションです。

CONTAINERWRITE: リカバリ・アプライアンスがコンテナ・ファイルに書き込む際のディスクI/Oパフォーマンスを測定します。--diskgroupと--rasysが必須です。--filesizeと--chunksizeはオプションです。

CONTAINERALLOC: リカバリ・アプライアンスのコンテナ・ファイルの割当て率を測定します。--diskgroupと--rasysが必須です。--filesizeと--chunksizeはオプションです。

ALL: すべてのテストを実行します。必須オプションをすべて設定する必要があります。

--RASYS

リカバリ・アプライアンスのSYSアカウントの接続文字列。すべてのI/Oテストで必須です。

--catalog

リカバリ・アプライアンスの仮想プライベート・カタログ(VPC)アカウントの接続文字列。NETBACKUPテストとNETRESTOREテストで必須です。

--filesize

オプションです。ユーティリティがテストに使用するファイルのサイズ(MB単位)。テスト要件に応じて適切なファイル・サイズを設定することを強くお薦めします。デフォルトのファイル・サイズは1024MBです。

--chunksize

オプションです。ユーティリティがCONTAINERREADテストまたはCONTAINERWRITEテストで使用するチャンク・サイズ(MB単位)。デフォルトは、システムで構成されているチャンク・サイズです。

--diskgroup

I/Oテストで読み込む、または書き込むディスク・グループの名前。たとえば、--diskgroup=+DISK1ではASMディスク・グループを指定し、--diskgroup=/:DELTAではコンテナ・グループを指定します。すべてのI/Oテストで必須です。

--parms

RMANですでに構成されている場合には、オプションです。RMANで、NETBACKUPテストまたはNETRESTOREテストに使用するPARMS設定です。このパラメータには、libra.soの場所とウォレット情報を指定する必要があります。例: --parms='SBT_LIBRARY=/u01/oracle/lib/libra.so, ENV=(RA_WALLET=location=file:/u01/oracle/dbs/ra credential_alias=ra-scan:1521/zdlra5:dedicated)'。

--oracle_home

オプションです。$ORACLE_HOME環境変数。このオプションは、変数を設定する、または現在の設定を上書きする場合に使用します。

--oracle_sid

オプションです。$ORACLE_SID環境変数。このオプションは、変数を設定する、または現在の設定を上書きする場合に使用します。

15 リカバリ・アプライアンスのエラー・メッセージ・リファレンス

この章では、ORA-45100からORA-45299の範囲とORA-64700以降のZero Data Loss Recovery Appliance (リカバリ・アプライアンス)のエラー・メッセージについて詳しく説明します。

ORA-45100: データベース・インカネーションがstringからstringになりました。リカバリ・アプライアンスの修復が必要です。

原因: リカバリ・アプライアンスで'startup resetlogs'コマンドが実行されました。このため、古いメタデータが記憶域の場所の参照に使用されました。リカバリ・アプライアンスを起動するには、修復操作を実行してメタデータと記憶域を同期する必要があります。

処置: DBMS_RA.STARTUP_RECOVERY_APPLIANCEを実行してください。その後の修復中にインシデントが記録された場合は、修正する必要があります。修正したら、DBMS_RA.STARTUP_RECOVERY_APPLIANCEの実行を繰り返してください。

ORA-45102: stringバイトの記憶域を割り当てられません

原因: リカバリ・アプライアンスは、データベースの記憶域の場所で現在の割当てに対して追加のディスク領域を割り当てることができませんでした。この状況は、次の理由のいずれかが原因である可能性があります: * 保証付きコピーがデータベースに指定されていて、テープへのコピーを待機しているバックアップが多すぎるため。

* リカバリ・アプライアンスのメタデータが修復中であるため。

* データベースの記憶域の場所内で何もパージできないため。

処置: データベースの記憶域の場所に記憶域をさらに追加してください。

ORA-45109: データベースstringのメタデータ、ファイルstringが破損しています

原因: 内部セルフチェックで、リカバリ・アプライアンスのブロック・プールの管理に使用されるメタデータに破損が見つかりました。

処置: Oracleサポート・サービスに問い合せて、トレース・ファイルとアラート・ファイルを提出してください。

ORA-45111: タスクstringはstring回の再開後、停止中です。

原因: リカバリ・アプライアンス・タスクで生成されたエラーが多すぎます。エラー後に、タスクは通常どおり再開されます。10回の試行後に再開に失敗すると、タスクは破損とマークされ、再開されなくなります。

処置: タスクを終了させたエラーを修正してから、タスクの再実行をリクエストしてください。

ORA-45113: リカバリ・アプライアンス内部エラーstring

原因: 内部エラーが発生しました。

処置: Oracleサポート・サービスに問い合せて、トレース・ファイルとアラート・ファイルを提出してください。

ORA-45114: メタデータは、ファイル"string"を、記憶域の場所stringに関して参照していません

原因: リカバリ・アプライアンスのチェックファイル・タスクによって実行された一貫性チェックで、ファイルがリカバリ・アプライアンスのメタデータによって参照されていないことが確認されました。このような参照がないと、リカバリ・アプライアンスではファイルを管理できません。

処置: ファイルが誤って記憶域の場所に入れらた場合は、他の場所に移動する必要があります。ファイルがメタデータから切り離されている場合は、Oracleサポート・サービスに問い合せて、トレース・ファイルとアラート・ファイルを提出してください。

ORA-45115: DB_KEY stringのデータベースは、大きすぎるため移動できません。

原因: 指定されたデータベースを新しい記憶域の場所に移動しようとしましたが、データベースを記憶域の予約内に縮小できず、依然として保存ウィンドウを保持しています。

処置: データベースの記憶域の予約を増やすか、保存ウィンドウを縮小してください。

ORA-45116: BP_KEY stringのバックアップ・ピースのメタデータを読取り中に異常が検出されました

原因: バックアップ・データに一時的な異常が見つかりました。

処置: 異常が解決されない場合は、バックアップ・ピースのコピーを見つけ(入手できる場合)、記憶域の場所に再挿入してください。コピーを入手できない場合は、バックアップ・ピースの全データファイルについて新しいレベル0バックアップを生成してください。

ORA-45118: サーブレット・タイムアウト・エラー

原因: リストア・タスクが、サーブレット・プロセスでクライアントにデータが渡されるのを待機していました。レスポンスに割り当てられた時間を超えたため、リストア・タスクは強制終了されました。

処置: これは、クライアントでリストア・リクエストが取り消される場合によくある事象です。リクエストを再発行してください。

ORA-45119: 権限を変更するための、存在しない操作を受け取りました

原因: 無効なオプションが指定されました。

処置: サポートされる値は、BACKUP、RECONCILE、READ、WRITEおよびNULLのみです。

ORA-45120: 領域不足のため、操作に失敗しました

原因: 記憶域の場所が新しいデータベースをサポートするには小さすぎました。

処置: 記憶域の場所のサイズを大きくするか、保護ポリシーのDISK_RESERVED_SPACEを小さくしてください。

ORA-45121: 権限を変更するための不正な値を受け取りました

原因: 権限の付与または取消中に、内部エラーが検出されました。

処置: Oracleサポート・サービスに問い合せて、トレース・ファイルとアラート・ファイルを提出してください。

ORA-45122: 無効なサイズまたは数値が指定されました

原因: 無効なサイズまたは数値が指定されました。

処置: NULL以外または0より大きい数値を使用してください。

ORA-45123: 名前string (string)はすでに存在します。

原因: オブジェクト名は一意ではありませんでした。

処置: このオブジェクトに一意の名前を指定してください。

ORA-45124: オブジェクトstring (string)は参照されているため、削除できません。

原因: オブジェクトは、記憶域の場所またはデータベースによって使用中です。

処置: このアイテムを参照するオブジェクトをすべて削除してください。

ORA-45125: オブジェクトstring (string)は存在しません。

原因: オブジェクト名は存在しませんでした。

処置: 既存のオブジェクトを指定してください。

ORA-45126: データベースstringの削除に失敗しました

原因: データベースを削除できませんでした。予期しないエラーが発生しました。

処置: 関連するメッセージを調査し、例外の原因を特定してください。

ORA-45127: 必須パラメータstringを指定する必要があります。

原因: パラメータがAPIルーチンに指定されませんでした。

処置: 欠落しているパラメータを指定してコマンドを再実行してください。

ORA-45128: バックアップ・ピースstring(データベースstring)は、カタログによって参照されていません。

原因: リカバリ・アプライアンスのチェックファイル・タスクによって実行された一貫性チェックで、指定されたバックアップ・ピースがRMANカタログによって参照されていないことが確認されました。このような参照がないと、リカバリ・アプライアンスではこのピースで使用される領域を解放できません。

処置: Oracleサポート・サービスに問い合せてください。

ORA-45129: stringバイトがデータベースstringによって記憶域の場所stringで使用されていると予測されていましたが、使用されているのはstringバイトであることが検出されました

原因: リカバリ・アプライアンスのチェックファイル・タスクによって実行された一貫性チェックで、記憶域の場所でのデータベースの記憶域使用量がリカバリ・アプライアンスに割り当てられた記憶域ピースのサイズの合計と一致しないことが確認されました。

処置: Oracleサポート・サービスに問い合せてください。

ORA-45130: 記憶域パラメータがstringの記憶域と重複しています。

原因: 別の記憶域の場所にすでに割り当てられている記憶域と重なっている記憶域の場所のパラメータが指定されました。

原因: 記憶域に対して別の場所を指定するコマンドを再発行してください。

ORA-45131: 不正または不明なリストア圧縮オプションが指定されました

原因: 指定された圧縮オプションは、 リカバリ・アプライアンス・データベースまたはバックアップを提供しているデータベースのいずれかでサポートされていませんでした。

処置: V$RMAN_COMPRESSION_ALGORITHMビューを問い合せて、アルゴリズム名がその表のアルゴリズム名のいずれかと一致すること、オプションにIS_VALID = 'YES'が指定されていること、INITIAL_RELEASE列の値がリカバリ・アプライアンスとバックアップを提供しているデータベースの両方より小さいことを確認します。有効な圧縮アルゴリズム名を指定してコマンドを再発行してください。

ORA-45132: バックアップ・ピースで破損ブロックが検出されました

原因: リカバリ・アプライアンス・ブロック・プールへの移入時に、破損ブロックがバックアップ・ピースで検出されました。

処置: データベースの破損ブロックに対してブロック・メディア・リカバリを実行してから、累積レベル1のバックアップを実行してください。

ORA-45133: stringバイトがデータベースstringによって割り当てられていると予測されていましたが、割り当てられているのはstringバイトであることが検出されました

原因: リカバリ・アプライアンスのチェックファイル・タスクによって実行された一貫性チェックで、データベースの記憶域割当てがすべての記憶域の場所でのそのデータベースに対する割当てサイズの合計と一致しないことがわかりました。

処置: Oracleサポート・サービスに問い合せてください。

ORA-45135: リクエストはリカバリ・アプライアンスによって終了されました

原因: リクエストがリカバリ・アプライアンスで必要なリソースを保持し続けたため、そのリソースを解放するために終了されました。これは、ディスク領域などのリソース不足によって引き起こされる可能性があります。

処置: 使用可能なディスク領域を確認した上で、リカバリ・アプライアンス・データベースに関するエラーがないかも確認してください。

ORA-45136: パラメータstringの値が無効です

原因: 指定したパラメータに指定した値が無効でした。

処置: リカバリ・アプライアンスのドキュメントを確認し、正しい値でコマンドを再実行してください。

ORA-45137: 不明なプラットフォーム

原因: リカバリ・アプライアンスは、System Backup to Tape (SBT)から、またはポーリングによってどのバックアップも受信していません。これは、リカバリ・アプライアンスがデータベースの保護されたプラットフォームを認識し、現在の操作が成功するのに必要です。

処置: 小さいアーカイブ・ログや他のバックアップを、SBTを使用するかポーリング位置に送信してバックアップします。その後で、この操作を再試行してください。

ORA-45138: バックアップが見つかりません。

原因: 指定されたバックアップがカタログに見つかりませんでした。

処置: 確認し、正しいバックアップ・ピース・キーまたはバックアップ・セット・キーを指定してください。

ORA-45139: この破損を修正するための有用なバックアップが見つかりませんでした。

原因: 仮想バックアップ・ピース・キーが指定されましたが、このバックアップを修正するための既知のバックアップがテープまたはディスクにありません。

処置: 破損バックアップがデータファイルの最古の仮想バックアップである場合、さらに古いバックアップにカタログの修正に必要なデータが含まれていることもあります。そのような古いバックアップを見つけて、直接指定してください。

ORA-45140: カタログにバックアップを挿入できません

原因: 指定されたバックアップが増分ではないか、カタログの問題を修正するための適切なSCN範囲内にありません。

処置: 正しいキー値を指定していることと、適切な増分バックアップ・ピースが見つかることを確認してください。

ORA-45141: ファイル"string"が記憶域の場所stringにありませんでした。

原因: リカバリ・アプライアンスのリカバリ中、指定されたファイルがリカバリ・アプライアンスのメタデータによって参照されましたが、記憶域の場所に見つかりませんでした。

処置: レプリケートされたリカバリ・アプライアンスが存在する場合、ファイルはそこからリカバリする必要があります。ファイルがメタデータから切り離されている場合は、Oracleサポート・サービスに問い合せて、トレース・ファイルとアラート・ファイルを提出してください。

ORA-45142: リカバリ・アプライアンスの前提条件はすでに設定されています。

原因: DBMS_RA_INSTALLプロシージャが実行され、リカバリ・アプライアンスに対するカタログ・スキーマを作成するために前提条件オブジェクトが設定されました。データベース用のリカバリ・アプライアンスを管理するユーザー・スキーマが1つしか存在できないため、このエラーが報告されます。

処置: リカバリ・アプライアンス・スキーマを別のユーザー・スキーマで再作成するには、以前のリカバリ・アプライアンス・スキーマ設定をアンインストールしてください。

ORA-45143: リカバリ・アプライアンスの前提条件設定管理者のユーザー名が一致しません。

原因: DBMS_RA_INSTALLプロシージャが実行され、正しくないユーザー名についてリカバリ・アプライアンスの前提条件オブジェクトがアンインストールされました。

処置: DBMS_RA_INSTALLのユーザー名パラメータを修正して、プロシージャを再実行してください。

ORA-45144: 保護ポリシーに初期レプリケーション・タイプが定義されていません。

原因: initial_replication_typeが保護ポリシーに定義されていません。

処置: 保護ポリシーのinitial_replication_typeをLAST FULL、ALLまたはNONEのいずれかで更新してください。

ORA-45145: リカバリ・アプライアンス・ユーザーstringは存在しません。

原因: リカバリ・アプライアンス・ユーザーは存在しません。

処置: 既存のリカバリ・アプライアンス・ユーザーを指定してください。

ORA-45146: 記憶域の場所stringには、追加の記憶域がstringバイト必要です。

原因: 'resetlogs'コマンド使用してデータベースをオープンした後にリカバリ・アプライアンスのメタデータを修復していましたが、指定された記憶域の場所で割り当てられた記憶域が不十分でした。これは、'resetlogs'コマンドのために'update_storage_location'コールが失われたか、resetlogsコマンドの実行時に記憶域の場所の空き領域が非常に少なくなったことで引き起こされる可能性があります。

処置: 指定された値で記憶域の場所を更新してから、DBMS_RA.STARTUP_RECOVERY_APPLIANCEを実行して修復を再試行してください。

ORA-45147: データベースstringおよびデータベースstringは、どちらも移動中です。

原因: 'resetlogs'を使用してデータベースをオープンした後にリカバリ・アプライアンスのメタデータを修復していましたが、2つのデータベースが記憶域の場所の間を移動していることがわかりました。リカバリ・アプライアンスが正しく機能するのは、1つのデータベースの移動時のみです。これは、'resetlogs'コマンドのために'update_protection_policy'または'update_db'コールが失われたことで引き起こされる可能性があります。

処置: 各データベースで使用される 記憶機の場所を特定してから、失われた可能性があるデータベースの移動を繰り返してください。

ORA-45148: リカバリ・アプライアンスを再起動する前にstringのエラーを修正する必要があります

原因: リカバリ・アプライアンスのメタデータの修復中に、リカバリ・アプライアンスの再起動を妨げるエラーが検出されました。

処置: 特定されたエラーを修正し、DBMS_RA.STARTUP_RECOVERY_APPLIANCEを実行して修復を再試行してください。

ORA-45149: 不明なタスク・タイプ: string

原因: リカバリ・アプライアンスで、不明なタスク・タイプのタスクを実行しようとしました。

処置: Oracleサポート・サービスに問い合せてください。

ORA-45150: ファイルstringは、不明なDBID stringを参照しています。

原因: リカバリ・アプライアンスのメタデータの修復中に、指定されたファイルがリカバリ・アプライアンスでは不明の指定されたデータベースを参照していました。これは、'resetlogs'コマンドのために'add_db'コールが失われたことで引き起こされる可能性があります。

処置: 失われた'add_db'コールを繰り返してください。

ORA-45151: ロックstringのロック・プロトコルが不正です

原因: 内部エラーのため、ロックが正しく使用されなくなりました。

処置: Oracleサポート・サービスに問い合せてください。

ORA-45152: stringのバックアップ・ピース形式が不正です

原因: リカバリ・アプライアンスのメタデータの修復中に、指定されたファイルのタイプが確認できませんでした。

処置: 破損したファイルを削除してから、DBMS_RA.STARTUP_RECOVERY_APPLIANCEを再実行してください。

ORA-45153: データ・ファイルstring (DBID string)が不明です

原因: リカバリ・アプライアンスのメタデータの修復中に、指定されたデータベースのデータのデータファイルが見つかりませんでした。

処置: 指定されたデータベースでRMANを使用している場合、'resync'コマンドを使用してリカバリ・アプライアンスのメタデータをリフレッシュしてから、リカバリ・アプライアンスの再起動を再試行してください。

ORA-45154: ファイルstringに不正なリカバリ・アプライアンス形式が検出されました

原因: リカバリ・アプライアンスのメタデータの修復中に、チャンク・ファイルでもバックアップ・ピースでもないファイルが記憶域の場所で見つかりました。

処置: リカバリ・アプライアンスの記憶域の場所から問題となっているファイルを削除してから、リカバリ・アプライアンスの再起動を再試行してください。

ORA-45155: リカバリ・アプライアンスがインストールされていません。

原因: リカバリ・アプライアンスがこのデータベースにインストールされていません。リクエストされたプロシージャは、リカバリ・アプライアンスでのみサポートされます。

処置: リカバリ・アプライアンス以外でこのプロシージャを試行しないでください。

ORA-45156: SBTジョブstringが見つかりません

原因: 指定されたSBTジョブが見つかりませんでした。

処置: ユーザーがSBTジョブを削除しているかどうかを確認してください。そうしている場合は、スケジューラ・ジョブを削除してください。

ORA-45157: パラメータ値string (string)無効です。

原因: パラメータの指定された値は無効でした。

処置: 有効な値を指定してください。

ORA-45158: SBTライブラリstringの準備ができていません。

原因: 指定されたSBTライブラリの準備ができていないませんでした。

処置: ユーザーがライブラリを一時停止しているかどうかを確認してください。そうしている場合は、SBTライブラリを再開してください。

ORA-45159: データベースstringのRECOVERY_WINDOW_GOALが失われました。

原因: 領域不足により、指定データベースのリカバリ・ウィンドウ目標をサポートするために必要なバックアップの削除が強制されました。

処置: これは警告であり、アクションは不要です。ただし、DBMS_RA.UPDATE_PROTECTION_POLICYを使用してデータベースのDISK_RESERVED_SPACE値を増やし、追加バックアップが保存されるようにすることはできます。RA_DATABASEからSPACE_USAGEを選択し、どの程度の領域が現在使用中かを確認してください。また、ディスクの領域を消費しているKEEPバックアップがないか確認し、テープまたは他のディスク・ストレージに移動するかどうかを決定してください。詳細は、DBMS_RA.MOVE_BACKUP_PIECEを参照してください。

ORA-45160: データベースstringの永久増分方法が失われました。

原因: 領域不足により、1つ以上のデータファイルの最後まで残る仮想LEVEL 0を生成するために必要なバックアップ・データの削除が強制されました。次のクライアント・バックアップは、LEVEL 1が指定されてもLEVEL 0全体バックアップになります。

処置: これは警告であり、アクションは不要です。ただし、DBMS_RA.UPDATE_DBを使用してデータベースのRESERVED_SPACE値を増やし、追加バックアップが保存されるようにすることはできます。RA_DATABASEからSPACE_USAGEを選択し、どの程度の領域が現在使用中かを確認してください。また、ディスクの領域を消費しているKEEPバックアップがないか確認し、テープまたは他のディスク・ストレージに移動するかどうかを決定してください。詳細は、DBMS_RA.MOVE_BACKUP_PIECEを参照してください。

ORA-45161: バックアップ・ピース・サイズはデータベースDISK_RESERVED_SPACEを超えることはできません。

原因: 単体のバックアップ・ピースがデータベース保護ポリシーのDISK_RESERVE_SPACE値を超えました。安全なDISK_RESERVED_SPACE値がデータベースのサイズを上回ります。

処置: DBMS_RA.UPDATE_DBを使用してデータベースのDISK_RESERVED_SPACE値を増やしてください。

ORA-45162: システム・グローバル領域メモリーが正しく構成されていません。

原因: 初期化パラメータLARGE_POOL_SIZEおよびSHARED_POOL_SIZEを確認します。リカバリ・アプライアンスでは、LARGE_POOL_SIZEの全部またはSHARED_POOL_SIZEの20%を使用して仮想バックアップまたはテープ・バックアップがリストアされます。必要な実際の領域はNETWORK_CHUNKSIZE * 2 * (同時リストア・チャネルの数)です。NETWORK_CHUNKSIZEは、DBMS_RA.CONFIGを使用して設定されます。DBMS_RA.CONFIGを使用してNETWORK_CHUNKSIZEを小さくするか、できればLARGE_POOL_SIZEまたはSHARED_POOL_SIZEを大きくします。

処置: 初期化パラメータLARGE_POOL_SIZEおよびSHARED_POOL_SIZEを確認し、適切に設定てください。

ORA-45163: 操作はユーザーstringに対してのみサポートされています。

原因: リカバリ・アプライアンス管理者以外のユーザーがリカバリ・アプライアンスを起動しようとしました。

処置: インストール時に指定されたユーザーとしてのみリカバリ・アプライアンスを起動してください。

ORA-45164: リカバリ・アプライアンスは実行されていません。

原因: リカバリ・アプライアンスを使用しようとしましたが、管理者によってリカバリ・アプライアンスが非アクティブ化されています。

処置: リカバリ・アプライアンス管理者にDBMS_RA.STARTUP_RECOVERY_APPLIANCEを実行してもらい、操作を再試行してください。

ORA-45165: BP_KEY stringを持つリカバリ・アプライアンス・バックアップ・ピースが破損しています

原因: バックアップ・データに破損が見つかりました。

処置: 影響を受けるデータファイルの機能するバックアップがあることを確認してください。その後で、破損したバックアップ・ピースを削除して状況を解消します。

ORA-45166: ファイルstringにアクセスできません

原因: エラーとなった指定のファイルにアクセスしようとしました。次のメッセージにエラーの説明が表示されます。

処置: ファイルが正しいか確認してください。破損している場合は、削除するか、置換します。

ORA-45167: BP_KEY stringを持つバックアップ・ピースを検証できません

原因: エラーとなった指定のバックアップ・ピースを検証しようとしました。次のメッセージにエラーの説明が表示されます。

処置: バックアップ・ピースが正しいか確認してください。破損している場合は、削除するか、置換します。

ORA-45168: タイプstringのタスクID stringを実行中にスケジューラが予期せずに終了しました

原因: リカバリ・アプライアンスで、タスクが予期しないエラー・コードで失敗しました。

処置: Oracleサポート・サービスに問い合せてください。

ORA-45169: タイマー・プロセスが予期せずに終了しました

原因: リカバリ・アプライアンスで、タイマー・プロセスが予期しないエラー・コードで失敗しました。

処置: Oracleサポート・サービスに問い合せてください。

ORA-45170: 記憶域の場所stringがいっぱいです。

原因: 指定された記憶域の場所をパージしたため、そのデータベースのいずれかに対するリカバリ・ウィンドウ目標が失われました。

処置: その記憶域の場所にさらに記憶域を追加するか、その記憶域の場所からデータベースをいくつか削除するか、その記憶域の場所にある一部のデータベースに対するリカバリ・ウィンドウ目標を減らしてください。

ORA-45171: 1つ以上のデータベースに対してチャンク最適化タスクが最近実行されていません。

原因: 少なくとも1つのデータベースに対してバックグラウンド・チャンク最適化タスクが最近実行されていません。これは、フォアグラウンド・アクティビティによるリカバリ・アプライアンスへの負荷が過剰すぎてバックグラウンド・タスクを実行する時間がない場合に起こることがあります。

処置: 保護されたデータベースによるバックアップの頻度を減らすか、リカバリ・アプライアンスから一部のデータベースの負荷を軽減して、リカバリ・アプライアンスから負荷をある程度除いてください。

ORA-45172: 1つ以上のデータベースに対して検証タスクが最近実行されていません。

原因: 少なくとも1つのデータベースに対してバックグラウンド検証タスクが最近実行されていません。これは、フォアグラウンド・アクティビティによるリカバリ・アプライアンスへの負荷が過剰すぎてバックグラウンド・タスクを実行する時間がない場合に起こることがあります。

処置: 保護されたデータベースによるバックアップの頻度を減らすか、リカバリ・アプライアンスから一部のデータベースの負荷を軽減して、リカバリ・アプライアンスから負荷をある程度除いてください。

ORA-45173: 1つ以上の記憶域の場所に対してチェックファイル・タスクが最近実行されていません。

原因: 1つ以上の記憶域の場所に対してバックグラウンド・チェックファイル・タスクが最近実行されていません。これは、フォアグラウンド・アクティビティによるリカバリ・アプライアンスへの負荷が過剰すぎてバックグラウンド・タスクを実行する時間がない場合に起こることがあります。

処置: 保護されたデータベースによるバックアップの頻度を減らすか、リカバリ・アプライアンスから一部のデータベースの負荷を軽減して、リカバリ・アプライアンスから負荷をある程度除いてください。

ORA-45174: レプリケーション・サーバーstringを使用できません

原因: リカバリ・アプライアンスを使用しているときに、バックアップをターゲットのレプリケートされたリカバリ・アプライアンスに送信できなかったか、レプリケートされたリカバリ・アプライアンスに対するリストア・リクエストが完了できませんでした。

処置: 次のエラー・メッセージを確認し、実際のエラーを診断してください。

ORA-45175: SBTライブラリstringを使用できません

原因: リカバリ・アプライアンスを使用しているときに、指定されたSystem Backup to Tapeライブラリを使用しましたが、リクエストが完了できませんでした。

処置: 次のエラー・メッセージを確認し、実際のエラーを診断してください。

ORA-45176: レプリケーション・サーバーstringは、一時停止状態ではありません。

原因: 一時停止状態ではないレプリケーション・サーバーに関する情報を更新しようとしました。

処置: このリカバリ・アプライアンスのレプリケーション・サーバーを一時停止してください。

ORA-45177: 以前にポーリング中に見つかったファイルstringが見つかりません

原因: ポーリング位置で以前に見つかったバックアップ・ピース・ファイルがその後、リカバリ・アプライアンスでアクセスできませんでした。

処置: ネットワーク・エラーのためにそのファイルが使用できない場合、ネットワークが使用可能になれば、そのファイルは再度見つかります。そのバックアップ・ピースが削除された場合、新しいバックアップを作成してください。

ORA-45178: 割当て単位サイズを変更できません。

原因: 割当て単位サイズが異なる記憶域の場所に1つ以上のデータベースを移動しようとしました。この値は、記憶域の場所によって参照されているディスク・グループの作成時に指定されたASMディスク・グループの割当て単位サイズから取得されます。

処置: ソースと同じ最小割当てサイズの記憶域の場所を使用してください。必要な場合は、新しい記憶域の場所を作成する前に、サイズが一致する新しいディスク・グループを作成してください。

ORA-45179: データベースstringに対して調整タスクが最近実行されていません。

原因: 指定されたデータベースに対してバックグラウンド調整タスクが最近実行されていません。これは、フォアグラウンド・アクティビティによるリカバリ・アプライアンスへの負荷が過剰すぎてバックグラウンド・タスクを実行する時間がない場合に起こることがあります。

処置: 保護されたデータベースによるバックアップの頻度を減らすか、リカバリ・アプライアンスから一部のデータベースの負荷を軽減して、リカバリ・アプライアンスから負荷をある程度除いてください。

ORA-45180: 1つ以上のデータベースに対してクロスチェック・タスクが最近実行されていません。

原因: 少なくとも1つのデータベースに対してバックグラウンド調整タスクが最近実行されていません。これは、フォアグラウンド・アクティビティによるリカバリ・アプライアンスへの負荷が過剰すぎてバックグラウンド・タスクを実行する時間がない場合に起こることがあります。

処置: 保護されたデータベースによるバックアップの頻度を減らすか、リカバリ・アプライアンスから一部のデータベースの負荷を軽減して、リカバリ・アプライアンスから負荷をある程度除いてください。

ORA-45181: ポーリング中に重複したファイル名stringが見つかりました

原因: 指定されたファイル名はすでに記憶域の場所に含まれていました。この警告の理由として次の3つが考えられます。

* 2つのデータベースによってポーリング位置が同じになっていますが、どちらの形式にもDBIDが含まれていません。

* バックアップ・コマンドに一意の形式名が指定されていませんでした。

* リカバリにより、その場所にアーカイブ・ログがリストアされています。これは、ポーリング位置がプライマリ・アーカイブ・ログの宛先である場合に発生する可能性があります。

処置: 原因が名前の形式である場合、形式を修正して指定されたファイルの名前を変更してください。その後、再度ポーリングでファイルが検出されたら、含めてください。これがリカバリだった場合、ファイルは本当に重複しているため、ファイルを削除してください。このような重複ファイルはコピーされていないため、DELETE_INPUTオプションは役立たないので注意してください。

ORA-45182: カタログ所有者またはsysを使用してデータベース・アクセス権を付与または取り消すことはできません

原因: DBMS_RA.GRANT_DB_ACCESSプロシージャとDBMS_RA.REVOKE_DB_ACCESSプロシージャで、カタログ所有者またはSYSがユーザーとして指定されました。これは許可されていません。

処置: 別のユーザーを作成し、必要なアクセス権を付与してください。

ORA-45183: リクエストはセッションstring (インスタンスstring)によってブロックされています

原因: 別のAPIの処理中に、リカバリ・アプライアンスに対してAPIリクエストが行われました。一度に実行できるAPIは1つのみです。

処置: 他のAPIが完了するのを待機するか、特定されたセッションを終了してから、失敗したAPIリクエストを繰り返してください。

ORA-45184: ウォレット操作中にORA-stringが発生しました。WRL string

原因: 示されたエラーのため、ウォレットに対する操作が失敗しました。

処置: 詳細は、示されたOracleメッセージを参照してください。

ORA-45185: 別名stringがstringウォレットで見つかりません

原因: 指定されたウォレット別名がウォレット内にありませんでした。

処置: ウォレット別名を確認するか、指定された属性のウォレットで別名を作成してから、コマンドを再試行してください。

ORA-45187: 記憶域の場所stringを使用できません。コンテナ修復キーはstringです。

原因: リカバリ・アプライアンスの修復中に、指定された記憶域の場所を再構築しているとき、致命的なエラーが検出されました。

処置: 検出されたエラーについてどの修復コマンドが発行されたか、インスタンスのアラート・ログを調べます。エラーの原因がディスク・グループの欠落であることがわかった場合は、そのディスク・グループを追加してSTARTUP_RECOVERY_APPLIANCE APIを実行してください。欠落したデータをリストアできないと判断した場合は、REPLACEオプションを指定してREPAIR_STORAGE_LOCATION APIを実行してからSTARTUP_RECOVERY_APPLIANCE APIを実行してください。

ORA-45188: 記憶域の場所stringは修復が必要です。コンテナ修復キーはstringです。

原因: リカバリ・アプライアンスの修復中に、指定された記憶域の場所を再構築しているとき、一貫性エラーが検出されました。

処置: 検出されたエラーについてどの修復コマンドが発行されたか、インスタンスのアラート・ログを調べます。エラーの原因がディスクまたはディスク・グループの欠落であることがわかった場合は、そのディスクまたはディスク・グループを追加してSTARTUP_RECOVERY_APPLIANCE APIを実行してください。欠落したデータをリストアできないと判断した場合は、REPLACEオプションを指定してREPAIR_STORAGE_LOCATION APIを実行してからSTARTUP_RECOVERY_APPLIANCE APIを実行してください。

ORA-45189: 記憶域の場所の名前がstringからstringに変更されたため、修復に失敗しました

原因: リカバリ・アプライアンスの修復中に、記憶域の場所の定義に当初使用された名前とは異なる名前の記憶域の場所が見つかりました。

処置: 不正な記憶域の場所を削除し、正しい名前で再作成してください。

ORA-45190: BP_KEY stringのデータベースのメタデータを読取り中に異常が検出されました

原因: バックアップ・データに一時的な異常が見つかりました。

処置: 異常が解決されない場合は、データベースの全データファイルについて新しいレベル0バックアップを生成してください。

ORA-45191: リカバリ・アプライアンス・バックアップに適したSBTライブラリが見つかりませんでした

原因: リカバリ・アプライアンス・メタデータのバックアップの実行に適したSystem Backup to Tape (SBT)ライブラリが見つかりませんでした。

処置: リカバリ・アプライアンス・バックアップに使用できるSBTライブラリを作成してください。

ORA-45192: リカバリ・アプライアンス・バックアップにはすでに予約があります

原因: 有効な予約が存在するのに、リカバリ・アプライアンス・メタデータのバックアップを実行する新しい予約を作成しようとしました。

処置: 既存の予約を削除してから、新しい予約を作成してください。

ORA-45193: 複数のSBTライブラリがあります

原因: リカバリ・アプライアンス・メタデータのバックアップに使用できるSystem Backup to Tape (SBT)ライブラリが複数見つかりました。

処置: SBTライブラリの予約時に名前を指定してください。

ORA-45194: リカバリ・アプライアンス・メタデータのSBTライブラリへのバックアップに失敗しました

原因: System Backup to Tape (SBT)ライブラリへのリカバリ・アプライアンス・メタデータのバックアップ中にエラーが発生しました。このエラーは、SBTライブラリ構成またはリカバリ・アプライアンスの内部エラーにより発生した可能性があります。

処置: SBTライブラリ構成またはRA_INCIDENT_LOGビューを確認してください。

ORA-45195: 予約待機時間を越えています

原因: System Backup to Tape (SBT)ライブラリの予約を待機中にタイムアウトが発生しました。

処置: '_drive_wait_minutes'構成パラメータを変更して予約の待機時間を増やしてから、操作を再試行してください。

ORA-45196: 既存の予約の予約解除に失敗しました

原因: 既存のSystem Backup to Tape (SBT)ライブラリの予約を予約解除できませんでした。

処置: このエラーの原因に関する情報がないか、'ERROR_LOG'表およびトレース・ファイルを確認してください。

ORA-45197: 予約用のSBTライブラリstringが見つかりませんでした

原因: リカバリ・アプライアンスで、指定された名前のSystem Backup to Tape (SBT)ライブラリが見つかりませんでした。

処置: SBTライブラリ名を確認してから、操作を再試行してください。

ORA-45198: マシンが物理リカバリ・アプライアンスではありません

原因: 物理リカバリ・アプライアンスではないマシンでリカバリ・アプライアンス・サービスを起動しようとしました。

処置: リカバリ・アプライアンス・サービスはこのシステムで起動できません。

ORA-45199: エラーstringがstringの実行中に発生しました。

原因: PL/SQLコードの実行中にエラーが発生しました。このメッセージに付随して、エラーの原因を示すその他のエラー・メッセージが表示されます。

処置: 付随するエラー・メッセージを確認してください。

ORA-45200: HTTPステータス・コード: string

原因: サーブレット・リクエストの処理中に、示されたHTTPステータス・コードが受信されました。

処理: ありません。

ORA-45201: 追加情報: string

原因: サーブレット・リクエストの処理中に、示された追加エラーが受信されました。

処理: ありません。

ORA-45202: 操作に失敗しました。再度実行してください

原因: サーブレット・リクエストの処理中に、バックアップ操作またはリストア操作に失敗しました。操作は再試行できます。

処置: SBTクライアントより、このメッセージを使用して操作を再試行するかどうか決定されます。

ORA-45203: string"(バックアップ・ピース・ファイル"string")に失敗しました

原因: 指定されたバックアップ・ピースでのOS操作からエラーが戻されました。

処置: 追加メッセージを確認してください。

ORA-45210: リソースがビジー状態です。再試行してください

原因: サーブレット・リクエストの処理中に、バックアップ操作またはリストア操作に失敗しました。操作は再試行できます。

処置: SBTクライアントより、このメッセージを使用して操作を再試行するかどうか決定されます。

ORA-45211: データの送信中にエラーが発生しました。エラー・コードstring

原因: クライアントへのデータの送信中にエラーが発生しました。

処置: 追加メッセージを確認してください。

ORA-45212: データの受信中にエラーが発生しました。エラー・コードstring

原因: クライアントからのデータの受信中にエラーが発生しました。

処置: 追加メッセージを確認してください。

ORA-45213: ユーザーまたはロール'string'は存在しません

原因: 指定された名前のユーザーまたはロールがありませんでした。

処置: 有効なユーザー名またはロールを指定してください。

ORA-45214: 'string'を数値に変換できません

原因: 算術、数値、文字列、変換または制約のエラーが発生しました。たとえば、NOT NULLと宣言されている変数にNULL値が割り当てられていたり、NUMBER(2)と宣言されている変数に99より大きい整数が割り当てられています。

処置: データ、データの操作方法またはデータの宣言方法を変更し、値が定義された制約に違反しないようにしてください。

ORA-45215: 使用中のレプリケーション・サーバーを削除できません

原因: バックアップをアクティブにリストアしているレプリケーション・サーバーを削除しようとしました。

処置: リストアを取り消すか、リストアの完了を待機してから、レプリケーション・サーバーを削除してください。

ORA-45216: バックアップ・メタデータstring (string)がデータベースstringに見つかりませんでした

原因: 報告されたバックアップ・メタデータが見つかりませんでした。

処置: これは情報メッセージです。SBTタスクが実行されるまで、バックアップが保持されることを確認してください。

ORA-45217: SBTタスクstringが見つかりません

原因: 指定されたSBTタスクが見つかりませんでした。

処置: 有効なSBTタスク識別子を指定し、コマンドを再試行してください。

ORA-45264: リカバリ・アプライアンスのテスト・リカバリstring中にエラーが発生しました

原因: リカバリ・アプライアンス保護の一環として、リカバリ・アプライアンス・メタデータ保護スクリプトによってテスト・リカバリが実行されました。テスト・リカバリでは、データファイルをリストアするための追加ディスク領域要件なしに、イメージ・コピーを使用してデータベースがテストされます。

処置: この障害に関する追加情報がRA_INCIDENT_LOGに記録され、Oracle Enterprise Managerコンソールにも表示されます。

ORA-45265: リカバリ・アプライアンスのバックアップ・ヘルス・チェックstring中にエラーが発生しました

原因: リカバリ・アプライアンス保護の一環として、リカバリ・アプライアンス・メタデータ保護スクリプトによってバックアップ・ヘルス・チェックが実行されました。バックアップ・ヘルス・チェックでは、データベースの'validate'および'preview'コマンドを使用してバックアップがテストされます。

処置: この障害に関する追加情報がRA_INCIDENT_LOGに記録され、Oracle Enterprise Managerコンソールにも表示されます。

ORA-45266: リカバリ・アプライアンスのデータベース・ヘルス・チェックstring中にエラーが発生しました

原因: リカバリ・アプライアンス保護の一環として、リカバリ・アプライアンス・メタデータ保護スクリプトによってデータベース・ヘルス・チェックが実行されました。バックアップ・ヘルス・チェックでは、'backup validate'コマンドを使用してデータベース・ヘルス・チェックが実行されます。

処置: この障害に関する追加情報がRA_INCIDENT_LOGに記録され、Oracle Enterprise Managerコンソールにも表示されます。

ORA-45275: コンテナ: 'string'

原因: このメッセージは、他のメッセージが含まれているリカバリ・アプライアンス・コンテナの名前を報告しています。

処置: 問題の説明については、関連するエラー・メッセージを参照してください。

ORA-45276: コンテナを作成できませんでした

原因: コンテナの作成に失敗しました。エラー・スタックに、問題の詳細を示す他のメッセージが出力されます。

処置: エラー・スタック全体を調べてください。問題が修正可能な場合は、修正してからこのコンテナの作成を再試行してください。

ORA-45277: 新規AUサイズstringが既存のAUサイズstring (グループstring)と異なります。

原因: このコンテナ・グループにすでに存在する他のコンテナとAUサイズが異なる新しいコンテナを作成しようとしました。

処置: コンテナ・グループの他のコンテナとAUサイズが同じコンテナを指定してください。

ORA-45278: コンテナ・グループstringが空ではありません。

原因: 指定されたコンテナ・グループを削除しようとしましたが、空です。

処置: グループから残りのオブジェクトを削除するか、FORCEオプションを使用してください。FORCEオプションは、コンテナ・グループのすべてのファイルを修復できないように削除するので注意してください。

ORA-45279: コンテナ・グループstringが存在しません。

原因: 指定されたコンテナ・グループが存在しません。

原因: 存在するコンテナ・グループを指定してください。

ORA-45280: コンテナ・グループstringはすでに存在します。

原因: 指定されたコンテナ・グループがすでに存在します。

処置: 存在しないコンテナ・グループを指定してください。

ORA-45281: サイズstringバイトは最大コンテナ・サイズstringを超えています。

原因: 最大サイズより大きいコンテナを作成しようとしました。

処置: 小さいサイズを指定してください。

ORA-45282: コンテナの識別中にエラーが発生しました

原因: コンテナの識別中にエラーが発生しました。

処置: エラー・スタックに、問題の詳細を示す他のメッセージがあります。

ORA-45283: コンテナへの書込み中にエラーが発生しました

原因: コンテナへの書込み中にI/Oエラーが発生しました。

処置: エラー・スタックに、問題の詳細を示す他のメッセージがあります。

ORA-45284: コンテナからの読取り中にエラーが発生しました

原因: コンテナンからの読取り中にI/Oエラーが発生しました。

処置: エラー・スタックに、問題の詳細を示す他のメッセージがあります。

ORA-45285: stringを超えるコンテナ・グループを作成できません。

原因: 新しいコンテナ・グループを追加しようとしたため、コンテナ・グループ数がシステム最大値を超えました。

処置: コンテナ・グループ制限を増やしてください。

ORA-45286: stringを超えるコンテナを作成できません。

原因: 新しいコンテナを追加しようとしたため、コンテナ数がシステム最大値を超えました。

処置: コンテナ制限を増やしてください。

ORA-45287: ファイル名stringは作成用として有効ではありません。

原因: 含まれるファイルの名前を無効な形式で作成しようとしました。

処置: 名前を修正し、操作を再試行してください。

ORA-45289: stringバイトはコンテナ・グループstringで予約できません。

原因: 指定されたコンテナ・グループの領域が不足していました。

処置: コンテナ・グループに別のコンテナを追加してください。

ORA-45290: ビジー状態であるため、ファイルstringを縮小できません。

原因: 指定されたファイルを他のプロセスがオープンしたままにしているため、サイズを減らすことができません。

処置: 他のプロセスがファイルを解放するまで待機してから、サイズの縮小を試行してください。

ORA-45291: コンテナstringはグローバルに識別されていません。

原因: 必要なコンテナがこのインスタンスでグローバルに識別されていないため、ファイルを作成または識別しようとして失敗しました。通常、GEN0プロセスのログにファイルを識別できない理由が示されます。

処置: GEN0プロセスのログを調べ、一部のコンテナをアクセス不可にしている問題を修正してください。

ORA-45292: コンテナ・グループの再構築中にエラーが発生しました

原因: コンテナ・グループの再構築中にリカバリ不能なエラーが発生しました。

処置: 詳細は、エラー・スタックの他のメッセージを確認してください。

ORA-64700: リカバリ・アプライアンスは停止中です

原因: リカバリ・アプライアンスは停止中でした。このメッセージは、リカバリ・アプライアンスのインシデント・ログに記録されます。停止が完了すると、インシデントはFIXEDとマークされます。

処置: リカバリ・アプライアンスの停止が完了するのを待機してください。

ORA-64701: 記憶域の場所stringは予約に対応できなくなりました。

原因: 指定された記憶域の場所に、割り当てられたすべてのデータベースの予約を果たすのに十分な領域がありませんでした。このエラーは、記憶域の場所でディスク領域の一部が失われ、修復中であった場合に発生します。

処置: 記憶域の場所に含まれているデータベースの予約を縮小するか、記憶域の場所にディスク領域をさらに追加してください。

ORA-64702: 記憶域の場所stringのコンテナ・ファイルを修復中にエラーが発生しました: string

原因: 保護されたデータベースからのデータの格納に使用されるコンテナ・ファイルを再構築または修復しようとして、エラーが戻されました。

処置: 後続のエラーにより、リカバリ・アプライアンスの修復前に対処する必要があるエラーが特定されます。

ORA-64703: リソース・エラーが検出されました

原因: 一時表領域の不足やスナップショットが古すぎるなどのリソース制限が検出されたため、タスクを中断する必要がありました。リソースの競合が減少したら、再試行されます。2番目のメッセージにより、すべて使用されたリソースが特定されます。

処置: このエラーがまれに発生した場合、ユーザー・アクションは必要ありません。この状況が解決しない場合、リカバリ・アプライアンス管理者はすべて使用されたリソースを増やす必要があります。

ORA-64705: 列stringにある"string"に宛先がありません

原因: 記憶域の宛先に構文エラーがありました。

処置: 構文エラーを修正してから、操作を再試行してください。

ORA-64708: 列stringにある"string"に複数のpolling_locationがあります

原因: polling_locationが複数指定されました。指定できるpolling_locationは1つのみです。

処置: ポーリングの宛先ディレクトリを1つのみ指定し、操作を再試行してください。

ORA-64709: 列stringにある"string"ではASM polling_locationはサポートされません

原因: polling_locationにASMベースの場所が指定されました。非ASMベースのpolling_locationsのみサポートされます。

処置: 非ASMポーリング宛先を1つ指定して、操作を再試行してください。

ORA-64711: 記憶域の宛先はASMディスクグループを参照しません

原因: 記憶域の宛先は非ASM記憶域の場所を参照していました。ASMベースの記憶域の宛先のみ使用できます。操作はロール・バックされました。

処置: 構文エラーを修正してから、操作を再試行してください。

ORA-64713: stringにリクエストされたサイズstringは小さすぎます。すでにstringを使用しています

原因: 記憶域の宛先用にリクエストされたサイズは現在のサイズより小さい値でした。

処置: リクエストされたサイズを増やしてから、操作を再試行してください。

ORA-64714: stringにリクエストされたサイズstringは、合計利用可能領域stringより大きい値です

原因: 記憶域の宛先用にリクエストされたサイズは現在の使用済領域に現在の空き領域を加算した値を上回っていました。

処置: リクエストされたサイズを減らしてから、操作を再試行してください。

ORA-64715: ディスクグループstringの冗長性タイプ"string"が無効です

原因: 指定されたディスクグループの冗長性タイプは{NORMAL | HIGH | EXTERN}のいずれでもありませんでした。

処置: ディスクグループの冗長性タイプを修正してから、操作を再試行してください。

ORA-64716: 記憶域の場所stringの割当てサイズstringがディスクグループstringの割当てサイズstringと等しくありません

原因: 指定された記憶域の場所の最小割当てサイズは、指定されたディスクグループの割当て単位サイズと異なっていました。

処置: 別のディスクグループまたは別の記憶域の場所を指定し、操作を再試行してください。

ORA-64717: ネットワーク・チャンク・サイズstringがディスクグループstringの割当てサイズstringの倍数ではありません

原因: 構成済のネットワーク・チャンク・サイズは、指定されたディスクグループの割当て単位サイズの倍数ではありませんでした。

処置: 別のディスクグループを指定するか、ネットワーク・チャンク・サイズを再構成してから、操作を再試行してください。

ORA-64718: ディスクグループstringの割当てサイズstringが2のべき乗ではありません

原因: ディスクグループの割当て単位サイズは2のべき乗ではありませんでした。

処置: 別のディスクグループを指定し、操作を再試行してください。

ORA-64719: ディスクグループstringの割当てサイズstringが2メガバイトstringより小さい値です

原因: ディスクグループの割当て単位サイズが2MB未満でした。

処置: 別のディスクグループを指定し、操作を再試行してください。

ORA-64720: 記憶域の場所stringにコンテナが作成されていません

原因: 指定された記憶域の場所に対して記憶域が割り当てられておらず、初期化されていません。

処置: 記憶域の場所に別のディスクグループを指定し、ディスクグループのサイズを増やすか、記憶域の場所のサイズを減らしてから、操作を再試行してください。

ORA-64721: 予約された領域stringが最小予約stringより小さい値です

原因: 指定された記憶域の場所に対して記憶域が割り当てられておらず、初期化されていません。

処置: 記憶域の場所に別のディスクグループを指定し、ディスクグループのサイズを増やすか、記憶域の場所のサイズを減らしてから、操作を再試行してください。

ORA-64722: ドライブ数は0より大きくする必要があります

原因: 指定されたテープ・ドライブ数がNULLか、ゼロ以下でした。

処置: テープ・ドライブ数を0 (ゼロ)より大きい値に指定し、操作を再試行してください。

ORA-64723: リストア操作に予約するドライブ数はゼロ以上である必要があります

原因: リストア操作用に予約されるテープ・ドライブ数がNULLか、ゼロ未満でした。

処置: リストア操作用に予約されるテープ・ドライブ数をゼロ以上に指定し、操作を再試行してください。

ORA-64724: リストア・ドライブ数stringが大きすぎます。string未満にする必要があります

原因: リストア操作用に予約されるテープ・ドライブ数が使用可能なドライブの合計数以上でした。リストア操作用に予約されるテープ・ドライブ数は、使用可能なドライブの合計未満である必要があります。

処置: リストア操作用に予約されるテープ・ドライブ数を使用可能なドライブの合計数より小さい値に指定し、操作を再試行してください。

ORA-64725: ストリーム数は0より大きくする必要があります

原因: ストリーム数がゼロ以下でした。

処置: ストリーム数をゼロより大きい値に指定し、操作を再試行してください。

ORA-64726: ストリーム数stringが大きすぎます。string未満にする必要があります

原因: ストリーム数が使用可能なドライブの合計数より大きい値でした。ストリーム数は、使用可能なドライブの合計数より小さくする必要があります。

処置: 使用可能なストリーム数を減らしてから、操作を再試行してください。

ORA-64727: コピー数stringが1から4の範囲に入っていません

原因: コピー数がNULLか、1以上4以下の範囲外でした。

処置: コピー数を1から4の範囲内に指定し、操作を再試行してください。

ORA-64728: レプリケーション・サーバー名の長さstringが長すぎます

原因: レプリケーション・サーバー名が128文字を超えていました。

処置: レプリケーション・サーバー名を128文字未満にし、操作を再試行してください。

ORA-64729: レプリケーション・サーバーのプロキシ・ポートstringはゼロよりも大きい必要があります

原因: レプリケーション・サーバー・プロキシ・ポート番号がゼロ以下でした。

処置: レプリケーション・サーバー・プロキシ・ポート番号をゼロより大きい値に指定し、操作を再試行してください。

ORA-64730: レプリケーション・サーバーのプロキシURLは指定されましたが、プロキシ・ポートがNULLです

原因: レプリケーション・サーバー・プロキシURLが指定されましたが、プロキシ・ポート番号が指定されていません。プロキシURLまたはプロキシ・ポートのいずれかを指定した場合、両方を指定する必要があります。

処置: レプリケーション・サーバーURLとレプリケーション・サーバー・プロキシ・ポート番号の両方を指定し、操作を再試行してください。

ORA-64731: レプリケーション・サーバーのプロキシ・ポートは指定されましたが、プロキシURLがNULLです

原因: レプリケーション・サーバー・プロキシ・ポート番号が指定されましたが、プロキシURLが指定されていません。プロキシURLまたはプロキシ・ポートのいずれかを指定した場合、両方を指定する必要があります。

処置: レプリケーション・サーバーURLとレプリケーション・サーバー・プロキシ・ポート番号の両方を指定し、操作を再試行してください。

ORA-64732: レプリケーション・ホストでHTTPサーバーが構成されていません

原因: レプリケーション・ホスト・サイトでHTTPサーバーが構成されていません。

処置: レプリケーション・ホスト・サイトでHTTPサーバーが構成してから、操作を再試行してください。

ORA-64733: BP_KEY stringを持つ個別バックアップ・ピースを移動きません; KEEPバックアップではありません

原因: 単体のバックアップ・ピースを移動しようとしましたが、このバックアップ・ピースがメンバーのバックアップ・セットはKEEPバックアップではありませんでした。

処置: KEEPバックアップ・セットのメンバーであるバックアップ・ピース・キーを指定し、操作を再試行してください。

ORA-64735: 不明なインカネーションがリカバリ・アプライアンスで検出されました。カタログの再同期が必要です

原因: 新しいインカネーションに属する新しいアーカイブ・ログまたはバックアップ・セットがリカバリ・アプライアンスで受信されました。

処置: RMANを使用して、リカバリ・カタログとしてリカバリ・アプライアンスに、ターゲット・データベースとしてプライマリ・データベースに接続し、RESYNC CATALOG RMANコマンドを使用して再同期化操作を実行してください。このエラーが(レプリケートされたリカバリ・アプライアンス設定の)リカバリ・アプライアンスのダウンストリームで発生した場合、アップストリーム・リカバリ・アプライアンスで同じエラーが修正されると、調整操作によってこのエラーは自動的に修正されます。

ORA-64736: タスクIDstring (タイプstring)がstring回中断されました。

原因: 指定されたタスクが予期しない回数再開されました。リソースの競合がある場合、タスクは中断されます。これは単なる警告です。リカバリ・アプライアンスの問題を必ずしも示すものではありません。

処置: このような問題が長期間解決しない場合、Oracleサポート・サービスに問い合せてください。

ORA-64737: データファイルが見つからないため、データベースstringの全体バックアップをコピーできません

原因: データベース全体バックアップをテープまたはレプリケートされたリカバリ・アプライアンスに作成中、1つ以上のデータファイルのレベル0バックアップがありませんでした。

処置: RA_SBT_TEMPLATE_MDFビューを問い合せて、バックアップがないデータファイルを確認してください。「永久的に増分」バックアップ計画を使用している場合、指定されたデータベースに対してレベル0増分バックアップを実行してから、操作を再試行してください。

ORA-64738: データベースstringの保証付きコピーが一時停止しました

原因: 次の操作のいずれかを実行した結果、割り当てられたディスク領域より多くの領域がデータベースで使用されています。

- DISK_SPACE_RESERVE値を下げたUPDATE_DBを実行

- guaranteed_copyパラメータにYESを設定したUPDATE_PROTECTION_POLICY

- 指定されたデータベースのバックアップ・データが存在している場所でのDELETE_SBT_LIBRARY追加のバックアップ・データを許可する安全性が再計算できるようになるまで、新しいバックアップ・リクエストが停止する可能性があり、そうしないとバックアップ・データが失われる可能性があります。

処置: 適切なタイミングでバックアップがテープに書き込まれるようにすると、このイベントを回避できます。逆に、適切なタイミングでバックアップがテープに書き込まれない場合は、「原因」であげたアクティビティを回避する必要があります。

ORA-64739: データベースstringのRECOVERY_WINDOW_GOALが失われました。

原因: 保護ポリシーのリカバリ・ウィンドウ目標は、その範囲内の任意の時点までリストアおよびリカバリできることを示します。現在のバックアップ・セットの場合、これは不可能です。考えられる理由として、アーカイブ・ログ・バックアップの欠落、データファイル・バックアップの欠落、予約済ディスク領域の欠落があります。

処置: バックアップが定期的に実行されるようにしてください。予約済ディスク領域の値が目標を維持するのに十分高い値に設定されていることを確認します。DISK_RESERVED_SPACEパラメータとRECOVERY_WINDOW_SPACEパラメータについてRA_DATABASEビューを問い合せて、この2つのパラメータを比較し、目標を満たすのに十分な領域が用意されていることを確認します。ただし、DBMS_RA.UPDATE_PROTECTION_POLICYプロシージャを使用してDISK_RESERVED_SPACE値を増やし、追加バックアップが保存されるようにすることはできます。また、ディスクの領域を消費しているKEEPバックアップがないか確認し、テープまたは他のディスク・ストレージに移動するかどうかを決定してください。

ORA-64740: データベースstringのバックアップがUNPROTECTED_WINDOW期間以上にわたって見つかっていません

原因: 保護ポリシーにUNPROTECTED_WINDOWが指定され、少なくともその期間、リカバリ・アプライアンスでは指定のターゲット・データベースから十分なアーカイブ・ログ・バックアップまたはデータファイル・バックアップが受信されていません。

処置: 適切なタイミングでバックアップが実行されているか確認し、そのように設定されている場合は、REDOログまたはバックアップがリカバリ・アプライアンスに送信されているか確認してください。

ORA-64741: スケジューラstring (タスクstring (タイプstring)を実行)は、string回のリクエスト後に停止しませんでした。

原因: 指定されたリカバリ・アプライアンス・スケジューラ・プロセスを停止できませんでした。

処置: このような問題が長期間解決しない場合、Oracleサポート・サービスに問い合せてください。

ORA-64744: 引数stringがNULL、無効または範囲外です

原因: 引数に予期される値はNULL以外の有効な値ですが、渡された引数値はNULL、無効または範囲外でした。

処置: プログラムを確認し、NULL、無効または範囲外の引数値を転送しないよう、ルーチンのコール元を修正してください。

ORA-64745: 名前の長さはstring文字です。最大長はstringです。

原因: 名前の長さが制限を超えています。

処置: 名前を短くしてから、操作を再試行してください。

ORA-64746: 名前に無効な文字が含まれています。

原因: 名前が"_"、"-"、":"または数字で誤って始まっているか、英数字以外の文字が含まれています。文字列にある場合、他のすべての二重引用符は二重引用符のペアが隣接していることを確認してください。名前の途中で二重引用符を使用しないでください。

処置: 名前を変更して、無効な文字を除いてください。

ORA-64747: 名前に無効な文字"string"が含まれています。位置は[string]です。

原因: 名前が"_"、"-"、":"または数字で誤って始まっているか、英数字以外の文字が含まれています。文字列にある場合、他のすべての二重引用符は二重引用符のペアが隣接していることを確認してください。名前の途中で二重引用符を使用しないでください。

処置: 名前を変更して、無効な文字を除いてください。

ORA-64750: インスタンスstringがstringにアクセスできません。

原因: 操作に必要なファイルが見つかりませんでした。

処置: 指定されたインスタンスで指定されたファイルのファイル・システムが使用できることを確認してください。

ORA-64751: string中にレプリケーション設定エラーが発生しました。レプリケーション・サーバー: string、データベース: string。

原因: 指定されたデータベースのレプリケーションの構成および設定を完了できませんでした。

処置: ダウンストリーム・レプリケーション・サーバーが適切に構成され、すべてのネットワーク通信パスが有効であることを検証してください。

ORA-64752: 記憶域がデータベースstringの新しいREDOまたはバックアップに使用できません

原因: ポーリング位置からREDOをバックアップ中またはバックアップをコピー中に障害が発生しました。この状況は、次の理由のいずれかが原因と考えられます。

* 単体のバックアップ・ピースがデータベース保護ポリシーのDISK_RESERVE_SPACE値を超えました。* Guaranteed_copyが有効になっているのに、十分なデータがテープにスプールされていません。* 記憶域の場所のサイズの構成が正しくありません。

処置: DISK_RESERVED_SPACEの値および記憶域の場所の使用状況を確認してください。

ORA-64753: 不適切なオブジェクト・タイプが指定されました。stringが指定されましたが、stringが必要です

原因: APIコマンドに正しくないオブジェクト・タイプが指定されました。

処置: オブジェクト固有のAPIを使用してください。たとえば、'resume_sbt_library'ではなく、'resume_replication_server'を使用します。

ORA-64754: 関連付けられたテープまたはレプリケーション・オブジェクトを使用して操作を実行できません

原因: 'update_db'または'update_protection_policy'を実行し、保護ポリシーに関連付けられたレプリケーション・サーバーまたはテープ・ジョブを使用して記憶域の場所を変更しようとしましたが失敗しました。

処置: ターゲット保護ポリシーのテープ属性およびレプリケーション属性を持つ現在の保護ポリシーと同じ記憶域の場所を指定した一時保護ポリシーを作成し、一時保護ポリシーに更新してから、ターゲット保護ポリシーに最終的に更新してください。

ORA-64755: データベースstringの削除に失敗しました。リカバリ・アプライアンスが実行されていません

原因: データベースを削除しようとしましたが、管理者によってリカバリ・アプライアンスが非アクティブ化されています。

処置: リカバリ・アプライアンス管理者にDBMS_RA.STARTUP_RECOVERY_APPLIANCEを実行してもらい、delete_db()操作を再試行してください。

ORA-64756: データベースstringの削除に失敗しました。削除ジョブの完了時にエラーが発生しました

原因: バックグラウンド削除ジョブが予期せず失敗したため、データベースを削除できませんでした。

処置: 詳細は、Oracleサポート・サービスに連絡してください。

ORA-64757: BP_KEY stringを持つバックアップ・ピースをリストアできません

原因: エラーとなった指定のバックアップ・ピースをリストアしようとしました。次のメッセージにエラーの説明が表示されます。

処置: バックアップ・ピースが正しいか確認してください。破損している場合は、削除するか、置換します。

ORA-64760: データベースstringには、順序付け待機状態のタスクがstring日間を超えて存在しています。

原因: 指定されたデータベースには、デルタ・ストアに対してタイル表示にならなかったため、実行できないINDEX_BACKUPタスクがありました。増分バックアップ・ピースの対象のフル・バックアップがデルタ・ストアに見つからない場合、増分バックアップ・ピースはデルタ・ストアにタイル表示されません。

処置: データベースに欠落している増分バックアップを提供します。他の増分バックアップが見つからない場合、新しいフル・バックアップをデータベースに提供します。

ORA-64761: ディスク・グループstringはリカバリ・アプライアンスで使用できません

原因: リカバリ・アプライアンスのインストール・ソフトウェアでは、以前は用意されていなかったディスク・グループがcreate_storage_location APIまたはupdate_storage_location APIに提供されました。

処置: ra_updateプロシージャを実行し、ディスク・グループを処理してAPIを再試行します。

ORA-64762: タスクstring(タイプstring)がstring用に実行中です。

原因: ある程度の時間の経過後、指定されたタスクが完了しませんでした。これは単なる警告メッセージです。

処置: これらのエラーが繰り返される場合は、Oracleサポート・サービスに連絡してください。

ORA-64763: タスクstring(タイプstring)がstring用に実行された後に停止されました。

原因: 指定されたタスクは完了せず、ハングしていると推定されました。プロセスは停止し、再開されました。

処置: これらのエラーが繰り返される場合は、Oracleサポート・サービスに連絡してください。

ORA-64766: RMANを使用するバックアップの削除は保護ポリシーによって回避されます

原因: リカバリ・マネージャは、該当するリカバリ・アプライアンス保護ポリシーの'allow_backup_deletion'パラメータが「いいえ」のため、バックアップ・ピースを削除できません。

処置: 該当する保護ポリシーの'allow_backup_deletion'パラメータを「はい」に変更して、バックアップを削除できるようにします。

ORA-65000: プラガブル・データベース名が欠落しているか無効です

原因: 必要な有効なプラガブル・データベース名が存在しませんでした。

処置: 有効なプラガブル・データベース名を指定して文を再発行してください。

ORA-65001: 管理ユーザー名が欠落しているか無効です

原因: CREATE PLUGGABLE DATABASE文の構文に必要な有効な管理ユーザー名が存在しませんでした。

処置: 有効な管理ユーザー名を指定してCREATE PLUGGABLE DATABASE文を再発行してください。

ORA-65002: 管理ユーザー・パスワードが欠落しているか無効です

原因: CREATE PLUGGABLE DATABASE文の構文に必要な有効な管理ユーザー・パスワードが存在しませんでした。

処置: 有効な管理ユーザー・パスワードを指定してCREATE PLUGGABLE DATABASE文を再発行してください。

ORA-65003: XMLファイル名が欠落しているか無効です

原因: CREATE PLUGGABLE DATABASE文の構文に必要な有効なXMLファイル名が存在しませんでした。

処置: 有効なXMLファイル名を指定してCREATE PLUGGABLE DATABASE文を再発行してください。

ORA-65004: データベース・リンク名が欠落しているか無効です

原因: CREATE PLUGGABLE DATABASE文の構文に必要な有効なデータベース・リンク名が存在しませんでした。

処置: 有効なデータベース・リンク名を指定してCREATE PLUGGABLE DATABASE文を再発行してください。

ORA-65005: ファイルのファイル名パターンが欠落しているか無効です - string

原因: SOURCE_FILE_NAME_CONVERTまたはFILE_NAME_CONVERT句で、ソースまたは置換ファイル名パターンが欠落しているか無効でした。

処置: SOURCE_FILE_NAME_CONVERTまたはFILE_NAME_CONVERT句を修正してから、文を再発行してください。

ORA-65006: ENABLE PLUGGABLE DATABASE句が欠落しているか無効です

原因: CREATE DATABASE文の構文に必要なENABLE PLUGGABLE DATABASE句が存在しませんでした。

処置: 有効なENABLE PLUGGABLE DATABASE句を指定してCREATE DATABASE文を再発行してください。

ORA-65007: ENABLE PLUGGABLE DATABASE句が重複しています

原因: CREATE DATABASE文に、重複するENABLE PLUGGABLE DATABASE句が指定されていました。

処置: 有効なENABLE PLUGGABLE DATABASE句を指定してCREATE DATABASE文を再発行してください。

ORA-65008: SEED句が欠落しているか無効です

原因: CREATE DATABASE文の構文に必要なSEED句が存在しませんでした。

処置: 有効なSEED句を指定してCREATE DATABASE文を再発行してください。

ORA-65010: 最大数のプラガブル・データベースが作成されました

原因: ユーザーが、サポートされている数を超えるプラガブル・データベースを作成しようとしました。

処置: 多すぎるプラガブル・データベースを作成しないでください。

ORA-65011: プラガブル・データベースstringが存在しません

原因: ユーザーが、存在しないプラガブル・データベースを指定しようとしました。

処置: DBA_PDBSを確認し、それが存在しているか調べてください。

ORA-65012: プラガブル・データベースstringはすでに存在しています。

原因: ユーザーが、すでに存在している名前のプラガブル・データベースを作成しようとしました。

処置: DBA_PDBSを確認し、名前が存在しているか調べてください。

ORA-65013: CONTAINER句が無効です

原因: 無効なCONTAINER句が検出されました。

処置: 有効なCONTAINER句を指定してDDL文を再発行してください。

ORA-65014: SHARING句が無効です

原因: 無効なSHARING句が検出されました。

処置: 有効なSHARING句を指定してDDL文を再発行してください。

ORA-65015: コンテナ名が欠落しているか無効です

原因: ALTER SESSION SET CONTAINERまたはALTER USER ... SET|ADD|REMOVE CONTAINER_DATA文の構文に必要な有効なコンテナ名が存在しませんでした。

処置: 有効なコンテナ名を指定して文を再発行してください。

ORA-65016: FILE_NAME_CONVERTを指定する必要があります

原因: プラガブル・データベースの作成の一部として、データファイルおよびおそらくその他のファイルをコピーする必要がありました。しかし、Oracle Managed Files (OMF)が有効化されておらず、PDB_FILE_NAME_CONVERTが定義されておらず、FILE_NAME_CONVERT句の指定に失敗しました。

処置: OMFを有効化するかPDB_FILE_NAME_CONVERTシステム・パラメータを定義してから、CREATE PLUGGABLE DATABASE文を発行するか、FILE_NAME_CONVERT句を文の一部として指定してください。

ORA-65017: シード・プラガブル・データベースは削除または変更できません

原因: ユーザーが、シード・プラガブル・データベースを削除または変更しようとしましたが、それは許可されていませんでした。

処置: 正しいプラガブル・データベース名を指定してください。

ORA-65018: FILE_NAME_CONVERTまたはNOCOPYを指定する必要があります

原因: Oracle Managed Files (OMF)が有効化されておらず、PDB_FILE_NAME_CONVERTが定義されていませんでした。FILE_NAME_CONVERTまたはNOCOPY句が、データファイルを使用したプラガブル・データベースの作成の一部として指定されていませんでした。

処置: OMFを有効化するかPDB_FILE_NAME_CONVERTシステム・パラメータを定義してから、CREATE PLUGGABLE DATABASE文を発行するか、FILE_NAME_CONVERT句またはNOCOPYを文の一部として指定してください。

ORA-65019: プラガブル・データベースstringはすでにオープンしています

原因: すでに開いているプラガブル・データベースにサービスを開こうとしました。

処置: V$PDBSビューのOPEN_MODE列を確認してください。

ORA-65020: プラガブル・データベースstringはすでにクローズしています

原因: すでに閉じているプラガブル・データベースにサービスを閉じようとしました。

処置: V$PDBSビューのOPEN_MODE列を確認してください。

ORA-65021: SHARING句の使用方法が正しくありません

原因: 予期しないコンテキストでSHARING句が検出されました。

処置: Oracle提供のスクリプトの外部でSHARING句を使用しないでください。

ORA-65022: CONTAINER句はすでに使用されています

原因: 文に複数のCONTAINER句が含まれていました。

処置: 重複しているCONTAINER句を削除してください。

ORA-65023: コンテナstringにアクティブなトランザクションが存在します

原因: 文が、現在のコンテナ内で新しいトランザクションを作成しようとしましたが、別のコンテナにアクティブなトランザクションがありました。

処置: アクティブなトランザクションがあるコンテナに切り替えてそのアクティブなトランザクションをコミット、ロールバックまたは連結解除してから、別のコンテナに新しいトランザクションの作成を試行する文の発行を試みてください。

ORA-65024: プラガブル・データベースstringはオープンしていません。

原因: 開いていないプラガブル・データベースで操作を実行しようとしました。

処置: 適切なオーブン・モードを使用してプラガブル・データベースを開いてください。

ORA-65025: プラガブル・データベースstringはすべてのインスタンスでクローズしていません。

原因: すべてのOracle RACインスタンスで閉じていないプラガブル・データベースで操作を実行しようとしました。

処置: プラガブル・データベースをすべてのインスタンスで閉じてから、操作を再試行してください。

ORA-65026: XMLメタデータ・ファイル・エラー: string

原因: XMLメタデータ・ファイルを解析しようとするか、それに書き込もうとしてエラーが発生しました。

処置: XMLメタデータ・ファイルが存在し、読取り可能であることを確認してください。

ORA-65027: (string - string)のノードまたは値の取得中にXMLメタデータ・ファイル・エラーが発生しました

原因: XMLメタデータ・ファイルを解析しようとしてエラーが発生しました。

処置: XMLメタデータ・ファイルを確認して修正してください。

ORA-65028: パスstringにあるプラグイン・データ・ファイルを開くことができません

原因: データファイルをオープンしようとしてエラーが発生しました。

処置: データファイルがそのパスに存在していることを確認してください。

ORA-65029: ローカル・ユーザーは、共通権限やロールを付与または取り消しできません

原因: ローカル・ユーザーがCONTAINER=ALLを指定してGRANTまたはREVOKE文を発行しましたが、それは無効です。

処置: CONTAINER=ALLを文から削除してください。

ORA-65030: ローカル・ユーザーまたはロールには共通権限を付与できません

原因: 共通ユーザーがCONTAINER=ALLを指定し、権限受領者としてローカル・ユーザーまたはロールを指定してGRANT文を発行しましたが、それは無効です。

処置: ローカル権限を付与しようとする場合は、文からCONTAINER=ALLを削除してください。共通権限を付与しようとする場合は、権限受領者のリストからローカル・ユーザーおよびロールを削除してください。

ORA-65031: ローカル・ユーザーまたはロールから共通権限を取り消すことはできません

原因: 共通ユーザーがCONTAINER=ALLを指定し、権限受領者としてローカル・ユーザーまたはロールを指定してREVOKE文を発行しましたが、それは無効です。

処置: ローカル権限を取り消そうとする場合は、文からCONTAINER=ALLを削除してください。共通権限を取り消そうとする場合は、権限受領者のリストからローカル・ユーザーおよびロールを削除してください。

ORA-65032: ローカル・ロールは、現在のコンテナ内でのみ付与または取り消しできます

原因: ユーザーがCONTAINER=ALLを指定し、付与または取り消すロールの中にローカル・ロールをリストしてGRANTまたはREVOKE文を発行しましたが、それは無効です。

処置: ローカル・ロールを取り消そうとする場合は、文からCONTAINER=ALLを削除してください。共通権限またはロール、あるいはその両方を取り消そうとする場合は、付与または取り消すロールのリストからローカル・ロールを削除してください。

ORA-65033: ローカル・オブジェクトでは、共通権限を付与または取り消しできません

原因: CONTAINER=ALLを指定し、権限を付与または取り消す対象としてローカル・オブジェクトを指定してGRANTまたはREVOKE文が発行されましたが、それは無効です。

処置: CONTAINER=ALLを文から削除してください。

ORA-65034: PDBが説明する出力ファイルが指定されていません

原因: ユーザーが、出力XMLファイルの場所を指定せずにプラガブル・データベースを記述しようとしました。

処置: 記述する出力ファイルの場所を指定してください。

ORA-65035: stringからプラガブル・データベースを作成できません

原因: プラガブル・データベースに、リカバリが必要となる進行中またはアクティブなトランザクションがありました。

処置: トランザクションのリカバリが実行されるように、再びクローニングする前に読取り/書込みモードでプラガブル・データベースをオープンしてください。

ORA-65036: プラガブル・データベースstringは必要なモードでオープンされていません

原因: 不適切なオープン・モードでプラガブル・データベースに操作を実行しようとしました。

処置: この操作に必要なモードでプラガブル・データベースを開いてください。

ORA-65037: ローカル・ユーザーでは、共通権限を付与または取り消しできません

原因: CONTAINER=ALLを指定し、権限を付与または取り消す対象としてローカル・ユーザーを指定してGRANTまたはREVOKE文が発行されましたが、それは無効です。

処置: CONTAINER=ALLを文から削除してください。

ORA-65039: コンテナ識別子の列がないか、CONTAINER_DATAオブジェクトの定義に予期しない型があります

原因: 定義にCONTAINER_DATA句が含まれる表またはビューに、データが属するコンテナを識別するために使用される列がないか、その列が予期しないタイプでした。

処置: 文を修正して再入力してください。

ORA-65040: プラガブル・データベース内からの操作は許可されていません

原因: ルート・コンテナでのみ実行できる操作を実行しようとしました。

処置: ルート・コンテナに切り替えて、その操作を実行してください。

ORA-65041: このユーザーのCONTAINER_DATA属性は変更できません

原因: ユーザーSYSまたはSYSBACKUPのCONTAINER_DATA属性を変更しようとしましたが、それは許可されていません。

処置: ユーザーSYSまたはSYSBACKUPのCONTAINER_DATA属性を変更しないでください。

ORA-65042: すでに既存のコンテナで使用されている名前です

原因: その名前は別のコンテナによってすでに使用されていました。

処置: 有効な名前を指定してください。

ORA-65043: TABLESPACEキーワードが必要です。

原因: TABLESPACEキーワードが欠落していました。

処置: TABLESPACEキーワードを指定してください。

ORA-65044: STORAGEキーワードに続くオプションが欠落しているか無効です

原因: MAXSIZEまたはMAX_SHARED_TEMP_SIZE以外のオプションが指定されました。

処置: 有効なオプションのみを指定してください。

ORA-65045: プラガブル・データベースが限定モードではありません

原因: 限定モードではないプラガブル・データベースで操作を実行しようとしました。

処置: プラガブル・データベースを限定モードで開いてください。

ORA-65046: プラガブル・データベース外からの操作は許可されていません

原因: プラガブル・データベース内からのみ実行できる操作を実行しようとしました。

処置: プラガブル・データベースに切り替えて、その操作を実行してください。

ORA-65047: オブジェクトstring.stringが無効であるか、CDB$ROOTでエラー付きでコンパイルされました

原因: 無効であるかCDB$ROOTでエラーありでコンパイルされたオブジェクトにメタデータ・リンクDDLを発行しようとしました。

処置: CDB$ROOTのオブジェクトの妥当性を確認してください。

ORA-65048: プラガブル・データベースstringで現在のDDL文を処理中にエラーが発生しました

原因: プラガブル・データベースの1つで文を実行中にエラーが発生しました。

処置: プラガブル・データベースの障害の原因を調べてください。

ORA-65049: CDB$ROOTでは、ローカル・ユーザーまたはロールの作成は許可されていません

原因: CDB$ROOTでローカル・ユーザーまたはロールを作成しようとしました。

処置: 共通ユーザーまたはロールを作成しようとする場合は、CONTAINER=ALLを指定してください。

ORA-65050: 共有DDLはCDB$ROOTでのみ使用できます

原因: プラガブル・データベースで共有DDLを発行しようとしました。

処置: CDB$ROOTに切り替え、そこで共有DDLを発行してください。

ORA-65051: 有効なコンテナ識別子がありません

原因: 有効なコンテナ識別子が指定されていませんでした。

処置: 有効なコンテナ識別子を指定してください。

ORA-65052: この文には、コンテナの有効範囲が異なる操作が含まれています

原因: すべてのコンテナに適用される1つの操作と、ローカル・コンテナにのみ適用される別のものを1つの文に結合しようとしました。

処置: それらの操作は別々の文で実行してください。

ORA-65053: グローバル・ユーザーはセッションのコンテナを変更できません。

原因: グローバル・ユーザーが、ALTER SESSION SET CONTAINER文を使用してコンテナを変更しようとしました。

処置: この操作は、グローバル・ユーザーには許可されていません。

ORA-65054: 要求されたモードでプラガブル・データベースをオープンすることはできません。

原因: CDBのものとは互換性のないモードで、プラガブル・データベースを開こうとしました。

処置: 最初にCDBを互換性のあるモードで開いてから、操作を再試行してください。

ORA-65056: プラガブル・データベースでは、CONTAINER_DATA属性は使用されていません。

原因: プラガブル・データベースに接続しているユーザーが、CONTAINER_DATA属性を変更しようとしましたが、それは無効です。

処置: プラガブル・データベースに接続しているユーザーが表示できるのは、自分に適切な権限が付与され、そのプラガブル・データベースまたはCDB全体に関連しているCONTAINER_DATAオブジェクトの行のみです。このデータを表示できるかどうかはCONTAINER_DATA属性によって制御されません。それを使用して制御できるのは、CDBのCDB$ROOTに接続しているときに特定のコンテナに関連している行を表示できるかどうかのみです。

ORA-65057: CONTAINER_DATA属性には常に現在のコンテナが含まれている必要があります

原因: ALTER USER ... SET|REMOVE CONTAINER_DATA = ... 文を発行するユーザーが、CONTAINER_DATA属性から現在のコンテナを除外しようとしました。

処置: CONTAINER_DATA属性には常に現在のコンテナを含めてください。

ORA-65058: オブジェクト固有のCONTAINER_DATA属性を指定できるのは、CONTAINER_DATAオブジェクトのみです

原因: オブジェクト固有のCONTAINER_DATA属性を変更するALTER USER文で参照されているオブジェクトが、CONTAINER_DATA表またはビューではありませんでした。

処置: その文で参照されているオブジェクトは必ずCONTAINER_DATA表またはビューにしてください。

ORA-65059: CONTAINER_DATA句でコンテナ名が重複しています

原因: CONTAINER_DATA句で、いずれかのコンテナの名前への重複する参照が見つかりました。

処置: 複数回出現するコンテナ名がないようにしてください。

ORA-65060: CONTAINER_DATA属性が設定されていません

原因: ユーザーが、明示的に設定されていないまたはDEFAULTに設定されているオブジェクト固有のCONTAINER_DATA属性にコンテナを追加しようとしたか、明示的に設定されていないかDEFAULTに設定されているCONTAINER_DATA属性からコンテナを削除しようとしました。

処置: 明示的に設定されていないまたはDEFAULTに設定されているオブジェクト固有のCONTAINER_DATA属性にコンテナを追加したり、明示的に設定されていないかDEFAULTに設定されているCONTAINER_DATA属性からコンテナを削除しないでください。

ORA-65061: 指定されたコンテナの一部がCONTAINER_DATA属性に属していません

原因: ユーザーが、CONTAINER_DATA属性から、それに属していないコンテナを削除しようとしました。

処置: CONTAINER_DATA属性から、それに属していないコンテナを削除しないでください。

ORA-65062: CONTAINER_DATA属性がALLに設定されています

原因: ユーザーが、現在の値がALLであるCONTAINER_DATA属性に(またはそれから)、コンテナを追加(または削除)しようとしましたが、それはサポートされていません。

処置: 現在の値がALLであるCONTAINER_DATA属性に(またはそれから)、コンテナを追加(または削除)しないでください。

ORA-65063: CONTAINER_DATA句はすでに指定されています

原因: CONTAINER_DATA句が2回指定されました。

処置: CONTAINER_DATA句は1つのみ指定してください。

ORA-65064: XMLメタデータ・ファイルのコンテンツが正しくありません

原因: XMLメタデータ・ファイルのコンテンツが実際のファイル・プロパティと異なっていました。

処置: XMLメタデータ・ファイルを確認して修正してください。

ORA-65065: ローカル・ユーザーまたはロールは、現在のコンテナ内でのみ変更できます

原因: CONTAINER=ALLを指定し、変更対象のユーザーまたはロールの中にローカル・ユーザーまたはロールをリストしてALTER USERまたはALTER ROLE文を発行しましたが、それは無効です。

処置: ローカル・ユーザーまたはロールを変更しようとしている場合は、CONTAINER=CURRENTを指定してください。共通ユーザーまたはロールを変更しようとしている場合は、変更対象のロールのリストからローカル・ユーザーまたはロールを削除してください。

ORA-65066: 指定された変更はすべてのコンテナに適用する必要があります

原因: 現在のコンテナに、指定した変更を適用しようとしました。

処置: CONTAINER=ALLを指定してください。

ORA-65067: ローカル・ロールを参照するDEFAULT ROLE句を適用できるのは現在のコンテナのみです

原因: DEFAULT ROLE句を使用してすべてのコンテナにわたってローカル・ロールを参照しようとしました。

処置: ローカル・ロールをデフォルト・ロールとして設定しようとしている場合は、CONTAINER=CURRENTを指定してください。共通ロールをデフォルト・ロールとして設定しようとしている場合は、DEFAULT ROLE句で参照されているロールのリストからローカル・ロールを削除してください。

ORA-65068: プラガブル・データベースが切断された後に起動されるトリガーは定義できません

原因: プラガブル・データベースが切断された後に起動されるトリガーを作成しようとしました。この型のトリガーは、サポートされていません。

処置: プラガブル・データベースが切断された後に起動されるトリガーを作成しないでください。

ORA-65069: プラガブル・データベースにはAFTER DB_ROLE_CHANGEトリガーを定義できません

原因: スタンバイ・データベースからプライマリへ、またはその逆にロールの変更が行われた後に起動されるプラガブル・データベース・トリガーを作成しようとしました。この型のトリガーは、サポートされていません。

処置: プラガブル・データベースに対してトリガーを作成するときにAFTER DB_ROLE_CHANGEを指定しないでください。

ORA-65070: AFTER CLONEトリガーを作成できるのはプラガブル・データベースのみです

原因: スキーマまたはデータベースにAFTER CLONEトリガーを作成しようとしました。この型のトリガーは、サポートされていません。

処置: スキーマまたはデータベースにトリガーを作成するときにAFTER CLONEを指定しないでください。

ORA-65071: BEFORE UNPLUGトリガーを作成できるのはプラガブル・データベースのみです

原因: スキーマまたはデータベースにBEFORE UNPLUGトリガーを作成しようとしました。この型のトリガーは、サポートされていません。

処置: スキーマまたはデータベースにトリガーを作成するときにBEFORE UNPLUGを指定しないでください。

ORA-65072: ユーザーは、トリガーが作成されるプラガブル・データベースに接続している必要があります

原因: プラガブル・データベースに接続していないときに、プラガブル・データベースにデータベース・イベント・トリガーを作成しようとしました。これはサポートされていません。

処置: データベース・イベント・トリガーを作成する必要があるプラガブル・データベースに接続してから、そのようなトリガーの作成を試行してください。

ORA-65073: プラガブル・データベースのクローニング前に起動されるトリガーは定義できません

原因: プラガブル・データベースがクローニングされる前に起動されるトリガーを作成しようとしました。この型のトリガーは、サポートされていません。

処置: プラガブル・データベースがクローニングされる前に起動されるトリガーを作成しないでください。

ORA-65074: 共通ユーザーではエディションはサポートされていません

原因: 共通ユーザーに対してエディションをサポートしようとしました。

処置: 共通ユーザーにはエディションを有効化しないでください。

ORA-65080: プラガブル・データベース名を判別できません

原因: データベースIDをプラガブル・データベース名にマップしようとしました。

処置: Oracleサポート・サービスに問い合せてください。

ORA-65081: データベースまたはプラガブル・データベースは、読取り専用モードでオープンしていません

原因: 読取り専用モードで開いていないデータベースまたはプラガブル・データベースに操作を実行しようとしました。

処置: データベースまたはプラガブル・データベースを読取り専用モードで開いてから、操作を再試行してください。

ORA-65082: プラガブル・データベースをこれ以上追加できません: 制限数stringを超えました

原因: 制御ファイルには、これ以上プラガブル・データベースを追加する空きがありません。

処置: 制御ファイルを再作成してください。

ORA-65083: 進行中のプラガブル・データベース(PDB)の停止

原因: プラガブル・データベースは強制終了中です。

処置: しばらく待ってから操作を再試行してください。

ORA-65084: オブジェクトstring.stringはルートに存在しません

原因: ルートに存在していない共通オブジェクトを作成しようとしました。

処置: すべてのコンテナでオブジェクトを作成するcatcon.plを使用してスクリプトを起動します。

ORA-65085: プラガブル・データベースを読取り専用モードでオープンすることはできません

原因: プラガブル・データベースは作成されていましたが、オープンされていませんでした。

処置: 最初にプラガブル・データベースを読取り/書込みモードまたは限定モードで開く必要があります。

ORA-65086: プラガブル・データベースをオープン/クローズできません

原因: プラガブル・データベースは切断されました。

処置: そのプラガブル・データベースには、削除のみ実行できます。

ORA-65087: プラガブル・データベース内からはOracleが提供する操作を実行できません

原因: ルート・コンテナでのみ実行できるOracle提供のスクリプト内の操作を実行しようとしました。

処置: その操作がルート・コンテナで必要であることを確認してから、ルート・コンテナに切り替えて操作を実行してください。

ORA-65088: データベースのオープンを再試行する必要があります

原因: 制御ファイルとデータ辞書の間に非一貫性が見つかり、データベースのオープン中に修正されました。データベースのオープンを再度実行する必要があります。

処置: データベースのオーブンを再試行してください。

ORA-65089: プラガブル・データベースはクリーンではありません

原因: そのプラガブル・データベースはいずれの場所でも開いていませんが、まだクリーンとマークされていませんでした。

処置: クリーンアップが完了するまで待ち、再試行してください。

ORA-65090: この操作は、コンテナ・データベースでのみ許可されています

原因: ユーザーがCDB内でのみ許可される操作を実行しようとしました。

処置: CDBに接続し、この操作を実行してください。

ORA-65091: stringに関する操作が許可されているのはプラガブル・データベースのみです

原因: ルート・コンテナでのみ実行できるUNDO表領域またはロールバック・セグメント操作を実行しようとしました。

処置: ルート・コンテナに切り替えて、UNDO表領域またはロールバック・セグメント操作を実行してください。

ORA-65092: 有効範囲の異なるシステム権限が'string'に付与されました

原因: 別の有効範囲で付与されたシステム権限を取り消そうとしました。ユーザーが、現在のコンテナ内で共通権限を取り消そうとしたか、コンテナ・データベース(CDB)内でローカル権限を取り消そうとしました。

処置: CONTAINER句の適切な値を指定してください。

ORA-65093: マルチテナント・コンテナ・データベースが適切に設定されていません

原因: 初期化パラメータ・ファイルでマルチテナント・コンテナ・データベースに正しいパラメータを設定せずに、マルチテナント・コンテナ・データベースをオープンしようとしました。

処置: 初期化パラメータ・ファイルでマルチテナント・コンテナ・データベースに'enable_pluggable_database=true'パラメータを設定し、データベースを再起動してください。

ORA-65094: ローカル・ユーザーまたはロール名が無効です

原因: ローカル・ユーザーまたはロールに対して無効な名前を指定して、ローカル・ユーザーまたはロールを作成しようとしました。ユーザーおよびロール名に対する通常のルールの他に、ローカル・ユーザーおよびロール名がC##またはc##で始めることはできません。

処置: 有効なローカル・ユーザーまたはロール名を指定してください。

ORA-65095: 共通オブジェクト名が無効です

原因: 共通オブジェクトに有効ではない名前を使用して共通オブジェクトを作成しようとしました。オブジェクト名に対する通常のルールのほかに、共通オブジェクト名はASCII文字のみで構成する必要があります。

処置: 有効な共通オブジェクト名を指定してください。

ORA-65096: 共通ユーザーまたはロール名が無効です

原因: 共通ユーザーまたはロールに有効ではない名前を使用して共通ユーザーまたはロールを作成しようとしました。ユーザーおよびロール名に対する通常のルールのほかに、共通ユーザーおよびロール名はC##またはc##で始まり、ASCII文字のみで構成されている必要があります。

処置: 有効な共通ユーザーまたはロール名を指定してください。

ORA-65097: 無効な引数がCDB$VIEW関数に指定されました

原因: CDB$VIEWは、<owner>.<tablename>形式の有効な表名に適用できます。

処置: 文を修正してください。

ORA-65098: CDB$VIEW関数でサポートされていないデータ型です

原因: サポートされていないデータ型の列が、CDBビューから選択されました。

処置: その列を選択リストから削除してください。

ORA-65099: CDBがオープンでない場合、操作を実行できません

原因: コンテナ・データベース(CDB)がオープンしている必要がある操作をプラガブル・データベース内で実行しようとしました。*処置: CDBをオープンしてから、操作を再発行してください。

処理: ありません。

ORA-65100: パス接頭辞が欠落しているか無効です - string

原因: パス接頭辞が欠落しているか無効でした。

処置: PATH_PREFIX句を修正してから、文を再発行してください。

ORA-65101: コンテナ・データベースが正しく設定されていません

原因: コンテナ・データベース制御ファイル以外を使用して、コンテナ・データベース(CDB)を起動しようとしました。

処置: CDBの新しい制御ファイルを作成してください。

ORA-65102: インスタンス名が欠落しているか無効です

原因: ALTER PLUGGABLE DATABASE文の構文に必要な有効なインスタンス名が存在しませんでした。

処置: 有効なインスタンス名を指定して文を再発行してください。

ORA-65103: READ ONLYモードでオープンされているPDBにはUPGRADEを指定できません

原因: ALTER PLUGGABLE DATABASE ... OPEN UPGRADEが指定されましたが、ルートはREAD ONLYでオープンされているため、指定したPDBもREAD ONLYでオープンされます。UPGRADEは、READ ONLYでオープンされているPDBに対して指定できません。

処置: UPGRADEを指定せずに文を再発行するか、ルートをREAD WRITEモードで再オープンして文を再発行してください。

ORA-65104: 非アクティブなプラガブル・データベースでの操作は許可されていません

原因: プラガブル・データベースのステータスがINACTIVEでした。まだ作成中であるか、作成操作中にエラーが発生しました。

処置: ステータスがCREATEDに変わるまで待機するか、エラーの場合はプラガブル・データベースを削除し、再作成してください。

ORA-65105: プラガブル・データベース#stringのSYSTEMデータ・ファイルが見つかりません

原因: プラガブル・データベースのSYSTEM表領域でCREATE CONTROLFILE文にデータファイルが指定されていませんでした。

処置: データファイルを指定して、CREATE CONTROLFILE文を再実行してください。

ORA-65106: プラガブル・データベース#string (string)は無効状態です

原因: プラガブル・データベースのCREATE CONTROLFILE文にデータファイルが指定されていませんでした。

処置: プラガブル・データベースを削除するか、データファイルを指定してCREATE CONTROLFILE文を再実行してください。

ORA-65107: インスタンスstringで現在のタスクを処理中にエラーが発生しました

原因: Oracle RACインスタンスの1つでプラガブル・データベース・タスクの実行中にエラーが発生しました。

処置: インスタンスの障害の原因を調べてください。

ORA-65108: 別のコンテナに属するカーソルからの使用は無効です

原因: 異なるコンテナで解析または実行されたカーソルを使用しようとしました。

処置: SET CONTAINER文の不適切な使用がないか調べてください。同じコンテナ内でのみ、カーソルを解析、実行、フェッチ、クローズしてください。

ORA-65109: 操作はCDB$ROOTで許可されていません

原因: コンテナ・データベースのルートでサポートされていない操作を実行しようとしました。

処置: プラガブル・データベースに切り替えて、その操作を実行してください。

ORA-65110: 無効なインスタンス名が指定されました

原因: インスタンス句で無効または非アクティブなインスタンス名を使用して、プラガブル・データベースの状態を変更しようとしました。

処置: 有効かつアクティブなインスタンス名を指定してください。

ORA-65111: 同じインスタンスに再配置できません

原因: プラガブル・データベースを現行のインスタンスに移動しようとしました。

処置: 現行のインスタンスとは異なるインスタンスを指定してください。

ORA-65112: プラガブル・データベースstringはスタンバイ・データベースのすべてのインスタンスでクローズしていません

原因: プラガブル・データベースがプライマリ・データベース上で切断されたか、削除されたか、あるいは名前を変更されたため、メディア・リカバリは停止しました。

処置: プラガブル・データベースをすべてのインスタンスで閉じてから、リカバリを再起動してください。

ORA-65113: PDBのMAX_PDB_STORAGEプロパティの値が小さすぎます

原因: ALTERまたはCREATE PLUGGABLE DATABASE文で指定されたMAX_PDB_STORAGEの値がコンテナのデータファイルと一時ファイルの現在の領域使用量を下回っています。

処置: MAX_PDB_STORAGEに高い値を指定してください。

ORA-65114: コンテナ内の領域の使用量が高すぎます

原因: 現在のコンテナの領域使用量がコンテナのMAX_PDB_STORAGEの値を超えました。

処置: ALTER PLUGGABLE DATABASE文を使用してMAX_PDB_STORAGEに高い値を指定してください。

ORA-65115: CDBリソース・プランstringにPDBディレクティブがstring個超あります

原因: サポートされている数よりも多くのディレクティブを使用するために、指定されたマルチテナント・コンテナ・データベース(CDB)のリソース・プランを作成または更新しようとしました。

処置: このデータベースでアクティブではないプラガブル・データベース(PDBs)に対するディレクティブを削除してください。

ORA-65116: 互換性のないデータベース・キャラクタ・セットです

原因: コンテナ・データベースのデータベース・キャラクタ・セットは、差し込まれているプラガブル・データベースのデータベース・キャラクタ・セットのスーパーセットではありませんでした。

処置: 互換性のあるデータベース・キャラクタ・セットを持つコンテナ・データベースにプラガブル・データベースを差し込んでください。

ORA-65117: CONTAINER句は、コンテナ・データベースに接続された場合のみ指定できます

原因: コンテナ・データベース(CDB)に接続していないときに、CONTAINER句が指定されました。

処置: CONTAINER句なしでその文を再度入力してください。

ORA-65118: プラガブル・データベースに影響を与える操作は、別のプラガブル・データベースから実行できません

原因: 異なるプラガブル・データベースに接続しているときに、プラガブル・データベースに影響を与える操作を実行しようとしました。

処置: 必要なプラガブル・データベースに接続し、その操作を実行してください。

ORA-65119: 互換性のない各国語キャラクタ・セットです

原因: コンテナ・データベースの各国語キャラクタ・セットは、差し込まれているプラガブル・データベースの各国語キャラクタ・セットと同じではありませんでした。

処置: 同じ各国語キャラクタ・セットを持つコンテナ・データベースにプラガブル・データベースを差し込んでください。

ORA-65120: XMLメタデータ・ファイルの文字セットIDが正しくありません

原因: プラグインされているプラガブル・データベースに対するXMLメタデータ・ファイルが、データベースあるいはコンテナ・データベースに対して無効な各国語キャラクタ・セットIDを含んでいました。これは、XMLファイルが手動で変更されたとき、ディスク上で破損しているとき、あるいはユーザー定義のキャラクタ・セットがコンテナ・データベースのOracleホーム・ディレクトリにインストールされていないため、サポートされているキャラクタ・セットがコンテナ・データベースとプラガブル・データベースのソース・データベースで異なっているときに発生することがあります。

処置: プラガブル・データベースのメタデータXMLファイルを手動で変更した場合は、その元のファイルをリストアするか、そのソース・データベースからプラガブル・データベースを再作成してください。XMLファイルの手動変更はサポートされていません。プラガブル・データベースがユーザー定義のキャラクタ・セットを使用している場合、コンテナ・データベースのOracleホーム・ディレクトリにキャラクタ・セットがインストールされていることを確認してください。または、Oracleサポート・サービスに連絡してください。

ORA-65121: ALTER SESSION SET CONTAINERはこのクライアントから実行できません

原因: Oracle Database 12cリリース1以前のクライアントはこの機能をサポートしていません。

処置: クライアントをOracle Database 12cリリース1以降にアップグレードしてください。

ORA-65122: プラガブル・データベースのGUIDが既存のコンテナのGUIDと競合しています。

原因: プラガブル・データベースを作成中に、GUIDがコンテナ・データベースの既存のコンテナのGUIDと競合しました。

処置: そのプラガブル・データベースの作成を再試行するか、別のプラガブル・データベースのコピーを差し込む場合は、CREATE PLUGGABLE DATABASEにAS CLONE句を使用することを検討してください。

ORA-65123: このコンテキストではSET CONTAINER操作は実行できません

原因: そのような操作が禁止されているコンテキスト内でコンテナを設定しようとしました。

処置: システム・トリガーあるいはDMLコンテキスト内からコンテナを設定しないでください。

ORA-65125: 有効なXMLファイル名が必要です

原因: XML拡張子を持っていないファイル名を指定しようとしました。

処置: XMLファイルを指定してください。

ORA-65126: プラガブル・データベースstringは切断できません。

原因: そのプラガブル・データベースは正常にクローズしませんでした。そして、リカバリが必要なアクティブ・トランザクションがあります。

処置: トランザクションのリカバリが実行されるように、再び切断する前に読取り/書込みモードでプラガブル・データベースをオープンしてください。

ORA-65127: PDBリカバリの出力ファイルが指定されていません

原因: 出力XMLファイルの場所を指定せずにプラガブル・データベース(PDB)をリカバリしようとしました。

処置: リカバリの出力ファイルの場所を指定してください。

ORA-65128: PDBリカバリのデータ・ファイル名が指定されていません

原因: データ・ファイルの場所を指定せずにプラガブル・データベース(PDB)をリカバリしようとしました。

処置: リカバリのデータ・ファイルの場所を指定してください。

ORA-65129: プラガブル・データベースstringは再配置できません。

原因: そのプラガブル・データベースはすべてのインスタンスですでに開かれています。

処置: RELOCATE句を使用せずにプラガブル・データベースをクローズするか、あるいは別のインスタンスのプラガブル・データベースをクローズしてください。

ORA-65130: 複数のプラガブル・データベースを再配置することはできません。

原因: 複数のプラガブル・データベースを再配置しようとしました。

処置: 一度に1つのプラガブル・データベースをRELOCATEしてください。

ORA-65131: 機能stringはプラガブル・データベースではサポートされていません。

原因: プラガブル・データベースでサポートされていない機能を使用しようとしました。

処置: この機能をプラガブル・データベースで使用しないでください。

ORA-65134: エンディアンが一致しません

原因: コンテナ・データベースのエンディアンは、差し込まれているプラガブル・データベースのエンディアンと同じではありませんでした。

処置: 同じエンディアンを持つコンテナ・データベースにプラガブル・データベースを差し込んでください。

ORA-65135: このコンテキストではALTER SESSION SET CONTAINER操作は実行できません。

原因: ALTER SESSION SET CONTAINER操作を、そのような操作が禁止されているコンテキストで実行しようとしました。

処置: 移行できるセッションあるいはOCI接続プールのセッションからALTER SESSION SET CONTAINER操作を実行しないでください。

ORA-65136: SPFILE名はプラガブル・データベースには指定できません

原因: プラガブル・データベースにSPFILE名を指定しようとしました。

処置: SPFILE名を削除してから、プラガブル・データベースで操作を再試行してください。

ORA-65137: データ・ファイルstringはプラガブル・データベースのリセット・ログ操作中です。

原因: そのプラガブル・データベースはプラガブル・データベース(PDB)のRESETLOGS操作中です。

処置: 可能であれば、このプラガブル・データベースがPDB RESETLOGS操作中ではなくなるように、コンテナ・データベースをさらにリカバリしてください。もう1つの選択肢は、PDBポイント・イン・タイム・リカバリを実行することです。メッセージは、SCNとプラガブル・データベースが特定の時点にリカバリすることができるまでの時間を示すアラート・ログ記録されます。

ORA-65138: データファイルstringは、プラガブル・データベースstringの孤立したPDBインカネーションに属しています。

原因: 指定されたデータファイルは、RESETLOGS操作によりすでに廃棄された期間中に取得されたバックアップからリストアされたか、ファイルが属するプラガブル・データベース・インカネーションを識別できなかったかのいずれかです。アラート・ログには詳細な情報が含まれています。

処置: プラガブル・データベースの現行あるいは以前のインカネーションのいずれかに属するこのファイルのバックアップをリストアしてください。リストアにRMANを使用すると、RMANによって正しいバックアップが自動的に選択されます。

ORA-65139: string (string)の値に対するXMLファイルとデータ・ファイルstringが一致しません

原因: XMLメタデータ・ファイルまたはデータ・ファイルが破損していました。

処置: 切断された時点でXMLメタデータ・ファイルおよびデータ・ファイルが一致していることを確認し、操作を再試行してください。

ORA-65140: 共通プロファイル名が無効です

原因: 共通プロファイルに有効ではない名前を使用して共通プロファイルを作成しようとしました。共通プロファイル名は、C##またはc##で始め、ASCII文字のみで構成する必要があります。

処置: 有効な共通プロファイル名を指定してください。

ORA-65141: ローカル・プロファイル名が無効です

原因: ローカル・プロファイルに有効ではない名前を使用してローカル・プロファイルを作成しようとしました。ローカル・プロファイル名はC##またはc##で始めないでください。

処置: 有効なローカル・プロファイル名を指定してください。

ORA-65142: ローカル・プロファイルは、現在のコンテナ内でのみ変更できます

原因: CONTAINER=ALL句を指定したALTER PROFILE文を使用してローカル・プロファイルを変更しようとしました。

処置: ローカル・プロファイルを変更しようとする場合は、正しいコンテナに接続していることを確認し、必要に応じてCONTAINER=CURRENTを指定してください。

ORA-65143: CDB$ROOTでは、ローカル・プロファイルの作成は許可されていません

原因: CDB$ROOTでローカル・プロファイルを作成しようとしました。

処置: 共通プロファイルを作成しようとするときは、CONTAINER=CURRENTを指定しないでください。

ORA-65144: ALTER SYSTEM DISABLE RESTRICTED SESSIONは許可されていません

原因: PDB_PLUG_IN_VIOLATIONSに未解決のエラーが存在しているのに、制限付きセッションを無効にしようとしました。

処置: 制限付きセッションを無効にする前に、すべてのエラーを解決してください。

ORA-65145: 複数のインスタンスでのプラガブル・データベースの強制オープンはサポートされていません

原因: 複数のインスタンスでプラガブル・データベースをFORCEオープンしようとしました。

処置: 一度に1つのインスタンスでプラガブル・データベースのFORCEオープンを試行してください。

ORA-65146: アカウントがルートでロックされている間は、PDBでロックを解除はできません。

原因: コンテナ・データベースのルートでロックされているプラガブル・データベース(PDB)で共通ユーザー・アカウントをロック解除しようとしました。

処置: PDBでロック解除をする前に、共通ユーザー・アカウントがルートでロックされていないことを確認してください。

ORA-65147: SPFILEスコープなしでDB_UNIQUE_NAMEが指定されました

原因: SCOPE=SPFILEなしのALTER SYSTEM文にDB_UNIQUE_NAMEを指定しようとしました。

処置: SCOPE=SPFILEのみを指定してDB_UNIQUE_NAMEを使用してください。

ORA-65148: アップグレード・モードに対してプラガブル・データベースを強制オープンすることはできません

原因: アップグレード・モードに(またはアップグレード・モードから)プラガブル・データベースをFORCEオープンしようとしました。

処置: プラガブル・データベースを閉じてから、操作を再試行してください。

ORA-65149: PDB名がCDBまたはPDBの既存のサービス名と競合します

原因: コンテナ・データベース(CDB)またはPDBに既存するサービス名と競合する名前のプラガブル・データベース(PDB)を作成しようとしました。

処置: PDBに別の名前を選択してください。

ORA-65150: インスタンスを開始できません

原因: 他のインスタンスの少なくとも1つが異なるモードで起動されているときに、インスタンスをコンテナ・データベースまたは非コンテナ・データベースとして起動しようとしました。

処置: 他のすべてのインスタンスと同じモードでインスタンスを起動してください。

ORA-65151: 無効な表領域名が指定されました

原因: プラガブル・データベースの作成時に、USER_TABLESPACES句で無効な表領域名または必須の表領域名(SYSTEMまたはSYSAUX)を使用しようとしました。

処置: 有効な表領域名を指定してください。

ORA-65152: データファイルをオンライン化できません

原因: リカバリに対して無効になっているプラガブル・データベースに属する1つ以上のデータファイルをオンラインにしようとしました。

処置: ALTER PLUGGABLE DATABASE ENABLE RECOVERY文を発行してから、操作を再試行してください。

ORA-65153: 表領域をオンライン化できません

原因: プラグXMLファイルにない表領域またはプラガブル・データベースの作成時に除外された表領域をオンラインにしようとしました。

処置: その表領域を削除し、再作成してからオンラインにしてください。

ORA-65154: プラガブル・データベースの指定されたロギング属性は、現在の属性値と同じです

原因: デフォルト・ロギング属性をプラガブル・データベースの現在の属性値と同じ値に変更しようとしました。

処置: ロギング属性を異なる値に変更してください。

ORA-65155: ソース・ファイル・ディレクトリstringが欠落しているか無効です

原因: ソース・ファイル・ディレクトリが欠落しているか無効です。

処置: SOURCE_FILE_DIRECTORY句を修正してから、文を再発行してください。

ORA-65156: プラガブル・データベース・バージョンstringは許可されていません

原因: 互換性のないバージョンのマルチテナント・コンテナ・データベースを使用して、プラガブル・データベースをプラグインしようとしました。

処置: 互換性のあるバージョンのマルチテナント・コンテナ・データベースを使用して、プラガブル・データベースをプラグインしてください。

ORA-65157: SOURCE_FILE_NAME_CONVERTとSOURCE_FILE_DIRECTORYは、同時に指定できません

原因: SOURCE_FILE_NAME_CONVERT句とSOURCE_FILE_DIRECTORY句の両方が指定されています。

処置: SOURCE_FILE_NAME_CONVERT句かSOURCE_FILE_DIRECTORY句のいずれかを使用し、文を再発行してください。

ORA-65158: 次に一致するファイルが見つかりませんでした - string

原因: SOURCE_FILE_DIRECTORY句で指定されたディレクトリで一致するファイルが見つかりませんでした。

処置: SOURCE_FILE_DIRECTORY句を修正するか、ディレクトリにファイルが存在することを確認してから、文を再発行してください。

ORA-65159: 無効なサービス名が指定されました

原因: services句で無効なサービス名を使用しようとしました。

処置: 有効なサービス名を指定します。

ORA-65160: クリーンアップ・タスクIDが無効です

原因: 無効なクリーンアップ・タスクIDをDBMS_PDB.CLEANUP_TASKファンクションに渡そうとしました。

処置: 有効なクリーンアップ・タスクIDを指定してください。

ORA-65161: データがないプラガブル・データベースを作成できません

原因: クラスタ表、索引構成表またはアドバンスト・キュー表が含まれるプラガブル・データベースをクローニングしようとしました。

処置: ソース・プラガブル・データベースからこのようなオブジェクトをすべて削除してから、クローニング操作を再試行してください。

ORA-65162: パスワードが期限切れです。

原因: ユーザーのアカウントの期限が切れたため、マルチテナント・コンテナ・データベースのルートに接続してパスワードを変更する必要があります。

処置: パスワードを変更するか、DBAに連絡してください。

ORA-65164: データベースはNOARCHIVELOGモードです

原因: プラガブル・データベース(PDB)を強制終了しようとしたとき、データベースはNOARCHIVELOGモードでした。

処置: ALTER DATABASE ARCHIVELOGコマンドを発行して、データベースをARCHIVELOGモードに設定してください。

ORA-65165: ファイル作成string用のパスが欠落しているか無効です

原因: CREATE_FILE_DEST句に指定されたパスがないか無効です。

処置: CREATE_FILE_DEST句を修正してから、文を再発行してください。

ORA-65166: PDBのバージョンがCDBと異なる場合、noncdb_to_pdb.sqlは実行できません

原因: プラガブル・データベース(PDB)のバージョンがマルチテナント・コンテナ・データベース(CDB)のバージョンと異なるのに、noncdb_to_pdb.sqlを実行しようとしました。

処置: noncdb_to_pdb.sqlの実行前に、PDBをアップグレードしてください。

ORA-65167: コンテナ・データベースがアップグレード・モードの場合、noncdb_to_pdb.sqlは実行できません

原因: マルチテナント・コンテナ・データベース(CDB)がアップグレード・モードなのに、noncdb_to_pdb.sqlを実行しようとしました。

処置: CDBを非アップグレード・モードでオープンしてください。

ORA-65168: PFILE名がありません

原因: プラガブル・データベースで、PFILE名を指定せずにPFILEが含まれる操作が発行されました。

処置: 有効なPFILE名を指定してから、プラガブル・データベースで操作を再試行してください。

ORA-65169: ファイルstringのコピー中にエラーが発生しました

原因: プラガブル・データベースの作成中、ファイルをコピーしようとしてエラーが発生しました。

処置: ファイルをコピーできなかった原因について追加エラー・メッセージを確認し、それに基づいて問題を解決してください。

ORA-65170: XMLファイルstringはすでに存在します

原因: その名前のファイルがすでに存在するため、XMLファイルを作成しようとして失敗しました。

処置: 別のXMLファイル名を使用してください。

ORA-65171: DB_BLOCK_CHECKINGパラメータの値が無効です

原因: マルチテナント・コンテナ・データベース(CDB)でDB_BLOCK_CHECKINGパラメータの値がFALSEでもOFFでもないのに、プラガブル・データベース(PDB)でDB_BLOCK_CHECKINGパラメータに値FALSEまたはOFFを指定しようとしました。CDBのDB_BLOCK_CHECKINGパラメータが有効になっている場合、PDBではDB_BLOCK_CHECKINGパラメータを無効にできません。

処置: PDBのDB_BLOCK_CHECKINGパラメータにFALSEまたはOFF以外の値を指定してください。

ORA-65172: プラガブル・データベースが未変換の非コンテナ・データベースでないかぎり、noncdb_to_pdb.sqlは実行できません

原因: 未変換の非コンテナ・データベースではないプラガブル・データベース(PDB)で'noncdb_to_pdb.sql'を実行しようとしました。

処置: このPDBに'noncdb_to_pdb.sql'は必要ありません。

ORA-65173: 有効範囲の異なる権限が'string'に付与されました

原因: 異なる有効範囲で付与されたシステム権限を取り消そうとして、失敗しました。ユーザーが、現在のコンテナで共通権限を取り消そうとしたか、マルチテナント・コンテナ・データベース(CDB)でローカル権限を取り消そうとしました。

処置: CONTAINER句の適切な値を指定してください。

ORA-65174: プラガブル・データベースのサービスstringに無効な名前または競合する名前が見つかりました

原因: 指定されたサービスのサービス名またはネットワーク名が無効か、コンテナ・データベースの既存のサービス名またはネットワーク名と競合しています。

処置: 適切なSERVICE_NAME_CONVERT句を使用し、文を再発行してください。

ORA-65175: SYSDBA権限をルートでローカルには付与できません

原因: マルチテナント・コンテナ・データベース(CDB)のルートでSYSDBA権限をローカルに付与しようとしました。

処置: ルートに接続しているとき、SYSDBA権限は共通にしか付与できません。

ORA-65176: システム表領域のブロック・サイズ(string)が構成されたブロック・サイズと一致しません

原因: プラグインされるプラガブル・データベースのシステム表領域のブロック・サイズが、コンテナ・データベースで構成されているブロック・サイズと一致しませんでした。

処置: DB_<n>K_CACHE_SIZEパラメータ(<n>は2、4、8、16または32)を使用して、システム表領域のブロック・サイズに対して適切なキャッシュを構成してください。

ORA-65177: ローカル・ユーザーと同じ名前の共通ユーザーは作成できません

原因: 既存のローカル・ユーザーと同じ名前の共通ユーザーを作成しようとしました。

処置: 異なるユーザー名を指定してください。

ORA-65178: プラガブル・データベースに無効なロギング・モードが指定されました

原因: 競合するロギング・モードを有効にしようとしたか、有効になっていないロギング・モードを無効にしようとしました。

処置: プラガブル・データベースのDBA_PDBSで現在のロギング・モードを確認し、有効なモードを指定してください。

ORA-65179: 切断されていないプラガブル・データベースのデータファイルを保持できません

原因: INCLUDING DATAFILES句を指定しないでプラガブル・データベースを削除しようとしましたが、プラガブル・データベースは切断されていません。

処置: プラガブル・データベースを切断してから削除するか、DROP PLUGGABLE DATABASE文でINCLUDING DATAFILES句を使用してください。

ORA-65180: 重複するファイル名が見つかりました - string

原因: メッセージに示されたソース・ファイル名に対して重複するソース・ファイル名またはターゲット・ファイル名を指定してCREATE PLUGGABLE DATABASE 文を発行しようとしました。これは、正しくないSOURCE_FILE_NAME_CONVERTまたはFILE_NAME_CONVERT句により発生した可能性があります。

処置: 適切なSOURCE_FILE_NAME_CONVERTまたはFILE_NAME_CONVERT句を使用して、ソース・ファイル名またはターゲット・ファイル名が重複しないようにしてから、文を再発行してください。

ORA-65181: 無効な引数がCONTAINERS関数に指定されました

原因: マルチタレント・コンテナ・データベース(CDB)ビューを無効な表名またはビュー名で作成しようとしました。

処置: <owner>.<table_name | view_name>形式の有効な表名またはビュー名を指定してください。

ORA-65182: プラガブル・データベースstringの状態を変更できません

原因: 現在、状態遷移中のプラガブル・データベースの状態を変更しようとしました。

処置: しばらく待ってから操作を再試行してください。

ORA-65183: PDBがオープンしているインスタンスの数個のみで、PDBを強制オープンすることはできません

原因: プラガブル・データベースが現在オープンしているOracle RACインスタンスの数個のみで、プラガブル・データーベースをFORCEオープンしようとしました。

処置: FORCEオープンを再試行し、PDBがオープンしているOracleインスタンスをすべて含めます。

ORA-65184: 異なるPDBに属するデータファイルが見つかりました

原因: データファイル、または別のPDBに属するデータファイルが含まれるディレクトリ名を指定して、DBMS_PDB.RECOVER()を起動しようとしました。

処置: DBMS_PDB.RECOVER()に指定されたパスを確認してから、操作を再試行してください。

ORA-65185: SYSTEM表領域に属するデータファイルが見つかりませんでした

原因: データファイルまたはデータファイルが含まれるディレクトリ名を指定して、DBMS_PDB.RECOVER()を起動しようとしましたが、SYSTEM表領域に属するデータファイルが見つかりませんでした。SYSTEM表領域はPDBのリカバリに不可欠です。

処置: dbms_pdb.recover()に指定されたパスをチェックして、少なくともSYSTEM表領域に属するデータファイルが含まれていることを確認してください。

ORA-65400: 表には、CLUSTERING句が関連付けられていません

原因: ユーザーが、CLUSTERING句がない表でそれを変更しようとしました。

処置: 最初に、表にCLUSTERING句を作成してください。

ORA-65402: CLUSTERING句に無効なオプションがあります

原因: CLUSTERING句に無効なオプションがあります。[YES | NO ] ON LOADまたは[YES | NO ] ON DATA MOVEMENTのみが有効です。

処置: CLUSTERING句のオプションを修正してください。

ORA-65403: CLUSTERING句の使用方法が無効です

原因: CLUSTERING句の使用方法が無効です。この句は、CREATE/ATLER TABLE/SNAPSHOT/MATERIALIZED VIEWに対してのみ指定できます。

処置: この文ではCLUSTERING句を使用しないでください。

ORA-65404: CLUSTERING句が表に複数指定されています

原因: 1つの表に設定できるCLUSTERING句は1つのみです。その句が複数回指定されました。

処置: CLUSTERING句を1回のみ使用するように文を修正してください。

ORA-65405: CLUSTERING句は既存の表オプションとともに使用できません

原因: CLUSTERING句が、表の他の句と競合しています。IOT、CLUSTERED、GLOBAL TEMPORARY TABLE、EXTERNAL TABLEではクラスタリングを使用できません。

処置: CLUSTERING句が他の句と競合しないように文を修正してください。

ORA-65406: CLUSTERING句に無効なオプションがあります

原因: CLUSTERINGの後にBY [LINEAR | MULTIDIMENSIONAL] ORDERが続いていませんでした。

処置: CLUSTERING句のオプションを修正してください。

ORA-65407: CLUSTERING句はすでに表に存在します

原因: CLUSTERING句の追加が、既存のCLUSTERING句が指定されている表に対して指定されました。

処置: 表にCLUSTERINGが設定されている場合は、ON LOADまたはON DATA MOVEMENTオプションのみ変更できます。他のオプションを変更するには、最初にその句を削除します。

ORA-65408: CLUSTERING句のBY ORDERに指定されている列が多すぎます

原因: BY ORDER副次句に10個を超える列が指定されました。BY ORDER副次句に指定できる列は最大10個です。

処置: BY ORDER副次句に指定する列の数を、10以下の値に減らしてください。

ORA-65409: CLUSTERING句のMULTIDIMENSIONAL列またはグループが多すぎます

原因: MULTIDIMENSIONAL ORDER副次句に、40個を超える列が指定されました。MULTIDIMENSIONAL ORDER副次句に指定できる列は最大40個です。

処置: BY MULTIDIMENSIONAL ORDER副次句に指定する数を、40列以下または4グループ以下の値に減らしてください。

ORA-65410: CLUSTERING句に指定できるのはスカラー列のみです

原因: 非スカラー列が、BY LINEARまたはMULTIDIMENSIONAL ORDER副次句に指定されました。また、仮想または非表示列は許可されません。

処置: BY [LINEAR | MULTIDIMENSIONAL] ORDER副次句には、スカラー列のみ指定してください。

ORA-65411: CLUSTERING句が存在しません

原因: CLUSTERING句が関連付けられていない表でCLUSTERING句を変更または削除しようとしました。

処置: 存在しないCLUSTERING句を変更しようとしないでください。

ORA-65412: ALTER TABLE ..のオプションが無効です。CLUSTERING

原因: ALTER TABLE...CLUSTERINGに無効なオプションを指定しました。たとえば、1つの文にDROPおよびADD CLUSTERINGを指定しました。

処置: 文を修正してください。

ORA-65413: CLUSTERING句の参照オブジェクトを解決できません

原因: 実表参照に解決できないオブジェクトがCLUSTERING句で参照されました。

処置: CLUSTERING句は、実表のみ参照できます。

ORA-65414: CLUSTERING句で列が複数の表に解決されます

原因: CLUSTERING句で列が複数の表に解決されます。

処置: 文を修正してください。列は、1つの表にのみ解決される必要があります。表名で修飾する必要があります。

ORA-65415: CLUSTERING句の結合条件が正しくありません

原因: CLUSTERING句にOR条件が指定されており、実表の列の個々の結合条件が等価結合ではありませんでした。

処置: 文を修正してください。結合条件が等価結合であり、OR条件がないこと、または結合に式がないことを確認してください。

ORA-65416: CLUSTERING句に複数のディメンション表があります

原因: CLUSTERING内の結合が、ディメンション表を複数回参照していました。

処置: 文を修正してください。いずれかの参照を削除してください。

ORA-65417: CLUSTERING句のディメンション表が正しくありません

原因: CLUSTERING句内のディメンション表が無効でした。ディメンション表は、GLOBAL TEMPORARY TABLEとEXTERNAL TABLEのいずれにもすることができません。

処置: ディメンション表で無効なオプションを使用しないように文をリライトしてください。

ORA-65418: CLUSTERINGの結合に主キーまたは一意キー制約がありません

原因: CLUSTERING句のファクト表とディメンション表の間の結合に、ディメンション表に対する主キーまたは一意キー制約がありませんでした。

処置: ディメンション表の結合列に主キーまたは一意キー制約を追加してください。

ORA-65419: クラスタリング・グループの列が異なる表から取得されています

原因: クラスタリング・グループの列が異なる表から取得されていました。たとえば、... CLUSTERING BY ... ( (t1.c1, t2.c2), (t2.c1, t2.c2) )です。クラスタリング・グループ(t1.c1, t2.c2)には、1つの表のみへの参照を含める必要があります。

処置: 1つの表への参照のみが含まれるようにクラスタリング・グルーブを再作成してください。

ORA-65420: CLUSTERING句の結合条件の列に互換性がありません

原因: CLUSTERING句の結合条件の列のデータ型に互換性がありませんでした。それらは同じタイプにする必要があります。

処置: CLUSTERING句の結合条件に対して互換性のあるデータ型を選択してください。

ORA-65421: 変更される列にCLUSTERING句が定義されています

原因: CLUSTERING句が存在する列にALTER TABLE MODIFY COLUMNコマンドが発行されました。

処置: 列を変更する前に、CLUSTERING句を削除してください。

ORA-65422: CLUSTERING句には、すでにゾーンマップが定義されています

原因: WITH MATERIALIZED ZONEMAPオプションを指定してALTER TABLE MODIFY CLUSTERINGコマンドが発行されましたが、表にはすでにゾーンマップが定義されていました。

処置: 実表に関連付けられているゾーンマップを削除してから、CLUSTERING句を使用してゾーンマップの追加を試行してください。

ORA-65423: CLUSTERING句にゾーンマップが関連付けられていません

原因: WITHOUT MATERIALIZED ZONEMAPオプションを指定してALTER TABLE MODIFY CLUSTERINGコマンドが発行されましたが、表には、CLUSTERING句と関連付けられたゾーンマップがありませんでした。

処置: ALTER TABLE MODIFY CLUSTERING WITHOUT ZONEMAPを使用しないでください。

ORA-65424: CLUSTERING句に指定されている結合が多すぎます

原因: CLUSTERING句に4個を超える結合が指定されていました。ディメンション表には最大4個まで結合を指定できます。

処置: 結合の数を4個以下に減らしてください。

ORA-65425: このストレージ・タイプの表領域に格納された表では、CLUSTERING句はサポートされていません

原因: Oracle以外のExadataストレージに格納された表にクラスタリングを定義しようとしました。

処置: Oracle Exadataストレージに存在する表領域でこの表を作成するか、CLUSTERING句を削除してください。

ORA-65426: クラスタリング列に非スカラーのデータ型が使用されています

原因: クラスタリング列に非スカラー・データ値を移入しようとしたため、またはデフォルトが非スカラー値に設定されたクラスタリング列が省略されたため、データ・クラスタリングを実行できません。

処置: クラスタリング列にスカラー・データ型のみを使用するか、NO_CLUSTERINGヒントを使用してデータ・クラスタリングを無効にしてください。

ORA-65451: 拡張索引圧縮は、このストレージ・タイプの表領域ではサポートされていません。

原因: サポートされていないストレージ・タイプで拡張索引圧縮を使用しようとしました。

処置: 現行のストレージ・タイプでサポートされている圧縮オプションを使用して、検索の削除と再作成をしてください。

ORA-65455: ファミリstringは無効です

原因: パラメータ値の指定に無効なファミリが使用されました。

処置: 有効なファミリを使用してください。

ORA-65456: ファミリstringは、stringインスタンスでは有効ではありません

原因: 指定されたファミリは現在のインスタンス・タイプでは使用できませんでした。

処置: 環境変数ORACLE_FAMILYからそのファミリを削除してください。

ORA-65457: ファミリstringは、stringインスタンスでは有効ではありません

原因: 指定されたファミリは現在のインスタンス・タイプでは使用できませんでした。

処置: 初期化パラメータを設定するためにこのインスタンスに対して有効なファミリを使用してください。

ORA-65458: パラメータ修飾子が最大長を超えました

原因: 初期化パラメータ・ファイルのパラメータ修飾子で指定した文字が多すぎます。

処置: パラメータ修飾子を有効なSIDまたはファミリに変更してください。

ORA-65459: 特定のシステム識別子(SID)とともに使用されるファミリ

原因: SIDがFAMILYで使用されました。

処置: FAMILYをSIDなしで使用してください。

ORA-65460: ファミリstringは無効です

原因: 無効なファミリがORACLE_FAMILYでこのインスタンスに指定されました。

処置: ORACLE_FAMILYで有効なファミリを使用してください。

ORA-65461: CONTAINER句をALLに設定した無効なパラメータ名が指定されています

原因: CONTAINER句は、PDB以外の修正可能なパラメータに対してALTER SYSTEM SET文でALLに設定されました。

処置: CONTAINER句なしでALTER SYSTEM SET文を再試行してください。

ORA-65466: ファミリ'string' は、無効な文字が含まれているか、長すぎます

原因: 指定したファミリに、SPFILE設定では使用できない無効な文字が含まれているか、指定したファミリが長すぎます。無効な文字には、*,#"'=()と空白が含まれます。

処置: 特殊文字または空白が含まれないファミリを使用してください。ファミリの最大長は、プラットフォーム固有のドキュメントを参照してください。

ORA-65500: DB_UNIQUE_NAMEを変更できませんでした。リソースが存在します

原因: DB_UNIQUE_NAMEによって識別されるデータベース・リソースがクラスタ内に存在したため、DB_UNIQUE_NAMEを変更できませんでした。DB_UNIQUE_NAMEを変更するには、先に、それによって識別されるリソースをすべて削除する必要があります。

処置: DB_UNIQUE_NAMEによって識別されるデータベース・リソースを削除してから、DB_UNIQUE_NAMEを変更してください。

ORA-65501: この操作では、stringコンテナからのロケータはコンテナstringで使用できません

原因: プラガブル・データベース環境で、別コンテナに属するロケータを使用してLOBを変更しようとしました。

処置: 元のコンテナに切り替えてください。

ORA-65502: 一時LOBデータにアクセスできません

原因: データベースはオープンされていませんでした。

処置: LOBデータにアクセスする前に、データベースをオープンしてください。

ORA-65535: Oracleクライアントでは65535を超えるエラー・コードを処理できません。実際のエラー・コードおよびメッセージは次のとおりです

原因: Oracleサーバーでエラー・コードが65535を超えるエラーが発生しました。古いOracleクライアント(バージョン12より前)は、65535より大きいエラー・コードを処理できません。

処置: 実際のOracleエラー・コードおよびエラー・メッセージは、ORA-65535のエラー・メッセージの一部です。Oracleクライアントを、バージョン12クライアント・ライブラリ以降にアップグレードしてください。

用語集

アラート

Cloud Controlで特定のメトリック条件が発生したことを示すインジケータ。たとえば、アラートはメトリックしきい値に達したことを示します。

属性セット

リカバリ・アプライアンス・バックアップをテープにコピーする際にジョブ・レベルで設定されるパラメータのセット。属性セットは、このライブラリに関連付けられている各ドライブのメディア・マネージャ・ライブラリの一部として作成されます。

自動サービス・リクエスト(ASR)

特定のリカバリ・アプライアンスのハードウェアに障害が発生すると自動的にサービス・リクエストを開く製品機能。ASRは、ディスク、ファン、電源装など、最も一般的なサーバー・コンポーネントで障害を検出します。

自動デルタ・プール領域管理

リカバリ・アプライアンスが不要になったブロックを特定して削除する一連の操作。具体的な領域管理を次に示します。

- ディスク・リカバリ・ウィンドウ目標およびSBT保存ポリシーに基づいて、廃止されたまたは期限切れになったバックアップを特定します(リカバリ・アプライアンスの記憶域の場所およびテープの両方)

- リカバリ・アプライアンスの記憶域から不要なブロックを削除することで、保護されたデータベースそれぞれに構成されたディスク・リカバリ・ウィンドウ目標および予約済領域パラメータに対処します。

- デルタ・プールを最適化して、リストア操作のパフォーマンスを改善します

バックアップ・コピー・ポリシー

リカバリ・アプライアンスで削除する前に新しいバックアップをレプリケートまたはテープにコピーすべきかどうかを決定する保護ポリシーの属性。

バックアップ収集

保護されたデータベースによって送信されたバックアップをリカバリ・アプライアンスでスキャンする自動化されたステージ。リカバリ・アプライアンスはバックアップを小さいブロック・セットに分解し、ブロックを適切な記憶域の場所に書き込んで、バックアップの索引を作成します。索引作成には、リカバリ・アプライアンスのメタデータ・データベースに行を挿入して各ブロックの物理的な場所を記述する作業が含まれます。

バックアップ・モード

オンライン・バックアップをとる前にALTER TABLESPACE ... BEGIN BACKUPまたはALTER DATABASE BEGIN BACKUP文を発行すると開始されるデータベース・モード(ホット・バックアップ・モードとも呼ばれます)。ALTER TABLESPACE ... END BACKUPまたはALTER DATABASE END BACKUP文を発行すると、表領域でバックアップ・モードが終了します。

バックアップ・ポーリング・ディレクトリ

保護されたデータベースからのバックアップ・ピースおよびアーカイブREDOログ・ファイルの宛先である、リカバリ・アプライアンスの外部にある共有記憶域のファイルシステム・ディレクトリ。リカバリ・アプライアンスは指定された間隔でディレクトリをポーリングし、見つかったバックアップ・データを抽出した後、データを処理して格納します。

バックアップ・ポーリング・ポリシー

クライアント・データベースがリカバリ・アプライアンスと直接対話せずに、バックアップを配置する記憶域を定義するオプションのリカバリ・アプライアンス・オブジェクト。ポーリング・ポリシーでは、記憶域へのファイルシステム・パスおよび新しいバックアップを検索する頻度を定義します。

バックアップ受信

リカバリ・アプライアンスがバックアップの索引を作成する前に、保護されたデータベースがネットワーク経由でリカバリ・アプライアンスにバックアップを送信するステージ。

バックアップ・ウィンドウ

バックアップが完了するのにかかる時間。

ブロック・チェンジ・トラッキング

各データベース更新によって影響を受けたデータファイル・ブロックを、Oracle Databaseが追跡するためのデータベース・オプション。追跡情報は、ブロック・チェンジ・トラッキング・ファイルに格納されます。ブロック変更トラッキングを有効にすると、RMANでは変更トラッキング・ファイルから変更されたブロックの記録を使用して、データファイル全体を読み取るのではなく、変更されたブロックのみを読み取ることで、増分バックアップのパフォーマンスを向上させます。

カスケード型レプリケーション

さらに下流のリカバリ・アプライアンスに対して、ダウンストリーム・リカバリ・アプライアンスがアップストリーム・リカバリ・アプライアンスとしても機能する構成。

Cloud Control

Oracle Enterprise Manager Cloud Controlは、Oracleのエンタープライズ・クラウド管理ソリューションです。単一コンソールで完全なOracle ITインフラストラクチャをモニターおよび管理できます。このアーキテクチャのコア・コンポーネントには、Oracle Management Agent、Oracle Management Service、Oracle Management Repository、Enterprise Manager for Zero Data Loss Recovery Applianceプラグイン、Enterprise Manager Cloud Controlコンソールが含まれます。

copy-on-writeスナップショット

サードパーティの記憶域スナップショットが作成された後で、記憶域ブロックに対する最初の変更が発生すると、アレイはディスク上の新しい場所に変更前イメージ・ブロックをコピーします。スナップショットは、スナップショットの変更前イメージ・ブロックとアクティブ・バージョンのデータベースの新しいブロックを保持します。

デルタ・プール

仮想完全バックアップの作成元である一連のデータ・ファイル・ブロック。リカバリ・アプライアンスにバックアップされる個々のデータ・ファイルが、独自のデルタ・プールを持ちます。デルタ・プールはデルタ・ストアにあります。

デルタ・プールの最適化

デルタ・プールの自動トラッキングおよび再編成。古いブロックが削除され、更新されたデータ・ファイルに関する新しい増分バックアップが届くと、バックアップ内のブロックの連続性が低下することがあります。この状態によって、リストア操作のパフォーマンスが低下する可能性があります。リカバリ・アプライアンスは自動的にブロックを再編成して、通常の保守および検証中に連続性を維持します。

デルタ・プッシュ

保護されたデータベースからリカバリ・アプライアンスへのバックアップおよび変更の転送。このソリューションは、保護されたデータベースそれぞれで実行される2つの操作、すなわちリアルタイムREDOトランスポートと永久的増分バックアップ計画で構成されます。

デルタ・ストア

クライアント・バックアップ・データの格納に使用されるリカバリ・アプライアンス記憶域合計。デルタ・ストアには、すべてのデータ・ファイルとアーカイブREDOログのバックアップが含まれます。

ディスク・リカバリ・ウィンドウ目標

ディスク・バックアップのみを使用してポイント・イン・タイム・リカバリできる必要のある間隔。たとえば、リカバリ・ウィンドウ目標が15日間で、現在の日時が4月25日正午の場合、4月10日正午以降の任意の時点にポイント・イン・タイム・リカバリを実行することが目標です。各保護ポリシーに指定された目標は、厳格な制限ではありません。

ダウンストリーム・リカバリ・アプライアンス

リカバリ・アプライアンス・レプリケーション・トポロジでは、ダウンストリーム・リカバリ・アプライアンスはアップストリーム・リカバリ・アプライアンスからレプリケート済データを受け取ります。

データベースの登録

特定のリカバリ・アプライアンスが保護されたデータベースからバックアップを受け取ることができるようにするプロセス。登録では、保護されたデータベース(DBMS_RA.ADD_DB)の追加、このデータベースへのアクセス権のリカバリ・アプライアンス・ユーザー・アカウント(DBMS_RA.GRANT_DB_ACCESS)への付与、仮想プライベート・カタログでのこのデータベースの登録(RMAN REGISTER DATABASEコマンド)を行います。

高速リカバリ領域

制御ファイルのコピー、オンラインREDOログのコピー、アーカイブREDOログ・ファイル、フラッシュバック・ログ、RMANバックアップなどのリカバリ関連ファイルの格納のために使用可能なオプションのディスクの場所。

保証付きコピー

すべてのバックアップをテープにコピーするか、レプリケートする必要があることを示す保護ポリシーのオプション設定。リカバリ・アプライアンスは、操作が完了するまで、記憶域の場所からバックアップをパージできません。テープまたはレプリケーションが維持されない場合、リカバリ・アプライアンスは新しいバックアップを拒否することがあります。

永久的増分バックアップ計画

最初のレベル0バックアップがリカバリ・アプライアンスに送信され、後続のすべての増分バックアップがレベル1で行われる計画。リカバリ・アプライアンスは、最初のレベル0バックアップと後続のレベル1バックアップを組み合せて仮想完全バックアップを作成します。

メディア・マネージャ・ライブラリ

これは、テープ・バックアップ・ジョブを管理するメディア管理ライブラリです。このライブラリは、含まれるドライブごとの属性セットで構成され、テープ・バックアップ・ジョブに適用する記憶域パラメータを定義します。

メディア管理ソフトウェア

メディア管理ソフトウェアは、リカバリ・アプライアンスとテープ間のミドルウェアです。リカバリ・アプライアンスからテープへのバックアップのコピーを制御および管理します。

リカバリ・アプライアンスではOracle Secure Backupがメディア管理ソフトウェアとして使用され、事前構成されて付属しています。

一方向リカバリ・アプライアンス・レプリケーション

1つのアップストリーム・リカバリ・アプライアンスがバックアップを1つの ダウンストリーム・リカバリ・アプライアンスに送信する、リカバリ・アプライアンス・レプリケーションの最も簡易な形式です。

Oracle Configuration Manager

Oracleホームから構成情報を収集して環境にアップロードするツール。サービス・リクエストを記録している場合、構成データによってOracle Support Serviceはよりよいサービスを提供できます。

Oracle Enterprise Manager Cloud Control

「Cloud Control」を参照してください。

保護されたデータベース

データをリカバリ・アプライアンスにバックアップするクライアント・データベース。

保護ポリシー

リカバリ・アプライアンスがバックアップ・データを格納および管理する方法を制御する属性のグループ。保護されたデータベースはそれぞれ、そのクライアントのバックアップ処理のすべての側面を制御する1つの保護ポリシーに割り当てられます。

リアルタイムREDOトランスポート

REDOの変更の保護されたデータベースのSGAからリカバリ・アプライアンスへの継続的な転送。リアルタイムREDOトランスポートにより、RMANはほぼ0のリカバリ・ポイントの目標(RPO)を実現できます。一般に、障害発生時にRMANは1秒以内にリカバリできます。保護されたデータベースは、生成されるとメモリーからリカバリ・アプライアンスに直接REDOエントリを書き込みます。

リコンサイル

リカバリ・アプライアンス・レプリケーションで、リカバリ・アプライアンスがすぐ下流のリカバリ・アプライアンスからメタデータを受け取るプロセス。

リカバリ・アプライアンス

Zero Data Loss Recovery Applianceの短縮名。リカバリ・アプライアンスは、Oracle Databaseを保護するため専用に設計されたOracle Engineered Systemです。RMANに統合されており、クラウド規模の耐障害性の高いハードウェアと記憶域を使用して、企業全体にわたる何百から何千ものデータベースを対象とした、一元的な永久的増分バックアップ計画が可能です。

リカバリ・アプライアンス・ユーザー・アカウント

リカバリ・アプライアンスへの接続およびリカバリ・アプライアンスからのサービスのリクエストが許可されたユーザー・アカウント。リカバリ・アプライアンス・ユーザー・アカウントはすべて、リカバリ・アプライアンス・メタデータ・データベース上のOracle Databaseユーザー・アカウントであり、仮想プライベート・カタログの所有者です。保護されたデータベースをバックアップする際、RMANはリカバリ・アプライアンス・ユーザー・アカウント資格証明を使用してリカバリ・カタログに接続します。

リカバリ・アプライアンス管理者

リカバリ・アプライアンスを管理する管理者。一般的な責務として、データベースの作成および保護ポリシーへの追加、記憶域の管理、ユーザー・アカウントの管理、テープ・バックアップおよびリカバリ・アプライアンス・レプリケーションの構成、リカバリ・アプライアンスのモニタリングなどがあります。

リカバリ・アプライアンス・バックアップ・モジュール

RMANがネットワーク経由で保護されたデータベースのバックアップをリカバリ・アプライアンスに送信する際に使用する、Oracle提供のSBTライブラリ。このライブラリを、保護されたデータベースが使用する各Oracleホームにインストールする必要があります。

このモジュールは、リカバリ・アプライアンスにバックアップするためのチャネルを割当てまたは構成する際に、RMANが参照するSBTメディア管理ライブラリとして機能します。RMANはこのモジュールを使用して、リカバリ・アプライアンスへのすべてのバックアップおよび完全なバックアップ・セットのすべてのリストアを実行します。

リカバリ・アプライアンス・メタデータ・データベース

リカバリ・アプライアンス内部で実行されるOracle Database。このデータベースには、ユーザー定義、保護ポリシー定義、クライアント・データベース定義などの構成データが格納されます。メタデータ・データベースには、デルタ・ストアのコンテンツなどのバックアップ・メタデータも格納されます。

リカバリ・アプライアンス・レプリケーション

あるリカバリ・アプライアンスがバックアップを受け取った後にそれを別のリカバリ・アプライアンスに転送する構成。転送先はアップストリーム・リカバリ・アプライアンスで、受信側はダウンストリーム・リカバリ・アプライアンスです。

リカバリ・アプライアンス・スキーマ

RASYSユーザーが所有するリカバリ・アプライアンス・メタデータ・データベースのスキーマ。このスキーマはリカバリ・カタログ・スキーマのスーパーセットで、リカバリ・アプライアンスでバックアップを管理するために内部的に使用されるその他のメタデータが含まれます。

リカバリ・アプライアンスの記憶域の場所

バックアップを格納するリカバリ・アプライアンス内の一連のOracle ASMディスク・グループ。記憶域の場所は、複数の保護されたデータベースで共有できます。各リカバリ・アプライアンスには、DELTAという名前のデフォルトのリカバリ・アプライアンスの記憶域の場所があります。

リカバリ・ポイント目標(RPO)

ビジネス・プロセスまたは組織の許容データ損失量に相当します。RPOは、通常、時間を基準として測定されます(5時間または2日分のデータ損失など)。

リカバリ・ウィンドウ

リカバリ・アプライアンスがリカバリ目的でカタログ内にテープ・バックアップを保持する期間の長さを定義する設定。

リカバリ・ウィンドウ目標

ビジネス要件を満たすために、この期間内に保護されたデータベースをリカバリできる必要があります。保護ポリシー内の保護されたデータベースごとに、リカバリ・アプライアンスでは、現在の時間から遡って指定された間隔内(過去7日間など)の任意の時点までのポイント・イン・タイム・リカバリを、ディスクで最古のバックアップによってサポートできるようにしようとします。

REDOステージング領域

リアルタイムREDOトランスポート・リカバリに対応するリカバリ・アプライアンス・インストールの場合、保護されたデータベースによって送信されたREDOストリームのリカバリ・アプライアンスの記憶域宛先です。リカバリ・アプライアンスはREDOストリームをアーカイブREDOログ・ファイルに変換してから、バックアップ・ピースに変換して記憶域の場所に書き込みます。

レプリケーション・ユーザー・アカウント

ダウンストリーム・リカバリ・アプライアンスのデータベース・ユーザー・アカウントで、アップストリーム・リカバリ・アプライアンスではこのダウンストリーム・リカバリ・アプライアンスによる認証に使用します。

予約済領域

あるデータベースがディスク・リカバリ・ウィンドウ目標を達成するために予約されている、リカバリ・アプライアンスのディスク領域の最小量。他の保護されたデータベースは予約済領域を使用できません。一般に、リカバリ・アプライアンスは領域不足になるまで予約済領域の設定を無視します。領域不足になると、これらの設定およびリカバリ・ウィンドウ目標を使用してパージするバックアップを決定します。

保存ポリシー

バックアップがSBTデバイスに保持される現在から遡った期間として表される時間。バックアップは指定されたウィンドウよりも長く保持されることがあります。保存ポリシー・ウィンドウ内の任意の時点までポイント・イン・タイム・リカバリが可能であることを保証するのに十分な期間保持するためです。

RMANリカバリ・カタログ

リカバリ・アプライアンス・メタデータ・データベースに配置されているメタデータ・ビューのセット。

SBT

テープへのシステム・バックアップ。この用語はバックアップ・デバイス・タイプを表します。通常はテープ・デバイスまたはリカバリ・アプライアンスです。RMANでは、ディスクおよびSBTのタイプのチャネルがサポートされています。

テープ・バックアップ・ジョブ

関連付けられているメディア・マネージャ・ライブラリ、属性セット、バックアップ・タイプ、ランタイム・ウィンドウなどの定義済プロパティに基づいて、リカバリ・アプライアンス・バックアップをテープにコピーする操作。このジョブは繰り返し可能で、作成後ただちに実行するように、または後から指定した時間に実行するようにスケジュールできます。

サードパーティの記憶域スナップショット

サードパーティの記憶域デバイスによって管理される、スナップショットの作成時に存在していた記憶域ブロック(Oracleブロックではない)に対するポインタのセットです。デバイスは、元のデータと同じストレージ・アレイにスナップショットを保持します。スナップショットが変更されたことを認識すると、デバイスは新しいバージョンの記憶域ブロックのみを作成します。

保護されていないウィンドウのしきい値

保護ポリシーの管理下にある保護されたデータベースのユーザー定義の最大データ損失量。たとえば、保護ポリシーSILVERに指定された5分というしきい値は、SILVERで保護されているデータベースは5分以上データを損失できないことを示します。

アップストリーム・リカバリ・アプライアンス

リカバリ・アプライアンス・レプリケーション・トポロジで、バックアップを他のリカバリ・アプライアンスにレプリケートするリカバリ・アプライアンス。

仮想完全バックアップ

1つのポイント・イン・タイムでの完全なデータベース・イメージ。保護されたデータベースの増分バックアップのインデックス化を通じて、効率よく管理されます。仮想完全バックアップには、複数の増分バックアップからの個別のブロックが含まれます。たとえば、月曜にSCN 10000でレベル0バックアップをとり、火曜にSCN 11000で増分レベル1バックアップをとった場合、リカバリ・アプライアンス・メタデータ・データベースには現在からSCN 11000までの仮想レベル0バックアップが示されます。

本質的に、仮想完全バックアップは、領域を効率的に使用する、増分バックアップ時点の物理完全バックアップのポインタ・ベース表現です。リストア操作が必要になったら、デルタ・ストアは適切な増分バックアップSCNから物理完全バックアップを再作成します。

仮想プライベート・カタログ

データベース・ユーザー・アカウントがアクセス権限を付与されている、RMANリカバリ・カタログ内のメタデータのサブセット。制限付きユーザー・アカウントは、それぞれ独自の仮想プライベート・カタログへの完全な読取り/書込み権限を持っています。

Zero Data Loss Recovery Appliance

「リカバリ・アプライアンス」を参照してください。

Zero Data Loss Recovery Applianceバックアップ・モジュール

「リカバリ・アプライアンス・バックアップ・モジュール」を参照してください。

索引

A  B  C  D  E  F  I  L  M  O  P  R  S  T  U  V  Z

A

- リカバリ・アプライアンス・レポートへのアクセス

- 基本タスク 1

- リカバリ・アプライアンス・ホームページへのアクセス 1

- リカバリ・アプライアンスの記憶域の場所ページへのアクセス 1

- アーカイブ・バックアップ 1 , 3

- 非同期REDOトランスポート・サービス 1

- 属性セット, SBT

- 作成 1 , 2

- デフォルト値 1

- 削除 1

- 編集 1

- 自動デルタ・プール領域管理 1 , 2

- 自動サービス・リクエスト(ASR) 1

B

- バックアップおよびREDOフェイルオーバー

- 構成 1

- BACKUPコマンド 1

- バックアップ収集フェーズ 1

- バックアップ・モード 1

- バックアップ・プーリング

- ディレクトリ 1 , 2

- バックアップの処理方法 1

- 場所 1 , 2

- ポリシー 1 , 2 , 3 , 4 , 5

- ステージ 1

- バックアップ, RMAN

- アーカイブ 1

- テープへのコピー 1

- レプリケート 1

- 仮想完全 1

- バックアップ計画

- サードパーティの重複除外アプライアンスへの完全バックアップ 1

- 増分バックアップとRECOVER COPY 1

- 永久的増分 1

- サード・パーティのスナップショット 1

- 週次完全と日次増分 1

- バックアップ・ウィンドウ, 削減 1

- BI Publisherレポート

- 容量計画詳細 1

- 容量計画サマリー 1

- 保護されたデータベースの詳細 1

- データ転送別上位10の保護されたデータベース 1

- ブロック・チェンジ・トラッキング 1

C

- 容量計画詳細レポート 1

- 容量計画サマリー・レポート 1

- カスケード型レプリケーション 1

- Cloud Control管理者 1

- リカバリ・アプライアンス用のCloud Control

- Oracle Secure Backupドメインへのアクセス 1

- レプリケーション・ページへのアクセス 1

- アラート 1

- BI Publisherレポート 1

- リカバリ・アプライアンスの集中管理 1

- 保護ポリシーの作成ページ 1 , 2

- すべてのリカバリ・アプライアンスの表示 1

- copy-to-tapeジョブの管理 1

- モニタリング・ツール 1

- リカバリ・アプライアンス・レポート・ページ 1

- 記憶域の場所ページ 1

- 保護されたデータベースのプロパティの更新 1

- ユーザー・アカウント 1

- CONNECT CATALOGコマンド 1 , 2 , 3

- CONNECT TARGETコマンド 1 , 2

- テープへのバックアップのコピー

- 一時停止および再開 1

- バックアップ保存 1

- 基本タスク 1

- コンポーネント 1

- 例 1

- 概要 1

- copy-on-writeスナップショット 1

- copy-to-tapeジョブ

- 削除 1

- 編集 1

- 管理 1

- ステータスの表示 1

- SBTライブラリの作成 1

- SBTメディア・プールの作成 1

D

- データベースの登録 1

- データ・ファイルとデルタ・プール 1

- DBMS_RA.ABORT 1

- DBMS_RA.ABORT_RECOVERY_APPLIANCE 1

- DBMS_RA.ADD_DB 1 , 2 , 3 , 5 , 7 , 8 , 9 , 10

- DBMS_RA.ADD_REPLICATION_SERVER 1 , 2 , 3 , 4

- DBMS_RA.CONFIG 1

- DBMS_RA.COPY_BACKUP 1 , 2 , 3 , 4

- DBMS_RA.COPY_BACKUP_PIECE 1

- DBMS_RA.CREATE_POLLING_POLICY 1 , 2 , 3 , 4

- DBMS_RA.CREATE_PROTECTION_POLICY 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10

- DBMS_RA.CREATE_REPLICATION_SERVER 1 , 2 , 3 , 5

- DBMS_RA.CREATE_SBT_ATTRIBUTE_SET 1 , 2 , 3

- DBMS_RA.CREATE_SBT_JOB 1

- DBMS_RA.CREATE_SBT_JOB_TEMPLATE 1 , 2

- DBMS_RA.CREATE_SBT_LIBRARY 1 , 2 , 3

- DBMS_RA.CREATE_STORAGE_LOCATION 1

- DBMS_RA.DELETE_DB 1

- DBMS_RA.DELETE_POLLING_POLICY 1

- DBMS_RA.DELETE_PROTECTION_POLICY 1 , 2 , 3 , 4

- DBMS_RA.DELETE_REPLICATION_SERVER 1 , 2

- DBMS_RA.DELETE_SBT_ATTRIBUTE_SET 1 , 2

- DBMS_RA.DELETE_SBT_JOB 1 , 2

- DBMS_RA.DELETE_SBT_JOB_TEMPLATE 1

- DBMS_RA.DELETE_SBT_LIBRARY 1 , 2 , 3

- DBMS_RA.DELETE_STORAGE_LOCATION 1

- DBMS_RA.GRANT_DB_ACCESS 1 , 2 , 3 , 5 , 6 , 7

- DBMS_RA.MIGRATE_TAPE_BACKUP 1

- DBMS_RA.MOVE_BACKUP 1 , 2 , 3

- DBMS_RA.MOVE_BACKUP_PIECE 1

- DBMS_RA.PAUSE_REPLICATION_SERVER 1

- DBMS_RA.PAUSE_SBT_LIBRARY 1 , 2 , 3

- DBMS_RA.POPULATE_BACKUP_PIECE 1

- DBMS_RA.QUEUE_SBT_BACKUP_TASK 1 , 2 , 3

- DBMS_RA.REMOVE_REPLICATION_SERVER 1 , 2

- DBMS_RA.RENAME_DB 1

- DBMS_RA.RESET_ERROR 1

- DBMS_RA.RESUME_REPLICATION_SERVER 1

- DBMS_RA.RESUME_SBT_LIBRARY 1 , 2 , 3

- DBMS_RA.REVOKE_DB_ACCESS 1 , 2

- DBMS_RA.SHUTDOWN 1

- DBMS_RA.SHUTDOWN_RECOVERY_APPLIANCE 1

- DBMS_RA.STARTUP 1

- DBMS_RA.STARTUP_RECOVERY_APPLIANCE 1

- DBMS_RA.UPDATE_DB 1 , 2 , 3 , 5 , 6

- DBMS_RA.UPDATE_POLLING_POLICY 1

- DBMS_RA.UPDATE_PROTECTION_POLICY 1 , 2 , 3

- DBMS_RA.UPDATE_REPLICATION_SERVER 1

- DBMS_RA.UPDATE_SBT_ATTRIBUTE_SET 1 , 2 , 3

- DBMS_RA.UPDATE_SBT_JOB 1 , 2

- DBMS_RA.UPDATE_SBT_JOB_TEMPLATE 1 , 2

- DBMS_RA.UPDATE_SBT_LIBRARY 1 , 2 , 3

- DBMS_RA.UPDATE_STORAGE_LOCATION 1

- DBMS_RAパッケージ

- Cloud Controlの代替 1

- DBMS_SCHEDULER.CREATE_JOB 1

- デルタ・プール

- 自動領域管理 1

- データ・ファイルごと 1

- 最適化 1

- デルタ・プッシュ

- リアルタイムREDOトランスポート 1

- DELTA記憶域の場所 1 , 2

- デルタ・ストア

- デルタ・プール 1

- 仮想完全バックアップ 1

- ディスク・リカバリ・ウィンドウ目標 1 , 2 , 3 , 4 , 5 , 6 , 7

E

- 暗号化バックアップ, RMAN 1

- 保護されたデータベースの登録

- Cloud Controlの使用 1

- Enterprise Manager for Zero Data Loss Recovery Applianceプラグイン。

- 「リカバリ・アプライアンス・プラグイン」を参照

- 期限切れのバックアップ 1

F

- 高速リカバリ領域 1

- ファイバ・チャネル 1

I

- 永久的増分計画

- 仕組み 1

L

- ライブラリ, SBT

- 作成 1

- 定義 1

- LIST BACKUPSETコマンド 1

M

- メディア・マネージャ・ライブラリ

- Cloud Controlを使用して作成 1

- 削除 1

- Cloud Controlの使用 1

- メディア・マネージャ 1

- メディア・プール, SBT

- 作成 1

- 定義 1

- RMANバックアップの移行 1

- mkstoreユーティリティ 1

- リカバリ・アプライアンスのモニタリング

- 自動サービス・リクエスト(ASR) 1

- インシデント・マネージャ 1

- メトリックと収集設定 1

- パフォーマンス 1

- Cloud Controlの使用 1

- Oracle Configuration Managerの使用 1

O

- 不要なバックアップ 1

- Oracle ASM 1

- Oracle Configuration Manager 1

- Oracle Enterprise Manager Cloud Control (Cloud Control)

- 「Cloud Control」を参照

- Oracle Scheduler

- SBTジョブのスケジューリング 1

- Oracle Secure Backup

- テープ・アーカイブ 1

- テープ取得 1

- Oracle Secure Backupドメイン

- アクセス 1

- Oracleウォレット

- 作成 1 , 2

- mkstoreユーティリティ 1

P

- テープ・コピー操作の一時停止と再開

- 概要 1

- 保護されたデータベースの詳細レポート 1

- 保護対象データベース

- DBMS_RAを使用したアクセス 1

- 追加 1

- 管理者 1

- レプリケーションの構成 1

- リカバリ・アプライアンスへの登録 1 , 2

- DBMS_RAを使用した保護ポリシーの再割当て 1

- リカバリ・アプライアンス・スキーマ 1

- 登録 1

- ステータス・レポート 1

- Cloud Controlを使用したプロパティの更新 1

- 保護ポリシー

- 概要 1

- バックアップ・ポーリング・ポリシーの設定 1

- 基本タスク 1

- メリット 1

- Cloud Controlページ 1

- copy-to-tape設定 1

- 作成 1

- DBMS_RAプロシージャ 1

- 定義 1

- Cloud Controlを使用した削除 1

- ディスク・リカバリ・ウィンドウ目標 1

- テープへのバックアップのコピー 1

- 管理 1

- 概要 1 , 2

- レプリケーション 1

- レプリケーション・サーバー構成 1 , 2

- 記憶域属性 1

- 更新 1

R

- RA_ACCESSビュー 1

- RA_ACTIVE_SESSIONビュー 1

- RA_API_HISTORYビュー 1

- RA_CONFIGビュー 1

- RA_DATABASE_STORAGE_USAGEビュー 1

- RA_DATABASE_SYNONYMビュー 1

- RA_DATABASEビュー 1 , 2 , 3 , 4 , 5 , 6 , 7

- RA_DB_ACCESSビュー 1 , 2

- RA_DISK_RESTORE_RANGEビュー 1

- RA_EM_SBT_JOB_TEMPLATEビュー 1

- RA_EM_SBT_JOBビュー 1

- RA_HOSTビュー 1

- RA_INCIDENT_LOGビュー 1

- RA_INCOMING_BACKUP_PIECESビュー 1

- RA_POLLING_FILES 1

- RA_POLLING_POLICYビュー 1 , 2

- RA_PROTECTION_POLICYビュー 1 , 2 , 3 , 4 , 5 , 6 , 7

- RA_PURGING_QUEUEビュー 1 , 2

- RA_REPLICATION_SERVERビュー 1 , 2 , 3 , 4

- RA_RESTORE_RANGEビュー 1

- RA_SBT_ATTRIBUTE_SETビュー 1 , 2

- RA_SBT_JOBビュー 1 , 2

- RA_SBT_LIBRARYビュー 1 , 2 , 3 , 4

- RA_SBT_RESTORE_RANGEビュー 1

- RA_SBT_TASKビュー 1 , 2

- RA_SBT_TEMPLATE_MDFビュー 1

- RA_SERVERビュー 1

- RA_STORAGE_HISTOGRAMビュー 1

- RA_STORAGE_LOCATIONビュー 1

- RA_TASKビュー 1

- RA_TIME_USAGEビュー 1

- RASYSユーザー・アカウント 1 , 2 , 3 , 5 , 6 , 8 , 9 , 10 , 11 , 12 , 13

- RC_BACKUP_PIECE_DETAILSビュー 1

- リアルタイムREDOトランスポート

- 概要 1

- RECOVER COPYコマンド 1

- リカバリ・アプライアンス

- アラート 1

- バックアップ収集フェーズ 1

- ダウンストリーム・リカバリ・アプライアンス 1

- 利用可能なリカバリ・アプライアンスのリスト 1

- Cloud Controlによる管理 1

- バックアップの移行 1

- 監視 1 , 2

- レプリケーション・ソリューション 1

- ロール 1

- テープ・ソリューション 1

- 検証 1

- 警告 1

- リカバリ・アプライアンスの管理

- 職務分離 1

- ツール 1

- リカバリ・アプライアンス管理者 1

- リカバリ・アプライアンス・バックアップ・モジュール 1 , 2 , 3 , 4

- リカバリ・アプライアンス環境 1

- リカバリ・アプライアンス・ホームページ

- アクセス 1

- リカバリ・アプライアンス・メタデータ・データベース 1 , 2 , 3 , 4 , 5

- リカバリ・アプライアンス・プラグイン 1

- リカバリ・アプライアンス・レプリケーション

- 基本タスク 1

- 双方向 1

- カスケード型レプリケーション 1

- ダウンストリーム・リカバリ・アプライアンスの構成 1

- Cloud Controlを使用した構成 1

- DBMS_RAを使用した構成 1

- 例 1

- 仕組み 1 , 2

- RMANがバックアップをリストアする方法 1

- ハブアンドスポーク 1

- 一方向 1

- 概要 1

- 保護ポリシー 1 , 2

- 用途 1

- リコンサイル 1 , 2

- テスト 1

- アップストリーム・リカバリ・アプライアンス 1

- リカバリ・アプライアンス・スキーマ 1

- リカバリ・アプライアンスのサービス階層 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9

- リカバリ・アプライアンスの記憶域

- バックアップ・ポーリングの場所 1

- Cloud Control 1

- DELTA記憶域の場所 1

- 保証付きコピー 1

- 場所 1 , 2 , 3 , 4 , 6

- max_retention_window 1

- recovery_window_goal 1

- タイプ 1

- リカバリ・アプライアンス・ユーザー・アカウント 1 , 2 , 3

- リカバリ・アプライアンスのワークフロー

- 計画 1

- 設定と構成 1

- リカバリ・カタログ

- RASYSが所有 1

- ビュー 1 , 2

- Recovery Manager(RMAN) 1

- リカバリ・ポイント目標(RPO) 1 , 2

- リカバリ・ウィンドウ, SBT 1

- REGISTER DATABASEコマンド 1

- 予約済領域 1 , 2 , 3

- RMANバックアップ

- アーカイブ 1

- 暗号化 1

- 廃止および期限切れの処理 1

- ライフサイクル 1

- 移行 1 , 2

- RMANコマンド

- BACKUP 1

- CONNECT CATALOG 1 , 2

- CONNECT TARGET 1 , 2

- LIST BACKUPSET 1

- RECOVER COPY 1

- REGISTER DATABASE 1

- SWITCH 1

- RMAN暗号化バックアップ 1

S

- SBTジョブ

- DBMS_RAを使用した作成 1

- Cloud Controlを使用したスケジューリング 1

- Oracle Schedulerを使用したスケジューリング 1

- Cloud Controlを使用したステータスの表示 1

- SBTライブラリ

- DBMS_RAを使用した作成 1

- 定義 1

- DBMS_RAを使用した管理 1

- SBTメディア・プール

- 作成 1

- 定義 1

- SBTリカバリ・ウィンドウ 1

- SBT保存期間 1

- スケジューラ

- 「Oracle Scheduler」を参照

- Oracle Schedulerを使用したSBTジョブのスケジューリング 1

- サービス階層

- 「リカバリ・アプライアンス・サービス階層」を参照

- サービス階層, リカバリ・アプライアンス 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9

- SQL*Plus 1

- SWITCHコマンド 1

- SYSMANアカウント 1

T

- テープ

- バックアップのコピーの一時停止および再開 1

- バックアップのコピー 1

- リカバリ・アプライアンスでの操作の概要 1

- バックアップのコピーを管理するためのリカバリ・アプライアンス・コンポーネント 1

- テープ・ライブラリ 1

- サードパーティの重複除外アプライアンス 1

- サード・パーティのスナップショット 1

- データ転送別上位10の保護されたデータベース・レポート 1

U

- ユーザー・アカウント

- Cloud Control 1 , 2

- RASYS 1

- リカバリ・アプライアンス 1 , 2 , 3

- ユーティリティ

- network_throughput_test.sh 1

- rastat.pl 1

V

- ビュー, リカバリ・カタログ 1 , 2

- 仮想完全バックアップ

- copy-to-tapeジョブ 1

- 動作の概要 1

- レプリケーションの使用 1

- 仮想プライベート・カタログ 1 , 2 , 3 , 4

Z

- Zero Data Loss Recovery Appliance。

- 「リカバリ・アプライアンス」を参照

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。