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システムに割り当てられるリソースを決定するshapeを選択します。 DBシステムを作成した後、そのシェイプを新しい処理能力要件に適応するように変更できます。 次のシェイプを使用できます:
フレキシブル・シェイプ
フレキシブル・シェイプを使用すると、コンピュート・リソース(インスタンスに割り当てられたECPUまたはOCPU)をカスタマイズできます。 フレキシブル・シェイプを使用してインスタンスを作成する場合、インスタンスで実行されるワークロードに必要なコンピュート・リソースを選択します。 この柔軟性により、ワークロードに一致するインスタンスを構築できるため、パフォーマンスを最適化し、コストを最小限に抑えることができます。 許可されるメモリー量は、選択したECPUまたはOCPUの数に基づいており、ECPUまたはOCPUに対するメモリーの比率はシェイプによって異なります。
Ampere、AMDおよびIntelプロセッサでは、柔軟なシェイプを使用できます。 次の表に、使用可能なシェイプを示します。
表 - フレキシブル・シェイプ
| シェイプ | Compute | メモリー |
|---|---|---|
| 世代に依存しないVM.Standard.x86 |
最小は4 ECPU、最大は256 ECPUです。 4の増分である必要があります。 |
4 ECPUごとに8 GB。 |
| Ampere VM.Standard.A1.Flex | 最小は1 OCPUで、最大は57 OCPUです。 |
8 GB/OCPU。 最小値は8 GBで、最大値は合計メモリー456 GBです。 |
| AMD VM.Standard.E5.Flex | 最小は1 OCPUで、最大は64 OCPUです。 |
16 GB/OCPU。 最小は16 GBで、最大は合計メモリー1024 GBです。 |
| AMD VM.Standard.E4.Flex | 最小は1 OCPUで、最大は64 OCPUです。 |
16 GB/OCPU。 最小は16 GBで、最大は合計メモリー1024 GBです。 |
| Intel X9 VM.Standard3.Flex | 最小は1 OCPUで、最大は32 OCPUです。 |
16 GB/OCPU。 最小は16 GBで、最大は合計メモリー512 GBです。 |
ノート:
- ArmベースのAmpere A1シェイプは、23.7.0.0、19.19.0.0およびそれ以降のリリース更新(RU)から始まるOracle Databaseバージョン26aiおよび19cでのみ使用できます。
- AMD E5シェイプは、23.4.0.24.05、19.21.0.0およびそれ以降のリリース更新(RU)以降のOracle Databaseバージョン26aiおよび19cでのみ使用できます。
- AMD E4シェイプは、Oracle Databaseバージョン26ai、21cおよび19c (23.4.0.24.05、21.6.0.0、19.15.0.0以降のリリース更新(RU)のみ)で使用できます。
- Intel X9シェイプは、23.4.0.24.05、21.8.0.0、19.17.0.0およびそれ以降のリリース更新(RU)を使用するOracle Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- マルチ・ノードRAC DBシステムには、ノード当たり2つ以上のOCPUが必要です。
世代に依存しないX86シェイプ
VM標準x86シェイプは、インスタンスに割り当てられるECPUの数をカスタマイズできる、最新世代に依存しない柔軟なシェイプです。 次に、x86シェイプに関する追加の詳細を示します:
- X86シェイプでは、ECPUベースの請求が使用され、より詳細な使用量ベースの価格設定が可能になります。
- X86シェイプは、Oracle Databaseバージョン26aiのみをサポートしています。
- 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システムでのみサポートされています。
- Ampere A1シェイプ・ベースのDBシステムでは、Oracle Database Standard Editionはサポートされていません。
- データベース・ソフトウェア・イメージは、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関連付けはサポートされていません。
標準シェイプ
Standardシェイプは、Intelプロセッサで使用できます。
次の表に、X7シリーズで使用可能なシェイプを示します。
表 - VM使用可能なシェイプX7シリーズ
| シェイプ | CPUコア | メモリー |
|---|---|---|
| VM.Standard2.1 | 1 | 15 GB |
| VM.Standard2.2 | 2 | 30 GB |
| VM.Standard2.4 | 4 | 60 GB |
| VM.Standard2.8 | 8 | 120 GB |
| VM.Standard2.16 | 16 | 240 GB |
| VM.Standard2.24 | 24 | 320 GB |
ノート:
- Intel X7シェイプは、Oracle Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- VM.Standard 2.1シェイプは、マルチ・ノードのRAC DBシステムには使用できません。
使用可能なデータベース・バージョン
OCIでは、古いデータベース・バージョンを使用したDBシステムの作成がサポートされています。 各シェイプについて、最新バージョンとリリースの2つ前のバージョンが、次の仕様でプロビジョニング時に使用可能になります。
- ArmベースのAmpere A1シェイプは、23.7.0.0、19.19.0.0およびそれ以降のリリース更新(RU)から始まるOracle Databaseバージョン26aiおよび19cでのみ使用できます。
- AMD E5シェイプは、23.4.0.24.05、19.21.0.0およびそれ以降のリリース更新(RU)以降のOracle Databaseバージョン26aiおよび19cでのみ使用できます。
- AMD E4シェイプは、Oracle Databaseバージョン26ai、21cおよび19c (23.4.0.24.05、21.6.0.0、19.15.0.0以降のリリース更新(RU)のみ)で使用できます。
- Intel X9シェイプは、23.4.0.24.05、21.8.0.0、19.17.0.0およびそれ以降のリリース更新(RU)を使用するOracle Databaseバージョン26ai、21cおよび19cでのみ使用できます。
- Intel X7シェイプは、Oracle 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ブロック・ストレージが使用されます。 次の表に、使用可能なストレージ・オプションの詳細を示します。 合計ストレージには、使用可能なストレージとリカバリ・ログが含まれます。
一般情報
- データ・ストレージとリカバリ・ストレージは個別にスケーリングできます。 Oracleでは、合計ストレージの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ユニバーサル・クレジット | 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システムに使用するフォルト・ドメインを選択すると、選択したフォルト・ドメインにノードが割り当てられます。 Oracleでは、マルチ・ノードRAC DBシステムの各ノードを異なるフォルト・ドメインに配置することをお薦めします。
フォルト・ドメインの詳細は、「リージョンと可用性ドメイン」を参照してください。
計画メンテナンスのためのDB Systemノードの再起動
DBシステム・ノードでは、定期的なメンテナンスが必要な、基礎となる物理ホストが使用されます。 このようなメンテナンスが必要な場合は、OCIによってDBシステム・ノードの再起動がスケジュールされ、再起動の予定がユーザーに通知されます。 この再起動によって、DBシステム・ノードをメンテナンスを必要としない新しい物理ホストに移行できます。 (ノードを停止して起動すると、新しい物理ホストへの移行も行われます。) DBシステム・ノードへの影響は、再起動そのもののみです。 元の物理ハードウェアの計画メンテナンスは、ご使用のノードが新しいホストに移行された後に実行され、DBシステムには影響しません。
DBシステム・ノードでメンテナンス再起動がスケジュールされている場合、コンソールまたはAPIを使用すると、それよりも前にノードを再起動できます(停止して起動します)。 これにより、ノードのダウンタイムが発生する方法と時期を制御できます。 スケジュールされた時間よりも前に再起動しないように選択した場合は、OCIによって、スケジュールされた時間にノードが再起動されて移行されます。
先回りして再起動できるDBシステム・ノードを識別するには、コンソールでシステムの「DBシステム詳細」ページに移動し、「ノード・メンテナンス再起動」フィールドを確認します。 インスタンスにメンテナンス再起動がスケジュールされており、事前に再起動できる場合、このフィールドにはリブートの日時が表示されます。 「メンテナンス再起動」フィールドに日付が表示されない場合、DBシステムにはノード・メンテナンス・イベントがスケジュールされていません。
APIを使用してスケジュールされたメンテナンス・イベントを確認するには、GetDbNode操作を使用して、DbNodeリソースのtimeMaintenanceWindowEndフィールドを確認します。 このフィールドには、次のスケジュール済ノード再起動がいつ開始するかが指定されています。
メンテナンス再起動がスケジュールされているノードを検索するには、「検索サービス」を事前定義済問合せとともに使用して、メンテナンス再起動がスケジュールされているすべてのDBシステムを検索できます。
コンソールを使用してノードを再起動する手順については、「DB Systemのリブート」を参照してください。
DBシステムのセキュリティ強化ツール
Oracle Linux 7を使用してプロビジョニングされたDBシステムには、DBシステムのセキュリティ強化を実行するために使用できる、セキュリティ技術実装ガイド(STIG)ツールと呼ばれるPythonスクリプトが含まれます。
ブート・ボリューム・バックアップ
Oracleでは、重大なエラーやシステム障害の発生時にシステムを簡単にリストアできるように、DBシステムの週次ブート・ボリューム・バックアップを保持しています。 現在、ブート・ボリュームのバックアップはユーザーにアクセスできません(DBシステム・ブート・ボリュームのバックアップへのコンソール、APIまたはCLIアクセスはありません)。Oracleでは、バックアップの保存とメンテナンスにかかるコストがかかります。 システム障害が発生した場合は、My Oracle Supportに連絡して、Oracleがブート・ボリューム・バックアップからDBシステムのリストアを実行するようにリクエストします。