Apporta modifiche allo schema nei database delle pubblicazioni

Si applica a:SQL Server e Istanza gestita di SQL di Azure

La replica supporta una vasta gamma di modifiche dello schema negli oggetti pubblicati. Quando si apporta una delle seguenti modifiche dello schema nell'oggetto pubblicato appropriato nel server di pubblicazione Microsoft SQLServer, tale modifica viene propagata per impostazione predefinita a tutti i Sottoscrittori SQLServer:

  • ALTER TABLE

  • ALTER TABLE SET LOCK ESCALATIONnon dovrebbe essere utilizzato se la replica di cambio di schema è abilitata e una topologia include SQL Server 2005 (9.x) o SQL Server Compact 3.5 Subscribers.

  • ALTER VIEW

  • ALTER PROCEDURE

  • ALTER FUNCTION

  • ALTER TRIGGER

    ALTER TRIGGER può essere utilizzato solo per i trigger del linguaggio di manipolazione dei dati (DML), perché i trigger del linguaggio di definizione dei dati (DDL) non possono essere replicati.

Importante

Devi apportare modifiche allo schema alle tabelle usando Transact-SQL o SQL Server Management Objects (SMO). Quando apporti modifiche allo schema in SQL Server Management Studio, Management Studio cerca di rimuovere e ricreare la tabella. Non puoi rimuovere oggetti pubblicati, quindi il cambio di schema fallisce.

Per la replica transazionale e di tipo merge, le modifiche dello schema vengono propagate in modo incrementale quando l'agente di distribuzione o l'agente di merge è in esecuzione. Per la replica tramite snapshot, le modifiche dello schema vengono propagate quando un nuovo snapshot viene applicato al Sottoscrittore. Nella replica snapshot, una nuova copia dello schema viene inviata al Sottoscrittore ogni volta che viene eseguita la sincronizzazione. Pertanto, tutte le modifiche allo schema (non solo quelle elencate in precedenza) agli oggetti precedentemente pubblicati vengono propagate automaticamente con ogni sincronizzazione.

Per informazioni sull'aggiunta e l'eliminazione di articoli nelle pubblicazioni, vedere Aggiungere ed eliminare articoli in pubblicazioni esistenti.

Per replicare le modifiche dello schema

Le modifiche allo schema elencate in precedenza sono replicate di default. Per informazioni sulla disabilitazione della replica delle modifiche dello schema, vedere Replicate Schema Changes.

Considerazioni per le modifiche dello schema

Quando si replicano le modifiche dello schema, tenere presenti le considerazioni seguenti.

Considerazioni generali

  • Le modifiche dello schema sono soggette a tutte le restrizioni imposte da Transact-SQL. Ad esempio, ALTER TABLE non permette di modificare le colonne chiave primarie.

  • La mappatura dei tipi di dati avviene solo per l'istantaneo iniziale. Le modifiche allo schema non corrispondono alle versioni precedenti dei tipi di dati. Ad esempio, se usi ALTER TABLE ADD datetime2 column SQL Server 2012 (11.x), il tipo di dato non si traduce in nvarchar per gli abbonati di SQL Server 2005 (9.x). In alcuni casi, le modifiche dello schema vengono bloccate nel server di pubblicazione.

  • Se imposti una pubblicazione per permettere la propagazione dei cambiamenti dello schema, essa propaga i cambiamenti dello schema indipendentemente da come imposti l'opzione di schema correlata per un articolo nella pubblicazione. Ad esempio, se si seleziona di non replicare i vincoli di chiave esterna per un articolo della tabella, ma si esegue un ALTER TABLE comando che aggiunge una chiave esterna alla tabella nella Publisher, la chiave esterna viene aggiunta alla tabella nel Sottoscrittore. Per prevenire questo comportamento, disabilita la propagazione dei cambiamenti di schema prima di emettere il ALTER TABLE comando.

  • Effettua modifiche allo schema solo presso l'Publisher, non sugli Abbonati (inclusi i ripubblichi degli Abbonati). La replica di tipo merge impedisce le modifiche dello schema nel Sottoscrittore. La replica transazionale non impedisce le modifiche, ma queste possono causare il fallimento della replica.

  • Per impostazione predefinita, le modifiche propagate a un Sottoscrittore di ripubblicazione vengono propagate ai relativi Sottoscrittori.

  • Se la modifica dello schema fa riferimento a oggetti o vincoli esistenti sull'Publisher ma non sull'Abbonato, la modifica dello schema ha successo sullo Publisher ma fallisce sull'Abbonato.

  • Tutti gli oggetti nel Sottoscrittore a cui si fa riferimento quando si aggiunge una chiave esterna devono avere lo stesso nome e lo stesso proprietario degli oggetti corrispondenti nel Publisher.

  • L'aggiunta, la rimozione o la modifica esplicita di indici non viene replicata. Devi eseguire qualsiasi modifica che coinvolga un indice esplicito su ogni set di repliche singolarmente. Gli indici creati in modo implicito per i vincoli, ad esempio un vincolo di chiave primaria, sono supportati.

  • Modificare o rimuovere colonne identità gestite dalla replica non è supportato. Per altre informazioni sulla gestione automatica di colonne Identity, vedere Replicare colonne Identity.

  • Le modifiche allo schema che includono funzioni non deterministiche non sono supportate perché possono portare a dati diversi presso Publisher e Subscriber (noto come non-convergenza). Ad esempio, se si esegue il comando seguente nel Publisher: ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), i valori sono diversi quando il comando viene replicato nel Subscriber ed eseguito. Per altre informazioni sulle funzioni non deterministiche, vedere Deterministic and Nondeterministic Functions.

  • Specifica esplicitamente i vincoli del nome. Se non nomini esplicitamente un vincolo, SQL Server genera un nome per il vincolo, e questi nomi sono diversi sia sull'Publisher che su ogni abbonato. Questa differenza può causare problemi durante la replicazione delle modifiche dello schema. Ad esempio, se si elimina una colonna nel Publisher e viene eliminato un vincolo dipendente, la replicazione tenta di eliminare il vincolo sull'Abbonato. L'eliminazione nel Subscriber non riesce perché il nome del vincolo è diverso. Se la sincronizzazione ha esito negativo per un problema di denominazione del vincolo, eliminare manualmente il vincolo nel Sottoscrittore e quindi eseguire nuovamente l'agente di merge.

  • Se pubblichi una tabella per la replica, non puoi modificare una colonna in quella tabella in un tipo di dato XML se hai già generato uno snapshot della pubblicazione. Per modificare la colonna, devi prima rimuovere la replicazione.

  • Read uncommitted non è un livello di isolamento supportato durante l'esecuzione di operazioni DDL su una tabella pubblicata.

  • Non usare SET CONTEXT_INFO per modificare il contesto delle transazioni in cui vengono effettuate modifiche allo schema su oggetti pubblicati.

