しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、こんにちは。最近、訪問先で「しばちょう先生ですか？」とお声掛け頂ける機会が増え、嬉しい半面、期待値のハードルが上がってしまって内心焦っていたりする“しばちょう”こと柴田長（しばた つかさ）です。
そして、これまた自分でハードルを上げる形になりますが、11月14日（木）に開催されるOracle DBA & Developer Day 2013において、Oracle Databaseのデータ破損の対策方法について解説する予定でございます。詳しくはイベントサイトをご覧ください。
さて、引き続き、今回もRecovery Manager（RMAN）をご紹介していきます。前回までは、RMANバックアップが必要最低限の時間とH/Wリソースの消費で高速に取得することが出来ることを主眼として体験して頂きましたが、今回は「アプリケーションの性能への影響を極力減らすには？」という観点で、バックアップで消費するリソース割り当てを制御する方法についてご紹介したいと思います。（申し訳ないですが、前回の終わりに予告させて頂いた「確実に復旧できるバックアップとは？」については次回以降にとさせて下さい。）
ブロック・チェンジ・トラッキング機能を有効化することで、RMANバックアップの際のDiskの読込み、書込みの総量を減らすことが出来ると前回までご紹介してきました。今回は、その総量は同じだけど、Oracle Database Resource Managerを使用することで、時間をかけて、ゆっくりと読み書きさせる方法について体験して頂きたいと考えています。
小学生の算数で「面積=縦×横」とか「道のり=早さ×時間」という有名な公式を学びましたが、正にこれと同じ考え方で「RMANバックアップのI/O総量 ≒ 単位時間当たりのI/O量 × 時間」という関係式が基本的には成り立ちます。よって、同じ面積然り、道のりであるRMANバックアップのI/O総量は、バックアップ時間をゆっくり（増加）にすれば、単位時間当たりのI/O量を減少させることができますから、アプリケーションの性能への影響を減らすことが可能になります。もちろん、バックアップしている時間が長くなりすぎても運用上で問題が出てくると思いますので、バランスには注意する必要がありますよ。
Oracle Database Resource Managerとはその名の通り、システム・リソースやデータベース・リソースの割り当て先を制御し、複数のワークロードの優先順位を管理することが可能です。今回はこのResource Managerを使用して、バックアップ処理へ割り当てるCPUリソースを制限することで、バックアップ時間を制御してみましょう。
と言う事で、以下の演習をOracle Database 11g Release 2 Enterprise Editionのデータベースで試してみてください。
1. RMANにおいて、オンラインでイメージ・コピー・バックアップが実行できるように設定をして下さい。
$ sqlplus / as sysdba SQL> -- RMAN バックアップの為に、アーカイブ・ログ・モードと高速リカバリ領域の設定 shutdown immediate ; startup mount ; alter database archivelog ; alter system set DB_RECOVERY_FILE_DEST = '+FRA' ; alter system set DB_RECOVERY_FILE_DEST_SIZE = 10g ; alter database oopen ; SQL> -- 確認 archive log list SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 21 Next log sequence to archive 23 Current log sequence 23 show parameter db_recovery NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string +FRA db_recovery_file_dest_size big integer 10G
RMANの連載は3回目となりますので、この演習は問題無いと思います。
上記では、アーカイブ・ログ・モードと、高速リカバリ領域を設定していますが、前者は「オンライン・バックアップ」を満たす為に必須となります。後者の高速リカバリ領域については使用しなくてもRMANでのバックアップを実行することができますが、その場合はバックアップ先をきちんと設定しておく必要がありますね。今回も、高速リカバリ領域を使用してバックアップしていきます。
2. 現在設定されているリソース・プランと、そのプラン・ディレクティブを確認してください。
$ sqlplus / as sysdba SQL> set linesize 150 pages 50000 SQL> -- 現在設定されているリソース・プラン名の確認 select * from V$RSRC_PLAN ; ID NAME IS_TO CPU INS PARALLEL_SERVERS_ACTIVE PARALLEL_SERVERS_TOTAL MANAGED ----- ------------- ----- --- --- ----------------------- ---------------------- ------- 12876 INTERNAL_PLAN TRUE OFF OFF 0 32 FIFO SQL> -- 現在設定されているリソース・プランのプラン・ディレクティブの確認 select PLAN, GROUP_OR_SUBPLAN, MGMT_P1, MGMT_P2, MGMT_P3, MGMT_P4, MAX_UTiLIZATION_LIMIT from DBA_RSRC_PLAN_DIRECTIVES where PLAN='INTERNAL_PLAN' ; PLAN GROUP_OR_SUBPLAN MGMT_P1 MGMT_P2 MGMT_P3 MGMT_P4 MAX_UTILIZATION_LIMIT ------------- ---------------- ------- ------- ------- ------- --------------------- INTERNAL_PLAN OTHER_GROUPS 0 0 0 0
突然、リソース・プランという名称が出てきましたが、Oracle Resource Managerはリソース・プランで定義された通りにリソースの割り当て先、優先順位を制御する機能ですので、リソース・プランとはOracle Resource Managerへインプットする設計書とか指示書のようなものになります。
少しだけリソース・プランについて解説しておきましょう。
Oracle Database 11g Release2では自動化メンテナンス・タスクと呼ばれる機能が存在しており、3種類（自動オプティマイザ統計収集、自動セグメント・アドバイザ、自動SQLチューニング・アドバイザ）が事前定義されています。デフォルトでは、これら3種類のタスクは、全てメンテナンス・ウィンドウ（要は、実行する曜日と期間）で実行するように構成されています。デフォルトでは平日の午後10時～午前2時の4時間、土日は午前6時からの20時間が定義されています。
自動化メンテナンス・タスクが実行されると言う事は、少なからずデータベース・サーバーやストレージのH/Wリソースを消費することになりますが、皆さんだったら、メンテナンス・タスクとアプリケーションからのSQLのどちらを優先させたいですか？そうですよね。アプリケーションのSQLだと思います。なので、この期間はインスタンスが使用するリソース・プランが自動的に「DEFAULT_MAINTENANCE_PLAN」と呼ばれるプランへ変更され、自動化メンテナンス・タスクとアプリケーションの処理の優先度を上手に制御していたりするのですね。
演習のSQL自体はそれほど難しくは無いと思います。V$RSRC_PLANビューに問い合わせることで、現時点でデータベース・インスタンスが使用しているリソース・プランの名前を確認することが出来ます。RSRCはリソース=RESOURCEを短縮したものなので覚えやすいと思います。各列の意味については、リファレンス・マニュアルをご参照ください。ここでは、「INTERNAL_PLAN」というリソース・プランが使用されているようですね。なので、2つのSQLでこのプランのプラン・ディレクティブを確認することになります。ちなみに、今回の私の環境は、Resource Managerが無効化されているので「INTERNAL_PALN」というプラン名が出力されており、リソース配分（プラン・ディレクティブ）が全て「0」になっています。
3. RMANを使用して、全てデータファイルのイメージ・コピー・バックアップを取得してください。その際、バックアップに要した時間と、その期間中のCPU使用率を確認して確認してください。
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"; $ rman target / connected to target database: ORCL (DBID=1353634468) RMAN> BACKUP AS COPY DATABASE TAG 'SIBACHO' ; Starting backup at 2013/10/28 14:34:42 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy input datafile file number=00001 name=+DATA/orcl/datafile/system.260.825853749 output file name=+FRA/orcl/datafile/system.280.830010883 tag=SIBACHO RECID=97 STAMP=830010896 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15 channel ORA_DISK_1: starting datafile copy input datafile file number=00002 name=+DATA/orcl/datafile/sysaux.261.825853781 output file name=+FRA/orcl/datafile/sysaux.265.830010899 tag=SIBACHO RECID=98 STAMP=830010909 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15 channel ORA_DISK_1: starting datafile copy input datafile file number=00003 name=+DATA/orcl/datafile/undotbs1.262.825853809 output file name=+FRA/orcl/datafile/undotbs1.260.830010913 tag=SIBACHO RECID=99 STAMP=830010917 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07 channel ORA_DISK_1: starting datafile copy copying current control file output file name=+FRA/orcl/controlfile/backup.272.830010919 tag=SIBACHO RECID=100 STAMP=830010920 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting datafile copy input datafile file number=00004 name=+DATA/orcl/datafile/users.264.825853835 output file name=+FRA/orcl/datafile/users.271.830010921 tag=SIBACHO RECID=101 STAMP=830010921 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:04 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 2013/10/28 14:35:24 channel ORA_DISK_1: finished piece 1 at 2013/10/28 14:35:25 piece handle=+FRA/orcl/backupset/2013_10_28/nnsnf0_sibacho_0.277.830010925 tag=SIBACHO comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 2013/10/28 14:35:25
はい、如何でしょうか？今回は特に高速増分バックアップを行う予定は無いので、シンプルな構文になっているかと思います。この演習で確認するべきは、Resource Managerが無効な場合のバックアップに要した時間だけです。つまりは、43秒間と言う事ですね。この数字を覚えておいてください。（本連載での処理時間は、実行環境によって大きく前後します。あくまで理解を容易にする為に掲載しているものであり、この処理時間を保証するものではございません。）
4. 事前定義のコンシューマ・グループ・マッピング・ルールを確認し、ORACLE_FUNCTION属性のBACKUP及びCOPYにコンシューマ・グループBATCH_GROUPがマッピングされているか確認してください。
$ sqlplus / as sysdba SQL> set linesize 150 pages 50000 col ATTRIBUTE for a16 col VALUE for a12 col COMSUMER_GROUP for a12 col STATUS for a12 select * from DBA_RSRC_GROUP_MAPPINGS ; ATTRIBUTE VALUE CONSUMER_GROUP STATUS ---------------- ------------ ------------------------------ ------------ ORACLE_USER SYS SYS_GROUP ORACLE_USER SYSTEM SYS_GROUP ORACLE_FUNCTION BACKUP BATCH_GROUP ORACLE_FUNCTION COPY BATCH_GROUP ORACLE_FUNCTION DATALOAD ETL_GROUP
またまた聞き慣れない難しい単語が出てきました。Resource Managerについては別の機会にきちんと解説した方が良さそうな気がしてきました。。。今回はさらっとだけ紹介しておきますね。
演習2の回答例の2つ目のSQLで、DBA_RSRC_PLAN_DIRECTIVESビューに問い合わせることでリソース・プランのディレクティブを確認していましたが、このビューの「GROUP_OR_SUBPLAN」に表示される値（演習2ではOTHER_GROUPS）がコンシューマ・グループ名だったりします。そのコンシューマ・グループ名に対してユーザー名や処理内容を紐づけたものが、「コンシューマ・グループ・マッピング・ルール」と呼ばれています。そして、この演習では改めてマッピング・ルールを作ってくださいとは言っておらず、事前定義されているルールを確認するだけとなります。と言う事で、「BACKUP」と「COPY」という処理がコンシューマ・グループ「BATCH_GROUP」にマッピングされていることが確認できたと思います。
これらが何を意味しているのかについては、管理者マニュアル（Oracle Database Resource Managerの参照情報の[表27-6 事前定義のコンシューマ・グループ・マッピング・ルール]）を読んでみましょう。
ちょっとだけ驚いて欲しいのですが、RMANでのバックアップ操作やコピー操作を実行するセッションでは、自動的にBATCH_GROUPというコンシューマ・グループに切り替えられる定義が事前にされていると言う事なのですよ。つまり、RMANでバックアップやコピーを実行する際に、そのデータベース・インスタンスが使用しているリソース・プランのプラン・ディレクティブにBATCH_GROUPが定義されていれば、その 割り当てルールに自動的に従ってくれることになります。これを使わない手は無いですよね。
もし、回答例のようにBATCH_GROUPに対して、BACKUPやCOPY操作がマッピングされていない場合は、次のプロシージャを実行することでマッピング・ルールを追加することが可能です。
$ sqlplus / as sysdba
SQL>
BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.ORACLE_FUNCTION, -
'BACKUP', 'BATCH_GROUP');
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.ORACLE_FUNCTION, -
'COPY', 'BATCH_GROUP');
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
5. RMANバックアップのI/O量を制限する目的で、バックアップ処理で最大でも10%のCPUしか使用させないような新規のリソース・プランBK_PLANを作成し、インスタンスが使用するリソース・プランに設定して下さい。
$ sqlplus / as sysdba
SQL> --BK_PLANの作成
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;
/
SQL> --BK_PLANのプラン・ディレクティブの確認
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> --インスタンスが使用するリソース・プランをBK_PLANに変更
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
さて、DBMS_RESOURCEパッケージを使用して新しいリソース・プランBK_PLANを作成します。今回は、BK_PLANを構成するプラン・ディレクティブには3つのコンシューマ・グループを定義することにします。一つ目はSYSユーザーやSYSTEMユーザーがマッピングされているSYS_GROUPコンシューマ・グループ、二つ目は演習4で確認したRMANのBACKUPとCOPY操作がマッピングされているBATCH_GROUPコンシューマ・グループ、最後三つ目は、SYS_GROUPとBATCH_GROUPに属さないその他全て（要はアプリケーションからのセッション）を意味するOTHER_GROUPSです。
- SYS_GROUPは優先的にCPUリソースを使用出来るように、MGMT_P1で75%を割り当てます。
- SYS_GROUPで使い切れなかったCPUリソースをその次のMGMT_P2のレベルでBATCH_GROUPとOTHER_GROUPSの二つのグループで割り振りが行われます。
- MGMT_P2のレベルにおいて、RMANバックアップよりもアプリケーションのセッションによる処理を優先させたいのでOTHER_GROUPSの90%、BATCH_GROUPを10%とします。
そして、今回最も重要なポイントは、RMANバックアップで最大でも10%のCPUしか使わせたくないという部分なので、「MAX_UTILIZATION_LIMIT=>10」を指定する部分です。これを指定しない場合、データベース・サーバーでCPUリソースが余っていればRMANバックアップの処理で使ってしまう動作となりますので注意してくださいね。
DBA_RSRC_PLAN_DIRECTIVESビューへ問い合わせることで目的通りのプラン・ディレクティブで構成されていることを確認した後、初期化パラメータRESOURCE_MANAGER_PLANをBK_PLANリソース・プランに動的に変更してみましょう。
6. 再度、RMANを使用して、全てデータファイルのイメージ・コピー・バックアップを取得して下さい。
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"; $ rman target / connected to target database: ORCL (DBID=1353634468) RMAN> BACKUP AS COPY DATABASE TAG 'SIBACHO' ; Starting backup at 2013/10/28 14:47:55 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=21 device type=DISK channel ORA_DISK_1: starting datafile copy input datafile file number=00001 name=+DATA/orcl/datafile/system.260.825853749 output file name=+FRA/orcl/datafile/system.271.830011679 tag=SIBACHO RECID=102 STAMP=830011745 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:15 channel ORA_DISK_1: starting datafile copy input datafile file number=00002 name=+DATA/orcl/datafile/sysaux.261.825853781 output file name=+FRA/orcl/datafile/sysaux.260.830011753 tag=SIBACHO RECID=103 STAMP=830011811 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:05 channel ORA_DISK_1: starting datafile copy input datafile file number=00003 name=+DATA/orcl/datafile/undotbs1.262.825853809 output file name=+FRA/orcl/datafile/undotbs1.265.830011819 tag=SIBACHO RECID=104 STAMP=830011837 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25 channel ORA_DISK_1: starting datafile copy copying current control file output file name=+FRA/orcl/controlfile/backup.280.830011843 tag=SIBACHO RECID=105 STAMP=830011842 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:02 channel ORA_DISK_1: starting datafile copy input datafile file number=00004 name=+DATA/orcl/datafile/users.264.825853835 output file name=+FRA/orcl/datafile/users.262.830011845 tag=SIBACHO RECID=106 STAMP=830011845 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 2013/10/28 14:50:46 channel ORA_DISK_1: finished piece 1 at 2013/10/28 14:50:47 piece handle=+FRA/orcl/backupset/2013_10_28/nnsnf0_sibacho_0.281.830011847 tag=SIBACHO comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 2013/10/28 14:50:47
いかがでしょうか？RMANによるイメージ・コピーのバックアップ処理時間が延びたことが確認できたのではないでしょうか？私の環境では「172秒」（=14:50:47 – 14:47:55）に変化しておりました。ちなみに、Resource Managerが無効であった演習3では43秒だったので、129秒間処理時間が延びたことになりますね。もちろん、実行環境によって効果は異なりますので、もしバックアップ処理時間に差が見られないようでしたら、MAX_UTILIZATION_LIMITで指定する値をもう少し小さくしてみると良いかもしれませんね。
とは言え、本当にResource Managerによる効果なのかという疑問が残りますので、次の演習で確認しておきましょう。
7. 演習6のRMANバックアップにおいて、各コンシューマ・グループがどの程度CPUリソースを待機したのかをV$RSRC_CONS_GROUP_HISTORYビューで確認して下さい。
$ sqlplus / as sysdba
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
はい、V$RSRC_CONS_GROUP_HISTORYビューに問い合わせることで、各コンシューマ・グループがResource Managerによってどの程度CPUの割り当てを待機させられたのかを確認することが可能です。
上記回答例では非常に面白い結果が出ています。と言うのも、RMANのバックアップを実行したセッションが所属するBATCH_GROUPコンシューマ・グループにおいて、CPUの割り当てを待機させられた時間（CPU_WAIT_TIME）は117035(ミリ秒)=117秒だと分かります。これは、演習6で解説させて頂いたRMANバックアップ処理時間が129秒間延びたという数字と非常に近いことがご理解頂けると思います。つまり、バックアップ処理時間が延びた理由は、Recovery Managerによって、CPUの割り当てを待機させられたからと結論づけられると思います。
ちなみに、CPUの割り当てを待機させられなかったら、実際に使用したCPU時間（CONSUMED_CPU_TIME）である約31秒間で終了したのか？と問われれば、それは正しくはありません。ここで表示されているのはあくまでCPUを使用した時間であり、その他のOracle Database内部でのロック機構での待機やI/O待機時間は含まれていない点を考慮してください。実際に演習2では43秒要していますしね。
その他、RMANバックアップ中に次の二つの問合せを実行することでも、Resource Managerの機能が動作していることを確認することが可能ですのでお時間があれば試してみてください。
SQL> SELECT se.sid sess_id, co.name consumer_group, se.state,
se.consumed_cpu_time cpu_time, se.cpu_wait_time, se.queued_time
FROM v$rsrc_session_info se, v$rsrc_consumer_group co
WHERE se.current_consumer_group_id = co.id;
SESS_ID CONSUMER_GROUP STATE CPU_TIME CPU_WAIT_TIME QUEUED_TIME
---------- -------------------------------- --------------- ---------- ------------- -----------
145 SYS_GROUP RUNNING 144 0 0
20 SYS_GROUP WAITING 58 0 0
11 SYS_GROUP WAITING 597 0 0
21 BATCH_GROUP WAITING FOR CPU 4939 17097 0
144 _ORACLE_BACKGROUND_GROUP_ NOT MANAGED 0 0 0
142 _ORACLE_BACKGROUND_GROUP_ NOT MANAGED 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
--- ---------- ------------ -------- ------------------------------------------ -----------------------
11 11 SYS INACTIVE rman@vm11204.localdomain (TNS V1-V3) SYS_GROUP
20 45 SYS INACTIVE rman@vm11204.localdomain (TNS V1-V3) SYS_GROUP
21 37 SYS ACTIVE rman@vm11204.localdomain (TNS V1-V3) BATCH_GROUP
8. リソース・プランBK_PLANを削除してください。
$ sqlplus / as sysdba SQL> -- 今回は、SCOPE=MEMORYを指定してプランを一時的に変更していたので、インスタンス再起動で元のプランへ戻ります。 shutdown immediate ; startup ; SQL> -- リソース・プランの削除 BEGIN DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN => 'BK_PLAN'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; /
この演習はオマケです。設定したは良いけど、元に戻す方法が不明というケースが多いと思いましたので、参考までに記述させて頂きました。
さて、いかがでしたでしょうか？
高速にバックアップを取得したいという要件が多い一方、お客様の要件の優先順位によっては、アプリケーションの性能へ影響なくバックアップを取得したいという要件もあるのではないか？と気付かされ、今回はResource Managerによるバックアップ時間を延ばす方法をご紹介させて頂きました。原稿を書いているうちに、今回はRecovery Managerと言うよりも、Resource Managerの回だったのではないか？という疑問がふつふつと沸いてきてしまいましたが、参考になれば幸いです。もちろん、前回ご紹介したブロック・チェンジ・トラッキング機能によってI/Oの総量を非常に小さく抑えると言うのが基本原則ですので、是非組み合わせてご活用ください。
今回も体験して頂きまして、ありがとうございました。次回もよろしくお願い致します。