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

Transcription

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

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

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

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

5 本日の目的とゴール 目的 益々重要な機能となってきた Recovery Manager(RMAN) の活用レベルをあげる ゴール 高速増分バックアップの動作を理解する RMAN チューニング方法のポイントを知る RMAN 利用時の注意するポイントを知る 5

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

7 バックアップ要件と実装機能目標復旧時間 / リカバリタイム目標 Recovery Time objective (RTO) バックアップ & リカバリ要素技術 物理データ保護 Recovery Manager (RMAN) Automatic Storage Management (ASM) Data Guard 論理データ保護 Flashback テクノロジ Recovery Manager (RMAN) リカバリ分析 データ リカバリ アドバイザ Disaster Recovery 物理データ保護 Data Guard 目標復旧時間 / リカバリタイム目標 (RTO) Days / Hours Minutes / Seconds / Zero Hours / Minutes 問題特定時間の最小化 目標復旧時間 / リカバリタイム (RTO) Minutes / Seconds 7

8 様々なバックアップ方式 InfiniBand Network Storage Expansion Rack 高速なバックアップとリストア ILM アーカイブ Second DATA2 Disk Group Expansion of DATA Ethernet Oracle Secure Backup Admin Server Oracle Secure Backup Media Servers 10GigE or InfiniBand Network Fiber Channel SAN Tape library オフサイトバックアップ 10GigE or InfiniBand Network ZFS Storage Appliance データベース それ以外のバックアップ スナップショット クローン 8

9 RMAN の構成 テープへバックアップを取得する場合 別途 メディア管理ソフトウェアが必要例 ) Oracle Secure Backup メディアマネージャ テープ ライブラリへのバックアップ ターゲット データベース サーバプロセス 制御ファイル データファイル アーカイブ REDO ログ 初期化パラメータファイル オンライン REDO ログ バックアップ対象 ( 初期化パラメータファイルは SPFILE のみ ) RMAN 高速リカバリ領域 クライアント 制御ファイル データファイル アーカイブ REDO ログ ディスク バックアップ 初期化パラメータファイル 9

10 Program Agenda はじめに高速増分バックアップバックアップの運用ポリシー RMANバックアップのチューニング押さえておきたい注意点 10

11 高速増分バックアップ (Enterprise Edition 機能 ) 特徴 バックアップに要する時間 増分バックアップ データ ファイル全体を読み込み 更新のあったブロックをコピーする 全体バックアップと比較して変わらない 高速増分バックアップ (Enterprise Edition) データの変更時に更新ブロック情報を記録 バックアップ時は記録されたブロックのみを読み込み 全体バックアップと比較して短縮可能 イメージ図 水火月 月水火 火月水 水月火 RMAN 水水水水 水火月 CTWR 月水火 火月水 水月火 ブロック チェンジ トラッキング ファイル RMAN 水水水水 11

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

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

14 高速増分バックアップ BCT File への書き出し BCT File を有効化すると Large Pool 内に CTWR dba buffer を確保し バックグラウンド プロセス CTWR が起動 SQL> select pool,name,sum(bytes) from v$sgastat where name like 'CTWR%' group by pool,name; large pool CTWR dba buffer BCT File への書き出しの流れ サーバープロセスが更新ブロック情報を CTWR dba buffer へ書き込む CTWR がトランザクションと非同期で buffer から随時 BCT File へ書き出し Checkpoint 時に CTWR dba buffer と BCT File の間で同期が取られる 14

15 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 Incremental Rman Backup High Waits On 'block change tracking buffer space サポートの指示に従って設定を行って下さい 15

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

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

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

19 増分更新バックアップ Level1 のバックアップを Level0 のバックアップに適用して運用する 取得済みのイメージ コピー形式の Level0 の増分バックアップに対し Level1 の増分バックアップで取得した内容を更新 ( ロール フォワード ) 適用すべき Level1 や Archive Log を最小化することでメディアリカバリの処理時間を短縮 1 日目 A B C D E F 2 日目 A B H D E F G 3 日目 A B H D I F G J レベル 0 の増分バックアップ レベル 1 の増分バックアップ 増分更新バックアップ レベル 1 の増分バックアップ A B C D E F A B C D E F G H A B H D E F G I J 19

20 増分適用 ( 増分更新 ) Level0 Image Copy Backup を Level1 Backup で Roll Forward 適用する Level1 を制御することが可能 何も気にしなければ 全ての Level1 が適用されて Level0 は最新化 数日前にリカバリ出来ること という要件がある場合は UNTIL 句を指定する RMAN> # 7 日前の任意の地点へリカバリできる Level0 になるよう Level1 を適用 RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE' UNTIL TIME 'SYSDATE-7' ; 20

