我們有一個連接到 Azure 資料庫的應用程式。當它建立連接時，連接字串將如下所示：
Provider=MSOLEDBSQL;Server=<servernamehere>.database.windows.net;Database=<databasehere>;Uid=<whateverthisshouldbe>;Pwd=<whateverthatshouldbe>;MARS Connection=True;Application Name=<ourapplicationhere>;
我們最近也開始使用 MSOLEDBSQL19，所以如果安裝了它，連接字串可能是
Provider=MSOLEDBSQL19;Server=<servernamehere>.database.windows.net;Database=<databasehere>;Uid=<whateverthisshouldbe>;Pwd=<whateverthatshouldbe>;MARS Connection=True;Application Name=<ourapplicationhere>;
幾點考慮：
- 當我從自己的機器上運行相同的應用程式以連接到同一個資料庫時，它每次都能完美運行。
- 我們在幾個不同的 Azure 資料庫上有幾個客戶端。這個客戶端是一個相對較小的客戶端，有 8 個用戶。我們的客戶擁有多達 100 個用戶，他們在連接到各自的 Azure 資料庫時從未遇到此問題。
- 當我們嘗試在此客戶端的 PC 上運行該軟體時，它會連接好幾次，然后，幾秒鐘后，它會失敗，只是在很短的時間后再次連接正常。
這是連接失敗時引發的錯誤：
無效的連接字串 - 沒有連接字串的連接：（見上文）
登錄超時已過期
建立與 SQL Server 的連接時發生與網路相關或特定于實體的錯誤。服務器未找到或無法訪問。檢查實體名稱是否正確以及 SQL Server 是否配置為允許遠程連接。有關詳細資訊，請參閱 SQL Server 聯機叢書。
命名管道提供程式：無法打開到 SQL Server [53] 的連接
因為我們有很多其他客戶端在連接到具有相同配置的Azure 資料庫時從來沒有遇到過這些問題，所以我認為問題不在服務器端，盡管這條訊息說什么以及我在網上找到了什么。
我試過的
- I did a speed check on their internet and found it had a very respectable 100mbps down and nearly as much up. For a site of this size that should be plenty.
- Thinking the issue was DNS related I configured one user's Ethernet connection to use the CloudFlare DNS servers. The problem persisted
- Again in the DNS realm, I put the IP address to our Azure server in the Hosts file. The problem persisted
So I'm stuck. Any suggestions on what we could try next?
One thing that strikes me as odd is the mention of "Named Pipes Provider" in the inner exception. I would have thought it uses TCP/IP but what do I know? Or is there some kind of configuration change required here?
EDIT:
For troubeshooting, I installed SSMS on a user's machine and I tried to connect to tcp:.database.windows.net. Here's what I found:
- Click Connect. If it takes anything over a second, I cancel. Click Connect again.
- This happened like 4 or 5 times.
- Click Connect and wouldn't you know it.... STRAIGHT IN. Now what is going on!?
I also ran powershell -Command "Test-NetConnection -ComputerName '<servernamehere>.database.windows.net' -Port 1433" from a Windows command prompt to test database network connectivity and got a peculiar result. The first time it succeeds:
ComputerName : <servernamehere>.database.windows.net
RemoteAddress : NN.NN.NNN.NNN
RemotePort : 1433
InterfaceAlias : MyInterface
SourceAddress : xxx.xxx.xxx.xxx
TcpTestSucceeded : True
But when I repeat the same command, it fails. What's really strange is that it resolves the SAME ComputerName to DIFFERENT IP addresses on different occasions:
ComputerName : <servernamehere>.database.windows.net
RemoteAddress : MM.MMM.MMM.M
RemotePort : 1433
InterfaceAlias : MyInterface
SourceAddress : xxx.xxx.xxx.xxx
TcpTestSucceeded : False
It sometimes resolves to one IP address, sometimes the other. One IP address ALWAYS fails, the other ALWAYS succeeds.
uj5u.com熱心網友回復：
讓我感到奇怪的一件事是在內部例外中提到了“命名管道提供者”。我原以為它使用 TCP/IP，但我知道什么？還是這里需要某種配置更改？
這是 TCP/IP 連接失敗后的預期結果。如果 TCP 連接失敗，客戶端驅動程式將嘗試命名管道。對命名管道的參考與您的問題無關。
真正奇怪的是它在不同的場合將相同的計算機名決議為不同的 IP 地址
如SQL 資料庫連接體系結構中所述，來自 Azure 外部的客戶連接連接到 Azure SQL 資料庫網關。由于一個網關可能有多個 IP 地址（因地區而異），您可能會為同一個 DNS 名稱獲得不同的 IP 地址。
一個網關 IP 地址連接成功但另一個失敗的癥狀表明您的客戶端已阻止（或未將問題列入白名單）到該 IP/子網的問題 IP/子網或 TCP 埠 1433 流量。要求您的客戶將托管 SQL 資料庫的區域的網關 IP/子網列入白名單。網關 IP 地址和子網列在檔案的網關 IP 地址部分。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/454758.html
標籤：sql-server azure networking dns azure-sql-database
上一篇：檢索最暢銷的產品