Amazon Web Services ブログ

Amazon RDS Custom for Oracle インスタンスの構成を変更する方法 : パート1

本投稿は、Jobin Joseph、 Dwarka RaoとNitin Saxenaによる記事 Make configuration changes to an Amazon RDS Custom for Oracle instance: Part 1を翻訳したものです。

Amazon Relational Database Service (Amazon RDS) Custom は一般的なRDS よりもより多くのコントロール(データベースの構成・サーバーの構成・オペレーティングシステムの構成のカスタマイズ)を必要とするアプリケーションに柔軟性を提供するマネージド・データベース・サービスです。Amazon RDS Custom for Oracleはレガシー、カスタマイズ、パッケージアプリケーション、OSやDB環境にアクセスする必要のあるあらゆるアプリケーション向けに構成されています。

クローン環境を作成するためのスナップショットの作成/リストアや、レプリカインスタンスに読み取り専用のワークロードをオフロードするためのリードレプリカの作成、ストレージ構成の変更やAmazon RDSコンソールやAmazon RDS APIを用いてアップデートやパッチを適用するためのCustom Engine Version(CEV)の変更といった組み込み機能によって、RDS Custom for Oracleインスタンスのカスタマイズが可能です。データベースの機能・オプションの有効化やタイムゾーン・文字コードの変更といったアプリケーションごとの要件に応じてデフォルトの構成を変更する必要があるかもしれません。rootユーザーを用いたAmazon Elastic Compute Cloud(Amazon EC2)のインスタンスのシェルへのアクセスや、sysdba権限を用いたデータベースへのアクセスが可能であるため、そういったカスタマイズをEC2インスタンスやデータベース層に対して実施可能です。お客様が実施した変更がデータベースやOS上で構成されているRDS Customの監視フレームワークと自動化への影響を通知するため、AWSはサポートペリメーター機能を導入しています。お客様のRDS Custom for Oracleインスタンスに加えた変更がサポートペリメーターに違反していないかを確認することは重要です。サポートペリメーターがunsupported-configrationになった場合、加えた変更が修正されるまで、unsupported-configrationの状態となります。unsupported-configurationになった場合、RDS Custom for Oracleのマネージドサービス機能(例えば自動バックアップの作成や、基盤となる Amazon EC2 インスタンスの障害発生時のリプレース)が動作しません。

この投稿のシリーズでは、サポートペリメーターに違反することなくRDS Custom for Oracleのよくあるカスタマイズをするためにベストプラクティスとステップ・バイ・ステップについてご紹介します。

  • パート1(本投稿)ではタイムゾーンの変更とデータベースの文字コードの変更についてご紹介します。
  • パート2では、データベースの再作成を必要とするデフォルトのブロックサイズの変更についてご紹介します。
  • パート3では、flashback databaseの有効化やTNS構成・データベースオプションの構成の変更、そしてRDS Custom for Oracleインスタンスにパッチを適用するためのベストプラクティスについてご紹介します。

カスタマイズのワークフロー

サポートペリメーターに違反することなくRDS Custom for Oracleインスタンスの構成変更を行う場合、次のワークフローに従ってください。このセクションでは、それぞれのステップについてご紹介します。

Pause RDS Custom automation (RDS Customオートメーションの停止)

RDS Custom for OracleのDBインスタンスをカスタマイズする前に、カスタマイズ作業とRDS Customのオートメーションと監視フレームワークが干渉しないようにオートメーションを停止する必要があります。Amazon RDS ConsoleもしくはAWS Command Line Interface(AWS CLI)を用いてオートメーションの停止を行うことができます。具体的な手順については、Pausing and resuming RDS Custom automationのマニュアルを参照してください。メンテナンス作業を完了するために必要な時間を元に、オートメーションを停止します。必要な時間の目処が立たない場合、いったん60分でオートメーションを停止し、停止期間が切れる前に延長することもできます。

Identify the EC2 instance hosting the database(データベースが稼働しているEC2インスタンスの特定)

