Le istruzioni UPDATE possono essere replicate come coppie DELETE/INSERT

Questo articolo descrive che le istruzioni Update possono essere replicate come coppie DELETE/INSERT.

Versione originale del prodotto: SQL Server
Numero KB originale: 238254

Riepilogo

Se una colonna che fa parte di un vincolo univoco viene aggiornata, SQL Server implementa l'aggiornamento come "aggiornamento posticipato", ovvero come coppia di DELETE/INSERT operazioni. Questo "aggiornamento posticipato" fa sì che la replica invii una coppia di DELETE/INSERT istruzioni ai sottoscrittori. Esistono anche altre situazioni che potrebbero causare un aggiornamento posticipato. Pertanto, qualsiasi logica di business implementata nei trigger o nelle UPDATE stored procedure personalizzate nel Sottoscrittore deve essere inclusa anche nei trigger o nelle DELETE/INSERT stored procedure personalizzate.

Ulteriori informazioni

Il comportamento predefinito nella replica transazionale consiste nell'usare INSERTUPDATE e DELETE stored procedure personalizzate per applicare le modifiche ai sottoscrittori.

INSERT Le istruzioni eseguite nel server di pubblicazione vengono applicate ai sottoscrittori tramite una INSERT chiamata di stored procedure. Analogamente, un'istruzione DELETE viene applicata tramite una DELETE chiamata di stored procedure.

Tuttavia, quando un'istruzione UPDATE viene eseguita come "aggiornamento posticipato", l'agente di lettura log inserisce una coppia di chiamate di stored procedure nel database di DELETE/INSERT distribuzione da applicare ai Sottoscrittori anziché una chiamata alla stored procedure di aggiornamento. Si supponga, ad esempio, di avere una tabella di pubblicazione denominata TABLE1, con queste tre colonne:

• col1 int
• col2 int
• col3 varchar(30)

L'unico vincolo univoco in TABLE1 viene definito in col1 tramite un vincolo di chiave primaria. Si supponga di avere un record (1,1,'Dallas').

Quando si esegue questo codice:

UPDATE TABLE1 set col1 = 3 where col3 = 'Dallas'

L'istruzione UPDATE viene implementata da SQL Server come coppia diINSERTDELETE/istruzioni poiché si aggiorna col1, che ha un indice univoco definito. Pertanto, il lettore di log inserisce una coppia di chiamate nel database di DELETE/INSERT distribuzione. Ciò può influire su qualsiasi logica di business presente nei trigger o nelle stored procedure personalizzate nel Sottoscrittore. È consigliabile incorporare la logica di business aggiuntiva nei DELETE trigger e INSERT nelle stored procedure per gestire questa situazione.

Se si preferisce usare una sola logica e si vuole che tutti i UPDATE comandi vengano replicati come DELETE/INSERT coppie, è possibile abilitare un flag di traccia.

Inoltre, se si usa un filtro orizzontale nella pubblicazione e se la riga aggiornata non soddisfa una condizione di filtro, ai sottoscrittori viene inviata solo una DELETE chiamata di routine. Se la riga aggiornata in precedenza non soddisfa la condizione di filtro, ma soddisfa la condizione dopo l'aggiornamento, viene inviata solo la chiamata di INSERT routine tramite il processo di replica.

Nell'esempio precedente si supponga di avere anche un filtro orizzontale definito in TABLE1: where col3 = 'Dallas'. Se si esegue questo codice:

UPDATE table1 set col3 = 'New York' where col1 = 3

L'agente di lettura log inserisce solo una DELETE chiamata di stored procedure da applicare ai sottoscrittori poiché la riga aggiornata non soddisfa i criteri di filtro orizzontale.

Ora, se si esegue questo codice:

UPDATE table1 set col3 = 'Dallas' where col1 = 3

Il logreader genera solo la chiamata alla INSERT stored procedure, poiché la riga non soddisfaceva in precedenza la condizione di filtro.

Sebbene sia stata eseguita un'operazione UPDATE nel server di pubblicazione, nel Sottoscrittore vengono applicati solo i comandi appropriati.