Dela via


Felsöka tillfälliga anslutningsfel i SQL Database och SQL Managed Instance

Gäller för:Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics

Den här artikeln beskriver hur du förhindrar, felsöker, diagnostiserar och åtgärdar anslutningsfel och tillfälliga fel som klientprogrammet stöter på när det interagerar med Azure SQL Database, Azure SQL Managed Instance och Azure Synapse Analytics. Lär dig hur du konfigurerar logik för omprövning, skapar anslutningssträng och justerar andra anslutningsinställningar.

Tillfälliga fel (tillfälliga fel)

Ett tillfälligt fel, även kallat ett tillfälligt fel, har en underliggande orsak som snart löser sig själv. Ibland kan tillfälliga fel bero på att Azure-systemet snabbt flyttar maskinvaruresurser för bättre belastningsutjämning av olika arbetsbelastningar. De flesta av dessa omkonfigurationshändelser slutförs på under 60 sekunder. Under den här omkonfigurationstiden kan det uppstå problem med att ansluta till databasen i SQL Database. Program som ansluts till databasen bör anpassas för att klara av dessa tillfälliga fel. För att hantera dem implementerar du återförsökslogik i koden i stället för att användarna ser dem som programfel.

Om klientprogrammet använder ADO.NET får ditt program information om det tillfälliga felet vid sqlexception-utkastet.

Anslut ion kontra kommando

Försök igen med SQL Database- och SQL Managed Instance-anslutningen eller upprätta den igen, beroende på följande:

  • Ett tillfälligt fel inträffar under ett anslutnings försök

Försök ansluta igen efter en fördröjning på flera sekunder.

  • Ett tillfälligt fel inträffar under ett SQL Database- och SQL Managed Instance-frågekommando

Försök inte omedelbart med kommandot igen. Efter en fördröjning upprättar du i stället anslutningen på nytt. Försök sedan med kommandot igen.

Logik för omprövning av tillfälliga fel

Klientprogram som ibland stöter på ett tillfälligt fel är mer robusta när de innehåller återförsökslogik. När programmet kommunicerar med databasen i SQL Database via mellanprogram från tredje part frågar du leverantören om mellanprogrammet innehåller omprövningslogik för tillfälliga fel.

Principer för återförsök

  • Om felet är tillfälligt försöker du öppna en anslutning igen.
  • Försök inte direkt med en SQL Database- eller SQL Managed Instance-instruktion SELECT som misslyckades med ett tillfälligt fel. Upprätta i stället en ny anslutning och försök SELECTsedan igen .
  • När en SQL Database- eller SQL Managed Instance-instruktion UPDATE misslyckas med ett tillfälligt fel upprättar du en ny anslutning innan du försöker uppdatera igen. Logiken för återförsök måste se till att antingen hela databastransaktionen har slutförts eller att hela transaktionen återställs.

Andra överväganden för återförsök

  • Ett batchprogram som startar automatiskt efter arbetstid och avslutas före morgonen har råd att ha mycket tålamod med långa tidsintervall mellan försöken.
  • Ett användargränssnittsprogram bör ta hänsyn till den mänskliga tendensen att ge upp efter för lång väntan. Lösningen får inte försöka igen med några sekunders mellanrum, eftersom den principen kan översvämma systemet med begäranden.

Intervallökning mellan återförsök

Vi rekommenderar att du väntar i 5 sekunder innan du försöker igen. Om du försöker igen efter en fördröjning som är kortare än 5 sekunder riskerar du att överbelasta molntjänsten. För varje efterföljande återförsök bör fördröjningen växa exponentiellt, upp till högst 60 sekunder.

En diskussion om blockeringsperioden för klienter som använder ADO.NET finns i Anslut ionspooler (ADO.NET).

Du kanske också vill ange ett maximalt antal återförsök innan programmet avslutas själv.

Kodexempel med logik för omförsök

Kodexempel med omprövningslogik finns på:

Testa logiken för återförsök

Om du vill testa logiken för återförsök måste du simulera eller orsaka ett fel som kan korrigeras medan programmet fortfarande körs.

Testa genom att koppla från nätverket

Ett sätt att testa logiken för återförsök är att koppla från klientdatorn från nätverket medan programmet körs. Felet är:

  • SqlException.Number = 11001
  • Meddelande: "Ingen sådan värd är känd"

Som en del av det första återförsöket kan du återansluta klientdatorn till nätverket och sedan försöka ansluta.

