The SQL Server Performance Counters are the bread and butter for performance tuning exercise.

Using the performance counters, we can measure the current performance of the SQL Server basis on different criteria like Memory Information, Storage Information, CPU Information, Pages Information and other.

In this post, I am going to share some of the important Performance Counters for monitoring the SQL Server Performance.

Memory Information Counters:

Using this script, you can find the total amount of physical memory on the computer.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'Total Server Memory (KB)'
GO

Using this script, you can find different memory-related counters and its information.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name LIKE '%Memory%'
GO

Page Information Counters:

Using this script, you can find that how long pages stay in the buffer cache in seconds. If the value is more significant, SQL Server does not read from disk, and it serves the request from the buffer only.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'Page life expectancy'
GO

It shows the value of the number of physical database page reads that are issued per second.
Around 80 per second is normal, but if it is above, you may get a timeout in your application.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'page reads/sec'
GO

It shows the number of requests to find a page in the buffer pool.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'Page lookups/sec'
GO

Using below script, you can find a different page related counters and its information.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name LIKE '%Page%'
GO

User Connection Counter:

It shows the number of different users that are connected to the SQL Server.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'User Connections'
GO

Buffer Information Counters:

A greater value indicates that more significant number of requests are satisfied with the data cache and SQL Server is getting queries data from the memory instead of disk.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'Buffer Cache Hit Ratio'
GO

Using below script, You can find different information of the buffers.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name LIKE '%Buffer%'
GO

Batch Requests Counter:

It shows the number of batches per second, which are received by the SQL Server. If the number is high, more queries are executed in SQL Server.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'Batch Requests/Sec'
GO

SQL Compilation Counter:

It shows the number of execution plan compilation per second by the SQL Server. The compilation of execution plan is resource intensive, and it should be lesser than the number of batches per second.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'SQL Compilations/Sec'
GO

Block Transaction Information Counters:

This blocking related counters are essential for finding the different information of the blocked transactions so that as much as we can avoid the deadlock situation.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name LIKE '%block%'
GO

CPU Counters:

Using this script, You can find the usage of CPU in percentage.

SELECT *FROM sys.dm_os_performance_counters 
WHERE counter_name = 'CPU usage %'
GO

In the previous post, I shared T-SQL script to generate a DeadLock situation in SQL Server Database.
In this post, I am sharing different scripts to detect a Deadlock in SQL Server.

1. Using SP_LOCK, you can find the WAIT status for blocking sessions:

SP_LOCK

2. Using sys.sysprocesses:

SELECT * FROM sys.sysprocesses 
WHERE blocked > 0

3. Using common DMV:

SELECT 	
	der.blocking_session_id AS BlockingSessionID
	,dest.text AS BlockingStatement
FROM sys.dm_exec_connections AS sdec
INNER JOIN sys.dm_exec_requests AS der
    ON sdec.session_id = der.blocking_session_id
INNER JOIN sys.dm_os_waiting_tasks AS dowt
    ON der.session_id = dowt.session_id
CROSS APPLY sys.dm_exec_sql_text(sdec.most_recent_sql_handle) AS dest

4. Using sys.dm_tran_locks:

SELECT 
	request_session_id AS SPID 
	,DB_NAME(resource_database_id) AS DatabaseName
	,resource_type AS LockedResource
	,request_mode AS LockType
FROM sys.dm_tran_locks

5. Enable required trace flags to log DeadLock related information in Tracefile:

DBCC TRACEON (1204, -1)
DBCC TRACEON (1222, -1)

6. Count total number of DeadLock:

SELECT cntr_value AS TotalNumberOfDeadLocks
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Number of Deadlocks/sec'
   AND instance_name = '_Total'

7. Using Extended Events and below script to create Extended Event for monitoring the DeadLock:

CREATE EVENT SESSION [Deadlock_Monitor] ON SERVER 
ADD EVENT sqlos.scheduler_monitor_deadlock_ring_buffer_recorded,
ADD EVENT sqlserver.lock_deadlock,
ADD EVENT sqlserver.lock_deadlock_chain,
ADD EVENT sqlserver.xml_deadlock_report 
ADD TARGET package0.event_file(SET filename=N'C:\Temp\Deadlock_Monitor.xel')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)
GO

You can also use SSMS to create Extended Events for DeadLock, and you can monitor the live status of the server.

8. Using SQL Server Profiler:
SQL Server Profiler has three different events to capture a deadlock.

1.Deadlock graph
2.Lock: Deadlock
3.Lock: Deadlock Chain