De nombreux administrateurs de bases de données doivent prendre en charge des instances de SQL Server Reporting Services (SSRS), ou au moins les bases de données principales requises pour SSRS. Pendant des années, SSRS a été fourni avec l'installation de SQL Server, ce qui a contribué à ajouter à la confusion autour des licences et de la prise en charge du produit. Ainsi, à partir de SSRS 2017, le package d'installation de Reporting Services est un téléchargement séparé.
Cet article couvrira de nombreux domaines que les administrateurs de base de données doivent connaître pour autoriser, récupérer et régler correctement une installation de Reporting Services. Ces rubriques s'appliquent à la fois à SQL Server Reporting Services et à Power BI Report Server.
Licence
L'installation et la prise en charge de SSRS peuvent prêter à confusion. Le service de création de rapports peut être installé en tant qu'instance autonome sur un serveur dédié, sur la même instance que SQL Server ou dans un déploiement évolutif (Enterprise Edition uniquement). Chaque instance où SSRS est installé en production nécessite une licence SQL Server, ainsi qu'une licence pour l'instance de SQL Server où résident les bases de données ReportServer et ReportServerTempDB.
La façon dont j'aime expliquer comment attribuer une licence à Reporting Services consiste à considérer le service de création de rapports comme une application qui utilise SQL Server en arrière-plan. Au début de SSRS, une exigence était également d'installer et de configurer Internet Information Services (IIS). SSRS 2008 a introduit ce composant dans le module de service de rapport. Il est très courant de voir SSRS et MSSQL installés sur la même instance en raison de la licence et cela peut bien fonctionner pour les petites implémentations. Pour les déploiements plus importants, il est courant de voir un serveur de service de création de rapports dédié avec ReportServer et ReportServerTempDB sur un serveur SQL consolidé. Pour les très grandes installations, les déploiements évolutifs sont utilisés pour assurer l'équilibrage de charge du service de serveur de rapports. Dans un déploiement évolutif, chaque instance de la batterie doit être sous licence.
Récupération
Dans chacun des modèles de déploiement, le rôle de l'administrateur de base de données est de s'assurer que SSRS est stable, fiable et récupérable. La partie récupérable est quelque chose qui cause des problèmes de DBA. La base de données ReportServer est cryptée et certaines opérations nécessitent la restauration de la clé symétrique. S'il y a une panne et que la base de données doit être restaurée sur un autre serveur, le nom ou le mot de passe du compte de service Report Server Windows est modifié, le nom de l'ordinateur est modifié, vous migrez vers un autre serveur ou vous ajoutez un nouveau serveur à une balance. out configuration, vous devrez restaurer la clé de chiffrement. À moins que la clé ne soit sauvegardée, toutes les données protégées, telles que les chaînes de connexion et les mots de passe, ne peuvent pas être déchiffrées. J'ai constaté que de nombreux DBA n'en sont pas conscients jusqu'à ce qu'il soit trop tard. La clé peut être sauvegardée et restaurée manuellement à l'aide du gestionnaire de configuration de Reporting Services, de l'utilitaire rskeymgmt.exe ou de PowerShell. Techniquement, vous n'avez besoin de sauvegarder qu'une seule copie de la clé symétrique.
Les bases de données ReportServer et ReportServerTempDB sont des bases de données SQL Server et doivent faire partie d'un processus de sauvegarde régulier, tout comme les autres bases de données utilisateur. ReportServer doit utiliser le modèle de récupération complète tandis que ReportServerTempDB peut utiliser le modèle de récupération simple. Techniquement, ReportServerTempDB peut être recréé par un script en cas de sinistre, mais Reporting Services ne peut pas démarrer sans ReportServerTempDB. Les administrateurs de bases de données sont habitués à restaurer des bases de données, plutôt qu'à rechercher un script pour recréer la base de données. Contrairement à la base de données système tempdb, ReportServerTempDB n'est pas recréé au démarrage. La meilleure pratique pour les administrateurs de bases de données consiste à traiter simplement ReportServer et ReportServerTempDB comme n'importe quelle autre base de données utilisateur.
Il existe des fichiers de configuration qui stockent les paramètres d'application qui doivent également être sauvegardés. Ceux-ci peuvent être couverts par vos sauvegardes au niveau du système d'exploitation ; cependant, les administrateurs de base de données doivent s'assurer que ces fichiers sont sauvegardés après la configuration initiale et/ou après l'application de toute extension personnalisée. Ces fichiers sont constitués de :
- Rsreportserver.config
- Rssvrpolicy.config
- Rsmgrpolicy.config
- Reportingservciesservice.exe.config
- Web.config
- Machine.config
Considération pour la sauvegarde de vos fichiers Report Designer tels que; Les fichiers .rdl, .rds, .dv, .ds, rptproj et .sln doivent être fournis.
Options de réglage
Le réglage de SSRS ressemble à n'importe quelle autre application. Les utilisateurs exécutent des rapports à partir d'un serveur d'applications qui communique avec des bases de données. La grande différence est que vous avez un serveur d'applications (Reporting Services) avec ses propres bases de données, mais le rapport a des sources de données se connectant à d'autres bases de données utilisateur. Les administrateurs de base de données doivent s'adapter à l'intégrité globale de l'infrastructure Reporting Services, ainsi qu'aux rapports réels.
Infrastructure des services de création de rapports
La latence du disque pour ReportServer et ReportServerTempDB est très importante. Selon la charge de travail, ces bases de données peuvent devoir être placées sur des disques plus rapides. Les caches des résultats des rapports sont stockés dans la base de données ReportServerTempDB et les performances d'E/S peuvent devenir un problème ici.
La charge de travail de Reporting Services peut dicter que des instances Reporting Services supplémentaires sont nécessaires pour gérer cette charge de travail. Un déploiement scale-out nécessite une licence Enterprise Edition. Les avantages d'un déploiement évolutif incluent l'équilibrage de charge des clients pour un débit plus élevé, une haute disponibilité, ainsi que la possibilité de segmenter le traitement du serveur de rapports.
Tirez parti des instantanés là où ils ont du sens. Si vous avez des rapports qui utilisent des données d'un jour, envisagez d'utiliser un instantané afin que les vues suivantes de ce rapport utilisent un instantané plutôt que d'avoir à générer à nouveau l'intégralité du rapport.
Les abonnements basés sur les données peuvent être utilisés pour exécuter des rapports et fournir le contenu en fonction de la base d'abonnés et selon un calendrier. En fonction du calendrier, bon nombre de ces rapports peuvent être exécutés une fois le traitement des données terminé, bien avant que les utilisateurs n'arrivent au travail, à une période moins chargée pour l'environnement.
Les administrateurs de base de données doivent être familiarisés avec la journalisation des exécutions, car cela peut aider à identifier les rapports qui pourraient être candidats à la mise en cache ainsi que les rapports qui doivent être examinés pour améliorer les performances en fonction du traitement de l'exécution. La journalisation des exécutions fournit des informations sur des éléments tels que la fréquence d'exécution des rapports, le format le plus demandé et le pourcentage de traitement lié à une phase du processus de rapport. Ces données sont accessibles à l'aide des vues intégrées pour ExecutionLog, ExecutionLog2 et ExecutionLog3.
Réglage général
Pour les bases de données utilisateur utilisées par les rapports et l'instance contenant ReportServer et ReportServerTempDB, vous souhaitez suivre et référencer les performances. Vous devez surveiller l'utilisation de la mémoire/du disque/du processeur, les E/S réseau, l'utilisation de tempdb, les attentes et d'autres compteurs pour savoir ce qui est normal pour la charge de travail globale de ces systèmes. Si les utilisateurs commencent à signaler des problèmes, vous devez être en mesure de savoir si l'utilisation actuelle est normale ou non. Si vous ne le surveillez pas, comment pouvez-vous le mesurer ?
En plus de la surveillance et de l'établissement de références, les meilleures pratiques acceptées par l'industrie doivent être en place pour l'instance. J'ai couvert les paramètres de mémoire, la maintenance des index, les statistiques, MAXDOP et le seuil de coût pour le parallélisme dans un article précédent, Common SQL Server Mishaps.
La vraie magie pour rendre les rapports plus rapides est d'optimiser pour ce rapport. Un rapport est essentiellement juste une autre requête. Pour régler un rapport lent, cela signifie généralement que vous devez créer des index pour ce rapport spécifique ou régler le code dans le rapport. S'il s'agit de rapports qui accèdent à la base de données OLTP, la création d'index pour les rapports peut avoir un impact sur le système OLTP en utilisant plus d'espace, en générant des E/S supplémentaires pour les mises à jour, les insertions et les suppressions, et en entraînant une surcharge supplémentaire pour la maintenance de ces index. Vous devez équilibrer le risque par rapport à la récompense. Certains clients peuvent séparer la base de données de rapports de l'OLTP en utilisant la réplication transactionnelle, ce qui permet d'indexer la base de données de rapports sans affecter la base de données OTLP.
Bien que vous puissiez suivre l'utilisation des rapports à l'aide de ExecutionLog, vous devrez également rechercher dans l'instance de base de données utilisateur des requêtes coûteuses et longues pour les opportunités de réglage. Les DMV et Query Store sont également d'une grande aide, mais un outil de surveillance comme SQL Sentry peut être beaucoup plus puissant et flexible. SQL Sentry n'a pas de "tableau de bord Reporting Services" en soi, mais vous pouvez créer des vues de calendrier des événements SSRS, filtrer facilement les métriques et les rapports intégrés pour vous concentrer sur l'activité SSRS et créer des conditions consultatives robustes pour surveiller les aspects précis de Reporting Services dont vous vous souciez (et aucun du bruit que vous n'avez pas). Même si vous n'exécutez pas SSRS sur une machine SQL Server, vous pouvez toujours utiliser Win Sentry pour obtenir des informations détaillées sur les performances de l'activité actuelle et historique au niveau des processus et des services.
Conclusion
Le réglage de SQL Server Reporting Services présente plusieurs caractéristiques uniques, mais le réglage des performances standard est toujours applicable pour l'optimisation des rapports et la surveillance des bases de données ReportServer et ReportServerTempDB. La sauvegarde de la clé de chiffrement est nécessaire pour tout effort de reprise après sinistre ou de migration. Pour mieux comprendre l'utilisation des rapports, les DBA doivent commencer à utiliser ExecutionLog.
