Zero Data Loss Recovery Appliance...Incremental Forever Backup Strategy •2つの増分バックアップの間の変更データは、REDO転送によって埋める 22 A A A A

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

佐々木亨シニアエンジニア

日本オラクル株式会社製品戦略統括本部データベースエンジニアリング本部応用技術グループ

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.

Oracle DBA & Developer Days 2014for your Skill

使える実践的なノウハウがここにある

#odddtky

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

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

3

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


本日覚えて帰って頂きたい内容

Recovery Applianceは

• RMAN 増分バックアップと Data Guard のREDO転送

(適用は含まない) の機能を使って非常に多くのデータベース

(数千) を対象にしてバックアップを取得可能

•ブロック検査&圧縮済みのバックアップから、任意の時点に

高速(1度のリストア)に、リカバリすることが可能

4


本日の内容

1

2

3

4

5

バックアップ・リカバリの現状と Recovery Appliance の概要

ハードウェア・ソフトウェア構成概要

アーキテクチャ

バックアップのライフサイクル

まとめ

5


従来のバックアップ装置はDB保護に適していない定期的にファイルコピーを単にするだけでは、以下の課題が起こりえる

6

毎日のバックアップ・ウィンドウ

本番環境への大きな性能インパクト

フルバックアップはCPU, I/O, ネットワークを膨大に消費

データ損失のリスク

最後のバックアップ以降の全データを失うリスク(DBをマウントできなくなった場合)

例えば夜間バックアップだけでは日中データを失うリスクがある

膨大なバックアップ・システムの管理

拡張性に乏しいため、各DB毎にバックアップ装置を個々に導入し、管理/運用している

データベースを正常に復旧できないリスク

単にファイルコピーするだけで、DBを意識しない状態で保管されているため、リカバリできないリスクがある


Oracle Zero Data Loss Recovery Appliance

7

従来のデータベース・バックアップを根本から革新


Recovery Appliance が実現するユニークなメリット

8

バックアップ業務の影響を最小化（フルバックアップ不要）

本番環境はデータ変更のみを転送し、バックアップ業務はオフロード

データ損失をなくす

リアルタイム・ログ転送により迅速なトランザクション保護を実現

卓越した拡張性、多様な環境に対応

単一システムを柔軟に拡張し、データセンター内の全てのデータベースを容易に保護。各種OS/バージョンに対応

データベース・レベルの確実な復旧

エンドツーエンドの信頼性と可視性、管理が可能。データベース・フォーマット/ブロック・レベルでの保証


バックアップ・リカバリの統合的な管理単一システムで、あらゆるバージョン/プラットフォームを統一した方式で管理

9

個別システム毎のバラバラな管理 Recovery Appliance での統一管理

Oracle 10gOracle 11gOracle 12c

EE/SE

LinuxWindows

SolarisAIX

HP-UXWindows

Linux

Solaris

AIX

HP-UX

EMC

IBM

HP

NetApp


Recovery Appliance：全体概要

10

クラウドスケール• 数千もの保護DB• 各種OS/Version対応

• ペタバイトのデータも保護

• 高価な Agentが不要

RecoveryAppliance

EM 12c

Delta Push:• 増分バックアップを定期取得• 変更データのみを送信• REDOを送信(任意)

Delta Store:• ブロックチェック、圧縮済みの形でバックアップデータを格納

• 任意の時点へ高速なリストア• Exadataのスケーラビリティと柔軟性

Tape Library

Autonomous Archive:• テープへのコピー

Replication :• DRサイトへの複製


本日の内容

1

2

3

4

5





まとめ

11


ハードウェア構成(1/2)Base Rack からスタートし、ストレージを1台ずつ拡張していく

• 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

12

ストレージ拡張

Recovery Appliance Base Rack

http://www.oracle.com/us/products/engineered-systems/recovery-appliance-ds-2313692.pdf

http://www.oracle.com/us/products/engineered-systems/recovery-appliance-ds-2313692.pdf


ハードウェア構成(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台

• 実効容量：224TB

• Step 3: Multi Rack

– 18 Rack まで接続可能

• 実効容量：4PB

• InfiniBand 接続

• 複数世代の混在可

13


ソフトウェア構成(1/3)Recovery Appliance 内のソフトウェア

• Exadataと同様 OEDA (Oracle Exadata Deployment Assistant)を用いて構築

• Grid Infrastructure が構成される– 2つの ASM Disk Group (+CATALOG, +DELTA)

• RAC データベースが1つ作成される–各保護DBのリカバリ・カタログが格納される

(+CATALOG)

–バックアップのメタデータ格納(+CATALOG)

•受信したバックアップは +DELTA に格納

14

DB Instance

processprocess

process

カタログDB＋メタデータ(+CATALOG)

バックアップ格納場所(+DELTA)

バックアップセット


ソフトウェア構成(2/3)保護DB上に必要な追加ソフトウェア

•保護DBのORACLE_HOME上に Oracle が提供する SBT ライブラリ (libra.so) を追加インストールする–バックアップ取得時にサーバープロセスが上記 SBTライブラリを用いてバックアップをネットワーク越しに転送する

–バックアップを転送する特別なプロセスが起動するわけではない

– Recovery Appliance上にもライブラリは配置される

–OTNでツールを提供• ライブラリの配置や、Recovery Appliance に接続するためのwallet の設定、通信ポートの設定などを行う

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 パッケージでも実施可能

16


リカバリ・カタログ・データベースの使用について

•保護DB内の制御ファイルを使ったバックアップの管理は不可– Recovery Appliance 側で、空き領域管理など通常のバックアップ管理以上のことを行うため、保護DB側の個々の制御ファイルでは管理できない

•バックアップ取得時には、カタログDBと保護DBに接続–カタログDBに接続するユーザは、保護DB毎に分けることも可能

• Recovery Applianceの管理ユーザが RASYSユーザ– DBMS_RAパッケージ

–リカバリ・カタログ

17

RAスキーマ

リカバリ・カタログ

Virtual Private Catalog

Virtual Private Catalog

RASYS

保護対象データベース

Connectas SYSBACKUP

Connectas RA User

RA User


本日の内容

1

2

3

4

5





まとめ

18


Recovery Appliance：全体概要

RecoveryAppliance

EM 12c

Delta Push:• 増分バックアップを定期取得• 変更データのみを送信• REDOを送信(任意)

Delta Store:• ブロックチェック、圧縮済みの形でバックアップデータを格納

• 任意の時点へ高速なリストア• Exadataのスケーラビリティと柔軟性

Tape Library

Autonomous Archive:• テープへのコピー

Replication :• DRサイトへの複製

クラウドスケール• 数千もの保護DB• 各種OS/Version対応

• ペタバイトのデータも保護

• 高価な Agentが不要

19


Delta Push

20


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







21


Delta Push の概要イメージ

• フル・バックアップを送るのは初回のみ– Image Copy 形式ではなく、Backup Set 形式

•以降は永久に増分バックアップ（=Delta）を送る（フル・バックアップは二度と不要）

Incremental Forever Backup Strategy

• 2つの増分バックアップの間の変更データは、REDO転送によって埋める

22

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転送

RecoveryAppliance


Delta Push の概要保護DBからRecovery Appliance へのデータの流れは大きく3種類

フル・バックアップ、増分バックアップをRecovery Appliance に送る方法

a. SBT ライブラリを使ったバックアップの転送

b. Polling によるバックアップの転送

※上記のいずれかを使う

REDOデータを送る方法

c. Near-Zero Data Loss Recovery REDO転送

23

RecoveryAppliance

REDOStaging Area

Archived REDO

Storage Location(+DELTA)

BackupPolling Location(NAS)

(a)

(b)

(c)

Backup Set


(a). Recovery Appliance へのバックアップ・データの送信

•サーバー・プロセスがSBTライブラリを使い増分バックアップをRecovery Appliance に直接送信(ローカルにバックアップ・ファイルの置き場は不要)

• Recovery Appliance との通信には、HTTP が使われる

•保護DB側のバックアップ・コマンドを下記のようにする (後述の通り、EMを使えばコマンドは自動生成される)

24

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


バックアップの設定(1/2)

• Recovery Appliance のセットアップ、設定とは別に、保護DB側でバックアップの設定（バックアップ先、スケジュール）が必要– EM画面：保護DB >可用性 > バックアップとリカバリ > バックアップ設定

25

バックアップ転送先Recovery Applianceの選択とカタログDB用ユーザ名の選択

各種選択後、「適用」ボタンを押すと、必要な設定が行われる

• 初期化• データベース・ホストの構成• Recovery Appliance リカバリ・カタログ使用の設定

• メディア管理設定• ログ・アーカイブ保存先およびREDOトランスポート・ユーザの構成

• パラメータの評価• データベースの再起動• 構成後処理

保護DB側での設定


バックアップの設定(2/2)

•バックアップ先の指定後、バックアップのスケジュールを設定

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

26



(b). Polling によるRecovery Appliance へのバックアップ転送

•保護DB側で単独でバックアップを取り、NASに配置している場合

•指定したディレクトリ・パス(Backup Polling Location)を、Recovery Applianceが定期的にPolling し、新しいバックアップがあればコピーする

• Backup Polling LocationをRecovery Appliance からマウントしてアクセス可能である必要がある

• Recovery Appliance 側へのバックアップのコピーが完了後、NAS上のオリジナルバックアップを消す設定は可能

27

NAS

保護DB群

バックアップPolling


Polling の設定(1/1)

• Recovery Appliance で設定する保護ポリシーの設定画面で指定する– EM 画面： Recovery Appliance > Protection Policies > Create

– Recovery Appliance から Polling するロケーション

– Polling する頻度

– Polling して Recovery Appliance にバックアップをコピーした後に、Polling ロケーションにあるオリジナルのバックアップを消すかどうかのチェック

28

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 側に転送する

29


DB Instance


30

RecoveryAppliance

Backup

(1) REDO転送

データファイル

ログバッファ

NSA/TTnn

DB Instance

RFS

REDO StagingArea (+DELTA)

アーカイブREDOログファイル


保護DB

LAD1location=USE_DB_RECOVERY_FILE_DEST valid_for=(ONLINE_LOGFILE,ALL_ROLES) db_unique_name=dblraalternate=LOG_ARCHIVE_DEST_2

LAD2location=+CATALOG valid_for=(ONLINE_LOGFILE,ALL_ROLES) db_unique_name=dblraalternate=LOG_ARCHIVE_DEST_1

LAD3location=+DELTA valid_for=(STANDBY_LOGFILE,ALL_ROLES)

バックアップセット

(2) アーカイブ

(3) Storage Locationにコピーし、リカバリ・カタログに登録



• REDO転送の仕組みはData Guard と同じ–転送プロセスがログ・バッファからREDOを読み出し、Recovery Appliance に送る

–現時点では非同期転送のみ可能

• REDO受信後の動作– Recovery Appliance 側でREDOを受け取ると、一旦、REDO Staging Area に格納

–このREDO Staging Area 中のアーカイブREDOログファイルを、圧縮してStorage Location に格納、リカバリカタログに登録する（一時ファイルは削除される）

–ステージングエリアは保護DBで共通

31


Near-Zero Data Loss Recovery REDO転送設定(1/1)

•バックアップ設定画面でチェックを入れると自動設定される–保護DBのHome > “可用性” > “バックアップとリカバリ” > “バックアップ設定”

•設定作業を続けると下記が自動設定される– LOG_ARCHIVE_DEST_nパラメータなど通常のData Guard と同等の設定(保護DB側)

32



Delta Pushまとめ保護DBからRecovery Appliance へのデータの流れは大きく3種類

フル・バックアップ、増分バックアップをRecovery Appliance に送る方法

a. SBT ライブラリを使ったバックアップの転送

b. Polling によるバックアップの転送

※上記のいずれかを使う

REDOデータを送る方法

c. Near-Zero Data Loss Recovery REDO転送

33

RecoveryAppliance

REDOStaging Area

Archived REDO


BackupPolling Location(NAS)

(a)

(b)

(c)

Backup Set


Delta Store

34


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







35


Delta Store の概要イメージ

•送られてきたバックアップ・セットは、小さな単位（便宜上”ブロック”と呼ぶ）に分解する

• ブロックを検査、圧縮を行い格納

•圧縮されたブロック毎に管理される

•管理のためのメタデータは、カタログ・データベース上に保持している

• メタデータを基に個々のブロックを寄せ集めて、フル・バックアップ相当のもの（仮想フル・バックアップ）を作り出せる

36

A A A A A

B B B

C C

RecoveryAppliance

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はリカバリに使われるだけなので特殊な加工はされない

•下記の処理を本番DBサーバーから Recovery Appliance へオフロード可能–取得済みバックアップのブロック破損有無の検査

– RMANバックアップの圧縮

• Exadataのスケーラビリティと柔軟性が組み込まれている– Exadata + Storage Expansion (HCディスク)

–多くの保護DBのバックアップに対応可能

37


用語の整理

• Delta Pool

– Recovery Appliance に送られてきたバックアップを加工して格納する場所

–仮想フルバックアップを構成するデータファイルブロックの集合

–各保護DBのデータファイルは、対応するDelta Pool を持つ

– Recovery Appliance セットアップ時に多数のDelta Pool が作成される

• Delta Store

– Delta Pool の集合

• Storage Location

– ASM Disk Group と1対1対応、サイズ指定する

– + DELTA という Disk Group が指定される

38

Storage Location = ASM Disk Group

Delta Store

Delta PoolDelta Pool

Delta Pool


Delta Pool


仮想フル・バックアップ(Virtual Full Backup)

•仮想フル・バックアップ作成の流れ– Recovery Appliance で受信したバックアップを、小さな単位（便宜上”ブロック”と呼ぶ）に分解し、検査・圧縮して、Delta Poolに格納する

–索引付けをして、バックアップ取得時点における、仮想的なフル・バックアップを構築する (仮想フル・バックアップ)• 索引はRecovery Appliance 内にあるカタログDBにメタデータという形で格納される

• 仮想フル・バックアップは VB$_* という形でリカバリ・カタログから見える

• 管理者からは、通常のフルバックアップと同様に扱える

–仮想フル・バックアップ完成時点で、Recovery Appliance で受信した、分解前のバックアップ・セットは削除される• 分解して、Delta Pool 内に格納されている、仮想フル・バックアップを構成しているブロックは、保護ポリシーに則って削除される

• レプリケーション設定時は、削除前にバックアップを複製先に転送される

39


仮想フル・バックアップの制限

•制限事項– 10gR2(10.2.0.4)以降のデータベースが対象

–バックアップ・セット方式のバックアップが前提

– RMANで圧縮、暗号化したバックアップからは仮想フル・バックアップは作成できない• バックアップは可能だが、オリジナルの暗号化されたフォーマットのまま格納される

40


仮想フル・バックアップの推奨事項

•増分バックアップは、”累積増分”で取得される(デフォルト設定)

41

前回レベル1以降に変更された全ブロックをバックアップ

前回レベル0以降に変更された全ブロックをバックアップ

•累積増分だと、レベル0を一度しか取らない ”Incremental Forever Backup”戦略だと、バックアップ量が次第に大きくなるのでは？間違い–累積増分も差分増分も実質的に動作は変わらない

–直近の累積増分から作成された仮想フル・バックアップが直近のレベル0扱いとなる

差分増分バックアップ累積増分バックアップ


仮想フル

仮想フル・バックアップ（イメージ）

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

42

#1 #2 #3 #4 #5

#6 #7 #8

#9 #10

RecoveryAppliance保護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③ –点線部分に相当するメタデータを保持している


仮想フル・バックアップ

43

“VB$_” で始まる名前のものが仮想フル・バックアップ

この仮想フル・バックアップは通常のフル・バックアップと全く同じように扱うことができる


仮想フル・バックアップを用いたリストア・リカバリ（例）9/2 PM 05:00 の時点にPoint in Time リカバリしたい場合

44

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

RecoveryAppliance

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 リカバリはできない–オリジナルのフル・バックアップに増分バックアップを適用済みなので

利用可能なユースケース

ある時点の本番データベースのバックアップを使って、ステージング環境にテスト用のデータベースを作成する

45


本日の内容

1

2

3

4

5





まとめ

46


Gold

Silver

Bronze

保護ポリシーの管理

•バックアップは保持期間などを設定して、取得から削除までのライフサイクルを適切に管理する必要がある

•可用性要件毎にポリシー(リカバリ・ウィンドウ、ディスク保持期間など)を定義し、データベース毎にポリシーを適用する

47

ミッション・クリティカルディスク：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)

