第 142 回夜な夜な! なにわオラクル塾 2015 年版 RMAN バックアップ チューニング 日本オラクル株式会社データベース事業統括ソリューション本部中部 西日本 SC 部 2015 年 03 月 25 日 Copyright 2015 Oracle and/or its affiliates

第142回夜な夜な! なにわオラクル塾

2015年版 RMANバックアップ・チューニング

日本オラクル株式会社

データベース事業統括ソリューション本部

中部・西日本SC部

2015年03月25日

Safe Harbor Statement

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とす

るものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供すること

をコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。

オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標また

は商標です。

他社名又は製品名は、それぞれ各社の商標である場合があります。

Program Agenda

1

2

3

4

5

はじめに

高速増分バックアップ

バックアップの運用ポリシー

RMANバックアップのチューニング

押さえておきたい注意点

Program Agenda

1

2

3

4

5

はじめに

高速増分バックアップ

バックアップの運用ポリシー

RMANバックアップのチューニング

押さえておきたい注意点

本日の目的とゴール

•

高速増分バックアップの動作を理解する

•

_{RMANチューニング方法のポイントを知る}

•

RMAN利用時の注意するポイントを知る

目的

益々重要な機能となってきたRecovery Manager(RMAN)

の活用レベルをあげる

ゴール

バックアップ要件とは？

どういったリカバリが必要かで考える

•

Recovery Time objective (RTO)

–

どのぐらいの時間でリカバリしなければならないのか？

•

Recovery Point Objective (RPO)

–

データをロストしても許容される範囲は？

•

Backup Retention Policy

–

バックアップを保持しておくべき期間は？

•

Additional Questions

バックアップ要件と実装機能

目標復旧時間 / リカバリタイム目標 Recovery Time objective (RTO)

バックアップ＆リカバリ要素技術

目標復旧時間 / リカバリタイム目標(RTO)

物理データ保護

・Recovery Manager (RMAN)

・Automatic Storage Management (ASM)

・Data Guard

Days / Hours

→ Minutes / Seconds / Zero

論理データ保護

・Flashback テクノロジ

・Recovery Manager (RMAN)

Hours / Minutes

リカバリ分析

・データ・リカバリ・アドバイザ

問題特定時間の最小化

Disaster Recovery

目標復旧時間 / リカバリタイム(RTO)

物理データ保護

・ Data Guard

様々なバックアップ方式

Fiber Channel

SAN

10GigE or

InfiniBand

Oracle Secure Backup

Media Servers

Oracle Secure Backup

Admin Server

Tape library

•オフサイト

バックアップ

InfiniBand

Network

Storage Expansion Rack

•高速なバックアップとリストア

•ILM アーカイブ

•Second DATA2 Disk Group

•Expansion of DATA

10GigE or

InfiniBand

Network

Ethernet

ZFS Storage Appliance

•データベース、それ以外のバックアップ

•スナップショット

RMANの構成

データファイル

制御ファイル

アーカイブ

REDOログ

オンライン

REDOログ

初期化

パラメータ

ファイル

データファイル

制御ファイル

アーカイブ

_REDOログ

RMAN

サーバ

プロセス

メディア

マネージャ

クライアント

テープ・ライブラリへの

バックアップ

ディスク・バックアップ

バックアップ対象(初期化パラメータファイルはSPFILEのみ)

テープへバックアップを取得する場合、

別途、メディア管理ソフトウェアが必要

例） Oracle Secure Backup

初期化

パラメータ

ファイル

高速リカバリ領域

Program Agenda

1

2

3

4

5

はじめに

高速増分バックアップ

バックアップの運用ポリシー

RMANバックアップのチューニング

押さえておきたい注意点

高速増分バックアップ（Enterprise Edition機能）

増分バックアップ

高速増分バックアップ

（Enterprise Edition）

特徴

• データ･ファイル全体を読み込み、更新

のあったブロックをコピーする

• データの変更時に更新ブロック情報を記録

• バックアップ時は記録されたブロックのみを

読み込み

バックアップに要する

時間

全体バックアップと比較して変わらない

全体バックアップと比較して短縮可能

イメージ図

水

火

月

月

水

火

火

月

水

水

月

火

RMAN

水 水 水 水

水

火

月

月

水

火

火

月

水

水

月

火

RMAN

ブロック・チェンジ・

トラッキング・ファイル

CTWR

水

水

水

水

RMANによる高速増分バックアップ

抽出と適用の二分割により、バックアップ中の障害にも対応可能

+FRA DG

+DATA DG

バックアップ前提

運用フェーズ(バックアップ運用)

Image Bkup(level 0)

BCT File

DML

ctwr

dbwr

Data Files

全体Bkup

Bkup開始

Bkup完了

高速増分Bkup

(level 1)

増分更新

Bkup Window

BkupSet (level 1)

高速増分バックアップ

Block Change Tracking (BCT) File

•

BCT Fileは、更新されたブロック・アドレスをビットマップでバージョン管理

–

更新されたブロックだけにアクセスする

_{高速増分バックアップを実現}

–

BCT Fileのサイズは、データベースのサイズ及びRedoのスレッドの数に比例

•

初期サイズは10MBで、通常、データベースサイズの約1/30,000×ノード数

•

300GBまでは10MB、600GB時は20MB+α

–

Oracle Real Application Clusters環境もSingle Database環境と同じ設定

•

全インスタンスが読み書き可能なデバイス（例: ASM Diskgroup）上に一つだけ配置

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING

USING FILE '+FRA(CHANGETRACKING)' REUSE ;

SQL> select * from v$block_change_tracking ;

STATUS FILENAME BYTES

--- --- ---

高速増分バックアップ

BCT Fileへの書き出し

•

BCT Fileを有効化すると、Large Pool内にCTWR dba bufferを確保し、

バックグラウンド・プロセスCTWRが起動

•

BCT Fileへの書き出しの流れ

–

サーバープロセスが更新ブロック情報をCTWR dba buffer へ書き込む

–

CTWRがトランザクションと非同期でbufferから随時BCT Fileへ書き出し

•

Checkpoint時に、CTWR dba bufferとBCT Fileの間で同期が取られる

SQL> select pool,name,sum(bytes) from v$sgastat where name like 'CTWR%' group by pool,name;

large pool CTWR dba buffer 1167360

CTWR dba buffer

block change tracking buffer space待機イベント

•

サーバー・プロセスによるCTWR dba bufferへ書き出しが待たされた

場合に発生する待機イベント

–

主な要因と回避策

•

BCT Fileが配置されているストレージI/O性能のボトルネック

–

ASM上のBCT Fileへ書き出す場合は基本的に非同期I/Oの為、書込み自体の待機イベントは発生しない

–

ファイル・システム上のBCT Fileへ書き出す場合は同期I/Oの為、”db file parallel write”待機イベントも発生



