RDS for Oracleを作成後、対象インスタンスの内部で共通して実施することの多い、基本的な設定を記載致します。パラメータグループやオプショングループ等のAWSコンソール上で設定可能な項目につきましては、記載対象外となっておりますので、ご了承いただければと存じます。また、全て網羅しているわけではない点につきましても、ご了承いただければと存じます。
動作確認環境
今回はRDS for Oracle 12.1 SE2を利用して動作確認を実施致しました。
エディションやバージョンが異なる場合、内容も若干異なる可能性がある点につきましても、ご了承いただければと存じます。
REDOログ
RDS初期構築時の設定
RDS for Oracleでは、構築時に128MBのREDOログ・グループが4つ用意されています。各REDOログ・グループには1つのメンバが存在する状況です。
SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;
GROUP# MB STATUS
---------- ---------- --------------------------------
1 128 ACTIVE
2 128 CURRENT
3 128 ACTIVE
4 128 ACTIVEオンプレミスに慣れ親しんだ方から見ると、REDOログ・メンバが1つという状況に違和感を覚えるかもしれませんが、RDS for Oracleではグループにメンバを追加することはできません。
したがって、RDS for OracleにおいてのREDOログ管理は、「REDOログファイルのサイズ」と「REDOログ・グループの数」の2つの観点となります。
更に、RDS for Oracleでは5分おきに強制的にログスイッチが発生するという内部仕様があります。これはRDSのPITR機能を実現するためのもので、変更することはできません。
DB インスタンスの復元可能な直近の時間は、通常、現在時刻の 5 分以内です。
Amazon RDS のバックアップと復元
つまり、どれだけREDOログを大きくしても、ログスイッチの発生間隔を5分より短くすることはできません。したがって、チェックポイントの発生間隔も5分より短くすることはできません。
この仕様により、RDS for Oracleでは次のようなメッセージがアラートログに出力されやすくなっています。5分間隔で定期的に出力されており、かつ、具体的なパフォーマンス影響がない場合、現状では無視せざるを得ないメッセージです。
Thread 1 cannot allocate new log, sequence 5154
Checkpoint not complete
Current log# 5 seq# 5153 mem# 0: /rdsdbdata/db/ORCL_A/onlinelog/o1_mf_5_hq02flny_.log5分間隔よりも短く、かつ、継続的に出力されているような場合は、REDOログのサイズを大きくしたり、REDOログのグループ数を増やしたりするといった対応の検討を行います。
チェックポイントの発生があまりにも多すぎるという印象を持たれる方もいらっしゃるかとは存じますが、マネージドサービスのため、現状では受け入れるしかない仕様です。
REDOログサイズ変更
RDSでは、具体的には次のような流れにてREDOログのサイズ変更を行います。流れ自体はオンプレミスと変わりありませんが、操作にはAWSが用意したプロシージャを利用する必要があります。
- 十分な空きストレージ容量があることを確認する
- 適切なサイズのREDOログを適切な数だけ追加する(
rdsadmin.rdsadmin_util.add_logfile) - ログスイッチを行い追加したREDOログを
CURRENTにする(rdsadmin.rdsadmin_util.switch_logfile) - 既存のREDOログが
INACTIVEでない場合はチェックポイントを手動で発生させる(rdsadmin.rdsadmin_util.checkpoint) - 既存のREDOログを削除する(
rdsadmin.rdsadmin_util.drop_logfile)
次の例では、REDOログのサイズを128MBから1GBに変更しています。REDOログの数は4つのままとしています。
-- 1GBのREDOログを4つ追加します(引数にはサイズを指定します)
SQL> exec rdsadmin.rdsadmin_util.add_logfile(p_size => '1024M');
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.rdsadmin_util.add_logfile(p_size => '1024M');
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.rdsadmin_util.add_logfile(p_size => '1024M');
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.rdsadmin_util.add_logfile(p_size => '1024M');
PL/SQLプロシージャが正常に完了しました。
-- 1GBのREDOログが4つ追加されたことを確認します
SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;
GROUP# MB STATUS
---------- ---------- --------------------------------
1 128 ACTIVE
2 128 CURRENT
3 128 ACTIVE
4 128 ACTIVE
5 1024 UNUSED
6 1024 UNUSED
7 1024 UNUSED
8 1024 UNUSED
8行が選択されました。
-- ログスイッチを行い追加したREDOログを`CURRENT`にします
SQL> exec rdsadmin.rdsadmin_util.switch_logfile;
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.rdsadmin_util.switch_logfile;
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.rdsadmin_util.switch_logfile;
PL/SQLプロシージャが正常に完了しました。
SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;
GROUP# MB STATUS
---------- ---------- --------------------------------
1 128 ACTIVE
2 128 ACTIVE
3 128 ACTIVE
4 128 ACTIVE
5 1024 ACTIVE
6 1024 ACTIVE
7 1024 CURRENT
8 1024 UNUSED
8行が選択されました。
-- チェックポイントにより既存のREDOログを`INACTIVE`にします
SQL> exec rdsadmin.rdsadmin_util.checkpoint;
PL/SQLプロシージャが正常に完了しました。
SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;
GROUP# MB STATUS
---------- ---------- --------------------------------
1 128 INACTIVE
2 128 INACTIVE
3 128 INACTIVE
4 128 INACTIVE
5 1024 INACTIVE
6 1024 INACTIVE
7 1024 CURRENT
8 1024 UNUSED
8行が選択されました。
-- 既存のREDOログを削除します(引数には削除するREDOログのグループ番号を指定します)
SQL> exec rdsadmin.rdsadmin_util.drop_logfile(grp => 1);
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.rdsadmin_util.drop_logfile(grp => 2);
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.rdsadmin_util.drop_logfile(grp => 3);
PL/SQLプロシージャが正常に完了しました。
SQL> exec rdsadmin.rdsadmin_util.drop_logfile(grp => 4);
PL/SQLプロシージャが正常に完了しました。
SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;
GROUP# MB STATUS
---------- ---------- --------------------------------
5 1024 INACTIVE
6 1024 INACTIVE
7 1024 CURRENT
8 1024 UNUSEDUNDO表領域
RDS初期構築時の設定
RDS for Oracleでは、構築時にUNDO_T1として自動拡張が有効になっているUNDO表領域(BIGFILE)が用意されます。私の環境だと320MBでした。自動拡張が有効で、かつ、BIGFILEという点が特徴的です。
SQL> select tablespace_name, bigfile, contents, segment_space_management, retention from dba_tablespaces where contents = 'UNDO' order by 1;
TABLESPACE_NAME BIGFIL CONTENTS SEGMENT_SPAC RETENTION
------------------------------------------------------------ ------ ------------------ ------------ ----------------------
UNDO_T1 YES UNDO MANUAL NOGUARANTEE
SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_data_files where tablespace_name like 'UNDO%' order by 1, 2;
TABLESPACE_NAME FILE_NAME AUTOEX MB MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
UNDO_T1 /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_hv5s98qk_.dbf YES 320 102400しかしながら、定まった値を確保し、自動拡張させたくないという方もいらっしゃるかと存じます(個人的には、クラウドを利用するなら最大値を設けた上でUNDOもストレージも自動拡張させてしまいますが、予算都合等もありますので)。
UNDO表領域サイズ変更
ALTER TABLESPACE文のRESIZEを利用してUNDO表領域のサイズ変更を行います。なお、新しくUNDO表領域を作成し、UNDO_TABLESPACEパラメータで新規作成したUNDO表領域を指定する方法もあります。
UNDO表領域名はUNDOTBS1でないと落ち着かないという方は、表領域名を変更することも可能ですが、新規作成された方が確実かとは存じます。
SQL> alter tablespace undo_t1 resize 500m;
表領域が変更されました。
SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_data_files order by 1, 2;
TABLESPACE_NAME FILE_NAME AUTOEX MB MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
UNDO_T1 /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_hv5s98qk_.dbf YES 500 102400UNDO表領域自動拡張変更
ALTER TABLESPACE文のAUTOEXTENDを利用してUNDO表領域のサイズ変更を行います。サイズと同様、新しくUNDO表領域を作成し、UNDO_TABLESPACEパラメータで新規作成したUNDO表領域を指定する方法もあります。
SQL> alter tablespace undo_t1 autoextend off;
表領域が変更されました。
SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_data_files order by 1, 2;
TABLESPACE_NAME FILE_NAME AUTOEX MB MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
UNDO_T1 /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_hv5s98qk_.dbf NO 500 0その他
デフォルトのUNDO表領域において、UNDOの保証はNOGUARANTEEとなっています。したがって、UNDOを保証する場合は別途有効にする作業が必要です。また、自動拡張も有効にしておく必要がある点にも留意が必要です。
ちなみに、パラメータグループ上でUNDO_TABLESPACEにデフォルトのUNDO表領域名(UNDO_T1)以外の名前を指定し、その表領域が存在しない状況で起動した場合、RDS側でデフォルト設定のUNDO表領域を自動的に作成してくれます。なお、これは確認時点の挙動なので、確証はございません。
一時表領域
RDS初期構築時の設定
RDS for Oracleでは、構築時にTEMPとして自動拡張が有効になっている一時表領域(BIGFILE)が用意されます。私の環境だと100MBでした。UNDO表領域と同様、自動拡張が有効で、かつ、BIGFILEという点が特徴的です。
SQL> select tablespace_name, bigfile, contents, segment_space_management from dba_tablespaces where contents = 'TEMPORARY' order by 1;
TABLESPACE_NAME BIGFIL CONTENTS SEGMENT_SPAC
------------------------------------------------------------ ------ ------------------ ------------
TEMP YES TEMPORARY MANUAL
SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_temp_files order by 1, 2;
TABLESPACE_NAME FILE_NAME AUTOEX MB MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
TEMP /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_hym2gnd6_.tmp YES 100 102400こちらも、UNDOと同様、一定サイズを指定し、自動拡張は無効にされたい方もいらっしゃるかと存じます。
一時表領域サイズ変更
ALTER TABLESPACE文のRESIZEを利用して一時表領域のサイズ変更を行います。UNDO表領域と同じです。
SQL> alter tablespace temp resize 200m;
表領域が変更されました。
SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_temp_files order by 1, 2;
TABLESPACE_NAME FILE_NAME AUTOEX MB MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
TEMP /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_hym2gnd6_.tmp YES 200 102400一時表領域自動拡張変更
ALTER TABLESPACE文のAUTOEXTENDを利用してUNDO表領域のサイズ変更を行います。こちらもUNDO表領域と同じです。
SQL> alter tablespace temp autoextend off;
表領域が変更されました。
SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_temp_files order by 1, 2;
TABLESPACE_NAME FILE_NAME AUTOEX MB MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
TEMP /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_hym2gnd6_.tmp NO 200 0自動メンテナンスタスク
RDS初期構築時の設定
ライセンス等の関係で、とりあえず無効にされることもある自動メンテナンスタスクですが、RDS for Oracleにおいても健在で、全て有効状態となっています。
また、バッチ時間帯と重複して統計情報を取得されたら困るということで、自動メンテナンスタスクの実行時間帯を変更することも多いかと存じますが、RDS for Oracleにおいては、時間だけでなくタイムゾーンも考慮する必要があります。
ウィンドウのタイムゾーン設定がETC/UTCであるためです。
SQL> select client_name, window_group, status from dba_autotask_client order by 1;
CLIENT_NAME WINDOW_GROUP STATUS
-------------------------------- ---------------- ----------------
auto optimizer stats collection ORA$AT_WGRP_OS ENABLED
auto space advisor ORA$AT_WGRP_SA ENABLED
sql tuning advisor ORA$AT_WGRP_SQ ENABLED
SQL> select window_group_name, number_of_windows, enabled, next_start_date from dba_scheduler_window_groups order by 1;
WINDOW_GROUP_NAME NUMBER_OF_WINDOWS ENABLED NEXT_START_DATE
------------------------- ----------------- ---------- ------------------------------------------------------------------------------------------------------------------------
MAINTENANCE_WINDOW_GROUP 7 TRUE 20-12-29 22:00:00.000000 ETC/UTC
ORA$AT_WGRP_OS 7 TRUE 20-12-29 22:00:00.000000 ETC/UTC
ORA$AT_WGRP_SA 7 TRUE 20-12-29 22:00:00.000000 ETC/UTC
ORA$AT_WGRP_SQ 7 TRUE 20-12-29 22:00:00.000000 ETC/UTC
SQL> select * from dba_autotask_window_clients order by 1;
WINDOW_NAME WINDOW_NEXT_TIME WINDOW_ACT AUTOTASK_STATUS OPTIMIZER_STATS SEGMENT_ADVISOR SQL_TUNE_ADVISOR HEALTH_MONITOR
-------------------- --------------------------------------------------------------------------- ---------- ---------------- ---------------- ---------------- ---------------- ----------------
FRIDAY_WINDOW 21-01-01 22:00:00.000000 ETC/UTC FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
MONDAY_WINDOW 21-01-04 22:00:00.000000 ETC/UTC FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
SATURDAY_WINDOW 21-01-02 06:00:00.000000 ETC/UTC FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
SUNDAY_WINDOW 21-01-03 06:00:00.000000 ETC/UTC FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
THURSDAY_WINDOW 20-12-31 22:00:00.000000 ETC/UTC FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
TUESDAY_WINDOW 20-12-29 22:00:00.000000 ETC/UTC FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
WEDNESDAY_WINDOW 20-12-30 22:00:00.000000 ETC/UTC FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
7行が選択されました。
SQL> select window_name, repeat_interval, duration, enabled from dba_scheduler_windows order by 1;
WINDOW_NAME REPEAT_INTERVAL DURATION ENABLED
-------------------- ---------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
FRIDAY_WINDOW freq=daily;byday=FRI;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE
MONDAY_WINDOW freq=daily;byday=MON;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE
SATURDAY_WINDOW freq=daily;byday=SAT;byhour=6;byminute=0; bysecond=0 +000 20:00:00 TRUE
SUNDAY_WINDOW freq=daily;byday=SUN;byhour=6;byminute=0; bysecond=0 +000 20:00:00 TRUE
THURSDAY_WINDOW freq=daily;byday=THU;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE
TUESDAY_WINDOW freq=daily;byday=TUE;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE
WEDNESDAY_WINDOW freq=daily;byday=WED;byhour=22;byminute=0; bysecond=0 +000 04:00:00 TRUE
WEEKEND_WINDOW freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0 +002 00:00:00 FALSE
WEEKNIGHT_WINDOW freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0 +000 08:00:00 FALSE
9行が選択されました。自動メンテナンスタスク無効化
RDSでもDBMS_AUTO_TASK_ADMINを利用して無効化を行います。次の例ではSQLチューニング・アドバイザーを無効にしています。
SQL> begin
2 dbms_auto_task_admin.disable(
3 client_name => 'sql tuning advisor',
4 operation => null,
5 window_name => null
6 );
7 end;
8 /
PL/SQLプロシージャが正常に完了しました。
SQL> select client_name, window_group, status from dba_autotask_client order by 1;
CLIENT_NAME WINDOW_GROUP STATUS
-------------------------------- ---------------- ----------------
auto optimizer stats collection ORA$AT_WGRP_OS ENABLED
auto space advisor ORA$AT_WGRP_SA ENABLED
sql tuning advisor ORA$AT_WGRP_SQ DISABLEDメンテナンスウィンドウ変更(タイムゾーン)
ウィンドウのタイムゾーンがETC/UTCになっているということは、JSTから見た場合9時間遅いということになります。そのままだと、夜間のつもりが日本時間だと昼間だったということも起こり得るため、タイムゾーンを変更します。
タイムゾーンの変更にはDBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTEを利用します。
次の例では、タイムゾーンをAsia/Tokyoに変更しています。なお、Asia/Tokyoの部分を+09:00としてもJSTを表します。
SQL> begin
2 dbms_scheduler.set_scheduler_attribute(
3 attribute => 'default_timezone',
4 value => 'Asia/Tokyo'
5 );
6 end;
7 /
PL/SQLプロシージャが正常に完了しました。
SQL> select * from dba_autotask_window_clients order by 1;
WINDOW_NAME WINDOW_NEXT_TIME WINDOW_ACT AUTOTASK_STATUS OPTIMIZER_STATS SEGMENT_ADVISOR SQL_TUNE_ADVISOR HEALTH_MONITOR
-------------------- --------------------------------------------------------------------------- ---------- ---------------- ---------------- ---------------- ---------------- ----------------
FRIDAY_WINDOW 21-01-01 22:00:00.000000 ASIA/TOKYO FALSE ENABLED ENABLED ENABLED DISABLED DISABLED
MONDAY_WINDOW 21-01-04 22:00:00.000000 ASIA/TOKYO FALSE ENABLED ENABLED ENABLED DISABLED DISABLED
SATURDAY_WINDOW 21-01-02 06:00:00.000000 ASIA/TOKYO FALSE ENABLED ENABLED ENABLED DISABLED DISABLED
SUNDAY_WINDOW 21-01-03 06:00:00.000000 ASIA/TOKYO FALSE ENABLED ENABLED ENABLED DISABLED DISABLED
THURSDAY_WINDOW 20-12-31 22:00:00.000000 ASIA/TOKYO FALSE ENABLED ENABLED ENABLED DISABLED DISABLED
TUESDAY_WINDOW 20-12-29 22:00:00.000000 ASIA/TOKYO FALSE ENABLED ENABLED ENABLED DISABLED DISABLED
WEDNESDAY_WINDOW 20-12-30 22:00:00.000000 ASIA/TOKYO FALSE ENABLED ENABLED ENABLED DISABLED DISABLED
7行が選択されました。
SQL> select window_group_name, number_of_windows, enabled, next_start_date from dba_scheduler_window_groups order by 1;
WINDOW_GROUP_NAME NUMBER_OF_WINDOWS ENABLED NEXT_START_DATE
------------------------- ----------------- ---------- ------------------------------------------------------------------------------------------------------------------------
MAINTENANCE_WINDOW_GROUP 7 TRUE 20-12-29 22:00:00.000000 ASIA/TOKYO
ORA$AT_WGRP_OS 7 TRUE 20-12-29 22:00:00.000000 ASIA/TOKYO
ORA$AT_WGRP_SA 7 TRUE 20-12-29 22:00:00.000000 ASIA/TOKYO
ORA$AT_WGRP_SQ 7 TRUE 20-12-29 22:00:00.000000 ASIA/TOKYOメンテナンスウィンドウ変更(時間帯)
メンテナンスウィンドウの時間帯を変更したいというケースもあるかと存じます。デフォルトですと、平日は22時から4時間、土日は6時から20時間が実行時間帯となっていますが、これがベストという場合は少ないものと存じます。
ウィンドウ時間の変更にはDBMS_SCHEDULER.SET_ATTRIBUTEを利用します。
次の例では、月火水木金のウィンドウを2時30分から4時間、土日のウィンドウを2時30分から8時間としています。
SQL> begin
2 dbms_scheduler.set_attribute(
3 name => 'sys.monday_window',
4 attribute => 'repeat_interval',
5 value => 'freq=daily;byday=mon;byhour=2;byminute=30; bysecond=0'
6 );
7 dbms_scheduler.set_attribute(
8 name => 'sys.tuesday_window',
9 attribute => 'repeat_interval',
10 value => 'freq=daily;byday=tue;byhour=2;byminute=30; bysecond=0'
11 );
12 dbms_scheduler.set_attribute(
13 name => 'sys.wednesday_window',
14 attribute => 'repeat_interval',
15 value => 'freq=daily;byday=wed;byhour=2;byminute=30; bysecond=0'
16 );
17 dbms_scheduler.set_attribute(
18 name => 'sys.thursday_window',
19 attribute => 'repeat_interval',
20 value => 'freq=daily;byday=thu;byhour=2;byminute=30; bysecond=0'
21 );
22 dbms_scheduler.set_attribute(
23 name => 'sys.friday_window',
24 attribute => 'repeat_interval',
25 value => 'freq=daily;byday=fri;byhour=2;byminute=30; bysecond=0'
26 );
27 dbms_scheduler.set_attribute(
28 name => 'sys.saturday_window',
29 attribute => 'repeat_interval',
30 value => 'freq=daily;byday=sat;byhour=2;byminute=30; bysecond=0'
31 );
32 dbms_scheduler.set_attribute(
33 name => 'sys.saturday_window',
34 attribute => 'duration',
35 value => numtodsinterval(8, 'hour')
36 );
37 dbms_scheduler.set_attribute(
38 name => 'sys.sunday_window',
39 attribute => 'repeat_interval',
40 value => 'freq=daily;byday=sat;byhour=2;byminute=30; bysecond=0'
41 );
42 dbms_scheduler.set_attribute(
43 name => 'sys.sunday_window',
44 attribute => 'duration',
45 value => numtodsinterval(8, 'hour')
46 );
47 end;
48 /
PL/SQLプロシージャが正常に完了しました。
SQL> select window_name, repeat_interval, duration, enabled from dba_scheduler_windows order by 1;
WINDOW_NAME REPEAT_INTERVAL DURATION ENABLED
-------------------- ---------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
FRIDAY_WINDOW freq=daily;byday=fri;byhour=2;byminute=30; bysecond=0 +000 04:00:00 TRUE
MONDAY_WINDOW freq=daily;byday=mon;byhour=2;byminute=30; bysecond=0 +000 04:00:00 TRUE
SATURDAY_WINDOW freq=daily;byday=sat;byhour=2;byminute=30; bysecond=0 +000 08:00:00 TRUE
SUNDAY_WINDOW freq=daily;byday=sat;byhour=2;byminute=30; bysecond=0 +000 08:00:00 TRUE
THURSDAY_WINDOW freq=daily;byday=thu;byhour=2;byminute=30; bysecond=0 +000 04:00:00 TRUE
TUESDAY_WINDOW freq=daily;byday=tue;byhour=2;byminute=30; bysecond=0 +000 04:00:00 TRUE
WEDNESDAY_WINDOW freq=daily;byday=wed;byhour=2;byminute=30; bysecond=0 +000 04:00:00 TRUE
WEEKEND_WINDOW freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0 +002 00:00:00 FALSE
WEEKNIGHT_WINDOW freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0 +000 08:00:00 FALSE
9行が選択されました。Statspack
Statspack導入
RDSではPerformance Insightsという非常に便利なパフォーマンス分析ツールを利用できますが、Web上にも情報量が多いStatspackを導入されたいという方もいらっしゃるかと存じます。
導入についての流れはOracle Statspack のセットアップに公式案内がございますので、そちらを参考に実施します。
なお、PERFSTATユーザのデフォルト表領域はSYSAUXで作成されます。つまり、SYSAUXにStatspack関連情報が格納されます。これについては、気持ち悪いと感じられる方もいらっしゃるかと存じます。
後々この格納先を変更することも可能とは推察しますが(表領域作成、クォータ設定、デフォルト表領域変更、既存テーブルの表領域変更)、手動で色々と変更するリスクを考えると、あくまで私個人の意見としては、このまま利用されるのもよろしいかと存じます。
※万が一、Statspack関係で何かあった際、サポートに共有する背景が減るため、結果として楽になるかもしれないというのが本音です。
SQL> select username, default_tablespace, temporary_tablespace, profile, authentication_type from dba_users where username = 'PERFSTAT';
USERNAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE PROFILE AUTHENTICATION_T
---------- ------------------------------------------------------------ ------------------------------------------------------------ ---------- ----------------
PERFSTAT SYSAUX TEMP DEFAULT PASSWORDStatspackスナップショット作成ジョブ
公式情報としてStatspack レポートの生成でスナップショット作成ジョブのサンプルが提供されていますが、非推奨のDBMS_JOBを利用したものです。
したがって、DBMS_SCHEDULERを利用したサンプルを記載致します。また、スナップショット作成と併せて、スナップショット削除のジョブも実装することが多いと存じますため、そちらのサンプルも記載致します。
下記は、毎時0分にスナップショットを作成し(レベル7)、毎日0時に90日経過したスナップショットを削除するジョブのサンプルです。CREATE JOB権限を保有しているPERFSTATでログインして実行することを想定しています(grant create job to perfstat;)。
SQL> select job_name, job_action, next_run_date, enabled from dba_scheduler_jobs where owner = 'PERFSTAT';
レコードが選択されませんでした。
SQL> begin
2 dbms_scheduler.create_job (
3 job_name => 'statspack_snapshot',
4 job_type => 'plsql_block',
5 job_action => 'begin statspack.snap(i_snap_level=>7); end;',
6 start_date => null,
7 repeat_interval => 'freq=hourly; byminute=0; bysecond=0',
8 auto_drop => false,
9 enabled => true
10 );
11 end;
12 /
PL/SQLプロシージャが正常に完了しました。
SQL> begin
2 dbms_scheduler.create_job (
3 job_name => 'statspack_snapshot_purge',
4 job_type => 'plsql_block',
5 job_action => 'begin statspack.purge(i_num_days=>90); end;',
6 start_date => null,
7 repeat_interval => 'freq=daily; byhour=0; byminute=0; bysecond=0',
8 auto_drop => false,
9 enabled => true
10 );
11 end;
12 /
PL/SQLプロシージャが正常に完了しました。
SQL> select job_name, job_action, next_run_date, enabled from dba_scheduler_jobs where owner = 'PERFSTAT';
JOB_NAME JOB_ACTION NEXT_RUN_DATE ENABLED
------------------------- --------------------------------------------- --------------------------------------------------------------------------- ----------
STATSPACK_SNAPSHOT begin statspack.snap(i_snap_level=>7); end; 20-12-29 18:00:00.352110 ASIA/TOKYO TRUE
STATSPACK_SNAPSHOT_PURGE begin statspack.purge(i_num_days=>90); end; 20-12-30 00:00:00.737920 ASIA/TOKYO TRUE統計情報取得
おそらく、上記のような対応と共に、ユーザ表領域の作成、業務ユーザの作成、オブジェクトの作成やデータのロード等を、初期作業の一環として実施されるものと存じます。
オブジェクトを作成したスキーマの統計情報取得については意識的に実行されるケースも多いものと存じますが、スキーマの統計情報に加えて、個人的にディクショナリと固定オブジェクトの統計情報も気休めとして最後に取得するようにしています。
ディクショナリと固定オブジェクトを取得するため、具体的には、次のパッケージを利用します。RDSでもオンプレミスと変わりません。
- DBMS_STATS.GATHER_DICTIONARY_STATS
- DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
次に、ディクショナリと固定オブジェクトの統計情報を取得する例を記載します。
SQL> -- ディクショナリ統計情報
SQL> begin
2 dbms_stats.gather_dictionary_stats(
3 options => 'GATHER'
4 );
5 end;
6 /
PL/SQLプロシージャが正常に完了しました。
SQL> -- 固定オブジェクト統計情報
SQL> begin
2 dbms_stats.gather_fixed_objects_stats;
3 end;
4 /
PL/SQLプロシージャが正常に完了しました。なお、上記に加えてシステムの統計情報をDBMS_STATS.GATHER_SYSTEM_STATSを利用して取得することも可能ですが、下記のようにデフォルト値を推奨する記載があるため、システムの統計情報は取得していません。
Unless there is a good reason to gather manually, Oracle recommends using the defaults for system statistics.
—[中略]—
Oracle recommends using the defaults for system statistics in most cases.
13.4.2 Guidelines for Gathering System Statistics
まとめ
RDS for Oracleはマネージドサービスのため、作成したら即座に使えるという素晴らしさがあります。しかしながら、意図した通りに動作させるためには、追加での設定が必要になります。
同じような構成のRDS for Oracleを利用することが見込まれる場合、毎回、同じ作業を実施するのも手間となりますので、初期作業を実施した後のRDSから手動スナップショットを作成し、テンプレートとして保存しておくという運用も考えられるかもしれません。
コメント