Comments
Sort by recent activity
Not Yet - Thank you for pointing it out. We were already in the process of rolling CU4 out to lower environment servers and should have deployed to Production in the next couple of weeks. Relief! / comments
Not Yet - Thank you for pointing it out. We were already in the process of rolling CU4 out to lower environment servers and should have deployed to Production in the next couple of weeks. Relief!
I sent you a message via the site w/ the password for the archive. / comments
I sent you a message via the site w/ the password for the archive.
I have emailed the logs in a password protected 7-ZIP archive and referenced this post in the email; is there a separate email address or means that I can communicated the password to you? Also the errors occurred on these date/times: 10/18/2018 12:57:18AM 10/07/2018 6:25:34 AM 9/30/2018 11:05:36 PM 9/30/2018 11:05:36 PM / comments
I have emailed the logs in a password protected 7-ZIP archive and referenced this post in the email; is there a separate email address or means that I can communicated the password to you? Also the...
Hi Dan B, I don't see the path you referenced. I do see these two paths however we are running version 9.2.1.128. Would the log be located somewhere the SQL Backup 9 path? C:\Program Files (x86)\Red Gate\SQL Backup 8 C:\Program Files (x86)\Red Gate\SQL Backup 9 / comments
Hi Dan B,I don't see the path you referenced. I do see these two paths however we are running version 9.2.1.128. Would the log be located somewhere the SQL Backup 9 path?C:\Program Files (x86)\Red ...
Hi Dan B- we've run DBCC CheckDB on both the Secondary server itself within the affected database and on a restored copy of the database and both checks came back clean -no data corruption. The last time encountered the error was 10/07/2018 a week after we first encountered it on 09/30/2018. " Is it the case that log 1,2,3,4work 5, doesn't and then 6,7,8 work or are you doing something after the errors to reset the behaviour and then it occurs again?" - Yes that is essentially the case. We will have 1 bad log file written by Redgate SQL Backup, we manually intervene and skip it and the rest of the logs restore without issue. We did not anything to reset the behavior in between the 2 occurrences. Any additional suggestions to get to the bottom of this are greatly appreciated. / comments
Hi Dan B- we've run DBCC CheckDB on both the Secondary server itself within the affected database and on a restored copy of the database and both checks came back clean -no data corruption. The la...