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. È possibile eseguire gli aggiornamenti mentre il Sottoscrittore o il server di pubblicazione è offline.

Quando si aggiornano i dati in un Sottoscrittore, questi vengono innanzitutto propagati al server di pubblicazione e quindi agli altri Sottoscrittori. Se si utilizza l'aggiornamento immediato, le modifiche vengono propagate immediatamente tramite il protocollo di commit in due fasi. Se si utilizza l'aggiornamento in coda, le modifiche vengono archiviate in una coda. Le transazioni in coda vengono quindi applicate in modo asincrono nel server di pubblicazione ogni volta che è disponibile la connettività di rete. Poiché gli aggiornamenti vengono propagati in modo asincrono al server di pubblicazione, gli stessi dati potrebbero essere stati aggiornati dal server di pubblicazione o da un altro Sottoscrittore e potrebbero verificarsi conflitti in fase di applicazione degli aggiornamenti. I conflitti vengono rilevati e risolti in base a criteri di risoluzione dei conflitti impostati durante la creazione della 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 le sottoscrizioni aggiornabili per le pubblicazioni transazionali, Enable Updating Subscriptions for Transactional Publications

Per creare sottoscrizioni aggiornabili per le pubblicazioni transazionali, vedere Creare una sottoscrizione aggiornabile di una pubblicazione transazionale (Management Studio)

Passaggio da una modalità di aggiornamento all'altra

Quando si utilizzano le sottoscrizioni aggiornabili, è possibile specificare che per una sottoscrizione venga utilizzata una modalità di aggiornamento e quindi si passi all'altra se l'applicazione lo richiede. È possibile, ad esempio, specificare che per una sottoscrizione venga utilizzato l'aggiornamento immediato, ma si passi all'aggiornamento in coda se un errore di sistema provoca la perdita della connettività di rete.

Se si passa dall'aggiornamento immediato all'aggiornamento in coda, non sarà possibile tornare all'aggiornamento immediato fino a quando il Sottoscrittore e il server di pubblicazione non sono connessi e tramite l'agente di lettura coda non sono stati applicati al server di pubblicazione tutti i messaggi in sospeso nella coda.

Per passare da una modalità di aggiornamento all'altra

Per passare da una modalità di aggiornamento all'altra, è necessario abilitare la pubblicazione e la sottoscrizione per entrambe le modalità e quindi passare da una all'altra, se necessario. Per ulteriori informazioni, vedere
Passare da una modalità di aggiornamento all'altra per una sottoscrizione transazionale aggiornabile

Considerazioni per l'utilizzo di sottoscrizioni aggiornabili

• Dopo che una pubblicazione è stata abilitata per le sottoscrizioni aggiornabili o per le sottoscrizioni con aggiornamento in coda, non è più possibile disabilitare l'opzione per la pubblicazione, anche se le sottoscrizioni non devono necessariamente utilizzarla. Per disabilitare l'opzione, è necessario eliminare la pubblicazione e crearne 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, tutte le INSERT istruzioni devono includere un elenco di colonne.

• Per apportare modifiche dello schema a una tabella in una pubblicazione che supporta sottoscrizioni aggiornabili, è necessario interrompere qualsiasi attività sulla tabella nel server di pubblicazione e nei sottoscrittori e propagare a tutti i nodi le modifiche ai dati in sospeso prima di apportare qualsiasi modifica dello schema. In questo modo le transazioni in sospeso non entrano in conflitto con le modifiche allo schema in sospeso. Dopo avere propagato a tutti i nodi le modifiche dello schema, è possibile riprendere le attività nelle tabelle pubblicate. Per altre informazioni, vedere Come mettere una topologia di replica in stato di inattività (programmazione Transact-SQL della replica).

• Se si prevede di passare da una modalità di aggiornamento all'altra, è necessario eseguire l'agente di lettura coda almeno una volta dopo l'inizializzazione della sottoscrizione. Per impostazione predefinita, l'agente di lettura coda viene eseguito continuamente.

• Se il database del Sottoscrittore è partizionato orizzontalmente e nella partizione vi sono righe presenti nel Sottoscrittore ma non nel server di pubblicazione, il Sottoscrittore non potrà aggiornare tali righe. I tentativi di aggiornamento di queste righe generano un errore. Le righe devono essere eliminate dalla tabella e quindi aggiunte al Publisher.

• La replica transazionale con sottoscrittori aggiornabili in coda potrebbe presentare prestazioni ridotte quando vengono utilizzati indici filtrati univoci. Se si verifica un conflitto in un articolo con indici filtrati univoci, la risoluzione dei conflitti comporterebbe ulteriori eliminazioni e inserimenti nel Sottoscrittore per le righe non incluse dall'indice filtrato univoco.

Aggiornamenti presso il sottoscrittore

• Gli aggiornamenti nel Sottoscrittore vengono propagati al server di pubblicazione, anche se una sottoscrizione è scaduta o inattiva. Verificare che tali sottoscrizioni vengano eliminate o reinizializzate.

