dbサーバ(postgesql)とwebサーバ(apache)をos起動時に自動起動するよう無事設定したので、マシンの設定はほぼ完了。
そこで、dbサーバの引越し方法についてネットで調べたところ、pg_dumpなるとても便利なコマンドがあることがわかった。
このコマンドは、現在のDBの内容を検査し、まったく同じものを構築できるよう、sqlで記述させるコマンドだそうだ。
内容をsqlで記述するので、引越し先でそのsqlを実行すると同じものができあがるという寸法である。
これは便利だけど、旧のぼろPCだと相当に時間かかりそうな・・
ただ、やり方としては確実に思えたので、早速試してみることに。
旧サーバでpg_dump実行。
1時間経過、2時間経過、睡眠・・、8時間経過、・・出勤・・
株価は全銘柄数年分ためこんでいるので、やはり相当に時間がかかった。が、会社から帰宅して除いてみると、処理が終わっていた。
できあがったsqlのサイズを見てみると、200MB弱。思ったほどではないが、よくよく計算してみるとまぁ、こんなものか。
早速、旧PCで作成した引越し用のsqlをそのまま新PCからFTPでgetし、新PCでそのsqlを実行。
花火が散ったかのように画面がスクロールをはじめた。
あとで考えたら当然なのだが、実行の様子を画面に標準出力している。
これは時間のかかるプログラムだとさらに実行に足を引っ張りそうだと憂鬱に思っていたら、ほんの１、２分後だったろうか、画面にエラーメッセージがでて、その後、同じようなエラーが５、６回でたらコマンドプロンプトが戻ってきてしまった。
てっきり、異常終了したのかと思い、エラーメッセージを読むと、文字コードがUTF8ではないというようなエラー表示。
途中で不都合が発生したっぽいので、どこまでできたか確認するために新PCのDBの中をのぞいてみた。
驚いたことに、全銘柄の株価テーブルはこの短い時間で正常に出来上がっている！
エラーの表示が文字コードがらみなので、決算テーブルや取引市場テーブル、銘柄名テーブルなど、セル値に日本語が使われているテーブルを確認してみたところ、これらのテーブルのインポートができていないことがわかった。
エラーが５、６個出たのは、漢字を使っているテーブルへのインポートに失敗したときに表示されたエラーだったのだ。
fedora7に入っているpostgresqlのバージョンは、utf8でないとインポートできないのかどうなのかよくわからないが（そんなことはないと思うが・・）、windowsで編集しやすいように既存DBの文字コードをsjisにしていたのがいけなかったらしい。
ただ、既存PCのテーブルの日本語コードをutfに変換するのは、csvで吐き出してperlで処理し、再インポートすれば簡単にできる。また、今後を考えるとutfの方が互換性がありそうな気もするので、これを機に、日本語はutfで統一することに決めた。
それにしても新PCの威力恐るべし。
旧PCがぼろすぎるのかもしれないが、DBの計算性能はものすごく改善されそうである。
（cpuがP3-400Mhz→amd athlon64 3000Mhz×2へ
memoryが256MB→2000MBへ
osがrhat linux8→rhat fedora7 linux 64bit版へ)
全部インポートがうまくいったら処理性能比較のために新pcでpg_dumpを実行してみようと思う。
思ったよりはすんなりと株価DB引越しのめどもたったので次の週末あたりにでも完了させることにしよう。
