Skip to content

Brian Shinkle

My feedback

1 result found

  1. 27 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  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)
    An error occurred while saving the comment
    Brian Shinkle commented  · 

    Agreed. Powershell scripts should surface the same data via $alertData that is visible in the UI.
    This would allow an alert to trigger a powershell script that would have access to enough data to resolve the problem.
    If the powershell script returns a specific value, this should trigger closure of the alert (as if the alert had been closed via the UI).

    Consider this example:
    1) Alert is raised for server waits. The alert is configured to trigger a user-created powershell script
    2) The alert passes $alertData to the script, which includes the following data points that are visible in the UI when viewing alerts:
    - query IDs for the top queries during the time window
    3) The powershell script can take action on the query in question, potentially by either killing the session, recompiling the procedure, or removing the plan from the procedure cache.
    4) Upon completion, the powershell script would return a code that instructs Redgate monitor to clear the alert.

    In this day and age of automation, DBAs should be provided the tools to build self-healing alert monitors. Without this, we would have to build our own monitoring code outside of Redgate Monitor.

    Brian Shinkle supported this idea  · 

Feedback and Knowledge Base