電話番号 電話番号 お問い合わせ

受付時間 平日10:00~18:00

TOP

資料ダウンロードはこちら >>

ロゴ

AWSやシステム・アプリ開発の最新情報|クロスパワーブログ

AWS RDS

Amazon RDS for Oracle入門(3)

PCと筆記用具

マツナミです。前回から引き続き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で異なる箇所を見ていきたいと思います。