Comments
Sort by recent activity
Adding the VDICommandTimout Registry Key and setting it to FFFFFFFF resolves the issue. Thanks petey! / comments
Adding the VDICommandTimout Registry Key and setting it to FFFFFFFF resolves the issue. Thanks petey!
I have observed this issue with data files as small as 7GB and others as large as 200GB.
I suspect some sort of VDI timeout is occurring with the larger files. Also note that the files I am restoring were created with 3 threads. / comments
I have observed this issue with data files as small as 7GB and others as large as 200GB.
I suspect some sort of VDI timeout is occurring with the larger files. Also note that the files I am restor...
Are there any long term plans to merge the two products into one? / comments
Are there any long term plans to merge the two products into one?
Thanks Peter. I will work on building a script that parses the correct values and performs the insert when needed. I will let you know how it goes.
In an effort to make the log shipping process more stable, I have one other issue. Just like the fact that occasionally a record does not get inserted into backupfiles_copylist, sometimes after a successful copy the status doesn't get updated causing a second copy of the file to be sent to the log shipping destination. When this happens, I get an error message on the destination that the file is out of sequence. When it tries to move the file to the MOVETO destination, it already exists and I get an error message that it can't overwrite the existing file. Hence I manually need to delete the file when this happens. Is there an option that can allow the MOVETO destination file to be overwritten when it does exist? Or alternatively delete the duplicate file in the log shipping destination directory? / comments
Thanks Peter. I will work on building a script that parses the correct values and performs the insert when needed. I will let you know how it goes.
In an effort to make the log shipping process m...
That works. Thanks Brian. / comments
That works. Thanks Brian.
No problem Robin. Thanks for logging a bug. Also would you confirm that the 64 bit Wow6432Node registry path was indeed relocated with release 6.4? If true, then the online help as well as KB articles should be updated to reflect this change. / comments
No problem Robin. Thanks for logging a bug. Also would you confirm that the 64 bit Wow6432Node registry path was indeed relocated with release 6.4? If true, then the online help as well as KB ar...
Thanks for the query, I likewise work around the problem by quering msdb records and using other custom restore scripts. But sometimes it's just easier to use the GUI. The main drawback of course to using the GUI is performance. / comments
Thanks for the query, I likewise work around the problem by quering msdb records and using other custom restore scripts. But sometimes it's just easier to use the GUI. The main drawback of course...
I am very glad to hear that fixing this problem is on Red Gate's radar.
I do have a purge policy of 30 days. But due to the number of databases and frequency of transaction log backups on some instances, it just isn't enough. If I need to perform a restore with the GUI, I almost always have to restore directly from file as the restore history is just too slow. One interesting note, even if I query history from the CE database directly results often come back quickly compared to the GUI. I think the bigest issue is the whole caching logic. For reasons that I don't understand, the client GUI wants to copy all the data in the CE databases to the local desktop and then present the restore history from local cache. The problem with that logic is that it takes a long time to copy all the data. While I believe that ditching the CE is important, ditching local client caching is far more critical to improving GUI performance. / comments
I am very glad to hear that fixing this problem is on Red Gate's radar.
I do have a purge policy of 30 days. But due to the number of databases and frequency of transaction log backups on some ins...
I have said it before, but I will say it again.
This is one of those things that would be greatly improved upon if Red Gate were to ditch the use of SQL CE and local client caching. A simple restore history query directly to the SQL tables is lightning fast by comparison. I would recommend that the SQLBackup tables currently stored in the CE database be stored in the MSDB database instead. And there is really no need to waste local storage and CPU cycles by syncing data to the desktops local harddrive. This is extreemly painful for customers that have lots of instances with frequent backups. / comments
I have said it before, but I will say it again.
This is one of those things that would be greatly improved upon if Red Gate were to ditch the use of SQL CE and local client caching. A simple resto...
I have seen in maybe a few times, but it's rare and doesn't seen to be a problem at this point. I have not seen anything in the logs that indicate a cause. The instance that produced this one is running on SQL 2005 SP2 build 9.0.3159 x64.
Like I stated in the initial post, this is more of an FYI. / comments
I have seen in maybe a few times, but it's rare and doesn't seen to be a problem at this point. I have not seen anything in the logs that indicate a cause. The instance that produced this one is ...