今回完全な妄想モードで失礼いたします。

数日前になりますが、SQL Server チームがBLOGに以下の投稿をしました。

「中堅企業向け オラクル都市伝説シーズン2: 其の一」への反論
http://blogs.technet.com/sqlpm-j/archive/2009/08/27/3277427.aspx

上記の投稿は、タイトル通り、オラクル社のサイトに掲載された「中堅企業向け オラクル都市伝説シーズン2: 其の一」に対する反論です。弊社 北川 による熱い内容になっています。

技術的な検証はプロダクトマネージャーの北川が詳しく行っているので、私は、なぜKさん（上記コラムに登場するエンジニア氏）がこのようなトラブルに見舞われてしまったのか、Kさんの感情移入して検証してみたいと思います。

＃ORACLE社の本文をお読みになってから、以下をお読みくださいませ

Kさんはシステムが動かないという連絡を受け、深夜のタクシーで現場に向かいます。現場に到着し状況を確認してから顔が青ざめていることから、おそらくタクシーの中では寝ていたのでしょう。無理もありません。真夏の夜が寝苦しいと書かれているので、エアコンはあまり効かせないで寝る習慣があるのかもしれません。そのため、恒常的な寝不足気味だったと予測されます。エアコンの効いたタクシーは、それは素敵な涼しい空間だったことでしょう。もしタクシーでの移動中に、携帯電話で現場のお客様により詳しい状況を確認できていれば、現地に到着後、より迅速な対応ができたはずですが、今回はそれは問題ではありません。

現場に到着してからのKさんは、お客様への謝罪もそこそこに、マシン室に直行、目にもとまらぬ速さでログオンし、状況把握に努めます。

本文より、発生している事象は2件あることがわかります。

• ログファイルが肥大化しディスクフルだった
• ログファイルが破損していた

Kさんは、ファイル肥大化→ログの物理破損→システム停止 と判断したようです。確かにファイルの容量が肥大化すれば破損の可能性が拡大することは事実です。ただしそれは物理的な破損の可能性です。おそらくKさんとお客様の間で、以下のようなやり取りがあったものと思われます。

Kさん「SQL Server が不用意にログファイルを肥大化させたことが原因でディスクが圧迫されてしまいました。それが原因で、ログファイル自身が破損し、ミラーリングが意味のないものとなってしまいました。」

お客様「ファイルが肥大化すると破損するものなのかね？」

Kさん「はい。物理的に破損する可能性は高まります。」

お客様「それはOSの問題なのか？それともSQL Serverの問題なのか？」

Kさん「さまざまな原因が考えられます」

お客様「今回は何が原因だったのかね？」

Kさん「SQL Serverがファイルを肥大化させてディスクを圧迫したことが原因です」

お客様「いや、だから。ディスクを圧迫するとファイルは���損するものなのか？と聞いているのだよ」

Kさん「そうです」

お客様「それは常識なのかね？」

Kさん「気をつけるべき点ではあります」

お客様「じゃ、なぜ気をつけなかったのかね？」

Kさん「いや、知らない間に肥大化していたもので」

お客様「なぜ知らないのかね？気をつけてしかるべきコトなのだろう？」

Kさん「…」

お客様「運用マニュアルはどうなっているのだ？」

Kさん「…」

ショッピングサイトという無停止を要求されるシステムでは、当然のことながらディスク容量の監視も必要です。なんらかの監視ソフト、もしくは Windows Serverの標準機能を使用したディスク容量の監視を行っていたはずです。もちろん、そうした対策は運用マニュアルに書かれているべき事項ですし、365日24時間SEサポートを契約しているのであれば、当然サーバーの遠隔監視サービスも契約されているでしょう。Kさんは「気づかぬ間にログが肥大化していた」と告白しています。つまり、ディスク容量の監視は事実上を行われていなかったことがうかがえます。

また、北川が指摘するように、SQL Serverのメンテナンス方法についても、あまり事前調査をしていなかったのでしょう。さすがに、Kさんも「SQL Serverはメンテナンスフリーだ」とまでは思っていなかったはずですから、これは明らかにKさんがSEとしての仕事を放棄していたことに他なりません。

さて、Kさんは「安い」というだけでSQL Serverを選択したことを猛烈に後悔しています。

が、あまりにも後悔しすぎたのか、次第にKさんの「心のジャーナル」に論理破たんが起きています。

Kさんは自分自身が「安い」という理由だけでSQL Serverを選んだことをすっかり忘れ（一度は反省したにもかかわらず）、自分が所属する企業から「無理やり選ばされた」ことにしてしまっているのです。そして、その「選ばされた」企業を辞め、別の企業に転職してしまいます。

ここでどうしても気になるのは、今回トラブルに見舞われたお客様は、その後どうしたのか？ということです。ORACLEに乗り換えたのでしょうか？いや、SQL Serverが嫌で転職したわけですから、どうもそうではなさそうです。

このお客様は、トラブルを引き起こしてしまった（と、Kさんが思っている）SQL Server を引き続き使い続けているわけですから、同じような障害に見舞われる可能性も、いまだに抱えているはずです。

にもかかわらず、Kさんは、今後の障害回避策を提案しなかったと思われます。

なぜならば、もし障害回避策を提案していたとしたら、「安い」（とKさんが認めている）うえに「トラブルを回避する方法が存在している」SQL Server を捨てる理由は、全く無くなるわけですから。

（いや、生理的に嫌になったという理由はあるかもしれませんが…）

こうしたKさんの言動を見るにつけ、はたしてKさんは次の会社において、きちんとやっていけるのかどうか心配になります。ORACLEに乗り換えたところで、結局は自分の調査不足を棚に上げ、DB2を選択する企業に転職してしまうんじゃないでしょうか。

「障害に強いオラクル」であっても、メンテナンスフリーではありません。すばらしい「ログの二重化機能」は、「SEの調査不足を担保する」ものでは無いはずです。ディスクの容量を含め、メンテナンス計画を立案し実行することは担当のフィールドSEとして必須の作業ですし、ディスク容量が圧迫されて運用が停止するなどということは、インフラに携わるSEとして想定しておくべき事項です。

私は、今回のトラブルは、Kさんが「エンジニアとしてやるべきこと」をやっていなかったからではないかと思えてならないのです。

ま…それはそれとして…ログの二重化機能は SQL Server にも欲しいですよね。＞偉い人