I / O disk tempdb tinggi selama menggabungkan replikasi BLOB

Memiliki publikasi gabungan untuk mereplikasi BLOB (tipe image), mendapat I / O disk tempdb yang sangat tinggi untuk ukuran data saya. Publikasi hanya dapat diunduh dan tidak memiliki filter.

Disk I / O yang tinggi disebabkan oleh sinkronisasi (ketika tidak ada pelanggan yang melakukan sinkronisasi, semuanya baik-baik saja), sangat berkorelasi dengan jumlah pelanggan. Itu terjadi bahkan ketika tidak ada data yang diubah di Publisher di antara sinkronisasi, dan itu mengganggu saya.

• Ukuran tabel yang direplikasi: 7MB (jumlah total baris sekitar 100)
• tempdb I / O: ~ 30 MB / detik untuk menulis (file log dan data)
• Jumlah pelanggan: sedikit di atas 100, masing-masing menyinkronkan setiap 30 menit (lebih atau kurang merata).
• Periode retensi diatur ke 14 hari

Menggunakan SQL Server 2008 di Penerbit, SQL Server 2005-2008R2 di Pelanggan. Semua pelanggan menggunakan Sinkronisasi Web.

Selain itu, sinkronisasi di pelanggan membutuhkan banyak waktu, dengan beberapa kejadian replmerg.logseperti ini:

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

Mencoba @stream_blob_columnsmenghidupkan dan mematikan tanpa efek.

The Pertanyaan adalah: Apakah itu ide yang baik untuk replikasi penggunaan gabungan untuk mengirim gumpalan ini untuk pelanggan? Kami memiliki publikasi lain (meskipun mereka tidak memiliki kolom BLOB) dengan banyak data tanpa masalah tempdb. Apakah ini kesalahan SQL Server, atau pengaturan yang buruk?

Penerbit dan Distributor berada pada contoh yang sama, SQL Server 2008 SP4, tidak dapat memastikan tentang Pelanggan, beberapa dari mereka mungkin tidak mutakhir. Lagi pula, saya dapat menyiapkan lingkungan pengujian dengan beberapa pelanggan yang memiliki versi terkontrol, jika tampaknya membantu.

Dikonfirmasi, bahwa penggunaan tempdb berlebihan disebabkan oleh eksekusi sys.sp_MSenumgenerations90. Diperiksa MSMerge_genhistorytabel, ditemukan lebih dari 1,2 juta catatan di mana pubidadalah nol.

Menemukan percakapan ini dengan guru replikasi:

Dieksekusi sp_mergemetadataretentioncleanuptanpa efek.

Ditemukan komentar pada kasus seperti ini (terlalu banyak baris MSmerge_genhistory) di mana menghapus baris di mana pubidnol dan genstatus= 1 membantu memperbaiki replikasi.

Baris yang dihapus di mana pubidadalah nol (menyiratkan bahwa semua Pelanggan disinkronkan, dan yang tidak - akan diinisialisasi ulang dalam "mode manual") dan disk IO kembali normal lagi!

Saya mempunyai perasaan, bahwa situasi ini dapat disebabkan oleh fakta, bahwa semua Pelanggan saya anonim melalui WebSync dan kebanyakan dari mereka memiliki nama host yang sama. Saya akan mencoba memeriksa, jika -hostnamekunci membantu untuk tidak menggandakan catatan MSmerge_genhistory.

Ada blog TechNet yang membahas beberapa masalah replikasi gabungan dengan gumpalan pada SQL Server 2008 atau server yang lebih tinggi.

http://blogs.technet.com/b/claudia_silva/archive/2011/10/31/replication-watch-out-for-stream-blob-columns-when-setting-up-up-replication-on-your-sql- 2008-server.aspx

Perhatikan bahwa penulis memperingatkan tentang pengaturan mana yang harus digunakan ketika ada klien SQL Server 2005, seperti yang Anda miliki.

Saya punya masalah yang sama dengan server pelanggan yang menyebabkan tidak dapat diselesaikan. Jumlah IO yang tinggi memperlambat penyimpanan dan memengaruhi beberapa sistem. Saya tidak dapat memberikan solusi untuk menyelesaikan penyebabnya sendiri, tetapi mungkin opsi (sementara) yang memecahkan masalah yang dihasilkan dan memberi Anda lebih banyak waktu untuk mengidentifikasi dan menyelesaikan penyebabnya.

Kami telah memecahkan masalah-IO sambil memindahkan tempdb ke ramdisk. Dalam kasus kami, kami harus bertindak cepat, karena sistem lain menjadi tidak responsif karena masalah kinerja sementara. Alih-alih mengubah pengaturan server, kami menyalin file tempdb ke ramdisk, membuat cadangan dari file asli dan menggantinya dengan symlink. Ramdisk memuat gambar yang berisi file-file tempdb. Layanan sql telah ditunda untuk memastikan ramdisk telah memulai dan memuat gambar sebelum layanan sql dimulai. Downtime yang efektif untuk beralih dari disk ke ram memakan waktu kurang dari satu menit.

Dalam kasus kami, kami meningkatkan kinerja secara besar-besaran dan menyelesaikan masalah dengan penyimpanan. Solusi ini bekerja sangat baik untuk pelanggan kami dan pada akhirnya itu menjadi solusi permanen.

Brent menentukan mengapa kita perlu menambah file data tempDb. Anda dapat merujuk tautan di bawah ini

https://www.brentozar.com/blitz/tempdb-data-files/