Forum
Merhaba
Oracle 10 g kullanıyoruz oracle db conneciton ve maximum session hatası alıyorduk.Parametreler verilerini artırarak düzelttik.Weblogic uygulamsında kullandığımız java conneciton pool 20 olmasına rağmen bazen session lar yığılmakta ve dbde 20 aynı kullanıcı ile session açmaktadır.Acaba connection pool içinde db'de ne gibi ayarlar yapılmalı.Örnek de yazarsanız sevinirim.Özellikle uğur hocamdan support bekliyorum.
İyi çalışmalar
Merhaba,
SESSIONS parametresinin değerini arttırdınızmı?Ayrıca aşağıdaki linklere göz atabilirsin.
http://docs.oracle.com/cd/B14117_01/win.101/b10117/features001.htm
Ancak connection pooling veritabanından ziyade program katmanında yapılan bir işlemdir. Senin bu durumunda kullanıcılarının, muhtemelen ya PGA ile ilgili sıkıntıları var yada oturum açan bazı inaktifler oturumu bırakmıyorlar(askıda kalıyorlar). Geçen cuma günü bloğumda yayınladığım http://uguroracle.blogspot.com/2011/12/oracle-10g-icin-pga-ve-buffer-cache.html yazısındakileri sisteminde tatbik etmeni tavsiye ederim PGA ile ilgili, ayrıca inaktif oturumların sonlandırılması için ise http://uguroracle.blogspot.com/2011/01/sqlnetexpiretime-parametresi-ile.html yazım referans olabilir.
Postunda RAC sistem olup olmadığını belirtmemişsin. Eğer RAC kullanıyorsan http://uguroracle.blogspot.com/2011/01/oracle-10g-rac-mimarisinde-yuk.html ve http://uguroracle.blogspot.com/2011/01/rac-mimarisinde-transparent-application.html yazılarımıda incelemeni tavsiye ederim uygulamalarda yük dengeleme hakkında...
Bunun yanında, bu sorunun olduğu zamanda select * from v$resource_limit sorgusunu çalıştırıp, SESSIONS kaynağının current_utilization değerinin max_utilization değerinden az olduğundan emin olun, aksi durumda kaynak kıtlığını işaret eder.
kolay gelsin,
Uğur İNAL
Merhaba Hocam Yazılım ile sıkıntı olduğunu sanıyorum connection pool'da catch problemi mi var işlem yapmadığında neden disconnect olmadığını anlayamadım.Bu konuda yardımcı olabilir misiniz.Dökümanları incelemeye başladım.Çok teşekkürler.bence çok mükemmel bir oracle'cısınız. best wishes
RESOURCE_NAME |
CURRENT_UTILIZATION | MAX_UTILIZATION | INITIAL_ALLOCATION | LIMIT_VALUE |
processes | 88 | 145 | 300 | 300 |
sessions | 120 | 198 | 335 | 335 |
enqueue_locks | 94 | 122 | 4740 | 4740 |
enqueue_resources | 96 | 134 | 1692 | UNLIMITED |
ges_procs | 0 | 0 | 0 | 0 |
ges_ress | 0 | 0 | 0 | UNLIMITED |
ges_locks | 0 | 0 | 0 | UNLIMITED |
ges_cache_ress | 0 | 0 | 0 | UNLIMITED |
ges_reg_msgs | 0 | 0 | 0 | UNLIMITED |
ges_big_msgs | 0 | 0 | 0 | UNLIMITED |
ges_rsv_msgs | 0 | 0 | 0 | 0 |
gcs_resources | 0 | 0 | 0 | 0 |
gcs_shadows | 0 | 0 | 0 | 0 |
dml_locks | 3 | 79 | 1472 | UNLIMITED |
temporary_table_locks | 0 | 3 | UNLIMITED | UNLIMITED |
transactions | 8 | 71 | 368 | UNLIMITED |
branches | 0 | 1 | 368 | UNLIMITED |
cmtcallbk | 0 | 8 | 368 | UNLIMITED |
sort_segment_locks | 4 | 24 | UNLIMITED | UNLIMITED |
max_rollback_segments | 12 | 30 | 368 | 65535 |
max_shared_servers | 1 | 1 | UNLIMITED | UNLIMITED |
parallel_max_servers | 0 | 0 | 285 | 3600 |
Bu arada rac yok bizde ilginize teşekkürler hocam
İltifatın için teşekkürler, henüz mükemmel seviyesi erken.
İşlem yapmayanların veritabanında bağlantılarının sonlandırılmasının en kesin yolu SQL.NET.EXPIRE_TIME parametresinin ayarlanması. Sqlnet.expire_time parametresi istemci/sunucu arasındaki bağlantıların aktif olup olmadığını anlamak için hangi sıklıkta yoklayıcının gönderileceğini belirtmekte kullanılır ve dakika değerini temsil eder, o süre zarfında inaktif kullanıcının oturumu sonlandırılır. Connection pool'da kod hatası versa veritabanında elinden gelen herşeyi yapmış olacaksın bu durumda.
Hocam Bloğunuzdaki sorgulamalrı yaptım pga için 2 adet sorgu aşağıdaki gibidir.
Current MB |
PGA Target MB | Estimated Time Delta(s | Estimated extra MB |
1628 | 203,5 | 1602,020278 | 12287,66602 |
1628 | 407 | 59,90405437 | 789,0214844 |
1628 | 814 | 22,05122058 | 506,7753906 |
1628 | 1221 | 22,05122058 | 506,7753906 |
1628 | 1628 | 0 | 342,3525391 |
1628 | 1953,599609 | -23,83227617 | 164,6494141 |
1628 | 2279,199219 | -23,83227617 | 164,6494141 |
1628 | 2604,799805 | -23,83227617 | 164,6494141 |
1628 | 2930,399414 | -23,83227617 | 164,6494141 |
1628 | 3256 | -23,83227617 | 164,6494141 |
1628 | 4884 | -23,83227617 | 164,6494141 |
1628 | 6512 | -23,83227617 | 164,6494141 |
1628 | 9768 | -23,83227617 | 164,6494141 |
1628 | 13024 | -23,83227617 | 164,6494141 |
V$DB_CACHE_ADVICE
CURRENT_SIZE | SIZE_FOR_ESTIMATE | ESTD_IO_SECONDS_DELTA | PHYSICAL_READS_DELTA |
3632 | 352 | 230115 | 55147056 |
3632 | 704 | 174267 | 41762887 |
3632 | 1056 | 131354 | 31478866 |
3632 | 1408 | 97851 | 23449882 |
3632 | 1760 | 71635 | 17167257 |
3632 | 2112 | 51105 | 12247165 |
3632 | 2464 | 34731 | 8323140 |
3632 | 2816 | 21597 | 5175599 |
3632 | 3168 | 10939 | 2621460 |
3632 | 3520 | 2303 | 551722 |
3632 | 3632 | 0 | 0 |
3632 | 3872 | -4934 | -1182469 |
3632 | 4224 | -10985 | -2632612 |
3632 | 4576 | -16082 | -3854166 |
3632 | 4928 | -20475 | -4906982 |
3632 | 5280 | -24339 | -5833059 |
3632 | 5632 | -27799 | -6662158 |
3632 | 5984 | -30982 | -7424936 |
3632 | 6336 | -33955 | -8137318 |
3632 | 6688 | -36812 | -8822116 |
3632 | 7040 | -39677 | -9508669 |
buffer cache'i 6000 MB'e, PGAyı da 1950MB'ya çıkararak fiziksel IO yu ve tamamlanma sürelerini azaltabilirsin. Ancak, bunun senin sorununla ilgisi yok. Arada çok uçurum yapan bir durum yok bu raporlar sonucunda...bir önceki cevabımı değerlendir ve mümkünse program kodunu düzeltmeye bak, sql.net parametresi ayarlamasıda çözüm olmazsa.
pga'yı sistemin automatik belirlemesini sağlayabiliyor muyuz hocam
pga'yı sistemin automatik belirlemesini sağlayabiliyor muyuz hocam
http://docs.oracle.com/cd/B12037_01/server.101/b10752/memory.htm#49321