Đã xảy ra lỗi cấp độ vận chuyển khi nhận kết quả từ máy chủ [đã đóng]

Tôi đang gặp lỗi SQL Server:

Đã xảy ra lỗi cấp độ vận chuyển khi nhận kết quả từ máy chủ. (nhà cung cấp: Nhà cung cấp bộ nhớ dùng chung, lỗi: 0 - Tay cầm không hợp lệ.)

Tôi đang chạy Sql Server 2008 SP1, Windows 2008 Standard 64 bit.

Đây là một ứng dụng web .Net 4.0. Nó xảy ra khi một yêu cầu được thực hiện cho máy chủ. Nó không liên tục. Bất cứ ý tưởng làm thế nào tôi có thể giải quyết nó?

Kết nối cơ sở dữ liệu được đóng bởi máy chủ cơ sở dữ liệu. Kết nối vẫn hợp lệ trong nhóm kết nối của ứng dụng của bạn; kết quả là, khi bạn chọn chuỗi kết nối được chia sẻ và cố gắng thực thi thì nó không thể truy cập cơ sở dữ liệu. Nếu bạn đang phát triển Visual Studio, chỉ cần đóng máy chủ web tạm thời trên thanh tác vụ của bạn.

Nếu nó xảy ra trong sản xuất, việc đặt lại nhóm ứng dụng cho trang web của bạn sẽ tái chế nhóm kết nối.

Hãy thử lệnh sau trên dấu nhắc lệnh:

netsh interface tcp set global autotuning=disabled

Điều này sẽ tắt khả năng mở rộng tự động của ngăn xếp mạng

Tôi đã từng gặp vấn đề tương tự. Tôi đã khởi động lại Visual Studio và điều đó đã khắc phục vấn đề

Đối với những người không sử dụng IIS, tôi gặp vấn đề này khi gỡ lỗi với Visual Studio 2010. Tôi đã kết thúc tất cả các quy trình gỡ lỗi: WebDev.WebServer40.EXE đã giải quyết vấn đề.

Lỗi cấp độ vận chuyển thường được liên kết với kết nối đến máy chủ sql bị hỏng ... thường là mạng.

Hết thời gian hết hạn thường được ném khi truy vấn sql mất quá nhiều thời gian để chạy.

Vì vậy, một vài lựa chọn có thể là:

1. Kiểm tra kết nối trong VPN (nếu được sử dụng) hoặc bất kỳ công cụ nào khác
2. Khởi động lại IIS
3. Khởi động lại máy
4. Tối ưu hóa các truy vấn sql.

Tất cả những gì bạn cần là Dừng Máy chủ Phát triển ASP.NET và chạy lại dự án

Nếu bạn được kết nối với cơ sở dữ liệu của mình thông qua Microsoft SQL Server Management, hãy đóng tất cả các kết nối và thử lại. Có lỗi này khi được kết nối với Cơ sở dữ liệu Azure khác và đã hoạt động với tôi khi đóng nó. Vẫn không biết tại sao ..

Đã nhận được điều này, luôn luôn sau khoảng 5 phút hoạt động. Đã điều tra và nhận thấy rằng một cảnh báo từ e1.co luôn xảy ra trước khi thất bại. Đây rõ ràng là một lỗi phải làm với một số bộ điều hợp TCP / IP nhất định. Nhưng việc thay đổi từ WiFi sang hardwired không ảnh hưởng đến nó.

Vì vậy, đã thử Kế hoạch B và khởi động lại Visual Studio. Sau đó, nó hoạt động tốt.

Khi nghiên cứu kỹ hơn tôi nhận thấy rằng, khi làm việc chính xác, thông điệp The Thread '<No Name>' has exited with code 0 xảy ra gần như chính xác thời gian chạy bị hỏng trong các lần thử trước. Một số Googling tiết lộ rằng thông báo đó xuất hiện khi (trong số những thứ khác) máy chủ đang cắt xén nhóm luồng.

Có lẽ có một luồng không có thật trong nhóm luồng và mỗi lần máy chủ cố gắng "cắt" nó, nó sẽ gỡ ứng dụng xuống.

Nhìn vào blog MSDN để biết chi tiết về lỗi này:

Xóa kết nối

Pooler kết nối sẽ xóa kết nối khỏi pool sau khi nó không hoạt động trong một thời gian dài hoặc nếu pooler phát hiện ra rằng kết nối với máy chủ đã bị cắt đứt.

