The first EAP contained a lean implementation of our new ‘Custom Metrics and Alerts’ feature. This gives users the ability to run custom T-SQL against their databases, monitor the data and receive alerts when the data breaches the defined thresholds. We wanted to get the bare bones of the feature out as soon as possible so we could begin getting feedback as we continued to work on the feature.

What’s in the next EAP?

We’ll have an improved version of the Custom metrics and alerts feature in the forthcoming EAP.

We’ve also asked for suggestions on what you’d like to see in v3 via SQL Monitor Uservoice. The most commonly requested feature has been the ability to have multiple levels of user, for example, a “’guest’ user who could review the data that was collected but not modify the settings”. So we’ve been working on this feature and it should also be in the next EAP. Again, we’re interested to hear your thoughts on it.

We’d like to take this opportunity to thank everyone that has given us feedback so far and we’re also grateful for everyone that enabled the automatic error and feature usage reporting which are particularly useful ways for us to receive technical feedback from the EAP without requiring effort from the user.

If you’d like to sign up to the next EAP, please email SQL Monitor and we’ll send you the details.

Who knows, next year we may even give you the chance to win a ticket back…

DBA in Space

The EAP will be released next month. If you would like to participate in this EAP please enter your details and we will contact you nearer the time with more information.

In the meantime, you can tell us what you’d like to see in SQL Monitor v3

As always, we appreciate your feedback and look forward to hearing from you.

Cheers!

The SQL Monitor Development Team

That is, served with a healthy dose of hot sauce and washed down with Ingeniously Pale Ale.

There are presentations by Grant Fritchey, Brad McGehee, Steve Jones, Buck Woody, Mladen Prajdić, Jonathan Allen, Neil Hambly and more. There’ll be plenty of Red Gaters floating around (neat trick that) you can talk to if you’d like to know more about our tools or share any feedback.

For me, this is the best bit; having the opportunity to talk to you about SQL Monitor, listening to what you think about it so far and what you want to see next. Your feedback is much appreciated.

Did I say ‘best bit’? I was forgetting the drinks reception.

We look forward to seeing you…

Cheers!
The SQL Monitor Team

Fatherjack (Twitter|blog) and Mrs Fatherjack (Twitter|blog) are already heading there in style in a classic Mark 1 Golf GTI convertible seemingly powered by Red Gate:

There is an interesting experiment happening over at SQLServerCentral.com. The databases for SSC and Simple-talk.com can be monitored by anyone (SQL Monitor was installed and the interface made public at monitor.red-gate.com). So you’re invited to take a look at them, and then suggest changes to the configuration based on what you see.

Brad McGehee is writing a series of articles, with each article focusing on a specific topic, and readers are invited to send in their suggestions. In Part 1 the focus is simply on the property settings, because as Brad says, this is “what I do when I first check out a SQL Server that I have never seen before”. Brad, along with Grant Fritchey, Steve Jones and Simon Lye, will comment on the suggestions and then write a follow up. Gradually the articles will dive deeper into the environment and build a picture of best practices as recommended by the community.

Here’s an example of how it’s working:

Read Brad’s opening article, SQLServerCentral Best Practices Clinic: Part 1 for all the info.

Back on Twitter, there was some talk about whether anything in the SQL Monitor console pointed to something obviously wrong with the SSC databases. Particular attention was being paid to a CPU spike which could be seen in SQL Monitor’s performance counter analysis tab. I had a look at this, and saw that it started at 7.00am GMT … which I knew from experience was when the full backups of the SSC databases are run. @davebally had mentioned that the high CPU was being caused by the SQL Backup process, so it seemed that the high CPU was something that I would expect at that time. After further investigation in SQL Monitor, I could not see anything else obviously wrong with SQL Server.

The next step was to have a look at the web server. I logged in, and firstly had a look at the event logs. Immediately it was obvious that it wasn’t happy – there were a series of events in the Application event log referring to the unexpected termination of an application pool process some time earlier. A further error stated that the application pool serving the SSC web site was failing to respond. It seemed fairly clear that something nasty had happened to the SSC web site application pool, so the first thing I tried was an application pool recycle. Immediately after this was done, the site came to life again. A quick check showed that it seemed to be working … except for the SSC blogs, which were still down, and something that was also quickly mentioned on Twitter!

