08/07/01 16:30:12
1万ユーザーで同時使用は1000人くらいですが
パフォーマンス的には問題ないでしょうか？
760:NAME IS NULL
08/07/01 16:37:14
使用状況や環境にもよるでしょ。
761:NAME IS NULL
08/07/01 16:43:03
具体的なトランザクション数とまでは言わないけれど、一口に同時使用が
1000人といっても、それはフロント部分の作りに大きく依存するでそ。
それだけじゃなんとも言えない罠。ただ、今現在そのシステムがOracle等で
動いているのなら、パフォーマンス的にはPostgreSQLでも動くはず
というのはいえる。
762:NAME IS NULL
08/07/01 23:30:29
>>755
ありがとうございます。
確認した所下記のようになっておりましたorz。
LANG=ja_JP.eucJP
PGCLIENTENCODING=EUC_JP
現時点でレンタルサーバの設定は触れないので、
自分で似たような環境を作り試してみた所、
UTFからEUCに変換できない文字(?など)があると現象が発生するような感じでした。
多分データベースがUTF-8なのに対し、PGCLIENTENCODINGがEUC_JPの為、
pg_dump時にEUC_JPにコンバートしてしまい、EUCに変換できない箇所でWarningが出ているのかなと思いました。
なおLANGは無関係そうな感じでした。
その為、PGCLIENTENCODINGの設定を変更してもらう方向で検討してみたいと思います。
どうもありがとうございました。
763:NAME IS NULL
08/07/01 23:34:10
>>762の上から8行目は文字コード0xE28094のUTFの文字を貼り付けたのですが、文字化けしてしまいました。
多分pg_dumpでも同じようなことがおきてWARNING表示になったのだと思います。
764:NAME IS NULL
08/07/01 23:53:51
>>762
自分の環境変数は自分で変えられるよ
export PGCLIENTENCODING=UTF-8
ってやってからpg_dumpしよう
765:NAME IS NULL
08/07/01 23:58:16
連投ごめんです。
記憶違いでなければ、PGCLIENTENCODINGが設定されていない場合はLANGが使用されたと思うよ。
んで、ダンプファイルを突っ込むときにエンコード周りのエラーが出た場合なんだけど、
ダンプファイルの中の set client_encoding という行がある場合はそれが
優先されているので、そこがおかしくないかチェックしてみるとよいです。
766:NAME IS NULL
08/07/02 00:15:01
>>764
レスどうもです。
一応自分で構築したサーバーで>>764の記述と
export PGCLIENTENCODING=EUC_JP
でのpg_dumpの出力結果を元に>>762のような感じかなと推測しました。
実際に使用しているレンタルサーバーの方は、
自分の判断だけでは手がつけられないため、試してないですが。
>>765
私の構築したサーバーの設定は下記ですが、問題なかったのはLANGにUTF-8を指定してたからということですね。
LANG=ja_JP.UTF-8
PGCLIENTENCODINGはなし
危うく、PGCLIENTENCODINGの設定を無くすだけで終えるところでした。
データベースは複数ありますがどれもUTF-8なので、PGCLIENTENCODINGをUTF-8にする方向で対応したいと思います。
後、手元に問題のダンプデータがないので、明日Warningのでる場合と出ない場合のset client_encodingの記述をチェックしてみます。
どうもありがとうございました。
767:NAME IS NULL
08/07/02 09:25:32
pg_dumpに-eって無かったっけ？
768:NAME IS NULL
08/07/02 10:01:57
-E または, --encoding= でしょ、あるよ。
769:737
08/07/02 11:28:22
>>751
今回は関係なかった様です。ありがとうございました。
>>752
EUC_JPのＤＢは化けてませんでした。
と言うか、SQL_ASCIIのDBを削除する為に仮に作っただけだったので、データーが殆ど入ってなかったと言うのもありますが。
追伸
SJISの文字化けで質問していた者です。他の業務が入ってしまい追試が遅くなりました。
色々やってみましたが、ＤＢから携帯からのメールのみ削除してバックアップした所文字化けがなくなりました。
携帯の特殊文字に関連しているのかも知れません。とりあえずプログラマにその旨を伝え、対応してもらう事になりました。
時間が取れたらこちらでも詳しく調べようと思います。
ご教示頂いた皆様、本当にありがとうございました。
追伸２
４GのメモリとQuadのマザー買っちゃいました。素人が試行錯誤するには反応が早くて良いですね。
770:NAME IS NULL
08/07/02 21:56:28
>>765
set client_encodingチェックしました。
すべてのダンプがEUCでしたorz
どうもありがとうございました。
それと、私が試した限りではPGCLIENTENCODINGが設定されていない場合、
LANGではなく、データベースのEncodingが使用されているようでした。
その為、下記のaaaaというデータベースのダンプはEUC_JPで作られ、
bbbbというデータベースはUNICODEで作られていました。
List of databases
Name|Owner|Encoding
-----+-----+--------
aaaa |ccccc |EUC_JP
bbbb |ddddd |UNICODE
>>767、>>768
使用しているバージョンが7.4.19なのですが、このバージョンでは-Eと--encoding=はないようです
(pg_dump --helpで調べましたが、そのオプションは存在せず、試してみてもエラーになりました)。
出来れば既存の環境には手を加えたくないので、PGCLIENTENCODINGには手をつけず、
pg_dump -Eで対応できれば良かったのですが。
何か良い案があるようでしたらアドバイスいただければと思います。
今はまだPGCLIENTENCODINGを変更すると、既存の環境に悪影響が出ないか検証できていない為、
変更できていないので。
なおpg_dumpのマニュアルは下記を参考にしました。
URLﾘﾝｸ(www.postgresql.jp)
URLﾘﾝｸ(www.postgresql.jp)
771:NAME IS NULL
08/07/02 23:37:35
>>765
PGCLIENTENCODINGが設定されてない場合の補足ですが、
下記のサイトに以下の記載がありました。
> -E encoding
> --encoding=encoding
> 指定した文字セット符号化方式でダンプを作成します。デフォルトでは、ダンプはデータベースの符号化方式で作成されます
> （PGCLIENTENCODING環境変数を好みのダンプ時の符号化方式に設定することで、同じ結果を得ることができます）。
URLﾘﾝｸ(www.postgresql.jp)
この文章の「デフォルトでは、ダンプはデータベースの符号化方式で作成されます」というのが、
>>770のEncodingの部分を指していると思われます。
772:NAME IS NULL
08/07/03 02:08:24
テーブルに登録している「folderpath」を
SQLのWHERE句にて
Like検索したいのですが、
以下結果となりました。
1. folderPath = "c:\\test" OK （データ取得成功）参考
2. folderPath like "c:%" OK
3. folderPath like "c:\%" OK
4. folderPath like "c:\\%" NG （取得データ0件）
5. folderPath like "c:\t%" NG
6. folderPath like "c:\\t%" NG
\が入っているフォルダパスを
検索する良い方法はないですか。
よろしくお願いします。
773:NAME IS NULL
08/07/03 03:31:45
>>772
フロントエンド(psqlなりプログラミング言語なり)がエスケープする分とlikeがエスケープする分が必要。
folderPath like 'c:\\\\%'
774:NAME IS NULL
08/07/03 09:53:15
c:\% がOKなのは、 c:\% → c:% → c:% だからだな。
775:NAME IS NULL
08/07/04 14:49:20 gyCCSjbu
MYSQLからPostgreSQLに乗り換えたいと思いインストールしてみたんですが
phppgadminから起動が出来ません
環境は
apache2.2/PHP5/PostgreSQL8/WindowsXP
php.iniの php_pgsql.dllの部分の；は解除してますが
phpinfoにもPostgresが出てきません
インストールが失敗しているんでしょうか？
一応 ユーザーアカウントを新しくrootとして権限をかけて作りました
Linux環境のサイトが多くWindowsの情報が無く困ってます
Phppgadminのエラー詳細は
データベースをサポートするように
PHP のコンパイル・インストールがされていません。
configure の --with-pgsql
オプションを用いて PHP を再コンパイルする必要があります。
776:NAME IS NULL
08/07/04 15:43:53
phpinfoに出てこないんじゃ、そもそも無理でしょ。
PostgreSQLが使えるようにビルドしなおすか、
ビルドしたバイナリ持ってくるしかない。
777:776
08/07/04 15:49:51
ちょっとググってみたけど、extension_dirは設定してる？
そして、extension_dir にちゃんと php_pgsql.dll は入ってる？
778:NAME IS NULL
08/07/04 16:09:43
>>775
phpinfo();
でpgsqlのセクションが表示されなければ
たぶん、extensions_dirの設定ミス。
つか、Win32版のバイナリなら再コンパイルとか不要で、
ほとんどのオプションはphp.iniの設定変更のみで使用できる。
779:NAME IS NULL
08/07/04 18:49:06
>>775
Bug #44905 PHP 5.2.6 fails to load PostgreSQL related libraries
URLﾘﾝｸ(bugs.php.net)
これかな?