Microsoft SQL ServerMonitoring and Profiling

Alireza Sadeghipour, Abouzar Noori24th Azar 1394

Microsoft SQL Server:Monitoring and Profiling• Performance Monitoring• Estimated Execution Plan• Indexing• Database Engine Tuning Advisor• SQL Server Profiling

Before MS SQL• Be aware of Select N+1 Problem when using EF lazy loading

• Log EF queries to find the problem:

Performance Monitoring

Resource Monitor

• First of all, check Resource Monitor and find sqlserver.exe

SQL Server Performance Counters

SQL Server Performance Counters

• Access Methods: Full Scans/sec• Buffer Manager: Buffer Cache Hit Ratio• Database: Transactions/sec• Database: Write Transactions/sec• General Statistics: User Connections

SQL Server Performance Counters (cont.)

• Locks: Lock Requests / Sec• Locks: Lock Waits / Sec• Locks: Lock Timeouts/sec• Locks: Number of Deadlocks/sec• SQL Statistics: Batch Requests/Sec• SQL Statistics: SQL Re-Compilations/sec• SQL Statistics: SQL Compilations/sec

Checking Execution Plan with SSMS

Actual Execution Plan in SQL Server

IO Statistics

• Copy message into http://www.statisticsparser.com/

• Logical reads is the most prominent counter

Indexing

Indexing

• Clustered index• Primary Key: Includes all columns

• Non-clustered index• One or more columns: Include as many columns as needed

• SELECT * FROM Device WHERE Serial = ‘0123456789’• Execution plan suggests to add:

• CREATE NONCLUSTERED INDEX (…) ON Device (Serial)

Indexing (cont.)

• A new index is a new copy of the table, containing “key columns” and “include columns”

• 4,516 logical read• SSMS hints:

• Logical reads decreases to 13

Indexing (cont.)

• Indexing helps• SELECT item using COLUMN = VALUE• COLUMN compare VALUE

• INDEX name on table (a, b)• Sort on a values, then b values in each bucket on a• Not good for

• SELECT id FROM table WHERE a > 100 and b = 200• SELECT id FROM table WHERE b = 200

• Good for• SELECT id FROM table WHERE b > 100 and a = 200• SELECT id FROM table WHERE a > 100

Investigating index usage (index_usage_stats)

• SELECT OBJECT_NAME(ddius.[object_id], ddius.database_id) AS [object_name] ,ddius.index_id ,ddius.user_seeks ,ddius.user_scans ,ddius.user_lookups ,ddius.user_seeks + ddius.user_scans + ddius.user_lookups

AS user_reads ,ddius.user_updates AS user_writes ,ddius.last_user_scan ,ddius.last_user_update

FROM sys.dm_db_index_usage_stats ddiusWHERE ddius.database_id > 4 -- filter out system tables

AND OBJECTPROPERTY(ddius.OBJECT_ID, 'IsUserTable') = 1AND ddius.index_id > 0 -- filter out heaps

ORDER BY ddius.user_scans DESC

Identify indexes that have never been accessed• SELECT OBJECT_NAME(i.[object_id]) AS [Table Name] , i.name FROM

sys.indexes AS I INNER JOIN sys.objects AS o ON i.[object_id] = o.[object_id] WHERE i.index_id NOT IN ( SELECT ddius.index_idFROM sys.dm_db_index_usage_stats AS ddiusWHERE ddius.[object_id] = i.[object_id] AND i.index_id = ddius.index_id AND database_id = DB_ID() ) AND o.[type] = 'U‘ ORDER BY OBJECT_NAME(i.[object_id]) ASC

Tune Your Indexing Strategy with SQL Server DMVs• https://www.simple-talk.com/sql/performance/tune-your-indexing-

strategy-with-sql-server-dmvs/

Database Engine Tuning Advisor

SQL Server Profiling

Some Columns in DB are Locked!

• Use sp_who2 and check BlkBy to see who has blocked whom• sp_whoisactive does it in a better way

SQL Server Profiler

Profile Using Execution Plan Cache

• Install sp_BlitzCache• Run: sp_blitzcache @sort_order = 'reads', @top = 20• You will find “Query Text”, “Total Reads”, “# Executions”, “Execution Plan”,

and some hints about how to improve performance of those queries.• It gave us a hint to add the following index:

• We thought indexing this table is not important since it is solely used in admin panel. But sp_BlitzCache tells that 20% of reads are related to this function.

Other Diagnosing Stored Procedures

• sp_BlitzIndex: Gives you hints on how much your indexes are used and suggestions for new indexes and their estimated effect

• sp_Blitz: Checks common health measures of your DB• sp_AskBrent: For 5 seconds watches your DB and gives you a report on:

• Blocking or long-running queries• If a backup, DBCC, or index maintenance job was running• Query wait statistics to figure out SQL Server’s current bottleneck• Perf. counters for CPU use, slow drive response times, or low Page Life Expectance

• You can create an agent job which runs sp_AskBrent every 15 minutes and appends the result to a table in your DB (more info)

• All these stored procedures are packaged in the ZIP file containing sp_BlitzCache

Evidences of Effect!

• # of lock requests / sec

• Avg. wait time

• CPU usage

Questions?