17.檢查下，保證新的邏輯驅動器在Windows資源管理器中都能夠看到   18.在安裝SQL Server 2012之前，把所有需要的邏輯驅動器都建立上   19.使用CrystalDiskMark測試每個邏輯驅動器的效能   20.使用SQLIO測試每個邏輯驅動器的效能   21.在每個驅動器上，建立下面的資料夾        資料驅動器：SQLData       日誌驅動器：SQLLogs       TempDB驅動器：TempDB        備份驅動器：SQLBackups   22.使用組策略編輯器（GPEDIT.MSC）將這些Windows許可權授予SQL Server服務帳戶        執行卷維護任務        鎖定記憶體頁面      23.安裝SQL Server 2012企業版        確保沒有待處理的重新引導，否則SQL Server 2012將無法安裝        僅安裝此例項所需的SQL Server 2012元件       C。使用混合模式認證            將sa密碼設定為強密碼           II。將自己新增為SQL管理員           III。新增任何需要成為管理員的其他DBA        對於SQL Server服務帳戶使用域賬戶       使用對應的域賬戶作為SQL Server代理帳戶       F。將SQL Server代理服務設定為自動啟動       G。將預設目錄設定為相應的驅動器號和路徑           I.使用者資料庫目錄：P：\ SQLData           II.使用者資料庫日誌目錄：L：\ SQLLogs           III. Temp DB目錄：T：\ TempDB           IV。 Temp DB日誌目錄：T：\ TempDB           v。備份目錄：N：\ SQLBackups   24.安裝SQL Server 2012最新 Service Pack    25.安裝SQL Server 2012 最新的累積更新6        累積更新可從此位置獲得：            http://support.microsoft.com/kb/2874879/en-us        安裝後手動對C：驅動器進行碎片整理           如果您使用的是SSD，則不需要這樣做 26.更改SQL Server 2012例項級屬性        a. 啟用optimize for ad hoc workloads

          這將允許SQL Server在第一次執行時使用較少的記憶體來儲存臨時查詢計劃        b.設定最大並行度設定為伺服器上NUMA節點中的物理核心數       c.啟用預設備份壓縮            這將為所有資料庫備份預設使用SQL Server備份壓縮        d.在SQL Server配置管理器中新增跟蹤標誌3226作為啟動選項            這將阻止在SQL Server錯誤日誌中記錄成功的資料庫備份訊息       e .在SQL Server配置管理器中新增跟蹤標誌1118作為啟動選項            這將有助於緩解tempdb中的配置爭用       f. 在例項上啟用資料庫郵件            用於SQL Server代理警報和SQL Server代理作業失敗時郵件通知       G。將Max Server Memory設定為適當的非預設值

           值取決於伺服器中可用的實體記憶體量               它還取決於安裝的SQL Server元件           II。以下是一些示例值：               1.96GB總RAM：將最大伺服器記憶體設定為87000               2. 64GB總RAM：將最大伺服器記憶體設定為56000               3. 32GB總RAM：將最大伺服器記憶體設定為27000       H。在T：\ TempDB目錄中額外再建立三個TempDB資料檔案。總共4個tempdb檔案（不需要一開始就和CPU個數對齊）            所有TempDB資料檔案的大小應為4096MB

               將自動增長設定為1024MB            II。 TempDB日誌檔案應為1024MB   27.確認您可以從域上的其他計算機ping通 SQL Server計算機   28.使用SQL Server 2012 Configuration Manager，確認例項啟用了TCP / IP   29.確認您可以使用其他計算機上的SSMS遠端連線到SQL Server例項   30.在例項上建立一個SQL Server操作員        使用DBAdmin與電子郵件地址[email protected]   31.確認資料庫郵件正常執行        右鍵單擊資料庫郵件併發送測試訊息   32.配置SQL Server代理郵件以使用資料庫郵件   33.為以下錯誤建立SQL Server代理警報：       a . YourServerName Alert - Sev 19錯誤：資源中的致命錯誤       b. YourServerName Alert - Sev 20錯誤：當前程序中的致命錯誤       C。 YourServerName Alert - Sev 21錯誤：資料庫程序中的致命錯誤       d。 YourServerName Alert - Sev 22錯誤致命錯誤：表完整性可疑       e. YourServerName Alert - Sev 23錯誤：致命錯誤資料庫完整性可疑       f。 YourServerName Alert - Sev 24錯誤：致命的硬體錯誤       g。 YourServerName Alert - Sev 25錯誤：致命錯誤       h。 YourServerName Alert - Error 825：Read-Retry Required       i。 YourServerName警報 - 錯誤832：常量頁面已更改       j.YourServerName警報 - 錯誤855：檢測到不可糾正的硬體記憶體損壞       k。 YourServerName警報 - 錯誤856：SQL Server已檢測到硬體記憶體損壞，但已恢復該頁面   34.這裡提供了建立這些SQL Server代理警報的通用指令碼：        確保每個代理警報都有響應來通知DBAdmin操作員   35.建立一個名為Nightly Free System Cache的SQL Server代理作業，執行此命令：        DBCC FREESYSTEMCACHE ('SQL Plans');        每天晚上在凌晨12:00執行   36.下載最新版本的Ola Hallengren的SQL Server維護解決方案指令碼：        http://ola.hallengren.com/        連線到例項時開啟MaintenanceSolution.sql指令碼            將@BackupDirectory變數修改為N：\ SQLBackups           II。執行指令碼建立十一個新的SQL Server代理作業           III。對於每個作業，如果作業發生故障，請轉到“通知”屬性視窗，並將作業通過電子郵件傳送給DBAdmin組           IV。對於每個作業，建立一個執行時間的計劃。           v。這是一個建議的工作時間表：               CommandLogCleanup星期日上午12:00               2. DatabaseBackup - SYSTEM_DATABASES - 完整的每日11:55 PM               3. DatabaseBackup - USER_DATABASES - DIFF Daily at 12:00 PM               4. DatabaseBackup - USER_DATABASES - 上午12:00時全天               5. DatabaseBackup - USER_DATABASES - 每小時記錄一次               DatabaseIntegrityCheck - SYSTEM_DATABASES星期六上午7:55               7. DatabaseIntegrityCheck - USER_DATABASES星期六上午8:00               8. IndexOptimize - USER_DATABASES星期日下午8:00               9. 檔案清理 星期日上午12:00               10.sp_delete_backuphistory星期日上午12:00               11.sp_purge_jobhistory 星期日上午12:00。

