Firebird関連スレ3

**NAME IS NULL** · 2009/02/11(水) 10:10:31

前スレ
http://pc11.2ch.net/test/read.cgi/db/1135527179/

本家
http://www.firebirdsql.org/
http://firebird.sourceforge.net/

wiki
http://firebird.skr.jp/?FrontPage

**NAME IS NULL** · 2013/04/18(木) 19:16:47.97

30秒に１回トランザクションしても2108年持つね。

**NAME IS NULL** · 2013/04/18(木) 19:42:19.23

30秒に一回ってそんなのんきな

**NAME IS NULL** · 2013/04/18(木) 20:45:56.23

のんきなってそんなにしょっちゅうコミットだらけのシステム実用に何の？

**NAME IS NULL** · 2013/04/18(木) 23:55:22.89

トランザクションは更新の時だけやないやろ。

**NAME IS NULL** · 2013/04/19(金) 01:23:40.04

30秒に１回でコミットだらけなのか・・・・
皆さんとは感覚が違ってたみたいすみませんでした。

**NAME IS NULL** · 2013/04/19(金) 05:05:21.90

つうかそれに耐えられるハードならバックアップリストアなんてあっという間に終わるじゃろという話

**NAME IS NULL** · 2013/04/19(金) 05:07:13.13

>>489
え？更新しないのにID増えるわけないよね

**NAME IS NULL** · 2013/04/19(金) 05:25:17.79

>>490
平均の話してんのに感覚とか意味不明

**NAME IS NULL** · 2013/04/19(金) 09:12:41.82

普段もっと忙しいシステムばっかさわってるから
あなたが携わっているような30秒に一回のトランザクションも無いくらいが普通なんだって感覚がなかったってことです

**NAME IS NULL** · 2013/04/19(金) 10:30:45.27

そもそもそんな忙しいシステムにFirebird使おうとか考えないよねw

**NAME IS NULL** · 2013/04/19(金) 17:43:28.86

>>494
平均の意味分かってるよね？

**NAME IS NULL** · 2013/04/19(金) 17:45:39.84

しかも論点は何秒に１回とかそこじゃねーし

**NAME IS NULL** · 2013/04/19(金) 17:47:56.91

>>494
で、君のシステムだと何ヶ月ぐらい持ちそうなの？
それ言わないと話し始まんないジャン

**NAME IS NULL** · 2013/04/20(土) 15:56:29.21

>>498
答えないと話を進ませない人ですね

**NAME IS NULL** · 2013/04/20(土) 17:50:14.80

間違いと気づいたなら素直に謝りなよ
FBには瑕疵はないよ

**NAME IS NULL** · 2013/04/21(日) 01:49:32.38

ID出ないのをいいことにw

**NAME IS NULL** · 2013/04/21(日) 08:44:52.26

>484 のpdfなどを読んだが
トランザクションidは行ユニークじゃないか
1行に対して2Gトランザクションを超えるシステムは扱った事がない
とは言え有り得ないとまでは言えないか

**NAME IS NULL** · 2013/04/21(日) 18:10:57.58

事実上ありえないから

**NAME IS NULL** · 2013/04/22(月) 08:42:01.91

なんか2000年問題とか2038年問題みたいだなｗ
自分が生きてる間持てばいいっていう発想

**NAME IS NULL** · 2013/04/22(月) 09:18:17.90

>>504
ぜんぜん違うだろw アホかw

**NAME IS NULL** · 2013/04/22(月) 16:14:43.53

罵倒しないとレスれないのか？

**NAME IS NULL** · 2013/04/22(月) 16:43:10.50

起こる可能性のあることは、いつか実際に起こる。

**NAME IS NULL** · 2013/04/22(月) 21:07:24.43

バックアップリストアなしで2000年とかありえないから

**NAME IS NULL** · 2013/04/22(月) 21:08:56.71

>507
ハードよりソフトの方が寿命が長いとでも思ってんの？

**NAME IS NULL** · 2013/04/22(月) 21:09:48.53

もとい、ソフトよりハードの方が

