Como restaurar um banco de dados do SQL Server e encolher seus arquivos ao mesmo tempo?

Question

Digamos que eu tenha um banco de dados do SQL Server cujos arquivos de dados tenham sido criados com um tamanho inicial de 100 GB, mas ele contém apenas 10 GB de dados. Um backup de banco de dados terá então apenas 10 GB de tamanho.

Eu quero restaurar esse backup para um servidor diferente (ou um banco de dados diferente no mesmo servidor), mas não quero que ele ocupe o mesmo espaço em disco que o original (100 GB), que é o que acontece por padrão.

Eu não posso reduzir o banco de dados original antes de fazer um backup (é um banco de dados de produção, e ele precisa de muito espaço pré-alocado); Eu poderia reduzir o banco de dados restaurado após a restauração ser feita, mas eu realmente preferiria que não ocupasse 100 GB enquanto fazia isso; Além disso, neste cenário específico, eu não tenho muito espaço livre em disco, então a restauração não vai a lugar nenhum.

Existe alguma maneira de restaurar o banco de dados e ele ocupa apenas o espaço que os dados que ele contém ?

    

Answer 1

Não, desculpe - de jeito nenhum. Restaurar restaura arquivos como estavam no backup. Schinking tem que ser feito depois disso ou antes de fazer o backup.

    

Answer 2

Se você tiver muito espaço em disco, poderá colocar o arquivo .bak em um compartilhamento de rede & restaurá-lo de lá. Deve funcionar se o seu servidor SQL em execução tiver uma conta de domínio & dê à parte direitos suficientes para ler o arquivo.

A outra opção que estava anteriormente na cesta "Você está louco" (mas útil apenas se o seu SQL Server 2008 r2) é que o SQL Server suporta a criação de arquivos de banco de dados diretamente para um compartilhamento sem ter que usar um rastreador ; Eu posso dizer pela experiência pessoal que você trabalha! Então você pode fazer uma restauração WITH MOVE para um compartilhamento.

    

Answer 3

De um modo geral, não. Algumas ideias aleatórias que podem ou não ajudá-lo:

• A menos que você realmente precise de dados de esse backup específico , poderá criar um novo banco de dados (vazio) do tamanho de destino e usar cópias em massa (ou SSIS) para empurrar todas as tabelas do atual banco de dados (ao vivo) em sua cópia.
• Existem ferramentas de terceiros (Redgate Compare, por exemplo) que podem ajudar a automatizar esse tipo de coisa, se isso for mais do que uma operação única.
• Alguns softwares de backup de terceiros (Quest Litespeed, por exemplo) têm a capacidade de fazer uma " recuperação em nível de objeto ", que pode restaurar tabelas individuais ou outros objetos para um novo (vazio) base de dados. Mesmo que o backup não tenha sido criado usando o Litespeed, acredito que o produto funcione em backups nativos do SQL.

Por fim, também gosto de uma "sala de cotovelo" em meus bancos de dados de produção, mas 90 GB livres de 100 GB no total soam um pouco extremos. As etapas a seguir podem fornecer o que você precisa e não deve impactar a produção:

1. Execute um DBCC SHRINKFILE ('myfile.MDF', TRUNCATEONLY) no arquivo de dados de produção para liberar temporariamente qualquer espaço livre no final do arquivo (um TRUNCATEONLY não é intensivo em E / S e não fragmentará os índices)
2. Se o arquivo de log também for grande, execute um DBCC SHRINKFILE no arquivo de log de produção durante um período de baixa atividade, logo após fazer um backup de log.
3. Execute seu backup
4. Execute um ALTER DATABASE MODIFY FILE para aumentar novamente o arquivo de dados de produção para o tamanho original.

Não deve haver nenhum impacto na produção usando essas etapas. O único risco é se alguns dos dados estiverem no final do arquivo de dados de 100 gb, caso em que o Step (1) não liberará muito se houver espaço.