Aggiunta di colonne

  • Per aggiungere una nuova colonna a una tabella e includerla in una pubblicazione esistente, esegui ALTER TABLE <Table> ADD <Column>. Per impostazione predefinita, la colonna viene quindi replicata a tutti i Sottoscrittori. La colonna deve permettere NULL valori o includere un vincolo predefinito. Per maggiori informazioni sull'aggiunta di colonne, consulta la sezione "Merge Replication" in questo articolo.

  • Per aggiungere una nuova colonna a una tabella e non includerla in una pubblicazione esistente, disabilita la replica delle modifiche dello schema e poi esegui ALTER TABLE <Table> ADD <Column>.

  • Per includere una colonna esistente in una pubblicazione esistente, usare sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) o la finestra di dialogo Proprietà pubblicazione - <Pubblicazione>.

    Per altre informazioni, vedere Define and Modify a Column Filter. Questa azione richiede la riinizializzazione degli abbonamenti.

  • L'aggiunta di una colonna identità a una tabella pubblicata non è supportata, perché può portare a non convergenza quando la colonna viene replicata all'Abbonato. I valori della colonna Identity nel server di pubblicazione dipendono dall'ordine in cui vengono fisicamente archiviate le righe della tabella interessata. Nel caso in cui le righe siano state archiviate in modo diverso nel Sottoscrittore, il valore della colonna Identity può essere diverso per le stesse righe.

Colonne che si abbattono

  • Per eliminare una colonna da una pubblicazione esistente e rimuovere la colonna dalla tabella presso l'Publisher, eseguire ALTER TABLE <Table> DROP <Column>. Per impostazione predefinita, la colonna viene quindi eliminata dalla tabella in tutti i Sottoscrittori.

  • Per eliminare una colonna da una pubblicazione esistente, ma mantenerla nella tabella del server di pubblicazione, usare sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) o la finestra di dialogo Proprietà pubblicazione - <Pubblicazione>.

    Per altre informazioni, vedere Define and Modify a Column Filter. Questa azione richiede di generare una nuova istantanea.

  • Non puoi usare la colonna per inserire le clausole filtro di qualsiasi articolo di qualsiasi pubblicazione nel database.

  • Quando si elimina una colonna da un articolo pubblicato, considera eventuali vincoli, indici o proprietà della colonna che potrebbero influenzare il database. Ad esempio:

    • Non puoi rimuovere colonne usate in una chiave primaria dagli articoli nelle pubblicazioni transazionali, perché la replica le utilizza.

    • Non puoi eliminare la rowguid colonna dagli articoli nelle pubblicazioni di fusione o la mstran_repl_version colonna dagli articoli nelle pubblicazioni transazionali che supportano l'aggiornamento degli abbonamenti, perché la replica li utilizza.

    • Le modifiche dell'indice non vengono propagate agli Abbonati. Se si elimina una colonna nel server di pubblicazione e viene eliminato un indice dipendente, l'eliminazione dell'indice non viene replicata. È necessario eliminare l'indice nel Sottoscrittore prima di eliminare la colonna nel server di pubblicazione, in modo che l'eliminazione della colonna abbia esito positivo quando viene replicata dal server di pubblicazione al Sottoscrittore. Se la sincronizzazione non riesce a causa di un indice nel Sottoscrittore, eliminare manualmente l'indice nel Sottoscrittore e quindi eseguire nuovamente l'agente di merge.

    • Assegna un nome ai vincoli in modo esplicito, così da poterli eliminare. Per maggiori informazioni, consulta la sezione "Considerazioni Generali" all'inizio di questo articolo.

