INF: Microsoft SQL Server performansını en iyi duruma getirme

Makale çevirileri Makale çevirileri
Makale numarası: 110352 - Bu makalenin geçerli olduğu ürünleri görün.
Hepsini aç | Hepsini kapa

Bu Sayfada

Özet

En verimli şekilde Microsoft SQL Server performansını en iyi duruma getirmek için <a0></a0>, çok çeşitli durumlarda en büyük performans artışı sağlar ve çözümleme bu alanlara odaklanmak alanları tanımlamalısınız. Aksi halde, önemli zaman ve çaba boyutlandırılabilir geliştirmeleri getirebilecek konularda expend.

Ço?unlukla, aşağıdaki bilgiler, çok kullanıcılı eşzamanlılık dallanma performans sorunları gidermez. Bu "En üst düzeye çıkarma veritabanı tutarlılığı ve SQL Server sürüm 4.2 x"C Programmer's Reference"içinde bulunan, eşzamanlılık," Belge kapsadığı ayrı, karmaşık bir konu, ek E ve diğer Knowledge Base makalelerini de. Sürüm 6.0 belgelerinde değil, ancak bu başlık altında <a1>MSDN</a1> (Microsoft Geliştirici Ağı) CD'sinde bulunabilir.

Teorik tartışmayı yerine, bu makalede deneyim Microsoft SQL Server destek ekibi tarafından gösterilen gerçek durumlarda kullanışlı bir değeri olması için öncelikle alanlara odaklanmıştır.

En büyük yararı, SQL Server performansını mantıksal veritabanı tasarımını, <a1>dizin tasarımı</a1>, sorgu tasarım ve uygulama tasarım genel alanlarından kazanılan deneyimi gösterir. Bunun tersi olarak, en büyük performans sorunlarına çoğunlukla deficiencies aynı bu alanlarda nedeniyle. Performans kuşkularınız varsa çok büyük bir performans artışı genellikle bir görece küçük bir zaman yatırım ile sağlanabilir olduğundan, bu alanlara önce ö?renmeye.

Bellek önbellek arabellekleri, donanım ve benzeri, kesinlikle incelemesi için aday gibi diğer sistem düzeyinde performans sorunları, ancak deneyimi performans kazanç gelen bu alanlar genellikle artımlı olduğunu gösterir. SQL Server kullanılabilir donanım kaynakları otomatik olarak, ço?unlukla, gerek (ve bu nedenle, yararı), geniş bir sistem düzeyi el ayarlama yönetir.

Microsoft SQL Server 6. 0'ın platform katmanı için yeni fırsatlar, büyük miktarda bellek, simetrik çoklu işlem, paralel verileri tarama, en iyi duruma getiricisi geliştirmeleri ve disk şeritleme performans geliştirmeleri sağlar. Ancak, büyük bu geliştirmeleri gibi kapsamda sınırlı kullanılırlar. Hızlı bilgisayar verimsiz sorguları veya hatalı tasarlanmış bir uygulama ile bogged. Bu nedenle, SQL Server 6. 0'ı sağlayan bile ek performans artırma ile veritabanı, dizin, sorgu ve uygulama tasarım en iyi duruma getirmek son derece önemlidir.

Performans sorunlarının çoğu, yalnızca bir sunucu tarafı odak başarıyla çözümlenemiyor. Aslında bir "puppet" denetleyen hangi sorgular gönderilir, istemcinin sunucusudur ve böylece hangi kilitlerin elde yayımlanmış. Ayarlama bazı sunucu tarafında mümkün olsa da, performans sorunlarını çözme başarılı genellikle istemci uygulama davranışını çözümleniyor ve istemci yaygınlaşan rolünü sorunu oynadığı kurulabileceğini bağlıdır.

Daha fazla bilgi

Bağlı olan bazı öneriler karşılaşıyorsunuz, önemli performans kazançları sağladığını şunlardır:

Mantıksal bir veritabanı tasarım Normalleştir

Mantıksal bir veritabanı tasarımının makul normalleştirme en iyi performansı verir. Bir daha dar tabloları Normalleştirilmiş bir veritabanının özellik sayısıdır. Bir daha az Geniş tablolara Normalleştirilmemiş veritabanının özellik sayısıdır. Yüksek Normalleştirilmiş bir veritabanı, performansı zararı karmaşık ilişkisel birleşim ile düzenli olarak ilişkilidir. Ancak, etkin dizin kullanılabilir olarak SQL Server iyileştirici birleştirmeler, hızlı ve verimli seçme en çok etkili olur.

Normalleştirme yararları şunlardır:
  • Daha dar bir tablo olduğundan, sıralama ve dizin oluşturma, hızlandırır.
  • Daha fazla tablo olduğundan daha kümelenmiş dizinler sağlar.
  • Dizinler, dar olarak olma eğilimindedir ve daha fazla sıkıştırma.
  • UPDATE performans yardımcı tablo başına daha az sayıda dizin.
  • Daha az boşluk ve artan, daha az boş bir veri compactness veritabanı.
  • DBCC Tanılama, eşzamanlılık etkisini azaltır, çünkü, gerekli tablo kilitlerin daha az veri etkileyecektir.
SQL Server ile genellikle makul normalleştirme yerine hurts performans sağlar. Normalleştirme arttıkça, bu nedenle numarasını yapmak ve verileri almak için gerekli olan birleştirmeler karmaşıklığını. Bir tahmini kural sayısı başparmak Microsoft, bu dört yönlü ya da daha büyük olan birleştirmeler çok sayıda sorgu neden sürece normalleştirme işlemi taşıyan önerir.

Mantıksal bir veritabanı tasarım zaten sabit toplam ise tasarım uygun şifresini çözmesi olasıdır seçerek bu tabloda bir gösterir, büyük bir tablo normalize etmek değil. Veritabanına erişimi, saklı yordamlar yönetilir, bu şema değişikliği yer uygulamaları etkilemesini olmadan ele geçirebilir. Tersi durumda, tek bir tablo gibi görünen bir görünüm oluşturarak değişikliği gizlemek, mümkün olabilir.

Verimli bir dizin tasarımı kullanın.

Ilişkisel olmayan birçok sistemlerinden farklı olarak, mantıksal bir veritabanı tasarımının bir parçası ilişkisel dizinleri dikkate alınmaz. Dizinler eklenebilen kesildiğinde, ve veritabanı şema veya uygulama tasarımı performans dışındaki herhangi bir şekilde etkilemeden değiştirdi. Etkili bir dizin tasarımı, iyi bir SQL Server performans sağlandığı önemli olur. Bu nedenle, farklı bir dizin ile denemek için hesitate değil.

Iyileştirici en etkin dizin, çoğu durumda güvenilir bir şekilde seçer. Genel dizin tasarım strateji, en iyi duruma getiricisi için iyi bir seçim dizinlerinin sağlamak ve doğru bir karar için güven olmalıdır. Bu çözümleme zamanı azaltır ve çeşitli durumlarda üzerinde iyi performans sağlar.

