SQL Server I/O の基礎

適用対象:SQL ServerAzure SQL Managed InstanceAzure VM 上の SQL Server

SQL Server データベースの主な目的はデータの格納と取得であるため、データベース エンジンの主要な特性は頻繁なディスクの入出力 (I/O) ということになります。 ディスク I/O 操作は多くのリソースを消費するうえ、完了するのに比較的長い時間がかかるため、 SQL Server では I/O の効率を上げることに重点を置いています。

SQL Server のストレージ サブシステムは、メカニカル ドライブやソリッド ステート ストレージなど、複数のフォーム ファクターで提供されます。 この記事では、ドライブ キャッシュの原則を使用して、データベース エンジン I/O を改善する方法について詳しく説明します。

SQL Server では、SQL Server I/O 信頼性プログラムの要件に関する説明に従って、システムが安定したメディアへの確実な配信をサポートする必要があります。 SQL Server データベース エンジンの入力と出力の要件の詳細については、「SQL Server データベース エンジン ディスクの入出力 (I/O) の要件」を参照してください。

ディスク I/O

バッファー マネージャーはデータベースの読み取りと書き込みだけを行います。 他のファイル操作やデータベース操作 (開く、閉じる、拡張、圧縮など) は、データベース マネージャー コンポーネントおよびファイル マネージャー コンポーネントによって実行されます。

バッファー マネージャーによるディスク I/O 操作には、次の特性があります。

• I/O は非同期で実行されます。つまり、呼び出し側スレッドでの処理中でも、I/O 操作はバックグラウンドで進行します。 状況によっては (ログ I/O の位置がずれているなど)、同期 I/O が発生する可能性があります。

• すべての I/O は affinity I/O mask オプションが使用中でなければ、呼び出し側スレッドで発行されます。 affinity I/O mask オプションでは、 SQL Server のディスク I/O が、指定した CPU のサブセットに関連付けられます。 ハイエンドな SQL Server オンライン トランザクション処理 (OLTP) 環境では、この拡張機能により、I/O を発行する SQL Server スレッドのパフォーマンスを向上できます。

• 複数ページの I/O は、スキャッター/ギャザー I/O を使用して実行されます。スキャッター/ギャザー I/O を使用すると、連続しないメモリ領域との間でデータを転送できます。 つまり、SQL Server は、複数の物理 I/O 要求を回避しながら、バッファー キャッシュをすばやく使用またはフラッシュできます。

実行時間の長い I/O 要求

バッファー マネージャーは未処理状態が 15 秒以上続いている I/O 要求を報告します。 これはシステム管理者が SQL Server の問題か I/O サブシステムの問題かを区別するのに役立ちます。 SQL Server のエラー ログには、次のようにエラー メッセージ MSSQLSERVER_833 が報告および記録されます。

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

実行時間の長い I/O は読み取りまたは書き込みのどちらかの処理ですが、どちらの処理なのかはメッセージに示されません。 実行時間の長い I/O のメッセージは、警告であってエラーではありません。 Sこれらは SQL Server の問題ではなく、基礎になっている I/O システムの問題を示します。 これらのメッセージが報告されることにより、システム管理者は、SQL Server の応答時間が遅い原因を追究したり、SQL Server の制御の範囲外にある問題を見分けたりするのに役立てることができます。 このように、メッセージに対するアクションは不要ですが、システム管理者は I/O 要求が長時間かかっている理由や、かかっている時間が正当であるかどうかを調べる必要があります。

実行時間の長い I/O 要求の原因

実行時間の長い I/O のメッセージは、I/O が永続的にブロックされていて決して完了しないこと (ロスト I/O ともいいます) を示す場合があります。または、I/O が単純にまだ完了していないことを示す場合があります。 この場合、どちらのシナリオなのかをメッセージから区別することはできません。ただ、ロスト I/O の結果、ラッチ タイムアウトが生じることがよくあります。

多くの場合、実行時間の長い I/O は、SQL Server のワークロードによってディスク サブシステムに過度の負荷がかかっていることを示します。 ディスク サブシステムが不十分だと、次の現象が発生することがあります。

• 負荷の高い SQL Server ワークロード中に、実行時間の長い I/O のメッセージがエラー ログに複数記録される。
• パフォーマンス モニターに、長時間ディスクが遅延している、長時間ディスク キューに登録されている、ディスクのアイドル時間がないといった情報が表示される。

