FAQ

Oracle Database Cloud Serviceとは何ですか。

Oracle Database Cloud ServiceではOracleデータベースをクラウド内で簡単に構築、スケーリングおよび保全することができます。データベースはDBシステム上に作成します。これは、(ローカルNVMeフラッシュまたはSSDストレージを備えた)ベア・メタル・サーバーか、ブロック・ボリュームを備えた仮想マシンのどちらかです。どちらの場合も、高パフォーマンスでコスト効率のよい価格が実現します。また、このサービスにより、仮想クラウド・ネットワーク・レイヤーでの仮想マシン・サーバーへの「クラウドファースト」なOracle RAC実装のサポートが可能になります。

データベースは、パッチ適用、Data Guard、バックアップ/リカバリなどの簡略化されたツールを使用して管理できます。これらのツールにはすべて、Oracle Cloud Infrastructure REST APIまたはコンソールを使用してアクセスできます。あるいは、データベース・ホストにアクセスし、既存のツールを使用して、クラウド内のデータベースをオンプレミスで管理する場合と同様の方法で管理することもできます。

Oracle Database Cloud Serviceではどの機能が提供されますか。

Oracle Database Cloud Serviceは高パフォーマンスなベア・メタル・サーバーまたは仮想マシン上でリクエストされたコア数をDBシステムにプロビジョニングして、選択したエディションのOracle Databaseソフトウェアをデプロイし、DBシステムを仮想クラウド・ネットワーク(VCN)内で作成します。VCNはユーザー構成済のセキュリティ・リストを備えるプライベート・ネットワークで、DBシステムを不正なアクセスから保護します。

また、Oracle Database Cloud Serviceは、データベース・サービス・パッチ適用、Oracle Data Guardやバックアップ/リストアを使用した高可用性の構成など、管理を容易にする機能を提供しています。これにより、Oracleデータベースの実行に必要な日常的なタスクを簡略化できます。

最初のデータベースはどのように作成できますか。

Oracle Cloud Infrastructureアカウントを作成した後は、コンソールREST APICLIおよびSDKを使用して、Database Cloud Service上にOracleデータベースを作成できます。

使用するリソースについてどのように支払をするのですか。

ベア・メタル・サーバーと仮想マシンのいずれも、OracleのUniversal Creditモデルをサポートしており、「ライセンス組込み」と「ライセンス持込み(Bring Your Own License)」の価格設定が可能です。価格設定は柔軟で、pay as you goオプションと、オラクルの営業担当が提供する割引コミット価格の両方から選べます。価格は、選択したデータベース・エディション、データベース・シェイプ、および選択したコア数に応じて決まります。

お客様はshop.oracle.comでアカウントを作成することで、Oracle Database Cloud Serviceデータベース・インスタンスを利用できます。また、すでに利用中のお客様は営業担当者に連絡して、アカウントを作成し、既存のクレジット・プールを有効にするか新しいプールを購入することで、Oracle Cloud Infrastructureリソースを使用できます。詳細は、データベースの価格に関する項を参照してください。

既存の従量制/非従量制テナンシについては、Universal Creditモデル・テナンシに変換されるまで、既存の計画に基づいて請求が行われます。

どのバージョンのOracle Databaseソフトウェアがサポートされていますか。

現在、Oracle Database Cloud ServiceではOracle Databaseのバージョン11.2.0.4、12.1.0.2、12.2.0.1および18.1.0.0がサポートされています。

どのエディションのOracle Databaseソフトウェアがサポートされていますか。

次のOracle Databaseソフトウェア・エディションがサポートされ、クラウド用に最適化されています。

  • Standard Edition
  • Enterprise Edition
  • Enterprise Edition High Performance
  • Enterprise Edition Extreme Performance

Oracle Databaseの各ソフトウェア・エディションではどのデータベース・オプションを使用できますか。

各エディションで使用可能なデータベース・オプションを次のリストに示します。すべてのパッケージにはOracle Database Transparent Data Encryption (TDE)が含まれることに注意してください。

Database Edition データベース・オプション
Standard Edition Oracle Database Standard Edition Packageが含まれます。
Enterprise Edition Oracle Database Enterprise Edition Package、Data Masking and Subsetting Pack、Diagnostics and Tuning Packs、およびReal Application Testingが含まれます。
Enterprise Edition High Performance 次のオプションでEnterprise Packageを拡張したものです: Multitenant、Partitioning、Advanced Compression、Advanced Security、Label Security、Database Vault、OLAP、Advanced Analytics、Spatial & Graph、Database Lifecycle Management Pack、Cloud Management Pack for Oracle Database。
Enterprise Edition Extreme Performance 次のオプションでHigh Performance Packageを拡張したものです: Real Application Clusters (RAC)、In-Memory Database、Active Data Guard。

DBシステムの起動時にどのシェイプ(ストレージおよびCPU構成)を使用できますか。

ベア・メタル・シェイプ
クリティカルなエンタープライズ・アプリケーションのパフォーマンス要件は非常に高く、これを満たすために、Oracle Database Cloud Serviceは3つのベア・メタル・シェイプをサポートしています。これにより、1つのデータベースで200,000を超えるTPSまたはIOPSを達成可能です。Bare Metal DBシステムでは、最大パフォーマンスを実現するために、ローカルにアタッチされたNVMeまたはSSDストレージが使用されます。ストレージの容量は、DBシステムの起動時に指定されたシェイプによって決まります。

ベア・メタル・シェイプ コア/OCPU メモリー ストレージ・タイプ RAWストレージ ストレージ(双方向ミラーリング) ストレージ(3方向ミラーリング)
BM.HighIO1.36* 2 – 36 512GB NVMe 12.8TB 3.5TB 2.3TB
BM.DenseIO1.36 2 – 36 512GB NVMe 28.8TB 9.4TB 5.4TB
BM.DenseIO2.52 2 – 52 768GB NVMe 51.2TB 16TB 9TB
BM.RACLocalStorage1.72*
(2つの物理ノードで構成される)
2 – 36/ノード 512GB/ノード SSD 64TB 22.1TB 14TB

High IO & Dense IOシェイプでStandard Editionを使用する場合、許容される最大OCPUはインスタンス当たり8のOCPUです。

*BM.HighIO1.36およびBM.RACLocalStorage1.72*シェイプは利用できなくなりました。ただし、既存のお客様へのサポートは継続されます。

仮想マシン・シェイプ
Oracle Database Cloudでは、標準のVMコンピュート・シェイプに基づいた様々な仮想マシンをサポートしています。VMシェイプの選択により、1コアから24コアまで、256GBから40TBまでのスケーラブルで耐久性のあるリモート・ストレージを選択でき、コスト効率および柔軟性を実現できます。

VMシェイプ コア/OCPU メモリー ストレージ(ブロックのみ) ネットワーク帯域幅
VM.Standard.1.1 1 7GB 256GB - 40TB 最大600Mbps
VM.Standard.1.2 2 14GB 256GB - 40TB 最大1.2Gbps
VM.Standard.1.4 4 28GB 256GB - 40TB 1.2Gbps
VM.Standard.1.8 8 56GB 256GB - 40TB 2.4Gbps
VM.Standard.1.16 16 112GB 256GB - 40TB 4.8Gbps
VM.Standard.2.1 1 15GB 256GB - 40TB 1Gbe
VM.Standard.2.2 2 30GB 256GB - 40TB 2Gbe
VM.Standard.2.4 4 60GB 256GB - 40TB 4Gbe
VM.Standard.2.8 8 120GB 256GB - 40TB 8Gbe
VM.Standard.2.16 16 240GB 256GB - 40TB 16Gbe
VM.Standard.2.24 24 320GB 256GB - 40TB 25Gbe

注意: 2コア以上のシェイプはいずれも、「ノードの合計数」を2と指定してRAC構成を取得できます。Standard Editionを使用する場合、許容される最大シェイプはVM.Standard1.8です。

DBシステムとは何ですか。

DBシステムは、Oracle Databaseソフトウェアがデプロイされたベア・メタル・サーバーまたは仮想マシンであり、ユーザーが指定したコア数、ソフトウェア・エディションおよびデータベース・バージョンで構成されます。

1つのDBシステム内に複数のデータベースを作成できますか。

はい。1つのベア・メタルDBシステムに複数のDB Homeを設定し、その中に複数のデータベースを持たせることができます。1つのDB Home内のデータベースはすべて同じバージョンですが、各DB Homeは異なるバージョンが可能です。たとえば、1つのEnterprise Edition DBシステムに、Enterprise Edition 11.2.0.4データベースのみが含まれるDB_Home11と、Enterprise Edition 12.1.0.2データベースのみが含まれるDB_Home12が存在する場合があります。ただし、仮想マシンDBシステムはシングル・データベース・インスタンスであることに注意してください。

DBシステムを起動した後でデータベース・エディションを変更できますか。

いいえ、エディションは変更できません。ただし、DBシステムを終了して、他のエディションでもう1つ起動することは容易です。

DBシステムを起動した後でデータベース・キャラクタ・セットを変更できますか。

DBシステムを起動すると、システム上に作成される初期データベースはデフォルトのキャラクタ・セットAL32UTF8とAL16UTF16を使用します。ただし、起動時にデータベースの詳細オプションで、別のキャラクタ・セットを容易に選択できます。

Oracle Database Cloud Serviceで独自のライセンスを使用(BYOL)できますか。

はい。独自のライセンスを使用できます(Bring Your Own License)。Oracle Database Cloud Serviceでは、ライセンス組込みとBYOLの両方の価格モデルをサポートしています。

DBシステムの監視にはどのベスト・プラクティスが推奨されますか。

データベースの監視ニーズにはEnterprise Managerを使用することを強くお薦めします。すぐに、Database Serviceから直接メトリックを返すためのサポートを追加する予定です。

アカウントに作成できるDBシステム数の制限について教えてください。

各インスタンス・タイプのデフォルト制限と、サービス制限拡大のリクエスト方法については、サービス制限のドキュメントを参照してください。必要に応じて、アカウント制限の数を増やすことは可能です。

Oracle RACはOracle Database Cloud Serviceでサポートされていますか。

はい。Oracle Database Cloud Serviceは仮想クラウド・ネットワーク内の仮想マシン上で「クラウドファースト」のOracle RACをサポートしています。

仮想マシン上のOracle RACは、DBシステムの起動中に「ノードの合計数」を2に設定することにより構成できます。

仮想マシン

仮想マシン(VM)上のOracle Cloud Infrastructure Database Serviceとは何ですか。

VM上のDatabase Serviceは、お客様が仮想マシン上であらゆる機能を備えたOracleデータベースを構築、スケーリングおよび管理できるようにするデータベース・サービス製品です。VM上でデータベースを実行する場合の大きなメリットは、コスト効率がよいこと、すぐに開始できること、ストレージの耐久性とスケーラビリティに優れていること、およびReal Application Clusters (RAC)を実行して可用性を高められることです。

RACデータベースは1つのアベイラビリティ・ドメイン(AD)内で実行されますが、各ノードは別々の物理ラックに存在するため、高可用性を実現できます。VM上のDatabase Cloud Serviceは、すべてのOracle Cloud Infrastructureサービスで使用される高パフォーマンスで高可用性のクラウド・インフラストラクチャを基盤としています。

VM上のDatabase Serviceのメリットは何ですか。

VM上のDatabase Serviceには、低コスト、柔軟なストレージなど、様々なメリットがあります。具体的には、

  • コスト効率と柔軟性が高い - 1OCPUのVMから始めて、最大24OCPUにまで拡張できます。使用したOCPUとストレージの分だけ支払います。
  • すぐに開始できる - データベース・エディションを選択して、Oracleで動作保証されたあらゆる機能を備えた完全サポート対象の11g、12c (12.1と12.2の両方)データベースを簡単に作成できます。
  • 組込みの高可用性コンストラクト - すべてのVMシェイプを使用した2ノードRAC構成を簡単にデプロイできます。例: 2コアの仮想マシンおよび最大40TBの共有ブロック・ストレージを使用する、2ノードRAC構成を簡単にデプロイできます。
  • 耐久性のあるスケーラブルなストレージ - 256GBから40TBまでのリモート・ストレージを使用できます。ストレージは、停止することなくスケールアップできます。
  • セキュア - 管理コントロール用のOracle IAMと、データベース環境を保護するためのVCNセキュリティ・リストのすべてのメリットを享受できます。

VM上のDatabase ServiceではすべてのRACデータベースがサポートされますか。

はい。VM上のDatabase Cloud Serviceでは、RAC (Real Application Cluster)データベースが2ノードRAC構成としてサポートされています。2ノードRACを有効にするには、VMデータベースの設定時にノードを2として選択します。RACデータベースはEnterprise Edition Extreme Performanceでのみサポートされます。VM当たりの最小コア数は2です。

最初の作成後にVMシェイプ内でDBシステムに関連付けられたコア数を変更できますか。

いいえ。現在、作成後にDBシステムで使用されるコア数を変更することはできません。

VM上の1つのデータベース内に複数のDB Homeを作成できますか。

いいえ。現在、1つのVMデータベース内に複数のDB Homeを作成することはできません。各VMデータベース・インスタンスで起動できるのは、インスタンス当たり1つのデータベースのみです。

VM内で実行されているデータベース・サービスで使用可能なストレージをスケーリングするには、どうすればいいですか。

DBシステムのストレージは、コンソールREST APICLIおよびSDKを使用すると簡単にスケールアップできます。VM上のDatabase Cloud Serviceではリモート・ブロック・ストレージが使用されるため、256GBから40TBまでの範囲で使用可能なストレージを構成できます。ストレージのスケールアップは、停止せずに実行できます。注意: インスタンスにアタッチされる合計ストレージは、使用可能なストレージ、RECOストレージおよびソフトウェア・サイズの合計になります。使用可能なストレージはお客様が選択します。RECOストレージは、使用可能なストレージに基づいて自動的に計算されます。ソフトウェア・サイズは固定サイズのOracleデータベース・コストです。

請求

Oracle Database Cloud Serviceの使用量の測定と請求はどのように行われますか。

Oracle Cloud Infrastructureでは、OracleのUniversal Creditモデルをサポートしています。ライセンス組込みとライセンス持込み(Bring Your Own License)の価格設定が可能です。価格設定は柔軟で、pay as you goと、オラクルの営業担当が提供する割引コミット価格の両方から選べます。Oracle Databaseは、次の使用量要素に基づいて課金されます。

  • ホストされる環境/時間 - ホストされる環境は、基本CPU性能、ローカル・ストレージ(ベア・メタルのみ)、選択したエディションで有効化されたOCPUを含む、DBシステムの基本インスタンスとして定義されます。部分的に消費されたホストされる環境時間は、1時間として課金されます。
  • OCPU/時間 - ホストされる環境またはDBシステムごとに、追加のOCPUを有効にできます。部分的に消費されたOCPU時間は、1時間として課金されます。
  • ブロック・ボリューム - VM上のDatabase Serviceでは、リモート・ブロック・ボリュームが使用されます。256GBから40TBまでの範囲のストレージをアタッチでき、支払いは合計ストレージの分だけです。これは、使用可能なストレージ、RECOストレージおよびソフトウェア・サイズの合計になります。使用可能なストレージはお客様が選択します。RECOストレージは、使用可能なストレージに基づいて自動的に計算されます。ソフトウェア・サイズは固定サイズのOracleデータベース・コストです。詳細は、Storageの価格を参照してください。
  • オブジェクト・ストレージ - 自動増分バックアップ、オンデマンド完全バックアップ、およびオンプレミスからクラウドへのバックアップは、Oracle Cloud Infrastructure Object Storageに格納され、お客様には標準オブジェクト・ストレージ・コストが課金されます。詳細は、Storageの価格を参照してください。

Oracle Database Cloud Serviceの価格設定モデルについて教えてください。

詳細は、データベースの価格に関する項を参照してください。

DB Systemのコア時間当たりの課金とは何ですか。

Oracle Database Cloud Serviceはオンデマンドであり柔軟性があるため、使用量に対してのみ課金されます。1時間に切り上げられて課金されます。たとえば、あるインスタンスを終了するまで45分実行した場合、1時間課金されます。

データベースのバックアップを作成するコストについて教えてください。

Oracle Cloud Infrastructure Object Storageへのデータベース・バックアップを構成するには、バックアップ/リストア機能を使用するか、RMANを使用できます。バックアップのコストは、使用中のオブジェクト・ストレージの合計額であり、オブジェクト・ストレージ価格設定に準拠します。

Data Guardを使用して可用性の高いデータベースを設定する場合の課金について教えてください。

別個のアベイラビリティ・ドメインにデプロイされた2つのDB SystemでData Guardを設定すると、可用性の高いデータベースが構成されます。各DB Systemの価格は、データベースの価格設定に示されている標準価格モデルに準拠します。

Oracle Database Cloud Serviceは課金停止に対応していますか。

はい。Oracle Database Cloud Serviceでは仮想マシン・データベースの課金停止に対応しています。この機能を利用するには、仮想マシン・データベース・システムに移動して、停止するノードを選択します。ノードが停止されてもデータベースはそのまま維持されます。ノードが稼働していない時間は課金されません。部分的に消費された時間は、その時間中にデータベース・システムによって使用されたOCPUの最大数に対して課金されます。

Bare Metal Dense I/OまたはExadata DBシステムに課金停止は適用されません。ホストされる環境全体が引き続き維持されるため、ノードを停止した後も課金は継続します。Bare Metal Dense I/OまたはExadataシェイプのコストを削減するには、データベース・シェイプのオンラインCPUスケーリング機能を使用して、未使用または使用量の少ない環境のOCPUを2 (DenseIOの場合)または22 (Exadata Qtr Rackの場合)に減らします。

セキュリティ

Oracle Virtual Cloud Network (VCN)とは何ですか。なぜDBシステムはデフォルトでVCNにデプロイされるのですか。

