適用対象:
SQL ServerAzure SQL Managed InstanceSQL Server on Azure VM
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 オプションが使用されていない限り、呼び出し元のスレッドで発行されます。 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 のメッセージは、警告であってエラーではありません。 それらのメッセージは 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 要求の処理を後回しにして、新しい要求の処理を優先し続けているために発生する場合もあります。 これは、 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 要件を満たします。 またキャッシュ コントローラーのさまざまな最適化機能を活用することで、ストレージのシーク時間や書き込み時間に関連するパフォーマンスの問題を回避します。
注
一部のストレージ ベンダーは、永続メモリ (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 (Algorithm for Recovery and Isolation Exploiting Semantics) と呼ばれています。 詳しくは、「高速データベース復旧の管理」をご覧ください。
これは、データを正しく保存・交換し、障害発生時に既知の状態に復元できるようにするために必要な、特定の定義された実装手順の集合です。 ネットワークにおいて一貫性と保護性のあるデータ交換を実現するために定義されたプロトコルがあるのと同様に、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) のトラップ、システム リセットを引き起こすハードウェアの不具合などが、制御不能なシステム中断を引き起こすことがあります。 また、ハードウェアの書き込みキャッシュ内でメモリ障害が発生して、重要なログ情報が失われる場合もあります。
これとは別に、書き込みキャッシュ コントローラーに関連して、システムのシャットダウン時に問題が発生する可能性もあります。 構成変更の際に OS やシステムを再起動することは珍しくありません。 OS の推奨事項に従って、すべてのストレージ アクティビティが停止するまで待ってからシステムを再起動しても、コントローラー内にキャッシュされた書き込みが残っていることがあります。 When the Ctrl+Alt+Del キーの組み合わせを押した場合や、ハードウェアのリセット ボタンを押した場合、これらのキャッシュされた書き込みが破棄され、データベースが損傷する可能性があります。
キャッシュ未書き込みデータが破棄されるすべての可能性を考慮したうえで、データベース サーバーで安全に使用できるハードウェア書き込みキャッシュを設計することは可能です。 このような設計機能の例には、キャッシュ コントローラーの制御不能なリセットを回避するための RST バス信号の傍受、オンボードのバッテリ バックアップ、ミラーリング メモリやエラー チェック、訂正 (ECC) メモリなどがあります。 データ損失を回避するために必要なこれらの機能やその他の機能が書き込みキャッシュに搭載されているかを、ハードウェア ベンダーに確認してください。
SQL Server でストレージ キャッシュを使用する
データベース システムの最も重要な機能は、予期しないシステム障害が発生した場合でも、データを正確に保存し、取得できるようにすることです。
システムは、現在の実行状態や複数のトランザクション、さまざまな障害点を考慮しながら、トランザクションの原子性と永続性を保証する必要があります。 これは一般に、ACID (Atomicity、Consistency、Isolation、Durability) 特性と呼ばれます。
このセクションでは、ストレージ キャッシュの影響について説明します。 キャッシュ処理やさまざまな障害モードに関する理解を深めるために、Microsoft Knowledge Base に掲載されている以下の記事を参照することをお勧めします。
次のドキュメントもお勧めします。
これら 2 つのドキュメントは、現在サポートされているすべてのバージョンの SQL Server に共通です。
バッテリ バックアップ付きキャッシュ ソリューション
高度なキャッシュ コントローラー システムは、ディスク上のキャッシュを無効にし、機能的なバッテリ バックアップ付きキャッシュ ソリューションを提供します。 これらのキャッシュは、キャッシュ内のデータを数日間保持できるうえ、キャッシュ カードを別のコンピューターに移すことも可能です。 電源が正常に復旧すると、未書き込みデータがすべてフラッシュされた後、それ以降のデータ アクセスが許可されます。 多くの製品では、最適なパフォーマンスを実現するために、読み取りキャッシュと書き込みキャッシュの比率を設定できます。 大容量のメモリ ストレージ領域を備えた製品もあります。 ハードウェア ベンダーによっては、数ギガバイトのキャッシュを搭載したハイエンドのバッテリ バックアップ付きドライブ キャッシュ システムを提供しています。 このようなソリューションにより、データベースのパフォーマンスが大幅に向上します。 バッテリ バックアップ付きキャッシュ ソリューションを使用することで、SQL Server が要求するデータの永続性と整合性を確保できます。
ストレージ サブシステムの実装
ストレージ サブシステムの実装にはさまざまな種類があります。 RAID (redundant array of independent disks) や SAN (storage area network) は、このようなサブシステム実装の代表的な 2 つの例です。 これらのシステムは通常、SCSI ベースのドライブで構成されています。 これにはいくつかの理由があります。 以下のセクションでは、ストレージに関する基本的な考慮事項を概説します。
SCSI、SAS、NVMe
SCSI、SAS、および NVMe ストレージ デバイスは、次の特徴を備えています。
- 通常、高負荷の用途向けです。
- 通常、複数ユーザーをサポートするサーバーへの実装を対象としています。
- 通常、他の実装よりも高い平均故障間隔を備えています。
- 差し迫った障害を予測するうえで役立つ高度なヒューリスティック機能を搭載しています。
注
SQL Server は、 Windows ハードウェア互換性プログラムの要件を満たすインターネット Small Computer System Interface (iSCSI) テクノロジ コンポーネントでサポートされています。 SQL Server は iSCSI と直接対話しませんが、Windows では iSCSI ストレージが標準ドライブとして提供されるため、シームレスに動作します。 これにより、SQL Server は IP ネットワーク間でリモート ブロック レベルのストレージとの間で読み取りと書き込みを行うことができます。 iSCSI はネットワークに依存するため、遅延やボトルネックが発生する可能性があるため、サーバーのキャッシュ パフォーマンスを最適化し、待機時間を最小限に抑える必要があります。 詳細については、「 iSCSI ターゲット サーバーのスケーラビリティの制限」を参照してください。
非 SCSI
IDE、ATA、SATA などのその他のドライブ実装は、次の特徴があります。
- 通常、軽度から中程度の負荷向けです。
- 通常、単一ユーザー向けの用途を対象としています。
非 SCSI のデスクトップ ベースのコントローラーは、メイン プロセッサー (CPU) の帯域幅をより多く消費するため、アクティブなコマンドが 1 件に制限されることがよくあります。 たとえば、非 SCSI ドライブが不良ブロックを調整している場合、ホストのコマンドは待機を強いられます。 ATA バスも同様で、ATA バスは 2 台のデバイスをサポートしますが、アクティブにできるコマンドは 1 件のみです。 そのため、片方のドライブがコマンドを処理している間、もう一方のドライブはアイドル状態になります。 デスクトップ技術をベースに構築された RAID システムは、これらの問題の影響を受けやすく、最も応答が遅いドライブによって全体の性能が大きく左右されることがあります。 これらのシステムは、高度な設計を採用していない限り、SCSI ベースのシステムほど効率的な性能は発揮できません。
ストレージに関する考慮事項
状況によっては、デスクトップ ベースのドライブやアレイが、コストを抑えた適切なソリューションとなる場合があります。 たとえば、読み取り専用のレポート用データベースを構成する場合、ドライブ キャッシュを無効にしても、OLTP データベースに見られるような多くのパフォーマンス要因に直面することはありません。
ストレージ デバイスの容量は年々増加しています。 低価格で大容量のドライブは魅力的に映るかもしれません。 しかし、SQL Server やビジネスの応答時間の要件に合わせてドライブを構成する際には、次の点を慎重に検討する必要があります。
- アクセス パスの設計
- ディスク上のキャッシュを無効にする必要性
機械式ハード ドライブ
機械式ドライブは、回転する磁気プラッタを使ってデータを保存します。 IDE、SATA、SCSI、Serial Attached SCSI (SAS) など、さまざまな容量やフォーム ファクターで提供されています。 中には、障害予測機能が組み込まれた SATA ドライブもあります。 SCSI ドライブは、高負荷な使用サイクルと故障率の低減を目的として設計されています。
SQL Server で使用する場合は、ドライブ キャッシュを無効にする必要があります。 既定では、ドライブ キャッシュは有効になっています。 Windows Server で、[ディスクのプロパティ]>[ハードウェア] タブを使用して、[プロパティ]>[ポリシー] タブにアクセスし、ドライブ キャッシュの設定を変更できます。
注
一部のドライブでは、この設定が反映されない場合があります。 このようなドライブでは、キャッシュを無効にするために特定のメーカーのユーティリティが必要です。
IDE や ATA ベースのシステムでは、不良ブロックの調整などの処理中にホストからのコマンドを後回しにすることがあります。 これにより、I/O アクティビティが一時的に停止する可能性があります。
SAS の利点には、最大 256 レベルの高度なキューイングや、先頭キュー処理、順不同キューイングなどがあります。 SAS バックプレーンは、同一システム内で SAS ドライブと SATA ドライブの両方を使用できるように設計されています。
SQL Server のインストール環境では、ディスク上のキャッシュを無効にし、安定した I/O キャッシュを提供できるかどうかは、コントローラーの能力に依存します。 コントローラーが適切な安定メディア キャッシュ機能を備えている限り、複数のドライブに対して順不同でデータを書き込んでも、SQL Server に悪影響は生じません。 ミラーリングなどの高度なデータ保護技術を用いることで、コントローラーの設計はより複雑になります。
ソリッド ステート ストレージ
ソリッド ステート ストレージは、機械式 (回転式) ハード ドライブと比べて多くの利点がありますが、回転式メディアと同様の障害パターンの多くに影響を受ける可能性があります。 ソリッド ステート ストレージは、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 がそれを感知して、そのブロックのデータを移動させることがあります。 通常は、摩耗が進んでいる別のブロックに移動し、元のブロックを新たな書き込み用に空けます。 これによりドライブ全体の摩耗を均等化できますが、読み取り専用データがより摩耗した場所に移されるため、わずかではあっても故障の可能性が数学的に高まります。
ウェア レベリングについては、別の副作用が SQL Server で発生することがあります。 たとえば、DBCC CHECKDB を実行してエラーが報告されたとします。 その後、同じコマンドをもう一度実行すると、ソリッド ステート ストレージの GC アクティビティがDBCC CHECKDBその間に変更を加える可能性があるため、DBCC CHECKDB が追加のエラーや異なるパターンのエラーを報告する可能性があります。
OS エラー 665 とデフラグ
回転式メディアでは、ドライブのヘッド移動を最小限に抑えてパフォーマンスを向上させるため、ブロックを近接した位置に配置する必要があります。 ソリッドステート ストレージには物理ヘッドが存在しないため、シーク時間が発生しません。 多くのソリッド ステート デバイスは、異なるブロックに対して並列に処理を行えるように設計されています。 つまり、ソリッド ステート メディアに対するデフラグ処理は不要です。 シリアルな処理が、ソリッド ステート ストレージ デバイスにおいて I/O スループットを最大化する最適なパターンです。
注
ソリッド ステート ストレージでは、trim 機能と呼ばれる OS レベルのコマンドによって、使用されなくなったブロックが消去されます。 Windows では、[ドライブの最適化] ツールを使用して、ドライブの最適化を週単位でスケジュール設定できます。
推奨事項:
書き込み処理を最適化するように設計された、適切なバッテリ バックアップ付きコントローラーを使用してください。 これにより、パフォーマンスの向上、ドライブの摩耗軽減、物理的な断片化の低減が処理されます。
NTFS の属性制限を回避するために、可能であれば ReFS ファイル システムを使用してください。
ファイルの自動拡張サイズが適切に設定されていることを確認してください。
断片化に関連する OS エラー 665 のトラブルシューティングの詳細については、「SQL Server ファイルの OS エラー 665 と 1450 が報告される」を参照してください。
圧縮
ドライブが安定メディアとしての要件を満たしている限り、圧縮によってドライブの寿命を延ばすことができ、パフォーマンスへの好影響が期待できます。 ただし、ファームウェアによっては、データがすでに目に見えないかたちで圧縮されていることがあります。 新しいストレージ構成を実稼働環境に導入する前に、必ずテストを行ってください。
まとめ
- 適切なバックアップおよびディザスター リカバリーの手順とプロセスを維持する。
- ファームウェアを常に最新の状態に保つ。
- ハードウェア メーカーのガイダンスに注意深く従う。
キャッシュに関する考慮事項と SQLIOSim
データを完全に保護するには、すべてのデータ キャッシュが適切に処理されていることを確認する必要があります。 多くの場合、ドライブの書き込みキャッシュを無効にする必要があります。
注
代替のキャッシュ メカニズムを使用する場合は、複数の種類の障害に対して適切に対処できることを確認してください。
Microsoft は、SQLIOSim ユーティリティを使用して複数の SCSI ドライブおよび IDE ドライブでテストを実施しました。 このユーティリティは、データ デバイスおよびログ デバイスを模擬し、非同期の重い読み取り/書き込みアクティビティをシミュレートします。 SQLIOSim の詳細については、「SQLIOSim ユーティリティを使用してディスク サブシステム上の SQL Server アクティビティをシミュレートする」を参照してください。
多くの PC メーカーは、書き込みキャッシュを無効にした状態でドライブを出荷しています。 しかし、テスト結果によると、例外もあるため、必ず十分に検証する必要があります。 ストレージ デバイスのキャッシュ状態について不明な点がある場合は、メーカーに問い合わせ、書き込みキャッシュの動作を無効にするための適切なユーティリティやジャンパー設定を入手してください。
SQL Server では、SQL Server I/O 信頼性プログラムの要件に従い、安定したメディアへの確実なデータ書き込みをシステムがサポートしている必要があります。 SQL Server データベース エンジンの入力と出力の要件の詳細については、「SQL Server データベース エンジン ディスク入出力 (I/O) の要件」を参照してください。