Отдельные таблицы / базы данных для отчетов и операций CRUD

Question

Периодически пользователи, запускающие отчеты, блокируют пользователей, выполняющих операции CRUD, и вызывают тайм-ауты. Я хочу создать дубликаты местоположений текущих таблиц для пользователей отчета.

Я думал о создании задания, которое создает резервную копию базы данных моего приложения и восстанавливает ее в базе данных отчетов на том же сервере, чтобы пользователи, выполняющие отчеты, были отделены от пользователей, выполняющих операции CRUD. Работа будет выполняться каждые 10 минут или около того. Начальные тесты показывают, что начало до конца будет около 30 секунд. Дисковое пространство не является проблемой.

Это хорошая / плохая идея? Какие подводные камни я должен остерегаться? Есть ли лучший способ сделать это?

Answer 1

Звучит как хорошая идея. Единственное, что меня беспокоит, это то, что вам нужно обновлять каждые 10 минут? Это также может замедлить работу во время работы обновления. Обычно это делается в одночасье (чтобы оказать наименьшее влияние на окружающих) или, если в течение дня, только в 3 фиксированных точках (скажем, в 10:00, 13:00 и 16:00).

Answer 2

Перед обновлением погрузчика вы можете увидеть, если поставить

...from sometable WITH (NOLOCK)

в ваших отчетных запросах смягчает проблему. Это может по крайней мере выиграть у вас время, чтобы выяснить, что является оптимальным.

Answer 3

Будьте осторожны с частым резервным копированием - это может привести к значительному простою!

Общие решения

Действительно, обычной практикой является создание отдельного экземпляра только для отчетов.

Некоторые люди даже идут дальше и размещают отчеты на отдельном физическом компьютере или кластере, чтобы дополнительно изолировать эту часть нагрузки.

Обе они могут быть обработаны с помощью replication (что позволяет избежать проблемы простоя). Или вы можете просто сделать ночное резервное копирование и сообщить об этом.

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

Заключительные мысли

И последнее: я видел, как некоторые магазины на пороге этой проблемы пытались избежать решения этой проблемы. Вот один из выводов: отчеты имеют тенденцию к всплеску в определенное время месяца или года, поэтому, если вы обычно находитесь на грани убийства сервера базы данных, последняя неделя месяца может оттолкнуть вас от края !

Этот вопрос очень похож: https://stackoverflow.com/questions/190512/sql-server-separate-database-for-reports

Answer 4

Естественно, что для большинства приложений корпоративного класса база данных транзакций всегда хранится отдельно от базы данных отчетов. Система транзакций настроена для OLTP, и база данных отчетов может быть денормализована в соответствии с потребностями сценариев отчетности. Так что это почти естественное предложение.