Serviços de Relatórios com Grupos de Disponibilidade AlwaysOn (SQL Server)

Este tópico contém informações sobre como configurar o Reporting Services para trabalhar com Grupos de Disponibilidade AlwaysOn (AG) no SQL Server 2014. Os três cenários para usar o Reporting Services e os Always On Availability Groups são bancos de dados de fontes de dados de relatório, bancos de dados do servidor de relatório e projeto de relatório. A funcionalidade com suporte e a configuração exigida é diferente para os três cenários.

Um dos principais benefícios do uso de Grupos de Disponibilidade Always On com fontes de dados do Reporting Services é aproveitar as réplicas secundárias legíveis como fonte de dados de relatórios, enquanto, ao mesmo tempo, as réplicas secundárias fornecem um failover para um banco de dados primário.

Para obter informações gerais sobre grupos de disponibilidade AlwaysOn, consulte perguntas frequentes sobre AlwaysOn para SQL Server 2012 (https://msdn.microsoft.com/sqlserver/gg508768).

Requisitos para usar o Reporting Services e grupos de disponibilidade AlwaysOn

Para usar grupos de disponibilidade AlwaysOn com o SQL Server 2014 Reporting Services, você precisa baixar e instalar um hotfix para o .Net 3.5 SP1. O hotfix adiciona suporte a Cliente SQL para os recursos do AG e suporte das 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: “Não há suporte para a palavra-chave '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 anotada será vista quando você clicar no botão "Testar Conexão" nas interfaces de usuário do Reporting Services e quando visualizar o relatório se erros remotos estiverem habilitados nos servidores de relatório.

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

Para obter informações sobre outros requisitos de Grupos de Disponibilidade AlwaysOn, consulte pré-requisitos, restrições e recomendações para grupos de disponibilidade AlwaysOn (SQL Server).

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 de AG.

Para utilizar Grupos de Disponibilidade Always On para fontes de dados de relatório, você precisa configurar a cadeia de conexão da fonte de dados do relatório para usar o nome DNS do listener do grupo de disponibilidade. As fontes de dados com suporte são as seguintes:

• Fontes de dados ODBC usando SQL Native Client.

• Cliente SQL, com o hotfix .Net aplicado ao servidor de relatório.

A cadeia de conexão também pode conter novas propriedades de conexão AlwaysOn que configuram as consultas de relatório para utilizar a réplica secundária em relatórios somente leitura. O uso da réplica secundária para solicitações de relatório reduzirá a carga em uma réplica primária de leitura/gravação. A ilustração a seguir é um exemplo de uma configuração de três réplicas de AG onde 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.

Veja a seguir uma cadeia de conexão de exemplo, em que o [AvailabilityGroupListenerName] é o Nome DNS do Ouvinte que foi configurado quando as réplicas foram criadas:

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

O botão Testar Conexão nas interfaces de usuário do Reporting Services validará se uma conexão pode ser estabelecida, mas não validará a configuração do 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 Testar Conexão validará apenas uma conexão que pode ser estabelecida para o servidor especificado.

Dependendo de como seus relatórios são criados e publicados, isso determinará onde você editará a cadeia de conexão:

• Modo nativo: Use o Gerenciador de Relatórios 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á estão publicados em um servidor do SharePoint.

• Design de Relatório: SQL Server Report Builder para SQL Server 2012 ou SQL Server Data Tools (SSDT) para a criação de novos relatórios. Consulte a seção 'Design de Relatório' neste tópico ou mais informações.

Recursos adicionais:

• Gerenciar fontes de dados de relatório

• Para obter mais informações sobre as propriedades da cadeia de conexão disponíveis, consulte Using Connection String Keywords with SQL Server Native Client.

• Para obter mais informações sobre ouvintes do grupo de disponibilidade, veja Criar ou configurar um ouvinte do grupo de disponibilidade (SQL Server).

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

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

• A localização geográfica e a distância entre as réplicas primárias e secundárias. Por exemplo, o atraso será geralmente maior se as réplicas secundárias estiverem em um data center diferente do que se estivessem no mesmo prédio que a 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 espera para confirmar transações em um banco de dados até que uma réplica secundária tenha gravado a transação em disco. Para obter mais informações, consulte a seção "Modos de Disponibilidade" de Visão Geral dos Grupos de Disponibilidade AlwaysOn (SQL Server).

Ao utilizar um secundário em modo somente leitura como uma fonte de dados do Reporting Services, é importante garantir que a latência na atualização de dados atenda às necessidades dos usuários do relatório.

Design de relatório e grupos de disponibilidade

Ao projetar relatórios no SQL Server Report Builder para SQL Server 2012 ou em 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 pelos Grupos de Disponibilidade AlwaysOn. O suporte para as novas propriedades de conexão depende de onde o usuário visualiza o relatório.

• Visualização local: O SQL Server Report Builder para SQL Server 2012 e o SQL Server Data Tools (SSDT) usam o .NET Framework 4.0 e dão suporte às propriedades da cadeia de conexão dos grupos de disponibilidade Always On.

• Versão prévia do modo de servidor ou remoto: Se depois de publicar relatórios no servidor de relatório ou usar a visualização no SQL Server Report Builder para SQL Server 2012, você verá 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 AlwaysOn não foi instalado no servidor de relatório.

Mensagem de erro: “Não há suporte para a palavra-chave 'applicationintent'"

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

O Reporting Services oferece suporte limitado para usar Grupos de Disponibilidade Always On com bancos de dados do servidor de relatórios. 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.

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 poderão não funcionar corretamente após o failover dos Grupos de Disponibilidade AlwaysOn.

Diferenças entre o modo nativo do SharePoint

Esta seção resume as diferenças entre como o modo do SharePoint e os servidores de relatório de modo nativo interagem com Grupos de Disponibilidade AlwaysOn.

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 para 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 que está associado com o aplicativo de serviço. A seguir são apresentados nomes de bancos de dados de exemplo para o servidor de relatório do modo do SharePoint:

• ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

• ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

• ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerta

Os servidores de relatórios de modo nativo usam 2 bancos de dados. A seguir são apresentados nomes de bancos de dados de exemplo para o servidor de relatório do modo nativo:

• ReportServer

• ReportServerTempDB

O modo nativo não dá suporte nem usa os bancos de dados de alerta e os recursos relacionados. Configure os servidores de relatório de modo nativo no Gerenciador de Configurações do Reporting Services. Para o modo do SharePoint, configure o nome do banco de dados do aplicativo de serviço para ser o nome do "ponto de acesso do cliente" que você criou como parte da configuração do SharePoint. Para obter mais informações sobre como configurar o SharePoint com Grupos de Disponibilidade AlwaysOn, consulte Configurar e gerenciar grupos de disponibilidade do SQL Server para SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).

