Mancato recapito dei dati ai Sottoscrittori

Se risulta che i dati non vengono recapitati ai Sottoscrittori, esistono due motivi generali:

• I dati non vengono applicati a causa di filtri, di un problema dell'agente o di un altro errore di replica.

• I dati vengono eliminati nel Sottoscrittore dopo l'applicazione.

Spiegazione

Il mancato recapito dei dati ai Sottoscrittori può essere determinato da diverse cause:

• La tabella viene filtrata e non sono presenti modifiche da recapitare a un determinato Sottoscrittore.

• Uno o più agenti non sono in esecuzione oppure si è verificato un errore in essi.

• Una sottoscrizione transazionale è stata inizializzata senza uno snapshot e sono state apportate modifiche nel server di pubblicazione dopo la creazione della pubblicazione.

• La replica dell'esecuzione di stored procedure per una pubblicazione transazionale produce risultati diversi nel Sottoscrittore.

• La stored procedure INSERT utilizzata in un articolo transazionale include una condizione non soddisfatta.

• I dati vengono eliminati da un utente, uno script di replica o un'altra applicazione.

• I dati vengono eliminati da un trigger oppure un trigger include un'istruzione ROLLBACK.

Azione utente

Prima di tentare una diagnosi del motivo per cui i dati non vengono recapitati ai Sottoscrittori, è consigliabile utilizzare la convalida o l'utilità tablediff per verificare la mancanza di righe:

• Se è possibile eseguire l'agente di distribuzione o di merge, determinare l'eventuale mancanza di dati eseguendo la convalida tramite 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 di merge, determinare l'eventuale mancanza di dati 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).

Risoluzione della causa dei dati mancanti

Le azioni seguenti consentono di risolvere le cause elencate nella sezione "Spiegazione".

• La tabella viene filtrata e non sono presenti modifiche da recapitare a un determinato Sottoscrittore.

  È possibile che le righe mancanti nel Sottoscrittore non siano state replicate poiché non soddisfano i criteri di filtro per la pubblicazione. Tutti i tipi di replica supportano filtri statici e la replica di tipo merge supporta inoltre filtri join e con parametri. Per ulteriori informazioni, vedere Applicazione di filtri ai dati pubblicati. Se uno o più articoli della pubblicazione vengono filtrati, eseguire le procedure seguenti e verificare il valore della clausola di filtro.

  • Filtro statico per pubblicazioni snapshot e transazionali: colonna filter_clause restituita da sp_helparticle (Transact-SQL).

  • Filtro statico o con parametri per pubblicazioni di tipo merge: colonna subset_filterclause restituita da sp_helpmergearticle (Transact-SQL).

  • Filtro join per pubblicazioni di tipo merge: colonna join_filterclause restituita da sp_helpmergefilter (Transact-SQL).

  Utilizzare la clausola di filtro per determinare se le righe mancanti soddisfano i criteri di filtro. È ad esempio possibile eseguire la clausola di filtro sulla tabella nel server di pubblicazione e determinare se i dati restituiti corrispondono ai dati nel Sottoscrittore.

• Uno o più agenti non sono in esecuzione oppure si è verificato un errore in essi.

  • In caso di inizializzazione di una sottoscrizione, verificare il completamento dell'agente snapshot per la pubblicazione prima di tentare l'applicazione dello snapshot con l'agente di distribuzione o di merge. Se si tenta di applicare lo snapshot prima del completamento, si verifica l'errore "Lo snapshot iniziale per la pubblicazione '%s' non è ancora disponibile".

  • Per la replica transazionale, verificare che l'agente di distribuzione e l'agente di lettura log siano in esecuzione. Per la replica di tipo merge, verificare che l'agente di merge sia in esecuzione. Per informazioni sull'avvio di questi agenti, vedere Procedura: Avvio e interruzione di un agente di replica (SQL Server Management Studio) e Concetti di base relativi ai file eseguibili dell'agente di replica.

  • In caso di interruzione di un agente in seguito a errore, visualizzare i dettagli dell'errore per l'agente per determinare la causa sottostante. Per informazioni su come visualizzare i dettagli degli errori per l'agente snapshot e l'agente di lettura log, vedere Procedura: Visualizzazione delle informazioni ed esecuzione di attività relative agli agenti associati a una pubblicazione (Monitoraggio replica). Per informazioni sull'agente di distribuzione e sull'agente di merge, vedere Procedura: Visualizzazione delle informazioni ed esecuzione delle attività degli agenti associati a una sottoscrizione (Monitoraggio replica). Se l'errore continua a verificarsi, aumentare il livello di dettaglio per la registrazione delle operazioni dell'agente e specificare un file di output per il log. A seconda del contesto dell'errore, in questo modo si potrebbero ottenere ulteriori informazioni sui passaggi che conducono all'errore e/o messaggi di errore aggiuntivi. Per ulteriori informazioni, vedere Agenti di replica (Risoluzione dei problemi).

    Tra gli errori comuni che causano il mancato recapito dei dati sono inclusi i problemi relativi alle autorizzazioni e le violazioni dei vincoli. Per ulteriori informazioni sui problemi relativi alle autorizzazioni, vedere Problemi di protezione che impediscono la replica dei dati. Le violazioni dei vincoli impediscono l'inserimento delle righe nel Sottoscrittore.

    Per la replica transazionale, le violazioni dei vincoli vengono considerate come errori. Per impostazione predefinita, il relativo rilevamento determina 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 dei vincoli vengono considerate come conflitti. Vengono registrate, ma non determinano l'interruzione 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 diverse impostazioni 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).

