none
PROCEDURE KULLANIMI RRS feed

  • Soru

  • Merhaba arkadaşlar,

    Her sorguda procedure kullanmak mantıklı mı ? Procedure sayısı fazla olunca örneğin 100-150 tane procedure olunca performansa zararı var mıdır ?

    10 Mayıs 2018 Perşembe 16:45

Yanıtlar

  • Değişir. Burada performans dışında da faktörler var ama merakınız performans yönünde olduğundan sadece o pencereden anlatmaya çalışayım.

    Öncelikle 1 tane veya 1000 tane sp olmasının en büyük negatif yanı bellek tarafında olacaktır. Ama "bence" bu sayılar gayet az ve önemsiz. 

    SQL server'da iş performans olduğunda ilk incelediğimiz kısım çalışma planıdır. Çalışma planı nedir? Bir sorgu yazdığınızda bu sorgunun yürütülmesi için yüzlerce farklı yol olabilir. Örneğin yaşı 100 den büyük kişiler şeklinde bir sorgunuz olsun. Öncelikle sql bu konuda bir istatistik bilgisi varsa ona başvuracaktır. Çünkü bu bilgi ona yaşı yüzden büyük insan sayısının tüm insanlara olan oranının çok düşük olduğunu söyleyecektir. Daha sonra uygun indekslere bakacaktır. Çünkü indeksler sayesinde tüm satırları tek tek okuyup yaş kolonuna bakmak zorunda kalmayacaktır. Indeksler sıralı olduğundan doğrudan ilgili sayfaya gidip hızlıca ilgili kayıtları çekebilir...

    SP lerin normal sorgulardan farkı siz özellikle belirtmediğiniz sürece çalışma planlarının sabit olmasıdır. Bu sayede çalışma planlı oluşturulması için zaman kaybedilmez. Doğrudan yürütülür. Fakat... çalışma planı tüm girdi parametrelerine uygun olmayabilir. Bu durumda bir çağrı için çok hızlı yanıt dönerken, bir diğeri için çok yavaş dönebilir. Bunu da çalışma planlarına bakıp anlayıp, istatistik ve/veya indeks eklemeleri yapıp ve "query hint" dediğimiz yardımcıları kullanırız. 

    Öte yandan normal sorgularda peş peşe geldiklerinde SQL server bunların çalışma planlarını saklama eğilimindedir. Sanki SP gibi hızlı çalışabilirler ve farklı parametrelere göre farklı çalışma planları oluşturulabilir.

    Bir diğer husus (hala splerde performans konuşuyoruz), projenin analizi ile ilgili olacaktır. Bu splerin bir birini çağırma durumları olacak mı? İç içe kullanılacaklar mı? Bu iç içe kullanımlarda genellikle (benim şahsi tecrübem) kötü bir çalışma planı çıkıyor. Ben eğer mümkünse SP ler yerine TVF'leri kullanmaya çalışıyorum. Çünkü bunlar CROSS JOIN ile kullanıldıklarında çok iyi optimize olabiliyorlar. Tabi TVF lerin çok fazla limitleri var.


    www.cihanyakar.com

    • Yanıt Olarak Öneren Cihan YakarMVP 21 Mayıs 2018 Pazartesi 16:58
    • Yanıt Olarak İşaretleyen Ekrem Önsoy 29 Haziran 2018 Cuma 12:57
    11 Mayıs 2018 Cuma 09:13
  • Selam Çoloğ,

    Bu konu sadece performans ile ilgili değil, aynı zamanda komple yazılım mimarisi ve yapısıyla ilgili. Birlikte çalıştığım bazı şirketler kodlarının veya "business"ın veritabanında olmasını istemiyorlar ve doğrudan yazılıma gömüyorlar. Bazıları veritabanı kodlamasıyla çok zaman kaybetmemek ve pratiklik için ORM, Linq gibi yöntemlerle oluşturuyorlar SQL kodlarını.

    Hepsinin artıları ve eksileri var, belki saatlerce, günlerce konuşulup tartışılabilecek konular.

    SQL Server'da çalışacak tüm sorgular için, SP olsun, parameterized sorgular olsun, dinamik SQL olsun, hepsi için çalıştırma planı oluşturulur ve sorgu bu plana göre çalışır. Oluşturulan planın sadece 1 kere mi, yoksa çoklu kez mi kullanılacağı ise çalışacak sorgunun SP ile mi, parameterized mı, dinamik mi ve hangisi olursa olsun çalışacak kod ile gelecek parametre/değer ve kullanılacak yönteme göre değişir. Yani SP için sadece 1 kere plan oluşturulur ve hep o kullanılır gibi bir şey diyemez kimse, çünkü o SP içerisinde RECOMPILE seçeneği kullanılabilir ve o zaman o SP'ye ait hiçbir plan Plan Cache'te tutulamaz. Keza öyle bir dinamik SQL kodu çalışır ki, hep aynı değer ile gelir ve tek bir planı olur ve hep o plan kullanılabilir.

    Tabii veritabanı düzeyinde yapılacak Parameterization ayarları da tüm mekanizmayı değiştirebilir. Yani belki sana göre basit, ama aslında çok derinliği olan bir soru sormuşsun.

    Bu derinliği pas geçerek doğrudan ve yüzeysel olarak sorunu cevaplarsam, SP kullanmak mantıksız değil ve veritabanı ve Plan Cache'i çöplüğe çevirmediğin sürece, yani SP'leri verimli bir şekilde oluşturup kullandığın sürece SP sayısının performansa zararı olmaz.


    http://ekremonsoy.blogspot.com | http://www.ekremonsoy.com | @EkremOnsoy

    • Yanıt Olarak Öneren Ekrem Önsoy 29 Haziran 2018 Cuma 12:57
    • Yanıt Olarak İşaretleyen Ekrem Önsoy 29 Haziran 2018 Cuma 12:57
    29 Haziran 2018 Cuma 08:56

