Gestão e limpeza das tabelas de MarkLog existentes nas base de dados de BizTalk Server

Todas as base de dados de BizTalk Server para as quais o “Backup BizTalk Server” job faz o backup, ou seja todas à excepção do BAM Star Schema (BAMStarSchema), tem uma tabela chamada "MarkLog".

Estas tabelas contêm registos de todas as transacções de backups de logs efectuados (que na realidade são timestamps em formato de string) criados pelo 3º passo presente no job “Backup BizTalk Server” (MarkAndBackUpLog), para uma determinada base de dados de BizTalk. Este passo, MarkAndBackupLog, é responsável pela registo que um determinado backup do ficheiro de log será efectuado nestas tabelas e depois efectuar o respectivo backup. Isto significa que cada vez que este passo é executado, por defeito de 15 em 15 minutos, uma string é armazenada nessa tabela com a seguinte convenção de nomenclatura:

• Log_<yyyy>_<MM>_<dd>_<HH>_<mm>_<ss>_<fff>

Onde:

• “Log”: é uma string constante
• yyyy: A representação dos 4 dígitos do ano.
• MM: A representação do mês de 01 a 12
• dd: O respectivo dia do mês, de 01 a 31.
• HH: A representação da hora usando a nomenclatura de um relógio de 24 horas, ou seja os valores vão de 00 a 23
• mm: A representação dos minutos de 00 a 59.
• ss: A representação dos segundos de 00 a 59.
• fff: A representação dos milisegundos de uma determinada data.

Exemplo: BTS_2014_05_06_14_15_01_327

Mas infelizmente o BizTalk Server não providencia nenhuma funcionalidade out-of-the-box para limpar estas tabelas. E o procedimento normal é executar a ferramenta BizTalk Terminator para limpar essas tabelas. Podemos ver mais informações sobre esta tarefa aqui: Clean up the MarkLog table with Terminator

BizTalk Terminator é uma excelente ferramenta que permite endereçar e resolver os problemas mais comuns atravês de scripts disponibilizados pela equipa de produto e que deve ser usado com cuidado e por utilizadores que compreendam o que realmente estão a fazer.

No entanto têm uma limitação duas limitações bastante grave:

• Para executar em segurança esta ferramenta o ambiente terá de ser parado, o que significa downtime da nossa plataforma de integração.
• E se validar-mos a descrição dessa tarefa “PURGE Marklog table“ efectuada pelo BizTalk verificamos que a operação chama um script SQL que limpa completamente todos os registos destas tabelas - e que talvez não seja uma boa prática pois perdemos algumas informações que nos poderão ser interessantes!

A informação (timestamps) presente na tabela de MarkLog são úteis para administradores BizTalk? Devo limpar todos os dados deste tabelas ou devo manter um histórico?

Pela mesmas razões que nós mantemos um histórico de backup na tabela Adm_BackupHistory controlada pelo passo "Clear History Backup" do job 'Backup BizTalk Server'. Esta informação é importante, por exemplo, para manter um histórico sobre os backups de logs efectuados, por forma a validar se as tarefas de limpeza e manutenção estão a funcionar correctamente e por forma a garantir quais os backups que necessitam de ser restaurados em caso de falhas.

Segundo as boas práticas, nós deveremos manter ou garantir que estas tabelas contêm os registos referentes ao período que se encontra definido no ultimo passo do “Backup BizTalk Server” job. Ou seja se definirmos que queremos manter um registo do histórico de backup na tabela Adm_BackupHistory de 15 dias, isso significa que deveremos também manter todos os registos referentes a esses 15 dias nas tabelas de MarkLog. O resto dos registos podemos excluir com segurança.

E é por isso que, na minha opinião, você não deve usar o BizTalk Terminator para realizar esta operação!

É seguro limpar estas informações em runtime, ou seja sem necessidade de parar a minha plataforma?

Sim, as linhas na tabela Marklog não são "necessárias" e podem ser limpas sempre que você quiser, desde que “Backup BizTalk Server” job não esteja a ser executado.

Tarefa para limpar as tabelas de MarkLog segundo as boas práticas

Por forma a resolver este simples problema decidi recriar o stored procedure “sp_DeleteBackupHistory” (que se encontra configurado no ultimo passo do “Backup BizTalk Server (BizTalkMgmtDb)” job), com um nome diferente “sp_DeleteBackupHistoryAndMarkLogsHistory” e configurar este procedimento para executar também a tarefa de limpeza das tabelas de MarkLog:

DECLARE @BackupServer sysname, @BackupDB sysname, @RealServerName sysname
DECLARE @tsql nvarchar(1024)
DECLARE @ret int
/* Create a cursor */
DECLARE BackupDB_Cursor insensitive cursor for
   SELECT ServerName, DatabaseName
   FROM admv_BackupDatabases
   ORDER BY ServerName
 
open BackupDB_Cursor
fetch next from BackupDB_Cursor into @BackupServer, @BackupDB
WHILE (@@FETCH_STATUS = 0)
   BEGIN
      -- Get the proper server name
      EXEC @ret = sp_GetRemoteServerName @ServerName = @BackupServer, @DatabaseName = @BackupDB, @RemoteServerName = @RealServerName OUTPUT
 
      /* Create the delete statement */
      select @tsql =
      'DELETE FROM [' + @RealServerName + '].[' + @BackupDB + '].[dbo].[MarkLog]
      WHERE DATEDIFF(day, REPLACE(SUBSTRING([MarkName],5,10),''_'',''''), GETDATE()) > ' + cast(@DaysToKeep as nvarchar(5) )
                            
      /* Execute the delete statement */
      exec (@tsql)
      /* Get the next DB. */
      fetch next from BackupDB_Cursor into @BackupServer, @BackupDB
   END
close BackupDB_Cursor
deallocate BackupDB_Cursor

Passos necessários para instalar e configurar esta tarefa

• Criar o stored procedure “sp_DeleteBackupHistoryAndMarkLogsHistory” disponível para download aqui: BizTalk Server: Cleaning MarkLog Tables According to Some of the Best Practices
• ·Alterar a configuração do 4 º passo do trabalho do “Backup BizTalk Server (BizTalkMgmtDb)” job por forma a que este passe a invocar este novo procedimento

Nota: não elimine o “sp_DeleteBackupHistory”

Um obrigado especial ao Tord Glad Nordahl e ao Pedro Sousa que me ajudaram a elaborar este SQL Script.

Download: BizTalk Server: Cleaning MarkLog Tables According to Some of the Best Practices |Microsoft TechNet Gallery