O DBA preocupado com a reorganização ou reestruturação de índices pode causar perda de dados?

Temos alguns bancos de dados com fragmentação de índice que é> 95%. O melhor que posso dizer é que os índices nunca foram reconstruídos e muito menos reorganizados. Em anos.

(Para ser justo, essas tabelas parecem ter estatísticas de atualização automática ativadas. Também para ser justo, ele é diligente em relação aos backups: logs diários completos e trx a cada hora.)

Quando perguntei, o DBA disse que estava relutante em reconstruir ou reorganizar os índices. Quando perguntei por que, ele realmente não conseguiu articular. Eventualmente, ele disse que estava preocupado com a possível perda de dados. Por exemplo, um dos bancos de dados é usado pelo nosso aplicativo de contabilidade da Great Plains Dynamics, e ele parecia muito preocupado com isso.

Eu não sou um DBA, mas pelo que li, a ansiedade dele parece ... difícil de entender.

Não sei o que fazer a seguir. Sugestões como devo proceder?

sql-server maintenance

— Greg Hendershott
fonte

A menos que o banco de dados seja afetado 24 horas por dia, 7 dias por semana, e o mundo chegará ao fim se ficar offline, não há desculpa para esse comportamento. Escrevo reorganizações e estatísticas todas as semanas em mais de 12.000 bancos de dados sem pensar duas vezes. Em 16 anos, tive apenas um corrompido devido a um controlador ruim.

— precisa saber é o seguinte

Respostas:

A reconstrução de um índice de banco de dados não deve causar perda de dados. No entanto, provavelmente causará uma degradação substancial do desempenho, pois os índices que estão sendo reconstruídos normalmente não estarão disponíveis para uso até que a reconstrução seja concluída. Por esse motivo, isso deve ser feito fora do horário comercial, quando os sistemas afetados estão ociosos.

A paranóia é uma coisa boa em um DBA - se eles estiverem preocupados com a perda de dados, solicitarei que eles façam um teste adequado dos backups (restaure-os em um sistema separado e verifique se todos os dados estão lá) e se estão Se ainda estiver preocupado, executar um backup completo antes de reconstruir os índices seria uma precaução razoável a ser tomada.

— voretaq7
fonte

+1 para Paranoia é uma boa característica do DBA

— Joel Coel

Entendo e aprecio completamente a paranóia saudável. Meça duas vezes, corte uma vez. O que me deixa mais confuso é que isso parece mais com falta de entendimento do que cautela. E, em vez de "vamos determinar uma maneira de tentar com cuidado", é "sim, não vai acontecer". Poderíamos (digamos) colocar uma instância do EC2 de teste com uma cópia dos dados, reorganizar os índices, cronometrar e delta as linhas da tabela de resultados para confirmar que nenhum dado foi corrompido. Esse tipo de plano seria cauteloso ... em oposição à inação?

— Greg Hendershott

Apenas um lembrete que o índice de reorganizar está sempre on-line (todos os índices estão disponíveis durante a desfragmentação) e reconstrução de índice podem ser feitas também on-line ( WITH (ONLINE=ON)contanto que o índice não contém colunas BLOB.

— Remus Rusanu

@ Greg Sim, a mentalidade "Não vamos tocar nos índices que estão tão fragmentados que provavelmente estão prejudicando o desempenho" também me confunde demais - a ocasional REINDEXcomo "manutenção preventiva" em tabelas onde o conteúdo do índice muda bastante é bastante comum na minha experiência (se o índice é mais estático que é menos de uma coisa)

— voretaq7

@Remus good tip - Isso diminui o impacto no desempenho (você ainda terá uma E / S de disco alta, o que reduzirá sua velocidade, mas pelo menos as coisas que usariam um índice ainda podem usá-lo, em vez de recorrer a verificações sequenciais )

— voretaq7

Não há risco de perda de dados devido à reconstrução ou desfragmentação de índices.

— mrdenny
fonte

A menos que você já tenha algum grau de corrupção de dados ou que haja falha no hardware. Mas em qualquer um desses casos, a fragmentação do índice é a menor das suas preocupações!

— db2 5/05

Mas isso não seria corrupção de uma reconstrução de índice, mas de algum outro problema.

— mrdenny

A reorganização dos índices levará menos tempo e menos esforço do servidor SQL, portanto, eles podem ser feitos em um tipo de instância durante a semana. Se o que você está dizendo é verdade, mesmo a reorganização dos índices que nunca foram, também pode causar um impacto maior no servidor. A reconstrução dos índices exigirá uma quantidade substancial de esforço do servidor SQL, pois eles são descartados e reconstruídos. Fazer uma reconstrução em uma semana não vale o risco de o servidor estar ocupado com índices e não atender às pessoas que o utilizam.

Concordo com o voretaq7, se ele está preocupado em trabalhar com índices, experimente primeiro nos servidores de desenvolvimento ou teste para ver como eles reagem.

— Controle de taxa
fonte

Outra abordagem a ser adotada pode ser explicitamente DROP INDEXe re CREATE INDEX-não tenho certeza sobre o SQL Server, mas sei que o PostgreSQL às vezes faz melhor explodir um índice e começar do zero, em vez de tentar reconstruí- REINDEXlo ( ).

— Voretaq7

Tenho certeza que soltar e recriar é desnecessário no SQL Server.

— Justin Dearing

@Justin eu tenho certeza que você está certo (na verdade de meus dias Sybase Lembro-me de que um comportamento a reindexação é efetivamente uma gota / criar então não há nenhuma estranheza de bloqueio índice como em Postgres)

— voretaq7

A reorganização dos índices pode levar menos tempo. Qual demora mais dependerá da quantidade de fragmentação do índice.

— Mrdenny 14/05