SQL Server: banco de dados bloqueado no estado "Restaurando"

Eu fiz backup de um banco de dados:

BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing

E então tentou restaurá-lo:

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE --force restore over specified database

E agora o banco de dados está preso no estado de restauração.

Algumas pessoas teorizaram que é porque não havia um arquivo de log no backup e ele precisava ser avançado usando:

RESTORE DATABASE MyDatabase
WITH RECOVERY 

Exceto que, é claro, falha:

Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

E exatamente o que você deseja em uma situação catastrófica é uma restauração que não funcionará.

O backup contém um arquivo de dados e log:

RESTORE FILELISTONLY 
FROM DISK = 'MyDatabase.bak'

Logical Name    PhysicalName
=============   ===============
MyDatabase    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log  C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF

Você precisa usar a WITH RECOVERYopção, com seu RESTOREcomando de banco de dados , para colocar seu banco de dados online como parte do processo de restauração.

Obviamente, isso é apenas se você não pretende restaurar nenhum backup de log de transações, ou seja, você deseja apenas restaurar um backup do banco de dados e depois poder acessar o banco de dados.

Seu comando deve ficar assim,

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE,RECOVERY

Você pode ter mais sucesso usando o assistente de restauração do banco de dados no SQL Server Management Studio. Dessa forma, você pode selecionar os locais de arquivos específicos, a opção de substituição e a opção WITH Recovery.

Tive essa situação restaurando um banco de dados em uma instância do SQL Server 2005 Standard Edition usando o Symantec Backup Exec 11d. Após a conclusão da tarefa de restauração, o banco de dados permaneceu no estado "Restaurando". Não tive problemas de espaço em disco - o banco de dados simplesmente não saiu do estado "Restaurando".

Executei a seguinte consulta na instância do SQL Server e constatei que o banco de dados se tornou imediatamente utilizável:

RESTORE DATABASE <database name> WITH RECOVERY

Aqui está como você faz isso:

1. Pare o serviço (MSSQLSERVER);
2. Renomeie ou exclua os arquivos de Banco de Dados e Log (C: \ Arquivos de Programas \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...) ou onde quer que você tenha os arquivos;
3. Iniciar o serviço (MSSQLSERVER);
4. Exclua o banco de dados com problema;
5. Restaure o banco de dados novamente.

Tive um incidente semelhante ao interromper um servidor secundário de envio de logs. Após o comando para remover o servidor do envio de logs e interromper o envio do servidor primário, o banco de dados no servidor secundário ficou paralisado ao restaurar o status após o comando

RESTORE DATABASE <database name> WITH RECOVERY

As mensagens do banco de dados:

RESTORE DATABASE processou 0 páginas com êxito em 18.530 segundos (0.000 MB / s).

O banco de dados foi utilizável novamente após esses 18 segundos.

Eu tive um problema semelhante ao restaurar usando o SQL Management Studio. Tentei restaurar um backup do banco de dados para um novo com um nome diferente. No início, isso falhou e, depois de corrigir os nomes de arquivo do novo banco de dados, ele foi executado com êxito - em qualquer caso, o problema que estou descrevendo ocorreu novamente, mesmo que eu tenha acertado desde a primeira vez. Portanto, após a restauração, o banco de dados original permaneceu com um (Restaurando ...) ao lado do nome. Considerando as respostas do fórum acima (Bhusan), tentei executar no editor de consultas ao lado o seguinte:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

que corrigiu o problema. No começo, eu estava tendo problemas por causa do nome do banco de dados que continha caracteres especiais. Resolvi isso adicionando aspas duplas - aspas simples não funcionariam, fornecendo o erro "Sintaxe incorreta perto de ...".

Esta foi a solução mínima que tentei resolver esse problema (banco de dados bloqueado na restauração do estado) e espero que possa ser aplicado a mais casos.

OK, tenho um problema semelhante e, exatamente como no caso de Pauk, foi causado pelo servidor ficar sem espaço em disco durante a restauração e, portanto, causou um estado de restauração permanente. Como finalizar esse estado sem interromper os serviços do SQL Server?

Eu encontrei uma solução :)

Drop database *dbname*

A opção WITH RECOVERY é usada por padrão quando os comandos RESTORE DATABASE / RESTORE LOG são executados. Se você estiver preso no processo de "restauração", poderá retornar um banco de dados ao estado online executando:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Se houver necessidade de restauração de vários arquivos, os comandos da CLI exigirão WITH NORECOVERY e WITH RECOVERY respectivamente - somente o último arquivo no comando deve ter WITH RECOVERY para recuperar o banco de dados on-line:

RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO

Você também pode usar o assistente do SQL Server Management Studio:

Há também um processo de restauração virtual, mas você precisará usar soluções de terceiros. Geralmente, você pode usar um backup de banco de dados como banco de dados on-line ao vivo. ApexSQL e Idera têm suas próprias soluções. Revisão por SQL Hammer sobre o ApexSQL Restore . A restauração virtual é uma boa solução se você estiver lidando com um grande número de backups. O processo de restauração é muito mais rápido e também pode economizar muito espaço na unidade de disco. Você pode dar uma olhada no infográfico aqui para fazer uma comparação.

