Átmeneti csatlakozási hibák elhárítása

A következőkre vonatkozik:Azure SQL DatabaseFelügyelt Azure SQL-példányAzure Synapse AnalyticsSQL-adatbázis a Fabricben

Ez a cikk ismerteti, hogyan előzheti meg, háríthatja el, diagnosztizálhatja, és csökkentheti az ügyfélalkalmazás által az Azure SQL Database, a Microsoft Fabric SQL Database, az Azure SQL Managed Instance és az Azure Synapse Analytics használatakor előforduló csatlakozási és átmeneti hibákat. Megtudhatja, hogyan konfigurálhatja az újrapróbálkozási logikát, hogyan hozhatja létre a kapcsolati sztringet, és hogyan módosíthatja az egyéb kapcsolati beállításokat.

Átmeneti hibák (átmeneti hibák)

Az átmeneti hibáknak, más néven átmeneti hibáknak van egy mögöttes oka, amely hamarosan megoldódik. Az átmeneti hibák alkalmi oka, hogy az Azure-rendszer gyorsan áthelyezi a hardvererőforrásokat a különböző számítási feladatok terheléselosztásának jobb kihasználása érdekében. Az újrakonfigurálási események többsége kevesebb mint 60 másodperc alatt fejeződik be. Az újrakonfigurálási időtartam alatt problémákat tapasztalhat az adatbázishoz való csatlakozással kapcsolatban az SQL Database-ben. Az adatbázishoz csatlakozó alkalmazásokat úgy kell létrehozni, hogy ezekre az átmeneti hibákra számítson. A kezelésükhöz implementáljon újrapróbálkozási logikát a kódban, ahelyett, hogy a felhasználóknak alkalmazáshibaként mutatná őket.

Ha az ügyfélprogram ADO.NET-et használ, a programot az átmeneti hibáról a SqlExceptionkivétel dobásával értesítik.

Kapcsolat vs. parancs

Próbálkozzon újra a kapcsolattal, vagy hozza létre újra a kapcsolatot az alábbiaktól függően:

  • Egy kapcsolati kísérlet során átmeneti hiba

Néhány másodperces késés után próbálkozzon újra a kapcsolattal.

  • Átmeneti hiba történik egy lekérdezési parancs során

Ne próbálkozzon azonnal újra a paranccsal. Ehelyett egy késés után hozza létre újra a kapcsolatot. Ezután próbálkozzon újra a paranccsal.

Újrapróbálkozási logika átmeneti hibák esetén

Az olyan ügyfélprogramok, amelyek időnként átmeneti hibába ütköznek, robusztusabbak, ha újrapróbálkozási logikát tartalmaznak. Amikor a program harmadik féltől származó köztes szoftveren keresztül kommunikál az SQL Database-ben lévő adatbázissal, kérdezze meg a szállítót, hogy a köztes szoftver tartalmaz-e újrapróbálkozási logikát átmeneti hibák esetén.

Újrapróbálkozás alapelvei

  • Ha a hiba átmeneti, próbálkozzon újra egy kapcsolat megnyitásához.
  • Ne próbálkozzon közvetlenül egy SELECT utasítással, amely átmeneti hibával meghiúsult. Ehelyett hozzon létre egy új kapcsolatot, majd próbálkozzon újra a SELECT.
  • Ha egy UPDATE utasítás átmeneti hibával meghiúsul, hozzon létre egy új kapcsolatot, mielőtt újrapróbálkozza a UPDATE. Az újrapróbálkozás logikájának biztosítania kell, hogy a teljes adatbázis-tranzakció befejeződött, vagy a teljes tranzakció vissza legyen állítva.

Az újrapróbálkozások egyéb szempontjai

  • Egy olyan kötegelt program, amely munkaidő után automatikusan elindul, és reggel előtt fejeződik be, megengedheti magának, hogy nagyon türelmes legyen az újrapróbálkozási kísérletek között.
  • A felhasználói felület programnak figyelembe kell vennie az emberi tendenciát, hogy túl hosszú várakozás után feladja. A megoldásnak nem szabad néhány másodpercenként újrapróbálkoznia, mert ez a szabályzat kérésekkel eláraszthatja a rendszert.

Az újrapróbálkozási időköz növelése

Javasoljuk, hogy várjon 5 másodpercet az első újrapróbálkozás előtt. Ha 5 másodpercnél rövidebb késleltetés után újra próbálkozik, az túlterheli a felhőszolgáltatást. Minden további újrapróbálkozáshoz a késleltetésnek exponenciálisan, legfeljebb 60 másodpercig kell növekednie.

A ADO.NET használó ügyfelek blokkolási időszakáról a Kapcsolatkészletezés (ADO.NET)című témakörben olvashat.

Mielőtt a program automatikusan leáll, érdemes lehet beállítani az újrapróbálkozások maximális számát.

Kódminták újrapróbálkozási logikával

Az újrapróbálkozással kapcsolatos példák a következő helyen érhetők el:

Az újrapróbálkozás logikája tesztelése

Az újrapróbálkozási logika teszteléséhez szimulálnia kell vagy hibát kell okoznia, amely javítható a program futtatása közben.

Tesztelés a hálózatról való leválasztással

Az újrapróbálkozási logika tesztelésének egyik módja, ha leválasztja az ügyfélszámítógépet a hálózatról, miközben a program fut. A hiba a következő:

  • SqlException.Number = 11001
  • Üzenet: "Nincs ilyen ismert kiszolgáló"

Az első újrapróbálkozási kísérlet részeként újra csatlakoztathatja az ügyfélszámítógépet a hálózathoz, majd megpróbálhat csatlakozni.

A teszt gyakorlatiassá tétele érdekében húzza ki a számítógépet a hálózatról, mielőtt elindítja a programot. Ezután a program felismer egy futtatókörnyezeti paramétert, amely miatt a program a következőt eredményezi:

  • Ideiglenesen adja hozzá az 11001-et az átmenetiként figyelembe veendő hibák listájához.
  • Próbálja meg az első kapcsolatfelvételt a szokásos módon.
  • A hiba észlelése után távolítsa el az 11001-et a listából.
  • Megjelenít egy üzenetet, amely tájékoztatja a felhasználót, hogy csatlakoztassa a számítógépet a hálózathoz.
  • Szüneteltetheti a további végrehajtást a Console.ReadLine metódus vagy egy OK gombot tartalmazó párbeszédpanel használatával. A felhasználó lenyomja az Enter billentyűt, miután a számítógép csatlakoztatva van a hálózathoz.
  • Próbálkozzon újra a csatlakozáshoz, és várjon sikert.

Tesztelés a felhasználónév elírásával a csatlakozáskor

A program szándékosan elgépelheti a felhasználónevet az első kapcsolati kísérlet előtt. A hiba a következő:

  • SqlException.Number = 18456
  • Üzenet: "A bejelentkezés nem sikerült az "WRONG_MyUserName" felhasználónál."

Az első újrapróbálkozási kísérlet részeként a program kijavíthatja a helyesírást, majd megpróbálhat csatlakozni.

A teszt gyakorlatiassá tétele érdekében a program felismer egy futtatókörnyezeti paramétert, amely miatt a program a következőt eredményezi:

  • Ideiglenesen adja hozzá az 18456-ot az átmenetinek tekintett hibák listájához.
  • Szándékosan adja hozzá az "WRONG_" nevet a felhasználónévhez.
  • A hiba észlelése után távolítsa el az 18456-ot a listából.
  • Távolítsa el a "WRONG_" nevet a felhasználónévből.
  • Próbálkozzon újra a csatlakozáshoz, és várjon sikert.

.NET SqlConnection-paraméterek a kapcsolat újrapróbálkozáshoz

