ID do artigo: 953199 - Última revisão: quinta-feira, 14 de agosto de 2008 - Revisão: 1.0

Como configurar e solucionar problemas de parâmetro SubscriptionStreams do Distribution Agent no SQL Server 2005

Dica do SistemaEste artigo aplica-se a um sistema operativo diferente do que está a utilizar. Foi desactivado o conteúdo do artigo, que pode não ser relevante para si.

Nesta página

Expandir tudo | Recolher tudo

INTRODUÇÃO

Em uma replicação transacional no Microsoft SQL Server 2005, você pode usar o parâmetro SubscriptionStreams para habilitar conexões múltiplas que o Distribution Agent usa para aplicar os lotes de alterações em paralelo para o assinante. Ao mesmo tempo, o agente de distribuição pode ainda manter muitas das mesmas características transacionais como quando o Distribution Agent usa uma única conexão para aplicar as alterações.

Observação Em seções a seguir, uma sessão se refere a uma conexão que é aberto o Distribution Agent para a instância do SQL Server no assinante.

Sumário

Este artigo descreve os tópicos a seguir:
  • Como solucionar o problema quando a distribuição agente alterna para usar somente uma sessão.
  • Como determinar um valor eficiente para SubscriptionStreams parâmetro.

Mais Informações

O comportamento do Distribution Agent depois que você especificar o parâmetro SubscriptionStreams

O Distribution Agent mantém o número de sessões que você especifica no parâmetro SubscriptionStreams . O Distribution Agent usa essas sessões para aplicar as alterações no assinante.

No entanto, depois de você especificar o parâmetro SubscriptionStreams e o Distribution Agent é executado por algum tempo, o Distribution Agent pode mudar para usar somente uma sessão para aplicar as alterações para o assinante.

Motivos para o Distribution Agent alternar para usar somente uma sessão

O Distribution Agent poderá alternar para usar somente uma sessão por vários motivos. A seguir estão as razões mais comuns:
  • Quando o Distribution Agent está aplicando as alterações, uma das sessões gerará um erro.

    Por exemplo, o Distribution Agent insere uma linha em uma tabela filho usando uma sessão. Se isso ocorrer antes do Distribution Agent insere a linha correspondente na tabela pai usando outra sessão, uma violação de restrição chave estrangeira gera uma mensagem de erro.
  • O bloqueio thread do monitor detecta bloqueio. O bloqueio pode ocorrer por uma das seguintes razões:
    • O Distribution Agent executa uma operação INSERT e uma operação UPDATE em uma tabela no assinante, usando diferentes sessões. Se a tabela contém um índice que não estão em cluster exclusivo, bloqueio entre duas sessões pode ocorrer quando o Distribution Agent atualiza as chaves de índice da tabela.
    • No assinante, o Distribution Agent executa instruções DML em várias tabelas. Se um modo de exibição indexado é definido nessas tabelas, bloqueio entre duas sessões pode ocorrer quando o modo de exibição indexado atualiza as chaves de índice compartilhada.
    • O Distribution Agent executa uma instrução DML uma tabela no assinante usando uma sessão. Disparadores DML são definidos nesta tabela. Os disparadores DML executar declarações DML em outra tabela que está sendo atualizada usando outra sessão. Nessa situação, o bloqueio entre duas sessões pode ocorrer.
É altamente recomendável não usar os seguintes objetos de banco de dados no banco de dados do assinante:
  • Restrições de chave externa
  • Índices exclusivos que não estão em cluster
  • Modos de exibição indexados
  • Disparadores DML que podem causar bloqueio entre sessões

Como determinar se o Distribution Agent alternou para usar somente uma sessão

Para fazer isso, use um dos seguintes métodos.

Observação Embora você pode confirmar que o agente de distribuição não alternou para usar uma sessão usando o método 1, você deve usar o método 2 ou o método 3 para confirmar que o Distribution Agent alternou para usar uma sessão.

Método 1

Consulte as sessões de conexão ao banco de dados inscrição sys.dm_exec_sessions DMV (exibição de gerenciamento dinâmico). Se você vir apenas uma conexão sessão, o Distribution Agent talvez tenha alternado para usar uma sessão. Se você vir mais de uma sessão de conexão, o agente de distribuição ainda está usando o número especificado de sessões.

Para confirmar que o Distribution Agent alternou para usar uma sessão, use o método 2 ou o método 3.

Método 2

Consulte a coluna de comentários da tabela msdistribution_history no banco de dados de distribuição. Se o resultado da consulta contiver a entrada a seguir, o Distribution Agent alternou para usar uma sessão:
O processo falhou concluir o último lote no modo de fluxo contínuo multi, ele foi redefinido para modo de conexão única e está tentando executar a operação novamente.

Método 3

Examine o arquivo de saída do agente de distribuição. O Distribution Agent alternou para usar somente uma sessão se o arquivo de saída contém a mesma mensagem de erro como método 2.

