X



Oracle? DB2? Symfoware? HiRDB? SQL鯖?
0168名無しさん@お腹いっぱい。
垢版 |
03/09/11 22:33ID:???
>>166
DB2の一番下の奴は展示会とかでタダで取れるな。アドバイザだっけ?
馬鹿みたいに簡単だったが。ただ単にDB2エンジニアと「呼べる奴」の人数を
増やしたいだけちゃうんかと。
0171155
垢版 |
03/09/13 12:17ID:Y9TyuqBX
>>168
そうだよ。
0172名無しさん@お腹いっぱい。
垢版 |
03/09/14 22:09ID:YBCGxTkp
マイクロソフトのサーバOSが、駆逐されてゆくこの世では
Windowsがないと動かないSQL鯖は論外。
よってOracleの勝ち。
MSDEって何だ?SQL鯖もどきか?Jet関係か?
くだらねぇ(笑)
0175名無しさん@お腹いっぱい。
垢版 |
03/09/15 00:08ID:O54VGyaG
>>174
あふぉ。自然に消えてゆくから心配すんな。
0178名無しさん@お腹いっぱい。
垢版 |
03/09/17 01:12ID:???
 Oracleを選択するならOSをLinuxにするメリット
がイマイチ分からん。
 Oracle Enterpriseが高すぎるから少しでもハード
(とOS)代浮かせたいから?それともIntelチップの
高クロックが欲しいから?Solarisのエンジニアが
いないから?
0180名無しさん@お腹いっぱい。
垢版 |
03/09/19 21:17ID:LOXaQ3p5
sybase ASEは?
0181名無しさん@お腹いっぱい。
垢版 |
03/09/19 21:30ID:TcVlwXEr
冗談じゃありません、現状でDBの性能は100%出せます!
OSなんて飾りです!偉い人にはそれがわからんのです!!
0183名無しさん@お腹いっぱい。
垢版 |
03/09/20 01:23ID:CHNTbK9w
DB2、S/390の組み合わせが最強
スケーラビリティゼロのRACは話にならない
0185名無しさん@お腹いっぱい。
垢版 |
03/09/21 00:23ID:???
企業で最もよく利用されているデータベース製品
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%

0186名無しさん@お腹いっぱい。
垢版 |
03/09/21 01:51ID:29uAnMC3
勝ち組は、 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

0187名無しさん@お腹いっぱい。
垢版 |
03/09/21 02:09ID:???
>>99
Informix は IBM に買われちまったよ。

>>98
Free が中小規模ではメジャーで進むだろうね、PostgreSQL/MySQL/FireBird
だが、ある規模以上だとハード企業が手伝わないと性能向上が難しい。当面は
Oracle/SQL Server/DB2 は必要
0188名無しさん@お腹いっぱい。
垢版 |
03/09/21 03:51ID:???
規模とか混同してないか?
大規模システムなら、Oracle対DB2だろ。
ほかに選択しないし。
MSSQLとか選択してるなら、まぁ、それは勇気のあることだが。
0191>
垢版 |
03/09/21 16:07ID:OZNHk18f
ちょいと失礼。
テスト。
0192名無しさん@お腹いっぱい。
垢版 |
03/09/21 21:03ID:WmFfRnHB
>>183 >>190
MF + 390DB2 なら嬉しいけどね
P/i/X + DB2UDB は嫌だね、Oracle 以下なのが明白
UNIX + RAC が MF(H/W CF)+DB2 に信頼性が劣るのは事実だろうが、
それに対抗する UNIX + DB2 でのソリューションを提案できないのが
IBM の限界だろう
0193名無しさん@お腹いっぱい。
垢版 |
03/09/22 17:25ID:3qgQP3Jd
>192
P/i/X って何?
0194名無しさん@お腹いっぱい。
垢版 |
03/09/23 00:03ID:FB5RtJhO
>>193
IBM の pSerise(AIX)、iSerise(AS400)、xSerise(PC Server)
じゃねぇのか
0195名無しさん@お腹いっぱい。
垢版 |
03/09/23 07:17ID:???
xSeriesの間違いだな。それはいいとして、kabu.comってとこが
受注系DBにMS-SQL Server使ってるんだよ。俺も良く使うなと思ったけど、
UNISYSの32CPUサーバーを16CPUずつ分割して、Win2k Datacenter Editionを
入れてるようだ。このクラスになると汎用機並みに稼動中に
CPUやメモリ入れ替えできるんでしょ?
0196名無しさん@お腹いっぱい。
垢版 |
03/09/23 08:06ID:AU5HFLl5
>192
サンクス。
AS400とDB2UDBの組み合わせはダメなのか、知らんかった。
AS400が日経コンピュータの満足度調査とかで評価が高いのはなぜ?
0197名無しさん@お腹いっぱい。
垢版 |
03/09/23 23:55ID:VCjepKVS
>>196
昔のオフコンの生き残りが AS400 で今の iSeries だ
高いけど、手厚いサポートが着いてくるので顧客満足度は高い
国産企業も、昔の汎用機やオフコンみたいに高い金額をくれるならIBM
よりも良いサポートは可能だろうって。。

0198196
垢版 |
03/09/23 23:58ID:???
>197
なるほど。
無知ですまんが、AS400のDBってDB2UDBが標準?
0199名無しさん@お腹いっぱい。
垢版 |
03/09/26 00:07ID:mP6tebCf
DB2/400 ってのが元
0201198
垢版 |
03/09/26 08:11ID:???
>199
なるほど、DB2/400がDB2のオリジナルなのか
サンクス!
0207名無しさん@お腹いっぱい。
垢版 |
03/09/28 01:11ID:Plk4oOKV
>>201

いや、元な訳ではなく。

オフコンや汎用機についてるDBに、ブランドネームとしてDB2という名前を付けてるだけ。
ただ、ブランド名としてDB2は勝手に名乗れるが、UDBを名乗るために必要な機能の定義ってのがある。らしい・・・。


ちなみに、AS/400のvarcharは、可変長に見えるように仕込んである固定長です。
0209名無しさん@お腹いっぱい。
垢版 |
03/09/28 11:35ID:Plk4oOKV
>>208
いや、「DB2 は市場占有率1位」は本当。
だって、DBが動いてる全てのプラットフォームを含んでの話だから、嘘にはならないねぇ。
マーケティング上の口八丁な訳だし。

つこって、プラットフォーム別の占有率を調査した結果を知ってる人でてきて〜。
それぞれの真実を知りたい。
0214名無しさん@お腹いっぱい。
垢版 |
03/10/01 01:03ID:i97HSwFc
>>210
ま、Oracleがトップなのはやっぱりなってカンジだが。
商用UNIXで66%とは、すげーな。ほとんど寡占みたいなもんだな。
0215名無しさん@お腹いっぱい。
垢版 |
03/10/01 11:31ID:Vyqu2M54
>>214
特に日本ではOracle一色。
確か1999年はUNIXで80%くらいシェアあったんじゃない。
育代のOra伝みればOracleの一番輝いてたときがわかるよ(w
0218名無しさん@お腹いっぱい。
垢版 |
03/10/01 15:24ID:???
RACのインスタンス同士は "7秒間" 同期しないのがデフォルト!
しかも、それを推奨値にしてるって知ってた?
→ 0秒にすると負荷が高すぎて使い物になんねーんだってyo
ダーティリードを不正な読み取りと解釈すると、コレもそうだな(w
別インスタンスに接続した奴は max 7秒は最新データみれないからな(爆

あと、tpccベンチマークトップをとった10gも意図的にRACを使ってねーよ

RACの真実を知りたい人は↓を申し込め!無料でもらえるぞ
http://www-6.ibm.com/jp/software/data/reality/
0220名無しさん@お腹いっぱい。
垢版 |
03/10/02 00:27ID:???
>>218
ネタにまじれすで申し訳ないが、
国際業務機械のOra叩きを真に受けるとはおめでてーな

国際業務機械の工作員かと思ったが、
> あと、tpccベンチマークトップをとった10gも意図的にRACを使ってねーよ

わけわかんね
TPC-CトップのSuperdomeは2箱で1台のマシンだYo!
Iの工作員ならこれくらい知ってるはずだからな。
ただのアンチOra房だな。

どこの工作員かしらんが、煽るならもっとうまくやれ
0221名無しさん@お腹いっぱい。
垢版 |
03/10/02 00:36ID:???
>>218
>RACのインスタンス同士は "7秒間" 同期しないのがデフォルト!
>しかも、それを推奨値にしてるって知ってた?
>→ 0秒にすると負荷が高すぎて使い物になんねーんだってyo

MAX_COMMIT_PROPAGATION_DELAYを間違って解釈してるYo!
マニュアルがおかしいんだけどな。
0222名無しさん@お腹いっぱい。
垢版 |
03/10/02 00:39ID:qfKVqpJh
国際業務機械ってなんでつか?
0226名無しさん@お腹いっぱい。
垢版 |
03/10/02 01:00ID:???
>>220
>TPC-CトップのSuperdomeは2箱で1台のマシンだYo!
ていうか、RAC がほんとにパフォでるんだったら
RAC で勝負するダロ。現実は RAC より シングル の方が上だからな
0229名無しさん@お腹いっぱい。
垢版 |
03/10/02 12:42ID:qfKVqpJh
>>221
池田先生
MAX_COMMIT_PROPAGATION_DELAY の本当の解釈を教えてください
0231名無しさん@お腹いっぱい。
垢版 |
03/10/02 19:08ID:zE7f2TYg
>>227 >>228
いくら待ってもRACの結果はtpccには入らないyo (藁
仮に, 4台構成のRACでシングルよりも1.5倍程度の結果しか残せなかったら
「RACはヘボです」っていってるようなもんだし。
都合の悪いデータはベンチマーク登録せず。これ鉄則
0234名無しさん@お腹いっぱい。
垢版 |
03/10/02 23:53ID:U6YvNlQh
オマエ、Oracleどころかその「RBSもってないRDBMS」すら
ロクに理解してないだろ。
0237234(w
垢版 |
03/10/03 00:21ID:???
池田先生(赤彗星さま)
フォローお願いしまつ
0238名無しさん@お腹いっぱい。
垢版 |
03/10/03 00:48ID:GcIbQuqU
この板でよく出てくる赤彗星って何者?
0241名無しさん@お腹いっぱい。
垢版 |
03/10/03 01:29ID:???
>>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の中の人マニュアルなおせ。

0245233
垢版 |
03/10/05 16:39ID:???
だからといって、COMMIT前のデータ読ませてもいいのか??
0246233
垢版 |
03/10/05 16:47ID:???
きっとOracleでread committedの動きを考えたヤシらは、
リードロックでアプリが遅くなるのを恐れたチキンどもばかりのはず。

「おれのcommitが終わってから読んでくれ」という要請に、
Oracleのread committedでは答えられないのだよ。
(カーソルつかえば別だけど)
0248名無しさん@お腹いっぱい。
垢版 |
03/10/06 00:15ID:???
>>245,246
そのためのSELECT FOR UPDATEだろ?

ん、233=245=246は常にread lockがかかって欲しいひとなのか?
そういう思想を否定はしないが...

0250 
垢版 |
03/10/10 15:31ID:???
>>248
Oracle以外だと、そういう文化の人が多いよ


第一、select for updateだとそういうやりかたを知ってる人しか記述できないジャン。

ロックの使い方=トランザクション保護なのだから、
指針としてきれいにだせて、コーディングレベルのミスを減らせられなければヘンだよ。

いちいち設計書に書いてあげる?ンなバカな・・・
そんなことやらないといけない時点で、品質きまっちゃうよ。
0251名無しさん@お腹いっぱい。
垢版 |
03/10/11 00:09ID:???
>>250
ISOで規定されたそれぞれのトランザクション隔離レベルで保証
されるべきものとそうでないものとの区別ができていないんだな。
read commited で保証されるのは dirty read が発生しないこと。
それ以上でもそれ以下でもない。

必要な隔離レベルを満たす実装方法はひとつではないし、その
方法によってやや特性が異なる部分はあるが、そこのところの
切り分けがきちんとできていないと、可搬性の悪い設計をしたり
「Oracleはおかしい」と悪態を吐いたりすることになるわけだ。

dirty read と nonrepeatable read との区別がついていないのは
論外。
0252名無しさん@お腹いっぱい。
垢版 |
03/10/11 00:20ID:6NZPCXlT
dirty readって何でつか?
0253 
垢版 |
03/10/11 01:29ID:???
>>251
単にoracle的解釈だとnon-repeatable readになるだけだろ、あれって。

ANSIにのっとった解釈ではないよあれは。






ただ、ANSIに則っているからといって、どうなんだ?といわれるとアレだけど。
0254 
垢版 |
03/10/11 01:30ID:???
oracleのあのやりかたって、ホンシメジだと思うんだけどね。
そう、チキンっていう表現は適切ではないね。

ホンシメジが適切。
0256名無しさん@お腹いっぱい。
垢版 |
03/10/11 10:18ID:???
>>253
>単にoracle的解釈だとnon-repeatable readになるだけだろ、あれって。

non-repeatable read じゃなくて read committed のことを言って
いるんだと思うが、ANSIの解釈とどう違うって?
0257 
垢版 |
03/10/11 23:21ID:???
なんかどうどうめぐりになってくる予感がするな。

ちとここまでの流れを整理してみよう。
0258 
垢版 |
03/10/11 23:45ID:???
それに、ANSIの定義の話になったところで、
せいぜいfjニュースグループ程度の議論しかでけんでしょ。

そもそもレコード排他は、ACID特性のACIの部分を実現するための技術。

 ・限定品購入トランザクション:あと2名様って書いてあったから予約しよう
   正しい結末:ちゃんと予約できる

 ・期末テストトランザクション:見直してみたら間違えていたので修正しよう
   正しい結末:直した結果が評価されて点がつく

 ・障害報告トランザクション:お客さんに今日の障害表を報告しよう
   正しい結末:今日の障害表が報告される

 ・今日の晩御飯トランザクション:冷蔵庫にあと何個くらい卵があったか子供に数えさせよう
   正しい結末:ざっぱに見てあるかないかがわかる

 数多のRDBMSは、これらが正しく行われるために
 1SQLごとにロックの付与、質、粒度を変化させて実現を図る。
 付与する期間はトランザクションの開始〜終了までの間。
  
 ・障害報告トランザクション
これについて、Oracle型の結末と、DB2型の結末は違う場合がありえる。

報告役のアクション:
 お客さんに今日の障害表を報告しよう。
 障害表で今日まででまだ未解決のものを探して報告するのだ。

障害調査員のアクション:
 やっと社内レビューおわったよ。
 障害表に原因判明って書いとけって課長が言ってたっけ。急いで直すべ。
  ↓
 Oracle:
    「障害表に原因判明って書いとけって課長が言ってたっけ。急いで直すべ。」が
    反映されていない傷害報告が行われる可能性がある。
    ただし、報告役の人間は、きちんと報告時間にやってくることが保障される。

 DB2:今日報告したい内容の障害報告がなされることが保障される。
    ただし、報告役の人間が、報告時刻にすこし遅れてやってくる場合がありえる。

Oracle :間に合わなかった報告項目は、割愛
DB2  :正しい報告を行うためにロック待ち
0259 
垢版 |
03/10/11 23:52ID:???
Oracle :間に合わなかった報告項目は、割愛
DB2  :正しい報告を行うためにロック待ち


 ↓


Oracle:
read committedとは既コミット済みを読ませればよいので、係でコミット済みのものを読ませる

 ・読もうとした内容が、他トランザクションでコミットが済んでいないものがある
  →その前の時点でコミット済みのレコードを読ませる。
 (この解釈はOracleだけが行っている解釈)


DB2:
read committedとは、コミットが済んでいないものを読ませてはいけないので、
書き手トランザクションと読み手トランザクションの排他関係でコミット済みのものを読ませる

 ・読もうとした内容が、他トランザクションでコミットが済んでいないものがある
  →他トランザクションの終了を待つ


結論:
read committedの解釈は現状2つにわかれている。
性能をとるなら、Oracle的解釈
正しさをとるなら、DB2的解釈
0260 
垢版 |
03/10/11 23:54ID:???
(正誤表)

(誤)
Oracle:
read committedとは既コミット済みを読ませればよいので、係でコミット済みのものを読ませる
  ↓
(正)
Oracle:
read committedとは既コミット済みを読ませればよいので、
排他をとらず、読み手には、前に誰かがコミット済みにしたものを読ませる

0261 
垢版 |
03/10/11 23:56ID:???
また、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
と書いた場合になります。
0262 
垢版 |
03/10/11 23:59ID:???
なんでこんなにくどく書くかというと、
最近、基幹系のアプリ障害でこういうケースがあったからです。

お客さんって、どちらかというと汎用機よりの考えをします。(つまりDB2より)
一方最近のSEはOracleよりの考えで報告します。

仲裁するヤツの立場にもなれっつーのよ、ホント。
0263名無しさん@お腹いっぱい。
垢版 |
03/10/13 02:01ID:???
あーあ、だからちゃんと勉強しとけって言ってるのに。

その設計をした香具師は「後続の読み取りトランザクションはread
committedだから先行の更新トランザクションの完了を待つはず」と
思い込みをしたわけだろ?

トランザクション分離レベルというのは他トランザクションの結果が
自トランザクションの結果に及ぼす影響をどれだけ排除するかという
度合いであって、排他制御とか、実行制御の話ではない。もちろん
実装上はロック等の排他制御を利用するが、それはあくまでも
実装の話。製品が異なれば実装が異なるのはあたりまえ。

ところで

T1:トランザクションA開始
T2:トランザクションAがレコードを更新
T3:トランザクションB開始、レコードを読み取り

T1<T3は何らかの方法で保証したとして、T2<T3てのもちゃんと
同期をとって保証されるようにしたのかね?そうでなきゃ、DB2
使ったとしてもおんなじ障害は発生するよ。
レスを投稿する


ニューススポーツなんでも実況