É apagar todos os registros em uma tabela de uma má prática em SQL Server?

votos
6

Eu estou movendo um sistema a partir de um aplicativo VB / Acesso ao servidor SQL. Uma coisa comum no banco de dados de acesso é o uso de tabelas para armazenar dados que está a ser calculados e, em seguida, usando esses dados para um relatório.
por exemplo.

delete from treporttable
insert into treporttable (.... this thing and that thing)
Update treportable set x = x * price where (...etc)  

e, em seguida, relatar vai de treporttable

Ouvi dizer que servidor SQL não gosto quando todos os registros de uma tabela são eliminadas, pois cria registros enormes etc. eu tentei tabelas SQL temporários, mas eles não persistir por tempo suficiente para o relatório que está em um processo diferente para executar e relatar fora de.

Há uma série de lugares onde isso é feito para diferentes tabelas de relatório no aplicativo. Os relatórios podem ser executados várias vezes por dia e tem um grande número de registros criados nas tabelas de relatórios.

Alguém pode me dizer se existe uma melhor prática para isso ou se meu informações sobre os logs é incorreto e este código vai ficar bem no servidor SQL.

Publicado 19/05/2009 em 14:58
fonte usuário
Em outras línguas...                            


9 respostas

votos
20

Se você não precisa registrar a atividade de eliminação que você pode usar o comando da tabela truncada.

A partir de livros on-line:

TRUNCATE TABLE é funcionalmente idêntico ao DELETE sem cláusula WHERE: ambos remover todas as linhas na tabela. Mas TRUNCATE TABLE é mais rápido e usa menos recursos do sistema e log de transações do que DELETE.

http://msdn.microsoft.com/en-us/library/aa260621(SQL.80).aspx

Respondeu 19/05/2009 em 14:59
fonte usuário

votos
5
delete from sometable

Vai permitir que você para reverter a mudança. Então, se sua mesa é muito grande, então isso pode causar uma série de useage de memória e tempo.

No entanto, se você não tem medo do fracasso, em seguida:

truncate sometable

Irá realizar quase instantaneamente, e com os requisitos mínimos de memória. Não há reversão embora.

Respondeu 19/05/2009 em 15:02
fonte usuário

votos
2

Você também pode remover a tabela e recriá-lo ... se não houver relacionamentos.

A [tabela GOTA] afirmação é transacional seguro enquanto [TRUNCATE] não é.

Então, isso depende do seu esquema que direção você quer ir !!

Além disso, use o SQL Profiler para analisar seus tempos de execução. Testá-lo e ver o que é melhor !!

Respondeu 19/05/2009 em 16:19
fonte usuário

votos
2

Para Nathan Feger:

Você pode reverter a partir TRUNCATE. Veja por si mesmo:

CREATE TABLE dbo.Test (I int); GO INSERIR IGNORO dbo.Test (i) SELECT 1; VAI COMEÇAR TRAN TRUNCATE TABLE dbo.Test; SELECIONE i DE dbo.Test; ROLLBACK GO selecione Eu DE dbo.Test; IR

Eu

(0 linha (s) afectado)

Eu

1

(Uma linha (s) afectado)

Respondeu 19/05/2009 em 15:25
fonte usuário

votos
1

Considere o uso de tabelas temporárias. Seus nomes começam com # e eles são excluídos quando ninguém se refere a eles. Exemplo:

create table #myreport (
    id identity,
    col1,
    ...
)

As tabelas temporárias são feitos para ser jogado fora, e isso acontece de forma muito eficiente.

Outra opção é usar TRUNCATE TABLE em vez de DELETE. O truncamento não vai crescer o arquivo de log.

Respondeu 19/05/2009 em 15:10
fonte usuário

votos
1

A resposta depende do modelo de recuperação do banco de dados. Se você está em modo de recuperação completa, então você tem registos de transacções que poderiam se tornar muito grande quando você apaga um monte de dados. No entanto, se você estiver fazendo backup de logs de transação em uma base regular para liberar o espaço, isso pode não ser uma preocupação para você.

De um modo geral, se o log de transações não importa para você em tudo, você deve truncar a tabela em vez. Esteja atento, porém, de quaisquer sementes chave, porque TRUNCATE irá propagar novamente a tabela.

EDIT: Note que mesmo que o modelo de recuperação está definida como Simples, os logs de transações vai crescer durante uma missa excluir. Os logs de transação só vai ser apagada depois (sem soltar o espaço). A ideia é que APAGAR irá criar uma transação ainda que temporariamente.

Respondeu 19/05/2009 em 15:02
fonte usuário

votos
0

Há uma série de maneiras de lidar com isso. Primeiro, você pode mover a criação dos dados a correr do próprio relatório. Isto que eu sinto é a melhor maneira de lidar, então você pode usar tabelas temporárias para encenar temporariamente seus dados e ninguém terá problemas concurency se várias pessoas tentam executar o relatório ao mesmo tempo. Dependendo do número de relatórios que estamos a falar, pode demorar algum tempo para fazer isso, então você pode precisar de outra solutio curto prazo n bem.

Em segundo lugar você pode mover todas as suas tabelas de relatórios para um db difffernt que está definido para o modo simples e truncar-los antes de executar suas consultas para preencher. Esta é mais próximo ao seu processo atual, mas se vários usuários estão tentando executar o mesmo relatório poderia ser um problema.

Em terceiro lugar, você poderia configurar um trabalho para preencher as tabelas (ainda em conjunto db separado para recuperação simples) uma vez por dia (truncando naquela época). Então qualquer um que funciona um relatório que dia vai ver os mesmos dados e não haverá problemas de concorrência. No entanto, os dados não serão up-to-the minutos. Você também pode configurar um awarehouse dados de relatórios, mas que é provavelmente um exagero no seu caso.

Respondeu 19/05/2009 em 16:19
fonte usuário

votos
0

Na verdade, as mesas como treporttable não precisa ser recuperado para um ponto de tempo. Como tal, eles podem viver em um banco de dados separado com o modo de recuperação simples. Isso alivia a carga de registro.

Respondeu 19/05/2009 em 15:28
fonte usuário

votos
0

Eu acho que seu exemplo tem um possível problema de concorrência. E se vários processos estão usando a tabela ao mesmo tempo? Se você adicionar uma JOB_IDcoluna ou algo como que permitirá que você para limpar as entradas relevantes nesta mesa sem sobrepor os dados que está sendo usado por outro processo.

Respondeu 19/05/2009 em 15:06
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more