• 使用するサイズを指定

48


Storage Location = ASM Disk Group

Delta Store


Delta Pool


Delta Pool

設定後のEM画面


保護ポリシーの定義保護ポリシーの作成(1/2)

•下記の項目を指定する–保護ポリシー名

–リカバリ・ウインドウ目標(Disk&Tape)：どの時点まで、Point-in-time リカバリ可能とするか

– Storage Location 名：保護ポリシーを割り当てたDBのバックアップが格納される場所

– Copy to Tape / レプリケーション• テープへの移動、他のRecovery Appliance への複製を行うか

49


設定後のEM画面


保護ポリシーの定義保護ポリシーの作成(2/2)

• recovery_window_goal / recovery_window_sbt

–何日前まで Point-in-Time リカバリを可能にするか期間を指定

– Disk上のバックアップ、Tape 上のバックアップそれぞれに対して指定

• max_retention_window

–バックアップを保持する期間を指定

• guaranteed_copy

–バックアップがディスク上から削除される前に、テープやReplication先に移動するか• No ：バックアップ時に領域がなければ古いものは消されるが、バックアップが失敗しない

• Yes ：バックアップ時に領域がなければ、バックアップを失敗させる。保持目標を満たすことを優先

50



保護ポリシーの定義保護DBに保護ポリシーを割り当てる

