SQL Server storage - evaluate the number and types of read write operations for the existing deployment Training for SQL Server, one of the questions in Learning material says:
Before migrating on-premise SQL Server deployment (single server) to Azure VM, you need to evaluate &quot;number and types of read/write operations&quot; of the existing deployment
Which tool should you use ?
Options (pick correct one)

SQL Server Profiler trace using TSQL template
SQLIOSim
Database Engine Tuning Advisor
SQL Disk Usage Standard Report

Best probably would have been &quot;Performance Monitor&quot;, but its not in the list
I think correct one is 4) &quot;SQL Disk Usage Standard Report&quot;, but Learning Material says that correct  answer is 2) &quot;SQLIOSim&quot;
But, In my opinion, SQLIOSim is for testing the disk subsystem, it is not for measuring existing SQL Server instance metrics
Who is right - me, Learning material, or you (your option) ?
And what they mean by &quot;types&quot; of read/write operations ?
Who is right - me, Learning material, or you (your option ) ?

None of the options is correct.  The &quot;Disk Usage Standard Report&quot; is a database-level report that displays disk space utilization, not IO.


And what they mean by &quot;types&quot; of read/write operations ?

Judging that the &quot;correct&quot; answer was SQLIOsim, it probably meant sequential/random IO size that you can measure with SQLIO or Diskspd.
Here's what they're getting at:
When preparing for a SQL Server migration, a simple and effective migration plan is to provide equivalent-or-better resources in the new environment.  Alternatively you can attempt to measure the SQL Server resource utilization and base size the new environment off of that.
Of the two approaches the first is simpler and safer, and for a migration to an Azure VM, where you get to choose the VM family, size, and storage configuration, and where subsequent right-sizing is simple, that's the approach I would take.
Use Diskspd or SQLIO to measure the IO system, and use the system specs or standard benchmarks to measure the CPU and Memory capabilities, and spec the new enviornment from that.  Very simple, and can be done by a sysadmin, developer, or DBA.
The problem with this approach is that sometimes the existing deployment is unnecessarily fast, and results in an unnecessarily expensive new environment.  Then I would dig in with DBA and admin tools and adjust the estimate based on the actual utilization.
This happens frequently for storage where either:

There's a high-end shared SAN device providing storage for multiple servers.  You might measure a very high peak throughput on such a device, and would be unlikely to want to provide an Azure Disk configuration that matches it for each server.

SQL Server databases are stored on local NVMe flash storage and replicated with AlwaysON Availability Groups.  Storing your databases on the local flash drive is not supported for SQL Server on Azure VMs (although that's how Azure SQL Database Premium/Business Critical runs).


For that you would use something like the Azure SQL Database DTU Calculator, which will collect performance counters and create an estimate of the cpu and IO throughput required.
For IO I would start with:
Logical Disk - Avg. Disk Bytes/Read
Logical Disk - Avg. Disk Bytes/Write
Logical Disk - Avg. Disk sec/Read
Logical Disk - Avg. Disk sec/Write
Logical Disk - Disk Reads/sec
Logical Disk - Disk Writes/sec
Logical Disk - Disk Read Bytes/sec
Logical Disk - Disk Write Bytes/sec

Focusing mainly on the log and tempdb volumes, unless you see consistently significant data file read IO.  But you still have to imagine how the workload would behave if you reduced peak capacity in the new environment.  Do you really care if backup takes a little longer?  Sometimes yes, sometimes no.  Is the CPU maxed only during an overnight batch operation, and do you really care if that takes a bit longer?
The additional data collection and the need to interpret it with the understanding of how SQL Server works and in the context of the business needs of the application create significant additional complexity.