しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニング

しばちょう先生による特別講義！
RMAN Backupの
運用と高速化チューニング
柴田長
シニア・マネジャー
Applied Technology, Database & Exadata
Database Engineering, Product Strategy
Database Business Unit, Oracle Japan
Copyright © 2014, Oracle and/or its affiliates. All rights reserved.
Oracle DBA & Developer Days 2014
for your Skill
使える実践的なノウハウがここにある
#odddtky

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

自己紹介
“しばちょう”こと柴田長（しばたつかさ）と申します。
日本オラクル株式会社
データベース事業統括製品戦略統括本部
データベースエンジニアリング本部
Database & Exadata技術部応用技術グループ
シニアマネジャー
Oracle Technology Networkで毎月連載中
「しばちょう先生の試して納得！DBAへの道」
http://www.oracle.com/technetwork/jp/database/articles/shibacho/index.html
4

アジェンダ
1
2
3
4
5
はじめに
高速増分バックアップ
バックアップの運用ポリシー
RMANバックアップのチューニング
押さえておきたい注意点
5

本資料を作成する上で参考にした資料
• Backup and Recovery Performance and Best Practices for Exadata Cell and Oracle Exadata Database Machine
– http://www.oracle.com/technetwork/database/features/availability/maa-tech-wp-sundbm-backup-11202-183503.pdf
• Backup and Recovery of Oracle Exadata: Experiences and Best Practices
– http://www.oracle.com/technetwork/database/availability/8277-exadata-backuprecovery-1888646.pdf
• Doc ID 1311518.1 Incremental Rman Backup High Waits On 'block change tracking buffer space’
• Doc ID 1072545.1 RMAN Performance Tuning Using Buffer Memory Parameters
• Oracle Databaseバックアップおよびリカバリ・リファレンス 11gリリース2（11.2）
• Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース2（11.2）
White Paper、Doc、マニュアル、（実機検証…）
6

はじめに
7

バックアップ要件とは？
• Recovery Time objective (RTO)
– どのぐらいの時間でリカバリしなければならないのか？
• Recovery Point Objective (RPO)
– データをロストしても許容される範囲は？
• Backup Retention Policy
– バックアップを保持しておくべき期間は？
• Additional Questions
– データ量は？パフォーマンス要件は？ Disaster Recoveryは？
8

様々なバックアップ方式
Oracle Exadata Backup Destination Options
9
Fiber Channel
SAN
10GigE or
InfiniBand
Network
Oracle Secure Backup
Media Servers
Oracle Secure Backup
Admin Server
Tape library
•Offsite Backups
•Vaulting
InfiniBand
Network
Storage Expansion Rack
•Fastest Backup and Restore
•ILM Historical Archive
•Second DATA2 Disk Group
•Expansion of DATA
10GigE or
InfiniBand
Network
Ethernet
ZFS Storage Appliance
•Backups of database & non-database files
•Snapshots
•Clones

Oracle Zero Data Loss Recovery Applianceの登場
Oracle Exadata Backup Destination Options
10
Fiber Channel
SAN
10GigE or
InfiniBand
Network
Tape library
InfiniBand
Network
10GigE or
InfiniBand
Network
Zero Data Loss Recovery Appliance
•ゼロ・データ・ロス
•膨らみ続けるバックアップ・コスト対策
•あらゆるDBバージョンとプラットフォーム
ZFS Storage Appliance
Storage Expansion Rack

最適なバックアップ方式の選択
• 次のセッションへご参加下さい！！
「Oracle Zero Data Loss Recovery Appliance」による
データベース保護のアーキテクチャ
• 本セッションでは、
Zero Data Loss Recovery Applianceの登場で益々重要な機能となってきた
Oracle Recovery Managerについて
– 高速増分バックアップの動作
– チューニング方法
– 注意すべきポイント
をご紹介させて頂きます。
11

12

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)
13

• BCT Fileは、更新されたブロック・アドレスをビットマップでバージョン管理
– 更新されたブロックだけにアクセスする高速増分バックアップを実現
– BCT Fileのサイズは、データベースのサイズ及びRedoのスレッドの数に比例
• 初期サイズは10MBで、通常、ブロック・サイズの約1/30,000×ノード数
• 300GBまでは10MB、600GB時は20MB+α
– Oracle Real Application Clusters環境もSingle Database環境と同じ設定
• 全インスタンスが読み書き可能なデバイス（例: ASM Diskgroup）上に一つだけ配置
Block Change Tracking File
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '+FRA(CHANGETRACKING)' REUSE ;
14

• BCT Fileを有効化すると、Large Pool内にCTWR dba bufferを確保し、
バックグラウンド・プロセスCTWRが起動
• BCT Fileへの書き出しの流れ
– サーバープロセスが更新ブロック情報をCTWR dba buffer へ書き込む
– CTWRがトランザクションと非同期でbufferから随時BCT Fileへ書き出し
• Checkpoint時に、CTWR dba bufferとBCT Fileの間で同期が取られる
BCT Fileへの書き出し
SQL> select * from v$block_change_tracking ;
STATUS FILENAME BYTES
-------- ------------------------------------------ ----------
ENABLED +FRA/orcl/changetracking/ctf.496.840482383 11599872
15

