SQL Server 儲存 - 評估現有部署的讀寫操作的數量和類型
SQL Server 培訓，學習材料中的問題之一說：
**在將本地 SQL Server 部署（單伺服器）遷移到 Azure VM 之前，您需要評估現有部署的“讀/寫操作的數量和類型”
您應該使用哪個工具？**
選項（選擇正確的一項）
- 使用 TSQL 模板的 SQL Server Profiler 跟踪
- SQLIOSim
- 數據庫引擎優化顧問
- SQL 磁碟使用標準報告
最好的可能是
"Performance Monitor"，但它不在列表中，我認為正確的一個是 4)
"SQL Disk Usage Standard Report"，但學習材料說正確的答案是2) "SQLIOSim"但是，在我看來，
SQLIOSim是為了測試磁碟子系統，而不是為了測量現有的 SQL Server 實例指標誰是對的——我、學習材料，還是你（你的選擇）？
他們所說的讀/寫操作的“類型”是什麼意思？
誰是對的——我、學習材料，還是你（你的選擇）？
沒有一個選項是正確的。“磁碟使用標準報告”是數據庫級報告，顯示磁碟空間使用率，而不是 IO。
他們所說的讀/寫操作的“類型”是什麼意思？
判斷“正確”的答案是 SQLIOsim，它可能意味著您可以使用 SQLIO 或 Diskspd 測量的順序/隨機 IO 大小。
這就是他們的目的：
在準備 SQL Server 遷移時，一個簡單有效的遷移計劃是在新環境中提供同等或更好的資源。或者，您可以嘗試測量 SQL Server 資源使用率和新環境的基本大小。
在這兩種方法中，第一種更簡單、更安全，對於遷移到 Azure VM，您可以在其中選擇 VM 系列、大小和儲存配置，並且後續調整大小很簡單，這就是我將採用的方法.
使用 Diskspd 或 SQLIO 來衡量 IO 系統，並使用系統規格或標準基準來衡量 CPU 和記憶體能力，並以此來規範新環境。非常簡單，可由系統管理員、開發人員或 DBA 完成。
這種方法的問題在於，有時現有的部署速度過快，並導致新環境的成本過高。然後我會深入研究 DBA 和管理工具，並根據實際使用率調整估計值。
這種情況經常發生在以下儲存中：
- 有一個高端共享 SAN 設備為多台伺服器提供儲存。您可能會在此類設備上測量到非常高的峰值吞吐量，並且不太可能希望為每台伺服器提供與其匹配的 Azure 磁碟配置。
- SQL Server 數據庫儲存在本地 NVMe 快閃記憶體儲存上，並使用 AlwaysON 可用性組進行複制。Azure VM 上的 SQL Server 不支持將數據庫儲存在本地快閃記憶體驅動器上（儘管Azure SQL Database Premium/Business Critical就是這樣執行的）。
為此，您將使用Azure SQL Database DTU Calculator之類的東西，它將收集性能計數器並創建所需的 cpu 和 IO 吞吐量的估計值。
對於 IO，我將從：
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主要關注日誌和 tempdb 卷，除非您看到持續顯著的數據文件讀取 IO。但是您仍然必須想像如果您在新環境中降低峰值容量，工作負載會如何表現。你真的關心備份是否需要更長的時間嗎？有時是，有時不是。CPU 是否僅在夜間批處理操作期間達到最大值，您是否真的關心這是否需要更長的時間？
額外的數據收集以及在了解 SQL Server 的工作原理以及應用程序的業務需求的上下文中對其進行解釋的需要，會產生顯著的額外複雜性。
