バックアップ・リカバリのベストプラクティスが詰 …otndnld.oracle.co.jp/ondemand/ddd-2016/DD1-5.pdf– Block Header が不正 – Block HeaderとFooterの情報が不一致

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

バックアップ・リカバリのベストプラクティスが詰まったZero Data Loss Recovery Appliance 詳解

日本オラクル株式会社クラウド・テクノロジー事業統括Database & Exadata プロダクトマネジメント本部応用技術部シニアエンジニア佐々木亨

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

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

2


本日お伝えしたいこと

Recovery Manager (RMAN)の経験有無に関係無くRecovery Appliance は安心して使えます

なぜなら、Recovery Appliance にはバックアップ・リカバリに関するベストプラクティスが詰まっているからです

3


本日の内容

Recovery Appliance 動作概要

バックアップ・リカバリのベストプラクティス

Recovery Appliance 利用時のベストプラクティス

まとめ

1

2

3

4

4


Recovery Appliance 全体像

5

RecoveryAppliance本番機

EM管理コンソール

Delta Push• 増分バックアップ取得し、

Recovery Appliance に直接転送• REDO を送信（任意）

Delta Store• 受け取った増分バックアップを分解、索引付けし、検査、圧縮をして格納

• 増分バックアップからフルバックアップを生成

Replication :• DRサイトへの複製

RecoveryAppliance災対サイト

本番機

データ保護をメニュー化• 定義したメニューから保護対象DBに見合った保護レベルを選択する

Autonomous Archive:

• テープへのコピー

クラウドスケール• 数千もの保護DB• 各種OS/Version対応• ペタバイトのデータも保護可能

• 高価な Agentが不要


バックアップ時の動作イメージ

データの実体

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

#1 #2 #3 #4 #5

#6 #7 #8

#9 #10

A A A B B

B A A B C

Lv1 Backup

Lv1 Backup

REDO転送

REDO転送

Backup転送

増分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}

メタデータ(仮想フルバックアップ)

更新

9/2 AM 1:00

9/3 AM 1:00

switch

Flash(作業場所)

6

REDOは適用せずにアーカイブとして保持

リアルタイムREDO転送でRPO≒0を実現


リストア時の動作イメージ

7

点線の時刻にPoint in Timeリカバリ

A A A A A

B A A B B

時間

9/1 AM 1:00

A A A B B

B A A B C

9/2 AM 1:00

A A A A A

B A A B B

A A A A A

B B B

Virtual Full#1

Virtual Full #2

#1#2#3#4#5

#6 #7#8

アーカイブREDO

アーカイブREDO

データの実体メタデータ(仮想フルバックアップ)

1. set until time 9/2 05:00 PMrestore database;recover database;

2. 9/2 05:00 PM 直前のフルバックアップはVirtual Full #2であることを自動的に認識し、Virtual Full#2からフルバックアップを構成し対象にリストアする

Virtual Full#2 ={#6#2#3#7#8}

B A A B BB A A B B

4. リカバリ B A A B C 3. リストア先に必要なアーカイブREDOがなければ、アーカイブREDOもリストア


それぞれの動作はタスクとして実行される

Name DescriptionINDEX_BACKUP バックアップピースを索引付けしDelta Pool に格納する(仮想フルバックアップの作成)BACKUP_ARCH RFSが受け取ったアーカイブログをStorage Location にコピーするOPT_DF リストアのIO効率を改善(最新の仮想フルバックアップへのアクセス)するためにDelta Pool内の

ブロックを並び替えるRESTORE 1つ以上のDelta Pool からバックアップピースを構成するのを補助するPURGE_DUP 複数のLevel0バックアップに索引付けした際に発生する重複ブロックをDelta Pool から削除するBACKUP_SBT バックアップピースをテープもしくは、Replication先のRAに複製するRESTORE_SBT テープもしくはReplication先のRAからバックアップピースをリストアするPURGE 新しいバックアップのための空き領域を確保するために非同期に古いバックアップをDelta Store

から削除するCROSSCHECK_DB カタログがテープやReplication先のRAに格納されるバックアップを反映しているか検査するVALIDATE データベースに格納されているバックアップを検査する

8

動作しているタスクの例


それぞれの動作はタスクとして実行される

データの実体

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


Virtual Full#1

Virtual Full#2

Virtual Full#3

#1 #2 #3 #4 #5

#6 #7 #8

#9 #10

A A A B B

B A A B C

Lv1 Backup

Lv1 Backup

REDO転送

REDO転送

Backup転送

増分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}

メタデータ(仮想フルバックアップ)

更新

switch

Flash(作業場所)

9

INDEX_BACKUP

INDEX_BACKUP

INDEX_BACKUP

BACKUP_ARC

BACKUP_ARC

Jnnn

Jnnn

Jnnn

Jnnn

Jnnn

PURGE

Jnnn

VALIDATEJnnn


RA_TASK ビュー

10

Recovery Appliance上で動く各タスクのステータスが分かる

SQL> select db_unique_name, task_type, state, creation_time from ra_task;

DB_UNIQUE_ TASK_TYPE STATE CREATION_TIME---------- --------------------- ---------- ------------------------------------DEMO1 BACKUP_ARCH COMPLETED 12-OCT-16 03.05.00.329570 PM +09:00DEMO1 BACKUP_ARCH COMPLETED 12-OCT-16 03.05.01.551786 PM +09:00DEMO1 INDEX_BACKUP COMPLETED 12-OCT-16 03.06.29.375337 PM +09:00DEMO1 INDEX_BACKUP COMPLETED 12-OCT-16 03.06.34.281116 PM +09:00DEMO1 INDEX_BACKUP COMPLETED 12-OCT-16 03.07.47.418527 PM +09:00DEMO1 PURGE_DUP COMPLETED 12-OCT-16 03.07.48.406041 PM +09:00DEMO1 DEFERRED_DEL COMPLETED 12-OCT-16 03.07.48.572036 PM +09:00DEMO1 PLAN_DF COMPLETED 12-OCT-16 03.07.49.490420 PM +09:00DEMO1 OPTIMIZE COMPLETED 13-OCT-16 11.24.19.810113 AM +09:00DEMO1 CROSSCHECK_DB COMPLETED 13-OCT-16 11.24.19.813185 AM +09:00DEMO1 RESTORE_RANGE_REFRESH COMPLETED 13-OCT-16 04.15.26.591837 PM +09:00DEMO1 VALIDATE RUNNING 13-OCT-16 04.25.12.418079 PM +09:00


本日の内容




まとめ

1

2

3

4

11


破損チェックOracle Database インスタンスを介したブロックチェック

12


Oracle Database インスタンスを介したチェック

• RMANを利用したバックアップではOracle Database インスタンスを介してブロックを読むので次のような破損を検知可能– Block Header が不正– Block HeaderとFooterの情報が不一致– Data の欠落– Block の配置場所が不正など

• RMANでバックアップを取得するだけでなく、下記を運用に組み込むことでブロック破損チェックを万全にできる– 週次でRMANのCROSSCHECK– 週次もしくは月次のRMAN BACKUP/RESTORE VALIDATE– 月次もしくは四半期のリストア・リカバリ訓練

13

ブロック構造を理解してブロック破損を検知可能


Oracle Database インスタンスを介したチェック

• バックアップ取得時(RMANコマンド)– バックアップ対象のOracle Databaseインスタンスによるデータブロックの検査

• 仮想フルバックアップ作成時[*]– 受け取ったバックアップを分解、検査し、仮想フルバックアップ化してHDDに書き込む

• Recovery Appliance内に格納されているバックアップの検査時[*]– 日次で全バックアップセットのCROSSCHECK– 週次でデータファイルを構成するバックアップデータの最適化(=Block読込)– 隔週で全バックアップセットの検査(RESTORE VALIDATEと同様)

14

Recovery Appliance を使えば万全なブロック破損チェックをより簡単に

[*] Recovery Appliance 上で動作する Oracle Database インスタンスのバックグラウンドプロセスが処理


Recovery Appliance 格納後のバックアップ検査

• Recovery Appliance 内部で下記のタスクがバックグラウンドで行われる• 頻度の変更は認められている（DBMS_RA.CONFIG プロシージャ）

15

バックアップの検査を担う定期実行タスク

タスク名 CONFIGパラメータ頻度内容VALIDATE validate_db_days 14日バックアップピースの検査を実施CHECK_FILES check_file_days 14日 Recovery Appliance 内のメタデータの一

貫性チェックを実施CROSSCHECK_DB crosscheck_db_days 7日 Recovery Appliance上のカタログを検査OPT_DF optimize_chunk_days 7日バックップ構成データの配置最適化


