DBA

Background process can block restore of database

We can use database snapshots for the development of new databases or fine tunning complex upgrade scripts. All active connections must be closed before the database can be restored from a database snapshot. Closing of active connections manually via Activity Monitor isn’t an option that can be easily automated so we can use this simple batch to close all active connections in the given database before restore:

Most of the time it’s working perfectly but for some specific databases and only at some point in time we can see this exception to be fired:

The question is: Is there an active system SPID in our database? Let’s check it in the Activity Monitor or with the query below:

There is really one active system SPID running and it looks like to do some serious work based on cpu and physical_io columns. Where is this coming from?

Most probably our database has Change Tracking feature active on it and this system SPID is background task to maintain the history cleanup. We can check for it:

If we see one row listed there for our database then most probably the system SPID belongs to the Change Tracking cleanup job which is activated on our database and is blocking restore from the snapshot. You can read more about this in documentation. A similar situation we can expect for the Change Data Capture feature.

When Change Tracking doesn’t need to be active on our development database then the best option is to switch it off before snapshot creation:

If Change Tracking needs to active we can use the undocumented stored procedure sp_flush_commit_table_on_demand. There is more info about it at sirsql.net.

Leave a Reply

Your email address will not be published. Required fields are marked *