MOHAN SAHU

01

SQL SERVER -
PERFORMANCE
TROUBLESHOOTING
MOHAN SAHU
02

INTRODUCTION
Being a SQL server DBA, you will encounter
database performance issues. It's essential
to have a structured process and specific

U
tasks to address these problems. This post

H
SA
outlines steps to help you create a standard
N
A

troubleshooting guide. Questions about SQL

H
O

Server performance troubleshooting are

M

frequently asked. The purpose of these

questions is to evaluate your approach and
knowledge.
 MOHAN SAHU
03

THE REAL TRUTH

As a SQL Server DBA, resolving incidents in a
production environment can be one of the most
challenging tasks, especially with high concurrent
usage. Imagine working for e-com client and the

U
website becomes unresponsive, with error logs

H
SA
showing "Database Timeout" messages. Your phone
starts ringing, and you're surrounded by your
N
A

managers, and even the leadership. How you handle

H
O

this situation can either increase your value to the

M

company or lead to consequences.

We all have experienced similar situations with
positive outcomes, and I want to share learning from
these. If you haven't faced such a scenario yet, it's
best to be prepared for when it happens.
MOHAN SAHU
04

THE APPROACH
As the only person available on shift with no
access to senior resources, the first and most
important thing is to avoid panic. Staying calm is
crucial in such situations. We can't provide a

U
solution until we follow a systematic approach that

H
SA
will lead us to solution.
A
N
Check the below details on your database-
H
O

Check Blocking/deadlock?
M

Did we have any recent changes in application?

Do we have enough free space?
Do we have multiple application running?
 MOHAN SAHU
05

CHECK BLOCKING
Using sp_who2 System Stored Procedure-
This procedure provides information about current
SQL Server processes, including blocked processes.
EXEC sp_who2;
Using Dynamic Management Views (DMVs)-

U
H
sys.dm_exec_requests: This DMV shows details of all

SA
running processes, including blocked ones.
N
SELECT session_id, blocking_session_id, wait_type, wait_time,
A
wait_resource FROM sys.dm_exec_requests WHERE blocking_session_id <> 0;
H

Using sys.dm_os_waiting_tasks: This DMV returns

O

information about tasks waiting on resources.

M

SELECT session_id, wait_duration_ms, wait_type, blocking_session_id FROM

sys.dm_os_waiting_tasks WHERE blocking_session_id <> 0;
Using SQL Server Management Studio (SSMS):
Activity Monitor: Provides a graphical interface to
view blocked processes.
Reports: Built-in reports can show blocking
information
 MOHAN SAHU
06

CHECK DEADLOCK
Using SQL Server Profiler
Set up a trace to capture deadlock events. Look for
the Deadlock graph event to analyze deadlocks.

U
Using Extended Events

H
SA
Create an Extended Events session to capture
N
deadlock information.
A
H

CREATE EVENT SESSION [DeadlockCapture] ON SERVER ADD EVENT

O

sqlserver.lock_deadlock
M

ADD TARGET package0.event_file (SET filename =

N'deadlock_capture.xel')
WITH (STARTUP_STATE = ON);

Using Trace Flags-Enable trace flags to log

deadlock information to the SQL Server error log.
DBCC TRACEON(1222, -1);
 MOHAN SAHU

RECENT CHANGES
07

The application might have been altered without your

knowledge. Even if no stored procedures were changed,
modifications to the application's front end could cause
performance degradation.
If the application uses a framework like Hibernate
for data persistence, the SQL code might not be directly

U
H
written by the programmer. Additionally, a web developer

SA
could add ad-hoc queries within the code, making you
unaware of any changes to the SQL code.
N
A
Changes to the application's configuration file could
H

also occur without your knowledge. Parameters related to

O
M

the maximum number of simultaneous connections,

connection pooling, or enabling implicit transactions can
negatively impact database performance.
Additionally, you can check system tables, stored
procedures, functions, and Change Data Capture (CDC) for
any SQL changes. For application changes, review recent
application logs, version control systems, and deployment
records.
MOHAN SAHU
08

CHECK DISK SPACE

Another important consideration is checking the
available hard disk free space using the
xp_fixeddrives extended stored procedure.
However, even if the hard disk has plenty of free

U
H
space, the database auto-growth might be disabled

SA
or set to a percentage of the file size instead of a
N
A
fixed amount in megabytes. For instance, if your
H

database file is 2TB and the auto-growth is set to

O
M

10%, you would need 200GB of free space on the

drive for the file to grow. Check my article or post
about auto-growth settings for more details.

You can also check the disk IOPS for performance.

MOHAN SAHU
09

MULTI APPLICATION

This item should not be overlooked. If

the issue is with the server, all

