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によるデータベース保護のアーキテクチャ

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

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

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

Plus de オラクルエンジニア通信

Plus de オラクルエンジニア通信 (20)

Dernier

Dernier (10)

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