Query Tuning Proaktif mi, Reaktif mi olmalı?

Bir yazılım geliştiricisi ve hedefleyen bir DBA olarak, SQL Server veritabanlarımı tasarlarken en iyi uygulamaları benimsemeye çalışıyorum (yazılımımın% 99'unun SQL Server'ın üzerinde oturduğu zamanın% 99'u). Geliştirme öncesinde ve geliştirme sırasında mümkün olan en iyi tasarımı yapıyorum.

Ancak, diğer tüm yazılım geliştiricilerde olduğu gibi, eklenmiş işlevsellik, hatalar ve sadece değiştirilmiş / yaratılmış veritabanı nesneleri gerektiren gereksinimlerin değiştirilmesi vardır.

Sorum şu: sorgulama ayarlama proaktif mi yoksa reaktif mi olmalı? Başka bir deyişle, bazı ağır kod / veritabanı değişikliklerinden birkaç hafta sonra, sorgu performansını kontrol etmek ve buna göre ayarlamak için bir gün ayırmalı mıyım? Tamam gibi görünüyor olsa bile ?

Yoksa ortalamadan daha düşük bir performansın bir veritabanı kontrolü olması gerektiğinin farkında olmalı mıyım?

Sorgu ayarlama çok zaman alabilir ve ilk veritabanı tasarımına bağlı olarak minimum fayda olabilir. Kabul edilen modus operandi'lerini merak ediyorum.

Her ikisi de, ancak çoğunlukla proaktif

Geliştirme sırasında gerçekçi miktarlara ve veri kalitesine karşı test yapmak önemlidir. Bir geliştiricinin 100 veya 1000 satırında çalışan bir sorgunun ardından 10 milyon üretim satırıyla düz bir şekilde düşmesi inanılmaz derecede yaygındır.

"Dizin burada yardımcı olabilir" hakkında da not almanıza olanak tanır. Veya "beni tekrar ziyaret et". Veya "bir sonraki DB versiyonunda yeni özellik xxx ile düzeltir".

Ancak, birkaç sorgu zaman testine dayanmaz. Veri dağıtımı değişiyor veya katlanarak gidiyor, çünkü optimize edici farklı bir birleştirme türü kullanmaya karar veriyor. Bu durumda, sadece tepki verebilirsiniz.

En azından, SQL Server için, çeşitli "eksik indeks" ve "en uzun sorgu" DMV sorgularının telefon görüşmesinden önceki sorunlu alanları gösterebileceğini söylemek

Düzenleme: netleştirmek için ...

Proaktif şimdi her sorgu ayarlamak anlamına gelmez. Bu, makul bir yanıt süresine neye ihtiyacınız olduğunu (sık sık çalıştırmak) ayarlamak anlamına gelir. Çoğunlukla haftalık 3 am Pazar rapor sorgularını yoksay.

Tamam, ısırıp karşıt bir bakış açacağım. Öncelikle, başınızı belaya sokacağını bildiğiniz bir şey yaparak başlamamalısınız derim. Buna en iyi uygulamaları uygulayarak aramak istiyorsanız, devam edin. Bu proaktif olmak gerektiği kadarıyla gitmeli.

Ondan sonra zamanın (ve paranın) bir boşa harcanması ile devam edin ve ürününüzü teslim edin. Şişe boyunları olabilecek ya da asla ortaya çıkmayacak sorguları ayarlamak için tonlarca tasarım zamanı almak yerine, bu zamanı yük testi dahil ekstra testler için kullanın.

Bir şeyin tasarımınızın özelliklerine uymadığını veya profilinizin yanıt süreleri listesinin% 10'unun veya% 20'sinin altına düşerse bir şey olduğunu anlarsanız, bu durumda olduğu gibi ince ayar yapmanız için zaman ayırın kırık.

Mükemmel bir dünyada, her şey baştan mükemmel bir şekilde tasarlanır ve mantıksal bir yapı dizisi kullanılarak geliştirilir. Gerçek dünyada bütçe ve zamanla ilgili kısıtlamalar vardır ve test verileriniz üretim verileriniz gibi görünmeyebilir. Bu nedenle, proaktif olarak sorunlardan kaçınmak için sağduyumu kullanın, ancak sınırlı kaynaklarınızı yoğunlaştırıp, hayali veya potansiyel problemler aramak için muhtemelen sahip olmadığınız zaman ve para harcamak yerine gerçek sorunlara yol açan şeyleri ayarlamaya odaklanın.

3 tip ayar, 1 reaktif ve 2 proaktif olacaksınız.

tepkili

Maviden, bazı sorgular size soruna neden oluyor Bir uygulama hatası veya özelliği, beklentilerin üzerinde büyüyen bir tablo, bir trafik artışı veya "en iyi duruma getirici" olan sorgu iyileştirici olabilir. Bu, gecenin bir yarısı, ahlaksız bir ilişki türü olabilir ya da kritik olmayan bir nitelikteki sistem yavaşlığına cevaben olabilir. Her iki durumda da, reaktif ayarlamanın tanımlayıcı karakteri, zaten bir sorun yaşamanızdır . Söylemeye gerek yok, mümkün olduğunca az bunu yapmak istiyorsun. Bu bizi ...

Proaktif

Tip 1: Rutin Bakım

Bir tür programda, şemanızın ne sıklıkla değiştiğine ve verilerinizin ne kadar hızlı büyüdüğüne bağlı olarak birkaç ayda veya haftada bir, veritabanınızın performans analizi araçlarının (örneğin Oracle DBA'lar için AWR raporları) çıktılarını gözden geçirmelisiniz. Yeni sorunlara bakıyorsunuz; bu, Reaktif ayarlama gerektirme yolunda, düşük asılı meyvelerin yanı sıra, yakında sorun çıkması muhtemel olmayan ancak çok fazla önleme umuduyla çok az çaba göstererek gelişebilecek olan şeylerdir. - gelecekteki problemler. Bunun için ne kadar zaman harcamanız gerektiğine ve ne kadar zaman harcayabileceğinize bağlı olacak, ancak en uygun miktar asla sıfır değildir. Ancak, daha fazlasını yaparak harcayacağınız miktarı kolayca azaltabilirsiniz ...

Tip 2: Uygun Tasarım

Knuth'un "erken optimizasyona" karşı uyarısı yaygın olarak bilinmekte ve usulüne uygun olarak saygı duyulmaktadır. Ancak "prematüre" nin doğru tanımı kullanılmalıdır. Bazı uygulama geliştiricileri, kendi sorgularını yazmalarına izin verildiğinde, üzerine vurdukları ilk sorguyu mantıken doğru bir şekilde benimseme eğilimindedirler ve performans, şimdi veya gelecek için hiçbir sakıncası yoktur. Ya da sadece üretim ortamını temsil etmeyen bir geliştirme veri setine karşı test edebilirler (ipucu: Bunu yapma! Geliştiriciler her zaman test için gerçekçi verilere erişebilmelidir.). Mesele şu ki, bir sorguyu ayarlamak için uygun zaman, ilk uygulandığı zaman, düşük performanslı bir SQL listesinde görünmediğinde ve kesinlikle kritik bir soruna neden olduğunda değil.

Öyleyse DBA topraklarında erken bir optimizasyon olarak nitelendirilecek olan nedir? Listemin başında kanıtlanmış bir ihtiyaç olmadan normalleşmeden fedakarlık olacaktır. Çalışma sırasında alt satırlardan hesaplamak yerine üst satırda toplam tutabildiğinizden emin olabilirsiniz, ancak gerçekten gerekli mi? Twitter veya Amazon iseniz, stratejik normalleştirme ve ön hesaplama en iyi arkadaşlarınız olabilir. 5 kullanıcı için küçük bir muhasebe veritabanı tasarlıyorsanız, veri bütünlüğünü kolaylaştıracak uygun yapının öncelikli olması gerekir. Diğer erken optimizasyonlar da aynı şekilde bir öncelik meselesidir. Günde bir kez çalıştırılan ve 0,1 saniyeye kesebileceğinizi düşünseniz bile, 10 saniye süren bir sorguyu ayarlayarak saatler harcamayın. Belki günde 6 saat çalışan bir raporunuz vardır. ancak ayarlama zamanına yatırım yapmadan önce toplu iş olarak zamanlamayı keşfedin. Üretim yükünüz asla% 10'un üzerine çıkmazsa (güvenliği yönetebileceğinizi varsayarak) ayrı, gerçek zamanlı olarak çoğaltılmış bir raporlama örneğine yatırım yapmayın.

Gerçekçi verilere karşı test ederek, büyüme ve trafik düzenleri hakkında eğitimli tahminler alarak (sivri uçlar için artılar) ve platformunuzun optimize edici tuhaflıkları hakkındaki bilgilerinizi uygulayarak, şu anda değil, gelecekte en iyi şekilde çalışan (en yakın) sorguları dağıtabilirsiniz. ve idealin altında koşullar altında. Uygun teknikleri uyguladığınızda, sorgu performansı doğru bir şekilde tahmin edilebilir ve optimize edilebilir (her bir bileşenin olması gerektiği kadar hızlı olması anlamında).

(Ve sen onun yanındayken istatistikleri öğren! )

Mükemmel bir dünyada tüm ayarlamalar proaktif olarak tasarım aşamasında yapılacak ve hiçbir şey reaktif olmayacaktı, ama dünya mükemmel değil. Test verilerinin bazen temsili olmadığını, test durumlarının kaçırılacağını, yüklerin beklenmedik şekilde farklı olacağını ve performans sorunlarına neden olan hataların olacağını göreceksiniz. Bu durumlar biraz reaktif ayarlama gerektirebilir, ancak bu reaktif ayarlama tercih edilmediği anlamına gelmez. Amaç her zaman bunları öne çıkarmak olmalıdır.

Geçmişe dönük ayarlama planlamanız çok pragmatik. Test ederken, beklenen zamanlamaları ve verimi belgelemelisiniz ve zaman zaman üretim süreçlerinin tasarım şartnamelerine uymadığını size bildiren analizler yapmalısınız. Bu şekilde hangi kodun ayarlanması gerektiğini önceden tanımlayabilirsiniz. Ardından sadece sorunun ne olduğunu değil, tasarım / test aşamasında neden yakalayamadığınızı belirleyebilirsiniz.

Benim için performans testi her zaman geliştirme sürecinin bir parçası olmuştur. Bu tabloyu değiştirmek, bu raporu değiştirmek, bu özelliği eklemek ister misiniz? Testin bir parçası olarak, bireysel ve genel performansı bilinen taban çizgileriyle ve / veya gereksinimlerle karşılaştırabildiğinizden emin olun (örneğin, arka planda çalışan bazı raporlar veya başka bir şekilde otomatikleştirilmiştir; sistem her zaman birinci öncelik değildir).

IMHO, bu hiç reaktif bir süreç olmamalı - bir değişiklik, üretimde bir performans problemine tepki vermeye başlamasına neden olana kadar asla beklememelisiniz. Geliştirme / test vb'de değişiklik yaptığınızda, bu değişiklikleri benzer donanımdaki benzer verilerle aynı uygulamalarla ve benzer kullanım modelleriyle test etmeniz gerekir. Bu değişikliklerin üretime girmesine ve sizi şaşırtmasına izin vermeyin. Bu, neredeyse her zaman, bir günlük ayarı harcamak için uygun olmadığında gerçekleşir - bu ayarlama süresi için önceden bütçeyi önceden ayarlayın.