Here’s a short introduction video for how DiskSpd can be used to gather the necessary performance metrics without using the SQL Server Dynamic Management Views (DMVs). Having a way to support your case without using SQL Server to capture these metrics can sometimes be helpful.

Using DiskSpd on Your SQL Server System

Using Diskspd we can benchmark the raw performance of storage without relying on SQL Server DMV information at all. It’ll report on write and read latency, on sequential and random disk activity. It’s very granular and can be extremely insightful.

For example, I downloaded the utility and ran it on my laptop using the following command.

Diskspd.exe -b8K -d60 -h -L -o2 -t4 -r -w30 -c100M c:\test\io.dat > c:\test\output.txt

In this simple case, I set the block size to 8K using the -b parameter, ran the test for 60 seconds using the -d parameter, disabled hardware and software caching with the -h parameter, measured latency statistics with -L, used 2 overlapped IOs with the -o parameter, created 4 threads per target with the -t parameter, defined a workload of random input/output with the -r parameter, defined 30% of the I/O to be writes with the -w parameter, had the utility create a 100MB test file at c:\test\io.dat, and configured the output to be written to c:\test\output.txt.

There are many more parameters available in DiskSpd. For a complete list, run DiskSpd -?.

Interpreting the DiskSpd Disk I/O Performance Results

In my case, I received the following results in the c:\test\output.txt file. Keep in mind this is on a laptop and not a production SQL Server.

Command Line: Diskspd.exe -b8K -d60 -h -L -o2 -t4 -r -w30 -c100M c:\test\io.dat

Input parameters:

	timespan:   1
	-------------
	duration: 60s
	warm up time: 5s
	cool down time: 0s
	measuring latency
	random seed: 0
	path: 'c:\test\io.dat'
		think time: 0ms
		burst size: 0
		software cache disabled
		hardware write cache disabled, writethrough on
		performing mix test (read/write ratio: 70/30)
		block size: 8192
		using random I/O (alignment: 8192)
		number of outstanding I/O operations: 2
		thread stride size: 0
		threads per file: 4
		using I/O Completion Ports
		IO priority: normal

System information:

	computer name: DESKTOP-K9DJS56
	start time: 2020/10/21 14:18:01 UTC

Results for timespan 1:
*******************************************************************************

actual test time:	60.00s
thread count:		4
proc count:		4

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|  71.35%|  13.26%|   58.10%|  28.65%
   1|  66.28%|  15.23%|   51.04%|  33.72%
   2|  70.03%|  13.41%|   56.61%|  29.97%
   3|  68.15%|  17.73%|   50.42%|  31.85%
-------------------------------------------
avg.|  68.95%|  14.91%|   54.04%|  31.05%

Total IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      4398579712 |       536936 |      69.91 |    8948.90 |    0.222 |     0.740 | c:\test\io.dat (100MiB)
     1 |      4435599360 |       541455 |      70.50 |    9024.22 |    0.221 |     0.739 | c:\test\io.dat (100MiB)
     2 |      4433772544 |       541232 |      70.47 |    9020.50 |    0.221 |     0.757 | c:\test\io.dat (100MiB)
     3 |      4367548416 |       533148 |      69.42 |    8885.77 |    0.224 |     0.787 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:       17635500032 |      2152771 |     280.31 |   35879.40 |    0.222 |     0.756

Read IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      3077742592 |       375701 |      48.92 |    6261.66 |    0.256 |     0.669 | c:\test\io.dat (100MiB)
     1 |      3101097984 |       378552 |      49.29 |    6309.18 |    0.256 |     0.751 | c:\test\io.dat (100MiB)
     2 |      3100819456 |       378518 |      49.29 |    6308.61 |    0.254 |     0.606 | c:\test\io.dat (100MiB)
     3 |      3055476736 |       372983 |      48.57 |    6216.36 |    0.258 |     0.715 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:       12335136768 |      1505754 |     196.06 |   25095.82 |    0.256 |     0.688