CTWR dba buffer
• サーバー・プロセスによる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’
block change tracking buffer space待機イベント
16

CTWR dba buffer
• CTWR dba bufferのサイズは、LARGE_POOL_SIZEから導出
• 隠しパラメータで動的にサイズ変更可能（Doc ID 1311518.1）
– サポートの指示に従って設定を行って下さい
– 実際に確保される上限はLARGE_POOL_SIZE以下となる為、
LARGE_POOL_SIZEの拡張も同時に検討してください
• 12c以降、動的に拡張する機能が追加
初期サイズと変更方法（11g Release 2）
SQL> select pool,name,sum(bytes) from v$sgastat where name like 'CTWR%' group by pool,name;
large pool CTWR dba buffer 1167360
17

BCT Fileを使用したLevel1 Backup取得時
• 高速増分バックアップでは、基本的にはBCT Fileにトラッキングされたブロック
のみを読込む
– 従来の増分バックアップよりもブロック読込み量が減少し、高速化が期待できる
– とは言え、更新ブロックの散らばり具合により、
Multi-Block Readの方が効率的なこともあるので、
実はI/Oサイズを最適に変更して、不要ブロックも含めて読み込むことがある
読込みI/Oサイズの最適化
物理的に歯抜けに更新されると、
Small READになりやすい
物理的に連続して更新されると、
Large READになりやすい
※ 上記はあくまでイメージ図であり、正確な動作を表すものではありません
18

Block Change Tracking File
• 可用性
– RMANでBCF File自体のバックアップは非サポート
– 必要に応じて、ASMやRAID等で冗長化
– BCT Fileが破損した場合、次回の増分バックアップが高速とならない
• Image Copy Backup（Level0）は必要ありません（良く誤解されている）
• バージョニング
– BCT Fileではデフォルト8世代分（バックアップ8回分）の更新情報を保持
• 9回目以降の累積増分バックアップでは高速とならない
• 隠しパラメータで拡張可能（Doc ID 1736769.1 / KROWN#122168）
補足
19

RMANによる高速増分バックアップ
抽出と適用の二分割により、バックアップ中の障害にも対応可能
+FRA DG
+DATA DG
バックアップ前提運用フェーズ(バックアップ運用)
Image Bkup(level 0)
BCT File
DML
ctwr
dbwr
Data Files
全体Bkup
高速増分Bkup
(level 1)
増分更新
Bkup Window
BkupSet (level 1)
20

増分適用（増分更新）
• RECOVERコマンドで、Level1 Backup内のブロックをLevel0 Image Copy Backup
に適用し、ロール・フォワードする処理
– Level0をリストアする際に、適用すべきLevel1やArchive Logを最小化
– 適用するLevel1を制御することが可能
• 何も気にしなければ、全てのLevel1が適用されてLevel0は最新化
• 「数日前にリカバリ出来ること」という要件がある場合はUNTIL句を指定する
Level0 Image Copy BackupをLevel1 BackupでRoll Forward
RMAN> # 7日前の任意の地点へリカバリできるLevel0になるようLevel1を適用
RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE'
UNTIL TIME 'SYSDATE-7' ;
21

増分適用時のI/O
• Level1を読み込んで、Level0へ上書き（Level0のブロックは読み込まれない）
Level0 Image Copy BackupをLevel1 BackupでRoll Forward
1 2 3 4 5 6 7 8 9 10
1 5 7 10
1 2 3 4 5 6 7 8 9 10
増分適用
Level 0 Image Copy Backup
Level 1 Backup
Data File
22
Small I/O or Large I/O Read
Level1 を読み込んで、
Level0の該当ブロックのみ上書き

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

増分バックアップの種類
差分増分バックアップと累積増分バックアップ
24
• Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11.2
– https://docs.oracle.com/cd/E16338_01/backup.112/b56269/rcmcncpt.htm#i1007616
差分累積

各バックアップの増分開始SCN
増分バックアップのアルゴリズム（増分適用によるLevel0の変化を見逃しガチ）
• 増分開始SCN
– 増分バックアップの対象となる最小のSCN
• このSCNよりも大きなSCNが記録されたブロックが増分バックアップされることになる
– 差分増分バックアップ
• 最新のLevel1バックアップのCheckpoint SCN
– 累積増分バックアップの起点
• 最新のLevel0バックアップのCheckpoint SCN
• Level0にLevel1を適用すると、Level0のCheckpoint SCNはLevel1のものに置き換わっていることに注意
– つまり、累積増分バックアップ前に増分適用をした場合、差分増分バックアップと同じ範囲となる
– 万が一、Level1が破損していて増分適用が失敗した場合、差分増分ではバックアップ・ジョブを止めて、手動で
累積増分に変更する必要があるが、累積増分バックアップではその手間が発生しないメリット有り
25

正しく理解しておくべき構文
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のバックアップを識別する為に必須
– 指定したTAG名のLevel0のバックアップが存在しない場合は、Level0のバックアップを取得する
26

増分適用とバックアップ実行のタイミング
• 例えば、毎日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（高速リカバリ領域）の容量設計が必要
– もしくは、 UNTIL 'SYSDATE-（1+Backup Window）' を指定した増分適用の実施
これが意外と難しい。でも、Recovery Applianceならば考える必要が無くなる！！
27

オンラインで取得したバックアップの中には、
バックアップ期間中に更新されたブロックも含まれる
バックアップの開始地点ではなく、終了地点以降のリカバリで使用可能
28
高速増分バックアップ増分適用（ UNTIL 'SYSDATE-1' ）
+FRA DG
+DATA DG
DML
dbwr
Data Files
SCN:300
22:10
最新Level1（SCN:300）
SCN:310
22:20
SCN:320
22:30
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 (高速リカバリ領域)
Recovery Files Comments
Control file and
archived log backups
Estimate total size of all archived logs generated between
successive backups on the busiest days x 2 (in case of
unexpected redo spikes)
Flashback logs (Redo rate x Flashback retention target time) x 2
Image copy backups Size of database minus temporary files
Backup set backups (full) # of full backups x estimated size
Incremental Backups # of incremental backups* x estimated size
サイジング考え方
* リカバリ可能とする日数”+1日”を忘れがちです!!
例えば、一週間以内の任意の地点へリカバリする要件であれば、8日分
29

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が設定されていれば、
Archive Logに関しては、こちらの設定にも従う（後述）
FRA上のファイルの自動削除
30

BACKUP RETENTION POLICY（保持ポリシー）
• リカバリ期間、もしくは冗長性のどちらか一方を設定
• 方針を満たさないバックアップは削除対象として扱われる
– リカバリ期間
• 現時点からリカバリ可能時点までの日数
– 冗長性（高速増分バックアップの運用では、こちらが推奨）
• 各データファイル及び制御ファイルの全体、又はLevel0のバックアップの数
バックアップ（Archive Logを含む）の保存方針を設定
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS ;
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1 ;
31

増分更新バックアップの保持ポリシーは冗長性を推奨
• 増分更新バックアップ機能を使用している場合は、
以下の方法でバックアップファイルを管理すること
– 冗長性を指定したBACKUP RETENTION POLICY(デフォルト1世代分) を使用
– これにより、Level 0を更新するために使用したLevel 1を削除対象となる
• 例えば、リカバリ期間を指定すると、不要なLevel1が残り続けてしまう
– Level 0にLevel 1を適用してロール・フォワードするRECOVERコマンド実行時には、
この保存ポリシーは考慮されない為、
RECOVERコマンドにUNTIL句を追加し、レベル0を増分更新する時点を指定
Doc ID 463875.1 Frequently asked questions on Rman backup retention policy
32

ARCHIVELOG DELETION POLICY
• Archive Logがディスクからの削除対象となる複数条件を設定可能
• 方針を満たすArchive Logが削除対象となる
– Archive Logバックアップの数とバックアップ先
– Standby Database側への転送済み、又は適用済み
Archive Logの削除方針を設定
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP <#> TIMES
TO DEVICE TYPE [DISK | SBT] ;
CONFIGURE ARCHIVELOG DELETION POLICY TO [SHIPPED | APPLIED]
ON [ALL] STANDBY ;
※ 上記の2つの条件の組み合わせて指定（後述）が可能
33

Archive Logの削除コマンド
• Archive Logを削除するRMANコマンドは次の二つであり、
バージョン毎に動作が異なる（マニュアル表記は古い可能性有り）
BACKUP RETENTION POLICY & ARCHIVELOG DELETION POLICY
RMAN Command Release
BACKUP
RETENTION
POLICY
ARCHIVELOG
DELETION
POLICY
DELETE ARCHIVELOG ALL; 共通 × ○
DELETE OBSOLETE ;
（Archive Log以外も削除対象）
~11.2.0.3 ○ ×
11.2.0.4~ ○ ○
34

Archive Logの削除例
• BACKUP RETENTION POLICYとARCHIVELOG DELETION POLICYの両方の設定
に従って、Archive Logが削除されるコマンド
– 例：全Standby Databaseで適用済み、かつ、1度以上Diskへバックアップ済みのArchive
Logを削除するポリシー設定の例
DELETE OBSOLETE ; (11.2.0.4~)
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 ;
35

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コマンドに
SEQUENCE#や日付を指定して実行しなければならない
動作の補足
36

カタログ・データベース
• メリット
– 長期間、バックアップのメタデータを保持することが可能
 NOCATALOGモード時は、
CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータの設定に依存
– 複数データベース環境の統合バックアップ環境
– KEEP FOREVER句の使用が可能
– Data Guard環境においてサイト間での柔軟なリストアを実現
• Primaryの制御ファイルのバックアップをStandby側へリストアする際に、全データ・ファイルのパスを適
切に自動変換してリストアしてくれる
• カタログ・データベースは無償、EMのレポジトリと同じサーバー上に配置可
Highly Recommended
http://www.oracle.com/technetwork/database/availability/8277-exadata-backuprecovery-1888646.pdf
37

CONTROL_FILE_RECORD_KEEP_TIME
• CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータ
– デフォルト：7（単位：日）、指定可能な範囲：0~365
• NOCATALOG モードで運用している場合に設定値を検討する
– バックアップ・セット情報等のRMANに必要な情報は制御ファイルに格納
– 上記パラメータの設定期間を経過後は上書き対象
• RMANの保存ポリシーは無視されてしまうので、リカバリ・ウィンドウの日数以上に設定する必要有り
– 例：過去2週間以内の任意の地点へリカバリする要件があれば、最低でも15（日）を設定
Doc ID 1734969.1 / KROWN#120064
38

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' ;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL TAG 'INCR_UPDATE' ;}
39

日曜日はフルバックアップ& 月~土曜日は高速増分バックアップ（累積）
 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 ;
日曜日のバックアップ開始～火曜日のバックアップ開始までの間、
Level0 Image Copy Backupを2世代持ちになる為、FRAの容量設計に注意
H/Wリソースに余裕があれば、VALIDATEコマンドでバックアップの破損チェックを検討
40

Sample Backup Script 2
毎日、高速増分バックアップ（差分）、Recovery Window: 7日間、Backup Window: 1時間
 1世代のBackup
RMAN> #事前設定
CONFIGURE RETENTION POLICY TO REDUNDANCY 1 ; # Level0が1世代となる為
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 ;
41

毎日、高速増分バックアップ（累積）
 2世代（最新のLevel0 & 過去7日以内にリカバリ可能なLevel0+Level1）
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' ;
42

毎日、高速増分バックアップ（累積）
 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 ;
毎日の高速増分バックアップで共通のLevel1バックアップを取得し、
2つのLevel0 Image Copy Backupが7日間のズレを維持したまま毎日ロールフォワードされていく
もしもの障害時にはリカバリ目標地点をUNTIL句で指定したRESTOREコマンドの実行が必要
 UNTIL句を指定しないRESTOREでは、最新のバックアップがリストアされる為
43

Oracle Zero Data Loss Recovery Applianceの登場
• 世代数（複雑なバックアップ・スクリプト）からの解放
– ZDLRAで設定するのは、どの時点までリカバリしたいのか？だけ！
• データベース側では、高速増分バックアップ（累積）を繰り返すのみ
• ZDLRA内では、そのLevel1を用いて仮想フルバックアップが構成される為、
Level0の数（世代数）を完全に意識する必要が無い
– その為に、前述のBackup Script3のような若干トリッキーなバックアップ運用は不要
• 本セクションで完璧な理解が必要となるのは、（多分）Archive Logの管理!?
• もちろん、ZDLRA側には全てのRedoレコードが転送されているので、誤って削除してしまっても安心
バックアップ運用の簡素化を実現
44

RMAN Backupのチューニング
45

RMAN Backup Data Flow
• Read Phase
– RMANチャネル（サーバー・プロセス）がDiskからinput I/O buffersへブロックを読み込む
• Copy Phase
– RMANチャネルがinput buffersからoutput buffersへブロックをコピーする
– ここで、ブロックに対する追加処理が行われる
• Validate blocks, Compress and/or Encrypt data, if requested
• Write Phase
– RMANチャネルがoutput buffersからストレージ(Disk or SBT)へブロックを書き出す
Overview
46

RMAN Backup Data Flow
Overview
Read
Write
Copy
Restore処理は逆フロー
47

Tuning Principles
• 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
– TCP/IP performance measurement tools such as qperf
• Databaseサーバー  Tape System間
1. StorageのI/O性能、Networkスループットの限界を把握
48

Tuning Principles
• Oracle Automatic Storage Management（ASM）
– 一般的には、DATAとFRAのDiskは分ける構成
– もし、DATAとFRAがDiskを共有する場合（Readの方が多い傾向なので）
• 高速な外周にDATA Diskgroupを配置
• 低速な内周にFRA Diskgroupを配置
– 一般的な性能差は15~25%（1MB Sequential Write)
• Not Using ASM
– Stripe Size=1MBで、全てのDiskにData Fileが分散されるように構成
2. 最適な性能を引き出すDiskの構成
49

