享技水工坊 TechX Studio，資訊．音樂人同學會 –大家都想知道的如何將松柏 ERP Server 系統與 SQL Server 資料庫分散在不同的伺服器以減少負載提高效率(陸續優化)

參考整體架構

[ODBC]
DRIVER=SQL Server
UID=frank
Trusted_Connection=Yes
Database=松測
WSID=FRANK
CONNECT=1
SERVER=192.168.1.159 *** 資料庫指向主機的區網位置 ***
DBQ=C:\Program Files\印刷帳務管理系統(SQL)\WNSH.mdb
Site=S *** 指主機而不是工作站 ***

項目設定值說明
ERP Server192.168.1.156安裝印刷帳務管理系統(SQL) 主程式
SQL Server192.168.1.159真正的資料庫所在地
管理工具SSMS v18.11.1安裝在 **ERP Server** 上遠端管理
資料庫名稱松測這次的測試庫
資料夾SQL存放 ERP Server 相關代碼
DSNODBC 系統資料來源ERP 連線的橋樑

ERP Server 與 SQL Server 跨伺服器分流實務指南

ERP Server 與 SQL Server 分到不同的實體/虛擬伺服器上，以提高 ERP Server 系統速度！

先前工作-在 SQL Server 設定 SQL 共用夾，方便在 ERP Server 還原資料庫時，找得到要還原的 bak 檔

一、 為什麼要「分家」？

這在資料量少、上線人數少的草創期確實行得通，但隨著公司擴大、交易單據積少成多，就會開始影響效能

  1. 記憶體爭奪戰（RAM Starvation）： SQL Server 是一個對記憶體「要求」的軟體，預設情況下，只要給它實體記憶體，它就會盡可能吃滿以快取資料頁（Data Pages），此時，ERP 系統主程式要在伺服器上處理邏輯計算、產生報表時，就會發現系統根本沒有剩餘的 RAM 可用，只能一直讀寫硬碟 swap 空間，導致整體效能慘不忍睹。
  2. CPU 資源搶占（CPU Bottleneck）： ERP 系統要處理商業邏輯（計算成本、應收帳款、庫存核算），SQL Server 要處理複雜的查詢（Index Scan、Join、Sort），當幾十個使用者同時點擊大型報表，伺服器的 CPU 執行緒會在應用程式與資料庫進程之間頻繁進行上下文切換（Context Switching），大幅衰減運算效率。
  3. 單點故障風險（Single Point of Failure, SPOF）： 一旦這台「單獨」伺服器硬體故障（如主機板燒毀或 POWER 損壞），企業的應用程式與關鍵業務資料庫將一瞬間同時陷入癱瘓，完全沒有緩衝空間。

讓 ERP 專心處理商業邏輯與介面運算，讓 SQL Server 專心做資料查詢與交易寫入，「各司其職，分而治之」，才是打造高可用性、高效能企業 IT 環境的不二法門！讓 SQL Server 在本機 ERP Server(192.168.1.156) 完成遠端 (192.168.1.159) 還原

二、 本次實戰架構與環境設定

1. 網路與伺服器節點配置

  • ERP 應用伺服器（ERP Server）：
    • IP 位址： 192.168.1.156
    • 角色： 執行 ERP 主系統、客戶端對接、SQL Server Management Studio (SSMS) 管理介面。
  • 資料庫伺服器（SQL Server）：
    • IP 位址： 192.168.1.159
    • 角色： 專門運行 MS SQL Server 資料庫引擎，存放業務資料。
  • 預計管理之資料庫名稱： 松測
  • SQL Server 存放 ERP 相關代碼與工作目錄： SQL(192.168.1.159)

2. 管理工具與設定檔細節

  • 管理工具： SQL Server Management Studio (SSMS) V18.11.1（安裝於 ERP Server 192.168.1.156）。
  • ODBC 連結檔 (DSN 設定)：

有了這張清晰的地圖，接下來我們就進入最核心的實作階段！

[ODBC]
DRIVER=SQL Server
UID=frank
Trusted_Connection=Yes
Database=松測
WSID=FRANK
CONNECT=1
SERVER=192.168.1.159
DBQ=C:\Program Files\印刷帳務管理系統(SQL)\WNSH.mdb
Site=S

三、 第一關：通訊管道打通——跨伺服器連線與防火牆設定

既然把 ERP 與 SQL Server 放在兩台不同的伺服器（192.168.1.156 與 192.168.1.159），第一步就是要確保兩者之間的網路通暢，不會被中間的防火牆或 SQL 預設安全機制攔截。

步驟 1：開放 SQL Server (192.168.1.159) 的 TCP/IP 協定

