Articolo
09/28/2010

Modifiche allo schema nei database di pubblicazione

La replica supporta numerose modifiche dello schema negli oggetti pubblicati. Quando si apporta una delle modifiche dello schema seguenti nell'oggetto pubblicato appropriato in un server di pubblicazione MicrosoftSQL Server, tale modifica viene propagata per impostazione predefinita a tutti i Sottoscrittori SQL Server:

ALTER TABLE
ALTER TABLE SET LOCK ESCALATION non deve essere utilizzato se la replica della modifica dello schema è abilitata e una topologia include SQL Server 2005 o SQL Server Compact 3.5 Subscribers.ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER

È possibile utilizzare ALTER TRIGGER solo per trigger [DML] (Data Manipulation Language), in quanto non è possibile replicare trigger [DDL] (Data Definition Language).

Importante
È necessario apportare le modifiche dello schema nelle tabelle tramite Transact-SQL o SQL Server Management Objects (SMO). Quando si apportano modifiche dello schema in SQL Server Management Studio, Management Studio tenta di eliminare e ricreare la tabella. Poiché non è possibile eliminare gli oggetti pubblicati, la modifica dello schema ha esito negativo.

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 snapshot, le modifiche dello schema vengono propagate quando viene applicato un nuovo snapshot 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 dello schema, non solo quelle elencate sopra, negli oggetti pubblicati in precedenza vengono automaticamente propagate con ogni sincronizzazione.

Per informazioni sull'aggiunta e la rimozione di articoli dalle pubblicazioni, vedere Aggiunta ed eliminazione di articoli a e da pubblicazioni esistenti.

Per replicare le modifiche dello schema

Le modifiche dello schema elencate sopra vengono replicate per impostazione predefinita. Per informazioni sulla disattivazione della replica delle modifiche dello schema, vedere gli argomenti seguenti:

SQL Server Management Studio: Procedura: Replica delle modifiche dello schema (SQL Server Management Studio)
Programmazione Transact-SQL della replica: Procedura: Replica delle modifiche dello schema (programmazione Transact-SQL della replica)

Considerazioni sulle 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. ALTER TABLE, ad esempio, non consente di eseguire l'istruzione ALTER per le colonne chiave primaria.
Il mapping dei tipi di dati viene eseguito solo per lo snapshot iniziale. Il mapping delle modifiche dello schema alle versioni precedenti dei tipi di dati non viene eseguito. Se ad esempio viene utilizzata l'istruzione ALTER TABLE ADD datetime2 column in SQL Server 2008, il tipo di dati non viene convertito in nvarchar per i Sottoscrittori di SQL Server 2005. In alcuni casi, le modifiche dello schema vengono bloccate nel server di pubblicazione.
Se si imposta una pubblicazione in modo da consentire la propagazione delle modifiche dello schema, queste ultime vengono propagate indipendentemente da come è impostata la relativa opzione dello schema per un articolo nella pubblicazione. Se, ad esempio, si sceglie di non replicare i vincoli di chiave esterna per un articolo di tabella, ma in seguito si esegue un comando ALTER TABLE che aggiunge una chiave esterna alla tabella nel server di pubblicazione, la chiave esterna viene aggiunta alla tabella nel Sottoscrittore. Per evitare questo problema, disattivare la propagazione delle modifiche dello schema prima di eseguire il comando ALTER TABLE.
Le modifiche dello schema devono essere apportate solo nel server di pubblicazione, non nei Sottoscrittori, inclusi i Sottoscrittori di ripubblicazione. La replica di tipo merge impedisce le modifiche dello schema nel Sottoscrittore. La replica transazionale non impedisce le modifiche, ma le modifiche possono provocare errori nella 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 nel server di pubblicazione, ma non nel Sottoscrittore, la modifica dello schema avrà esito positivo nel server di pubblicazione, ma negativo nel Sottoscrittore.
È necessario che il nome e il proprietario di tutti gli oggetti nel Sottoscrittore a cui si fa riferimento quando si aggiunge una chiave esterna siano gli stessi dell'oggetto corrispondente nel server di pubblicazione.
L'aggiunta, la rimozione e la modifica di indici in modo esplicito non sono supportate. Gli indici creati in modo implicito per i vincoli, ad esempio un vincolo di chiave primaria, sono supportati.
La modifica o l'eliminazione di colonne Identity gestite dalla replica non è supportata. Per ulteriori informazioni sulla gestione automatica di colonne Identity, vedere Replica di colonne Identity.
Le modifiche dello schema che includono funzioni non deterministiche non sono supportate, in quanto possono restituire dati diversi nel server di pubblicazione e nel Sottoscrittore, impedendo la convergenza. Se, ad esempio, si esegue il comando ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE() nel server di pubblicazione, i valori saranno diversi quando il comando viene replicato nel Sottoscrittore ed eseguito. Per ulteriori informazioni sulle funzioni non deterministiche, vedere Funzioni deterministiche e non deterministiche.
È consigliabile denominare i vincoli in modo esplicito. Se un vincolo non viene denominato in modo esplicito, SQL Server genera un nome per il vincolo, che sarà diverso nel server di pubblicazione e in ogni Sottoscrittore. Ciò può causare problemi durante la replica delle modifiche dello schema. Se ad esempio viene eliminata una colonna nel server di pubblicazione, insieme a un vincolo dipendente, il processo di replica tenterà di eliminare tale vincolo nel Sottoscrittore. L'eliminazione del vincolo nel Sottoscrittore non potrà tuttavia essere eseguita, poiché 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 viene pubblicata una tabella per la replica, non è possibile modificare una colonna in tale tabella impostando il tipo di dati XML se è già stato generato uno snapshot di pubblicazione. Per modificare la colonna, è necessario prima rimuovere la replica. Per ulteriori informazioni, vedere Rimozione della replica.

