Não sou bom em SQL, mas tenho um banco de dados para manter.
Não há quase nenhum lugar para isso, então eu decidi excluir todos os dados para, digamos, o ano de 2008. Depois de executar a consulta de exclusão (com cerca de 10.000.000 de linhas limpas) e limpar o log de transações, descobri que meu ações não tiveram efeito no tamanho do banco de dados. Há mais alguma coisa que eu tenho que fazer?
Respostas:
Embora encolher seja realmente perigoso pelas razões mencionadas aqui. Há um meio termo entre a resposta de Jimbo e a resposta de John ... Você sempre deve considerar seriamente se deseja ou não reduzir seu banco de dados.
Em um mundo ideal - você criaria seu banco de dados com bastante espaço livre para crescer. Eu chamo isso de "dimensionamento correto" de seu banco de dados. Você permitiria que esse espaço livre estivesse lá e não se esforçasse para devolvê-lo e manter seu tamanho total no tamanho usado. Por que? Como seu banco de dados voltará a crescer novamente .. Então você diminuirá novamente .. E você ficará preso nesse padrão horrível de redução inútil seguido por crescimentos - e o tempo todo, como alguns apontaram, você estará aumentando sua fragmentação de índice.
Eu publiquei um blog sobre isso, onde eu aconselhava as pessoas a " não tocarem nesse botão! ", Mas às vezes ... Às vezes você precisa. Se você possui um banco de dados grande, liberou um espaço significativo e não espera voltar a usá-lo - bem, é bom considerar diminuir como uma operação única, desde que você possa cuidar da fragmentação do índice depois da reconstrução eles. A operação de encolhimento pode ser demorada, portanto, você deve planejá-lo por um tempo em que possa pagar o preço de um encolhimento. A abordagem de criar um banco de dados vazio e copiar dados nele funciona - mas isso pode se tornar muito difícil com bancos de dados maiores e muitos dados.
Se você planeja adicionar esse espaço de volta ao banco de dados por meio de padrões normais de uso e crescimento no futuro, convém deixar o espaço lá.
Além disso
Você disse que "limpou" seu log de transações. Eu ficaria curioso para saber como você fez isso, mas, ao ler a postagem que eu compartilhei e as outras da série, você verá algumas dicas sobre gerenciamento de log de transações. Mas, resumindo, se você estiver no modo de Recuperação total, deverá fazer backups regulares de log para manter a reutilização do log. Caso contrário - sem backups de log enquanto estiver no modo completo - o arquivo de log continuará crescendo, crescendo e crescendo e sempre salva o que você fez, porque você disse ao SQL que não deseja apenas manter esse log para recuperação de falhas, mas deseja manter um backup manual dele para reproduzir transações / desfazer transações para recuperar em um ponto específico no tempo para fins de recuperação ... Se você é simples e vê o log crescer excessivamente,BEGIN TRAN ... do work.... COMMIT TRANou se você acabou de emitir uma grande DELETEdeclaração e excluiu toda uma bagunça de dados em uma transação implícita.)
Também estou assumindo que você está procurando esse espaço livre no seu sistema de arquivos. Se você estiver procurando por ele no SQL e no arquivo grande que você possui - pode ser que você esteja aguardando a conclusão da limpeza do fantasma se procurar imediatamente após a operação. Paul Randal escreve sobre Ghost Cleanup .
A exclusão de linhas em um banco de dados não diminuirá o tamanho real do arquivo do banco de dados.
Você precisa compactar o banco de dados após a exclusão da linha.
DBCC SHRINKDATABASE do SQL Server 2005 (Transact-SQL)
Depois de executar isso, você desejará recriar índices. A redução geralmente causa fragmentação do índice e isso pode ser um custo de desempenho significativo.
Também recomendo que, depois que você encolher, volte a aumentar os arquivos para ter espaço livre. Dessa forma, quando novas linhas entram, elas não acionam o crescimento automático. O crescimento automático tem um custo de desempenho e é algo que você gostaria de evitar (através do dimensionamento adequado do banco de dados) sempre que possível.
NÃO ENCOLHE SUA BASE DE DADOS!
"Por que isso acontece? Uma operação de redução de arquivo de dados funciona em um único arquivo de cada vez e usa os bitmaps do GAM (consulte Por Dentro do Mecanismo de Armazenamento: GAM, SGAM, PFS e outros mapas de alocação) para encontrar a página mais alta alocada no Em seguida, ele é movido o mais longe possível para a frente do arquivo, e assim por diante. No caso acima, ele reverteu completamente a ordem do índice em cluster, passando de perfeitamente desfragmentado para perfeitamente fragmentado. "
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
"Veja a ironia do banco de dados Shrinking. Uma pessoa reduz o banco de dados para ganhar espaço (pensando que ajudará no desempenho), o que leva a um aumento na fragmentação (reduzindo o desempenho). Para reduzir a fragmentação, é necessário reconstruir o índice, o que leva ao tamanho de banco de dados para aumentar muito mais do que o tamanho original do banco de dados (antes de encolher). Bem, encolhendo, não se ganha o que procurava normalmente ".
Quando você exclui dados, o SQL Server reserva seu espaço para uso posterior na inserção de novos dados. Você precisa reduzir o banco de dados. Você pode encontrar mais informações aqui .
Descobri isso porque acabei de excluir várias tabelas de backup porque meu banco de dados havia atingido o limite máximo. Fiquei olhando para a propriedade "Size", pensando por que isso não está ficando menor? . Depois de ler isso, não, não quero reduzir o banco de dados. O que eu quero fazer é "recuperar" o espaço para o lixo que acabei de excluir. O que eu precisava olhar era "Espaço disponível". Estou pensando que talvez seja isso que outra pessoa precise olhar também.
É importante notar também que, se a tabela tiver índices, poderá haver fragmentação após a exclusão de grandes faixas de dados. Hoje eu tinha uma mesa que tinha ~ 70 milhões de registros, com cerca de 13 GB. Limpei para 1639 registros (o restante foi gerado por um único bug), mas a tabela ainda ocupava cerca de 4,5 GB. Depois de reconstruir todos os índices da tabela, foram necessárias apenas 85 páginas (680kb). Depois disso, usei o shrinkfile incremental para recuperar o espaço (e corrigi o bug no sistema para impedir a repetição).