[DBWT-2] 信頼性: ミッションクリティカルなデータベースに必須となる高可用性の考え方とは

Oracle Database World
Tokyo
⽇下部明
⽇本オラクル株式会社
クラウドエンジニアリング統括 COE本部データベース・ソリューション部
プリンシパルクラウドエンジニア
2023年4⽉12⽇
ミッションクリティカルな
データベースに必須となる
⾼可⽤性の考え⽅とは

View Slide

Copyright © 2023, Oracle and/or its affiliates
2
⼊⼒と出⼒の対応関係の定義
SQL
出⼒
SELECT ename, dname, job, empno, hiredate, loc
FROM emp, dept
WHERE emp.deptno = dept.deptno
ORDER BY ename
⼊⼒
論理データ構造

View Slide

3
⼊⼒と出⼒の対応関係の定義
SQL
出⼒
SELECT ename, dname, job, empno, hiredate, loc
FROM emp, dept
WHERE emp.deptno = dept.deptno
ORDER BY ename
⼊⼒
何を取り出すかの定義であって、どうやって
導出するかのアルゴリズムは記述されていない

View Slide

4
インターフェースとアルゴリズム実装の分離
SQLの結果集合を導出するアルゴリズムは⾃動⽣成される
⼊⼒
出⼒
対応関係の定義
インターフェース
SQL実⾏計画
SQL実⾏計画探索
アルゴリズム
全体最適化問題
値の分布統計物理データ構造ハードウェア・リソース

View Slide

5
⼊⼒
SQLの結果集合を導出するアルゴリズムは⾃動⽣成される
出⼒
SQL実⾏計画
アルゴリズム
アプリケーション開発で
注⼒すべきところ
• 論理データ構造
• クエリー

View Slide

6
データベース・エンジン実装が⽬指すところ
出⼒
SQL実⾏計画
アルゴリズム
⼊⼒
論理データ構造の定義と
インターフェース(SQL)を変更せずに
アルゴリズム実装が改良される

View Slide

7
リレーショナル・モデルの操作からはじまったが、他のモデルでも使⽤されるようになった
SQL - 抽象化されたデータ操作
データ・モデル
• Relational
• Text Search
• Object Relational
• XML
• JSON
• Spatial
• Network
• ...
ワークロード
• オンライン・トランザクション
• 分析・集計
• 機械学習
• ...

View Slide

8
リレーショナル・モデルの操作からはじまったが、他のモデルでも使⽤されるようになった
SQL - 抽象化されたデータ操作
データ・モデル
• Relational
• Text Search
• Object Relational
• XML
• JSON
• Spatial
• Network
• ...
ワークロード
• オンライン・トランザクション
• 分析・集計
• 機械学習
• ...
SQLは抽象データ操作
↓
異なる種類のデータ・モデルを操作する実装
異なる種類のワークロードに最適化する実装
↓
Converged Database

View Slide

9
抽象化されたデータ操作
user-Bの所有するスキーマ
service-A
SQL
どういうデータを取り出したいかの記述
(「どうやって」の⼿続き的アルゴリズムの記述ではない)
CONNECT user-B/password@host:port/service-A
データベース・クライアントは「サービス」に接続する
サービス
データベースのワークロードを抽象化した概念

View Slide

10
SQL
サービス
service-A
データベース
ストレージ上のファイルの集合
Oracleインスタンス
データベース・サーバー上のOracleプロセスとメモリーの集合

View Slide

11
SQL
サービス
service-A
データベース
データベース・クライアントは「サービス」に接続
↓
サービス(抽象)がデータベース・サーバー側の物理構成(具象)を隠蔽

View Slide

12
⽂脈によって意味が異なる⽤語
サービス / インスタンス / データベース
データベース・サーバー
(Computeノード)
ストレージ
サービス
クラウドが⽤意する機能のメニュー
データベース
データの集合
インスタンス
サービスを実体化したもの
service
データベース・サーバー上の
Oracleプロセスとメモリーの集合
データベース
サービス
データベースのワークロードを抽
象化した概念
Oracle Databaseの⽂脈クラウドの⽂脈
例: Oracle Base Database Service

View Slide

13
Oracleインスタンスとデータベース
「CPU+メモリー」と「ストレージ」をわけて考える
データベース
揮発性メモリーに⼀時的に格納(キャッシュ)
(再起動などでなくなることを想定)
不揮発性デバイスに永続化
(データの本体なのでなくなると困る)
(Computeノード)
ストレージ

View Slide

14
⾼可⽤性を実装する⼿段
各階層で冗⻑性を持たせる
データベース
プロセスとメモリーが起動できるOS環境を⽤意
データベース・サーバーのクラスタ構成
データの複製を⽤意
ミラー / バックアップ / レプリケーション
(Computeノード)
ストレージ

View Slide

15
⾼可⽤性を実装する⼿段
各階層で冗⻑性を持たせる
データベース
プロセスとメモリーが起動できるOS環境を⽤意
データベース・サーバーのクラスタ構成
データの複製を⽤意
(Computeノード)
ストレージ

View Slide

16
Maximum Availability Architecture (MAA)
Oracle Databaseの各階層の保護機能の組み合わせ

View Slide

17
SQL
サービス
service-A
データベース
Maximum Availability Architecture
• サービスが具象レイヤーの構成を隠蔽
• サービスへのアクセスを継続
抽象化されたデータ操作を計画停⽌/⾮計画停⽌どちらがあっても継続する

View Slide

18
Real Application Clusters (RAC)
Shared Everything Cluster

View Slide

19
全ノードが全データにアクセス可能
RACの物理構成
ストレージ・ネットワーク
インターコネクト・ネットワーク
パブリック・ネットワーク
データベース・クライアント
クライアントとの通信
ストレージ・ノード
• ストレージ・デバイス
コンピュート・ノード
• CPU+メモリー
• 全ノードが対等な関係
コンピュート・ノード間の通信
全コンピュート・ノードは全ストレージにアクセス可能

View Slide

20
データ・モデル(スキーマ構造)、トランザクション分離レベルの挙動も同じ
クライアントはどのノードに接続してもシングル・インスタンス構成と同じアクセスが可能
インターコネクト・ネットワークコンピュート・ノード間の通信
メモリー⼀貫性を全⾃
動で維持
oracle
クライアントが接続した
ノードのプロセスがSQL
処理

View Slide

21
どのノードからも全データに同じようにアクセス可能 - クライアントから⾒るとシングル・インスタンス構成と同じ
RAC におけるデータアクセス
クライアントはどのサーバーに接続しても
同じデータの⾒え⽅、シングルインスタンス
と同じトランザクション分離レベル
サーバー・ノード間のメモリー
⼀貫性を全⾃動で維持
シングル・インスタンス構成と同じアクセスが可能
• データ・モデル(スキーマ構造)、トランザクション分離レベルの挙動も同じ
並列実⾏プロセスがデータを
分割して並列処理
PX PX PX PX PX PX
全ノードを使⽤した1つのSQL処理の並列化が可能
• アプリからは巨⼤な⼀つのデータベースインスタンスに⾒える

View Slide

22
サーバーがクラッシュしてもクライアントは別ノードに接続すると全データにアクセス可能
クライアントはどのノードに接続してもシングル・インスタンス構成と同じアクセスが可能
メモリー⼀貫性を全⾃
動で維持
oracle
クライアントが接続した
ノードのプロセスがSQL
処理
oracle

View Slide

23
ユーザーからは透過的に複数CPUで処理可能
RACは共有メモリー型マルチ・プロセッサと同じくキャッシュ⼀貫性を維持
共有メモリー型マルチ・プロセッサ
キャッシュ・メモリーキャッシュ・メモリー
キャッシュ⼀貫性
CPU 1 CPU 2
SGA
DRAM (メイン・メモリー)

View Slide

24
Oracle Real Application Clusters
SGA
ユーザーからは透過的に複数CPUで処理可能
共有メモリー型マルチ・プロセッサ
RACは共有メモリー型マルチ・プロセッサと同じくキャッシュ⼀貫性を維持
ノード1
(キャッシュ)
ノード2
(キャッシュ)
データベース (ストレージ上のファイル群)
SGA
キャッシュ・メモリーキャッシュ・メモリー
CPU 1 CPU 2
SGA
DRAM (メイン・メモリー)

