Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Problemi di replica transazionale di SQL Server

Abbiamo iniziato a parlare dei problemi di replica transazionale di SQL Server in precedenza. Ora continueremo con alcune altre demo pratiche per comprendere i problemi di prestazioni della replica che si verificano di frequente e come risolverli correttamente.

Abbiamo già discusso problemi come problemi di configurazione, problemi di autorizzazione, problemi di connettività e problemi di integrità dei dati insieme alla risoluzione dei problemi e alla loro risoluzione. Ora ci concentreremo su vari problemi di prestazioni e problemi di danneggiamento che incidono sulla replica di SQL Server.

Poiché i problemi di corruzione sono un argomento molto vasto, discuteremo come il loro impatto solo in questo articolo e non entreremo nei dettagli. Ho selezionato diversi scenari che possono rientrare in Problemi di prestazioni e corruzione in base alla mia esperienza:

  • Problemi di prestazioni
    • Transazioni attive di lunga durata nel database dell'editore
    • Operazioni di INSERT/UPDATE/DELETE in blocco sugli articoli
    • Enormi modifiche ai dati all'interno di una singola transazione
    • Blocchi nel database di distribuzione
  • Problemi relativi alla corruzione
    • Corruzioni del database dell'editore
    • Corruzioni del database di distribuzione
    • Corruzioni del database degli abbonati
    • Corruzioni del database MSDB

Problemi di prestazioni

La replica transazionale di SQL Server è un'architettura complicata che coinvolge diversi parametri come il database dell'editore, il database del distributore (distribuzione), il database dell'abbonato e diversi agenti di replica in esecuzione come processi di SQL Server Agent.

Poiché abbiamo discusso in dettaglio tutti questi elementi nei nostri articoli precedenti, conosciamo l'importanza di ciascuno per la funzionalità di replica. Qualsiasi elemento che influisca su questi componenti può influire sulle prestazioni della replica di SQL Server.

Ad esempio, l'istanza del database di Publisher contiene un database critico con molte transazioni al secondo. Tuttavia, le risorse del server presentano un collo di bottiglia come l'utilizzo costante della CPU superiore al 90% o l'utilizzo della memoria superiore al 90%. Avrà sicuramente un impatto sulle prestazioni del lavoro dell'agente di lettura log che legge i dati di modifica dai registri transazionali del database del publisher.

Allo stesso modo, qualsiasi scenario di questo tipo nelle istanze del database del distributore o dell'abbonato può influire sull'agente snapshot o sull'agente di distribuzione. Pertanto, come DBA, devi assicurarti che le risorse del server come CPU, memoria fisica e larghezza di banda di rete siano configurate in modo efficiente per le istanze del database Publisher, Distributor e Subscriber.

Partendo dal presupposto che i server di database dell'editore, dell'abbonato e del distributore siano configurati correttamente, è possibile che si verifichino ancora problemi di prestazioni di replica quando si verificano gli scenari seguenti.

Transazioni attive di lunga durata nel database dell'editore

Come indica il nome, le transazioni attive a esecuzione prolungata mostrano che è presente una chiamata all'applicazione o un'operazione utente nell'ambito della transazione in esecuzione da molto tempo.

Trovare una transazione attiva di lunga durata significa che la transazione non è ancora stata salvata e può essere annullata o salvata dall'applicazione. Ciò impedirà il troncamento del registro delle transazioni, con conseguente aumento continuo delle dimensioni del file del registro delle transazioni.

L'agente di lettura log esegue la scansione di tutti i record impegnati che sono contrassegnati per la replica dai log transazionali in un ordine serializzato in base al numero di sequenza del log (LSN), ignorando tutte le altre modifiche che si verificano per gli articoli che non vengono replicati. Se i comandi delle transazioni attive a esecuzione prolungata non sono ancora stati sottoposti a commit, la replica salterà l'invio di tali comandi e invierà tutte le altre transazioni vincolate al database di distribuzione. Una volta che la transazione attiva di lunga durata è stata confermata, i record verranno inviati al database di distribuzione e fino a quel momento la parte inattiva del file di registro delle transazioni del DB Publisher non verrà cancellata causando un aumento delle dimensioni del file di registro delle transazioni del database di Publisher.

