Limit czasu upłynął. Limit czasu upłynął przed zakończeniem operacji lub serwer nie odpowiada. Instrukcja została zakończona

295

Mam wielu użytkowników na mojej stronie internetowej (20000–60000 dziennie), która jest witryną pobierania plików mobilnych. Mam zdalny dostęp do mojego serwera (Windows Server 2008-R2). Wcześniej
otrzymywałem błędy „Serwer jest niedostępny” , ale teraz widzę błąd przekroczenia limitu czasu połączenia.
Nie znam się na tym - dlaczego tak się dzieje i jak mogę to naprawić?

Pełny błąd znajduje się poniżej:

Błąd serwera w aplikacji „/”. Limit czasu upłynął. Limit czasu upłynął przed zakończeniem operacji lub serwer nie odpowiada. Instrukcja została zakończona. Opis: Wystąpił nieobsługiwany wyjątek podczas wykonywania bieżącego żądania internetowego. Przejrzyj dane śledzenia stosu, aby uzyskać więcej informacji o błędzie i jego źródle w kodzie.

Szczegóły wyjątku: System.Data.SqlClient.SqlException: Upłynął limit czasu. Limit czasu upłynął przed zakończeniem operacji lub serwer nie odpowiada. Instrukcja została zakończona.

Błąd źródła:

Podczas obsługi bieżącego żądania sieciowego wygenerowano nieobsługiwany wyjątek. Informacje dotyczące pochodzenia i lokalizacji wyjątku można zidentyfikować za pomocą śledzenia stosu wyjątków poniżej.

Ślad stosu:

[SqlException (0x80131904): Upłynął limit czasu. Limit czasu upłynął przed zakończeniem operacji lub serwer nie odpowiada. Instrukcja została zakończona.]
System.Data.SqlClient.SqlConnection.OnError (wyjątek SqlException, Boolean breakConnection) +404
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning () +412
System.Data.SqlClient.TdsParserhe Run Run , SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) +1363
System.Data.SqlClient.SqlCommand.FinishExecuteReader (SqlDataBeRaverior, Run RunSer
System.Data.SqlClient.SqlCommand.RunExecuteReaderTds (CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) +6389442
System.Data.SqlClient.SqlCommand.RunExecuteBeReHeReRe 538
System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery (wynik DbAsyncResult, ciąg MethodName, Boolean sendToPipe) +689
System.Data.SqlClient.SqlCommand.ExecuteNonQuery () +327
Parametry NovinMediaDataDataProcedura , Int32 i wiersze zmienione) +209
DataLayer.OnlineUsers.Update_SessionEnd_And_Online (Object Session_End, Boolean Online) +440
NiceFileExplorer.Global.Application_Start (Nadawca obiektu, EventArgs e) +163

[HttpException (0x80004005): Upłynął limit czasu. Limit czasu upłynął przed zakończeniem operacji lub serwer nie odpowiada. Oświadczenie zostało zakończone.]
System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode (HttpContext kontekst, HttpApplication app) +4052053
System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS (IntPtr appContext, HttpContext kontekst, MethodInfo [] koparki) +191
System.Web.HttpApplication. InitSpecial (stan HttpApplicationState, procedury obsługi MethodInfo [], kontekst aplikacji IntPtr, kontekst HttpContext) +352
System.Web.HttpApplicationFactory.GetSpecialApplicationInstance (kontekst aplikacji IntPtr, kontekst kontekstu HttpContext) +407
System.Web.Hosting.PipextRuntime.Info

[HttpException (0x80004005): Upłynął limit czasu. Limit czasu upłynął przed zakończeniem operacji lub serwer nie odpowiada. Instrukcja została zakończona.]
System.Web.HttpRuntime.FirstRequestInit (kontekst HttpContext) +11686928 System.Web.HttpRuntime.EnsureFirstRequestInit (kontekst HttpContext) +141 System.Web.HttpRuntime.ProcessRequestNotificationPrivate II Nota prywatna7 Nota prywatna