Dizin tasarım önerileri şunlardır:
  • WHERE yan tümcesi, SQL sorgularınızı, çünkü bu birincil odağını iyileştirici inceleyin.

    WHERE yan tümcesinde listelenen her bir sütun, bir dizin için olası bir adaydır. Temsil edici bir ve yalnızca yavaş olanlara incelemek için çok fazla sorgu varsa,'ı seçin. SQL kodu geliştirme aracınızla saydam olarak oluşturursa, bu seçenek daha zordur. Bu araçların çoğu, hata ayıklama amacıyla bir dosya veya ekran oluşturulan SQL söz dizimini günlüğe izin verir. Böyle bir özellik varsa, aracın satıcıdan öğrenmek isteyebilirsiniz.
  • Dar dizinler kullanır.

    Dar dizinlerinin daha sık olan birden çok sütun, bileşik dizinlerinin daha etkin. Dar dizinler, sayfa başına daha fazla satır ve performansını artırma daha az sayıda dizin düzeyi vardır.

    Iyileştirici hızla ve etkili bir şekilde yüzlerce ya da hatta binlerce dizin ve birleştirme olasılıkları çözümleyebilirsiniz. Dar dizinlerinin daha büyük bir sayı olması genellikle performans yardımcı iyileştirici, seçim yapılacak daha fazla olasılıkları ile sağlar. Daha az sayıda geniş, birden çok sütun dizinleri sahip olan performans zararı, içinden seçim yapabileceğiniz daha az olasılıkları ile en iyi duruma getiricisi sağlar.

    Genellikle, tam olarak kapsanan sorguda vurgulama için bir strateji benimsemesine en iyisidir. Tüm sütunlar, SELECT yan tümcesinde, kümelenmemiş bir dizin tarafından kapsanır, en iyi duruma getiricisi bu tanımak ve çok iyi bir performans sağlar, bu geçerlidir. Ancak, bu genellikle aşırı derecede geniş dizinlerde oluşur ve iyileştirici bu stratejiyi kullanacağını olasılığı çok bağlıdır. Genellikle, sağlayan genellikle daha iyi başarım sorgularının daha geniş bir aralığı içinde daha çok dar dizinleri kullanmanız gerekir.

    Bu dizin güncelleştirilirken yükü nedeniyle yeterli okuma performansı elde etmek gerekli olandan daha fazla dizin olmamalıdır. Ancak, hatta çoğu yönelik güncelleştirme işlemlerini çok daha fazla okuma yazma daha gerektirir. Bu nedenle, denemek için hesitate değil, düşünüyorsanız, yeni bir dizin yardımcı olur; bu, her zaman, daha sonra doğrudan.
  • Kümelenmiş bir dizin kullanın.

    Kümelenmiş dizinler uygun kullanımı, performansı büyük ölçüde artırabilirsiniz. Bile GÜNCELLEŞTIR ve SIL işlemlerini kadar okuma işlemlerini gerektirdiği için kümelenmiş dizinler tarafından genellikle Hızlandırılmış. Tablo başına tek bir kümelenmiş dizin izin verilir, bu nedenle bu dizin akıllıca kullanın. Iyi adayları hızlandırmasını kümelenmiş bir dizin tarafından çok sayıda satır döndüren bir sorgu veya sorgu aralığı, kişiyle ilgili olan.

    Örnekler:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    Bu tür sorgu, ortak ise Bunun aksine, yukarıda SOYAD veya MEMBER_NO sütunları kümelenmemiş bir dizin için iyi bir aday olmayan büyük olasılıkla. Birkaç satır burada döndürülen sütunlarda kümelenmemiş dizin kullanmayı deneyin.
  • Sütun benzersizliği inceleyin.

    Bu, hangi sütun, kümelenmiş bir dizin, kümelenmemiş dizin veya dizin için bir adaydır karar vermenizde yardımcı olur.

    Aşağıda bir örnek sorgu sütun benzersizliği incelemek için yer almaktadır:
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    Bu sütundaki benzersiz değerlerin sayısını verir. Bu tablodaki satır sayısı için karşılaştırın. 10.000 Satır tabloda 5.000 benzersiz değerleri, sütun kümelenmemiş bir dizin için iyi bir aday yapacağı. Aynı tabloda 20 benzersiz değerler kümelenmiş bir dizin daha iyi uyacak. Üç benzersiz değerler her dizine eklenmelidir değil. Bu yalnızca, sabit ve hızlı kuralları verilebilir. Sütunları tek tek sorguların WHERE yan tümceleri listelenen dizinleri yerleştirmek unutmayın.
  • Dizinlenmiş sütunlardaki veriler dağıtım inceleyin.

    Genellikle uzun süren bir sorguyu birkaç benzersiz değerlere sahip bir sütunu dizin veya bir sütunda bir JOIN işlemi nedeniyle oluşur. Bu durum, veriler ve sorgu kendisini temel bir sorundur ve genellikle bu durum tanımlama olmadan çözülemez. Örneğin, soyadına göre alfabetik olarak sıralanmış fiziksel bir telefon dizini şehrin tüm kişiler yalnızca "Etikan" veya "Etikan" olarak adlandırılır, bir kişi aranıyor hızlandırmak. Tek bir şekil için sütun değerlerinin benzersiz olmasını sağlar, yukarıdaki sorgu, ek olarak, bir GROUP BY sorgusu veri dağıtım dizini oluşturulmuş anahtar değerleri görmek için kullanabilirsiniz. Bu verileri nasıl en iyi duruma getiricisi görüntüler için daha yüksek çözünürlük resim verileri ve daha iyi bir perspektif sağlar.

    Iki sütunlu bir anahtarı COL1, COL2 varsayarak, dizin oluşturulmuş anahtar değerleri veri dağıtımını incelemek için bir örnek sorgu şudur:
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    Bu işlem, her bir değerin örneklerinin sayısı olan her anahtar değeri için bir satır döndürür. Döndürülen satırların sayısını azaltmak için <a0></a0>, bir HAVING yan tümcesi ile bazı çıkarmak yararlı olabilir. Örneğin, yan tümcesi
          HAVING COUNT(*) > 1
    
    						
    benzersiz bir anahtar olan tüm satırların dışında bırakır.

    Sorguda döndürülen satır da önemli bir faktör dizin seçimdeki sayısıdır. Iyileştirici kümelenmemiş bir dizin en az bir sayfa g/Ç döndürülen satır başına maliyetini dikkate alır. Bu hızda bu hızla tablonun tamamını taramak için daha verimli olur. Sonuç kümesinin boyutunu sınırlamak için veya bir kümelenmiş dizini olan büyük sonuç bulmak için başka bir nedeni budur.
