Kevin Holman's OpsMgr Blog : TSQL

Writing reports against RAW Perf data in the Data Warehouse

kevinhol — Fri, 24 Jul 2009 22:51:25 GMT

By default – our generic reports access *aggregated* data in the warehouse… either daily or hourly. These contain information like number of data points, avg, min, max, and std. deviation data. However, sometimes users will want access to the RAW, individual data points.

This is kept in the warehouse – and you can see it in the Perf.vPerfRaw view in the DB. By default – we keep this data for 10 days, and in general – we do NOT recommend that you extend this to any longer retention.

I will add these to my mega-query list… HERE

Here are some core query examples/samples for RAW perf data – which you can use to write reports against this output:

Raw data – core query:

select top 10 *
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

More selective of “interesting” output data:

select top 10 Path, FullName, ObjectName, CounterName, InstanceName, SampleValue, DateTime
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Scoped to a ComputerName (FQDN)

Scoped to a Counter:

Scoped to a Computer and Counter:

Ordered By DateTime:

Modified DateTime relative to Central Time zone:

select top 10 Path, FullName, ObjectName, CounterName, InstanceName, SampleValue, dateadd(hh,-5,DateTime) as 'DateTime (GMT-5)'
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId
WHERE CounterName = 'Private Bytes'
AND Path = 'OMDB.OPSMGR.NET'
Order By DateTime DESC

How to get all the possible optional data to modify these queries above, in a list:

Select Distinct Path
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Select Distinct Fullname
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Select Distinct ObjectName
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Select Distinct CounterName
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Select Distinct InstanceName
from Perf.vPerfRaw pvpr
inner join vManagedEntity vme on pvpr.ManagedEntityRowId = vme.ManagedEntityRowId
inner join vPerformanceRuleInstance vpri on pvpr.PerformanceRuleInstanceRowId = vpri.PerformanceRuleInstanceRowId
inner join vPerformanceRule vpr on vpr.RuleRowId = vpri.RuleRowId

Outages and Maintenance Report

kevinhol — Thu, 11 Jun 2009 07:48:00 GMT

This is a little report I put together on request.

This report will query the data warehouse, and show all the outages, and maintenance, for objects in specific groups.

The outages look at all the “Failed to Connect to Computer” alerts, and list the start and end time of the outage, based on the time the alert was created, to the time it was closed (assumes it is auto-closed by the agent coming back online)

The maintenance looks at the times that the Health Service Watcher objects are placed into maintenance mode.

There is a start and end time parameters for the report – and the report defaults to the last 30 days.

There is a group choice parameter – you should pick a group that contains Health Service Watcher objects.

It looks like this:

It is based on this query, which you can tune to meet your needs:

declare @startdate datetime
declare @enddate datetime
declare @computergroups varchar(50)
SET @startdate = '2009-06-01 00:00:00.000'
SET @enddate = getutcdate()
set @computergroups = 'Agent Managed Computer Group'

select
apv.ParameterValue as SystemName,
(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) as DownDateTime,
(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),arsv.StateSetDateTime)) as RestoredDateTime,
adv.CustomField2 as OutageType,
adv.CustomField3 as RootCause,
adv.CustomField4 as Reason,
adv.DBLastModifiedByUserId as UserID
FROM Alert.vAlert av
JOIN Alert.vAlertDetail adv on av.AlertGuid = adv.AlertGuid
JOIN Alert.vAlertResolutionState arsv on av.AlertGuid = arsv.AlertGuid
JOIN Alert.vAlertParameter apv on av.AlertGuid = apv.AlertGuid
WHERE AlertName = 'Failed to Connect to Computer'
AND arsv.ResolutionState = '255'
--AND adv.CustomField2 IS NOT NULL
AND (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) between @startdate and @enddate
and apv.ParameterValue IN (
SELECT vManagedEntity.DisplayName
FROM vManagedEntity
INNER JOIN vRelationship ON vManagedEntity.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId
INNER JOIN vManagedEntity AS ManagedEntity_1 ON vRelationship.SourceManagedEntityRowId = ManagedEntity_1.ManagedEntityRowId
WHERE (ManagedEntity_1.DisplayName = @computergroups)
)

UNION ALL

