This release focuses on Reports, the Windows Health Dashlet, and ongoing fixes and improvements to make your daily experience of VSM just a little bit better.

At a glance:

  • Windows System Health Dashlet now shows SQL Performance Counters
  • Reporting enhancements for Customer Equipment and Station Data reports

 

New Functionality

Windows System Health Dashlet

The Windows System Health Dashlet has been updated to include a new panel for SQL Performance Monitoring.

If you are running a SQL Server, and it’s being managed by VSM, all you need to do is tick this checkbox on the Dashlet stetting:

 

Data is shown over a 30 minute period via an expandable graph, and there are tooltips describing what the counters measure and how to interpret the results.

The dashlet shows the following metrics:

  • Buffer Hit Ratio: The buffer cache hit ratio counter shows the ratio of data pages found and read from the SQL Server cache. If the page doesn’t exist in the buffer cache, it has to be read from disk which downgrades performance.  It is recommended the Buffer cache hit ratio is 90% or higher. A low buffer cache hit ratio can be indicative of a memory problem.
  • Processes blocked: The processes blocked counter identifies the number of blocked processes. When one process is blocking another process, the blocked process cannot move forward with its execution plan until the resource that is causing it to wait is freed up.  Ideally there should not be any blocked processes, and any blocked processes should be investigated.
  • Page life expectancy: The page life expectancy counter measures how long pages stay in the buffer cache in seconds. The longer a page stays in memory, the more likely SQL Server will not need to read from disk to resolve a query. Generally, a page life expectancy below 5 minutes (300 s), can be indicative of memory problems.
  • Forwarded Records/sec: The number of rows per second fetched from a heap through forwarded record pointers. When this number is high, it means there were many updates to rows that no longer fit on the original page, and requires rebuilding the heap, or adding a clustered index to correct.   Ideally this number should be very close to 0.
  • Batch Requests/sec: Batch Requests/Sec measures the number of batches SQL Server is receiving per second and is an indicator of the amount of activity on the server. Sudden changes can reveal availability issues or unexpected changes in demand.
  • SQL Compilations/sec: The SQL Compilations/Sec measures the number of times SQL Server compiles an execution plan per second. Compiling an execution plan is a resource-intensive operation. Compilations/Sec should be compared with the number of Batch Requests/Sec to get an indication of whether or not complications might be hurting your performance. Ideally 90% of queries should be reused, so compilations/sec should be <10% of the batch requests/sec.

Reporting enhancements

  • The Customer Equipment report has been updated to include Equipment ID, as well as Site and Site ID. You’ll also find this information in the export CSV file.
  • The Station Data Report (under Configuration Manager) has been extended to include IP Office in the Equipment selection. The report is useful for those looking to understand how the various configuration screens that relate to the configuration of a station actually interrelate.

 

Fixes

  • Sometimes the OS Memory Report appeared to be missing data over a one month period.  This was caused with how data was referenced in the database and has now been fixed.
  • There was an issue for Business Partners when switching entities, not all thresholds were visible.  This has been fixed.
  • Previously, with the last release, clicking through on the table rows in the VQM Summary Dashlet, would take the user through to the old discontinued VQM page.  This has now been updated and fixed.
  • There was a logic error on the ACM System Health Summary Dashlet, when where the Primary CDR Link was down, and the secondary was Not Administrated, the dashlet flagged this as ‘grey’ instead of red.  This has been corrected.
  • There was an issue where for environments using multiple CMS’, data would not show up on VSM’s Call History Page.  This has been corrected.
  • There were some configuration issues with how SNMP v3 was managed for generic devices, which would sometimes cause the SNMP v3 username to be a mandatory field regardless of SNMP version, and was also incorrectly shown on the view details page for that equipment.  Both issues are now fixed.