tskitaga's tweets on Thu, Jun 03

00:26 @takeshiwatanabe やっぱりそうですよね！ [in reply to takeshiwatanabe]
00:27 I just ousted Saopon F. as the mayor of セブンイレブン千葉海浜幕張駅前店 on @foursquare! http://4sq.com/bPqbm6
00:27 帰宅ったー。 (@ セブンイレブン千葉海浜幕張駅前店) http://4sq.com/bPqbm6
02:00 @MatsuJun_MJ マッサージですが、17時からでお願いします。肉は２１：30で予約できました。
02:09 大変美味しくいただきました。RT @MatsuJun_MJ: @thitomi 昨日お菓子進呈できなくてごめんなさいでした。今日、@tskitaga さん他が消費してくださいましたｗ
02:11 @takh777 日本人が受け取るイメージと、ネイティブが使う感覚とで差がありそうな単語ですね。 [in reply to takh777]
08:28 不幸な事案に対して準備万端だとなかなかその事案は顕在化しないという不思議。いや、いいことなのですが。
08:30 いや、事案は顕在化してほしくないのですが。いずれにせよ土曜日に病院にいけるのでその際話ができればいいか。
11:31 お腹が空いた…。一昨日アップに失敗したブログも書き直さないと…。
13:30 @konakaya ガンシップ懐かしいなぁ…。 [in reply to konakaya]
13:32 @MatsuJun_MJ 16時までに夕飯をとり、早く帰宅して早く寝る。健康診断に備えて。 [in reply to MatsuJun_MJ]
13:33 @yokatsuki 歩いて移動する!? [in reply to yokatsuki]
13:35 @shin135 何事も共感できる単純化された状態で語られるのか。最新の状況を確認することなくイメージで。 [in reply to shin135]
13:39 赤坂見附ランチネタが TL を占拠している。
13:40 I'm at トスカーナ　代々木店 (代々木1-53-4田尻ビル2F, 渋谷区). http://4sq.com/afJNYO
13:58 I'm at マイクロソフト (代々木2-2-1 小田急サザンタワー, Tokyo). http://4sq.com/67TS6m
14:08 D2K にいたころ通ったなぁ…。RT @toshi_shiratori: 写真忘れRT 麹町の二代目つじ田にてつけ麺を食す。弾力のある太麺に負けないスープは深く旨味がある。具のチャーシューとメンマ、味玉もそれぞれ完成度が高い…
14:11 @Aska_Chan あの味が懐かしくなりました。 [in reply to Aska_Chan]
14:18 @Aska_Chan そそ。スダチがいい。さっぱりする。 [in reply to Aska_Chan]
14:34 [sqlpm blog] Microsoft SQL Server 2008 R2 Technology Summit を機に検証機貸出し開始します http://bit.ly/aIG9vL
15:21 技術的な文書を公の場に提示するのであれば、きちんと互いにフェアな前提とするべきだ。「あの」と揶揄されてはいるが、実際ありえない状態での比較に何の意味があるのだろうか。
15:24 「あの」データベースでは、Table Full Scan が Block されるほど Long Transaction を実施すると。その前提を等しく当てはめるのであれば、Oracle であっても Commit していないデータが残存しているのでしょう。
15:24 そしていつまでたってもデータを読み込むことができないと。
15:26 また、創造した文章であれば、どのような表現をしてもよいのかと。「検証の段階で遅くて使い物にならない事が判明」とされているが、公平な第三者に検証してもらってもそのような結論にはなっていない。
15:30 物語であれば、どのような記述をしてもよいということなのだろう…。
15:40 @miche__rm いえいえ。技術的に正しければ何にも問題はないと思います。でも、これは「ネタ元になった可能性」だけあって、ものすごく恣意的な記載になっていますよね…。残念です。 [in reply to miche__rm]
15:47 読取り一貫性により SELECT 発行時点で Commit されているデータを読み込んでいるわけで、「あの」データベースに対して行われているように「多数の更新が行われている」のでしょう。文レベルの読取り一貫性により、SELECT 発行時点なので、最新ではないデータで分析することに
15:55 ちなみに「ダーティーリード」は「ロールバックすると存在しないレコードを読み込む」事である。読取り一貫性とは関係しない。Oracle も「あの」データベースも Read Committed であり、コミット済みのデータしか読取ることはできない。
15:57 この「コミット済みのデータ」を読み取る際に、SELECT が発行された時点の一貫性を持たせているのが文レベルの読取り一貫性。途中でレコードが更新されても、そのレコードがコミットされても、SELECT 文発行時の「過去のコミット済みデータ」を読取る。
15:59 「あの」と揶揄されている可能性の高い SQL Server では、デフォルトではコミット済みデータのみを読取る。ダーティーリードなどしない。
16:00 読取り一貫性とダーティーリードの違いを正しく理解できていないのにこのような主張はいかがなものだろうか。
16:01 @miche__rm はい。残念です。 [in reply to miche__rm]
16:02 @waki はい。頑張ります。一緒に OST 出ますか？ [in reply to waki]
16:17 @miche__rm NOLOCK ヒントで読ませてしまうと、都市伝説として「違い」が際立つ物語が成り立たなくなるのです。なので、文中に「ダーティリード」という文言が出てしまい、ウェブコンテンツとしての一貫性を欠いてしまっているのかもしれません。 [in reply to miche__rm]
16:19 SELECT 文発行時で最新ではないデータで分析するのが良いのか、未コミットデータを含む可能性があるデータで分析するほうがいいのか。どっちでしょうね。違いはそこだと思うのですが。
16:20 もちろん、TempDB の格納先をきちんと設定し、Isolation level を Read Committed Snapshot に変更してもいいのですが。こうなると文レベルの読取り一貫性になり、差をなくすことができますね。
16:26 TempDB に更新前レコードデータを格納することでオーバーヘッドになる、とされていますが、レコードの更新前データは UNDO 領域に格納されますよね。同じコストをかけた処理なのではないかと。なのに、Oracle では性能に影響がなく、SQL Server では影響があると。
16:27 UNDO 領域はきちんと設計されたディスク上に確保するのに対して、TempDB は C ドライブの単一ファイルを前提としているのでしょうか。
16:43 @MatsuJun_MJ なぜだろうか!? [in reply to MatsuJun_MJ]
16:50 @miche__rm いえいえ。PowerPivot を例に挙げて揶揄するというのは残念でなりません。ユーザーサイドでのデータ活用を進めるために広く提供しているツールなのに…。 [in reply to miche__rm]
17:46 @mkurosa いえいえ。これは疑問ではなく、問いかけですね。先方への。 [in reply to mkurosa]
17:50 @mkurosa きれいに包まれていますよ。ロゴもきれいに入っています。写真では包装されているので、当日のお楽しみということで。 #ts2010j
17:54 ちなみに参加者へのノベルティはこちら。シリコンメモパッドです。あんなことやこんなことを書いても消しゴムで消せます。
17:55 ちなみに #ts2010j 参加者へのノベルティはこちら。シリコンメモパッドです。あんなことやこんなことを書いても消しゴムで消せます。
18:04 空目!? RT @junichia: リモコンメモパッドに見えた RT @tskitaga ちなみに #ts2010j 参加者へのノベルティはこちら。シリコンメモパッドです。あんなことやこんなことを書いても…
18:05 w RT @moinose: さっき「都市伝説（笑）」って書いてましたよね？RT @tskitaga: ちなみに #ts2010j 参加者へのノベルティはこちら。シリコンメモパッドです。あんなことやこんなことを
18:44 いったん引き揚げ。帰宅後ブログを書く!!
20:42 DB マガジンの方々とお疲れさま会なう。初期の寄稿者と PDF のアーカイブを見ながら思い出話。
23:49 @juniwata わかっている方には笑い話ですむのでしょうが、データーベースで信頼されている会社の公式サイトですから。当然詳しくない方も見るでしょうし、真に受ける方も出るかもしれません。 [in reply to juniwata]
23:53 @juniwata 正しい、より客観的に共通の前提を明示した上での情報提供につとめたいですね。前提や条件の曖昧な比較は誤解を招くだけだと思っています。自社の製品については正しく、比較は客観的にやりたいです。 [in reply to juniwata]