Planejando notificações
Para usar notificações de consulta de forma eficaz, considere se seu aplicativo pode se beneficiar das notificações de consulta, se as consultas usadas pelo seu aplicativo oferecem suporte a notificações, além da estratégia a ser usada pelo aplicativo para inscrever e receber notificações.
As notificações de consulta oferecem um modo prático de reduzir viagens de ida e volta ao banco de dados se os dados da consulta forem alterados relativamente com pouca frequência; se o aplicativo não exigir uma atualização instantânea das alterações de dados e se a consulta atender os requisitos e as restrições descritas em Criando uma consulta para notificação. Muitos aplicativos baseados na Web atendem esses critérios, e esses aplicativos podem tirar proveito das notificações de consulta.
Nem todo cenário se beneficia das notificações de consulta. As notificações de consulta são úteis nas situações em que um aplicativo lê dados do banco de dados com frequência, mas em que as atualizações de dados são relativamente pouco frequentes. Por exemplo, um aplicativo de catálogo online é exibido com mais frequência do que as atualizações do catálogo. Para um carrinho de compras online, porém, o conteúdo de um particular pode ser atualizado com bastante frequência, de modo que as notificações de consulta são menos vantajosas.
As notificações de consulta são mais eficazes quando um aplicativo emite consultas que compartilham uma estrutura comum e só variam nos valores dos parâmetros. Por exemplo:
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
Nesse caso, as assinaturas de notificação de consulta de ambas as notificações compartilham do mesmo modelo interno, requerendo menos sobrecarga no SQL Server que duas notificações com estruturas de consulta diferentes. Observe-se, no entanto, que os parâmetros das consultas são preservados. Embora as consultas compartilhem um modelo, adicionar um item com uma ListPrice de 350 origina uma notificação na segunda consulta, mas não na primeira.
Quando as notificações de consulta estiverem ativas em uma tabela, as atualizações da tabela serão mais dispendiosas. O Mecanismo de Banco de Dados executa trabalho extra para verificar as assinaturas e, se necessário, gerar notificações. Reutilizar modelos internos ajuda a minimizar a sobrecarga por assinatura. Por isso, você só deve usar notificações de consulta em aplicativos que enviem consultas de estruturas semelhantes. Um aplicativo que envia consultas com estruturas diferentes não deve usar notificações de consulta.
Por exemplo, um aplicativo que mostra itens de catálogo em determinada faixa de preços envia consultas com a mesma estrutura. Nesse caso, o Mecanismo de Banco de Dados pode utilizar novamente o modelo interno de cada consulta, e as notificações de consulta podem melhorar o desempenho. No entanto, um aplicativo que propicia relatórios ad hoc envia consultas com estrutura variável. Nesse caso, o aplicativo não deve usar notificações de consulta.
O Mecanismo de Banco de Dados mantém um modelo interno, contanto que seja usado por pelo menos uma assinatura registrada. O Mecanismo de Banco de Dados limita o número de modelos internos diferentes em uma tabela específica. Quando esse limite é atingido, o Mecanismo de Banco de Dados não registra assinaturas que possam causar a criação de um novo modelo. O Mecanismo de Banco de Dados gera imediatamente uma mensagem de assinatura indicando que a assinatura não pôde ser registrada.
Planejando uma estratégia de notificações de consulta eficiente
As notificações de consulta costumam funcionar muito bem quando o número total de notificações é pequeno a moderado, e o aplicativo não exige um tempo de resposta de notificação instantâneo quando os dados são alterados. O cenário típico de invalidação de cache na camada Web se ajusta a este modelo e tende a ser um aplicativo ideal para usar notificações de consulta. As notificações de consulta talvez não sejam a melhor opção para aplicativos quando elas precisam ser recebidas com um tempo de resposta em subsegundos, quando a infraestrutura de rede não é rápida nem confiável, ou quando há um grande volume de notificações.
Ao usar notificações de consulta, teste e ajuste seu aplicativo à escala e no ambiente onde ele operará quando for implantado. Considere o cenário de uso mundial real com a carga esperada mais pesada e prepare-se para eventuais estouros em função da alta atividade.
Se você estiver usando notificações de consulta em uma situação em que precisa de notificações de consulta confiáveis em subsegundos, as mesmas técnicas que se aplicam à criação de qualquer aplicativo OLTP de alto desempenho se aplicarão a seu aplicativo de notificações de consulta.
Verifique se seu aplicativo está mantendo bloqueios por mais de uma fração de segundo. Por exemplo, não execute transações com várias instruções de um cliente em uma rede com desempenho não confiável.
Identifique e elimine pontos de acesso em suas tabelas de dados de usuário.
As tabelas internas de notificações de consulta costumam ser verificadas em sequência em cada atualização de uma tabela de usuário relacionada na qual você tenha definido notificações de consulta. Se o bloqueio em nível de tabela na tabela interna de notificações de consulta correr o risco de se tornar um afunilamento, considere particionar a tabela de usuário com a notificação de consulta em várias tabelas separadas a fim de reduzir o número de possíveis notificações a serem avaliadas para cada alteração de dados.
Se o tempo de vida de suas solicitações de notificação for curto, procure usar um tempo limite com o Construtor SqlDependency que seja significativamente menor que o padrão de 5 dias (por exemplo, um minuto). Isso pode reduzir muito o número de linhas em tabelas de notificações de consulta internas. Consequentemente, isso também pode reduzir o tempo necessário para processar essas tabelas e reduzir sua contenção de bloqueio.
Alternativas para notificações de consulta
Se você precisar de tempo de resposta rápido e altamente previsível para notificações sobre alterações de dados em um ambiente com alto índice de atualização de dados e muitas solicitações de notificação pendentes, procure soluções alternativas, como as apresentadas a seguir.
Crie um gatilho AFTER UPDATE na tabela que está sendo monitorada, cuja ação usa o SQL Server Service Broker para enviar uma mensagem à entidade que precisa da notificação. (Isso pode ser feito de vários modos; por exemplo, adicionando uma coluna à tabela de interesse com uma indicação da entidade que deve ser notificada sobre as alterações ou unindo a tabela primária à segunda tabela que contém informações sobre a entidade que requer a notificação.)
Use uma solução personalizada da camada de aplicativo que não se baseie em notificações de consulta. Por exemplo, configure uma notificação para que ocorra totalmente de um aplicativo middleware que mantém os dados monitorados em uma coleção de objetos de memória principal. Seu aplicativo pode gerar uma notificação quando um objeto é modificado de forma que atenda aos critérios de uma notificação.
Use o cache do Windows Server App Fabric, que oferece suporte a um mecanismo de alteração de notificações, com base em um cache de objeto de memória e em funções de retorno de chamada registradas com os objetos.