O seguinte arquivo de saída é um exemplo:
<Date><Time>transação (ões 100) com 1181 comandos foram entregues.
<Date><Time>transação (ões 100) com 2672 comandos foram entregues.
<Date><Time>Compartimento de memória 6 anulada aguardar o evento pronto para confirmar, deadlock encontrado entre spid 117 e 114
<Date><Time>Compartimento de memória 1 anulado aguardar o evento pronto para confirmar, deadlock encontrado entre spid 117 e 114
<Date><Time>Compartimento de memória 3 anulada aguardar o evento pronto para confirmar, deadlock encontrado entre spid 117 e 114
<Date><Time>Compartimento de memória 0 anulada aguardar o evento pronto para confirmar, deadlock encontrado entre spid 117 e 114
<Date><Time>Compartimento de memória 5 anulada aguardar o evento pronto para confirmar, deadlock encontrado entre spid 117 e 114
<Date><Time>Compartimento de memória 2 anulada aguardar o evento pronto para confirmar, deadlock encontrado entre spid 117 e 114
<Date><Time>Compartimento de memória 7 anulada aguardar o evento pronto para confirmar, deadlock encontrado entre spid 117 e 114
<Date><Time>Compartimento de memória 4 anulada aguardar o evento pronto para confirmar, devido ao evento de desligamento de thread
...
<Date><Time>Número de fluxos de inscrição foi redefinido de 8 para 1, 4 de estado.
<Date><Time>Desconectando-se de assinante <SQLinstance>
<Date><Time>Desconectando-se de assinante <SQLinstance>
<Date><Time>Desconectando-se de assinante <SQLinstance>
<Date><Time>Desconectando-se de assinante <SQLinstance>
<Date><Time>Desconectando-se de assinante <SQLinstance>
<Date><Time>Desconectando-se de assinante <SQLinstance>
<Date><Time>Desconectando-se de assinante <SQLinstance>
<Date><Time>Desconectando-se de assinante <SQLinstance>

<Date><Time>Conectando-se ao assinante <SQLinstance>
<Date><Time>O processo falhou concluir o último lote no modo de fluxo contínuo multi, ele foi redefinido para modo de conexão única e está tentando executar a operação novamente.
<Date><Time>transação (ões 21) com 390 comandos foram entregues.