MS SQL Server 在預設安裝時，為了安全性考量，往往會關閉遠端 TCP/IP 連線。

  1. 登入 SQL Server 伺服器 (192.168.1.159)。
  2. 開啟 SQL Server 組態管理員（SQL Server Configuration Manager）。
  3. 展開 SQL Server 網路組態 -> 點擊 MSSQLSERVER 的協定。
  4. 找到 TCP/IP 項目，如果狀態為「已停用」，請點右鍵選擇 【啟用】。
  5. 點擊 TCP/IP 右鍵【內容】，切換到 【IP 位址】 頁籤，拉到最底部的 IPAll，確認 TCP 連接埠 設定為預設的 1433。
  6. 關鍵步驟： 重啟 SQL Server 服務（SQL Server Services -> SQL Server (MSSQLSERVER) -> 右鍵【重新啟動】），設定才會生效！

步驟 2：配置 Windows 防火牆規則

許多 IT 人員折騰半天連不上，80% 是被 Windows 防火牆硬生生檔了下來。

在 SQL Server 伺服器 (192.168.1.159) 的 Windows 防火牆中：

  1. 新增輸入規則（Inbound Rule）。
  2. 選擇 【連接埠 (Port)】，指定 TCP 1433，允許連線。
  3. 如果有使用 SQL Server Browser 服務或動態連接埠，建議另外開放 UDP 1434。
  4. 在 ERP Server (192.168.1.156) 開啟 Command Prompt (cmd)，輸入：DOStelnet 192.168.1.159 1433 如果畫面變黑或顯示連線成功，恭喜你，通訊大門已經順利開啟！

(Port 1433) 是 SQL Server 預設通訊埠

四、 第二關：DSN 檔案剖析與 ODBC 跨機連線設定

在我們的案例中，ERP 系統使用了一個 DSN (Data Source Name) 設定檔來尋找資料庫，讓我們來仔細剖析這段關鍵的 DSN 內容：

[ODBC]
DRIVER=SQL Server
UID=frank
Trusted_Connection=Yes
Database=松測
WSID=FRANK
CONNECT=1
SERVER=192.168.1.159
DBQ=C:\Program Files\印刷帳務管理系統(SQL)\WNSH.mdb
Site=S

關鍵參數深度解讀：

  • SERVER=192.168.1.159： 這是分散式架構的靈魂！它告訴 ERP 系統，不要在本地（127.0.0.1 或 localhost）找資料，而是直接透過網路封包，前往 IP 為 192.168.1.159 的 SQL Server 資料庫主機請求資料庫服務。
  • Database=松測： 指定連接的資料庫名稱為「松測」。
  • UID=frank 與 Trusted_Connection=Yes： 這裡包含了混合認證機制。Trusted_Connection=Yes 代表使用 Windows 驗證模式（Domain/Windows 帳號），若 ERP 與 SQL 未加入同一個 Active Directory 網域，建議改用 SQL 混合驗證（設定 Trusted_Connection=No，並帶入 SQL 專屬帳號 frank 與對應密碼）。
  • DBQ=...WNSH.mdb： 這是早期許多台灣傳統 ERP（如印刷帳務管理系統）常見的雙模架構，可能作為前端暫存檔或 Access 轉接介面，但在後端交易上，核心已正式交由 192.168.1.159 的 SQL Server 處理。

五、 第三關：跨機超操控！在 ERP Server 透過 SSMS 還原資料庫

現在進入本篇最精采、也最容易讓人產生觀念混淆的重頭戲——「如何在 ERP Server (192.168.1.156) 上，利用 SSMS V18.11.1，將資料庫還原至 SQL Server (192.168.1.159) 且指定存放於 “SQL" 資料夾？」

🚨 觀念陷阱警報： 在操作跨機還原時，一定要記住：「SSMS 只是操控遙控器，真正的檔案讀取與寫入動作，全部發生在遠端的 SQL Server (192.168.1.159) 上！」

實戰步驟 1：開啟 SSMS V18.11.1 並遠端連線

打開 SSMS V18.11.1 及遠端連線後所看到的檔案總管會是 SQL Server 端的，所以要把相關要用的代碼放到 SQL Server 的 “SQL” 及設共用才能存取

  1. 在 ERP Server (192.168.1.156) 前，開啟 SQL Server Management Studio V18.11.1。
  2. 在「連線到伺服器」視窗中：
    • 伺服器類型： 資料庫引擎 (Database Engine)
    • 伺服器名稱： 輸入遠端 SQL Server IP 192.168.1.159
    • 驗證方式： 選擇 Windows 驗證或 SQL Server 驗證（帳號 frank）。
  3. 點擊【連線】。成功連入後，你在 SSMS 物件總管看到的，就是遠端 192.168.1.159 主機上的資料庫狀態。

參考建議-關鍵的「檔案」設定——把資料庫存到 DB Server(192.168.1.159) 規劃的的 “SQL” 資料夾，其他相關代碼放”SQL” 資料夾下如 “DBworkarea”

這一步是效能最佳化的核心，當你選好備份檔後，先別急著按確定，切換到左側的「檔案」頁面（或有些版本叫「選項」）。

