Rozwiązywanie problemów z przejściowymi błędami połączenia w usługach SQL Database i SQL Managed Instance

Artykuł
07/04/2024

Dotyczy: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics

W tym artykule opisano sposób zapobiegania, rozwiązywania problemów, diagnozowania i eliminowania błędów połączenia oraz błędów przejściowych napotykanych przez aplikację kliencą podczas interakcji z usługą Azure SQL Database, usługą Azure SQL Managed Instance i usługą Azure Synapse Analytics. Dowiedz się, jak skonfigurować logikę ponawiania prób, skompilować parametry połączenia i dostosować inne ustawienia połączenia.

Błędy przejściowe (błędy przejściowe)

Błąd przejściowy, znany również jako błąd przejściowy, ma podstawową przyczynę, która wkrótce się rozwiąże. Czasami błędy przejściowe występują, gdy system Azure szybko przenosi zasoby sprzętowe, aby lepiej zrównoważyć rozłożenie różnych obciążeń. Większość z tych zdarzeń ponownej konfiguracji kończy się w mniej niż 60 sekund. W tym okresie ponownej konfiguracji mogą wystąpić problemy z nawiązaniem połączenia z bazą danych w usłudze SQL Database. Aplikacje łączące się z bazą danych powinny być tworzone w taki sposób, aby spodziewały się tych przejściowych błędów. Aby je obsłużyć, zaimplementuj logikę ponawiania prób w kodzie aplikacji, zamiast pokazywać je użytkownikom jako błędy aplikacji.

Jeśli program kliencki używa ADO.NET, program zostanie poinformowany o błędzie przejściowym przez zgłoszenie wyjątku SqlException.

Połączenie a polecenie

Spróbuj ponownie nawiązać połączenie z usługą SQL Database i wystąpieniem zarządzanym SQL lub ustanowić je ponownie, w zależności od następujących:

Podczas próby połączenia występuje błąd przejściowy

Po kilku sekundach spróbuj ponownie nawiązać połączenie.

Błąd przejściowy występuje podczas wykonywania polecenia zapytania usługi SQL Database i wystąpienia zarządzanego SQL

Nie należy natychmiast ponowić próby wykonania polecenia. Zamiast tego, po opóźnieniu, świeżo ustanów połączenie. Następnie spróbuj ponownie wykonać polecenie.

Logika ponawiania próby w przypadku błędów przejściowych

Programy klienckie, które czasami napotykają błąd przejściowy, są bardziej niezawodne, gdy zawierają logikę ponawiania prób. Gdy program komunikuje się z bazą danych w usłudze SQL Database za pośrednictwem oprogramowania pośredniczącego innej firmy, zapytaj dostawcę, czy oprogramowanie pośredniczące zawiera logikę ponawiania prób dla błędów przejściowych.

Zasady dotyczące ponawiania próby

Jeśli błąd jest przejściowy, spróbuj ponownie otworzyć połączenie.
Nie należy bezpośrednio ponawiać próby wykonania instrukcji usługi SQL Database lub wystąpienia SELECT zarządzanego SQL, która nie powiodła się z powodu błędu przejściowego. Zamiast tego ustanów nowe połączenie, a następnie ponów próbę .SELECT
Jeśli instrukcja SQL Database lub SQL Managed Instance UPDATE kończy się niepowodzeniem z powodu błędu przejściowego, ustal nowe połączenie przed ponowieniu próby aktualizacji. Logika ponawiania musi zapewnić zakończenie całej transakcji bazy danych lub wycofanie całej transakcji.

Inne zagadnienia dotyczące ponawiania próby

Program wsadowy, który automatycznie rozpoczyna się po godzinach pracy i kończy się przed godzinami porannymi, może sobie pozwolić na to, aby być bardzo cierpliwym z długimi interwałami czasu między próbami ponawiania próby.
Program interfejsu użytkownika powinien uwzględniać tendencję człowieka do rezygnacji po zbyt długim oczekiwaniu. Rozwiązanie nie może ponawiać próby co kilka sekund, ponieważ te zasady mogą zalać system żądaniami.

Zwiększanie interwału między ponawianiami

Zalecamy poczekanie 5 sekund przed pierwszą ponowną próbą. Ponawianie próby po opóźnieniu krótszym niż 5 sekund może przeciążyć usługę w chmurze. Dla każdego kolejnego ponawiania opóźnienie powinno rosnąć wykładniczo, maksymalnie do 60 sekund.

Aby zapoznać się z omówieniem okresu blokowania dla klientów korzystających z ADO.NET, zobacz Buforowanie połączeń (ADO.NET).

Możesz również ustawić maksymalną liczbę ponownych prób przed automatycznym kończeniem programu.

Przykłady kodu z logiką ponawiania prób

Przykłady kodu z logiką ponawiania prób są dostępne pod adresem:

Testowanie logiki ponawiania prób

Aby przetestować logikę ponawiania prób, musisz symulować lub spowodować błąd, który może zostać poprawiony, gdy program jest nadal uruchomiony.

Testowanie przez odłączenie od sieci

Jednym ze sposobów testowania logiki ponawiania jest odłączenie komputera klienckiego od sieci podczas działania programu. Błąd:

SqlException.Number = 11001
Komunikat: "Taki host nie jest znany"

W ramach pierwszej próby ponawiania można ponownie połączyć komputer kliencki z siecią, a następnie spróbować nawiązać połączenie.

Aby ten test był praktyczny, odłącz komputer z sieci przed rozpoczęciem programu. Następnie program rozpoznaje parametr środowiska uruchomieniowego, który powoduje, że program ma:

Tymczasowo dodaj 11001 do listy błędów, które należy wziąć pod uwagę jako przejściowe.
Spróbuj nawiązać pierwsze połączenie, jak zwykle.
Po przechwyceniu błędu usuń element 11001 z listy.
Wyświetl komunikat informujący użytkownika o podłączeniu komputera do sieci.
Wstrzymaj dalsze wykonywanie przy użyciu metody Console.ReadLine lub okna dialogowego z przyciskiem OK. Użytkownik naciska Enter po podłączeniu komputera do sieci.
Spróbuj ponownie nawiązać połączenie, spodziewając się powodzenia.

Przetestuj, błędnie wpisując nazwę użytkownika podczas nawiązywania połączenia

Program może celowo przegapić nazwę użytkownika przed pierwszą próbą połączenia. Błąd:

SqlException.Number = 18456
Komunikat: "Logowanie użytkownika "WRONG_MyUserName" nie powiodło się".

W ramach pierwszej próby ponawiania próby program może poprawić błędną pisownię, a następnie spróbować nawiązać połączenie.

Aby ten test był praktyczny, program rozpoznaje parametr środowiska uruchomieniowego, który powoduje, że program ma:

Tymczasowo dodaj 18456 do listy błędów, które należy wziąć pod uwagę jako przejściowe.
Celowo dodaj "WRONG_" do nazwy użytkownika.
Po przechwyceniu błędu usuń 18456 z listy.
Usuń element "WRONG_" z nazwy użytkownika.
Spróbuj ponownie nawiązać połączenie, spodziewając się powodzenia.

Parametry programu SqlConnection platformy .NET na potrzeby ponawiania próby połączenia

Jeśli program kliencki łączy się z bazą danych w usłudze Azure SQL Database przy użyciu klasy .NET Framework System.Data.SqlClient.SqlConnection, użyj programu .NET 4.6.1 lub nowszej wersji (lub platformy .NET Core), aby można było użyć funkcji ponawiania połączenia. Aby uzyskać więcej informacji na temat tej funkcji, zobacz SqlConnection.ConnectionString, właściwość.

Podczas tworzenia parametry połączenia dla obiektu SqlConnection należy koordynować wartości między następującymi parametrami:

ConnectRetryCount: wartość domyślna to 1. Zakres wynosi od 0 do 255.
ConnectRetryInterval: wartość domyślna to 10 sekund. Zakres wynosi od 1 do 60.
Limit czasu połączenia: wartość domyślna to 15 sekund. Zakres wynosi od 0 do 2147483647.
Limit czasu polecenia: wartość domyślna to 30 sekund. Zakres wynosi od 0 do 2147483647.

Ustawienia ponawiania połączenia (ConnectRetryCount i ConnectRetryInterval) mają zastosowanie do odporności połączenia. Odporność połączenia obejmuje następujące różne typy:

Odporność otwierania połączenia odnosi się do początkowej metody SqlConnection.Open lub OpenAsync(). Pierwsza próba połączenia jest liowana jako próba zero. ConnectRetryCount ma zastosowanie do kolejnych ponownych prób. W związku z tym, jeśli zero połączenia zakończy się niepowodzeniem (może to nie nastąpić natychmiast), program ConnectRetryInterval zostanie zastosowany najpierw, a następnie kolejne próby ConnectRetryCount (i ConnectRetryInterval). Aby skorzystać ze wszystkich ponownych prób, właściwość Limit czasu połączenia musi zapewnić czas dla wszystkich prób.
Odporność bezczynności połączenia odnosi się do automatycznego wykrywania i ponownego łączenia istniejących bezczynnych połączeń, które zostały przerwane. Pierwsza próba ponownego nawiązania połączenia bezczynnego jest liczone jako pierwsza próba ponawiania próby. Aby skorzystać ze wszystkich ponownych prób, limit czasu polecenia musi zapewnić czas dla wszystkich prób.

Przykład: Przyjmij następujące wartości parametrów ConnectRetryCount i ConnectRetryInterval :

ConnectRetryCount: 3 ConnectRetryInterval: 10 sekund

Zobacz, jak te wartości są używane w następujących scenariuszach:

Scenariusz: Nowe połączenie

4:10:00 — Connection.Open() — zero prób

4:10:01 — Wykryto błąd połączenia

4:10:11 — Ponów próbę 1 —> pierwsze ponowienie próby następuje po połączeniuRetryInterval

4:10:21 — Ponów próbę 2

4:10:31 — Ponów próbę 3

W tym scenariuszu wybrane wartości powinny spełniać następujący warunek:
Connection Timeout > = ConnectRetryCount * ConnectionRetryInterval

Jeśli na przykład liczba wynosi 3, a interwał wynosi 10 sekund, limit czasu wynoszący tylko 29 sekund nie zapewnia wystarczającej ilości czasu na trzecie i ostatnie ponowienie próby w celu nawiązania połączenia:

29 < 3 * 10

Scenariusz: bezczynne połączenie

ConnectRetryCount: 3 ConnectRetryInterval: 10 sekund

4:10:00 — wykryto przerwane połączenie podczas wykonywania polecenia

4:10:00 — Ponów próbę 1 —->Pierwsza ponowna próba następuje natychmiast

4:10:10 — Ponów próbę 2

4:10:20 — Ponów próbę 3

To nie jest początkowe połączenie. W związku z tym limit czasu połączenia nie ma zastosowania. Jednak ponieważ odzyskiwanie połączenia odbywa się podczas wykonywania polecenia, ustawienie Limit czasu polecenia ma zastosowanie. Wartość domyślna limitu czasu polecenia to 30 sekund. Mimo że odzyskiwanie połączenia jest szybkie w typowych okolicznościach, sporadycznie awaria może spowodować, że odzyskiwanie zajmie trochę czasu wykonywania polecenia.

W tym scenariuszu, jeśli chcesz w pełni skorzystać z ponownych prób odzyskiwania bezczynności połączenia, wybrane wartości powinny spełniać następujący warunek:
Command Timeout > (ConnectRetryCount - 1) * ConnectionRetryInterval

Jeśli na przykład liczba wynosi 3, a interwał wynosi 10 sekund, wartość limitu czasu polecenia niższa niż 20 sekund nie da wystarczającej ilości czasu na trzecie i ostatnie ponowienie próby nawiązania połączenia: (3– 1) * 10 = 20'