View Slide

25
データ・モデルとクラスタ・ノード構成が分離されている
現実にあるほとんどのアプリケーション・スキーマは完全には
パーティショニングできない。
RACはデータの配置がデータベース・サーバーと結びつい
ていない。
シェアード・ナッシング・クラスタはデータがパーティショニング
できることを暗黙の前提にしている。
パーティショニングできないアプリケーション・スキーマでも動
作できるようにしたのが”Real Application” Clusters
Oracle Real Application Clusters
データ・モデル/SQL
抽象
実装
データ構造/クラスタ構成

View Slide

26
Oracle Autonomous Database
Exadataをベースにして⾼度な抽象化がなされた⾃律型データベース・サービス
Exadata上のプラガブル・データベース
• 指定する変数はOCPU数とストレージ容量のみ
• RACノード数はユーザーが指定する変数ではない
Oracle Computing Unit (OCPU)
• スケールアップかつスケールアウトを抽象化
• OCPU数に⽐例したCPU時間
• OCPU数に⽐例したメモリー容量
• OCPU数に⽐例したストレージ性能
• 1 OCPUは1CPU物理コアに相当
• 無停⽌でOCPU数(リソース割り当て)を変更
service

View Slide

27
Oracle Autonomous Database
Oracle Computing Unit(OCPU) の1変数にハードウェア・リソースを抽象化
DBサーバー
ストレージ
Oracle Computing Unit (OCPU)
• 1 OCPUは1CPU物理コアに相当
• スケール・アップかつスケール・アウトを抽象化
• OCPU数に⽐例したCPU時間
• OCPU数に⽐例したメモリー容量
• OCPU数に⽐例したストレージ性能
• 無停⽌でOCPU数(リソース割り当て)を変更
CPU
メモリー
Autonomous Databaseインスタンス
• 1つのプラガブル・データベースのこと
• OCPUに抽象化されたリソース割り当て
• サービスでリソース制御
スケール・アップ
スケール・アウト
Oracle Computing Unit
サービス
• データベースのワークロードを抽象化
service

View Slide

28
⾼速アプリケーション通知
Fast Application Notification: FAN
Oracle ClusterwareからOracleクライアントにメッセージ通知する仕組み
Fast Application Notification (FAN)
• Oracle Clusterwareからクライアントにイベント通知
Oracle製コネクション・プールがFAN対応
• Universal Connection Pool for Java (UCP)
• OCI Session Pool
• ODP.NET Unmanaged Driver
Fast Connection Failover
• DOWNイベントによるコネクション破棄
• 計画停⽌/⾮計画停⽌を区別
• UPイベントによるコネクション作成(UCP)
Connection
Pool
ノード 1 ノード 2
アプリケーション・サーバー
Clusterware Clusterware
FANイベント
FANイベント
service service

View Slide

29
コマンドでサービス停⽌が発⽣する場合プールに論理コネクションが返却されてから物理コネクションを切断
1. srvctl relocate service発⾏ 2. 物理コネクションの新規接続と排出
FAN対応クライアントと組み合わせたOracleインスタンスの計画停⽌
Oracle
instance1
Oracle
instance2
service1 service1
Oracleクライアント
FANイベント Pool
(2) UP通知
Oracle
instance1
Oracle
instance2
service1
Pool
(6) インスタンス1との物
理コネクションはプー
ルに返却されたら切
断
(1) サービス起動
(4) DOWN通知
(5) 新規の物理コネク
ションはインスタンス
2に接続される
(3) サービス停⽌

View Slide

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

View Slide

31
異常を検出する機能と検出した異常に対処する機能
• FANとAC/TACは組み合わせると都合の良い機能であって、使⽤すること⾃体はそれぞれ独⽴している
• 計画停⽌(FAN-FCF)/⾮計画停⽌(TAC)両⽅のOracleインスタンス停⽌をアプリケーションからマスク
Fast Application Notification(FAN)と
(Transparent) Application Continuity(TAC/AC)は独⽴した別の機能
発⽣した異常を検出検出した異常に対処
Pool
Driver
Driver
Driver
• (Transparent) Application Continuity
は切断されたことを検出すると⾃動再接続＆
⾃動再実⾏する機能
• ⾮計画停⽌での切断に対処
• 切断検出のきっかけは何でもよい
• Fast Connection Failover (FCF)はサービ
スが停⽌したことを明⽰的に通知する機能
• 計画停⽌と⾮計画停⽌を区別
• TCPレベルで応答がないケースでもコネクショ
ン・プールから障害ノードとのコネクションを削除

View Slide

32
Oracle Databaseはなぜデータの複製を
Oracleソフトウェアでやろうとするのか

View Slide

33
データ消失に備えて異なるハードウェア上にデータを複製する
データを複製する⼿段
• ミラー : 継続的なデータの複製 (ローカル・ストレージ)
• バックアップ : バックアップ操作をした時点のデータの複製
• レプリケーション : 継続的なデータの複製 (リモート・ストレージ)
• (スナップショット)
データの複製⼿段

View Slide

34
ミラー/レプリケーション/バックアップ
ストレージ機能でのデータの複製
ストレージ・コントローラストレージ・コントローラ
リモート・レプリケーション (レプリケーション)
• 別のストレージ筐体に書き込みを複製
RAID (ミラー)
• 複数のストレージ・デバイスに書き込みを複製
スプリット・ミラー (バックアップ)
• ミラーを⼀時的に解除することで
その時点のストレージの状態を保持
書き込みデータ

View Slide

35
データを失う要因はストレージ・デバイスの故障以外にもある
ストレージ・デバイスが故障していなくても、格納されてい
るファイルのデータが破損している場合がある。
エラー・ログを出⼒するのは、その異常を検出した階層。
異常検出能⼒のない階層はエラー・ログを出⼒できない。
データを破損させた階層が破損させたことを直接ログに記
録していることは期待できない。
ストレージのデータを破損させる要因
• CPU/メモリー故障
• レーザー出⼒不安定
• 電源障害
• ランサムウェア
• ...
データを失う要因はストレージ・デバイスの故障以外にもある
Oracle Database
OS
Multipath Driver
Device Driver
Host Bus Adapter
Storage Controller
Network
CPU/Memory
?
ERROR
?

View Slide

36
書き込むデータが意味的に正常なのかはストレージは判別できないのでデータ破損が伝搬する
ストレージ機能でのデータの複製
ストレージ・コントローラストレージ・コントローラ
リモート・レプリケーション (レプリケーション)
• 別のストレージ筐体に書き込みを複製
RAID (ミラー)
• 複数のストレージ・デバイスに書き込みを複製
スプリット・ミラー (バックアップ)
• ミラーを⼀時的に解除することで
その時点のストレージの状態を保持
破損データ

View Slide

37
Oracle Databaseの歴史はデータ破損との闘い
Oracle Databaseはなぜデータの複製をOracleソフトウェアでやろうとするのか
Oracleインスタンス破損検査
↓
破損伝搬の抑⽌
↓
⾃動修復
実装バージョン機能名機能
Oracle8 RMAN バックアップ/リストア
Oracle9i Data Guard REDO情報を別サーバーに転送
Oracle 10g ASM ストレージの冗⻑化と⾃動修復
Oracle 11g Exadata Oracle専⽤ストレージがデータ構造を検査
Oracle 11g Active Data Guard Data Guard+⾃動修復
Oracle 12c ZDLRA RMANバックアップ+REDO転送
• データ構造がOracle Databaseとして正しいかを検査できるのは
Oracle⾃⾝しかない
• ある階層から別の階層に移動させるとき検査される
• 破損が次の階層に伝搬しない
• データの複製がある場合は⾃動修復を試みる

View Slide

38
Automatic Storage Management (ASM)
Stripe And Mirror Everything

View Slide

39
デバイス・
ファイル
Oracle Database専⽤のクラスタ・ボリューム・マネージャ兼クラスタ・ファイルシステム
Oracle Automatic Storage Management
ファイル構造
Oracle構造
POSIXファイルシステム
ボリューム・マネージャ
ファイルシステム
表、索引
表領域
ファイル
ASM
ASM
表、索引
表領域
ボリューム・マネージャ
ファイルシステム
ファイル
管理者から⾒た操作の階層はどちらもディレクトリ・ツリーとファイルで同じ
RAIDとは異なる実装で
• ストレージ・デバイスの障害に対処可能
• データ破損を検出すると⾃動修復

View Slide

40
どのファイルへのアクセスもストレージの性能を最⼤限引き出す
ファイルを分割し、すべてのストレージ・デバイスに均等に分散する。
ストレージ・デバイスが増減しても、再配置して均等を維持する。
ASMのファイル配置コンセプト1
ASM上のファイル
extent extent extent
ASMエクステント

View Slide

41
どのファイルも冗⻑化して障害に対処する
• ファイルを分割しミラーを⽤意する。
• ミラーは異なる障害グループ(FAILGROUP)のストレージ・デバイスに配置する。
• ストレージ・デバイスが増減しても、再配置して冗⻑構成を維持する。
ASMのファイル配置コンセプト2
FAILGROUP 1 FAILGROUP 2 FAILGROUP 3 FAILGROUP n
プライマリ・エクステントセカンダリ・エクステントセカンダリ・エクステント
FAILGROUP ≒ 1つのストレージ筐体
1つのFAILGROUPが停⽌してもそのエクステントのミラーが他のFAILGROUPにある

View Slide

42
Stripe And Mirror Everything (S.A.M.E.)
ファイルを分割し、
• すべてのストレージ・デバイスに均等に分散する ⇒Stripe
• ミラーは異なる障害グループ(FAILGROUP)のストレージ・デバイスに配置する ⇒Mirror
そしてストレージ・デバイスが増減してもリバランスすることでStripeとMirrorを維持する
ASMのファイル配置コンセプト
1 2 3 4
3 6 1 7
5 6 7 8
4 2 8 5
異なるデバイスに
ミラーリング
すべてのデバイスにストライピング
プライマリ・エクステント
セカンダリ・エクステント

View Slide

43
ストレージ・デバイスが増減してもStripe And Mirror Everything (S.A.M.E.)を維持する
ストレージ・デバイスが故障して使⽤できなくなったらASMディスク・グループから削除
⇒エクステントを失うので既存ストレージ・デバイスにエクステントを追加して冗⻑性(2重化および3重化)を回復
ASMディスク・グループにストレージ・デバイスを追加
⇒既存ストレージ・デバイスのエクステントを追加ストレージ・デバイスに移し替えてストライプ性能向上
リバランスはオンラインで⾏われる
動的リバランス
異なるデバイスに
ミラーリング
すべてのデバイスにストライピング
削除
追加

View Slide

44
ASMファイルの破損が検出されるとセカンダリ・エクステントから読み取って処理継続および⾃動修復
ファイルの破損検出と⾃動修復
oracle
Oracleサーバー・プロセス
SGA
1. プライマリ・エクステントの
破損を検出した
2. セカンダリ・エクステントから読
み取りエラーを返さず処理継続
1 2 3
3 1 1
プライマリ・
エクステント
セカンダリ・
エクステント
3. 正常エクステントのデータで
破損個所を修復
ASMディスク・グループ

View Slide

45
データベースのバックアップ・リストア・リカバリ

View Slide

46
「Oracleインスタンス」と「データベース」
アーカイブREDOログ・ファイル
• オンラインREDOログ・ファイルの
バックアップ
オンラインREDOログ・ファイル
• 更新の履歴
• 1本書き込み完了したら複製
データファイル
• 表データの本体
プロセスとメモリーの集合
データベース

View Slide

47
Oracleサーバー・プロセスがメモリを更新しバックグラウンド・プロセスがファイルに永続化
REDOログ・バッファ
LGWR
oracle oracle
Oracleサーバー・プロセス
ログ・ライター・プロセス
データベース・バッファ・キャッシュ
DBWn データベース・ライター・プロセス
SGA
oracle
Oracleサーバー・プロセスに
よるSQL処理はメモリを更新
バックグラウンド・プロセスが
ファイルに永続化 OS
Oracle Databaseアーキテクチャ

View Slide

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

View Slide

