tempdb データベースの Microsoft SQL Server I/O サブシステムの要件

この記事では、SQL Server の tempdb データベースの I/O サブシステム要件について説明します。

元の製品バージョン: Microsoft SQL Server
元の KB 番号: 917047

まとめ

Microsoft SQL Server では、システム データベースとユーザー データベースを格納するために使用される I/O サブシステムが、特定の I/O プリンシパルを介して先書きログ (WAL) 要件を完全に遵守する必要があります。 トランザクションの ACID プロパティ (Atomic、Consistent、Isolated、Durable) を遵守するには、次の要件が必要です。 I/O サブシステムのコンプライアンス要件の詳細については、 SQL Server I/O の基本を参照してください。

要件の概要を次に示します。

• 書き込みの順序を維持する必要があります。
• 依存書き込みの整合性を維持する必要があります。
• 書き込みは、常に安定したメディアで/で保護する必要があります。
• 破損 I/O 防止が行われる必要があります。

持続性のメンテナンスは、他のすべてのデータベースにとって重要なままですが、tempdb データベースでは緩和される可能性があります。 次の表は、SQL Server データベースの重要な I/O 要件の一部をまとめたものです。

トランザクション セクターの書き換えには、サブシステムによって完全にログに記録された操作が含まれます。この操作により、セクターを元のイメージに完全に移動、置換、またはロールバックできます。 通常、このような操作を実行するために必要なオーバーヘッドが増えるため、これらの書き換えは推奨されません。 その例として、ファイル データを移動する defragmentation ユーティリティがあります。 新しいセクターとデータがセキュリティで保護されるまで、ファイル内の元のセクターを新しいセクターの場所に置き換えることはできません。 障害 (停電など) によって元のデータが再確立されるように、セクターの再マッピングはトランザクション方式で行う必要があります。 この種のプロセス中に、無効なデータ アクセスを防ぎ、SQL Server I/O の他のテナントを維持するためのロック メカニズムがあることを確認します。

停止間の生存

tempdb データベースは SQL Server のスクラッチ領域であり、SQL Server の起動時に再構築されます。 初期化は、再起動後もデータが必要な場合よりも優先されます。

トランザクション セクターの書き換え操作

ロールバックやクラッシュ復旧などの復旧プロセスの成功を保証するには、データ ページが格納される前にログ レコードが安定したメディアに正しく格納されている必要があり、トランザクション プロパティを受け入れないと書き換えられません。 これには、書き込み順序付け、セクターアライン書き込み、サイズ設定された書き込み、前述のドキュメントで説明したその他の I/O 安全属性など、特定の属性を維持するサブシステムと SQL Server が必要です。 tempdb データベースでは、SQL Server の起動時にデータベースが常に初期化されるため、クラッシュ復旧は不要です。 ただし、tempdb データベースには引き続きロールバック機能が必要です。 したがって、WAL プロトコルのいくつかの属性を緩和できます。

tempdb データベースのストレージの場所は、確立されたディスク ドライブ プロトコルに厳密に従って動作する必要があります。 すべての方法で、tempdb データベースが格納されているデバイスが表示され、書き込み後の読み取り機能を提供する物理ディスクとして機能する必要があります。 トランザクション セクターの書き換え操作は、特定の実装の追加要件になる場合があります。 たとえば、SQL Server では、NTFS ファイル システムの圧縮を使用したデータベースの変更はサポートされていません。NTFS 圧縮では、書き込まれ、書き込まれたと見なされたログのセクターが書き換えられる可能性があるためです。 この種類の書き換え中にエラーが発生すると、データベースが使用できなくなる可能性があります。これにより、SQL Server が既にセキュリティで保護されていると見なしたデータが破損する可能性があります。

トランザクション セクターの書き換え操作は、tempdb データベースを含むすべての SQL Server データベースに関連します。 増え続ける拡張ストレージ テクノロジでは、SQL Server がセキュリティで保護されたと見なすデータを書き換えることができるデバイスとユーティリティが使用されています。 たとえば、一部の新しいテクノロジでは、メモリ内キャッシュまたはデータ圧縮が実行されます。 データベースの重大な損傷を回避するには、障害が発生した場合にデータが前のセクター イメージにロールバックされるように、セクターの書き換えに完全なトランザクション サポートが必要です。 これにより、SQL Server が予期しない中断やデータの損傷状態にさらされることはありません。

tempdb データベースは、RAM ディスク、ソリッド ステート、他のデータベースでは使用できないその他の高速実装などの特殊なサブシステムに配置できる場合があります。 ただし、「 詳細情報 」セクションに示されている主な要因は、これらのオプションを評価するときに考慮する必要があります。

詳細

