解析SQL Server数据库系统的编译_Mssql数据库教程

推荐：教你SQL Server日志清除的两种方法
方法一 一般情况下，SQL数据库的收缩并不能很大程度上减小数据库大小，其主要作用是收缩日志大小，应当定期进行此操作以免数据库日志过大 1、设置数据库模式为简单模式：打开SQL企业管理器，在控制台根目录中依次点开Microsoft SQL Server--SQL Server组--双

你知道SQL Server这么庞大的企业级数据库服务器产品是如何build出来的吗?

这有些相关的数据：

每个build 的大小在300GB左右。

每个完整的build需要几十台高端的服务器运行2.5天。

每个完整的build由几千个job、10000多个参数组成。

我们每天同时做20个左右的build，每周130个。

位于美国微软总部雷蒙德和北京的build团队能够保证build全天24小时不间断的顺利进行。

从去年至今，我们build team已经成功而准时地完成了数以千计的build。

也许你会问：你们的build怎么这么大?怎么需要这么长的时间?为什么你们每天要做这么多build?

为什么我们的一个build这么大?比如说你的32位中文零售开发版SQL Server的DVD，包括工具和帮助文档是4GB，那么你可以这样估算一下：首先加上一些内部的build信息和统计，以及用于debug的Symbol，然后乘以2(retail版，debug 版)，再乘以3(CPU 类型：x86、x64和ia64)，再乘以所有的版本数(企业版、开发版、标准版等)，最后再乘以支持的语言数。不只1个TB 了吧?J 幸好SQL 2008 的setup 团队采用了consolidated setup模式，这样在一个语言包中，安装程序可以判定你的CPU类型并根据你输入的产品序列号，自动安装对应的版本。由此我们的build才压缩到了300GB。

为什么我们的一个build需要这么长时间?Build这么庞大的企业级数据库服务器产品是一个极其复杂的过程，况且SQL Server的build 系统已经是微软内最为高效的系统之一。她是图形化用户界面并且高度自动化的。历经60小时，多数build会顺利的自动完成并通知相关人员其build的状态及信息。如果build失败，其也会提供详细的错误信息用于debug。SQL Server的build 系统不仅如此易用和高效，同时可以灵活的适应某些特殊的需求和build工作流。SQL Server的build 系统是由Windows Workflow Foundation驱动的，其数以千计的job被并行或串行的分发到几十台 build机器上并完成。build的过程包括：

将几十GB的源文件及相关的所需文件和资源同步到build机器上

源代码静态分析

编译所有的可执行文件和测试文件并签名

生成系统数据库

优化

本地化

制作安装文件和安装包并签名

索引Symbol和源文件

我们每天做这么多的build正体现了我们如何支持整个SQL Server工程体系和构架：

首先需要声明的是我们随时都在为多个产品提供支持，比如当前的SQL Server 2005和即将发布的SQL Server 2008。

在SQL Server 2008的工程体系和构架中，我们将每个需要增加或增强的功能特性做成一个单独的分支，在这个功能特性开发和测试完成后，其代码才会合并到SQL Server的主线代码中。因此根据功能特性的优先级和大小，SQL Server分成了几十个不同的团队，每个团队包括了架构师、项目经理、开发和测试人员，帮助及案例文档专员，甚至科学家和科研人员。每个分支都需要build来进行及时的测试，因此有了这个我们当前每周需要的build个数——130。当build结束后，Test Execution team和其分支团队会执行自动测试来确保其代码的质量符合严格的要求和标准。最后当这个功能特性开发和测试完成后，其代码将会融入到SQL Server的主线代码中，然后其它各个分支团队将重新获取主线代码并融合其分支的当前代码，来保证和主线代码的同步。

分享：怎样解决SQL Server数据库权限冲突
在SQL Server数据库中，主要是通过角色来继承相关的权限。但是，这个权限继承很容易造成权限上的冲突。如现在有个销售员账户SALE1，有一个销售部门角色DE_SALES。其中销售部门角色DE_SALES具有查询所有客户信息，即CUSTOM表的权限。但是销售员账户SALE1其由