Ha az ügyfélprogram a Microsoft.Data.SqlClient.SqlConnection vagy a System.Data.SqlClient.SqlConnection .NET-osztály vagy a System.Data.SqlClient.SqlConnection segítségével csatlakozik az adatbázishoz az Azure SQL Database-ben, használhatja a kapcsolat újrapróbálkozási funkcióit. Ehhez System.Data.SqlClienthasználja a .NET-keretrendszer 4.6.1-es vagy újabb verzióját (vagy .NET Core-t). A funkcióval kapcsolatos további információkért lásd SqlConnection.ConnectionString tulajdonság.

Jegyzet

Microsoft.Data.SqlClient az új alkalmazásfejlesztéshez ajánlott ADO.NET adatszolgáltató. A kapcsolat újrapróbálkozásán kívül támogatja a konfigurálható újrapróbálkozási logikát a kapcsolat- és a parancs-újrapróbálkozáshoz is. További információ: Bevezetés a Microsoft.Data.SqlClient névtérbe.

A SqlConnection objektum kapcsolati sztringjének létrehozásakor koordinálja az értékeket az alábbi paraméterek között:

  • ConnectRetryCount: Az alapértelmezett érték 1. A tartomány 0 és 255között van.
  • ConnectRetryInterval: Az alapértelmezett érték 10 másodperc. A tartomány 1 -től 60-ig terjed.
  • Kapcsolat időtúllépés: Az alapértelmezett érték 15 másodperc. A tartomány 0-tól 2147483647-ig.

A kapcsolat rugalmasságára a kapcsolat újrapróbálkozási beállításai (ConnectRetryCount és ConnectRetryInterval) vonatkoznak. A kapcsolat rugalmassága a következő különböző típusokat foglalja magában:

  • Az kapcsolatnyitás rugalmassága az SqlConnection.Open vagy OpenAsync() kezdeti metódusra utal. Az első kapcsolati kísérlet nullának számít. ConnectRetryCount a későbbi újrapróbálkozésekre vonatkozik. Ezért, ha az első kapcsolat meghiúsul (ami nem biztos, hogy azonnal bekövetkezik), először a ConnectRetryInterval kerül alkalmazásra, majd az azt követő ConnectRetryCount (és ConnectRetryInterval) próbálkozások. Az újrapróbálkozási kísérletek előnyeinek kihasználásához a kapcsolat időtúllépési tulajdonságnak időt kell adnia az összes kísérlethez.

  • Az inaktív kapcsolat rugalmassága a megszakadt inaktív kapcsolatok automatikus észlelését és újracsatlakozását jelenti. A megszakadt tétlen kapcsolatok újracsatlakoztatásának első kísérlete az első újrapróbálkozási kísérletnek számít. Az újrapróbálkozási kísérletek előnyeinek kihasználásához a parancs időkorlátnak időt kell biztosítania minden kísérlethez.

Példa: Tegyük fel, hogy a ConnectRetryCount és a ConnectRetryInterval paraméterek a következő értékeket:

ConnectRetryCount: 3 ConnectRetryInterval: 10 másodperc

Tekintse meg, hogyan használják ezeket az értékeket a következő helyzetekben:

forgatókönyv: Új kapcsolat

4:10:00 – Connection.Open() – nulla kísérlet

4:10:01 – Kapcsolati hiba észlelhető

4:10:11 – Első újrapróbálkozás –> Az első újrapróbálkozás után történik ConnectRetryInterval

4:10:21 – Újrapróbálkozás 2

4:10:31 – Újrapróbálkozás 3

Ebben a forgatókönyvben a kiválasztott értékeknek meg kell felelniük a következő feltételnek:
Connection Timeout > = ConnectRetryCount * ConnectionRetryInterval

Ha például a szám 3, és az intervallum 10 másodperc, akkor a mindössze 29 másodperces időtúllépés nem biztosít elegendő időt a rendszer harmadik és utolsó újrapróbálkozásához a csatlakozáshoz:

29 < 3 * 10

forgatókönyv: Tétlen kapcsolat

ConnectRetryCount: 3 ConnectRetryInterval: 10 másodperc

4:10:00 – Megszakadt a kapcsolat a parancs végrehajtásakor