VCNはOracle Cloud Infrastructureのカスタマイズ可能なプライベート・ネットワークです。従来のデータ・センター・ネットワークと同様に、VCNではネットワーク環境を完全に制御できます。これには独自のプライベートIPアドレス領域の割当て、サブネットの作成、ルート表の作成、およびステートフル・ファイアウォールの構成が含まれます。単一のテナントが複数のVCNを保有できるため、関連リソースのグループ化と分離が可能です。

デフォルトでVCNにデプロイすることで、セキュリティを確保し、次の柔軟性を得ることができます。

  • データベースをインターネットから保護されたプライベート・ネットワークにデプロイ。
  • セキュリティ・リスト(インバウンド/アウトバウンド)を構成して、悪意のあるユーザーのDB Systemへのアクセスを防止。

デプロイメント中、どのサブネットにDB Systemを配置すればよいですか。

アベイラビリティ・ドメインごとに別個のサブネットを作成し、それらのサブネットにDB Systemを配置することを強くお薦めします。これにより、サブネットに詳細なインバウンド/アウトバウンド・セキュリティ・リストを定義して、ネットワーク・アクセスを制御できます。

データベースにTDEを設定する方法について教えてください。

プロビジョニング中、DB SystemにはデフォルトでTDEが構成されます。DB Systemにログインして他のセキュリティ・ポリシーを制御する柔軟性も備えられています。標準のデータベース・セキュリティのベスト・プラクティスに従うことができます。

管理アクセスを制御してDBシステムを保護する方法について教えてください。

Oracle Cloud InfrastructureのIdentity and Access Management (IAM)では、セキュリティおよびコンプライアンス要件をサポートするようにクラウド環境を構成できます。データベースの観点から、ベア・メタルおよび仮想マシンDB Systemへのアクセスを管理の観点から選択したユーザー・セット(DBA)のみに制限できるIAMポリシーを構成します。Oracle Database Cloud ServiceでOracle IAMを使用する方法については、テクニカル・ドキュメンテーションを参照してください。

DB Systemで実行された操作は監査できますか。

はい。DB Systemへのフル・ルート・アクセスを使用して、DB System上のすべての操作の監査を構成できます。Oracle Database Cloud Serviceは、データベースのすべてのエディションで堅牢な監査をサポートしています。監査レコードには、監査した操作、操作を実行しているユーザー、操作の日時に関する情報が含まれます。監査レコードは、データベース監査証跡またはオペレーティング・システム上のファイルに保存できます。標準の監査には、権限、スキーマ、オブジェクト、文に対する操作が含まれます。

また、Oracle Cloud Infrastructure Auditを使用して、テナンシで実行されたすべてのAPI管理コールを監査できます。

ハードウェア

データベースのニーズに適したシェイプを選択する方法について教えてください。

Oracle Cloud Infrastructureで現在提供されているシェイプでは、コスト、使用可能なストレージ、パフォーマンス、またはOracle RACデータベースの必要性によってDatabase Service内での選択内容が決まります。シェイプを選択する際は、データベース・サイズの成長計画を念頭に置いてください。

最初に作成した後にDBシステムに関連付けるコア数を変更できますか。

はい。ベア・メタル・システムの場合、DBシステムで使用されるコア数は、コンソールで直接、またはAPIを使用して、停止することなく変更できます。現在、仮想マシンでのコア・スケーリングはサポートされていません。

ベア・メタルDBシステム内のコアをスケール・アップまたはスケール・ダウンする際、インスタンスは再起動されますか。

いいえ。スケール・アップまたはスケール・ダウンする際、インスタンスは再起動されません。この機能により、開発シナリオやテスト・シナリオで必要でない場合に使用するコア数を削減することで、コストを削減できます。

ベア・メタル・サーバーDBシステムにブロック・ストレージ・ボリュームをアタッチできますか。

いいえ。ベア・メタル・サーバーDBシステムにブロック・ストレージ・ボリュームをアタッチすることはできません。ただし、仮想マシン上のDatabase Cloud Serviceでは、プラットフォームで完全に管理されているデータベースに対してリモート・ブロック・ボリュームが使用されます。

DB SystemにSSHできますか。

お客様にはベア・メタルおよび仮想マシン・システムへのフル・ルート・アクセスが提供されます。SSHキー情報を使用することにより、DB SystemにSSHできます。

インスタンスのパフォーマンスが非常に低い場合、どうすればよいでしょうか。

Oracle Database Cloud Serviceは、データベース・インスタンスへのフル・ルートSSHアクセス、およびデータベース・インスタンス上のスキーマおよびパフォーマンス・チューニングを定義する機能を提供しています。Oracleトレース・ファイルを解析して、遅延クエリの背後にある理由を把握できます。正常な動作から逸脱するシステム・レベル・メトリックがある場合は、Enterprise Managerを使用してDB Systemのパフォーマンス・メトリック(CPU使用率、ネットワーク・スループットなど)を監視することをお薦めします。

また、My Oracle Supportを通じてサービス・リクエストを送信いただくことで、デバッグやトラブルシューティングのサポートを受けることができます。さらに、24時間365日のサポート・オプションを提供するOracle Premium Supportにサインアップできます。詳細は、営業担当にお問い合せください。

パッチ適用

Oracle Cloud Infrastructure Database Cloud Serviceのパッチ適用機能とは何ですか。

Database Cloud Serviceのパッチ適用機能を使用すると、DBシステムとデータベースへのパッチ適用に必要な手順を簡略化できます。Oracle Cloud InfrastructureコンソールおよびAPIを使用して、DBシステムまたはデータベース・ホームに適用可能なパッチを確認し、パッチ適用リクエストを発行できます。Database Cloud Serviceによってエンドツーエンドのパッチ適用ステップが自動的に実行され、そのステータスが表示されます。

適用されたすべてのパッチを確認し、必要に応じてパッチを再適用できます。また、Oracle Identity and Access Management (IAM)コントロールを使用して、パッチ適用機能へのアクセスを管理できます。

パッチ適用機能にはどのようにしてアクセスできますか。

この機能にアクセスするには、Oracle Cloud InfrastructureコンソールおよびRest APIを使用できます。