RDS CustomのDBインスタンスが稼働しているEC2インスタンスを特定するために以下の手順に従ってください。

  1. Amazon RDS Console上で、ナビゲーションペインの中でデータベースを選択し、接続したいRDS CustomのDBインスタンスを選択します。
  2. 設定タブを選択します。
  3. リソースIDの値を控えておきます。例えば、リソースIDはdb-ABCDEFGHIJKLMNOPQRS0123456といった値です。
  4. Amazon EC2コンソールでのナビゲーションパネルで、インスタンスを選択します。
  5. EC2インスタンスの名前を検索し、リソースIDと関連のあるインスタンスIDを選択します。例えば、EC2のインスタンスIDはi-abcdefghijklm01234といったものです。

Connect to the EC2 instance(EC2インスタンスへの接続)

必要なカスタマイズを実施するために、SSHキーあるいはAWS Systems Managerを用いて傘下のEC2インスタンスに接続します。(具体的な手順は、Connecting to your RDS Custom DB instance using AWS Systems Managerを参照してください。)

ec2-userでログインした後、rootユーザーもしくはOracle databaseのバイナリーの所持ユーザーであるrdsdbユーザーに変更できます。

ec2-user> sudo su –
or
ec2-user> sudo su – rdsdb

Verify the current configuration(現在の構成の確認)

変更作業の確認を行うために、カスタマイズ後の設定との比較を行えるように、データベースもしくはオペレーティングシステムの層で現在の構成の確認を行います。変更の内容に応じて、OSのツールもしくはデータベースへのクエリーを用いて現在の構成を確認します。

Make required configuration changes(必要な構成変更の実施)

この段階では、オペレーティングシステムのユーティリティやSQL*Plusといったデータベースのクライアントツールを用いて必要な構成変更を行います。

Reboot the EC2 instance or bounce the database(EC2インスタンスの再起動もしくはデータベースの再起動)

カスタマイズの内容に応じて、EC2インスタンスの再起動か変更が有効になるようにデータベースインスタンスの再起動を行います。

Verify modified setting(変更された設定の確認)

この段階では、カスタマイズを行う前の設定値との比較をデータベースもしくはオペレーティングシステムの層で行い、構成変更の確認を行います。

Resume automation(オートメーションの再開)

インスタンスに対してオートメーションの再開を行うことにより、RDS Customのオートメーションと監視のフレームワークを有効化します。停止期間を過ぎた後、RDS Custom for Oracleはオートメーションを自動的に再開します。しかし、メンテナンス作業が完了したタイミングで、Amazon RDS ConsoleもしくはAPIを用い、手動でオートメーションの再開を行うことが可能です。

Verify the RDS Custom automation framework(RDS Customのオートメーション機構の確認)

カスタマイズ作業が完了しオートメーションを再開し、作業が正常に進んだ場合コンソール上のインスタンスの状態が 利用可能になり、RDS Customインスタンスは自動バックアップの取得を行います。バックアップの完了後、Amazon RDS ConsoleのメンテナンスとバックアップのタブもしくはAWS CLIの以下のコマンドを用いて、最も遅い復元可能な時刻を以下のように確認することができます。

aws rds describe-db-instances --db-instance-identifier demo-2-replica
"LatestRestorableTime": "2022-05-18T11:21:27+00:00"

Amazon RDS Consoleの自動バックアップを選択し、DB名を選択し、システムスナップショットを選択することにより最新のスナップショットを確認することが可能です。もしくはAWS CLIを用いて以下のように確認することも可能です。

aws rds describe-db-snapshots --db-instance-identifier  demo-2-replica --query="max_by(DBSnapshots, &SnapshotCreateTime)"


    "DBSnapshotIdentifier": "rds:demo-2-replica-2022-05-18-11-16",
    "DBInstanceIdentifier": "demo-2-replica",
    "SnapshotCreateTime": "2022-05-18T11:17:33.417000+00:00",

この例では、demo-2-replicaがRDS Custom for Oracleのインスタンスを示します。