Preparar os bancos de dados do servidor de relatório para grupos de disponibilidade

Veja a seguir as etapas básicas de preparação e adição dos bancos de dados do servidor de relatório a grupos de disponibilidade AlwaysOn:

• Crie seu Grupo de disponibilidade e configure um Nome DNS do Ouvinte.

• Réplica primária: configure os bancos de dados do servidor de relatório para fazerem parte de um único grupo de disponibilidade e para criarem uma réplica primária que inclui 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 réplica secundária é 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 AlwaysOn (SQL Server).

• Credenciais do servidor de relatório: você precisa criar as credenciais de servidor de relatório apropriadas nas réplicas secundárias, tal qual você criou na réplica primária. As etapas exatas dependem do tipo de autenticação que você está usando em seu ambiente do Reporting Services; Conta de serviço do Window Reporting Services, conta de usuário do Windows ou autenticação do SQL Server. Para saber mais, confira Configurar uma conexão de banco de dados do servidor de relatório (Configuration Manager do SSRS)

• Atualize a conexão de banco de dados para usar o Nome DNS de Lister. para os servidores de relatórios do modo de 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 aplicativo de serviço do Reporting Services.

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

As etapas a seguir precisam ser concluídas após um failover de Grupos de Disponibilidade AlwaysOn para uma réplica secundária:

1. Pare a instância do serviço SQL Agent que estava sendo usado 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 do servidor de relatório.

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

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

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

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

Comportamento do servidor de relatório quando ocorre um failover

Quando ocorre o failover de bancos de dados do servidor de relatório e você atualizou o ambiente do servidor de relatório para usar a nova réplica primária, há alguns problemas operacionais que resultam do failover e do processo de recuperação. O impacto desses problemas variará dependendo da carga do Reporting Services no momento do failover, bem como do tempo necessário para que os Grupos de Disponibilidade AlwaysOn 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 a incapacidade de o servidor de relatório marcar trabalho agendado como concluído durante o período de failover.

• A execução do processamento em segundo plano que normalmente teria sido disparada para ser executada 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, instantâneos do Reporting Services.

Consulte Também

Suporte do Cliente Nativo do SQL Server para Alta Disponibilidade e Recuperação de DesastreGrupos de Disponibilidade AlwaysOn (SQL Server)Introdução aos Grupos de Disponibilidade AlwaysOn (SQL Server)Uso de Palavras-chave na Cadeia de Conexão com o Cliente Nativo do SQL ServerSuporte do Cliente Nativo do SQL Server para Alta Disponibilidade e Recuperação de DesastreSobre o Acesso de Conexão do Cliente às Réplicas de Disponibilidade (SQL Server)