パッチ適用機能を有効にするためのネットワーキング要件について教えてください。

インターネット・ゲートウェイを使用してDBシステムのクラウド・ネットワーク(VCN)を構成する必要があります。DBシステムとOracle Object Storageの間のネットワーク・トラフィックは、Oracle Database Cloud Service内部サービス・バックボーン上を流れます

どのDBシステム、シェイプおよびエディションで、パッチ適用機能を使用してパッチを適用できますか。

この機能を使用してパッチを適用できるのは、すべてのシェイプおよびエディションを対象とした1ノードおよび2ノードのベア・メタルDBシステム全部です。2ノードのRAC、VMおよびExadata Systemは、現在サポートされていません。ただし、これらのシステムには、ホストにログオンしてOPatchユーティリティを使用することにより、パッチを適用できます。

パッチ適用機能を使用すると、どのようなパッチを適用できますか。

DBシステムおよびデータベース・ホームに対して、Database Cloud Serviceに固有のパッチを適用できます。データベース・ホームは最新と以前のパッチの両方をサポートしていますが、DBシステムに使用できるのは最新パッチのみです。現在使用可能なDBシステムとデータベース・ホームのパッチのリストは、Oracle Cloud Infrastructureテクニカル・ドキュメンテーションに記載されています。

すべてのDatabase Cloud Serviceデータベース・バージョンにパッチを適用できますか。

はい。これらのバージョンに対して使用可能なパッチが1つ以上あれば、適用できます。現在、11.2.0.4、12.1.0.2および12.2.0.1データベース・バージョンに対してパッチが使用可能です。

Database Cloud Serviceでまだサポートされていない個別パッチまたは四半期バンドル・パッチは、どのようにして適用できますか。

ホストにログオンし、OPatchユーティリティを使用して個別パッチを適用できます。OPatchユーティリティを使用してオンプレミスの四半期バンドル・パッチを適用することはお薦めしません。これらのパッチは、クラウドに固有の追加パッチを適用しないと動作しない可能性があります。かわりに、Oracle Cloud Infrastructure Database Cloud ServiceコンソールおよびREST APIを介して使用可能な、クラウド用にカスタマイズした四半期パッチを適用する必要があります。

仮想マシンとExadata DBシステムおよびデータベースにはどのようにしてパッチ適用できますか。

これらのシステムにパッチを適用するには、ホストにアクセスし、OPatchユーティリティを使用します。OPatchユーティリティの詳細はこちらを参照してください。

パッチの適用中、停止時間はありますか。

はい。1ノードのDBシステムの場合、Oracle Data Guardを構成していなければ停止時間があります。停止時間をなくすためには、Maximum Availability Architecture (MAA)ベスト・プラクティスに従う必要があります。

パッチ適用機能を使用したがパッチ適用に失敗した場合、どうなりますか。

パッチが失敗した場合、DBシステムまたはデータベース・ホームは「使用可能」状態になります。パッチ履歴に、失敗した操作の理由が示されることがあります。失敗の根本的な原因をデバッグするために、ホストにアクセスして、詳細なパッチ適用関連ログにアクセスできます。ログ情報だけでは問題をデバッグできない場合、根本的な原因を特定するためにOracleサポートにリクエストを申請できます。

パッチ適用機能を使用してDBシステムまたはデータベース・ホームにインストールされたパッチの詳細を確認するには、どうすればいいですか。

コンソールREST APIおよびSDKを使用して、DBシステムおよびデータベース・ホームのパッチ履歴を問い合せることにより、適用されたパッチを確認できます。

DBシステムおよびデータベース・ホームのパッチではパッチ適用順序に従う必要がありますか。

はい。DBシステムのバージョンは、データベース・ホームと同じかそれより上位のバージョンである必要があります。バージョン競合を回避するために、最初にDBシステム・パッチを適用し、その後でデータベース・ホーム・パッチを適用してください。この順序に従わないと、パッチの適用中にエラー・メッセージが表示されます。

パッチ適用機能を使用して適用するパッチを事前チェックまたはロールバックすることはできますか。

はい。パッチは適用前に事前チェックできます。ただし、パッチをロールバックするには、データベース・ホストにログインし、OPatchユーティリティを使用する必要があります。

パッチ適用へのアクセスを、定義したユーザー・セットに制限することはできますか。

はい。Oracle Identity and Access Management (IAM)サービスを使用して、ユーザー・レベルおよびグループ・レベルでアクセスを制限できます。

オンプレミスに使用可能なOracleデータベース・バンドル・パッチとOracle Cloud Infrastructure Database Cloud Serviceに使用可能なパッチには何か違いがありますか。

はい。Oracleデータベース・バンドル・パッチとOracle Cloud Infrastructureデータベース・パッチは異なります。Oracle Cloud Infrastructureデータベース・パッチは、Oracleデータベース・バンドル・パッチ、Oracle Cloud Infrastructure固有のMLR (Merge Label Request)、およびその他のパッチを含むスーパーセットです。

パッチ適用機能を使用してオペレーティング・システム(OS)にパッチを適用できますか。

いいえ。現在、OSへのパッチ適用はサポートされていません。ホストに直接アクセスして、手動でOSにパッチを適用してください。詳細は、ベア・メタルおよび仮想マシンDBシステムのOSの更新およびExadata DBシステムのOSの更新に関するドキュメンテーションを参照してください。

Oracle Cloud Infrastructure Database Cloud Serviceパッチは累積パッチですか。

はい。データベース・パッチは累積パッチです。新しいOracle Cloud Infrastructureデータベース・パッチには、以前のDBシステムからのパッチか、同じバージョンのDB Homeパッチが含まれています。

オラクルはクリティカル・セキュリティ・パッチに関する通知をどのように行いますか。オラクルはクリティカル・セキュリティ・パッチを当社のシステムに自動適用してくれますか。

Oracle Cloud Infrastructureは、クリティカル・セキュリティ・パッチに関する通知を電子メールでお客様に送信します。パッチの重要性に応じて、セキュリティ・パッチを適用するための猶予期間を設定いたします。

パッチ適用を完了するまでにどのくらいの時間がかかりますか。

