資料 - Oracle

#odddtky
for your Skill
Oracle DBA & Developer Days 2014
Zero Data Loss Recovery Appliance
によるデータベース保護の
アーキテクチャ
佐々木亨
シニアエンジニア
日本オラクル株式会社
製品戦略統括本部
データベースエンジニアリング本部
応用技術グループ
Copyright © 2014, Oracle and/or its affiliates. All rights reserved.
使える実践的なノウハウがここにある
• 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明する
ものです。また、情報提供を唯一の目的とするものであり、いかなる契約
にも組み込むことはできません。以下の事項は、マテリアルやコード、機
能を提供することをコミットメント（確約）するものではないため、購買決定
を行う際の判断材料になさらないで下さい。オラクル製品に関して記載さ
れている機能の開発、リリースおよび時期については、弊社の裁量により
決定されます。
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
3
本日覚えて帰って頂きたい内容
Recovery Appliance は
• RMAN 増分バックアップと Data Guard のREDO 転送
(適用は含まない) の機能を使って非常に多くのデータベース
(数千) を対象にしてバックアップを取得可能
• ブロック検査&圧縮済みのバックアップから、任意の時点に
高速(1度のリストア) に、リカバリすることが可能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
4
本日の内容
1
バックアップ・リカバリの現状と Recovery Appliance の概要
2
ハードウェア・ソフトウェア構成概要
3
アーキテクチャ
4
バックアップのライフサイクル
5
まとめ
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
5
従来のバックアップ装置はDB保護に適していない
定期的にファイルコピーを単にするだけでは、以下の課題が起こりえる
データ損失のリスク
毎日のバックアップ・ウィンドウ
最後のバックアップ以降の全デー
タを失うリスク
(DBをマウントできなくなった場合)
本番環境への大きな性能インパクト
フルバックアップはCPU, I/O, ネット
ワークを膨大に消費
例えば夜間バックアップだけでは
日中データを失うリスクがある
データベースを正常に復旧で
きないリスク
膨大なバックアップ・システ
ムの管理
単にファイルコピーするだけで、DB
を意識しない状態で保管されている
ため、リカバリできないリスクがある
拡張性に乏しいため、各DB毎に
バックアップ装置を個々に導入し、
管理/運用している
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
6
従来のデータベース・バックアップを
根本から革新
Oracle Zero Data Loss
Recovery Appliance
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
7
Recovery Appliance が実現するユニークなメリット
データ損失をなくす
リアルタイム・ログ転送により迅
速なトランザクション保護を実現
バックアップ業務の影響を最
小化（フルバックアップ不要）
本番環境はデータ変更のみを転送
し、バックアップ業務はオフロード
データベース・レベルの確実
な復旧
卓越した拡張性、多様な環
境に対応
エンドツーエンドの信頼性と可視性、
管理が可能。データベース・フォー
マット/ブロック・レベルでの保証
単一システムを柔軟に拡張し、
データセンター内の全てのデータ
ベースを容易に保護。各種OS/
バージョンに対応
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
8
バックアップ・リカバリの統合的な管理
単一システムで、あらゆるバージョン/プラットフォームを統一した方式で管理
個別システム毎のバラバラな管理
Recovery Appliance での統一管理
EMC
Solaris
AIX
IBM
Windows
HP-UX
Linux
HP
Oracle 10g
Oracle 11g
Oracle 12c
EE/SE
Linux
Windows
Solaris
AIX
HP-UX
NetApp
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
9
Recovery Appliance：全体概要
Recovery
Appliance
Delta Push:
• 増分バックアップを定期取得
• 変更データのみを送信
• REDO を送信(任意)
クラウドスケール
• 数千もの保護DB
• 各種OS/Version対応
• ペタバイトのデータも
保護
• 高価な Agentが不要
Delta Store:
• ブロックチェック、圧縮済みの形で
バックアップデータを格納
• 任意の時点へ高速なリストア
• Exadata のスケーラビリティと柔軟性
Autonomous
Archive:
• テープへのコピー
Replication :
• DRサイトへの複製
EM 12c
Tape Library
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
10
本日の内容
1
バックアップ・リカバリの現状と Recovery Appliance の概要
2
ハードウェア・ソフトウェア構成概要
3
アーキテクチャ
4
バックアップのライフサイクル
5
まとめ
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
11
ハードウェア構成(1/2)
Base Rack からスタートし、ストレージを1台ずつ拡張していく
• Base Rack (最小構成)
Recovery Appliance
Base Rack
– 2 x Compute Server
• 8 x 10Gb Ethernet / Rack
• 12 x 40Gb InfiniBand / Rack
• (オプション, テープ接続用) 4 x 16Gb Fiber Channel / Rack
ストレージ拡張
– 3 x Storage Server
• 12 x 4 TB (raw) 7,200RPM High Capacity Disk / Server
• Full Rack: 2 x Compute Server, 14 x Storage Server
http://www.oracle.com/us/products/engineered-systems/recovery-appliance-ds-2313692.pdf
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
12
ハードウェア構成(2/2)
• Step 1: Base Rack
– Exadata Quarter Rack 同一
– Compute 2台 + Cell 3台
• 実効容量：37TB
• Step 2: Storage Cell 追加
– Cell を1台づつ追加 (17TB)
– Full Rack: Cell 14台
• Step 3: Multi Rack
– 18 Rack まで接続可能
• 実効容量：224TB
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
• 実効容量：4PB
• InfiniBand 接続
• 複数世代の混在可
13
ソフトウェア構成(1/3)
Recovery Appliance 内のソフトウェア
• Exadata と同様 OEDA (Oracle Exadata Deployment Assistant) を用いて構築
• Grid Infrastructure が構成される
– 2つの ASM Disk Group (+CATALOG, +DELTA)
DB Instance
• RAC データベースが1つ作成される
process
process
process
– 各保護DBのリカバリ・カタログが格納される
(+CATALOG)
– バックアップのメタデータ格納(+CATALOG)
• 受信したバックアップは +DELTA に格納
バックアップ
セット
バックアップ格納場所
(+DELTA)
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
カタログDB＋メタデータ
(+CATALOG)
14
ソフトウェア構成(2/3)
保護DB上に必要な追加ソフトウェア
• 保護DBのORACLE_HOME 上に Oracle が提供する SBT ライブラリ (libra.so)
を追加インストールする
– バックアップ取得時にサーバープロセスが上記 SBTライブラリを用いて
バックアップをネットワーク越しに転送する
– バックアップを転送する特別なプロセスが
起動するわけではない
– Recovery Appliance 上にもライブラリは配置される
– OTNでツールを提供
• ライブラリの配置や、Recovery Appliance に接続する
ためのwallet の設定、通信ポートの設定などを行う
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
15
ソフトウェア構成(3/3)
Oracle 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 パッケージでも
実施可能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
16
リカバリ・カタログ・データベースの使用について
• 保護DB内の制御ファイルを使ったバックアップの管理は不可
– Recovery Appliance 側で、空き領域管理など通常のバックアップ管理以上の
ことを行うため、保護DB側の個々の制御ファイルでは管理できない
• バックアップ取得時には、カタログDBと保護DBに接続
– カタログDBに接続するユーザは、保護DB毎に分けることも可能
• Recovery Appliance の管理ユーザ
が RASYS ユーザ
– DBMS_RAパッケージ
– リカバリ・カタログ
Connect
as RA User
Connect
as SYSBACKUP
保護対象データベース
Virtual Private
Catalog
Virtual Private
Catalog
リカバリ・カタログ
RA User
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
RASYS
RA スキーマ
17
本日の内容
1
バックアップ・リカバリの現状と Recovery Appliance の概要
2
ハードウェア・ソフトウェア構成概要
3
アーキテクチャ
4
バックアップのライフサイクル
5
まとめ
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
18
Recovery Appliance：全体概要
Recovery
Appliance
Delta Push:
• 増分バックアップを定期取得
• 変更データのみを送信
• REDO を送信(任意)
クラウドスケール
• 数千もの保護DB
• 各種OS/Version対応
• ペタバイトのデータも
保護
• 高価な Agentが不要
Delta Store:
• ブロックチェック、圧縮済みの形で
バックアップデータを格納
• 任意の時点へ高速なリストア
• Exadata のスケーラビリティと柔軟性
Autonomous
Archive:
• テープへのコピー
Replication :
• DRサイトへの複製
EM 12c
Tape Library
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
19
Delta Push
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
20
Delta Push で覚えて頂きたいポイント
Recovery Appliance は
• RMAN 増分バックアップと Data Guard のREDO 転送
(適用は含まない) の機能を使って非常に多くのデータベース
(数千) を対象にしてバックアップを取得可能
• ブロック検査&圧縮済みのバックアップから、任意の時点に
高速(1度のリストア) に、リカバリすることが可能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
21
Delta Push の概要イメージ
• フル・バックアップを送るのは初回のみ
– Image Copy 形式ではなく、Backup Set 形式
• 以降は永久に増分バックアップ（=Delta）
を送る（フル・バックアップは二度と不要）
 Incremental Forever Backup Strategy
