Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
TechNight#68 - Autonomous Database のバックアップおよび災害...
Search
oracle4engineer
PRO
July 31, 2023
Technology
690
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
TechNight#68 - Autonomous Database のバックアップおよび災害対策に関連する機能の活用方法と使いどころ
oracle4engineer
PRO
July 31, 2023
More Decks by oracle4engineer
See All by oracle4engineer
OracleTechnologyNight101_Oracle_Backup_Recovery_Strategy_from_REDO_UNDO
oracle4engineer
PRO
1
480
Oracle Cloud Infrastructure:2026年7月度サービス・アップデート
oracle4engineer
PRO
1
640
Lakehouseの要!Open Table Format深掘り(OCHaCafe Season 11 #6)
oracle4engineer
PRO
2
130
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
[JPOUG Tech Talk Night #16]1歩踏み込むSQLの結合方法
oracle4engineer
PRO
4
320
『モデル + ハーネス』で読み解く AIエージェント入門
oracle4engineer
PRO
2
350
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
8.7k
Deep Data Security 機能解説
oracle4engineer
PRO
2
480
Oracle Cloud Infrastructure:2026年6月度サービス・アップデート
oracle4engineer
PRO
1
1k
Other Decks in Technology
See All in Technology
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
1.2k
属人化を叩き割れ!「制作加速」と「安定化」の矛盾を打破する:8年目プロダクトが辿り着いた「ミスが起こり得ない」アセット制作フローの全貌
gree_tech
PRO
0
460
形式手法特論:Hyperproperty とモデル検査 #kernelvm / Kernel VM Study Tokyo 19th
ytaka23
0
780
巨大気象データと戦う ― サロゲートモデル学習を高速化する圧縮技術
gpuunite_official
0
270
AI駆動開発はどこまで来たのか? ファインディの最新実態調査で読み解く現在地 Devin Con Tokyo
akiratom
1
600
RapidCopy2 Matrix I/Oエンジンによるファイルコピーソフトウェアの設計と実装
kengosawa2
1
390
電話に出る Python のログの話
shinnosuke_kishida
0
220
Kiro入門|仕様駆動開発で変わるAI時代の開発スタイル
cmkudo
0
360
Data Hubグループ 紹介資料
sansan33
PRO
0
3.2k
AI時代の「OAuth認証」にどう物申すか?(OAuth/OIDC Numa (Immersion) Workshop 2026)
oidfj
PRO
0
130
ブラウザで変わるID連携(OAuth/OIDC Numa (Immersion) Workshop 2026)
oidfj
PRO
0
140
AI・HPC開発を支えるGPU環境の新しい選択肢 液冷GPUシステム「AquSys」の取り組み
gpuunite_official
0
240
Featured
See All Featured
Chasing Engaging Ingredients in Design
codingconduct
0
280
The Cult of Friendly URLs
andyhume
79
7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.8k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
220
Discover your Explorer Soul
emna__ayadi
2
1.3k
How to Think Like a Performance Engineer
csswizardry
28
2.7k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
67
57k
Building an army of robots
kneath
306
46k
Transcript
Oracle Database Technology Night #68 Autonomous Database のバックアップおよび災害 対策に関連する機能の活用方法と使いどころ Ryunosuke
Deguchi 日本オラクル株式会社 クラウド・エンジニアリング統括 Autonomous & Analytics ソリューション部 2023/6/22
Safe harbor statement 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。 以下の事項は、マテリアルやコード、機能を提供することを確約するものではないため、 購買決定を行う際の判断材料になさらないで下さい。 オラクル製品に関して記載されている機能の開発、リリース、時期及び価格については、 弊社の裁量により決定され、変更される可能性があります。 Copyright
© 2023, Oracle and/or its affiliates 2
• データベース停止時間の種類とその対処方法 • 高可用性/災害対策ソリューション • 各ソリューション比較 • まとめ Agenda Copyright
© 2023, Oracle and/or its affiliates 3
• データベース停止時間の種類とその対処方法 • 高可用性/災害対策ソリューション • 各ソリューション比較 • まとめ Agenda Copyright
© 2023, Oracle and/or its affiliates 4
データベース停止時間の種類 計画メンテナンス リカバリ可能なローカル障害 リカバリ不可能な障害またはリージョン障害 Copyright © 2023, Oracle and/or its
affiliates ・・・ インスタンス再起動を伴うDB・GI・OSパッチ適用 ・・・ サーバー障害、ストレージ障害、人的エラーやデータ破損 ・・・ バックアップからの復旧が必要な障害、自然災害 5
Autonomous Database の事前構成済みの高可用性機能 Copyright © 2023, Oracle and/or its affiliates
基盤となるテクノロジー Oracle RMAN 3重化されたオブジェクト・ストレージへの自動 バックアップ Oracle RAC ノード障害からの保護 停止時間0(ゼロ)のソフトウェア・メンテナ ンス 停止時間のない柔軟な変更(CPU、メモリ、 ストレージ) ASM 複数のストレージを束ねて仮想化 3重化によりストレージ障害、ブロック破損に 対応 Flashback 過去データの参照、操作の取り消しが可能 ユーザーによる誤操作や予期せぬトランザク ションに対応 FAN/TAC トランザクションを安全に自動再実行 アプリからは(ほぼ)透過的な計画(外)メン テナンス リージョン1 バックアップ・コピー バックアップ・REDO ポッドA ポッドB プライマリ 停止のマトリックス* 数時間 数分 1分 計画 メンテナンス リカバリ可能な障害 リカバリ不可能な障害 またはリージョン障害 0(ゼロ) ほぼ0(ゼロ) 1分 *サービスレベル目標(SLO) 優れたSLA保証: 99.95% (非合理な例外なし) 6 RPO RTO
システム停止することなく最新・セキュアな状態に維持 パッチのローリング適用-Real Application Clusters (RAC)を活用 7 Autonomous Databaseにおける実装 オラクル社による事前テスト 実行計画の変動に伴う性能劣化を防ぐ仕組みを実装し、アプリ影響を排除
サービスを止めずに自動適用(*) • 各リージョンの本番環境に順次適用 • 各コンポーネントに対してローリング適用 • Fast Application Notification(FAN)により自動再接続 • Transparent Application Continuity(TAC)を有効化することでトランザクションの自動リカバリが可能(推奨) オラクルの設計思想 常に最新のパッチを適用いただく • 最新技術によるメリットの享受のため • 不具合や脆弱性へのプロアクティブな対応を図るため システムを止めずに柔軟に適用できる機能を提供していく * システム停止が必要な場合は事前通知の上で実施 ローリング適用 Copyright © 2023, Oracle and/or its affiliates
Fast Application Notification (FAN) と Transparent Application Continuity (TAC)の利用 8
ノード 1 ノード 2 ノード 3 shutdown Fast Application Notification(事前構成済み) コネクション・プールが物理コネクションを制御する機能 • 計画停止 - Oracleインスタンスshutdown前に物理 コネクションをアプリケーションから返却されたら切断す る • 非計画停止 - コネクション・プールから該当物理コネク ションを即時破棄 • サービス起動 - 物理コネクションのリバランス Transparent Application Continuity(追加設定) 接続ドライバによる自動再実行 接続サービス毎に有効化するだけ • 非計画停止 - 物理コネクションが異常切断されたら 自動再接続して自動再実行 • アプリからは処理がわずかに遅れたようにみえる startup Connection Pool FANとTACの詳しい解説 Oracle Database Technology Night #67 ミッションクリティカルなデータベースに必須となる高可用性の考え方とは Copyright © 2023, Oracle and/or its affiliates データベース接続を積極的に制御する
Copyright © 2023, Oracle and/or its affiliates 9 ASMファイルの破損が検出されるとセカンダリ・エクステントから読み取って処理継続および自動修復 データ破損の自動修復-Automatic
Storage Management(ASM) oracle Oracleサーバー・プロセス SGA 1. プライマリ・エクステントの 破損を検出した 2. セカンダリ・エクステントから読 み取りエラーを返さず処理継続 1 2 3 3 1 1 プライマリ・ エクステント セカンダリ・ エクステント 3. 正常エクステントのデータで 破損個所を修復 3重化ASMディスク・グループ
Autonomous Database の事前構成済みの高可用性機能 Copyright © 2023, Oracle and/or its affiliates
基盤となるテクノロジー Oracle RMAN 3重化されたオブジェクト・ストレージへの自動 バックアップ Oracle RAC ノード障害からの保護 停止時間0(ゼロ)のソフトウェア・メンテナ ンス 停止時間のない柔軟な変更(CPU、メモリ、 ストレージ) ASM 複数のストレージを束ねて仮想化 3重化によりストレージ障害、ブロック破損に 対応 Flashback 過去データの参照、操作の取り消しが可能 ユーザーによる誤操作や予期せぬトランザク ションに対応 FAN/TAC トランザクションを安全に自動再実行 アプリからは(ほぼ)透過的な計画(外)メン テナンス リージョン1 バックアップ・コピー バックアップ・REDO ポッドA ポッドB プライマリ 停止のマトリックス* 数時間 数分 1分 計画 メンテナンス リカバリ可能な障害 リカバリ不可能な障害 またはリージョン障害 0(ゼロ) ほぼ0(ゼロ) 1分 *サービスレベル目標(SLO) 優れたSLA保証: 99.95% (非合理な例外なし) 10 RPO RTO
スタンバイ・データベースによるリカバリ不可能な障害とリージョン障害からの保護 Copyright © 2023, Oracle and/or its affiliates 追加オプション Autonomous
Data Guard コンソールからワンクリックで構成可能 (最大2つのスタンバイ:ローカルと リモート1つずつ) スタンバイへのアクセスはなし リージョン1 プライマリ 停止のマトリックス 計画 メンテナンス リカバリ可能な障害 リカバリ不可能な障害 またはリージョン障害 0(ゼロ) ほぼ0(ゼロ) 1分 ローカル・スタンバイ リージョン2 リモート・スタンバイ 数分 バックアップ 1分 Autonomous Data Guard構成時のSLA: 99.995%(非合理な例外なし) 11 バックアップ 数分 RPO RTO
• データベース停止時間の種類とその対処方法 • 高可用性/災害対策ソリューション • 各ソリューション比較 • まとめ Agenda Copyright
© 2023, Oracle and/or its affiliates 12
• Autonomous Data Guard 【スタンバイ・データベースによる高可用性構成】 • バックアップベースのディザスタ・リカバリ 【低コストなDR対策 / バックアップの遠隔地保管】
• 長期バックアップ 【バックアップの長期保管】 • クローン 【開発環境としても利用可能なバックアップ環境の作成】 高可用性/災害対策ソリューション Copyright © 2023, Oracle and/or its affiliates 13
14 Copyright © 2023, Oracle and/or its affiliates Autonomous Data
Guard スタンバイ・データベースによる高可用性構成のサポート コンソールからのクリック操作で簡単に構成可能 スタンバイ先を選択可能 • 同一リージョン(ローカル) • 他のリージョン(クロス・リージョン) • またはローカルとクロスリージョンの併用が可能(右図) スタンバイ側も同一構成 • データベース名、OCPU数、ストレージサイズ、等 • OCPUのスケールアップ等の操作はスタンバイ側にも適用される • 起動、停止、OCPU数の変更、など。 最小限のダウンタイムでフェイルオーバー(F/O)、スイッチオーバー(S/O)が可能 • F/O、S/O後、アプリ修正は不要(Walletの変更は不要、接続文字列の変更は必要) • F/O完了後は自動的に新規スタンバイが作成される 同期モードは非同期 Cross-region Standby Local Standby Production Redo logs Redo logs Redo logs Tokyo Osaka Autonomous Data Guard構成時のSLA: 99.995%(非合理な例外なし)
• Autonomous Data Guard 【スタンバイ・データベースによる高可用性構成】 • バックアップベースのディザスタ・リカバリ 【低コストなDR対策 / バックアップの遠隔地保管】
• 長期バックアップ 【バックアップの長期保管】 • クローン 【開発環境としても利用可能なバックアップ環境の作成】 高可用性/災害対策ソリューション Copyright © 2023, Oracle and/or its affiliates 15
バックアップベースのディザスタ・リカバリ ローカル・バックアップ・コピー(事前構成済み) → Exadataシステム全体の障害 Tokyo プライマリ バックアップ, REDO クロスリージョン・バックアップ・コピー(追加設定) →
リージョン障害, バックアップの遠隔地保管 Tokyo Osaka プライマリ Copyright © 2023, Oracle and/or its affiliates 16 ポッドA ポッドB ポッドC ポッドA 本番環境(プライマリ)とは異なるExadata環境にバックアップを使用してピア・データベースをインスタンス化
17 Copyright © 2023, Oracle and/or its affiliates バックアップベースのディザスタ・リカバリ コンソールからのクリック操作で簡単に構成可能
スイッチオーバー、フェイルオーバー実行時にバックアップを使用してピア・データベースをインスタンス化 • Autonomous Data Guardより低コストでDRが構成可能 • リカバリ時間目標(RTO)はAutonomous Data Guardより長い • RPO:1分 • RTO:1時間 + 5TBごとに1時間 ピア・データベースを作成するリージョンを選択可能 • ローカルはデフォルトで構成済(従来の自動バックアップ) • リモート(クロス・リージョン) • バックアップに必要なストレージ容量の2倍のコストが必要 • ローカルとリモート(クロス・リージョン)の併用が可能 スイッチオーバー、フェイルオーバーは手動で実施 インスタンス化されたピア・データベースはプライマリと同一構成 • データベース名、OCPU数、ストレージサイズ等
18 Copyright © 2023, Oracle and/or its affiliates クロス・リージョン・ディザスタ・リカバリのスナップショット・スタンバイ クロスリージョンのAutonomous
Data Guardスタンバイ・データベースまたはバックアップ・ベースのディザスタ・リカバリのスタ ンバイをスナップショット・スタンバイに変更できるようになりました。読取り/書込みデータベースとして最大2日間利用できま す。スタンバイ・データベースのデータ検証や一時的なテスト環境(DML操作も可)としての利用が可能です。
• Autonomous Data Guard 【スタンバイ・データベースによる高可用性構成】 • バックアップベースのディザスタ・リカバリ 【低コストなDR対策 / バックアップの遠隔地保管】
• 長期バックアップ 【バックアップの長期保管】 • クローン 【開発環境としても利用可能なバックアップ環境の作成】 高可用性/災害対策ソリューション Copyright © 2023, Oracle and/or its affiliates 19
自動バックアップ Always On / 増分バックアップ+REDO/ 追加コスト不要 目的 • 稼働中のAutonomous Databaseのリストア/リカバリ
• 過去60日以内の任意の時点のDBの複製 (クローンの作成) 長期バックアップ お客様が有効化 / スタンドアロン・バックアップ/ 追加コスト必要 目的 • バックアップの長期保存(社内ルール、コンプライアンス対応) • 60日以上前のバックアップ時点のデータの取出し (クローンの作成) Autonomous Databaseのバックアップ Copyright © 2023, Oracle and/or its affiliates 20 自動バックアップ 長期バックアップ バックアップ リストア バックアップ 保持期間:60日 保持期間:90日〜10年 ※バックアップ取得時にお客様DBの処理性能に影響を与えないように設計されている ※Oracle管理の領域に暗号化されて保存されるため、バックアップファイルを取り出すことはできない
• Autonomous Data Guard 【スタンバイ・データベースによる高可用性構成】 • Backup-Based Disaster Recovery 【低コストなDR対策
/ バックアップの遠隔地保管】 • 長期バックアップ 【バックアップの長期保管要件】 • クローン 【開発環境としても利用可能なバックアップ環境の作成】 高可用性/災害対策ソリューション Copyright © 2023, Oracle and/or its affiliates 21
Autonomous Databaseのクローン機能 Autonomous Databaseで利用可能なクローン フル・クローン • ソースとなるAutonomous Database全体(メタデータとデータ)を複製して、新しいAutonomous Databaseを作成 •
実行中のAutonomous Database、およびそのバックアップから作成可能 • 特定時点の論理バックアップとしても利用可能 メタデータ・クローン • ソースとなるAutonomous Databaseのメタデータのみを複製して、新しいAutonomous Databaseを作成(データは無し) • 実行中のAutonomous Database、およびそのバックアップから作成可能 リフレッシュ可能クローン • ソースとなるAutonomous Database全体(メタデータとデータ)を複製して、新しいAutonomous Databaseを作成 • 作成後にリフレッシュを実行して、ソースDBの更新内容を反映可能 • 実行中のAutonomous Databaseからのみ作成可能 Copyright © 2023, Oracle and/or its affiliates 22
• データベース停止時間の種類とその対処方法 • 高可用性/災害対策ソリューション • 各ソリューション比較 • まとめ Agenda Copyright
© 2023, Oracle and/or its affiliates 23
各ソリューションのRTO/RPOとコスト比較 Copyright © 2023, Oracle and/or its affiliates 24 ソリューション
対応可能な障害 RTO(サービスレベル のダウンタイム) RPO(サービスレベル のデータ・ロス)* 追加コスト デフォルト対応 (Real Application Clusters, Automatic Storage Management) • Exadataクラスタの NW障害 • ストレージ障害 • DBインスタンス障害 • DBサーバー障害 ほぼ0 0 0 バックアップベースのディザスタ・リカバリ ローカル・バックアップ・コピー • 全ノード障害 • ストレージの完全な 障害 1時間+5TBにつき 1時間 1分 0 ローカル Autonomous Data Guard • 全ノード障害 • ストレージの完全な 障害 数秒〜2分 1分 CPU:プライマリと同一 ストレージ:プライマリと同一サイズ バックアップベースのディザスタ・リカバリ クロスリージョン・バックアップ・コピー • リージョン障害 • バックアップの遠隔 地保管 1時間+5TBにつき 1時間 1分 CPU:0 ストレージ:プライマリの2倍のサイズ クロスリージョン Autonomous Data Guard • リージョン障害 • バックアップの遠隔 地保管 15分 1分 CPU:プライマリと同一 ストレージ:プライマリの2倍のサイズ *サービスレベル目標(SLO)
参考:各ソリューションの復旧時間とコストサンプル Copyright © 2023, Oracle and/or its affiliates 25 ソリューション
RTO(サービスレベルのダウンタイム) 実際の復旧時間 追加コスト(/月) バックアップベースのディザスタ・リカバリ ローカル・バックアップ・コピー 1時間+5TBにつき 1時間 33分 ¥0 ローカル Autonomous Data Guard 数秒〜2分 1分26秒 ¥593,158 4OCPU:¥560,006 2TB:¥33,152 バックアップベースのディザスタ・リカバリ クロスリージョン・バックアップ・コピー 1時間+5TBにつき 1時間 26分 ¥66,304 4TB:¥66,304 クロスリージョン Autonomous Data Guard 15分 12分 ¥626,310 4OCPU:¥560,006 4TB:¥66,304 環境情報 ワークロード・タイプ:トランザクション処理(ATP) OCPU数:4 ストレージ:2TB 結果
参考:各ソリューションの復旧時間とコストサンプル Copyright © 2023, Oracle and/or its affiliates 26 環境情報
ワークロード・タイプ:トランザクション処理(ATP) OCPU数:4 ストレージ:5TB 結果 ソリューション RTO(サービスレベルのダウンタイム) 実際の復旧時間 追加コスト(/月) バックアップベースのディザスタ・リカバリ ローカル・バックアップ・コピー 1時間+5TBにつき 1時間 56分 ¥0 ローカル Autonomous Data Guard 数秒〜2分 1分36秒 ¥642,886 4OCPU:¥560,006 5TB:¥82,880 バックアップベースのディザスタ・リカバリ クロスリージョン・バックアップ・コピー 1時間+5TBにつき 1時間 53分 ¥165,760 10TB:¥165,760 クロスリージョン Autonomous Data Guard 15分 6分17秒 ¥725,766 4OCPU:¥560,006 10TB:¥165,760
27 Copyright © 2023, Oracle and/or its affiliates サンプルケース 現在、4OCPU、
ストレージ2TBのATPを本番環境で運用しています。 なるべくコストをかけずにリモート・リージョンに災害対策とテストを兼ねた環 境を作りたいです。 リモート・リージョンにクロスリージョン・バックアップ・コピーを取っておき、テストの際は一 時的にスナップショット・スタンバイに変換し、読み書き可能なインスタンスにする方法 があります。 バックアップ・コピーにはOCPU課金は発生せず、スナップショット・スタンバイも最小の 1OCPUから利用することが可能ですので、最低限のコストで実現可能です。
サンプルケース 平時(クロスリージョン・バックアップ・コピー) Tokyo プライマリ 4OCPU 2TB Osaka バックアップ・コピー テスト時(スナップショット・スタンバイ) Tokyo
Osaka スナップショット・スタンバイ 2OCPU 2TB 48時間まで 変換可能 追加コスト:ストレージ4TB 追加コスト:2OCPU+ストレージ4TB Copyright © 2023, Oracle and/or its affiliates 28 プライマリ 4OCPU 2TB
29 Copyright © 2023, Oracle and/or its affiliates まとめ •
よくある障害はRAC(ノード切り替え)やASM(ストレージ冗長構成)で自動対処 • 広域障害への対処はバックアップベースのディザスタ・リカバリ or Autonomous Data Guard • コスト・RTO(目標復旧時間)に応じて選択 • ワンクリックですぐに構成可能 • バックアップの遠隔地保管、長期保管のソリューション
None