We may recognize CHadrBuildSourceStateLimitConcurrentBackups (similar to value LIMIT_CONCURRENT_BACKUPS value from the hadr_automatic_seeding_state_transition event) what is a parameter to the function CallFunctAndResumeBuildTask(). So my second idea was to capture the stack dump from the windbg tool while running the seeding session and here what I was able to see: Indeed, we may also claim that anything else (excluding the seeding operation itself) could have trigger the load of the sqlvdi.dll. The above picture seems to confirm my assumption but this test is not perfect. So my first idea consisted in checking if the corresponding dll is loaded as module used by the sqlservr.exe process and the tasklist tool is a good candidate to answer to our need. How to check if SQL Server uses VDI during direct seeding operation? Well, we know that using VDI implies to use sqlvdi.dll. If SQL Server uses backup stream and VDI interface internally during seeding operation, it may explain why it has to limit concurrent backups in our case. Well, let’s continue with this other query SELECTĭo you notice the command text related to the direct seeding session? VDI_CLIENT_WORKER seems to indicate that SQL Server is using the virtual device interface internally during the seeding operation (VDI prefix as Virtual Device Interface).
So direct seeding as a streaming backup? Well that sounds good! We also recognize characteristic wait types that occur during a backup operation (ASYNC_IO_COMPLETION, BACKUPBUFFER). But the interesting part is that adding a database with direct seeding mode seems to be similar to performing a backup operation from a locking perspective. In short, my backup session is waiting on database object with a LCK_M_U lock type that is already held by my direct seeding session. Blocking session (my direct seeding session).SELECTĭB_NAME(tl.resource_database_id) as , In fact, my backup was blocked (as I supposed) and here what I found from the sys.dm_tran_locks and sys.dm_exec_requests DMVs. So let’s try to perform a backup while the database is concerned by an active seeding session.
As said last time, this value is meaningful by itself. We found an interesting LIMIT_CONCURRENT_BACKUPS value for current state of the hadr_automatic_seeding_state_transition event. As promised in my prior blog post, we’ll talk now about direct seeding feature and backups.
0 kommentar(er)
