Oracle AI Databaseデータベース・サービス: BaseDB/ExaDB-Dの可用性

Oracle AI Database Servicesの可用性 Base Database Service/Exadata Database Service 日本オラクル株式会社
2026年4月7日

BaseDBとExaDBの可用性概要

Oracle Cloud上のOracle AI Databaseサービス Grid Infrastructure(GI) • サーバーのクラスタリング機能(Oracle Clusterware)とストレージ仮想化機能(Automatic
Storage Managment) • BaseDBのシングル構成でも構成される Real Application Clusters(RAC) • Active-Activeなデータベースのクラスタ機能 • ExaDB、ADBはデフォルトでRAC構成 Data Guard • 災害/障害対策のためのレプリケーション機能 • 東京/大阪リージョン間やリージョン内で自動構成 - リージョン内でもHWを分けられる耐障害性 Recovery Manager(RMAN) • Oracle Databaseの効率的なバックアップ・リストア 3 Copyright © 2026, Oracle and/or its affiliates | Oracle AI Databaseの高可用性機能を利用可能 BaseDB、ExaDB、ADB BaseDB(EP)、ExaDB、ADB VCN AD AD Tokyo Region Osaka Region プライマリ RAC セカンダリ Data Guard BaseDB(EE/HP/EP)、ExaDB、ADB BaseDB、ExaDB、ADB Recovery Service Recovery Service Object Storage Object Storage GI RMAN

Oracle Maximum Availability Architecture(MAA) 最高レベルのデータベース可用性とスケーラビリティを実現する推奨アーキテクチャリファレンス・アーキテクチャデプロイメントの選択肢高可用性(HA)の構成や運用方法
顧客インサイトと専門家からの推奨事項本番サイトレプリカ・サイトレプリケーション 24/7 Zero Downtime Migration (ZDM) Bronze Silver Gold Platinum 継続性 Application Continuity Edition-based Redefinition Online Redefinition アクティブ・レプリケーションデータ保護 Flashback ZDLRA+ ZRCV RMAN 高性能 True Cache Resource Management Database In-Memory スケール・アウトおよびライフサイクル RAC Globally Distributed AI Database FPP Real Application Testing Active Data Guard GoldenGate Full Stack DR 汎用システム Autonomous AI DB BaseDB, ExaDB Engineered Systems Multicloud Diamond Copyright © 2026, Oracle and/or its affiliates | 4

RTO: ローカル障害: 10秒以内サイト障害: 0から10 秒 RPO: 0もしくは限りなく0 Oracle Maximum
Availability Architecture（Oracle MAA) 停止が許されないシステム向けに標準化されたリファレンス・アーキテクチャ RTO: ローカル障害: 数分から時間サイト障害: 数時間から数日 RPO: < 15 分 RTO: ローカル障害: 数秒から数分サイト障害: 数時間から数日 RPO: < 15 分 RTO: ローカル障害: 1分以内サイト障害: < 5 分 RPO: 0もしくは限りなく0 Bronze Silver Gold Mission critical Gold with Exadata + オプション1 - GoldenGate と Oracle Database 19c もしくはオプション 2- (Active) Data Guard と Oracle AI Database 26ai Platinum Extreme availability 構成 GoldenGate 26aiでのレプリケーション + Oracle AI Database 26ai + RAC on Exadata + (Active) Data Guard Diamond (NEW) Dev, test, prod シングル・インスタンスDB Restartable バックアップ・リストア Business critical Silver with RAC + DBレプリケーション (Active) Data Guard + 自動フェイルオーバークライアント・フェイルオーバー DRベスト・プラクティス Prod/departmental Bronze + データベースHA構成 (RAC もしくはローカルData Guard) クライアント・フェイルオーバー HAベスト・プラクティス Application Continuity (オプション) RTO: ローカル障害: 20秒以内サイト障害: < 1 分 RPO: 0もしくは限りなく0 Copyright © 2026, Oracle and/or its affiliates | 5

OCI Region Availability Domain Fault Domain Fault Domain OCI Region
Availability Domain Fault Domain Fault Domain OCI Region Availability Domain Fault Domain 自動構成での高可用性構成イメージ Base Database Service シングル構成・フォルト・ドメイン(FD)指定可能・データベースのデータ領域は Block Storageを利用・Recovery Service or Object Storageへの自動バックアップ設定可能 Data Guard RAC構成 Active-Activeなクラスタリング構成・エディションはExtreme Performanceが必要・FD指定可能。指定しない場合、自動で別FDに配置・データベースのデータ領域は、VM間で共通の Block Storageを利用・ Recovery Service or Object Storageへの自動バックアップ設定可能 Extreme Performance Edition Data Guard構成計画/計画外停止に備えたDBレプリケーションでの冗長構成・フィジカル・スタンバイ。同一VCN、同一/別AD間で自動構成可能。同一ADの場合、自動で別FDに配置・DBシステムは同一エディション同士。スタンバイは１つ・RAC環境同士のData Guard構成も可能(VM) ・プライマリおよびスタンバイからの自動バックアップ取得が可能・Enterprise Edition以上・Active Data Guardは Extreme Performance Block Storage Block Storage Block Storage Block Storage Database Database Database Database Database VCN VCN VCN バックアップ OCI Object Storage or Copyright © 2026, Oracle and/or its affiliates | 6 Autonomous Recovery Service (RCV/ZRCV) OCI Object Storage or Autonomous Recovery Service (RCV/ZRCV) バックアップ OCI Object Storage or Autonomous Recovery Service (RCV/ZRCV) バックアップ OCI Object Storage or Autonomous Recovery Service (RCV/ZRCV) バックアップ

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 Exadata Database Service Oracle Databaseの高可用性プラクティスが詰まったExadata 7 Oracle Clusterware Real Application Clusters Service Automatic Storage Management SCAN Listener 可用性 > 99.95% 管理性 > 99.95% https://www.oracle.com/jp/cloud/sla/ デフォルトで各コンポーネントが冗長化 Copyright © 2026, Oracle and/or its affiliates | 7

参考) Exadataのメリット 8 ネットワーク障害の高速な検出 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によるフル・スタック・ヘルス・チェック（重大な問題のアラートあり）セル間のリバランスによるデータ・アクセラレータ・キャッシュの保持コントローラ・キャッシュ障害からの自動修復自動データ保護、健全性の保持するライフサイクル管理、サービス品質や性能維持、停止時の性能影響の最小化… アプリケーションへの影響を極小化 Exadataの組み込みの高可用性機能 Copyright © 2026, Oracle and/or its affiliates | 8

システム要件整理

データベース可用性: 停止時間の種類とリカバリ目標計画メンテナンスリカバリ可能なローカル障害リカバリ不可能な障害またはサイト障害パッチ適用アップグレード
RPO（リカバリ・ポイント/データ損失） RTO（リカバリ時間）停止時間の種類リカバリ目標時間計画停止計画外停止 Copyright © 2026, Oracle and/or its affiliates | 10

