SQL Sorunlarının İzini Sürmek
Production sorunları hepimizin korkulu rüyası... En olmadık zamanlarda en olmadık yerlerde karşımıza çıkabiliyorlar. Günlük döngümüzde çoğunlukla veri bozuklukları veya sorgu performansıyla ilgili problemler ile karşılaşıyoruz.
Bazen sorunlar o kadar sinsice ortaya çıkıyor ki, kendinizi en rahat hissettiğiniz anda patlak veriyor. Bu yazıda, hiç beklemediğimiz anda karşımıza çıkan bir problemi ele alacağım.
Problemimiz, bir batch işimizin durduk yere anlamsız bir hata mesajı vererek kesilmesiyle başlıyor. Bu her gece düzenli çalışan bir iş, daha önce de hata almamış. Önce sorunun anlık bir şey olabileceğini düşünerek birkaç kez yeniden başlatmayı deniyoruz ama hata düzelmiyor.
Aldığımız hata “Internal error code 12351 21312” gibi database seviyesinde bir hataydı. İşin kötüsü hata kodu ile Google’da arattığımızda hiç yararlı bir sonuç bulamıyorduk. Daha detaylı incelemek için ekip arkadaşlarımızla bir araya geldik.
Hata bizim kitleyi çekerken çalışan sorgudan alınıyordu. Aynı sorguyu bizim sorgu ortamında çalıştırınca, 15sn gibi sürelerde tamamlanıp hata vermeden yanıt dönebiliyordu.
- Sorgunun sonucundan çok fazla kayıt da gelmiyordu, gelen kayıtlarda da bir veri bozukluğu yoktu.
- Batch bir iş için normal bir sürede tamamlanıyordu.
- Sorgu uzun sürdüğünden veya kayıtlardan dolayı hata alabilecekmiş gibi de durmuyordu.
Hata mesajından bir şey çıkaramayınca, neden olabileceği konusuna teoriler üretmeye başladık.
İlk aklımıza gelen çalıştığı saat aralığında çalışan başka bir işten etkileniyor olabileceği olmuştu. Farklı saatlerde çalıştırıp denedik, o saatte çalışan işlere baktık ama bir sonuç çıkaramadık. İşi ne zaman çalıştırırsak çalıştıralım yine aynı şekilde hata alıyordu.
Sonraki teorimiz uygulamada veya ortamda bir değişiklik yapıp yapmadığımız üzerine oldu. Burada geçmişte yaptığımız versiyon geçişlerine ve değişikliklerimize göz attık. En son geçişimizin üzerinden 2–3 hafta gibi bir süre geçmişti ve iş o geçişin öncesinde de sonrasında da başarılı bir şekilde çalışıyor olduğunu gördük. Yeni bir versiyon geçerek bozmuş olamayız gibi duruyordu. Kendi kontrolümüzdeki ortam konfigürasyonlarımızı da değiştirmemiştik.
En son yine başa dönüp sorguyu incelemeye başladık. Sorguda dikkatimizi çeken komplike bir view’ımıza join atması oldu. Bu komplike view’a online sorgular ile gitmemeye dikkat ediyorduk. Genelde online sorgularımızın performansını kötü yönde etkiliyordu. Bizde bu view’dan şüphelenerek buradaki sorunun SQL parse aşamasında yaşanan bir sorun olabileceğini düşündük.
Oracle’da bir sorgu çalışmadan önce bir dizi aşamalardan geçip çalıştırılıyor. Bu aşamalar; sorgunun shared pool’a alınması, SQL syntax’ının, tablo ve kolon isimlerinin doğruluğunun kontrol edilmesi, hangi indexlerin kullanılacağının hesaplanması gibi düşünebilirsiniz. Bizimde tahminimiz bu parse ettiği aşamada bir yerde sorun olup hata aldığı yönünde oldu.
Önce daha ufak bir kitleye indirgeyerek sorguyu değiştirip test ettik. Başarılı olduğunu görünce de view’da yapılan işi uygulama seviyesine alma yoluna gittik. Bunun sonucunda iş başarılı bir şekilde tamamlanır hale geldi. Sanırım db bize “Şu sorguyu bi düzeltiverin, parse ederken canım çıkıyor” demeye çalışıyordu.
Böyle sorunlarla uğraşmak bana geliştirmeleri/tasarımları yaparken daha iyi bir bakış açısı kazandırdığını düşünüyorum. Yaptığım değişiklik sonucunda veya böyle canına tak edip kendi kendine bozulan sqller ile ilgili yazılarımın devamı gelecek…
Okuduğunuz için teşekkürler.