Isso pode ser bastante óbvio, mas isso me fez tropeçar agora:

Se você estiver executando um backup de log de cauda, ​​esse problema também pode ser causado pela opção verificada no assistente de restauração do SSMS - "Deixe o banco de dados de origem no estado de restauração (WITH NORECOVERY)"

Eu descobri o porquê.

Se o cliente que emitiu o RESTORE DATABASEcomando for desconectado durante a restauração, a restauração será interrompida.

É estranho que o servidor, quando solicitado a restaurar um banco de dados por uma conexão do cliente, não conclua a restauração, a menos que o cliente permaneça conectado o tempo todo.

este funcionou:

http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/8dd1b91d-3e14-4486-abe6-e3a550bfe457

Eu tive uma situação em que meu banco de dados mostrava o estado de restauração e não conseguia executar nenhuma consulta e não consegui me conectar ao nosso software.

O que eu fiz para sair dessa situação é:

1. Pare todos os serviços relacionados ao SQL dos serviços do Windows.

2. Abri a pasta DATA onde os arquivos Ldf e Mdf residem no diretório SQL, normalmente como: "C: \ Arquivos de Programas *********** \ MSSQL \ DATA

3. Depois copiei os arquivos Ldf e Mdf do banco de dados: [nome do banco de dados] .mdf e [nome do banco de dados] _log.ldf

Copiei esses dois arquivos para outra pasta.

4. Em seguida, iniciei todos os serviços relacionados ao SQL (na etapa 1) novamente a partir dos serviços do Windows.

5. Iniciei meu estúdio de gerenciamento do MS SQL com login normal.

6. Clique com o botão direito do mouse no banco de dados responsável e pressione DELETE (para excluir o banco de dados).

7. Todos os arquivos LDF e MDF relacionados a esse banco de dados foram da pasta DATA (mencionados na etapa 2).

8. Criou um novo banco de dados com o mesmo nome (o mesmo nome que eu excluí na etapa 6 - o banco de dados responsável).

9. Em seguida, [nome do banco de dados] -> clique com o botão direito do mouse -> tarefas -> Desligar.

10. Copiei os dois arquivos (da etapa 3) de volta para a pasta DATA (etapa 2).

11. [nome do banco de dados] -> clique com o botão direito do mouse -> tarefas -> Colocar Online.

Eu tive um . no nome do meu banco de dados e a consulta não funcionou por causa disso (dizendo sintaxe incorreta perto de '.'). Então percebi que precisava de um colchete para o nome:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

No meu caso, foi suficiente descartar o banco de dados que estava pendurado no estado "Restaurando ..." com o comando SQL

 drop database <dbname> 

em uma janela de consulta.

Em seguida, cliquei com o botão direito do mouse em Bancos de dados e selecione Atualizar, que removeu a entrada no Management Studio. Depois, fiz uma nova restauração que funcionou bem (observe que colocá-la offline não funcionou, a reinicialização do serviço SQL não funcionou, a reinicialização do servidor também não funcionou).

Eu tive esse problema quando também recebi um erro TCP no log de eventos ...

Solte o banco de dados com sql ou clique com o botão direito no gerenciador "delete" e restaure novamente.

Na verdade, eu comecei a fazer isso por padrão. Faça o script da queda do banco de dados, recrie e restaure.

Por padrão, todos RESTORE DATABASEvêm com a RECOVERYconfiguração. As opções 'NORECOVERY', basicamente informa ao SQL Server que o banco de dados está aguardando mais arquivos de restauração (pode ser um arquivo DIFF e um arquivo LOG e, pode incluir um arquivo de backup de log de cauda, ​​se possível). As opções 'RECUPERAÇÃO', finalizam todas as transações e deixam o banco de dados pronto para realizar as transações.

Assim:

1. se o seu banco de dados estiver configurado com o modelo de recuperação SIMPLE , você poderá executar uma restauração COMPLETA somente com a NORECOVERYopção quando tiver um backup DIFF . Nenhum backup de LOG é permitido no banco de dados do modelo de recuperação SIMPLE .
2. Caso contrário, se o seu banco de dados estiver configurado com o modelo de recuperação COMPLETO ou BULK-LOGGED , você poderá executar uma restauração COMPLETA seguida pela NORECOVERYopção, executar um DIFF seguido por NORECOVERYe, finalmente, executar a restauração LOG com a RECOVERYopção

Lembre-se de que a última consulta de restauração deve ter RECOVERYopção . Poderia ser uma maneira explícita ou não. Em termos de T-SQL, a situação:

1

 USE [master]
    GO
    RESTORE DATABASE Database_name 
    FROM DISK = N'\\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, 
    RECOVERY -- This option could be omitted.
    GO

A opção WITH REPLACE deve ser usada com cautela, pois pode levar à perda de dados