Om du vill göra det här testet praktiskt kan du koppla från datorn från nätverket innan du startar programmet. Sedan identifierar programmet en körningsparameter som gör att programmet:

  • Lägg tillfälligt till 11001 i listan över fel som ska anses vara tillfälliga.
  • Försök med den första anslutningen som vanligt.
  • När felet har fastnat tar du bort 11001 från listan.
  • Visa ett meddelande som uppmanar användaren att ansluta datorn till nätverket.
  • Pausa ytterligare körning med hjälp av metoden Console.ReadLine eller en dialogruta med en OK-knapp. Användaren trycker på Retur-tangenten när datorn är ansluten till nätverket.
  • Försök igen att ansluta och förvänta dig att lyckas.

Testa genom att felstava användarnamnet vid anslutning

Ditt program kan avsiktligt felstava användarnamnet före det första anslutningsförsöket. Felet är:

  • SqlException.Number = 18456
  • Meddelande: "Inloggningen misslyckades för användaren 'WRONG_MyUserName'."

Som en del av det första återförsöket kan programmet korrigera felstavningen och sedan försöka ansluta.

För att göra det här testet praktiskt identifierar programmet en körningsparameter som gör att programmet:

  • Lägg tillfälligt till 18456 i listan över fel som ska anses vara tillfälliga.
  • Lägg avsiktligt till "WRONG_" i användarnamnet.
  • När felet har fastnat tar du bort 18456 från listan.
  • Ta bort "WRONG_" från användarnamnet.
  • Försök igen att ansluta och förvänta dig att lyckas.

.NET Sql Anslut ion-parametrar för återförsök av anslutning

Om klientprogrammet ansluter till databasen i Azure SQL Database med hjälp av .NET Framework-klassen System.Data.SqlClient.Sql Anslut ion använder du .NET 4.6.1 eller en senare version (eller .NET Core) så att du kan använda funktionen för återförsök av anslutningen. Mer information om den här funktionen finns i Sql Anslut ion.AnslutionString-egenskap.

När du skapar anslutningssträng för sql Anslut ion-objektet samordnar du värdena mellan följande parametrar:

  • Anslut RetryCount: Standardvärdet är 1. Intervallet är 0 till 255.
  • Anslut RetryInterval: Standardvärdet är 10 sekunder. Intervallet är 1 till 60.
  • Anslut ion Timeout: Standardvärdet är 15 sekunder. Intervallet är 0 till och med 2147483647.
  • Tidsgräns för kommando: Standardvärdet är 30 sekunder. Intervallet är 0 till och med 2147483647.

Inställningarna för anslutningsåterförsök (Anslut RetryCount och Anslut RetryInterval) gäller för anslutningsåterhämtning. Anslut ionsåterhämtning innehåller följande distinkta typer:

  • Öppen anslutningsåterhämtning refererar till den inledande Sql Anslut ionen. Open- eller OpenAsync()-metod. Det första anslutningsförsöket räknas som försök noll. Anslut RetryCount gäller för efterföljande återförsök. Om anslutningen noll misslyckas (detta kanske inte inträffar omedelbart) tillämpas därför Anslut RetryInterval först följt av efterföljande Anslut RetryCount-försök (och Anslut RetryInterval). Om du vill dra nytta av alla återförsök måste egenskapen Anslut ion Timeout ge tid för alla försök.

  • Inaktiv anslutningsåterhämtning avser automatisk identifiering och återanslutning av befintliga inaktiva anslutningar som har brutits. Det första försöket att återansluta en bruten inaktiv anslutning räknas som det första återförsöket. Om du vill dra nytta av alla återförsök måste tidsgränsen för kommandot ge tid för alla försök.

Exempel: Anta följande värden för parametrarna Anslut RetryCount och Anslut RetryInterval:

Anslut RetryCount: 3 Anslut RetryInterval: 10 sekunder

Se hur dessa värden används i följande scenarier:

Scenario: Ny anslutning

4:10:00 - Anslut ion. Open() – noll försök

4:10:01 – Anslut ionsfel har identifierats

4:10:11 – Försök igen 1 –> Första återförsöket görs efter Anslut RetryInterval

4:10:21 – Försök igen 2

4:10:31 – Försök igen 3

I det här scenariot bör dina valda värden uppfylla följande villkor:
Connection Timeout > = ConnectRetryCount * ConnectionRetryInterval

