仮想マシン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システムの作成後、新しい処理能力の要件に合せてシェイプを変更できます。次のシェイプを使用できます:
フレキシブル・シェイプ
フレキシブル・シェイプを使用すると、インスタンスに割り当てられるOCPUの数をカスタマイズできます。フレックス・シェイプを使用してインスタンスを作成する場合、インスタンスで実行するワークロードに必要なOCPU数を選択します。この柔軟性により、ワークロードに一致するインスタンスを構築できるため、パフォーマンスの最適化およびコストの最小化が可能になります。使用可能なメモリー容量は選択したOCPUの数に基づいており、メモリーとOCPUの比率はシェイプによって異なります。
Ampere、AMDおよびIntelプロセッサでは、柔軟なシェイプを利用できます。次の表に、使用可能なシェイプを示します。
表1-2 フレキシブル・シェイプ
| シェイプ | CPUコア | メモリー | ネットワーク帯域幅 |
|---|---|---|---|
| アンペア VM.Standard.A1.Flex | 最小は1 OCPUで、最大は57 OCPUです。 |
8 GB/OCPU。 最小は8 GBで、最大は456 GBの合計メモリーです。 |
1Gbps/OCPU。 ネットワーク帯域幅の最小は1Gbps、最大は40Gbpsです。 |
| AMD VM.Standard.E4.Flex | 最小は1 OCPU、最大は64 OCPUです。 |
16GB/OCPU。 合計メモリーの最小は16GB、最大は1024GBです。 |
1Gbps/OCPU。 最小は1Gbps、最大は40Gbpsのネットワーク帯域幅です。 |
| Intel X9 VM.Standard3.Flex | 最小は1 OCPUで、最大は32 OCPUです。 |
16GB/OCPU。 合計メモリーの最小は16GB、最大は512GBです。 |
1Gbps/OCPU。 ネットワーク帯域幅の最小は1Gbps、最大は32Gbpsです。 |
- ArmベースのAmpere VM.Standard.A1。フレックス・シェイプは、19.19.0.0以降のリリース更新(RU)でのみ、Oracle Databaseバージョン19cで使用できます。
- AMD VM.Standard.E4。フレックス・シェイプは、Oracle Databaseバージョン23c、21cおよび19cの23.3.0、21.6.0.0、19.15.0.0以降のリリース更新(RU)でのみ使用できます。
- Intel X9 VM.Standard3。フレックス・シェイプは、Oracle Databaseバージョン23c、21cおよび19cの23.3.0、21.8.0.0、19.17.0.0以降のリリース更新(RU)でのみ使用できます。
- マルチノードRAC DBシステムには、ノード当たり2つ以上のOCPUが必要です。
Armベースのアンペア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システムのプロビジョニングおよびリストアはサポートされていません。
- AmpereのA1シェイプは、OCIボールト暗号化を使用するデータベースではサポートされていません。
- Ampere A1シェイプベースのDBシステムのシェイプは、IntelまたはAMDシェイプベースのDBシステム(またはその逆)に変更できません。
- Ampere A1シェイプベースのデータベースのバックアップは、IntelまたはAMDシェイプベースのDBシステム(またはその逆)にリストアできません。
- Ampere A1シェイプベースのDBシステムでは、IntelまたはAMDシェイプベースのDBシステムとのData Guardアソシエーションはサポートされていません。
標準シェイプ
標準シェイプは、Intelプロセッサで使用できます。
次の表に、X7シリーズで使用可能なシェイプを示します。
表1-3 X7シリーズで使用可能なVMシェイプ
| シェイプ | 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 Databaseバージョン23c、21cおよび19cでのみ使用できます。
- VM.Standard2.1シェイプは、マルチノードのRAC DBシステムには使用できません。
使用可能なデータベース・バージョン
OCIでは、古いデータベース・バージョンを使用したDBシステムの作成がサポートされています。各シェイプについて、リリースの最新バージョンとその前の2バージョンが、次の仕様でプロビジョニング時に使用できます。
- ArmベースのAmpere VM.Standard.A1。フレックス・シェイプは、19.19.0.0以降のリリース更新(RU)でのみ、Oracle Databaseバージョン19cで使用できます。
- Intel X9 VM.Standard3。フレックス・シェイプは、Oracle Databaseバージョン23c、21cおよび19cの23.3.0、21.8.0.0、19.17.0.0以降のリリース更新(RU)でのみ使用できます。
- AMD VM.Standard.E4。フレックス・シェイプは、Oracle Databaseバージョン23c、21cおよび19cの23.3.0、21.6.0.0、19.15.0.0以降のリリース更新(RU)でのみ使用できます。
- Intel X7シェイプは、Oracle Databaseバージョン23c、21cおよび19cでのみ使用できます。
- X9への移行は、21.8.0.0、19.17.0.0以降のリリース更新のベース・イメージを使用しているインスタンスでのみサポートされます。これらのリリース更新前に作成されたインスタンスでは、ベース・イメージ自体が移行をサポートしていないため、更新および移行できません。
- AMDへの移行は、21.6.0.0、19.15.0.0以降のリリース更新のベース・イメージを使用しているインスタンスでのみサポートされます。これらのリリース更新前に作成されたインスタンスでは、ベース・イメージ自体が移行をサポートしていないため、更新および移行できません。
古いデータベース・バージョンを使用してDBシステムを作成する必要がある場合、選択したデータベース・バージョンでの既知のセキュリティ問題の詳細は、クリティカル・パッチ・アップデートを参照してください。また、古いデータベース・バージョンに含まれているオペレーティング・システムの既知のセキュリティ問題を分析してパッチ適用する必要もあります。OCIのデータベースに対するセキュリティのベスト・プラクティスの詳細は、データベースの保護を参照してください。
様々な構成が使用可能なストレージに与える影響
DBシステムではOCIブロック・ストレージが使用されます。次の表に、使用可能なストレージ・オプションの詳細を示します。合計ストレージには、使用可能なストレージとリカバリ・ログが含まれます。
一般情報
- データ・ストレージとリカバリ・ストレージは個別にスケーリングできます。リカバリ・ストレージを常に合計ストレージの20%以上にしておくことをお薦めします。
- マルチノードのRAC DBシステムの場合、ストレージ容量はノード間で共有されます。
- リカバリ領域ストレージは、選択したストレージに基づいて決定されます。ただし、プロビジョニング後にリカバリ領域ストレージを個別に変更できます。
フレキシブル・シェイプに使用可能なデータ・ストレージ
表1-4 フレキシブル・シェイプに使用可能なデータ・ストレージ
| 使用可能なデータ・ストレージ(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 |
標準シェイプに使用可能なデータ・ストレージ
表1-5 標準シェイプに使用可能なデータ・ストレージ
| 使用可能なデータ・ストレージ(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 |
高速プロビジョニング・オプション
単一ノードDBシステムの場合、OCIには高速プロビジョニング・オプションが用意されており、Logical Volume Manager (LVM)をストレージ管理ソフトウェアとして使用してDBシステムを作成できます。標準的な方法(標準プロビジョニング)は、自動ストレージ管理(ASM)を使用してプロビジョニングすることです。
高速プロビジョニング・オプションには、次の詳細が適用されます:
- 高速プロビジョニング・オプションを使用する場合、プロビジョニング中に指定したブロック・ボリュームの数とサイズによって、スケーリングで使用可能な最大合計ストレージが決まります。
- マルチノードのRAC DBシステムにはASMが必要で、高速プロビジョニング・オプションを使用して作成することはできません。
- 高速プロビジョニング・オプションを使用して作成されたDBシステムをクローニングできます。
- LVMを使用してDBシステムをプロビジョニングする場合、カスタム・データベース・ソフトウェア・イメージは使用できません。
高速プロビジョニングの使用時のストレージのスケーリングの考慮事項
このトピックは、単一ノードDBシステムにのみ適用されます。
高速プロビジョニング・オプションを使用してDBシステムをプロビジョニングする場合、プロビジョニング中に指定した「使用可能ストレージ(GB)」の値によって、スケーリングで使用可能な最大合計ストレージが決まります。次の表では、プロビジョニング・ワークフローで提供される設定ごとに、スケーリングで使用可能な最大ストレージ値を示します:
表1-6 高速プロビジョニングの使用時のストレージのスケーリングの考慮事項
| プロビジョニング中に指定した初期ストレージ(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システムのリストアの実行を依頼してください。