Molti amministratori di database si trovano a dover supportare le istanze di SQL Server Reporting Services (SSRS) o almeno i database back-end necessari per SSRS. Per anni SSRS è stato fornito in bundle con l'installazione di SQL Server, il che ha contribuito ad aggiungere un po' di confusione in merito alle licenze e al supporto per il prodotto, quindi a partire da SSRS 2017, il pacchetto di installazione per Reporting Services è un download separato.
Questo articolo tratterà molte aree di cui gli amministratori di database devono essere a conoscenza per ottenere la licenza, ripristinare e ottimizzare correttamente un'installazione di Reporting Services. Questi argomenti si applicano sia a SQL Server Reporting Services che a Power BI Report Server.
Licenza
L'installazione e il supporto di SSRS possono creare confusione. Il servizio di creazione rapporti può essere installato come istanza autonoma in un server dedicato, nella stessa istanza di SQL Server o in una distribuzione con scalabilità orizzontale (solo Enterprise Edition). Ogni istanza in cui SSRS è installato in produzione richiede una licenza di SQL Server, oltre alla licenza dell'istanza di SQL Server in cui risiedono i database ReportServer e ReportServerTempDB.
Il modo in cui mi piace spiegare come concedere in licenza Reporting Services è pensare al servizio di reporting come a un'applicazione che utilizza SQL Server sul back-end. Agli albori di SSRS, un requisito era anche installare e configurare Internet Information Services (IIS). SSRS 2008 ha portato tale componente nel modulo del servizio di reporting. È molto comune vedere SSRS e MSSQL installati sulla stessa istanza a causa delle licenze e questo può funzionare bene per implementazioni più piccole. Per distribuzioni più grandi, è comune vedere un server del servizio di creazione rapporti dedicato con ReportServer e ReportServerTempDB su un SQL Server consolidato. Per installazioni di grandi dimensioni, le distribuzioni con scalabilità orizzontale vengono utilizzate per fornire il bilanciamento del carico del servizio del server di report. In una distribuzione con scalabilità orizzontale, ogni istanza nella farm deve essere concessa in licenza.
Recupero
In ciascuno dei modelli di distribuzione, il ruolo dell'amministratore del database è assicurarsi che SSRS sia stabile, affidabile e ripristinabile. La parte recuperabile è qualcosa che causa alcuni problemi con i DBA. Il database ReportServer è crittografato e alcune operazioni richiedono il ripristino della chiave simmetrica. Se si verifica un errore e il database deve essere ripristinato su un altro server, il nome dell'account del servizio Windows del server di report o la password vengono modificati, il nome del computer viene modificato, si esegue la migrazione a un altro server o si aggiunge un nuovo server a una scalabilità. fuori configurazione, ti verrà richiesto di ripristinare la chiave di crittografia. A meno che non venga eseguito il backup della chiave, i dati protetti, come le stringhe di connessione e le password, non possono essere decrittografati. Ho scoperto che molti DBA non ne sono consapevoli finché non è troppo tardi. È possibile eseguire il backup e il ripristino manuale della chiave utilizzando Gestione configurazione Reporting Services, l'utilità rskeymgmt.exe o PowerShell. Tecnicamente devi solo eseguire il backup di una copia della chiave simmetrica.
I database ReportServer e ReportServerTempDB sono database di SQL Server e dovrebbero far parte di un normale processo di backup, proprio come altri database utente. ReportServer dovrebbe utilizzare il modello di ripristino completo mentre ReportServerTempDB può utilizzare il modello di ripristino semplice. Tecnicamente, ReportServerTempDB può essere ricreato da uno script in caso di emergenza, tuttavia Reporting Services non può essere avviato senza ReportServerTempDB. I DBA hanno familiarità con il ripristino dei database, piuttosto che con la ricerca di uno script per ricreare il database. A differenza del database tempdb di sistema, ReportServerTempDB non viene ricreato all'avvio. La migliore pratica per i DBA consiste nel trattare semplicemente ReportServer e ReportServerTempDB come qualsiasi altro database utente.
Esistono file di configurazione che memorizzano le impostazioni dell'applicazione di cui è necessario eseguire il backup. Questi possono essere coperti dai backup a livello di sistema operativo; tuttavia, i DBA devono assicurarsi che venga eseguito il backup di questi file dopo la configurazione iniziale e/o dopo l'applicazione di eventuali estensioni personalizzate. Questi file sono costituiti da:
- Rsreportserver.config
- Rssvrpolicy.config
- Rsmgrpolicy.config
- Reportingservciesservice.exe.config
- Web.config
- Machine.config
Considerazione per il backup dei file di Report Designer come; Devono essere forniti i file .rdl, .rds, .dv, .ds, rptproj e .sln.
Opzioni di ottimizzazione
L'ottimizzazione di SSRS è molto simile a qualsiasi altra applicazione. Gli utenti stanno eseguendo report da un server delle applicazioni che sta comunicando con i database. La grande differenza è che si dispone di un server delle applicazioni (Reporting Services) con i propri database, ma il report ha origini dati che si connettono ad altri database utente. I DBA devono ottimizzare l'integrità generale dell'infrastruttura di Reporting Services e ottimizzare i report effettivi.
Infrastruttura dei servizi di reporting
La latenza del disco per ReportServer e ReportServerTempDB è molto importante. A seconda del carico di lavoro, potrebbe essere necessario posizionare tali database su dischi più veloci. Le cache dei risultati dei report sono archiviate nel database ReportServerTempDB e le prestazioni di I/O possono diventare un problema qui.
Il carico di lavoro di Reporting Services potrebbe imporre la necessità di ulteriori istanze di Reporting Services per gestire tale carico di lavoro. Una distribuzione con scalabilità orizzontale richiede una licenza Enterprise Edition. I vantaggi di un'implementazione con scalabilità orizzontale includono il bilanciamento del carico dei clienti per un throughput più elevato, un'elevata disponibilità e la possibilità di segmentare l'elaborazione del server di report.
Approfitta delle istantanee dove hanno senso. Se disponi di rapporti che utilizzano dati vecchi di un giorno, considera l'utilizzo di un'istantanea in modo che le visualizzazioni successive di tale rapporto utilizzino un'istantanea anziché dover generare nuovamente l'intero rapporto.
Le sottoscrizioni basate sui dati possono essere utilizzate per eseguire report e fornire il contenuto in base alla base di abbonati e in base a una pianificazione. In base alla pianificazione, molti di questi rapporti possono essere eseguiti al termine dell'elaborazione dei dati, molto prima che gli utenti arrivino al lavoro, in un momento meno intenso per l'ambiente.
I DBA dovrebbero avere familiarità con la registrazione dell'esecuzione in quanto ciò può aiutare a identificare i report che potrebbero essere candidati per la memorizzazione nella cache, nonché i report che dovrebbero essere esaminati per il miglioramento delle prestazioni in base all'elaborazione dell'esecuzione. La registrazione dell'esecuzione fornisce informazioni dettagliate su aspetti quali la frequenza di esecuzione dei report, il formato più richiesto e la percentuale di elaborazione legata a una fase del processo di report. È possibile accedere a questi dati utilizzando le viste integrate per ExecutionLog, ExecutionLog2 ed ExecutionLog3.
Regolazione generale
Per i database utente utilizzati dai report e dall'istanza che contiene ReportServer e ReportServerTempDB, si desidera monitorare e basare le prestazioni. È necessario monitorare l'utilizzo di memoria/disco/CPU, I/O di rete, utilizzo di tempdb, attese e altri contatori per sapere cosa è normale per il carico di lavoro complessivo di tali sistemi. Se gli utenti iniziano a segnalare problemi, è necessario essere in grado di sapere se l'utilizzo corrente è normale o meno. Se non lo stai monitorando, come puoi misurarlo?
Oltre al monitoraggio e alla baseline, per l'istanza dovrebbero essere messe in atto le migliori pratiche accettate dal settore. Ho trattato le impostazioni della memoria, la manutenzione dell'indice, le statistiche, il MAXDOP e la soglia dei costi per il parallelismo in un articolo precedente, Errori comuni di SQL Server.
La vera magia per rendere più veloci i rapporti è ottimizzare per quel rapporto. Un report è essenzialmente solo un'altra query. Per ottimizzare un report lento, ciò in genere significa che è necessario creare indici per quel report specifico o ottimizzare il codice all'interno del report. Se si tratta di report che stanno raggiungendo il database OLTP, la creazione di indici per i report può influire sul sistema OLTP utilizzando più spazio, generando ulteriori operazioni di I/O per aggiornamenti, inserimenti ed eliminazioni e comportando un sovraccarico aggiuntivo per la gestione di tali indici. Devi bilanciare il rischio e la ricompensa. Alcuni clienti possono separare il database dei rapporti dall'OLTP utilizzando la replica transazionale e ciò consente di indicizzare il database dei rapporti senza influire sul database OTLP.
Sebbene tu possa tenere traccia dell'utilizzo dei rapporti utilizzando ExecutionLog, dovrai ricercare l'istanza del database utente per query a costo elevato e di lunga durata anche per opportunità di ottimizzazione. Anche DMV e Query Store sono di grande aiuto, ma uno strumento di monitoraggio come SQL Sentry può essere molto più potente e flessibile. SQL Sentry non dispone di un "dashboard di Reporting Services" di per sé, ma puoi creare visualizzazioni del calendario degli eventi SSRS, filtrare facilmente le metriche e i report incorporati per concentrarti sull'attività SSRS e creare solide condizioni di avviso per monitorare gli aspetti precisi di Reporting Servizi a cui tieni (e nessuno dei rumori che non ti interessa). Anche se non stai eseguendo SSRS su una macchina SQL Server, puoi comunque usare Win Sentry per ottenere informazioni dettagliate sulle prestazioni nell'attività corrente e cronologica a livello di processo e servizio.
Conclusione
L'ottimizzazione di SQL Server Reporting Services presenta diverse caratteristiche univoche, tuttavia l'ottimizzazione delle prestazioni standard è ancora applicabile per l'ottimizzazione dei report e il monitoraggio dei database ReportServer e ReportServerTempDB. Il backup della chiave di crittografia è necessario per qualsiasi operazione di ripristino di emergenza o migrazione. Per comprendere meglio l'utilizzo dei report, i DBA dovrebbero iniziare a utilizzare ExcecutionLog.
