SQL Server 2000升级到2005注意屎项* l- K: M& r6 I
|, y8 d, |. a, j$ F8 U
+ }, _. P# i" ~7 `7 w' G0 l# i1 Q9 [ l3 u' I
( n" v: ~ k! D5 {7 C$ `; G
; B; K5 R: \: Z$ w3 \- n! x
. _5 s/ O& m3 x2 u: H5 U/ B* ^0 m1 k+ f( |) f2 Z3 y
8 ] X' T; n2 r0 `2 J 如果你计划将数据库从SQL Server 2000 升级到 SQL Server 2005。你在升级之前一定会测试每样东西，并且证明应用程序是稳定的。即使这样，如果升级之后发生任何问题的话，你仍然会想要确保你仍然可以回退到原来的环境中去，并且保证不丢失任何的数据修改。- M" m! r& a5 M0 W% q! u
这篇文章列出了保持原有数据(SQL Server 2000)中数据最新，直到新的环境被证明是最棒的方法。
4 M3 ^# Q2 {- ^3 c( C 保持原有SQL Server环境最新的方法：( L/ S- Y* r% N; e! Z3 [2 t) V/ n
在SQL Server中，有一些方法可以用来复制数据修改到另外一个数据库中去：
5 ?2 s; c) W; f% D: R7 @- S) k 1、日志传送1 g F. \, f! j. O8 c7 s8 m5 s! W
2、拷贝数据库任务
! [; @' A& x) K4 q' T, | 3、复制(事务，快照)6 w; Z. k" }4 Y3 }4 ]! W
4、SQL 追踪. @* E4 t) O) E% L, n. t; s3 _
5、编程(触发器、DTS，BCP等)
8 S" y, u. D O 6、第三方工具. a+ O2 [% a4 e' o( d
下面我们来讨论其中的三种方法：
) y8 O6 T/ \3 i: {# r7 M, T% b/ H, y 日志传送8 ?: ?6 `& H6 n, M- ~% W
我们可以在SQL Server 2005数据库(主数据库)和SQL Server 2000数据库(从数据库)之间传送日志吗?
. ?- M( S' L9 v" a; B$ T L 我努力在因特网上寻找这个问题的积极答案，但是很不走运。然后我试图自己创造性地寻找一种解决方法，使用产品自带的标准工具。也没有门，天啊……我只能在第二个数据库中使用WITH NORECOVERY将日志从SQL Server 2000 传送到SQL Server 2005，没有其他办法。所以，答案是“没有”，使用日志传送是不现实的。+ P3 ? L2 @4 _6 U% r
拷贝数据库
; K9 V4 K4 c* ?0 ` 不幸的是，当开启拷贝数据库向导的时候，当源和目标版本不同的时候，你就会收到错误信息，不能继续下去。
+ N' S7 ^- X7 J3 V5 t! l 复制
/ ^2 D4 L# z w/ u 事务复制
# A/ I. S7 I+ e$ ]# u 事务复制是在两个版本之间工作的。这个解决方案有两个问题：
* m6 T- B0 s" P$ ^7 p 有一些SQL Server的版本不能作为PRIMARY 或者DISTRIBUTOR参加复制模型，《SQL Server 2005 Features Comparison》一书中对此有详细描述。
! ~3 X9 ^* t1 l5 C 没有定义Unique键的表不能参加这个模型。
4 {( ]; g% L% B; O 快照复制) _) ^' c9 h- |" E3 _& l; ?2 |
这个解决方案有效，但是也有几项例外。例如，如果表中有用户自定义数据类型，并且必须在表被创建之前创建，那么由于在SQL Server2000没有CREATE TYPE这个命令，就会失败。4 b! j( u* i/ n! ~1 ]
SQL 追踪& H6 a# y. Y- w- B% M Q5 P2 v
用SQL Server Profiler 或者SQL Trace可以捕捉到工作量，并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。& y. z! y4 t3 v* U0 D7 ~- \
这个解决方案存在的问题包括：
7 _' \5 _" e- P 1、执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了，而这个操作不是这一系列命令中的一个，那么脚本就无法使其发生关系，因为“会话”无法被Traces识别了。6 a# S; m- z1 X# L
2、如果在两个版本之间，命令语法有区别，那么在从数据库中的执行一定会失败。
+ ^, |' ~/ Q2 c. m$ L5 f 编程9 s/ X+ g# _3 z4 X* p
如果你有一小批数据库要移植，那么你可能会考虑编写一个数据库组件来传输数据的修改。
5 {6 G7 ~+ B1 u! `8 ?' ? 示例：
h" n% S% l' L; O" k) H! C3 \+ d ・ 使用触发器――这可能会影响性能，因为触发器是事务的一部分。7 u5 @* l& m% S' }, {- [& [1 s
・ 使用DTS或者BCP来传输数据――这种方法在很大程度上依赖数据量的大小。
" L ~# m/ z+ r/ q 第三方工具" [8 s( A5 }, O7 t" \' `! y1 n4 C2 O
你可以使用第三方工具，例如Log Readers来从事务日志、脚本中读取SQL 命令，然后在从数据库中执行它们。还有，虽然我无法自己找到这样的一个工具，但是在SQL Server 2005中肯定会有一个工具能够备份事务日志，并且在SQL Server2000中顺利地重新存储它们。' k7 }: ~% L) i$ Q) ]
其它! B, Q, C8 f- E5 E' A
你还可以创新……
. y7 i: g: ^- k 例如，在某些情况下，你可以将日志传送到从SQL Server 2005数据库中，把它的兼容级别改为80，然后备份并重新存储到第三个数据库中去。- O+ ?! P/ R7 |
结论1 D/ j) E b* }( \1 }3 c! U
对于关键的数据库，保留要升级的数据库的旧的版本，以及最新的数据修改，以便在需要回滚的时候用到，确实是个好主意。
8 M3 `( s k, `/ l, E! M" |- l 但是……任何事物都没有“最好的解决方法”。你必须分析你的数据库特点和结构，然后决定针对你的需求的最佳解决方法。就我个人来说，我倾向于认为复制是最快最可靠的解决方法。 |
|华强北 电脑城 龙岗电子世界 龙华电脑城 pc4g.com
( 粤ICP备16039863号 )
发表于 2013-1-2 23:35:05