SQL Server 7.0、SQL Server 2000、および SQL Server 2005 のログ記録とデータ記憶アルゴリズムによるデータの信頼性の向上

文書翻訳 文書翻訳
文書番号: 230785 - 対象製品
この記事は、以前は次の ID で公開されていました: JP230785
すべて展開する | すべて折りたたむ

目次

概要

データの信頼性と整合性の向上を目的として、SQL Server 7.0、SQL Server 2000、および SQL Server 2005 では Microsoft SQL Server の以前のリリースから、ログ記録方式とデータのアルゴリズムの再構築および再設計が行われました。

SQL Server 7.0 エンジンおよび SQL Server 2000 エンジンを支える基本概念の詳細については、『ACM Transactions on Database Systems』の「ARIES (Algorithm for Recovery and Isolation Exploiting Semantics): A Transaction Recovery method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging」を参照することをお勧めします。この文書の著者は Chunder Mohan です。

この資料では、SQL Server 7.0、SQL Server 2000、および SQL Server 2005 でのデータの信頼性と整合性を向上する手法を障害と関連付けて説明します。

キャッシュや代替障害モードの詳細な説明については、「サポート技術情報」 (Microsoft Knowledge Base) の次の資料を読むことをお勧めします。
86903 [SQL]INF: SQL Server とディスク コントローラのキャッシュ
46091 SQL Server でハード ディスク コントローラ キャッシュを使用する
234656 INF: SQL Server でディスク ドライブのキャッシュを使う。

詳細

詳細説明の前に、この資料で使用する用語のいくつかについて次の項で定義します。
元に戻す全体を表示する
用語 定義
バッテリ付き (の) データ消失を防止するための、直接利用可能でキャッシュ メカニズムによって制御される個別のローカライズされたバッテリ バックアップ機能。
: これは無停電電源装置 (UPS) とは異なります。UPS は書き込み動作を保証せず、キャッシュ装置から切断される可能性があります。
キャッシュ 物理的な I/O 操作の最適化と性能向上に使用される中間記憶メカニズム。
ダーティ ページ 安定記憶にフラッシュされる必要があるデータ変更を含むページ。ダーティ ページ バッファの詳細については、SQL Server Books Online を参照してください。
障害 SQL Server 処理の意図しない停止をもたらすもの。例 : 停電、コンピュータのリセット、メモリ エラー、その他のハードウェアの問題、不良セクタ、ドライブ停止、OS 障害など。
フラッシュ 安定記憶にキャッシュ バッファを強制的に書き込むこと。
ラッチ リソースの物理的一貫性の保護に使用する同期化オブジェクト。
不揮発性記憶 システム障害が発生した後も利用可能なメディア。
固定されたページ 関係付けられたログ レコードが安定記憶にすべて安全に保存されるまで、データ キャッシュに残り安定記憶にフラッシュされないページ。
安定記憶 不揮発性記憶に同じ。
揮発性記憶 障害が発生した後、内容が元どおりにならないメディア。
SQL Server 2005、SQL Server 2000、SQL Server 7.0、以前のバージョンの SQL Server、および今日の市場で主流をなすデータベース製品の多くが、先行書き込みログ (WAL) プロトコルを使用しています。

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

プロトコルという用語は WAL をよく表しています。WAL は、特定の定義された一連の実装手順で、データの保存と交換の確実な実行、および、障害発生時における既知の状態への復旧を保証するために必要なものです。一貫性があり保護された方法でデータ交換を行うための定義済みプロトコルがネットワークに関して存在するように、WAL でも同様にデータを保護するプロトコルが記述されます。

ARIES の文書では WAL は次のように定義されています。
WAL プロトコルでは、不揮発性記憶内にある変更前データを、変更後のデータで置換することが許可されるには、その前にデータ変更を記録したログ レコードが安定記憶に保存されていることが必要となります。つまり、少なくともページ更新を記録したログ レコードの UNDO 部分が安定記憶に書き込まれるまで、更新されたページの不揮発性記憶への書き込みはシステムによって許可されません。
先行書き込みログ (WAL) の詳細については、SQL Server Books Online を参照してください。

SQL Server と WAL

SQL Server 2005、SQL Server 2000、SQL Server 7.0、および以前の SQL Server リリースでは、WAL プロトコルを使用しています。トランザクションを適切にコミットするには、トランザクションに関連付けられたすべてのログ レコードが安定記憶内で保護される必要があります。

