適用於 SAP NetWeaver 的 SQL Server Azure 虛擬機器 DBMS 部署

本文介紹當我們在 Azure IaaS 部署 SAP 工作負載適用的 SQL Server 時，幾個要考量到的地方。 作為本檔的先決條件，請閱讀 Azure 上 SAP 工作負載的 Azure 虛擬機器 DBMS 部署考慮檔，以及 Azure 上 SAP 工作負載中的其他指南。

一般情況下，您應該考慮使用最新的 SQL Server 版本，以便在 Azure IaaS 中執行 SAP 工作負載。 最新的 SQL Server 版本能與部分的 Azure 服務和功能進行更好的整合。 或者功能上已有改進，能將 Azure IaaS 基礎結構的各項操作最佳化。

您可以在下列文章中找到在 Azure 虛擬機器 （VM） 中執行的 SQL Server 一般檔：

• Azure 虛擬機器上的 SQL Server (Windows)
• 使用 Windows SQL Server IaaS 代理程式擴充功能來自動化管理
• 在 Azure VM (資源管理員) 上設定 SQL Server 的 Azure Key Vault 整合
• 檢查清單：Azure VM 上的 SQL Server 最佳作法
• 儲存體：Azure VM 上的 SQL Server 效能最佳做法
• HADR 設定最佳作法 (Azure VM 上的 SQL Server)

在 Azure VM 文件中，於一般 SQL Server 中進行的所有內容和陳述並非都適用於 SAP 工作負載。 但是，文件對原則給人留下了良好的印象。 SAP 工作負載不支援的功能範例是FCI叢集的使用方式。

繼續進行前，應先了解關於 IaaS 中 SQL Server 的專屬資訊：

• SQL 版本支援：即使 SAP 附注 #1928533 指出最低支援的 SQL Server 版本是 SQL Server 2008 R2，Azure 上支援的 SQL Server 版本視窗也會隨著 SQL Server 生命週期而決定。 SQL Server 2012 延伸維護已於 2022 年年中結束。 因此，新部署系統的目前最低版本應該是 SQL Server 2014。 愈新愈好。 最新的 SQL Server 版本能與部分的 Azure 服務和功能進行更好的整合。 或者功能上已有改進，能將 Azure IaaS 基礎結構的各項操作最佳化。
• 使用來自 Azure Marketplace 的映像︰部署新 Microsoft Azure VM 的最快方式就是使用來自 Azure Marketplace 的映像。 Azure Marketplace 中的映像包含最新的 SQL Server 版本。 已經安裝 SQL Server 的映像不能立即用於 SAP NetWeaver 應用程式。 原因是預設 SQL Server 定序會安裝在這些映像內，而不是 SAP NetWeaver 系統所需的定序。 若要使用這類映像，請參閱使用來自 Microsoft Azure Marketplace 的 SQL Server 映像一章中記載的步驟。
• 單一 Azure VM 內的 SQL Server 多重執行個體支援：支援此部署方法。 但請注意資源限制，特別是所用 VM 類型的網路和儲存體頻寬。 如需詳細資訊，請參閱 Azure 中虛擬機器的大小一文。 這些配額限制可能會造成您無法比照內部部署的架構，以實作多重執行個體。 關於單一 VM 內共用可用資源的組態與干擾，所需考量與內部部署相同。
• 單一 VM 中單一 SQL Server 執行個體的多個 SAP 資料庫：支援這類組態。 關於多個 SAP 資料庫共用單一 SQL Server 執行個體的共用資源，所需考量與內部部署相同。 請考量其他限制，例如：特定 VM 類型可連結的磁碟數目。 或是特定 VM 類型的網路和儲存體配額限制，如 Azure 中的虛擬機器大小所述。

新的 M 系列 VM 和 SQL Server

Azure 在Mv3系列下發行了一些新的 M 系列 SKU 系列。 此系列中的某些 VM 類型不應該用於 SQL Server，包括 SQL Server 2022，而不停用 Windows Server 客體 OS 中的 SMT （Hyperthreading）。 理由是呈現至 Windows Server 客體 OS 的 NUMA 節點數目，其大於 64 個 vCPU，因此 SQL Server 無法容納。 藉由在 Windows Server 客體 OS 中停用 SMT，vCPU 數目就會減少。 因此，每個 NUMA 節點中的 vCPU 數目小於 64。 此處說明如何停用 SMT 的方式。 特定的 VM 型態如下：

