BACKUPコマンドのBUFFERCOUNT、BLOCKSIZE、およびMAXTRANSFERSIZEの設定

私を探しています実用的に値を設定するためのガイダンスBUFFERCOUNT、BLOCKSIZEおよび、MAXTRANSFERSIZEのBACKUPコマンド。私は少し調査を行い（以下を参照）、少しテストを行いました。本当に価値のある答えは「まあ、それは...」で始まることを十分に認識しています。私が行ったテストと私が見つけたリソースのいずれかに示されているテスト（以下の方法を参照）に対する私の懸念は、テストが真空で行われることです。ほとんどの場合、他の負荷のないシステムで行われます。

長期的な経験に基づいたこれらの3つのオプションに関する適切なガイダンス/ベストプラクティスに興味があります：数週間または数か月にわたる多くのデータポイント。そして、特定の値を探しているわけではありません。それはほとんどが利用可能なハードウェアの機能だからです

• さまざまなハードウェア/負荷要因が、実行すべき内容にどのように影響するか。
• これらの値がどれもオーバーライドされるべきではない状況はありますか？
• すぐに明らかではないこれらのいずれかをオーバーライドするための落とし穴はありますか？メモリーやディスクI / Oを使いすぎていますか？復元操作を複雑にしますか？
• SQL Serverの複数のインスタンス（既定のインスタンスと2つの名前付きインスタンス）を実行しているサーバーがあり、3つのインスタンスすべてのバックアップを同時に実行すると、集合（BUFFERCOUNT* MAXTRANSFERSIZE）使用可能なRAMを超えていませんか？可能なI / O競合？
• 1つのサーバーで3つのインスタンスを使用し、3つすべてのバックアップを同時に同時に実行する同じシナリオで、各インスタンス内で複数のデータベースのバックアップを同時に実行すると、これらの値の設定にどのように影響しますか？つまり、3つのインスタンスのそれぞれに100個のデータベースがあり、各インスタンスごとに2つまたは3つのバックアップを同時に実行し、6から9のバックアップが同時に実行される場合。（この状況では、いくつかの大きなデータベースではなく、多くの中小規模のデータベースがあります。）

これまでに収集したもの：

• BLOCKSIZE：

  • サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および65536（64 KB）バイトです。^[1]
  • デフォルトは、テープデバイスの場合は65536、それ以外の場合は512です^[1]
  • CD-ROMへのコピーおよびCD-ROMからの復元を計画しているバックアップを作成する場合は、BLOCKSIZE = 2048 ^[1]を指定します
  • 単一のディスクに書き込む場合、デフォルトの512で十分です。RAIDアレイまたはSANを使用する場合は、デフォルトまたは65536のどちらが優れているかをテストする必要があります。^{[13（18ページ）]}

  • 手動で設定する場合、値はデータファイルの作成に使用されるブロックサイズ以上でなければなりません。そうでない場合、次のエラーが表示されます。

    メッセージ3272、レベル16、状態0、行3
    'C：\ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak'デバイスのハードウェアセクターサイズは4096ですが、ブロックサイズパラメーターは互換性のない512のオーバーライド値。互換性のあるブロックサイズを使用してステートメントを再発行します。

• BUFFERCOUNT：

  • デフォルト^[2]、[8]：

    SQL Server 2005以降のバージョン：
    （NumberofBackupDevices * [mystery_multiplier]）+ NumberofBackupDevices +（2 * NumberofVolumesInvolved）

  • [mystery_multiplier]：この値に関していくつかの矛盾があります。私はそれが3つの形式で表現されているのを見ました：

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    3SQL Server 2005 SP2 ^[9]で乗数が必要であることを示すテストが行われました。

    SQL Server 2008 R2および2012でのテスト、およびSQL Server 2014に関するユーザーコメント^[8]は、乗数がであることを示しています4。意味GetSuggestedIoDepth（以下のいずれかに報告された値が与えられた場合）：

    • GetSuggestedIoDepth現在4、または
    • 乗数は今 GetSuggestedIoDepth + 1
  • GetSuggestedIoDepth3DISKデバイスの返品^[9]
  • ハードセットされた最大値はありませんが、必要なメモリ=（BUFFERCOUNT* MAXTRANSFERSIZE）を考えると、実際の最大値は次のようになります。 BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE：
  • 可能な値は、最大4194304バイト（4 MB）の範囲の65536バイト（64 KB）の倍数です。^[1]
  • デフォルト値：デバイスが読み取りモード（復元）の場合、またはこれがDesktopまたはExpress Editionで64Kを使用する場合、1 MBを使用します。^[9]
