1. 使用率が上がりすぎてデータベースサーバがワークロードを処理できなくなった場合、ログデータベースを別のサーバに移せる。また、ログデータベースを複数のサーバに置けば、ワークロードをさらに分散できる。
2. このデータ分離アーキテクチャによって、ログデータやイベントデータを中央のデータウェアハウスに移動することや、ログデータベースから定期的にデータを削除することが容易になる。
3. データを分離しておけば、アプリケーションデータベースの規模を抑えることができる。これによって関連する管理作業だけでなく、開発環境やQA（品質保証）環境、ステージング環境へのデータコピーが容易になる。
4. データベースの使用率が上がると、アプリケーションは、ビジーサーバで発生するタイムアウトなどの問題によって、多くのエラーログを残す傾向がある。ログデータがアプリケーションで使われるデータと同じデータベースに保存されている場合、アプリケーションがエラーログを残すと、サーバの負荷をさらに増やし、問題を悪化させる恐れがある。だが、データ分離アーキテクチャを採用すれば、こうした事態を避けられる。
5. ログデータベースを独立したサーバで動かしている場合、SQL ServerのStandard Editionが使えるかもしれない。アプリケーションのバックエンドデータベースに要求されるような高い可用性は必要ないことが多いからだ。

　このアーキテクチャによるイベントログ管理のアプローチでは、複数のアプリケーションのログデータを1カ所に集約できる。アプリケーションが記録したログデータを、複数の場所にアクセスして分析するのではなく、中央の1カ所にログインして分析することが可能だ。

　私は、複数の安価なロギングサーバを運用し、それらから毎日、データウェアハウスにデータを取り込む方式が気に入っている。このアーキテクチャでは、ロギングサーバを簡単に追加できる他、このロギングフレームワークを使用するアプリケーションの接続文字列を変更するだけで、ロギング先をあるサーバから別のサーバに切り替えることも選択できる。

　ログデータのタイプごとに多様なデータを記録する必要があるかもしれないため、最初はデータの一部をXMLドキュメントとして保存するとよいだろう。そうすれば、データをデータウェアハウスに移動する際に、イベントタイプに基づいてXMLノードを解析し、クエリとレポーティングが容易なリレーショナルテーブルにデータを抽出できる。

　エラーログを記録するための書き込みコードは既存のものが利用できるため、最初から作り直す必要はない。幾つかのオープンソースのライブラリが公開されており、ダウンロードして自社のソリューションに統合できる。その一例としてLog4Netがある。Log4Netは、ロギングフレームワークであるApache log4jから移植された.NETライブラリだ。非常に使いやすいライブラリであり、良い出発点になる。そのまま使えるし、独自のコードで拡張して自社のロギング要件に対応させることもできる。

　自分の経験を踏まえ、最初からデータの廃棄方針を立てておくこともお勧めする。大量のデータを記録していると、Tバイト規模のログデータがどんどん蓄積され、管理や廃棄が難しい状況に陥るかもしれない。

　1つの解決策は、イベントを分類し、各タイプのログデータの保存期間を決め、定義したしきい値を基に、保存期間が終了した行を削除するという廃棄作業だ。場合によっては、データの集計値（例えば、ボタンが1日当たり何回クリックされたか、データベースのタイムアウトが特定の時間帯に何回発生したかなど）だけを保存すればよい。

　ログおよびイベントデータを分離するアーキテクチャは、負荷分散、リポーティングの集中管理、高可用性要件の簡素化などのメリットをもたらす。以上のステップを実践することで、SQL Serverデータベースのパフォーマンスが改善されるだろう。