總結

對於個人認為比較重要的最佳實踐我都用紅色的標註了。不過上面的

啟用超執行緒和turbo-boost 

我覺得要根據客戶的實際情況，如果 客戶的系統能夠用上這些多餘的邏輯CPU，那麼才應該開啟超執行緒。根據經驗通常OLTP系統開啟超執行緒是比較有好處的。但對於某些報表查詢，可能開啟超執行緒反而會有不良影響。

詳細可以參考：https://blogs.msdn.microsoft.com/slavao/2005/11/12/be-aware-to-hyper-or-not-to-hyper/ 

tempdb檔案個數

我們知道增加tempdb資料檔案可以減少PAGELATCH爭用 ，按照以前的最佳實踐是和CPU核心數對齊。但是現在已經做了優化，不需要一來就設定那麼多

MBR and GPT

GPT意為GUID分割槽表。（GUID意為全域性唯一識別符號）。這是一個正逐漸取代MBR的新標準。它和UEFI相輔相成——UEFI用於取代老舊的BIOS，而GPT則取代老舊的MBR。之所以叫作“GUID分割槽表”，是因為你的驅動器上的每個分割槽都有一個全域性唯一的識別符號.在MBR磁碟上，分割槽和啟動資訊是儲存在一起的。如果這部分資料被覆蓋或破壞，事情就麻煩了。相對的，GPT在整個磁碟上儲存多個這部分資訊的副本，因此它更為健壯，並可以恢復被破壞的這部分資訊。GPT還為這些資訊儲存了迴圈冗餘校驗碼（CRC）以保證其完整和正確——如果資料被破壞，GPT會發覺這些破壞，並從磁碟上的其他地方進行恢復。而MBR則對這些問題無能為力——只有在問題出現後，你才會發現計算機無法啟動，或者磁碟分割槽都不翼而飛了.

總之，GPT更先進，更健壯，推薦使用GPT

關於其他選項沒什麼爭議。應該儘量遵守的。