Você pode descobrir todos esses eventos que estão no ciclo atual do log de eventos usando sp_readerrorlog
:
EXEC sys.sp_readerrorlog @p1 = 0, @p2 = 1, @p3 = N'OFFLINE';
Você pode percorrer os valores de @p1
se não o encontrar no log de eventos atual. Por padrão, você deve poder ler os 6 arquivos de log de erros atuais e anteriores, portanto, use 0-6 como argumentos para voltar o mais longe possível (no meu sistema não foi possível obter 0
/ NULL
agregar em todos os arquivos de log; YMMV )
Retornará algo como isto:
LogDate ProcessInfo Text
------------- ----------- ---------------------------------------------------------
yyyy-mm-dd... spid72 Setting database option OFFLINE to ON for database 'foo'.
É claro que há uma chance de o log de erros ser preenchido o suficiente para que o (s) evento (s) tenha ocorrido antes do conjunto atual de logs de erros. Nesse caso, você está sem sorte. Para manter um histórico de execução mais longo no futuro, você pode alterar o número de logs de erros que são mantidos. No Pesquisador de Objetos, expanda Gerenciamento, clique com o botão direito do mouse em Logs do SQL Server e escolha Configurar. Lá, você pode alterar as configurações de reciclagem do arquivo de log de erros, incluindo manter os 99 arquivos anteriores. Veja também esta resposta .
Observe que não sp_readerrorlog
há documentos e não há suporte, embora muitas pessoas tenham escrito sobre isso . No final, os arquivos de log de erros são apenas arquivos de texto sem formatação, então você pode escrever seu próprio PowerShell, CLR etc., que apenas analisa os arquivos e retorna as mesmas informações. Você pode determinar onde estão os arquivos de log de erros para esta instância usando:
SELECT SERVERPROPERTY('ErrorLogFileName');
Os arquivos serão nomeados ERRORLOG
, ERRORLOG.1
, ERRORLOG.2
, etc. Você pode ir e abrir os arquivos em um editor de texto básico para ver a estrutura, embora eu seria cauteloso sobre a abertura do arquivo atual em uso ( ERRORLOG
).