Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Oracle データベースバックアップをクローニングする

共同作成者
PDF

SnapCenter を使用して、データベースのバックアップを使用して Oracle データベースをクローニングすることができます。

  • このタスクについて *

クローニング処理では、データベースデータファイルのコピーが作成され、新しいオンライン REDO ログファイルと制御ファイルが作成されます。指定したリカバリ・オプションに基づいて、データベースを指定した時刻までリカバリすることもできます。

メモ Linux ホストで作成されたバックアップを AIX ホストにクローニングしようとすると、クローニングが失敗します。その逆も同様です。

SnapCenter では、 Oracle RAC データベースのバックアップからクローニングした場合にスタンドアロンデータベースが作成されます。SnapCenter では、 Data Guard スタンバイデータベースおよび Active Data Guard スタンバイデータベースのバックアップからのクローニングをサポートしています。

クローニング中に、 SnapCenter はリカバリ処理用にログバックアップをマウントします。リカバリ後、ログバックアップはアンマウントされます。これらのクローンはすべて、 /var/opt/snapcenter /scu/clones/_ の下にマウントされます。NFS 経由で ASM を使用している場合は、 ASM_diskstring パラメータで定義された既存のパスに /var/opt/snapcenter /scu/clones/*/*_ を追加する必要があります。

SAN 環境で ASM データベースのバックアップをクローニングする際には、クローニングされるホストデバイスの udev ルールが /etc/udev/rules.d/ 999-scu-netapp.rules_ に作成されます。クローニングされるホストデバイスに関連付けられた udev ルールは、クローンを削除すると削除されます。

メモ Flex ASM 設定では、カードの数が RAC クラスタ内のノード数より少ない場合、リーフノードでクローン操作を実行できません。

  • 手順 *

    1. 左側のナビゲーションペインで、 * リソース * をクリックし、リストから適切なプラグインを選択します。

    2. [ リソース ] ページで、 [ * 表示 ] リストから [ * データベース * ] または [ * リソースグループ * ] を選択します。

    3. データベースの詳細ビューまたはリソースグループの詳細ビューでデータベースを選択します。

      データベーストポロジのページが表示されます。

    4. [ コピーの管理 ] ビューで、バックアップを [ ローカルコピー ] （プライマリ）、 [ ミラーコピー ] （セカンダリ）、または [ バックアップコピー ] （セカンダリ）から選択します。

    5. 表からデータバックアップを選択し、 * をクリックしますクローンアイコン*

    6. [ 名前 ] ページで、次のいずれかの操作を実行します。

      状況 手順

      データベース（ CDB または CDB 以外）のクローンを作成します。

      1. クローンの SID を指定します。

        クローンの SID はデフォルトでは使用できず、 SID の最大長は 8 文字です。

        メモ クローンを作成するホストに、同じ SID を持つデータベースが存在しないようにします。

      Pluggable Database （ PDB ）のクローニング

      1. [PDB Clone] を選択します。

      2. クローニングする PDB を指定します。

      3. クローニングされた PDB の名前を指定します。PDB をクローニングする詳細な手順については、を参照してください "プラグイン可能なデータベースをクローニングします"。

      ミラーデータまたはバックアップデータを選択した場合：

      • ミラーまたはボルトにログバックアップがない場合、何も選択されず、ロケータは空です。

      • ミラーまたはバックアップにログバックアップが存在する場合は、最新のログバックアップが選択され、対応するロケータが表示されます。

        メモ 選択したログバックアップがミラーとバックアップの場所の両方に存在する場合、両方のロケータが表示されます。

    7. [ 場所 ] ページで、次の操作を実行します。

      フィールド 手順

      ホストをクローニングする

      ソースデータベースホストがデフォルトで入力されています。

      代替ホスト上にクローンを作成する場合は、ソース・データベース・ホストと同じバージョンの Oracle および OS を持つホストを選択します。

      データファイルの場所

      データファイルの場所がデフォルトで入力されています。

      SAN または NFS ファイルシステムの SnapCenter のデフォルトの命名規則は、 FileSystemNameofsourcedatabE_CLONESID です。

      ASM ディスクグループの SnapCenter のデフォルトの命名規則は、 SC_HASHCODEofDISKGROUP_CLONESID です。HASHCODEofDISKGROUP は、 ASM ディスクグループごとに一意の自動生成番号（ 2 ～ 10 桁）です。

      メモ ASM ディスクグループ名をカスタマイズする場合は、 Oracle がサポートする最大長に名前の長さが準拠していることを確認してください。

      別のパスを指定する場合は、クローンデータベースのデータファイルマウントポイントまたは ASM ディスクグループ名を入力する必要があります。データファイルパスをカスタマイズする場合は、制御ファイルと REDO ログファイルの ASM ディスクグループ名またはファイルシステムも、データファイルに使用されている名前か、既存の ASM ディスクグループまたはファイルシステムに変更する必要があります。

      制御ファイル

      制御ファイルのパスがデフォルトで入力されています。

      制御ファイルは、データファイルと同じ ASM ディスクグループまたはファイルシステムに配置されます。制御ファイルのパスを無効にする場合は、別の制御ファイルのパスを指定します。

      メモ ファイルシステムまたは ASM ディスクグループがホストに存在する必要があります。

      デフォルトでは、制御ファイルの数はソースデータベースの数と同じになります。制御ファイルの数は変更できますが、データベースをクローニングするには少なくとも 1 つの制御ファイルが必要です。

      制御ファイルのパスを、ソースデータベースとは異なるファイルシステム（既存）にカスタマイズできます。

      REDO ログ

      redo ログファイルグループ、パス、およびサイズがデフォルトで入力されています。

      REDO ログは、クローンデータベースのデータファイルと同じ ASM ディスクグループまたはファイルシステムに配置されます。REDO ログファイルのパスを上書きする場合は、ソースデータベースとは別のファイルシステムに REDO ログファイルのパスをカスタマイズできます。

      メモ 新しいファイルシステムまたは ASM ディスクグループがホストに存在する必要があります。

      デフォルトでは、 Redo ロググループの数、 Redo ログファイルのサイズはソースデータベースのサイズと同じになります。次のパラメータを変更できます。

      • Redo ロググループの数

      メモ データベースをクローニングするには、少なくとも 2 つの REDO ロググループが必要です。

      • 各グループの REDO ログファイルとそのパス

        REDO ログファイルのパスを、ソースデータベースとは別のファイルシステム（既存）にカスタマイズできます。

      メモ データベースをクローニングするには、 Redo ロググループに少なくとも 1 つの REDO ログファイルが必要です。

      • Redo ログファイルのサイズ

    8. [Credentials] ページで、次の操作を実行します。

      フィールド 手順

      sys ユーザのクレデンシャル名

      クローンデータベースのシステムユーザパスワードを定義するために使用するクレデンシャルを選択します。

      ターゲットホストの sqlnet.ora ファイルで SQLNET.authentication_services が none に設定されている場合は、 SnapCenter GUI で Credential として *None を選択しないでください。

      ASM インスタンス資格情報名

      クローンホスト上の ASM インスタンスへの接続に対して OS 認証が有効な場合は、「 * なし」を選択します。

      それ以外の場合は、「 'sys' 」ユーザまたはクローン・ホストに適用可能な「 'ysasm' 」権限を持つユーザで構成された Oracle ASM クレデンシャルを選択します。

      Oracle ホーム、ユーザ名、およびグループの詳細が、ソースデータベースから自動的に入力されます。この値は、クローンを作成するホストの Oracle 環境に基づいて変更できます。

    9. PreOps ページで、次の手順を実行します。

      1. クローニング処理の前に実行するプリスクリプトのパスと引数を入力します。

        プリスクリプトは、 _ /var/opt/snapcenter /spl/scripts_or 内のいずれかのフォルダに保存する必要があります。デフォルトでは、 /var/opt/snapcenter /spl/scripts_path が読み込まれます。このパス内の任意のフォルダにスクリプトを配置した場合は、スクリプトが配置されているフォルダまでの完全なパスを指定する必要があります。

      2. Database Parameter settings セクションで、データベースの初期化に使用される、すでに入力されているデータベースパラメータの値を変更します。

  • をクリックすると、パラメータを追加できます*

    Oracle Standard Edition を使用していて、データベースがアーカイブログモードで実行されている場合、またはアーカイブ REDO ログからデータベースをリストアする場合は、パラメータを追加してパスを指定します。

    • LOG_ARCHIVE _ dest の略

    • log_archive_duplex_dest

      メモ Fast Recovery Area （ FRA ）は、すでに格納されているデータベースパラメータに定義されていません。関連パラメータを追加することで、 FRA を構成できます。
      メモ LOG_ARCHIVE のデフォルト値は $ORACLE_HOME/clone_sid で、クローンデータベースのアーカイブログはこの場所に作成されます。log_archive_dest_1 パラメータを削除した場合、アーカイブ・ログの場所は Oracle によって決定されます。log_archive_dest_1 を編集して、アーカイブ・ログの新しい場所を定義できます。ただし、ファイル・システムまたはディスク・グループが、ホスト上に存在し、使用可能になっている必要があります。

      1. [*Reset] をクリックして、データベースパラメータのデフォルト設定を取得します。

        1. PostOps ページで、 * Recover database * および * Until Cancel * がデフォルトで選択されて、クローンデータベースのリカバリを実行します。

          SnapCenter は、クローニング用に選択されたデータバックアップ後に、破損していない一連のアーカイブログを含む最新のログバックアップをマウントすることによってリカバリを実行します。セカンダリストレージでクローンを実行するには、プライマリストレージでログとデータのバックアップを実行し、セカンダリストレージでログとデータのバックアップを実行する必要があります。

          SnapCenter が適切なログ・バックアップを検出できない場合は、 [ データベースのリカバリ * ] および [ キャンセルまで * ] オプションは選択されません。外部アーカイブログの場所を指定する： * でログバックアップを使用できない場合は、外部アーカイブログの場所を指定します。 *複数のログの場所を指定できます。

          メモ フラッシュリカバリ領域（ FRA ）と Oracle Managed Files （ OMF ）をサポートするように設定されているソースデータベースをクローニングする場合は、リカバリのログデスティネーションも OMF ディレクトリ構造に従っている必要があります。

        ソースデータベースが Data Guard スタンバイデータベースまたは Active Data Guard スタンバイデータベースの場合、 PostOps ページは表示されません。Data Guard スタンバイデータベースまたは Active Data Guard スタンバイデータベースの場合、 SnapCenter には SnapCenter GUI でリカバリのタイプを選択するオプションはありませんが、ログを適用せずに、 Cancel リカバリタイプを使用してデータベースをリカバリします。

      フィールド名 説明

      キャンセルするまで

      SnapCenter は、クローニング用に選択されたデータバックアップのあとに、アーカイブログの連続が解除された最新のログバックアップをマウントすることによってリカバリを実行します。クローンデータベースは、欠落または破損したログファイルまでリカバリされます。

      日付と時刻

      SnapCenter は、指定された日時までデータベースをリカバリします。指定できる形式は、 mm/dd/yyyy hh:mm:ss です

      メモ 時刻は 24 時間形式で指定できます。

      Until SCN （システム変更番号）

      SnapCenter は、指定された System Change Number （ SCN ）までデータベースをリカバリします。

      外部アーカイブログの場所を指定します

      外部アーカイブログの場所を指定します。

      新しい DBID を作成します

      デフォルトでは、 * 新しい DBID * を作成チェック・ボックスが選択され、ソース・データベースとは別の、クローン・データベースに一意の番号（ DBID ）が生成されます。

      ソースデータベースの DBID をクローンデータベースに割り当てる場合は、このチェックボックスをオフにします。このシナリオでは、ソースデータベースがすでに登録されている外部の RMAN カタログにクローニングされたデータベースを登録する場合に、処理が失敗します。

      一時表領域用の tempfile を作成します

      クローニングされたデータベースのデフォルトの一時表領域に対して一時ファイルを作成する場合は、チェックボックスをオンにします。

      このチェックボックスをオフにすると、 tempfile を使用せずにデータベースクローンが作成されます。

      クローン作成時に適用する SQL エントリを入力します

      クローン作成時に適用する SQL エントリを追加します。

      クローニング処理のあとに実行するスクリプトを入力します

      クローニング処理の実行後に実行するポストスクリプトのパスと引数を指定します。

      PostScript は /var/opt/snapcenter /spl/scripts_or に保存するか、このパス内の任意のフォルダに保存する必要があります。デフォルトでは、 /var/opt/snapcenter /spl/scripts_path が読み込まれます。

      このパス内の任意のフォルダにスクリプトを配置した場合は、スクリプトが配置されているフォルダまでの完全なパスを指定する必要があります。

      1. [ 通知 ] ページの [ 電子メールの設定 *] ドロップダウンリストから、電子メールを送信するシナリオを選択します。

        また、送信者と受信者の E メールアドレス、および E メールの件名を指定する必要があります。実行したクローン処理のレポートを添付する場合は、 * ジョブレポートの添付 * を選択します。

    メモ E メール通知を利用する場合は、 GUI または PowerShell コマンド Set-SmtpServer を使用して、 SMTP サーバの詳細を指定しておく必要があります。

    1. 概要を確認し、 [ 完了 ] をクリックします。

      メモ クローニング処理の一環としてリカバリを実行する場合は、リカバリが失敗してもクローンが作成され、警告が表示されます。このクローンに対して手動リカバリを実行することで、クローンデータベースの整合性を確保できます。

    2. 操作の進行状況を監視するには、 * Monitor * > * Jobs * をクリックします。

  • 結果 *

データベースをクローニングしたあとにリソースページを更新すると、クローンデータベースが、バックアップに使用できるリソースの 1 つとしてリストに追加されます。クローンデータベースは、標準バックアップワークフローを使用して他のデータベースと同様に保護することも、リソースグループ（新規作成または既存）に含めることもできます。クローニングされたデータベースは、さらにクローニング（クローンのクローニング）が可能です。

クローニング後は、クローンデータベースの名前を絶対に変更しないでください。

メモ クローニング中にリカバリを実行しなかった場合は、不適切なリカバリが原因でクローンデータベースのバックアップが失敗し、手動によるリカバリが必要になることがあります。また、アーカイブログが格納されたデフォルトの場所がネットアップ以外のストレージにある場合や、ストレージシステムに SnapCenter が設定されていない場合も、ログバックアップが失敗することがあります。

AIX のセットアップでは、 lkdev コマンドを使用して、クローニングされたデータベースが存在するディスクの名前をロックし、 rendev コマンドを使用して変更できます。

デバイスをロックしたり名前を変更したりしても、クローンの削除処理には影響しません。SAN デバイス上に構築された AIX LVM レイアウトの場合、クローニングされた SAN デバイスではデバイスの名前変更はサポートされません。