SQL Server 2000升级到2005注意屎项
) C; P+ V2 ?) m: U8 i$ n' f
4 B$ L, |( u! r0 M" L8 h# ~$ a: | [* G% ?' S2 ~5 j1 S
3 I$ I6 C- n7 P( d D0 C/ W2 t# p* h1 j/ ?
( s! t% G( `2 Y5 o2 J
0 S# k+ O; ?% d5 D& Y; f1 Z3 c; D0 X) g1 ?
9 S1 d8 u) L. D; r* X* m 如果你计划将数据库从SQL Server 2000 升级到 SQL Server 2005。你在升级之前一定会测试每样东西,并且证明应用程序是稳定的。即使这样,如果升级之后发生任何问题的话,你仍然会想要确保你仍然可以回退到原来的环境中去,并且保证不丢失任何的数据修改。- Q3 N+ q2 P& V& ], b
这篇文章列出了保持原有数据(SQL Server 2000)中数据最新,直到新的环境被证明是最棒的方法。
! |! F( h$ ]% U 保持原有SQL Server环境最新的方法:9 u1 d% [; v: i
在SQL Server中,有一些方法可以用来复制数据修改到另外一个数据库中去:
3 ~7 e3 Y3 ?3 }% I% s. h, l 1、日志传送* d3 @4 r5 N* F* y8 Q
2、拷贝数据库任务, X+ G" Q; X( _% T4 S1 Q
3、复制(事务,快照)5 S8 q* c% _9 f4 t2 w4 ^
4、SQL 追踪
* _0 g/ o- i# x" ^1 z- k 5、编程(触发器、DTS,BCP等)7 Z( K2 z0 {+ g7 S& C S- R
6、第三方工具# s3 i" [8 }% F6 v9 z' H* O
下面我们来讨论其中的三种方法:
2 c$ E& d: B( x) i! Y- \- _- L2 w 日志传送) Y9 B0 l7 j& q; Z
我们可以在SQL Server 2005数据库(主数据库)和SQL Server 2000数据库(从数据库)之间传送日志吗?
+ l9 X7 C+ f# j6 j 我努力在因特网上寻找这个问题的积极答案,但是很不走运。然后我试图自己创造性地寻找一种解决方法,使用产品自带的标准工具。也没有门,天啊……我只能在第二个数据库中使用WITH NORECOVERY将日志从SQL Server 2000 传送到SQL Server 2005,没有其他办法。所以,答案是“没有”,使用日志传送是不现实的。
& W8 ^- t; D2 G8 S' u 拷贝数据库
% u5 Y7 Y2 o/ X% H 不幸的是,当开启拷贝数据库向导的时候,当源和目标版本不同的时候,你就会收到错误信息,不能继续下去。: [& i& C' k/ Z+ q2 }
复制- n% M9 w) c0 U* P5 e
事务复制
) `" U( s; m! s 事务复制是在两个版本之间工作的。这个解决方案有两个问题:, j' i; q# b) i0 ^
有一些SQL Server的版本不能作为PRIMARY 或者DISTRIBUTOR参加复制模型,《SQL Server 2005 Features Comparison》一书中对此有详细描述。
- n( { d% v6 |9 m O7 g7 @' O# z& z 没有定义Unique键的表不能参加这个模型。
- _' i0 ]1 C" M$ ^2 C6 t# ? 快照复制: T* [. \+ E. G/ b( w/ M* U
这个解决方案有效,但是也有几项例外。例如,如果表中有用户自定义数据类型,并且必须在表被创建之前创建,那么由于在SQL Server2000没有CREATE TYPE这个命令,就会失败。
) \( L" F& S' m H) R SQL 追踪
1 L6 \4 q, N! `' {% p 用SQL Server Profiler 或者SQL Trace可以捕捉到工作量,并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。
$ a9 n. ]& L, [$ n9 o 这个解决方案存在的问题包括:
' d5 z$ N9 \7 M" Q 1、执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了,而这个操作不是这一系列命令中的一个,那么脚本就无法使其发生关系,因为“会话”无法被Traces识别了。7 K/ ^0 f+ f, A% ]8 ~ {, {
2、如果在两个版本之间,命令语法有区别,那么在从数据库中的执行一定会失败。
/ |( s: H& y5 q2 | 编程& V0 c$ e+ r8 x# F5 g: ?
如果你有一小批数据库要移植,那么你可能会考虑编写一个数据库组件来传输数据的修改。7 ], C2 n5 b" a
示例:7 p. ]9 k) B' F8 ^, i* ?( t, r
・ 使用触发器――这可能会影响性能,因为触发器是事务的一部分。0 W: ]' v# a& [7 E
・ 使用DTS或者BCP来传输数据――这种方法在很大程度上依赖数据量的大小。
+ R* H0 H4 [4 e# z 第三方工具
6 b# ~' W$ L. Y$ n0 w 你可以使用第三方工具,例如Log Readers来从事务日志、脚本中读取SQL 命令,然后在从数据库中执行它们。还有,虽然我无法自己找到这样的一个工具,但是在SQL Server 2005中肯定会有一个工具能够备份事务日志,并且在SQL Server2000中顺利地重新存储它们。. m6 T% O) V+ y7 }# f) Q
其它" B" I) ~, j' O1 w0 h n% P7 X& d
你还可以创新……
0 \% m3 J1 P' ~( U( F7 a$ W% @ 例如,在某些情况下,你可以将日志传送到从SQL Server 2005数据库中,把它的兼容级别改为80,然后备份并重新存储到第三个数据库中去。& P" b6 S5 W Q9 p' i: t4 z3 i8 m. T
结论1 c, x2 U* a2 ~% @
对于关键的数据库,保留要升级的数据库的旧的版本,以及最新的数据修改,以便在需要回滚的时候用到,确实是个好主意。
2 N% q% B% D1 d+ {. C A 但是……任何事物都没有“最好的解决方法”。你必须分析你的数据库特点和结构,然后决定针对你的需求的最佳解决方法。就我个人来说,我倾向于认为复制是最快最可靠的解决方法。 |