SQL Server 2000升级到2005注意屎项* [6 p8 J6 C1 {5 k& }8 \
$ ^4 x* p3 j( M9 X& B9 v
0 o# J. \0 J6 L1 k, d- f) X0 E
7 b) ~6 R0 \: W8 U' p6 p8 e/ s* N0 \
" l4 n+ n6 g$ {5 u5 L- z: g
" G w" h& q Z# H2 E+ l' @9 e3 v* k' w+ Z
9 ~, f4 L7 X6 E$ N9 P
如果你计划将数据库从SQL Server 2000 升级到 SQL Server 2005。你在升级之前一定会测试每样东西，并且证明应用程序是稳定的。即使这样，如果升级之后发生任何问题的话，你仍然会想要确保你仍然可以回退到原来的环境中去，并且保证不丢失任何的数据修改。
, q( i" ^- v% w; ~; _0 B 这篇文章列出了保持原有数据(SQL Server 2000)中数据最新，直到新的环境被证明是最棒的方法。5 D; C9 h" q1 I/ O6 A
保持原有SQL Server环境最新的方法：
9 _" ^2 t/ u5 e, o 在SQL Server中，有一些方法可以用来复制数据修改到另外一个数据库中去：4 s+ W+ H* T9 @6 B! ^3 l& `: a
1、日志传送
2 _: Z3 L, _2 K, p 2、拷贝数据库任务0 U, M+ G+ \9 O2 p8 `( N/ A
3、复制(事务，快照)
. E9 p4 ~' D: T/ g: \, M1 K 4、SQL 追踪7 |8 |+ I, L8 j* Y1 E3 t; H3 m
5、编程(触发器、DTS，BCP等)
0 T- n' A0 l* g, g, f$ \- [3 c 6、第三方工具
) B# q7 Z# h L6 l7 q. a' o 下面我们来讨论其中的三种方法：- A$ k! K. F9 N* e: v; u
日志传送9 @; q9 A4 X) z) o* w8 b5 a2 S3 z
我们可以在SQL Server 2005数据库(主数据库)和SQL Server 2000数据库(从数据库)之间传送日志吗?4 B2 c' M$ R5 ]$ H" }3 o/ Z4 }, B; B
我努力在因特网上寻找这个问题的积极答案，但是很不走运。然后我试图自己创造性地寻找一种解决方法，使用产品自带的标准工具。也没有门，天啊……我只能在第二个数据库中使用WITH NORECOVERY将日志从SQL Server 2000 传送到SQL Server 2005，没有其他办法。所以，答案是“没有”，使用日志传送是不现实的。
/ Q& E- ?, V. s$ C0 [: m5 W 拷贝数据库9 F1 t' \! d9 x- I& Z6 @
不幸的是，当开启拷贝数据库向导的时候，当源和目标版本不同的时候，你就会收到错误信息，不能继续下去。
& o! M3 e1 Q' w' j# ? 复制3 {5 `+ w( f3 Z. g# N0 x; J
事务复制
' ^8 P, ]" A, z& ^9 h! j1 f- g* G 事务复制是在两个版本之间工作的。这个解决方案有两个问题：' G+ ^; q, Z$ `% l/ T
有一些SQL Server的版本不能作为PRIMARY 或者DISTRIBUTOR参加复制模型，《SQL Server 2005 Features Comparison》一书中对此有详细描述。6 i) \$ x6 O x& ~; E
没有定义Unique键的表不能参加这个模型。+ @3 A7 M6 r0 ]9 l) }
快照复制8 Y1 b; d, p( i- |* |. }
这个解决方案有效，但是也有几项例外。例如，如果表中有用户自定义数据类型，并且必须在表被创建之前创建，那么由于在SQL Server2000没有CREATE TYPE这个命令，就会失败。
9 C, N& f. i x2 l, G4 B SQL 追踪- E4 p% l _0 j3 a; W$ M9 t( }/ ?
用SQL Server Profiler 或者SQL Trace可以捕捉到工作量，并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。
1 l. C4 m( g( D2 A1 s 这个解决方案存在的问题包括：/ n5 L4 L- [1 q1 d
1、执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了，而这个操作不是这一系列命令中的一个，那么脚本就无法使其发生关系，因为“会话”无法被Traces识别了。1 r; |/ e* B2 |' O9 G
2、如果在两个版本之间，命令语法有区别，那么在从数据库中的执行一定会失败。( ^5 L! s, t8 |# ~9 ~/ {- I
编程* }% m3 b3 g% [, X' N
如果你有一小批数据库要移植，那么你可能会考虑编写一个数据库组件来传输数据的修改。
2 ?5 j- h0 o& h4 p' r. g8 x 示例：3 X B3 {/ \5 }7 F K7 l/ g q! R
・ 使用触发器――这可能会影响性能，因为触发器是事务的一部分。
; A9 ~' q# I: B ・ 使用DTS或者BCP来传输数据――这种方法在很大程度上依赖数据量的大小。6 T( F4 x/ {7 b4 B; V3 K
第三方工具4 a8 S5 u4 W& u+ ?
你可以使用第三方工具，例如Log Readers来从事务日志、脚本中读取SQL 命令，然后在从数据库中执行它们。还有，虽然我无法自己找到这样的一个工具，但是在SQL Server 2005中肯定会有一个工具能够备份事务日志，并且在SQL Server2000中顺利地重新存储它们。/ L4 x, h+ Q2 V/ A7 R: @. [
其它
, g# H9 z3 M/ h4 R {9 a1 i 你还可以创新……
+ \3 h0 u, r# L3 Q 例如，在某些情况下，你可以将日志传送到从SQL Server 2005数据库中，把它的兼容级别改为80，然后备份并重新存储到第三个数据库中去。3 [) _, R7 Z# j9 c5 A2 V: z8 J
结论
* F L; ]( x" C0 @ i, F- { 对于关键的数据库，保留要升级的数据库的旧的版本，以及最新的数据修改，以便在需要回滚的时候用到，确实是个好主意。+ i% j2 P; N. n! H" r
但是……任何事物都没有“最好的解决方法”。你必须分析你的数据库特点和结构，然后决定针对你的需求的最佳解决方法。就我个人来说，我倾向于认为复制是最快最可靠的解决方法。 |
|华强北 电脑城 龙岗电子世界 龙华电脑城 pc4g.com
( 粤ICP备16039863号 )
发表于 2013-1-2 23:35:05