高トラフィック/ボリュームテーブルに個別のデータベースを使用する理由

Question

私が使用しているアプリケーションのデータベース構造を見ていると、同じSQL Serverインスタンスで3つの異なるデータベースを使用していることがわかりました。

最初のものには、ほとんど変更されないメインデータが含まれています。

2つ目は、トラフィックとボリュームが多いイベントログを含み、最後の1つは古いイベントログのアーカイブデータベースです。

データベースが同じインスタンスで実行されており、データベースファイルが同じディスクに配置されているため、この構造の利点は何だろうと思いました。したがって、これによるパフォーマンスの向上は期待できません。

多分私は何かを見落としていて、誰かが私が考えていなかった利点を私に指摘することができると思いました。

更新：
メンテナンスとセキュリティに関していくつかの良い点がありました。しかし、私はまだパフォーマンスの改善を得ることが可能かどうか疑問に思っています。

より一般的な質問は次のとおりです。1つのテーブルのパフォーマンスが同じデータベース内の他の大きなテーブルの影響を受けますか（フラグメンテーションまたはその他の理由により）、またはそれらの影響はおそらく無視できますか？.

Jensd · Accepted Answer

ソリューションを設計した開発者/アーキテクトに質問してください。彼らだけが本当に知ることができます。いくつかの理由が考えられます。

データベースが異なる時間に追加された可能性があります。最初にメインデータベース、次にイベント用のデータベースが必要で、最後に古いデータを保存する場所を決定しました。環境によっては、既存のデータベースに多数の新しいテーブルを追加するよりも、新しいデータベースを作成する方が簡単な場合があります。私は時々本番データのバックアップを取り、読み取り専用アーカイブとしてオンラインにして、現在のデータベースからすべての古いデータを削除するシステムに取り組んできました-したがって、同時にいくつかの古いデータベースを利用できます。
将来の使用：多分彼らはシステムが最終的に異なるサーバー（または多分その高トラフィックデータベースのためのより高速なディスク）に分割される必要があると考えました。
異なるバックアップ時間の計画など。アーカイブがバックアップのためにダウンすることはないが、24時間年中無休の統計で利用できる場合があります。本番環境は毎日またはさらに頻繁にバックアップされ、イベントログの他の計画はありますか？

実際には、上記のすべて、一部、またはまったくない可能性があります...

Brent Ozar · Answer

ここには2つの異なる質問があり、個別に回答します。

Q：1つのテーブルのパフォーマンスが同じデータベース内の他の大きなテーブルの影響を受ける可能性はありますか？

はい、挿入/更新/削除中です。 SQL Serverには、データベースごとに1つのログファイルしかありません。挿入/更新/削除すると、データがログファイルに書き込まれるまでトランザクションは完了しません。

2つのテーブルがあるとします。

ドキュメント-ものの大きなXML表現を格納します。 IDとXMLフィールドの2つのフィールドしかありませんが、レコードが小さいという意味ではありません。ここに挿入する場合、XML全体をログファイルに書き込む必要があり、XMLドキュメントはそれぞれ5〜10 MBになる傾向があります。
注文-Webサイトからの注文を保存します。これは小さなテーブルです-XMLまたはVARCHAR（MAX）フィールドはなく、顧客と製品のIDがいくつかあります。ここで挿入すると、1Kになります。

これらのテーブルが両方とも同じデータベース内にあり、ドキュメントの作成中にも注文しようとすると、注文トランザクションのパフォーマンスが低下する可能性があります。

さて、これは極端な例ですが、一般的に、これが重要度が低く、値が大きく、幅が狭いレコードテーブルを、それほど重要ではなく、値が大きく、幅が広いレコードテーブルとは別のデータベースに格納することをお勧めします。ただし、両方のテーブルのセットをまったく同じ時点に復元する必要がある場合、またはサーバー間でそれらを一緒にフェイルオーバーする必要がある場合は、同じデータベース内にある必要があります。 SQL Serverは、AlwaysOn可用性グループなどのフェイルオーバー時のデータベース間のトランザクションの一貫性を保証しません。

Q：変化の速いデータ、変化の遅いデータ、変化のないデータがある場合、それらを異なるデータベースに分離する必要がありますか？

はい、いくつかの理由により：

さまざまなバックアップスケジュール-変化の速いデータをできるだけ速くバックアップする必要があります。一般に、人々は単一のバックアップジョブを使用して、すべてのデータベースのフルバックアップを実行します。多くの場合、フルバックアップを実行するときにトランザクションログのバックアップを実行しません。 10 GBの高速で変化するデータベースと1 TBの変化しないデータベースがあり、単一の完全バックアップジョブを使用する場合、1 TBの完全バックアップの実行中にトランザクションログのバックアップを取得できない可能性があります。これは、潜在的なデータ損失のより大きなウィンドウです。個別のバックアップジョブまたはより厳しいスケジュールでこれを軽減できます。あなたが本当にやりたいことは、決して変化しないデータのバックアップを避けることです-より少ないIOロード、より少ないバックアップファイルをテープにシャッフルするために。
インデックスの再構築と統計の更新ジョブが異なる-変更されていない大規模なデータベースでインデックスの再構築/デフラグを実行したくない。理想的には、すべてのインデックスを100％FILL FACTORで再構築し、フルスキャンで統計を更新し、データベースを読み取り専用に設定します。プレスト、高密度のページ、面倒なロックなしの高速パフォーマンス。（さらに、偏執的なDBAとして、私は誰もそれをそのように変更しないことを確認できます。）
さまざまなHA/DR戦略-変更がほとんどない大規模で安定したデータベースがある場合、それを読み取り専用モードにして、その読み取り専用コピーを障害復旧環境に復元します。プライマリデータセンターからセカンダリにデータをコピーする場合、頻繁に変更されるデータについてのみ心配する必要があります。