停止理由停止の種類停止理由計画外停止インスタンス障害(DBプロセス障害) サーバー障害ストレージ障害(ディスクおよび筐体障害) データ障害(特定ブロック破損) データ障害(人的エラー) データ障害(ストレージ全損障害)
サイト障害計画停止計画メンテナンスリソース変更(拡張) データベース・シオステムにおける停止影響範囲 Copyright © 2026, Oracle and/or its affiliates | 11

停止理由ごとの対策サーバーの冗長構成による対応

インスタンス障害またはサーバー障害時の挙動 VM内での障害発生時 • Oracle Grid Infrastructure(Oracle Clusterware)が監視対象リソースの障害を検知すると、リソースの再起動又はフェイルオーバーを試行 •
1ノードのシングル構成の場合、VM内で再起動インフラ障害によるVM障害発生時 • インフラ障害によってVMが停止した場合、自動インスタンス・リカバリを試み、正常なホスト上でのVM起動を試行 • データベースのインスタンス障害(VM内)発生時には発動しない自動での再起動もしくはフェイルオーバー OCR CRS CRS CRS Listener Oracle Listener Oracle Listener Oracle VIP VIP VIP VIP リソースが再起動できない場合はフェイルオーバークラスタ再構成 VM Copyright © 2026, Oracle and/or its affiliates | 14

可用性: データベース・インスタンス障害、サーバー障害時のRAC構成 Oracleインスタンス障害 • 一瞬でOracle Grid Infrastructureに検出される • Oracleインスタンス障害が検出されると正常ノードの Oracleインスタンスによって自動的にリカバリされる
• 最低1つのOracleインスタンスが正常動作していれば全データにアクセス可能(アプリケーションが動作する) OSより下の階層の障害 • OS以下の障害は正常ノードのOracle Grid Infrastructureがタイムアウトで検出 • ExaDBの場合、Exadata特有の高速な障害ノード検出が可能。アプリケーションへの影響を低減インスタンスやサーバー障害が発生すると正常ノードが自動リカバリ GI GI GI GI GI: Oracle Grid Infrastructure Copyright © 2026, Oracle and/or its affiliates | 15

