Sottoscrizioni aggiornabili - Per la replica transazionale

Si applica a:SQL Server

La replicazione transazionale supporta gli aggiornamenti presso i Sottoscrittori tramite sottoscrizioni aggiornabili e replica peer-to-peer. Di seguito sono indicati i due tipi di sottoscrizioni aggiornabili:

• Aggiornamento immediato. Per l'aggiornamento dei dati nel Sottoscrittore è necessario che il server di pubblicazione e il Sottoscrittore siano connessi.

• Aggiornamento in coda L'Editore e il Sottoscrittore non devono essere connessi per aggiornare i dati nel Sottoscrittore. Puoi aggiornare i dati mentre l'Abbonato o l'Publisher sono offline.

Quando aggiorni i dati presso un Abbonato, l'aggiornamento va prima all'Publisher e poi ad altri Abbonati. Se usi l'aggiornamento immediato, le modifiche vengono eseguite immediatamente utilizzando il protocollo di commit a due fasi. Se usi l'aggiornamento tramite coda, le modifiche vengono inserite in una coda. Le transazioni in coda vengono inviate allo Publisher in modo asincrono quando è disponibile la connettività di rete. Poiché gli aggiornamenti vengono inviati allo Publisher in modo asincrono, gli stessi dati possono essere aggiornati dall'Publisher o da un altro Abbonato e possono verificarsi conflitti durante l'applicazione degli aggiornamenti. Il sistema rileva e risolve i conflitti secondo una politica di risoluzione dei conflitti che hai impostato quando crei la pubblicazione.

Se si crea una pubblicazione transazionale con sottoscrizioni aggiornabili utilizzando la Creazione guidata Nuova pubblicazione, sono abilitati sia l'aggiornamento immediato sia l'aggiornamento in coda. Se si crea una pubblicazione con stored procedure, è possibile abilitare una o entrambe le opzioni. Quando si crea una sottoscrizione della pubblicazione, è necessario specificare la modalità di aggiornamento da utilizzare. Se necessario, sarà quindi possibile passare da una modalità di aggiornamento all'altra. Per ulteriori informazioni, vedere la sezione seguente "Passaggio da una modalità di aggiornamento all'altra".

Per abilitare abbonamenti aggiornabili per pubblicazioni transazionali, vedi Abilita l'aggiornamento degli abbonamenti per pubblicazioni transazionali.

Per creare abbonamenti aggiornabili per pubblicazioni transazionali, vedi Creare un abbonamento aggiornabile a una pubblicazione transazionale (Management Studio).

Passaggio tra modalità di aggiornamento

Quando usi abbonamenti aggiornabili, puoi specificare una modalità di aggiornamento per un abbonamento e passare all'altra modalità se l'applicazione lo richiede. Ad esempio, puoi specificare che un abbonamento utilizzi un aggiornamento immediato, ma passi all'aggiornamento in coda se un guasto di sistema comporta la perdita della connettività di rete.

Se passi dall'aggiornamento immediato all'aggiornamento in coda, non puoi tornare all'aggiornamento immediato finché l'Abbonato e il Publisher non sono connessi e l'Agente Lettore della Coda non applica tutti i messaggi in sospeso nella coda all'Publisher.

Per passare da una modalità di aggiornamento all'altra

Per passare tra le modalità di aggiornamento, abilita la pubblicazione e l'abbonamento per entrambe le modalità di aggiornamento, e poi passa tra di esse se necessario. Per ulteriori informazioni, vedere
Passare da una modalità di aggiornamento all'altra per una sottoscrizione transazionale aggiornabile

Considerazioni per l'uso degli abbonamenti aggiornabili

• Dopo aver attivato una pubblicazione per aggiornare abbonamenti o abbonamenti in coda, non puoi disabilitare l'opzione per la pubblicazione (anche se gli abbonamenti non devono necessariamente usarla). Per disabilitare l'opzione, elimina la pubblicazione e creane una nuova.

• La ripubblicazione dei dati non è supportata.

• La replica aggiunge la colonna msrepl_tran_version alle tabelle pubblicate per consentire il rilevamento. A causa di questa colonna aggiuntiva, includi un elenco di colonne in tutte le istruzioni INSERT.

• Per apportare modifiche allo schema su una tabella in una pubblicazione che supporta l'aggiornamento degli abbonamenti, fermare tutta l'attività sulla tabella presso Publisher e Subscribers, e propagare le modifiche di dati in sospeso a tutti i nodi prima di effettuare qualsiasi modifica allo schema. Questo processo garantisce che le transazioni in sospeso non entrino in conflitto con la modifica dello schema in sospeso. Dopo che i cambiamenti dello schema si propagano a tutti i nodi, l'attività può riprendere sulle tabelle pubblicate. Per altre informazioni, vedere Come mettere una topologia di replica in stato di inattività (programmazione Transact-SQL della replica).

• Per passare tra le modalità di aggiornamento, l'Agente Lettore della Coda deve eseguire almeno una volta dopo l'inizializzazione dell'abbonamento (di default, l'Agente Lettore della Coda funziona continuamente).

• Se il database degli abbonati è partizionato orizzontalmente e ci sono righe nella partizione che esistono presso l'abbonato ma non presso l'Publisher, l'abbonato non può aggiornare le righe preesistenti. I tentativi di aggiornamento di queste righe generano un errore. Elimina le righe dalla tabella e poi aggiungile nel Publisher.

