SQL Server - отдельная база данных для отчетов?

На нашем SQL Server у нас есть база данных для каждого из наших веб-приложений. Для отчетов мы используем службы отчетов, и все данные отчетов (включая параметры отчетов) поступают из хранимых процедур.

Хранимые процедуры находятся в той же базе данных, что и данные в отчете. Так, например, процы, обслуживающие отчеты о запасах, находятся в базе данных запасов. В некоторых отчетах показывается информация из более чем одной базы данных, и тогда процесс будет находиться в одной из этих исходных баз данных. Параметры отчета получают свои данные из процедур в базе данных Enterprise, в которой есть такие данные, как магазины, сотрудники и т. Д.

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

У меня вопрос: есть ли преимущество перемещения отчетов в отдельную базу данных «Отчеты» . Я знаю преимущества переноса отчетов на другой сервер, и я не говорю об этом - это будет на том же сервере.

Вещи, которые могут повлиять на это:

• Влияет ли наличие более одного подключения к базе данных для отчета, влияет на скорость отчета?
• Помешает ли нам создание отчета в отдельной базе данных из данных, чтобы мы не использовали индексированные представления?
• Вам было легче / сложнее управлять вашими отчетами в отдельной базе данных?

Пожалуйста, дай мне знать, что ты думаешь.

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

1. Скопируйте вашу базу данных на другой сервер и перенесите на нее спрогнозированные отчеты. Отчеты запускаются с реплицированного сервера. Это наименьшее усилие и может повторно использовать ваши существующие отчеты и хранимые процедуры.
2. Создайте хранилище данных, которое объединяет данные из ваших производственных систем и преобразует их в форму, удобную для отчетности . Если у вас есть много специальных статистических отчетов, которые можно было бы сделать приемлемо из моментального снимка «вчерашнего закрытия бизнеса», хранилище данных может быть лучшим подходом.

Я думаю, что многое зависит от того, какой SP вы используете. Если они тяжелые и могут влиять на другие вещи, работающие на сервере базы данных, я бы их переместил. В противном случае я бы постарался сохранить близость к базе данных, о которой они на самом деле сообщают, если бы мне было намного проще поддерживать и отслеживать. Простое размещение отчета близко к фактической базе данных также может повлиять на производительность, но если вы используете стандартную настройку и не перемещаете огромный объем данных, я думаю, это будет крошечной разницей.

Я также нашел эту статью полезной.

Я бы не рекомендовал переносить хранимые процедуры в другую базу данных по нескольким причинам. С точки зрения разработки вы должны воспроизводить две базы данных каждый раз, когда вы хотите внести изменения. Как следствие, теперь вы узнаете, как синхронизировать схему из базы данных «data» и хранимые процедуры из второй с производственными версиями. Что касается аварийного восстановления и резервного копирования / восстановления, теперь вам нужно заняться восстановлением 2 баз данных только для того, чтобы ваша система работала.

При тестировании вы также добавили сложности. У вас будет больше точек сбоев в отношении разрешений, версий и т. Д. Теперь, если у вас есть более 1 человека, работающего над различными инициативами в базах данных, у вас будет больше времени для координации усилий. Теперь представьте, что сейчас 3 часа ночи, система не работает, и вам нужно найти разрешения для всех баз данных и убедиться, что никто не оставил функцию или процедуру в неправильной базе данных во время разработки.

Я бы порекомендовал вам использовать две базы данных.

Получение отчетов из «живой» базы данных вызывает проблемы с производительностью.

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

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