Oracle Database インスタンスを介したチェックRecovery Applianceのリソースを使ってバックアップの健全性を確認している

FC-SW NWSW

従来型NAS

RMAN> VALIDATE BACKUPSET DEVICE TYPE DISK;

CPU95%

I/O FC-SW NWSW

Recovery Appliance

CPU

本番DBサーバーのCPUリソースを使って、NAS上のバックアップファイルの健全性チェック

本番DBサーバーのCPUリソースは使わないRecovery Appliance 上のリソースを使って健全性チェック

バックアップ用ネットワーク上のI/O(Read)が発生する

バックアップの健全性チェックは、Recovery Appliance 内で完結。チェック用ジョブはデフォルトでスケジュール済み

CPU

既存統合バックアップ環境の場合 Recovery Applianceの場合

DB DB DB DB

16


【参考情報】チェック系タスクの実行時間

• ブロック検査のタスクは優先度の低いタスクとしてスケジューリングされるため、他の優先度の高いタスクが生成された場合には終了を待機する可能性がある

• バックアップデータ量に対するVALIDATE完了までの時間例(※)– 全バックアップデータサイズ:9TB 440分– 全バックアップデータサイズ:128GB 45分

17

社内環境での実績

RA_TASK ビューの確認結果(一部抜粋)

DB_UN TASK_TYPE STATE CREATION_TIME COMPLETION_TIME------ -------------- ---------- --------------------- ---------------------DEMO1 VALIDATE COMPLETED 13-OCT-16 04.25.12 PM 13-OCT-16 05.09.14 PMDEMO1 CROSSCHECK_DB COMPLETED 14-OCT-16 11.27.56 AM 14-OCT-16 11.27.56 AM

DBM01 VALIDATE COMPLETED 15-OCT-16 12.29.50 AM 15-OCT-16 07.54.39 AMDBM01 CROSSCHECK_DB COMPLETED 15-OCT-16 02.31.43 PM 15-OCT-16 02.31.43 PM

※実行時間の一例であり、性能を保証するものではありません


破損を検知した場合

• Recovery Appliance は Exadata の基盤の上で動く– バックアップデータはASMを利用して格納されている– バックアップ破損検知時はASMのセカンダリのエクステントから復旧を試みる

• 復旧できない場合はバックアップの取り直しを行う• リストア/リカバリを実施するよりも前に「気付ける」という点が重要

– 失敗できないリストア/リカバリの段階で、バックアップの破損を検知すると。。。– ストレージ機能はフィルムカメラ、RMANを使ったバックアップはデジタルカメラ

• 大切な写真を現像してみたら「目をつむっていた」「ピントがずれていた」が無いように

• Recovery Appliance を利用していたとしても、実際のオペレーションに備えて定期的にリストア・リカバリ訓練を実施することは大事

18


バックアップのライフサイクル世代管理の自動化

19


バックアップは取得して終わりではない

• RMANのBACKUP RETENTION POLICYを設定し、DELETE OBSOLETE コマンドを定期実行する– ポリシーに従って不要と判断されたバックアップセット、アーカイブログが削除される

20

RMANの場合削除ポリシーを定めれば良い

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS ;またおはRMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1 ;

RMAN> DELETE OBSOLETE ;

• これで安心？– バックアップの取得先がNAS上だったら？– NAS上にあるファイルシステム上のバックアップを rm されたら？


保護ポリシーに基づくバックアップ管理

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

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

21

Recovery Appliance では自動でやってくれる

GoldSilver

Bronze

ミッション・クリティカルディスク:30日テープ:90日 Replication:有

ビジネス・クリティカルディスク:10日テープ:30日 Replication:無

ポリシーの例

テスト、開発ディスク:6時間テープ:なし Replication:無


Recovery Appliance はブロック単位で管理する保護ポリシー上不要となったブロックを削除する

B

A A A A A

B A A B B

時間

9/1 AM 1:00

A A A B B

B A A B C

9/3 AM 1:00

9/2 AM 1:00

9/4 AM 1:00

#1#2#3#4#5A A A A A

B

B B#6#7

#8

#9

RAへ転送

RAへ転送

RAへ転送

RAへ転送

A A B B

A A B C

9/2 AM 1:00 時点のフル・バックアップデータは、#1,2,3,6,7 を集めれば作りだせるため、#4,#5 のブロックは不要

不要になったタイミングで、ブロック単位で、#4,#5 が削除

領域が断片化しないようにブロックの再配置処理が定期的に動く(OPT_DFタスク)

