Manter e solucionar problemas BizTalk Server bancos de dados

Este artigo fornece informações detalhadas sobre como manter e solucionar problemas BizTalk Server bancos de dados.

Versão original do produto: BizTalk Server bancos de dados
Número de KB original: 952555

Resumo

A integridade dos bancos de dados do Microsoft BizTalk Server é importante para um ambiente de mensagens BizTalk Server bem-sucedido. Este artigo discute coisas importantes a serem consideradas quando você trabalha com bancos de dados BizTalk Server. Essas considerações incluem o seguinte:

  • Você deve desabilitar as auto update statistics opções e auto create statistics SQL Server.
  • Você deve definir a opção max degree of parallelism (MAXDOP) corretamente.
  • Determine quando você pode recompilar índices BizTalk Server.
  • O bloqueio, o bloqueio ou o bloqueio podem ocorrer.
  • Você pode ter problemas com bancos de dados ou tabelas grandes.
  • Trabalhos SQL Server Agent BizTalk.
  • As instâncias de serviço podem ser suspensas.
  • Você pode ter problemas de desempenho SQL Server e BizTalk Server.
  • Você deve seguir as práticas recomendadas no BizTalk Server.

Introdução

Este artigo descreve como manter bancos de dados BizTalk Server e como solucionar problemas BizTalk Server banco de dados.

Você deve desabilitar as opções de estatísticas de criação automática e atualização automática

Você deve manter as auto create statistics opções e auto update statistics desabilitadas no BizTalkMsgBoxDb banco de dados. Para determinar se essas configurações estão desabilitadas, execute os seguintes procedimentos armazenados em SQL Server:

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'

Você deve definir a configuração atual como off. Se essa configuração estiver definida como on, desative-a executando os seguintes procedimentos armazenados no SQL Server:

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'

Você deve definir corretamente a propriedade Grau Máximo de Paralelismo

No computador que está executando SQL Server e hospedando o BizTalkMsgBoxDb banco de dados, defina o grau máximo de paralelismo run_value e config_value propriedades como um valor de 1. Em versões posteriores do SQL, também é possível especificar essa configuração por banco de dados em vez de por instância SQL. Para obter mais informações, consulte Definir MAXDOP. Para determinar a max degree of parallelism configuração, execute o seguinte procedimento armazenado no banco de dados Mestre em SQL Server:

EXEC sp_configure 'show advanced options', 1;
GO
EXEC sp_configure 'max degree of parallelism'

Se as run_value propriedades e config_value não estiverem definidas como um valor de 1, execute o seguinte procedimento armazenado em SQL Server para defini-las como 1:

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

Determinar quando você pode recompilar índices de BizTalk Server

A maioria dos índices BizTalk Server são clusterizados (ID do índice: 1). Você pode usar a DBCC SHOWCONTIG instrução SQL Server para exibir informações de fragmentação para as tabelas de BizTalk Server.

Os índices BizTalk Server são baseados em GUID. Portanto, a fragmentação normalmente ocorre. Se o valor de Densidade de Verificação retornado pela instrução for inferior a 30%, os índices BizTalk Server poderão ser reconstruídos durante o DBCC SHOWCONTIG tempo de inatividade.

Muitas BizTalk Server tabelas contêm colunas que usam DataType definições. A indexação online não pode ser executada nessas colunas. Portanto, você nunca deve recompilar os índices BizTalk Server enquanto BizTalk Server processa dados.

O bloqueio, o bloqueio ou o bloqueio podem ocorrer

Normalmente, bloqueios e blocos ocorrem em um ambiente BizTalk Server. No entanto, esses bloqueios ou blocos não permanecem por um longo tempo. Portanto, o bloqueio e o impasse indicam um problema em potencial.

Você pode ter problemas com bancos de dados ou tabelas grandes

Vimos que, quando o BizTalkMsgBoxDb banco de dados é maior, podem ocorrer problemas de desempenho. O ideal é que o BizTalkMsgBoxDb banco de dados não esteja segurando nenhum dado. O BizTalkMsgBoxDb banco de dados deve ser considerado um buffer até que os dados sejam processados ou movidos para o BizTalkDTADb banco de dados ou BAM.