オートメーションが再開された後に作成された最新のスナップショットを確認すると、最も早い復元可能な時刻はオートメーションを停止した時間を指していることが確認できます。10分後に再度同じクエリーを発行すると、インスタンスのステータスがhealthになっていることが確認できます。

以降の項では、タイムゾーンの変更やデータベースの文字コードのカスタマイズについてステップ・バイ・ステップで紹介します。

データベースのタイムゾーンの変更

RDS Custom for Oracleインスタンスのタイムゾーンの変更は、ホストレベルもしくはデータベースレベルで行うことができます。

ホストレベルでタイムゾーンの変更を行うと、SYSDATE、SYSTIMESTAMPやCURRENT_DATEといった関数で返される値と全てのデータ型が影響を受けます。RDS Custom for Oracleのインスタンスがアプリケーションのデータを含む場合、タイムゾーンの変更によって時刻と対応するSystem Change Numbers(SCNs)が2つできていまい、point-int-time recovery(PITR)の実施に影響を与えます。

データベースレベルでタイムゾーンを変更するためにはALTER DATABASEコマンドを用いますが、この場合は特定のデータ型(TIMESTAMP WITH LOCAL TIME ZONE)とalter.logやtraceファイルに記載されたタイムスタンプのメッセージのみに影響を与えます。この場合、SYSDATE、SYSTIMESTAMPやCURRENT_DATE関数で返される値には影響を与えません。データベースのタイムゾーンの関数がTIMESTAMP WITH LOCAL TIME ZONE(TSLTZ)のデータ型の値を用いている場合、データベースに格納された現在のタイムゾーンで標準化されます。しかし、これらの値はセッションレベルのタイムゾーン設定によって挿入や取り出しを行う際に変換されることとなるため、データベースレベルでのタイムゾーンの設定は重要ではありません。

お客様のユースケースに応じて、データベースレベル、ホストレベル、もしくはその両方でタイムゾーンを変更するかを選択します。両方のタイムゾーンの設定を変更する方法およびタイムゾーン変更の制約とベストプラクティスについてはChanging the time zone of an RDS Custom for Oracle DB instanceをご参照ください。本項ではホストレベルとデータベースレベルでのタイムゾーンの変更方法をステップバイステップで紹介します。

ホストレベルでのタイムゾーンの変更

以下の手順でRDS Custom for Oracleのタイムゾーンをホストレベルで変更できます:

  1. カスタマイズ作業がRDS Customのオートメーションフレームワークと競合しないよう、RDS Customオートメーションの停止を行います。タイムゾーンの変更作業は30分未満で完了できます。しかし、より多くの作業時間が必要な場合は停止時間を延長をすることが可能です。
  2. RDS Custom for Oracleのインスタンスが用いているEC2インスタンスを特定し、SSHキーあるいはSystems Managerを用いて接続します。(詳細はConnecting to your RDS Custom DB instance using AWS Systems Managerを参照してください。)
  3. ec2-userでログインした後、rootユーザーに変更します。 
    ec2-user> sudo su –
  4. timedatectlを用いて現在のタイムゾーンの設定を確認します。 
    root>timedatectl
      Local time: Sat 2022-04-09 16:27:13 UTC
  Universal time: Sat 2022-04-09 16:27:13 UTC
        RTC time: Sat 2022-04-09 16:27:13
       Time zone: UTC (UTC, +0000)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
  5. 利用可能なタイムゾーンのオプションを表示します。 
    root>timedatectl list-timezones

Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
Africa/Algiers
Africa/Asmara
Africa/Bamako
Africa/Bangui
Africa/Banjul
Africa/Bissau
Africa/Blantyre
Africa/Brazzaville
Africa/Bujumbura
Africa/Cairo
Africa/Casablanca
.
.
  6.  インスタンスのタイムゾーンを希望するものに変更します。以下の例ではタイムゾーンをGMT+4に変更しています。 
    root>timedatectl set-timezone "Asia/Dubai"
  7. timedatectlを用いて現在のタイムゾーンの設定を確認します。 
    root>timedatectl
      Local time: Sat 2022-04-09 21:23:19 +04
  Universal time: Sat 2022-04-09 17:23:19 UTC
        RTC time: Sat 2022-04-09 17:23:19
       Time zone: Asia/Dubai (+04, +0400)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
  8. ベストプラクティスとして、タイムゾーンの設定を変更した後はRDS Custom for OracleインスタンスをホストするEC2インスタンスの再起動を行います。
  9. SYSDATEコマンドが変更後のタイムゾーンの値を返すことを確認します: 
    root>sudo su – rdsdb
rdsdb>sqlplus / as sysdba
SQL>  select to_char(sysdate,'DD/MM/YYYY:HH24:MI:SS') from dual;
09/04/2022:21:33:20
  10. RDS Customのオートメーションと監視フレームワークを有効化するため、オートメーションの再開を行います。
  11. オートメーションを再開した後に自動スナップショットが取得されていることを確認し、LatestRestorableTimeがオートメーション再開後の時間を示していることを確認します。

データベースレベルでのタイムゾーンの変更

デフォルトでは、RDS Custom for OracleインスタンスはUTC(+00:00)のタイムゾーンで作成されています。これはサーバーのオペレーティングシステムのデフォルトタイムゾーンです。ALTER DATABASEコマンドを用いてデータベースのタイムゾーンを変更することに加え、TIMESTAMP WITH LOCAL TIME ZONEのデータ型にデータの格納・取り出し・変換を行うためにセッションレベルでタイムゾーンを変更することができます。これにはORA_SDTZ環境変数を用いるか、もしくはALTER SESSIONコマンドを用います。より詳細については、Setting the Session TIme Zoneのマニュアルを参照してください。データベースレベルでタイムゾーンの設定を変更するには、以下の手順に従ってください:

  1. オートメーションを30分停止し、EC2インスタンスに接続し、rdsdbユーザーにスイッチします: 
    ec2-user$> sudo su – rdsdb
  2. データベースに接続し、現在のタイムゾーンの設定を確認します: 
    rdsdb$>sqlplus / as sysdba
SQL>  SELECT dbtimezone FROM DUAL;
DBTIME
------
+00:00
  3. データベースのタイムゾーン設定を希望する値に変更します。以下の例はデータベースのタイムゾーンをGMT+4に変更するコマンドです: 
    SQL>ALTER DATABASE SET TIME_ZONE='+04:00';
Database altered.
  4. データベースを再起動し、dbtimezoneの設定を確認します。(変更を有効にするためにはデータベースの再起動が必要です): 
    rdsdb$ sqlplus / as sysdba
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL>startup
ORACLE instance started.
Total System Global Area 1.2382E+10 bytes
Fixed Size                  8910200 bytes
Variable Size            6207569920 bytes
Database Buffers         6140461056 bytes
Redo Buffers               24641536 bytes
Database mounted.
Database opened.
SQL>  SELECT dbtimezone FROM DUAL;

DBTIME
------
+04:00
  5. RDS Customのオートメーションと監視フレームワークを有効にするため、オートメーションの再開を行います。
  6. オートメーションを再開した後に自動スナップショットが取得されていることを確認し、LatestRestorableTimeがオートメーション再開後の時間を示していることを確認します。

データベース・キャラクタセットと各国語キャラクタ・セットの変更

文字コードはデータベースの中の言語の格納方式を決定します。Oracle Databaseには2つのタイプのキャラクタセットがあります: データベース・キャラクタセットと各国語キャラクタセットです。データベース・キャラクタセットはPL/SQLのプログラムやCHAR、VARCHAR2、CLOBやLONG列で格納されるデータ型を決定します。各国語キャラクタセットはNCHARやNVARCHAR2列に格納されたデータの解釈に用いられます。Oracle Databaseのキャラクタセットに関するより詳細な説明は、Choosing a Character Setのマニュアルを参照してください。

本記事の投稿時点においては、RDS Custom for Oracleのインスタンスのデータベース・キャラクタセットはUS7ASCIIで作成されています。しかしながら、データベースの中の言語セットをサポートするため、RDS Custom for Oracleが作成したデータベース・キャラクタセットを変更する必要があるかもしれません。US7ASCIIがキャラクタセット要件に合致しない場合、Unicode UTF-8であるuniversal character set(AL32UTF8)に変更することを推奨します。Unicodeのキャラクタセットとして、AL32UTF8はデータベースに格納される主要な言語に対応しています。お客様の要件におうじて、他のキャラクタセットに変更することも可能です。

同様に、RDS Custom for Oracleのデータベース作成時点で設定されている各国語キャラクタセットはAL16UTF16ですが、これは推奨値です。もしアプリケーションの依存性の問題により、8bitエンコーディングのUnicodeに変更する必要がある場合、UTF8に変更することができます。現在、Oracle Databaseは各国語キャラクタセットとしてUTF8とAL16UTF16のみをサポートしています。

本記事の投稿時点おいて、RDS Custom for Oracleはデータベース・キャラクタセットと各国語キャラクタセットの設定をプロビジョン時に指定することをサポートしていません。しかしながら、本セクションで説明する方法を用いてお客様はデータベース・キャラクタセットおよび各国語キャラクタセットをインスタンスのプロビジョン後に手動で変更することができます。本記事で紹介する手順は、プロビジョンされた直後のデータベースに対して行うデータベース・キャラクタセットと各国語キャラクタセットの変更手順であり、アプリケーションのデータをロードする前に行うことを留意ください。もし、アプリケーションのデータをロード済みのRDS Custom for Oracleインスタンスのキャラクタセットを変更する場合、Changing the Character Set After Database Creationに記載されているDatabase Migration Assistant for Unicode (DMU)やexport/importの手順を実施が必要になります。そういったマイグレーションをダウンタイムを最小化して行う場合、Oracle GoldenGateやAWS Database Migration Service (AWS DMS)といったレプリケーションツールのご利用をご検討ください。

データベース・キャラクタセットの変更(NLS_CHARACTERSET)

以下の例では、データベース・キャラクタセットをAL32UTF8に変更しています。アプリケーションのデータをロードする前の状況で、Oracle Databaseがサポートする任意のキャラクタセットへの変更を同様の手順で実施できます。

  1. カスタマイズ作業がRDS Customのオートメーションフレームワークと競合しないよう、オートメーションの停止を行います。タイムゾーンの変更作業は30分未満で完了できます。しかし、より多くの作業時間が必要な場合は停止時間を延長をすることが可能です。
  2. EC2インスタンスに接続し、rdsdbユーザーにスイッチします: 
    ec2-user$> sudo su – rdsdb
  3. 現在のデータベース・キャラクタセットを確認します: 
    rdsdb$ sqlplus / as sysdba
SQL> select PROPERTY_VALUE from database_properties where PROPERTY_NAME='NLS_CHARACTERSET';

PROPERTY_VALUE
--------------------------------------------------------------------------------
US7ASCII

SQL>
  4. データベース・キャラクタセットを変更します。以下のコマンドではAL32UTF8に変更しています。AL32UTF8を任意の文字コードに置き換えて実施することも可能です。 
    SQL>shutdown immediate
SQL>startup restrict
SQL>ALTER DATABASE CHARACTER SET INTERNAL_CONVERT AL32UTF8;
SQL>shutdown immediate
SQL>startup
  5. キャラクタセットの変更を確認します: 
    SQL> select PROPERTY_VALUE from database_properties where PROPERTY_NAME='NLS_CHARACTERSET';

PROPERTY_VALUE
--------------------------------------------------------------------------------
AL32UTF8
  6. RDS Customのオートメーションと監視フレームワークを有効化するため、オートメーションの再開を行います。
  7. オートメーションを再開した後に自動スナップショットが取得されていることを確認し、LatestRestorableTimeがオートメーション再開後の時間を示していることを確認します。

注意 : ALTER DATABASE CHARACTER SET INTERNAL_CONVERTコマンドで指定するキャラクタセットは変更前のキャラクタセットのスーパーセットである必要があり、そうでない場合は以下のエラーが発生します:

ERROR at line 1:
ORA-12712: new character set must be a superset of old character set

現在のキャラクタセットのスーパーセットではないキャラクタセットへの変更を行う場合、Part2で紹介するデータベースの再作成を行います。

各国語キャラクタセットの変更(NLS_NCHAR_CHARACTERSET)

ALTER DATABASE NATIONAL CHARACTER SET UTF8コマンドを用いてRDS Custom for Oracleの各国語キャラクタ・セットをAL16UTF16(デフォルト)からUTF8に変更することが可能です。しかし、Oracleの内部スキーマにNCHARのデータが存在するため作業手順が複雑となり、以下のエラーで失敗する可能性があります:

ORA-12717: Cannot issue ALTER DATABASE NATIONAL CHARACTER SET when NCLOB, NCHAR
or NVARCHAR2 data exists

本手順を実行するためには、NCHARのデータ型を含むテーブルのデータをエクスポートし、truncateし、再度インポートする手順を行う必要があります。その代わり、Part2で記載されているように初期データベースを削除し任意のキャラクタセットで再作成するほうがより簡潔な手順です。

このセクションではデータベースの再作成を行うことなくRDS Custom for Oracleの初期データベースの各国語キャラクタ・セットをAL16UTF16からUTF8に変更するステップ・バイ・ステップの手順を紹介します。

  1. カスタマイズ作業がRDS Customのオートメーションフレームワークと競合しないよう、オートメーションの停止を行います。本手順は60分未満で完了できます。しかし、より多くの作業時間が必要な場合は停止時間を延長をすることが可能です。
  2. EC2インスタンスに接続し、rdsdbユーザーにスイッチします: 
    ec2-user$> sudo su – rdsdb
  3. 現在の各国語キャラクタセットを確認します: 
    rdsdb$ sqlplus / as sysdba
SQL> select PROPERTY_VALUE from database_properties where PROPERTY_NAME= 'NLS_NCHAR_CHARACTERSET';

PROPERTY_VALUE
--------------------------------------------------------------------------------
AL16UTF16
SQL>
  4. SYS・SYSTEM以外のスキーマが保有するテーブルのうちNCHAR、NVARCHAR、NCLOB列の特定を行うため以下のスクリプトを実行します: 
    set pages 1000 linesize 200
set serveroutput on
declare
  v_nchar_row_count  number;
  v_tables_with_nchar_data number := 0;
  v_tables_without_nchar_data number := 0;
begin
  for r in (select distinct owner, table_name
              from dba_tab_columns
             where (data_type = 'NCHAR' or data_type = 'NVARCHAR2' or data_type = 'NCLOB') 
	     and owner not in ('SYS','SYSTEM')
             order by owner, table_name
           ) loop
    execute immediate 'select count(*) from '||r.owner||'.'||r.table_name into v_nchar_row_count;
    if (v_nchar_row_count != 0) then
      dbms_output.put_line('found '||v_nchar_row_count||' rows in NCHAR table: '||r.owner||'.'||r.table_name);
      v_tables_with_nchar_data := v_tables_with_nchar_data + 1;
    else
      v_tables_without_nchar_data := v_tables_without_nchar_data + 1;
    end if; 
  end loop;
  dbms_output.put_line('total tables with NCHAR data: '||v_tables_with_nchar_data);
  dbms_output.put_line('total tables without NCHAR data: '||v_tables_without_nchar_data);
end;
/

    出力結果としてそのようなデータ型が確認されなければ、懸念はありません。

  5. データベースをrestrictedモードで起動します: 
    rdsdb$ sqlplus / as sysdba
SQL> shutdown immediate
SQL>startup restrict
  6. NCHARのデータ型を含むSYSのオブジェクト(SYS.RADM_FPTM$ と SYS.RADM_FPTM_LOB$)をエクスポートします。この手順ではRDSのプライマリユーザーをADMINと想定しています。もしRDSのプライマリユーザーがADMINではない場合、ユーザー名を置換する必要があります。 
    rdsdb$ sqlplus / as sysdba
SQL> create table ADMIN.RADM_FPTM$ as select * from SYS.RADM_FPTM$;
SQL>create table ADMIN.RADM_FPTM_LOB$ as select * from SYS.RADM_FPTM_LOB$;
SQL>create directory temp_dir as '/tmp';

-- Export the tables created in ADMIN schema.
expdp \'/ as sysdba\' directory=TEMP_DIR dumpfile=NCHAR.dmp LOGFILE=NCHAR.log tables=ADMIN.RADM_FPTM$,ADMIN.RADM_FPTM_LOB$

-- Drop tables in ADMIN schema and truncate SYS tables.

SQL>drop table ADMIN.RADM_FPTM$;
SQL>truncate table SYS.RADM_FPTM$;

SQL>drop table ADMIN.RADM_FPTM_LOB$;
SQL>truncate table SYS.RADM_FPTM_LOB$;
  7. 各国語キャラクタ・セットをUTF8に変更します: 
    SQL> alter database national character set UTF8;
  8. databaseにデータのインポートを行います: 
    impdp \'/ as sysdba\'  directory=TEMP_DIR dumpfile=NCHAR.dmp     LOGFILE=NCHAR_imp.log FULL=y TABLE_EXISTS_ACTION=TRUNCATE

SQL> insert into sys.RADM_FPTM$ (select * from ADMIN.RADM_FPTM$);
SQL>insert into sys.RADM_FPTM_LOB$ (select * from ADMIN.RADM_FPTM_LOB$);
SQL>commit;

    バージョン12cと19cのみですが、SYS.RADM_FPTM$とSYS.RADM_FPTM_LOB$はエクスポートが必要となるNCHAR型を含んでいます。そのようなデータが他にある場合、データベースの各国語キャラクタセットをUTF8に変更する手順はORA-12717で終了し、NCHAR型を含むテーブル一覧はデータベースのalert.logにリストされます。そのような場合、それらのテーブルをここで述べている手順に含んでください。

  9. テーブルとディクショナリ・オブジェクトの削除を行います: 
    rdsdb$ rm /tmp/NCHAR.dmp
rdsdb$ sqlplus / as sysdba
SQL>drop table ADMIN.RADM_FPTM$;
SQL>drop table ADMIN.RADM_FPTM_LOB$;
SQL>drop directory temp_dir;
  10. データベースの再起動を行い、各国語キャラクタ・セットの確認を行います。 
    SQL>shutdown immediate
SQL>startup
SQL> select PROPERTY_VALUE from database_properties where PROPERTY_NAME= 'NLS_NCHAR_CHARACTERSET';

PROPERTY_VALUE
--------------------------------------------------------------------------------
UTF8
  11. RDS Customのオートメーションと監視フレームワークを有効化するため、オートメーションの再開を行います。
  12. オートメーションを再開した後に自動スナップショットが取得されていることを確認し、LatestRestorableTimeがオートメーション再開後の時間を示していることを確認します。

結論

RDS Custom for Oracleはマネージドサービスの利点に加え、関連性のあるアプリケーションのさまざまな要件を満たすためにカスタマイズ可能なデータベース環境を提供します。

本投稿ではサポートペリメーターに違反することなくキャラクタ・セットとタイムゾーンのカスタマイズを行う方法をご紹介しました。本シリーズのパート2ではRDS Custom for Oracleのデータベース再作成を必要とするいくつかの構成変更、例えばブロック・サイズの変更、についてご紹介します。パート3ではflashback databaseの有効化やTNS構成の変更、データベースオプションの変更やRDS Custom for Oracleインスタンスへのパッチ適用のベストプラクティスについてご紹介します。

本投稿へのご意見はコメント欄にお願いします。

翻訳はソリューションアーキテクトの 矢木 覚 が担当しました。原文はこちらです。