Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Exadata Database Service on Dedicated Infrastru...

Exadata Database Service on Dedicated Infrastructure (ExaDB-D) サービス技術詳細

Oracle Cloud Infrastructure / OCI
Exadta Database Service on Dedicated Infrastructure / ExaDB-D
Oracle Exadata
Exadata Cloud Service / ExaCS

Avatar for oracle4engineer

oracle4engineer

February 26, 2024
Tweet

More Decks by oracle4engineer

Other Decks in Technology

Transcript

  1. Oracle Cloud Infrastructure Exadata Database Service on Dedicated Infrastructure (ExaDB-D)

    サービス技術詳細 日本オラクル株式会社 データベース・ソリューション部 2025 年 6月 24日
  2. Oracle Exadata とは すべてのデータベース・ワークロードのための 最高のプラットフォーム • 単一ベンダーによるサポート • データベースに特化した設計 •

    ハードウェアとソフトウェアの 密なインテグレーション • ストレージへの革新的なアプローチ • Real Application ClustersとOracle Clusterwareにより、DBサーバを並 列稼働させ、高可用性と高拡張性を実現 • Automatic Storage Managementにより、ストレージ・サーバを並列稼 働させ、高いI/O性能と高可用性・高拡張性を実現 • さらに、Exadata System Softwareが処理の一部をオフロードし、大量 データの高速処理を実現。多層のキャッシュの活用、RoCEによるNWボ トルネック排除により、OLTP処理も高速化 Copyright © 2025, Oracle and/or its affiliates | 驚異的なパフォーマンス、優れた運用効率、最高の可用性とセキュリティ、クラウド対応 スケールアウト可能なインテリジェント・ストレージ スケールアウト可能なデータベース・サーバ 最速の内部ネットワーク DBサーバを並列稼働 ストレージを並列稼働 オンプレミスにも クラウドにも 理想的 3
  3. お客様のデータセンターまたはオラクルのパブリック・クラウドで稼働 オンプレミス Exadata Database Machine Cloud@Customer Exadata Database Service on

    Cloud@Customer パブリック・クラウド Exadata Database Service on Dedicated Infrastructure/ on Exascale Infrastructure Oracle Exadataのデプロイ・モデル お客様のデータセンター お客様資産 お客様による管理 お客様のデータセンター サブスクリプション オラクルによる管理 Oracle Cloud Infrastructure サブスクリプション オラクルによる管理 Copyright © 2025, Oracle and/or its affiliates | 5
  4. Oracle Cloud Infrastructureデータベース・サービス(Oracle Database) Oracle Database on Virtual Machines 1-64

    OCPUs (RAC: 4-128 OCPUs) BaseDB (Base Database Service) 1コアからスタート エディション選択可能 RAC対応 ADB (Autonomous Database) Autonomous Data Warehouse Autonomous Transaction Processing AI/機械学習を活用した 自律型データベース 完全なマネージドサービス ExaDB-D (Exadata Database Service on Dedicated Infrastructure) あらゆるワークロードで 高性能を実現する Exadataの専有環境 Oracle Exadata 16-24,320 ECPUs (4-6,080 OCPUs) Automated (今までのOracle Databaseを便利に利用できる) Full-Managed ExaDB-XS (Exadata Database Service on Exascale Infrastructure) あらゆるワークロードで 高性能を実現する Exadataの共有環境 Oracle Exadata 16-2,000 ECPUs (4-500 OCPUs) Copyright © 2025, Oracle and/or its affiliates | 本資料の内容 6
  5. 最高のデータベース基盤をパブリック・クラウドで利用可能 Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) ミッションクリティカル基盤で圧倒的な実績を誇る

    Exadata専有環境をサブスクリプションで利用可能 Exadata 専有環境 CPUは1秒単位で柔軟に増減可能 HW/SW/サポート全て込み 全てのオプション機能が使い放題 柔軟な 価格体系 Exadata基盤の管理は全てオラクルにお任せ 超高速なOracle Databaseとしてシンプルに利用可能 インフラ 管理不要 Copyright © 2025, Oracle and/or its affiliates | 7
  6. 多様なビジネス要件に対応する柔軟なサービスを提供 Oracle Cloudにて提供するデータベースサービス 8 Base Database Service Exadata Database Service

    Autonomous Database Oracleによるフルマネージド Oracle管理のインフラストラクチャとお客さま管理のデータベース あらゆるワークロードに対応する最高のパフォーマンス、拡張性、統合性 シングル/小規模なワークロード Automation ADB Serverless ADB on Dedicated Infrastructure ExaDB on Dedicated Infrastructure Oracle Cloud Infrastructure ExaDB on Cloud@Customer Enterprise and Standard Database Services ADB on Cloud@Customer Oracle Cloud Infrastructure お客さまの データセンター お客さまの データセンター Copyright © 2025, Oracle and/or its affiliates | ExaDB on Exascale Infrastructure 専有型 専有型 共有型 共有型
  7. 各サービスの管理範囲の違い DB on IaaS ExaDB Autonomous Database OCI データベース・サービス Copyright

    © 2025, Oracle and/or its affiliates | データセンター ハードウェア機器 OS データベース アプリケーション クラウド 事業者管理 お客様管理 ハイパーバイザー 仮想マシン データセンター ハードウェア機器 OS データベース アプリケーション クラウド 事業者管理 お客様管理 ハイパーバイザー 仮想マシン データセンター ハードウェア機器 OS データベース アプリケーション クラウド 事業者管理 お客様管理 ハイパーバイザー 仮想マシン OS以上は オンプレミス同様の管理 データベースはBYOL OS以上の操作が可能 OS/DBのバージョンや構成が限定される クラウドのメリットを享受(従量課金や自動化) 最小限のDB管理を除き DB以下はすべてクラウド事業者が管理 Automated Full-Managed 9
  8. シェイプ別仕様 Elastic構成(X11M/X9M/X8M) • 必要な分のデータベース/ストレージ・サーバーで構成 • 最小構成 - データベース・サーバー2台+ストレージ・サーバー3台 • 1台ずつスケーリング可能

    - データベース・サーバー: 2-32台 - ストレージ・サーバー: 3-64台 Base System • モデル(H/W世代)指定不可 • 利用可能なモデルのいずれかが割り当てられる • サーバー数固定、リソースも最小構成 • DBサーバーx2、ストレージ・サーバーx3 • サーバー数はElasticの最小構成と同様だが、実 際に利用可能なHWリソースは小さい Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) Copyright © 2025, Oracle and/or its affiliates | 10 + データベース・サーバー + ストレージ・サーバー 2025/06/24 更新
  9. ExaDB-D: シェイプ別仕様 https://www.oracle.com/a/ocom/docs/engineered-systems/exadata/exadb-d-x11m-ds.pdf * as of January 2025 Base System

    最小構成 追加データベース・サーバー 追加ストレージ・サーバー データベース・サーバー数 2 2 1 - ECPU/OCPU 数 Min-Max 拡張単位 Min-Max 拡張単位 Min-Max 拡張単位 - 0-192 16以上 8単位 0-1,520 16以上 8単位 0-760 8以上 4単位 - メモリ容量 720 GB 2,780 GB 1,390 GB - ストレージ・サーバー数 3 3 - 1 ストレージ・サーバー・コア数 144 192 - 64 XRMEM容量 N/A 3.75 TB - 1.25 TB フラッシュ容量 38.4 TB 81.6 TB - 27.2 TB 利用可能ストレージ容量 (三重化) 73 TB 240 TB - 80 TB Infrastructure 月額概算費用 (カッコ内は時間費用) ¥1,240,000 (\1,666.6685/h) \1,674,000 (\2,249.98/h) 334,797 (¥ 449.996/h) 334,797 (¥ 449.996/h) ECPU/OCPU 時間費用 \ 52.08 / ECPU (License Include)|\12.5085 / ECPU (BYOL) ✓ ECPUは1データベース・サーバー当たり、8ECPU以上 4ECPU単位で拡張 [拡張例] Quarter Rackの例:0(停止状態)=>16=>24=>32…|Half Rack 相当(4DBサーバー)の例:0(停止状態)=>32=>48=>64… ✓ ストレージは、High Redundancy (三重化) で固定 ✓ Infrastructure 月額概算費用:時間単位の費用を744時間(24時間×31日)で換算 Exadata X11M 世代設定なし Copyright © 2025, Oracle and/or its affiliates | 11 Elastic構成 DB/Storage Serverを1台ずつ追加 Half Rack 相当:Quarter + 2 DB + 3 Storage Full Rack 相当: Quarter + 6 DB + 9 Storage
  10. ExaDB-D: X9M シェイプ別仕様 https://www.oracle.com/a/ocom/docs/engineered-systems/exadata/exadata-cloud-infrastructure-x9m-ds.pdf * as of September 2024 Quarter

    Rack X9M Half Rack 相当 Full Rack 相当 データベース・サーバー数 2 4 8 OCPU数 Min-Max 拡張単位 Min-Max 拡張単位 Min-Max 拡張単位 0-252 4以上2単位 0-504 8以上4単位 0-1,008 16以上8単位 メモリ容量 2,780 GB 5,560 GB 11,120 GB ストレージ・サーバー数 3 6 12 永続性メモリ容量 4.5 TB 9.0 TB 18.0 TB フラッシュ容量 76.8 TB 153.6 TB 307.2 TB 利用可能ストレージ容量 (三重化) 190 TB 381 TB 763 TB Infrastructure 月額概算費用 (カッコ内は時間費用) \1,674,000 (\2,250.011/h) \3,348,000 (\4,499.991/h) \6,696,000 (\8,999.951/h) OCPU 時間費用 \208.3355 / OCPU (License Include)|\50.003 / OCPU (BYOL) ✓ OCPUは1データベース・サーバー当たり、2 OCPU以上1 OCPU単位で拡張 [拡張例] Base System/Quarter Rackの例:0(停止状態)=>4=>6=>8…|Half Rack 相当の例:0(停止状態)=>8=>12=>16… ✓ ストレージは、High Redundancy (三重化) で固定 ✓ Infrastructure 月額概算費用:時間単位の費用を744時間(24時間×31日)で換算 Exadata X9M Copyright © 2025, Oracle and/or its affiliates | 12 Elastic構成 DB/Storage Serverを1台ずつ追加 Half Rack 相当:Quarter + 2 DB + 3 Storage Full Rack 相当: Quarter + 6 DB + 9 Storage
  11. Copyright © 2025, Oracle and/or its affiliates | 13 Base

    Systemは、ハードウェアの世代に依存しない固定されたシェイプで、コスト効率の良いエントリーモデルです • 注意点 • モデル(H/W世代)は選択できません • データベース・サーバーならびにストレージ・サーバーの拡張(物理H/Wリソースのスケーリング)はできません - 割り当てられているリソース内でのスケーリングは可能 - さらにH/Wリソースが必要になった場合には、お客様による別のシェイプへデータベース移行が必要 • 短期利用等以外では、Elastic構成/Quarter Rack以上のシェイプを推奨 • 最新のH/Wモデルを利用したい - 最新モデルの性能向上を享受・H/Wモデルに依存する新機能の利用 など • 長期での利用 - データ増幅や処理数増加が見込まれ、H/Wリソースの追加が想定される・H/WのEOSLの観点で長く使いたい など • 特定のモデルを指定して使いたい - 検証・開発目的で、オンプレミスで利用しているH/Wモデルと同じものを使いたい、複数ExaDB構成でH/Wモデルを合わせたい など ExaDB-D: Base Systemについて
  12. ExaDB-D: 価格体系(ECPU:X11M) 1. Exadata ECPU • 0から搭載している最大CPUまで変更可能 - 1DBサーバー当たり、8ECPU以上、4ECPU単位で拡張 •

    課金は1秒単位 (最低利用期間1分間) • 2種類:ライセンス込(License Included) or BYOL 2. Exadata Infrastructure • Base System or Elastic構成 - Elastic構成:2 DB/3 Storage + 1台ずつ追加 • 課金は1秒単位 (最低利用期間48時間) Exadata Infrastructure ECPU 1秒単位 (48時間以上) 1秒単位 (1分間以上) ゼロ CPU から可能 \2,250.011/時 = \1,674,000/月 (最小構成) 1 2 \52.08/時 (ライセンス込) \12.5085/時 (BYOL) Copyright © 2025, Oracle and/or its affiliates | 14 Exadata Database Serviceの優れた柔軟性 * as of January 2025
  13. ExaDB-D: 価格体系(OCPU:X9Mまで) 1. Exadata OCPU • 0から搭載している最大CPUまで変更可能 • 課金は1秒単位 (最低利用期間1分間)

    • 2種類:ライセンス込 or BYOL 2. Exadata Infrastructure • Base System or Elastic構成 - Elastic構成:Quarter + 追加DB/Storage • 課金は1秒単位 (最低利用期間48時間) Exadata Infrastructure OCPU 1秒単位 (48時間以上) 1秒単位 (1分間以上) ゼロ CPU から可能 \2,250.011/時 = \1,674,000/月 (最小構成) 1 2 \208.3355/時 (ライセンス込) \50.003/時 (BYOL) Copyright © 2025, Oracle and/or its affiliates | 15 Exadata Database Serviceの優れた柔軟性 * as of September 2024
  14. ECPU (X11M) • 参考)導入サービス: ADB/ExaDB-D/ExaDB-XS • コンピューティング・リソースの抽象化された単位 • 共有プールから柔軟に割り当てられるコア数に基づく •

    長期的観点で一貫した価格メトリックとして導入 • プロセッサ・モデルやクロックスピードに依存しない価格メト リックで複雑性を回避することを目的 OCPU (X9Mまで) • 参考)導入サービス: BaseDB/ExaDB-D • 物理コアに相当する単位 • ハイパー・スレッドを有効にしたIntel Xeonプロセッサの1 つの物理コアと同等 • 1 OCPUは、x86ベースのコンピュートでは2 vCPU同 等と考えられる Exadata Database Service X11Mのサポート開始 参考) CPUモデル: ECPUとOCPU Copyright © 2025, Oracle and/or its affiliates | 16 考え方: 4 ECPU = 1 OCPU * *価格は同一。スペック・性能に関しては異なる
  15. サポートもサービス費用に含む ExaDBでは全てのOracle Database機能とオプションが利用可能 Extreme Performance High Performance Enterprise Edition Multitenant

    Partitioning Advanced Compression Advanced and Label Security, Database Vault, SQL Firewall Real Application Clusters DB In-Memory Active Data Guard • 全てのSE2標準機能 - Machine Learning - Spatial and Graph - Multitenant (3PDB) • 表領域暗号化 Standard Edition • 全てのEE標準機能 - Data Guard - Hybrid Columnar Compression(HCC) - パラレル処理 etc Real Application Testing OLAP Management Packs (Data Masking and Subsetting Pack, Diagnostics and Tuning Packs) Management Packs (Database Lifecycle Management Pack, Cloud Management Pack for Oracle Database) Copyright © 2025, Oracle and/or its affiliates | 17 BaseDBでのエディションの考え方 Exadata Database Service
  16. 2種類のライセンス・タイプから利用可能。作成後にオンラインのライセンスタイプ変更も可能 License Included • 全Databaseオプションが利用可能 (Database Enterprise Edition Extreme Performance)

    - RAC, Active Data Guard, Partitioning, In-Memory, Multitenant, Advanced Security, Diag Pack, Tuning Pack, Real Application Testing, Advanced Analytics, Advanced Compression, Label Security, Data Masking など • 全Exadata System Software 機能が利用可能 • サポート費用込み BYOL to PaaS • 既にお持ちのデータベース・ライセンスやオプションの持ち込み - 1 Processor = 8 ECPU or 2 OCPU - 25 NUP = 8 ECPU or 2 OCPU • Database Serviceのクラウド・ツール機能、インフラ監視・管理、Exadata System Softwareは含まれる • 透過的データ暗号化(TDE)、 Diagnostic Pack, Tuning Pack, Real Application Testingは含まれる • お客様が持ち込んだデータベースおよびデータベース・オプションのオンプレミス・サポートは引き続きお支払いいただく • On-Premiseからの移行の場合、オンプレミスから環境移行する作業期間として、最長100日間のライセンスの一時的 な並行利用が可能(オンプレミスからの移行時における並行稼動期間の特例) 参考) ExaDB-D: 価格体系 Copyright © 2025, Oracle and/or its affiliates | 18 * 2024年9月現在
  17. ExaDB-D: 専有型のインフラストラクチャのリソース 共有型(BaseDB/ExaDB-XS/ADB-S) • 沢山のH/Wを束ねたリソースのプールから、必要な分だけを 切り出して利用 • リソース追加する場合、プール内でのリソース割り当て量を増 やす 専有型(ExaDB-D/ADB-D)

    • 利用するH/Wのリソースを全て利用可。ExaDBやADB-Dは、 さらにプール化して切り出す形での利用も可能 • 利用中H/Wリソース内でリソース追加する場合は、プール内 でのリソース割り当て。利用中リソース以上のリソースが必要 な場合する場合、H/W追加を行う 20 Copyright © 2025, Oracle and/or its affiliates | OCI Oracle Databaseサービスの共有型と専有型での違い 課金対象 インフラ ストラクチャ ストレージ CPU コンピュート ストレージ CPU コンピュート
  18. DBサーバー1 DBサーバー2 DBサーバー3 構成 インフラストラクチャ構成 • 必要な分のデータベース/ストレージ・サーバーで構成 • 最小構成 -

    データベース・サーバー2台+ストレージ・サーバー3台 • 1台ずつスケーリング可能 - データベース・サーバー: 2-32台 - ストレージ・サーバー: 3-64台 Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) Copyright © 2025, Oracle and/or its affiliates | 21 + データベース・サーバー + ストレージ・サーバー インフラストラクチャ上の柔軟な構成 • 1データベース(システム)での専有環境でも、複数シス テム(OS分離、DB分離)での共有環境でも構成可 必要に応じたスケール・アウト/イン 23.4.0 19.22.0 19.21.0 VMクラスタA (3VMクラスタ) VMクラスタB(2VMクラスタ) VMクラスタC (1VM) 例) データベース・サーバー3台上に複数環境を構成する例 要件や用途に応じた複数環境の集約・統合 23.4.0 VMクラスタごとに利用する リソース(CPU等)を設定
  19. 構成要素 ①Exadata インフラストラクチャ Exadataモデル(X11M、X9M..等)とそのシステム構成。ユー ザー専有のリソース ②VMクラスタ 複数のVMのクラスタ構成。VMクラスタごとに、ネットワーク、 OCPU数、Grid Infrastructure(GI)、GIによるVMのクラスタ構 成やストレージ構成を管理

    ③ネットワーク(VCN) VMクラスタが利用するクライアントおよびバックアップ・ネット ワークの構成 ④仮想マシン(ノード) クラスタを構成するコンピュート(ゲストVM) ⑤Grid Infrastructure(GI) Oracle Clusterwareによるデータベースやリソース管理、ASM によるストレージ管理などを担うソフトウェア ⑥データーベース VMクラスタ内の複数VMに跨って構成される、RAC(Real Application Clusters)データベース ⑦DBホーム VMクラスタにおいて利用する、各種バージョンのOracle Databaseソフトウェア・バイナリーの構成 ⑧Exadataストレージ VMクラスタごとに割り当てられるストレージ領域 ⑨DBバックアップ 自動バックアップの保存先 Exadata Database Service on Dedicated Infrastructure(ExaDB-D) Copyright © 2025, Oracle and/or its affiliates | 22 ②VM クラスタ ①Exadata インフラストラクチャ ⑧Exadataストレージ DATA RECO (SPARCE) ③VCN クライアント・ネットワーク バックアップ・ネットワーク ④仮想マシン(ノード) KVMホスト ストレージ・サーバー2 ストレージ・サーバー3 ストレージ・サーバー1 ⑦ DBホーム ⑤Grid Infrastructure DBサーバー1 DBサーバー2 ゲストVM KVMホスト ゲストVM 仮想マシン(ノード) ⑥データベース ⑨DBバックアップ *最小構成 の場合
  20. Copyright © 2025, Oracle and/or its affiliates | 23 Oracle

    Exadata Database Service on Dedicated Infrastructure (ExaDB-D) サービス構成とリソース: ①Exadata Infrastructure
  21. Exadata インフラストラクチャ : サーバー構成 Exadata Database Service on Dedicated Infrastructure

    構成 Copyright © 2025, Oracle and/or its affiliates | 24 モデル • X11M、X9M、X8M • Base System データベース・サーバー • X11M/X9M/X8M: 最小2。最大で 32 まで構成可能 • Base System: 2 で固定 ストレージ・サーバー • X11M/X9M/X8M : 最小3。最大で 64 まで構成可能 • Base System: 3 で固定 Exadataインフラストラクチャ ストレージ サーバー1 データベース サーバー 2 データベース サーバー 1 データベース サーバー N ストレージ サーバー2 ストレージ サーバー3 ストレージ サーバーN … … 2025/06/24 更新 参考) ・ExaDB-D管理者ガイド> X8M、X9MおよびX11MスケーラブルExadata Infrastructureの概要 ・ExaDB-D 技術アーキテクチャ > Rack概要
  22. Copyright © 2025, Oracle and/or its affiliates | 27 Oracle

    Exadata Database Service on Dedicated Infrastructure (ExaDB-D) サービス構成とリソース: ②ネットワーク
  23. ネットワーク ネットワーク • VCNで設定 - 2つのサブネット: クライアント用とバックアップ用 • VMクラスタ作成時に、事前作成済みのサブネットを選択 •

    ネットワーク分離の観点で、VMクラスタ毎に異なるサブネッ トを利用することを推奨(同一も可) - Object Storageや自律型リカバリ・サービスへのアクセスのため の設定が必要 • 内部ネットワーク - Exadata内の通信は、RoCE (X11M/X9M/X8M)ファブリック • RoCE(RDMA over Converged Ethernet)による、広帯域で低遅延なセキュア・ ファブリック・ネットワーク Exadata Database Service on Dedicated Infrastructure 構成 Copyright © 2025, Oracle and/or its affiliates | 28 2025/06/24 更新 VM クラスタ Exadata インフラストラクチャ VCN クライアント・ネットワーク バックアップ・ネットワーク 仮想マシン(ノード) ストレージ・サーバー2 ストレージ・サーバー3 ストレージ・サーバー1 DBサーバー1 DBサーバー2 仮想マシン(ノード) Secure Fabric VM クラスタ 仮想マシン(ノード) 仮想マシン(ノード) 参考) ・ExaDB-D管理者ガイド> ネットワーク設定 ・ExaDB-D 技術アーキテクチャ > VCN
  24. 接続イメージ Copyright © 2025, Oracle and/or its affiliates | 29

    OCI Region Availability Domain 1 On-Premises Public Subnet Private Subnet Private Subnet for Backup Network VCN Auditing Identity & Access Management Public/Private Subnet for Client Network Object Storage DRG Customer Premises Equipment Site-to-Site VPN Oracle Services Network Service Gateway Virtual Machine Exadata Database Service Virtual Machine Fast Connect Autonomous Recovery Service Internet Gateway Internet
  25. クライアント・サブネット(Public)の場合 ネットワーク例 Copyright © 2025, Oracle and/or its affiliates |

    30 クライアント・サブネット(Private)の場合 OCI Documentation Exadata Cloud Service > Network Setup for Exadata Cloud Infrastructure Instances
  26. Copyright © 2025, Oracle and/or its affiliates | 31 属するVCN内に2つのサブネット(クライアント/バックアップ)が必要

    • サブネットは、リージョン内のすべてのADにまたがる「リージョナル・サブネット」の利用を推奨 - AD固有にする場合は、クライアント/バックアップ・サブネットは同一AD内に作成 • 全てのノード間で、TCPとICMPの疎通ができるようにセキュリティ・リストのイングレス/エグレス設定 • X8M以降のシステムの場合、Oracleでは、イングレスおよびエグレス・トラフィックのために、クライアント・サブネット上のすべてのポートをオープンする必要があることを推奨 - システムにデータベース・サーバーを追加するための要件 IPアドレス・スペースの要件 • 利用するクライアントサブネット、バックアップサブネットは下記と重複しないこと X8M以降: 100.106.0.0/16と100.107.0.0/16 X8以前 : 192.168.*(特に192.168.128.0/20) • データベース・サーバー、ストレージ・サーバー間のインターコネクトのネットワークで利用しているため。 • お客様ネットワークで上記CIDRブロックと重なるネットワークを利用している場合、NATを設定することで対応可能 • 複数システムを利用する場合、相互のIPアドレスが重複しないこと • VMクラスタごとのVM数に応じて、必要なアドレス数を用意(次ページ) オブジェクト・ストレージへのアクセス • オブジェクト・ストレージへのDBバックアップとリストア、パッチ適用やクラウド・ツールの更新のため、オブジェクト・ストレージへのアクセスが必要(134.70.0.0/16) Autonomous Recovery Service(ZRCV/RCV)へのアクセス • Autonomous Recovery Service(ZRCV/RCV)を使用する場合、専用のサービス・サブネットが必要 参考) ネットワーク前提条件 3 Preparing for Exadata Cloud Infrastructure> Network Setup for Exadata Cloud Infrastructure Instances
  27. 必須IPアドレス数/最小サイズ • VMクラスタごとに必要なIPアドレス数を算出 参考) ネットワーク前提条件 Copyright © 2025, Oracle and/or

    its affiliates | 32 クライアント・サブネット バックアップ・サブネット モデルとシェイプ 必須IPアドレス数 最小サイズ 必須IPアドレス数 最小サイズ Elastic 構成 (N: VM数) 下記より算出 •4 x N (Host IP/VIP) •3 (SCAN) + 3 (reserve) - 下記より算出 •3 x N (Host IP/VIP) •3 (reserve) - Base System 14 •4x2 nodes (Host IP/VIP) •3 (SCAN) + 3 (reserve) /28(16 IPアドレス) 9 •3x2 nodes (Host IP) •3 (reserve) /28(16 IPアドレス) 上記IPアドレス数はMulti-VM構成の場合VM Cluster毎に必要になります 3 Preparing for Exadata Cloud Infrastructure> Network Setup for Exadata Cloud Infrastructure Instances 2025/06/24 更新
  28. • クライアント、バックアップサブネットでIPv4/IPv6デュアルスタックネットワーキング構成でVMClusterをプロビジョニング可能 • 1つのIPv6接頭時を持つサブネットのみをサポート • グローバル・ユニキャスト・アドレス (GUA)、BYOIP、ユニーク・ローカル・アドレス(ULA)のIPv6接頭時をサポート • 仮想IPとシングル・クライアント・アクセス名(SCAN)は、IPv4とIPv6ネットワーク用に構成、アプリケーションVIPもIPv6構成可能 •

    既存のIPv4構成から新しいIPv4/IPv6構成の環境にData Guardで移行可能 • Migrate from a Single Stack (IPv4) Exadata VM Cluster to a Dual Stack (IPv4/IPv6) Exadata VM Cluster with Data Guard Synchronization 最小要件 • Exadata System Software : 24.1.4以上 • Oracle Database/Oracle Grid Infrastructure: 19.26 / 23.7以上 考慮事項 • 自律型リカバリ・サービスを利用する場合は、IPv4専用サブネットが必要 チュートリアル • Oracle Exadata Database Service on Dedicated InfrastructureのIPv4/IPv6デュアルスタック・ネットワーキングの構成 IPv4/IPv6デュアルスタックネットワークのサポート Copyright © 2025, Oracle and/or its affiliates | 33 2025/06/24 追加
  29. Copyright © 2025, Oracle and/or its affiliates | 37 Oracle

    Exadata Database Service on Dedicated Infrastructure (ExaDB-D) サービス構成とリソース: ③VM クラスタ
  30. 複数のVM(仮想マシン)をGrid Infrastructureでクラスタ構成 • VMクラスタレベルで管理されるリソース • CPU数、ネットワーク・サブネット、Grid Infrastructure、ストレージ・サー バー上のストレージ領域(ASM Disk Group)、IORMなど

    • Exadataインフラストラクチャ上に、VMクラスタを複数構成可能(マルチVM) - DBのインフラ統合をしてリソースの効率化によりコスト削減しながら、用 途や要件に応じてワークロードや管理等、分離させることが可能 - VMクラスタごとに必要OCPUを設定することで、コストの最適化 • VM クラスタの作成、削除、リソース変更はコンソールやCLI/APIから可能 VMクラスタ Copyright © 2025, Oracle and/or its affiliates | 38 ストレージサーバー1 ストレージサーバー2 ストレージサーバー3 ストレージサーバー4 ストレージサーバー5 DBサーバー1 DBサーバー2 DBサーバー3 DBサーバー4 Disk Group(VMクラスタA) Disk Group(VMクラスタB) Disk Group(VMクラスタC) VMクラスタA VMクラスタB VMクラスタC Secure Fabric VCN Grid Infrastructure Grid Infrastructure Grid Infrastructure 参考) ・ExaDB-D管理者ガイド> VMクラスタの管理 ・ExaDB-D 技術アーキテクチャ > VMクラスタ
  31. 複数VMクラスタ構成(マルチVM)について 1つのExadataインフラストラクチャ上に、VMクラスタを複数構成 • X8M以降のシェイプをサポート。Base Systemは非対応 • 1つのDBサーバー上には最大8VM、1つのExadataインフラストラクチャ上 には合計8VMクラスタまでが作成可能 • 特定のDBサーバーでのVMクラスタ作成も可能(ノードのサブセット化)

    - 1VMだけのVMクラスタも可能=データベースはシングル構成 • DBのインフラ統合をしてリソースの効率化によりコスト削減しながら、用途や 要件に応じてワークロードや管理等、分離させることが可能 • 分離要件の例 - OS分離: VMクラスタごとにVMが構成 - クラスタウェア分割 : VM クラスタ毎にGrid Infrastructureがインストール - ネットワーク分離 : VM クラスタ毎に異なるサブネットを利用可能(推奨) - ストレージ分離 : VM クラスタ毎に ASM Disk Group を利用 • インフラ・メンテナンスは同一Exadataインフラストラクチャ上で共通 • Autonomous Database (ADB-D)も利用可能 VMクラスタ Copyright © 2025, Oracle and/or its affiliates | 39 ストレージサーバー1 ストレージサーバー2 ストレージサーバー3 ストレージサーバー4 ストレージサーバー5 DBサーバー1 DBサーバー2 DBサーバー3 DBサーバー4 Disk Group(VMクラスタA) Disk Group(VMクラスタB) Disk Group(VMクラスタC) VMクラスタA VMクラスタB VMクラスタC Secure Fabric VCN Grid Infrastructure Grid Infrastructure Grid Infrastructure
  32. VMクラスタ データベース統合の効率とクラウドの経済性を向上 40 Copyright © 2025, Oracle and/or its affiliates

    | 同一Exadata Cloud Infrastructure上で複数サービス利用 Autonomous Database と Exadata Database Service 同一インフラストラクチャ上で 同時に実行可能 Database Server 1 Database Server 2 VM Cluster 2 OLTPのためのより多くのコンピュート Autonomous Database VM Cluster 1 分析のためのより多くのストレージ Exadata Database Service VM Cluster 3 コンピュートとストレージのバランスした構成 Autonomous Database 2025/06/24 更新
  33. ソフトウェア・バージョンとリソース バージョンの選択 • Oracle Grid Infrastructure : 23ai、19c • データベースで23aiを利用したい場合、GIは23aiを選択

    • Exadata ゲスト・バージョン : Exadata System Software(ESS) 25 (2025/6現在) • 「イメージの変更」をクリックするとバージョン指定が可能 • X9Mまで: ESS24までのバージョンも選択可能 VM クラスタの構成 同一VM クラスタ内の VM はすべて同じサイズのリソースが割り当てられる X11Mの場合 • VM あたりの ECPU 数: 8 ~ 760* ECPU • VM あたりのメモリー(GB): 30 ~ 1,390* GB • VM あたりのローカル・ファイル・システム・サイズ (GB): • /u02: 60 ~ 900* GB • 追加ローカル・ファイル・システム構成オプション: /、/var、/home、/tmp、/u01、/var/log、 /var/log/auditも指定可能 VMクラスタの構成 Copyright © 2025, Oracle and/or its affiliates | 41 *最大数はデータベース・サーバーあたり。複数VMクラスタを作成する場合、 VMクラスタ作成時に、未割り当て=使用可能なリソースが最大値となる。 2025/06/02 更新
  34. 詳細 OS (Exadata System Software) • クラウド上で提供されている最新バージョン: 25 (X9Mまでのシェイプは、24以前も選択可能(2025/06現在)) •

    OSはOracle Linux。バージョンは、Exadata System Softwareのバージョンに紐づく • Oracle Linux等のExadata System Softwareに含まれるコンポーネントのバージョン - Doc ID 888828.1 Exadata Database Machine and Exadata Storage Server Supported Versions から該当するExadata System Softwareの情報を確認 • 最新で利用可能なバージョンについてMOS Noteから確認 - インスタンス作成前など実環境で確認不可の場合など - Doc ID 2333222.1: Exadata Database Cloud Software Versions にて、Exadata Version(Exadata System Software)を確認し、 そのバージョンでのOSバージョンを Doc ID 888828.1 Exadata Database Machine and Exadata Storage Server Supported Versions にて確認可能 インフラレイヤー(Exadata System Software など) • クラウド上で提供されている最新バージョン(指定不可) Doc ID 2333222.1: Exadata Database Cloud Software Versions OSバージョン選択 Copyright © 2025, Oracle and/or its affiliates | 42 2025/06/24 更新
  35. 利用可能CPU 数 Exadata VM クラスタ全体で利用可能なCPU数 • 各仮想マシンには等しい数のCPU数が割当 (仮想マシンごとに異なる CPU 数にはできない)

    - スケーリング時、仮想マシンあたり1 CPU単位で増減(2ノードでECPUモデルの場合:16、32、48…) • 仮想マシンあたり最低 8 ECPU or 2 OCPU 以上が必要 • 仮想マシン上のDBインスタンスあたり4 ECPU or1OCPU以上が推奨 • CPU を 0 に設定した場合は仮想マシンは停止し、CPUの課金も停止 43 Copyright © 2025, Oracle and/or its affiliates | VMクラスタごとに割り当て VMクラスタ(2ノードの場合) 10 ECPU 10 ECPU 20 ECPU 仮想マシン 1 仮想マシン 1 VMクラスタ(4ノードの場合) 10 ECPU 10 ECPU 40 ECPU 仮想マシン 1 仮想マシン 2 仮想マシン 4 仮想マシン 3 10 ECPU 10 ECPU 4ノードRAC 4ノードRAC 2ノードRAC 2ノードRAC 2025/06/24 更新
  36. VM数とローカル・ファイル・システムに割り当てられるサイズの関係(X8M以降の場合) データベース・サーバーあたり利用できる合計ローカル・ファイル・システム容量 • 最大 2,243 GB • VMあたりの最小容量: 244 GB

    (そのうち/u02は60GB) VMクラスタの構成 Copyright © 2025, Oracle and/or its affiliates | 44 VM 数 データベース・サーバーあたり、全てのVMの OS、GI によって利用される合計容量 (GB) データベース・サーバーあたり、すべての VM に 追加で利用できる合計容量 (GB) 1 244 1999 2 488 1755 3 732 1511 4 976 1267 5 1220 1023 6 1464 779 7 1708 535 8 1952 291
  37. VMのローカル・ファイル・システムごとの割り当て可能サイズと、スケーリング可否 マウントポイント デフォルトサイズ 構成 ファイルシステムのリサイズ 参考) 2024/06以前のサイズ / 15 GB

    最大 900 GB. 拡張のみ 15 GB /u01 20 GB 最大 900 GB. 拡張のみ 250 GB /u01/../grid 50 GB 変更不可 50 GB /u02 60 GB 最大 900 GB. 拡張、縮小可 60 GB /acfs01 100 GB リサイズ時はオラクルサポートに連絡 100 GB /boot 509 MB 変更不可 509 MB /crashfiles 20 GB 変更不可 20 GB /home 4 GB 最大 900 GB. 拡張のみ 4 GB /var 5 GB 最大 900 GB. 拡張のみ 10 GB /var/log 18 GB 最大 900 GB. 拡張のみ 30 GB /var/log/audit 3 GB 最大 900 GB. 拡張のみ 3 GB /tmp 3 GB 最大 900 GB. 拡張のみ 3 GB VMクラスタの構成 Copyright © 2025, Oracle and/or its affiliates | 45
  38. VMクラスタの構成 /u01 : Grid Infrastructure用 • GRID_HOMEパス :/u01/app/<GI Version>/grid /u02

    : Oracle Database用 • ORACLE_HOMEパス:/u02/app/oracle/product/<DB Version>/dbhome_<n> /acfs<xx> :一時ファイル置き場 • マウント済ACFS。イメージやパッチなど、 Cloud Toolの一時ファイル置き場として利用される • 移行時などのダンプファイル置き場としても利用可能 • 領域拡張方法 • ホワイトペーパー Exadata デプロイメントにおけるOracle ASMの考慮事項: オンプレミスとクラウド Exadata Cloud で のASMディスク・グループの設定 /var/opt/oracle : クラウド・ツール用 46 Copyright © 2025, Oracle and/or its affiliates | ファイル・システムのディレクトリについて
  39. VMクラスタの構成 ExaDBは複数バージョンの利用が可能。バージョンごと、DBホームごとのディレクトリが自動作成 • OS 上には作成したDBバージョンのバイナリのみインストール済 • データベースごと、もしくは複数データベース共有でDBホームを作成 47 Copyright ©

    2025, Oracle and/or its affiliates | Oracle DatabaseならびにGrid Infrastructureのホーム・ディレクトリ Database 19c : /u02/app/oracle/product/19.0.0.0/dbhome_<N> 23ai: /u02/app/oracle/product/23.0.0.0/dbhome_<N> Grid Infrastructure 19c : /u01/app/19.0.0.0/grid 23ai: /u01/app/23.0.0.0/grid 19cのDBホーム(ORACLE_HOME)を3つ作った場合 #1つ目 /u02/app/oracle/product/19.0.0.0/dbhome_1 #2つ目 /u02/app/oracle/product/19.0.0.0/dbhome_2 #3つ目 /u02/app/oracle/product/19.0.0.0/dbhome_3
  40. Exadataストレージの構成 Exadataストレージ VMクラスタごとに割り当てられるストレージ領域 • 最小 2TB • Automatic Storage Management

    (ASM) で管理 • DATA/RECO/SPARSEのディスクグループが 3 重化で作成 • ストレージ構成オプション • Exadataスパース・スナップショット機能を使用するか、 ローカル(RECO)へのバックアップを取得するかどうかを 選択 - VMクラスタ作成後の変更は不可 • 選択内容に応じ、割り当てられたストレージ容量の 中でディスクグループごとの容量の割合がきまる - 利用可能なデータベース・サイズは、 Exadataストレージの サイズではなく、その中のDATAディスクグールプのサイズ VMクラスタの構成 Copyright © 2025, Oracle and/or its affiliates | 48 構成 DATA ディスクグループ RECO ディスクグループ SPARSE ディスクグループ Exadata ストレージ上のDBバックアップ :なし SPARSE ディスク・グループ : なし 80% 20% - Exadata ストレージ上のDBバックアップ :あり SPARSE ディスク・グループ : なし 40% 60% - Exadata ストレージ上のDBバックアップ :なし SPARSE ディスク・グループ : あり 60% 20% 20% Exadata ストレージ上のDBバックアップ :あり SPARSE ディスク・グループ : あり 35% 50% 15% 参考) 3 Preparing for Exadata Cloud Infrastructure> Storage Configuration
  41. SPARSEディスク・グループ ExaDB-D の VM クラスタ 内での、データベースのスナップショット機能 • ストレージ使用量を最適化し、迅速なクローン作成 • コピーオンライト形式のスナップショット

    • 更新データのみを保持し、未更新データはマスターを参照 • Exadata 特有の機能を全て利用可能 • Exadata ハードウェア内で、スナップショットの機能をネイティブサポート • スナップショット先の領域として、SPARSEディスク・グループが必要 • 従来の DATA や RECO ディスク・グループとは異なる、SPARSE 属性のディスク・グループとグリッド・ディスクを使用 • SPARSEディスク・グループの作成はVMクラスタ作成時のみ。 また、削除は不可 49 Copyright © 2025, Oracle and/or its affiliates | Exadata スナップショット機能を利用するのに必要なディスク・グループ SPARSE DG DATA DG マスター 更新分 更新分 更新分 更新分 スナップショット
  42. Exadataストレージ VM クラスタ作成の際にディスク・グループの構成を指定 ローカル・バックアップ/SPARSE ディスク・グループ 有無により、ディスク割り当ての割合が異なる • 初期構築の割合から変更・SPARSE ディスク・グループ有無の変更は、VM クラスタの再作成が必要となる点に注意

    50 Copyright © 2025, Oracle and/or its affiliates | ストレージ・サイズ詳細(1VMクラスタの場合の最大値:参考値) 構成 Disk Group % X11M ※1つのVMクラスタに全領域を割り当てる場合 最小構成(3サーバー) 1サーバーあたり ローカル・バックアップ用にストレージを割当て:なし Exadataスパース・スナップショットのストレージ割当て: なし DATA 80 192 TB 64 TB RECO 20 48 TB 16 TB ローカル・バックアップ用にストレージを割当て:あり Exadataスパース・スナップショットのストレージ割当て: なし DATA 40 96 TB 32 TB RECO 60 144 TB 48 TB ローカル・バックアップ用にストレージを割当て:なし Exadataスパース・スナップショットのストレージ割当て: あり DATA 60 144 TB 48 TB RECO 20 48 TB 16 TB SPARSE 20 48 TB 16 TB ローカル・バックアップ用にストレージを割当て:あり Exadataスパース・スナップショットのストレージ割当て: あり DATA 35 84 TB 28 TB RECO 50 120 TB 40 TB SPARSE 15 36 TB 12 TB VM クラスタ構成時の画面 参考) 3 Preparing for Exadata Cloud Infrastructure> Storage Configuration 2025/01/09 更新
  43. Copyright © 2025, Oracle and/or its affiliates | 53 Oracle

    Exadata Database Service on Dedicated Infrastructure (ExaDB-D) サービス構成とリソース: ④データベース・ホーム/⑤データベース
  44. Copyright © 2025, Oracle and/or its affiliates | 54 複数のデータベース

    (CDB) や PDB が作成可能 • バージョンやパッチレベルが異なるデータベースごとに、DB ホーム (ORACLE_HOME) を作成 • 同一パッチレベルであれば DB ホームに共有可能 • 作成可能な数はリソース依存 • データベースとGrid Infrastructureのバージョンの関係 • バージョンの1桁目で同じかそれ以下であれば利用可能 - 例: GI 19.9.0.0 であり、データベースは 19.10.0.0 であることは可能。 GIが19cであり、データベースは 23aiであることは不可 ユースケース • 複数バージョンのデータベース環境の統合 • 検証/開発環境 • 環境内で新旧 DB ホームを保持したアップデート・アップグレード 複数のデータベースを複数のバージョン/パッチレベルで利用可能 GI 23 DB Home 19.22.0 上記構成のVM内DBホーム・ディレクトリ /u02/app/oracle/product/23.0.0.0/dbhome_1 ←23.4.0 /u02/app/oracle/product/23.0.0.0/dbhome_2 ←23.4.0 /u02/app/oracle/product/19.0.0.0/dbhome_1 ←19.22.0 /u02/app/oracle/product/19.0.0.0/dbhome_2 ←19.21.0 DB Home 23.4.0 DB Home 19.21.0 DB Home 23.4.0 Doc ID 337737.1: Oracle Clusterware (CRS/GI) - ASM - Database Version Compatibility Doc ID 888828.1: Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1) 2024/09/30 更新 *19cより古いバージョンの利用は、別途有償サービス(アップグレード・サポート契約)が必要
  45. ゲストVMのOS上のソフトウェア・バージョン Database • サポート提供中の各バージョンから選択可能 • Release : 23ai、19c - Oracle

    Database のライフタイム・サポートに準拠 - *古いバージョンの利用は別途有償サービス(アップグレード・サポート契約)が必要 • Release Update(RU): 最新+3つ前までの計 4 つの選択肢から作成可能 - セキュリティ・ポリシーに準拠 - RUの指定は、該当するRUレベルの既存のデータベース・ホームを利用するか、 新規データベース・ホームの作成で『利用可能なイメージ』もしくは『ソフトウェア・イメージ』を利用 Grid Infrastructure • 23aiもしくは19cを選択可能 (RUはクラウド上で提供されている最新RUが自動選択) Exadata ゲストバージョン(Exadata System Software(ESS)) • クラウド上で提供されている最新バージョン • VMクラスタ(ゲストVM)のESS : 25(OL8)(X9Mまでのシェイプの場合、24までのバージョンも選択可能(2026/6現在)) バージョン選択 Copyright © 2025, Oracle and/or its affiliates | 55 19 12.2.0.1 (*) 12.1.0.2 (*) 最新 1つ前 2つ前 Release RU 3つ前 11.2.0.4 (*) 23 参考) ExaDB-D上で提供されいてる最新バージョンの情報: Exadata Cloud Service Software Versions (Doc ID 2333222.1) 2025/06/24 更新
  46. DBもしくはGIのゴールド・イメージ パッチ適用済みのゴールド・イメージ作成が可能 • 複数環境/複製環境構築時など、時間を短縮 • 同一サービス内で利用可 • Data Guardのスタンバイ作成時にも利用可 •

    パッチ適用の手順の簡素化 • 個別パッチ適用をコンソールで完結 • Out-of-placeでのパッチ適用のデータベース・ ホーム作成の利用 • Object Storageのオラクル管理バケット内に保存 • コンソールから管理。自動で削除はされません • 利用可能なパッチバージョン • Oracle Cloud Infrastructureでサポートされているもの • データベース・ホームを作成するH/Wモデルでサポートされているもの • 推奨バージョン(最新もしくは3つ前まで)よりも古いものは最新のクラウド・ ツールのテストが行われていないため、ユーザー側で実機確認をしてください ソフトウェア・イメージ Copyright © 2025, Oracle and/or its affiliates | 56
  47. 23aiを利用する場合のバージョン • 新規作成 • 23aiで新規DBホーム作成 - Grid Infrastructure : 23ai

    (23.4.0以上) - Guest VMのExadata System Software : 23.1.8 以上 - Exadata InfrastructureのExadata System Software : 23.1.x 以上 • 23aiで新規VMクラスタ=Grid Infrastructure作成 - VMクラスタ作成時に23aiを選択 (2024/05現在: デフォルト19c選択) - Exadata Guest VMのExadata System Software : 23.1.8 以上 - Exadata InfrastructureのExadata System Software : 23.1.x 以上 • 既存環境のアップグレード • GI、DBともに19c(マルチテナント構成)のみアップグレード可能 - 19c以前のバージョンは、一度19cにアップグレードした上で23aiへ アップグレードが必要 • GI のアップグレード時の要件 - ASMのcompatible.rdbms パラメーター を 19.0.0.0 以降に設定が必要 ( 2024/05現在: デフォルト 11.2.0.4) - VM Cluster on a Single VM ではGIアップグレードは未サポート Exadata Database ServiceでのOracle Database 23ai Copyright © 2025, Oracle and/or its affiliates | 57 GI 23ai (ASMのcompatible.rdbms が19.0.0.0 以降) ESS 23.1.x 以上 ESS 23.1.8 以上 DB 23ai DB 23ai DB 19c Guest VM (顧客管理) Exadata Infrastructure (オラクル管理)
  48. Exadata Database Cloud Software Versions (Doc ID 2333222.1) 各種ソフトウエアバージョン確認方法 Copyright

    © 2025, Oracle and/or its affiliates | 58 2025/06/24 更新 ※2025/06時点。最新情報はDoc ID 2333222.1をご確認ください
  49. Exadata Database Cloud Software Versions (Doc ID 2333222.1) Exadata System

    Software でOCI ExaDB-D に適用可能なバージョン Copyright © 2025, Oracle and/or its affiliates | 59 ※2025/06時点。最新情報はDoc ID 2333222.1をご確認ください
  50. Copyright © 2025, Oracle and/or its affiliates | 60 対象サービス

    • Base Database Service, Exadata Database Service (Public & Cloud@Customer) サポート終了 • 基本的にオンプレミスのライフタイム・サポートに準拠して設定 (オンプレミスにおけるエラー修正終了時に、クラウドではサポート終了となり、Sustaining Supportは提供されない) • セキュリティ・パッチを含むパッチ提供を終了、新規プロビジョニングを終了 • 当該バージョンのインスタンス稼働は保証されない (速やかなアップグレードもしくはインスタンス停止を推奨) データベース・クラウドでのサポート期間 Release Schedule of Current Database Releases (Doc ID 742060.1) クラウドでの提供開始 サポート終了 (Sustaining Supportの提供なし) 11g R2 (11.2.0.4) 2014年9月 2021年3月31日 (終了済み) 12c R1 (12.1.0.2) 2014年9月 2022年7月31日 (終了済み) 12c R2 (12.2.0.1) 2017年3月 2022年3月31日 (終了済み) 18c (12.2.0.2相当) 2018年3月 2021年6月30日 (終了済み) 19c (12.2.0.3相当) 2019年1月 2032年12月31日 21c 2020年12月 2027年7月31日 23ai 2023年9月 2031年12月31日 (延長サポート期間はTBD) 2025/02/04 更新
  51. サポート終了後も当該バージョンのデータベースを実行できます か • サポート終了後、オラクルは稼働を保証しません - “These services will not be

    covered under Sustaining Support and Oracle makes no commitment that any cloud service instances will continue to run after the end of their support life (Premier, extended, error correction, or MDS).” (Release Schedule of Current Database Releases (Doc ID 742060.1)) • サポート終了後、当該インスタンスに関するSR受付は行いま せん • データベース・クラウドではSustaining Supportは提供されま せん • 速やかなアップグレードもしくはインスタンス停止を推奨します 当該バージョンのデータベースを、いつまで新しくプロビジョニングで きますか • サポート終了日まで可能です 最後のパッチバンドルはいつですか • サポート終了日までにリリースされたパッチバンドルが利用で きます • 重大度1の修正は、サポート終了日まで利用できます 新しいバージョンへはどのようにアップグレードできますか • アップグレード機能が提供されています - Base Database Service|Exadata Database Service Extended Support期間中に追加費用は必要ですか • BYOLの場合も含め、データベース・クラウドでは追加費用は 必要ありません - “Extended Support is bundled with both the license-included and BYOL versions of these services and does not require additional fees.” (Release Schedule of Current Database Releases (Doc ID 742060.1)) データベース・クラウドでのサポート期間:FAQ Copyright © 2025, Oracle and/or its affiliates | 61 2023/12/15 更新
  52. Copyright © 2025, Oracle and/or its affiliates | 62 ゲストOS上のクラウドツール(dbaascli)を利用して作成する場合、コンソールでの管理可能

    • 下記のコマンドでnon-CDB(非CDB)のデータベースを作成 • 注意: 非CDBアーキテクチャは、12c以降で非推奨、 21c以降は非サポート 参考: 『データベース・アップグレード・ガイド』 非CDB Oracle Databaseのサポート終了 コンソールから作成するデータベースと異なる構成をCLIで作成可能なケース ケース1) non-CDB(非CDB)のデータベース作成 (dbaascli) OCI Documentation ExaDB-D > dbaascli Command Reference > dbaascli database create # dbaascli database create --dbname <DB_name> --oracleHomeName <DBHome_name> --createAsCDB false
  53. Enable Unified Auditing While Creating a Database Home • Oracle

    Database 12.2以上で新規DBホーム作成時、統合監査(Unified Auditing)を有効化可能 • 23aiではデフォルト有効(従来監査が23aiから非サポート) • 12.2~19cではデフォルト無効。有効が選択可能 • 12.1以下は利用不可(従来監査) • DBホーム作成後、統合監査の無効化は不可 データベース・ホーム作成時の統合監査の有効化 Copyright © 2025, Oracle and/or its affiliates | 63
  54. Copyright © 2025, Oracle and/or its affiliates | 64 •

    データベース及びスタンバイ・データベース作成時のみdb_unique_name およびSID接頭辞が指定可能、 作成後変更不可能 ※SID接頭辞指定は12.1以降のデータベースで利用可能 db_unique_name および SID 接頭辞の指定 db_unique_name SID接頭辞 文字数 30文字以内 12文字以内 使用可能文字 英数字またはアンダースコア(_)文字のみ 英数字のみ 先頭の文字 アルファベット アルファベット その他条件 VMクラスタ全体で一意 ※テナンシ全体で一意になるようにする事を推奨 VMクラスタ内、およびプライマリ・データベースとスタンバ イ・データベース間で一意 未指定時 次のフォーマットで一意の名前が自動生成 <db_name>_<3_chars_unique_string>_<region-name> db_unique_nameの先頭12文字
  55. Copyright © 2025, Oracle and/or its affiliates | 66 バックアップを利用して、コンソールやCLI

    からデータベースの新規作成が可能 • 作成先は、バックアップ元と同一システム上でも 異なるシステム上でも、別リージョンでも可能 • ExaDB-D 以外へのリストアはツールは非対応 • 障害時の復旧、複製や移行にも利用可能 • 作成先の DB バージョンはバックアップ元の DB バージョンと同一またはそれ以上 バックアップからのデータベースの作成 Object Storage Exadata System Exadata System 2025/06/24 更新
  56. 必要な時に簡単に構築可能 バックアップからの複製 • バックアップからの新規データベース作 成をして複製 • 自動バックアップ or 任意のタイミ ングで取得したバックアップ

    • 別環境へリストア PDBクローン機能 • PDB単位の複製 • 更新可能PDBを活用し、直近の状態 (最短1分前)の本番DBの複製可能 Data Guardスナップショット・スタンバイ • スタンバイの利活用 • 常時REDO転送・適用による、直近の状態の 本番DBの複製可能 • 更新不可モード(フィジカル・スタンバイ)から、 更新可能なモードに切り替えて利用 • フィジカル・スタンバイ作成はコンソールから可 • 1コマンドでの切り替えが可能 • この間の同期は停止、REDOは転送・受信 • 使用後にフィジカル・スタンバイに戻して利用可 検証環境の構築方法 Copyright © 2025, Oracle and/or its affiliates | 67 本番 PDB ステージング PDB テスト、障害調査、 データマスキング等 ホット・クローン もしくは 更新可能PDB 想定される利用シーン • 本番データを利用したステージング環境の構築 • 障害原因調査用DBの構築 • データマスキング用データベースの作成 • バージョンアップやパッチ適用のテスト環境の構築 コンソール/APIから可能な方法 テスト環境(READ WRITE) REDO転送※1 プライマリ スナップショット・スタンバイ 2025/06/25 更新
  57. 変動キャパシティ・モデルによるコストの最適化 柔軟な拡張性 Copyright © 2025, Oracle and/or its affiliates |

    71 スケール・アウト: H/Wリソースのスケーリング(X8M以降) スケール・アップ: 割り当て済H/Wリソース内でのスケーリング 各VMクラスタに割り当てるリソースの増減 ・CPU*、メモリ、ローカル・ストレージ、ストレージ ・VM数(スケール・アウト) *課金に影響のあるスケーリング Exadata Cloud Infrastructureに割り当てるサーバー数の増減 ・データベース・サーバー*、ストレージ・サーバー*
  58. スケールアップ・ダウン(VMクラスタの拡張性)とスケールアウト・イン(インフラの拡張性)が可能 ExaDB-Dの拡張性 Copyright © 2025, Oracle and/or its affiliates |

    72 特徴 課金 データベース・ サーバー スケールアップ・ダウン (CPU、メモリ、ローカ ルストレージ) • OCPUの変更が動的(オンライン)に可能。1 OCPU×ノード数の単位。変更完 了も数分程度 • VMのメモリサイズの変更、ローカル・ファイルシステムのスケールダウンは再起 動を伴う • OCPU数に応じた課金変動 • メモリやローカルストレージの拡 張は影響なし スケールアウト・イン (VM、物理サーバー) • VMクラスタを構成するVMを追加・削除可能 • インフラのデータベース・サーバーの追加・削除がオンラインで可能 • インフラの物理サーバー数に応 じた課金変動 ストレージ スケールアップ・ダウン (Exadataストレージ) • VMクラスタを構成するExadataストレージ(ASMディスクグループ)のサイズの変 更がオンラインで可能 • ディスクグループのサイズの拡 張は影響なし スケールアウト・イン (物理サーバー) • インフラのストレージ・サーバーの追加・削除がオンラインで可能 • インフラの物理サーバー数に応 じた課金 オンラインでスケーリングが可能なことがメリットになりうるケース • 性能劣化、リソース使用率の逼迫を検知 • CPUネックの場合、OCPUスケールアップで対処可能(Dynamic Scalingを実装して自動スケーリング可) • データ量の増加によるDisk Group使用率の逼迫であれば、VMクラスタのExadataストレージをスケールアップ • 計画停止・計画外停止時 • 縮退時のパフォーマンス維持のためのスケールアップ • 通常時はスタンバイ側は最低限のリソースで運用している場合、切り替え後に再起動なしですぐにスケールアップ
  59. オンラインでのCPUスケーリングにより、トランザクションやシステムへの影響なしでコストの最適化 変動キャパシティのユースケース Copyright © 2025, Oracle and/or its affiliates |

    73 • 負荷が低くなるときにCPUコア数 減 • 夜間、週末など • 負荷が高くなるときにCPUコア数 増 • 日次/月次バッチなど • アクセス、処理量の増加によるCPU逼迫 月・曜日・日・時で 本番環境の負荷が変動するケース • テスト環境 • テスト利用時以外CPU割当てを0に • 開発プロジェクトのピーク時に、テスト環境を一 時的に増やす • スタンバイ・サイト • 平時はCPU数を絞って稼働 本番環境以外の用途で 利用状況が変動するケース 処理を継続させながらコスト最適化が可能 他の環境へ影響を与えずに 必要になった際に迅速に利用可能に
  60. ExaDB-Dの拡張性 Copyright © 2025, Oracle and/or its affiliates | 74

    • 利用可能なH/Wリソースの中から、VMクラスタ毎にリソースを割り当て可能 (オーバーサブスクリプション不可) • 後から変更不可のリソースは、 VM クラスタ作成前に十分な検討が必要 最小値 リソース変更可否 リソース変更動作 CPU 8 ECPU or 2 OCPU / VM 可 オンライン メモリ 30 GB / VM 可 VM 再起動(ローリング) ローカル・ファイルシステム領域 (次のスライド参照) 可* (次のスライド参照) Exadata ストレージ 2 TB 可** オンライン Disk Group の比率 - 不可 - ネットワーク 2つのみ(クライアント、バックアップ) 不可 - *X8M以降のみ ** スケールダウン時は現在利用しているディスク・グループ容量の 1.15 倍が最小値。 「リソース変更動作」欄は2022/12時点でExaDB-D のマニュアルにページが不足しているのでExaDB-C@Cのマニュアルより参考記載 VM クラスタのスケーリング:リソースの最小値と変更 (スケーリング) について
  61. VM クラスタのスケーリング: コンソールでの実行画面(CPU、メモリ、ローカルストレージ、Exadataストレージ) サービス構成とリソース Copyright © 2025, Oracle and/or its

    affiliates | 75 1. 『Exadata VMクラスタ』ページで『VMクラスタのスケーリング』をクリック 2.利用中のVMクラスタの各種リソースに対して適 切な値を入力して『スケール』をクリック
  62. 必要な時に必要な分だけ、オンラインでスケーリング可能 • VMクラスタごとに利用可能なCPUコア数を設定 • VMクラスタ内の全VMで同数のCPUが有効化 • コンソール、OCICLI、ツール等で変更可能 • オンライン(動的)でのCPU変更 •

    VMやDBの再起動なしで1VMずつ変更される - 処理中のトランザクションを止めることなくリソース増強 • データベースは、OS上の有効なコア数を自動検知 - デフォルト: DBの設定として、OSで利用可能なコア数を利用できる ようになっている(CPU_COUNT=0) 注意点 - インスタンス・ケージング(CPU_COUNT=n)設定をしている場合 :明 示的な設定値に基づくため、割り当てられた変更後のリソース状 態に合わせた自動変更はされないので、スケーリング後に設定が 必要 - インスタンス起動時にCPU数に基づいて自動設定されるパラメータ で自動変更されないものもあるため、スケーリング後に設定が必要 利用可能OCPU数の変更 Copyright © 2025, Oracle and/or its affiliates | 76 2024/09/26 更新
  63. 変更方法 オンデマンド変更 • コンソール/CLI/APIで即座に変更 ジョブ・スクリプトでのスケジューリング • CLI/APIでの変更操作をスクリプト化す るなど、手動設定での自動スケーリン グ可能 例)

    cronを使用してスクリプト実行 自動スケーリングの実装 • Dynamic Scalingツールを導入し、CPU 負荷やスケジュールに応じた自動ス ケーリングを実装可 • チュートリアル: 『Oracle Exadata Cloud Infrastructureでの 動的スケーリングの構成』 • 詳細/ツールのダウンロード: (ODyS) Oracle Dynamic Scaling Suite Main Index Page(Doc ID 2774779.1) 利用可能OCPU数の変更 Copyright © 2025, Oracle and/or its affiliates | 77 $ oci db cloud-vm-cluster update --cpu-core-count xxx --cloud-vm-cluster-id xxx … 23:00 OCPU 0... 5:00 OCPU 8… 2025/03/xx 更新
  64. CLIでのCPUのスケールアップ・ダウン例(OCI CLI) Copyright © 2025, Oracle and/or its affiliates |

    78 $ oci db cloud-vm-cluster update --cpu-core count <core number#> --cloud-vm-cluster-id <cloud-vm-cluster-id> 参考) Oracle cloud Infrastructure CLI Command Reference Docs » db » cloud-vm-cluster » update $ oci db cloud-vm-cluster get --cloud-vm-cluster-id xxx --query 'data.{"1.Name":"display-name", "2.shape":"shape","3.cpu-core-count": "cpu-core-count"}' { "1.Name": “<system name>", "2.shape": "Exadata.Quarter2.92", "3.cpu-core-count": 44 } $ oci db cloud-vm-cluster update --cpu-core-count 66 --cloud-vm-cluster-id xxx … $ oci db cloud-vm-cluster get --cloud-vm-cluster-id xxx --query 'data.{"1.Name":"display-name", "2.shape":"shape","3.cpu-core-count": "cpu-core-count"}' { "1.Name": “<system name>", "2.shape": "Exadata.Quarter2.92", "3.cpu-core-count": 66 } • 実行例
  65. Copyright © 2025, Oracle and/or its affiliates | 79 Exadata

    CPU • CPU スケールアップ・ダウンが可能 • CPU 数を 0 にすると仮想マシン停止+ CPU 課金停止 • 『仮想マシン停止』では課金停止にはならないので注意 Exadata Infrastructure • 利用期間中は課金対象で、終了されるまで課金継続 • Exadata Infrastructure は最低48時間。48時間未満で終了した場合も48時間分は課金 課金対象期間について 48時間未満で終了する場合→インフラは48時間課金 48時間経過後で終了する場合→終了時に課金停止 OCPU Exadata Infrastructure OCPU 作成 終了 48h CPU Scale up CPU down to 0 停止 起動 CPU Scale up OCPU Exadata Infrastructure OCPU 作成 終了 48h CPU Scale up CPU down to 0 停止 起動 CPU Scale up
  66. CPU数を0にスケールダウンする • 停止(仮想マシン停止)ではなく、CPU数を 0 にすることで CPU 課金の停止が可能 • インフラ部分はインスタンス利用中は課金継続 (ストレージ含めインフラを利用しているため)

    • 定期的な課金停止をしたい場合 • CLI での CPU スケール・ダウンをジョブ・スケジューリングするなどで対応可能 • OCICLI • REST 参考) CPU課金の停止方法(API/CLI) Copyright © 2025, Oracle and/or its affiliates | 80 $ oci db cloud-vm-cluster update --cpu-core-count 0 --cloud-vm-cluster-id <VM クラスタの OCID> REST API Documentation CloudVmCluster > UpdateCloudVmCluster Oracle cloud Infrastructure CLI Command Reference db>cloud-vm-cluster>update PUT /20160918/cloudVmCluster/<cloudVmClusterId> Host: database.<region>.oraclecloud.com <authorization and other headers> { "cpuCoreCount" : 0 }
  67. 新規VM作成時の各ファイルシステムのサイズ マウントポイント デフォルトサイズ 構成 ファイルシステムのリサイズ 以前のサイズ / 15 GB 最大

    900 GB. 拡張のみ 15 GB /u01 20 GB 最大 900 GB. 拡張のみ 250 GB /u01/../grid 50 GB 変更不可 50 GB /u02 * 60 GB 最大 900 GB. 拡張、縮小可 60 GB /acfs01 100 GB リサイズ時はオラクルサポートに連絡 100 GB /boot 509 MB 変更不可 509 MB /crashfiles 20 GB 変更不可 20 GB /home 4 GB 最大 900 GB. 拡張のみ 4 GB /var 5 GB 最大 900 GB. 拡張のみ 10 GB /var/log 18 GB 最大 900 GB. 拡張のみ 30 GB /var/log/audit 3 GB 最大 900 GB. 拡張のみ 3 GB /tmp 3 GB 最大 900 GB. 拡張のみ 3 GB Guest VMのローカル・ファイル・ストレージのスケーリング Copyright © 2025, Oracle and/or its affiliates | 81 * Oracle Home が配置されるファイルシステム。スケール・ダウン時は、全 VM の中で最も大きいローカル・ストレージ領域 使用量の 1.15 倍が最小値。
  68. Copyright © 2025, Oracle and/or its affiliates | 82 •

    インフラストラクチャーをオンラインでスケーリング可能 • データベース・サーバー: 2-32台 • ストレージ・サーバー: 3-64台 • スケーリングは、任意のタイミングで実施可能 • データベース・ホームやデータベースの作成前にスケーリングする場合 ‒ 所要時間: 1台あたり30 - 45分 ‒ 追加する台数が決まっている場合は、データベース・ホームやデータベース の作成前に実施する方がVMクラスタの更新時間を短縮可能 • データベース・ホームやデータベースの作成後にスケーリングする場合 ‒ 所要時間:データベース・ホームの数やデータ量による • 追加された容量を実際に利用するには、「インフラストラクチャをスケーリング」追加した後、その容量をVMクラスタに追 加する「VMクラスタのスケーリング」の操作が必要 ExaDB-D インフラストラクチャのスケーリング(X11M/X9M/X8M) 2025/06/24 更新
  69. Exadata Infrastructureでスケーリングしたいサー バー数を入力。インフラとして割り当て • WR完了後)Exadata Infrastructureの中に はまだ組み込まれていない(詳細ページでも サーバー数や容量は増えていない) Exadata Infrastructure

    詳細ページの上部に表 示される「ストレージ容量追加」のボタンをクリック • 下記の処理により、時間を要する • Exadataに組み込み • Guest OSから見えるようになる • Grid diskが作成され、ASMから見え るようになり、リバランスが走る • WR完了後) Exadataリソースの値に追加 され、利用可能なストレージ容量として表 示される。VMクラスタには未割り当て 対象のVMクラスタの詳細ページにて「VMクラス タのスケーリング」でストレージ容量追加 • 下記の処理により、時間を要する • ASMのDisk Groupに追加され、リバラ ンスが走る • WR完了後) VMクラスタに割り当てられてい るDisk Groupの容量に組み込まれる ExaDB-D: ストレージ・サーバーの追加とVMクラスタへの容量割り当て Copyright © 2025, Oracle and/or its affiliates | 83 Step 1 Exadata Infrastructureのスケーリング Step 2 Exadata Infrastructureのストレージ容量追加 Step 3 VMクラスタのスケーリング Exadata Infrastructureのスケーリング VMクラスタのスケーリング 2025/06/24 追加
  70. データベース・サーバー/ストレージ・サーバーの削除(スケール・ダウン) • インフラストラクチャで追加済みのサーバーの削除 • 最小構成より少ない台数へのスケーリングは不可 • 前提 • データベース・サーバー -

    対象サーバーがVMクラスタで使用されていない状態 • 対象サーバー上にVMが存在しない状態にするために、 事前にVMクラスタのメンバーからの削除が必要 • ストレージ・サーバー • 削除することにより、Exadataストレージの合計サイズが 使用しているサイズを下回る場合は実行不可 • CPU=0のVMクラスタがある場合は実行不可 • ストレージ・サーバーが5台以下でSPARSEディスク・グループ があるVMクラスタがある場合、ストレージ・サーバーの削除が 不可(該当VMクラスタを削除することで対応可) ExaDB-D インフラストラクチャのスケーリング(X11M/X9M/X8M) Copyright © 2025, Oracle and/or its affiliates | 84 2025/06/17 更新
  71. Exadata Database Serviceであれば高可用性構築の環境がすぐに利用可能 全てのコンポーネントが多重化、自己復元機能を搭載 • Real Application Clusters & Oracle

    Clusterware : DBのクラスタリング • Service : データベース・サービスを複数ノード上で抽象化 • SCAN Listener : 接続サービスをクラスタレベルで抽象化 • Automatic Storage Management : 堅牢な共有ストレージ管理 • 内部ネットワーク : Active-Active RoCE ファブリック 様々な可用性機能がデフォルトで有効 • データ保護のためのチェック機能: ブロック破損や書き込み欠損のチェック • Flashback Database : バックアップのリストアよりも短いRTOでの復旧 可用性構成を簡単に構築可能 • RMAN: Oracle Databaseを安全に確実にリストアするためのバックアップ機能 • Zero Data Loss Autonomous Recovery Service : 短いRTO/RPOでの復旧 • Active Data Guard: 参照利用*可能で自動修復*を備えたDBレプリケーション機能 Exadata Database ServiceのSLA/SLO : 99.95% Oracle Databaseの高可用性プラクティスが詰まったExadata Copyright © 2025, Oracle and/or its affiliates | 86 SLA: https://www.oracle.com/jp/cloud/sla/ SLO: https://docs.oracle.com/ja-jp/iaas/Content/General/Reference/servicelevelobjectives.htm Oracle Clusterware Real Application Clusters Service Automatic Storage Management SCAN Listener デフォルトで各コンポーネントが冗長化
  72. Exadata Database Serviceの組み込みの高可用性機能 ExaDBを利用することで高用性を高めることが可能 Copyright © 2025, Oracle and/or its

    affiliates | 87 ネットワーク障害の高速な検出 cellsrvシャットダウン時の冗長性保護 インスタンス・リカバリ時の一時停止の短縮 ILOMハングの検出および修復 セル・シャットダウン時の冗長性保護 I/Oエラー破損時における自動ASMミラー読取り Exadataディスク・スクラビング およびASM破損修復によるI/Oエラー回避 Exadata HARD HARDサポートによる破損回避 ドライブ障害誤検出の排除 電源停止時の冗長性チェック 取り外しOKを知らせる青色LED通知 BBUのドロップと交換 アプライアンス・モードのサポート セル・アラートのサマリー フラッシュとディスクのライフサイクル管理のアラート 自動ディスク管理 優先順位リバランスのサポート EM障害レポート データベース・サーバーに対する障害モニタリング patchmgrによるデータベース・ノードの更新 最適化、高速化されたExadataパッチ適用 セル・アラート用カスタム診断パッケージ VLANのサポートおよび自動化 アクティブ/アクティブRoCEネットワーク Exadataスマート・ライトバック Exadata スマート・フラッシュ・ロギング 最速のREDO Applyとインスタンス・リカバリ フラッシュ障害後の効率的なリシルバ・リバランス 読取りおよび書込みにおけるI/O待機時間制限 セルI/Oタイムアウトしきい値 Smart Write Back Flash Cache永続性 I/Oおよびネットワークのリソース管理 障害と断定されるディスクのヘルス要素 ディスクの拘束 I/Oハングの検出および修復 ディスク修復時におけるセルからセルへのオフロード セル間のリバランスによるフラッシュ・キャッシュの保持 柔軟性のあるExadata構成 ハード・ディスクのドロップと交換 ディスク取り外しのための自動LEDサポート 自動オンライン EXAchkによるフル・スタック・ヘルス・チェック(重大な問題のアラートあり) セル間のリバランスによるデータ・アクセラレータ・キャッシュの保持 コントローラ・キャッシュ障害からの自動修復
  73. スケール・アウトおよびライフサイクル データ保護 Oracle Maximum Availability Architecture(Oracle MAA) 停止が許されないデプロイメント向けに標準化されたリファレンス・アーキテクチャ Copyright ©

    2025, Oracle and/or its affiliates | 88 リファレンス・ アーキテクチャ デプロイメントの選択肢 高可用性(HA)機能、 構成、運用方法 顧客インサイトと専門家からの推奨事項 本番サイト レプリケートされた サイト レプリケーション 汎用システム エンジニアド・システム BaseDB、ExaDB/ExaCC Autonomous DB フラッシュバック 継続的な可用性 アプリケーション・ コンティニュイティ エディションベースの 再定義 アクティブ・レプリケーション RAC Globally Distributed Database FPP 24時 間 /365 日 オンライン 再定義 Zero Downtime Migration(ZDM) Bronze Silver Gold Platinum ZDLRA+ ZRCV RMAN Active Data Guard GoldenGate Full Stack DR
  74. RTO/RPO要件に応じて計画停止/計画外停止を考慮した構成を検討 高可用性構成 Copyright © 2025, Oracle and/or its affiliates |

    89 ✓RAC構成で DBバックアップ取得 ✓DBシステム冗長構成 ✓複数スタンバイ構成 ✓複製サイトの複数レプリカ構成 ケース1 定期メンテナンス許容可能 + 大規模障害時のRTO/RPOが バックアップ・リストアで満たせる ExaDB x1 + DBバックアップ ケース2 計画停止や計画外停止の DB停止時間を短くしたい。 大規模障害のためのDR保持 ケース3 計画停止時やExaDBインフラ上の障 害時の切り替えを短く、 大規模障害にも対応したい ケース4 大規模・多重障害時も含めRPO/RTO を ゼロに近づけたい ExaDB x2 (同一or別リージョン) +DBバックアップ ExaDB x3 (同一&別リージョン) + DBバックアップ ExaDB x4 (同一&別リージョン) + DBバックアップ RAC on Exadata Region #1 Region #2 DBバックアップ DBバックアップ プライマリ Region #1 Region #2 DBバックアップ DBバックアップ スタンバイ Data Guard(DG) ローカル・ スタンバイ Region #1 Region #2 DBバックアップ リモート・スタンバイ Data Guard(DG) プライマリ Region #1 Region #2 DBバックアップ Data Guard(DG)/GoldenGate(GG) DG DG/GG DBバックアップ DBバックアップ DBバックアップ DBバックアップ DG/GG DBバックアップ
  75. 自動データベース・バックアップ データベース・バックアップの自動取得が設定可能 • 取得先 : 自律型リカバリ・サービス(デフォルト) or Object Storage •

    設定に基づき、特定の時間に日次で自動で取得される - バックアップ・ジョブの開始時間帯(UTC)や完全バックアップの曜日を指定可能 - 最初のバックアップは即時作成することを推奨 • バックアップは全て暗号化 • 取得先の変更可 • Data Guard構成のプライマリでもスタンバイでも取得可 前提条件 • バックアップ取得先へのアクセスが可能なIAMポリシー・ネットワークの設定 91 Copyright © 2025, Oracle and/or its affiliates | Oracle Managed Backups(推奨) 取得先 頻度と種類 保持期間 推奨 自律型リカバリ・サービス (Autonomous Recovery Service) ・初回フル(Level 0) ・永久差分増分(Level 1) ・Oracle定義(14/35/65/95日)もしくはユーザー定義の保護ポリシーから選 択(デフォルトSilver 35日) ・長期バックアップをObject Storageに保持可能(90日-10年) Object Storage (オラクル管理バケット内) ・週次フル(Level 0) ・日次差分増分(Level 1) 7/15/30/45/60日から選択 (デフォルト30日) 2025/6/24 更新
  76. 自律型リカバリ・サービス(Autonomous Recovery Service(RCV/ZRCV)) • 2つのモードから選択 • リアルタイム・データ保護無効 (RCV) - デフォルトの設定

    - 対象DBバージョン: 19.16 or 21.7 以上 • リアルタイム・データ保護有効 (ZRCV) - REDOログをほぼリアルタイムに転送するため、データ損失を限りなくゼロに することが可能。チェックボックスにチェックを入れると有効化 - 対象DBバージョン: 19.18 or 21.8 以上 • 保護ポリシー:14日間から95日間で設定可能 • Oracle定義の4種類のポリシー、もしくはユーザー定義のポリシーから選択 • ユーザー定義ポリシーは、事前に自律型リカバリ・サービスのコンソール もしくはAPIで設定 • 長期バックアップ(最大10年)や任意のタイミングのバックアップを作成することも可能 自動データベース・バックアップでの推奨の取得先 Copyright © 2025, Oracle and/or its affiliates | 92 OCI Documentation Database Autonomous Recovery 2025/6/24 更新
  77. 保存先によるバックアップ・リストアの違い バックアップ(自動) ・初回フルバックアップ(L0)を取得後、日次で差分増分バックアップ(L1)のみのため、バックアップ取得時 間の短縮と負荷軽減 ・30分毎にアーカイブREDOログのバックアップ ・リアルタイムデータ保護を利用した場合、オンラインREDOログの常時転送 ・初回フルバックアップ(L0)を取得後、日次で差分増分バックアップ(L1)と週次で フルバックアップ(L0) ・30分毎にアーカイブREDOログのバックアップ リストア・リカバリ

    ・仮想フルバックアップ(L0)+アーカイブREDOログのため高速(RTO) ・リアルタイムデータ保護(ZRCV)の場合、上記+オンラインREDOログ ・フルバックアップ(L0)+差分増分バックアップ(L1)+アーカイブREDOログ RPO ・オンラインREDOログも使用不可の場合、障害発生前の数時間以内(オンラインREDOログが利用可 能であれば、障害発生直前まで) ・リアルタイムデータ保護(ZRCV)の場合、障害発生直前まで ・オンラインREDOログも使用不可の場合、障害発生前の数時間以内 (オンライ ンREDOログが利用可能であれば、障害発生直前まで) ランサムウェア 対策 ・バックアップの暗号化 ・犯人から見えない領域でバックアップを作成・保持 ・(ZRCVの場合)オンラインREDO利用不可の場合でも、破壊直前までのデータを復旧 ・バックアップデータの破損チェックにより完全性を担保 ・バックアップの暗号化 自動データベース・バックアップ Copyright © 2025, Oracle and/or its affiliates | 93 自律型リカバリ・サービス (Autonomous Recovery Service(RCV)/ Zero Data Loss Autonomous Recovery Service(ZRCV)) Object Storage … リストア L0 L0 L1 L1 L1 L0 L1 L1 アーカイブREDOログ ......... リストア 仮想フルバックアップで高速リストア 初回フルバックアップ + 永久差分増分 L0 アーカイブREDOログ (ZRCVの場合)オンラインREDOログ (ZRCVの場合)RPO:障害発生直前 L0 L1 L1 L1 推奨 2025/6/24 更新
  78. 参考情報 Oracle Database Zero Data Loss Autonomous Recovery Service サービス概要

    https://speakerdeck.com/oracle4engineer/zrcv-overview • 概要、価格 • バックアップ取得とリストアの仕組み • コンソール・イメージ など 自動バックアップのコスト比較 リカバリ・サービス(RCV/ZRCV)とオブジェクト・ストレージ https://speakerdeck.com/oracle4engineer/rcvzrcv-objectstorage • 取得先の種類と仕組み • 見積もり方法 など 94 Copyright © 2025, Oracle and/or its affiliates | 詳細な情報は下記公開資料をご参照ください
  79. 任意の時点でバックアップを取得可能 • コンソール or APIから実行可能 - バックアップの取得先がObject Storageの場合:完全バックアップ(Level 0 フルバックアップ)

    - 自律型リカバリ・サービスの場合は増分バックアップ(Level 1)でバックアップを作成 • スタンドアロン・バックアップとして長期保存が可能(自動バックアップの保持期限の対象外) • ユースケース : 計画メンテナンスの前、データベース削除の前、環境複製時など - Object Storageにバックアップを取得している場合、自動バックアップで取得されているフル・増分バックアップからリストアするのに比べて、リストア時間 の短縮が見込める Oracle Managed Backups(推奨) オンデマンド・バックアップ Copyright © 2025, Oracle and/or its affiliates | 95 OCI Documentation Exadata Cloud Service > Managing Exadata Database Backups OTN連載 : もしもみなみんがDBをクラウドで動かしてみたら 第20回 自動バックアップが有効(自律型リカバリ・サービス) 自動バックアップが有効(オブジェクト・ストレージ)
  80. • バックアップ保存先に、自律型リカバリ・サービスを利用する場合、 最長10年までの長期保管用バックアップ作成が可能に • コンプライアンスや法令要件への対応が、データベースへの負荷 を最小に多くのコストをかけることなく簡単に実現 • 指定可能な保存期間: 90日から10年 -

    これまでのバックアップの最大保存期間は95日 • 自律型リカバリ・サービスで取得しているバックアップ から作成し、Object Storageに保存されるため低コスト • LTRからの新規データベース作成(リストア)可能 - 対象CDBに含まれる、すべてのPDBもしくは一部のPDBで選択可 SKU • Object Storage Standard- ¥3.9525 GB/月 (24H分) • Object Storage Infrequent Access - ¥1.55 GB/月 • Database Backup Cloud - ¥0.7905 GB/月 最長10年までの長期保管用バックアップ 長期バックアップ保存(LTR) Copyright © 2025, Oracle and/or its affiliates | 96 マニュアル) https://docs.oracle.com/en/cloud/paas/recovery-service/dbrsu/longtermbackup-LTR-recoveryservice.html 既存バックアップ Object Storage Standard Object Storage Infrequent Access 24H 2025/06/24追加
  81. データベース終了後も保持*されるスタンドアロン・バックアップ ExaDB-D 中長期的なバックアップ保持の方式 Copyright © 2025, Oracle and/or its affiliates

    | 97 操作・ 管理 概要 保持期間 取得先/SKU バックアップか らの環境作成 補足 コン ソール /API オンデマンド・ バックアップ (スタンドアロン・ バックアップ) (自律型リカバリ・サービスを利用してい ない場合のみ) 任意のタイミングで作成したバックアッ プを、Object Storageにて保持 削除 するまで ・Object Storage Standard(Oracle管理) ・Database Backup Cloud コンソール/ API ・自律型リカバリ・サービスを利 用している場合は、保持期間 に基づき削除される 長期保存バック アップ(LTR) (自律型リカバリ・サービスを利用してい る場合のみ) 任意のタイミングで作成したバックアッ プを低コスト保持 LTRの保持期 間に基づく (最大10年) ・Object Storage Infrequent Access (Oracle管理) *最初の24HはObject Storage Standard ・Database Backup Cloud コンソール/ API CLI (手動) 自動バックアップ の複製 mv2bucketツールを用いて、Object StorageのOracle管理バケットからユー ザー管理バケットへバックアップファイル をコピー 削除 するまで Object Storage (ユーザー管理) 手動 ・自動バックアップ(Oracle管理) との併用は非サポート ・Object Storageの機能(別リー ジョンへのコピーなど)も利用可 能 ユーザー 手動バックアップ 例1. dbaascliツールを用いて、任意の 場所へバックアップを取得 例2. RMANコマンドでのバックアップ 削除 するまで Object Storage (ユーザー管理)など 手動 ・自動バックアップ(Oracle管理) との併用は非サポート ・Object Storageの機能(別リー ジョンへのコピーなど)も利用可 能 *自動バックアップにて取得されたバックアップは、データベース終了後、 72時間もしくは保持期間まで保持したのちに削除される 2025/06/24追加
  82. Oracle Managed Backups(推奨) • リストア可能な期間内での、任意のポイントへリストア可能 • CDB単位: 最新にリストア / タイムスタンプにリストア(時間指定)/システム変更番号(SCN)にリストア

    • PDB単位: 最新にリストア / タイムスタンプにリストア(時間指定) • Data Guard構成で取得されたバックアップのリストア • 自律型リカバリ・サービスの場合は、取得元とリストア先のDBロールが異なっても リストア可能 • Object Storageの場合は、取得元とリストア先のDBロールが同一の場合のみリストア可能 • バックアップを利用した新規DB作成にも利用可能 • 別環境へのリストア、複製、移行などで活用 • 同一/別VMクラスタ上、同一/別リージョンの別Exadataインフラストラクチャ上、 同一セキュリティ・ゾーン内 - 自律型リカバリ・サービスの場合、バックアップがあるVCNと新規DB作成先の VCNで通信ができる状態であること 参照 データベースのリストア・リカバリ Copyright © 2025, Oracle and/or its affiliates | 98 OCI ドキュメント: コンソールを使用したデータベースのリストア 2024/09/30 更新 2025/06/24更新
  83. • 自動バックアップを有効にしている際に、RMANコマンドを利用したRMAN設定の変更は非推奨 • バックアップ処理実行中に、可用性を妨げる操作(パッチ適用など)を実行しないことが推奨 • バックアップが失敗した場合、自動バックアップは次回のバックアップ・ウィンドウで再試行されるため、バックアップが取 得されていない時間帯でのデータロスの可能性がある • 手動バックアップを設定する場合 •

    自動バックアップとの併用は非推奨のため、自動バックアップは無効に設定 • アーカイブ・ログの自動バックアップ・ジョブの設定を無効化 - OCI ドキュメント 手動バックアップおよびリカバリ管理を容易にするための自動バックアップの無効化 自動バックアップ設定に関する推奨事項 Copyright © 2025, Oracle and/or its affiliates | 99
  84. 方式検討 下記の順で推奨 1. コンソール もしくは API (ExaDB-Dのデフォルト)(Oracle Managed Backups) •

    コンソールからのバックアップ管理が可能 • OCIの他のサービスとの連携などが可能 - 例) イベント・通知サービスなどでバックアップイベントの通知 2. dbaascli database backup (旧bkup_api) (User Configured Backups) • 1の手法で対応していないケースで、dbaascli database backupでなら可能なものなど - 例)他リージョンへのレプリケーションをするためにOSS bucket へのバックアップの実施。 ExaDB-Dシステム(筐体)内へのバックアップ取得など • コントロールプレーンと同期されない 3. RMANを直接使ったバックアップ • お客様のRMANスクリプトでの実施。非推奨 • 顧客管理の手動バックアップ・ジョブと競合しないために、デフォルト有効のクラウド管理バックアップ機能の無効化が必要 - OCI ドキュメント 手動バックアップおよびリカバリ管理を容易にするための自動バックアップの無効化 注意事項 • 上記手法の混在はサポートされません。混在(併用)した場合、自動バックアップ処理が中断されます Exadata Database Serviceのデータベースのバックアップ Copyright © 2025, Oracle and/or its affiliates | 100
  85. バックアップ考え方によって、取得先や取得先による設定方式を検討 Exadata Database Serviceのデータベースのバックアップ Copyright © 2025, Oracle and/or its

    affiliates | 101 ケース1 ExaDB-Dシステム内に取得 ケース2 同一AD内の別サービスに取得 ケース3 バックアップを別リージョンに複製 方式 dbaascli 推奨 コンソール/API dbaascli バックアップ取得先 ExaDB-Dシステム内(Exadata筐体内の RECO) 同一AD内の自律型リカバリ・サービス or Object Storage(オラクル管理) 同一AD+別リージョンのObject Storage(顧客管理バケット) 特徴 ・RECOを利用するので、その分DATA領域 を小さく or ストレージ・サーバーを増やす ため、利用するケース2や3よりコスト高の 可能性あり ・リストア時間(RTO)が短い* ・サービス・インスタンス(筐体)以上の範囲 の障害時に復旧できないリスク → dbaascliでObject Storageと両方に取得 する設定で対応。その場合、ケース3も設 定可能 ・コンソール/API方式との併用不可 ・コンソール/APIから管理・操作が可能の ため推奨 ・リストアや環境複製など、コンソール/API から簡単に実行 ・OCIの他のサービスとの連携(通知など) ・リージョン障害などの大規模障害に復 旧できないリスク→Data Guard構成をとる ことで対応 ・自律型リカバリ・サービスを利用する場 合、ランサムウェア対策などセキュリティ向 上 ・大規模障害への対応 ・Object Storageのレプリケーション機能を 利用し、別リージョンにもバックアップを保 持 ・コンソール/API方式との併用不可 2025/04/28 更新 *自律型リカバリ・サービスを利用した場合はリストアの考え方が異なる(リストアが早い実装)ため、ケース1の方がRTOが早くなるとは限らない 可用性 復旧(リストア)時間*
  86. User Configured Backups dbaascliを利用し、事前に用意したObject Storageのバケット、もしくはExaDB-D内のローカル・ストレージ(RECOディスク・グ ループ)への自動バックアップ取得設定可能 • 自動バックアップ設定方法 • 事前に設定ファイルを用意(/var/opt/oracle/ocde/assistants/bkup/<構成ファイル名>.cfg)

    - 取得先 (Object Storageのみ、ローカル・ストレージのみ、両方のいずれか)、保存期間、Object Storageの場合はアクセス情 報など • 自動設定対象のDBに対して設定を有効化 • オンデマンド・バックアップ取得 • 自動バックアップと同様の形式で、オンデマンド・バックアップ取得 既存のObject Storageバケット内やRECOへの自動バックアップ取得設定 Copyright © 2025, Oracle and/or its affiliates | 102 # dbaascli database backup -–dbname <DB_name> --configure -–configfile <configfile_pass> # dbaascli database backup --start -–dbname <DB_name> マニュアル Exadata Database Service on Dedicated Infrastructure dbaascliコマンド・リファレンス dbaascli database backup
  87. User Configured Backups • オンデマンド・バックアップ取得 : コマンド例 • 自動バックアップと同様の形式でバックアップ取得 •

    特定のPDBのバックアップ • データベース全体を削除するまで存続できる長期バックアップ • レベル0バックアップ • レベル1バックアップ 既存のObject Storageバケット内やRECOへの自動バックアップ取得設定 Copyright © 2025, Oracle and/or its affiliates | 103 # dbaascli pdb backup –-dbname <DB_name> --pdbname <pdbname> -–start # dbaascli database backup -–dbname <DB_name> --start # dbaascli database backup –-dbname <DB_name> –-start --archival –-tag <tag> # dbaascli database backup -–dbname <DB_name> --level0 –-start # dbaascli database backup -–dbname <DB_name> --level1 –-start マニュアル Exadata Database Service on Dedicated Infrastructure dbaascliコマンド・リファレンス dbaascli database backup
  88. ExaDB-DのOS領域のバックアップ・リストアはどのように実施すれば良いでしょうか? • 仮想マシンのOSバックアップはCloud Operationsチームが定期的に取得(週1回)、起動できない場合はこのバック アップからリストアを実施(SR対応) • OS部分に何か追加設定をしている場合には、 LVMスナップショットによるバックアップと、tarコマンド等によるファイルバッ クアップを併用いただくことを推奨 •

    LVMスナップショットはOS(domU)が再起動可能な状態の場合のみリストア可能なので、併用を推奨 • NFSマウント頂いた領域に出力可能 参考) Exadata Cloud Compute Node Backup and Restore Operations (Doc ID 2809393.1) Computeノードのシステムバックアップ・リストア(ExaDB-D) Copyright © 2025, Oracle and/or its affiliates | 104
  89. Copyright © 2025, Oracle and/or its affiliates | 105 可用性構成

    データベースの冗長構成 : Data Guard/Active Data Guard
  90. レプリカDBをData Guardで構成することのメリット Exadata Database Cloudのレプリカ構成 Copyright © 2025, Oracle and/or

    its affiliates | 106 • 自動データ同期によるデータ保護・ 計画外停止時の迅速な切り替え • ブロック破損コピーの防止 • 自動ブロック破損修復 • 切り替え後に壊れた旧プライマリを 簡単に復旧 • 参照系処理のオフロード • (19c-)更新処理も可能に • 普段から利用することによるレプリカ 側のデータ正常性の確認 • スナップショット・スタンバイに一時的 に切り替え検証利用 • 計画停止時のサービス継続 • 有事の切り替えに備えた正常性確認 • 定期的な切り替えを推奨 Primary Standby 同期 迅速な切り替え Primary Standby 同期 Primary →Standby Standby → Primary 計画停止のお知らせ 週末 22:00-08:00 データ保護(DR) リードレプリカ/検証 メンテナンス切り替え
  91. Data Guard構成をコンソール/APIから構築・管理 • 同一/別リージョン間での、別のVM クラスタへのDBレプリケーション • 同一DBバージョン間 • フィジカル・スタンバイを6つまで管理可能 •

    管理のためにData Guard Brokerが有効 • Active Data Guard/Data Guard の選択・切替可能 • DGロールの切り替え、フェイルオーバー後の回復などを1クリックで実行 • 上記の構成外の場合、手動でData Guardを構築も可能 • 7つ以上のスタンバイ、 フィジカル・スタンバイ以外など • 参考 : Oracle Data Guard ハイブリッド・構成 Data Guardグループ Copyright © 2025, Oracle and/or its affiliates | 107 ExaDB ExaDB リージョン 別VMクラスタ 別リージョン リージョン ExaDB 別ExaDB OCI Documentation Exadata Cloud Service> Using Oracle Data Guard with Exadata Cloud Infrastructure OTN 連載もしもみなみんがDBをクラウドでうごかしたら第19回 DBの可用性を高めよう - Data Guard編 (DBCS/ExaCS) Oracle Patch Assurance - Data Guard Standby-First Patch Apply (Doc ID 1265700.1)
  92. 複数のスタンバイを保持することにより、データ保護・柔軟性・ROIを向上 1つのプライマリ・データベースに対して、最大6個までスタンバイ・データベースが作成・管理可能 • データ保護の向上 : ローカルおよびリモートでスタンバイを保持し、様々なケースの障害 からデータを保護 • 柔軟性の向上: 地理的に複数の異なる場所に配置してデータ保護を強化し、必要に

    応じてスナップショット・スタンバイ(書き込み可能)を利用した汎用性の向上 • ROIの向上: 特定のスタンバイ・データベースで、処理のオフロードおよびスケールアウト • Oracle Database 19c以上 • 手動で構築した2個目以降のスタンバイ・データベースが既にある場合、Data Guardグループに追加したい場合はクラウド・ツールを利用し た再構築が必要 • (2025/1/22)本機能のリリースに伴い、Data Guard管理機能が新しいAPIに • 従来名称『Data Guardアソシエーション』→新名称『Data Guardグループ』 • 既存環境で本機能を利用する場合、新しいAPIの『Data Guardグループ』への変更が必要 • 現時点では従来の『Data Guardアソシエーション』のAPIもサポート。今後、事前通知をした上で非推奨予定 Data Guard 複数スタンバイ・データベース構成 Copyright © 2025, Oracle and/or its affiliates | 108 参考) チュートリアル: ExaDB-DおよびExaDB-C@Cの複数のスタンバイ・データベースの作成 2025/2/4 更新
  93. Data Guardの複数スタンバイ・データベース構成サポートの機能リリースに伴う、新しいAPI Data Guard管理の新しいAPI: Data Guardグループ Copyright © 2025, Oracle

    and/or its affiliates | 109 従来『Data Guardアソシエーション』 →『Data Guardグループ』 従来: 対(ピア)のデータベースのみ表示(プライマリ側にはスタンバイ、スタンバイ側にはプライマリ) →プライマリ・データベースの情報やリージョンも表示され、Data Guard構成全体の管理性向上 2025/2/4 更新
  94. 従来APIの『Data Guardアソシエーション』で管理している環境の、新APIの『Data Guardグループ』への変更 Data Guard管理の新しいAPI: Data Guardグループ Copyright © 2025,

    Oracle and/or its affiliates | 110 『Data Guardアソシエーション』に対するAPIと『Data Guardグループ』に対するAPI は異なるため、CLIでの運用をしている場合はCLIの内容の変更が必要 2025/2/4 更新
  95. APIの変更 • 『Data Guardグループ』のAPI • https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/ecs-using-data- guard.html#GUID-F52705B4-8396-40F5-8148-40EBF9BFB6FA • 従来の『Data Guardアソシエーション』のAPI

    • https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/ecs-using-data- guard.html#GUID-76913DF6-8BFA-4843-981F-A71C9F50D4A1 Data Guard管理の新しいAPI: Data Guardグループ Copyright © 2025, Oracle and/or its affiliates | 111 2025/2/4 更新
  96. ExaDBでData Guard 構成を検討する際に確認すること Copyright © 2025, Oracle and/or its affiliates

    | 112 Data Guardが利用可能な構成か Data Guard(フィジカル・スタンバイ)前提条件 • プライマリとスタンバイで一致させる必要があるもの • Oracle Databaseのパッチレベル • データベース構造 (例:CDB構成かNon-CDB構成か) • オプション機能のライセンス 参照) MOS Doc ID 2183849.1、 Doc ID 413484.1 GoldenGateは異機種間レプリケーションが可能な製品 • ただし、フィジカル・レプリケーションではなく、 レプリカ先もActive(更新可能)であり非同期のため データ保護を目的として使う場合にデータ差分を 防ぐ仕組みは必要 別のソリューション検討(GoldenGateなど) 自動Data Guard機能が利用可能な構成か 自動Data Guard機能の前提条件 • Oracle Cloud Infrastructure内 • 異なるVMクラスタ間 • 同一コンパートメント内、同一DBバージョン間 • 管理可能なフィジカル・スタンバイは6つまで 手動Data Guardを検討 • OnP、他OCIサービス、他社クラウド間など • 手動Data Guard構成の場合、Data Guardの管理も 手動で従来の方式を利用 参照) Oracle Data Guard ハイブリッド・クラウド構成 YES NO NO 2025/6/24 更新
  97. 手動Data Guard構築のケース Copyright © 2025, Oracle and/or its affiliates |

    113 • Cloud環境同士の手動Data Guard – 自動構成の前提条件以外の構成でのData Guard – Multicloudの別クラウドとのData Guard • オンプレミスとのHybrid Data Guard – クラウド環境のインフラ管理はオラクル – 動的CPUスケーリングによる必要な時だけ必要な分のコスト 削減 Customer Datacenter Compartment Region Exadata System Compartment Exadata System DB System 別コンパートメント間 別サービス間 OnPや他クラウドと Hybrid DG 2025/6/24 更新
  98. スイッチオーバー • メンテナンスなど計画定期に行うロール変換 • 各データベースが正常にオープン(またはマウント)さ れ、データが完全に同期をとれている場合に実施 可能 • 切り替え後もData Guardとして継続運用やロール

    を戻す(スイッチバック)ことが可能 フェイルオーバー • 障害発生時など主に計画外停止で行うロール変換 • プライマリ・データベースが停止した状態 • 最大保護モード以外はデータ損失可能性あり • 旧プライマリは、スタンバイ・データベースとして再作 成が必要 Data Guardの切り替えの種類 Copyright © 2025, Oracle and/or its affiliates | 114 Primary Standby → Primary Primary →Standby Standby → Primary
  99. • フェイルオーバー後、旧プライマリはData Guard構成か ら外れるため、スタンバイがない状態 • フェイルオーバーは、主に旧プライマリが利用できな い状態(壊れた状態)の際にスタンバイに切り替え がされるため、旧プライマリはData Guard構成から はずれる

    • 「回復」機能でコンソール上から簡単に、旧プライマリを スタンバイとしてデータベースを回復させてData Guard 構成を再編成可能 • Flashback Databaseの機能を利用した仕組みで、 Data Guard Brokerによってワンコマンドで実行され る • Flashback Databaseによって回復できない状態の 場合は、別途再構築 旧プライマリの回復 Copyright © 2025, Oracle and/or its affiliates | 117 Primary Standby → Primary ①プライマリで障害発生、フェイルオーバー ②旧プライマリをFlashback Databaseで障害発生前の 時点に復旧 Primary ③復旧後、スタンバイとしてData Guard構成へ追加。 過去時点に戻った分のデータ差分は自動で同期 Primary Standby 同期 ②と③をコンソール/CLIから簡単に実行できる
  100. Copyright © 2025, Oracle and/or its affiliates | 120 アプリケーション・スタック全体のためのDR

    インフラストラクチャからアプリケーションのための 統合された、1回のクリックで管理できるDR Automated discovery • 自動で相互依存のリソースを見つけ、 カスタマイズされたDR計画を作成 • 一元管理を提供 • 統合されたUI/APIによる DR計画の検証と実行の監視 OCI Full Stack Disaster Recovery (FSDR) Standby OCI Region Application Application Oracle Database Infrastructure Block Storage Object Storage Virtual Machine Load Balancer Base Database Service Autonomous Database Exadata DB Service File Storage Application Application Primary OCI Region Application Oracle Database Infrastructure Block Storage Object Storage Virtual Machine Load Balancer Base Database Service Autonomous Database Exadata DB Service File Storage Application Application Application DNS Full stack DR orchestration (Autonomous) Data Guard Storage replication
  101. 管理範囲 Exadata Database Service Copyright © 2025, Oracle and/or its

    affiliates | 122 お客様のコントロール • データベース • データ、スキーマ、暗号化鍵はお客様が全て保有 • データベース管理・構成変更 • DB、Grid Infrastructure、VMをCloud Automation (UI/APIs)で管理 • お客様がroot権限を持ち、仮想OS以上を監視・管理 • メンテナンス作業・判断はお客様 • DB、Grid Infrastructure、OS(Exadata System Software)のアップデート・アップグレード • OS上のクラウド・ツールは自動アップグレード(手動も可) • オラクルの運用スタッフはお客様VMにアクセスできない オラクルが管理とコントロール • ハイパーバイザ、DB/コンピュートサーバー、ストレージ・サーバー、内部ネットワーク等 • パッチ適用、セキュリティスキャン、セキュリティアップデート(四半期メンテナンス) • 重要セキュリティアップデート(月次セキュリティメンテナンス) • モニタリングとメンテナンス、セキュリティ・スキャン • お客様はアクセスできない • メンテナンス作業はオラクル。お客様は実施タイミングのある程度の制御は可能 • オラクルが全問題に対処 Hypervisor Guest VM Databases Data/Schema Grid Infrastructure OS HW Data Center お 客 様 管 理 オ ラ ク ル 管 理
  102. Exadata Database Service のメンテナンスの種類 Firmware OS Exadata System Software ストレージ・サーバー

    コンポーネント その他コンポーネント 管理用 Ethernet Switch 電源供給ユニット(PDU) データベース・サーバー Firmware OS/Guest VM RDMAネットワーク・スイッチ (2) Exadata System Software Update (1) Database / Grid Infrastructure パッチ パッチの種類 (3) 部位ごとに提供 されるパッチ OS/KVM Host Oracle Database Grid Infrastructure Firmware KVM Guest KVM Host Storage Server Software Storage Server OS Storage Server Firmware Switch Firmware DB Guest VM/OS インフラストラクチャ・メンテナンス 4.インフラストラクチャ セキュリティ メンテナンス 5.インフラストラクチャ 四半期メンテナンス 3.Guest VM OS(ESS)のメンテナンス 1.Databaseのメンテナンス 2.Grid Infrastructureのメンテナンス メンテナンスの種類 お客様作業範囲 オラクル社作業範囲 DB Firmware Copyright © 2025, Oracle and/or its affiliates | 123 DB KVM Host
  103. いずれもサービスとしては無停止、実施タイミングはお客様で制御可能 ExaDB-Dのメンテナンスの種類 Copyright © 2025, Oracle and/or its affiliates |

    124 2025/1/9 更新 名称 対象 リリース タイミング 適用 タイミング 日時設定 作業者 対象 適用方式 VMの 再起動 パッチ適用中の VM上の DB再起動 1 Oracle DB アップデート DB 四半期毎 最低 年に1回 任意・即実行 お客様 DBホーム 単位 ローリング なし あり 2 Oracle GI アップデート GI 四半期毎 最低 年に1回 任意・即実行 お客様 VMクラスタ 単位 ローリング なし あり 3 Guest VM OS(ESS)アップデート Guest OS 毎月 最低 年に1回 任意・即実行 お客様 VMクラスタ 単位 ローリング あり あり 4 Cloud Tool アップデート Cloud Tool 不定期 自動(事前 通知あり) 事前通知 (任意の日時で 手動可能) オラクル (お客様も 可能) VM単位 無停止 なし なし 5 Exadata Infrastructure 月次セキュリティ・メンテナンス ESSインフラ 毎月 毎月 事前通知 (GUIから変更) オラクル Exadata Infra 全体 無停止 なし なし 6 Exadata Infrastructure 四半期メンテナンス ESSインフラ 四半期毎 毎四半期 GUIから指定・ 変更 オラクル Exadata Infra 全体 ローリング or ノン・ローリング あり あり お 客 様 管 理 オ ラ ク ル 管 理
  104. ExaDB-D メンテナンスの影響 メンテナンス種別 ターゲット メンテナンスの影響 データベースの更新 Database Home • 更新はローリング方式で実行されます。

    • 当該ノードのデータベース・インスタンスの停止が発生します。 • 当該ノードのデータベース・インスタンスに接続していたセッションは切断されます。 • 当該ノードのデータベース・インスタンスが使えないため、性能影響が発生します。 • RACのリコンフィグのため、一時的な性能影響が発生します。 Grid Infrastructureの更新 Exadata VMクラスタ • 「データベースの更新」と同じです。 仮想マシンの Exadata OSイメージの更新 Exadata VMクラスタ • 「データベースの更新」に加えて、VMの再起動が発生します。 クラウド・ツールの更新 VM上のクラウド・ツール • 稼働中のデータベースへの影響はありません。 Exadataインフラストラクチャ・ セキュリティ・メンテナンス Exadataインフラストラク チャ • データベース・サーバーへの更新はKspliceテクノロジを介してオンラインで適用されるため、稼働中のデータベースへの影響は ありません。 • ストレージ・サーバーへの更新はローリング方式で適用されます。 • ストレージ・サーバー数が減るため、性能影響が発生します。 • ASMの高速ミラー再同期のため、一時的な性能影響が発生します。 Exadataインフラストラクチャの 四半期メンテナンス Exadataインフラストラク チャ 以下、ローリング・メンテナンスの場合について記載します。 データベース・サーバー • 当該ノードの再起動が発生します。 • 当該ノードのデータベース・インスタンスに接続していたセッションは切断されます。 • 当該ノードのデータベース・インスタンスが使えないため、性能影響が発生します。 • RACのリコンフィグのため、一時的な性能影響が発生します。 ストレージ・サーバー • 当該ストレージ・サーバーが使えないため、性能影響が発生します。 • ASMの高速ミラー再同期のため、一時的な性能影響が発生します。 Copyright © 2025, Oracle and/or its affiliates | 125
  105. Copyright © 2025, Oracle and/or its affiliates | 128 ゲストVM内はお客様対応範囲

    • お客様の任意のタイミングで適用可能 : 自動適用はされません。定期的なアップデートを推奨 • Database/Grid Infrastructure - コンソールや CLI (dbaascli) などクラウドツールで適用可能 - 可能な限り、 opatchによる適用ではなくクラウドツールを利用して適用 • OS (Exadata System Software*) - コンソールやpatchmgr (専用 CLI ツール) による適用 • クラウド・ツール (dbaastools、dbcs agent) - 新バージョンリリース時に事前通知された上で、計画的に自動適用 • 適用時間はオンライン実行で平均約10分。 • コンピュート内のCLIで手動適用も可能(dbaascli)。自動適用の日程の変更やスキップは不可だが、事前に手動で適用が可 能 ゲストVM内のソフトウェア・メンテナンス * Exadata System Software とは Exadata の各コンポーネントに搭載される、 OS や Exadata 固有のソフトウェア機能を含むソフトウェア・バンドル。
  106. お客様の管理範囲のため、任意のタイミングで計画・実施 • 最低年に1回のアップデート、計画的なアップグレード(メジャー・バージョン)を推奨 • 常に最新のアップデートを適用することで、お客様の環境をセキュリティ脆弱性及びインスタンス停止や著しいパフォーマンスダウン といった既知の重要な不具合から守れます • アップデート: DB/GIはRU、ESS(OS)はメンテナンス・リリース •

    古いバージョンを利用し続けた場合 • オラクルの運用スタッフはお客様VMにアクセスできないため、お客様責任で利用継続は可能です - 自動バージョンアップ、インスタンスの停止や削除等は、基本的にありません • 稼働中のシステムで障害が発生して復旧のために新規作成が必要になった場合に、元のバージョンでは作成できずにシステ ムの復旧に時間を要する可能性があります - サポート終了後は、コンソール等からのクラウドライフサイクル管理機能で該当バージョンに対する新規作成操作ができなくなる。現状、19cより 古いバージョンに関しては、クラウドライフルサイクル管理機能による新規作成関連の操作は不可 - VMクラスタやDB/DBホームの新規作成時、選択可能なバージョンが限られている(最新含めた計4つ) • Real Application Testing(RAT)をご活用ください。 - ExaDB-C@C、ExaDB-DなどのOracle Cloud環境では、RATオプションライセンスも含まれいます - 定期的なアップデート・アップグレードのために本番と同等なテストを容易に低コストで実現可能です ゲストVM内のソフトウェア・メンテナンス Copyright © 2025, Oracle and/or its affiliates | 129
  107. SQL非互換や性能影響の確認が可能 • RATを利用して、SQL非互換や性能影響を確認 • Oracle Databaseの機能を使って実際に流れている SQLを取得しテストを行うため、リアルなテストケースを 効率的に実行可能 • エラー発生や実行計画の変動有無確認であれば

    実データを使わずにテスト可能 • OCIのBase Database ServiceであればEE以上で 利用可能であり、例えばクラウド環境に実データを持っ ていくことが難しい場合でも低コストで実行可能 参考) Oracle Real Application Testing (RAT) による影響調査 SQLと 実行統計を取得 取得した SQLを実行 現行環境 テスト環境 それぞれの 実行結果を比較し てレポート出力 Copyright © 2025, Oracle and/or its affiliates | 130
  108. 四半期ごとにRelease Updateを適用する Interim Patch (暫定パッチ/個別パッチ)よりRelease Updateが推奨 • オラクル社の開発部門でリリース前におこなっているテストの種類・量ともに大きな違いがある - Interim

    Patchは、個別環境での特定の不具合を修正するためのパッチなので、不具合修正テストのみ - Release Updateは、リリースより6-12週前にコードをフリーズし、 100万以上の機能テスト、ストレス・テストと破壊的テスト、パフォーマンス・テ ストなど、広範なテストといった、広範なテストを経て出荷される • Interim Patchの過剰な適用により、世界に1つの「独自の環境」になってしまう可能性が高まる • Interim Patchは直近(General Availabilityから3年間は12ヶ月、4年目以降は24ヶ月)のRUにしか作成されない Release Updateは四半期ごとに適用する • 四半期ごとの適用を想定して提供される • 最新のセキュリティ・パッチに加えて、広く該当する可能性がある不具合の修正が提供されおり、セキュリティと不具合の両方 に対して問題が起きる前に対応できる • さらに、 Release Updateでは、実行計画に影響するオプティマイザの修正はデフォルトで無効になっているため、負荷が高い パフォーマンス・テストをおこなう必要がない • 累積パッチであるため、四半期ごとの適用が難しい場合には半期ごとの適用も可能(それ以下の頻度は推奨しない) • Oracle Database 19cの場合はDoc ID 555.1の推奨パッチ(19.17以降のLinux版はDoc ID 2898740.1のMonthly Recommended Patches)、Exadata X8M/X9Mの場合はDoc ID 2724126.1の推奨パッチも併せて適用する (各ドキュメントの定期的な確認を推奨) 参考) Oracle Databaseのパッチ適用のベスト・プラクティス Copyright © 2025, Oracle and/or its affiliates | 131
  109. お客様によるアップデートの実施 Database/Grid Infrastructure のアップデート Copyright © 2025, Oracle and/or its

    affiliates | 132 コンソール、CLI からパッチ適用が可能 • RU/BP レベルのパッチをコンソールから適用可能 • 対象のパッチ: 直近4四半期分 • パッチ関連操作 • 事前チェック、適用(ローリングで実施)が可能 • 操作結果をパッチ履歴から確認可能 • データベースに関して: パッチレベルの異なるデータベース・ホームを 用意してデータベースを移動することで、アップグレードやダウングレード を行うことも可能(推奨) • アップデート手順詳細: Patching and Updating VM Cluster’s GI and Database Homes
  110. 2種類の方式 単一DBへの適用: Out-of-place方式 データベース・ホームへの適用: In-Place方式 データベースのパッチ適用(更新)方法 Copyright © 2025, Oracle

    and/or its affiliates | 133 23.3.0 23.4.0 23.3.0 • メンテナンス時間が短い • 事前にテスト済みのDBホームを利用できる • 切り戻しが容易 • 複数データベースが属す場合、個別に実行可能 • 複数データベースが属す場合、一括実行可能 • データベース・ホームのパスが変わらない (EBS等、パス変更不可のシステム向け) • Out-of-placeに比べて、データベース・ホームが使用する ストレージ容量は少なく済む 23.4.0 推奨
  111. ExaDB-D データベースのパッチ適用(更新)方法 Copyright © 2025, Oracle and/or its affiliates |

    134 単一DBへの適用: Out-of-place(推奨) データベース・ホームへの適用: In-Place ・既存のデータベース・ホームとは別のデータベース・ホームを作成して、切り替 える方式 ・In-placeと比べて、データベースへの影響少 メンテナンス時間(事前にパッチ適用済みのデータベース・ホームへ切り 替え)、切り戻しが容易、複数データベースが属す場合は個別実行 等 ・ローリング適用。データベース・ホームのパスが変わる ・基本的にコンソールで実行可能 ・dbaascliツールの場合、ノードを指定した適用も可能 ・既存のデータベース・ホームを直接入れ替える方式 ・Out-of-placeと比べて、データベースへの影響多 メンテナンス時間(DB停止後にパッチ適用)、データベース・ ホームを直接変更、複数データベースが属す場合は一括 等 ・複数データベースに一度で適用可能(データベース・ロールが全て一 致している必要あり)。データベース・ホームのパスは変わらない ・ローリング適用 ・dbaascliツールの場合、ノードを指定した適用も可能 RUのみの適 用 適用 コンソールから適用バージョンの 「新規データベース・ホーム」を作成 →データ ベースを「別のデータベース・ホームへの移動」で移動 (最新+3つ前のバージョンではない場合 : 事前に「データベース・ソフトウェア・イ メージ」で該当イメージの作成が必要) (ノード指定して順に適用したい場合、コンソールからは不可。dbaascli database move --nodeList でノード指定適用 ) コンソールから「更新」でデータベース・ホームに適用 (ノード指定して順に適用したい場合、コンソールからは不可。 dbaascli dbhome patch --nodes でノード指定適用 ) ロールバック コンソールから「別のデータベース・ホームへの移動」で、元のバージョンのデータ ベース・ホームへ移動 (ロールバック先が最新+3つ前のバージョンではない場合、コンソールからは不 可。dbaascli database moveで移動) SR RU以外を 含む適用 (個別パッチ 等) 適用 方法1: 「データベース・ソフトウェア・イメージ」で適用済みイメージを作成 → 「新規データベース・ホーム」作成 →「別のデータベース・ホームへの移動」 方法2: 「暫定ソフトウェア更新」で個別パッチをダウンロードし、opatchで新規 or既存データベース・ホームへ適用→「別のデータベース・ホームへの移動」 方法1: 「データベース・ソフトウェア・イメージ」で適用済みイメージを作 成 → 「更新」に作成済みイメージを指定 方法2: 「暫定ソフトウェア更新」で個別パッチをダウンロードし、opatch で適用 ロールバック ・「別のデータベース・ホームへの移動」で、未適用の移動前のデータベース・ ホームへ移動 ・opatchでロールバック
  112. rootユーザーで実行 • DBのパッチ適用は Out-Of-Place適用(Move)がベストプラクティス • 現在のバージョン確認 • move先のDBホーム(Oracle Home)の確認 •

    適用前の前提条件確認(プリチェック) • パッチ適用(Out-of-place方式:DBHOMEのmove) • 適用したパッチのロールバック(Out-of-place方式: DBHOMEの再moveで旧バージョンのDBHOMEへ) データベースのパッチ適用(更新)方法 : CLI Copyright © 2025, Oracle and/or its affiliates | 135 $ opatch lspatches # dbaascli system getDBHomes # dbaascli dbhome getDatabases --oracleHomeName oracle_Home_Name # dbaascli database move --oracleHome path_to_target_oracle_home --dbname database_name --executePrereqs # dbaascli database move --oracleHome path_to_target_oracle_home --dbname database_name # dbaascli database move --oracleHome path_to_target_oracle_home --dbname database_name OCI Documentation Exadata Cloud Service> Patching and Update an Exadata Cloud Instance System
  113. ExaDB-D Grid Infrastructureのパッチ適用(更新)方法 Copyright © 2025, Oracle and/or its affiliates

    | 136 Grid Infrastructureホームへの適用: In-Place ・既存のGIホームを直接入れ替える方式 ・ローリング適用 ・dbaascliツールの場合、ノードを指定した適用も可能 RUのみの適用 適用 ・「更新」でVMクラスタ(GI)に適用 ・dbaascliでノード指定適用も可能(dbaascli grid patch --nodeList) ロールバック SR RU以外を含む適 用 (個別パッチ等) 適用 ・opatchで適用 ロールバック ・opatchでロールバック
  114. RACローリングもしくはStandby-Firstによるメンテナンス時の停止時間削減 RACローリング • アップデート中のノード以外で処理継続。データベースとしては無停止 • RACノード間で一時的にパッチ状態が異なるバイナリで稼働 • アップデート中のノードは利用不可となり、縮退運転 • クライアント側からの接続設定を変えることなく処理継続

    • SCANやサービス、クライアント側の接続情報の設定により、稼働 中のインスタンスに新規接続 • FANにより、既存セッションの安全な切断 Standby-First(Data Guard) • プライマリで業務継続しながら、スタンバイに先にパッチ適用をすること で停止時間の削減 • プライマリ、スタンバイで同時にパッチ適用をする必要がない • スタンバイを先にアップデートできることで、パッチ適用状態でのテストや 問題発生時のロールバックも、プライマリには影響なしで行える • 異なるバージョンでの運用は最大31日までサポート。適用前後のバー ジョンは、リリースが1年以内のもののみサポート(Doc ID 1265700.1) 可用性構成でのアップデート Copyright © 2025, Oracle and/or its affiliates | 138 停止 スタンバイ プライマリ 適用するパッチが各手法に対応しているか事前に確認 *基本的にRUはどちらの方式も対応
  115. お客様によるアップデートの実施 • Oracle のメンテナンスにより、データベース・サーバー上の KVM Host の Exadata System Software

    が四半期ごとにアップ デートされる • アップデート後のバージョンを確認いただき、必要に応じてお客様 VM にも同一のアップデートを実施 アップデート手順詳細 : Updating an Exadata Cloud VM Cluster Operating System OS (Exadata System Software) のアップデート Copyright © 2025, Oracle and/or its affiliates | 139 Oracle 作業 (基本的に四半期) お客様作業 (最新のアップデートを12か月以上遅延しないことを推奨) KVM Host アップデート お客様 VM の アップデート KVM Host アップデート 内容の確認 • KVM Host に適用された Exadata System Software のバージョンを SR にて確認 • お客様 VM に適用する Exadata System Software の詳細は Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1) にて確認
  116. Copyright © 2025, Oracle and/or its affiliates | 140 仮想マシン上の

    OS (Exadata System Software) のアップデートが、コンソールや CLI (patchmgr) から可能 • コンソールでは適用可能なアップデートがリストされ、簡単に適用可能 • 対象は Exadata System Software のリビジョン • リリースされるとリストに自動的に追加 • コンソールでの現状のバージョン情報の確認 • 「VM クラスタ情報」> 「バージョン」セクション> 「Exadata イメージ・バージョン」 で確認可能 • CLI で行う場合 • CLI (patchmgr) を MOS からダウンロードしてアップデートを実施 パッチの適用方法 –仮想マシン上の OS (Exadata System Software) コンソール: OCI Documentation Exadata Cloud Service> Updating an Exadata Cloud VM Cluster Operating System CLI: OCI Documentation Exadata Cloud Service > Updating an Exadata Cloud VM Cluster OS Manually
  117. OCI Region ExaDB-D ExaDB-D DB/GIに対するパッチ適用自動化機能 • DBおよびGIのRU適用を簡素化、標準化 • 単一のメンテナンス・スケジュールを利用して、 DBとGIをそれぞれのグループでアップデート

    • OCIネイティブなサービスでOCIコンソール、 API、CLIから実行可能 参考) Exadataフリート更新の発表 https://blogs.oracle.com/oracle4engineer/ post/announcing-exadata-fleet-update-jp Exadataフリート更新概要 https://blogs.oracle.com/oracle4engineer/ post/exadata-fleet-update-concepts-jp Exadata Fleet Update Overview https://youtu.be/IgGEnykNGss Exadataフリート更新(Exadata Fleet Update) Copyright © 2025, Oracle and/or its affiliates | 141 ExaDB-D Database Collection Grid Infrastructure Collection
  118. Copyright © 2025, Oracle and/or its affiliates | 142 Grid

    Infrastructure(GI)のアップグレードはコンソールやCLIから可能 • 19cにアップグレード可能 (2021年11月時点) • 前提条件: OSバージョンが Oracle Linux 7 (古い場合は、MOS Doc ID 2521053.1参照) • 注意点 • 24時間以内にスケジュールされたインフラ・メンテナンスがある場合は実行不可 • 実行中は、ほかの管理操作の実行不可 • アップグレードで利用可能なCLI/API • dbaascli (OS上のツール)、REST APIや各種SDK アップグレード – Grid Infrastructure OCI Documentation Exadata Cloud Service> Patching and Updating VM Cluster’s GI and Database Homes
  119. Copyright © 2025, Oracle and/or its affiliates | 143 DatabaseのアップグレードはコンソールやCLIから可能

    • 19cにアップグレード可能 (2021年11月時点) • 前提条件 • OSバージョンがOracle Linux 7 (古い場合は、MOS Doc ID2521053.1参照) • Grid Infrastructureが19c • 全てのPDBがOpenできることを確認 • データベースがARCHIVELOGモードかつフラッシュ バック・データベースが有効になっていること • 最新バージョンの19cのDBホームが2つあること • 注意点 • データベースの停止時間あり • 事前にテスト用データベースでテストすることを推奨 • アップグレード後は、アップグレード前に取得した自動バックアップでのリストアは不可 • アップグレードで利用可能なCLI/API • dbaascli (OS上のツール)、REST APIや各種SDK アップグレード – Database OCI Documentation Exadata Cloud Service> Patching and Updating VM Cluster’s GI and Database Homes
  120. インフラストラクチャ・メンテナンスの種類 Exadata Database Service Copyright © 2025, Oracle and/or its

    affiliates | 145 四半期メンテナンス 月次セキュリティ・メンテナンス • 四半期ごとに実施 • ESSのメンテナンス・リリースの適用 • VM再起動ありで、RACローリング適用(非ローリングも可) • メンテナンスのスケジュール設定が可能。設定に基づき、 日時が設定されて通知。必要に応じて変更可能 • 多くて月次での実施(毎月必ず行われるわけではない) • DBとVMは無停止、ストレージ・サーバーはローリングでの適用 • パッチ適用日時をお客様が柔軟に制御可能 • メンテナンスサイクルの範囲内で、適用日時を制御可能
  121. Exadata System Softwareのメンテナンス・リリースの適用 Exadata Database Serviceのインフラに対して、定期的にオラクルが実施 • 事前に顧客側で実施可能日時等を設定し、実施タイミングの制御が可能 基本的にサービス停止なし •

    メンテナンス実施中のサーバーは基本再起動 - データベース・サーバーのメンテナンス中は、対象のサーバー上のゲストVMも再起動 • ローリング適用の場合、サービスとしてのダウンタイムなし - デフォルトはローリング適用(1台ずつ適用) - 顧客側で非ローリング適用に設定することで、メンテナンス時間短縮も可能 メンテナンス中もデータベースは稼働 - Real Application Clusters構成の場合、データベースのダウンタイムも極小化 • セッション瞬断の可能性はあり • VMクラスタやデータベースがシングル構成の場合は、VM再起動中はデータベース停止 - 縮退運転となり、メンテナンス中のトランザクションは、メンテナンス実施中のサーバー以外の上で処理実行 四半期インフラストラクチャ・メンテナンス Copyright © 2025, Oracle and/or its affiliates | 146 データベース・サーバー ストレージ・サーバー
  122. メンテナンス・スケジュール設定(プリファレンス) メンテナンス方法やメンテナンスが許容できるタイミングを、事前に指定可能 • 実施のスケジュールを予め設定することが可能(月/週/曜日/開始時間) • メンテナンス月: 各四半期の中で1つ以上選択 • 週 :

    任意の週 or 第x週を1つ以上選択 • 曜日:すべての曜日 or 1つ以上選択 • 開始時間(UTC) : 任意の時間 or 1つ指定(正時XX:00を選択可能) • メンテナンス実施日の事前通知のタイミングを設定可能 (1~4週間前) - リードタイムを守る形で、次回のメンテナンスが計画 • メンテナンス方法 • ローリングもしくは非ローリング • カスタム・アクション: 各DBサーバーのメンテナンス開始前に猶予時間を 設けることが可能(デフォルト30分。15-120分まで分単位で設定可能) 設定された内容に基づき、次回のメンテナンスが計画 • 通知は、管理者や登録者へのメール送信及びコンソール上で確認(英語) • 計画された後改めて変更も可能。即時実行も可能 四半期インフラストラクチャ・メンテナンス 147 Copyright © 2025, Oracle and/or its affiliates |
  123. より詳細な設定が可能 1つのメンテナンスで、全てのコンポーネントのメンテナンスをまとめて実行するか、分割して実行するかが選択可能に • 四半期メンテナンスの対象は、DBサーバーとストレージサーバー • 対象コンポーネント全てに対して更新が必要なので、サーバー数が多ければ多いほど、メンテナンスウィンドウは長い - 従来からの方法: 一度にまとめる場合、1回のメンテナンス・ウィンドウは長くなるが1回で済む -

    分割した場合、1回のメンテナンス・ウィンドウは短く抑えられるが回数が増える • ウィンドウ期間を設定することで、メンテナンス・ウィンドウのタイムラインを遵守 • 更新の順序を制御可能なので、特定のコンポーネントを優先してメンテナンス可能 インフラストラクチャ メンテナンスを、より短い時間枠に合わせて柔軟に実行可能 四半期インフラ・メンテナンスのポリシー設定 Copyright © 2025, Oracle and/or its affiliates | 148 チュートリアル) Oracle Exadata Database Service on Dedicated Infrastructureのメンテナンス・スケジューリング・ポリシーの作成 2025/06/24追加
  124. Copyright © 2025, Oracle and/or its affiliates | 149 •

    コンソール上で、スケジュール済の次回メンテナンス予定日を確認可能 • 変更が必要な場合、コンソール上で変更可能 参考) スケジュール済の次回メンテナンス日の確認と変更 OCI Documentation Exadata Cloud Service> Configure Oracle-Managed Infrastructure Maintenance
  125. 四半期インフラストラクチャ・メンテナンス カスタムアクションの設定 •メンテナンス方法: (2022年3月以降、順次可能に) • ローリング(デフォルト): 1台ずつパッチを適用(ただし終了まで時間がかかる) • 非ローリング: DBサーバーとストレージサーバーを同時にアップデート

    - 全体のメンテナンス時間は最小限になるが、ダウンタイムが発生 •カスタムアクションを有効にするかどうか: (2022年3月以降、順次可能に) • カスタムアクション有効時の動き - ローリングの場合 ◦ 各DBサーバーでメンテナンスを開始する前に、カスタムアクション待機用のタイムアウトまで待ってからメンテナンスの実行 - 非ローリングの場合 ◦ 全DBサーバーでメンテナンスを開始する前に、タイムアウトを設定したカスタムアクションを待機 • カスタム・アクションのタイムアウト(2022年3月以降、順次可能に) • デフォルト: 30分 • 最大: 120分 • カスタム・アクション待機では、必要な作業が終わったらタイムアウト時間を待たずにCloud Consoleから明示的にパッチ適用を再 開させることも可能 Copyright © 2025, Oracle and/or its affiliates | 150
  126. 四半期インフラストラクチャ・メンテナンス: ローリング適用時 パッチ適用の流れとカスタムアクションの活用について カスタムアクション DB Serverパッチ適用 (約1.5時間/1台) 1台ずつ 実施 開始イベント

    終了イベント 開始イベント 終了イベント Storage Serverパッチ適用 (約1時間/1台) 開始イベント 終了イベント メンテンナンス開始イベント 1台ずつ 実施 メンテンナンス終了イベント カスタム・アクションの待機中に、お客様は • RACサービスのドレイン(移動) • パッチ適用済みDB Server上のDBの起動確認 • アプリケーション接続先の切り替え などを実施することができる Copyright © 2025, Oracle and/or its affiliates | 151 コンソールで、推定メンテナンス時間や適用順序が確認可能 現状と同一構成の場合、四半期メンテナンスの メンテナンス・ウィンドウが現状よりも短縮されます 2025/6/24 更新
  127. 四半期インフラストラクチャ・メンテナンス パッチ適用時間 ローリング適用時:デフォルト • ローリングで適用するため、サービスを継続できるかわりに、 1台ずつの適用のため、全体の時間がかかる • DB Server →

    Storage Server の順に、一台ずつパッチ適用 • DB Server: 1 台あたり平均 90 分 • Storage Server: 1 台あたり平均 60 分 • カスタムアクションを有効化する場合 • 各DBサーバーでメンテナンスを開始する前のタイムアウト時間も加味 して、全体の適用時間の見積もりが必要 非ローリング適用時 • パッチ適用時にダウンタイムが発生するが、 全体の適用時間は短縮される • 適用時間の目安 • シェイプに関係なく、トータルで約4-7時間 Copyright © 2025, Oracle and/or its affiliates | 152
  128. 月次セキュリティ・メンテナンス セキュリティ体制 を強化 データベースは 無停止 (DBサーバー無停止) スケジュール • お客様が最も安全なインフラストラクチャでミッションクリティカルなワークロード を実行できるようにするための運用変更

    • お客様に最も安全で安心なクラウドを提供するベンダーとして、Oracle Cloudのセキュリティおよびコンプライアンス要件として実施 • ゲストVM上のOS、GI、DBは月次セキュリティ・メンテナンスの対象外 (Exadataインフラストラクチャのみが対象) • DBサーバーは無停止で更新、DBサーバー再起動は不要 • オラクルのテクノロジ Kspliceにより無停止でカーネルにパッチ適用 • ストレージ・サーバーはローリング方式で更新 • データベース自体の停止は不要 • 重要度の高いパッチがある場合のみで、毎月必ず行われるわけではない • メンテナンスサイクルの範囲内でパッチ適用日時をお客様が柔軟に制御可能 • 通知、イベント、コンソールの更新による可視化 Copyright © 2025, Oracle and/or its affiliates | 154
  129. メンテナンスによって対応されるCVEの確認 月次セキュリティ・メンテナンス Copyright © 2025, Oracle and/or its affiliates |

    156 Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1) 1.計画されている次回のメンテナンス詳細の「CVEリリース・マトリックス」の 『表示』をクリックするとDoc ID 888828.1が表示される 2. 該当するESSバージョンのNoteに記載の 「CVE Release Matrix Note xxx」から、詳細情報がダウンロード可能
  130. 同じ月に四半期メンテナンスと月次セキュリティ・メンテナンスが予定されている場合 1. 四半期メンテナンス予定日時から 24時間以内に月次セキュリティ・メン テナンスを実施するように設定 • 同日に実施することができ、インフラ・ メンテナンスを1回にまとめられる • 月次→四半期の順番で24時間以内

    の実施は不可 2.四半期メンテナンスの予定日時か ら25時間前までに月次セキュリティ・ メンテナンスをを実施するように設定 • 別日での実施にはなるが、四半期メ ンテナンス内でのストレージ・サーバー へのメンテナンスはスキップされるため、 四半期メンテナンスのメンテナンス・ ウィンドウを短くすることができる 3.月次セキュリティ・メンテナンスの予 定日時から25時間前までに四半期 メンテナンスをを実施するように設定 • 各メンテナンスを別日にわけて実施 • DBサーバーがローリング(OS再起動あ り)で実施されるメンテナンスを許容で きるタイミングが、月次セキュリティ・メン テナンスの期間にない場合など インフラ・メンテナンスの実施タイミングのガイドライン Copyright © 2025, Oracle and/or its affiliates | 157 Exadata Cloud: Frequently Asked Questions about SMR - Monthly Security Maintenance (Doc ID 2951685.1) *OS再起動なし 四半期メンテナンス 月次セキュリティ・メンテナンス DBサーバー ストレージ・サーバー DBサーバー* ストレージ・サーバー 四半期メンテナンス 月次セキュリティ・メンテナンス DBサーバー DBサーバー* ストレージ・サーバー 四半期メンテナンス 月次セキュリティ・メンテナンス DBサーバー ストレージ・サーバー DBサーバー* ストレージ・サーバー 24時間以内 25時間以上 25時間以上
  131. ExaDB-D のインフラ・メンテナンス Copyright © 2025, Oracle and/or its affiliates |

    158 ユーザーの任意のタイミングを指定可能 • UI からの四半期ごとの事前スケジュール設定機能 • メンテナンス日時確定後の、UI からの再スケジュー ル機能による、メンテナンス開始日時の調整機能 メンテナンス時間を設けられる場合 メンテナンス期間を設けるのが難しい場合/ ローリングが許容できない場合 ユーザー側でアプリケーションへの エラーを防ぐ対応が必要 • エラーハンドリングや再接続/再試行 • メンテナンス前後でのレプリカへの切り替え など
  132. Application システムの継続性を支えるソリューションの導入を検討 • メンテナンス中以外のノードでトランザクションを継続 • Real Application Clusters構成によるローリング・メンテナンス(デフォルト) - 計画メンテナンスでのRHPhelper

    でのドレイン • 各サーバーのメンテナンス開始前にAP接続先の手動切り替え等で対応 - 四半期インフラ・メンテナンスの設定で、各DBサーバーのメンテナンス開始前の猶予 時間を設定(カスタム・アクションの有効化)し、お客様による作業が可能 • FAN – Fast Connection Failoverによるコネクションの破棄と作成 - FAN(Fast Application Notification) Oracle Clusterwareによるイベント通知 • Application Continuityによる自動再接続・再実行 • アプリケーション側でエラーを検出することなくトランザクション完了 • Oracle接続ドライバがOracleサーバーの障害を検出すると再接続からトランザクショ ン再実行まで自動実行 • メンテナンス前後でレプリカと切り替える運用 • Data GuardやGoldenGateなどで同期している環境への切り替え - 有事の際の切り替え先としてスタンバイを持つ場合は、いざという時に切り替えられ ないDR環境にならないよう、定期的な切り替えテストが推奨 • Full Stack Disaster Recovery Serviceによるシステム全体の切り替え メンテナンス時も処理を止められない場合 Copyright © 2025, Oracle and/or its affiliates | 159 Connection Pool FAN イベント RACローリング
  133. Copyright © 2025, Oracle and/or its affiliates | 160 アプリケーション・スタック全体のためのDR

    インフラストラクチャからアプリケーションのための 統合された、1回のクリックで管理できるDR Automated discovery • 自動で相互依存のリソースを見つけ、 カスタマイズされたDR計画を作成 • 一元管理を提供 • 統合されたUI/APIによる DR計画の検証と実行の監視 OCI Full Stack Disaster Recovery (FSDR) Standby OCI Region Application Application Oracle Database Infrastructure Block Storage Object Storage Virtual Machine Load Balancer Base Database Service Autonomous Database Exadata DB Service File Storage Application Application Primary OCI Region Application Oracle Database Infrastructure Block Storage Object Storage Virtual Machine Load Balancer Base Database Service Autonomous Database Exadata DB Service File Storage Application Application Application DNS Full stack DR orchestration (Autonomous) Data Guard Storage replication
  134. Copyright © 2025, Oracle and/or its affiliates | 161 •

    virtual machine Exadata OS imageのアップデート、 Grid Infrastructure とデータベースのアップデートとアップグレードに は、 OCI Management Interfaces を 利用すること • パッチ適用にOCI UI/API/CLI/SDK/Terraform などの自動化ツールの選択が可能 • OCIインターフェースでサポートされていないユースケースの場合は、dbaascliやpatchmgrなどの他のツールを使用し てください • クラウド自動化ツールを使用せずに手動で更新とアップグレードを実行するのは、文書化されたユースケースに対し てのみ行う必要があります。 クラウド自動化ツールを介して利用できる機能を手動で更新すると、クラウド自動化を 使用しようとする将来の試みが失敗する可能性があります。 • デフォルトのシステム構成からの VM へのカスタマイズは避けること。標準の Exadata イメージをインストールすること、不 必要なソフトウェアをインストールしないこと • root アクセスが可能であっても、engineered cloud solution として扱うこと、ジェネリックなLinuxとして扱わないこと • プライマリ・本番環境に新しいソフトウェアを適用する前にテスト環境、スタンバイ環境で評価すること • OS, GI, データベースへのexachk とプリチェックでアップデート(パッチ適用)とアップグレードの準備が整っていることを確 認すること • システムがヘルシーな状態であることとソフトウエアの依存性を確認すること ベスト・プラクティス
  135. Copyright © 2025, Oracle and/or its affiliates | 162 •

    インフラストラクチャのメンテナンスに対するゲストVMの準備状況を確認する • Exachkを使用して、システムが正常な状態にあることを確認する • 事前のメンテナンスが完了していることを確認する。 例:ASMはローリングアップグレードモードではないことを確認 する • 指定されない限りは、インフラストラクチャ、仮想マシン、GI、データベースのパッチレベルに依存関係は無い • できるだけ早く最新のリリースにアップデートすること • 最新リリースへの更新が不可能な場合は、インフラストラクチャのメンテナンス更新から12か月以内のバージョンにす べてのパッチレベルを維持すること • お客様は、古いソフトウェアリリースを実行する場合、関連するリスクを負うことになる • メジャーバージョンの依存関係はMOS Note 888828.1. と MOS Note 2333222.1で公開されており、ExaChkによっ て検証される • 特定のアプリケーションには特定の要件がある、グリッドインフラストラクチャとデータベースのアップデート(パッチ適用) およびそれらのアプリケーションに関連するアップグレードのベストプラクティスに従うこと ベスト・プラクティス(続き)
  136. Copyright © 2025, Oracle and/or its affiliates | 163 マスターノート

    • Oracle Database Cloud Exadata Service Supported Software Versions and Planning for Updates (Doc ID 2124174.1) • Exadata Database Cloud in OCI Best Practices (Doc ID 2570952.1) Grid Infrastructure • Upgrading Oracle Grid Infrastructure from 12.1.0.2 to 12.2.0.1 on Exadata Database Cloud or Exadata Cloud at Customer, and then creating a database deployment using Oracle Database version 12.2.0.1 (Doc ID 2206224.1) • 19c Grid Infrastructure and Database Upgrade steps for Exadata Database Machine running on Oracle Linux (Doc ID 2542082.1) OS • How to update the Exadata System Software (DomU) on the Exadata Database Cloud in OCI (19.x to 19.x)(Doc ID 2566035.1) ソフトウェア・メンテナンス 参考情報
  137. OCI - Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)

    Support Dates (Doc ID 2649066.1) • ExaDB-D のサポート終了日は、特記のない限りは、オンプレミスの同じリリースのサポート・ポリシーに準拠します • サポート終了を迎えると、そのリリースに対するパッチ(セキュリティ・パッチを含む)は提供されなくなり、新しいインスタンスのプロビジョニングは不可となります。 • オラクルは、お客様に対し、12ヶ月前にはサービス終了の通知を行います。お客様は、サービス終了前に、以下のいずれかのご対応が必要となります。 • ExaDB-Dの新しいリリースへの移行 • 後継のOCIのサービスへの移行 • ExaDB-Dのインスタンスの終了 ExaDB-Dのサポート終了 (EOL) について Copyright © 2025, Oracle and/or its affiliates | 164 ExaDB-D Releases (UCM/Government) General Availability (GA) Date End-of-Life Announce* (EOL-A) Date End-of-Life (EOL) Date 個別のMOS Note ExaDB-D X11M Jan 7, 2025 TBD TBD ExaDB-D X9M April 19, 2022 TBD TBD ExaDB-D X8M Systems Oct 15, 2020 TBD TBD ExaDB-D X8 Systems Dec 5, 2019 May 31, 2025 November 30, 2026 Doc ID 3086798.1 ExaDB-D Base System June 18, 2019 TBD TBD ExaDB-D X7 Systems June 15, 2018 May 31, 2024 November 30, 2025 Doc ID 3025018.1 ExaDB-D X6 Systems May 1, 2017 May 31, 2023 November 30, 2024 Doc ID 2952509.1 Exadata OCPU May 1, 2017 TBD TBD Exadata OCPU - BYOL May 1, 2017 TBD TBD 2025/06/24更新
  138. 参考) ハードウェア製品のサポート期間 Oracle Premier Support for Systemsは、該当するハードウェア・システムの最終出荷日から最低5年間ご利用になれます。 オラクルは、Service Life終了について12か月前の事前通知ができるよう、商業的に合理的な努力をいたします。 最終出荷日から5年経過すると、交換部品をご提供できない場合があり、また交換部品を送付する対応時間が長くなる

    場合もあります。 なお、出荷日から5年が経過している製品については、Aged Hardware Surcharge (経年機器調整料金)制度の対象とな ります。 165 Copyright © 2025, Oracle and/or its affiliates | Exadata Database Machineのサポート・ポリシー Oracle Hardware 及び Systems サポート・ポリシー https://www.oracle.com/jp/a/ocom/docs/hardware-systems-support-policies-079759-ja.pdf Exadata System Software Certification & Error Correction (Doc ID 2075007.1) List of Supported Oracle Hardware (With Last Ship Dates Announced) (Doc ID 1450710.1) Product Last Ship Date LSD + 5 years Exadata Database Machine X6-2 Nov 2017 Nov 2022 Exadata Database Machine X7-2 Jun 2019 Jun 2024 Exadata Database Machine X8-2 Dec 2020 Dec 2025 Exadata Database Machine X8M-2 Sep 2022 Sep 2027 Exadata Database Machine X9M-2 Nov 2024 Nov 2029
  139. Copyright © 2025, Oracle and/or its affiliates | 167 利用形態ごとの運用・管理範囲の比較

    Oracle Databaseの運用・管理範囲 ファシリティ管理 サーバー管理 パッチ適用 リソース監視 バックアップ/リストア HA/DR DB最適化 お客様管理 OSインストール DBインストール DB構築 スケーリング オラクル管理 オンプレミス DB on IaaS BaseDB/ExaDB Automated Autonomous DB Full-Managed AP管理/最適化 ファシリティ管理 サーバー管理 パッチ適用 リソース監視 バックアップ/リストア HA/DR DB最適化 OSインストール DBインストール DB構築 AP管理/最適化 ファシリティ管理 サーバー管理 パッチ適用 リソース監視 バックアップ/リストア HA/DR DB最適化 OSインストール DBインストール スケーリング AP管理/最適化 ファシリティ管理 サーバー管理 パッチ適用 リソース監視 バックアップ/リストア HA/DR DB最適化 OSインストール DBインストール DB構築 スケーリング AP管理/最適化 ユーザー管理範囲 ユーザー管理範囲+機能(ツール)提供 オラクル管理範囲 DB構築 スケーリング
  140. OSログインやDB管理に関するそれぞれのメリット Automated(BaseDB/ExaDB) ✓ DB管理が可能 • データベース全体の管理権限が必要な操作が可能 • 従来に近しいかたちで運用管理可能 • バージョン選択やメンテナンスの選択肢

    • 構成変更、レプリケーションや外部連携設定、ハ イブリッド構成など ✓ OSログインが可能 • 従来に近しいかたちで運用管理可能 • エージェントのインストール、ログ監視 • OS領域をファイル置き場として利用可能 • 収まるサイズのファイルであれば、別途ストレージは 不要(コスト、性能面でメリット) Full-Managed(Autonomous Database) ✓ 運用管理を削減し、データ管理に専念可能 • データベース全体管理はオラクル • データベースの自動最適化 • プロアクティブな自動メンテナンスによるセキュリティ対策 • S/WやH/Wのサポート期間の対応不要 User-Managedサービス vs Full-Managed サービス Copyright © 2025, Oracle and/or its affiliates | 168 2024/09/26 更新
  141. コンソール、REST APIs、SDK、CLI、Terraformなどで管理可能 • VMクラスタ管理、リソースのスケーリング • データベース(CDB、PDB)構築・管理、DBバックアップ・リカバリ、ストレージIO制御 • Data Guard構築・管理 •

    ソフトウェア管理、アップデート・アップグレード など Exadata Database Serviceのライフサイクル管理機能 Copyright © 2025, Oracle and/or its affiliates | 169 API CLI Control Plane 2024/09/26 更新
  142. クラウド機能・DB機能を組み合わせ、手間のかかるテスト環境構築からテスト実施までを自動化できる テスト環境構築・テスト実施の自動化 Copyright © 2025, Oracle and/or its affiliates |

    170 • クラウド機能 • API、CLIを使ったテスト環境構築 • DB環境構築・破棄 • S/Wゴールド・イメージ化 • バックアップからの新規作成 • PDBクローンでデータ複製 • CPUコア数のスケーリング • アップデート自動化(Exadataフリート更新) • Oracle Database機能 • Data Maskingでセンシティブ情報をマスキング テスト環境構築の自動化 • Oracle Database機能 • Real Application Testing(RAT)で自動テスト • Diagnostic Pack / Tuning Packで性能問題の 特定とチューニング • テスト環境のチューニング結果をEnterprise Managerで本番環境に反映 ※RAT, Diagnostic Pack/Tuning PackはExaDB上で 無償で利用可能 DBテスト/チューニングの自動化
  143. 提供されるOSユーザー Copyright © 2025, Oracle and/or its affiliates | 171

    ユーザー・アカウント 説明 opc システム管理者アカウント。 sudo コマンドでroot ユーザーのアクセス権を得られる oracle Oracle Database 管理者アカウント。 直接アクセスが可 grid Grid Infrastructure(ASM/Clusterware)管理者アカウント。 直接アクセスすることは不可。ユーザー・アクセスを必要とする操作を実行 する場合、opcユーザーで“sudo -s”でrootにアクセスした後、gridにスイッチ root システムのroot管理者。直接アクセスすることは不可。ユーザー・アクセスを 必要とする操作を実行する場合、opcユーザーで"sudo -s"を実行 OCI Documentation Exadata Database Cloud > Connecting to an Exadata Database Cloud Instance opc oracle grid (root) sudo -s
  144. クラウドツールについて • 運用・管理のために、コンソールやAPI/CLIが利用可能 1. Oracle Cloud Infrastructure共通 : コンソール画面やREST API、ocicli、各種SDKなど

    2. ExaDB-D特有 : VM内のOS上にインストールされたクラウド・ツール - OS上の運用・管理のために用いられる - 定期的にコントロール・プレーンと情報同期 Exadata Database Serviceの運用・管理 Copyright © 2025, Oracle and/or its affiliates | 172 OS GI Cloud Tool API/CLI コンソール REST ocicli SDK… DB コントロール・プレーン サービス・インスタンス OCI各種サービス
  145. よくある質問 「クラウド・ツールは使わずに従来の方法(コマンド)で運用、設定変更してもいいですか?」 • 背景 • 従来の運用から変えたくない • 回答 • クラウド・ツール(コンソールやCLI/API)で操作可能なものはクラウド・ツールで実施するのが推奨

    - 従来通りの方式やOS上の設定変更など、直接操作可能な処理でもクラウド・ツールの利用を検討 • OS以上の監視に関しては、Oracle Enterprise Manager Cloud Control など従来通りの製品のエージェント導入で も可能(3rd Party製品に関しては、その製品のベンダーへ確認ください) • PaaSのため極力OS周りの設定を変えないことを推奨します • 注意点 • 管理ツールの動作や運用・管理への影響などがありえます - クラウド・ツールが利用できない状態だと、クラウドでの新機能も利用できない可能性があります • ツール以外の方法で実施する場合には、十分なテストを実施の上での利用をお願いします ※ 判断のつかないケースについては、サポートサービスにお問い合わせください Exadata Database Serviceの運用・設定に関して Copyright © 2025, Oracle and/or its affiliates | 173
  146. 例) Exadata Database ServiceのAPI/CLIについて Copyright © 2025, Oracle and/or its

    affiliates | 174 OS GI DB Cloud Tool Control Plane REST,ocicli コンソール REST API/ ocicli*/SDK など Event/Notification コンソールからできることがAPI/CLIから可能 • 環境作成・管理、スケーリング、DB作成・管理など。ジョ ブ管理ツールなどから、DB作成自動化、スケーリング自 動化などの際に有効 OS上のクラウド・ツール。コンソールからできることより細かい設定や操作が可能 dbaascli DB作成:Non-CDBでの作成なども可能 DB管理:CDB管理・運用、PDB作成・管理・運用、パッチ適用、 DBホーム管理、リスナー管理、TDE管理、DG管理 DBバックアップ・リカバリ:設定、管理・運用、オブジェクト・ストレージ以外への取得 設定も可能 ExaCLI ストレージ(Cell)の情報・管理。ストレージの情報を取得したい場合など利用可能 イベントを検知したら通知を飛ばせるOCIの機能 • スケーリング実行時や、バックアップ実行時、 インフラメンテナンス時なども可能 参考) ・Exadata Cloud API/CLI Alignment Matrix (Doc ID 2768569.1) ・ExaDB-D dbaascliでできること *ocicliでExaDB-Dの新しいリソースモデルを サポートするのは2.13.0以上 2024/09/26 更新
  147. Copyright © 2025, Oracle and/or its affiliates | 175 OCIコンソールを使用してPDBの管理を行う事が可能(起動/停止の例)

    起動:対象のPDBをオープンする 停止:対象のPDBをマウント状態にする OCIコンソールを使用したPDB管理 PDBの管理操作画面 1. OCIコンソールの左上にあるメニューアイコンをクリック 2. [ベア・メタル、VMおよびExadata] を選択→ DBシステム(DBシステム詳細画面)に移動 3. 対象のDBシステムをクリック 4. 操作対象となるデータベースをクリック 5. 画面左側の[プラガブル・データベース]をクリック PDBの管理機能 • プラガブル・データベースの新規作成 • PDBの起動/停止 • PDBの削除 • PDBのクローン(ローカルクローン、リモートクローン(同じクラ ウドVMクラスタ内のExadataプラガブル・データベース間、また はクラウドVMクラスタ間))
  148. • Oracle Database 19c以上をサポート • PDB管理 • 作成・削除、起動・停止、リストア、再配置(リロケート)、クローン(ローカル、リモート、リフレッシュ可能) • SQL等でコンソールを介さずに手動で追加したPDBも、定期的な自動検出により管理対象となる

    • オープン・モードの確認 • オープンモード(読み取り/書き込み、読み取り専用、 マウントなど)を確認可能 • コンソールやAPIからのオープン・モードの変更は不可 のため、SQLなど手動で実行 • バックアップ・リストア • 自動バックアップはCDB単位。PDB単位のバックアップは dbaascliで可能 • リストアは、インプレース・リストア(元のCDB)も アウト・オブ・プレース・リストア(別CDB)もサポート コンソール/APIからPDB(プラガブル・データベース)の管理 PDB管理 Copyright © 2025, Oracle and/or its affiliates | 176 2025/06/24 更新
  149. • リストア先は新規DB上にのみ。既存DB上へは不可 • クローン(リモート・クローン、リフレッシュ可能クローン)は、同一AD内で利用可能 • DBバージョンは、同一バージョン間もしくは上位へのクローンが可能 • Exadata Infrastructure間は不可 •

    Data GuardアソシエーションのスタンバイDBでは利用不可 • 現在、Oracle管理キーで管理しているデータベースのみサポート PDB の再配置(リロケート)、リストア、リフレッシュ可能クローン PDB管理 Copyright © 2025, Oracle and/or its affiliates | 177
  150. OCIコンソールからパフォーマンス・ハブに移動する事で、データベースパフォーマンスを監視することができます。 利用する上での前提: • 「データベース管理の有効化」が必要 ※データベース管理オプションによって利用可能な機能が異なる 基本管理…「ASH分析」「SQLモニタリング」 完全管理…上記+「ADDM」「ブロックしているセッション」 • データベース管理に利用するDBユーザに対して、次の権限付与が必要 •

    監視対象はCDB単位(※2022年2月時点) パフォーマンス・ハブを使用したデータベースの監視 Copyright © 2025, Oracle and/or its affiliates | 178 GRANT CREATE PROCEDURE to <db_monitoring_user> GRANT SELECT ANY DICTIONARY, SELECT_CATALOG_ROLE to <db_monitoring_user> GRANT ALTER SYSTEM to <db_monitoring_user> GRANT ADVISOR to <db_monitoring_user> GRANT EXECUTE ON DBMS_WORKLOAD_REPOSITORY to <db_monitoring_user>
  151. Exadata 性能分析・ヘルスチェック方法 Copyright © 2025, Oracle and/or its affiliates |

    179 Exachk でのExadata全体のヘル スチェック AWRレポートでのExadata 全体の パフォーマンス分析 Enterprise Manager によるリア ルタイムSQL分析
  152. Copyright © 2025, Oracle and/or its affiliates | 180 ユーザーは仮想マシン内のみアクセス可能

    アクセス可能な部分から取得可能であれば、操作/情報収集可能 • ASMインスタンス • AWR • Exachk • ExaCLI Storage Serverの情報について
  153. Copyright © 2025, Oracle and/or its affiliates | 181 仮想マシンからStorage

    Serverへのログインは不可 • アクセス・レベルの分離、セキュリティ担保 • VM内から一部のStorage Server情報は取得可能 - AWRレポートのStorage Server情報、ASMインスタンスからのス トレージ情報など ExaCLIでStorage Serverにログインせずに一部監視可能・管 理可能 • 利用可能な操作 - 参照系(メトリック、構成情報等)、diagpack/iormplan/ト レースレベルなどの設定変更 - 参照)ExaCLI コマンド • Exadcliで、複数ストレージ・サーバーへのExaCLIをパラレルで 実行可能 Storage Serverの情報参照機能(ExaCLI) Storage Server Storage Server Storage Server dom0/KVM host dom0/KVM host VM VM ExaCli ExaCli
  154. Copyright © 2025, Oracle and/or its affiliates | 182 事前準備

    • ユーザー名とパスワードを確認 - ユーザー名 : cloud_user_<クラスタ名> 下記の例の場合、”cloud_user_ExaDB-Dclst-009” - パスワード • Storage Server(Cell Server)のIPアドレスを確認 - /etc/oracle/cell/network-config/cellip.ora ExaCLI の利用 -- ユーザー名の確認(gridユーザー) # su - grid $ crsctl get cluster name CRS-6724: Current cluster name is 'ExaDB-Dclst-009' -- パスワードの確認(opcユーザー) $/opt/exacloud/get_cs_data.py OCI Documentation Exadata Cloud Service > Monitoring and Managing Exadata Storage Servers with ExaCLI
  155. Copyright © 2025, Oracle and/or its affiliates | 183 ExaCLI

    の利用 実行 $ exacli -c 192.168.xxx.xxx -l cloud_user_ExaDB-Dclst-009 Password: *********** exacli [email protected]> list cell nrt100307exdcl07 online $ exacli -c 192.168.xxx.xxx -l cloud_user_ExaDB-Dclst-009 -e list cell Password: *********** nrt100307exdcl07 online exacli -c <ip> [-l username] [--xml] [--cookie-jar [filename]] [-e command] • 対話形式 • コマンド指定
  156. Copyright © 2025, Oracle and/or its affiliates | 184 デフォルトではセッションごとにパスワード入力を求められる

    ExaCLI の利用 $ exacli -c 192.168.xxx.xxx -l cloud_user_ExaDB-Dclst-009 Password: *********** $ exacli -c 192.168.xxx.xxx -l cloud_user_ExaDB-Dclst-009 –-cookie-jar Password: *********** • Cookie を設定することにより、2度目以降はパスワードなしで実施可能
  157. Copyright © 2025, Oracle and/or its affiliates | 185 ExaCLIをパラレルで複数Cellに実行可能なユーティリティ

    Exadcliの利用 $ exadcli -g cell_group -l cloud_user_ExaDB-Dclst-009 list cell 192.168.xxx.xxx: nrt100307exdcl07 online 192.168.xxx.xxx: nrt100307exdcl08 online 192.168.xxx.xxx: nrt100307exdcl09 online exadcli [options] [command] $ vi cell_group 192.168.xxx.xxx 192.168.xxx.xxx 192.168.xxx.xxx • Storage Server(Cell Server)のIPアドレスを書いたファイルを用意 • Storage Server(Cell Server)のIPアドレスを書いたファイルを用意
  158. オプトインによる監視とサポート Diagnostic Events • Oracle Databaseのリソースのステータスの更新を通知 - クリティカルなエラー - ディスクリソース利用率

    - メモリ利用率 - クラスターステータス 等 • Oracle社に上記の収集を許可 Health Monitoring • Oracle Databaseのヘルス・メトリックやイベントの情報収集(Eventsで 通知設定することも可能) - 起動/停止 - ディスクの使用量 - CPU使用率 等 • Oracle社がゲストVMの健全性(上記情報)の収集を許可 Incident Logs and Trace Collections • Oracle社にインシデントログとトレースファイルを収集する権限を付与、 SRを起票する際のお客様の負担を軽減 Automatic Diagnostic Collection Copyright © 2025, Oracle and/or its affiliates | 186 Base Database Service Exadata Database Service on Dedicated Infrastructure Exadata Database Service on Cloud@ Customer Diagnostic Events 利用可 利用可 利用可 Health Monitoring - 利用可 利用可 Incident Logs and Trace Collection 利用可 利用可 利用可
  159. VM上のOracle Databasesまたはその他のコンポーネントのヘルスの問題について通知可能 • 通知可能なイベント(抜粋) ローカル・ディスクの残容量10%未満、CRSの停止、SCANリスナーの停止、 ローカル・リスナーの停止、CDBインスタンスの停止、CRSによるノード排除、 DBブロック・コラプション、アーカイバのハング、DBプロセスのハング、 バックアップの失敗、ASM DGの使用量90%超え •

    通知方法 VMクラスタ作成時(デフォルト有効化)もしくは作成後に診断通知を有効化し、 OCI EventsやNotificationサービスなどと組合せることで、 Oracle Databaseまたはそのほかのコンポーネントの診断情報を メールなどで通知可能です 診断通知 Copyright © 2025, Oracle and/or its affiliates | 187
  160. • シリアル・コンソール接続接続を作成・削除が可能 • 起動やログイン不可なVMに対するトラブルシューティング等で利用 • 作成後24時間を過ぎると、自動で接続が切断 • 前提条件 • Exadata

    System Software 23.1.13以上 • 事前準備 • IAMポリシーの設定 • SSHキー・ペアの作成 • シリアル・コンソール・サーバーから接続先のVMへ、通信が可能な状態に設定 シリアル・コンソール接続 Copyright © 2025, Oracle and/or its affiliates | 188 Allow group <group_name> to manage dbnode-console-connection in tenancy Allow group <group_name> to read db-nodes in tenancy 参考) Troubleshooting Virtual Machines Using Console Connections チュートリアル: Oracle Exadata Database Service on Dedicated Infrastructureのシリアル・コンソール・アクセスの作成
  161. Delegate Access Control for ExaDB-D • アクセス制御の委任サービスは、 Oracle Exadata Database

    Service on Dedicated InfrastructureおよびOracle Exadata Oracle Exadata Database Service on Cloud@Customerのお客様に、VMおよびデータベースのメンテナンスお よびサポート・サービスをサブスクライブし、サービス・プロバイダへのアクセスを委任し、サービス・プロバイダがVMおよび データベース・リソースにアクセスできるタイミングを制御できるようになりました。 • アクセス制御の委任サービスはオペレーターアクセスコントロールの機能 アクセス制御の委任機能の対応 Copyright © 2025, Oracle and/or its affiliates | 189 サービス・プロバイダ Oracle Database Cloud Customer Support Oracle Database Cloud Operation Oracle Engineered Systems Deployment and Infrastructure Support Strategic Customers Program for DB Cloud Platforms 2025/1/7 追加
  162. Delegate Access Control for ExaDB-D アクセス制御の委任により、Oracle Exadata Database Service on

    Cloud@CustomerおよびOracle Exadata Database Service on Dedicated Infrastructureの顧客は次のことを実行可能に • 登録されたサポート・プロバイダに“委任サブスクリプション”を実行することで、お客様が指定した顧客所有リソースを管 理可能に • 顧客IAM内にサポート・プロバイダのアイデンティティを維持することなく、Exadata VMsへの(SSHとAPIを通じた)アクセスを サポート・プロバイダに委任 • すべての委任リソースおよびリソースにアクセスできる特定のサポート・プロバイダを表示 • 委任されたリソースにアクセスしたときに、委任のスコープおよびサポート・プロバイダ・オペレータに付与された権限に対す る制御を保持 • サポート・プロバイダ・オペレータが、お客様が定義した委任管理ポリシー外の委任リソースへのアクセスを禁止 • アクセス期間を事前定義された時間に制限 • サポート・プロバイダ・オペレータが委任リソースに対して行ったすべてのアクションを監査 Oracle Delegate Access Control: https://docs.oracle.com/en-us/iaas/delegate-access-control/index.html デモ動画 : https://www.youtube.com/watch?v=fwKtfp3aNuk&cc_load_policy=1&cc_lang_pref=ja アクセス制御の委任機能の対応 Copyright © 2025, Oracle and/or its affiliates | 190
  163. Tokyo/Osaka Region Oracle Databaseの運用監視を強化するサービス Observability & Management 191 Private Subnet

    Compartment / VCN Management Agent Logging Analytics Database Management データベースの性能監視 データベースのリソース監視や パフォーマンス・チューニング ※Basic Management:無償 Full Management :有償 Ops Insights リソースのトレンド分析 長期データに基づいた 需要予測やSQL分析 ※有償 Copyright © 2025, Oracle and/or its affiliates | ログ分析基盤 アラートや監査ログ等の 各種ログを一元的に集約 横断的な分析と長期保管 ※10GBまでは無償 10GB以降は有償 Private Endpoint Monitoring リソースのメトリック監視 データーベースの稼働状況や 性能を表すメトリックを監視 ※一部有償 Stack Monitoring メトリックやプロセスの監視 ユーザー独自のメトリックやプロセ スを監視可能 ※有償 ExaDB-D 2025/6/24 更新
  164. データベースの運用監視要件に対応するOCIサービス Observability & Management 192 Copyright © 2025, Oracle and/or

    its affiliates | 監視項目 要件 要件を満たすための考慮ポイント 対応するOCIサービス リソース監視 データベースのリソースを監視し、 問題が発生した場合に早期に検知・対応できる 仕組みを確立する •CPU、メモリなどの各リソースの稼働状況を監視 •エラーや障害、異常な動作などの検出 •検出された異常値を自動的に通知、アラートの生成 Monitoring Stack Monitoring Database Management 性能監視 データベースの性能要件が維持されていることを 確認し、業務特性やピーク時の特性を踏まえて性 能監視・チューニングを行う •レスポンス時間や処理速度を監視する •SQLのボトルネックを特定し、パフォーマンスを最適化 •リソースを予測し、性能不足を未然に防止 Database Management Ops Insights ログ管理 データベースの正常動作、およびエラーや障害など のログを日常的に取得・管理することで 問題発生時のトラブルシューティングに対応する •問題を特定するための分析手法を確立 •ログの長期保管と不適切なアクセスや削除を防止 •エラーや異常なログを検出し、アラートの生成 Logging Analytics 2025/6/24 追加
  165. データベースの主な監視・管理項目への対応 Observability & Management 193 監視・管理項目 ExaDB-D管理詳細画面 (デフォルト表示) 対応するOCIサービス リソース監視

    DBシステム (CPU、メモリ、スワップ、ASMディスク・グループ使 用率、ロード平均、ノード・ステータス) ◦ Monitoring データベース (CPU、メモリ使用等の使用率、ストレージの使 用状況、実行数、ブロック変更、解析数(合計)、 現在のログオン) ◦ Monitoring (Database Managementの有効化でPDBの監視も可能) メトリック拡張 - Stack Monitoring 表領域管理 - Database Management キャパシティ管理 - Ops Insights データベースの運用管理 DBパラメータ管理、DBユーザー管理 - Database Management データベースの性能監視 AWRレポートの出力、AWRエクスプローラ - Database Management、 Ops Insights アクティブ・セッション履歴(ASH)分析、 SQLモニタリング - Database Management 自動データベース診断モニター(ADDM)、 SQLチューニング・アドバイザ - Database Management -Full (※EE 以上) ログ管理 ログ監視 - Logging Analytics、 Database Management-Full (アラートログのみ) ログ分析 - Logging Analytics Copyright © 2025, Oracle and/or its affiliates | 2025/6/24 追加
  166. リソース監視 • 各リソース(CPU、メモリ、ストレージ等)の使用率を監視・分析 • 設定したしきい値に対して、アラームを発報させ管理者に通知可能 利用する上での前提 • PDBのリソース監視にはDatabase Managementの有効化が必要 (Full

    Management) 価格 • 一部有償 ※分析やアラーム発報の際にMonitoringからデータが取り込まれたときに課金が発生 Monitoring 194 Copyright © 2025, Oracle and/or its affiliates | Notifications しきい値を超えた際に アラームを発報 通知サービスと連携 2025/6/24 追加
  167. メトリック拡張 • ユーザー独自のメトリックを追加 • 収集方法はOSコマンド、SQL、JMX、HTTPを選択 • 作成~テスト~デプロイまでGUIで作成可能 • SQL別の負荷情報や特定プロセスの死活を監視 •

    ベースラインを設定し、メトリックの異常値を可視化 • Monitoring と連携し、設定したしきい値に対して管理者に通知 利用する上での前提 • データベースに管理エージェントのインストールが必要 • Stack Monitoring(EE)を有効化 価格 • 有償 Stack Monitoring Copyright © 2025, Oracle and/or its affiliates | 195 従来のメトリックでは監視できないメトリック 2025/6/24 追加
  168. モニタリング・テンプレート • 特定または複数の監視データベースにアラームを一括で設定 • 新たに追加したリソースに対しても同様のアラーム設定が可能 • アラームの条件が事前に定義されたテンプレートが用意 (条件はカスタマイズ可能) 利用する上での前提 •

    データベースに管理エージェントのインストールが必要 • Stack Monitoring(SE・EE)を有効化 価格 • 有償 Stack Monitoring Copyright © 2025, Oracle and/or its affiliates | 196 事前定義済みのモニタリング・テンプレート 2025/6/24 追加
  169. • リアルタイムなデータベースのパフォーマンス監視と分析 • ASH分析やSQLモニタリングなどのパフォーマンス分析機能 • AWRエクスプローラーによるパフォーマンスデータの視覚化 利用する上での前提 • 監視データベースの設定はPDB単位 •

    DBシステムの詳細画面から「データベース管理の有効化」が必要 価格 • Basic Management:無償 • Full Management:有償 パフォーマンス・ハブ Database Management 197 Copyright © 2025, Oracle and/or its affiliates | 実行されているSQLの負荷情報 ※ 上記の管理オプションによって利用可能な機能が異なる 無償のBasic ManagementはCDBのみが対象 2025/6/24 追加
  170. • ExaDB-Dのハードウェア・リソースに関する情報を提供 • サーバ・モデルやディスク・ステータスなどの構成確認 • ExaDB-Dにデプロイされた 複数のデータベースのパフォーマンス特性を分析 • I/Oの高い負荷を特定し、その負荷を バックアップ、リバランス、ユーザーI/Oなどに分類

    利用する上での前提 • DBシステムの詳細画面から「データベース管理の有効化」が必要 価格 • Basic Management:無償 • Full Management:有償 ハードウェア・リソース監視 Database Management 198 Copyright © 2025, Oracle and/or its affiliates | ※ 上記の管理オプションによって利用可能な機能が異なる 無償のBasic ManagementはCDBのみが対象 パフォーマンス・ハブのExadataを選択 2025/6/24 追加
  171. フリート・サマリー • 管理下にある全てのPDBのステータスを一目で把握 • 各データベースの稼働状況やリソース使用率の情報 • データベース名をクリックするとより詳細の情報が表示 利用する上での前提 • 監視データベースの設定はPDB単位

    • DBシステムの詳細画面から「データベース管理の有効化」が必要 価格 • Full Management:有償 Database Management Copyright © 2025, Oracle and/or its affiliates | 199 監視しているDBが表示 2025/6/24 追加
  172. SQL Insights • 最大25ヶ月の長期保存されたSQLをベースに以下のインサイトを提供 1. データベース全体を俯瞰するフリート分析 2. 時間経過に伴うワークロードを解析するデータベース分析 3. SQLパフォーマンス統計に基づいた詳細なSQL分析

    - 性能が良くないSQLはOps InsightsからDatabase Managementの チューニング・アドバイザの画面に推移してチューニング可能 ( Database Managementの有効化が必要) 利用する上での前提 • DBシステムの詳細画面から「Ops Insightsの有効化」が必要 価格 • 有償 Ops Insights 200 Copyright © 2025, Oracle and/or its affiliates | チューニング・アドバイザに推移可能 2025/6/24 追加
  173. Exadata Insights • Exadata専用の機能 • ExaDB-Dのリソース(CPU、メモリ等)監視と予測 • ラックを構成するコンポーネント(ソフトウェアとハードウェア)の詳細 • 複数のデータベース、ホストを横断した監視と分析

    • ストレージ・サーバーの監視と予測 • Exadata Explorerを利用したカスタム分析 利用する上での前提 • DBシステムの詳細画面から「Ops Insightsの有効化」が必要 価格 • 有償 Ops Insights 201 Copyright © 2025, Oracle and/or its affiliates | ラックを構成するコンポーネント 2025/6/24 追加
  174. ログ監視 • アラートや監査ログ等の各種ログを一元的に集約 • 複数データベースを横断したログの分析 • ログの長期保管 • データベースのログを統合的に監視するダッシュボードを作成 •

    Monitoring と連携し、取り込まれたログに応じたアラームの発報 利用する上での前提 • データベースに管理エージェントのインストールが必要 • 監査ログなどデータベースの表に格納されているログを収集する場合は、 クレデンシャルの作成が必要 価格 • 10GBまでは無償 • 10GB以降は有償 Logging Analytics 202 Copyright © 2025, Oracle and/or its affiliates | データベースのログ監視ダッシュボード 2025/6/24 追加
  175. ExaDB-Dのパフォーマンス管理の選択判断 Copyright © 2025, Oracle and/or its affiliates | 203

    Enterprise Managerを使い慣れている(エキスパート) OCIのサービスで統合監視したい パフォーマンス運用監視でAgentを導入したくない 導入作業の負荷を軽減したい Enterprise Managerの(Diag/Tuning)以外の機能を利用 開発フェーズから利用(スキーマ管理、ユーザー、ロール管理) Enterprise Managerの管理(VerUpやメンテナンス)が大変 機械学習やキャパシティ・プランニング機能の利用 Database Management Enterprise Manager Enterprise Manager or Database Management? サービスの管理を軽減したい(マネージドサービス) パフォーマンス以外の機能との連携(ログ管理、アプリ監視) OCIのサービスで対応可能? DBツールなどの利用可能? 2025/6/24 追加
  176. デフォルトでのセキュリティ対策 OCI • テナント分離と階層型権限管理 • IAMポリシーベースのアクセス制限 • OCIネットワーク設定でのアクセス制限 • セキュリティ・リスト

    • ルーティング・ルール 等 • SSH鍵認証でのOSログイン など Oracle Database • 表領域暗号化が有効 • SQL*Netコネクションの暗号化 • DBバックアップの暗号化 • 万が一のセキュリティ被害時にも迅速 に復旧できるサイバーレジリエンシーを 備えた、自動バックアップのデフォルト 宛先設定(Zero Data Loss Autonomous Recovery Service) Exadata • OS上の必要のない機能を排除、イン ストールを最適化。必要なサービスも 最小権限で実行されるように実装 (STIG Hardened) • セキュリティ・スキャンを定期的に実施 • ストレージへのログイン不可 • Exadata System Softwareの各リリース にセキュリティに関する修正を統合、 万が一のゼロデイの脆弱性に対処す るために緊急修正も提供 (月次セキュリティ・メンテナンス) Exadata Database Serviceのデータ・セキュリティ Copyright © 2025, Oracle and/or its affiliates | 205
  177. Copyright © 2025, Oracle and/or its affiliates | 206 •

    デフォルトでOracle Net 接続の暗号化強制が設定済 • Diffie-Hellman鍵交換を使用した通信の暗号化 • セッション毎にセッション鍵が変更される • Oracle Netのクライアント設定によらず、通信が暗号化または整合性サービスが有効化するようにExaDB-D側で設 定済 • クライアント側で暗号化を拒否(SQLNET.ENCRYPTION_CLIENT = rejected)している場合は、 接続に失敗します Oracle Net Servicesクライアント構成 SQLNET.ENCRYPTION_SERVER = required SQLNET.CRYPTO_CHECKSUM_SERVER = required SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128) sqlnet.ora
  178. Copyright © 2025, Oracle and/or its affiliates | 207 •

    データベース作成時に、OCI Vault を選択可 能 • データベース作成後も、Oracle 管理キー/顧 客管理キーを変更可能 • Data Guard 環境では、OCI Vaultの使用は 不可 OCI Vault サービスとの連携 OCI Documentation Exadata Cloud Service > Manage Database on Exadata Cloud Infrastructure > Customer-Managed keys in Exadata Cloud Infrastructure
  179. Exadata Database Serviceであればデータセキュリティ機能を無償で利用可能 機密性の高い情報を保護するデータ・セキュリティ ✓ Data Safeによる構成・ユーザのアセ スメントと機密データの発見 ✓ Data

    Safeによる監査ログの管理 ✓ OCIはデフォルトで暗号化 ✓ Database Vaultによる権限分掌 データ中心の セキュリティ Copyright © 2025, Oracle and/or its affiliates | 208 1. 監査証跡の記録 ✓ 情報システムに対するサイバー攻撃を予兆検知 2. セキュリティ設定ミス、特権ユーザーの利用を監視 ✓ 無差別型攻撃で狙われる構成ミスや管理者権限の利用状況を監視 3. データの暗号化 ✓ 個人データが漏えいした際、二次的被害(社内外の影響)を最小限に 4. データのアクセス制御 / 権限分掌 ✓ 悪意のある攻撃者よりデータの閲覧、改変、破壊などを防ぐ 発見的対策 予防的対策 凡 例
  180. Copyright © 2025, Oracle and/or its affiliates | 209 Oracle

    Databaseをより安全に利用するためのクラウドベースのデータベース・セキュリティ・サービス データベースとData Safeを接続し、以下のセキュリティ機能を提供 - セキュリティ・アセスメント(Security Assessment) - ユーザー・アセスメント (User Assessment) - 機密データ検出(Sensitive Data Discovery ) - データ・マスキング(Data Masking) - アクティビティ監査(Activity Auditing) セキュリティ対策が後手になりがちなデータベースに対して、CISベンチマークを 基準にしたリスク評価やマスキング、監査ログ監視等の運用により データベースをセキュアな状態に保つ Oracle Cloud上のOracle Databaseだけでなく、オンプレミスや 他社クラウドのOracle Databaseも同様に管理することが可能 Oracle Cloud Databaseが対象の場合は無償 (※監査ログは100万件/月まで無料) オンプレミス、他社クラウド上のOracle Databaseの場合は有償 Oracle Data Safe Oracle Cloud上の データベース 監査 ユーザー 発見 アセス マスク オンプレミス のデータベース Data Safe AWS, Azure上の オラクルデータベース 2024/1/15 更新
  181. Oracle Maximum Security Architecture 参考) データベースを最大限保護するOracle Database Security 210 Copyright

    © 2025, Oracle and/or its affiliates | 210 Oracle Database 暗 号 化 アクセス制御 監 査 ユーザーやセッション情報に基づいて 表のアクセスを列・行レベルで制限 DB管理者の無制限のアクセスを 強制的に禁止、厳格な職務分掌を実現 Database Vault 認証強化 外部認証基盤による認証強化 トークン・ベース認証 DF11233 U*1 $5Ha1qui %H1 HSKQ112 A14 FASqw34 £$1 アプリケーションへの影響がない 透過的な暗号化 Transparent Data Encryption 機密データをマスキングし セキュアなテストデータを作成 Data Masking and Subsetting データベースのアクセスログを 漏れなく詳細に記録 Unified Audit アクセスログの分析を自動化し 不正なアクセスの検知・アラート Audit Vault and Database Firewall Centrally Managed Users Virtual Private Database Data Redaction Label Security SQL Firewall OCI Logging Analytics OCI Data Safe クラウド・サービス
  182. Protect Sensitive Data With Oracle Cloud Infrastructure Zero Trust Packet

    Routing • Zero Trust Packet Routing(ZPR)とは • ネットワーク構成とセキュリティポリシーを分離し、 人的ミスに起因するデータ漏洩を防止するソリューション - セキュリティ責任者が、人間の言語でルールを記載 - ZPRが解釈、人手を介さずセキュリティポリシーを強制 - ネットワーク担当は実装に直接介在しない • ExaDB-Dでの設定 • VMクラスタのセキュリティ属性で、事前に作成済みの ZPRポリシーを追加 Zero Trust Packet Routing(ZPR) Copyright © 2025, Oracle and/or its affiliates | 211 ロードバランサ サブネット API サブネット データベース サブネット Load Balancer API Database Zero Trust Packet Routing セキュリティ責任者 セキュリティポリシー (誰がどのデータにどの経路でアクセスできるか) 2025/1/9 追加
  183. 参考:機能概要 Copyright © 2025, Oracle and/or its affiliates | 212

    機能名 製品名 概要 用途 ① データ暗号化 Transparent Data Encryption 既存のアプリケーションに変更なく、透過的に本番、 バックアップデータを暗号化 本番、バックアップデータを保護 ② 鍵の集中管理 Key Vault 公開鍵、秘密鍵、Oracle Walletsなどを集中管理 暗号鍵を管理、保全 ③ DB管理者 職務分掌 Database Vault DB管理者の業務データアクセスを制御。特定のDB設定やパスワード 変更、業務データの閲覧等を制限 DB管理者の職務分掌 業務データにアクセスさせない ④ データマスキング Data Masking 実データのマスキング(伏字化) テスト、開発環境の情報を保護 ⑤ 権限分析 Privilege Analysis 不正アクセスの原因となる過度な権限付与を検出 必要な権限のみを付与し、最小権限の原則を実現 ⑥ アセスメント Database Security Assessment Tool データベースのセキュリティ構成、ユーザーと権限付与、重要データの 格納先などのリスク可視化と推奨対策の提示 データベースのセキュリティ状況の把握や コンプライアンスへの対応 ⑦データアクセス制御 Label Security / Virtual Private DB 特定の表への行・列レベルでのより厳密なアクセス制御 参照、更新時における行・列レベルでのアクセス制御 ⑧ 通信暗号化 Oracle Database 標準機能 データベースに関する通信を暗号化 データベースとの通信時の情報を保護 ⑨ 機密データ伏字化 Data Redaction 特定の表への参照範囲をデータベース内で列レベルで制限 参照時における列レベルでの伏字化 ⑩ 不正SQL検知 Audit Vault and Database Firewall 定常的なレポートと不正なアクセスを検知 監査証跡の取得、管理 ⑪ 証跡管理 Audit Vault and Database Firewall ログを取得し、改ざん・削除されないようログを保全 監査証跡の取得、管理 ⑫ 認証・多要素認証 Identity Cloud Service 多段要素認証によるなりすまし防止 Webアプリケーションの厳密なアクセス制御 ⑬ セキュリティ対策の自動 化 Data Safe データベースセキュリティ対策の可視化と自動化により重要なデータを 保護 管理工数をかけずクラウドで利用するデータベースの セキュリティ強化
  184. 参考) ExaDB-D セキュリティ・ガイド • Exadata Database Service on Dedicated infrastructureのセキュリティ・ガイド

    https://docs.oracle.com/cd/F56555_01/ecscm/ecs-security-guide.html#GUID-EBDA0EB5-734A-4AD2-A740-8C174B1FFE3B • Exadata Database Service on Dedicated Infrastructure Security Controls 不正なアクションの防止、検出、対応に役立ち、ITセキュリティポリシーの要件に対応する機能 https://www.oracle.com/jp/a/ocom/docs/engineered-systems/exadata/exadata-cloud-service-security-ja.pdf 213 Copyright © 2025, Oracle and/or its affiliates | 2025/6/24 追加
  185. 1つのExadataインフラストラクチャ上に複数データベース環境を構築可能 Exadata&Oracle DatabaseテクノロジでのDB統合 Copyright © 2025, Oracle and/or its affiliates

    | 215 • VMクラスタ/VM分割: 複数VMクラスタを作成可能(X8M以降) • 1インフラ上のVMクラスタ数 : 1~8 • VMクラスタに属するVMが稼働するDBサーバーを指定可能 • 例) VMクラスタAは全サーバー、VMクラスタBとCは2サーバーずつで分離する など、可用性・分離要件に合わせた統合環境の構築 • DBサーバー上のVM数: 1~8 • VMクラスタのノード数増減も可 • VMクラスタごとにストレージ領域(ディスク・グループ)が割り当て • DB分割(CDB/PDB): 複数CDB、複数PDBの構成で利用可能 • 複数DBホームが作成可能なので、DBごとに同一・異なるバージョンで利 用可能 • 例)バージョンごとの検証、DBホーム切り替えによる迅速なメンテナンス(out- of-place)、システムの要件に合わせたメンテナンス・サイクルやタイミング 各コンポーネントの作成可能な最大数は、使用可能なHWリソースにも依存 ストレージサーバー1 ストレージサーバー2 ストレージサーバー3 ストレージサーバー4 ストレージサーバー5 DBサーバー1 DBサーバー2 DBサーバー3 DBサーバー4 Disk Group(VMクラスタA) Disk Group(VMクラスタB) Disk Group(VMクラスタC) VMクラスタA VMクラスタB VMクラスタC Secure Fabric VCN Grid Infrastructure Grid Infrastructure Grid Infrastructure
  186. 1つのExadataインフラストラクチャ上に複数データベース環境を構築可能 Exadata&Oracle DatabaseテクノロジでのDB統合によるHWリソース最適化 Copyright © 2025, Oracle and/or its affiliates

    | 216 VMクラスタ: 複数VMクラスタを作成可能(X8M以降) • VMクラスタに属するVMが稼働するDBサーバーを指定可能 • 例) VMクラスタAは全サーバー、VMクラスタBとCは2サーバーずつで分離させる • 1インフラ上のVMクラスタ数 : 1~8 • 使用可能なHWリソースにも依存 • DBサーバー上のVM数: 1~8 ストレージ: VMクラスタごとにディスク・グループを使用 • ストレージ・サイズ: VMクラスタごとにサイズと構成を設定。利用している ストレージ・サーバーの台数によって利用可能なサイズが変わる • ディスク・グループ: VMクラスタごとに各ディスク・グループが1つずつ作成 • DATA、RECO、SPARSE(作成するかどうかを選択) DB: 複数DB/PDBを複数バージョンで利用可能 • DB数、DBホーム数ともに、利用可能なリソース量次第 ストレージサーバー1 ストレージサーバー2 ストレージサーバー3 ストレージサーバー4 ストレージサーバー5 DBサーバー1 DBサーバー2 DBサーバー3 DBサーバー4 Disk Group(VMクラスタA) Disk Group(VMクラスタB) Disk Group(VMクラスタC) VMクラスタA VMクラスタB VMクラスタC Secure Fabric VCN Grid Infrastructure Grid Infrastructure Grid Infrastructure
  187. 分離・統合のためのリソース制御・セキュリティ機能を利用して、HWリソースの最適化 Exadata&Oracle DatabaseテクノロジでのDB統合によるHWリソース最適化 Copyright © 2025, Oracle and/or its affiliates

    | 217 VMクラスタ: VMが稼働するデータベース・サーバーの指定可能 • 全サーバー or サーバー指定 例) 本番と開発で物理的に分離 • 使用する分だけのOCPUやリソースの割り当て • VMクラスタごとのSSH鍵管理 • Secure Fabricでのネットワーク分離 ストレージ: リソースの確保とVMクラスタごとのデータ分離 • VMクラスタ毎に全サーバーに跨ってリソース割り当て • 別のVMC上から、ストレージ上のデータへのアクセスは不可 • DBごとにIOリソース制御の比率が可能 • 特定のVMクラスタからのストレージ使用量が増えても、別の VMクラスタの利用可能なストレージに影響を与えない DB: 複数DB/PDBを複数バージョンで利用可能 • コンソールから簡単に環境用意・複製 • PDB機能やDatabase Vaultでアクセス制御 • CDB、PDBごとのリソース制御 • コンソールから簡単にアプグレード、アップデート • 複数DBホームによる迅速な切り替え ストレージサーバー1 ストレージサーバー2 ストレージサーバー3 ストレージサーバー4 ストレージサーバー5 DBサーバー1 DBサーバー2 DBサーバー3 DBサーバー4 Disk Group(VMクラスタA) Disk Group(VMクラスタB) Disk Group(VMクラスタC) VMクラスタA VMクラスタB VMクラスタC Secure Fabric VCN Grid Infrastructure Grid Infrastructure Grid Infrastructure
  188. リソースの共有と分離 Exadata Database Service Copyright © 2025, Oracle and/or its

    affiliates | 218 分離の単位 DB(CDB) OS(VMクラスタ) インフラ(物理サーバー) 構成 イメージ 特徴 ・CDBごとにDBバージョンを分けられ、CDBごとのメンテ ナンスが可能 ・CDBごとに、サービス・レベルに合わせた構成可能(可 用性、セキュリティ等) ・インフラやVM等の共有部分(OSやGI)の計画停止・ 計画外停止は、全てのCDBに影響。メンテナンスをまと めて行える ・物理リソースのIOやメモリは共有のため、干渉する可 能性あり。リソース制御の設定で対応可 ・物理サーバーのリソースを共有。物理サーバーの有 効リソース内で、状況に応じて柔軟な割り当てが可能。 ・VM内のOSやGIは、VMクラスタごとのメンテナンスが可 能 ・インフラの計画停止・計画外停止は全ての環境に影 響。メンテナンスをまとめて行える ・物理リソースは共有のため、干渉する可能性あり (データベース・サーバーは物理も分割可能) ・物理サーバー含め、すべてのリソースを分離。セキュリ ティ観点やシステム間の影響等、確実な分離 ・物理IO含め、性能影響範囲を分離 ・インフラ・メンテナンスを分けられるため、段階的な作 業・確認が可能。メンテナンス回数はその分増える ・リージョン等、配置場所を分けられるため、計画停 止・計画外停止の影響範囲を絞れる ・インフラごとにHWリソース割り当てや課金 DG (VMクラスタA) DBサーバー ストレージ・サーバー DG (VMクラスタB) DG (VMクラスタC) A B C ASM Disk Group (VMクラスタA) ASM VMクラスタA DBサーバー ストレージ・サーバー DG (VMクラスタA) ASM DBサーバー ストレージ・サーバー A DBサーバー ストレージ・サーバー DG (VMクラスタB) DG (VMクラスタC) B C ASM
  189. コンピュート内のリソース制御 Copyright © 2025, Oracle and/or its affiliates | 219

    • SGA、PGA • Resource Manager PDB内 • SGA、PGA • リソース・マネージャ(PDB単位) • PDB毎のCPU_COUNT設定 • CDB内リソース・プランのシェア設定 DB内 (PDB間) • リソース・マネージャ(DB単位) • コンシューマ・グループ • インスタンス・ケージングによるCPU制御 • RAC サービス • サーバー・プール • ポリシー管理・データベース • QoS 管理 クラスタ内 (DB間) • リソース・マネージャ(DB、DBインスタンス単位) • DBのインスタンス・ケージングによるCPU制御 サーバー内 (DB間) • IORM • DB間の優先順位決め I/O Oracle Grid Infrastructure Oracle RAC Storage Servers Database Servers DB(CDB)s PDBs 2025/6/24 更新
  190. 複数データベース間でのリソース管理 • データベース間で I/O リソース使用の優先順位指定が可能 • ユーザーの設定値に基づき、自動的に制御 • "Share"を使用したデータベースごとの優先順位 •

    デフォルトは全データベースに1が設定されている • 設定値は1~32が指定可能で、数値が高いほど優先度高 • サービス・コンソール(UI)で設定可能 参考: Configuring Exadata I/O Resource Manager for Common Scenarios (Doc ID 1363188.1) リソース制御: I/O Resource Manager (IORM) Copyright © 2025, Oracle and/or its affiliates | 220
  191. Copyright © 2025, Oracle and/or its affiliates | 222 移行が必要になるケース

    • サービスの変更 (例:ExaDBからADBやExaDB-XSへの移行) • シェイプ変更 (ExaDB-DのBase SystemからQuarter以上へ変更) • ロケーション変更 (別リージョンやADなど) • ソフトウェアのメンテナンス(アップデート、アップグレード) • 利用中のインスタンスのHW EOL Exadata Database Service上のデータベース移行 お客様要件 クラウドサービス要件
  192. Copyright © 2025, Oracle and/or its affiliates | 223 コンソールや各種ツール、サービスを使い、シンプルな移行が可能

    • ExaDBのクラウド管理機能 : バックアップを利用した新規DB作成、PDBクローン、Data Guard • OCIサービス利用: Database Migration Service、OCI GoldenGate • 手動で設定・実行 : 上記の方式の他、Data Pump、GoldenGate、トランスポータブル表領域、Zero Downtime Migrationなど 主な移行方法 Exadata System Exadata System Object Storage Exadata System Exadata System Exadata System Exadata System Object Storage Exadata System ZDM バックアップを変更先の ExaDB-D へリストア PDBのリモート・クローン Data Guardでの 切り替え Zero Downtime Migration を使った移行 コンソール/APIから可能な方法 • コンソールから操作可能 • 停止時間が設けられる場合など • コンソールから操作可能 • PDB毎に順次移行可能 • 同一リージョン内 • コンソールから操作可能 • 差分同期されるので、 停止時間は数分~ Exadata System
  193. Oracle Database主な移行方式一覧 移行ツール 移行対象 最低移行元バージョ ン(サポート中のDB のみ記載)(*1) 移行元 エディション アップグレード

    可否 ビックエンディアンからの 変換 スキーマ構成 の変更 non-CDB からCDBへ の移行 停止時間 補足 Data Pump DB/表領域/ スキーマ/表 11.2.0.4 SE~ 〇 〇 〇 〇 大~中 RMAN Backup/Restore DB 11.2.0.4 SE~ 〇 〇(一部制限あり) × ×(*3) 中~小 RMAN Duplicate DB 11.2.0.4 SE~ 〇 〇(一部制限あり) × × 小 Transportable Tablespaces 表領域 11.2.0.4 EE 〇 〇(一部制限あり) × 〇 中~小 移行先DBはEE以上が必要 Full Transportable export/import DB 11.2.0.4 EE 〇 〇(一部制限あり) × 〇 中~小 移行先DBはEE以上が必要 移行先DBバージョンは12.1.0.1以降 RMAN Transportable Tablespaces DB/表領域 11.2.0.4 EE 〇 〇(一部制限あり) × 〇 中~小 移行先DBはEE以上が必要 PDB Unplug/Plug PDB 12.1.0.2 SE~ 〇 × × × 中~小 PDB Clone PDB 12.1.0.2 SE~ 〇 × × × 小 Non-CDB Clone DB 12.1.0.2 SE~ × × × 〇 小 Data Guard DB 11.2.0.4 EE 〇 × × × 極小 移行先DBはEE以上が必要 アップグレードを伴う移行には要ADG GoldenGate DB/表領域/ スキーマ/表 11.2.0.4(*2) SE~+ GoldenGate 〇 〇 〇 〇 極小 ダウンタイムを極小化したい場合に 他の移行方式と併用しての利用を推奨 Zero Downtime Migration DB 11.2.0.4 SE~ 〇 〇(AIX,Solarisのみ) 〇 〇 極小 Oracle Cloud Infrastructureへの移行 移行元ライセンスによって 選択可能な移行方式が異なる Database Migration Service DB 11.2.0.4 SE~ 〇 × × 〇 極小 Oracle Cloud Infrastructureへの移行 ZDMの論理移行をフルマネージドサービスで 提供 アップグレードを伴う 移行は〇から選択 (*1)サポートされている最低バージョン。これよりも古いバージョンでのサポート可否は都度確認が必要。 (*2)利用製品/バージョン/OS等、ソースDBのサポート可否は都度確認が必要。 (*3)non-CDBが18c以降である場合はDBMS_PDB.EXPORTRMANBACKUPを活用することで実現可能 https://oracle-base.com/articles/18c/multitenant-usable-backups-of-non-cdbs-and-relocated-pdbs-18c Copyright © 2025, Oracle and/or its affiliates | 224
  194. フルマネージド型データレプリケーション(Change Data Capture)サービス サービス概要/特徴 • OCI GoldenGate は、Oracle GoldenGateをベースとしたフル マネージド型のデータレプリケーションサービスです

    • OCI GoldenGate は、接続対象データベースのパフォーマンス への影響を最小限に抑えながら、リアルタイムの変更データ をキャプチャして、OLTP、DWH、ODS、レポート・システムなど に伝搬します こんな課題に役立ちます • OLTPシステムとDWHシステムの間で、変更差分デー タをリアルタイムに連携させたい • オンプレミスDBのデータをクラウド上のDBにリアルタイム 連携させたい • クラウド上のDB間でリアルタイムデータ連携をしたい サービス価格(PAYG) • Oracle Cloud Infrastructure - GoldenGate \188.174[OCPU/時間] Oracle Cloud Infrastructure - GoldenGate GUIで操作する フルマネージド型 GoldenGate サービス オンプレミスと クラウドを繋ぐ リアルタイムな データ連携 マルチリージョン、 マルチクラウドでの リアルタイムな データ連携 Copyright © 2025, Oracle and/or its affiliates | 225
  195. ZDMとDMSの違い ZDM (Oracle Zero Downtime Migration) DMS (OCI Database Migration

    Service) Oracle Databaseの移行ツール/サービス • Oracle Database用の移行ツール • Data Pump, GoldenGate, RMAN, Data Guardを内部 的に動作してダウンタイムを極小化した移行を実行す る • コマンド・ベースの操作 • 詳細な移行要件の指定が可能 • 無償 • Oracle Database用の移行サービス • ZDM (Data Pump, GoldenGate)を内部的に動作してダ ウンタイムを極小化した移行を実行する • OCI上でのGUIベースの操作 • 無償 Copyright © 2025, Oracle and/or its affiliates | 226
  196. Copyright © 2025, Oracle and/or its affiliates | 227 •

    資料: 『Oracle Databaseの移行方式と選び方』 • データベースの移行方式の違いと選び方についてのガイド • 資料: 『Oracle Databaseのアップグレードと移行』 • アップグレードと移行に関する考え方や方式検討などの情報 • 直接アップグレードと新バージョンへの移行の違い 参考
  197. 環境作成のおおまかな流れ ExaDB-Dスタートアップ・ガイド Copyright © 2025, Oracle and/or its affiliates |

    229 VM作成、データベース・ボールト作成など アカウントがプロビジョニング(作成)されれば、 事前準備の項目が実施できます。 3には数営業日を要するため、お急ぎの場合は 1~4を並行して実施することがおすすめです CDBとPDB(1個)の作成、DBホームの作成など H/Wリソース(データベース・サーバー、ストレージ・サーバー)の割り当て 1.コンパートメントやユーザー等の設定 事前準備 環境作成 作成された環境の確認 4.ネットワーク設定 2.IAMポリシー設定 3.サービス制限の変更の申請 2.VMクラスタの作成 3.データベースの作成 1.Exadataインフラストラクチャの作成
  198. サービス制限 • Oracle Cloud Infrastructureのすべての環境(テナンシ)には、初期状態でサービス制限というリソース制限がかけられて います。例えば可用性ドメインあたりに作成できるコンピュート・インスタンスの最大数が設定されており、それ以上の数 のコンピュート・インスタンスを作成しようとすると、エラーメッセージと共に失敗します • ExaDB-Dは、デフォルトでサービス制限の値が0=利用制限がかかっている状態のため、事前に『サービス制限の引き上 げのリクエスト』が必要です

    • オラクルで申請内容を確認した上で申請が承認。リクエストの許可には数営業日を要するため、お急ぎの場合は インスタンス作成やスケーリング前に余裕をもって申請することを推奨 - 申請内容に関して確認が必要と判断された場合、オラクルから申請者にメール(英語)が送られる場合があります • サービス制限の引き上げ後もしくは利用していたExadataインフラストラクチャを削除後、14日の間にExadataインフ ラストラクチャが作成されていない場合、割り当て済み制限が自動リセットされる。そのため、サービス制限の引き上 げのリクエストは、利用開始予定日の14日前以内での申請を推奨 • 引き上げ済みの制限が削除された後に利用予定の場合、再度サービス制限の引き上げをリクエスト ExaDB-Dスタートアップ・ガイド Copyright © 2025, Oracle and/or its affiliates | 230 参考) OCI Documentation(日本語) サービス > サービス制限 OTN連載 : もしもみなみんがDBをクラウドで動かしてみたら 第16回
  199. 参考) ポリシー設定 • ユーザーの所属するグループに対して、どのような操作をどのようなリソースに対して許可するかという権限の制御 • 設定されていない場合、プロビジョニング作業が実行できないため、事前設定が必要 下記のサービスに対する全ての操作を許可する場合の設定 • Exadata Database

    Service、Base Database • リソース・タイプごとへの権限・操作設定も可能 • 参考) Exadata Database Service on Exascale Infrastructureのポリシー詳細 ExaDB-Dスタートアップ・ガイド Copyright © 2025, Oracle and/or its affiliates | 231 Allow group DatabaseAdmins to manage database-family in tenancy
  200. 参考) ネットワーク前提条件 属するVCN内に2つのサブネット(クライアント/バックアップ)が必要 • サブネットは、リージョン内のすべてのADにまたがる「リージョナル・サブネット」の利用を推奨 - AD固有にする場合は、クライアント/バックアップ・サブネットは同一AD内に作成 • 全てのノード間で、TCPとICMPの疎通ができるようにセキュリティ・リストのイングレス/エグレス設定 •

    X8M以降のシステムの場合、Oracleでは、イングレスおよびエグレス・トラフィックのために、クライアント・サブネット上のすべてのポートをオープンする必要があることを推奨 - システムにデータベース・サーバーを追加するための要件 IPアドレス・スペースの要件 • 利用するクライアントサブネット、バックアップサブネットは下記と重複しないこと X8M以降: 100.106.0.0/16と100.107.0.0/16 • 複数システムを利用する場合、相互のIPアドレスが重複しないこと • VMクラスタごとのVM数に応じて、必要なアドレス数を用意(次ページ) オブジェクト・ストレージへのアクセス • オブジェクト・ストレージへのDBバックアップとリストア、パッチ適用やクラウド・ツールの更新のため、オブジェクト・ストレージへのアクセスが必要(134.70.0.0/16) Autonomous Recovery Service(ZRCV/RCV)へのアクセス • Autonomous Recovery Service(ZRCV/RCV)を使用する場合、専用のサービス・サブネットが必要 ExaDB-Dスタートアップ・ガイド Copyright © 2025, Oracle and/or its affiliates | 232 3 Preparing for Exadata Cloud Infrastructure> Network Setup for Exadata Cloud Infrastructure Instances
  201. 必須IPアドレス数/最小サイズ • VMクラスタごとに必要なIPアドレス数を算出 参考) ネットワーク前提条件 Copyright © 2025, Oracle and/or

    its affiliates | 233 クライアント・サブネット バックアップ・サブネット モデルとシェイプ 必須IPアドレス数 最小サイズ 必須IPアドレス数 最小サイズ Elastic 構成 (N: VM数) 下記より算出 •4 x N (Host IP/VIP) •3 (SCAN) + 3 (reserve) - 下記より算出 •3 x N (Host IP/VIP) •3 (reserve) - Base System 14 •4x2 nodes (Host IP/VIP) •3 (SCAN) + 3 (reserve) /28(16 IPアドレス) 9 •3x2 nodes (Host IP) •3 (reserve) /28(16 IPアドレス) 上記IPアドレス数はMulti-VM構成の場合VM Cluster毎に必要になります 3 Preparing for Exadata Cloud Infrastructure> Network Setup for Exadata Cloud Infrastructure Instances
  202. Copyright © 2025, Oracle and/or its affiliates | 234 マニュアル

    • OCI ドキュメント > Database > Exadata DBシステム > Exadata DBシステムの作成 • https://docs.oracle.com/ja-jp/iaas/Content/Database/Tasks/exacreatingDBsystem.htm チュートリアル(一部最新ではない情報を含みます) • 101 : ExaDB-Dを使おう • https://oracle-japan.github.io/ocitutorials/database/exadb-d101-create-exadb-d/ • 102 : ExaDB-D上のPDBを管理しよう • 103 : 自動バックアップを設定しよう • 104 : バックアップからリストアしよう • 105 : スケーリングしよう スタートアップ・ガイド
  203. Copyright © 2025, Oracle and/or its affiliates | 235 OCI

    Exadata Database Service on Dedicated Infrastructure マニュアル • 英語 https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/index.html • 日本語 https://docs.oracle.com/cd/F56555_01/ecscm/index.html リリースノート • https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/exa-whats-new.html • OCI全体のリリース・ノート : https://docs.cloud.oracle.com/iaas/releasenotes/ その他のリソース • Exadata Database Service on Dedicated Infrastructure Technical Architecture: https://docs.oracle.com/en/engineered-systems/exadata- cloud-service/ecsid/exadbd_overview.html • Learn(チュートリアル): https://docs.oracle.com/learn/?q=&product=en%2Fengineered-systems%2Fexadata-cloud-service&sort=date- desc&lang=ja • ホワイトペーパ: https://docs.oracle.com/ja-jp/iaas/Content/General/Reference/aqswhitepapers.htm リンク集