高可用性の実現（HA構成との比較） HA(Active-Standby）構成障害時にストレージ接続の切り替えやデータベースの再起動が必要 RAC(Active-Active）構成全てのサーバが稼働しているためすぐに別のサーバで処理を引き継ぐことが可能 Oracle RACの特徴 Copyright
© 2026, Oracle and/or its affiliates | 16 共有ストレージ共有ストレージストレージ接続の切り替え稼働数分〜十数分本番機バックアップ機待機データベース再起動稼働稼働稼働全てのサーバのリソースを有効活用高速なフェイルオーバー数秒〜数十秒 ※フェイルオーバー: 稼動中のシステムやサーバに障害が発生した際に、自動的に待機システムに切り替える仕組み

障害影響の低減と縮退時のパフォーマンス維持 RACのノード数 3ノード以上（ExaDBでのみ構成可） 2ノード単一ノード障害時の障害影響障害影響は3台以上中の1台障害影響は2台中の1台復旧までのDBノード冗長性冗長構成あり 1台で冗長構成なし
復旧までの性能維持残りの2台以上で性能維持この状態でCPUを増やそうとするとき、 ExaDBではオンラインでCPUの追加も可残りの1台で性能維持。この状態でCPUを増やそうとするとき、 ExaDBではオンラインでCPUの追加も可ノード数が多い方が、障害発生から復旧完了までのシステム可用性が高い Copyright © 2026, Oracle and/or its affiliates | 17

コネクション・プールはOracleインスタンスとの物理コネクションを接続したままにする Real Application Clustersとコネクション・プール Connection Pool RACノード 1 RACノード n
アプリケーション・サーバー Clusterware Clusterware service service 停止起動計画外停止 (DBサーバー側のクラッシュ) トランザクションは自動でロールバックされるが... • TCPの性質でクライアント側が切断されたことに気付かずにハング状態になる障害パターンがある • 切断されたコネクションのトランザクションはエラーになる計画停止 (ローリング・パッチ適用など) Oracleインスタンスをコマンドで停止/起動する • トランザクション中にOracleインスタンスを停止させるとエラーになる • 接続されたままの物理コネクションを安全に切断できるか？ Oracleインスタンス/サービス起動接続リクエストを受け付け可能だが... • 起動してきたOracleインスタンス/サービスに物理コネクションが作成されるのはいつ？ Copyright © 2026, Oracle and/or its affiliates | 18

Connection Pool データベース・コネクションを積極的に制御する2つの機能群 Oracleインスタンスの停止をアプリケーションからマスクするアプリケーション・サーバー Clusterware Clusterware FANイベント service service
(Transparent) Application Continuity (透過的)アプリケーション・コンティニュイティ RACノード 1 RACノード n Fast Application Notification 高速アプリケーション通知 • 切断検出したら自動再実行 • (T)AC対応Oracle接続ドライバ • サーバー側のイベントをコネクション・プールに通知してコネクションを制御 • FAN対応コネクション・プール停止起動計画停止(コマンドで停止) 計画外停止(異常終了) • 障害ノードとのコネクションを即時破棄 • コネクションがプールに返却されたら切断計画外停止(異常終了) • 自動再接続＆自動再実行 ※透過的アプリケーション・コンティニュイティ(TAC)とはアプリケーション・コンティニュイティの動作モードの1つで、19c 以降ではほとんどの場合こちらを使用します Copyright © 2026, Oracle and/or its affiliates | 19

Fast Application Notification (FAN) / 高速アプリケーション通知 Oracle ClusterwareからOracleクライアントにメッセージ通知する仕組み Fast Application
Notification (FAN) • Oracle Clusterwareからクライアントにイベント通知 Oracle製コネクション・プールがFAN対応 • Universal Connection Pool for Java (UCP) • Oracle Call Interface(OCI) Session Pool • ODP.NET Unmanaged Driver Fast Connection Failover • DOWNイベントによるコネクション破棄 • 計画停止/非計画停止を区別 • UPイベントによるコネクション作成(UCP) Runtime Connection Load Balancing • Oracleインスタンスが負荷配分比率を算出 • リクエストを発行するOracleインスタンスを制御 • 物理コネクションのリバランス Connection Pool ノード 1 ノード 2 アプリケーション・サーバー Clusterware Clusterware FANイベント FANイベント service service Copyright © 2026, Oracle and/or its affiliates | 20

物理コネクションが異常切断されても更新トランザクションを安全に自動再実行アプリケーション・コンティニュイティ対応接続ドライバは Oracleサーバーに発行した処理を記憶している。 Oracle接続ドライバがセッション切断を検出すると (1) 再接続 (2) トランザクション状態の確認 (3) トランザクション再実行
まで自動で行う。アプリケーションから見るとエラーを検出せずにトランザクションが完了する。 Oracle製コネクション・プールからコネクションを取り出してCOMMITしたら返却するコードならコード改修は (ほぼ)不要。 (Transparent) Application Continuity (透過的)アプリケーション・コンティニュイティ (1) 再接続 (2) 状態確認 (3) 再実行 Oracleクライアント RAC SELECT INSERT UPDATE COMMIT Copyright © 2026, Oracle and/or its affiliates | 21

詳細はこちらの資料をご参照ください Oracle Databaseのネットワーク接続 https://speakerdeck.com/oracle4engin eer/oracle-database-oracle-net-services データベース・コネクションの積極的な制御 https://speakerdeck.com/oracle4engine er/transparent-application-continuity アプリケーション・コンティニュイティ https://speakerdeck.com/oracle4engin
eer/application-continuity Copyright © 2026, Oracle and/or its affiliates | 22

ASMのストレージ障害への対処ストレージ・デバイス障害時に自動切り離し • OSシステム・コールがエラーになるストレージ・デバイスをオフライン化、復旧できない場合は切り離す • 冗長化されていれば処理は継続 • ストレージ・パス障害の切り替えはOSのI/Oタイムアウトに依存 (60秒程度)
• Exadataならば数秒でノード障害を切り離せる • ストレージ・デバイスの増減にあわせてリバランスして冗長性を回復ファイル破損時の自動修復 • 読み取ったファイルの破損を「検出」するのはOracleのプロセスであるが... • ストレージ・デバイス以外の階層の異常でもストレージのデータを破損させる場合がある • ASMで冗長化している場合ファイル破損を検出すると自動的にミラーから読み取り処理継続し、破損箇所を自動修復 Oracle Clientに透過的かつ自動的な切り離し、再配置、ブロック修復データベースインスタンス ASM インスタンス 1 2 3 2 3 1 自動切り離し処理継続自動修復自動リバランス ASM利用の構成の場合 Copyright © 2026, Oracle and/or its affiliates | 23

停止理由ごとの対策データ・リカバリによる対策

データの複製をOracle自身が行い、自動破損チェックと自動修復 Oracle Databaseのデータ破損対策データ障害(特定ブロック破損) ハードウェアが故障していなくてもデータが破損していることがある ⇒ データ破損検査することで破損の伝搬を阻止 • バックアップ –
Recovery Manager & Zero Data Loss Autonomous Recovery Service • ミラー – Automatic Storage Management • レプリケーション – Active Data Guard レプリケーション Automatic Storage Management • スケールアウト・ストレージ • Stripe And Mirror Everything • データ破損の検出とミラーからの自動修復 Active Data Guard • REDOログ転送によるRPO=0も可能なデータベース全体の複製 • REDOログのデータ構造の検査 • ブロック破損を検出すると対向データベースから取り寄せ自動修復 Recovery Manager • Oracleインスタンスがファイル・アクセスする仕組みを使ったバックアップ/リカバリ • データ破損の検出 • 高速差分バックアップ Zero Data Loss Autonomous Recovery Service • RMANバックアップ + Data Guard REDO転送でRPOがほぼ0 • 差分バックアップの断片をつなぎ合わせてフル・バックアップ・ファイルを合成ミラー Copyright © 2026, Oracle and/or its affiliates | 26

データ・ブロックの破損が検出されると対向データベースから正常ブロックを取り寄せてリカバリ Active Data Guard自動ブロック・メディア・リカバリオンライン REDOログ・ファイル oracle Oracleサーバー・プロセスデータファイル
SGA 1. データ・ブロックの破損を検出したデータベース・バッファ・キャッシュデータファイル SGA プライマリ・データベーススタンバイ・データベース 2. 該当データ・ブロックを取り寄せる 3. リカバリ 4. SQL処理はエラーなく継続 ※スタンバイ・データベースでブロック破損が検出されるとプライマリ・データベースから該当ブロックを取り寄せてリカバリ Copyright © 2026, Oracle and/or its affiliates | 27 補足スライドデータ障害(特定ブロック破損)

Flashback Database/Data Guard/バックアップがカバーする範囲 INSERT UPDATE DELETE 時刻t1 バックアップ (長期間の過去状態の保存) 時間
INSERT UPDATE DELETE 欠損 Active Data Guard (最新状態のデータベースに短時間で切り替え) Flashback Database (比較的短期間の過去に戻す) ~数日数百~数十日バックアップ (長期間の過去状態の保存) REDO転送 (最新のREDO) バックアップ+アーカイブログがバックアップされているので、バックアップに含まれていない最新のREDO情報は戻せない可能性あり。復旧時間はバックアップ・サイズに依存 Zero Data Loss Autonomous Recovery Serviceはバックアップ +REDO転送で最新のREDO情報まで複製可能。アーカイブREDOログ・ファイルと同じ領域にUNDOブロックのバックアップを取得するので容量的にバックアップほどの長期間保持するのは難しい。データベースのファイルが破損していないことが前提。 Data Guardは転送されたREDOでリカバリを継続するので最新に近い状態のデータベースを維持する。時刻t1より前に戻すには Flashback Databaseと組み合わせる。 Copyright © 2026, Oracle and/or its affiliates | 28

指定した時刻までデータベースの状態を戻す Flashback Database データ障害(人的エラー) *23ai以降:FRA以外の領域を指定可能 (DB_FLASHBACK_LOG_DEST) Flashback Database 0. Flashback
Databaseを有効にすると、UNDOブロックのバックアップがFast Recovery Areaに取られる* 1. 戻したい指定時刻(時刻t1)より前のUNDOブロックをデータ用データファイルに直接リストア 2. REDOを適用して指定時刻(時刻t1)までロールフォワード ⇒データファイル全体をリストアするポイント・イン・タイムリカバリより速いし簡単オンラインREDOログアーカイブREDOログ時間時刻t0 時刻t2 リカバリ (REDOログの適用) Flashback Log (UNDOブロックのバックアップ) リストア (UNDOブロックの書き戻し) 時刻t1 リカバリを時刻t1までで止める最新データの時刻はt2 Copyright © 2026, Oracle and/or its affiliates | 29

Enterprise Editionの標準機能で、不完全リカバリを使わずにある時点に戻す・参照主な利用者種類機能名概要使用する情報 BaseDB
での利用 ExaDB での利用 DB 管理者リカバリ Flashback Database 指定した時刻までデータベースの状態を巻き戻しフラッシュバック・ログ EE以上: ◯ (DG構成:有効) ◯ (有効) Flashback Table 指定した時刻まで表や表セットの状態を巻き戻し UNDO EE以上: ◯ ◯ Flashback Drop DROP TABLE操作の巻き戻し Recyclebin ◯ ◯ AP 開発者 Flashback Transaction トランザクションおよび依存関係のあるトランザクションの操作の巻き戻し REDO EE以上: ◯ ◯ 参照 Flashback Transaction Query 特定のトランザクションの追跡 + UNDO SQLの取得 UNDO EE以上: ◯ ◯ Flashback Query 過去データの問い合わせ UNDO ◯ ◯ Flashback Versions Query どういう経緯で現在の値に至ったのか、過去のトランザクションの確認 UNDO ◯ ◯ Flashback Time Travel 特定の表に対する長時間の履歴保存フラッシュバック・アーカイブ領域 EE以上: ◯ ◯ Flashbackテクノロジー Copyright © 2026, Oracle and/or its affiliates | 30

バックアップ取得機能の種類 Autonomous Recovery Service 自動バックアップ • OCIの管理バックアップで自動取得 • RCVもしくはZRCVを選択 •
保護ポリシーにより保持(14-95日) • 取得スケジュール/保護ポリシーは要件に応じてカスタマイズ可能オンデマンドバックアップ • ユーザー操作で任意のタイミングでバックアップを取得 • RCV、ZRCVともに利用可能 • バックアップ保持期間は設定済みの保護ポリシーに準拠長期保存バックアップ(LTR) • ユーザー操作で長期保管用バックアップ (LTR)を任意のタイミングで作成 • 保持期間は90日間-10年間 • 自動バックアップとは独立し、 Object Storageに保管 • 期間内にリストアして新規DBを作成可能リージョン1 リージョン1 リージョン1 増分初回フル +永久増分 LTR Copyright © 2026, Oracle and/or its affiliates | 31

Oracle Managed Backups（推奨）データベース・バックアップの自動取得が設定可能 • 取得先 : 自律型リカバリ・サービス(デフォルト) or Object
Storage • 設定に基づき、特定の時間に日次で自動で取得される - バックアップ・ジョブの開始時間帯(UTC)や完全バックアップの曜日を指定可能 - 最初のバックアップは即時作成することを推奨 • バックアップは全て暗号化 • 取得先の変更可前提条件 • バックアップ取得先へのアクセスが可能なIAMポリシー・ネットワークの設定自動データベース・バックアップ取得先頻度と種類保持期間補足推奨自律型リカバリ・サービス (Autonomous Recovery Service) ・初回フル(Level 0) ・永久差分増分(Level 1) ・Oracle定義(14/35/65/95日)もしくはユーザー定義の保護ポリシーから選択(デフォルト 35日) ・90日-10年の長期バックアップ(LTR) も可・データ損失を限りなく減らす「リアルタイム・データ保護」機能あり・保持期間を過ぎるまで変更または削除を不可にする「保持ロック」機能あり Object Storage （オラクル管理バケット内）・週次フル(Level 0) ・日次差分増分(Level 1) ・7/15/30/45/60日から選択(デフォルト30日) ・削除するまで保持可能な長期バックアップ(スタンドアロン・バックアップ)も可 Copyright © 2026, Oracle and/or its affiliates | 32

Oracle Database Zero Data Loss Autonomous Recovery Service ランサムウェアに対する耐性を高めます •
ファイルを不可視化し、盗難を防止 • リアルタイムバックアップにより、感染直前までのリカバリーを可能 • 完全性が担保されたバックアップにより、確実に復旧可能バックアップにおける、本番環境への影響を極小化します • 増分バックアップの断片を合成し最新のフル・バックアップ相当ファイルを生成 • フル・バックアップ相当のファイルをリストアするため、リストア時間が短縮 • 増分バックアップ取得のみになるため、週次フル・バックアップは不要 • すべてのバックアップ・ファイルに対する検証をリカバリ・サービス内で実施クラウドにより、低コストかつシンプルな運用管理を実現します • 保護データ量のみに比例する価格体系 • 大規模なデータベース保護環境を、数クリックで構成可能 • データ保護に関する詳細なインサイトを取得するダッシュボードを提供 OCI、マルチクラウドおよびオンプレミス上のOracle Database向けインテリジェントなデータ保護実績のあるRecovery Applianceの技術を採用 Database @Azure Autonomous Database – Dedicated Zero Data Loss Autonomous Recovery Service Database @GCP Multicloud OCI Database @AWS Exadata Database Service Base Database Service Incremental Forever / Real-Time Redo Transport Cross-Domain / Cross-Region Fast Restore Clean Room Cloud Protect - New On-Premises / Any Linux x64 system Copyright © 2026, Oracle and/or its affiliates | 33

自律型リカバリ・サービス(Autonomous Recovery Service(RCV/ZRCV)) • ２つのモードから選択 • リアルタイム・データ保護無効 (RCV) - デフォルトの設定
- 対象DBバージョン: 19.16 or 21.7 以上 • リアルタイム・データ保護有効 (ZRCV) - REDOログをほぼリアルタイムに転送するため、データ損失を限りなくゼロにすることが可能。チェックボックスにチェックを入れると有効化 - 対象DBバージョン: 19.18 or 21.8 以上 • 保護ポリシー：14日間から95日間で設定可能 • Oracle定義の４種類のポリシー、もしくはユーザー定義のポリシーから選択 • ユーザー定義ポリシーは、事前に自律型リカバリ・サービスのコンソールもしくはAPIで設定 • Object Storage に設定していた自動バックアップの宛先を途中から変更することも可能自動データベース・バックアップでの推奨の取得先 OCI Documentation Database Autonomous Recovery Copyright © 2026, Oracle and/or its affiliates | 34

保存先によるバックアップ・リストアの違い自動データベース・バックアップバックアップ(自動) ・初回フルバックアップ(L0)を取得後、日次で差分増分バックアップ(L1)のみのため、バックアップ取得時間の短縮と負荷軽減・定期的にアーカイブREDOログのバックアップ・リアルタイムデータ保護を利用した場合、オンラインREDOログの常時転送・初回フルバックアップ(L0)を取得後、日次で差分増分バックアップ(L1)と週次でフルバックアップ(L0) ・定期的にアーカイブREDOログのバックアップ
リストア・リカバリ・仮想フルバックアップ(L0)+アーカイブREDOログのため高速(RTO) ・リアルタイムデータ保護(ZRCV)の場合、上記＋オンラインREDOログ・フルバックアップ(L0)+差分増分バックアップ(L1)+アーカイブREDOログ RPO ・オンラインREDOログも使用不可の場合、障害発生前の数時間以内(オンラインREDOログが利用可能であれば、障害発生直前まで) ・リアルタイムデータ保護(ZRCV)の場合、障害発生直前まで・オンラインREDOログも使用不可の場合、障害発生前の数時間以内 (オンラインREDOログが利用可能であれば、障害発生直前まで) ランサムウェア対策・バックアップの暗号化・犯人から見えない領域でバックアップを作成・保持・(ZRCVの場合)オンラインREDO利用不可の場合でも、破壊直前までのデータを復旧・バックアップデータの破損チェックにより完全性を担保・バックアップの暗号化自律型リカバリ・サービス (Autonomous Recovery Service(RCV)/ Zero Data Loss Autonomous Recovery Service(ZRCV)) 一般的なバックアップ運用 … リストア L0 L0 L1 L1 L1 L0 L1 L1 アーカイブREDOログ ......... リストア仮想フルバックアップで高速リストア初回フルバックアップ + 永久差分増分 L0 アーカイブREDOログ (ZRCVの場合)オンラインREDOログ (ZRCVの場合)RPO:障害発生直前 L0 L1 L1 L1 推奨 Copyright © 2026, Oracle and/or its affiliates | 35

参考情報 Oracle Database Zero Data Loss Autonomous Recovery Service サービス概要
https://speakerdeck.com/oracle4engineer/zrcv-overview • 概要、価格 • バックアップ取得とリストアの仕組み • コンソール・イメージなど自動バックアップのコスト比較リカバリ・サービス(RCV/ZRCV)とオブジェクト・ストレージ https://speakerdeck.com/oracle4engineer/rcvzrcv-objectstorage • 取得先の種類と仕組み • 見積もり方法など詳細な情報は下記公開資料をご参照ください Copyright © 2026, Oracle and/or its affiliates | 36

• 自動バックアップを有効にしている際に、RMANコマンドを利用したRMAN設定の変更は非推奨 • バックアップ処理実行中に、可用性を妨げる操作(パッチ適用など)を実行しないことが推奨 • バックアップが失敗した場合、自動バックアップは次回のバックアップ・ウィンドウで再試行されるため、バックアップが取得されていない時間帯でのデータロスの可能性がある • 手動バックアップを設定する場合 •
自動バックアップとの併用は非推奨のため、自動バックアップは無効に設定 • アーカイブ・ログの自動バックアップ・ジョブの設定を無効化自動バックアップ設定に関する推奨事項 Copyright © 2026, Oracle and/or its affiliates | 37

遠隔地保管要件への対応

リージョン2 リージョン1 リージョン2 リージョン1 ユーザー管理バケットリージョン2 リージョン1 データの遠隔地保管方式についてバックアップ
(Active) Data Guard バックアップ (ZRCV/RCV) バックアップ (ZRCV/RCV) コンソールから管理可能な方法バックアップ特徴 • ZRCV/RCVによる高いRTO/RPOを実装する自動バックアップ方式 • コンソールで管理可能 • 別リージョンへの新規インスタンス作成 (リストア・リカバリ)も可能 • 自動バックアップは利用せずに、バックアップ・リストアと遠隔地保管の方法をCLIベースでシンプルに実装 • (ZRCV/RCVは不可) • コンソールで簡単にバックアップ・リカバリが可能で、復旧が必要な障害時にスタンバイに即時切り替えもしくはリストアが可能なので、RTOを短くすることが可能。REDO受信のため、スタンバイの起動が必要バックアップ • ローカルに自動バックアップ取得(コンソールで管理) • ZRCV/RCVに取得されたバックアップは内部的に冗長化 • バックアップは自動取得(CLIで管理) • ファイルをObject Storageのユーザー管理バケットにおき、レプリケーション機能でリモートへコピー • Data Guardを構成し、リージョンごとにローカルにバックアップを取得(コンソールで管理。オブジェクト・ストレージも可) リモートへのデータ転送・なし • RMANのバックアップセット(圧縮) • Data GuardによるREDOの常時転送リストア・リカバリ・ローカルでの復旧はコンソールで可能・手動でリストア・リカバリ(コンソール不可) • Data Guardのスタンバイへの切り替え、もしくはリストア・リカバリ。コンソールで可能ユーザー管理バケットレプリケーションバックアップを使った新規インスタンス作成オラクル管理バケットオラクル管理バケットオラクル管理バケットコンソールで操作が完結+RTO/RPOの観点から、下記を推奨 Copyright © 2026, Oracle and/or its affiliates | 39 可用性

リージョン2 リージョン2 [バックアップ手法について] Data Pumpで論理バックアップを取得する場合現行システムでの運用を踏まえた、バックアップ・パターンを掲載した例コンソールから管理可能な方法特徴・ZRCV/RCVによる高いRTO/RPOを備えながら、現行に倣う形でData
Pumpによる表の論理バックアップを取得し遠隔地保管・Data Pumpのexpdp/impdpの実行は、従来通りのコマンドラインベースで運用し、Object Storageで遠隔地へ自動レプリケーション (Flashback機能の活用や、ExaDBの利用によるバックアップ時間の改善ができるなど、Data Pumpによる日次バックアップは不要という判断の場合) コンソール/APIで簡単に運用管理が可能で、復旧が必要な障害時にスタンバイに即時切り替えもしくは高速なリストアが簡単に可能なため、RTOが短いバックアップ・Data Guardを構成し、リージョンごとにローカルにバックアップを取得・コンソールで管理・Data Pumpは手動取得。Object Storageのユーザー管理バケットに出力・スタンバイからのバックアップ取得も可(図ではプライマリのみ) ・Data Guardを構成し、リージョンごとにローカルにバックアップを取得・コンソールで管理リモートへのデータ転送・Data GuardによるREDOの常時転送・Data Pumpのダンプ・ファイルをObject Storageのレプリケーション機能で自動リモートコピー(オラクル管理バケットでは不可) ・Data GuardによるREDOの常時転送リストア・リカバリ・バックアップからの復旧・DGのスイッチバック/フェイルバックはコンソールで可能・ZRCV/RCVの場合、リストア時間(RTO)が短くできる可能性あり・Data Pumpを利用する復旧は、手動でデータ・インポート・Data Guardのスタンバイへの切り替え、もしくはリストア・リカバリ。コンソールで可能・ZRCV/RCVの場合、リストア時間(RTO)が短くできる可能性ありリージョン1 Data Guard バックアップ・リストア (ZRCV/RCV) オラクル管理オラクル管理運用がシンプルな構成リージョン1 バックアップ (ZRCV/RCV) Data Pump ユーザー管理バケットユーザー管理バケットレプリケーションオラクル管理バケット Data Guard オラクル管理バケット Copyright © 2026, Oracle and/or its affiliates | 40

バックアップ考え方によって、取得先や取得先による設定方式を検討例) Exadata Database Serviceのデータベースのバックアップケース1 ExaDB-Dシステム内に取得ケース2 同一AD内の別サービスに取得ケース3
バックアップを別リージョンに複製方式 dbaascli 推奨コンソール/API dbaascli バックアップ取得先 ExaDB-Dシステム内(Exadata筐体内の RECO) 同一AD内のRCV/ZRCV 同一AD＋別リージョンのObject Storage(顧客管理バケット) 特徴・RECOを利用するので、その分DATA領域を小さく or ストレージ・サーバーを増やすため、利用するケース2や3よりコスト高の可能性あり・リストア時間(RTO)が短い* ・サービス・インスタンス(筐体)以上の範囲の障害時に復旧できないリスク → dbaascliでObject Storageと両方に取得する設定で対応。その場合、ケース3も設定可能・コンソール/API方式との併用不可・コンソール/APIから管理・操作が可能のため推奨・リストアや環境複製など、コンソール/API から簡単に実行・OCIの他のサービスとの連携(通知など) ・リージョン障害などの大規模障害に復旧できないリスク→Data Guard構成をとることで対応・RCV/ZRCVを利用する場合、ランサムウェア対策などセキュリティ向上・大規模障害への対応・Object Storageのレプリケーション機能を利用し、別リージョンにもバックアップを保持・コンソール/API方式との併用不可 *自律型リカバリ・サービスを利用した場合はリストアの考え方が異なる(リストアが早い実装)ため、ケース1の方がRTOが早くなるとは限らない可用性復旧(リストア)時間* Copyright © 2026, Oracle and/or its affiliates | 41

バックアップの取得方法

データファイルのコピーとREDOログの適用バックアップおよびリストア・リカバリ REDOログ・ファイル • 更新の履歴データファイル • データの本体用語意味
バックアップ (主にデータファイル) ファイルのコピーを取得することリストアバックアップ・ファイルから書き戻すことリカバリ REDOログをデータ・ブロックに適用すること Oracle Databaseではリストアとリカバリはセット REDOログ・ファイルの情報でデータファイルの内容を破損直前までもどす Copyright © 2026, Oracle and/or its affiliates | 43

BaseDBとExaDBのバックアップ推奨 Oracle管理バックアップ (自動バックアップ) • OCIの管理機能が自動で取得 • コンソールで管理、OCI APIから参照 •
ユーザーは取得スケジュールを要件に合わせてカスタマイズ • 任意のタイミングでバックアップ取得も可能 • OCIの他のサービスとの連携などが可能 • イベント・通知サービスなどでバックアップイベントの通知など • RMAN設定変更は非推奨 • 取得先は以下2種類のサービスから選択※ • 推奨Autonomous Recovery Service(RCV/ZRCV) • OCI Object Storage (Oracle管理バケット) 顧客管理バックアップ (手動バックアップ) • ユーザーが手動で取得 • ホスト側ツール(dbcli/dbaascliなど)で取得・運用管理が可能 • 取得スケジュール・TDE wallet保護・アーカイブログ保持/ クリーンアップ設計をユーザー側で担保 • Control Planeと非同期、ライフサイクル管理も非対応 • 細かな操作が実施可能の場合がある • 他リージョンへのレプリケーションをするためにOSS bucketへのバックアップの実施 • ExaDB-Dシステム(筐体)内へのバックアップ取得など • 取得先の例 • OCI Object Storage (顧客管理バケット) • ローカル Oracle AI Databaseのバックアップ取得方法自動バックアップの自動化処理が壊れるため、両者の併用はサポートされません。 ※新規テナンシの場合は、Autonomous Recovery Service(RCV/ZRCV)のみ選択可能 Copyright © 2026, Oracle and/or its affiliates | 44

BaseDBとExaDBのバックアップ推奨 Oracle管理バックアップ (自動バックアップ) • OCIの管理機能が自動で取得 • コンソールで管理、OCI APIから参照 •
ユーザーは取得スケジュールを要件に合わせてカスタマイズ • 任意のタイミングでバックアップ取得も可能 • OCIの他のサービスとの連携などが可能 • イベント・通知サービスなどでバックアップイベントの通知など • RMAN設定変更は非推奨 • 取得先は以下2種類のサービスから選択※ • 推奨Autonomous Recovery Service(RCV/ZRCV) • OCI Object Storage (Oracle管理バケット) 顧客管理バックアップ (手動バックアップ) • ユーザーが手動で取得 • ホスト側ツール(dbcli/dbaascliなど)で取得・運用管理が可能 • 取得スケジュール・TDE wallet保護・アーカイブログ保持/ クリーンアップ設計をユーザー側で担保 • Control Planeと非同期、ライフサイクル管理も非対応 • 細かな操作が実施可能の場合がある • 他リージョンへのレプリケーションをするためにOSS bucketへのバックアップの実施 • ExaDB-Dシステム(筐体)内へのバックアップ取得など • 取得先の例 • OCI Object Storage (顧客管理バケット) • ローカル Oracle AI Databaseのバックアップ取得方法自動バックアップの自動化処理が壊れるため、両者の併用はサポートされません。 ※新規テナンシの場合は、Autonomous Recovery Service(RCV/ZRCV)のみ選択可能以降は、Oracle推奨のバックアップ先であるRCV/ZRCVに絞り、機能・運用方法を解説しています。 Copyright © 2026, Oracle and/or its affiliates | 45

リストア・リカバリ方法

リストア・リカバリの種類 Autonomous Recovery Service バックアップ取得元のDBへリストア • ユーザー操作で任意の地点へリストア • リストア・タイプは3種類から選択 •
最新/タイムスタンプ/SCN • リアルタイムデータ保護オプション利用で RPOを最小化 • LTRはIn Place復旧の対象外最新のバックアップから新規DB作成 • ユーザー操作で任意の地点へリストアし、新規DBを作成 • リストア・タイプは3種類から選択 • 最新バックアップ/タイムスタンプ • RPOは選択した復旧ポイントと構成に依存任意のバックアップから新規DB作成 • 任意のバックアップを指定し、その地点の新規DBを作成 • 設定内容は新規DB作成時と同じ • 作成リージョンを指定して、他リージョンへのリストアも可能リージョン1 NEW リージョン1 リージョン1 NEW Copyright © 2026, Oracle and/or its affiliates | 48

Oracle Managed Backups（推奨）バックアップ取得元のDBへリストア • リストア可能な期間内での、任意のポイントへリストア可能 • CDB単位: 最新にリストア /
タイムスタンプにリストア(時間指定)/システム変更番号(SCN)にリストア • PDB単位: 最新にリストア / タイムスタンプにリストア(時間指定) • Data Guard構成で取得されたバックアップのリストア • Autonomous Recovery Serviceの場合は、取得元とリストア先のDBロールが異なってもリストア可能 • 明示的にどのロールで取得されたバックアップを利用するかは指定不可データベースのリストア・リカバリ Copyright © 2026, Oracle and/or its affiliates | 50

Oracle Managed Backups（推奨）最新・任意バックアップから新規DB作成 • 自動バックアップあるいはオンデマンド・バックアップで取得したバックアップから、新しいDBシステムを作成可能 • BaseDBの場合、エディションの変更は同等以上のエディションに限定されるリストア可能な期間内での、任意のポイントへリストア可能 •
最新のバックアップから新規DB作成 • CDB単位: 最新にリストア / タイムスタンプにリストア(時間指定) • PDB単位: 最新にリストア / タイムスタンプにリストア(時間指定) • 任意のバックアップから新規DB作成 • CDB単位: 最新にリストア / タイムスタンプにリストア(時間指定)/システム変更番号(SCN)にリストア • PDB単位:復元するPDBを指定可能 • Data Guard構成で取得されたバックアップのリストア • プライマリもしくはスタンバイから取得されたバックアップを利用可能データベースのリストア・リカバリ NEW Copyright © 2026, Oracle and/or its affiliates | 52

Oracle Managed Backups(推奨) 任意の時点でバックアップを取得可能 • コンソール or APIから実行可能 • バックアップの取得先がAutonomous
Recovery Service(RCV/ZRCV)の場合は増分バックアップ(Level 1)でバックアップを作成 • 自動バックアップが設定されていない場合は、スタンドアロン・バックアップとしてObject Storageに長期保存が可能 • ユースケース : 計画メンテナンスの前、データベース削除の前、環境複製時など • 実行中のバックアップ処理はキャンセル可能オンデマンド・バックアップ自動バックアップが設定されていない場合自動バックアップ構成されている場合 Copyright © 2026, Oracle and/or its affiliates | 54

• バックアップ保存先に、自律型リカバリ・サービスを利用する場合、最長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) マニュアル) https://docs.oracle.com/en/cloud/paas/recovery-service/dbrsu/longtermbackup-LTR-recoveryservice.html 既存バックアップ Object Storage Standard Object Storage Infrequent Access 24H Copyright © 2026, Oracle and/or its affiliates | 56

