這個系列文主要是我個人經驗與我看待DB的角度出發
然後因為現在有 AI，語法、datatype 那些很基礎的東西網路上都很多了，所以就不會出現在這裡
系列文主要會分成兩個階段，基礎 & 效能調校。
因為都是我個人經驗，如有錯誤請多指教。

安裝 SQL Server的首要考量

1. 版本
   • 有幾個版本可以選 Enterprise、Standard、Developer、Express。
   • 當然考量的點是功能、DB 大小需求、成本等等。
   • 至於這幾個版本實際有什麼差別，問 AI 會更準，我可以先說一下大致上是標準版有24核心、128 GB RAM 限制，企業版沒有，最重要的是 AOAG 差別，你有一個很高的 HA 需求，那就必須得用企業版才辦的到，標準版還是可以做 AOAG 只是有一點閹割。
     阿什麼是 AOAG、HA 什麼的，現在還不知道沒差，練習的時候就直接用 Enterprise Developer 就好了。
     然後我只能很粗略的簡介，這會因為每一個年份版本不同而有所變動，要列出來太多了，例如上面說的 24 核、128 GB RAM 那是 2022 的，據我所知 2025 後好像提升到 32 核、256 GB
2. 授權
   • 授權模式，等等說明。
3. 本地部屬 v.s. 雲端部屬
   • 本地部屬還是雲端部屬，這優缺點很明顯。
   • 有些企業還是會擔心資料庫上雲的安全性，或是有些在意的是成本。
   • 所謂的成本不只硬體、授權，還有企業要找工程師維護的人力。
   • 有些功能是只有本地才有的，在決定之前要先確認一下這功能要不要用，例如 :
     或是一些其他跟作業系統有關的 Agent，雲端不是沒有 Agent，他是受一些限制。
   • 阿這邊說的 "雲端"，是例如說 Azure SQL Database，你如果是 Azure VM，然後在裡面裝 SQL Server，那當然跟本地端一樣完整支援。
4. 硬體考量
5. 軟體考量

授權模式

先說授權模式，通常落實在企業的時候啦，都是找代理報價，把你的需求給他們，他們再一份報價給你。
所以說了解這個東西沒什麼用，頂多是不要被坑而已。

授權模式有分 CAL、CORE、訂閱跟雲端，訂閱應該是很少在用沒看過有人用。

CAL 模式

1. CAL 是客戶端授權模式，包含使用者或設備兩種。
2. 使用CAL授權模式也必須支付一筆固定 SERVER 費用。
3. 假設有 100 個設備 300 個人使用，那只需要買 100 個設備的授權+ SERVER 授權費用，反之亦然。
4. 但微軟並不會因為你只買一個授權就限制你只能一個人用，你依然是可以使用 SQL SERVER 沒有限制，但是被抓到就會要你補足授權或是罰錢。
5. 只有 Standard 版本可選 CAL 模式。
6. 所謂的人數或設備數定義是，真正會用到的，微軟認定的是終端數，不是中繼數；例如有一個網頁只用一個帳號一個連線去登入 SQL SERVER，但是有 10 個人會使用這個網頁，那麼此時微軟認定應當是需要 10 個授權。
7. 判定的方式我是覺得很玄，而且還有百百種可能，所以代理要你買多少就買多少吧，出4了還有人可以負責。

CORE 模式

1. CORE 模式是 CPU 核心制，購買最小單位為 2 核心，任一 CPU 一次最少得有 4 核心授權，就算你 CPU 只有單核，你一樣得付 4 核的錢，因為這是最小起買點。
2. 虛擬機跟實體機一樣，虛擬機是計算你分配多少核心。
3. CORE 模式下就不限定使用人數、使用裝置數。
4. CORE 模式指的是 CPU 實體核心不是超線呈。
5. INTEL 最新 CPU 有大小核的分別，但在 SQL SERVER 上依舊認定為同一種核心沒有區分。
6. 跟 CAL 模式一樣，只購買 4 核心授權裝在 8 核心電腦上，依然可以運作，且 SQL SERVER 會預設使用8核心，但是被抓到就要補授權或罰錢。

AZURE

1. 這個就按你的規格還有時間計價，一小時多少錢這樣
2. 然後基本上這也可以算是 CORE 模式，他沒有 CAL 的限制。
   我知道他有別種計費方式，但真的把所有細項全部寫完真的太多，所以就大概大概，我認為是重點的地方才會寫的很詳細。

Windows Server Core

