Mnoho správců databází musí podporovat instance SQL Server Reporting Services (SSRS) nebo alespoň backendové databáze, které jsou pro SSRS vyžadovány. Po léta byl SSRS spojen s instalací SQL Serveru, což přispělo k určitému zmatku kolem licencování a podpory produktu, takže počínaje SSRS 2017 je instalační balíček pro Reporting Services samostatným stažením.

Tento článek se bude zabývat mnoha oblastmi, o kterých si správci databází musí být vědomi, aby mohli správně licencovat, obnovit a vyladit instalaci Reporting Services. Tato témata platí pro SQL Server Reporting Services i pro Power BI Report Server.

Licencování

Instalace a podpora SSRS může být matoucí. Službu hlášení lze nainstalovat jako samostatnou instanci na vyhrazený server, na stejnou instanci jako SQL Server nebo v rozšiřitelném nasazení (pouze Enterprise Edition). Každá instance, kde je SSRS instalována v produkci, vyžaduje licenci SQL Server a také licencování instance SQL Server, kde jsou umístěny databáze ReportServer a ReportServerTempDB.

Způsob, jakým rád vysvětluji, jak licencovat Reporting Services, je uvažovat o službě Reporting jako o aplikaci, která používá SQL Server na zadní straně. V počátcích SSRS bylo požadavkem také nainstalovat a nakonfigurovat Internet Information Services (IIS). SSRS 2008 přinesl tuto komponentu do modulu reportovací služby. Je velmi běžné vidět SSRS a MSSQL nainstalované ve stejné instanci kvůli licencování a to může fungovat dobře pro menší implementace. U větších nasazení je běžné vidět vyhrazený server reportovací služby s ReportServer a ReportServerTempDB na konsolidovaném SQL serveru. U velmi rozsáhlých instalací se k zajištění vyrovnávání zátěže služby serveru pro vytváření sestav používají škálovací nasazení. V rozšiřujícím nasazení musí být každá instance ve farmě licencována.

Obnovení

V každém z modelů nasazení je úlohou správce databáze zajistit, aby SSRS bylo stabilní, spolehlivé a obnovitelné. Obnovitelná část je něco, co způsobuje problémy s DBA. Databáze ReportServer je šifrovaná a určité operace vyžadují obnovení symetrického klíče. Pokud dojde k poruše a databázi je třeba obnovit na jiný server, změní se název účtu nebo heslo služby Report Server Windows, změní se název počítače, migrujete na jiný server nebo přidáte nový server do měřítka- po konfiguraci, budete muset obnovit šifrovací klíč. Pokud není klíč zálohován, nelze dešifrovat žádná chráněná data, jako jsou připojovací řetězce a hesla. Zjistil jsem, že mnoho správců databází o tom neví, dokud není příliš pozdě. Klíč lze zálohovat a obnovit ručně pomocí nástroje Reporting Services Configuration Manager, pomocí nástroje rskeymgmt.exe nebo pomocí prostředí PowerShell. Technicky potřebujete zálohovat pouze jednu kopii symetrického klíče.

Databáze ReportServer a ReportServerTempDB jsou databáze SQL Server a měly by být součástí pravidelného procesu zálohování, stejně jako jiné uživatelské databáze. ReportServer by měl používat model úplné obnovy, zatímco ReportServerTempDB může používat jednoduchý model obnovy. Technicky lze ReportServerTempDB v případě havárie znovu vytvořit pomocí skriptu, avšak Reporting Services nelze spustit bez ReportServerTempDB. DBA jsou obeznámeni s obnovou databází, spíše než hledáním skriptu pro opětovné vytvoření databáze. Na rozdíl od systémové databáze tempdb se ReportServerTempDB při spuštění znovu nevytvoří. Nejlepší praxí pro správce databází je skutečně zacházet s ReportServer a ReportServerTempDB jako s jakoukoli jinou uživatelskou databází.

Existují konfigurační soubory, které ukládají nastavení aplikace, která by měla být také zálohována. Ty mohou být pokryty zálohami na úrovni operačního systému; správci databází by se však měli ujistit, že tyto soubory jsou zálohovány po počáteční konfiguraci a/nebo po použití jakýchkoli vlastních rozšíření. Tyto soubory se skládají z:

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

Zvažte zálohování souborů Návrháře sestav, jako jsou; Měly by být uvedeny soubory .rdl, .rds, .dv, .ds, rptproj a .sln.

Možnosti ladění

Ladění SSRS je podobné jako u jakékoli jiné aplikace. Uživatelé spouštějí sestavy z aplikačního serveru, který komunikuje s databázemi. Velký rozdíl je v tom, že máte aplikační server (Reporting Services) s vlastními databázemi, ale sestava má zdroje dat připojené k jiným uživatelským databázím. DBA musí vyladit celkový stav infrastruktury Reporting Services a také vyladit skutečné sestavy.

Infrastruktura reportovacích služeb

Latence disku pro ReportServer a ReportServerTempDB je velmi důležitá. V závislosti na pracovní zátěži může být nutné tyto databáze umístit na rychlejší disky. Mezipaměti výsledků sestav jsou uloženy v databázi ReportServerTempDB a zde může být problémem výkon I/O.

Pracovní vytížení Reporting Services může diktovat, že ke zpracování tohoto zatížení jsou potřeba další instance Reporting Services. Škálovatelné nasazení vyžaduje licenci Enterprise Edition. Mezi výhody škálovatelného nasazení patří poskytování vyvažování zátěže zákazníkům pro vyšší propustnost, vysokou dostupnost a také možnost segmentovat zpracování serveru sestav.

Využijte Snapshots tam, kde mají smysl. Máte-li přehledy, které používají data stará den, zvažte použití snímku, aby další zobrazení tohoto přehledu používala snímek namísto toho, abyste museli znovu generovat celý přehled.

Data Driven Subscriptions lze použít ke spouštění sestav a poskytování obsahu na základě předplatitelské základny a podle plánu. Na základě plánu lze mnoho z těchto sestav spustit po dokončení zpracování dat, dlouho předtím, než uživatelé dorazí do práce, v době méně rušné pro životní prostředí.

DBA by měli být obeznámeni s protokolováním provádění, protože to může pomoci identifikovat sestavy, které by mohly být kandidáty na ukládání do mezipaměti, a také sestavy, u kterých je třeba se zaměřit na zlepšení výkonu na základě zpracování provádění. Protokolování provádění poskytuje informace o tom, jak často jsou sestavy spouštěny, nejžádanější formát a procento zpracování vázané na fázi procesu sestavování. K těmto datům lze přistupovat pomocí vestavěných zobrazení pro ExecutionLog, ExecutionLog2 a ExecutionLog3.

Obecné ladění

U uživatelských databází používaných sestavami a instancí obsahující ReportServer a ReportServerTempDB chcete sledovat a základní výkon. Musíte sledovat využití paměti/disku/CPU, síťové I/O, využití databáze tempdb, čekání a další čítače, abyste věděli, co je normální pro celkovou zátěž těchto systémů. Pokud uživatelé začnou hlásit problémy, musíte vědět, zda je aktuální využití normální nebo ne. Pokud to nesledujete, jak to můžete měřit?

Kromě monitorování a základního stanovení by například měly být zavedeny osvědčené postupy akceptované průmyslem. Nastavení paměti, údržbu indexu, statistiky, MAXDOP a prahovou hodnotu pro paralelismus jsem popsal v předchozím článku Běžné chyby serveru SQL.

Skutečným kouzlem pro rychlejší spouštění přehledů je optimalizace pro daný přehled. Zpráva je v podstatě jen další dotaz. Chcete-li vyladit pomalou sestavu, obvykle to znamená, že musíte vytvořit indexy pro tuto konkrétní sestavu nebo vyladit kód v sestavě. Pokud se jedná o sestavy, které zasahují do databáze OLTP, pak vytváření indexů pro sestavy může ovlivnit systém OLTP tím, že zabere více místa, generuje další I/O pro aktualizace, vkládání a mazání a vynakládá další režii na údržbu těchto indexů. Musíte vyvážit riziko a odměnu. Někteří zákazníci mohou oddělit databázi hlášení od OLTP pomocí transakční replikace, což umožňuje indexování databáze hlášení bez dopadu na databázi OTLP.

I když můžete sledovat využití sestav pomocí ExecutionLog, budete muset prozkoumat instanci uživatelské databáze a vyhledat také vysoké náklady a dlouhotrvající dotazy pro příležitosti ladění. Velkou pomocí jsou také DMV a Query Store, ale monitorovací nástroj jako SQL Sentry může být mnohem výkonnější a flexibilnější. SQL Sentry nemá „řídicí panel Reporting Services“ jako takový, ale můžete vytvářet kalendářové pohledy na události SSRS, snadno filtrovat vestavěné metriky a sestavy, abyste se zaměřili na aktivitu SSRS, a vytvářet robustní poradenské podmínky pro sledování přesných aspektů Reporting Services, na kterých vám záleží (a žádný hluk, který nemáte). I když nepoužíváte SSRS na počítači se serverem SQL Server, můžete stále používat Win Sentry k získání bohatého přehledu o výkonu aktuální a historické aktivity na úrovni procesů a služeb.

Závěr