Não sou bom em SQL, mas tenho um banco de dados para manter.
Quase não há lugar para isso, então decidi excluir todos os dados para, digamos, o ano de 2008. Depois de executar a consulta de exclusão (teve cerca de 10.000.000 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 tenha que fazer?
Embora o encolhimento seja realmente perigoso pelas razões mencionadas aqui. Há um meio termo entre a resposta de Jimbo e a resposta de John... Você deve sempre considerar seriamente se deseja ou não reduzir seu banco de dados.
Em um mundo ideal - você criaria seu banco de dados com muito espaço livre para crescer. Eu chamo isso de "Dimensionamento Certo" de seu banco de dados. Você permitiria que esse espaço livre estivesse lá e não se esforçaria para devolvê-lo e manter seu tamanho total exatamente no tamanho usado. Por quê? Porque seu banco de dados acabará crescendo novamente.. Então você encolherá novamente. aumentando sua fragmentação de índice.
Eu escrevi sobre isso em um blog onde eu admoestei as pessoas a " Não toque nesse botão de encolher! ", mas às vezes... Às vezes você precisa. Se você tiver um banco de dados grande, acabou de liberar espaço significativo e não espera voltar a crescer nele - bem, então não há problema em considerar a redução como uma operação única, desde que você possa cuidar da fragmentação do índice posteriormente por meio da reconstrução eles. A operação de redução pode ser demorada, portanto, você deve planejá-la para um período em que possa pagar o preço de uma execução de redução. 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, talvez queira deixar o espaço lá.
Também Você disse que "limpou" seu log de transações. Eu ficaria curioso para saber como você fez isso, mas ao ler o post que compartilhei e os outros da série, você verá algumas dicas sobre gerenciamento de log de transações. Mas resumindo - se você estiver no modo de recuperação completa, deverá fazer backups regulares de log para manter o log sendo reutilizado. Caso contrário - sem backups de log no modo completo - o arquivo de log continua crescendo e crescendo e sempre salvando o que você fez porque você disse ao SQL que você não quer apenas manter esse log para recuperação de falhas, mas quer manter um backup manual dele para repetir transações/desfazer transações para recuperar para um ponto específico no tempo para fins de recuperação... Se você estiver no simples e vendo o log crescer excessivamente,
BEGIN TRAN ... do work.... COMMIT TRANou se você acabou de emitir uma grandeDELETEdeclaração e excluiu toda uma confusão de dados em uma transação implícita.)Também estou assumindo que você está procurando esse espaço livre em seu sistema de arquivos. Se você estiver procurando por isso no SQL e nesse arquivo grande que você possui - pode ser que você esteja aguardando a conclusão da limpeza fantasma se estiver procurando imediatamente após sua operação. Paul Randal bloga sobre limpeza de fantasmas .
A exclusão de linhas em um banco de dados não diminuirá o tamanho real do arquivo de banco de dados.
Você precisa compactar o banco de dados após a exclusão da linha.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Depois de executar isso, você desejará reconstruir os índices. A redução normalmente causa a fragmentação do índice, e isso pode representar um custo de desempenho significativo.
Eu também recomendaria que, depois de reduzir, você aumentasse os arquivos novamente para ter algum espaço livre. Dessa forma, quando novas linhas chegam, elas não acionam o crescimento automático. O crescimento automático tem um custo de desempenho e é algo que você gostaria de evitar (por meio do dimensionamento adequado do banco de dados) sempre que possível.
NÃO REDUZA SEU BANCO DE DADOS!
"Por que isso acontece? Uma operação de redução de arquivo de dados funciona em um único arquivo por vez e usa os bitmaps GAM (consulte Inside The Storage Engine: GAM, SGAM, PFS e outros mapas de alocação) para encontrar a página mais alta alocada no Em seguida, ele o move para a frente do arquivo o máximo que pode, e assim por diante, e assim por diante. No caso acima, ele inverteu completamente a ordem do índice clusterizado, 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 encolhe o banco de dados para ganhar espaço (pensando que isso ajudará no desempenho), o que leva ao aumento da fragmentação (reduzindo o desempenho). o banco de dados para aumentar muito mais do que o tamanho original do banco de dados (antes de encolher). Bem, encolhendo, não se ganhava o que estava procurando normalmente."
http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increases-fragmentation-reduces-performance/
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 .
Eu encontrei isso porque acabei de excluir um monte de tabelas de backup porque meu banco de dados estava "máximo". Fiquei olhando para a propriedade "Tamanho", 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 ver era "Espaço Disponível". Estou pensando que talvez seja isso que outra pessoa precisa estar olhando para isso também.?*
Vale a pena notar também que, se a tabela tiver índices, a fragmentação pode existir após a exclusão de grandes faixas de dados. Eu tinha uma tabela hoje que tinha ~ 70 milhões de registros, levando 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 que eu reconstruí todos os índices na tabela, ele estava levando apenas 85 páginas (680kb). Depois disso, usei o shrinkfile incremental para recuperar o espaço (e corrigi o bug no sistema para evitar uma repetição).
Eu escrevi isso depois de estar exatamente no mesmo cenário e precisar reduzir o banco de dados. Eu não queria usar DBCC SHRINFKILE, então usei o método de Paul Randals para reduzir o banco de dados.
https://gist.github.com/tcartwright/ea60e0a38fac25c847e39bced10ecd04