(um cara apertou o botão verde em vez do azul, três racks restantes como era seu alvo original, provavelmente o verde é melhor do que o azul, neste SAN estão salvos os arquivos do banco de dados)
após este acidente, executei uma verificação de consistência nos bancos de dados
mas um dos bancos de dados retorna erro de consistência
Falha:(-1073548784) A execução da consulta "DBCC CHECKDB(N'XxxXxxx') WITH NO_INFOMSGS " falhou com o seguinte erro: "Extensão (1:511776) no banco de dados ID 9 está marcada alocada no GAM, mas não SGAM ou IAM A extensão (1:511784) no banco de dados ID 9 está marcada como alocada no GAM, mas nenhum SGAM ou IAM a alocou.
. . .
A extensão (1:994048) no banco de dados ID 9 está marcada como alocada no GAM, mas nenhum SGAM ou IAM a alocou. A página Index Allocation Map (IAM) (0:0) é apontada pelo ponteiro anterior da página IAM (1:3318703) na ID de objeto 0, ID de índice -1, ID de partição 0, ID de unidade de alocação 72057594374717440 (tipo desconhecido) , mas não foi detectado na verificação. CHECKDB encontrou 32446 erros de alocação e 0 erros de consistência não associados a nenhum objeto único. CHECKDB encontrou 32446 erros de alocação e 0 erros de consistência no banco de dados 'XxxXxx'.
repair_allow_data_loss é o nível mínimo de reparo para os erros encontrados por DBCC CHECKDB (XxxXxx)." Possíveis motivos da falha: Problemas com a consulta, propriedade "ResultSet" não definida corretamente, parâmetros não definidos corretamente ou conexão não estabelecida corretamente.
UAT parece com sucesso, sem falta de dados
exceção é (razão pela qual fiz esta pergunta) da alocação de um novo espaço no disco rígido
minha pergunta é
posso executar bancos de dados de reparo padrão (será minha primeira tentativa)
procure detalhes e execute este reparo em mesas de concreto
banco de dados construído a partir de conjuntos de backups e, em seguida, importar novos dados (é possível, neste banco de dados existem instantâneos de dados armazenados)
EDITAR
para futuros leitores, houve alguns problemas no meu caso (DBCC CHECKTABLE aprovado com sucesso, sem exceções)
O SQL Server (ambos 2008_R2/2012_R2) repara apenas parte dos erros usando DBCC CHECKDB(DbName, REPAIR_ALLOW_DATA_LOSS) ....
Eu tenho que executar este processo quatro vezes (o número de GAMs alocados diminuiu), a última execução corrigiu este problema,
interessante é o fato de que ambos os SQL Servers 2008_R2 e 2012_R2 tiveram os mesmos processos com as mesmas exceções, número de exceções, número de reparos necessários, desempenhos muito semelhantes (um ambiente com duas instâncias diferentes)
Parece que você tem uma séria corrupção de banco de dados, pois CHECKDB aponta isso
As únicas opções viáveis são:
Em ambos os casos, você terá perda de dados (desde que tenha bons backups completos e T-log antes que aquele cara apertasse o botão verde em vez do azul).
Eu iria para a opção 1 => Restaurar de um backup bom e conhecido!
Consulte páginas IAM, cadeias IAM e unidades de alocação e exemplos de corrupção de página IAM
Se você tem o UAT regularmente sincronizado com o PROD, o melhor é usar esse conjunto de dados para restaurar o PROD - a menos que você esteja mascarando os dados do PROD no UAT.