1read 100read
2011年10月1期データベースOracle>>>>>>SQLServer TOP カテ一覧 スレ一覧 削除依頼
・ 次のスレ
【pc系鯖】 oyster鯖 争奪戦 【新鯖獲得!?】
Oracle 儲かって儲かって、うはうは
oracleの信憑性について
【DBMS】 HiRDB


Oracle>>>>>>SQLServer


1 :03/07/02 〜 最終レス :10/10/22
だろ

2 :
なにが?

3 :
価格

4 :
オッス!おらオラクル!

5 :
不覚にもワロテしまった…
何でこんな…鬱山車農

6 :
良スレage

7 :
価格なら逆だな。
性能等なら正しいが。
用途が違うよ

8 :
>>7
>用途が違うよ
違うのか?

9 :
価格なら逆???????????

10 :
信頼性、セキュリティ性、安定性、堅牢性では明らかにOracleの方が勝っているな。

11 :
脆弱性の数で言えば
Oracleの方が多いんだけどな。

12 :
>>11
ソースキボン?
誰が数えた数なんだよ。

13 :
なぜ、unbreakable をアピールしているのか?
oracleってそんなにこわれやすいの?

14 :
Linux上で使うからだろう。
Sunに払う金あったらうち(Oracle)にまわせと。

15 :
>>12
OracleとMSが発表しているセキュリティ情報みればわかるよ。
2003年に発見された SQL Server の脆弱性はゼロ
Oracle9i は4つか5つほどかな。
2002年も同様にOracleの方が多い
Oracle使ってたら当然わかると思うんだけどなw
SQL Server だと大げさに取り上げられて
Oracleだとそうでもないからみんなホッとしてるよw

16 :
SQL Serverデベロッパー版 値下げです
ビックリするよマジで
http://www.microsoft.com/japan/presspass/detail.aspx?newsid=1632
開発環境が入ってないとダメなのかな?

17 :
デベロッパー版を値下げされてもな・・・

18 :
>>16
開発環境入っていないとダメってどういうこと?

19 :
今日このことを知らずに買ったやつは
大泣きだな。

20 :
>>19
前の価格で開発目的で買うならMSDNに入った方が安くつかない?

21 :

 |  オラクルオラクウオラゴクウ!をやっていいですか?
 \____  ________________/
    /||ミ  V
   / ::::||
 /:::::::::::||____
 |:::::::::::::::||        ||
 |:::::::::::::::||│ /   ||
 |:::::::::::::::|| ̄\   ガチャッ
 |:::::::::::::::||゚ ∀゚)─ ||
 |:::::::::::::::||_/    ||
 |:::::::::::::::||│ \   ||
 |:::::::::::::::||∧ ∧∩ ||
 |:::::::::::::::|| ゚∀゚)/.  ||
 |:::::::::::::::||∧ ∧∩ ||
 |:::::::::::::::|| ゚∀゚)/. ||
 |:::::::::::::::||    〈.  ||
 |:::::::::::::::||,,/\」.  ||          …
 \:::::::::::|| ̄ ̄ ̄ ̄                        ∧_∧
   \ ::::||                       ___\(・∀・  ) < お前ら、誰ですか?
    \||                       \_/⊂ ⊂_ )
                              / ̄ ̄ ̄ ̄ ̄ ̄ /|

22 :

                \ │ /
                 / ̄\   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
               ─( ゚ ∀ ゚ )< オラ悟空オラ悟空!
                 \_/   \_________
                / │ \
                    ∩ ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄\∩ ∧ ∧ \( ゚∀゚)< オラ悟空オラ悟空オラ悟空!
オラ悟空〜〜〜!   >( ゚∀゚ )/ |    / \__________
________/ |    〈 |   |
              / /\_」 / /\」
               ̄     / /
                    ̄

23 :
>>18
ライセンス上の問題です
たしかデベロッパー版は通常のデーターベースとしての
継続利用ができなかったと思ったので

24 :
>>15
SQL鯖の脆弱性はOSの脆弱性とと一体化してるから
実態は分からんと思われ。

25 :
>>16
Windows2003とVS.Netがこの値段ならびっくりだけどな。
この2つが無いと実質使えないし、実本番に使えない
開発者ライセンスだけが安くてもねぇ。

26 :
ばれなきゃ大丈夫。

27 :

28 :
     ∧_∧  ∧_∧
ピュ.ー (  ・3・) (  ^^ ) <これからも僕たちを応援して下さいね(^^)。
  =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
  = ◎――――――◎                      山崎渉&ぼるじょあ

29 :
RBSでロックをごまかしているRDBMSの何が最強なものか
Oracle、テメーのことだ

30 :
使われてるシステムの規模が段違いなので、単純比較はどうなのか?

31 :
DB2も結構よさげ。

32 :
1GBを超えるデータのインポートが出来ませんが・・・

33 :
みのるの超流行語では、
流行語大将になりそうな言葉を紹介していきたいと思います(^‥^)。
オヒャヒャ           僕、みのる様が使用している笑い方です。
(^‥^)          僕、みのる様が愛用している顔文字です。
トライブット        僕、みのる様のサイトがある所の偉い所の人。
みのる様ファン倶楽部    会員数がもう100億人超えた超えてます。
マヨネーズ         僕様の大好きなマヨネーズの一種です
スペシャルギニア      世界共通語で、誰でも分かります
応援ありがとう!!!    皆が僕様を応援してくれるから、僕様も返信します
           俺様の素晴らしいサイト↓
         http://minoru_god.tripod.co.jp/
   データーべス板のオタクやアホやバカドモはこっちに来て勉強しな
                    BYE みのる様

34 :
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

35 :
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

36 :
>>29
ごまかしてないぞ

37 :
SQLserverは、Oracleのシステムをマイクロソフトが購入して作ってると聞く。
と言うか、セッション数が100を越え、データ更新で100以上になってくると
SQLserverとかは、表単位でロックを掛けるらしいからやっぱ大規模なシステム
なんかになるとOracleだけが対応できる見たい。
トランザクションが行単位でどんなにやっても効いてるのは、Oracleだけだそうな。

38 :
>37
知っている言葉を並べれば良いという訳ではないぞ

39 :
>>37,38
Oracleはロックエスカレーションしないというのは正しい。

40 :
オラクルにはそもそもそんな機能ないからな

41 :

42 :
>>40
無知は発言すんなよ

43 :
MSのほうって行ロックできるようになった?(⌒V⌒)

44 :
>>37
MSがかったのはさいべーすだしょ。しかも古いやつ。ようはいまのさいべーす
と兄弟なんだ。もちろんさいべーすはぐんぐん進化し、MSはあのていたらく
できのいい兄とおまえの関係クリソツだ(⌒V⌒)

45 :
>>44
兄弟というよりも親子か。いやクローンか
できのいい俺と羊のドリー関係クリソツだ(⌒V⌒)

46 :
さいべーすがぐんぐん進化?

47 :
>>40
機能がないのではなくて、そもそもロックエスカレーションの必要がない。
行ロックのフラグが行ヘッダにあるから。
何行でも行ロックできる。
ほかのDBはロックを管理する領域が別にあって、そこがあふれそうになったらロックエスカレーションしてロックの総数を減らす必要がある。

48 :
ロックエスカレーションなんてかっこいい名前つけてるが、
そもそもそんなの機能として言わなきゃいけないことが恥ずかしいこと。

49 :
この板に常駐しているOracle関係者うぜぇ
赤すいせいか?山田せいしか?

50 :
>>49
MS関係者でつか?

51 :
>>50
みらくるが嫌いなだけ

52 :
>>49
Sybase厨もなかなか良い味出してるよな。

53 :
MS使いの人でてきてよー

54 :
スレタイが意味する所は「Oracleが進化してSQLServerになった」ですよね?

55 :
MS SQL Serverの良いところは
ある程度までの規模なら、メンテフリーで
パフォーマンスも良好な所。

56 :
すみません。オラクルにできて SQLserver にできないことって何ですか?

57 :
ロックエスカレーションのメリットは
ロックに必要なりソースが少なくなることと
ロックの解放が早くなること

58 :
>56
他OSでの動作

59 :
>56
インストール中に飯を食べる

60 :
>>56
FOREIGN KEY XXXX REFERENCES YYYY(ZZZZ)
ON UPDATE SET NULL ON DELETE SET NULL
~~~~~~~~ ~~~~~~~~
なんでこんなこともサポートされてないんだYO!!

61 :
>60
実アプリではこんな使い方しねーよ
生粋のOracle社員の意見だな

62 :
>>60
( ・∀・)つ〃∩ ヘェーヘェーヘェーヘェーヘェーヘェーヘェーヘェーヘェーヘェーヘェーヘェー

63 :
>>61
何故>>60がOracle社員のカキコに見えるのか意味不明

64 :
>63
おまえは信者

65 :
>>60
どんなときに使った?

66 :
>60の構文ってどういう意味なんでしょうか。
外部キーの値設定?
Oracleを知らない厨に教えてくだされ・・・

67 :

68 :
これを見ると、SQL Server が Oracle を越えるのは無図化しそう
デルとオラクル、両社製品を組み合わせて提案・提供する共同営業体制を確立
http://linux.ascii24.com/linux/news/today/2003/09/19/646030-000.html
日本オラクル、営業支援プログラムのサービスでMIRACLE LINUXを配布
http://www.zdnet.co.jp/enterprise/0309/17/epn09.html
国内データベース製品シェア1位はオラクル
http://www.mainichi.co.jp/digital/computing/archive/200309/05/5.html
ミラクル・リナックス、ネットワーク・アプライアンス社と大規模Linuxシステムで提携
http://linux.ascii24.com/linux/news/today/2003/09/19/646047-000.html
http://www.mainichi.co.jp/digital/computing/archive/200309/05/4.html
http://linux.ascii24.com/linux/news/today/2003/09/01/645726-000.html

69 :
OTNで落とした9iが30日超えても
使えているけど…これって論理制限
つけてないの?

70 :
>>61
SQL92の定義が使えないのは問題かと・・・。
あと、ロックエスカレーションもエンタープライズで使えない原因。
同じロック粒度でもSQLサーバではデッドロックでトランザクション障害となる。

71 :
Ora信者 キタ━━━━(゚∀゚)━━━━ッ!!

72 :
>>71
Ora信者じゃないよん。OCPだが。
SQLServerの良さもあるよ。
同レベルの技術者ならSQLServerの方が高度な部分まで使えるし、
デフォルト(チューニングなし)ならSQLServerの方が確実に高速。

73 :
>72
OCPなんて言ってもほとんど通じねーぞ(藁
新入社員はひっこんでろ

74 :
>70
SQL92の定義が使えるかどうかっていう発想自体がSE失格
おまえSEやめた方がいいYO!!
ってかおまえ教育センター(アシストとか)の現場を知らない講師だろ(ワラ

75 :
ま  た  オ  ラ  オ  タ  か

76 :
>>75
シャアないやろ、連邦軍かジオン軍しかないのだから
http://www.atmarkit.co.jp/news/200309/13/gartner21.html

77 :
良くわからんから質問。
オラクルってSCN管理で一貫性を保持してるよね。(9iで変わった?)
ここらへんのアルゴリズムの良さが行ロックを常に行える理由だと思うのだが。

SQLServerはどんな方式を使ってるわけ?

例えば>>70はオラクルの話してるの?
ロックエスカレーションってさ普通一つ〜複数のトランザクション間の
リソースロックの連鎖によって
行→ブロック→セグメント→テーブルとロックの範囲やロックの強度があがることを
普通言うと思うんだが。。違うわけ?

ちなみにオラクルはロックエスカレーションを起こさせないはず。

78 :
後、オラクルでも限定状況でテーブルリソースを行ロックのつもりでも
セグメントロックになることはあるよね。
(ビットマップインデックス使用時とか。)
どのレベルで比較してるのか頭から見たんだけど、どうもわからんかった。。。。
後72にちょっと突っ込みなのだが。。。。
>デフォルト(チューニングなし)ならSQLServerの方が確実に高速。
こんなんで金もらえる仕事なら紹介してよ。。w

79 :
後双方使った事ある人がいたら教えて欲しいんだが、
SQLServerとオラクルでインデックスの見積もりって相当違う?
(Btreeの場合限定で教えて欲しい。
ルート、ブランチ、リーフあたりの見積もりとスプリット関連の発生有無&方式)
運用時にそのインデックスとテーブルデータとの絡みで
困ったこととかがあれば聞いてみたい。

80 :
>78
MSDE使うような小規模システムならデフォで運用ってのもそう珍しくないような気が。
Accessで組むのとそう変わらないくらいの予算しか取れないような案件だったり
するんで、チューニング云々の工数なんか取れないよ。

81 :
>>80
ちょっと意識のズレが大きいかも。。
新規システム導入(ハードから完全に調達)、
又は既存システムの焼き直し(これも基本はハードから完全に調達)、
既存システムに組み込み(ソフトの選定&調達)。
他のケースもあるけど大体この三つに分けれるよね。
調達時点で大体の見積もりは行いきるのが普通。
チューニングって単語はネットや講習では言われるけど、
現実問題では大規模システムになればなるほどチューニングは不可能だから
完全に見積もりきるぐらいの設計をしないとクリティカルになりかねないのよね。
(オラクルのVerUPの影の主役はシャットダウンしないで
ダイナミックにパラメータ変更を行えることって結構知らない人多いぐらいだし。
現実運用でダイナミックにパラメータを変更するにもその影響度を
試験機で試して運用してみてから導入するぐらいの時間をかけるのが
当たり前なぐらいの話なわけで。。。)
で、小規模だからデフォで良いと言うのが俺にはどうしても理解できないんだよね。
調達レベルでデフォでOKって客からネゴを取って見積もってるのか。
小規模特有のなぁなぁ商売でデフォでOKとしてるわけ?
(遅損賠償とか怖くてそんな商売できない。。)
スレ違いな上に長文すまそ。

82 :
>81
小規模システムでは、そんなに大量のデータを扱わないことが多々ある。
そんな場合、SQLServerのデフォルトのままでも全く問題ない。
だって十分速いのだから。
ボラクルみたいにチューニング必須ではないからね。Microsoftもそれをウリにしている部分もあるし。
そもそも企業は小規模システムごときにお金をかけたくない。
なんでそんなにチューニングしたいの?
あまりぼったくらないでね。
    ボラクルが使われているシステムの保守費用に泣かされている一般企業より

83 :
>>82
>そんな場合、SQLServerのデフォルトのままでも全く問題ない。
これを裏付ける見積もりをしているかどうかが問題なんだよね。
小規模システムと大規模システムに見積もりに違いってあるの?
オラクルもチューニングは必須項目じゃないよ?
(マスターの話じゃないよ。)

84 :
データベースのチューニングって、具体的にどんな事をするんでしょう?
厨な質問ですんません。。。

85 :
>>84
具体的になんて言いようが無いと思うよ。
通常はAPのスループット関連の解消がメインだろうけど、
カツカツにやってるところなら運用前から
各種モニタツールを使ってモニタ結果の収集を行い
メモリ、ディスクの容量の観点、スループットの観点で閾値判断を行い
処置が必要かどうかを判断をする(第一チューニング)
処置必要な場合は適切に処置する(第二チューニング)
その他時間帯によるトランザクションピークによるAPの調査
APの修正、ジョブの変更等等、その他処置(インデックスの追加←容量のチューニングにも絡む)
によるAP単体の必要なリソース削減によるオーバーヘッド削減。
バックアップリカバリだって当然絡む。
時間を捻り出せなければいざチューニングすると言ってもできないわけで
ディスク拡張してバックアップ時間が延びたなんて間抜けなことになってもいけないわけで
総合的な運用を見据えて運用が快適にできるよう考える視野が必要。
ノウハウが溜まれば溜まる程やれることは増えるね。
はっきり言ってディスク辺りのチューニングになると
今時は当然RAIDを知った上でのチューニングになるから
VG構成の理解も必要だし、そこからPV、LVOLの構成まで把握した上で
DB側から見た物理、論理で考えないといけないし。
メモリに関しても各種プロセスが共用メモリなのかプロセス固有メモリで動いているかどうか
把握する必要もある。そうなるとプラットフォームのUNIXをある程度の理解が必要になる。
(知らないでチューニングは不可能)
まだまだ沢山あるよ。

86 :
>83
私は>82ではないですが・・・
小規模・・・いや、零細規模と言ったほうがいいかな?
そういうシステムの見積もりに参加した事がありますが(DBMSはMSDE、クライアント数5)
鯖はメーカーラインナップのローエンドモデル(当然ディスクは1台のみ)
バックアップは1日1回、クライアントが稼動していない深夜DATにフルバックアップ。
DB鯖まわりの見積もりなんて、メモリはクライアント数とOSとDBMSが要求するカタログ
スペック値から算出した値+αでえいやぁ、ディスク容量も日次データ量x年数でえぃやぁ。

87 :
機能面でも、要件定義書にレスポンスタイムに関する記述が実質無いので、単純に
機能毎にプログラミング工数出して余裕率掛けてドーン。こんなもんです。
MSDEはウイザードで作成した保守計画とバックアップジョブを登録した以外、素でインストールしたまま。
さすがにディスク1台はマズいだろうという事でミラーリングしてくれという要求は出してるみたいですけど。

88 :
>>86
俺としては同時セッション数30を越える、
一日に要求されるトランザクション数5000を超える、
一日に出力されるジャーナル(REDO)1Gを超える、
これ未満のものはえいやーでもしょうがないと思う。
多分このレベルだと調達なんてただでいいから開発もセットでお願いします。
でペイするような仕事だよね。(と共にこのレベル仕事のDB管理者って可愛そうとも思う。。
調達と開発がわかれるのって上の三つのどれかを満たした辺りからだと思う。
スレから大分ズレたな。。すまそ。

89 :
えいやーで良いとは言ったが根拠がグラグラでもあるか無いかは別。
これは小規模だろうが大規模だろうが最後は運用するまでわからないから
えいやーになってしまうんだよね。

90 :
私がいた所の感覚なら、>88さんが言う基準は「中規模」以上なんじゃないかなぁ。
「規模」の感覚って、会社によっても大きく違うから難しいですね。
>開発もセットでお願いします
まさにそれです。
ちなみに、先に挙げたシステムでは管理者なんて付きませんw
毎日バックアップテープ交換するのは事務所のオネーサン、鯖ログは月1回の
定期訪問時にちゃちゃっとチェックするだけです。
これで5年ノントラブル(PGのバグは別として)だからすごい

91 :
つうかそのレベルなら何使っても同じじゃないのか?

92 :
>>90
DBって俺的な主観なんだが、
洋服と一緒でS,M,Lで大体の人は多少の着心地は違っても
NGにはならないのと一緒で動くものだと思ってるのよ。
でも本当のスループット(着心地)を追求すると、する必要がある
厳密な仕事や格好の場合にチューニングって必要となると思う。
又は既製品(洋服)では型にはめれない特殊な人(システム)で
その技術が必要となると思う。
それとシステムを稼動(人の身体的な成長)による拡張や癖(業務特性)
を知った上での変更がチューニングだと思う。
一応これで終了。
オラクルとSQLサーバの両方を使った人のレポ希望募集します。

93 :
【結論】
SQLServerはある程度の規模までは無理にチューニングしなくても十分速い。
それをウリにしているし、素人が下手にチューニングすると返って問題がおこる。
Microsoftはそこそこの技術者でも扱えるDBを目指している。
一方オラクルは完全にプロ向け。
素人の扱える代物ではない。よって信者は完全にのぼせている。
だからオラクル信者はだれでも扱えるSQLServerを嫌う。そしてけなす。
チューニングしないDBは糞と考える。
それにチューニングなどの設定に時間をかけたほうが客からお金を巻き上げられるのでかなりおいしい!

94 :
sed s/SQLServer/DB2/ 93

95 :

96 :
このスレってさ、営業スレだろ?
すげー笑えるんだけどw

97 :
>>70
デッドロック=トランザクション障害 = つかえない
ということが基幹で成り立つか?
答え:ありえない。 デッドロック発生の予測不足
もう一回まわせばいけるんだからアプリケーション側でリトライするだけさ。

98 :
チューニング=かならずしなければならないか?
大規模:そんなの設計段階で設定を決めておけ(ないしは見積もり式を決定しておけ)
     キャパシティプラニングやってるんだろ?
小規模:出たとこ勝負 工数が足らんし。
と、顧客or営業に言われておしまい。
トランザクション量ピーク時付近の補正をかける程度で済ませるのが
本当のSEだと思うな。
ピーク付近での動きについては、本来は性能チューニングじゃなくて、
負荷耐久という視点でみてからチューニングすべき。

99 :
Oracleの代わりにM$SQLServerなんて選択肢イラネ
そんなときはPostgreSQL, Firebirdとかがある

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 削除依頼
・ 次のスレ
【pc系鯖】 oyster鯖 争奪戦 【新鯖獲得!?】
Oracle 儲かって儲かって、うはうは
oracleの信憑性について
【DBMS】 HiRDB