Şema değişiklikleri Kullanılabilirlik Gruplarını “kırıyor” mu yoksa şeffaf olarak mı ele alınıyor?

Kuruluşum SQL Server 2012 Kullanılabilirlik Gruplarını benimsemeyi planlıyor ve uygulama yükseltme sürecimiz üzerinde (varsa) ne gibi etkileri olacağını anlamaya çalışıyorum.

Uygulama güncellemelerini 8 haftalık bir döngüde yayınlarız ve herhangi bir sürümde şema değişiklikleri ve / veya veri geçişleri bulunabilir.

Anlamaya çalıştığım HA / DR çözümünün şema değişikliklerini şeffaf bir şekilde işleyip işlemediğini (yeni sütunlar, dizinler ikincil öğelere eklenir) ya da her örnekte şema oluşturmak ve sonra Her Zaman Açık'ı açmak için manuel müdahalenin gerekli olup olmadığıdır.

Kabul ettiğim veri taşıma parçası şeffaf bir şekilde işleniyor ancak bunu da onaylamak istiyor.

Sanırım bu davranışlarda, Kullanılabilirlik Grupları yapılandırmasına bağlı olarak yanlış olabilecek bir fark olmadığını da varsayıyorum. Lütfen bana haber ver.

Kısaca; Uygulamamın herhangi bir sürümünde, sütunları ekleyerek çok büyük bir tabloyu (10 ila 100 milyon kayıt) değiştirebilirim. Bazı sütunlar "Net new" olabilir, böylece Enterprise Online şema değişikliği işlevini kullanabilirler. Diğer sütunlar, var olan bir sütunun yeniden düzenlenmesi olabilir (FullName, FirstName ve LastName olarak bölünür) ve tablodaki her satır için bu alanları doldurmak üzere bir taşıma çalıştırılır. Bu davranışlardan herhangi biri, DBA'ların AlwaysOn yapılandırmasını değiştirmesini gerektiriyor mu veya bu varsayılan olarak ele alınıyor ve tüm ikincil öğeler DDL ve DML deyimlerini "ücretsiz" alıyor?

Sağlayabileceğiniz her türlü netlik için teşekkür ederiz.

Şema değişiklikleri ve veri değişiklikleri aslında aynıdır. Bugün geleneksel yansıtma gibi çalışır: birincil kayıtta olanlar ikincil olayda olur. Vegas'ta olan her şey Vegas'ta kalmak zorunda değil. :-)

Dikkatli olmak isteyebileceğiniz yer, birincil öğeye işaret eden bir uygulamanız olduğunda ve bunu şema değişiklikleriyle eşleşecek şekilde güncelleştirdiğiniz zamandır. Ancak ikincil öğeyi işaret eden farklı bir uygulamanız olabilir (örneğin salt okunur niyetle) ve bu uygulama değişikliğinin de senkronize edilmesi gerekir.

Bir başka potansiyel sorun, kullanılabilirlik grubunun bir parçası olan veritabanınızın diğer veritabanlarındaki nesnelere (örneğin, bir yardımcı program veritabanında depolanan statik arama tablosu) referansları olmasıdır. Bunlar değişirse ve AG bu nesnelere bağlıysa, bu değişiklikleri manuel olarak zorlamanız gerekir. Aynı durum, işler, sunucu düzeyi oturum açma bilgileri, bağlı sunucular vb. İçin de geçerlidir - veritabanı dışında yaşayan ve / veya işlenemeyen her şey. Veritabanı kullanıcıları yetim kalabilir (içerilen kullanıcılar bir yana). Bunun muhtemelen açık olduğunu biliyorum ama bütünlük için açıkça listelemek istedim.

Remus'tan daha fazla yanıt, kullanıcılar ikincil çoğaltma ile ilgili sorguları kaldırmayı ve tablodaki yeniden sıra boyutu durumunu kontrol etmelerini istiyor: sys.dm_hadr_database_replica_states AlwaysOn DDL ve Şema Değişiklikleri