49
INSERT
UPDATE
DELETE
オンラインREDOログ
時間
データベースの更新はオンラインREDOログ・
ファイルに記録される。
時間

View Slide

50
INSERT
UPDATE
DELETE
時間
アーカイブ・REDOログ
オンラインREDOログ・ファイルは固定⻑循環
型なので、書き込み完了したファイルはアーカ
イブREDOログ・ファイルにコピーされる。
時間

View Slide

51
INSERT
UPDATE
DELETE
時間
時刻t0
バックアップ
(データファイルのコピー)
時間
時刻t0に取得したデータ・ファイルのバックアッ
プには最新でも時刻t0までの情報しか含ま
れていない。
INSERT
UPDATE
DELETE

View Slide

52
INSERT
UPDATE
DELETE
アーカイブREDOログ
時間
時刻t0 時刻t1
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
バックアップ
時間
時刻t1にデータファイルの破損を検出した。

View Slide

53
INSERT
UPDATE
DELETE
時間
時刻t0
データファイル障害発⽣
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
バックアップ
リストア
(データファイルの書き戻し)
時刻t0に取得したデータ・ファイルのバックアッ
プには最新でも時刻t0までの情報しか含ま
れていない。
時刻t1

View Slide

54
INSERT
UPDATE
DELETE
時間
時刻t0
データファイル障害発⽣
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
リカバリ
(REDOログの適⽤)
バックアップ
リストア
データファイルの状態が
時刻t1まで復元される。
時刻t1

View Slide

55
Recovery Manager (RMAN)
破損検査付きバックアップおよびリストア・リカバリ

View Slide

56
推奨はRMAN
• Oracle付属のバックアップ・ツール
• Oracleサーバー・プロセスがデータベースのファイルにア
クセスする仕組みを使ってファイルをコピー
• Oracleインスタンス管理下で⾏われる操作
• RMAN以外の⽅法でコピーするすべての⼿法
• Oracleインスタンスがコピーを関知しない
• OSのファイル・コピー・コマンド
• ストレージ機能のスナップショットやスプリット・ミラー
Oracle Databaseの2種類の物理バックアップ⼿法
oracle
rman
（コピー元）
バックアップ
（コピー先）
スナップショット
スプリット・ミラー
Recovery Manager (RMAN) ユーザー管理バックアップ
RMANクライアント
Oracleサーバー・
プロセス
コピー元ボリュームバックアップ・ボリューム

View Slide

57
確実にリカバリするための"Recovery" Manager
• コピー時に破損検査が⾏われる
• 破損が伝搬しない
• バックアップしたファイルの破損検査も可能
• 破損領域がそのままコピーされる
• バックアップも破損している場合がある
• 誤った単位でボリュームをコピーしているとリカバリ時に
なってはじめてリカバリ不能に気付く
ファイル・コピー中のブロック破損検査
oracle
rman
（コピー元）
バックアップ
（コピー先）
スナップショット
スプリット・ミラー
Recovery Manager (RMAN) ユーザー管理バックアップ
RMANクライアント
Oracleサーバー・
プロセス
コピー元ボリュームバックアップ・ボリューム

View Slide

58
データベース本体の破損に備えるためのバックアップ
データベース本体とバックアップ⽤ストレージは分ける
• 更新の履歴
• データの本体
バックアップ
• データファイルの
バックアップ
データベース本体⽤ストレージバックアップ⽤ストレージ

View Slide

59
最新の更新情報はオンラインREDOログ・ファイルにしかない
バックアップデータファイル
データベース
最新の更新情報
• 更新の履歴
• 1本書き込み完了したら複製

View Slide

60
書き込み真っ最中のオンラインREDOログ・ファイルは複製できない
「バックアップ」操作で複製できる範囲
データベース
「バックアップ」操作で複製できる範囲
• 更新の履歴
• 1本分書き込み完了したら複製
バックアップデータファイル
追記中のオンラインREDOログ・
ファイルは複製できない

View Slide

61
データベース本体⽤ストレージ
オンラインREDOログ・ファイルが格納されているストレージが全損すると
INSERT
UPDATE
DELETE
時間
時刻t0 時刻t1
ストレージ障害発⽣
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
リカバリ
バックアップ
リストア
最新のトランザクション
情報を失う

