SQL Server 2008已经发布，我们可以看到它在各方面都有了显著的进步，这些让人侧目之处和失望之处都有可能极大地影响大型企业的采购意向。
微软SQL Server 2008的开发代号是Katmai，这个名字来源于阿拉斯加半岛东端阿拉斯加州北部阿留申山区的一座活火山，对数据库而言，可能并不是个最好的比喻（嘿嘿，目前为止，Katmai火山还没有在我头上爆发过）。低调的Katmai看起来似乎是Yukon的一个好的接班人，而Yukon是SQL Server 2005的开发代号。
在基于对SQL Server 2005彻底的、面向企业的改进之后，Katmai为大规模部署带来了非常引人注目的特性，比如数据库引擎中的数据及备份压缩、稀疏列、压缩与过滤索引，这些功能都是为了节省存储空间，环保、绿色；另外，别忘了还有Change Data Capture，其在表中捕捉生成数据的差别，以便更新数据仓库。
这些都只不过是冰山一角（喔，不是冰山是火山），还有许多其他的新特性，如基于策略的管理——这是针对中小企业和大型企业的，不仅这些，SQL Server 2008的各个方面都让人留下了深刻的印象。
更多的数据，更少的存储空间
一般来说，数据库中有两种类型的压缩：行压缩与页压缩。实际上，它们以不同的方法压缩数据，因此，很有必要理解两者的优势所在及它们的工作方式。行压缩是真正的压缩，为什么数据库引擎会删除列尾未使用的空间呢？当然这是为了节省空间。这正是SQL Server在vardecimal压缩中使用的同一技术，微软只不过把它扩展到其他数据类型上了。
而页压缩使用的是众所皆知的字典压缩，它把每页中的数据标准化之后并保留一个查找指针。这也是Oracle Database 11g所使用的技术，只不过Oracle称之为Oracle高级压缩。在此，我们无须对两种压缩方式了解过多，但必须知道SQL Server的页压缩包括了更低级的行压缩，换句话来说，假如你打开了页压缩，就自动打开了行压缩。
在SQL Server 2008中，微软已经包含了几个存储过程，以方便你在开始压缩之前，就可以估计使用哪种压缩方法之后，两者的节省水平，以及解压数据库之后，数据将会扩展到多大。这是一个非常重要且体贴的功能，因为你不仅需要了解是否值得花时间压缩，而且还要知道磁盘是否处理得了还原后未压缩的数据。但要紧记的是，这些存储过程是基于小范围的统计上的随机数据采样，假如碰巧遇到一个数据上的采样失误，那么就会得到错误的估计结果。
另外，微软实现压缩的方法，节约的不仅仅是存储资源，数据还可以在内存中保持压缩状态，只在读取时才解压，这意味着你可以把更多的数据页装入内存中，由此减少磁盘读取次数，而CPU用于解压的时间，也远远少于磁盘寻道的时间。
稀疏列允许你存储空值而无须占用物理空间，假如在一张“巨大”的表中，列有许多空值，可能会浪费大量的磁盘空间来跟踪这些空值。而把空值存储在稀疏列中则不会占用任何空间，存储需求也会随之降低。
在使用稀疏列时要非常留意一点，它们与压缩不兼容，坦白地说，这是微软的一大失误。希望本着为用户着想的原则，在某个Service Pack中就能更正这个问题，而不是要等到下个版本。同时，假如你在表中也定义了稀疏列，那么也不要指望会压缩表中的数据，真是不知道微软是怎么搞的，这些本不应该出现在正式产品中的。假如非要说稀疏列与压缩他俩是一对完美的组合，那“如花”可能也配得上金城武了。
压缩索引还像码事，至少名符其实，这又是节省存储空间的另一个方法。过滤索引可以在索引上放置一个where子句（如某条查询），以便只有表的一部分被索引。听上去似乎不太妥当，但在某些情况下你可能就会想要过滤某些索引了，举个例子来说，在使用稀疏列时，有了过滤索引就无须保持一个包含了主要是空值的索引，你可在稀疏列上放置一条索引，只取那些非空值就行了。这样做以后，只有那些带有实际值的行会被索引，而索引的体积也会相应大幅减小。
工作负荷是好，还是差？
Resource Governor是微软在SQL Server中真正对资源管理的一次尝试，老实讲，根本就比不上Oracle，但仍是一个好的开始。SQL Server 2008允许你在内存和CPU中定义资源限制，但在重负荷工作情况下仍然差强人意。
微软对此的回应是，Resource Governor不是旨在满足重负荷工作要求，在这第一个版本中，目标仅是管控工作负荷中的那些资源，以防止它们变成“野”进程。当然了，这仍未解决过度占用磁盘或处理器时间的问题。在SQL Server 2008中，假如一个进程开始占用过多的资源，那么也没有办法自动把它挪到一个定义好的Resource Governor中，也就是说，一个进程要么在资源上受Resource Governor管控，要么就不受控。
其实这个特性最大的受益者是OLTP（在线交易或联机事务处理）系统，其只会产生一些轻量级的数据，假如不想它占用过多服务器资源，可把查询进程放入它们自己的Resource Governor中，以管控资源使用量，使服务器的大部分功率都用于OLTP负载，赚取真正的“真金白银”啊。
CDC（Change Data Capture，改变数据采集）是一个非常好的功能，我想对那些整日与ETL（取出、转换、加载）处理“扭打”的数据库管理员来说，它会非常受欢迎。CDC允许SQL Server在定义的列中，捕捉到哪些行列已改变，并把变化的结果放入到一张可被ETL查询的单独的表中。好处显而易见，对哪些行被插入、删除或更新，就不再需要广泛地进行查询了。当前来说，在一张表中发现这些操作并不容易，经常还需要编写代码才能找出来。但有了CDC之后，你就可在数据库级别上定义这些审计策略，不用修改程序代码，一边看报纸喝茶去啰。
SQL Server 2008还带来了基于策略的管理（PBM），其是一种可为任何事件定义策略（规则）的方法，可在服务器超出策略时，要么强制执行，要么发出警报。你几乎可在策略中定义任何事情，甚至像“表名不能以tbl打头”这样的策略也可以强制执行；还可以定义如“所有数据库都应每天备份，假如某台服务器缺少备份，应发出警报。”PBM正成为SQL Server发展中一个非常强大的工具，至少我也非常喜欢它。
SQL Server 2008已经发布，我们可以看到它在各方面都有了显著的进步，这些让人侧目之处和失望之处都有可能极大地影响大型企业的采购意向。
微软SQL Server 2008的开发代号是Katmai，这个名字来源于阿拉斯加半岛东端阿拉斯加州北部阿留申山区的一座活火山，对数据库而言，可能并不是个最好的比喻（嘿嘿，目前为止，Katmai火山还没有在我头上爆发过）。低调的Katmai看起来似乎是Yukon的一个好的接班人，而Yukon是SQL Server 2005的开发代号。
在基于对SQL Server 2005彻底的、面向企业的改进之后，Katmai为大规模部署带来了非常引人注目的特性，比如数据库引擎中的数据及备份压缩、稀疏列、压缩与过滤索引，这些功能都是为了节省存储空间，环保、绿色；另外，别忘了还有Change Data Capture，其在表中捕捉生成数据的差别，以便更新数据仓库。
这些都只不过是冰山一角（喔，不是冰山是火山），还有许多其他的新特性，如基于策略的管理——这是针对中小企业和大型企业的，不仅这些，SQL Server 2008的各个方面都让人留下了深刻的印象。
更多的数据，更少的存储空间
一般来说，数据库中有两种类型的压缩：行压缩与页压缩。实际上，它们以不同的方法压缩数据，因此，很有必要理解两者的优势所在及它们的工作方式。行压缩是真正的压缩，为什么数据库引擎会删除列尾未使用的空间呢？当然这是为了节省空间。这正是SQL Server在vardecimal压缩中使用的同一技术，微软只不过把它扩展到其他数据类型上了。
而页压缩使用的是众所皆知的字典压缩，它把每页中的数据标准化之后并保留一个查找指针。这也是Oracle Database 11g所使用的技术，只不过Oracle称之为Oracle高级压缩。在此，我们无须对两种压缩方式了解过多，但必须知道SQL Server的页压缩包括了更低级的行压缩，换句话来说，假如你打开了页压缩，就自动打开了行压缩。
在SQL Server 2008中，微软已经包含了几个存储过程，以方便你在开始压缩之前，就可以估计使用哪种压缩方法之后，两者的节省水平，以及解压数据库之后，数据将会扩展到多大。这是一个非常重要且体贴的功能，因为你不仅需要了解是否值得花时间压缩，而且还要知道磁盘是否处理得了还原后未压缩的数据。但要紧记的是，这些存储过程是基于小范围的统计上的随机数据采样，假如碰巧遇到一个数据上的采样失误，那么就会得到错误的估计结果。
另外，微软实现压缩的方法，节约的不仅仅是存储资源，数据还可以在内存中保持压缩状态，只在读取时才解压，这意味着你可以把更多的数据页装入内存中，由此减少磁盘读取次数，而CPU用于解压的时间，也远远少于磁盘寻道的时间。
稀疏列允许你存储空值而无须占用物理空间，假如在一张“巨大”的表中，列有许多空值，可能会浪费大量的磁盘空间来跟踪这些空值。而把空值存储在稀疏列中则不会占用任何空间，存储需求也会随之降低。
在使用稀疏列时要非常留意一点，它们与压缩不兼容，坦白地说，这是微软的一大失误。希望本着为用户着想的原则，在某个Service Pack中就能更正这个问题，而不是要等到下个版本。同时，假如你在表中也定义了稀疏列，那么也不要指望会压缩表中的数据，真是不知道微软是怎么搞的，这些本不应该出现在正式产品中的。假如非要说稀疏列与压缩他俩是一对完美的组合，那“如花”可能也配得上金城武了。
压缩索引还像码事，至少名符其实，这又是节省存储空间的另一个方法。过滤索引可以在索引上放置一个where子句（如某条查询），以便只有表的一部分被索引。听上去似乎不太妥当，但在某些情况下你可能就会想要过滤某些索引了，举个例子来说，在使用稀疏列时，有了过滤索引就无须保持一个包含了主要是空值的索引，你可在稀疏列上放置一条索引，只取那些非空值就行了。这样做以后，只有那些带有实际值的行会被索引，而索引的体积也会相应大幅减小。
工作负荷是好，还是差？
Resource Governor是微软在SQL Server中真正对资源管理的一次尝试，老实讲，根本就比不上Oracle，但仍是一个好的开始。SQL Server 2008允许你在内存和CPU中定义资源限制，但在重负荷工作情况下仍然差强人意。
微软对此的回应是，Resource Governor不是旨在满足重负荷工作要求，在这第一个版本中，目标仅是管控工作负荷中的那些资源，以防止它们变成“野”进程。当然了，这仍未解决过度占用磁盘或处理器时间的问题。在SQL Server 2008中，假如一个进程开始占用过多的资源，那么也没有办法自动把它挪到一个定义好的Resource Governor中，也就是说，一个进程要么在资源上受Resource Governor管控，要么就不受控。
其实这个特性最大的受益者是OLTP（在线交易或联机事务处理）系统，其只会产生一些轻量级的数据，假如不想它占用过多服务器资源，可把查询进程放入它们自己的Resource Governor中，以管控资源使用量，使服务器的大部分功率都用于OLTP负载，赚取真正的“真金白银”啊。
CDC（Change Data Capture，改变数据采集）是一个非常好的功能，我想对那些整日与ETL（取出、转换、加载）处理“扭打”的数据库管理员来说，它会非常受欢迎。CDC允许SQL Server在定义的列中，捕捉到哪些行列已改变，并把变化的结果放入到一张可被ETL查询的单独的表中。好处显而易见，对哪些行被插入、删除或更新，就不再需要广泛地进行查询了。当前来说，在一张表中发现这些操作并不容易，经常还需要编写代码才能找出来。但有了CDC之后，你就可在数据库级别上定义这些审计策略，不用修改程序代码，一边看报纸喝茶去啰。
SQL Server 2008还带来了基于策略的管理（PBM），其是一种可为任何事件定义策略（规则）的方法，可在服务器超出策略时，要么强制执行，要么发出警报。你几乎可在策略中定义任何事情，甚至像“表名不能以tbl打头”这样的策略也可以强制执行；还可以定义如“所有数据库都应每天备份，假如某台服务器缺少备份，应发出警报。”PBM正成为SQL Server发展中一个非常强大的工具，至少我也非常喜欢它。
SQL Server 2008的闪光之处
SQL Server 2008带来了太多的新功能，片言之间难以表述，笔者甚至都还没有试一下完全重写后的SQL Server Reporting Services，或体验一下SQL Server Integration Services、SQL Server Analysis Services中的全部功能，还有新的数据仓库、交互式Dundas向下搜索报告、IntelliSense（智能感知）、新的活动监视器、集成PowerShell等等。
对多数大型企业来说，我认为SQL Server 2008最大的亮点在于数据压缩及CDC，因为两者都会影响到企业的预算。Resource Governor是一个非常好的功能，但目前它还比较“稚嫩”，局限太多，还未达到微软期望的水平，相信再经过几个版本，它定会不负众望。
压缩及过滤索引这次想必给大家带来了不一样的感觉，虽然过滤索引存在上面提到的一些小问题，但假如你把它们用对地方，也能看到所期望的性能提升。另外，在其他工具方面也有了一些重大的改进，但对数据库管理员来说，他们可能要失望了，因为这些改进都是针对开发人员的。