На нашем SQL Server у нас есть база данных для каждого из наших веб-приложений. Для отчетов мы используем службы отчетов, и все данные отчетов (включая параметры отчетов) поступают из хранимых процедур.
Хранимые процедуры находятся в той же базе данных, что и данные в отчете. Так, например, процы, обслуживающие отчеты о запасах, находятся в базе данных запасов. В некоторых отчетах показывается информация из более чем одной базы данных, и тогда процесс будет находиться в одной из этих исходных баз данных. Параметры отчета получают свои данные из процедур в базе данных Enterprise, в которой есть такие данные, как магазины, сотрудники и т. Д.
Это означает, что все отчеты имеют как минимум соединение с базой данных Enterprise и другое соединение с другой базой данных, а иногда и больше.
У меня вопрос: есть ли преимущество перемещения отчетов в отдельную базу данных «Отчеты» . Я знаю преимущества переноса отчетов на другой сервер, и я не говорю об этом - это будет на том же сервере.
Вещи, которые могут повлиять на это:
- Влияет ли наличие более одного подключения к базе данных для отчета, влияет на скорость отчета?
- Помешает ли нам создание отчета в отдельной базе данных из данных, чтобы мы не использовали индексированные представления?
- Вам было легче / сложнее управлять вашими отчетами в отдельной базе данных?
Пожалуйста, дай мне знать, что ты думаешь.
источник
Ответы:
Ответ: да, это выгодно. Отчеты по оперативной базе данных будут использовать много ресурсов и будут влиять на производительность операционной системы. Помните, что производительность базы данных подвержена механическим ограничениям (перемещение головок дисков назад и вперед и задержка вращения, пока мы ожидаем появления правого сектора под головкой). У вас есть два широких варианта стратегии отчетности:
источник
Я думаю, что многое зависит от того, какой SP вы используете. Если они тяжелые и могут влиять на другие вещи, работающие на сервере базы данных, я бы их переместил. В противном случае я бы постарался сохранить близость к базе данных, о которой они на самом деле сообщают, если бы мне было намного проще поддерживать и отслеживать. Простое размещение отчета близко к фактической базе данных также может повлиять на производительность, но если вы используете стандартную настройку и не перемещаете огромный объем данных, я думаю, это будет крошечной разницей.
Я также нашел эту статью полезной.
источник
Я бы не рекомендовал переносить хранимые процедуры в другую базу данных по нескольким причинам. С точки зрения разработки вы должны воспроизводить две базы данных каждый раз, когда вы хотите внести изменения. Как следствие, теперь вы узнаете, как синхронизировать схему из базы данных «data» и хранимые процедуры из второй с производственными версиями. Что касается аварийного восстановления и резервного копирования / восстановления, теперь вам нужно заняться восстановлением 2 баз данных только для того, чтобы ваша система работала.
При тестировании вы также добавили сложности. У вас будет больше точек сбоев в отношении разрешений, версий и т. Д. Теперь, если у вас есть более 1 человека, работающего над различными инициативами в базах данных, у вас будет больше времени для координации усилий. Теперь представьте, что сейчас 3 часа ночи, система не работает, и вам нужно найти разрешения для всех баз данных и убедиться, что никто не оставил функцию или процедуру в неправильной базе данных во время разработки.
источник
Я бы порекомендовал вам использовать две базы данных.
Получение отчетов из «живой» базы данных вызывает проблемы с производительностью.
Кроме того, поскольку база данных отчетов в основном предназначена для поиска, вы можете настроить индексы для повышения производительности. (Реальная база данных будет иметь вставки, которые будут отрицательно влиять на определенные индексы)
источник
Другой подход - перенести таблицы отчетов в отдельную схему и в отдельную файловую группу. Файлы в файловой группе отчетов могут быть удалены с жестких дисков с данными. Это гораздо проще для администрирования, будущего развития и управления доступом.
источник