select
vme.displayname,
(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.StartDateTime)) as DownDateTime,
(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.EndDateTime)) as RestoredDateTime,
'OutageType' =
CASE
vmm.PlannedMaintenanceInd
WHEN '1' THEN 'Scheduled'
WHEN '0' THEN 'Unscheduled'
END,
'RootCause' =
CASE
vmmh.ReasonCode
WHEN '0' THEN 'Other (Planned)'
WHEN '1' THEN 'Other (Unplanned)'
WHEN '2' THEN 'Hardware: Maintenance (Planned)'
WHEN '3' THEN 'Hardware: Maintenance (Unplanned)'
WHEN '4' THEN 'Hardware: Installation (Planned)'
WHEN '5' THEN 'Hardware: Installation (Unplanned)'
WHEN '6' THEN 'Operating System: Reconfiguration (Planned)'
WHEN '7' THEN 'Operating System: Reconfiguration (Unplanned)'
WHEN '8' THEN 'Application: Maintenance (Planned)'
WHEN '9' THEN 'Application: Maintenance (Unplanned)'
WHEN '10' THEN 'Application: Installation (Planned)'
WHEN '11' THEN 'Application: Unresponsive'
WHEN '12' THEN 'Application: Unstable'
WHEN '13' THEN 'Security Issue'
WHEN '14' THEN 'Loss of network connectivity (Unplanned)'
END,
vmmh.Comment as Reason,
vmmh.userid as UserID
from vMaintenanceMode vmm
join vManagedEntity vme on vmm.managedentityrowid = vme.managedentityrowid
join vMaintenanceModeHistory vmmh on vmm.maintenancemoderowid = vmmh.maintenancemoderowid
where vme.FullName LIKE '%HealthServiceWatcher%'
and (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.StartDateTime)) between @startdate and @enddate
and vme.displayname IN (
SELECT vManagedEntity.DisplayName
FROM vManagedEntity
INNER JOIN vRelationship ON vManagedEntity.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId
INNER JOIN vManagedEntity AS ManagedEntity_1 ON vRelationship.SourceManagedEntityRowId = ManagedEntity_1.ManagedEntityRowId
WHERE (ManagedEntity_1.DisplayName = @computergroups)
)
ORDER BY DownDateTime

The report is attached below.

How to find a specific rule/monitor/discovery in the console – when all you have a more cryptic ID in an alert

kevinhol — Fri, 17 Apr 2009 21:58:53 GMT

Sometimes – we will get a Script Error alert, or WMI failure Alert, or some generic alert, telling us that some OTHER workflow had a problem. These alerts are NOT the root cause… the root cause is the workflow that gets referenced in the alert.

The problem is – the alert often gives us a Rule/Monitor/Discovery name, that is not the same as the Common Display Name of the workflow in the console.

For instance – in R2 – we have a new rule that will temporarily disable a workflow that is flooding alerts. Here is an example of that alert:

Alert generation was temporarily suspended due to too many alerts
A rule has generated 50 alerts in the last 60 seconds.
Usually, when a rule generates this many alerts, it is because the rule definition is misconfigured.
Please examine the rule for errors.
In order to avoid excessive load, this rule will be temporarily suspended until 2009-04-17T10:54:33.2764287+01:00.
Rule: Microsoft.SystemCenter.GenericNTPerfMapperModule.FailedExecution.Alert
Instance: rms.opsmgr.net
Instance ID: {1219134EC-909D-VA37-1E06-679DD505D87C}
Management Group: OPS

Now – to tune, or investigate – we need to understand the problem workflow. In this case… the problem workflow is a rule, “Microsoft.SystemCenter.GenericNTPerfMapperModule.FailedExecution.Alert”

To troubleshoot – we need to find this rule in the console. However – the console lets us search on the Display Name, not this more cryptic ID. So here is a query that will help us map that:

Rules:

SQL:

select DisplayName from ruleview
where name = 'Microsoft.SystemCenter.GenericNTPerfMapperModule.FailedExecution.Alert'

Command Shell:

(Get-Rule | Where {$_.name -match 'Microsoft.SystemCenter.GenericNTPerfMapperModule.FailedExecution.Alert'}).DisplayName

Discoveries:

SQL:

select DisplayName from DiscoveryView
where name = 'Microsoft.Office.Sharepoint.Server.2007.MOSS.Server.Discovery'

Command Shell:

(Get-Discovery| Where {$_.name -match 'Microsoft.Office.Sharepoint.Server.2007.MOSS.Server.Discovery'}).DisplayName

Monitors:

SQL:

select DisplayName from monitorview
where Name = 'MAPI_logon_failure.Monitor'

Command Shell:

(Get-Monitor| Where {$_.name -match 'MAPI_logon_failure.Monitor'}).DisplayName

This will output the common display name of the rule/monitor/discovery:

Generic Performance Mapper Module Execution Failure

With this – finding the rule is pretty easy. One of the fastest ways – is to use search:

Tools > Search, then paste in the workflow common display name we got from the query:

Then – click “View Knowledge” This will bring up the rule properties. From there – you can view the data source, and get a better idea of what the rule/monitor/discovery does, and how to troubleshoot it.

MOM 2005 SP1 - upgrading SQL server from 2000 to 2005

kevinhol — Sat, 02 Feb 2008 01:44:02 GMT

Upgrading from SQL 2000 to SQL 2005 to support MOM 2005 SP1:

1. Backup your MOM SQL server databases (OnePoint and Systemcenterreporting). Backup your Microsoft SQL Server Reporting Services databases.
2. Backup the SRS encryption key.

3. Stop the MOM Service on all management servers.

4. Upgrade the database servers and reporting servers to SQL 2005.

5. Upgrade the servers with SQL SP1 or greater.

6. Finally you need to apply the following hotfixes to complete the upgrade process:

File Name: MOM2005-SP1-KB913812-X86-ENU.MSI
Knowledge Base (KB) Article: KB913812
Overview: Unable to discover computers in AD after upgrading to .NET Framework 2.0

http://www.microsoft.com/downloads/details.aspx?FamilyId=F53F1EF3-A7A0-4C45-AEFC-7C1EC5DCCAA6&displaylang=en

This updates the following files. If your files are newer – no need to apply:

File name

File version

File size

Date

Time

Dasclient.dll

5.0.2911.31

101,104

08-Feb-2006