OracleからPostgreSQLへの移行トラブル・シューティングに待ち時間(Wait Time)分析を活用する

レガシーなOracleデータベースをオープンソースのPostgreSQLで置き換えるというコスト削減戦略を取っている場合、次のような質問が出てくるでしょう。

1. PostgreSQL のワークロードのパフォーマンスが Oracle よりも優れている、あるいは劣っている場所（および理由）をピンポイントで特定するにはどうすればよいか？
2. 使用中のOracle チューニングとトラブルシューティングのスキルはどのように PostgreSQL に移行するのか？
3．PostgreSQLのコミュニティは私にとって新しいものです。チューニングや構成に関する質問はどこにすればいいのでしょうか？

上記の最初の質問に対する答えは、PostgreSQLで作業負荷がより良く、あるいはより悪くなる場所をピンポイントで特定する、待ち時間分析です。これは、データベース移行の機能および性能テストフェーズを迅速化するのに役立ちます。これは、何がうまくいっているのか、あるいはうまくいっていないのかを理解する最善方法です。

最初に PostgreSQL ツール-pgAdminを利用

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

Database Performance Analyzerへのツール変更

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

PostgreSQL のパフォーマンスを向上させるための待ち時間分析の使用

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

注：Wait Eventsは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：データベースパフォーマンスアナライザーによるチューニングの推奨事項

DPAが提供するアドバイスに従って、いくつかの変更を加えました。

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

上記の図1に示すように、これらの変更により、12月7日から12月10日にかけて平均待ち時間を8倍に短縮し、サブミリセンドのトランザクション性能目標を達成することが可能になりました。

OracleとPostgreSQLの性能比較の可視化

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

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

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

DPAに装備されたその他の便利なOracleからPostgreSQLへの移行支援ツール

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

異常検知でさらに診断する

DPAは異常検知にも使えます。正常な状態から逸脱している場合に教えてくれるのです。例えば、下のグラフの12月9日のOracleの待ち時間のデータは、水曜日らしくなく、大きく外れているため、私の注意を引くことになりました。

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

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

テーブル・チューニングのアドバイスを受ける

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

最後に

以上、OracleからPostgreSQLへのデータベース移行プロジェクトに役立つ待ち時間分析の使用例を紹介しました。PostgreSQLの待機イベントと従来の統計データを比較して、パフォーマンスのボトルネックを特定し、自信を持って移行するために、既に知っていることを受け入れることができます。残念なことに、両方の分野の専門家であるDBAはほとんどいないのです。

OracleとPostgreSQLの両方の待ち時間を分析するために1つのツールを使うことで、どこに注意を向けるべきか、何をどのようにトラブルシュートすればよいかを容易に理解することができました。待ち時間分析に加え、DPAにあるチューニングのヒントは、移行プロセスにおいてPostgreSQLの知識を大きく向上させるのに役立つでしょう。環境、リソース利用、予測、変更の影響などをより理解できるようになります。

関連したトピックス

• 待ち時間分析によるOracleからPostgreSQLへの移行のトラブルシューティング：Database Performance Analyzer（DPA）
• 進化するクエリと PostgreSQLの台頭：そのデータベー スパフォーマンス重要性
• 仮想化されたデータベース：パフォーマンス監視の考慮事項
• Database Performance Analyzer [DPA] でSQL Serverのパフォーマンスを見つけ、分析し、最適化へ
• PostgreSQLとMySQLのデータベースとしての機能の違い
• Oracle SE データベースと Query Performance Analyzer [Oracle Performance Analyzer: DPA]
• ユーザ・データベースの最適化とOracle支出の削減
• Oracle RAC パフォーマンス・チューニング
• DPA(Ignite)のアラート設定について(待ち時間アラート編:Wait Time Alert)
• PostgreSQLパフォーマンス・チューニング・ツール（クエリアナライザ付き) [DPA]