Autonomous Databaseをクローニングするには、コンソールを使用しているか、REST APIをSDK、CLIまたは別のツールとともに使用しているかに関係なく、管理者によって記述された次のポリシー文を使用して、必要なアクセスが必要です:

Allow group <Group_Name>
to manage autonomous-databases
in compartment <Compartment_Name>

Allow group <Group_Name>
to read autonomous-container-databases
in compartment <Compartment_Name>

データベース・インスタンスからクローニングする場合:

• ソースおよびターゲットの暗号化キーは、同じキーストア・タイプである必要があります。

• クローン・データベースに指定するADMINパスワードは、ソース・データベースのADMINデータベース・ユーザーとは異なる必要があります。そうしないと、クローン操作は失敗します。

• フル・クローンの場合、クローン・データベースに指定できる最小ストレージは、ソース・データベースで実際に使用されている領域をGB単位に切り上げたものになります。

バックアップからクローニングする場合:

• ターゲットAutonomous Exadata VMクラスタには、最小に4 ECPUまたは1 OCPUが必要です。使用可能なCPUの数は、Oracle Cloud InfrastructureコンソールのAutonomous Exadata VMクラスタのリストから表示できます。詳細は、Autonomous Exadata VMクラスタのリストの表示を参照してください。

• ソースとターゲットの暗号化キーのキーストアは、異なるタイプでかまいません。ただし、次の要件を満たす必要があります。

  • ソースとターゲットの両方がOracle Key Vault (OKV)を使用して顧客管理キーを使用する場合は、同じOKV宛先を使用する必要があります。ターゲットAutonomous Exadata VMクラスタおよびAutonomous Container Databaseでは、キーのソースOracle Key Vault (OKV)へのアクセスが必要になります。

  • Oracle Cloudで、ソースがKMSを介して顧客管理キーを使用する場合、リストア操作中にターゲットAutonomous Exadata VMクラスタがソースKMSボールトにアクセスできることを確認する必要があります。

宛先テナンシでクローンを作成するコマンドを実行し、宛先テナンシがクローン・ソースが存在するソース・テナンシに接続できるように、ソース・テナンシおよび宛先テナンシのOCI Identity and Access Managementグループおよびポリシーを定義します。これらのポリシーが取り消されると、テナンシ間クローニングは許可されません。

• 宛先テナンシで、グループ(たとえば: DestinationGroup)を作成し、このグループへのクロス・テナンシ・クローンの作成を許可されるユーザーを追加します。ガイダンスは、コンソールを使用したグループの作成を参照してください。

• ソース・テナンシで、宛先テナンシ(DestinationGroup)で作成されたグループがソース・テナンシのクローン・ソースを使用してクローンを作成できるようにするIAMポリシーを作成します。ガイダンスは、コンソールを使用したポリシーの作成を参照してください。

  たとえば、次に示すように、ソース・テナンシ上の指定されたコンパートメント内の特定のAutonomous DatabaseインスタンスからDestinationTenancyのDestinationGroupでユーザーが読み取れるようにするポリシーを定義できます:

  define tenancy DestinationTenancy as ocid1.tenancy.oc1..unique_ID
  define group DestinationGroup as ocid1.group.region1..unique_ID
  admit group DestinationGroup of tenancy DestinationTenancy to read autonomous-database-family
         in compartment ocid1.compartment.region1..unique_ID 
         where target.id = 'oc1.autonomousdatabase.oc1..unique_ID'

  ノート
  
  ポリシーでは、ソースAutonomous Databaseインスタンスでの読取りアクセスを許可してクロス・テナンシ・クローンを作成することのみが必要です。
  前述のポリシーでは、次を指定します。

  • 行1: クローンを作成する宛先テナンシのOCID。
  • 行2: クローンを作成するユーザーが属する宛先グループのOCID。
  • 行3: クローン・ソースが存在するコンパートメントのOCID、およびクローン・ソースのOCID (Autonomous Databaseインスタンスまたはバックアップ)。
    ノート
    
    前述の例のwhere句はオプションです。特定のクローン・ソースへのアクセス権を付与するためのより詳細な方法を提供します。

• 宛先テナンシで、ソース・テナンシのクローン・ソースを管理するためのグループを承認するIAMポリシーを作成します。ガイダンスは、コンソールを使用したポリシーの作成を参照してください。

  例:

  Define tenancy SourceTenancy as ocid1.tenancy.oc1..unique_ID
  Endorse group DestinationGroup to manage autonomous-database-family in tenancy SourceTenancy

  前述のポリシーでは、次を指定します。

  • 行1: クローン・ソースが存在するソース・テナンシOCIDのOCID。
  • 行2: ソース・テナンシでAutonomous Databasesを管理できる宛先グループを指定します。

  前述の例で説明したこのポリシーにより、DestinationGroupはソース・テナンシにAutonomous DatabasesおよびAutonomous Databaseクローンを作成できます。クローニング権限を制限して、グループがAutonomous Databasesのみをクローニングし、Autonomous Databasesを作成できないようにしたり、特定のタイプのクローンのみを作成する権限(フル・クローンまたはメタデータ・クローン)をさらに制限できます。詳細および例は、Autonomous DatabaseのIAM権限およびAPI操作を参照してください。

データベース・インスタンスからクローニングする場合:

• Autonomous Data Guardを使用しているデータベースの場合、プライマリ・データベースのみをクローニングできます。ただし、バックアップからのクローニング時には、プライマリ・データベースまたはスタンバイ・データベースのいずれかをクローニングできます。
• 通常のデータベースをAutonomous Database for Developersインスタンスにクローニングすることも、その逆も可能です。ただし、通常のデータベースを開発者データベースに正常にクローニングするには、ソース・データベースの実際の使用済領域を次のGBに切り上げて32GB以下にする必要があります。

バックアップからクローニングする場合:

• メタデータ・クローンはサポートされていません。データベース・クローンの作成には、「フル・クローン」オプションのみを使用できます。

• ターゲットAutonomous Exadata VMクラスタでは、一度に1つのリストア操作のみを実行できます。つまり、単一のAutonomous Exadata VMクラスタに複数のバックアップ・クローンを同時に作成することはできません。

• ソース・データベースに割り当てられた領域が32GB以下の場合のみ、Autonomous Database for Developersにバックアップをクローニングできます。

• ポイントインタイム・クローン・オプションを使用して長期バックアップをクローニングすることはできません。

• 必要に応じて、クローン後にのみCPUを小数値にサイズ変更できます。小数CPU値の使用の詳細は、「CPUオーバープロビジョニング」を参照してください。

• Exadata Cloud@Customerの場合:

  • ローカル・ディスクベースのバックアップをクローニングに使用することはできません。
  • Autonomous Databaseのクローニングにかかる時間は、CPU数と、バックアップ保存先とターゲットのAutonomous Container Databaseの間のネットワーク帯域幅によって異なります。