這在以前我會覺得沒必要，因為還要再多去找到一個會用 Server Core 的工程師來維護，但如今有 AI 可以輔助，所以如果可以的話，要用 Server Core 也是沒問題。
在Windows Server Core上安裝SQL SERVER是相對安全的，因為他攻擊面積小、漏洞少、又可提升性能

硬體考量

1. 你要去考慮公司硬體生命替換週期，通常建議三年。
2. 通常會規劃比實際需求更高規格，但並非每次都使用更高規格，例如採用共享資源的私有雲基礎架構。在這種情境下，過度配置伺服器規格會對整個環境產生負面影響，甚至波及那台過度配置的伺服器本身。
3. SQL SERVER 最基本硬體是4G RAM + 一核2GHz的cpu，但一般都建議2核vcore以上+( 4g ram + 每1核心 1g ram)

儲存

儲存的硬體設備，基本上就是 SQL Server 的命脈，不論後期你執行計畫、index 等等調的再好，儲存的硬體設備或是規劃很爛的話，再怎麼調都是徒勞。
以下有幾個建議參考 :

1. 建議Data files 跟 Log files 跟 TempDB 分別放在三個不同的硬碟或是陣列。
2. TempDB是最常被使用到的系統資料庫所以拜託一定要獨立出來。
3. 如果全部都放在同一個硬碟或陣列在日後有大量 I/O 時，會發生 Disk contention。
4. 在理想狀況下，最好的選擇是RAID 10，但成本非常高所以不現實。
5. 因此建議在有相當高的讀寫比時 Data files 使用RAID 5，一般來說讀寫比是三比一就可以作為一個良好的評估基準，當然，這會因每個情境而有所不同。
6. 如果SQL SERVER 只使用基本功能，那Log file 使用 RAID 1 是最好的選擇，比RAID 5好，因為記錄檔的寫入活動具有「循序 」寫入的特性。
7. 但是，某些SQL SERVER功能會對Log 進行大量的讀取，如果是常用這些功能，就會希望跟Data一樣使用Raid 10
   1. AOAG
   2. 資料庫鏡像
   3. 建立快照
   4. Backups
   5. DBCC CHECKDB
   6. 異動資料擷取 CDC
   7. Log shipping

TempDB RAID

Data 跟 Log 要用什麼 RAID 都可以，甚至不用 RAID 我也沒意見。
然後基本上也不會有人推薦你去用 RAID0 來當 Data 的陣列。
可是我實際看過有人或是網路上的人推薦把 RAID0 拿來做 TempDB 的陣列。

這點我是絕對不同意的

我理解他們為什麼會這樣推薦，理由不外乎是 : 因為 RAID0 速度很快，又剛好符合 TempDB 不需要備援的特性，TempDB 又是一個需要速度最快的 DB，這樣方常 OK。

乍看之下是沒問題，但是如果今天這個 RAID0 壞掉了呢?
我們要先知道，如果沒有 TempDB，那 SQL Server instance 是開不起來的，這時候怎麼辦?
你的 RTO 時間夠你在那邊慢慢修 RAID0 嗎?
遇到這種把 TempDB 放在 RAID0 上面，然後 RAID0 又剛好壞掉的狀況，只剩下兩條路走
1. 等待你的團隊把 RAID0 修好，換一顆硬碟然後重跑 RAID 之類的。
2. 把SQL SERVER的 Instance 用 minimal configuration 模式開啟，然後用SQLCMD去變更TempDB的儲存位置。
所以基於這個原因，我不同意為了效能，把TempDB 放在一個脆弱的RAID上，真的要放，也是去放RAID10，相較於主要DATA，TempDB放 RAID10的話會便宜很多，他不用太大的硬碟。

SSD

確實如果你很有錢，就用這個吧。
只是SSD的特性應該大家都知道，無預警突發性故障、故障後資料很難救回等等，所以要用 SSD 的話RAID還是要做。
SSD／NVMe 通常能同時提供較好的隨機 I/O 延遲與循序吞吐量，因此很適合 SQL Server。不過仍需評估寫入耐久度、持續寫入效能、斷電保護、容量成本與備援設計，不能因為使用 SSD 就省略 RAID、備份或高可用規劃。
所以用之前還是評估一下這個Instance 用途是什麼。
最重要的還是錢的問題

SAN

還有一個儲存架構是 SAN，但這我沒用過，所以我也不會。

磁碟區塊

1. 預設的 NTFS分配的單元大小很可能是被設定為 4KB。問題在於，SQL Server 會將資料組織成 8 個連續的 8KB 分頁 (pages)，這被稱為一個「區段 (extent)」。
2. 為了讓 SQL Server 獲得最佳效能，用來託管資料檔、記錄檔與 TempDB 的磁碟區其區塊大小應該與此對齊，並設定為 64KB。
3. 可以用這個指令再powershell裡查看區塊大小

