#odddtky Oracle DBA & Developer Days 2014 for your Skill 使える実践的なノウハウがここにある しばちょう先生による特別講義! RMAN Backup の 運用と高速化チューニング 柴田長シニア マネジャー Applied Technology,

しばちょう先生による特別講義！

RMAN Backup

の

運用と高速化チューニング

柴田 長

シニア・マネジャー

Applied Technology, Database & Exadata

Database Engineering, Product Strategy

Database Business Unit, Oracle Japan

Oracle DBA & Developer Days 2014

for your

Skill

使える実践的なノウハウがここにある

•

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

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

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

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

を行う際の判断材料になさらないで下さい。オラクル製品に関して記載さ

れている機能の開発、リリースおよび時期については、弊社の裁量により

決定されます。

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

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

自己紹介

“しばちょう”こと柴田長（しばた つかさ）と申します。

日本オラクル株式会社

データベース事業統括 製品戦略統括本部

データベースエンジニアリング本部

Database & Exadata技術部 応用技術グループ

シニアマネジャー

Oracle Technology Networkで毎月連載中

「しばちょう先生の試して納得！DBAへの道」

アジェンダ

1

2

3

4

5

はじめに

高速増分バックアップ

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

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

押さえておきたい注意点

本資料を作成する上で参考にした資料

•

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）

バックアップ要件とは？

•

Recovery Time objective (RTO)

–

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

•

Recovery Point Objective (RPO)

–

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

•

Backup Retention Policy

–

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

•

Additional Questions

様々なバックアップ方式

Oracle Exadata Backup Destination Options

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

Oracle Zero Data Loss Recovery Applianceの登場

Oracle Exadata Backup Destination Options

Fiber Channel

SAN

10GigE or

InfiniBand

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について

–

高速増分バックアップの動作

–

チューニング方法

–

注意すべきポイント

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)

高速増分バックアップ

•

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 ;

高速増分バックアップ

•

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

--- --

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’

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

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

•

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

のみを読込む

–

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

–

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

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

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

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

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

Small READになりやすい

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

Large READになりやすい

Block Change Tracking File

•

可用性

–

RMANでBCF File自体のバックアップは非サポート

–

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

–

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

•

Image Copy Backup（Level0）は必要ありません（良く誤解されている）

•

バージョニング

–

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

•

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

•

隠しパラメータで拡張可能（Doc ID 1736769.1 / KROWN#122168）

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)

増分適用（増分更新）

•

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'

増分適用時の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

Small I/O or Large I/O Read

Level1

を読み込んで、

増分バックアップの種類

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

•

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が破損していて増分適用が失敗した場合、差分増分ではバックアップ・ジョブを止めて、手動で

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

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

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のバックアップを識別する為に必須

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

•

例えば、毎日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）' を指定した増分適用の実施

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

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

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

高速増分バックアップ

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

+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

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日”を忘れがちです!!

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に関しては、こちらの設定にも従う（後述）

BACKUP RETENTION POLICY（保持ポリシー）

•

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

どちらか一方

を設定

•

方針を満たさない

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

–

リカバリ期間

•

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

–

冗長性（

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

）

•

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

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

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

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

•

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

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

–

冗長性を指定したBACKUP RETENTION POLICY

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

–

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

•

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

–

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

RECOVERコマンド実行時には、

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

為、

RECOVERコマンドにUNTIL句を追加し、レベル0を増分更新する時点を指定

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 ;

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

○

×

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 ;

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#や日付を指定して実行しなければならない

カタログ・データベース

•

メリット

–

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

 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

CONTROL_FILE_RECORD_KEEP_TIME

•

CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータ

–

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

•

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

–

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

–

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

•

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

–

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

Doc ID 1734969.1 / KROWN#120064

Sample Backup Script 1 – (1)

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

Recovery Window: 1日間

 Level0

が

₂

世代分の

_FRA

領域が必要

RMAN> #事前設定

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

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY

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

CONFIGURE COMPRESSION ALGORITHM 'LOW' ; # ArchiveLog Backup用

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

run{

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

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

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

Sample Backup Script 1 – (2)

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

Recovery Window: 1日間

 Level0

が

₂

世代分の

_FRA

領域が必要

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

run{

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

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

BACKUP INCREMENTAL LEVEL 1 cumulative FOR RECOVER OF COPY

WITH TAG 'INCR_UPDATE' DATABASE ;

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



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

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

Sample Backup Script 2

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

 1

世代の

_Backup

RMAN> #事前設定

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

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY

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

CONFIGURE COMPRESSION ALGORITHM 'LOW' ; # ArchiveLog Backup用

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

run{

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

VALIDATE CHECKLOGICAL DATAFILECOPY ALL NODUPLICATES DEVICE TYPE DISK ;

DELETE NOPROMPT OBSOLETE ;

BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY

WITH TAG 'INCR_UPDATE' DATABASE ;

Sample Backup Script 3 – (1)

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

Recovery Window: 7日間

 2

世代（最新の

_{Level0 &}

過去

₇

日以内にリカバリ可能な

_{Level0+Level1}

）

RMAN> #事前設定

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

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY

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

CONFIGURE COMPRESSION ALGORITHM 'LOW' ; # ArchiveLog Backup用

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

run{

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

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

Sample Backup Script 3 – (2)

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

Recovery Window: 7日間

 2

世代（最新の

_{Level0 &}

過去

₇

日以内にリカバリ可能な

_{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コマンドの実行が必要

Oracle Zero Data Loss Recovery Applianceの登場

•

世代数（複雑なバックアップ・スクリプト）からの解放

–

ZDLRAで設定するのは、どの時点までリカバリしたいのか？だけ！

•

データベース側では、高速増分バックアップ（累積）を繰り返すのみ

•

ZDLRA内では、そのLevel1を用いて仮想フルバックアップが構成される為、

Level0の数（世代数）を完全に意識する必要が無い

–

その為に、前述のBackup Script3のような若干トリッキーなバックアップ運用は不要

•

本セクションで完璧な理解が必要となるのは、（多分）Archive Logの管理!?

•

もちろん、ZDLRA側には全てのRedoレコードが転送されているので、誤って削除してしまっても安心

バックアップ運用の簡素化を実現

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)へブロックを書き出す

RMAN Backup Data Flow

Overview

Read

Write

Copy

Restore処理は逆フロー

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間

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が分散されるように構成

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を割り当てる

自動チャネル割り当て

•

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

自動チャネル割り当て

•

各インスタンスの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

接続が必須

数値のみ

指定可能

手動チャネル割り当て

•

事前に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' ;}

文字列

指定可能

SYSBACKUP

with Oracle Database 12c Release 1

•

クローズ状態のデータベースへの接続機能を含め、バックアップおよびリカ

バリに必要な権限を含む

–

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

–

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

のかわりにSYSBACKUPを付与

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

前述した

_Target

接続や

_Channel

割り当て時の

_SYS

のパスワード管理が不要

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

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

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,

ELAPSED_TIME/100 "ELPD(SEC)",

BUFFER_SIZE

,

BUFFER_COUNT

,

TOTAL_BYTES/1024/1024 "TOTAL_MB",

IO_COUNT, READY, SHORT_WAITS, LONG_WAITS,

FILENAME

from GV$BACKUP_ASYNC_IO

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

order by INST_ID, USE_COUNT, TYPE ;

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

GV$BACKUP_ASYNC_IO in Level0 Image Copy Backups with 2node

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

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---1 ---1 02/27 ---1---1:24:56 02/27 ---1---1: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サイズ

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

Copy Phase

•

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

–

Compression: 圧縮レベルを下げる（LOW / MEDIUM)

–

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

–

TDE Tablespace Encryption:

•

Compressed & Encrypted backupの場合、

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

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

圧縮しないことを検討

•

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

–

Validate Block:

•

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

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初期化パラメータの設定には依存しない

Copy Phase

•

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

–

読込み元ブロックに対して、Physical Corruption Checkを通過したブロック

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

–

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

•

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

Validate Block(Logical Corruption Check)

RMAN Command

Description

VALIDATE …

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

Corruption検出時の動作

•

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

Logical Corruptionの合計数

–

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

•

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

–

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

•

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

–

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

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

–

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

•

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

SET MAXCORRUTコマンド

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を自動設定

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

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

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

非同期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の回数

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

•

非同期I/Oの特徴

–

非同期処理は複数のタスクの同時発生を伴う

–

OracleのI/Oは、各I/O要求の完了を知るために、

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

•

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

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

–

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

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

非同期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待機数

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

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 ;

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

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

•

次の方法で、RMAN Backupを長時間かけて実行することで、

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

–

Database Resource Manager 

しばちょう先生の連載 第

23

回

•

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

–

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

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

•

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

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

–

BATCH_GROUPを使用したリソース・プランを設定、使用するだけで制御可能

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;

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

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

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

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

バックアップ中にデータファイルが消された際の挙動

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はデータファイル毎でバージョン管理されている為、

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

Standby Databaseで高速増分バックアップ

•

Problem

–

Checkpointが実行されなければ、BCT Fileを使用することが不可能な為、

Primary Database側でLog Switchがされなければ、Standby Database側で差分ブロック

が無いこととなり、バックアップがスキップされる。

•

Workaround

–

Standby Database側で高速増分バックアップを実施する直前に、

Primary Database側でLog Switchの実行を推奨

Flashback Databaseの取り消しでORA-01244

•

Problem

–

Flashback Databaseの取り消し = Recover Database によるロール・フォワード（Redo適

用）であるが、そのRedo内にDatafileの追加が含まれる場合には、ORA-01244が発生し

て、リカバリができません。

•

Workaround

–

SET NEWNAMEで正しいファイル・パスを指定し、バックアップからRestore

•

コマンド例は次のスライド参照

Datafileの追加処理のロール・フォワードはRestoreが必須