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