Replicazione transazionale

  • Le modifiche dello schema vengono propagate ai Sottoscrittori in cui sono in esecuzione versioni precedenti di SQL Server, ma l'istruzione DDL deve includere solo la sintassi supportata dalla versione nel Sottoscrittore.

    Se il Sottoscrittore ripubblica i dati, le uniche modifiche dello schema supportate sono l'aggiunta e l'eliminazione di una colonna. Apporta queste modifiche sul Publisher usando sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) invece della ALTER TABLE sintassi DDL.

  • Le modifiche allo schema non vengono replicate agli abbonati non SQL Server.

  • Le modifiche allo schema non vengono propagate da publisher non SQL Server.

  • Non puoi modificare le viste indicizzate che vengono replicate come tabelle. È possibile modificare le viste indicizzate replicate come viste indicizzate, ma la loro modifica le fa diventare viste normali anziché viste indicizzate.

  • Se la pubblicazione supporta aggiornamenti immediati o sottoscrizioni con aggiornamento in coda, metti il sistema in stato di quiescenza prima di apportare modifiche allo schema: arresta ogni attività sulla tabella pubblicata nel Publisher e nei Subscribers e propaga a tutti i nodi le modifiche ai dati in sospeso. Dopo che i cambiamenti dello schema si propagano a tutti i nodi, l'attività può riprendere sulle tabelle pubblicate.

  • Se la pubblicazione è in una topologia peer-to-peer, mettere il sistema in modalità quiesce prima di apportare modifiche allo schema. Per altre informazioni, vedere Come mettere una topologia di replica in stato di inattività (programmazione Transact-SQL della replica).

  • L'aggiunta di una colonna timestamp a una tabella e la mappatura del timestamp a binary(8) comportano la reinizializzazione dell'articolo per tutte le sottoscrizioni attive.

Replica di tipo merge

  • Il modo in cui la replica di fusione gestisce le modifiche dello schema dipende dal livello di compatibilità con la pubblicazione e dal fatto che lo snapshot sia impostato in modalità nativa (predefinita) o in modalità carattere:

    • Per replicare le modifiche dello schema, imposta il livello di compatibilità con la pubblicazione ad almeno 90RTM. Se gli abbonati usano versioni precedenti di SQL Server o il livello di compatibilità è inferiore a 90RTM, usa sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) per aggiungere e rimuovere colonne. Tuttavia, queste procedure sono deprecate.

    • Se si tenta di aggiungere a un articolo esistente una colonna con un tipo di dati introdotto in SQL Server 2008 (10.0.x), SQL Server presenta il comportamento seguente:

      100RTM, snapshot nativo 100RTM, istantanea del carattere Tutti gli altri livelli di compatibilità
      hierarchyid Consenti modifica Modifica bloccata Modifica bloccata
      geografia e geometria Consenti modifica Consenti modifica* Modifica bloccata
      filestream Consenti modifica Modifica bloccata Modifica bloccata
      date, time, datetime2e datetimeoffset Consenti modifica Consenti modifica* Modifica bloccata

      *I sottoscrittori di SQL Server Compact convertono questi tipi di dati presso il sottoscrittore.

  • Se si verifica un errore quando si applica una modifica dello schema, ad esempio un errore dovuto all'aggiunta di una chiave esterna che fa riferimento a una tabella non disponibile nel Sottoscrittore, la sincronizzazione ha esito negativo ed è necessario reinizializzare la sottoscrizione.

  • Se si apporta una modifica dello schema in una colonna coinvolta in un filtro join o in un filtro con parametri, è necessario reinizializzare tutte le sottoscrizioni e rigenerare lo snapshot.

  • La replica di tipo merge offre stored procedure che consentono di ignorare le modifiche dello schema durante la risoluzione dei problemi. Per altre informazioni, vedere sp_markpendingschemachange (Transact-SQL) e sp_enumeratependingschemachanges (Transact-SQL).

Contenuto correlato

  • Last updated on