大規模なSQL Serverデータベースのバックアップ中にデータ更新操作を実行する

大規模な（数千万レコードの）データベースがあり、データベースの完全バックアップを実行します。

ただし、データベースは十分に大きいため、バックアップの実行前および実行中にトランザクションを開始できるだけでなく、バ​​ックアップの実行中および実行後にコミットすることもできます。

例えば：

T0 = Transaction A start
T1 = Full database backup start
T2 = Transaction B start (will not deadlock with A)
T3 = Transaction A commit/rollback (does not matter, does it?)
T4 = Full database backup end
T5 = Transaction B commit/rollback (again, does not matter, does it?)

T0          T1          T2          T3          T4          T6
||----------||----------||----------||----------||----------||---------->

私の理解では、バックアップ中にロックは使用されません（ただし、I / Oが高いために他のパフォーマンスの問題が発生する可能性があります）が、何がコミットされるかどうかは保証できません。

また、私の懸念は、データベースが一貫性のない状態になることではなく、その状態がどのようになるか（たとえそれが確定的ではなくても、一貫して適用できる一連のルールがある場合）と、そこに到達する方法（たとえば、バックアップファイルを作成するためにトランザクションログと一緒にどのくらいのデータファイルが使用されますか？

基本的に、バックアップは、バックアップのデータ読み取り部分が終了するとデータベースの状態になります（したがって、すべてのデータがバックアップされます）。さらに、トランザクションの一貫性を確保するために必要なトランザクションログの量（開始含まれるログの時間はMIN(most recent checkpoint time, oldest active transaction start time)）です。Paul Randalがここでこれをカバーします（図を使用して、すべてが非常に簡単になります）。あなたの例でAは、コミットされ（またはのROLLBACK TRANSACTION代わりにが発行された場合はロールバックされCOMMIT）、B（そのトランザクションの最終結果に関係なく）ロールバックされます。

（I / Oの競合を除いて、静かな時間にバックアップを実行しようとするもう1つの理由は、バックアップ中に生成されたすべてのトランザクションログを通常、バックアップに含める必要があるためです。）

データベースリストアのリカバリフェーズでは、バックアップに含まれるログからコミットされたすべてのトランザクションを取得してデータベースに適用し、コミットされていないすべてのトランザクションをロールバックします。（これがWITH RECOVERY/ WITH NORECOVERYが重要な理由です。WITH RECOVERYデータベースを使用することはできますが、それ以上のログバックアップを適用することはできませんWITH NORECOVERY。ログバックアップをロールインするには、データベースを復元する必要があります。リカバリでは、コミットされていないトランザクションをロールバックすることにより、ログチェーンが壊れます。 ）

参考文献：

• 30 SQL Serverバックアップの神話
• 完全バックアップに関するいくつかの神話を暴く
• SQL Serverでのログ記録と回復

フルバックアップでは、バックアップのデータ読み取り部分が完了した時点から、その時点でコミットされていないトランザクションを除いた時点に復元されます。

おっしゃったように、バックアップが行われている間、データベースはオンラインのままであり、書き込み可能です。これがどのように機能するかは、バックアップシステムが一貫性のないデータページのセットをバックアップすることです（データの読み取りにゼロ以外の時間がかかるため）-どのような状態であっても、各データページのコピーが取得されます。完全バックアップには、バックアップの開始時に最も古いアクティブなトランザクションの開始から始まり、データ読み取り部分が完了する最後のログレコードまでのトランザクションログレコードも含まれます。

バックアップが復元されると、データとログはそのまま再構成され（データページが不整合な状態にあることに注意してください）、バックアップされたトランザクションログの最初から（ここでもフルバックアップ内で）REDOプロセスが発生します。 、最後までずっと; 次に、を使用して復元した場合、バックアップが完了した時点でRECOVERY、取り消しが発生してコミットされていないトランザクションがロールバックされます。アンドゥ操作を使用できるようになり、トランザクション一貫性のある状態でデータベースを残しものです。を使用して復元するとNORECOVERY、元に戻すプロセスがスキップされ、追加のバックアップ（差分ログまたはトランザクションログ）を復元できます。

データベースが非常に大きく、書き込み作業負荷が大きい場合、現在割り当てられているスペースが不十分な場合、バックアップ中にトランザクションログが大きくなる可能性があることに注意してください。トランザクションログバックアップを実行している場合でも、フルバックアップにはログレコードが必要であるため、フルバックアップ中はログを（内部的に）クリアできません。完全バックアップの実行中にトランザクションログバックアップを実行している場合、ログの消去は完全バックアップが完了するまで自動的に延期されます。