DBバックアップと基盤(VM/OS・Boot)バックアップの役割分担 DBバックアップは「DBデータ保護」、VM/OS・Bootは「環境復旧」目的 • Oracle管理のVM/Bootバックアップ：主にカタストロフィ障害(起動不能など)からの環境復旧を目的(復旧はSR等で実施) • DBバックアップ(手動・自動)： DBのバックアップ/復旧を目的(最新・時刻・SCNなどの復旧ポイント) 注意： VM/OSバックアップはパッチ適用やアップグレードのロールバック用途ではない(別手順)
DBバックアップと基盤バックアップは代替ではなく補完のため、目的に応じて両方を設計する (KB63696) Exadata Cloud Compute Node Backup and Restore Operations 役割と責任分界が異なる DB(データ)を守る VM/OS(環境)を守る Oracle管理 (標準で提供) Autonomous Recovery Service(RCV/ZRCV) ・DBの復旧(最新/時刻/SCN等) ・RPO最小化はリアルタイム保護(オプション) ・起動不能などの環境復旧を目的・ユーザーは直接アクセス不可(SRで復旧、サービスで異なる) BaseDB：Boot Volumeバックアップ(週次) ExaDB-D：基盤保護(サービス仕様に従う)※ 顧客管理 (要件により追加) CLI/RMAN等の手動運用・運用/鍵管理/保持は顧客責任構成/アプリ設定など追加要件に備えた保護例：設定ファイルの退避、外部ストレージ保管など ※基盤(VM/OS・Boot)バックアップの範囲・頻度・保持・復旧手順はサービスにより異なるため、最新のサービス仕様/ドキュメントに従う Copyright © 2026, Oracle and/or its affiliates | 57

