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:
- http://sensibledataintegrations.com/2018/03/29/is-your-cube-corrupt/
- https://docs.microsoft.com/en-us/analysis-services/instances/database-consistency-checker-dbcc-for-analysis-services?view=asallproducts-allversions
- https://www.mssqltips.com/sqlservertip/4077/consistency-checks-for-sql-server-analysis-services/
- https://social.msdn.microsoft.com/Forums/SECURITY/en-US/7157109f-e0a8-4d64-a95f-60e9267b5170/database-consistency-checks-dbcc-failed-while-checking-the-data-segments?forum=sqlanalysisservices
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