Analysis Services – Banco de Dados corrompido

Publicado em por

É comum para profissionais administradores de banco de dados (DBA) em algum momento da vida se deparar com falhas de corrupção em bancos de dados transacionais. Porém, recentemente tivemos a experiência de vivenciar uma corrupção no banco de dados analítico (OLAP) do SQL Server Analysis Services utilizando o modelo de implantação Tabular.

O fato é: tenha uma das seguintes opções backup do cubo ou o backup do código fonte, para que você faça respectivamente a restauração ou reimplantação do projeto e em seguida reprocessamento dos dados.

Os erros que você pode encontrar em caso de corrupção do seu cubo:

As verificações de consistência do banco de dados (DBCC) falharam ao verificar um segmento de dados.
O seguinte arquivo está corrompido: Arquivo físico: 4960.NOME_SUA_TABELA (6495).NOME_CAMPO_TABELA (6537).dictionary. Arquivo lógico ..
Erro ao carregar os dados da tabela. Possível causa: arquivo de dados de repositório de cadeia de caracteres corrompido para uma das colunas da tabela.
Um valor duplicado foi detectado no repositório Valor Exclusivo associado com o dicionário.
As verificações de consistência do banco de dados (DBCC) falharam ao verificar um segmento de dados.
…
Ocorreu um erro ao carregar objetos de dados Vertipaq para diversas tabelas.

Pela internet, você vai encontrar diversas boas referências para como conseguir solucionar este problema:

Porém, o que me motiva a escrever este artigo é um complemento que não observei em nenhum dos artigos acima, mas em um workaround encontrado no site da Microsoft:

O meu problema não era o que fazer, se iria restaurar o backup ou refazer o deploy, eu precisava remover o banco de dados (cubo) e enquanto tentava fazê-lo ele apresentava erros (que eu já sabia que existiam), então com o comando:

<Delete xmlns=”http://schemas.microsoft.com/analysisservices/2003/engine” IgnoreFailures=”true”> <Object>
<DatabaseID>NOME_SEU_BANCO_DE_DADOS</DatabaseID>
</Object>
</Delete>

Com este comando XMLA o SQL Server estará eliminando o banco de dados e ignorando falhas que possam ocorrem durante o processo de exclusão, pois, sim ele iria verificar que a estrutura não está consistente, mas isso eu não queria que ele fizesse.

Um aspecto interessante, é que em https://docs.microsoft.com/en-us/analysis-services/instances/database-consistency-checker-dbcc-for-analysis-services?view=asallproducts-allversions#disable-automatic-consistency-checks-on-database-load-operations-through–the-msmdsrvini-configuration-file poderíamos configurar para que em toda a instância fosse ignorado a verificação de consistência em alguns casos, inclusive, a opção 0 é bem interessante, pois seria verificado apenas em situações como RESTORE, IMAGELOAD, LOCALCUBELOAD e ATTACH.

Espero que tenha esclarecido suas dúvidas.

Obrigado!

Vithor da Silva e Silva | CTO – Datasource Expert
vithor@datasource.expert