時間はパッチのタイプによって異なります。パッチの適用が完了すると、DBシステムまたはデータベース・ホームの状態が「使用可能」に変わります。

バックアップとリカバリ

データベースにバックアップとリカバリを設定する方法を教えてください。

データベースのバックアップは、Oracleデータベース環境の重要な側面です。バックアップの格納とリカバリに使用できるオプションは複数あります。Oracle Cloud Infrastructureコンソール、CLIまたはREST APIでバックアップ/リストア機能を使用することも、dbcliまたはRMANを使用してバックアップを手動で設定して管理することもできます。すべてのオプションの詳細は、ここをクリックしてテクニカル・ドキュメンテーションを参照してください。

Oracle Cloud Infrastructure Database Cloud Serviceのバックアップおよびリストア機能とは何ですか。

データベースのバックアップ/リストア機能を使用すると、Oracle Cloud Infrastructureコンソール、CLIまたはREST APIを使用して、データベースのバックアップを作成および管理できます。また、バックアップから既存のデータベースをリストアしたり、バックアップから新しいデータベースを作成することもできます。

バックアップ/リストア機能を使用する場合のメリットと、手動でバックアップを管理する場合のメリットは何ですか。

バックアップ/リストア機能には、バックアップを作成および管理するためのコンソール、CLIおよびREST APIが用意されています。コンソールを使用する場合、数回のクリックで、完全バックアップを作成したり、自動増分バックアップを設定したりできます。同様に、バックアップを確認し、最後に認識された良好な状態、ポイントインタイムまたはSCN (System Change Number)を使用してデータベースをリストアできます。また、既存または新規のDBシステムでバックアップから新しいデータベースを作成することもできます。

バックアップ/リストア機能の使用に対して追加のコストが発生しますか。

バックアップはOracle Cloud Infrastructure Object Storageに格納されるため、バックアップの格納に対するサービス料金が適用されます。Object Storageの価格の詳細はこちらを参照してください。この機能の使用に対して課される追加料金はありません。

バックアップ/リストア機能では、どのデータベース・シェイプ、エディションおよびデータベース・バージョンがサポートされますか。

バックアップ/リストア機能では、すべてのベア・メタルおよび仮想マシン・シェイプ、エディションおよびデータベース・バージョンがサポートされます。現在、Exadataはサポートされていません。ただし、Exadataについては、手動でRMAN (Recovery Manager)を設定してバックアップとリカバリを実行できます。

バックアップ/リストア機能では、現在どのようなバックアップがサポートされていますか。

現在、オンデマンド完全バックアップおよび自動増分バックアップがサポートされています。

バックアップ/リストア機能を使用した自動増分バックアップの保存期間を教えてください。

自動増分バックアップの保存期間は30日間です。

自動増分バックアップのバックアップ保存期間または頻度は独自に設定できますか。

いいえ。バックアップ/リストア機能を使用してこれらの設定を制御することはできません。ただし、手動のRMANオプションを使用してカスタムの保存期間と頻度を設定することはできます。

バックアップ/リストア機能を使用して設定した自動増分バックアップのスケジュールを教えてください。

データベースの自動バックアップを有効にすると、Oracle Cloud Infrastructure Database Cloud Serviceによって00:00から06:00 am UTCまで(毎日のバックアップ時間枠)の間に、最初のレベル0のバックアップが作成されます。最初のバックアップ以降は、翌週末まで毎日、レベル1のバックアップが実行されます。毎週末に新しいレベル0のバックアップが作成されます。

データベース・バックアップは暗号化されますか。

はい。すべてのバックアップは、TDE暗号化に使用されるのと同じマスター・キーを使用して暗号化されます。

バックアップの損失を防ぐために、どのような手段が使用されますか。

お客様のバックアップはOracle Cloud Infrastructure Object Storageに格納されます。Oracle Object Storageは、ゼロから高い耐久性までを実現するよう設計されています。データは、複数のストレージ・サーバーおよび複数のアベイラビリティ・ドメインにわたって冗長的に格納されます。データ整合性はチェックサムを使用してアクティブに監視され、破損したデータは検出されて自動修復されます。データ冗長性が失われた場合は自動的に検出され、ユーザーに影響を与えることなく自己修復が行われます。

バックアップ/リストア機能の使用中にバックアップが失敗する可能性があるのは、どのような状況ですか。

バックアップ/リストア機能の使用中に、データベースまたはDBシステムが「使用可能」な状態にない場合、バックアップ操作が失敗することがあります。パッチ適用、SSHキー追加、Data Guard操作などの処理によって、DBシステムやデータベースの状態が変化することがあります。バックアップの失敗を回避するために、これらの処理はバックアップ時間枠(00:00 - 06:00 UTC)を避けて実行してください。自動増分バックアップが失敗した場合、Database Cloud Serviceは翌日のバックアップ時間枠でバックアップ操作を再試行します。オンデマンド・バックアップが失敗した場合、DBシステムとデータベースの両方が使用可能になっているときに、手動で操作を再試行する必要があります。

バックアップからデータベースをリストアするために使用可能なオプションを教えてください。

バックアップ/リストア機能の使用時には、データベースを最新の状態、ポイントインタイム状態、またはシステム変更番号(SCN)で定義されたデータベースのコミット済状態にリストアできます。ただし、dbcliまたはRMANオプションを使用すると、詳細なリストア・オプションを設定できます。

SCNはどのようにして確認できますか。

SCN番号を確認するには、データベースにアクセスするか、オンラインまたはアーカイブ済のログにアクセスします。

バックアップから新しいデータベースを作成できますか。

はい。既存または新規のDBシステムでバックアップから新しいデータベースを作成できます。ただし、この目的でバックアップを使用する前に、バックアップの生成元のデータベースを削除する必要があります。仮想マシンDBシステムからのバックアップの場合は、新規または既存のDBシステムでそのバックアップを使用する前に、バックアップの取得元のデータベース・インスタンスを終了する必要があります。

バックアップから新しいデータベースを作成する場合、別のDBシステム、コンパートメントまたはアベイラビリティ・ドメインを選択できますか。

