【Oracle DBA & Developer Day 2014】しばちょう先生による特別講義！ RMANの運用と高速化チューニング

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

| Program Agenda 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

| 様々なバックアップ方式 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

| Zero Data Loss Recovery Applianceの登場 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開始 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 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 Data File 22

| バックアップの運用ポリシー 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' を指定した増分適用の実施 • 上記の例では、Backup Windowは22:00-22:30までの30分間 (= 30/60/24を加える) これが意外と難しい。でも、Recovery Applianceならば考える必要が無くなる！！ 27

| オンラインで取得したバックアップの中には、バックアップ期間中に更新されたブロックも含まれるバックアップの開始地点ではなく、終了地点以降のリカバリで使用可能 28 +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 (高速リカバリ領域) 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

| 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コマンドでバックアップの破損チェックを検討 40

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

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

| 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では、最新のバックアップがリストアされる為 43

| 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'; 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接続が必須数値のみ指定可能 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'; 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' ;} 文字列指定可能 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 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サイズ 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重暗号化 (暗号化された列は、暗号化されていないものとして扱われる） – 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 ;

| 非同期I/Oのデータ読込み性能の確認（2） • 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のデータ読込み性能の確認（2） • 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のデータ読込み性能の確認（3） • 非同期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

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

| 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

| 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%に制限 75

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

| Database Resource Manager 実装例(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 [email protected] (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

【Oracle DBA & Developer Day 2014】しばちょう先生による特別講義...

【Oracle DBA & Developer Day 2014】しばちょう先生による特別講義！ RMANの運用と高速化チューニング

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript