この現象は以前からよく報告されています。原因は、XREA の管理画面の記述がわかりにくいところにあると思います。XREA の管理画面には次のような記載があります。

この画面には「ページ入室の際はログ閲覧画面の認証パスワード(ユーザー名:*****,パスワード:****))をご利用下さい。」と書かれていますが、これは phpMyAdmin のログインパスワードでありません。次のような Basic 認証のダイアログボックスで入力する ID、パスワードのことです。

このダイアログボックスに入力するパスワードが、XREA の管理画面に書かれているパスワードです。phpMyAdmin にログインする際のパスワードは MySQL のパスワードですので異なります。特に管理画面から「自動」のリンクで飛んだときには Basic 認証のダイアログが飛ばされますので、わかりにくいと思います。

CentOS 5.x では、PHP 5.1.6 をベースにしています。手順としては Oracle Instant Client をインストールし、CentOS の PHP の SRPM をダウンロードし、SPEC ファイルを編集し、ビルドという手順になります。

Oracle Instant Client の インストール

Oracle Instant Client 10.2.0.4 の RPM をダウンロードします。ダウンロードには OTN の登録が必要です。ここでは Linux x86版(32bit版)の 10.2.0.4 の RPM をダウンロードします。最低限、oracle-instantclient-basic と oracle-instantclient-devel のパッケージはインストールが必要です。jdbc ドライバは不要です。

次に /etc/ld.so.conf.d/oracle-instant-client.conf というファイルを作成し、ライブラリパスを追加します。

# echo '/usr/lib/oracle/10.2.0.4/client/lib/' >> /etc/ld.so.conf.d/oracle-instant-client.conf

64bit 版の場合は次のようになります。

# echo '/usr/lib/oracle/10.2.0.4/client64/lib/' >> /etc/ld.so.conf.d/oracle-instant-client.conf

ライブラリパスを再読込します。

# ldconfig

いまは PHP をビルドするのが目的なので、Oracle データベースへの接続確認は割愛します。

PHP の SRPM のダウンロード

なぜか yumdownloader コマンドではうまく行かなかったので、理化学研究所のミラーから直接ダウンロードしました。

  wget http://ftp.riken.go.jp/Linux/centos/5.4/os/SRPMS/php-5.1.6-23.2.el5_3.src.rpm

この RPM をインストールすると、/usr/src/redhat/SPECS/ に php.spec ファイルが置かれます。また、/usr/src/redhat/SOURCES/ 配下にビルドに必要な PHP のソースファイルと、各種パッチファイルや設定ファイルなどが置かれます。

パッチファイルのダウンロード

php-5.1.6-oci8conf.patch をダウンロードして SOURCES ディレクトリに配置してください。Oracle が提供する SRPM や、他のパッチを元に、私が作ったものです。

SPEC ファイルの編集

こちらも、oci8 のために変更が必要です。変更箇所が多いので、php.spec (php-5.1.6.23.2.el5_3 用 32bit)に置きました。これをダウンロードして php.spec と差し替えてください。変更点は diff を取ればわかると思います。64bit 環境では、ライブラリパスを /usr/lib/oracle/%{ociver}/client/lib から /usr/lib/oracle/%{ociver}/client64/lib に変更する必要があります。

RPM のビルド

  $ rpmbuild -ba php.spec --target i686  --define 'oracle 1'

開発ライブラリなどがないと、コンパイルエラーとなります。事前に php.spec の BuildRequires セクションに書かれている RPM 群を yum コマンドでインストールしておきましょう。bzip2-devel, curl-devel, libstdc++-devel などです。

  # yum install bzip2-devel curl-devel libstdc++-devel

ビルドにはかなり時間がかかります。RPM ファイルは上記の例では /usr/src/redhat/RPMS/i686/ に配置されます。 php-oci8-5.1.6-23.2.ora.i686.rpm というファイルが PHP の OCI8 関数のモジュールを含んだ RPM です。 このモジュールを含む PHP の RPM をインストールしたら Apache を再起動します。phpinfo() コマンドで oci8 パッケージが有効になっていることを確認してみてください。

SQL> set timing on

これで SQL を実行すれば、最後に経過時間が表示されます。

