SQL Server 2000升级到2005注意屎项
T. e/ R! U2 J1 B3 l3 m& [( g) O+ i5 l; X4 c0 `0 G2 u9 K
' A% e) w3 A4 V8 U
# p& t% {0 \! g
% q6 T A. h, s! w- N
4 ]& }, n, h/ Q4 m
0 @5 R/ D$ Z0 G' L9 Z
) w& K* i/ Y0 P5 p% k6 i- P" m( w6 P$ g
如果你计划将数据库从SQL Server 2000 升级到 SQL Server 2005。你在升级之前一定会测试每样东西,并且证明应用程序是稳定的。即使这样,如果升级之后发生任何问题的话,你仍然会想要确保你仍然可以回退到原来的环境中去,并且保证不丢失任何的数据修改。
1 v. \, _8 a, _: V/ I+ Y 这篇文章列出了保持原有数据(SQL Server 2000)中数据最新,直到新的环境被证明是最棒的方法。6 W4 ~" y# V. J& y# n" z6 _* A
保持原有SQL Server环境最新的方法:0 I9 ^2 ? T+ {' Y/ M# k
在SQL Server中,有一些方法可以用来复制数据修改到另外一个数据库中去:
6 r2 E- k9 d5 e1 C 1、日志传送* T! z' V) y) @6 u9 i) Q
2、拷贝数据库任务
# K. j4 C% |8 O7 M+ j$ h$ X! u6 ~$ T 3、复制(事务,快照)
; I: G# s. w( }! E# f; f 4、SQL 追踪
2 t' ? D2 W0 }' g) O* L 5、编程(触发器、DTS,BCP等)' y* g! z$ K2 f* i! a
6、第三方工具5 M5 O! N' P6 K1 ?8 r+ j
下面我们来讨论其中的三种方法:
0 h5 Z8 L/ g% Z3 b" M 日志传送
- R- w$ K9 n# O9 d) r 我们可以在SQL Server 2005数据库(主数据库)和SQL Server 2000数据库(从数据库)之间传送日志吗?( X& b4 `' L. \: L M7 A& S0 l
我努力在因特网上寻找这个问题的积极答案,但是很不走运。然后我试图自己创造性地寻找一种解决方法,使用产品自带的标准工具。也没有门,天啊……我只能在第二个数据库中使用WITH NORECOVERY将日志从SQL Server 2000 传送到SQL Server 2005,没有其他办法。所以,答案是“没有”,使用日志传送是不现实的。
$ b3 k) u4 F! A) G; ~7 H: ] 拷贝数据库# {0 s& }$ B3 M W |/ Y8 e! K
不幸的是,当开启拷贝数据库向导的时候,当源和目标版本不同的时候,你就会收到错误信息,不能继续下去。6 X" ?/ s; i2 X' L2 _% U
复制7 o" Z/ h# q3 G) D3 F, p5 G* G
事务复制1 k; N8 T- C3 ~$ o1 z+ v
事务复制是在两个版本之间工作的。这个解决方案有两个问题:
. }' i v6 x$ d% y; I/ r 有一些SQL Server的版本不能作为PRIMARY 或者DISTRIBUTOR参加复制模型,《SQL Server 2005 Features Comparison》一书中对此有详细描述。
! D0 f# t3 L5 G& Z2 p3 O; d. @ 没有定义Unique键的表不能参加这个模型。
1 |5 R8 R1 C8 b 快照复制+ n# X/ W: d/ F. `% t. ?! E( Y
这个解决方案有效,但是也有几项例外。例如,如果表中有用户自定义数据类型,并且必须在表被创建之前创建,那么由于在SQL Server2000没有CREATE TYPE这个命令,就会失败。
2 l) L. z: Y- T0 ]4 k& v, Q6 D! | SQL 追踪
4 B b' ^1 c; {# \: ^4 M 用SQL Server Profiler 或者SQL Trace可以捕捉到工作量,并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。
) @! C1 L! Z# j$ y+ s9 y; P 这个解决方案存在的问题包括:0 ~/ R6 h& S& R9 d1 @; U/ V; X
1、执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了,而这个操作不是这一系列命令中的一个,那么脚本就无法使其发生关系,因为“会话”无法被Traces识别了。
+ L8 L( L: P) s' _ 2、如果在两个版本之间,命令语法有区别,那么在从数据库中的执行一定会失败。2 E' e# q, y5 j! Q
编程
8 O4 O1 S" Q9 y6 H 如果你有一小批数据库要移植,那么你可能会考虑编写一个数据库组件来传输数据的修改。" d4 M1 i" V1 Q( L+ a6 z. ]+ H& j4 Q
示例:
) L+ ?' c5 S% C7 d+ U ・ 使用触发器――这可能会影响性能,因为触发器是事务的一部分。
( J- N2 B+ O6 a% [: T ・ 使用DTS或者BCP来传输数据――这种方法在很大程度上依赖数据量的大小。0 h$ |- k- H) Z/ Q
第三方工具
2 M% U8 y3 R! L, N 你可以使用第三方工具,例如Log Readers来从事务日志、脚本中读取SQL 命令,然后在从数据库中执行它们。还有,虽然我无法自己找到这样的一个工具,但是在SQL Server 2005中肯定会有一个工具能够备份事务日志,并且在SQL Server2000中顺利地重新存储它们。
$ P3 @6 I8 @4 S e0 R1 b8 [ 其它
/ {" J) O, A9 Q- D* X0 T# l; ?5 m 你还可以创新……
( n+ l* q/ K: n 例如,在某些情况下,你可以将日志传送到从SQL Server 2005数据库中,把它的兼容级别改为80,然后备份并重新存储到第三个数据库中去。
- |/ \7 I0 Y0 r# I2 z7 D& f8 k 结论
# F) W4 c C' K; @9 z 对于关键的数据库,保留要升级的数据库的旧的版本,以及最新的数据修改,以便在需要回滚的时候用到,确实是个好主意。# M0 v8 \: K5 F0 q$ r4 N$ f
但是……任何事物都没有“最好的解决方法”。你必须分析你的数据库特点和结构,然后决定针对你的需求的最佳解决方法。就我个人来说,我倾向于认为复制是最快最可靠的解决方法。 |