Um ambiente que usa um SQL Server poderoso no back-end e muitas orquestrações de longa duração podem ter um BizTalkMsgBoxDb banco de dados maior que 5 GB. Um ambiente de alto volume que não usa orquestrações de longa duração deve ter um banco de BizTalkMsgBoxDb dados muito menor que 5 GB.

O BizTalkDTADb banco de dados não tem um tamanho definido. No entanto, se o desempenho diminuir, o banco de dados provavelmente será muito grande. Para alguns clientes, 20 GB podem ser considerados muito grandes, enquanto para outros que com 200 GB podem funcionar bem com um SQL server altamente forte em execução em várias CPUs, muita memória e uma rede e armazenamento rápidos. Quando você tem bancos de dados grandes BizTalk Server, você pode enfrentar os seguintes problemas:

  • O BizTalkMsgBoxDb banco de dados continua a crescer. No entanto, tanto o arquivo de log quanto o tamanho dos dados permanecem grandes.

  • BizTalk Server leva mais tempo do que o normal para processar até mesmo um cenário de fluxo de mensagens simples.

  • As consultas do console de administração do BizTalk ou do HAT (Controle de Atividades e Integridade) levam mais tempo do que o normal e podem demorar um pouco mais.

  • O arquivo de log de banco de dados nunca é truncado.

  • Os trabalhos do BizTalk SQL Server Agent são mais lentos do que o normal.

  • Algumas tabelas são maiores ou têm muitas linhas em comparação com o tamanho usual da tabela.

Os bancos de dados podem se tornar grandes por vários motivos. Esses motivos podem incluir o seguinte:

  • Trabalhos de SQL Server Agent biztalk não estão em execução
  • Grande número de instâncias suspensas
  • Falhas no disco
  • Acompanhamento
  • Limitação
  • Desempenho do SQL Server
  • Latência de rede

Verifique se você sabe o que é esperado em seu ambiente para determinar se um problema de dados está ocorrendo.

Por padrão, o rastreamento está habilitado no host padrão. O BizTalk exige que a opção Permitir Rastreamento de Host seja verificada em um único host. Quando o rastreamento está habilitado, o TDDS (Serviço de Decodificação de Dados de Acompanhamento) move os dados de evento de rastreamento do BizTalkMsgBoxDb banco de dados para o BizTalkDTADb banco de dados. Se o host de rastreamento for interrompido, o TDDS não moverá os dados para o BizTalkDTADb banco de dados e as TrackingData_x_x tabelas no BizTalkMsgBoxDb banco de dados crescerão.

É recomendável que você dedique um host ao rastreamento. Para permitir que o TDDS mantenha novos eventos de rastreamento em cenários de alto volume, crie várias instâncias de um único host de rastreamento. Não deve existir mais de um host de rastreamento.

Pode haver muitas linhas em uma tabela. Não há um número definido de linhas que sejam muitas. Além disso, esse número de linhas varia de acordo com o tipo de dados armazenados na tabela. Por exemplo, uma dta_DebugTrace tabela que tem mais de 1 milhão de linhas provavelmente tem muitas linhas. Uma <HostName>Q_Suspended tabela que tem mais de 200.000 linhas provavelmente tem muitas linhas.

Usar os trabalhos de SQL Server Agent biztalk corretos

Os trabalhos SQL Server Agent BizTalk são importantes para gerenciar os bancos de dados BizTalk Server e para manter o alto desempenho.

O trabalho de backup BizTalk Server SQL Server Agent é o único método com suporte para fazer backup dos bancos de dados BizTalk Server quando SQL Server Agent e as instâncias de host BizTalkServer forem iniciadas. Este trabalho requer que todos os bancos de dados BizTalk Server usem um Modelo de Recuperação Completa. Você deve configurar esse trabalho para um ambiente de BizTalk Server saudável. Os métodos SQL Server poderão ser usados para fazer backup dos bancos de dados BizTalk Server somente se SQL Server Agent for interrompido e se todas as instâncias de host BizTalk Server forem interrompidas.

O MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb trabalho SQL Server Agent é executado infinitamente. Portanto, o SQL Server Agent histórico de trabalho nunca exibe uma conclusão bem-sucedida. Se ocorrer uma falha, o trabalho será reiniciado em um minuto e continuará sendo executado infinitamente. Portanto, você pode ignorar com segurança a falha. Além disso, o histórico de trabalho pode ser limpo. Você só deve se preocupar se o histórico de trabalho relatar que esse trabalho falha constantemente e é reiniciado.

