问题描述
问题原因猜测与验证
首先声明,这儿的Login Failed不是什么SQL Server 服务没起来之类的错误引起。一般的解决办法是不行的,可能的原因笔者猜测是由于计算机名称更改造成,最终在成功解决问题后发现确实如此。在安装SQL Server默认实例时,笔者采用的认证模式是Windows验证,而且用户是本机的一个用户帐户(不是域帐户),所以当机器名称更改后就会导致无法连接,因为之前安装的数据库实例它认为用户是之前的用户,而且没有sa用户。
问题解决
幸好微软提供了一个解决办法PsExec,它允许你以NT AUTHORITY\SYSTEM账号运行程序,和“常规”管理员账号不同——具有天生访问SQLServer的权限。
下载PsExec地址:PsExec - Windows Sysinternals | Microsoft Docs
注:PsExec是PsTools的一个组件
下载完成后以管理员身份打开CMD,并cd到PsTools的解压目录,然后运行如下命令
PsExec -s -i "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe" 其中””中的内容为SSMS(SQL Server Management Studio)的路径
接下来的操作也请参考上面的第一个连接(添加域帐户和sa(如果你想)),在此不再赘述。
注意要先使的验证模式为混合验证模式,否则新建登陆帐号是不起作用的
拓展延伸
不得不说PsExec (PsTools)是一个好工具,以后出现无法登陆或连接的情况,可以用这个工具直接模拟登陆,然后想怎么建立用户或修改权限都可以。
后续
后来又发现机器名称更改后还会造成无法进行发布复制啊,坑爹啊,Google了一下,可以通过以下脚本解决此问题
USE MASTER
GO
SELECT @@SERVERNAME;
SELECT SERVERPROPERTY('SERVERNAME')
--如果这两个结果不一致,说明机器改过名字,在配置复制的时候就会报上面的错误。
--要修复此问题
--执行下面的语句,完成后重新启动SQL服务
IF SERVERPROPERTY('SERVERNAME') <> @@SERVERNAME
BEGIN
DECLARE @SERVER SYSNAME
SET @SERVER = @@SERVERNAME
EXEC SP_DROPSERVER @SERVER = @SERVER
SET @SERVER = CAST(SERVERPROPERTY('SERVERNAME') AS SYSNAME)
EXEC SP_ADDSERVER @SERVER = @SERVER, @LOCAL = 'LOCAL'
END
--最后别忘了重新启动服务哦,启动完后,再运行
记住:一定要重启SSMS等相关服务