Czy zmiany schematu „niszczą” grupy dostępności, czy też są obsługiwane w sposób przejrzysty?

Moja organizacja planuje przyjęcie grup dostępności programu SQL Server 2012 i staram się zrozumieć, jaki będzie to wpływ (jeśli w ogóle) na proces aktualizacji aplikacji.

Wydajemy aktualizacje aplikacji w cyklu 8-tygodniowym, a każda wersja może zawierać zmiany schematu i / lub migracje danych.

Próbuję zrozumieć, czy rozwiązanie HA / DR obsługuje przejrzyste zmiany schematu (nowe kolumny, indeksy są dodawane do pomocniczych), czy też wymagana jest ręczna interwencja, aby utworzyć schemat w każdej instancji, a następnie ponownie włączyć Always On.

Zakładam, że migracja danych jest obsługiwana w przejrzysty sposób, ale chciałbym to również potwierdzić.

Wydaje mi się, że przyjmuję również ogólne założenie, że nie ma różnicy w tych zachowaniach w zależności od konfiguracji grup dostępności, co również może być fałszywe. Proszę daj mi znać.

W skrócie; W dowolnym wydaniu mojej aplikacji mogę zmienić bardzo dużą tabelę (od 10 do 100 milionów rekordów), dodając do niej kolumny. Niektóre kolumny mogą być „nowe netto”, więc mogą korzystać z funkcji zmiany schematu Enterprise Online. Inne kolumny mogą być refaktoryzacją istniejącej kolumny (FullName zostanie podzielona na FirstName i LastName), a migracja zostanie uruchomiona dla każdego wiersza w tabeli, aby wypełnić te pola. Czy któreś z tych zachowań wymaga DBA do zmiany konfiguracji AlwaysOn czy jest to obsługiwane domyślnie, a wszystkie pomocnicze pobierają instrukcje DDL i DML „za darmo”?

Dziękujemy za wszelkie wyjaśnienia, które możesz zapewnić.

Zmiany schematu i zmiany danych są zasadniczo takie same. Działa to tak jak tradycyjne tworzenie kopii lustrzanych: to, co stało się w dzienniku głównym, dzieje się na wtórnym. Nie wszystko, co dzieje się w Vegas, musi pozostać w Vegas. :-)

Należy zachować ostrożność, gdy masz aplikację wskazującą na podstawową i aktualizujesz ją, aby dopasować zmiany schematu. Ale możesz mieć inną aplikację, która wskazuje na pomocniczą (np. Z zamiarem tylko do odczytu), i ta zmiana aplikacji również musiałaby zostać zsynchronizowana.

Innym potencjalnym problemem jest sytuacja, gdy baza danych, która jest częścią grupy dostępności, zawiera odwołania do obiektów w innych bazach danych (np. Statyczna tabela wyszukiwania przechowywana w bazie danych narzędzi). Jeśli te się zmienią, a AG zależy od tych obiektów, będziesz musiał ręcznie wprowadzić te zmiany. To samo dotyczy zadań, loginów na poziomie serwera, połączonych serwerów itp. - wszystko, co znajduje się poza bazą danych i / lub nie podlega transakcji. Użytkownicy bazy danych mogą zostać osieroceni (użytkownicy zamknięci na bok). Wiem, że jest to prawdopodobnie oczywiste, ale chciałem to wyraźnie wymienić.

Więcej odpowiedzi tutaj od Remusa, użytkownicy proszą o ewentualne usunięcie zapytań na replice wtórnej i sprawdzenie stanu wielkości kolejki w tabeli: sys.dm_hadr_database_replica_states AlwaysOn DDL i zmiany schematu