Tuning Principles
• 非同期I/Oを使用
– もし、プラット・フォームで非同期I/Oがサポートされていない場合、
Oracleは非同期I/Oをシミュレートする仕組みが実装されている
• Disk backup: set DB_IO_SLAVES parameter
• Tape backup: set BACKUP_TAPE_IO_SLAVES parameter
• Channel数の割り当て
– Disk backup: I/O性能が最大になるようにChannel数を増やす
• Image Copy Backupでは、一つのChannelは同時に一つのData Fileを扱う
– Tape backup: 一つのTape Drive毎に、一つのChannelを割り当てる
3. デバイス性能を最大限に活用する為のRMAN側の設定
50

自動チャネル割り当て
• Channel（サーバー・プロセス）を複数起動して、バックアップを並列化
– 特に、Level0 Image Copy Backupでは一つのChannelが一つのData Fileをバック
アップする為、高速化のためには複数起動が望ましい
– 一つのChannelでは一つのCPUコアしか使用できない
• Channelの複数起動  複数CPUコアの使用
• Channelの単一起動  Backupのオーバーヘッド（CPUやI/O消費）の低減
Channel数とH/Wリソース
RMAN> # Diskデバイス用のチャネルのパラレル化（自動チャネル割り当て）
CONFIGURE DEVICE TYPE DISK PARALLELISM <n> ;
51

自動チャネル割り当て
• 各インスタンスのH/Wリソースを使用してバックアップの実行が可能
– 設定例：2ノードRACで、インスタンス毎に2つのChannel割り当て（合計4つ）
Doc ID 1734142.1 / KROWN#109790 RAC環境でのチャネル割り当てについて
$ rman target /
RMAN> # Diskデバイス用のチャネルのパラレル化（自動チャネル割り当て）
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 ;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK CONNECT 'sys@orcl1';
$ rman target sys/<password>
RMAN> # 事前設定された自動チャネル割り当てを使用したLevel0 Image Copy Backup
BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'INCR_UPDATE' ;
事前設定時には
パスワード不要
ただし、実際にChannel
を使用する際、
パスワードを明示指定
したTarget接続が必須
数値のみ
指定可能
52

手動チャネル割り当て
• 事前にCONFIGUREコマンドで設定せずに、run{}内で手動割り当て
– 設定例：2ノードRACで、インスタンス毎に2つのChannel割り当て（合計4つ）
– run{}内のALLOCATE CHANNELコマンドで設定した値は、run{}内でのみ有効
Doc ID 1734142.1 / KROWN#109790 RAC環境でのチャネル割り当てについて
$ rman target sys/<password>
RMAN> run{
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT 'sys@orcl1';
BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'INCR_UPDATE' ;}
文字列
指定可能
53

SYSBACKUP with Oracle Database 12c Release 1
• クローズ状態のデータベースへの接続機能を含め、バックアップおよびリカ
バリに必要な権限を含む
– SELECT ANY TABLE等のデータ・アクセス権限は含まない
– システム管理者は、バックアップおよびリカバリを実行するユーザーに対して、SYSDBA
のかわりにSYSBACKUPを付与
 バックアップ専用ユーザーを用意することで、
前述したTarget接続やChannel割り当て時のSYSのパスワード管理が不要
SYSDBA権限やSYSユーザーのパスワードの分散を防止
54

Read Phase
• ASM環境におけるBufferは最適な性能が得られるように自動設定
– Channel（サーバー・プロセス）毎に、Input I/O BufferがPGAに割り当てられる
– Bufferの数
• サーバー・プロセスが同時に発行出来る非同期I/O数
• ASM DiskgroupのDisk数に応じて自動調整
– 一つのBufferのサイズ
• サーバー・プロセスが発行する非同期I/Oの最大I/Oサイズ
• ASM DiskgroupのAllocation Unitのサイズ
Input I/O Buffers with Oracle Database 11g Release 2 & ASM
Doc ID 1072545.1 RMAN Performance Tuning Using Buffer Memory Parameters
55

Input/Output Bufferの数とサイズの確認
Query V$BACKUP_ASYNC_IO / GV$BACKUP_ASYNC_IO
56
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
57
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 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 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 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 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 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 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 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 INPUT FINISHED 29 1048576 20 1,024 35 1026 571 0 455 +FRA/orcl/datafile/undotbs2.383.xxx
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 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サイズ
Bufferの数

Read Phase Tuning
• 基本的には、RMANチャネル数を増加させることで対処可能
– さらに、ASM環境であれば、最適なBufferの数とサイズに自動調整されている
• DiskのI/O性能を全て引き出せてない、
かつ、CPUやMemoryに空きがある場合に限り、
RMAN Input I/O Bufferの数とサイズを増加させることが可能
– ただし、隠しパラメータにつき、サポートの指示に従って設定して下さい
• 次のDoc内のPDFファイル（rman_buffer.pdf）を参照
– Doc ID 1072545.1 RMAN Performance Tuning Using Buffer Memory Parameters
Hidden Parameters with Oracle Database 11g Release 2
58

