Share via

I dati del server di pubblicazione e quelli del Sottoscrittore non corrispondono

  • Articolo

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:

  1. 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 del conteggio delle righe, ma questa modalità non rivela le differenze di 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 How to: Compare Replicated Tables for Differences (Replication Programming).
  2. 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 AdventureWorks
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:
    • I trigger devono generare modifiche di dati del Sottoscrittore solo se si utilizza 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.
    • 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 How to: Execute Scripts During Synchronization (Replication Transact-SQL Programming).
    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 una stored procedure, la definizione della procedura viene replicata nel Sottoscrittore all'inizializzazione della sottoscrizione. Quando la procedura viene eseguita nel server di pubblicazione, la replica esegue la corrispondente procedura nel Sottoscrittore. Per ulteriori informazioni, vedere Pubblicazione dell'esecuzione delle stored procedure nella replica transazionale.
    Se la stored procedure esegue un'azione diversa nel Sottoscrittore o agisce su dati diversi da quelli del server di pubblicazione, può verificarsi una non convergenza. Si consideri una procedura che esegue un calcolo e successivamente inserisce i dati basati su questo 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'interruzione 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 di un vincolo sono considerate conflitti. Vengono registrate ma non provocano l'interruzione della sincronizzazione da parte dell'agente di merge. Per entrambi i tipi di replica, le violazioni di un vincolo possono portare a non convergenza se un inserimento, un aggiornamento o un'eliminazione che ha avuto esito positivo in un nodo non ha esito positivo nell'altro.
    Quando una tabella viene pubblicata, le opzioni predefinite per lo schema specificano che i vincoli FOREIGN KEY e i vincoli CHECK devono essere creati nel database di sottoscrizione con l'opzione NOT FOR REPLICATION. 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 How to: Specify Schema Options (Replication Transact-SQL Programming).

Vedere anche

Concetti

Risoluzione dei problemi relativi alla replica

Guida in linea e informazioni

Assistenza su SQL Server 2005