Comments
Sort by recent activity
Hi John,
A very good question, and one we're still debating. We'd like to have more feedback from our beta users to understand what people need in this area, and why.
One available solution in the beta is that if you really aren't worried by the disk space consumed by your dev machines, then after the disk space incidents come up you can hit "Ignore on <MACHINENAME>" to prevent them from coming up on that machine in the future.
Thanks,
Dan / comments
Hi John,
A very good question, and one we're still debating. We'd like to have more feedback from our beta users to understand what people need in this area, and why.
One available solution in the ...
This is a very interesting discussion. I'd be very interested to know what configurations are typical for our customers, so if you do have issues in this area, or would like to comment further, please do. We definitely want to make it as workable as possible for people to use this tool the way they need to. / comments
This is a very interesting discussion. I'd be very interested to know what configurations are typical for our customers, so if you do have issues in this area, or would like to comment further, ple...
Hi Andrew,
Thanks for your question. You're quite right, the Beta version of SQL Response does assume that you have such a login, and that all SQL Servers are on the same domain.
Customers monitoring multiple domains can of course install one Incident Repository per domain, and connect to them sequentially using a single client.
However, it sounds like your requirements are rather different. If SQL Response were to permit the user to specify a different Windows login for each server, would that satisfy your requirements? Or is Windows authentication not feasible between the Incident Repository computer and the monitored SQL Servers? If not on the same domain, are they on the same LAN? Are any protocols other than SQL communication open?
All the best,
Dan Archer
Red Gate Software / comments
Hi Andrew,
Thanks for your question. You're quite right, the Beta version of SQL Response does assume that you have such a login, and that all SQL Servers are on the same domain.
Customers monitori...
Thanks for that, that's a good point. We're very interested in which incident types are good, which are bad, and any that are missing.
All the best,
Dan Archer
Red Gate Software / comments
Thanks for that, that's a good point. We're very interested in which incident types are good, which are bad, and any that are missing.
All the best,
Dan Archer
Red Gate Software
Thanks for your feedback.
Would you say this is useful even if you have no jobs scheduled to run on that server?
Since, if there are jobs scheduled to run, then if the Agent is not running, you will be told the agent is not running - via "Job failed to start (Agent not running)" incident per job. / comments
Thanks for your feedback.
Would you say this is useful even if you have no jobs scheduled to run on that server?
Since, if there are jobs scheduled to run, then if the Agent is not running, you wil...
Hi Oleg,
Thanks for that. All comments and critique are welcome.
We don't currently have plans for gifts for beta testers, though we are offering a reward for people willing to talk to us by phone or in person in the UK regarding SQL Response. We're looking to conduct sessions of up to one hour.
We're looking both for DBAs who are responsible for monitoring and maintaining SQL Servers, and might use a tool like SQL Response, but haven't touched SQL Response yet; and for users who have already had a chance to play with it.
If anyone is interested, please e-mail usability@red-gate.com. Places are limited, but we are looking for quality feedback (not necessarily positive!) and those we talk to will receive a $100 Amazon voucher.
Thanks,
Dan / comments
Hi Oleg,
Thanks for that. All comments and critique are welcome.
We don't currently have plans for gifts for beta testers, though we are offering a reward for people willing to talk to us by phone ...
Hi all,
Another update: we've isolated the problem to use of the RESTORE FILELISTONLY command with backups created with multiple threads. SQL Backup 5.0 and 5.1 end up verifying the entire file during this process, which naturally takes some time if the file is large. The UI uses this command in order to work out which files each backup file contains.
We've got a fix in progress for this at the moment. This should make it into the 5.2 release of SQL Backup. I don't have an exact timetable for that release as yet, but if anyone has an urgent need for a fix for this, please private message me and I'll see what I can do [image]
All the best,
Dan / comments
Hi all,
Another update: we've isolated the problem to use of the RESTORE FILELISTONLY command with backups created with multiple threads. SQL Backup 5.0 and 5.1 end up verifying the entire file dur...
Thanks to you both for that.
You're right, with multiple threads there is interleaved data in the file as backed up by those threads. This is to maximise the speed of the backup, as it avoids the threads waiting on each other in order to write the backup file in a precise sequence.
As an update, re the time taken to check passwords/validate backups performed with multiple threads: we've confirmed similar behaviour under certain conditions in our test suite - we're just isolating exactly what the cause is, and exactly when it happens. I'll get back to you as soon as I know more.
Thanks for your help so far.
All the best,
Dan / comments
Thanks to you both for that.
You're right, with multiple threads there is interleaved data in the file as backed up by those threads. This is to maximise the speed of the backup, as it avoids the t...
Hi Marc,
Thanks, that's useful. We'll try and reproduce it locally and get back to you, hopefully tomorrow.
All the best,
Dan / comments
Hi Marc,
Thanks, that's useful. We'll try and reproduce it locally and get back to you, hopefully tomorrow.
All the best,
Dan
Thanks for your replies.
Can I confirm you're both using SQL Backup 5? Backup 5 should indeed generate one file regardless of the number of threads.
All the best,
Dan / comments
Thanks for your replies.
Can I confirm you're both using SQL Backup 5? Backup 5 should indeed generate one file regardless of the number of threads.
All the best,
Dan