Konfigurovatelná logika opakování (JDBC)

Stáhnout ovladač JDBC

Konfigurovatelná logika opakování (CRL) je mechanismus založený na pravidlech, který automaticky opakuje neúspěšné příkazy nebo počáteční pokusy o připojení na základě SQL Server čísel chyb, která zvolíte, s parametry časování, které řídíte. CRL bylo zavedeno v ovladači Microsoft JDBC Driver 12.10 pro SQL Server.

CRL je oddělené od odolnosti neaktivních připojení a vlastností connectRetryCount / connectRetryInterval. Odolnost při nečinnosti transparentně obnovuje přerušená připojení a connectRetryCount opakuje počáteční ověření v pevných intervalech u předdefinovaného seznamu přechodných chyb. CRL umožňuje rozhodnout, které chyby se dají opakovat, kolikrát a jak dlouho se mají čekat mezi pokusy. Můžete použít všechny tři mechanismy společně.

Opakování CRL

CRL zpracovává dva různé scénáře, z nichž každá je řízena vlastní vlastností připojení:

Scenario	Vlastnictví	Při spuštění opakování	Aktivoval(a)
Selhání při spuštění příkazu	retryExec	Při provádění příkazu (například executeQuery, executeUpdate, execute, nebo dávkové provádění)	SQLServerException, jehož číslo chyby odpovídá nakonfigurovanému pravidlu příkazu
Selhání počátečního připojení nebo ověřování	retryConn	Uvnitř smyčky ovladače pro opakované pokusy o připojení (která je řízena prvky connectRetryCount a loginTimeout)	SQLServerException během ověřování s číslem chyby, které odpovídá nakonfigurovanému pravidlu připojení, nebo ve výchozím nastavení jakákoli přechodná chyba zahrnutá v integrovaném seznamu opakovaných pokusů

U příkazů ovladač zopakuje pouze příkaz, který selhal. Ovladač neobnoví aktuální stav transakce, takže navrhněte pravidla s ohledem na chyby, po kterých zůstane relace použitelná, například oběť uváznutí (1205) nebo vypršení časového limitu uzamčení (1222).

Pro připojení CRL rozšiřuje nebo nahrazuje integrovaný seznam přechodných chyb připojení v ovladači. Viz Pravidla opakování připojení pro + sémantiku předpony.

Povolit CRL

CRL má dvě vrstvy:

1. Vrstva opakování připojení je ve výchozím nastavení zapnutá: pokud connectRetryCount > 0 (výchozí hodnota je 1), ovladač opakuje předdefinovaný seznam chyb přechodných připojení.
2. Vrstva přizpůsobení (vaše vlastní retryExec a retryConn pravidla) je ve výchozím nastavení vypnutá. Obě vlastnosti jsou prázdné řetězce, pokud je nenastavíte. Můžete je nastavit pomocí adresy URL JDBC, objektu Properties nebo objektu SQLServerDataSource. Ovladač odstraní volitelné obaly {...} ve všech třech formách.

Ukázky kódu v jazyce Java v tomto článku kvůli stručnosti vynechávají importy a obalení tříd.

V adrese URL JDBC

Každé pravidlo (nebo celý seznam pravidel) musí být zabalené do složených závorek ({...}), protože adresa URL JDBC se používá ; jako oddělovač:

jdbc:sqlserver://server;databaseName=db;retryExec={1205,1222:3,2*2:select,update}
jdbc:sqlserver://server;databaseName=db;retryConn={+<customErrorNumber>}

S objektem Properties

Properties props = new Properties();
props.setProperty("user", "...");
props.setProperty("password", "...");
props.setProperty("retryExec", "1205,1222:3,2*2:select,update");
props.setProperty("retryConn", "+<customErrorNumber>");
Connection c = DriverManager.getConnection("jdbc:sqlserver://server;databaseName=db", props);

S SQLServerDataSource

Stejné settery existují v ISQLServerDataSource rozhraní:

SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("server");
ds.setDatabaseName("db");
ds.setRetryExec("1205,1222:3,2*2:select,update");
ds.setRetryConn("+<customErrorNumber>");

Syntaxe pravidla

Jedno pravidlo má až tři oddíly oddělené dvojtečkami:

<errorNumbers> : <retryTimings> : <queryFilter>

Oddíl	Povinné?	Význam
errorNumbers	Ano	Jedno číslo chyby SQL Serveru nebo několik čísel oddělených čárkami (například 1205 nebo 1205,1222). U pravidel připojení volitelný úvodní prvek + určuje, zda se stávající přechodné chyby zachovají.
retryTimings	Požadováno pro pravidla příkazů . Vynechání pravidel připojení.	retryCount[,initialRetryTime[<op>retryChange]] kde <op> je + (součinitel) nebo * (multiplikativní).
queryFilter	Volitelné, pouze pravidla pro příkazy	Čárkami oddělený seznam klíčových slov SQL Ovladač při parsování převádí hodnotu na malá písmena a za běhu převádí na malá písmena i dříve spuštěný příkaz SQL. Pravidlo se aktivuje, když připojený seznam filtrů obsahuje první token spuštěného SQL. Pokud chcete filtrování zakázat, vynecháte třetí část.

Pokud chcete použít více pravidel ve stejné vlastnosti, oddělte je ; a zabalte je {...} při jejich umístění do adresy URL JDBC.

Parametry časování

Pro pravidlo příkazu s časováním retryCount, initialRetryTime <op> retryChange:

• retryCount: Počet dalších pokusů, které ovladač provede po prvním selhání. Hodnota 0 zakáže opakování. Záporné hodnoty jsou neplatné.
• initialRetryTime: Počet sekund čekání před prvním opakováním. Výchozí hodnota je 0.
• <op>: Operátor, který může být + nebo *. Výchozí hodnota je +.
• retryChange: Částka použitá pro výpočet následných dob čekání. Výchozí hodnota je 2. Pokud je operandem * a retryChange je v pravidle vynechán, ovladač nastaví retryChange = initialRetryTime.

Important

Pokud zadáte initialRetryTime bez explicitního operandu (například 3,5), ovladač použije výchozí hodnoty pro operand a retryChange (+ a 2). Čekání nejsou konstantní. Zvyšují se o 2 s každým opakováním. Pokud chcete získat konstantní čekání, použijte explicitní formulář retryCount,N+0 (například 3,5+0).

Ovladač vypočítá dobu čekání na pokus i (0) v době analýzy:

Operand	Počkejte na pokus i
+ (aditivní)	initialRetryTime + (retryChange * i)
* (multiplikativní)	initialRetryTime * (retryChange ^ i)

Příklady řetězců časování:

Řetězec	retryCount	initialRetryTime	operand	retryChange	Posloupnost čekání (sekundy)
3	3	0 (výchozí)	+ (výchozí)	2 (výchozí)	0, 2, 4
3,5	3	5	+ (výchozí)	2 (výchozí)	5, 7, 9
3,5+5	3	5	+	5	5, 10, 15
3,2*2	3	2	*	2	2, 4, 8
4,1*	4	1	*	1 (rovná se initialRetryTime , protože operand je * a retryChange je vynechán)	1, 1, 1, 1

Sekce retryTimings může obsahovat nejvýše jednu čárku. Více než jedna čárka vyvolává R_invalidParameterNumber.

Pravidla pro opakování příkazu (retryExec)

Pravidla pro příkazy umožňují opakovat spuštění neúspěšného příkazu. Když příkaz vyvolá výjimku SQLServerException, ovladač:

1. Vyhledá číslo chyby způsobující selhání v sadě pravidel pro analyzovaný příkaz.
2. Pokud pravidlo existuje a aktuální počet pokusů je menší než retryCount, volitelně zkontroluje naposledy spuštěný SQL proti pravidlu queryFilter.
3. Pokud se vše shoduje, ovladač počká několik waitTimes[retryAttempt] sekund (v závislosti na queryTimeout, viz Interakce s queryTimeout a connectRetryCount) a znovu spustí příkaz.
4. Pokud žádné pravidlo neodpovídá, ovladač znovu vyvolá výjimku.

Formát (příkazy)

{errorNumber(s):retryCount[,initialRetryTime[<op>retryChange]][:queryFilter]}

