Много администратори на бази данни се налага да поддържат екземпляри на SQL Server Reporting Services (SSRS) или поне бекенд бази данни, които са необходими за SSRS. В продължение на години SSRS беше в комплект с инсталирането на SQL Server, което помогна да се добави част от объркването около лицензирането и поддръжката на продукта, така че започвайки от SSRS 2017, инсталационният пакет за Reporting Services е отделно изтегляне.

Тази статия ще обхване много области, с които администраторите на бази данни трябва да са наясно, за да лицензират правилно, възстановяват и настройват инсталация на Reporting Services. Тези теми важат както за SQL Server Reporting Services, така и за Power BI Report Server.

Лицензиране

Инсталирането и поддръжката на SSRS може да бъде объркващо. Услугата за отчитане може да бъде инсталирана като самостоятелен екземпляр на специален сървър, на същия екземпляр като SQL Server или в разгръщане на мащабиране (само за Enterprise Edition). Всеки екземпляр, където SSRS е инсталиран в производството, изисква лиценз за SQL Server, както и лицензиране на екземпляра на SQL Server, където се намират базите данни ReportServer и ReportServerTempDB.

Начинът, по който обичам да обяснявам как да лицензирам Reporting Services, е да мисля за услугата за отчитане като приложение, което използва SQL Server в задния край. В първите дни на SSRS изискването беше също да се инсталират и конфигурират Интернет информационни услуги (IIS). SSRS 2008 въведе този компонент в модула на услугата за отчитане. Много често е да видите SSRS и MSSQL инсталирани на един и същи екземпляр поради лицензиране и това може да работи добре за по-малки реализации. За по-големи разгръщания е обичайно да видите специален сървър за услуга за отчитане с ReportServer и ReportServerTempDB на консолидиран SQL сървър. За много големи инсталации се използват разгръщане на мащабиране, за да се осигури балансиране на натоварването на услугата на сървъра за отчитане. При мащабно разгръщане всеки екземпляр във фермата трябва да бъде лицензиран.

Възстановяване

Във всеки от моделите на внедряване ролята на администратора на базата данни е да се увери, че SSRS е стабилен, надежден и възстановим. Възстановимата част е нещо, което причинява някои проблеми с DBA. Базата данни на ReportServer е криптирана и определени операции изискват възстановяване на симетричния ключ. Ако има неизправност и базата данни трябва да бъде възстановена на друг сървър, името или паролата на услугата на Windows на сървъра за отчети се променят, името на компютъра се променя, мигрирате към друг сървър или добавяте нов сървър към мащаб- извън конфигурацията, ще трябва да възстановите ключа за криптиране. Освен ако ключът не е архивиран, всички защитени данни, като низове за връзка и пароли, не могат да бъдат декриптирани. Открих, че много администратори на база данни не са наясно с това, докато не стане твърде късно. Ключът може да бъде архивиран и възстановен ръчно с помощта на Мениджъра за конфигурация на Reporting Services, с помощта на помощната програма rskeymgmt.exe или чрез PowerShell. Технически трябва да архивирате само едно копие на симетричния ключ.

Базите данни ReportServer и ReportServerTempDB са бази данни на SQL Server и трябва да бъдат част от редовен процес на архивиране, точно както други потребителски бази данни. ReportServer трябва да използва модела за пълно възстановяване, докато ReportServerTempDB може да използва прост модел за възстановяване. Технически, ReportServerTempDB може да бъде пресъздадена чрез скрипт в случай на бедствие, но услугите за докладване не могат да стартират без ReportServerTempDB. DBA са запознати с възстановяването на бази данни, вместо да търсят скрипт за пресъздаване на базата данни. За разлика от системната база данни tempdb, ReportServerTempDB не се пресъздава при стартиране. Най-добрата практика за DBA е наистина просто да третират ReportServer и ReportServerTempDB като всяка друга потребителска база данни.

Има конфигурационни файлове, които съхраняват настройките на приложението, които също трябва да бъдат архивирани. Те могат да бъдат покрити от вашите резервни копия на ниво ОС; обаче администраторите на база данни трябва да се уверят, че тези файлове са архивирани след първоначалната конфигурация и/или след прилагането на всякакви персонализирани разширения. Тези файлове се състоят от:

• Rsreportserver.config
• Rssvrpolicy.config
• Rsmgrpolicy.config
• Reportingservciesservice.exe.config
• Web.config
• Machine.config

Обмисляне за архивиране на вашите файлове на Report Designer, като например; Трябва да се дадат файлове .rdl, .rds, .dv, .ds, rptproj и .sln.

Опции за настройка

Настройката на SSRS е много като всяко друго приложение. Потребителите изпълняват отчети от сървър на приложения, който комуникира с бази данни. Голямата разлика е, че имате сървър на приложения (Reporting Services) със собствени бази данни, но отчетът има източници на данни, свързващи се с други потребителски бази данни. DBA трябва да се настройват за цялостното състояние на инфраструктурата на Reporting Services, както и да настройват действителните отчети.

