postgresql データベースのリストア fsync=off で

postgresql 8.3 を本番業務で使っているが、幸いDBがクラッシュしてしまうということはまだない。

しかし、テストで現在のDBを別DBにコピーして実験する場合が多いので、その時は、pg_adminIIIのバックアップ・リストアを使う場合が多かった。

でも、本番業務では、Cronで定期的にpg_dumpして、本番サーバー上にバックアップを取っており、そいつを元に戻せないといけないわけで、ある時に、pg_dump そして　pg_restore をやってみたら。。。

リストアがめちゃくちゃ遅い！

DBの中に入っている2つくらいのテーブルに30万件くらいのデータが（合計60万件）入っているし、これからも増え続けるが、pg_dump した容量はplain で１６０MB位。

これだけの処理をpg_restoreしたら、延々2時間くらいはかかった。

これでは話にならないと思い、検索して調べたら

fsync = off (wal つまりログの先行書き込み）

にすると劇的に早くなるということ

そしてPostgresqlの公式マニュアルにもこれに関する記述があって、

以下引用 http://www.postgresql.jp/document/current/html/runtime-config-wal.html
--------------------------
この危険性のため、fsyncに対する普遍的に正しい設定は存在しません。常にfsyncを無効にする管理者がいる一方、何か不都合が発生した場合に明確な再起動ポイントが存在する様な時 は、初期の大量読み込みの際にのみ無効にする管理者もいます。さらに常にfsyncを有効にする管理 者もいます。デフォルトは、最大限の信頼性の確保のため、fsyncを有効にしてあります。もし使用 しているオペレーティングシステム、ハードウェア、電力会社（もしくはバッテリーバックアップ）を信頼するのであれば、fsyncを無効にすることを検討しても良いでしょう。
---------------------------

とある。

それでやってみたら。。。


なんと約3分弱くらいでリストア終了。

もちろんリストア前に　fsync = off でpostgresql 再起動、
リストア後に　fsync = on (というか設定行の前の＃を再び復活）　にすることを忘れない。


これで一安心です。

でもやっぱりこういう事に突き当たりながら経験は積むものなんだなと実感。

こういうことを経験しながらPostgresqlの性能を調べて良くと、うんうん　うまくできてるなって　うなることもしばしばです。

VS2008 DVD 自動再生せず DLACTRLW.exe が犯人

開発に必要でVisualStudio２００８（DVD)をインストールしようとしました。

すると自動再生がいかず、おまけにハングアップする始末。


いやここにきて、ThinkPadR60の光学ドライブの故障か～～～？　と凹みました
。

気を取り直して、他のメディアを入れたところ、問題なく動作。

ということは・・・・


とググりました。

ググる前に、マイコンピュータからCDドライブをダブルクリックして開こうとしても、ハングした状態に。

その時に応答しなかったプロセスが　DLACTRLW.EXE　なるものでした。

こいつが怪しい～～～と検索したら、やはり同じ現象に悩まされた方がいました。

とりあえず対策としては、　msconfig で　スタートアップから外し、マシンを再起動。


すると・・・・

全く問題なく自動再生ができました。


忘れないように書いときますし、他の方も同じように悩んでいる方もいるのではないかと思います。