Estou usando o SQL Server 2005. Tenho duas tabelas que contêm informações agregadas. As informações são constantemente atualizadas, gerando quase 5 GB de dados de log por dia. (Isso é maior que o banco de dados inteiro!) Gostaria de desativar o log nessas tabelas, pois a reversão não é realmente necessária. No entanto, gostaria de continuar registrando as outras tabelas no banco de dados.
É possível desativar o log em determinadas tabelas no banco de dados? Caso contrário, posso colocar as duas tabelas no mesmo esquema e desabilitar o log no esquema? É a única opção para mover as duas tabelas para um banco de dados separado e desativar o log lá?
Atualização: acho que vou explicar por que realmente não preciso registrar a atividade nessas tabelas.
As duas tabelas são preenchidas com dados de GPS e, portanto, ficam muito grandes. A primeira tabela está capturando locais brutos de seis tabelas Android em campo. Novos dados de cada um dos tablets chegam a cada 5 a 10 segundos. Essas informações são agregadas como locationA, locationB, travelTime. O objetivo é obter os menores tempos de viagem entre todos os locais, com base nos dados reais de direção. Os dados são apenas para uma cidade pequena e com precisão de apenas quatro casas decimais, portanto, são gerenciáveis. No entanto, à medida que novos dados brutos são recebidos, há tempos de viagem mais lentos que precisam ser atualizados e novos que precisam ser inseridos.
Depois que os dados brutos são agregados, eles são limpos. Não vamos voltar atrás para tempos de viagem mais longos; é por isso que reverter não importa tanto nessas tabelas.
fonte
Respostas:
O log de operações do usuário não pode ser desativado.
Há uma classe de operações chamadas operações minimamente registradas que só permite uma transação para ser rolada para trás (ao contrário de também ser capaz de rolar para a frente ). No entanto, não parece que o que você está fazendo cumprisse os critérios para isso, nem acho que isso resolveria o problema de qualquer maneira.
A solução do SQL Server seria aterrar as tabelas temporárias em um novo banco de dados em
SIMPLErecuperação, separado do banco de dados de resultados de agregação, que suponho estar emFULLrecuperação. Embora isso não diminua o volume do registro, elimina a necessidade de fazer backup do log gerado pelas cargas de dados. (Veja minha postagem no blog aqui sobre log e alguns dos fatores envolvidos na escolha do modelo de recuperação de um banco de dados.)A separação das tabelas em outro banco de dados proporcionaria flexibilidade para aterrar o arquivo de log em um subsistema de E / S mais rápido, provavelmente uma pequena matriz de unidades de estado sólido conectadas localmente.
Além disso, considere que o SQL Server sozinho pode não ser a melhor solução para resolver o problema. Existem outras soluções RDBMS que oferecem a capacidade de desativar completamente o log para determinadas tabelas. Os dados podem ser preparados e agregados em outro sistema e os resultados mesclados no banco de dados existente do SQL Server, que é bem protegido por logs e backups completos.
fonte
Não, não há como impedir o logon no SQL Server, independentemente do esquema, tabela ou nível do banco de dados.
De fato, todas as transações que realizam modificações ou alterações no banco de dados do SQL Server são registradas, exceto as transações relacionadas ao armazenamento de versão que envolvem o TempDB quando o isolamento de instantâneo é usado. (efetuar logon no log de transações garante que a transação possa ser revertida (em determinadas operações, você pode reduzir o log (isso é chamado de operações minimamente registradas)) alterando o modelo de recuperação para BULK Logged --- você pode aprender mais sobre isso nos Manuais Online do SQL Server aqui
fonte
A resposta é, como sempre, depende.
Quando você disse:
Que tipo de agregação é essa?
Tente usar uma VIEW, não é necessário atualizar nem registrar.
Se isso não for uma opção, tente usar transações mais curtas e fazer backup do log entre elas.
Usar um banco de dados diferente significa sobrecarga de administração de segurança etc. e terá seu próprio log de transações (mesmo com o modelo de recuperação SIMPLE em que o log é gravado, o SQL Server simplesmente trunca o log automaticamente, mas não libera espaço em disco), portanto, eu não recomendaria essa opção .
fonte