ちゃっぴの監禁部屋

DB を扱っている時、各 resource がどのように lock されているか、すなわち blocking の状況を把握することが重要です。SQL Server 2005 以降で blocking の状態を調査するには [master].[sys].[dm_tran_locks] を SELECT してやることで取得できます。

まあ、実際には [master].[sys].[dm_tran_locks] だけでは必要な情報が足りない場合が多く、[master].[sys].[dm_exec_sessions] や [master].[sys].[dm_exec_connections] と結合したりしますがこちらについては下記の Figure 3 Capturing locking stats を参考にしてください。

SQL Server のブロッキングを最小限に抑える

[master].[sys].[dm_tran_locks] を SELECT してやることで取得できた lock 情報ですが、このままではわかりずらいのでまずは [resource_associated_entity_id] を object name に変換します。その変換 script が Figure 4 Learning more about blocked data です。環境によっては大文字小文字の統一や @resource_associated_entity_id を bigint に修正してから実行する必要がありますのでご注意を。

で table name が取れたらいよいよ lock されている resource を特定します。これには undocumented な %%lockres%% を利用します。

SELECT * FROM [table name] WHERE %%lockres%% = @resource_description

@resource_description に [master].[sys].[dm_tran_locks] で取得した値を設定して上記 SQL を実行してください。Lock されている行が取得できます。

%%lockres%% は非常に使えるので、ぜひ document に載せて欲しいなぁと思うのですが、過去にその feedback をされていた方がいました。

Make %%lockres%% a documented feature

結果は検証する時間が無いので行わないとのことです。残念です。

検討の発端は Firefox がいつまでたっても Low Intergrity Level に対応しそうもなく、Google Chrome がとっくの前から対応していて使えそうに思えてきたから。

ただ、いくつか懸念している点があります。

• Script Blocker

  NoScript のような script の on, off を簡単に切り替える add on。XSS 等問題のある Web page へ突撃するために欲しいです。

• SSL まで対応した Network Trace を行える開発 tool

  Firebug のような SSL の network trace まで採れる add on。

• Google Bookmarks

  Add on でもなんでもいいので、Google Bookmarks を簡単に扱える方法。

• Mouse over 辞書

  Add on でもなんでもいいので英単語を手間かけずに翻訳する方法。

上記情報をお持ちの方どうか教えてください。

dynaTrace AJAX Edition で同時に JRE が install されると書きましたが、これってどうなんだろ。

確かに JRE を同梱することにより JRE を別途 install する必要が無くなるので、便利かもしれない。だけど、JRE の普及率はかなり高く、この blog への閲覧の統計でも 92 % は Java を support しているという現実があります。つまり、JRE を同梱した場合、大多数の user は同一端末内で複数の JRE を管理しなければならず管理負荷が増大します。

もっとも、Eclipse に代表されるように開発で利用するものについては複数 version を使い分けることが必要になる場合があるので、容易に差し替えられるようにすることも考慮に入れなければならないかもしれない。しかし、既定で利用するものは既に install されているものを利用して欲しい。昔は update まで指定して動作保障を限定するなんてことありましたが、さすがに今は無いでしょうから。

なお、ここ一年ばかり猛威を奮っている Gumblar の攻撃方法の内、もっとも攻撃が成功しやすい方法は下記記事によると JRE を狙ったものであるそうだ。

いま一番危ないぜい弱性は何だ？

もっとも、application に同梱した JRE の利用は Web browser から利用されるわけではないため、攻撃を受ける可能性は相当低いと思われますが用心するに越したことないでしょう。

なお、この手の同梱の問題は他にもいろいろあって、array controller の管理用 interface が Tomcat を利用した Web application で作成されているとか。昔はかなり放置気味な気がしていましたが、最近はどうなのだろう？

Application を提供する方はその application のみの保守で設計するのはやめて、全体としての保守運用の最小化まで意識して設計を行っていただきたいです。

Internet Explorer で HTTPS の network trace を採る tool を探していたら見つけた。

dynaTrace AJAX Edition

こんな感じで HTTPS の network trace ばっちり取れています。

他にも timeline とったりといろいろ機能は豊富なようなのでおいおい使いこなしていこうかと。

ところで、dynaTrace AJAX Edition は Java で動作しているようで、install した時に installed directory に JRE が一緒に install されます。現在の最新 version 1.6.0.322 では最新ではない JRE 6 Upadate 19 が install されます。JRE 6 Upadate 19 には JRE 6 Upadate 20 で修正された脆弱性が含まれているため、install が終わったら JRE を必ず最新のものに置き換えておきましょう。

こうゆうものを検知してくれる Secunia PSI マジで便利だわ。