実行時間の長い I/O は、I/O パス内のコンポーネント (ドライバー、コントローラー、ファームウェアなど) が原因になっている場合もあります。新しい I/O 要求の処理を優先して、古い I/O 要求の処理を絶えず延期するためです。 これは、iSCSI やファイバー チャネル ネットワークなどの相互接続された環境で発生する可能性があります (構成の誤りまたはパス障害が原因)。 これはパフォーマンス モニター ツールと連携させるのが困難である場合があります。大半の I/O は速やかに処理されるためです。 実行時間の長い I/O 要求は大容量のシーケンシャル I/O を実行するワークロードによって増大することがあります。たとえば、バックアップおよび復元、テーブル スキャン、並べ替え、インデックスの作成、一括読み込み、ファイルの占有領域の解放処理などがあります。

実行時間の長い I/O のうち、以前の状態には関係ないと考えられる孤立した I/O は、ハードウェアやドライバーの問題が原因になっている場合があります。 システム イベント ログには、問題の診断に役立つ関連イベントが含まれていることがあります。

非効率的なクエリまたはフィルター ドライバーによって発生する I/O パフォーマンスの問題

I/O が遅い原因として、効率的に書き込まれていないクエリや、インデックスと統計を使用して適切にチューニングされていないクエリが考えられます。 I/O 待機時間のもう 1 つの一般的な要因は、データベース ファイルをスキャンするウイルス対策プログラムまたはその他のセキュリティ プログラムの存在です。 このスキャン ソフトウェアはネットワーク層に拡張される可能性があり、ネットワーク待機時間が増加し、間接的にデータベースの待機時間に影響を与えます。 15 秒の I/O について説明したシナリオはハードウェア コンポーネントで一般的ですが、最適化されていないクエリやウイルス対策プログラムが正しく構成されていない場合は、I/O 待機時間が短くなる可能性が高くなります。

これらの問題に対処する方法の詳細については、「I/O によって発生する SQL Server のパフォーマンス低下の問題のトラブルシューティング」を参照してください。

SQL Server でウイルス対策保護を構成する方法については、「SQL Server で動作するようにウイルス対策ソフトウェアを構成する」を参照してください。

ストレージ コントローラーでの書き込みキャッシュ

キャッシュを使用せずに実行される I/O 転送は、ハード ドライブのスピン レート、ドライブ ヘッドの移動に必要な機械的時間、およびその他の制限要因により、機械的ドライブで大幅に長くなる可能性があります。 SQL Server のインストールは、キャッシュ コントローラーを提供するシステムを対象としています。 これらのコントローラーは、ディスク上のキャッシュを無効にし、SQL Server I/O 要件を満たすために安定したメディア キャッシュを提供します。 キャッシュ コントローラーのさまざまな最適化を使用して、ストレージのシークと書き込み時間に関連するパフォーマンスの問題を回避します。

Note

一部のストレージ ベンダーでは、キャッシュではなく永続メモリ (PMEM) をストレージとして使用しているため、全体的なパフォーマンスが向上する可能性があります。 詳細については、「SQL Server on Windows 用に永続メモリ (PMEM) を構成する」および「SQL Server on Linux 用に永続メモリ (PMEM) を構成する」を参照してください。

書き込みキャッシュ (ライトバック キャッシュとも呼ばれます) ストレージ コントローラーを使用すると、SQL Server のパフォーマンスを向上させることができます。 書き込みキャッシュ コントローラーとストレージ サブシステムは、データ クリティカルなトランザクション データベース管理システム (DBMS) 環境で使用するように設計されている場合、SQL Server にとって安全です。 これらの設計機能は、システム障害が発生した場合にキャッシュ データを保持する必要があります。 電源に関係のない故障モードが発生する可能性があるため、外部無停電電源装置 (UPS) を使用してこれを実現するだけでは一般に十分ではありません。

キャッシュ コントローラーとストレージ サブシステムは、SQL Server で安全に使用できます。 これらを組み込んだほとんどの新しい専用サーバー プラットフォームは安全です。 ただし、データ クリティカルなトランザクション リレーショナル データベース管理システム (RDBMS) 環境でストレージ サブシステムがテストされ、使用が承認されていることをハードウェア ベンダーに確認する必要があります。

先書きログ