21 増分適用時の I/O Level0 Image Copy Backup を Level1 Backup で Roll Forward Level1 を読み込んで Level0 へ上書き (Level0 のブロックは読み込まれない ) Small I/O or Large I/O Read Data File 高速増分バックアップ Level 1 Backup Level1 を読み込んで Level0 の該当ブロックのみ上書き 増分適用 Level 0 Image Copy Backup 21

22 Program Agenda はじめに高速増分バックアップバックアップの運用ポリシー RMANバックアップのチューニング押さえておきたい注意点 22

23 増分バックアップの種類差分増分バックアップと累積増分バックアップ マルチレベル増分バックアップ 差分 累積 23

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

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 のバックアップを取得する 25

26 増分適用とバックアップ実行のタイミングこれが意外と難しい でも 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 の数をリカバリ ウィンドウ要件に +1 した FRA( 高速リカバリ領域 ) の容量設計が必要 もしくは UNTIL 'SYSDATE-(1+Backup Window)' を指定した増分適用の実施 26

27 オンラインで取得したバックアップの中には バックアップ期間中に更新されたブロックも含まれるバックアップの開始地点ではなく 終了地点以降のリカバリで使用可能 Data Files SCN:300 22:10 Bkup 開始 高速増分バックアップ dbwr SCN:310 22:20 前回 Level1(SCN:200) Level0 Image Copy Backup SCN:100 DML SCN:320 22:30 Bkup 完了 増分適用 ( UNTIL 'SYSDATE-1' ) 最新 Level1(SCN:300) 前回 Level1(SCN:200) 増分適用翌 22:00 バックアップ期間中 (SCN=310) に更新されたブロック ( 緑色 ) も含まれている為 SCN=320(22:30) 以降の時点へのリカバリにしか使用不可 Level0 SCN:200 +DATA DG +FRA DG 27

28 高速リカバリ領域 / Fast Recovery Area (FRA) バックアップ関連のファイルを配置するディスク領域 高速リカバリ領域に保存されたバックアップは必要に応じて削除されます 管理者の指定した 保存方針 により不要となったバックアップ アーカイブ REDO ログファイルなど 初期化パラメータファイルにて設定 位置 : DB_RECOVERY_FILE_DEST サイズ :DB_RECOVERY_FILE_DEST_SIZE Oracle Database を構成するファイル群が格納されているディスクとは別のディスクへ配置 多重化 Oracle Database 制御ファイル REDOログファイルデータファイル初期化パラメータファイル高速リカバリ領域制御ファイル REDOログファイルアーカイブ ログバックアップセットイメージ コピー 28

29 高速リカバリ領域 / Fast Recovery Area (FRA) サイジング考え方 リカバリ対象 制御ファイル / アーカイブログファイル コメント バックアップ間で生成されるアーカイブログ全体サイズの推定 x 2 フラッシュバックログ (Redo 量 x フラッシュバックできる時間の上限 ) x 2 イメージコピー バックアップセット (full) 増分バックアップ データベースサイズから一時ファイルのサイズを除く 全体バックアップの数 x 推定サイズ 増分バックアップの数 * x 推定サイズ * リカバリ可能とする日数 +1 日 を忘れがちです!! 例えば 一週間以内の任意の地点へリカバリする要件であれば 8 日分 29

30 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 が設定されていれば Archive Log に関しては こちらの設定にも従う 30

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

32 増分更新バックアップの保持ポリシーは冗長性を推奨 Doc ID 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 を増分更新する時点を指定 32

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

34 Archive Log の削除コマンド BACKUP RETENTION POLICY & ARCHIVELOG DELETION POLICY Archive Log を削除する RMAN コマンドは次の二つであり バージョン毎に動作が異なる RMAN Command DELETE ARCHIVELOG ALL; DELETE OBSOLETE; (Archive Log 以外も削除対象 ) Release BACKUP RETENTION POLICY ARCHIVELOG DELETION POLICY 共通 ~ ~ 34

35 Archive Log の削除例 DELETE OBSOLETE ; ( ~) 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 ; 35

36 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