Ou, se você executar um backup COMPLETO e DIFF, poderá usar este

   USE [master]
    GO
    RESTORE DATABASE Database_name
      FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
       NOUNLOAD,NORECOVERY
    GO
    RESTORE DATABASE Database_name
      FROM DISK =N'\\path_of_**diff**backup_file.bak' WITH FILE = 1, 
     NOUNLOAD, RECOVERY
    GO

 2. USE [master]
    GO
   -- Perform a Tail-Log backup, if possible. 
   BACKUP LOG Database_name
   GO
   -- Restoring a FULL backup
   RESTORE DATABASE Database_name
    FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
     NOUNLOAD,NORECOVERY
  GO 
  -- Restore the last DIFF backup
  RESTORE DATABASE Database_name
    FROM DISK = N'\\path_of_DIFF_backup_file.bak' WITH FILE = 1,
     NORECOVERY,NOUNLOAD
  GO
  -- Restore a Log backup
  RESTORE LOG Database_name
    FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2,
    RECOVERY, NOUNLOAD
  GO

Obviamente, você pode executar uma restauração com a opção STATS = 10 que instrui o SQL Server a relatar a cada 10% concluído.

Se preferir, você pode observar o processo ou restaurar em consultas baseadas em tempo real. Como se segue:

USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time 
    FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a 
        WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO

Espero que esta ajuda.

Também pode haver problemas ao excluir um banco de dados bloqueado se a captura instantânea estiver ativada. Para mim, isso funcionou:

1. Primeiro, segui as etapas de Tipu Delacablu (leia algumas postagens)
2. comando run: drop database [seu banco de dados], que fornecerá um erro informando o nome do banco de dados de captura instantânea
3. comando de execução: solte o banco de dados [banco de dados de captura instantânea] e execute o comando na etapa 2 novamente.

Você já tentou executar um VERIFY ONLY? Apenas para garantir um backup de som.

http://msdn.microsoft.com/en-us/library/ms188902.aspx

Eu tenho o caso MyDbName (Restaurando ...) devido ao limite licenciado do SQL Express.

No arquivo de log, encontrei o seguinte:

CREATE DATABASE ou ALTER DATABASE falhou porque o tamanho cumulativo do banco de dados resultante excederia o limite licenciado de 10240 MB por banco de dados.

Portanto, se você estiver tentando restaurar um banco de dados maior, precisará mudar o servidor SQL Express para Developer Edition, por exemplo.

Ocorreu um problema semelhante ao restaurar o banco de dados usando o SQL Server Management Studio e ele ficou preso no modo de restauração. Após várias horas de rastreamento de problemas, a consulta a seguir funcionou para mim. A consulta a seguir restaura o banco de dados de um backup existente para um estado anterior. Eu acredito que o problema é o de ter o arquivo .mdf e .log no mesmo diretório.

RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY

1. Vamos verificar e executar o SQL Agent Service primeiro.

2. Usando o seguinte T-SQL:

   SELECT nome do arquivo FROM master.sys.sysaltfiles WHERE dbid = DB_ID ('db_name');

3. Usando o T-SQL continuamente:

   RESTORE DATABASE FROM DISK = 'DB_path' COM REINICIAR, SUBSTITUIR;

Espero que esta ajuda!

Todas as opções baseadas no WITH RECOVERY não funcionaram para mim.

O que fez foi a restauração completa do Management Studio.

USE [master]
RESTORE DATABASE Sales_SSD
FROM  DISK = N'D:\databaseBackups02\Daily_Sales_20150309_0941.bak' 
WITH  FILE = 1,  
MOVE N'Sales_Data' TO N'C:\Data\SSD\Sales.mdf',  
MOVE N'Sales_Log' TO N'C:\Data\SSD\Sales_1.ldf',  
NOUNLOAD,  REPLACE,  STATS = 5

Eu tive o mesmo problema ... embora eu não saiba por que meu banco de dados teve esse problema, pois minha unidade não estava cheia ... É como se estivesse corrompida ou algo assim. Eu tentei todas as opções acima, nenhuma delas funcionou totalmente, pensei especialmente na sugestão de interromper o serviço e excluir os arquivos mdf e ldf funcionaria ... mas ainda congelou na restauração?

Acabei resolvendo isso excluindo os arquivos conforme mencionado, mas em vez de tentar restaurar o banco de dados novamente, copiei os arquivos .mdf e .ldf frescos e os anexei usando o assistente de Front End Attachment. Alívio, funcionou !!

Sempre foi necessário copiar os novos arquivos, pois estou usando uma máquina virtual ... então, copiar e colar usando a área de transferência levou uma hora, então eu recomendaria isso apenas como uma última tentativa.

O que foi corrigido para mim foi

1. parando a instância
2. criando um backup dos arquivos .mdf e .ldf na pasta de dados
3. Reinicie a instância
4. excluir o banco de dados preso restauração
5. coloque os arquivos .mdf e.ldf novamente na pasta de dados
6. Anexe a instância aos arquivos .mdf e .ldf

RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY

Use o seguinte comando para resolver esse problema

RESTORE DATABASE [DatabaseName] WITH RECOVERY