代码之家  ›  专栏  ›  技术社区  ›  Dave Ward

升级SQL Server 6.5

  •  33
  • Dave Ward  · 技术社区  · 16 年前

    是的,我知道。存在一个正在运行的 SQL Server 6.5 2008年是荒谬的。

    那规定了,什么是最好的迁移方式 6.5 2005 ?有什么直接的途径吗?我发现的大多数文档都是关于升级的 六点五 7 .

    我应该忘记那个本地人吗 SQL Server 升级实用程序,编写所有对象和数据的脚本,并尝试从头重新创建?

    我本周末打算升级,但服务器问题把升级推迟到了下一步。因此,在本周内,任何想法都会受到欢迎。

    更新。我就是这样做的:

    • 备份有问题的数据库并打开master 六点五 .
    • 执行 SQL Server 2000 instcat.sql 反对 六点五 主人。这允许 SQL Server 2000 要连接到的OLEDB提供程序 六点五 .
    • 使用 SQL Server 2000 独立自主 "Import and Export Data" 要创建DTS包,请使用 OLEDB 连接到6.5。这成功地复制了所有 六点五 的新表 二千零五 数据库(也使用 奥莱德 )
    • 使用 六点五 的企业管理器,用于将数据库的所有索引和触发器编写为.sql文件的脚本。
    • 在2005的ManagementStudio中,针对数据库的新副本执行该.sql文件。
    • 使用6.5的Enterprise Manager编写所有存储过程的脚本。
    • 执行那个 .sql 文件反对 二千零五 数据库。几十个存储过程存在使它们与 二千零五 . 主要是 non-ANSI joins quoted identifier issues .
    • 纠正所有这些问题并重新执行 SQL 文件。
    • 重新创建 六点五 在登录 二千零五 并给予他们适当的许可。

    在更正存储过程时有一些清洗/重复(有数百个要更正),但升级在其他方面做得很好。

    能够使用管理工作室而不是 Query Analyzer Enterprise Manager 6.5 是如此惊人的不同。一些报告查询花费了20-30秒 6.5 database 现在运行1-2秒,没有任何修改、新索引或任何内容。我没想到会有这种立即的改善。

    4 回复  |  直到 8 年前
        1
  •  9
  •   Dillie-O    16 年前

    嘿,我也被困在营地里了。我们必须支持的第三方应用程序最终将达到2K5,因此我们几乎是无计可施。但我感觉到你的痛苦8^d

    也就是说,从我从DBA听到的所有信息中,关键是首先将数据库转换为8.0格式,然后转到2005年。我相信他们为此使用了内置的迁移/升级工具。在6.5和8.0之间有一些大的步骤比直接从6.5到2005更好地解决了。

    如果你还不知道的话,你最大的痛苦就是数据传输服务(dts)为了支持ssis而消失了。有一个shell类型的模块将运行现有的dts包,但您需要在ssis中手动重新创建所有这些包。这一点的容易程度将取决于包本身的复杂性,但到目前为止,我在工作中已经做了一些工作,而且这些工作非常顺利。

        2
  •  3
  •   Chris Miller    16 年前

    您可以将6.5升级到SQL Server 2000。您可能更容易掌握SQL Server或2000版的MSDE。Microsoft在上有一页 going from 6.5 to 2000 . 一旦将数据库设置为2000格式,SQL Server 2005就可以轻松地将其升级为2005格式。

    如果没有SQL Server 2000,则可以 download the MSDE 2000 直接来自Microsoft的版本。

        3
  •  2
  •   akash    8 年前

    我决不是权威人士,但我相信唯一支持的途径是从6.5到7。当然,这是最明智的选择,那么我相信你可以毫不痛苦地从7岁直接迁移到2005年。

    至于编写所有对象的脚本,我建议您不要这样做,因为您不可避免地会错过一些东西(除非您的数据库真的很琐碎)。

        4
  •  2
  •   leifg    8 年前

    如果您可以找到专业版或其他超级企业版的Visual Studio 6.0,它附带一份 MSDE (基本上是SQL Express的前身)。我相信微软仍然可以免费下载msde 2000,但我不知道你是否可以直接从6.5迁移到2000。

    我认为在概念上,你不会面临任何危险。但是,多年的实践告诉我,您总是会错过一些对象、权限或其他不会立即显示出来的数据库项。如果您可以编写整个转储的脚本,那就更好了。因为您不太可能错过某些东西——如果确实错过了某些东西,可以很容易地将其添加到脚本中并进行修复。我会避免任何手动步骤(除了按一下回车键一次)如瘟疫。