中長期保管要件への対応

データベース終了後も保持*されるスタンドアロン・バックアップ中長期的なバックアップ保持の方式操作・管理概要保持期間取得先/SKU バックアップからの環境作成補足
コンソール/API オンデマンド・バックアップ (スタンドアロン・バックアップ) (RCV/ZRCVを利用していない場合のみ) 任意のタイミングで作成したバックアップを、 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 (手動) ユーザー手動バックアップ例1. dbaascli/dbcliツールを用いて、任意の場所へバックアップを取得例2. RMANコマンドでのバックアップ削除するまで Object Storage (ユーザー管理)など手動・自動バックアップ(Oracle管理)との併用は非サポート・Object Storageの機能(別リージョンへのコピーなど)も利用可能 *自動バックアップにて取得されたバックアップは、データベース終了後、 72時間もしくは保持期間まで保持したのちに削除される Copyright © 2026, Oracle and/or its affiliates | 59

中長期的なバックアップ保持の方式バックアップ保持日数の要件に合わせて使うツールを選択運用方法など他の要件次第で適切なツールを選択しましょう操作・管理保持日数の要件 1日- 14日間 14日間 – 95日間
90日間 – 10年それ以上コンソール/API 自動バックアップ(RCV/ZRCV) ◎ LTR ◎ オンデマンド・バックアップ (スタンドアロン・バックアップ) ◦ ◦ ◦ ◦ CLI (手動) ユーザー管理の手動バックアップ ◦ ◦ ◦ ◦ Copyright © 2026, Oracle and/or its affiliates | 60

