Modifiche allo schema nei database di pubblicazione
Data aggiornamento: 14 aprile 2006
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 Microsoft SQL Server, tale modifica viene propagata per impostazione predefinita a tutti i Sottoscrittori SQL Server:
- ALTER TABLE
- 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 della replica in Transact-SQL: How to: Replicate Schema Changes (Replication Transact-SQL Programming)
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.
- 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. La colonna può essere modificata prima della generazione dello snapshot. Per modificare la colonna, è innanzitutto necessario 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 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 How to: Define and Modify a Column Filter (Replication Transact-SQL Programming) 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 nella colonna Identity nel server di pubblicazione dipendono dall'ordine in cui le righe della tabella interessata vengono fisicamente archiviate. È 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 How to: Define and Modify a Column Filter (Replication Transact-SQL Programming) 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 propagate ai Sottoscrittori non SQL Server provocano la reinizializzazione del Sottoscrittore.
- Le modifiche dello schema non vengono propagate dai server di 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 How to: Quiesce a Replication Topology (Replication Transact-SQL Programming).
- 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
- Per replicare le modifiche dello schema, è necessario che il livello di compatibilità della pubblicazione sia almeno 90RTM. Per ulteriori informazioni, vedere la sezione relativa al livello di compatibilità per le pubblicazioni di tipo merge nell'argomento Utilizzo di più versioni di SQL Server in una topologia di replica. Se nei Sottoscrittori sono in esecuzione versioni precedenti di SQL Server o se il livello di compatibilità è inferiore a 90RTM, è comunque possibile utilizzare sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) per aggiungere ed eliminare colonne.
- 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).
Cronologia delle modifiche
Versione | Cronologia |
---|---|
14 aprile 2006 |
|
Vedere anche
Concetti
Pubblicazione di dati e oggetti di database
Rigenerazione di procedure transazionali personalizzate per riflettere le modifiche dello schema
Altre risorse
ALTER TABLE (Transact-SQL)
ALTER VIEW (Transact-SQL)
ALTER PROCEDURE (Transact-SQL)
ALTER FUNCTION (Transact-SQL)
ALTER TRIGGER (Transact-SQL)