EDIT PO odpowiada:
my Application_Startw Global.asaxto jak poniżej:

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

    OnlineUsers.Update_SessionEnd_And_Online(
        DateTime.Now,
        false);

    AddTask("DoStuff", 10);
}

Wywoływana procedura składowana to:

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

Mam dwie metody pozyskiwania użytkowników online:

  1. za pomocą Application["OnlineUsers"] = 0;
  2. drugi używa bazy danych

Tak więc dla metody nr 2 resetuję wszystkich użytkowników online o Application_Start. W tej tabeli znajduje się ponad 482 751 rekordów.

SilverLight
źródło
1
Jak tu napisano Domyślnie jest 15 sekund
V4Vendetta,
1
Lepiej przeprowadzić analizę przyczyn źródłowych. Istnieje wiele przyczyn powodujących taki problem. Najbardziej podstawowa jest złożona struktura zapytania. Napotkałem ten sam problem podczas pobierania obrazów, które przechowywane są jako wartości szesnastkowe w tabeli.
Vijay Kumbhoje
Oprócz powyższych przyczyn dodam jeszcze jeden: Limit czasu blokady: docs.microsoft.com/en-us/sql/t-sql/statements/… Jeśli ten wątek będzie czekał na blokadę zbyt długo, upłynie limit czasu powyżej dokumentu.
Herbert Yu

Odpowiedzi:

344

Wygląda na to, że masz zapytanie, które trwa dłużej niż powinno. Ze śladu stosu i kodu powinieneś być w stanie dokładnie określić, jakie to zapytanie.

Ten typ limitu czasu może mieć trzy przyczyny;

  1. Gdzieś jest impas
  2. Statystyki bazy danych i / lub pamięć podręczna planu zapytań są niepoprawne
  3. Kwerenda jest zbyt złożona i wymaga dostosowania

Impas może być trudny do naprawienia, ale łatwo jest ustalić, czy tak jest. Połącz się z bazą danych za pomocą Sql Server Management Studio. W lewym okienku kliknij prawym przyciskiem myszy węzeł serwera i wybierz Monitor aktywności . Spójrz na uruchomione procesy. Zwykle większość będzie bezczynna lub działa. Gdy wystąpi problem, możesz zidentyfikować każdy zablokowany proces według stanu procesu. Jeśli klikniesz prawym przyciskiem myszy na proces i wybierzesz szczegóły , wyświetli się ostatnie zapytanie wykonane przez proces.

Drugi problem spowoduje, że baza danych będzie korzystała z nieoptymalnego planu zapytań. Można to rozwiązać, usuwając statystyki:

exec sp_updatestats

Jeśli to nie zadziała, możesz spróbować

dbcc freeproccache

Nie powinieneś tego robić, gdy twój serwer jest obciążony, ponieważ tymczasowo poniesie duży hit wydajności, ponieważ wszystkie przechowywane procy i zapytania są rekompilowane przy pierwszym uruchomieniu. Ponieważ jednak stwierdzasz, że problem występuje czasami , a ślad stosu wskazuje, że aplikacja się uruchamia, myślę, że uruchamiasz zapytanie, które jest uruchamiane tylko od czasu do czasu. Lepiej może być wymuszając na SQL Server nieużywanie poprzedniego planu zapytań. Zobacz tę odpowiedź, aby dowiedzieć się, jak to zrobić.

Dotknąłem już trzeciego problemu, ale możesz łatwo ustalić, czy zapytanie wymaga dostrojenia, wykonując je ręcznie, na przykład za pomocą Sql Server Management Studio. Jeśli zapytanie trwa zbyt długo, nawet po zresetowaniu statystyk prawdopodobnie będziesz musiał je dostroić. Aby uzyskać pomoc, powinieneś zamieścić dokładne zapytanie w nowym pytaniu.

