Partilhar via

Reporting Services com grupos de disponibilidade Always On (SQL Server)

Aplica-se a:SQL Server

Este artigo contém informações sobre como configurar o Reporting Services para trabalhar com grupos de disponibilidade Always On (AG) no SQL Server. Os três cenários para usar o Reporting Services e grupos de disponibilidade Always On são bases de dados para fontes de dados de relatórios, bases de dados de servidor de relatórios e conceção de relatórios. A funcionalidade suportada e a configuração necessária são diferentes para os três cenários.

Um dos principais benefícios de usar Always On availability groups com fontes de dados do Reporting Services é utilizar réplicas secundárias legíveis como fonte de dados de relatórios enquanto estas réplicas secundárias fornecem um failover para uma base de dados primária.

Para obter informações gerais sobre grupos de disponibilidade Always On, consulte Perguntas frequentes sobre Always On para SQL Server 2012 (.. /.. /.. /sql-server/index.yml).

Requisitos para utilizar o Reporting Services e os Grupos de Disponibilidade Always On

O SQL Server Reporting Services e o Servidor de Relatório do Power BI usam o .NET Framework 4.0 e oferecem suporte a propriedades de cadeia de conexão de grupos de disponibilidade Always On para uso com fontes de dados.

Para usar grupos de disponibilidade Always On com o Reporting Services 2014 e versões anteriores, você precisa baixar e instalar um hotfix para o .NET 3.5 SP1. O hotfix adiciona suporte ao SQL Client para recursos AG e suporte às propriedades da cadeia de conexão ApplicationIntent e MultiSubnetFailover. Se o Hotfix não estiver instalado em cada computador que hospeda um servidor de relatório, os usuários que tentarem visualizar relatórios verão uma mensagem de erro semelhante à seguinte e a mensagem de erro será gravada no log de rastreamento do servidor de relatório:

Mensagem de erro: "Palavra-chave não suportada 'applicationintent'"

A mensagem ocorre quando você inclui uma das propriedades dos grupos de disponibilidade Always On na cadeia de conexão do Reporting Services, mas o servidor não reconhece a propriedade. A mensagem de erro observada é vista quando você seleciona o botão 'Testar conexão' nas interfaces de usuário do Reporting Services e quando visualiza o relatório se erros remotos estiverem habilitados nos servidores de relatório.

Para obter mais informações sobre o hotfix necessário, consulte KB 2654347A hotfix introduz suporte para os recursos Always On do SQL Server 2012 para o .NET Framework 3.5 SP1.

Para obter informações sobre outros requisitos de grupos de disponibilidade Always On, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On (SQL Server).

Observação

Não há suporte para arquivos de configuração do Reporting Services, como RSreportserver.config como parte da funcionalidade de grupos de disponibilidade Always On. Se você fizer alterações manualmente em um arquivo de configuração em um dos servidores de relatório, precisará atualizar manualmente as réplicas.

Fontes de dados de relatório e grupos de disponibilidade

O comportamento das fontes de dados do Reporting Services com base em grupos de disponibilidade Always On pode variar dependendo de como o administrador configurou o ambiente AG.

Para utilizar grupos de disponibilidade Always On para fontes de dados de relatório, é preciso configurar a cadeia de conexão da fonte de dados do relatório para usar o nome DNS do ouvinte do grupo de disponibilidade. As fontes de dados suportadas são as seguintes:

  • Fonte de dados ODBC usando o SQL Native Client.

  • SQL Client, com o hotfix .NET aplicado ao servidor de relatório.

A cadeia de conexão também pode conter novas propriedades de conexão Always On que configuram as solicitações de consulta de relatórios para utilizar a réplica secundária em relatórios de leitura apenas. O uso de réplica secundária para requisições de relatório reduz a carga em uma réplica primária de leitura-escrita. A ilustração a seguir é um exemplo de uma configuração AG de três réplicas em que as cadeias de conexão da fonte de dados do Reporting Services foram configuradas com ApplicationIntent=ReadOnly. Neste exemplo, as solicitações de consulta de relatório são enviadas para uma réplica secundária e não para a réplica primária.

