当我单击“对象资源管理器”中的“数据库”节点时,它只会继续“加载项目”,直到某个时候它只是挂起。
这仅在连接到远程服务器时发生,而不是在访问我的 PC 上的数据库时发生。
任何其他节点也不会发生这种情况。
网络托管公司的人对此没有任何问题。(但他们运行的是 2008 年,那里的 SQL 服务器也是如此)
我重新安装了整个 SQL 服务器等,但无济于事。
可能是什么问题?
当我单击“对象资源管理器”中的“数据库”节点时,它只会继续“加载项目”,直到某个时候它只是挂起。
这仅在连接到远程服务器时发生,而不是在访问我的 PC 上的数据库时发生。
任何其他节点也不会发生这种情况。
网络托管公司的人对此没有任何问题。(但他们运行的是 2008 年,那里的 SQL 服务器也是如此)
我重新安装了整个 SQL 服务器等,但无济于事。
可能是什么问题?
我遇到了同样的问题:使用对象资源管理器访问远程服务器时,SSMS 会无限期挂起。Windows 系统事件日志将显示 DCOM 错误 10009(“DCOM 无法使用任何配置的协议与计算机 MACHINE_NAME 进行通信。”)。
解决方案是从我的个人资料中清除 MRU 历史记录和其他设置。要做到这一点:
您会看到您的 MRU 列表已被清除。然后,您应该能够重新输入您的凭据并正常使用 SSMS。
如果一切正常,您可以删除重命名的文件夹。否则,删除新创建的“11.0”文件夹并将原来的文件夹重命名为“11.0”。
我不知道是否实际上是导致此问题的 MRU 列表,或者是否是其他一些配置文件数据。
我们能够发现 SSMS 正在尝试通过端口 135 与 SQL Server 建立 DCOM 连接(可能用于 SSIS、T-SQL 调试或其他)。我们的防火墙被配置为阻止端口 135。通过在防火墙中打开端口,我们能够使用 SSMS(因此它对本地数据库有效,但对远程数据库无效)。不幸的是,开放的 135 端口会招致很多攻击,所以这对我们来说不是一个实用的解决方案。
在所有数据库上关闭自动关闭。对我来说就像一个魅力!每次展开或刷新数据库列表时,服务器都必须唤醒导致挂起的数据库。
只需运行它即可找到所有已自动关闭的数据库
SELECT name, is_auto_close_on
FROM master.sys.databases AS dtb
WHERE is_auto_close_on = 1
ORDER BY name
要为数据库关闭此设置 - 在对象资源管理器中右键单击数据库实例 -> 单击属性 -> 在数据库属性窗口的左侧导航窗格中单击“选项” -> 将“自动关闭”属性的值更改为“False”右窗格,如下面的快照所示:
假设您只能访问托管公司的一个数据库(几乎总是如此,至少使用特定的用户名/密码),您可以通过将注册服务器设置为默认值来避免使用下拉菜单您应该访问的数据库:
(这里也可能需要更长的时间,但这将是一次性的。您也可以键入它而不是等待列表填充。)
这样,即使主机为您创建的登录默认将您路由到 tempdb 或其他东西,Management Studio 仍会将您置于数据库的上下文中。
我现在看到您在谈论对象资源管理器节点,而不是我以某种方式错误解释的“使用数据库”下拉菜单。尝试的一个练习可能是突出显示数据库节点(不要展开它)并单击 F7(对象资源管理器详细信息)。如果这为您加载,那么它可以作为在层次结构中导航的替代方法,并且作为奖励,您可以在此处显示许多实体属性以及多选,这两件事您在对象资源管理器中无法控制。
如果这没有帮助,那么你的主人应该比他们看起来更好地帮助你。如果支持 SSMS 2012,那么他们应该能够在 SSMS 2012 中对此进行测试,并确认或否认他们可以重现它。如果不支持,那么我认为您的办法是安装 SSMS 2008(它们可以共存)并将其用于管理此特定服务器。
当然,您可以在对象资源管理器中做的任何事情(以及很多您不能做的事情),都可以通过使用目录视图和/或DMV来完成。因此,在您确定要做什么之前,您可能想要查看(或与我们分享)您使用对象资源管理器的确切用途 - 如果有一种方法可以在没有对象资源管理器的情况下执行此操作,那么您可能比拥有两个版本更喜欢这种解决方法工具(因为 2012 SSMS 的改进与对象资源管理器完全无关)。
我花了一个多月的时间与 Microsoft SQL Support 一起解决此问题。它已作为错误提交。
我在 Win 7 (64) 上安装了 SQL 2012 SSMS 和 VS 2012。
删除配置文件文件夹从未在任何合理的时间内起作用。
我们找到的解决方法是确保我的 SSMS 配置文件在连接时默认为主数据库。这似乎与我正在使用 Windows 身份验证连接并且我属于多个分配了 SQL 权限并且我没有在我的 AD 帐户上设置 SQL 特定权限的 AD 组这一事实有关。
在我的情况下,删除配置文件文件夹只工作一次。下次我打开 SSMS 2012 时,它会在连接到服务器时再次冻结。SP1 也没有解决这个问题。
直到我在 connect.microsoft.com 上找到 Ben Amada 在票证上描述的以下简单解决方法:始终在关闭 SSMS 2012 之前关闭对象资源管理器详细信息。
所以对我来说完整的解决方法是:
SqlStudio.bin
从旧的个人资料文件夹复制到新的(旧的个人资料文件夹之后可以删除)前两个步骤只需要一次,或者如果“对象资源管理器详细信息”窗口意外打开。
编辑
我刚刚注意到,在同一个 SSMS 会话中(重新)连接到 SQL 服务器时,也需要关闭对象资源管理器详细信息窗口。所以基本上每当连接到服务器时,对象资源管理器详细信息窗口都必须关闭。
从 2000 年到 2012 年有一些 SQL Server,然后从我的桌面通过 SMSS 访问。问题以不同的频率发生,如下所示:当我在对象资源管理器中折叠服务器时,SMSS 冻结。
查看相关服务器上的活动监视器,我在主数据库中找到一个进程,主机 = 我的桌面执行以下查询
SELECT dtb.name AS [Name] FROM master.dbo.sysdatabases AS dtb ORDER BY [Name] ASC SMSS
杀死进程释放 SMSS。
我从 2000 年到 2012 年连接到多个远程服务器。本地 PC 上的 SMSS 是 SQL Server 2012,SMSS 是 11.0.2100.60
SSMS 每天冻结数次。发生这种情况时,我通过 RDP 转到本地服务器 / SMSS / Activity Monitor 并从我的 PC 中终止进程,数据库名称 = master,一次一个,直到我的 PC 上的 SMSS 解冻。
这总是有效的,然而,治愈这种疾病而不是症状会受到高度欢迎。
这对我有用 打开 SSMS 单击连接到服务器对话框中的连接到对象资源管理器按钮 展开选项>>单击全部重置 完成!
我已经测试了以上所有答案,但我的 SSMS 卡在扩展数据库列表中。我终于找到了问题。问题是因为我恢复了一个数据库,但它最后确实恢复了。然后,当我扩展数据库列表时,它就卡住了。
我运行查询
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM master.sys.databases AS dtb
然后结果花了太长时间,最后超时但是当我过滤卡住的数据库时,我得到了结果。
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM
master.sys.databases AS dtb
Where name <> 'StuckDB' ORDER BY [Name] ASC
最后我决定分离 StuckDB 来解决我的问题。
“打开 SSMS 单击连接到服务器对话框中的连接到对象资源管理器按钮展开选项>>单击全部重置” - 它有效
我现在已经应用了 SQL 2012 Service Pack 1(通过 Windows 更新),它现在似乎工作正常,尽管它确实需要很长时间才能加载。
我通过将默认数据库更改回主数据库解决了这个问题。