Lưu ý rằng một kết nối bị đứt chỉ có thể được phát hiện sau khi cố gắng giao tiếp với máy chủ. Nếu một kết nối được tìm thấy không còn kết nối với máy chủ, nó được đánh dấu là không hợp lệ.

Các kết nối không hợp lệ chỉ bị xóa khỏi nhóm kết nối khi chúng bị đóng hoặc được thu hồi.

Nếu một kết nối tồn tại đến một máy chủ đã biến mất, kết nối này có thể được rút ra từ nhóm ngay cả khi nhóm kết nối không phát hiện ra kết nối bị cắt đứt và đánh dấu nó là không hợp lệ.

Đây là trường hợp bởi vì chi phí kiểm tra kết nối vẫn còn hiệu lực sẽ loại bỏ các lợi ích của việc có một pooler bằng cách gây ra một chuyến đi khứ hồi khác đến máy chủ.

Khi điều này xảy ra, lần thử đầu tiên sử dụng kết nối sẽ phát hiện ra rằng kết nối đã bị cắt đứt và một ngoại lệ được đưa ra.

Về cơ bản những gì bạn đang thấy là ngoại lệ trong câu cuối cùng.

Một kết nối được lấy từ nhóm kết nối, ứng dụng không biết rằng kết nối vật lý đã biến mất, một nỗ lực sử dụng được thực hiện theo giả định rằng kết nối vật lý vẫn còn đó.

Và bạn có được ngoại lệ của bạn.

Có một vài lý do phổ biến cho việc này.

1. Máy chủ đã được khởi động lại, điều này sẽ đóng các kết nối hiện có.

Trong trường hợp này, hãy xem nhật ký Máy chủ SQL, thường được tìm thấy tại: C: \ Chương trình tệp \ Microsoft SQL Server \\ MSSQL \ LOG

Nếu dấu thời gian để khởi động là rất gần đây, thì chúng ta có thể nghi ngờ rằng đây là nguyên nhân gây ra lỗi. Cố gắng tương quan dấu thời gian này với thời gian ngoại lệ.

2009-04-16 11: 32: 15.62 Máy chủ ghi nhật ký Thông điệp máy chủ SQL trong tệp 'C: \ Chương trình tệp \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ LOG \ ERRORLOG'.

2. Ai đó hoặc một cái gì đó đã giết SPID đang được sử dụng.

Một lần nữa, hãy xem nhật ký SQL Server. Nếu bạn tìm thấy một kill, hãy thử tương quan dấu thời gian này với thời gian ngoại lệ.

2009-04-16 11: 34: 09.57 spidXX Quá trình ID XX đã bị giết bởi tên máy chủ xxxxx, ID tiến trình máy chủ XXXX.

3. Có một chuyển đổi dự phòng (ví dụ như trong thiết lập nhân bản), hãy xem nhật ký SQL Server.

Nếu có chuyển đổi dự phòng, hãy thử tương quan dấu thời gian này với thời gian ngoại lệ.

2009-04-16 11: 35: 12.93 spidXX Cơ sở dữ liệu được nhân đôi trong cơ sở dữ liệu đang thay đổi vai trò từ VÒNG PRINCIPAL và thành MIR MIRROR do lỗi chuyển đổi.

Bạn nhận được thông báo này khi tập lệnh của bạn khiến SQL Service bị dừng vì một số lý do. vì vậy nếu bạn khởi động lại dịch vụ SQL, có lẽ vấn đề của bạn sẽ được giải quyết.

Tôi biết điều này có thể không giúp được tất cả mọi người (những người biết, có thể có), nhưng tôi đã gặp vấn đề tương tự và sau một thời gian, chúng tôi nhận ra rằng nguyên nhân là do chính mã.

Máy tính cố gắng truy cập máy chủ, ở một mạng khác, kết nối có thể được thiết lập nhưng sau đó bị hủy.

Cách chúng tôi sử dụng để sửa nó là thêm một tuyến tĩnh vào máy tính, cho phép truy cập trực tiếp vào máy chủ mà không cần vượt qua tường lửa.

route add –p YourServerNetwork mask NetworkMask Router 

Mẫu vật:

route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2 

Tôi hy vọng nó sẽ giúp được ai đó, tốt hơn là nên có cái này, ít nhất là một đầu mối, vì vậy nếu bạn đối mặt với nó, bạn sẽ biết cách giải quyết nó.

Tôi đã gặp lỗi tương tự trong môi trường phát triển Visual Studion 2012, dừng IIS Express và chạy lại ứng dụng, nó bắt đầu hoạt động.