•保護DBをRecovery Appliance上のリカバリ・カタログに登録する– DB名、対応させる保護ポリシー、利用する領域サイズを指定する

– Storage Locationは、複数の保護DBで共有されるので、各保護DB毎に、使用するサイズを管理者自身で計算して指定する必要がある• サイジングの目安は下記

SIZE(Level0) + SIZE(Level1) * recovery_window+ SIZE(archivelog/1day) * recovery_window

これに圧縮率、データ量増加を加味

51


保護DB毎に、保護ポリシーを割り当てている


Delta Pool の空き領域管理

•バックアップの削除対象有無の確認を行うタイミング–定期的なタイミング(バックアップをDisk からTapeに移動するジョブ)

–バックアップ取得時に領域が不足しているタイミング

•管理方法–下記の優先順で削除対象とする

1. 期限切れしているアーカイブバックアップ

2. バックアップの存在期間＞バックアップ保持期間かつ Point-in-Time リカバリに不要なものを削除対象とする

3. Point-in-Time リカバリに必要だが、保護DB毎の確保スペースを超えているもの(reserved_space)

4. 期限切れしていないアーカイブバックアップ

• 断片化した領域をデフラグする機能も定期的に動作する

52


Autonomous Archive

53


テープへのバックアップのコピー

• Exadata X4構成にテープへの接続が追加されている

