データベース

latin1 で作ってしまったデータベースを phpMyAdmin で文字化けせずに export する方法

phpmyadmin_export.png
昨晩は EC-CUBEで構築された、とある EC サイトの移行作業であった。 フリーエンジニアの場合、夜中に作業出来ることを重宝されることがある。今回のような移行作業は特に。ようは、お買い物に来る人が少ない時間帯に移行作業をやってしまおうってやつだ。

昼間のうちに必要な情報はすべて集め、夜までは他の仕事をこなしつつ、約束していた移行作業の開始時間を待っていた。

「そういえば、MySQLのダンプを忘れていたなー。phpMyAdmin がインストールされているはず(今回の作業を引き受ける条件として、phpMyAdminがインストールされているサーバという話をしていたので)なんだけど、URLを聞くのを忘れていたなー」

ということでお客さんに電話した。

「えっと、管理画面とかそういうの無いんですよ。確認して折り返し電話します。」

という回答。嫌な予感。

MySQL で Got a packet bigger than 'max_allowed_packet' bytes エラーが発生した

Drupal で色々やってたらエラーが表示されるようになった。
どんなエラーかというと、 **Got a packet bigger than 'max_allowed_packet' bytes** というやつ。

Session データを書き込もうとしていたみたいなんだけど、MySQL があまり長い SQLを受け付けない設定になっていたみたいではじかれてた。

cron で VACUUM (vacuumdb と .pgpass)

先ほど EC-CUBEなサイトの夜間 VACUUM 設定が完了したのでメモ。

まずは、以下の感じで crontab に vacuumdb コマンドの実行を指定。この設定だと 4時0分にコマンドが起動される。

0 4 * * * /usr/bin/vacuumdb --analyze -U databaseuser databasename

crontab(1) コマンドは忘れた事無いけど、一応老後の為に書いておく。以下のようにする事で、username さんの権限で起動するコマンドが指定出来る(例えば、nologin なユーザの設定をしたいときに使う)。

% crontab -u username -e

ついでに中身だけ見るときは

% crontab -u username -l

関西オープンソース2004 で JPUGの手伝い

行って来ました。関西オープンソース2004。

COREBlog 作者の柴田さんにお声をかけていただいたので、JPUGのブースを手伝ってきました。正直言って PostgreSQL にあんまり詳しくなかったので(結構利用していたのですが、ぜんぜん情報収集してなかった)、私のようなものでも役にたつのか心配でした。まあ、なんとかなったんですが。

柴田さんにお会いしたのは今回がはじめてでした。メーリングリスト等でやり取りをさせていただいたことが何度かあったのですが、いざご本人を前にすると非常に緊張してしまいました。

東京からは、柴田さんのほかに、JPUGの片岡理事長も来られていました。温厚な方で、色々と親切に教えてくださいました。片岡さんにとって PostgreSQLは空気のような存在なのだそうです。

いろんな意味で、本当に楽しかったです。

PostgreSQL 対応 XOOPS2

PostgreSQL 対応の xoops2 が存在 する。

MySQL が必要だからという理由で xoops の導入をあきらめた人も多いはず。 私も MySQLを使っているものの、PostgreSQLのほうが安心して使えるため(MySQLが安心して使えないというのではなく、PostgreSQLに慣れているので安心して使えるという意味です。)、安定して使えることが判ればこちらのバージョンを積極的に使っていきたいと思う。

先ほどインストールしてみたが、今のところ問題なく動いているようだ。

SQLite の INSERT は遅いのか?

MySQLとSQLite(PrinCo.)という記事経由で、生まれ変わるPHP - Zend Engine 2、SQLiteの実力は?(MYCOM PC WEB)という記事を読んだ。 MySQL と SQLite で INSERT 時の処理速度が公開されている。 1000件のレコードのINSERTを実行し、それぞれにどれぐらいの時間がかかっているかを示しているのだ。 MySQLが 0.4秒、SQLite が 16秒だというのだが、これはあまりにもひどすぎる。しかも、結論としてどうやら大量データの連続挿入はSQLiteの不得意な処理のようだ。と書かれている。1000件程度でこんなにかかるんだったら、10000件だったら160秒ぐらいかかる(単純すぎ。)って事? 実はこれにはからくりがあって、SQLite の処理は トランザクション の中でないと著しく遅いのだ。おそらく、これが原因なのではないかと思っている。

SQLite での ロック

あるプロセスが データを書き換え中に、他のプロセスが書き換えできないようになっているようだ。

仕組みとしては、トランザクション中に、他のプロセスがトランザクションを開始しようとすると、SQLITE_BUSY ってのが返ってくる。 API の sqlite_busy_timeout() を使って、SQLITE_BUSY になるまでの時間をミリ秒で指定できる。

トランザクションの開始だけでなく、DELETE, INSERT, UPDATEなども出来ないようになっている。

SQLite での SEQUENCE

FAQ : How do I create an AUTOINCREMENT field. で説明されているように、フィールドを INTEGER PRIMARY KEYで定義しておき、INSERT でそのフィールドに null値を代入すると、自動的に SEQUENCE 値が代入される。

あと、SEQUENCE値として代入された数値を取り出す場合は、API sqlite_last_insert_rowid() を使用する。