How can we help you today? How can we help you today?
qcjims
Activity overview Badges (0) Posts (11) Comments (16)

Comments

Sort by recent activity
I have this same issue. would love a fix. / comments
  1. Community
  2. SQL Backup Previous Versions
  3. Restore to default directory
I have this same issue. would love a fix.
0 votes
James Moore wrote: Hi Jim, This is possible - Please pm me the settings you want to set then we can come up with the right TSQL for you. James Please post how this is done in the forums. We have 100 physical systems (150+ instances) and would like to be able to do this as well. -js / comments
  1. Community
  2. SQL Backup Previous Versions
  3. How can I set backup options via t-sql commands
James Moore wrote: Hi Jim, This is possible - Please pm me the settings you want to set then we can come up with the right TSQL for you. James Please post how this is done in the forums. We ha...
0 votes
Disabling key replication is not a good fix for us. this is because the settings for email, how many days to keep logfiles, etc. are all in the registry. if we set these settings on one node, and those settings don't propagate to the other nodes, then we run into problems if an instance of sql server is ever moved over to another clustered node. please fix this ASAP. / comments
  1. Community
  2. SQL Backup Previous Versions
  3. Error in system event log on x64 cluster system
Disabling key replication is not a good fix for us. this is because the settings for email, how many days to keep logfiles, etc. are all in the registry. if we set these settings on one node, and...
0 votes
We are definitely affected by this bug. we have 30+ clustered environments with RGB installed. manually changing this on all the systems is a serious pita. Our event logs are basically completely useless because of this problem, since we run 10+ instances per cluster our logs are just completely dominated by these errors. Is red-gate working with Microsoft to try and determine the cause of this issue? -js / comments
  1. Community
  2. SQL Backup Previous Versions
  3. Error in system event log on x64 cluster system
We are definitely affected by this bug. we have 30+ clustered environments with RGB installed. manually changing this on all the systems is a serious pita. Our event logs are basically completel...
0 votes
does the 6.3 release resolve this issue? / comments
  1. Community
  2. SQL Backup Previous Versions
  3. Error in system event log on x64 cluster system
does the 6.3 release resolve this issue?
0 votes
Is there any update to this? / comments
  1. Community
  2. SQL Backup Previous Versions
  3. Error in system event log on x64 cluster system
Is there any update to this?
0 votes
RBA wrote: Yes, MSCS replicates keys on failover (which seems slightly odd, since the previously active node might well be offline) so you won't see registry changes propagate until later. so taking the SQLBACKUP_AGENT offline and then bringing it back online is not enough? This KB article seems to indicate that registry changes are replicated when the resource goes offline. So, if i just fail the resource then it should replicate across all nodes right? http://support.microsoft.com/kb/174070 Any inconsistencies are probably a result of the fact that key replication breaks when this bug occurs. What bug are you referring to? -js / comments
  1. Community
  2. SQL Backup Previous Versions
  3. Error in system event log on x64 cluster system
RBA wrote: Yes, MSCS replicates keys on failover (which seems slightly odd, since the previously active node might well be offline) so you won't see registry changes propagate until later. so t...
0 votes
registry replication appears to be the culprit for us. I removed the entries in cluster admin for the individual SQLBACKUP_AGENT cluster resources and the errors in the System event log have disappeared. If I look in the cluster.log for errors, I see the following entries (or similar). The .tmp file mentioned matches up with the error in the event logs. Here are the cluster.log entries: 000010a8.00001a38::2009/09/17-23:23:21.391 WARN [CP] CppRegNotifyThread CppNotifyCheckpoint due to timer failed, reset the timer. 000010a8.00001a38::2009/09/17-23:23:21.391 INFO [CP] CppRegNotifyThread checkpointing key Software\Wow6432Node\Red Gate\SQL Backup\BackupSettings\B to id 2 due to timer 000010a8.00001a38::2009/09/17-23:23:21.391 INFO [Qfs] QfsGetTempFileName C:\DOCUME~1\MCS64\LOCALS~1\Temp\, CLS, 54807 => C:\DOCUME~1\MCS64\LOCALS~1\Temp\CLSD617.tmp, status 0 000010a8.00001a38::2009/09/17-23:23:21.391 INFO [Qfs] QfsDeleteFile C:\DOCUME~1\MCS64\LOCALS~1\Temp\CLSD617.tmp, status 0 000010a8.00001a38::2009/09/17-23:23:21.391 INFO [Qfs] QfsRegSaveKey C:\DOCUME~1\MCS64\LOCALS~1\Temp\CLSD617.tmp, status 5 000010a8.00001a38::2009/09/17-23:23:21.391 INFO [Qfs] QfsDeleteFile C:\DOCUME~1\MCS64\LOCALS~1\Temp\CLSD617.tmp, status 0 000010a8.00001a38::2009/09/17-23:23:21.391 WARN [CP] CppCheckpoint failed to get registry database Software\Wow6432Node\Red Gate\SQL Backup\BackupSettings\B to file C:\DOCUME~1\MCS64\LOCALS~1\Temp\CLSD617.tmp error 5 000010a8.00001a38::2009/09/17-23:23:21.391 INFO [Qfs] QfsDeleteFile C:\DOCUME~1\MCS64\LOCALS~1\Temp\CLSD617.tmp, status 2 000010a8.00001a38::2009/09/17-23:23:21.391 WARN [CP] CppRegNotifyThread CppNotifyCheckpoint due to timer failed, reset the timer. Here is the corresponding error in the system event log: Event Type: Error Event Source: ClusSvc Event Category: Database Mgr Event ID: 1080 Date: 9/17/2009 Time: 4:23:21 PM User: N/A Computer: XXXXXXXXXXXX Description: Cluster service could not write to a file (C:\DOCUME~1\MCS64\LOCALS~1\Temp\CLSD617.tmp). The disk may be low on disk space, or some other serious condition exists. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 05 00 00 00 .... When I add the replicated registry entries back using CLUADMIN, the errors do not return. However, it does not appear that registry replication is actually doing anything at this point (which might explain the lack of errors). When I attempt to make changes to these values using the SQLBackup GUI (changing smtp setting for example), the values are recorded on the node that the cluster group is running on, but the values are not replicated to the other nodes. I have also noticed that there are inconsistencies between the instances listed under the BackupSettings, BackupSettingsGlobal and InstalledInstances registry keys across the cluster nodes. Shouldn't all the instances listed under each key be the same across the entire cluster? -js / comments
  1. Community
  2. SQL Backup Previous Versions
  3. Error in system event log on x64 cluster system
registry replication appears to be the culprit for us. I removed the entries in cluster admin for the individual SQLBACKUP_AGENT cluster resources and the errors in the System event log have disap...
0 votes
I was curious about the feature set since the roadmap indicates releases this year. I don't have anything in particular that I'd like to see at this point. / comments
  1. Community
  2. SQL Backup Previous Versions
  3. SQL Backup Pro 6.5 and 7
I was curious about the feature set since the roadmap indicates releases this year. I don't have anything in particular that I'd like to see at this point.
0 votes
I was fed up with this product too. Too many issues to deal with and try to troubleshoot. I just simply gave up and will wait for these bugs to be fixed. Maybe version 3 will work a little better. For now, 2.1 is basically unusable in a large environment. -jim / comments
  1. Community
  2. SQL Monitor Previous Versions
  3. Monitoring Stopped - NOT INFORMED OF THIS
I was fed up with this product too. Too many issues to deal with and try to troubleshoot. I just simply gave up and will wait for these bugs to be fixed. Maybe version 3 will work a little bette...
0 votes
Total activity
37
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
10