DBシステムについて
Oracle Cloud Infrastructure (OCI)は仮想マシン上のDBシステムを提供します。
仮想マシン上のデータベース・システム(DBシステム)には、2つのタイプがあります:
- 単一ノードDBシステム: 1ノードのDBシステムは、1つの仮想マシンで構成されます。
- マルチノードRAC DBシステム: 2ノードのDBシステムは、2つの仮想マシンで構成されます。
開発またはテスト目的でDBシステムをプロビジョニングする必要がある場合は、特別な高速プロビジョニング単一ノードDBシステムを使用できます。
DBシステムを作成する場合、そのDBシステムのデータベースに適用するOracle AI Databaseのエディションおよびバージョンを選択します。選択したエディションは変更できません。選択したOracle AI Databaseのエディションおよびバージョンによっては、DBシステムで複数のプラガブル・データベース(PDB)をサポートできます。選択したOracle AI Databaseバージョンで使用可能なプラガブル・データベースおよびコンテナ・データベース(CDB)の最大数の詳細は、次のOracle AI Databaseライセンスのトピックを参照してください。
- Oracle Database 19c: Oracle AI Databaseオファリングにより許可された機能、オプションおよび管理パック
DBシステムは単一のデータベース・ホームのみ持つことができ、データベース・ホームには単一のデータベースのみ含めることができます。DBシステム・データベースでは、ローカル・ストレージではなくOCIブロック・ストレージを使用します。DBシステムの作成時にストレージ・サイズを指定し、必要に応じていつでもストレージをスケール・アップできます。既存のDBシステムのCPUコア数を変更するには、そのDBシステムのシェイプを変更する必要があります。詳細は、DB Systemのシェイプの変更を参照してください。
ノート:マルチノードのRAC DBシステムでは、シェイプ変更操作はローリング方式で実行されるため。データベースのダウンタイムなしでシェイプを変更できます。
使用可能なシェイプおよび割り当てられるリソースの決定方法
DBシステムを作成するときに、DBシステムに割り当てられるリソースを決定するシェイプを選択してください。DBシステムを作成した後、そのシェイプを新しい処理能力要件に適応するように変更できます。次のシェイプを使用できます:
注意:
Oracle Base Database Serviceは、2026年7月31日より、VM.Standard.x86シェイプ、Enterprise Edition - Extreme Performance (EE-EP)ソフトウェア・エディションおよびOCPU従量制サービスSKUのリタイアを発表しました。既存のデプロイメントは引き続き実行されますが、新しいプロビジョニングと契約の更新が影響を受けます。
必要に応じて、ECPUメトリックを使用してVM.BaseDB.x86への移行を計画するか、EE-EPワークロードの場合はOracle Exadata Database Service on Exascale Infrastructure (ExaDB-XS)に移行します。影響を受けるSKU、お客様への影響および移行ガイダンスの詳細は、My Oracle Supportの記事KB921246を参照してください。
フレキシブル・シェイプ
フレキシブル・シェイプでは、インスタンスに割り当てられるECPUまたはOCPUなどのコンピュート・リソースをカスタマイズできます。フレキシブル・シェイプを使用してインスタンスを作成する場合は、インスタンスで実行されるワークロードに必要なコンピュート・リソースを選択します。この柔軟性により、ワークロードと一致するインスタンスを構築できるため、パフォーマンスを最適化し、コストを最小限に抑えることができます。許容されるメモリー量は、選択したECPUまたはOCPUの数に基づいており、メモリーとECPUまたはOCPUの比率はシェイプによって異なります。
フレキシブル・シェイプは、Ampere、AMDおよびIntelプロセッサで使用できます。次の表に、使用可能なシェイプを示します。
| 形状 | コンピュート | メモリー |
|---|---|---|
| VM.BaseDB.x86 | 最小は4 ECPU、最大は256 ECPUです。 4の増分である必要があります。 |
4 ECPUごとに8 GB。 最小は8 GBで、最大は512 GBの合計メモリーです。 |
| VM.Standard.x86 | 最小は4 ECPU、最大は252 ECPUです。 4の増分である必要があります。 |
4 ECPUごとに8 GB。 最小は8 GBで、最大は504 GBの合計メモリーです。 |
| Ampere VM.Standard.A1。フレックス | 最小は1 OCPU、最大は57 OCPUです。 | OCPU当たり8 GB。 最小は8 GBで、最大は456 GBの合計メモリーです。 |
| AMD VM.Standard.E5。フレックス | 最小は1 OCPU、最大は64 OCPUです。 | OCPU当たり16 GB。 最小は 16 GB、最大は 1024 GBの合計メモリーです。 |
| AMD VM.Standard.E4.Flex | 最小は1 OCPU、最大は64 OCPUです。 | OCPU当たり16 GB。 最小は 16 GB、最大は 1024 GBの合計メモリーです。 |
| Intel X9 VM.Standard3.Flex | 最小は1 OCPU、最大は32 OCPUです。 | OCPU当たり16 GB。 最小は 16 GB、最大は 512 GBの合計メモリーです。 |
注意:
- ArmベースのAmpere A1シェイプは、23.7.0.0、19.19.0.0およびそれ以降のリリース更新(RU)以降、Oracle AI Databaseバージョン26aiおよび19cでのみ使用できます。
- AMD E5シェイプは、23.4.0.24.05、19.21.0.0およびそれ以降のリリース更新(RU)以降のOracle AI Databaseバージョン26aiおよび19cでのみ使用できます。
- AMD E4シェイプは、23.4.0.24.05、21.6.0.0、19.15.0.0およびそれ以降のリリース更新(RU)を含むOracle AI Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- Intel X9シェイプは、23.4.0.24.05、21.8.0.0、19.17.0.0およびそれ以降のリリース更新(RU)を含むOracle AI Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- マルチノードRAC DBシステムでは、ノードごとに少なくとも2 OCPUが必要です。
世代に依存しないX86シェイプ
VM.BaseDB.x86シェイプおよびVM.Standard.x86シェイプは、世代に依存しない柔軟なx86シェイプであり、DBシステムに割り当てられるECPUの数をカスタマイズできます。これらのシェイプは、サポートされているx86インフラストラクチャ世代にわたって一貫したエクスペリエンスを提供しながら、ワークロード要件に基づいてコンピュート・リソースをスケーリングできます。
x86シェイプには次の特性があります。
- ECPUベースの請求を使用して、より詳細な使用量ベースの価格設定を実現します。
- VM.BaseDB.x86は、Oracle AI Database 26aiおよびOracle Database 19cをサポートしています。
- VM.Standard.x86は、Oracle AI Database 26aiのみをサポートします。
-
次のOracle AI Databaseソフトウェア・エディションをサポートします。
- Standard Edition
- Enterprise Edition
- Enterprise Edition - High Performance
- ストレージ管理のためのLogical Volume Managerのサポート。
- 単一ノードのDBシステムのみをサポートします。
ノート: x86シェイプでは、フォルト・ドメインはサポートされていません。
ArmベースのAmpere A1シェイプ
ArmベースのAmpere A1シェイプは柔軟性があり、インスタンスに割り当てられるOCPUの数をカスタマイズできます。次に、Ampere A1シェイプに関する追加詳細を示します。
- Ampere A1シェイプは、Logical Volume Managerでのみサポートされています。
- Ampere A1シェイプは、単一ノードのDBシステムでのみサポートされています。
- Oracle AI Database Standard Editionは、Ampere A1シェイプベースのDBシステムではサポートされていません。
- データベース・ソフトウェア・イメージは、Ampere A1シェイプベースのDBシステムでのデータベースの作成には使用できません。
- Ampere A1シェイプベースのDBシステムのプロビジョニングとリストアは、データベースのバックアップの保存先がAutonomous Recovery Serviceの場合、サポートされていません。
- Ampere A1シェイプは、OCIボールト暗号化を使用するデータベースではサポートされていません。
- Ampere A1シェイプベースのDBシステムのシェイプは、IntelまたはAMDのシェイプベースのDBシステム(またはその逆)に変更できません。
- Ampere A1シェイプベース・データベースのバックアップは、IntelまたはAMDシェイプベースDBシステム(またはその逆)ではリストアできません。
- Ampere A1シェイプベースのDBシステムでは、IntelまたはAMDシェイプベースのDBシステムとのData Guardアソシエーションはサポートされていません。
標準シェイプ
標準シェイプは、Intelプロセッサで使用できます。
次の表に、X7シリーズで使用可能なシェイプを示します。
| 形状 | CPUコア | メモリー |
|---|---|---|
| VM.Standard2.1 | 1 | 15GB |
| VM.Standard2.2 | 2 | 30GB |
| VM.Standard2.4 | 4 | 60GB |
| VM.Standard2.8 | 8 | 120GB |
| VM.Standard2.16 | 16 | 240GB |
| VM.Standard2.24 | 24 | 320GB |
注意:
- Intel X7シェイプは、Oracle AI Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- VM.Standard2.1シェイプは、マルチノードのRAC DBシステムには使用できません。
使用可能なデータベース・バージョン
OCIでは、次のシェイプ要件に従って、古いデータベース・バージョンを使用したDBシステムの作成がサポートされています。
承認された最新のリリース更新は、デフォルトで利用可能です。表示されるメッセージを確認した後、前述の2つのリリース更新(N-1またはN-2)のいずれかを選択することもできます。N-2より前のリリース更新を使用するには、サービス・リクエストを発行する必要があります。
- ArmベースのAmpere A1シェイプは、23.7.0.0、19.19.0.0およびそれ以降のリリース更新(RU)以降、Oracle AI Databaseバージョン26aiおよび19cでのみ使用できます。
- AMD E5シェイプは、23.4.0.24.05、19.21.0.0およびそれ以降のリリース更新(RU)以降のOracle AI Databaseバージョン26aiおよび19cでのみ使用できます。
- AMD E4シェイプは、23.4.0.24.05、21.6.0.0、19.15.0.0およびそれ以降のリリース更新(RU)を含むOracle AI Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- Intel X9シェイプは、23.4.0.24.05、21.8.0.0、19.17.0.0およびそれ以降のリリース更新(RU)を含むOracle AI Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- Intel X7シェイプは、Oracle AI Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- Intel X9シェイプからAMD E4およびE5シェイプへの移行はサポートされていません。
- AMD E4シェイプへの移行は、21.6.0.0、19.15.0.0以降のリリース更新のベース・イメージを使用しているインスタンスでのみサポートされます。これらのリリース更新前に作成されたインスタンスでは、ベース・イメージ自体が移行をサポートしていないため、更新および移行できません。
- Intel X9シェイプへの移行は、21.8.0.0、19.17.0.0およびそれ以降のリリース更新でベース・イメージを使用するインスタンスでのみサポートされています。これらのリリース更新前に作成されたインスタンスでは、ベース・イメージ自体が移行をサポートしていないため、更新および移行できません。
古いデータベース・バージョンでDBシステムを作成する必要がある場合、選択したデータベース・バージョンで既知のセキュリティ問題の詳細は、クリティカル・パッチ・アップデートに関する項を参照してください。また、古いデータベース・バージョンに含まれているオペレーティング・システムについて、既知のセキュリティ問題を分析してパッチ適用する必要があります。OCIのデータベースに対するセキュリティのベスト・プラクティスの詳細は、データベースの保護に関する項を参照してください。
様々な構成が使用可能なストレージに与える影響
DBシステムではOCIブロック・ストレージが使用されます。次の表に、使用可能なストレージ・オプションの詳細を示します。合計ストレージには、使用可能なストレージとリカバリ・ログが含まれます。
一般情報
- データ・ストレージとリカバリ・ストレージは個別にスケーリングできます。リカバリ・ストレージを常に合計ストレージの20%以上にしておくことをお薦めします。
- マルチノードのRAC DBシステムの場合、ストレージ容量はノード間で共有されます。
- リカバリ領域ストレージは、選択したストレージに基づいて決定されます。ただし、プロビジョニング後にリカバリ領域ストレージを個別に変更できます。
- 合計ストレージは、使用可能なデータ・ストレージ、リカバリ領域ストレージ、およびDBシステム・ソフトウェア用に予約された200 GBの合計です。
フレキシブル・シェイプに使用可能なデータ・ストレージ
| 使用可能なデータ・ストレージ(GB) | リカバリ領域ストレージ(GB) | 合計ストレージ(GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1024 | 512 | 1736 |
| 2048 | 512 | 2760 |
| 4096 | 1024 | 5320 |
| 8192 | 2048 | 10440 |
| 12288 | 4096 | 16584 |
| 16384 | 4096 | 20680 |
| 24576 | 8192 | 32968 |
| 32768 | 8192 | 41160 |
| 40960 | 10240 | 51400 |
| 49152 | 12288 | 61640 |
| 57344 | 14336 | 71880 |
| 65536 | 16384 | 82120 |
| 73728 | 18432 | 92360 |
| 81920 | 20480 | 102600 |
標準シェイプに使用可能なデータ・ストレージ
| 使用可能なデータ・ストレージ(GB) | リカバリ領域ストレージ(GB) | 合計ストレージ(GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1024 | 256 | 1480 |
| 2048 | 408 | 2656 |
| 4096 | 820 | 5116 |
| 6144 | 1228 | 7572 |
| 8192 | 1640 | 10032 |
| 10240 | 2048 | 12488 |
| 12288 | 2456 | 14944 |
| 14336 | 2868 | 17404 |
| 16384 | 3276 | 19860 |
| 18432 | 3688 | 22320 |
| 20480 | 4096 | 24776 |
| 22528 | 4504 | 27232 |
| 24576 | 4916 | 29692 |
| 26624 | 5324 | 32148 |
| 28672 | 5736 | 34608 |
| 30720 | 6144 | 37064 |
| 32768 | 6552 | 39520 |
| 34816 | 6964 | 41980 |
| 36864 | 7372 | 44436 |
| 38912 | 7784 | 46896 |
| 40960 | 8192 | 49352 |
サービスの制限
ベース・データベース・リソースには、次の制限が適用されます。
| リソース | Oracle Universal Credits | Pay As You Goまたはトライアル |
|---|---|---|
| VM DBブロック・ストレージ合計 | 150TB | 2TB |
| VM.Standard1 - 合計OCPU | 300コア | 2コア |
| VM.Standard2 - 合計OCPU | 300 cores for US West (Phoenix), 300 cores for US East (Ashburn), 50 cores for Germany Central (Frankfurt), 50 cores for UK South (London) |
2コア |
ノート: VM DBブロック・ストレージ合計には、すべてのVM.Standard1およびVM.Standard2仮想マシン・データベースのブロック・ストレージが含まれます。
高速プロビジョニング・オプション
単一ノードDBシステムの場合、OCIには高速プロビジョニング・オプションが提供されており、Logical Volume Manager (LVM)をストレージ管理ソフトウェアとして使用してDBシステムを作成できます。標準的な方法(標準プロビジョニング)は、自動ストレージ管理(ASM)を使用してプロビジョニングすることです。
高速プロビジョニング・オプションには、次の詳細が適用されます:
- 高速プロビジョニング・オプションを使用する場合、プロビジョニング中に指定したブロック・ボリュームの数とサイズによって、スケーリングで使用可能な最大合計ストレージが決まります。
- マルチノードのRAC DBシステムにはASMが必要で、高速プロビジョニング・オプションを使用して作成することはできません。
- 高速プロビジョニング・オプションを使用して作成されたDBシステムをクローニングできます。
- LVMを使用してDBシステムをプロビジョニングする場合、カスタム・データベース・ソフトウェア・イメージは使用できません。
詳細は、次の各トピックを参照してください:
高速プロビジョニングの使用時のストレージのスケーリングの考慮事項
ノート:このトピックは、単一ノードDBシステムにのみ適用されます。
高速プロビジョニング・オプションを使用してDBシステムをプロビジョニングする場合、プロビジョニング中に指定した「使用可能ストレージ(GB)」の値によって、スケーリングで使用可能な最大合計ストレージが決まります。次の表では、プロビジョニング・ワークフローで提供される設定ごとに、スケーリングで使用可能な最大ストレージ値を示します:
| プロビジョニング中に指定した初期ストレージ(GB) | スケーリングで使用可能な最大ストレージ(GB) |
|---|---|
| 256 | 2560 |
| 512 | 2560 |
| 1024 | 5120 |
| 2048 | 10240 |
| 4096 | 20480 |
| 8192 | 40960 |
マルチノードRAC DBシステムのフォルト・ドメインに関する考慮事項
マルチノードのRAC DBシステムをプロビジョニングすると、デフォルトで各ノードが別々のフォルト・ドメインに割り当てられます。プロビジョニング・ダイアログの「拡張オプション」リンクを使用すると、マルチノードのRAC DBシステムに使用されるフォルト・ドメインを選択できます。選択したフォルト・ドメインにノードが割り当てられます。マルチノードRAC DBシステムの各ノードを別のフォルト・ドメインに配置することをお薦めします。
フォルト・ドメインの詳細は、リージョンおよび可用性ドメインを参照してください。
計画メンテナンスのためのDBシステム・ノードの再起動
DBシステム・ノードでは、定期的なメンテナンスが必要な基礎となる物理ホストが使用されます。そのようなメンテナンスが必要な場合、OCIはDBシステム・ノードの再起動をスケジュールし、再起動の予定をユーザーに通知します。再起動により、DBシステム・ノードをメンテナンスの必要のない新しい物理ホストに移行できます。(ノードを停止してから起動しても、結果として新しい物理ホストに移行されます。) DBシステム・ノードへの唯一の影響は、再起動そのもののみです。元の物理ハードウェアの計画的メンテナンスは、ノードがその新しいホストに移行された後に実行されて、DBシステムへの影響は発生しません。
DBシステム・ノードでメンテナンス再起動がスケジュールされている場合、コンソールまたはAPIを使用して、ノードを(停止してから起動することで)事前に再起動できます。これにより、ノードの停止時間が発生する方法と時期を制御できます。スケジュールされた時間よりも前に再起動しないことを選択した場合は、OCIによって、スケジュールされた時間にノードが再起動されて移行されます。
プロアクティブに再起動できるDBシステム・ノードを特定するには、コンソールでシステムの「DB Systemの詳細」ページに移動し、「ノード・メンテナンス再起動」フィールドを確認します。インスタンスのメンテナンス再起動がスケジュールされていて、それより前にそのインスタンスを再起動できる場合、このフィールドには再起動の日付と開始時間が表示されます。「メンテナンス再起動」フィールドに日付が表示されていない場合、DBシステムにはスケジュールされたノード・メンテナンス・イベントはありません。
APIを使用してスケジュール済メンテナンス・イベントをチェックするには、GetDbNode操作を使用して、DbNodeリソースのtimeMaintenanceWindowEndフィールドを確認します。このフィールドには、次回にスケジュールされているノード再起動がいつ起動されるかが指定されます。
メンテナンス再起動はスケジュールされているノードを見つけやすいために、検索サービスを事前定義済の問合せとともに使用して、メンテナンスリブートがスケジュールされているすべてのDBシステムを探します。
コンソールを使用してノードを再起動する手順については、DB Systemの再起動を参照してください。
DBシステムのセキュリティ強化ツール
Oracle Linux 7を使用してプロビジョニングされたDBシステムには、セキュリティ技術導入ガイド(STIG)ツールと呼ばれるPythonスクリプトが含まれており、これを使用してDBシステムのセキュリティ強化を行えます。
詳細は、次の各トピックを参照してください:
- Security Technical Implementation Guide (STIG) Tool for the DB System.
- Enable FIPS, SE Linux, and STIG on the DB System Components.
ブート・ボリューム・バックアップ
Oracleは、DBシステムの週次のブート・ボリューム・バックアップを保持して、重大なエラーまたはシステム障害が発生した場合にシステムを簡単にリストアできるようにします。現在、ユーザーがブート・ボリューム・バックアップにアクセスすることはできず(コンソール、APIまたはCLIにはDBシステムのブート・ボリューム・バックアップへのアクセス権がない)、Oracleがバックアップの保持およびメンテナンスのコストを負担します。システム障害が発生した場合は、My Oracle Supportに連絡して、Oracleにブート・ボリューム・バックアップからのDBシステムのリストアの実行を依頼してください。