Veel databasebeheerders moeten instanties van SQL Server Reporting Services (SSRS) ondersteunen, of op zijn minst de backend-databases die nodig zijn voor SSRS. Jarenlang werd SSRS gebundeld met de installatie van SQL Server, wat hielp om de verwarring rond licenties en ondersteuning voor het product te vergroten, dus vanaf SSRS 2017 is het installatiepakket voor Reporting Services een aparte download.

Dit artikel behandelt veel gebieden waarvan databasebeheerders op de hoogte moeten zijn om een juiste licentie voor een Reporting Services-installatie te krijgen, deze te herstellen en af te stemmen. Deze onderwerpen zijn van toepassing op zowel SQL Server Reporting Services als Power BI Report Server.

Licentieverlening

Installatie en ondersteuning van SSRS kan verwarrend zijn. De rapportageservice kan worden geïnstalleerd als een zelfstandige instantie op een dedicated server, op dezelfde instantie als SQL Server of in een scale-out-implementatie (alleen Enterprise Edition). Elke instance waarin SSRS in productie is geïnstalleerd, vereist een SQL Server-licentie, evenals een licentie voor de instance van SQL Server waar de ReportServer- en ReportServerTempDB-databases zich bevinden.

De manier waarop ik graag uitleg over het licentiëren van Reporting Services, is door de rapportageservice te beschouwen als een applicatie die SQL Server aan de achterkant gebruikt. In de begindagen van SSRS was het een vereiste om ook Internet Information Services (IIS) te installeren en configureren. SSRS 2008 bracht dat onderdeel in de rapportageservicemodule. Het is heel gebruikelijk dat SSRS en MSSQL op dezelfde instantie zijn geïnstalleerd vanwege licenties en dit kan goed werken voor kleinere implementaties. Voor grotere implementaties is het gebruikelijk om een speciale rapportageserviceserver te zien met de ReportServer en ReportServerTempDB op een geconsolideerde SQL Server. Voor zeer grote installaties worden scale-out-implementaties gebruikt om de taakverdeling van de rapportageserverservice te bieden. In een scale-out-implementatie moet elke instantie in de farm een licentie hebben.

Herstel

In elk van de implementatiemodellen is de rol van de databasebeheerder ervoor te zorgen dat SSRS stabiel, betrouwbaar en herstelbaar is. Het herstelbare deel is iets dat sommige DBA-problemen veroorzaakt. De ReportServer-database is versleuteld en voor bepaalde bewerkingen moet de symmetrische sleutel worden hersteld. Als er een storing is en de database moet worden hersteld naar een andere server, wordt de accountnaam of het wachtwoord van de Report Server Windows-service gewijzigd, de computernaam gewijzigd, migreert u naar een andere server of voegt u een nieuwe server toe aan een schaal- out-configuratie, moet u de coderingssleutel herstellen. Tenzij er een back-up van de sleutel wordt gemaakt, kunnen alle beveiligde gegevens, zoals verbindingsreeksen en wachtwoorden, niet worden ontsleuteld. Ik heb gemerkt dat veel DBA's zich hiervan niet bewust zijn totdat het te laat is. De sleutel kan handmatig worden geback-upt en hersteld met behulp van de Reporting Services Configuration Manager, met het hulpprogramma rskeymgmt.exe of met PowerShell. U hoeft technisch gezien maar één kopie van de symmetrische sleutel te back-uppen.

De ReportServer- en ReportServerTempDB-databases zijn SQL Server-databases en zouden deel moeten uitmaken van een regelmatig back-upproces, net als andere gebruikersdatabases. ReportServer zou het volledige herstelmodel moeten gebruiken, terwijl de ReportServerTempDB het eenvoudige herstelmodel kan gebruiken. Technisch gezien kan ReportServerTempDB opnieuw worden gemaakt door een script in het geval van een ramp, maar Reporting Services kan niet starten zonder ReportServerTempDB. DBA's zijn bekend met het herstellen van databases, in plaats van te zoeken naar een script om de database opnieuw te maken. In tegenstelling tot de systeemdatabase tempdb, wordt ReportServerTempDB niet opnieuw gemaakt bij het opstarten. De beste praktijk voor DBA's is eigenlijk om ReportServer en ReportServerTempDB te behandelen zoals elke andere gebruikersdatabase.

Er zijn configuratiebestanden die applicatie-instellingen opslaan waarvan ook een back-up moet worden gemaakt. Deze kunnen worden gedekt door uw back-ups op besturingssysteemniveau; DBA's moeten er echter voor zorgen dat van deze bestanden een back-up wordt gemaakt na de eerste configuratie en/of nadat eventuele aangepaste extensies zijn toegepast. Deze bestanden bestaan uit:

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

Overweging voor het maken van back-ups van uw Report Designer-bestanden zoals; .rdl-, .rds-, .dv-, .ds-, rptproj- en .sln-bestanden moeten worden opgegeven.

Afstemmingsopties

