[pgsql-jp: 34977] Re: データーベース破損について

[yasushi,m]

マスオカです。
岡野様　早速のご教授有り難うございます。


>レンタル容量オーバー時にはレンタル業者側はどう処置したのでしょう？
>オーバーした時点のファイルがそのまま残るのであれば
>テーブルが見えなくなることはないと思います。
>
レンタルサポートに問い合わせたところ
「容量オーバーの際は監視プログラムにより書き込めない（更新）
状態になります。」
との回答でした。

が・・　同時に
「ログを調査、確認しておりましたがロックがかかった形跡
はございませんでしたので別の原因が考えられます」
との回答も頂きました。

この回答の前に・・
「考えられます原因としてデータベース容量がご契約容量に達したため、破損
した可能性が考えられます。」
と
「過去に容量オーバーでテーブル全てが消えてしまうという事例はございませ
んが起こりうる可能性は考えられます。」
との　回答を頂いてましたので、これが原因で　全てのテーブルが無くなった
ものだとばかり、思いこんでました。

容量オーバーが、原因で無いとすると・・考えられるのが
　PGSQLコマンドラインから、DROPTABLE　する。
　Apach実行ユーザー（ポストデータに何らかのDROPTABLE用のソースを埋め込
まれる、もしくはその様なコードが混じってしまう）
　の、２つしか思い浮かびません。
　それ以外に、原因となる様な要因が有れば、ご教授いただけませんでしょう
　か？

ちなみに、同じレンタル容量内で、作成しているＤＢ（My_DB_2）は、無傷の
ように見えます。
それから・・　運の悪いことに、apacheのアクセスログ、エラーログは、本日
の　17:00以前分が、取れなくなってしまっている状態です。

まずは・・
>> SELECT oid,datname FROM pg_database;
を見たところ
oid　　　　datname
4158520　　My_DB_2　（My_DB_1より、後に作成したＤＢ）
31858567　 My_DB_1　（今回　テーブルが無くなってしまったＤＢ）

となっており、oid が、先に作成したＤＢの方が、大きな数字になっているの
ですが、このようなことは　あり得るのでしょうか？


>>[pgsql-jp: 34945] Re: DROPDBした時の復旧
こちらも、全てが理解できたわけでは、無いと思いますが・・　汗
大変参考になりました。　

如何せん、レンタルサーバー内のことですので、実行権限の壁で　この作業を
完遂できないのでは、と判断して　別の角度で検証を続けています。