「中堅企業向け オラクル都市伝説シーズン2: 其の一」への反論
マイクロソフトの北川です。
本日とあるページが日本オラクル社のウェブサイトに掲載されていることを確認しました。このブログ記事をアップすることで、当該ページが削除されてしまうと何に対しての反論なのかわからなくなりますので、魚拓へのリンクを作っておきました。
日本オラクル社ウェブサイト：2009年8月27日取得 ウェブ魚拓
中堅企業向け オラクル都市伝説シーズン2: 其の一
要は、SQL Server のトランザクション ログが自動拡張されることを揶揄した記事なのですが、本文中には「本当に SQL Server の運用を理解して書かれたのか」また「ディスク ミラーリングの仕組みを理解して書かれたのか」が疑問な箇所があります。
以下疑問点と、SQL Server の運用に関しての補足を行いたいと思います。
トランザクション ログ ファイルの肥大化について
SQL Server では、ログを循環利用しますが、トランザクションの量によっては再利用ができず、トランザクション ログ ファイルの拡張を行います。SQL Server が自習書をはじめとしてその運用方法としてガイドしている内容は運用監視を行い、1日当たりのトランザクション ログ ファイルの増加量を確認したうえで、トランザクション ログ ファイルの自動拡張が不要なサイズのトランザクション ログ ファイルを確保することと合わせて、定期的なトランザクション ログ ファイルのバックアップを計画する
というものです。こうすることで、トランザクション ログ ファイルの肥大化を防止し、日本オラクルのサイトに書かれているようなトラブルを防止することができます。また、その設定に関しても下記のように「メンテナンス プラン ウィザード」を使用して簡単に設定することが可能です。
図1: メンテナンス プラン ウィザードによるバックアップの設定図1 の画面で「データベースのバックアップ(完全)」「データベースのバックアップ(トランザクション ログ)」を選択して自動処理させるように設定しておけば、肥大化は防止できます。また、もし肥大化してしまったとしても、上記処理を実行した後で「データベースの圧縮」を実行することで、縮小を行うことも可能です。
なお、上記日本オラクルのサイトに書かれているような状況は、Oracle Database において、アーカイブ ログを書き込む領域がいっぱいになってしまったときと同じ状況です。アーカイブ ログを作成できない場合、Oracle Database であっても処理が止まってしまいます。
Oracle Database をアーカイブ ログ モードで運用する際には、アーカイブ ログを適宜削除して領域を確保する必要があります。これは、Oracle Database の運用管理にも描かれている事項です。なぜ、Oracle Database の運用では上記処理を想定していながら、SQL Server では上記のようなガイドがなされているにもかかわらず、それが「行えない」ような記載をされているのか理解に苦しみます…。
壊れたログファイルがそのまま二重化されていた(ミラーディスクに壊れたトランザクション ログ ファイルが書き込まれていた)
今回の記事で最も納得がいかない部分です。
SQL Server にとって、トランザクション ログ ファイルを多重化できないという弱点があることは事実です。ですので、RAID 1 構成のディスク上にトランザクション ログ ファイルを格納することをガイドしています。今回の日本オラクル社の記事では、RAID 1 ディスク上にトランザクション ログ ファイルを置いていたにもかかわらず、ログファイルが破損し、多重化されたディスクにその破損したログファイルが書き込まれたことになっています。
RAID 1 の構成では、ディスクに書き込まれた内容がミラーディスクにも反映されることになっていますので、上記想定は「SQL Server が論理的に誤ったトランザクション ログをディスクに書き込んだ」ということを意味しています。
これはひどい誹謗中傷です。
製品に関して事実無根の誹謗中傷を行い、ユーザーに対して誤った事実を植え付けようとする姿勢は容認できるものではありません。
機能的に不十分であるという印象を与えようとしているのかもしれませんが、SQL Server において、トランザクション ログ ファイルの論理障害が発生するようなことはありません。もしこれが「論理障害が発生する可能性」に関しての言及なのであれば、Oracle Database でも発生し得ますし、その場合、Oracle Database のログの多重化でも対応することはできません。上記を踏まえると、トランザクション ログの障害は特定のディスクにおける物理障害であるはずですので、ミラーディスクから無事に復旧できることになります。
注：
Oracle Database の例によると、ログ ファイルの障害は多重化されたログにより解決されるとのことですので、おそらく本記事を書かれた方の想定は「物理障害」だったのでしょう。とすると、記事を書かれた方は RAID 1 の仕組みを正しく理解されていないのですね…。SQL Server ではログ ファイルの論理障害を想定し、Oracle Database では物理障害。同じ条件での比較にしてほしいものです。
上記サイトにはまとめとして下記の文言が記載されています。
ログファイルが肥大化しないOracle Databaseを選択すれば、この地獄から無事生還することは容易だ。それどころか、地獄を経験せずに済む仕組みが随所に施されている。
Oracle Database では確かにログファイルの肥大化は発生しないかもしれません。ただし、ユーザーが削除しない限りアーカイブ ログが蓄積され、ディスク容量を圧迫します。アーカイブ ログが取得できなければ Oracle Database といえども停止してしまいます。そのため、Oracle Databsae はその運用方法としてバックアップ取得後にアーカイブ ログの削除を行うようにガイドしています。
同じく、SQL Server にもログ ファイルの肥大化を防ぎ、無用な障害を防止するためのガイドや仕組みが用意されています。Oracle Database の運用と同じく、これらのガイドに従えば、日本オラクル社のページに記載されているようなことは発生しないということをご理解ください。
このような「**本当にあった怖い話」として事実無根の誹謗中傷に近い記事が掲載されたままになるのであれば、明らかな不実告知**に当たりますので、何らかの手段を講じる必要があるのかもしれません。
都市伝説シーズン2に関してはこれからも十分な注意を払い、事実と異なる情報を流布されないようにしたいと思います。