• M176（d）s_3_v3 - 停用 SMT 或使用M176bds_4_v3或M176bds_4_v3作為替代方案
• M176（d）s_4_v3 - 停用 SMT 或使用 M176bds_4_v3 作為替代方案
• M624（d）s_12_v3 - 停用 SMT 或使用 M416ms_v2 作為替代方案
• M832（d）s_12_v3 - 停用 SMT 或使用 M416ms_v2 作為替代方案
• M832i（d）s_16_v3 - 停用 SMT 或使用 M416ms_v2 作為替代方案

適用於 SAP 相關之 SQL Server 部署的 VM/VHD 結構建議

根據基本說明，作業系統、SQL Server 可執行檔及 SAP 可執行檔應位於或安裝於不同的 Azure 磁碟。 一般而言，大部分的 SQL Server 系統資料庫不會在 SAP NetWeaver 工作負載的高階使用。 然而，SQL Server 系統資料庫應與其他 SQL Server 目錄一併位於不同 Azure 磁碟。 SQL Server tempdb 應位於非永續性磁碟機 D:\ 或不同磁碟。

• 使用所有 SAP 認證的 VM 類型（請參閱 SAP 附注 #1928533），tempdb 數據和記錄檔可以放在非持續 D：\ 磁碟驅動器上。
• 使用 SQL Server 版本時，SQL Server 只會安裝一個數據檔的 tempdb，建議您使用多個 tempdb 資料檔。 請注意，D:\ 磁碟機磁碟區的大小和功能會根據 VM 類型而有所不同。 如需不同 VM 的 D:\ 磁碟機正確大小，請參閱 Azure 中 Windows 虛擬機器的大小文章 \(機器翻譯\)。

這些組態會讓 tempdb 耗用更多空間；更重要的是，每秒 I/O 作業 (IOPS) 和儲存體頻寬也高於系統磁碟機的提供量。 非永續性磁碟機 D:\ 也能提供較佳的 I/O 延遲和輸送量。 若要判斷正確的 tempdb 大小，您可以在現有的系統上檢查 tempdb 大小。

執行含有 SAP 資料庫的 SQL Server 且 tempdb 資料和 tempdb 記錄檔放置於 D:\ 磁碟機和 Azure 進階儲存體 v1 或 v2 的 VM 組態應該像這樣︰

圖表顯示了簡單案例。 如適用於 SAP 工作負載的 Azure 虛擬機器 DBMS 部署考量所述，Azure 儲存體類型、磁碟數目和大小取決於不同因素。 不過總體而言，我們建議：

• 針對較小範圍和中範圍部署，使用一個大型磁碟區，其中包含 SQL Server 資料檔案。 此組態背後的原因是，如果 SQL Server 資料檔案沒有相同的可用空間，處理不同的 I/O 工作負載會比較容易。 而在大型部署中，特別是客戶使用異質性資料庫移轉至 Azure 中的 SQL Server 的部署，我們會使用不同的磁碟，然後將資料檔案分散到這些磁碟。 這類結構只有在每個磁碟具有相同數目的資料檔案、所有資料檔案的大小都相同，且大致具有相同的可用空間時才會成功。
• 只要效能夠好，tempdb 就使用 D:\磁碟機。 如果 tempdb 的整體工作負載在 D：\ 磁碟驅動器上的效能有限，您必須如本文建議，將 tempdb 移至 Azure 進階記憶體 v1 或 v2 或 Ultra 磁碟。

SQL Server 比例填充機制會讓所有資料檔案的讀取和寫入平均分佈，前提是所有 SQL Server 資料檔案的大小和可用空間皆相同。 當讀取和寫入平均分散到所有可用的數據檔時，SAP on SQL Server 可提供最佳效能。 若資料庫的現有資料檔案數目過少，或資料檔案高度不平衡，最佳修正方法則為 R3load 匯出和匯入。 R3load 匯出和匯入會涉及停機時間，如有必須解決的明顯效能問題方可進行。 如果數據檔的大小只有中度不同，請將所有數據檔增加為相同的大小，而 SQL Server 會隨著時間重新平衡數據。 如果已設定追蹤旗標 1117，或未使用 SQL Server 2016 或更高版本，SQL Server 就會自動成長數據檔，而不使用追蹤旗標。

M 系列 VM 的特殊情況

