OCI Base Database Service

解決する課題

• Oracle Database を自前のサーバーに構築すると OS パッチ・DB パッチ・バックアップ・冗長化 の運用が重い → マネージドに任せたい
• DB が単一サーバーで止まると困る → Data Guard によるスタンバイ複製と自動フェイルオーバーで可用性を上げたい
• フルマネージドな Autonomous Database では OS やパラメータの細かな制御ができない → DB そのものは自分で運用したいが、インフラ運用は減らしたい
• 既存のオンプレ Oracle 資産（バージョン・構成・ライセンス）を 大きく作り替えずにクラウドへ移したい

主要概念と用語

• DB システム（DB System）: 稼働する DB の基本単位。VM または Bare Metal の計算リソースと、その上で動く Oracle Database を含む
• 配置形態（シェイプ）: VM（仮想マシン）と Bare Metal（占有物理サーバー）を選べる。さらに上位には Exadata 専用基盤の別サービスがある
• エディション: Standard Edition / Enterprise Edition などを選択。Enterprise 系では Data Guard や暗号化などの上位機能が使える
• データベースホーム（DB Home）: 特定の Oracle バージョン・パッチレベルのソフトウェアが入る領域。1 つの DB システム上に複数持てる
• PDB / CDB: マルチテナント構成。コンテナ DB（CDB）の中にプラガブル DB（PDB）を複数収容する
• Data Guard: プライマリの REDO をスタンバイ DB へ転送して複製する仕組み。同期・非同期を選べ、自動フェイルオーバーは Observer が担う
• 自動バックアップ / 手動バックアップ: Object Storage 等へ取得し、ポイントインタイムリカバリ（PITR）に対応
• メンテナンスウィンドウ: パッチや更新を適用する時間帯

仕様・制限・クォータ

• 配置は VM と Bare Metal から選び、シェイプで OCPU・メモリ・ストレージ規模が決まる。VM は Flex シェイプで OCPU を柔軟に指定できる
• ストレージは作成時に確保し、後から 拡張（拡大方向） が可能。縮小は基本的にできない
• 自動バックアップの 保持期間は設定可能で、要件に応じて短縮・延長する。手動バックアップは任意のタイミングで取得できる
• エディションによって利用可能機能が変わる（例: Data Guard は上位エディション向け）。詳細・上限は変動するため公式ドキュメントを基準にする
• リージョン / テナンシごとに サービス制限（リミット） があり、上限引き上げは申請で対応する
• ライセンスは ライセンス込み と BYOL（Bring Your Own License） を選択できる

内部の仕組み

Base Database Service は、選んだ VM または Bare Metal の上に Oracle Database を構成し、OS と DB のパッチ適用・バックアップ・Data Guard 設定などをコントロールプレーン経由で自動化します。利用者は SSH で OS にアクセスして DB を直接運用できる一方、パッチやバックアップといった定型作業は OCI のツール（コンソール・CLI・API）から実行できます。Autonomous Database が OS まで隠蔽する「自己運用」なのに対し、Base Database は OS と DB を利用者が触れる「マネージド」 という位置づけです。

可用性は Data Guard で確保します。プライマリの REDO ログをスタンバイへ転送し、Maximum Availability / Maximum Performance / Maximum Protection の保護モードで同期・非同期の度合いを選びます。プライマリ障害時は Observer がフェイルオーバーを実行し、アプリの接続先をスタンバイへ切り替えます。

設計パターン / ベストプラクティス

• 本番 DB は Data Guard でスタンバイを構成し、別の可用性ドメイン（AD）やリージョンへ冗長化する
• DB システムは プライベートサブネットに置き、パブリックには公開しない
• 接続元は セキュリティリスト / ネットワークセキュリティグループ（NSG） で Oracle のリスナーポートへ最小限だけ許可する
• バックアップは 自動バックアップを有効化し、保持期間を要件に合わせて設定。重要環境では複製先を Object Storage 等へ確保する
• パッチは メンテナンスウィンドウで適用し、重要更新は検証用 DB システムで事前テストする
• DB 接続資格情報は OCI Vault（Secrets） で集中管理し、アプリにハードコードしない

運用・監視

• OCI Monitoring（メトリクス）/ Logging / Database Management で CPU・接続数・スロークエリ・ストレージ使用率を可視化する
• 接続できないときは セキュリティリスト・NSG・サブネット・ルート・リスナーの設定を順に確認する
• パッチ・アップグレードはコンソール / CLI から適用でき、適用前に自動バックアップの取得状況を確認する
• 障害時は Data Guard 構成なら スタンバイへフェイルオーバーし、復旧後にプライマリを再構築（リインスタンス）する

コスト

• 基本は コンピュート＋ストレージ＋バックアップで構成され、Data Guard を組むとスタンバイ分が加算される
• BYOL を選べば保有する Oracle ライセンスを持ち込めるため、ライセンス込みより費用を抑えられる場合がある

セキュリティ

• 保存時暗号化は 既定で有効（Transparent Data Encryption, TDE）。鍵は Oracle 管理に加え、OCI Vault のカスタマー管理鍵を指定できる
• 転送時は TLS/SSL で暗号化し、リスナー設定で暗号化接続を強制できる
• DB システムは プライベートサブネットへ配置し、NSG / セキュリティリストで接続元を最小化する
• 操作権限は IAM ポリシー（グループ・動的グループとポリシー）で最小権限に絞る
• DB 利用者の資格情報は OCI Vault（Secrets） に保管し、コードへ直書きしない

Well-Architected の観点

• 信頼性（Reliability）: Data Guard によるスタンバイ複製と自動フェイルオーバー、自動バックアップ＋PITR で復旧性を確保する。スタンバイは別 AD やリージョンへ分散する
• 運用（Operational Excellence）: パッチ・バックアップ・監視をマネージド機能とメンテナンスウィンドウで標準化し、手作業を減らす。重要更新は検証環境で事前テストする

試験で問われるポイント

関連サービス・比較

• より自動運用に寄せたいなら Autonomous Database、最高性能・大規模統合が必要なら Exadata 専用基盤が選択肢になる
• AWS から移行・比較する読者には、Base Database が RDS for Oracle に最も近いと案内すると理解が早い

ハンズオン / CLI例

# 利用可能な DB システムのシェイプを確認
oci db system-shape list \
  --compartment-id "$COMPARTMENT_OCID" \
  --availability-domain "$AD_NAME" \
  --output table

# VM 上に Base Database の DB システムを作成（プライベートサブネット前提）
oci db system launch \
  --compartment-id "$COMPARTMENT_OCID" \
  --availability-domain "$AD_NAME" \
  --subnet-id "$PRIVATE_SUBNET_OCID" \
  --shape "VM.Standard.E4.Flex" \
  --cpu-core-count 2 \
  --database-edition ENTERPRISE_EDITION \
  --hostname app-basedb \
  --ssh-authorized-keys-file ./id_rsa.pub \
  --db-name APPDB \
  --admin-password "$DB_ADMIN_PASSWORD" \
  --display-name app-base-database

# DB システムの一覧を確認
oci db system list \
  --compartment-id "$COMPARTMENT_OCID" \
  --output table

# 自動バックアップの構成や手動バックアップは database 配下のコマンドで操作
oci db backup create \
  --database-id "$DATABASE_OCID" \
  --display-name app-basedb-manual-bkp