Her zaman iyi performans ve tersi dizin kullanım günleriyle değil. Dizin her zaman kullanmak için en iyi başarımı üretilen, iyileştirici'nın iş çok basit - olacaktır her zaman kullanılabilir herhangi bir dizini kullanır. Aslında, yanlış seçim dizinlenmiş alma performansı çok hatalı yol açabilir. Bu nedenle iyileştirici'nın görev burada performans yardımcı olmak ve dizinlenmiş alma önlemek dizinlenmiş alma yeri performans zararı seçmektir.

Sorgu Tasarımı'nı verimli kullanma

Bazı sorgular devralınarak yoğun kaynak türleridir. Bu temel bir veritabanı ve dizin sorunları çoğu ilişkisel veritabanı yönetim sistemi (RDBMSs), özellikle SQL Server ortak ilişkilidir. Iyileştirici sorguları olası en verimli şekilde gerçekleştirmek için yetersiz, değildirler. Ancak, kaynak yoğundur; kümesi yönelimli yapısı SQL verimsiz görünür yapmanız. Hiçbir düzeyde iyileştirici karar destek sistemi bu yapıları devralınan kaynak maliyetini ortadan kaldırabilirsiniz. Daha basit bir sorgu karşılaştırıldığında intrinsically pahalı kullanılırlar. SQL Server en uygun bir erişim planı kullanacaktır, ancak bu temelde olası nedir tarafından sınırlandırılır.

Örneğin,:
  • Büyük boyutlu sonuç kümeleri
  • IN, NOT IN ve veya sorgular
  • Yüksek benzersiz olmayan bir WHERE yan tümceleri
  • ! (eşit değildir) karşılaştırma işleçleri =
  • TOPLA gibi belirli bir sütun işlevleri
  • WHERE yan tümcesinde deyimlerde ya da veri dönüştürme
  • WHERE yan tümcesinde yerel değişkenler
  • GROUP BY ile karmaşık görünümleri
Çeşitli faktörlere kullanılması, bu sorgu yapıları bazıları başlatılmalarını. Iyileştirici sonuç sorgunun kaynak yoğun bölümü uygulamadan önce kümesini kısıtlayabilirsiniz, bunlar etkisini lessened. Aşağıda bazı örnekler yer almaktadır.

Yoğun kaynak:
   SELECT SUM(SALARY) FROM TABLE
				

Daha az kaynak yoğun:
   SELECT SUM(SALARY) FROM TABLE WHERE
   ZIP='98052'
				

Yoğun kaynak:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

Daha az kaynak yoğun:
   SELECT * FROM TABLE
   WHERE LNAME=@VAR AND ZIP='98052'
				

Ilk örnekte, TOPLAM işlemi ile dizin Hızlandırılmış edemiyor. Her satır okuma toplanır ve gerekir. Var olduğunu varsayarak dizin ALAN sütunu, iyileştirici büyük olasılıkla bu başlangıçta sonuç SUM uygulamadan önce kümesini sınırlamak için kullanır. Daha hızlı olabilir.

Ikinci örnekte, yerel değişken çalıştırma kadar çözümlenemedi. Ancak, çalışma süresi kadar bir erişim planı seçimi iyileştirici kurduğunuzda ertelemek olamaz; derleme zamanında seçmeniz gerekir. Erişim planı, yerleşik, henüz derleme zaman, @ VAR değer bilinmiyor ve sonuç olarak dizin seçimi girdi olarak kullanılamaz.

Resimli teknik iyileştirme sonuç ile AND yan tümcesinin kümesini sınırlama içerir. Bir diğer yöntem olarak saklanan bir yordamın kullanın ve değeri @ VAR saklı yordam için parametre olarak geçirmek.

