July 2, 2013 at 1:14 pm
Hello,
We have a SQL Server instance with ~200 DBs on it. Each one is log shipped to a remote site. To avoid all jobs going off at once, I've scripted sqllogship.exe to run in 1 job sequentially. Anyway, I am finding that each DB is taking 30 seconds to complete. I have log shipping on servers with ~100 DBs similarly sized and with similar data that works fine, taking seconds on each DB. I have invoked sqllogship.exe from the command prompt and indeed it took 30 seconds. So the problem lies within sqllogship.exe. I thought perhaps these 200 DBs have created a large MSDB that is slowing down sqllogship so I ran sp_delete_backuphistory and eventually deleted everything but the last 30 days, which leaves about 100k records, which is very small compared to the other servers that have a much faster time running sqllogship. I also added some indexes I thought could help (backupset(media_set_id), restorefile(restore_history_id), restorefilegroup(restore_history_id)) but they did not affect the 30 second runtime. What is odd is that it has been 30 seconds exactly on several databases. Another clue is that backupset logs the backups being made by sqllogship.exe as being finished in a second or so...so where are the other 29 seconds coming from? I tried setting verboselevel to 0 in sqllogship but that doesn't help either.
All of our servers have this version:
Microsoft SQL Server 2012 (SP1) - 11.0.3368.0 (X64)
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
Thanks!
July 3, 2013 at 12:26 am
An update --- I tested on another sql server instance on the same machine where I am implementing log shipping. After initializing only a few of these DBs I could see that sqllogship.exe was taking 30 secs to finish. So it appears this is not related to how many log shipping configs are on the server. Since both servers reside on the same physical machine, it could be the machine that is the issue. But I am curious what environmental factors could cause sqllogship.exe to finish in 30 seconds everytime whereas similar databases (even copies of these DBs elsewhere) finish in seconds when log shipped. Any ideas?
Thanks!
October 25, 2013 at 2:54 pm
Any thoughts? This still persists with my only workaround to use queue and several workers to concurrently process the log backups
November 13, 2013 at 12:06 pm
I have a similar problem (mine was a 60 sec delay) when backing up to a SQL 2012 clustered storage server.
I just found that if I turn off "continuous availability" on the clustered file share the problem goes away.
Not sure it if this is your problem but you might try backing up to a different location as a test to see if it changes.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply