SQL Server实例之间传输登录与密码的描述 |
本文标签:SQL Server实例之间传输登录 如果你在SQL Server实例之间传输登录和密码的实际操作中,你对SQL Server实例之间传输登录和密码有不解之处时,你可以通过以下的文章对其的实际应用与功能有所了解,以下是文章的具体介绍,望你浏览完以下的内容会有所收获 。 概要 在将数据库移动到新服务器后,用户可能无法登录到新服务器 。相反,他们会收到下面的错误消息: Msg 18456, Level 16, State 1 Login failed for user %ls. 您必须将登录和密码传输到新服务器 。本文介绍如何将登录和密码传输到新服务器 。 如何在运行 SQL Server 7.0 的服务器之间传输登录和密码 SQL Server 7.0 数据转换服务 (DTS) 对象传输功能可在两台服务器之间传输登录和用户,但它不传输 SQL Server 验证登录的密码 。要将登录和密码从一台运行 SQL Server 7.0 的服务器传输到另一台运行 SQL Server 7.0 的服务器,请执行“在不同版本的 SQL Server 之间传输登录和密码的完整解决方案”一节中的步骤 。 如何从 SQL Server 7.0 向 SQL Server 2000 或者在运行 SQL Server 2000 的服务器之间传输登录和密码 要从 SQL Server 7.0 服务器向 SQL Server 2000 的一个实例或者在 SQL Server 2000 的两个SQL Server实例之间传输登录和密码,可以使用 SQL Server 2000 中新的 DTS 包传输登录任务 。为此,请按照下列步骤操作:1. 连接到 SQL Server 2000 目标服务器,移动到 SQL Server 企业管理器中的数据转换服务,展开此文件夹,右键单击“本地包”,然后单击“新增包” 。 2. 在 DTS 程序包设计器打开后,单击“任务”菜单上的“传输登录任务” 。根据需要完成有关“源”、“目标”和“登录”选项卡的信息 。
重要说明:SQL Server 2000 目标服务器不能运行 64 位版本的 SQL Server 2000 。64 位版本 SQL Server 2000 的 DTS 组件不可用 。如果要从其他计算机上的 SQL Server 实例中导入登录,您的 SQL Server 实例必须在域帐户下运行才能完成此任务 。
注意:DTS 方法将传输密码,但不会传输原始 SID 。如果登录不是使用原始 SID 创建的,而且用户数据库也被传输到一台新服务器,则该数据库用户将从该登录中孤立出去 。要传输原始 SID 并绕过被孤立的用户,请执行“在不同版本的 SQL Server 之间传输登录和密码的完整解决方案”一节中的步骤 。
在不同版本的 SQL Server 之间传输登录和密码的完整解决方案
此方法适用于以下情况: 从 SQL Server 7.0 向 SQL Server 7.0 传输登录和密码 。 从 SQL Server 7.0 向 SQL Server 2000 传输登录和密码 。 从 SQL Server 7.0 向 SQL Server 2005 传输登录和密码 。 在运行 SQL Server 2000 的服务器之间传输登录和密码 。 从 SQL Server 2000 向 SQL Server 2005 传输登录和密码 。 注意:请查看本文末尾的备注,以了解有关下列步骤的重要信息 。 要在不同版本的 SQL Server 之间传输登录和密码,请按下列步骤操作:1. 在源 SQL Server 上运行以下脚本 。此脚本可在 master 数据库中创建名为 sp_hexadecimal 和 sp_help_revlogin 的两个存储过程 。请在完成过程的创建之后继续执行第 2 步 。 注意:下面的过程取决于 SQL Server 系统表 。这些表的结构在 SQL Server 的不同版本之间可能会有变化,请不要直接从系统表中选择 。
在创建 sp_help_revlogin 存储过程后,请从源服务器上的查询分析器中运行 sp_help_revlogin 过程 。sp_help_revlogin 存储过程可同时用于 SQL Server 7.0 和 SQL Server 2000 。sp_help_revlogin 存储过程的输出是登录脚本,该脚本可创建带有原始 SID 和密码的登录 。 保存输出,然后将其粘贴到目标 SQL Server 上的查询分析器中,并运行它 。例如:EXEC master..sp_help_revlogin 备注 在目标 SQL Server 上运行输出脚本之前,请认真查看此脚本 。如果必须将登录传输到与 SQL Server 源实例不在同一个域中的 SQL Server 实例,请编辑由 sp_help_revlogin 过程生成的脚本,并在 sp_grantlogin 语句中将域名替换为新的域名 。 由于在新域中被授予访问权的集成登录与原始域中的登录具有不同的 SID,因此数据库用户将从这些登录中孤立出去 。要解决这些孤立用户,请查看以下项目符号项中引用的文章 。如果在同一个域中的 SQL Server 实例之间传输集成登录,则会使用相同的 SID,而且用户不太可能被孤立 。 在移动登录之后,用户将不再具有访问已被同时移动的数据库的权限 。此问题称为“孤立用户” 。如果尝试将访问此数据库的权限授予该登录,则可能会失败,这表明该用户已存在:
有关如何将登录映射到数据库用户以解决孤立的 SQL Server 登录和集成登录的说明,请查看相关文章: (http://support.microsoft.com/kb/240872/) 如何解决在运行 SQL Server 的服务器之间移动数据库时的权限问题 。 有关使用 sp_change_users_login 存储过程逐个解决孤立用户(仅能解决从标准 SQL 登录中孤立出去的用户)的说明,请查看相关文章: (http://support.microsoft.com/kb/274188/) PRB:联机丛书中的“孤立用户疑难解答”主题不完整 。 如果传输登录和密码是向运行 SQL Server 的新服务器移动数据库的一部分,请查看相关文章,以了解对所涉及的工作流程和步骤的说明: (http://support.microsoft.com/kb/314546/) 如何在运行 SQL Server 的计算机之间移动数据库 。 能够这样做的原因在于:sp_addlogin 系统存储过程中的 @encryptopt 参数允许通过使用加密密码来创建登录 。有关此过程的更多信息,请参见 SQL Server 联机丛书中的“sp_addlogin (T-SQL)”主题 。 默认情况下,只有 sysadminfixed 服务器角色的成员可以从 sysxlogins 表中进行选择 。除非 sysadmin 角色的成员授予了必要的权限,否则最终用户将无法创建或运行这些存储过程 。 此方法不会尝试传输特定登录的默认数据库信息,因为默认数据库并不始终存在于目标服务器中 。要为某个登录定义默认数据库,您可以使用 sp_defaultdb 系统存储过程,方法是将登录名和默认数据库作为参数传递给该过程 。有关使用此过程的更多信息,请参见 SQL Server 联机丛书中的“sp_defaultdb”主题 。 在 SQL Server 实例之间传输登录的过程中,如果源服务器的排序顺序不区分大小写,而目标服务器的排序顺序区分大小写,则在将登录传输到目标服务器后,必须以大写形式输入密码中的所有字母字符 。 如果源服务器的排序顺序区分大小写,而目标服务器的排序顺序不区分大小写,则无法通过本文所述的步骤使用已传输的登录进行登录,除非原始密码不包括字母字符或原始密码中的所有字母字符都是大写字符 。 如果两个服务器都区分大小写或者都不区分大小写,则不会出现此问题 。这是 SQL Server 处理密码的方式所带来的副作用 。有关更多信息,请参见 SQL Server 7.0 联机丛书中的“Effect>在目标服务器上运行“sp_help_revlogin”脚本的输出时,如果该目标服务器已经定义了一个登录,且该登录名与脚本输出中的某个登录名相同,则在执行“sp_help_revlogin”脚本的输出时,可能会看到下面的错误:
同样,如果此服务器上存在其他登录,且其 SID 值与您要尝试添加的登录的 SID 值相同,则会收到以下错误消息:
因此,您必须仔细复查这些命令的输出,检查 sysxlogins 表的内容,并相应地解决这些错误 。 特定登录的 SID 值用作在 SQL Server 中实现数据库级别访问的基础 。因此,如果同一登录在该数据库级别(在该服务器上的两个不同数据库中)有两个不同的 SID 值,则此登录将仅能访问其 SID 与该登录的 syslogins 中的值相匹配的数据库 。 如果所讨论的两个数据库已从两个不同的服务器合并在一起,则可能出现这种情形 。要解决此问题,必须使用 sp_dropuser 存储过程从具有不匹配 SID 的数据库中手动删除所讨论的登录,然后再使用 sp_adduser 存储过程添加它 。
这篇文章中的信息适用于:
Microsoft SQL Server 7.0 标准版
Microsoft SQL Server 2000 标准版
上述的相关内容就是对在SQL Server实例之间传输登录和密码的描述,希望会给你带来一些帮助在此方面 。 |