Skip to content

Kenneth Fossum

← Redgate Monitor

My feedback

1 result found

  1. Show a log of query activity

    45 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    1 comment  ·  Suggestions  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    An error occurred while saving the comment
    Kenneth Fossum commented  · 

    The information provided in the top 10 expensive queries, is lacking. In our environments, we have multiple apps (or 'program_names') executing the same queries. Not being able to see which program_name that is executing the query is very frustrating.

    Then, you should add the possibility of pulling out (graphical) reports on the top 10 CPU consumers (program_name) over time. This is valuable info in environments where you are managing several different apps on the same database.

    You should add more information to the deadlock alerts.
    In environments where one app can execute multiple queries (often the same queries), from several hosts (often App servers), the info you provide now is not sufficient:

    Block occurred at: 3:09 AM
    Blocked process: App1
    Blocking process: App2
    Object blocked: Database (MyDB)

    Where is the SPID? App1 can have several connections to the DB executing the same queries, so I have no way of telling which process got blocked. You should provide something like this:

    The deadlock victim was spid <SPID> with application name 'App1' by user 'Username' on host 'AppServer'.
    Last query executed <Queryinfo>

    This info should not only be visible through the web interface, but also in the email alert.

    On the Analysis page you should add a blocking module where one can go and troubleshoot - real time and historically. Being able to go back and pinpoint lead blockers and victims, with relevant query info would be great.

    My background is DBA in environments with a lot of different clients doing a lot of weird things causing all sorts of issues. Having the necessary tool that quickly can provide the necessary info needed to "shut them up" would be great :). Obviously I have my scripts and queries that will pull out info I need, but a nicely drawn graph with some black on white facts will increase my chances of convincing them that I am right.

    Thank you for your time.

    Kenneth Fossum supported this idea  · 

Feedback and Knowledge Base

(thinking…)