Дисковый ввод-вывод с высокой скоростью базы данных во время репликации слиянием больших двоичных объектов

Имея публикацию слиянием для репликации BLOB (тип image), я получил очень высокий дисковый ввод-вывод tempdb для моего размера данных. Публикация доступна только для скачивания и не имеет фильтров.

Высокий дисковый ввод-вывод вызван синхронизацией (когда никакие подписчики не синхронизируются, все в порядке), сильно коррелирует с количеством подписчиков. Это происходит даже тогда, когда в Publisher не меняются данные между синхронизациями, и это беспокоит меня.

• Размер реплицируемой таблицы: 7 МБ (общее количество строк составляет около 100)
• Id / tempdb: ~ 30 МБ / с для записи (файлы журнала и данных)
• Количество подписчиков: чуть более 100, каждый из которых синхронизируется каждые 30 минут (более или менее равномерно).
• Срок хранения установлен в 14 дней

Использование SQL Server 2008 на издателе, SQL Server 2005-2008R2 на подписчиках. Все подписчики используют веб-синхронизацию.

Кроме того, синхронизация на подписчике занимает много времени, с множеством случаев, replmerg.logнапример:

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

Пробовал устанавливать @stream_blob_columnsи выключать без эффекта.

Вопрос : является ли это хорошая идея репликации использование слияния , чтобы отправить эти сгустки абонентам? У нас есть другие публикации (хотя у них нет BLOB-столбцов) с большим количеством данных без проблем с tempdb. Это недостаток SQL Server или плохая настройка?

Издатель и распространитель находятся в одном экземпляре, SQL Server 2008 с пакетом обновления 4 (SP4), не могут быть уверены в подписчиках, некоторые из них, возможно, не обновлены. В любом случае, я могу подготовить тестовую среду с несколькими подписчиками, у которых есть контролируемые версии, если это кажется полезным.

Подтверждено, что чрезмерное использование базы данных tempdb вызвано выполнением sys.sp_MSenumgenerations90. Проверил MSMerge_genhistoryтаблицу, нашел более 1,2 миллиона записей, где pubidноль.

Нашел этот разговор с репликацией гуру:

Выполнено sp_mergemetadataretentioncleanupбез эффекта.

Нашел замечание по такому случаю (слишком много строк в MSmerge_genhistory), где удаление строк с pubidнулевым значением и genstatus= 1 помогло исправить репликацию.

Удаленные строки с pubidнулевым значением (подразумевается, что все подписчики синхронизированы, а которые нет - будут повторно инициализированы в «ручном режиме»), и дисковый ввод-вывод снова вернулся в нормальное состояние!

У меня есть ощущение, что эта ситуация может быть вызвана тем фактом, что все мои подписчики являются анонимными через WebSync, и большинство из них имеют одинаковое имя хоста. Я постараюсь проверить, -hostnameпомогает ли ключ не умножать записи в MSmerge_genhistory.

В блоге TechNet обсуждаются некоторые проблемы репликации слиянием с BLOB-объектами на сервере SQL Server 2008 или более поздней версии.

http://blogs.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

Обратите внимание, что автор предупреждает о том, какие параметры использовать при наличии таких клиентов SQL Server 2005, как у вас.

У меня была похожая проблема с клиентским сервером, причина которой не могла быть решена. Большое количество операций ввода-вывода замедлило хранение и затронуло несколько систем. Я не могу предоставить решение для устранения самой причины, но это может быть (временный) вариант, который решает возникающую проблему и дает вам больше времени для выявления и устранения причины.

Мы решили проблему ввода-вывода при перемещении tempdb на виртуальный диск. В нашем случае мы должны были действовать быстро, так как другие системы временно перестали отвечать из-за проблем с производительностью. Вместо того, чтобы изменить настройки сервера, мы скопировали файлы tempdb на виртуальный диск, создали резервную копию исходных файлов и заменили их символическими ссылками. RAM-диск загружает изображение, которое содержит tempdb-файлы. Sql-сервисы были отложены, чтобы убедиться, что ramdisk запустился и загрузил образ до запуска sql-сервиса. Эффективное время простоя для переключения с диска на оперативную память заняло менее минуты.

В нашем случае мы значительно повысили производительность и решили проблему с хранилищем. Решение очень хорошо работает для нашего клиента, и в конце концов оно стало постоянным решением.

Брент определяет, почему нам нужно увеличить файл данных tempDb. Вы можете обратиться по ссылке ниже

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