Forum
Merhaba,
link isimli muhasebe, bordolama programı kullanıyoruz program serverda kurulu programda işlem yaparken kişinin adı soyadını yazıyoruz ve tarihlerde ileri geri gezerken çok yavaş geliyor sorgu sql veritabanı ile ilgili sorun var sanırım nasıl hızlandırabilirim.
Örnek olarak 01 firmasında 100 kayıt var hızlı çalışıyor 02 firmasında 900 kayıt var daha geç çalışıyor.
hızlandırmak için ne yapabiliriz acaba.
Teşekkürler.
link özel bir paket program olduğu için siz bir kullanıcı olarak program içindeki sql cümlelerine müdahale edemezsiniz. özel paket programlarda yazılım firmaları tarafından çeşitli dönemlerde verisiyon değişimleri ile bazı sorgular kısaltılarak performans artışı yapılabiliyor.
sizin yapabileceğiniz network alt yapınızı mevcut halinden biraz daha üst sınıflara çıkartarak kendinizi çözüm üretebilirsiniz,
örneğin cat5 kablo ve 10/100 switclerden, cat6 kablolama ve gigabit switch ve ethernetlerle network alt yapınız ilerletebilinir diye düşünüyorum, iyi çalışmalar
Öncelikle sql server tarafında bazı iyileştirmeler yapılabilir.SQL Server versiyonunuzu ve Server konfigürasyonunu söyleyebilirseniz ona göre daha verimli yardımcı olabilirim.
Örneğin; SQL Server özelliklerinde minimum query memory 'yi 2048 yada 4096 yapmak fayda sağlayabilir. Eğer 2 ve üzeri işlemcili bir server üzerinde çalışıyor ise SQL Server ın işlemci kullanım mimarisini ve cost larını gözden geçirmek gerekebilir.
SQL Server versiyonunuzu ve server yapısını öğrenir isem daha detaylı bilgi verebilirim.
benimde böyle bir sorunum vardı aslında mikro programı kullandıgımız serverı değiştirdik önceki server sql 2000 vardı şimdiki serverda ise sql server 2008 std. var.Server 3ghz Xenon işlemcili 4 gb ramli raid 1 yapılmış bir serverdır.
Acaba sql üzerindeki clint makinaların stok kontrolleri sırasında yada farklı bir işlemn yaptıklarında ki veri çekmelerindeki yavaşlığı nasıl giderebiliriz.
Performance sıkıntısına sebep olabilecek çok fazla etken var.
Sunucunun memory durumu eğer response ları performanslı karşılayamayacak düzeyde ise page life expectancy iniz düşük olacak ve bu durumda memory yerine sürekli disk e erişmek durumunda kalacaksınız. Memory cache hit ratio ve Page life Expectancy performance counter larını kontrol etmekte fayda var.
CPU problemi olabilir bu durumda da gelen istekler runnable queue larda çok bekleyebilir ki bunuda sys.dm_os_schedulers DMW sinden sorgulayabilirsiniz.
Disk problemi olabilir, diskler response lara geç cevap veriyordur yani response time ları düşüktür. Bunuda sys.dm_io_virtual_file_stats DMF sinden bakabilirsiniz. Bu DMW ve DMF ler ile alakalı "Her Gün 1 DMW" yazı dizime 1 Eylül itibarıyla başlayacağım. Bu reklamı da burada geçelim:)
Birde maxdop configuration parametrenizi kontrol etmenizi tavsiye ederim. OLTP sistemlerde 1 kullanımı best practise dir. Default u 0 dır. sp_configure dan bakabilirsiniz.
bunlar sizin kendi tarafınızda kontrol edip upgrade işlemi yapabileceğiniz durumlar.
Birde yazılımın iyileştirilmesi durumu var ki paket program olduğu için bunu siz yapamazsınız. Ama firmaya tavsiyelerde bulunabilirsiniz.
Kısa vadeli bir profiler alıp bunu PAL de sorgulayabilirsiniz.
Missing Index sorguları çekebilirsiniz. (DMW leri var. )
Yada en pahalı sorgu raporlarına bakabilirsiniz.
Ve son olarak networksel kontrol ler var ki bu konu benim uzmanlık alanım değil. Uzmanı olan bir kişiye sormak lazım.
İlk etapta aklıma gelenler bunlar. Dediğim gibi performance sıkıntısını oluşturabilecek çok fazla etken var. Hepsini değerlendiriyor olmak lazım.