對於 Azure M 系列虛擬機器來說，使用 Azure 寫入加速器時，和 Azure 進階儲存體效能 v1 相比，可縮短寫入交易記錄的延遲時間。 如果進階記憶體 v1 提供的延遲限制 SAP 工作負載的延展性，則可以針對寫入加速器啟用儲存 SQL Server 事務歷史記錄檔的磁碟。 如需詳細資訊，請參閱寫入加速器文件。 Azure 寫入加速器不適用於 Azure 進階儲存體 v2 和 Ultra 磁碟。 在這兩種情況下，延遲比 Azure 進階儲存體 v1 所提供的還要好。 寫入加速器不支援進階 SSD v2。

將磁碟格式化

針對 SQL Server，適用於含有 SQL Server 資料和記錄檔之磁碟的 NTFS 區塊大小應該是 64 KB。 不需要格式化 D:\ 磁碟機。 此磁碟機已預先格式化。

若要避免還原或建立資料庫是透過歸零檔案內容來初始化資料檔案，請確定 SQL Server 服務執行的使用者內容具有使用者權權限執行磁碟區維護工作。 如需詳細資訊，請參閱資料庫檔案立即初始化。

SQL Server 2014 和較新的 SQL Server 版本 - 直接將資料庫檔案儲存在 Azure Blob 儲存體

SQL Server 2014 和更新版本開啟將資料庫檔案直接儲存在 Azure Blob 存放區的可能性，而不需要其周圍 VHD 的「包裝函式」。 這項功能旨在解決幾年前 Azure 區塊儲存體的缺點。 目前不建議使用此部署方法，而是選擇 Azure 進階儲存體 v1、進階儲存體 v2 或 Ultra 磁碟。 視需求而定。

SQL Server 的備份/復原考量

將 SQL Server 部署至 Azure，您必須檢閱備份架構。 即使系統不是生產系統，也必須定期備份 SQL Server SAP 資料庫。 由於 Azure 儲存體會保留三個映像，因此在補償儲存體損毀方面，備份現在已變得較不重要。 維護適當備份和復原計劃的優先順序原因對於時間點復原功能而言很重要，以補償邏輯/手動錯誤。 目標是使用備份將資料庫還原回特定時間點。 或者，使用 Azure 中的備份來植入另一個系統，並複製現有的資料庫備份。

有數種方式可以在 Azure 中備份和還原 SQL Server 資料庫。 若要取得最佳概觀和詳細資料，請閱讀文件 Azure VM 上 SQL Server 的備份與還原。 本文章描述幾個不同的可能性。

使用來自 Microsoft Azure Marketplace 的 SQL Server 映像

Microsoft提供 Azure Marketplace 中的 VM，其中包含 SQL Server 的版本。 至於需要 SQL Server 和 Windows 授權的 SAP 客戶，使用這些映像便可以利用已經安裝 SQL Server 來啟動 VM，這樣就不用取得授權了。 若要針對 SAP 使用這類映像，必須進行下列考量︰

• SQL Server 非評估版本的取得成本高於從 Azure Marketplace 部署的「僅限 Windows」VM。 若要比較價格，請參閱 Windows 虛擬機器定價和 SQL Server Enterprise 虛擬機器定價。
• 您只能使用 SAP 為其軟體支援的 SQL Server 版本。
• Azure Marketplace 所提供 VM 安裝的 SQL Server 執行個體定序，並不是 SAP NetWeaver 要求 SQL Server 執行個體執行的定序。 不過您可以利用下一節的指示來變更定序。

變更 Microsoft Windows/SQL Server VM 的 SQL Server 定序

由於 Azure Marketplace 中的 SQL Server 映射未設定為使用 SAP NetWeaver 應用程式所需的定序，因此必須在部署之後立即變更。 至於 SQL Server，一旦部署 VM 且系統管理員能夠登入已部署的 VM 之後，就能夠使用下列步驟來完成定序的變更：

• 以系統管理員身分開啟 Windows 命令視窗。
• 將目錄變更為 C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012。
• 執行命令︰Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
  • <local_admin_account_name> 帳戶，第一次透過資源庫部署 VM 時已定義為系統管理員帳戶。

此流程應該只需要幾分鐘。 若要確定此步驟最終是否會有正確的結果，請執行下列步驟：

• 開啟 SQL Server Management Studio。
• 開啟查詢視窗。
• 在 SQL Server master 資料庫中，執行 sp_helpsort 命令。

所需的結果應該看起來如下：

Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

若結果不同，請「停止」部署，並找出設定命令未依預期運作的原因。 針對 NetWeaver 部署，不支援將 SAP NetWeaver 應用程式部署到 SQL Server 字碼頁與上述提及之字碼頁不同的 SQL Server 執行個體。

