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


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

ここまで見た
  • 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は仕様が簡単で、使いやすいと思うが・・・


ここまで見た
  • 178
  •  
  • 2002/10/13 23:19
どーでもいいけど DB2 情報少ないよな。

ここまで見た
  • 179
  • ど素人
  • 2002/10/13 23:34
 DB2に関してロックの問題があちこちのスレで取りざたされてるけど、それ
はOLTPなら問題だけど、DSSなら問題ない?

ここまで見た
  • 180
  •  
  • 2002/10/13 23:35
oracle6ってオンラインバックアップできなかったっけ?

ここまで見た
  • 181
  •  
  • 2002/10/14 00:06
>>179
問題の原因は、ロックの行が多くなると表ロックにエスカレーション
され、意図しない行までがロックされることと、更新中の行は他が
アクセスできないという点にある。
前者はDSSで陥りやすく、後者は並列でトランザクションが走る場合に、
OLTPならレスポンス低下、最悪デッドロックを招き、DSSであれば
バッチが終わるまで延々と待ちの状態になる可能性がある。

当然、プログラムを組むときは、その点を注意する。

ここまで見た
  • 182
  •  
  • 2002/10/14 01:05
>>180
NetWareサーバで、インスタンスを停止してデータ領域をまるごとやってました。
でもたまにインスタンスが停止しなくてバックアップ失敗があたり前になったり
してたから、当時から5連装テープチェンジャーでDATにおとしてました。

ここまで見た
  • 183
  •  
  • 2002/10/17 10:42
>>182
それって>>180の質問の答えになってるんだろうか?

ここまで見た
  • 184
  •  
  • 2002/10/25 22:39
>>182
それは、コールドバックアップですね。

ここまで見た
  • 185
  •  
  • 2002/10/26 01:31
>>184
そのとおりです(^^;)
最近開発以外やってないので、言葉を忘れてました


ここまで見た
  • 186
  •  
  • 2002/10/27 15:58
>>185って>>135なんだろ。
そんな基本的なDB用語もわからんで、よくDB2の批判できるな。
135で書込んだ内容も怪しいもんだ。

ここまで見た
  • 187
  •  
  • 2002/10/27 22:34
単にOracleに慣れててDB2に慣れてないで評価しただけだろ。
結局は慣れよ慣れ。
慣れてれば使いやすいわけよ。何だって。


ここまで見た
  • 188
  •  
  • 2002/10/29 00:12
>>187
慣れてる奴はコールドバックアップなどやらんと思うが?

ここまで見た
  • 189
  •  
  • 2002/10/29 00:59
>>188
なれではない。運用次第。
社内の夜間活動しないサーバーでは、実施しているケースもある。

ここまで見た
  • 190
  •  
  • 2002/10/29 20:36
>186
哀BMの人?

ここまで見た
  • 191
  •  
  • 2002/10/30 23:31
バックアップはそのシステムに合わせた方法を
行うことには胴衣。

しかし135(185?)がOracleに慣れてるようには・・・?

ここまで見た
  • 192
  •  
  • 2002/11/01 20:22
このスレさ〜面白いけど板違いのような・・・。
>>151 確かにできないよ。俺もインストーラが止まったことあり。

ここまで見た
  • 193
  •  
  • 2002/11/03 23:41
>>192
インストールの不具合は、ディレクトリ階層が深すぎるか、
Javaを先にインストールしてる場合、CLASSPATHが誤爆している
可能性がある。

>>191
100台もマシンがあれば、1人で運用してる訳でも無いだろう。
135(185)が直接オペレーションをしているかどうかは置いといて、
135(185)の運用環境における客観的な事象として、落ちる・落ちないの
話は見るべきものがあるだろう。
# 信じるかどうかは受け止める側次第だが。

ここまで見た
  • 194
  •  
  • 2002/11/04 12:44
>>193 いや深くないよ。2階層ぐらいだから。homeは駄目でもprofessionalでは同じ手順で問題ないし。

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

★お気に入り追加

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