**NAME IS NULL** · 2013/04/22(月) 21:31:05.04

postgresもだいぶ昔のバージョンはトランザクションidは32bit unsigned intの40億回有限だった。（今もだけど）
バージョンが7.2とかだったかな。
postgresトランザクションID周回でググってみるとよい。

それで問題が結構起きて今はオンラインのままvacuum走らせればそこら辺もメンテされるようになってる。

昔のpostgresでさえそうなのに今を生きるrdbmsとしてfirebirdでそんなにトランザクション発生させるなんて事実上有り得ないとか、
maxに達するまでダンプレストアがないなんて有り得ないとか言っちゃう人は
どんだけ狭い了見で生きてんのって話。

**NAME IS NULL** · 2013/04/23(火) 00:52:15.49

>>511
アホくさ

**NAME IS NULL** · 2013/04/23(火) 05:20:32.78

>>511
しかしそこまで非論理的な内容をよく堂々と発言できるな。
馬は草しか食わないんだから人間も草だけ食べるべきといってるのと同じだぞ

**NAME IS NULL** · 2013/04/23(火) 05:23:10.83

>>511
ちなみに「firebirdでそんなにトランザクション発生させるなんて事実上有り得ない」というのは
どっかのバカの発言だから。
FBは十分大規模システムにも耐えられるよ。

**NAME IS NULL** · 2013/04/23(火) 07:22:07.74

>>514
いや、ヘレン女史も同じこと言ってたよ。

**NAME IS NULL** · 2013/04/23(火) 07:50:38.87

たくそんなに無駄な心配ばっかしてるから禿げるんだよ

**NAME IS NULL** · 2013/04/23(火) 08:38:10.87

まぁ仕事の引継ぎとか考えると留意すべき点ではあるね
つか64bit版のFirebirdならそこも直ってそうなもんだけど

**NAME IS NULL** · 2013/04/23(火) 08:42:43.39

留意する必要もないし直す必要がないものが直るわけないだろ。
単純に考えてもレコード数×フィールド数×数バイト×etc でDB容量増加なんて基地外沙汰だわ

**NAME IS NULL** · 2013/04/23(火) 08:46:35.51

君は何の話をしているのだ？

**NAME IS NULL** · 2013/04/23(火) 08:56:16.68

