Finding and fixing performance issues in SQL Server and the Azure SQL database requires understanding how database engine works and what can affect performance. People sometime make changes without finding the exact cause of the problem, which causes additional issues in the future. In this presentation, we will see some techniques you can apply to identify problems and solutions using Query Store technology, DMVs, SQL plan analysis, etc.
https://www.tarabica.org/Session/Details/78
4. Maintaining the instance
• Is your instance properly configured?
• TEMPDB, backups
• Are there any issues in databases?
• Tools
• First Responder Kit
• BPCHECK
6. Sp_blitz results
• Last good DBCC CHECKDB over 2 weeks old
• Many Plans for One Query
• 170 plans are present for a single query in the plan cache - meaning we
probably have parameterization issues.
• Cost threshold for parallelism
• Set to 5, its default value. Changing this sp_configure setting may reduce
CXPACKET waits.
• Max degree of parallelism
• Set to 0, its default value. Changing this sp_configure setting may reduce
CXPACKET waits.
7. DBCC CHECKDB
• Options
• NOINDEX - Specifies that intensive checks of nonclustered indexes for user tables should not be performed. This decreases
the overall execution time. NOINDEX does not affect system tables because integrity checks are always performed on system
table indexes.
• PHYSICAL_ONLY - Limits the checking to the integrity of the physical structure of the page and record headers and the
allocation consistency of the database. This check is designed to provide a small overhead check of the physical consistency
of the database, but it can also detect torn pages, checksum failures, and common hardware failures that can compromise a
user's data.
• TABLOCK - Causes DBCC CHECKDB to obtain locks instead of using an internal database snapshot. This includes a short-term
exclusive (X) lock on the database. TABLOCK will cause DBCC CHECKDB to run faster on a database under heavy load, but
decreases the concurrency available on the database while DBCC CHECKDB is running.
• DATA_PURITY - Causes DBCC CHECKDB to check the database for column values that are not valid or out-of-range. For
example, DBCC CHECKDB detects columns with date and time values that are larger than or less than the acceptable range
for the datetime data type; or decimal or approximate-numeric data type columns with scale or precision values that are not
valid.
• Repair options
• REPAIR_ALLOW_DATA_LOSS - Tries to repair all reported errors. These repairs can cause some data loss.
• REPAIR_REBUILD - Performs repairs that have no possibility of data loss. This can include quick repairs, such as repairing
missing rows in non-clustered indexes, and more time-consuming repairs, such as rebuilding an index.
8. SqlTiger Maintenance solution
• http://aka.ms/MaintenanceSolution
• Weekly DBCC CHECKDB on all online, read-write user databases below 1TB.
• Daily combination of DBCC CHECKALLOC, DBCC CHECKCATALOG, DBCC
CHECKTABLE (depending on VLDB setting) on all online, read-write user
databases over 1TB.
• Weekly execution of DBCC UPDATEUSAGE on all online, read-write
databases up to 4GB.
• Weekly execution of sp_createstats with indexonly.
• Weekly purge of all MSDB job history over 30d.
• Weekly purge of all maintenance plan text reports over 30d (if you are still
using package based maintenance plans).
11. Other tools
• sp_BlitzWho: What Queries are Running Now
• sp_BlitzCache: Most Resource-Intensive Queries
• sp_BlitzQueryStore: Most Resource-Intensive Queries in history
• sp_BlitzFirst: Real-Time Performance Advice
• More on
• https://github.com/microsoft/tigertoolbox
• https://github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit
17. Why is my query running slow?
• Not enough CPU?
• Not enough memory?
• Too much IO?
• TempDB spill?
• Cardinality estimate?
• Wrong plan?
• Waiting some other query (blocked)?
18. What to check?
• Is there CPU, memory, IO pressure?
• Why the plan is waiting? Is it blocked?
• Is the plan changed? Is it slower?
