Имея публикацию слиянием для репликации 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.
У меня была похожая проблема с клиентским сервером, причина которой не могла быть решена. Большое количество операций ввода-вывода замедлило хранение и затронуло несколько систем. Я не могу предоставить решение для устранения самой причины, но это может быть (временный) вариант, который решает возникающую проблему и дает вам больше времени для выявления и устранения причины.
Мы решили проблему ввода-вывода при перемещении tempdb на виртуальный диск. В нашем случае мы должны были действовать быстро, так как другие системы временно перестали отвечать из-за проблем с производительностью. Вместо того, чтобы изменить настройки сервера, мы скопировали файлы tempdb на виртуальный диск, создали резервную копию исходных файлов и заменили их символическими ссылками. RAM-диск загружает изображение, которое содержит tempdb-файлы. Sql-сервисы были отложены, чтобы убедиться, что ramdisk запустился и загрузил образ до запуска sql-сервиса. Эффективное время простоя для переключения с диска на оперативную память заняло менее минуты.
В нашем случае мы значительно повысили производительность и решили проблему с хранилищем. Решение очень хорошо работает для нашего клиента, и в конце концов оно стало постоянным решением.
источник
Брент определяет, почему нам нужно увеличить файл данных tempDb. Вы можете обратиться по ссылке ниже
https://www.brentozar.com/blitz/tempdb-data-files/
источник