SQL Server: database preso no estado “Restaurando”

Eu fiz backup de um database:

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

E então tentei restaurá-lo:

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

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

Algumas pessoas teorizaram que é porque não havia 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ê quer em uma situação catastrófica é uma restauração que não funciona.


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 opção WITH RECOVERY , com o comando RESTORE database, para colocar seu database online como parte do processo de restauração.

Isto é claro, apenas se você não pretende restaurar quaisquer backups de log de transactions, ou seja, você só deseja restaurar um backup de database e, em seguida, ser capaz de acessar o database.

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 de database 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. Às vezes, o processo de restauração ficou preso apenas por causa do tamanho do arquivo de database. veja aqui: https://madhivanan.wordpress.com/2016/09/06/issue-in-recovering-a-database-that-is-in-the-restoring-state-reference/

Eu tive essa situação restaurando um database para uma instância do SQL Server 2005 Standard Edition usando o Symantec Backup Exec 11d. Depois que o trabalho de restauração foi concluído, o database permaneceu em um estado “Restaurando”. Não tive problemas de espaço em disco – o database simplesmente não saiu do estado “Restaurando”.

Eu executei a consulta a seguir com relação à instância do SQL Server e descobri que o database tornou-se imediatamente utilizável:

 RESTORE DATABASE  WITH RECOVERY 

Veja como você faz isso:

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

Boa sorte!

Eu tive um incidente semelhante ao parar um servidor secundário de envio de log. Após o comando para remover o servidor do envio de log e interromper o envio de log do servidor principal, o database no servidor secundário ficou preso ao restaurar o status após o comando

 RESTORE DATABASE  WITH RECOVERY 

As mensagens do database:

RESTORE DATABASE processou com sucesso 0 páginas em 18,530 segundos (0,000 MB / seg).

O database pode ser usado novamente após esses 18 segundos.

Eu tive um problema semelhante com a restauração usando o SQL Management Studio. Eu tentei restaurar um backup do database para um novo com um nome diferente. No começo, isso falhou e depois de consertar os nomes dos arquivos do novo database, ele foi executado com sucesso – em qualquer caso, o problema que estou descrevendo ocorreu novamente mesmo se eu acertei da primeira vez. Assim, após a restauração, o database original permaneceu com um (restaurando …) ao lado de seu nome. Considerando as respostas do fórum acima (Bhusan’s) eu tentei rodar no editor de consultas do lado a seguir:

 RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]" 

que resolveu o problema. Eu estava tendo problemas no início por causa do nome do database que continha caracteres especiais. Eu resolvi isso adicionando aspas duplas – aspas simples não funcionariam dando um erro “Sintaxe incorreta próxima …”.

Esta foi a solução mínima que tentei resolver esse problema (database preso no estado de restauração) e espero que possa ser aplicado a mais casos.

OK, eu tenho problema semelhante e exatamente como foi no caso de Pauk, foi causado pelo servidor ficar sem espaço em disco durante a restauração e assim causou um estado de restauração permanente. Como terminar este estado sem parar 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á recuperar um database para o estado on-line, 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 deverá ter WITH RECOVERY para retornar o database 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:

insira a descrição da imagem aqui

Há também um processo virtual de restauração, mas você terá que usar soluções de terceiros. Normalmente você pode usar um backup de database como database online ao vivo. O ApexSQL e o Idera possuem 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 alguma comparação.

Isso pode ser bastante óbvio, mas me atrapalhou agora:

Se você estiver realizando um backup do log final, esse problema também pode ser causado por essa opção ter sido marcada no assistente Restauração do SSMS – “Deixar o database de origem no estado de restauração (WITH NORECOVERY)”

insira a descrição da imagem aqui

Eu descobri o porquê.

Se o cliente que emitiu o RESTORE DATABASE desconectar durante a restauração, a restauração será paralisada.

É estranho que o servidor, quando instruído a restaurar um database por uma conexão de cliente, não termine a restauração a menos que o cliente permaneça conectado o tempo todo.

este fez um trabalho:

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

Eu tive uma situação em que meu database mostrou estado de restauração e não consegui executar nenhuma consulta e não consegui me conectar com nosso software.

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

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

  2. Eu abri a pasta DATA onde os arquivos Ldf e Mdf residem no diretório SQL, normalmente é como: “C: \ Program Files *********** \ MSSQL \ DATA

  3. Em seguida, copiei os arquivos Ldf e Mdf do database: [nome do database] .mdf e [nome do database] _log.ldf

