性格

OracleDatabaseかSQLserverか。私はOracleのほうがやりやすいです。というのも、9,10,11と自動運転の部分が増えたものの、Oracleは最初に利用計画を立ててパラメータの値を考えていくうちに「あそこはどうしよう」「こういう障害が起きたらどうしよう」ということを考えざるを得ないようなしくみになっています。

反対にSQLserverはそこまで深く考えなくとも動くようになっていますし、考えたいけれども深くつっこんでチューニングさせてくれないように思わせる何かがあります。向かい合っていると「我々にお任せください」と言われているように思います。たとえて言えば日産＝Oracleでホンダ＝SQLserver、またはヤマハ＝Oracleで川崎＝SQLserverとでも言えるでしょうか。交通でもうひとついうと、道路からセンターラインを無くすと事故が減るそうです。理由は危ないという意識が強まるからだそうで、そういう意味ではOracleはセンターラインがない道路に近い存在だといえます（もちろん全然ないという意味ではなく比較したら、の話です）

ログ

今回の議論のもとになっているREDOログ・アーカイブログ（Oracle)またはトランザクションログ（SQLserver）にしても考え方の違いがあります。Oracleであればメンバーがいくつでディスクはどこ、アーカイブログの多重化はする／しないでディスクはどこ、というのを避けて通れません。SQLserverの細かい設定は自信がないのでMicrosoftの北川さんのブログを参考にしてみると、「メンテナンスプランウィザード」で設定するようです。選択肢を見てみると特に設定しないまま（＝肥大化を招きやすい）でも進めるようでもあり、そのように場当たり的に設定を行うのはMicrosoftとしても当然推奨していることでもなく、またかといって色々と細かく設定しないと動かないという面倒さは時には邪魔で、このように簡単に設定できる魅力は大きなものでもあります。

もちろん、Oracleの設定でREDOログメンバーを複数にしてかつアーカイブログと同じディスク上に書き込んだらディスク容量はすぐに使い果たされてしまうでしょう。その意味でも危ないですし、多重化によるメリット（ディスク障害から逃れられる）がないので、GUIから設定すれば警告メッセージが出たはずです。ただしOracleでこれをやると、REDOログがいっぱいになったのでログスイッチが発生し、それによりアーカイブログを作成しようとしてディスク領域不足が発生し、アーカイブログが作れませんエラー→REDOログが切り替えられませんエラーが出ます。記憶を頼りに書いているので怪しいかもしれませんが、こういった「手に取るように動きがわかる」範囲が広いのがオラクルのよいところであるように思います。（一方、古くからのOracleファンは最近の自動運転化の流れを全員が全員、好意的に受け止めているわけではないように感じます。）

技術者の層

また、Oracleについては↑のほうで明らかに間違ったことでも書こうものなら「ちっちっち」と詳しい方がわんさか出てくるという特徴もあります。OTNなどOracle側の提供するコンテンツの充実ぶりもさることながら、インターネットを見渡せばOracle社員以外のエンジニアから膨大な量の情報が発信されていることがわかります。

「昨日はほぼ徹夜でさ。1時間だけ寝たけどSTARTUP MOUNT状態だわ。」

「フリスクでも食ってALTER DATABASE OPENしろよ。」

という会話がエンジニア同士で成り立つほどです。Oracleエコシステムはそれほど大きく、トラブルの対処法や勉強方法、PL/SQLのサンプルなどはたくさん見つかります。開発要員が足りないときに「Oracleわかる人ー」と募集すると「SQLserverわかる人ー」と募集するよりも人が集めやすいように思います。.NETを使っているとプログラムサイドではOracleもSQLserverもさほど違いませんが、基盤系だと層の厚さにはOracleに一日の長があります。（もちろん2世代、3世代前の技術で停滞してしまっている方もいて、混乱を招くこともあるようですが）

しかしここでまた特性の違いという問題があります。一人のOracleエンジニアが見られるOracleデータベースの数とSQLserverデータベースの数は違ってくるでしょう。この点はエンジニアのスキル、システムの難易度など本当に様々なパターンを考えなくてはいけませんのでどちらがどうだと断言することはできません。ただし傾向としては「Oracleは大規模で難易度の高いデータベースに採用されがちで、本気度が高いのでエンジニアも潤沢に投入される」のに対して「SQLserverは複雑なシステムでは敬遠される傾向にあり、必要以上に軽く見られることによってミスを招き不安定な印象がことさらに強調されやすい」ように思います。海外ではまた違うと思いますが、日本人は日本語しか読めないというエンジニアが多いので海外の影響を受けにくく、一度ピラミッドが築かれてしまった以上はしばらくこの傾向が続きそうです。

クラウドについて

つい長くなってしまったのですが、これが言いたくて書き始めたことがあります。クラウド時代が本格化し、RDB以外のデータベースが本格的に勢力を伸ばしてくるとしたらどうなるでしょうか。また、RDB自体が月額いくらという計算になったらどうなるでしょうか。

RDB以外のデータベースとして、キーバリュー型データストアやBigTableのようなRelationalでないデータベースがあります。それらが本格的に使えるようになった場合、こういったデータの形とも連携がしやすいという性質はとても重要なものになるでしょう。

また、運用管理をクラウドの向こうに任せてしまう場合、性能が出にくければなんとかがんばるというのは今と同じと思われます。そうでない場合、性能がそこそこ出ているからCPUやメモリの無駄遣いを気にしない、という方向に向かうかもしれません。となるとクラウドベンダーはそれを受け止めなくてはなりません。容量でいくら、というモデルが成立しないかもしれません。となるとCPUや内部処理されたデータ量でいくらということになると思います。そうなると同じようなシステムを依頼したのにA社のシステムでは月に100ドル、B社のシステムでは500ドルなんていうことがあるかもしれません。

今のところだと「OracleはSQL文をこう解釈するから」というような、深くつっこんだチューニングの世界も広がっており、それがクラウド時代にも通用するかどうかわかりません。クラウドデータセンターの基盤担当者は一人で5000台を見るという話からも、もし容量いくらというモデルでDBサービスが提供されるのであればベンダー側でのSQLの解析や最適化はこれまで以上のレベルで高度に自動化されるであろうことが予想されます。また、基盤に負荷をかけやすいDBサービスの単価よりも、キーバリューストアであったりまだ見ぬ他のDBのほうが安い価格を設定され、技術の中心がそちらへ移っていくかもしれません。RDBがなくなるとは思いませんが、なんでもRDBという考えは長続きしないと思っています。そこのところにおいては、手元においてガチガチに運用してきたOracleよりもMicrosoftのほうがスムーズにオンプレミスからクラウドへの移行ができ、また移行しただけのクラウドからクラウドらしいシステムへの拡張もしやすいのではないか、という気にさせてくれます。

OracleかSQLserverか

本音はどっちでもいいです。手がかからず、性能さえ出てくれれば。

お願い

両社とも素晴らしいデータベース製品を世に送り出しており、改善して欲しいと強く願う点はひとつしかありません。CD-ROM（DVD-ROM）の種類が見分けづらいです。for Linuxとかfor Windowsとか。各バージョンの違いも。脳トレの間違い探しやっているようです。もちろんもらった時点で分類はします。その最初の分類が鬼門です。あとサーバルーム内の作業では不要な媒体は持ち込めませんので、整理されたバインダーから何枚からを手持ちして担当者に入り口で確認してもらって入室する、というような手続きがあるところが多いと思いますが、それをやると中でバラバラになるんですよね。テプラなどのシールを貼っても影響しないとは思いますが、万一にもサーバ機のドライブ壊したら洒落になりませんし貼りません。媒体がお客様の資産であるケースもありますし。そういうわけで媒体がユニバーサルなデザインになって欲しいなぁと思っております。