A quick recycle of the application pool used by the blogs site also bought that back online, and all seemed to be good after this.

So it seems that the problem was ultimately with IIS. However it was great to see people out there using the live SQL Monitor site to investigate any potential SQL Server issues after noticing the site was unavailable, and also great to find out that there weren’t any! It was also an interesting experience (and a testament to the power of social networking) to find that I was alerted to the problem more quickly through Twitter than through our enterprise monitoring system!

Support information on using SQL Monitor with IIS

In the example above, our cheeringly named death machine is set to suspend alerting for one hour each evening at 11pm. SQL Monitor continues to collect the data, so you can still go back in time to a point that occured in a maintenance window and see what was happening, and the data will be in the repository for reporting purposes (I’m coming to that), but alerts won’t be raised for the duration of the window. This is useful for scheduled downtime and is in addition to the existing ‘Suspend monitoring’ option which can be used to manually stop monitoring and prevent SQL Monitor from connecting until you resume monitoring.

We’ve also provided a free SQL Monitor SSRS Reporting Pack as a good place to get started if you want to generate reports from SQL Monitor’s data repository. There are 9 examples, including reports to show CPU, Memory, RAM or disk usage over time.

Download the free SQL Monitor SSRS reporting pack
Release notes for SQL Monitor 2.2

We hope you find these useful and look forward to your feedback as we continue developing the next release…

I work for Red Gate as a Test Engineer and for some time now I’ve been involved with the creation of the recently released SQL Monitor 2. I started using Amazon’s EC2 service to create a network of 50-60 machines that I had full control over. In this virtual network I had specific machines for domain controller, base monitor (the machine that runs our data collection service), web server (to run our Web UI), data repository (a standard Amazon SQL Server AMI) and a machine that ran an internal application for creating activity on SQL Servers instances. All other machines were pre-configured as SQL Servers containing a hefty database which our sql activity application would be hammering on many threads (each thread = 1 user connection). The idea was that this would go some way towards simulating the real-world environments for which our monitoring solution would be used.

The 50 remaining virtual machines (all running SQL Server) were added to SQL Monitor and the software was left to do its work for several hours (long enough to monitor performance impacts but no soak testing being done here). This is where Amazon’s CloudWatch service comes in handy. We were able to simply toggle CloudWatch on or off for any of the running instances. But to prevent information overload we chose to monitor the base monitor, SQL Server data repository, web server and several of the Servers being monitored. If you’re wondering why we monitor the servers that SQL Monitor is itself monitoring (it can get confusing), it’s so that we can see our impact on these machines. Although we have an idealised zero-impact goal for our customer’s SQL Servers (unlike some of our competitors we don’t install agents) , the perfmon, WMI, windows file sharing and SQL queries do add a slight overhead. So this had to be monitored very carefully.

As I stated CloudWatch can be toggled on or off for any instance. This can be done in the start up code (if you want to automate) or using the Amazon Management Console. In a previous post I criticised this console for various reasons but its support for CloudWatch is very nice. You can view graphs for CPU Utilization, Network Inbound, Network Outbound and get an early indication of issues on any of the machines. This brings me nicely to what I consider to be a huge omission with CloudWatch. For some inexplicable reason it doesn’t monitor memory usage and I can only assume that there are technical reasons for this as it’s a huge oversight.

Once the test period was finished and the monitoring data safe on my hard drive (it can be collected using the CloudWatch API), I would analyse it in Excel and if necessary create graphs to emphasise any performance issues found.

Base Monitor machine monitoring fifty servers:

This testing ran in parallel with more traditional in-house testing and went a long way to being able to confidently say that the product performs acceptably under stress.

Why the long running query?

Or, we’ve wished we could escape the office and keep an eye on our databases while we were at home relaxing… wielding an axe (not much call for chopped wood in our electrically heated office)

Log backup overdue

More likely, you’ve wanted to get away from the server room and simply chow down on some chicken in a restaurant (I’m vegetarian, but…)

Cashew nut hit ratio

So to recap, I’ve never monitored on horseback, whilst chopping wood, or eating chicken. If you have any similar photos of monitoring your servers, please Send us your photo now so we can see what we could be doing if we had SQL Monitor and an iPad.

Man's best friend - SQL Monitor on the iPad