View Slide

62
(Active) Data Guard
最新のREDO情報をリモート・データベースに転送

View Slide

63
プライマリ・データベース⽤ストレージが全損しても最新のREDO情報が別の場所にある
REDO情報が⽣成されたら即時に別のサーバーに転送︓(Active) Data Guard
• 更新の履歴
プライマリ・データベース⽤ストレージスタンバイ・データベース⽤ストレージ
プライマリ・データベース・サーバー
ネットワーク
メモリー(REDOログ・バッファ)上
にREDO情報が⽣成されたら
転送開始
スタンバイREDOログ・ファイル
• プライマリのREDO情報の受信
スタンバイ・データベース・サーバー

View Slide

64
プライマリ・データベースのREDO情報でデータファイルをリカバリし続ける
(Active) Data Guard︓プライマリ・データベースと全く同じ内容になる
• 更新の履歴
プライマリ・データベース⽤ストレージスタンバイ・データベース⽤ストレージ
ネットワーク
リカバリ継続
スタンバイ・データベース・サーバー
プライマリと同⼀内容

View Slide

65
(Active) Data Guard︓リモートでリストア＆リカバリを継続
INSERT
UPDATE
DELETE
時間
時刻t0
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
バックアップ
リストア
スタンバイ・データベース
プライマリ・データベース
REDO転送
リカバリ
(REDOログの適⽤) 最新のトランザクション
情報が複製される
REDO転送

View Slide

66
Flashback Database
過去のある時点の状態に戻したい

View Slide

67
ポイント・イン・タイム・リカバリ
1. 該当データファイルのアクセスしたい時刻(時刻t1)より前(時刻t0)のフル・バックアップからリストアする。
2. リカバリを途中(時刻t1)で⽌める。
⇒データファイルのサイズが⼤きいとリストアにかなり時間がかかる。
過去のある時点のデータにアクセスしたい
時間
時刻t0 時刻t2
リカバリ
バックアップ
リストア
時刻t1
リカバリを時刻t1までで⽌める最新データの時刻はt2

View Slide

68
指定した時刻までデータベースの状態を戻す
Flashback Database
0. Flashback Databaseを有効にすると、UNDOブロックのバックアップがFast Recovery Areaに取られる
1. 戻したい指定時刻(時刻t1)より前のUNDOブロックをリストア
2. REDOを適⽤して指定時刻(時刻t1)までロールフォワード
⇒データファイル全体をリストアするポイント・イン・タイムリカバリより速いし簡単
Flashback Database
時間
時刻t0 時刻t2
リカバリ
Flashback Log
(UNDOブロックのバックアップ)
リストア
(UNDOブロックの書き戻し)
時刻t1
リカバリを時刻t1までで⽌める最新データの時刻はt2

View Slide

69
Flashback Database/Data Guard/バックアップがカバーする範囲は異なる
INSERT
UPDATE
DELETE
時刻t1
バックアップ
(⻑期間の過去状態の保存)
時間
INSERT
UPDATE
DELETE
⽋損
(Active) Data Guard
(最新状態のデータベースに短時間で切り替え)
Flashback Database
(⽐較的短期間の過去に戻す)
~数⽇
数百~数⼗⽇
⼀般的な「バックアップ」はバックアップ操作をしたときに存在してい
たファイルを複製するので最新のREDO情報が複製できない。
アーカイブREDOログ・ファイルと同じ領域にUNDOブロックのバッ
クアップを取得するので容量的にバックアップほどの⻑期間保持す
るのは難しい。データベースのファイルが破損していないことが前提。
Data Guardは転送されたREDOでリカバリを継続するので最
新に近い状態のデータベースを維持する。時刻t1より前に戻すに
はFlashback Databaseと組み合わせる。

View Slide

70
Zero Data Loss Recovery Appliance (ZDLRA)
RMANバックアップ + Data GuardのREDO転送

View Slide

