Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行する上でのベスト プラクティス: PostgreSQL 環境のターゲット データベースに関する考慮事項

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行する上でのベスト プラクティス: PostgreSQL 環境のターゲット データベースに関する考慮事項:

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログ記事は、データベース移行で考慮すべきコンポーネントに関する高水準の側面について説明するシリーズの第 3 回です。このシリーズでは、アプリケーション コンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事「データベースの移行—始める前に知っておく必要のある事柄」をお読みください。

以前の記事、「移行プロセスとインフラストラクチャに関する考察」および「Oracle および AWS DMS CDC 環境でのソース データベースの考察」では、Oracle データベースの構成方法について説明しました。この考察には AWS Data Migration Service (AWS DMS) および AWS Schema Conversion Tool (AWS SCT) のセットアップが含まれていました。これらの設定後、かつデータ移行の開始前に、ターゲットの PostgreSQL データベースを、関連するすべてのスキーマとパラメータを使って起動および稼動させる必要があります。

このシリーズの最後のブログ記事では、AWS DMS と AWS SCT を使用して Oracle データベースからの移行を支援するために PostgreSQL 環境を設定する方法の概要を示します。この記事では、移行セットアップに役立つ PostgreSQL データベースパラメータの構成について説明します。

移行環境では、高可用性、スケーラビリティ、アーカイブ、バックアップ、負荷分散、およびロールバックのための戦略を採用することもお勧めします。これらの戦略については、この記事では扱いません。また、データベース移行の手動部分については触れません。独自の要件やアプリケーションの依存関係の複雑さに合わせて調整できるステップバイステップの手順も含まれません。これらの詳細については、「PostgreSQL を使用した Oracle Database 11g/12c から Amazon Aurora への移行」プレイブックを参照してください。このプレイブックでは、特定の Oracle データベースのオブジェクトと機能を PostgreSQL の互換機能を使って Amazon Aurora に手動で移行する方法が説明されています。

DMS とセカンダリ オブジェクトの移行

DMS は、すべてのデータをソースからターゲットに効率的に移行するために必要なオブジェクトのみを移行します。これらには、プライマリ キー、場合によっては一意のインデックスが含まれます。DMS は、外部キー制約、トリガー、セカンダリ インデックスなどのセカンダリ オブジェクトの移行は行いません。

この機能のために、DMS はテーブルごとに移行を実行するので、完全な読み込み中に外部キー制約とセカンダリ インデックスが無効になっていることを確認してください。外部キー制約を保持すると、 完全な読み込みが失敗します。外部キー制約とセカンダリ インデックスは、フル ロード フェーズ後に有効にする必要があります。キャッシュされた変更を適用する前にインデックスを適用できますが、外部キーを有効にするには、キャッシュされた変更を適用する必要があります。

Amazon RDS for PostgreSQL の主要パラメータに関する推奨事項

以下に、Amazon RDS for PostgreSQL の主要パラメータに関する推奨事項を示します。データ読み込み専用の場合、データベース パラメータ グループを変更して次の設定を含めます。パラメータ設定をテストし、DB インスタンス サイズにとって最も効率的な設定を見つけてください。また、データ移行の完了後に、これらのパラメータを本稼動の値に戻す必要があります。

データを読み込む前に、いくつかの重要な DB インスタンス パラメータを設定します。

• DB インスタンスのバックアップを無効にします (backup_retention を 0 に設定)。これにより、読み込み中の自動バックアップが無効になります。
• Multi-AZ を無効にします。これを提案するのは、マルチ AZ 配置では、スタンバイ時に発生する同期データ複製のために、シングル AZ 配置と比較して書き込みおよびコミットのレイテンシを増やすことができるためです。
• wal_buffer、Maintenance_work_mem、checkpoint_segments、および checkpoint_timeout を増やします (説明は、以下を参照してください)。
• synchronous_commit を無効にします (説明は、以下を参照してください)。
• AUTOVACUUM は無効にしません。有効にすると、AUTOVACUUM は大量の挿入、更新、または削除されたタプルを持つテーブルをチェックします。この機能は、読み込みが完了するまでは求められており、大量のデータが読み込まれるとトランザクション ID のラップアラウンドが停止します。
• vacuum_freeze_min_age は無効にしません。この設定を減らすと、テーブルを再びバキューム処理しなければならなくなる前に経過可能なトランザクションの数が増えるため、トランザクション ID のラップアラウンドが発生する可能性があります。
• 初期読み取り後に分析をバキューム処理して最新の統計を維持する:
  
  • 適度に正確な統計情報を得ることは重要です。さもないと計画の選択肢が貧弱になり、データベースのパフォーマンスが低下する可能 性があります。
  • LOBS を含むテーブルに対して VACUUM FULL を実行します。DMS は行を更新することでデータをチャンクにロードし、PostgreSQL 上で bloat を作成します。VACUUM FULL では、より多くのディスク容量を再利用できますが、実行速度は標準形式の VACUUM よりもはるかに遅くなります。標準形式では、本稼動データベース操作と並行して実行が可能だからです。
