Como posso garantir que as inserções no SQL Server 2008 R2 sejam armazenadas em cache na RAM primeiro?

Imagine um fluxo de dados que seja "estourado", ou seja, pode ter 10.000 eventos chegando muito rapidamente, seguidos por nada por um minuto.

Seu conselho de especialistas: como posso escrever o código de inserção de C # para o SQL Server, de modo que haja uma garantia de que o SQL armazena tudo em cache imediatamente em sua própria RAM, sem bloquear meu aplicativo por mais do que o necessário para alimentar dados na referida RAM? Para conseguir isso, você conhece algum padrão de configuração do próprio servidor SQL ou padrões para configurar as tabelas SQL individuais nas quais estou escrevendo?

Obviamente, eu poderia fazer minha própria versão, que envolve a construção de minha própria fila na RAM - mas não quero reinventar o Paleolítico Stone Axe, por assim dizer.

Você já tentou escrever e ver o que acontece? Você tem um gargalo conhecido?

Se você precisar impedir que seu aplicativo seja bloqueado, seria uma maneira de enfileirar as gravações para adiar a chamada ao banco de dados. No entanto, eu esperaria que a fila desaparecesse em um segundo ou 2: então você precisa de uma fila se isso estiver OK?

Ou você pode colocar em spool em uma tabela de preparação e liberar mais tarde? Usamos essa técnica para lidar com gravações sustentadas de milhões de novas linhas por minuto (na verdade, usamos um banco de dados intermediário com recuperação Simples): mas não a implementamos até que tivéssemos experiência de apenas escrever linhas.

Nota: Toda gravação no SQL Server fará o disco como parte do protocolo Write Ahead Logging (WAL). Isso se aplica à entrada t-log para essa gravação.

A página de dados com a linha irá para o disco em algum momento (com base no tempo, uso, pressão da memória etc.), mas geralmente seus dados estarão na memória de qualquer maneira. Isso é chamado de "Ponto de verificação" e não remove dados da memória, apenas libera alterações (editado em 24 de novembro de 2011)

Editar:

Para considerações gerais, com base no último parágrafo acima, mude seu LDF para este banco de dados para um conjunto dedicado de discos para obter mais desempenho. O mesmo vale para um banco de dados intermediário (um para MDF / LDF). É bastante comum ter uma dúzia ou três volumes diferentes (via SAN normalmente) para o servidor de banco de dados

A menos que esteja faltando alguma coisa, isso violaria o requisito de durabilidade do ACID ( http://en.wikipedia.org/wiki/ACID ). Ou seja, se seu aplicativo "gravar" os dados na RAM e o servidor travar, seus dados serão perdidos.

Portanto, o que você procura é um sistema que não seja de banco de dados que serve como uma fila para armazenamento eventual em um banco de dados ou um sistema de banco de dados que seja suficientemente rápido para o que você está fazendo. Sugiro tentar o primeiro primeiro e ver se é suficiente; não peça emprestado problemas.

Eu usei uma vez um conjunto de dados para isso. Eu estava inserindo linhas no conjunto de dados quando elas chegaram e havia outro thread que estava liberando as linhas a cada 2 segundos no banco de dados. Você também pode usar o documento xml para fazer o cache e depois passar o xml para o banco de dados em uma chamada, isso pode ser ainda melhor.

Saudações

Piotr