I / O đĩa tempdb cao trong quá trình sao chép BLOB hợp nhất

Có một ấn phẩm hợp nhất để sao chép BLOB (loại image), có I / O đĩa tempdb rất cao cho kích thước dữ liệu của tôi. Ấn phẩm chỉ tải về và không có bộ lọc.

I / O đĩa cao là do đồng bộ hóa (khi không có người đăng ký nào được đồng bộ hóa, mọi thứ đều ổn), tương quan mạnh với số lượng người đăng ký. Nó xảy ra ngay cả khi không có dữ liệu nào được thay đổi tại Nhà xuất bản giữa các lần đồng bộ hóa và điều đó làm phiền tôi.

• Kích thước của bảng được nhân rộng: 7MB (tổng số hàng khoảng 100)
• tempdb I / O: ~ 30 MB / giây để ghi (tệp nhật ký và dữ liệu)
• Số lượng người đăng ký: hơn 100 người, mỗi người đồng bộ hóa cứ sau 30 phút (nhiều hơn hoặc ít hơn).
• Thời gian lưu giữ được đặt thành 14 ngày

Sử dụng SQL Server 2008 tại Publisher, SQL Server 2005-2008R2 tại các thuê bao. Tất cả các thuê bao sử dụng đồng bộ hóa Web.

Ngoài ra, đồng bộ hóa tại thuê bao mất rất nhiều thời gian, với nhiều lần xuất hiện replmerg.lognhư sau:

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

Đã thử cài đặt @stream_blob_columnsbật và tắt mà không có hiệu lực.

Câu hỏi là: Có nên sử dụng bản sao hợp nhất để gửi các đốm màu này đến người đăng ký không? Chúng tôi có các ấn phẩm khác (mặc dù chúng không có cột BLOB) với nhiều dữ liệu mà không gặp sự cố tempdb. Đây có phải là một lỗ hổng SQL Server hay thiết lập xấu?

Nhà xuất bản và Nhà phân phối cùng một phiên bản, SQL Server 2008 SP4, không thể chắc chắn về Người đăng ký, một số trong số họ có thể không cập nhật. Dù sao, tôi có thể chuẩn bị một môi trường thử nghiệm với một vài người đăng ký có các phiên bản được kiểm soát, nếu nó có vẻ hữu ích.

Xác nhận rằng việc sử dụng tempdb quá mức gây ra bởi việc thực thi sys.sp_MSenumgenerations90. Đã kiểm tra MSMerge_genhistorybảng, tìm thấy hơn 1,2 triệu hồ sơ không có pubidgiá trị.

Tìm thấy cuộc trò chuyện này với Guru nhân rộng:

Thực hiện sp_mergemetadataretentioncleanupkhông có hiệu lực.

Đã tìm thấy một nhận xét về trường hợp như thế này (quá nhiều hàng trong MSmerge_genhistory) trong đó xóa các hàng trong đó pubidnull và genstatus= 1 đã giúp sửa lỗi sao chép.

Các hàng đã bị xóa trong đó pubidlà null (ngụ ý rằng tất cả các thuê bao được đồng bộ hóa và không - sẽ được khởi tạo lại trong "chế độ thủ công") và IO đĩa trở lại bình thường!

Tôi có cảm giác rằng tình huống này có thể được gây ra bởi thực tế là tất cả những Người đăng ký của tôi đều ẩn danh qua WebSync và hầu hết trong số họ có cùng tên máy chủ. Tôi sẽ cố gắng kiểm tra, nếu -hostnamekhóa giúp không nhân bản ghi vào MSmerge_genhistory.

Có một blog TechNet thảo luận về một số vấn đề sao chép hợp nhất với các đốm màu trên máy chủ SQL Server 2008 hoặc cao hơn.

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

Lưu ý rằng tác giả cảnh báo về việc sử dụng cài đặt nào khi có máy khách SQL Server 2005, chẳng hạn như bạn có.

Tôi gặp vấn đề tương tự với máy chủ của khách hàng mà không thể giải quyết được. Lượng IO cao làm chậm việc lưu trữ và ảnh hưởng đến một số hệ thống. Tôi không thể cung cấp giải pháp để tự giải quyết nguyên nhân, nhưng nó có thể là một tùy chọn (tạm thời) giải quyết vấn đề kết quả và cho bạn thêm thời gian để xác định và giải quyết nguyên nhân.

Chúng tôi đã giải quyết vấn đề IO trong khi di chuyển tempdb sang ramdisk. Trong trường hợp của chúng tôi, chúng tôi đã phải hành động nhanh chóng, vì các hệ thống khác trở nên không đáp ứng tạm thời do vấn đề hiệu suất. Thay vì thay đổi cài đặt máy chủ, chúng tôi đã sao chép các tệp tempdb vào ramdisk, tạo bản sao lưu của các tệp gốc và thay thế chúng bằng các liên kết tượng trưng. Ramdisk tải một hình ảnh có chứa các tệp tempdb. Các dịch vụ sql đã bị trì hoãn để đảm bảo ramdisk đã bắt đầu và tải hình ảnh trước khi dịch vụ sql bắt đầu. Thời gian chết hiệu quả để chuyển từ đĩa sang ram mất ít hơn một phút.

Trong trường hợp của chúng tôi, chúng tôi đã cải thiện hiệu suất một cách ồ ạt và giải quyết vấn đề với bộ lưu trữ. Giải pháp này hoạt động rất tốt cho khách hàng của chúng tôi và cuối cùng nó đã trở thành một giải pháp lâu dài.

Brent được xác định lý do tại sao chúng ta cần tăng tệp dữ liệu tempDb. Bạn có thể tham khảo liên kết bên dưới

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