• 2つの増分バックアップの間の変更デー
タは、REDO転送によって埋める
Recovery
Appliance
9/1 AM 1:00 Backup転送
A A A A A
Lv0 Backup
A A A A A
REDO転送
A A A B B
9/2 AM 1:00 Backup転送
B A A B B
B A A B C
Lv1 Backup
B
B B
REDO転送
9/3 AM 1:00 Backup転送
B C A B C
Lv1 Backup
C
C
時間
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
22
Delta Push の概要
保護DBからRecovery Appliance へのデータの流れは大きく3種類
フル・バックアップ、増分バックアップをRecovery Appliance に送る方法
a. SBT ライブラリを使ったバックアップの転送
b. Polling によるバックアップの転送
REDO
Staging Area
(c)
※ 上記のいずれかを使う
Archived
REDO
(a)
REDO データを送る方法
c. Near-Zero Data Loss Recovery REDO転送
Backup Set
Backup (b)
Polling Location
(NAS)
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Storage Location
(+DELTA)
Recovery
Appliance
23
(a). Recovery Appliance へのバックアップ・データの送信
• サーバー・プロセスがSBT ライブラリを使い増分バックアップをRecovery
Appliance に直接送信(ローカルにバックアップ・ファイルの置き場は不要)
• Recovery Appliance との通信には、HTTP が使われる
• 保護DB側のバックアップ・コマンドを下記のようにする (後述の通り、EMを
使えばコマンドは自動生成される)
ツールを使ってコピーした
SBTライブラリを使用
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;
}
Recovery Applianceに接続するた
めの資格証明用Wallet
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
24
保護DB側での設定
バックアップの設定(1/2)
• Recovery Appliance のセットアップ、設定とは別に、保護DB側でバックアッ
プの設定（バックアップ先、スケジュール）が必要
– EM画面：保護DB > 可用性 > バックアップとリカバリ > バックアップ設定
各種選択後、「適用」ボタンを押すと、
必要な設定が行われる
バックアップ転送先Recovery Applianceの
選択とカタログDB用ユーザ名の選択
• 初期化
• データベース・ホストの構成
• Recovery Appliance リカバリ・カタログ
使用の設定
• メディア管理設定
• ログ・アーカイブ保存先およびREDOト
ランスポート・ユーザの構成
• パラメータの評価
• データベースの再起動
• 構成後処理
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
25
保護DB側での設定
バックアップの設定(2/2)
• バックアップ先の指定後、バックアップのスケジュールを設定
• EM Recovery Appliance Plug-in をインストール済みの場合、下記設定画面
で、Recovery Appliance へのバックアップに適した設定が可能
– 保護DBのHome > 可用性 > バックアップとリカバリ > バックアップのスケジュール
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
26
(b). Polling によるRecovery Appliance へのバックアップ転送
• 保護DB側で単独でバックアップを取り、NASに配置している場合
• 指定したディレクトリ・パス(Backup Polling Location)を、Recovery Appliance
が定期的にPolling し、新しいバックアップがあればコピーする
• Backup Polling Location を
Recovery Appliance からマウントして
アクセス可能である必要がある
保護DB群
• Recovery Appliance 側へのバックアップの
コピーが完了後、NAS上のオリジナル
バックアップを消す設定は可能
バックアップ
Polling
NAS
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
27
Recovery Appliance側
での設定
Polling の設定(1/1)
• Recovery Appliance で設定する保護ポリシーの設定画面で指定する
– EM 画面： Recovery Appliance > Protection Policies > Create
– Recovery Appliance から Polling するロケーション
– Polling する頻度
– Polling して Recovery Appliance にバックアップをコピーした後に、Polling ロケーショ
ンにあるオリジナルのバックアップを消すかどうかのチェック
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
28
(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 側に転送する
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
29
(c). Near-Zero Data Loss Recovery REDO転送
保護DB
DB Instance
ログ
バッファ
データファイル
NSA/
TTnn
(1) REDO転送
DB Instance
Recovery
Appliance
RFS
LAD1
location=USE_DB_RECOVERY_FILE_
DEST
valid_for=(ONLINE_LOGFILE,ALL_RO
LES) db_unique_name=dblra
alternate=LOG_ARCHIVE_DEST_2
(2) アーカイブ
Backup
アーカイブ
REDOログファイル
バックアップ
セット
Storage Location
(+DELTA)
REDO Staging
Area (+DELTA)
(3) Storage Locationにコピーし、
リカバリ・カタログに登録
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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)
30
(c). Near-Zero Data Loss Recovery REDO転送
• REDO転送の仕組みはData Guard と同じ
– 転送プロセスがログ・バッファからREDOを読み出し、Recovery Appliance に送る
– 現時点では非同期転送のみ可能
• REDO受信後の動作
– Recovery Appliance 側でREDOを受け取ると、一旦、REDO Staging Area に格納
– このREDO Staging Area 中のアーカイブREDOログファイルを、圧縮してStorage Location
に格納、リカバリカタログに登録する（一時ファイルは削除される）
– ステージングエリアは保護DBで共通
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
31
保護DB側での設定
Near-Zero Data Loss Recovery REDO転送設定(1/1)
• バックアップ設定画面でチェックを入れると自動設定される
– 保護DBのHome > “可用性” > “バックアップとリカバリ” > “バックアップ設定”
• 設定作業を続けると下記が自動設定される
– LOG_ARCHIVE_DEST_n パラメータなど通常のData Guard と同等の設定(保護DB側)
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
32
Delta Push まとめ
保護DBからRecovery Appliance へのデータの流れは大きく3種類
フル・バックアップ、増分バックアップをRecovery Appliance に送る方法
a. SBT ライブラリを使ったバックアップの転送
b. Polling によるバックアップの転送
REDO
Staging Area
(c)
※ 上記のいずれかを使う
Archived
REDO
(a)
REDO データを送る方法
c. Near-Zero Data Loss Recovery REDO転送
Backup Set
Backup (b)
Polling Location
(NAS)
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Storage Location
(+DELTA)
Recovery
Appliance
33
Delta Store
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
34
Delta Store で覚えて頂きたいポイント
Recovery Appliance は
• RMAN 増分バックアップと Data Guard のREDO 転送
(適用は含まない) の機能を使って非常に多くのデータベース
(数千) を対象にしてバックアップを取得可能
• ブロック検査&圧縮済みのバックアップから、任意の時点に
高速(1度のリストア) に、リカバリすることが可能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
35
Delta Store の概要イメージ
• 送られてきたバックアップ・セットは、小さな
単位（便宜上”ブロック”と呼ぶ）に分解する
Recovery
Appliance
#1 #2 #3 #4 #5
A A A A A
カタログDB内の
メタデータ
A A A A A
Virtual Full #1 =
{#1,#2,#3,#4,#5}
• ブロックを検査、圧縮を行い格納
• 圧縮されたブロック毎に管理される
• 管理のためのメタデータは、カタログ・データ
ベース上に保持している
• メタデータを基に個々のブロックを寄せ集め
て、フル・バックアップ相当のもの（仮想フル・
バックアップ）を作り出せる
#6
#7 #8
B
B B
B A A B B
Virtual Full #2 =
{#6,#2,#3,#7,#8}
#9
#10
C
C
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
B C A B C
Virtual Full #3 =
{#6,#9,#3,#7,#10}
36
Delta Store の特徴
• 仮想フル・バックアップの仕組みにより、任意の時点に高速にリカバリ可能
– 1度の（仮想フル・バックアップ）リストア＋リカバリで復旧可能
• REDO はリカバリに使われるだけなので特殊な加工はされない
• 下記の処理を本番DBサーバーから Recovery Appliance へオフロード可能
– 取得済みバックアップのブロック破損有無の検査
– RMANバックアップの圧縮
• Exadata のスケーラビリティと柔軟性が組み込まれている
– Exadata + Storage Expansion (HCディスク)
– 多くの保護DBのバックアップに対応可能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
37
用語の整理
• Delta Pool
– Recovery Appliance に送られてきたバックアップを加工して格納する場所
– 仮想フルバックアップを構成するデータファイルブロックの集合
– 各保護DBのデータファイルは、対応するDelta Pool を持つ
– Recovery Appliance セットアップ時に多数のDelta Pool が作成される
• Delta Store
Storage Location = ASM Disk Group
– Delta Pool の集合
Delta Store
• Storage Location
– ASM Disk Group と1対1対応、サイズ指定する
– + DELTA という Disk Group が指定される
Delta Pool
Delta Pool
Delta Pool
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Delta Pool
Delta Pool
Delta Pool
38
仮想フル・バックアップ(Virtual Full Backup)
• 仮想フル・バックアップ作成の流れ
– Recovery Appliance で受信したバックアップを、小さな単位（便宜上”ブロック”と呼ぶ）
に分解し、検査・圧縮して、Delta Poolに格納する
– 索引付けをして、バックアップ取得時点における、仮想的なフル・バックアップを構築す
る (仮想フル・バックアップ)
• 索引はRecovery Appliance 内にあるカタログDBにメタデータという形で格納される
• 仮想フル・バックアップは VB$_* という形でリカバリ・カタログから見える
• 管理者からは、通常のフルバックアップと同様に扱える
– 仮想フル・バックアップ完成時点で、Recovery Appliance で受信した、分解前のバック
アップ・セットは削除される
• 分解して、Delta Pool 内に格納されている、仮想フル・バックアップを構成しているブロックは、保護ポ
リシーに則って削除される
• レプリケーション設定時は、削除前にバックアップを複製先に転送される
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
39
仮想フル・バックアップの制限
• 制限事項
– 10gR2(10.2.0.4)以降のデータベースが対象
– バックアップ・セット方式のバックアップが前提
– RMANで圧縮、暗号化したバックアップからは仮想フル・バックアップは作成できない
• バックアップは可能だが、オリジナルの暗号化されたフォーマットのまま格納される
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
40
仮想フル・バックアップの推奨事項
• 増分バックアップは、”累積増分”で取得される(デフォルト設定)
差分増分バックアップ
累積増分バックアップ
前回レベル1以降に変更された
全ブロックをバックアップ
前回レベル0以降に変更された
全ブロックをバックアップ
• 累積増分だと、レベル0を一度しか取らない ”Incremental Forever Backup”
戦略だと、バックアップ量が次第に大きくなるのでは？  間違い
– 累積増分も差分増分も実質的に動作は変わらない
– 直近の累積増分から作成された仮想フル・バックアップが直近のレベル0扱いとなる
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
41
仮想フル・バックアップ（イメージ）
9/1 AM 1:00
A A A A A
-- POINT① -差分増分 Backup でなく、
累積増分 Backup が推奨
累積増分
Backup転送
Lv0 Backup
仮想フル
A A A A A
分解 &
圧縮
白抜きで表して
いるブロックは実
体は存在しない
#1 #2 #3 #4 #5
A A A A A
A A A A A
Virtual Full #1
REDO転送
Virtual Full #1 =
{#1,#2,#3,#4,#5}
A A A B B
9/2 AM 1:00
B A A B B
B A A B C
9/3 AM 1:00
B C A B C
増分Backup転送
Lv1 Backup
B
B B
分解 &
圧縮
#6
#7 #8
B
B B
Virtual Full #2
REDO転送
増分Backup転送
Lv1 Backup
C
C
分解 &
圧縮
B A A B B
#9
#10
C
C
B C A B C
Virtual Full #3
時間
保護DB
Recovery
Appliance
-- POINT② -Full #1 からの累積ではなく、
Virtual Full #2 からの累積
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Virtual Full #2 =
{#6,#2,#3,#7,#8}
Virtual Full #3 =
{#6,#9,#3,#7,#10}
-- POINT③ –
点線部分に相当する
メタデータを保持している
42
仮想フル・バックアップ
“VB$_” で始まる名前のものが仮想フル・バックアップ
この仮想フル・バックアップは通常のフル・バックアップ
と全く同じように扱うことができる
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
43
仮想フル・バックアップを用いたリストア・リカバリ
（例）9/2 PM 05:00 の時点にPoint in Time リカバリしたい場合
9/1 AM 1:00
A A A A A
#1 #2 #3 #4 #5
A A A A A
アーカイブREDO
Recovery
Appliance
9/2 PM 5:00 の時点に
Point in Time リカバリしたい
A A A A A
Virtual Full #1
A A A B B
9/2 AM 1:00
B A A B B
#6
#7 #8
B
B B
B A A B B
Virtual Full #2
B A A B C
9/3 AM 1:00
B C A B C
Virtual Full #2 =
{#6,#2,#3,#7,#8}
1.直近の仮想フル・バックアップ
(=Virtual Full #2) をリストア
 Block#6,2,3,7,8 を寄せ集めて
リストアする
アーカイブREDO
#9
#10
C
C
2.それ以降、9/2 05:00 までのREDO
(アーカイブREDO)を使ってリカバリ
B C A B C
Virtual Full #3
B A A B B
＋

B A A B C
時間
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
44
仮想フル・バックアップを用いたリストア・リカバリ
• 任意の時点へのPoint-in-Time リカバリにおいて、「直前の仮想フル・バッ
クアップのリストア＋リカバリ」で済む
– 「フル・バックアップのリストア＋ Level 1 増分バックアップのリストア + リカバリ」
とはならず、リストアが一度で済む
• 「増分更新バックアップ」でもリストアは一度で済むが、「任意の時点」
へのPoint-in-Time リカバリはできない
– オリジナルのフル・バックアップに増分バックアップを適用済みなので
利用可能なユースケース
ある時点の本番データベースのバックアップを使って、ステージング環境
にテスト用のデータベースを作成する
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
45
本日の内容
1
バックアップ・リカバリの現状と Recovery Appliance の概要
2
ハードウェア・ソフトウェア構成概要
3
アーキテクチャ
4
バックアップのライフサイクル
5
まとめ
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
46
保護ポリシーの管理
• バックアップは保持期間などを設定して、取得から削除までのライフサイ
クルを適切に管理する必要がある
• 可用性要件毎にポリシー(リカバリ・ウィンドウ、ディスク保持期間など)を
定義し、データベース毎にポリシーを適用する
ポリシーの例
Gold
ミッション・クリティカル
ディスク：30日、テープ：90日、Replication 有
Silver
ビジネス・クリティカル
ディスク：10日、テープ：30日、Replication 無
Bronze
テスト、開発
ディスク：6時間、テープ：なし、Replication 無
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
47
Recovery Appliance側
での設定
保護ポリシーの定義
Storage Location の作成
• Storage Location ：受信したバックアップを格納する ASM Disk Group
– 下記の項目を指定する
Storage Location = ASM Disk Group
• Storage Location 名
• 使用する ASM Disk Group
Delta Store
– 現行 Recovery Appliance で指定可能なDisk Group は1つ
(= +DELTA)
• 使用するサイズを指定
Delta Pool
Delta Pool
Delta Pool
Delta Pool
Delta Pool
Delta Pool
設定後のEM画面
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
48
Recovery Appliance側
での設定
保護ポリシーの定義
保護ポリシーの作成(1/2)
• 下記の項目を指定する
– 保護ポリシー名
– リカバリ・ウインドウ目標(Disk&Tape)：どの時点まで、Point-in-time リカバリ可能とするか
– Storage Location 名：保護ポリシーを割り当てたDBのバックアップが格納される場所
– Copy to Tape / レプリケーション
• テープへの移動、他のRecovery Appliance への複製を行うか
設定後のEM画面
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
49
Recovery Appliance側
での設定
保護ポリシーの定義
保護ポリシーの作成(2/2)
• recovery_window_goal / recovery_window_sbt
– 何日前まで Point-in-Time リカバリを可能にするか期間を指定
– Disk 上のバックアップ、Tape 上のバックアップそれぞれに対して指定
• max_retention_window
– バックアップを保持する期間を指定
• guaranteed_copy
– バックアップがディスク上から削除される前に、テープやReplication先に移動するか
• No ：バックアップ時に領域がなければ古いものは消されるが、バックアップが失敗しない
• Yes ：バックアップ時に領域がなければ、バックアップを失敗させる。保持目標を満たすことを優先
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
50
Recovery Appliance側
での設定
保護ポリシーの定義
保護DBに保護ポリシーを割り当てる
• 保護DBをRecovery Appliance上のリカバリ・カタログに登録する
– DB名、対応させる保護ポリシー、利用する領域サイズを指定する
– Storage Locationは、複数の保護DBで共有されるので、各保護DB毎に、使用するサイ
ズを管理者自身で計算して指定する必要がある
• サイジングの目安は下記
SIZE(Level0) + SIZE(Level1) * recovery_window
+ SIZE(archivelog/1day) * recovery_window
これに圧縮率、データ量増加を加味
保護DB毎に、保護ポリシーを
割り当てている
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
51
Delta Pool の空き領域管理
• バックアップの削除対象有無の確認を行うタイミング
– 定期的なタイミング(バックアップをDisk からTapeに移動するジョブ)
– バックアップ取得時に領域が不足しているタイミング
• 管理方法
– 下記の優先順で削除対象とする
1. 期限切れしているアーカイブバックアップ
2. バックアップの存在期間＞バックアップ保持期間かつ Point-in-Time リカバリに不要なものを削
除対象とする
3. Point-in-Time リカバリに必要だが、保護DB毎の確保スペースを超えているもの(reserved_space)
4. 期限切れしていないアーカイブバックアップ
• 断片化した領域をデフラグする機能も定期的に動作する
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
52
Autonomous Archive
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
53
テープへのバックアップのコピー
• Exadata X4 構成にテープへの接続が追加されている
• 16Gb Fibre Channel Cards
• 通常保護DBで実施するテープへのバックアップをZDLRAにオフロー
ドすることができる
• Oracle Secure Backup がプリ・インストールされている
• Disk 上での保存期限を過ぎたバックアップはテープへと移動される
• テープへのコピー時には、Disk 上の仮想フル・バックアップから取
得した通常のRMANのLevel 0, Level 1 バックアップ
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
54
Replication
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
55
遠隔地へのレプリケーション：災害/サイト障害への対応
• 遠隔地のRecovery Appliance にバックアップを複製することで災害時、サ
イト障害時にバックアップ・データを保護できる
• Recovery Appliance 間の複製に使われるのは、保護DBから送られてきた
増分バックアップ
• 基本的な動作は下記の通り
1. Recovery Appliance は保護DBからバックアップを受け取り、処理する（前述通り）
2. UpstreamのRecovery Appliance が、バックアップをDownstreamに送る
3. Upstreamからのバックアップを受け取ると、Downstream の Recovery Appliance は
処理をし、自身のメタデータを更新する
4. DownstreamのRecovery Appliance はメタデータの更新をしたことを、Upstreamの
Recovery Appliance に通知する
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
56
遠隔地へのレプリケーション：災害/サイト障害への対応
Local Data Center
Remote Data Center
One Way
BiDirectional
Hub &
Spoke
• 遠隔地の Recovery
Appliance へレプリケー
ションすることで、災害/
サイト障害へ対応
• ローカルもしくは遠隔地
の Recovery Appliance か
ら直接リストア可能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
57
本日の内容
1
バックアップ・リカバリの現状と Recovery Appliance の概要
2
ハードウェア・ソフトウェア構成概要
3
アーキテクチャ
4
バックアップのライフサイクル
5
まとめ
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
58
バックアップ・リカバリの統合的な管理
単一システムで、あらゆるバージョン/プラットフォームを統一した方式で管理
個別システム毎のバラバラな管理
Recovery Appliance での統一管理
EMC
Solaris
AIX
IBM
Windows
HP-UX
Linux
HP
Oracle 10g
Oracle 11g
Oracle 12c
EE/SE
Linux
Windows
Solaris
AIX
HP-UX
NetApp
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
59
Recovery Appliance で利用できる機能と対応バージョン
DBバージョン
利用できる機能
10.2.0.4
• Recovery Appliance へのバックアップ
• 仮想フルバックアップ
11.1.0.7 以降
• REDO転送 (Linux, Windows, Solaris x86)
11.2.0.4 以降
• REDO転送 (SPARC Solaris, IBM Power, HP Itanium)
• REDO転送 (Standard Edition)
• REDO転送の暗号化
12.1.0.2 または
12.1.0.1＋パッチ
• リアルタイム・カスケード
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
60
まとめ
Recovery Appliance は
• RMAN 増分バックアップと Data Guard のREDO 転送
(適用は含まない) の機能を使って非常に多くのデータベース
(数千) を対象にしてバックアップを取得可能
• ブロック検査&圧縮済みのバックアップから、任意の時点に
高速(1度のリストア) に、リカバリすることが可能
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
61
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
62
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Download Report