Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャ

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Zero Data Loss Recovery Appliance による
データベース保護のアーキテクチャ
日本オラクル株式会社
クラウド・テクノロジー製品戦略統括本部データベースエンジニアリング本部
シニアエンジニア
佐々木亨

• 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明する
ものです。また、情報提供を唯一の目的とするものであり、いかなる契約
にも組み込むことはできません。以下の事項は、マテリアルやコード、機
能を提供することをコミットメント（確約）するものではないため、購買決定
を行う際の判断材料になさらないで下さい。オラクル製品に関して記載さ
れている機能の開発、リリースおよび時期については、弊社の裁量により
決定されます。
2
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。

本日覚えて帰って頂きたい内容
Recovery Appliance は
• RMAN 増分バックアップと Data Guard のREDO 転送
(適用は含まない) の機能を使って非常に多くのデータベース
(数千) を対象にしてバックアップを取得可能
• ブロック検査&圧縮済みのバックアップから、任意の時点に
高速(1度のリストア) に、リカバリすることが可能
3

本日の内容
1
2
3
4
5
バックアップ・リカバリの現状と Recovery Appliance の概要
ハードウェア・ソフトウェア構成概要
アーキテクチャ
バックアップのライフサイクル
まとめ
4

従来のバックアップ装置はDB保護に適していない
定期的にファイルコピーを単にするだけでは、以下の課題が起こりえる
5
毎日のバックアップ・ウィンドウ
本番環境への大きな性能インパクト
フルバックアップはCPU, I/O, ネット
ワークを膨大に消費
データ損失のリスク
最後のバックアップ以降の全デー
タを失うリスク
(DBをマウントできなくなった場合)
例えば夜間バックアップだけでは
日中データを失うリスクがある
膨大なバックアップ・システ
ムの管理
拡張性に乏しいため、各DB毎に
バックアップ装置を個々に導入し、
管理/運用している
データベースを正常に復旧で
きないリスク
単にファイルコピーするだけで、DB
を意識しない状態で保管されている
ため、リカバリできないリスクがある

Zero Data Loss
Recovery Appliance
6
従来のデータベース・バックアップ
を根本から革新

Recovery Appliance が実現するユニークなメリット
7
バックアップ業務の影響を最
小化（フルバックアップは初回
のみ）
本番環境はデータ変更のみを転送
し、バックアップ業務はオフロード
データ損失をなくす
リアルタイム・ログ転送により迅
速なトランザクション保護を実現
卓越した拡張性、多様な環
境に対応
単一システムを柔軟に拡張し、
データセンター内の全てのデータ
ベースを容易に保護。各種OS/
バージョンに対応
データベース・レベルの確実
な復旧
エンドツーエンドの信頼性と可視性、
管理が可能。データベース・フォー
マット/ブロック・レベルでの保証

バックアップ・リカバリの統合的な管理
単一システムで、あらゆるバージョン/プラットフォームを統一した方式で管理
8
個別システム毎のバラバラな管理 Recovery Appliance での統一管理
Oracle 10g
Oracle 11g
Oracle 12c
EE/SE
Linux
Windows
Solaris
AIX
HP-UX
Windows
Linux
Solaris
AIX
HP-UX
EMC
IBM
HP
NetApp

Recovery Appliance：全体概要
Recovery
Appliance
EM 12c
Delta Push:
• 増分バックアップを定期取得
• 変更データのみを送信
• REDO を送信(任意)
Delta Store:
• ブロックチェック、圧縮済みの形で
バックアップデータを格納
• 任意の時点へ高速なリストア
• Exadata のスケーラビリティと柔軟性
Tape Library
Autonomous
Archive:
• テープへのコピー
Replication :
• DRサイトへの複製
クラウドスケール
• 数千もの保護DB
• 各種OS/Version対応
• ペタバイトのデータも
保護
• 高価な Agentが不要
9

本日の内容
1
2
3
4
5
まとめ
10

ハードウェア構成(1/2)
Base Rack からスタートし、ストレージを1台ずつ拡張していく
• Base Rack (最小構成)
– 2 x Compute Server
• 4 x 10Gb Ethernet ports / Server
• Dual 40Gb/sec InfiniBand ports / Server
• Dual-port 16Gb Fibre Channel for Tape Connectivity / Server (Option)
– 3 x Storage Server
• 12 x 8 TB (raw) 7,200RPM High Capacity Disk / Server
• Full Rack: 2 x Compute Server, 18 x Storage Server
11
ストレージ拡張
Recovery Appliance
Base Rack

