Mange databaseadministratorer er nødt til at understøtte forekomster af SQL Server Reporting Services (SSRS), eller i det mindste de backend-databaser, der kræves til SSRS. I årevis var SSRS bundtet med installationen af SQL Server, hvilket var med til at øge noget af forvirringen omkring licensering og support til produktet, så fra og med SSRS 2017 er installationspakken til Reporting Services en separat download.

Denne artikel vil dække mange områder, som databaseadministratorer skal være opmærksomme på for korrekt at licensere, gendanne og justere en Reporting Services-installation. Disse emner gælder for både SQL Server Reporting Services og Power BI Report Server.

Licensering

Installation og support af SSRS kan være forvirrende. Rapporteringstjenesten kan installeres som en selvstændig instans på en dedikeret server, på samme instans som SQL Server eller i en udskaleringsinstallation (kun Enterprise Edition). Hver forekomst, hvor SSRS er installeret i produktionen, kræver en SQL Server-licens, samt licens til den forekomst af SQL Server, hvor ReportServer- og ReportServerTempDB-databaserne findes.

Den måde, jeg kan lide at forklare, hvordan man licenserer Reporting Services, er at tænke på rapporteringstjenesten som en applikation, der bruger SQL Server på bagenden. I de tidlige dage af SSRS var et krav også at installere og konfigurere Internet Information Services (IIS). SSRS 2008 bragte denne komponent ind i rapporteringsservicemodulet. Det er meget almindeligt at se SSRS og MSSQL installeret på samme instans på grund af licensering, og dette kan fungere godt for mindre implementeringer. For større implementeringer er det almindeligt at se en dedikeret rapporteringstjenesteserver med ReportServer og ReportServerTempDB på en konsolideret SQL Server. For meget store installationer bruges scale-out-implementeringer til at give belastningsbalancering af rapporteringsservertjenesten. I en udskaleringsinstallation skal hver instans i farmen have licens.

Gendannelse

I hver af implementeringsmodellerne er databaseadministratorens rolle at sikre, at SSRS er stabilt, pålideligt og kan gendannes. Den genskabelige del er noget, der forårsager nogle DBA-problemer. ReportServer-databasen er krypteret, og visse operationer kræver gendannelse af den symmetriske nøgle. Hvis der er en fejl, og databasen skal gendannes til en anden server, ændres Report Server Windows-tjenestens kontonavn eller adgangskode, computernavnet ændres, du migrerer til en anden server, eller du tilføjer en ny server til en skala- ud af konfigurationen, bliver du bedt om at gendanne krypteringsnøglen. Medmindre nøglen er sikkerhedskopieret, kan beskyttede data, såsom forbindelsesstrenge og adgangskoder, ikke dekrypteres. Jeg har fundet ud af, at mange DBA'er ikke er klar over dette, før det er for sent. Nøglen kan sikkerhedskopieres og gendannes manuelt ved hjælp af Reporting Services Configuration Manager, ved hjælp af rskeymgmt.exe-værktøjet eller ved hjælp af PowerShell. Du behøver teknisk set kun at sikkerhedskopiere én kopi af den symmetriske nøgle.

ReportServer- og ReportServerTempDB-databaserne er SQL Server-databaser og bør være en del af en almindelig backup-proces, ligesom andre brugerdatabaser. ReportServer bør bruge den fulde gendannelsesmodel, mens ReportServerTempDB kan bruge den simple gendannelsesmodel. Teknisk set kan ReportServerTempDB genskabes af et script i tilfælde af en katastrofe, men Reporting Services kan ikke starte uden ReportServerTempDB. DBA'er er fortrolige med at gendanne databaser i stedet for at lede efter et script til at genskabe databasen. I modsætning til systemdatabasen tempdb bliver ReportServerTempDB ikke genskabt ved opstart. Bedste praksis for DBA'er er egentlig bare at behandle ReportServer og ReportServerTempDB som enhver anden brugerdatabase.

Der er konfigurationsfiler, der gemmer applikationsindstillinger, som også bør sikkerhedskopieres. Disse kan være dækket af dine sikkerhedskopier på OS-niveau; DBA'er bør dog sørge for, at disse filer sikkerhedskopieres efter den indledende konfiguration og/eller efter at eventuelle brugerdefinerede udvidelser er blevet anvendt. Disse filer består af:

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

Overvejelse for at sikkerhedskopiere dine Report Designer-filer såsom; .rdl, .rds, .dv, .ds, rptproj og .sln filer skal angives.

Indstillingsmuligheder

Tuning af SSRS er meget som enhver anden applikation. Brugere udfører rapporter fra en applikationsserver, der kommunikerer med databaser. Den store forskel er, at du har en applikationsserver (Reporting Services) med egne databaser, men rapporten har datakilder, der forbinder til andre brugerdatabaser. DBA'er skal tune efter den generelle tilstand af Reporting Services-infrastrukturen samt tune de faktiske rapporter.

Infrastruktur for rapporteringstjenester

