In-Memory OLTP

Microsoft SQL Server 2016 SP1 – Atualização Cumulativa 8 disponível

A Microsoft disponibilizou para download recentemente a Atualização Cumulativa 8 para SQL Server 2016 SP1. As informações obtidas através do artigo KB4077064 publicado no site de suporte da Microsoft, esta atualização traz correções decorrentes dos problemas apresentados e identificados após o lançamento do SP1 e das atualizações cumulativas anteriores. Relação de Atualizações Cumulativas disponíveis para … Continue Lendo "Microsoft SQL Server 2016 SP1 – Atualização Cumulativa 8 disponível"

O “SQL Server 2016” está chegando

Satya Nadella, CEO da Microsoft, anunciou o “SQL Server 2016”, a mais nova versão da plataforma de dados da Microsoft no MS Ignite 2015. Existem melhorias significativas, como: Always Encrypted O SQL Server tem os bancos de dados com o menor número

Webcast Virtual PASS – Agosto – 2014

Olá pessoal, Como já é de costume, O Global Portuguese Virtual PASS aka Virtual PASS PT realiza mensalmente os webcasts sempre trazendo um assunto diferente. E para o mês de Setembro, preparamos mais uma sessão de peso com o MVP em SQL Server Luan Moreno. Abaixo, você tem mais detalhes. Cenários de Utilização In-Memory OLTP […]

Apresentação NetPonto – O RESCALDO

No passado sábado realizei a apresentação "SQL Server 2014 In-Memory OLTP – Game Changer para os Programadores" na 45ª Reunião Presencial da Comunidade NetPonto em Lisboa.

A minha autoapreciação da sessão é bastante positiva mas existiram alguns pontos que causaram alguma controvérsia (ou criaram algumas dúvidas) nomeadamente a necessidade de tratamento de erros. Para quem não esteve presente aqui fica um breve resumo da questão:

Com a adoção da nova componente In-Memory OLTP do MSSQL 2014 irão inevitavelmente ocorrer erros onde anteriormente ocorriam "esperas". Isto deve-se ao facto de se tratar um modelo "lock-free", ou sejam, um modelo concorrencial otimista onde não são utilizados locks para impedir o acesso concorrencial às mesmas estruturas de dados por pedidos simultâneos distintos. Os locks são dispensados pois é utilizada uma multiversion store, isto é, é mantido um histórico de todos os registos alterados com a indicação do momento em que a referida alteração ocorreu. Desta forma, sempre que uma transação necessita de consultar os dados de um registo, que está a ser/foi alterado, não fica a aguardar pelo término de uma transação mas acede aos dados que existiam no momento em que a transação iniciou. Neste exemplo tudo parece correr bem… mas irão existir situações em que este modelo terá consequências “adversas”. Vamos tentar perceber porquê:


Modelo Pessimista (default no MSSQL 2012)

Modelo Optimista (default no In-Memory 2014)


Como é fácil de perceber o modelo optimista é mais “amigo” da concorrência visto que a Transação 2 não fica á espera que a transação 1 termine.

Vamos ver uma situação em que o comportamento tem efeitos colaterais diferentes que necessitam de alguma atenção:

Modelo Pessimista (default no MSSQL 2012)

Modelo Optimista (default no In-Memory 2014)



Neste caso a transação 2 é interrompida e dá origem a um erro porque ocorre a tentativa de atualização de um registo que tem uma alteração “pendente”. Este tipo de erros são algo que terão que ser tratados pelos programadores porque a abordagem agora é: “Fail Fast/Retry Faster”, isto é, se é para falhar que falhe depressa e tentamos novamente rapidamente.

De qualquer maneira podemos adotar esta lógica nas nossas SPs e evitar alterações a nível aplicacional.

Uma forma de contornar isto seria utilizar algo do género:



Ora foi exatamente este ponto que suscitou alguma controvérsia pois foi apresentada, a título de exemplo, esta SP com o comando while (medo!!!) e a ideia que ficou foi a de ser necessário alterar muito código com a adoção deste novo componente. A verdade é que o tratamento de erros deveria ser uma constante no nosso código e na falta de um comando BEGIN TRY WITH X RETRIES temos que de alguma forma controlar o número de vezes que um comando deve ser repetido caso falhe. Esta forma pode ter origem a nível aplicacional ou pode ser embebida nas Stored Procedures. Isto não é nada de novo mas sim algo que tem vindo a ser descurado… Veja-se a título de exemplo a sugestão Microsoft para solucionar o problema dos dead locks:


Source: http://technet.microsoft.com/en-us/library/ms179296(v=sql.105).aspx

Não obstante a reação "negativa" é importante ressalvar quenão devemos passar todas as nossas tabelas para o modelo In-Memory e esperar só vantagens. Deve ser feita uma análise criteriosa dos custos/beneficios desta abordagem...
Go to Top