サード パーティのファイル キャッシュ システム SQL Server を評価する際に考慮する点

文書翻訳 文書翻訳
文書番号: 917043
すべて展開する | すべて折りたたむ

目次

概要

この資料ではお客様はサード パーティのファイル システムのキャッシュを評価する際に注意すべき重要な要素のいくつかについて説明します。

サード パーティのファイル キャッシュの実装が適切に実装すると、Microsoft SQL Server データベースのパフォーマンスを向上します。具体的な実装をただし、およびこれらの製品の SQL Server データベースでのデータ損失のリスクが高いままです。お客様は適切なデータの整合性を確保するように構成を完全にテストしてください。

URL およびその他のインターネット Web サイト参照を含め、このドキュメントの情報は予告なく変更されることです。特記のない限り、企業、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、およびイベントの例ここでは架空のものです。実在する会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人、場所、またはイベントが、対象としています。 または推論する必要があります。すべての該当する著作権法を遵守する責任をユーザーです。著作権の権利を制限することなく、が本書のいかなる部分可能性がありますに再現、格納、検索システムへの導入またはいかなる形式、手段 (電子、機械、複写、録音、またはそれ以外の場合)、または、目的、Microsoft Corporation の書面を送信します。

マイクロソフトは、特許、特許申請、商標、著作権、またはその他の知的財産権をこのドキュメント内の特定の分野をカバーする必要があります。場合マイクロソフトのライセンス契約で、本書を別途、許諾これらの特許、商標、著作権、またはその他の知的財産を提供しませんを除き。

? 2006 Microsoft Corporation。すべての権限予約されています。

Microsoft、Windows、Windows Server、および SQL Server は、登録商標または商標 Microsoft Corporation の米国およびその他の国のものです。

この資料では、SQL Server を具体的に書き込まれますが一般に Active Directory および Exchange Server の商品もを使用する Jet データベースに適用されます。

詳細

ここでは、要件の概要について説明し、どのようなソリューションを展開する前に、サード パーティ ベンダーが完全に検討すべき詳細な例を提供します。お客様もデータの完全性が適切に維持されているかどうかを確認するのには、さまざまなリカバリ ・ シナリオをテストするのには特に注意する必要があります。

SQL Server の入力/出力 (I/O) の要件

SQL Server のバックアップまたはファイル記憶域を必要と基礎は、先行書き込みログ (WAL) プロトコルをサポートします。これら基礎の次の資料に記載されています。
SQL Server 2000年の I/O の基本
http://technet.microsoft.com/en-us/library/cc966500.aspx
メモ 「には SQL Server にも適用されます。2005 年です。
230785 7.0 の SQL Server、SQL Server 2000、および SQL Server 2005 のログ記録とデータ記憶アルゴリズムは、データの信頼性を拡張します。
いくつかの重要な要件を次に示します。
  • 書き込み順序を維持する必要があります。
  • 依存する書き込みの整合性を維持する必要があります。
  • 厩舎や書き込みを常に保護する必要があります。メディア。
  • I/O の破損の防止を行う必要があります。

パートナー製品認定の互換性や安全性は保証されません。

サード パーティ製品や、特定のベンダーはマイクロソフトのロゴ認定を受信できます。ただし、パートナーの証明書や、特定のマイクロソフトのロゴの互換性や特定の目的への適合性、SQL Server、Exchange Server、または Active Directory を保証しません。

FILE_FLAG_WRITETHROUGH と FILE_FLAG_NO_BUFFERING

Microsoft データベース製品具体的にはライト ・ スルーし、バッファリングのフラグなしデータベース ファイルを開くときのデータ損失を防ぐために使用します。安定したメディアに書き込み要求にこれらのファイルを保護する必要があります。それ以外の場合は、データ損失が発生することができます。次にファイル システム キャッシュを失う可能性があります特定の例を示します。
  • ライト コンバインと書き込みの順序変更
    物理 I/O 要求を減らすために、非-バッテリ ベース キャッシュ多くの場合、結合し、書き込み操作はすぐに、WAL プロトコルの要件を分割、順序を変更します。
  • I/o のブロック サイズ
    同様に、書き込み結合と並べ替えが I/o ブロック ・ サイズ。キャッシュは、I/O パスのブロック サイズでの I/o の完了を試行します。もう一度、これがパフォーマンスの向上を提供できるがデータベースを破損する開きすぐに、WAL プロトコルの要件を分割します。

トーキング ポイントと例

