Oracle から Azure Database for PostgreSQL への移行のベスト プラクティス
適用対象: 
Azure Database for PostgreSQL - フレキシブル サーバー
次のシナリオでは、Oracle から Azure Postgres への移行中に発生した潜在的な課題の一部について説明します。 推奨されるソリューションは、独自の移行を計画および実行するときに、これらの課題を克服するのに役立ちます。
シナリオ: 同じデータベース上で独立して動作している 2 つの個別の低遅延、高スループットのクライアント アプリケーションが検出されました。 各アプリケーションにより、誤って他のキャッシュされたクエリがバッファーから外されてしまいました。 共有読み込みとリソースの組み合わせの競合により、データベースの共有バッファーが頻繁にフラッシュされすぎて、両方のシステムのパフォーマンスが低下する結果になりました。
推奨される解決策: システム グローバル領域 (SGA) とプログラム グローバル領域 (PGA) の両方のメモリ構造のメモリ消費量と使用率パターンなど、データベース プラットフォーム環境のすべての側面を、最初の評価がキャプチャしていることを確認します。 リソース要件に一致するコンピューティングの適切なファミリを選択し、Postgres の計画容量が必要に応じて調整されていることを確認します。
ヒント
pg_buffercache 拡張機能は、使用率を調べる手段を提供し、共有バッファー プールで何が起こっているかをリアルタイムで確認できます。
Buffer Cache Hit Ratio
ヒット率を調べることで、キャッシュの有効性を評価し、共有バッファー サイズが適切かどうかを判断できます。 優れたキャッシュ ヒット率は、ほとんどのデータ要求がディスクではなくメモリから処理され、最適なパフォーマンスを提供している証拠です。
SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;
最も頻繁にアクセスされるテーブルとインデックス
最も頻繁にアクセスされる、およびバッファー プール内の最も多くの領域を占有しているテーブルとインデックスを調べると、メモリにキャッシュされているホットスポットを特定するのに役立ちます。
SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;
バッファー プールの競合
バッファー プール内の著しい競合は、複数のクエリが同じバッファー領域で競合し、パフォーマンスのボトルネックの発生につながる可能性があることを示します。 バッファー アクセスの場所と頻度を調べると、このような問題の診断に役立ちます。
SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;
シナリオ: 移行作業が、Postgres プラットフォームのリリース サイクルの間に、複数のリリースで開始されました。 最新リリースで新機能と機能強化が利用できるにもかかわらず、移行の開始時に選択されたバージョンは変更されていません。 その後、最適なパフォーマンスと新機能を実現するために、最初の移行後に Postgres データベースのバージョンをアップグレードするために、追加の作業、時間、および費用が費やされました。
推奨される解決策: 可能な限り、移行時に最新リリース バージョンの Postgres の導入に優先順位を付けます。 Postgres コミュニティ開発チームは、すべてのパフォーマンスと安定性を新しいリリースごとに最大限に高めるために懸命に取り組んでいます。それを活用せずにいることは、本質的にパフォーマンスを後回しにしていることを意味します。 さらに、Azure の新機能も最大限に活用しましょう。 新しい Azure Postgres 機能には、SSDv2 ストレージ、インフラストラクチャの最新のサーバー ファミリ、自動インデックス チューニング、自律サーバー パラメーター チューニング機能が含まれます。
シナリオ: 初めて Postgres に移行する組織は、実行速度が遅いクエリを特定する際のベスト プラクティスとアプローチになじみがないことがあります。 適切に新しいインデックス型を実装するときは、特別な配慮と注意が必要です。 特に、Postgres データベース エンジンは、クエリ ヒントを指定する必要性や機能なしで、クエリのパフォーマンスを最適化するように設計されています。
推奨される解決策: 拡張機能は、Postgres を非常に強力なものにするための不可欠な部分です。 データベースが最高のパフォーマンスで動作していることを確保できる重要な機能を提供する拡張機能がいくつかあります。 検討すべき主な拡張機能には、次のようなものがあります。
auto_explain: は、設定済みのしきい値を超えて実行されるクエリの実行プランを自動的にログします。 データベース管理者は、各クエリで EXPLAIN を手動で実行せずに、パフォーマンスの問題を診断し、クエリのパフォーマンスを最適化できます。
pg_trgm: は、trigram 一致を使用してテキスト ベースのデータの類似性を判断するための関数と演算子を提供します。 この拡張機能は、テキスト検索、あいまい一致、および類似性ベースのクエリを含むタスクに有用です。 テキスト列の GIN または GIST インデックスと組み合わせると、LIKE クエリと類似性検索のパフォーマンスが向上します。
pg_cron: を使用すると、定期的なタスクをデータベース内で直接スケジュールおよび管理できます。 cron のようなジョブ スケジューリングを Postgres に統合すると、定期的なメンテナンス タスク、データ処理、同様の反復操作を自動化できます。
ヒント
データベース操作に大量のデータベース オブジェクトの作成と削除の繰り返しが含まれている場合、古い pg_catalog システム テーブルのタプルが増加し、テーブルの "肥大化" が発生します。 pg_catalog は多くのデータベース操作に関係するシステム テーブルであるため、このテーブルに対して完全なメンテナンスを行うと、データベース全体のパフォーマンスが低下する可能性があります。 定期的な pg_cron スケジュールを構成することで、pg_catalog が適切に維持され、適切にバキュームされることを確保できます。
- pg_hint_plan: Postgres は、手動による介入を必要とせずに一貫した信頼性の高いパフォーマンスを提供することを目的としており、その結果、クエリ ヒントを含めないように意図的に設計を決定します。 クエリ プランの設計を具体的かつ正確に制御する必要がある一部のシナリオには、SQL コメントに埋め込まれたヒントを使用してクエリ プランナーの決定に影響を与える方法が pg_hint_plan により提供されます。 これらのヒントを使用すると、データベース管理者は、複雑なクエリを最適化したり、プランナーが単独で処理できない可能性があるパフォーマンスの問題に対処したりするために、クエリ プランナーが特定のプランを選択するように指示できます。
Note
これらの例は、Postgres データベースで使用できる非常に膨大な拡張機能のセットのほんの一部にすぎません。 Postgres データベースを最大限に活用するため、これらの拡張機能を完全に探索することをお勧めします。 さらに、Postgres を現在の機能を超えて拡張できる可能性がある場合は、独自の拡張機能を作成することも検討できます。 強力に柔軟な拡張アーキテクチャにより、Postgres は常にプラットフォームの要件に合わせて適応および進化できるようになります。
シナリオ: 場合によっては、レガシ テーブル パーティション戦略によって何千ものパーティションが作成されることがあります。 これは以前に使用したときは有効であったかもしれませんが、これらの戦略では、特定の状況で Postgres のクエリ パフォーマンスが低下するおそれがあります。 非常に特殊なケースでは、クエリを解析するときに、クエリ プランナーが適切なパーティション キーを特定できない場合があります。 その結果、計画時間が長くなり、クエリの計画に実際のクエリ実行よりも時間がかかります。
推奨される解決策: パーティションを過剰に大量に生成するパーティション分割戦略の必要性を再評価します。 Postgres データベース エンジンでは、データの同じセグメント化が不要になっていて、パーティションの数を減らすとパフォーマンスが向上する可能性があります。 従来のパーティション分割スキームが評価され、必要と判断された場合は、最初に動的パーティション キーを識別して抽出し、その後、クエリ操作でパーティション キーを使用するために、クエリを個別の操作に再構築することを検討してください。
シナリオ: 外部の依存関係や環境の状況によっては、Oracle と Azure Postgres の両方のデータベースが共存する必要があるハイブリッド データベース シナリオが必要になる場合があります。 たとえば、データのインポートや複雑な ETL プロセスの変更のオーバーヘッドなしに、Azure Postgres から直接 Oracle データにアクセスしてクエリを実行するために段階的な移行が必要になる場合があります。 その他の例では、Oracle と Azure Postgres の両方の環境で同等のデータセットを同時に比較して並列データ検証を実行すると、移行中および移行後にデータの整合性と整合性を確保するのに役立ちます。
推奨される解決策: PostgreSQL Foreign Data Wrapper (FDW) 拡張機能は Postgres の主要な機能で、外部システムに保存されたデータに、あたかも Azure Postgres データベースにネイティブに存在しているかのようにアクセスし、それを操作することができます。 FDW を使用すると、Azure Postgres をフェデレーション データベースとして機能させることができます。これにより、Oracle データベースを含む任意の数の外部データ ソースとの統合が可能になります。 FDW により Postgres データベース内に外部テーブル定義が作成され、それらの外部テーブルは定義された外部データ ソースのプロキシとして機能し、ユーザーは通常の SQL クエリを使用してこれらの外部テーブルに対してクエリを実行できます。 内部的には、Postgres エンジンは外部 FDW 定義を使用して、リモート データ ソースからの要求に応じてデータと通信し、調整します。
oracle_fdw: (Foreign Data Wrapper for Oracle) は、Azure Postgres 内から Oracle データベースにアクセスできる Postgres 拡張機能です。 Oracle から Azure Postgres に移行する場合、データ アクセス、データ検証、増分移行、リアルタイム データ同期を提供することで、oracle_fdw が重要な役割を果たすことができます。 FDW を使用する場合は、次の重要な考慮事項に留意することが重要です。
- oracle_fdw を介してクエリを実行すると、リモート Oracle サーバーからデータが処理およびフェッチされている間、ネットワーク通信と認証ネゴシエーションの形でオーバーヘッドが発生します
- 一部のデータ型では、システム間でデータ型が正しくマップされるように、特別な処理または変換が必要になる場合があります。
oracle_fdw を効果的に使用すると、移行プロセス全体を通じてアプリケーションとデータにアクセスできるようになり、データベースの移行を簡素化し、データのアクセシビリティが確保される可能性があります。