It is second to human nature to compare when given options. When I wrote about the blog, SQL SERVER – Playing with Backups and Compression, I did compare some of the space savings one will achieve when working with backups and compression. Though the space savings were significant, one of the blog readers wanted to understand how this would be on time? Is it faster or slower to do the same. I went about taking the same script and I collected the time taken. Let us learn about Performance Analysis of Backup to Azure.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
10 percent processed…. <<<removed for blog>>
70 percent processed.
Processed 53423 pages for database ‘AdventureWorks2016’, file ‘AdventureWorks2016CTP3_Log’ on file 1.
100 percent processed.
BACKUP DATABASE successfully processed 93263 pages in 1.970 seconds (369.852 MB/sec).
SQL Server Execution Times: CPU time = 140 ms, elapsed time = 2180 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
10 percent processed……<<<removed for blog>>
Processed 53425 pages for database ‘AdventureWorks2016’, file ‘AdventureWorks2016CTP3_Log’ on file 1.
100 percent processed.
BACKUP DATABASE successfully processed 93264 pages in 2.149 seconds (339.052 MB/sec).
SQL Server Execution Times: CPU time = 109 ms, elapsed time = 2373 ms.
As you can see, there is hardly any difference in time when it comes to working with backup compressions. Even for large backups, the difference is not significant that one can complain as a DBA.
On a completely different note, I wanted to play around and see what will be the effect when working with Azure based backup to the URL. I wanted to test the same database and check on performance. I used the following script:
On completion of the above script, the backup was taken to a blob as mentioned in the URL. I took the same performance metrics of time to check the difference. It is shown below:
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
10 percent processed.
20 percent processed….
100 percent processed.
BACKUP DATABASE successfully processed 93266 pages in 3.809 seconds (191.293 MB/sec).
SQL Server Execution Times:
CPU time = 94 ms, elapsed time = 4385 ms.
As you can see, in this case the time difference is significant for sure. This is fundamentally because as the backup is being taken, it must be streamed onto Azure in parallel. This increased network bandwidth usage is going to take a toll on the overall process. As you can see based on my small database, it is close to twice the time. In this case, I wanted to bring this to notice because as a DBA we need to make sure this has been considered when working with Backup to Azure.
I hope you enjoyed Performance Analysis. On a completely side note, I would love to learn if you are using the backup to Azure capability in your environments? How big are these databases? Do let me know via comments about your experience.
Reference: Pinal Dave (http://blog.sqlauthority.com)
First appeared on SQL SERVER – Performance Analysis of Backup to Azure