Comments
Sort by recent activity
Nup. Rows like the one below all through the period of the issue (actually, all the rows in the table look exactly the same...).
copylist_id attempt type copystart copyend success message
356058 1 C 19/07/2014 23:52 19/07/2014 23:53 -1
BB / comments
Nup. Rows like the one below all through the period of the issue (actually, all the rows in the table look exactly the same...).
copylist_id attempt type copystart copyend success message
356058 1...
Thanks Peter,
There is no registry setting for COPYTO:ExpiryIntervalInMinutes
A lot of large backups get copied around during this time because of database maintenance jobs. Log shipping for this server gets many hours behind at this time of the week but we have only seen it fail to copy files once before.
BB / comments
Thanks Peter,
There is no registry setting for COPYTO:ExpiryIntervalInMinutes
A lot of large backups get copied around during this time because of database maintenance jobs. Log shipping for this s...
Thanks Pete.
Some of the log files here are pretty big and take 10s of minutes to copy, others only take a few seconds. With the log backups every 15 minutes, it appears that the small files are getting copied down during this period and just the big ones are queuing. (Though I can picture a scenario where all 5 threads are doing big file copies which would certainly hold other things up).
The network link is very definitely a bottleneck so adding more threads is probably not going to help much.
As this doesn't look likely to solve the issue with the out of order copying I don't think I'll make these changes.
Thanks for your time and thought on the issue.
BB / comments
Thanks Pete.
Some of the log files here are pretty big and take 10s of minutes to copy, others only take a few seconds. With the log backups every 15 minutes, it appears that the small files are ge...
Thanks Pete,
That was the query I was using to examine the log.
Running it again now the particular row now looks like ....
id name copyto overwrite count diskretryinterval diskretrycount mailto mailto_onerror created lastattempt
40266 H:\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\fred\fred_20131215000201.sqb \\fred-sql2\Log Shipping Share\fred\LOG_fred_20131215000201.sqb 0 1 30 10 2013-12-15 00:02:05.377 2013-12-15 17:03:56.000
If that formats to anything useful for you, it should show you that it was only attempted once. The created time of 2 minutes after midnight makes sense and the last (and only) attempt was 5:03pm. When I was looking at it prior to 5pm it showed count of 0 and nothing in the last attempt column.
I've spared you the other 1000 rows from that period and changed the server name and database name. There were 4 files that behaved like this yesterday. All came right by themselves in the end.
Thanks, BB. / comments
Thanks Pete,
That was the query I was using to examine the log.
Running it again now the particular row now looks like ....
id name copyto overwrite count diskretryinterval diskretrycount mailto ma...
Hi,
I've logged in with the service account and confirmed that osql is in the path.
I also checked the tmp dir and it is writeable by this account.
BB. / comments
Hi,
I've logged in with the service account and confirmed that osql is in the path.
I also checked the tmp dir and it is writeable by this account.
BB.
This is still weird... I changed to ERASEFILES=2 and now it is deleting stuff 36 hours old rather than 48!
My timezone is GMT + 12... could this be freaking out the calculation?
javascript:emoticon(':?')
Confused / comments
This is still weird... I changed to ERASEFILES=2 and now it is deleting stuff 36 hours old rather than 48!
My timezone is GMT + 12... could this be freaking out the calculation?
javascript:emoticon...