web-dev-qa-db-ja.com

大規模な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が高いために他のパフォーマンスの問題が発生する可能性があります) ですが、何がコミットされるかを保証できるかわかりませんない。

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

8
casperOne

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

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

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

参考文献:

7
Simon Righarts

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

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

バックアップが復元されると、データとログはそのまま再構成され(データページが不整合な状態にあることに注意してください)、バックアップされたトランザクションログの先頭からredoプロセスが発生します(繰り返しになりますが、完全バックアップの内部)、最後まで。次に、RECOVERYを使用して復元した場合、バックアップが終了した時点で、コミットされていないトランザクションをロールバックするためにndoが発生します。 ndo操作は、データベースをトランザクションの一貫性のある状態にして、使用できる状態にします。 NORECOVERYを使用して復元するとndoプロセスがスキップされ、追加のバックアップ(差分またはトランザクションログ)を復元できます。

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

4
Jon Seigel