Get-Volume -DriveLetter C | Select-Object DriveLetter, FileSystem, AllocationUnitSize

4. 較大的 Allocation Unit Size 可以減少大型資料庫檔案所需管理的檔案系統配置單位數量，並較符合 SQL Server 常見的大型連續 I/O；但實際效能仍取決於儲存延遲、IOPS、吞吐量、控制器及工作負載。

雲端

最後就是雲端了
這東西每一家都不一樣AWS、AZURE、姑姑魯 Cloud，然後又貴，所以沒研究。

軟體

作業系統

雖然SQL Server如今以支持多種作業系統，但最好還是使用windows系統

1. 版本最好用一致例如SQL Server 2022 那就用 Windows 2022。因為這樣EOL會比較接近。
2. 最好都使用最新版前一版比較穩定。

電源計畫

選高效能的電源計畫

背景服務最佳化

1. 確保伺服器處於背景服務優先於前景應用程式的狀態。
2. 可以使用GUI調整或是PowerShell

Set-ItemProperty -path HKLM:\SYSTEM\CurrentControlSet\Control\PriorityControl -name Win32PrioritySeparation -Type DWORD -Value 24

指派使用者權限

這個容易被人忽略，以下介紹三種在安裝期間不會自動授予的權限，但我建議去處理的

即時檔案初始化

如果再安裝 SQL Server 的時候沒有啟用即時檔案初始化也就是 IFI (Instant File Initialization)的話，那麼當 SQL Server 需要建立或是擴充一個檔案的時候，她會直接把那個檔案全部填滿0。

這個動作叫做 zeroing out，目的是複寫先前占用該磁碟空間的任何資料，雖然安全但這樣就會花費一點時間，特別對於大型檔案而言更明顯。

再細一點的話就是，這個影響僅限於 data file，以及 2022 以後的 log file 如果自動成長 <= 64 mb 的話，也可以受用，其餘擴展檔案都沒辦法因此受益。

一般來說微軟是建議啟用的，阿他建議啟用但是又不開預設我是不懂為什麼。
可能是因為這動作有一個很小的安全風險，因為他不寫0了，所以先前存在硬碟上這個位置的資料，在理論上是可以被發現的。但這風險很小，所以還是開吧。

為了達成這個目的，必須將 Perform Volume Maintenance Tasks 的使用者權限給SQL Server Database Engine 的服務帳戶。一旦給予這個權限，SQL Server會自動立即檔案初始化，不需要做其他設定。

win+r 然後輸入 secpol.msc
然後「本機原則」➤「使用者權限指派」。
這會顯示完整的指派清單。向下捲動直到找到「執行磁碟區維護工作」。

在該指派上按一下右鍵並進入其內容，即可加入SQL Server 服務帳戶。

鎖定記憶體分頁

如果Windows 面臨記憶體壓力，那他會嘗試釋放RAM，這很合理，但這會造成SQL Server的效能問題。

SQL Server 會將最近使用過的資料快取在 buffer cache 中，這是Database Engine 所保留的一塊記憶體區域，所有資料分頁都是從buffer cache 中讀取的，即使必須先從磁碟讀取出來。所以如果Windows 面臨RAM壓力時，選擇釋放這個 buffer cache ，那SQL Server就會面臨效能問題。

為了避免這種情況發生，可以跟 IFI 一樣授予權限給SQL Server Database Engine 服務帳戶，但前提是SQL Server的版本必須是企業版或標準版。

這次要給的權限叫做鎖定記憶體分頁，給這個權限之後就可以把buffer cache 鎖定在記憶體中不被Windows 釋放。

原則上來說，放 SQL Server 的那一台伺服器，應該是不要再做別的事情了，Windows 不應該有記憶體壓力。
如果是使用虛擬機，根據虛擬平台的設定，可會無法設定鎖定記憶體分頁，因為這可能會因為balloon driver。虛擬化平台會使用氣球驅動程式來從客體作業系統 中回收記憶體。

SQL 稽核記錄檔

如果預計使用SQL Audit來擷取instance的活動，可以選擇把產生的事件儲存到檔案、安全性記錄檔或應用程式記錄檔。如果有高度的安全需求，安全性記錄檔會是最適合的位置。

為了讓事件能寫入安全性記錄檔，Database Engine的服務帳戶必須授予產生安全性稽核( Generate Security Audits )的使用者權限指派。

然後還要啟用這個

下一篇開始進入正式安裝。