• What workload are you trying to work out a performance profile for?

    If it is only going to be a SELECT from a 9MB table then you are most of the way there. If it is to predict how your production system will work on the new servers then you are going down the wrong tack.

    If you want to work out how your production workload will perform then you need to run part of your production workload. SQL Server has Replay capabilities, so you can capture a SQL Profiler trace of your production system and replay the workload on your new system. While both the capture and replay are running, also run a PAL trace to capture IO statistics. You can then compare raw run times between the capture and the replay to get an idea of comparative run times, and compare the PAL output to see where bottlenecks exist in your old and new systems. If you find a bottleneck in your new system you think you can fix, then do so and rerun the workload.

    At some point you will get to a state where you cannot fix any further bottlenecks found by PAL. At this stage you can look at overall run times, response times, etc, and have meaningful data you can report to management about the new system performance. It is then up to the managers to decide if the new system is fit for use.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara