SQL Server でのデータの信頼性を拡張するログとデータのストレージ アルゴリズムの説明

重要: このサポート技術情報 (以下「KB」) は、翻訳者による翻訳の代わりに、マイクロソフト機械翻訳システムによって翻訳されたものです。マイクロソフトは、お客様に、マイクロソフトが提供している全ての KB を日本語でご利用いただけるように、翻訳者による翻訳 KB に加え機械翻訳 KB も提供しています。しかしながら、機械翻訳の品質は翻訳者による翻訳ほど十分ではありません。誤訳や、文法、言葉使い、その他、たとえば日本語を母国語としない方が日本語を話すときに間違えるようなミスを含んでいる可能性があります。マイクロソフトは、機械翻訳の品質、及び KB の内容の誤訳やお客様が KB を利用されたことによって生じた直接または間接的な問題や損害については、いかなる責任も負わないものとします。マイクロソフトは、機械翻訳システムの改善を継続的に行っています。

英語版 KB:230785
概要
この資料では Microsoft SQL Server のログ記録とデータのアルゴリズムでのデータの信頼性と整合性の拡張方法について説明します。

ARIES (アルゴリズム ・独立性を悪用する意味) およびエンジンの基礎となる概念に関する詳細についてを参照してください、次の ACM トランザクション データベース システムのドキュメント (「ボリューム番号 1、3 月の 1992 第 17) の下で。

このドキュメントのリード ライターは C. Mohan です。ドキュメントは、SQL Server データの信頼性と整合性に関する障害を拡張する方法について説明します。

キャッシュに関する詳細については、マイクロソフト サポート技術情報の次の記事を読むことをお勧めや代替障害モードの議論。
86903 SQL Server のディスク コント ローラーのキャッシュの説明
234656 ディスク ドライブのキャッシュを使用して、SQL Server のすべてのデータベース管理者が知っておくべきことをについての情報
詳細
詳細な説明を始める前にこの資料で使用されている用語の一部は、次の表で定義されます。
用語定義
バッテリ ・ バックアップ別のローカライズされたバッテリ バックアップ機能直接キャッシュ メカニズムによって制御されるとデータ損失を防ぐために。
注: <b>無停電電源装置 (UPS) ではありません。UPS は書き込み動作を保証していないと、キャッシュ装置から切断されることができます。
キャッシュ物理的な I/O 操作の最適化し、性能向上に使用される中間記憶のメカニズム。
ダーティ ページ安定記憶にフラッシュする必要があるデータ変更を含むページ。ダーティ ・ ページのバッファーの詳細についてを参照してください、"ページを作成「SQL Server Books Online にあるトピックです。
注: <b>コンテンツは、Microsoft SQL Server 2012年およびそれ以降のバージョンにも適用されます。
障害が発生SQL Server プロセスの予期しない停止を引き起こす可能性のあるものです。例: 電源の停止、コンピューターのリセット、メモリ エラー、その他のハードウェアの問題、不良セクター、ドライブ停止、システム障害、およびなど。
フラッシュ安定記憶にキャッシュ バッファーを強制的します。
ラッチ同期オブジェクトがリソースの物理的一貫性の保護に使用されます。
不揮発性記憶システム障害が発生した使用可能な残りのメディア。
固定されたページデータはキャッシュし、すべての関連付けられているログ レコードが安定記憶領域にセキュリティで保護されているまで安定記憶にフラッシュされないページ。
安定記憶不揮発性記憶に同じ。
揮発性記憶メディアはないそのまま障害が発生しました。

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

プロトコルという用語は WAL を記述するための優れた方法です。特定し、定義された一連の実装手順のために必要なデータが格納され正常に交換し、障害発生時に既知の状態にリカバリできます。ので、一貫性があり保護された方法でデータを交換するには、定義済みプロトコルがネットワークに関して存在と同様、WAL はデータを保護するプロトコルについてはすぎます。