Należy również wziąć pod uwagę, że samo polecenie wymaga czasu do wykonania po odzyskaniu połączenia.

Uwaga

Wartości czasu trwania podane w tych scenariuszach dotyczą tylko pokazu. Rzeczywiste czasy wykrywania w obu scenariuszach zależą od podstawowej infrastruktury.

Połączenie a polecenie

Parametry ConnectRetryCount i ConnectRetryInterval pozwalają obiektowi SqlConnection ponowić próbę wykonania operacji łączenia bez konieczności zwracania lub przejmowania programu, takiego jak zwracanie kontrolki do programu. Ponawianie prób może wystąpić w następujących sytuacjach:

Wywołanie metody SqlConnection.Open
Wywołanie metody SqlConnection.Execute

Istnieje subtelność. Jeśli podczas wykonywania zapytania wystąpi błąd przejściowy, obiekt SqlConnection nie ponowi próby wykonania operacji łączenia. Z pewnością nie ponawia próby zapytania. Jednak program SqlConnection bardzo szybko sprawdza połączenie przed wysłaniem zapytania w celu wykonania. Jeśli szybkie sprawdzenie wykryje problem z połączeniem, program SqlConnection ponawia próbę wykonania operacji łączenia. Jeśli ponowienie próby powiedzie się, zapytanie zostanie wysłane do wykonania.

Czy połączenie polecenia ConnectRetryCount z logiką ponawiania prób aplikacji

Załóżmy, że aplikacja ma niezawodną niestandardową logikę ponawiania prób. Może ona ponowić próbę wykonania operacji łączenia cztery razy. W przypadku dodania parametrów ConnectRetryInterval i ConnectRetryCount =3 do parametry połączenia liczba ponownych prób zwiększy się do 4 * 3 = 12 ponownych prób. Możesz nie zamierzać tak dużej liczby ponownych prób.

Połączenia z bazą danych w usłudze SQL Database

Połączenie: Parametry połączenia

Parametry połączenia, które są niezbędne do nawiązania połączenia z bazą danych, różni się nieco od ciągu używanego do nawiązywania połączenia z programem SQL Server. Możesz skopiować parametry połączenia dla bazy danych z witryny Azure Portal.

Uzyskiwanie parametry połączenia z witryny Azure Portal

Użyj witryny Azure Portal, aby uzyskać parametry połączenia, które są niezbędne dla programu klienckiego do interakcji z usługą Azure SQL Database.

Wybierz pozycję Wszystkie usługi>Bazy danych SQL.
Wprowadź nazwę bazy danych w polu tekstowym filtru w lewym górnym rogu okienka Bazy danych SQL.
Wybierz wiersz dla bazy danych.
Po pojawieniu się okienka dla bazy danych dla wygody wizualnej wybierz przyciski Minimalizuj , aby zwinąć bloki używane do przeglądania i filtrowania bazy danych.
W okienku bazy danych wybierz pozycję Pokaż parametry połączenia bazy danych.
Skopiuj odpowiednie parametry połączenia. tj. Jeśli zamierzasz użyć biblioteki połączeń ADO.NET, skopiuj odpowiednie parametry z karty ADO.NET .
Edytuj parametry połączenia zgodnie z potrzebami. tj. Wstaw hasło do parametry połączenia lub usuń ciąg "@<servername>" z nazwy użytkownika, jeśli nazwa użytkownika lub nazwa serwera jest za długa.
W jednym formacie lub innym wklej informacje parametry połączenia do kodu programu klienckiego.

Aby uzyskać więcej informacji, zobacz Parametry połączenia i pliki konfiguracji.

Połączenie: adres IP

Należy skonfigurować usługę SQL Database tak, aby akceptowała komunikację z adresu IP komputera, który hostuje program kliencki. Aby skonfigurować tę konfigurację, edytuj ustawienia zapory za pośrednictwem witryny Azure Portal.

Jeśli zapomnisz skonfigurować adres IP, program zakończy się niepowodzeniem z przydatnym komunikatem o błędzie informującym o wymaganym adresie IP.

Zaloguj się w witrynie Azure Portal.
Na liście po lewej stronie wybierz pozycję Wszystkie usługi.
Przewiń i wybierz pozycję Serwery SQL.
W polu tekstowym filtru zacznij wpisywać nazwę serwera. Zostanie wyświetlony wiersz.
Wybierz wiersz dla serwera. Zostanie wyświetlone okienko serwera.
W okienku serwera wybierz pozycję Ustawienia.
Wybierz pozycję Zapora.
Wybierz pozycję Dodaj adres IP klienta. Wpisz nazwę nowej reguły w pierwszym polu tekstowym.
Wpisz wartości niskich i wysokich adresów IP dla zakresu, który chcesz włączyć.
- Może to być przydatne, aby mieć niską wartość końcową z wartością .0 i wysoką wartość końcową z .255.
Wybierz pozycję Zapisz.

Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień zapory w usłudze SQL Database.

Połączenie: porty

Zazwyczaj należy upewnić się, że tylko port 1433 jest otwarty dla komunikacji wychodzącej na komputerze hostującym program kliencki.

Na przykład gdy program kliencki jest hostowany na komputerze z systemem Windows, możesz użyć Zapory systemu Windows na hoście, aby otworzyć port 1433.

Otwórz Panel sterowania.
Wybierz pozycję Wszystkie Panel sterowania elementy>Zaawansowane ustawienia>Zapory systemu>Windows Akcje>reguł>ruchu wychodzącego Nowa reguła.

Jeśli program kliencki jest hostowany na maszynie wirtualnej platformy Azure, przeczytaj porty przekraczające 1433 dla ADO.NET 4.5 i usługi SQL Database.

Aby uzyskać podstawowe informacje na temat konfiguracji portów i adresów IP w bazie danych, zobacz Zapora usługi Azure SQL Database.

Połączenie: ADO.NET 4.6.2 lub nowszy

Jeśli program używa klas ADO.NET, takich jak System.Data.SqlClient.SqlConnection do nawiązywania połączenia z usługą SQL Database, zalecamy użycie programu .NET Framework w wersji 4.6.2 lub nowszej.

Począwszy od ADO.NET 4.6.2

Próba otwarcia połączenia zostanie natychmiast ponowiona dla usługi Azure SQL, co zwiększa wydajność aplikacji z obsługą chmury.

Począwszy od ADO.NET 4.6.1

W przypadku usługi SQL Database niezawodność jest ulepszana po otwarciu połączenia przy użyciu metody SqlConnection.Open . Metoda Open obejmuje teraz mechanizmy ponawiania prób w odpowiedzi na błędy przejściowe w przypadku niektórych błędów w okresie przekroczenia limitu czasu połączenia.
Obsługiwane jest buforowanie połączeń, co obejmuje wydajną weryfikację działania obiektu połączenia, który daje program.

Jeśli używasz obiektu połączenia z puli połączeń, zalecamy tymczasowe zamknięcie połączenia przez program, gdy nie jest natychmiast używany. Ponowne otwarcie połączenia nie jest kosztowne, ale jest konieczne utworzenie nowego połączenia.

Jeśli używasz ADO.NET 4.0 lub starszej wersji, zalecamy uaktualnienie do najnowszej wersji ADO.NET. Od sierpnia 2018 r. możesz pobrać ADO.NET 4.6.2.

Diagnostyka

Diagnostyka: testowanie, czy narzędzia mogą się łączyć

Jeśli program nie może nawiązać połączenia z bazą danych w usłudze SQL Database, jedną z opcji diagnostycznych jest próba nawiązania połączenia z programem narzędziowym. W idealnym przypadku narzędzie łączy się przy użyciu tej samej biblioteki, z którą korzysta program.

Na dowolnym komputerze z systemem Windows możesz wypróbować następujące narzędzia:

SQL Server Management Studio (ssms.exe), który łączy się przy użyciu ADO.NET
sqlcmd.exe, który łączy się za pomocą ODBC

Po nawiązaniu połączenia z programem sprawdź, czy działa krótkie zapytanie SQL SELECT.

Diagnostyka: Sprawdzanie otwartych portów

Jeśli podejrzewasz, że próby nawiązania połączenia kończą się niepowodzeniem z powodu problemów z portem, możesz uruchomić narzędzie na komputerze, które raportuje konfiguracje portów.

W systemie Linux przydatne mogą być następujące narzędzia:

netstat -nap
nmap -sS -O 127.0.0.1: Zmień wartość przykładu na twój adres IP.

W systemie Windows przydatne może być narzędzie PortQry.exe . Oto przykładowe wykonanie, które wykonało zapytanie dotyczące sytuacji portu w bazie danych w usłudze SQL Database i zostało uruchomione na komputerze przenośnym:

[C:\Users\johndoe\]
>> portqry.exe -n johndoesvr9.database.windows.net -p tcp -e 1433

Querying target system called: johndoesvr9.database.windows.net

Attempting to resolve name to IP address...
Name resolved to 23.100.117.95

querying...
TCP port 1433 (ms-sql-s service): LISTENING

[C:\Users\johndoe\]
>>

Diagnostyka: rejestrowanie błędów

Sporadyczne problemy są czasami najlepiej diagnozowane przez wykrywanie ogólnego wzorca w ciągu dni lub tygodni.

Klient może pomóc w diagnostyce, rejestrując wszystkie napotkane błędy. Może być możliwe skorelowanie wpisów dziennika z danymi o błędach, które usługa SQL Database rejestruje wewnętrznie.

Biblioteka 6 przedsiębiorstwa (EntLib60) oferuje klasy zarządzane platformy .NET, które ułatwiają rejestrowanie. Aby uzyskać więcej informacji, zobacz 5 — Tak łatwo, jak spada dziennik: Użyj bloku aplikacji rejestrowania.

Diagnostyka: Sprawdzanie dzienników systemu pod kątem błędów

Poniżej przedstawiono niektóre instrukcje Języka Transact-SQL SELECT, które wysyłają zapytania o dzienniki błędów i inne informacje.

Kwerenda dziennika	opis
`SELECT e.*` `FROM sys.event_log AS e` `WHERE e.database_name = 'myDbName'` `AND e.event_category = 'connectivity'` `AND 2 >= DateDiff` `(hour, e.end_time, GetUtcDate())` `ORDER BY e.event_category,` `e.event_type, e.end_time;`	Widok sys.event_log zawiera informacje o poszczególnych zdarzeniach, w tym niektóre, które mogą powodować błędy przejściowe lub błędy łączności. W idealnym przypadku można skorelować wartości start_time lub end_time z informacjami o tym, kiedy program kliencki napotkał problemy. Aby uruchomić to zapytanie, musisz nawiązać połączenie z bazą danych master .
`SELECT c.*` `FROM sys.database_connection_stats AS c` `WHERE c.database_name = 'myDbName'` `AND 24 >= DateDiff` `(hour, c.end_time, GetUtcDate())` `ORDER BY c.end_time;`	Widok sys.database_connection_stats oferuje zagregowane liczby typów zdarzeń na potrzeby dodatkowej diagnostyki. Aby uruchomić to zapytanie, musisz nawiązać połączenie z bazą danych master .

Diagnostyka: wyszukiwanie zdarzeń problemów w dzienniku usługi SQL Database

Wpisy dotyczące zdarzeń problemów można wyszukać w dzienniku usługi SQL Database. Spróbuj wykonać następującą instrukcję Transact-SQL SELECT w bazie danych master :

SELECT
   object_name
  ,CAST(f.event_data as XML).value
      ('(/event/@timestamp)[1]', 'datetime2')                      AS [timestamp]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="error"]/value)[1]', 'int')             AS [error]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="state"]/value)[1]', 'int')             AS [state]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="is_success"]/value)[1]', 'bit')        AS [is_success]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="database_name"]/value)[1]', 'sysname') AS [database_name]
FROM
  sys.fn_xe_telemetry_blob_target_read_file('el', null, null, null) AS f
WHERE
  object_name != 'login_event'  -- Login events are numerous.
  and
  '2015-06-21' < CAST(f.event_data as XML).value
        ('(/event/@timestamp)[1]', 'datetime2')
ORDER BY
  [timestamp] DESC
;

Kilka zwracanych wierszy z sys.fn_xe_telemetry_blob_target_read_file

W poniższym przykładzie pokazano, jak może wyglądać zwrócony wiersz. Wyświetlane wartości null często nie mają wartości null w innych wierszach.

object_name                   timestamp                    error  state  is_success  database_name

database_xml_deadlock_report  2015-10-16 20:28:01.0090000  NULL   NULL   NULL        AdventureWorks

Biblioteka przedsiębiorstwa 6

Biblioteka 6 przedsiębiorstwa (EntLib60) to struktura klas platformy .NET, która ułatwia implementowanie niezawodnych klientów usług w chmurze, z których jedna to SQL Database. Aby zlokalizować tematy przeznaczone dla każdego obszaru, w którym może pomóc biblioteka EntLib60, zobacz Biblioteka przedsiębiorstwa 6.

Logika ponawiania prób do obsługi błędów przejściowych to jeden obszar, w którym może pomóc EntLib60. Aby uzyskać więcej informacji, zobacz 4 — Wytrwałość, wpis tajny wszystkich triumfów: Używanie przejściowego bloku aplikacji obsługi błędów.

Uwaga

Kod źródłowy biblioteki EntLib60 jest dostępny do publicznego pobrania z Centrum pobierania. Firma Microsoft nie planuje wprowadzania dalszych aktualizacji funkcji ani aktualizacji konserwacji biblioteki EntLib.

Klasy EntLib60 dla błędów przejściowych i ponawiania próby

Poniższe klasy EntLib60 są szczególnie przydatne w przypadku logiki ponawiania prób. Wszystkie te klasy znajdują się w przestrzeni nazw Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling lub w tej przestrzeni nazw.

W przestrzeni nazw Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling:

RetryPolicy, klasa
- ExecuteAction, metoda
ExponentialBackoff, klasa
SqlDatabaseTransientErrorDetectionStrategy , klasa
ReliableSqlConnection, klasa
- ExecuteCommand , metoda

W przestrzeni nazw Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.TestSupport:

AlwaysTransientErrorDetectionStrategy , klasa
NeverTransientErrorDetectionStrategy , klasa

Oto kilka linków do informacji o EntLib60:

Pobierz bezpłatną książkę: Przewodnik dewelopera po bibliotece Microsoft Enterprise Library, 2. edycji.
Najlepsze rozwiązania: Ogólne wskazówki dotyczące ponawiania prób zawierają doskonałą szczegółową dyskusję na temat logiki ponawiania prób.
Pobieranie nuGet: Biblioteka przedsiębiorstwa — przejściowy blok aplikacji do obsługi błędów 6.0.

EntLib60: blok rejestrowania

Blok rejestrowania jest wysoce elastycznym i konfigurowalnym rozwiązaniem, którego można użyć do:
- Twórz i przechowuj komunikaty dzienników w wielu różnych lokalizacjach.
- Kategoryzuj i filtruj komunikaty.
- Zbierz informacje kontekstowe przydatne do debugowania i śledzenia, a także inspekcji i ogólnych wymagań dotyczących rejestrowania.
Blok rejestrowania stanowi abstrakcję funkcji rejestrowania z miejsca docelowego dziennika, tak aby kod aplikacji był spójny, niezależnie od lokalizacji i typu docelowego magazynu rejestrowania.

Aby uzyskać więcej informacji, zobacz 5 — Tak łatwo, jak spada dziennik: Użyj bloku aplikacji rejestrowania.

Kod źródłowy metody EntLib60 IsTransient

Następnie z klasy SqlDatabaseTransientErrorDetectionStrategy jest kodem źródłowym języka C# dla metody IsTransient . Kod źródłowy wyjaśnia, które błędy zostały uznane za przejściowe i godne ponawiania próby.

public bool IsTransient(Exception ex)
{
  if (ex != null)
  {
    SqlException sqlException;
    if ((sqlException = ex as SqlException) != null)
    {
      // Enumerate through all errors found in the exception.
      foreach (SqlError err in sqlException.Errors)
      {
        switch (err.Number)
        {
            // SQL Error Code: 40501
            // The service is currently busy. Retry the request after 10 seconds.
            // Code: (reason code to be decoded).
          case ThrottlingCondition.ThrottlingErrorNumber:
            // Decode the reason code from the error message to
            // determine the grounds for throttling.
            var condition = ThrottlingCondition.FromError(err);

            // Attach the decoded values as additional attributes to
            // the original SQL exception.
            sqlException.Data[condition.ThrottlingMode.GetType().Name] =
              condition.ThrottlingMode.ToString();
            sqlException.Data[condition.GetType().Name] = condition;

            return true;

          case 10928:
          case 10929:
          case 10053:
          case 10054:
          case 10060:
          case 40197:
          case 40540:
          case 40613:
          case 40143:
          case 233:
          case 64:
            // DBNETLIB Error Code: 20
            // The instance of SQL Server you attempted to connect to
            // does not support encryption.
          case (int)ProcessNetLibErrorCode.EncryptionNotSupported:
            return true;
        }
      }
    }
    else if (ex is TimeoutException)
    {
      return true;
    }
    else
    {
      EntityException entityException;
      if ((entityException = ex as EntityException) != null)
      {
        return this.IsTransient(entityException.InnerException);
      }
    }
  }

  return false;
}

Udostępnij za pośrednictwem

Rozwiązywanie problemów z przejściowymi błędami połączenia w usługach SQL Database i SQL Managed Instance

Błędy przejściowe (błędy przejściowe)

Połączenie a polecenie

Logika ponawiania próby w przypadku błędów przejściowych

Zasady dotyczące ponawiania próby

Inne zagadnienia dotyczące ponawiania próby

Zwiększanie interwału między ponawianiami

Przykłady kodu z logiką ponawiania prób

Testowanie logiki ponawiania prób

Testowanie przez odłączenie od sieci

Przetestuj, błędnie wpisując nazwę użytkownika podczas nawiązywania połączenia

Parametry programu SqlConnection platformy .NET na potrzeby ponawiania próby połączenia

Połączenie a polecenie

Czy połączenie polecenia ConnectRetryCount z logiką ponawiania prób aplikacji

Połączenia z bazą danych w usłudze SQL Database

Połączenie: Parametry połączenia

Uzyskiwanie parametry połączenia z witryny Azure Portal

Połączenie: adres IP

Połączenie: porty

Połączenie: ADO.NET 4.6.2 lub nowszy

Począwszy od ADO.NET 4.6.2

Począwszy od ADO.NET 4.6.1

Diagnostyka

Diagnostyka: testowanie, czy narzędzia mogą się łączyć

Diagnostyka: Sprawdzanie otwartych portów

Diagnostyka: rejestrowanie błędów

Diagnostyka: Sprawdzanie dzienników systemu pod kątem błędów

Diagnostyka: wyszukiwanie zdarzeń problemów w dzienniku usługi SQL Database

Kilka zwracanych wierszy z sys.fn_xe_telemetry_blob_target_read_file

Biblioteka przedsiębiorstwa 6

Klasy EntLib60 dla błędów przejściowych i ponawiania próby

EntLib60: blok rejestrowania

Kod źródłowy metody EntLib60 IsTransient

Następne kroki

Opinia

Dodatkowe zasoby