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

[OCI Technical Deep Dive] クラウドシフトに向けたAutonomous...

[OCI Technical Deep Dive] クラウドシフトに向けたAutonomous Databaseのメリット(2025年8月5日開催)

Oracle Cloud Infrastructure(OCI) Technical Deep Dive(2025年8月5日開催)
https://go.oracle.com/LP=149126
-----
本資料では、Autonomous Databaseの基幹システム移行の観点で解説します。
「Autonomous Database(ADB)は分析基盤向け」——そう思っていませんか?
実は、基幹システム移行においても多くの採用事例があり、その効果を実感しているお客様が多数いらっしゃいます。
本動画では、ケーススタディ形式で事例を紹介しながら、ADBの運用自動化・高可用性・セキュリティのメリットを解説。
さらに、よくある質問やオブジェクションへの回答も交えて、提案時に押さえておきたいポイントをお伝えします。

[こんな方におすすめ]
・基幹システム移行でのADB活用事例を知りたい方
・提案時に出やすい懸念や質問への対処法を学びたい方
・運用負荷軽減と信頼性向上を両立したい方

Avatar for oracle4engineer

oracle4engineer PRO

August 12, 2025
Tweet

More Decks by oracle4engineer

Other Decks in Technology

Transcript

  1. 本⽇のAgenda 2 Autonomous Database 1. 本セッションの⽬的について 2. Autonomous Databaseの導⼊事例より、コストメリットや運⽤メリットのご紹介 3.

    Autonomous Databaseのパッチ・メンテナンスに関するオブジェクションハンドリング 4. まとめと結論 Copyright © 2025, Oracle and/or its affiliates
  2. 本セッションの⽬的について Autonomous Database(ADB)の導⼊価値としてコストメリットや運⽤メリットがあります。本⽇は導⼊事例を通し て具体的にお伝えいたします。 また、お客様からよくある質問としてAutonomous Database (ADB)のパッチ・メンテナンスについては、お客様から の懸念や質問が多いテーマですが、その多くは従来のオンプレミス環境における経験から来ているものだと想定しています。 Autonomous Database

    (ADB)の運⽤に関してより正しく理解して頂いて、お客様からよくある質問(パッチ・メン テナンス)に対して最適なオブジェクションハンドリングが出来るように纏めた情報をお伝えいたします。 Autonomous Database (ADB)の仕組みや運⽤実績をご認識頂いて、⾃信をもってご提案して頂きたいです。 3 Copyright © 2025, Oracle and/or its affiliates
  3. • 販売管理システムのデータ管理にOracle Databaseをオンプレミスで 20年以上にわたり利⽤ • Oracle Databaseの機能や使い勝⼿等のメリットを継続して活⽤し ながら、運⽤管理負担を軽減するため、ATPへ移⾏ • 保有しているOracle

    Database Standard Edition ライセンスを持 ち込むことで、コストを抑えながら、最新機能をクラウドで活⽤可能に • 既存のアプリケーションを⼤きく改修する必要がなかったため、利⽤ユー ザの操作性を変えることなく、 1ヶ⽉という短期間で移⾏を完了 • ATPが持つ⾃律機能により、運⽤管理負担を軽減しながら、アプリケー ション処理速度が約1.5倍向上し、バッチ処理時間も従来から半減し たことで、業務効率の⼤幅な向上を実現 東映 様 Copyright © 2025, Oracle and/or its affiliates 5 Oracle Autonomous Transaction Processing (ATP)への移⾏を1カ⽉で完了 アプリケーション性能向上、バッチ処理時間の半減 により、業務効率向上に貢献 “SaaSでのクラウド利⽤は進んでいますが、今回初めてデー タベースのクラウドへの移⾏を⾏いました。オンプレミスの 「Oracle Database」から「Oracle Autonomous Database」への移⾏は想定よりも容易で、基本的な使い ⽅が変わらず、従来の知⾒を⽣かして運⽤することができ、 利⽤者もクラウドに移⾏したことを意識せず利⽤できています。 チューニングも最低限で、移⾏しただけで性能が向上したの は驚きでした。今回の移⾏により改めてクラウドのメリットを実 感しており、今後そのほかのデータベースやシステムにおいても クラウドの利⽤を積極的に検討したいと考えています。" 東映株式会社 情報開発室 室⻑ 鈴⽊ 聡 ⽒ 課⻑ 池⽥ 治 ⽒
  4. ⼩売業向け販売管理システム提供基盤をOCIで構築し、性能および信頼性を向上 システム概要 • 「storeGATE2」は、専⾨店・⼩売業に適した、全店舗の販 売情報をリアルタイムに把握できるサービスで、約10年で40 社、3,000店舗以上で導⼊ • 従来オンプレミス環境でサービスを提供。ハードウェア更改に 際し、サービス基盤をモダナイズすることを決定 採⽤ポイント

    • ⾃律型データベースにより、データベースのチューニング、ス ケーリング、パッチ適⽤などの運⽤管理を⾃動化し、⾼いレ ベルの性能、セキュリティ、可⽤性が実現できること - 現⾏オンプレミス環境と⽐較し、5倍以上の性能向上 - システムを無停⽌でスケールアップおよびスケールダウンが可能 • 専有環境であるため、⾃社のポリシーに合った頻度でのメン テナンスの設定が可能で、⾃社の管理要件をすべて満たす ことができた • 保有しているStandard EditionライセンスをBYOLすること ができ、コストを低減しながら、Exadata/Enterprise Editionの機能がフル活⽤できる 顧客事例︓NECネクサソリューションズ様 Copyright © 2025, Oracle and/or its affiliates 6 システム構成イメージ 利⽤サービス・製品 • Autonomous Database Dedicated (Autonomous Transaction Processing) • OCI Compute, Storage, FastConnect https://www.oracle.com/jp/news/announcement/necnexsolutions-20210908.html
  5. Autonomous Databaseの料⾦体系 Autonomous DatabaseはStandard Edition 2ライセンスをBYOL可能 BYOLでも機能はExadataを含むすべてのOracle Databaseの機能を利⽤できとてもリーズナブル ECPU (1

    EPU単位, 最⼩2 ECPU) Exadata ストレージ (ADW: 1 TB単位) (ATP: 1 GB単位, 最⼩20 GB) 52.08円 ECPU/時間 3,782円 TB/⽉(ADW) 17.918円 GB/⽉(ATP) 保有ライセンスをBYOLすると (ECPU料⾦が低減) Copyright © 2025, Oracle and/or its affiliates 8 Backup ストレージ (1 GB単位) 3.782円 GB/⽉ 料⾦例 (1ヶ⽉/744時間) 2 ECPU/ストレージ 1TB /バックアップ 5TB 12.5085円 ECPU/時間 101,040円(ADW) 115,176円(ATP) 42,157円(ADW) 56,293円(ATP) 76%OFF 3,782円 TB/⽉(ADW) 17.918円 GB/⽉(ATP) 3.782円 GB/⽉ [Exadata + Enterprise Edition + AI/機械学習による⾃律化] を備えたデータベース・サービスを⽉額約8万円(BYOLの場合約2万円)からご利⽤いただけます * 価格はOCI Public Regionの価格で算出しています。
  6. ü 2ECPU/ストレージ 20GB ü 24時間31⽇間(744時間) スモールスタートが可能 ⾒積り例︓ECPUモデルの場合の最⼩リソース サービス名 数量 単価

    単位 費⽤ Oracle Autonomous Transaction Processing - ECPU 2 ¥52.08 1時間/ECPU ¥77,495 (744時間) Oracle Autonomous Transaction Processing Exadata Storage for ECPU 20 ¥17.918 1ヶ⽉/GB ¥358 合計 ¥77,853 * その他の費⽤︓バックアップストレージ 等 Copyright © 2025, Oracle and/or its affiliates 9 ⾒積りサイト https://www.oracle.com/jp/cloud/costestimator.html 1⽇12時間で20⽇間だけ利⽤する、 といった柔軟な使い⽅も可能 * 料⾦:︓ADB-Sのケース 2025/7現在
  7. システム概要 • ⼤阪ガスグループの全社共通データ利活⽤基盤(DUSH)のDWH - DUSH: Data Utilization Support & Help

    • Exadataの更改タイミングでクラウド化を検討 採⽤ポイント • 現⾏システム相当のパフォーマンスと可⽤性 • ビジネス変化に応じたシステムの柔軟性を実現 - Autonomous Databaseでは柔軟なリソース増減が可能 • OCI GoldenGateを⽤いた新旧切り替え時のダウンタイム極⼩化 • Oracle Support Rewardsを活⽤することにより、既存のソフトウェア・ライセンス・ サポート料⾦を削減 利⽤サービス・製品 • Oracle Autonomous Database • OCI GoldenGate, Compute, Object Storage グループの全社共通データ利活⽤基盤にOracle Autonomous Databaseを採⽤ 移⾏イメージ 顧客事例︓⼤阪ガス様 Copyright © 2025, Oracle and/or its affiliates 10 ②BIツール ③ETLツール 関連システム (約100) 各種集計 レポート出⼒ データ量 約20TB 変換 ⽣成 オンプレミス/データセンター Oracle Cloud Infrastructure ①DWH Autonomous Database (12 OCPU) ③ETLツール Virtual Machine ②BIツール Virtual Machine 移⾏前 移⾏後 ①DWH 加⼯/蓄積/集計 Exadata X6-2 RAC使⽤ ファイル連携 Dynamic Routing Gateways Object Storage 導⼊SIer • 株式会社オージス総研 • アクセンチュア株式会社 導⼊パートナー • 株式会社アシスト 「⼤阪ガスは、⻑年にわたり全社でのデータ利活⽤に注⼒しています。 ビジネス変化に対して柔軟に拡張、増強できるデータ分析基盤に刷新する上で、システムの特性、 要件に合った運⽤環境を活⽤し、最適化しました。 『Oracle Autonomous Database』を選定したことで、オンプレミス環境と同等の性能とこれま で利⽤してきたBIツールとの連携を維持しながら、機動性に優れたデータ基盤へと進化させること ができました。今後は、AIも含めOCIの機能活⽤に取り組みながら、社内のデータ利活⽤をさら に促進していきます。」 ⼤阪ガス株式会社 次世代DUSH構築プロジェクトチーム マネジャー 岡村 智仁 ⽒
  8. 顧客事例︓⼤和総研様 Copyright © 2025, Oracle and/or its affiliates 11 https://www.oracle.com/jp/news/announcement/dir-uses-autonomous-data-warehouse-

    powers-data-platform-2023-12-11/ ⼤和総研、受発注分析基盤に「Oracle Autonomous Data Warehouse」を導⼊ ⼤和総研が⼤和証券のグローバルマーケット部⾨向け受発注分析基盤を、オラクルのクラウドサービス「Oracle Autonomous Data Warehouse (ADW)」に刷新 導⼊の背景と狙い︓ •データ量やユーザー増加への柔軟対応、分析ツールの利便性向上を⽬指した刷新。 •既存のオンプレミス環境から、クラウドベースのマルチクラウド共通基盤への移⾏。 •データ保存期間を3年から10年に延⻑する要望に対応。 ADW導⼊の理由︓ •従来の「Oracle Database」との親和性が⾼く、アプリ改修が不要。 •⼤容量データにも安定した性能とコスト最適化を両⽴。 •⾃動スケーリングやセキュリティパッチの⾃動適⽤により運⽤負荷を軽減。 導⼊成果︓ •2023年11⽉に構築・移⾏を完了。 •既存ツールを継続利⽤可能なため、ユーザーへの負担なし。 •今後はAIや機械学習を活⽤した⾼度なデータ分析にも着⼿予定。 お客様コメント(⼤和総研・筧⽒)︓ 分析基盤の刷新により、運⽤負荷とコストを削減し、 安定的で⾼性能な環境を実現。今後はAI活⽤を通 じて、さらなるデータ利活⽤を推進していく。
  9. システム概要 • 2019年に中期IT戦略を策定し、2023年を⽬標にITコストの最適化、機動性、柔 軟性を⾼めるためのIT基盤構築に取り組む • ⼩売業に求められるスピード感の獲得に加え、コスト効率化も考慮した結果、決⼼ したのが”脱レガシー”と”内製化” • 情報系システムの中核を担う統合データ基盤としてADWを導⼊、900万⼈の会員 データを含む約400店舗およびECサイトの販売データの集約、⾼速処理を実現

    導⼊効果 • ⼤量データの⾼速処理を実現する⾼い性能と柔軟性 - 多重SQL実⾏時に、他社クラウドサービスの1.5倍、レガシーシステムの3倍以上の 性能を実現 - 夜間に⼤量のデータ集計処理を実⾏し、⽇中は⾃動スケーリングでリソースを⾃ 動的に縮退することでコストを最適化 • ⾃律機能による運⽤負荷軽減 - ⾃社メンバーが専⾨知識を習得したり、外部から⼈材を採⽤したりせずとも内製 で運⽤可能 • オンプレミスで稼働するレガシー・システムを全廃し、ADWにすべてのデータを集約す ることで、システム運⽤に掛かるコストを10分の1まで削減できる⾒込み Oracle Autonomous Data Warehouseでデータ・ドリブン経営基盤を実現 システム構成イメージ • 情報系システム内製化のため、クラウド・サービスを積極的に活⽤し、最適なサー ビスを組み合わせたマルチクラウド環境でシステムのコスト最適化を図っている 顧客事例︓アルペン様 Copyright © 2025, Oracle and/or its affiliates 12 https://www.oracle.com/jp/news/announcement/alpen-data-driven-business-autonomous-data-warehouse-2022-08-29/ 利⽤サービス・製品 • Oracle Autonomous Data Warehouse 「情報システムの刷新では、ビジネスの変化に迅速に対応するため内製化を進め、脱レガシー、 脱ミドルウェアによるエンジニアへの依存解消を⽬指しました。 『Oracle Autonomous Data Warehouse』は、⾃律機能により、⼿をかけずに、低コストで⼤量 データを処理する性能を実現し、他のシステムからのETLも容易で、アプリケーションの開発者で も簡単にデータを扱えます。社内システムの内製化をさらに推進していくことで、よりビジネスに 密接な部分にリソースをシフトすることができます。現在、オンプレミス環境の基幹システムの データ移⾏も進めており、今後は巨⼤な統合データ基盤として社内システムのあらゆるデータを 集約し、データの利活⽤によるEC展開やデジタル・マーケティングの強化を⽀援していきます。」 株式会社アルペン 執⾏役員 デジタル本部⻑ 兼 情報システム部⻑ 蒲⼭ 雅⽂ ⽒
  10. ⾃動スケーリング、かつOSヘッドルーム(OSに割り当てるリソース)不要 柔軟なリソースと従量課⾦制でコストを削減 予測される最も⾼いピーク時の使⽤量 + OSオーバーヘッドの⽀払い システムの利⽤率が低い場合でも コストの削減は出来ない Autonomous Database ⾃動スケーリング有

    CPU使⽤料 固定されたコンピュート・シェイプ 低いベース・コスト +ワークロードのスパイク分の利⽤量払い ワークロードに応じて、 コンピュートリソースを⾃動スケーリング ピーク時の 使⽤量に 対する ⽀払い 実際の 使⽤量に 対する ⽀払い • 正確なECPU数、TB数の プロビジョニング • 1から数千ECPUまでの 柔軟な拡張 • 変化するワークロードに合わ せ、3倍まで⾃動的に拡張 • アイドル状態のシステムの コンピュートを停⽌ 30% OSなどDatabase以外 のリソースが使⽤される OS分のオーバーヘッド無し 設定のCPU数の3倍のCPUを無償でリソース確保 課⾦は使った分だけ Copyright © 2025, Oracle and/or its affiliates 14 ADBをプロビジョニングしたら⾃動で無料 で利⽤するリソースの3倍を⽤意してある ので、即時3倍までのリソースを利⽤する ことができる
  11. ソフトウェア/ハードウェアの⾃動パッチ適⽤とアップグレード 数ヶ⽉に及ぶ計画やテストは不要 OS データベース ストレージ・スイッチ データ/スキーマ コンピュート・サーバー ストレージ ORACLE OS

    データベース ストレージ・スイッチ データ/スキーマ ORACLE お客様が管理 Autonomous Database お客様管理のデータベース 新しいハードウェア OS V+1 データベース ストレージ・スイッチ V+1 データ/スキーマ コンピュート・サーバーV+1 ORACLE 新しいハードウェア上の Autonomous Database パッチ適⽤(個別のパッチを含む) ハードウェアのアップグレード データベースの⼿動アップグレード 以下の作業は不要に︓ コンピュート・サーバー ストレージ ストレージ V+1 16 Copyright © 2025, Oracle and/or its affiliates
  12. AWR AWR Autonomous Database SQLの性能劣化を検出し修復する過程を全て⾃動化 Copyright © 2025, Oracle and/or

    its affiliates 17 さらに、 パフォーマンス向上のためにも活⽤ • ⾃動索引 [19c] • ⾃動パーティション[19c] • ⾃動ゾーンマップ [21c] • ⾃動Materialized Views [21c] ①SQLの実⾏情報を⾼頻度で⾃動収集 (⾃動SQLチューニングセット) SQL Tuning Set 実⾏計画 履歴 ②リソースを⼤量消費する上位SQLを⾃動検出 (⾃動SQL計画管理) ④現⾏のベースラインと代替プランを⽐較し、 良い実⾏計画であればベースラインに⾃動登録 (SPM展開アドバイザ) 実⾏計画 Baseline PLAN (未承認) PLAN (未承認) PLAN (承認済) PLAN (未承認) PLAN (承認済) PLAN (採⽤) ⑤ベースラインに存在する実⾏計画を優先利⽤ (オプティマイザ) ③代替プランを⾃動検索 (⾃動SQL計画管理) Object Activity Tracking System [21c]
  13. ADB-Sのパッチ・メンテナンスに関するよくある質問 19 Copyright © 2025, Oracle and/or its affiliates 1.アプリケーションへの影響が発⽣するのでは︖

    お客様 メンテナンス中にアプリケーションへの影響が発⽣しない の︖ ・パッチ適⽤すると接続中のセッションが瞬断するんじゃないか︖
  14. ADB-Sのパッチ・メンテナンスに関するよくある質問 20 Copyright © 2025, Oracle and/or its affiliates 1.アプリケーションへの影響が発⽣するのでは︖

    Oracle ADBでは、パッチ適⽤時にもアプリケーションへの影響を発⽣ させないよう、⾼可⽤性を維持するための設計がされています。 ADBのパッチ適⽤は「ローリング適⽤」により実施されます。 そのため、パッチ適⽤中もサービスの継続性が確保されており、 接続中のセッションが瞬断(強制切断)しない技術が取り ⼊れられています。
  15. ADB-Sのメンテナンス l オラクル社にて⾃動適⽤ Ø お客様作業は不要 Ø 全てのコンポーネントが対象 - Firmware, OS,

    Hypervisor, Clusterware, Database - メンテナンスタイプは「Database」と「Infrastructure」。基本はDatabaseで毎週実施。Infrastructureは約3ヶ⽉に⼀回 Ø 事前定義されたメンテナンス・ウィンドウにて実施(緊急メンテナンス時を除く) - メンテナンス・ウィンドウはインスタンス作成時に決定 - 次回のメンテナンス・ウィンドウはコンソールおよびOCI Notificationによる通知から確認可 l アプリケーション(既存セッション)への影響 Ø パッチはオンラインもしくはローリングで適⽤︓DBとして停⽌時間なし - 再起動が⾏われるノードではFAN(Fast Application Notification)のドレインによって接続は別ノードへ⾃動的に切り替えが⾏われる - ※ FANのドレインとは、RACにおいてサービス停⽌やインスタンス停⽌時に「いきなりセッションを切断しないで、既存のセッションに猶予時間を与える」仕組み (デフォルトのFANドレイン・タイムアウトは300秒(5分)) - ドレイン・タイムアウトまでにトランザクションが終了しないセッションなど上記対応でカバーできないセッションは瞬断される - TAC(Transparent Application Continuity)の実装あれば上記の瞬断の保護可能。TACでカバーできない処理(⼀部のバッチ処理 等)についてはメンテナンス・ウィンドウから外して処理する等の⼯夫は必要 Ø やむを得ずサービス停⽌が必要となるメンテナンスについては、事前に通知の上で実施 - ハードウェアの⾃動アップグレード、Databaseのバージョンアップ等 21 Copyright © 2025, Oracle and/or its affiliates お客様の作業は不要でインフラ全体のメンテナンスを実施
  16. ADB-Sのメンテナンス l そもそも定期メンテナンスでセッション瞬断が発⽣しない構成がされている Ø Autonomous DatabaseではFANが内部実装。メンテナンス時にはDBは複数ノードで動作し、DB再起動が実施されるノードには 新規セッションは接続されず、既存セッションはドレイン処理が実施 l 透過的アプリケーション・コンティニュイティ(TAC)の有効化の検討 Ø

    DB障害時のエラー回避やドレイン・タイムアウトを超えるトランザクション処理がある場合には有効化を検討 Ø トランザクションがDBで完結せずTACで対応できない下記のようなジョブについては、メンテナンス・ウィンドウで実施すると影響発⽣ バッチ処理はメンテナンスウィンドウ外で実施すべき - DBMS_CLOUD.COPY_DATAによるインポート処理、expdp/impdpによるデータ移⾏処理 - SQL*Loaderによるデータロード - DBMS外部に対し操作を実⾏するプロシージャ • UTL_FILE, UTL_HTTP, DBMS_FILE, など l Application Continuityに関する参考資料はこちら Ø TechNightセミナー#39 「⾼可⽤性アーキテクチャ - アプリケーションの継続性] - 資料 : https://speakerdeck.com/oracle4engineer/apurikesiyonkonteiniyuitei - 動画 : https://www.youtube.com/watch?v=3PWbsQny1Mw 22 Copyright © 2025, Oracle and/or its affiliates 定期メンテナンスではDBは停⽌しない。TACの適⽤によって障害時のエラー回避も可能 オンラインでノード切り替される 通常のトランザクション処理ではセッション断しない メンテナンスウィンドウから外すことをご提案
  17. 23 Copyright © 2025, Oracle and/or its affiliates 補⾜資料︓ Fast

    Application Notification (FAN) とTransparent Application Continuity (TAC)の利⽤ Fast Application Notification(事前構成済み) コネクション・プールが物理コネクションを制御する機能 • 計画停⽌ - Oracleインスタンスshutdown前に物理コネク ションをアプリケーションから返却されたら切断する • ⾮計画停⽌ - コネクション・プールから該当物理コネクション を即時破棄 • サービス起動 - 物理コネクションのリバランス Transparent Application Continuity(追加設定) 接続ドライバによる⾃動再実⾏ 接続サービス毎に有効化するだけ • ⾮計画停⽌ - 物理コネクションが異常切断されたら⾃動再 接続して⾃動再実⾏ • アプリからは処理がわずかに遅れたようにみえる • ADBではコマンドにより有効化が必要 • アプリの⾔語やドライバのバージョンによって対応の有無が 出るので確認要。 データベース接続を積極的に制御する Connection Pool アプリケーション・サーバー Clusterware Clusterware FANイベント service service (T)AC 切断検出したら⾃動再実⾏ FAN DOWN/UP/負荷配分通知 RACノード 1 RACノード n
  18. 再接続 セッションが切断されても⾃動再接続&更新トランザクション⾃動再実⾏ アプリケーション Oracle接続ドライバ SQL 1 SQL 2 SQL 3

    SQL n COMMIT SQL 1 SQL 2 SQL 3 SQL n COMMIT Oracleサーバー SQL 1 SQL 2 SQL 3 SQL n COMMIT SQL 1 SQL 2 SQL 3 Oracle接続ドライバは 何を発⾏したかを記憶し ているので⾃動再実⾏ Copyright © 2025, Oracle and/or its affiliates 24 補⾜資料︓ (Transparent) Application Continuity
  19. 25 Copyright © 2025, Oracle and/or its affiliates Real Application

    Clusters Automatic Storage Management Storage Servers Database Servers ||| ・ ||| Container Database Autonomous Databaseインスタンス • 1つのプラガブル・データベース • ECPU単位でリソース制御。動的なリソース増減、オートス ケールに対応 • ECPU数に応じてメモリやストレージ帯域を割り当て • AutoSPMなど⾃動化機能を実装 Oracle Exadata Database Machine • Database ServerはOracle Real Application Clustersによるクラスタ構成 • ストレージはAutomatic Storage Managementによる ⾼可⽤性構成 • Smart Scan, Smart Flash Cacheなど Exadata System Softwareによる⾼速化機能を実装 CMAN* CMAN CMAN Load Balancer データベース接続 • 各データベースへはOracle Connection Managerを通 じて接続 • セッションの負荷分散やFANによる切り替えを実装 *Oracle Connection Manager 補⾜資料︓ ADB-Sのアーキテクチャ概念図 標準でCPU数にかかわらず 全コンポーネントで⾼可⽤性構成
  20. 基本2時間のウィンドウで毎週実施 OCIコンソールよりメンテナンス実施履歴を確認可能 リソースタイプがDatabaseの場合、DB再起動をただし、DB再起動を伴うケースと伴わないケースあり リソースタイプがInfrastructureの場合、VM/OSレイヤーのパッチ適⽤で再起動を伴い2時間のウィンドウを超える場合もあり 26 Copyright © 2025, Oracle and/or

    its affiliates 補⾜資料︓メンテナンス履歴の確認 - OCIコンソール メンテナンス開始時間と終了時間 メンテナンス対象のリソースタイプ Databaseのパッチでも種別 によって適⽤時間が異なる場 合がある 約2時間の場合もあり 約9分の場合もあり ※DB再起動は毎回発⽣す るわけではない。基本的には、 バイナリパッチ適⽤の際には DB再起動が伴う、ディクショナ リパッチ適⽤の際にはDB再起 動が無い
  21. ADB-Sのパッチ・メンテナンスに関するよくある質問 27 Copyright © 2025, Oracle and/or its affiliates 2.パッチ適⽤がとにかく不安。もしデグレが起きたらどうするのか︖

    お客様 過去Oracleのパッチ適⽤で失敗したり、デグレが発⽣し たケースがあってが不安。ADBでは発⽣しないのか︖ ・そもそも頻繁にパッチ適⽤を⾏って問題が発⽣しないのか︖ ・もしパッチ適⽤ミスやデグレが発⽣したら、どのような対処が⾏われるのか︖ ・問題があるパッチのロールバックってやってくれるの︖その際の作業影響や時間は︖
  22. ADB-Sのパッチ・メンテナンスに関するよくある質問 28 Copyright © 2025, Oracle and/or its affiliates 2.パッチ適⽤がとにかく不安。もしデグレが起きたらどうするのか︖

    Oracle ・オラクルはADBを継続的インテグレーションと開発(CI/CD)のプロセスに基づいた 開発・テスト・リリースを実施しており⾃動回帰テスト(⾃動リグレッションテスト)によ る品質確保を⾏うためのプロセスを実施しております。 また、本番環境に適⽤前に早期パッチおよびFree Tier環境で1週間前にパッチ適 ⽤を⾏い、ユーザーアクセプタンステストを実施した上で、通常環境に適⽤します。 このようなプロセスでADB品質を担保する取り組みを実施しております。 また、もし早期パッチ環境でパッチが起因した問題が発覚した場合はその問題が通常 パッチADBに伝搬しないための修正アクションを実施します。できるだけ速やかに問題 があるパッチの影響を最⼩化する措置が⾏われます。必要な場合には障害のあった ADBインスタンスがある環境に修正パッチをHot Patchとしてオンラインで緊急適⽤す るというケースもあります。 パッチをロールバックするケースの場合にはパッチ全体、または問題の要因となったパッ チのサブセットをロールバックします。
  23. Copyright © 2025, Oracle and/or its affiliates 29 重要なオンライン・パッチは、すべてのリージョンで8時間で配信可能 開発部⾨

    継続的インテグレーション Build Test Publish Sync ⾃動的デプロイ リリース管理 Dev Object store Dev Dev Dev QA サインオフ ソース管理 開発/安定/本番前環境 継続的デリバリー 継続的 インテグレーション 開発 本番テスト/Free DBs テスト ⼀週間前 ⽇曜 カットオフ ⽉曜 ビルド ⽕曜/⽔曜 デプロイ ⽊曜/⾦曜 QA, サインオフ 本番影響確認 QA Stable QA 本番前環境 Code Repo 本番DB適⽤ ⼩規模なリージョン から開始 本番適⽤ ADBS-21.10.2.1 完全に⾃動化され たパッチ OS、ASM、GI、 Exadata Infrastructureク ラウドVMなどへの パッチ... ADB-Sのメンテナンス・サイクル – CI/CDとテストサイクル
  24. 30 Copyright © 2025, Oracle and/or its affiliates l ⽬的について

    Ø ADBにおけるパッチ適⽤⽅式の⼀つで、通常パッチよりも1週間早くパッチを適⽤できます。これにより、開発環境やテスト環境で、本 番環境への通常パッチ適⽤前に新しいパッチをテストし、影響を事前に確認することができます。 l 適⽤について Ø お客様が適⽤させるパッチを選択できます。(早期パッチ or 通常パッチ) 補⾜資料︓ADBにおける早期パッチ(Early Patch)とは
  25. ADB-Sのパッチ・メンテナンスに関するよくある質問 31 Copyright © 2025, Oracle and/or its affiliates 3.早期パッチの提供時期が直前過ぎでは︖

    お客様 早期パッチの提供がされるのは良いけど、1週間前では テストが⼗分にできないよ。
  26. ADB-Sのパッチ・メンテナンスに関するよくある質問 32 Copyright © 2025, Oracle and/or its affiliates 3.早期パッチの提供時期が直前過ぎでは︖

    Oracle ADBが⾼頻度パッチ適⽤を導⼊することで1回のメンテナンスで適⽤するパッチが17個 (2025年5⽉の平均)であり、これは従来のOracle DatabaseのRUよりも⼤幅に少 ないため、ソフトウェアとしての差分が⼩さいことが品質の安定化につながっていると考えてお ります。 また、テストに関しては同様のご意⾒は多くいただいておりますが、ADBではテストを⾃動化 する機能を提供しております。Oracle Databaseが持つ⾃動テスト機能のあるReal Application Testingを有効活⽤したものです。本番データベース環境のリフレッシュ可能 クローンを早期パッチ環境で作成し、本番データベースのワークロードを⾃動取得し、早期 パッチ環境でそのワークロードを⾃動再⽣する「⾃動ワークロードリプレイ機能」でパッチ適⽤ テストの⾃動化が可能です。 この機能の詳細はこちらのマニュアルから確認願います。 https://docs.oracle.com/ja-jp/iaas/autonomous-database-serverless/doc/autonomous-real-application- testing.html#GUID-0B11E425-1216-4B17-837D-5929FD13C86F
  27. 33 Copyright © 2025, Oracle and/or its affiliates 通常のパッチタイプ環境のワークロードを⾃動取得し、早期パッチ環境でそのワークロードを⾃動再⽣する⾃動ワークロー ドリプレイ機能が提供されました。早期パッチ環境(ソースのリフレッシュ可能クローン)で週次パッチが適⽤されると、ソー

    スでキャプチャされたワークロードが⾃動的に実⾏されます。 ※早期パッチレベルが利⽤できるリージョンのみ(東京/⼤阪は可能) ⾃動ワークロード・リプレイ機能の有効化⼿順 1. リフレッシュ可能クローンをパッチレベルを早期パッチに設定して作成 2. ソース・データベースで以下を実⾏し、有効化とオプションでワークロードのキャプチャ設定を実施 BEGIN DBMS_CLOUD_ADMIN.ENABLE_FEATURE( feature_name => 'WORKLOAD_AUTO_REPLAY', params => JSON_OBJECT( 'target_db_ocid' VALUE 'OCID1.TENANCY.REGION..ID1', --リフレッシュ可能クローンのOCID(必須) 'capture_duration' VALUE 120, --ワークロードがキャプチャされる期間(1分〜720分) 'capture_day' VALUE 'MONDAY', -- キャプチャをする曜⽇ 'capture_time' VALUE '15:00')); -- キャプチャをスタートする時間 END; / Documentation: Test Workloads Against an Upcoming Patch blog: Safeguard Your Workloads Against Upcoming Patches in Autonomous Database ⾃動ワークロード・リプレイ
  28. 34 Copyright © 2025, Oracle and/or its affiliates テスト環境作成 通常パッチ

    本番環境 早期パッチ テスト環境 リフレッシュ可能クローン 1週前にテスト適⽤ ADBS-24.6.3.2 ADBS-24.6.4.2 ⾃動テスト AP SR作成 分析レポート リプレイ 修正 本番適⽤ ADBS-24.6.4.2 ORA-???発⽣ 毎週⾃動でテスト可能 Oracle お客様 万が⼀問題が 発⾒された場合 ⻘字︓お客様のテスト ⾚字︓Oracleの対応 早期パッチと⾃動ワークロードリプレイを利⽤したテストフロー
  29. Oracle DatabaseのRUにおけるパッチ修正は1回あたり(平均で)、約378 ADBにおけるパッチ修正数は1回あたり(平均で) 、約16 お客様商⽤環境でのパッチ適⽤は1年に1度、またはそれ以上での周期になるのではと想定しております つまり、Oracle DatabaseのRU1年分適⽤だと1回あたり(直近で)、1357 ADBでは毎週パッチ適⽤されるものの多い場合でも(直近で)、 64 ※修正数が少ないほどパッチ適⽤の影響度合いも少なく安全

    35 Copyright © 2025, Oracle and/or its affiliates No パッチ名称 DB修正数 1 ADBS-25.1.2.2 6 2 ADBS-25.1.3.2 1 3 ADBS-25.1.4.2 25 4 ADBS-25.1.5.2 1 5 ADBS-25.3.1.2 1 6 ADBS-25.3.3.2 4 7 ADBS-25.3.4.2 22 8 ADBS-25.4.1.2 2 9 ADBS-25.4.2.2 9 10 ADBS-25.4.3.2 64 11 ADBS-25.4.4.2 43 12 ADBS-25.4.5.2 4 13 ADBS-25.5.5.2 24 Autonomous Databaseのプロアクティブ・パッチ(2025年1⽉〜5⽉) 2024 2025 1⽉ 4⽉ 7⽉ 10⽉ 1⽉ 4⽉ 7⽉ 10⽉ RU 19.22.0 19.23.0 19.24.0 19.25.0 19.26.0 19.27.0 GI修正数 73 70 67 68 78 83 DB修正数 264 225 189 217 393 262 Oracle Database19c と Grid Infrastructureのプロアクティブ・パッチ 補⾜資料︓ Oracle DatabaseのRUとADBのパッチ修正数について
  30. ADBのサービスレベル契約(SLA)では、 99.95%を超える可⽤性が定められています 36 Copyright © 2025, Oracle and/or its affiliates

    Availability SLA with Autonomous Data Guard 99.95% 99.995% Availability SLA SLAメトリックは下記を含む: • クラウドワイドのインフラおよびソフトウェア・スタック • すべてのメンテナンスとパッチ適⽤ 毎⽇更新︓ADB-S可⽤性の状況をホームページ上で公開 https://www.oracle.com/autonomous-database/adb-global-database-metrics.html 補⾜資料︓ADBのSLAについて
  31. 1時間に約344億以上のクエリーが動作している。 (過去7⽇間の平均、全データセンターにおける1時間あたりのクエリ数 2025年7⽉31⽇時点。) 37 Copyright © 2025, Oracle and/or its

    affiliates https://www.oracle.com/autonomous-database/adb-global-database-metrics.html 【補⾜めも】 仮に全てのADBの5%がFree Tier環境、早期パッチ環境だった場合、 1時間あたり約17億クエリーが実⾏されている計算 補⾜資料︓ADBはどれくらいの規模で利⽤されているか︖
  32. Autonomous Databaseの価値マップ 技術的特⻑ 顧客にもたらす価値 他社製品や従来DBとの違い ローリングパッチ適⽤(FAN/TACあり) DB再起動・停⽌なしでパッチ適⽤が可能 多くのDBは停⽌を伴う。ADBはアプリ影響ゼロを ⽬指す構成 ⾃動スケーリング(ECPUベース)

    利⽤に応じた柔軟な拡張・縮⼩でコスト最適化 事前リソース予約が不要。秒単位の課⾦、利⽤に 応じて課⾦ Elastic Pool(論理グループ単位の課⾦) 多数のDBを統合管理・課⾦。無駄なリソースを省 き運⽤効率化 DB個別課⾦ではなく、プール単位で課⾦できる Oracle独⾃の仕組み 完全⾃動化された運⽤(バックアップ・監視等) 管理⼯数80%削減。⼈的ミスや属⼈性を排除 オンプレやVMベースでは⼿動運⽤が前提 APEX/AutoMLなど組込み済み開発環境 ノーコード/ローコードで⾼速な業務アプリや機械 学習モデルを構築可能 他社は別途機械学習ツールやWeb開発基盤が 必要なことが多い ⾼可⽤構成(RAC/Exadataベース) SLA 99.95%以上、災害対策にも対応 DB単体構成が多い。⾼可⽤性が担保されない ケースが多い BYOL対応 既存ライセンスを活かして移⾏コスト削減 他社クラウドでは再購⼊が必要なケースあり 39 Copyright © 2025, Oracle and/or its affiliates “サービス停⽌ゼロでコスト最適化” “開発も運⽤もお⼿軽”
  33. まとめと結論 Autonomous Database(ADB)のパッチ・メンテナンスについては、お客様からの懸念や質問が多いテーマですが、その多くは従来の オンプレミス環境における経験から来ているものだと想定しています。 しかし、ADBでは以下のようにパッチ・メンテナンスが「構造的に安全・計画的・⾼可⽤性」であることが保証されています。 Ø 全てのメンテナンスはRAC環境におけるローリングパッチで実施され、停⽌時間を発⽣させずに完了している Ø FANによる接続切替と5分間のドレイン・タイムアウトにより、アプリケーションの影響を最⼩限にしている Ø

    平均で毎時344億クエリを処理するグローバルスケールの信頼性と可⽤性 Ø 適⽤されるパッチの修正数も限定的で差分が少ないため、安全性が⾼い Ø 公式SLAと可⽤性実績も公開されており、透明性が確保されている https://www.oracle.com/autonomous-database/availability-metrics/ お客様が持つ「パッチは危険」「動作保証が不安」といった印象は、ADBの仕組みと実績を知ることで払拭できます。 だからこそ、⾃信を持ってADBを提案しましょう︕︕ それは、OracleのADBがグローバル規模で実証し続けている安全で信頼性の⾼い⾃動化クラウドプラットフォームだからです。 40 Copyright © 2025, Oracle and/or its affiliates