ARIES の文書は次のように、WAL を定義します。
WAL プロトコルは、ことを表すいくつかのデータ変更のログ レコードする必要があります既に安定した記憶領域に、変更されたデータが不揮発性記憶域内のデータの以前のバージョンを置き換えることができる前にアサートします。つまり、システムは少なくともするまでは、ページの不揮発性記憶バージョンを更新されたページを作成するページには、更新プログラムを説明するログ レコードの undo 部分が安定記憶に書き込まれました。
先行書き込みログ記録の詳細についてを参照してください、 先行書き込みトランザクション ログ SQL Server Books Online にあるトピックです。

SQL Server と WAL

SQL Server は、WAL プロトコルを使用します。トランザクションが正常にコミットされたことを確認するには、トランザクションに関連付けられているすべてのログ レコードが安定記憶に保護する必要があります。

このような状況を明確にするには、次の特定の例を検討してください。

注: <b>次の使用例は、インデックスがないと、影響を受けるページがページ 150 であると仮定します。
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
次に、細分化、活動は、単純なログ記録手順に、次の表で説明されているように。
ステートメント実行するアクション
トランザクションを開始します。ログ キャッシュ領域に書き込まれます。ただし、SQL Server が任意の物理的な変更が行われないために、安定記憶にフラッシュする必要はありません。
TblTest の挿入
  1. 既に利用できない場合、データ ページ 150 が SQL Server のデータ キャッシュに取得されます。
  2. ページが ラッチ, 固定、と ダーティとしてマーク付け、し、適切なロックが取得されます。
  3. Insert ログ レコードは作成され、ログ キャッシュに追加します。
  4. 新しい行がデータ ページに追加されます。
  5. ラッチが解放されます。
  6. ログ レコードは、トランザクションに関連付けられているか、ページのすべての変更はまだ揮発性記憶にあるため、この時点でフラッシュする必要はありません。
トランザクションをコミットします。
  1. Commit ログ レコードが形成され、トランザクションに関連付けられているログ レコードが安定記憶に書き込まする必要があります。トランザクションは、ログ レコードが安定記憶に正常に割り当てられているまでにコミットされたとは見なされません。
  2. データ ページ 150 が SQL Server のデータ キャッシュに残っているおり、安定記憶にはすぐにフラッシュされません。ログ レコードが正しく安全であり、ときに回復必要がある場合、操作をやり直すことができます。
  3. トランザクション ロックが解放されます。
操作を混同しないでくださいで用語が「ロック」および「ログ記録」重要なロックとログ記録は別の問題と、WAL を扱う場合です。前の例で SQL Server の一般的にラッチを保持ページ 150 時間のトランザクションの時間全体ではなく、ページでは、物理的な挿入変更の実行に必要です。適切なロックの種類は、行、範囲、ページ、またはテーブルが必要に応じて保護するために確立されます。ロックの種類に関する詳細については、SQL Server オンライン ブックのロック セクションを参照してください。

例の詳細に見ると、レイジー ライターまたはチェックポイント プロセスを実行したときの動作を確認可能性があります。SQL Server 7 を安定記憶、ダーティかつ固定されたページに関連付けられたトランザクション ログ レコードに対して、すべての適切なフラッシュが発行されます。これは、WAL プロトコルのデータ ページが、関連付けられたトランザクション ログ レコードがフラッシュされるまでは、安定記憶に書き込まれないことを確認します。

SQL Server を安定記憶

SQL Server のディスク セクターのサイズ (一般的 4,096 または 512 バイト) の情報を含むログとデータ ページ操作が向上します。

トランザクションの ACID プロパティを維持するために、SQL Server の障害点考慮あります。ディスク ドライブの仕様の多くは、障害発生時に、セクター書き込み操作の限られた量のみ保証されます。ほとんどの仕様では、障害が発生したときに単一セクター書き込みの完了が保証されます。

SQL Server を使用 8 KB のデータ ページとログ (フラッシュ) する場合、セクター サイズの倍数にします。(ほとんどのディスク ドライブを使用して 512 バイトとして、デフォルトのセクター サイズです。)障害時、SQL Server が書き込み動作の報告、セクターより大きいログ パリティと破損書き込みの手法によって。

破損ページ検出