• 一般/その他：
  • 使用できる最大サイズは（バッファプールの物理メモリ/ 16）です。GlobalMemoryStatusEx（ullTotalPhys）API呼び出しから返されたとおり。^[9]
  • トレースフラグは3213、バックアップ/復元操作の実行中にバックアップ/復元構成パラメーターを3605出力し、ERRORLOGファイルに出力をダンプします。DBCC TRACEON (3213, 3605, -1);
  • DISK = N'NUL:'（DOS /dev/nullでUNIXに相当するWindows ）を使用して、一部のメトリックのテストを簡単に行うことができます（ただし、書き込みI / Oをスキップしているため、合計プロセス時間を把握できません）。

資源

1. T-SQL BACKUPコマンドのMSDNページ
2. KB904804：SQL Server 2000でデータベースをバックアップするとパフォーマンスが低下する
3. SQL Serverバックアップのパフォーマンスを向上させるオプション
4. バックアップと復元
5. SQL Serverのバックアップと復元の最適化
6. バックアップパフォーマンスの最適化
7. 圧縮およびソリッドステートディスクを使用してSQLデータベースの完全バックアップの速度を上げる方法
8. 不適切なBufferCountデータ転送オプションは、OOM状態につながる可能性があります
9. 仕組み：SQL Serverのバックアップと復元はどのように転送サイズを選択しますか
10. 仕組み：SQL Serverバックアップバッファー交換（VDIフォーカス）
11. SQLバックアップによる大規模データベースのチューニング
12. バックアップバッファー用のSQL Serverメモリ
13. ケーススタディ：ネットワークを介したVLDBの高速で信頼性の高いバックアップと復元（.docxファイル）
14. バックアップパフォーマンスを向上させるために、バックアップデバイスをいくつ推奨しますか？

私はテストしました：

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

更新

質問に答えるときにいつも他の人に提供するように頼んでいる情報の一部を追加するのを忘れることがあるようです;-)。私は現在の状況に関して上記の情報を提供しましたが、詳細を提供できます。

私は24/7 / 365.25 SaaSアプリケーションを提供するクライアントで働いています。そのため、ユーザーはいつでもアクセスできる可能性がありますが、現実的には、ユーザーはすべて米国に拠点を置き（現時点では）、ほとんど「標準」時間で作業する傾向があります。 （つまり、東部標準時の午後10時）、ただし月曜日から金曜日だけでなく、週末の負荷は少し軽くなりますが、週7日です。

各クライアントが独自のDBを持つように設定されています。ニッチな業界なので、数万（またはそれ以上）の潜在的なクライアントはいません。クライアントDBの数はインスタンスごとに異なり、最大のインスタンスは206クライアントを保持します。最大のDBは約です。8 GBですが、1 GBを超えるデータベースは約30のみです。したがって、私は特にVLDBのパフォーマンスを最大化しようとはしていません。

このクライアントで始めたとき、それらのバックアップは常に1日1回フルで、LOGバックアップはありませんでした。また、MAXTRANSFERSIZEを4 MBに、BUFFERCOUNTを50に設定しました。そのセットアップを、Ola Hallengrenのデータベースバックアップスクリプトのわずかにカスタマイズされたバージョンに置き換えました。少しカスタマイズされた部分は、各インスタンスに接続するときに動的にDBを検出し、インスタンスごとに調整できるようにするマルチスレッドツール（私が書いてすぐに販売を開始する予定です）から実行されることです（したがって、現在実行しています3つのインスタンスを同時に実行しますが、各インスタンスごとにDBを順番に実行します。これらを同時に実行することの影響がわからないためです。

