Database Support Blog

【PostgreSQL/EPAS】障害発生に備えて取得しておきたい情報

PostgreSQL/EDB Postgres Advanced Server(以降、EPAS)運用中には、様々なエラーが発生することがあり、そういった障害発生時の初動調査には様々な情報が必要となります。
実際には、発生した障害によって取得する情報は異なる場合もありますが、本記事では一般的に障害時の初動調査をする際に必要となる情報をご紹介いたします。

取得しておきたい情報

postgresql.conf

DBクラスタに対して設定されているパラメータにどのようなものがあるか確認し、その設定に起因して事象が発生していないか切り分けます。
通常、dataディレクトリ(環境変数PGDATAの場所)に格納されています。

PostgreSQL/EPASのサーバログ

象発生タイミングに問題視するべきエラー等が出力されていないか、また、そういった出力がある場合には発生事象との因果関係はあるのか、等を確認する目的で収集します。
サーバログを確認する際は、効率よく調査を進める目的でサポートセンターから事象発生タイミングを伺うことがあります。
デフォルトは、dataディレクトリ(環境変数PGDATAの場所)配下の pg_logディレクトリに格納されています。

事象発生タイミング

事象発生タイミングの近辺に何か問題視するべき出力がないか効率的に確認する目的でヒアリングします。

事象発生タイミングが不明だと、どの出力内容を問題視するべきか特定できなかったり、効率よく調査が進まなかったりします。

pg_stat_activity/pg_locks

ロック獲得待ちに起因した事象発生であるか確認したり、事象発生当時どのようなSQLが実行されていたか確認したりする目的で取得します。
SELECTリストには、current_timestampを追加しておくと実行タイミングが明らかとなり、調査に役立ちます。
なお、pg_stat_activity/pg_locksは実行時点の情報が取得できますので、事象発生最中に取得するか、定期的に取得できるよう工夫する必要があります。

psql -c "select current_timestamp, * from pg_stat_activity"
psql -c "select current_timestamp, * from pg_locks"

また、PostgreSQL/EPAS9.6以上をご利用であれば、pg_blocking_pidsシステム情報関数と、pg_stat_activityビューを使用することでロック獲得中のセッションと、ロック獲得待ちをしているセッションを簡単に確認することが可能です。

   
 postgres=# \x
 Expanded display is on.
 
 postgres=# SELECT pid, pg_blocking_pids(pid), state, wait_event_type,
 wait_event,query
 postgres-# FROM pg_stat_activity;
 -[ RECORD 1
 ]----+----------------------------------------------------------------------------
 pid              | 19495 <-- ★ロック待ちしているプロセス
 pg_blocking_pids | {19724}
 state            | active
 wait_event_type  | Lock★
 wait_event       | transactionid
 query            | update test set col2 = 'AAAAA' where col2 = 'AAA';
 -[ RECORD 2
 ]----+----------------------------------------------------------------------------
 pid              | 19724 <-- ★ロック獲得中のプロセス
 pg_blocking_pids | {}
 state            | active
 wait_event_type  |
 wait_event       |
 query            | SELECT pid, pg_blocking_pids(pid), state,
 wait_event_type, wait_event,query+
                  | FROM pg_stat_activity;
   

OS負荷情報

取得しておきたい情報は、OSごとに異なります。一般的には下記のような情報を取得すると初動調査に役立ちます。

Windows環境では、イベントログ(システム/アプリケーション)から問題視すべきエラーや出力がないか確認したり、パフォーマンスモニタからサーバの負荷状況を確認したりします。

Linux環境では、topコマンドから CPUやメモリの使用率が高いプロセスが存在しないか確認したり、vmstatコマンドからサーバの負荷状況を確認したりします。

補足情報

Linux環境をご利用の方に限定されてしまいますが、上述で記載した pg_stat_activityや pg_locksの情報に加えて、psや top等の情報も 1分ごとに 5回取得できるサンプルスクリプトをご用意しました。


調査のために、事象が発生している最中だけではなく、比較対象として事象が発生していない時(正常時)にも情報を採取してください。
下記スクリプト内の PGPORT/PGUSER/PGDATABASEといった環境変数の値にはお客様環境の情報を代入し、「chmod +x <サンプルスクリプト名>」コマンドにて実行権限を付与した上でご利用ください。

#!/bin/sh
export PGPORT=10000
export PGUSER=p100
export PGDATABASE=postgres
echo "Please wait for five minutes."
dmesg | grep Memory > dmesg.txt
EXECNT=0
while (( ${EXECNT} < 5 ))
do
EXE_DATE=`date +'%Y/%m/%d %H:%M:%S'`
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> ps_ef.txt
ps -elf >> ps_ef.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> mpstat.txt
mpstat 1 3 >> mpstat.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> meminfo.txt
cat /proc/meminfo>> meminfo.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> slabinfo.txt
cat /proc/slabinfo >> slabinfo.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> ps_eo.txt
ps -eo pid,%cpu,%mem,rss,vsz,stat,wchan=WIDE-WCHAN-COLUMN,args >> ps_eo.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> top.txt
top -b -n 1 | head -50 >> top.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> vmstat.txt
vmstat 1 3 >> vmstat.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> iostat.txt
iostat -x 1 3 >> iostat.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> swapon.txt
/sbin/swapon -s >> swapon.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> netstat1.txt
netstat -a -i -n >> netstat1.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> netstat2.txt
netstat -s >> netstat2.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> pg_stat_activity.txt
psql -c "select clock_timestamp(),* from pg_stat_activity" >> pg_stat_activity.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> pg_locks.txt
psql -c "select clock_timestamp(),* from pg_locks" >> pg_locks.txt
sleep 60
EXECNT=`expr ${EXECNT} + 1`
done
exit

まとめ

障害が発生したというお問い合わせを弊社にも多くいただきますが事象発生タイミングの情報を取得していなかったために、原因追求や有効な対処方法の提示が難しい場合がありました。
この情報以外にも障害に応じてサポートセンターから追加で情報依頼させていただくことがありますが、今後なんらかの障害が発生した際の一次調査や解決にお役立てできれば幸いです。


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

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

関連している記事

  • Oracle Database
  • Oracle Cloud
2025.12.25

Oracle Databaseユーザー必見!ZRCVで始めるランサムウェア対策

ランサムウェアの脅威からデータベースを守る!OCIのフルマネージドバックアップサービスZRCVは、3-2-1-1-0ルールに対応し、データ損失ゼロに近い復旧を実現します。本記事では堅牢な保護機能と、GUIで完結するわずか5ステップのシンプルな設定方法を解説します。

  • Oracle Database
2025.12.22

【Oracle Database】FAQを活用したDBエンジニア育成

本記事では、お客様の自己解決率向上のために注力したFAQ作成、および、そのFAQ作成をエンジニア育成に活用した当社ならではの取り組みをご紹介します。

  • Oracle Cloud
  • Oracle Database
2025.12.12

Oracle AI World2025視察記

今年もオラクル社の年次イベント「Oracle AI World 2025」が開催され、アシストからも11名の社員がラスベガス現地で参加しました。 本記事では「Oracle AI World 2025 視察記」として「Oracle AI World 2025のハイライト」と「アシストの注目ポイント」を、Oracle AI World 2025全体の雰囲気とともにお伝えします。

ページの先頭へ戻る