Analisando problemas e Reconstruindo o ReportServerTempDB

Muitas vezes ele passa desapercebido, mas o banco de dados ReportServerTempDB possui grande importância para o funcionamento do seu ambiente de SQL Server Reporting Services (SSRS) e, ao contrário do que alguns podem pensar, este banco não é descartável e precisa, por exemplo, ser incluído em sua política de backups.

Para começar, vamos citar algumas características deste banco de dados:

  • Seus dados expiram baseado nas configurações de expiração
  • Ajuda a melhorar a performance de execução dos relatórios, já que armazena dados de CACHE que são acessados durante a execução dos relatórios
  • Armazena dados sobre sessões e execuções de relatórios, relatórios em cache
  • Reinicializações do serviço limpa seus dados temporários (aqui vale o destaque, o banco NÃO é recriado na reinicialização)

Considerando então que esse banco NÃO é recriado durante a reinicialização do serviço, precisamos considerar o que acontece se perdermos esse banco de dados, devido a uma corrupção, por exemplo.

Inicialmente, o seu ambiente SSRS não vai funcionar corretamente. Por mais que este banco seja “temporário”, ele é frequentemente utilizado durante operações básicas do SSRS e você verá muito rapidamente alguma mensagem de erro ao tentar acessar seu ambiente.

O ideal a fazer nessa situação é restaurar o banco de dados a partir de um backup, para então reiniciar o serviço, que vai limpar algum dado temporário, e então seu ambiente deve ficar novamente operacional.

O problema é, o que fazer caso eu não tenha um backup válido para uso? (Se você não inclui esse banco em sua política de backups, faça isso agora!)

Uma possibilidade seria recriar o banco com o mesmo nome, mas como já disse antes, este banco não tem seus objetos recriados durante a reinicialização, então isso não resolveria.

De qualquer forma, esse passo ainda seria útil, desde que você lembre de criar o banco com o collate correto, normalmente o ReportServerTempDB usa um collation bem incomum, no meu caso era o “Latin1_General_CI_AS_KS_WS”. Você pode se basear em sua documentação ou então no collation do banco de dados ReportServer.

Depois disso você deve recriar a ROLE “RSExecRole”. Adicione os usuários que fazem parte dessa mesma ROLE no banco de dados ReportServerTempDB, nesta role no ReportServerTempDB.

Em seguida você deve recriar os objetos do seu banco de dados (lembre-se de mudar o contexto para o banco ReportServerTempDB) utilizando o script “CatalogTempDB.sql” que fica na pasta “C:\Program Files\Microsoft SQL Server\MSRS10.SQL01\Reporting Services\ReportServer” (este caminho pode ser diferente, dependendo de onde o SSRS foi instalado).

O problema é que, mesmo após recriar este banco a partir desse script, ao acessar o seu ambiente você pode se deparar com mensagens do tipo (isso baseado no que vi em um SQL Server 2008 R2!):

“An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database. (rsReportServerDatabaseError)

Invalid column name ‘EditSessionID’. Invalid column name ‘SitePath’. Invalid column name ‘SiteZone’. Invalid column name ‘DataSetInfo’. Invalid column name ‘ReportDefinitionPath’.”

Se você pesquisar, verá que essas colunas mencionadas são da tabela SessionData no ReportServerTempDB.

Pelo que eu pude entender da situação, o problema é que o script que mencionei acima recria o banco, mas na forma que ele tinha na versão RTM! Ou seja, tudo que foi alterado neste banco de dados devido as atualizações seguintes fica faltando.

E então, o que fazer?

Bem, considerando o ambiente que eu tinha quando enfrentei essa situação, tive que recriar alguns objetos e alterar outros (me baseei em outras bases que tinha, no mesmo build, e nas mensagens de erro). A ordem de criação/alteração dos objetos nesse caso foi importante, pois há constraint entre as mesmas. O meu ambiente estava no build 10.50.4266.

1) Recriar as tabelas Temp*, na sequência abaixo:

  • TempCatalog
  • TempDataSets
  • TempDataSources

2) Criar a tabela DBUpgradeHistory e importar os dados da mesma de uma base com os mesmos dados, ou seja, que esteja no mesmo build.

3) Verificar a estrutura das demais tabelas, pois devido as atualizações, algumas tiveram a estrutura alterada (colunas adicionadas, índices, etc)

Aqui uma falha minha, esqueci de anotar os objetos que foram alterados e o que foi alterado, mas de qualquer forma isso faria o procedimento válido apenas para o build 4266. Caso você enfrente esse problema, e não tenha um backup, o ideal realmente será comparar a sua base com uma já existente.

Sei que nesse ponto alguém deve estar comentando “há, já que preciso ter uma outra base no mesmo build, é mais fácil gerar o script dela, alterar apenas o nome do banco de dados, se necessário, e criar a base novamente”.

Isso é verdade, mas a ideia aqui era explicar o motivo do problema e como ele pode ser contornado detalhadamente.

Por fim, apenas mais um comentário sobre o ReportServerTempDB. Como banco de dados para dados temporários, sabiam que este banco pode sofrer de problemas de contenção similares aos do Tempdb?

A forma de análise é basicamente a mesma, contadores do perfmon e DMVs. E a solução?

Assim como no Tempdb, alocar os data files do ReportServerTempDB para um disco dedicado e/ou gerar mais datafiles, sempre lembrando de mantê-los com o mesmo tamanho e a mesma política de crescimento.

Fontes interessantes:

Esse post foi publicado em Artigos, Virtual PASS BR. Bookmark o link permanente.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s