Restaure o backup MSSQL que foi feito com a opção NO_LOG

2

Estou fazendo o script da cópia dos bancos de dados de um servidor para outro. Ambos estão executando o SQL Server 2005 e os bancos de dados estão no modo de recuperação total.

Os logs de transações nesses bancos de dados podem ficar muito grandes e eu não preciso deles no servidor para o qual eles estão sendo copiados. (ou seja, eu não preciso restaurar a qualquer momento, só quero uma cópia do banco de dados no momento em que o backup foi realizado). Então, se possível, eu gostaria de evitar o tempo necessário para executar o backup de log, copiar em uma rede lenta e restaurar.

Estou tentando usar a opção de backup "NO_LOG" para conseguir isso. Isso produz um backup ok, mas quando tento restaurar o backup no servidor de destino, o banco de dados permanece no estado 'Restaurando' e não pode ser acessado. Estou assumindo que isso é porque espera que eu restaure os logs de transação.

Existe alguma maneira de contornar isso e criar um novo log de transações vazio? Observe que não posso apenas truncar os logs de transação no servidor de origem antes de fazer um backup (sem NO_LOG), pois eles são importantes.

Se não existem outras opções para obter uma cópia de um banco de dados diferente de backup / restauração? Eu já tentei o método "transfer", que faz o script de todos os objetos e dados, mas isso é muito lento para as minhas necessidades devido ao grande número de objetos.

Obrigado

Edit: Aqui estão os comandos usados

BACKUP DATABASE FrontEnd TO DISK='c:\somepath\abackup.bak' WITH NO_LOG, COPY_ONLY

RESTORE DATABASE FrontEnd FROM Disk='c:\somepath\abackup.bak' WITH RECOVERY

A resposta para este comando é

Processed 1944 pages for database 'FrontEnd', file 'DimensionPrototype' on file 1.
The database cannot be recovered because the log was not restored.
This RESTORE statement successfully performed some actions, but the database could not be brought online because one or more RESTORE steps are needed. Previous messages indicate reasons why recovery cannot occur at this point.
RESTORE DATABASE ... FILE=<name> successfully processed 1944 pages in 0.923 seconds (17.253 MB/sec).
    
por rnwood 14.10.2009 / 13:40

3 respostas

0

Espero que a maneira mais fácil de fazer isso seja reduzir o log de transações do banco de dados do Frontend para seu tamanho inicial e fazer backup do banco de dados e, em seguida, aumentar o log de transações para um tamanho apropriado.

Você deve fazer isso em um momento tranquilo em que a atividade transacional mínima está acontecendo.

    
por 14.10.2009 / 14:48
2

Você não precisa usar NO_LOG com a opção COPY_ONLY para realizar isso. O backup completo COPY_ONLY será suficiente para restaurar com recuperação. Quando você restaurar o banco de dados, ele criará os arquivos de log e dados nos tamanhos em que estavam quando o backup foi feito. Você não pode contornar isso. NO_LOG está truncando seu log de transações, portanto, não é possível fazer uma recuperação pontual do banco de dados principal depois de executar isso. Você precisa iniciar seu backup através de um backup completo padrão se você tiver emitido este comando.

    
por 14.10.2009 / 14:37
1

Primeiro, parece haver algum equívoco aqui de que todo o log de transações (arquivo .ldf) é finalizado no arquivo de backup. Este não é o caso. O SQL Server copia o suficiente do log de transações para que a operação de restauração possa recuperar o banco de dados.

O motivo pelo qual você não pode restaurar o banco de dados é porque você precisa restaurar um backup de log sobre o backup que acabou de restaurar para permitir que o banco de dados execute uma recuperação. O SQL Server não pode colocar um banco de dados online a partir de uma restauração sem um backup de log. Para obter mais informações, consulte este artigo ms kb .

Não há como evitar isso. Suga e & vai comprar mais espaço em disco.

    
por 15.10.2009 / 14:49