Appendix C. Repository Database Management

Repository Web Application includes one particular component that is responsible for execution of several Sentinet scheduled and certificates management tasks. This component is automatically configured by the Repository Configuration Wizard as a Windows Service process.

Sentinet Agent Service Windows service — Figure 10. **Sentinet Agent Service** Windows service in the Windows Server **Services** MMC console.

One particular scheduled task, Purge Historical Data which Sentinet Agent Service executes, is responsible for the maintenance of the Repository database. Internally this task executes SQL scripts, which remove from the Sentinet Repository monitoring data older than the configured time interval. All other Repository data is stored indefinitely, because it creates negligible impact on the SQL Server database size. By default, the task, Purge Historical Data, is disabled because different organizations may have different policies on how long to retain historical monitoring and auditing data. Purge Historical Data task is commented in application’s configuration file Nevatech.Vsb.Agent.exe.config located in the root of the Sentinet installation folder.

To enable Repository database maintenance script:

Stop Sentinet Agent Service (not the Sentinet Agent Service (Sentinet Node)) from the Windows Server Services MMC console.

Uncomment Purge Historical Data section in the Nevatech.Vsb.Agent.exe.config file inside configuration section <nevatech.vsb.agent><tasks> as shown below. If needed, adjust parameters of this task as described in Appendix C. Repository Database Management.

<nevatech.vsb.agent>
<tasks saveOnExit="false">
…
<!-- Uncomment to enable and configure "Purge Historical Data" task -->
<add name="Purge Historical Data"
 type="Nevatech.Vsb.Agent.Tasks.PurgeDataTask, Nevatech.Vsb.Agent, 
 Version=6.0.0.0, Culture=neutral, PublicKeyToken=f35d905149dcb6c0">
  <purgeData xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://schemas.nevatech.com/sentinet/2011/02">
   <disposeTimeout>PT1M</disposeTimeout>
   <lastExecutionTime>2010-01-01T00:00:00-05:00</lastExecutionTime>
      <pattern i:type="hourlyPattern">
      <hours>24</hours>
      </pattern>
      <startTime>2000-01-01T03:00:00-05:00</startTime>
      <timerInterval>PT10M</timerInterval>
      <quotas>
          <activitiesDays>90</activitiesDays>
          <alertsDays>180</alertsDays>
          <changesMonths>0</changesMonths>
          <daysBasedMetricsYears>3</daysBasedMetricsYears>
          <hoursBasedMetricsMonths>3</hoursBasedMetricsMonths>
          <minutesBasedMetricsDays>7</minutesBasedMetricsDays>
          <recordsDays>90</recordsDays>
          <secondsBasedMetricsDays>3</secondsBasedMetricsDays>
          <transactionsDays>180</transactionsDays>
      </quotas>
  </purgeData>
</add>
…

Start Sentinet Agent Service windows service.

After Windows service is restarted, Sentinet Repository tables with large amounts of data will be periodically cleansed from "old" monitoring data. By default (as defined in the agent's configuration file), the data purge task will be executed every 24 hours at 3am EST time (T03:00:00-05:00 above). All configuration settings and task schedule can be changed in the configuration file.

Note

When Sentinet Agent Service is used to purge monitoring data, Sentinet automatically ensures that the load-balanced Repository servers execute Purge Historical Data task only once per scheduled time.

Alternatively, to purge historical data Database Administrators can use their own scripts (for example, SQL Server Agent’s Job(s)) by leveraging Sentinet Repository’s PurgeConfiguration and PurgeMonitoring SQL stored procedures (Sentinet Agent Service actually calls these two stored procedures when Purge Historical Data task is executed). The PurgeConfiguration and PurgeMonitoring procedures provide comments explaining its parameters (you can view these stored procedures’ code in your Sentinet Repository database (when single database configuration is used), or in the Sentinet Repository and Sentinet Monitoring databases when stand-alone Monitoring database configuration is used):

CREATE PROCEDURE PurgeConfiguration

-- Number of days to keep alerts in Alerts table

@AlertsDays int = 180,

-- Number of months to keep change auditing history

@ChangesMonths int = NULL

AS

...

CREATE PROCEDURE PurgeMonitoring

-- Number of days to keep transaction history

@TransactionsDays int = 180,

-- Number of days to keep recorded messages

@RecordsDays int = 90,

-- Number of days to keep system tracing history

@ActivitiesDays int = 90,

-- Number of days to keep SLA readings and violations defined

-- on the seconds-based time interval

@SecondsBasedMetricsDays int = 3,

-- Number of days to keep SLA readings and violations defined

-- on the minutes-based time interval

@MinutesBasedMetricsDays int = 7,

-- Number of months to keep SLA readings and violations defined

-- on the hours-based time interval

@HoursBasedMetricsMonths int = 3,

-- Number of years to keep SLA readings and violations defined

-- on the days-based time interval

@DaysBasedMetricsYears int = 3,

-- Number of days to keep alert history

@AlertsDays int = 180,

-- Number of months to keep change auditing history

@ChangesMonths int = NULL

AS

....

Appendix C. Repository Database Management

Note