オラクル社以外のスクリプトによるバックアップと復元

RCUスキーマにAutonomous Transaction Processingを使用しなかった場合または複数のEssbaseインスタンスが単一のAutonomous Transaction Processingデータベースを使用してデプロイされている場合、オラクル社提供のバックアップ・スクリプトを使用できません。インスタンスごとに、<Essbase prefix>_Essbaseスキーマおよびデータ・ブロック・ボリュームを個別にバックアップする必要があります。

Essbaseインスタンスのオラクル社以外のスクリプトによるバックアップ

まだ実行していない場合は、Oracle Instant Clientおよびツールをインストールして構成します。データ・ポンプおよびSQL*Plusを実行する必要があります。

データ・ポンプおよびOracle Cloud Infrastructureコンソールを使用してEssbaseスキーマをバックアップします。

オブジェクト・ストレージと連動して機能するように、Autonomous Transaction Processingインスタンスを構成します。
データベース・クライアント・アプリケーションを使用して、Oracle Cloud Infrastructureアカウントおよびデフォルトのオブジェクト・ストレージ・バケットととも使用するためにAutonomous Transaction Processingインスタンスを構成します。SQL Developerは、クラウド・ウォレット接続を許可し、必要な場合は複数のAutonomous Transaction Processingインスタンスに同時接続できるため、データベース・クライアントに適した選択肢です。
1. SQL Developerを使用してAutonomous Transaction Processingインスタンスへの接続を作成します(企業ネットワークを介して接続されている場合はプロキシの必要性を考慮します)。
2. Oracle Cloud Infrastructureコンソールを使用して認証トークンを作成します。
  トークン値をコピーしてセキュアな場所に書き留めます。この値を再度取得することはできません。
  
  ノート:
  以前はこの手順の後、OCIコンソールから、Autonomous Databaseについて、バックアップを手動で構成していました。この手動操作は不要になりました。
Essbaseサービスを停止します。ノード・マネージャを停止する必要はありません。(Oracle Cloud InfrastructureでEssbaseコンピュートを停止しないでください。)
データ・ポンプを使用してAutonomous Transaction ProcessingインスタンスからEssbaseスキーマをバックアップします。
各Essbaseインスタンスには、関連付けられたスキーマがAutonomous Transaction Processingデータベースに9個あります。9個のスキーマすべてに共通のrcu_schema_prefixが付いており、Oracle Resource Manager (ORM)適用ジョブの出力にレポートされます。セキュリティにOracle Identity Cloud Serviceを使用している場合は、バックアップするEssbaseインスタンスに対応する、<prefix>_ESSBASEスキーマのみをバックアップする必要があります。Autonomous Transaction Processingインスタンスには複数のインスタンスからのEssbaseスキーマが存在する場合があることに留意してください。
1. TNS_ADMIN変数がエクスポート元となるAutonomous Transaction Processingインスタンスのウォレットの場所を指していることを確認します。Oracle Instant Clientを使用して、次のデータ・ポンプ・コマンドを発行します。
```
$ expdp admin_<database name>_low directory=data_pump_dir schemas=<source schema prefix>_ESSBASE logfile=<logfile name>.out dumpfile=<dump file name>.dmp
```
  ノート:
  接続情報内のAutonomous Transaction Processing接頭辞は、複数のEssbaseインスタンスを同じAutonomous Transaction Processingデータベースにデプロイした場合、バックアップしているEssbaseスキーマのスキーマ接頭辞と異なることがあります。
2. スキーマのバックアップが、Autonomous Transaction Processingデータベースのデータ・ポンプ・ディレクトリ内にあるディスクに物理的に格納されます。
PUT OBJECTプロシージャを使用して.dmpファイルをOracle Cloud Infrastructureオブジェクト・ストレージに移動します。
1. .dmpファイルを任意のオブジェクト・ストレージ・バケットに移動します(Instant Client SQL*Plusパッケージをインストールした場合を除き、SQL Developerを使用)。Put Object URIの/o/xxxxxxxxxx.dmp部分は、オブジェクト・ストレージの.dmpファイルに割り当てる名前を示します。file_nameは、データ・ポンプを使用してエクスポートをディスク上に作成した際に割り当てた.dmpファイル名と一致する必要があります。
  
  ノート:
  オブジェクト・ストレージ・バケット名は、大/小文字を区別します。
```
BEGIN DBMS_CLOUD.PUT_OBJECT(credential_name => <your credential name>, object_uri => <your object uri>, directory_name => <your data pump directory name>, file_name => <your data pump export file name>); END;/
```
2. オブジェクト・ストレージ・バケットをリフレッシュして.dmpファイルを表示します。
Essbaseデータ・ボリュームをバックアップします。必ず、EssbaseスキーマをエクスポートしたばかりのEssbaseインスタンスにアタッチされたブロック・ボリュームをバックアップします。ブロック・ボリューム・バックアップの概要およびボリュームのバックアップを参照してください。「ボリュームのバックアップ」のコンソールの使用に関する項のステップ2で、ブロック・ボリュームを選択するかわりに、メニューを使用して「手動バックアップの作成」を選択します。

ノート:
ブロック・ボリュームのバックアップはスナップショットであるため、Autonomous Transaction Processingスキーマのバックアップが完了し、ブロック・ボリュームのバックアップが開始されたらすぐにEssbaseサービスを再開できます。ブロック・ボリュームのバックアップが完了するのを待ってからEssbaseサービスを再開する必要はありません。
オブジェクト・ストレージ内のAutonomous Transaction Processingの.dmpファイルおよびブロック・ボリュームのバックアップのタイムスタンプに注目してください。Essbaseサービスが停止したため、これらのバックアップは、必要となった場合にEssbaseの一貫した復元を実行するのに使用できます。
Essbaseサービスを開始します。

オラクル社以外のスクリプトによるバックアップからのEssbaseインスタンスの復元

障害が発生した場合、オラクル社以外のスクリプトによるバックアップを復元するには、新しいターゲットEssbaseインスタンスをデプロイする必要があります。新しいターゲット・インスタンスのデプロイ後に、Essbaseスキーマおよびデータ・ブロック・ボリュームをバックアップから復元できます。新しいターゲット・インスタンスは、障害が発生したコンピュートにデプロイされたのと同じバージョンである必要があります。最近アップグレードしていない場合は、GitHubからイメージを取得する必要があります。新しいターゲット・インスタンスをデプロイしたら、そのターゲットを使用してバックアップからリカバリできます。

障害が発生していなくても、ソース・インスタンスを移行またはロールバック(同一ホスト・リカバリ)する場合は、後述の復元ステップを使用します。ただし、次の例外があります。

ステップ1および2をスキップします。
ステップ4bで、REMAP_SCHEMA=<sourceEBprefix>_ESSBASE:<targetEBprefix>_ESSBASEパラメータを含めないでください。
バックアップを取ったのと同じホームでリカバリするため、後述のステップで言及されているターゲット・インスタンスがソース・インスタンスになります。

次のステップにより、同じAutonomous Transaction Processingデータベースにデプロイされている可能性がある他のEssbaseインスタンスに影響を与えずに、単一のEssbaseインスタンスを復元できます。これらのステップは、Autonomous Transaction Processingをデータベース・スキーマに使用しなかった場合にも適しています。

ノート:

EssbaseノードにパブリックIPがない場合は、要塞をプロキシとして使用します。

