オルタナティブ・ブログ > Azureの鼓動 >

クラウド戦役をZガンダム視点でわかりやすく解説するブログ+時々書評。

戦争とはいえ、ルールはある…私はそう思っております。と、オラクル担当社にいって欲しかった件

»

Oracle都市伝説というコラムをご存じだろうか。製品名こそ明記していないものの
SQL Serverを使っているとこんな危ない目に遭うかもしれないということを示唆する、
それらしい話を掲載している。人気なのかどうかはわからないがセカンドシーズンまで掲載している。

オラクルは私の心の故郷であり、今でもオラクルという製品や会社を尊敬しているし、
たまたま競合のマイクロソフトに現在在籍しているからといって嫌いになったわけでは
ないのだが、この都市伝説シリーズ含め、最近の取り組みには少々危うさを感じている。

直近、私が問題視しているのは、このコラムが他社製品に対し、技術的な誤解を招きかねない
表現をアグレッシブに盛り込んでいる点だ。ロックエスカレーションの問題にしても、
ログ量の増大についても、そうなってしまう可能性自体は否定しないが、回避するための
ガイドラインを示し、事実、問題なく稼働しているシステムはたくさんあるにも関わらず、
「行ロックができるのはOracleだけ」「ログファイルが肥大化すると、ディスク容量がすぐに
一杯になるし、データファイルが破損する危険性が高まる」と文面で表現してしまうのは、
一線を越えてしまっている気がする。

前後の文脈や、話し手の所属や職種によっては、局所的な現場のにぎやかしや営業トーク
としてこういった話を展開したくなるのはわからなくもないし、管理のしようもないだろうが、
オラクルの看板つけた公式サイト内にこの記事を掲載し、プロモーションしてしまって
いるのは正直どうなのだろうかと思う。

このような感覚は私の思い過ごしか、と思っていたのだが、SQL Server製品チームの
ブログ
や別媒体ITproにも同じような記事が掲載されており、改めて考えてみると、
このメディアデバイスという記事の結びのように、正面から勝負すべきだと私も思う。

救いがあるとすれば、広報がチェックした正式な社外向け文書でも、OTNに掲載される
正規の技術文書やではなくブログ風のコラム形式で「都市伝説」といっている点だ。
おそらく書き手にも何らかのギリギリ感、罪悪感がどこかにあったのではないだろうか。
そう信じたい。

ここで、ガンダムMS-08小隊の一場面を紹介しよう。
ライヤー大佐率いる連邦軍の主力部隊が、高出力のメガ粒子砲を備える拠点攻略用
モビルアーマーであるアプサラスIIIの存在を察知し、その開発が進むジオン軍の
鉱山基地を包囲している最中の出来事。ジオン側から病院船の脱出の申し出があり、
一度は了承しながらも、無抵抗の病院船を秘密裏に配備していた長距離射程のジムスナイパーで撃破。

続いてアプサラスIIIのパイロットであるアイナ・サハリンを助けるべく、軍を抜け
別行動をとろうとしたシロー・アマダ少尉が乗るガンダムEZ-8に、あらかじめ
ライヤー大佐から特命を受けていたシローの部下であるカレンとサンダースの
RX-79G先行量産型ガンダムが照準を向けるシーン。

彼らの上官であるコジマ大隊長が本作戦指令のライヤー大佐と旗艦ビッグトレー内で
交わす会話である。

コジマ)…ッ処刑など聞いていません!これは…リンチです!
    ロブ…サリー…マイク…。この戦いで…多くの部下を失った…!
ライヤー)だからさ。もう一人くらい…。
コジマ)いいえ!だからこそです!カレン!隊を集結させろ!我々は別行動をとる!
カレン)はい!
コジマ)…さっき…確か病院船を撃墜せよと仰いましたな…。
    戦争とはいえ、ルールはある…私はそう思っております。
ライヤー)…ジャブローのオフィスは快適だよ…。
コジマ)私はエアコンというものが苦手でしてな。

この会話の後、ライヤー大佐が乗艦するビッグトレーは怒りに満ちたアイナ・サハリンが駆る
アプサラスIIIの高出力メガ粒子砲で消え去ることになる。

戦争の中でモビルスーツ開発を支える要素技術が飛躍的に進化するように、IT業界でも競合することで
互いの技術が進化すること自体は非常によいことだと考えている。しかし、比較広告だけならともかく、
他社の製品に対し、誤解を招くような表現をあえて盛り込むことが本当に必要だったのだろうか?

両方の技術を多少なりともわかっている人なら、そんなのすでに回避策のある問題なのになんで
あえて今更とりあげているのだろうか?と技術者のモラルに関わる疑念をもたせてしまうのではなかろうか。
データベースの王者オラクルたる、毅然とした戦いをこれからも続けてもらいたいものだ。

Comment(8)

コメント

砂金さん
 前回のMeetingにいけずお会いできなかったのが残念ですが、来月か再来月あたりにはぜひ、お話したいですね。
 今回の記事、とても共感いたします。どの会社がどうという意味ではないのですが。
 自分の会社のどなたかが、そのような戦法(といえるか?)をとろうとしたときには、それを止めようとすることの出来る人間でいたいと思います。

ログファイルの管理の問題に触れるのは
SQL Azure が本格稼動したなら墓穴となるのでは?

· Self-provisioning, auto-healing and disaster recovery, with high availability and no physical database administration. Self service provisioning means you can provision any number of databases and not have to worry about machines, disks, or server configuration.

吉田 賢治郎さん、ご無沙汰しております。
ご挨拶が遅れておりまして申し訳ありません。
そう、いざ自社がそうしようとしたときにどう抑制するかは難しいですよね。

kwinさん、毎度のことながらさすが、鋭い。
でも、クラウドサービスってその管理レベルを受け入れて流すのがお互いストレスがたまらない秘訣かと。
あれもこれも気になって要求すると、結局オンプレミスの方が安心ですし。
SQL Azureについては、どこまで何ができるようになるのか、何に使えそうか、もうちょっと検討に時間をかけた方がよさそうですね。
やってることの方向性は正しいので開発チームの今後のがんばりに期待です。

オラクルが論点をずらしてきましたね。
http://blogs.oracle.com/mamoruiwasaki/2009/09/oracledatabasesqlserver.html
http://friendfeed.com/satonaoki/0ca0c059/oracledatabasesqlserver-itmedia

SQL ServerのことをあまりわかってなくてOracleで食ってる私としては、これらからリンクされている山口氏のブログに肯いてしまうのだけど。
結局は、どのデータベースであっても技術者がきちんと理解して使わないとということですね。

しかし都市伝説の「しかし、ログファイルが肥大化しないOracle Databaseを選択すれば、この地獄から無事生還することは容易だ。 」とまとめられると、「これ書いた人ダイジョブかなぁ」と思わざるを得ないですね。

コメント、ありがとうございます。
おそらくオラクルの中の人で技術的地検と良識を持った方々は、微妙な気持ちで見ているのでしょうね。
Oracleはよいデータベースだとは思いますが、なんでもかんでもOracle使わないといけないか、というとそうでもないかと。
最近私はOracle vs SQL Server にはあまり興味がなくて(とか書くとサラリーマン的に怒られるのですが…)
RDBMS vs KeyValueのそれぞれに適した使い道を模索する方に興味大ありです。
特に、KeyValueストアは実際の運用を考慮した際のベストプラクティスがまだまだ不足しているので、
多くのエンジニアの人たちのがんばりが必要かと。

もだめ

「ログファイルが肥大化」は知りませんが、tempDBが肥大化しつづけて、
ディスク領域不足で、システムダウンした事例ならありますよ。
マイクロソフトさんはデータが壊れなければ、システムダウンしてもいいと
思ってるんでしょうかね?

コメント、ありがとうございます。
思ってるんでしょうかね?>マイクロソフトさんは、もちろん思ってないです。
ディスク領域不足…にならないよう、tempDB肥大化に気をつけて運用してください。
おそらく、何らかの監視は、しますよね?
予測できないほど前触れなく急激に肥大化したということでしょうか…。

もだめ

データ分布や統計情報の精度によって発生すると思いますが、
以下の事例だと予測できないほど前触れなく急激に肥大化したようです。
http://comfair2.blog24.fc2.com/blog-entry-453.html

私が実際に見たのは、おそらく以下のSQLSERVERのバグが原因で、
mdbファイルが4GBであるのに対して、tempdbが32GB程度になっていました。
現象再現までは、数カ月かかるため現在経過観察中です。

tempdb データベースで SQL Server 2005 で内部オブジェクトを作成するクエリを実行すると継続的に、tempdb データベース内の使用、領域が増加します。
http://support.microsoft.com/kb/947204/ja

コメントを投稿する