バックアップの内部-SQL Serverのロックとパフォーマンスのオーバーヘッドに関して、バックアップジョブの実行中に何が起こりますか？

Question

MySQLの場合、SQLステートメントでデータベースがテーブルごとにバックアップされることを知っています。これによりロックが発生し、バックアップ中に列を更新すると、整合性の問題が発生する可能性があります。

私の理解では、これはMicrosoft SQL Serverには当てはまりませんが、SQL Serverはこれをどのように処理しますか？データベースの整合性を保つために内部凍結はありますか？

また、単一のファイルにバックアップする場合、バックアップはシングルスレッドであり、コアを1つだけ使用することを聞いたことがあります。また、マルチコアマシン、たとえば16コア、または少なくとも1つよりもかなり大きな数のマシンがあると仮定します。

私の個人的な経験から、バックアップをとるときに問題はなく、ロックやオーバーヘッドの問題もありませんでしたが、私の経験は限られています。そのため、サーバーのプロパティで常にバックアップの圧縮をオンにすることをお勧めします。

では、バックアップジョブが実行されているとどうなりますか？また、バージョンごとに大きな違いはありますか？たとえば、2008、2012、2014（ライセンスではありません）。

Kin Shah · Accepted Answer

すべてのポイントはバックアップの神話-Paul Randalによるでカバーされています。

30-01）バックアップ操作によりブロッキングが発生する

いいえ。バックアップ操作は、ユーザーオブジェクトをロックしません。バックアップはI/Oサブシステムで非常に重い読み込み負荷を引き起こすため、ワークロードがブロックされているように見えるように見えるかもしれませんが、実際はそうではありません。減速しているだけです。一括ログに記録されたエクステントを取得する必要があるバックアップがファイルロックを取得する特殊なケースがあり、チェックポイント操作をブロックする可能性がありますが、DMLはブロックされません。

また、単一のファイルにバックアップする場合、バックアップはシングルスレッドであり、コアを1つだけ使用することを聞いたことがあります。

単一のファイルまたはデバイスへのバックアップは、1つの書き込みスレッドを使用します。そのため、複数のファイル/デバイス（複数の.bakファイルであること）にバックアップする場合は、ファイル/デバイスごとに1つのライタースレッドがあります。

バックアップパフォーマンスを改善する最も簡単な方法は、バックアップ操作を並列化できるようにすることです。これは、バックアップストライピングと呼ばれます。デフォルトでは、読み取られるドライブ文字またはマウントポイントごとに1つのデータリーダースレッドがあり、書き込まれるバックアップデバイスごとに1つのデータライタースレッドがあります。

小切手

Shanky · Answer

Paulが書いたバックアップの内部に関する記事はすばらしいものであり、必ず読んでください。他の人が言ったことに加えて、質問の特定の部分を強調します

また、単一のファイルにバックアップする場合、バックアップはシングルスレッドであり、コアが1つだけ使用されると聞きました。また、マルチコアマシン、たとえば16コア、または少なくとも1つよりもかなり大きな数のマシンがあると仮定します。

バックアップ操作can use parallelismですが、これはではないことを覚えておいてください並列化はSQL Serverのオプティマイザによって駆動され、バックアップが必要な場所から関与するディスクの数によって駆動されますデータファイルを読み取り、backupがデータファイルと作成されたバックアップファイルの量を書き込む場所。

SQL Serverのバックアップ中にMAXDOPヒントを使用することはできません

単純なTSQLバックアップ操作のSSMSで実行プランを生成することはできません。

SQL Serverのクエリオプティマイザーによって駆動される並列処理は、基本的に関与するオペレーター向けです（実際にはより複雑ですが、簡単にするためにこれを使用できます）。バックアップ操作にはオペレーターが含まれないため、オプティマイザーによって駆動される並列処理は使用できません。

Technet Wikiでバックアップと並列処理についての記事を書きました。ここでは、簡単な例を使用して、SQL Serverバックアップ中の並列処理について説明しました。以下は結論です

データベースファイルが複数のディスク上にある場合、バックアップ操作はデバイスドライブごとのスレッドで開始され、データを読み取ります。同様に、複数のドライブ/マウントポイントで復元が行われた場合、バックアップ操作により、ドライブ/マウントポイントごとに1つのスレッドが開始されます。
同じドライブにバックアップの複数のコピーをダンプする場合でも、バックアップファイルごとに1つのスレッドがダンプされます。
バックアップに関連する並列処理は、ストライプに関連しています。各ストライプは独自のワーカースレッドを取得します。これが、バックアップ/復元の唯一の部分であり、並列処理として検討する必要があります。
最大並列度は、バックアップ操作には影響しません。

私はこれについてポールとボブ・ドールからいくつかの専門家の意見を得ました。

では、バックアップジョブが実行されているとどうなりますか？また、バージョンごとに大きな違いはありますか？たとえば、2008、2012、2014（ライセンスではありません）。

ボブ・ドーアによるこのblog.msdnの記事を読むことをお勧めします。彼が強調したいくつかの重要な点は

バックアップが開始すると、一連のバッファーが作成され、バッファープールの外部のメモリから割り当てられます。ターゲットは通常、各バッファーにつき4MBであり、約4から8バッファーになります。計算の詳細は次の場所にあります： http://support.Microsoft.com/kb/904804/en-us
バッファは空きキューとデータキューの間で移行されます。リーダーは空きバッファをプルし、データを入れてデータキューに配置します。ライタは、データキューからデータバッファをプルし、バッファを処理して空きリストに戻します。
バックアップデバイスごとにライターを取得し、それぞれがデータキューから取得します。したがって、ディスクへの指定が4（4）のバックアップコマンドには、4つのライターと1つのリーダーがあります。リーダーは非同期I/Oを使用するため、ライターに対応できます。

trace flags 3213 and 3605を有効にできます。どちらも文書化されていないため、テスト環境で使用して、SQL Serverエラーログにダンプされた興味深いメッセージを確認してください。以下のようなものが表示されます

Memory limit: 249MB BufferCount: 7 Sets Of Buffers: 1 MaxTransferSize: 1024 KB Min MaxTransferSize: 64 KB Total buffer space: 7 MB Tabular data device count: 1 Fulltext data device count: 0 Filestream device count: 0 TXF device count: 0 Filesystem i/o alignment: 512 Media Buffer count: 7 Media Buffer size: 1024KB

さまざまなバージョンのバックアップコードの大幅な変更については知りません。そのようなことは文書化されていません。 TSQLまたはSMOを使用してSQL ServerからWindows Azure Blobストレージサービスからバックアップと復元を有効にするSQL Server 2012 SP1 Cumulative Update 2,で導入された拡張機能についてのみ知っています。読むここ

usr · Answer

基本的に、SQL Serverはディスク上のすべてのページのダーティーコピーを実行します。並行アクティビティがある場合、または以前にチェックポイントされていないアクティビティがあった場合、これらのページは一貫性がない可能性があります。

次に、SQL Serverは、古くなったページを最新バージョンにして、復元時にすべてを一貫させるために必要なトランザクションログの必要な部分もコピーします。

バックアップ操作のマルチスレッド化について話すことはできません。並列化されることを期待しています。他にどのようにして10GB /秒の10TBデータベースをバックアップできますかIOサブシステム？