Thời gian hết hạn. Khoảng thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi. Các tuyên bố này đã bị chấm dứt


296

Tôi có nhiều người dùng trên trang web của mình (20000-60000 mỗi ngày), đây là trang tải xuống cho các tệp di động. Tôi có quyền truy cập từ xa vào máy chủ của mình (máy chủ windows 2008-R2).
Trước đây tôi đã nhận được lỗi "Máy chủ không khả dụng" nhưng hiện đang thấy lỗi hết thời gian kết nối.
Tôi không quen với điều này - tại sao nó xảy ra và làm cách nào để khắc phục nó?

Lỗi đầy đủ là dưới đây:

lỗi server trong ứng dụng '/' Thời gian hết hạn. Khoảng thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi. Các tuyên bố này đã bị chấm dứt. Mô tả: Một ngoại lệ chưa được xử lý đã xảy ra trong quá trình thực hiện yêu cầu web hiện tại. Vui lòng xem lại dấu vết ngăn xếp để biết thêm thông tin về lỗi và nguồn gốc của mã.

Chi tiết ngoại lệ: System.Data.SqlClient.SqlException: Hết hạn. Khoảng thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi. Các tuyên bố này đã bị chấm dứt.

Lỗi nguồn:

Một ngoại lệ chưa được xử lý đã được tạo trong quá trình thực hiện yêu cầu web hiện tại. Thông tin liên quan đến nguồn gốc và vị trí của ngoại lệ có thể được xác định bằng cách sử dụng dấu vết ngăn xếp ngoại lệ bên dưới.

Dấu vết ngăn xếp:

[SqlException (0x80131904): Hết thời gian hết hạn. Khoảng thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi. Báo cáo kết quả đã bị chấm dứt.]
System.Data.SqlClient.SqlConnection.OnError (SqlException ngoại lệ, Boolean breakConnection) 404
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning () 412
System.Data.SqlClient.TdsParser.Run (RunBehavior runBehavior , SqlCommand cmdHandler, SqlDataReader datastream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) 1363
System.Data.SqlClient.SqlCommand.FinishExecuteReader (ds SqlDataReader, runBehavior runBehavior, string resetOptionsString) 6.387.741
System.Data.SqlClient.SqlCommand.RunExecuteReaderTds (CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) 6.389.442
System.Data.SqlClient.SqlCommand.RunExecuteReader (CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String phương pháp, kết quả DbAsyncResult) + 538
System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery (kết quả DbAsyncResult, string methodName, Boolean sendToPipe) 689
System.Data.SqlClient.SqlCommand.ExecuteNonQuery () 327
NovinMedia.Data.DbObject.RunProcedure (string storedProcName, IDataParameter [] thông số , Int32 & rowsAffected) +209
DataLayer.OnlineUsers.Update_SessionEnd_And_Online (Object session_End, Boolean Online) +440
NiceFileExplorer.Global.Application_Start (Người gửi đối tượng, EventArss e) +163

[HttpException (0x80004005): Hết thời gian hết hạn. Khoảng thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi. Tuyên bố đã bị chấm dứt.]
System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode (bối cảnh httpContext, ứng dụng httpApplication
) +4052053
System.Web.HttpApplication.ege Ban đầu Đặc biệt (trạng thái httpApplicationState, trình xử lý Phương thức [], trình xử lý IntPtr, ứng dụng IntPtr, liên kết ngữ cảnh) +352
System.Web.HttpApplicationFactory.GetecialApplicationInstance (IntPtr appContext,
liên kết của hệ thống).

[HttpException (0x80004005): Hết thời gian hết hạn. Khoảng thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi. Báo cáo kết quả đã bị chấm dứt.]
System.Web.HttpRuntime.FirstRequestInit (HttpContext ngữ cảnh) 11.686.928 System.Web.HttpRuntime.EnsureFirstRequestInit (HttpContext ngữ cảnh) 141 System.Web.HttpRuntime.ProcessRequestNotificationPrivate (IIS7WorkerRequest wr, HttpContext ngữ cảnh) 4.863.749


CHỈNH SỬA SAU TRẢ LỜI: trong
của tôi giống như dưới đây: Application_StartGlobal.asax

protected void Application_Start(object sender, EventArgs e)
{
    Application["OnlineUsers"] = 0;

    OnlineUsers.Update_SessionEnd_And_Online(
        DateTime.Now,
        false);

    AddTask("DoStuff", 10);
}

Thủ tục lưu trữ đang được gọi là:

ALTER Procedure [dbo].[sp_OnlineUsers_Update_SessionEnd_And_Online]
    @Session_End datetime,
    @Online bit
As
Begin
    Update OnlineUsers
    SET
        [Session_End] = @Session_End,
        [Online] = @Online

End

Tôi có hai phương pháp để có được người dùng trực tuyến:

  1. sử dụng Application["OnlineUsers"] = 0;
  2. một cái khác sử dụng cơ sở dữ liệu

Vì vậy, đối với phương pháp # 2, tôi đặt lại tất cả Người dùng trực tuyến tại Application_Start. Có hơn 482.751 hồ sơ trong bảng đó.


1
Như đã nói ở đây Mặc định là 15 giây
V4Vendetta

1
Tốt hơn để thực hiện phân tích nguyên nhân gốc rễ, Có nhiều lý do để gây ra vấn đề như vậy. Cơ bản nhất là cấu trúc phức tạp của truy vấn. Tôi gặp vấn đề tương tự khi tôi tìm nạp Hình ảnh được lưu dưới dạng giá trị Hex trong bảng.
Vijay Kumbhoje

Ngoài các nguyên nhân trên, tôi sẽ thêm một nguyên nhân nữa: Hết thời gian khóa: docs.microsoft.com/en-us/sql/t-sql/statements/ trộm Nếu chủ đề này chờ khóa quá lâu, nó sẽ hết thời gian dựa trên tài liệu trên.
Herbert Yu

Câu trả lời:


344

Có vẻ như bạn có một truy vấn mất nhiều thời gian hơn bình thường. Từ theo dõi ngăn xếp và mã của bạn, bạn sẽ có thể xác định chính xác đó là truy vấn nào.

Loại thời gian chờ này có thể có ba nguyên nhân;

  1. Có một bế tắc ở đâu đó
  2. Số liệu thống kê của cơ sở dữ liệu và / hoặc bộ đệm kế hoạch truy vấn không chính xác
  3. Truy vấn quá phức tạp và cần được điều chỉnh

Một bế tắc có thể khó khắc phục, nhưng thật dễ dàng để xác định liệu đó có phải là trường hợp không. Kết nối với cơ sở dữ liệu của bạn với Sql Server Management Studio. Trong khung bên trái, nhấp chuột phải vào nút máy chủ và chọn Activity Monitor . Hãy xem các quá trình đang chạy. Thông thường hầu hết sẽ không hoạt động hoặc đang chạy. Khi sự cố xảy ra, bạn có thể xác định bất kỳ quy trình bị chặn bởi trạng thái quy trình. Nếu bạn nhấp chuột phải vào quy trình và chọn chi tiết, nó sẽ hiển thị cho bạn truy vấn cuối cùng được thực hiện bởi quy trình.

Vấn đề thứ hai sẽ khiến cơ sở dữ liệu sử dụng gói truy vấn tối ưu phụ. Nó có thể được giải quyết bằng cách xóa số liệu thống kê:

exec sp_updatestats

Nếu điều đó không hiệu quả, bạn cũng có thể thử

dbcc freeproccache

Bạn không nên làm điều này khi máy chủ của bạn đang tải nặng vì nó sẽ tạm thời phải chịu một cú đánh hiệu suất lớn vì tất cả các procs và truy vấn được lưu trữ được biên dịch lại khi lần đầu tiên được thực hiện. Tuy nhiên, kể từ khi bạn nêu vấn đề này xảy ra đôi khi , và stack trace chỉ ra ứng dụng của bạn đang bắt đầu lên, tôi nghĩ rằng bạn đang chạy một truy vấn mà chỉ được chạy trên thỉnh thoảng. Bạn có thể tốt hơn bằng cách buộc SQL Server không sử dụng lại gói kế hoạch truy vấn trước đó. Xem câu trả lời này để biết chi tiết về cách làm điều đó.