よりわかりやすくするために、以下の特定の例について考えます (この例では、インデックスがないこと、および影響を受けるページが 150 ページ目であることを想定しています)。
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
ここで行われる操作を、以下の単純なログ記録手順に分割します。
元に戻す全体を表示する
ステートメント 実行される操作
BEGIN TRANSACTION ログ キャッシュ領域に書き込まれますが、SQL Server による物理的変更は行われないため、安定記憶にフラッシュする必要はありません。
INSERT INTO tblTest 1. データ ページ 150 が SQL Server のデータ キャッシュに取得されます (まだ利用可能ではない場合)。

2. ページは、ラッチおよび固定され、ダーティ ページとしてマーク付けされます。該当するロックが取得されます。

3. Insert ログ レコードが作成され、ログ キャッシュに追加されます。

4. 新規行がデータ ページに追加されます。

5. ラッチが解放されます。

6. すべての変更はまだ揮発性記憶にあるため、トランザクションやページに関係付けられたログ レコードは、この時点ではフラッシュされる必要はありません。
COMMIT TRANSACTION 1. Commit ログ レコードが作成され、トランザクションに関係付けられたログ レコードが安定記憶に書き込まれる必要があります。ログ レコードが正しく安定記憶に割り当てられない限り、トランザクションがコミットされたとは見なされません。

2. データ ページ 150 は、SQL Server のデータ キャッシュに残っており、安定記憶にはすぐにフラッシュされません。ログ レコードが正しく安全に保存されていれば、必要に応じて、復旧により操作をやり直すことが可能です。

3. トランザクション ロックは解除されます。
ロックとログ記録は混同しないように注意する必要があります。いずれも重要ですが、WAL を扱う場合、ロックを行うこととログを記録することは異なります。上記の例では、SQL Server 7.0、SQL Server 2000、および SQL Server 2005 は一般的に、トランザクションの時間全体ではなく、ページにおける物理的な挿入変更の実行に必要な時間だけページ 150 のラッチを保持します。適切なロックの種類が確立され、行、範囲、ページ、またはテーブルが必要に応じて保護されます。ロックの種類に関する詳細については、SQL Server Books Online のロックの種類に関する項に記載されています。

より詳細に例を見ると、LazyWriter や CheckPoint プロセスが実行されるときにどのようなことが発生するかについて疑問が生じることがあります。SQL Server 7.0、SQL Server 2000、および SQL Server 2005 では、ダーティかつ固定されたページに関連付けられたトランザクション ログ レコードに対して、すべての適切な安定記憶へのフラッシュが発行されます。このことにより、WAL プロトコルは、関連付けられたトランザクション ログ レコードがフラッシュされるまでは、安定記憶にデータ ページが書き込まれないことを保証します。

SQL Server と安定記憶

SQL Server 7.0、SQL Server 2000、および SQL Server 2005 では、ディスク セクタのサイズ (一般的には 512 バイト) の情報を含めることで、ログとデータ ページ操作を拡張しています。

トランザクションの ACID 特性を維持するには、SQL Server によって障害ポイントが報告される必要があります。障害時、多くのディスク ドライブの仕様では、セクタ書き込み動作を部分的にだけ保証しています。ほとんどの仕様では、障害発生時には単一セクタ書き込みの完全性が保証されています。

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

torn page detection

次の項は、SQL Server 7.0 Books Online で torn page detection について説明している部分からの引用です。
このオプションを使用すると、電源障害やその他のシステムの停止によって発生した不完全な I/O 操作を SQL Server が検出できます。このオプションを TRUE に設定すると、8 KB のデータベース ページをディスクに書き込むとき、ページ内の 512 バイト セクタごとに 1 ビットがフリップされます。後で SQL Server がページを読み取ったときにビットが誤っている場合は、ページが誤って書き込まれたことを意味し、破損したページが検出されます。正しく書き込まれていないページは復旧によって読み取られることが多いので、通常は復旧の際に破損したページが検出されます。

SQL Server のデータベース ページは 8 KB ですが、ディスクは 512 バイト セクタを使用して I/O 操作を実行します。したがって、1 データベース ページあたり 16 個のセクタが書き込まれます。オペレーティング システムが最初の 512 バイト セクタをディスクに書き込んだときから 8 KB の I/O 操作が完了するまでの間に、電源障害などのシステム障害が発生した場合に、破損したページが発生します。障害が発生する前にデータベース ページの最初のセクタの書き込みが成功している場合は、ディスク上のデータベース ページが更新されたかのように見えますが、実際には成功していないこともあります。

