Tsql SQL Server 2000传输登录名和关联的服务器角色以及对特定数据库的访问

我在一家规模相对较小的公司工作，员工不到50人，我可能是最接近DBA的人……我实际上是一名程序员，但这与问题无关。我们有一个

SQLServer2000

，大约有100个不同的数据库。几乎所有这些数据库都有一个相关联的SQL登录名，该登录名与特定数据库的

DB\u所有者

数据库角色绑定。我们还有一些登录名被设置为

DB\u DATAREADER

数据库角色

我们购买了一台全新的机器（目前一台使用了12年，担心硬件故障可能会使我们的业务在不可接受的时间内陷入瘫痪）。我们没有升级SQL Server版本。我们将坚持2000年

我的问题是最简单的方法是什么。我的想法是分离所有数据库，将它们复制到新机器上，然后重新连接每个数据库。我将保持机器名和IP的相同，只需删除旧服务器，这样就不需要修改任何连接字符串。这看起来没那么糟糕，可以在周末轻松完成。这种方法的问题是，在执行此操作之后，我需要从数据库中删除用户，然后使用用户名/密码重新创建

登录名

，然后为每个用户分配适当的角色。我在这里才5年，我没有每个特定数据库和程序使用的所有可能的用户名/密码。我不想破坏任何现有的程序，也不想去每一台机器上更新它……或者甚至可能需要找到旧的源代码并重新编译……是的，我们的一些旧东西在源代码中硬编码了用户名/密码：（

所以我想主要的问题是他们的

脚本

，我可以在现有服务器上运行，该服务器将生成一个脚本，在新机器上运行，以设置现有的

登录

，

用户

，

角色

，用户名/密码与以前相同

如果有更简单的方法将SQLServer实例从一台机器转移到另一台机器，我洗耳恭听

---

仅供参考，我们已尝试从现有服务器创建VHD以在虚拟机中使用，但已检查了该路径。我们从未能够将机器引导到windows中。我认为这是驱动程序问题。

我认为您可能能够关闭服务器，然后将所有与数据库相关的文件复制到新服务器并重新启动新服务器qlserver正在使用这些复制的文件。但除了此之外，找不到更多

此链接为您提供关于如何操作的支持意见

---

考虑到VHD路线，您是否也尝试过与之竞争的产品？您可能会尝试一下VMWare，我听说过它的优点，如果其他产品失败，它可能会成功。

除非您在目标计算机上运行64位版本的SQL server，否则第一条评论中提供的链接应允许您成功地传输登录毫无疑问

中标题为“在不同版本的SQL Server之间传输登录名和密码的完整解决方案”的部分为您提供了一个逐步实现目标的过程

尽管这样做肯定非常危险，但您始终可以使用一些工具（如）创建现有服务器驱动器的映像，并在新硬件上恢复该映像

我在从传统驱动器迁移到固态驱动器时做过这样的操作，虽然花了很长时间（几个小时），但效果很好。当然，如果您正在更改操作系统，这种方法将不起作用，并且可能由于硬件和驱动程序的差异而无法正常工作

---

这当然需要做更多的工作，但这些类型的升级让您有机会纠正一些问题，这些问题使您很难将db服务器迁移到新安装（例如：硬编码凭据等）。如果您有能力、时间和愿望来纠正这些问题，那么这样做可能是值得的。

自从我入侵SQL 2000以来，已经有很长很长时间了……但它是可以被入侵的，其方式不适用于2005年及以后。以下是基于“如果我们这样做会发生什么…”的旧记忆提出的想法和建议；我无法给您提供具体的命令或示例，因为我目前无法访问任何SQL 2000实例

• 创建“新”主数据库的备份
• SQL 2000的两个实例位于两个不同的框中。将它们称为“旧”和“新”
• 关闭旧的
• 将主数据库文件（master.mdf、master.log或其名称）复制到新服务器
• 确保您有“新”主数据库的备份
• 将它们作为用户数据库附加到新实例。重命名文件，可能是“OldMaster”
• 在两个主数据库中找到合适的系统数据库。SysLogins？SysLoginX？联机丛书将在这里提供帮助（这些系统表自2000年以来已完全修订）
• 从一个数据库插入…选择…到另一个数据库。我很确定我曾经这样做过。（就在我们放弃SA帐户之前，只是想看看我们是否可以。）（哦，不要放弃SA帐户。）
• 我认为您必须翻转一些sp_选项开关，以允许手动更新系统数据库
• 你确实备份了“新”主数据库，是吗？（实际上，关闭实例、复制主数据库文件并再次启动它们也可以正常工作——只需关闭，将副本复制回混乱的文件，然后再次启动，就可以恢复到原来的状态——只要没有弄乱任何其他数据库。）

sp\u change\u users\u login

（使用“report”然后使用“autofix”）在这里应该是非常宝贵的——它可以用于将登录（主数据库中的定义）与用户（数据库中存储的定义）同步