SQL Server 2000 -SQL Server 2005升级手记

先说一下这次升级，我最大的体会：我觉得一个企业没有办法用一个系统，特别是当一个企业越做越大的时候，所以一个企业不可避免地就会有各种各样的系统，这些系统可以从业务上分为各种不同的系统，同时也可以在技术上分为数据层，中间层，展现层等，但是无论如何，系统间从架构上说一定要做到松耦合，这是架构师必须考虑的问题，否则后续麻烦很多。比如SQL Server 2005, 我之前一直是比较推崇的，微软随数据库服务器免费发布了ETL服务器和报表服务器，从性价比上还是非常实用的，SSIS比以前SQL 2000的DTS相比总算一个ETL产品了，而且用户不用掏钱，何乐而不为呢？集成性一直是微软产品的特点，虽然windows集成了IE招来了很多官司，但是微软还是要坚持，我之前也没觉得什么不好，现在SQL Server本身更是集成了各种工具，看起来也不错，但是这样一次简单的升级，就会让问题都暴露出来，原本只是简单地升级数据库服务器，数据结构都不变，看起来应该很快搞定，但是因为使用微软外围的DTS等一些列工具开发的诸多程序，问题变得很复杂，不得不对这些程序进行修改和重新测试。投入不算，因为升级时间窗口通常比较短，有可能还会造成数据丢失等问题。

从这个层面上讲，我觉得从企业数据仓库建设，数据库服务器，ETL服务器，报表服务器，一定要做到独立性，最好选择不同厂商的产品，以避免厂商升级产品的时候，企业的相关产品不得不被动地大规模的升级，让问题集中爆发；同时也避免问题互相牵扯，使得问题错中复杂。

 

下面讲讲SQL 2000->2005的升级问题：（以下问题只是基于特定环境和当时知识能力碰到的问题，换了情况不一定发生）

1.升级前准备:我们在另外一台机器上安装了2005软件，使用Upgrade adivsor,对2000的服务器做了全面的检查,其中根据advisor的提示，预先对2000做了一定的调整，减少了部分升级工作，比如：2005不支持对象名称中用 / 符号，我们预先修改了这些对象名称。

升级准备工作中，应对2000系统的对象做广泛细致的调研，形成报告和check list,以便于迁移过程中测试和检查。特别是针对升级中可能碰到的问题做充分的测试，以保证升级在规定的time window中完成。升级需要检查的对象包括：a)数据库配置 b)User logins c)Database Right d)Job e)DTS f)Windows Schedule Task (这个有时候会忽略) g)System Right H)Maintainence Plan I)脚本(包括各种宏等,同时特别注意，2000中DTSRUN这个功能不可用了，注意一下可能需要修改的脚本) J)其他，想不到的是我们用了2000的SQL XML功能，可以把SQL写在http request中，直接返回XML执行结果。而2005不直接支持这个功能，后来我们通过手动编写aspx程序，解决了这个问题。 

2.升级方法：本次是从2000到2005的标准版，请注意是标准版，因为现场测试，标准版的安装程序不支持在2000的基础上直接在安装过程中升级，而企业版在安装过程中有个选项，可以直接升级2000的数据库。这样我们的升级方法不得不采用：备份数据->卸载2000->安装2005->恢复数据的过程。

3.备份选择：考虑到大数据库文件全量备份和恢复会耗费较长的时间（我们的数据库大概200GB左右，Copy个文件花几个小时时间），我们采用了备份-》恢复 和 Detach->Attach相结合的方式，大数据库直接detach-attach，节省了一定的时间。

4.DTS->SSIS的升级：

4.1对于DTS的备份，我们做了双重备份，一方面备份了msdb这个系统库，另外一方面备份了DTS到文件；

4.2SQL Server支持从文件和msdb（需要连接2000服务器）升级DTS两种方式，但是从文件转换，每次只能选中一个文件，非常不方便，如果有几百个DTS，肯定死掉了。因此，对于我们这种先卸载后安装2005软件的升级方式，强烈建议：在卸载2000前安装一个2005软件，把所有DTS先转换到2005的DTSX; 或者把2000的msdb还原到另外一个2000的数据库服务器上，用新安装的2005从那台2000上升级。

4.3DTS->SSIS转换可能发生的问题：

4.3.1如果在2000的package里面调用了其他dts package, 到2005下面，会转换成事务流中一个控件：调用SQL 2000 DTS Package，请注意，在工具箱下面，那个控件下面，有另外一个控件叫调用 SSIS 包，应该把原来的调用SQL 2000 DTS Package替换为新的控件，否则调用失败。

4.3.2文本文件的抽取式最容易出错的地方，以前2000对文本文件的管理不太严格，2005可能为了体现加强元数据管理的思想，增加了很多对数据的检测，比如2000中一个字符被截断，一般不会报错，但是2005中就出错失败；另外一个奇怪的转换问题是，有时候DTS-SSIS转换器会把行映射转反掉，比如按照原定义，从前到后，字段应该是col1, col2,...,col5;转换后变成col5对应原来的col的数据，这样数据就乱了，没办法需要重新映射；本次升级，几乎每一个文本文件的抽取DTS, 我们都手工做了修改；

5.Job：如果Job里面命令执行了DTS,那么转换后可能还是dtsrun的命令调用，2005已经不支持这个命令了，不得不重新编辑Job属性，重新选择2005的SSIS Package.

6.DTSRun命令：我们的数据库服务器很多处使用了改命令，该命令后面可以接一个加密的串表示DTS package的名字等其他信息，但是不幸的是该加密的过程视乎是不可逆的，并且2005也不再支持该命令，但dts转换程序并不能把该调用直接转换成替代命令，不得不挨个修改；另外应为加密命令无法逆向解释，这样如果我们没有文档，我们就没办法知道原先Job调用的dts package是什么，这样也就无法用SSIS package改写

7.Job: 我们备份了原来的2000下面的Job成一个脚本，并用该脚本在2005下直接还原了2000的Job，我们修改了Job,调用了对应的SSIS package, 不幸的是问题还没结束，Job调用SSIS package, SSIS package中如果有数据库连接，并且不是windows认证，那么因为2005的Package都有个属性叫ProtectionLevel, 密码可以再BIDS中存在，并且在BIDS中调试时也能通过,但是发布到SSIS,通过Agent调用将不能直接获得密码，而必须通过配置文件的方式，把密码传递给Job,否则Job执行将失败。

8.SMTP：2005下发邮件需要smtp协议的支持，不幸的是本项目所在的客户网络上全面禁用了smtp协议，无法使用2005发邮件的功能，这个也是本项目疏忽的地方，最后请客户把smtp协议对该服务器开放，解决的问题，但是耽误了升级时间。所以对于升级前的测试，一定要认证。尽量能对每个问题做出验证，这样才能保证升级的平滑。

 

写着么多文字真是不容易啊。