Segue-se um exemplo de cadeia de ligação, em que [AvailabilityGroupListenerName] é o Nome DNS do Ouvinte que foi configurado quando as réplicas foram criadas:

Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2022; ApplicationIntent=ReadOnly

O botão Testar Conexão nas interfaces de usuário do Reporting Services valida se uma conexão pode ser estabelecida, mas não validará a configuração AG. Por exemplo, se você incluir ApplicationIntent em uma cadeia de conexão para um servidor que não faz parte do AG, o parâmetro extra será ignorado e o botão Test Connection só validará uma conexão que pode ser estabelecida com o servidor especificado.

Dependendo de como os seus relatórios são criados e publicados, isso irá determinar o local onde se edita a cadeia de conexão.

  • Modo nativo: Use o portal da Web para fontes de dados compartilhadas e relatórios que já estão publicados em um servidor de relatório de modo nativo.

  • Modo do SharePoint: Use as páginas de configuração do SharePoint dentro das bibliotecas de documentos para relatórios que já foram publicados em um servidor do SharePoint.

  • Design do relatório: Construtor de Relatórios ou SSDT (SQL Server Data Tools) ao criar novos relatórios. Consulte a seção 'Design do relatório' neste artigo ou mais informações.

Recursos Adicionais:

Considerações: As réplicas secundárias normalmente sofrem um atraso no recebimento de alterações de dados da réplica primária. Os seguintes fatores podem afetar a latência de atualização entre as réplicas primária e secundária:

  • O número de réplicas secundárias. O atraso aumenta a cada réplica secundária adicionada à configuração.

  • Localização geográfica e distância entre as réplicas primária e secundária. Por exemplo, o atraso normalmente é maior se as réplicas secundárias estiverem em um data center diferente do que se estivessem no mesmo prédio da réplica primária.

  • Configuração do modo de disponibilidade para cada réplica. O modo de disponibilidade determina se a réplica primária aguarda para confirmar transações em um banco de dados até que uma réplica secundária tenha gravado a transação no disco. Para obter mais informações, consulte a seção 'Modos de disponibilidade' de Visão geral de grupos de disponibilidade Always On (SQL Server).

Ao usar um secundário somente leitura como fonte de dados do Reporting Services, é importante garantir que o tempo de atualização dos dados atenda às necessidades dos utilizadores do relatório.

Design de relatórios e grupos de disponibilidade

Ao criar relatórios no Construtor de Relatórios ou um projeto de relatório no SSDT (SQL Server Data Tools), um usuário pode configurar uma cadeia de conexão de fonte de dados de relatório para conter novas propriedades de conexão fornecidas por grupos de disponibilidade Always On. O suporte para as novas propriedades de conexão depende de onde um usuário visualiza o relatório.

  • Pré-visualização local: O Construtor de Relatórios e o SSDT (SQL Server Data Tools) usam o .NET Framework 4.0 e oferecem suporte a propriedades de cadeia de conexão de grupos de disponibilidade Always On.

  • Pré-visualização em modo remoto ou servidor: Se depois de publicar relatórios no servidor de relatório ou usar a visualização no Construtor de Relatórios, você vir um erro semelhante ao seguinte, é uma indicação de que você está visualizando relatórios no servidor de relatório e o Hotfix do .NET Framework 3.5 SP1 para grupos de disponibilidade Always On não foi instalado no servidor de relatório.

Mensagem de erro: "Palavra-chave não suportada 'applicationintent'"

Bancos de dados do servidor de relatório e grupos de disponibilidade

