Ошибка производительности репликации базы данных SQL Server 2012

Question

Мы настроили репликацию транзакций базы данных SQL Server 2012 для веб-приложения .NET нашего клиента для распространения транзакций SQL и отчетов на разных SQL-серверах.

Мы реализовали репликацию транзакций на SQL-Node1, работая как главный сервер базы данных. Мы сконфигурировали репликацию главной базы данных SQL-Node2, чтобы вывести отчеты в наше веб-приложение, которое имеет множество транзакций и загрузку данных от статей с большим количеством записей около 10 миллионов записей в день.

После настройки репликации на двух экземплярах SQL Server 2012 через несколько недель мы столкнулись с некоторыми проблемами производительности и обнаружили, что какой-то ресурс блокируется при загрузке файлов в базу данных, поэтому приложение не может получить доступ к этим таблицам и данным. Также выяснилось, что сервер работает слишком медленно в дневное время, когда пользователи обращаются к нашему веб-приложению.

Теперь мы планируем распространять нагрузки на различные 3 узла SQL Server 2012. Где веб-приложение будет получать доступ и транслировать данные в SQL-Node1, запросы отчетов будут извлекать данные из SQL-Node2, а SQL-Node3 будет использоваться для загрузки данных Excel в базу данных, которая будет реплицироваться на всех других узлах SQL.

Текущая настройка, все серверы с Windows Server 2008 Standard и SQL Server 2012 Enterprise Edition.

размер около

базы данных: 15 Гб/Replication используется: Транзакция/Распространитель роль настроена на SQL NODE1/роли подписчика настроена на SQL Node 2.

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

Какая функция будет хорошо работать для вышеуказанного сценария среди SQL Server 2012 HA, репликации SQL Server или зеркалирования SQL Server?

Быстрый ответ будет высоко оценен ....

Answer 1

Потому что у вас есть изменения происходят в более чем одном узле (транзакционных данных на узле 1, первенствует загрузки на узле 3), «ни один из вышеперечисленных». Все вышеупомянутые технологии основаны на изменении данных в одном месте и распространении на другие. Вы могли бы посмотреть на репликацию сверстников, но это кажется излишним.

Если бы это был я, я попытался бы диагностировать, почему ваш процесс загрузки файлов убивает производительность и исправляет/работает вокруг этого. Как только вы это сделаете, я перенесет этот процесс на узел 1 и внедряю группу доступности для покрытия ваших потребностей в отчетах (с добавленным бонусом HA).

Answer 2

Все технологии будут падать на большой импорт данных, который выполняется в одной крупной транзакции. Я предлагаю сделать это как функцию ETL. Импортируйте в промежуточную таблицу и перенесите данные в производственную таблицу в куски размером с укусом (проверьте множество размеров строк данных, чтобы найти размер, который наилучшим образом подходит для вашей среды). 2 сервера должны быть в порядке с репликацией на кластере для HA с рабочими нагрузками, о которых вы говорите.