Tüm Yanıtlar

  • Değişir. Burada performans dışında da faktörler var ama merakınız performans yönünde olduğundan sadece o pencereden anlatmaya çalışayım.

    Öncelikle 1 tane veya 1000 tane sp olmasının en büyük negatif yanı bellek tarafında olacaktır. Ama "bence" bu sayılar gayet az ve önemsiz. 

    SQL server'da iş performans olduğunda ilk incelediğimiz kısım çalışma planıdır. Çalışma planı nedir? Bir sorgu yazdığınızda bu sorgunun yürütülmesi için yüzlerce farklı yol olabilir. Örneğin yaşı 100 den büyük kişiler şeklinde bir sorgunuz olsun. Öncelikle sql bu konuda bir istatistik bilgisi varsa ona başvuracaktır. Çünkü bu bilgi ona yaşı yüzden büyük insan sayısının tüm insanlara olan oranının çok düşük olduğunu söyleyecektir. Daha sonra uygun indekslere bakacaktır. Çünkü indeksler sayesinde tüm satırları tek tek okuyup yaş kolonuna bakmak zorunda kalmayacaktır. Indeksler sıralı olduğundan doğrudan ilgili sayfaya gidip hızlıca ilgili kayıtları çekebilir...

    SP lerin normal sorgulardan farkı siz özellikle belirtmediğiniz sürece çalışma planlarının sabit olmasıdır. Bu sayede çalışma planlı oluşturulması için zaman kaybedilmez. Doğrudan yürütülür. Fakat... çalışma planı tüm girdi parametrelerine uygun olmayabilir. Bu durumda bir çağrı için çok hızlı yanıt dönerken, bir diğeri için çok yavaş dönebilir. Bunu da çalışma planlarına bakıp anlayıp, istatistik ve/veya indeks eklemeleri yapıp ve "query hint" dediğimiz yardımcıları kullanırız. 

    Öte yandan normal sorgularda peş peşe geldiklerinde SQL server bunların çalışma planlarını saklama eğilimindedir. Sanki SP gibi hızlı çalışabilirler ve farklı parametrelere göre farklı çalışma planları oluşturulabilir.

    Bir diğer husus (hala splerde performans konuşuyoruz), projenin analizi ile ilgili olacaktır. Bu splerin bir birini çağırma durumları olacak mı? İç içe kullanılacaklar mı? Bu iç içe kullanımlarda genellikle (benim şahsi tecrübem) kötü bir çalışma planı çıkıyor. Ben eğer mümkünse SP ler yerine TVF'leri kullanmaya çalışıyorum. Çünkü bunlar CROSS JOIN ile kullanıldıklarında çok iyi optimize olabiliyorlar. Tabi TVF lerin çok fazla limitleri var.


    www.cihanyakar.com

    • Yanıt Olarak Öneren Cihan YakarMVP 21 Mayıs 2018 Pazartesi 16:58
    • Yanıt Olarak İşaretleyen Ekrem Önsoy 29 Haziran 2018 Cuma 12:57
    11 Mayıs 2018 Cuma 09:13
  • Selam Çoloğ,

    Bu konu sadece performans ile ilgili değil, aynı zamanda komple yazılım mimarisi ve yapısıyla ilgili. Birlikte çalıştığım bazı şirketler kodlarının veya "business"ın veritabanında olmasını istemiyorlar ve doğrudan yazılıma gömüyorlar. Bazıları veritabanı kodlamasıyla çok zaman kaybetmemek ve pratiklik için ORM, Linq gibi yöntemlerle oluşturuyorlar SQL kodlarını.

    Hepsinin artıları ve eksileri var, belki saatlerce, günlerce konuşulup tartışılabilecek konular.

    SQL Server'da çalışacak tüm sorgular için, SP olsun, parameterized sorgular olsun, dinamik SQL olsun, hepsi için çalıştırma planı oluşturulur ve sorgu bu plana göre çalışır. Oluşturulan planın sadece 1 kere mi, yoksa çoklu kez mi kullanılacağı ise çalışacak sorgunun SP ile mi, parameterized mı, dinamik mi ve hangisi olursa olsun çalışacak kod ile gelecek parametre/değer ve kullanılacak yönteme göre değişir. Yani SP için sadece 1 kere plan oluşturulur ve hep o kullanılır gibi bir şey diyemez kimse, çünkü o SP içerisinde RECOMPILE seçeneği kullanılabilir ve o zaman o SP'ye ait hiçbir plan Plan Cache'te tutulamaz. Keza öyle bir dinamik SQL kodu çalışır ki, hep aynı değer ile gelir ve tek bir planı olur ve hep o plan kullanılabilir.

    Tabii veritabanı düzeyinde yapılacak Parameterization ayarları da tüm mekanizmayı değiştirebilir. Yani belki sana göre basit, ama aslında çok derinliği olan bir soru sormuşsun.

    Bu derinliği pas geçerek doğrudan ve yüzeysel olarak sorunu cevaplarsam, SP kullanmak mantıksız değil ve veritabanı ve Plan Cache'i çöplüğe çevirmediğin sürece, yani SP'leri verimli bir şekilde oluşturup kullandığın sürece SP sayısının performansa zararı olmaz.


    http://ekremonsoy.blogspot.com | http://www.ekremonsoy.com | @EkremOnsoy

    • Yanıt Olarak Öneren Ekrem Önsoy 29 Haziran 2018 Cuma 12:57
    • Yanıt Olarak İşaretleyen Ekrem Önsoy 29 Haziran 2018 Cuma 12:57
    29 Haziran 2018 Cuma 08:56
  • @Ekrem bey, sanıyorum ki benim cevabım gözünüzden kaçmış. Mimari açıdan dediklerinize tamamen katılıyorum o konuya soru ile ilgili olmadığından girmedim çünkü bu forumda "mimari açıdan yanlış yapıyorsun" veya "mimari açıdan da düşünmek lazım" diye belirttiğinizde "kısa kes! cevabı biliyorsan söyle" minvalinde yanıt alıyorsunuz ve bundan çok yoruldum. Siz değindiğiniz için teşekkür ederim. Çalışma planları konusunda birebir aynı şeyi söylemişiz.Fakat, performans konusunda ise MSSQL özelinde konuşacak olursak, SP lerin başka bir query veya SP içerisinde çağrılması aynı işi yapan TVF'ye Cross Join atılarak inline edilmesine göre ciddi anlamda daha yavaş çalışmaktadır. Yine CLR_SP ler bazı durumlarda klasik SP'lerden çok daha hızlı çalışmaktadır. 

    www.cihanyakar.com



    29 Haziran 2018 Cuma 10:40
  • Selamlar Cihan,

    Cevabını okumuştum, gözümden kaçmadı. Eksik veya yanlış yorum yaptığını düşündüğüm için değil, cevabı güçlendirmek ve birkaç ek noktaya değinmek istediğim için bir cevap da ben vermek istedim.

    Aynı işi yapan farklı teknikler senaryoya göre çok farklı sonuçlar üretebilir, CLR SP, klasik SP'den daha hızlı çalışabilirken, Memory Optimized SP hepsinden çok daha hızlı çalışabilir. Bu konudaki olasılıklar çok fazla. Sen de biliyorsun, performans iyileştirme birçok açıdan ve çok farklı alternatiflerle yapılabiliyor.


    http://ekremonsoy.blogspot.com | http://www.ekremonsoy.com | @EkremOnsoy

    29 Haziran 2018 Cuma 12:57