Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Oracleデータベースバックアップのクローニング

共同作成者

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

  • 始める前に *

root以外のユーザとしてプラグインをインストールした場合は、実行権限をプリスクリプトディレクトリとポストスクリプトディレクトリに手動で割り当てる必要があります。

  • このタスクについて *

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

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

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

    クローニング中、SnapCenterでは、SCNまたはDATとリカバリ処理の時間に基づいて、最適な数のログバックアップがマウントされます。リカバリが完了すると、ログバックアップがアンマウントされます。これらのクローンはすべて、 /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クラスタ内のノード数より少ない場合、リーフノードでクローン操作を実行できません。
  • SnapLockが有効なポリシーの場合、ONTAP 9.12.1以前のバージョンでは、Snapshotロック期間を指定すると、リストアの一環として改ざん防止Snapshotから作成されたクローンにSnapLockの有効期限が継承されます。SnapLockの有効期限が過ぎた時点で、ストレージ管理者がクローンを手動でクリーンアップする必要があります。

  • 手順 *

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

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

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

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

    4. [コピーの管理]ビューで、ローカルコピー(プライマリ)、ミラーコピー(セカンダリ)、バックアップコピー(セカンダリ)のいずれかのバックアップを選択します。

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

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

      状況 手順

      データベースのクローニング(CDBまたは非CDB)

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

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

        メモ クローンを作成するホストに、同じSIDのデータベースが存在しないことを確認してください。

      プラガブルデータベース(PDB)のクローニング

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

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

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

      ミラーデータまたはバックアップデータを選択する場合:

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

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

        メモ 選択したログバックアップがミラーとバックアップの両方の場所に存在する場合は、両方のロケータが表示されます。
    7. [ 場所 ] ページで、次の操作を実行します。

      フィールド 操作

      クローンホスト

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

      別のホストにクローンを作成する場合は、ソースデータベースホストと同じバージョンのOracleおよびOSがインストールされているホストを選択します。

      データファイルの場所

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

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

      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ユーザのクレデンシャル名

      クローンデータベースの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 が読み込まれます。スクリプトをこのパス内の任意のフォルダに配置した場合は、スクリプトを配置するフォルダまでの完全なパスを指定する必要があります。

        SnapCenterでは、プリスクリプトとポストスクリプトの実行時に、事前定義された環境変数を使用できます。 "詳細"

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

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

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

        • LOG_ARCHIVE _ dest の略

        • log_archive_duplex_dest

          メモ データが格納されているデータベースパラメータでは、高速リカバリ領域(FRA)は定義されていません。FRAを設定するには、関連パラメータを追加します。
      メモ log_archive_dest_1のデフォルト値は$ORACLE_HOME/clone_sidで、この場所にクローンデータベースのアーカイブログが作成されます。log_archive_dest_1パラメータを削除した場合、アーカイブログの場所はOracleによって決定されます。log_archive_dest_1を編集してアーカイブログの新しい場所を定義できますが、ファイルシステムまたはディスクグループが存在し、ホスト上で使用可能になっている必要があります。
      1. [*Reset] をクリックして、データベースパラメータのデフォルト設定を取得します。

    10. 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でリカバリタイプを選択するオプションはありませんが、ログを適用せずに[キャンセル]リカバリタイプを使用してデータベースをリカバリします。

      フィールド名 説明

      キャンセルするまで

      SnapCenterは、クローニング対象として選択されたデータバックアップのあとに、破損していない一連のアーカイブログを含む最新のログバックアップをマウントすることでリカバリを実行します。クローンデータベースは、欠落または破損したログファイルまでリカバリされます。

      日付と時刻

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

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

      SCN(システム変更番号)まで

      SnapCenterは、指定されたシステム変更番号(SCN)までデータベースをリカバリします。

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

      データベースがARCHIVELOGモードで実行されている場合、SnapCenterは指定したSCNまたは選択した日時に基づいて、最適な数のログバックアップを識別してマウントします。

      外部アーカイブログの場所を指定することもできます。

      メモ [Until Cancel]を選択した場合、SnapCenterはログバックアップを自動的に識別してマウントしません。

      新しいDBIDの作成

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

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

      一時表領域用の一時ファイルの作成

      クローンデータベースのデフォルトの一時表領域用の一時ファイルを作成する場合は、このチェックボックスを選択します。

      このチェックボックスをオフにすると、一時ファイルなしでデータベースクローンが作成されます。

      クローンの作成時に適用するSQLエントリを入力してください

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

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

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

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

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

      メモ クローニング処理が失敗した場合、ポストスクリプトは実行されず、クリーンアップアクティビティが直接トリガーされます。
    11. [ 通知 ] ページの [ 電子メールの設定 *] ドロップダウンリストから、電子メールを送信するシナリオを選択します。

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

    メモ Eメール通知を使用する場合は、GUIまたはPowerShellコマンドSet-SmSmSmtpServerを使用して、SMTPサーバの詳細を指定しておく必要があります。
    1. 概要を確認し、 [ 完了 ] をクリックします。

      メモ クローニング処理の一環としてリカバリを実行する場合は、リカバリが失敗してもクローンが作成され、警告が表示されます。このクローンに対して手動リカバリを実行すると、クローンデータベースの整合性を維持できます。
    2. 操作の進行状況を監視するには、 * Monitor * > * Jobs * をクリックします。

  • 結果 *

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

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

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

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

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