Neden birdenbire dizinlere veya sorgunun değiştirilmesi gerektiğine nasıl cevap verilir


11

3 yıllık deneyime sahip genç DBA'yım. Bizim işimiz, sorgularda ince ayar yapmak veya geliştiricilere belirli kodların yeniden yazılması veya dizinlere ihtiyaç duyulması konusunda tavsiyelerde bulunmaktır.

Geliştirici ekibinin sıkça sorduğu basit bir soru: "Dün iyi geçti, aniden ne değişti?" ve altyapı tarafını kontrol etmemiz istenecek. Herhangi bir soruna ilk tepki her zaman doğrulanan ilk şey olan altyapıya maksimum suçlama getirmek gibi görünmektedir.

Geliştirme ekibinin “değişen” sorularına nasıl cevap vermeliyiz? Aynı durumla hiç karşılaştınız mı? Öyleyse, lütfen deneyiminizi paylaşın.

Yanıtlar:


10

Değişen soruyu dev ile nasıl cevaplayabilirim?

Bu sadece DEV için değil, BT ve iş dünyasındaki her takım için de çok yaygın bir sorudur.

Ne değişti ? ==> gerçekler ve rakamlarla cevaplanabilir.

Gerçekler örneğin

  • veritabanına erişen kullanıcı sayısını artırmak?
  • Sunucu yapılandırma parametresinde herhangi bir değişiklik var mı?
  • Veritabanı Bakımı - güncelleme istatistikleri, yapılmayan dizinlerin yeniden düzenlenmesi / yeniden oluşturulması? Bu nedenle planlar yanlış oluşturuluyor!
  • Veri miktarı arttı mı?
  • Ağ tarafında değişiklikler yapıldı, işletim sistemi yamalandı ve / veya sql sunucusu için yeni bir hizmet paketi veya CU dağıtıldı - uygulama iş döngünüzün tam regresyon testi yapılmadan ?
  • Altta yatan SAN aniden yavaşladı mı?

Gösterilecek verileriniz varsa rakamlar türetilebilir. Örneğin :

  • Bu durumda sunucunuzu temel almak çok önemlidir. Gerçekleri katı figürlerle destekleyebileceğiniz için bu suçlama oyununu hafifletecektir .
  • Verileri bir sql sunucusu yeniden başlatıldıktan sonra kalıcı hale gelmesi için DMV'leri veya bir tabloya sp_whoisactive kullanarak veri toplamaya başlayın.