Pravidla příkazů musí obsahovat sekci časování. retryCount je povinné. Pravidlo, které obsahuje pouze číslo chyby, se interpretuje jako pravidlo připojení , takže pro příkazy vždy zadejte alespoň retryCount.

Příklady (příkazy)

Rule	Účinek
{1205:3}	Zopakujte oběť vzájemného zablokování (1205) až 3krát, nečekejte mezi opakovanými pokusy.
{1205,1222:3,5+5}	V případě ukončení operace kvůli uváznutí nebo vypršení časového limitu zámku opakujte pokus až 3krát s čekáním 5, 10 a 15 sekund.
{2714:2,1*2}	Opakujte akci "objekt již existuje" až 2krát a počkejte 1 a 2 sekundy.
{1205:4,2+2:select,update}	Opakujte pouze tehdy, když příkaz, který selhal, začíná na select nebo update.
{1205:3,5+5};{1222:2,2}	Dvě nezávislá pravidla, oddělená ;.

Uvedení několika čísel chyb (například 1205,1222) je zkrácený způsob zápisu. Ovladač rozvine pravidlo na jednu položku pro každou chybu, přičemž všechny sdílejí stejné časování a filtr dotazů.

Pravidla opakování připojení (retryConn)

Pravidla připojení fungují spolu se stávající smyčkou opakovaných pokusů o připojení. Tato smyčka je aktivní, pouze pokud connectRetryCount > 0 (výchozí hodnota je 1). Smyčka již opakuje předdefinovaný seznam přechodných chyb připojení v connectRetryInterval sekundách od sebe, až po connectRetryCount další pokusy a je vázán loginTimeout.

Pravidlo připojení poskytuje pouze část s číslem chyby. Nemá žádné časování ani filtr dotazů:

{[+]errorNumber(s)}

• Bez +, nakonfigurovaná pravidla nahradí vestavěný seznam přechodných chyb. Opakovat se budou jenom chyby, které vypíšete.
• Při + použití (například {+4060}) se nakonfigurovaná pravidla přidají do integrovaného seznamu. Chyby i výchozí nastavení ovladače se opakují.

Režim nahrazení nebo přidání je globální pro celou hodnotu retryConn. Pokud některé pravidlo v této hodnotě vynechá +, ovladač přepne na nahrazení režimu pro všechna pravidla v této hodnotě. Například retryConn={+4060};{40143} nepřidá 4060 a 40143 k integrovanému seznamu. Pravidlo 40143 vynechá +, takže předdefinovaný seznam se vynechá a bude se opakovat pouze 4060 a 40143. Pokud chcete připojit obojí, zapsat retryConn={+4060};{+40143} (nebo retryConn={+4060,40143}).

Smyčka připojení nadále používá connectRetryInterval a connectRetryCount k řízení tempa a ohraničení. Pravidlo CRL rozšiřuje nebo nahrazuje sadu chyb, které lze zkusit znovu.

Příklady (připojení)

Rule	Účinek
{+<customErrorNumber>}	Přidejte vlastní číslo chyby do integrovaného seznamu přechodných chyb.
{+<customError1>,<customError2>}	Přidejte do integrovaného seznamu přechodných chyb několik vlastních čísel chyb.
{4060}	Opakovat pouze chybu 4060. Vestavěné přechodné chyby již nejsou systémem CRL znovu zpracovávány.

Note

retryConn nemění loginTimeout sémantiku. Stávající smyčka opakovaných pokusů o připojení stále omezuje celkovou uplynulou dobu a ukončí pokusy dříve, pokud by další connectRetryInterval posunul uplynulý čas za loginTimeout.

Integrovaný seznam chyb přechodných připojení

Smyčka opakovaných pokusů o připojení již opakuje následující chyby i bez jakékoli konfigurace CRL, pokud connectRetryCount > 0. Vypsání kterékoli z těchto chyb v pravidle retryConn s + nemá žádný efekt (jsou již zahrnuté). retryConn Pravidlo použijte, když potřebujete přidat chybu, která není v tomto seznamu, nebo když potřebujete seznam úplně odstranit pomocí formuláře typu no-replace+.

Note

Nemusíte přidávat běžné přechodné chyby připojení Azure SQL, jako jsou 40197, 40501, 40613, 49918, 49919 nebo 49920. Předdefinovaný seznam už je opakuje.