Oracle Marketplaceを使用してターゲットEssbaseスタックをデプロイします。
- ソースOracle Identity Cloud Serviceの機密アプリケーションを使用します。
- ソースAutonomous Transaction Processingデータベースおよびパスワードを使用します。必要に応じて、新しいAutonomous Transaction Processingデータベースを作成します。これは、新しいリージョンで復元する場合に必要です。
- ソースの仮想クラウド・ネットワークおよびアプリケーション・サブネットを使用します。必要に応じて、新しいネットワークを作成します。これは、新しいリージョンで復元する場合に必要です。
- ソース・スタックにロード・バランサがある場合、ターゲットのロード・バランサをデプロイしないでください。バックエンド・セットは、ターゲット・スタックのデプロイ後に変更できます。必要に応じて、新しいロード・バランサを作成します。これは、新しいリージョンで復元する場合に必要です。
- ソースで使用したのと同じEssbaseシステム管理ユーザー名およびパスワードをターゲットで使用します。
- ソース・スタックで使用したのと同じOracle Identity Cloud Service Essbase管理ユーザーをターゲット・スタックで使用します。これが不可能な場合は、ソースEssbaseインスタンスに、Essbaseシステム管理者ロールを保持する有効なOracle Identity Cloud Serviceユーザーが少なくとも1つ必要です。復元後、ソース・インスタンスのEssbaseシステム管理者ロールを保持する有効なOracle Identity Cloud Serviceユーザーとして、ターゲット・インスタンスにログインする必要があります。
ターゲット・インスタンスのログインURLを管理します。
1. ソース・ロード・バランサがある場合、ターゲット・コンピュートで使用するために、'essbase'バックエンド・セットを管理します。ロード・バランサがターゲット・コンピュートへの接続をリフレッシュする時間を確保した後、Essbase Webインタフェースにログインして、バックアップからの復元に進む前にターゲット・インスタンスが正しくデプロイされていることを確認します。
  1. ソース・コンピュート・バックエンドを削除します。
  2. ターゲット・コンピュート・バックエンドを追加します。ポート443を使用します。
  同じロード・バランサIPがターゲットEssbaseインスタンスにルーティングされるようになったため、Oracle Identity Cloud Serviceの機密アプリケーションのURLを更新する必要はありません。
2. ソース・スタックにロード・バランサがない場合、ターゲットIPアドレスを使用して新しいリダイレクトURLおよびログアウト後のリダイレクトURLで、Oracle Identity Cloud Serviceの機密アプリケーションを更新します。
  Oracle Identity Cloud Serviceにログインし、ソース機密アプリケーションを編集して以前に使用されたソースIPアドレスのかわりにターゲットIPアドレスが使用されるようにします。
ターゲットEssbaseサービスを(oracleユーザーとして)停止します。Oracle Cloud Infrastructureでノード・マネージャまたはEssbaseコンピュートを停止しないでください。

ノート:
このユースケースはソース・コンピュート・サーバーまたはハードウェアの障害に関係しているため、ソース・コンピュートのEssbaseサービスが停止していることを前提としています。これらのステップをシミュレートする場合は、必ず、ソース・コンピュートのEssbaseサービスも停止します。
ターゲット・データベース・スキーマをソース・スキーマのバックアップから復元します。
ターゲット・スタックのAutonomous Transaction Processingデータベースを復元する際、REMAP_SCHEMAオプションを使用してソース・スキーマのバックアップをターゲットEssbaseスキーマにインポートします。

必ず、ソースEssbaseサービスが停止している間に作成したソース・スキーマのバックアップを選択します。また、同時期のソースEssbaseデータ・ブロック・ボリュームがあることを確認します。

ノート:
ソース・インスタンスに使用したのと同じAutonomous Transaction Processingデータベースをターゲット・インスタンスに使用した場合は、オブジェクト・ストレージとともに使用するためにすでに構成されています。新しいAutonomous Transaction Processingデータベースを作成した場合は、オブジェクト・ストレージとともに使用するために構成する必要があります。前述のEssbaseインスタンスのオラクル社以外のスクリプトによるバックアップのステップ1を参照してください。
1. ターゲットEssbaseスキーマが格納されているAutonomous Transaction Processingデータベースを指すようにInstant Clientが構成されていることを確認します。
2. Oracle Instant Clientを使用して、次のデータ・ポンプ・インポート・コマンドを発行します。
```
impdp admin@<database name>_high directory=data_pump_dir credential=<yourcredname>dumpfile=<your object storage native URI> REMAP_SCHEMA=<sourceEBprefix>_ESSBASE:<targetEBprefix>_ESSBASE table_exists_action=replace
```
  ノート:
  オブジェクト・ストレージのネイティブURIのオブジェクト(/o/)は、オブジェクト・ストレージ内にあるソース・バックアップの.dmpファイル名になります。
