Help urgent required for the Azure SQL DTU Calculator

Hi @Alan Macdonald

Good news, your file is very close, and the generic error tells us the headers passed validation. The failure is in parsing the rows, and your sample shows exactly why.

Two problems:

1. Column count mismatch. Your header has 6 names, but every data row has 7 fields (the timestamp plus 6 values). The header needs a first column for the timestamp, otherwise every value shifts one position and parsing dies.
2. The first data row is empty (just spaces between commas). Perfmon always writes a blank first sample, and the calculator can't parse spaces as numbers. Delete that row, and any others with empty fields.

Also drop the two "Bytes/sec" columns. The calculator only uses four counters, and fewer columns means fewer things to go wrong.

Here's your file corrected, using your own data:

Interval,% Processor Time,Disk Reads/sec,Disk Writes/sec,Log Bytes Write/sec
09/17/2026 08:41:39.225,0.00,0.00,2.99,0.00

Keep commas as separators, dots as decimals, no spaces after commas, and no blank cells anywhere. Then enter the server's core count on the site and calculate.

One thing to keep in mind: that calculator is a 2015 community tool and quite fragile. If it still complains after this fix, the modern route is the Azure SQL Migration extension in Azure Data Studio, which collects the same perf counters and gives you a SKU recommendation for both DTU and vCore, without any CSV wrangling.

If this helped, please click Accept Answer so others fighting the same upload can find it.

References: https://learn.microsoft.com/en-us/answers/questions/1458360/dtu-calc-gives-error-when-uploading-file https://learn.microsoft.com/en-us/azure/dms/ads-sku-recommend

Hi @Alan Macdonald

1. The first data row contains only blanks CSV 09/17/2026 08:41:38.218, , , , , Show more lines The calculator may not tolerate empty numeric values.
2. Your counters don't exactly match those listed by Microsoft The DTU Calculator documentation lists:
   • Processor - % Processor Time
   • Logical Disk - Disk Reads/sec
   • Logical Disk - Disk Writes/sec
   • Database - Log Bytes Write/sec (or Flushed/sec depending on collection method/version) [dtucalc.az...bsites.net], [mssqltips.com]
   Your file additionally contains:
   • Disk Read Bytes/sec
   • Disk Write Bytes/sec
   If you manually edited the headers, the parser may be expecting a very specific column layout.
3. The timestamp may need its own dedicated column header In PerfMon exports, the first column is typically a timestamp column. Your header row starts directly with a counter name, which may not match the format the calculator expects.
4. The calculator is quite old The site appears to have been designed around the output of the downloadable utility, not arbitrary CSV imports. [dtucalc.az...bsites.net]

My strongest recommendation is:

• Download and run the Command Line Utility or PowerShell Script from the DTU Calculator page.
• Upload the CSV it generates without modifying headers, separators, timestamps, or column order
  1. The first data row contains only blanks CSV 09/17/2026 08:41:38.218, , , , , Show more lines The calculator may not tolerate empty numeric values.
  2. Your counters don't exactly match those listed by Microsoft The DTU Calculator documentation lists:
     • Processor - % Processor Time
     • Logical Disk - Disk Reads/sec
     • Logical Disk - Disk Writes/sec
     • Database - Log Bytes Write/sec (or Flushed/sec depending on collection method/version) [dtucalc.az...bsites.net], [mssqltips.com]
     Your file additionally contains:
     • Disk Read Bytes/sec
     • Disk Write Bytes/sec
     If you manually edited the headers, the parser may be expecting a very specific column layout.
  3. The timestamp may need its own dedicated column header In PerfMon exports, the first column is typically a timestamp column. Your header row starts directly with a counter name, which may not match the format the calculator expects.
  4. The calculator is quite old The site appears to have been designed around the output of the downloadable utility, not arbitrary CSV imports. [dtucalc.az...bsites.net]
• My strongest recommendation is:
  • Download and run the Command Line Utility or PowerShell Script from the DTU Calculator page.
  • Upload the CSV it generates without modifying headers, separators, timestamps, or column order

Thanks.

Your CSV does appear to have formatting issues, as mentioned in the existing answers. However, before spending too much time getting the legacy DTU Calculator working, I would also consider how you want to size the Azure SQL Database.

The DTU Calculator is useful when you specifically want a DTU-based sizing estimate from an existing SQL Server workload. But DTU is a bundled measure of CPU, data I/O and log I/O, so the calculated DTU number is only an approximation of the required Azure SQL capacity.

For a new Azure SQL deployment, I would consider the vCore-based model as well. Rather than converting your server's CPU/IO counters directly into DTUs, you can collect the workload characteristics and evaluate the appropriate vCore service tier/size, then validate the choice with actual workload testing and Azure Monitor metrics.

If your primary objective is cost optimization, I would compare the available options rather than assume that the DTU number is the answer:

DTU-based Standard/Premium tier

vCore-based General Purpose

• vCore-based Serverless, if the workload has significant idle periods (NOT recommended for production workloads)

The cheapest option depends on the workload pattern, storage requirements, I/O characteristics and whether the database can benefit from serverless or other purchasing options.

So, if this is an existing production SQL Server that you are planning to migrate, I would use the collected performance data to establish the workload baseline, select a candidate Azure SQL SKU, and then validate it under representative peak workload. The DTU Calculator can still be used as one reference point, but I wouldn't treat its result as the definitive sizing answer.

Also, Microsoft provides guidance for moving between DTU and vCore models, including approximate DTU-to-vCore relationships, but those should be treated as estimates rather than exact performance equivalence. More info here https://learn.microsoft.com/en-us/azure/azure-sql/database/migrate-dtu-to-vcore?view=azuresql&tabs=azure-portal#migrate-a-database

References:

• DTU-based purchasing model: https://learn.microsoft.com/en-us/azure/azure-sql/database/service-tiers-dtu
• DTU to vCore migration guidance: https://learn.microsoft.com/en-us/azure/azure-sql/database/migrate-dtu-to-vcore
• Azure SQL purchasing models: https://learn.microsoft.com/en-us/azure/azure-sql/database/purchasing-models