Considerazioni sulla replica transazionale
La replica transazionale presenta alcuni requisiti:
Spazio del log delle transazioni.
Spazio su disco per il database di distribuzione.
Chiavi primarie per ogni tabella pubblicata.
Trigger.
Tipi di dati LOB (Large OBject).
Sottoscrizioni aggiornabili (se vengono utilizzate). Per ulteriori informazioni sui requisiti per le sottoscrizioni aggiornabili, vedere Sottoscrizioni aggiornabili per la replica transazionale.
Spazio del log delle transazioni
Per ogni database da pubblicare utilizzando la replica transazionale assicurarsi che nel log delle transazioni sia disponibile spazio sufficiente. Il log delle transazioni di un database pubblicato può richiedere più spazio del log di un database identico ma non pubblicato, poiché i record del log non vengono troncati fino a quando non vengono trasferiti al database di distribuzione.
Se il database di distribuzione non è disponibile oppure l'agente di lettura log non è in esecuzione, le dimensioni del log delle transazioni di un database di pubblicazione aumentano in modo progressivo. Non è possibile troncare il log dopo la transazione pubblicata meno recente che non è stata recapitata al database di distribuzione. Per il file di log delle transazioni è consigliabile impostare l'aumento automatico delle dimensioni in modo che il log risulti predisposto per queste condizioni. Per ulteriori informazioni, vedere CREATE DATABASE (Transact-SQL) e ALTER DATABASE (Transact-SQL).
Nel database di distribuzione è consigliabile impostare l'opzione sync with backup, che ritarda il troncamento del log nel database di pubblicazione finché non viene eseguito il backup delle transazioni corrispondenti nel database di distribuzione. Il risultato potrebbe essere un log delle transazioni di dimensioni maggiori nel database di pubblicazione. Per ulteriori informazioni su questa opzione, vedere Strategie per il backup e il ripristino della replica snapshot e della replica transazionale.
Spazio su disco per il database di distribuzione
Verificare di disporre di spazio su disco sufficiente per archiviare le transazioni replicate nel database di distribuzione.
Se non si rendono i file di snapshot immediatamente disponibili per i Sottoscrittori (impostazione predefinita): le transazioni vengono archiviate finché non sono state replicate in tutti i Sottoscrittori o finché non è trascorso il periodo di memorizzazione, a seconda dell'evento che richiede meno tempo.
Se si crea una pubblicazione transazionale e si rendono i file di snapshot immediatamente disponibili per i Sottoscrittori: le transazioni vengono archiviate finché non sono state replicate in tutti i Sottoscrittori o finché non viene eseguito l'agente snapshot con conseguente creazione di un nuovo snapshot, a seconda dell'evento che richiede più tempo. Se il tempo trascorso tra le esecuzioni dell'agente snapshot è più lungo del periodo di memorizzazione massimo per la distribuzione prima della pubblicazione, che ha un valore predefinito di 72 ore, le transazioni precedenti al periodo di memorizzazione vengono rimosse dal database di distribuzione. Per ulteriori informazioni, vedere Scadenza e disattivazione delle sottoscrizioni.
Sebbene la disponibilità immediata dello snapshot per i Sottoscrittori consenta un accesso più rapido alla pubblicazione da parte dei nuovi Sottoscrittori, questa opzione può richiedere uno spazio di archiviazione su disco maggiore per il database di distribuzione. Viene inoltre generato un nuovo snapshot a ogni esecuzione dell'agente snapshot. Se l'opzione non viene utilizzata, viene generato un nuovo snapshot solo in presenza di una nuova sottoscrizione.
Chiavi primarie per ogni tabella pubblicata
Tutte le tabelle pubblicate nella replica transazionale devono includere una chiave primaria dichiarata. È possibile preparare per la pubblicazione le tabelle esistenti aggiungendo una chiave primaria tramite Transact-SQLl'istruzione ALTER TABLE (Transact-SQL).
Trigger
Valutare i fattori seguenti per l'utilizzo dei trigger in un database di sottoscrizione:
Per impostazione predefinita, i trigger vengono eseguiti con l'opzione XACT_ABORT impostata su ON. Se l'istruzione di un trigger genera un errore mentre l'agente di distribuzione applica le modifiche al Sottoscrittore, l'intero batch di modifiche avrà esito negativo, invece della singola istruzione. In una replica transazionale, è possibile utilizzare il parametro -SkipErrors dell'agente di distribuzione per ignorare le istruzioni che generano errori. Se -SkipErrors viene utilizzato con l'opzione XACT_ABORT impostata su ON, se un'istruzione genera un errore viene ignorato l'intero batch di modifiche. A meno che non sia necessario che l'opzione XACT_ABORT sia impostata su ON nei trigger, è consigliabile impostarla su OFF se si utilizza il parametro -SkipErrors. Per impostare tale opzione su OFF, specificare SET XACT_ABORT OFF nella definizione del trigger. Per ulteriori informazioni su XACT_ABORT, vedere SET XACT_ABORT (Transact-SQL). Per ulteriori informazioni sul parametro -SkipErrors, vedere Errori da ignorare nella replica transazionale.
È consigliabile non includere transazioni esplicite nei trigger del Sottoscrittore. La replica transazionale utilizza i batch di transazioni per ridurre i round trip in rete, migliorando così le prestazioni. Se nel Sottoscrittore vengono aggiunti trigger che includono istruzioni ROLLBACK, i batch di transazioni possono essere annullati e può essere generato l'errore del server 266 (Il numero delle transazioni dopo l'esecuzione di EXECUTE indica che manca un'istruzione COMMIT o ROLLBACK TRANSACTION. Numero di transazioni precedente = %ld, numero di transazioni corrente %ld). Un batch può contenere comandi di più transazioni o fare parte di transazioni su grandi quantità di dati nel server di pubblicazione, per questo il rollback di transazioni può compromettere l'integrità delle transazioni.
Se si includono transazioni esplicite, verificare che tutte le istruzioni COMMIT di un trigger presentino le corrispondenti istruzioni BEGIN TRANSACTION. Un'istruzione COMMIT mancante della corrispondente BEGIN TRANSACTION genera un'applicazione non transazionale delle modifiche di riga del Sottoscrittore. Può inoltre verificarsi un errore in seguito se l'agente di distribuzione rileva l'errore del server 266 e prova ad eseguire il rollback di una transazione o di un batch di comandi in modo da poterli applicare di nuovo. Quando l'agente tenta di applicare comandi che sono già stati applicati, si verificano errori di chiavi duplicate.
Per ulteriori informazioni sui trigger, vedere Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION.
Tipi di dati LOB (Large OBject)
La replica transazionale supporta la pubblicazione di dati LOB ed esegue aggiornamenti parziali sulle colonne LOB: se viene aggiornata una colonna LOB, viene replicato solo il frammento di dati modificati invece di tutti i dati della colonna.
Se una tabella pubblicata include LOB, valutare l'opportunità di utilizzare i seguenti parametri dell'agente di distribuzione: -UseOledbStreaming, -OledbStreamThreshold e -PacketSize. Il metodo più semplice per impostare questi parametri consiste nell'utilizzare il profilo dell'agente di distribuzione Profilo di distribuzione per flussi OLEDB. Per ulteriori informazioni, vedere Profili degli agenti di replica. Oltre a questo profilo predefinito, è possibile specificare il parametro in un profilo di agente creato o modificato oppure nella riga di comando. Per ulteriori informazioni, vedere:
Procedura: Utilizzo dei profili agenti di replica (SQL Server Management Studio)
Procedura: Utilizzo dei profili agenti di replica (programmazione Transact-SQL della replica)
Concetti di base relativi ai file eseguibili dell'agente di replica
Tipi di dati text, ntext e image
Per il processo di replica dei tipi di dati text, ntext e image in una pubblicazione transazionale, è necessario tenere presenti alcuni fattori. È consigliabile utilizzare i tipi di dati varchar(max), nvarchar(max), varbinary(max) invece di utilizzare, rispettivamente, i tipi di dati text, ntext e image.
Se si utilizza text, ntext o image, considerare i seguenti fattori:
Le istruzioni WRITETEXT e UPDATETEXT devono essere incluse nelle transazioni esplicite.
È possibile replicare le operazioni di testo registrate eseguendo le istruzioni WRITETEXT e UPDATETEXT con l'opzione WITH LOG sulle tabelle pubblicate. L'opzione WITH LOG è necessaria perché la replica transazionale registra le modifiche nel log delle transazioni.
È possibile utilizzare le operazioni UPDATETEXT solo se tutti i Sottoscrittori eseguono SQL Server. Le operazioni WRITETEXT vengono replicate come istruzioni UPDATE, in modo che possano essere utilizzate anche con Sottoscrittori non SQL Server.
Il parametro configurabile max text repl size controlla le dimensioni massime (in byte) dei dati di tipo text, ntext, varchar(max), nvarchar(max) e image che è possibile replicare. Ciò consente il supporto dei driver ODBC e dei provider OLE DB, delle istanze di Motore di database di SQL Server che non sono in grado di gestire valori di grandi dimensioni per questi tipi di dati e dei server di distribuzione con numero di risorse di sistema (memoria virtuale) limitate. Se vengono pubblicate colonne con uno di questi tipi di dati ed eseguite operazioni INSERT, UPDATE, WRITETEXT o UPDATETEXT che comportano il superamento del limite massimo configurato, le operazioni hanno esito negativo.
Utilizzare la stored procedure di sistema sp_configure (Transact-SQL) per impostare il parametro max text repl size.
Quando si pubblicano colonne di tipo text, ntext e image, il puntatore di testo deve essere recuperato all'interno della stessa transazione come operazione UPDATETEXT o WRITETEXT (e con ripetibilità di lettura). Non è consigliabile, ad esempio, richiamare il puntatore di testo in una transazione e utilizzarlo successivamente in un'altra transazione, in quanto potrebbe essere stato spostato e non essere più valido.
Dopo avere recuperato il puntatore di testo, prima di eseguire istruzioni UPDATETEXT o WRITETEXT non eseguire operazioni che possono modificare la posizione del testo a cui fa riferimento il puntatore di testo, ad esempio l'operazione di aggiornamento della chiave primaria.
Di seguito viene riportata la procedura consigliata per la replica dei dati tramite le operazioni UPDATETEXT e WRITETEXT:
Avviare la transazione.
Recuperare il puntatore di testo utilizzando la funzione TEXTPTR() con livello di isolamento REPEATABLE READ.
Utilizzare il puntatore di testo nell'operazione UPDATETEXT o WRITETEXT.
Eseguire il commit della transazione.
[!NOTA]
Se il puntatore non viene recuperato nella stessa transazione, le modifiche sono consentite nel server di pubblicazione ma non vengono pubblicate nei Sottoscrittori.
Ad esempio:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRAN DECLARE @mytextptr varbinary(16) SELECT @mytextptr = textptr(Notes) FROM Employees WHERE EmployeeID = '7' IF @mytextptr IS NOT NULL BEGIN UPDATETEXT Employees.Notes @mytextptr 0 NULL 'Terrific job this review period.' -- Dummy update to fire trigger that will update metadata and ensure the update gets propagated to other Subscribers. UPDATE Employees -- Set value equal to itself. SET Notes = Notes WHERE EmployeeID = '7' END COMMIT TRAN SET TRANSACTION ISOLATION LEVEL READ COMMITTED
[!NOTA]
Questo esempio è basato sul database Northwind, che non viene installato per impostazione predefinita. Per informazioni sull'installazione di questo database, vedere Northwind and pubs Sample Databases (informazioni in lingua inglese) nell'Area download Microsoft.
Quando si ridimensionano i database dei Sottoscrittori, tenere presente che il puntatore di testo per le colonne di tipo text, ntext e image replicate deve essere inizializzato sulle tabelle dei Sottoscrittori, anche quando le colonne non sono inizializzate nel server di pubblicazione. Ogni colonna di tipo text, ntext e image aggiunta alla tabella del Sottoscrittore tramite l'attività di distribuzione occupa pertanto almeno 43 byte di spazio del database, anche se non include alcun contenuto.