Estou trabalhando em como funcionam as auditorias do SQL Server e gostaria de esclarecer como funcionam as opções QUEUE_DELAY. BOL define as opções como:
Determina o tempo, em milissegundos, que pode decorrer antes que as ações de auditoria sejam forçadas a serem processadas. Um valor de 0 indica entrega síncrona. O valor mínimo de atraso de consulta configurável é 1000 (1 segundo), que é o padrão. O máximo é 2.147.483.647 (2.147.483,647 segundos ou 24 dias, 20 horas, 31 minutos, 23,647 segundos). A especificação de um número inválido gerará o erro MSG_INVALID_QUEUE_DELAY.
Onde estão essas ações enfileiradas tempdb, uma tabela de sistema, etc? Posso consultar esse local para ver quantos itens estão na fila? Se a opção ON_FAILURE for definida para desligar o servidor, esses itens serão registrados na auditoria assim que o servidor for reiniciado e o local puder ser acessado novamente?
O SQL Server Audit aproveita a nova arquitetura Extended Events introduzida em 2008.
Se você observar os DMVs a seguir, poderá ver as estruturas relacionadas exibidas quando a auditoria for iniciada.
Observe que as auditorias têm seu próprio conjunto de alvos especiais, que não podem ser usados diretamente por meio de eventos estendidos. Se você começar a gerar alguns eventos de auditoria, verá os eventos exibidos no destino real, mas, diferentemente de um destino de buffer de anel, eles não aparecem na
target_data
coluna do DMV por motivos de segurança.Dito isso, não está claro (e aparentemente não documentado) como os alvos da sessão de auditoria funcionam internamente. Com base no fato de que a auditoria é criada em eventos estendidos e, dadas as opções de comportamento para quando a auditoria falhar, presumo que os destinos de auditoria sejam simplesmente destinos de buffer de anel modificados que não expõem os dados do evento de volta ao SQL Server. Embora essa explicação faça mais sentido para mim, honestamente não tenho 100% de certeza. Espero que alguém com mais conhecimento interno possa comentar.
Não tanto quanto eu posso dizer; novamente, provavelmente por razões de segurança.
Existem muitos cenários em que o evento não pôde ser registrado. Se minha suposição sobre atingir um buffer de memória estiver correta, os eventos com falha serão descartados, pois um desligamento liberará toda a memória do SQL Server. Qualquer coisa que não tenha chegado ao disco será perdida.
O SQL Server enfileirará as gravações dos dados capturados e somente os gravará nos logs quando o tempo especificado tiver passado.
Estou interessado em saber qual é a sua situação. Nós escrevemos um software, LOGbinder SQL, que traduz logs de auditoria SQL e os envia para sistemas de gerenciamento de log/SIEM. Normalmente, recomendamos o uso de um compartilhamento de arquivo em outro servidor onde nosso software é executado para reduzir ao mínimo o impacto no servidor SQL. Seria bom testar o que acontece se esse servidor ficar indisponível por um tempo. Isso se refere ao uso de uma pasta local no servidor SQL. Não recomendamos usar o log de eventos do Windows por motivos de desempenho.
O valor definido para o atraso da fila geralmente é uma compensação entre segurança e desempenho. se ocorrer uma falha no servidor, os resultados que estão no buffer, mas ainda não liberados para o destino, serão perdidos. Se o atraso da fila for definido como zero, as gravações síncronas ocorrerão à medida que os eventos acontecerem. Isso evita a chance de perda de eventos em caso de falha do servidor, mas pode afetar o desempenho do servidor.