37 Sample Backup Script 1 (1) 日曜日はフルバックアップ & 月 ~ 土曜日は高速増分バックアップ ( 累積 ) Recovery Window: 1 日間 Level0 が 2 世代分の FRA 領域が必要 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{ 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' ;} 37

38 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 の容量設計に注意 H/W リソースに余裕があれば VALIDATE コマンドでバックアップの破損チェックを検討 38

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

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

41 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 コマンドの実行が必要 UNTIL 句を指定しない RESTORE では 最新のバックアップがリストアされる為 41

42 Recovery Manager リポジトリとリカバリ カタログ複数の Oracle Database のバックアップ状況を一元管理 Recovery Manager リポジトリ Recovery Manager がバックアップ リカバリおよびメンテナンスに使用する ターゲット データベースに関するメタデータのコレクション 制御ファイルに格納 ( 領域に制限有り ) 初期化パラメータファイル :CONTROL_FILE_RECORD_KEEP_TIME( デフォルト 7 日 ) リカバリ カタログを作成し リポジトリを長期間保存可能 複数の Oracle Database のバックアップ状況を一元管理できます リポジトリ用途は無償 ターゲット データベース ターゲット データベース ターゲット データベース カタログ スキーマ 制御ファイル 制御ファイル 制御ファイル リカバリ カタログ 42

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

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

45 Program Agenda はじめに高速増分バックアップバックアップの運用ポリシー RMANバックアップのチューニング押さえておきたい注意点 45

46 RMAN によるバックアップ作成フロー Overview 読取りフェーズ RMAN チャネル ( サーバー プロセス ) が Disk から入力バッファへブロックを読み込む コピー フェーズ RMAN チャネルが入力バッファから出力バッファへブロックをコピーする ここで ブロックに対する追加処理が行われる 必要に応じて検証 / 圧縮 / 暗号化の実行 書込みフェーズ RMAN チャネルが出力バッファからストレージ (Disk or SBT) へブロックを書き出す 46

47 RMAN によるバックアップ作成フローイメージ Read Copy Write Restore 処理は逆フロー 47

48 Tuning Principles 1. Storage の I/O 性能 Network スループットの限界を把握 RMAN Backup チューニング前に環境の I/O 性能を測定 Oracle ORION Calibration Tool 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 ベンチマークツールで測定 Database サーバー Tape System 間 48

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

50 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 を扱う テープへのバックアップ : 一つの Tape Drive 毎に 一つの Channel を割り当てる 50

51 自動チャネル割り当て 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> ; 51

52 自動チャネル割り当て Doc ID / KROWN# 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'; 事前設定時にはパスワード不要ただし 実際に Channel を使用する際 パスワードを明示指定した Target 接続が必須 $ rman target sys/<password> RMAN> # 事前設定された自動チャネル割り当てを使用した Level0 Image Copy Backup BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'INCR_UPDATE' ; 52

53 手動チャネル割り当て Doc ID / KROWN# RAC 環境でのチャネル割り当てについて 事前に CONFIGURE コマンドで設定せずに run{} 内で手動割り当て 設定例 :2 ノード RAC で インスタンス毎に 2 つの Channel 割り当て ( 合計 4 つ ) 文字列指定可能 $ 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' ;} run{} 内の ALLOCATE CHANNEL コマンドで設定した値は run{} 内でのみ有効 53

54 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 の時間が 実際のバックアップの時間より大幅に短い場合は 出力デバイスへの書込みがボトルネックになっている可能性がある コピーおよび書込みのフェーズのチューニング 54

55 読取りフェーズのチューニング Doc ID RMAN Performance Tuning Using Buffer Memory Parameters ASM 環境における Buffer は最適な性能が得られるように自動設定 Channel( サーバー プロセス ) 毎に 入力バッファが PGA に割り当てられる Buffer の数 サーバー プロセスが同時に発行出来る非同期 I/O 数 ASM Diskgroup の Disk 数に応じて自動調整 一つの Buffer のサイズ サーバー プロセスが発行する非同期 I/O の最大 I/O サイズ ASM Diskgroup の Allocation Unit のサイズ 55

56 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 ; 56

57 Input/Output Buffer の数とサイズの確認 GV$BACKUP_ASYNC_IO in Level0 Image Copy Backups with 2node Input or Output を判別可能 一つの Buffer サイズ Buffer の数 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 /27 11:24:56 02/27 11:26: AGGREGATE UNKNOWN /27 11:24:56 02/27 11:26: INPUT FINISHED , DATA/orcl/datafile/jpet.271.xxx /27 11:24:55 02/27 11:26: OUTPUT FINISHED FRA/orcl/datafile/jpet.386.xxx /27 11:24:52 02/27 11:26:03 15 AGGREGATE UNKNOWN /27 11:24:52 02/27 11:26:03 15 INPUT FINISHED , DATA/orcl/datafile/sysaux.260.xxx /27 11:24:50 02/27 11:26:03 15 OUTPUT FINISHED FRA/orcl/datafile/sysaux.607.xxx /27 11:26:28 02/27 11:26:36 15 AGGREGATE UNKNOWN /27 11:26:28 02/27 11:26:36 15 INPUT FINISHED DATA/orcl/datafile/users.279.xxx /27 11:26:28 02/27 11:26:38 15 OUTPUT FINISHED FRA/orcl/datafile/users.646.xxx /27 11:26:49 02/27 11:26: AGGREGATE UNKNOWN /27 11:26:49 02/27 11:26: INPUT FINISHED DATA/orcl/datafile/tbs64k.268.xxx /27 11:26:49 02/27 11:26: OUTPUT FINISHED FRA/orcl/datafile/tbs64k.661.xxx /27 11:26:56 02/27 11:26: AGGREGATE UNKNOWN /27 11:26:56 02/27 11:26: INPUT FINISHED DATA/orcl/datafile/tbs4m.257.xxx /27 11:26:56 02/27 11:26: OUTPUT FINISHED FRA/orcl/datafile/tbs4m.373.xxx /27 11:26:58 02/27 11:26:59 15 AGGREGATE UNKNOWN /27 11:26:58 02/27 11:26:59 15 INPUT FINISHED DATA/orcl/datafile/tbs xxx /27 11:26:58 02/27 11:26:59 15 OUTPUT FINISHED FRA/orcl/datafile/tbs xxx /27 11:27:02 02/27 11:27: AGGREGATE UNKNOWN /27 11:27:02 02/27 11:27: INPUT FINISHED /u01/app/oracle/product/11.2.0/xxx /27 11:27:02 02/27 11:27: OUTPUT FINISHED FRA/orcl/autobackup/2014_02_27/xx /27 11:24:43 02/27 11:25:10 16 AGGREGATE UNKNOWN /27 11:24:43 02/27 11:25:10 16 INPUT FINISHED , FRA/orcl/datafile/undotbs1.xxx /27 11:24:43 02/27 11:25:12 16 OUTPUT FINISHED FRA/orcl/datafile/undotbs1.336.xxx /27 11:24:45 02/27 11:25:14 15 AGGREGATE UNKNOWN /27 11:24:45 02/27 11:25:14 15 INPUT FINISHED , FRA/orcl/datafile/undotbs2.383.xxx /27 11:24:44 02/27 11:25:15 15 OUTPUT FINISHED FRA/orcl/datafile/undotbs2.652.xxx /27 11:26:31 02/27 11:26:48 16 AGGREGATE UNKNOWN /27 11:26:31 02/27 11:26:48 16 INPUT FINISHED , FRA/orcl/datafile/undotbs3.411.xxx /27 11:26:30 02/27 11:26:48 16 OUTPUT FINISHED FRA/orcl/datafile/undotbs3.537.xxx /27 11:26:30 02/27 11:26:44 15 AGGREGATE UNKNOWN /27 11:26:30 02/27 11:26:44 15 INPUT FINISHED DATA/orcl/datafile/system.270.xxx /27 11:26:29 02/27 11:26:45 15 OUTPUT FINISHED FRA/orcl/datafile/system.428.xxx 57

58 読取りフェーズのチューニング 基本的には RMAN チャネル数を増加させることで対処可能 ASM 環境であれば 最適な Buffer の数とサイズに自動調整されている Disk の I/O 性能を全て引き出せてない かつ CPU や Memory に空きがある場合に限り 入力バッファの数とサイズを増加させることが可能 ただし 隠しパラメータにつき サポートの指示に従って設定して下さい 次の Doc 内の PDF ファイル (rman_buffer.pdf) を参照 Doc ID RMAN Performance Tuning Using Buffer Memory Parameters 58

59 読取りフェーズのチューニング 多重化のレベルの調整 ASM ストライプ化されたディスク推奨事項 なし あり 多重化のレベルを上げます MAXOPENFILESまたは各バックアップ セット内のファイル数のいずれが最小値かを確認してから この値を増やす RMANがテープ バッファを一杯にする速度を上げ ストリームを継続するのに十分な速度でバッファがメディア マネージャに送信される確率を高くする なしなしチャネル上の MAXOPENFILES 設定値を増やす あり該当なしチャネルの MAXOPENFILES パラメータを 1 または 2 に設定する 特に高速増分ではない増分バックアップのときに検討 59

60 コピー フェーズ RMAN バックアップ時の検証 / 圧縮 / 暗号化ガイドライン CPU リソースを非常に消費する処理のため CPU 増設もしくは下記を実施 Compression: 圧縮レベルを下げる (LOW / MEDIUM)( 要 :Advanced Compression) TDE 列暗号化 : 2 重暗号化なので RMAN 側は暗号化しない TDE 表領域暗号化 : Compressed & Encrypted backup の場合 暗号化された表領域は復号された後 圧縮 再度暗号化される動作となる為 圧縮しないことを検討 その場合 暗号化されたブロックのままバックアップされる ブロック検証 : デフォルトで Physical Corruption のチェックが実行される 通常 この処理では CPU に負荷はかからない 60

61 コピー フェーズブロック検証 ( 物理破損検証 ) デフォルトで有効化 ( 推奨 ) NOCHECKSUM オプションで無効化が可能 ただし Block ヘッダやフッターの物理的な整合性チェックは無効化不可 読込み元ブロックに対して 埋め込まれているチェックサムを検証 DB_BLOCK_CHECKSUM 初期化パラメータの設定に依存 FALSE の場合 SYSTEM 表領域のみ TYPICAL or FULL の場合 全表領域が対象 ( 参照資料 ) 書込み先ブロックに対して チェックサムを計算して埋め込む DB_BLOCK_CHECKSUM 初期化パラメータの設定には依存しない 61

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

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

64 書込みフェーズ Channel 毎に割り当てられるバックアップの書き出し用の Buffer Default の設定 バッファ数 : 一つの Channel に 4 つの出力バッファが割り当てられる バッファサイズ :Disk 1MB / SBT 256KB Set BLKSIZE channel parameter >= media mgmt client buffer size Oracle Secure Backup の場合は変更の必要なし ASM Diskgroup への書き出しに関しては 最適な性能が得られるように書き込みバッファを自動設定 64

65 書込みフェーズチューニング 入力バッファと同様に 書込み先ストレージの I/O 性能を全て引き出せてない場合 RMAN 出力バッファの数とサイズを増加させて対処させることが可能 ただし 隠しパラメータにつき サポートの指示に従って設定して下さい 次の Doc 内の PDF ファイル (rman_buffer.pdf) を参照 Doc ID RMAN Performance Tuning Using Buffer Memory Parameters SBT(Tape): Oracle Secure Backup 使用時は自動調整の為 設定不要 65

66 非同期 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 ; 66

67 非同期 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 で同時にバックアップした場合は それらの合計値で比較する必要有り 67

68 非同期 I/O のデータ読込み性能の確認 (2) V$BACKUP_ASYNC_IO 応答時間 ( 長い順 ): LONG_WAITS > SHORT_WAITS > READY Column Name IO_COUNT READY SHORT_WAITS LONG_WAITS Description そのデータファイルをバックアップする為に発行した全ての非同期 I/O 数 待機することなく Buffer が使用可能であった非同期 I/O の回数 Buffer が直ぐに使用可能にならなかったが I/O 完了の為の nonblocking poll を実行した後に使用可能となった非同期 I/O の回数 Buffer が直ぐに使用可能にならず さらに blocking 待機 (AIOWAIT Call) 後に使用可能となった非同期 I/O の回数 処理中でも出力されるので 進捗確認にも使用可能 68

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

70 非同期 I/O のデータ読込み性能の確認 (4) V$IOSTAT_FUNCTION_DETAIL File Type 毎の詳細な I/O 統計 (I/O サイズの確認が可能 ) RMAN 処理を挟む形で 2 回取得することで差分を抽出する FUNCTION_NAME FILETYPE_NAME 主要な Column Name SMALL_READ_MEGABYTES / REQS SMALL_WRITE_MEGABYTES / REQS LARGE_READ_MEGABYTES / REQS LARGE_WRITE_MEGABYTES / REQS NUMBER_OF_WAITS Description RMAN DBWR LGWR 等の識別が可能 File Type の識別が可能 Small I/O size の読取りリクエスト MB / 数 Small I/O size の書込みリクエスト MB / 数 Large I/O size の読取りリクエスト MB / 数 Large I/O size の書込みリクエスト MB / 数 同期 I/O 待機数 WAIT_TIME 合計同期 I/O 待機時間 ( ミリ秒 ) 70

71 V$IOSTAT_FUNCTION_DETAIL Where FUNCTION_NAME = 'RMAN' 指定時の主な FILETYPE_NAME FILETYPE_NAME Control File Archive Log Archive Log Backup Data File Data File Incremental Backup Data File Backup Data File Copy 主な出力処理の例 制御ファイルに対する Read/Write Archive Log のバックアップ時の Read Archive Log の Backupset への Write データ ファイルのバックアップ時の Read データ ファイルの Backupset への Write 増分更新時の Level1 からの Read Image Copy Backup 取得の Write 増分更新時の Level0 への Write 71

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

73 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) /27 15:49:43 02/27 15:50: /27 15:49:43 02/27 15:50: /27 15:49:43 02/27 15:50:

74 RMAN Backup の消費リソースの平準化バックアップ時間を長くすることで 業務アプリへの影響を極小化 単位時間当たりの H/W リソース消費量を抑えることを目的にデータベースリソースマネージャを活用を検討 RMAN Backup を少ないリソースで長時間かけて実行することになる 業務アプリケーションのレスポンス タイムへの影響を極小化 道のり ( バックアップ処理量 ) = 速さ ( 単位時間当たりの H/W コスト ) x 時間 74

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

76 Program Agenda はじめに高速増分バックアップバックアップの運用ポリシー RMANバックアップのチューニング押さえておきたい注意点 76

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

78 ( 参考 ):SYSBACKUP 管理権限で実行できる操作 STARTUP SHUTDOWN ALTER DATABASE ALTER SYSTEM ALTER SESSION ALTER TABLESPACE CREATE CONTROLFILE CREATE ANY DIRECTORY CREATE ANY TABLE CREATE ANY CLUSTER CREATE PFILE データベースをオープンしていない場合でもデータベースに接続可能 CREATE RESTORE POINT(GUARANTEED リストア ポイントを含む ) CREATE SESSION CREATE SPFILE DROP DATABASE DROP TABLESPACE DROP RESTORE POINT(GUARANTEED リストア ポイントを含む ) FLASHBACK DATABASE RESUMABLE UNLIMITED TABLESPACE SELECT ANY DICTIONARY SELECT ANY TRANSACTION SELECT_CATALOG_ROLE SELECT X$ 表 V$ およびGV$ ビュー APPQOSSYS.WLM_CLASSIFIER_PLAN SYSTEM.LOGSTDBY$PARAMETERS DELETE/INSERT SYS.APPLY$_SOURCE_SCHEMA SYSTEM.LOGSTDBY$PARAMETERS EXECUTE SYS.DBMS_BACKUP_RESTORE SYS.DBMS_RCVMAN SYS.DBMS_DATAPUMP SYS.DBMS_IR SYS.DBMS_PIPE SYS.SYS_ERROR SYS.DBMS_TTS SYS.DBMS_TDB SYS.DBMS_PLUGTS SYS.DBMS_PLUGTSP 78

79 バックアップ中にデータファイルが消された際の挙動 RMAN Backup は異常終了する為 再実行が必要 RMAN> backup incremental level 1 for recover of copy with tag 'incr_update' database ; Starting backup at 17-DEC channel ORA_DISK_1: starting datafile copy input datafile file number=00008 name=+data/orcl/datafile/tbs4m output file name=+fra/orcl/datafile/tbs4m 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/ :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

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

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

82 Flashback Database の取り消しで ORA 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; } 82

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

84 まとめ バックアップ要件 リカバリ要件に即したバックアップ運用の実現に向けて 高速増分バックアップの活用 バックアップボトルネックのチューニング バックアップ保持期間の調整を駆使して安心 安全なデータベース運用を実現 84

85 Appendix 85

86 Oracle Database 12c 新機能 クロス プラットフォーム バックアップおよびリストアの拡張機能 RMAN では 全体および増分のバックアップ セットを使用することで プラットフォーム間でデータをトランスポートできます 増分バックアップを使用すると 表領域をプラットフォーム間でトランスポートする際に必要となるアプリケーション停止時間を減らすことができます 表および表パーティションのリカバリ RMAN では 以前作成された RMAN バックアップから 指定された時点に表および表パーティションをリカバリすることができます ネットワークを介したファイルのリカバリおよびリストア RMAN では バックアップ セットを使用し データベース データファイル 表領域または制御ファイルを フィジカル スタンバイ データベースからリカバリすることができます RMAN は ネットワークを介してバックアップ セットを宛先ホストに送信します これは スタンバイ データベースとプライマリ データベースを同期化する Data Guard 環境で役立ちます Storage Snapshot Optimization を使用したサード パーティのスナップショット テクノロジに対するサポートの改善 ストレージ スナップショットの最適化により ストレージ スナップショット テクノロジを使用し Oracle Database を BACKUP モードにしなくてもバックアップおよびリカバリできます スナップショット テクノロジは 特定の要件に準拠する必要があります 増分およびマルチセクション バックアップの改善 RMAN が提供するマルチセクション テクノロジ ( 大規模なファイルを複数チャネルでパラレルにバックアップおよびリストアできる ) を 増分バックアップとイメージ コピーの両方に適用できるようになりました アクティブなデータベース複製の拡張 RMAN で アクティブなデータベース複製の実行にバックアップ セットを使用できるようになりました 十分な補助チャネルが割り当てられると 補助インスタンスはターゲット インスタンスに接続し ネットワークを介してバックアップ セットを取得するため ターゲット インスタンスでの処理の負荷を軽減します 複製プロセスでは 未使用ブロックの圧縮を使用して ネットワーク上でトランスポートされるバックアップのサイズを削減することができます アクティブなデータベースの複製を実行している間 バックアップの暗号化とマルチセクション バックアップを使用することもできます 86

87 Zero Data Loss Recovery Appliance (Recovery Appliance) ゼロ データ ロス RPO の極小化 REDO ログ転送によるリアルタイム トランザクション保護データ破損の自動チェックにより確実な復旧を保証 膨らみ続けるバックアップコスト対策永遠に差分バックアップのみで運用 10 倍の容量効率を実現するアーキテクチャ あらゆるデータベースバージョンとプラットフォーム DB バージョン DB プラットフォームの違いを問わずバックアップを一元化 87

88 Zero Data Loss Recovery Appliance の登場バックアップ運用の簡素化を実現 世代数 ( 複雑なバックアップ スクリプト ) からの解放 ZDLRA で設定するのは どの時点までリカバリしたいのか? だけ! データベース側では 高速増分バックアップ ( 累積 ) を繰り返すのみ ZDLRA 内では その Level1 を用いて仮想フルバックアップが構成される為 Level0 の数 ( 世代数 ) を完全に意識する必要が無い 機能面 REDO 転送 メリット ほぼゼロ データ ロス ( 最新データを守れる ) 例えば 最新データは守りたいが 一部の DB しか対応できていない 仮想フルバックアップ 幅広いプラットフォーム対応 任意の時点にリカバリ ( ある断面でのステージング ) フルバックアップは 1 度永遠に差分で OK 数千 DB のバックアップ集約バックアップ品質アップ 災害対策はテープだけしかできていない データ量が多い DB 統合していて ウインドウの確保が たくさんのデータベース バックアップの方式 / 装置 / レベルがバラバラ 88

89 参考資料 Backup and Recovery Performance and Best Practices for Exadata Cell and Oracle Exadata Database Machine Backup and Recovery of Oracle Exadata: Experiences and Best Practices Doc ID Incremental Rman Backup High Waits On 'block change tracking buffer space Doc ID RMAN Performance Tuning Using Buffer Memory Parameters Oracle Databaseバックアップおよびリカバリ リファレンス 11gリリース2(11.2) Oracle Databaseバックアップおよびリカバリ ユーザーズ ガイド 11g リリース2(11.2) Oracle Databaseバックアップおよびリカバリ ユーザーズ ガイド 12cリリース1 (12.1) Oracle Databaseバックアップおよびリカバリ リファレンス 12cリリース1 (12.1) 89

90 Database Resource Manager 実装例 (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'); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'BK_PLAN', - GROUP_OR_SUBPLAN => 'BATCH_GROUP', MGMT_P2 => 10, - MAX_UTILIZATION_LIMIT => 10,comment => 'TEST'); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'BK_PLAN', - GROUP_OR_SUBPLAN => 'OTHER_GROUPS',MGMT_P2 => 90, comment => 'TEST'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; / * MAX_UTILIZATION_LIMIT で RMAN で使用する CPU 使用率を最大 10% に制限 90

91 Database Resource Manager 実装例 (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 BK_PLAN OTHER_GROUPS BK_PLAN BATCH_GROUP 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 BK_PLAN TRUE ON OFF 0 32 FULL 91

92 Database Resource Manager 実装例 (3) Resource Plan の効果を確認 SQL> set linesize 180 set pages 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 SYS_GROUP OTHER_GROUPS BATCH_GROUP _ORACLE_BACKGROUND_GROUP_ 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 SYS ACTIVE rman@vm11204.localdomain (TNS V1-V3) BATCH_GROUP 92

93 Oracle Recovery Manager 概要 93

94 Oracle Recovery Manager(RMAN) とは データベースのバックアップ リストアおよびリカバリを行うための Oracle ユーティリティを使用したバックアップ リカバリ方法 実行方法 2 種類 OS プロンプトから RMAN を起動しコマンドラインで実行 Oracle Enterprise Manager(EM) の GUI を使用して実行 % rman target / RMAN> bacbakup database; RMAN> restore database; RMAN> recover database; 94

95 RMAN を使う利点バックアップ管理を Oracle Database 自身で! Oracle Database がバックアップに必要な設定を管理 Oracle Database がバックアップすべきデータを認識 Oracle Database がバックアップ保存期間を認識 Oracle Database がバックアップ領域を管理 高速リカバリ領域 (FAST RECOVERY AREA) 利用 どこにバックアップを取得するか? どのファイルをバックアップするか? いつまで保存するか? 領域は十分にあるか? 2 週間前 1 週間前 3 週間前 これまでは DB 管理者の仕事 95

96 RMAN を使う利点迅速なリカバリを Oracle Database がサポート! Oracle Database がリカバリに必要なバックアップを自動的に選択 Oracle Database がリカバリ方法をアドバイス データ リカバリ アドバイザ 障害復旧 1. 障害の診断 2. 復旧手順の検討 3. 復旧操作 人間が考えている時間 リストア / リカバリの時間 修復に要した時間 障害解析に要した時間 総ダウンタイム 96

97 RMAN を使う利点操作の自動化 運用ミスを減らす バックアップ リカバリのコマンドがシンプルに OS コマンド ( 複雑な Shell) と組み合わせなくても良い コマンド スクリプトの可読性 メンテナンス性が高まる RMAN> backup database; Oracle Database でバックアップすべき全データを保存 データファイル ( バックアップ セット ) 制御ファイル (configure で設定 ) 初期化パラメータ ファイル (SPFILE のみ Configure で設定 ) RMAN> backup database plus archivelog ; 上記に加えて アーカイブ REDO ログファイルもバックアップ対象にする 97

98 RMAN を使う利点 Oracle Database の仕組みを最大限に利用 バックアップ モード不要 データブロック単位での読み書き 破損ブロックの検証 増分バックアップ 高速増分バックアップ (EE) 未使用データの圧縮 ( スキップ ) (EE) バイナリ圧縮 (Advanced Compression) BASIC アルゴリズムでの圧縮は標準機能 ブロック メディア リカバリ (EE) バックアップ リカバリ単位がファイルからブロックへ 98

99 RMAN で取得できるバックアップ タイプ全体バックアップと増分バックアップ 全体バックアップ すべての割当て済みブロックを対象とする イメージ コピーもしくはバックアップ セットの形式で取得 増分バックアップよりリストアが高速 毎回すべての割当済みブロックをコピーするので多くの領域が必要 増分バックアップ 以前のバックアップアップ以降に変更されたブロックのみを対象とする 差分増分 と 累積増分 の 2 種類 一回のバックアップ量が少ないためバックアップ サイズを小さくできる リストア時 全体 + 差分の適応 日月火水木日月火水木 差分増分 累積増分 99

100 RMAN で可能なその他のバックアップに関する設定 バックアップに関する設定の一覧確認と変更方法 バックアップの最適化 自動チャネルの割り当てのデフォルトのデバイス タイプ 制御ファイルの自動バックアップ バックアップの並列度とバックアップ タイプ バックアップの多重度 暗号化バックアップに使用するアルゴリズム 圧縮バックアップに使用するアルゴリズム スナップショット制御ファイルの保存先 100

101 物理バックアップユーザ管理バックアップと Oracle Recovery Manager ユーザ管理バックアップ OS 提供のコピーコマンドと SQL コマンドを併用するバックアップ方法 バックアップ関連ファイルを管理者が管理する バックアップ対象データファイルとその格納場所 バックアップの世代管理と不要なファイルの削除 リカバリ作業時に 障害に応じたリストア対象ファイルの特定と正しい場所へのリストア作業 ファイルのタイプによってバックアップ方法が異なる 制御ファイル データ ファイル OS 提供のコピーコマンドを利用するので ファイル破損があったとしても検知できない ストレージ機能を使ったバックアップ時に利用 Oracle Recovery Manager (RMAN) Oracle Database のバックアップ リストア リカバリをおこなうためのユーティリティ バックアップ関連ファイルを Oracle Database 自身が管理する バックアップ状況を Oracle Database の制御ファイルに保存し リストア リカバリ時に活用 バックアップ状況を外部のリカバリ カタログに登録することで 複数のバックアップの一元管理が可能 プラットフォームを問わず 同じコマンドで対処可能 ファイル破損を検知可能 ファイル よりも小さな Oracle Block 単位でのバックアップ リストア リカバリが可能 RMAN 独自機能が利用可能 101

102 参考 ) バックアップ リカバリ ( リストア ) の単位 基本的にはファイル単位 バックアップ リストア データファイル 1 データファイル 1 データファイル 1 データファイル 1 データファイル 2 データファイル 2 データファイル 2 データファイル 2 データファイル 3 データファイル 3 データファイル 3 データファイル 3 表領域 ( オンライン ) バックアップ領域 表領域 ( オフライン ) バックアップ領域 ファイルよりも小さな粒度 ( データブロック単位 :RMAN 使用 ) バックアップ リストア データファイル データファイル 表領域 ( オンライン ) バックアップ領域 表領域 ( オンライン ) バックアップ領域 102

103 103

104