××

ポリシーに従ってブロック単位(ファイルではない)で完全に自動管理

22


カタログに接続してRMANコマンドでも消せない

23

手動でのバックアップ削除を許さない設定も可能

PROCEDURE CREATE_PROTECTION_POLICYArgument Name Type In/Out Default?------------------------------ ----------------------- ------ --------PROTECTION_POLICY_NAME VARCHAR2 INDESCRIPTION VARCHAR2 IN DEFAULTSTORAGE_LOCATION_NAME VARCHAR2 INPOLLING_POLICY_NAME VARCHAR2 IN DEFAULTRECOVERY_WINDOW_GOAL INTERVAL DAY TO SECOND INMAX_RETENTION_WINDOW INTERVAL DAY TO SECOND IN DEFAULTRECOVERY_WINDOW_SBT INTERVAL DAY TO SECOND IN DEFAULTUNPROTECTED_WINDOW INTERVAL DAY TO SECOND IN DEFAULTGUARANTEED_COPY VARCHAR2 IN DEFAULTALLOW_BACKUP_DELETION VARCHAR2 IN DEFAULTSTORE_AND_FORWARD VARCHAR2 IN DEFAULT

保護ポリシーを作成するプロシージャ


DELETEコマンドによるバックアップ削除をブロック保護ポリシーの属性 ALLOW_BACKUP_DELETION='NO'

• Recovery Appliance 内に格納されたバックアップに対する RMAN DELETE コマンドをブロック可能– ストレージ機能では、保持期間内のバックアップに対する誤ったDELETE操作かどうかを識別できない

– バックアップデータの管理はRecovery Applianceに完全に任せる

– データベース管理者とバックアップ管理者の間の職務分掌

– 「集中管理」「データベースを意識した」「サービスとしてのデータ保護」（一般的なファイルバックアップと違う）

保護ポリシー"GOLD"

ALLOW_BACKUP_DELETION = ‘NO’

“DELETE BACKUP ..”

ORA-64766: backup deletion using RMAN preventedby protection policy

24


【参考】Recovery Appliance上でのBackupの見え方

25

データの実体A A A A A

A A A A AA A A A AA A A A AVirtual Full#1= {#1#2#3#4#5}

#1 #2 #3 #4 #5

Backup転送

仮想フルバックアップが出来たタイミングで削除

メタデータ(仮想フルバックアップ)Flash(作業場所)名前:bcrh1u52_1_1 名前:

VB$_4052721630_83992I

RMAN> list backup;BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------84036 Incr 0 82.92M SBT_TAPE 00:00:00 30-SEP-16

BP Key: 84037 Status: AVAILABLE Compressed: YES Tag: TEST20160930_4Handle: VB$_4052721630_83992I Media:

List of Datafiles in backup set 84036File LV Type Ckp SCN Ckp Time Name---- -- ---- ---------- --------- ----1 0 Incr 7815554 30-SEP-16 +DATAC1/DEMO1/DATAFILE/system.1218.92140990716 0 Incr 7815554 30-SEP-16 +DATAC1/DEMO1/DATAFILE/users.2053.923860355

RMAN List コマンドでも仮想フルバックアップが作成されていることを確認できる


テープへのコピーバックアップは「3-2-1」(3つのコピーを、2つの異なるメディアに、1つはオフサイトでオフライン)

26


バックアップは「3-2-1」

27

テープバックアップの必要性

1 2

プライマリコピーセカンダリコピー DR向けコピー

3

ディスクテープ

プライマリサイト DRサイト or クラウド

3) 3つのコピー

2) 2つの異なるメディア

1) 1つはオフサイトでオフライン


バックアップは「3-2-1」を実現するには

• ディスクにバックアップ• バックアップソフトウェアをインストールしたサーバーからバックアップをマウント

• テープへバックアップをコピー

Backup サーバーや、バックアップソフトウェアが必要となる

BackupサーバーやBackup用ソフトウェアが必要

本番

DB1

Backup

BackupSoft

本番

DB2

Backup

Tape

28


Recovery Appliance なら本番DBへの影響無しRecovery ApplianceとTape間の通信のみ & Backupサーバー/Agentは不要

A A A A A

B B B

C C

#1 #2 #3 #4 #5

#6 #7 #8

#9 #10

VB#1={#1#2#3#4#5}

VB#2={#6#2#3#7#8}

