DBA & Developer Day 2016 ダウンロード資料

(1)

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

クティスが詰まったZero Data Loss

Recovery Appliance 詳解

日本オラクル株式会社

クラウド・テクノロジー事業統括

Database & Exadata プロダクトマネジメント本部

応用技術部

(2)

• 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するも

のです。また、情報提供を唯一の目的とするものであり、いかなる契約

にも組み込むことはできません。以下の事項は、マテリアルやコード、

機能を提供することをコミットメント（確約）するものではないため、

購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関

して記載されている機能の開発、リリースおよび時期については、弊社

の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。

文中の社名、商品名等は各社の商標または登録商標である場合があります。

(3)

本日お伝えしたいこと

Recovery Manager (RMAN)の経験有無に関係無く

Recovery Appliance は安心して使えます

なぜなら、Recovery Appliance には

バックアップ・リカバリに関する

(4)

本日の内容

Recovery Appliance 動作概要

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

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

まとめ

1

2

3

4

(5)

Recovery Appliance 全体像

Recovery

Appliance

本番機

EM管理コンソール

Delta Push

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

Recovery Appliance に直接転送

• REDO を送信（任意）

Delta Store

• 受け取った増分バックアップを分解、

索引付けし、検査、圧縮をして格納

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

Replication

:

• DRサイトへの複製

Recovery

Appliance

災対サイト

本番機

データ保護をメニュー化

• 定義したメニューから

保護対象DBに見合った

保護レベルを選択する

Autonomous

Archive:

• テープへのコピー

クラウドスケール

• 数千もの保護DB

• 各種OS/Version対応

• ペタバイトのデータ

も保護可能

• 高価な Agentが不要

(6)

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

データの実体

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

A A A A A

B C A B C

B A A B B

A A A A A

B

B B

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

REDO転送

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(作業場所)

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

データの実体

メタデータ(仮想フ

_{ルバックアップ)}

1. set until time 9/2 05:00 PM

restore 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 B

4. リカバリ

B A A B C

3. リストア先に必要なアーカイブREDOが

_{なければ、アーカイブREDOもリストア}

(8)

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

Name

Description

INDEX_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

データベースに格納されているバックアップを検査する

(9)

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

データの実体

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

A A A A A

B C A B C

B A A B B

A A A A A

B

B B

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

REDO転送

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(作業場所)

INDEX_BACKUP

BACKUP_ARC

Jnnn

PURGE

Jnnn

VALIDATE

Jnnn

(10)

RA_TASK ビュー

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:00

DEMO1 BACKUP_ARCH COMPLETED 12-OCT-16 03.05.01.551786 PM +09:00

DEMO1 INDEX_BACKUP COMPLETED 12-OCT-16 03.06.29.375337 PM +09:00

DEMO1 INDEX_BACKUP COMPLETED 12-OCT-16 03.06.34.281116 PM +09:00

DEMO1 INDEX_BACKUP COMPLETED 12-OCT-16 03.07.47.418527 PM +09:00

DEMO1 PURGE_DUP COMPLETED 12-OCT-16 03.07.48.406041 PM +09:00

DEMO1 DEFERRED_DEL COMPLETED 12-OCT-16 03.07.48.572036 PM +09:00

DEMO1 PLAN_DF COMPLETED 12-OCT-16 03.07.49.490420 PM +09:00

DEMO1 OPTIMIZE COMPLETED 13-OCT-16 11.24.19.810113 AM +09:00

DEMO1 CROSSCHECK_DB COMPLETED 13-OCT-16 11.24.19.813185 AM +09:00

DEMO1 RESTORE_RANGE_REFRESH COMPLETED 13-OCT-16 04.15.26.591837 PM +09:00

DEMO1 VALIDATE RUNNING 13-OCT-16 04.25.12.418079 PM +09:00

(11)

本日の内容

Recovery Appliance 動作概要

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

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

まとめ

1

2

3

4

(12)

破損チェック

(13)

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

