La replica transazionale di SQL Server è una delle tecniche di replica più comuni utilizzate per condividere, copiare o distribuire dati a più destinazioni. In questo articolo parleremo della replica, di vari tipi di replica e presteremo particolare attenzione al lavoro di replica transazionale.
Che cos'è la replica transazionale SQL?
La replica è la tecnologia di SQL Server per copiare o distribuire dati da un database all'altro mantenendo la coerenza dei dati.
La replica può essere utilizzata per trasferire dati da un database all'altro
- nella stessa istanza o in un'altra istanza nello stesso server;
- o tra server in un'unica posizione o in più posizioni.
Innanzitutto, dovremmo esaminare l'architettura di replica e comprendere le terminologie di replica.
Architettura e terminologie di replica di SQL Server
- L'editore è l'istanza del database di origine che pubblica le modifiche ai dati che possono essere distribuite a un altro database. Dati da un unico editore può essere inviato a un Abbonato singolo o più Abbonati .
- Abbonato è l'istanza del database di destinazione in cui distribuiamo le modifiche ai dati acquisite dal database dell'editore. L'abbonato può essere un'istanza dell'editore o un'altra istanza nel server dell'editore/un altro server nella stessa posizione/posizione distante. Prima che le modifiche ai dati vengano distribuite all'istanza del database dell'abbonato, questi dati vengono archiviati nel Distributore .
- Il Distributore è un database che archivia i registri delle modifiche acquisiti dai database di Publisher. Quando un Server è abilitato come Distributore, creerà un Database di sistema denominato database di distribuzione .
In base alla posizione dei database di distribuzione, possono essere classificati come distributori locali o remoti.
– Distributore locale è un database di distribuzione che risiede nell'istanza del database di Publisher.
– Distributore remoto è un database di distribuzione che risiede nell'istanza del database del Sottoscrittore o in qualsiasi altra istanza di SQL Server diversa dall'istanza del database del Publisher.
Il fattore decisivo è dove posizionare il database di distribuzione nell'istanza di Publisher (un'altra istanza). dipende dalle risorse del server disponibili per gestire il carico di distribuzione dei dati.
A seconda del modo in cui i dati verranno inviati dal database di distribuzione all'istanza dell'abbonato, possono essere classificati in Push o Ritira abbonamenti .
– Abbonamento push significa che il database di distribuzione si assume la responsabilità di inviare i dati all'istanza del database dell'abbonato.
– Ritira abbonamento significa che l'istanza del database dell'abbonato si assume la responsabilità di estrarre i dati disponibili dal database di distribuzione e applicarli al database dell'abbonato.
- Articoli sono l'unità fondamentale della Replica. Indica eventuali modifiche ai dati su questo oggetto o articolo di database che verranno replicati dall'editore all'abbonato. L'articolo può essere una tabella, una vista, una vista indicizzata, una procedura memorizzata o una funzione definita dall'utente.
- Pubblicazioni sono una raccolta di uno o più Articoli dal database in Publisher.
- Abbonamento definisce quale pubblicazione verrà ricevuta. Inoltre, determina da quale pubblicazione e in quale pianificazione vengono replicati i dati. L'abbonamento può essere Push o Pull (dalla pubblicazione all'abbonamento).
- Agenti di replica sono programmi autonomi responsabili del monitoraggio delle modifiche e della distribuzione dei dati attraverso l'editore al distributore e all'abbonato. Tutti gli agenti di replica vengono eseguiti come processi in SQL Server Agent. Pertanto, può essere amministrato tramite SSMS in Processi di SQL Server Agent o Replication Monitor. Sono disponibili i seguenti tipi di agenti di replica:
- Agente per istantanee – Utilizzato da quasi tutti i tipi di replica. L'agente snapshot viene eseguito dal server che contiene il database di distribuzione. Prepara lo Schema e i dati iniziali di tutti gli Articoli inclusi in una Pubblicazione su un Editore. Inoltre, crea i file di snapshot in una cartella di snapshot e registra i dettagli di sincronizzazione nel database di distribuzione.
- Agente per la lettura dei log – Utilizzato dalla replica transazionale. L'obiettivo è leggere le modifiche ai dati degli articoli abilitati per la replica dai registri delle transazioni del database dell'editore e archiviati nel database di distribuzione. l'agente di lettura log viene eseguito dal server di distribuzione.
- Agente di distribuzione – Utilizzato dalla replica transazionale e snapshot. Applica i file snapshot iniziali e le transazioni in sospeso incrementali o disponibili dal database di distribuzione al database dell'abbonato. L'agente di distribuzione viene eseguito dal server del distributore per gli abbonamenti push e dal server dell'abbonato per gli abbonamenti pull.
- Agente di fusione – Utilizzato solo da Merge Replication. Applica i file di snapshot iniziali e la riconciliazione delle modifiche differenziali o incrementali nell'editore o nell'abbonato. L'agente di fusione viene eseguito sul server di distribuzione per la replica push e dal server di abbonato per le sottoscrizioni pull.
- Agente per la lettura delle code – L'agente di lettura della coda viene utilizzato dalla replica transazionale con l'opzione di aggiornamento in coda. Sposta le modifiche dall'abbonato all'editore. L'agente di lettura code viene eseguito dal server di distribuzione.
- Lavori di manutenzione della replica – Come spiegato in precedenza, tutti gli agenti di replica sono programmi autonomi impostati durante la configurazione della replica. Vengono eseguiti come processi in Processi di SQL Server Agent. Pochi lavori significativi da notare sono Pulizia distribuzione:distribuzione, Pulizia cronologia agenti:distribuzione e Pulizia abbonamenti scaduti.
Tipi di replica in SQL Server
Ora, quando conosciamo la terminologia, immergiamoci nei tipi di replica.
- Replica transazionale . Come suggerisce il nome, ogni transazione o modifica dei dati all'interno dell'ambito transazionale sull'editore verrà inviata all'abbonato quasi in tempo reale con ritardi minori a seconda della larghezza di banda della rete e delle risorse del server. La replica transazionale utilizza l'agente di lettura log per leggere le modifiche ai dati dai registri transazionali del database di Publisher. Utilizza anche l'agente di distribuzione per applicare le modifiche all'abbonato. Occasionalmente può utilizzare Snapshot Agent per acquisire i dati snapshot iniziali di tutti gli articoli replicati. La pubblicazione della replica transazionale può rientrare nelle seguenti categorie:
- Replica transazionale standard – Sottoscrittore è un database di sola lettura dal punto di vista della replica transazionale. Eventuali modifiche apportate da chiunque nel database dell'Abbonato non verranno tracciate e aggiornate nel Database dell'editore. La Replica transazionale standard viene spesso definita Replica transazionale.
- Replica transazionale con abbonamenti aggiornabili è un miglioramento della replica transazionale standard che tiene traccia delle modifiche ai dati in corso sugli abbonamenti. Ogni volta che vengono avviate modifiche ai dati su un abbonamento aggiornabile, verranno prima propagate all'editore e quindi agli altri abbonati.
- Replica peer-to-peer è un miglioramento della replica transazionale standard. Propaga modifiche coerenti a livello transazionale quasi in tempo reale su più istanze del server.
- Replica bidirezionale è un miglioramento della replica transazionale standard che consente a due server (limitati a soli 2 server e quindi denominati bidirezionali) di scambiare le modifiche dei dati tra loro con qualsiasi server che agisce come editore (per inviare modifiche a un altro server) o come abbonato (per ricevere le modifiche da un altro server).
- Unisci replica – Supporta l'acquisizione delle modifiche ai dati che avvengono sia nell'editore che nell'abbonato e le distribuisce all'altro server. La replica di unione richiede il ROWGUID colonna nella tabella Articoli coinvolti nella replica di fusione. Utilizza i trigger per acquisire le modifiche ai dati tra editore e abbonato. Inoltre, fornisce le modifiche tra i server quando sia l'editore che l'abbonato sono connessi alla rete. La replica di unione utilizza l'agente di unione per replicare le modifiche ai dati tra l'editore e l'abbonato.
- Replica snapshot – Come indica il nome, Snapshot Replication non si basa né sui log transazionali né sui trigger per acquisire le modifiche. Prende un'istantanea degli articoli coinvolti nella pubblicazione e la applica all'abbonato con i record disponibili al momento dell'istantanea. La replica snapshot utilizza l'agente snapshot per acquisire un'istantanea dell'editore e utilizza l'agente di distribuzione per applicare questi record all'abbonato.
Replica transazionale di SQL Server
La replica transazionale è in genere preferita negli scenari in cui il database di OLTP Publisher ha pesanti attività di INSERT/UPDATE e/o DELETE di dati.
Poiché l'istanza del server Publisher ha un'enorme quantità di I/O DISK in corso, la generazione di report può causare gravi blocchi. Può anche influire sulle prestazioni del server. Quindi, un altro server con dati quasi in tempo reale è utile per scaricare i requisiti di reporting.
Uno dei requisiti fondamentali per la replica transazionale è che le tabelle replicate dispongano di una chiave primaria.
Possiamo riassumere come funziona la replica transazionale. Dai un'occhiata al diagramma dell'architettura di replica transazionale di seguito tratto dalla documentazione ufficiale di Microsoft.
La Pubblicazione viene creata nel database Editore che comprende l'elenco degli Articoli da replicare nel database Abbonati.
La replica transazionale viene in genere inizializzata dall'editore al distributore tramite l'agente snapshot o backup completi. L'agente snapshot è supportato tramite la configurazione guidata della replica. Il backup completo è supportato tramite istruzioni TSQL per inizializzare la replica transazionale.
L'agente di lettura del registro esegue la scansione del registro transazionale del database dell'editore alla ricerca di articoli tracciati. Quindi copia le modifiche ai dati dal registro transazionale al database di distribuzione.
Il database di distribuzione può essere in Editore o Abbonato; può anche essere o un'altra istanza di SQL Server indipendente.
Nota anche le seguenti cose:
- L'agente di lettura log viene eseguito continuamente dal server di distribuzione per cercare nuovi comandi contrassegnati per la replica. Tuttavia, se non desideri eseguire continuamente e desideri invece eseguire in base a una pianificazione, possiamo modificare il processo SQL dell'agente di lettura log che verrà creato.
- L'agente di lettura log preleva tutti i record contrassegnati per la replica dai batch di log transazionali e li invia al database di distribuzione.
- L'agente di lettura registro preleva solo le transazioni impegnate dal registro transazionale del database dell'editore. Pertanto, qualsiasi query di lunga durata sul database di Publisher può influire direttamente sulla replica in attesa del completamento della transazione attiva.
L'agente di distribuzione raccoglie tutti i nuovi comandi non distribuiti dal database di distribuzione e li applica al database di sottoscrizione tramite il meccanismo push o pull. Come accennato in precedenza, se il Distributore di abbonamenti push assume la proprietà di applicare le modifiche dal database di distribuzione all'abbonato mentre in abbonamento pull il database dell'abbonato assume la proprietà di recuperare le modifiche dal database di distribuzione all'abbonato.
Una volta che i record sono stati distribuiti correttamente dal database di distribuzione all'abbonato, verranno contrassegnati come distribuiti e contrassegnati per l'eliminazione dal database di distribuzione. Uno dei lavori di manutenzione della replica delle chiavi denominato Pulizia della distribuzione:il lavoro di distribuzione viene eseguito una volta ogni 10 minuti per eliminare i record distribuiti dal database di distribuzione per mantenere le dimensioni del database di distribuzione sotto controllo.
Con la spiegazione dettagliata dei concetti di replica e replica transazionale, possiamo metterci le mani sopra configurando Replica per AdventureWorks database e verifica della replica per ogni componente discusso in teoria.
Configurazione della replica transazionale passo dopo passo (tramite la GUI SSMS)
La configurazione della replica transazionale prevede 3 passaggi principali:
- Configurazione del database di distribuzione
- Creazione di pubblicazioni
- Creazione dell'abbonamento
Prima di provare a configurare la replica, assicurati che i componenti di replica siano installati come parte dell'installazione di SQL Server oppure utilizza il supporto di SQL Server per installare i componenti di replica, poiché sono necessari per l'attività.
In SSMS, connettiti a Istanza database dell'editore e fai clic con il pulsante destro del mouse su Replica :
La distribuzione non è configurata in questo momento. Quindi, abbiamo l'opzione Configura distribuzione. Possiamo configurare il database di distribuzione utilizzando la procedura guidata di configurazione della distribuzione o tramite la procedura guidata di creazione della pubblicazione.
Per configurare il database di distribuzione e la pubblicazione, attenersi alla seguente procedura:
Espandi Replica e fai clic con il pulsante destro del mouse su Nuova pubblicazione .
Nuova procedura guidata di pubblicazione lancerà. Fai clic su Avanti per vedere il Distributore opzioni di configurazione.
Per impostazione predefinita, sceglie il server di pubblicazione per contenere il database di distribuzione. Se desideri utilizzare un database di distribuzione remota, scegli la seconda opzione. Fai clic su Avanti .
L'opzione successiva riguarda la configurazione della Cartella snapshot . Cambialo nella cartella richiesta. In caso contrario, verrà creato nel percorso della cartella di installazione di SQL Server per impostazione predefinita. Fai clic su Avanti .
Seleziona il Database delle pubblicazioni (ecco AdventureWorks ) e fai clic su Avanti .
Scegli il Tipo di pubblicazione – Replica transazionale . Fai clic su Avanti .
Scegli Articoli per questa pubblicazione. A scopo di test, seleziona tutte le Tabelle e Viste :
Prima di fare clic su Avanti , espandi le tabelle ancora una volta per verificare alcuni problemi.
Alcune tabelle sono contrassegnate da icone rosse. Quando facciamo clic su quelle tabelle, vediamo l'avviso che indica che una tabella non può essere replicata perché non ha una chiave primaria, uno dei requisiti cruciali per la replica transazionale. In seguito entreremo più nel dettaglio. Ora, fai clic su Avanti .
Una pagina con Problemi con gli articoli verrà visualizzato relativo alle dipendenze. Fai clic su Avanti .
L'opzione successiva è Filtra le righe della tabella – poiché stiamo testando la replica di base, possiamo ignorarla. Fai clic su Avanti .
Configura l'agente snapshot – ignora e fai clic su Avanti .
Agente Impostazioni – fai clic su Impostazioni di sicurezza per configurare l'account per eseguire l'agente snapshot e l'agente di lettura log in esso.
Quindi, modifica il Processo dell'agente snapshot da eseguire con l'account di servizio di SQL Server Agent.
Imposta l'Agente per la lettura dei log a Connetti all'editore> Impersonando l'account di processo . Fare clic su OK .
Agent Security verrà aggiornato.
Pertanto, abbiamo configurato il Distributore e tutti gli elementi della Pubblicazione come Articoli , Agente snapshot , Agente per la lettura dei registri e Titoli agente . Abbiamo quasi completato la creazione della pubblicazione tramite procedura guidata.
Se hai bisogno di approfondire gli script TSQL utilizzati per creare la pubblicazione, possiamo controllare il Genera un file di script per creare la pubblicazione opzione. Altrimenti, fai clic su Avanti .
Poiché ho scelto di salvare il file, la procedura guidata mi consente di impostare il Percorso del file di script e nome . Fornisci questi dettagli e fai clic su Avanti .
Il Mago chiede infine il Nome della pubblicazione , l'ho chiamato AdventureWorks_pub con il nome del database e le parole chiave per indicarlo come pubblicazione per una più facile identificazione.
Verifica tutti i dati forniti nel Riepilogo pagina e fai clic su Fine .
La procedura guidata mostrerà lo stato di avanzamento della Creazione della pubblicazione . Quando sarà completo, vedremo la conferma. Fai clic su Chiudi .
Per verificare la corretta creazione del Distributore (Database di distribuzione), espandere i database di sistema:
Per verificare la corretta creazione della Pubblicazione , espandi Pubblicazione locale :
Abbiamo configurato il database di distribuzione e creato il database di pubblicazione sul database AdventureWorks con successo. Ora possiamo procedere con l'Abbonamento creazione
Fai clic con il pulsante destro del mouse sulla nuova Pubblicazione abbiamo appena creato e selezionato Nuove iscrizioni :
La Procedura guidata per le nuove iscrizioni apparirà. Per avviare il processo, fai clic su Avanti .
La Pubblicazione pagina chiede di garantire che sia la Pubblicazione e Editore database sono selezionati. Fai clic su Avanti .
Imposta l'Agente di distribuzione su Spingi o Tira Sottoscrizione. Utilizzeremo il Server dell'editore come Abbonato e quel tipo non avrà alcun impatto. Quindi, lasciamo l'impostazione predefinita Push Sottoscrizione. Fai clic su Avanti .
Seleziona gli Abbonati (Banca dati). Sto selezionando AdventureWorks_REPL ripristinato dallo stesso backup del database AdventureWorks. Fai clic su Avanti .
Imposta la Sicurezza agente :
Dal momento che farò tutto all'interno di un unico server, sto utilizzando l'Account del servizio dell'agente .
La finestra successiva presenta il Distribution Agent Security valori già configurati. Fai clic su Avanti .
Programma di sincronizzazione – lasciarlo al valore predefinito. Fai clic su Avanti .
Inizializza le iscrizioni – lasciarlo con i valori predefiniti. Fai clic su Avanti .
Dopo aver fornito tutti i dettagli necessari, sarai in grado di completare il processo di creazione dell'Abbonamento. Controlla Genera file di script... opzione per studiare gli script in un secondo momento e fare clic su Avanti .
Fornisci il percorso per salvare i file, fai clic su Avanti .
Dai un'occhiata al riepilogo e controlla tutti i valori configurati. Una volta verificato, fai clic su Fine .
La creazione dell'abbonamento è completata. Fai clic su Chiudi .
Ora possiamo vedere l'Abbonamento visualizzato sotto la nostra Pubblicazione .
Configura l'agente snapshot
Il prossimo passo è lavorare sull'Istantanea Agente per inviare i dati iniziali da Editore a Abbonato .
Prima di entrarci, dobbiamo notare il Monitoraggio della replica . Questo strumento fondamentale è disponibile in SSMS per visualizzare lo stato della replica a vari livelli, livello di server, livello di database dell'editore, livello di sottoscrizione e livello di agenti di replica.
Fare clic con il pulsante destro del mouse su Replica /Pubblicazione locale /Abbonamento locale /Pubblicazione o l'Abbonamento abbiamo creato per avviare il Monitoraggio repliche come mostrato di seguito:
Nel Monitoraggio repliche , espandi Server editore (RRJ)> Pubblicazione ([AdventureWorks]:AdventureWorks_pub) per visualizzare i dettagli dell'abbonamento. Fai clic con il pulsante destro del mouse su Abbonamento e seleziona Visualizza dettagli .
Come possiamo vedere, le informazioni sull'Istantanea iniziale per la nostra pubblicazione AdventureWorks_pub non è ancora disponibile. Dovremo eseguire il processo dell'agente snapshot per inviare i dati iniziali al database degli iscritti .
Tieni aperta questa finestra per vedere lo stato di avanzamento di Snapshot dopo aver avviato il processo Snapshot Agent .
Fai clic con il pulsante destro del mouse su Pubblicazione > Visualizza lo stato dell'agente snapshot :
L'agente non è mai stato eseguito messaggio indica che non abbiamo mai eseguito l'agente snapshot. Fai clic su Inizia .
Durante l'esecuzione di Snapshot Agent, puoi guardare l'avanzamento:
Quando tutte le istantanee sono state create, produrrà il messaggio di conferma:
Possiamo vedere i file Snapshot creati di recente nella cartella Snapshot per la quale abbiamo fornito il percorso in precedenza.
Dopo che tutte le istantanee sono state applicate dall'agente di distribuzione al database degli abbonati , visualizzerà lo stato seguente nel Monitoraggio replica aperto finestra:
Congratulazioni! Abbiamo configurato correttamente la replica transazionale utilizzando l'agente snapshot.
Nota :se disponiamo di un enorme database dell'editore, la creazione di snapshot potrebbe richiedere molto tempo. Pertanto, si consiglia di utilizzare il backup completo del database di Publisher invece di eseguire l'agente snapshot:tratteremo questo problema negli articoli successivi.
Verifica dei componenti di replica
Tutti i componenti di replica possono essere verificati sia dalla GUI di SSMS che dalle query TSQL. Ne discuteremo in ulteriori articoli e qui spiegheremo rapidamente come visualizzare le proprietà dei componenti seguenti.
Editore
In SSMS, fai clic con il pulsante destro del mouse su Replica > Proprietà dell'editore > Banca dati di pubblicazione :
Per visualizzare i dettagli sull'editore , esegui le query seguenti sul database di distribuzione.
USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO
Abbonato
Le informazioni sull'abbonato possono essere ottenute con la query seguente in SSMS.
USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info
Distributore
In SSMS, fai clic con il pulsante destro del mouse su Replica > Distributore Proprietà :
Fai clic su Editori per visualizzare l'elenco di tutti gli editori che utilizzano questo database di distribuzione.
In SSMS, possiamo eseguire la query seguente per ottenere gli stessi dettagli.
USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO
Articoli
Fai clic con il pulsante destro del mouse su Pubblicazione > Proprietà di pubblicazione > Articoli . Vedrai l'elenco di tutti gli articoli disponibili. Le proprietà dei singoli articoli possono essere modificate cliccando su Proprietà articolo anche.
USE AdventureWorks
GO
-- To View all articles available under a Publication
exec sp_helparticle @publication = 'Adventureworks_pub'
GO
-- To View all article columns for a particular article available under a Publication
exec sp_helparticlecolumns @publication = 'Adventureworks_pub', @article = 'Address'
GO
USE distribution
GO
SELECT * from MSArticles
Pubblicazione
Fai clic con il pulsante destro del mouse su Pubblicazione > Proprietà :
In SSMS, possiamo eseguire la query seguente per visualizzare le Proprietà della pubblicazione :
USE AdventureWorks
GO
exec sp_helppublication
GO
USE distribution
GO
SELECT * FROM MSPublications
Abbonamento
Fai clic con il pulsante destro del mouse su Abbonamento > Proprietà dell'abbonamento :
In SSMS, possiamo eseguire lo script seguente per ottenere le informazioni sull'abbonamento:
USE AdventureWorks
GO
exec sp_helpsubscription
GO
USE distribution
GO
SELECT * FROM MSsubscriptions
GO
Agenti di replica
In Processi di SQL Server Agent , possiamo trovare i Offerte di lavoro specifici creato per tutti gli agenti di replica:
In SSMS, possiamo eseguire la query per scoprire quale lavoro è il lavoro dell'agente di lettura log necessario , Lavoro dell'agente istantaneo e Lavori di agente di distribuzione . Inoltre, possiamo vedere il processo di pulizia dell'agente di distribuzione e molti altri lavori relativi alla replica creati durante l'impostazione interna della pubblicazione e degli abbonamenti.
Come funziona l'agente di lettura log
L'Agente per la lettura dei registri legge tutti i dati vincolati dai registri transazionali del database di Publisher e li invia al database del Distributore. Anche se Microsoft non fornisce un modo ufficiale per leggere i log transazionali, ci sono poche funzioni non documentate come fn_dblog() e fn_dump_dblog() in grado di leggere i dati dai file di registro. Tuttavia, queste funzioni non sono documentate e non sono coperte dal supporto Microsoft. Pertanto, non li esploreremo ulteriormente.
Come l'agente di distribuzione fornisce le modifiche ai dati al database degli abbonati
Una volta che i dati sono stati scritti nel database di distribuzione, è possibile leggere come tali dati vengono archiviati nelle tabelle di distribuzione. Per questo, applichiamo sp_browsereplcmds procedura:recupera i record attraverso i MSrepl_commands e MSrepl_transactions tabelle.
A scopo didattico, prendiamo una tabella con 3 colonne denominata Person.ContactType :
L'Abbonamento creato eseguirà 3 procedure per ogni articolo che fa parte della Pubblicazione nel database degli abbonati con le seguenti convenzioni di denominazione:
- dbo.sp_MSins_
- dbo.sp_MSupd_
- dbo.sp_MSdel_
Per l'articolo Person.ContactType Table, possiamo vedere le procedure seguenti create nel database degli abbonati:
- dbo.sp_MSins_PersonContactType – INSERIRE nuovi record acquisiti dal database dei registri delle transazioni del publisher e quindi propagati al database di distribuzione.
- dbo.sp_MSupd_PersonContactType – AGGIORNAMENTO modifiche acquisite dal database dei registri delle transazioni del publisher e quindi propagate al database di distribuzione.
- dbo.sp_MSdel_PersonContactType – ELIMINA record acquisiti dai registri delle transazioni del database di Publisher e quindi propagati al database di distribuzione.
Script of the dbo.sp_MSins_PersonContactType Procedure
As you can see, it’s a straightforward INSERT statement that comes out of the distribution database:
ALTER procedure [dbo].[sp_MSins_PersonContactType]
@c1 int,
@c2 nvarchar(50),
@c3 datetime
as
begin
insert into [Person].[ContactType] (
[ContactTypeID],
[Name],
[ModifiedDate]
) values (
@c1,
@c2,
@c3 )
end
GO
Script of the dbo.sp_MSupd_PersonContactType Procedure
The script relies on the Primary Key values to identify the unique record for updating:
ALTER procedure [dbo].[sp_MSupd_PersonContactType]
@c1 int = NULL,
@c2 nvarchar(50) = NULL,
@c3 datetime = NULL,
@pkc1 int = NULL,
@bitmap binary(1)
as
begin
declare @primarykey_text nvarchar(100) = ''
update [Person].[ContactType] set
[Name] = case substring(@bitmap,1,1) & 2 when 2 then @c2 else [Name] end,
[ModifiedDate] = case substring(@bitmap,1,1) & 4 when 4 then @c3 else [ModifiedDate] end
where [ContactTypeID] = @pkc1
if @@rowcount = 0
if @@microsoftversion>0x07320000
Begin
if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
Begin
set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13233
End
Else
exec sp_MSreplraiserror @errorid=20598
End
end
GO
Script of the dbo.sp_MSdel_PersonContactType Procedure
This script relies on the Primary Key values to identify a unique record for deleting records from the Subscriber :
ALTER procedure [dbo].[sp_MSdel_PersonContactType]
@pkc1 int
as
begin
declare @primarykey_text nvarchar(100) = ''
delete [Person].[ContactType]
where [ContactTypeID] = @pkc1
if @@rowcount = 0
if @@microsoftversion>0x07320000
Begin
if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
Begin
set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13234
End
Else
exec sp_MSreplraiserror @errorid=20598
End
end
GO
This clearly explains why Transactional Replication enforces the Primary Key as a key requirement for tables to be added as part of Replication .
Now, let’s see the Transactional Replication in action. Let’s change some data in the Publisher database. For simplicity, I’ll take the same Person.ContactType tabella.
Executing the SELECT statement on the table yields 20 records:
Next, I INSERTed a sample record into the Person.ContactType tabella:
And, I UPDATE the newly inserted record:
DELETE the newly inserted record from the table:
We need to verify these transactions in Replication using sp_browsereplcmds
Changes from Person.ContactType were captured from the Transactional Logs of Publisher Database (AdventureWorks ) and sent to the Distribution database in the same order. Later, it was propagated to the Subscriber Database (AdventureWorks_REPL ).
Conclusione
Thanks for reading this long power-packed article! We have gone through a variety of topics, such as:
- Replication Architecture and Terminologies
- SQL Server Replication Types
- SQL Server Transactional Replication in Detail
- SQL Server Transactional Replication Configuration (Default approach)
- SQL Server Transactional Replication Verification
- SQL Server Transactional Replication in action
I hope that you’ve found lots of helpful information in this article. In subsequent parts, we’ll explore troubleshooting various issues that are frequently encountered in Replication, and learn how to handle them more efficiently.
