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
Bağlantı dayanıklılığı , JDBC sürücüsünün bozuk boşta kalan bağlantıyı saydam bir şekilde geri yüklemesine ve başarısız olursa ilk bağlantıyı yeniden denemesine olanak tanır. Bu makale, bu davranışı denetleyen iki bağlantı dizesi özelliğini (connectRetryCount ve connectRetryInterval) ve sürücünün kesilen boşta bir bağlantıyı algılamak için kullandığı keepalive ayarlarını ele alır. Bağlantı dayanıklılığı, SQL Server için Microsoft JDBC Sürücüsü 10.2.0 ile başlayarak kullanılabilir. Bozuk bir boşta bağlantıyı yeniden bağlamak için SQL Server 2014 ve sonraki sürümler veya Azure SQL Veritabanı gereklidir.
Tip
Bağlantı dayanıklılığı yalnızca ilk bağlantıyı yeniden dener ve kesilen boşta bağlantıları sessizce yeniden kurar. Başarısız deyimleri otomatik olarak yeniden denemek (örneğin, kilitlenme kurbanı 1205 veya kilit zaman aşımı 1222) ya da bağlantı yeniden deneme listesini özel hata numaralarıyla (örneğin, 40197 veya 40613 gibi geçici hatalar Azure SQL) genişletmek için Yapılandırılabilir yeniden deneme mantığını kullanın. CRL kural tabanlıdır; hangi hataların ve geri dönüş mekanizmasının kullanılacağını siz belirlersiniz ve bu makalede açıklanan özelliklerle birlikte çalışır.
JDBC sürücüsü nasıl yeniden dener
JDBC sürücüsü üç bağımsız yeniden deneme mekanizması sağlar. Birlikte çalışırlar, böylece hepsini aynı anda kullanabilirsiniz:
| Mekanizma | Ne yapar? | Daha fazla bilgi nereden edinilir? |
|---|---|---|
| Boşta bağlantı dayanıklılığı | Kullanıcıya fark ettirmeden kesilen boşta durumdaki bir bağlantıyı (örneğin, sunucu veya yük dengeleyici tarafından kapatılan bağlantı havuzundaki bir bağlantıyı) yeniden kurar. | Bozuk boşta bağlantıları algılama (bu makale) |
| İlk bağlantı yeniden denemesi | Yerleşik bir geçici hata listesi için, başarısız olan ilk bağlantı denemesi sabit bir zamanlamayla yeniden denenir. | İlk bağlantıları yeniden deneyin (bu makale) |
| Yapılandırılabilir yeniden deneme mantığı (CRL) | Başarısız ifadeler ve özel hata numaraları için kural tabanlı yeniden deneme. Microsoft JDBC Driver 12.10 ile kullanıma sunulmuştur. | Yapılandırılabilir yeniden deneme mantığı |
İlk bağlantıları yeniden deneyin
JDBC sürücüsü, ilk bağlantıyı yeniden denemeden önce sürücünün ne sıklıkta ve ne kadar bekleyeceğini denetleyebilen iki bağlantı özelliği içerir. Bu özellikleri bağlantı dizesi ekleyin veya veri kaynağı özellikleri aracılığıyla ayarlayın.
| Keyword | Değerler | Varsayılan | Description |
|---|---|---|---|
connectRetryCount |
0 ile 255 arasında tamsayı (dahil) | 1 | Vazgeçmeden önce bağlantı kurma veya yeniden kurma girişim sayısı üst sınırı. Varsayılan olarak, sürücü tek bir yeniden deneme girişiminde bulunur.
0 değeri yeniden denemeyi devre dışı bırakır. |
connectRetryInterval |
1 ile 60 arasında tamsayı (dahil) | 10 | Bağlantı yeniden deneme girişimleri arasındaki saniye cinsinden süre. Sürücü, kopmuş durumdaki boşta bir bağlantı algıladığında hemen yeniden bağlanmayı dener, ardından tekrar denemeden önce connectRetryInterval saniye bekler.
connectRetryCount, 0 olduğunda bu özellik yok sayılır. |
Sürücü ilk denemeyi hemen yapar ve her sonraki denemeden önce saniyeler bekler connectRetryInterval , böylece connectRetryCount tekrar denemeler yaklaşık (connectRetryCount - 1) * connectRetryInterval saniyeler sürer.
loginTimeout, tüm sekansı sınırlandırır: sürücü, geçen süre ile connectRetryInterval toplamı loginTimeout'ye ulaştığında yeniden denemeyi durdurur; bu da loginTimeout'ün kendisinden bir aralık önce gerçekleşir.
Bu özellikler yalnızca geçici bağlantı hatalarının yerleşik listesini yeniden dener. Kapsanan hataların tam listesi (4060, 40197, 40501, 40613, 49918-49920 ve diğerleri) için bkz. Yerleşik geçici bağlantı hata listesi. Bu kümeye özel hata numaraları eklemek veya tamamen değiştirmek için retryConn kullanın. Başarısız deyimleri yeniden denemek için aynı makalede kullanın retryExec .
Caution
Eğer retryConn öğesini başında + olmadan belirtirseniz, yerleşik listeyi genişletmek yerine değiştirir. Kendiniz listelemediğiniz tüm yerleşik hatalar, 40613 dahil, artık yeniden denenmez.
Özellikleri ayarlama
connectRetryCount ve connectRetryInterval öğelerini JDBC URL’sinde, bir Properties nesnesinde veya bir SQLServerDataSource üzerinde ayarlayın.
JDBC URL'sinde:
jdbc:sqlserver://server;databaseName=db;connectRetryCount=3;connectRetryInterval=10
Bir Properties nesnesi ile. Bu makaledeki Java kod parçacıklarında, kısalık amacıyla import ifadelerine ve sınıf tanımlarına yer verilmemiştir.
Properties props = new Properties();
props.setProperty("user", "...");
props.setProperty("password", "...");
props.setProperty("connectRetryCount", "3");
props.setProperty("connectRetryInterval", "10");
Connection c = DriverManager.getConnection("jdbc:sqlserver://server;databaseName=db", props);
ile : SQLServerDataSource
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("server");
ds.setDatabaseName("db");
ds.setUser("...");
ds.setPassword("...");
ds.setConnectRetryCount(3);
ds.setConnectRetryInterval(10);
Otomatik duraklatılmış sunucusuz veritabanına bağlanın
Azure SQL Veritabanı'i sunucusuz kullandığınızda otomatik duraklatma etkin, veritabanı ilk bağlantı girişiminde devam eder. Bu deneme, özgeçmiş çalışırken 40613 hatasıyla başarısız oluyor. Veritabanları genellikle bir dakikadan kısa sürede yeniden başlar. Daha fazla bilgi için bkz. Otomatik duraklatma ve otomatik devam.
40613 hatası dahili geçici bağlantı hata listesinde yer aldığından, sürücü bağlantıyı tekrar dener. Uygulamanızın bu durumda kendi yeniden deneme döngüsü gerekmez. Varsayılan ayarlar devam ettirmeyi kapsamaz: connectRetryCount, 1 olduğunda sürücü bu tek yeniden denemeyi hemen çalıştırır. Her iki deneme de veritabanı hâlâ sürdürülürken gerçekleşir, bu yüzden uygulama hatayla karşılaşır.
Bir özgeçmişi yönetmek için, üç özelliği bir arada ayarlayın:
| Property | Neden önemlidir? |
|---|---|
connectRetryCount |
Kaç yeniden deneme yapılacağını ayarlar. Varsayılan değerinden 1daha yüksek ayarlayın. |
connectRetryInterval |
Yeniden denemeler arasına süre koyar. İlk yeniden deneme hemen yapılır; sürücü bundan sonraki her denemeden önce bu kadar bekler. |
loginTimeout |
Tüm diziyi sınırlar. Sürücü, geçen süreye connectRetryInterval eklendiğinde ve sonuç loginTimeout değerine ulaştığında yeniden denemeyi durdurur. |
Aşağıdaki değerler yaklaşık bir dakika boyunca tekrar deniyor, bu da tipik bir özgeçmişi kapsar:
jdbc:sqlserver://<server>.database.windows.net;databaseName=<database>;encrypt=true;loginTimeout=120;connectRetryCount=5;connectRetryInterval=15
Tek başına yükseltme loginTimeout yardımcı olmuyor, çünkü bağlantı girişimi 40613 ile hızlı başarısız oluyor, askıya kalıyor. Tek başına yükseltme connectRetryCount de yardımcı olmuyor, çünkü loginTimeout diziyi kısaltıyor.
Bozuk boşta bağlantıları algılama
Tipik bir boşta bağlantı, bağlantı havuzunda bekleyen bir bağlantıdır. Sürücü, yaklaşık 30 saniye sonra hiçbir etkinlik olmadan boşta bir bağlantı olduğunu düşünür. Sunucu veya istemci ile sunucu arasındaki bir ağ cihazı, boştaki bağlantıları kapatabilir; bu nedenle sürücünün, bir sonraki sorgu çalıştırılmadan önce soketin artık geçersiz olduğunu tespit etmesinin bir yoluna ihtiyaç vardır.
Kopmuş boşta kalan bağlantıları algılamak için sürücü, soket düzeyinde TCP canlı tutma paketlerine dayanır. Java 11 ve daha sonraki sürümlerle Linux'ta, sürücü otomatik olarak keepalive paketlerini 30 saniyelik aralıkla etkinleştirir (KeepAliveTime), bir arıza olduğunda tekrar denemeler arasında 1 saniyelik gecikme olur (KeepAliveInterval).
Önemli
Windows’ta ve Java 11 ya da önceki sürümlerde, kesilmiş boşta bağlantıların kurtarılmasından yararlanmak için işletim sisteminde keepalive ayarlarını el ile yapılandırmanız gerekir. Keepalive'leri yapılandırma hakkında bilgi için bkz. Azure SQL veritabanına bağlantı.
Sınırlamalar
Aşağıdaki koşullardan herhangi biri doğru olduğunda sürücü bozuk boşta bağlantıyı geri yükleyemez:
- Tam olarak ayrıştırılmamış veya arabelleğe alınmamış açık bir sonuç kümesi vardır.
- Bağlantı veritabanlarını Azure SQL karşı değiştirdi.
- Açık bir işlem var.