障害の原因調査に備えて採取すべき情報

アシストのサポートセンターでは様々な障害のお問い合わせをいただきますが、障害の原因調査に必要な情報が採取されていない場合、原因調査を進めることが困難になることが少なくありません。また、お客様から「様々な障害の原因調査に備えて採取すべき情報を教えてほしい」というお問い合わせをいただくことも増えてきています。そこで、今回はPostgreSQLにおける様々な障害の原因調査に備えて採取すべき情報をご紹介します。

様々な障害調査に備えて採取すべき情報

データベースが起動しない、処理がハングしたなど障害の内容によって調査に必要となる情報は異なりますが、様々な障害の初期調査（障害の発生箇所の切り分け）をよりスムーズに進めるために最低限採取しておきたい情報は以下です。

PostgreSQLのログファイル
pg_stat_activity・pg_locksビューの情報
サーバーの負荷情報
OSのログファイル

以降では、上に挙げた各種情報の採取方法について詳しくご紹介します。

PostgreSQLのログファイル

必要な理由

出力先

Windows

Linux

pg_stat_activity・pg_locksビューの情報

必要な理由

サーバーの負荷情報

OSのログファイル

■本記事の内容について
　本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。

■商標に関して
　・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
　・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
　　文中の社名、商品名等は各社の商標または登録商標である場合があります。

今さら聞けない!?WALアーカイブのベストプラクティス

PostgreSQL開発に多く貢献しているEnterpriseDB社による WALアーカイブ設定に関するベストプラクティスをご紹介します。

EDB
PostgreSQL

2025.04.16

PostgreSQLの拡張機能「system_stats」のご紹介

EDB社が提供するPostgreSQLの拡張機能「system_stats」はPostgreSQL ユーザーがパフォーマンス問題に取り組む際の非常に強力なツールになります。SQLクエリでOS情報を取得できるため、DBエンジニアにとってはパフォーマンスの監視が格段に簡単になります。テストした結果をご紹介します。