SQL Server 在 Azure 中適用於 SAP 的高可用性

在適用於 SAP 的 Azure IaaS 部署中使用 SQL Server，您可以新增數種不同的可能性來部署資料庫層高可用性。 Azure 會針對使用不同 Azure 區塊儲存體、部署在 Azure 可用性設定組中的一對 VM，或跨 Azure 可用性區域部署的一組 VM，為單一 VM 提供不同的上線時間 SLA。 針對生產系統，我們預期您會在虛擬機擴展集內部署一對 VM，並在兩個可用性區域中彈性協調流程。 如需詳細資訊，請參閱 SAP 工作負載 的不同部署類型比較。 一部 VM 會執行使用中的 SQL Server 執行個體。 另一個 VM 會執行被動實例

使用 Windows 水平擴充檔案伺服器或 Azure 共用磁碟的 SQL Server 叢集

在 Windows Server 2016 中，Microsoft 引進了儲存空間直接存取。 根據儲存空間直接存取部署，基本上支援 SQL Server FCI 叢集。 Azure 也提供可用於 Windows 叢集的 Azure 共用磁碟。 SAP 工作負載不支援這些 HA 選項。

SQL Server 記錄傳送

其中一個高可用性功能是 SQL Server 記錄傳送。 若 HA 組態中的相關 VM 已有可行的名稱解析，便不會發生問題。 Azure 中的設定方式，如同內部部署的相關記錄傳送設定及記錄傳送原則。 如需 SQL Server 記錄傳送的詳細資料，請參閱文章關於記錄傳送 (SQL Server)。

SQL Server 記錄傳送功能根本很難用於 Azure 中來實現單一 Azure 區域中的高可用性。 但在下列案例中，SAP 客戶已成功以 Azure 進行記錄傳送：

• 從一個 Azure 區域到另一個 Azure 區域的嚴重損壞修復案例
• 從內部部署到 Azure 區域的災害復原設定
• 從內部部署至 Azure 的切換案例。 在這些情況下，記錄傳送是用來同步處理 Azure 中的新資料庫部署與內部部署進行中的生產系統。 在剪下時，生產環境會關閉，並確定最後和最新的事務歷史記錄備份已傳輸到 Azure 資料庫部署。 然後，系統會針對生產環境開啟 Azure 資料庫部署。

SQL Server Always On