Marnix van Valen
źródło
39
Miałem ten sam błąd, ale w zapytaniu, które „tylko” zajęło 8 sekund ... i twoja wskazówka na temat exec sp_updatestatsrozwiązania mojego problemu. Wielkie dzięki!
nrod
2
Rozwiązanie takiego problemu prawie nigdy nie jest kwestią dostrajania limitów czasu lub wielkości puli połączeń. Musisz zanurkować i ustalić przyczynę. Jeśli potrzebujesz pomocy w rozwiązaniu tej podstawowej przyczyny, możesz opublikować własne pytanie.
Marnix van Valen
5
Z pewnością nie jest to impas. Może to być spowodowane nadmiernym blokowaniem, ale zakleszczenia są rozwiązywane w ciągu sekundy i generują różne błędy. Może to być nadmierne blokowanie, ale nie impas.
Michael J Swart
1
czy jesteśmy pewni, że jest to limit czasu polecenia, a nie limit połączenia? „System.Data.SqlClient.SqlConnection.OnError” dla mnie oznacza problem z połączeniem.
Mike W
1
@PrashantPimpale To zależy Jeśli masz poważny problem z produkcją, w którym nieprawidłowe statystyki prowadzą do złych planów wykonania, to tak, może to być rozwiązanie. Z wyjątkiem wyjątkowych problemów (takich jak awaria sprzętu) aktualizacja statystyk nie spowoduje uszkodzenia bazy danych. Może to powodować nieco wolniejsze zapytania. W końcu jednak to twój telefon.
Marnix van Valen
155

W kodzie, w którym uruchamiasz procedurę przechowywaną, powinieneś mieć coś takiego:

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

Dodaj taki wiersz kodu:

c.CommandTimeout = 0;

Będzie to czekać tyle czasu, ile potrzeba na zakończenie operacji.

Elastep
źródło
143
Należy również pamiętać, że wartość 0 nie jest zalecana : wartość 0 wskazuje brak limitu i należy jej unikać w CommandTimeout, ponieważ próba wykonania polecenia będzie czekać w nieskończoność. Lepiej dowiedzieć się, ile czasu zajmuje polecenie, i w razie potrzeby zwiększyć wartość Limit czasu.
Otiel
7
Zgadzam się z Otielem i przegłosowałem twoją odpowiedź: Ustawiając komendę TimeTime na 0, nie dajesz serwerowi sieci Web szansy na odzyskanie danych z serwera bazy danych, który nie odpowiada. Po drugie, gdy przekroczysz domyślny limit czasu, powinieneś rozważyć przyjrzenie się przyczynie. W większości przypadków lepiej jest naprawić zapytanie niż zwiększyć limit czasu.
Maarten Kieft
10
Nie wpadłbym w pułapkę, że jej nie polecam. Jest to bardzo przydatne dla mnie i moich codziennych zaplanowanych zadań: nieskończony limit czasu nie zatrzymuje procesu kończącego się i zwraca błąd, jeśli coś pójdzie nie tak. Mówiąc najprościej, pozwala tylko na zakończenie zapytania w dowolnym momencie, bez stwarzania problemów później, ponieważ nie masz wystarczająco dużo czasu na zakończenie procesu. Możesz także uniknąć blokowania programu przez wielowątkowość.
WonderWorker,
2
Tak, jeśli nie ustawiono dużych transferów danych, nie ma to sensu. Jeśli przenosisz miliony wierszy, to, co mówią Otiel i BlackHawkDesign, nie ma sensu.
bluerubez
W ciągu 20 lat rozwoju skoncentrowanego na danych nigdy nie musiałem tego robić. Prawie zawsze istnieje dość proste rozwiązanie, które zapewnia lepszą wydajność i nie stwarza możliwości jednemu procesowi przeszukiwania bazy danych przez cały dzień. Zdecydowaną większość problemów z wydajnością db można dostroić do miejsca, w którym wykonują one kilka rzędów wielkości szybciej. To znaczy, że proces, na który czekasz 3 godziny, prawdopodobnie może zostać dostosowany do 3 minut, a nawet 3 sekund.
b_levitt,
25

Można ustawić CommandTimeoutwłaściwość polecenia SQL, aby zezwolić na długo działającą transakcję SQL.