Disklatens for ReportServer og ReportServerTempDB er meget vigtig. Afhængigt af arbejdsbelastningen skal disse databaser muligvis placeres på hurtigere diske. Caches af rapportresultater gemmes i ReportServerTempDB-databasen, og I/O-ydelse kan blive et problem her.

Reporting Services-arbejdsbyrden kan diktere, at yderligere Reporting Services-instanser er nødvendige for at håndtere denne arbejdsbyrde. En udskaleringsimplementering kræver en Enterprise Edition-licens. Fordelene ved en udskaleringsimplementering omfatter at give kunderne belastningsbalancering for højere gennemløb, høj tilgængelighed samt muligheden for at segmentere rapportserverbehandling.

Udnyt Snapshots, hvor de giver mening. Hvis du har rapporter, der bruger daggamle data, kan du overveje at bruge et øjebliksbillede, så efterfølgende visninger af denne rapport bruger et øjebliksbillede i stedet for at skulle generere hele rapporten igen.

Datadrevne abonnementer kan bruges til at køre rapporter og levere indholdet baseret på abonnentbase og på en tidsplan. Baseret på tidsplanen kan mange af disse rapporter køres efter databehandlingen er fuldført, i god tid før brugerne ankommer på arbejde, i en mindre travl tid for miljøet.

DBA'er bør være fortrolige med eksekveringslogning, da det kan hjælpe med at identificere rapporter, der kunne være kandidater til caching, såvel som rapporter, der bør ses på for at forbedre ydeevnen baseret på eksekveringsbehandling. Eksekveringslogning giver indsigt i ting som, hvor ofte rapporter køres, det mest efterspurgte format og procentdelen af behandlingen, der er knyttet til en fase af rapportprocessen. Disse data kan tilgås ved hjælp af de indbyggede visninger for ExecutionLog, ExecutionLog2 og ExecutionLog3.

Generel indstilling

For de brugerdatabaser, der bruges af rapporterne og den instans, der indeholder ReportServer og ReportServerTempDB, vil du spore og baseline ydeevne. Du skal overvåge hukommelse/disk/CPU-udnyttelse, netværks-I/O, tempdb-brug, ventetider og andre tællere for at vide, hvad der er normalt for den samlede arbejdsbyrde for disse systemer. Hvis brugere begynder at rapportere problemer, skal du være i stand til at vide, om den aktuelle udnyttelse er normal eller ej. Hvis du ikke overvåger det, hvordan kan du så måle det?

Ud over overvågning og baselining bør industriaccepterede bedste praksis for eksempel være på plads. Jeg har dækket hukommelsesindstillinger, indeksvedligeholdelse, statistik, MAXDOP og omkostningstærskel for parallelitet i en tidligere artikel, Common SQL Server Mishaps.

Den virkelige magi til at få rapporter til at køre hurtigere er at optimere til denne rapport. En rapport er i bund og grund blot endnu en forespørgsel. For at tune efter en langsom rapport betyder det normalt, at du skal oprette indekser for den specifikke rapport eller justere koden i rapporten. Hvis disse er rapporter, der rammer OLTP-databasen, kan oprettelse af indekser til rapporter påvirke OLTP-systemet ved at bruge mere plads, generere yderligere I/O til opdateringer, indsættelser og sletninger og pådrage sig yderligere overhead til vedligeholdelse af disse indekser. Du skal balancere risiko vs. belønning. Nogle kunder kan adskille rapporteringsdatabasen fra OLTP ved at bruge transaktionsreplikering, og dette giver mulighed for at indeksere rapporteringsdatabasen uden at påvirke OTLP-databasen.

Selvom du kan spore rapportbrug ved hjælp af ExecutionLog, skal du undersøge brugerdatabaseforekomsten for høje omkostninger og langvarige forespørgsler til tuning-muligheder også. DMV'er og Query Store er også en stor hjælp, men et overvågningsværktøj som SQL Sentry kan være meget mere kraftfuldt og fleksibelt. SQL Sentry har ikke et "Reporting Services-dashboard" i sig selv, men du kan oprette kalendervisninger af SSRS-begivenheder, nemt filtrere indbyggede metrics og rapporter for at fokusere på SSRS-aktivitet og skabe robuste rådgivende betingelser for at overvåge de præcise aspekter af Rapporteringstjenester, du holder af (og ingen af den støj, du ikke gør). Selvom du ikke kører SSRS på en SQL Server-maskine, kan du stadig bruge Win Sentry til at få rig præstationsindsigt i aktuelle og historiske proces- og serviceniveauaktiviteter.

Konklusion

Tuning af SQL Server Reporting Services har flere unikke egenskaber, men standardindstilling af ydeevne er stadig anvendelig til optimering af rapporter og overvågning af ReportServer- og ReportServerTempDB-databaserne. Sikkerhedskopiering af krypteringsnøglen er nødvendig for enhver katastrofegendannelse eller migreringsindsats. For bedre at forstå brugen af rapporter bør DBA'er begynde at bruge ExcecutionLog.