【IT168 技术文档】1. 针对一台或多台服务器，在安全性和性能方面实现非常好的方案
SQL Server 2008 引入了Policy-Based Management。 Policy-Based Management 是一套基于规则的框架，它可以针对一个或多个SQL Server 2008 的实例。在SQL Server Management Studio 中用户可以创建策略，在不同级别上对数据库服务器进行管理(包括服务器级别、数据库级别、以及SQL Server 对象级别)，并且可以对其设定单独的条件限制或一组条件限制。
在第一个练习当中，我们将对一些预先创建的、满足SQL Server 2008非常好的方案的策略以及条件进行强制、验证、以及设置计划任务。此外，第一个练习还将帮助您熟悉Policy-Based Management 的架构及其所提供的条件。
任务一：
研究并启用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 区域输入如下信息：
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
------------------------------
CheckOnSchedule requires a Schedule. Select an existing Schedule, create a new Schedule, or change 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，而不需要在每一台计算机中设置服务器和组
如果我们只有一台服务器的话，那么管理起来很容易。但通常情况下我们需要管理位于不同位置的多台服务器。为了简化管理任务，我们可以采用CentralizedManagement 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 窗口打开，关闭其它窗口
2. 自定义新策略
在此练习当中，您将通过定义策略来阻止在DBO架构下创建对象。
任务一：在AdventureWorks 的dbo 架构下新建对象
步骤：1. 依次点击File, Open, File… 然后打开C:\Manageability Labs\Policy-Based Management 目录下的ObjectOwnerCreationPoliciesTestScript.sql 脚本，确保在CHICAGO\SQLDev01 实例下打开该脚本
2. 打开行号。点击Tools, Options… 在Options 对话框中，展开Text Editor 部分然后选择All Languages.勾选Line numbers 选项，然后点击OK 并关闭该对话框
3. 执行第27-40行：
USE AdventureWorks
go
CREATE TABLE TestTable
(
Col1 int
)
go
SELECT SCHEMA_NAME(schema_id) AS SchemaName, *
FROM sys.objects
WHERE [name] = 'TestTable'
-- note that it is in the default schema of dbo
go
4. 查看输出结果显示架构名称为dbo.
5. 保持该脚本处于打开状态，然后继续后面的任务
任务二：创建一个策略可以强制执行的条件
步骤：6. 在CHICAGO\ConfigServer 的Object Explorer 中，依次展开Management, Policy Management, Conditions.
7. 右键点击Conditions 然后点击New Condition…
8. 在General 选项卡中，输入“DBO is not a valid user-defined Schema Name” 作为该条件的名称
9. 在Facet 下拉列表中，点击Multipart Name.
10. 在Expression 中首先点击Field 下拉列表，然后点击Field 列中的单元格，此时下拉菜单将会出现。针对Multipart Name 有两个选项，分别是@Name (针对对象名称) 和@Schema (针对创建此对象的架构名称). 选择@Schema.
11. 在Expression 中点击Operator 下拉列表。在此实验中我们希望@Schema != ‘dbo’ ，因此在Operator 下拉列表中选择!=
12. 最后，在Value 列中输入‘dbo’ (包括上引号).
13. 点击下面的空行，从而完成当前行的输入。然后点击OK 退出
14. 在Description 选项卡中，输入如下信息：“DBO is not a valid user-defined Schema Name as object/schema separation is enforced. All user-defined objects should be designed/defined in schemas that reflect the granularity required for security and object access.”.
15. 点击OK 从而完成此条件的添加过程
任务三：创建一个策略来强制执行用户定义的条件
步骤：16. 在Object Explorer 中，依次展开Management/Policy Management/Policies, 然后右键点击Policies 并点击New Policy…
17. 在General 选项卡中，输入: “DBO is not a valid user-defined Schema Name - Base Tables, Views & SPs” 作为策略的名称
18. 在Check condition 下拉列表中，找到Multipart Name 组并选择“DBO is not a valid user-defined Schema Name”
19. 完成后你将可以设置该策略都要应用到那些对象上。在Against Targets 中选择Every StoredProcedure, Table 以及View，但只应用到“Development Databases.” 为了创建我们所要定义的“Development Databases”，点击? Database 然后点击New Condition…
20. 在General 选项卡中，输入：“Development Databases (explicitly named)” 作为条件的名称
21. 在Facet 下拉列表中，选择Database.
22. 在Expression 中，首先点击Field 下拉列表，然后选择@Name.
23. 在Expression 中，点击Operator 下拉列表，此时我们希望@Name IN (‘AdventureWorks’, ‘AdventureWorksDW’) ，因此我们在Operator 下拉列表中选择IN
24. 最后在Value 列中输入‘AdventureWorks2008’, ‘AdventureWorksDW2008’, AdventureWorksLT2008’ (包括上引号和逗号，另外不要直接从此实验手册中复制粘贴，否则引号格式将发生改变)
25. 点击下面的空行，从而完成当前行的输入。然后点击OK 退出
26. 此时OK 按钮依然无法点击。目前这是IN 操作符的一个bug，因此对上述内容进行修改，只针对AdventureWorks2008. 最终的条件将变为@Name = ‘AdventureWorks2008’. 点击OK 并创建此条件
27. 在Create New Policy 对话框中，为每一个对象类型(StoredProcedure, Table, 和View)勾选? , 然后选择“Development Databases (explicitly named)”:
28. 当设置完目标以后，我们将设置Execution Mode 为On Change – Prevent.
29. 在Server restriction 选项中，保留默认设置None.
30. 在Description 选项卡中，设置Category 为“Database Best Practice: Security ”.
31. 然后输入描述信息“Corporate standard (as of September 2008), is to use schemas for better security and granularity. Objects should not be owned by the dbo - especially if cross-database ownership chaining were to become enabled.”
32. 此外在Additional Help Hyperlink 中添加一些辅助信息，如下所示：
Text to display: Please see our Security Guidelines and Best Practices here
Address: http://InternalWebsite/Policies/SQLServerSecurity.htm
33. 返回到General 选项卡，并勾选? Enabled 复选框来启用该策略
34. 点击OK
任务四：尝试在DBO 架构下新建一个对象，并对比着在非DBO 架构下新建对象
步骤：35. 返回到查询窗口(ObjectOwnerCreationPoliciesTestScript.sql 脚本应当处于打开状态). 如果没有打开，请从C:\Manageability Labs\Policy-Based Management 目录将其打开
36. 执行第42-43行:
DROP TABLE TestTable
go
37. 删除数据表以后，尝试再次执行第27-40行:
USE AdventureWorks
go
CREATE TABLE TestTable
(
Col1 int
)
go
SELECT SCHEMA_NAME(schema_id) AS SchemaName, *
FROM sys.objects
WHERE [name] = 'TestTable'
-- note that it is in the default schema of dbo
go
38. 这次将会看到如下信息：
CHICAGO(CHICAGO\Administrator):
Policy 'DBO is not a valid user-defined Schema Name - Base Tables, Views & SPs' has been violated by 'Server/Database[@Name='AdventureWorks2008']/Table[@Name='TestTable' and @Schema='dbo']'.
This transaction will be rolled back.
Policy description: Corporate standard (as of September 2008), is to use schemas for better security and granularity. Objects should not be owned by the dbo - especially if cross-database ownership chaining were to become enabled.'
Additional help: 'Please see our Security Guidelines and Best Practices' : 'http://InternalWebsite/Policies/SQLServerSecurity.htm'.
CHICAGO(CHICAGO\Administrator): Msg 3609, Level 16, State 1, Procedure sp_syspolicy_dispatch_event, Line 50
The transaction ended in the trigger. The batch has been aborted.
CHICAGO(CHICAGO\Administrator): (0 row(s) affected)
39. 现在执行第47-55行:
CREATE TABLE Person.TestTable
(
Col1 int
)
Go
SELECT SCHEMA_NAME(schema_id) AS SchemaName, *
FROM sys.objects
WHERE [name] = 'TestTable'
40. 对象(Person.TestTable) 将可以成功创建，因为它不在dbo 架构中
41. 退出SQL Server Management Studio，本实验结束。
