0

本社に 2 つの SQL Server インスタンスがあり、同じ場所にある Web サーバーに 1 つあります。Web サーバーと本社サーバー間のデータ交換を処理する複製がいくつかあります。

今日、本社でISPを切り替えました。宿題をして、切り替えの準備ができました (hosts ファイルの ips が変更されたなど...) 新しい接続に切り替えるとすぐに、すべてのレプリケーションが完全に壊れました。SSMS を使用して本社のサーバーに接続しようとしました。クッキーなし。Web サーバーのサーバー名を使用して、ホーム オフィス サーバーに ping および ftp を実行できます。ポート 1433 と 1434 が新しい ISP によってブロックされていることを確認し、適切な担当者に通知しました。今すぐブロックを解除する必要があります。SMSS からのダイスはまだありません。

次に、sqlcmd で接続してみましたが、驚くほどうまくいきました。SMSS はサーバーに接続しませんが、sqlcmd は接続します。どうしてこれなの?ISP を切り替える前は、すべてが魔法のように機能していました。

ping ホームサーバー
    成功!
ftp ホームサーバー
    成功!
sqlcmd -S ホームサーバー\インスタンス -U ユーザー -P パス
    成功!
- 同じホームサーバー\インスタンスとユーザー/パスの組み合わせを使用して、SSMSを使用して接続しようとしています
    プロバイダー: SQL ネットワーク インターフェイス、エラー: 26 - 指定されたサーバー/インスタンスの検索中にエラーが発生しました)
4

4 に答える 4

1

SQL は TCP 1434 をリッスンせず、UDP 1434 をリッスンします。telnet を使用して UDP ポートをテストすることはできません。ISP に UDP 1434 を開いてもらいます。

サーバー上のクライアント接続順序を確認すると、名前付きパイプが TCP/IP を上回っていることがわかりますが、SSMS は何らかの理由で名前付きパイプを使用していません。

名前付きインスタンスを使用している場合は、使用しているすべての TCP ポートが SQL Server にあり、コロとオフィスの間で開いていることを確認してください。

オフィスとコロの間のファイアウォールについて心配する必要がないように、オフィスとコロの間に VPN を設定することを検討することをお勧めします。

于 2009-03-23T00:05:00.317 に答える
0

サーバーでSQLブラウザサービスを有効にすることもできます。これにより、サーバーインスタンスの名前を実際に確認できます。

于 2009-03-20T09:42:14.977 に答える
0

インスタンスは次のようになります:homeserver \ instance(スラッシュではなくバックスラッシュ)

于 2009-03-18T22:36:13.830 に答える
0

少し推測できますが、SQLには、共有メモリ、TCP / IP、名前付きパイプ、VIAなど、ネットワークプロトコルに対してさまざまなオプションがあります。SQL Server Configuration Managerを使用して、サーバーとクライアントの両方(適切なマシン上)の構成を設定できます。ネイティブクライアントは名前付きパイプを使用することがよくありますが、名前解決にブロードキャストを使用するため(私が思うに)、WAN経由では機能しないことがよくあります(さらに多くのポートを開く必要がある場合があります)。したがって、SSMSが名前付きパイプを介して接続しようとすると、サーバー名を解決できない場合がありますが、sqlcmdがTCP/IPを使用している場合は解決できます。

つまり、最初に確認するのは、サーバーとクライアントの両方のSQLServer構成マネージャーです。TCP / IP以外のすべてを無効にするか、プロバイダーの順序を変更して、TCP/IPが最上位になるようにしてください。共有メモリを一番上に置いたままにして、必要に応じて有効にすることができます。これは、ローカルマシン接続に便利です。

于 2009-03-18T22:47:53.273 に答える