Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy: 
.NET Framework .NET Standard
Konfigurowalna logika ponawiania prób (CRL) umożliwia składnikowi Microsoft.Data.SqlClient ponawianie wybranych operacji SqlConnection i SqlCommand po wystąpieniu przejściowych błędów. Wybierasz, które błędy kwalifikują się, ile prób wykonać, jak opóźnienia rosną między próbami i które polecenia można powtarzać.
CRL jest domyślnie wyłączone. Umożliwia się to, przypisując dostawcę do połączenia, polecenia lub obu. Obaj dostawcy są niezależni: przypisanie dostawcy do połączenia nie powoduje przypisania go do poleceń utworzonych na podstawie tego połączenia.
Uwaga / Notatka
CRL jest dostępny w Microsoft. Data.SqlClient 3.0 i nowsze. Wartość domyślna to SqlConfigurableRetryFactory.CreateNoneRetryProvider, co oznacza, że próba nie jest ponawiana.
Ponowienia prób CRL
| Scenario | Przypisz dostawcę do | Typowe awarie |
|---|---|---|
| Otwórz połączenie | SqlConnection.RetryLogicProvider | Przełączanie awaryjne, ograniczanie przepustowości, krótka niedostępność bazy danych oraz błędy transportu podczas nawiązywania połączenia. |
| Wykonywanie polecenia | SqlCommand.RetryLogicProvider | Wybrane błędy wyciągów, które można bezpiecznie powtórzyć poza transakcją. |
W przypadku wspólnego katalogu błędów połączenia, dla których można ponowić próbę w usługach SQL Server, Azure SQL Database, Azure SQL Managed Instance, bazie danych SQL w Microsoft Fabric oraz dedykowanych pulach SQL w Azure Synapse Analytics, zobacz temat Built-in transient error list.
Wybierz ścieżkę konfiguracji
| Zadanie | Artykuł |
|---|---|
| Utwórz i przypisz dostawcę w kodzie | Konfiguruj logikę retry w SqlClient |
| Porównaj dostawców stałych, inkrementalnych, wykładniczych i bez powtórek | Wbudowani dostawcy logiki ponawiania w SqlClient |
| Ustaw domyślne wartości dla całej aplikacji w pliku konfiguracyjnym | Konfiguruj logikę ponownych prób w SqlClient za pomocą pliku konfiguracyjnego |
| Zaimplementuj niestandardowy przedział, predykat błędu lub dostawcę | Stwórz niestandardowego dostawcy powtórek dla SqlClient |
Projektuj politykę bezpiecznego ponownego próbowania
- Powtórz tylko niepowodzenia, które prawdopodobnie zostaną usunięte bez zmiany danych aplikacji.
- Ogranicz ponowne próby zarówno liczbą prób, jak i maksymalnym opóźnieniem. Nieograniczona pętla powtórek może przekształcić awarię w długotrwałe obciążenie.
- Traktuj
NumberOfTriesjako łączną liczbę prób, wliczając początkową operację. - Dodaj jitter, żeby wielu klientów nie próbowało ponownie jednocześnie. Wbudowani dostawcy automatycznie dodają jitter.
- Ponów całą transakcję, a nie jedną instrukcję w jej obrębie. Wbudowani dostawcy poleceń nie ponawiają poleceń dla połączenia z aktywną transakcją.
- Ogranicz powtórki poleceń do operacji idempotentnych lub do operacji chronionych mechanizmem idempotencji na poziomie aplikacji.
- Zapisz zdarzenie Retrying , aby odróżnić odzyskane awarie przejściowe od utrzymujących się incydentów.
Ogólne wskazówki dotyczące architektury można znaleźć w wzorcu Retry. Aby uzyskać wskazówki dotyczące błędów Azure SQL, zobacz błędy przejściowe.
Limity czasu po stronie klienta i bezserwerowe wznawianie
CRL ponawia próby tylko w przypadku błędów, które sterownik faktycznie otrzymuje. Limit czasu po stronie klienta objawia się jako błąd -2, który nie znajduje się na wbudowanej liście błędów przejściowych, więc wbudowani dostawcy nie ponawiają operacji Open() ani polecenia, dla którego upłynął limit czasu po stronie klienta.
ConnectTimeout i CommandTimeout muszą być wystarczająco długie, aby same objąć cały proces.
Ten warunek ma największe znaczenie dla poziomu obliczeń Serverless dla Azure SQL Database z włączonym automatycznym pauzowaniem. Automatycznie wstrzymana baza danych zostaje wznowiona po pierwszym Open(), a wznowienie może potrwać od 30 do 60 sekund lub dłużej. Podnieś ConnectTimeout do co najmniej 60 sekund, gdy cel może automatycznie pauzować. Logika powtórek obsługuje następnie pozostałe przejściowe błędy (na przykład 40613, 40197, i 40501), podczas gdy baza danych jest uruchamiana.