Trong trường hợp của tôi, dịch vụ Máy chủ "SQL Server" đã dừng. Khi tôi khởi động lại dịch vụ cho phép tôi chạy truy vấn và loại bỏ lỗi.

Đây cũng là một ý tưởng tốt để kiểm tra truy vấn của bạn để tìm hiểu lý do tại sao truy vấn khiến dịch vụ này dừng lại

Tôi gặp vấn đề tương tự. Tôi đã giải quyết nó, cắt bớt SQL Server LOG. Kiểm tra làm điều đó, và sau đó cho chúng tôi biết, nếu giải pháp này đã giúp bạn.

Đối với tôi, câu trả lời là nâng cấp HĐH từ 2008R2 lên 2012R2, giải pháp iisreset hoặc khởi động lại apppool không hiệu quả với tôi. Tôi cũng đã thử bật cài đặt TCP Chimney Offload, nhưng tôi đã không khởi động lại máy chủ vì đây là máy chủ sản xuất, cũng không hoạt động.

Đối với tôi giải pháp là hoàn toàn khác nhau.

Trong trường hợp của tôi, tôi đã có một nguồn đối tượng yêu cầu tham số datetimestamp. Mặc dù tham số ODS ConvertEmptyStringToNull là đúng 1/1/0001 đã được chuyển cho SelectMethod. Chính điều đó đã gây ra ngoại lệ tràn dữ liệu sql khi thời gian đó được chuyển đến máy chủ sql.

Đã thêm một kiểm tra bổ sung cho datetime.year! = 0001 và điều đó đã giải quyết nó cho tôi.

Điều kỳ lạ là nó sẽ gây ra lỗi cấp độ vận chuyển chứ không phải lỗi tràn thời gian. Dù sao ..

Gần đây chúng tôi đã gặp lỗi này giữa máy chủ doanh nghiệp và máy chủ cơ sở dữ liệu của chúng tôi. Giải pháp cho chúng tôi là vô hiệu hóa "IP Offloading" trên các giao diện mạng. Sau đó, lỗi đã biến mất.

Một trong những lý do tôi tìm thấy cho lỗi này là ' Kích thước gói = xxxxx ' trong chuỗi kết nối. nếu giá trị của xxxx quá lớn, chúng ta sẽ thấy lỗi này. Xóa giá trị này và để máy chủ SQL xử lý hoặc giữ ở mức thấp, tùy thuộc vào khả năng của mạng.

Nó xảy ra với tôi khi tôi đang cố gắng khôi phục cơ sở dữ liệu SQL và kiểm tra sau Hộp kiểm trong Optionstab,

Vì nó là một máy chủ cơ sở dữ liệu độc lập chỉ cần đóng SSMS và mở lại nó đã giải quyết vấn đề cho tôi.

Điều này xảy ra khi cơ sở dữ liệu bị hủy và tạo lại một số tài nguyên được chia sẻ vẫn đang xem xét cơ sở dữ liệu vẫn tồn tại, vì vậy khi bạn chạy lại truy vấn thực hiện để tạo bảng trong cơ sở dữ liệu sau khi được tạo lại, lỗi sẽ không hiển thị lại và Command(s) completed successfully.thông báo sẽ hiển thị thay vì thông báo lỗi Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.).

Đơn giản chỉ cần bỏ qua lỗi này khi bạn bỏ và tạo lại cơ sở dữ liệu và thực hiện lại các truy vấn DDL của bạn mà không phải lo lắng.

Tôi đã đối mặt với cùng một vấn đề gần đây, nhưng tôi không thể nhận được câu trả lời trong google. Vì vậy, hãy nghĩ đến việc chia sẻ nó ở đây, để nó có thể giúp đỡ ai đó trong tương lai.

Lỗi:

Trong khi thực hiện truy vấn, truy vấn sẽ cung cấp một vài đầu ra, sau đó nó sẽ đưa ra lỗi bên dưới.

"Lỗi cấp độ vận chuyển đã xảy ra khi nhận đầu ra từ máy chủ (TCP: nhà cung cấp, lỗi: 0- tên mạng được chỉ định không còn khả dụng"

Giải pháp:

1. Kiểm tra nhà cung cấp của máy chủ được liên kết đó
2. Trong thuộc tính nhà cung cấp đó, bật tùy chọn "Cho phép trong quá trình" cho nhà cung cấp cụ thể đó để khắc phục sự cố.