Quando o database do SophiA apresentar o erro “Suspect”, se os dados ainda não estiverem restaurados no Enterprise Manager e você só possuir os arquivos de dados e de log com problemas (.MDF e .LDF), é preciso realizar os seguinte passos:
1 - No Enterprise Manager, criar um database com o mesmo nome do database do cliente, e assim gerar os arquivos com os mesmos nomes
2 - Parar o SQL Server
3 - Sobrepor os arquivos do novo database com os arquivos com problemas
4 - Iniciar o SQL Server
No Enterprise Manager, o database deverá aparecer como SUSPECT.
- Após esse procedimento, executar os passos descritos na Solução 2:
Solução 2:
1 - Configurar o SQL Server para permitir alterações nas tabelas de sistema. É possível alterar de duas formas:
Via Query Analyzer:
- Use Master
- GO
- sp_configure 'allow updates', 1
- reconfigure with override
- GO
Via Enterprise Manager:
- Clicar com o botão direito sobre o servidor e selecionar a opção Propriedades
- Na aba "Configurações do Servidor", marcar a opção "Permitir que modificações sejam feitas diretamente nas tabelas do sistema":
2 - Acessar o Query Analyzer e colocar o database em EMERGENCY MODE:
- Use Master
- GO
- begin tran
- update sysdatabases set status = 32768 where name = 'Nome do database com problema'
- Verify one row is updated before committing
- commit tran
3 - Parar o SQL Server.
4 - Ir na pasta onde se encontram os dados e renomear o arquivo de log com problema;
5 - Iniciar o SQL Server.
6 - Recriar o arquivo de log:
DBCC REBUILD_LOG('Nome do database com problema', 'Caminho + nome do arquivo de log')
GO
Exemplo: DBCC REBUILD_LOG('Biblioteca', 'D:\Base\SQL\Biblioteca_Log.LDF')
Os passos 7, 10 a 13 devem ser executados no Query Analyzer, com o database Master selecionado.
7 - Alterar as configurações do database com problema, (os procedimentos abaixo devem ser executados no Query Analyzer, com o database Master selecionado:
sp_dboption 'Nome do database com problema', 'dbo use only', 'false'
GO
sp_dboption 'Nome do database com problema', 'single user', 'true'
GO
8 - Parar o SQL Server
9 - Iniciar o SQL Server
10 - Reparar o database com problema:
DBCC CHECKDB ('Nome do database com problema', REPAIR_ALLOW_DATA_LOSS)
GO
11 - Dependendo do resultado do comando CHECKDB, reparar as tabelas com problemas. Rodar o comando DBREINDEX para cada tabela:
DBCC DBREINDEX ('Database.Login.Tabela com problema')
GO
Exemplo: DBCC DBREINDEX ('Biblioteca.Biblioteca.Dic_Obra')
Em alguns casos, pode ser necessário utilizar o comando CHECKTABLE.
12 - Verificar que tudo foi reparado com sucesso:
DBCC CHECKDB ('Nome do database com problema') with ALL_ERRORMSGS, NO_INFOMSGS
GO
Exemplo: DBCC CHECKDB ('Biblioteca') with ALL_ERRORMSGS, NO_INFOMSGS
13 - Alterar as configurações do database com problema:
sp_dboption 'Nome do database com problema', 'single user', 'false'
GO
14 - Configurar o SQL Server para NÃO permitir alterações nas tabelas de sistema. É possível alterar de duas formas:
Via Query Analyzer:
Use Master
GO
sp_configure 'allow updates', 0
reconfigure with override
GO
Via Enterprise Manager:
- Clicar com o botão direito sobre o servidor e selecionar a opção Propriedades.
- Na aba "Configurações do Servidor", DESMARCAR a opção "Permitir que modificações sejam feitas diretamente nas tabelas do sistema".