Possiamo testare lo scenario di transazione attiva di lunga durata eseguendo i passaggi seguenti:

Per impostazione predefinita, l'agente di distribuzione ripulisce tutte le modifiche salvate al database dell'abbonato, conservando l'ultimo record per monitorare le nuove modifiche in base al numero di sequenza del registro (LSN).

Possiamo eseguire le seguenti query per verificare lo stato dei record disponibili in MSRepl_Commands tabelle o utilizzando sp_browsereplcmds procedura nel database di distribuzione:

exec sp_browsereplcmds
GO
SELECT * FROM MSrepl_commands

Ora, apri una nuova finestra di query ed esegui lo script seguente per creare una transazione attiva di lunga durata su AdventureWorks Banca dati. Si noti che lo script seguente non include alcun comando ROLLBACK o COMMIT TRANSACTION. Pertanto, si consiglia di non eseguire questo tipo di comandi sul database di produzione.

BEGIN TRANSACTION 

SET IDENTITY_INSERT Person.ContactType ON;
insert into person.ContactType (ContactTypeId, Name, ModifiedDate) values ( 22, 'Test New Position', GETDATE());
SET IDENTITY_INSERT Person.ContactType OFF;

Possiamo verificare che questo nuovo record non sia stato replicato nel database dell'abbonato. Per questo, eseguiremo l'istruzione SELECT su Person.ContactType tabella nel database degli abbonati:

Verifichiamo se il comando INSERT sopra è stato letto da Log Reader Agent e scritto nel database di distribuzione.

Esegui di nuovo gli script dalla parte del passaggio 1. I risultati mostrano ancora lo stesso vecchio stato, a conferma che il record non è stato letto dai registri delle transazioni del database dell'editore.

Ora apri una Nuova query finestra ed eseguire lo script UPDATE di seguito per vedere se l'agente di lettura log è stato in grado di saltare la transazione attiva di lunga durata e leggere le modifiche apportate da questa istruzione UPDATE.

UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

Verificare nel database di distribuzione se l'agente di lettura log è in grado di acquisire questa modifica. Esegui lo script come parte del passaggio 1:

Poiché l'istruzione UPDATE di cui sopra è stata salvata nel database di Publisher, l'agente di lettura log potrebbe eseguire la scansione di questa modifica e inserirla nel database di distribuzione. Successivamente, ha applicato questa modifica al database degli abbonati come mostrato di seguito:

INSERT su Person.ContactType verrà replicato nel database dell'abbonato solo dopo che la transazione INSERT è stata salvata nel database dell'editore. Prima di impegnarci, possiamo verificare rapidamente come identificare una transazione attiva di lunga durata, comprenderla e gestirla in modo efficiente.

Identifica una transazione attiva di lunga durata

Per verificare la presenza di transazioni attive di lunga durata su qualsiasi database, apri una nuova Finestra delle query e connettiamoci al rispettivo database che dobbiamo controllare. Esegui il DBCC OPENTRAN comando console – è un comando della console del database per visualizzare le transazioni aperte nel database al momento dell'esecuzione.

USE AdventureWorks
GO
DBCC OPENTRAN

Ora sappiamo che c'era uno SPID (ID processo server ) 69 in esecuzione da molto tempo. Verifichiamo quale comando è stato eseguito su quella transazione utilizzando il DBCC INPUTBUFFER comando console (un comando della console del database utilizzato per identificare il comando o l'operazione in corso sull'ID processo del server selezionato).

Per maggiore leggibilità, sto copiando EventInfo valore del campo e formattandolo per mostrare il comando che abbiamo eseguito in precedenza.

Se non ci sono transazioni attive di lunga durata nel database selezionato, riceveremo il messaggio seguente:

Simile al DBCC OPENTRAN comando della console, possiamo SELEZIONARE da DMV denominato sys.dm_tran_database_transactions per ottenere risultati più dettagliati (fare riferimento all'articolo MSDN per ulteriori dati).

Ora sappiamo come identificare la transazione di lunga durata. Possiamo eseguire il commit della transazione e vedere come viene replicata l'istruzione INSERT.

Vai alla finestra in cui abbiamo inserito il record nel Person.ContactType tabella all'interno dell'Ambito della Transazione ed eseguire la TRANSAZIONE COMMIT come mostrato di seguito:

L'esecuzione di COMMIT TRANSACTION ha eseguito il commit del record nel database dell'editore. Pertanto, dovrebbe essere visibile nel database di distribuzione e nel database degli abbonati:

Se hai notato, i record meno recenti del database di distribuzione sono stati eliminati dal processo di pulizia dell'agente di distribuzione. Il nuovo record per INSERT su Person.ContactType era visibile in MSRepl_cmds tabella.

Dai nostri test, abbiamo imparato le seguenti cose:

  • Il processo dell'agente di lettura log di Replica transazionale di SQL Server eseguirà la scansione dei record vincolati solo dal database dei registri transazionali del server di pubblicazione e INSERT nel database dell'abbonato.
  • L'ordine dei dati modificati sul database dell'editore inviato all'abbonato sarà basato sullo stato e sull'ora Impegnati nel database dell'editore anche se i dati replicati avranno la stessa ora del database dell'editore.
  • L'identificazione delle transazioni attive di lunga durata può aiutare a risolvere la crescita del file di registro transazionale dell'editore o del distributore o dell'abbonato o di qualsiasi database.

Operazioni SQL INSERT/UPDATE/DELETE in blocco sugli articoli

Con enormi dati che risiedono nel database di Publisher, spesso ci ritroviamo con i requisiti per INSERIRE o AGGIORNARE o ELIMINARE enormi record nelle tabelle replicate.

Se le operazioni INSERT, UPDATE o DELETE vengono eseguite in una singola Transazione, finirà sicuramente nella Replica bloccata per molto tempo.

Diciamo che dobbiamo INSERIRE 10 milioni di record in una tabella replicata. L'inserimento di tali record in una singola ripresa causerà problemi di prestazioni.

INSERT INTO REplicated_table
SELECT * FROM Source_table

Invece, possiamo INSERIRE record in batch di 0,1 o 0,5 milioni di record in un WHILE ciclo continuo o Ciclo CURSORE e garantirà una replica più rapida. Potremmo non ricevere problemi importanti per le istruzioni INSERT a meno che altrimenti la tabella coinvolta abbia molti indici. Tuttavia, ciò avrà un enorme impatto sulle prestazioni per le istruzioni UPDATE o DELETE.

Si supponga di aver aggiunto una nuova colonna alla tabella Replicata che ha circa 10 milioni di record. Vogliamo aggiornare questa nuova colonna con un valore predefinito.

Idealmente, il comando seguente funzionerà correttamente per AGGIORNARE tutti i 10 milioni di record con il valore predefinito come Abc :

-- UPDATE 10 Million records on Replicated Table with some DEFAULT values
UPDATE Replicated_table
SET new_column = 'Abc'

Tuttavia, per evitare impatti sulla replica, dovremmo eseguire l'operazione UPDATE di cui sopra in batch di 0,1 o 0,5 milioni di record per evitare problemi di prestazioni.

-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
	UPDATE TOP(100000) Replicated_Table
	SET new_Column = 'Abc'
	WHERE new_column is NULL

	IF @@ROWCOUNT = 0
	BREAK
END

Allo stesso modo, se dobbiamo ELIMINARE circa 10 milioni di record da una tabella replicata, possiamo farlo in batch:

-- DELETE 10 Million records on Replicated Table with some DEFAULT values
DELETE FROM Replicated_table

-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
	DELETE TOP(100000) Replicated_Table

	IF @@ROWCOUNT = 0
	BREAK
END

La gestione efficiente di BULK INSERT, UPDATE o DELETE può aiutare a risolvere i problemi di replica.

Suggerimento professionale :per INSERIRE dati di grandi dimensioni in una tabella replicata nel database di Publisher, utilizzare la procedura guidata IMPORTA/ESPORTA in SSMS, poiché inserirà record in batch di 10000 o in base alla dimensione del record calcolata più velocemente da SQL Server.

Enormi modifiche ai dati all'interno di una singola transazione

Per mantenere l'integrità dei dati dal punto di vista dell'applicazione o dello sviluppo, molte applicazioni hanno transazioni esplicite definite per operazioni critiche. Tuttavia, se vengono eseguite molte operazioni (INSERT, UPDATE o DELETE) all'interno di un singolo ambito di transazione, l'agente di lettura log attenderà prima il completamento della transazione, come abbiamo visto in precedenza.

Una volta che la transazione viene confermata dall'applicazione, l'agente di lettura log deve eseguire la scansione delle enormi modifiche ai dati eseguite sui registri delle transazioni del database di Publisher. Durante quella scansione, possiamo vedere gli avvisi o i messaggi informativi nell'agente di lettura log come

L'agente di lettura log sta esaminando il registro delle transazioni per i comandi da replicare. Sono stati scansionati circa xxxxxx record di registro nel passaggio n. xxxx di cui sono stati contrassegnati per la replica, tempo trascorso xxxxxxxxx (ms)

Prima di identificare la soluzione per questo scenario, è necessario comprendere come l'agente di lettura dei registri esegue la scansione dei record dai registri transazionali e inserisce i record nel database di distribuzione MSrepl_transactions e MSrepl_cmds tabelle.

SQL Server dispone internamente di un Log Sequence Number (LSN) all'interno dei registri transazionali. L'agente di lettura log utilizza i valori LSN per analizzare le modifiche contrassegnate per la replica di SQL Server nell'ordine.

Log Reader Agent esegue sp_replcmds stored procedure estesa per recuperare i comandi contrassegnati per la replica dal database dei registri transazionali del publisher.

Sp_replcmds accetta un parametro di input denominato @maxtrans per recuperare il numero massimo di transazioni. Il valore predefinito sarebbe 1, il che significa che eseguirà la scansione del numero di transazioni disponibili dai registri da inviare al database di distribuzione. Se sono presenti 10 operazioni INSERT eseguite tramite una singola transazione e salvate nel database di Publisher, un singolo batch potrebbe contenere 1 transazione con 10 comandi.

Se vengono identificate molte transazioni con comandi minori, Log Reader Agent combinerà più transazioni o XACT numero di sequenza a un singolo batch di replica. Ma viene memorizzato come un diverso XACT Sequenza numero in MSRepl_transactions tavolo. I singoli comandi appartenenti a tale transazione verranno acquisiti in MSRepl_commands tabella.

Per verificare le cose di cui abbiamo discusso sopra, sto aggiornando il ModifiedDate colonna di dbo.AWBuildVersion tabella alla data odierna e guarda cosa succede:

UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

Prima di eseguire l'AGGIORNAMENTO, verifichiamo i record presenti nei MSrepl_commands e MSrepl_transactions tabelle:

Ora, esegui lo script UPDATE sopra e verifica i record presenti in quelle 2 tabelle:

Un nuovo record con l'ora di UPDATE è stato inserito in MSrepl_transactions tabella con il vicino entry_time . Controllo del comando su questo xact_seqno mostrerà l'elenco dei comandi raggruppati logicamente utilizzando sp_browsereplcmds procedura.

In Replication Monitor, possiamo vedere una singola istruzione UPDATE acquisita in 1 transazione/i con 1 comando/i dall'editore al distributore.

E possiamo vedere lo stesso comando essere consegnato dal Distributore all'Abbonato in una frazione di secondo di differenza. Indica che la replica sta avvenendo correttamente.

Ora, se c'è un numero enorme di transazioni combinate in un unico xact_seqno , possiamo vedere messaggi come 10 transazioni con 5000 comandi sono state consegnate .

Verifichiamolo eseguendo UPDATE su 2 tabelle diverse contemporaneamente:

Possiamo vedere due record di transazione in MSrepl_transactions tabella corrispondente alle due operazioni di UPDATE e poi il n. di record in quella tabella corrispondenti al n. di record aggiornati.

Il risultato delle MSrepl_transactions tabella:

Il risultato dei MSrepl_commands tabella:

Tuttavia, abbiamo notato che queste 2 transazioni sono raggruppate logicamente dal Log Reader Agent e combinate in un unico batch come 2 transazioni con 109225 comandi.

Ma prima potremmo vedere messaggi come Delivering Transazioni replicate, xact count:1, command count 46601 .

Ciò avverrà fino a quando l'agente di lettura dei registri non eseguirà la scansione dell'insieme completo di modifiche e identificherà che 2 transazioni UPDATE sono state lette completamente dai registri transazionali.

Una volta che i comandi sono stati completamente letti dai registri transazionali, vediamo che 2 transazioni con 109225 comandi sono state consegnate dall'agente del lettore di registri:

Poiché l'agente di distribuzione è in attesa della replica di un'enorme transazione, potremmo visualizzare un messaggio del tipo Delivering Transazioni replicate indicando che è stata replicata un'enorme transazione e che dobbiamo attendere che venga replicata completamente.

Una volta replicato, possiamo vedere anche il seguente messaggio nell'agente di distribuzione:

Diversi modi sono utili per risolvere questi problemi.

Modo 1:CREA una nuova stored procedure SQL

È necessario creare una nuova stored procedure e incapsularvi la logica dell'applicazione nell'ambito di Transaction.

Una volta creato, aggiungi l'articolo di stored procedure a Replica e modifica la proprietà dell'articolo Replica in Esecuzione della stored procedure opzione.

Aiuterà a eseguire l'articolo Stored procedure sull'abbonato invece di replicare tutte le singole modifiche ai dati in corso.

Esaminiamo come l'Esecuzione della Stored Procedure l'opzione Replica riduce il carico sulla replica. Per fare ciò, possiamo creare una stored procedure di prova come mostrato di seguito:

CREATE procedure test_proc
AS
BEGIN
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

UPDATE TOP(10) Production.TransactionHistoryArchive
SET ModifiedDate  = GETDATE()

UPDATE TOP(10) Person.Person
SET ModifiedDate  = GETDATE()
END

La procedura precedente AGGIORNA un singolo record su AWBuildVersion tabella e 10 record ciascuno in Production.TransactionHistoryArchive e Persona.Persona tabelle per un totale di 21 modifiche record.

Dopo aver creato questa nuova procedura sia nell'editore che nel Sottoscrittore, aggiungerla a Replica. Per questo, fai clic con il pulsante destro del mouse su Pubblicazione e scegli l'articolo della procedura su Replica con l'impostazione predefinita Solo definizione di stored procedure opzione.

Una volta terminato, possiamo verificare i record disponibili in MSrepl_transactions e MSrepl_commands tabelle.

Ora, eseguiamo la procedura nel database di Publisher per vedere quanti record vengono tracciati.

Possiamo vedere quanto segue nelle tabelle di distribuzione MSrepl_transactions e MSrepl_commands :

Tre xact_seqno sono stati creati per tre operazioni UPDATE in MSrepl_transactions tabella e 21 comandi sono stati inseriti in MSrepl_commands tabella.

Apri Replication Monitor e verifica se vengono inviati come 3 batch di replica diversi o come un unico batch con 3 transazioni insieme.

Possiamo vedere che tre xact_seqno è stato consolidato come un unico batch di replica. Quindi, possiamo vedere che 3 transazioni con 21 comandi sono state consegnate correttamente.

Rimuoviamo la procedura da Replica e la riaggiungiamo con la seconda Esecuzione della Stored Procedure opzione. Ora, esegui la procedura e osserva come vengono replicati i record.

Il controllo dei record dalle tabelle di distribuzione mostra i dettagli seguenti:

Ora, esegui la procedura sul database di Publisher e guarda quanti record vengono registrati nelle tabelle di distribuzione. L'esecuzione di una procedura ha aggiornato 21 record (1 record, 10 record e 10 record) come in precedenza.

La verifica delle tabelle di distribuzione mostra i dati seguenti:

Diamo una rapida occhiata a sp_browsereplcmds per vedere il comando effettivo ricevuto:

Il comando è “{call “dbo”.”test_proc” }” che verrà eseguito sul database degli abbonati.

In Replication Monitor, possiamo vedere che solo 1 transazione/i con 1 comando/i è stata consegnata tramite Replica:

Nel nostro test case, abbiamo utilizzato una procedura con solo 21 modifiche ai dati. Tuttavia, se lo facciamo per una procedura complicata che comporta milioni di modifiche, allora lo Stored Procedure si avvicina con l'Esecuzione della Stored Procedure l'opzione sarà efficiente nel ridurre il carico di replica.

È necessario convalidare questo approccio verificando se la procedura ha la logica per aggiornare solo lo stesso insieme di record nei database Publisher e Subscriber. In caso contrario, ciò creerà problemi di incoerenza dei dati tra l'editore e l'abbonato.

Modo 2:configurazione dei parametri dell'agente di lettura log MaxCmdsInTran, ReadBatchSize e ReadBatchThreshold

MaxCmdsInTran – indica il numero massimo di comandi che possono essere raggruppati logicamente all'interno di una transazione durante la lettura dei dati dal database dei registri transazionali del publisher e scritti nel database di distribuzione.

Nei nostri test precedenti, abbiamo notato che circa 109225 comandi sono stati accumulati in un'unica sequenza esatta di replica, con conseguente lieve lentezza o latenza. Se impostiamo MaxCmdsInTran parametro a 10000, la singola sequenza esatta il numero verrà suddiviso in 11 xact con conseguente invio più rapido dei comandi dall'editore al distributore . Anche se questa opzione consente di ridurre la contesa del database di distribuzione e di replicare più rapidamente i dati dal server di pubblicazione al database dell'abbonato, prestare attenzione durante l'utilizzo di questa opzione. Potrebbe finire per consegnare i dati al database dell'abbonato e accedervi dalle tabelle del database dell'abbonato prima della fine dell'ambito della transazione originale.

ReadBatchSize – Questo parametro potrebbe non essere utile per un singolo scenario di transazione di grandi dimensioni. Tuttavia, aiuta quando ci sono molte transazioni più piccole che si verificano nel database di Publisher.

Se il numero di comandi per transazione è inferiore, l'agente di lettura log combinerà più modifiche in un unico ambito di transazione del comando di replica. La dimensione del batch di lettura indica quante transazioni possono essere lette nel registro delle transazioni prima di inviare le modifiche al database di distribuzione. I valori possono essere compresi tra 500 e 10000.

Leggi Soglia batch – indica il numero di comandi da leggere dal registro transazionale del database di Publisher prima di essere inviati al Sottoscrittore con un valore predefinito di 0 per eseguire la scansione del file di registro completo. Tuttavia, possiamo ridurre questo valore per inviare i dati più velocemente limitandolo a 10000 o 100000 comandi del genere.

Modo 3:configurazione dei migliori valori per il parametro SubscriptionStreams

SubscriptionStreams – indica il numero di connessioni che un agente di distribuzione può eseguire in parallelo per recuperare i dati dal database di distribuzione e propagarli al database dell'abbonato. Il valore predefinito è 1 e suggerisce un solo flusso o connessione dalla distribuzione al database dell'abbonato. I valori possono essere compresi tra 1 e 64. Se vengono aggiunti più flussi di abbonamento, potrebbero verificarsi congestione CXPACKET (in altre parole, parallelismo). Pertanto, dovresti prestare attenzione durante la configurazione di questa opzione in Produzione.

Per riassumere, prova a evitare enormi INSERT, UPDATE o DELETE in una singola transazione. Se è impossibile eliminare queste operazioni, l'opzione migliore sarebbe testare i metodi sopra indicati e scegliere quello che si adatta meglio alle tue condizioni specifiche.

Blocchi nel database di distribuzione

Il database di distribuzione è il cuore della replica transazionale di SQL Server e, se non viene mantenuto correttamente, si verificheranno molti problemi di prestazioni.

Per riassumere tutte le pratiche consigliate per la configurazione del database di distribuzione, dobbiamo assicurarci che le configurazioni seguenti siano eseguite correttamente:

  1. I file di dati dei database di distribuzione devono essere collocati su unità con IOPS elevato. Se il database dell'editore avrà molte modifiche ai dati, dobbiamo assicurarci che il database di distribuzione sia posizionato su un'unità con IOPS elevato. Riceverà continuamente dati dall'agente di lettura log, inviando dati al database dell'abbonato tramite l'agente di distribuzione. Tutti i dati replicati verranno eliminati dal database di distribuzione ogni 10 minuti tramite il processo di pulizia della distribuzione.
  2. Configura le proprietà Dimensioni file iniziali e Crescita automatica del database di distribuzione con i valori consigliati in base ai livelli di attività del database di Publisher. In caso contrario, causerà la frammentazione dei dati e dei file di registro causando problemi di prestazioni.
  3. Includi i database di distribuzione nei normali lavori di manutenzione dell'indice configurati sui server in cui si trova il database di distribuzione.
  4. Includi i database di distribuzione nella pianificazione dei processi di backup completo per risolvere eventuali problemi specifici.
  5. Assicurati che il Pulizia della distribuzione:distribuzione il lavoro viene eseguito ogni 10 minuti secondo la pianificazione predefinita. In caso contrario, le dimensioni del database di distribuzione continuano ad aumentare e causano problemi di prestazioni.

Come abbiamo notato finora, nel database di distribuzione, le tabelle chiave coinvolte sono MSrepl_transactions e MSrepl_commands . I record vengono inseriti lì dal lavoro dell'agente di lettura log, selezionati dal lavoro dell'agente di distribuzione, applicati al database dell'abbonato e quindi eliminati o ripuliti dal lavoro dell'agente di pulizia della distribuzione.

Se il database di distribuzione non è configurato correttamente, possiamo riscontrare blocchi di sessione su queste 2 tabelle, che comporteranno problemi di prestazioni di replica di SQL Server.

Possiamo eseguire la query seguente su qualsiasi database per visualizzare le sessioni di blocco disponibili nell'istanza corrente di SQL Server:

SELECT * 
FROM sys.sysprocesses
where blocked > 0
order by waittime desc

Se la query precedente restituisce dei risultati, possiamo identificare i comandi su quelle sessioni bloccate eseguendo il DBCC INPUTBUFFER(spid) comando della console e intraprendere le azioni di conseguenza.

Problemi relativi alla corruzione

Un database di SQL Server utilizza l'algoritmo o la logica per archiviare i dati nelle tabelle e mantenerli nelle estensioni o nelle pagine. Il danneggiamento del database è un processo mediante il quale lo stato fisico dei file/estensioni/pagine relativi al database cambia da normale a instabile o allo stato di mancato recupero, rendendo più difficile o impossibile il recupero dei dati.

Tutti i database di SQL Server sono soggetti a danneggiamenti del database. Le cause possono essere:

  • Errori hardware come problemi di disco, archiviazione o controller;
  • Errori del sistema operativo del server come problemi di patch;
  • Interruzioni di alimentazione con conseguente arresto improvviso dei server o arresto improprio del database.

Se siamo in grado di ripristinare o riparare i database senza alcuna perdita di dati, la replica di SQL Server non sarà interessata. Tuttavia, se si verificano perdite di dati durante il ripristino o la riparazione di database corrotti, inizieremo a ricevere molti problemi di integrità dei dati di cui abbiamo discusso nel nostro articolo precedente.

I danneggiamenti possono verificarsi in vari componenti, come ad esempio:

  • Dati dell'editore/danneggiamento del file di registro
  • Dati dell'abbonato/danneggiamento del file di registro
  • Dati del database di distribuzione/danneggiamento del file di registro
  • Dati del database Msdb/danneggiamento del file di registro

If we receive a lot of data integrity issues after fixing up Corruption issues, it is recommended to remove the Replication completely, fix all Corruption issues in the Publisher, Subscriber, or Distributor database and then reconfigure Replication to fix it. Otherwise, data integrity issues will persist and lead to data inconsistency across the Publisher and Subscriber. The time required to fix the Data integrity issues in case of Corrupted databases will be much more compared to configuring Replication from scratch. Hence identify the level of Corruption encountered and take optimal decisions to resolve the Replication issues faster.

Wondering why msdb database corruption can harm Replication? Since msdb database hold all details related to SQL Server Agent Jobs including Replication Agent jobs, any corruption on msdb database will harm Replication. To recover quickly from msdb database corruptions, it is recommended to restore msdb database from the last Full Backup of msdb database. This also signifies the importance of taking Full Backups of all system databases including msdb database.

Conclusione

Thanks for successfully going through the final power-packed article about the Performance issues in the SQL Server Transactional Replication. If you have gone through all articles carefully, you should be able to troubleshoot almost any Transactional Replication-based issues and fix them out efficiently.

If you need any further guidance or have any Transactional Replication-related issues in your environment, you can reach out to me for consultation. And if I missed anything essential in this article, you are welcome to point to that in the Comments section.