Eu copiei esses dois arquivos para outra pasta.

  1. Então eu comecei todos os serviços relacionados SQL (na etapa 1) novamente a partir de serviços do Windows.

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

  3. Clique com o botão direito do mouse no database culpado e clique em EXCLUIR (para excluir o database).

  4. Todos os arquivos LDF e MDF relacionados a este database passaram da pasta DATA (mencionada na etapa 2).

  5. Criado um novo database com o mesmo nome (mesmo nome do que eu deletei no passo 6 – o database culpado).

  6. Em seguida, [nome do database] -> clique com o botão direito -> tarefas -> Colocar off-line.

  7. Em seguida, copiei os dois arquivos (da etapa 3) de volta para a pasta DATA (etapa 2).

  8. [nome do database] -> clique com o botão direito -> tarefas -> Colocar on-line.

Eu tive um . no meu nome do database, ea consulta não funcionou por causa disso (dizendo syntax incorreta perto de ‘.’) Então percebi que eu preciso de um suporte para o nome:

 RESTORE DATABASE [My.DB.Name] WITH RECOVERY 

Eu tive esse problema quando eu também recebi um erro TCP no log de events …

Largar o database com o SQL ou clique com o botão direito no gerenciador “delete” e restaurar novamente.

Eu comecei a fazer isso por padrão. Script o DB drop, recriar e depois restaurar.

Também pode haver problema ao excluir um database bloqueado se a captura instantânea estiver ativada. Para mim isso funcionou:

  1. Primeiro eu segui os passos do Tipu Delacablu (leia alguns posts acima)
  2. comando de execução: descartar o database [seu database], que fornecerá um erro informando o nome do database de captura instantânea
  3. execute o comando: solte o database [database de instantâneos] e, em seguida, execute o comando na etapa 2 novamente.

Por padrão, todo RESTORE DATABASE vem com a configuração RECOVERY . As opções ‘NORECOVERY’, basicamente, informa ao SQL Server que o database está aguardando mais arquivos de restauração (pode ser um arquivo DIFF e um arquivo LOG e, se possível, pode include um arquivo de backup final do log). As opções de ‘RECUPERAÇÃO’, terminam todas as transactions e deixam o database pronto para realizar transactions.

Assim:

  1. Se o database estiver configurado com o modelo de recuperação SIMPLE , você só poderá executar uma restauração COMPLETA com a opção NORECOVERY , quando houver um backup DIFF . Nenhum backup de LOG é permitido no database do modelo de recuperação SIMPLE .
  2. Caso contrário, se seu database estiver configurado com o modelo de recuperação FULL ou BLOQUEADO , você poderá executar uma restauração COMPLETA seguida pela opção NORECOVERY , executar um DIFF seguido por NORECOVERY e, por último, executar a restauração LOG com a opção RECOVERY .

Lembre-se, a última consulta de restauração deve ter opção de RECOVERY . Pode ser uma maneira explícita ou não. Em therms 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 cuidado, 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 
  1. 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

Naturalmente, você pode executar uma restauração com a opção STATS = 10 que informa ao SQL Server para informar cada 10% concluído.

Se preferir, você pode observar o processo ou restaurar a consulta 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.

No meu caso, foi suficiente para soltar o database que estava pendurado no estado “Restaurando …” com o comando SQL

  drop database  

em uma janela de consulta.

Em seguida, cliquei com o botão direito do mouse em Bancos de dados e selecionei a opção Atualizar, que removeu a input no Management Studio. Depois eu fiz uma nova restauração que funcionou bem (note que trazê-lo offline não funcionou, uma reboot do serviço SQL não funcionou, uma reboot do servidor não funcionou tão bem).

Você já tentou executar um VERIFICAR SOMENTE? Só para ter certeza que é um backup de som.

http://msdn.microsoft.com/pt-br/library/ms188902.aspx

  1. Vamos verificar e executar o SQL Agent Service em primeiro lugar.
  2. Usando o seguinte T-SQL:

    SELECT filename FROM master.sys.sysaltfiles WHERE dbid = DB_ID (‘nome_bd’);

  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 foi fazer 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 sei porque meu database experimentou este problema como o meu disco não estava cheio … É como se tivesse corrompido ou algo assim. Eu tentei todos os itens acima nenhum deles totalmente trabalhado, eu pensei especialmente que a sugestão para parar o serviço e excluir os arquivos mdf e ldf funcionaria … mas ainda congelou na restauração?

Acabei resolvendo isso excluindo os arquivos como mencionado, mas em vez de tentar restaurar o database novamente, copiei os arquivos .mdf e .ldf recentes e os Anexei usando o assistente de anexo de front-end. Alívio, funcionou !!

Demorou SEMPRE para copiar os novos arquivos como eu estou usando uma máquina virtual … para copiar e colar usando a área de transferência demorou uma hora em si, então eu só recomendaria isso como uma última tentativa.

Eu tenho o caso MyDbName (Restaurando …) por causa do limite licenciado do SQL Express.

No arquivo de log, encontrei isto:

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

Portanto, se você estiver tentando restaurar um database maior, será necessário alternar seu servidor SQL Express para a edição Developer, por exemplo.

    Intereting Posts