Comments
Sort by recent activity
Peter,
I finally got around to testing the combination of LATEST_ALL with STOPAT. This is probably by design, but I noticed that the restore worked exactly as you indicated it would, as long as the STOPAT value was later than the most recent database-level backup. However, if I specify a STOPAT value earlier than the most recent database-level backup, the process will still restore the most recent FULL, followed by the most recent DIFFERENTIAL, and then it will fail when it attempts to apply the LOG backups. This behavior can be illustrated by the following example.
Assume I have the following available backups:
L-8
L-7
D-6
L-5
L-4
D-3
L-2
L-1
F-0
If I attempt to set the STOPAT parameter to a datetime value between L-4 and L-5, the LATEST_ALL parameter seems to still force the restore of F-0 followed by D-6 before processing the STOPAT cutoff time. As I said, this is probably by design. However, it might be beneficial for SQL Backup to be able to apply the STOPAT criteria before it selects which backup sets it is going to use.
Anyway, just thought I would share the results of my testing. Keep up the good work, it is much appreciated.
Regards,
-Mike Eastland / comments
Peter,
I finally got around to testing the combination of LATEST_ALL with STOPAT. This is probably by design, but I noticed that the restore worked exactly as you indicated it would, as long as th...
Peter,
The patch appears to have addressed this particular issue. Thank you for the quick turnaround.
Now, I have yet to upgrade my remaining servers to 6.5. In order to do so, would I need to install the base 6.5 release and then apply the patch as I did with this test server?
Thanks,
-Mike / comments
Peter,
The patch appears to have addressed this particular issue. Thank you for the quick turnaround.
Now, I have yet to upgrade my remaining servers to 6.5. In order to do so, would I need to in...
Peter,
Please ignore my previous upgrade question. I think I've got it covered.
Thanks again for the quick resolution.
-Mike / comments
Peter,
Please ignore my previous upgrade question. I think I've got it covered.
Thanks again for the quick resolution.
-Mike
Peter,
I would not be opposed to trying to recreate the error. However, I want to be sure that something is different, such as a higher debug setting etc, in order to provide you with additional troubleshooting information. It seems that just flipping back to the multiple files for the sake of having the process generate another error doesn't really get us closer to the root cause.
Thanks,
-Mike / comments
Peter,
I would not be opposed to trying to recreate the error. However, I want to be sure that something is different, such as a higher debug setting etc, in order to provide you with additional t...
Peter,
The process has executed successfully the past four consecutive days since the switch was made back to using a single backup file. I'll watch it for the rest of the week, but it appears this change has resolved my particular issue.
That being said, have there been any other reports of customers having issues with striping backupsets across multiple files? At my previous employer, I did this frequently with the larger databases I managed using native SQL Server backups and it seemed to work fine.
Thanks again for your time.
-Mike Eastland / comments
Peter,
The process has executed successfully the past four consecutive days since the switch was made back to using a single backup file. I'll watch it for the rest of the week, but it appears thi...
Peter,
The process has not failed since the switch was made back to writing the full backupset to a single file. This is not a problem for me currently, but I think other customers with larger databases could see significant performance gains in their backup jobs by striping large database backups across multiple files.
I'm not sure how you want to leave this. I'm fine with considering the issue closed from my end, but I would also be happy to provide any additional information that might help troubleshoot the underlying issue.
Thanks,
-Mike / comments
Peter,
The process has not failed since the switch was made back to writing the full backupset to a single file. This is not a problem for me currently, but I think other customers with larger dat...
Peter,
I made one change to the backup process for this particular database last night. Instead of striping the backup across multiple files, I went back to writing it to a single file. Subsequently, the restore process completed successfully this morning. Is it possible that trying to restore from multiple backup files is causing this problem?
Thanks,
-Mike / comments
Peter,
I made one change to the backup process for this particular database last night. Instead of striping the backup across multiple files, I went back to writing it to a single file. Subsequen...
Peter,
I checked both files, per your instructions. Here is the information I collected: HKCR\CLSID\{40700425-0080-11d2-851f-00c04fc21759}\InprocServer32
C:\Program Files\Microsoft SQL Server\80\COM\sqlvdi.dll
Version: 8.05.2312
Size: 157KB
HKCR\Wow6432Node\CLSID\{40700425-0080-11d2-851f-00c04fc21759}\InprocServer32
C:\Program Files (x86)\Microsoft SQL Server\80\COM\sqlvdi.dll
Version: 8.05.2312
Size: 120KB
From what I can tell, both files are the same version, but have a considerable difference in size. I'm not sure if that means anything or not. Please let me know if there is any additional information I can collect to help troubleshoot.
Thanks again for your time.
-Mike / comments
Peter,
I checked both files, per your instructions. Here is the information I collected:HKCR\CLSID\{40700425-0080-11d2-851f-00c04fc21759}\InprocServer32
C:\Program Files\Microsoft SQL Server\80\CO...
Peter,
For the purpose of comparison, I checked the version of these files on another host to which I frequently restore this database. The versions of both sqlvdi.dll files match the server on which the error is being generated, but I don't seem to get the error on the second server. Also, the version of SQLBackup is consistent across both servers.
I was hoping to find something different on the server that isn't generating any errors, but that is unfortunately not the case.
-Mike / comments
Peter,
For the purpose of comparison, I checked the version of these files on another host to which I frequently restore this database. The versions of both sqlvdi.dll files match the server on wh...
Peter,
Thanks for the suggestions. I see the following SQLVDI errors in the Application Log which seem to correspond with the time that the restore failed: Log Name: Application
Source: SQLVDI
Date: 4/26/2011 7:15:19 AM
Event ID: 1
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SQLDEV.uhlig.com
Description:
SQLVDI: Loc=CVDS::Close. Desc=Open devices!. ErrorCode=(0). Process=2008. Thread=2196. Client. Instance=. VD=Global\SQLBACKUP_CD6523F1-6602-4913-B5F8-47A982752801_SQLVDIMemoryName_0.
Log Name: Application
Source: SQLVDI
Date: 4/26/2011 7:15:19 AM
Event ID: 1
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SQLDEV.uhlig.com
Description:
SQLVDI: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0). Process=2008. Thread=2196. Client. Instance=. VD=Global\SQLBACKUP_CD6523F1-6602-4913-B5F8-47A982752801_SQLVDIMemoryName_0.
Looking at the SQL Server error log, I also see that a process was killed by the local host around the same time. While I can't say for sure that the killed process is related to the sqlBackup error, there isn't much else going on with the server at the time of the failed restore. Date 4/26/2011 7:15:20 AM
Log SQL Server (Current - 4/26/2011 12:29:00 AM)
Source spid62
Message
Process ID 93 was killed by hostname SQLDEV, host process ID 2208.
Does this information get us any closer to a possible root cause?
Thanks,
-Mike / comments
Peter,
Thanks for the suggestions. I see the following SQLVDI errors in the Application Log which seem to correspond with the time that the restore failed:Log Name: Application
Source: ...