O MessageBox_Message_Cleanup_BizTalkMsgBoxDb trabalho SQL Server Agent é o único trabalho BizTalk Server que não deve ser habilitado porque é iniciado pelo MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb trabalho SQL Server Agent.

O trabalho DTA Purge and Archive SQL Server Agent ajuda a manter o BizTalkDTADb banco de dados purgando e arquivando mensagens rastreadas. Este trabalho lê todas as linhas da tabela e compara o carimbo de hora para determinar se o registro deve ser removido.

Todos os trabalhos SQL Server Agent BizTalk, exceto o MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb trabalho SQL Server Agent devem ser executados com êxito.

Instâncias de serviço podem ser suspensas

As instâncias de serviço podem ser suspensas (resumáveis) ou suspensas (não resumáveis). Essas instâncias de serviço podem ser Mensagens, Orquestração ou Porta.

Essas instâncias de serviço podem fazer com que o BizTalkMsgBoxDb banco de dados cresça desnecessariamente e possa ser encerrado. Você pode usar o Hub de Grupo para consultar, retomar ou encerrar mensagens. Você também pode usar Terminate.vbs script ou a ferramenta BHM (BizTalk Health Monitor) para consultar, limpar e manter bancos de dados BizTalk. Em algumas situações, pode haver mensagens órfãs ou zumbis deixadas no sistema. A ferramenta BHM pode ajudar a corrigir essas situações.

Para obter mais informações sobre o script Terminate.vbs , consulte Removendo instâncias de serviço suspensas.

As instâncias de cache não aparecem na página Hub de Grupo e você não pode suspendê-las ou encerrá-las. Essa restrição é uma causa comum de crescimento da tabela. Para evitar novas mensagens zumbis para as instâncias do serviço de cache no BizTalk Server 2006, instale o hotfix no artigo da Base de Dados de Conhecimento da Microsoft 936536. Esse problema é corrigido em BizTalk Server 2006 R2 e versões posteriores.

Observação

Uma mensagem zumbi é uma mensagem que foi roteada, mas não consumida.

Para obter uma descrição das mensagens zumbis, visite o seguinte site do MSDN: WebLog do Mecanismo Do BizTalk Core

Você pode ter problemas de desempenho SQL Server e BizTalk Server

BizTalk Server faz centenas de transações curtas e rápidas para SQL Server em um minuto. Se o SQL Server não puder sustentar essa atividade, BizTalk Server poderá ter problemas de desempenho. Em Monitor de Desempenho, monitore os contadores Avg. Disk sec/Read, Avg. Disk sec/Transfer e Avg. Disk sec/Write Monitor de Desempenho contadores no objeto de desempenho PhysicalDisk. O valor ideal é menor que 10 ms (milissegundos). Um valor de 20 ms ou maior é considerado baixo desempenho.

Melhores práticas no BizTalk Server

Inicie SQL Server Agent no SQL Server. Quando o SQL Server Agent é interrompido, o BizTalk interno SQL Server Agent trabalhos responsáveis pela manutenção do banco de dados não podem ser executados. Esse comportamento causa o crescimento do banco de dados e esse crescimento pode causar problemas de desempenho.

Coloque os arquivos SQL Server Arquivo de Banco de Dados de Log (LDF) e Arquivo de Banco de Dados Principal (MDF) em unidades separadas. Quando os arquivos LDF e MDF para os BizTalkMsgBoxDb bancos de dados e BizTalkDTADb estão na mesma unidade, a contenção de disco pode ocorrer.

Se você não se beneficiar do acompanhamento do corpo da mensagem, não habilite esse recurso. No entanto, é uma boa ideia habilitar o acompanhamento do corpo da mensagem enquanto você desenvolve e soluciona problemas de uma solução. Se você fizer isso, certifique-se de desabilitar o acompanhamento do corpo da mensagem quando terminar. Quando o rastreamento do corpo da mensagem é habilitado, os bancos de dados BizTalk Server crescem. Se houver uma necessidade de negócios que exija habilitar o acompanhamento do corpo da mensagem, confirme se os TrackedMessages_Copy_BizTalkMsgBoxDb trabalhos de Limpeza e SQL Server Agent Arquivamento do DTA estão sendo executados com êxito.

Normalmente, logs de transações menores causam melhor desempenho. Para manter os logs de transação menores, configure o trabalho backup BizTalk Server SQL Server Agent para ser executado com mais frequência.

O sp_ForceFullBackup procedimento armazenado no BizTalkMgmtDb banco de dados também pode ser usado para ajudar a executar um backup completo ad hoc dos dados e arquivos de log. O procedimento armazenado atualiza a adm_ForceFullBackup tabela com um valor 1. Na próxima vez que o trabalho de backup BizTalk Server for executado, um conjunto de backup de banco de dados completo será criado.

A ferramenta BHM (BizTalk Health Monitor) pode ser usada para avaliar uma implantação de BizTalk Server existente. O BHM executa várias verificações relacionadas ao banco de dados.

Solução de problemas

As melhores etapas de solução de problemas para os bancos de dados BizTalk Server SQL Server dependem do tipo de problema do banco de dados, como bloqueio ou impasse. Para solucionar problemas de um problema de banco de dados BizTalk Server, siga estas etapas.

Etapa 1: habilitar e executar todos os trabalhos de SQL Server Agent biztalk necessários

Todos os trabalhos do BizTalk SQL Server Agent, exceto o MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb trabalho, devem ser habilitados e executados com êxito. Não desabilite nenhum outro trabalho.

Se ocorrer uma falha, use a opção Exibir Histórico em SQL Server para exibir as informações de erro e, em seguida, solucionar a falha de acordo. Lembre-se de que o MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb trabalho SQL Server Agent é executado infinitamente. Portanto, você só deve se preocupar se o histórico de trabalho relatar que o trabalho falha constantemente e é reiniciado.

Etapa 2: usar a ferramenta BizTalk Health Monitor (BHM)/MsgBoxViewer

Colete o relatório do BHM enquanto você reproduz um problema.

A ferramenta BHM é útil para solução de problemas porque fornece um relatório HTML que tem informações detalhadas sobre tamanhos de tabela e a contagem de linhas. O relatório também pode ajudar a determinar se BizTalk Server está limitando. Além disso, a ferramenta fornece uma exibição instantâneo dos bancos de dados BizTalk Server e da configuração BizTalk Server.

Para obter mais informações sobre a limitação no BizTalk Server, consulte Como BizTalk Server implementa a limitação do host.

Quando BizTalk Server estiver em execução mais lenta do que o normal, execute a ferramenta BHM e examine o relatório HTML gerado para quaisquer problemas. A seção Resumo lista avisos em amarelo e possíveis problemas em vermelho.

Além disso, você pode usar a saída da ferramenta BHM para determinar quais tabelas são as maiores e têm mais registros. A tabela a seguir lista as tabelas de BizTalk Server que normalmente crescem as maiores. Você pode usar esses dados para determinar onde um problema em potencial pode existir.

Tabela Descrição
<HostName>Q_Suspended Esta tabela contém uma referência a mensagens na Spool tabela associadas a instâncias suspensas para o host específico. Esta tabela está no banco de BizTalkMsgBoxDb dados.
<HostName>Q Esta tabela contém uma referência às mensagens na Spool tabela que estão associadas ao host específico e não estão suspensas. Esta tabela está no banco de BizTalkMsgBoxDb dados.
Spool

Parts

Fragments
Essas tabelas armazenam dados de mensagens reais no BizTalkMsgBoxDb banco de dados.
Instances Essa tabela armazena todas as instâncias e seus status atuais no BizTalkMsgBoxDb banco de dados.
TrackingData_0_x Essas quatro tabelas armazenam os eventos acompanhados do BAM (Business Activity Monitoring) no BizTalkMsgBoxDb banco de dados do TDDS para mover os eventos para o BAMPrimaryImport banco de dados.
TrackingData_1_x Essas quatro tabelas armazenam os eventos rastreados no BizTalkMsgBoxDb banco de dados do TDDS para mover os eventos para o BizTalkDTADB banco de dados.
Tracking_Fragmentsx
Tracking_Partsx
Tracking_Spoolx
Duas dessas tabelas estão nos BizTalkMsgBoxDb bancos de dados e BizTalkDTADb . Um está online e o outro está offline.