次のセクションでは、キーの例とデータの完全性と安全性に関するトーキング ポイントを提供します。電源障害、障害を明確にするため、共通点として使用しますが、この多くの場合のようなデータベースの整合性の問題につながるさまざまなその他の問題に置き換えることができます。

例 1: データの損失、物理的または論理的な破損

次のシナリオを検討してください。
  1. ページ 100 のデータベースは、ログ レコードが書き込まれます。
  2. バッテリ ベース以外のキャッシュでは、ログ レコードが保持されますが、データベース エンジンのログ書き込みは完了「保護メディア安定に」あるように指示されます。
  3. データベース エンジンは LSN 強化およびページ 100 の書き込みと見なされます。
  4. ページ 100 もない-バッテリ ベース キャッシュ内に保持されます。
  5. コミット トランザクションがエラーなしを完了します。
安定したメディアへの書き込みが正常にコミットされると、データベース エンジンは処理を続行します。変更がない-バッテリ バックアップ キャッシュ外は物理的に存在しているため、停電この時点では、ただし、即時データに失われます。クラッシュ回復は、失われたログ レコードが認識していないため、作業をやり直すことはできませんするためクラッシュ回復エラーを示しません。複数のオブジェクト変更シナリオ (たとえば、主キー、外部キーの挿入) に発生することができます、データベースの破損の種類を展開します。

I/o がキャッシュを処理する方法に小さな変更が発生する可能性がありますさまざまなその他の問題があります。簡単な派生トランザクションが物理的にページ 100 のメディアがロールバックされましたを前提としています。クラッシュ回復再度 (は、メディアを安定に行った) ログ レコードに関する論理的および物理的に可能性がありますが破損しているデータベースを残しておくクラッシュ リカバリ中には、元に戻す操作を受信しないページ 100 なりますので知りません。

例 2: 問題のあるデータベース

一部のベンダー"ファイルの opt"アンド多くの場合、データベースのログ ファイル (.ldf は SQL Server) のままにキャッシュ アウトを選択したことをお勧めします。管理者はキャッシュ ソフトウェアを無視するファイルをマークする必要がありますように「オプトアウト」ポリシーです。それ以外の場合は、そのファイルは自動的に含まれます。

次の例では、強調表示これが悪い前提です。すべてのデータベースとバックアップ ファイル キャッシュから脱退することをお勧めします。
  1. 安定したメディアに書き込みを取得するため、ログ ・ ファイルを選択して、します。
  2. ページ 100 が変更されます。
  3. データベース エンジンは、チェックポイント操作を実行します。
  4. エンジンはすべてのページのデータベースし、ログの記録はセキュリティで保護された指示です (時点にチェックポイントの考慮を強化されて)。ただし、データ ページは、すべてのまたは安定したメディアに格納されているされません。
  5. SQL Server データベース回復モードでは「シンプル」ので、チェックポイントはログ レコードが切り捨てられます。
  6. ページ 100 が示されるかを確認をもう一度変更されます。
この状況では、データベースにデータが失われる公開されているが、一般にデータベースの問題が発生します。停電が行われる場合は、切り捨てが存在しないため、クラッシュ リカバリ ログ レコードがありません。データベース エンジンでは、データベース ページがチェックポイント中に保護されている必要がありますデータが不足していることを示す情報はありません。クラッシュ回復 [100] ページで、2 番目の変更を分析しようとしていますがページ 100 が正しく安定したメディアには、チェックポイントの時点で設定されていないために失敗します。

クラッシュ回復回復のニーズを確認するのにページ ヘッダーに格納された LSN 値を使用します。
  • ページの LSN がログ レコードのより新しいで場合は、ページがログ レコードの LSN の比較で一貫性のあるので回復さらに作業ページはありません。
  • ページの LSN がログ レコードよりも古いである場合は、回復をページを適切な状態に戻すには、適切な操作を実行する必要があります。回復の不足しているデータの状態によって発見され、の正当な状態にページを返すことはできませんが正しくリカバリは失敗します。
この例では、ページ ヘッダーには、ページ 100 の 2 番目の変更のログ レコードに格納されている前回の LSN は存在しませんし、ありません前のログ レコードがページに存在します。回復を安全に続行できません、ため、データベース、未確認します。

例 3: バックアップができないサイレントのバックアップ チェーンの改

例 2 は、このような問題が発生した可能性がありますの一部だけです。この例では、リカバリ モードではなく「単純な」ご配置データベース「完全復旧」モード ログとデータベースの定期的なバックアップを実行します。最初に、そのままログ チェインをしただけで、この問題を解決するのには、復元シーケンスを実行できませんでしたのでこのことをお勧めするが表示されます。