ハードウェア構成(2/2)
• Step 1: Base Rack
– Exadata Quarter Rack 同一
– Compute 2台 + Cell 3台
• 実効容量：94TB
• Step 2: Storage Cell 追加
– Cell を1台づつ追加 (32TB)
– Full Rack: Cell 18台
• 実効容量：580 TB
• Step 3: Multi Rack
– 18 Rack まで接続可能
• 実効容量：約10PB
• InfiniBand 接続
• 複数世代の混在可
12

ソフトウェア構成(1/3)
Recovery Appliance 内のソフトウェア
• Exadata と同様 OEDA (Oracle Exadata Deployment Assistant) を用いて構築
• Grid Infrastructure が構成される
– 2つの ASM Disk Group (+CATALOG, +DELTA)
– CATALOG：3重化、DELTA：2重化(default)
• RAC データベースが1つ作成される
– 各保護DBのリカバリ・カタログが格納される
(+CATALOG)
– バックアップのメタデータ格納(+CATALOG)
• 受信したバックアップは +DELTA に格納
13
DB Instance
process
process
process
カタログDB＋メタデータ
(+CATALOG)
バックアップ格納場所
(+DELTA)
バックアップ
セット

保護DB上に必要な追加ソフトウェア
• 保護DBの$OH上に Oracle が提供する SBTライブラリ (libra.so) を配置
– 配置するためのツールはOTN で提供
• ライブラリの配置、Recovery Appliance に接続
するためのWallet の設定、通信ポートの設定
14
$ java -jar ra_install.jar -dbUser <dbuser> -dbPass <pass>
-host <host> -port <port> -serviceName <service>
-walletDir <walletdir> -libDir <SBTLIBdir>
• バックアップ取得時の動作
– RMANによって起動された保護DB上のサーバープロセスが
上記 SBTライブラリを用いてバックアップデータをネットワーク越しに転送する
– バックアップを転送する特別なプロセスが起動するわけではない

Enterprise Manager Recovery Appliance Plug-in
• 多数の保護DB のバックアップを
Enterprise Manager を使って管理
• 必要なソフトウェア
– EM 12.1.0.4
– DB Plug-in 12.1.0.6
– Exadata Plug-in 12.1.0.6
– Recovery Appliance Plug-in 12.1.0.1
• Recovery Appliance 上の設定は、
DBMS_RA PL/SQL Packageで実施可
15

ネットワーク構成
• 10GbE / InfiniBand での接続を利用可能
– InfiniBand 接続はEngineered System とのサポートではされる
• Backup/Restore 転送ネットワークは 10GbE を使うことを推奨
– InfiniBand のメンテナンス(upgrade)時に停止が必要な可能性あり
– IBネットワークを介したバックアップファイルの転送(受信)によって、Recovery
Appliance内でのバックアップファイルのI/O が影響を受けるのを防ぐため
• ネットワーク暗号化の必要がある場合は SSL通信を使う
– DB 10.2 ～ 11.2.0.3 は手動での HTTPS 構成が必要
– DB 11.2.0.4 及び 12.x は完全にサポート
16

リカバリ・カタログ・データベースの使用について
• 保護DB内の制御ファイルを使ったバックアップの管理は不可
– Recovery Appliance 側で、空き領域管理など通常のバックアップ管理以上の
ことを行うため、保護DB側の個々の制御ファイルでは管理できない
• バックアップ取得時には、カタログDBと保護DBに接続
– カタログDBに接続するユーザは、保護DB毎に分けることも可能
– 他のDBのバックアップにアクセス不可
• Recovery Appliance の管理
ユーザが “RASYS”
– DBMS_RAパッケージ
– リカバリ・カタログ
17
RA スキーマ
リカバリ・カタログ
Virtual Private
Catalog
Virtual Private
Catalog
RASYS
保護対象データベース
Connect
as SYSBACKUP
Connect
as RA User
RA User

リカバリ・カタログ・データベースのバックアップについて
• 仮想フル・バックアップをリストア・リカバリするには、Recovery Appliance
上にあるカタログ情報とメタデータが必要
定期的にRecovery Appliance 上のカタログ・データベースのバックアップを取得する
ことを推奨
– Recovery Appliance に組み込まれている RMANスクリプトを使って、Recovery
Appliance 内の高速リカバリ領域（+DELTA）、もしくはテープにバックアップを取得する
(+CATALOG  +DELTA もしくは +CATALOG  Tape)
• テープ上のバックアップはRMANのバックアップセット形式に再度変換され
ているため、テープと保護DBを直結すれば、Recovery Appliance 上のカタ
ログを介さずにリストアすることが可能
18

本日の内容
1
2
3
4
5
まとめ
19

Recovery Appliance：全体概要
クラウドスケール
• 数千もの保護DB
• 各種OS/Version対応
• ペタバイトのデータも
保護
• 高価な Agentが不要
Recovery
Appliance
EM 12c
Delta Push:
• 増分バックアップを定期取得
• 変更データのみを送信
• REDO を送信(任意)
Delta Store:
• ブロックチェック、圧縮済みの形で
バックアップデータを格納
• 任意の時点へ高速なリストア
• Exadata のスケーラビリティと柔軟性
Tape Library
Autonomous
Archive:
• テープへのコピー
Replication :
• DRサイトへの複製
20

Delta Push
21

Delta Push で覚えて頂きたいポイント
22

Delta Push の概要イメージ
• フル・バックアップを送るのは初回のみ
– Image Copy 形式ではなく、Backup Set 形式
• 以降は永久に増分バックアップ（=Delta）
を送る（フル・バックアップは二度と不要）
 Incremental Forever Backup Strategy
• 2つの増分バックアップの間の変更デー
タは、REDO転送によって埋める
(REDOは送ってRecovery Appliance上で
溜めておくだけで適用はしない)
23
A A A A A
B A A B B
B C A B C
時間
Lv0 Backup A A A A A
B B B
C C
9/1 AM 1:00
A A A B B
B A A B C
Lv1 Backup
9/2 AM 1:00
Lv1 Backup
9/3 AM 1:00
REDO転送
REDO転送
Backup転送
Backup転送
Backup転送
Recovery
Appliance
switch

フル・バックアップ、増分バックアップをRecovery Appliance に送る方法
a. SBT ライブラリを使ったバックアップの転送
b. Polling によるバックアップの転送
※ 上記のいずれかを使う
REDO データを送る方法
c. Near-Zero Data Loss Recovery REDO転送
Delta Push の概要
保護DBからRecovery Appliance へのデータの流れは大きく3種類
24
Recovery
Appliance
Archived
REDO
Storage Location
(+DELTA)
Backup
Polling Location
(NAS)
(a)
(b)
(c)
Backup Set

(a). Recovery Appliance へのバックアップ・データの送信
• サーバー・プロセスがSBT ライブラリを使い増分バックアップをRecovery
Appliance に直接送信(ローカルにバックアップ・ファイルの置き場は不要)
• Recovery Appliance との通信には、HTTP/HTTPS が使われる
• 保護DB側のバックアップ・コマンドを下記のようにする (後述の通り、EMを
使えばコマンドは自動生成される)
25
RMAN>
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE 'SBT_TAPE‘
PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.1.0.2/dbhome_1/lib/libra.so,
ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/zdlra
credential_alias=xxxxxxx:1521/zdlra:dedicated')";
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DEVICE TYPE SBT TAG ‘BCK_DBM01_20141111' database;
}
ツールを使ってコピーした
SBTライブラリを使用
Recovery Applianceに接続するた
めの資格証明用Wallet

ジョブ管理システムからのバックアップジョブ発行
• JP1 などのジョブ管理システムから、バックアップ・ジョブを実行するには、
下記のようにします
– 保護対象DBと、Recovery Appliance 上のカタログ・データベースの両方に、RMAN ク
ライアントから接続（P.17参照）
– 前ページのRMANの Backup コマンドを発行する
– Backup コマンドのプロンプトが正常終了で返れば Backup 完了
26

