「オブジェクトエクスプローラー」で「データベース」ノードをクリックすると、ある時点でハングするまで「アイテムのロード」を続けます。
これは、リモートサーバーに接続する場合にのみ発生し、PC上のデータベースにアクセスする場合には発生しません。
また、他のノードでは発生しません。
ウェブホスティング会社の人たちは、それで問題を抱えていませんでした。 (しかし、彼らは2008を実行しているので、SQLサーバーも同様です)
SQLサーバー全体などを再インストールしましたが、役に立ちませんでした。
何が問題なのでしょうか?
この同じ問題が発生しました。オブジェクトエクスプローラーでリモートサーバーにアクセスすると、SSMSが無期限にハングします。 Windowsシステムイベントログには、DCOMエラー10009(「DCOMは、構成されたプロトコルのいずれかを使用してコンピューターMACHINE_NAMEと通信できませんでした。」)が表示されます。
解決策は、プロファイルからMRU履歴とその他の設定をクリアすることでした。それを行うには:
MRUリストがクリアされていることがわかります。その後、資格情報を再入力し、通常どおりSSMSを使用できるようになります。
すべてが機能する場合は、名前を変更したフォルダーを削除できます。そうでない場合は、作成された新しい「11.0」フォルダーを削除し、元のフォルダーの名前を「11.0」に戻します。
この問題を引き起こしているのは実際にMRUリストなのか、それとも他のプロファイルデータなのかはわかりません。
SSMSがポート135を介してSQL Server(おそらくSSIS、T-SQLデバッグなど)にDCOM接続を確立しようとしていることがわかりました。ファイアウォールはポート135をブロックするように構成されました。ファイアウォールでポートを開くことにより、SSMSを使用できました(そのため、リモートデータベースではなくローカルデータベースに対して機能しました)。残念ながら、開いているポート135は多くの攻撃の誘因であるため、私たちにとって実用的な解決策ではありませんでした。
すべてのデータベースで自動クローズをオフにします。私にとって魅力のように働いた!データベースリストを展開または更新するたびに、サーバーはハングの原因となっているデータベースを起動する必要があります。
これを実行して、自動クローズがオンになっているすべてのデータベースを見つけます。
SELECT name, is_auto_close_on
FROM master.sys.databases AS dtb
WHERE is_auto_close_on = 1
ORDER BY name
データベースのこの設定をオフにするには-オブジェクトエクスプローラでデータベースインスタンスを右クリック->プロパティをクリック->データベースプロパティウィンドウの左側のナビゲーションペインで[オプション]をクリック->自動終了プロパティの値を[偽]に変更以下のスナップショットに示されている右ペイン:
ホスティング会社で1つのデータベースのみにアクセスできると仮定すると(少なくとも特定のユーザー名/パスワードではほとんどの場合)、登録済みサーバーをデフォルトに設定することにより、ドロップダウンを使用する必要性をまったく回避できます。アクセスすることになっているデータベース:
(ここでも時間がかかる場合がありますが、これは1回限りです。リストが表示されるのを待つ代わりに入力することもできます。)
この方法では、ホストが作成したログインがデフォルトでtempdbまたは何かにルーティングする場合でも、Management Studioはデータベースのコンテキスト内に配置します。
どうやら間違って解釈した「データベースを使用」ドロップダウンではなく、オブジェクトエクスプローラノードについて話していることがわかりました。試行する演習として、データベースノードを強調表示し(展開しない)、F7(オブジェクトエクスプローラーの詳細)をクリックします。これが読み込まれると、階層をナビゲートする代替手段となり、ボーナスとして、ここで多くのエンティティ属性を表示したり、オブジェクトエクスプローラーで制御できない2つの項目を複数選択したりできます。
それが役に立たない場合、あなたのホストはあなたが彼らが思われるよりもあなたを助けているはずです。 SSMS 2012がサポートされている場合、SSMS 2012でこれをテストし、再現できることを確認または拒否できるはずです。サポートされていない場合は、SSMS 2008もインストールして(共存可能)、この特定のサーバーの管理に使用することをお勧めします。
もちろん、オブジェクトエクスプローラーでできることは何でも(できないこともたくさん)、 catalog views および/または DMVs を使用して行うことができます。 。そのため、何をすべきかを決定する前に、オブジェクトエクスプローラーを使用しているものを正確に確認(または共有)することをお勧めします-オブジェクトエクスプローラーを使用せずにそれを行う方法がある場合、2つのバージョンを使用するよりも回避策を好むかもしれませんツールの(2012 SSMSの改善はオブジェクトエクスプローラーとはまったく関係ないため)。
これをトラブルシューティングするために、Microsoft SQLサポートに1か月以上費やしました。バグとして提出されました。
Win 7(64)にSQL 2012 SSMSとVS 2012の両方がインストールされています。
プロファイルフォルダーを削除しても、妥当な時間は機能しませんでした。
回避策は、接続時にSSMSプロファイルがデフォルトでMasterデータベースに設定されるようにすることでした。 Windows認証で接続していて、SQLアクセス許可が割り当てられている複数のADグループに属し、ADアカウントにSQL固有のアクセス許可が設定されていないという事実と関係があるように見えます。
2000年から2012年にかけていくつかのリモートサーバーに接続しています。ローカルPCのSMSSはSQL Server 2012、SMSSは11.0.2100.60です。
SSMSは1日に数回フリーズします。これが発生すると、RDP経由でローカルサーバー/ SMSS /アクティビティモニターに移動し、PCのSMSSがフリーズ解除されるまで、データベース名= masterのPCからプロセスを1つずつ強制終了します。
これは常に機能しますが、症状よりも病気の治療法は大歓迎です。
私の場合、プロファイルフォルダーの削除は1回だけでした。次回SSMS 2012を開いたときに、サーバーに接続すると再びフリーズしました。 SP1はこれも修正しませんでした。
connect.Microsoft.comでのBen Amadaによるチケット :を常に閉じる SSMS 2012を閉じる前のオブジェクトエクスプローラーの詳細。
だから私にとっての完全な回避策はこれです:
SqlStudio.bin
古いプロファイルフォルダから新しいプロファイルフォルダへ(古いプロファイルフォルダは後で削除できます)最初の2つの手順は1回だけ必要です。または、オブジェクトエクスプローラーの詳細ウィンドウが誤って開いたままになっている場合です。
編集
同じSSMSセッションでSQLサーバーに(再)接続するときに、[オブジェクトエクスプローラーの詳細]ウィンドウを閉じることも必要であることに気付きました。そのため、基本的にサーバーに接続するときは常に、オブジェクトエクスプローラーの詳細ウィンドウを閉じる必要があります。
2000年から2012年までの一部のSQL Serverを使用し、デスクトップからSMSSを介してアクセスします。問題はさまざまな頻度で発生し、次のようになります。オブジェクトエクスプローラーでサーバーを折りたたむと、SMSSがフリーズします。
問題のサーバー上のアクティビティモニターを見ると、次のクエリを実行しているHost = my desktopのプロセスがmaster dbで見つかります
SELECT dtb.name AS [Name] FROM master.dbo.sysdatabases AS dtb ORDER BY [Name] ASC SMSS
プロセスを強制終了すると、SMSSが解放されます。
上記のほぼすべての回答をテストしましたが、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 Updateを介して)適用しましたが、ロードに非常に長い時間がかかりますが、現在は正常に動作しているようです。
デフォルトのデータベースをマスターに戻すことで、この問題を解決しました。
「サーバーへの接続ダイアログボックスの[オブジェクトエクスプローラーへの接続]をクリックしてSSMSを開く]オプションを展開>> [すべてリセット]をクリックします-動作します