facebook twitter hatena line google mixi email
★お気に入り追加


  • 1
  • まちがえた。
  • 2001/09/06 14:43
なんだかんだ言ってもやっぱオラクルの方が上ですか?
IBMにもがんばって欲しいんですけどねー。

ここまで見た
  • 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度止まる。そいでデータも壊れる。
AIXマシンでログをIBMにだしても原因がわからない。
2年ほど。数台で。

対して、ORACLE。RAID組んでないHDDの物理破損によるデータ破損は
あったが、それ以外の原因で飛んだ経験はない。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を、というよりDBを勉強してから書き込んでくれよ〜
どこの世界にディスクに書き込まないでコミットするRDBMSがあるんだよ〜
Oracleの場合、Redoログファイルに書き込みが終わるのを待ち届けてからコミットが完了するんだよ〜

ちなみに、ロールバックセグメントはその名の通りロールバックに使用される。
他にも、更新中でコミット前のデータを読むときにも使われるね〜
Redoログファイルはリカバリのときに使用される。
マシンがクラッシュ!したときなんかは、Redoログから更新データを読み込んで復旧するわけだ。

すごいぞOracle!

ここまで見た
  • 142
  •  
  • 2002/09/26 01:55
>>141
>他にも、更新中でコミット前のデータを読むときにも使われるね〜
ごめん
この言葉ちょっと御幣がある

ここまで見た
  • 143
  •  
  • 2002/09/26 07:13
UDBのオプティマイザの感想教えて!
よく他社競合製品の比較で、某社のDBのオプティマイザはヒントが
必要とか、某社のDBのオプティマイザはヒント文化だとか書かれて
いるんだけど、ヒントの実装が無いUDBのオプティマイザはそこまで
完璧なの??

某社のDB使い続けているけど、ヒントって本当に困ってどうしようも
ないときしか使わんぞ、オラァ!

ここまで見た
  • 144
  • 131
  • 2002/09/26 09:32
>>141
すまん。思いっきり誤爆した。

折れとしては、不勉強な人の話も含めて、色々聞きたいのだよ。
折れはIBMとも日本おらとも代理店とも関係ない1人のSIerで、単に良い
商品を客に勧めたいだけ。
エンドユーザーがどのような視点で商品選定を悩んでいるのか知りたい。
その点、>>135のような話も、信じるかどうかはともかくとして興味深い。
それとか、「俺って日本おらの営業に騙されてる?」とか、
IBMの根拠の無いあおり文句とか。そういう話って聞けないかなあ。

ところで、UDBのオプティマイザって、どうよ。

ここまで見た
  • 145
  •  
  • 2002/09/26 11:19
>ところで、UDBのオプティマイザ
UDBは8でもコストベースのみでルールベースはないらしい。

最近はUDBの本も増え、研修も無料、開発CD-ROMもただで、製品値段も激安、
IBMという会社は信頼できるので、個人的にはDB2でやりたい。

でも>>135みたいなことがある。問題に対応できる技術というか能力がお粗末

逆にORAは、スタンダードの値段をあげるは、開発ツールは抱き合わせ販売
するは、インストーラがJAVAで遅いのは我慢できるがツールもJAVA化を推進
するは、サポート、講習会はバカ高いので、さっさと縁を切りたいがRDB
の性能(チューンすればね)、安定性がとてもよいうえに各種ツールが
そろっているのでムカはいってるけど捨てられない。

結果として日本おら社に中指つきたてながら、おら使ってる(とりあえず、
プロジェクトが成功して安定稼動すれば、総予算からみればオラとDB2の
価格差などハナクソみたいなもんですぐ吸収できるから)

 おらであればすぐに開発要員を確保でき、市販本を勉強すれば中小企業
で必要とされる要件内のバッチ処理も入力系もまともなものを安心して構
築できる。


ここまで見た
  • 146
  •  
  • 2002/09/26 11:28
>>143
>ヒントの実装が無いUDBのオプティマイザはそこまで完璧なの?
たしか、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月号に結構くわしく書いてある
例えば
・導入コスト重視ならDB2
・運用が楽なのはオラ
運用なんて毎月の固定だから、トータルでは運用費が安いほうがいいのだが、
初期費用の差が大きすぎるのが痛いね。


ここまで見た
  • 150
  •  
  • 2002/09/28 02:33
おらくる9iってWinXP Homeにインストールできないのね・・・
自宅で勉強しようと思ったのに。

ここまで見た
  • 151
  •  
  • 2002/09/28 10:57
>おらくる9iってWinXP Home
保証はしてないけど、一応できると思うが・・


ここまで見た
  • 152
  •  
  • 2002/09/28 13:50
>>151
そうなの?
なんかインストーラが途中で固まっちゃうんですけど
本についてた120日版だからかな

ここまで見た
  • 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
しかし、DB2のカスよりはよほどまともなオプティマイザだとおもう。
一度DB2で偏った大量データをもつシステムに触ってみなさい。

ここまで見た
  • 162
  •  
  • 2002/10/08 00:58
>>160
煽りじゃなくて真実だと思うよ。実際にAnalyzeの運用をきっちり
把握してなくてレスポンスが悪くなったって騒いでるケースは
多々あるからね。
ほんと、単純なのでいいから自動化オプション付けてくれよって思う。

ただね。>>161の言ってることも事実。
DB2は、オプティマイザが正常判断しなかったときに、統計情報を
いじらなきゃいけないってのも、ちょっとね…

ここまで見た
  • 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だと思ったが。
読み取り一貫性っておらでは言ってるけど、あるタイミングでカーソルを
オープンした後で、別のところから更新・コミットしてもそのカーソルは
(クローズしない限り)更新前の情報が読み取られる。…んじゃなかったっけ?


ここまで見た
  • 166
  •  
  • 2002/10/09 00:53
>>165
ちょと違う。読取専用であれば、新規にカーソルを開くことも出来る。
更新中の行の変更情報をロールバックセグメント(これがおら独自の
アーキテクチャ)に記録してあるため、コミットされるまでは常に
更新前の一貫性のある情報が読み取れる。

ここまで見た
  • 167
  •  
  • 2002/10/09 00:58
>>163
新製品セミナーやDBマガジソ見る限りでは、変わったという情報は無い。
アーキテクチャを変えない限りは>>164のとおりダーティーリードしか
ないし、ANSI的には分離レベルはその実装でOKだからな。

ここまで見た
  • 168
  •  
  • 2002/10/09 21:19
>164-167 ありがとうございます。
そですか、、、やっぱり、、
削除の場合は待たないので、なんか変な感じがしていて、
最新版では何か変わってるんじゃないかと思ったんですが。

でも、これだと24時間運転中のバックアップとか、
バッチ処理みたいなことをする時ってタイムアウトの嵐
なんじゃ。。。 (ノД`、)

やっぱり価格以外はOracleがいいのかも。。。

ここまで見た
  • 169
  •  
  • 2002/10/09 21:48
インデックスつければ良いだけだろ。。。。。
オラからDBに入ったら離れられなくなるってそういうことなのかな?>読み取り一貫性
良いのか悪いのか。。。

ここまで見た
  • 170
  •  
  • 2002/10/10 01:10
>>169
command.comがDB2だとすると、bash、tcshあたりがOracleって感じだな。

ここまで見た
  • 171
  •  
  • 2002/10/10 15:06
17億円所得隠しage

ここまで見た
  • 172
  •  
  • 2002/10/10 22:21
>169
まぁ、そうなんですけど、、、、

更新は見せないけど、削除は見せるというポリシーのなさが気になったもので、、、

オラクルのようにコミット切るまでは一貫して前のデータが見えたほうがスッキリしていいと思うのです。
(もちろん更新前にはロックかけますが、、、)

プログラマー上がりなもので、そういう所って結構気持になるんです。。。
DB2が全然ダメとは思ってないです。誤解があったらごめんなさい。

DB2のシェルから呼べるところなんかはいいと思います。


ここまで見た
  • 173
  •  
  • 2002/10/11 01:01
>>135
今の仕事場では一回も止まったことないよ。
むしろdb2stopコマンドで止まらなかったことが2回ある。(プロンプトが返ってこない)


ここまで見た
  • 174
  •  
  • 2002/10/11 01:20
>>172
教えてクンでスマソけど。
それって、トランザクションが削除行をロールバックしたら
見えなかった行が復活するってことだよね。
だとしたら、インデックスが付いてたら更新中でも読めるって
機能は、場合によってオフにできないとやばいと思うんだけど、
可能?


ここまで見た
  • 175
  •  
  • 2002/10/12 22:37
>>135
10年前からOracle使ってる人っているんだ。
その破損ディスクにのっかてたデータは復元できたの?

ここまで見た
  • 176
  •  
  • 2002/10/13 00:00
>>175
幸いデイリーでバックアップとってたので前日夜までは復元。
経理系のシステムで伝票・請求書などのもとペーパーはあったので、
ユーザーに頭をさげて残業で打ち込んでもらった。
ORALCE6で、2番目に手がけた。
それ以来RAID必須にして、問題がおこったことはない。
(移行ミスで本番データ全件削除という人為ミスをのぞく)

ここまで見た
  • 177
  •  
  • 2002/10/13 14:17
>>90
ばりばりSunです。
DB2は仕様が簡単で、使いやすいと思うが・・・


砂時計アラームタイマー
フリックラーニング
ここまで見た

★お気に入り追加

このページを共有する
facebook twitter hatena line google mixi email
おすすめワード