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)

バックアップセット


ソフトウェア構成(2/3) 保護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ライブラリを用いてバックアップデータをネットワーク越しに転送する

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


ソフトウェア構成(3/3) 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


保護DB

バックアップセット

(2) Storage Location にアーカイブして、リカバリカタログに登録

REDO Logs

LAD1 location=USE_DB_RECOVERY_FILE_DEST valid_for=(ONLINE_LOGFILE,ALL_ROLES) db_unique_name=dblra alternate=LOG_ARCHIVE_DEST_2 LAD2 location=+CATALOG valid_for=(ONLINE_LOGFILE,ALL_ROLES) db_unique_name=dblra alternate=LOG_ARCHIVE_DEST_1 LAD3 location=+DELTA valid_for=(STANDBY_LOGFILE,ALL_ROLES)

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


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


仮想フル

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

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

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

Technology

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