Инфраструктура на услугите за отчитане

Закъснението на диска за ReportServer и ReportServerTempDB е много важно. В зависимост от работното натоварване може да се наложи тези бази данни да бъдат поставени на по-бързи дискове. Кешовете на резултатите от отчетите се съхраняват в базата данни ReportServerTempDB и I/O производителността може да стане проблем тук.

Работното натоварване на Reporting Services може да диктува, че са необходими допълнителни екземпляри на Reporting Services за справяне с това работно натоварване. За разгръщане на мащаба е необходим лиценз за Enterprise Edition. Предимствата на мащабното внедряване включват предоставяне на балансиране на натоварването на клиентите за по-висока пропускателна способност, висока наличност, както и възможността за сегментиране на обработката на сървъра за отчети.

Възползвайте се от моментните снимки там, където имат смисъл. Ако имате отчети, които използват данни за един ден, помислете за използването на моментна снимка, така че следващите изгледи на този отчет да използват моментна снимка, вместо да се налага да генерирате целия отчет отново.

Абонаментите, управлявани от данни, могат да се използват за изготвяне на отчети и доставяне на съдържанието въз основа на база абонати и по график. Въз основа на графика много от тези отчети могат да се изпълняват след завършване на обработката на данните, доста преди потребителите да пристигнат на работа, в по-малко натоварено време за околната среда.

DBA трябва да са запознати с регистрирането на изпълнението, тъй като това може да помогне за идентифициране на отчети, които биха могли да бъдат кандидати за кеширане, както и отчети, които трябва да се разглеждат за подобряване на производителността въз основа на обработката на изпълнение. Регистрирането на изпълнението предоставя информация за неща като честотата на изготвяне на отчетите, най-търсения формат и процента на обработка, обвързана с фаза от процеса на отчет. Тези данни могат да бъдат достъпни с помощта на вградените изгледи за ExecutionLog, ExecutionLog2 и ExecutionLog3.

Обща настройка

За потребителските бази данни, използвани от отчетите, и екземпляра, съдържащ ReportServer и ReportServerTempDB, искате да проследявате и базовата производителност. Трябва да наблюдавате използването на памет/диск/процесор, мрежов вход/изход, използване на tempdb, изчаквания и други броячи, за да знаете какво е нормално за цялостното натоварване на тези системи. Ако потребителите започнат да съобщават за проблеми, трябва да можете да разберете дали текущото използване е нормално или не. Ако не го наблюдавате, как можете да го измерите?

В допълнение към наблюдението и базовото изготвяне, трябва да има и най-добри практики, приети от индустрията. Разгледах настройките на паметта, поддръжката на индекса, статистиката, MAXDOP и прага на разходите за паралелизъм в предишна статия, Често срещани грешки в SQL Server.

Истинската магия за по-бързо изпълнение на отчетите е да оптимизирате за този отчет. Отчетът по същество е просто още една заявка. За да настроите бавен отчет, това обикновено означава, че трябва да създадете индекси за този конкретен отчет или да настроите кода в отчета. Ако това са отчети, които удрят OLTP базата данни, тогава създаването на индекси за отчети може да повлияе на OLTP системата чрез използване на повече пространство, генериране на допълнителен I/O за актуализации, вмъквания и изтривания и поемане на допълнителни разходи за поддържане на тези индекси. Трябва да балансирате риска срещу наградата. Някои клиенти могат да отделят базата данни за отчети от OLTP, като използват репликация на транзакции и това позволява индексиране на базата данни за отчети, без да се засяга OTLP базата данни.

Въпреки че можете да проследявате използването на отчети с помощта на ExecutionLog, ще трябва да проучите потребителската база данни за висока цена и продължителни заявки за възможности за настройка. DMV и Query Store също са от голяма помощ, но инструмент за наблюдение като SQL Sentry може да бъде много по-мощен и гъвкав. SQL Sentry няма "табло за управление на услугите за отчитане" само по себе си, но можете да създавате календарни изгледи на SSRS събития, лесно да филтрирате вградени показатели и отчети, за да се съсредоточите върху SSRS активността, и да създавате стабилни условия за съвет за наблюдение на точните аспекти на Услуги за отчитане, които ви интересуват (и никой от шума, който не ви интересува). Дори и да не използвате SSRS на машина на SQL Server, все пак можете да използвате Win Sentry, за да получите богата информация за производителността на текущата и историческа дейност на ниво процес и услуга.

Заключение

Настройка на SQL Server Reporting Services има няколко уникални характеристики, но стандартната настройка на производителността все още е приложима за оптимизиране на отчетите и наблюдение на базите данни ReportServer и ReportServerTempDB. Архивирането на ключа за криптиране е необходимо за всякакви усилия за възстановяване при бедствие или миграция. За да разберат по-добре използването на отчети, администраторите на база данни трябва да започнат да използват ExcecutionLog.