Activity overview
Latest activity by MattS
Thanks for you reply, and the link to the patch.
I understand your recommendation to upgrade, and If/when we upgrade to to SQL2012 there will be an obvious and clear need to upgrade our Red Gate tools (which will satisfy the people that pay the bills and sign off these things).
For now, for testing, the patch does the job.
Thanks again. / comments
Thanks for you reply, and the link to the patch.
I understand your recommendation to upgrade, and If/when we upgrade to to SQL2012 there will be an obvious and clear need to upgrade our Red Gate to...
SQL Compare 9 - SQL 2012 Compatibility
Hi,
We are doing some preliminary testing with SQL2012, and unfortunately have found that SQL Compare errors when trying to connect to a 2012 database.
We are currently on version 9.0.0.79.
I logge...
We deployed the patch on Tuesday and our log shipping backup/restore processes have been running ok.
Last night there was a failure in the restore job, but this was handled and subsequent restore jobs have completed successfully. The same SQLVDI error messages are recorded in the windows event logs, so it seems likely this is the same error that was causing the jobs to hang previously.
Deploying the patch therefore seems to have resolved the issue with the jobs hanging.
For reference, the errors recorded in the SQL backup log file are: 10/05/2012 03:05:08: Thread 0 error:
Process terminated unexpectedly. Error code: -2139684861 (The api was waiting and the timeout interval had elapsed.)
10/05/2012 03:05:08:
10/05/2012 03:05:08: SQL error 3013: SQL error 3013: RESTORE LOG is terminating abnormally.
10/05/2012 03:05:08: SQL error 3201: SQL error 3201: Cannot open backup device 'SQLBACKUP_2022D7BB-9FE4-4987-AF55-9B1A8AFA6512'. Operating system error 0x80770006(failed to retrieve text for this error. Reason: 15100).
Should the errors persist I will raise a new forum topic.
Thanks for your help. / comments
We deployed the patch on Tuesday and our log shipping backup/restore processes have been running ok.
Last night there was a failure in the restore job, but this was handled and subsequent restore j...
Hi Chris,
Thanks for the response. I'll deploy the patch and let you know. / comments
Hi Chris,
Thanks for the response. I'll deploy the patch and let you know.
SQL Agent Hangs With Wait Type PREEMPTIVE_OS_GETPROCADDRESS
Hi,
We are using SQL Backup 6.5.1.9, SQL Server 2008 R2.
We have log shipping running between a production and DR server (it has been running for several months), and twice in the past week the res...
Eddie,
Thanks for your reply, and the clarification. / comments
Eddie,
Thanks for your reply, and the clarification.
Assertion Failure When Verifying Backup
Hi,
I have worked around this issue, but on searching the forums I could find only one post relating to assertion failures, which mentioned that they were a rare occurrence, so I thought I'd post d...
Copy Queue Table For Full/Differential Backups?
Hi,
I understand that when SQL backups are copied from the local directory to a network directory they are queued in the [backupfiles_copylist] table.
However, the only records that appear to be in...
It's now working!
Simply restarting the SQL Backup Agent service seems to have done the trick.
One of the factors behind the move from the current network share to the new DFS namespace is the new DR solution we are implementing. Part of this solution includes log shipping, which we are using SQL Backup for.
Before approaching the network guys about granting 'EVERYONE' permissions on the new share, I tried the same tests we did before (backup msdb to the DFS namespace/EXEC sqbutility) on the DR server and they worked. The SQL Backup service on the DR server is running under the same domain account as the server we've had the issues with, so this again confirmed it was not a permissions issue. As a final test I thought it may be worth restarting the SQL Backup service, and hey presto everything is working now :-)
Thanks for your assistance Pete. Greatly appreciated. / comments
It's now working!
Simply restarting the SQL Backup Agent service seems to have done the trick.
One of the factors behind the move from the current network share to the new DFS namespace is the new ...
It returns the following: <SQBUTILITYRESULT>:0:Folder does not exist : <network share>
Thanks for your help. / comments
It returns the following:<SQBUTILITYRESULT>:0:Folder does not exist : <network share>
Thanks for your help.