Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
SQL ServerAzure SQL Managed Instance
Este artigo descreve opções para ativação do Service Broker.
O Service Broker oferece suporte a mensagens assíncronas e enfileiradas. Como as conversas podem durar dias, meses ou anos, muitos aplicativos usam a ativação para escalar dinamicamente. Esta seção descreve algumas estratégias comuns para iniciar um aplicativo que usa o Service Broker.
Estratégias de startup
As estratégias para iniciar um pedido dividem-se em quatro grandes categorias:
Ativação interna
Ativação baseada em eventos
Tarefa agendada
Tarefa de inicialização
Cada estratégia de ativação tem vantagens diferentes. Um aplicativo pode combinar essas estratégias. Por exemplo, um aplicativo pode usar a ativação interna com um pequeno número de leitores de fila na maioria das vezes, mas em determinados momentos do dia, ele pode iniciar mais leitores de fila.
Ativação interna
Com a ativação interna do Service Broker, um monitor de fila do Service Broker ativa diretamente um procedimento armazenado quando necessário. Esta é, muitas vezes, a abordagem mais simples. Usando a ativação direta de um procedimento armazenado, você não precisa escrever código adicional no aplicativo para gerenciar a ativação. No entanto, a ativação interna requer que o aplicativo seja escrito como um procedimento armazenado do SQL Server. Ao usar a ativação interna, você escreve o aplicativo para sair quando não houver mais mensagens para processar.
Ativação baseada em eventos
Alguns aplicativos são executados em resposta a um evento específico. Por exemplo, você pode executar um aplicativo quando o uso da CPU no computador cai abaixo de um determinado nível, ou você pode executar um aplicativo de log quando uma nova tabela é criada.
A ativação externa do Service Broker é um caso especial de ativação baseada em eventos. Para ativação externa, o aplicativo é iniciado em resposta ao evento QUEUE_ACTIVATION.
Para eventos que podem ser acionados por notificações de eventos, você pode combinar a ativação baseada em eventos com a ativação interna do Service Broker. Nesse caso, você usa a ativação interna na fila que recebe a notificação de evento. O procedimento armazenado de ativação recebe a mensagem de notificação e inicia o aplicativo.
Para outros eventos, você pode usar o SQL Server Agent para iniciar trabalhos no mesmo computador em que o SQL Server é executado. Você pode escrever um aplicativo que monitora eventos WMI (Instrumentação de Gerenciamento do Windows) a partir de um computador remoto. O aplicativo pode iniciar uma tarefa quando ocorre um evento WMI no computador que executa o SQL Server.
Ao usar a ativação baseada em eventos, um aplicativo normalmente é encerrado quando não há mais mensagens para processar.
Tarefa agendada
Com uma tarefa agendada, um aplicativo é ativado em um cronograma definido. Esta estratégia é conveniente para aplicações de processamento em lote. Um aplicativo que é executado como uma tarefa agendada pode sair quando não há mais mensagens para processar, ou o programa pode sair em um determinado momento.
Por exemplo, um aplicativo que processa pedidos para um fornecedor pode armazenar mensagens durante o dia e, em seguida, processar as mensagens durante a noite para produzir um único pedido para o fornecedor. Nesse caso, o aplicativo pode usar um trabalho do SQL Server Agent para iniciar o aplicativo em um horário específico todas as noites.
Tarefa de inicialização
Alguns aplicativos são iniciados uma vez, normalmente quando o computador é iniciado ou quando o SQL Server é iniciado. Exemplos dessas tarefas são um procedimento armazenado de inicialização no SQL Server, um aplicativo no grupo de inicialização do Windows ou um serviço do Windows. Nesse caso, o aplicativo permanece em execução e processa as mensagens à medida que elas chegam. Um aplicativo que é executado continuamente não requer tempo de inicialização quando uma mensagem chega na fila. No entanto, como o aplicativo não sai quando não há mensagens, o programa consome recursos mesmo quando não há trabalho para o programa fazer.
Essa estratégia pode ser útil para um aplicativo que processa um fluxo constante de mensagens e que consome relativamente recursos durante a inicialização.