• Un sottoscrizione transazionale è stata inizializzata senza uno snapshot e sono state apportate modifiche nel server di pubblicazione dopo la creazione della pubblicazione.

  • Se si abilita l'inizializzazione di una pubblicazione da un backup, le modifiche apportate alle tabelle pubblicate vengono rilevate nel log del database di pubblicazione appena viene creata la pubblicazione. Quando una sottoscrizione viene inizializzata, le modifiche in sospeso vengono recapitate al Sottoscrittore finché risultano disponibili nel database di distribuzione.

  • A differenza dell'inizializzazione da un backup, in caso di inizializzazione di una sottoscrizione con l'opzione Solo supporto replica l'utente o l'applicazione deve verificare che i dati e lo schema siano sincronizzati correttamente nel momento in cui si aggiunge la sottoscrizione. In presenza di attività nel server di pubblicazione tra il momento in cui i dati e lo schema vengono copiati nel Sottoscrittore e il momento in cui viene aggiunta la sottoscrizione, le modifiche risultanti da tale attività potrebbero non essere replicate nel Sottoscrittore.

  Per ulteriori informazioni, vedere Inizializzazione di una sottoscrizione transazionale senza uno snapshot.

• La replica dell'esecuzione di stored procedure per una 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 al Sottoscrittore viene applicato un filtro in base al quale il calcolo nel Sottoscrittore è basato su dati diversi, il risultato inserito nel Sottoscrittore potrebbe essere diverso oppure l'inserimento potrebbe non verificarsi.

• La stored procedure INSERT utilizzata in un articolo transazionale include una condizione non soddisfatta.

  Per impostazione predefinita, nella replica transazionale viene utilizzato un set di stored procedure per la propagazione delle modifiche al Sottoscrittore. È inoltre possibile utilizzare tali procedure per includere la logica di business richiesta dall'applicazione. Per ulteriori informazioni, vedere Impostazione della modalità di propagazione delle modifiche per gli articoli transazionali. Se la logica della stored procedure INSERT include una condizione che non viene soddisfatta, l'inserimento non viene eseguito. Si consideri una procedura personalizzata in modo da controllare un determinato valore in una tabella (tabella A) nel Sottoscrittore prima di consentire un inserimento in un'altra tabella (tabella B). Se il valore non è disponibile nella tabella A a causa di un errore oppure perché non è ancora stato replicato in questa tabella, la riga prevista risulta assente nella tabella B.

• I dati vengono eliminati da un utente, uno script di replica o un'altra applicazione.

  • Se si desidera consentire agli utenti di eliminare dati nel Sottoscrittore, utilizzare la replica di tipo merge, la replica transazionale con sottoscrizioni aggiornabili oppure la replica transazionale peer-to-peer. Le eliminazioni vengono propagate al server di pubblicazione, garantendo così la convergenza dei dati nel server di pubblicazione e nel Sottoscrittore. 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 eliminare dati nel Sottoscrittore, creare un trigger per ogni tabella in cui è contenuta la parola ROLLBACK e viene utilizzata l'opzione NOT FOR REPLICATION, che impedisce l'attivazione del trigger quando un agente di replica esegue un'operazione. 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.

  • La replica consente l'esecuzione di script prima e dopo l'applicazione dello snapshot e durante la sincronizzazione. 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 attività amministrative, ad esempio per l'aggiunta di account di accesso nel Sottoscrittore. Se gli script vengono utilizzati per eliminare dati di un Sottoscrittore che dovrebbero essere considerati come di sola lettura, l'amministratore deve impedire che ne risulti la non convergenza.

• I dati vengono eliminati da un trigger oppure un trigger include un'istruzione ROLLBACK.

  I trigger nel Sottoscrittore devono essere gestiti correttamente affinché non causino 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 numerosi casi, è opportuno che i trigger utilizzino l'opzione NOT FOR REPLICATION. Se un trigger include un'istruzione ROLLBACK e non utilizza l'opzione NOT FOR REPLICATION, è possibile che le righe replicate in un Sottoscrittore non vengano applicate.

  • Per la replica transazionale, esistono considerazioni aggiuntive relative all'impostazione XACT_ABORT e all'utilizzo di istruzioni COMMIT e ROLLBACK in un trigger. Per ulteriori informazioni, vedere la sezione relativa ai trigger in Considerazioni sulla replica transazionale.

Vedere anche

Concetti

Risoluzione dei problemi (replica)