SQL Server 2000 Analysis Services 連接池技術深度解析與 Web 應用最佳實務

前言

資源管理是構建可擴展客戶端與 Web 應用的關鍵。Microsoft XML for Analysis Provider (msxaserv.dll) 內建連接池機制，透過 ADOConPool (管理 ADO 連線) 與 OLEDBConPool (管理 OLE DB Session) 兩個 COM 物件，實現連線重用、降低延遲、提升併發處理能力。本文詳細解析連接池運作原理、物件模型、安全性驗證機制、平衡/收縮策略，以及 IIS 託管環境下的執行緒模型配置陷阱。

一、連接池核心架構

1. 兩大池管理物件

兩者共享相同底層池管理機制，支援 Microsoft OLE DB Provider for OLAP Services 8.0 (MSOLAP.2)，需 SQL Server 2000 SP1 以上版本。

2. 池內連線分組

• 可用連線集：未配置給客戶端，等待重用。
• 已用連線集：正被客戶端持有使用。

二、連線請求與歸還流程

1. 請求連線 (GetConnection / GetSession)

1. 精確匹配：尋找可用池中「網域\使用者 SID」完全相同的連線 → 直接返回。
2. 資料庫匹配：找同一目標資料庫的可用連線。
3. 角色安全性匹配：比對角色權限集合是否相同。
4. 使用者名稱匹配：若角色匹配，比對登入名稱；相同則直接返回，不同則以新使用者身分重新驗證現有連線後返回 (核心優化：跨使用者重用同一經驗證連線)。
5. 建立新連線：以上條件皆不滿足，建立新連線並配置給請求者。

2. 歸還連線 (ReturnConnection / ReturnSession)

客戶端呼叫歸還方法，池管理器驗證連線屬於該池後，放回可用連線集。極簡流程，無額外開銷。

3. 安全性注意：角色權限變更的快取問題

現象：使用者 A 屬角色 R (可存取 Cube1, Cube2) → 取得連線 C → 歸還 → 管理員修改 R 僅存取 Cube1 → 使用者 A 再次請求 → 仍獲連線 C → 仍可存取 Cube2 (舊權限殘留)。

根因：池重用機制僅在建立新連線時向 Analysis Server 驗證；重用現有連線跳過驗證。

解決方案：

• Web 應用：角色變更後重啟 IIS (強制應用程式域卸載，池清空)。
• WinForm/服務：定期呼叫 ShrinkPool 或重啟進程。
• 關鍵權限變更場景：考慮停用池 (不使用池物件，直接建立連線)。

三、Visual C++ 專案配置要點

#include 
#import "\msxaserv.dll" \
    rename("tag_inner_PROPVARIANT", "tagPROPVARIANT") \
    rename("_LARGE_INTEGER", "") \
    rename("_ULARGE_INTEGER", "")
using namespace MSXMLAnalysisSCLib;

需在專案屬性 → C/C++ → General → Additional Include Directories 加入 msxaserv.dll 所在目錄。

四、連接池平衡與收縮策略

1. 平衡

定期檢查可用連線集大小，若超過閾值，關閉最久未使用的連線，釋放伺服器資源。

2. 收縮

應用程式閒置期 (如夜間) 主動呼叫 ShrinkPool 方法，將可用連線數降至最小 (或 0)，配合資料庫伺服器端的閒置連線逾時設定。

兩機制均為被動、非阻塞設計，不影響正常請求取得連線。

五、IIS 託管環境關鍵配置陷阱

問題現象

ASP/ASP.NET 應用將池物件存放在 Application 或 Session 物件變數中 → IIS 5.0+ 預設檢查 COM 元件 Threading Model → XML for Analysis Provider 支援 Free-threaded 但未提供 FTM (Free-threaded Marshaler) → IIS 判定為「非靈活」 → 使用系統安全性內容 (預設 IUSR/應用程式池身分) 呼叫池方法 → 模擬機制失效，所有使用者共用同一連線，嚴重安全風險。

解決方案

1. 開啟 IIS Metabase：ASPTrackThreadingModel = TRUE (僅在該虛擬目錄/網站層級設定，避免全域效能衰退)。
2. 或改用 ASP.NET 托管程式碼，透過 Microsoft.AnalysisServices.AdomdClient (ADOMD.NET) 內建連接池 (支援連線字串 Pooling=true; Max Pool Size=100)，完全繞過 COM 執行緒模型限制。

六、最佳實務總結

• Web 應用優先使用 ADOMD.NET 管理連線池，避免 COM 執行緒模型坑。
• 必須用 XML for Analysis Provider 時：
  ① 池物件存放於 Application 域；
  ② 設定 ASPTrackThreadingModel=TRUE；
  ③ 角色變更機制觸發 IIS 回收。
• 監控指標：Active Connections、Pooled Connections、Connection Wait Time (效能計數器)。
• 連線字串統一管理，避免硬編碼；敏感資訊用加密設定檔。