Konieczne może być także przyjrzenie się zapytaniu SQL, które powoduje przekroczenie limitu czasu.

Kev Ritchie
źródło
cześć "lub trzeba spojrzeć na zapytanie SQL, które powoduje przekroczenie limitu czasu" -> w SQL Server 2008, gdzie powinienem sprawdzić ten limit?
SilverLight,
Konieczne może być przetestowanie procedury składowanej wywoływanej z DataLayer.OnlineUsers.Update_SessionEnd_And_Online, ponieważ ślad stosu wydaje się wskazywać w tym kierunku. Weź kopię testowej bazy danych na żywo i uruchom Procedurę składowaną, przekazując wymagane parametry, jeśli jej ukończenie zajmie więcej niż 30 sekund, dlatego masz czas na przerwę. Zakładam, że masz dostęp do SQL Server Management Studio.
Kev Ritchie,
tak, mam dostęp do serwera SQL 2008. Powinienem spróbować.
SilverLight,
Jeśli znajdziesz procedurę przechowywaną, która powoduje problem, możesz uruchomić zapytanie zawarte w procedurze przechowywanej za pośrednictwem Doradcy dostrajania bazy danych, który zasugeruje, czy potrzebujesz indeksów itp. Link tutaj msdn.microsoft.com/en-us/library /ms174202.aspx
Kev Ritchie
12

Chociaż wszystkie wcześniejsze odpowiedzi dotyczą tego problemu, nie obejmowały wszystkich przypadków.

Firma Microsoft potwierdziła problem i naprawiła go w 2011 roku dla obsługiwanych systemów operacyjnych, więc jeśli otrzymasz ślad stosu, taki jak:

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)

może być konieczne zaktualizowanie zestawów .NET.

Ten problem występuje z powodu błędu w algorytmie ponownej próby połączenia dla lustrzanych baz danych.

Gdy używany jest algorytm ponownej próby, dostawca danych czeka na zakończenie pierwszego wywołania odczytu (SniReadSync). Wywołanie jest wysyłane do komputera zaplecza, na którym działa program SQL Server, a czas oczekiwania jest obliczany przez pomnożenie wartości limitu czasu połączenia przez 0,08. Jednak dostawca danych niepoprawnie ustawia połączenie na stan skazany na niepowodzenie, jeśli odpowiedź jest powolna i jeśli pierwsze wywołanie SniReadSync nie zostanie zakończone przed upływem czasu oczekiwania.

Szczegółowe informacje zawiera KB 2605597

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

Matcheek
źródło
9

Może przyda się komuś. Zetknąłem się z tym samym problemem i w moim przypadku przyczyną było to, że SqlConnection został otwarty i nie został umieszczony w metodzie, którą wywołałem w pętli z około 2500 iteracjami. Pula połączeń została wyczerpana. Właściwe usunięcie rozwiązało problem.

wieczność
źródło
to! Dokładnie to. Mój problem polegał na tym, że odpalałem metody w innym wątku, nie czekając na nie (ponieważ użytkownik nie potrzebuje wyniku tej metody, skryptu w tle). Bez usuwania (korzystania z usingbloków) mam problem z przekroczeniem limitu czasu. To wydawało się rozwiązać.
CularBytes
czy wystąpił błąd przekroczenia limitu czasu przy puli połączeń, czy upłynął limit czasu? Limit czasu upłynął przed zakończeniem operacji lub serwer nie reaguje, ponieważ jeśli otrzymasz maksymalną osiągniętą pulę, warto poszukać informacji o nieszczelnym połączeniu. ale dostaję błąd serwera.
Jeeva Subburaj
8

Musisz ustawić atrybut CommandTimeout. Możesz ustawić atrybut CommandTimeout w klasie potomnej 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; }
}
Siddarth Kanted
źródło
7

Napotkałem ten sam problem, który pracował nad nim około 3 dni. Zauważyłem, ponieważ nasza liczba rekordów to niewiele, nasz starszy programista przechowuje 2 obrazy i odcisk palca w bazie danych. Kiedy próbuję pobrać te wartości szesnastkowe, co zajmuje dużo czasu, obliczam średni czas wykonania mojej procedury na około 38 sekund. Domyślny limit czasu poleceń wynosi 30 sekund, więc jest to mniej niż średni czas wymagany do uruchomienia mojej procedury składowanej. Ustawiłem limit czasu poleceń jak poniżej

cmd.CommandTimeout = 50

i działa dobrze, ale czasami, jeśli twoje zapytanie trwa dłużej niż 50 sekund, wyświetli ten sam błąd.

Vijay Kumbhoje
źródło
4

Ostatnio napotkałem ten błąd i po krótkim dochodzeniu odkryłem, że przyczyną jest brak miejsca na dysku przechowującym bazę danych (mniej niż 1 GB).

Gdy tylko przeniosłem pliki bazy danych (.mdf i .ldf) na inny dysk na tym samym serwerze (z dużo większą ilością miejsca), ta sama strona (uruchamiająca zapytanie) została wczytana w ciągu trzech sekund.

Inną kwestią do zbadania podczas próby rozwiązania tego błędu jest rozmiar plików dziennika bazy danych. Twoje pliki dziennika mogą wymagać zmniejszenia.

Hafiz Adewuyi
źródło
3

Mam problem z dużymi obliczeniami w sp_foo, które zajmują dużo czasu, więc naprawiłem
ten mały kod

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;
    }
Nabeel Iqbal
źródło
3

Domyślny limit czasu to 15 sekund. Aby to zmienić, 0 jest nieograniczone, każda inna liczba to liczba sekund.

W kodzie

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

W twoim Web.Config: „Limit czasu poleceń = 0;” nie przekraczaj limitu czasu lub poniżej 1 godziny (3600 sekund)

  <add name="ConnectionString" connectionString="Data Source=ServerName;User ID=UserName;Password=Password;Command Timeout=3600;" providerName="System.Data.SqlClient" />
David C Fuchs
źródło
2
To są dwa różne limity czasu. Twoja pierwsza sugestia odnosi się do pytania. Twój drugi działałby tylko wtedy, gdyby dostawca połączenia go obsługiwał, czego nie robi SqlClient. W każdym razie przekroczenie limitu 0 nigdy nie jest dobrym pomysłem w produkcji. Zwykle domyślnym jest 30 sekund.
Suncat2000,
2

@SilverLight .. Jest to oczywiście problem z obiektem bazy danych. Może to być źle napisane zapytanie lub brakujące indeksy. Ale na razie nie sugeruję, aby zwiększyć limit czasu bez zbadania problemu z obiektami bazy danych

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

Umieść punkt przerwania w tym wierszu kodu, aby znaleźć nazwę procedury, a następnie zoptymalizuj procedurę, sprawdzając jej plan wykonania.

Nie mogę ci pomóc, dopóki nie opublikujesz szczegółowych informacji na temat procedury przechowywanej.

Amit Rai Sharma
źródło
Procedura składowana nie wykonuje żadnych wymyślnych czynności. Wygląda jednak na to, że tabela OnlineUsers jest blokowana podczas wykonywania procedury. Wypróbuj profiler SQL, aby zobaczyć, co się dzieje w Application_Start
Amit Rai Sharma
2

próbować

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

następnie odbuduj swój indeks

maksoud
źródło
8
Czy możesz wyjaśnić swoje rozwiązanie?
Hp93,
0

Upłynął limit czasu, ponieważ zapytanie SQL zajmuje więcej czasu niż ustawione we właściwości sqlCommand.CommandTimeout.

Oczywiście możesz zwiększyć CommandTimeout, aby rozwiązać ten problem, ale zanim to zrobisz, musisz zoptymalizować zapytanie, dodając indeks. Jeśli uruchomisz zapytanie w studiu zarządzania serwerem Sql, w tym w rzeczywistym planie wykonania, wówczas studio zarządzania serwerem Sql zasugeruje odpowiedni indeks. W większości przypadków możesz pozbyć się problemu z przekroczeniem limitu czasu, jeśli możesz zoptymalizować zapytanie.

