Avere una pubblicazione di tipo merge per replicare BLOB (tipo image), ha ottenuto I / O su disco tempdb molto elevato per la mia dimensione di dati. La pubblicazione è solo per il download e non ha filtri.
L'I / O su disco elevato è causato dalla sincronizzazione (quando nessun abbonato si sta sincronizzando, tutto è ok), fortemente correlato al numero di abbonati. Succede anche quando nessun dato viene modificato su Publisher tra le sincronizzazioni e questo mi disturba.
- Dimensione della tabella replicata: 7 MB (il conteggio totale delle righe è di circa 100)
- I / O tempdb: ~ 30 MB / sec per scrittura (file di registro e dati)
- Numero di abbonati: poco più di 100, ciascuno sincronizzato ogni 30 minuti (più o meno uniformemente).
- Periodo di conservazione impostato su 14 giorni
Utilizzando SQL Server 2008 presso Publisher, SQL Server 2005-2008R2 presso gli abbonati. Tutti gli abbonati utilizzano la sincronizzazione Web.
Inoltre, la sincronizzazione presso l'abbonato richiede molto tempo, con più occorrenze replmerg.logcome queste:
DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088, S2, INFO: [WEBSYNC_PROTOCOL] Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194, S2, INFO: [WEBSYNC_PROTOCOL] Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload
Ho provato ad accendere @stream_blob_columnse spegnere senza alcun effetto.
La domanda è: è una buona idea utilizzare la replica di tipo merge per inviare questi BLOB agli abbonati? Abbiamo altre pubblicazioni (anche se non hanno colonne BLOB) con molti dati senza problemi tempdb. È un difetto di SQL Server o un'installazione errata?
Publisher e distributore si trovano nella stessa istanza, SQL Server 2008 SP4, non possono essere sicuri degli abbonati, alcuni dei quali potrebbero non essere aggiornati. Ad ogni modo, posso preparare un ambiente di test con pochi abbonati che hanno versioni controllate, se sembra aiutare.
Confermato, l'utilizzo eccessivo di tempdb causato dall'esecuzione di sys.sp_MSenumgenerations90. MSMerge_genhistoryTabella controllata , trovata oltre 1,2 milioni di record in cui pubidè null.
Ho trovato questa conversazione con il guru della replica:
Eseguito sp_mergemetadataretentioncleanupsenza effetto.
Ho trovato un'osservazione su un caso come questo (troppe righe in MSmerge_genhistory) in cui l'eliminazione delle righe in cui pubidè null e genstatus= 1 ha contribuito a correggere la replica.
Le righe eliminate dove pubidsono nulle (il che implica che tutti i Sottoscrittori sono sincronizzati e che non lo sono - verranno reinizializzate in "modalità manuale") e l'IO del disco tornerà alla normalità!
Ho la sensazione che questa situazione potrebbe essere causata dal fatto che tutti i miei abbonati sono anonimi tramite WebSync e molti di loro hanno lo stesso nome host. Proverò a controllare, se la -hostnamechiave aiuta a non moltiplicare i record MSmerge_genhistory.