SQL Server データ変更ステートメントは、論理ページ書き込みを生成します。 この書き込みストリームは、ログとデータベース自体の 2 つの場所に分けることができます。 パフォーマンス上の理由から、SQL Server は独自のキャッシュ バッファー システムを介してデータベースへの書き込みを延期します。 ログへの書き込みが一時的に遅延されるのは、 COMMIT 時刻までのみです。 これらは、データ書き込みと同じ方法でキャッシュされません。 特定のページのログ書き込みは常にページのデータ書き込みの前にあるため、ログは先書きログ (WAL) と呼ばれることがあります。

先書きログ (WAL) プロトコル

プロトコルという用語は、WAL を記述する優れた方法です。 SQL Server で使用される WAL は、ARIES (復旧と分離の悪用セマンティクスのアルゴリズム) と呼ばれます。 詳しくは、「高速データベース復旧の管理」をご覧ください。

これは、データが適切に格納および交換され、障害が発生した場合に既知の状態に復旧できるようにするために必要な、特定の定義された一連の実装手順です。 ネットワークに一貫性のある保護された方法でデータを交換するための定義済みのプロトコルが含まれているのと同様に、WAL もデータを保護するためのプロトコルを記述します。 すべてのバージョンの SQL Server では、Win32 CreateFile 関数を使用してログ ファイルとデータ ファイルが開きます。 dwFlagsAndAttributes メンバーには、SQL Server によって開かれた場合、 FILE_FLAG_WRITE_THROUGH オプションが含まれます。

FILE_FLAG_WRITE_THROUGH

SQL Server では、 FILE_FLAG_WRITE_THROUGH フラグを使用してデータベース ファイルが作成されます。 このオプションは、中間キャッシュを介して書き込み、ストレージに直接移動するようにシステムに指示します。 システムは書き込み操作をキャッシュすることはできますが、遅延フラッシュすることはできません。 詳細については、「CreateFileA」を参照してください。

この FILE_FLAG_WRITE_THROUGH オプションを使用すると、書き込み操作で正常な完了が返されるときに、データが安定したストレージに正しく格納されます。 これは、データを確保するために、先書きログ記録 (WAL) プロトコル仕様に合わせて調整されます。 多くのストレージ デバイス (NVMe、PCIe、SATA、ATA、SCSI、IDE ベース) には、512 KB、1 MB 以上のオンボード キャッシュが含まれています。 ストレージ キャッシュは通常、バッテリベースのソリューションではなく、コンデンサに依存します。 これらのキャッシュ メカニズムでは、電源サイクルまたは同様の障害ポイント間での書き込みを保証することはできません。 セクター書き込み操作の完了のみが保証されます。 ストレージ デバイスのサイズが拡大し続けるにつれて、キャッシュが大きくなり、障害発生時に大量のデータが公開される可能性があります。

Linux ディストリビューションによる FUA サポートと SQL Server へのその影響について詳しくは、「SQL Server On Linux: 強制ユニット アクセス (FUA) の内部構造」を参照してください。

トランザクションの整合性と SQL Server の復旧

トランザクションの整合性は、リレーショナル データベース システムの基本的な概念の 1 つです。 トランザクションは、完全に適用されるか、完全にロールバックされるアトミックな作業単位と見なされます。 SQL Server の先書きトランザクション ログは、トランザクションの整合性を実装する上で不可欠なコンポーネントです。

また、リレーショナル データベース システムは、計画外のシステム障害からの復旧であるトランザクションの整合性に密接に関連する概念にも対処する必要があります。 いくつかの理想的ではない実際の影響がこの障害を引き起こす可能性があります。 多くのデータベース管理システムでは、システム障害が発生すると、人が指示する手動復旧プロセスが長くなります。

これに対し、SQL Server の回復メカニズムは自動で、人間の介入なしに動作します。 たとえば、SQL Server はミッション クリティカルな運用アプリケーションをサポートし、一瞬の電力変動によるシステム障害が発生する可能性があります。 電源が回復すると、サーバー ハードウェアが再起動され、ネットワーク ソフトウェアが読み込んで初期化され、SQL Server が再起動します。 SQL Server が初期化されると、トランザクション ログ内のデータに基づいて修復プロセスが自動的に実行されます。 このプロセス全体は、人間の介入なしに行われます。 クライアント ワークステーションが再起動されるたびに、ユーザーは入力した最後のトランザクションまで、存在するすべてのデータを検索します。

