Muitos administradores de banco de dados precisam dar suporte a instâncias do SQL Server Reporting Services (SSRS) ou, pelo menos, aos bancos de dados de back-end necessários para o SSRS. Durante anos, o SSRS foi empacotado com a instalação do SQL Server, o que ajudou a aumentar a confusão em torno do licenciamento e do suporte para o produto, portanto, a partir do SSRS 2017, o pacote de instalação do Reporting Services é um download separado.
Este artigo abordará muitas áreas que os administradores de banco de dados precisam conhecer para licenciar, recuperar e ajustar adequadamente uma instalação do Reporting Services. Esses tópicos se aplicam tanto ao SQL Server Reporting Services quanto ao Power BI Report Server.
Licenciamento
A instalação e o suporte do SSRS podem ser confusos. O serviço de relatório pode ser instalado como uma instância autônoma em um servidor dedicado, na mesma instância do SQL Server ou em uma implantação de expansão (somente Enterprise Edition). Cada instância em que o SSRS está instalado em produção requer uma licença do SQL Server, bem como o licenciamento da instância do SQL Server onde residem os bancos de dados ReportServer e ReportServerTempDB.
A maneira que gosto de explicar como licenciar o Reporting Services é pensar no serviço de relatório como um aplicativo que usa o SQL Server no back-end. Nos primeiros dias do SSRS, um requisito também era instalar e configurar o Internet Information Services (IIS). O SSRS 2008 trouxe esse componente para o módulo de serviço de relatórios. É muito comum ver SSRS e MSSQL instalados na mesma instância devido ao licenciamento e isso pode funcionar bem para implementações menores. Para implantações maiores, é comum ver um servidor de serviço de relatório dedicado com ReportServer e ReportServerTempDB em um SQL Server consolidado. Para instalações muito grandes, as implantações de expansão são usadas para fornecer balanceamento de carga do serviço de servidor de relatório. Em uma implantação em expansão, cada instância no farm deve ser licenciada.
Recuperação
Em cada um dos modelos de implantação, a função do administrador de banco de dados é garantir que o SSRS seja estável, confiável e recuperável. A parte recuperável é algo que causa alguns problemas de DBAs. O banco de dados ReportServer é criptografado e certas operações exigem a restauração da chave simétrica. Se houver uma falha e o banco de dados precisar ser restaurado para outro servidor, o nome ou a senha da conta de serviço do Report Server Windows for alterado, o nome do computador for alterado, você migrar para outro servidor ou adicionar um novo servidor a uma escala. fora da configuração, será necessário restaurar a chave de criptografia. A menos que seja feito backup da chave, quaisquer dados protegidos, como strings de conexão e senhas, não podem ser descriptografados. Descobri que muitos DBAs não sabem disso até que seja tarde demais. A chave pode ser copiada e restaurada manualmente usando o Reporting Services Configuration Manager, usando o utilitário rskeymgmt.exe ou usando o PowerShell. Tecnicamente, você só precisa fazer backup de uma cópia da chave simétrica.
Os bancos de dados ReportServer e ReportServerTempDB são bancos de dados SQL Server e devem fazer parte de um processo de backup regular, assim como outros bancos de dados de usuários. O ReportServer deve usar o modelo de recuperação completo, enquanto o ReportServerTempDB pode usar o modelo de recuperação simples. Tecnicamente, ReportServerTempDB pode ser recriado por um script no caso de um desastre, mas o Reporting Services não pode ser iniciado sem ReportServerTempDB. Os DBAs estão familiarizados com a restauração de bancos de dados, em vez de procurar um script para recriar o banco de dados. Ao contrário do tempdb do banco de dados do sistema, o ReportServerTempDB não é recriado na inicialização. A melhor prática para DBAs é apenas tratar ReportServer e ReportServerTempDB como qualquer outro banco de dados de usuário.
Existem arquivos de configuração que armazenam as configurações do aplicativo que também devem ser submetidas a backup. Eles podem ser cobertos pelos backups no nível do sistema operacional; no entanto, os DBAs devem certificar-se de que é feito backup desses arquivos após a configuração inicial e/ou após a aplicação de quaisquer extensões personalizadas. Esses arquivos consistem em:
- Rsreportserver.config
- Rssvrpolicy.config
- Rsmgrpolicy.config
- Reportingservciesservice.exe.config
- Web.config
- Machine.config
Consideração para fazer backup de seus arquivos do Report Designer, como; Os arquivos .rdl, .rds, .dv, .ds, rptproj e .sln devem ser fornecidos.
Opções de ajuste
O ajuste do SSRS é muito parecido com qualquer outro aplicativo. Os usuários estão executando relatórios de um servidor de aplicativos que está se comunicando com bancos de dados. A grande diferença é que você tem um servidor de aplicativos (Reporting Services) com seus próprios bancos de dados, mas o relatório possui fontes de dados conectando-se a outros bancos de dados de usuários. Os DBAs devem ajustar a integridade geral da infraestrutura do Reporting Services, bem como ajustar os relatórios reais.
Infraestrutura de serviços de relatórios
A latência de disco para ReportServer e ReportServerTempDB são muito importantes. Dependendo da carga de trabalho, esses bancos de dados podem precisar ser colocados em discos mais rápidos. Caches de resultados de relatórios são armazenados no banco de dados ReportServerTempDB e o desempenho de E/S pode se tornar um problema aqui.
A carga de trabalho do Reporting Services pode determinar que instâncias adicionais do Reporting Services sejam necessárias para lidar com essa carga de trabalho. Uma implantação de expansão requer uma licença do Enterprise Edition. Os benefícios de uma implantação escalável incluem oferecer aos clientes balanceamento de carga para maior taxa de transferência, alta disponibilidade, bem como a capacidade de segmentar o processamento do servidor de relatório.
Aproveite os instantâneos onde eles fazem sentido. Se você tiver relatórios que usam dados do dia anterior, considere usar um instantâneo para que as exibições subsequentes desse relatório usem um instantâneo em vez de gerar o relatório inteiro novamente.
Assinaturas orientadas a dados podem ser usadas para executar relatórios e entregar o conteúdo com base na base de assinantes e em uma programação. Com base no cronograma, muitos desses relatórios podem ser executados após a conclusão do processamento de dados, bem antes de os usuários chegarem ao trabalho, em um horário menos movimentado para o ambiente.
Os DBAs devem estar familiarizados com o log de execução, pois isso pode ajudar a identificar relatórios que podem ser candidatos para armazenamento em cache, bem como relatórios que devem ser analisados para melhoria de desempenho com base no processamento de execução. O log de execução fornece informações sobre a frequência com que os relatórios são executados, o formato mais solicitado e a porcentagem de processamento vinculada a uma fase do processo de relatório. Esses dados podem ser acessados usando as visualizações internas para ExecutionLog, ExecutionLog2 e ExecutionLog3.
Ajuste geral
Para os bancos de dados do usuário que estão sendo usados pelos relatórios e a instância que contém o ReportServer e ReportServerTempDB, você deseja acompanhar e basear o desempenho. Você precisa monitorar a utilização de memória/disco/CPU, E/S de rede, uso de tempdb, esperas e outros contadores para saber o que é normal para a carga de trabalho geral desses sistemas. Se os usuários começarem a relatar problemas, você precisa saber se a utilização atual está normal ou não. Se você não está monitorando, como você pode medi-lo?
Além do monitoramento e da linha de base, as melhores práticas aceitas pelo setor devem estar em vigor para a instância. Cobri as configurações de memória, manutenção de índice, estatísticas, MAXDOP e limite de custo para paralelismo em um artigo anterior, Common SQL Server Mishaps.
A verdadeira mágica para tornar os relatórios executados mais rapidamente é otimizar para esse relatório. Um relatório é essencialmente apenas outra consulta. Para ajustar um relatório lento, isso geralmente significa que você precisa criar índices para esse relatório específico ou ajustar o código dentro do relatório. Se forem relatórios que atingem o banco de dados OLTP, a criação de índices para relatórios pode afetar o sistema OLTP usando mais espaço, gerando E/S adicional para atualizações, inserções e exclusões e incorrendo em sobrecarga adicional para manter esses índices. Você deve equilibrar o risco versus recompensa. Alguns clientes podem separar o banco de dados de relatórios do OLTP usando replicação transacional e isso permite indexar o banco de dados de relatórios sem afetar o banco de dados OTLP.
Embora você possa rastrear o uso do relatório usando o ExecutionLog, também precisará pesquisar a instância do banco de dados do usuário para consultas de alto custo e de longa duração para oportunidades de ajuste. DMVs e Query Store também são uma grande ajuda, mas uma ferramenta de monitoramento como o SQL Sentry pode ser muito mais poderosa e flexível. O SQL Sentry não possui um "painel do Reporting Services" por si só, mas você pode criar exibições de calendário de eventos do SSRS, filtrar facilmente métricas e relatórios integrados para se concentrar na atividade do SSRS e criar condições de consultoria robustas para monitorar os aspectos precisos de Reporting Services com os quais você se importa (e nenhum barulho que você não gosta). Mesmo se você não estiver executando o SSRS em uma máquina SQL Server, ainda poderá usar o Win Sentry para obter insights de desempenho avançados sobre o processo atual e histórico e a atividade de nível de serviço.
Conclusão
O ajuste do SQL Server Reporting Services tem várias características exclusivas, no entanto, o ajuste de desempenho padrão ainda é aplicável para otimizar relatórios e monitorar os bancos de dados ReportServer e ReportServerTempDB. Fazer backup da chave de criptografia é necessário para qualquer esforço de migração ou recuperação de desastres. Para entender melhor o uso de relatórios, os DBAs devem começar a usar o ExecutionLog.
