SQL Server 2000升级到2005注意屎项

admin

SQL Server 2000升级到2005注意屎项
8 y+ W6 ^4 W7 X/ ~" o
5 [# i# `' U# q( e8 Y! J, o
( U9 k, I; w$ n8 c  ]8 o1 ~
$ P5 I1 v2 C" Y% Z6 I! o9 a
! E- D" @  S: _( s) T: R+ G

+ c: Z2 R9 A0 e+ j- V! H
- ?+ `% h) a/ u+ x: n2 o  r' X6 _% \
$ m$ Y: L( S/ R: q! b! ~( x6 U　　如果你计划将数据库从SQL Server 2000 升级到 SQL Server 2005。你在升级之前一定会测试每样东西，并且证明应用程序是稳定的。即使这样，如果升级之后发生任何问题的话，你仍然会想要确保你仍然可以回退到原来的环境中去，并且保证不丢失任何的数据修改。
　　这篇文章列出了保持原有数据(SQL Server 2000)中数据最新，直到新的环境被证明是最棒的方法。
5 X, v! c, L" X/ o- y& Y' _　　保持原有SQL Server环境最新的方法：
+ d: m5 q: T0 H9 _5 x6 A6 r7 L! M- u　　在SQL Server中，有一些方法可以用来复制数据修改到另外一个数据库中去：
　　1、日志传送
　　2、拷贝数据库任务
0 G$ g5 x' d, z4 P1 N+ X' L　　3、复制(事务，快照)
　　4、SQL 追踪
* v% z! `( h- {7 D& n　　5、编程(触发器、DTS，BCP等)
0 b) R' {4 v& m) @- b! w- l　　6、第三方工具
　　下面我们来讨论其中的三种方法：
# z( _* x( j3 F! Q　　日志传送
% b' {6 A2 j2 h9 k  ]- m　　我们可以在SQL Server 2005数据库(主数据库)和SQL Server 2000数据库(从数据库)之间传送日志吗?
9 ~  v/ r* u! l. ^3 j" i9 f- a　　我努力在因特网上寻找这个问题的积极答案，但是很不走运。然后我试图自己创造性地寻找一种解决方法，使用产品自带的标准工具。也没有门，天啊……我只能在第二个数据库中使用WITH NORECOVERY将日志从SQL Server 2000 传送到SQL Server 2005，没有其他办法。所以，答案是“没有”，使用日志传送是不现实的。
/ Z  N6 n4 q7 O/ Y4 K: W4 t  ^, N　　拷贝数据库
　　不幸的是，当开启拷贝数据库向导的时候，当源和目标版本不同的时候，你就会收到错误信息，不能继续下去。
; z5 b( z# J" S2 b2 O3 o0 k　　复制
　　事务复制
8 _- a. \8 [* ^7 y7 v+ r! X　　事务复制是在两个版本之间工作的。这个解决方案有两个问题：
　　有一些SQL Server的版本不能作为PRIMARY 或者DISTRIBUTOR参加复制模型，《SQL Server 2005 Features Comparison》一书中对此有详细描述。
　　没有定义Unique键的表不能参加这个模型。
　　快照复制
) I& q+ w" S$ d$ a3 [- b  z　　这个解决方案有效，但是也有几项例外。例如，如果表中有用户自定义数据类型，并且必须在表被创建之前创建，那么由于在SQL Server2000没有CREATE TYPE这个命令，就会失败。
　　SQL 追踪
　　用SQL Server Profiler 或者SQL Trace可以捕捉到工作量，并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。
　　这个解决方案存在的问题包括：
! j% {6 s0 ]1 m7 D　　1、执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了，而这个操作不是这一系列命令中的一个，那么脚本就无法使其发生关系，因为“会话”无法被Traces识别了。
　　2、如果在两个版本之间，命令语法有区别，那么在从数据库中的执行一定会失败。
9 G* n8 Z% w5 U! J1 d9 g: ?　　编程
# p6 n! V6 ]4 G, T　　如果你有一小批数据库要移植，那么你可能会考虑编写一个数据库组件来传输数据的修改。
　　示例：
: {' a8 V3 M1 C+ e6 f- F　　・ 使用触发器――这可能会影响性能，因为触发器是事务的一部分。
　　・ 使用DTS或者BCP来传输数据――这种方法在很大程度上依赖数据量的大小。
+ @# R; g; n! B$ _5 Y* N4 V1 B, X　　第三方工具
　　你可以使用第三方工具，例如Log Readers来从事务日志、脚本中读取SQL 命令，然后在从数据库中执行它们。还有，虽然我无法自己找到这样的一个工具，但是在SQL Server 2005中肯定会有一个工具能够备份事务日志，并且在SQL Server2000中顺利地重新存储它们。
2 _  H# s' ?: p" P0 J; K0 E　　其它
2 k: n& `) B* _; }5 [* W3 C% H　　你还可以创新……
* s4 d* y- e" S, S) h　　例如，在某些情况下，你可以将日志传送到从SQL Server 2005数据库中，把它的兼容级别改为80，然后备份并重新存储到第三个数据库中去。
　　结论
* L( Q+ k2 u' k- L　　对于关键的数据库，保留要升级的数据库的旧的版本，以及最新的数据修改，以便在需要回滚的时候用到，确实是个好主意。
1 B- a9 g) Y' W6 Q( U3 j5 q　　但是……任何事物都没有“最好的解决方法”。你必须分析你的数据库特点和结构，然后决定针对你的需求的最佳解决方法。就我个人来说，我倾向于认为复制是最快最可靠的解决方法。