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

Digamos que eu tenho um banco de dados do SQL Server cujos arquivos de dados foram criados com um tamanho inicial de 100 GB, mas contém apenas 10 GB de dados. Um backup do banco de dados terá apenas 10 GB de tamanho.

Desejo restaurar esse backup em um servidor diferente (ou em 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.

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

Existe alguma maneira de restaurar o banco de dados e ocupar apenas tanto espaço quanto os dados reais que ele contém ?

Não, desculpe - de jeito nenhum. A restauração restaura os arquivos como estavam no backup. Schinking deve ser feito depois disso ou antes de fazer o backup.

Se você tiver pouco espaço em disco, poderá colocar o arquivo .bak em um compartilhamento de rede e restaurá-lo a partir daí. Deve funcionar se o seu servidor sql em execução com uma conta de domínio e conceder ao compartilhamento 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 em execução) é que o SQL Server suporta a criação de arquivos de banco de dados diretamente em um compartilhamento sem a necessidade de usar um traceflag; da experiência pessoal você trabalha! Assim, você pode fazer uma restauração com o MOVE em um compartilhamento.

De um modo geral, não. Algumas idéias aleatórias que podem ou não ser úteis para você:

• A menos que você precise absolutamente de dados desse backup específico , crie um novo banco de dados (vazio) do tamanho de destino e use cópias em massa (ou SSIS) para enviar todas as tabelas do banco de dados (ativo) atual para sua cópia.
• Existem ferramentas de terceiros (Redgate Compare, por exemplo) que podem ajudar a automatizar esse tipo de coisa, se 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 no nível do objeto ", que pode restaurar tabelas individuais ou outros objetos em um novo banco de dados (vazio). Mesmo que o backup não tenha sido criado usando o Litespeed, acredito que o produto funcione em backups nativos do SQL.

Finalmente, eu também gosto de "espaço livre" nos meus bancos de dados de produção, mas 90 GB livres de 100 GB no total parecem um pouco extremos. As etapas a seguir podem fornecer o que você precisa e não deve afetar 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 exige muito IO e não fragmentará índices)
2. Se o arquivo de log também for grande, execute um DBCC SHRINKFILEno arquivo de log de produção durante um período de baixa atividade, logo após fazer um backup do log.
3. Execute seu backup
4. Faça um ALTER DATABASE MODIFY FILEpara 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 é que alguns dos dados estejam no final do arquivo de 100 GB, caso em que a Etapa (1) não liberará muito espaço.