待ち時間分析によるOracleからPostgreSQLへの移行のトラブルシューティング：Database Performance Analyzer（DPA）

投稿日: 2024年5月28日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

レガシーなOracleデータベースをオープンソースのPostgreSQLに置き換えるというコスト削減計画を持っている場合、おそらく次のような疑問が沸いてくるでしょう：

1. PostgreSQLのワークロードのパフォーマンスがOracleよりも良い、あるいは悪い場合、その場所（および理由）をどのように特定すればよいだろうか？
2.現状のOracleのチューニングやトラブルシューティングのスキルはどのようにPostgreSQLに移行するのべきか？
3.PostgreSQLコミュニティには不安があります。チューニングや構成に関する質問はどこにすればよいのでしょうか。

初めてOracleからPostgreSQLへの移行プロジェクトに携われば、このような疑問を抱いくのは当たり前です。主にOracleとSQL Serverに関わっていて、それらのデータベースには精通し、その後PostgreSQLが登場し、データベースのライセンス費用を節約するために使い始めたエンジニアは最初にそれらの不安が当然頭をよぎります。

上記の最初の質問に対する答えは、つまりPostgreSQLで負荷がより良く、あるいはより悪くなる箇所をピンポイントで特定する方法は、待ち時間分析です。これは、データベース移行の機能テストと性能テストの段階を迅速化するのに役立ちます。何がうまくいっているのか、あるいはあまりうまくいっていないのかを理解しようとするとき、これは常套手段です。

 

最初のPostgreSQLツール-pgAdmin

最初のOracleからPostgreSQLへの移行プロジェクトで、最初にやらなければならないことはツールを整備することです。pgAdminから始めましす。pgAdminは、ユーザを作成したり、テーブル定義や現在のアクティビティを確認したりするような管理作業には適しています。しかし、Oracle Enterprise Managerで見慣れていたトラブルシューティング情報がありません。経時的な傾向を見たり、過去のデータに基づいてトラブルシューティングを行うことはできません。

Database Performance Analyzerへのツール切り替え

 Database Performance Analyzer（DPA）で、Oracleで使い慣れたPostgreSQL用の機能を使用できるようになります。また、OracleとPostgreSQLの両方をサポートしているため、両方のデータベースで表示されるパフォーマンスを正規化して比較できるという利点もあります。

待ち時間分析を使ってPostgreSQLのパフォーマンスを改善する

DPAはデータベースのワークロードを把握し、Wait Time Analysis（待機時間分析）を理解し、適切なツールを持っているとします。その場合、まだPostgreSQLを学習中であっても、移行したデータベースのチューニングを加速させることができます。Oracleから移行したPostgreSQLデータベースのWait分析について説明します。

注意: 待機イベントはPostgreSQL v9.6で導入されたため、これを行うにはPostgreSQL 9.6以降に移行する必要があります。

以下のDPAの Top SQL Average Wait TimeダッシュボードはPostgreSQLチューニングの道のりを示しています。トランザクションのスループットを数秒からミリ秒以下にするのに数日かかっています。

図 1: データベース・パフォーマンス・アナライザの平均待ち時間

1日目：PGTuneを使ってデフォルトのPostgreSQL構成設定から抜け出す
まず、PGTuneという無料のオンライン・サービスからワークロードとハードウェア固有の推奨値を使用して、デフォルトのPostgreSQL設定を変更。上記の12月6日と12月7日の平均待ち時間の比較でわかるようにし、これは大きな違いをもたらしました。

2～4日目：WALとバッファーのパフォーマンス問題の解決
以下のDPAの合計待ち時間ダッシュボードを見ると、PostgreSQLのライト・アヘッド・ロギング（WAL）が多くの時間を消費していることがわかります：

図2：合計待ち時間-WALの書き込みに多くの時間がかかっている（12月7日）。

ダッシュボードはまた、どのような設定の変更を検討すべきか推奨します。これは、PostgreSQLのチューニングの学習曲線を登っていくときに役に立ちます：

図3：Database Performance Analyzerのチューニング推奨事項

DPAが提供したアドバイスに従って、いくつかの変更を追加：

1.共有バッファとWALバッファのサイズを増加
2.WALを別の場所に移動した（これによって大きな違いが生じた）
3.バッファーの競合を減らすため、オートフィル係数を100から90に変更
4.同時セッション数を制限するためにアプリケーション・コードを変更

上の図1に示すように、これらの変更により、12月7日から12月10日にかけて平均待ち時間が8倍に短縮され、ミリ秒以下のトランザクション・パフォーマンス目標を達成することができました。

OracleとPostgreSQLのパフォーマンスの可視化

OracleとPostgreSQLのパフォーマンスを同じダッシュボードで表示できることは、特に並行テスト中に役立つ知見の1つです。DPAはPostgreSQLとOracle（および他の多くのDBMS）の両方をサポートしており、PostgreSQL対Oracleの待機時間履歴を確認することが可能です：

図4：OracleとPostgreSQLの待ち時間履歴の比較

1つのツールを使用して両方のデータベースのパフォーマンスを監視することで、OracleとPostgreSQLのパフォーマンスチューニングを正規化でき、パフォーマンスプロファイルの違いを理解しやすくなります。

DPAのその他の有用なOracleからPostgreSQLへの移行支援補助

DPAが提供する待機時間に関する洞察機能の中には、異常検知やテーブルチューニングアドバイスなど、役に立つと思われるものが他にもあります。

異常検知を使用してさらに診断する

DPA は異常検知にも使用できます。こ れは、 通常か ら 逸脱 し てい る と き に通知 し ます。例えば、下のグラフにある12月9日のオラクル待機時間データは、水曜日らしくない範囲外の値を起こしています。

図5：DPAにおける待機時間異常の可視化

そこから、異常が発生した日または時間帯をドリルダウンして、異常の原因となった特定のSQL文、文を発行したクライアント マシン、使用したリソースなどを調べることができます。

テーブルチューニングのアドバイス

個々のステートメントを確認したら、Table Tuning Advisor を使用して、そのステートメントをチューニングし、パフォーマンスを向上させるためにできることがあるかどうかを確認できます。高負荷のクエリを分析し、非効率なワークロードが実行されているテーブルを特定するのに役立ちます。このアドバイザは、テーブルと各テーブルの非効率なクエリに関する集計情報を表示します。どのSQL文に取り組み、どのテーブルにインデックスを作成すればブロックが軽減されるかを判断するのに役立ちます。

最後に

以上のようにOracleからPostgreSQLへのデータベース移行プロジェクトにおいて、DPAが待ち時間分析をどのように役立てるかの例をいくつか紹介しました。PostgreSQLの待機イベントと従来の統計データを比較することで、性能のボトルネックを特定し、自信を持って移行することができます。結局のところ、両方の分野の専門家であるDBAは稀です。

DPAによるOracleとPostgreSQLの両方の待ち時間を分析する単一のツールを使用することで、どこに注意を向けるべきか、何をどのようにトラブルシュートすべきかを理解しやすくなりました。待ち時間分析に加えて、DPAにあるチューニングのヒントは、移行プロセス中にPostgreSQLのIQを大いに高めてくれます。環境、リソースの利用状況、予測、変更の影響などをよりよく理解できるようになります。

Database Performance Analyzer（DPA）のお問い合わせはこちらへ

関連したトピックス

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。