SQL> select table_name from user_tables; //計測したいSQL
～(略)～
135行が選択されました

経過: 00:00:03.06

ただし、ここでの経過時間は結果の表示時間も含んでますので、実際の実行時間だけを求めたい場合は、事前に set autotrace traceonly statistics として、結果の表示を抑制した方がよいでしょう。このコマンドは set autotrace trace stat と略せますので、まとめると次のようになります。

SQL> set timing on
SQL> set autotrace trace stat
SQL> select table_name from user_tables; //計測したいSQL
135行が選択されました

経過: 00:00:03.06
統計 ～(略)～

C# のプログラムで OeDB で “DB_E_BADORDINAL(0×80040E55)” のエラーが発生。調べるたところパラメータードクエリで、必要以上のパラメータを add していました。

反対にパラメータが不足しているときは “DB_E_PARAMNOTOPTIONAL(0×80040E10)” が出ます。

条件によってパラメータ数が変わるクエリを投げているときなどは気をつけましょう。

１. PLAN_TABLE 表を作成

初回のみこの作業が必要になります。SQL*Plus でDBに接続し utlxplan.sql ファイルを実行します。

  SQL> @%ORACLE_HOME%\rdbms\admin\utlxplan.sql

Oracle クライアントのインストールオプションによっては、このファイルは存在しないかもしれません。管理者インストールならおそらく入っていると思います。utlxplan.sql 既に PLAN_TABLE が作成されていればこの作業は不要です。

2. EXPLAIN PLAN FOR SELECT ～ で実行計画を取得

実行計画を調べたい問い合わせ文の SQL に “EXPLAIN PLAN FOR ” を付加して実行します。

  SQL> EXPLAIN PLAN FOR SELECT * FROM employee WHERE id = 100;
  解析されました。

３.取得した実行計画を表示

utlxpls.sql ファイルを実行します。

  SQL> @%ORACLE_HOME%\rdbms\admin\utlxpls.sql
  PLAN_TABLE_OUT_PUT
  | TABLE ACCESS BY INDEX ROWID | employee    |   1 |  27 |
  |  INDEX UNIQUE SCAN          | pk_employee |   1 |     |
  

この結果で、INDEX UNIQUE SCAN があれば、問い合わせにはユニークスキャンが行なわれ1行取得していることがわかります。

  PLAN_TABLE_OUT_PUT
  | TABLE ACCESS FULL     | employee   |     |     |
  

上記のように表示されるときは、インデックスは使われていないことが分かります。

実行計画の削除

取得した実行計画の解析結果が不要になったら、PLAN_TABLE を切り捨てておきます。

  SQL> TRUNCATE TABLE plan_table;

定期的にシャットダウンできないような状態で運用しているオラクルサーバは、共有プールのメモリ断片化 によりパフォーマンスが低下することがあります。そのような場合、Oracle を再起動しなくても、次の方法で 共有プールのキャッシュをクリアできます。

  ALTER SYSTEM FLUSH SHARED_POOL;

共有プールからすべてのデータをクリアします。 共有プールにはデータディクショナリのキャッシュ情報や、SQL文、パッケージ、実行計画などが格納されています。

ただし、コマンド実行後は、実行中の SQL の再解析が実行されて一時的に遅くなる可能性があります。また、シーケンスオブジェクトのキャッシュもクリアされるので欠番が発生します。

データベース・バッファ・キャッシュのクリア

Oracle 9i では使えません。Oracle 10g 以降でのみ利用できる方法です。性能検証の際にバッファ・キャッシュに格納されたデータブロックを追い出すためにいちいち再起動する必要がなくなりました。

  ALTER SYSTEM FLUSH BUFFER_CACHE ;

すべてのバッファ・キャッシュがクリアされます。気をつけなければいけないのは、同一インスタンス上で実行中の全てのSQLに影響します。パフォーマンス測定などの開発・テスト環境でのみ使用しましょう。

SYSDBA 権限で実行します。

オラクルの停止

サーバのコマンドプロンプトで、SYS 権限のユーザで SQLPLUS に入ります。

  C:\> SQLPLUS "SYS/*** AS SYSDBA"

*** はパスワードです。「～に接続されました。」と出ます。次にシャットダウンを実行します。

  SQL> shutdown immediate
  ORACLEインスタンスがシャットダウンされました。

immediate を指定したときは接続中のセッションを全て切断します。トランザクションは全てロールバックされます。transactional を指定すると、トランザクション終了後にすべてのセッションを切断して再起動します。すべてのセッションが切断されるのを待ってから DB を終了したい場合は、normal を指定します。

ここで、正常にシャットダウンしない場合、次のように強制終了することもできます。

SQL> shutdown abort
ORACLEインスタンスがシャットダウンされました。

abort を指定した場合は、実行中のトランザクションはロールバックされない状態で切断されます。一応、次回起動時にクラッシュリカバリが自動的に実行されてロールフォワード／ロールバックされるので、データの整合性は保たれるということですが、場合によっては整合性が失われないとも限りません。やはり最後の手段です。自己責任でお願いいたします。

オラクルの起動

次は起動です。Oralce の起動は「停止」→NOMOUNT → MOUNT → OPEN の４段階の状態があります。通常は startupコマンドで、停止から OPEN 状態に一気に移行できます。

  SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 1134311410 bytes
Fixed Size                   458148 bytes
Variable Size             379258410 bytes
Database Buffers         2358411072 bytes
Redo Buffers               36955800 bytes
データベースがマウントされました。
データベースがオープンされました。

（上記の数値は環境によって異なります。また、適当な値に書き換えています。）

ここで、データベースを作成したり、起動時にメンテナンスを実施する必要がある場合は、マウントせずに起動することもできます。

 SQL> starup nomount;

この場合は、alter database で、手作業でマウントします。

  SQL> alter database mount;
  データベースが変更されました。

この状態ではまだマウントされただけでオープンされていません。オープンするには、次のように実行します。

  SQL> alter database open;
  データベースが変更されました。

データベースを読み取り専用モードでオープンしたい場合は、read only 句を付けて open します。

  SQL> alter database open read only;
  データベースが変更されました。

  SELECT file_name, regexp_replace(file_name, '(^.*_)([0-9]+)(U_.*$)', '\\2') FROM table_name WHERE file_name ~ '(^.*_)([0-9]+)(U_.*$)';

file_name               | regexp_replace
------------------------+----------------
hoge_030914U_A01.jpg    | 030914
foo_bar_152528U_B03.jpg | 152528
test123_4317U_X_YZ.png  | 4317

こんな感じで正規表現の一部を利用した表示ができます。\1, \2, ……は、正規表現中の ( ) にマッチした内容です。バックスラッシュを表わすために、SQL 中ではさらに \ を加えて、\\1,\\2, ……のようになります。UPDATE 文でも利用できます。

 SELECT * FROM pg_database_size('dbname');

ORA-00911: invalid character in hogehoge.php on line X

しかし、SQL には誤りはなく sqlplus で実行できますし、しばらく時間が経過すると、Apache + PHP 上でもエラーかでなくなります。PHP のコード中では

putenv("NLS_LANG=Japanese_Japan.UTF8");

として、NLS_LANGの値を設定していますが、どうもこの設定が反映されないようです。いろいろ調べると、apache の起動スクリプト中で環境変数を設定すればよいということでした。

/etc/rc.d/init.d/httpd を直接編集しても良いのですが、Red Hat 系(Fedora や CentOS) では、それは避けた方が良さそうです。起動スクリプト中では /etc/sysconfig/httpd がユーザが編集するファイルとして読み込まれ、実行されますので、こちらに記述します。

# vi  /etc/sysconfig/httpd

export NLS_LANG=Japanese_Japan.UTF8

これで Apache を再起動後すれば、起動直後でも NLS_LANG の値が有効になっており、エラーは発生しなくなりました。

買収したのが Oracle でなくてよかったと思いますが、Sun は過去に Cobalt を買収して失敗したりしているので、今回もそのようなことにならないか心配です。あと MySQL には Intel、SAP、Red Hat などが投資していましたが、今後の関係がどうなるのか興味深いところ。

また「Sun」という色が付くことで嫌がる OSS 支持者が、PostgreSQL や Firebird に流れることも予想されますね。LAMP から LAPP への流れが加速するかもしれません。

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 33554432 bytes!
[ERROR] Can't init databases
[ERROR] Aborting

InnoDB のログファイルのデフォルトは 5M ですが、これを 32M ほどに設定し直したところ、ファイルサイズが設定と違うという理由でエラーとなっているようです。自動的に再作成はしてくれないようですので、ログファイルを削除してから MySQL を起動すれば大丈夫でした。

対処しようにもコンソールからもなかなかログインできず、手こずりました。top 込まんとでは mysql が仮想メモリの 80% 以上を使っていたので間違いなく MySQL が何らかの理由で仮想メモリを食いつぶしたのだと思います。スワップしまくりでした。

mysqld を停止して（Timeout で失敗しましたが）、swapoff -a としてスワップ領域も開放しました。

原因は調査中なのですが特に DoS ということはなさそうなので、先頃リリースされた MySQL のアップデート版 RPM をインストールしたせいではないかと考えています。が、どこかのスパムボットによる絨毯爆撃の可能性も考えられるため、とりあえず Apache のパラメータをいじって同時接続数を減らしたりはしてみました。単にメモリ不足なのかもしれませんが。どうなることやら。

  update temp_table set num = (select max(num) +1 from temp_table) where num=1;
  ERROR 1093 (HY000): You can't specify target table 'temp_table' for update in FROM clause

PostgreSQL や Oracle ではこのようなエラーは起きずに更新が完了します。対処方法としてはテンポラリテーブルを使うか MySQL をやめること。テンポラリテーブルも同一クエリ内では2回以上使えなかったりと制限があります。

MySQL はちょっと凝ったことをしようとすると途端にできなくなるので、本当に困ります。

データベースの作成

root ユーザで mysql のコンソールに入り、CREATE DATABASE コマンドを実行。

# mysql -u root
mysql> CREATE DATABASE db_name;

ユーザの作成

Oracle や PostgreSQL と異なり、CREATE USER 文ではなく GRANT 文で作成する。

mysql> GRANT ALL PRIVILEGES ON db_name.* TO user_name@localhost IDENTIFIED BY "*********";

データベースの一覧

mysql> SHOW DATABASES;

データベースの選択

mysql コンソールに入ってから使うデータベースを指定したり、切り替える場合。

mysql> \u db_name;

テーブルの一覧

mysql> SHOW TABLES;

テーブルの詳細情報

mysql> DESC table_name;

データベースのダンプ

データベースの内容をファイルに出力

$ mysqldmp -u user_name -p db_name | gzip > db.dump.gz

データベースのリストア

$ zcat db.dump.gz | mysql -u user_name -p db_name

4.0.1 のときは phpPgAdmin のサイトから入手できるサードパーティ製 RPM を利用していましたが、4.1.1 では Fedora Extras の RPM を利用しました。そのためか、インストール先のディレクトリや設定ファイルの場所がかなり違うのでとまどいました。サーバは Cent OS 4 で試しました。

設定ファイルの場所の変更

4.0.1 までは /var/www/html/phpPgAdmin/conf/ ディレクトリに設定ファイルが配置されます。4.1.1 の RPM では /etc/phpPgAdmin/ に設置されるようになっており、Red Hat 系のお約束（設定ファイルを /etc/ に配置する）を守っています。/usr/share/phpPgAdmin/conf/ ディレクトリからはシンボリックリンクで設定ファイルにリンクされています。（ディレクトリのシンボリックリンクでないところがミソ）

これはセキュリティ上のメリットもあって、設定ファイルのバックアップを .old とか .php.bak とか、.~php のような拡張子で保存してしまうと、/var/www/html/phpPgAdmin/ 配下では閲覧できる状態になります。

しかし /etc/ に分離されていれば不用意にバックアップファイルを置いてもアクセス可能な状態にはなりません。バックアップファイルにはシンボリックリンクが張られていないためです。

phpPgAdmin のコンテンツの場所

4.0.1 以前は /var/www/html/phpPgAdmin/ に配置されていましたが、4.1.1 では /usr/share/phpPgAdmin/ に変更されています。古いディレクトリが残っていると動作がおかしくなることがあるので削除するか移動しておきましょう。

Apache 用の設定ファイルの追加

また関連して、Apache 用の設定ファイル /etc/httpd/conf.d/phpPgAdmin.conf が追加されています。ですので httpd.conf を編集する必要はありません。初期状態では 127.0.0.1 からのアクセスしか許可していませんので、設定を追加する必要があります。

Alias /phpPgAdmin /usr/share/phpPgAdmin

<Location /phpPgAdmin>
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
    Allow from 192.168.1.0/24 #追加
    Allow from ::1
</Location>

設定ファイルを保存して Apache の再起動（設定の再読込）をすれば、 http://ServerName/phpPgAdmin の URL でアクセス可能になります。

たとえば timestamp with time zone 型の last_access_time に最終アクセス日が格納されているとして、現在より1時間以内にアクセスしたデータを取り出すときは

  SELECT * FROM tablename WHERE now() - last_access_time < '01:00';

とすれば OK です。5分であれば、

  SELECT * FROM tablename WHERE now() - last_access_time < '5 minutes';

のような指定もできます。1週間であれば、

  SELECT * FROM tablename WHERE now() - last_access_time < '1 week';

のようにも指定できますし、 7 days にしても OK です。

これは各記事の「ピンを許可」のチェックの方が優先されるためですので、既存の記事へのトラックバックを拒否したいのであれば、過去の記事の「ピンを許可」のチェックを外す必要があります。記事数が多い場合はいちいち設定できませんので、MySQL にログインして、SQL で一括変換するのが良いと思います。

mysql> UPDATE wp_posts SET ping_status='closed';
Query OK, 52 rows affected (0.00 sec)
Rows matched: 50  Changed: 50  Warnings: 0

mysql> SELECT COUNT(ping_status), ping_status FROM wp_posts GROUP BY ping_status;
+--------------------+-------------+
| count(ping_status) | ping_status |
+--------------------+-------------+
|                 50 | closed      |
+--------------------+-------------+
1 row in set (0.00 sec)

元に戻すときは ‘closed’ の代わりに ‘open’ を指定します。コメントの場合は ping_status のところを comment_status にしましょう。コミットも忘れずに。

mysql> UPDATE wp_posts SET comment_status='closed';

別の方法もあるかもしれませんが、SQL を使える人ならばこういう方法を知っておけば色々応用が利くと思います。

当時のバージョンでは、Oracle Instant Client を使う場合、SPEC ファイルを書き換え、パッチを当てる必要がありましたが、この度リリースされた php-4.3.2-23.ent.src.rpm からは、パッチが取り込まれたのでその必要はなくなりました。素晴らしい!!

RHEL3 で試した限りでは、次のようにすれば OK でした。Oracle Instant Client パッケージのインストールが済んでいることが前提です。

パッケージのダウンロード

  # up2date --get-source php

RHEL で、RHN に加入しているのであれば、これだけでソースパッケージが /var/spool/up2date にダウンロードされます。クローンのディストリビューションの場合は、それぞれの FTP サーバなどから入手しましょう。

パッケージの再構築

基本的には --define 'oracle 1' をつけて再構築するだけです。たとえば、

  # rpmbuild --rebuild --target i686 --define 'oracle 1' php-4.3.2-23.ent.src.rpm

のようになります。できあがった RPM ファイルは /usr/src/redhat/RPMS/i686 の下にできます。これをインストールすれば、Oracle 関数も使えます。ほとんどの環境では、mbstring オプションも有効になっています。

パッケージの構築に当たっては、普段つかわないパッケージ群のインストールが必要になります。たとえば mysql とか unixODBC-devel などです。さらに要求されませんが、flex パッケージと sendmail が無い環境でパッケージを作ってしまうと、一部の関数が使えなくなってしまいますので注意しましょう。

肯定の時は

  カラム名 = TRUE
  カラム名 = FALSE

でよいのですが、否定の時は、

  カラム名 IS NOT TRUE
  カラム名 IS NOT FALSE

のようにしなければならないようです。 <> や != だと正しい結果になりませんでした。