Analysis Services – Banco de Dados corrompido

É 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