Aggiunta di colonne

Per aggiungere una nuova colonna a una tabella e includere tale colonna in una pubblicazione esistente, eseguire ALTER TABLE <Table> ADD <Column>. Per impostazione predefinita, la colonna viene quindi replicata a tutti i Sottoscrittori. È necessario che la colonna consenta i valori NULL o che includa un vincolo DEFAULT. Per ulteriori informazioni sull'aggiunta di colonne, vedere la sezione "Replica di tipo merge" in questo argomento.
Per aggiungere una nuova colonna a una tabella e non includere tale colonna in una pubblicazione esistente, disattivare la replica delle modifiche dello schema e quindi eseguire ALTER TABLE <Table> ADD <Column>.
Per includere una colonna esistente in una pubblicazione esistente, utilizzare sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) o la finestra di dialogo Proprietà pubblicazione - <Publication>.

Per ulteriori informazioni, vedere Procedura: Definizione e modifica di un filtro di colonna (programmazione Transact-SQL della replica) e Procedura: Definizione e modifica di un filtro di colonna (SQL Server Management Studio). Sarà necessario reinizializzare le sottoscrizioni.
L'aggiunta di una colonna Identity a una tabella pubblicata non è supportata, in quanto può impedire la convergenza quando la colonna viene replicata nel Sottoscrittore. I valori della colonna Identity nel server di pubblicazione dipendono dall'ordine in cui vengono fisicamente archiviate le righe della tabella interessata. È possibile che le righe vengano archiviate in modo diverso nel Sottoscrittore e pertanto il valore della colonna Identity può essere diverso per le stesse righe.

Eliminazione di colonne

Per eliminare una colonna da una pubblicazione esistente e dalla tabella nel server di pubblicazione, 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 nel server di pubblicazione, utilizzare sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) o la finestra di dialogo Proprietà pubblicazione - <Publication>.