はい。既存のDBシステムを選択することも、任意のコンパートメントに新規DBシステムを作成することもできます。ただし、新規または既存のDBシステムは、バックアップがホストされているのと同じアベイラビリティ・ドメインにある必要があります。新規DBシステムを作成する場合、指定するOracle Databaseソフトウェア・エディションは、バックアップされたデータベースのエディション以上である必要があります。また、指定するシェイプは、バックアップが取得されたデータベースと同じタイプである必要があります。たとえば、1ノード・データベースのバックアップを使用している場合は、ターゲットとして選択するDBシステムも1ノードDBシステムである必要があります。

自動増分バックアップはデフォルトで有効化されていますか。

いいえ。自動増分バックアップはデフォルトで有効化されていません。データベースの作成時またはデータベースのプロビジョニング後の任意の時点にオプションを有効化できます。

DBシステムの終了後、バックアップはどうなりますか。

DBシステムを終了する前に、DBシステム内のすべてのデータベースを終了することを強くお薦めします。データベースを終了するときに、Object Storageにスタンドアロン・バックアップとして残る最終バックアップを作成することを選択できます。後でこのスタンドアロン・バックアップを新規データベースとしてリストアできます。

オンプレミスのOracle DatabaseからDatabase Cloud Serviceにデータを移行するには、どうすればいいですか。

RMANを手動で設定して、データベース・バックアップをOracle Cloud Infrastructure Object Storageに移動し、そのバックアップを使用して新規または既存のDBシステムにデータベースを作成できます。

高可用性

可用性の高いデータベースはOracle Database Cloud Serviceでどのように設定しますか。

複数のDBシステムを異なるアベイラビリティ・ドメイン内で起動し、可用性の高いOracleデータベースを設定するためにData Guardを構成することができます。Oracle Data Guardは、エンタープライズ・データの高可用性、データ保護および障害回復を実現します。Data Guardは、1つ以上のスタンバイ・データベースを作成、保守、管理および監視する包括的なサービス・セットを提供します。

Oracleデータベースのデータ損失ゼロの高可用性構成を設定する方法の詳細は、高可用性のためのData GuardおよびMaximum Availability Architecture (MAA)ベスト・プラクティスを参照してください。

アベイラビリティ・ドメインとは何ですか。また、Oracle Database Cloud Serviceでのデータベースの設定になぜ関係があるのですか。

アベイラビリティ・ドメイン(AD)は、独立した信頼性の高いリージョンのサブコンポーネントです。各ADは、ビル、発電機、冷却装置、ネットワーク接続など、完全に独立したインフラを使用して構築されます。火災や洪水など非常にまれな災害時には、1つのADのみが影響を受けます。さらに、同じリージョン内のADは高速の低レイテンシ・ネットワークで接続されるため、顧客はアプリケーションのレイテンシとパフォーマンスへの影響を最小限に抑えながら、信頼性の高いアプリケーションおよびワークロードを構築および実行できます。

これらの障害独立型のADにより、顧客はパフォーマンスを犠牲にすることなく、クラウドに可用性の高いアプリケーションを構築できます。プライマリ・データベースとスタンバイ・データベースを別個のADに配置して、前述の一般的な障害から保護することを強くお薦めします。

Data Guard機能は、どのDatabase Cloud Serviceデータベース・エディションでサポートされますか。

Data Guardは、すべてのEnterpriseデータベース・エディションでサポートされます。Enterprise Extreme Performanceエディションでは、Active Data Guardがサポートされます。

Database Cloud Serviceを使用してData Guardを設定する場合のメリットと、手動でData Guardを設定する場合のメリットは何ですか。

Database Cloud Serviceでは、Oracle Cloud InfrastructureコンソールおよびREST APIを使用してData Guardを構成できます。

数回のクリックで、Data Guardを有効にし、スイッチオーバー、フェイルオーバーおよび再稼働アクションを実行できます。また、Oracle Identity and Access Management Serviceを使用して、この機能に対するきめ細かなアクセス制御を設定することもできます。この機能の使用に対して課されるコストはありません

Data Guard機能は、どのシェイプおよびデータベース・バージョンでサポートされますか。

Data Guard機能では、すべてのベア・メタル1ノードおよび2ノード・シェイプがサポートされます。現在、Exadataおよび仮想マシンはサポートされていません。ただし、ホストにログオンしてData Guardコマンドライン・インタフェース(DGMGRL)にアクセスすることにより、Exadataおよび仮想マシンに対して手動でData Guardを設定できます。DGMGRLの詳細はこちらを参照してください。

Data Guard機能では、現在どの機能がサポートされていますか。

現在、スイッチオーバー、フェイルオーバーおよび再稼働の機能がサポートされています。ただし、ホストにログオンしてData Guardコマンドライン・インタフェース(DGMGRL)にアクセスすることにより、手動でData Guardを設定できます。DGMGRLの詳細はこちらを参照してください。

Data Guard機能では、どの保護モードおよび転送タイプがサポートされますか。

現在、「最大パフォーマンス」保護モードおよび「非同期」転送タイプがサポートされています。ただし、DBシステムにログオンしてData Guardコマンドライン・インタフェース(DGMGRL)にアクセスすることにより、他の保護モードおよび転送タイプを構成できます。DGMGRLの詳細はこちらを参照してください。

Data Guard機能を使用するためのネットワーク設定前提条件について教えてください。

Data Guardを設定するには、プライマリDBシステムとセカンダリDBシステムの両方が同じVCN内に配置され、両方のDBシステムでポート1521がオープンしている必要があります。各DBシステムは異なるサブネットにあってもかまいません。

Data Guardを複数のアベイラビリティ・ドメインにわたって設定できますか。

はい。Data Guardは、1つのリージョンの同じアベイラビリティ・ドメイン内に設定することも、異なるアベイラビリティ・ドメイン内に設定することもできます。ただし、複数のアベイラビリティ・ドメインにわたるData Guard構成を設定することをお薦めします。

Data Guardを複数のOracle Cloud Infrastructureリージョンにわたって設定できますか。