• ロギングのデフォルトをより詳細に調整します。

Shared_buffers

shared_buffers パラメータの設定量を決定します。RDS PostgreSQL パラメータのデフォルト設定として、システム メモリの 25％ から開始します (単位は 8 KB)。Aurora PostgreSQL では、デフォルトはメモリの 75% です。

このパラメータをチェックするには、次のコマンドを実行します。

pg=> select setting from pg_settings where name like 'shared_buffers';  ( in 8K unit) setting  
--------- 
 62500 
(1 row) 

このパラメータの現在値を表示するには、次のコマンドを実行します。

pg=> show shared_buffers;   # show actual value 
 shared_buffers  
---------------- 
 500,000kB 
(1 row) 
 
[oracle@ip-x-x-x-x ~]$ echo "62500*8"|bc 
500000 

Max_Connections

これは厳しい制限なので、最大接続を大目に見積もるようにしてください。 制限に達するとクライアントは接続を拒否され、システムがハングします。

RDS PostgreSQL 9 および 10 では、この値は次の通りです。 LEAST({DBInstanceClassMemory/9531392},5000)

例として、RDS PostgreSQL 9 および 10 で T2.micro DB インスタンス クラスの場合を考えましょう。T2.micro インスタンス クラスが保持できるメモリは 1 GB ですが、これは 1024 * 1024 * 1024 バイト / 9531392 に等しく、言い換えると 112.65 です。0.65 の接続というのはあり得ないので、最大接続を 112 または 113 に丸めます。次のコマンドを使用して、インスタンスの max_connections 値をチェックできます。

postgres=> show max_connections;

Aurora では、デフォルトのパラメータ グループには、エンジン、計算クラス、およびインスタンスの割り当てられたストレージに基づいて、データベース エンジンのデフォルトおよび Amazon RDS システムのデフォルトが含まれます。デフォルト DB パラメータ グループのパラメータ設定は変更できません。パラメータ設定をデフォルト値から変更するには、RDS ドキュメントの説明に従って独自の DB パラメータ グループを作成する必要があります。これを行うには、カスタム パラメータ グループの max_connections パラメータを変更します。その後、新しいパラメータ グループを使用するように DB インスタンスを変更する必要があります。

DB インスタンスに関連付けられた DB パラメータ グループを変更する場合は、DB インスタンスによって新しい DB パラメータ グループが使用される前に、インスタンスを手動で再起動する必要があります。

先書きログ (WAL)

WAL ファイルを使用して、データベースの変更に関する情報を記録します。これらの変更は、WALセグメントと呼ばれるセグメントに格納されます。 WAL セグメントは、短期の WAL バッファとは対照的な、永久記憶域を表します。WAL セグメントは、コンテンツ (WAL レコード) をリカバリと複製に確実に使用できるようにするのに役立ちます。wal_buffers パラメータで、WAL 用の共有メモリ内のディスクページ バッファの数を設定します。この共有メモリは、まだディスクに書き込まれていない WAL データ用に使用されます。この値の単位は 8KB です。このパラメータを設定すると、WAL 生成速度の向上に役立ちます。

パラメータ max_wal_size (単位は WAL セグメント) を使用して、WAL セグメントを制御します。Aurora PostgreSQLではこのパラメータを調整することはできません。これは RDS PostgreSQL でのみ可能です。ただし、max_wal_size もチェックポイントの設定に影響します。checkpoint_timeout 秒ごとのチェックポイントの開始、または max_wal_size の超過の、どちらか早いほうが発生したときに、これが影響を及ぼします。WAL セグメントの場合、このパラメータは、スタンバイが回復に WAL ファイルを必要とする場合に備えて、ディスクに保持される WAL ファイルの数を決定します。各ファイルのサイズは 16 MB です。RDS のデフォルトは 32 です。ただし、これは特定のニーズに応じて変えることができます。たとえば、個々のファイルが 16 MB の場合、max_wal_size を 32 に設定すると、ディスク上の WAL レコード用に 512 MB の領域が予約されます。

PostgreSQL 10 では、このパラメータの単位がファイルからメガバイトに変更されました。この変更は、PostgreSQL 10 で max_wal_size を 32 に設定すると、32 MB に設定されることを意味します。

コマンド pg=> show wal_buffers; を実行すると、出力は次のようになります。

 wal_buffers  
------------- 
 14432 KB 
(1 row)

パラメータ	デフォルト値	最大値	ステータス	現在	単位	説明
wal_buffers	-1	2147483647	True	エンジンのでデフォルト	整数	(8 KB) WAL 用共有メモリ内のディスクページ バッファの数を設定する

デフォルト設定の -1 では、PostgreSQL ドキュメントに記載されている通り、shared_buffers の 1/32 (約 3%) に等しいサイズが選択されます。

移行に WAL パラメータを使用する場合は、次の操作を行います。

• データベースがデータ ウェアハウスでない場合は、work_mem を 1M デフォルトに変更してください。このパラメータはソートごと、クライアントごとに設定され、メモリが不足しなくても必要です。
• システム メモリが完全に不足してしまうことを確実に防ぐため、メモリーベースのチューニング可能パラメータ (主に shared_buffers と work_mem) を注意深くかつ調和良く調整する必要があります。maintenance_work_mem を 1 GB の RAM あたり 約 50 MBに設定します。
• wal_buffers を 16 MB に増やします。これを行うには、このパラメーターの単位が 8 KB であるため、2048 に設定します。

チェックポイント パラメータ

時折、ユーザがチェックポイント パラメータの非標準設定をパフォーマンス不良と解釈し、これがストレージに関する I/O の問題につながることがあります。Aurora PostgreSQL における IOPS の処理は、PostgreSQL エンジンの標準バージョンとは異なります。Aurora は、従来の PostgreSQL のデータ ブロックベースのシステムとは対照的に、ログベースのストレージ システムを使用します。

この場合、2 つのエンジン間で書き込みは大きく異なります。Aurora PostgreSQL では、Write IOPS メトリックは 1 秒あたりに生成されたオーロラストレージ書き込みレコードの数を報告します。この数値は、データベースによって生成されたログ レコードの数とほぼ同じです。これらの書き込みは、8 KB のページ書き込みに対応しておらず、送信されたネットワーク パケットにも対応していません。また、この値は、課金目的で I/O を測定するために使用するものではありません。

チェックポイントがワークロードに基づいて適切に設定されていない場合、システムが遅くなる可能性があります。チェックポイントは、以下が原因で引き起こされます。

• WAL ファイルに相当する checkpoint_segments が書き込まれている。
• 前回のチェックポイント以降、checkpoint_timeout 秒が経過した。
• SQL コマンド CHECKPOINT を使用して、手動でチェックポイントを強制した。

特定の設定が、データベース チェックポイントを回避する助けになります。RDS PostgreSQL では、checkpoint_segments を 16 (256 MB) から 256(256*16=4096=4 GB) 以上 (1,024 でも良い) に増やすことをお勧めします。また、checkpoint_timeout を 1,800 (デフォルトは 300) に増やすこともお勧めします。これらのパラメータを調整できるのは RDS PostgreSQL だけで、Aurora PostgreSQL では調整できません。

同様に、PostgreSQL 9.4 (9.5 ではなく) では、max_wal_size を 256 (デフォルトは 128) に設定します。PostgreSQL 9.6 および 10 のデフォルト max_wal_size 値は、1 GB です。

同じことが Oracle にも当てはまります。特定の設定では、ディスク上のデータベース データ ファイルへのダーティ バッファ キャッシュ ページの書き込みに遅延が発生します。この種の遅延はポイントインタイムリカバリ時間を増加させるため、データ移行のパフォーマンスが向上します。この改善のために、以下を設定してください。

• checkpoint_segments – 自動 WAL チェックポイント間のログ ファイル セグメントの最大数 (各セグメントは通常 16 メガバイトです)。この値のデフォルトは 16 で、16*16 MB=256 MB になります。サーバーがビジー状態にある場合や大量のデータ移行を行っている場合、この最大値ではすぐにいっぱいになります。
• checkpoint_timeout – 自動 WAL チェックポイント間の最大時間 (秒)。この値はデフォルトで 300 秒 (5 分) です。RDS PostgreSQL では、1800 (30 分) に変更することをお勧めします。Aurora PostgreSQL ではこの値は変更できません。Aurora PostgreSQLでは、checkpoint_timeout パラメータの値は 60 秒に設定されています。この設定は、開発チームのパフォーマンス テスト、RDS 回復サービスの依存関係、およびその他の要因に基づいています。

上記の現在のチェックポイント パラメータ設定を確認するには、以下を実行します。

pg=> select * from pg_settings where name like '%checkpoint%';

WAL パラメータの実行時構成の詳細については、PostgreSQL のドキュメントで「ログ先行書き込み」を参照してください。

SYNC_Commit

FSYNC を無効にしないでください。代わりに、DISABLE synchronous_commit を使用してディスクへの書き込みを高速化してください。数パーセントのパフォーマンス向上を得るために FSYNC を無効にする価値はありません。FSYNC を無効にすると、データベースを破壊される危険にさらすことになります。

Maintenance_work_mem

用途に応じて maintenance_work_mem パラメータを 16 MB、512 MB、1,024 MB、または 4,096 MB に変更してみて、どの程度の改善が見られるかを確認してください。以下の手法をお勧めします。

1. まず、2GB に設定し、次に逆方向に作業してゆきます。
2. VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY など、メンテナンス操作に使用するメモリの最大量を指定します。
3. デフォルト値を大きく設定し過ぎないように注意してください。AUTOVACUUM が実行されると、このメモリー量を autovacuum_max_workers 倍まで割り当てることができます。デフォルトの autovacuum_max_workers 値は、RDS PostgreSQL では 3 です。

次のコマンドは、maintenance_work_mem の現在値を示します。

postgres=> show maintenance_work_mem; 
maintenance_work_mem 
50961 kB 
(1 row)

関連するもう 1 つのパラメータ work_mem は、ソートごとおよびクライアントごとに機能します。通常、クエリ内で実行されるソートはそれほど多くありません。普段実行されるのは、1 つか 2 つだけです。さらに、アクティブなすべてのクライアントのソートが同時に行われるわけではありません。

work_mem の通常のガイダンスは、shared_buffers を割り当てた後の空き RAM の量を考慮することです。effective_cache_size の計算に必要なのと同じ OS キャッシュサイズの数字。この値を max_connections で除算し、その数値の端数を取ります。その数値の半分が、積極的な work_mem 値です。同時に 2 つのアクティブなソートをすべてのクライアントで実行するなら、サーバーのメモリが不足する可能性がありますが、恐らくそのようなことはないでしょう。

次のコマンドは、work_mem の現在値を示します。

postgres=> select name,setting,unit from pg_settings where name = 'work_mem'; 
 name          | setting | unit 
----------+---------+------ 
work_mem | 4076    | kB 
(1 row) 
 
postgres=> show work_mem; 
work_mem 
---------- 
 
4076kB 
(1 row)

work_mem のチューニングおよび log_temp_files の使用について詳しくは、PostgreSQL wiki の「PostgreSQL Server のチューニング」を参照してください。この種のチューニングは、ログのソート、ハッシュ、一時ファイルに対して行うことができます。このロギングを使用して、ソートがメモリに収まらずにディスクに流出しているかどうかを調べることができます。

関連するもう 1 つの解決策は、max_connection を RDS のデフォルト値 (100) ではなく 1000 に設定することです。

バキューム パラメータ

デフォルトでは、RDS PostgreSQL で autovacuum が有効です。次のコマンドを実行して、これを確認できます。

postgres=> show autovacuum; 
 autovacuum 
------------ 
 on 
(1 row) 

移行をセットアップするには、データを読み込む前に手動によるバキューム操作を実行します。これで、移行のパフォーマンスを向上させることができます。別の有用な手法については、AWS データベースのブログ記事「Amazon RDS for PostgreSQL でのトランザクション ID ラップアラウンドの早期警戒システムの実装」を参照してください。

データを読み込む前に、バキューム プロセス用に以下を実行することをお勧めします。

pg=> vacuum verbose; 
pg=> vacuum full verbose; 
pg=> select relname,last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables; 
pg=> select relname,last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_all_tables where schemaname = 'public'; 
 
check table n_dead_tup > 0 
pg=> select relname, n_dead_tup, last_vacuum, last_autovacuum from pg_catalog.pg_stat_all_tables where n_dead_tup > 0 [ and relname = 'pg_authid' ] order by n_dead_tup desc; 
 relname  | n_dead_tup | last_vacuum | last_autovacuum  
-----------+------------+-------------+----------------- 
pg_authid |          2 |             |  

Shared_buffers と pg_buffercache

PostgreSQLには、専用のメモリ (shared_buffers パラメータで指定) とファイル システム キャッシュの両方を活用します。最初は、shared_buffers と effective_cache_size の RDS のデフォルト設定から開始できます。shared_buffers と OS キャッシュに基づいて effective_cache_size を調整します。RDS PostgreSQL 9 では、デフォルトは {DBInstanceClassMemory/16384} です。単位は 8 KB なので、インスタンス メモリの半分になります。

OS cache size を max_connections で除算してから、2 で除算します。これにより、クライアントのソートごとに使用される work_mem の最大限妥当な設定が得られます。デフォルトは 1M であるため、データ ウェアハウス システムでの性能を理解するには 4M、8M と設定してゆき、1G まで試してください。work_mem の単位は KB です。

システムに 1 GB 以上の RAM が搭載されている場合、shared_buffers の妥当な開始値はシステム メモリの 4 分の 1 です。RAM それより少ない場合は、OS が占有している RAM をより慎重に考慮する必要があります。その場合は、15％ 付近が一般的です。一部のワークロードでは、shared_buffers の設定をさらに大きくすると効果的です。ただし、PostgreSQL がオペレーティング システムのキャッシュにも依存することを考えると、RAM の 40％ より多くを使用する必要は通常ありません。

RDS PostgreSQL での shared_buffers のデフォルト設定は、{DBInstanceClassMemory/32768} *8K = 8192/32768=1/4 です。

以下は、サーバーが使用する共用メモリー バッファーの数を示します。

shared_buffers -> {DBInstanceClassMemory/32768} -> 16-1073741823 -> true - > system -> static -> integer -> (8kB)

shared_buffers パラメーターは、サーバーによって使用される共用メモリーの主要コンポーネントです。これは、ブロックのキャッシング、およびデータベースの読み込みと書き込みに割り当てられたラージ ブロックを示します。

pg=> select name,setting,unit,current_setting(name) from pg_settings where name='shared_buffers'; 
      name      | setting | unit | current_setting  
----------------+---------+------+----------------- 
shared_buffers | 65000   | 8kB  | 500MB 
(1 row) 

shared_buffers の設定が低すぎると、起動時に次のエラーが発生する可能性があります。

 
 
FATAL: could not create shared memory segment: Invalid argument 
DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600) 
-------- 
postgres=> SHOW rds.extensions;    
(since RDS Postgres 9.4, pg_buffercache extension is available, RDS Postgres 9.3 doesn't support)  
----------------------------------------------------------------------------------------------------------------- 
btree_gin,btree_gist,chkpass,citext,cube,dblink,dict_int,dict_xsyn,earthdistance,fuzzystrmatch,hstore,intagg,intarray,ip4r,isn,ltree,pgcrypto,pgrowlocks,pgstattuple,pg_buffercache,pg_prewarm,pg_stat_statements,pg_trgm,plcoffee,plls,plperl,plpgsql,pltcl,plv8,postgis,postgis_tiger_geocoder,postgis_topology,postgres_fdw,sslinfo,tablefunc,test_parser,tsearch2,unaccent,uuid-ossp 
(1 row) 
 
postgres=> select * from pg_available_extensions where name = 'pg_buffercache';  
      name      | default_version | installed_version |             comment              
----------------+-----------------+-------------------+--------------------------------- 
 pg_buffercache | 1.0             | 1.0               | examine the shared buffer cache 
(1 row) 
postgres=> create extension pg_buffercache; 
 
extension 
 
postgres=> select name,setting,unit,current_setting(name) FROM pg_settings where name='shared_buffers'; 
      name      | setting | unit | current_setting  
----------------+---------+------+----------------- 
 shared_buffers | 25480   | 8kB  | 203840kB 
(1 row) 
postgres=> select count(*) from pg_buffercache; 
 count  
------- 
 25480 
(1 row)

システムの shared_buffers の大きさを見て、pg_buffercache によって返されるエントリ数が一致していることに注目することで、ユーティリティが期待どおりに動作していることを確認できます。

関連するデータベース内部の動作を理解するために、 pg_buffercache モジュールを使用して PostgreSQL のshared_buffers データベース キャッシュの現在の内容を調べることができます。 そうすることで、さまざまなアクティビティを実行しながら共有メモリ内のブロックがどのように変化するかを視覚的に確認できます。pg_buffercache を使用すると、現在接続しているデータベースに関連する有用な情報を表示できます。

pg_buffercache の詳細は、PostgreSQL ドキュメントの「pg_buffercache」および PostgreSQL wiki の「PostgreSQL Server のチューニング」を参照してください。

pg_buffercache を使用してキャッシュを確認するには、次のコマンドを実行します。

pg=> create extension pg_buffercache; 
CREATE EXTENSION 
 
pg=> SELECT c.relname, pg_size_pretty(count(*) * 8192) as buffered, round(100.0 * count(*) / ( SELECT setting FROM pg_settings WHERE name='shared_buffers')::integer,1) AS buffers_percent,round(100.0 * count(*) * 8192 / pg_relation_size(c.oid),1) AS percent_of_relation FROM pg_class c INNER JOIN pg_buffercache b ON b.relfilenode = c.relfilenode INNER JOIN pg_database d ON (b.reldatabase = d.oid AND d.datname = current_database()) WHERE pg_relation_size(c.oid) > 0 GROUP BY c.oid, c.relname ORDER BY 3 DESC LIMIT 10; 
 
        relname               |  buffered  | buffers_percent | percent_of_relation  
------------------------------+------------+-----------------+--------------------- 
 pg_depend                    | 520 kB     |            0.1 |               106.6 
 pg_transform_type_lang_index | 8192 bytes |   0.0 |   100.0 
 TEST9                             | 8192 bytes |         0.0 |               100.0 
 awsdms_status            | 8192 bytes |         0.0 |               100.0 
 t1                                    | 8192 bytes |         0.0 |               100.0 
 TEST10                           | 8192 bytes |         0.0 |               100.0 
 pg_namespace_oid_index | 16 kB      |      0.0 |               100.0 
 pg_constraint_oid_index   | 16 kB      |      0.0 |               100.0 
 pg_extension_oid_index    | 16 kB      |      0.0 |               100.0 
 TEST8_pkey                   | 16 kB          |          0.0 |               100.0 
(10 rows) 

メモリ内のページは、ブロックに加え、バッファ ヘッダーと呼ばれる、ブロックの種類を識別するための少量のオーバーヘッドを保持します。

effective_cache_size

effective_cache_size パラメータは、OS と PostgreSQL のバッファ キャッシュで使用できるメモリの量の目安であり、割り当てではありません。この値は、考慮している計画が RAM に収まるかどうかを判断するために、PostgreSQL のクエリー プランナだけで使用されます。このパラメータをあまりに低く設定すると、インデックスを使用したクエリーが期待どおりに実行されない可能性があります。shared_buffers の設定はここでは考慮されていません。effective_cache_size だけなので、データベース専用のメモリーも含める必要があります。

effective_cache_size を合計メモリの半分に設定するのは、通常の保守的な設定です。

外部キー

一部のテーブルで外部キーが有効になっていると、初回読み込み時に読み込みが失敗します。フル ロードを実行する場合は、外部キーの依存関係を無効にする必要があります。または、次で説明する追加属性を使用して、読み込み障害を回避できます。それ以外の場合は、外部キーの競合が存在します。フル ロードでの外部キーを無効にしてから、移行タスクを停止して、外部キーを再度有効にできます。詳細は、DMS ドキュメントの「フル ロード タスクの設定」を参照してください。

さらに、フル ロード中に外部キーを無効にするために、ターゲット エンドポイントに余分な接続属性があるかどうかをチェックすることもできます。詳細は、

DMS ドキュメントの「PostgreSQL を AWS DMS のターゲットとして使用する場合の余分な接続属性」を参照してください。PostgreSQL を AWS DMS のターゲットとして構成するために使用できる余分な接続属性を確認します。

afterConnectScript=SET session_replication_role='replica' 

外部キーを持つテーブルの読み込み処理は、次のようになります。

1. AWS SCT を使用してスキーマを移行します。
2. 上記の属性を使用して AWS DMS にすべての外部キーとユーザー トリガーをバイパスさせない場合は、ターゲットへの外部キーの依存性を無効にします。この属性を使用すると、フル ロード モードの使用時にデータをバルク ロードする時間が大幅に短縮されます。
3. ターゲット準備モードを使用してタスクを DO NOTHING として作成し、進行中のレプリケーションが開始される直前にタスクが停止することも確認します。詳細は、DMS ドキュメントの「フル ロード タスクの設定」を参照してください。
4. フル ロードが完了してタスクが停止したら、ターゲット上で外部キーを有効に戻します。
5. タスクを開始し、ソースとターゲットが同期している場合は、アプリケーションを停止します。ソースにアクセスして数分間待ち、開いているトランザクションがターゲットで完了したことを確認します。
6. アプリケーションにターゲットを指し示すと、移行プロセス全体がうまくいきます。

まとめ

Oracle から PostgreSQL への移行は、さまざまな段階のデータ移行を経る、特殊なスキルを必要とする複雑なプロセスになることがあります。このシリーズのブログでは、データベースを移行する上で考慮すべきコンポーネントに関する高度な説明を提供します。このシリーズでは、アプリケーション コンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。これらは利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事「データベースの移行—開始する前に知っておく必要のある事柄」を参照してください。

移行プロセスでは、AWS DB Freedom プログラムで利用可能な移行方法を使用できます。当社は、革新的な近代化サービスを提供し、組織が既存のソフトウェア アプリケーションに最新の技術を適用して、新しい AWS クラウド ソリューションを作成することを可能にします。これは、たとえば従来の Oracle アプリケーションを AWS クラウドに移行したり、複数のデータソースにリアルタイムでアクセスしたり、Aurora または RDS PostgreSQL データベースでレガシーアプリケーションを使用したりすることを意味します。さらに、このプロセスを使用すると、古い言語のアプリケーションを新しいアプリケーションに直接接続できます。同じ標準を使用し、AWS Database Migration Service (AWS DMS)、および AWS Consulting Service Partners (AWS CSP)、および当社の AWS ISV パートナーと協力して、レガシー データを移行および統合できます。これにより、既存のアプリケーションの可能性を最大限に引き出す助けになります。組織は、投資収益率を高め、生産性と効率性を向上させ、運用リスクを管理する能力を得ることができます。

データベース移行環境設定のさまざまな段階については、3 つのブログ記事に分けて説明しています。まだお読みでない場合は、初期移行プロセスとインフラストラクチャの考慮事項について詳しく解説されている「移行プロセスとインフラストラクチャに関する考慮事項」をお読みください。また、「Oracle および AWS DMS CDC 環境のソース データベースに関する考慮事項」を参照すると、Change Data Capture (CDC) を使用したワンタイム移行または片方向継続レプリケーション用のソース データベース環境の設定に役立ちます。

これらの 3 つのブログ記事は、Oracle から PostgreSQL へのデータベース移行のためのコンポーネントの設定の概要をまとめたものです。これらの記事では、より包括的なデータベース移行戦略を構築する前にテストする必要がある基本手順が説明されています。このシリーズを、完全な解決策とは決して考えないでください。特定の Oracle データベース オブジェクトと機能を Amazon Aurora with PostgreSQL Compatibility の同等機能に手動で移行する手順については、「Oracle Database 11g/12c から Amazon Aurora with PostgreSQL への移行 Playbook」を参照してください。

謝辞

このブログは、Melanie Henry、Wendy Neu、Eran Schitzer、Mitchell Gurspan、Ilia Gilderman、Kevin Jernigan、Jim Mlodgenski、Chris Brownlee、Ed Murray、および Michael Russo の徹底的で粘り強いレビューとフィードバック無しには執筆は不可能でした。

---

著者について

Mahesh Pakala は、2014 年から Amazon に勤務しています。Amazon 入社以前は、Ingres、Oracle Corporation、Dell Inc. など各社で経験を積みました。戦略重視の顧客に向けて、可用性とスケーラビリティの高いアプリケーション、異種クラウドアプリケーションの移行について設計をアドバイスし、システムパフォーマンスの支援を行っています。