Átmeneti csatlakozási hibák elhárítása az SQL Database-ben és az SQL Managed Instance-ben

A következőkre vonatkozik: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics

Ez a cikk bemutatja, hogyan előzheti meg, háríthatja el, diagnosztizálhatja és háríthatja el azokat a csatlakozási és átmeneti hibákat, amelyeket az ügyfélalkalmazás a Azure SQL Database, Azure SQL Managed Instance és Azure Synapse Analytics használatakor tapasztal. Megtudhatja, hogyan konfigurálhatja az újrapróbálkozási logikát, hogyan hozhatja létre a kapcsolati sztring, é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 megoldja önmagát. Az átmeneti hibák alkalmi oka, hogy az Azure-rendszer gyorsan áthelyezi a hardveres erőforrásokat a különböző számítási feladatok jobb terheléselosztá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 során problémák léphetnek fel az adatbázishoz való csatlakozás során SQL Database. 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 alkalmazáshibákként jelenne meg a felhasználóknak.

Ha az ügyfélprogram ADO.NET használ, a program az SqlException dobásával értesül az átmeneti hibáról.

Kapcsolat és parancs

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

  • Átmeneti hiba történik egy kapcsolati kísérlet során

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

  • Átmeneti hiba történik egy SQL Database és SQL Managed Instance lekérdezési parancs során

Ne próbálkozzon újra azonnal a paranccsal. Ehelyett egy késlelteté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

Azok az ü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 adatbázissal SQL Database, kérdezze meg a szállítót, hogy a köztes szoftver tartalmaz-e újrapróbálkozási logikát az átmeneti hibákhoz.

Újrapróbálkozás alapelvei

  • Ha a hiba átmeneti, próbálkozzon újra egy kapcsolat megnyitásával.
  • Ne próbálkozzon közvetlenül olyan SQL Database vagy SQL Managed Instance 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 SQL Database vagy SQL Managed Instance UPDATE utasítás átmeneti hibával meghiúsul, hozzon létre egy új kapcsolatot az UPDATE újrapróbálkozása előtt. 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 eltelt hosszú időintervallumokkal.
  • A felhasználói felületi programnak figyelembe kell vennie az emberi hajlamot, 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 eláraszthatja a rendszert kérésekkel.

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

Javasoljuk, hogy várjon 5 másodpercet az első újrapróbálkozás előtt. Az 5 másodpercnél rövidebb késleltetés után történő újrapróbálkozás 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 bővebben.

Azt is érdemes lehet beállítani, hogy a program önkiállítása előtt maximális számú újrapróbálkozás legyen.

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

Az újrapróbálkozások logikájával kapcsolatos példakódok 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 futá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: "Nem ismert ilyen gazdagép"

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

A teszt gyakorlati elvégzéséhez húzza ki a számítógépet a hálózatról, mielőtt elindítja a programot. Ezután a program felismeri a futásidejű paramétert, amely miatt a program a következőt eredményezi:

  • Ideiglenesen adja hozzá az 11001-et a hibák listájához, amelyeket átmenetinek kell tekinteni.
  • Próbálja meg az első kapcsolatot a szokásos módon.
  • A hiba észlelése után távolítsa el az 11001-et a listából.
  • Üzenet megjelenítése, amely arra utasítja 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 az OK gombot tartalmazó párbeszédpanel használatával. A felhasználó megnyomja 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 elgépelésével a csatlakozáskor

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

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

Az első újrapróbálkozási kísérlet részeként a program kijavíthatja a hibásan írt szöveget, majd megpróbálhat csatlakozni.

A teszt gyakorlatiassá tétele érdekében a program felismer egy futásidejű paramétert, amely a következőt eredményezi:

  • Ideiglenesen adja hozzá az 18456-ot a hibák listájához, amelyeket átmenetinek kell tekinteni.
  • Szándékosan adja hozzá a "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_" elemet 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 System.Data.SqlClient.SqlConnection .NET-keretrendszer osztály használatával csatlakozik az adatbázishoz Azure SQL Database-ben, használja a .NET 4.6.1-es vagy újabb verzióját (vagy .NET Core-t), hogy használni tudja a kapcsolat újrapróbálkozási funkcióját. A funkcióval kapcsolatos további információkért lásd: SqlConnection.ConnectionString tulajdonság.

Az SqlConnection-objektumkapcsolati sztring létrehozásakor koordinálja az értékeket a következő paraméterek között:

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

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

  • A nyílt kapcsolat rugalmassága a kezdeti SqlConnection.Open vagy OpenAsync() metódusra utal. Az első csatlakozási kísérlet nullának számít. A ConnectRetryCount a későbbi újrapróbálkozásokra vonatkozik. Ezért ha a kapcsolat nullája meghiúsul (ez nem feltétlenül következik be azonnal), a ConnectRetryInterval először a következő ConnectRetryCount (és ConnectRetryInterval) kísérleteket alkalmazza. Az újrapróbálkozási kísérletek előnyeinek kihasználásához a kapcsolat időtúllépési tulajdonságának időtúllépési időt kell biztosítania az összes kísérlethez.

  • Az üresjárati kapcsolat rugalmassága a megszakadt tétlen kapcsolatok automatikus észlelését és újracsatlakozását jelenti. A megszakadt üresjárati kapcsolat újracsatlakozá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őtúllépésének időtúllépést kell biztosítania az összes kísérlethez.

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

ConnectRetryCount: 3 ConnectRetryInterval: 10 másodperc

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

Forgatókönyv: Új kapcsolat

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

4:10:01 – Kapcsolati hiba észlelhető

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

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

04: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 időköz 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 kapcsolat észlelhető 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 – 2. újrapróbálkozás

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

Nem ez a kezdeti kapcsolat. Ezért a kapcsolat időtúllépése nem érvényes. Mivel azonban a kapcsolat helyreállítása a parancs végrehajtása során történik, a parancs időtúllépési beállítása érvényes. A parancs időtúllépése alapértelmezés szerint 30 másodperc. Bár a kapcsolat helyreállítása jellemző körülmények között gyors, időszakos leállás miatt előfordulhat, hogy a helyreállítás a parancs végrehajtásának egy részét is igénybe veszi.

Ebben a forgatókönyvben, ha teljes mértékben ki szeretné használni a tétlen 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 kisebb parancsidőkorlát nem ad elegendő időt a harmadik és a végleges újrapróbálkozáshoz a csatlakozáshoz: (3 - 1) * 10 = 20'

Azt is vegye figyelembe, hogy magának a parancsnak a végrehajtásához időre van szükség a kapcsolat helyreállítása után.

Megjegyzés

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

Kapcsolat és parancs

A ConnectRetryCount és a ConnectRetryInterval paraméterek lehetővé teszik, hogy az SqlConnection-objektum újrapróbálkozott a kapcsolódási művelettel anélkül, hogy a programnak szólna vagy zavarná, például vissza kell adnia a vezérlőt a programnak. Az újrapróbálkozások a következő helyzetekben fordulhatnak elő:

  • SqlConnection.Open metódushívás
  • SqlConnection.Execute metódushívás

Van egy finomság. Ha a lekérdezés végrehajtása közben átmeneti hiba történik, az SqlConnection objektum nem próbálkozik újra a kapcsolódási művelettel. Ez természetesen nem próbálkozik újra a lekérdezés. Az SqlConnection azonban nagyon gyorsan ellenőrzi a kapcsolatot, mielőtt elküldené a lekérdezést végrehajtásra. Ha a gyors ellenőrzés kapcsolódási problémát észlel, az SqlConnection újrapróbálkozásokat fog végrehajtani a kapcsolódási művelettel. Ha az újrapróbálkezés sikeres, a rendszer elküldi a lekérdezést végrehajtásra.

A ConnectRetryCount és az alkalmazás újrapróbálkozása logikával kombinálva

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 kapcsolódási művelettel. Ha a ConnectRetryInterval és a ConnectRetryCount =3 értéket adja hozzá a kapcsolati sztring, az újrapróbálkozások számát 4 * 3 = 12 újrapróbálkozási értékre növeli. Előfordulhat, hogy nem kíván ilyen sok újrapróbálkozást végrehajtani.

Kapcsolatok az adatbázishoz a SQL Database

Kapcsolat: Kapcsolati sztring

Az adatbázishoz való csatlakozáshoz szükséges kapcsolati sztring kissé eltérnek a SQL Server való csatlakozáshoz használt sztringtől. Az adatbázis kapcsolati sztring a Azure Portal másolhatja.

A kapcsolati sztring beszerzése a Azure Portal

A Azure Portal segítségével beszerezheti azokat a kapcsolati sztring, amelyek szükségesek ahhoz, hogy az ügyfélprogram együttműködjön Azure SQL Database-lel.

  1. Válassza az Összes szolgáltatás>SQL-adatbázisát.

  2. Írja be az adatbázis nevét az 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ázis-szűréshez használt panelek összecsukásához.

  5. Az adatbázis panelén válassza az adatbázis kapcsolati sztringjeinek megjelenítése lehetőséget.

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

    Az adatbázis ADO-kapcsolati sztring másolása

  7. Szükség szerint szerkessze a kapcsolati sztring. Például szúrja be a jelszót a kapcsolati sztring, vagy távolítsa el a "@<servername>" nevet a felhasználónévből, ha a felhasználónév vagy a kiszolgálónév túl hosszú.

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

További információ: Kapcsolati sztringek és konfigurációs fájlok.

Kapcsolat: IP-cím

Konfigurálnia kell SQL Database, hogy fogadja 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 a Azure Portal.

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

  1. Jelentkezzen be az Azure Portalra.

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

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

    A Azure SQL-adatbáziskiszolgáló megkeresése a portálon

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

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

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

  7. Válassza a Tűzfal lehetőséget.

    Válassza a Beállítások tűzfal lehetőséget >

  8. Válassza az Ügyfél IP-címének hozzáadása lehető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 vége .0 , a magas érték pedig 0,255.
  10. Válassza a Mentés lehetőséget.

További információ: Tűzfalbeállítások konfigurálása SQL Database.

Kapcsolat: Portok

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

Ha például az ügyfélprogram egy Windows rendszerű számítógépen fut, a gazdagépen a Windows tűzfal használatával megnyithatja az 1433-at.

  1. Nyissa meg a Vezérlőpultot.
  2. Válassza az összes Vezérlőpult elemet>a Windows tűzfal>speciális beállításainak>kimenő szabályokkal>kapcsolatos műveletek>új szabálya lehetőséget.

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

Az adatbázis portjainak és IP-címeinek konfigurálásáról további információt Azure SQL Adatbázis tűzfala című témakörben talál.

Kapcsolat: ADO.NET 4.6.2 vagy újabb verzió

Ha a program olyan ADO.NET osztályokat használ, mint a System.Data.SqlClient.SqlConnection SQL Database, javasoljuk, hogy .NET-keretrendszer 4.6.2-es vagy újabb verzióját használja.

A ADO.NET 4.6.2-től kezdve

  • A kapcsolatmegnyitási kísérlet azonnal újrapróbálkozott Azure SQL, ezáltal javítva a felhőalapú alkalmazások teljesítményét.

A ADO.NET 4.6.1-től kezdve

  • A SQL Database megbízhatósága javul, ha az SqlConnection.Open metódussal nyit meg egy kapcsolatot. Az Open metódus most már tartalmazza a legjobb erőkifejtésű újrapróbálkozási mechanizmusokat bizonyos hibák átmeneti hibáira válaszul a kapcsolat időtúllépési időszakán belül.
  • A kapcsolatkészletezés támogatott, amely hatékony ellenőrzést biztosít a program számára biztosított kapcsolatobjektum működéséről.

Ha kapcsolati objektumot használ egy kapcsolatkészletből, azt javasoljuk, hogy a program ideiglenesen zárja be a kapcsolatot, ha az 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-t.

Diagnosztika

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

Ha a program nem tud csatlakozni az adatbázishoz SQL Database, az egyik diagnosztikai lehetőség egy 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 hiúsulnak meg, 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 az 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: Hibák naplózása

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

Az ügyfél az összes észlelt hiba naplózásával segíthet a diagnózisban. Előfordulhat, hogy a naplóbejegyzéseket olyan hibaadatokkal tudja korrelálni, amelyek belsőleg SQL Database naplózza magát.

Az Enterprise Library 6 (EntLib60) .NET által felügyelt osztályokat kínál a naplózáshoz. További információ: 5 – Olyan egyszerű, mint leesni egy naplóból: Használja a naplózási 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 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;
A sys.event_log nézet információkat nyújt az egyes eseményekről, amelyek átmeneti hibákat vagy csatlakozási hibákat okozhatnak.

Ideális esetben korrelálhatja a start_time vagy end_time értékeket az ügyfélprogram problémáival kapcsolatos információkkal.

A lekérdezés futtatásához csatlakoznia kell a master 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 master adatbázishoz.

Diagnosztika: Problémaesemények keresése a SQL Database naplóban

A problémaeseményekre vonatkozó bejegyzéseket a SQL Database naplóban keresheti meg. Próbálja ki a következő Transact-SQL SELECT utasítást a master 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

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ódtár 6

Az Enterprise Library 6 (EntLib60) a .NET-osztályok keretrendszere, amely segít a felhőalapú szolgáltatások robusztus ügyfeleinek megvalósításában, amelyek közül az egyik SQL Database. Az EntLib60 minden olyan területéhez kapcsolódó témakörök megkereséséhez, amelyekben az EntLib60 segítséget nyújthat, tekintse meg az Enterprise Library 6 – April 2013 című témakört.

Az átmeneti hibák kezelésének újrapróbálkozási logikája az egyik terület, ahol az EntLib60 segíthet. További információ: 4 – Kitartás, minden diadal titka: Használja az átmeneti hibakezelési alkalmazásblokkot.

Megjegyzés

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ási logikához. Ezek az osztályok a Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling névtérben vagy alatt találhatók.

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

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

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

  • 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:
    • A naplóüzenetek számos különböző helyen hozhatók létre és tárolhatók.
    • Üzenetek kategorizálása és szűrése.
    • Gyűjtsön környezetfüggő információkat, amelyek hasznosak a hibakereséshez és a nyomkövetéshez, valamint a naplózáshoz és az általános naplózási követelményekhez.
  • A naplózási blokk elvonja a naplózási funkciót a napló célhelyéről, hogy az alkalmazáskód konzisztens legyen, függetlenül a célnaplózási tároló helyétől és típusától.

További információ: 5 – Olyan egyszerű, mint leesni egy naplóból: Használja a naplózási alkalmazásblokkot.

EntLib60 IsTransient metódus forráskódja

Ezután az SqlDatabaseTransientErrorDetectionStrategy osztályból származik az IsTransient metódus C#-forráskódja. A forráskód tisztázza, hogy mely hibák tekinthetők átmenetinek és érdemesnek az újrapróbálkozásra 2013 áprilisától.

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

Következő lépések

Lásd még