停止理由ごとの対策データベース・システムが利用不可になる大規模障害

Data Guard 構成をUI/APIから簡単に、構成・管理・切り替え・障害後の回復が可能 • サービス・インスタンス間でのDBレプリケーション • 同一コンパートメント内、同一サービス間*、同一DBバージョン間 • 1つのプライマリ・データベースに対して、最大6個までのフィジカル・スタンバイ •
Data Guard構成 • 管理のためにData Guard Broker機能が有効 • Active Data GuardかData Guardの構成時選択・切替が可能 • 保護モードは、最大パフォーマンスモードか最大可用性モード • フェイルオーバー後のData Guard構成回復のために、Flashback Databaseが有効 • 上記の構成外の場合、手動でData Guardを構築も可能 - 別コンパートメント間、制限以上の複数スタンバイ、フィジカル・スタンバイ以外、OnPとの構成など自動Data Guard管理機能同期 Copyright © 2026, Oracle and/or its affiliates | 63 *ExaDB-DとExaDB-XSでのData Guard構成は可能

レプリカDBをData Guardで構成することのメリット • 自動データ同期によるデータ保護 • ブロック破損コピーの防止 • 自動ブロック破損修復 • 有事の迅速な切り替え
• 切り替え後に壊れた旧プライマリを簡単に復旧可能 • 計画停止時のサービス継続 • 有事の切り替えに備えた正常性確認 • 定期的な切り替えを推奨プライマリスタンバイ → プライマリ同期切り替え計画停止週末 22:00-08:00 データ保護(DR) メンテナンス切り替えプライマリ → スタンバイスタンバイ → プライマリ同期切り替え Copyright © 2026, Oracle and/or its affiliates | 64 • 参照系処理のオフロード • (19c-)更新処理も可能に • 普段から利用することによるレプリカ側のデータ正常性の確認 • スナップショット・スタンバイに一時的に切り替え検証利用同期リードレプリカ/検証プライマリスタンバイ

