部署虛擬桌面基礎架構（VDI）時，企業通常先計算伺服器容量、使用者數量及網絡延遲，但支撐登入、存取設定和活動紀錄的數據庫同樣影響整體穩定性。若設定資料與稽核紀錄全部依賴同一個未經分層的數據庫，維護、備份及容量調整便容易互相牽連。

Cybele Software 於 2026 年 10 月發表的 Thinfinity Workspace 技術文章，說明在 Oracle Cloud Infrastructure（OCI）上採用 MySQL HeatWave 的部署思路。重點並非單純把數據庫搬到雲端，而是把核心設定資料與分析／稽核資料分開規劃，按不同的重要程度設計高可用性、備份及保留政策。

先分清楚哪一組資料會影響使用者登入

Thinfinity Workspace 在正式環境需要使用外部數據庫；內置的 Absolute Database 主要供評估用途，MySQL 則是其建議的數據庫引擎。Cybele 建議把生產環境的資料分成兩個用途：

• 設定及身份資料庫：存放存取設定檔、角色型存取控制（RBAC）規則及身份驗證映射。連線代理需要依靠這些資料驗證使用者並套用權限，因此屬於關鍵服務。
• 分析及稽核資料庫：保存活動紀錄、分析資料及審計日誌，保留期應按調查、合規及營運需要決定。

兩者的故障影響並不相同。設定資料庫出現問題，可能直接影響使用者登入及存取資源；分析及稽核資料庫則主要影響監察、報表和事後追查。把兩者分開，管理員便可為關鍵設定資料安排較高的可用性，同時獨立控制稽核資料的容量及保留期限。

為甚麼 OCI 上的 MySQL HeatWave 值得納入評估？

MySQL HeatWave 是 OCI 提供的受管理 MySQL 服務。Cybele 的部署建議是使用 MySQL DB System，而非因為服務名稱包含 HeatWave，就額外部署選用的 HeatWave 記憶體內分析叢集；Thinfinity Workspace 的報表功能會讀取其本身的分析及稽核數據庫。

受管理服務可把部分日常工作交由雲端平台處理，包括數據庫配置、修補、升級、監察及自動備份。啟用高可用性後，服務可透過多個 MySQL 執行個體支援故障轉移；自動備份亦支援時間點復原。這些能力可減少 IT 團隊自行維護叢集的工作，但企業仍須負責資料結構、帳戶權限、應用程式連線及復原測試。

自行管理 MySQL 叢集仍有其價值，例如需要指定版本、外掛程式或更深入的引擎調校。不過，企業亦要自行處理複寫、仲裁、故障轉移、修補、監察，以及定期測試完整和局部還原。選擇受管理或自建方案，應比較團隊能否長期承擔這些工作，而不只是比較雲端服務的月費。

Thinfinity Workspace 的數據層可按以下方式部署

1. 讓數據庫與連線代理位於同一雲端區域

把 MySQL DB System 放在與 Thinfinity brokers 相同的 OCI 區域，有助減少身份驗證查詢的網絡往返，亦方便按資料所在地要求規劃。實際選擇區域時，仍須核對服務可用性、資料處理要求及企業的延遲目標，不應單憑地理位置推斷合規性。

2. 以私有子網限制連線來源

數據庫應放在只供 Thinfinity brokers 存取的私有網絡範圍，並只向指定來源開放 MySQL 所需連接埠（預設 3306）。不要因為方便測試而把數據庫直接暴露到公網；如需管理連線，應使用受控的管理通道及明確的存取規則。

3. 為兩類資料分別建立 DB System

設定及身份資料庫可採用高可用性配置，並按服務復原目標安排備份；分析及稽核資料庫則按日誌量、查詢模式及保留政策決定容量和可用性。這種分層方式避免為所有資料一律採用最高成本配置，也減少分析資料增長對登入流程的影響。

4. 使用專用數據庫帳戶連接 Thinfinity

為 Thinfinity 建立獨立 MySQL 使用者，只授予建立所需資料表及執行 CRUD 操作的權限。OCI IAM 負責雲端 DB System 的管理控制；Thinfinity 應使用專用 MySQL 帳戶連接數據庫，兩種身份用途不應混為一談。

5. 在 Configuration Manager 指定資料庫並測試復原

在 Thinfinity Configuration Manager 的 Database 設定中，為各組元件指定對應數據庫。完成連線後，測試登入、權限套用、分析紀錄寫入及稽核查詢，再按復原時間目標實際執行還原演練。只確認備份工作成功，並不足以證明服務可以按預期復原。

安全設計不應只停留在網絡隔離

數據庫位於私有子網只是第一層控制。企業還應確認靜態資料加密、用戶端 TLS 連線、專用帳戶權限及金鑰管理方式。若使用自訂金鑰，需清楚界定金鑰輪替及復原責任；如採用平台管理的金鑰，亦應確認其政策符合內部要求。

分析及稽核資料通常包含使用者、連線及管理活動資訊，應限制可查閱的人員，並按調查與合規需要設定保留和刪除流程。若資料需要供外部服務供應商支援，應先界定支援人員可存取的範圍及審計方式。

備份政策要以還原目標為起點

設定資料庫和稽核資料庫不應套用完全相同的備份策略。前者關乎登入和存取控制，企業可按可接受資料遺失量（RPO）及復原時間（RTO）設計較嚴謹的高可用性及時間點復原安排；後者則可按日誌保留期、調查需要和儲存成本設定備份頻率。

建議定期測試整個數據庫、單一資料庫及必要資料表的還原流程，並確認復原後的 Thinfinity brokers 可以正常連線。若只測試雲端控制台顯示備份完成，卻沒有驗證應用程式能否重新登入及讀取權限設定，便無法確認實際復原能力。

甚麼情況適合其他數據庫或自建叢集？

MySQL HeatWave 是 Cybele 對 Thinfinity Workspace 在 OCI 上的建議方案，並非唯一選擇。Thinfinity 亦支援 PostgreSQL、SQL Server 及 MariaDB；若工作負載部署在其他雲端，可按該平台提供的受管理數據庫及企業現有技能作評估。若需要完全控制數據庫版本、外掛程式或儲存引擎設定，並且有團隊負責高可用性和復原維護，自建叢集仍然合理。

採購評估時，應把數據庫高可用性、備份儲存、資料保留、監察、人手及故障演練一併納入總體擁有成本。對 VDI 使用者而言，登入穩定性和資料可復原性往往比單一伺服器規格更直接影響服務體驗。

常見問題

Thinfinity Workspace 正式環境可以繼續使用內置 Absolute Database 嗎？

Cybele 指出內置 Absolute Database 主要用於評估用途；正式部署應配置外部數據庫，MySQL 是其建議選項之一。

是否需要啟用 MySQL HeatWave 的分析叢集？

不需要。Thinfinity Workspace 需要的是 MySQL DB System；其分析及報表功能會讀取 Thinfinity 自身的分析和稽核資料庫。

兩個數據庫是否必須都啟用高可用性？

不一定。設定及身份資料庫直接支援登入和權限套用，應優先考慮高可用性；分析及稽核資料庫則按保留、合規及營運要求決定配置。

VDI 的穩定性不只取決於桌面主機是否在線，也取決於身份設定、稽核資料和復原流程是否各有清晰責任。先把資料用途分層，再按關鍵程度配置高可用性、網絡隔離及還原測試，企業便能以更可控的方式管理 Thinfinity Workspace 的數據層。