Write IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1320837120 |       161235 |      20.99 |    2687.24 |    0.144 |     0.879 | c:\test\io.dat (100MiB)
     1 |      1334501376 |       162903 |      21.21 |    2715.04 |    0.139 |     0.702 | c:\test\io.dat (100MiB)
     2 |      1332953088 |       162714 |      21.19 |    2711.89 |    0.144 |     1.023 | c:\test\io.dat (100MiB)
     3 |      1312071680 |       160165 |      20.85 |    2669.41 |    0.145 |     0.928 | c:\test\io.dat (100MiB)
-----------------------------------------------------------------------------------------------------
total:        5300363264 |       647017 |      84.25 |   10783.58 |    0.143 |     0.890



total:
  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.054 |      0.048 |      0.048
   25th |      0.168 |      0.082 |      0.121
   50th |      0.192 |      0.095 |      0.174
   75th |      0.228 |      0.113 |      0.211
   90th |      0.337 |      0.144 |      0.292
   95th |      0.557 |      0.203 |      0.454
   99th |      1.394 |      0.610 |      1.291
3-nines |      4.510 |     14.778 |      5.577
4-nines |     18.031 |     26.059 |     20.629
5-nines |    117.426 |    117.574 |    117.502
6-nines |    153.091 |    161.708 |    153.091
7-nines |    162.048 |    161.708 |    162.048
8-nines |    162.048 |    161.708 |    162.048
9-nines |    162.048 |    161.708 |    162.048
    max |    162.048 |    161.708 |    162.048

As you can see, DiskSpd creates quite a bit of information.

According to the results, the test consumed nearly 69% of the CPU resources. As for the latency, the last section shows the metrics broken down by percentiles. In my case, the minimum read latency was 0.054 ms and the best write latency I could achieve was 0.048 ms. The maximum latencies were read 162.048 ms and write 161.708 ms. At the 50th percentile, my system had a read latency of 0.192 ms and a write latency of 0.095 ms.

This output can help you determine whether the disk I/O subsystem is delivering the performance your SQL Server system needs.

Where to Get DiskSpd

DiskSpd is available on GitHub, and additional how-to documentation can be found on TechNet here.

For other checks to run on your SQL Server system, check out Is My SQL Server Configured Properly.

The post Identify Disk I/O Performance Issues for Your SQL Server Using DiskSpd appeared first on The SERO Group.

What Is tempdb?

Let’s start with a very brief description of tempdb. When SQL Server needs some additional workspace to resolve a query, it uses a built-in system database called tempdb. A query may use tempdb for sorting operations, cursors, temporary tables, or even aggregation operations among other things. Since there is only one tempdb database for each SQL Server instance, it can be quite heavily used. 

By default, when you install SQL Server, one data file is created for the tempdb database. Having only one data file, however, can hinder SQL Server’s performance. The solitary file can become a bottleneck for queries that require tempdb. This is a pretty common issue, in fact, it made our Top 5 List. 

How Many tempdb Files Do You Need?

So, if the default value is likely not right for you, how many tempdb data files should you have? The answer is: it depends. According to Microsoft Support, the best approach is to create one tempdb data file per logical processor up to 8 data files.

If your system has more than 8 logical processors, start with 8 data files and monitor your server’s workload to determine if more data files would be beneficial. If you do find that an increase is warranted, add 4 data files at a time, but do not add more than the number of logical processors.

How Many tempdb Files Do You Have?

How many tempdb data files does your SQL Server have? A fairly straightforward query can answer the question. Open Management Studio and run the following query.

--tell me about my tempdb
SELECT
  f.name AS [file_name],
  CAST((f.size / 128.0) AS DECIMAL(15, 2)) AS [size_in_MB],
  CAST(f.size / 128.0 - CAST(FILEPROPERTY(f.name, 'SpaceUsed') AS INT) / 128.0 AS DECIMAL(15, 2)) AS [space_available_in_MB],
  [file_id] AS [file_id],
  ISNULL(fg.name, 'LOG') AS [filegroup_name],
  f.physical_name AS [physical_name]