SQL Server の電源障害やその他のシステムの停止によって発生した、不完全な I/O 操作を検出することができます。ページが書き込まれるたびに、8 キロバイト (KB) のデータベース ページ内の 512 バイト セクターごとに反転させるのには、ビットが true の場合、ディスクにします。少しは間違った状態で後が、ページを読み取る場合 SQL Server によって、ページ正しく書き込まれていません。破損したページが検出されます。正しく書き込まれていないページは復旧によって読み取られるため、通常、破損ページは復旧中に検出されます。

SQL Server のデータベース ページは 8 KB が、ディスクは 512 バイト セクターを使用して I/O 操作を実行します。したがって、1 データベース ページあたり 16 個のセクターが書き込まれます。破損ページは (たとえば、電源障害) のために、システム障害が発生した場合は、時間をオペレーティング システムが最初の 512 バイト セクターをディスクに書き込みますと、8 KB の I/O 操作の完了との間に発生します。場合、障害発生前に正常にデータベース ページの最初のセクターが書き込まれるディスク上のデータベース ページが更新、ない成功している可能性がありますがされます。

バッテリ付きディスク コント ローラーのキャッシュを使用することができるかどうか、ディスクへのデータの書き込みが完了したことを確認に書き込まれます。このような場合は、設定しないで破損ページの検出を"true"必要はありません。

注: <b>破損ページ検出は、既定では、SQL Server では使用できません。詳細については、次の MSDN web サイトを参照してください。

ログ パリティ

ログ パリティ チェックは、破損ページ検出と非常に似ています。512 バイト セクターごとにパリティ ビットが含まれています。このパリティ ビットは常にログ レコードに書き込まれます、ログ レコードが取得されると評価されます。512 バイト境界での強制ログ書き込み、SQL Server ことができますようにコミット操作が物理的なディスク セクターに完全に書き込まれることです。

7.0 より前のバージョンの SQL Server

以前のバージョンの SQL Server 7.0 よりも提供しませんでしたログ パリティや破損ビット検出機能。実際には、これらのバージョンは、同一のログ ページ複数回書き、ログ レコードが 2 KB のログ ページを埋めるまでです。これは正常にコミットされたトランザクションを公開できます。場合は、障害発生時に、ログ ページが書きこまれていると、コミットされたトランザクションのセクターが書き込まれていない正しく。

パフォーマンスへの影響

SQL Server のすべてのバージョンは、Win32 のCreateFile関数を使用して、ログとデータ ファイルを開きます。DwFlagsAndAttributesメンバーには SQL Server が開いたときにせずに FILE_FLAG_WRITE_THROUGHオプションが含まれます。
せずに FILE_FLAG_WRITE_THROUGH
システムが中間キャッシュをスルーしてディスクに直接書きこむよう指示します。システムはキャッシュ書き込み操作をできませんレイジーでフラッシュするには

せずに FILE_FLAG_WRITE_THROUGH オプションは、書き込み操作が正常に完了を返すときに、データが正しく安定記憶に保存されることを確認します。これは、WAL プロトコルのデータを保証すると揃えて配置します。
多数のディスク ドライブ (SCSI や IDE) には、512 KB、1 MB 以上のオンボード キャッシュが含まれています。ただし、ドライブ キャッシュは通常コンデンサーおよびバッテリ ・ バックアップ ・ ソリューションではない依存します。これらのキャッシュ メカニズムまたは同様のエラー、電源の書き込みサイクルを保証できません。また、セクター書き込み操作の完了がのみ保証されます。これは、具体的には、破損書き込みとログ パリティ検出が SQL Server 7.0 およびそれ以降のバージョンに組み込まれている理由です。ドライブのサイズが大きくなるに従って、キャッシュのサイズが大きく、なるし、大量のデータを公開するには、障害発生時にします。

多くのハードウェア ベンダーは、バッテリ付きディスク コント ローラーのソリューションを提供します。これらのコント ローラー キャッシュ、キャッシュ内のデータを数日間維持し、2 台目のコンピューターに配置する、キャッシュのハードウェアを使用することも。電源が正しく復元されているときに、以降のデータ アクセスを許可する前に、未書き込みのデータは完全にフラッシュされます。それらの多くは読み取りの割合と書きこみのキャッシュの最適なパフォーマンスを確立するようにします。大容量メモリのストレージ領域が含まれます。実際には、市場の非常に特定のセグメントを一部のハードウェア ベンダーはハイエンドのバッテリ付きディスク キャッシュ コント ローラーのシステムと 6 GB のキャッシュを提供します。これは、データベースのパフォーマンスが大幅に向上します。