O Reporting Services e o Servidor de Relatório do Power BI oferecem suporte limitado para o uso de grupos de disponibilidade Always On com bancos de dados do servidor de relatório. Os bancos de dados do servidor de relatório podem ser configurados no AG para fazer parte de uma réplica; no entanto, o Reporting Services não usará automaticamente uma réplica diferente para os bancos de dados do servidor de relatório quando ocorrer um failover. Não é suportado o uso de MultiSubnetFailover com os bancos de dados do servidor de relatórios.

Ações manuais ou scripts de automação personalizados precisam ser usados para concluir o failover e a recuperação. Até que essas ações sejam concluídas, alguns recursos do servidor de relatório podem não funcionar corretamente após o failover dos grupos de disponibilidade Always On.

Observação

Ao planejar o failover e a recuperação de desastres para os bancos de dados do servidor de relatório, é aconselhável sempre fazer backup de uma cópia da chave de criptografia do servidor de relatório.

Diferenças entre o modo nativo do SharePoint

Esta seção resume as diferenças entre como os servidores de relatório do modo do SharePoint e do modo nativo interagem com os grupos de disponibilidade Always On.

Um servidor de relatório do SharePoint cria 3 bancos de dados para cada aplicativo de serviço do Reporting Services criado. A conexão com os bancos de dados do servidor de relatório no modo do SharePoint é configurada na Administração Central do SharePoint quando você cria o aplicativo de serviço. Os nomes padrão dos bancos de dados incluem um GUID associado ao aplicativo de serviço. A seguir estão exemplos de nomes de banco de dados, para um servidor de relatório de modo do SharePoint:

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

Os servidores de relatório de modo nativo usam 2 bancos de dados. A seguir estão exemplos de nomes de banco de dados, para um servidor de relatório de modo nativo:

  • ReportServer

  • ReportServerTempDB

Observação

Quando você configura o Reporting Services para trabalhar com um grupo de disponibilidade (AG), o modelo de recuperação do ReportServerTemp banco de dados muda para Completo. Como resultado, há cenários em que o banco de dados continua crescendo ReportServerTemp em tamanho. É uma prática recomendada remover o ReportServerTemp banco de dados da configuração do AG e ter o modelo de recuperação definido como Simples. O ReportServerTemp banco de dados armazena apenas dados temporários. Removê-lo do AG não afeta os Serviços de Relatórios.

O modo nativo não suporta nem usa os bancos de dados de Alertas e recursos relacionados. Configure servidores de relatório de modo nativo no Gerenciador de Configuração do Reporting Services. Para o modo do SharePoint, você configura o nome do banco de dados do aplicativo de serviço para ser o nome do "ponto de acesso do cliente" criado como parte da configuração do SharePoint. Para obter mais informações sobre como configurar o SharePoint com grupos de disponibilidade Always On, consulte Configurar e gerenciar grupos de disponibilidade do SQL Server para o SharePoint Server (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)).

Observação

Os servidores de relatório no modo do SharePoint usam um processo de sincronização entre os bancos de dados do aplicativo de serviço do Reporting Services e os bancos de dados de conteúdo do SharePoint. É importante manter os bancos de dados do servidor de relatório e os bancos de dados de conteúdo juntos. Você deve considerar configurá-los nos mesmos grupos de disponibilidade para que façam failover e recuperem como um conjunto. Considere o seguinte cenário:

  • Você restaura ou faz failover para uma cópia da base de dados de conteúdo que não recebeu as mesmas atualizações recentes que a base de dados do servidor de relatórios recebeu.
  • O processo de sincronização do Reporting Services detetará diferenças entre a lista de itens no banco de dados de conteúdo e os bancos de dados do servidor de relatório.
  • O processo de sincronização excluirá ou atualizará itens no banco de dados de conteúdo.

Preparar bases de dados do servidor de relatórios para grupos de disponibilidade