FROM sys.master_files AS f
LEFT OUTER JOIN sys.data_spaces AS fg
  ON f.data_space_id = fg.data_space_id
WHERE f.database_id = 2;

You’ll notice that the results from the query above include the folder location for each tempdb file. That’s because file placement can also have a dramatic impact on performance and even reliability. But that’s another story.

For more information about tempdb, check out Microsoft’s SQL Docs. 

Want to know more about other configuration options that could affect performance and reliability? Check out Is My SQL Server Configured Properly?

[EDIT Oct 5, 2021] – Also see How to Configure SQL Server tempdb? for other tempdb configuration settings that can affect performance.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation.

Schedule a call with us to get started.

The post How Many tempdb Data Files Should My SQL Server Have? appeared first on The SERO Group.

Someone has started a database restore (or backup) using a T-SQL command. Now he wants to know how long the process will take to complete. He’s gone to the bathroom and even gotten a coffee, yet it’s still running. 

If he had used the WITH STATS option for either the BACKUP DATABASE or RESTORE DATABASE command, the percentage processed would have been piped to the Messages tab of Management Studio a little at a time. 10 percent processed. 20 percent processed. And so on as shown below.

BACKUP DATABASE wideworldimporters TO DISK = 'c:\temp\wwi.bak' WITH STATS;

SQL Server backup/restore information using DMVs

Still, that doesn’t provide an estimate of how long the process is likely to run. Fortunately, the Dynamic Management Views in SQL Server allow us to gather and report backup and restore estimates.

Here’s a script that I’ve found useful. It’s an amalgamation of a script I found on StackOverflow and my own handiwork. As always, this is for your reference only and no guarantees are implied.

SELECT SERVERPROPERTY('ServerName') AS [Instance],
   reqs.session_id,
   sess.login_name,
   reqs.command,
   CAST(reqs.percent_complete AS NUMERIC(10, 2)) AS [Percent Complete],
   CONVERT(VARCHAR(20), DATEADD(ms, reqs.estimated_completion_time, GETDATE()), 20) AS [Estimated Completion Time],
   CAST(reqs.total_elapsed_time / 60000.0 AS NUMERIC(10, 2)) AS [Elapsed Minutes],
   CAST(reqs.estimated_completion_time / 60000.0 AS NUMERIC(10, 2)) AS [Estimated Remaining Time in Minutes],
   CAST(reqs.estimated_completion_time / 3600000.0 AS NUMERIC(10, 2)) AS [Estimated Remaining Time in Hours],
   CAST((
     SELECT SUBSTRING(text, reqs.statement_start_offset/2,
                CASE
                WHEN reqs.statement_end_offset = -1
                THEN 1000
                ELSE(reqs.statement_end_offset-reqs.statement_start_offset)/2
                END)
     FROM sys.dm_exec_sql_text(sql_handle)) AS VARCHAR(1000)) AS [SQL]
FROM sys.dm_exec_requests AS reqs
 JOIN sys.dm_exec_sessions AS sess ON sess.session_id = reqs.session_id
WHERE command IN('RESTORE DATABASE', 'BACKUP DATABASE');

The script returns the following information:

• Instance Name
• Session Id 
• Login Name
• Command 
• Percent Complete
• Estimated Completion Time
• Elapsed Time in Minutes
• Estimated Remaining Time in Minutes
• Estimated Remaining Time in Hours
• The Complete Command Used to Start Backup/Restore
  

Since this script uses Dynamic Management Views, it won’t work on ancient versions of SQL Server. I’ve tested it on SQL Server 2008 R2 and forward on the Windows version. I haven’t tried it on SQL Server 2017 running on Linux. 

Hopefully, you’ll find this script handy. Here are a few more that you may find helpful.

• High Availability and Disaster Recovery in SQL Server
• How to Create SQL Server 2019 Failover Clustered Instances in Azure
• Vollgar: 6 Scripts to Help Review Your SQL Servers

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Script: How Long Until My SQL Server Backup/Restore Completes? appeared first on The SERO Group.