●DB2とオラクル、どっちがどういい？● [sc](★0)
-
- 1
- まちがえた。
- 2001/09/06 14:43
-
なんだかんだ言ってもやっぱオラクルの方が上ですか？
ＩＢＭにもがんばって欲しいんですけどねー。
-
- 114
- 2002/09/21 00:52
-
IBM DB2 UDBは、やたらとシェアードナッシング型のクラスタアーキテクチャを
採用していることを、やたらオラクルと比較した際の優位点だと押してるんだよな。
だけど、上位のメインフレーム版のDB2では、オラクルでも採用してるシェアード
ディスク型を採用してるんだわ。
そもそもDB2 UDBってAS/400とかで動いているDB2とは似て非なるもの。
UNIX上でシェアードディスクのクラスタを実装する技術力が無いってだけじゃん。
売り方が姑息だよ。
-
- 115
- 2002/09/21 04:33
-
>>112
何も突っ込まないでやるから、とりあえず勉強して来い
-
- 116
- 2002/09/21 04:41
-
>>114の解説をしよう。
IBMはメインフレームのすばらしいクラスタアーキテクチャを利用することでなんとか
AS/400版DB2ではシェアード・ディスクを構成できる。
しかし、所詮技術力のないIBM、UNIXやWindowsではシェアード・ディスクができません。
まあ、完全な行レベルロックも実装できないのにシェアード・ディスクができるわけないやな。
そのうちInfomixもInfomix UDBとかInfomix DB2とか命名するのかな。
（もうなってたりして）
売り方が姑息なのは昔からだな。
所詮営業力のIBM。
膨大なマンパワー利用して売り込みかけてシェアをせこせこのばしてるに過ぎない。
あわれかな、IBM。
-
- 117
- 2002/09/21 11:28
-
>116
そして見せかけの安さに負けて買った客は、開発で苦しみ、さらに
システム稼動後もトラブル対応できる技術者が確保できずにIBMの
ｳﾞｧｶ高いオンサイトサポートで貪られるって寸法だ。
しかも、研修ですら>113といった按配じゃあなぁ。
ロックのエスカレーションって、初めて聞いた時、「ﾊｧ?」
大規模システムには向いてないね。
-
- 118
- 2002/09/21 17:59
-
>>116
研究力はすごいんだけどねぇ。
Oracle や MS SQL Server など他社のデータベースも採用している理論や技術の
多くがIBMの研究所発祥のはず。
実用化の能力が弱いってことだろうか。
DB2 はもともとメインフレーム用製品だったのをWindowsやLinuxにも移植した
ものだそうだけど、メインフレーム版はマシなのかしら。
-
- 119
- 2002/09/21 18:20
-
研究力もそれに対する投資も確かに凄い。
そもそもRDBの生みの親、Codd博士がIBMラボの人間。
学術に近い技術書になると、DB2をサンプルにしているものも少なくない。
上のほうでも書かれていたように、思想的な部分でDB2は良く出来ている。
ただ実用段階では少々様子が異なる。
IBMの製品は、初期は使い物にならない品質でも出荷してしまう。
品質向上の期間をIBMのネームバリューで持ちこたえられたら良いが、
そうなるまでは使い物にならないことも多々ある。
DB2 UDBは諸々の機能を実装している最中であり、まだ過渡期に
あるため、ミッションクリティカル・ビジネスで使うには、もう
数年の発酵期間が必要かと。
ちなみに、メインフレーム上で動いているDB2は実績があるし、
市場でもきちんと評価されている。
DB2 UDBは、移植でなく書き直されたものらしいがね。
-
- 120
- 2002/09/21 23:06
-
>>116
>そのうちInfomixもInfomix UDBとかInfomix DB2とか命名するのかな。
>（もうなってたりして）
まだなってないな。
基本的に「IBM」が製品の前につくようになったみたいだ。
いつまでInformixやるのかなぁ。DB2に逝こうなんてことになったら
最悪っぽいね。高くてもOracleの方が楽かな？
-
- 121
- 2002/09/22 02:11
-
Oracleのシェアードディスクってパフォーマンス上がらないって良く言われない？
１+１が1.2位だって。。。
みんな言ってるよ！
-
- 122
- 2002/09/22 08:39
-
ロックエスカレーション.......
確かにとんでもねえけど、考え方によっては下手な素人が
テーブルの全レコードをUpdateしようなんてしたとき、テーブルロック
しなかったためにロックのオーバーフローなんて起きないようにしてくれる
って機能だから親切って言っちゃ親切だな。
玄人からするとウザイけど。
-
- 123
- 2002/09/22 13:21
-
>>121
それって、Oracle8iの話だろ？
9iのRACはすげーよ。
1+1で1.9くらいのパフォーマンスだせる。
-
- 124
- 2002/09/23 02:00
-
>>103
菅原タンﾊｧﾊｧ、国内刊行物の殆どに絡んでるんだけど。
情報少ないな。
-
- 125
- 2002/09/23 03:17
-
>>123
OLTP系でもDSS系でも両方とも？
良くRACは止まらないって、ORACLEの営業が言ってるけど、それ本当〜？
あと、ロックエスカレーションが叩かれているけど、テーブルロックを必要とすることはないの？
-
- 126
- 2002/09/23 19:39
-
おらの場合、表ロックしたければそれも可。
DB2 UDBやMS SQL Serverのように、ユーザーの意図しないところで
行ロックが上位のロックになることはない。
-
- 127
- 123
- 2002/09/24 00:18
-
>>125
なるほど、それは確かに良いね！
おらの分離度はどう？
読み取り一貫性って、あんなんでいいの？
-
- 128
- 2002/09/24 01:26
-
ロックのどの点を疑問に思ってるのかわからんが、
ANSI標準でいうところでは4段階定義されてるよね。
1.直列化(完全保護)
2.読取反復可能(仮読込に弱い)
3.コミット読込(仮読込・非反復読取に弱い)
4.未コミット読込(ダーティリードもお構いなし)
おらは1番と3番を、DB2 UDBは4段階全てを実装してて、デフォルトは
両方3番のコミット読み込み。
(ちなみに、Microsoft SSも4段階全部実装、デフォルト3番)
システム構築上は、直列化とコミット読込だけで不足はなく、
ダーティリード論外には同意はするのだが、自分ところの
ポリシーだけでなく、標準通りに実装してくれよ、とも思う。
-
- 129
- 122
- 2002/09/24 21:45
-
表ロックしたいときは表ロックするさ。
問題なのは行ロックを指定していたにもかかわらず勝手に表ロックに
されてしまうことなのさ。（これがエスカレーション）
ま、設定次第なんだがな。
-
- 130
- 2002/09/24 23:27
-
でも具体的にロックエスカレーションで困ることってある？
ロックの目的は、指定したトランザクションの分離度が実現する為のものであると理解してます。
オラの読み取り一貫性は、厳密には、ANSI4段階のどれとも微妙に違うらしいが、そっちの方が問題じゃないかなー
昔は、ロックエスカレーションをして、間違ってロックしてパフォーマンスが低下するケースがあったらしけど、今はそんなことはないらしいよ。
といって、DB2、MSが良いDBかというと非常に疑わしいが。
IBMもMSもDBビジネスにどこまで本気なのだろうか…？
-
- 131
- 2002/09/25 00:49
-
おらがANSI標準SQL規格と異なるのではなく、他のRDBMSとおらでは
READ COMMITTEDの実装が異なるというのが正解っしょ。
READ COMMITTEDのおらでの未確定行の読み込みは、最新の確定の
データを返す。他のRDBMSでは未確定行の読取は確定するまで不可。
そのせいで、おらにはロールバックセグメントやUNDO表領域なんて
機能的には便利だが管理が面倒なのが必要になってたり、実装の
違いで他のRDBMSから流れて来た人には嫌われたりするのだが。
だけどね。IBMにもっと頑張って欲しいと思う反面ね。
ロールバックセグメントの件もそうなんだけど、かつて遅いと叩かれた
シェアードディスククラスタも、茨の道を歩きながら実装にこぎつけて
いるおらを見ていたら、最初から技術的に妥協しているMSやIBMが
おらに追いつけるとは、とても思えないんだよ。
-
- 132
- 2002/09/25 17:17
-
>>125
>OLTP系でもDSS系でも両方とも？
RACはやっぱり、OLTP系に強いのが売りなんじゃないかな。
DSS系で強いのは当然、更新ばんばんかかるOLTPでもパフォーマンス出せるのを売り文句にしてる。
-
- 133
- 2002/09/25 17:18
-
>>131
なんか、おんなじ考えの人がいて泣けたっす！
-
- 134
- 2002/09/26 00:43
-
>>131
おらは、ある意味すごいと思うが、ロールバックセグメントにデータが
書きこまれた時点でコミットしているから、“READ COMMITTEDのおらでの
未確定行の読み込みは、最新の確定のデータを返す”ということができるんだよね？
ディスクに書きこまれてない状態でコミットするってのはどうかなー？
正直かなり不安があるけど、、、
運用も複雑そうだし。。。
僕は、MSとか、IBMは、製品コンセプト、投資対象のポイントが違うからで、
妥協しているとは思ってないが。
オラクル伝だっけ、昔読んだけど、すごく頑張った会社だと思うが、最近のおらを見て
今後も、おらと付き合うのは、どうかと思うけど、そんなこと思うのは、僕だけかな？
-
- 135
- 2002/09/26 00:43
-
UDB、2,3ヶ月に1度止まる。そいでデータも壊れる。
ＡＩＸマシンでログをＩＢＭにだしても原因がわからない。
2年ほど。数台で。
対して、ＯＲＡＣＬＥ。RAID組んでないＨＤＤの物理破損によるデータ破損は
あったが、それ以外の原因で飛んだ経験はない。10年ほど。
Netware,Win3.5,4,2000＆UNIXで、100台ほど。
よって理論や哲学をおいて、現実と経験ではORACLE圧勝。
-
- 136
- 131
- 2002/09/26 00:47
-
>133
賛同ありが?。でも、技術者のｵﾅｰﾆだと嫌なので、迷えるユーザーさんの
ためにもう少し書かせておくれ。
データベースを資料室だとする。俺は資料室にある資料を修正したい。
そこで、資料室の管理人さんにお願いして、資料を貸し出させてもらう。
自分の机に持ち戻って修正する。終わったら資料室の管理人さんに返す。
その間に君が同じ資料を見たいとする。残念ながら目当ての資料は
貸し出されてて無い。仕方ないので、俺が資料を戻すのを待つ。
君が急ぎのとき、俺んとこにきて修正中の資料を盗み見ることになるが、
それがダーティリード。俺が資料中の前社長の額に肉マークを落書きしてても
(当然返すまでには新しく就任した社長の写真と入れ替えるのさ)、それが
正しい情報だと判断することになる。
以上が非おらの場合のトランザクション分離性、READ COMMITTEDの実装。
-
- 137
- 131
- 2002/09/26 00:47
-
おらの場合、資料室の管理人さんは、貸し出すときに資料のコピーを
とっておいてくれる。ただ見たいだけの人にはコピーを見せる。
待ちたい人には待たせるし、原本はあくまで貸し出し中なので、
勝手に修正はできない。
これはおらの読取一貫性機能とよばれているもので、ディスクの負荷は
増えるけど、大勢の人間がデータを効率よく利用することができるし、
急ぎの人には直近の正しい情報が渡せるので、ダーティリードの必要性
自体が無くなっている。
-
- 138
- 131
- 2002/09/26 00:48
-
どっちがいいかは場合によって異なるが、アーキテクチャの理解を深めれば、
非おらのDBMSがデータを入れる単なる箱であるのに対し、おらの場合は
それを超えるサービスを提供してくれているという認識はある。
MSはユーザーインターフェース、DTSをはじめとしたユーティリティの
秀逸さは認める。
IBM(UDB)は標準に準拠した、思想的優位性は認める。
それ以外に特筆する点は...どうだろう？
-
- 139
- 131
- 2002/09/26 00:59
-
>133
えーと、正確には、ロールバックセグメントではなくてREDOろぐだよ。
REDOろぐに書き出された時点でデータリカバリが可能になるので、コミットとして
認識される。
製品コンセプトと妥協については、受け取り手の捉え方次第だね。
さらに改良するための壁を越えようとしているのか、ハナから壁を越えるのを
拒否しているか。最近ほっとなクラスタの議論を見ていると、特にそれを感じるのさ。
ああは書いたが、DBMSはACIDとサポートが完全に機能するならば、他は全部
オプションというのがおいらのスタンス。
最近の日本おら社は...センスもパワーも感じない。
大きくなりすぎたのかなって感じがするよ。
2ちゃんで長文ｽﾏｿ。それじゃ逝くわ。
-
- 140
- 131
- 2002/09/26 01:03
-
>>133にもう逝ってん補足だわ。
読み取り一貫性機能でのロールバックセグメントとREDOログの
データ書き出しは、別。
詳しくは...勉強してくれ。
-
- 141
- 2002/09/26 01:54
-
>>139>>140
それは>>134に対する突込みでしょ？
漏れも憤慨したので突っ込むぞ！
>>134
>ディスクに書きこまれてない状態でコミットするってのはどうかなー？
おいおい、Oracleを、というよりＤＢを勉強してから書き込んでくれよ〜
どこの世界にディスクに書き込まないでコミットするRDBMSがあるんだよ〜
Oracleの場合、Redoログファイルに書き込みが終わるのを待ち届けてからコミットが完了するんだよ〜
ちなみに、ロールバックセグメントはその名の通りロールバックに使用される。
他にも、更新中でコミット前のデータを読むときにも使われるね〜
Redoログファイルはリカバリのときに使用される。
マシンがクラッシュ！したときなんかは、Redoログから更新データを読み込んで復旧するわけだ。
すごいぞOracle！
-
- 142
- 2002/09/26 01:55
-
>>141
>他にも、更新中でコミット前のデータを読むときにも使われるね〜
ごめん
この言葉ちょっと御幣がある
-
- 143
- 2002/09/26 07:13
-
UDBのオプティマイザの感想教えて！
よく他社競合製品の比較で、某社のDBのオプティマイザはヒントが
必要とか、某社のDBのオプティマイザはヒント文化だとか書かれて
いるんだけど、ヒントの実装が無いUDBのオプティマイザはそこまで
完璧なの？？
某社のDB使い続けているけど、ヒントって本当に困ってどうしようも
ないときしか使わんぞ、ｵﾗｧ!
-
- 145
- 2002/09/26 11:19
-
＞ところで、UDBのオプティマイザ
UDBは8でもコストベースのみでルールベースはないらしい。
最近はUDBの本も増え、研修も無料、開発CD-ROMもただで、製品値段も激安、
IBMという会社は信頼できるので、個人的にはDB2でやりたい。
でも>>135みたいなことがある。問題に対応できる技術というか能力がお粗末
逆にORAは、スタンダードの値段をあげるは、開発ツールは抱き合わせ販売
するは、インストーラがJAVAで遅いのは我慢できるがツールもJAVA化を推進
するは、サポート、講習会はバカ高いので、さっさと縁を切りたいがＲＤＢ
の性能（チューンすればね）、安定性がとてもよいうえに各種ツールが
そろっているのでムカはいってるけど捨てられない。
結果として日本おら社に中指つきたてながら、おら使ってる（とりあえず、
プロジェクトが成功して安定稼動すれば、総予算からみればオラとDB2の
価格差などハナクソみたいなもんですぐ吸収できるから）
おらであればすぐに開発要員を確保でき、市販本を勉強すれば中小企業
で必要とされる要件内のバッチ処理も入力系もまともなものを安心して構
築できる。
-
- 146
- 2002/09/26 11:28
-
>>143
>ヒントの実装が無いUDBのオプティマイザはそこまで完璧なの？
たしか、ＵＤＢでヒント文のような、実行計画を変えさせることをやろうとすると、
統計情報をそう仕向けるようにいじくってやらなきゃいけないらしい。
とてもめんどうくさいし、それ以前にどういじくればいいのかの情報が全然ないらしい。
>某社のDB使い続けているけど、ヒントって本当に困ってどうしようも
>ないときしか使わんぞ、ｵﾗｧ!
つまり、オラのオプティマイザがすばらしい、ってことだね！
-
- 147
- 2002/09/26 11:31
-
>>147
>ツールもJAVA化を推進するは
そのおかげで、OSが違ってもまったく変わらないインターフェースが実現できるわけで、
むしろ助かってる面の方が大きいぞ。
確かにJAVAは遅いけどな。
-
- 148
- 2002/09/26 12:44
-
オラ、ライセンス価格が半額になったとかサギみたいなこと言ってるが
だまされるなよ。
これまで
エンタープライズ1000万+スタンバイサーバ25％＝1250万円
現在
エンタープライズ500万+スタンバイサーバ定価＝1000万円
-
- 149
- 2002/09/26 13:48
-
日経オープンシステム10月号に結構くわしく書いてある
例えば
・導入コスト重視ならＤＢ２
・運用が楽なのはオラ
運用なんて毎月の固定だから、トータルでは運用費が安いほうがいいのだが、
初期費用の差が大きすぎるのが痛いね。
-
- 150
- 2002/09/28 02:33
-
おらくる９iってWinXP Homeにインストールできないのね・・・
自宅で勉強しようと思ったのに。
-
- 151
- 2002/09/28 10:57
-
＞おらくる９iってWinXP Home
保証はしてないけど、一応できると思うが・・
-
- 152
- 2002/09/28 13:50
-
>>151
そうなの？
なんかインストーラが途中で固まっちゃうんですけど
本についてた１２０日版だからかな
-
- 153
- 2002/10/01 04:15
-
>>149
UDB、毎週止めて表のリビルドって、何で必要なんだろ。
これって、雑誌の記事の例に挙がるほど一般的な作業なの？
基幹系に使うには危険すぎる香りがするんだけど。
-
- 154
- 2002/10/01 08:22
-
>153
な、なんだそれは？毎週止める？そんなDBあんのか
-
- 155
- 2002/10/01 20:36
-
>153
よほどフラグメントがひどいのかな?
でもそんなの1コンテナ？1テーブルにしちゃえばよさげなきがするが。。。
-
- 156
- 2002/10/01 20:57
-
詳しくは日経オープンシステム 2002年10月号 156Pを読んでくれ。
日本おら社が金を握らせてるんじゃないか？と疑いたくなるほどな内容。
ちなみに、DB2 UDBの事例で挙がっているのはクボタの出張旅費生産
システムで、運用の中でテーブル再編成(REORG)のため、毎週データ
ベースを停止して2時間半の再構成をするそうな。
しかも、そのときには作業領域も必要になるので、空き容量監視も
厳しく行う必要があるそうな。
ほかにも、ログの出力が不便だとか、GUIコンソールではコピーの隣に
ドロップがあるとか、とにかく読んでいて不安になるばかり。
まだ出荷もされていないv8.1では解消の方向に向かうとか書かれても。
俺が客だったら、こんなRDBMSの面倒は見たくない。
-
- 157
- 2002/10/01 21:52
-
おいらはどっちでもいーけど
DB2の方が稼動費たくさん取れる。
面倒だがおいしいのはDB2。 ｳﾋｬﾋｬ!
-
- 158
- 2002/10/06 01:44
-
DB2のJavaのツール、重いよね。
どんな環境でも同じものが動くのは良いけど重いのだけはなんとかなんねぇもんかなぁ。
-
- 159
- 2002/10/06 13:05
-
Javaツールって不安定だしな。しかし、Oracleのも重いぞ。
全部コマンドでやっちまうから、折れには関係ないが。
-
- 160
- 2002/10/07 13:05
-
煽り覚悟で申し上げますが、
他は知らぬがオラのオプティマイザはまだまだ不十分だ。
自動でそして定期的にアナライズしてくれ･･･
-
- 161
- 2002/10/07 23:21
-
>>160
しかし、ＤＢ２のカスよりはよほどまともなオプティマイザだとおもう。
一度ＤＢ２で偏った大量データをもつシステムに触ってみなさい。
-
- 163
- DB2
- 2002/10/08 23:28
-
更新中の表を検索する時に
IndexないとLockWaitってなんかアホっぽいんだけど。。。
最新版ってなんか変わってる？
-
- 164
- 2002/10/09 00:14
-
>163
変わってないんじゃないか？
むしろそれはダーティリードでもさせない限りどんなDB でも避けられないと思うが....
オラクルとかはOKなん？
-
- 165
- 2002/10/09 00:41
-
確かOKだと思ったが。
読み取り一貫性っておらでは言ってるけど、あるタイミングでカーソルを
オープンした後で、別のところから更新・コミットしてもそのカーソルは
（クローズしない限り）更新前の情報が読み取られる。…んじゃなかったっけ？
このページを共有する
おすすめワード