パフォーマンスのために、独自のドライブアレイ上のtempdbをいくつかのファイルに分割しています。非データドライブにDBログファイルがあります。 tempDBログファイルをすべてのDBまたは他の場所のログドライブに配置する必要があるかどうかを疑問視しますが、temdbデータファイルから分離します。
私はこれについて心配したことがありません。 MSのサイトを見ると、tempdbのログが最小限に抑えられていることがわかります。それはおそらくあなたにとって問題ではないかもしれません。そしてもちろん、時期尚早に最適化することはお勧めできません。つまり、現実的な負荷の下で現在の環境をテストする前です。すべての条件のSQL構成に関する単一のベストプラクティスはありません。
バイナリトランザクションログについて話しているのですか、それともプレーンテキストのアプリケーションログファイルについて話しているのですか?データベースワークロードの一般的なベストプラクティスは、トランザクションログをデータストアとは異なる物理ディスクに保持することです。これにより、トランザクションログでシーケンシャル書き込みがシーケンシャルに保たれ、キャッシュチャーンが最小限に抑えられるため、両方のボリュームでのキャッシュヒット率が向上します。
従来の見方では、ユーザーデータベースのデータファイルは1つのドライブに、ユーザーデータベースのログファイルは別のドライブ(これは実際に高速レイテンシが必要なドライブです)に、TempDBは別のドライブに配置する必要があります。ログとデータファイルは、それらを互いに分離する以外に、非常に異なるIO特性を持っています。
SAN管理者は通常、DBAにディスクの大きなチャンクの一部を切り分けて提供したため、SANの外観によって状況が変わりました。パフォーマンスの違いはそれほど明白ではありませんでした。
DBAは、データファイルをログからTempDBから分離したと考えていた可能性があるため、仮想化によって状況はさらに変化しましたが、VM管理者は、これらすべての異なる「ドライブ」を同じ物理ドライブに配置しました-VMの世界では、これらのドライブは単なるファイルです。
私の見解では、データファイル、ログファイル、およびTempDBのファイルを別々に保持することは依然として良いことです-それらの1つが肥大化した場合、それを修正するためにもう少し時間がかかることを願っています-そしてそれはすべてを破壊することはありません。
それが可能な場合でも、ベストプラクティスは、データファイルとログファイルを別々に保つことです。TempDBも別々に保つことができれば、すばらしいことです。一部のアプリケーション、特に読み取りコミットスナップショットアイソレーションを使用するアプリケーションは、TempDBを多用します。
はい、TempDBログファイルとデータファイルを別々のドライブに配置することをお勧めします。いつものように、トランザクションが両方のファイルに同時に書き込むときに、すべてのDB |のデータファイルとすべてのDBのログファイルを別々のドライブに配置します。したがって、TempDBファイルにも同じ概念が適用されます。