Tedarikçi, İş Başvurusu için her 5 dakikada bir MSDB işini çalıştırmak istiyor


15

Her iki DB'nin SQL Server örneğimizde 150'den fazla başka DB ile bulunduğu 2 farklı uygulamayı entegre etmeye çalışan bir üçüncü taraf tedarikçimiz var ve 2 farklı uygulamayı her 5 dakikada bir "senkronize etmek" için bir MSDB işi oluşturmak istiyorlar. her dakika çalıştırmak istedim).

Benim ilk önsezi, bunun yerine bir şekilde Windows zamanlanmış bir iş, hatta belki de korkunç bir tetikleyici (bu gibi durumlarda başvurduğumuz) ile Uygulama katmanında bir şekilde yapmaları gerektiğidir.

MSDB işlerini orada dağınıklığı azaltmak için DBA görevleri için mümkün olduğunca ayırmayı tercih ediyorum ve ayrıca bu gibi süper aktif işlerle iş geçmişlerini görüntülerken MSDB'nin yavaş sorgulanmasıyla da karşılaştım ( yedekleme geçmişleri gibi daha önemli şeyler). Ama sonra tekrar, belki benim tercihlerim yanlış ve MSDB Uygulama katmanı için biraz yer yapmak ve kolları sıvamış ve iş geçmişleri sorunları yakalamak için çok daha fazla tarih girişleri tutmak gerektiğinde yüklemek için sonsuza kadar alarak düzeltmek gerekir yedekleme gibi önemli şeyler (veya hiper aktif iş girişlerini temizleme).

Sahip olduğum başka bir sorun, şimdi GUI aracılığıyla yükseltmelerini gerçekleştirdiklerinde ve görevimin kritik olduğu yerde havaya uçmadıklarını umduklarında, yalnızca DB'lerinde yalnızca "dbo" hakları yerine bu satıcının "sysadmin" haklarını vermesi gerektiğidir. DB'ler (konsolidasyonun dezavantajlarından biridir).

Ben biz güzel oyun olmayan tüm satıcıları koymak başka bir "izole" Örneğin koyabilirsiniz tahmin ediyorum, ama o zaman yeni bir SQL örneğine noktasına Uygulamaları (yeniden gerek nefes bu durumda maalesef önemsiz değil).

Satıcı zaten tetikleyicilerin ne kadar kötü olduğu hakkında konuşurken endişelerimi geri itti. Bu yüzden, biraz "googled" ve boş geldi. Herkes orada kötü bir fikir olduğunu "otoriter görünümlü" herhangi bir bağlantı gördü ve ben ona başvurabilir miyim? Yoksa yaklaşımlarını benimsemeliyim?

Yardım istemeden önce bir sql forumunda yayınladığımı sanmıyorum, bu yüzden umarım araştırmam düzgün bir şekilde çerçevelenmiştir.

EDIT: SQL Server 2008 Enterprise R2 x64 SP1 çalıştırıyoruz (sürümü belirtmeyi unuttum işaret ettiğin için teşekkürler!). Hmmm, umarım daha yeni bir sürüme gittiğimizde MSDB yükseltme komut dosyalarını değiştirmeleri gerekmez.

Zaman ayırdığınız için teşekkürler! Zengin


Güzel ifade. Belki de kullandığınız belirli bir versiyona sahip bir etiket ekleyebilirsiniz (ve ayrıca soruda baskıdan da bahsedebilirsiniz.) Standard ve Enterprise arasında farklılıklar olup olmadığından emin değilsiniz, ancak alakalı olabilir.
ypercubeᵀᴹ

Her zaman işi kendi geçmişini temizlemeyi söyleyebilirsiniz (MSDB tablolarından kolayca silebilirsiniz), bu nedenle "geçmiş tablolarının yavaş sorgulanması" bir faktör olmamalıdır. Harici bir sürecin bununla başa çıkmasına izin vermekten daha fazla endişelenirim, çünkü tarih üzerinde daha az kontrole sahip olurdum. Ayrıca 5 dakika "yeterince akım" ise, neden her bir DML işlemini gerçek zamanlı olarak etkileyecek tetikleyicilere dönelim?
Aaron Bertrand

Not: İş işlevselliğini gerçekten değiştirmedikçe 2008 R2 ile 2012 arasında herhangi bir iş oluşturma komut dosyasında herhangi bir değişiklik olacağından şüpheliyim (bazı yeni özelliklerden yararlanmadığı sürece sürüme özgü bir şey olmaz). İş betiğinin kendisi değişmemelidir.
Aaron Bertrand

2
sysadminOnlara SQL aracısı işlerini değiştirmelerine izin vermek zorunda değilsiniz - msdn.microsoft.com/en-us/library/ms188283(v=sql.105).aspx
SQLFox

Herkese hızlı yanıt için teşekkürler! Yaklaşımlarını kucaklayacağım ve onlara sysadmin vermemeyle birlikte tasfiyeye bakacağım.
rzuech

Yanıtlar:


12

Tedarikçiniz IMO aslında doğru yolda.