Khabir
źródło
0

TLDR :

  1. Ponowne uruchomienie zarówno aplikacji, jak i serwerów DB to najszybsza poprawka, w której ilość danych, ustawienia sieciowe i kod nie uległy zmianie. Zawsze robimy to z reguły
  2. Może wskazywać na awarię dysku twardego wymagającą wymiany - sprawdź powiadomienia systemowe

Często napotykałem ten błąd z różnych powodów i miałem różne rozwiązania, w tym:

  1. refaktoryzacja mojego kodu do użycia SqlBulkCopy
  2. zwiększenie wartości Limit czasu, jak podano w różnych odpowiedziach, lub sprawdzenie przyczyn ( może nie być związanych z danymi) )
  3. Limit czasu połączenia (domyślnie 15s) - czas oczekiwania na ustanowienie połączenia z serwerem SQL przed zakończeniem - związany z TCP / PORT - może przejść przez listę kontrolną rozwiązywania problemów (bardzo przydatny artykuł MSDN)
  4. Limit czasu poleceń (domyślnie 30s) - czas oczekiwania na wykonanie zapytania - wykonanie zapytania / ruch sieciowy - również ma proces rozwiązywania problemów (kolejny bardzo przydatny artykuł MSDN)
  5. Ponowne uruchomienie serwera (serwerów) - zarówno aplikacji, jak i serwera DB (jeśli są osobne) - gdzie kod i dane nie uległy zmianie, środowisko musi się zmienić - Najpierw musisz to zrobić. Zwykle spowodowane przez poprawki (system operacyjny, .NET Framework lub łaty lub aktualizacje programu SQL Server). Szczególnie jeśli wyjątek przekroczenia limitu czasu pojawia się jak poniżej (nawet jeśli nie korzystamy z platformy Azure):
    • System.Data.Entity.Core.EntityException: Zgłoszono wyjątek, który prawdopodobnie jest spowodowany przejściową awarią. Jeśli łączysz się z bazą danych SQL Azure, rozważ użycie SqlAzureExecutionStrategy. ---> System.Data.Entity.Core.EntityCommandExecutionException: Wystąpił błąd podczas wykonywania definicji polecenia. Zobacz wewnętrzny wyjątek, aby uzyskać szczegółowe informacje. ---> System.Data.SqlClient.SqlException: Wystąpił błąd na poziomie transportu podczas odbierania wyników z serwera. (dostawca: Dostawca TCP, błąd: 0 - Upłynął limit czasu semaforów.) ---> System.ComponentModel.Win32Exception: Upłynął limit czasu semaforów
użytkownik919426
źródło
0

Upewnij się również, że po prostu nie masz oczekującej transakcji. :)

Robiłem kilka testów i rozpocząłem bezpieczną transakcję, ale nigdy jej nie zamknąłem. Chciałbym, żeby błąd był bardziej wyraźny, ale no cóż!

jeromej
źródło
0

Mieliśmy ciężkie czasy Timeout expired/max pool reached Sqlexception. Aby obejść ten problem i aby zapobiec ponownemu uruchomieniu serwera lub usługi, modyfikujemy MAX SERVER MEMORYzmienną w SQL Server (za pomocą SQL Managment Studio lub T-SQL):

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

To tymczasowo rozwiązuje problem, dopóki nie powtórzy się. W naszym przypadku podejrzewamy, że ma to związek z przeciekami połączeń na poziomie aplikacji.

Santiago rezygnuje z SO
źródło
0

Niedawno zaktualizowaliśmy do wersji NuGet SqlClient( Microsoft.Data.SqlClient), która zawiera błąd . Ten błąd został wprowadzony podczas cyklu 1.x i został już naprawiony. Poprawka będzie dostępna w wersji 2.0.0, która nie jest dostępna w momencie pisania tego tekstu. Podgląd jest dostępny.

Możesz sprawdzić szczegóły tutaj: https://github.com/dotnet/SqlClient/issues/262

Noel Widmer
źródło