SQL Server 2008 R2 多服务器管理：修改临界值
修改临界值
对于通用控制点，微软设置了相当数量的默认值。你可以通过在工具浏览器中选中的 通用控制点下面点击“工具管理选项”来修改设置。默认情况下，对所有过度利用的设置， 临界值都是 70%，所有未充分利用设置的临界值是 0%。70%的过度利用设置可能对大部分 人来说很合适，但是你可能想调整 0%的未充分利用设置，这取决于你给定系统的标准服务 器负载。
在这里，你可以每隔一定周期调整一次估计值，以及可以调整在 CPU 报警被触发之前， 它们必须被违反多少(与估计值的偏差程度)。
对于高利用率的警报，可以用一个滑动条从短到长进行调整来实现，短的可以是一小 时，长的可以达到一周。然后，你可以设置警报触发之前违反量必须达到的百分比。
对于低利用率警报，滑动条就非常简单了，只需在相同百分比范围设置，时间段是从 一天到一个月。
TT 数据库技术专题之“SQL Server 2008 R2 中文教程” Page 33 of 82
如果需要的话，你可以通过编辑受管实例，点击实例属性中的“策略明细”标签页来 指定针对特殊实例的策略。在这里你可以给实例配置特殊设置，如果这些实例与受通用控 制点管理的其他服务器应用的全局策略不一致的话。
最后的步骤
现在你已经有了这些信息了，关键是找到用它来做智能决策的方式。通过简单的一瞥， 你可以看到哪些服务器负荷过度了，哪些服务器上还有可用空间。这样你就应该可以更好 地利用你的环境。简单来说，如果你知道甲服务器上的数据库应用占用高 CPU 负载，而乙 服务器占用的 CPU 负载很低，那么那个数据库应用可能就很适合从一台服务器移到另一台 服务器。
(作者：Denny Cherry 译者：冯昀晖 来源：TT 中国)
原文标题：SQL Server 2008 R2 多服务器管理：修改临界值 链接：http://www.searchdatabase.com.cn/showcontent_33012.htm
TT 数据库技术专题之“SQL Server 2008 R2 中文教程”
Page 34 of 82
分析 SQL Server 2008 R2 数据层应用的优缺点
利用 SQL Server 2008 R2 和 Visual Studio 2010 的紧密集成，微软给我们带来一个 称为数据层应用(data-tier applications ,DAC)的新功能。将 Visual Studio 的 DAC 部 署到 SQL Server 是通过一个数据层应用程序包，即 DACPAC 来完成的。
优点
DACPAC 相比较在 SQL Server 上部署细微的应用程序更改来说变化很大。它允许代码 保持在现有源码控制范围之内，并为开发人员提供一个简单的方法在已熟悉的 Visual
Studio 环境中编辑 SQL Server 对象。这意味着开发人员可以对他们开发的数据库进行所 有的编码，然后将所有更改打包成一个 DACPAC 进行上线。该 DACPAC 也可以被 DBA 处理后 发布到生产或测试环境。
DACPAC 通过数据层来处理数据库更新，为开发人员提供了一个简易的方式来进行数据 库开发，使得.NET 开发人员有能力来编写数据库的表、存储过程、视图和函数。
缺点
首版的数据层应用存在几个问题。第一个问题就是 DACPAC 并非支持 SQL Server 引擎 的所有特性，包括在 SQL Server 的 Service Broker、CLR 对象和最为重要的 SQL Server 安全。
现在，使用既定的脚本可以支持所有的这些特性，不过这不是最好的解决办法，为了 创建和管理对象以及安全性，开发人员必须知道所有适当的 T - SQL 命令。
目前 DACPAC 只能支持到 SQL Server 2008 R2，而且他们必须使用 Visual Studio 2010 来开发。
(作者：Denny Cherry 译者：宋广磊 来源：TT 中国)
原文标题：分析 SQL Server 2008 R2 数据层应用的优缺点 链接：http://www.searchdatabase.com.cn/showcontent_35636.htm
Page 35 of 82
TT 数据库技术专题之“SQL Server 2008 R2 中文教程”
数据层应用（DAC）与 SQL Azure 数据库的协作
DACPAC 与数据层应用相关的最大问题是如何将 DAC 的更新发布到 SQL Server。这通 过一个临时名称创建新数据库，在数据库中生成新的对象，然后将现有数据库中的数据移 动到新数据库中来完成。在所有数据被转移后，运行既定的脚本，现有的数据库被删除， 新数据库更正为其名。
这种发布技术导致数据库至少需要两倍的数据空间，以及足够的日志空间至少能容纳 目标数据库事务日志中的最大对象。例如，你的数据库是 5 GB、最大数据表是 500 MB， 你需要能够容纳 5 GB 数据库和能够容纳 500 MB 数据表的事务日志的磁盘空间。
这项技术有几个问题。首先，你的事务日志变得毫无用处，这是因为数据库被重命名， 在数据库的升级过程中不能恢复事务日志。
另一个问题是如果在数据库中使用 SQL Server 的 Service Broker，升级过程队列中 的所有信息会丢失，在升级过程发布之后、完成之前数据表中所做的任何数据更改也会丢 失。
现在可以为一个现有的数据库开发 DACPAC 以使得它并不仅仅为新项目所使用，但并 非所有的数据库都可以成功地转换为 DACPAC。
为什么要使用数据层应用程序呢?
看完这一切，第一个问题可能就是为什么还要使用 DACPAC?答案很简单，即 SQL
Azure。也许你已经意识到 DACPAC 支持的特性与当前版本的 SQL Azure 的特性相当吻合。 由于少量数据可以通过 Azure 适配到数据库(1 GB 或 10 GB，取决于购买的数据库大小)， 所以使用 SQL Azure，你不必担心备份，这已被此方案的冗余技术所解决。
只要你能根据 DACPAC 平台的条件工作，为 SQL Azure 数据库设计的数据层应用完全 能够被用来处理本地的内部数据库。
由于 DACPAC 系统所使用的发布技术，建议您不要为 Tier 1 应用程序或者为 SQL Azure 支持的大于 10GB 的数据库应用程序使用 DACPAC。这样做将在新旧数据库间移动数 据的升级过程中需要更长的停机时间。
显然微软还没有作出有关 DACPAC 第二版的任何通告，这一版本据说能够支持 SQL Server 2008 R2 的其他功能集并允许 DACPAC 去支持微软 SQL Server 的早期版本。
TT 数据库技术专题之“SQL Server 2008 R2 中文教程” Page 36 of 82