Отдельная база данных для отчетов SQL Server
Я исследовал это здесь (и другие сайты) довольно немного. Я чувствую, что упускаю что-то простое. Поэтому, пожалуйста, направьте меня на другую публикацию или помогите ответить на мой вопрос.
По сути, мы расширили наш текущий сервер баз данных. Основная проблема - высокая загрузка ЦП из-за плохо написанных отчетов поверх плохо спроектированной реляционной базы данных. Другая проблема связана с использованием ввода-вывода для обеих рабочих нагрузок. Пользователи сталкиваются с блокировками и проблемами при попытке сохранить их в системе во время высокой загрузки и когда отчеты указывают на один и тот же сервер. Индексирование и обслуживание выполняется часто. Существует небольшая фрагментация в индексах, которая может привести к увеличению ввода-вывода или ЦП. Блокировка (с помощью отчетов) была сведена к минимуму, однако другие запросы все еще должны получать блокировки для поддержания соответствия.
Я вынужден отделить от него две основные рабочие нагрузки... Что, между прочим, должно произойти в любом случае, поскольку одна из них - рабочая нагрузка OLTP, а другая - рабочая нагрузка создания отчетов с использованием SSRS.
Вот три основных варианта, которые я пытался создать отдельную базу данных отчетов, а также причины, по которым каждый из них не будет работать.
Вещи уже пробовали:
Полная копия базы данных - это то, что мы делаем, но это медленно, и наши отчеты будут иметь данные за 12 часов. Это не соответствует нашим бизнес-требованиям или ожиданиям конечного пользователя.
Доставка журналов - я пытался реализовать это, но мы потеряли 15-минутную опцию восстановления для наших резервных копий (Data Protection Manager). Возможность восстановления базы данных с 15-минутным приращением казалась более важной, чем наличие отдельной базы данных отчетов. Это обоснованное замечание моего руководителя, хотя оно становится все более серьезной из-за проблем, с которыми пользователи сталкиваются на стороне системы OLTP. Другая проблема с доставкой журналов заключается в том, что сервер отчетов не работает, пока восстановление происходит в базе данных отчетов.
3. Репликация - Транзакционная репликация является рекомендуемым решением Microsoft. Это сохранит наши 15-минутные резервные копии, а также предоставит нам практически живые данные отчетов. Из-за некоторого кода, который они используют в нашей системе медицинских карт, он не совместим с репликацией. Интенсивное использование усечения (не поддерживается репликацией), а также возможности (сомнительной), позволяющей конечным пользователям создавать новые столбцы базы данных (изменения в схеме) через веб-интерфейс.
Любая помощь там? Спасибо.
1 ответ
Поскольку у меня, похоже, нет возможности отвечать на опубликованные ответы, я собираюсь ответить таким образом. Извините за путаницу.
Марк Хендерсон: Да, я немного оптимизировал эти запросы. К сожалению, я могу сделать так много, чтобы они работали лучше. Отчасти это связано с кодом сторонней системы медицинских записей... Отчасти это связано с нехваткой ресурсов, которые мне дают для сервера, чтобы адекватно обрабатывать обе рабочие нагрузки. Индексирование стоит проверить снова, хотя я сделал это немного, я продолжу исследовать.
CMcKeown: я недавно читал больше о зеркалировании. Предупреждение с этим, похоже, похоже на доставку бревен. Пока происходит моментальный снимок, база данных отчетов будет отключена, а пользователи будут отключены. Зеркальное отображение, насколько я понимаю, также потребует наличия группы доступности, которая может потребовать внесения изменений в приложение медицинской документации, которое мне, возможно, не дадут реализовать.
Дэрин Стрейт: Да, у меня есть сценарии, которые только дефрагментируют или перестраивают индексы, которые фрагментированы только для определенного процента. Это было необходимо из-за объема роста в базе данных. Индексы в обновляемых таблицах часто фрагментируются быстрее, чем другие индексы... Поэтому необходимо было обрабатывать их отдельно. У нас было несколько обсуждений по поводу задержки в данных отчетности. Сначала до 24 часов было хорошо, потом мы получили некоторую отдачу от пользователей, теперь многие отчеты, по-видимому, должны иметь почти живые данные. Я пытаюсь выдвинуть на час или полчаса окна в этой точке. Часть проблемы удовлетворяет всех, и, если я не могу, то делаю нужных людей настолько счастливыми, насколько это возможно. Я не знаю, почему я не рассматривал возможность использования резервных копий журналов, отправленных в DPM, для заполнения базы данных отчетов. Если не рассматривать это на самом деле, то проблемы с доставкой журналов могут показаться такими же: база данных должна находиться в автономном режиме во время восстановления. Я также не знаю, существует ли хороший автоматизированный способ для DPM справиться с такой задачей. Это стоит исследовать, поэтому я благодарю вас за эту идею.
Пролив Дарина: Спасибо за исправление в группе доступности и асинхронном зеркалировании базы данных. Однако из того, что я вижу, с моментальными снимками возникает та же проблема, что и с восстановлением доставки журналов. Пользователи будут отключены во время создания снимка. Мы используем корпоративную версию, так что это вариант. В конце концов, это может быть лучшим вариантом, поскольку он не мешает нашей текущей системе резервного копирования. Спасибо за вклад, я приму это к серьезному рассмотрению.