Em BizTalk Server 2004 SP2 e em versões posteriores, o TrackedMessages_Copy_BizTalkMsgBoxDb trabalho SQL Server Agent move os corpos de mensagens rastreados diretamente para essas tabelas no BizTalkDTADb banco de dados.

Em BizTalk Server 2004 Service Pack 1 (SP1) e em versões anteriores de BizTalk Server 2004, o TrackedMessages_Copy_BizTalkMsgBoxDb trabalho SQL Server Agent copia os corpos de mensagens rastreados nessas tabelas no BizTalkMsgBoxDb banco de dados. O TrackingSpool_Cleanup_BizTalkMsgBoxDb trabalho SQL Server Agent limpa as tabelas offline e torna as tabelas online enquanto o trabalho também deixa as tabelas online offline.
dta_ServiceInstances Essa tabela armazena eventos rastreados para instâncias de serviço no BizTalkDTADb banco de dados. Se essa tabela for grande, o BizTalkDTADb banco de dados provavelmente será grande.
dta_DebugTrace Esta tabela armazena os eventos de depurador de orquestração no banco de dados BizTalkDTADb.
dta_MessageInOutEvents Essa tabela armazena mensagens de evento rastreadas no BizTalkDTADb banco de dados. Essas mensagens de evento rastreadas incluem informações de contexto de mensagem.
dta_ServiceInstanceExceptions Esta tabela armazena informações de erro para qualquer instância de serviço suspensa no BizTalkDTADb banco de dados.

Considere os seguintes cenários.

  • <HostName>Q_Suspended Tabelas

    Se as <HostName>Q_Suspended tabelas tiverem muitos registros, as tabelas poderão ser instâncias suspensas válidas que aparecem no Hub de Grupo ou no HAT. Essas instâncias podem ser encerradas. Se essas instâncias não aparecerem no Hub de Grupo ou no HAT, as instâncias provavelmente serão instâncias de cache ou relatórios de falha de roteamento órfãos. Quando as instâncias suspensas são encerradas, os itens nesta tabela e suas linhas associadas nas Spool tabelas e Instances são limpos.

    Nesse cenário, lide com as instâncias suspensas retomando-as ou encerrando-as. A ferramenta BHM também pode ser usada.

  • <HostName>Q Tabelas

    Se as <HostName>Q tabelas tiverem muitos registros, os seguintes tipos de instâncias poderão existir:

    • Instâncias prontas para execução
    • Instâncias ativas
    • Instâncias desidratadas BizTalk Server precisa de tempo para "recuperar o atraso" e processar as instâncias.

    Essa tabela pode crescer quando a taxa de processamento de entrada supera a taxa de processamento de saída. Esse cenário pode ocorrer quando ocorre outro problema, como um banco de dados grande BizTalkDTADb ou SQL Server atrasos em disco.

  • Spool, Partse Fragments tabelas

    Se as Spooltabelas , Partse Fragments tiverem muitos registros, muitas mensagens estarão ativas, desidratadas ou suspensas no momento. Dependendo do tamanho, do número de partes e das configurações de fragmentação nessas tabelas, uma única mensagem pode gerar todas essas tabelas. Cada mensagem tem exatamente uma linha na Spool tabela e pelo menos uma linha na Parts tabela.

  • Instances Tabela

    O Administrador do BizTalk não deve permitir que muitas instâncias suspensas permaneçam na Instances tabela. As instâncias desidratadas só devem permanecer se a lógica de negócios exigir orquestrações de longa duração. Lembre-se de que uma instância de serviço pode ser associada a muitas mensagens na Spool tabela.

  • TrackingData_x_x Tabelas

    Se as TrackingData_x_x tabelas forem grandes, o TDDS (host de rastreamento) não será executado com êxito. Se a instância do host de rastreamento estiver em execução, examine os logs de eventos e a TDDS_FailedTrackingData tabela no BizTalkDTADb banco de dados para obter informações de erro. Se BizTalk estiver limitando com um estado de 6 (banco de dados grande), essas tabelas também poderão ser truncadas usando a ferramenta BizTalk Terminator se os dados não forem necessários.

    Se houver uma grande lacuna entre os números de sequência nas BizTalkMsgBoxDbTrackingData_x_x tabelas e as tabelas ouTDDS_StreamStatusBizTalkDTADb, então, o BAMPrimaryImport TDDS poderá não mover os dados do banco de BizTalkMsgBoxDb dados. Para corrigir isso, use a ferramenta BHM para limpar essas tabelas e redefinir o número da sequência.

  • dta_DebugTrace e dta_MessageInOutEvents tabelas

    A dta_DebugTrace tabela é preenchida quando o shape start and end é habilitado em uma orquestração. Se a dta_DebugTrace tabela tiver muitos registros, esses eventos de depuração de orquestração estão sendo usados ou estão sendo usados. Se a depuração de orquestração não for necessária para operações regulares, desmarque a caixa iniciar e terminar a forma marcar nas propriedades orquestração.

    A dta_MessageInOutEvents tabela é preenchida quando o envio e o recebimento de mensagens são habilitados em orquestrações e/ou pipelines. Se esses eventos de acompanhamento não forem necessários, desmarque a caixa marcar para essa opção nas propriedades de orquestração e/ou pipeline.

    Se esses eventos de rastreamento estiverem desabilitados ou se houver um backlog no banco de dados, essas tabelas poderão continuar a crescer porque o BizTalkMsgBoxDb TDDS continua a mover esses dados para essas tabelas.

    Por padrão, o controle global está habilitado. Se o rastreamento global não for necessário, ele poderá ser desabilitado. Para obter mais informações, consulte Como desativar o rastreamento global.

    Se a dta_DebugTrace tabela e/ou a dta_messageInOutEvents tabela no BizTalkDTADb banco de dados forem muito grandes, você poderá truncar as tabelas manualmente depois de parar o host de rastreamento. A ferramenta BHM também fornece essa funcionalidade.

    Para truncar todas as tabelas de acompanhamento no BizTalkMsgBoxDb banco de dados, use a ferramenta BHM. A ferramenta BHM está disponível externamente no Centro de Download da Microsoft.

    Para obter mais informações sobre como acompanhar as diretrizes de dimensionamento do banco de dados, visite o seguinte site MSDN: Diretrizes de dimensionamento de banco de dados de acompanhamento.

  • dta_ServiceInstanceExceptions Tabela

    Normalmente, a dta_ServiceInstanceExceptions tabela se torna grande em um ambiente que regularmente tem instâncias suspensas.