バッテリ付きディスク キャッシュを使用すれば、ディスクへのデータの書き込みが完了したか、まったく書き込まれていないかのどちらかになります。バッテリ付きディスク キャッシュを使用する場合は、torn page detection オプションを TRUE に設定しないでください。
: torn page detection オプションは、SQL Server 7.0 のデフォルトでは有効ではありません。現在のシステムでこのオプションを有効にする方法については、SQL Server 7.0 Books Online の「sp_dboption」を参照してください。

ログ パリティ

ログ パリティ チェックは、torn page detection に非常に似ています。512 バイト セクタにはそれぞれパリティ ビットが含まれています。このパリティ ビットは、常にログ レコードに書き込まれ、ログ レコードの取得時に評価されます。512 バイト境界での強制ログ書き込みにより、SQL Server 7.0、SQL Server 2000、および SQL Server 2005 ではコミット操作が物理的なディスク セクタに完全に書き込まれることが保証されます。

この変更により、以前の SQL Server のバージョンよりもデータ一貫性が向上します。

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

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

性能に及ぼすインパクト

すべてのバージョンの SQL Server で、ログおよびデータ ファイルは CreateFile を使用して開かれます。SQL Server によって開かれた場合は、dwFlagsAndAttributes メンバには FILE_FLAG_WRITE_THROUGH オプションが入ります。
FILE_FLAG_WRITE_THROUGH
システムに対して中間キャッシュをスルーしてディスクに直接書き込むよう指示します。その場合でもシステムはキャッシュ書き込み操作を行うことができますが、レイジーでフラッシュすることはできません。

FILE_FLAG_WRITE_THROUGH オプションは、書き込み操作が正常終了を返した場合にはデータが正常に安定記憶に保存されていることを保証します。これは、WAL プロトコルと合わせてデータを保証するものです。
多くのディスク ドライブ (SCSI や IDE) には、512 KB、1 MB、またはそれ以上のオンボード キャッシュが搭載されています。しかし、ドライブ キャッシュは通常コンデンサに依存し、バッテリによりバックアップされているものではありません。このようなキャッシュ メカニズムでは、電源などの障害の際の書き込みは保証されず、セクタ書き込み操作の完全性のみが保証されます。これが、破損書き込みとログ パリティ検出が SQL Server 7.0、SQL Server 2000、および SQL Server 2005 に組み込まれた大きな理由です。ドライブのサイズが大きくなるにつれ、キャッシュも大きくなってきました。そのため、障害が起こると大量のデータを失う可能性があります。

バッテリ付きディスク コントローラは多数のハードウェア ベンダから発売されています。これらのコントローラのキャッシュはデータを数日間維持し、その間にキャッシュのハードウェアを別のコンピュータに移すこともできます。電源が正常に復旧したら、以降のデータ アクセスが許可される前に、未書き込みのデータは完全にフラッシュされます。多くのディスク コントローラでは、最適な性能を得られるように、読み取りと書き込みのキャッシュの割合を設定できます。大容量メモリを搭載しているものもあります。実際、(きわめて限定された市場の領域では) 6 GB のキャッシュを持つハイエンドのバッテリ付きディスク キャッシュ コントローラ システムを発売しているハードウェア ベンダもあります。このような製品を使用することにより、データベースの性能を著しく向上させることができます。

最新のキャッシュ実装では、システム リセット、電源障害、またはその他の障害が発生した際の再書き込みを実現しているため、コントローラ キャッシュを無効にせずに FILE_FLAG_WRITE_THROUGH 要求を処理します。

キャッシュを使用せずに I/O 転送を行うと、機械的にかかる時間 (ドライブのヘッド移動、回転数、およびその他の制限) のために、転送速度が著しく低下する可能性があります。

セクタ順序付け

セクタ順序付けは、I/O 性能を向上させる一般的な手法です。機械的なヘッドの移動を避けるために、なるべく同一方向のヘッドの動きでデータを取り出したり保存したりできるように読み取り/書き込みの要求が並べ替えられます。

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

書き込みキャッシュが介在する場合、データはまだ揮発性記憶にあると考えられます。しかし、SQL Server が状況を把握する方法である Win32 API の WriteFile を呼び出すと、成功のリターン コードが返されます。WriteFile API 呼び出しを使用する SQL Server やその他のプロセスからは、データが正しく安定記憶に書き込まれたかどうかは、推測する以外に方法がありません。

説明のために、ここではデータ ページのすべてのセクタが、合致するログ レコードのセクタの前に書き込まれるように並んでいると仮定します。これは、この時点で既に WAL プロトコルに違反しています。キャッシュはログ レコードより前にデータ ページを書き込みます。キャッシュが完全にバッテリによってバックアップされていない場合、障害が発生すると致命的な結果がもたらされる可能性があります。