Het afstemmen van SSRS lijkt veel op elke andere toepassing. Gebruikers voeren rapporten uit vanaf een applicatieserver die communiceert met databases. Het grote verschil is dat u een applicatieserver (Reporting Services) met eigen databases hebt, maar het rapport heeft gegevensbronnen die verbinding maken met andere gebruikersdatabases. DBA's moeten afstemmen op de algehele gezondheid van de Reporting Services-infrastructuur en de daadwerkelijke rapporten afstemmen.

Infrastructuur voor rapportagediensten

Schijflatentie voor ReportServer en ReportServerTempDB is erg belangrijk. Afhankelijk van de workload moeten die databases mogelijk op snellere schijven worden geplaatst. Caches van rapportresultaten worden opgeslagen in de ReportServerTempDB-database en I/O-prestaties kunnen hier een probleem worden.

De werklast van Reporting Services kan ertoe leiden dat er extra Reporting Services-instanties nodig zijn om die werklast af te handelen. Een scale-out implementatie vereist een Enterprise Edition-licentie. Voordelen van een scale-out-implementatie zijn onder meer dat klanten taakverdeling krijgen voor een hogere doorvoer, hoge beschikbaarheid en de mogelijkheid om de verwerking van rapportservers te segmenteren.

Profiteer van Snapshots waar ze zinvol zijn. Als u rapporten heeft die gegevens van een dag oud gebruiken, overweeg dan om een momentopname te gebruiken, zodat volgende weergaven van dat rapport een momentopname gebruiken in plaats van het hele rapport opnieuw te moeten genereren.

Gegevensgestuurde abonnementen kunnen worden gebruikt om rapporten uit te voeren en de inhoud te leveren op basis van abonneebestand en volgens een schema. Op basis van het schema kunnen veel van deze rapporten worden uitgevoerd nadat de gegevensverwerking is voltooid, ruim voordat gebruikers op het werk arriveren, in een minder drukke tijd voor het milieu.

DBA's moeten bekend zijn met uitvoeringsregistratie, omdat dit kan helpen bij het identificeren van rapporten die in aanmerking komen voor caching, evenals rapporten die moeten worden bekeken voor prestatieverbetering op basis van uitvoeringsverwerking. Uitvoeringsregistratie biedt inzicht in zaken als hoe vaak rapporten worden uitgevoerd, de meest gevraagde indeling en het verwerkingspercentage dat is gekoppeld aan een fase van het rapportproces. Deze gegevens zijn toegankelijk via de ingebouwde weergaven voor ExecutionLog, ExecutionLog2 en ExecutionLog3.

Algemene afstemming

Voor de gebruikersdatabases die worden gebruikt door de rapporten en het exemplaar dat de ReportServer en ReportServerTempDB bevat, wilt u de prestaties bijhouden en basislijnen. U moet het gebruik van geheugen/schijf/CPU, netwerk-I/O, tempdb-gebruik, wachttijden en andere tellers in de gaten houden om te weten wat normaal is voor de algehele werklast van die systemen. Als gebruikers problemen beginnen te melden, moet u weten of het huidige gebruik normaal is of niet. Als u het niet controleert, hoe kunt u het dan meten?

Naast monitoring en basislijning, moeten er door de industrie geaccepteerde best practices zijn voor de instantie. Ik heb geheugeninstellingen, indexonderhoud, statistieken, MAXDOP en kostendrempel voor parallellisme behandeld in een vorig artikel, Common SQL Server Mishaps.

De echte magie om rapporten sneller te laten werken, is om voor dat rapport te optimaliseren. Een rapport is in wezen gewoon een andere vraag. Als u wilt afstemmen op een traag rapport, betekent dit meestal dat u indexen voor dat specifieke rapport moet maken of de code in het rapport moet afstemmen. Als dit rapporten zijn die de OLTP-database bereiken, kan het maken van indexen voor rapporten van invloed zijn op het OLTP-systeem door meer ruimte te gebruiken, extra I/O te genereren voor updates, invoegingen en verwijderingen, en extra overhead te veroorzaken voor het onderhouden van die indexen. U moet het risico versus de beloning afwegen. Sommige klanten kunnen de rapportagedatabase scheiden van de OLTP door gebruik te maken van transactionele replicatie, waardoor de rapportagedatabase kan worden geïndexeerd zonder de OTLP-database te beïnvloeden.

Hoewel u het gebruik van rapporten kunt volgen met behulp van ExecutionLog, moet u ook de gebruikersdatabase-instantie onderzoeken op hoge kosten en langlopende query's voor afstemmingsmogelijkheden. DMV's en Query Store zijn ook een enorme hulp, maar een monitoringtool zoals SQL Sentry kan veel krachtiger en flexibeler zijn. SQL Sentry heeft niet per se een "Reporting Services-dashboard", maar u kunt kalenderweergaven van SSRS-gebeurtenissen maken, eenvoudig ingebouwde statistieken en rapporten filteren om u te concentreren op SSRS-activiteit, en robuuste adviesvoorwaarden creëren om de precieze aspecten van Reporting Services waar u om geeft (en geen van de ruis waar u niet om geeft). Zelfs als u SSRS niet op een SQL Server-machine gebruikt, kunt u Win Sentry nog steeds gebruiken om uitgebreide prestatie-inzichten te krijgen in huidige en historische activiteit op proces- en serviceniveau.

Conclusie