Oracle＞＞＞＞＞＞SQLServer

**名無しさん＠お腹いっぱい。** · 03/07/02 22:08

だろ

**NAME IS NULL** · 2010/04/01(木) 21:33:06

なかなか興味深い記事です。

オラクル都市伝説に物申す。
http://d.hatena.ne.jp/matu_tak/20100324/1269539205

どちらの言ってることが正しいんですかね？

**NAME IS NULL** · 2010/04/03(土) 21:53:25

純正SQL Developerでいいやろ。

**NAME IS NULL** · 2010/04/03(土) 22:06:40

顔真っ赤にして書いたってかんじのblogだな。

**NAME IS NULL** · 2010/05/01(土) 17:10:12

Oracleばっかやってるヤツは他DBに来るとめちゃくちゃデタラメなSQL書くからのぅ

**NAME IS NULL** · 2010/05/19(水) 01:31:13

SQLserverの行ロックってなんや？

検証したんか？　したなら、テスト環境書かんかい。
SQLserverオタは必ずテスト結果も出さずに出来る出来るいいよる。
オラクルの行ロックは検証結果があっちこっちで書かれてるやろ。

**NAME IS NULL** · 2010/06/03(木) 14:25:49

検証しました。
該当ページに含まれるすべての行に行ロックが発生しました。
結論：SQLserverで行ロックはできません。

**NAME IS NULL** · 2010/06/17(木) 12:25:36

会社でOracle使ってるものですけど、ある時SQL Server教えてもらえる機会があって、教えてもらいながら
ヨタヨタ使ってたんですけど、使ってたら

select table-a ......
updete table-b set ....
update table-c set ....
go
select table-b .....

とかやってたときに、table-bの更新間違えてたことに気づいて、まあいいや、と
rollback
したんですよ。そしたら、そのrollback効かなかったんですよ。友人に聞いたらgoしたらrollbackは
効かないんだとかなんとか、
本当なんですかね？　commitしてないのにrollback効かないの？？

**NAME IS NULL** · 2010/06/17(木) 16:23:28

即時コミットモードがデフォルトでトランザクションを使いたければ
begin transaction命令を使う必要がある。

**NAME IS NULL** · 2010/06/18(金) 11:17:18

>>220

なんと、ＳＱＬＳｅｒｖｅｒは即時コミットモードとTransactionモードなんてのがあるのか、いや驚いた。
しかし、2つのモードをユーザーが意識しながら使い分けなきゃいけないなんて
使い難いだろ。

**NAME IS NULL** · 2010/06/18(金) 22:09:05

どっちか一方のモードしか使えなかったら、それはそれで文句言うだろ。

**NAME IS NULL** · 2010/06/18(金) 23:47:53

>>222

いや、即時コミットモードなどいらん。
まともなロックと読み取り一貫性があれば。

**NAME IS NULL** · 2010/07/01(木) 16:03:47

OracleのSQLインタープリタ（SQLPLUS)にはちょっとしたわながあって、
commitもrollbackもしないままEXITで終了させると、
commitされてしまう。

共有ロック方式の場合長時間ロックは厳禁だから即時コミットデフォなのは妥当な措置だな。
マルチバージョニングでも書き込み同士はロックがかかるから長時間ロックは避けたほうが
いいと思うが、リード操作でロックフリーなのをアピールしたかったのだろう。

**NAME IS NULL** · 2010/08/24(火) 02:39:10

SQLServer2000はスナップショット分離レベルが無いから辛い…
更新済未コミットレコードは読む事さえ出来ない…

**NAME IS NULL** · 2010/08/24(火) 03:16:46

>>213
217さんに聞きたいです(純粋に聞きたいだけです)。
SQLServerのロックエスカレーションの発生理由は、
大量の行ロックによるメモリ圧迫に対しての対策だとMS社サイトに書いてありました。
※メモリ節約がより有効と判定された場合は、大量の行ロックを1個のテーブルロックにする
Oracleは、どんなに行ロック件数が多くなってもそのまま？

**NAME IS NULL** · 2010/08/24(火) 03:28:24

すいません。47 とかに書いてありました…

**NAME IS NULL** · 2010/09/14(火) 08:39:55

>>224
exitコマンド打った時にトランザクションが残ってるってメッセージも出ないプログラム設計がダメだな

**NAME IS NULL** · 2010/09/26(日) 21:31:40

SQLSERVERの３大糞仕様

①ロックエスカレーション　
5000行以上のレコードを一度に更新、或いはロックした場合に発生し、
行ロックがテーブルロックへ昇格する。

②テーブルスキャンによるロック待ち
対象テーブルの中でたた一件だけでもロックしているレコードがあると、
まったく関係ない行へのロックが獲得できない場合がある。
発生条件としては、キー、或いはインデックス情報だけでダイレクトに
対象データに到達できないSQLを発行した場合。

③実行プランキャッシュの使用判断基準
一度発行されたSQLの実行プランがキャッシュにある場合、
検索条件の値が異なる同様のSQLが発行されると、
明らかに非効率な検索になるにもかかわらず、強引にキャッシュされた
プランを利用してしまい、いつまでも実行結果が返ってこないことがある。

**NAME IS NULL** · 2010/09/27(月) 16:50:13

SQL Server でロックエスカレーションを禁止するには、
以前のバージョン（SQL Server 2005 以前）では、トレースフラグ 1211 をセットします。
これでロックエスカレーションを禁止することができます。

**NAME IS NULL** · 2010/09/27(月) 16:52:18

SQL Server 2008 の場合は、LOCK ESCALATION オプションがサポートされたので、
テーブル単位でロックエスカレーションの禁止を行うことができます。

**NAME IS NULL** · 2010/09/27(月) 17:02:33

http://msdn.microsoft.com/ja-jp/library/ms188469.aspx

[テーブルのプロパティ] ([全般] ページ)

[ロックエスカレーション]
DISABLE
ほとんどの場合でロックエスカレーションを禁止します。
テーブルレベルのロックは完全には禁止されません。
たとえば、SERIALIZABLE 分離レベルでクラスタ化インデックスがないテーブルをスキャンしている場合は、
データベースエンジンでテーブルロックを実行して、データの整合性を保護します。

**NAME IS NULL** · 2010/10/01(金) 12:09:54

>>229
③に関しては、Oracleだって同じ現象が発生するじゃん

**NAME IS NULL** · 2010/10/01(金) 23:37:48

プレースホルダ使った静的SQLならごく当たり前の動作だな。
値を埋め込んだ動的SQLで値の違うキャッシュを使用するなら逆にすごい。

**NAME IS NULL** · 2010/10/10(日) 22:42:26

NASDAQ
SQL Server 2005 の展開によって、リアルタイムの取引照合とクエリを実現
http://www.microsoft.com/japan/showcase/nasdaq3.mspx

株式会社百五銀行
世界初。Windows Server 2003, Datacenter Edition とSQL Server 2005 Enterprise Edition をプラットフォームに、銀行の勘定系システムを再構築。
http://www.microsoft.com/japan/showcase/hyakugo.mspx

**NAME IS NULL** · 2010/10/22(金) 00:09:22

SQLServer2005はSP2ぐらいまでクエリエンジンがバグだらけだったのに
金融系で使うとか正気の沙汰じゃないよ。
社内システムか、分析系システムならいいが‥