71
REDO転送の仕組みを流⽤することで最新の状態までリカバリ可能
Zero Data Loss Recovery Appliance (ZDLRA または RA)
• Data GuardのREDO転送の仕組みを流⽤
• バックアップ+REDO転送のOracle Database専⽤バックアップ・アプライアンス
• ほぼ最新のREDO情報の複製を持っているため最新の状態までリカバリ可能
• ハードウェアはExadataを流⽤
Oracle Database専⽤のバックアップ・アプライアンス

View Slide

72
プライマリ・データベース⽤ストレージが全損しても最新のREDO情報が別の場所にある
REDO転送の仕組みをバックアップ⽤サーバーにも実装︓ZDLRA
• 更新の履歴
Zero Data Loss Recovery Appliance
RMANバックアップ+Data Guard REDO転送
ネットワーク
メモリー(REDOログ・バッファ)上
にREDO情報が⽣成されたら
転送開始
• プライマリのREDO情報の受信
※ZDLRAでのREDO転送は⾮同期(ASYNC)モード

View Slide

73
Zero Data Loss Recovery Appliance︓バックアップ+REDO転送
INSERT
UPDATE
DELETE
時間
時刻t0
INSERT
UPDATE
DELETE
INSERT
UPDATE
DELETE
バックアップ
ZDLRA
プライマリ・データベース
REDO転送
通常のバックアップがカバーできる範囲
(データファイルとアーカイブREDOログ・ファイルのコピー)
REDO転送
REDO転送
最新のトランザクション
情報が複製される
Zero Data Loss

View Slide

74
Flashback Database/Data Guard/バックアップがカバーする範囲は異なる
INSERT
UPDATE
DELETE
時刻t1
バックアップ
時間
INSERT
UPDATE
DELETE
⽋損
(Active) Data Guard
(最新状態のデータベースに短時間で切り替え)
Flashback Database
(⽐較的短期間の過去に戻す)
~数⽇
数百~数⼗⽇
バックアップ
REDO転送
(最新REDO)
⼀般的な「バックアップ」はバックアップ操作をしたときに存在してい
たファイルを複製するので最新のREDO情報が複製できない。
Zero Data Loss Recovery Applianceはバックアップ
+REDO転送で最新のREDO情報まで複製できる。
アーカイブREDOログ・ファイルと同じ領域にUNDOブロックのバッ
クアップを取得するので容量的にバックアップほどの⻑期間保持す
るのは難しい。データベースのファイルが破損していないことが前提。
Data Guardは転送されたREDOでリカバリを継続するので最
新に近い状態のデータベースを維持する。時刻t1より前に戻すに
はFlashback Databaseと組み合わせる。

View Slide

75
REDO転送の仕組みを流⽤することで最新の状態までリカバリ可能
Zero Data Loss Recovery Appliance (ZDLRA または RA)
• Data GuardのREDO転送の仕組みを流⽤
• バックアップ+REDO転送のOracle Database専⽤バックアップ・アプライアンス
• ほぼ最新のREDO情報の複製を持っているため最新の状態までリカバリ可能
• ハードウェアはExadataを流⽤
Zero Data Loss Autonomous Recovery Service (ZRCV)
• ZDLRAをOracle Cloud Infrastructureのサービスとして提供
• バックアップの容量に⽐例する課⾦体系
• REDO転送なし(RCV)
• REDO転送あり(ZRCV)
Oracle Database専⽤のバックアップ・アプライアンス

View Slide

76
SQL
サービス
service-A
データベース
Maximum Availability Architecture
• サービスが具象レイヤーの構成を隠蔽
• サービスへのアクセスを継続
抽象化されたデータ操作を計画停⽌/⾮計画停⽌どちらがあっても継続する

View Slide

Oracle Database World
Tokyo
ご清聴ありがとうございました

View Slide

[DBWT-2] 信頼性: ミッションクリティカルなデータベースに必須となる高可用性の考え方とは

[DBWT-2] 信頼性: ミッションクリティカルなデータベースに必須となる高可用性の考え方とは

oracle4engineer
PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

[DBWT-2] 信頼性: ミッションクリティカルなデータベースに必須となる高可用性の考え方とは

[DBWT-2] 信頼性: ミッションクリティカルなデータベースに必須となる高可用性の考え方とは

oracle4engineer PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

oracle4engineer
PRO