Bazı durumlarda basit sorgu tek ve çok karmaşık bir sorgu kullanımı çok ara sonuçları saklamak için geçici tablolar'ı kullanarak bir grup kullanmak en iyisidir.

Büyük boyutlu sonuç kümeleri üzerinde çoğu RDBMSs pahalı. Büyük bir sonuç göz atarak istemciye son veri seçim kümesi döndürmek denemelisiniz. Veritabanı sistemi için tasarlanmıştır işlevi gerçekleştirmek izin verme sonuç kümesinin boyutunu sınırlamak için çok daha etkilidir. Bu da ağ g/Ç azaltır ve uygulama dağıtımı amenable daha yavaş bir uzaktan erişim bağlantıları üzerinden sağlar. Uygulama olarak, eşzamanlılık ilgili performansı iyileştirir... yukarı daha çok kullanıcının ölçeklendirir.

Verimli bir uygulama tasarımı kullanın.

SQL Server performans uygulama tasarımı oynadığı rolü overstated edemiyor. Resim yaygınlaşan roldeki sunucu yerine, bir istemcinin puppet denetleyen bir varlık ve sunucu istemcinin resim daha doğru durumundadır. SQL Server istemcisinin, gönderilen, sorguları, ve sonuçları nasıl işleneceğini ilgili komut tümüyle altındadır. Bu sırayla türünü ve süre kilitlerinin g/Ç ve CPU yükü miktarını sunucuda önemli bir etkisi vardır ve dolayısıyla performansı iyi ya da bozuk olup olmadığı.

Bu nedenle, uygulama tasarım aşamasında doğru kararlar almak önemlidir. Ancak değişiklikler istemci uygulamasına olanaksız görünen anahtar teslimi bir uygulama kullanarak performans sorunu yüz olsa bile, bu performansı etkileyen temel etkene değiştirmez - bunlar istemci yaygınlaşan bir role ve pek çok performans sorunlarını oynadığı istemci değişiklik yapmadan çözümlenemiyor.

Iyi tasarımlanmış bir uygulamada, SQL Server, binlerce eşzamanlı kullanıcıyı destekleyen yeteneğine sahiptir. Kötü tasarlanmış bir uygulama ile bile en güçlü sunucu platformu birkaç kullanıcılarla bog.

Istemci uygulama tasarımı için aşağıdaki önerileri kullanarak SQL Server iyi bir performans sağlar:
  • Küçük bir sonuç kümesi'ni kullanın. Istemcide gözatma CPU ve ağ g/Ç yükü ekler, uygulamayı uzaktan kullanımını daha az ulaşabileceği yapar ve çok kullanıcılı ölçeklenebilirlik sınırlayabilirsiniz gerekmedikçe, büyük boyutlu sonuç alınıyor (örneğin, binler basamağı satır) ayarlar. Tasarım sürelerinde küçük bir sonuç kümeleri oluşturma sorgularını olan kullanıcıdan yeterli giriş uygulama gönderilen için iyidir.

    Bu kolaylaştırmak uygulama tasarım teknikleri, sorgular, sorgu oluşturma, belirli bir giriş alanları mandating ve yasaklanması improvised, joker karakter kullanımını sınırlama içerir.
  • Dbcancel(), DB Kitaplık uygulamaları doğru kullanın. Tüm uygulamaları bir sorgu iptali, sürüyor izin vermelisiniz. Uygulama kullanıcının bir sorguyu iptal etmek için istemci bilgisayarı yeniden başlatın zorlaması. Değil bu ilkesine çözümlenemeyen performans sorunlarına neden olabilir. Dbcancel() kullanıldığında doğru bakım ile ilgili işlem düzeyi kullandı. Ek bilgi için lütfen Microsoft Knowledge Base'de aşağıdaki makaleye bakın:
    117143: INF: zamanı ve dbcancel() veya sqlcancel() nasıl kullanılır
    ODBC sqlcancel() çağrı kullanılıyorsa, aynı sorunları ODBC uygulamaları için geçerlidir.
  • Her zaman tüm sonuçları tamamlama işlemi. Değil bir uygulama tasarımı veya sorguyu iptal etmeden sonuç satırlarını işlemeyi durdurur anahtar teslimi bir uygulama kullanın. Böylece, engelleme ve yavaş performans genellikle bir yol açacaktır.
  • Her zaman sorgu zaman aşımı'nı kullanın. Sonsuza kadar çalıştırmak, sorgularını izin vermiyor. Uygun bir DB-Library veya ODBC çağrıları, sorgu zaman aşımı için yapın. DB Kitaplığı'nda, bu dbsettime() çağrısıyla ve ODBC SQLSetStmtOption() ile yapılır.
  • Sunucuya gönderilen SQL deyimlerini açık denetime olanak sağlayan bir uygulama geliştirme aracını kullanın. Sorgu iptali, sorgu zaman aşımı ve işlem denetimini gibi önemli özellikleri sağladığı saydam olarak daha yüksek düzey nesnelerde temel SQL deyimlerini oluşturur, bir araç kullanın. Iyi bir performans sağlamak veya bu işlem üzerinde açık denetimi ve kilitleme izin vermediğinden, uygulamanın tüm tek başına "saydam SQL" oluşturursa, bir performans sorununu performans resim için kritik olan sorunları gidermek için kilitlenemeyeceğini genellikle.
  • Çevrimiçi işlem (OLTP) sorgularını işleme ve karar destek intermix değil.
  • Değil bir uygulama tasarımı veya sorguyu iptal etmek için istemci bilgisayarı yeniden başlatın kullanıcının zorlayan bir anahtar teslimi uygulamasını kullanın. Bu, çeşitli nedeniyle olası artık bağlantıları gidermek zor performans sorunlarına neden olabilir. Daha fazla bilgi için, aşağıdaki Microsoft Bilgi Bankası makalesine bakın:
    137983: SQL Server'daki artık bağlantıları ile ilgili sorunları giderme