Como solucionar problemas de um agente de distribuição que alterna para usar somente uma sessão

  1. Execute o SQL Server Profiler no assinante para capturar o evento de relatório de processo bloqueado e o evento de exceção . Esses eventos registram erros que ocorrem quando o Distribution Agent aplica as alterações e bloqueio.

    Observação O evento de exceção pode ser causado por qualquer tipo de erro que pode ser associado com o problema. Por exemplo, o erro pode ser causado por uma violação de restrição de chave externa.
  2. Use um dos métodos na seção "Como determinar se o Distribution Agent alternou para usar somente uma sessão" para monitorar o Distribution Agent.
  3. Se o Distribution Agent alternou para usar uma sessão, pare o rastreamento.
  4. No arquivo de saída do Distribution Agent ou da coluna da tabela msdistribution_history hora_de_início , obter a hora da seguinte entrada:
    O processo falhou concluir o último lote no modo de fluxo contínuo multi, ele foi redefinido para modo de conexão única e está tentando executar a operação novamente.
  5. Abra o arquivo rastreamento (.trc) do assinante. Localize um script de bloqueio ou um evento de exceção cujo carimbo de hora é o mesmo como ou muito perto para o carimbo de hora que você obteve na etapa 4.
  6. Se você notar uma exceção, examine os detalhes da exceção para determinar a causa. Por exemplo, a exceção pode ser causada por uma violação de restrição de chave externa. Se for esse o caso, recomendamos que você remover a restrição de chave externa no banco de dados do assinante.

    Se você notar um bloqueio de script, o problema é causado por bloqueio. The following is a sample blocking script:
    <blocked-process-report monitorLoop="41589">
     <blocked-process>
      <process id="process3a6d438" taskpriority="0" logused="24592" waitresource="KEY: 6:72057594375700480 (0100e420fa5a)" waittime="9937" ownerId="568644832" transactionname="user_transaction" lasttranstarted="2008-05-05T04:55:04.430" XDES="0xa5619e370" lockMode="X" schedulerid="11" kpid="6104" status="suspended" spid="58" sbid="0" ecid="0" priority="0" transcount="2" lastbatchstarted="2008-05-05T04:55:04.553" lastbatchcompleted="2008-05-05T04:55:04.430" clientapp=<DistributionAgentProgram> hostname=<servername> hostpid="3980" loginname=<SQLAgentAcct>  isolationlevel="read committed (2)" xactid="568644832" currentdb="6" lockTimeout="4294967295" clientoption1="671090784" clientoption2="128056">
       <executionStack>
        <frame line="5" stmtstart="642" stmtend="1600" sqlhandle="0x0300060057a14477a8c6dd00609a00000100000000000000"/>
       </executionStack>
       <inputbuf>
    Proc [Database Id = 6 Object Id = 2000986455]   </inputbuf>
      </process>
     </blocked-process>
     <blocking-process>
      <process status="sleeping" spid="68" sbid="0" ecid="0" priority="0" transcount="1" lastbatchstarted="2008-05-05T04:55:04.570" lastbatchcompleted="2008-05-05T04:55:05.103" clientapp=<DistributionAgentProgram> hostname=<servername> hostpid="3980" loginname=<SQLAgentAcct> isolationlevel="read committed (2)" xactid="568644998" currentdb="6" lockTimeout="4294967295" clientoption1="671090784" clientoption2="128056">
       <executionStack/>
       <inputbuf>
    Proc [Database Id = 6 Object Id = 1172459501]   </inputbuf>
      </process>
     </blocking-process>
    </blocked-process-report>
    
    script bloqueio registra uma sessão bloqueada e uma sessão de bloqueio. A sessão bloqueada inicia a partir da marca <blocked-process>. A sessão de bloqueio inicia a partir da marca <blocking-process>.
  7. Localize a identificação de objeto do objeto PROC. na sessão bloqueada e na sessão bloqueio.

    No exemplo de bloqueio de script, a identificação de objeto do objeto PROC. na sessão bloqueado é 2000986455. A identificação de objeto do objeto PROC. na sessão bloqueio é 1172459501.
  8. No banco de dados de inscrição, consulte o modo de exibição sys.objects especificando a coluna object_id para ser igual ao objeto IDs que você obteve na etapa 7. Quando você fizer isso, você pode determinar os nomes de objeto.

    Por exemplo, executar a consulta seguinte no contexto de banco de dados de inscrição:
    USE <SubDBName>
    GO
    SELECT name FROM sys.objects
    WHERE object_id = 1172459501 OR object_id = 2000986455
    
    anotações
    • O <SubDBName> espaço reservado representa o nome do banco de dados inscrição.
    • Geralmente, esses objetos são procedimentos armazenados que são usados na replicação.
  9. Determine o índice ou o modo de exibição indexado que faz com que o bloqueio. Para fazer isso, execute as seguintes etapas:
    1. No script de bloqueio, localize o valor da propriedade waitresource .

      No exemplo de bloqueio de script, o valor da propriedade waitresource é 72057594375700480.
    2. O modo sys.partitions para obter a identificação do objeto e a identificação de índice, especificando a coluna PARTITION_ID para ser igual ao valor da propriedade waitresource que você obteve na etapa 9a da consulta.

      Por exemplo, execute a seguinte consulta:
      SELECT object_id, index_id FROM SYS.PARTITIONS WHERE PARTITION_ID=72057594375700480
    3. No banco de dados de inscrição, consulte o modo de exibição sys.indexes para determinar o índice usando a identificação do objeto e a identificação de índice que você obteve na etapa 9b.

      Por exemplo, executar a consulta a seguir: nome
      USE <SubDBName>
      GO
      SELECT name, type_desc, is_unique FROM sys.indexes
      WHERE object_id = <objID> and index_id = <idxID>
      
      Observação O <objID> espaço reservado representa a identificação do objeto que você obteve na etapa 9b. O <idxID> espaço reservado representa a identificação de índice que você obteve na etapa 9b.
  10. Se o bloqueio é causado por um modo de exibição indexado, recomendamos que você soltar o modo de exibição indexado. Se o bloqueio é causado por um índice exclusivo que não estão em cluster, recomendamos que você pode descartar o índice e, em seguida, recriar um índice não exclusivo.

Descrição do bloqueio thread do monitor

O Distribution Agent mantém um bloqueio thread do monitor que detecta o bloqueio entre as sessões. Se o bloqueio thread do monitor detecta bloqueio entre as sessões, o Distribution Agent alternará para usar uma sessão para reaplicar o lote atual de comandos que o Distribution Agent não pôde aplicar anteriormente.

Para obter mais informações sobre o bloqueio thread do monitor, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
956601  (http://support.microsoft.com/kb/956601/ ) Descrição do thread monitor bloqueio no SQL Server 2005

Como o Distribution Agent reinicia várias sessões

Antes do Distribution Agent pode continuar a várias sessões, o Distribution Agent deve executar o procedimento sp_MSget_repl_commands armazenados para repetir a consulta o banco de dados distribuição para os comandos que não foram aplicadas no assinante. Em seguida, o Distribution Agent deve aplicar esses comandos no assinante antes do agente de distribuição pode ser reiniciada várias sessões. Em um ambiente de replicação latentes, o agente de distribuição não pode continuar várias sessões porque o Distribution Agent deve se aplicar muitos comandos no assinante antes do agente de distribuição pode ser reiniciada várias sessões.

Para controlar todo o processo, examine o arquivo de saída do Distribution Agent.

Referências

Para obter mais informações sobre como usar o parâmetro SubscriptionStreams para melhorar a taxa de transferência do subsistema de disco, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
956600  (http://support.microsoft.com/kb/956600/ ) Como usar o parâmetro SubscriptionStreams para testar a transferência de subsistema de disco aprimorados no SQL Server 2005

A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
Palavras-chave: 
kbmt kbsql2005repl kbexpertiseadvanced kbhowto kbinfo KB953199 KbMtpt
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 953199  (http://support.microsoft.com/kb/953199/en-us/ )