BCT File

を高速ストレージ上に再配置

•

更新量が多い為に、CTWR dba bufferが枯渇



CTWR dba buffer

のサイズを拡張

(

隠しパラメータで動的にサイズ変更可能

)

Doc ID 1311518.1 Incremental Rman Backup High Waits On 'block change tracking buffer space’

BCT Fileを使用したLevel1 Backup取得時

読込みI/Oサイズの最適化

•

高速増分バックアップでは、基本的にはBCT Fileにトラッキングされた

ブロックのみを読込む

–

従来の増分バックアップよりもブロック読込み量が減少し、高速化が期待できる

–

とは言え、更新ブロックの散らばり具合により、

Multi-Block Readの方が効率的なこともあるので、

実はI/Oサイズを最適に変更して、不要ブロックも含めて読み込むことがある

物理的に歯抜けに更新されると、

Small READになりやすい

物理的に連続して更新されると、

Large READになりやすい

※ 上記はあくまでイメージ図であり、正確な動作を表すものではありません

Block Change Tracking File

補足

•

可用性

–

RMANではBCF File自体のバックアップは、されない

–

必要に応じて、ASMやRAID等で冗長化

–

BCT Fileが破損した場合、次回の増分バックアップが高速とならない

•

Image Copy Backup（Level0）は必要ありません

•

バージョニング

–

BCT Fileではデフォルト8世代分（バックアップ8回分）の更新情報を保持

•

9回目以降の累積増分バックアップでは高速とならない

RMANによる高速増分バックアップ

抽出と適用の二分割により、バックアップ中の障害にも対応可能

+FRA DG

+DATA DG

バックアップ前提

運用フェーズ(バックアップ運用)

Image Bkup(level 0)

BCT File

DML

ctwr

dbwr

Data Files

全体Bkup

Bkup開始

Bkup完了

高速増分Bkup

(level 1)

増分更新

Bkup Window

BkupSet (level 1)

増分更新バックアップ

Level1のバックアップをLevel0のバックアップに適用して運用する

•

取得済みのイメージ・コピー形式のLevel0の増分バックアップに対し、

Level1の増分バックアップで取得した内容を更新（ロール・フォワード）

•

適用すべきLevel1やArchive Logを最小化することでメディアリカバリの処理時間を短縮

A

B

C

D

E

F

A

B

H

D

E

F

G

H

G

_I

_J

レベル0の

増分バックアップ

1日目

A

B

H

D

I

F

G

J

2日目

増分更新バックアップ

3日目

レベル1の

増分バックアップ

レベル1の

増分バックアップ

A

B

C

D

E

F

A

B

C

D

E

F

A

B

H

D

E

F

G

増分適用（増分更新）

Level0 Image Copy BackupをLevel1 BackupでRoll Forward

•

適用するLevel1を制御することが可能

–

何も気にしなければ、全てのLevel1が適用されてLevel0は最新化

–

「数日前にリカバリ出来ること」という要件がある場合はUNTIL句を指定する

RMAN> # 7日前の任意の地点へリカバリできるLevel0になるようLevel1を適用

RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE'

増分適用時のI/O

Level0 Image Copy BackupをLevel1 BackupでRoll Forward

•

Level1を読み込んで、Level0へ上書き（Level0のブロックは読み込まれない）

1 2 3 4 5 6 7 8 9 10

1 5 7 10

Small I/O or Large I/O Read

Level1

を読み込んで、

Level0

の該当ブロックのみ上書き

1 2 3 4 5 6 7 8 9 10

高速増分バックアップ

増分適用

Level 0 Image Copy Backup

Level 1 Backup

Program Agenda

1

2

3

4

5

はじめに

高速増分バックアップ

バックアップの運用ポリシー

RMANバックアップのチューニング

押さえておきたい注意点

増分バックアップの種類

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

•

マルチレベル増分バックアップ

各バックアップの増分開始SCN

増分バックアップのアルゴリズム（増分適用によるLevel0の変化を見逃しがち）

•

増分開始SCN

–

増分バックアップの対象となる最小のSCN

•

このSCNよりも大きなSCNが記録されたブロックが増分バックアップされることになる

–

差分増分バックアップ

•

最新のLevel1バックアップのCheckpoint SCN

–

累積増分バックアップの起点

•

最新のLevel0バックアップのCheckpoint SCN

•

Level0にLevel1を適用すると、Level0のCheckpoint SCNはLevel1のものに置き換わっていることに注意

–

つまり、

累積増分バックアップ前に増分適用をした場合、差分増分バックアップと同じ範囲

_となる

–

万が一、Level1が破損していて増分適用が失敗した場合、差分増分ではバックアップ・ジョブを止めて、

手動で累積増分に変更する必要があるが、累積増分バックアップではその手間が発生しないメリット有り

正しく理解しておくべき構文

FOR RECOVER OF COPY と WITH TAG

•

BACKUP INCREMENTAL LEVEL 1 CUMULATIVE

FOR RECOVER OF COPY

WITH TAG 'INCR_UPDATE'

DATABASE ;

–

FOR RECOVER OF COPY

•

Level0 Image Copy Backupが存在しない場合、Level0 Image Copy Backupが取得される

•

Level0 Image Copy Backupが存在する場合、Level1 Backupsetが取得される

–

運用の中で新規表領域が追加された場合でも、

_{バックアップ・スクリプトの改修が不要}

•

この句を指定せずに、Level0 Backupが存在しない場合には、Level0 Backupsetが取得される

–

Level0 Backupsetは増分適用対象にはならないので注意

–

WITH TAG

•

増分バックアップの増分開始SCNを決める上で、Level0のバックアップを識別する為に必須

増分適用とバックアップ実行のタイミング

これが意外と難しい。でも、Recovery Applianceならば考える必要が無くなる！！

•

例えば、毎日22時にバックアップ・ジョブを実行

1.

22:00に、UNTIL 'SYSDATE-1'を指定して増分適用を試行

2.

22:10～22:30で高速増分バックアップ（当日分のLevel1）を取得

※

_{この場合、22:00の増分適用時には、昨日のLevel1は適用されない}

•

昨日のLevel1は22:30時点のものなので、当たり前と言えば当たり前。

•

もし、これが適用されてしまうと、Level0は昨日の22:30以降の時点リカバリにしか使用できません

•

増分適用実行時（本日の22:00）の24時間前（昨日の22:00）にリカバリ不可になってしまう

–

昨日のLevel1は削除できないことになるので、保持されるLevel1の数を

リカバリ・ウィンドウ要件に“＋１“したFRA（高速リカバリ領域）の容量設計が必要

オンラインで取得したバックアップの中には、

バックアップ期間中に更新されたブロックも含まれる

