Concurrent dump database and dump transaction Commands

SAP ASE allows you to run a dump transaction concurrently with a dump database command, reducing the risk of losing database updates for a longer period than that established by the dump policy.

dump database works in two phases: the first phase copies the database pages to the dump archive, and the second phase copies the active part of the transaction log to the dump archive. dump transaction uses a single phase when it copies the active part of the transaction log to the dump archive.

dump database allows a concurrent dump transaction when copying the database pages (the longest phase), but does not allow a concurrent dump transaction when it copies the active part of the transaction log. While copying the active part of the transaction log, dump transaction waits for the dump database to finish, or vice versa, before it starts.

Any dump transaction that occurs concurrently with dump database (that is, completes before dump database starts copying the active log), cannot be loaded on top of that database dump: the dump of the transaction log belongs to the preceding load sequence.

It may be difficult to determine whether a transaction log you dumped with dump tran precedes the database dump (in which case it need not be loaded), or occurs after the database dump (in which case it should be loaded). Use the dump history file to resolve questions of precedence by including the transaction log or not, as appropriate.

In this example, which shows a typical daily backup strategy and uses serialized dumps, a crash at 23:15 that occurs while a dump database is running means that you can restore the database only to the point it was at 21:00, and more than two hours worth of database updates are lost:

Image shows a series of dumps taken on the hour. The last full dump was at 22:00

However, because concurrent dumps allow you to continue dumping the transaction log while dump database is running, when the crash occurs at 23:15, you can restore the database to the condition it was in at 23:00 because of the transaction log dumps taken at 22:00 and at 23:00, and only 15 minutes of database updates are lost.

Image shows a series of dumps taken on the hour, every hour. The last dump was at 22:00, and there was a crash at 23:15. However, there were transaction log dumps taken at 22:00, 23:00, and 24:00.

Note: dump transaction does not truncate the transaction log while it is running concurrently with dump database.