• La replicazione transazionale con sottoscrittori aggiornabili in coda può presentare rallentamenti quando vengono utilizzati indici filtrati unici. Se si verifica un conflitto su un articolo che dispone di indici filtrati unici, la risoluzione dei conflitti comporta ulteriori eliminazioni e inserimenti nel sottoscrittore per le righe non coperte dagli indici filtrati unici.

Aggiornamenti presso il sottoscrittore

• Gli aggiornamenti sull'Abbonato si propagano all'Publisher anche se un abbonamento è scaduto o inattivo. Assicurati di interrompere o riavviare tali abbonamenti.

• Se si utilizzano le colonne TIMESTAMP o IDENTITY e le si replicano come tipi di dati sottostanti, non aggiornare i valori in queste colonne nel Sottoscrittore.

• Gli abbonati non possono aggiornare o inserire testi,ntext o valori di immagine perché i trigger di tracciamento dei cambiamenti di replicazione non possono leggere dalle tabelle inserite o cancellate. Allo stesso modo, gli Abbonati non possono aggiornare o inserire valori di testo o immagine usando WRITETEXT o UPDATETEXT perché l'Publisher sovrascrive i dati. Invece, potresti suddividere le colonne di testo e immagine in una tabella separata e modificare entrambe le tabelle all'interno di una transazione.

  Per aggiornare oggetti di grandi dimensioni in un Sottoscrittore, usare i tipi di dati varchar(max), nvarchar(max) e varbinary(max) invece dei tipi di dati text, ntext e image, rispettivamente.

• Gli aggiornamenti di chiavi uniche (incluse le chiavi primarie) che generano duplicati, come un aggiornamento del modulo UPDATE <column> SET <column> =<column>+1, non sono permessi e vengono rifiutati a causa di una violazione dell'unicità. Gli aggiornamenti eseguiti presso il Sottoscrittore vengono propagati tramite replica come singole istruzioni UPDATE per ogni riga interessata.

• Se il database dell'Abbonato è partizionato orizzontalmente e la partizione contiene righe che esistono presso l'Abbonato ma non presso il Publisher, l'Abbonato non può aggiornare le righe preesistenti. I tentativi di aggiornamento di queste righe generano un errore. Elimina e reinserisci queste righe.

Trigger definiti dall'utente

• Se l'applicazione richiede trigger nel Sottoscrittore, definire i trigger con l'opzione NOT FOR REPLICATION nell'Editore e nel Sottoscrittore. Questa opzione garantisce che i trigger si attivino solo per la modifica originale dei dati, ma non quando la replica propaga la modifica.

  Assicurati che il trigger definito dall'utente non si attivi quando il trigger di replicazione aggiorna la tabella. Chiama la procedura sp_check_for_sync_trigger nel corpo del trigger definito dall'utente. Per altre informazioni, vedi sp_check_for_sync_trigger (Transact-SQL).

Aggiornamento immediato

• Per gli abbonamenti ad aggiornamento immediato, le modifiche sull'Abbonato si propagano all'Publisher e si applicano utilizzando Microsoft Distributed Transaction Coordinator (MS DTC). Assicurarsi che MS DTC sia installato e configurato nel server di pubblicazione e nel server di sottoscrizione. Per ulteriori informazioni, vedere la documentazione di Windows.

• I trigger usati dalle sottoscrizioni con aggiornamento immediato richiedono una connessione al Publisher per replicare le modifiche.

• Se la pubblicazione consente l'aggiornamento immediato degli abbonamenti e un articolo nella pubblicazione ha un filtro per colonne, non puoi filtrare colonne non nullabili senza impostazioni predefinite.

Aggiornamento in coda

• Non puoi pubblicare tabelle incluse in una pubblicazione di fusione come parte di una pubblicazione transazionale che consente abbonamenti aggiornati in coda.

• Non aggiornare le colonne della chiave primaria quando si utilizza l'aggiornamento differito perché la chiave primaria funge da identificatore del record per tutte le query. Quando la politica di risoluzione dei conflitti è impostata su Vincite degli Abbonati, fai attenzione all'aggiornamento delle chiavi primarie. Se sia il Publisher che l'Abbonato aggiornano la chiave primaria, il risultato sono due righe con chiavi primarie diverse.

• Per le colonne di tipo di dati SQL_VARIANT: quando i dati vengono inseriti o aggiornati nel Sottoscrittore, l'Agente Lettore della Coda li converte nel modo seguente quando copia i dati dal Sottoscrittore alla coda:

  • BIGINT, DECIMAL, NUMERIC, MONEY e SMALLMONEY vengono mappati a NUMERIC.

  • BINARY e VARBINARY vengono mappati al tipo di dati VARBINARY.

Rilevamento e risoluzione dei conflitti

• Per la politica sui conflitti Subscriber Wins: la risoluzione dei conflitti non supporta aggiornamenti alle colonne chiave primarie.

• La replicazione non risolve i conflitti dovuti a violazioni dei vincoli di chiave esterna:

  • Se non ti aspetti conflitti e i dati sono ben partizionati (gli Abbonati non aggiornano le stesse righe), usa i vincoli di chiave esterna su Publisher e Abbonati.

  • Se prevedi conflitti: non usare vincoli di chiave esterna nel Publisher o nel Subscriber se usi la risoluzione dei conflitti "Subscriber wins". Non usare vincoli di chiave esterna al Sottoscrittore se si utilizza la risoluzione dei conflitti "Publisher wins".

Contenuto correlato

• Peer-to-Peer - Replica transazionale
• Replicazione transazionale
• Pubblicare dati e oggetti di database
• Sottoscrivere pubblicazioni