バックアップ ファイルまたは一部分が予期せずキャッシュできるため、キャッシュ実装によって「オプトアウト」ポリシーを使用するときは、有効な前提データをことがあります。SQL Server SQL Server バックアップ ファイルをフラッシュすると、バックアップ メディアへの書き込みはすべて正しくまたは Win32 API を使用して、安定したメディアに格納されていることが必要 FlushFileBuffers 関数です。したがって、キャッシュ仕入先のすべての書き込みが正しくフラッシュ、確実ではない場合は、中には、 FlushFileBuffers 操作は正常に完了する前に、安定したメディアへの関数呼び出しは、データベース エンジンをセキュリティで保護されたバックアップのことがなく、ログを切り捨てます。もう一度、電源障害この時点で条件の適切なログ レコードが不足しているし、クラッシュ復旧を失敗可能性がありますが発生します。重要なは、クラッシュ ・ リカバリ、データベース内のログ レコードが不足しているためのこれを検出することはできませんし、バックアップ チェーン サイレントが破損している可能性がありますです。のみ、バックアップを復元しようとすると、データベース エンジンは、バックアップが破損しているかを示すことができます。

例 4: 無効なデータベースの状態

データベース ファイルには、他の厳密な書き込みを必要とする、すべてのグループに適用することによってコンプライアンスを注文間の依存関係が含まれます。無効な前提データ、ログ ファイルのみを選択するようにポリシーを作成、いくつかの書き込みを必要とするデータ ファイルでは、発生することが、主要なデータベース ・ アクティビティのチェックポイント、ファイル サイズの変更、差分バックアップ、ログに記録されない操作および一括ログ記録復旧モデルです。

例 5: スナップショット データベース データ損失 ? ありますサイレント

SQL Server 2005 はスナップショット データベースのポイント ・ イン ・ タイムのクエリについて説明します。これは、データベースのコピー オン ライト テクノロジを使用して、基本データベース内のデータ ページには、新しい変更が行われる前に、スナップショット データ データベース内のデータ ページのコピーをセキュリティで保護します。このプロセスは、トランザクションを続行する前に、スナップショット データベースに、ページを保護する必要があります。データ整合性の問題は、ページ上または安定したメディアにセキュリティ保護されていない場合は、保持されます。ページの書き込みは非常に重要です、スナップショット データベース、トランザクション ・ ログはありません。電源異常の場合のようなものが発生した場合は、メイン データベース ページが変更されていますが、キャッシュされた書き込みが失われたためスナップショットが前のイメージに反映していない可能性があります。

構成する方法

ファイル キャッシュから何かない-バッテリ バックアップ キャッシュは、ベンダーの実装に固有であるようにすることは、製品を構成する方法ただし、いくつかの規則が適用できます。
  • I/O が完了したことを示すキャッシュをオペレーティング システムにすべての書き込みまたは安定したメディアに完了する必要があります。
  • 読み取り要求がキャッシュから処理されたまたは安定したメディア上にあるように、同じイメージを返す限り、データをキャッシュできます。
これらのルールは基本的にない-バッテリ バックアップ キャッシュ読み取り操作を有効にする可能性がありますが、書き込み要求では使用できませんを意味します。適切な構成では、これはデータベース エンジンのパフォーマンスの向上を提供できます。これは、必要があります、しかし、SQL Server で使用可能な RAM の全体的なパフォーマンスが低下する可能性がありますと同じように何か別途設定ために、慎重にテストします。SQL Server より一般的なキャッシュ メカニズムを正確に、余分なメモリを使用する必要があります。

読み取り専用データベース

読み取り専用データベースを例として、これらの製品の種類を excel をことがあります。データベースが作成され、データの整合性、読み取りのみ、データベースをマークするために使用する ALTER DATABASE ステートメントとその後、キャッシュ メカニズムに割り当てられているデータベースを確実に安定したメディアに格納されている最初の場合は、パフォーマンスの向上が発生します。実装によって圧縮画像データベース ・ ページの物理データをキャッシュから取得することができ、物理 I/O の削減は、キャッシュに保持します。

注意 WAL プロトコルを維持しませんがキャッシュに割り当てられている場合の読み取り/書き込みデータベース必要があります。

セキュリティ

