Page 1 of 2

MS-SQL Server VVizard

Posted: Fri Oct 03, 2014 2:54 pm
by rseiwert
I just ran the MS-SQL Wizard for the first time and the results were interesting. It seems to me that some of the default labels from the wizard may not be 100% correct. The Free Pages, Target Pages, and Stolen Pages don't appear to be per sec. The Lock Wait Average Time seems long, if the average wait time per SQL transaction was 45 mins I'm sure I would have heard about it.

Code: Select all

MSSQL Free Pages Per Sec	        CRITICAL: Free pages is 307476.0
MSSQL Lock Requests Per Sec	CRITICAL: Lock Requests / Sec is 32156.3680542/sec
MSSQL Database Pages Per Sec	CRITICAL: Database pages are 2972764.0
MSSQL Lock Wait Times	        CRITICAL: Lock Wait Average Time (ms) is 2729662.0ms
MSSQL Page Looks Per Sec	        CRITICAL: Page Lookups Per Second is 10225.0251363
MSSQL Target Pages Per Sec	CRITICAL: Target pages are 3670431.0
MSSQL Stolen Pages Per Sec	CRITICAL: Stolen pages are 354916.0
Running XI 2014 1.4 and MS SQL Server Wizard 1.8

Re: MS-SQL Server VVizard

Posted: Fri Oct 03, 2014 3:04 pm
by abrist
I wonder if the uom for transactions is actually microseconds . . . I will file a small bug fix request for the "per sec" labels. Could you run a lock wait time query and compare the result to the plugin output and post teh results?

EDIT: I filed a bug report for the text inconsistencies, let me know about the lock wait.

Re: MS-SQL Server VVizard

Posted: Fri Oct 03, 2014 3:42 pm
by rseiwert
This is indeed what the Lock Wait Average Time (ms) counter is reporting when queried directly on the server. That's something I'm going to need to look into.

Re: MS-SQL Server VVizard

Posted: Fri Oct 03, 2014 4:06 pm
by abrist
Alright, keep us posted. If it is just an issue with uom, that is a really easy fix. Otherwise, you may have problems with that sql server . . . .

Re: MS-SQL Server VVizard

Posted: Fri Oct 03, 2014 4:09 pm
by lmiltchev
That's something I'm going to need to look into.
Sure. I will keep this this topic open for a while.

Re: MS-SQL Server VVizard

Posted: Thu Oct 09, 2014 7:25 pm
by rseiwert
Been looking into this and the raw data returned by the wizard / check_mssql_server.py is incorrect. This seems to be true for other values as well. The counter SQLServer:Locks /Average Wait Time (ms)/_Total is of type PERF_AVERAGE_BULK. To get a valid number you need the PERF_LARGE_RAW_BASE which would be SQLServer:Locks /Average Wait Time Base/_Total. The PERF_AVERAGE_BULK counter value represents an average metric. The cntr_value is cumulative. The base value of type PERF_LARGE_RAW_BASE is used which is also cumulative. The value is obtained by first taking two samples of both the PERF_AVERAGE_BULK value A1 and A2 as well as the PERF_LARGE_RAW_BASE value B1 and B2. The difference between A1 and A2 and B1 and B2 are calculated. The final value is then calculated as the ratio of the differences, the difference of the PERF_AVERAGE_BULK difference by the delta of the PERF_LARGE_RAW_BASE.

http://blogs.msdn.com/b/psssql/archive/ ... nters.aspx
http://technet.microsoft.com/en-us/libr ... 90382.aspx
http://www.quest.com/backstage/images/p ... Poster.pdf


Just FYI so y'all know, you can close this

Re: MS-SQL Server VVizard

Posted: Fri Oct 10, 2014 10:27 am
by abrist
Thanks for the follow up. I have added your information above to the bug report and have linked to this thread.

Re: MS-SQL Server VVizard

Posted: Fri Jan 27, 2017 11:49 am
by rseiwert
BTW, just updated everything and ran the SQL wizard and still had the same issues. FYI. Bogus Values on many of the monitored values resulting from not cooking the counters. :-(

Re: MS-SQL Server VVizard

Posted: Fri Jan 27, 2017 12:01 pm
by dwhitfield
rseiwert wrote:BTW, just updated everything
Let's unpack this a bit.

What are the new versions of Windows, MS SQL, Linux, XI, and the component?

Do you have any new logs for us to look at?

Re: MS-SQL Server VVizard

Posted: Wed Feb 15, 2017 1:59 pm
by rseiwert
Sorry updated Nagios and the SQL Wizard. My SQL server is the same. The wizard seems to report the same bogus data as it always did.