Oracle? DB2? Symfoware? HiRDB? SQL鯖？

**名無しさん＠お腹いっぱい。** · 03/07/01 20:39

商　用　Ｒ　Ｄ　Ｂ　Ｍ　Ｓ　徹　底　比　較　ス　レ　ッ　ド

**233** · 03/10/05 16:47

きっとOracleでread committedの動きを考えたﾔｼらは、
リードロックでアプリが遅くなるのを恐れたチキンどもばかりのはず。

「おれのcommitが終わってから読んでくれ」という要請に、
Oracleのread committedでは答えられないのだよ。
（カーソルつかえば別だけど）

**名無しさん＠お腹いっぱい。** · 03/10/05 18:47

ほら、初心者がツールの使い方よく理解してなくて
「バグだ、バグだ」って騒ぐことってあるよな。

**名無しさん＠お腹いっぱい。** · 03/10/06 00:15

>>245,246
そのためのSELECT FOR UPDATEだろ？

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

**名無しさん＠お腹いっぱい。** · 03/10/06 00:18

>>247
あるね。

03/10/10 15:31

>>248
Oracle以外だと、そういう文化の人が多いよ

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

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

いちいち設計書に書いてあげる？ンなバカな・・・
そんなことやらないといけない時点で、品質きまっちゃうよ。

**名無しさん＠お腹いっぱい。** · 03/10/11 00:09

>>250
ISOで規定されたそれぞれのトランザクション隔離レベルで保証
されるべきものとそうでないものとの区別ができていないんだな。
read commited で保証されるのは dirty read が発生しないこと。
それ以上でもそれ以下でもない。

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

dirty read と nonrepeatable read との区別がついていないのは
論外。

**名無しさん＠お腹いっぱい。** · 03/10/11 00:20

dirty readって何でつか？

03/10/11 01:29

>>251
単にoracle的解釈だとnon-repeatable readになるだけだろ、あれって。

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

ただ、ANSIに則っているからといって、どうなんだ？といわれるとアレだけど。

03/10/11 01:30

oracleのあのやりかたって、ﾎﾝｼﾒｼﾞだと思うんだけどね。
そう、チキンっていう表現は適切ではないね。

ﾎﾝｼﾒｼﾞが適切。

**名無しさん＠お腹いっぱい。** · 03/10/11 01:49

>>254
え、ここで笑ったらいいの？

**名無しさん＠お腹いっぱい。** · 03/10/11 10:18

>>253
>単にoracle的解釈だとnon-repeatable readになるだけだろ、あれって。

non-repeatable read じゃなくて read committed のことを言って
いるんだと思うが、ANSIの解釈とどう違うって？

03/10/11 23:21

なんかどうどうめぐりになってくる予感がするな。

ちとここまでの流れを整理してみよう。

03/10/11 23:45

それに、ANSIの定義の話になったところで、
せいぜいfjニュースグループ程度の議論しかでけんでしょ。

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

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

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

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

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

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

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

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

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

Oracle　：間に合わなかった報告項目は、割愛
DB2　　：正しい報告を行うためにロック待ち

03/10/11 23:52

Oracle　：間に合わなかった報告項目は、割愛
DB2　　：正しい報告を行うためにロック待ち

　↓

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

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

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

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

結論：
read committedの解釈は現状２つにわかれている。
性能をとるなら、Oracle的解釈
正しさをとるなら、DB2的解釈

03/10/11 23:54

（正誤表）

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

03/10/11 23:56

また、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
と書いた場合になります。

03/10/11 23:59

なんでこんなにくどく書くかというと、
最近、基幹系のアプリ障害でこういうケースがあったからです。

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

仲裁するヤツの立場にもなれっつーのよ、ホント。

**名無しさん＠お腹いっぱい。** · 03/10/13 02:01

あーあ、だからちゃんと勉強しとけって言ってるのに。

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

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

ところで

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

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

**NAME IS NULL** · 03/10/13 17:21

並行して複数のトランザクションが走る場合、それらトランザクション間に
依存関係は存在しないのが大前提。つまりどのトランザクションが先に
完了したとしてもその結果が正しいといえることが必要。その前提のもと
では、トランザクション間の関係はISOが定めた4つの隔離レベルのみを
考えれば十分。
>>233が>>258-262で書いたケースでは、「報告役」トランザクションと
「障害調査員」トランザクションとの間に依存関係が存在する。つまり、
これらのトランザクションを並行して実行するべきではなく、「報告役」
トランザクションの完了を待って「障害調査員」トランザクションを開始
するようジョブ管理を行うべきであった。
そのように設計されていれば、OracleかDB2かにかかわりなく、どちらも
期待通り動作したはず。
そのジョブ管理をDBMSの暗黙のロック機構に期待したのが誤り。

**NAME IS NULL** · 03/10/14 22:45

正直、使う側で何とかすれば、どのDBでもなんとかなるだろ。

**NAME IS NULL** · 03/10/16 07:08

>265
禿同。

まあ、自製品への囲い込み戦略が上手すぎたが、
実働レベルの人間のスキル育成に大成功しているOracleを選択するというのが
人材確保の点では、現時点では一歩優位だろう。

しかし、「Oracle以外はNG」という、頭の悪いエンジニアが多いのも困ったものである。
ある意味、一時のSolaris信仰に近いもんがあるように思う。
可哀想にLinuxがWindowsへ放った流れ弾があたって、SunWorldが廃刊だが（ｗ

Synforware、HiRDBは知らんが、
FとHがシステムの面倒を見てくれるのが前提だ。
彼ら以外が使うための下地（情報整備、手近なエンジニア）はない。。

SQLServerとDB2は必ず残るし、遭遇する機会も多い。
身に付けておいて損はない。
特にDB2は、IBMにより基幹系システムのSIで使用されており、
製品自体の寿命は長いだろう。
悪くてもAS/400のような感じの生き残り方はするだろう。

DBエンジニアを自称するなら、
少なくともOracle、SQLServer、DB2の中から最低２科目は選択必須科目だ。

ベンダーに催眠をかけられてはいけない。
根幹的な技術はどこも既に枯れている。
ある意味、RDBベンダーは持久戦に突入しているし、
５年後にどこが手を引いていてもおかしくない。

Oracleにしたって、RDBMSそのものの利益は悪化している。
9iと同じく、10ｇも奮わないだろう。

03/10/18 21:29

>>263
それだと逆もまた真なり、にならないよ？
自・他の関係は、ひっくり返すと他が自になる。

ロック制御＝実装の問題、それはあたりまえのこと　違ってて当然。

論理として、逆がなりたたないと、やっぱそれはおかしい。

ちなみに、T1/T2/T3の書き方、
先行トランザクションのレコード読み取りのタイミングもかかないと不公平だよ。

あと、同じ障害は生じない。

03/10/18 21:46

>>263
Oracle風の解釈を勉強するからそういう考え方になるだけだって。

-transaction1-
set transaction read write, read committed
select column1 from table1
update column1 from table1
commit work

-transaction2-
set transaction read only, read committed
select column1 from table1
commit work

oracleだと、この程度のトランザクションを守る分離レベルがないんですよ。
DB2だときちんと待って最新とってくれますし、ヒント句書いたらOracle風にもできます。

わかってて返答書いているのかな？

なぜ分離レベルで、ノンリピータブルリードを防げるようになっているか？
ってわかってますか？
（これはisolation level repeatable readの話だからそれますけどね）

まず、
・他のトランザクションに影響をあたえない
・コミット
まず、この言葉の意味を考えてみてください。
影響とは？トランザクションとは？コミットとは？

ものの定義をあまりにも記号化して考えていませんか？

**NAME IS NULL** · 03/10/18 21:48

あれ？？
書き込みボタン押したときにブルースクリーンになってWindowsクラッシュしたのに、
書き込みできてるよ。

D特性あるんだね(笑)

267と268はｼﾞｻｸｼﾞｴﾝで2人いるわけではなく、同一人物です

03/10/18 21:52

>>265
漏れは>>268程度のSQLの組み合わせをまもるために、
ノード間排他なんか導入する気起きないですよ。
例えば、秒間数百トランザクションの世界で、ノード間うまく排他とるの難しいですよ。

# 排他テーブルに常にupdateしてやる、なんていうSQLをはじめに打って、
# それから読ませる、みたいなことで逃げたこともありますけどね・・・

**263** · 03/10/19 18:11

>>267
>それだと逆もまた真なり、にならないよ？

何が言いたいのかさっぱりわからん。
もともとオマエが>>233で書いたのは、Oracleのトランザクション分離レベル
read committed が正しく read committed として機能しないということだったろう？
それに対して、ANSI/ISOで規定するトランザクション分離レベルに対する理解が
不足していて、DBMS固有の機能との切り分けができていないんじゃないかという
ツッコミ>>251があったわけだ。
んで、今度はANSIの定義は関係ないと言い出して>>258-262で長々と書いた
けれども、内容を聞いてみれば案の定>>251の指摘の通りだったし。

>先行トランザクションのレコード読み取りのタイミングもかかないと不公平だよ。

不公平って何が何に対して？
先行トランザクションの読み取りタイミングが変わることでなにか結果に影響
するならば考慮する必要もあるだろうが、なにか変わるのか？

>あと、同じ障害は生じない。

read committed なら、T3<T2の場合はトランザクションBはトランザクションAの
更新結果を読むことができない。ここで主張していた「障害」はそういうこと
だったろう？

>>268
>Oracle風の解釈を勉強するからそういう考え方になるだけだって。

ここで言っている「解釈」ってのは、ANSIで規定する read committed に対する
解釈ってことで良いよな？なら、ANSIの定義を挙げて、どの部分に違反して
いるか示してみろよ。それではっきりするから。

>oracleだと、この程度のトランザクションを守る分離レベルがないんですよ。
>DB2だときちんと待って最新とってくれますし、ヒント句書いたらOracle風にもできます。

んだから、read committed で「きちんと待って」くれなければならないなんて
キマリは無いの。DB2がそういう実装だったからといって、すべてがそうだと
思い込んだオマエが勉強不足なだけ。そもそも read committed 以上の分離
レベルでの話をしているのに、他トランザクションの未commit更新後データを
「最新」と考えるのがおかしい。
しかも既に書いたように、オマエの言う「障害」はDB2でも防げない。
オマエもそうだしその設計者もそうだが、そういうところがよくわかっていない
のに設計なんかするから、変な障害で苦労するんだよ。

もう一度書くけど、トランザクション分離レベルってのはトランザクション間の干渉を
防ぐためのもの。オマエが期待しているのは、あるトランザクションの結果が別の
トランザクションの結果に依存していて欲しいということだから、もともとお門違いな
ワケ。

**NAME IS NULL** · 03/10/19 19:31

SQL> SELECT COUNT(*) FROM 漏れのことが好きな女;
SELECT COUNT(*) FROM 漏れのことが好きな女
*
1行でエラーが発生しました。
ORA-00942: 表またはビューが存在しません。

｡･ﾟ･(ﾉД`)･ﾟ･｡

**NAME IS NULL** · 03/10/19 21:14

>>272
スレ違い
↓こっち池
http://pc2.2ch.net/test/read.cgi/db/1057289721/

**NAME IS NULL** · 03/10/20 08:14

というか、テストケースぐらいだしたら？

**NAME IS NULL** · 03/10/20 22:53

マトリックスのネオは、oracle使い
Nステでやってた、「答えをオラクルの中で探すが見つからない・・・」

**NAME IS NULL** · 03/10/20 23:46

神託だろ
宗教がかってるんだし

**NAME IS NULL** · 03/10/21 00:39

>>267-268
ｵｫ、ｽｹﾞｪ。
君、ショボ過ぎる。DB2が泣くぞ。
とにかく今は、勉強に専念しろ。語るのはその後だ。

**277** · 03/10/21 01:25

>>258-260
ｵｫ、ｺｯﾁﾉﾎｳｶﾞ、ﾓｯﾄｽｹﾞｪ。

クエリーの読み取り一貫性とトランザクションの原子性が
勝手に融合されて未知の理論にまでエスカレーションしとる。

ｺﾘｬ、Oracleは号泣するぞ。

**NAME IS NULL** · 03/10/21 03:26

Interbaseも仲間に入れてやってくれ

**NAME IS NULL** · 03/11/08 18:19

で、結局どのDBMSが勝ったの？

**NAME IS NULL** · 03/11/08 21:16

>>280
ALL　END　（゜∀。）ｂ

**最強RDBMS** · 03/11/09 04:29

おれ

**NAME IS NULL** · 03/11/14 02:08

林家ペーの脳内DBに決まりました。
誕生日検索トランザクション数No.1

**NAME IS NULL** · 03/11/25 12:03

今月の DB Magazineで Oracle 10g 特集！やっぱ最強
http://www.seshop.com/detail.asp?pid=4719

**NAME IS NULL** · 03/11/26 14:27

正規表現がやっと使えるようになった程度のDBに最強を名乗ってほしくはないのだ。

**NAME IS NULL** · 03/11/30 20:04

>>285
ほう。Oracleより遥かに良いDBがあるのか。利点も含めて教えてくれよ。

**NAME IS NULL** · 03/11/30 20:30

>>285-286
いや、もういいから、そういうのは。

**NAME IS NULL** · 03/11/30 21:47

>>287
だってそういうスレだし。

**NAME IS NULL** · 03/11/30 22:48

>>288
だって住人の平均年齢が高そうで煽り合いが盛り上がらないし。

**NAME IS NULL** · 03/12/03 01:32

>>285が思う最強DBってなに？
あおりでなくて

**NAME IS NULL** · 03/12/03 23:56

>>290
用途によって最強は変わるだろ。
各DBが、各分野で最強になりえると思う。
Oracle使っときゃ間違いないとか、そういうことではない。

**NAME IS NULL** · 03/12/07 16:35

>>290
と言う事は、君はOracle10gが最強だと言うのだな。

**NAME IS NULL** · 03/12/07 23:28

IMS

**NAME IS NULL** · 03/12/12 01:10

>>284
Oracle 10g!?
うわっそんなの出る（出た？）のかー！？

暫くＤＢマガ買ってなかったからなー・・・時代に乗り遅れちまった。
つーか、９ｉを業務で使ってるところを見たことがないのだが。
最高8.16

オラクル突っ走っとるなぁ・・・。

**NAME IS NULL** · 03/12/13 03:03

>>294
いや、8.1.6は中途半端だろ。

**NAME IS NULL** · 03/12/13 12:45

8.1.7なら解るな。

**NAME IS NULL** · 03/12/18 20:31

W2kに初対応じゃなかった？＞8.1.6

**NAME IS NULL** · 03/12/21 01:06

結局は適材適所なんだろうけれど、
各種RDBMSの得手不得手を冷静に比較しているサイト、もしくは本ってないですか？

**NAME IS NULL** · 04/01/14 18:19

オラクルって資格を変えて追加試験料取ったり抜き打ちライセンス確認(実はそう見せかけた営業)したりしないと駄目なぐらい落ちぶれたって本当？

**NAME IS NULL** · 04/01/15 21:50

>>299
ええ本当です。
オラクルのシェアは、オープン系では日本ではたったの61%で１位、オラクルは参入してなく
IBMが富士通が好きなだけぼったくれるメインフレームの市場を含めても、46%ぽっちで１位なのですから。

http://www.atmarkit.co.jp/news/200312/12/oracle.html
　IDC Japanは、2002年の国内データベース管理システム市場動向を発表した。国内ベンダ別RDBMS／ORDBMS市場では、ソフトウェアライセンス
とサポート料から成る売上金額シェアで、オラクルが46％を獲得、2年連続で1位になった。2位はIBM／Informixの17.9％、3位は富士通の13.6％、4位
はマイクロソフトの9.7 ％、5位には4.7％で日立製作所が入った。
　メインフレームを除く、UNIXとLinux、Windowsを合わせたオープン系プラットフォームに限れば、オラクルは国内RDBMS／ORDBMS市場で、1位となる
61％のシェアを獲得した。内訳はUNIX市場で68.4％、Linux市場で54.2％、Windows市場で48.3％となっている。

**NAME IS NULL** · 04/01/16 22:31

日本オラクルってすごいよね。
世界でもこれだけシェアとれてるところって他にないよね。

**NAME IS NULL** · 04/01/17 00:24

シェアと値段と機能がこれほど釣り合っていない分野も珍しいけどな…

**301** · 04/01/17 01:10

(日本人は右へ習えが大好きですね)

**NAME IS NULL** · 04/01/24 16:03

WebSphereやRedbrickみたいに、他の製品の一部品としてが使われることが多くなるかな

**age** · 04/02/15 21:54

>>299
そんなの来たことないですが何か？

**NAME IS NULL** · 04/03/01 19:27

あげ

**NAME IS NULL** · 04/04/17 22:29

何を選んだところで、とんまなDBAがおかしな設計して
性能を十分に発揮できないようなシステムになるんだから
どうだっていいじゃん。

**NAME IS NULL** · 04/04/19 03:47

能力のある奴が作れば、MySQL3を使おうが、まともなものが出来上がるからな。

**なんだかなぁ。。。** · 04/06/22 21:20

エンドユーザにとってＤＢＭＳはあまり重要ではないねぇ。要するに業務が支障なく動けばエエねん。

**NAME IS NULL** · 04/06/24 02:24

そそ、アクセスでもいいのよ

**NAME IS NULL** · 04/07/05 18:34

適材適所。

**NAME IS NULL** · 04/11/08 22:36:14

MySQL って機能的には良いんだね。
問題は分け分からんサポートくらいか。

はてなダイアリー - mir the diver
http://d.hatena.ne.jp/mir/20040917

**ｺﾋﾟﾍﾟ推奨** · 04/11/09 16:56:42

●２ちゃんねるは創価学会のベンチャーだった！●

1 ：名無しさん＠そうだ選挙に行こう：04/07/11 16:42 ID:DfqA2A8A
●２ちゃんねるは創価学会のベンチャーだった！●
中尾嘉宏　創価学会札幌支部幹部、２ちゃんねるのサーバー管理者
ピンク２ちゃんねる代表　前科２犯児童買春斡旋、マルチ詐欺
ピンクちゃんねるで創価学会札幌支部にお布施、
エロサイトの資金で池田大作先生も潤い、喜ばれているそうです。

http://money3.2ch.net/test/read.cgi/venture/1089531720/l50

**NAME IS NULL** · 04/11/18 23:42:39

>>310
アクセスじゃだめだろ。

Jet というならわかるが。

**NAME IS NULL** · 05/03/06 21:08:55

今までの話を総合すると、HiRDBが最強ということでFA。

**www.geocities.jp/shouhishahogo/** · 05/03/06 21:56:45

汎用機の場合、Ｉ／Ｏセンターを作っておられるユー
ザーもいます。
・伝票入力（インプット）のキーパンチャー
・帳票出力（アウトプット）の操作員

　でも、昨今は、インプットは現場で、アウトプットは
印刷屋さんへの移管（アウトソーシング）が多いようで
す。

**NAME IS NULL** · 05/03/10 09:54:42

>>315
それってHP-UXだけ？

ちゃんとHI-UXで動くんだろうな！

**NAME IS NULL** · 05/03/10 11:30:43

>>312
PosgreSQLやMySQL系のようなオプソ系DBのほうが標準への準拠度が高かったり、
新しい機能の実装が早かったりしますね。
Oracleは互換性を大事にするのはいいけどいい加減長さゼロの文字列の扱いを何とかして欲しいものです。

ただそのリンク先のプログの記事は突っ込みどころ満載、引用に使うにはどうかと。

**NAME IS NULL** · 05/03/11 01:27:36

モントランって何だか知ってる人いますか？
ＤＢに関することだと思うんですが
さっぱり何のことか分かりません。

**NAME IS NULL** · 05/03/11 01:45:51

すいません
質問させてください
Linter（リンター）っていうＲＤＢをご存知な方いますか？
なんでもロシアで作られた高性能ＤＢエンジンらしんですけど…

http://money3.2ch.net/test/read.cgi/employee/1088916963/l50

このスレの552って奴がが610で言ってたので
気になって調べてみたんですが
組み込みシステム用のＤＢらしく
一応プラットフォームはＤＢ２並に選ばないみたいなんですが、
これは社内システムに使えるのかと疑問

↓ちなみに日本の代理店サイト
http://www.linter.jp/

誰か知ってる方いますか？

**NAME IS NULL** · 2005/05/21(土) 17:37:15

遅レスですが、臨たーは
ソニエリとかに採用されているので
それなりに有名だと思います。

ただ基本的に日本では組込系向けで売っているので
社内システムに・・といってもサポートしてくれるんでしょうかね・・

**NAME IS NULL** · 2005/05/22(日) 22:30:21

OracleのRACって、MTTRを短くするためのものなのか・・・・？

**NAME IS NULL** · 2005/07/29(金) 05:59:01

2年で322しか行かないとは

**NAME IS NULL** · 2006/01/27(金) 00:28:43

SQL Server 2000 にデータを持つ Webアプリケーション (IIS, ASP) を
DB2 UDB 用にポーティングする話が持ち上がりそうです。

DB2 UDB って、SQL Server 2000 のようにテーブルを返す関数を定義できますか?
ODBCを使いたくないですが ADO (OLEDB) 使用可能でしょうか。

**NAME IS NULL** · 2006/03/32(土) 00:09:49

>>322

RAC なんて使うのが間違ってる罠。

**NAME IS NULL** · 2006/04/22(土) 13:55:03

保守age

**NAME IS NULL** · 2006/09/10(日) 17:04:02

えーと、つまりどれでも一緒って事で AC?

**NAME IS NULL** · 2006/09/18(月) 15:27:32

チンコウェア最強！！

**NAME IS NULL** · 2006/09/25(月) 01:55:55

チンコage

**NAME IS NULL** · 2006/10/14(土) 11:08:55

DB2 9.1になっても何も変わってないな。

http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.admin.doc/doc/r0005274.htm

表 202. ロック・タイプの互換性保持されているリソースの状態
要求されている状態なし IN IS NS S IX SIX U X Z NW W
なし yes yes yes yes yes yes yes yes yes yes yes yes
IN yes yes yes yes yes yes yes yes yes no yes yes
IS yes yes yes yes yes yes yes yes no no no no
NS yes yes yes yes yes no no yes no no yes no
S yes yes yes yes yes no no yes no no no no
IX yes yes yes no no yes no no no no no no
SIX yes yes yes no no no no no no no no no
U yes yes yes yes yes no no no no no no no
X yes yes no no no no no no no no no no
Z yes no no no no no no no no no no no
NW yes yes no yes no no no no no no no yes
W yes yes no no no no no no no no yes no

これを理解してプログラムできるのかな。

**NAME IS NULL** · 2006/10/14(土) 11:23:39

そのロック互換性を独自のオプションで回避しろというのだから
狂気でしょう。

こてこてのオプション読込専用カーソル書込可能カーソル
WITH RR (or default isolation RR) S U
WITH RR USE AND KEEP SHARE LOCKS S S
WITH RR USE AND KEEP UPDATE LOCKS U U
WITH RR USE AND KEEP EXCLUSIVE LOCKS X X
WITH RS (or default isolation RS) S U
WITH RS USE AND KEEP SHARE LOCKS S S
WITH RS USE AND KEEP UPDATE LOCKS U U
WITH RS USE AND KEEP EXCLUSIVE LOCKS X X

それでもDB2を売り付けるのだから営業はスゴいよ。

**NAME IS NULL** · 2006/10/15(日) 03:26:26

>>325
RACはボッタクリ用のおいしいオプションだろｗ
RAC担当させられたエンジニアは死ぬことになるけどな。

**NAME IS NULL** · 2006/10/15(日) 10:00:36

RACの仕事してるのか？
いいないいな。
おれも入れてくれヨ。

**NAME IS NULL** · 2006/10/15(日) 16:35:40

http://ugya.tripod.com/deadlock/etc/db2locks.gif

**NAME IS NULL** · 2006/10/15(日) 18:36:16

>>332

10g SE なら RAC は標準なのだが。
どのへんで死ぬことになるのか教えてくれるかな。

**NAME IS NULL** · 2006/10/17(火) 01:53:16

>>335
藻前ボラクルのマーケだろｗ
おまいらが嘘ばかり言うとるから死ぬことになるんやろうがボケカス

**NAME IS NULL** · 2006/10/17(火) 06:43:06

10gSE RACってトータルで4CPUしか使えないし。

**NAME IS NULL** · 2006/10/17(火) 08:42:20

>>336

そういうのを FUD と言うのだよ。
具体的な事例を挙げろと言ってるのだ。

俺が管理しているDBはほとんど問題が起こってない。
0件ではないが、数ヶ月に1回サポートに聞くことが発生する程度。

同時接続数も100くらいで、データ量も200GBくらいしかないからかな。

**NAME IS NULL** · 2006/10/17(火) 14:44:51

>>338
ｋｗｓｋ

**NAME IS NULL** · 2006/10/17(火) 18:38:49

>0件ではないが、数ヶ月に1回サポートに聞くことが発生する程度。

いや、それは品質基準としてどーなんだろう？

**NAME IS NULL** · 2006/10/17(火) 19:47:02

>>338
>俺が管理しているDB

ってお前DBAかよｗ
そのくせマーケ用語（FUD）使って、本当にお前が管理してんのかよ！
本当ならどんなシステムかもっと詳しく言ってみろよ
ボラクル社員だってバレバレだなｗｗ

**338** · 2006/10/17(火) 21:11:46

ん?
俺はオラクル社員じゃないよ? DBAだと悪いのか?
DB2 も SQL Server も使うよ?

Oracle が嫌いだったら使わなければいいだけのことだろう。
要件に合った製品選択もろくにできないような使えない奴は
相手にしてもしょうがないが。

**338** · 2006/10/17(火) 21:13:33

>>332 で言うところの
「RACを使うと死ぬことになる」という事例が知りたいんだよね。

しょうもない罵倒はただのゴミだ。
大人だったら論理的な話をしよう。

**NAME IS NULL** · 2006/10/17(火) 22:01:27

RACに限らず、一般的なクラスタウェアをつかったHA構成でもいえるんだけど、
導入時に入念にテストやっても、いざっていう時にちゃんとサービスのフェイルオーバ・テイクオーバできるかどうか
不安が付きまとうもんなぁ。

**NAME IS NULL** · 2006/10/17(火) 23:12:56

>>342
>DBAだと悪いのか?
>DB2 も SQL Server も使うよ?

そんなDBAいねーよ。
嘘ばっかり言ってねーで、お前の管理してるシステムを詳しく言ってみろよｗ

>要件に合った製品選択

DBAに製品選択権はねーよｗｗ

**338** · 2006/10/17(火) 23:33:58

>>345

はぁ?

俺は主にカード決済系の会員管理DBを扱うことが多いよ。
IBMのサーバが強いところなら System p5 + DB2 だし、
何も指定がなければ慣れている HP + Oracle のパッケージクラスタを使う。

詳しくは言えないが、大きいところでは
会員数160万人程度を毎日洗替しているDBもあるよ。

DBA の定義がお前のところとは違うみたいだな。
そろそろ「死ぬ」という事例を教えてくれないか。
何もないんだったら首吊って死ね。