Bu yazımızda ne yaparsak performansı arttırabiliriz bunu ele alacağız,yine bu yazımızda kısa kısa notlar şeklinde olacak.
Tabloların istatistiği olabildiğince güncel tutulmalıdır.Bunun için genelde DWH ortamında ETL'lerde kullanılan tabloları otomatik olarak analiz eden bir iş tanımlanır ve hergün çalıştırılır.
Bir sorgu çalıştırıldıgında explain plana baktıysanız cost diye bir ifade vardır.Cost o sorgunun memory,I/O kullanımını ifade eder.Az cost demek az memory az cpu az I/O kullanımı demektir.
Cost ne kadar küçük ise o kadar iyidir.
Sorgu çalıştırıldıgında memory de 20 gb alan ayrılmış ama bizim 50 gb lık bir ihtiyacımız varsa memory den okuyamayacagindan diskten fiziksel okuma yapılacak bu yuzden sorgu yavas dönecektir.
Olabildiğince memory büyüklüğünü yüksek tutmak gerekiyor.
İki büyük tablo arassında hash join yapilir.Memory e baglidir en hizli join çeşididir.
Nested loop en yavas calisan joindir.
Nested join:Bir kucuk bir büyük tablolarda genelde kullanilir.Küçük tablodaki bir id alinir büyük tabloda onu arar.
Merge join :Önce sıralar sonra birlestirir.Joinin sonunda genelde ORDER BY olan sorgularda kullanilir.
Bir sorguyu hep su planla çalış diyebiliriz,profile yaratarak o sorgu için.
Büyük tabloların kullanıldığı sorgularda ORDER BY ifadesi kullanılırsa bu sıralamayı diskte yapacağından sorgu yavaş gelecektir.Altın kural : Datayi buffer cache de tutarak okunmasını sağlamak.
Recursive call:
Oracle in arka planda yazdigi sorguladir.Yetkisi var mi,sorguyu çalistirmış mı daha once gibi kontroller.
İlk çalistirildiginda rakam olarak yüksek çıkar,sorgu tekrar çalıştığında bu 1 olur.
Session browseri açtıgımızda çalışan sorgularda :abc gibi ifadeler görürüz bunlara bind denir,session bazli degiskene deger vermek için kullanılır.
Kucuk tablolarda index kullanımı kardan cok zarar verebilir,unutmayın index yaratmanın da bir maaliyeti var.
DWH ortamında çalışıyorsanız genelde exadata uzerinde storage index ler tanımlandıgından kullanıcıların index yaratmadan çalışmaları istenir.Exadata full okumayı tavsiye eder.
Star semada ana tablo(genelde fact) diger tum tablolara direk baglidir.(tek join)
Snowflake yapısında ise birden çok joinle elde ederiz istediklerimizi genelde.
Kötü kod nedir kısaca su sekilde cevap verebiliriz:
Kötü parse ediliyorsa,
Diske okuma için cok fazla gitmesi,
Cpu time ı fazla ise bize kodun kotu yazıldıgını gosteriyor olabilir,sorgu üzerinde performance tuning yapmak gerekebilir.Oracle cost base tabanli çalisir ne kadar düşükse o kadar iyidir.
Sorgularımızda commit kullanırız commit demek diske gidip yazmak demektir,commit rastgele koyulmamalıdır.Örneğin milyon tane Update var ise en sona tek bir commit koymaktan ziyade ara ara commit girmek daha uygundur,bufferdaki datayi diske yaziyor cunku.
Shrink ile bozulan bloklari,chain degerine bakarak anlariz.Sıfırdan farklı ise bozulmalar vardır diyebiliriz.
Diğer yazımızda buluşmak uzere...
Yorum Gönder