SQL Server Management Studio 2012 挂起 [英] SQL Server Management Studio 2012 hangs

问题描述

当我点击对象资源管理器"中的数据库"节点时，它只会继续加载项目"，直到某个时候它挂起.

When I click on the "Databases" node in "Object Explorer" it just keeps on "Loading items" until at some point it just hangs.

这仅在连接到远程服务器时发生，而不是在访问我 PC 上的数据库时发生.

This happens only when connecting to a remote server, not when accessing a database on my PC.

它也不会发生在任何其他节点上.

It also doesn't happen with any other node.

网络托管公司的工作人员对此没有任何问题.(但他们运行的是 2008 年，那里的 SQL 服务器也是如此)

The guys at the web-hosting company didn't have any trouble with it. (But they're running 2008, and so is the SQL server there)

我重新安装了整个 SQL 服务器等，但无济于事.

I reinstalled the whole SQL server etc. but to no avail.

可能是什么问题?

推荐答案

我遇到了同样的问题:使用对象资源管理器访问远程服务器时，SSMS 会无限期挂起.Windows 系统事件日志将显示 DCOM 错误 10009(DCOM 无法使用任何配置的协议与计算机 MACHINE_NAME 通信.").

I experienced this same problem: when accessing a remote server with the Object Explorer, SSMS would hang indefinitely. The Windows System Event Log would show DCOM error 10009 ("DCOM was unable to communicate with the computer MACHINE_NAME using any of the configured protocols.").

解决方案是从我的个人资料中清除 MRU 历史记录和其他设置.要做到这一点:

1. 关闭所有打开的 SSMS 2012 实例
2. 在资源管理器中，打开%AppData%\Microsoft\SQL Server Management Studio"
3. 将11.0"文件夹重命名为其他名称，例如11.0.old"
4. 打开 SSMS 2012

您会看到您的 MRU 列表已被清除.然后，您应该能够重新输入您的凭据并照常使用 SSMS.

You'll see that your MRU list has been cleared. You should then be able to re-enter your credentials and use SSMS as normal.

如果一切正常，您可以删除重命名的文件夹.否则，删除新创建的11.0"文件夹并将原来的文件夹重命名为11.0".

If everything works, you can delete the renamed folder. Otherwise, delete the new "11.0" folder that was created and rename the original one back to "11.0".

我不知道实际上是 MRU 列表导致了这个问题，还是其他一些配置文件数据.

I have no idea whether it's actually the MRU list that's causing this problem or if it's some other profile data.

我们发现 SSMS 正在尝试通过端口 135 与 SQL Server 建立 DCOM 连接(可能用于 SSIS、T-SQL 调试或其他).我们的防火墙配置为阻止端口 135.通过在防火墙中打开端口，我们能够使用 SSMS(因此它对本地数据库有效，但对远程数据库无效).不幸的是，开放的 135 端口会招致很多攻击，因此这对我们来说不是一个实用的解决方案.

We were able to discover that SSMS is trying to make a DCOM connection over port 135 to the SQL Server (perhaps for SSIS, T-SQL Debugging, or something else). Our firewall was configured to block port 135. By opening the port in the firewall we were able to use SSMS (hence the reason it worked against local databases but not remote ones). Unfortunately, an open port 135 is an invitation for a lot of attacks, so that wasn't a practical solution for us.

这篇关于SQL Server Management Studio 2012 挂起的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！