Data Guardアソシエーションが有効な環境の管理 Data Guard アソシエーションが有効な環境では、Data Guard Broker機能が有効 • Data Guard
Broker は、Data Guard環境を管理する仕組み(フレームワーク) • Data Guard Brokerのプロセスが、Data Guard環境の管理・監視 • ユーザーは、OS上でDGMGRLユーティリティを利用してData Guard環境の管理が可能 • OCIコンソール(UI)/APIでのData Guardの管理・運用は、 OS上のData Guard Brokerのプロセスと連携 • Data Guard Broker機能を無効化すると、UI/API などを用いた管理ができなくなるため、無効化しないでください Control Plane プライマリスタンバイ Data Guard Broker構成 dmon dmon Cloud Tooling Cloud Tooling Broker プロセス Broker プロセス DGMGRL> #dbaascli/dbcli API(ocicli/RESTなど) Copyright © 2026, Oracle and/or its affiliates | 65 参照) Data Guard Broker詳説 https://speakerdeck.com/oracle4engineer/dataguard-broker-detail

計画停止時の切り替え先として利用するケースローカル・スタンバイとリモート・スタンバイの用途の違いリージョン1(本番) リージョン2(DR) ローカル・スタンバイ • DB層の計画停止・計画外停止のローカル切り替え先 • 近距離でのレプリケーションでギャップ(データ差分)が少なく、 RPOとRTOが短い
• DB層で切り替えが必要となる場合も、AP層はそのままでレイテンシー(距離)を確保 • サイト障害時は切り替え先として利用不可リモート・スタンバイサイト障害などの大規模障害時の切り替え先 • 遠隔地でのレプリケーションのため、RPOとRTOがローカルと比べると長くなる • DB層のみの停止時、AP層は切り替えずにリージョン1で稼働し続ける場合はAPとDB間のレイテンシーが、AP層もリージョン2に切り替える場合は切り替え時間・作業が課題となるえる • RPO/RTO観点で計画停止・計画停止の内容に応じて使い分けられるよう、複数スタンバイを保持することが推奨 • ROI観点でスタンバイ側の利活用も検討プライマリスタンバイスタンバイ Copyright © 2026, Oracle and/or its affiliates | 66