Etapa 3: investigar cenários de impasse

Em um cenário de impasse, habilite o rastreamento DBCC no SQL Server para que as informações de impasse sejam gravadas no log SQLERROR.

Em SQL Server 2005 e versões posteriores, execute a seguinte instrução:

DBCC TRACEON (1222,-1)

Em SQL Server 2000, execute a seguinte instrução:

DBCC TRACEON (1204)

Além disso, use o utilitário PSSDiag para coletar dados sobre o Lock:Deadlock evento e o Lock:Deadlock evento Chain.

O BizTalkMsgBoxDB banco de dados é um banco de dados OLTP (processamento de transações online) de alto volume e alta transação. Alguns impasses são esperados e esse impasse é tratado internamente pelo mecanismo BizTalk Server. Quando esse comportamento ocorre, nenhum erro é listado nos logs de erro. Quando você investiga um cenário de impasse, o impasse que você está investigando na saída deve ser correlacionado com um erro de impasse nos logs de eventos.

Espera-se que o comando de dequeue e alguns trabalhos de SQL Server Agent fiquem em impasse. Normalmente, esses trabalhos são selecionados como vítimas de impasse. Esses trabalhos aparecerão em um rastreamento de impasse. No entanto, nenhum erro está listado nos logs de eventos. Portanto, esse impasse é esperado e você pode ignorar com segurança o impasse com esses trabalhos.

Se os impasses frequentes aparecerem em um rastreamento de impasse e se um erro de correlação estiver listado nos logs de eventos, você poderá querer o impasse.

Etapa 4: procure processos bloqueados

Use o Monitor de Atividades no SQL Server para obter o SPID (identificador de processo de servidor) de um processo de sistema de bloqueio. Em seguida, execute o SQL Profiler para determinar a instrução SQL que está sendo executada no SPID de bloqueio.

