SQL SERVER - Dicas que todo DEV deveria conhecer part-1

    Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server em seu dia-a-dia na empresa.

Serão abordados diversos temas sequenciais, e depois da conclusão listaremos todos em um menu completo aqui.

Part-1 Transaction Log 
Part-2 Variáveis ​​table e JOIN's & Criação de tabelas dentro de stored procedures

Part-1 Transaction Log 

De modo simplista, todos imaginamos que quando executamos algum DML insert, update ou delete.
O SGBD registra em disco Transaction Log (faremos referencia com T-Log, daqui pra frente) para depois efetuar commit em mdf, certo?

Não - Errado.

Neste caminho simplificado, existe um camada de Log Buffer. Uma região em memoria responsável pelo buffer das informações, que somente apos check irá "commitar" esses dados em memoria para disco log. De maneira simplificada, esse é o WAIT mais comum relacionado ao T-Log.
Ele está relacionado ao tempo que SQL Server está esperando para escrever no disco.

Como podemos otimizar essa escrita ?

Nossa primeira Dica, neste tópico será a otimização do Transaction log, imaginem um loop de 10mil transações:

Já imaginou o trabalho que o SQL Server teria para abrir e fechar 10mil transações em loop?
Então imagine como seria muito mais simples, fazer tudo em uma única transação!

Padrão:

WHILE @id < 10000

   BEGIN

    INSERT INTO TABELA_TESTE VALUES(...)

   END

Melhoria:

BEGIN TRAN

   WHILE @id < 10000

   BEGIN

    INSERT INTO TABELA_TESTE VALUES(...)

   END

COMMIT

*

Por favor não confundam transaction begin tran  / while if begin de blocos de comando ok

Essa falha é muito comum em select into, update from também, onde indiferente da transação 

Já existiria um tratamento de erro no final If (@@Error > 0). O que torna totalmente adaptável o controle transacional no bloco de repetições.

No exemplo nosso tempo de execução baixou de forma considerável de mais de 2 minutos para 45 segundos! Ou seja, foi reduzido mais da metade do tempo! Essa melhora ocorreu por que o SQL Server processou as 10 mil inserções em uma única transação. Nem sempre é possível realizar essa otimização, mas ela pode ser uma boa solução.