• RMANを利用したバックアップではOracle Database インスタンスを介してブ

ロックを読むので次のような破損を検知可能

–

Block Header が不正

–

Block HeaderとFooterの情報が不一致

–

Data の欠落

–

Block の配置場所が不正など

• RMANでバックアップを取得するだけでなく、下記を運用に組み込むことでブ

ロック破損チェックを万全にできる

–

週次でRMANのCROSSCHECK

–

週次もしくは月次のRMAN BACKUP/RESTORE VALIDATE

–

月次もしくは四半期のリストア・リカバリ訓練

(14)

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

• バックアップ取得時(RMANコマンド)

–

バックアップ対象のOracle Databaseインスタンスによるデータブロックの検査

• 仮想フルバックアップ作成時[*]

–

受け取ったバックアップを分解、検査し、仮想フルバックアップ化してHDDに書き込む

• Recovery Appliance内に格納されているバックアップの検査時[*]

–

日次で全バックアップセットのCROSSCHECK

–

週次でデータファイルを構成するバックアップデータの最適化(=Block読込)

–

隔週で全バックアップセットの検査(RESTORE VALIDATEと同様)

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

(15)

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

• Recovery Appliance 内部で下記のタスクがバックグラウンドで行われる

• 頻度の変更は認められている（DBMS_RA.CONFIG プロシージャ）

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

タスク名

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日

バックップ構成データの配置最適化

(16)

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

Recovery Applianceのリソースを使ってバックアップの健全性を確認している

FC-SW

NWSW

従来型NAS

RMAN> VALIDATE

BACKUPSET DEVICE TYPE

DISK;

CPU

95%

I/O

_FC-SW

_NWSW

Recovery Appliance

CPU

本番DBサーバーのCPUリソースを

使って、NAS上のバックアップ

ファイルの健全性チェック

本番DBサーバーのCPUリソースは

使わない

Recovery Appliance 上のリソース

を使って健全性チェック

バックアップ用ネッ

トワーク上のI/O

(Read)が発生する

バックアップの健全性チェック

は、

Recovery Appliance 内で

完結

。チェック用ジョブはデ

フォルトでスケジュール済み

CPU

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

Recovery Applianceの場合

DB

(17)

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

• ブロック検査のタスクは優先度の低いタスクとしてスケジューリングされるため、

他の優先度の高いタスクが生成された場合には終了を待機する可能性がある

• バックアップデータ量に対するVALIDATE完了までの時間例(※)

–

全バックアップデータサイズ:9TB  440分

–

全バックアップデータサイズ:128GB  45分

社内環境での実績

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 PM

DEMO1 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 AM

DBM01 CROSSCHECK_DB COMPLETED 15-OCT-16 02.31.43 PM 15-OCT-16 02.31.43 PM

※実行時間の一例であり、

(18)

破損を検知した場合

• Recovery Appliance は Exadata の基盤の上で動く

–

バックアップデータはASMを利用して格納されている

–

バックアップ破損検知時はASMのセカンダリのエクステントから復旧を試みる

• 復旧できない場合はバックアップの取り直しを行う

• リストア/リカバリを実施するよりも前に「気付ける」という点が重要

–

失敗できないリストア/リカバリの段階で、バックアップの破損を検知すると。。。

–

ストレージ機能はフィルムカメラ、RMANを使ったバックアップはデジタルカメラ

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

• Recovery Appliance を利用していたとしても、実際のオペレーションに備え

て定期的にリストア・リカバリ訓練を実施することは大事

(19)

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

世代管理の自動化

(20)

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

• RMANのBACKUP RETENTION POLICYを設定し、DELETE OBSOLETE コマ

ンドを定期実行する

–

ポリシーに従って不要と判断されたバックアップセット、アーカイブログが削除される

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

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS ;

またおは

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1 ;

RMAN> DELETE OBSOLETE ;

• これで安心？

–

バックアップの取得先がNAS上だったら？

(21)

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

• バックアップは保持期間などを設定して、取得から削除までのライフサイクル

を適切に管理する必要がある

• 可用性要件毎にポリシー

(リカバリ・ウィンドウ、ディスク保持期間など)

を定

義し、データベース毎にポリシーを適用する

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

Gold

Silver

Bronze

ミッション・クリティカル

ディスク:30日テープ:90日 Replication:有

ビジネス・クリティカル

ディスク:10日テープ:30日 Replication:無

ポリシーの例

テスト、開発

ディスク:6時間テープ:なし Replication:無

(22)

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#5

A A A A A

B

B B

#6#7

#8

#9

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タスク)

××

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

(23)

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

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

PROCEDURE CREATE_PROTECTION_POLICY

Argument Name Type In/Out Default?

--- --- ---

---PROTECTION_POLICY_NAME VARCHAR2 IN

DESCRIPTION VARCHAR2 IN DEFAULT

STORAGE_LOCATION_NAME VARCHAR2 IN

POLLING_POLICY_NAME VARCHAR2 IN DEFAULT

RECOVERY_WINDOW_GOAL INTERVAL DAY TO SECOND IN

MAX_RETENTION_WINDOW INTERVAL DAY TO SECOND IN DEFAULT

RECOVERY_WINDOW_SBT INTERVAL DAY TO SECOND IN DEFAULT

UNPROTECTED_WINDOW INTERVAL DAY TO SECOND IN DEFAULT

GUARANTEED_COPY VARCHAR2 IN DEFAULT

ALLOW_BACKUP_DELETION VARCHAR2 IN DEFAULT

STORE_AND_FORWARD VARCHAR2 IN DEFAULT

(24)

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 prevented

by protection policy

(25)

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

データの実体

A A A A A

Virtual 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_4

Handle: VB$_4052721630_83992I Media:

List of Datafiles in backup set 84036

File LV Type Ckp SCN Ckp Time Name

-- -- -

----1 0 Incr 78----15554 30-SEP---16 +DATAC----1/DEMO----1/DATAFILE/system.----12----18.92----1409907

16 0 Incr 7815554 30-SEP-16 +DATAC1/DEMO1/DATAFILE/users.2053.923860355

RMAN List コマンドでも仮想フルバックアッ

プが作成されていることを確認できる

(26)

テープへのコピー

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

(27)

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

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

1

2 プライマリコピー

セカンダリコピー DR向けコピー

3 ディスク

テープ

プライマリサイト

DRサイト or クラウド

3) 3つのコピー

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

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

(28)

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

• ディスクにバックアップ

• バックアップソフトウェアをインス

トールしたサーバーからバックアップ

をマウント

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



Backup サーバーや、バックアップソ

フトウェアが必要となる

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

本番

DB1

Backup

Soft

本番

DB2

Backup

Tape

(29)

Recovery Appliance なら本番DBへの影響無し

Recovery ApplianceとTape間の通信のみ & Backupサーバー/Agentは不要

A A A A A

B

B B

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 にオフロードするため、本

番環境への影響を与えない

(30)

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

• テープ保管期間

：(例) 60日間

• テープ入出庫サイクル：(例) 7日間(遠隔地に60日間保管、60日後に再入庫)

• テープバックアップ

：(例) 7日間毎にCopy-to-Tapeジョブ(Full Backup)

時系列

現在

ディスク・

リカバリ・ウィンドウ目標

(Recovery Window Goal)

Recovery Appliance から

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

60日間

未設定

35日間

メディア・マネージャ・

リカバリ・ウィンドウ・ポリシー

Recovery Window SBT

=60日

Recovery Applianceまたはテープから

Point-in-timeリカバリが可能な期間(保証値)

(31)

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

Oracle Secure Backup を使う場合は必要な設定が（名前、ド

ライブ数、OSBの共有ライブラリのパス）が入力されている

3 rd

_{party 製品の場合は手動で入力する}

必要な設定（名前）が

Recovery Appliance セット

アップ時に設定されている

(32)

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

保護ポリシーに含まれる全てのデータベースを対

象にするか、個別のデータベースを対象にするか

を選べる

バックアップのタイプを選択する

（フル、増分、アーカイブのいずれか）

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

(33)

本日の内容

Recovery Appliance 動作概要

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

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

まとめ

1

2

3

4

(34)

構成

(35)

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

One Way

Bi-Directional

Hub &

Spoke

Remote Data Center

Local Data Center

• 遠隔地のRecovery Appliance

へレプリケーションすること

で災害/サイト障害へ対応

• ローカルもしくは遠隔地の

Recovery Appliance から

直接

リストア可能

(36)

Recovery Appliance を使った災害対策

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

• Data Guardを組める場合はData Guardの利用が望ましい

–

すばやく切替が可能

–

REDOのみの転送となりWAN回線を消費しない

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

(37)

事例

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

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

Cloud Control

12.1.0.4 Exadata X5

Exadata X2

Other Databases

Exadata X4

DR Site

Primary Site

Data Guard

Replication for

non-Data Guard

Databases

計画中

(38)

事例

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 Rack

7EF + 4 HC (HIGH)

Exadata X5-2 Half Rack

7 EF (HIGH)

FDC LFDC

(39)

リカバリ

• どの時点までリカバリできるのかをリアルタイムに把握する

(40)

全データベースの保護状態を一元管理

Enterprise Manager による監視

任意の時点へのリカバリ可能な日数

ポリシーに準拠し容量を管理

＝失う可能性のあるデータの範囲が一目で分かる

保護されていないデータ

各

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

(41)

複製データベースの作成

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

テスト用データ

日次論理バックアップ

(Datapump)

任意時点の

データの抽出

任意の地点のデータを再現できるの

で、テストデータの抽出という作業

自体を削減可能。かつテストデータ

の準備は必要な日時を指定するのみ。

バックアップ取得以外に本番

データベースへの負荷は無い

(42)

タグVLAN対応

• 保護DBはVLANネットワークを介し

てRecovery Appliance に接続可能

• 各DBとのバックアップ・リカバリに

関する通信はVLAN毎に分離される

• RMAN RESTORE/DUPLICATE 操作

は通常通り動作する

–

同じVPCユーザで認証されていれば、

VLAN1上のデータベースで取得された

バックアップをVLAN2上のデータベース

にリストア可能

• インストール後にVLANを設定する詳

細手順はMOS Note 2047411.1

Prod DBs

Test/Dev DBs

(43)

バックアップ取得

(44)

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

• 大きなデータファイル(1TB超え)ではマルチセクションバックアップを利用

–

セクションサイズは64GBから検討を開始し、チャネル数に合わせてカスタマイズ

• 仮想フルバックアップの作成状況を監視する

–

次回の増分バックアップ(推奨は累積増分バックアップ)は、仮想フルバックアップをLevel 0

として増分が検討される (詳細はページ下部リンク参照)

• 仮想フルバックアップのタスクはバックアップセット単位で1タスク1プロセス

が割り当てられて行われるので、バックアップセットに含めるデータファイル

は少なくした方が良い  filesperset 1 (デフォルト64)

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;

(45)

本日の内容

Recovery Appliance 動作概要

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

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

まとめ

1

2

3

4

(46)

まとめ

Recovery Manager (RMAN)の経験有無に関係無く

Recovery Appliance は安心して使えます

なぜなら、Recovery Appliance には

バックアップ・リカバリに関する

(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 12c: マルチテナント・アーキテクチャ (2日間) Oracle Database 12c: ASM 管理 (2日間) Oracle Database 12c: 管理クイック・スタート (2日間) Oracle Database 12c: 管理ネクスト・ステップ (3日間) Ad va nc ed A na lyti cs O pti on 対応コース

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

(48)

Oracle Digitalは、オラクル製品の導入をご検討いただく際の総合窓口。

電話とインターネットによるダイレクトなコニュニケーションで、どんなお問い合わせにもすばやく対応します。

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

(49)

(50)

(51)