SQL Server 2000升级到2005注意屎项, M2 U. L4 s7 u2 H! e. A/ v( o
2 o8 a4 P& H* D L0 |* ]" f- y
- X$ d3 {$ t, u+ g( A( N
0 p d. M5 z+ o, h$ E# S6 n' H0 M' l+ L
8 y" z9 G" U$ {! o c+ Z6 p$ h; L1 ^& A/ q; l8 q
& a; J. @5 [9 i+ f* `5 W) N
9 E2 {. S x' e 如果你计划将数据库从SQL Server 2000 升级到 SQL Server 2005。你在升级之前一定会测试每样东西,并且证明应用程序是稳定的。即使这样,如果升级之后发生任何问题的话,你仍然会想要确保你仍然可以回退到原来的环境中去,并且保证不丢失任何的数据修改。1 { x& u0 n1 Z5 ~ E( T _# P
这篇文章列出了保持原有数据(SQL Server 2000)中数据最新,直到新的环境被证明是最棒的方法。
& T8 ]5 ]" t! @% d0 v 保持原有SQL Server环境最新的方法:5 m1 x) h9 u& d" b2 i# E# N. o
在SQL Server中,有一些方法可以用来复制数据修改到另外一个数据库中去:
& e1 N1 l% R( H1 p u0 j 1、日志传送8 o/ j5 K3 R7 n8 v
2、拷贝数据库任务$ u' h8 I1 {% v# w) ~3 M u& A' }" w
3、复制(事务,快照)
* g2 C2 w. Z$ I) R) H0 x 4、SQL 追踪
% I @. n+ z" M' J 5、编程(触发器、DTS,BCP等)
: C3 `# _$ x9 g9 b z- q# f 6、第三方工具
' q% `/ a B/ J9 {2 S$ I( ?( k 下面我们来讨论其中的三种方法:2 B. y: y9 s- y; n
日志传送
1 `# _0 E: h; O* r$ ]+ @5 ^ 我们可以在SQL Server 2005数据库(主数据库)和SQL Server 2000数据库(从数据库)之间传送日志吗?
. ~+ j5 ^ ?: t5 t 我努力在因特网上寻找这个问题的积极答案,但是很不走运。然后我试图自己创造性地寻找一种解决方法,使用产品自带的标准工具。也没有门,天啊……我只能在第二个数据库中使用WITH NORECOVERY将日志从SQL Server 2000 传送到SQL Server 2005,没有其他办法。所以,答案是“没有”,使用日志传送是不现实的。
) q% `% V) l% \* k( d: }! g 拷贝数据库; o$ T) K2 x) s- J) A9 D6 k4 c
不幸的是,当开启拷贝数据库向导的时候,当源和目标版本不同的时候,你就会收到错误信息,不能继续下去。
; m+ I2 U' u0 V% E3 l8 K 复制
& P. k' _ a- {) C( m5 n 事务复制
& S. ^5 n$ x8 c, J5 @7 _ 事务复制是在两个版本之间工作的。这个解决方案有两个问题:6 I( \, s& X$ s9 S, K: S) j, J3 K
有一些SQL Server的版本不能作为PRIMARY 或者DISTRIBUTOR参加复制模型,《SQL Server 2005 Features Comparison》一书中对此有详细描述。
4 w, D* e( j* i w$ U. A 没有定义Unique键的表不能参加这个模型。- m8 s4 x9 T4 {
快照复制
, T& J7 C2 x) c {6 { 这个解决方案有效,但是也有几项例外。例如,如果表中有用户自定义数据类型,并且必须在表被创建之前创建,那么由于在SQL Server2000没有CREATE TYPE这个命令,就会失败。
7 B0 L _# v1 y2 B SQL 追踪
- i9 J7 g: O1 m 用SQL Server Profiler 或者SQL Trace可以捕捉到工作量,并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。
3 J8 u6 P3 _- |4 ` 这个解决方案存在的问题包括:
/ o' r# H/ M- c* T+ M2 L. R4 H 1、执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了,而这个操作不是这一系列命令中的一个,那么脚本就无法使其发生关系,因为“会话”无法被Traces识别了。! g' E5 S+ b" F" Y& [
2、如果在两个版本之间,命令语法有区别,那么在从数据库中的执行一定会失败。
% W H6 |( e4 [ 编程
+ P+ N3 w4 |" q) V$ { 如果你有一小批数据库要移植,那么你可能会考虑编写一个数据库组件来传输数据的修改。
6 m% Z$ Q- `8 O5 w 示例:0 B# D5 S* C# R- V, v2 w8 w
・ 使用触发器――这可能会影响性能,因为触发器是事务的一部分。
: _- W7 B) l8 q! J& V$ \ ・ 使用DTS或者BCP来传输数据――这种方法在很大程度上依赖数据量的大小。
9 [! U- ~; l r* P. l 第三方工具
. y* G2 C3 ~3 h7 F* T, l% \ 你可以使用第三方工具,例如Log Readers来从事务日志、脚本中读取SQL 命令,然后在从数据库中执行它们。还有,虽然我无法自己找到这样的一个工具,但是在SQL Server 2005中肯定会有一个工具能够备份事务日志,并且在SQL Server2000中顺利地重新存储它们。% X- e5 l: V6 m* z6 N S0 I: w
其它3 c$ b! e u& p3 T; R+ f
你还可以创新……
/ ` b3 ~3 x3 I9 t* g+ a7 _ 例如,在某些情况下,你可以将日志传送到从SQL Server 2005数据库中,把它的兼容级别改为80,然后备份并重新存储到第三个数据库中去。9 a7 w2 }! R. T2 W
结论
8 Y1 W* f3 P; P& a- E 对于关键的数据库,保留要升级的数据库的旧的版本,以及最新的数据修改,以便在需要回滚的时候用到,确实是个好主意。4 G P( c R) w6 M9 {9 o4 s* ~
但是……任何事物都没有“最好的解决方法”。你必须分析你的数据库特点和结构,然后决定针对你的需求的最佳解决方法。就我个人来说,我倾向于认为复制是最快最可靠的解决方法。 |