Muchos administradores de bases de datos se ven obligados a admitir instancias de SQL Server Reporting Services (SSRS), o al menos las bases de datos de back-end que se requieren para SSRS. Durante años, SSRS se incluyó con la instalación de SQL Server, lo que ayudó a aumentar parte de la confusión sobre las licencias y el soporte para el producto, por lo que, a partir de SSRS 2017, el paquete de instalación de Reporting Services es una descarga independiente.
Este artículo cubrirá muchas áreas que los administradores de bases de datos deben conocer para otorgar licencias, recuperar y ajustar correctamente una instalación de Reporting Services. Estos temas se aplican tanto a SQL Server Reporting Services como a Power BI Report Server.
Licencias
La instalación y el soporte de SSRS pueden ser confusos. El servicio de informes se puede instalar como una instancia independiente en un servidor dedicado, en la misma instancia que SQL Server o en una implementación escalada (solo Enterprise Edition). Cada instancia donde se instala SSRS en producción requiere una licencia de SQL Server, así como la licencia de la instancia de SQL Server donde residen las bases de datos ReportServer y ReportServerTempDB.
La forma en que me gusta explicar cómo obtener una licencia de Reporting Services es pensar en el servicio de informes como una aplicación que usa SQL Server en el back-end. En los primeros días de SSRS, un requisito también era instalar y configurar Internet Information Services (IIS). SSRS 2008 incorporó ese componente al módulo de servicio de informes. Es muy común ver SSRS y MSSQL instalados en la misma instancia debido a la licencia y esto puede funcionar bien para implementaciones más pequeñas. Para implementaciones más grandes, es común ver un servidor de servicio de informes dedicado con ReportServer y ReportServerTempDB en un SQL Server consolidado. Para instalaciones muy grandes, se utilizan implementaciones de escalamiento horizontal para proporcionar equilibrio de carga del servicio del servidor de informes. En una implementación escalada, cada instancia en la granja debe tener una licencia.
Recuperación
En cada uno de los modelos de implementación, el rol del administrador de la base de datos es asegurarse de que SSRS sea estable, confiable y recuperable. La parte recuperable es algo que causa algunos problemas de DBA. La base de datos de ReportServer está encriptada y ciertas operaciones requieren restaurar la clave simétrica. Si hay una falla y la base de datos debe restaurarse en otro servidor, se cambia el nombre o la contraseña de la cuenta de servicio de Windows del servidor de informes, se cambia el nombre de la computadora, se migra a otro servidor o se agrega un nuevo servidor a una báscula. fuera de la configuración, se le pedirá que restaure la clave de cifrado. A menos que se haga una copia de seguridad de la clave, los datos protegidos, como las cadenas de conexión y las contraseñas, no se pueden descifrar. Descubrí que muchos DBA no se dan cuenta de esto hasta que es demasiado tarde. La clave se puede respaldar y restaurar manualmente usando el Administrador de configuración de Reporting Services, usando la utilidad rskeymgmt.exe o usando PowerShell. Técnicamente, solo necesita hacer una copia de seguridad de una copia de la clave simétrica.
Las bases de datos ReportServer y ReportServerTempDB son bases de datos de SQL Server y deben formar parte de un proceso de copia de seguridad regular, al igual que otras bases de datos de usuarios. ReportServer debe usar el modelo de recuperación completa, mientras que ReportServerTempDB puede usar el modelo de recuperación simple. Técnicamente, un script puede recrear ReportServerTempDB en caso de desastre; sin embargo, Reporting Services no puede iniciarse sin ReportServerTempDB. Los DBA están familiarizados con la restauración de bases de datos, en lugar de buscar un script para recrear la base de datos. A diferencia de la base de datos del sistema tempdb, ReportServerTempDB no se vuelve a crear al inicio. La mejor práctica para los administradores de bases de datos es simplemente tratar ReportServer y ReportServerTempDB como cualquier otra base de datos de usuario.
Hay archivos de configuración que almacenan la configuración de la aplicación de los que también se debe hacer una copia de seguridad. Estos pueden estar cubiertos por sus copias de seguridad a nivel de sistema operativo; sin embargo, los DBA deben asegurarse de que se realice una copia de seguridad de estos archivos después de la configuración inicial y/o después de aplicar cualquier extensión personalizada. Estos archivos consisten en:
- Rsreportserver.config
- Rssvrpolicy.config
- Rsmgrpolicy.config
- Reportingservciesservice.exe.config
- Web.config
- Máquina.config
Consideración para hacer una copia de seguridad de sus archivos de Report Designer, como; Se deben proporcionar archivos .rdl, .rds, .dv, .ds, rptproj y .sln.
Opciones de sintonización
Tuning SSRS es muy parecido a cualquier otra aplicación. Los usuarios ejecutan informes desde un servidor de aplicaciones que se comunica con las bases de datos. La gran diferencia es que tiene un servidor de aplicaciones (Reporting Services) con sus propias bases de datos, pero el informe tiene fuentes de datos que se conectan a otras bases de datos de usuarios. Los administradores de bases de datos deben ajustar el estado general de la infraestructura de Reporting Services, así como ajustar los informes reales.
Infraestructura de servicios de informes
La latencia de disco para ReportServer y ReportServerTempDB es muy importante. Dependiendo de la carga de trabajo, es posible que esas bases de datos deban colocarse en discos más rápidos. Las cachés de los resultados de los informes se almacenan en la base de datos ReportServerTempDB y el rendimiento de E/S puede convertirse en un problema aquí.
La carga de trabajo de Reporting Services puede dictar que se necesiten instancias adicionales de Reporting Services para manejar esa carga de trabajo. Una implementación escalada requiere una licencia de Enterprise Edition. Los beneficios de una implementación escalable incluyen brindar a los clientes equilibrio de carga para un mayor rendimiento, alta disponibilidad, así como la capacidad de segmentar el procesamiento del servidor de informes.
Aproveche las instantáneas donde tengan sentido. Si tiene informes que usan datos del día anterior, considere usar una instantánea para que las vistas posteriores de ese informe usen una instantánea en lugar de tener que generar todo el informe nuevamente.
Las suscripciones controladas por datos se pueden usar para ejecutar informes y entregar el contenido según la base de suscriptores y según un cronograma. Según la programación, muchos de estos informes se pueden ejecutar después de que se complete el procesamiento de datos, mucho antes de que los usuarios lleguen al trabajo, en un momento menos ocupado para el medio ambiente.
Los administradores de bases de datos deben estar familiarizados con el registro de ejecución, ya que puede ayudar a identificar informes que podrían ser candidatos para el almacenamiento en caché, así como informes que deben analizarse para mejorar el rendimiento en función del procesamiento de ejecución. El registro de ejecución proporciona información sobre cosas como la frecuencia con la que se ejecutan los informes, el formato más solicitado y el porcentaje de procesamiento vinculado a una fase del proceso del informe. Se puede acceder a estos datos mediante las vistas integradas para ExecutionLog, ExecutionLog2 y ExecutionLog3.
Afinación general
Para las bases de datos de usuario que utilizan los informes y la instancia que contiene ReportServer y ReportServerTempDB, desea realizar un seguimiento y una referencia del rendimiento. Debe monitorear la utilización de memoria/disco/CPU, E/S de red, uso de tempdb, esperas y otros contadores para saber qué es normal para la carga de trabajo general de esos sistemas. Si los usuarios comienzan a informar problemas, debe poder saber si la utilización actual es normal o no. Si no lo está monitoreando, ¿cómo puede medirlo?
Además del monitoreo y la línea de base, se deben implementar las mejores prácticas aceptadas por la industria para la instancia. He cubierto la configuración de la memoria, el mantenimiento de índices, las estadísticas, MAXDOP y el umbral de costo para el paralelismo en un artículo anterior, Contratiempos comunes de SQL Server.
La verdadera magia para hacer que los informes se ejecuten más rápido es optimizar para ese informe. Un informe es esencialmente una consulta más. Para ajustar un informe lento, eso generalmente significa que necesita crear índices para ese informe específico o ajustar el código dentro del informe. Si se trata de informes que llegan a la base de datos de OLTP, la creación de índices para informes puede afectar al sistema OLTP al utilizar más espacio, generar E/S adicionales para actualizaciones, inserciones y eliminaciones, e incurrir en una sobrecarga adicional para mantener esos índices. Debe equilibrar el riesgo frente a la recompensa. Algunos clientes pueden separar la base de datos de informes de OLTP mediante la replicación transaccional y esto permite indexar la base de datos de informes sin afectar la base de datos de OTLP.
Si bien puede realizar un seguimiento del uso de informes mediante ExecutionLog, también deberá investigar la instancia de la base de datos de usuario en busca de consultas de alto costo y ejecución prolongada para oportunidades de ajuste. Los DMV y Query Store también son de gran ayuda, pero una herramienta de monitoreo como SQL Sentry puede ser mucho más poderosa y flexible. SQL Sentry no tiene un "panel de servicios de informes" per se, pero puede crear vistas de calendario de eventos de SSRS, filtrar fácilmente métricas e informes integrados para centrarse en la actividad de SSRS y crear condiciones de asesoramiento sólidas para monitorear los aspectos precisos de Informes de los servicios que le interesan (y nada del ruido que no le importa). Incluso si no está ejecutando SSRS en una máquina con SQL Server, aún puede usar Win Sentry para obtener información valiosa sobre el rendimiento de la actividad de nivel de servicio y proceso actual e histórica.
Conclusión
La optimización de SQL Server Reporting Services tiene varias características únicas; sin embargo, la optimización del rendimiento estándar sigue siendo aplicable para optimizar los informes y monitorear las bases de datos ReportServer y ReportServerTempDB. La copia de seguridad de la clave de cifrado es necesaria para cualquier esfuerzo de migración o recuperación ante desastres. Para comprender mejor el uso de los informes, los administradores de bases de datos deben comenzar a utilizar ExcecutionLog.