Bir uygulama katmanı işi, çok sayıda kullanıma hazır SQL Agent özelliğini (örneğin, zaten çalışan bir işi çalıştırmama mantığı, bir güvenlik ve kimlik bilgileri deposu çözümü bulması, iş sonuçlarını hata raporlaması ve SQL vb. vb. sonuç takibi). Ve en önemlisi, zamanlama için bir yedekleme / HA / DC çözümü sağlayın. Sen istemiyoruz sizin felaket kurtarma hikayesi olmak 've bu 50 NT zamanlayıcı görevler oluşturmak gidip bekleme sunucusu kurtarma tamamladıktan sonra'. Bu yüzden sistem zamanlayıcısını kullanmaya karşı geri itme konusunda haklı, Agent'ın sahip olduğu özellik ve yeteneklerden hiçbir şey yok.

Tetikleyicilere karşı geri itme konusunda daha da haklıdır. Eşzamanlı bir tetikleyici ile periyodik bir işin değiştirilmesi, istek gecikmesini artırır, uyum ve eşleşmeyi artırır (şema değişikliklerini düşünün ...), eşitleme sorunlarından kaynaklanan kesinti riskini artırır (tetikleme hatası-> uygulama hatası - iş hatası-> düzelt ve daha sonra tekrar dene) , kilitlenme sorunlarını (paletli / izleyici arasındaki çapraz güncellemeler nedeniyle) önemli ölçüde artırır ve daha birçok problemi vardır.

En kolay çözüm aslında bir Ajan işi ve msdbhiçbir şekilde DBA'lar için ayrılmıyor. Daha süslü bir çözüm , öncelikli olarak kontrolden dolayı (her şey uygulama DB'sinde, yük devretme senaryolarını yansıtmayı düşünüyorum) Ajan işleri üzerinde bazı avantajlara sahip olan konuşma zamanlayıcılarını ve dahili aktivasyonu kullanmak olacaktır, ancak satıcınızın çok özel bir bilgi birikimi gerektiren bir şey denemeye isteksiz. BTW Umarım DB başına her 5 dakikada bir iş anlamına gelmez .

Sysadmin izinlerine gelince: oyunun adı kod imzalamadır . Sizin tarafınızdan denetlenen ve onaylanan özel prosedürlere, özel sertifikanızla imzalayarak izin verebilirsiniz.


Yığın Taşması konusundaki cevabınızın, konuşma zamanlayıcılarına ve dahili aktivasyona bir örnek gösteren bir bağlantısı: stackoverflow.com/a/4079716
Jon Seigel

1
Bunu fikir birliği gibi görünen kabul edilmiş cevap olarak işaretledim. Tüm bunlardan uzaklaştığım en büyük şey, Uygulamaların sık sık MSDB işlerini kullanması sorun değil ve sadece güvenlik için uygun bir şekilde yapmak için burada verilen bağlantıları kullanmam gerekecek. Herkes çok anlayışlı ve yorumlarınız ve zamanınız için teşekkürler!
rzuech

2

Kişisel tercihim, senkronizasyonun en azından bir kısmını işlemek için tetikleyiciler kullanmak olacaktır. Potansiyel çakışmalar, eski veriler, tekrarlanan işin performans etkisi, vb. İle uğraşmak zorunda olduğunuz için özellikle planlı yoklama senkronizasyonunu önemsemiyorum. 1 ila 5 dakika kadar agresif bir şekilde yapmak istiyorlarsa çatışmaları ve sadakati hafifletmek ve bir tetikleyicinin aciliyeti bunu ele alacaktı.

Her şey aynı sunucuda gerçekleşiyorsa, muhtemelen senkronizasyon kodunu tetikleyicilerin içine koymanız veya tetikleyicilerin etkilenen her kaydı senkronize eden saklı bir prosedürü çağırmasını sağlamanız gerekir. Senkronizasyon sunuculara yayılıyorsa veya bir veritabanının çevrimdışı olmasının diğer veritabanının kullanılabilir olmasını engellemediğinden emin olmak istiyorsanız, zaman uyumsuz güncellemeleri işlemek için Service Broker'ı kullanın. Bunu, satış girişi rakamlarını iki farklı sunucu arasındaki CRM verileriyle senkronize ederken, her iki sunucunun da diğer uygulamayı etkilemeden çevrimdışı olmasına izin vermek için yaptım. Yedeklendiğinde, Service Broker iletileri dağıtır ve uzak sunucudaki verileri günceller.

Ve tetikleyiciler hakkında gerçekten kötü bir şey yok, ancak T-SQL'in çoğu yönü gibi, korkunç performans gösteren kod yazmak çok mümkün. Eğer yardımcı olursa, tetikleyicilerin ortak tuzakları hakkında bir makale yazdım.

İyi Davalı Tetikleyiciler Yazma


Evet, 2 DB aynı sunucu örneğinde. Şahsen ben de tetikleyicileri yapardım ve Uygulamaları orada oldukça ağır görev DB bazı göre oldukça küçük patates. Ancak, MSDB işlerini Uygulama senkronizasyonu için kullanmama konusunda gerçekten "en iyi uygulama" öğelerine gerçekten işaret edemediğim için satıcıyı gerçekten ikna edebileceğimi sanmıyorum. Ayrıca Aaron'un fikrine biraz saygı duyuyorum, bu yüzden onlara baskı yapmayacağım. db2 Bağlantınızı okudum ve oldukça bilgilendirici buldum ve Service Broker bile düşünmediğim iyi bir seçenek. Teşekkürler!
rzuech

Evet, tetikleyicilerin başarısız olmasından endişe ediyorsanız (çevrimdışı veritabanı, şema değişiklikleri, vb.), O zaman Service Broker anlık senkronizasyon istediğinizi (yakın) varsayarsak gitmenin yoludur.
db2
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.