バックアップ内部-SQL Serverのロックとパフォーマンスオーバーヘッドの観点から、バックアップジョブの実行中はどうなりますか？

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

私の理解では、これはMicrosoft SQL Serverには適用されませんが、SQL Serverはこれをどのように処理しますか？DBの一貫性を保つために内部フリーズがありますか？

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

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

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

あなたのすべてのポイントはバックアップ神話でカバーされています-ポール・ランダル

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

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

また、バックアップはシングルスレッドであり、単一のファイルにバックアップすることを想定して、1つのコアのみを使用することを聞きました。

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

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

小切手

1. SQL Server 2008 Microsoft認定マスター（MCM）対応ビデオ、特にBackup Internals。
2. バックアップの内部構造と、バックアップと復元のスループットを追跡する方法（パート1）-By：Jonathan Kehayias
3. バックアップの内部構造と、バックアップと復元のスループットを追跡する方法（パート2）-By：Jonathan Kehayias

バックアップ内部についてPaulが書いた記事は素晴らしいものであり、あなたはそれを読む必要があります。他の人が言ったことに追加し、あなたの質問の特定の部分を強調する

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

バックアップ操作ですcan use parallelismが、これはSQL Serverのオプティマイザーによる並列処理ではなく、バックアップがデータファイルを読み取る必要があるディスクの数と、バックアップがデータファイルを書き込む場所と作成されるバックアップファイルの量によって駆動される並列処理ではないことに注意してください。

MAXDOPSQL Serverバックアップの取得中はヒントを使用できません

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

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

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

1. データベースファイルが複数のディスクにある場合、デバイスドライブごとにスレッドでバックアップ操作が開始され、データが読み取られます。同様に、復元が複数のドライブ/マウントポイントで実行される場合、バックアップ操作はドライブ/マウントポイントごとに1つのスレッドを開始します

2. 同じドライブにバックアップの複数のコピーをダンプしている場合でも、バックアップファイルごとに1つのスレッドがダンプされます。

3. バックアップに関連する並列性はストライプに関連しています。各ストライプは独自のワーカースレッドを取得します。これは、実際には、並列操作と見なすべきバックアップ/復元の唯一の部分です。

4. 最大並列度は、バックアップ操作に影響しません。

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

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

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

1. バックアップが開始されると、バッファプールの外部のメモリから割り当てられた一連のバッファが作成されます。ターゲットは通常、各バッファーにつき4MBであり、約4〜8バッファーになります。計算の詳細は、http：//support.microsoft.com/kb/904804/en-usにあります。

2. バッファは、空きキューとデータキューの間で移行されます。リーダーは、空きバッファをプルし、データで満たし、データキューに配置します。ライターは、いっぱいになったデータバッファーをデータキューから引き出し、バッファーを処理して空きリストに返します。

3. バックアップデバイスごとにライターを取得し、それぞれがデータキューから取得します。したがって、ディスクへの4（4）仕様のバックアップコマンドには、4つのライターと1つのリーダーがあります。リーダーは非同期I / Oを使用するため、ライターに追いつくことができます。

を有効にすることができますtrace flags 3213 and 3605。両方ともドキュメント化されていないので、テスト環境で使用してください。SQLServerエラーログにダンプされる興味深いメッセージを確認してください。以下のようなものが表示されます

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

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

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

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

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