キャッシュは、RAM ベースのファイル システムのキャッシュなどのご紹介「メモリ不足」の別の場所にデータを紹介します。データベース エンジンなどの製品は、重要なデータまたは安定したメディア上に保存されているし、正しくアクセス制御リスト (ACL) の保護を維持を想定できます。RAM ベースのキャッシュはデータに一連のセキュリティ上の問題は、安定したメディアと比較一意である危険です。たとえば、アプリケーションのようなものを使用するように設計されています、 SecureZeroMemory 関数を重要な情報、アプリケーションの使用を終了するたびにデータは RAM が存在することを期待を持っています。ただし、アプリケーションや安定したメディアに期待すると、フォームのデータのキャッシュに残ることができる場合は、セキュリティ上の考慮を変更可能性があります。

データの整合性チェック

マイクロソフトは、常に強力な明確にデータ整合性戦略をお勧めします。これは、含める必要がありますが、バックアップと通常の DBCC CHECKDB 操作を本番データと、復元されたデータベースに復元するには、限定されるわけでいます。

評価し、環境への変更を実装する際、または環境の安定性に関連する問題を発生する場合は、このような安全性テストの頻度を増やすことをもお勧めします。

詳細については、SQLIOStress を使用する方法ユーティリティは、Knowledge Base の資料を参照するのには、次の資料番号をクリックします。
231619SQLIOStress ユーティリティを使用する方法SQL Server などのディスク サブシステムを強調するには

TEMPDB データベース

検索することもできますが、 TEMPDB 特定キャッシュ システム上のデータベース。いくつかの要因慎重に検討し、必要がありますテストの格納場所を評価する際に、 TEMPDB この構成に含まれる ◇Knowledge Base の次の資料では、I/O 要件、関連のサポートの範囲、およびパフォーマンスの向上について説明します。
917047 TEMPDB データベースは Microsoft SQL Server I/O サブシステムの要件

サポート

お客様の標準的なデータ復旧技術を使用して、Microsoft SQL Server のサポートに役立ちます。それまで、データの整合性に異議を Microsoft SQL Server、Active Directory および Exchange のサポート製品をアンインストールすることを要求する可能性がありますコンピューターの描画され上にインストールされている製品根本原因解析が関与しない場合は、問題と製品も再現できます。

マイクロソフト認定や、サード ・ パーティ製品と SQL Server が正常に動作ことを確認しません。さらに、マイクロソフト、保証、保証、またはステートメントの SQL Server で使用したサード パーティ製品への適合性はありません。

関連情報

SQL Server のパフォーマンスの向上を評価するのには、次の参照では、関連する追加情報を慎重に検討します。

826433 その他の SQL Server 診断報告されない入出力の問題を検出するために追加
828339 ハードウェアの問題またはシステムの問題では、SQL Server エラー メッセージ 823 がある可能性があります。
234656 SQL Server がディスク ドライブのキャッシュを使用します。
110352 Microsoft SQL Server のパフォーマンスを最適化します。
304261 ネットワーク ・ データベース ・ ファイル SQL Server でのサポートの説明
910716 サード パーティのリモート ・ ミラーリング ・ ソリューションをサポート SQL Server 2000年および 2005年のユーザーがデータベースを使用します。
913945 マイクロソフトサード ・ パーティ製品がマイクロソフト SQL が動作することを保証しません。サーバー
SQL Server、Microsoft SQL Server、Always-On、ストレージ ソリューション レビュー プログラムで概説されている '確実な配信を安定したメディア' をサポートするために、システムする必要があります。参加者SQL Server データベース エンジン用の入出力の要件の詳細については、Knowledge Base の資料を参照するのには、次の資料番号をクリックしてください。
967576Microsoft SQL Server データベース エンジンの入出力の要件

プロパティ

文書番号: 917043 - 最終更新日: 2011年7月19日 - リビジョン: 3.0
キーワード:?
kbinfo kbexpertiseadvanced kbmt KB917043 KbMtja
機械翻訳の免責
重要: このサポート技術情報 (以下「KB」) は、翻訳者による翻訳の代わりに、マイクロソフト機械翻訳システムによって翻訳されたものです。マイクロソフトは、お客様に、マイクロソフトが提供している全ての KB を日本語でご利用いただけるように、翻訳者による翻訳 KB に加え機械翻訳 KB も提供しています。しかしながら、機械翻訳の品質は翻訳者による翻訳ほど十分ではありません。誤訳や、文法、言葉使い、その他、たとえば日本語を母国語としない方が日本語を話すときに間違えるようなミスを含んでいる可能性があります。マイクロソフトは、機械翻訳の品質、及び KB の内容の誤訳やお客様が KB を利用されたことによって生じた直接または間接的な問題や損害については、いかなる責任も負わないものとします。マイクロソフトは、機械翻訳システムの改善を継続的に行っています。
英語版 KB:917043
Microsoft Knowledge Base の免責: Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com