Автоматическое выполнение отчетов
Едва в 2005-м появились DMV (и DMF – dynamic management functions), с помощью которых можно получить массу подноготной правды о жизни и здоровье SQL Server, в SQL Server Manageability Product Unit, который выпускает Management Tools для SQL Server, немедленно возникла мысль скрестить выразительные средства Reporting Services с информативностью DMV и построить нечто сродни ситуационного центра администратора - https://blogs.msdn.com/sqlrem/archive/2006/05/16/SSMS-Reports-1.aspx. Был сделан набор стандартных отчетов, позволяющих мониторить различные аспекты деятельности SQL Server: рис. 1 Помимо основной задачи мониторинга, с помощью отчетов SSMS можно было решить также обратную задачу – подсмотреть, к каким DMV происходит обращение в датасете (запросе) отчета с тем, чтобы затем использовать их для своих собственных надобностей. Это элементарно сделать через профайлер (https://blogs.msdn.com/alexejs/archive/2009/07/25/1-2.aspx) при запуске отчета, либо скачав исходные RDLи стандартных отчетов - https://blogs.msdn.com/sqlrem/attachment/732910.ashx. Можно создать BIный проект типа Report Server Project, куда подцепить все rdl-файлы SSMS: рис. 2 Можно даже их подредактировать по своему желанию и засунуть обратно, потому что в SQL Server 2005 Service Pack 2 в дополнение к стандартным появилась возможность создавать Custom Reports - https://blogs.msdn.com/sqlrem/archive/2006/11/20/custom-reports-in-management-studio.aspx. Процедура создания и вызова пользовательских отчетов описана в BOL: https://msdn.microsoft.com/ru-ru/library/bb153684.aspx. Примерно тогда же, в районе 2005 SP2, были выпущены дополнительные отчеты по контролю за производительностью, расширяющие стандартный список. рис. 3 которые распространялись в составе SQL Server 2005 Performance Dashboard, свободного дополнения к SQL Server 2005, доступного по адресу https://www.microsoft.com/downloads/details.aspx?FamilyId=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en. С ней тоже можно развлекаться, создав в Visual Studio собственный Report Server Project и подцепив в него все rdlи в ее составе: рис. 4 Как утверждалось, the information captured in the reports is retrieved from SQL Server's dynamic management views. There is no additional tracing or data capture required, which means the information is always available and this is a very inexpensive means of monitoring your server. И это действительно, так. Стандартные отчеты, помимо DMV, прибегают к чтению SQL Serverной дефолтной трассы ::fn_trace_gettable(@base_tracefilename, default) в Backup_Restore_Events.rdl, Configuration_Changes_History.rdl, Database_Consistency_History.rdl, Disk_Usage.rdl, Login_Failures.rdl, Memory_Consumption.rdl, Schema_Changes_History.rdl, Schema_Changes_History_DB.rdl. Performance Dashboard основывается сугубо на DMV. Однако Performance Dashboard создает в msdb схему MS_PerfDashboard, а в ней свои процедуры и функции. Разумеется, исходный код созданных процедур и функций можно посмотреть в SSMS. В отличие от стандартных отчетов, Performance Dashboard не считалась штатной функциональностью SQL Server. Это означало, что если вы обнаружили какой-либо баг в стандартных отчетах, его будут исправлять, а Performance Dashboard предлагалась as is и поддержка на нее не распространялась. Впрочем, поскольку и то, и другое доступно в виде своих RDL-исходников, поправить выявленные баги не составляет труда - http://blog.hoegaerden.be/2008/12/21/a-performance-dashboard-issue/. Единственно, в случае стандартных отчетов пришлось бы довольствоваться custom report, пока разработчики SQL Server официально не внесут исправления в следующем сервис-паке. Последовательность установки Performance Dashboard и что какой отчет в ней значит разбирается, например, здесь - http://www.sql-server-performance.com/articles/per/bm_performance_dashboard_2005_p2.aspx. Проблема что стандартных отчетов, что Performance Dashboard состоит в том, что они нигде не накапливают собранную информацию, т.е. нельзя посмотреть изменение характеристик в динамике, чтобы понять, как мы дошли до жизни такой. Насколько я помню, в схеме MS_PerfDashboard не создается никаких табличек, токмо процедуры и функции, дабы уменьшить монструозность запросов. В 2008-м этой проблемы нет, в его состав штатно входит Performance Management Studio - дальнейшее развитие идей Performance Dashboard, где создается хранилище для накопления исторической информации. Но про Performance Management Datawarehouse мы поговорим в следующий раз, а сейчас я хочу остановиться на теме, вынесенной в название поста. Коль скоро в Performance Dashboard ретроспектива не поддерживается, а потребность в ней была, на одном проекте, имевшем место года 2 - 2.5 назад, возникла мысль иметь своего рода snapshot history, т.е. чтобы выбранные отчеты из списка Performance Dashboard или стандартных или комбинированного или еще какого-нибудь, неважно, выполнялись с заданной частотой в течение дня и результаты складировались. В данном посте мне показалось, будет полезным выделить фрагмент в виде более общей задачи. Имеется набор некоторых отчетов в виде rdl. Отчеты могут быть параметризованы, тогда предполагается, что к каждому такому отчету прилагается список значений его параметров. Требуется выполнить все эти отчеты и получить результаты в виде xls'ов. Я покажу, как бы стал решать эту задачу на примере отчетов Performance Dashboard. В SQL Server 2005 SP2 оболочка SSMS была доработана с тем, чтобы она могла отображать отчеты из RDL-файлов без необходимости установки Reporting Services - Reporting Services is not required to be installed to use the Performance Dashboard Reports. Разумеется, в данном случае нам понадобится честная установка Reporting Services. Существуют два способа автоматизировать действия на Reporting Service: при помощи VB-подобных скриптов утилиты командной строки rs.exe и обратившись к нему как к веб-сервису. Я выбрал второй вариант. Чтобы написать программу выполнения списка отчетов, вначале требуется этот список как либо составить. Можно просто читать rdlи из папки, но тогда непонятно, как быть с параметрами отчетов. Я остановился на XML, содержащем полные имена RDL и XLS как результата экспорта и полагающиеся каждому отчету значений параметров. Так это будет выглядеть в случае Performance Dashboard DeployExecReports.xml:
Скрипт 1 Под это дело, я думаю, можно даже подогнать схему. DeployExecReports.xsd:
Скрипт 2 Это, собственно, код
Скрипт 3 Результатом выполнения является набор указанных экселей рис. 5 с выполненными отчетами. Пример: рис. 6 Или вот, кстати, отчет, выводящий перечень всех запущенных трасс c их характеристиками (см. пред.пост «Программно сгенерить трассу профайлера»): рис. 7 Автор: Алексей Шуленин |