Machines, servers, physical servers, SQL servers…

One of the issues we are encountering on a daily basis in the development process for SQL Response 2 is the question of how you think about your monitored servers. SQL Response 2, like version 1, will monitor both SQL Server issues (deadlocks, job failures, blocked processes, long running queries, database status changes and so on) as well as disk and memory performance issues from the physical computer itself (CPU utilization, disk usage, read/write latency etc).

SQL Response will have an overview page for each physical server and also for each individual SQL Server instance; these pages will display different types of data. So it’s up to you what you look at. However, for the global overview, the ‘front page’ that is intended to alert you to parts of your network where there may be an issue to investigate, we want you to quickly identify where there is an issue affecting a machine (the box itself) or where there is a specifically SQL Server problem.

One instance per physical server?

If all your servers run just one SQL Server instance, then most of the time maybe you don’t really need to differentiate between a computer issue and a SQL Server problem. After all, a problem on that computer is likely to be a problem that affects the running of SQL Server. In this case, rather than view two lines of information (computer status and SQL Server status) for each instance, maybe you’d rather have a flat list of just SQL Server instances.

Several instances per physical server?

If your servers run several SQL Server instances, then it is clearly useful to see clearly machine-triggered issues and issues that affect one of the SQL Servers that run on that machine. In this case, maybe you’d like to sort by computer name, and see computer issues, as well as any SQL Server problems, and always be able to distinguish the two in the overview.

So, how important is it to know that there is an issue affecting the computer rather than identify all issues as relating to a SQL Server – even if they are disk or CPU issues. And what terminology do you prefer – physical server, computer, server, machine, box – when identifying the source of a problem?

This entry was posted in Uncategorized. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

3 Comments

  1. Jonathan Allen
    Posted October 23, 2009 at 1:50 pm | Permalink

    We have a mixture of single instance per ‘server’ and multiple instances per ‘server’ here. How about simply having one row per instance and having a similar coloured background for instances on the same hardware? Having the interface allow for grouping/sorting by hardware or by instance name etc can still happen. The hardware doesnt necessarily have to be declared on the page. I know my infrastructure well enough (and I am sure most DBAs do) to link instances to hardware so having redundant information on the screen seems a waste.

    If its absolutely necessary I can crack open MSPaint and draw what I am trying to explain but you have seen my attempts at drawing before…!

    Jonathan

  2. Nicole Garris
    Posted October 23, 2009 at 3:55 pm | Permalink

    We have one instance per server. However, rather than being physical servers, most of our SQL Server servers are virtual. As a result, we don’t care when the memory drops to a low value as long as SQL Server doesn’t need a lot of memory at that particular time. We would want to be alerted when the server tries to get more memory from the host but can’t (probably because some other server on that host is using more than its share). The same goes for CPU, but our hosts tend to be memory bound.

    It would be nice if SQL Response knew which SQL Servers were hosted on the same virtual host.

  3. Tom
    Posted November 2, 2009 at 12:33 pm | Permalink

    Jonathan

    It’s OK I think we understand ;o)
    We are considering an alternative flat list view of instances too – I do like the idea of color coding to show instances are hosted on the same machine.

    Nicole

    Unfortunately we probably won’t be able to detect what’s on the same virtual host ; but we will be able to show what SQL Instances are on the same virtual machine. We’ll also allow you to group machines manually as a kind of work around.

    In terms of alerting, we should be able to cater for this type of scenario as we’ll be collecting information on Target Server Memory and Total Server Memory Used.

Post a Comment

Required fields are marked *

Add an Image

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>