Tôi đã chạm vào vấn đề thứ ba, nhưng bạn có thể dễ dàng xác định liệu truy vấn có cần điều chỉnh hay không bằng cách thực hiện truy vấn theo cách thủ công, ví dụ như sử dụng Sql Server Management Studio. Nếu truy vấn mất quá nhiều thời gian để hoàn thành, ngay cả sau khi đặt lại các số liệu thống kê, bạn có thể cần phải điều chỉnh nó. Để được giúp đỡ với điều đó, bạn nên đăng câu hỏi chính xác trong một câu hỏi mới.


39
Tôi đã gặp lỗi tương tự nhưng trong một truy vấn 'chỉ' mất 8 giây ... và mẹo của bạn về cách exec sp_updatestatsgiải quyết vấn đề của tôi. Cảm ơn nhiều!
nrod

2
Giải quyết một vấn đề như thế này hầu như không bao giờ là vấn đề điều chỉnh thời gian chờ hoặc kích thước nhóm kết nối. Bạn sẽ cần phải đi sâu vào và tìm ra nguyên nhân gốc rễ. Nếu bạn cần trợ giúp để giải quyết nguyên nhân gốc rễ đó, bạn có thể đăng câu hỏi của riêng mình.
Marnix van Valen

5
Đây chắc chắn không phải là một bế tắc. Nó có thể được gây ra bởi việc chặn quá mức, nhưng các bế tắc được giải quyết trong một giây và chúng tạo ra các lỗi khác nhau. Điều này có thể bị chặn quá mức, nhưng không phải là một bế tắc.
Michael J Swart

1
chúng tôi có chắc chắn đây là Hết giờ lệnh và không phải là Hết thời gian kết nối không? "System.Data.SqlClient.SqlConnection.OnError" với tôi chỉ ra sự cố kết nối.
Mike W

1
@PrashantPimpale Nó phụ thuộc Nếu bạn gặp vấn đề nghiêm trọng trong sản xuất khi số liệu thống kê không chính xác dẫn đến kế hoạch thực hiện tồi thì, vâng, đây có thể là một giải pháp. Chặn các vấn đề đặc biệt (như lỗi phần cứng), cập nhật số liệu thống kê sẽ không phá vỡ cơ sở dữ liệu của bạn. Nó có thể gây ra các truy vấn chậm hơn một chút. Cuối cùng, đó là cuộc gọi của bạn.
Marnix van Valen

155

Trong mã của bạn nơi bạn chạy thủ tục được lưu trữ, bạn sẽ có một cái gì đó như thế này:

SqlCommand c = new SqlCommand(...)
//...

Thêm một dòng mã như vậy:

c.CommandTimeout = 0;

Điều này sẽ đợi nhiều thời gian cần thiết để hoạt động hoàn thành.


143
Bạn cũng nên lưu ý rằng giá trị 0 không được khuyến nghị : Giá trị 0 chỉ ra không có giới hạn và nên tránh trong CommandTimeout vì một nỗ lực thực thi lệnh sẽ chờ vô thời hạn. Tốt hơn là nên học lệnh mất bao nhiêu thời gian và tăng giá trị Hết giờ nếu cần.
Otiel

7
Tôi đồng ý với Otiel và từ chối câu trả lời của bạn: Khi đặt lệnhTimeTime thành 0, bạn không cho máy chủ web cơ hội khôi phục từ máy chủ cơ sở dữ liệu không phải là phản hồi. Thứ hai, khi bạn nhấn thời gian chờ mặc định, bạn nên xem xét nguyên nhân. Trong hầu hết các trường hợp, tốt hơn là sửa truy vấn hơn là tăng thời gian chờ.
Maarten Kieft

10
Tôi sẽ không rơi vào cái bẫy không giới thiệu nó. Nó rất hữu ích cho tôi và các nhiệm vụ được lên lịch hàng ngày của tôi: Có thời gian chờ vô hạn không ngăn quá trình hoàn thành và trả về lỗi nếu có sự cố. Nói một cách đơn giản, nó chỉ giúp bạn cho phép một truy vấn kết thúc bất cứ khi nào cần, mà không gây ra vấn đề gì cho bạn sau này, vì bạn đã không phân bổ đủ thời gian để quá trình kết thúc. Bạn cũng có thể tránh bị khóa chương trình của mình bằng cách đa luồng.
WonderWorker

2
Có đối với chuyển dữ liệu lớn không thiết lập điều này không có ý nghĩa. Nếu bạn đang chuyển hàng triệu hàng thì những gì Otiel và BlackHawkDesign đang nói không có ý nghĩa gì.
bluerubez

Trong 20 năm phát triển tập trung vào dữ liệu, tôi chưa bao giờ cần phải làm điều này. Hầu như luôn luôn có một giải pháp hợp lý đơn giản mang lại hiệu suất tốt hơn và không tạo ra cơ hội cho một quy trình duy nhất có thể làm hỏng cơ sở dữ liệu suốt cả ngày. Phần lớn các vấn đề về hiệu năng db có thể được điều chỉnh để chúng thực hiện một số thứ tự cường độ nhanh hơn. Tức là quá trình bạn đang chờ 3 giờ để hoàn thành, có thể được điều chỉnh thành 3 phút hoặc thậm chí 3 giây.
b_levitt

25

Bạn có thể đặt thuộc CommandTimeouttính của Lệnh SQL để cho phép giao dịch SQL chạy dài.

Bạn cũng có thể cần phải xem Truy vấn SQL gây ra thời gian chờ.


xin chào, "hoặc bạn cần xem Truy vấn SQL đang hết thời gian chờ" -> trong máy chủ sql 2008 tôi nên kiểm tra thời gian chờ đó ở đâu?
SilverLight

Bạn có thể cần kiểm tra Quy trình được lưu trữ được gọi từ DataLayer.OnlineUsers.Update_SessionEnd_And_Online khi Trace Stack dường như hướng đến nó. Lấy một bản sao của cơ sở dữ liệu trực tiếp để kiểm tra và chạy Thủ tục lưu trữ trong các tham số bắt buộc, nếu mất hơn 30 giây để hoàn thành, đó là lý do tại sao bạn sắp hết thời gian. Tôi giả sử bạn có quyền truy cập vào SQL Server Management Studio.
Kev Ritchie

vâng, tôi có quyền truy cập vào máy chủ sql năm 2008. Tôi nên thử theo cách của bạn.
SilverLight

Nếu bạn tìm thấy quy trình được lưu trữ gây ra sự cố, bạn có thể chạy truy vấn có trong quy trình được lưu trữ thông qua Trình cố vấn điều chỉnh cơ sở dữ liệu sẽ đề xuất nếu bạn cần bất kỳ chỉ mục nào, v.v. Liên kết tại đây msdn.microsoft.com/en-us/l Library /ms174202.aspx
Kev Ritchie

12

Trong khi tất cả các phản hồi trước đó giải quyết vấn đề, họ không bao gồm tất cả các trường hợp.

Microsoft đã thừa nhận sự cố và khắc phục sự cố vào năm 2011 cho các hệ điều hành được hỗ trợ, vì vậy nếu bạn nhận được dấu vết ngăn xếp như:

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)

bạn có thể cần cập nhật các cụm .NET của mình.

Sự cố này xảy ra do lỗi trong thuật toán thử lại kết nối cho cơ sở dữ liệu được nhân đôi.

Khi thuật toán thử lại được sử dụng, nhà cung cấp dữ liệu sẽ chờ lệnh gọi đầu tiên (SniReadSync) kết thúc. Cuộc gọi được gửi đến máy tính phía sau đang chạy SQL Server và thời gian chờ được tính bằng cách nhân giá trị hết thời gian kết nối với 0,08. Tuy nhiên, nhà cung cấp dữ liệu đặt kết nối không chính xác sang trạng thái cam chịu nếu phản hồi chậm và nếu cuộc gọi SniReadSync đầu tiên không hoàn thành trước khi hết thời gian chờ.

