Postgresqlのレポート機能について

Postgresql8.1とAccess2003にて販売管理システムを構築しております。
データベースサーバーは会社に設置しており
自宅からPgAdmin1.10にて接続し管理などを行っております。

サーバーにはA、Bと同じ構成をしたデータベースが存在しています。
PgAdminからAのテーブルにSQLを実行したところ
タイムアウトなのか無限ループに陥ったのか、エラーでSQLの処理が止まってしまい
PgAdmin毎落ちました。

仕方なく、再度PgAdminからAのデータベースに接続しようとすると
「could not receive data from server: Software caused connection abort(0x00002745/10053)」
とエラーが表示され、その後一切の接続できなくなりました。
PgAdminの再インストールや、PC・ネットワーク環境を変えたりしましたが
どの方法でもA、Bともに接続不可となってしまいました。

そこでサーバー自体の再起動を行いましたところ
アプリケーション（Access）からAのデータベースに接続することができ
データの読み書きも問題なく出来ました。
また、PgAdminを使った場合も外部から接続するのではなく
同じローカルネットワーク内から接続すると問題なく
A、Bのデータベースに接続でき、テーブルの参照やレコードの編集、
VACUUMやバックアップ(pg_dump)も可能でした。


ここでまず一つ目の質問ですが、

このA、Bのデータベースは、破損している状態でしょうか？
もしくはPostgreSQL毎破損している状態でしょうか？

PgAdminから出力できるレポートで該当テーブル全体の統計情報を見ると
タプルの挿入や更新などがすべて「0」で表示されます。
（サイズだけは計算されて、恐らく実データ量だと思われるバイト数が表示されていました）


二つ目の質問ですが、

Aのデータベースの状態が”壊れている状態”だとしたら、すぐにでも
バックアップを取り、新しくデータベースを作り直してリストアしたいと考えていますが
バックアップ前のデータベースとリストア後のデータベースを比較して、
レコードがすべてリストア出来ているかを確認したいのですが
どのような方法で確認できますか？
例えば全テーブルのレコード数一覧などを出力し比較出来る事が望ましいですが
前述のテーブルの統計情報レポートでは、まともに数字が表示されないので
困っております。

（なお、アーカイブ形式のバックアップだと一部テーブルのレコードが一切復元されない
という現象が発生した為、プレーン形式でのバックアップを考えています。
プレーン形式で書き出して中身を見たところ、問題のテーブルのレコードも
はき出されておりました。（これも、"破損"と考えた要因の一つです））


現状、アプリケーションからの利用だけで言えば、特段問題がありませんが
やはり気持ちが悪く、出来る限り修復（or再構築）を行いたいと考えています。
詳しい方、アドバイスなどあれば是非教えてください。
宜しくお願いいたします。

No.1 ベストアンサー 回答者： copymaster 回答日時： 2011/03/06 03:02

あくまで個人の経験からの話です。

記載されている内容から、
「could not receive data from server: Software caused connection abort(0x00002745/10053)」
の時点でPostgreSQLのサービスが落ちて、サーバー自体の再起動時に、PostgreSQLのサービスが
上がって正常復旧。という状況かと思われます。

障害が起きた時に実行したSQL文は、select文でしょうか。
それならば、キャパシティをオーバーする大量行数のクエリが返るSQLでハングすることはありえても
DBMS(PostgreSQL本体)や、データベースがぶっ壊れることはまずないと思われます。
また、select文ならばトランザクションの復旧などは不要です。

PostgreSQL8.1は、Windows版でしょうか。
「アーカイブ形式のバックアップだと一部テーブルのレコードが一切復元されない」のは、
はもともとである気がします。
今回の障害以前に、アーカイブ形式のバックアップ＆リストアは成功した実績はありますでしょうか。
私は、8.1のWindows版で、アーカイブ形式で上手くいったためしがないので、
これは“使えない機能”と判断し、いつも必ずプレーンテキストでダンプしてました。

全テーブルのレコード数一覧をとる方法ですが、私は、
select count(*) from テーブル1;
select count(*) from テーブル2;
select count(*) from テーブル3;
…
とSQL文を羅列したファイル(仮にc:\temp\getcnt.sqlとする)を作り、コマンドラインから、psqlで
\o c:\temp\res.txt
\i c:\temp\getcnt.sql
\q
のように、ファイル（この場合、c:\temp\res.txt）に実行結果を書き出して、数えています。

（なお、Windows版の場合、psql を使うときは、
　>psql -U postgres <データベース名>
　のように、ユーザ名(postgres)を指定してpsqlに接続する必要があります。）

ご心配でしたら、ためしに別の名前のデータベースを作って、そこにダンプをリストアしてみて、
行数をカウントして本番サーバと同じであれば特に問題ないのではと思います。

過去、PostgreSQL(Linux版)のデータベースがぶっ壊れた状態も経験していますが、
その時は、ダンプ時にエラーが出ました。特定のテーブルに差し掛かった時に
読めないと怒られるという状況でした。
ぶっ壊れた原因はメモリ障害でした。SQL文ごときでデータベースがぶっ壊れるというのは
まずありえないのではないかと思います。

この回答へのお礼

丁寧に回答頂き、有り難うございます。

私が使用しているのは、Linux版の8.1です。
その後、会社のモデムとルーターを再起動すると何事もなかったかのごとく
PgAdminにて接続できました。。
いったい何だったんでしょうか。

ちなみに「UPDATE文」で障害が起きました。
（テーブルのカラムの属性を変更するUPDATE文だったと思います。


ただ、アーカイブ形式のダンプはやはり特定のテーブルのみ
リストアされませんし、レポートの数値もやはり0のままです。

全テーブルのレコード数確認の方法、早速使わせて頂きます。
大変勉強になりました。

（早く8.4にバージョンアップしたいのですが
使用しているSQL文がそのまま使用できないのでまずはそこから見直しです。。）

本当に有り難うございました。

お礼日時：2011/03/07 16:35