(ortamınıza ve ihtiyaçlarınıza, ne sıklıkta veri toplayacağınıza / hangi verilerin toplanacağına ve saklama süresinin ne kadar olacağına bağlı olarak egzersiz yapmalısınız ) veya (sqlsentry veya idera'nın tanılama yöneticisi gibi üçüncü taraf bir yazılıma yatırım yapabilirsiniz. yukarıdaki işi sizin için yapacak) .


7

Farklı bir plan alıyor olabilirsiniz çünkü:

  • plan aşağıdaki nedenlerden ötürü önbellekten çıkarılmış olabilir:
    • hizmetin yeniden başlatılması
    • plan önbelleğinin manuel olarak temizlenmesi
    • bir hizmeti yeniden başlatma veya yük devretme
    • yanlışlıkla yapılan bir değişiklik, örneğin bazı sp_configuredeğişiklikler önbelleği temizleyebilir
    • temel alınan nesnelerde, dizinlerde, istatistiklerde veya diğer bağımlılıklarda yapılan bazı değişiklikler yeniden derlemeyi tetikledi
  • diğer kullanıcılardan veya önceki çağrılardan farklı bir plan elde edebilirsiniz, çünkü:
    • sorgu metni aynı olmayabilir (büyük / küçük harf duyarlılığı ve boşluk içerir , farklı sütunları dikkate almayın, birleştirme ölçütleri, filtreler vb.)
    • (planındaki herhangi bir nesne tam nitelikli adını yoksa, ya da farklı bir varsayılan şemalar sorgu farklı set seçenekleriyle farklı kullanıcılar tarafından işletilen olabilir şema dahil )
  • sorgu ve plan aynı olabilir, ancak farklı performans elde ediyor olabilirsiniz çünkü:
    • plan farklı parametreler kullanılarak önbelleğe alındı ​​ve bu plan geçerli parametre seti için uygun değil (buna genellikle "parametre koklama" denir)
    • parametrelere dayalı veya sadece bu arada veri değişikliği nedeniyle veri miktarı önemli ölçüde farklıdır
    • veriler, verilere erişmenin en etkili yolunu değiştirecek kadar değişti, ancak istatistik güncellemelerini veya yeniden derlemeleri tetiklemek için yeterli değil (artan önemli sorunu ve otomatik istatistik algoritmasını arayın)
    • veriler arabellek havuzundan çıkarıldı ve şimdi diskten okunmalıdır
    • sorguyu yerine getirmek için gereken kaynaklar üzerinde daha yüksek eşzamanlılık, engelleme veya diğer zorluklar var

Bunların çoğunu burada daha ayrıntılı olarak inceliyorum:

Bunlar farklı ortamlarda çalışıyorsa, burada kontrol edilecek bir sürü şeyim var:

Ayrıca, bir dizin oluşturmanın veya sorguyu değiştirmenin, bir sorgunun birdenbire daha iyi performans göstermesinin doğrudan nedeni olmadığını akılda tutmak önemlidir - bazen sadece bu değişikliklerin gerçekten yeni bir plan oluşturması ve / veya zaten var olan planı geçersiz kılması .


7

Her zamanki gibi Aaron Bertrand ve Kin mükemmel cevaplar verdiler. Ancak her iki cevap da ortak bir konu içerir. Her iki yanıtı da analiz ederseniz, XYZ'nin dün olduğu gibi çalışmamasının nedeninin X'in yaptığınız / yaptığınız bir şeyden kaynaklanmadığını göreceksiniz. İşlerin değişmesinin nedeni, veritabanının XYZ nedeniyle farklı şeyler yapmaya karar vermesidir.

Bir veritabanı yaşayan, nefes alan bir varlıktır . Veritabanları, varsayımlar, istatistikler ve diğer sezgisel araçların birleşimi nedeniyle kararlar alacak ve fikrini değiştirecektir. Bu, çoğu uygulama katmanı programlamasından önemli ölçüde farklıdır (makine öğrenimi dikkate değer bir istisnadır).

Bazı askeri referansları kullanacağım çünkü şu anda daha iyi bir şey düşünemiyorum. Daha genel bir metafor takdir edilecektir (cinas amaçlanmamıştır).

Çoğu uygulamada programcı bir Matkap Eğitmeni olarak görev yapar. Bilgisayara tam olarak ne yapılacağını, hangi sırada ve bazen ne kadar süreyle yapılacağını söylerler . Bir veritabanının programlanması daha çok Komuta Görevlisi gibi davranmaya benzer. Yüksek seviyede ne yapmasını istediğinizi söyleyin ve gerektiğinde bazı önerilerde bulunun. Veritabanı, gençler ve görevlendirilmemiş memurlar gibi mevcut istihbarata dayalı olarak planı yürütmenin en iyi yolunu bulmakla görevlidir.

Bu ayrımı diğer programcıların zihninde açıklığa kavuşturarak, umarım çevrelerinde olduğu gibi dikte edici güçlerinizin olmadığını görmeye başlayacaklardır. Veritabanını çözüme yönlendiriyorsunuz ve bazen veritabanı iyi veya kötü nedenlerden dolayı yoldan çıkıyor. Sonuçta, veritabanının neden * gitmediğinin önemli olmadığını, ancak geri getirmek için neler yapabileceğimizi hatırlatın.

* "Neden" in gelecekteki önleme, öğrenme vb. İçin çok değerli olduğunu biliyorum, ancak OP sorun hakkında bilgi edinmeye veya yardım etmeye çalışmayan insanların direnişiyle karşı karşıya gibi görünüyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.