3. 为SQL Server 2005升级而复制数据库的最好方法是什么?
我在试着将有着近300个数据库的SQL Server 2000 32位移植到SQL Server 2000 64位。我尝试用“复制数据库”的特性，但是它不能成功的复制任何数据库。我还需要将所有的登录移植过去。欢迎任何建议。
我发现一般情况下复制数据库向导同其他的移动数据方法相比要慢而且低效。它最好用于当你需要在两个服务器之间做少量数据的一个非常快速并有冗余的转移，而且不想花费时间去做备份或分离数据库的情况下。
假如你需要转移300个数据库，我认为你会发现最好的方法是在SQL Server 2000实例上使用sp_detach_db来分离每一个数据库，并在SQL Server 2005实例上用sp_attach_db重新绑定每一个数据库。这么做还能保留你的数据库用户。
然而，即使使用这个方法，你仍然需要获得对SQL Server 2005实例的登录。访问一个KB文章，那里包含了一个可以帮助你做这个工作的脚本，查看这个微软支持页面。
注重，当你完成的时候，你可能需要重新匹配数据库用户和登录。为了重新匹配，使用sp_change_users_login系统存储过程。
—Adam Machanic，SQL Server 2005专家
4. 在升级之后我怎么调整SQL Server查询性能?
我们将我们的SQL Server 2000 10 GB数据库移植到SQL Server 2005。少数查询比在SQL Server 2000中时要慢。先前我们获得结果要10秒钟，而现在要30分钟。这个执行查询计划在SQL Server 2000和SQL Server 2005中是不同的。SQL Server 2000使用索引而SQL 2005使用表的表扫描。还有表的嵌套循环/内连接的序列也改变了。因为这是一个动态应用，所以修订查询是很困难的。你可以提供什么建议关于调整SQL Server 2005中的查询性能吗?
你需要把这个问题当做一个和升级无关的新的问题来检修。需要重新建立索引，需要更新统计。有时在一个SQL Server升级之后(从SQL 7到SQL 2000，或者从SQL 2000到SQL 2005)需要重新建立索引，需要更新统计。我总是推荐使用UPDATE STATISTICS命令替代sp_updatestats，因为UPDATE STATISTICS命令使你可以访问比sp_updatestats存储过程给予的更多的选项。
—Adam Machanic，SQL Server 2005专家
5.故障转移集群在SQL 2005中是怎么工作的?
故障转移集群在SQL 2005中是怎么工作的?它与Oracle和DB2的故障支持相比怎么样?
在SQL Server 2005中故障转移集群功能在很多方面都得到了很大扩展。
首先，运行于Windows 2000 Datacenter 的SQL Server 2000仅限于四个服务器的集群。现在运行在Windows 2003 Server的SQL Server 2005可以支持八个结点(取决于Windows 2003的版本)。
现在故障也被支持于更多种类的服务。分析服务、通知服务、复制和SQL Server代理都是SQL Server 2005中的集群意义上的服务。这对于那些利用这些特性和需要维护高可用性的公司来说是个重要的因素。
但是在数据库可用性方面最大的改进根本不是故障转移集群。一个叫做“数据库镜像”的新的特性将证实是一个更具吸引力的维护正常运行时间的方式。
这个特性可以被认为是日志传送的更实时的方式。事务被连续的从一个活动的结点传送到另一台一直保持恢复状态的服务器上的正在等待中的数据库中。当或假如这个活动结点传送过来，这个镜像几乎可以立即接收。这是对滞后的一个非常巨大的改善——有时几分钟——这可以同故障转移集群一起使用。
关于这个和数据库治理员感爱好的其它特性的更多信息，可以在TechNet文章里看到，提供给数据库治理员的SQL Server 2005 Beta 2概述
—Adam Machanic，SQL Server 2005专家
评论加载中…
 |