適用於 SAP NetWeaver 的 SQL Server Azure 虛擬機器 DBMS 部署
本檔涵蓋在 Azure IaaS 中部署適用于 SAP 工作負載的 SQL Server 時要考慮的幾個不同區域。 作為本檔的先決條件，您應該已閱讀 Azure 虛擬機器 SAP 工作負載的 DBMS 部署考慮檔 ，以及 Azure 上 SAP 工作負載 的其他指南 檔 。
重要
本檔的範圍是 SQL Server 上的 Windows 版本。 SAP 不支援任何 SAP 軟體的 Linux 版 SQL Server。 本檔未討論Microsoft Azure SQL 資料庫，這是 Microsoft Azure 平臺的平臺即服務供應專案。 本文中的討論是關於執行 SQL Server 產品，因為它以 Azure 虛擬機器內部部署而聞名，利用 Azure 的基礎結構即服務功能。 這兩個供應專案之間的資料庫功能和功能不同，不應彼此混合。 如需詳細資訊，請參閱 Azure SQL 資料庫 。
一般而言，您應該考慮使用最新的 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 金鑰保存庫整合 （Resource Manager）
- 檢查清單：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 資料庫：支援這類設定。 共用單一 SQL Server 實例共用共用資源的多個 SAP 資料庫考慮與內部部署相同。 請記住其他限制，例如可連結至特定 VM 類型的磁片數目。 或特定 VM 類型的網路和儲存體配額限制，以作為 Azure 中虛擬機器的詳細 大小。
適用于 SAP 相關 SQL Server 部署的 VM/VHD 結構建議
根據一般描述、作業系統、SQL Server 可執行檔，SAP 可執行檔應位於或安裝個別的 Azure 磁片。 一般而言，SAP NetWeaver 工作負載不會在高階使用大部分的 SQL Server 系統資料庫。 不過，SQL Server 的系統資料庫應該與個別 Azure 磁片上的其他 SQL Server 目錄一起。 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 大小。
注意
如果您將 tempdb 資料檔案和記錄檔放在您建立的 D：\ 磁片磁碟機上，您必須確定該資料夾在 VM 重新開機之後確實存在。 由於 VM 重新開機之後，可以重新初始化 D：\ 磁片磁碟機，因此可以抹除所有檔案和目錄結構。本文 記載 了在 SQL Server 服務啟動之前，在 D：\ 磁片磁碟機上重新建立最終目錄結構的可能性。
使用 SAP 資料庫執行 SQL Server 的 VM 組態，其中 tempdb 資料和 tempdb 記錄檔會放在 D：\ 磁片磁碟機上，而 Azure 進階儲存體 v1 或 v2 看起來會像這樣：
圖表顯示了簡單案例。 如 SAP 工作負載 的 Azure 虛擬機器 DBMS 部署考慮一文 所述，Azure 儲存體類型、數目和磁片大小取決於不同的因素。 但一般而言，我們建議：
- 針對較小的和中範圍部署，使用一個大型磁片區，其中包含 SQL Server 資料檔案。 此組態背後的原因是，如果 SQL Server 資料檔案沒有相同的可用空間，處理不同的 I/O 工作負載會比較容易。 而在大型部署中，特別是客戶使用異質資料庫移轉至 Azure 中的 SQL Server 的部署，我們會使用不同的磁片，然後將資料檔案分散到這些磁片。 這類架構只有在每個磁片具有相同數目的資料檔案時才會成功，所有資料檔案的大小都相同，而且大致具有相同的可用空間。
- 只要效能足夠好，請使用 tempdb 的 D：\drive。 如果 tempdb 位於 D：\ 磁片磁碟機上的整體工作負載受限於效能，您必須依照本文 的建議 ，將 tempdb 移至 Azure 進階儲存體 v1 或 v2 或 Ultra 磁片。
SQL Server 比例填滿機制會將讀取和寫入分散到所有資料檔案，只要所有 SQL Server 資料檔案的大小都相同，且具有相同的可用步調。 當讀取和寫入平均分散到所有可用的資料檔案時，SQL Server 上的 SAP 將會提供最佳效能。 如果資料庫的資料檔案太少或現有的資料檔案高度不平衡，則更正的最佳方法是 R3load 匯出和匯入。 R3load 匯出和匯入牽涉到停機時間，只有在有需要解決的明顯效能問題時，才應該完成。 如果資料檔的大小只有中度不同，請將所有資料檔案增加為相同的大小，而且 SQL Server 會隨著時間重新平衡資料。 如果設定追蹤旗標 1117，或使用 SQL Server 2016 或更高版本，SQL Server 就會自動增加資料檔案。
M 系列 VM 的特殊功能
對於 Azure M 系列 VM，相較于使用 Azure 寫入加速器時的 Azure 進階儲存體效能 v1，可以降低寫入交易記錄的延遲。 如果進階儲存體 v1 所提供的延遲限制 SAP 工作負載的延展性，則可以針對寫入加速器啟用儲存 SQL Server 交易記錄檔的磁片。 您可以在檔寫入加速器 中讀取詳細資料 。 Azure 寫入加速器不適用於 Azure 進階儲存體 v2 和 Ultra 磁片。 在這兩種情況下，延遲比 Azure 進階儲存體 v1 所提供的還要好。
格式化磁片
針對 SQL Server，適用於含有 SQL Server 資料和記錄檔之磁碟的 NTFS 區塊大小應該是 64 KB。 不需要格式化 D:\ 磁碟機。 此磁碟機已預先格式化。
若要避免還原或建立資料庫是透過零檔案的內容初始化資料檔案，請確定 SQL Server 服務執行的使用者內容具有使用者權限 執行磁片區維護工作 。 如需詳細資訊，請參閱 資料庫立即檔案初始化 。
SQL Server 2014 和更新版本 - 直接將資料庫檔案儲存在Azure Blob 儲存體
SQL Server 2014 和更新版本開啟將資料庫檔案直接儲存在 Azure Blob 存放區的可能性，而不需要其周圍 VHD 的「包裝函式」。 這項功能旨在解決 Azure 區塊儲存體的缺點。 這些天不建議使用此部署方法，而是選擇 Azure 進階儲存體 v1、進階儲存體 v2 或 Ultra 磁片。 視需求而定。
SQL Server 2014 緩衝集區擴充功能
SQL Server 2014 引進了稱為緩衝集區擴充功能的 新功能 。 雖然在 Azure 上的 SAP 工作負載下測試的功能並未改善裝載工作負載。 因此，不應該考慮它
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 版本。
- SQL Server 實例的定序，安裝在 Azure Marketplace 中提供的 VM 不是 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
如果結果不同，請停止任何部署，並調查安裝命令無法如預期般運作的原因。 將 SAP NetWeaver 應用程式部署到 SQL Server 實例，其 SQL Server 字碼頁與 NetWeaver 部署不支援不同的 SQL Server 字碼頁。
Azure 中 SAP 的 SQL Server 高可用性
在適用于 SAP 的 Azure IaaS 部署中使用 SQL Server，您可以新增數種不同的可能性來部署 DBMS 層高可用性。 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 中新的 DBMS 部署與內部部署進行中的生產系統。 在剪下時，生產環境會關閉，並確定最後和最新的交易記錄備份已傳輸到 Azure DBMS 部署。 然後，系統會針對生產環境開啟 Azure DBMS 部署。
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。 您應該將靜態 IP 位址指派給 AlwaysOn 組態中這些 VM 的網路介面（本文 將 說明定義靜態 IP 位址）。 相較于 DHCP 的靜態 IP 位址，在兩部 VM 可能停止的情況下，會防止指派新的 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)
注意
閱讀 Azure 虛擬機器 上的 SQL Server Always On 可用性群組簡介，您將瞭解 SQL Server 的 直接網路名稱 （DNN） 接聽程式 。 SQL Server 2019 CU8 引進這項新功能。 這項新功能會讓處理可用性群組接聽程式虛擬 IP 位址的 Azure 負載平衡器使用過時。
SQL Server Always On 是 Azure 中用於 SAP 工作負載部署的最常見高可用性和災害復原功能。 大部分的客戶都會使用 AlwaysOn 在單一 Azure 區域內的高可用性。 若部署受限於只有兩個節點，則您有兩個連線選擇：
- 使用可用性群組接聽程式。 您必須部署 Azure 負載平衡器，才能使用可用性群組接聽程式。
- 使用 SQL Server 2016 SP3、SQL Server 2017 CU 25 或 SQL Server 2019 CU8 或 Windows Server 2016 或更新版本的 SQL Server 版本，您可以使用 直接網路名稱 （DNN） 接聽程式 ，而不是 Azure 負載平衡器。 DNN 可免除我們 Azure 負載平衡器的需求。
使用 SQL Server 資料庫鏡像的連線參數，應該只考慮使用其他兩種方法的一輪調查問題。 在此情況下，您必須以兩個節點名稱命名的方式設定 SAP 應用程式的連線。 這類 SAP 端設定的確切詳細資料記載于 SAP 附注 #965908 。 使用此選項時，您就不需要設定可用性群組接聽程式。 而且，沒有 Azure 負載平衡器，而且可以調查這些元件的問題。 但回想一下，只有在您將可用性群組限制為跨越兩個實例時，此選項才有效。
大部分的客戶都使用 SQL Server Always On 功能，在 Azure 區域之間使用災害復原功能。 很多客戶也會使用從次要複本中執行備份的功能。
SQL Server 透明資料加密
許多客戶在 Azure 中部署其 SAP SQL Server 資料庫時，都會使用 SQL Server 透明資料加密 （TDE）。 SAP 完全支援 SQL Server TDE 功能（請參閱 SAP 附注 #1380493 ）。
套用 SQL Server TDE
如果您執行異質移轉，從另一個在內部部署環境中執行的 DBMS 移轉到在 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 提供金鑰保存庫 的服務 來儲存加密金鑰。 另一端的 SQL Server 提供連接器，以使用 Azure 金鑰保存庫作為 TDE 憑證的存放區。
針對 SQL Server TDE 清單使用 Azure 金鑰保存庫的詳細資料，例如：
- 為 Azure VM 上的 SQL Server 設定 Azure 金鑰保存庫整合（Resource Manager）。
- 更多客戶關於 SQL Server 透明資料加密 – TDE + Azure 金鑰保存庫 的問題。
重要
使用 SQL Server TDE，特別是搭配 Azure Key Vault，建議使用 SQL Server 2014、SQL Server 2016 和 SQL Server 2017 的最新修補程式。 原因是，根據客戶的意見反應、優化和修正已套用至程式碼。 例如，請檢查 KBA #4058175 。
最低部署組態
在本節中，我們建議針對 SAP 工作負載下不同資料庫大小設定的一組最小組態。 評估這些大小是否符合您的特定工作負載太困難。 在某些情況下，相較于資料庫大小，我們對於記憶體而言可能很慷慨。 另一方面，某些工作負載的磁片調整大小可能太低。 因此，這些組態應該視為它們是什麼。 它們是應該提供您起點的組態。 微調特定工作負載和成本效益需求的設定。
一些 SQL Server 實例的設定範例，其資料庫大小在 50 GB 到 250 GB 之間可能看起來像
| 組態 | DBMS VM | 註解 |
|---|---|---|
| VM 類型 | E4s_v3/v4/v5 （4 vCPU/32 GiB RAM） | |
| 加速網路 | Enable | |
| SQL Server 版本 | SQL Server 2019 或更新版本 | |
| 資料檔案的 # | 4 | |
| 記錄檔的 # | 1 | |
| 暫存資料檔案的 # | 自 SQL Server 2016 以來的 4 或預設值 | |
| 作業系統 | Windows Server 2019 或更新版本 | |
| 磁片匯總 | 如有需要，儲存空間 | |
| 檔案系統 | NTFS | |
| 格式化區塊大小 | 64 KB | |
| # 和資料磁片的類型 | 進階版儲存體 v1：2 x P10 （RAID0） 進階版儲存體 v2：2 x 150 GiB （RAID0） - 預設 IOPS 和輸送量 |
快取 = 進階儲存體 v1 的唯讀 |
| # 和記錄磁片的類型 | 進階版儲存體 v1：1 x P20 進階版儲存體 v2：1 x 128 GiB - 預設 IOPS 和輸送量 |
快取 = NONE |
| SQL Server 最大記憶體參數 | 90% 的實體 RAM | 假設單一實例 |
設定或資料庫大小介於 250 GB 到 750 GB 之間的小型 SQL Server 實例範例，例如較小的 SAP Business Suite 系統，看起來會像這樣
| 組態 | DBMS VM | 註解 |
|---|---|---|
| VM 類型 | E16s_v3/v4/v5 (16 vCPU/128 GiB RAM) | |
| 加速網路 | Enable | |
| SQL Server 版本 | SQL Server 2019 或更新版本 | |
| 資料檔案的 # | 8 | |
| 記錄檔的 # | 1 | |
| 暫存資料檔案的 # | 自 SQL Server 2016 起的 8 或預設值 | |
| 作業系統 | Windows Server 2019 或更新版本 | |
| 磁片匯總 | 如有需要，儲存空間 | |
| 檔案系統 | NTFS | |
| 格式化區塊大小 | 64 KB | |
| # 和資料磁片的類型 | 進階版儲存體 v1：4 x P20 （RAID0） 進階版儲存體 v2：4 x 100 GiB - 200 GiB （RAID0） - 預設 IOPS 和每個磁片 25 MB/秒的額外輸送量 |
快取 = 進階儲存體 v1 的唯讀 |
| # 和記錄磁片的類型 | 進階版儲存體 v1：1 x P20 進階版儲存體 v2：1 x 200 GiB - 預設 IOPS 和輸送量 |
快取 = NONE |
| SQL Server 最大記憶體參數 | 90% 的實體 RAM | 假設單一實例 |
中型 SQL Server 實例的設定範例，其資料庫大小在 750 GB 到 2,000 GB 之間，例如中型 SAP Business Suite 系統，看起來可能像這樣
| 組態 | DBMS VM | 註解 |
|---|---|---|
| VM 類型 | E64s_v3/v4/v5 （64 vCPU/432 GiB RAM） | |
| 加速網路 | Enable | |
| SQL Server 版本 | SQL Server 2019 或更新版本 | |
| 資料裝置的 # | 16 | |
| 記錄裝置的 # | 1 | |
| 暫存資料檔案的 # | 自 SQL Server 2016 起的 8 或預設值 | |
| 作業系統 | Windows Server 2019 或更新版本 | |
| 磁片匯總 | 如有需要，儲存空間 | |
| 檔案系統 | NTFS | |
| 格式化區塊大小 | 64 KB | |
| # 和資料磁片的類型 | 進階版儲存體 v1：4 x P30 （RAID0） 進階版儲存體 v2：4 x 250 GiB - 500 GiB - 加上每個磁片 2,000 IOPS 和 75 MB/秒輸送量 |
快取 = 進階儲存體 v1 的唯讀 |
| # 和記錄磁片的類型 | 進階版儲存體 v1：1 x P20 進階版儲存體 v2：1 x 400 GiB - 預設 IOPS 和 75MB/秒的額外輸送量 |
快取 = NONE |
| SQL Server 最大記憶體參數 | 90% 的實體 RAM | 假設單一實例 |
大型 SQL Server 實例的設定範例，其資料庫大小介於 2,000 GB 到 4,000 GB 之間，例如較大的 SAP Business Suite 系統，看起來會像這樣
| 組態 | DBMS VM | 註解 |
|---|---|---|
| VM 類型 | E96（d）s_v5 （96 vCPU/672 GiB RAM） | |
| 加速網路 | Enable | |
| SQL Server 版本 | SQL Server 2019 或更新版本 | |
| 資料裝置的 # | 24 | |
| 記錄裝置的 # | 1 | |
| 暫存資料檔案的 # | 自 SQL Server 2016 起的 8 或預設值 | |
| 作業系統 | Windows Server 2019 或更新版本 | |
| 磁片匯總 | 如有需要，儲存空間 | |
| 檔案系統 | NTFS | |
| 格式化區塊大小 | 64 KB | |
| # 和資料磁片的類型 | 進階版儲存體 v1：4 x P30 （RAID0） 進階版儲存體 v2：4 x 500 GiB - 800 GiB - 加上 2500 IOPS 和每個磁片 100 MB/秒輸送量 |
快取 = 進階儲存體 v1 的唯讀 |
| # 和記錄磁片的類型 | 進階版儲存體 v1：1 x P20 進階版儲存體 v2：1 x 400 GiB - 加上 1,000 IOPS 和 75MB/秒的額外輸送量 |
快取 = NONE |
| SQL Server 最大記憶體參數 | 90% 的實體 RAM | 假設單一實例 |
大型 SQL Server 實例的設定範例，其資料庫大小為 4 TB+，例如大型全域使用的 SAP Business Suite 系統，看起來可能像這樣
| 組態 | DBMS VM | 註解 |
|---|---|---|
| VM 類型 | M 系列 （1.0 到 4.0 TB RAM） | |
| 加速網路 | Enable | |
| SQL Server 版本 | SQL Server 2019 或更新版本 | |
| 資料裝置的 # | 32 | |
| 記錄裝置的 # | 1 | |
| 暫存資料檔案的 # | 自 SQL Server 2016 起的 8 或預設值 | |
| 作業系統 | Windows Server 2019 或更新版本 | |
| 磁片匯總 | 如有需要，儲存空間 | |
| 檔案系統 | NTFS | |
| 格式化區塊大小 | 64 KB | |
| # 和資料磁片的類型 | 進階版儲存體 v1：4+ x P40 （RAID0） 進階版儲存體 v2：4+ x 1,000 GiB - 4,000 GiB - 加上 4,500 IOPS 和 125 MB/秒的磁片輸送量 |
快取 = 進階儲存體 v1 的唯讀 |
| # 和記錄磁片的類型 | 進階版儲存體 v1：1 x P30 進階版儲存體 v2：1 x 500 GiB - 加上 2,000 IOPS 和 125 MB/秒輸送量 |
快取 = NONE |
| SQL Server 最大記憶體參數 | 95% 的實體 RAM | 假設單一實例 |
例如，此設定是 SQL Server 上 SAP Business Suite 的 DBMS VM 組態。 此 VM 裝載全球公司單一全球 SAP Business Suite 實例的 30TB 資料庫，年收入超過 2000 億美元，全職員工超過 20 萬。 該系統會執行所有財務處理、銷售和配送處理，以及更多不同領域的商務程式，包括北美洲工資。 從 2018 年初開始，系統會使用 Azure M 系列 VM 作為 DBMS VM，在 Azure 中執行。 由於高可用性，系統會將 Always on 與相同 Azure 區域另一個可用性區域中另一個同步複本和另一個 Azure 區域中的另一個非同步複本搭配使用。 NetWeaver 應用層部署在 Ev4 VM 中。
| 組態 | DBMS VM | 註解 |
|---|---|---|
| VM 類型 | M192dms_v2 （192 vCPU/4,196 GiB RAM） | |
| 加速網路 | 已啟用 | |
| SQL Server 版本 | SQL Server 2019 | |
| 資料檔案的 # | 32 | |
| 記錄檔的 # | 1 | |
| 暫存資料檔案的 # | 8 | |
| 作業系統 | Windows Server 2019 | |
| 磁片匯總 | 儲存空間 | |
| 檔案系統 | NTFS | |
| 格式化區塊大小 | 64 KB | |
| # 和資料磁片的類型 | 進階版儲存體 v1：16 x P40 | 快取 = 唯讀 |
| # 和記錄磁片的類型 | 進階版儲存體 v1：1 x P60 | 使用寫入加速器 |
| # 和 tempdb 磁片的類型 | 進階版儲存體 v1：1 x P30 | 沒有快取 |
| SQL Server 最大記憶體參數 | 95% 的實體 RAM |
Azure 上的 SAP 一般 SQL Server 摘要
本指南中有許多建議，建議您在規劃 Azure 部署之前多次閱讀。 不過，一般而言，請務必遵循 Azure 特定建議上的頂級 DBMS：
- 使用最新的 DBMS 版本，例如 SQL Server 2019，在 Azure 中具有最大優點。
- 請仔細規劃 Azure 中的 SAP 系統內容，以平衡資料檔案配置和 Azure 限制：
- 沒有太多磁片，但有足夠的磁片，以確保您可以連線到所需的 IOPS。
- 只有在您需要達到更高的輸送量時，才能跨磁片等量分割。
- 沒有太多磁片，但有足夠的磁片，以確保您可以連線到所需的 IOPS。
- 請勿安裝軟體，或將任何需要持續性的檔案放在 D：\ 磁片磁碟機上，因為它不是永久的，而且此磁片磁碟機上的任何專案都可以在 Windows 重新開機或 VM 重新開機時遺失。
- 使用 DBMS 廠商的 HA/DR 解決方案來複寫資料庫資料。
- 一律使用名稱解析，不要依賴 IP 位址。
- 使用 SQL Server TDE，套用最新的 SQL Server 修補程式。
- 請小心使用來自 Azure Marketplace 的 SQL Server 映射。 如果您使用 SQL Server 一個，您必須先變更實例定序，才能在它上安裝任何 SAP NetWeaver 系統。
- 如部署指南 所述 ，安裝和設定適用于 Azure 的 SAP 主機監視。
下一步
閱讀文章