Om antalet till exempel är 3 och intervallet är 10 sekunder ger en tidsgräns på bara 29 sekunder inte tillräckligt med tid för systemets tredje och sista återförsök att ansluta:

29 < 3 * 10

Scenario: Inaktiv anslutning

Anslut RetryCount: 3 Anslut RetryInterval: 10 sekunder

4:10:00 – Bruten anslutning identifierad vid kommandokörning

4:10:00 – Försök igen 1 –> Första återförsöket görs omedelbart

4:10:10 – Försök igen 2

4:10:20 – Försök igen 3

Det här är inte den första anslutningen. Därför gäller inte tidsgränsen för Anslut ion. Men eftersom anslutningsåterställningen sker under kommandokörningen gäller inställningen För tidsgräns för kommandot. Standardvärdet för tidsgränsen för kommandot är 30 sekunder. Även om anslutningsåterställningen är snabb under typiska omständigheter kan ett tillfälligt avbrott leda till att återställningen tar en del av körningstiden för kommandot.

För det här scenariot, om du vill dra full nytta av återställningsförsök för inaktiv anslutning, bör dina valda värden uppfylla följande villkor:
Command Timeout > (ConnectRetryCount - 1) * ConnectionRetryInterval

Om antalet till exempel är 3 och intervallet är 10 sekunder skulle ett timeoutvärde för kommandon som är lägre än 20 sekunder inte ge tillräckligt med tid för det tredje och sista återförsöket att ansluta: (3–1) * 10 = 20'

Tänk också på att själva kommandot kräver tid att köra när anslutningen har återställts.

Kommentar

Varaktighetsvärdena som anges i dessa scenarier är endast för demonstration. De faktiska identifieringstiderna i båda scenarierna beror på den underliggande infrastrukturen.

Anslut ion kontra kommando

Med parametrarna Anslut RetryCount och Anslut RetryInterval kan sql Anslut ion-objektet försöka ansluta igen utan att berätta eller störa programmet, till exempel att returnera kontroll till programmet. Återförsöken kan inträffa i följande situationer:

  • Sql Anslut ion. Öppna metodanrop
  • Sql Anslut ion. Kör metodanrop

Det finns en subtilitet. Om ett tillfälligt fel inträffar när frågan körs försöker inte sql Anslut ion-objektet ansluta igen. Det försöker verkligen inte din fråga igen. Sql Anslut ion kontrollerar dock anslutningen mycket snabbt innan du skickar frågan för körning. Om snabbkontrollen identifierar ett anslutningsproblem försöker Sql Anslut ion ansluta igen. Om återförsöket lyckas skickas frågan för körning.

Ska Anslut RetryCount kombineras med logik för omprövning av program

Anta att ditt program har robust logik för anpassade återförsök. Den kan försöka ansluta igen fyra gånger. Om du lägger till Anslut RetryInterval och Anslut RetryCount =3 i anslutningssträng ökar du antalet återförsök till 4 * 3 = 12 återförsök. Du kanske inte har för avsikt att göra så många återförsök.

Anslut joner till databasen i SQL Database

Anslut ion: Anslut ionssträng

Den anslutningssträng som krävs för att ansluta till databasen skiljer sig något från strängen som används för att ansluta till SQL Server. Du kan kopiera anslutningssträng för databasen från Azure-portalen.

Hämta anslutningssträng från Azure-portalen

Använd Azure-portalen för att hämta de anslutningssträng som krävs för att klientprogrammet ska kunna interagera med Azure SQL Database.

  1. Välj Alla tjänster>SQL-databaser.

  2. Ange namnet på databasen i filtertextrutan längst upp till vänster på bladet SQL-databaser .

  3. Välj raden för databasen.

  4. När bladet visas för databasen väljer du knapparna Minimera för att minimera bladen som du använde för surfning och databasfiltrering.

  5. På bladet för databasen väljer du Visa databas anslutningssträng.

  6. Kopiera lämpliga anslutningssträng. Om du tänker använda ADO.NET anslutningsbiblioteket kopierar du lämplig sträng från fliken ADO.NET .

    Copy the ADO connection string for your database

  7. Redigera anslutningssträng efter behov. d.v.s. Infoga lösenordet i anslutningssträng eller ta bort "@<servername>" från användarnamnet om användarnamnet eller servernamnet är för långt.

  8. I ett eller annat format klistrar du in anslutningssträng information i klientprogramkoden.

Mer information finns i Anslut ionssträngar och konfigurationsfiler.

Anslut ion: IP-adress

Du måste konfigurera SQL Database för att acceptera kommunikation från IP-adressen för den dator som är värd för klientprogrammet. Om du vill konfigurera den här konfigurationen redigerar du brandväggsinställningarna via Azure-portalen.

Om du glömmer att konfigurera IP-adressen misslyckas programmet med ett praktiskt felmeddelande som anger den nödvändiga IP-adressen.

  1. Logga in på Azure-portalen.

  2. I listan till vänster väljer du Alla tjänster.

  3. Rulla och välj SQL-servrar.

    Find your Azure SQL Database server in the portal

  4. I textrutan filter börjar du skriva namnet på servern. Raden visas.

  5. Välj raden för servern. Ett blad för servern visas.

  6. Välj Inställningar på serverbladet.

  7. Välj Brandvägg.

    Select Settings > Firewall

  8. Välj Lägg till klient-IP. Skriv ett namn på den nya regeln i den första textrutan.

  9. Ange de låga och höga IP-adressvärdena för det intervall som du vill aktivera.

    • Det kan vara praktiskt att ha det låga värdet slut med .0 och det höga värdet slut med .255.
  10. Välj Spara.

Mer information finns i Konfigurera brandväggsinställningar i SQL Database.

Anslut ion: Portar

Vanligtvis måste du se till att endast port 1433 är öppen för utgående kommunikation på den dator som är värd för klientprogrammet.

När klientprogrammet till exempel finns på en Windows-dator kan du använda Windows-brandväggen på värden för att öppna port 1433.

  1. Öppna Kontrollpanelen.
  2. Välj Alla Kontrollpanelen objekt>i Windows-brandväggen>Avancerad Inställningar> Åtgärder för utgående regler>>Ny regel.

Om klientprogrammet finns på en virtuell Azure-dator läser du Portar utöver 1433 för ADO.NET 4.5 och SQL Database.

Bakgrundsinformation om konfiguration av portar och IP-adresser i databasen finns i Azure SQL Database-brandväggen.

Anslut ion: ADO.NET 4.6.2 eller senare

Om ditt program använder ADO.NET klasser som System.Data.SqlClient.Sql Anslut ion för att ansluta till SQL Database rekommenderar vi att du använder .NET Framework version 4.6.2 eller senare.

Börjar med ADO.NET 4.6.2

  • Det öppna anslutningsförsöket görs omedelbart för Azure SQL, vilket förbättrar prestandan för molnaktiverade appar.

Börjar med ADO.NET 4.6.1

  • För SQL Database förbättras tillförlitligheten när du öppnar en anslutning med hjälp av Sql Anslut ion. Öppna-metoden. Metoden Öppna innehåller nu mekanismer för bästa möjliga återförsök som svar på tillfälliga fel för vissa fel inom tidsgränsen för anslutningen.
  • Anslut ionspooler stöds, vilket innefattar en effektiv verifiering av att anslutningsobjektet som det ger programmet fungerar.

När du använder ett anslutningsobjekt från en anslutningspool rekommenderar vi att programmet tillfälligt stänger anslutningen när den inte används omedelbart. Det är inte dyrt att öppna en anslutning igen, men det är att skapa en ny anslutning.

Om du använder ADO.NET 4.0 eller tidigare rekommenderar vi att du uppgraderar till den senaste ADO.NET. Från och med augusti 2018 kan du ladda ned ADO.NET 4.6.2.

Diagnostik

Diagnostik: Testa om verktyg kan ansluta

Om programmet inte kan ansluta till databasen i SQL Database är ett diagnostikalternativ att försöka ansluta till ett verktygsprogram. Helst ansluter verktyget med hjälp av samma bibliotek som programmet använder.

På valfri Windows-dator kan du prova dessa verktyg:

  • SQL Server Management Studio (ssms.exe), som ansluter med hjälp av ADO.NET
  • sqlcmd.exe, som ansluter med hjälp av ODBC

När programmet har anslutits testar du om en kort SQL SELECT-fråga fungerar.

Diagnostik: Kontrollera de öppna portarna

Om du misstänker att anslutningsförsök misslyckas på grund av portproblem kan du köra ett verktyg på datorn som rapporterar om portkonfigurationerna.

I Linux kan följande verktyg vara till hjälp:

  • netstat -nap
  • nmap -sS -O 127.0.0.1: Ändra exempelvärdet till din IP-adress.

I Windows kan verktyget PortQry.exe vara användbart. Här är ett exempel på en körning som efterfrågade portsituationen på en databas i SQL Database och som kördes på en bärbar dator:

[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\]
>>

Diagnostik: Logga dina fel

Ett tillfälligt problem diagnostiseras ibland bäst genom identifiering av ett allmänt mönster över dagar eller veckor.

Klienten kan hjälpa till med en diagnos genom att logga alla fel som den stöter på. Du kanske kan korrelera loggposterna med feldata som SQL Database loggar internt.

Företagsbibliotek 6 (EntLib60) erbjuder .NET-hanterade klasser för att hjälpa till med loggning. Mer information finns i 5 – Lika enkelt som att falla från en logg: Använd loggningsappblocket.

Diagnostik: Undersök systemloggar efter fel

Här följer några Transact-SQL SELECT-instruktioner som frågar efter felloggar och annan information.

Loggfråga Description
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;
Vyn sys.event_log innehåller information om enskilda händelser, som innehåller några som kan orsaka tillfälliga fel eller anslutningsfel.

Helst kan du korrelera start_time eller end_time värden med information om när klientprogrammet har problem.

Du måste ansluta till huvuddatabasen för att köra den här frågan.
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;
Vyn sys.database_connection_stats erbjuder aggregerade antal händelsetyper för ytterligare diagnostik.

Du måste ansluta till huvuddatabasen för att köra den här frågan.

Diagnostik: Sök efter problemhändelser i SQL Database-loggen

Du kan söka efter poster om problemhändelser i SQL Database-loggen. Prova följande Transact-SQL SELECT-instruktion i huvuddatabasen:

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
;

Några returnerade rader från sys.fn_xe_telemetry_blob_target_read_file

I följande exempel visas hur en returnerad rad kan se ut. De null-värden som visas är ofta inte null i andra rader.

object_name                   timestamp                    error  state  is_success  database_name

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

Företagsbibliotek 6

Enterprise Library 6 (EntLib60) är ett ramverk av .NET-klasser som hjälper dig att implementera robusta klienter för molntjänster, varav en är SQL Database. Information om hur du hittar ämnen som är dedikerade till varje område där EntLib60 kan hjälpa till finns i Företagsbibliotek 6–april 2013.

Omprövningslogik för hantering av tillfälliga fel är ett område där EntLib60 kan hjälpa till. Mer information finns i 4 – Uthållighet, hemlighet för alla triumfer: Använd programblocket för övergående felhantering.

Kommentar

Källkoden för EntLib60 är tillgänglig för offentlig nedladdning från Download Center. Microsoft har inga planer på att göra ytterligare funktionsuppdateringar eller underhållsuppdateringar till EntLib.

EntLib60-klasser för tillfälliga fel och försök igen

Följande EntLib60-klasser är särskilt användbara för omprövningslogik. Alla dessa klasser finns i eller under namnområdet Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.

I namnområdet Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling:

  • RetryPolicy-klass
    • ExecuteAction-metod
  • ExponentialBackoff-klass
  • SqlDatabaseTransientErrorDetectionStrategy-klass
  • ReliableSql Anslut ion-klass
    • ExecuteCommand-metod

I namnområdet Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.TestSupport:

  • AlwaysTransientErrorDetectionStrategy-klass
  • NeverTransientErrorDetectionStrategy-klass

Här följer några länkar till information om EntLib60:

EntLib60: Loggningsblocket

  • Loggningsblocket är en mycket flexibel och konfigurerbar lösning som du kan använda för att:
    • Skapa och lagra loggmeddelanden på en mängd olika platser.
    • Kategorisera och filtrera meddelanden.
    • Samla in sammanhangsbaserad information som är användbar för felsökning och spårning, samt för granskning och allmänna loggningskrav.
  • Loggningsblocket abstraherar loggningsfunktionen från loggmålet så att programkoden är konsekvent, oavsett plats och typ av målloggningsarkiv.

Mer information finns i 5 – Lika enkelt som att falla från en logg: Använd loggningsappblocket.

Källkod för EntLib60 IsTransient-metod

Från klassen SqlDatabaseTransientErrorDetectionStrategy finns sedan C#-källkoden för metoden IsTransient. Källkoden klargör vilka fel som ansågs vara tillfälliga och värda att försöka igen från och med april 2013.

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;
}

Nästa steg