Report Server Database

Report Server Database — это реляционная база данных, в которой служба Microsoft SQL Server Reporting Services (SSRS) хранит все метаданные, конфигурации, объекты отчётов (определения отчётов, источники данных, расписания, подписки, параметры безопасности) и историю выполненных отчётов. Эту базу данных часто называют каталогом сервера отчётов (report server catalog); без неё работа службы Reporting Services невозможна. Фактически она является единственным источником истины для всех компонентов SSRS — веб-портала, веб-службы и фоновых процессов обработки.

Назначение и функции

Report Server Database выполняет несколько ключевых функций:

• Хранение метаданных отчётов: определения отчётов (.rdl-файлы), общие источники данных (.rsds), общие наборы данных (.rsd), модели отчётов (.smdl).
• Управление безопасностью: роли, разрешения, политики доступа на уровне папок, элементов отчётов и отдельных объектов. Вся авторизация строится на данных этой базы.
• Очередь обработки: SSRS помещает в базу запросы на запуск отчётов (по расписанию, по запросу, через подписки). Фоновый процесс polling постоянно читает эту очередь и инициирует выполнение.
• Хранение истории выполнений: снапшоты (моментальные снимки) отчётов, кэшированные экземпляры и журнал выполнения (execution log).
• Подписки и уведомления: данные о подписчиках, условиях доставки (по электронной почте, в файловую систему, на SharePoint) и состоянии последних доставок.
• Настройки расширений: конфигурации пользовательских модулей безопасности, рендеринга, доставки и обработки данных.

Архитектура и технология

Report Server Database использует реляционную модель хранения. Исторически поддерживаются только Microsoft SQL Server (все редакции, включая Express) и, начиная с SQL Server 2016, Azure SQL Database. СУБД требуется для работы службы — сама база данных не может быть размещена, например, на Oracle или PostgreSQL.

База данных автоматически создаётся при установке службы SSRS через мастер настройки Reporting Services Configuration Manager (RSConfigTool) или при развёртывании в режиме интеграции с SharePoint. Для новой установки создаётся пустая база данных. Для обновления — используется существующая (при совместимости версий).

Основные таблицы

Структура базы данных недокументирована для конечного пользователя — Microsoft не рекомендует изменять её напрямую, так как это может привести к неработоспособности службы. Тем не менее известны некоторые ключевые таблицы:

• Catalog — центральная таблица, содержащая все элементы (отчёты, папки, источники данных, изображения, ресурсы). Столбцы включают ItemID, Path, Name, Content (XML-определение отчёта), Type, CreatedByID.
• ExecutionLog и ExecutionLog2 — журнал выполнения отчётов. Содержит время запуска, имя пользователя, параметры, статус и время рендеринга.
• Schedule — расписания автоматического выполнения, используемые подписками и снапшотами.
• Subscriptions — данные о подписках: владелец, формат доставки, параметры расширения доставки.
• Users и Policies — информация о пользователях (локальные идентификаторы) и политиках доступа.
• SnapshotData — сжатые данные снапшотов (результаты выполнения отчёта на определённый момент).

Взаимосвязь между таблицами многократна, поддерживается внешними ключами и индексами, оптимизированными для выполнения процедур dbo.CreateSnapshot, dbo.ExecuteReport и других системных хранимых процедур.

Режимы работы и топология

Режим собственного сервера (Native Mode)

Наиболее распространённая конфигурация. Сервер отчётов использует одну базу данных для каталога (ReportServer) и одну — для временного хранения сеансов и кэша (ReportServerTempDB). ReportServerTempDB содержит временные таблицы (SessionData, CacheData, SnapshotSegment) и очищается автоматически при перезапуске службы. Обе базы данных могут находиться на том же экземпляре SQL Server, на удалённом сервере (удалённом SQL Server) или в группе доступности Always On.

Режим интеграции с SharePoint