• 16Gb Fibre Channel Cards

•通常保護DBで実施するテープへのバックアップをZDLRAにオフロードすることができる

• Oracle Secure Backup がプリ・インストールされている

• Disk 上での保存期限を過ぎたバックアップはテープへと移動される

• テープへのコピー時には、Disk 上の仮想フル・バックアップから取得した通常のRMANのLevel 0, Level 1 バックアップ

54


Replication

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 に通知する

56


One Way

Bi-Directional

Hub & Spoke

Remote Data CenterLocal Data Center

• 遠隔地の Recovery Appliance へレプリケーションすることで、災害/サイト障害へ対応

• ローカルもしくは遠隔地の Recovery Appliance から直接リストア可能

遠隔地へのレプリケーション：災害/サイト障害への対応

57


本日の内容

1

2

3

4

5





まとめ

58


バックアップ・リカバリの統合的な管理単一システムで、あらゆるバージョン/プラットフォームを統一した方式で管理

59

個別システム毎のバラバラな管理 Recovery Appliance での統一管理

Oracle 10gOracle 11gOracle 12c

EE/SE

LinuxWindows

SolarisAIX

HP-UXWindows

Linux

Solaris

AIX

HP-UX

EMC

IBM

HP

NetApp


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＋パッチ

• リアルタイム・カスケード

60


まとめ







61

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 62


Documents

Zero Data Loss Recovery Appliance...Incremental Forever Backup Strategy •2つの増分バックアップの間の変更デー タは、REDO転送によって埋める 22 A A A A

Zero Data Loss Recovery Appliance...Incremental Forever Backup Strategy •2つの増分バックアップの間の変更データは、REDO転送によって埋める 22 A A A A