I dati del server di pubblicazione e quelli del Sottoscrittore non corrispondono
I dati del server di pubblicazione e quelli del Sottoscrittore sono considerati non convergenti (in altre parole non corrispondono) se:
Il numero di righe nel Sottoscrittore è diverso dal numero di righe nel server di pubblicazione e la pubblicazione non è filtrata. Se la pubblicazione è filtrata, è possibile prevedere che il numero di righe sia diverso.
I dati di una o più righe hanno contenuti diversi nel server di pubblicazione e nel Sottoscrittore.
Spiegazione
I dati del server di pubblicazione e quelli del Sottoscrittore potrebbero non essere convergenti per diverse ragioni:
Sono stati aggiornati dei dati in un Sottoscrittore che dovrebbe essere considerato di sola lettura. Il database di sottoscrizione dovrebbe essere considerato di sola lettura a meno che non si utilizzi la replica di tipo merge, la replica transazionale con sottoscrizioni aggiornabili o la replica transazionale peer-to-peer.
Nel Sottoscrittore vengono utilizzati i trigger. I trigger possono modificare i dati del Sottoscrittore e impedire l'aggiornamento dei dati se il trigger esegue un'istruzione ROLLBACK.
Gli script vengono eseguiti nella replica nel Sottoscrittore ma non nel server di pubblicazione.
La replica dell'esecuzione di una stored procedure per una pubblicazione transazionale produce risultati diversi nel Sottoscrittore.
Le violazioni di vincoli o altri problemi impediscono l'inserimento, l'aggiornamento o l'eliminazione di righe nel Sottoscrittore.
Azione utente
Nelle azioni seguenti viene descritto come stabilire se i dati non sono convergenti e come portarli alla convergenza:
Stabilire se i dati non sono convergenti utilizzando la convalida o l'utilità tablediff:
Se è possibile eseguire l'agente di distribuzione o l'agente di merge, stabilire se vi sono dati mancanti eseguendo la convalida del checksum binario. È inoltre possibile utilizzare la convalida tramite conteggio delle righe, ma questo metodo non rileva le differenze nel contenuto dei dati. Per ulteriori informazioni, vedere Convalida dei dati replicati.
Se non è possibile eseguire l'agente di distribuzione o l'agente di merge, stabilire se i dati non sono convergenti eseguendo l'utilità tablediff. Per informazioni sull'utilizzo di questa utilità sulle tabelle replicate, vedere Procedura: Confronto di tabelle replicate al fine di individuare le differenze (programmazione della replica).
Se i dati non sono convergenti, è possibile utilizzare l'utilità tablediff per generare uno script Transact-SQL in modo da rendere i dati convergenti. Per ulteriori informazioni, vedere Utilità tablediff.
Identificazione della causa della non convergenza dei dati
Le azioni seguenti consentono di identificare le cause elencate nella sezione "Spiegazione":
I dati vengono aggiornati nel Sottoscrittore al di fuori della replica:
Se si desidera consentire agli utenti di inserire, aggiornare ed eliminare dati nel Sottoscrittore, utilizzare la replica di tipo merge, la replica transazionale con sottoscrizioni aggiornabili o la replica transazionale peer-to-peer. Per ulteriori informazioni, vedere Panoramica della replica di tipo merge e Tipi di pubblicazioni per la replica transazionale.
Se si desidera impedire agli utenti di inserire, aggiornare ed eliminare dati nel Sottoscrittore, creare un trigger per ogni tabella che contiene la parola ROLLBACK e utilizza l'opzione NOT FOR REPLICATION, che impedisce l'attivazione del trigger all'esecuzione di un'operazione da parte di un agente di replica). Ad esempio:
USE AdventureWorks2008R2; GO CREATE TRIGGER prevent_user_dml ON Person.Address FOR INSERT, UPDATE, DELETE NOT FOR REPLICATION AS ROLLBACK;Per ulteriori informazioni, vedere CREATE TRIGGER (Transact-SQL) e Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION.
Nel Sottoscrittore vengono utilizzati i trigger. I trigger nel Sottoscrittore devono essere gestiti correttamente, per evitare la non convergenza o altri problemi:
È opportuno che i trigger causino modifiche di dati in un Sottoscrittore soltanto se si utilizza la replica di tipo merge, la replica transazionale con sottoscrizioni aggiornabili oppure la replica transazionale peer-to-peer. Per ulteriori informazioni, vedere Panoramica della replica di tipo merge e Tipi di pubblicazioni per la replica transazionale.
In molti casi, i trigger devono utilizzare l'opzione NOT FOR REPLICATION. Si consideri un trigger che inserisce i dati in una tabella di rilevamento: quando l'utente inserisce la riga inizialmente, è giusto che il trigger si attivi e inserisca una riga nella tabella di rilevamento, ma non deve attivarsi quando i dati vengono replicati nel Sottoscrittore, perché questo provocherebbe l'inserimento di una riga superflua nella tabella di rilevamento.
Se un trigger include un'istruzione ROLLBACK e non utilizza l'opzione NOT FOR REPLICATION, è possibile che le righe che replicate in un Sottoscrittore non vengano applicate.
Per la replica transazionale, vi sono altre considerazioni relative all'impostazione XACT_ABORT e all'uso delle istruzioni COMMIT e ROLLBACK in un trigger. Per ulteriori informazioni, vedere la sezione relativa ai trigger in Considerazioni sulla replica transazionale.
Gli script vengono eseguiti nella replica nel Sottoscrittore ma non nel server di pubblicazione.
I parametri @pre_snapshot_script e @post_snapshot_script di sp_addpublication e sp_addmergepublication consentono di specificare gli script da eseguire prima e dopo l'applicazione dello snapshot. Per ulteriori informazioni, vedere Esecuzione di script prima e dopo l'applicazione dello snapshot. La stored procedure sp_addscriptexec consente di eseguire uno script durante il processo di sincronizzazione. Per ulteriori informazioni, vedere Procedura: Esecuzione di script durante la sincronizzazione (programmazione Transact-SQL della replica).
Questi script vengono in genere utilizzati per le attività di amministrazione, come l'aggiunta degli account di accesso nel Sottoscrittore. Se gli script vengono utilizzati per aggiornare dati in un Sottoscrittore che andrebbe considerato di sola lettura, l'amministratore deve accertarsi che non si generi una non convergenza.
La replica dell'esecuzione di una stored procedure per la pubblicazione transazionale produce risultati diversi nel Sottoscrittore.
Se si replica l'esecuzione di un stored procedure, la definizione della procedura viene replicata nel Sottoscrittore quando viene inizializzata la sottoscrizione. Quando la procedura viene eseguita nel server di pubblicazione, la replica esegue la procedura corrispondente nel Sottoscrittore. Per ulteriori informazioni, vedere Pubblicazione dell'esecuzione delle stored procedure nella replica transazionale.
Se la stored procedure completa un'azione diversa nel Sottoscrittore oppure viene eseguita su dati diversi rispetto al server di pubblicazione, si può riscontrare la non convergenza. Si consideri una procedura che esegue un calcolo e quindi inserisce dati basati su tale calcolo. Se il Sottoscrittore viene filtrato in modo che i dati nello stesso si basino su altri dati, il risultato inserito nel Sottoscrittore può essere diverso o l'inserimento può non avere affatto luogo.
Le violazioni di vincoli o altri problemi impediscono l'inserimento, l'aggiornamento o l'eliminazione di righe nel Sottoscrittore.
Per la replica transazionale, le violazioni di un vincolo sono considerate errori. Per impostazione predefinita provocano l'arresto della sincronizzazione da parte dell'agente di distribuzione (per informazioni su come ignorare questi errori, vedere Errori da ignorare nella replica transazionale). Per la replica di tipo merge, le violazioni dei vincoli vengono considerate come conflitti. Vengono registrate, ma non determinano l'arresto della sincronizzazione da parte dell'agente di merge. Per entrambi i tipi di replica, le violazioni dei vincoli possono causare la non convergenza se un'operazione di inserimento, aggiornamento o eliminazione viene completata in un nodo ma non in un altro.
Quando una tabella viene pubblicata, le opzioni predefinite dello schema specificano che nel database di sottoscrizione devono essere creati vincoli FOREIGN KEY e vincoli CHECK con l'opzione NOT FOR REPLICATION impostata. Se l'applicazione richiede impostazioni diverse per i vincoli, modificare le opzioni dello schema. Per ulteriori informazioni, vedere Procedura: Impostazione delle opzioni dello schema (SQL Server Management Studio) e Procedura: Impostazione delle opzioni dello schema (programmazione Transact-SQL della replica).