スキーマのインポートが終了したら、SQL Developerなどのデータベース・クライアントを使用してデータを監査します。<targetprefix>_ESSBASEスキーマ内のESSBASE_APPLICATION表を参照して、ターゲット・スキーマ(スキーマのインポート前は空)にソース・アプリケーションがあることを確認できます。
/etc/fstabのデータ・ブロック・ボリュームのエントリを一時的に無効にします。
1. ターゲット・コンピュートに(opcユーザーとして) ssh接続します。
2. sudo vi /etc/fstab
3. /u01/dataのエントリの前に#を挿入します。
4. ファイルを保存します。
データ・ブロック・ボリュームをターゲットEssbaseコンピュートからデタッチします。iSCSIの警告をメモし、OCIコンソールを使用してデタッチする前に、必ずボリュームをアンマウントして切断します。
1. アンマウントするには:
  1. ターゲット・コンピュートに(opcユーザーとして) ssh接続します。
  2. lsblk
  3. sudo umount /u01/data
2. iSCSIを切断するには:
  1. OCIコンソールで、ターゲット・コンピュートを選択します。
  2. 「リソース」→「アタッチされたブロック・ボリューム」を選択します。
  3. データ・ブロック・ボリュームの「アクション」メニューから、「iSCSIコマンドおよび情報」を選択します。
3. 切断するためのiSCSIコマンドをコピーします。
4. ターゲット・コンピュートに(opcユーザーとして) ssh接続します。
5. コピーした切断コマンドを貼り付けて[Enter]を押します。
6. デタッチするには:
  1. OCIコンソールで、ターゲット・コンピュートを選択します。
  2. 「リソース」→「アタッチされたブロック・ボリューム」を選択します。
  3. データ・ブロック・ボリュームの「アクション」メニューから、「デタッチ」を選択します。
ソース・データ・ブロック・ボリュームをバックアップから復元します。必ず、ターゲット・コンピュートと同じ可用性ドメインを選択します。
前のステップで作成したブロック・ボリュームをターゲット・コンピュートにアタッチします。ボリュームのアタッチメント・タイプは、iSCSIにする必要があります。
OCIコンソールに示されたiSCSIコマンドを使用して、新たにアタッチしたターゲット・データ・ブロック・ボリュームを接続します。
/etc/fstabの/u01/dataのエントリを更新して新しいデータ・ブロック・ボリュームをマウントします。
1. ターゲット・コンピュートに(opcユーザーとして) ssh接続します。
2. lsblkを実行して、新たにアタッチしたデータ・ボリュームの名前を確認します。
3. sudo blkidを実行して、新たにアタッチしたデータ・ボリュームのUUIDを書き留めます。
4. sudo vi /etc/fstab
5. データ・ブロック・ボリュームのエントリをコメント解除します。
6. 既存のデータ・ボリューム・エントリのUUIDを新たにアタッチしたデータ・ボリュームのUUIDで置き換えます。マウント・ポイント/u01/dataが変更されていないことを確認します。従来のfstabオプションを参照してください。
7. /etc/fstabファイルを保存したら、次のコマンドを発行します。
  1. sudo systemctl daemon-reload
  2. sudo mount -a
8. lsblkを実行してマウント・ポイントを確認します。
Essbaseサービスを(oracleユーザーとして)開始します。

ノート:

ターゲットEssbaseスタックに正常にリカバリしたら、障害が発生したソース・コンピュート・ノードを削除し、不要なブロック・ボリュームおよびバックアップをさらにクリーン・アップできます。