你會看到「將資料庫檔案還原為」的列表，通常會有兩個檔案：一個是資料檔（.mdf），一個是記錄檔（.ldf）。系統預設會把它們還原到 SQL Server 的預設目錄，這往往就是造成磁碟 I/O 瓶頸。

請手動修改「還原為」欄位的路徑，把它們指向你規劃的資料夾。例如：

  • C:\SQL\松測.mdf
  • C:\SQL\松測_log.ldf

這樣做有兩個好處：

  1. 磁碟分離：如果 SQL資料夾 是位於 192.168.1.159 這台機器上獨立的實體磁碟或 SSD，那就等於是把資料庫的讀寫壓力跟作業系統分開，以提高效能。
  2. 路徑統一：強制把資料庫檔案放在一個你清楚知道的地方，未來要備份或搬移都方便。

設定完成後，按下「確定」，SSMS 就會把指令送到 192.168.1.159，開始還原，你會看到進度條跑動，此時 192.168.1.156 ERP Server 完全不會感到任何負擔，因為它只是在「監工」。

實戰步驟 2：資料庫備份檔 (.bak) 的擺放位置

假設你手上有一個備份檔要還原成「松測」資料庫：

  • 錯誤做法： 把 松測.bak 放在 ERP Server (192.168.1.156) 的 C:\ 磁碟機，然後在 SSMS 選擇還原。SQL Server (192.168.1.159) 會找不到檔案而報錯！
  • 正確做法： 必須將 松測.bak 複製到 SQL Server (192.168.1.159) 本地的硬碟 中（例如 C:\SQL\松測.bak），或者透過網路共享路徑（UNC Path）讓 SQL Server 服務帳戶有權限讀取。

六、 驗證與測試：如何確定還原成功？

當 SSMS 跳出「資料庫 ‘松測’ 還原成功」的提示視窗後，我們需要進行「階段驗證法」，確認系統已順利在新架構下運作：

1. 檔案實體確認

前往 SQL Server 伺服器 (192.168.1.159)，打開檔案資源管理器，進入 C:\SQL\ 資料夾，你應該會看到生成的 松測.mdf 與 松測_log.ldf 檔案，且檔案建立時間為剛才還原的時間點。

2. SSMS 狀態檢查

在 ERP Server (192.168.1.156) 的 SSMS 中，重新整理【資料庫】清單，點開「松測」->【資料表】，隨機執行一次查詢：

SELECT TOP 100 * FROM [松測].[dbo].[客戶資料表];

確認資料能順利讀取且無無碼狀況。

七、 專家調校指南：跨機分散後的效能優化建議

將 ERP 與 SQL Server 分散在兩台伺服器後，雖然解決了運算資源搶占問題，但同時也引入了一個新的變數——「網路延遲（Network Latency）」。

以前 ERP 與 SQL 在同一台伺服器時，資料交換走的是 Shared Memory（記憶體直接存取），速度極快；現在變成了跨機通訊，資料必須封包化經由網卡（NIC）傳輸。為了防止網路成為新的瓶頸

1. 升級區域網路硬體（Gigabit / 10GbE）

確保 ERP Server (192.168.1.156) 與 SQL Server (192.168.1.159) 之間的網路交換器（Switch）支援 Gigabit (1000 Mbps) 以上規格，且網線採用 Cat.6 以上規格。如果企業條件允許，建議為這兩台伺服器配置 獨立的實體網卡，建立專用的備份/資料傳輸通道（Heartbeat / Backup Network）。

2. SQL Server 記憶體上限設定（Max Server Memory）

雖然 SQL Server 現在獨佔 192.168.1.159 伺服器，但仍不建議將「最大伺服器記憶體」設為無限大。請至少保留 2GB ~ 4GB 的記憶體給 Windows 作業系統本身，否則當 OS 記憶體不足時發生 Page Fault，反而會 Drag down SQL Server 的效能。

在 SSMS 中對伺服器點右鍵【內容】->【記憶體】-> 修改 最大伺服器記憶體 (MB)。


八、 結語：擺脫卡頓，迎向高效能企業 IT

透過本篇的詳細圖文與實戰演練，我們成功將原本擠在同一台機器上的 ERP 系統（192.168.1.156）與 SQL Server 資料庫（192.168.1.159）完美拆分。

我們不僅實現了 跨伺服器的 DSN ODBC 配置，更示範了如何透過 SSMS V18.11.1 遠端操控還原「松測」資料庫至指定的 SQL 目錄。

IT 系統架構的升級，往往不需要盲目追求高昂的新硬體，只要「架構放對位置，資源合理分配」，老舊的 ERP 系統也能煥發新生，告別卡頓、死機的噩夢！

你的公司 ERP 系統還在「單打獨鬥」嗎？快把這篇文章分享給你們的系統管理員，一起動手幫伺服器分家吧！

交換心得，發表迴響