バックアップの開始地点ではなく、終了地点以降のリカバリで使用可能

+FRA DG

+DATA DG

高速増分バックアップ

DML

dbwr

Data Files

SCN:300

22:10

Bkup開始

Bkup完了

最新Level1（SCN:300）

SCN:310

22:20

SCN:320

22:30

増分適用（ UNTIL 'SYSDATE-1' ）

Level0 Image Copy Backup

SCN:100

増分適用

バックアップ期間中（SCN=310）に更

新されたブロック（緑色）も含まれて

いる為、SCN=320（22:30）以降の

時点へのリカバリにしか使用不可

前回Level1(SCN:200）

前回Level1（SCN:200）

Level0

SCN:200

翌22:00

高速リカバリ領域/ Fast Recovery Area (FRA)

•

バックアップ関連のファイルを配置するディスク領域

•

高速リカバリ領域に保存されたバックアップは必要

に応じて削除されます

–

管理者の指定した「

保存方針

_{」により不要となった}

バックアップ、アーカイブREDOログファイルなど

•

初期化パラメータファイルにて設定

–

位置： DB_RECOVERY_FILE_DEST

–

サイズ：DB_RECOVERY_FILE_DEST_SIZE

•

Oracle Databaseを構成するファイル群が格納されて

いるディスクとは別のディスクへ配置

Oracle Database

高速リカバリ領域

アーカイブ・ログ

バックアップセット

イメージ・コピー

制御ファイル

REDOログファイル

制御ファイル

REDOログファイル

データファイル

初期化パラメータファイル

多重化

高速リカバリ領域/ Fast Recovery Area (FRA)

サイジング考え方

リカバリ対象

コメント

制御ファイル/アーカイ

ブログファイル

バックアップ間で生成されるアーカイブログ全体サイズの推

定x 2

フラッシュバックログ

(Redo量 xフラッシュバックできる時間の上限) x 2

イメージコピー

データベースサイズから一時ファイルのサイズを除く

バックアップセット (full)

全体バックアップの数 x 推定サイズ

増分バックアップ

増分バックアップの数

_*

_{x 推定サイズ}

* リカバリ可能とする日数”+1日”を忘れがちです!!

例えば、一週間以内の任意の地点へリカバリする要件であれば、8日分

FRAと二つのポリシー設定

FRA上のファイルの自動削除

•

FRAの空き領域が不足した場合、次の順序に従ってファイルを自動削除

1. Flashback Logs

•

最も古いものから（db_flashback_retention_targetは保証されない）

ただし、保証付きリストア・ポイント用のFlashback Logは必ず保持する

2. RMAN backup pieces/copies and archived logs

•

BACKUP RETENTION POLICY

で保持する必要が無くなったもの

もしくは、Tapeやバックアップ用Diskへ複製済みのもの

•

ARVHIVELOG DELETION POLICY

が設定されていれば、

BACKUP RETENTION POLICY（保持ポリシー）

バックアップ（Archive Logを含む）の保存方針を設定

•

リカバリ期間、もしくは冗長性の

どちらか一方

_を設定

•

方針を満たさない

_{バックアップは削除対象として扱われる}

–

リカバリ期間

•

現時点からリカバリ可能時点までの日数

–

冗長性（

高速増分バックアップの運用では、こちらが推奨

_）

•

各データファイル及び制御ファイルの全体、又はLevel0のバックアップの数

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

増分更新バックアップの保持ポリシーは冗長性を推奨

Doc ID 463875.1 Frequently asked questions on Rman backup retention policy

•

増分更新バックアップ機能を使用している場合は、

以下の方法でバックアップファイルを管理すること

–

冗長性を指定したBACKUP RETENTION POLICY

(デフォルト1世代分) を使用

–

これにより、Level 0を更新するために使用したLevel 1を削除対象となる

•

リカバリ期間を指定すると、不要なLevel1が残り続けてしまう

–

Level 0にLevel 1を適用してロール・フォワードする

RECOVERコマンド実行時には、

この保存ポリシーは考慮されない

_{為、RECOVERコマンドにUNTIL句を追加し、}

Level0を増分更新する時点を指定

ARCHIVELOG DELETION POLICY

Archive Logの削除方針を設定

•

Archive Logがディスクからの削除対象となる

複数条件

を設定可能

•

方針を満たす

_{Archive Logが削除対象となる}

–

Archive Logバックアップの数 とバックアップ先

–

Standby Database側への転送済み、又は適用済み

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP <#> TIMES

TO DEVICE TYPE [DISK | SBT] ;

CONFIGURE ARCHIVELOG DELETION POLICY TO [SHIPPED | APPLIED]

ON [ALL] STANDBY ;

Archive Logの削除コマンド

BACKUP RETENTION POLICY & ARCHIVELOG DELETION POLICY

•

Archive Logを削除するRMANコマンドは次の二つであり、

バージョン毎に動作が異なる

RMAN Command

Release

BACKUP

RETENTION POLICY

ARCHIVELOG

DELETION POLICY

DELETE

ARCHIVELOG ALL;

共通

×

○

DELETE OBSOLETE;

（Archive Log以外も削

除対象）

~11.2.0.3

○

×

11.2.0.4~

○

○

Archive Logの削除例

DELETE OBSOLETE ; (11.2.0.4～)

•

BACKUP RETENTION POLICYとARCHIVELOG DELETION POLICYの両方の

設定に従って、Archive Logが削除されるコマンド

–

例：全Standby Databaseで適用済み、かつ、1度以上Diskへバックアップ済みの

Archive Logを削除するポリシー設定の例

RMAN> # 各POLICYの設定

CONFIGURE RETENTION POLICY TO REDUNDANCY 1 ;

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL

STANDBY BACKED UP 1 TIMES TO DEVICE TYPE DISK ;

RMAN> # 両POLICYの設定に従ったArchive Logの削除(バックアップも対象)

DELETE OBSOLETE ;

DELETE OBSOLETEコマンド

動作の補足

•

DELETE OBSOLETEコマンドの削除対象

–

Archive Logだけでは無く、BACKUP RETENTION POLICYの

設定によって不要と判断されたImage Copy/Backupsetも対象

•

Archive LogをFast Recovery Area（FRA）に配置した場合

–

FRAの空き容量が十分で削除の必要が無い場合は、削除対象のArchive Logで

あっても本コマンドによって削除されない

•

バックアップ済みのArchive Logは一旦リストア処理が必要となる為、残しておいた方がメリット有り

–

確実に不要なArchive Logを削除する為には、DELETE ARCHIVELOGコマンドに

Sample Backup Script 1 – (1)

日曜日はフルバックアップ& 月～土曜日は高速増分バックアップ（累積）

Recovery Window: 1日間

→ Level0が 2世代分のFRA領域が必要

RMAN> #事前設定

CONFIGURE RETENTION POLICY TO REDUNDANCY 2 ; # Level0が２世代となる為

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY

BACKED UP 1 TIMES TO DEVICE TYPE DISK ; # Data Guard環境を想定

CONFIGURE COMPRESSION ALGORITHM 'LOW' ; # ArchiveLog Backup用

RMAN> #日曜日のフルバックアップ

run{

RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE' UNTIL TIME 'SYSDATE-1' ;

DELETE NOPROMPT OBSOLETE ; # 不要なバックアップ、Archive Logを削除

BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'INCR_UPDATE' ;

Sample Backup Script 1 – (2)

日曜日はフルバックアップ& 月～土曜日は高速増分バックアップ（累積）

Recovery Window: 1日間

→ Level0が 2世代分のFRA領域が必要

RMAN> #月～土曜日の高速増分バックアップ

run{

RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE' UNTIL TIME 'SYSDATE-1' ;

DELETE NOPROMPT OBSOLETE ; # 不要なバックアップ、Archive Logを削除

BACKUP INCREMENTAL LEVEL 1 cumulative FOR RECOVER OF COPY

WITH TAG 'INCR_UPDATE' DATABASE ;

BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL TAG 'INCR_UPDATE' ;}

日曜日のバックアップ開始～火曜日のバックアップ開始までの間、

Level0 Image Copy Backupを2世代持ちになる為、FRAの容量設計に注意

Sample Backup Script 2

毎日、高速増分バックアップ（差分）、Recovery Window: 7日間、Backup Window: 1時間

→ 1世代のBackup

RMAN> #事前設定

CONFIGURE RETENTION POLICY TO REDUNDANCY 1 ; # Level0が1世代となる為

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY

BACKED UP 1 TIMES TO DEVICE TYPE DISK ; # Data Guard環境を想定

CONFIGURE COMPRESSION ALGORITHM 'LOW' ; # ArchiveLog Backup用

RMAN> #毎日の高速増分バックアップ（増分適用処理、Level0の破損チェック含む）

run{

RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE' UNTIL TIME 'SYSDATE-(7+1/24)' ;

VALIDATE CHECKLOGICAL DATAFILECOPY ALL NODUPLICATES DEVICE TYPE DISK ;

DELETE NOPROMPT OBSOLETE ;

BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY

WITH TAG 'INCR_UPDATE' DATABASE ;

Sample Backup Script 3 – (1)

毎日、高速増分バックアップ（累積）

Recovery Window: 7日間

→ 2世代（最新のLevel0 & 過去7日以内にリカバリ可能なLevel0+Level1）

RMAN> #事前設定

CONFIGURE RETENTION POLICY TO REDUNDANCY 2 ; # Level0が2世代となる為

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY

BACKED UP 1 TIMES TO DEVICE TYPE DISK ; # Data Guard環境を想定

CONFIGURE COMPRESSION ALGORITHM 'LOW' ; # ArchiveLog Backup用

RMAN> #初めてのバックアップ

run{

BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'NEWEST' ;

BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'BEFORE7DAYS' ;

Sample Backup Script 3 – (2)

毎日、高速増分バックアップ（累積）

Recovery Window: 7日間

→ 2世代（最新のLevel0 & 過去7日以内にリカバリ可能なLevel0+Level1）

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' ;}

 毎日の高速増分バックアップで共通のLevel1バックアップを取得し、

2つのLevel0 Image Copy Backupが7日間のズレを維持したまま毎日ロールフォワードされていく

もしもの障害時にはリカバリ目標地点をUNTIL句で指定したRESTOREコマンドの実行が必要

Recovery Managerリポジトリとリカバリ・カタログ

複数のOracle Databaseのバックアップ状況を一元管理

•

Recovery Managerリポジトリ

–

Recovery Managerがバックアップ、リカバリおよびメンテナンスに使用する、

ターゲット・データベースに関するメタデータのコレクション

–

制御ファイルに格納（領域に制限有り）

•

初期化パラメータファイル：CONTROL_FILE_RECORD_KEEP_TIME（デフォルト7日）

•

リカバリ・カタログを作成し、リポジトリを長期間保存可能

–

複数のOracle Databaseのバックアップ状況を一元管理できます

制御ファイル

ターゲット・

データベース

制御ファイル

ターゲット・

データベース

制御ファイル

ターゲット・

データベース

カタログ・

_スキーマ

リポジトリ用途

は無償

カタログ・データベース

•

メリット

–

長期間、バックアップのメタデータを保持することが可能

 NOCATALOGモード時は、

CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータの設定に依存

–

複数データベース環境の統合バックアップ環境

–

KEEP FOREVER句の使用が可能

–

Data Guard環境においてサイト間での柔軟なリストアを実現

•

Primaryの制御ファイルのバックアップをStandby側へリストアする際に、全データ・ファイルのパスを適

切に自動変換してリストアしてくれる

•

カタログ・データベースは無償、EMのレポジトリと同じサーバー上に配置可

CONTROL_FILE_RECORD_KEEP_TIME

Doc ID 1734969.1 / KROWN#120064

•

CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータ

–

デフォルト：7（単位：日）、指定可能な範囲：0~365

•

NOCATALOG モードで運用している場合に設定値を検討する

–

バックアップ・セット情報等のRMANに必要な情報は制御ファイルに格納

–

上記パラメータの設定期間を経過後は上書き対象

•

RMANの保存ポリシーは無視されてしまうので、リカバリ・ウィンドウの日数以上に設定する必要有り

–

例：過去2週間以内の任意の地点へリカバリする要件があれば、最低でも15（日）を設定

Program Agenda

1

2

3

4

5

はじめに

高速増分バックアップ

バックアップの運用ポリシー

RMANバックアップのチューニング

押さえておきたい注意点

RMANによるバックアップ作成フロー

Overview

•

読取りフェーズ

–

RMANチャネル（サーバー・プロセス）がDiskから

入力バッファ

へブロックを読み込む

•

コピー・フェーズ

–

RMANチャネルが入力バッファから出力バッファへブロックをコピーする

–

ここで、ブロックに対する

追加処理

_{が行われる}

•

必要に応じて検証/圧縮/暗号化の実行

•

書込みフェーズ

–

RMANチャネルが

出力バッファ

からストレージ(Disk or SBT)へブロックを書き出す

RMANによるバックアップ作成フロー

イメージ

Read

Write

Copy

Restore処理は逆フロー

Tuning Principles

1. StorageのI/O性能、Networkスループットの限界を把握

•

RMAN Backupチューニング前に環境のI/O性能を測定

–

Oracle ORION Calibration Tool

http://docs.oracle.com/cd/E16338_01/server.112/b56312/iodesign.htm#CACJEEDI

•

Oracleをインストールせずに、OracleデータベースのI/O性能を測定可能

–

Oracleと同じI/O Stackを使用して、I/Oワークロードをシミュレート

•

Level0 Image Copy Backup  ex. 1MB Large I/O

•

Level1 Backup  ex. 32KB Small I/O

–

「 qperf 」などのTCP/IP ベンチマークツールで測定

Tuning Principles

2. 最適な性能を引き出すDiskの構成

•

Automatic Storage Management（ASM）の場合

–

一般的には、DATAとFRAのDiskは分ける構成

–

もし、DATAとFRAがDiskを共有する場合

•

高速な外周にDATA Diskgroupを配置

•

低速な内周にFRA Diskgroupを配置

–

一般的な性能差は15~25%（1MB Sequential Write)

•

ASMを使わない場合

Tuning Principles

3. デバイス性能を最大限に活用する為のRMAN側の設定

•

非同期I/Oを使用

–

もし、プラット・フォームで非同期I/Oがサポートされていない場合、

Oracleは非同期I/Oをシミュレートする仕組みが実装されている

•

ディスクへのバックアップ: 初期化パラメータ DB_IO_SLAVES を0以外に設定する

•

テープへのバックアップ: 初期化パラメータ BACKUP_TAPE_IO_SLAVES をTRUEにする

•

Channel数の割り当て

–

ディスクへのバックアップ: I/O性能が最大になるようにChannel数を増やす

•

Channelの数はストライプ化されたディスクの数を最大とする

•

Image Copy Backupでは、一つのChannelは同時に一つのData Fileを扱う

自動チャネル割り当て

Channel数とH/Wリソース

•

Channel（サーバー・プロセス）を複数起動して、バックアップを並列化

–

特に、Level0 Image Copy Backupでは一つのChannelが一つのData Fileを

バックアップする為、高速化のためには複数起動が望ましい

–

一つのChannelでは一つのCPUコアしか使用できない

•

Channelの複数起動  複数CPUコアの使用

•

Channelの単一起動  Backupのオーバーヘッド（CPUやI/O消費）の低減

RMAN> # Diskデバイス用のチャネルのパラレル化（自動チャネル割り当て）

CONFIGURE DEVICE TYPE DISK PARALLELISM <n> ;

自動チャネル割り当て

Doc ID 1734142.1 / KROWN#109790 RAC環境でのチャネル割り当てについて

•

各インスタンスのH/Wリソースを使用してバックアップの実行が可能

–

設定例：2ノードRACで、インスタンス毎に2つのChannel割り当て（合計4つ）

$ rman target /

RMAN> # Diskデバイス用のチャネルのパラレル化（自動チャネル割り当て）

CONFIGURE DEVICE TYPE DISK PARALLELISM 4 ;

CONFIGURE CHANNEL 1 DEVICE TYPE DISK CONNECT 'sys@orcl1';

CONFIGURE CHANNEL 2 DEVICE TYPE DISK CONNECT 'sys@orcl1';

CONFIGURE CHANNEL 3 DEVICE TYPE DISK CONNECT 'sys@orcl2';

CONFIGURE CHANNEL 4 DEVICE TYPE DISK CONNECT 'sys@orcl2';

$ rman target sys/<password>

RMAN> # 事前設定された自動チャネル割り当てを使用したLevel0 Image Copy Backup

BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'INCR_UPDATE' ;

事前設定時には

パスワード不要

ただし、実際にChannel

を使用する際、

パスワードを明示指定

したTarget接続が必須

数値のみ

指定可能

手動チャネル割り当て

Doc ID 1734142.1 / KROWN#109790 RAC環境でのチャネル割り当てについて

•

事前にCONFIGUREコマンドで設定せずに、run{}内で手動割り当て

–

設定例：2ノードRACで、インスタンス毎に2つのChannel割り当て（合計4つ）

–

run{}内のALLOCATE CHANNELコマンドで設定した値は、run{}内でのみ有効

$ rman target sys/<password>

RMAN> run{

ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT 'sys@orcl1';

ALLOCATE CHANNEL ch2 DEVICE TYPE DISK CONNECT 'sys@orcl1';

ALLOCATE CHANNEL ch3 DEVICE TYPE DISK CONNECT 'sys@orcl2';

ALLOCATE CHANNEL ch4 DEVICE TYPE DISK CONNECT 'sys@orcl2';

BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'INCR_UPDATE' ;}

文字列

指定可能

Tuning Principles

4.バックアップの検証を使用した読取りと書込みのボトルネックの識別

•

バックアップ・ジョブで出力デバイスまたは入力ディスクI/Oのどちらがボトルネックになっているかを確認する方法と

してバックアップ・タスクの実行時間と、バックアップの検証(BACKUP VALIDATE)の実行時間を比較することがある

–

BACKUP VALIDATEは、ディスク読取りを実行するが、出力デバイスに対するI/Oはしない

•

バックアップ時間と検証時間を比較する手順

1.

NLS環境の日付書式変数の設定

•

setenv NLS_LANG AMERICAN_AMERICA.WE8DEC;

•

setenv NLS_DATE_FORMAT "MM/DD/YYYY HH24:MI:SS"

2.

BACKUPコマンドでなくBACKUP VALIDATEコマンドを使用するようにバックアップ・スクリプトを編集し実行

•

Starting backup atとFinished backup atに間の時間を計算

3.

BACKUP VALIDATEコマンドでなくBACKUPコマンドを使用するようにバックアップ・スクリプトを編集し実行

•

Starting backup atとFinished backup atに間の時間を計算

4.

検証と実際のバックアップで時間を比較

•

BACKUP VALIDATEの時間が、実際のバックアップの時間とほとんど変わらない場合は、読取りがボトルネックになっている可能性がある

–

「読取りフェーズのチューニング」

•

BACKUP VALIDATEの時間が、実際のバックアップの時間より大幅に短い場合は、出力デバイスへの書込みがボトルネックになっている可能性がある

読取りフェーズのチューニング

Doc ID 1072545.1 RMAN Performance Tuning Using Buffer Memory Parameters

•

ASM環境におけるBufferは最適な性能が得られるように自動設定

–

Channel（サーバー・プロセス）毎に、入力バッファがPGAに割り当てられる

–

Bufferの数

•

サーバー・プロセスが同時に発行出来る非同期I/O数

•

ASM DiskgroupのDisk数に応じて自動調整

–

一つのBufferのサイズ

•

サーバー・プロセスが発行する非同期I/Oの最大I/Oサイズ

Input/Output Bufferの数とサイズの確認

V$BACKUP_ASYNC_IO / GV$BACKUP_ASYNC_IO

SQL> set linesize 300 pagesize 500

col TYPE for a9

col STATUS for a12

col FILENAME for a65

col TOTAL_MB for 999,999,999

alter session set NLS_DATE_FORMAT='MM/DD HH24:MI:SS';

select INST_ID, USE_COUNT, OPEN_TIME, CLOSE_TIME, SID, TYPE, STATUS,

ELAPSED_TIME/100 "ELPD(SEC)",

BUFFER_SIZE

,

BUFFER_COUNT

,

TOTAL_BYTES/1024/1024 "TOTAL_MB",

IO_COUNT, READY, SHORT_WAITS, LONG_WAITS,

FILENAME

from GV$BACKUP_ASYNC_IO

where OPEN_TIME > to_date('11/27 13:00:00') -- Backup開始日時を指定すると便利

order by INST_ID, USE_COUNT, TYPE ;

Input/Output Bufferの数とサイズの確認

GV$BACKUP_ASYNC_IO in Level0 Image Copy Backups with 2node

INST_ID USE_COUNT OPEN_TIME CLOSE_TIME SID TYPE STATUS ELPD(SEC) BUFFER_SIZE BUFFER_COUNT TOTAL_MB EMBPS IO_COUNT READY SHORT_WAITS LONG_WAITS FILENAME

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 1 1 02/27 11:24:56 02/27 11:26:26 200 AGGREGATE UNKNOWN 90 0 0 68 6146 3512 0 2634

1 1 02/27 11:24:56 02/27 11:26:26 200 INPUT FINISHED 90 1048576 24 6,144 68 6146 3512 0 2634 +DATA/orcl/datafile/jpet.271.xxx 1 1 02/27 11:24:55 02/27 11:26:26 200 OUTPUT FINISHED 91 1048576 24 67 0 0 0 0 +FRA/orcl/datafile/jpet.386.xxx 1 2 02/27 11:24:52 02/27 11:26:03 15 AGGREGATE UNKNOWN 71 0 0 47 3352 2018 0 1334

1 2 02/27 11:24:52 02/27 11:26:03 15 INPUT FINISHED 71 1048576 24 3,350 47 3352 2018 0 1334 +DATA/orcl/datafile/sysaux.260.xxx 1 2 02/27 11:24:50 02/27 11:26:03 15 OUTPUT FINISHED 73 1048576 24 45 0 0 0 0 +FRA/orcl/datafile/sysaux.607.xxx 1 3 02/27 11:26:28 02/27 11:26:36 15 AGGREGATE UNKNOWN 8 0 0 80 643 391 0 252

1 3 02/27 11:26:28 02/27 11:26:36 15 INPUT FINISHED 8 1048576 24 641 80 643 391 0 252 +DATA/orcl/datafile/users.279.xxx 1 3 02/27 11:26:28 02/27 11:26:38 15 OUTPUT FINISHED 10 1048576 24 64 0 0 0 0 +FRA/orcl/datafile/users.646.xxx 1 4 02/27 11:26:49 02/27 11:26:51 200 AGGREGATE UNKNOWN 2 0 0 128 258 143 0 115

1 4 02/27 11:26:49 02/27 11:26:51 200 INPUT FINISHED 2 1048576 24 256 128 258 143 0 115 +DATA/orcl/datafile/tbs64k.268.xxx 1 4 02/27 11:26:49 02/27 11:26:51 200 OUTPUT FINISHED 2 1048576 24 128 0 0 0 0 +FRA/orcl/datafile/tbs64k.661.xxx 1 5 02/27 11:26:56 02/27 11:26:57 200 AGGREGATE UNKNOWN 1 0 0 256 258 152 0 106

1 5 02/27 11:26:56 02/27 11:26:57 200 INPUT FINISHED 1 1048576 24 256 256 258 152 0 106 +DATA/orcl/datafile/tbs4m.257.xxx 1 5 02/27 11:26:56 02/27 11:26:58 200 OUTPUT FINISHED 2 1048576 24 128 0 0 0 0 +FRA/orcl/datafile/tbs4m.373.xxx 1 6 02/27 11:26:58 02/27 11:26:59 15 AGGREGATE UNKNOWN 1 0 0 100 102 61 0 41

1 6 02/27 11:26:58 02/27 11:26:59 15 INPUT FINISHED 1 1048576 24 100 100 102 61 0 41 +DATA/orcl/datafile/tbs100.259.xxx 1 6 02/27 11:26:58 02/27 11:26:59 15 OUTPUT FINISHED 1 1048576 24 100 0 0 0 0 +FRA/orcl/datafile/tbs100.645.xxx 1 7 02/27 11:27:02 02/27 11:27:02 200 AGGREGATE UNKNOWN 0 0 0 21 22 20 2 0

1 7 02/27 11:27:02 02/27 11:27:02 200 INPUT FINISHED 0 1048576 16 21 22 20 2 0 /u01/app/oracle/product/11.2.0/xxx 1 7 02/27 11:27:02 02/27 11:27:02 200 OUTPUT FINISHED 0 1048576 10 21 19 0 2 +FRA/orcl/autobackup/2014_02_27/xx 2 1 02/27 11:24:43 02/27 11:25:10 16 AGGREGATE UNKNOWN 27 0 0 37 1026 601 0 425

2 1 02/27 11:24:43 02/27 11:25:10 16 INPUT FINISHED 27 1048576 20 1,024 37 1026 601 0 425 +FRA/orcl/datafile/undotbs1.xxx 2 1 02/27 11:24:43 02/27 11:25:12 16 OUTPUT FINISHED 29 1048576 20 35 0 0 0 0 +FRA/orcl/datafile/undotbs1.336.xxx 2 2 02/27 11:24:45 02/27 11:25:14 15 AGGREGATE UNKNOWN 29 0 0 35 1026 571 0 455

2 2 02/27 11:24:45 02/27 11:25:14 15 INPUT FINISHED 29 1048576 20 1,024 35 1026 571 0 455 +FRA/orcl/datafile/undotbs2.383.xxx 2 2 02/27 11:24:44 02/27 11:25:15 15 OUTPUT FINISHED 31 1048576 20 33 0 0 0 0 +FRA/orcl/datafile/undotbs2.652.xxx 2 3 02/27 11:26:31 02/27 11:26:48 16 AGGREGATE UNKNOWN 17 0 0 60 1026 494 0 532

2 3 02/27 11:26:31 02/27 11:26:48 16 INPUT FINISHED 17 1048576 20 1,024 60 1026 494 0 532 +FRA/orcl/datafile/undotbs3.411.xxx 2 3 02/27 11:26:30 02/27 11:26:48 16 OUTPUT FINISHED 18 1048576 20 56 0 0 0 0 +FRA/orcl/datafile/undotbs3.537.xxx 2 4 02/27 11:26:30 02/27 11:26:44 15 AGGREGATE UNKNOWN 14 0 0 55 772 476 0 296

2 4 02/27 11:26:30 02/27 11:26:44 15 INPUT FINISHED 14 1048576 24 770 55 772 476 0 296 +DATA/orcl/datafile/system.270.xxx 2 4 02/27 11:26:29 02/27 11:26:45 15 OUTPUT FINISHED 16 1048576 24 48 0 0 0 0 +FRA/orcl/datafile/system.428.xxx

Input or Outputを判別

可能

一つのBufferサイズ

読取りフェーズのチューニング

•

基本的には、RMANチャネル数を増加させることで対処可能

–

ASM環境であれば、最適なBufferの数とサイズに自動調整されている

•

DiskのI/O性能を全て引き出せてない 、

かつ、CPUやMemoryに空きがある場合に限り、

入力バッファの数とサイズを増加させることが可能

–

ただし、隠しパラメータにつき、サポートの指示に従って設定して下さい

•

次のDoc内のPDFファイル（rman_buffer.pdf）を参照

読取りフェーズのチューニング

•

多重化のレベルの調整

特に高速増分ではない増分バックアップのときに検討

ASM ストライプ化されたディスク 推奨事項

なし

あり

多重化のレベルを上げます。MAXOPENFILESまたは各バックアップ・セット内の

ファイル数のいずれが最小値かを確認してから、この値を増やす

RMANがテープ・バッファを一杯にする速度を上げ、ストリームを継続するのに

十分な速度でバッファがメディア・マネージャに送信される確率を高くする

なし

なし

チャネル上のMAXOPENFILES設定値を増やす

あり

該当なし

チャネルのMAXOPENFILESパラメータを1または2に設定する

コピー・フェーズ

RMAN バックアップ時の検証/圧縮/暗号化ガイドライン

•

CPUリソースを非常に消費する処理のため、CPU増設もしくは下記を実施

–

Compression: 圧縮レベルを下げる(LOW / MEDIUM)(要：Advanced Compression)

–

TDE 列暗号化: 2重暗号化なので、RMAN側は暗号化しない

–

TDE 表領域暗号化:

•

Compressed & Encrypted backupの場合、

暗号化された表領域は復号された後、圧縮

_{再度暗号化される動作となる為、}

圧縮しないことを検討

•

その場合、暗号化されたブロックのままバックアップされる

–

ブロック検証:

•

デフォルトでPhysical Corruptionのチェックが実行される

•

通常、この処理ではCPUに負荷はかからない

コピー・フェーズ

ブロック検証(物理破損検証)

•

デフォルトで有効化（推奨）

–

NOCHECKSUMオプションで無効化が可能

–

ただし、Blockヘッダやフッターの物理的な整合性チェックは無効化不可

•

読込み元ブロックに対して、埋め込まれているチェックサムを検証

–

DB_BLOCK_CHECKSUM初期化パラメータの設定に依存

•

FALSEの場合  SYSTEM表領域のみ

•

TYPICAL or FULLの場合  全表領域が対象

–

http://www.oracle.com/webfolder/technetwork/jp/ondemand/ddd2013/C-2.pdf

(

参照資料

)

•

書込み先ブロックに対して、チェックサムを計算して埋め込む

–

DB_BLOCK_CHECKSUM初期化パラメータの設定には依存しない

コピー・フェーズ

ブロック検証(論理破損検証)

•

デフォルト無効で、 CHECK LOGICALオプションで有効化が可能

–

読込み元ブロックに対して、物理破損検証を通過したブロック

（表、索引セグメント）の論理的な破損の有無をチェック

–

通常1～3%のオーバーヘッドが付加される（マニュアルより）

•

BACKUPコマンドだけではなく、以下のコマンドでも追加指定が可能

RMAN Command

Description

VALIDATE …

バックアップ、データファイル等の検証コマンド

Corruption(破損)検出時の動作

SET MAXCORRUTコマンド

•

バックアップ、リストア中にデータファイルに許容される

物理破損、論理破損の合計数

–

デフォルト設定は0（ゼロ）で、一つの破損も許容しない

•

破損検出時は、バックアップ or リストアがその時点で終了

–

デフォルト以外へ変更することで、

•

破損の合計数が設定値以下の場合は最後まで実行される

–

高速増分バックアップ（差分）の場合、

再度同じLevel1を取得することが難しい（累積増分バックアップやSCN指定のバックアップが必須となる）

–

破損ブロックはV$DATABASE_BLOCK_CORRUPTIONビューで確認可能

•

RECOVERコマンドでブロック単位での修復後、再度バックアップを取得するのが望ましい

書込みフェーズ

•

Channel毎に割り当てられるバックアップの書き出し用のBuffer

–

Defaultの設定

•

バッファ数：一つのChannelに4つの出力バッファが割り当てられる

•

バッファサイズ：Disk1MB / SBT  256KB

–

Set BLKSIZE channel parameter >= media mgmt client buffer size

–

Oracle Secure Backupの場合は変更の必要なし

•

ASM Diskgroupへの書き出しに関しては、

書込みフェーズチューニング

•

入力バッファと同様に、

書込み先ストレージのI/O性能を全て引き出せてない場合、

RMAN 出力バッファの数とサイズを増加させて対処させることが可能

–

ただし、隠しパラメータにつき、サポートの指示に従って設定して下さい

•

次のDoc内のPDFファイル（rman_buffer.pdf）を参照

–

Doc ID 1072545.1 RMAN Performance Tuning Using Buffer Memory Parameters

非同期I/Oのデータ読込み性能の確認（1）

Query V$BACKUP_ASYNC_IO / GV$BACKUP_ASYNC_IO

SQL> set linesize 300 pagesize 500

col TYPE for a9

col STATUS for a12

col FILENAME for a65

col TOTAL_MB for 999,999,999

alter session set NLS_DATE_FORMAT='MM/DD HH24:MI:SS';

select INST_ID, USE_COUNT, OPEN_TIME, CLOSE_TIME, SID, TYPE, STATUS,

BUFFER_SIZE, BUFFER_COUNT,

ELAPSED_TIME/100 "ELPD(SEC)"

,

TOTAL_BYTES/1024/1024 "TOTAL_MB", EFFECTIVE_BYTES_PER_SECOND,

IO_COUNT, READY, SHORT_WAITS, LONG_WAITS

,

FILENAME

from GV$BACKUP_ASYNC_IO

where OPEN_TIME > to_date('11/27 13:00:00') -- Backup開始日時を指定すると便利

order by INST_ID, USE_COUNT, TYPE ;

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

非同期I/Oのデータ読込み性能の確認（2）

V$BACKUP_ASYNC_IO

•

EFFECTIVE_BYTES_PER_SECOND列

–

Image Copy Backup時にのみ

出力

–

TOTAL_BYTES / ELAPSED_TIMEの計算結果で、秒間のスループット値

•

TOTAL_BYTES列: バックアップ対象のデータファイルのサイズ（単位:Byte）

•

ELAPSED_TIME列: バックアップに要した時間（単位:10msec）

–

この値がOracle ORIONを使用した検証結果よりも小さい場合

 ストレージに余力があるので、ChannelやBufferのチューニングを施す

•

ただし、同一Disk上のデータファイルを複数Channelで同時にバックアップした場合は、

それらの合計値で比較する必要有り

非同期I/Oのデータ読込み性能の確認（2）

V$BACKUP_ASYNC_IO

•

応答時間（長い順）: LONG_WAITS > SHORT_WAITS > READY

–

処理中でも出力されるので、進捗確認にも使用可能

Column Name

Description

IO_COUNT

そのデータファイルをバックアップする為に発行した全ての非同期I/O数

READY

待機することなくBufferが使用可能であった非同期I/Oの回数

SHORT_WAITS

Bufferが直ぐに使用可能にならなかったが、I/O完了の為のnonblocking

pollを実行した後に使用可能となった非同期I/Oの回数

LONG_WAITS

Bufferが直ぐに使用可能にならず、さらにblocking待機（AIOWAIT Call）後

に使用可能となった非同期I/Oの回数

非同期I/Oのデータ読込み性能の確認（3）

Doc ID 1736981.1 / KROWN#122407 Recovery Managerのセッションの監視

•

LONG_WAITS + SHORT_WAITS が IO_COUNTに対して高い割合

 ストレージのI/O性能がボトルネックになっている可能性有り

–

ただし、ELAPSED_TIME列と比較して、SHORT_WAIT_TIME_TOTALの値が低い場合、

遅延の原因が別の要因(プロセスのスワッピングなど)にある可能性

•

非同期I/Oの特徴

–

非同期処理は複数のタスクを同時発生させる

–

OracleのI/Oは、各I/O要求の完了を知るロジックとして

ポーリングを使用（割り込みメカニズムではない）

非同期I/Oのデータ読込み性能の確認（4）

V$IOSTAT_FUNCTION_DETAIL

•

File Type毎の詳細なI/O統計(I/Oサイズの確認が可能)

–

RMAN処理を挟む形で2回取得することで差分を抽出する

主要なColumn Name

Description

FUNCTION_NAME

RMAN、DBWR、LGWR等の識別が可能

FILETYPE_NAME

File Typeの識別が可能

SMALL_READ_MEGABYTES / REQS

Small I/O sizeの読取りリクエストMB / 数

SMALL_WRITE_MEGABYTES / REQS

Small I/O sizeの書込みリクエストMB / 数

LARGE_READ_MEGABYTES / REQS

Large I/O sizeの読取りリクエストMB / 数

LARGE_WRITE_MEGABYTES / REQS

Large I/O sizeの書込みリクエストMB / 数

NUMBER_OF_WAITS

同期I/O待機数

V$IOSTAT_FUNCTION_DETAIL

Where FUNCTION_NAME = 'RMAN' 指定時の主なFILETYPE_NAME

FILETYPE_NAME

主な出力処理の例

Control File

制御ファイルに対するRead/Write

Archive Log

Archive Logのバックアップ時のRead

Archive Log Backup

Archive LogのBackupsetへのWrite

Data File

データ・ファイルのバックアップ時のRead

Data File Incremental Backup

データ・ファイルのBackupsetへのWrite

Data File Backup

増分更新時のLevel1からのRead

Data File Copy

Image Copy Backup取得のWrite

増分更新時のLevel0へのWrite

RMAN処理の進捗確認

V$SESSION_LONGOPS (Doc ID 1736981.1 / KROWN#122407)

•

バックアップ、コピー及びリストアの進捗状況を確認可能

–

Image Copy Backupであれば

、V$BACKUP_ASYNC_IOビューでも確認可能

•

（BUFFER_SIZE * IO_COUNT / TOTAL_BYTES)*100

–

V$BACKUP_ASYNC_IO.TOTAL_BYTES列の値は対象のデータファイルのサイズを示すが、

高速増分バックアップでは読み飛ばす為に参考にはならない

SQL> -- KROWN#122407

SELECT sid, serial#, context, sofar, totalwork,

round(sofar/totalwork*100,2) "% Complete"

FROM v$session_longops

WHERE opname LIKE 'RMAN%' AND opname NOT LIKE '%aggregate%'

AND totalwork != 0 AND sofar <> totalwork ;

RMAN処理の進捗確認（参考）

V$SESSION_LONGOPS

SQL> -- sample

select INST_ID, SID,

SOFAR, TOTALWORK, round(SOFAR/TOTALWORK*100,2) "% Complete",

START_TIME,LAST_UPDATE_TIME,

round((LAST_UPDATE_TIME-START_TIME)*(1/(SOFAR/TOTALWORK)-1)*24*60*60) "REMAIN(sec)"

from GV$SESSION_LONGOPS

where OPNAME like 'RMAN%' and OPNAME not like '%AGGREGATE%'

and TOTALWORK !=0 and SOFAR <> TOTALWORK

and SOFAR !=0 ;

INST_ID SID SOFAR TOTALWORK % Complete START_TIME LAST_UPDATE_TI Remain(sec)

--- --- --- --- --- --- --- ---

1 142 262398 786432 33.37 02/27 15:49:43 02/27 15:50:13 60

1 142 741502 786432 94.29 02/27 15:49:43 02/27 15:50:45 4

RMAN Backupの消費リソースの平準化

バックアップ時間を長くすることで、業務アプリへの影響を極小化

•

単位時間当たりのH/Wリソース消費量を抑えることを目的に

データベースリソースマネージャを活用を検討

–

RMAN Backupを少ないリソースで長時間かけて実行することになる

•

業務アプリケーションのレスポンス・タイムへの影響を極小化

–

「道のり（バックアップ処理量） = 速さ（単位時間当たりのH/Wコスト） x 時間」

RMAN Backupの消費リソースの平準化

Database Resource Manager

•

Oracle Databaseはデフォルトで、RMANの処理（BACKUP/COPY）が

コンシューマ・グループ「BATCH_GROUP」にマッピングされている

Program Agenda

1

2

3

4

5

はじめに

高速増分バックアップ

バックアップの運用ポリシー

RMANバックアップのチューニング

押さえておきたい注意点

SYSBACKUP with Oracle Database 12c Release 1

SYSDBA権限やSYSユーザーのパスワードの分散を防止

•

クローズ状態のデータベースへの接続機能を含め、

バックアップおよびリカバリに必要な権限を含む

–

SELECT ANY TABLE等のデータ・アクセス権限は含まない

–

システム管理者は、バックアップおよびリカバリを実行するユーザーに対して、

SYSDBAのかわりにSYSBACKUPを付与

 バックアップ専用ユーザーを用意することで、