4:10:00 – 1. újrapróbálkozás –>Az első újrapróbálkozás azonnal megtörténik

4:10:10 – Újrapróbálkozás 2

4:10:20 – Újrapróbálkozás 3

Nem ez a kezdeti kapcsolat. Ezért kapcsolat időtúllépési nem érvényes. Mivel azonban a kapcsolat helyreállítása a parancs végrehajtása során történik, az utasítást végrehajtó SqlCommandparancs időtúllépési tulajdonsága érvényes. A parancs időtúllépési alapértelmezett értéke 30 másodperc. Bár a kapcsolat helyreállítása jellemző körülmények között gyors, időszakos kimaradás esetén előfordulhat, hogy a helyreállítás a parancsvégrehajtási idő egy részét is igénybe veszi.

Ebben a forgatókönyvben, ha teljes mértékben ki szeretné használni az üresjárati kapcsolat helyreállításának újrapróbálkozását, a kiválasztott értékeknek a következő feltételnek kell megfelelniük:
Command Timeout > (ConnectRetryCount - 1) * ConnectionRetryInterval

Ha például a szám 3, és az intervallum 10 másodperc, akkor a 20 másodpercnél rövidebb parancsidőkorlát nem ad elegendő időt a harmadik és utolsó újrapróbálkozáshoz a csatlakozáshoz: (3 – 1) * 10 = 20'

Vegye figyelembe azt is, hogy magának a parancsnak időre van szüksége a kapcsolat helyreállítása után.

Jegyzet

Az ezekben a forgatókönyvekben megadott időtartamértékek csak bemutatóra szolgálnak. Mindkét forgatókönyv tényleges észlelési ideje a mögöttes infrastruktúrától függ.

Kapcsolat vs. parancs

A ConnectRetryCount és ConnectRetryInterval paraméterek lehetővé teszik, hogy a SqlConnection objektum újrapróbálkozzon a kapcsolódási művelettel anélkül, hogy a programot értesítené vagy zavarná, például anélkül, hogy visszaadná a vezérlést a programnak. Az újrapróbálkozás a következő esetekben fordulhat elő:

  • SqlConnection.Open metódus hívása
  • SqlCommand.Execute* metódushívások

Van egy árnyalatnyi különbség. Ha átmeneti hiba történik a lekérdezési végrehajtása közben, a SqlConnection objektum nem próbálkozik újra a kapcsolódási művelettel. Természetesen nem próbálkozik újra a lekérdezésrel. Azonban SqlConnection nagyon gyorsan ellenőrzi a kapcsolatot, mielőtt elküldené a lekérdezést végrehajtásra. Ha a gyors ellenőrzés csatlakozási problémát észlel, SqlConnection újrapróbálkozza a csatlakozási műveletet. Ha az újrapróbálkozás sikeres, a rendszer végrehajtásra küldi a lekérdezést.

Kombinálni kellene a ConnectRetryCount-ot az alkalmazás újrapróbálkozási logikájával?

Tegyük fel, hogy az alkalmazás robusztus egyéni újrapróbálkoztatási logikával rendelkezik. Előfordulhat, hogy négyszer próbálkozik újra a csatlakozási művelettel. Ha ConnectRetryInterval és ConnectRetryCount =3 értéket ad hozzá a kapcsolati sztringhez, az újrapróbálkozási számot 4 * 3 = 12 újrapróbálkozási értékre növeli. Lehet, hogy nem tervez ilyen sok újrapróbálkozását.

Kapcsolatok az adatbázissal az SQL Database-ben

Kapcsolat: Kapcsolati karakterlánc

Az adatbázishoz való csatlakozáshoz szükséges kapcsolati sztring kissé eltér az SQL Serverhez való csatlakozáshoz használt sztringtől. Az Azure portálról másolhatja le az adatbázis kapcsolati sztringjét.

A kapcsolati sztring beszerzése az Azure Portalról

Az Azure Portal segítségével szerezze be az ügyfélprogram számára az Azure SQL Database használatához szükséges kapcsolati sztringet.

  1. Válassza a(z) Minden szolgáltatás>SQL-adatbázisoklehetőséget.

  2. Adja meg az adatbázis nevét a SQL-adatbázisok panel bal felső részén található szűrőszövegmezőbe.

  3. Válassza ki az adatbázis sorát.

  4. Miután megjelenik az adatbázis panelje, a vizuális kényelem érdekében válassza a Kis méretű gombokat a böngészéshez és az adatbázisszűréshez használt panelek összecsukásához.

  5. Az adatbázis ablaktábláján válassza a Adatbázis-kapcsolati karakterláncok megjelenítéselehetőséget.

  6. Másolja ki a megfelelő kapcsolati sztringet. Ha például a ADO.NET kapcsolatkódtárat szeretné használni, másolja ki a megfelelő sztringet a ADO.NET lapról.

    Képernyőkép az adatbázis ADO kapcsolati sztringjének másolásáról.

  7. Szükség szerint szerkessze a kapcsolati sztringet. Ebben a példában szúrja be a jelszót a kapcsolati sztringbe, vagy távolítsa el <server-name> a felhasználónévből, ha a felhasználónév vagy a kiszolgáló neve túl hosszú.

  8. Egy vagy több formátumban illessze be a kapcsolati sztring adatait az ügyfélprogram kódjába.

További információért lásd: Kapcsolati karaktersorozatok és konfigurációs fájlok.

Kapcsolat: IP-cím

Konfigurálnia kell az SQL Database-t, hogy fogadja el az ügyfélprogramot futtató számítógép IP-címéről érkező kommunikációt. A konfiguráció beállításához szerkessze a tűzfalbeállításokat az Azure portalsegítségével.

Ha elfelejti konfigurálni az IP-címet, a program egy hasznos hibaüzenettel meghiúsul, amely a szükséges IP-címet adja meg.

  1. Jelentkezzen be az Azure portálra .

  2. A bal oldali listában válassza a Minden szolgáltatáslehetőséget.

  3. Görgessen, és válassza ki SQL-kiszolgálókat.

    Képernyőkép az Azure SQL Database-kiszolgáló megkereséséről a portálon.

  4. Kezdje el beírni a kiszolgáló nevét a szűrőszövegmezőbe. Megjelenik a sor.

  5. Válassza ki a szerver sorát. Megjelenik a kiszolgálója panelje.

  6. A kiszolgálópanelen válassza a Beállításoklehetőséget.

  7. Válassza Tűzfal.

    Beállítások kiválasztása > tűzfal képernyőképe.

  8. Válassza Ügyfél IP-címének hozzáadásalehetőséget. Írja be az új szabály nevét az első szövegmezőbe.

  9. Írja be az engedélyezni kívánt tartomány alacsony és magas IP-címértékét.

    • Hasznos lehet, ha az alacsony érték .0, a magas érték pedig .255végződik.
  10. Válassza a Mentésgombot.

További információ: Azure SQL Database és Azure Synapse IP-tűzfalszabályok.

Kapcsolat: Portok

Általában gondoskodnia kell arról, hogy csak az 1433-as port legyen nyitva a kimenő kommunikációhoz az ügyfélprogramot üzemeltető számítógépen.

Ha például az ügyfélprogramot (kliens) Windows-számítógépen üzemelteti, a gazdagép Windows tűzfalán keresztül nyithatja meg a 1433-as portot.

  1. Nyissa meg a Vezérlőpultot.
  2. Válassza Minden Vezérlőpult-elem>Windows tűzfal>Speciális beállítások>Kimenő szabályok>Műveletek>Új szabálylehetőséget.

Ha az ügyfélprogram egy Azure-beli virtuális gépen (VM)fut, olvassa el az 1433-at meghaladó portokat a ADO.NET 4.5-ös verzióhoz.

Az adatbázis portjainak és IP-címeinek konfigurálásáról további információt az Azure SQL Database és az Azure Synapse IP-tűzfalszabályokban talál.

Kapcsolat: ADO.NET 4.6.2 vagy újabb verzió

Ha a program ADO.NET osztályokat használ, például System.Data.SqlClient.SqlConnection az SQL Database-hez való csatlakozáshoz, javasoljuk, hogy a .NET-keretrendszer 4.6.2-es vagy újabb verzióját használja. Új alkalmazások esetén fontolja meg a használatát Microsoft.Data.SqlClient, amely ugyanazt a kapcsolatot biztosítja a továbbfejlesztett funkciókkal.

Kezdje a ADO.NET 4.6.2-vel

  • A kapcsolat megnyitásának kísérlete azonnal újrapróbálkozott az Azure SQL-hez, ezáltal javítva a felhőalapú alkalmazások teljesítményét.

Kezdés a ADO.NET 4.6.1-sel

  • Az SQL Database esetében a megbízhatóság javul, ha megnyit egy kapcsolatot az SqlConnection.Open metódussal. A Open metódus mostantól a legjobb erőkifejtésű újrapróbálkozási mechanizmusokat is magában foglalja bizonyos hibák átmeneti hibáira válaszul a kapcsolati időtúllépési időszakon belül.
  • A kapcsolatkészletezés támogatott, amely magában foglalja annak hatékony ellenőrzését, hogy a program számára biztosított kapcsolatobjektum megfelelően működik-e.

Ha kapcsolati objektumot használ egy kapcsolatkészletből, javasoljuk, hogy a program ideiglenesen zárja be a kapcsolatot, ha nincs azonnal használatban. Nem költséges újra megnyitni egy kapcsolatot, de új kapcsolatot kell létrehoznia.

Ha a ADO.NET 4.0-s vagy korábbi verziót használja, javasoljuk, hogy frissítsen a legújabb ADO.NET. 2018 augusztusától letöltheti ADO.NET 4.6.2.

Diagnosztika

Diagnosztika: Annak tesztelése, hogy a segédprogramok képesek-e csatlakozni

Ha a program nem tud csatlakozni az adatbázishoz az SQL Database-ben, az egyik diagnosztikai lehetőség a segédprogrammal való kapcsolódás. Ideális esetben a segédprogram ugyanazzal a kódtárzal csatlakozik, amelyet a program használ.

Bármely Windows rendszerű számítógépen kipróbálhatja az alábbi segédprogramokat:

  • SQL Server Management Studio (ssms.exe), amely ADO.NET használatával csatlakozik
  • sqlcmd.exe, amely ODBC- használatával csatlakozik

A program csatlakoztatása után tesztelje, hogy működik-e egy rövid SQL SELECT-lekérdezés.

Diagnosztika: A megnyitott portok ellenőrzése

Ha azt gyanítja, hogy a csatlakozási kísérletek portproblémák miatt meghiúsulnak, futtathat egy segédprogramot a számítógépen, amely a portkonfigurációkról számol be.

Linuxon a következő segédprogramok lehetnek hasznosak:

  • netstat -nap
  • nmap -sS -O 127.0.0.1: Módosítsa a példaértéket a saját IP-címére.

Windows rendszeren a PortQry.exe segédprogram hasznos lehet. Íme egy példa a végrehajtásra, amely lekérdezte egy SQL Database-adatbázis porthelyzetét, és amelyet egy laptopon futtattak:

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

Diagnosztika: Naplózd a hibákat

Az időszakos problémákat néha a legjobban egy általános minta észlelésével diagnosztizálják napok vagy hetek alatt.

Az ügyfél a felmerülő hibák naplózásával segíthet a diagnózisban. Előfordulhat, hogy a naplóbejegyzéseket összevetheti az SQL Database által belsőleg naplózandó hibaadatokkal.

Az Enterprise Library 6 (EntLib60) .NET által felügyelt osztályokat kínál a naplózáshoz. További információért lásd: 5 – Olyan egyszerű, mint leesni egy fáról: Használja a naplózó alkalmazásblokkot.

Diagnosztika: A rendszernaplók hibáinak vizsgálata

Íme néhány Transact-SQL SELECT utasítás, amely hibanaplókat és egyéb információkat kérdez le.

Napló lekérdezése Leírás
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;
A sys.event_log nézet információkat tartalmaz az egyes eseményekről, amelyek átmeneti hibákat vagy csatlakozási hibákat okozhatnak.

Ideális esetben össze tudja kapcsolni a start_time vagy end_time értékeket azzal az információval, amikor az ügyfélprogramjában problémák merültek fel.

A lekérdezés futtatásához csatlakoznia kell a adatbázishoz.
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;
A sys.database_connection_stats nézet az eseménytípusok összesített számát kínálja további diagnosztikákhoz.

A lekérdezés futtatásához csatlakoznia kell a adatbázishoz.

Diagnosztika: Problémaesemények keresése az SQL Database naplójában

A problémaesemények bejegyzéseit az SQL Database naplójában keresheti meg. Próbálkozzon a következő Transact-SQL SELECT utasítással a adatbázisban:

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éhány visszaadott sor a sys.fn_xe_telemetry_blob_target_read_file-ból

Az alábbi példa bemutatja, hogyan nézhet ki egy visszaadott sor. A megjelenített null értékek gyakran nem null értékűek más sorokban.

object_name                   timestamp                    error  state  is_success  database_name

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

Vállalati könyvtár 6

Az Enterprise Library 6 (EntLib60) a .NET-osztályok keretrendszere, amely segít a felhőalapú szolgáltatások robusztus ügyfeleinek implementálásában, amelyek egyike az SQL Database. Az EntLib60-hoz kapcsolódó témakörök megkereséséhez tekintse meg Enterprise Library 6című témakört.

Az átmeneti hibák kezelésére szolgáló újrapróbálkozási logika egy olyan terület, ahol az EntLib60 segíthet. További információ: 4 – Kitartás, az összes diadal titka: Használja az átmeneti hibakezelési alkalmazásblokkot.

Jegyzet

Az EntLib60 forráskódja nyilvánosan letölthető a Letöltőközpontból. A Microsoft nem tervezi az EntLib további funkciófrissítéseit vagy karbantartási frissítéseit.

EntLib60-osztályok átmeneti hibákhoz és újrapróbálkozáshoz

Az alábbi EntLib60-osztályok különösen hasznosak az újrapróbálkozáshoz. Ezek az osztályok a Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling névtérben vagy alatt találhatók.

A névtérben Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling:

  • RetryPolicy osztály
    • ExecuteAction metódus
  • ExponenciálisBackoff osztály
  • SqlDatabaseTransientErrorDetectionStrategy osztály
  • ReliableSqlConnection osztály
    • ExecuteCommand metódus

A névtérben Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.TestSupport:

  • AlwaysTransientErrorDetectionStrategy osztály
  • NeverTransientErrorDetectionStrategy osztály

Íme néhány hivatkozás az EntLib60-ra vonatkozó információkra:

EntLib60: A naplózási blokk

  • A naplózási blokk egy rendkívül rugalmas és konfigurálható megoldás, amellyel:
    • Naplóüzenetek létrehozása és tárolása számos helyen.
    • Üzenetek kategorizálása és szűrése.
    • Gyűjtse össze a hibakereséshez és nyomkövetéshez, valamint a naplózáshoz és az általános naplózási követelményekhez hasznos környezeti információkat.
  • A naplózási blokk elvonja a naplózási funkciót a napló céljától, hogy az alkalmazáskód konzisztens legyen, függetlenül a célnapló-tároló helyétől és típusától.

További információért lásd: 5 – Olyan egyszerű, mint leesni egy fáról: Használja a naplózó alkalmazásblokkot.

EntLib60 IsTransient metódus forráskódja

Ezután az SqlDatabaseTransientErrorDetectionStrategy osztályból az IsTransient metódus C# forráskódja. A forráskód egyértelművé teszi, hogy mely hibák tekinthetők átmenetinek és érdemesnek az újrapróbálkozásra.

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