DBシステムについて
Oracle Cloud Infrastructure (OCI)は仮想マシン上のDBシステムを提供します。
- 単一ノードDBシステム: 1ノードのDBシステムは、1つの仮想マシンで構成されます。
- マルチノードRAC DBシステム: 2ノードのDBシステムは、2つの仮想マシンで構成されます。
開発またはテスト目的でDBシステムをプロビジョニングする必要がある場合は、特別な高速プロビジョニング単一ノードDBシステムを使用できます。
- Oracle Database 19c: Oracle Databaseオファリングにより許可される機能、オプションおよび管理パック
ノート:
マルチノードのRAC DBシステムではシェイプ変更操作はローリング方式で実行されるため、データベースを停止することなくシェイプを変更できます。関連項目
使用可能なシェイプおよび割り当てられるリソースの決定方法
DBシステムを作成するときに、DBシステムに割り当てられるリソースを決定するシェイプを選択します。DBシステムを作成した後で、新しい処理能力の要件に合せてそのシェイプを変更できます。次のシェイプを使用できます:
フレキシブル・シェイプ
フレキシブル・シェイプを使用すると、コンピュート・リソース(インスタンスに割り当てられたECPUまたはOCPU)をカスタマイズできます。フレキシブル・シェイプを使用してインスタンスを作成する場合は、インスタンスで実行されるワークロードに必要なコンピュート・リソースを選択します。この柔軟性により、ワークロードに一致するインスタンスの構築できるため、パフォーマンスを最適化し、コストを最小限に抑えることができます。許可されるメモリー量は、選択したECPUまたはOCPUの数に基づいており、ECPUまたはOCPUに対するメモリーの比率はシェイプによって異なります。
フレキシブル・シェイプは、Ampere、AMDおよびIntelプロセッサで使用できます。次の表に、使用可能なシェイプを示します。
表- フレキシブル・シェイプ
| 形状 | Compute | Memory |
|---|---|---|
| 世代に依存しないVM.Standard.x86 |
最小は4 ECPU、最大は256 ECPUです。 4の増分である必要があります。 |
4 ECPUごとに8 GB。 |
| アンペアVM.Standard.A1。フレックス | 最小は1 OCPU、最大は57 OCPUです。 |
OCPUごとに8 GB。 合計メモリーの最小は8GB、最大は456GBです。 |
| AMD VM.Standard.E5。フレックス | 最小は1 OCPU、最大は64 OCPUです。 |
16 GB/OCPU。 合計メモリーの最小は16GB、最大は1024GBです。 |
| AMD VM.Standard.E4.Flex | 最小は1 OCPU、最大は64 OCPUです。 |
16 GB/OCPU。 合計メモリーの最小は16GB、最大は1024GBです。 |
| Intel X9 VM.Standard3.Flex | 最小は1 OCPU、最大は32 OCPUです。 |
16 GB/OCPU。 合計メモリーの最小は16GB、最大は512GBです。 |
ノート:
- ArmベースのAmpere A1シェイプは、23.7.0.0、19.19.0.0以降のリリース更新(RU)から始まるOracle Databaseバージョン23aiおよび19cでのみ使用できます。
- AMD E5シェイプは、Oracle Databaseバージョン23aiおよび19c (23.4.0.24.05、19.21.0.0以降のリリース更新(RU)からのみ使用できます。
- AMD E4シェイプは、Oracle Databaseバージョン23ai、21cおよび19cで、23.4.0.24.05、21.6.0.0、19.15.0.0およびそれ以降のリリース更新(RU)のみで使用できます。
- Intel X9シェイプは、Oracle Databaseバージョン23ai、21cおよび19c(23.4.0.24.05、21.8.0.0、19.17.0.0およびそれ以降のリリース更新(RU)のみで使用できます。
- マルチノードRAC DBシステムでは、ノード当たり少なくとも2つのOCPUが必要です。
世代に依存しないX86シェイプ
VM標準x86シェイプは、インスタンスに割り当てられるECPUの数をカスタマイズできる、最新世代に依存しない柔軟なシェイプです。次に、x86シェイプに関する追加の詳細を示します:
- X86シェイプでは、ECPUベースの請求が使用され、より詳細な使用量ベースの価格設定が可能になります。
- X86シェイプは、Oracle Database 23aiのみをサポートします。
- X86シェイプでは、次のOracle Databaseソフトウェア・エディションがサポートされます。
- Standard Edition
- Enterprise Edition
- Enterprise Edition - High Performance
- X86シェイプは、ストレージ管理用のLogical Volume Managerをサポートしています。
- X86シェイプは、単一ノードDBシステムをサポートします。
- X86シェイプはフォルト・ドメインをサポートしていません。
ArmベースのAmpere A1シェイプ
ArmベースのAmpere A1シェイプは柔軟性があり、インスタンスに割り当てられるOCPUの数をカスタマイズできます。次に、Ampere A1シェイプに関するその他の詳細を示します。
- Ampere A1シェイプは、Logical Volume Managerでのみサポートされています。
- Ampere A1シェイプは、単一ノードのDBシステムでのみサポートされます。
- Oracle Database Standard Editionは、Ampere A1シェイプベースのDBシステムではサポートされていません。
- データベース・ソフトウェア・イメージは、Ampere A1シェイプベースのDBシステムでのデータベースの作成には使用できません。
- データベースのバックアップ保存先がAutonomous Recovery Serviceの場合、Ampere A1シェイプベースのDBシステムのプロビジョニングおよびリストアはサポートされていません。
- OCIボールト暗号化を使用するデータベースでは、Ampere A1シェイプはサポートされていません。
- Ampere A1シェイプベースのDBシステムのシェイプは、IntelまたはAMDシェイプベースのDBシステムに変更できず、その逆も同様です。
- Ampere A1シェイプベース・データベースのバックアップは、IntelまたはAMDシェイプベースDBシステムにはリストアできません。その逆も同様です。
- Ampere A1シェイプベースのDBシステムでは、IntelまたはAMDシェイプベースのDBシステムとのData Guardアソシエーションはサポートされていません。
標準シェイプ
標準シェイプは、Intelプロセッサで使用できます。
次の表に、X7シリーズで使用可能なシェイプを示します。
表- VMで使用可能なシェイプX7シリーズ
| 形状 | CPUコア | Memory |
|---|---|---|
| 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 Databaseバージョン23ai、21cおよび19cでのみ使用できます。
- VM.Standard2.1シェイプは、マルチノードのRAC DBシステムには使用できません。
使用可能なデータベース・バージョン
OCIでは、古いデータベース・バージョンを使用したDBシステムの作成がサポートされています。各シェイプについて、リリースの最新バージョンとその前の2バージョンが、次の仕様でプロビジョニング時に使用できます。
- ArmベースのAmpere A1シェイプは、23.7.0.0、19.19.0.0以降のリリース更新(RU)から始まるOracle Databaseバージョン23aiおよび19cでのみ使用できます。
- AMD E5シェイプは、Oracle Databaseバージョン23aiおよび19c (23.4.0.24.05、19.21.0.0以降のリリース更新(RU)からのみ使用できます。
- AMD E4シェイプは、Oracle Databaseバージョン23ai、21cおよび19cで、23.4.0.24.05、21.6.0.0、19.15.0.0およびそれ以降のリリース更新(RU)のみで使用できます。
- Intel X9シェイプは、Oracle Databaseバージョン23ai、21cおよび19c(23.4.0.24.05、21.8.0.0、19.17.0.0およびそれ以降のリリース更新(RU)のみで使用できます。
- Intel X7シェイプは、Oracle Databaseバージョン23ai、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コア(フェニックス)、米国東部300コア(アッシュバーン)、ドイツ中央部50コア(フランクフルト)、英国南部50コア(ロンドン) | 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システムの詳細」ページに移動し、「ノード・メンテナンス再起動」フィールドを確認します。インスタンスのメンテナンス再起動がスケジュールされていて、それより前にそのインスタンスを再起動できる場合、このフィールドには再起動の日付と開始時間が表示されます。「メンテナンス再起動」フィールドに日付が表示されていない場合、DBシステムにはスケジュールされたノード・メンテナンス・イベントはありません。
APIを使用してスケジュール済メンテナンス・イベントをチェックするには、GetDbNode操作を使用して、DbNodeリソースのtimeMaintenanceWindowEndフィールドを確認します。このフィールドには、次のスケジュール済ノード再起動がいつ開始するかが指定されています。
メンテナンス再起動がスケジュール済であるノードを検索するには、検索サービスを事前定義済問合せとともに使用して、メンテナンス再起動がスケジュール済であるすべてのDBシステムを検索します。
コンソールを使用してノードを再起動する手順については、DB Systemの再起動を参照してください。
DBシステムのセキュリティ強化ツール
Oracle Linux 7を使用してプロビジョニングされたDBシステムには、セキュリティ技術導入ガイド(STIG)ツールと呼ばれるPythonスクリプトが含まれており、これを使用してDBシステムのセキュリティ強化を行えます。
ブート・ボリューム・バックアップ
Oracleは、DBシステムの週次のブート・ボリューム・バックアップを保持して、重大なエラーまたはシステム障害が発生した場合にシステムを簡単にリストアできるようにします。現在、ユーザーがブート・ボリューム・バックアップにアクセスすることはできず(コンソール、APIまたはCLIにはDBシステムのブート・ボリューム・バックアップへのアクセス権がない)、Oracleがバックアップの保持およびメンテナンスのコストを負担します。システム障害が発生した場合は、My Oracle Supportに連絡して、Oracleにブート・ボリューム・バックアップからのDBシステムのリストアの実行を依頼してください。