Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

A DMV a Day – Day 15

The DMV for Day 15 is sys.dm_os_performance_counters, which is described by BOL as:

Returns a row per performance counter maintained by the server. For information about each performance counter, see Using SQL Server Objects.

This DMV is very useful, but can be very frustrating to work with. Depending on the value for cntr_type for a given row, you will have to go through some interesting gyrations to get meaningful information from this DMV. It is a replacement for the old sys.sysperfinfo from SQL Server 2000. This particular DMV works with SQL Server 2005, 2008, and 2008 R2. It requires VIEW SERVER STATE permission.

-- Recovery model, log reuse wait description, log file size, log usage size 
-- and compatibility level for all databases on instance
SELECT db.[name] AS [Database Name], db.recovery_model_desc AS [Recovery Model], 
db.log_reuse_wait_desc AS [Log Reuse Wait Description], 
ls.cntr_value AS [Log Size (KB)], lu.cntr_value AS [Log Used (KB)],
CAST(CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT)AS DECIMAL(18,2)) * 100 AS [Log Used %], 
db.[compatibility_level] AS [DB Compatibility Level], db.page_verify_option_desc AS [Page Verify Option]
FROM sys.databases AS db
INNER JOIN sys.dm_os_performance_counters AS lu 
ON db.name = lu.instance_name
INNER JOIN sys.dm_os_performance_counters AS ls 
ON db.name = ls.instance_name
WHERE lu.counter_name LIKE 'Log File(s) Used Size (KB)%' 
AND ls.counter_name LIKE 'Log File(s) Size (KB)%';

This particular query shows you the recovery model, log reuse wait description, transaction log size, log space used, % of log used, compatibility level, and page verify option for each database on the current SQL Server instance. This is all very valuable information that I like to gather when I am evaluating an unfamiliar database server. It it also useful from a monitoring perspective. For example, if your log reuse wait description is something unusual (such as ACTIVE_TRANSACTION), and your transaction log is 85% full, I would want some alarm bells to be going off…

Comments

Posted by Dukagjin Maloku on 15 April 2010

Yep, good info to see after running this script. I have a question about last column "Page Verify Option" I can see two values there, please little explanation about these values: CHECKSUM & TORN_PAGE_DETECTION?

Posted by Anonymous on 15 April 2010

Pingback from  Dew Drop – April 15, 2010 | Alvin Ashcraft's Morning Dew

Posted by Glenn Berry on 15 April 2010

CHECKSUM (which is the default for SQL Server 2005 and greater) does a better job of verifying the data during a read: Here is what BOL says about it.

When CHECKSUM is specified, the Database Engine calculates a checksum over the contents of the whole page and stores the value in the page header when a page is written to disk. When the page is read from disk, the checksum is recomputed and compared to the checksum value stored in the page header.

When TORN_PAGE_DETECTION is specified, a specific 2-bit pattern for each 512-byte sector in the 8-kilobyte (KB) database page is saved and stored in the database page header when the page is written to disk. When the page is read from disk, the torn bits stored in the page header are compared to the actual page sector information.

When NONE is specified, database page writes will not generate a CHECKSUM or TORN_PAGE_DETECTION value. SQL Server will not verify a checksum or torn page during a read even if a CHECKSUM or TORN_PAGE_DETECTION value is present in the page header.

Posted by Jason Brimhall on 15 April 2010

Thanks Glenn - this one is handy.  I have been using a similar script for my inventory process.

Half way done with the month.

Posted by Dukagjin Maloku on 15 April 2010

Glenn, thank you for the explanation.

Posted by arunkumarco on 16 January 2012

Thanks for your value added information

Leave a Comment

Please register or log in to leave a comment.