バックアップの設定(1/2)
• Recovery Appliance のセットアップ、設定とは別に、保護DB側でバックアッ
プの設定（バックアップ先、スケジュール）が必要
– EM画面：保護DB > 可用性 > バックアップとリカバリ > バックアップ設定
27
バックアップ転送先Recovery Applianceの
選択とカタログDB用ユーザ名の選択
各種選択後、「適用」ボタンを押すと、
必要な設定が行われる
• 初期化
• データベース・ホストの構成
• Recovery Appliance リカバリ・カタログ
使用の設定
• メディア管理設定
• ログ・アーカイブ保存先およびREDOト
ランスポート・ユーザの構成
• パラメータの評価
• データベースの再起動
• 構成後処理
保護DB側での設定

バックアップの設定(2/2)
• バックアップ先の指定後、バックアップのスケジュールを設定
• EM Recovery Appliance Plug-in をインストール済みの場合、下記設定画面
で、Recovery Appliance へのバックアップに適した設定が可能
– 保護DBのHome > 可用性 > バックアップとリカバリ > バックアップのスケジュール
28

(b). Polling によるRecovery Appliance へのバックアップ転送
• 保護DB側で単独でバックアップを取り、NASに配置している場合
• 指定したディレクトリ・パス(Backup Polling Location)を、Recovery Appliance
が定期的にPolling し、新しいバックアップがあればコピーする
• Backup Polling Location を
Recovery Appliance からマウントして
アクセス可能である必要がある
• Recovery Appliance 側へのバックアップの
コピーが完了後、NAS上のオリジナル
バックアップを消す設定は可能
29
NAS
保護DB群
バックアップ
Polling

Polling の設定(1/1)
• Recovery Appliance で設定する保護ポリシーの設定画面で指定する
– EM 画面： Recovery Appliance > Protection Policies > Create
– Recovery Appliance から Polling するロケーション
– Polling する頻度
– Polling して Recovery Appliance にバックアップをコピーした後に、Polling ロケーショ
ンにあるオリジナルのバックアップを消すかどうかのチェック
30
Recovery Appliance側
での設定

(c). Near-Zero Data Loss Recovery REDO転送
• データベース障害(マウントできなくなる)が発生すると、前回 Incremental
Backup を取得以降の変更が失われることになる
• データベース単体で実施可能な対策
1. 頻繁に増分バックアップを取得する
2. アーカイブREDOログを別途バックアップする
• いずれの場合も、オンラインREDO上のREDOは失われる可能性があるし、
頻繁なバックアップは本番データベースの負荷増大につながる
 “Near-Zero Data Loss Recovery” を実現するために、Data Guard のように、
ログバッファ/オンラインREDOログからREDOを読み、常時REDO を
Recovery Appliance 側に転送する
31

DB Instance
32
Recovery
Appliance
Backup
(1) REDO転送
データファイル
ログ
バッファ
NSA/
TTnn
DB Instance
RFS
Flash
Storage Location
(+DELTA)
保護DB
バックアップ
セット
(2) Storage Location にアーカイブして、
リカバリカタログに登録
REDO Logs
LAD1
location=USE_DB_RECOVERY_FILE_
DEST
valid_for=(ONLINE_LOGFILE,ALL_RO
LES) db_unique_name=dblra
alternate=LOG_ARCHIVE_DEST_2
LAD2
location=+CATALOG
valid_for=(ONLINE_LOGFILE,ALL_RO
LES) db_unique_name=dblra
alternate=LOG_ARCHIVE_DEST_1
LAD3
location=+DELTA
valid_for=(STANDBY_LOGFILE,ALL_R
OLES)
Data Guard との違いは、REDOの送信元と、受信先のDBの関係が、「多対１」という点
（Data Guard の場合は、「１対１」）

• REDO転送の仕組みはData Guard と同じ
– 転送プロセスがログ・バッファからREDOを読み出し、Recovery Appliance に送る
– 現時点では非同期転送のみ可能
• REDO受信後の動作
– Recovery Appliance 側でREDOを受け取ると、一旦、Flash に格納
– このFlash上のREDOログを、Storage Location に圧縮、アーカイブして、リカバリカタロ
グに登録する（一時ファイルは削除される）
33