SQL Server でのトランザクションの整合性と自動復旧は、強力な時間と労力の節約機能を構成します。 書き込みキャッシュ コントローラーがデータ クリティカルなトランザクション DBMS 環境で使用するように適切に設計されていない場合、SQL Server が復旧する機能が損なわれる可能性があるため、データベースが破損する可能性があります。 これは、コントローラーが SQL Server トランザクション ログの書き込みをインターセプトし、コントローラー ボード上のハードウェア キャッシュにバッファーするが、システム障害時にこれらの書き込まれたページを保持しない場合に発生する可能性があります。

書き込みキャッシュとストレージ デバイス コントローラー

ほとんどのストレージ デバイス キャッシュ コントローラーは、書き込みキャッシュを実行します。 書き込みキャッシュ関数を常に無効にすることはできません。

サーバーが UPS を使用している場合でも、キャッシュされた書き込みのセキュリティは保証されません。 UPS が対処しない多くの種類のシステム 障害が発生する可能性があります。 たとえば、メモリ パリティ エラー、オペレーティング システム (OS) トラップ、またはシステム リセットの原因となるハードウェアの障害によって、制御されないシステム中断が発生する可能性があります。 ハードウェア書き込みキャッシュのメモリ障害により、重要なログ情報が失われる可能性もあります。

書き込みキャッシュ コントローラーに関連するもう 1 つの問題は、システムのシャットダウン時に発生する可能性があります。 構成の変更中に OS を循環させたり、システムを再起動したりすることは珍しくありません。 システムを再起動する前にすべてのストレージ アクティビティが停止するまで待機するという OS の推奨事項に慎重に従うオペレーターでも、キャッシュされた書き込みがコントローラーに残る可能性があります。 Ctrl+Alt+Del キーの組み合わせを押すか、ハードウェア リセット ボタンを押すと、キャッシュされた書き込みを破棄して、データベースが破損する可能性があります。

ダーティ キャッシュ データを破棄する可能性のあるすべての原因を考慮に入れたハードウェア書き込みキャッシュを設計できます。これにより、データベース サーバーで安全に使用できます。 これらの設計機能の一部には、キャッシュ コントローラーの制御されていないリセットを回避するための RST バス信号のインターセプト、オンボード バッテリ バックアップ、ミラー化またはエラー チェックと修正 (ECC) メモリなどがあります。 ハードウェア ベンダーに問い合わせて、書き込みキャッシュに、データ損失を回避するために必要なこれらの機能とその他の機能が含まれていることを確認してください。

SQL Server でストレージ キャッシュを使用する

予期しないシステム障害が発生した場合でも、データベース システムはまず何よりも、データを正確に格納し取得する役目を持っています。

システムは、現在の実行、複数のトランザクション、およびさまざまな障害ポイントを考慮しながら、トランザクションの原子性と持続性を保証する必要があります。 これは多くの場合、ACID (原子性、整合性、分離、および持続性) プロパティと呼ばれます。

このセクションでは、ストレージ キャッシュの影響について説明します。 キャッシュと代替エラー モードのさらに詳しい説明については、Microsoft サポート技術情報の次の記事を参照することをお勧めします。

• 86903 SQL Server とキャッシュ ディスク コントローラー
• SQL Serverでのデータの信頼性を拡張するログ記録アルゴリズムとデータ ストレージ アルゴリズムの説明

次のドキュメントも推奨されます。

• SQL Server 2000 I/O Basics
• SQL Server I/O Basics Chapter 2

これら 2 つのドキュメントは、現在サポートされているすべてのバージョンの SQL Server に適用されます。

バッテリーベースのキャッシュ ソリューション

強化されたキャッシュ コントローラー システムは、ディスク上のキャッシュを無効にし、機能するバッテリベースのキャッシュ ソリューションを提供します。 これらのキャッシュは、キャッシュ内のデータを数日間保持でき、キャッシュ カードを 2 台目のコンピューターに配置することもできます。 電源が適切に復元されると、書き込まれていないデータは、それ以上のデータ アクセスが許可される前に完全にフラッシュされます。 その多くは、最適なパフォーマンスを得るために、読み取りキャッシュと書き込みキャッシュの割合を確立できます。 一部には、大きなメモリ記憶域が含まれています。 一部のハードウェア ベンダーは、数ギガバイトのキャッシュを備えたハイエンドのバッテリベースのドライブ キャッシュ システムを提供しています。 これらは、データベースのパフォーマンスを大幅に向上させることができます。 バッテリベースのキャッシュ ソリューションを使用すると、SQL Server が期待するデータの持続性と一貫性が提供されます。

ストレージ サブシステムの実装

サブシステムの実装にはさまざまな種類があります。 RAID (Redundant Array of Independent Disks) と SAN (記憶域ネットワーク) は、これらの種類のサブシステム実装の 2 つの例です。 通常、これらのシステムは SCSI ベースのドライブを使用して構築されます。 直接呼び出すべきではないいくつかの理由があります。 次のセクションでは、ストレージに関する大まかな考慮事項について一般的に説明します。

SCSI、SAS、NVMe

SCSI、SAS、NVMe ストレージ デバイス:

• 通常は高負荷の使用のために製造されます。
• 通常、マルチユーザーのサーバーベースの実装を対象とします。
• 通常、他の実装よりもエラー率が改善します。
• 差し迫った障害を予測するのに役立つ高度なヒューリスティックを含みます。

非 SCSI

IDE、ATA、SATA などのその他のドライブ実装:

• 通常、軽量および中程度の使用のために製造されます。
• 通常は、単一のユーザーベースのアプリケーションを対象とします。

SCSI 以外のデスクトップベースのコントローラーでは、より多くのメイン プロセッサ (CPU) 帯域幅が必要であり、多くの場合、1 つのアクティブなコマンドによって制限されます。 たとえば、SCSI 以外のドライブが不良ブロックを調整している場合、ドライブはホスト コマンドを待機させる必要があります。 ATA バスには別の例が示されています。ATA バスは 2 つのデバイスをサポートしていますが、アクティブにできるコマンドは 1 つだけです。 これにより、一方のドライブはアイドル状態のままになりますが、もう一方のドライブは保留中のコマンドを処理します。 デスクトップ テクノロジに基づいて構築された RAID システムはすべて、これらの症状を経験し、最も低速なレスポンダーの影響を大きく受ける可能性があります。 これらのシステムが高度な設計を使用しない限り、そのパフォーマンスは SCSI ベースのシステムのパフォーマンスほど効率的ではありません。

ストレージに関する考慮事項

デスクトップベースのドライブまたはアレイが適切な低コストソリューションである場合があります。 たとえば、レポート用に読み取り専用データベースを設定した場合、ドライブのキャッシュが無効になっているときに OLTP データベースのパフォーマンス要因の多くが発生することはありません。

ストレージ デバイスのサイズは引き続き増加します。 低コストで大容量のドライブが魅力的な場合があります。 ただし、SQL Server のドライブとビジネス応答時間のニーズを構成する場合は、次の問題を慎重に検討する必要があります。

• アクセス パスの設計
• ディスク上のキャッシュを無効にする要件

メカニカル ハード ドライブ

メカニカル ドライブは、データを格納するために回転磁気プラッタを使用します。 IDE、SATA、SCSI、シリアル接続 SCSI (SAS) など、いくつかの容量とフォーム ファクターで使用できます。 一部の SATA ドライブには、障害予測コンストラクトが含まれています。 SCSI ドライブは、負荷の高いデューティ サイクルと故障率の低下を想定して設計されています。

SQL Server でドライブを使用するには、ドライブのキャッシュを無効にする必要があります。 既定では CSV キャッシュは有効になっています。 Windows Server では、[ディスクのプロパティ]>[ハードウェア] タブを使用して、[プロパティ]>[ポリシー] タブにアクセスしてドライブ キャッシュの設定を制御します。

Note

一部のドライブでは、この設定が適用されません。 これらのドライブでは、キャッシュを無効にするために特定の製造元ユーティリティが必要です。

IDE および ATA ベースのシステムは、不良ブロック調整などのアクティビティを実行するときにホスト コマンドを延期できます。 これにより、I/O アクティビティが停止する期間が発生する可能性があります。

SAS の利点には、最大 256 レベルの高度なキューと、キューの先頭と順序外のキューなどがあります。 SAS バックプレーンは、同じシステム内で SAS ドライブと SATA ドライブの両方を使用できるように設計されています。

SQL Server のインストールは、ディスク上のキャッシュを無効にし、安定した I/O キャッシュを提供するコントローラーの機能によって異なります。 コントローラーが適切な安定したメディア キャッシュ機能を提供している限り、さまざまなドライブにデータを順不同に書き込むのは SQL Server の妨げになりません。 ミラーリングなどの Advanced Data Security 手法により、コントローラー設計の複雑さが増します。

ソリッド ステート ストレージ

ソリッドステート ストレージは、メカニカル (回転) ハード ドライブよりも利点がありますが、回転メディアと同じ障害パターンの多くを受けやすくなります。 ソリッドステート ストレージは、NVM Express (NVMe)、PCI Express (PCIe)、SATA など、さまざまなインターフェイスを使用してサーバーに接続されます。 ソリッドステート メディアは、メディアを回転させる場合と同様に扱い、バッテリを使用したキャッシュ コントローラーなど、電源障害に対して適切なセーフガードが設定されていることを確認します。

電源障害が原因で発生する一般的な問題は次のとおりです。

• ビット破損: レコードはランダム ビット エラーを示します。
• フライ書き込み: 整形式のレコードが間違った場所に表示されます。
• ショーン書き込み: 操作は、予想されるセクター サイズを下回るレベルで部分的に実行されます。
• メタデータの破損: FTL のメタデータが破損しています。
• 応答しないデバイス: デバイスがまったく機能しないか、ほとんど機能しません。
• 非シリアル化可能性: ストレージの最終状態は、シリアル化可能な操作順序に起因しません。

512e

ほとんどのソリッドステート ストレージでは、512 バイトのセクター サイズが報告されますが、1 MB の消去ブロック内では 4 KB のページが使用されます。 SQL Server ログ デバイスに 512 バイトに調整されたセクターを使用すると、読み取り/変更/書き込み (RMW) アクティビティを増やすことができます。これは、パフォーマンスの低下と摩耗の促進に寄与する可能性があります。

推奨事項: キャッシュ コントローラーがストレージ デバイスの正しいページ サイズを認識し、物理書き込みをソリッドステート ストレージ インフラストラクチャに適切に合わせることができることを確認します。

0xFFFFFFFF

新しくフォーマットされたドライブは通常、すべてのゼロを保持します。 ソリッドステート デバイスの消去されたブロックはすべて 1 であり、消去されたブロックの未加工の読み取りをすべて 0xFF にします。 ただし、ユーザーが通常の I/O 操作中に消去されたブロックを読み取ることはほとんどありません。

パターン スタンプ

以前に使用した手法は、ドライブ全体に既知のパターンを書き込む方法です。 その後、同じドライブに対してデータベース アクティビティを実行すると、パターンが予期せず表示されたときに、不適切な動作 (古い読み取り/消失した書き込み/不適切なオフセットの読み取りなど) を検出できます。

この手法は、ソリッドステート ストレージではうまく機能しません。 書き込みの消去アクティビティと RMW アクティビティによってパターンが破棄されます。 ソリッドステート ストレージ ガベージ コレクション (GC) アクティビティ、摩耗平準化、プロポーショナル/セットアサイド リスト ブロック、およびその他の最適化により、書き込みが異なる物理的な場所を取得する傾向があります。これは、スピン メディアのセクターの再利用とは異なります。

ファームウェア

ソリッドステート ストレージで使用されるファームウェアは、スピン メディアに対応するファームウェアと比較して複雑になる傾向があります。 多くのドライブでは、受信要求とガベージ コレクション アクティビティを処理するために複数の処理コアが使用されます。 既知の問題を回避するために、ソリッドステート デバイスのファームウェアを最新の状態に保っていることを確認します。

データの損傷と摩耗の平準化を読み取る

ソリッドステート ストレージの一般的なガベージ コレクション (GC) アプローチは、繰り返される読み取りデータの損傷を防ぐのに役立ちます。 同じセルを繰り返し読むと、電子活動が漏れ、隣接するセルに損傷を与える可能性があります。 ソリッドステート ストレージは、さまざまなレベルのエラー訂正コード (ECC) やその他のメカニズムでデータを保護します。

このようなメカニズムの 1 つは、摩耗の平準化に関連しています。 ソリッドステート ストレージは、ストレージ デバイスの読み取りと書き込みのアクティビティを追跡します。 ガベージ コレクションは、他の場所よりも高速に摩耗しているホット スポットや場所を特定できます。 たとえば、GC は、ブロックが一定期間読み取り専用状態にあり、移動する必要があると判断します。 この動きは、通常、摩耗の多いブロックに対して行われるので、元のブロックを書き込みに使用できます。 これはドライブの摩耗のバランスを取るのに役立ちますが、読み取り専用データをより多くの摩耗がある場所に移動し、少しであっても数学的に故障の可能性を高めます。

摩耗平準化のもう 1 つの副作用は、SQL Server で発生する可能性があります。 DBCC CHECKDB を実行し、エラーを報告するとします。 2 回目に実行した場合、ソリッドステート ストレージ GC アクティビティによって DBCC CHECKDB 実行間で変更が加えられる可能性があるため、DBCC CHECKDB が追加または異なるエラー パターンを報告する可能性は小さくなります。

OS エラー 665 と最適化

回転メディアは、ドライブのヘッドの動きを減らし、パフォーマンスを向上させるために、ブロックを互いに近くに保つ必要があります。 ソリッドステート ストレージには物理ヘッドがないため、シーク タイムが不要になります。 多くのソリッドステート デバイスは、異なるブロックに対する並列操作を並列で行えるように設計されています。 つまり、ソリッド ステート メディアの最適化は不要です。 シリアル アクティビティは、ソリッドステート ストレージ デバイスの I/O スループットを最大化するための最適な I/O パターンです。

Note

ソリッドステート ストレージは、使用されなくなったと見なされるブロックを消去するオペレーティング システム (OS) レベルのコマンドである TRIM 機能の利点があります。 Windows では、[Optimize Drives] ツールを使用して、ドライブ を最適化するための週単位のスケジュールを設定します。

レコメンデーション:

• 書き込みアクティビティを最適化するように設計された、適切なバッテリベースのコントローラーを使用します。 これにより、パフォーマンスを向上させ、ドライブの摩耗と物理的な断片化レベルを減らすことができます。

• NTFS 属性の制限を回避するには、ReFS ファイル システムの使用を検討してください。

• ファイルの拡張サイズが適切なサイズになっていることを確認します。

断片化に関連する OS エラー 665 のトラブルシューティングの詳細については、「SQL Server ファイルの OS エラー 665 と 1450 が報告される」を参照してください。

Compression

ドライブが安定したメディアの意図を維持している限り、圧縮によってドライブの寿命が長く、パフォーマンスにプラスの影響を与える可能性があります。 ただし、一部のファームウェアでは、データが目に見えない程度に圧縮されている場合があります。 運用環境にデプロイする前に、新しいストレージ シナリオを必ずテストしてください。

まとめ

• 適切なバックアップとディザスター リカバリーの手順とプロセスを維持します。
• ファームウェアを最新に保ちます。
• ハードウェア製造のガイダンスをよく聴きます。

キャッシュに関する考慮事項と SQLIOSim

データを完全にセキュリティで保護するには、すべてのデータ キャッシュが適切に処理されるようにする必要があります。 多くの場合、ドライブの書き込みキャッシュを無効にする必要があります。

Note

代替キャッシュ メカニズムが複数の種類の障害を適切に処理できることを確認します。

Microsoft では、SQLIOSim ユーティリティを使用して、複数の SCSI ドライブと IDE ドライブのテストを実行しました。 このユーティリティは、シミュレートされたデータ デバイスとログ デバイスに対する大量の非同期読み取り/書き込みアクティビティをシミュレートします。 SQLIOSim の情報と詳細については、「SQLIOSim ユーティリティを使用してディスク サブシステム上の SQL Server アクティビティをシミュレートする」を参照してください。

多くの PC 製造元は、書き込みキャッシュが無効になっているドライブを発注します。 ただし、テストでは、必ずしもそうとは限らないため、常に完全にテストする必要があります。 ストレージ デバイスのキャッシュ状態について不明な点がある場合は、製造元に問い合わせて、書き込みキャッシュ操作を無効にする適切なユーティリティまたはジャンパー設定を入手してください。

SQL Server では、SQL Server I/O 信頼性プログラムの要件に関する説明に従って、安定したメディアへの確実な配信をサポートするシステムが必要です。 SQL Server データベース エンジンの入力と出力の要件の詳細については、「SQL Server データベース エンジン ディスクの入出力 (I/O) の要件」を参照してください。

関連するコンテンツ

• ページとエクステントのアーキテクチャ ガイド
• メモリ管理アーキテクチャガイド
• SQL Server on Linux: 強制ユニット アクセス (FUA) の内部
• SQL Server I/O Basics, Chapter 2