Configuração ideal do SQL Server Reporting Services

Question

Gostaria de determinar uma configuração ideal para o SQL Server Reporting Services usar como ferramenta integrada de geração de relatórios para aplicativos baseados na Web SaaS. Todos os relatórios são pré-definidos, para que os usuários escolham um relatório e insiram alguns parâmetros em um front-end baseado na web. Os parâmetros são então passados para o relatório, que puxa os dados, formata os resultados e retorna um arquivo PDF ou Excel para o aplicativo da Web.

Embora tenhamos servidores SQL existentes que suportam nossos aplicativos da Web, nenhum deles tem o Reporting Services instalado. As opções incluem:

1) adicione o Reporting Services a uma instância existente do SQL Server
2) criar uma nova instância em um servidor físico que já executa o SQL Server e usar essa nova instância do SQL para o Reporting Services
3) ter um servidor físico separado para o Reporting Services

Enquanto o # 3 é ideal, também custa uma licença adicional do SQL Server, o que não é barato. Não sei se ganho muito com a opção 2, além de alguma estabilidade. A opção 1 pode ser o caminho de menor resistência, mas eu entendo que há uma sobrecarga considerável causada pelo SSRS e não quero muito sucesso no desempenho.

Alguém precisa fazer algo assim? Anedotas e opiniões bem-vindas.

    

Answer 1

Você não indicou qual versão do SQL Server. Lembre-se de que o SSRS 2005 também requer o IIS instalado na caixa. O SSRS 2008 não. Ele usa o HTTP.SYS nativamente. A resposta ideal é a no. 3, no entanto, ela realmente depende da carga existente no servidor físico, bem como do tipo de relatório que você estaria executando. # 1 / # 2 são essencialmente a mesma opção em relação ao desempenho.

A verdade é que, sem conhecer as características de desempenho, ninguém aqui pode lhe dizer a melhor opção. Seu melhor caminho é ter uma boa idéia de como os SQL Servers estão funcionando hoje, configurar um pequeno ambiente SSRS de desenvolvimento e criar um perfil dele enquanto você testa os relatórios, e depois toma a decisão por lá. Se você não sabe por onde começar a obter um perfil de desempenho em seus servidores SQL, permita-me recomendar:

Mensagens de Brent Ozar sobre o ajuste de desempenho

    

Answer 2

Nós estamos indo na rota # 1 até que tenhamos algumas licenças gratuitas para um servidor rs / as / mirroring dedicado. Limitei o uso da memória para o pool de aplicativos. Com isso e tempos limite razoáveis, esperamos reduzir o impacto no mecanismo de banco de dados.

Eu não permitiria nenhum adhoc (criador de relatórios) no sistema número 1.

Eu realmente pressionaria pelo terceiro lugar. Você também pode usá-lo para espelhamento de banco de dados critcal ou executando ssis.

Nós servimos 3600 relatórios na semana passada em 4 dias - a memória fica em torno de 300-1500MB.

    

Answer 3

Considerável sobrecarga, eu acho, está nos olhos de quem vê. Por exemplo, um dos servidores que eu administro é um Data Warehouse do SQL Server 2000 com uma instância do SQL Server 2005 para manter o Reporting Services. Eu dificilmente diria que o SSRS tem uma sobrecarga considerável para nós, mas isso tem muito a ver com o modo como o usamos. Estamos consolidando os dois em uma única instância padrão do SQL Server 2008 por vários motivos, principalmente lidando com o tamanho pequeno de um SSRS em relação ao data warehouse. Temos menos de 50 relatórios, com a grande maioria deles sendo agendados. Nós também não fazemos caching ou snapshots. Então, no nosso caso, a consolidação é definitivamente o caminho a percorrer.

    

Answer 4

Usamos servidores virtuais ESX com licenças de centros de dados e licenças de CPU SQL, por isso não temos um problema com o número de instâncias SQL que hospedamos, então minha resposta é ...

Mantenha os serviços de relatórios em um servidor separado. A principal razão pela qual fazemos isso é que o SSRS tende a ser o serviço de atualização para a versão "mais recente e melhor" a primeira a obter o máximo benefício da nova funcionalidade (do SSRS e do Visual Studio 2008).

Nosso SSRS é o SQL 2008 - a maioria dos bancos de dados ainda é SQL2000 / e 2005

Também ajuda se você puder manter os dados em um servidor separado. Descobrimos que um servidor SSRS ocupado com o banco de dados no mesmo sistema diminuiu a velocidade de navegação na web para outros usuários no sistema. Isso foi menos quando movemos os dados para um servidor de "dados de relatório" dedicado.