2013-08-15 17 views
5

私は興味深い問題があります。私はSQL Server 2012 Developer EditionをSQL Server 2008 R2 Developer Editionの既存のインストールと一緒にインストールしました。元の2008 R2エディションはデフォルトのインスタンスで、新しいインストールは\ DEVという名前のインスタンスです。SQL Serverの名前付きインスタンスへの接続に遅延がありますか?

これまでのところ、とても良いです。リモート接続を有効にするには、新しいインスタンスに対して名前付きパイプとTCP/IPを有効にし、SQL Browserのログインアカウントをローカルシステムに変更する必要がありました。また、ローカルファイアウォールにUDP 1434を明示的にオープンしました。

したがって、新しい接続は新しいインスタンスへの接続を確立するのに20秒以上かかりますが、すぐに古いインスタンス(2008 R2)に接続します。 SQLCMDでは、接続タイムアウトを-l30で無効にする必要があります。 SSMSでは、最初の接続は失敗しますが、その後の再接続はただちに発生します。 RedGate Backup Proなどの他のクライアントとの接続でも同じ問題が発生します。接続のタイムアウトを最低30秒に修正する必要があります。ネットワークパケットサイズを4096から2048に半分にすることも役立ちます。

私はSQLブラウザをチェックしました。ファイルの詳細はバージョンが11.x.x.xです。ネットワークチームとチェックし、外部ファイアウォールなどのTCP/UDPトラフィックに障害がないようにする必要があります(同じサブネット内のクライアントからの接続にも同じ問題があります)。

誰にもアイデアはありますか?それは怒っている。前もって感謝します。

+1

ポート番号、つまりservernameを指定して新しいインスタンスに接続すると、2323はすぐに接続するのですか、それともしばらく時間がかかりますか?これは、クライアントがブラウザサービスからポート番号を見つけて、遅さやインスタンス自体を引き起こしているかどうかを判断するのに役立ちます。 – steoleary

+0

上記の修正、同じIP範囲を共有するサーバーからの接続を確認し、それらの間にアーキテクチャはなく、接続はほぼ一瞬です。ステレオレリーに応答して - 私は、その隣のサーバーからインスタント接続を介してダイナミックポート経由で接続しましたが、どこからでも私は接続できません。これは、ファイアウォールがダイナミックポートへのトラフィックを許可していないためです。 私は今、この問題はファイアウォールが途中にあるときにのみ現れるので、ファイアウォールのUDPポートフィルタリングは何らかの原因で責任があると思われます。 – user2685663

+2

UPDATE:接続は正常に動作しましたが、使用されている動的TCPポートにローカルファイアウォールルールを追加する必要がありました。ありがとう! – user2685663

答えて

0

これは、SQLの名前付きインスタンスを実行すると、実際にSQLディスカバリサービスに接続し、名前付きインスタンス情報(IPアドレスとポート番号)を検索するためです。 SSMSまたは接続文字列にServerName、Port#を指定した場合、インスタンスを検索するステップをスキップしているため、接続はほとんど瞬間的になります。

+0

いいえ、インスタンスをルックアップするのに20秒かかることはありません。 –

関連する問題