VB#3={#6#9#3#7#10}

B A A B B

RMAN バックアップセット形式のファイル

Backup Copy to Tape

：直近1ヵ月の間に戻るために必要なバックアップデータを保持

月末のデータを10年間分保持

Full

Archive Redo

テープ装置への出力をRecovery Appliance にオフロードするため、本番環境への影響を与えない

29


テープ遠隔地保管運用する例

• テープ保管期間：(例) 60日間• テープ入出庫サイクル：(例) 7日間(遠隔地に60日間保管、60日後に再入庫)• テープバックアップ：(例) 7日間毎にCopy-to-Tapeジョブ(Full Backup)

30

時系列

現在

ディスク・リカバリ・ウィンドウ目標(Recovery Window Goal)

Recovery Appliance から直接リストア可能な期間(保証値)

60日間未設定 35日間

メディア・マネージャ・リカバリ・ウィンドウ・ポリシーRecovery Window SBT=60日

Recovery ApplianceまたはテープからPoint-in-timeリカバリが可能な期間(保証値)


【補足】テープバックアップの設定

Oracle Secure Backup を使う場合は必要な設定が（名前、ドライブ数、OSBの共有ライブラリのパス）が入力されている3rd party 製品の場合は手動で入力する

必要な設定（名前）がRecovery Appliance セットアップ時に設定されている

31


【補足】テープバックアップの設定

保護ポリシーに含まれる全てのデータベースを対象にするか、個別のデータベースを対象にするかを選べる

バックアップのタイプを選択する（フル、増分、アーカイブのいずれか）

作成したテンプレートを使ったジョブを定期的にキューに入れればOK

32


本日の内容




まとめ

1

2

3

4

33


構成Data Guard を組める場合はData Guardで災害対策

34


Recovery Appliance のレプリケーション機能

One Way

Bi-Directional

Hub & Spoke

Remote Data CenterLocal Data Center

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

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

35


Recovery Appliance を使った災害対策

• ホワイトペーパーにあるベストプラクティス構成

• Data Guardを組める場合はData Guardの利用が望ましい– すばやく切替が可能– REDOのみの転送となりWAN回線を消費しない

36

Data Guard を組めるものはData Guardで災対構成

http://www.oracle.com/technetwork/database/availability/disaster-recovery-2526839.pdf


事例

• 現在DR Siteは存在しない。Data Guard ＋Recovery Appliance 増設を計画中

37

ブラジル・サンタカタリナ州裁判所（将来構成）

Cloud Control12.1.0.4

Exadata X5

Exadata X2

Other Databases

Exadata X4

DR SitePrimary Site

Data Guard

Replication for non-Data Guard

Databases

計画中

計画中


事例SK Hynix

• リアルタイムトランザクションへの影響低減– スタンバイDBからのバックアップ

• シンプルで低オーバーヘッド– 変更ブロックのみバックアップ Backup性能の安定– 複数のデータベースを1台のZDLRAでカバー– リストア性能の保証

• 永久増分バックアップと検査– バックアップウインドウは小さく– バックアップ検査は定期的に実行

• 各障害時の復旧方法を整理– 大規模障害では Data Guard で切り替えるため、サイトを跨ってDB全体のリストアをするケースはない

DR Center

Primary Center

M14FDC

M14LFDC

EXADATA

Restore &Bring-up

Incremental Forever

ADG

M14 DR

ZDLRA Exadata X5-2 Half Rack

Flashback

FDC

LFDC

Real-time Redo

Exadata X5-2 Half Rack7EF + 4 HC (HIGH)

Exadata X5-2 Half Rack7 EF (HIGH)

FDC

LFDC

38


リカバリ• どの時点までリカバリできるのかをリアルタイムに把握する• 複製DBの作成に有効活用

39


全データベースの保護状態を一元管理Enterprise Manager による監視

任意の時点へのリカバリ可能な日数ポリシーに準拠し容量を管理

保護されていないデータ＝失う可能性のあるデータの範囲が一目で分かる

各DBへドリルダウンした情報

40


複製データベースの作成Recovery Appliance 中のバックアップデータをテスト環境に配布

テスト用データ

日次論理バックアップ(Datapump)

任意時点のデータの抽出

任意の地点のデータを再現できるので、テストデータの抽出という作業自体を削減可能。かつテストデータの準備は必要な日時を指定するのみ。

バックアップ取得以外に本番データベースへの負荷は無い

41


タグVLAN対応

