Database Overview

SQL Response v2 will provide four main overviews of your system. Starting at the Global Overview page, you can drill down to a Machine overview, a SQL instance overview, and from there down to the database level. We’ve previously posted some of these overview designs for the Global, Machine and SQL Server levels.

The design below is a mock-up of how the overview page for a database might look. (Click to expand the image).

Database Overview

You will be able to click on an individual graph or metric to go to a dedicated page with more detail about that data, but what we’d like to know is –
is there anything not in this design that you’d really like to see at this overview level?

If you’ve drilled down this far, chances are you’re troubleshooting a problem? So perhaps you may need to see something about your tables (total number, growth, space) or your indexes, or connections? We’re trying to determine what would be the most useful information to display about each database, without cluttering the UI such that it’s too hard to find relevant information.

As ever, it would be great to hear your opinions…

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


  1. Adam
    Posted February 1, 2010 at 2:42 pm | Permalink

    One of our readers wasn’t able to post the comment himself, but kindly sent an email:

    If you’re an administrator, it would be great to be able to right-click on an index that needs defragmentation and to defragment it right then and there. Ditto for all sorts of other operations; e.g., rebuild, reorg, etc. for indexes, shrinkfile for logs, and so on.


    • Posted February 2, 2010 at 7:22 pm | Permalink

      Oh, one other slick feature would be the ability to run several Response monitors, but be able to show data collected by multiple Response installations in a single browser session. For example, I have two sites: one in San Diego and one in Virginia. Both have about the same number of SQL Servers, so using SQL REsponse 1.3 we have two Response systems running (one in each site). I have to flip between them in order to try and see any patterns in performance.

      I haven’t seen this get much discussion, but I like all the feaures you’ve been thinking about so far.

  2. Posted February 2, 2010 at 1:33 pm | Permalink

    I am not so sure about that. Rebuilding index can take hours, if not a day or two for our large tables.
    It would be better to have SQL Response to schema the rebuild as a one-time job, and have the job delete itself when done successfully.

  3. Brian.Harris
    Posted February 2, 2010 at 3:11 pm | Permalink

    Thanks Larry and Peso,

    Very interesting feedback.

    We’ve had similar suggestions for this kind of functionality before, but there’s also a vocal group of Response users who don’t want their monitoring tool to perform any of these corrective actions. The reason appears to be that they consider it part of their role as a DBA to maintain absolute control over any action that has a direct physical impact on their systems (in contrast to a tool that only collects information) and they don’t want to delegate even the simple things to a piece of software… that may be considered an abdication of their responsibility.

    Of course, a compromise solution is for a tool like Response to generate a script for carrying out various remedial functions, that can be modified and run at any time by the DBA. This is a halfway house between, say a “Defrag index now” button and user assistance text that explains the issue and how to resolve it. The ultimate responsibility would still rest with the DBA. The types of problem for which these scripts could be generated, however, would be necessarily limited, and only a subset of al the issues that Response can alert you to, so it would only ever be a partial solution.

    This is an interesting debate, though, and it’s always great to hear other views. For now, we’re throwing all our efforts behind implementing the best real-time monitoring interface we can (to augment the alerting functionality from v1) so this additional layer of reactive fixing functionality is not in our plans for v2.0. Beyond that, however, it’s certainly a very fruitful area for possible enhancements to our product, and one we’ll be considering in more depth post-release.

    • Posted February 2, 2010 at 7:19 pm | Permalink

      I was thinking that another nifty and easy feature would be sharing of sql instance lists between SQL Response and SQL Multi-script. I have to manually add a SQL Instance to both of these products now, and it would be really slick if I could just tell Multi-script to pull the list of SQL Servers from SQL Response’s list of monitored servers.

      • Adam
        Posted February 3, 2010 at 3:45 pm | Permalink


        We like this suggestion and think this may work as an add on. It won’t make v2.0 of SQL Response, and it will need some work on Multi-script too, but we’ll log this as a feature request and certainly keep it in mind.

        Thanks for the feedback


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>