Temos um banco de dados SQL Server que usa exibições indexadas para permitir a consulta eficiente de alguns dados que mudam regularmente (sim, sei que há um custo para manter o índice quando os dados mudam, mas no nosso caso vale muito a pena ) .
Meu entendimento é que as alterações nos índices de visualização devem ser registradas/backup da mesma forma que as alterações em qualquer outra tabela/índice. No entanto, parece-me que esse registro é redundante, pois o SQL pode reconstruir facilmente o índice de exibição a partir da definição de exibição no caso de uma falha.
Existe alguma maneira de conseguir algo assim com o SQL Server?
não
Há uma solicitação de longa data para o SQL Server oferecer suporte a objetos não registrados . Ele está disponível em vários formatos em outros sistemas de banco de dados, tanto para tabelas quanto para visualizações materializadas.
No entanto, até o momento em que este livro foi escrito, você não pode optar por marcar um objeto de qualquer variedade como não registrado no SQL Server. Embora possa ser logicamente redundante, não está claro em sua pergunta se está causando um problema ou se você simplesmente não gosta e prefere um comportamento diferente.
Se você estiver enfrentando problemas de desempenho com a manutenção de exibição indexada, faça uma pergunta mais direta sobre como melhorar isso , em vez de procurar uma mudança no comportamento atual do produto.
Para suas preocupações com a recuperação (seja de travamentos ou reinicializações), você pode aproveitar a recuperação acelerada do banco de dados no SQL Server 2019 e superior.
O registro garante consistência em seu banco de dados. Uma alteração feita em uma tabela subjacente pode não ter concluído a gravação no índice da exibição indexada no meio de uma falha. Ou talvez ainda pior, se estivesse no meio da reversão da alteração durante a falha.
Facilmente é subjetivo para começar. Se sua exibição indexada for computacionalmente pesada, provavelmente será mais fácil, rápido e menos problemático para o seu servidor continuar de onde parou com base no log. Além disso, pode haver casos em que ocorreria perda de dados se não houvesse o log para referência no meio de uma falha, especialmente porque os resultados da exibição indexada quase certamente não correspondem aos da(s) tabela(s) subjacente(s) .
Não, não acredito. Mas alguém mais esperto do que eu pode ter uma sugestão.
Qualquer inicialização e failover significa que a recuperação é executada. Qualquer coisa confirmada deve ser persistida, tudo não confirmado precisa ser revertido.
Ter itens excluídos desse processo significaria que a maioria das reinicializações/failovers tornaria suas exibições indexadas não confiáveis (não apenas por causa de dados de usuário incorretos, mas também ponteiros descontrolados, etc.).
Acho que implementar o que você pede é um grande empreendimento para a Microsoft, possivelmente exigindo uma grande reformulação do núcleo do mecanismo de banco de dados. – usuário151544
Lembre-se de que o registro não é necessário apenas para a recuperação de falhas .
Em uma configuração ARIES tradicional , as informações de log REDO são necessárias para aplicar os efeitos das transações confirmadas a quaisquer páginas do banco de dados que não foram atualizadas e liberadas para armazenamento estável a partir do ponto de recuperação. As informações de Log UNDO são necessárias para desfazer os efeitos de transações que sofreram alterações, mas nunca foram confirmadas de acordo com o log.
A informação UNDO também é necessária para desfazer os efeitos de transações abortadas (devido a um 'rollback' ou erro) durante as operações normais do banco de dados.
Se você não registrar informações de UNDO, a recuperação de um erro comum durante as alterações de dados pode exigir a reconstrução da visualização e seus índices após a recuperação do(s) objeto(s) a que ela faz referência. Isso pode não ser muito popular.
Conforme mencionado em outra resposta, as ideias do ARIES são implementadas de maneira diferente na Recuperação Acelerada de Banco de Dados (ADR). Os registros de log ainda precisam ser gravados como antes, mas o REDO é muito, muito mais rápido e o UNDO é quase instantâneo (embora a limpeza do plano de fundo continue separadamente).
Como os mesmos registros de log são gravados, o ADR não parece atender aos objetivos declarados, mas as melhorias de desempenho e o tamanho reduzido do log ativo podem. Dito isso, o ADR tem sobrecarga e não é aplicado para transações curtas, então você não pode fugir completamente do processamento UNDO tradicional.
Não haveria nada que impedisse a equipe do SQL Server de implementar uma
WITH NOINDEXESopção para backups e, em seguida, reconstruí-los a partir dos índices clusterizados. Em outras palavras: os mesmos argumentos usados para exibições indexadas também se aplicam a índices não agrupados.Mas o fato é que eles não o fizeram. É um processo de backup tudo ou nada. A saber: você não pode nem fazer um backup por tabela. Isso já foi solicitado por muitos anos e agora é o terceiro pedido mais votado no site de feedback , e eu recomendo fortemente que você também vote nele.