SQL Server 2000升级到2005注意屎项& _9 [4 U; h$ q" R: p2 \3 d
" M, |' U% G8 U8 ^/ g: _
" x) `% ?; [: J! z) C, ? _* m( ]) Q/ S3 j* q
3 d4 R5 U- x& @1 F1 O" I$ G/ T8 } j5 ^: P) U/ F0 Y. Q5 n* K4 M0 g
2 Z* K. V1 \) Y# |
# e6 v2 B) B2 v2 n7 i, @2 C. Q) \4 E1 ]7 H# A
如果你计划将数据库从SQL Server 2000 升级到 SQL Server 2005。你在升级之前一定会测试每样东西,并且证明应用程序是稳定的。即使这样,如果升级之后发生任何问题的话,你仍然会想要确保你仍然可以回退到原来的环境中去,并且保证不丢失任何的数据修改。0 g8 m; x" f7 U' m, T F" x
这篇文章列出了保持原有数据(SQL Server 2000)中数据最新,直到新的环境被证明是最棒的方法。& h9 _ v8 ~# F- m O& e% @. ?
保持原有SQL Server环境最新的方法:
3 m9 E1 B" ~* @* G1 j 在SQL Server中,有一些方法可以用来复制数据修改到另外一个数据库中去:0 {# |2 r) j. s" ]
1、日志传送
6 |4 q: S& ? m 2、拷贝数据库任务# a0 \+ ~7 b) \9 g9 R2 G) z; V
3、复制(事务,快照)
6 L8 B, }; L e& R8 Y' f3 e$ [ 4、SQL 追踪6 ?7 y) u" j, }3 r: `' v
5、编程(触发器、DTS,BCP等)& s" [- Z, M- ^1 ~& |
6、第三方工具0 j' |( r1 S4 _& [) p' k; s z
下面我们来讨论其中的三种方法:9 J& v U1 i' I8 m; p$ z$ n+ w
日志传送- H4 l# k+ @1 f. N$ Q8 A$ O$ F
我们可以在SQL Server 2005数据库(主数据库)和SQL Server 2000数据库(从数据库)之间传送日志吗?
( Z6 n: c0 A) B7 i 我努力在因特网上寻找这个问题的积极答案,但是很不走运。然后我试图自己创造性地寻找一种解决方法,使用产品自带的标准工具。也没有门,天啊……我只能在第二个数据库中使用WITH NORECOVERY将日志从SQL Server 2000 传送到SQL Server 2005,没有其他办法。所以,答案是“没有”,使用日志传送是不现实的。
5 n; X6 X; f, h4 Y0 }+ ~) z 拷贝数据库
- M- R- e. a( d# x5 r 不幸的是,当开启拷贝数据库向导的时候,当源和目标版本不同的时候,你就会收到错误信息,不能继续下去。. Q/ P% |. p N6 P, J) T
复制& G K% W+ Q+ \# @+ Y
事务复制# x8 j0 `" {+ }1 C4 B
事务复制是在两个版本之间工作的。这个解决方案有两个问题:
! M/ S* J1 {2 e' G 有一些SQL Server的版本不能作为PRIMARY 或者DISTRIBUTOR参加复制模型,《SQL Server 2005 Features Comparison》一书中对此有详细描述。" l- U+ q5 \) W( a4 A
没有定义Unique键的表不能参加这个模型。
: A, Y5 M- \: I3 ~' ^5 M+ p 快照复制
& V( @- b- J5 O0 s$ R; U 这个解决方案有效,但是也有几项例外。例如,如果表中有用户自定义数据类型,并且必须在表被创建之前创建,那么由于在SQL Server2000没有CREATE TYPE这个命令,就会失败。( a* M% U# A. |
SQL 追踪
- v9 M" q8 E& |- m* G4 S: }4 }/ a 用SQL Server Profiler 或者SQL Trace可以捕捉到工作量,并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。
- B) p7 o+ Q" s) G m7 ]5 T# [4 I 这个解决方案存在的问题包括:
1 W h& u# K$ | B. C2 T 1、执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了,而这个操作不是这一系列命令中的一个,那么脚本就无法使其发生关系,因为“会话”无法被Traces识别了。1 s; w1 p6 K' v6 H. T( N
2、如果在两个版本之间,命令语法有区别,那么在从数据库中的执行一定会失败。4 O# c/ ^7 C( K
编程$ x& `# t% e( ^8 k8 V
如果你有一小批数据库要移植,那么你可能会考虑编写一个数据库组件来传输数据的修改。
8 K4 L- i* `7 h: O' {/ T$ V+ R! { Z 示例:
. T B4 @' M& Q ・ 使用触发器――这可能会影响性能,因为触发器是事务的一部分。
% D; k) c; Q W# q- K$ O6 h: I, B ・ 使用DTS或者BCP来传输数据――这种方法在很大程度上依赖数据量的大小。+ u: Z: N, k7 h( Q6 z1 H
第三方工具
5 _2 S+ r$ q! e! W 你可以使用第三方工具,例如Log Readers来从事务日志、脚本中读取SQL 命令,然后在从数据库中执行它们。还有,虽然我无法自己找到这样的一个工具,但是在SQL Server 2005中肯定会有一个工具能够备份事务日志,并且在SQL Server2000中顺利地重新存储它们。7 ^8 r8 W: V3 Z3 k( D( J( T" e
其它
8 F" J+ o7 g' J8 A 你还可以创新……, h# W( N: s W- ?( p
例如,在某些情况下,你可以将日志传送到从SQL Server 2005数据库中,把它的兼容级别改为80,然后备份并重新存储到第三个数据库中去。
0 P) `0 B/ Q9 o" @3 o! q9 A, d 结论+ ` W! p8 k) ]7 n3 U8 t$ Y
对于关键的数据库,保留要升级的数据库的旧的版本,以及最新的数据修改,以便在需要回滚的时候用到,确实是个好主意。
2 y8 X1 h/ I( _ 但是……任何事物都没有“最好的解决方法”。你必须分析你的数据库特点和结构,然后决定针对你的需求的最佳解决方法。就我个人来说,我倾向于认为复制是最快最可靠的解决方法。 |