U
H
applications running on it would likely
SA
experience problems. If this isn't the
N
A

case, then the problem lies with the

H
O

application rather than the database

M

engine, leading us to the next question.

MOHAN SAHU
10

NEXT ACTION
If the above approaches are not working or
have already been checked, we can proceed
to investigate further issues:

U
Check the SQL Server error log.

H
SA
Verify when the statistics were last
N
updated.
A
H
O

Determine if there are any linked servers

M

configured to fetch data.

Assess if there is slow disk access.
Check for fragmentation of data and log
files.
 CHECK ERRORLOG
MOHAN SAHU
11

Using SQL Server Management Studio (SSMS)- Open SSMS:

Connect to your SQL Server instance->Expand the
Management Node->View SQL Server Logs: Right-click on "SQL
Server Logs" and select "View SQL Server Log."
Using T-SQL-You can query the error log directly using T-SQL:
EXEC sp_readerrorlog;

U
To read a specific error log file, you can specify the log number:

H
SA
EXEC sp_readerrorlog 0, 1, 'Error';
Using SQL Server Configuration Manager-Open SQL Server
N
Configuration Manager->Navigate to the SQL Server Services-
A
H

>Right-click on SQL Server Instance->Select "Properties."->View

O

Error Log Path: Under the "Startup Parameters" tab, you can
M

find the path to the error log files.

1. Using File Explorer- Navigate to the Error Log Directory:
The default location is typically:C:\Program Files\Microsoft
SQL Server\MSSQL{version}.MSSQLSERVER\MSSQL\Log->
Open the Error Log File: Look for files named ERRORLOG
and open them with a text editor.
 MOHAN SAHU
12

CHECK STATISTICS
Using T-SQL- View Statistics for a Specific Table
Use the DBCC SHOW_STATISTICS command to view statistics for
a specific table and index.
DBCC SHOW_STATISTICS ('table_name', 'IndexName');
List All Statistics for a Table- Query the sys.stats and
sys.stats_columns system views to list all statistics for a table

U
H
SELECT s.name AS statistics_name, c.name AS column_name, s.auto_created,

SA
s.user_created,s.no_recompute,s.has_filter, s.filter_definition FROM sys.stats AS s
JOIN sys.stats_columns AS sc ON s.stats_id = sc.stats_id JOIN sys.columns AS c ON
sc.column_id = c.column_id AND sc.object_id = c.object_id WHERE s.object_id =
N
OBJECT_ID('TableName');
A

Check Last Updated Statis: Use sys.dm_db_stats_properties

H
O

dynamic management view to check when statistics were last

M

updated.
SELECT object_name(s.object_id) AS table_name,s.name AS
statistics_name,sp.last_updated,sp.rows,sp.rows_sampled,sp.steps,sp.unfiltered_ro
ws FROM sys.stats AS s CROSS APPLY sys.dm_db_stats_properties(s.object_id,
s.stats_id) AS sp WHERE s.object_id = OBJECT_ID('YourTableName');
Using SQL Server Management Studio (SSMS): Connect to your SQL
Server instance->Navigate to the database containing the table you
want to check->Find and expand the table.->Right-click on "Statistics"
and select "Properties" to view details about each statistic.
 MOHAN SAHU
13
CHECK REMAINING DETAILS
Check linked severs: Always consider this when
troubleshooting an application's database: you might be
searching for issues on the wrong server. The simplest way
to check for problems with a linked server is to look for
excessive OLEDB wait tasks in the Performance Dashboard

U
report.

H
SA
Check slow disk: For SQL Server to operate properly,
disk access time should be below 30 milliseconds. The
N
quickest way to check this is by opening the SSMS
A
H

Activity Monitor, expanding the Data File I/O view, and

O

sorting it by Response Time in descending order.

M

Check fragmentation: sys.dm_db_index_physical_stats

dynamic management view to check the fragmentation
percentage of indexes. Query the sys.indexes and
sys.dm_db_index_physical_stats views to list indexes
with fragmentation. If your log files are fragmented with a
high amount of VLF files you will see a lot of WRITELOG
wait types. This is very detrimental for performance.
MOHAN SAHU

FINAL THOUGHTS 14

Troubleshooting a slow-performing SQL

Server involves staying calm and following a
structured process. Here are key points:
Monitor Performance: Use tools like
DMVs and SSMS.

U
H
Identify Issues: Look for slow queries,

SA
blocking, and hardware limitations.
N
Optimize: Regularly update statistics,
A
H

optimize queries, and check for

O
M

fragmentation.
Collaborate: Work with other teams to
resolve issues.
By following these steps, you can effectively
manage and improve SQL Server
performance.
MOHAN SAHU
15

SAVE THIS POST IF

YOU FIND IT USEFUL