• Se vengono utilizzati TIMESTAMP o colonne IDENTITY, e vengono replicati come i rispettivi tipi di dati sottostanti, i valori in queste colonne non devono essere aggiornati nel Subscriber.

• I sottoscrittori non possono aggiornare o inserire valori text, ntext o image perché non è possibile leggere dalle tabelle inserite o eliminate all'interno dei trigger di rilevamento modifiche della replica. In modo analogo, i sottoscrittori non possono aggiornare o inserire valori text o image tramite WRITETEXT o UPDATETEXT perché i dati vengono sovrascritti dal server di pubblicazione. È invece possibile partizionare le colonne text e image in una tabella distinta e modificare le due tabelle all'interno di una transazione.

  Per aggiornare gli oggetti di grandi dimensioni in un sottoscrittore, usare i tipi di dati varchar(max), nvarchar(max), varbinary(max) anziché, rispettivamente, text, ntext, e image .

• Gli aggiornamenti delle chiavi univoche, incluse le chiavi primarie, che generano duplicati, ad esempio, un aggiornamento del form UPDATE <column> SET <column> =<column>+1 , non sono consentiti e vengono rifiutati in quanto violazioni dell'univocità. Ciò è dovuto al fatto che gli aggiornamenti impostati nel Sottoscrittore vengono propagati dalla replica come singole UPDATE istruzioni per ogni riga interessata.

• Se il database del Sottoscrittore è partizionato orizzontalmente e nella partizione vi sono righe presenti nel Sottoscrittore ma non nel server di pubblicazione, il Sottoscrittore non potrà aggiornare tali righe. I tentativi di aggiornamento di queste righe generano un errore. In questi casi è necessario eliminare le righe dalla tabella e inserirle di nuovo.

Trigger definiti dall'utente

• Se l'applicazione richiede trigger nel Sottoscrittore, i trigger devono essere definiti con l'opzione NOT FOR REPLICATION nell'Autore e nel Sottoscrittore. In questo modo, i trigger vengono attivati solo per modifiche ai dati originali, ma non quando le modifiche vengono replicate.

  Verificare che il trigger definito dall'utente non venga attivato quando il trigger di replica aggiorna la tabella. A tale scopo, chiamare 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 le sottoscrizioni ad aggiornamento immediato, le modifiche nel Sottoscrittore vengono propagate al server di pubblicazione e applicate tramite 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.

• Per i trigger utilizzati dalle sottoscrizioni ad aggiornamento immediato, per replicare le modifiche è necessaria una connessione al server di pubblicazione.

• Se la pubblicazione consente sottoscrizioni con aggiornamento immediato e un articolo nella pubblicazione contiene un filtro sulle colonne, non è possibile escludere dal filtro le colonne che non ammettono valori null e non hanno valori predefiniti.

Aggiornamento in attesa

• Le tabelle incluse in una pubblicazione di tipo merge non possono essere pubblicate anche come parte di una pubblicazione transazionale che consente le sottoscrizioni ad aggiornamento in coda.

• La chiave primaria viene utilizzata come indicatore di posizione dei record per tutte le query, pertanto non è consigliabile apportare aggiornamenti a colonne chiave primaria quando si utilizza l'aggiornamento in coda. Quando i criteri di risoluzione dei conflitti sono impostati su Prevale il Sottoscrittore, è necessario prestare attenzione durante l'aggiornamento delle chiavi primarie. Se gli aggiornamenti alla chiave primaria vengono eseguiti sia nel Sottoscrittore che nel server di pubblicazione, si ottengono due righe con chiavi primarie diverse.

• Per le colonne del tipo di dati SQL_VARIANT:, quando i dati vengono inseriti o aggiornati nel sottoscrittore, ne viene eseguito il mapping dall'agente di lettura coda quando vengono copiati dal sottoscrittore alla coda nel modo illustrato di seguito:

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

  • Viene eseguito il mapping diBINARY e VARBINARY ai dati VARBINARY .

Rilevamento e risoluzione di conflitti

• Per il criterio di risoluzione dei conflitti "Prevale il Sottoscrittore": la risoluzione dei conflitti non è supportata per gli aggiornamenti alle colonne della chiave primaria.

• I conflitti provocati dagli errori relativi ai vincoli di chiave esterna non vengono risolti dalla replica:

  • Se non si prevedono conflitti e i dati sono ben partizionati (i Sottoscrittori non aggiornano le stesse righe), è possibile utilizzare vincoli di chiave esterna nell'Editore e nei Sottoscrittori.

  • Se sono previsti conflitti: non usare vincoli di chiave esterna nel Publisher o nel Subscriber se si utilizza la risoluzione dei conflitti "Prevale il Subscriber"; non usare vincoli di chiave esterna nel Subscriber se si utilizza la risoluzione dei conflitti "Prevale il Publisher".

Contenuto correlato

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