Yavaş Performans çözümleme için teknikleri

Sistem düzeyinde sunucu performans ayarlama tarafından yalnızca bir performans sorununu gidermek amacıyla tempting olabilir. Örneğin, bellek miktarını, dosya sisteminin türünü, sayısı ve işlemci ve türü. Microsoft SQL Server desteği, deneyimi, performans sorunlarının çoğu bu şekilde çözümlenemeyen göstermiştir. Bunlar uygulama çözümleyerek ele gerekir, sorguların uygulama veritabanı ve bu sorgular veritabanı şeması ile nasıl etkileşimli olarak gönderiliyor.

Önce sorgu veya sorguların yavaş olan ayırma. Genellikle yalnızca SQL sorgular yavaş tüm uygulama yavaş olduğunda, görünür. Bu genellikle sorun kesiliyor ve yavaş sorgularını yalıtma bir performans sorununu gidermek mümkün değildir. SQL saydam olarak oluşturduğu bir geliştirme aracı varsa, tüm kullanılabilir tanılama ya da bu aracının hata ayıklama modu, oluşturulan SQL yakalamak için kullanın. Çoğu durumda, izleme özellikleri kullanılabilir durumdadır, ancak bunlar açık belgelenmemiştir. Bir izleme özelliği uygulama tarafından üretilen SQL deyimi izleme için olup olmadığını belirlemek, uygulamanız için bir teknik desteğe başvurun.

Katıştırılmış bir SQL kullanan uygulama geliştirme araçları için bu kolayd?r - SQL açık olarak görünür.

Geliştirme aracı veya son kullanıcı uygulamayı bir izleme özelliği sağlayan, çeşitli seçenekler vardır:
  • SQL Server 4.2 x "Sorun giderme kılavuzu" ve SQL Server 6.0 yönergeleri için uygun 4032 izleme bayrağı kullanın "Transact-SQL başvuru." Bu SQL hata günlüğünde sunucuya gönderilen SQL deyimlerini yakalama izin verir.
  • Microsoft ağı gibi bir ağ çözümleyicisi üzerinden sorgular izleme Monitörü, Systems Management Server'ın bir parçasıdır.
  • ODBC uygulamaları için ODBC Yöneticisi program ODBC çağrılarını izlemeyi seçmek için kullanın. Daha fazla bilgi için ODBC belgelerine bakın.
  • DB-Library veya ODBC katmanları adresindeki SQL karşılar bir üçüncü taraf istemci tarafı yardımcı programını kullanın. Bu mavi Lagoon Software'den SQL denetleyici örneğidir.
  • Microsoft TechNet CD örnek olarak sağlanan SQLEye çözümlemesi aracını kullanın. Not: Microsoft Teknik Destek'e SQLEye desteklenmiyor.
