web-dev-qa-db-ja.com

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]


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

      SQL Server 2008 R2および2012での私のテスト、およびSQL Server 2014に関するユーザーコメント [8]、乗数が_4_であることを示します。つまり、GetSuggestedIoDepth（直下）の値が報告された場合、

      • GetSuggestedIoDepthは_4_になりました、または
      • 乗数は_GetSuggestedIoDepth + 1_になりました
    • GetSuggestedIoDepthはDISKデバイスに対して_3_を返します [9]
    • ハードセットの最大値はありませんが、必要なメモリ=（BUFFERCOUNT * MAXTRANSFERSIZE）とすると、実際の最大値は次のようになります：BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
  • MAXTRANSFERSIZE：
    • 可能な値は、最大4194304バイト（4 MB）の範囲の65536バイト（64 KB）の倍数です。 [1]
    • デフォルト値：デバイスが読み取りモード（復元）の場合、またはこれがデスクトップまたはエクスプレスエディションの場合は64Kを使用し、それ以外の場合は1 MBを使用します。 [9]
  • 一般/その他：
    • 使用できる最大サイズは（Buffer Pool’s To Physical Memory/16）です。 GlobalMemoryStatusEx （ullTotalPhys）API呼び出しから返されます。 [9]
    • トレースフラグ_3213_は、バックアップ/復元操作の実行中にバックアップ/復元構成パラメーターを出力し、_3605_はに出力をダンプします[〜＃〜]エラーログ[〜＃〜] ファイル：DBCC TRACEON (3213, 3605, -1);
    • _DISK = N'NUL:'_（UNIXではDOS/Windowsの_/dev/null_に相当）を使用して、いくつかのメトリックを簡単にテストできます（ただし、書き込みI/Oをスキップしているため、合計処理時間を正確に把握できません） ）

リソース

  1. T-SQLのMSDNページ [〜＃〜] backup [〜＃〜] コマンド
  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アプリケーション。したがって、ユーザーがいつでもオンになる可能性がありますが、現実的には、ユーザーはすべて米国ベースです（今のところ）ほとんど「標準」時間で働く傾向があります：午前7時太平洋（つまり東部午前10時）から7 PM太平洋（つまり10 PM東部）） 、しかし月曜日から金曜日だけではなく、週7日ですが、週末の負荷は少し軽くなります。

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

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

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

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

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

sql-serverbackupbest-practicesmaintenance
34
Solomon Rutzky

質問で大量のアイテムに対処しました。本当にありがとうございました！

私がすぐに気付いたいくつかのこと：

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

24時間年中無休のインスタンスを実行していますか？ 24時間の負荷はどのくらいですか？バックアップ圧縮が無効になっていることに気づきました。それはテストのための設計によるものですか、またはこれを本番環境に置くときに何らかの理由でオフにすることが望ましいですか？大量のハードウェアヘッドルーム（CPU/RAM）があり、バックアップを最短時間で完了することが最も重要な場合は、その目標を念頭に置いて、特定のハードウェアに合わせてこれらのパラメーターを調整する必要があります。 OLTPワークロードが24時間体制で処理され、バックアップがそれに影響を与えないようにしたい場合は、これらのパラメーターを逆に調整する必要がある可能性があります。一般的なガイダンスを求めているため、設計目標を特定しましたが、「それは次第」と賢明に述べています。

  • これらの値のいずれもオーバーライドしてはならない状況はありますか？

インスタンスを維持しなくなった後のサポートの可能性について懸念があり、交換の機能が不確かな場合は、デフォルト設定を保持することをお勧めします。特に調整する必要がない限り、デフォルトをそのままにしておくことをお勧めします。彼らが言うように、眠っている犬を嘘をつきましょう。

  • すぐにはわからないものを上書きすることの落とし穴はありますか？メモリやディスクI/Oを使いすぎていますか？復元操作は複雑ですか？

参照するドキュメントに明確に記載されているように、これらのパラメータを上げすぎると、稼働時間に悪影響が及ぶ可能性があります。本番ベースのすべてのものと同様に、デプロイする前にこれを徹底的にテストし、どうしても必要な場合を除いて、設定はそのままにしておく必要があります。

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

RAM予期せぬ状況に備えて、十分に残しておくことをお勧めします。使用可能なRAMの60％以上または70％以上を使用することは確かに心配ですバックアップ操作については、バックアップウィンドウの間に他に何も起こらないことを100％確実に知っている場合を除きます。

SQLServerScience.com で、バックアップパフォーマンステストの方法を示すいくつかのコードを含むブログ投稿を書きました。

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

12
Max Vernon