PBM的优势体现在:
按需管理:PBM提供了系统配置的逻辑视图,因此DBA们可以预先定义各自所需要的数据服务配置,而不用等到这些需要实际发生的时候再去配置。
智能监控:PBM可以持续监控系统的配置变化,并阻止那些违反了策略的配置变化操作。
虚拟管理:通过PBM,DBA们可以对多台服务器进行规模化管理,在企业内部统一实施某些强制性配置会变得更加方便。
基于策略管理的框架
PBM的框架有三部分组成:
策略管理:管理员制定各种策略。
显式管理:管理员通过对指定的目标或目标群应用策略来检查目标对策略的依从性,或者更严格的是禁止这些目标上违反策略的行为发生。
执行模式:SQL Server 2008的PBM支持4种执行模式,这4种模式决定了策略对目标的影响程度。这四种模式分别是:
按需(On Demand):这种模式下的策略可以有管理员自由的选择是否应用,例如管理员可以手动调用这些策略来检查目标的依从性,或者通过DDL Trigger来订阅这些策略。
更新时阻止(On Change - Prevent):这是最严格的一种,SQL Server 2008通过DDL Trigger的方式在订阅该策略的目标上发生操作时实施检查操作对策略的符合性,如果违反策略则回滚该操作,以达到强制策略的效果。
更新时记录(On Change - Log Only):SQL Server 2008通过Event Notification的机制在在订阅该策略的目标上发生操作时实施检查操作对策略的符合性,如果违反策略则发送消息,就将该违反操作通过Service Broker的队列发送进行记录。
按计划(On Schedule):通过SQL Agent的作业来调用策略对目标对象进行检查。
虽然PBM有以上四种执行模式,但是归总起来其实是两大种,一种是基于SQL Agent作业方式的On Schedule模式,而另外一种是基于Event机制的On Change模式。因此并非所有Facet都支持On Change模式,要支持On Change模式,那么Facet的状态改变必须可以通过事件捕获或者事务性的DDL操作,当然On Schedule和On Demand就没有这些机制,因为这两种模式无需参与到Facet状态更新的事务中去。
基于策略管理的架构图
对象(Facets):包括策略管理中某个方面的相关配置属性。例如在Surface Area中包括了像Database Mail Enabled以及CLR Integration Enabled之类的SQL Server功能的属性。
条件(Conditions):表示一个方面的状态。条件是基于单个方面的,并且可以被一个或多个策略使用。例如,DBA可以建立一个名为Minimal Surface Area的条件,在这个条件中将Surface Area Facet中的所有属性都设置为False。
策略(Policies):包括了用于约束单个或多个目标的条件。例如DBA可以创建一个名为Locked Down Server的策略,在这一策略中将Minimal Surface Area条件指派给某台服务器。
类别(Categories):包含一条或多条策略。数据库拥有者可以将一个或多个分类绑定到数据库上。例如,DBA可以创建一个名为Corporate DB Policies的分类,其中包含一条强制数据库对象命名规则的策略和一条强制数据库兼容级别的策略,并将该分类绑定到业务数据库上。通常所有数据库都绑定到默认分类,但是可以在服务器或数据库级别上将分类设置为激活(Active)或暂停(Inactive),这样管理员就可以灵活控制策略的强制性。
目标(Targets):目标代表像服务器、数据库、登录、表以及其他数据库对象各种被指派策略的实体。在一个SQL Server实例中的所有目标组成了一个目标层级。对于某个策略,DBA可以通过对目标层级进行筛选来定义一个目标集合。例如,DBA可以定义一个包含Production架构拥有的所有索引的目标集合。
为策略检查配置警报
如果某项策略被违反,SQL Server 2008会生成相应的警报,因此可以通过在SQL Agent中配置警报来监控这些事件,
执行模式 | 事件号 |
On Change - Prevent |
34050 |
On Change - Prevent | 34051 |
On schedule | 34052 |
On change |
34053 |
策略管理的安全性
属于PolicyAdministratorRole的成员才可以制定和修改策略定义,这个角色的成员是必须要小心控制的,因为恶意用户可以通过制定苛刻的策略来达到类似于拒绝服务攻击的效果。
基于策略管理的配置
基于策略管理的常规配置步骤为:
根据Facet创建Condition,Condition可以作为Policy的检查条件,也可以是用于确定策略应用范围的筛选条件。
引用已经创建好的策略来定义策略,同时可以在策略检查条件可以应用的对象集上附加筛选条件,例如一个检查Multiple Part Name对象状态的策略就可以有表、存储过程、视图、同义词等一系列的对象可以进行选择并附加筛选条件,默认的筛选条件是Every,也就是这个对象集中所有的对象。当然不是所有条件都可以充当筛选条件的,在二月CTP的测试中就发现包含LIKE运算符的表达式的条件就不能充当筛选条件。
如果需要可以在Server Restriction中定义需要应用策略的SQL实例条件。
如果需要还可以在Policy Management节点上定义策略组,并在策略的定义中将策略归入某个类别,然后由服务器管理员或数据库拥有者订阅某个策略组。不过要注意看看我的前一个帖子,默认策略组都是强制订阅的,要启用自选订阅要在策略组管理中设置。
然后就等着策略帮你自动管理SQL Server了,这就看策略定义时选择的执行模式了。
ASP编码教程:如何实现/使用缓存
[ASP]2015年4月15日ASP编码教程:asp缓存的分类
[ASP]2015年4月15日ASP编码教程:何谓ASP缓存/为什么要缓存
[ASP]2015年4月15日ASP编码教程:asp实现的sha1加密解密代码
[ASP]2015年4月15日ASP编码教程:asp执行带参数的sql语句实例
[ASP]2015年4月14日