Många databasadministratörer måste stödja instanser av SQL Server Reporting Services (SSRS), eller åtminstone de backend-databaser som krävs för SSRS. I flera år följde SSRS med installationen av SQL Server, vilket bidrog till att öka en del av förvirringen kring licensiering och support för produkten, så från och med SSRS 2017 är installationspaketet för Reporting Services en separat nedladdning.

Den här artikeln kommer att täcka många områden som databasadministratörer måste vara medvetna om för att korrekt licensiera, återställa och finjustera en Reporting Services-installation. Dessa ämnen gäller både SQL Server Reporting Services och Power BI Report Server.

Licensiering

Installation och support av SSRS kan vara förvirrande. Rapporteringstjänsten kan installeras som en fristående instans på en dedikerad server, på samma instans som SQL Server, eller i en utskalningsinstallation (endast Enterprise Edition). Varje instans där SSRS installeras i produktionen kräver en SQL Server-licens, samt licensiering av instansen av SQL Server där databaserna ReportServer och ReportServerTempDB finns.

Sättet jag gillar att förklara hur man licensierar Reporting Services är att tänka på rapporttjänsten som en applikation som använder SQL Server på baksidan. I början av SSRS var ett krav att även installera och konfigurera Internet Information Services (IIS). SSRS 2008 tog med den komponenten i rapporteringstjänstmodulen. Det är mycket vanligt att se SSRS och MSSQL installerade på samma instans på grund av licensiering och detta kan fungera bra för mindre implementeringar. För större distributioner är det vanligt att se en dedikerad rapporttjänstserver med ReportServer och ReportServerTempDB på en konsoliderad SQL Server. För mycket stora installationer används utskalningsinstallationer för att ge lastbalansering av rapporteringsservertjänsten. I en utskalningsinstallation måste varje instans i gården vara licensierad.

Återställning

I var och en av distributionsmodellerna är databasadministratörens roll att se till att SSRS är stabilt, pålitligt och återställbart. Den återställningsbara delen är något som orsakar vissa DBA-problem. ReportServer-databasen är krypterad och vissa operationer kräver att den symmetriska nyckeln återställs. Om det uppstår ett fel och databasen måste återställas till en annan server, ändras rapportserverns Windows-tjänstkontonamn eller lösenord, datornamnet ändras, du migrerar till en annan server eller lägger till en ny server på en skala- ut konfigurationen kommer du att behöva återställa krypteringsnyckeln. Om inte nyckeln säkerhetskopieras kan skyddad data, såsom anslutningssträngar och lösenord, inte dekrypteras. Jag har upptäckt att många DBA:er inte är medvetna om detta tills det är för sent. Nyckeln kan säkerhetskopieras och återställas manuellt med Reporting Services Configuration Manager, med hjälp av verktyget rskeymgmt.exe eller med PowerShell. Tekniskt sett behöver du bara säkerhetskopiera en kopia av den symmetriska nyckeln.

Databaserna ReportServer och ReportServerTempDB är SQL Server-databaser och bör vara en del av en vanlig säkerhetskopieringsprocess, precis som andra användardatabaser. ReportServer bör använda den fullständiga återställningsmodellen medan ReportServerTempDB kan använda den enkla återställningsmodellen. Tekniskt sett kan ReportServerTempDB återskapas av ett skript i händelse av en katastrof, men ReportServerTempDB kan inte startas utan ReportServerTempDB. DBA:er är bekanta med att återställa databaser, snarare än att leta efter ett skript för att återskapa databasen. Till skillnad från systemdatabasen tempdb, återskapas inte ReportServerTempDB vid start. Bästa praxis för DBA:er är egentligen att bara behandla ReportServer och ReportServerTempDB som vilken annan användardatabas som helst.

Det finns konfigurationsfiler som lagrar programinställningar som också bör säkerhetskopieras. Dessa kan täckas av dina säkerhetskopior på OS-nivå; dock bör DBA:er se till att dessa filer säkerhetskopieras efter den första konfigurationen och/eller efter att eventuella anpassade tillägg har tillämpats. Dessa filer består av:

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

Övervägande för att säkerhetskopiera dina Report Designer-filer som; .rdl-, .rds-, .dv-, .ds-, rptproj- och .sln-filer ska anges.

Inställningsalternativ

Att ställa in SSRS är ungefär som alla andra applikationer. Användare kör rapporter från en applikationsserver som kommunicerar med databaser. Den stora skillnaden är att du har en applikationsserver (Reporting Services) med egna databaser, men rapporten har datakällor som kopplar till andra användardatabaser. DBA:er måste ställa in den övergripande hälsan för Reporting Services-infrastrukturen samt justera de faktiska rapporterna.

Infrastruktur för rapporteringstjänster

Disklatens för ReportServer och ReportServerTempDB är mycket viktigt. Beroende på arbetsbelastningen kan dessa databaser behöva placeras på snabbare diskar. Cacheminne med rapportresultat lagras i ReportServerTempDB-databasen och I/O-prestanda kan bli ett problem här.

Reporting Services-arbetsbelastningen kan kräva att ytterligare Reporting Services-instanser behövs för att hantera den arbetsbelastningen. En utskalningsinstallation kräver en Enterprise Edition-licens. Fördelarna med en utskalningsinstallation inkluderar att ge kunderna lastbalansering för högre genomströmning, hög tillgänglighet, samt möjligheten att segmentera rapportserverbearbetning.

Dra nytta av ögonblicksbilder där de är meningsfulla. Om du har rapporter som använder daggamla data, överväg att använda en ögonblicksbild så att efterföljande visningar av den rapporten använder en ögonblicksbild istället för att behöva generera hela rapporten igen.

Datadrivna prenumerationer kan användas för att köra rapporter och leverera innehållet baserat på abonnentbas och enligt ett schema. Baserat på schemat kan många av dessa rapporter köras efter att databearbetningen är klar, långt innan användarna kommer till jobbet, i en mindre hektisk tid för miljön.

DBA:er bör vara bekanta med exekveringsloggning eftersom det kan hjälpa till att identifiera rapporter som kan vara kandidater för cachelagring samt rapporter som bör tittas på för prestandaförbättringar baserat på exekveringsbearbetning. Exekveringsloggning ger insikter i saker som hur ofta rapporter körs, det mest efterfrågade formatet och procentandelen av bearbetningen som är kopplad till en fas i rapportprocessen. Dessa data kan nås med de inbyggda vyerna för ExecutionLog, ExecutionLog2 och ExecutionLog3.

Allmän inställning

För användardatabaserna som används av rapporterna och instansen som innehåller ReportServer och ReportServerTempDB, vill du spåra och baslinjeprestanda. Du måste övervaka minne/disk/CPU-användning, nätverks-I/O, tempdb-användning, väntetider och andra räknare för att veta vad som är normalt för den totala arbetsbelastningen för dessa system. Om användare börjar rapportera problem måste du kunna veta om den nuvarande användningen är normal eller inte. Om du inte övervakar det, hur kan du mäta det?

Utöver övervakning och baslinje bör till exempel branschaccepterade bästa praxis finnas på plats. Jag har behandlat minnesinställningar, indexunderhåll, statistik, MAXDOP och kostnadströskel för parallellitet i en tidigare artikel, Common SQL Server Mishaps.

Den verkliga magin för att få rapporter att köras snabbare är att optimera för den rapporten. En rapport är i grunden bara en annan fråga. För att ställa in en långsam rapport betyder det vanligtvis att du måste skapa index för den specifika rapporten eller justera koden i rapporten. Om det här är rapporter som träffar OLTP-databasen kan skapande av index för rapporter påverka OLTP-systemet genom att använda mer utrymme, generera ytterligare I/O för uppdateringar, infogar och raderingar, och medföra ytterligare omkostnader för att underhålla dessa index. Du måste balansera risk kontra belöning. Vissa kunder kan separera rapportdatabasen från OLTP genom att använda transaktionsreplikering och detta möjliggör indexering av rapportdatabasen utan att påverka OTLP-databasen.

Även om du kan spåra rapportanvändning med ExecutionLog, måste du undersöka användardatabasinstansen för höga kostnader och långvariga frågor för att justera möjligheter också. DMVs och Query Store är också till stor hjälp, men ett övervakningsverktyg som SQL Sentry kan vara mycket mer kraftfullt och flexibelt. SQL Sentry har inte en "Reporting Services dashboard" i sig, men du kan skapa kalendervyer av SSRS-händelser, enkelt filtrera inbyggda mätvärden och rapporter för att fokusera på SSRS-aktivitet och skapa robusta rådgivande villkor för att övervaka de exakta aspekterna av Rapporteringstjänster du bryr dig om (och inget av bruset du inte gör). Även om du inte kör SSRS på en SQL Server-dator kan du fortfarande använda Win Sentry för att få omfattande prestandainsikter om aktuell och historisk aktivitet på process- och tjänstenivå.

Slutsats

Tuning SQL Server Reporting Services har flera unika egenskaper, men standardprestandajustering är fortfarande tillämplig för att optimera rapporter och övervaka databaserna ReportServer och ReportServerTempDB. Säkerhetskopiering av krypteringsnyckeln är nödvändig för all katastrofåterställning eller migrering. För att bättre förstå användningen av rapporter bör DBA:er börja använda ExcecutionLog.