Xem KB 2605597 để biết chi tiết

https://support.microsoft.com/kb/2605597


9

Có lẽ nó sẽ hữu ích cho ai đó. Tôi đã đối mặt với cùng một vấn đề và trong trường hợp của tôi, lý do là SqlConnection đã được mở và không được xử lý theo phương thức mà tôi đã gọi trong vòng lặp với khoảng 2500 lần lặp. Hồ bơi kết nối đã cạn kiệt. Bố trí đúng cách giải quyết vấn đề.


điều này! chính xác điều này Vấn đề của tôi là tôi đã bắn ra các phương thức trên một luồng khác mà không cần chờ chúng (vì người dùng không cần kết quả của phương thức đó, tập lệnh nền). Không cần xử lý (sử dụng các usingkhối) Tôi đã gặp sự cố hết thời gian này. Điều này dường như để giải quyết nó.
CularBytes

bạn đã nhận được lỗi hết thời gian với nhóm kết nối tối đa đạt được hay hết thời gian chờ. Khoảng thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi. Bởi vì, nếu bạn nhận được nhóm tối đa đạt được, sẽ rất hợp lý khi xem xét kết nối bị rò rỉ. Nhưng, tôi nhận được máy chủ không phản hồi lỗi.
Jeeva Subburaj

8

Tôi đã đối mặt với cùng một vấn đề trong khoảng 3 ngày. Tôi nhận thấy rằng số lượng hồ sơ của chúng tôi không nhiều nhà phát triển cao cấp của chúng tôi lưu giữ 2 hình ảnh và Dấu vân tay trong cơ sở dữ liệu. Khi tôi cố gắng tìm nạp các giá trị hex này mất nhiều thời gian, tôi tính thời gian trung bình để thực hiện quy trình của mình trong khoảng 38 giây. Thời gian lệnh mặc định là 30 giây, do đó cần ít hơn thời gian trung bình để chạy thủ tục được lưu trữ của tôi. Tôi đặt thời gian ra lệnh của mình như bên dưới

cmd.CommandTimeout = 50

và nó hoạt động tốt nhưng đôi khi nếu truy vấn của bạn mất hơn 50 giây thì nó sẽ báo lỗi tương tự.


8

Bạn phải đặt thuộc tính CommandTimeout. Bạn có thể đặt thuộc tính CommandTimeout trong lớp con DbContext.

public partial class StudentDatabaseEntities : DbContext
{
    public StudentDatabaseEntities()
        : base("name=StudentDatabaseEntities")
    {
        this.Database.CommandTimeout = 180;
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        throw new UnintentionalCodeFirstException();
    }

    public virtual DbSet<StudentDbTable> StudentDbTables { get; set; }
}

4

Tôi đã gặp lỗi này gần đây và sau một số điều tra ngắn, đã tìm ra nguyên nhân là chúng tôi đã hết dung lượng trên đĩa chứa cơ sở dữ liệu (dưới 1GB).

Ngay khi tôi chuyển các tệp cơ sở dữ liệu (.mdf và .ldf) sang một đĩa khác trên cùng một máy chủ (có nhiều dung lượng hơn), cùng một trang (chạy truy vấn) đã hết thời gian tải trong vòng ba giây.

Một điều khác để điều tra, trong khi cố gắng giải quyết lỗi này, là kích thước của tệp nhật ký cơ sở dữ liệu. Các tệp nhật ký của bạn có thể cần phải được thu nhỏ.


3

Tôi gặp vấn đề với tính toán lớn trong sp_foo, mất nhiều thời gian nên tôi đã sửa
với mã bit nhỏ này