これで、1週間に1日フルバックアップを行い、他の日にはDIFFバックアップを行うようになりました。LOGバックアップは10分ごとに取得されます。ここで問い合わせている3つのオプションにはデフォルト値を使用しています。しかし、それらがどのように設定されているかを知って、私は最適化を元に戻していないことを確認したかった（古いシステムにいくつかの大きな欠陥があったからといって、すべてが間違っていました）。現在、206個のデータベースの場合、FULLバックアップ（約1週間に1回）には約62分かかり、残りの日（FULL後の初日には7分、前日には20分）のDIFFバックアップに7分から20分かかります次のFULL）。そして、それはそれらを順番に実行しています（シングルスレッド）。LOGバックアッププロセスの合計（3つのインスタンスすべてのすべてのDB）は、毎回（再び、10分ごとに）50〜90秒かかります。

DBごとに複数のファイルを実行できることを理解していますが、a）DBのマルチスレッド化と中小規模のサイズがどれほど優れているか、b）復元プロセスを複雑にしたくない（b）単一のファイルを扱うことが望ましい理由はさまざまです）。

また、圧縮を有効にできることも認識しています（テストクエリでは意図的に無効になっています）。チームにそれを推奨していましたが、組み込みの圧縮がちょっと厄介であることに気付きました。古いプロセスの一部は、各ファイルをRARに圧縮することでした。独自のテストを行ったところ、RARバージョンはネイティブに圧縮されたバージョンよりも少なくとも 50％小さいことがわかりました。最初にネイティブ圧縮を使用してファイルを高速化してからRARを試しましたが、これらのファイルは、単にネイティブに圧縮されたものよりも小さいですが、RARのみの圧縮バージョンよりもまだ少し大きく、正当化するのに十分な違いがありましたネイティブ圧縮を使用していません。バックアップを圧縮するプロセスは非同期で、X分ごとに実行されます。.bakまたはを見つけた場合.trnファイル、それを圧縮します。このように、各ファイルの圧縮にかかる時間によってバックアッププロセスが遅くなることはありません。

質問で大量のアイテムに対処しました。徹底してくれてありがとう！

気付かないことがいくつかあります。

• さまざまなハードウェア/負荷要因が、実行すべき内容にどのように影響するか。

24時間365日のインスタンスを実行していますか？24時間の負荷はどれくらいですか？バックアップの圧縮が無効になっています。それはテスト用の設計によるものですか、それとも何らかの理由でこれを本番に移行するときにオフにすることが望ましいですか？大量のハードウェアヘッドルーム（CPU / RAM）があり、最短時間でバックアップを完了することが非常に重要な場合は、その目標を念頭に置いて、特定のハードウェアに合わせてこれらのパラメーターを調整する必要があります。OLTPワークロードが24時間対応であり、バックアップがそれに影響を与えないようにする場合は、これらのパラメーターを他の方法で調整する必要があります。ただし、一般的なガイダンスを求めているため、「目標に依存している」と賢明に述べているため、設計目標を特定していません。

• これらの値がどれもオーバーライドされるべきではない状況はありますか？

インスタンスをメンテナンスしなくなった後、将来のサポート可能性が懸念され、交換の能力が不確かな場合は、デフォルト設定を保持する必要があります。特に調整する必要がない限り、デフォルトをそのままにしておくことをお勧めします。彼らが言うように、眠っている犬を寝かせてください。

• すぐに明らかではないこれらのいずれかをオーバーライドするための落とし穴はありますか？メモリーやディスクI / Oを使いすぎていますか？復元操作を複雑にしますか？

参照するドキュメントに明確に記載されているように、これらのパラメーターを大きくしすぎると、確かにアップタイムに悪影響を与える可能性があります。実稼働ベースのすべてのものと同様に、展開する前にこれを徹底的にテストし、どうしても必要な場合以外は設定をそのままにしておく必要があります。

• SQL Serverの複数のインスタンス（既定のインスタンスと2つの名前付きインスタンス）を実行しているサーバーがあり、3つのインスタンスすべてのバックアップを同時に実行すると、集団（BUFFERCOUNT * MAXTRANSFERSIZE）は使用可能なRAMを超えていませんか？可能なI / O競合？

予期せぬ状況に備えて、十分なRAMを確保する必要があります。バックアップウィンドウ中に他に何も起こらないことを100％確信を持って知らない限り、バックアップ操作に 60％または70％を超えるRAM を使用することは確かに心配です。

SQLServerScience.comでバックアップパフォーマンステストを行う方法を示すコードを含むブログ投稿を作成しました。

^{これは私がこれまで書いた中で最良の答えではないかもしれませんが、The Great One™がかつて言ったように、「あなたが撮っていないショットの100％を逃します」}