A seguir estão as etapas básicas de preparação e adição dos bancos de dados do servidor de relatório a um grupo de disponibilidade Always On:

  • Crie o Grupo de Disponibilidade e configure um Listener DNS name.

  • Réplica primária: Configure os bancos de dados do servidor de relatório para fazer parte de um único grupo de disponibilidade e crie uma réplica primária que inclua todos os bancos de dados do servidor de relatório.

  • Réplicas secundárias: Crie uma ou mais réplicas secundárias. A abordagem comum para copiar os bancos de dados da réplica primária para a(s) réplica(s) secundária(s) é restaurar os bancos de dados para cada réplica secundária usando 'RESTORE WITH NORECOVERY'. Para obter mais informações sobre como criar réplicas secundárias e verificar se a sincronização de dados está funcionando, consulte Iniciar movimentação de dados em um banco de dados secundário Always On (SQL Server).

  • Credenciais do servidor de relatório: Você precisa criar as credenciais apropriadas do servidor de relatório nas réplicas secundárias criadas na principal. As etapas exatas dependem do tipo de autenticação que você está usando em seu ambiente do Reporting Services; Conta de serviço do Windows Reporting Services, conta de usuário do Windows ou autenticação do SQL Server. Para obter mais informações, consulte Configurar uma conexão de banco de dados do servidor de relatório (SSRS Configuration Manager)

  • Atualize a conexão do banco de dados para usar o Nome DNS do Listener. para servidores de relatório de modo nativo, altere o Nome do Banco de Dados do Servidor de Relatório no Gerenciador de Configuração do Reporting Services. Para o modo do SharePoint, altere o nome do servidor de banco de dados para o(s) aplicativo(s) de serviço do Reporting Services.

Etapas para concluir a recuperação de desastres de bancos de dados do servidor de relatório

As etapas seguintes precisam ser concluídas após o failover de um grupo de disponibilidade Always On para uma réplica secundária:

  1. Pare a instância do serviço SQL Agent que estava sendo usada pelo mecanismo de banco de dados primário que hospeda os bancos de dados do Reporting Services.

  2. Inicie o serviço SQL Agent no computador que é a nova réplica primária.

  3. Pare o serviço Servidor de Relatório.

    Se o servidor de relatório estiver no modo nativo, pare o servidor de relatório Windows usando o gerenciador de configuração do Reporting Services.

    Se o servidor de relatório estiver configurado para o modo do SharePoint, interrompa o serviço compartilhado do Reporting Services na Administração Central do SharePoint.

  4. Inicie o serviço do servidor de relatório ou o serviço do SharePoint do Reporting Services.

  5. Verifique se os relatórios podem ser processados na nova réplica primária.

Comportamento do servidor de relatório quando ocorre um failover

Quando os bancos de dados do servidor de relatório fazem failover e você atualiza o ambiente do servidor de relatório para usar a nova réplica primária, há alguns problemas operacionais resultantes do processo de failover e recuperação. O impacto desses problemas varia dependendo da carga do Reporting Services no momento do failover, bem como do tempo necessário para que os grupos de disponibilidade Always On façam failover para uma réplica secundária e para que o administrador do servidor de relatório atualize o ambiente de relatório para usar a nova réplica primária.

  • A execução do processamento em segundo plano pode ocorrer mais de uma vez devido à lógica de repetição e à incapacidade do servidor de relatório de marcar o trabalho agendado como concluído durante o período de failover.

  • A execução do processamento em segundo plano que normalmente teria sido acionado para ser executado durante o período do failover não ocorrerá porque o SQL Server Agent não poderá gravar dados no banco de dados do servidor de relatório e esses dados não serão sincronizados com a nova réplica primária.

  • Depois que o failover do banco de dados for concluído e depois que o serviço do servidor de relatório for reiniciado, os trabalhos do SQL Server Agent serão recriados automaticamente. Até que os trabalhos do SQL agent sejam recriados, as execuções em segundo plano associadas aos trabalhos do SQL Server Agent não serão processadas. Isso inclui: assinaturas, agendas e instantâneos do Reporting Services.

Ver também

  • Last updated on