由於 SAP 內部部署支援 Always On (參閱 SAP 附註 #1772688)，因此在 Azure 中搭配使用 SAP 時亦支援。 部署 SQL Server 可用性群組接聽程式有一些特殊考量事項 (不會與 Azure 可用性設定組混淆)。 因此，需要一些不同的安裝步驟。

以下是使用可用性群組接聽程式的一些考量︰

• 只能搭配 VM 客體 OS 為 Windows Server 2012 或更新版本來使用可用性群組接聽程式。 針對 Windows Server 2012，請確定已套用在 Windows Server 2008 R2 和以 Windows Server 2012 為基礎的 Microsoft Azure 虛擬機器上啟用 SQL Server 可用性群組接聽程式的更新。
• 針對 Windows Server 2008 R2，此修補程式不存在。 在此情況下，Always On 必須以與資料庫鏡像相同的方式使用。 藉由在連接字串中指定容錯移轉夥伴 (透過 SAP default.pfl 參數 dbs/mss/server 完成 - 請參閱 SAP 附註 #965908)。
• 使用可用性群組接聽程式時，您必須將資料庫 VM 連線到專用的 Load Balancer。 您應該在 Always On 組態中將靜態 IP 位址指派給這些 VM 的網路介面 (如需了解如何定義靜態 IP 位址，請參閱這篇文章)。 相較於 DHCP 的靜態 IP 位址，在兩部 VM 可能停止的情況下，系統會防止指派新的 IP 位址。
• 建置叢集需要指派特定 IP 位址的 WSFC 叢集組態時需要特殊的步驟，因為具有其目前功能的 Azure 會為叢集名稱指派與叢集建立所在的節點相同的 IP 位址。 此行為表示必須手動執行步驟，將不同的 IP 位址指派給該叢集。
• 可用性群組接聽程式將會透過 TCP/IP 端點建立於 Azure 中，其會指派給執行可用性群組之主要與次要複本的 VM。
• 可能需要使用 ACL 保護這些端點。

至於如何使用 Azure VM 中的 SQL Server 部署 Always On，請參閱以下文章：

• Azure 虛擬機器上的 SQL Server Always On 可用性群組簡介 \(機器翻譯\)。
• 在不同區域的 Azure 虛擬機器上設定 Always On 可用性群組 \(機器翻譯\)。
• 在 Azure 中設定 Always On 可用性群組的負載平衡器 \(機器翻譯\)。
• HADR 設定最佳作法 (Azure VM 上的 SQL Server)

SQL Server Always On 是 Azure for SAP 工作負載部署中，最常使用的高可用性和嚴重損壞修復功能。 大部分的客戶使用 Always On 來實現單一 Azure 區域內的高可用性。 若部署受限於只有兩個節點，則您有兩個連線選擇：

• 使用可用性群組接聽程式。 您必須部署 Azure 負載平衡器，才能使用可用性群組接聽程式。
• 有了 Windows Server 2016 以上版本的 SQL Server 2016 SP3、SQL Server 2017 CU 25 或 SQL Server 2019 CU8 或更新的 SQL Server 版本，您便可以使用直接網路名稱 (DNN) 接聽程式，而非 Azure Load Balancer。 DNN 可免除使用 Azure 負載平衡器的需求。

使用 SQL Server 資料庫鏡像的連線參數時，應該只考慮使用其他兩種方法的一連串調查問題。 在這種情況下，當設定 SAP 應用程式的連線時，這兩個節點名稱都要用到。 如需進一步了解如何設定這種的 SAP 端，請參閱 SAP 附註編號 965908。 使用這個選項時，您不需要設定可用性群組接聽程式。 在此情況下沒有 Azure Load Balancer，然後可以調查這些元件的問題。 但是請回想一下，只有當將可用性群組限制只能跨越兩個執行個體的時候，這個選項才有效。

多數客戶會使用 SQL Server Always On 功能，作為 Azure 區域間的嚴重災害復原功能。 很多客戶也會使用從次要複本中執行備份的功能。

SQL Server 透明資料加密

在 Azure 中部署 SAP SQL Server 資料庫時，許多客戶使用的是 SQL Server 透明資料加密 (TDE)。 SAP 完全支援 SQL Server TDE 功能 (請參閱 SAP 附註編號 1380493)。

套用 SQL Server TDE

如果您在從執行內部部署的另一個資料庫執行異質移轉至在 Azure 中執行的 Windows/SQL Server 時，您應該事先在 SQL Server 中建立空白的目標資料庫。 下一個步驟中，您可以針對這個空白資料庫套用 SQL Server TDE 功能。 您之所以會按照這種順序來執行，原因是空資料庫的加密程序會消耗相當長的時間。 然後在停機階段，SAP 匯入程序會將資料匯入加密的資料庫。 一個是產生額外負荷來匯入至加密的資料庫，另一個是在停機階段的匯出階段之後進行資料庫的加密，前者的影響時間沒有後者來得長。 當嘗試對資料庫上執行的 SAP 工作負載套用 TDE 時，會產生負面的體驗。 因此，建議完成 TDE 的部署時，不太需要特殊資料庫上的 SAP 工作負載。 從 SQL Server 2016 開始，您可以停止並繼續執行初始加密的 TDE 掃描。 文件透明資料加密 (TDE) 描述了命令和詳細資料。

將 SAP SQL Server 資料庫從內部部署移至 Azure 時，我們建議在您可以最快速套用加密的基礎結構進行測試。 針對此案例，請記住以下事實：

• 您無法定義當您將資料加密套用至資料庫時，會用到多少個執行緒。 執行緒數目主要是取決於 SQL Server 資料和記錄檔分佈的磁碟區數目。 表示比較相異的磁碟區（驅動器號），平行處理線程越多，才能執行加密。 這種組態與先前的磁碟組態建議衝突，也就是指為 Azure VM 中的 SQL Server 資料庫檔案，建立一或少數幾個儲存體空間。 若組態使用數個磁碟區，則會有數個執行緒執行加密。 單一執行緒加密會讀取 64 KB 範圍，進行加密，並在交易記錄檔中寫入一筆記錄，以通知加密範圍。 如此一來，交易記錄檔上的負載就比較適中。
• 在 SQL Server 舊版本中，加密您的 SQL Server 資料庫時的備份壓縮效率不彰。 當您的計畫是加密內部部署的 SQL Server 資料庫，然後將備份複製到 Azure，以便在 Azure 中還原資料庫時，這種行為會演變成一種問題。 SQL Server 備份壓縮可以達到係數 4 的壓縮比。
• 從 SQL Server 2016 開始，SQL Server 引進了新的功能，可讓您以有效率的方式壓縮加密資料庫的備份。 如需詳細資訊，請參閱此部落格文章。

使用 Azure Key Vault

Azure 提供的 Key Vault 服務，可以儲存加密金鑰。 另一方面，SQL Server 也提供連接器，可使用 Azure Key Vault 作為 TDE 憑證的存放區。

以下是 SQL Server TDE 詳細的 Azure Key Vault 用途：

• 在 Azure VM (資源管理員) 上設定 SQL Server 的 Azure Key Vault 整合。
• 更多關於 SQL Server 透明資料加密的問題 – TDE + Azure Key Vault \(英文\)。

最小部署組態

在本節中，我們建議針對 SAP 工作負載下不同資料庫大小設定的一組最小組態。 評估這些大小是否符合您的特定工作負載太過困難。 在某些情況下，相較於資料庫大小，我們對於記憶體而言可能很寬鬆。 另一方面，某些工作負載的磁碟重設大小可能太低。 因此，這些組態應依原用途使用。 它們是應該提供您起點的組態。 微調特定工作負載和成本效益需求的組態。

資料庫大小介於 50 GB – 250 GB 之間的一些 SQL Server 執行個體組態範例，看起來可能像這樣

資料庫大小介於 250 GB 至 750 GB 之間的組態或小型 SQL Server 執行個體範例，例如較小型的 SAP 商務套件系統，看起來可能像這樣

資料庫大小介於 750 GB 至 2,000 GB 之間的組態或中型 SQL Server 執行個體範例，例如中型的 SAP 商務套件系統，看起來可能像這樣

資料庫大小介於 2,000 GB 到 4,000 GB 之間的組態或大型 SQL Server 執行個體範例，例如大型的 SAP 商務套件系統，看起來可能像這樣

資料庫大小為 4 TB 以上的大型 SQL Server 執行個體組態範例，例如全域使用的較大型 SAP 商務套件系統，看起來可能像這樣

例如，此設定是 SQL Server 上 SAP Business Suite 的資料庫 VM 組態。 此 VM 裝載全球公司單一全球 SAP Business Suite 執行個體的 30TB 資料庫，年營收超過 2,000 億美元，且正職員工超過 20 萬人。 該系統會執行所有財務處理、銷售和配送處理，以及更多不同領域的商務程式，包括 北美洲 工資。 從 2018 年初開始，系統會使用 Azure M 系列 VM 作為資料庫 VM，在 Azure 中執行。 由於高可用性，系統會將 Always On 與相同 Azure 區域另一個可用性區域中的一個同步複本搭配使用。 另一個 Azure 區域中的另一個異步複本。 NetWeaver 應用層部署在最新的 D（a）/E（a） VM 系列上。

適用於 Azure 上的 SAP 的一般 SQL Server 摘要

本指南中提供許多建議，而我們建議您在規劃 Azure 部署之前，多次閱讀本指南。 不過，一般而言，請務必遵循 Azure 特定建議上的頂端 SQL Server：

1. 使用最新的 SQLServer 版本，例如 SQL Server 2022，在 Azure 中具有最大優點。
2. 在 Azure 中仔細規劃您的 SAP 系統架構，以平衡資料檔案配置和 Azure 限制︰
   • 不需要有太多磁碟，但必須足以確保您可以連線到所需的 IOPS。
     • 只有在您需要達到更高的輸送量時，才需在磁碟上劃分等量磁碟區。
3. 請勿安裝軟體，或將任何需要持續性的檔案放在 D：\ 磁碟驅動器上，因為它不是永久性。 此磁碟驅動器上的任何專案都可以在 Windows 重新啟動或 VM 重新啟動時遺失。
4. 使用 SQL Server AlwaysOn 解決方案來復寫資料庫數據。
5. 一律使用名稱解析，不要依賴 IP 位址。
6. 使用 SQL Server TDE，套用最新的 SQL Server 修補程式。
7. 請務必謹慎使用來自 Azure Marketplace 的 SQL Server 映像。 如果您使用 SQL Server 的映像，就必須變更執行個體定序，才能在其上安裝任何 SAP NetWeaver 系統。
8. 依照部署指南所述，安裝並設定適用於 Azure 的 SAP 主機監視功能。

下一步

閱讀文章

• 適用於 SAP 工作負載的 Azure 虛擬機器 DBMS 部署的考量因素