O banco de dados inicia sempre no modo de recuperação

Sempre que reinicio o servidor, o banco de dados está sempre no modo de recuperação e leva cerca de 20 minutos para se comportar normalmente. Isso sempre e sempre acontece quando eu reinicio o servidor, então eu tenho algumas perguntas ...

1. Foi-me dito que isso poderia ser causado por um grande arquivo de log? Isso pode estar correto? Caso contrário, quais poderiam ser as outras causas?
2. Preciso diminuir o espaço do arquivo de log para evitar recuperações. O que é melhor: encolhendo ou truncando?
3. Como posso reduzir ou truncar um arquivo de log / banco de dados para diminuir o tamanho? Qual é a sintaxe?

Atualmente, estou usando o Microsoft SQL Server 2008.

Tenho o mesmo problema e acredito que o resolvi, mas não pude testá-lo completamente para confirmar.

Acredito que os problemas estejam relacionados ao número de VLFs que você possui no arquivo de log e não ao seu tamanho. Se você tiver um grande arquivo de log, é provável que ele tenha crescido organicamente através de eventos de crescimento automático e que não foi um crescimento planejado intencional. Se for esse o caso, você pode ter milhares de VLFs dentro dos arquivos de log.

Aqui está uma consulta para ver quantos VLFs você tem que usei aqui :

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

Para uma explicação mais detalhada do que são as VLFs, consulte este link .

Acredito que o problema é que, com tantas VLFs, o SQL Server leva muito tempo para avaliar seu estado e depois recuperar o banco de dados da recuperação. Se você reduzir o arquivo de log para o menor tamanho possível, geralmente o tamanho do primeiro VLF que foi criado no arquivo de log, você poderá imediatamente aumentá-lo intencionalmente novamente e, assim, criar o número certo de VLFs (algo menor que 16)

Quando isso estiver concluído, acredito que você poderá ver que seu banco de dados sai da recuperação muito mais rapidamente.

Não tive a chance de testar o failover de nossas instâncias de produção depois que resolvi nossos próprios problemas de VLF, portanto, ficaria muito curioso para confirmar se essa é a causa raiz do problema. Experimentalmente, vi o tempo que leva para sair da restauração em nosso ambiente de preparação reduzido drasticamente devido a isso, espero que seja isso.

Neste artigo do MSDN :

Transações não confirmadas de longa execução aumentam o tempo de recuperação para todos os tipos de pontos de verificação.

Geralmente, não é recomendável executar qualquer tipo de arquivo shrink DBCC nos bancos de dados de produção. O comportamento do truncamento de log também foi alterado das versões anteriores para 2008 (obrigado @Edward) - de acordo com este blog :

O log de backup com trucate_only não é mais suportado no SQL 2008. Se seu banco de dados estiver no modelo de recuperação em massa ou com recuperação completa, agende o backup do T-Log em intervalos regulares e manterá seu t-log em forma.

Mais uma vez, vou mencionar, com que frequência você faz backup do banco de dados? Normalmente, os backups regulares "gerenciam" melhor o tamanho do log.

Reduzir o tamanho do log de transações online pode resolver o problema, ou seja, acelerar o banco de dados, mas você deve pensar na recuperação de desastres antes de fazer isso. Observe que se você estiver no modelo de recuperação simples, não poderá restaurar para um ponto no tempo. Por outro lado, se você estiver no modelo de recuperação COMPLETO, a melhor maneira de manter o tamanho do log de transações on-line é criar o backup do log de transações regularmente (agende-o).

Truncar o log de transações não libera espaço físico no disco rígido, apenas permite que o SQL Server reutilize esse espaço para transações que ocorreram desde o último CHEKPOINT (desde o último backup do log de transações).

Se você reduzir o banco de dados, reduzirá o tamanho dos arquivos. Para reduzir o banco de dados MyDB em 15%:

DBCC SHRINKDATABASE (MyDB, 15); IR