参考) Full Stack Disaster Recovery Service サービス概要/特徴 • リージョン間のインフラストラクチャ、プラットフォーム、アプリケーションの移行をワンクリックで管理
• 複雑なリカバリー・プロセスをオーケストレーション可能 • データベース・サービス(Autonomous Database、Base Database、Exadata Database)とも完全に統合こんな課題に役立ちます • 各レイヤー(ストレージやデータベース)のレプリケーションをリージョン間で行っているが、万が一のリージョン切り替えまでは実装できていない • リージョン切り替えを独自に実装しているが、保守運用にかかる工数を減らしたいサービス価格 • ¥1.984 [OCPU/時間] • ¥0.496 [ECPU/時間] * DR保護グループ(Disaster Recovery Protection Group)に登録した OCIリソースのOCPU/ECPU数に対して課金フルマネージド・ディザスタ・リカバリ・サービス(DR) * 2026年1月現在 Copyright © 2026, Oracle and/or its affiliates | 67 サービス概要資料: https://speakerdeck.com/oracle4engineer/fsdr-overview

「リージョン間だけどRPOを高めたい(データロスの可能性を減らしたい) 」 Far Sync(遠隔同期)インスタンス構成例 • 遠隔地の場合、システム性能とデータ保護のバランスから非同期モードが選択されるため、リカバリ不能な停止によって生じる様々なレベルのデータ損失が発生 • Far
Sync(遠隔同期)インスタンスを利用することで、遠隔地スタンバイで実現が難しかった「データロスの可能性を低くする構成」を実現 • クラウド・ツールは対応していないので、自動Data Guard機能の構成に手動で設定変更 • Far Sync(遠隔同期)インスタンス(12.1以降) • REDO転送の中継地となる、Active Data Guardの機能 • Far SyncインスタンスにはDBライセンス不要 (制御ファイルとログ・ファイルのみ保持) • Far Syncインスタンスの冗長化も可能 ap-tokyo-1 AD1 VCN ap-osaka-1 AD1 VCN 同期非同期手動設定・管理 Copyright © 2026, Oracle and/or its affiliates | 68

「自動切り替えしたい」ファスト・スタート・フェイルオーバー構成 • デフォルトのData Guard構成の場合、障害時の切り替えは手動で明示的に行う。RTOを考えた時に、迅速に切り替えられるかを重要とし、自動で切り替えたいというケースもある • Data Guardのファスト・スタート・フェイルオーバー機能を利用
することで、自動フェイル・オーバーが可能 - OCIクラウド・ツールは対応していないので、手動で設定 • ファスト・スタート・フェイルオーバー(FSFO)概要 • Oracle Data Guard Brokerの機能 - Data Guard Broker有効+FSFO有効化 (FSFOデフォルト無効) • オブサーバという監視プロセスが切り替えを判断 - FSFOを有効にした上で、自動切り替えしない監視専用モードや手動切り替えも可 • オブサーバ・サーバーにはDBライセンス不要 • オブサーバの冗長化も可能(12.2以降) • Oracle Enterprise Manager Cloud Control でオブザーバーの監視が可能手動設定・管理 Database System Database System Virtual Machine Observer Primary Database Standby Database Copyright © 2026, Oracle and/or its affiliates | 69

停止理由ごとの対策計画停止(メンテナンスやスケーリング)

• スケール・アップ/ダウン(VMクラスタの拡張性)とスケール・アウト/イン(インフラの拡張性)が可能 BaseDBの拡張性特徴課金スケールアップ・ダウン • CPU、メモリー、ネットワーク帯域幅のスケーリングが可能 • シェイプ変更は再起動を伴うが、RACの場合はローリングで実施
• ストレージはオンラインでスケーリング可能 • CPU数に応じた課金変動 • ストレージサイズに応じた課金変動スケールアウト・イン • VM数など、作成後のスケールアウト・インは不可 • 計画的なスケーリング(夜間・週末停止やデータ量・トランザクション量の予測に応じた変更等)の場合は、メンテナンス時間を設けることで再起動の影響を抑えることが可能 • 計画外停止時の即時スケーリング(縮退運転の際のスケーリングや、災対サイトへの切り替え等)の際に、切り替え時間に再起動が含まれることを考慮 Copyright © 2026, Oracle and/or its affiliates | 71

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

Exadata Database Service 災対環境でのスケーリング • スケール・アップがオンラインで可能 • 迅速な切り替えが可能(RTO) • 割り当て済みのインフラ・リソース内は確実にスケーリ
ング可能 • スケール・アウトもオンラインで可能 • VM数(RACノード数)やインフラのサーバー数の変更 • 例) 本番はRAC構成・災対はシングル構成で、切り替え時にシングル構成を本番と同じRAC構成したいという場合もオンラインで可能 73 Copyright © 2026, Oracle and/or its affiliates | 平常時は最低限のリソースでコストを抑え、切り替え時に本番同等のリソースへスケーリングスケール・アップスケール・アウト停止切り替え先本番災対平常時切り替え時

変更方法オンデマンド変更 • コンソール/CLI/APIで即座に変更ジョブ・スクリプトでのスケジューリング • CLI/APIでの変更操作をスクリプト化するなど、手動設定での自動スケーリング可能例)
cronを使用してスクリプト実行自動スケーリングの実装 • Dynamic Scalingツールを導入し、CPU 負荷やスケジュールに応じた自動スケーリングを実装可 • チュートリアル: 『Oracle Exadata Cloud Infrastructureでの動的スケーリングの構成』 • 詳細/ツールのダウンロード: (ODyS) Oracle Dynamic Scaling Suite Main Index Page(KB583239) Exadata Database Service 利用可能CPU数の変更 Copyright © 2026, Oracle and/or its affiliates | 74 $ oci db cloud-vm-cluster update --cpu-core-count xxx --cloud-vm-cluster-id xxx … 23:00 CPU 0... 5:00 CPU 8…

参考資料 • PaaSサービスやOracle Databaseの情報については、最新情報をご確認ください • ドキュメント - OCI Base Database
Service 管理者ガイド - OCI Exadata Database Service on Dedicated Service 管理者ガイド - OCI Exadata Database Service on Exascale Service 管理者ガイド - Oracle Database 26ai 高可用性概要およびベスト・プラクティス • スライド (Spekerdeck) - Oracle Base Database Service 技術詳細 - Oracle Exadata Database Service on Dedicated Infrastructure 技術詳細 - Oracle Exadata Database Service on Exascale Infrastructure 技術詳細

Oracle AI Databaseデータベース・サービス: BaseDB/ExaDB-Dの可用性

Oracle AI Databaseデータベース・サービス: BaseDB/ExaDB-Dの可用性

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript