「オラクル都市伝説」に対する反応まとめ

K ツヨシ @tskitaga

技術的な文書を公の場に提示するのであれば、きちんと互いにフェアな前提とするべきだ。「あの」と揶揄されてはいるが、実際ありえない状態での比較に何の意味があるのだろうか。

K ツヨシ @tskitaga

「あの」データベースでは、Table Full Scan が Block されるほど Long Transaction を実施すると。その前提を等しく当てはめるのであれば、Oracle であっても Commit していないデータが残存しているのでしょう。

K ツヨシ @tskitaga

そしていつまでたってもデータを読み込むことができないと。

K ツヨシ @tskitaga

また、創造した文章であれば、どのような表現をしてもよいのかと。「検証の段階で遅くて使い物にならない事が判明」とされているが、公平な第三者に検証してもらってもそのような結論にはなっていない。

K ツヨシ @tskitaga

物語であれば、どのような記述をしてもよいということなのだろう…。

みへ@noukin-a-gogo @miche__rm

@tskitaga 関わって無いのですが、何かしらネタ元になった可能性はあります。すみません。。。

K ツヨシ @tskitaga

@miche__rm いえいえ。技術的に正しければ何にも問題はないと思います。でも、これは「ネタ元になった可能性」だけあって、ものすごく恣意的な記載になっていますよね…。残念です。

みへ@noukin-a-gogo @miche__rm

@tskitaga えぇ、色々と残念です。

K ツヨシ @tskitaga

読取り一貫性により SELECT 発行時点で Commit されているデータを読み込んでいるわけで、「あの」データベースに対して行われているように「多数の更新が行われている」のでしょう。文レベルの読取り一貫性により、SELECT 発行時点なので、最新ではないデータで分析することに

K ツヨシ @tskitaga

ちなみに「ダーティーリード」は「ロールバックすると存在しないレコードを読み込む」事である。読取り一貫性とは関係しない。Oracle も「あの」データベースも Read Committed であり、コミット済みのデータしか読取ることはできない。

K ツヨシ @tskitaga

この「コミット済みのデータ」を読み取る際に、SELECT が発行された時点の一貫性を持たせているのが文レベルの読取り一貫性。途中でレコードが更新されても、そのレコードがコミットされても、SELECT 文発行時の「過去のコミット済みデータ」を読取る。

K ツヨシ @tskitaga

「あの」と揶揄されている可能性の高い SQL Server では、デフォルトではコミット済みデータのみを読取る。ダーティーリードなどしない。

K ツヨシ @tskitaga

読取り一貫性とダーティーリードの違いを正しく理解できていないのにこのような主張はいかがなものだろうか。

K ツヨシ @tskitaga

@miche__rm はい。残念です。

みへ@noukin-a-gogo @miche__rm

@tskitaga 確かに図がおかしいです。読み取り一貫性の話をしているようなのにNOLOCK(Read Uncommitted)で意図的にダーティーリードさせる説明にすり替わっている。残念。。。

K ツヨシ @tskitaga

@miche__rm NOLOCK ヒントで読ませてしまうと、都市伝説として「違い」が際立つ物語が成り立たなくなるのです。なので、文中に「ダーティリード」という文言が出てしまい、ウェブコンテンツとしての一貫性を欠いてしまっているのかもしれません。

K ツヨシ @tskitaga

SELECT 文発行時で最新ではないデータで分析するのが良いのか、未コミットデータを含む可能性があるデータで分析するほうがいいのか。どっちでしょうね。違いはそこだと思うのですが。

K ツヨシ @tskitaga

もちろん、TempDB の格納先をきちんと設定し、Isolation level を Read Committed Snapshot に変更してもいいのですが。こうなると文レベルの読取り一貫性になり、差をなくすことができますね。

みへ@noukin-a-gogo @miche__rm

@tskitaga ですね。結果混乱させる文章になっていしまっていて、まことに残念。意図的にミスリードさせようとしているのかもしれませんが、かえって混乱させるだけのような。。

K ツヨシ @tskitaga

TempDB に更新前レコードデータを格納することでオーバーヘッドになる、とされていますが、レコードの更新前データは UNDO 領域に格納されますよね。同じコストをかけた処理なのではないかと。なのに、Oracle では性能に影響がなく、SQL Server では影響があると。

K ツヨシ @tskitaga

UNDO 領域はきちんと設計されたディスク上に確保するのに対して、TempDB は C ドライブの単一ファイルを前提としているのでしょうか。

みへ@noukin-a-gogo @miche__rm

デフォルトでSELECTのLOCK待ちが無いってのはOracleのメリットではあると思うけど、それも伝わらないよなーこの文章。

K ツヨシ @tskitaga

@miche__rm いえいえ。PowerPivot を例に挙げて揶揄するというのは残念でなりません。ユーザーサイドでのデータ活用を進めるために広く提供しているツールなのに…。

みへ@noukin-a-gogo @miche__rm

@tskitaga はい。。残念です。人のふんどしをならまだしも、風呂敷を無理やりふんどしとして使っているような。

Masao Kurosaki @mkurosa

@tskitaga 今日はどしたの？ うちのメンバーに聞こうか？