Per ulteriori informazioni, vedere Procedura: Definizione e modifica di un filtro di colonna (programmazione Transact-SQL della replica) e Procedura: Definizione e modifica di un filtro di colonna (SQL Server Management Studio). Sarà necessario generare un nuovo snapshot.
La colonna da eliminare non può essere utilizzata nelle clausole di filtro degli articoli contenuti nelle pubblicazioni del database.
Quando si elimina una colonna da un articolo pubblicato, considerare eventuali vincoli, indici o proprietà della colonna che potrebbero avere conseguenze sul database. Ad esempio:
- Non è possibile eliminare le colonne utilizzate in una chiave primaria dagli articoli nelle pubblicazioni transazionali, in quanto vengono utilizzate dalla replica.
- Non è possibile eliminare la colonna rowguid dagli articoli nelle pubblicazioni di tipo merge o la colonna mstran_repl_version dagli articoli nelle pubblicazioni transazionali che supportano l'aggiornamento delle sottoscrizioni, in quanto queste colonne vengono utilizzate dalla replica.
- Le modifiche degli indici non vengono propagate ai Sottoscrittori. Se si elimina una colonna e un indice dipendente nel server di pubblicazione, 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.
- I vincoli devono essere denominati in modo esplicito per poter essere eliminati. Per ulteriori informazioni, vedere la sezione "Considerazioni generali" più indietro in questo argomento.

Replica 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. Queste modifiche devono essere apportate nel server di pubblicazione tramite sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) anziché la sintassi ALTER TABLE DDL.
Le modifiche dello schema non vengono propagate ai sottoscrittori non-SQL Server.
Le modifiche dello schema non vengono propagate dai server pubblicazione non SQL Server.
Non è possibile modificare le viste indicizzate replicate come tabelle. È possibile modificare le viste indicizzate replicate come viste indicizzate, ma la modifica ne comporta la trasformazione in viste normali.
Se la pubblicazione supporta le sottoscrizioni ad aggiornamento immediato o ad aggiornamento in coda, il sistema deve essere messo in stato di inattività prima di apportare modifiche dello schema: è necessario interrompere tutte le attività nella tabella pubblicata nel server di pubblicazione e nei Sottoscrittori e propagare a tutti i nodi le modifiche ai dati in sospeso. Dopo avere propagato a tutti i nodi le modifiche dello schema, è possibile riprendere le attività nelle tabelle pubblicate.
Se la pubblicazione si trova in una topologia peer-to-peer, è necessario mettere il sistema in stato di inattività prima di apportare modifiche dello schema. Per ulteriori informazioni, vedere Procedura: 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 il mapping tra timestamp e binary(8) provoca la reinizializzazione dell'articolo per tutte le sottoscrizioni attive.

Replica di tipo merge

La modalità di gestione delle modifiche dello schema da parte della replica di tipo merge è determinata dal livello di compatibilità della pubblicazione e dal fatto che lo snapshot sia impostato in modalità nativa (impostazione predefinita) o in modalità carattere:

Per replicare le modifiche dello schema, è necessario che il livello di compatibilità della pubblicazione sia almeno 90RTM. Se nei Sottoscrittori sono in esecuzione versioni precedenti di SQL Server o se il livello di compatibilità è inferiore a 90RTM, è possibile utilizzare sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) per aggiungere ed eliminare colonne. Tuttavia, queste procedure sono obsolete.

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

	100RTM, snapshot nativo	100RTM, snapshot carattere	Tutti gli altri livelli di compatibilità
hierarchyid	Modifica consentita	Modifica bloccata	Modifica bloccata
geography e geometry	Modifica consentita	Modifica consentita1	Modifica bloccata
filestream	Modifica consentita	Modifica bloccata	Modifica bloccata
date, time, datetime2 e datetimeoffset	Modifica consentita	Modifica consentita1	Modifica bloccata

1 I Sottoscrittori di SQL Server Compact convertono questi tipi di dati nel Sottoscrittore.

Per ulteriori informazioni sulla compatibilità delle pubblicazioni, vedere la sezione "Livello di compatibilità per le pubblicazioni di tipo merge" in Utilizzo di più versioni di SQL Server in una topologia di replica.

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 ulteriori informazioni, vedere sp_markpendingschemachange (Transact-SQL) e sp_enumeratependingschemachanges (Transact-SQL).