SQL Server 2008 引入了Policy-Based Management。 Policy-Based Management 是一套基於規則的框架，它可以針對一個或多個SQL Server 2008 的實例。在SQL Server Management Studio 中用戶可以創建策略，在不同級別上對數據庫服務器進行管理(包括服務器級別、數據庫級別、以及SQL Server 對象級別)，並且可以對其設定單獨的條件限制或一組條件限制。
針對一臺或多臺服務器，在安全性和性能方面實現最佳方案
研究並啓用SQL Server 中的一些策略(重點關注安全性和性能方面的最佳方案)。首先我們將瞭解一些性能相關的策略
1. 啓動SQL Server Management Studio。
在Windows 任務欄中，依次點擊Start | All Programs | Microsoft SQL Server 2008 | SQL Server Management Studio
2. 當SQL Server Management Studio 打開以後會提示進行連接。在Connect to Server 對話框中，輸入如下連接屬性並點擊Connect:
Server type: Database Engine
Server name: CHICAGO/ConfigServer
Authentication: Windows Authentication
我們只有使用一臺“配置服務器”才能夠通過策略集中存儲並集中管理全部的標準配置、服務器連接組(爲了讓SQL Server Management Studio 的連接性更好) 以及集中化的數據集合和數據分析。該服務器的名稱(及其硬件配置) 並不重要，與其它SQL Server服務器有所不同也無大礙。我們只需要通過該服務器集中化的使用SQL Server 中新的管理功能，包括：Policy-Based Management (此實驗的內容)， Performance Data Collection, 以及管理註冊服務器和服務器組的屬性。
3. 在Object Explorer, 展開Management 然後點擊Policy Management, 最後展開Facets。
4. 在Object Explorer Details 窗口中(如果該窗口沒有顯示在SQL Server Management Studio中，請點擊View, Object Explorer Details)，我們可以看到SQL Server 所支持的74 個方面並且默認情況下沒有任何策略。SQL Server 2008中所有滿足“最佳方案的策略”都是以.xml 文件的形式提供。如果需要導入滿足“最佳方案的策略”，只需要右鍵點擊Policies 然後再點擊Import Policy…。
5. 在Import 對話框中，點擊“Files to import:” 右側的…按鈕。當顯示Select Policy 菜單的時候，您將可以看到名爲“SQL Server Best Practices” 的鏈接。如果您看到了這個鏈接，則點擊進入C:/Program Files/Microsoft SQL Server/100/Tools/Polices 目錄，如果沒有看到這個鏈接，則手動瀏覽到該目錄中。SQL Server 2008 中針對Database Engine, Analysis Services 以及Reporting Services提供了符合最佳方案的相關策略。出於實驗目的，我們將關注有關Database Engine 的最佳方案。進入到/Database Engine/1033 文件夾。選擇所有的.xml 文件，然後這些被選中的文件將會在“Files to import:” 中羅列出來。注意對話框的其它選項，尤其是Policy state 下拉列表中的這三個選項：
• Preserve policy state on import
• Enable all policies on import
• Disable all policies on import
6. 選擇“Disable all policies on import” ，這樣我們的“配置服務器”默認不會啓用策略，以便於我們後續對策略慢慢進行定義，然後再將定義好的策略在生產環境中進行實施。點擊OK，導入所有滿足“最佳方案的策略”。
注意：SQL Server 2008 支持的所有策略在其相應的xml 文件中默認都是禁用的；但當將這些策略導入到“目標”服務器的時候，您可以選擇“Preserve policy state on import”或者選擇Enable all on import。
7. 加載完成後您將看到50條策略，71個條件以及原始的74個方面。
8. 查看一下這些策略的名稱。每一條策略都針對一個或多個目標並有一個或多個條件，您可以選擇相應條件進行強制執行，或者僅僅進行驗證和監控。大多數策略您可能已經很熟悉了，甚至就是您目前所遵循的一些最佳方案：
• CmdExec Rights Secured: 相關內容我們需要在SQL Server Surface Area Configuration Tool 中進行查看(一般情況下我們要將其關閉)。
• Data and Log File Location: 查看數據庫的屬性，但是如果服務器數量很多，你不得不在每一臺服務器中進行相關操作，或者編寫T-SQL 語句來分析所有數據庫的數據文件位置和日誌文件位置。這條策略可以很輕鬆的驗證特定數據庫的日誌文件和數據文件是否存儲在不同的邏輯驅動器上
• Database Auto Close: 查看數據庫屬性，你可以查看數據庫選項的狀態，但有時候卻不知道某些選項是否應當打開或關閉。在這個最佳方案中提示最好不要啓用該選項(針對生產環境的服務器)，因爲啓用該選項可能會造成無謂的系統開銷
9. 如果想了解策略的詳細信息，可以雙擊該策略，此時彈出的頁面中將會有兩個選項：general 和description. Descriptions 頁面中的內容雖然很簡練，但幫助很大。如果想深入研究，你還可以查看該策略生效的條件。下面我們將以SQL Server Lightweight Pooling 這條策略爲例
10. 雙擊SQL Server Lightweight Pooling 策略，將其打開
11. 點擊Description 選項卡並閱讀如下內容：Checks whether lightweight pooling is disabled on the server. Setting lightweightpooling to 1 causes SQL Server to switch to fiber mode scheduling. Fiber mode is intended for certain situations when the context switching of the UMS workers are the critical bottleneck in performance. Because this situation is unusual, fiber mode rarely enhances performance or scalability on the typical system。
雖然描述中的信息無法讓你立即成爲輕型池方面的專家，但卻能讓你大概對此有所瞭解
12. 在“Additional Hyperlink help”中點擊“Test Link” 按鈕，此時會打開聯機叢書中的相關文章，並進一步描述輕型池以及對該選項的推薦設置。某些情況下打開此設置是有益處的，但根據SQL Server 團隊的研究，大多數情況下推薦將此項設置關閉。
13. 返回到SQL Server Lightweight Pooling 策略的Open Policy 對話框
14. 如果強制此項策略，我們希望能夠在違反策略的時候提供更爲詳細的信息，因此在Additional Help Hyperlink 區域輸入如下信息*：
Text to display: Click for more information about this best practice
Address: http://msdn.microsoft.com/en-us/library/bb402857.aspx
15. *注意：上述信息並不是必須要輸入，在後面的步驟中我們將會看到這些信息在什麼情況下會顯示出來，因此你也可以任意輸入一些文字。同時，儘量保證文字的簡潔，因爲只有大概120個字符(根據窗口大小)可以顯示出來。建議只輸入對鏈接的描述信息即可。
最後，在點擊OK 之前，請注意Date modified 和Modified by 這兩個字段當前還是空的
16. 信息更改完成以後，點擊OK. 然後馬上雙擊該策略將其重新打開。這時可以看到我們之前所輸入的描述信息和鏈接，另外“date modified” 和“modified by” 字段中的信息也進行了更新
17. 將策略保持打開狀態，返回到General 選項卡，我們將設置強制執行該策略。但此時Enable 複選框仍是灰色的。這是因爲採用“On Demand” 方式的策略不能“enabled”，這些策略只能手動執行
18. 將Evaluation Mode 改爲On Schedule，此時Enabled 複選框將不再是灰色，但會提示出現錯誤
19. 注意對話框上部提示的錯誤：CheckOnSchedule requires a Schedule. Select an existing Schedule, create a new Schedule, or change the Execution mode。
20. 同時在Schedule 框中也有相對應的錯誤提示。將鼠標移動過去可以看到相同的消息。
21. 點擊對話框上部以黃色高亮顯示的錯誤消息，可以將此信息展開：
22. 注意在左下角有兩個額外的圖標：
23. 點擊右側的圖標(Copy message text) 可以將詳細信息複製到剪貼板中
24. 打開記事本(Start, run, notepad.exe) 並將剪貼板中的內容粘貼過來，可以看到更爲詳細的信息：
TITLE: Microsoft SQL Server Management Studio
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
CheckOnSchedule requires a Schedule. Select an existing Schedule, create a new Schedule, orchange the Execution mode。
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.0。1600.22+((SQL_PreRelease)。080709-1414+)&EvtSrc=MissingJobScheduleException&LinkId=20476
BUTTONS:
OK
25. 如果要設置計劃，首先需要決定是採用現有的計劃還是單獨新建一個計劃。點擊Pick 可以查看是否有以創建好的合適的計劃。檢查輕型池並不需要很頻繁，現有計劃當中最爲不頻繁的也要每隔6個小時執行一次。另外還有的計劃是當SQL Server Agent 啓動時運行，但這又顯得太過於稀鬆。如果你進一步研究會發現，更改輕型池選項需要重新啓動SQL Server，這也將導致SQL Server Agent 重啓。因此，選擇RunAsSQLAgentServiceStartSchedule 計劃然後點擊OK 返回General 選項卡
26. 最後，點擊Enabled 複選框，然後點擊OK 按鈕完成對策略所作的更改
27. 對策略進行評估很容易，我們可以從Object Explorer 或Object Explorer Details 中右鍵點擊該策略，然後點擊Evaluate，該策略將在當前實例中執行。驗證過程結束時，將會顯示該策略是否存在衝突
28. 注意在Details 欄中有一個鏈接View… ，可以查看詳細信息。點擊View… 將會顯示Results Detailed View 對話框，在這裏可以看到Expected Value, Actual Value, Policy Description, Additional Help 以及我們前面所定義的鏈接：
驗證該策略在CHICAGO 服務器的所有實例當中生效
我們可以很輕鬆的在創建策略的服務器中對該策略進行評估。那麼我們能否在其它服務器上對策略進行評估呢？
29. 點擊Close 關閉Evaluate Policies 窗口
30. 通過集中定義策略，我們可以藉助服務器組或在SQL Server Management Studio 中使用新引入的Centralized Management Server 功能實現在多臺服務器中執行策略。Centralized Management Servers 作爲SQL Server 2008 中新引入的功能，可以讓用戶集中存儲Registered Servers 以及Server Groups，而不需要在每一臺計算機中設置服務器和組
如果我們只有一臺服務器的話，那麼管理起來很容易。但通常情況下我們需要管理位於不同位置的多臺服務器。爲了簡化管理任務，我們可以採用Centralized Management Server 來減少設置服務器所需的時間
31. 在設置Centralized Management Server 時，將Registered Servers 欄添加到SQL Server Management Studio 中。如果沒有顯示該窗口，則可以點擊View, Registered Servers 菜單項將其添加進來。
如果你希望將Registered Servers 窗口顯示在其它位置，可以直接對其進行拖拽
32. 右鍵點擊Centralized Management Server，然後點擊Register Centralized Management Server…。
33. 在New Server Registration 對話框中，按照入下信息進行輸入，完成後先不要點擊OK：
Server type: Database Engine
Server name: CHICAGO/ConfigServer
Authentication: Windows Authentication
34. 在將CHICAGO/ConfigServer 作爲Centralized Management Sever 添加進來之前，建議將Registered server name: 中包含一些標記性字符，如CMS：，這樣便於與直接來自CHICAGO/ConfigServer 實例的連接進行區分
特別注意：儘管Centralized Management Servers (CMS) 可以顯著降低管理的複雜度，但一定要慎重使用。如果你在連接到CMS 的時候誤以爲自己連接到的是一個單獨實例，則很有可能無意中同時在多臺服務器上執行一些操作。藉助良好的命名規範，可以降低這種錯誤發生的概率
35. 點擊Save 從而將“CMS:CHICAGO/ConfigServer” 添加爲Centralized Management Server。
36. 右鍵點擊CMS:CHICAGO/ConfigServer 來創建New Server Group…。服務器組可以定義一個服務器集合，這樣策略可以在Registered Servers 的任意級別中進行驗證，實例也可以位於多個服務器組中。例如CHICAGO 服務器中總共安裝了5個實例(CHICAGO/SQLDev01, CHICAGO/SQLDev02, CHICAGO/SQLDev03, CHICAGO/SQLExpress – 再加上CHICAGO/ConfigServer)，你可以創建如下層級架構：
利用上述層級架構，你可以在整個CMS: Chicago/ConfigServer 中檢查並配置策略，也可以單獨在Production 組或者Development 組中配置策略
37. 在此實驗當中，我們將對Production 組執行策略
38. 當所有實例都如上圖所示進行了註冊時，右鍵點擊Production, 然後點擊Evaluate Policies…。
39. 在Evaluate Policies - Production 對話框中，點擊Source: 選項右側的…按鈕。
40. 在這裏你可以選擇從.xml 文件進行策略評估，或者從某個服務器中獲取策略選項
41. 選擇Server: ，然後輸入服務器屬性：
Server type: Database Engine
Server name: CHICAGO/ConfigServer
Authentication: Windows Authentication
42. 在Evaluate Policies – Production 對話框中，你將看到CHICAGO/ConfigServer 中的所有策略
43. 選中SQL Server Lightweight Pooling 策略，然後點擊右下角的Evaluate 按鈕
44. 該策略將在所有運行狀態的服務器中進行檢查。但該策略並不會在每一個本地服務器中創建，因此採用這種方法進行策略評估只能手動執行
45. 由於SQLDev03 沒有啓動，因此無法進行檢查。你必須啓動該服務器或等到超時才能完成。我們無法在Evaluate 選項中通過設置來跳過沒有啓動的服務器(但這對於生產環境中的服務器來說並不是個問題)。
設置策略
我們可以在一臺服務器上集中評估一條策略，但該策略並沒有添加進來。爲了將策略推到每一臺服務器中，需要使用Import Policies…
46. 右鍵點擊Production 組，然後點擊Import Policies…,
47. 在Import dialog 中，注意我們只可以導入文件。在將策略導入到其它服務器之前，我們需要將其保存。退出該對話框並返回到CHICAGO/ConfigServer 的策略列表
48. 右鍵點擊SQL Server Lightweight Pooling Best Practice 策略，然後點擊Export Policy. 將生成的xml 文件保存到C:/Manageability Labs/Policy-based Management/SQL Server Lightweight Pooling Best Practice.xml。
49. 完成後返回到Centralized Management Server 的Production 組中，點擊Import Policies…, 然後點擊“Files to import” 選項右側的… 按鈕
50. 當顯示Select Policy 菜單時，選擇C:/Manageability Labs/Policy-Based Management/SQL Server Lightweight Pooling Best Practice.xml 文件。 然後該文件將會顯示在“Files to import:” 中
51. 選擇 Preserve policy state on import。
52. 點擊OK 從而導入該策略
53. 完成後你將會看到錯誤信息。點擊Log 頁面(左上角的“Select a page”下面)查看詳細信息：
54. 在處於運行狀態的實例SQLDev01 和SQLDev02中，檢查該策略是否成功添加(依次展開Management, Policy Management, Policies)。
在此任務當中就，我們使用其它預先創建的策略
接下來我們將使用方面 所創建的分組來了解哪些策略應當針對多種情況而設置，例如Database Performance。
55. 依次展開Management, Policy Management, Facets。
56. 右鍵點擊Database Performance 方面 然後點擊Properties。
57. 點擊Dependent Policies 選項卡，顯示所有使用該方面 的策略：
58. 由於這些數據庫選項與數據庫性能相關，因此可以考慮在你的環境中採用推薦設置
59. 點擊Close 退出當前的方面。
60. 在Policies 列表中，右鍵點擊Database Performance 方面 中所列出的第一個策略，即Data and Log File Location，然後點擊Evaluate
61. 在Evaluate Policies - Data and Log File Location 對話框中，你可以看到該策略經過檢查，沒有數據庫出現失敗信息。我們的VPC 環境中只有一個驅動器，即C:/. 爲什麼能夠通過此測試？
62. 爲了驗證這條策略所定義的條件，請在Policy Selection 頁面中點擊該策略的鏈接
63. 在Against Targets 部分，注意該策略將應用到“every” 數據庫中。但真正檢查的條件是什麼？點擊Check Condition 下拉列表右側的… 按鈕，可以看到檢查條件的名稱爲：Data and Log Files on Separate Drives。
64. 在Open Condition 對話框中，你可以看到真正的檢查條件不僅僅是檢查邏輯卷標。總共有4個條件要進行檢查，只要其中有一個條件滿足，則最終結果將是“pass”
65. 點擊Close
66. 在Policies 部分，右鍵點擊Database Auto Close 然後點擊Evaluate…
67. 在Evaluate 對話框中，可以看到該策略在所有數據庫中都進行了檢測且沒有出現衝突。點擊Close 關閉該對話框
68. 在Policies 部分，右鍵點擊Database Auto Shrink 然後點擊Evaluate…
69. 在Evaluate 對話框中，可以看到ConfigServer 的數據庫與該策略存在衝突。如果想確定具體是哪個數據庫與該策略有衝突，可以在Target 部分查看詳細信息：
70. 如果點擊View… 按鈕，可以看到有一個名爲AutoShrinkIsEvil 的數據庫該項設置爲True，存在着衝突。除此以外，我們還可否通過其它途徑來了解該策略是否存在衝突？
71. 點擊Close 退出該對話框
72. 返回到Object Explorer 並右鍵點擊CHICAGO:ConfigServer，然後點擊Refresh. 展開Databases…一切照舊
73. 我們目前無法通過其它途徑來查看策略衝突的原因是該策略還沒有被啓用。即便評估過程失敗，也不會在其它地方提示存在衝突
74. 依次展開Management, Policy Management, Policies. 右鍵點擊Database Auto Shrink 策略然後點擊Properties。
75. 在General 選項卡中，enabled 選項是灰色的。爲了啓用該策略，我們首先需要設置一個日常檢查計劃。在Execution Mode 下拉列表中選擇On Schedule
76. 當On Schedule 被選中以後，Schedule 部分將顯示出來。我們希望設置爲每天的12:15am 進行檢查，由於沒有預先創建好的計劃，因此我們需要新建一個計劃。點擊New, 在New Job Schedule 對話框中，輸入計劃名稱JobSchedule_Daily_12:15am 然後按照如下內容設置屬性：
77. 完成後點擊OK
78. 確保一定要勾選Enabled 設置項。點擊OK 選擇JobSchedule_Daily_12:15am 計劃，然後在Open Policy 對話框中勾選Enabled 複選框
79. 右鍵點擊Database Auto Shrink 的策略，然後點擊Evaluate。
80. 此時與該策略存在衝突的數據庫將再次顯示錯誤信息。但當我們返回到Object Explorer ，右鍵點擊CHICAGO/CONFIGSERVER，然後點擊refresh 的時候，你將可以看到數據庫的狀態用不同的圖標顯示出來。右鍵點擊AutoShrinkIsEvil 數據庫，然後點擊Policies, View:
81. 在View Policies – AutoShrinkIsEvi 對話框中我們可以看到策略的信息
82. 既然自動收縮設置不應當被打開，那麼我們可以通過這條策略來更改數據庫設置嗎？答案當然是肯定的
83. 爲了“Apply” 一條策略，必須在評估過程中出現失敗的信息。重新評估Database Auto Shrink 策略，和第71步一樣，你將看到如下圖所示的結果：
84. 在Target details 列表中勾選複選框，此時右下角的“Apply” 按鈕將從灰色變爲可用狀態。點擊Apply。
85. 點擊Yes 來應用該策略
86. 刷新CHICAGO/ConfigServer，但此時策略衝突的標記並沒有消失。你首先需要重新評估該策略。右鍵點擊AutoShrinkIsEvil 數據庫，然後點擊Policies, 再點擊Evaluate. 對Database Auto Shrink 策略進行評估，當成功以後，我們可以看到衝突標記已經消失
檢查並配置所有數據庫使用Page Checksums 進行數據驗證
對於用戶定義的數據庫，通常要強制採用的策略是Database Page Verification. 這樣可以確保採用校驗和的方式進行數據驗證。我們不僅要確保啓用該策略，還要強制在生產環境的數據庫中實現該項設置
87. 使用Centralized Management Server 在所有Production 數據庫中檢查該設置，點擊Evaluate Policies…。
88. 在Evaluate Policies - Production 對話框中，點擊Source: 選項右側的… 按鈕
89. 選擇Server: 選項並輸入如下信息：
Server type: Database Engine
Server name: CHICAGO/ConfigServer
Authentication: Windows Authentication
90. 在Evaluate Policies – Production 對話框中，可以看到CHICAGO/ConfigServer 中的所有策略
91. 在Policies 中選擇Database Page Verification 策略，然後點擊Evaluate 按鈕
92. 注意Northwind 和Pubs 數據庫沒有通過驗證。這兩個數據庫是SQL Server 2000 中的示例數據庫，而CHECKSUM 功能是在SQL Server 2005中才引入的。
93. 勾選Results：中的複選框，這樣所有失敗的目標數據庫都將被選中：
94. 點擊Apply 然後點擊Yes 來修改這些數據庫
95. 在SQL Server Management Studio 中只保留Object Explorer 和Object Explorer Details 窗口打開，關閉其它窗口
