none
time out & Cpu % 100 RRS feed

  • Soru

  • 2 table dan Union komutu ile birleştirimiş bir sorgu yazıyorum ve bunu view olarak sql server 2005 e kaydettim. Hazırladığım uygulama ile OLEDB ADO kullanarak sorguyu çalıştırıyorum. bütün datayı istediğimde Time out hatası alıyorum bu arada SQL server ın çalıştığı sunucunun CPU aktivetesinin %100 olduğunu gözlemliyorum görev yöneticisinden.Aynı sorguyu kriterleri daraltarak istediğimde çalışıyor.

    table1 kayıt sayısı= 350000

    Table2 kayıt sayısı=200000

    Aynı sorguyu uygulamadan değilde SQL üzerinde "Edit table top 200" komutu ile de açmaya çalışıyorum yine time out hatası alıyorum

    Üstelik bu durumu tek kullanıcı ile yaşıyorum. birden fazla kullanıcı ile durum daha fena olucak sanırım.

    Yardımlarınız için şimdiden tşk ederim. Herkese iyi çalışmalar.

    13 Ocak 2011 Perşembe 15:28

Yanıtlar

  • Bu kadar kayıt olan tabloları SSMS arayüzünden "Edit table top 200" gibi bir komut ile düzenlemek çok da pratik değil, bunu sadece test amaçlı yaptığını düşünüyorum.

    SSMS tarafında arayüzden yaptığın işlemlerden kaynaklanan Timeout sorununu çözmek için bu ayarı şuradan değiştirebilirsin: Tools->Options->Designers->Table and Database Designers: Transaction time-out after.

    Uygulama tarafındaki Timeout sorununu da, Connection String'te veya uygulamanda kullandığın Connection Class'ındaki Connection ayarlarında bulunan Timeout değerini değiştirerek çözebilirsin. Örneğin .Net'te bu süre varsayılan olarak 15 saniyedir.

    Ayrıca ağ trafiğini azaltmak ve sorgularını hızlandırmak açısından açısından çekebileceğin en az veriyi çekmeni tavsiye ederim. Örneğin SELECT * FROM... değil de, gerçekten ihtiyacın olan alanları SELECT ALAN1, ALAN3 FROM... şeklinde getirtmen hem sorgunu hızlandıracaktır, hem sunucuda daha az READ yapmana neden olacaktır, hem ağ trafiğini rahatlatacaktır, hem de tablona ekleyebileceğin yeni alanların veya kullanıcıya görünmesini istemediğin alanların görünmemesini sağlayacaktır. Bu tabii ki tamamen başka bir konu, ama yeri gelmişken bu konuda da kısa bir bilgi vermek istedim.

    Eğer sorun devam ediyorsa, bizimle çalıştırdığın sorgunun Execution Plan'ını ve ilgili tabloların Schema'larını paylaşırsan, sorgunun performansı konusunda da yardımcı olmaya çalışabiliriz.


    Ekrem Önsoy - MCDBA, MCITP:DBA & DBD, MCSD.Net, SQL Server MVP | ekremonsoy@blogspot.com
    • Yanıt Olarak Öneren Serkan Bark 14 Ocak 2011 Cuma 13:53
    • Yanıt Olarak İşaretleyen Serkan Bark 17 Ocak 2011 Pazartesi 14:44
    13 Ocak 2011 Perşembe 21:22

Tüm Yanıtlar

  • Merhaba

    SQL'in  bu tarafinda fazla deneyemim yok ancak elimden geldigi kadar yardimci olmaya calisayim, tablolariniza ait herhnagi bir index yarattinizmi, bu islemi yaparken buyuk ihtimalle full scan oldugundan veya sorgu yapinizdan oturu sistemde kasilma olmakta. Index yoksa tavsiyem tablonuzu ve nasil kullanacaginiza gore index veya indexler yaratmanizdir.

    Sisteminizin ozellikleri nedir bu konuda bilgi verebilirmisiniz?


    Osman Shener
    • Yanıt Olarak İşaretleyen Erol YURDADUR 13 Ocak 2011 Perşembe 16:53
    • Yanıt İşaretini Geri Alan Erol YURDADUR 13 Ocak 2011 Perşembe 16:55
    13 Ocak 2011 Perşembe 15:56
  • Bu kadar kayıt olan tabloları SSMS arayüzünden "Edit table top 200" gibi bir komut ile düzenlemek çok da pratik değil, bunu sadece test amaçlı yaptığını düşünüyorum.

    SSMS tarafında arayüzden yaptığın işlemlerden kaynaklanan Timeout sorununu çözmek için bu ayarı şuradan değiştirebilirsin: Tools->Options->Designers->Table and Database Designers: Transaction time-out after.

    Uygulama tarafındaki Timeout sorununu da, Connection String'te veya uygulamanda kullandığın Connection Class'ındaki Connection ayarlarında bulunan Timeout değerini değiştirerek çözebilirsin. Örneğin .Net'te bu süre varsayılan olarak 15 saniyedir.

    Ayrıca ağ trafiğini azaltmak ve sorgularını hızlandırmak açısından açısından çekebileceğin en az veriyi çekmeni tavsiye ederim. Örneğin SELECT * FROM... değil de, gerçekten ihtiyacın olan alanları SELECT ALAN1, ALAN3 FROM... şeklinde getirtmen hem sorgunu hızlandıracaktır, hem sunucuda daha az READ yapmana neden olacaktır, hem ağ trafiğini rahatlatacaktır, hem de tablona ekleyebileceğin yeni alanların veya kullanıcıya görünmesini istemediğin alanların görünmemesini sağlayacaktır. Bu tabii ki tamamen başka bir konu, ama yeri gelmişken bu konuda da kısa bir bilgi vermek istedim.

    Eğer sorun devam ediyorsa, bizimle çalıştırdığın sorgunun Execution Plan'ını ve ilgili tabloların Schema'larını paylaşırsan, sorgunun performansı konusunda da yardımcı olmaya çalışabiliriz.


    Ekrem Önsoy - MCDBA, MCITP:DBA & DBD, MCSD.Net, SQL Server MVP | ekremonsoy@blogspot.com
    • Yanıt Olarak Öneren Serkan Bark 14 Ocak 2011 Cuma 13:53
    • Yanıt Olarak İşaretleyen Serkan Bark 17 Ocak 2011 Pazartesi 14:44
    13 Ocak 2011 Perşembe 21:22