tempdb データベースのストレージの場所を評価するときは、いくつかの要因を慎重に検討する必要があります。 たとえば、tempdb データベースの使用には、メモリ フットプリント、クエリ プラン、I/O の決定が含まれますが、これらに限定されません。 tempdb データベースの適切なチューニングと実装により、システムのスケーラビリティと応答性が向上します。 このセクションでは、tempdb データベースのストレージニーズを決定する際の主な要因について説明します。

高速サブシステム

SQL Server I/O サブシステム プロトコルの要件を提供するが、メディアの持続性を提供しないさまざまな高速サブシステム実装が市場で利用できます。

RAM ディスクは、このような実装の一般的な例の 1 つです。 RAM ディスクは、必要なドライバーをインストールし、メイン RAM ディスクの一部がシステムに接続されている任意のディスク ドライブと同様に表示され、機能できるようにします。 すべての I/O サブシステムは、SQL Server I/O 要件に完全に準拠している必要があります。 ただし、RAM ディスクが永続メディアではないことは明らかです。 そのため、RAM ディスクなどの実装は tempdb データベースの場所としてのみ使用でき、他のデータベースには使用できません。

実装とデプロイの前に考慮すべきキー

この種のサブシステムに tempdb データベースをデプロイする前に、さまざまな点を考慮する必要があります。 このセクションでは、RAM ディスクをディスカッションの基礎として使用しますが、他の高速実装でも同様の結果が発生します。

I/O の安全性

書き込み後の読み取りとトランザクション セクターの書き込みのコンプライアンスは必須です。 SQL Server I/O 要件を完全にサポートしていないシステムに SQL Server を展開したり、データの損傷や損失を危険にさらしたりしないでください。

既にキャッシュされているページ (ダブル RAM キャッシュ)

一時テーブルは、データベース内の他のすべてのテーブルと同様です。 これらはバッファー プールによってキャッシュされ、遅延書き込み操作によって処理されます。 RAM ディスクに一時テーブル ページを格納すると、バッファー プールに 1 つと RAM ディスクに 1 つずつ、2 つの RAM キャッシュが発生します。 これにより、バッファー プールの使用可能な合計サイズが直接取り除かれるので、一般に SQL Server のパフォーマンスが低下します。

RAM をあきらめる

RAM ディスクは、名前が示すようにメイン RAM の一部を指定します。 RAM ディスクと RAM ベースのファイル キャッシュには、いくつかの実装があります。 一部では、物理 I/O バッキング操作も有効になります。 RAM ベースのファイル キャッシュの重要な要素は、SQL Server で使用できる物理メモリから直接取り除くということです。 RAM ベースのファイル キャッシュを追加すると、アプリケーションのパフォーマンスが向上し、他のクエリやアプリケーションのパフォーマンスが低下しないという強力な証拠が常に存在します。

最初にチューニングする

アプリケーションは、tempdb データベースの使用を引き起こす可能性がある不要な並べ替えとハッシュを削除するように調整する必要があります。 インデックスを追加すると、プランでの並べ替えやハッシュの必要性が完全に解消され、tempdb データベースを使用しなくても最適なパフォーマンスが得られます。

考えられる特典ポイント

tempdb データベースを高速システムに配置する利点は、アプリケーション ワークロードの厳密なテストと測定によってのみ決定できます。 tempdb データベースが恩恵を受ける可能性がある特性については、ワークロードを慎重に検討する必要があります。また、デプロイ前に I/O の安全性を確認する必要があります。

並べ替え操作とハッシュ操作は、SQL Server メモリ マネージャーと連携して、並べ替え操作またはハッシュ操作ごとにメモリ内スクラッチ領域のサイズを決定します。 並べ替えまたはハッシュ データが割り当てられたメモリ内スクラッチ領域を超えるとすぐに、データが tempdb データベースに書き込まれる可能性があります。 このアルゴリズムは SQL Server で拡張され、以前のバージョンの SQL Server よりも tempdb データベースの使用要件が減りました。

SQL Server では、tempdb データベースを使用して、並べ替え、ハッシュ、行バージョン ストア、および一時テーブルを含むさまざまなアクティビティを処理します。

• 一時テーブルは、データ ページの共通バッファー プール ルーチンによって管理され、通常は特殊サブシステムの実装によるパフォーマンス上の利点を示しません。
• tempdb データベースは、ハッシュと並べ替えのスクラッチ領域として使用されます。 このような操作の I/O 待機時間を短縮すると、有益な場合があります。 ただし、ハッシュや並べ替えを回避するためにインデックスを追加すると、同様の利点が得られる可能性があります。

高速サブシステムに格納されている tempdb データベースの有無に関係なくベースラインを実行し、利点を比較します。 テストの一部として、並べ替え、ハッシュ、または一時テーブルを含まないユーザー データベースに対するクエリを含め、これらのクエリが悪影響を受けないことを確認する必要があります。 システムを評価する際には、次の業績評価指標が役立ちます。

トランザクション セクターの書き換えの例

次の例では、SQL Server データベースに必要なデータ セキュリティについて詳しく説明します。

RAM ディスク ベンダーがメモリ内圧縮実装を使用しているとします。 ファイル ストリームの物理的な外観を提供して、セクターがアラインされ、サイズが設定されたかのように、SQL Server が認識され、基になる実装から正しくセキュリティで保護されるように、実装を正しくカプセル化する必要があります。 圧縮の例を詳しく見てください。

• セクター 1 はデバイスに書き込まれ、領域を節約するために圧縮されます。
• セクター 2 はデバイスに書き込まれ、領域を節約するためにセクター 1 で圧縮されます。

デバイスは、セクター 1 のデータをセクター 2 のデータと組み合わせたときにセキュリティで保護するために、次のアクションを実行できます。

• セクター 1 とセクター 2 へのすべての書き込みをブロックします。
• セクター 1 をスクラッチ領域に圧縮解除し、現在のセクター 1 ストレージを取得するアクティブ なデータのままにします。
• セクター 1 と 2 を新しいストレージ形式に圧縮します。
• セクター 1 とセクター 2 のすべての読み取りと書き込みをブロックします。
• セクター 1 とセクター 2 の古いストレージを新しいストレージと交換します。 交換の試行が失敗した場合 (ロールバック):
  • セクター 1 とセクター 2 の元のストレージを復元します。
  • セクター 1 と 2 の結合されたデータをスクラッチ領域から削除します。
  • セクター 2 の書き込み操作を失敗します。
• セクター 1 とセクター 2 の読み取りと書き込みのブロックを解除します。

セクターの変更に関するロック メカニズムを提供し、セクター交換の試行が失敗したときに変更をロールバックする機能は、移行に準拠しているとみなされます。 拡張バッキングに物理ストレージを使用する実装では、SQL Server データベース ファイルの整合性を維持するためにディスク上の構造に適用された変更をセキュリティで保護およびロールバックするのに役立つ適切なトランザクション ログの側面が含まれます。

セクターの書き換えを有効にするすべてのデバイスは、SQL Server がデータ損失にさらされないように、トランザクション的な方法で書き換えをサポートする必要があります。

tempdb データベースを移動するときは注意してください

tempdb データベースを作成できない場合は SQL Server が起動しないため、tempdb データベースを移動するときは注意してください。 tempdb データベースを作成できない場合は、(-f) スタートアップ パラメーターを使用して SQL Server を起動し、tempdb データベースを有効な場所に移動します。

tempdb データベースの物理的な場所を変更するには、次の手順に従います。

1. ALTER DATABASE ステートメントと MODIFY FILE 句を使用して、tempdb データベース内の各ファイルの物理ファイル名を変更し、新しいディスクなどの新しい物理的な場所を参照します。

   ALTER DATABASE tempdb MODIFY FILE 
   (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')
   
   ALTER DATABASE tempdb MODIFY FILE 
   (name = templog, filename = 'C:\MyPath\templog.ldf')
   

2. SQL Server を停止してから再起動します。

パートナー製品の認定は、互換性や安全性の保証ではありません

サード パーティ製品または特定のベンダーは、Microsoft ロゴ認定を受けることができます。 ただし、パートナー認定または特定の Microsoft ロゴでは、SQL Server の特定の目的に対する互換性や適合性は認定されません。

サポート

この記事で説明されているように、トランザクション データベースの使用に対する I/O 保証をサポートする SQL Server でサブシステムを使用する場合、Microsoft は SQL Server および SQL Server ベースのアプリケーションをサポートします。 ただし、サブシステムに関する問題、または原因により発生した問題は、製造元と呼ばれます。

tempdb データベース関連の問題の場合は、Microsoft サポート Services から tempdb データベースの再配置が求められます。 トランザクション データベースを使用するためにデバイスが正しく展開および構成されていることを確認するには、デバイス ベンダーに問い合わせてください。

Microsoft は、サードパーティ製品が SQL Server で正しく動作することを認定または検証しません。 また、Microsoft は、SQL Server での使用に対するサードパーティ製品の適合性に関する保証、保証、または声明を提供しません。

関連情報

詳細については、以下を参照してください。

• エラー メッセージ 823 は、SQL Server のハードウェアの問題またはシステムの問題を示している可能性があります

• SQL Server でのディスク ドライブ キャッシュの使用

• SQL Server でのネットワーク データベース ファイルのサポートの説明

• Microsoft は、サード パーティ製品が Microsoft SQL Server と連携することを認定しません

• Azure Virtual Machines 上の SQL Server のパフォーマンスに関するガイドライン

• SQL Server 2014 のカーディナリティ推定機能によるクエリプランの最適化

• クエリのパフォーマンス

• SQL Server データベース エンジン のディスク入出力 (I/O) の要件