public partial class FooEntities : DbContext
{
   public FooEntities()
         : base("name=FooEntities")
    {
        this.Configuration.LazyLoadingEnabled = false;

        // Get the ObjectContext related to this DbContext
        var objectContext = (this as IObjectContextAdapter).ObjectContext;

        // Sets the command timeout for all the commands
        objectContext.CommandTimeout = 380;
    }

3

Thời gian chờ mặc định là 15 giây, để thay đổi điều đó, 0 là không giới hạn, bất kỳ số nào khác là số giây.

Trong mã

using (SqlCommand sqlCmd = new SqlCommand(sqlQueryString, sqlConnection))
   {
      sqlCmd.CommandTimeout = 0; // 0 = give it as much time as it needs to complete
      ...
    }

Trong Web.Config của bạn, "Hết thời gian lệnh = 0;" không hết giờ hoặc dưới 1 giờ (3600 giây)

  <add name="ConnectionString" connectionString="Data Source=ServerName;User ID=UserName;Password=Password;Command Timeout=3600;" providerName="System.Data.SqlClient" />

2
Đó là hai thời gian chờ khác nhau. Đề nghị đầu tiên của bạn giải quyết câu hỏi. Thứ hai của bạn sẽ chỉ hoạt động nếu nhà cung cấp kết nối hỗ trợ nó, điều mà SqlClient không có. Ở bất cứ giá nào, thời gian chờ là 0 không bao giờ là một ý tưởng hay trong sản xuất. 30 giây là mặc định thông thường.
Suncat2000

2

@SilverLight .. Đây rõ ràng là một vấn đề với đối tượng Cơ sở dữ liệu. Nó có thể là một truy vấn bằng văn bản xấu, hoặc thiếu chỉ mục. Nhưng đến bây giờ tôi sẽ không đề nghị bạn tăng thời gian chờ mà không điều tra vấn đề với các đối tượng Cơ sở dữ liệu của bạn

NovinMedia.Data.DbObject.RunProcedure(String storedProcName, IDataParameter[] parameters, Int32& rowsAffected) +209

Đặt một điểm dừng trên dòng mã này để tìm ra tên thủ tục và sau đó tối ưu hóa thủ tục bằng cách xem xét kế hoạch thực hiện của nó.

Tôi không thể giúp bạn nhiều hơn cho đến khi bạn đăng chi tiết về thủ tục được lưu trữ.


Thủ tục lưu trữ không làm bất kỳ công cụ ưa thích. Tuy nhiên, có vẻ như bảng OnlineUsers đang bị khóa trong khi thủ tục đang được thực thi. Hãy thử trình tạo hồ sơ SQL để xem những gì đang xảy ra tại Application_Start
Amit Rai Sharma

2

thử

EXEC SP_CONFIGURE 'remote query timeout', 1800
reconfigure
EXEC sp_configure

EXEC SP_CONFIGURE 'show advanced options', 1
reconfigure
EXEC sp_configure

EXEC SP_CONFIGURE 'remote query timeout', 1800
reconfigure
EXEC sp_configure

sau đó xây dựng lại chỉ mục của bạn


8
Bạn có thể giải thích giải pháp của bạn?
Hp93

0

Hết thời gian hết hạn vì truy vấn sql mất nhiều thời gian hơn bạn đặt trong thuộc tính sqlCommand.CommandTimeout.

Rõ ràng bạn có thể tăng CommandTimeout để giải quyết vấn đề này nhưng trước khi thực hiện điều đó, bạn phải tối ưu hóa truy vấn của mình bằng cách thêm chỉ mục. Nếu bạn chạy truy vấn của mình trong studio quản lý máy chủ Sql bao gồm cả kế hoạch thực hiện thực tế thì studio quản lý máy chủ Sql sẽ gợi ý cho bạn chỉ mục thích hợp. Hầu hết các trường hợp bạn sẽ thoát khỏi vấn đề thời gian chờ nếu bạn có thể tối ưu hóa truy vấn của mình.


0

TLDR :

  1. Khởi động lại cả ứng dụng và máy chủ DB là cách khắc phục nhanh nhất trong đó khối lượng dữ liệu, cài đặt mạng và mã không thay đổi. Chúng tôi luôn làm như vậy như một quy luật
  2. Có thể là dấu hiệu của lỗi ổ cứng cần thay thế - kiểm tra thông báo hệ thống

Tôi thường gặp phải lỗi này vì nhiều lý do và đã có nhiều giải pháp khác nhau, bao gồm:

  1. tái cấu trúc mã của tôi để sử dụng SqlBulkCopy
  2. tăng giá trị Hết giờ, như đã nêu trong các câu trả lời khác nhau hoặc kiểm tra các nguyên nhân cơ bản ( có thể không liên quan đến dữ liệu )
  3. Hết thời gian kết nối (Mặc định 15 giây) - Mất bao lâu để chờ kết nối được thiết lập với máy chủ SQL trước khi chấm dứt - liên quan đến TCP / PORT - có thể đi qua danh sách kiểm tra khắc phục sự cố (bài viết MSDN rất tiện dụng)
  4. Hết thời gian lệnh (Mặc định 30 giây) - Mất bao lâu để chờ thực hiện truy vấn - Thực hiện truy vấn / lưu lượng truy cập mạng liên quan - cũng có quy trình khắc phục sự cố (một bài viết MSDN rất tiện dụng khác)
  5. Khởi động lại (các) máy chủ - cả ứng dụng & Máy chủ DB (nếu tách rời) - nơi mã và dữ liệu không thay đổi, môi trường phải thay đổi - Điều đầu tiên bạn phải làm. Thông thường gây ra bởi các bản vá (hệ điều hành, .Net Framework hoặc SQL Server bản vá hoặc cập nhật). Đặc biệt nếu ngoại lệ hết thời gian xuất hiện như bên dưới (ngay cả khi chúng tôi không sử dụng Azure):
    • System.Data.Entity.Core.EntityException: Một ngoại lệ đã được nêu ra có khả năng là do lỗi tạm thời. Nếu bạn đang kết nối với cơ sở dữ liệu SQL Azure, hãy cân nhắc sử dụng SqlAzureExecutStrargety. ---> System.Data.Entity.Core.EntityCommandExecutException: Đã xảy ra lỗi khi thực hiện định nghĩa lệnh. Xem ngoại lệ bên trong để biết chi tiết. ---> System.Data.SqlClient.SqlException: Đã 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 TCP, lỗi: 0 - Hết thời gian chờ semaphore đã hết hạn.) ---> System.ComponentModel.Win32Exception: Hết thời gian chờ semaphore đã hết hạn

0

Ngoài ra, hãy đảm bảo bạn không có giao dịch đang chờ xử lý. :)

Tôi đã thực hiện một số thử nghiệm xung quanh và bắt đầu một giao dịch để được an toàn nhưng không bao giờ đóng nó. Tôi ước rằng lỗi sẽ rõ ràng hơn nhưng oh tốt!


0

Chúng tôi đã có thời gian khó khăn trên Timeout expired/max pool reached Sqlexception. Là một cách giải quyết và để ngăn khởi động lại máy chủ hoặc dịch vụ, chúng tôi sửa đổi MAX SERVER MEMORYbiến trong SQL Server (thông qua SQL Management Studio hoặc T-SQL):

DECLARE @maxMem INT = 3000 --Max. memory for SQL Server instance in MB
EXEC sp_configure 'show advanced options', 1
RECONFIGURE

Điều này tạm thời khắc phục vấn đề cho đến khi nó xảy ra một lần nữa. Trong trường hợp của chúng tôi, chúng tôi nghi ngờ rằng nó có liên quan đến rò rỉ kết nối ở cấp ứng dụng.


0

Gần đây chúng tôi đã nâng cấp lên phiên bản NuGet của SqlClient( Microsoft.Data.SqlClient) có lỗi . Lỗi này đã được giới thiệu trong suốt vòng đời của chu kỳ 1.x và đã được sửa. Bản sửa lỗi sẽ có sẵn trong bản phát hành 2.0.0 không có sẵn tại thời điểm viết bài này. Một bản xem trước có sẵn.

Bạn có thể kiểm tra các chi tiết tại đây: https://github.com/dotnet/SqlClient/issues/262

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.