VM を使用して Azure クラウドに SQL サーバーをセットアップしています。data/logs/tempdb の最適なセットアップを決定していたとき、Azure が提供する一時ストレージ ドライブに tempdb を配置することを推奨する多くのブログ投稿に出くわしました。ただし、より詳細な調査により、これを行うべきではないと言われているMicrosoft からのこの情報が明らかになりました。
したがって、次の質問が残ります。
最初の推奨事項は tempdb を D: ドライブに配置することだったので、これについては多少の混乱があります。これはもはや真実ではありません。最新情報については、http://msdn.microsoft.com/en-us/library/windowsazure/dn248436.aspx にあるホワイト ペーパー「Windows Azure 仮想マシンでの SQL Server のパフォーマンス ガイダンス」を読むことをお勧めします。
TempDB セクションの抜粋を次に示します。
「Windows Azure 仮想マシンのディスクとキャッシュの設定」セクションで説明したように、一時ディスク (D:) ではなく、オペレーティング システム ディスクまたはデータ ディスクに tempDB を配置することをお勧めします。以下は、SQL Server テスト ワークロードを使用した内部テストに基づく、この推奨事項の 3 つの主な理由です。
• パフォーマンスの差異: テストでは、オペレーティング システムまたは単一のデータ ディスクからの IOPS が増えない限り、D: と同じレベルのパフォーマンスが得られることがわかりました。ただし、D: ドライブのパフォーマンスは、オペレーティング システムやデータ ディスクほど予測可能であるとは限りません。これは、D: ドライブのサイズとそこから得られるパフォーマンスが、使用する仮想マシンのサイズに依存するためです。
• VM のダウンタイム時の構成: 仮想マシンが (計画的または予期しない理由で) シャットダウンされた場合、SQL Server が D: ドライブの下に tempDB を再作成するには、SQL Server サービスが開始されたサービス アカウントが必要です。ローカル管理者権限を持っています。さらに、オンプレミスの SQL 展開の一般的な方法は、データベースとログ ファイル (tempDB を含む) を別のフォルダーに保持することです。この場合、SQL Server を起動する前にフォルダーを作成する必要があります。ほとんどのお客様にとって、この余分な再構成のオーバーヘッドは見返りに値しません。
• パフォーマンスのボトルネック: D: ドライブに tempdb を配置し、アプリケーション ワークロードが tempDB を頻繁に使用する場合、D: ドライブが IOPS スループットの制約をもたらす可能性があるため、パフォーマンスのボトルネックが発生する可能性があります。代わりに、tempDB をオペレーティング システムまたはデータ ディスクに配置して、柔軟性を高めます。tempdb を最適化するための構成のベスト プラクティスの詳細については、「SQL Server TempDB IO のベスト プラクティスのコンパイル」を参照してください。
更新: 一時ドライブが D シリーズ Azure VM の SSD として利用できるようになったため、@CSharpRocks によって引用されたホワイトペーパーは少し古くなっています。最近の推奨事項については、次の 2 つの記事を参照してください (2014 年後半から 2015 年半ばまで)。
上記の記事では、tempdb とバッファー プール拡張機能を D:\ に配置することが明示的に言及されています。抜粋：
D シリーズの仮想マシン (VM) を使用する場合は、D ドライブに tempdb および/またはバッファー プール拡張機能のみを格納します。他の VM シリーズとは異なり、D シリーズ VM の D ドライブは SSD ベースです。これにより、一時オブジェクトを大量に使用するワークロードや、メモリに収まらないワーキング セットを持つワークロードのパフォーマンスを向上させることができます。