Para solucionar problemas de bloqueio e bloqueio no SQL Server, use o utilitário PSSDiag for SQL para capturar todos os eventos Transact-SQL que têm o script de bloqueio habilitado.

Em SQL Server 2005 e versões posteriores, você pode especificar a configuração de limite de processo bloqueado para determinar quais SPIDs ou SPIDs estão bloqueando mais do que o limite especificado.

Para obter mais informações sobre a configuração de limite de processo bloqueado , consulte o limite de processo bloqueado Opção de Configuração do Servidor.

Observação

Quando você enfrenta um problema de bloqueio ou bloqueio em SQL Server, é recomendável entrar em contato com os Serviços de Suporte ao Cliente da Microsoft. Os Serviços de Suporte ao Cliente da Microsoft podem ajudá-lo a configurar as opções corretas do utilitário PSSDiag.

Etapa 5: instalar o Pacote de Serviço de BizTalk Server mais recente e a atualização cumulativa

BizTalk Server versões posteriores foram movidas para um modelo de CU (Atualização Cumulativa). As atualizações cumulativas conterão as correções mais recentes.

Excluir todos os dados

Se os bancos de dados forem muito grandes ou se o método preferencial for excluir todos os dados, todos os dados poderão ser excluídos.

Cuidado

Não use esse método em nenhum ambiente em que os dados sejam críticos para os negócios ou se os dados forem necessários.

Etapas de limpeza do banco de dados BizTalkMsgBoxDb

Para excluir todos os dados no BizTalkMsgBoxDb banco de dados, use a ferramenta BHM (BizTalk Health Monitor).

Opções de purgação de banco de dados BizTalkDTADb

Para excluir todos os dados do BizTalkDTADb banco de dados, use a ferramenta BHM (BizTalk Health Monitor). Caso contrário, use um dos métodos a seguir.

Observação

Embora ambos os métodos excluam todas as mensagens, o método 2 é mais rápido.

  • Método 1:

    1. Faça backup de todos os bancos de dados BizTalk Server.

    2. Execute o dtasp_PurgeAllCompletedTrackingData procedimento armazenado. Para obter mais informações sobre o dtasp_PurgeAllCompletedTrackingData procedimento armazenado, consulte Como limpar manualmente dados do Banco de Dados de Rastreamento BizTalk.

      Observação

      Essa ação exclui todas as mensagens concluídas.

  • Método 2:

    1. Faça backup de todos os bancos de dados BizTalk.

    2. Execute o dtasp_CleanHMData procedimento armazenado. Use essa opção somente se o BizTalkDTADb banco de dados contiver muitas instâncias incompletas que devem ser removidas.

      Para fazer isso, siga estas etapas:

      1. Pare todos os hosts, serviços e adaptadores isolados personalizados do BizTalk. Se você usar HTTP ou o adaptador SOAP, reinicie os serviços do IIS.
      2. Execute o dtasp_CleanHMData procedimento armazenado no BizTalkDTADb banco de dados.
      3. Reinicie todos os hosts e BizTalk Server serviços.

BizTalk Server etapas somente 2004

Observação

Se você precisar ter os dados de rastreamento, faça backup do BizTalkDTADb banco de dados, restaure o banco de dados para outro SQL Server e limpe o banco de dados originalBizTalkDTADb.

Se você precisar de ajuda para analisar os dados do BHM ou a saída do PSSDiag, entre em contato com os Serviços de Suporte ao Cliente da Microsoft. Para obter uma lista completa de números de telefone dos Serviços de Suporte ao Cliente e informações sobre os custos de suporte, consulte Contato Suporte da Microsoft.

Observação

Antes de entrar em contato com os Serviços de Suporte ao Cliente, compacte os dados do relatório do BHM, a saída PSSDiag e os logs de eventos atualizados (arquivos.evt). Talvez você precise enviar esses arquivos para um engenheiro de suporte BizTalk Server.

Aplicável a

  • BizTalk Server 2009
  • BizTalk Server 2010
  • BizTalk Server 2013
  • BizTalk Server 2013 R2
  • BizTalk Server 2016
  • BizTalk Server 2020