最新のキャッシュ実装によって true を提供できるので、コント ローラー キャッシュを無効にせずに FILE_FLAG_WRITE_THROUGHのを要求するハンドルいきます、システム リセット、電源障害、またはその他の障害が発生しました。

キャッシュを使用せずに I/O 転送に、機械的にドライブのヘッドは、回転数、およびその他の制限要因を移動するために必要な時間のため、長いことができます。

セクター順序付け

I/O のパフォーマンスを向上するために使用する一般的な手法はセクター順序付けします。機械的なヘッドの移動を回避するためより一貫性のある運動のヘッドを取得したり、データを格納したりできるように読み取り/書き込みの要求がソートされています。

複数のログを保持できる、キャッシュとデータ書き込み要求を同時に。WAL プロトコルおよび WAL プロトコルの SQL Server の実装は、ページ書き込みが発行される前に、安定記憶に書き込まれます、ログのフラッシュが必要です。ただし、キャッシュを使用することが成功を返す、ログ書き込み要求 (つまりは、安定記憶に書き込まれます) の実際のドライブに書き込まれるデータがないです。これは、SQL Server のデータ ページの書き込み要求を発行する可能性があります。

書き込みキャッシュが介在、データはまだ揮発性記憶と見なされます。ただし、 WriteFileの Win32 API の呼び出しを SQL Server の活動を表示するかを明確に成功リターン コードが取得されました。SQL Server またはWriteFileAPI の呼び出しを使用するプロセスは、そのデータが正しく安定記憶に保存を取得を決定できます。

説明のために、データ ページのすべてのセクターが、合致するログ レコードのセクターの前に記述する並べ替えられていると仮定します。これは、WAL プロトコルに違反します。キャッシュはログ レコードの前にデータ ページを書き込みます。キャッシュは、完全にバッテリによってバックアップをしない限り、障害は壊滅的な結果になります。

データベース サーバーに対する性能の最適化要素を評価するときに考慮すべき多くの要因があります。これらの最も重要なが私のシステムを許可するせずに FILE_FLAG_WRITE_THROUGH 機能を無効しますか?]

注: <b>任意のキャッシュを完全に usingmust があることは、バッテリ ・ バックアップ ・ ソリューションをサポートします。他のすべてのキャッシュ メカニズムは、データ破壊やデータの損失の問題です。SQL Server では、WAL にせずに FILE_FLAG_WRITE_THROUGH を有効にするとします。

テストは多くのディスク ドライブ構成には、適切なバッテリ バックアップされていない書き込みキャッシュが含まれているが表示されます。SCSI、IDE、EIDE ドライブの書き込みキャッシュを最大限に活用します。SQL Server との Ssd の機能についてを参照してください以下の CSS SQL Server エンジニアのブログの記事。


多くの構成では正しく、IDE や EIDE ドライブの書き込みキャッシュを無効にする唯一の方法は、特定のメーカーのユーティリティを使用して、または、ドライブ上にあるジャンパーを使用してです。ドライブ自体に書き込みキャッシュが無効であるかどうかを確認をするには、ドライブの製造元に問い合わせてください。

SCSI ドライブは書き込みキャッシュもあります。ただし、これらのキャッシュは、オペレーティング システムによってよく無効になります。疑問がある場合は、適切なユーティリティをドライブの製造元に問い合わせてください。

書き込みキャッシュ スタック

書き込みキャッシュ スタックはセクター順序付けに似ています。次の定義は、大手の IDE ドライブ製造元の web サイトから直接実行します。
通常、このモードはアクティブです。書き込みキャッシュ モードは、ホスト書き込みデータをバッファーにバッファーが完全かホストの転送が完了するまでを受け付けます。

ホスト ・ データをディスクに保存するには、ディスクの書き込みタスクを開始します。ホストの書き込みコマンドは引き続き受け付けられ、書き込みコマンドのスタックがいっぱいか、データ バッファーがいっぱいになるまで、バッファーにデータを転送します。ドライブは、ドライブのスループットを最適化するための書き込みコマンドを並べ替え可能性があります。

