Oracle? DB2? Symfoware? HiRDB? SQL鯖?
商 用 R D B M S 徹 底 比 較 ス レ ッ ド Oracleは赤くてキモイ
ワールドカップの韓国を思い出す 誇らしげに人数を公表するなら、無料で取らせてほしい。 >>166
DB2の一番下の奴は展示会とかでタダで取れるな。アドバイザだっけ?
馬鹿みたいに簡単だったが。ただ単にDB2エンジニアと「呼べる奴」の人数を
増やしたいだけちゃうんかと。 マイクロソフトのサーバOSが、駆逐されてゆくこの世では
Windowsがないと動かないSQL鯖は論外。
よってOracleの勝ち。
MSDEって何だ?SQL鯖もどきか?Jet関係か?
くだらねぇ(笑) >>172
> マイクロソフトのサーバOSが、駆逐されてゆくこの世
世界は、人の数だけ存在するようだ。 >>174
あふぉ。自然に消えてゆくから心配すんな。 Oracleを選択するならOSをLinuxにするメリット
がイマイチ分からん。
Oracle Enterpriseが高すぎるから少しでもハード
(とOS)代浮かせたいから?それともIntelチップの
高クロックが欲しいから?Solarisのエンジニアが
いないから? >>178
じゃあ、なんでSolarisなの?
Sunの社員だから?(w 冗談じゃありません、現状でDBの性能は100%出せます!
OSなんて飾りです!偉い人にはそれがわからんのです!! DB2、S/390の組み合わせが最強
スケーラビリティゼロのRACは話にならない 今どきデータマイニングアプリ出してないメーカーのDBなんて糞
企業で最もよく利用されているデータベース製品
1位 Oracle 53.5%
2位 SQL Server 25.6%
3位 DB2 10.2%
4位 PostgreSQL 1.9%
5位 Sybase 1.4%
6位 Informix 1.4%
7位 SymfoWare 1.4%
8位 HiRDB 0.5%
その他 4.2%
合計 100.0%
勝ち組は、 H/W + OS + DBMS => DELL + Linux + Oracle
だろうna、DB2 は売れてないし、SQL Server は Winだけだしな。
PostgreSQL、MySQL は数は覆いけど、金額として見えないし、鯖企業
が担いでないからね。
デルとオラクル、両社製品を組み合わせて提案・提供する共同営業体制を確立
http://linux.ascii24.com/linux/news/today/2003/09/19/646030-000.html
http://www.oracle.co.jp/linux/linuxfaq.html#Support_All_Products
>>99
Informix は IBM に買われちまったよ。
>>98
Free が中小規模ではメジャーで進むだろうね、PostgreSQL/MySQL/FireBird
だが、ある規模以上だとハード企業が手伝わないと性能向上が難しい。当面は
Oracle/SQL Server/DB2 は必要 規模とか混同してないか?
大規模システムなら、Oracle対DB2だろ。
ほかに選択しないし。
MSSQLとか選択してるなら、まぁ、それは勇気のあることだが。 Ingresは完全に忘れ去られているな。
国内じゃもうどこも使っているところないかな? 信頼性No1は汎用機
Oracleは信頼性が要求されないシステムでしか使われない
SolarisもHP-UXも糞。Linuxは論外 >>183 >>190
MF + 390DB2 なら嬉しいけどね
P/i/X + DB2UDB は嫌だね、Oracle 以下なのが明白
UNIX + RAC が MF(H/W CF)+DB2 に信頼性が劣るのは事実だろうが、
それに対抗する UNIX + DB2 でのソリューションを提案できないのが
IBM の限界だろう >>193
IBM の pSerise(AIX)、iSerise(AS400)、xSerise(PC Server)
じゃねぇのか xSeriesの間違いだな。それはいいとして、kabu.comってとこが
受注系DBにMS-SQL Server使ってるんだよ。俺も良く使うなと思ったけど、
UNISYSの32CPUサーバーを16CPUずつ分割して、Win2k Datacenter Editionを
入れてるようだ。このクラスになると汎用機並みに稼動中に
CPUやメモリ入れ替えできるんでしょ? >192
サンクス。
AS400とDB2UDBの組み合わせはダメなのか、知らんかった。
AS400が日経コンピュータの満足度調査とかで評価が高いのはなぜ? >>196
昔のオフコンの生き残りが AS400 で今の iSeries だ
高いけど、手厚いサポートが着いてくるので顧客満足度は高い
国産企業も、昔の汎用機やオフコンみたいに高い金額をくれるならIBM
よりも良いサポートは可能だろうって。。
>197
なるほど。
無知ですまんが、AS400のDBってDB2UDBが標準? このスレってさ、営業スレだろ?
すげー笑えるんだけどw >199
なるほど、DB2/400がDB2のオリジナルなのか
サンクス! >>200
IBM社員もここに参戦すればいいのにね。 >>201
いや、元な訳ではなく。
オフコンや汎用機についてるDBに、ブランドネームとしてDB2という名前を付けてるだけ。
ただ、ブランド名としてDB2は勝手に名乗れるが、UDBを名乗るために必要な機能の定義ってのがある。らしい・・・。
ちなみに、AS/400のvarcharは、可変長に見えるように仕込んである固定長です。 >>207
そうすると、IBM が「DB2 は市場占有率1位」というのは虚偽に近い
んだね。AS/400 の異なった物まで含んでるんだから。。
>>208
いや、「DB2 は市場占有率1位」は本当。
だって、DBが動いてる全てのプラットフォームを含んでの話だから、嘘にはならないねぇ。
マーケティング上の口八丁な訳だし。
つこって、プラットフォーム別の占有率を調査した結果を知ってる人でてきて〜。
それぞれの真実を知りたい。 国内データベース市場出荷推移 (出荷金額)
国内 Windows Server RDBMS 市場ベンダー シェア (出荷金額)
出展:ガートナー データクエスト (2002年 7月)
http://www.microsoft.com/japan/sql/choice/leader/
>>210
ま、Oracleがトップなのはやっぱりなってカンジだが。
商用UNIXで66%とは、すげーな。ほとんど寡占みたいなもんだな。 >>214
特に日本ではOracle一色。
確か1999年はUNIXで80%くらいシェアあったんじゃない。
育代のOra伝みればOracleの一番輝いてたときがわかるよ(w >>140 >>141
read committed = コミットしていないデータを読ませるという意味ではない
と解釈すると、ある意味あっているようだが。
>>140 >>141
ダーティリード=不正な読み取り
と解釈すると、ある意味あっているようだが。 RACのインスタンス同士は "7秒間" 同期しないのがデフォルト!
しかも、それを推奨値にしてるって知ってた?
→ 0秒にすると負荷が高すぎて使い物になんねーんだってyo
ダーティリードを不正な読み取りと解釈すると、コレもそうだな(w
別インスタンスに接続した奴は max 7秒は最新データみれないからな(爆
あと、tpccベンチマークトップをとった10gも意図的にRACを使ってねーよ
RACの真実を知りたい人は↓を申し込め!無料でもらえるぞ
http://www-6.ibm.com/jp/software/data/reality/ >>217
read commitedのどこが不正な読み取り?
まじな解説おねがい。
dirty readってuncommited readじゃないのか?
>>218
ネタにまじれすで申し訳ないが、
国際業務機械のOra叩きを真に受けるとはおめでてーな
国際業務機械の工作員かと思ったが、
> あと、tpccベンチマークトップをとった10gも意図的にRACを使ってねーよ
わけわかんね
TPC-CトップのSuperdomeは2箱で1台のマシンだYo!
Iの工作員ならこれくらい知ってるはずだからな。
ただのアンチOra房だな。
どこの工作員かしらんが、煽るならもっとうまくやれ
>>218
>RACのインスタンス同士は "7秒間" 同期しないのがデフォルト!
>しかも、それを推奨値にしてるって知ってた?
>→ 0秒にすると負荷が高すぎて使い物になんねーんだってyo
MAX_COMMIT_PROPAGATION_DELAYを間違って解釈してるYo!
マニュアルがおかしいんだけどな。
>>222
いんたーなしょなる びじねす ましーん
>>220
>TPC-CトップのSuperdomeは2箱で1台のマシンだYo!
ていうか、RAC がほんとにパフォでるんだったら
RAC で勝負するダロ。現実は RAC より シングル の方が上だからな >>226
まずはシングルノードでやってみるもんでないの?
>>227
じゃぁ結果を楽しみに待ってるYO (w >>221
池田先生
MAX_COMMIT_PROPAGATION_DELAY の本当の解釈を教えてください >>227
性能出すんならシングルノードの方が追い込みやすいんだな。
>>227 >>228
いくら待ってもRACの結果はtpccには入らないyo (藁
仮に, 4台構成のRACでシングルよりも1.5倍程度の結果しか残せなかったら
「RACはヘボです」っていってるようなもんだし。
都合の悪いデータはベンチマーク登録せず。これ鉄則 >>219
RBSもってないRDBMSからみると、Oracleのは
set transaction read write , isolation level read uncommitted
にみえるワケよ オマエ、Oracleどころかその「RBSもってないRDBMS」すら
ロクに理解してないだろ。 >>233
おっOCP取得のアシ○トの新人君登場でつか? >>233
Oracleはuncomittedな他のセッションの更新はどうがんばってもreadできないぞ
>>229
赤彗星じゃなくて申し訳ないが
MAX_COMMIT_PROPAGATION_DELAYはSCNの伝播スキームを切り替える(3種類)
パラメータであって、同期しない時間間隔を設定するもんじゃないYo!
デフォルトの700だと、各ノードローカルでSCNが生成できる。
通常はノード間通信のパケットにSCNがパッキングされてるから、伝播遅延
は起きないYo!
ローカルキャッシュヒット100%のときとか、Oracleがひまにしてるときは
ノード間通信がおきないから、SCNが各ノードで差が大きくなる場合がある。
大きくずれるのは気持ち悪いから、適当な間隔でSCNを同期させる。
そのタイムアウトは3秒固定だ。
M_C_P_D<100のときはcommit即SCNブロードキャストね。
でも実際にはこれでも性能は落ちないYo!
マニュアルの記述が昔からかわってないから国際業務機械にあげあしとられ
るんだYo!
RACの中の人マニュアルなおせ。
シャアの声優が池田秀一なんだって
なんかオナニーだなw だからといって、COMMIT前のデータ読ませてもいいのか??
きっとOracleでread committedの動きを考えたヤシらは、
リードロックでアプリが遅くなるのを恐れたチキンどもばかりのはず。
「おれのcommitが終わってから読んでくれ」という要請に、
Oracleのread committedでは答えられないのだよ。
(カーソルつかえば別だけど) ほら、初心者がツールの使い方よく理解してなくて
「バグだ、バグだ」って騒ぐことってあるよな。 >>245,246
そのためのSELECT FOR UPDATEだろ?
ん、233=245=246は常にread lockがかかって欲しいひとなのか?
そういう思想を否定はしないが...
>>248
Oracle以外だと、そういう文化の人が多いよ
第一、select for updateだとそういうやりかたを知ってる人しか記述できないジャン。
ロックの使い方=トランザクション保護なのだから、
指針としてきれいにだせて、コーディングレベルのミスを減らせられなければヘンだよ。
いちいち設計書に書いてあげる?ンなバカな・・・
そんなことやらないといけない時点で、品質きまっちゃうよ。 >>250
ISOで規定されたそれぞれのトランザクション隔離レベルで保証
されるべきものとそうでないものとの区別ができていないんだな。
read commited で保証されるのは dirty read が発生しないこと。
それ以上でもそれ以下でもない。
必要な隔離レベルを満たす実装方法はひとつではないし、その
方法によってやや特性が異なる部分はあるが、そこのところの
切り分けがきちんとできていないと、可搬性の悪い設計をしたり
「Oracleはおかしい」と悪態を吐いたりすることになるわけだ。
dirty read と nonrepeatable read との区別がついていないのは
論外。 >>251
単にoracle的解釈だとnon-repeatable readになるだけだろ、あれって。
ANSIにのっとった解釈ではないよあれは。
ただ、ANSIに則っているからといって、どうなんだ?といわれるとアレだけど。 oracleのあのやりかたって、ホンシメジだと思うんだけどね。
そう、チキンっていう表現は適切ではないね。
ホンシメジが適切。 >>253
>単にoracle的解釈だとnon-repeatable readになるだけだろ、あれって。
non-repeatable read じゃなくて read committed のことを言って
いるんだと思うが、ANSIの解釈とどう違うって? なんかどうどうめぐりになってくる予感がするな。
ちとここまでの流れを整理してみよう。 それに、ANSIの定義の話になったところで、
せいぜいfjニュースグループ程度の議論しかでけんでしょ。
そもそもレコード排他は、ACID特性のACIの部分を実現するための技術。
・限定品購入トランザクション:あと2名様って書いてあったから予約しよう
正しい結末:ちゃんと予約できる
・期末テストトランザクション:見直してみたら間違えていたので修正しよう
正しい結末:直した結果が評価されて点がつく
・障害報告トランザクション:お客さんに今日の障害表を報告しよう
正しい結末:今日の障害表が報告される
・今日の晩御飯トランザクション:冷蔵庫にあと何個くらい卵があったか子供に数えさせよう
正しい結末:ざっぱに見てあるかないかがわかる
数多のRDBMSは、これらが正しく行われるために
1SQLごとにロックの付与、質、粒度を変化させて実現を図る。
付与する期間はトランザクションの開始〜終了までの間。
・障害報告トランザクション
これについて、Oracle型の結末と、DB2型の結末は違う場合がありえる。
報告役のアクション:
お客さんに今日の障害表を報告しよう。
障害表で今日まででまだ未解決のものを探して報告するのだ。
障害調査員のアクション:
やっと社内レビューおわったよ。
障害表に原因判明って書いとけって課長が言ってたっけ。急いで直すべ。
↓
Oracle:
「障害表に原因判明って書いとけって課長が言ってたっけ。急いで直すべ。」が
反映されていない傷害報告が行われる可能性がある。
ただし、報告役の人間は、きちんと報告時間にやってくることが保障される。
DB2:今日報告したい内容の障害報告がなされることが保障される。
ただし、報告役の人間が、報告時刻にすこし遅れてやってくる場合がありえる。
Oracle :間に合わなかった報告項目は、割愛
DB2 :正しい報告を行うためにロック待ち
Oracle :間に合わなかった報告項目は、割愛
DB2 :正しい報告を行うためにロック待ち
↓
Oracle:
read committedとは既コミット済みを読ませればよいので、係でコミット済みのものを読ませる
・読もうとした内容が、他トランザクションでコミットが済んでいないものがある
→その前の時点でコミット済みのレコードを読ませる。
(この解釈はOracleだけが行っている解釈)
DB2:
read committedとは、コミットが済んでいないものを読ませてはいけないので、
書き手トランザクションと読み手トランザクションの排他関係でコミット済みのものを読ませる
・読もうとした内容が、他トランザクションでコミットが済んでいないものがある
→他トランザクションの終了を待つ
結論:
read committedの解釈は現状2つにわかれている。
性能をとるなら、Oracle的解釈
正しさをとるなら、DB2的解釈
(正誤表)
(誤)
Oracle:
read committedとは既コミット済みを読ませればよいので、係でコミット済みのものを読ませる
↓
(正)
Oracle:
read committedとは既コミット済みを読ませればよいので、
排他をとらず、読み手には、前に誰かがコミット済みにしたものを読ませる
また、Oracleで
set transaction read write , isolation level read committed
と書かれているトランザクションを正しくDB2で動かすには、
set transaction read write , isolation level read uncommitted
と書かないといけません。
試しに、結合テストでタイミングが気になる処理のテストを実施してみてください。
そうした場合、そうしなかった場合でテスト結果が変わってきます。
Oracleのときのテスト結果と合うのは、後者の
set transaction read write , isolation level read uncommitted
と書いた場合になります。 なんでこんなにくどく書くかというと、
最近、基幹系のアプリ障害でこういうケースがあったからです。
お客さんって、どちらかというと汎用機よりの考えをします。(つまりDB2より)
一方最近のSEはOracleよりの考えで報告します。
仲裁するヤツの立場にもなれっつーのよ、ホント。
あーあ、だからちゃんと勉強しとけって言ってるのに。
その設計をした香具師は「後続の読み取りトランザクションはread
committedだから先行の更新トランザクションの完了を待つはず」と
思い込みをしたわけだろ?
トランザクション分離レベルというのは他トランザクションの結果が
自トランザクションの結果に及ぼす影響をどれだけ排除するかという
度合いであって、排他制御とか、実行制御の話ではない。もちろん
実装上はロック等の排他制御を利用するが、それはあくまでも
実装の話。製品が異なれば実装が異なるのはあたりまえ。
ところで
T1:トランザクションA開始
T2:トランザクションAがレコードを更新
T3:トランザクションB開始、レコードを読み取り
T1<T3は何らかの方法で保証したとして、T2<T3てのもちゃんと
同期をとって保証されるようにしたのかね?そうでなきゃ、DB2
使ったとしてもおんなじ障害は発生するよ。