自分に必要無いから必要ないんだ！！！！(ﾌﾟﾝﾌﾟﾝ

**NAME IS NULL** · 2013/04/23(火) 09:08:31.45

>>513
同じmvccを採用するpostgresを例に出して、
今よりずっと昔のネット上のトラフィックが少ない時に、すでに経験してきていることをfireirdだから経験しないなんて理屈はあり得ないって言っているだけだが何処が非論理的？
論理的に指摘してくれませんか？
firebirdのアーキテクチャを理解しないで適当にもの言ってる奴らばっかだな

**NAME IS NULL** · 2013/04/23(火) 10:00:10.02

バカだね。この世の全てのリソースは有限なのに。

**NAME IS NULL** · 2013/04/23(火) 10:08:14.87

>>521
アーキテクチャ理解してないの自分じゃね?
出来ない物は出来ないんだから、Firebirdの仕様の中でやれることを考えるだけじゃん?

一体誰に何を求めてんのよ。

**NAME IS NULL** · 2013/04/23(火) 10:14:18.97

あと FB3.0になると制限が40億超になるけど、制限があることは変わんないから
とっとと見限ってFBの存在なんか忘れたほうがいいよ。

**NAME IS NULL** · 2013/04/23(火) 10:29:55.92

>>523
はぁ？
俺は別に誰に何を求めてるわけでもないし、理解して問題なく使ってますが。
>>482でもないが、
>>485とか>>503とか目に余るレスを見つけて口挟んだだけ。
誰と勘違いしてんの？

あとついでに言うと>>502の理解もおかしいから。
自分が使ってって問題なければいいってならそれでいいけど、
パブリックの場だから一応間違った情報には注意しないと。

**NAME IS NULL** · 2013/04/23(火) 10:31:07.58

>>525
じゃあ誰と何の議論してんの? 全く無意味な空理空論吐いてるようにしか見えないけど。
あとID出して。

**NAME IS NULL** · 2013/04/23(火) 10:33:15.71

てか>>511=>>521何だろ?
その他の人間と同一視なんかしてないわけだが。

**NAME IS NULL** · 2013/04/23(火) 10:43:27.49

にぎわってんな。

**NAME IS NULL** · 2013/04/23(火) 10:45:25.56

同じ奴がID出ないのいいことに他人のふりして書き込んでるだけだと思うよw
このスレにそんなにROMがいたわけがない。

**NAME IS NULL** · 2013/04/23(火) 10:56:34.20

>>527
誰に言ってるのかも、レスした理由も書いたじゃん。
もうメンドイから黙っとくわ。

**NAME IS NULL** · 2013/04/23(火) 12:51:31.64

Firebirdの仕様がゴミだってのはみんなわかって使ってると思うよ
ただ納品後にDB変えるのは手間だから仕方なく使ってる
仕様に満足してるふりするのは他のDBと仕様を比較せずに使っちゃったせっかちさんだけ

**NAME IS NULL** · 2013/04/23(火) 14:12:31.63

>>525
他の解釈だと最大2G行しか保持できないだろ

**NAME IS NULL** · 2013/04/23(火) 14:23:04.40

海の水はどうしてですか？

**NAME IS NULL** · 2013/04/23(火) 18:43:01.69

>>525
ほんとお前バカだな。いいかお前に分かりやすいように説明してやる。
仮にお前の心配してたこと（以下「心配事」という）が数千年後に現実化したとしよう。
そのときおまえの後任者がやることは、クライアントからのエラー報告に対して
「データに更新処理をかけるか前のリストアを戻してください」
というエラー時の通常対応（以下「通常対応」という）をするだけだ。
次に、その前提となる「心配事」について検討しよう。
ここでクライアントについて「通常対応」が必要になった場合は
その「通常対応」がなされたときからさらに数千年は「心配事」が発生しないことになる。
なぜなら「通常対応」により「心配事」の種はリセットされるからである。
つまり、「心配事」が発生する条件は、数千年「通常対応」が起こらないということなのである。
そして、エントロピー増大の法則により有体物は必ず壊れるからこの条件が成就する確立は
限りなく０に近いのである。

**NAME IS NULL** · 2013/04/23(火) 20:31:15.97

第三に、仮に１つのレコードに数億回の更新がかかり「心配事」が１年ほどで現実化したとしよう。
そのような異常な使われ方をしたＨＤＤが正常でいられる可能性は著しく低いといわざるを得ない。
すなわち、そのような特殊環境ではＨＤＤが壊れる前に「通常対応」が必要な確率は逆にかなり高いのである。

**NAME IS NULL** · 2013/04/24(水) 06:53:46.98

第四に、やはり仮に１つのレコードに数億回の更新がかかり「心配事」が１年ほどで現実化するシステムが
あるとすると、そのような過酷な使われ方に耐えられるハードは相当高性能であり、
「通常対応」も数秒、数分で終わるだろう。
つまり、そのような優秀なハードがそろっているなら、１日１回定期定期的に「通常対応」をしても弊害が
生じないのである。

**NAME IS NULL** · 2013/04/24(水) 07:32:45.58

「仮に１つのレコードに数億回の更新」って、トランザクションIDの意味解っている?

**NAME IS NULL** · 2013/04/24(水) 07:51:59.39

>>537
大意を把握できないなら黙っててください

**NAME IS NULL** · 2013/04/24(水) 07:55:38.98

ここでも馬鹿がフルボッコにされてんな
ttp://tech.dir.groups.yahoo.com/group/firebird-support/message/112108

**NAME IS NULL** · 2013/04/24(水) 07:57:14.44

>>537
逆にお前がKarol BieniaszewskiみたいにトランザクションIDを誤解してるに１ペリカ

**NAME IS NULL** · 2013/04/24(水) 08:41:07.22

>>534
525じゃなくて悪いけど
・リストアをクライアントに任せられる恵まれた環境が前提の話
・数億回の更新が異常な使われ方という認識
みんながみんなに当てはまらないんじゃない？

**NAME IS NULL** · 2013/04/24(水) 09:29:10.65

>>541
そんなヘビーな環境一台でこなせるわけ無いじゃん。
だから普通はクラスタ化されてるわけで。。
で、クラスタ化されてればいくらでもメンテのタイミングは作れるわけで。

前提となる環境が空理空論。

**NAME IS NULL** · 2013/04/24(水) 10:00:38.79

>>539
ここに書いた人は一秒間に200トランザクションあるから四ヶ月で越えちゃうどうしようって言ってるけどな
秒間何十tps、何百tps何て今のサーバスペックじゃごく普通レベル、というか場合によっては少ない方だが…

**NAME IS NULL** · 2013/04/24(水) 10:26:42.66

>>543
何を根拠に普通って言ってるのかしらんけど
例えばTPC-Cで12000tpmcなんて環境は、なかなか縁のない環境だな。
I/O絡めてそんな数字出るハードもあんまり普通レベルとは言いがたいな。

**NAME IS NULL** · 2013/04/24(水) 10:38:30.85

何で二桁も飛んでるんだよw

**NAME IS NULL** · 2013/04/24(水) 10:47:56.11

tpc-bだけどこれ4年前の資料な
http://www.slideshare.net/tomneko/firebird25

**NAME IS NULL** · 2013/04/24(水) 10:55:40.88

>>546
TPC-Bでも200tpsに届いてないじゃんw

**NAME IS NULL** · 2013/04/24(水) 10:56:15.39

>>545
バカなのか

**NAME IS NULL** · 2013/04/24(水) 11:11:10.54

4年前のサーバスペックだぜ？
それに問題はtpcの指標じゃないし、別にtpc-bでもトランザクションであることには変わらない。
トランザクションの制限値に現実味があるかどうかだろ？
仮に秒間100だとしても248日後にはMAX到達。
まぁ認めたくないのはわかるがそろそろ無理があるぞお前。

**NAME IS NULL** · 2013/04/24(水) 11:23:05.11

>>549
4年前のサーバーが今現在稼働してるのは普通レベルじゃないのか?
しかも>>539は2011年のスレッドなわけだがw

で、CPU限界近くまでぶん回した上限値ギリギリでシステム設計するのが普通なのか?

つうかTPC-Bはアカンってお前の持ってきたスライドに書いてあるやん…

> まぁ認めたくないのはわかるがそろそろ無理があるぞお前。

お前がなw
レスの全てが突っ込みどころだらけじゃん。

あとID出せよw

**NAME IS NULL** · 2013/04/24(水) 11:24:55.37

で、件のスレッドでは
「お前のシステムはそもそもトランザクションが必要なのか? FB使うのがおかしくね?」
と問われてるわけで、当然俺もそう思う。

**NAME IS NULL** · 2013/04/24(水) 15:21:54.82

ところで「ワインに育毛効果！」って田崎真也に喧嘩売ってね？

**NAME IS NULL** · 2013/04/24(水) 18:08:33.37

>>551
な。ファイルにシリアルに書き込んでけばいいだけの話やんなｗ
ＤＢ屋ってバカだよなｗ

**NAME IS NULL** · 2013/04/24(水) 18:09:16.74

結論：心配性のバカはほっとけ

**NAME IS NULL** · 2013/04/25(木) 08:45:31.88

普通のプログラマなら自作テーブルで低機能・高速性を求めるか
DBエンジンで高機能・低速でいいかを最初に検討するはずだけどな。
何の考えもなしにDBエンジン使うとかエンジニアとしてのレベルが低いとしかいえん。

**NAME IS NULL** · 2013/04/26(金) 01:36:40.25

40億回でだめなら何回あればいいんだ
仕様､BUGがわかっていれば普通は回避策を考えるんだが
DB変えるとか

**NAME IS NULL** · 2013/04/26(金) 10:40:47.00

もう許してやれよ。涙目だぞ、そいつ

**NAME IS NULL** · 2013/04/26(金) 18:04:12.38

DBファイルだけで10TBとかそういう大規模なのだろう

**NAME IS NULL** · 2013/05/02(木) 11:59:20.03

>>556
Postgresならバキュームがあるから回数は1億でもいいと思うわ
問題は回数よりリセット方法が稚拙だってことだろうね

**NAME IS NULL** · 2013/05/02(木) 12:32:31.35

意図的なのかどうか知らんが論点がぶれてる
俺は、20億では少ないとか十分とか、Firefoxがいいとか悪いとか、運用の仕方の話じゃなくて、
異様に少ないコミット回数を前提にしてそんなトランザクション回数事実上有り得ないとか決めつけてたから、現実に十分あり得るし、以外と簡単に越えるんだよって一貫して言ってたんだけどな。

**NAME IS NULL** · 2013/05/02(木) 14:03:29.94

それは理解してるよ、あとFirefox関係ないだろｗ
で、現実的な解決策としてはPostgresのバキュームみたいなので
DB止めずにリセットできればいいねって
Accessとかだと最適化だったかな？最近触ってないから知らん
有り得ないとか決めつけてるやつは思考停止してるからほっとけよｗ

**NAME IS NULL** · 2013/05/02(木) 14:37:27.74

げ、自動補完でFirefoxになってた…
あと一行につき20億、じゃないし。仕組み理解してればdbにつき、てことくらいわかると思うが。

**NAME IS NULL** · 2013/05/02(木) 14:45:37.57

執念深いやつだなw
あんだけ論破されてもまだぐにゃぐにゃ言ってんのかw

**NAME IS NULL** · 2013/05/02(木) 14:47:18.01

>>560
てかお前は一体どいつだよw レス番書け。ID出せw

**NAME IS NULL** · 2013/05/03(金) 05:51:53.54

>>560
ＯＫ。じゃあ具体的に議論しようや。

＞異様に少ないコミット回数を前提にして
ではその前提をまず明らかにしてもらおうか。

＞現実に十分あり得るし、以外と簡単に越えるんだよ
ではその現実を明らかにしてもらおうか。

**NAME IS NULL** · 2013/05/03(金) 05:55:36.69

>>561
＞有り得ないとか決めつけてるやつは思考停止してるからほっとけよｗ
「事実上ありえもしないことを「ありえる！論理的にはありえる！」と騒いでる奴は思考停止どころか心配性で絶対頭禿げてるからほっとけよｗ」の間違いだよね

**NAME IS NULL** · 2013/05/03(金) 06:01:53.66

裁判では欠陥があると指摘する側に立証責任がある。
なのにここでFirefox?に欠陥があると騒いでる奴は、まるでその責任を果たしているとは思えない。
逆に欠陥はないという被告側に立証責任を負わせたうえ、しかも論破されてしまってるというのが現状。

**NAME IS NULL** · 2013/05/03(金) 06:11:16.59

しかも、原告側ではトランザクション開始さえすればトランザクションＩＤが増加するという誤った認識すらしている可能性が高い。
よって被告人は無罪。

**NAME IS NULL** · 2013/05/03(金) 07:14:33.07

Ann Harrison said,

Transactions that don't insert, update, or delete records are of no
interest to anyone once
they end. The long term value in transaction identifiers is only to
identify record versions.

**NAME IS NULL** · 2013/05/03(金) 18:38:02.33

問題あるある君の問題点

１　問題ない派は「2000年持つから大丈夫」ということを述べるために
　平均値を用いてるだけ（つまり何年持つかが重要であり平均値は
　その計算要素に過ぎない）のに「異様に少ないコミット回数を前提にして」と
　的外れなことを述べる。あるある君は自己の計算で何年持つのかを
　まったく明らかにせず、「持たない！持たない！」と騒ぐだけと思われても仕方がない。

２　あるある君はそもそもトランザクションIDがどのようなタイミングで
　増加していくのかをきちんと把握していない節がある。だからそもそも計算ができず、
　「異様に少ないコミット回数を前提にして」などと述べる。

３　あるある君は24/365ノンストップシステムを想定している節がある。
　しかし、そこで想定するそのようなシステムが本当にバックアップリストアをするタイ
　ミングがまったく必要ないものなのか謎が多すぎる。

４　あるある君はエラーなどがまったく発生しないシステムを想定している節がある。
　しかし、ハード的にもソフト的にもおよそ何らかの上限がないものなどないのだから
　いつかはバックアップリストアなどの更新処置（ガベージコレクション）が必要になるはず。
　仮にトランザクションＩＤが上限を超えてもそれと同様な処置すればいいだけなのに
　まるで特別な処置が必要かのような誤解をしているのではないか。
　「ガベコレ？面倒や！フリーメンテナンスにしろや！」とかいうならそもそもDBの知識が
　無いか何かを酷く誤解していると思われる。

**NAME IS NULL** · 2013/05/04(土) 18:11:13.19

いくら馬鹿なお前らでも期末更新プログラムみたいなものぐらいは作ってんだろｗｗ
そのプログラム実行時にトランザクションＩＤもリセットされるようにすればいいだけじゃんよｗｗｗ
まさかトランザクションＩＤのリセットのしかたすらも知らず騒いでたわけじゃあるまいｗｗ

**NAME IS NULL** · 2013/05/10(金) 14:52:24.01

トランザクションＩＤのリセットのしかたがDBを止めなきゃいけないのがだせー

**NAME IS NULL** · 2013/05/26(日) 15:18:39.07

なんだよこれ、MSaccessから使えないじゃん
糞ＤＢ
リンクテーブル作ろうとすると、オブジェクトが見つかりませんとかエラー出て使えねー

accessからODBCでエキスポートは出来たのに、逆ができない

**NAME IS NULL** · 2013/05/26(日) 16:26:34.13

馬鹿には無理

**NAME IS NULL** · 2013/05/26(日) 16:40:20.26

糞ＤＢだからだろ

**NAME IS NULL** · 2013/05/27(月) 10:04:36.62

馬鹿はよく吠えるな

**NAME IS NULL** · 2013/05/27(月) 20:02:35.54

馬鹿に限って自分の馬鹿さを隠そうとする

**NAME IS NULL** · 2013/05/28(火) 00:46:15.49

ユーザの程度が低いな～
アホに限って偉そうにしてるとか終わってますがな

**NAME IS NULL** · 2013/05/28(火) 09:15:28.57

最底辺のカスが何か語ってます

**NAME IS NULL** · 2013/05/30(木) 11:54:02.12

FB2.5を使ってます
BLOBのSEGMENT SIZEの意味がよくわかりません
wikiだと格納できる最大サイズはページサイズに依存とありますが具体的なことが書いてありません
デフォルトだとSEGMENT SIZE 80らしいのですがこれだと何バイトまではいるのでしょうか
ページサイズは8Kです

**NAME IS NULL** · 2013/05/30(木) 23:36:06.13

何バイトでも入るよ。何バイト単位で領域確保されるかが違うだけ。

と俺は理解しているが、間違ってたら識者の人が訂正してるれるだろう。

**325** · 2013/06/02(日) 19:27:37.03

>>581
どうもです
調べてもよくわからないのでとりあえず実験してみたら
デフォルトで必要なサイズは余裕で入るみたいなのでとりあえず疑問は棚上げします

**NAME IS NULL** · 2013/06/02(日) 19:28:39.95

う、また３２５が残ってる
前の書き込みで消してるのに何で復活してるんだ

**NAME IS NULL** · 2013/06/04(火) 09:31:18.12

なぜ

firebird blob limit

辺りででググってみようとはしないのか

**NAME IS NULL** · 2013/06/15(土) 15:58:38.85

D7でIBXでfirebirdに接続するとwindows7でtry exceptでゼロ除算エラーが捕まえられなくなるんだけど
同様の体験した人いる?
同じexeファイルでXpだと例外になるんだけど7だと例外にならずに除算の結果が-NANになる
windows7だとfirebirdに接続する前と後でGet8087cwで帰ってくる値が変わってるし