自動書き込み再割り当て (AWR)

データを保護するために使用する別の一般的な技法は、データ操作中に不良セクターを検出します。以下の説明では、大手の IDE ドライブ製造元の web サイトから。
この機能は、ライト ・ キャッシュの一部であるし、遅延書き込み操作中にデータ損失のリスクを軽減します。ディスク書き込み処理中にディスク エラーが発生した場合は、ディスクのタスクは停止し、問題のあるセクターはドライブの最後にある代替セクターのプールに再割り当てされます。ディスクの書き込みタスクは再配置には、次のことが完了するまでが続行されます。
これはキャッシュのバッテリ ・ バックアップを提供する場合、非常に強力な機能ができます。これは、再起動時に、適切な変更を提供します。ディスク エラーを検出することをお勧めは、WAL プロトコルのデータ セキュリティがリアルタイムに実行するのには、この要求を遅延処理ではなく。WAL パラメーター内では、AWR の手法はセクター エラーのため、ログの書き込みが失敗するが、ドライブがいっぱい状況のアカウントします。データベース エンジンは、知る必要がありますすぐに失敗に関するトランザクションを正しく中止されるため、管理者は、警告することができ、データを保護し、メディアのエラー状態を修正する手順を修正します。

データの安全性

データベース管理者は、データの安全性を確実に実行されるいくつかの注意事項があります。
  • 常に、壊滅的な障害から回復するための十分なバックアップ戦略であるかどうかを確認することをお勧めします。オフサイトでの保管、およびその他の注意事項は、適切です。
  • [セカンダリ データベースの復元操作または頻繁にテスト データベースをテストします。
  • すべてのキャッシュ デバイスがあらゆる障害状態 (停電、不良セクター、ドライブ不良、システム停止、ロックアップ、電源でのスパイクなど) を処理できるかどうかを確認します。
  • 確認してくださいキャッシュ デバイス。
    • バッテリ バックアップが内蔵されて
    • 書き込みを再発行できる電源投入時に
    • 完全に無効にする必要がある場合
    • 不良セクターの再マップをリアルタイムで処理します。
  • 破損ページの検出を有効にします。(これはパフォーマンスにほとんど影響しません)。
  • 可能な場合は、不良ディスク ドライブのホット スワップを許可する RAID のドライブを構成します。
  • OS を再起動せずにディスク領域を追加することができる、新しいキャッシュ コント ローラーを使用します。これは、理想的なソリューションです。

ドライブのテスト

データを完全に保護するには、すべてのデータのキャッシュが正しく処理されることを確認する必要があります。多くの場合、ディスク ドライブの書き込みキャッシュは無効にする必要があります。

注: <b>メカニズムをキャッシュする代わりに、複数の種類の障害を正しく処理できるかどうかを確認します。

マイクロソフトでは、 SQLIOSimユーティリティを使用して複数の SCSI と IDE ドライブのテストを実施します。このユーティリティは、シミュレートされたデータ デバイスとログ デバイスを非同期読み取り/書き込みアクティビティをシミュレートします。テスト パフォーマンスの統計情報は、平均の書き込み操作あたりのドライブの書き込みキャッシュが無効の 50 ~ 70 秒と 5,200 ~ 7,200 RPM 範囲を表示します。

SQLIOSimユーティリティの詳細については、次の資料、マイクロソフト サポート技術を参照してください。
231619 SQLIOSim ユーティリティを使用して、ディスク サブシステム上の SQL Server のアクティビティをシミュレートする方法
多くのコンピューター製造元は、書き込みキャッシュを無効にしてドライブをオーダーします。ただし、テストをこのできない可能性がある場合は示しています。そのため、常に完全なテストです。

データ デバイス

すべてがログに記録されない場合は、SQL Server はログ レコードのフラッシュのみを必要とします。ログに記録されない操作を実行する場合、データ ページ必要がありますもは安定記憶にフラッシュします。障害時にアクションを再生成する個別のログ レコードはありません。

データ ページは、レイジー ライターまたはチェックポイント プロセス安定記憶にフラッシュするまでキャッシュに残ります。WAL プロトコルを使用して、ログ レコードが正しく格納されているかどうかを確認するのには、データ ページを既知の状態を復旧できますを確認します。

キャッシュされたドライブにデータ ファイルを配置することをお勧めするわけではありません。安定記憶にデータ ページをフラッシュするは、SQL Server の場合は、ログ レコードは、トランザクション ログから切り捨てられます。データ ページが揮発性キャッシュに保存し、障害発生時にページの復旧に使用するログ レコードが切り捨てを可能性があります。データとログの両方のデバイスに安定記憶に保存を正しく対応できることを確認します。

パフォーマンスの向上

発生した最初の質問は:」に IDE ドライブがあります。無効にすると、性能が予想よりも大幅に削減します。なぜですか?」

5,200、RPM 速度で実行される多くの IDE ドライブを Microsoft でテストされたのと、SCSI ドライブ、7,200 RPM で。書き込みを無効にすると、IDE ドライブのキャッシュ、機械のパフォーマンスになります係数。

パフォーマンスの違いに対処する非常に明確な領域があります:「トランザクション レート アドレス」。

多くのオンライン トランザクション処理 (OLTP) システム、高いトランザクション ・ レートが必要になることがあります。これらのシステムでは、ライト ・ キャッシュをサポートおよびデータの整合性を確保しながらパフォーマンスを向上するには、適切なキャッシュ コント ローラーの使用を検討します。

大幅に SQL Server のキャッシュ ドライブ上の性能の変化で発生するには、小さなトランザクションを使用してトランザクション レートを増加させました。

高い書き込みバッファーの 512 KB 以上 2 MB より大きい値であることを示していますテストのパフォーマンスが低下可能性があります。
次の使用例を検討してください。
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
SQL Server のサンプル テストの結果を次に示します。
SCSI(7200 RPM) 84 秒
SCSI(7200 RPM) の 15 秒間 (コント ローラーのキャッシュ)

IDE(5200 RPM) 14 秒 (ドライブ キャッシュが有効な場合)
IDE(5200 RPM) 160 秒

1 つのトランザクションで、全体の一連の INSERT 操作の折り返しはすべての構成では、約 4 秒で実行されます。

必要なログのフラッシュの数です。、トランザクションなしの場合各挿入トランザクション自体、ありたびに、トランザクションに対するログ レコードをフラッシュする必要があります。各フラッシュは 512 バイトで、大きな機械的なドライブへの書き込みを必要とします。

1 つのトランザクションを使用する場合は、トランザクションに対するログ レコードはまとめし、単一の大きなサイズの書き込み収集されたログ レコードをフラッシュすることができます。機械的な要素が大幅に低下します。

警告:トランザクションのスコープを増やさないことをお勧めします。実行時間の長いトランザクションが過剰で不必要なブロッキングする可能性し、オーバーヘッドの増加します。SQL Server: データベースの SQL Server のパフォーマンス カウンターを使用して、トランザクション ログ ベースのカウンターを表示します。具体的には、フラッシュされたログのバイト送受信が高いディスクの利用状況を多くの小さいトランザクションを指定できます。

ログのフラッシュに関連付けられているステートメントをログのフラッシュ回数を削減するかどうかを確認できます。前の例では、1 つのトランザクションが実装されました。ただし、多くの場合、このロックの好ましくない動作をする可能性があります。トランザクションの設計を確認します。頻繁で小さいサイズのログのフラッシュ処理を減らすためにバッチを実行するのにには、次のようなコードを使用できます。
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server が必要なシステムをサポートしている「確実な配信、安定したメディアに」で説明されているように、 SQL Server の I/O の信頼性プログラムのレビュー要件 ドキュメントをダウンロードします。 SQL Server データベース エンジンでは、入力と出力の要件の詳細については、次の技術情報の記事に移動する次の文書番号をクリックしてください。
967576 Microsoft SQL Server データベース エンジンの入力と出力の要件

警告: この記事は自動翻訳されています

プロパティ

文書番号:230785 - 最終更新日: 05/17/2015 07:11:00 - リビジョン: 1.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbhowto kbinfo kbmt KB230785 KbMtja
フィードバック