Database Health Beta 9.3 Released Today
Today I had the pleasure of releasing Beta 9.3 of the Database Health Monitor. It has been a whole week since the last beta update,… Read More »Database Health Beta 9.3 Released Today
Blog posts relating to SQL Performance Tuning.
SQL Server tuning is the process of optimizing the database’s configuration, queries, and infrastructure to ensure the system runs as efficiently as possible. The goal is to reduce resource usage, increase query speed, and improve overall system responsiveness. Performance tuning involves analyzing server performance metrics, identifying bottlenecks, and implementing solutions that range from hardware upgrades to query rewriting. These optimizations are crucial for maintaining a smooth user experience and supporting business-critical applications.
A key aspect of performance tuning is query optimization. Poorly written SQL queries, missing indexes, or incorrect indexing strategies often lead to slow query execution. By using tools such as execution plans and SQL Profiler, DBAs can identify and correct inefficiencies in SQL code. Techniques like index tuning, query rewriting, and partitioning can drastically reduce query execution times. Regularly updating statistics and reorganizing or rebuilding indexes further enhances query performance and ensures accurate query plans.
Beyond queries, performance tuning also focuses on the SQL Server environment itself. Configuring server settings, adjusting memory allocation, and fine-tuning I/O operations play a significant role in optimizing database performance. Monitoring tools like Database Health Monitor (available at DatabaseHealth.com) provide insights into server health and potential issues. Stedman Solutions offers comprehensive SQL Server performance tuning services, combining years of experience with specialized tools to ensure your SQL Server environment performs at its peak. Learn more about our managed services at Stedman Solutions.
Today I had the pleasure of releasing Beta 9.3 of the Database Health Monitor. It has been a whole week since the last beta update,… Read More »Database Health Beta 9.3 Released Today
This week I will be attending and speaking at Vancouver DevTeach. This event taking place on December 2nd to 4th 2013 at the Vancouver Sheraton… Read More »Speaking at Vancouver DevTeach this week.
It has been a busy week at SteveStedman.com. Here is a quick summary of this weeks postings: June 14th – CTE Data Paging June 13th – Query… Read More »Week In Review – June 15th 2012
This is intended as a brief overview of indexing on SQL Server. Understanding and using indexes can lead to some major performance improvements. Non-Clustered Indexes… Read More »Index Overview – Clustered and Nonclustered
For more information on Common Table Expessions and performance, take a look at my book at Amazon.com: Common Table Expressions Joes 2 Pros®: A CTE Tutorial on Performance, Stored Procedures, Recursion, Nesting and the use of Multiple CTEs
There are many reasons that a Temp Table, Table Variable or Common Table Expression can be a good solution, but there is also a lot of confusion around these. Much of that confusion is around the use of TempDB.
For the purpose of this article I am going to use my standard Departments table from my CTE presentation. It is just a simple database to work with. Also, this is running on my local SQL Server with no other users connected.
USE [Master]; set statistics io off; IF EXISTS(SELECT name FROM sys.databases WHERE name = 'cte_demo') BEGIN ALTER DATABASE [cte_demo] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE [cte_demo]; END CREATE DATABASE [cte_demo]; GO USE [cte_demo]; -- create a table to use for CTE query demo CREATE TABLE [Departments] ( id int, --would normally be an INT IDENTITY department VARCHAR (200), parent int ); -- insert top level departments insert into [Departments] (id, department, parent) values (1, 'Camping', null); insert into [Departments] (id, department, parent) values (2, 'Cycle', null); insert into [Departments] (id, department, parent) values (3, 'Snowsports', null); insert into [Departments] (id, department, parent) values (4, 'Fitness', null); -- now some sub-departments for camping insert into [Departments] (id, department, parent) values (5, 'Tents', 1); insert into [Departments] (id, department, parent) values (6, 'Backpacks', 1); insert into [Departments] (id, department, parent) values (7, 'Sleeping Bags', 1); insert into [Departments] (id, department, parent) values (8, 'Cooking', 1); -- now some sub-departments for cycle insert into [Departments] (id, department, parent) values (9, 'Bikes', 2); insert into [Departments] (id, department, parent) values (10, 'Helmets', 2); insert into [Departments] (id, department, parent) values (11, 'Locks', 2); -- now some sub-departments for snowsports insert into [Departments] (id, department, parent) values (12, 'Ski', 3); insert into [Departments] (id, department, parent) values (13, 'Snowboard', 3); insert into [Departments] (id, department, parent) values (14, 'Snowshoe', 3); -- now some sub-departments for fitness insert into [Departments] (id, department, parent) values (15, 'Running', 4); insert into [Departments] (id, department, parent) values (16, 'Swimming', 4); insert into [Departments] (id, department, parent) values (17, 'Yoga', 4);
Then to compare the difference on the TempDB usage, I am going to use an under-documented function called fn_dblog() which shows you a list of the items that are written to the transaction log in different scenarios. I will also combine this with the CHECKPOINT command to clear the contents of the log for TempDB.
To try out out, run the following on a TEST or DEVELOPMENT database. Don’t run this on your production system.
USE TempDB; GO SELECT * FROM fn_dblog(null, null); CHECKPOINT; SELECT * FROM fn_dblog(null, null);
Then take a look at the output which will look something like this.
The first time you select from fn_dblog() you may be many rows. In my example fn_dblog() returned 171 rows, you may have many more. But after running CHECKPOINT you only get 3 rows, and those are the 3 rows that you will normally get after running CHECKPOINT.
Read More »Temp Table vs Table Variable vs CTE and the use of TEMPDB.
Now that Beta 2 of the Database Health Project is out, and people are using it, I am going to focus my attention on 2… Read More »Now that Database Health Beta 2 is out, whats next…
I often get asked “how do I find the contents of the SQL Server Plan Cache?” My first response is just use the Database… Read More »Finding the contents of the Plan Cache
Beta 2 of the Database Health Reports has just been released. The new Beta contains several bug fixes, and several new features. Here is a… Read More »Beta 2 of the Database Health Reports Released
Although clustered indexes are not required, and there are many cases where you should not use a clustered index, quite often clustered indexes can be… Read More »Finding tables that don’t have a clustered index.
In October last year I started work on the Database Health reports project. It started out as a series of SSRS reports that I released… Read More »It is finally here. Beta 1 of the Database Health Reports for SQL Server.