Copy Phase
• CPUリソースを非常に消費する処理のため、CPU増設もしくは下記を実施
– Compression: 圧縮レベルを下げる（LOW / MEDIUM)
– TDE Column Encryption: 2重暗号化なので、RMAN側は暗号化しない
– TDE Tablespace Encryption:
• Compressed & Encrypted backupの場合、
暗号化された表領域は復号された後、圧縮再度暗号化される動作となる為、
圧縮しないことを検討
• その場合、暗号化されたブロックのままバックアップされる
– Validate Block:
• デフォルトでPhysical Corruptionのチェックが実行される
RMAN Backup Compression, Encryption & Validate Block Guidelines
59

Copy Phase
• デフォルトで有効化（推奨）
– NOCHECKSUMオプションで無効化が可能
– ただし、Blockヘッダやフッターの物理的な整合性チェックは無効化不可
• 読込み元ブロックに対して、埋め込まれているチェックサムを検証
– DB_BLOCK_CHECKSUM初期化パラメータの設定に依存
• FALSEの場合  SYSTEM表領域のみ
• TYPICAL or FULLの場合  全表領域が対象
– http://www.oracle.com/webfolder/technetwork/jp/ondemand/ddd2013/C-2.pdf (昨年のDDD資料を要参照)
• 書込み先ブロックに対して、チェックサムを計算して埋め込む
– DB_BLOCK_CHECKSUM初期化パラメータの設定には依存しない
Validate Block(Physical Corruption Check)
60

Copy Phase
• デフォルト無効で、 CHECK LOGICALオプションで有効化が可能
– 読込み元ブロックに対して、Physical Corruption Checkを通過したブロック
（表、索引セグメント）の論理的な破損の有無をチェック
– 通常1~3%のオーバーヘッドが付加される（マニュアル抜粋）
• BACKUPコマンドだけではなく、以下のコマンドでも追加指定が可能
Validate Block(Logical Corruption Check)
RMAN Command Description
VALIDATE … バックアップ、データファイル等の検証コマンド
RECOVER … Level0の増分更新、データファイルのリカバリ用コマンド
61

Corruption検出時の動作
• バックアップ、リストア中にデータファイルに許容されるPhysical Corruption、
Logical Corruptionの合計数
– デフォルト設定は0（ゼロ）で、一つの破損も許容しない
• 破損検出時は、バックアップ or リストアがその時点で終了
– デフォルト以外へ変更することで、
• 破損の合計数が設定値以下の場合は最後まで実行される
– 高速増分バックアップ（差分）の場合、
再度同じLevel1を取得することが難しい（累積増分バックアップやSCN指定のバックアップが必須となる）
– 破損ブロックはV$DATABASE_BLOCK_CORRUPTIONビューで確認可能
• RECOVERコマンドでブロック単位での修復後、再度バックアップを取得するのが望ましい
SET MAXCORRUTコマンド
62

Write Phase
• Channel毎に割り当てられるバックアップの書き出し用のBuffer
– Defaultの設定
• Buffer数：一つのChannelに4つのOutput I/O Bufferが割り当てられる
• Bufferサイズ：Disk1MB / SBT  256KB
– Set BLKSIZE channel parameter >= media mgmt client buffer size
– Oracle Secure Backupの場合は変更の必要なし
• ASM Diskgroupへの書き出しに関しては、
最適な性能が得られるようにOutput I/O Bufferを自動設定
Output I/O Buffers with Oracle Database 11g Release 2
63

Write Phase Tuning
• Input I/O Bufferと同様に、
書込み先ストレージのI/O性能を全て引き出せてない場合、
RMAN Output I/O Bufferの数とサイズを増加させて対処させることが可能
– ただし、隠しパラメータにつき、サポートの指示に従って設定して下さい
• 次のDoc内のPDFファイル（rman_buffer.pdf）を参照
– Doc ID 1072545.1 RMAN Performance Tuning Using Buffer Memory Parameters
– SBT（Tape）: Oracle Secure Backup使用時は自動調整の為、設定不要
Hidden Parameters with Oracle Database 11g Release 2
64

非同期I/Oのデータ読込み性能の確認（1）
Query V$BACKUP_ASYNC_IO / GV$BACKUP_ASYNC_IO
65
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 ;

• EFFECTIVE_BYTES_PER_SECOND列
– Image Copy Backup時にのみ出力
– TOTAL_BYTES / ELAPSED_TIMEの計算結果で、秒間のスループット値
• TOTAL_BYTES列: バックアップ対象のデータファイルのサイズ（単位:Byte）
• ELAPSED_TIME列: バックアップに要した時間（単位:10msec）
– この値がOracle ORIONを使用した検証結果よりも小さい場合
 ストレージに余力があるので、ChannelやBufferのチューニングを施す