• 保護DBはVLANネットワークを介してRecovery Appliance に接続可能

• 各DBとのバックアップ・リカバリに関する通信はVLAN毎に分離される

• RMAN RESTORE/DUPLICATE 操作は通常通り動作する– 同じVPCユーザで認証されていれば、

VLAN1上のデータベースで取得されたバックアップをVLAN2上のデータベースにリストア可能

• インストール後にVLANを設定する詳細手順はMOS Note 2047411.1

Prod DBs

Test/Dev DBs

42


バックアップ取得Recovery Appliance へのバックアップはデータファイル毎にピースを分ける

43


バックアップ取得時のベストプラクティス

• 大きなデータファイル(1TB超え)ではマルチセクションバックアップを利用– セクションサイズは64GBから検討を開始し、チャネル数に合わせてカスタマイズ

• 仮想フルバックアップの作成状況を監視する– 次回の増分バックアップ(推奨は累積増分バックアップ)は、仮想フルバックアップをLevel 0 として増分が検討される (詳細はページ下部リンク参照)

• 仮想フルバックアップのタスクはバックアップセット単位で1タスク1プロセスが割り当てられて行われるので、バックアップセットに含めるデータファイルは少なくした方が良い filesperset 1 (デフォルト64)

44

MOS Doc ID 2176686.1

RMAN> backup device type sbt cumulative incremental level 1 filesperset 1 section size 64g database plus archivelog not backed up filesperset 32;

http://www.oracle.com/webfolder/technetwork/jp/ondemand/ddd2014/B2-3.pdf


本日の内容




まとめ

1

2

3

4

45


まとめ

Recovery Manager (RMAN)の経験有無に関係無くRecovery Appliance は安心して使えます

なぜなら、Recovery Appliance にはバックアップ・リカバリに関するベストプラクティスが詰まっているからです

46

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 47

Oracle Database 12c 対応研修コースのご案内

Oracle Database 12c: SQL 基礎 I (3日間)

Oracle Database 12c: 管理ワークショップ

(5日間)

Oracle Database 12c: SQL チューニングワークショップ

(3日間)

Oracle Database 12c: PL/SQL プログラム開発 (3日間)

Oracle Database 12c: インストール＆アップグレード

(2日間)

Oracle Database 12c: バックアップ・リカバリ(5日間)

Oracle Database 12c: 新機能(5日間)

Oracle Database 12c: セキュリティ

(5日間)

Oracle Database 12c:Clusterware 管理

(4日間)

Oracle Database 12c:RAC 管理(4日間)

Oracle Database 12c: PL/SQL 基礎

(2日間)

データベース設計(3日間)

Oracle Database 12c: パフォーマンス・チューニング

(5日間)

Bronze

Silver

Platinum

Gold

Oracle Database 12c: SQL 基礎 II

(2日間)

Oracle Database 11g: データ・マイニング

手法(2 日間)

Oracle Database 12c: Database Vault

(2日間)

Oracle ではじめる統計入門(1 日間)

Oracle R Enterprise エッセンシャルズ

(2 日間)

※ Oracle Database 12cR2対応研修は順次提供予定です。詳しくはオラクルユニバーシティまでお問い合わせください。

Oracle Database 12c: マルチテナント・アーキテクチャ

(2日間)

Oracle Database 12c: ASM 管理(2日間)

Oracle Database 12c: 管理クイック・スタート(2日間)

Oracle Database 12c: 管理ネクスト・ステップ(3日間)

Adva

nced

Ana

lytic

s O

ptio

n 対応コース

基礎から上級スキルまで。Oracle Database 12c の製品機能を学習できる多彩な研修コースでスキルアップを


Oracle Digitalは、オラクル製品の導入をご検討いただく際の総合窓口。電話とインターネットによるダイレクトなコニュニケーションで、どんなお問い合わせにもすばやく対応します。

もちろん、無償。どんなことでも、ご相談ください。

http://www.oracle.com/jp/contact-us/index.html



バックアップ・リカバリのベストプラ クティスが詰 …otndnld.oracle.co.jp/ondemand/ddd-2016/DD1-5.pdf– Block Header が不正 – Block HeaderとFooterの情報が不一致

Documents

バックアップ・リカバリのベストプラクティスが詰 …otndnld.oracle.co.jp/ondemand/ddd-2016/DD1-5.pdf– Block Header が不正 – Block HeaderとFooterの情報が不一致