Error	Message	Troubleshooting
64	Připojení bylo úspěšně navázáno se serverem, ale během procesu přihlášení došlo k chybě. (zprostředkovatel: Zprostředkovatel TCP, chyba: 0 – Zadaný název sítě už není k dispozici.)	Spojení TCP bylo přerušeno během navazování spojení. Nejedná se o selhání přihlašovacích údajů. Pokud problém přetrvává, zkontrolujte, zda není síť na straně klienta nestabilní, zda se nevyskytují chyby funkce offload síťové karty nebo zda některé mezilehlé zařízení neukončuje napůl navázaná spojení.
233	Klient nemohl navázat připojení kvůli chybě během procesu inicializace připojení před přihlášením.	Přenos před přihlášením nebo selhání protokolu TLS Server to obvykle vrátí, když nemůže přijmout připojení (vyčerpání prostředků, dosažení maximálního počtu připojení nebo nepodporovaného klienta). Nejedná se o selhání přihlašovacích údajů. Ověřte stav serveru a potom zkontrolujte loginTimeout, nastavení TLS a kompatibilitu verzí TLS klienta a serveru.
4060	Nelze otevřít databázi database_name požadovanou přihlášením. Přihlášení se nezdařilo.	Přihlášení se ověřilo, ale požadovanou databázi se nepodařilo otevřít. Mezi přechodné příčiny patří to, že databáze je ve stavu přechodu (převzetí služeb při selhání, obnovení nebo navýšení kapacity) nebo je automaticky pozastavená. Trvalé příčiny (databáze neexistuje, chybějící přístup k přihlášení) nebudou opraveny opakovaným pokusem; zkontrolujte název databáze, mapování přihlášení a stav databáze.
4221	Přihlášení k read-secondary selhalo kvůli dlouhému čekání na HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING.	Sekundární replika pro čtení nemohla přijmout přihlášení, protože při restartování repliky stále chyběly verze řádků z probíhajících transakcí. Tomu lze předejít tím, že se na primárním serveru vyhnete dlouhým zapisovacím transakcím; opakovaný pokus obvykle uspěje, jakmile primární server otevřené transakce potvrdí nebo vrátí zpět.
10053	Při odesílání žádosti na server došlo k chybě na úrovni přenosu. (zprostředkovatel: Zprostředkovatel TCP, chyba: 0 – Navázání připojení bylo přerušeno softwarem v hostitelském počítači.)	místní strana ukončila spojení (Windows Sockets WSAECONNABORTED). Jde často o selhání mechanismu keepalive nebo o ukončení nečinného nebo polootevřeného připojení místním síťovým zásobníkem. Zkontrolujte stav síťového připojení na straně klienta, časovače keepalive v operačním systému a případný místní firewall nebo klienta VPN.
10054	Při odesílání žádosti na server došlo k chybě na úrovni přenosu. (zprostředkovatel: Zprostředkovatel TCP, chyba: 0 – Existující připojení bylo vynuceně uzavřeno vzdáleným hostitelem.)	vzdálená strana odeslala TCP reset (Windows Sockets WSAECONNRESET). Běžné příčiny: partnerský proces selhal, brána firewall vynutila reset spojení nebo brána Azure SQL ukončila nečinné připojení. U resetování při nečinnosti povolte na klientovi mechanismus TCP keepalive nebo zkraťte časový limit nečinnosti fondu připojení.
10928	ID prostředku: N. Limit typu limitu pro databázi je N a byl dosažen. Použití viz sys.dm_exec_sessions.	Byl dosažen limit správy prostředků v databázi (relace, pracovní procesy nebo požadavky). Určete typ limitu z hlášení a pak snižte souběžnost, navyšte kapacitu databáze nebo zkraťte dlouhotrvající operace, které blokují prostředek.
10929	ID prostředku: N. Minimální záruka typu limitu je N, maximální limit je N a aktuální využití databáze je N. Server je ale momentálně příliš zaneprázdněný na podporu požadavků větších než N pro tuto databázi.	Databáze překračuje své garantované minimum a podkladový server omezuje výkon. Opakování obvykle proběhne úspěšně při poklesu zatížení souseda. Trvalé výskyty značí, že potřebujete vyšší úroveň služby nebo méně hlučné prostředí.
40020 40143 40166 40540	Hlášeno v slotu Error code %d chyby 40197 během převzetí služeb při selhání.	Dílčí kódy obsažené ve zprávě o převzetí služeb při selhání 40197 se v některých případech zobrazují jako chybový kód nejvyšší úrovně. Ovladač každý z nich vypíše jednotlivě, aby se opakovaně opakuje v obou formulářích. Zachází s nimi stejně jako s 40197.
40197	Služba zjistila chybu při zpracování vaší žádosti. Zkuste to prosím znovu. Kód chyby N.	Aktualizace softwaru, selhání hardwaru nebo jiná událost převzetí služeb při selhání ve službě Azure SQL. Po opětovném připojení budete přesměrováni na zdravou repliku. Obsažený kód chyby určuje typ přepnutí při selhání. Opakované výskyty by měly být hlášeny spolu s ID trasování relace.
40501	Služba je aktuálně zaneprázdněna. Zkuste požadavek zopakovat po 10 sekundách. ID incidentu: guid. Kód: N.	Azure SQL omezování motoru. Doporučené minimum je prodleva 10 sekund. Trvalé omezování výkonu znamená, že jste překročili přidělenou kapacitu DTU/vCore; navyšte výkon nebo snižte souběžnost.
40613	Databáze database_name na serveru server_name není aktuálně dostupná. Opakujte pokus o připojení později. Pokud problém přetrvává, obraťte se na zákaznickou podporu a uveďte jim ID trasování relace guid.	Databáze není dostupná, obvykle během převzetí služeb při selhání nebo krátce během škálování. Opakujte pokus s postupně prodlužovaným intervalem; pokud problém přetrvává déle než několik minut, zaznamenejte ID trasování relace a vytvořte požadavek na podporu.
42108	Nejde se připojit k fondu SQL, protože je pozastavený. Obnovte provoz fondu SQL a zkuste to znovu.	Vyhrazený fond SQL (Synapse) je pozastavený. Opakování pomáhá pouze v případě, že se něco paralelně obnoví ve fondu. Fond obnovte ručně nebo úlohu naplánujte až po obnovení.
42109	Fond SQL se otepluje. Zkuste to prosím znovu.	Vyhrazený fond SQL se obnovuje. Opakujte pokus v postupně se prodlužujících intervalech, dokud nebude online; inicializace obvykle trvá několik minut.
49918	Požadavek nejde zpracovat. Nedostatek prostředků pro zpracování požadavku.	Control plane momentálně nemohl přidělit prostředky pro tento požadavek. Zkuste to znovu po prodlevě. Trvalé výskyty označují regionální tlak na kapacitu.
49919	Nelze zpracovat žádost o vytvoření nebo aktualizaci. Probíhá příliš mnoho operací vytváření nebo aktualizace pro předplatné N.	Limit souběžnosti operací správy na úrovni předplatného Omezte souběžná volání pro vytvoření nebo aktualizaci, nebo je rozložte v čase.
49920	Požadavek nejde zpracovat. Příliš mnoho probíhajících operací pro předplatné N.	Limit souběžnosti probíhajících operací na úrovni předplatného. Snižte míru paralelismu nebo počkejte, až probíhající operace doběhnou.

Kanonický seznam ovladače je výčet TransientError v SQLServerError.java. Text chybové zprávy je převzat z přechodných chyb připojení Azure SQL. Chyby na úrovni jednotlivých příkazů (například chyba 1205 – oběť deadlocku – nebo chyba 1222 – časový limit požadavku na uzamčení) v tomto seznamu nejsou, protože smyčka opakovaných pokusů o připojení se spouští pouze při počátečním připojení. Pokud chcete tyto chyby zopakovat, použijte retryExec pravidlo.

Načtení pravidel ze souboru vlastností

Pokud u připojení nenastavíte retryExec nebo retryConn, CRL vyhledá soubor s názvem mssql-jdbc.properties vedle souboru JAR ovladače na classpath. Soubor používá základní key=value analýzu. Řádky, které začínají na retryExec= nebo retryConn=, jsou rozpoznány. Hodnoty mají stejnou syntaxi, jaká je popsána v tomto článku, přičemž k oddělení více pravidel slouží ;.

Použijte přesné názvy klíčů (retryExec a retryConn) bez úvodního prázdného znaku. Soubor není analyzován jako úplný soubor vlastností Java. Ovladač doslovně kontroluje startsWith na každém řádku, takže:

• Řádky, které začínají na # nebo jakýkoli jiný prefix než retryExec/retryConn, se ignorují.
• Řádky, jejichž klíč začíná pouze na retryExec nebo retryConn (například retryExec2=...), jsou považovány za odpovídající vlastnost a mohou způsobit chyby při analýze. Nezavedávejte vlastní varianty.

Příklad mssql-jdbc.properties:

retryExec=1205:3,5+5;1222:2,2
retryConn=+4060,40143

Pokud soubor chybí, CRL zaznamená zprávu FINE v loggeru com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic a pokračuje bez pravidel. Do zprávy protokolu je zahrnuta cesta k souboru použitému pro vyhledávání.

Hodnoty připojovacího řetězce mají přednost. Pokud retryExec nebo retryConn nejsou v připojení prázdné, ovladač pro tuto vlastnost nenahlíží do souboru.

Chování aktualizace pravidel

CRL spravuje jedinou sadu pravidel v rámci celé JVM. Po konstrukci ovladač aktualizuje pravidla laziálně:

• Ovladač vyhodnocuje příležitosti aktualizace během provádění příkazů a opakování připojení.
• Aktualizace se skutečně provede až po uplynutí 30 sekund od předchozího čtení.
• Pokud pravidla původně pocházela z mssql-jdbc.properties, ovladač porovná časové razítko poslední změny souboru s časovým razítkem, které zaznamenal při předchozím čtení. Pokud se soubor změnil, ovladač ho znovu analyzuje.
• Pokud pravidla původně pocházejí z připojovací řetězec, ovladač znovu zobrazí dříve uloženou hodnotu připojovacího řetězce.

Toto chování znamená, že se úpravy v mssql-jdbc.properties automaticky projeví přibližně do 30 sekund, aniž by bylo nutné restartovat aplikaci.

Important

Protože je sada pravidel singleton pro celou JVM, otevření druhého připojení, které nastaví jinou hodnotu retryExec nebo retryConn, nahradí pravidla i pro první připojení. Konfiguraci CRL považujte za nastavení na úrovni procesu, nikoli za nastavení pro jednotlivá připojení, pokud se více připojení v rámci stejné JVM rozchází.

Interakce s queryTimeout a connectRetryCount

Opakování příkazů a queryTimeout

Když se aktivuje pravidlo příkazu, ovladač porovná další dobu čekání s hodnotou na úrovni queryTimeout připojení:

• Pokud queryTimeout >= 0atimeToWait > queryTimeout, ovladač vyvolá R_InvalidRetryInterval místo opětovného pokusu. Ovladač znovu nevyvolá původní chybu. Vyvolá chybu konfigurace.
• Vlastnost připojení queryTimeout má výchozí hodnotu -1, takže se porovnání ve výchozím nastavení přeskočí a je povoleno libovolné čekání.
• Nastavení queryTimeout=0tuto kontrolu nezakáže , protože 0 >= 0 je pravdivé. Jakýkoli timeToWait > 0 zvyšuje R_InvalidRetryInterval.

Když nastavíte queryTimeout na kladnou hodnotu, ponechte hodnotu initialRetryTime + (retryCount - 1) * retryChange (aditivní) nebo initialRetryTime * retryChange^(retryCount-1) (multiplikativní) pod ní.

Opakované pokusy o připojení a connectRetryCount a loginTimeout

retryConn sama o sobě neumožňuje opakované pokusy o ověření. Stávající vlastnosti zůstávají beze změny:

• connectRetryCount (výchozí hodnota 1, rozsah 0–255) je počet dalších pokusů o ověření. Nastavte hodnotu na 0, aby se zakázalo opakování pokusů o ověření. retryConn nemá žádný vliv, protože connectRetryCount = 0ovladač vyvolá při prvním selhání.
• connectRetryInterval (výchozí 10 sekund, rozsah 1–60) je čekání mezi pokusy. První opakování se spustí okamžitě.
• loginTimeout je celková mez. Ovladač se ukončí předčasně, pokud by další interval posunul uplynulý čas za loginTimeout.

Další informace najdete v tématu Odolnost připojení (JDBC)

Examples

Přežít zablokování a vypršení časových limitů uzamčení při zápisech

jdbc:sqlserver://server;databaseName=db;retryExec={1205,1222:4,2*2:insert,update,delete,merge}

Až čtyři opakované pokusy při deadlocku (1205) nebo vypršení časového limitu zámku (1222), s prodlevou 2, 4, 8 a 16 sekund, ale pouze pro zápisové příkazy.

Opětovné spuštění vytváření schématu v rámci online operací

retryExec={2714:2,1+1};{3702:2,1+1}

Opakování chyby 2714 (object already exists) a 3702 (cannot drop database currently in use) dvakrát po sobě, s 1 a 2 sekundami čekání.

Přidání vlastní chyby do seznamu přechodných chyb

retryConn={+<customErrorNumber>}

Přidá vlastní číslo chyby, které ještě není v integrovaném seznamu. Pokud přidáte předdefinovanou přechodnou chybu Azure SQL, například 40197, 40501, 40613, 49918, 49919 nebo 49920, nic se nezmění, protože ovladač už její opakování provádí automaticky.

Nakonfigurujte CRL pomocí souboru vlastností

Umístěte mssql-jdbc.properties vedle souboru JAR ovladače:

retryExec=1205:3,5+5:select,update
retryConn=+<customErrorNumber>

Nenastavujte retryExec ani retryConn na připojení. Ovladač čte pravidla ze souboru a po každé změně je znovu načte (kontrolováno každých 30 sekund).

Řešení potíží s CRL

Povolte protokolování FINE (nebo podrobnější) u protokolovače com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic, aby se zobrazily pokusy o čtení souborů a rozhodnutí při parsování:

com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.level=FINE

Běžné chyby konfigurace:

Klávesa s chybovou zprávou	Příčina
R_invalidParameterNumber	Objevil se nečíselný token, ve kterém ovladač očekával číslo chyby nebo parametr časování nebo retryTimings obsahoval více než jednu čárku.
R_InvalidRuleFormat	Pravidlo mělo více než 3 části oddělené dvojtečkami.
R_InvalidRetryInterval	Vypočítaná doba čekání pravidla příkazu překračuje queryTimeout. Zkraťte dobu čekání nebo zvyšte queryTimeout.
R_PathInvalid nebo R_URLInvalid	Ovladač nemohl najít cestu, kde hledat mssql-jdbc.properties.
R_errorReadingStream	Vstupně-výstupní chyba při čtení mssql-jdbc.properties.

Note

Text zprávy R_invalidParameterNumber zní Číslo parametru {0} není platné, což je stejný řetězec prostředku, který ovladač používá pro chyby při vázání parametrů připravených příkazů. Pokud ji vyvolá CRL, problematickou hodnotou je token vašeho pravidla opakování (například číslo chyby nebo časový prvek, který není číselný), nikoli index parametru PreparedStatement.

Co je potřeba zkontrolovat, když se pravidlo neaktivuje:

1. Výjimka SQLServerError.getErrorNumber() ve skutečnosti odpovídá číslu ve vašem pravidlu. SQL Server může zabalit některá selhání do různých čísel v závislosti na kontextu (například zablokování nebo vypršení časového limitu uzamčení).
2. Pro pravidla příkazů s queryFilter je v seznamu filtrů první token oddělený bílými znaky z SQL, které jste spustili, převedený na malá písmena. Komentáře a WITH výrazy CTE mění první token.
3. retryCount opakované pokusy jsou další pokusy. První spuštění se nepočítá.
4. Pro pravidla připojení je connectRetryCount větší než 0 a loginTimeout ponechá prostor alespoň pro jeden více connectRetryInterval.
5. Pravidlo má správný tvar. Pravidla příkazů musí obsahovat sekci časování. Pravidla připojení nesmějí.

Související obsah

• Odolnost připojení (JDBC)
• Pochopení vlastností časových limitů v ovladači JDBC
• Nastavení vlastností připojení
• Diagnostika problémů s ovladačem JDBC