Yavaş sorgu yalıtılmış sonra aşağıdakileri yapın:
  • ISQL gibi bir sorgu aracı kullanılarak bir yalıtım tehlikeye düşebileceğinden şüphe duyulması yavaş sorguyu çalıştırmak ve yavaş olduğunu doğrulayın. Genellikle sunucu bilgisayarında sorguyu çalıştırmak en uygunudur ISQL ve yerel kanalları kullanarak ve çıktıyı bir dosyaya yönlendirin. Bu, ağ g/Ç ekran ve uygulama sonuç arabelleğe alma gibi complicating etkene ortadan yardımcı olur.
  • Sorgu tarafından tüketilen g/Ç incelemek için ON STATISTICS g/Ç güvenlik güncelleþtirmesini daà ° SET kullanın. Mantıksal sayfası g/Ç sayısı dikkat edin. G/Ç sayısını en aza indirmek için iyileştirici'nın amacı olur. Mantıksal g/Ç sayısı kaydını yapın. Bu, geliştirme ölçmek için bir temel oluşturur. Genellikle ON SET SHOWPLAN kullanımı çok özel STATISTICS GÇ çıktı odaklanmak ve farklı sorgu deneyin ve dizin için daha çok etkili türleri olacaktır. Bazı incelemek ve daha etkili bir şekilde empirical sınamaları üzerinde harcanan zaman tüketebilir yorumlanması ve etkili bir şekilde SHOWPLAN çıkışını uygulama gerektirebilirsiniz. Performans sorunu sabit basit bu önerileri, en iyi duruma getiricisi davranışı daha kapsamlı olarak araştırmak için SHOWPLAN kullanabilirsiniz.
  • Sorgu, görünüm veya saklı yordam içeriyorsa, sorgu, görünüm veya saklı yordam ayıklamak ve ayrı ayrı çalıştırın. Bu, farklı bir dizin ile denemeler olarak değiştirmek erişim planı sağlar. Ayrıca, sorguya en iyi duruma getiricisi, görünüm veya saklı yordamlar nasıl işlendiğini ve kendisini sorun yerelleştirmeniz yardımcı olur. Sorun sorguda kendisini ancak yalnızca sorgu, görünüm veya saklı yordamın parçası olarak çalıştırdığınızda değilse, sorgunun kendisini çalıştıran bu belirlemek yardımcı olur.
  • Tetikleyici çalışırken, g/Ç şeffaf oluşturabilir ilgili tablolarda olası Tetikleyicileri, unutmayın. Yavaş bir sorguda kullanılan tüm Tetikleyicileri kaldırmanız gerekir. Bu sorun sorguda kendisini tetikleyici veya Görünüm; bu nedenle, yardımcı, odağınız doğrudan belirlemek yardımcı olur.
  • Yavaş bir sorgu tarafından kullanılan tabloları, dizinler inceleyin. Bu iyi bir dizin olup olmadığını belirlemek için daha önce listelenen teknikleri kullanan ve gerekirse bunları değiştirin. Ilk bir çaba, her sütun, WHERE yan tümcesinde'dizin oluşturmayı deneyin. Yalnızca WHERE yan tümcesi dizinlenmiş bir sütuna sahip değil ya da yararlı bir dizin gibi bir sütun üzerinde olması genellikle performans sorunları nedeniyle.
  • Önceden de belirttiğimiz sorgularını kullanarak, her sütunun bir WHERE yan tümcesinde belirtildiği ve özellikle dizinlenmiş her sütun için bir dağıtım ve verilerin benzersizliğini inceleyin. Çoğu durumda sorgu, tablo, dizinler ve verileri basit incelemesini hemen sorunun nedeni gösterir. Örneğin, performans sorunlarına çoğunlukla bir dizin, yalnızca üç veya dört benzersiz değerlere sahip bir anahtara sahip bir JOIN gibi bir sütun üzerinde gerçekleştirmek veya çok fazla sayıda satır istemciye göndermeden nedeniyle.
  • Bağlı olarak bu çalışma, uygulama, sorgu veya dizinler için gerekli değişiklikleri yapın. Sorguyu, değişikliği yaptıktan sonra yeniden çalıştırın ve g/Ç sayısı herhangi bir değişikliği inceleyin.
  • Geliştirme gösteren sonra ana uygulamanın genel performansı daha iyi olup olmadığını görmek için çalıştırın.