При развёртывании SSRS в ферме SharePoint (до версии 2016 включительно) используется та же структура базы данных, но управление безопасностью и папками делегируется SharePoint. В конфигурации присутствует дополнительная база данных — ReportServerSyncTempDB, используемая для синхронизации метаданных между службами.

Кластеризация и масштабирование

SSRS поддерживает развёртывание в режиме горизонтального масштабирования (scale-out): несколько серверов отчётов могут подключаться к одной и той же базе данных каталога. При этом все изменения мгновенно видны всем узлам. Для распределения нагрузки на базу данных используются чтение с реплик (Always Read-Only Routing) и кэширование отчётов. В масштабе до 10–15 узлов база данных редко становится узким местом; проблемные точки обычно связаны с производительностью самого SQL Server.

Обслуживание и производительность

Размер базы данных

Размер Report Server Database может быстро расти из-за:

• хранения истории выполнения отчётов (рекомендуется ограничивать количество записей, например, 100–500 тысяч);
• неочищенных снапшотов (по умолчанию SSRS хранит неограниченное количество);
• большого числа подписок и кэшированных экземпляров.

Типовые значения через год эксплуатации — от 1 до 50 ГБ на каталог. При очень высокой нагрузке (миллионы выполнений в день) размер может достигать сотен гигабайт.

Управление журналом выполнения

Начиная с SQL Server 2008 R2, SSRS автоматически ведёт журнал выполнения в таблицах ExecutionLog / ExecutionLog2. Администратор может включать/отключать ведение журнала сервера отчётов, очищать старые записи с помощью хранимой процедуры dbo.CleanExecutionLog или устанавливать максимальный срок хранения через RSConfigTool.

Индексы и статистики

Microsoft регулярно выпускает обновления схемы (в составе кумулятивных обновлений SQL Server), которые улучшают производительность запросов к каталогу. При высокой нагрузке рекомендуется следить за фрагментацией индексов и обновлять статистики, особенно на таблицах Catalog, ExecutionLog2 и SnapshotData.

Резервное копирование и восстановление

Report Server Database должна регулярно резервироваться как любой производственный каталог. Для восстановления работоспособности службы необходимо:

1. Восстановить базу данных на SQL Server.
2. Для шифрования ключей — восстановить резервную копию ключа из базы (SSRS хранит зашифрованные строки подключения и учётные данные).
3. Если база данных восстанавливается на новом экземпляре SQL Server — изменить имя сервера и учётные записи через RSConfigTool (команда rsconfig -c -s <сервер>).

Важное ограничение: нельзя использовать базу данных, созданную для более новой версии SSRS, в более старой — обратная совместимость отсутствует.

Ограничения и известные проблемы

• Отсутствие мультиарендности: одна база данных рассчитана на один сервер отчётов (или одну группу в scale-out). Использование одной базы для нескольких независимых служб (арендаторов) не поддерживается.
• Сложность миграции версий: при обновлении SSRS с версии на версию (например, с 2014 на 2022) база данных автоматически обновляется при запуске службы. Откат версии невозможен без восстановления из бекапа, сделанного до обновления.
• Проблемы с кодировкой: исторически база данных использует кодировку Latin1_General_CI_AS. При хранении кириллических названий отчётов возможны несоответствия при сортировке. В SQL Server 2022 и выше рекомендуется принудительно задать UTF-8 для базы данных.
• Уязвимости при неправильной очистке: если отчёт удаляется из веб-портала, его запись в таблице Catalog помечается как удалённая и физически удаляется только при полном перестроении индексов. При накоплении таких «мусорных» записей может снижаться производительность.

Источники

• Microsoft. SQL Server Reporting Services (SSRS) техническая документация. MSDN / learn.microsoft.com.
• Rushton M. SQL Server Reporting Services Recipes. Apress, 2010.
• Hodge W. et al. Professional SQL Server 2012 Reporting Services. Wrox, 2012.
• Microsoft. Описание схемы базы данных сервера отчетов (статья 820761 в базе знаний). Microsoft Support.
• Официальная документация по Reporting Services Configuration Manager. Microsoft Learn.