-- runser ... 掲示板

ID:749 に関連した投稿を表示しています。 他の投稿を表示したり、新しく書き込みする場合は[戻る]ボタンをクリックするか、掲示板に入りなおしてください。

データベースのアップグレード					ID: 749
日付	2004-11-08 03:50:51	名前	taro

週末、このサイトのバックエンドで動いてるデータベース（PostgreSQL）の アップグレード作業をしてました。 　データファイルに互換性がないのでいったんテキスト形式でバックアップ してから新版に流し込むのですが、新版では文字コードのチェックが厳しく なっていてそのままではリストアできない自体に。 　必要もないのに参照ページのRefererや、ブラウザの種類等のUserAgentを 記録していたのがまずかった。 　アタックもどきの不正コードはともかく、UserArentに絵文字を仕込んでいたり…。 　単に移行するだけならテキストベースで不正コードを排除、変換するだけで いけそうですけど、プログラム自体に不正文字コードのチェックを入れないと、 新版での運用はエラーが頻発しそうです。 　結局、プログラムの修正・改造を行なってからということで、アップグレードは 後回しに。

				コメント数 2

RE: データベースのアップグレード					ID: 819
日付	2006-03-22 20:16:20	名前	taro

前回のアップグレードは日本語コードの変換プログラムを作ってなんとか 対処しましたが、 　今回はデータベースPostgreSQLを7.4から8.1に上げました。 　ただし、このWebサーバはまだですが、先日テスト用のサーバでのことです。 　同じデータ／レコードを登録したのにファイル使用容量も少ないし、 パフォーマンス的にも速くなって順中に移行できたと思ってましたが。 　デフォルトでテーブルにOIDが含まれなくなったというのにはまりました。 （ファイルの使用量が少ないのはOIDがなくなったのも関係してそうです）。 　データとしてOIDは使っていないからなくなったところで問題はないのですが、 プログラムの中で新しく登録したレコードを調べるのにOIDを使っていました。 　INSERTしたら結果としてOIDが返ってくるのだから、普通はこれを使うよな。 　今後はシーケンス型を使ってCURRVAL()やLASTVAL()関数を使えということ みたいです。 　INSERT後にOIDを調べるテーブルにはSERIAL型を必ず入れていたので、LASTVAL()で 対応できますが、すべてのプログラムを修正して動作確認するのがけっこう大変。 　結局、OID付でテーブルを作り直して当面はこれで対処して、暇をみては 修正していくつもりです。 　OIDは32ビットしかなく溢れる可能性があるから廃止したのはわかりますけど、 うちのデータベースで4億超えるようなデータはないよなぁ。 　ただ、毎日数千レコードは増えているし、SMARTとかCD/DVD管理にもデータベースを 使っているから、年何かしたら超える可能性はあります。

更新	2006-03-22 20:18:06	→ 03/22 データベースのアッ... ID:749 の返事		コメント数 1

RE: データベースのアップグレード					ID: 820
日付	2006-04-02 00:53:30	名前	taro

このWebサーバのPostgreSQLも8.1にアップグレードしました。 　前回は文字コードの問題で苦労しましたが、 OIDの問題はあらかじめ気がついていたのですんなりといきました。 　ついでにApacheとPHPもアップグレードしました。 　しばらくはちゃんと動くかどうか様子見です。 　作業は1時間程度かと思っていましたが、自動コンパイル・インストール用の スクリプトをとちってやり直しが入って2時間かかってしまいました。 　まぁ、止まったところで誰かに迷惑がかかるわけでもないのですが、 なんとなく深夜早朝の一番アクセスの少ない時間帯で作業しています。

		→ 04/02 RE: データベースの... ID:819 の返事