Usuário com melhor resposta
Restauração de base demora horas

Pergunta
-
Bom dia pessoal,
Aqui na empresa utilizamos o SQL Server 2008 e para determinada base de dados a restauração de backups da mesma demora muito. Mas é algo ABSURDO, da ordem de horas!
Outras bases que temos aqui, com estrutura bem similar e também com a massa de dados similar (as vezes até BEM MAIS) são restauradas em até 3 minutos.
Então gostaria de saber se alguém já passou por isso ou sabe o que pode estar ocorrendo.
Quem souber, por favor me responda o mais breve possível.
Obrigado!
[]'s,
Vinícius.
Respostas
-
Vinícius,
O tamanho do Log influencia sim, certa vez tive problemas com a implementação de mirroring na hora de subir os backups no segundo servidor. Fui ver e era o tamanho...
É possível sim truncar o arquivo de log, como está rodando o SQL Server 2008, execute esse procedimento:
--Verifique o recovery model do database, caso nao seja Simple, execute o trecho abaixo:
-- Defininindo o Recovery Model do database como Simple
USE [master]
GO
ALTER DATABASE [Teste] SET RECOVERY SIMPLE WITH NO_WAIT
GO-- Truncando o arquivo de Log
USE [Teste]
GO
DBCC SHRINKFILE (N'Teste_log' , 100) -- Nome do arquivo de log e tamanho em Mb
GO-- Caso o recovery model do database seja Full antes desse script, execute esse trecho abaixo:
-- Defininindo o Recovery Model do database como Full
USE [master]
GO
ALTER DATABASE [Teste] SET RECOVERY FULL WITH NO_WAIT
GO--Após esse procedimento, execute um backup FULL do database
Att,
De Lima - MCITP SQL Server 2005/2008- Sugerido como Resposta De Lima terça-feira, 20 de abril de 2010 19:00
- Marcado como Resposta Vinícius Oliveira terça-feira, 20 de abril de 2010 21:38
Todas as Respostas
-
-
Vinícius,
O que esta base tem de diferença em relação as outras bases de dados?
Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário] -
Bom dia Diogo,
Aqui somos empresa de software, de toda forma, sim, eu tento a restauração em horário comercial.
Aliás, já restaurei essa base também fora do horário comercial, no período noturno (quando apenas meu usuário estava conectado ao SQL Server) e da mesma forma demorou MUITO.
Logo, acredito que o problema não seja referente a sobrecarga no servidor.
O restore é full e o banco está em modo multi_user.
Você tem idéia do que possa ser o problema da demora?
[]'s,
Vinícius. -
Bom dia Junior,
Pois é. Não noto o que há de diferente nessa base.
Inicialemente eu pensava que poderia ser alguma propriedade herdada do SQL Svr 2005 que fazia com que a base demorasse a ser restaurada na versão 2008.
Mas as demais bases, que são rapidamente restauradas, também são provenientes da versão 2005.
Logo, não faço idéia do que essa base a que me refiro tenha de diferente em relação às demais.
Você já viu uma base demorar tanto para ser restaurada? O backup dela tem em torno de 1.5 GB.
Outra coisa importante que me esqueci de mencionar antes com vocês é que o processo de restauração flui normalmente até chegar aos 100%. Chega nos 100% e aí fica por horas rodando para só depois concluir.
Faz idéia do que possa ser?
[]'s,
Vinícius. -
Vinicius,
Experimente fazer o restore desse backup em um outro servidor...
Qual é o tamanho físico dos arquivos mdf e ldf dessa base?
Como estão os níveis de compatibilidade desses databases, foram atualizados para 2008 (100)?
Att,
De Lima - MCITP SQL Server 2005/2008- Sugerido como Resposta De Lima terça-feira, 20 de abril de 2010 19:00
-
Boa tarde De Lima,
Eu já havia recuperado a base em outro servidor pra testar e o problema persiste.
Mas você me questionou o tamanho dos arquivos físicos da base e quando fui verificar eu me surpreendi.
Pois o arquivo de log, LDF, está com 35.859.712 KB.
Já o MDF tem 1.762.688 KB.
Será que o problema está relacionado ao tamanho do LDF?
Eu não sei como funciona o processo no SQL Server, há como eu reduzir o tamanho do LDF?
Aguardo retorno.
Obrigado.
[]'s,
Vinícius. -
Vinícius,
O tamanho do Log influencia sim, certa vez tive problemas com a implementação de mirroring na hora de subir os backups no segundo servidor. Fui ver e era o tamanho...
É possível sim truncar o arquivo de log, como está rodando o SQL Server 2008, execute esse procedimento:
--Verifique o recovery model do database, caso nao seja Simple, execute o trecho abaixo:
-- Defininindo o Recovery Model do database como Simple
USE [master]
GO
ALTER DATABASE [Teste] SET RECOVERY SIMPLE WITH NO_WAIT
GO-- Truncando o arquivo de Log
USE [Teste]
GO
DBCC SHRINKFILE (N'Teste_log' , 100) -- Nome do arquivo de log e tamanho em Mb
GO-- Caso o recovery model do database seja Full antes desse script, execute esse trecho abaixo:
-- Defininindo o Recovery Model do database como Full
USE [master]
GO
ALTER DATABASE [Teste] SET RECOVERY FULL WITH NO_WAIT
GO--Após esse procedimento, execute um backup FULL do database
Att,
De Lima - MCITP SQL Server 2005/2008- Sugerido como Resposta De Lima terça-feira, 20 de abril de 2010 19:00
- Marcado como Resposta Vinícius Oliveira terça-feira, 20 de abril de 2010 21:38
-
-
Vinicius, Boa Noite!
Já tive um caso semelhante e o problema era a configuração de Restore dos FullText Indexes da Base de Dados. Verifique se essa base de dados possui FullText Indexes em Storage.
Se for isso, se atente a localização que você está informando no comando de Restore.
Juliano Horta