Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
JDBC sürücüsünü indirin
Yapılandırılabilir yeniden deneme mantığı (CRL), denetlediğiniz zamanlama parametreleriyle seçtiğiniz SQL Server hata numaralarını temel alarak başarısız deyimleri veya ilk bağlantı girişimlerini otomatik olarak yeniden deneyen kural tabanlı bir mekanizmadır. CRL, SQL Server için Microsoft JDBC Sürücüsü 12.10'da tanıtıldı.
CRL, boşta bağlantı dayanıklılığından ve connectRetryCount / connectRetryInterval özelliklerinden ayrıdır. Boştayken dayanıklılık, kopan bağlantıları şeffaf bir şekilde yeniden kurar ve connectRetryCount yerleşik geçici hata listesinde yer alan hatalar için ilk kimlik doğrulamayı sabit aralıklarla yeniden dener. CRL , hangi hataların yeniden denenebileceğine, kaç kez ve denemeler arasında ne kadar bekleyebileceğinize karar vermenizi sağlar. Üç mekanizmayı da birlikte kullanabilirsiniz.
Hangi CRL yeniden denenir?
CRL, her biri kendi bağlantı özelliği tarafından denetlenen iki ayrı senaryo işler:
| Scenario | Mülkiyet | Yeniden deneme çalıştırıldığında | Tetikleyen |
|---|---|---|---|
| Komut çalıştırma hatası | retryExec |
Bir ifadeyi yürütürken (örneğin, executeQuery, executeUpdate, execute veya toplu yürütme) |
Hata numarası yapılandırılmış bir deyim kuralıyla eşleşen bir SQLServerException |
| İlk bağlantı veya kimlik doğrulama hatası | retryConn |
Sürücünün bağlantı yeniden deneme döngüsünün içinde (connectRetryCount ve loginTimeout tarafından denetlenen) |
Kimlik doğrulaması sırasında, hata numarası yapılandırılmış bir bağlantı kuralıyla eşleşen bir SQLServerException veya varsayılan olarak, yerleşik yeniden deneme listesinde zaten yer alan herhangi bir geçici hata |
İfadelerde sürücü yalnızca başarısız olan komutu yeniden dener. Sürücü geçerli işlem durumunu sıfırlamaz; bu nedenle kurallarınızı, deadlock kurbanı (1205) veya kilit zaman aşımı (1222) gibi oturumun kullanılabilir kalmasını sağlayan hataları göz önünde bulundurarak tasarlayın.
Bağlantılar açısından CRL, sürücünün yerleşik geçici bağlantı hataları listesini genişletir veya onun yerine geçer. Ön ek semantiği için bkz. +.
CRL'yi etkinleştirme
CRL'nin iki katmanı vardır:
- Bağlantı yeniden deneme katmanı varsayılan olarak açıktır: (varsayılan değer 1 olduğu sürece
connectRetryCount > 0), sürücü yerleşik geçici bağlantı hata listesini yeniden dener. - Özelleştirme katmanı (kendi
retryExecveretryConnkurallarınız) varsayılan olarak kapalıdır. Her iki özellik de siz ayarlamadığınız sürece boş dizelerdir. Bunları JDBC URL'si, birPropertiesnesnesi veya birSQLServerDataSourcearacılığıyla ayarlayabilirsiniz. Sürücü, isteğe bağlı{...}sarmalayıcılarını her üç biçimde de kaldırır.
Bu makaledeki Java kod parçacıklarında, kısa tutmak amacıyla import ifadeleri ve sınıf tanımları çıkarılmıştır.
JDBC URL'sinde
JDBC URL’si ayırıcı olarak ; kullandığı için her kural (veya kuralların tamamı) küme parantezleri ({...}) içine alınmalıdır:
jdbc:sqlserver://server;databaseName=db;retryExec={1205,1222:3,2*2:select,update}
jdbc:sqlserver://server;databaseName=db;retryConn={+<customErrorNumber>}
Bir Properties nesne ile
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);
SQLServerDataSource ile
Aynı setter metotları ISQLServerDataSource arabiriminde de mevcuttur:
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("server");
ds.setDatabaseName("db");
ds.setRetryExec("1205,1222:3,2*2:select,update");
ds.setRetryConn("+<customErrorNumber>");
Kural söz dizimi
Tek bir kural, iki nokta üst üste ile ayrılmış en fazla üç bölüm içerebilir:
<errorNumbers> : <retryTimings> : <queryFilter>
| Bölüm | Gerekli mi? | Meaning |
|---|---|---|
errorNumbers |
Yes | Bir SQL Server hata numarası veya virgülle ayrılmış birkaç hata numarası (örneğin, 1205 veya 1205,1222). Bağlantı kuralları için, isteğe bağlı bir öncü + mevcut geçici hataların tutulup tutulmayacağını denetler. |
retryTimings |
İfade kuralları için gereklidir. Bağlantı kuralları için hariç tut. |
retryCount[,initialRetryTime[<op>retryChange]] burada <op>, + (toplamsal) veya * (çarpımsal) olur. |
queryFilter |
İsteğe bağlı, yalnızca komut kuralları | SQL anahtar sözcüklerinin virgülle ayrılmış listesi. Sürücü, ayrıştırma zamanında değeri küçük harfe dönüştürür ve çalışma zamanında daha önce yürütülen SQL'i küçük harfe dönüştürür. Kural, birleştirilmiş filtre listesi yürütülen SQL'in ilk belirtecini içerdiğinde tetiklenir. Filtrelemeyi devre dışı bırakmak için üçüncü bölümü atlar. |
Aynı özellikte birden çok kural kullanmak için, bunları ; ile ayırın ve bir JDBC URL’sine yerleştirirken her kuralı {...} ile çevreleyin.
Zamanlama parametreleri
retryCount, initialRetryTime <op> retryChange zamanlamalarına sahip bir ifade kuralı için:
-
retryCount: Sürücünün ilk hatadan sonra yaptığı ek deneme sayısı.0değeri yeniden denemeyi devre dışı bırakır. Negatif değerler geçersiz. -
initialRetryTime: İlk yeniden denemeden önce bek için saniye sayısı.0varsayılan değerdir. -
<op>:+veya*olabilen işleç.+varsayılan değerdir. -
retryChange: Sonraki bekleme sürelerini hesaplamak için uygulanan tutar.2varsayılan değerdir. İşlenen*olduğunda veretryChangekuralda belirtilmemişse, sürücüretryChange = initialRetryTimedeğerini ayarlar.
Important
initialRetryTime öğesini açık bir işlenen belirtmeden sağlarsanız (örneğin, 3,5), sürücü işlenen ve retryChange için varsayılan değerleri kullanır (+ ve 2). Beklemeler sabit değildir. Her yeniden denemede 2'şer artar. Sabit bekleme almak için açık formu retryCount,N+0 kullanın (örneğin, 3,5+0).
Sürücü, ayrıştırma zamanında i (0 tabanlı) denemesi için bekleme süresini hesaplar:
| İşlem terimi | Denemeyi bekle i |
|---|---|
+ (katkı maddesi) |
initialRetryTime + (retryChange * i) |
* (çarpımsal) |
initialRetryTime * (retryChange ^ i) |
Zamanlama dizelerine örnekler:
| Dize | retryCount | initialRetryTime | Işlenen | retryChange | Bekleme sırası (saniye) |
|---|---|---|---|---|---|
3 |
3 | 0 (varsayılan) |
+ (varsayılan) |
2 (varsayılan) | 0, 2, 4 |
3,5 |
3 | 5 |
+ (varsayılan) |
2 (varsayılan) | 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 (initialRetryTime'a eşittir, çünkü işlenen *'dir ve retryChange atlanmıştır) |
1, 1, 1, 1 |
Bir retryTimings bölüm en fazla bir virgül içerebilir. Birden fazla virgül R_invalidParameterNumber oluşturur.
Deyim yeniden deneme kuralları (retryExec)
İfade kuralları, başarısız ifade yürütmelerini yeniden dener. Bir ifade bir SQLServerException oluşturduğunda sürücü:
- Ayrıştırılmış deyim kural kümesinde başarısızlığa neden olan hata numarasını bulur.
- Bir kural varsa ve geçerli deneme sayısı değerinden
retryCountküçükse isteğe bağlı olarak son yürütülen SQL'i kuralınqueryFilterüzerinde denetler. - Her şey eşleşirse, sürücü
waitTimes[retryAttempt]saniye bekler (queryTimeout’e bağlı olarak; bkz. queryTimeout ve connectRetryCount ile etkileşim) ve deyimi yeniden çalıştırır. - Hiçbir kural eşleşmezse, sürücü istisnayı yeniden fırlatır.
Biçim (ifadeler)
{errorNumber(s):retryCount[,initialRetryTime[<op>retryChange]][:queryFilter]}
İfade kuralları, zamanlamalar bölümü içermelidir.
retryCount zorunludur. Yalnızca hata numarası içeren bir kural bağlantı kuralı olarak yorumlanır, bu nedenle deyimler için her zaman en az retryCountdeğerini sağlar.
Örnekler (deyimler)
| Kural | Etkisi |
|---|---|
{1205:3} |
Kilitlenme kurbanı (1205) 3 kereye kadar yeniden deneyin, yeniden denemeler arasında beklemeyin. |
{1205,1222:3,5+5} |
Deadlock kurbanı veya kilit zaman aşımı durumunda, 5, 10 ve 15 saniye bekleyerek en fazla 3 kez yeniden deneyin. |
{2714:2,1*2} |
"Nesne zaten var" seçeneğini 2 kez yeniden deneyin ve 1 ve 2 saniye bekleyin. |
{1205:4,2+2:select,update} |
Yalnızca başarısız olan ifade select veya update ile başladığında yeniden deneyin. |
{1205:3,5+5};{1222:2,2} |
; ile ayrılmış iki bağımsız kural. |
Birkaç hata numarasının listelenmesi (örneğin, 1205,1222) kısaltmadır. Sürücü, kuralı hata başına bir girdiye genişletir ve hepsi aynı zamanlamayı ve sorgu filtresini paylaşır.
Bağlantı yeniden deneme kuralları (retryConn)
Bağlantı kuralları mevcut bağlantı yeniden deneme döngüsüyle çalışır. Bu döngü yalnızca (varsayılan değer 1) olduğunda connectRetryCount > 0etkindir. Döngü, yerleşik bir geçici bağlantı hataları listesini zaten connectRetryInterval saniye arayla, en fazla connectRetryCount ek denemeye kadar yeniden dener ve loginTimeout ile sınırlandırılmıştır.
Bağlantı kuralı yalnızca bir hata numarası bölümü sağlar. Zamanlama veya sorgu filtresi yok:
{[+]errorNumber(s)}
- olmadan
+, yapılandırılmış kurallar yerleşik geçici hata listesinin yerini alır . Yalnızca listelediğiniz hatalar yeniden deneniyor. - ile
+(örneğin,{+4060}) yapılandırılan kurallar yerleşik listeye eklenir . Hem hatalarınız hem de sürücü varsayılanları yeniden deneniyor.
Değiştirme veya ekleme modu değerin tamamı retryConn için geneldir. Bu değerdeki herhangi bir kural atlanırsa +, sürücü bu değerdeki tüm kurallar için değiştirme moduna geçer. Örneğin, retryConn={+4060};{40143} yerleşik listeye 4060 ve 40143 eklemez.
40143 kuralı + öğesini hariç tutar, bu nedenle yerleşik liste çıkarılır ve yalnızca 4060 ile 40143 yeniden denenir. Her ikisini de eklemek için yazın retryConn={+4060};{+40143} (veya retryConn={+4060,40143}).
Bağlantı döngüsü, zamanlama ve sınırlandırma için connectRetryInterval ve connectRetryCount kullanmayı sürdürür. CRL kuralı, yeniden deneme için uygun olan hata kümesini genişletir veya değiştirir.
Örnekler (bağlantılar)
| Kural | Etkisi |
|---|---|
{+<customErrorNumber>} |
Yerleşik geçici hata listesine özel bir hata numarası ekleyin. |
{+<customError1>,<customError2>} |
Yerleşik geçici hata listesine birden çok özel hata numarası ekleyin. |
{4060} |
Yalnızca 4060 hatasını yeniden deneyin. Yerleşik geçici hatalar artık CRL tarafından yeniden denenmez. |
Note
retryConn semantiği değiştirmez loginTimeout . Mevcut bağlanma-yeniden deneme döngüsü yine toplam geçen süreyi sınırlar ve bir sonraki connectRetryInterval, geçen süreyi loginTimeout değerinin ötesine iteceği durumda erken vazgeçer.
Yerleşik geçici bağlantı hata listesi
Bağlantıyı yeniden deneme döngüsü, connectRetryCount > 0 olduğu sürece, herhangi bir CRL yapılandırması olmadan aşağıdaki hataları zaten yeniden dener.
+ ile bir retryConn kuralında bu hatalardan herhangi birini listelemek no-op'tur (bunlar zaten kapsanmaktadır). Bu listede yer almayan bir hata eklemeniz gerektiğinde veya no-+ replace biçimini kullanarak listeyi tamamen kaldırmanız gerektiğinde bir retryConn kuralı kullanın.
Note
40197, 40501, 40613, 49918, 49919 veya 49920 gibi yaygın Azure SQL geçici bağlantı hatalarını eklemeniz gerekmez. Yerleşik liste bunları zaten yeniden dener.
| Error | Message | Troubleshooting |
|---|---|---|
| 64 | Sunucuyla başarıyla bağlantı kuruldu ancak oturum açma işlemi sırasında bir hata oluştu. (sağlayıcı: TCP Sağlayıcısı, hata: 0 - Belirtilen ağ adı artık kullanılamıyor.) | TCP bağlantısı el sıkışma sırasında koptu. Kimlik bilgileriyle ilgili bir hata değil. Devam ederse, istemci tarafındaki ağ kararsızlığını, NIC offload hatalarını veya yarı kurulmuş bağlantıları düşüren bir ara cihaz olup olmadığını kontrol edin. |
| 233 | İstemci, oturum açmadan önce bağlantı başlatma işlemi sırasında oluşan bir hata nedeniyle bağlantı kuramadı. | Oturum açma öncesi aktarım veya TLS hatası. Sunucu genellikle bağlantıyı kabul etmediğinde (kaynak tükenmesi, maksimum bağlantılara ulaşılması veya desteklenmeyen bir istemci) bunu döndürür. Bu bir kimlik doğrulama hatası değil. Sunucu durumunu doğrulayın, ardından , TLS ayarlarını ve istemci/sunucu TLS sürüm uyumluluğunu denetleyin loginTimeout. |
| 4060 | Oturum açma işlemi tarafından istenen database_name veritabanı açılamıyor. Giriş başarısız oldu. | Oturum açma kimliği doğrulandı ancak istenen veritabanı açılamıyor. Geçici nedenler arasında veritabanının geçiş durumunda olması (yük devretme, geri yükleme, ölçek büyütme) veya otomatik olarak duraklatılmış olması yer alır. Kalıcı nedenler (veritabanı mevcut değil, oturum açma erişimi yok) yeniden denenerek düzeltilmez; veritabanı adını, oturum açma eşlemesini ve veritabanı durumunu denetleyin. |
| 4221 |
HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING üzerinde uzun süre beklenmesi nedeniyle read-secondary’ye oturum açma başarısız oldu. |
Okunabilir ikincil, replika yeniden başlatıldığında devam eden işlemler için satır sürümleri hâlâ mevcut olmadığından oturum açma isteğini kabul edemedi. Bunu, birincil düğümde uzun yazma işlemlerinden kaçınarak azaltabilirsiniz; birincil düğüm açık işlemleri onayladıktan veya geri aldıktan sonra yeniden deneme genellikle başarılı olur. |
| 10053 | Sunucuya istek gönderilirken taşıma düzeyinde bir hata oluştu. (sağlayıcı: TCP Sağlayıcısı, hata: 0 - Ana makinenizdeki yazılım tarafından kurulan bir bağlantı durduruldu.) |
yerel taraf bağlantıyı iptal etti (Windows Sockets WSAECONNABORTED). Genellikle bir keepalive hatası veya boşta ya da yarı açık bir bağlantıyı sonlandıran yerel ağ yığını. İstemci tarafındaki ağ sağlığını, işletim sistemi keepalive zamanlayıcılarını ve yerel güvenlik duvarı veya VPN istemcisini denetleyin. |
| 10054 | Sunucuya istek gönderilirken taşıma düzeyinde bir hata oluştu. (sağlayıcı: TCP Sağlayıcısı, hata: 0 - Var olan bir bağlantı uzak konak tarafından zorla kapatıldı.) |
uzak taraf bir TCP sıfırlama paketi gönderdi (Windows Sockets WSAECONNRESET). Yaygın nedenler: eş süreç çöktü, bir güvenlik duvarı bir sıfırlama paketi gönderdi veya Azure SQL ağ geçidi boşta olan bir bağlantıyı kapattı. Bağlantının boştayken sıfırlanması durumlarında, istemcide TCP keepalive’ı etkinleştirin veya bağlantı havuzundaki boşta kalma zaman aşımını kısaltın. |
| 10928 | Kaynak Kimliği: N. Veritabanı için sınır türü sınırı N'dir ve bu sınıra ulaşıldı. Kullanım için bkz sys.dm_exec_sessions . |
Veritabanında bir kaynak yönetimi sınırına (oturumlar, çalışanlar veya istekler) ulaşıldı. İletideki sınır türünü belirleyin, ardından eşzamanlılığı azaltın, veritabanının ölçeğini genişletin veya kaynağı tutan uzun süre çalışan işlemleri kısaltın. |
| 10929 | Kaynak Kimliği: N. Sınır türü en düşük garanti N, üst sınır N ve veritabanı için geçerli kullanım N'dir. Ancak, sunucu şu anda bu veritabanı için N'den büyük istekleri desteklemek için çok meşgul. | Veritabanı minimum garanti düzeyini aştı ve altyapıdaki sunucu kısıtlama uyguluyor. Yeniden deneme genellikle komşu yükü düştüğünde başarılı olur. Sürekli oluşumlar, daha yüksek bir hizmet katmanına veya daha az gürültülü bir ortama ihtiyacınız olduğunu gösterir. |
| 40020 40143 40166 40540 |
Yük devretme sırasında oluşan 40197 hatasının Error code %d alanında bildirildi. |
Bazı yolların üst düzey hata numarası olarak göründüğü 40197 yük devretme iletisine eklenmiş alt kodlar. Sürücü, her birini ayrı ayrı listeler; böylece iki biçimden herhangi birinde yeniden dener. Bunları 40197 ile aynı şekilde değerlendirin. |
| 40197 | Hizmet isteğinizi işlerken bir hatayla karşılaştı. Lütfen yeniden deneyin. Hata kodu N. | Azure SQL’de bir yazılım yükseltmesi, donanım arızası veya başka bir yük devretme durumu. Yeniden bağlanma sizi sağlıklı bir kopyaya yönlendirir. Eklenen hata kodu yük devretme türünü tanımlar. Kalıcı oluşumlar oturum izleme kimliğiyle bildirilmelidir. |
| 40501 | Hizmet şu anda yoğun. İsteği 10 saniye sonra yeniden deneyin. Olay Kimliği: guid. Kod: N. | Azure SQL motor azaltma. Önerilen minimum bekleme süresi 10 saniyedir. Sürekli kısıtlama, DTU/vCore kotasını aştığınızı gösterir; ölçeği büyütün veya eşzamanlılığı azaltın. |
| 40613 | Sunucu server_name veritabanı database_name şu anda kullanılamıyor. Lütfen bağlantıyı daha sonra yeniden deneyin. Sorun devam ederse müşteri desteğine başvurun ve guid'nin oturum izleme kimliğini sağlayın. | Veritabanı, genellikle yük devretme sırasında veya ölçeklendirme işlemi sırasında kısa bir süreliğine kullanılamaz. Artan aralıklarla yeniden deneyin; sorun birkaç dakikadan uzun sürerse oturum izleme kimliğini kaydedin ve bir destek kaydı oluşturun. |
| 42108 | Duraklatıldığı için SQL havuzuna bağlanılamadı. Lütfen SQL havuzunu devam ettirin ve yeniden deneyin. | Ayrılmış SQL havuzu (Synapse) duraklatılmış durumda. Yeniden deneme yalnızca bir şey havuzu eşzamanlı olarak yeniden etkinleştirirse yardımcı olur. Havuzu açıkça yeniden başlatın veya iş yükünü yeniden başlatmadan sonraya planlayın. |
| 42109 | SQL havuzu ısınıyor. Lütfen yeniden deneyin. | Ayrılmış SQL havuzu yeniden başlatılıyor. Çevrimiçi olana kadar geri çekilmeyi yeniden deneyin; ısınma genellikle birkaç dakika sürer. |
| 49918 | İsteği işlenemiyor. İsteği işlemek için kaynaklar yeterli değil. | Kontrol düzlemi şu anda istek için kaynak ayıramıyor. Geri alma işlemini yeniden deneyin. Kalıcı oluşumlar bölgesel kapasite baskısını gösterir. |
| 49919 | Oluşturma veya güncelleştirme isteği işlenemiyor. N aboneliği için çok fazla oluşturma veya güncelleştirme işlemi sürüyor. | Yönetim işlemlerinde abonelik düzeyinde eşzamanlılık sınırı. Paralel oluşturma/güncelleştirme çağrılarını azaltın veya bunları kademeleyin. |
| 49920 | İsteği işlenemiyor. N aboneliği için çok fazla işlem sürüyor. | Uçuştaki işlemlerde abonelik düzeyinde eşzamanlılık sınırı. Paralelliği azaltın veya uçuş içi işlemlerin boşalmasını bekleyin. |
Sürücünün kanonik listesi, SQLServerError.java içindeki TransientError enum’udur. Hata iletisi metni Azure SQL geçici bağlantı hatalarından kaynaklanır. Bağlantı yeniden deneme döngüsü yalnızca ilk bağlantı sırasında tetiklendiğinden, deyim düzeyi hatalar (kilitlenme kurbanı 1205 veya kilit isteği zaman aşımı 1222 gibi) bu listede yer almaz. Bu hataları yeniden denemek için bir retryExec kural kullanın.
Özellikler dosyasından kural yükleme
Bağlantıda retryExec veya retryConn ayarlanmazsa CRL, classpath'teki sürücü JAR dosyasının yanında mssql-jdbc.properties adlı bir dosya arar. Dosya temel key=value ayrıştırma kullanır.
retryExec= veya retryConn= ile başlayan satırlar algılanır. Değerler, bu makalede açıklanan söz dizimini kullanır; birden çok kuralı ayırmak için ; kullanılır.
Başta boşluk olmadan tam anahtar adlarını (retryExec ve retryConn) kullanın. Dosya, tam Java özellikleri dosyası olarak ayrıştırılamaz. Sürücü her satırda startsWith ifadesini birebir denetler, bu nedenle:
-
#ile başlayan veyaretryExec, / ya daretryConndışında başka bir ön ekle başlayan satırlar yok sayılır. - Anahtarı yalnızca
retryExecveyaretryConnile başlayan satırlar (örneğin,retryExec2=...) ilgili özellik olarak işleme alınır ve ayrıştırma hatalarına neden olabilir. Özel çeşitlemeler tanıtmayın.
Örnek mssql-jdbc.properties:
retryExec=1205:3,5+5;1222:2,2
retryConn=+4060,40143
Dosya eksikse, CRL com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic günlük kaydedicisinde FINE iletisini kaydeder ve hiç kural olmadan devam eder. Arama işlemi için kullanılan dosya yolu, söz konusu günlük iletisinde yer alır.
Bağlantı dizesi değerleri önceliklidir. Bağlantı üzerinde retryExec veya retryConn boş değilse, sürücü bu özellik için dosyaya başvurmaz.
Kural yenileme davranışı
CRL, JVM çapında tek bir kural kümesi bulundurur. İnşaat sonrasında, sürücü kuralları gevşek bir şekilde yeniler:
- Sürücü, ifade yürütme ve bağlantı yeniden denemeleri sırasında yenileme fırsatlarını değerlendirir.
- Yenileme aslında yalnızca önceki okumadan bu yana geçen 30 saniye sonra gerçekleşir.
- Kurallar başlangıçta adresinden
mssql-jdbc.propertiesgeliyorsa, sürücü dosyanın son değiştirilen zaman damgasını önceki okumada kaydettiği zaman damgasıyla karşılaştırır. Dosya değiştiyse, sürücü dosyayı yeniden ayrıştırıyor. - Kurallar başlangıçta bir bağlantı dizesinden geldiyse, sürücü önceden depolanan bağlantı dizesi değerini yeniden uygular.
Bu davranış, mssql-jdbc.properties üzerinde yapılan değişikliklerin uygulamayı yeniden başlatmadan yaklaşık 30 saniye içinde otomatik olarak algılandığı anlamına gelir.
Important
Kural kümesi JVM genelinde tekil olduğundan, farklı retryExec veya retryConn değer ayarlayan ikinci bir bağlantının açılması da ilk bağlantının kurallarının yerini alır. Aynı JVM'de birden çok bağlantının aynı fikirde olmadığı durumlarda CRL yapılandırmasını bağlantı başına değil işlem düzeyi ayarı olarak değerlendirin.
queryTimeout ve connectRetryCount ile etkileşim
Deyim yeniden denemeleri ve queryTimeout
Bir ifade kuralı tetiklendiğinde, sürücü bir sonraki bekleme süresini bağlantı düzeyindeki queryTimeout değeriyle karşılaştırır:
-
queryTimeout >= 0isetimeToWait > queryTimeout, sürücü yeniden denemek yerine yükseltirR_InvalidRetryInterval. Sürücü özgün hatayı yeniden oluşturmaz. Yapılandırma hatası verir. -
queryTimeoutBağlantı özelliği varsayılan olarak-1olarak ayarlanır, bu nedenle varsayılan olarak karşılaştırma atlanır ve beklemeye izin verilir. -
queryTimeout=0ayarı,0 >= 0doğru olduğundan bu denetimi devre dışı bırakmaz. Herhangi birtimeToWait > 0,R_InvalidRetryIntervalartırır.
queryTimeout değerini pozitif bir değere ayarladığınızda, initialRetryTime + (retryCount - 1) * retryChange (toplamsal) veya initialRetryTime * retryChange^(retryCount-1) (çarpımsal) değerini bunun altında tutun.
Bağlantı yeniden denemeleri ve connectRetryCount ve loginTimeout
retryConn kimlik doğrulaması yeniden denemelerini tek başına etkinleştirmez. Sorumluluk mevcut özelliklerde kalır:
-
connectRetryCount(varsayılan 1, aralık 0-255), ek kimlik doğrulama girişimlerinin sayısıdır. Kimlik doğrulama yeniden denemelerini devre dışı bırakmak için olarak0ayarlayın. Sürücü ilk hatada hata verdiğinden,connectRetryCount = 0olduğundaretryConnhiçbir etkiye sahip değildir. -
connectRetryInterval(varsayılan 10 saniye, aralık 1-60) denemeler arasındaki beklemedir. İlk yeniden deneme hemen gerçekleşir. -
loginTimeoutgenel sınırdır. Sıradaki aralık geçen süreyiloginTimeoutdeğerinin ötesine taşıyacaksa, sürücü erken durur.
Daha fazla bilgi için bkz . Bağlantı dayanıklılığı (JDBC).
Examples
Kilitlenmelerden kurtulup yazmalarda zaman aşımlarını kilitleyin
jdbc:sqlserver://server;databaseName=db;retryExec={1205,1222:4,2*2:insert,update,delete,merge}
Kilitlenme kurbanı (1205) veya kilit zaman aşımı (1222) için en fazla dört yeniden deneme, 2, 4, 8 ve 16 saniye geri alma ile, ancak yalnızca yazma ifadeleri için.
Çevrimiçi işlemler altında şema oluşturmayı yeniden çalıştırma
retryExec={2714:2,1+1};{3702:2,1+1}
2714 (object already exists) ve 3702 (cannot drop database currently in use) hata kodlarını her biri için iki kez, 1 ve 2 saniye bekleyerek yeniden dener.
Geçici hata listesine özel hata ekleme
retryConn={+<customErrorNumber>}
Yerleşik listede olmayan özel bir hata numarası ekler. 40197, 40501, 40613, 49918, 49919 veya 49920 gibi Azure SQL’in yerleşik geçici hatalarından birini sonuna eklerseniz, sürücü zaten bunu yeniden denediği için hiçbir şey değişmez.
CrL'yi özellikler dosyası aracılığıyla yapılandırma
mssql-jdbc.properties öğesini sürücü JAR dosyasının yanına yerleştirin:
retryExec=1205:3,5+5:select,update
retryConn=+<customErrorNumber>
Bağlantıda retryExec veya retryConn ayarlamayın. Sürücü, dosyadan kuralları okur ve her değişiklikten sonra yeniden okur (30 saniyede bir denetlendi).
CRL sorunlarını giderme
Dosya okuma girişimlerini ve ayrıştırma kararlarını görmek için, com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic günlüğünde FINE (veya daha ayrıntılı) günlük kaydını etkinleştirin:
com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.level=FINE
Yaygın yapılandırma hataları:
| Hata iletisi anahtarı | Cause |
|---|---|
R_invalidParameterNumber |
Sürücünün bir hata numarası veya zamanlama parametresi beklediği yerde sayısal olmayan bir belirteç ortaya çıktı ya da retryTimings birden fazla virgül içeriyordu. |
R_InvalidRuleFormat |
Kural, iki nokta üst üste ile ayrılan 3'ten fazla bölüm içeriyordu. |
R_InvalidRetryInterval |
Bir ifade kuralının hesaplanan bekleme süresi queryTimeout değerini aşıyor. Bekleme süresini kısaltın veya queryTimeout oluşturun. |
R_PathInvalid veya R_URLInvalid |
Sürücü, mssql-jdbc.properties öğesini aramak için bir yol belirleyemedi. |
R_errorReadingStream |
mssql-jdbc.properties okunurken G/Ç hatası oluştu. |
Note
İletinin R_invalidParameterNumber metni şu şekildedir : Parametre numarası {0} geçerli değil; bu, sürücünün prepared-statement parametre bağlama hataları için kullandığı kaynak dizesiyle aynıdır. CRL bunu attığında, sorunlu değer parametre dizini değil, yeniden deneme kuralı belirtecinizdir (örneğin, sayısal olmayan bir PreparedStatement hata numarası veya zamanlama öğesi).
Bir kural tetiklenmediğinde kontrol edilmesi gerekenler:
- Özel durum
SQLServerError.getErrorNumber()aslında kuralınızdaki sayıyla eşleşir. SQL Server bağlama bağlı olarak bazı hataları farklı sayılara kaydırabilir (örneğin, kilitlenme ve kilit zaman aşımı). -
queryFilteriçeren ifade kuralları için, çalıştırdığınız SQL'in boşlukla ayrılmış ilk belirteci (küçük harfe dönüştürülmüş hâli) filtre listesinde yer alır. Açıklamalar veWITHCTE'ler ilk belirteci değiştirir. -
retryCounttekrar denemeler ek denemelerdir. İlk yürütme sayılmaz. - Bağlantı kuralları için,
connectRetryCount0'dan büyüktür veloginTimeouten az birconnectRetryIntervaldaha yer bırakır. - Kural doğru şekle sahiptir. Deyim kurallarının bir zamanlamalar bölümüne ihtiyacı vardır. Bağlantı kuralları olmamalı.