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

この資料は、Oracle AI Databaseデータベースのクラウド・サービス、Base Database Service と Exadata Database Serviceの可用性について説明しています。
対象サービス
・Base Database Service(BaseDB)
・Exadata Database Service on Dedicated Infrastructure (ExaDB-D)
・Exadata Database Service on Exascale Infrastructure (ExaDB-XS)

Transcript

1. Oracle AI Database Servicesの可用性 Base Database Service/Exadata Database Service 日本オラクル株式会社 2026年8月27日
2. BaseDBとExaDBの可用性概要
3. Oracle Cloud上のOracle AI Databaseサービス Oracle AI Databaseの高可用性機能を利用可能 Grid Infrastructure(GI) BaseDB、ExaDB、ADB • サーバーのクラスタリング機能(Oracle Clusterware)と ストレージ仮想化機能(Automatic Storage Managment) • BaseDBのシングル構成でも構成される Real Application Clusters(RAC) Tokyo Region AD AD VCN プライマリ セカンダリ GI BaseDB(EP)、ExaDB、ADB • Active-Activeなデータベースのクラスタ機能 Osaka Region RAC Data Guard • ExaDB、ADBはデフォルトでRAC構成 Data Guard BaseDB(EE/HP/EP)、ExaDB、ADB RMAN • 災害/障害対策のためのレプリケーション機能 • 東京/大阪リージョン間やリージョン内で自動構成 - リージョン内でもHWを分けられる耐障害性 Recovery Manager(RMAN) BaseDB、ExaDB、ADB • Oracle Databaseの効率的なバックアップ・リストア 8 Copyright © 2026, Oracle and/or its affiliates | Object Storage Recovery Service Object Storage Recovery Service
4. 高性能 Oracle Maximum Availability Architecture(MAA) 最高レベルのデータベース可用性とスケーラビリティを実現する推奨アーキテクチャ Resource Management Database In-Memory True Cache Platinum Diamond 継続性 顧客インサイトと専門家からの推奨事項 Application Continuity Online Redefinition Edition-based Redefinition データ保護 リファレンス・ アーキテクチャ 24/7 高可用性(HA)の 構成や運用方法 レプリケーション Flashback Gold Silver デプロイメントの選択肢 ZDLRA+ ZRCV アクティブ・レプリケーション レプリカ・サイト 本番サイト RMAN Active Data Guard Full Stack DR GoldenGate Bronze スケール・アウトおよびライフサイクル 9 汎用システム Engineered Systems Multicloud BaseDB, ExaDB Zero Downtime Migration (ZDM) Copyright © 2026, Oracle and/or its affiliates | Autonomous AI DB RAC Globally Distributed AI Database FPP Real Application Testing
5. Oracle Maximum Availability Architecture（Oracle MAA) 停止が許されないシステム向けに標準化されたリファレンス・アーキテクチャ Bronze Dev, test, prod シングル・インスタンスDB Restartable バックアップ・リストア Silver 10 Diamond (NEW) Prod/departmental Business critical Mission critical Extreme availability Bronze + Silver with RAC + 構成 データベースHA構成 (RAC も しくはローカルData Guard) DBレプリケーション (Active) Data Guard + 自動フェイルオーバー Gold with Exadata + オプション1 GoldenGate と Oracle Database 19c クライアント・フェイルオーバー HAベスト・プラクティス Application Continuity (オプション) RTO: ローカル障害: 数分から時間 サイト障害: 数時間から数日 RPO: < 15 分 Platinum Gold RTO: ローカル障害: 数秒から数分 サイト障害: 数時間から数日 RPO: < 15 分 Copyright © 2026, Oracle and/or its affiliates | クライアント・フェイルオーバー DRベスト・プラクティス RTO: ローカル障害: 1分以内 サイト障害: < 5 分 RPO: 0もしくは限りなく0 もしくは オプション 2(Active) Data Guard と Oracle AI Database 26ai RTO: ローカル障害: 20秒以内 サイト障害: < 1 分 RPO: 0もしくは限りなく0 GoldenGate 26aiでの レプリケーション + Oracle AI Database 26ai + RAC on Exadata + (Active) Data Guard RTO: ローカル障害: 10秒以内 サイト障害: 0から10 秒 RPO: 0もしくは限りなく0
6. Base Database Service 自動構成での高可用性構成イメージ シングル構成 Extreme Performance Edition RAC構成 ・フォルト・ドメイン(FD)指定可能 ・データベースのデータ領域は Block Storageを利用 ・Recovery Service or Object Storageへの 自動バックアップ設定可能 Active-Activeなクラスタリング構成 ・エディションはExtreme Performanceが必要 ・FD指定可能。指定しない場合、自動で別FDに配置 ・データベースのデータ領域は、VM間で共通の Block Storageを利用 ・ Recovery Service or Object Storageへの 自動バックアップ設定可能 OCI Region OCI Region Availability Domain VCN Fault Domain Data Guard構成 計画/計画外停止に備えたDBレプリケーションでの冗長構成 ・フィジカル・スタンバイ。同一VCN、同一/別AD間で 自動構成可能。同一ADの場合、自動で別FDに配置 ・DBシステムは同一エディション同士。スタンバイは１つ ・RAC環境同士のData Guard構成も可能(VM) ・プライマリおよびスタンバイからの自動バックアップ取得が可能 OCI Region Availability Domain Availability Domain VCN ・Enterprise Edition以上 ・Active Data Guardは Extreme Performance VCN Fault Domain Fault Domain Fault Domain Fault Domain Data Guard Database Database Block Storage Block Storage or 11 Autonomous Recovery Service (RCV/ZRCV) Copyright © 2026, Oracle and/or its affiliates | Database Block Storage Block Storage Autonomous Recovery Service (RCV/ZRCV) バックアップ or or OC I Object Storage Database バックアップ バックアップ バックアップ OCI Object Storage Database OC I Object Storage Autonomous Recovery Service (RCV/ZRCV) or OC I Object Storage Autonomous Recovery Service (RCV/ZRCV)
7. Exadata Database Service Oracle Databaseの高可用性プラクティスが詰まったExadata Exadata Database Serviceであれば高可用性構築の環境がすぐに利用可能 全てのコンポーネントが多重化、自己復元機能を搭載 • Real Application Clusters & Oracle Clusterware : DBのクラスタリング • Service : データベース・サービスを複数ノード上で抽象化 デフォルトで各コンポーネントが冗長化 • SCAN Listener : 接続サービスをクラスタレベルで抽象化 SCAN Listener • • Automatic Storage Management : 堅牢な共有ストレージ管理 内部ネットワーク : Active-Active RoCE ファブリック Service 様々な可用性機能がデフォルトで有効 Real Application Clusters • データ保護のためのチェック機能: ブロック破損や書き込み欠損のチェック Oracle Clusterware • Flashback Database : バックアップのリストアよりも短いRTOでの復旧 可用性構成を簡単に構築可能 Automatic Storage Management • RMAN: Oracle Databaseを安全に確実にリストアするためのバックアップ機能 • • Zero Data Loss Autonomous Recovery Service : 短いRTO/RPOでの復旧 Active Data Guard: 参照利用*可能で自動修復*を備えたDBレプリケーション機能 Exadata Database ServiceのSLA/SLO 12 Copyright © 2026, Oracle and/or its affiliates | 可用性 > 99.95% 管理性 > 99.95% https://www.oracle.com/jp/cloud/sla/
8. 参考) Exadataのメリット Exadataの組み込みの高可用性機能 電源停止時の冗長性チェック 読取りおよび書込みにおけるI/O待機時間制限 patchmgrによるデータベース・ノードの更新 Exadataディスク・スクラビング およびASM破損修復によるI/Oエラー回避 データベース・サーバーに対する障害モニタリング ILOMハングの検出および修復 ディスク取り外しのための自動LEDサポート インスタンス・リカバリ時の一時停止の短縮 セル・アラート用カスタム診断パッケージ 取り外しOKを知らせる青色LED通知 最適化、高速化されたExadataパッチ適用 Exadata HARD 自動オンライン 優先順位リバランスのサポート 自動データ保護、健全性の保持するライフサイクル管理、 セル間のリバランスによるフラッシュ・キャッシュの保持 ハード・ディスクのドロップと交換 サービス品質や性能維持、停止時の性能影響の最小化… 柔軟性のあるExadata構成 ディスク修復時におけるセルからセルへのオフロード コントローラ・キャッシュ障害からの自動修復 セル・シャットダウン時の冗長性保護 フラッシュとディスクのライフサイクル管理のアラート ネットワーク障害の高速な検出 最速のREDO Applyとインスタンス・リカバリ アプリケーションへの影響を極小化 フラッシュ障害後の効率的なリシルバ・リバランス Exadataスマート・ライトバック I/Oハングの検出および修復 EM障害レポート I/Oおよびネットワークのリソース管理 EXAchkによるフル・スタック・ヘルス・チェック（重大な問題のアラートあり） VLANのサポートおよび自動化 BBUのドロップと交換 ディスクの拘束 セル間のリバランスによるデータ・アクセラレータ・キャッシュの保持 HARDサポートによる破損回避 アクティブ/アクティブRoCEネットワーク 自動ディスク管理 I/Oエラー破損時における自動ASMミラー読取り 13 Copyright © 2026, Oracle and/or its affiliates | セルI/Oタイムアウトしきい値 障害と断定されるディスクのヘルス要素 ドライブ障害誤検出の排除 Exadata スマート・フラッシュ・ロギング cellsrvシャットダウン時の冗長性保護 Smart Write Back Flash Cache永続性 アプライアンス・モードのサポート セル・アラートのサマリー
9. システム要件整理
10. データベース可用性アセスメント: 停止時間の種類とリカバリ目標 停止時間の種類 リカバリ不可能な障害 またはサイト障害 リカバリ可能な ローカル障害 パッチ適用 アップグレード 計画 メンテナンス 計画外停止 計画停止 リカバリ目標 時間 RPO（リカバリ・ポイント/データ損失） 15 Copyright © 2026, Oracle and/or its affiliates | RTO（リカバリ時間）
11. アセスメント評価の項目 本日の説明内容 停止の種類 停止理由 インスタンス障害(DBプロセス障害) サーバー障害 ストレージ障害(ディスクおよび筐体障害) 計画外停止 データ障害(特定ブロック破損) データ障害(人的エラー) データ障害(ストレージ全損障害) サイト障害 計画停止 16 Copyright © 2026, Oracle and/or its affiliates | 計画メンテナンス リソース変更(拡張) 影響範囲
12. 停止理由ごとの対策 サーバーの冗長構成による対応
13. データベース・シオステムにおける停止 停止理由 停止の種類 停止理由 インスタンス障害(DBプロセス障害) サーバー障害 ストレージ障害(ディスクおよび筐体障害) 計画外停止 データ障害(特定ブロック破損) データ障害(人的エラー) データ障害(ストレージ全損障害) サイト障害 計画停止 25 Copyright © 2026, Oracle and/or its affiliates | 計画メンテナンス リソース変更(拡張) 影響範囲
14. インスタンス障害またはサーバー障害時の挙動 自動での再起動もしくはフェイルオーバー VM内での障害発生時 • Oracle Grid Infrastructure(Oracle Clusterware)が監 視対象リソースの障害を検知すると、リソースの再起 動又はフェイルオーバーを試行 • 1ノードのシングル構成の場合、VM内で再起動 インフラ障害によるVM障害発生時 • インフラ障害によってVMが停止した場合、自動インス タンス・リカバリを試み、正常なホスト上でのVM起動を 試行 • データベースのインスタンス障害(VM内)発生時に は発動しない クラスタ再構成 VIP VIP VIP Listener Listener Listener Oracle Oracle Oracle CRS CRS CRS OCR 27 VIP Copyright © 2026, Oracle and/or its affiliates | リソースが再起動 できない場合は フェイルオーバー VM
15. 可用性: データベース・インスタンス障害、サーバー障害時のRAC構成 インスタンスやサーバー障害が発生すると正常ノードが自動リカバリ Oracleインスタンス障害 • 一瞬でOracle Grid Infrastructureに検出される • Oracleインスタンス障害が検出されると正常ノードの Oracleインスタンスによって自動的にリカバリされる • 最低1つのOracleインスタンスが正常動作していれば 全データにアクセス可能(アプリケーションが動作する) GI GI GI GI OSより下の階層の障害 • OS以下の障害は正常ノードのOracle Grid Infrastructureがタイムアウトで検出 • ExaDBの場合、Exadata特有の高速な障害ノード 検出が可能。アプリケーションへの影響を低減 GI: Oracle Grid Infrastructure 28 Copyright © 2026, Oracle and/or its affiliates |
16. Oracle RACの特徴 高可用性の実現（HA構成との比較） HA(Active-Standby）構成 障害時にストレージ接続の切り替えやデータベースの 再起動が必要 RAC(Active-Active）構成 全てのサーバが稼働しているためすぐに別のサーバで処理 を引き継ぐことが可能 全てのサーバのリソースを 有効活用 本番機 バックアップ機 データベース 再起動 稼働 待機 共有ストレージ 数分〜十数分 29 Copyright © 2026, Oracle and/or its affiliates | 稼働 ストレージ接続 の切り替え 高速な フェイルオーバー 稼働 稼働 共有ストレージ 数秒〜数十秒 ※フェイルオーバー: 稼動中のシステムやサーバに障害が発生した際に、 自動的に待機システムに切り替える仕組み
17. RACのノード数 障害影響の低減と縮退時のパフォーマンス維持 3ノード以上（ExaDBでのみ構成可） 2ノード 単一ノード障害時の障害影響 障害影響は3台以上中の1台 障害影響は2台中の1台 復旧までのDBノード冗長性 冗長構成あり 1台で冗長構成なし 復旧までの性能維持 残りの2台以上で性能維持 この状態でCPUを増やそうとするとき、 ExaDBではオンラインでCPUの追加も可 残りの1台で性能維持。 この状態でCPUを増やそうとするとき、 ExaDBではオンラインでCPUの追加も可 ノード数が多い方が、障害発生から復旧完了までのシステム可用性が高い 30 Copyright © 2026, Oracle and/or its affiliates |
18. Real Application Clustersとコネクション・プール コネクション・プールはOracleインスタンスとの物理コネクションを接続したままにする アプリケーション・サーバー 計画外停止 (DBサーバー側のクラッシュ) トランザクションは自動でロールバックされるが... • TCPの性質でクライアント側が切断されたこ とに気付かずにハング状態になる障害パ ターンがある • 切断されたコネクションのトランザクションは エラーになる 計画停止 (ローリング・パッチ適用など) Oracleインスタンスをコマンドで停止/起動する • トランザクション中にOracleインスタンスを停 止させるとエラーになる • 接続されたままの物理コネクションを安全に 切断できるか？ Connection Pool service 停止 Clusterware RACノード 1 31 Copyright © 2026, Oracle and/or its affiliates | Oracleインスタンス/サービス起動 接続リクエストを受け付け可能だが... • 起動してきたOracleインスタンス/サービ スに物理コネクションが作成されるのは いつ？ service 起動 Clusterware RACノード n
19. Oracleインスタンスの停止をアプリケーションからマスクする データベース・コネクションを積極的に制御する2つの機能群 アプリケーション・サーバー Fast Application Notification 高速アプリケーション通知 • • サーバー側のイベントをコネクション・プール に通知してコネクションを制御 FAN対応コネクション・プール 計画外停止(異常終了) • 障害ノードとのコネクションを即時破棄 計画停止(コマンドで停止) • コネクションがプールに返却されたら切断 (Transparent) Application Continuity (透過的)アプリケーション・コンティニュイティ Copyright © 2026, Oracle and/or its affiliates | 切断検出したら自動再実行 (T)AC対応Oracle接続ドライバ FANイベント service 停止 Clusterware RACノード 1 32 • • Connection Pool service 起動 Clusterware RACノード n 計画外停止(異常終了) • 自動再接続＆自動再実行 ※透過的アプリケーション・コンティニュイティ(TAC)とはアプリ ケーション・コンティニュイティの動作モードの1つで、19c 以降ではほとんどの場合こちらを使用します
20. Fast Application Notification (FAN) / 高速アプリケーション通知 Oracle ClusterwareからOracleクライアントにメッセージ通知する仕組み Fast Application Notification (FAN) Connection Pool FANイベント service Clusterware ノード 1 33 Copyright © 2026, Oracle and/or its affiliates | アプリケーション・サーバー FANイベント service Clusterware ノード 2 • 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インスタンスを制御 物理コネクションのリバランス
21. (Transparent) Application Continuity (透過的)アプリケーション・コンティニュイティ 物理コネクションが異常切断されても更新トランザクションを安全に自動再実行 Oracleクライアント SELECT INSERT UPDATE COMMIT (1) 再接続 (2) 状態確認 (3) 再実行 RAC アプリケーション・コンティニュイティ対応接続ドライバは Oracleサーバーに発行した処理を記憶している。 Oracle接続ドライバがセッション切断を検出すると (1) 再接続 (2) トランザクション状態の確認 (3) トランザクション再実行 まで自動で行う。 アプリケーションから見るとエラーを検出せずにトランザ クションが完了する。 Oracle製コネクション・プールからコネクションを取り出 してCOMMITしたら返却するコードならコード改修は (ほぼ)不要。 34 Copyright © 2026, Oracle and/or its affiliates |
22. 詳細はこちらの資料をご参照ください 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 35 Copyright © 2026, Oracle and/or its affiliates |
23. ASM利用の 構成の場合 ASMのストレージ障害への対処 Oracle Clientに透過的かつ自動的な切り離し、再配置、ブロック修復 ストレージ・デバイス障害時に自動切り離し データベース インスタンス • OSシステム・コールがエラーになるストレージ・デバイスをオフライン化、 復旧できない場合は切り離す • 冗長化されていれば処理は継続 ASM インスタンス • ストレージ・パス障害の切り替えはOSのI/Oタイムアウトに依存 (60秒程度) • Exadataならば数秒でノード障害を切り離せる • ストレージ・デバイスの増減にあわせてリバランスして冗長性を回復 ファイル破損時の自動修復 • 読み取ったファイルの破損を「検出」するのはOracleのプロセスで あるが... 自動切り離し 自動リバランス 処理継続 1 2 2 3 3 1 自動修復 37 Copyright © 2026, Oracle and/or its affiliates | • ストレージ・デバイス以外の階層の異常でもストレージのデータを 破損させる場合がある • ASMで冗長化している場合ファイル破損を検出すると自動的に ミラーから読み取り処理継続し、破損箇所を自動修復
24. 停止理由ごとの対策 データ・リカバリによる対策
25. データベース・シオステムにおける停止 停止理由 停止の種類 停止理由 インスタンス障害(DBプロセス障害) サーバー障害 ストレージ障害(ディスクおよび筐体障害) 計画外停止 データ障害(特定ブロック破損) データ障害(人的エラー) データ障害(ストレージ全損障害) サイト障害 計画停止 39 Copyright © 2026, Oracle and/or its affiliates | 計画メンテナンス リソース変更(拡張) 影響範囲
26. データ障害(特定ブロック破損) Oracle Databaseのデータ破損対策 データの複製をOracle自身が行い、自動破損チェックと自動修復 ハードウェアが故障していなくてもデータが破損していることがある ⇒ データ破損検査することで破損の伝搬を阻止 • バックアップ – Recovery Manager & Zero Data Loss Autonomous Recovery Service • ミラー – Automatic Storage Management Active Data Guard • REDOログ転送によるRPO=0も可能なデータベース全体の複製 • レプリケーション – Active Data Guard • • REDOログのデータ構造の検査 ブロック破損を検出すると対向データベースから取り寄せ自動修復 レプリケーション ミラー Automatic Storage Management • スケールアウト・ストレージ • Stripe And Mirror Everything • データ破損の検出とミラーからの自動修復 41 Copyright © 2026, Oracle and/or its affiliates | Recovery Manager • Oracleインスタンスがファイル・アクセスする仕組みを使ったバックアップ/リカバリ • データ破損の検出 • 高速差分バックアップ Zero Data Loss Autonomous Recovery Service • RMANバックアップ + Data Guard REDO転送でRPOがほぼ0 • 差分バックアップの断片をつなぎ合わせてフル・バックアップ・ファイルを合成
27. 補足スライド データ障害(特定ブロック破損) Active Data Guard自動ブロック・メディア・リカバリ データ・ブロックの破損が検出されると対向データベースから正常ブロックを取り寄せてリカバリ Oracleサーバー・プロセス 1. データ・ブロックの破損を 検出した oracle 4. SQL処理はエ ラーなく継続 SGA SGA 3. リカバリ オンライン REDOログ・ ファイル 42 2. 該当データ・ブロックを 取り寄せる データファイル プライマリ・データベース Copyright © 2026, Oracle and/or its affiliates | データベース・ バッファ・ キャッシュ データファイル スタンバイ・データベース ※スタンバイ・データベースでブロック破損が検出されるとプライマリ・ データベースから該当ブロックを取り寄せてリカバリ
28. Flashback Database/Data Guard/バックアップがカバーする範囲 時刻t1 INSERT UPDATE DELETE ~数日 INSERT UPDATE DELETE Flashback Database (比較的短期間の過去に戻す) Data Guardは転送されたREDOでリカバリを継続するので最新に 近い状態のデータベースを維持する。時刻t1より前に戻すには Flashback Databaseと組み合わせる。 数百~数十日 43 バックアップ (長期間の過去状態の保存) 欠損 バックアップ (長期間の過去状態の保存) REDO転送 (最新のREDO) Copyright © 2026, Oracle and/or its affiliates | 時間 アーカイブREDOログ・ファイルと同じ領域にUNDOブロックのバック アップを取得するので容量的にバックアップほどの長期間保持する のは難しい。データベースのファイルが破損していないことが前提。 Active Data Guard (最新状態のデータベースに短時間で切り替え) バックアップ+アーカイブログがバックアップされているので、バックアッ プに含まれていない最新のREDO情報は戻せない可能性あり。復 旧時間はバックアップ・サイズに依存 Zero Data Loss Autonomous Recovery Serviceはバックアップ +REDO転送で最新のREDO情報まで複製可能。
29. データ障害(人的エラー) *23ai以降:FRA以外の領域を指定可能 (DB_FLASHBACK_LOG_DEST) Flashback Database 指定した時刻までデータベースの状態を戻す Flashback Database 0. Flashback Databaseを有効にすると、UNDOブロックのバックアップがFast Recovery Areaに取られる* 1. 戻したい指定時刻(時刻t1)より前のUNDOブロックをデータ用データファイルに直接リストア 2. REDOを適用して指定時刻(時刻t1)までロールフォワード ⇒データファイル全体をリストアするポイント・イン・タイムリカバリより速いし簡単 アーカイブREDOログ オンラインREDOログ Flashback Log (UNDOブロックのバックアップ) リストア (UNDOブロックの書き戻し) Copyright © 2026, Oracle and/or its affiliates | 時間 時刻t1 時刻t2 リカバリを時刻t1までで止める 最新データの時刻はt2 時刻t0 44 リカバリ (REDOログの適用)
30. Flashbackテクノロジー Enterprise Editionの標準機能で、不完全リカバリを使わずにある時点に戻す・参照 主な 利用者 種類 DB 管理者 リカバリ Flashback Database AP 開発者 参照 45 機能名 概要 使用する 情報 BaseDB での利用 ExaDB での利 用 指定した時刻までデータベースの状態を巻き戻し フラッシュバック・ ログ EE以上: ◯ (DG構成:有効) ◯ (有効) Flashback Table 指定した時刻まで表や表セットの状態を巻き戻し UNDO EE以上: ◯ ◯ Flashback Drop DROP TABLE操作の巻き戻し Recyclebin ◯ ◯ Flashback Transaction トランザクションおよび依存関係のあるトランザク ションの操作の巻き戻し REDO EE以上: ◯ ◯ Flashback Transaction Query 特定のトランザクションの追跡 + UNDO SQLの取 得 UNDO EE以上: ◯ ◯ Flashback Query 過去データの問い合わせ UNDO ◯ ◯ Flashback Versions Query どういう経緯で現在の値に至ったのか、過去のトラ ンザクションの確認 UNDO ◯ ◯ Flashback Time Travel 特定の表に対する長時間の履歴保存 フラッシュバック・ アーカイブ領域 EE以上: ◯ ◯ Copyright © 2026, Oracle and/or its affiliates |
31. 旧プライマリの回復 • フェイルオーバー後、旧プライマリはData Guard構成か ら外れるため、スタンバイがない状態 ①プライマリで障害発生、フェイルオーバー Standby → Primary Primary ②旧プライマリをFlashback Databaseで障害発生前の 時点に復旧 Primary ③復旧後、スタンバイとしてData Guard構成へ追加。 過去時点に戻った分のデータ差分は自動で同期 Standby 同期 ②と③をコンソール/CLIから簡単に実行できる 46 Copyright © 2026, Oracle and/or its affiliates | Primary • フェイルオーバーは、主に旧プライマリが利用できな い状態(壊れた状態)の際にスタンバイに切り替え がされるため、旧プライマリはData Guard構成から はずれる • 「回復」機能でコンソール上から簡単に、旧プライマリを スタンバイとしてデータベースを回復させてData Guard 構成を再編成可能 • Flashback Databaseの機能を利用した仕組みで、 Data Guard Brokerによってワンコマンドで実行され る
32. バックアップ取得機能の種類 Autonomous Recovery Service 自動バックアップ • OCIの管理バックアップで自動取得 • RCVもしくはZRCVを選択 • • オンデマンドバックアップ 長期保存バックアップ(LTR) • ユーザー操作で任意のタイミングで バックアップを取得 • ユーザー操作で長期保管用バックアップ (LTR)を任意のタイミングで作成 保護ポリシーにより保持(14-95日) • RCV、ZRCVともに利用可能 • 保持期間は90日間-10年間 取得スケジュール/保護ポリシーは 要件に応じてカスタマイズ可能 • バックアップ保持期間は 設定済みの保護ポリシーに準拠 • 自動バックアップとは独立し、 Object Storageに保管 • 期間内にリストアして新規DBを作成可能 リージョン1 初回フル +永久増分 リージョン1 リージョン1 増分 LTR 48 Copyright © 2026, Oracle and/or its affiliates |
33. 自動データベース・バックアップ 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日) ・削除するまで保持可能な長期バックアップ(スタン ドアロン・バックアップ)も可 49 Copyright © 2026, Oracle and/or its affiliates |
34. Oracle Database Zero Data Loss Autonomous Recovery Service OCI、マルチクラウドおよびオンプレミス上のOracle Database向けインテリジェントなデータ保護 ランサムウェアに対する耐性を高めます • ファイルを不可視化し、盗難を防止 • リアルタイムバックアップにより、感染直前までのリカバリーを可能 • 完全性が担保されたバックアップにより、確実に復旧可能 バックアップにおける、本番環境への影響を極小化します • 増分バックアップの断片を合成し最新のフル・バックアップ相当ファイルを生成 • フル・バックアップ相当のファイルをリストアするため、リストア時間が短縮 • 増分バックアップ取得のみになるため、週次フル・バックアップは不要 • すべてのバックアップ・ファイルに対する検証をリカバリ・サービス内で実施 クラウドにより、低コストかつシンプルな運用管理を実現します • 保護データ量のみに比例する価格体系 • 大規模なデータベース保護環境を、数クリックで構成可能 • データ保護に関する詳細なインサイトを取得するダッシュボードを提供 実績のあるRecovery Applianceの技術を採用 50 Copyright © 2026, Oracle and/or its affiliates | OCI Incremental Forever / Real-Time Redo Transport Autonomous Database – Dedicated Exadata Database Service Base Database Service Zero Data Loss Autonomous Recovery Service Multicloud Database @Azure Database Database @GCP @AWS Cross-Domain / Cross-Region Fast Restore Cloud Protect - New Clean Room On-Premises / Any Linux x64 system
35. 自動データベース・バックアップでの推奨の取得先 自律型リカバリ・サービス(Autonomous Recovery Service(RCV/ZRCV)) • ２つのモードから選択 • リアルタイム・データ保護無効 (RCV) - デフォルトの設定 対象DBバージョン: 19.16 or 21.7 以上 • リアルタイム・データ保護有効 (ZRCV) - REDOログをほぼリアルタイムに転送するため、データ損失を限りなくゼロに することが可能。チェックボックスにチェックを入れると有効化 - 対象DBバージョン: 19.18 or 21.8 以上 • 保護ポリシー：14日間から95日間で設定可能 • 51 • Oracle定義の４種類のポリシー、もしくはユーザー定義のポリシーから選択 • ユーザー定義ポリシーは、事前に自律型リカバリ・サービスのコンソール もしくはAPIで設定 Object Storage に設定していた自動バックアップの宛先を途中から変更することも可能 Copyright © 2026, Oracle and/or its affiliates | OCI Documentation Database Autonomous Recovery
36. 自動データベース・バックアップ 保存先によるバックアップ・リストアの違い 推奨 自律型リカバリ・サービス (Autonomous Recovery Service(RCV)/ Zero Data Loss Autonomous Recovery Service(ZRCV)) L0 L1 L1 L1 ......... 初回フルバックアップ + 永久差分増分 アーカイブREDOログ (ZRCVの場合)オンラインREDOログ リストア 一般的なバックアップ運用 L0 L1 L0 L1 L1 … アーカイブREDOログ L0 L0 仮想フルバックアップで高速リストア リストア L1 L1 (ZRCVの場合)RPO:障害発生直前 バックアップ(自動) ・初回フルバックアップ(L0)を取得後、日次で差分増分バックアップ(L1)のみのため、バックアップ取得時 間の短縮と負荷軽減 ・定期的にアーカイブREDOログのバックアップ ・リアルタイムデータ保護を利用した場合、オンラインREDOログの常時転送 ・初回フルバックアップ(L0)を取得後、日次で差分増分バックアップ(L1)と週次で フルバックアップ(L0) ・定期的にアーカイブREDOログのバックアップ リストア・リカバリ ・仮想フルバックアップ(L0)+アーカイブREDOログのため高速(RTO) ・リアルタイムデータ保護(ZRCV)の場合、上記＋オンラインREDOログ ・フルバックアップ(L0)+差分増分バックアップ(L1)+アーカイブREDOログ RPO ・オンラインREDOログも使用不可の場合、障害発生前の数時間以内(オンラインREDOログが利用可 能であれば、障害発生直前まで) ・リアルタイムデータ保護(ZRCV)の場合、障害発生直前まで ・オンラインREDOログも使用不可の場合、障害発生前の数時間以内 (オンライ ンREDOログが利用可能であれば、障害発生直前まで) ランサムウェア 対策 ・バックアップの暗号化 ・犯人から見えない領域でバックアップを作成・保持 ・(ZRCVの場合)オンラインREDO利用不可の場合でも、破壊直前までのデータを復旧 ・バックアップデータの破損チェックにより完全性を担保 ・バックアップの暗号化 52 Copyright © 2026, Oracle and/or its affiliates |
37. 参考情報 Oracle Database Zero Data Loss Autonomous Recovery Service 詳細な情報は下記公開資料をご参照ください サービス概要 自動バックアップのコスト比較 https://speakerdeck.com/oracle4engineer/zrcv-overview リカバリ・サービス(RCV/ZRCV)とオブジェクト・ストレージ https://speakerdeck.com/oracle4engineer/rcvzrcv-objectstorage • 概要、価格 • バックアップ取得とリストアの仕組み • コンソール・イメージ など 53 Copyright © 2026, Oracle and/or its affiliates | • 取得先の種類と仕組み • 見積もり方法 など
38. 自動バックアップ設定に関する推奨事項 • 自動バックアップを有効にしている際に、RMANコマンドを利用したRMAN設定の変更は非推奨 • バックアップ処理実行中に、可用性を妨げる操作(パッチ適用など)を実行しないことが推奨 • バックアップが失敗した場合、自動バックアップは次回のバックアップ・ウィンドウで再試行されるため、バックアップが取 得されていない時間帯でのデータロスの可能性がある • 手動バックアップを設定する場合 • 自動バックアップとの併用は非推奨のため、自動バックアップは無効に設定 • アーカイブ・ログの自動バックアップ・ジョブの設定を無効化 54 Copyright © 2026, Oracle and/or its affiliates |
39. 遠隔地保管要件への対応
40. コンソールから管理可能な方法 データの遠隔地保管方式について リージョン1 リージョン2 バックアップ バックアップを使った 新規インスタンス作成 コンソールで操作が完結+RTO/RPOの 観点から、下記を推奨 リージョン1 リージョン2 リージョン1 リージョン2 (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のスタンバイへの切り替え、もしくは リストア・リカバリ。コンソールで可能 可用性 56 Copyright © 2026, Oracle and/or its affiliates |
41. コンソールから管理可能な方法 [バックアップ手法について] Data Pumpで論理バックアップを取得する場合 現行システムでの運用を踏まえた、バックアップ・パターンを掲載した例 運用がシンプルな構成 リージョン1 リージョン2 リージョン1 リージョン2 Data Guard バックアップ (ZRCV/RCV) Data Guard バックアップ・リストア (ZRCV/RCV) 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)が短くできる可能性あり 57 Copyright © 2026, Oracle and/or its affiliates |
42. 例) 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)が短い* ・コンソール/APIから管理・操作が可能の ため推奨 ・リストアや環境複製など、コンソール/API から簡単に実行 ・OCIの他のサービスとの連携(通知など) ・リージョン障害などの大規模障害に復 旧できないリスク→Data Guard構成をとる ことで対応 ・RCV/ZRCVを利用する場合、ランサムウェ ア対策などセキュリティ向上 ・大規模障害への対応 ・Object Storageのレプリケーション機能を 利用し、別リージョンにもバックアップを保 持 ・コンソール/API方式との併用不可 ・サービス・インスタンス(筐体)以上の範囲 の障害時に復旧できないリスク → dbaascliでObject Storageと両方に取得 する設定で対応。その場合、ケース3も設 定可能 ・コンソール/API方式との併用不可 可用性 復旧(リストア)時間* 58 Copyright © 2026, Oracle and/or its affiliates | *自律型リカバリ・サービスを利用した場合はリストアの考え方が異なる(リストアが早い実装)ため、ケース1の方がRTOが早くなるとは限らない
43. バックアップの取得方法
44. バックアップおよびリストア・リカバリ データファイルのコピーとREDOログの適用 用語 意味 バックアップ (主にデータファイル) ファイルのコピーを取得すること リストア バックアップ・ファイルから書き戻すこと リカバリ REDOログをデータ・ブロックに適用すること Oracle Databaseではリストアとリカバリはセット REDOログ・ファイルの情報でデータファイルの内容を破損直前までもどす REDOログ・ファイル • 更新の履歴 60 Copyright © 2026, Oracle and/or its affiliates | データファイル • データの本体
45. BaseDBとExaDBのバックアップ Oracle AI Databaseのバックアップ取得方法 推奨 Oracle管理バックアップ (自動バックアップ) 顧客管理バックアップ (手動バックアップ) • OCIの管理機能が自動で取得 • ユーザーが手動で取得 • コンソールで管理、OCI APIから参照 • ホスト側ツール(dbcli/dbaascliなど)で取得・運用管理が可能 • ユーザーは取得スケジュールを要件に合わせてカスタマイズ • • 任意のタイミングでバックアップ取得も可能 取得スケジュール・TDE wallet保護・アーカイブログ保持/ クリーンアップ設計をユーザー側で担保 • OCIの他のサービスとの連携などが可能 • Control Planeと非同期、ライフサイクル管理も非対応 • 細かな操作が実施可能の場合がある • イベント・通知サービスなどでバックアップイベントの通知など • RMAN設定変更は非推奨 • 取得先は以下2種類のサービスから選択※ • 推奨Autonomous Recovery Service(RCV/ZRCV) • OCI Object Storage (Oracle管理バケット) • • 他リージョンへのレプリケーションをするためにOSS bucketへ のバックアップの実施 • ExaDB-Dシステム(筐体)内へのバックアップ取得など 取得先の例 • OCI Object Storage (顧客管理バケット) • ローカル 自動バックアップの自動化処理が壊れるため、両者の併用はサポートされません。 61 Copyright © 2026, Oracle and/or its affiliates | ※新規テナンシの場合は、Autonomous Recovery Service(RCV/ZRCV)のみ選択可能
46. BaseDBとExaDBのバックアップ Oracle AI Databaseのバックアップ取得方法 推奨 Oracle管理バックアップ (自動バックアップ) 顧客管理バックアップ (手動バックアップ) • OCIの管理機能が自動で取得 • ユーザーが手動で取得 • コンソールで管理、OCI APIから参照 • ホスト側ツール(dbcli/dbaascliなど)で取得・運用管理が可能 • ユーザーは取得スケジュールを要件に合わせてカスタマイズ • • 任意のタイミングでバックアップ取得も可能 取得スケジュール・TDE wallet保護・アーカイブログ保持/ クリーンアップ設計をユーザー側で担保 • OCIの他のサービスとの連携などが可能 • Control Planeと非同期、ライフサイクル管理も非対応 • 細かな操作が実施可能の場合がある • イベント・通知サービスなどでバックアップイベントの通知など • RMAN設定変更は非推奨 • 取得先は以下2種類のサービスから選択※ • 推奨Autonomous Recovery Service(RCV/ZRCV) • OCI Object Storage (Oracle管理バケット) 以降は、Oracle推奨のバックアップ先であるRCV/ZRCVに絞り、 機能・運用方法を解説しています。 • • 他リージョンへのレプリケーションをするためにOSS bucketへ のバックアップの実施 • ExaDB-Dシステム(筐体)内へのバックアップ取得など 取得先の例 • OCI Object Storage (顧客管理バケット) • ローカル 自動バックアップの自動化処理が壊れるため、両者の併用はサポートされません。 62 Copyright © 2026, Oracle and/or its affiliates | ※新規テナンシの場合は、Autonomous Recovery Service(RCV/ZRCV)のみ選択可能
47. バックアップ取得機能の種類 Autonomous Recovery Service 自動バックアップ • OCIの管理バックアップで自動取得 • RCVもしくはZRCVを選択 • • オンデマンドバックアップ 長期保存バックアップ(LTR) • ユーザー操作で任意のタイミングで バックアップを取得 • ユーザー操作で長期保管用バックアップ (LTR)を任意のタイミングで作成 保護ポリシーにより保持(14-95日) • RCV、ZRCVともに利用可能 • 保持期間は90日間-10年間 取得スケジュール/保護ポリシーは 要件に応じてカスタマイズ可能 • バックアップ保持期間は 設定済みの保護ポリシーに準拠 • 自動バックアップとは独立し、 Object Storageに保管 • 期間内にリストアして新規DBを作成可能 リージョン1 初回フル +永久増分 リージョン1 リージョン1 増分 LTR 63 Copyright © 2026, Oracle and/or its affiliates |
48. リストア・リカバリ方法
49. リストア・リカバリの種類 Autonomous Recovery Service バックアップ取得元のDBへリストア • ユーザー操作で任意の地点へリストア • リストア・タイプは3種類から選択 • 最新/タイムスタンプ/SCN リアルタイムデータ保護オプション利用で RPOを最小化 • LTRはIn Place復旧の対象外 • リージョン1 65 Copyright © 2026, Oracle and/or its affiliates | 最新のバックアップから新規DB作成 任意のバックアップから新規DB作成 • ユーザー操作で任意の地点へ リストアし、新規DBを作成 • 任意のバックアップを指定し、 その地点の新規DBを作成 • リストア・タイプは3種類から選択 • 設定内容は新規DB作成時と同じ 最新バックアップ/タイムスタンプ • 作成リージョンを指定して、 他リージョンへのリストアも可能 • • RPOは選択した復旧ポイントと 構成に依存 リージョン1 NEW リージョン1 NEW
50. リストア・リカバリの種類 Autonomous Recovery Service バックアップ取得元のDBへリストア • ユーザー操作で任意の地点へリストア • リストア・タイプは3種類から選択 • 最新/タイムスタンプ/SCN リアルタイムデータ保護オプション利用で RPOを最小化 • LTRはIn Place復旧の対象外 • リージョン1 66 Copyright © 2026, Oracle and/or its affiliates | 最新のバックアップから新規DB作成 任意のバックアップから新規DB作成 • ユーザー操作で任意の地点へ リストアし、新規DBを作成 • 任意のバックアップを指定し、 その地点の新規DBを作成 • リストア・タイプは3種類から選択 • 設定内容は新規DB作成時と同じ 最新バックアップ/タイムスタンプ • 作成リージョンを指定して、 他リージョンへのリストアも可能 • • RPOは選択した復旧ポイントと 構成に依存 リージョン1 NEW リージョン1 NEW
51. データベースのリストア・リカバリ Oracle Managed Backups（推奨） バックアップ取得元のDBへリストア • • 67 リストア可能な期間内での、任意のポイントへリストア可能 • CDB単位: 最新にリストア / タイムスタンプにリストア(時間指定)/システム変更番号(SCN)にリストア • PDB単位: 最新にリストア / タイムスタンプにリストア(時間指定) Data Guard構成で取得されたバックアップのリストア • Autonomous Recovery Serviceの場合は、取得元とリストア先のDBロールが異なってもリストア可能 • 明示的にどのロールで取得されたバックアップを利用するかは指定不可 Copyright © 2026, Oracle and/or its affiliates |
52. リストア・リカバリの種類 Autonomous Recovery Service バックアップ取得元のDBへリストア • ユーザー操作で任意の地点へリストア • リストア・タイプは3種類から選択 • 最新/タイムスタンプ/SCN リアルタイムデータ保護オプション利用で RPOを最小化 • LTRはIn Place復旧の対象外 • リージョン1 68 Copyright © 2026, Oracle and/or its affiliates | 最新のバックアップから新規DB作成 任意のバックアップから新規DB作成 • ユーザー操作で任意の地点へ リストアし、新規DBを作成 • 任意のバックアップを指定し、 その地点の新規DBを作成 • リストア・タイプは3種類から選択 • 設定内容は新規DB作成時と同じ 最新バックアップ/タイムスタンプ • 作成リージョンを指定して、 他リージョンへのリストアも可能 • • RPOは選択した復旧ポイントと 構成に依存 リージョン1 NEW リージョン1 NEW
53. データベースのリストア・リカバリ Oracle Managed Backups（推奨） 最新・任意バックアップから新規DB作成 • 自動バックアップあるいはオンデマンド・バックアップで取得したバックアップから、新しいDBシステムを作成可能 • BaseDBの場合、エディションの変更は同等以上のエディションに限定される リストア可能な期間内での、任意のポイントへリストア可能 • • • 最新のバックアップから新規DB作成 • CDB単位: 最新にリストア / タイムスタンプにリストア(時間指定) • PDB単位: 最新にリストア / タイムスタンプにリストア(時間指定) 任意のバックアップから新規DB作成 • CDB単位: 最新にリストア / タイムスタンプにリストア(時間指定)/システム変更番号(SCN)にリストア • PDB単位:復元するPDBを指定可能 Data Guard構成で取得されたバックアップのリストア • 69 プライマリもしくはスタンバイから取得されたバックアップを利用可能 Copyright © 2026, Oracle and/or its affiliates | NEW
54. バックアップ取得機能の種類 Autonomous Recovery Service 自動バックアップ • OCIの管理バックアップで自動取得 • RCVもしくはZRCVを選択 • • オンデマンドバックアップ 長期保存バックアップ(LTR) • ユーザー操作で任意のタイミングで バックアップを取得 • ユーザー操作で長期保管用バックアップ (LTR)を任意のタイミングで作成 保護ポリシーにより保持(14-95日) • RCV、ZRCVともに利用可能 • 保持期間は90日間-10年間 取得スケジュール/保護ポリシーは 要件に応じてカスタマイズ可能 • バックアップ保持期間は 設定済みの保護ポリシーに準拠 • 自動バックアップとは独立し、 Object Storageに保管 • 期間内にリストアして新規DBを作成可能 リージョン1 初回フル +永久増分 リージョン1 リージョン1 増分 LTR 70 Copyright © 2026, Oracle and/or its affiliates |
55. オンデマンド・バックアップ Oracle Managed Backups(推奨) 任意の時点でバックアップを取得可能 • • • • • コンソール or APIから実行可能 バックアップの取得先がAutonomous Recovery Service(RCV/ZRCV)の場合は増分バックアップ(Level 1)でバックアップを作成 自動バックアップが設定されていない場合は、 スタンドアロン・バックアップとしてObject Storageに長期保存が可能 ユースケース : 計画メンテナンスの前、データベース削除の前、環境複製時など 実行中のバックアップ処理はキャンセル可能 自動バックアップが設定されていない場合 自動バックアップ構成されている場合 71 Copyright © 2026, Oracle and/or its affiliates |
56. バックアップ取得機能の種類 Autonomous Recovery Service 自動バックアップ • OCIの管理バックアップで自動取得 • RCVもしくはZRCVを選択 • • オンデマンドバックアップ 長期保存バックアップ(LTR) • ユーザー操作で任意のタイミングで バックアップを取得 • ユーザー操作で長期保管用バックアップ (LTR)を任意のタイミングで作成 保護ポリシーにより保持(14-95日) • RCV、ZRCVともに利用可能 • 保持期間は90日間-10年間 取得スケジュール/保護ポリシーは 要件に応じてカスタマイズ可能 • バックアップ保持期間は 設定済みの保護ポリシーに準拠 • 自動バックアップとは独立し、 Object Storageに保管 • 期間内にリストアして新規DBを作成可能 リージョン1 初回フル +永久増分 リージョン1 リージョン1 増分 LTR 72 Copyright © 2026, Oracle and/or its affiliates |
57. 長期バックアップ保存(LTR) 最長10年までの長期保管用バックアップ • バックアップ保存先に、自律型リカバリ・サービスを利用する場合、 最長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/月 既存バックアップ Object Storage Standard 24H マニュアル) https://docs.oracle.com/en/cloud/paas/recovery-service/dbrsu/longtermbackup-LTR-recoveryservice.html 73 Copyright © 2026, Oracle and/or its affiliates | Object Storage Infrequent Access
58. DBバックアップと基盤(VM/OS・Boot)バックアップの役割分担 役割と責任分界が異なる DBバックアップは「DBデータ保護」、VM/OS・Bootは「環境復旧」目的 Oracle管理のVM/Bootバックアップ： 主にカタストロフィ障害(起動不能など)からの環境復旧を目的(復旧はSR等で実施) • DBバックアップ(手動・自動)： DBのバックアップ/復旧を目的(最新・時刻・SCNなどの復旧ポイント) 注意： VM/OSバックアップはパッチ適用やアップグレードのロールバック用途ではない(別手順) DBバックアップと基盤バックアップは代替ではなく補完のため、目的に応じて両方を設計する • DB(データ)を守る VM/OS(環境)を守る Oracle管理 (標準で提供) Autonomous Recovery Service(RCV/ZRCV) ・DBの復旧(最新/時刻/SCN等) ・RPO最小化はリアルタイム保護(オプション) ・起動不能などの環境復旧を目的 ・ユーザーは直接アクセス不可(SRで復旧、サービスで異なる) BaseDB：Boot Volumeバックアップ(週次) ExaDB-D：基盤保護(サービス仕様に従う)※ 顧客管理 (要件により追加) CLI/RMAN等の手動運用 ・運用/鍵管理/保持は顧客責任 構成/アプリ設定など追加要件に備えた保護 例：設定ファイルの退避、外部ストレージ保管 など ※基盤(VM/OS・Boot)バックアップの範囲・頻度・保持・復旧手順はサービスにより異なるため、最新のサービス仕様/ドキュメントに従う (KB63696) Exadata Cloud Compute Node Backup and Restore Operations 74 Copyright © 2026, Oracle and/or its affiliates |
59. 中長期保管要件への対応
60. 中長期的なバックアップ保持の方式 データベース終了後も保持*されるスタンドアロン・バックアップ 操作・ 管理 コンソール/API CLI (手動) 76 *自動バックアップにて取得されたバックアップは、データベース終了後、 72時間もしくは保持期間まで保持したのちに削除される 概要 保持期間 取得先/SKU バックアップから の環境作成 補足 オンデマンド・バック アップ (スタンドアロン・ バックアップ) (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 ユーザー 手動バックアップ 例1. dbaascli/dbcliツールを用いて、任 意の場所へバックアップを取得 例2. RMANコマンドでのバックアップ 削除 するまで Object Storage (ユーザー管理)など 手動 Copyright © 2026, Oracle and/or its affiliates | ・自動バックアップ(Oracle管 理)との併用は非サポート ・Object Storageの機能(別 リージョンへのコピーなど)も利用 可能
61. 中長期的なバックアップ保持の方式 バックアップ保持日数の要件に合わせて使うツールを選択 運用方法など他の要件次第で適切なツールを選択しましょう 操作・管理 保持日数の要件 コンソール/API 自動バックアップ(RCV/ZRCV) 1日- 14日間 14日間 – 95日間 77 それ以上 ◎ ◎ LTR CLI (手動) 90日間 – 10年 オンデマンド・バックアップ (スタンドアロン・バックアップ) ◦ ◦ ◦ ◦ ユーザー管理の 手動バックアップ ◦ ◦ ◦ ◦ Copyright © 2026, Oracle and/or its affiliates |
62. 停止理由ごとの対策 データベース・システムが利用不可になる大規模障害
63. データベース・シオステムにおける停止 停止理由 停止の種類 停止理由 インスタンス障害(DBプロセス障害) サーバー障害 ストレージ障害(ディスクおよび筐体障害) 計画外停止 データ障害(特定ブロック破損) データ障害(人的エラー) データ障害(ストレージ全損障害) サイト障害 計画停止 79 Copyright © 2026, Oracle and/or its affiliates | 計画メンテナンス リソース変更(拡張) 影響範囲
64. 自動Data Guard管理機能 Data Guard 構成をUI/APIから簡単に、構成・管理・切り替え・障害後の回復が可能 • 同期 • サービス・インスタンス間でのDBレプリケーション • 同一コンパートメント内、同一サービス間*、同一DBバージョン間 • 1つのプライマリ・データベースに対して、最大6個までのフィジカル・スタンバイ Data Guard構成 • 管理のためにData Guard Broker機能が有効 • Active Data GuardかData Guardの構成時選択・切替が可能 • 保護モードは、最大パフォーマンスモードか最大可用性モード • フェイルオーバー後のData Guard構成回復のために、Flashback Databaseが有効 • 上記の構成外の場合、手動でData Guardを構築も可能 - 81 Copyright © 2026, Oracle and/or its affiliates | 別コンパートメント間、制限以上の複数スタンバイ、 フィジカル・スタンバイ以外、OnPとの構成など *ExaDB-DとExaDB-XSでのData Guard構成は可能
65. レプリカDBをData Guardで構成することのメリット リードレプリカ/検証 メンテナンス切り替え データ保護(DR) 計画停止 週末 22:00-08:00 同期 切り替え 同期 同期 切り替え プライマリ • • • スタンバイ → プライマリ プライマリ → スタンバイ • 自動データ同期によるデータ保護 • • ブロック破損コピーの防止 • 自動ブロック破損修復 有事の迅速な切り替え 切り替え後に壊れた旧プライマリを簡単に復 旧可能 82 Copyright © 2026, Oracle and/or its affiliates | スタンバイ → プライマリ 計画停止時のサービス継続 有事の切り替えに備えた正常性確認 • 定期的な切り替えを推奨 プライマリ • • • スタンバイ 参照系処理のオフロード • (19c-)更新処理も可能に 普段から利用することによるレプリカ側の データ正常性の確認 スナップショット・スタンバイに一時的に切 り替え検証利用
66. Data Guardアソシエーションが有効な環境の管理 API(ocicli/RESTなど) Data Guard アソシエーションが有効な環境では、Data Guard Broker機能が有効 Control Plane #dbaascli/dbcli DGMGRL> • 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 などを用いた管理ができなくなるため、無効化しな いでください Cloud Tooling dmon dmon Broker プロセス Broker プロセス プライマリ Cloud Tooling スタンバイ Data Guard Broker構成 参照) Data Guard Broker詳説 https://speakerdeck.com/oracle4engineer/dataguard-broker-detail 83 Copyright © 2026, Oracle and/or its affiliates |
67. ローカル・スタンバイとリモート・スタンバイの用途の違い 計画停止時の切り替え先として利用するケース リージョン1(本番) スタンバイ • • • • リージョン2(DR) プライマリ ローカル・スタンバイ DB層の計画停止・計画外停止のローカル切り替え先 近距離でのレプリケーションでギャップ(データ差分)が少なく、 RPOとRTOが短い DB層で切り替えが必要となる場合も、AP層はそのままでレ イテンシー(距離)を確保 サイト障害時は切り替え先として利用不可 スタンバイ リモート・スタンバイ サイト障害などの大規模障害時の切り替え先 • 遠隔地でのレプリケーションのため、RPOとRTOがローカルと比べ ると長くなる • DB層のみの停止時、AP層は切り替えずにリージョン1で稼働し 続ける場合はAPとDB間のレイテンシーが、AP層もリージョン2に 切り替える場合は切り替え時間・作業が課題となるえる • RPO/RTO観点で計画停止・計画停止の内容に応じて使い分けられるよう、複数スタンバイを保持することが推奨 • ROI観点でスタンバイ側の利活用も検討 84 Copyright © 2026, Oracle and/or its affiliates |
68. 参考) Full Stack Disaster Recovery Service フルマネージド・ディザスタ・リカバリ・サービス(DR) サービス概要/特徴 サービス価格 • リージョン間のインフラストラクチャ、プラットフォーム、アプリ ケーションの移行をワンクリックで管理 • 複雑なリカバリー・プロセスをオーケストレーション可能 • データベース・サービス(Autonomous Database、Base Database、Exadata Database)とも完全に統合 • ¥1.984 [OCPU/時間] • ¥0.496 [ECPU/時間] * DR保護グループ(Disaster Recovery Protection Group)に登録した OCIリソースのOCPU/ECPU数に対して課金 こんな課題に役立ちます • 各レイヤー(ストレージやデータベース)のレプリケーションをリー ジョン間で行っているが、万が一のリージョン切り替えまでは 実装できていない • リージョン切り替えを独自に実装しているが、保守運用にか かる工数を減らしたい 85 Copyright © 2026, Oracle and/or its affiliates | サービス概要資料: https://speakerdeck.com/oracle4engineer/fsdr-overview * 2026年1月現在
69. 手動設定・管理 「リージョン間だけどRPOを高めたい(データロスの可能性を減らしたい) 」 Far Sync(遠隔同期)インスタンス構成例 ap-osaka-1 ap-tokyo-1 • 遠隔地の場合、システム性能とデータ保護のバランス から非同期モードが選択されるため、リカバリ不能な停 止によって生じる様々なレベルのデータ損失が発生 AD1 AD1 VCN VCN • Far Sync(遠隔同期)インスタンスを利用することで、遠 隔地スタンバイで実現が難しかった「データロスの可能 性を低くする構成」を実現 • クラウド・ツールは対応していないので、自動Data Guard機能の構成に手動で設定変更 • Far Sync(遠隔同期)インスタンス(12.1以降) 同期 非同期 • REDO転送の中継地となる、Active Data Guardの 機能 • Far SyncインスタンスにはDBライセンス不要 (制御ファイルとログ・ファイルのみ保持) 86 Copyright © 2026, Oracle and/or its affiliates | • Far Syncインスタンスの冗長化も可能
70. 手動設定・管理 「自動切り替えしたい」 ファスト・スタート・フェイルオーバー構成 • デフォルトのData Guard構成の場合、障害時の切り替えは 手動で明示的に行う。RTOを考えた時に、迅速に切り替えら れるかを重要とし、自動で切り替えたいというケースもある • Data Guardのファスト・スタート・フェイルオーバー機能を利用 することで、自動フェイル・オーバーが可能 - OCIクラウド・ツールは対応していないので、手動で設定 • ファスト・スタート・フェイルオーバー(FSFO)概要 Virtual Machine Observer • Oracle Data Guard Brokerの機能 - Database System Database System Primary Database 87 Copyright © 2026, Oracle and/or its affiliates | オブサーバという監視プロセスが切り替えを判断 • Standby Database Data Guard Broker有効+FSFO有効化 (FSFOデフォルト無効) - FSFOを有効にした上で、自動切り替えしない監視専用モード や手動切り替えも可 • オブサーバ・サーバーにはDBライセンス不要 • オブサーバの冗長化も可能(12.2以降) • Oracle Enterprise Manager Cloud Control でオブザー バーの監視が可能
71. 停止理由ごとの対策 計画停止(メンテナンスやスケーリング)
72. データベース・シオステムにおける停止 停止理由 停止の種類 停止理由 インスタンス障害(DBプロセス障害) サーバー障害 ストレージ障害(ディスクおよび筐体障害) 計画外停止 データ障害(特定ブロック破損) データ障害(人的エラー) データ障害(ストレージ全損障害) サイト障害 計画停止 89 Copyright © 2026, Oracle and/or its affiliates | 計画メンテナンス リソース変更(拡張) 影響範囲
73. BaseDBの拡張性 • スケール・アップ/ダウン(VMクラスタの拡張性)とスケール・アウト/イン(インフラの拡張性)が可能 特徴 課金 スケールアップ・ダウン • CPU、メモリー、ネットワーク帯域幅のスケーリングが可能 • シェイプ変更は再起動を伴うが、RACの場合はローリングで実施 • ストレージはオンラインでスケーリング可能 • CPU数に応じた課金変動 • ストレージサイズに応じた課金 変動 スケールアウト・イン • VM数など、作成後のスケールアウト・インは不可 • • 93 計画的なスケーリング(夜間・週末停止やデータ量・トランザクション量の予測に応じた変更等)の場合は、メンテナンス時間を 設けることで再起動の影響を抑えることが可能 計画外停止時の即時スケーリング(縮退運転の際のスケーリングや、災対サイトへの切り替え等)の際に、切り替え時間に 再起動が含まれることを考慮 Copyright © 2026, Oracle and/or its affiliates |
74. ExaDB-Dの拡張性 • スケールアップ・ダウン(VMクラスタの拡張性)とスケールアウト・イン(インフラの拡張性)が可能 データベース・ サーバー ストレージ 特徴 課金 スケールアップ・ダウン (CPU、メモリ、ローカ ルストレージ) • CPUの変更が動的(オンライン)に可能。変更完了も数分程度 • VMのメモリーサイズの変更、ローカル・ファイルシステムのスケールダウンは再起 動を伴う • CPU数に応じた課金変動 • メモリやローカルストレージの拡 張は影響なし スケールアウト・イン (VM、物理サーバー) • VMクラスタを構成するVMを追加・削除可能 • インフラのデータベース・サーバーの追加・削除がオンラインで可能 • インフラの物理サーバー数に応 じた課金変動 スケールアップ・ダウン (Exadataストレージ) • VMクラスタを構成するExadataストレージ(ASMディスクグループ)のサイズの変 更がオンラインで可能 • ディスクグループのサイズの拡 張は影響なし スケールアウト (物理サーバー) • インフラのストレージ・サーバーの追加がオンラインで可能 • インフラの物理サーバー数に応 じた課金 オンラインでスケーリングが可能なことがメリットになりうるケース • • 94 性能劣化、リソース使用率の逼迫を検知 • CPUネックの場合、CPUスケールアップで対処可能(Dynamic Scalingを実装して自動スケーリング可) • データ量の増加によるDisk Group使用率の逼迫であれば、VMクラスタのExadataストレージをスケールアップ 計画停止・計画外停止時 • 縮退時のパフォーマンス維持のためのスケールアップ • 通常時はスタンバイ側は最低限のリソースで運用している場合、切り替え後に再起動なしですぐにスケールアップ Copyright © 2026, Oracle and/or its affiliates |
75. Exadata Database Service 災対環境でのスケーリング 平常時は最低限のリソースでコストを抑え、切り替え時に本番同等のリソースへスケーリング • スケール・アップがオンラインで可能 • 迅速な切り替えが可能(RTO) • 割り当て済みのインフラ・リソース内は確実にスケーリ ング可能 切り替え時 スケール・アップ 平常時 • スケール・アウトもオンラインで可能 • VM数(RACノード数)やインフラのサーバー数の変更 • 例) 本番はRAC構成・災対はシングル構成で、切り 替え時にシングル構成を本番と同じRAC構成したい という場合もオンラインで可能 95 Copyright © 2026, Oracle and/or its affiliates | 本番 災対 停止 切り替え先 スケール・ アウト
76. Exadata Database Service 利用可能CPU数の変更 変更方法 オンデマンド変更 • コンソール/CLI/APIで即座に変更 ジョブ・スクリプトでのスケジューリング • CLI/APIでの変更操作をスクリプト化す るなど、手動設定での自動スケーリン グ可能 自動スケーリングの実装 • Dynamic Scalingツールを導入し、CPU 負荷やスケジュールに応じた自動ス ケーリングを実装可 • チュートリアル: 『Oracle Exadata Cloud Infrastructureでの 動的スケーリングの構成』 • 詳細/ツールのダウンロード: (ODyS) Oracle Dynamic Scaling Suite Main Index Page(KB583239) 例) cronを使用してスクリプト実行 23:00 CPU 0... 5:00 CPU 8… $ oci db cloud-vm-cluster update --cpu-core-count xxx --cloud-vm-cluster-id xxx … 96 Copyright © 2026, Oracle and/or its affiliates |
77. 参考資料 • 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 技術詳細