データベース サーバーに対する性能の最適化要素を評価する際には、考慮すべき要素が多数あります。まず最初に考慮すべき点は、"使用するシステムで FILE_FLAG_WRITE_THROUGH 機能を有効にできるかどうか" ということです。

: 使用するキャッシュは、バッテリによって完全にバックアップされている必要があります。その他すべてのキャッシュ メカニズムでは、データ破壊やデータ喪失が発生する可能性があります。SQL Server は、FILE_FLAG_WRITE_THROUGH を有効にすることで、WAL を保証しようとします。

テストの結果、多くのディスク ドライブの構成には、バッテリによって適切にバックアップされていない書き込みキャッシュが搭載されていることがわかりました。SCSI、IDE、および EIDE ドライブは、書き込みキャッシュを全面的に利用しています。

多くのハードウェア構成では、IDE や EIDE ドライブの書き込みキャッシュを適切に無効にするには、特定の製造元のユーティリティを使用するか、または、ドライブ上にあるジャンパを使用する以外に方法がありません。ドライブの書き込みキャッシュが無効になっていることを確認するには、ドライブの製造元に問い合わせてください。

また、SCSI ドライブでは書き込みキャッシュが使用されています。これらのキャッシュは通常オペレーティング システムで無効にすることが可能です。疑問点がある場合は、そのユーティリティのドライブ製造元に問い合わせてください。

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

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

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

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

データ保護に使用される一般的な手法で、データ操作中に不良セクタを検出します。次の説明は、同じ大手の IDE ドライブ製造元の Web サイトから引用したものです。
この機能は、書き込みキャッシュの一部で、遅延書き込み操作中にデータが失われる危険性を減少させるためのものです。ディスク書き込み処理の間にディスク エラーが起こった場合、ディスクのタスクは停止し、損傷した疑いのあるセクタはドライブの最後にある代替セクタのプールに再割り当てされます。再割り当ての後、ディスクの書き込みタスクは最後まで継続されます。
これは、バッテリのバックアップがキャッシュに用意されている場合、再起動後に適切な変更が行える非常に強力な機能です。ディスク エラーが検出されることは望ましいことですが、WAL プロトコルのデータ セキュリティでは、これを遅延処理ではなくリアル タイムで実行することが要求されます。WAL パラメータ内では、AWR の手法を使用した場合、セクタ エラーによる (ドライブがいっぱいの場合ではなく) ログの書き込みエラーが発生した状態を検出できません。トランザクションを正しく中止し、管理者に対して警告を発行し、データを保護するために適切な手順が取られ、メディアのエラー状態を修正できるようにするためには、データベース エンジンはエラーを即座に検出できる必要があります。

データの安全性

データの安全性を保証するために、データベース管理者は以下の点に注意します。
  • 致命的なエラーから回復するために必要なバックアップが十分に行われているかどうかを確認しておくことが重要です。記憶装置をサイト外に配置するなどの適切な対策を実施します。
  • データベースの復元操作のテストを行うか、定期的にデータベースのテストを行います。
  • すべてのキャッシュ デバイスがあらゆる障害状態 (電源障害、不良セクタ、ドライブ不良、システム停止、ロックアップ、電源でのスパイクなど) を処理できることを確認します。
  • 使用しているキャッシュ デバイスで次の点を確認します。
    • バッテリ バックアップが内蔵されていること
    • 電源投入時に書き込みを再発行できること
    • 必要に応じてキャッシュを完全に無効にできること
    • 不良セクタの再マップをリアルタイムに処理できること
  • torn page detection を有効にします。これにより、多少性能に影響が生じます。
  • 可能であれば RAID デバイスの環境設定を行い、故障したディスク ドライブのホット スワップを実行できるようにします。
  • OS を再起動せずにディスク領域を追加できる、新しいキャッシュ コントローラを使用します。これが理想的な解決策になることもあります。

ドライブのテスト

データの安全性を完全なものにするには、すべてのデータのキャッシュが適切に処理されなければなりません。多くの場合、これはディスク ドライブの書き込みキャッシュを無効にする必要があることを意味します。

: さまざまな種類の障害が代替キャッシュ メカニズムによって正しく処理されることを確認する必要があります。

マイクロソフトでは、SQLIOStress ユーティリティを使用して複数の SCSI と IDE ドライブのテストを行ってきました。このユーティリティは、シミュレート対象のデータ デバイスとログ デバイスに対して高負荷の非同期の読み取り/書き込み動作をシミュレートします。テストでの性能統計値では、書き込みキャッシュが無効で 5,200 〜 7,200 RPM クラスのドライブの場合、平均の 1 秒あたりの書き込み回数は 50 〜 70 となりました。

SQLIOStress ユーティリティの関連情報および詳細については、「サポート技術情報」 (Microsoft Knowledge Base) の次の資料を参照してください。
231619 SQLIOStress ユーティリティを使用して SQL Server などのディスク サブシステムに負荷をかける方法
多くの PC 製造元 (Compaq、Dell、Gateway、HP など) は、書き込みキャッシュを無効にしたドライブを使用していますが、テストの結果が示すとおり、必ずしも書き込みキャッシュが無効になっているとは限りません。このため、常に完全なテストを行う必要があります。

データ デバイス

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

データ ページは、LazyWriter または CheckPoint プロセスがデータ ページを安定記憶にフラッシュするまでキャッシュに残ります。WAL プロトコルを使用して確実にログ レコードを正しく保存すると、復旧操作によって確実にデータ ページを既知の状態に復旧できます。

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

性能向上

"キャッシュ付きの IDE ドライブを使用しているが、キャッシュを無効にすると性能が思ったより顕著に低下する" という疑問が最初に生じます。

マイクロソフトでテストした多くの IDE ドライブは 5,200 RPM で動作しており、SCSI ドライブの多くは 7,200 RPM で動作しています。IDE ドライブの書き込みキャッシュを無効にすると機械的な性能がドライブの性能を左右するようになります。

"トランザクション レート" を比較することにより、性能の違いをきわめて明確に表すことができます。

オンライン トランザクション処理 (OLTP) では高いトランザクション レートが要求されることが多く、このようなシステムでは、書き込みキャッシュを適切にサポートし、データ整合性を確保しながら性能を向上させられるキャッシュ コントローラの使用が想定されています。

キャッシュ付きドライブでの SQL Server の性能の変化を顕著に表すために、小さなトランザクションを使用してトランザクション レートを増加させました。

テスト結果から、512 KB 未満または 2 MB を超えるバッファで高頻度の書き込み動作を行うと性能が低下することがわかります。
以下の例を考慮します。
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT 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 秒
一連の INSERT 操作をすべて単一のトランザクション中に含めると、全体は約 4 秒で実行されます。

その理由は、必要とされるログのフラッシュ回数にあります。このトランザクションなしの場合は、それぞれの INSERT が 1 つのトランザクションとなり、トランザクションに対して毎回ログ レコードがフラッシュされる必要があります。各フラッシュは 512 バイトであり、ドライブへの機械的な書き込み要求が著しく発生します。

単一のトランザクションを使用すると、トランザクションに対するログ レコードはまとめられます。まとまったログ レコードは、単一の大きなサイズの書き込みを使用してフラッシュされるため、機械的な干渉は著しく減少します。

警告 : トランザクション範囲を広げることは推奨しません。トランザクションを長時間実行すると、オーバーヘッドの増加に加えて、過度の不要なブロッキングが発生します。SQL Server 7.0、SQL Server 2000、および SQL Server 2005 のパフォーマンス カウンタ SQL Server:Databases を使用して、トランザクション ログ ベースのカウンタを表示してください。特に Log Bytes Flushed/sec で、多数の小さいトランザクションによって機械的なディスク使用率が非常に高くなっていることが示されます。

ログのフラッシュに関連付けられたステートメントを調べて、ログのフラッシュの回数を削減できるかどうかを判断します。上記の例では、単一のトランザクションが実装されていました。ただし、多くの事例では、単一のトランザクションが原因で好ましくないロッキング現象が発生します。トランザクションの設計を調べてください。次のようなバッチを実行することにより、おそらく頻繁で小さいサイズのログのフラッシュ回数を削減することができます。
BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
SQL Server 6.x では、高頻度の小さいトランザクション ログの書き込みと同様のパフォーマンスの影響が発生しない場合があります。SQL Server 6.x では、トランザクションがコミットされるときに、同じ 2 KB のログ ページを書き直します。これにより、SQL Server 7.0、SQL Server 2000、および SQL Server 2005 では 512 バイト セクタの境界を使用してフラッシュするのに比べて、ログのサイズを大幅に削減できます。ログ サイズの削減の度合いは、ドライブの機械的な動作の量に直接関連します。ただし、上記で説明したように、SQL Server 6.x のアルゴリズムでは、コミットされたトランザクションが失われる可能性があります。

プロパティ

文書番号: 230785 - 最終更新日: 2006年4月24日 - リビジョン: 5.2
この資料は以下の製品について記述したものです。
  • 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
キーワード:?
kbhowto kbinfo KB230785
"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