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

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

元の製品バージョン:Microsoft SQL Server 2005、SQL Server 2008、SQL Server 2012 SQL Server 2014
元の KB 番号: 917047

概要

Microsoft SQL Serverでは、システム データベースとユーザー データベースを格納するために使用される I/O サブシステムが、特定の I/O プリンシパルを通じて Write-Ahead ログ記録 (WAL) 要件を完全に満たす必要があります。 これらの要件は、トランザクションの ACID プロパティ (Atomic、Consistent、Isolated、Durable) を満たすために必要です。 I/O サブシステムのコンプライアンス要件の詳細については、次のリファレンスを参照してください。

SQL Server 2000 I/O の基本https://technet.microsoft.com/library/cc966500.aspx

次の一覧は、要件の簡単な概要です。

• 書き込みの順序を維持する必要があります。
• 依存書き込みの整合性を維持する必要があります。
• 書き込みは、常に安定したメディアで/で保護する必要があります。
• 破損した 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 データベースのストレージニーズを判断する際の主な要因について説明します。

高速サブシステム

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

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 ディスクに一時テーブル ページを格納すると、バッファー プールと RAM ディスクに 1 つずつ、二重 RAM キャッシュが発生します。 これにより、バッファー プールの可能な合計サイズが直接取り除かれるので、一般にSQL Serverのパフォーマンスが低下します。

RAM を解放する

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

最初にチューニングする

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

考えられる特典ポイント

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

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

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

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

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

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

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

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

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

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

• セクター 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 DATABASEMODIFY 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 サポート サービスから tempdb データベースの再配置が求められます。 トランザクション データベース用にデバイスが正しくデプロイおよび構成されていることを確認するには、デバイス ベンダーに問い合わせてください。

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

関連情報

詳細については、次のマイクロソフト サポート技術情報を参照してください。

• 報告されていない I/O の問題を検出するために追加のSQL Server 診断が追加されました

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

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

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

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

• Azure Virtual Machines でのSQL Serverのパフォーマンス ガイドライン

• SQL Server 2014 カーディナリティ推定機能を使用したクエリ プランの最適化

• クエリ パフォーマンス