はい。Data Guardは複数のリージョンにわたって設定できますが、Database Cloud Service Data Guard機能では現在それをサポートしていません。ホストにログオンしてDGMGRLを使用することにより、手動でData Guardを複数のリージョンにわたって設定できます。Data Guardがリージョン間でログを転送できるように、プライマリDBシステムとスタンバイDBシステムのVCN上のインターネット・ゲートウェイを有効にする必要があります。DGMGRLの詳細はこちらを参照してください。

Data Guardを複数のコンパートメントにわたって設定できますか。

いいえ。現在、複数のコンパーメントにわたるData Guard設定はサポートされていません。

プライマリ・データベースとスタンバイ・データベースのDBシステムのシェイプおよびエディションは同じにする必要がありますか。

はい。Data Guard機能を使用してData Guardアソシエーションを有効にするには、スタンバイのDBシステムとプライマリのDBシステムのシェイプおよびエディションが同じである必要があります。

Database Cloud ServiceのData Guard機能を使用して作成されたスタンバイ・データベースのバージョンは何になりますか。

スタンバイ・データベースは、プライマリ・データベースのバージョンと同じバージョンで作成されます。

Managed Brokerを設定して、Data Guard機能を使用して自動スイッチオーバーのような処理を実行できますか。

いいえ。現在、Managed Broker機能はData Guard機能でサポートされていません。ただし、データベース・ホストにログオンしてData Guardコマンドライン・インタフェース(DGMGRL)にアクセスすることにより、手動でManaged Broker構成を設定できます。DGMGRLの詳細はこちらを参照してください。

Data Guard機能を使用してData Guardアソシエーションを削除できますか。

Data Guard機能を使用してData Guardアソシエーションを削除するには、まずスタンバイ・データベースを削除する必要があります。スタンバイ・データベースを削除すると、Data Guardアソシエーションが自動的に削除されます。

Data Guard設定でプライマリ・データベースを終了するには、どうすればいいですか。

Data Guard機能を使用する場合、プライマリ・データベースを削除するには、まずスタンバイ・データベースを削除する必要があります。あるいは、プライマリがスタンバイになるようにスイッチオーバー操作を開始してから、スタンバイを終了する方法もあります。

複数のスタンバイ・データベースを作成できますか。

いいえ。Data Guardを使用して作成できる物理スタンバイ・データベースは1つだけです。ただし、DBシステムにログオンしてDGMGRLにアクセスすることにより、手動で複数のスタンバイ・データベースを作成できます。DGMGRLの詳細はこちらを参照してください。

オンプレミス・データベースとOracle Cloud Infrastructureデータベースの間にData Guardを構成できますか。

はい。オンプレミス・データベースとOracle Cloud Infrastructureデータベースの間にData Guardを構成できます。DGMGRLを使用することにより、手動で、オンプレミス・データベースとOracle Cloud Infrastructureデータベースの間にData Guardを設定できます。DGMGRLの詳細はこちらを参照してください。

Oracle Identity and Access Managementコントロールを使用してData Guardアクションへのアクセスを制御できますか。

はい。Oracle Identity and Access Managementを使用して、Data Guard機能へのアクセスを制御できます。Oracle Identity and Access Managementの詳細はこちらを参照してください。

プライマリおよびスタンバイのData Guard設定でデータベースにパッチを適用するには、どうすればいいですか。

プライマリおよびスタンバイのData Guardの設定で、データベースにパッチを適用できます。まず、手動でスタンバイにパッチを適用してから、プライマリにスイッチオーバーしてパッチを適用する必要があります。

Data Guard設定でデータベースをバックアップするにはどうすればいいですか。

Oracle Cloud Infrastructure Databaseのバックアップ/リストア機能を使用して、プライマリ・データベースをバックアップおよびリストアできます。スタンバイのバックアップを有効にする場合は、スタンバイ・データベース・ホストにアクセスし、RMAN (Recovery Manager)を使用します。

障害の発生したプライマリ・データベースを再稼働してプライマリ・データベース状態に戻すには、どうすればいいですか。

Data Guard機能を使用する場合、プライマリ・データベースにフェイルオーバーすると、「無効なスタンバイ」状態であるとみなされます。この無効なスタンバイに関する問題を修正した後、スタンバイを再稼働して動作中のスタンバイ・ロールに戻すことができます。その後で、このスタンバイ・データベースを再びプライマリ・ロールにスイッチオーバーできます。

読取りまたは書込み操作にスタンバイ・インスタンスを使用できますか。

はい。Active Data Guard設定により、読取り専用操作にスタンバイ・インスタンスを使用できます。スタンバイでの書込み操作は有効になっていません。

プライマリ・データベースがスタンバイにフェイルオーバーしたかどうかをどうやって把握するのですか。

Oracle Cloud Infrastructureによって管理されるDB Systemの監視にEnterprise Managerを使用することをお薦めします。インスタンスでログ監査操作を有効にした場合、ログを表示して、プライマリがいつフェイルオーバーしたかを把握することもできます。

データベースのフェイルオーバーにはどのくらいの時間がかかりますか。

2ノードRAC構成の場合、フェイルオーバーは数十秒で完了します。ただし、Data Guardを使用する別個のADにある2つのインスタンス間でのフェイルオーバーの場合、フェイルオーバーは2分未満です。

2ノードRACシェイプはアベイラビリティ・ドメイン(AD)をまたがることができますか。

いいえ。2ノードRACシェイプは、同じAD内の異なるラックに配置された2つのサーバー上のセットです。ストレージは両方のインスタンス間で共有されます。この設定により、インスタンスのハードウェア障害に備えます。可用性を高めるために、各ADで別の2ノードRACシェイプを設定することをお薦めします。

インスタンスにアクセスして、ログで任意のデータベース操作を直接参照することはできますか。

はい。DB Systemへのルート・アクセスを使用して、DB System上のデータベースに対するすべての操作をレビューおよび監査できます。

×
すぐにご連絡ください
0120-155-096 (日本)

お問合せ
×
すぐにご連絡ください
0120-155-096 (日本)

テクニカル・サポート

Oracle Cloudディスカッション・フォーラム