Le modifiche allo schema "interrompono" i gruppi di disponibilità o vengono gestiti in modo trasparente?

La mia organizzazione sta pianificando di adottare i gruppi di disponibilità di SQL Server 2012 e sto cercando di capire quale impatto (se presente) avrà sul nostro processo di aggiornamento dell'applicazione.

Rilasciamo aggiornamenti dell'applicazione su un ciclo di 8 settimane e qualsiasi versione potrebbe includere modifiche allo schema e / o migrazioni di dati.

Quello che sto cercando di capire è se la soluzione HA / DR gestisce o meno le modifiche dello schema in modo trasparente (nuove colonne, indici vengono aggiunti ai secondari) o è necessario un intervento manuale per creare lo schema su ciascuna istanza e quindi riattivare Always On.

Il pezzo di migrazione dei dati che presumo sia gestito in modo trasparente ma vorrei confermarlo.

Immagino anche di supporre che non ci siano differenze in questi comportamenti in base alla configurazione dei gruppi di disponibilità, che potrebbe anche essere falsa. Per favore mi faccia sapere.

In poche parole; In una determinata versione della mia applicazione, posso modificare una tabella molto grande (da 10 a 100 milioni di record) aggiungendo colonne ad essa. Alcune colonne possono essere "nette nuove" in modo che possano utilizzare la funzionalità di modifica dello schema di Enterprise Online. Altre colonne possono essere un refactoring di una colonna esistente (FullName viene suddiviso in FirstName e LastName) e verrà eseguita una migrazione per ogni riga della tabella per popolare questi campi. Qualcuno di questi comportamenti richiede ai DBA di modificare la configurazione di AlwaysOn o è gestito per impostazione predefinita e tutti i secondari ottengono le istruzioni DDL e DML "gratuitamente"?

Grazie per la chiarezza che puoi fornire.

Le modifiche allo schema e le modifiche ai dati sono essenzialmente le stesse. Funziona come il mirroring tradizionale oggi: quello che è successo nel registro sul primario accade sul secondario. Non tutto ciò che accade a Las Vegas deve rimanere a Las Vegas. :-)

Dove potresti voler stare attento, è quando hai un'applicazione che punta al primario e lo aggiorni per abbinare le modifiche dello schema. Ma potresti avere un'applicazione diversa che punta al secondario (ad esempio con intento di sola lettura) e che anche la modifica dell'app dovrebbe essere sincronizzata.

Un altro potenziale gotcha è quando il database che fa parte di un gruppo di disponibilità ha riferimenti ad oggetti in altri database (ad esempio una tabella di ricerca statica memorizzata in un database di utilità). Se questi cambiano e l'AG dipende da quegli oggetti, dovrai spingerli manualmente. Lo stesso vale per lavori, accessi a livello di server, server collegati, ecc., Tutto ciò che vive al di fuori del database e / o non è trasferibile. Gli utenti del database possono rimanere orfani (a parte gli utenti contenuti). So che questo è probabilmente ovvio, ma volevo elencarlo esplicitamente per completezza.

Altre risposte qui da Remus, gli utenti chiedono eventualmente di rimuovere le query sulla replica secondaria e controllare lo stato della dimensione della coda di ripetizione nella tabella: sys.dm_hadr_database_replica_states AlwaysOn DDL e modifiche dello schema