Removing the Monitoring Database

When the Database Health Reports run with historic monitoring, there is a database created to keep track of the data over time. If you need to remove that monitoring database or start over with the monitoring for some reason, here are the steps you need to take to remove the historic monitoring database.

Step 1 Remove the DBHealthHistory Database

DBHealth_Remove1

Here is the database script to remove the DBHealthHistory database:


USE [master]
GO

ALTER DATABASE [DBHealthHistory]
 SET SINGLE_USER
 WITH ROLLBACK IMMEDIATE;

GO
DROP DATABASE [DBHealthHistory]
GO

Step 2 Remove any Linked Servers Added by Database Health Reports

Right click on the linked server and choose delete.

DBHealth_Remove2

Step 3 Remove the Agent Job called DBHealthMonitor

Right click and choose delete.

DBHealth_Remove3

Step 4 Remove the monitoring database from the local configuration file

On the computer where you run the Database Health Monitor application, the historic monitoring database is stored in an xml file located in your documents directory called dbHealthSettings.xml.

First be sure the Database Health Monitor application is closed.

You can either just delete the dbHealthSettings.xml file and redo all your connections, or you can open the dbHealthSettings.xml file with notepad (or another text editor) and remove an rows that start with the xml tag <DBHealthHistory_.

If you are not comfortable editing the xml file the easiest may be to just delete it. The next time you start Database Health Monitor it will recreate the file and store your new settings.

 

Once all four steps have been completed, if you restart database Health Reports, you can set up a new connection and restart the monitoring process if you need to.


Enroll Today!
SteveStedman5
SteveStedman5
Steve and the team at Stedman Solutions are here for all your SQL Server needs.
Contact us today for your free 30 minute consultation..
We are ready to help!

4 Comments on “Removing the Monitoring Database

  1. I want to monitor Server1, saving Historic Database on Server2, installing DBH on Workstation.
    On Server2 already exists Historic Database from 2013 Evaluation, and evaluation software was installed on Server1.

    Now, I installed v2 on Workstation, still want to monitor Server1 saving HistDatabase on Server2.
    When I tried to configure Historic Database, specified Server2 in dialog but nothing appears. I repeated this several times (full access to Server2 Databases) with same result. Then I decided to click on “Use Current Instance” and finally got the green message, but I don’t want the Historic Database on Server1 (this affects performance on Server2?). So I used the script to remove HistDatabase on Server1 and repeated the process to use the already existing database on Server2 and now it works. In credentials, I specified “sa” on Server1. Iis this ok?

    How is the Historic Database collecting information? Do I need to keep Database Health running on Workstation?

    Thanks a lot!

    • Daniel,

      Yes it looks like you have done the right thing.

      There is a SQL Server agent job that gets installed on the monitoring server, it runs a stored procedure that connects in your case from Server2 to Server1, storing the data on Server2.

      You don’t need to keep Database Health Running on the workstation.

      Good luck and let me know if you have any questions.

      -Steve Stedman

  2. Greetings,

    I removed the DBHealthHistory database and the job from the SQL instance, but I still see login failed for both my account and the SQL service account to access the database. Is there any other alert is set which needs to be removed from the instance? Please advise

    • Sam – As long as the DBHealthHistory database and the DBHealthMonitor job is removed then there will be no more historic monitoring.

      I would look elsewhere for the failed logins. Usually when SQL Server logs failed logins, it logs the IP Address that the connection is coming from. That might be a good place to start.

      -Steve Stedman

Leave a Reply

Your email address will not be published. Required fields are marked *

*

To prove you are not a robot: *