Near-Zero Data Loss Recovery REDO転送設定(1/1)
• バックアップ設定画面でチェックを入れると自動設定される
– 保護DBのHome > “可用性” > “バックアップとリカバリ” > “バックアップ設定”
• 設定作業を続けると下記が自動設定される
– LOG_ARCHIVE_DEST_n パラメータなど通常のData Guard と同等の設定(保護DB側)
34

Delta Push まとめ
保護DBからRecovery Appliance へのデータの流れは大きく3種類
フル・バックアップ、増分バックアップをRecovery Appliance に送る方法
a. SBT ライブラリを使ったバックアップの転送
b. Polling によるバックアップの転送
※ 上記のいずれかを使う
REDO データを送る方法
c. Near-Zero Data Loss Recovery REDO転送 Recovery
Appliance
Archived
REDO
Storage Location
(+DELTA)
Backup
Polling Location
(NAS)
(a)
(b)
(c)
Backup Set
35

Delta Store
36

Delta Store で覚えて頂きたいポイント
37

Delta Store の概要イメージ
• 送られてきたバックアップ・セットは、小さな
単位（便宜上”ブロック”と呼ぶ）に分解する
• ブロックを検査、圧縮を行い格納
• 圧縮されたブロック毎に管理される
• 管理のためのメタデータは、カタログ・データ
ベース上に保持している
• メタデータを基に個々のブロックを寄せ集め
て、フル・バックアップ相当のもの（仮想フル・
バックアップ）を作り出せる
38
A A A A A
B B B
C C
Recovery
Appliance
A A A A A
B C A B C
B A A B B
#1 #2 #3 #4 #5
#6 #7 #8
#9 #10
Virtual Full #1 =
{#1,#2,#3,#4,#5}
Virtual Full #2 =
{#6,#2,#3,#7,#8}
Virtual Full #3 =
{#6,#9,#3,#7,#10}
カタログDB内の
メタデータ

Delta Store の特徴
• 仮想フル・バックアップの仕組みにより、任意の時点に高速にリカバリ可能
– 1度の（仮想フル・バックアップ）リストア＋リカバリで復旧可能
• REDO はリカバリに使われるだけなのでRecovery Appliance 上で特殊な加工はされない
• 下記の処理を本番DBサーバーから Recovery Appliance へオフロード可能
– 取得済みバックアップのブロック破損有無の検査
– RMANバックアップの圧縮
• Exadata のスケーラビリティと柔軟性が組み込まれている
– Exadata + Storage Expansion (HCディスク)
– 多くの保護DBのバックアップに対応可能
39

用語の整理
• Delta Pool
– Recovery Appliance に送られてきたバックアップを加工して格納する場所
– 仮想フルバックアップを構成するデータファイルブロックの集合
– 同じ保護DBの同じデータファイルのバックアップは、同じDelta Pool 内に格納される
– Recovery Appliance セットアップ時に多数のDelta Pool が作成される
• Delta Store
– Delta Pool の集合
• Storage Location
– ASM Disk Group と1対1対応、サイズ指定する
– 現行バージョンではASM Disk Group は1つなので
Storage Location も1つ
40
Storage Location = ASM Disk Group
Delta Store
Delta Pool
Delta Pool
Delta Pool
Delta Pool
Delta Pool
Delta Pool

仮想フル
仮想フル・バックアップ（イメージ）
A A A A A
B A A B B
B C A B C
時間
Lv0 Backup A A A A A
B B B
C C
累積増分
A A A A A
B C A B C
B A A B B
A A A A A
B B B
C C
9/1 AM 1:00
分解 &
圧縮
Virtual Full #1
Virtual Full #2
Virtual Full #3
41
#1 #2 #3 #4 #5
#6 #7 #8
#9 #10
Recovery
Appliance保護DB
A A A B B
B A A B C
Lv1 Backup
9/2 AM 1:00
Lv1 Backup
9/3 AM 1:00
REDO転送
REDO転送
Backup転送
増分Backup転送
増分Backup転送
白抜きで表して
いるブロックは実
体は存在しない
分解 &
圧縮
分解 &
圧縮
-- POINT② --
Full #1 からの累積ではなく、
Virtual Full #2 からの累積
-- POINT① --
差分増分 Backup でなく、
累積増分 Backup が推奨
Virtual Full #1 =
{#1,#2,#3,#4,#5}
Virtual Full #2 =
{#6,#2,#3,#7,#8}
Virtual Full #3 =
{#6,#9,#3,#7,#10}
-- POINT③ –
点線部分に相当する
メタデータを保持している

仮想フル・バックアップ(Virtual Full Backup)
• 仮想フル・バックアップ作成の流れ
– Recovery Appliance で受信したバックアップを、小さな単位（便宜上”ブロック”と呼ぶ）
に分解し、検査・圧縮して、Delta Poolに格納する
– 索引付けをして、バックアップ取得時点における、仮想的なフル・バックアップを構築す
る (仮想フル・バックアップ)
• 索引はRecovery Appliance 内にあるカタログDBにメタデータという形で格納される
• 仮想フル・バックアップは VB$_* という形でリカバリ・カタログから見える
• 管理者からは、通常のフルバックアップと同様に扱える
– 仮想フル・バックアップ完成時点で、Recovery Appliance で受信した、分解前のバック
アップ・セットは削除される
• 分解して、Delta Pool 内に格納されている、仮想フル・バックアップを構成しているブロックは、保護ポ
リシーに則って削除される
• レプリケーション設定時は、削除前にバックアップを複製先に転送される
42

仮想フル・バックアップの制限
• 制限事項
– 10gR2(10.2.0.5)以降のデータベースが対象
– バックアップ・セット方式のバックアップが前提
– RMANで圧縮、暗号化したバックアップからは仮想フル・バックアップは作成できない
• バックアップは可能だが、オリジナルの暗号化されたフォーマットのまま格納される
– TDE(表領域暗号化)で暗号化されたデータからは、仮想フル・バックアップを作成可
• Recovery Appliance 上でも暗号化された状態で格納される
43

仮想フル・バックアップ
44
“VB$_” で始まる名前のものが仮想フル・バックアップ
この仮想フル・バックアップは通常のフル・バックアップ
と全く同じように扱うことができる

仮想フル・バックアップの推奨事項
• 増分バックアップは、”累積増分”で取得される(デフォルト設定)
45
前回レベル1以降に変更された
全ブロックをバックアップ
前回レベル0以降に変更された
全ブロックをバックアップ
• 累積増分だと、レベル0を一度しか取らない ”Incremental Forever Backup”
戦略だと、バックアップ量が次第に大きくなるのでは？  間違い
– 累積増分も差分増分も実質的に動作は変わらない
– 直近の累積増分から作成された仮想フル・バックアップが直近のレベル0扱いとなる
差分増分バックアップ累積増分バックアップ

仮想フル・バックアップを用いたリストア・リカバリ
（例）9/2 PM 05:00 の時点にPoint in Time リカバリしたい場合
46
A A A A A
B A A B B
B C A B C
時間
9/1 AM 1:00
A A A B B
B A A B C
9/2 AM 1:00
9/3 AM 1:00
Recovery
Appliance
A A A A A
B C A B C
B A A B B
A A A A A
B B B
C C
Virtual Full #1
Virtual Full #2
Virtual Full #3
#1 #2 #3 #4 #5
#6 #7 #8
#9 #10
Virtual Full #2 =
{#6,#2,#3,#7,#8}
9/2 PM 5:00 の時点に
Point in Time リカバリしたい
1.直近の仮想フル・バックアップ
(=Virtual Full #2) をリストア
 Block#6,2,3,7,8 を寄せ集めて
リストアする
2.それ以降、9/2 05:00 までのREDO
(アーカイブREDO)を使ってリカバリ
アーカイブREDO
アーカイブREDO
B A A B B ＋ B A A B C

仮想フル・バックアップを用いたリストア・リカバリ
• 任意の時点へのPoint-in-Time リカバリにおいて、「直前の仮想フル・バッ
クアップのリストア＋リカバリ」で済む
– 「フル・バックアップのリストア＋ Level 1 増分バックアップのリストア + リカバリ」
とはならず、リストアが一度で済む
• 「増分更新バックアップ」でもリストアは一度で済むが、「任意の時点」
へのPoint-in-Time リカバリはできない
– オリジナルのフル・バックアップに増分バックアップを適用済みなので
利用可能なユースケース
ある時点の本番データベースのバックアップを使って、ステージング環境
にテスト用のデータベースを作成する
47

本日の内容
1
2
3
4
5
まとめ
48

Gold
Silver
Bronze
保護ポリシーの管理
• バックアップは保持期間などを設定して、取得から削除までのライフサイ
クルを適切に管理する必要がある
• 可用性要件毎にポリシー(リカバリ・ウィンドウ、ディスク保持期間など)を
定義し、データベース毎にポリシーを適用する
49
ミッション・クリティカル
ディスク：30日、テープ：90日、Replication 有
ビジネス・クリティカル
ディスク：10日、テープ：30日、Replication 無
テスト、開発
ディスク：6時間、テープ：なし、Replication 無
ポリシーの例

保護ポリシーの定義
Storage Location の作成
• Storage Location ：受信したバックアップを格納する ASM Disk Group
– 下記の項目を指定する
• Storage Location 名
• 使用する ASM Disk Group
– 現行 Recovery Appliance で指定可能なDisk Group は1つ
(= +DELTA)
• 使用するサイズを指定
50
での設定
Storage Location = ASM Disk Group
Delta Store
Delta Pool
Delta Pool
Delta Pool
Delta Pool
Delta Pool
Delta Pool
設定後のEM画面

保護ポリシーの作成(1/2)
• 下記の項目を指定する
– 保護ポリシー名
– リカバリ・ウインドウ目標(Disk&Tape)：どの時点まで、Point-in-time リカバリ可能とするか
– Storage Location 名：保護ポリシーを割り当てたDBのバックアップが格納される場所
– Copy to Tape / レプリケーション
• テープへの移動、他のRecovery Appliance への複製を行うか
51
での設定
設定後のEM画面

保護ポリシーの作成(2/2)
• recovery_window_goal / recovery_window_sbt
– 何日前まで Point-in-Time リカバリを可能にするか期間を指定
– Disk 上のバックアップ、Tape 上のバックアップそれぞれに対して指定
• max_retention_window
– バックアップを保持する期間を指定
• guaranteed_copy
– バックアップがディスク上から削除される前に、テープやReplication先に移動するか
• No ：バックアップ時に領域がなければ古いものは消されるが、バックアップが失敗しない
• Yes ：バックアップ時に領域がなければ、バックアップを失敗させる。保持目標を満たすことを優先
52
での設定

保護DBに保護ポリシーを割り当てる
• 保護DBをRecovery Appliance上のリカバリ・カタログに登録する
– DB名、対応させる保護ポリシー、利用する領域サイズを指定する
– Storage Locationは、複数の保護DBで共有されるので、各保護DB毎に、使用するサイ
ズを管理者自身で計算して指定する必要がある
• サイジングの目安は下記
SIZE(Level0) + SIZE(Level1) * recovery_window
+ SIZE(archivelog/1day) * recovery_window
これに圧縮率、データ量増加を加味
53
での設定
保護DB毎に、保護ポリシーを
割り当てている

バックアップの世代管理からの解放
最新のLevel 0 & 過去7日以内にリカバリ可能なLevel 0 + Level 1を保持
54
RMAN> #毎日の高速増分バックアップ（二つのLevel0の増分適用処理を含む）
run{
RECOVER COPY OF DATABASE WITH TAG 'NEWEST' ;
RECOVER COPY OF DATABASE WITH TAG 'BEFORE7DAYS' UNTIL TIME 'SYSDATE-7' ;
DELETE NOPROMPT OBSOLETE ;
BACKUP INCREMENTAL LEVEL 1 cumulative FOR RECOVER OF COPY WITH TAG 'NEWEST' DATABASE ;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL TAG 'INCR_UPDATE' ;}
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 2 ; # Level0が2世代となる為
RMAN> #初めてのバックアップ
run{
BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'NEWEST' ;
BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'BEFORE7DAYS' ;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL TAG 'INCR_UPDATE' ;}
RMAN>
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE 'SBT_TAPE‘
PARMS=“SBT_LIBRARY=＄ORACLE_HOME/lib/libra.so,ENV=(RA_WALLET=‘location=file:$ORACLE_HOME/dbs/zdlra
credential_alias=hostname:1521/zdlra:dedicated')";
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DEVICE TYPE SBT TAG ‘INCR’ database; }
DB毎に保持要件が違うと、
DBの数だけスクリプトを用意
用意するスクリプトは1つのみ
バックアップは保護ポリシー
に合わせて自動的に世代管
理されるRecovery Appliance用のスクリプト

Delta Pool の空き領域管理
• バックアップの削除対象有無の確認を行うタイミング
– 定期的なタイミング(バックアップをDisk からTapeに移動するジョブ)
– バックアップ取得時に領域が不足しているタイミング
• 管理方法
– 下記の優先順で削除対象とする
1. 期限切れしているアーカイブバックアップ
2. バックアップの存在期間＞バックアップ保持期間かつ Point-in-Time リカバリに不要なものを削
除対象とする
3. Point-in-Time リカバリに必要だが、保護DB毎の確保スペースを超えているもの(reserved_space)
4. 期限切れしていないアーカイブバックアップ
• 断片化した領域をデフラグする機能も定期的に動作する
55

Autonomous Archive
56

テープへのバックアップのコピー
• Exadata X4 構成にテープへの接続が追加されている
• 16Gb Fibre Channel Cards
• Oracle Secure Backup がプリ・インストールされている
• Disk 上での保存期限を過ぎたバックアップはテープへと移動される
– 通常保護DBで実施するテープへのバックアップをRecovery Applianceにオフ
ロードすることができる
– テープへのコピー時には、通常のRMANのLevel 0, Level 1 バックアップ形式
となって格納される
– 任意のタイミングでも、テープへ移動させることができる
• Recovery Applianceを介さずに、リストア可能
57

Replication
58

One Way
Bi-
Directional
Hub &
Spoke
Remote Data CenterLocal Data Center
• 遠隔地の Recovery
Appliance へレプリケー
ションすることで、災害/
サイト障害へ対応
• ローカルもしくは遠隔地
の Recovery Appliance か
ら直接リストア可能
遠隔地へのレプリケーション：災害/サイト障害への対応
59

遠隔地へのレプリケーション：災害/サイト障害への対応
• Recovery Appliance 間の複製に使われるのは、保護DBから送られてきた
増分バックアップ
• 基本的な動作は下記の通り
1. Recovery Appliance は保護DBからバックアップを受け取り、処理する（前述通り）
2. UpstreamのRecovery Appliance が、バックアップをDownstreamに送る
3. Upstreamからのバックアップを受け取ると、Downstream の Recovery Appliance は
処理をし、自身のメタデータを更新する
4. DownstreamのRecovery Appliance はメタデータの更新をしたことを、Upstreamの
Recovery Appliance に通知する
• REDOは、Upstream のRecovery Appliance 上でアーカイブされたタイミング
で、アーカイブ単位で Downstream にコピーされる
60

本日の内容
1
2
3
4
5
まとめ
61

バックアップ・リカバリの統合的な管理
単一システムで、あらゆるバージョン/プラットフォームを統一した方式で管理
62
個別システム毎のバラバラな管理 Recovery Appliance での統一管理
Oracle 10g
Oracle 11g
Oracle 12c
EE/SE
Linux
Windows
Solaris
AIX
HP-UX
Windows
Linux
Solaris
AIX
HP-UX
EMC
IBM
HP
NetApp

利用できる機能とサポートされるバージョン
• RMAN 機能との併用について
– バックアップ取得の際、RMAN で圧縮/暗号化を行うと仮想フルバックアップの機能が利用できません
– 保護データベース側で本番データの圧縮や暗号化をご利用ください
63
最新情報は下記MOS Docを確認して下さい
Zero Data Loss Recovery Appliance Features Available per Oracle Database Release (Doc ID 1995866.1)
10.2.0.5 11.2.0.3 11.2.0.4 12.1.0.2 +
仮想フルバックアップ ○ ○ ○ ○
REDO転送 (Linux, Windows, Solaris x86, SPARC, AIX) ○ ○ ○
Backup Polling ○ ○
REDO転送の暗号化 ○ ○
Data Guard Broker 対応 (REDO from Primary)
* ロール変換後に新Primaryから転送再開
○ ○
Data Guard Broker 対応 (REDO from Standby)
* ロール変換後に新Standbyから転送再開
○
リアルタイムREDOカスケード ○

まとめ
64

Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャ

Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャ

More Related Content

What's hot

Viewers also liked

Similar to Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャ

More from オラクルエンジニア通信

Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャ