マツナミです。前回から引き続きAmazon RDS for Oracleとオンプレの違いについてみていきます。具体的には、オプショングループとスケジューラ設定について見ていきたいと思います。
オプショングループ
RDS for Oracleでは2017年6月現在以下のようなオプショングループがあります(11.2.0.4の場合。12.1.0.2だと下記より少ないです)。
APEX
APEX-DEV
NATIVE_NETWORK_ENCRYPTION
OEM
OEM_AGENT
SSL
STATSPACK
Timezone
UTL_MAIL
XMLDB
各オプションの詳細については公式サイトを見てもらうとして、特に重要なところ(と私が独断したところ)を見ていきます。
タイムゾーン
オンプレからRDSへの移行する際、必ず検討しないといけないのが本オプション設定です。
RDSに限った話ではありませんが、AWSのサービスはデフォルトのままだとUTCの設定になっているものが多く、その場合日本の時間と9時間ずれます。
sysdateやsystimestampの結果も9時間ずれるので、データへの影響は大きいです。
本項目で[Asia/Tokyo]を設定することで、日本時間とsysdateを合わせることができるのでオンプレからのアプリ移行が楽になりますね。
それではまず、オプションを設定しなかったときの挙動から見てみましょう
C:\Users\crosspower>sqlplus dbmaster/xxxxxxxx@yyyyyyyy SQL*Plus: Release 11.2.0.4.0 Production on 金 6月 16 06:13:36 2017 Copyright (c) 1982, 2013, Oracle. All rights reserved. Oracle Database 11g Release 11.2.0.4.0 - 64bit Production に接続されました。 SQL> alter session set nls_date_format='YYYY/MM/DD hh24:mi:ss'; セッションが変更されました。 SQL> col sessiontimezone for a30 SQL> select sysdate, sessiontimezone, dbtimezone from dual; SYSDATE SESSIONTIMEZONE DBTIMEZONE ------------------- ------------------------------ ------------ 2017/06/15 21:13:58 +09:00 -04:00 SQL> exit
SQL*Plusがログイン時に出力している時間と SYSDATEの時間が約9時間ずれていることがわかります。
SESSIONTIMEZONEはクライアントの設定を読んでいるため、ただしく+09:00になっているようですがDBTIMEZONEが-04:00になっている理由は不明です。 オンプレでDBCAを実行してインストールした場合、DBTIMEZONEは+00:00になりますしマニュアルにも+00:00が良いとの記載もあるのですが…。謎です。
気を取り直して、DB作成時にあらかじめオプショングループでTimezoneをAsia/Tokyoに変更していた場合の設定を見てみましょう。
C:\Users\crosspower>sqlplus dbmaster/xxxxxxx@zzzzzzzz SQL*Plus: Release 11.2.0.4.0 Production on 金 6月 16 06:20:26 2017 Copyright (c) 1982, 2013, Oracle. All rights reserved. Oracle Database 11g Release 11.2.0.4.0 - 64bit Production に接続されました。 SQL> alter session set nls_date_format='YYYY/MM/DD hh24:mi:ss'; セッションが変更されました。 SQL> col sessiontimezone for a30 SQL> select sysdate, sessiontimezone, dbtimezone from dual; SYSDATE SESSIONTIMEZONE DBTIMEZONE ------------------- ------------------------------ ------------ 2017/06/16 06:20:31 +09:00 -04:00
SQL*Plusがログイン時に出力している時間と SYSDATEの時間がほぼ一致しました。 SESSIONTIMEZONEとDBTIMEZONEは変わらずですね。
なお、ここまでの確認はRDS for Oracle 11.2.0.4.v12で確認しましたが、12.1.0.2.v8でも同様です。 DBTIMEZONEの変更は下記の通りRDSADMINのコマンドで変更できますが、その場合「TIMESTAMP WITH LOCAL TIME ZONE」型のデータに影響があるため、要動作確認です。
SQL> exec rdsadmin.rdsadmin_util.alter_db_time_zone(p_new_tz => '+00:00'); PL/SQLプロシージャが正常に完了しました。 SQL> select sysdate, sessiontimezone, dbtimezone from dual; SYSDATE SESSIONTIMEZONE DBTIMEZONE ------------------- ------------------------------ ------------ 2017/06/16 06:29:40 +09:00 +00:00 SQL>
STATSPACK
Oracleの性能分析のツールとしてAWRがありますが、これはEnterprise Editionの有償オプションのため、Standard Editionなどで性能分析をするにはSTATSPACKがほぼ必須です。 STATSPACKはOracle社のサポートから外れましたが、機能自体はまだ利用可能です。
RDS for OracleでSTATSPACKを利用するには、管理コンソール上のオプショングループにてSTATSPACKを選択してポチっとするだけです。 その後対象のインスタンスに対してPERFSTATスキーマが作成され、使えるようになります。
オンプレでSTATSPACKをインストールする場合、PERFSTATスキーマの表領域を選択できますが、RDS for Oracleでは表領域は指定できず、デフォルトのSYSAUXとなります。
SQL> select username, default_tablespace from dba_users order by 1; USERNAME DEFAULT_TABLESPACE ------------------------------ ------------------------------ APPQOSSYS SYSAUX CTXSYS SYSAUX DBMASTER USERS DBSNMP SYSAUX DIP USERS OUTLN SYSTEM PERFSTAT SYSAUX RDSADMIN RDSADMIN SYS SYSTEM SYSTEM SYSTEM 10行が選択されました。 SQL>
詳細な使い方は公式サイトが詳しいので割愛しますが、STATSPACKレポートをWeb上で見られるのはいかにもクラウドな感じです。
スケジューラ
ここでいうスケジューラとはOracle Databaseが内部的に持っているジョブスケジューラの設定のことです。
自動メンテナンス・タスク
Oracleの設計やら運用やらをしていると、統計情報が22時から自動的に取得されるけど夜間バッチと被るから統計情報取得のタスクの開始時間をずらさないと…みたいな話はよく聞く話です。 ここでRDS for Oracleで実行される時間などを確認してみます。
SQL> select window_name, window_next_time from dba_autotask_window_clients; select * from dba_autotask_window_clients * 行1でエラーが発生しました。: ORA-01882: タイムゾーンのリージョンが見つかりません SQL>
あら、珍しいエラーですね。 上記オプショングループを設定したにも関わらずタイムゾーンの情報が確認できていないようです。 今回使っているRDSインスタンスはデフォルトのオプショングループで作成したのち、Timezoneを追加したものなのですが、それが影響しているのかもしれません。 インスタンス作成時にオプショングループを明示的に設定して試してみましょう。
SQL> select window_name, window_next_time from dba_autotask_window_clients; WINDOW_NAME WINDOW_NEXT_TIME ------------------------------ -------------------------------------------------- MONDAY_WINDOW 17-06-19 22:00:00.000000 EST5EDT TUESDAY_WINDOW 17-06-20 22:00:00.000000 EST5EDT WEDNESDAY_WINDOW 17-06-21 22:00:00.000000 EST5EDT THURSDAY_WINDOW 17-06-22 22:00:00.000000 EST5EDT FRIDAY_WINDOW 17-06-16 22:00:00.000000 EST5EDT SATURDAY_WINDOW 17-06-17 06:00:00.000000 EST5EDT SUNDAY_WINDOW 17-06-18 06:00:00.000000 EST5EDT 7行が選択されました。 SQL>
こちらの環境では情報が取得できました。 オプショングループでタイムゾーンを設定するなら、インスタンス作成時からオプショングループを指定した方が良さそうですね。
SQLの結果を見ると、タイムゾーンを最初から設定した環境でも、ウィンドウの開始時刻に設定されているタイムゾーンが日本時間のJSTではなく、アメリカ東部のEST5EDTになっています。 EST5EDTはUTC -04:00(夏時間でない期間は -05:00)なので、DBTIMEZONEが-04:00だったこととも関連がありそうです。
このままだと日本時間と13時間ずれて動くことになってしまうので、タイムゾーンを戻しましょう。 まずはOracleのスケジューラのデフォルトタイムゾーンの設定を確認・変更します。
SQL> select dbms_scheduler.stime from dual; STIME --------------------------------------------------------------------------- 17-06-16 18:46:07.814547000 EST5EDT SQL>
EST5EDTになってることがわかります。
SQL> exec DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('default_timezone','+09:00'); PL/SQLプロシージャが正常に完了しました。 SQL> select dbms_scheduler.stime from dual; STIME --------------------------------------------------------------------------- 17-06-17 07:49:42.580173000 +09:00 SQL>
EST5EDTだった箇所が+09:00 に変更されました。これでメンテナンス・ウィンドウの時刻もオンプレと同じになりますね。
SQL> select window_name, window_next_time from dba_autotask_window_clients; WINDOW_NAME WINDOW_NEXT_TIME ------------------------------ -------------------------------------------------- MONDAY_WINDOW 17-06-19 22:00:00.000000 +09:00 TUESDAY_WINDOW 17-06-20 22:00:00.000000 +09:00 WEDNESDAY_WINDOW 17-06-21 22:00:00.000000 +09:00 THURSDAY_WINDOW 17-06-22 22:00:00.000000 +09:00 FRIDAY_WINDOW 17-06-23 22:00:00.000000 +09:00 SATURDAY_WINDOW 17-06-24 06:00:00.000000 +09:00 SUNDAY_WINDOW 17-06-18 06:00:00.000000 +09:00 7行が選択されました。 SQL>
スケジューラ・ジョブ
自動メンテナンス・タスクと比べると認知度が低く、そもそも何をやっているのかもよくわからないジョブ群ですが、オンプレとの違いを確認する意味でも確認しておきましょう。 オンプレ環境では以下のようになっています。
SQL> select job_name,next_run_date, schedule_name from dba_scheduler_jobs order by 1; JOB_NAME NEXT_RUN_DATE SCHEDULE_NAME ------------------------------ ---------------------------------------- ------------------------------ BSLN_MAINTAIN_STATS_JOB 17-06-18 00:00:00.000000 -05:00 BSLN_MAINTAIN_STATS_SCHED DRA_REEVALUATE_OPEN_FAILURES MAINTENANCE_WINDOW_GROUP FGR$AUTOPURGE_JOB FILE_WATCHER FILE_WATCHER_SCHEDULE HM_CREATE_OFFLINE_DICTIONARY MAINTENANCE_WINDOW_GROUP MGMT_CONFIG_JOB 17-06-17 01:01:01.000000 -05:00 MGMT_STATS_CONFIG_JOB 17-07-01 01:01:01.000000 -05:00 ORA$AUTOTASK_CLEAN 17-06-17 03:00:00.000000 US/CENTRAL DAILY_PURGE_SCHEDULE PURGE_LOG 17-06-17 03:00:00.000000 US/CENTRAL DAILY_PURGE_SCHEDULE RLM$EVTCLEANUP 17-06-16 21:40:37.300000 -05:00 RLM$SCHDNEGACTION 17-06-17 11:48:25.000000 +09:00 RSE$CLEAN_RECOVERABLE_SCRIPT 17-06-17 00:00:00.000000 US/CENTRAL SM$CLEAN_AUTO_SPLIT_MERGE 17-06-17 00:00:00.600000 US/CENTRAL XMLDB_NFS_CLEANUP_JOB 14行が選択されました。 SQL>
RDS for Oracleでスケジューラのデフォルトタイムゾーンを変更した場合、以下のように設定されています。
SQL> select job_name,next_run_date, schedule_name from dba_scheduler_jobs order by 1; JOB_NAME NEXT_RUN_DATE SCHEDULE_NAME ------------------------------ ---------------------------------------- ------------------------------ BSLN_MAINTAIN_STATS_JOB 17-06-18 00:00:00.800000 -04:00 BSLN_MAINTAIN_STATS_SCHED DRA_REEVALUATE_OPEN_FAILURES MAINTENANCE_WINDOW_GROUP FGR$AUTOPURGE_JOB FILE_WATCHER FILE_WATCHER_SCHEDULE HM_CREATE_OFFLINE_DICTIONARY MAINTENANCE_WINDOW_GROUP ORA$AUTOTASK_CLEAN 17-06-18 03:00:00.400000 +09:00 DAILY_PURGE_SCHEDULE PURGE_LOG 17-06-18 03:00:00.400000 +09:00 DAILY_PURGE_SCHEDULE RSE$CLEAN_RECOVERABLE_SCRIPT 17-06-18 00:00:00.400000 +09:00 SM$CLEAN_AUTO_SPLIT_MERGE 17-06-18 00:00:00.400000 +09:00 9行が選択されました。 SQL>
ジョブ数が異なるのはインストールしている機能の違いによるものですが、同一ジョブでも異なるのはオンプレ環境とRDS for Oracleの差異ととらえて良さそうです。
これらジョブについては具体的に何をやっているかについてのドキュメントが少ないため、いつ実施するのが良いかといったことの判断は難しいですが、差異があるということは覚えておいて良さそうです。
今回はタイムゾーンの話ばかりになってしまいました。次回は監視回りでオンプレとRDS for Oracleで異なる箇所を見ていきたいと思います。