• ただし、同一Disk上のデータファイルを複数Channelで同時にバックアップした場合は、
それらの合計値で比較する必要有り
V$BACKUP_ASYNC_IO
66

• I/O response: LONG_WAITS > SHORT_WAITS > READY
– 処理中でも出力されるので、進捗確認にも使用可能
V$BACKUP_ASYNC_IO
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の回数
67

• 非同期I/Oの特徴
– 非同期処理は複数のタスクの同時発生を伴う
– OracleのI/Oは、各I/O要求の完了を知るために、
割り込みメカニズムではなくポーリングを使用
• LONG_WAITS + SHORT_WAITS が IO_COUNTに対して高い割合
 ストレージのI/O性能がボトルネックになっている可能性有り
– ただし、ELAPSED_TIME列と比較して、SHORT_WAIT_TIME_TOTALの値が低い場合、
遅延の原因が別の要因(プロセスのスワッピングなど)にある可能性
Doc ID 1736981.1 / KROWN#122407 Recovery Managerのセッションの監視
68

• File Type毎の詳細なI/O統計(I/Oサイズの確認が可能)
– RMAN処理を挟む形で2回取得することで差分を抽出する
V$IOSTAT_FUNCTION_DETAIL
69
主要な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待機数
WAIT_TIME 合計同期I/O待機時間（ミリ秒）

V$IOSTAT_FUNCTION_DETAIL
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
Where FUNCTION_NAME = 'RMAN' 指定時の主なFILETYPE_NAME
70

RMAN処理の進捗確認
• バックアップ、コピー及びリストアの進捗状況を確認可能
– Image Copy Backupであれば、V$BACKUP_ASYNC_IOビューでも確認可能
• （BUFFER_SIZE * IO_COUNT / TOTAL_BYTES)*100
– V$BACKUP_ASYNC_IO.TOTAL_BYTES列の値は対象のデータファイルのサイズを示すが、
高速増分バックアップでは読み飛ばす為に参考にはならない
V$SESSION_LONGOPS
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 ;
71

RMAN処理の進捗確認（参考）
V$SESSION_LONGOPS
SQL> -- しばちょう流
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
1 142 786430 786432 100 02/27 15:49:43 02/27 15:50:48 0
72

RMAN Backupの消費リソースの平準化
• 次の方法で、RMAN Backupを長時間かけて実行することで、
単位時間当たりのH/Wリソース消費量を抑えることが可能
– Database Resource Manager  しばちょう先生の連載第23回
• 業務アプリケーションのレスポンス・タイムへの影響を極小化
– 「道のり（バックアップ処理量） = 速さ（単位時間当たりのH/Wコスト） x 時間」
バックアップ時間を長くすることで、業務アプリへの影響を極小化
73

RMAN Backupの消費リソースの平準化
• Oracle Databaseはデフォルトで、RMANの処理（BACKUP/COPY）が
コンシューマ・グループ「BATCH_GROUP」にマッピングされている
– BATCH_GROUPを使用したリソース・プランを設定、使用するだけで制御可能
Database Resource Manager
74

実装例(1) – Resource Planの作成
SQL>
BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'BK_PLAN',comment => 'BACKUP PLAN');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'BK_PLAN', -
GROUP_OR_SUBPLAN => 'SYS_GROUP', MGMT_P1 => 75, comment => 'TEST');
GROUP_OR_SUBPLAN => 'BATCH_GROUP', MGMT_P2 => 10, -
MAX_UTILIZATION_LIMIT => 10,comment => 'TEST');
GROUP_OR_SUBPLAN => 'OTHER_GROUPS',MGMT_P2 => 90, comment => 'TEST');
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/ * MAX_UTILIZATION_LIMITで、RMANで使用するCPU使用率を最大10%に制限
75

実装例(2) – Resource Planの確認と有効化
SQL> set linesize 150 pages 5000
select PLAN, GROUP_OR_SUBPLAN, MGMT_P1, MGMT_P2, MGMT_P3, MGMT_P4, MAX_UTiLIZATION_LIMIT
from DBA_RSRC_PLAN_DIRECTIVES
where PLAN='BK_PLAN' ;
PLAN GROUP_OR_SUBPLAN MGMT_P1 MGMT_P2 MGMT_P3 MGMT_P4 MAX_UTILIZATION_LIMIT
-------- ----------------- ---------- ---------- ---------- ---------- ---------------------
BK_PLAN SYS_GROUP 75 0 0 0
BK_PLAN OTHER_GROUPS 0 90 0 0
BK_PLAN BATCH_GROUP 0 10 0 0 10
SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = BK_PLAN scope=MEMORY ;
SQL> select * from V$RSRC_PLAN ;
ID NAME IS_TO CPU INS PARALLEL_SERVERS_ACTIVE PARALLEL_SERVERS_TOTAL PARALLEL.MANAGED
----- -------- ----- --- --- ----------------------- ---------------------- ----------------
14370 BK_PLAN TRUE ON OFF 0 32 FULL
76

実装例(3) – Resource Planの効果を確認
SQL> set linesize 180 set pages 50000
select SEQUENCE# SEQ, NAME, CPU_WAIT_TIME, CPU_WAITS, CONSUMED_CPU_TIME
from V$RSRC_CONS_GROUP_HISTORY ;
SEQ NAME CPU_WAIT_TIME CPU_WAITS CONSUMED_CPU_TIME
---------- ------------------------------ ------------- ---------- -----------------
2 SYS_GROUP 393 0 2285
2 OTHER_GROUPS 0 0 0
2 BATCH_GROUP 117035 152 31421
2 _ORACLE_BACKGROUND_GROUP_ 0 0 0
SQL>
select SID, SERIAL#, USERNAME, STATUS, PROGRAM, RESOURCE_CONSUMER_GROUP
from V$SESSION
where PROGRAM like 'rman%';
SID SERIAL# USERNAME STATUS PROGRAM RESOURCE_CONSUMER_GROUP
--- ---------- -------- -------- ------------------------------------ -----------------------
21 37 SYS ACTIVE rman@vm11204.localdomain (TNS V1-V3) BATCH_GROUP
77

押さえておきたい注意点
78

バックアップ中にデータファイルが消された際の挙動
RMAN Backupは異常終了する為、再実行が必要
RMAN> backup incremental level 1 for recover of copy with tag 'incr_update' database ;
Starting backup at 17-DEC-13
...
channel ORA_DISK_1: starting datafile copy
input datafile file number=00008 name=+DATA/orcl/datafile/tbs4m.270.834414641
output file name=+FRA/orcl/datafile/tbs4m.326.834421823 tag=INCR_UPDATE RECID=45 STAMP=………
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 12/17/2013 15:50:37
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: 'No file with this number, file does not exist'
* BCT Fileはデータファイル毎でバージョン管理されている為、
異常終了によって取得できていなかったデータファイルのLevel1は、次の高速増分バックアップで取得される
79

Data Guard環境でArchive Logが消せない
• Problem
– 二つのPolicy設定がデフォルトの状態、かつ転送LAGも発生していない状況で、
次のRMANエラーが発生し、Archive Logが削除できない
• Cause: LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの設定
• 一つでも”DEFER”に設定されているとNG
– 不要なRedo転送の設定はクリアしておくことがお勧め
二つのPOLICYを設定していなくても発生する
RMAN> show ARCHIVELOG DELETION POLICY ;
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
RMAN> delete archivelog all ;
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture
process
archived log file name=+FRA/orcl/archivelog/2014_01_11/thread_1_seq_165.471.836528941 …
80

Standby Databaseで高速増分バックアップ
• Problem
– Checkpointが実行されなければ、BCT Fileを使用することが不可能な為、
Primary Database側でLog Switchがされなければ、Standby Database側で差分ブロック
が無いこととなり、バックアップがスキップされる。
• Workaround
– Standby Database側で高速増分バックアップを実施する直前に、
Primary Database側でLog Switchの実行を推奨
Primary Database側でのLog Switchが必須
81

Flashback Databaseの取り消しでORA-01244
• Problem
– Flashback Databaseの取り消し = Recover Database によるロール・フォワード（Redo適
用）であるが、そのRedo内にDatafileの追加が含まれる場合には、ORA-01244が発生し
て、リカバリができません。
• Workaround
– SET NEWNAMEで正しいファイル・パスを指定し、バックアップからRestore
• コマンド例は次のスライド参照
Datafileの追加処理のロール・フォワードはRestoreが必須
82

Flashback Databaseの取り消しでORA-01244
Datafileの追加処理のロール・フォワードはRestoreが必須
SQL> recover database ; -- Flashback Databaseの取り消し
ORA-00283: エラーによってリカバリ・セッションは取り消されました。
ORA-01244: 名前のないデータファイルがメディア・リカバリで制御ファイルに追加されました
ORA-01110: データファイル7:'+DATA/orcl/datafile/test.dbf'
RMAN>
run{
set newname for
datafile '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00007'
to '+DATA/orcl/datafile/test.dbf';
restore tablespace 'TEST';
recover database;
}
83

バックアップ済みArchive Logとリカバリ
• 前提知識
– リカバリは、SQL*Plus or RMANユーティリティの両方で実行可能
• Problem
– SQL*Plusでリカバリを実行した場合、必要となるArchive Logがバックアップとして存在し
ていても、自動読み込みはされない
• Workaround
– RMANから実行する
– バックアップ済みのArchive Logをリストア後に、SQL*Plusでリカバリを実行する
RMANは自動で読み込むが、SQL*Plusでは個別Restoreが必要
84

しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニング

しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニング

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニング

Similar to しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニング (20)

More from オラクルエンジニア通信

More from オラクルエンジニア通信 (20)

Recently uploaded

Recently uploaded (11)

しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニング