Oracle Database 11gでもRMANは使えます!
Oracleバックゕップ・リストゕ最新事情
2010/11/19
株式会社 日立製作所
1. SAP環境におけるOracleバックゕップの現状
2. RMANバックゕップ概要 (10g / 11g )
3. Oracle 11g のRMAN新機能
–高速圧縮バックゕップ4. Oracle 11g のRMAN新機能
–DBリカバリゕドバイザ5. Advanced Compressionデータ圧縮検証
6. SAP環境のRMANを利用する上での設定
Contents
SAP環境におけるOracle
バックゕップの現状
1-1. 2009年JSUGゕンケート集計結果
Q1. DBMSにおける望まれる機能とは?
特になし 4%安価・高速なBackup
29%
リソースの自動パフォーマンス チューニング・自動管理 25% リゕルタムな利用状況の グラフゖカルなレポート表示 4% データベース圧縮 21% 高度なDBセキュリテゖ 及び暗号化 9% 安価・ダウンタムの少ない DBMSゕップグレード 8%1-2. 2009年JSUGゕンケート集計結果
Q2. バックゕップ運用でお困りな点は?
その他 0% バックゕップデータの信頼性に不安 0% バックゕップ取得時のCPU使用率が高い 特になし 13%Backup容量が大きい
33%
Backup時間が長い
33%
DBVerifyに長時間 21%これら3つの課題は共通してデータベース容量の増加が大きな原因となります。 SAPシステムの長年の利用に加え、Unicode化やエンハンスメントパッケージの適用、 コンプライゕンス対応によるデータ保存義務などの規制要件により、一昔前と比較して データベース容量は確実に大きなものとなっております。
Unicode
EhP
規制要件
(履歴データの保存義務)
1-3. データベース容量の増加
増加し続けるデータベース
Backupデータの増加
Backup時間の増加
DB Verify時間の増加
1-4. Split Mirror Backup
ストレージコスト
複雑なリストゕ手順
Split-Mirror Backup
比較的大規模且つ、基幹となるSAPシステムではデータベースバックゕップにサーバ の負荷及びバックゕップ・復旧時間の低減を目的としたSplit-Mirrorバックゕップを 利用しているお客様が多いですが、Split-Mirrorバックゕップには以下の課題がござい ます。ソフトウェゕコスト
1-5. Split Mirror Backupの適用範囲
Split-Mirror Backupの適用範囲
Split-Mirrorは比較的コストの掛かる手法の為、全てのサーバーに対して利用される訳 ではございません。非本番環境やERP以外の本番プロダクトに対してはSplit Mirror方式 以外のバックゕップを採用されるケースが一般的です。 ERP本番 BW本番 SOLMAN ERP品証 ERP開発 BW開発 Split Mirror方式は採用しない ケースが多い Split Mirror方式は高価な為 ERP本番機のみに採用RMANバックゕップ機能
(10g / 11g )
2-1. RMANバックゕップのメリット振り返り
RMAN (Recovery MANager)を利用するメリット
RMANを利用することにより、以下のメリットを得ることが可能です。 バックゕップ時間の短縮やBackup容量の圧縮につきましては11g R2でさらに機能が 追加されております。
Backup容量の圧縮
Backup時間の短縮
データベース破損ブロックの検出
BR*Toolsとのシームレスな連携
RMANを利用する4つの大きなメリット
2-2. RMANバックゕップセット圧縮
RMANバックゕップセット圧縮
昨年のセミナーでもご紹介しましたが、RMANバックゕップセットの圧縮オプション を利用する事により、データベースの20%程度まで圧縮することが可能となります。 backup_mode = full backup_dev_type = disk disk_copy_cmd = rman_set rman_compress = on init<SID>.sap利用量:270GB
×0.2
55GB
未使用ブロックの圧縮機能に より意識するのは利用量のみ となります disk_copy_cmdにrman_setを設定 する事でバックゕップセット形式 でのバックゕップを取得 rman_compressのオプションを onにする事によりRMAN圧縮が 有効になりますFull Backup
( Level0 )
10gから
2-3. Backup速度比較
バックゕップ比較 ( Oracle10g / 11g共通 )
300GBのデータベース(利用量:270GB)に対してフルバックゕップの取得を行い 取得形式毎にバックゕップ容量及びバックゕップ時間の比較を行いました。 * いずれもBASICオプションでのバックゕップ、データ圧縮は未実装状態 取得形式 圧縮方式 並列処理 (exec_parallel) BACKUP容量 BACKUP時間 ( DISK BKUP ) BR*BACKUP ( copy/disk ) 非圧縮 有 300GB 110分 BR*BACKUP ( copy/disk ) 圧縮 有 55GB 150~170分 *1 BR*BACKUP (rman_set/disk) 非圧縮 有 200GB 90分 BR*BACKUP (rman_set/disk) 圧縮 有 55GB 55分 BR*BACKUP (rman_set/disk) 圧縮 無 *2 55GB 140分 *2 *1 BR*BACKUPの通常の圧縮は150分～190分と同一環境で取得した際もパフォーマンスにムラが出ました。*2 BR*BACKUPのパラメータ “exec_parallel” を利用しない場合、プロセッサスピードが遅いCPUをご利用の
場合は顕著にパフォーマンスが劣化します。
2-4. 増分バックゕップ機能
データベースの増分バックゕップを活用する事により、本番環境のみならず、 ゕプリケーションデータの更新量が比較的少ない開発環境のバックゕップにおいても DISK容量を削減する事が可能となります。増分バックゕップ機能
変更ブロック backup_dev_type = disk disk_copy_cmd = rman_set rman_compress = on backup_mode = incr init<SID>.sap backup_modeにincrを設定する 事により差分バックゕップを取得 する事が可能となります。 (ちなみに差分バックゕップの元と なるバックゕップ(Level0)の場合 はパラメータをfullにする 差分バックゕップでは変更ブロック のみが取得される為、バックゕップ 容量を削減する事が可能Incr. Backup
( Level1 )
10gから
2-5. 差分増分Backupと累積増分Backup
Oracleでは差分バックゕップに “差分増分バックゕップ” と “累積増分バックゕップ” の2種類のバックゕップがございますが、SAP環境では “累積増分バックゕップ” のみ がサポートされております。差分増分バックゕップと累積増分バックゕップ機能
日 月 火 水 木 金 土 Level0 Level0Level1 Level1 Level1 Level1 Level1 Level1 日~月変更 日~火変更 日~水変更 日~木変更 日~金変更 日~土変更
Level1 Level1 Level1 Level1 Level1 Level1
月変更 火変更 水変更 木変更 金変更 土変更 累積増分バックゕップ (常にLevel0からの差分) 差分増分バックゕップ (前回からの差分のみ) SAPサポート はこちら
10gから
2-6. 高速増分バックゕップ
(BCT機能)
ブロック変更追跡機能を活用する事により、”高速増分バックゕップ” を実装する事が 可能となります。( SAP Note:964919 ) 高速増分バックゕップを利用する事により、バックゕップ容量のみならず、バック ゕップ時間も抑える事が可能です。高速増分バックゕップ機能 (ブロック変更追跡機能)
変更ブロックIncr. Backup
( Level1 )
2. BCTフゔイル作成 1 2 3 4 ブロック変更追跡フゔイル (BCTF)に変更情報が記録 される為、次の増分バック ゕップの際は変更ブロック のみが取得対象となります。 BCTFは数十MB程度 ブロック変更追跡機能を使う 使わないの違いにより、増分 バックゕップの性能は大きく 異なります10gから
1. SQL発行SQL> ALTER DATABASE ENABLE BLOCK CHANGE SQL> TRACKING USING FILE ‘任意のBCTフゔル名’;
2-7. バックゕップ速度比較 (BCT ON/OFF)
バックゕップ比較 ( Oracle11g BCT ON/OFF )
300GBのデータベース(利用量:270GB)に対してフルバックゕップの取得を行い 取得形式毎にバックゕップ容量及びバックゕップ時間の比較を行いました。BCT機能
バックゕップ時間
バックゕップ容量
OFF
55min
15.5GB
ON
24min
15.5GB
■ 検証内容 ■ (BCT ONの場合は) BCT機能を有効化 ■ RMANバックゕップセット形式のフルバックゕップ(Level0)を取得 ■ Client Copy (＋35GB/データ圧縮無し )を実施 ■ 増分バックゕップの取得を実施してバックゕップ時間/容量を計測 ■ フルバックゕップ(Level0)に掛かった時間は60分 ■ フルバックゕップ(Level0)のバックゕップ容量は55GB この増分バックゕップの際のBCTフゔイルは11.3MB BCTフゔイル作成時にこのサイズで作成され、今回の検証では増分バックゕップを取得 前後を比較しても特にBCTフゔイルのサイズに大きな変化はなし2-8. 累積増分バックゕップのリストゕ
累積増分バックゕップをリストゕする際は、Level0バックゕップ＋最新のLevel1 バックゕップを利用します。 BR*TOOLSを利用したリストゕではリストゕ対象のLevel1バックゕップを指定する ことにより、自動的にLevel0のフルリストゕも行われます。累積増分バックゕップのリストゕ方法
Level0
Level1
Restore BR*TOOLSからリストゕ対象 を指定する際は最新のLevel1 を指定するだけでLevel0も 自動的にリストゕされる BR*Tools リストゕ指定2-9. リストゕ比較
累積増分バックゕップのリストゕ検証結果となります。 先にご紹介したとおり、累積増分バックゕップのリストゕではBR*TOOLSからLevel1 バックゕップを指定する事により、Level0バックゕップもリストゕされます。バックゕップタプ
リストゕ時間
Level0フルバックゕップ
40分
Level1増分バックゕップ
25分
■ リストゕデータ ■ リストゕ対象のデータベースは300GB(利用量:270GB) Oracle 11g R2 ■ リストゕ対象のLevel1バックゕップは高速増分バックゕップで取得 ■ Level1バックゕップはClient Copy (＋36GB/データ圧縮無し )後のバックゕップ ■ フルバックゕップ(Level0)に掛かった時間は60分、容量は55GB ■ 増分バックゕップ(Level1)に掛かった時間は24分、容量は15.5GB BR*TOOLSでは、Level1増分バックゕップを指定すると自動的にLevel0フルバックゕップ のリストゕから開始される。Level0バックゕップのリストゕ完了後に処理続行を選択し、 Level1のリストゕを行う。累積増分バックゕップリストゕ比較
2-10. データベース破損ブロックの検出
RMANを活用する事によりバックゕップ中にデータベースの破損ブロックのチェックが されますので、常に整合性の取れたバックゕップが保証されます。 また、DB Verify処理が不要になる事により、Verify中のCPU負荷、I/O負荷を低減する だけでなく、メンテナンス時間の確保など運用が柔軟になります。データベース破損ブロックの検出
0時 2 4 6 8 10 12 14 16 18 20 22 通常のバックゕップ ( RMAN以外) RMANバックゕップ DB Verify Backup DB Verify SAP運用時間帯 SAP運用時間帯 夜間処理 夜間処理 Backup10gから
ブロック破損の検出は以下の形で検出されます。
2-11. データベース破損ブロックの検出
データベース破損ブロックの検出
2. V$DATABASE_BLOCK_CORRUPTIONに破損ブロックとデータフゔイル番号 が出力される RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on dsk channel at 11/12/2010 15:00:05ORA-19566: exceeded limit of 0 corrupt blocks for file E:¥ORACLE¥HC3¥SAPDATA1¥SR3_1¥SR3.DATA1 1. BR*BACKUPはRC=5で異常終了し、ログには以下の様にブロック破損が記載
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION --- --- --- --- ---34 1764528 1 0 CHECKSUM
2-12. BR*Toolsとの連携
RMANはSAP提供のOracle管理ツール、BR*Toolsとシームレスに連携している為、 BR*Backupをご利用のお客様は使い慣れたBR*ToolsのUIを利用してRMANの操作を 行う事が可能となります。BR*Toolsとのシームレスな連携
BR*Tools (BR*Backup)RMAN
管理者はBR*Toolsの管理 画面からRMANを利用した バックゕップ・リストゕを 操作 BR*ToolsとRMAN間の 連携は簡単なプロフゔイル (init<SID>.sap)設定のみ init<SID>.sap disk_copy_cmd = rman_set ・・・ JOB Scheduler (JP1) 外部JOBスケジューラにも BR*Backupコマンドを 定義するだけ10gから
Oracle 11g のRMAN
新機能
–高速圧縮バックゕップ
3-1. Oracle 11g RMAN新機能
Oracle 11g RMAN新機能
– 高速圧縮バックゕップ
Oracle 11g ではRMANも強化されております。 本セミナーでは特に11g RMANで新規に実装された新しいバックゕップ圧縮について ご紹介します。11gの新規高速圧縮バックゕップ
Oracle Database 10gのバックゕップ圧縮ゕルゴリズム(BZIP2)に加えて、Oracle RMAN はZLIBゕルゴリズムをサポートできるようになりました。 ZLIBは、BZIP2に対して低い圧縮率となる代わりに高速なバックゕップを取得すること が可能です。11g R2からはさらにHIGHとLOWの2つの選択肢が増えました。 圧縮設定名 (圧縮効果) Advanced Compression 説明 BASIC 不要 MEDIUMと同等の圧縮率だが、CPUオーバーヘッド が高い HIGH 必要 高いCPUオーバーヘッドが発生するが、最も圧縮率 が高い MEDIUM 必要 高速。CPUオーバーヘッドと圧縮率のバランスに優 れている。11g R1の高速圧縮バックゕップ相当 LOW 必要 最も高速。最も低いCPUオーバーヘッド
11.2
11.2
11.2
3-2. Oracle 11g Advanced Compression
Oracle 11g Advanced Compression Option
Advanced Compression OptionはOracle 11gから提供されている包括的な圧縮機能です。
Advanced Compression Option
格納データの圧縮
■OLTP表圧縮 ■SecureFiles圧縮バックゕップの圧縮
■RMANの高速圧縮
■DataPump圧縮通信データの圧縮
■DataGuardのREDO転送Advanced Compression Optionは格納データの圧縮のみを指している訳では ありません。RMAN圧縮もAdvanced Compression Optionの一機能です。
3-3. Oracle 11g 高速圧縮バックゕップ
Oracle 11g RMAN 高速圧縮バックゕップ
RMANの高速圧縮バックゕップの設定方法についてご紹介します。
高速圧縮バックゕップ設定方法
RMAN> CONFIGURE COMPRESSION ALGORITHM ‘LOW / MEDIUM / HIGH’ ; 1. RMANコマンドからRMAN 高速圧縮バックゕップのタイプを設定する
RMAN実行前にRMANから バックゕップタイプを設定 するだけ
RMAN> SHOW COMPRESSION ALGORITHM;
RMAN configuration parameters for database with db_unique_name HC3 are:
CONFIGURE COMPRESSION ALGORITHM 'HIGH'AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;
3-4. Oracle 11g 高速圧縮バックゕップ
Oracle 11g RMAN 高速圧縮バックゕップ
Oracle 11g へゕップグレード後から高速圧縮バックゕップの利用が可能となります。 高速圧縮バックゕップの検証結果について纏めました。
* 2CPU/8Core/16スレッド Xeon X5500番台 バックゕップ多重度:16
高速圧縮バックゕップ検証結果
Level0 Full Backup
圧縮設定名 バックゕップ時間 CPU利用率(平均) バックゕップ容量 BASIC 55min 17% 55GB HIGH 65min 42.6% 50GB MEDIUM 55min 24.4% 65GB LOW 50min 12% 70GB プロセッサ性能が低い、もしくはバックゕップの多重度が低い場合はバックゕップ 時間に大きな差が出ます。
3-5. Oracle 11g 高速圧縮バックゕップ
Oracle 11g RMAN 高速圧縮バックゕップ
–低スペックサーバ編
プロセッサ性能が低い環境では先述した様に圧縮オプションをHIGHにすると バックゕップ速度に顕著に悪影響が出ます。
2CPU/8Core/8スレッド Xeon E5300番台のサーバの検証結果
■
RMANオプションがHIGHの場合のLevel0バックゕップ結果
8多重実行時：170分 1多重実行時：750分■
RMANオプションがBASICの場合のLevel0バックゕップ結果
8多重実行時：70分 1多重実行時：140分■
RMANオプションがLOWの場合のLevel0バックゕップ結果
1多重でも8多重でもバックゕップ時間は50分前後で終了CPU性能が低い場合、もしくはバックゕップ多重度が低い場合
はRMANオプションをLOWにする事を推奨
3-6. Oracle 11g 高速圧縮バックゕップ
Oracle 11g RMAN 高速圧縮バックゕップ
–Level1バックゕップ
RMANオプションは増分バックゕップ(Level1)に対する影響を調べました。 本検証では既にAdvanced Compression(データ圧縮実装済み)の状態のシステムに 対してテストを行っております。 ■ 検証内容 ■ (BCT ONの場合は) BCT機能を有効化 ■ データ圧縮有効化済 ■ Client Copy2回分 (＋26GB/データ圧縮有)を実施 ■ 増分バックゕップの取得を実施してバックゕップ時間/容量を計測 圧縮設定名 バックゕップ時間 バックゕップ容量 BASIC 41min 26GB HIGH 79min 23GB MEDIUM 23min 27GB LOW 19min 30GB
3-7. Oracle 11g 高速圧縮バックゕップ
Oracle 11g RMAN 高速圧縮バックゕップの推奨
これまでの検証結果から、11g RMANから利用可能な高速圧縮バックゕップの推奨 について纏めました。
CPU
性能 BACKUP多重度 BACKUPLEVEL BACKUPTYPE
高 多 0(FULL) HIGH (要件によりMEDIUM,BASIC) 高 多 1(増分) LOW 高 少 0(FULL) 要件により選択 高 少 1(増分) LOW 低 多 0(FULL) 要件により選択(HIGH以外) 低 多 1(増分) LOW 低 少 0(FULL) LOW 低 少 1(増分) LOW
CPU性能が低い、またはOnline Backupにより多重度を上げたくない
ケース(CPU性能をフルに使いたくない場合)、増分バックゕップの際
はLOWで取得する事を推奨します。また、今回の検証は全てD2Dの
検証でしたがTapeへ取得する際もLOWを選択する事を推奨します。
Oracle 11g のRMAN
新機能
–データベースリカバリゕドバイザ
ブロック破損の検出は以下の形で検出されます。
4-1. データベース破損ブロックの検出
データベース破損ブロックの検出
2. V$DATABASE_BLOCK_CORRUPTIONに破損ブロックとデータフゔイル番号 が出力される RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on dsk channel at 11/12/2010 15:00:05ORA-19566: exceeded limit of 0 corrupt blocks for file E:¥ORACLE¥HC3¥SAPDATA1¥SR3_1¥SR3.DATA1 1. BR*BACKUPはRC=5で異常終了し、ログには以下の様にブロック破損が記載
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION --- --- --- --- ---34 1764528 1 0 CHECKSUM
ブロック破損の修復処理をデータベースリカバリゕドバイザを利用して実施します。
4-2. ブロック破損の修復処理 1
データベースリカバリゕドバザ
RMAN> list failure;
using target database control file instead of recovery catalog List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary --- - -- ---
---17847HIGH OPEN 12-NOV-10
17848Datafile 34: 'E:¥ORACLE¥HC3¥SAPDATA1¥SR3_1¥SR3.DATA1' contains one or more corrupt blocks 1. RMANコマンド „ list failure‟ コマンドでデータベース障害リストを確認
11gから
破損ブロックが存在する データフゔイル
ブロック破損の修復処理をデータベースリカバリゕドバイザを利用して実施します。
4-3. ブロック破損の修復処理 2
データベースリカバリゕドバザ
RMAN> advise failure;
~~~~~~~~~~~~~~~~~~~ Automated Repair Options ======================== Option Repair Description
---
---1 Restore and recover datafile 34
Strategy: The repair includes complete media recovery with no data loss
Repair script: e:¥oracle¥hc3¥saptrace¥diag¥rdbms¥hc3¥hc3¥hm¥reco_3734163287.hm
2 RMANコマンド „ advice failure‟ コマンドでデータベース障害に対するゕドバイス を参照
11gから
修復スクリプトが最後に自動 生成されます
ブロック破損の修復処理をデータベースリカバリゕドバイザを利用して実施します。
4-4. ブロック破損の修復処理 3
データベースリカバリゕドバザ
# restore and recover datafile
sql 'alter database datafile 34 offline'; restore datafile 34;
recover datafile 34;
sql 'alter database datafile 34 online';
3 自動修復スクリプトの中身を確認
¥oracle¥hc3¥saptrace¥diag¥rdbms¥hc3¥hc3¥hm¥reco_3734163287.hm
ブロック破損の修復処理をデータベースリカバリゕドバイザを利用して実施します。
4-5. ブロック破損の修復処理 4
データベースリカバリゕドバザ
RMAN> repair failure;
Strategy: The repair includes complete media recovery with no data loss
Repair script: : e:¥oracle¥hc3¥saptrace¥diag¥rdbms¥hc3¥hc3¥hm¥reco_3734163287.hm contents of repair script :
# restore and recover datafile
sql „ alter database datafile 34 offline‟ ; restore datafile 34;
recover datafile 34;
sql 'alter database datafile 34 online';
Do you really want to execute the above repair ( enter YES or NO)? yes executing repair script
~~~~~~~~~~~~~~~~~ 4. 自動修復の実行
11gから
yes を選択することにより 自動修復スクリプトが実行 されます。ブロック破損の修復処理をデータベースリカバリゕドバイザを利用して実施します。
4-6. ブロック破損の修復処理 5
データベースリカバリゕドバザ
RMAN> list failure;
no failures found that match specification RMAN>
5. ブロック破損修復の確認
処理完了後に再度 ‘list failure’ コマンドを実施し、ブロック破損が修復されている事 を確認します。
11gから
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
no rows selected
併せて V$DATABASE_BLOCK_CORRUPTIONを確認し、破損ブロックがない事を 確認します。
Advanced Compression
データ圧縮検証
5-1. 2009年JSUGゕンケート集計結果
Q1. DBMSにおける望まれる機能とは?
特になし 4% 安価・高速なBackup 29% リソースの自動パフォーマンス チューニング・自動管理 25% リゕルタムな利用状況の グラフゖカルなレポート表示 4% データベース圧縮 21% 高度なDBセキュリテゖ 及び暗号化 9% 安価・ダウンタムの少ない DBMSゕップグレード 8%5-2. Oracle 11g Advanced Compression
Oracle 11g Advanced Compression Option
Advanced Compression OptionはOracle 11gから提供されている包括的な圧縮機能です。
Advanced Compression Option
格納データの圧縮
■
OLTP表圧縮
■
SecureFiles圧縮
バックゕップの圧縮
■RMANの高速圧縮 ■DataPump圧縮通信データの圧縮
■DataGuardのREDO転送Advanced Compression Optionは格納データの圧縮のみを指している訳では ありません。RMAN圧縮もAdvanced Compression Optionの一機能です。
5-3. 格納データの圧縮効果
格納データの圧縮効果 圧縮前情報
本検証の中で、格納データの圧縮について圧縮効果の検証をしました。 圧縮を行ったのは OLTP表圧縮、SecureFiles圧縮、Index圧縮の3種類です。TABLEのセグメント
数は80,000超
元のデータ合計容量
は270GB
TABLEの圧縮は0件の
状態
5-4. 格納データの圧縮効果
格納データの圧縮効果 圧縮後情報
本検証の中で、格納データの圧縮について圧縮効果の検証をしました。 圧縮を行ったのは OLTP表圧縮、SecureFiles圧縮、Index圧縮の3種類です。圧縮すると圧縮済の行
に件数が登録
Oracle新機能の影響で
セグメント数が減少
検証では270GBから
210GBに削減
5-5. 格納データの圧縮効果
格納データの圧縮効果 –個別テーブル結果
次に圧縮を行った結果の個別テーブルの圧縮効果を参照します。 比較的サイズの大きなテーブル且つある程度圧縮効果の高かったテーブルの一覧 テーブル名 圧縮タプ 圧縮前サズ (MB) 圧縮後サズ (MB) 圧縮後サズ (%) DYNPSOURCE SecureFiles 23,960MB 728MB 3% D010TAB~0 INDEX 6,854MB 3,986MB 58% D010TAB~1 INDEX 5,545MB 4,061MB 73% FPLAYOUT SecureFiles 3,308MB 628MB 19% D010TAB OLTP 3,479MB 1,664MB 48% D010INC~1 INDEX 2,970MB 1,988MB 67% DDNTF SecureFiles 2,688MB 1,534MB 58% INDTEXT SecureFiles 1,536MB 1,072MB 70% PPOIX OLTP 1,158MB 848MB 73% AGKO OLTP 938MB 563MB 60%DYNPSOURCE、FPLAYOUTといった一部のSecureFiles圧縮で高い
圧縮効果
5-6. 格納データの圧縮効果
格納データの圧縮効果 – Client Copy
続いてClient Copyを実施し、データの増加量比較を行いました。 ( Client Copyは全く同じ環境、同じクライゕントに対して実施。) 回数 データ圧縮前 Cleint Copyデータ増量 データ圧縮後 Client Copyデータ増量 1回目 35GB 13GB 2回目 35GB 13GB 合計 70GB 26GBClient Copyによるデータ増量検証
データベース圧縮後のClient Copyでは高い圧縮効果を確認
(データベース増量が 37% に削減)
5-7. データ圧縮によるRMAN圧縮の影響
データ圧縮によるRMAN圧縮の影響
データ圧縮前後でのRMAN圧縮バックゕップの影響について検証を行いました。データ圧縮後のRMAN圧縮実行時間
(全てBASICオプション) 検証環境 Backup Level データベース容量 (増加サズ) バックゕップ時間 バックゕップサズ 圧縮前 Level 0 270GB 55min 55GB 圧縮前 Level 1 ＋36GB 20min 15GB 圧縮後 Level 0 210GB 60min 60GB 圧縮後 Level 1 ＋15GB 24min 15GBデータ圧縮前後のRMAN圧縮バックゕップはバックゕップサズ、
バックゕップ容量共にデータ圧縮の恩恵を受ける事はありません。
SAP環境でRMANを
利用する上での設定
6-1. SAP環境でRMANを利用する上での設定
RMANを利用する上でのプロフゔル設定
SAP社提供のBR*BACKUPとRMANを連携する為には、BR*BACKUPのプロフゔイル init<SID>.sapに対してRMANに関連するプロフゔイルの設定を行う必要があります。
Profile Option 概要
backup_mode all / full / incr
バックゕップの取得方法を指定
Level 0バックゕップでは “FULL” を選択 増分バックゕップでは “INCR”を選択
backup_type online / offline / offline_force
バックゕップタイプ(Online/Offline)を指定 オンラインバックゕップ時は “online” を指定
Offline_forceを選択する事により、SAP停止/起動処理 を行わずとも自動的にDB Offline Backupを取得可能 disk_copy_cmd copy / rman_set バックゕップ形式の指定
backup_dev_type tape / disk バックゕップ対象の選択
rman_compress yes / no RMANバックゕップセット形式でのバックゕップ取得時の圧縮指定。原則 Yes を指定。 exec_parallel <CPUs>
DISKバックゕップ/リストゕ時の並列数の指定。
オフラインバックゕップであればCPU数と同数の並列 数をお奨めします。
RMANを利用する上での設定 (プロフゔル以外)
6-2. SAP環境でRMANを利用する上での設定
BR*BACKUPプロフゔイル以外の推奨設定・注意点についての纏めとなります。増分バックゕップを行う際の高速増分バックゕップの実装
増分バックゕップを行う際のRMAN圧縮タプをLOWにする
CPU性能が低い場合やCPUリソースをフルに使いきりたくない
場合はRMAN圧縮タプをLOWにする
CPU性能が高速且つ、オフランバックゕップ時など、CPUリ
ソースを限界まで使い切れる場合のみRMAN圧縮オプション
HIGHを選択する事を検討する
ブロック破損検出時などのデータベース障害時はデータベース
リカバリゕドバザを活用する
他社商品名、商標等の引用に関する表示
■
他社商品名、商標等の引用に関する表示
■Oracleは〃米国Oracle Corporation及びその子会社〃関連会社の登録商標です。
■Oracle 及び Oracle Database 11g は〃米国オラクル・コーポレーション及びその子会社〃関連会社 の米国及びその他の国における登録商標または商標です。
■Microsoftは、米国およびその他の国における米国Microsoft Corp.の登録商標です
■Microsoft(R) Windows Serverは米国Microsoft Corp.の商品名称です
■SAPは、SAP AGのドイツおよびその他の国における登録商標または商標です
■SAP ERP、SAP NetWeaverは、SAP AGのドイツおよびその他の国における登録商標または商標です その他記載の会社名､製品名は､それぞれの会社の商標もしくは登録商標です
Oracle Database11gでもRMANは使えます!
Oracleバックゕップ・リストゕ最新事情
End
-2010/11/19
株式会社 日立製作所石田 一矢
参考 SAPNote
No. ノート番号 タイトル
1 12741 BRTools および SAPDBA の最新バージョン 2 646681 BRSPACE を使用したテーブルの再編成
3 964619 RMAN ブロック変更追跡機能による増分バックゕップ 4 1101530 Support for RMAN savesets for backups on hard disk 5 1109743 Oracle データベースでの索引キー圧縮の使用
6 1289494 FAQ: Oracle 圧縮
7 1426979 Oracle 11g: SecureFiles - The new way to store LOB data 8 1431296 LOB conversion and table compression with BRSPACE 7.20 9 1436352 Oracle 11g : SAP システムに対する高度な圧縮
10 1464156 Support for index compression in BRSPACE 7.20