Program, g/Ç veya CPU bağımlı davranış denetleyin. Genellikle, bir sorgu g/Ç veya CPU bağlı olup olmadığını belirlemek kullanışlıdır. Bu, geliştirme çalışmalarını doğru performans sorunu üzerinde odaklanmanıza yardım eder. CPU bağlı bir sorgudur, örneğin, daha fazla bellek, yalnızca önbellekteki artırdığı için SQL Server için daha fazla bellek performansını geliştiren büyük bir olasılıkla ekleme, bu durumda, zaten yüksek olan, isabet oranı.

Bağlı CPU ve g/Ç Query davranışı incele nasıl kurulur:
  • CPU etkinliği veya izleme g/Ç için Windows NT Performans izleyicisi'ni kullanın. "% Disk süresi" sayacı LogicalDisk'ın tüm örneklerini izlemek nesne. Ayrıca izleme "% toplam işlemci zamanı" sayaç sistemin nesne. Geçerli disk performans bilgileri görmek için önceden Windows NT DISKPERF ayarları yayımlayarak bırakmış gerekir "diskperf -Y" komut istemini ve sonra da sistem yeniden yükleniyor. Daha fazla bilgi için Windows NT belgelerine bakın.
  • Sorgu çalışırken, CPU grafik yüksek sürekli olarak (örneğin, yüzde 70 ' büyük) ve "% disk süresi" değerini devamlı olarak düşük bu CPU ilişkili bir durumu gösterir.
  • Sorgu çalışırken, CPU grafik devamlı olarak düşük (örneğin, yüzde 50'den daha az) ve "% disk süresi" sürekli olarak yüksek, bu durumu bir g/Ç bağlı gösterir.
  • CPU grafik STATISTICS GÇ bilgileriyle karşılaştırın.

Sonuç

SQL Server, çok yüksek bir performans üzerinde büyük veritabanları kapasitededir. Özellikle de SQL Server 6.0 ile böyledir. Bu olası performans elde etmek için <a0></a0>, verimli bir veritabanı, <a1>Dizin</a1>, sorgu ve uygulama tasarım kullanmanız gerekir. Bu en iyi aday önemli performans geliştirme almak üzere alanlardır. Uygulamanız daha çok kullanıcının ölçekler, çok kullanıcılı toplu yükü supportable böylece her sorgu olabildiğince, verimli hale getirmek bu seçeneği deneyin. Istemci uygulama davranışını dizinleriyle bu belgede yönergeleri kullanarak uygulama ve experimentation tarafından gönderilen sorguları incelemeye kesinlikle kullanmaları. Performans sorunlarını çözümleme, tümleştirildiği bir yaklaşım genellikle daha az zaman yatırım için önemli gelişme getirebilecek.

Özellikler

Makale numarası: 110352 - Last Review: 22 Şubat 2005 Salı - Gözden geçirme: 3.1
Bu makaledeki bilginin uygulandığı durum:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Anahtar Kelimeler: 
kbmt kbinfo kbother KB110352 KbMttr
Machine-translated Article
ÖNEMLİ: Bu makale, bir kişi tarafından çevrilmek yerine, Microsoft makine-çevirisi yazılımı ile çevrilmiştir. Microsoft size hem kişiler tarafından çevrilmiş, hem de makine-çevrisi ile çevrilmiş makaleler sunar. Böylelikle, bilgi bankamızdaki tüm makalelere, kendi dilinizde ulaşmış olursunuz. Bununla birlikte, makine tarafından çevrilmiş makaleler mükemmel değildir. Bir yabancının sizin dilinizde konuşurken yapabileceği hatalar gibi, makale; kelime dağarcığı, söz dizim kuralları veya dil bilgisi açısından yanlışlar içerebilir. Microsoft, içeriğin yanlış çevrimi veya onun müşteri tarafından kullanımından doğan; kusur, hata veya zarardan sorumlu değildir. Microsoft ayrıca makine çevirisi yazılımını sıkça güncellemektedir.
Makalenin İngilizcesi aşağıdaki gibidir:110352
Kullanım Dışı Bilgi Bankası İçeriği Yasal Uyarı
Bu makale, Microsoft'un artık destek sağlamadığı ürünler ile ilgili olarak yazılmıştır. Bu nedenle, bu makale "olduğu gibi" sağlanmıştır ve bundan sonra güncelleştirilmeyecektir.

Geri Bildirim Ver

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com