>>700 フリーズってPC(OS)丸ごと? クライアントアプリだけ?
アクセスしようとしたクライアントはナニ?
postgres以外のアカウントだとどぉう?
っていうか、posgreってなんだよ。
>>699 別にPostgreSQLで困りはしないだろ。
>>699 どっちでもいいので、DBは統一しておいた方が楽。
特にこだわりがなければPostgreSQLでいいでしょう。
>>699 併用しても問題ないけど、管理の手間を考えたらposgres一本の方がいいよ。
キャッシュの割り当てとかも一括だし。運用に携わる人はpostgresもmysqlも
どっちもプロフェッショナルなの?両方混ぜると似たようなコマンドで混乱すると思うんだけど。
あとマスタとか共通利用できないの?できるんだったらマスタテーブル一個の方が
更新も楽だしいいと思うけど。ものすごい負荷の高いシステムで将来的に
DBをわける可能性が大きいなら、今からインスタンスを分けておく意味も
あるかもしれない。
もし分けるとしても同じDBMSのほうがよさげに思う。
同じシステムのPC版、携帯版という違いであれば同じDBMSにしといたほうがいいよ。
708 :
700:2008/06/16(月) 23:47:37 ID:???
>>701 DOSからアクセスしたのですが、passを入力してenter押すとOSごとフリーズしてしまいます。
>>708 ローカルマシンのPostgreSQLインスタンスにpsqlで接続しようとしたらOSごとフリーズってことですか?
710 :
699:2008/06/16(月) 23:56:17 ID:???
>>702、703、706、707
みなさん、ありがとうございます。
postgresで統一したいと思います。
PCと携帯で違うデータを見せたいのですが
マスタテーブルも一つにした方が良さそうですね・・・。
ありがとうございました。
統一にしても、DBクラスタを別にしてPostgreSQLを複数起動するとか、
DBを別にするとか、スキーマでわけるか、テーブルで分けるか、キーで分けるか、
712 :
700:2008/06/17(火) 17:27:59 ID:???
>>709 そうです、ネットで調べた通りにやったのですが無理でした。
>>712 まずメモリをチェックしなさい。
次にHDDをチェックしなさい。
Linux(Unix)ならこんな事で落ちない。
うんともすんとも言わない。メッセージが出ない。
保護違反とかのエラーは全てメモリエラーと思っていい。
メモリエラーの結果、誤動作して保護違反ということはあるかもしれないが
保護違反とメモリエラーとは直接の関係は無い。
保護違反じゃなくて、理由のわからないフリーズはハードを疑ったほうがいいけどな。
フリーズってのが全体が止まるのならな。
ハードだろうね。
保護違反ならメッセージ出るか再起動するかする
717 :
700:2008/06/18(水) 00:44:28 ID:???
ということは、自分のパソコンを修理に出すべきなんでしょうか?
普通に使っている分には、まずフリーズしないのですが・・・SP1入れようとするとフリーズしますが・・・。
ノートで熱暴走してるとか
ないか
アンチウィルスソフトで引っかかってUAEの警告だそうとしてるだけとか
ないか
pgAdminではつなげないの?
sp1入れてフリーズって普通じゃないよな。
pc新規購入をお勧めする。
PC買い替える前にOS再インストールだな。
の前にH/Wいろいろチェック
Explaining Explain日本語版ドラフト ? NPO法人 日本PostgreSQLユーザ会
http://www.postgresql.jp/blog/56 にある Explaining Explain の日本語版読んでみたいんですが、
パーマリンクの変更があった影響なのか
単にもうファイルがないのか読めないでおります。
どなたかファイル持ってる方いらっしゃればどこかにあげていただけないでしょうか?
JPUG公式ぽいんですが、コメントのSPAM荒れっぷりを見てもメンテされてない可能性があるので
こちらにきてみました。
コリコリにDBチューニングしたいわけではなくて、SQLかく時にある
ちょっとした迷い(結果同じだけどどっちの書き方がいいかな?)
をクリアする助けになればなぁと思ってる感じです。
726 :
724:2008/06/20(金) 12:59:02 ID:???
ぐぁ・・・基本的なことが抜けておりました。
大感謝です!
すみません
質問させて下さい。
PostgreSQL Ver 8.3
WindowsServer2003
でDBを運用しているのですが、
現在dataフォルダが初期インストールパスのままになっております。
別ドライブにdataフォルダを移動しようと試みて、
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.3\ImagePath
を変更してみたのですが、
変更先がCドライブ以下なら変更可
他のドライブは変更不可(サービスが起動しない)
となってしまいます。
この場合、dataフォルダを退避して、PostgreSQLの再インストール
しか方法は無いのでしょうか?
何とかdataフォルダの移動だけで済ませたいと考えております。
アドバイスを宜しくお願いします。
上げてみました
うちのWinXPでは実行ファイルはC:にインストールしてあって、
-Dで指定するデータ領域は別のドライブにしているけど、普通に動いてる。
>>729さん
ありがとうございます。
多分initdb.exeで -D 以降に移動させたいファイルパスを指定
してあげればいいのかなと思うのですが、initdb.exeの使い方が
いまいちわかりません・・・。
新規にデータ領域を作成して、そこに既存のdataフォルダをコピー
するような感じでいけるんでしょうか?
initdb.exeはコマンドプロンプトで実行するのでしょうか?
もしわかれば教えてください。
宜しくお願い致します。
既存のデータ領域があるなら丸ごとコピーして-Dでそっちを指すようにすれば動くんじゃないかな。
initdb はコマンドプロンプトで --help とかつけて動かせば説明が出るけど、
>>1のドキュメントを読んだ方が良いかも。
>>731 アドバイスありがとうございます。
取り合えず調べて、空の別ドライブのdataフォルダにinitdbの実行し
成功するまでは出来ました。
その後、新規dataフォルダを既存のdataフォルダに上書きして、
サービスの実行・・・・・・起動不可
再度、空のdataフォルダを作成して、initdbを実行。
今度はそのままサービスの起動・・・・・・起動不可
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.3\ImagePath
の値はinitdbの指定パスと同じにしているのですが、他に設定
が足らないのでしょうか?
>>732 コントロールパネル -> コンピュータの管理 -> サービス を開いて
PostgreSQLのプロパティを見て、[全般]タブの「実行ファイルパス」が
レジストリと同じ値になっているか確認して味噌。
っていうか、レジストリを直接弄るってはじめて知った。
scコマンドを使うものばかりだと...。
システムのログでも見れば。
735 :
NAME IS NULL:2008/06/29(日) 02:05:45 ID:Kc/12zlO
>>733 >>734 ありがとうございます。
>レジストリと同じ値になっているか確認して味噌。
ここは同じになっております。
多分、レジストリの値を参照して、ここに表示しているようですね。
>システムのログでも見れば。
今見てみました。
postgres cannot access the server configuration file "F:/data/postgresql.conf": No such file or directory
とのエラーメッセージを発見しましたが、該当の
F:\data\postgresql.confは存在します。
なぜでしょう?
>>735 元Unix系でWindowsに移植されると、あるのにNo such file... って出て悩ませるときがあるよねぇ。
ユーザpostgresに読み取りアクセス権限が設定されていないとか。
そんときゃpostgresql.confだけじゃなくて、/dateディレクトリ下の全てのファイルとディレクトリを
設定し直さなきゃだが?
psql (PostgreSQL) 8.2.4 を使ってますが、バックアップとリストアをしようとしています。
pg_dumpallでファイルにバックアップした後リストアすると文字化けが発生してしまいます。
登録データーがSJISなのですが、OSはUTF-8 CJKになってる為と思われますが文字化けを回避する方法はありますでしょうか。
また、上記状態でpg_dumpallしてあるファイルを文字化け無しにリストアする事は出来ないでしょうか。
宜しくおねがいします。
つ nkf
バックアップ前・後のDBの文字コードは同じ?
FTPとかを利用してファイル移動とかする際に
文字化けが入ってしまう可能性は無い?
使用しているOSは?
もうちょっと情報プリーズ
739 :
737:2008/06/29(日) 12:21:50 ID:???
>>738 早速のご回答、ありがとうございます。
バックアップ前・後のDBの文字コードは同じです。
postgresはfedora上で動いており、XPからwinSCPとputtyを使ってアクセスしてますが
バックアップしておいた時点のDBを再現したいので最悪はputtyでログインして
fedoraのディスクにそのままバックアップとリストアが出来れば良いです。
出来ればwinscpでローカルのXPにバックアップ出来れば嬉しいですが…
nkf、ググって見ました。pg_dumpallしてしまったファイルに適用しても元に戻せるのでしょうか。ちょっとやってみます。
>>738 >FTPとかを利用してファイル移動とかする際に
>文字化けが入ってしまう可能性は無い?
記憶が曖昧なのですが、fedora上でputtyでログインし
バックアップとリストアしても文字化けした様に思います。
× 記憶が曖昧なのですが、fedora上でputtyでログインし
○ 記憶が曖昧なのですが、fedoraにputtyでログインし
>> 737
そもそもDB作るときに文字コード何にした?
$ psql -U postgres -l
List of databases
Name | Owner | Encoding
------------------+-----------+----------
***** | ******** | UTF8
この一番右のEncodingの値
>>742 -bash-3.2$ psql -U postgres -l
List of databases
Name | Owner | Encoding
-----------+----------+-----------
postgres | postgres | UTF8
template0 | postgres | UTF8
template1 | postgres | UTF8
test | postgres | EUC_JP
test1 | postgres | SQL_ASCII
(5 rows)
となってます。test1が目的のDBなのでSQL_ASCIIで良いでしょうか。
>>743 テストしてみた
test1が元データだよな?
## 吸出し部分
# DB作成
createdb -U postgres -E SQL_ASCII test2
# test2にSJISデータを流し込む(手動)
# データ吸出し
pg_dump -U postgres test2 > test2.sql
# SJISからUTFに変更
cat test2.sql |nkf --ic=sjis -w > test2.sql.utf
# ここでFedora上で読めるようにUTFに変換されている
# winscpでwindowsに転送してみた
test2.sql => SJIS
test2.sql.utf => UTF8
の文字コードであることを確認
# 戻すテスト
createdb -U postgres -E SQL_ASCII test4
cat test2.sql.utf |nkf -s |psql -U postgres test4
これで無事に戻せた。
特に問題なさそうだが、何処でダメなんだ?
>>744 実験までして頂いてお手数掛けます。
>test1が元データだよな?
そうです。pg_dumpは部分的ににかバックアップしない様なので使ったことが無いのですが
pg_dumpall > backup.sql
とした時にbackup.sqlが既に壊れているのでは無いかと考えていて
今、実験中なのですが自信が無いです。
単純に
pg_dumpall > backup.sql
psql -f backup.sql
とした時に標準出力(linuxのUTF)で化ける事って無いのでしょうか。
backup.sqlはUTFに変換されてしまいますよね。
それとも、実験して頂いた手順に
># SJISからUTFに変更
とあるのでSJISのままなのでしょうか。
>>745 とりあえずbackup.sqlの文字コードを調べてみ。
こんなかんじで。
$ nkf --guess test2.sql
Shift_JIS
$ nkf --guess test2.sql.utf
UTF-8
ここまで書いて思ったんだが
test | postgres | EUC_JP
test1 | postgres | SQL_ASCII
ってことはEUC_JPのやつとSJISのデータを混ぜて出力してる?
>>746 やってみました
-bash-3.2$ nkf --guess backup.sql
BINARY
でした。
ちなみにbackup.sqlの先頭の方で
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET escape_string_warning = 'off';
| |
REVOKE ALL ON DATABASE template1 FROM PUBLIC;
REVOKE ALL ON DATABASE template1 FROM postgres;
GRANT ALL ON DATABASE template1 TO postgres;
DROP DATABASE test;
CREATE DATABASE test WITH TEMPLATE = template0 OWNER = postgres ENCODING = 'EUC_JP';
DROP DATABASE test1;
CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = postgres ENCODING = 'SQL_ASCII';
となっていてエラーも出ていない様なのですが、多種類の文字コードだと出力出来ないのでしょうか。
backup.sqlの容量が900Mバイトもある為かサーバの反応が遅すぎるので、テスト用のサーバーを買ってこようと思います。
>>747 >多種類の文字コードだと出力出来ないのでしょうか。
DBごとにdumpしてみたらどうなのさ? もうちょと自分で思考錯誤しる。
もしかして: 試行錯誤
750 :
737:2008/06/30(月) 07:50:38 ID:???
>>748 DB毎にdumpしてみましたが文字化けが発生している様でした。
別サーバーを立てて文字化け部分を切り出そうとしている所ですが
昨日の初書き込みから、お蔭様でだいぶ進展した感じです。
暫く自分でやって見てまた判らない事がありましたら質問させて頂きます。
本当にありがとうございました。
環境変数のPGCLIENTENCODINGとか?
DB毎に文字化けってどういうこと?
例えばEUC_JPで出したものをEUC_JPとして見ようとしても化けてるの?
文字化けしてると勘違いしてるだけじゃね?
DBをASCIIでつくっちゃったんならクライアントの
文字列をそのままバイト配列として格納してくれるんだっけ?
新しいDBをUTFで作ってプログラム組んでSELECT->INSERTしたほうが
早そうだけなあ
>>754 DBがUTF-8でシェルのLANGがUTF-8じゃないとかじゃないの?
繰り返しになるけど、
環境変数のPGCLIENTENCODINGとか?
PostgreSQLって基幹業務でも安心して使えますか?
>>756 管理者が詳しければ安心
管理者が詳しくなければどのRDBMS使っても安心できない。
DB本体はともかく、基幹業務となるとバックアップとレプリケーションかなぁ。
一番の問題はPostgreSQLを扱えるSIの質と数だろうけど。
1万ユーザーで同時使用は1000人くらいですが
パフォーマンス的には問題ないでしょうか?
使用状況や環境にもよるでしょ。
具体的なトランザクション数とまでは言わないけれど、一口に同時使用が
1000人といっても、それはフロント部分の作りに大きく依存するでそ。
それだけじゃなんとも言えない罠。ただ、今現在そのシステムがOracle等で
動いているのなら、パフォーマンス的にはPostgreSQLでも動くはず
というのはいえる。
>>755 ありがとうございます。
確認した所下記のようになっておりましたorz。
LANG=ja_JP.eucJP
PGCLIENTENCODING=EUC_JP
現時点でレンタルサーバの設定は触れないので、
自分で似たような環境を作り試してみた所、
UTFからEUCに変換できない文字(?など)があると現象が発生するような感じでした。
多分データベースがUTF-8なのに対し、PGCLIENTENCODINGがEUC_JPの為、
pg_dump時にEUC_JPにコンバートしてしまい、EUCに変換できない箇所でWarningが出ているのかなと思いました。
なおLANGは無関係そうな感じでした。
その為、PGCLIENTENCODINGの設定を変更してもらう方向で検討してみたいと思います。
どうもありがとうございました。
>>762の上から8行目は文字コード0xE28094のUTFの文字を貼り付けたのですが、文字化けしてしまいました。
多分pg_dumpでも同じようなことがおきてWARNING表示になったのだと思います。
>>762 自分の環境変数は自分で変えられるよ
export PGCLIENTENCODING=UTF-8
ってやってからpg_dumpしよう
連投ごめんです。
記憶違いでなければ、PGCLIENTENCODINGが設定されていない場合はLANGが使用されたと思うよ。
んで、ダンプファイルを突っ込むときにエンコード周りのエラーが出た場合なんだけど、
ダンプファイルの中の set client_encoding という行がある場合はそれが
優先されているので、そこがおかしくないかチェックしてみるとよいです。
>>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の記述をチェックしてみます。
どうもありがとうございました。
pg_dumpに-eって無かったっけ?
-E または, --encoding= でしょ、あるよ。
769 :
737:2008/07/02(水) 11:28:22 ID:???
>>751 今回は関係なかった様です。ありがとうございました。
>>752 EUC_JPのDBは化けてませんでした。
と言うか、SQL_ASCIIのDBを削除する為に仮に作っただけだったので、データーが殆ど入ってなかったと言うのもありますが。
追伸
SJISの文字化けで質問していた者です。他の業務が入ってしまい追試が遅くなりました。
色々やってみましたが、DBから携帯からのメールのみ削除してバックアップした所文字化けがなくなりました。
携帯の特殊文字に関連しているのかも知れません。とりあえずプログラマにその旨を伝え、対応してもらう事になりました。
時間が取れたらこちらでも詳しく調べようと思います。
ご教示頂いた皆様、本当にありがとうございました。
追伸2
4GのメモリとQuadのマザー買っちゃいました。素人が試行錯誤するには反応が早くて良いですね。
>>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のマニュアルは下記を参考にしました。
ttp://www.postgresql.jp/document/pg812doc/html/app-pgdump.html ttp://www.postgresql.jp/document/pg746doc/html/app-pgdump.html
テーブルに登録している「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
\が入っているフォルダパスを
検索する良い方法はないですか。
よろしくお願いします。
>>772 フロントエンド(psqlなりプログラミング言語なり)がエスケープする分とlikeがエスケープする分が必要。
folderPath like 'c:\\\\%'
c:\% がOKなのは、 c:\% → c:% → c:% だからだな。
775 :
NAME IS NULL:2008/07/04(金) 14:49:20 ID: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 を再コンパイルする必要があります。
phpinfoに出てこないんじゃ、そもそも無理でしょ。
PostgreSQLが使えるようにビルドしなおすか、
ビルドしたバイナリ持ってくるしかない。
777 :
776:2008/07/04(金) 15:49:51 ID:???
ちょっとググってみたけど、extension_dirは設定してる?
そして、extension_dir にちゃんと php_pgsql.dll は入ってる?
>>775 phpinfo();
でpgsqlのセクションが表示されなければ
たぶん、extensions_dirの設定ミス。
つか、Win32版のバイナリなら再コンパイルとか不要で、
ほとんどのオプションはphp.iniの設定変更のみで使用できる。
プライマリキーのフィールドってインデックス化されるんだったけ?
それとも別途CREATE INDEXしなくちゃいけないの?
他のDBとごっちゃになってきた
プライマリキーを設定するとユニークなインデックスを作成します。
つか設定したときメッセージ出るべ?
>>782 サンクス
メッセージはC#&Npgsqlで直接CREATE TABLE&CREATE INDEXしてたもので出なかったのよ
>>775 PATH設定してみては?
おれもそれっぽいのにぶつかったが、
>>777の内容はクリアできてても
phpinfoでは出てこんかった。
とりあえず、PostgreSQLのbinにPATH通したら出てきたよ。
>>779の中にも同じような対処法も書いてある。
(PostgreSQLかPHPのインストーラーでうまくやれよ…と思うんだけど)
textのフィールドを範囲検索かつあいまい検索できるのでしょうか?
仮にtextのフィールド名をmojiretuとして
データが
AAA0001
AAA0002
AAA0003
BBB0001
BBB0002
BBB0003
とあった場合
あいまい検索は
select * from testTable where mojiretu like '%0001'
範囲検索は
select * from testTable where mojiretu >= 'AAA0001' and mojiretu <= 'AAA0002'
これで
AAA0001
AAA0002
BBB0001
BBB0002
だけを引っ張るにはどういうSQL文になるのでしょうか?
or 使えよ
正規表現で
SELECT * FROM testTable WHERE mojiretu ~ '.*000[1-2]'
とか。
LIKEを「あいまい検索」ってのは初めて聞いた。
俺の知り合いにも完全一致じゃないのを「あいまい検索」って言うのがいる。
面倒だからいちいち突っ込まない。
>>789 部分一致をあいまい検索と呼ぶのは、そう呼ぶ客が少なからずいるから、気持ちはわからんでもないのだけど、
>>786の例だと後方一致なんだよなw
テーブル内容が同一の2つのDBがあるのですが、SQLコマンド
一発でDB1のデータをDB2と同一にするような方法はあるもの
でしょうか。
ご教示いただけますと幸いです。
LIKE あいまい検索 の検索結果 約 6,370 件中 1 - 10 件目 (0.20 秒)
>>792 ありません。
レプリケーションの機能は現在のPostgreSQLの弱点の一つです。
って同じにするだけならdumpしてrestoreすればいいけどな
>>788 postgres って正規表現一致使えたのか・・・
永らくそれっぽい検索とかに展開して激しく無駄なことしてたよ・・・
吊ってくる
>>787,788
試してみます、サンクス
>>789-791 お客さんには伝わりやすいのですが
このスレの先輩方のおかげで正式名称がわかりました
俺的にはあいまい検索って言ったら表記の揺れを考慮するやつ。
あいまい三センチ