SQL Server 2000升级到2005注意屎项; J# v' R" w; \: w
" _. K* K6 `& G/ X
6 z: j7 w" ^& ^, D+ j0 U1 L2 J* {: F2 ?$ T2 \5 Q) F" x8 M! W( L$ V
`( \* k9 }" }
( j, z2 B$ @" h) }$ c
# M' ^/ c7 {, s, V: T
a( e* k$ J6 r$ q, F) p& S( D8 c6 O# v5 p/ @! R8 Z
如果你计划将数据库从SQL Server 2000 升级到 SQL Server 2005。你在升级之前一定会测试每样东西,并且证明应用程序是稳定的。即使这样,如果升级之后发生任何问题的话,你仍然会想要确保你仍然可以回退到原来的环境中去,并且保证不丢失任何的数据修改。
$ N1 I4 _6 B* p5 U' N$ ^" u+ y N 这篇文章列出了保持原有数据(SQL Server 2000)中数据最新,直到新的环境被证明是最棒的方法。" M# \( U7 u0 o7 ^; q6 x% @6 ?
保持原有SQL Server环境最新的方法:. T: L0 e2 g4 c4 n7 L$ v8 K
在SQL Server中,有一些方法可以用来复制数据修改到另外一个数据库中去:
: m7 Y# s; \0 A 1、日志传送. B, L% [( N& i. ~' ^( p9 G# B
2、拷贝数据库任务
# _2 M( o! P, B/ r% O/ g3 I( o7 u 3、复制(事务,快照)
" p" z. j/ H- r M9 S" c- B 4、SQL 追踪" o, P5 J/ j, Y" K
5、编程(触发器、DTS,BCP等)
7 X4 q4 a- z+ \- ~4 P5 ? 6、第三方工具
8 {" d! ^' k5 y& @$ c 下面我们来讨论其中的三种方法:
! q8 S- Q/ ]) D/ z 日志传送
+ M- q2 q$ V' d: a: b 我们可以在SQL Server 2005数据库(主数据库)和SQL Server 2000数据库(从数据库)之间传送日志吗?( ~8 L. N/ H: \) c- W
我努力在因特网上寻找这个问题的积极答案,但是很不走运。然后我试图自己创造性地寻找一种解决方法,使用产品自带的标准工具。也没有门,天啊……我只能在第二个数据库中使用WITH NORECOVERY将日志从SQL Server 2000 传送到SQL Server 2005,没有其他办法。所以,答案是“没有”,使用日志传送是不现实的。
: ]" b8 P6 X! ?/ O 拷贝数据库" r# R. g p% H
不幸的是,当开启拷贝数据库向导的时候,当源和目标版本不同的时候,你就会收到错误信息,不能继续下去。
5 t" \: {) _+ q' i& x 复制
8 m1 O% M, p+ s; O x1 J 事务复制 H4 Z9 e. T0 t2 t2 J2 q
事务复制是在两个版本之间工作的。这个解决方案有两个问题:
7 V7 r$ L0 q7 p 有一些SQL Server的版本不能作为PRIMARY 或者DISTRIBUTOR参加复制模型,《SQL Server 2005 Features Comparison》一书中对此有详细描述。3 b d& I! V c5 P( ]9 w, `
没有定义Unique键的表不能参加这个模型。& F9 c: ]0 `' E* r6 K7 y
快照复制: e! @9 t1 z( z
这个解决方案有效,但是也有几项例外。例如,如果表中有用户自定义数据类型,并且必须在表被创建之前创建,那么由于在SQL Server2000没有CREATE TYPE这个命令,就会失败。
. ? K; O% ~( U$ c$ K SQL 追踪
, `$ c \5 I' S- e 用SQL Server Profiler 或者SQL Trace可以捕捉到工作量,并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。# T0 o( X1 T2 X
这个解决方案存在的问题包括:
0 [9 F/ ]; f* h9 H6 ^ 1、执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了,而这个操作不是这一系列命令中的一个,那么脚本就无法使其发生关系,因为“会话”无法被Traces识别了。5 b# m$ z5 R0 L N
2、如果在两个版本之间,命令语法有区别,那么在从数据库中的执行一定会失败。
% j+ ^& n2 T' v& M 编程# U) c1 g6 V% L Y( U
如果你有一小批数据库要移植,那么你可能会考虑编写一个数据库组件来传输数据的修改。
, i5 @ X) L+ C9 a8 p) X: i 示例:
& w, N% c0 H' e- A. N1 n ・ 使用触发器――这可能会影响性能,因为触发器是事务的一部分。8 k6 ^6 X$ L; y* E
・ 使用DTS或者BCP来传输数据――这种方法在很大程度上依赖数据量的大小。+ W- `1 ?! R) m7 A X- X# w
第三方工具
) I9 A E- A7 R3 o1 z( c 你可以使用第三方工具,例如Log Readers来从事务日志、脚本中读取SQL 命令,然后在从数据库中执行它们。还有,虽然我无法自己找到这样的一个工具,但是在SQL Server 2005中肯定会有一个工具能够备份事务日志,并且在SQL Server2000中顺利地重新存储它们。: P( v$ g& r6 O+ ?4 f# O0 f! l
其它: O) J# A( x* h, s ^" p
你还可以创新……
) I/ m7 s/ c& B6 |( x; J4 O, A 例如,在某些情况下,你可以将日志传送到从SQL Server 2005数据库中,把它的兼容级别改为80,然后备份并重新存储到第三个数据库中去。
* K+ N8 g. {1 z& z Y: l4 G& V 结论
; W) U, E9 ]( l" d# V) E9 Z 对于关键的数据库,保留要升级的数据库的旧的版本,以及最新的数据修改,以便在需要回滚的时候用到,确实是个好主意。
& B8 }3 U& `) t8 \: z* A i8 \ 但是……任何事物都没有“最好的解决方法”。你必须分析你的数据库特点和结构,然后决定针对你的需求的最佳解决方法。就我个人来说,我倾向于认为复制是最快最可靠的解决方法。 |