Qual instrução é melhor para o desempenho - SELECT ou SET? SQL Server

Pergunta:  Qual instrução é melhor para o desempenho - SELECT ou SET?

Lembre-se de que o  SELECT  foi projetado para retornar dados, enquanto o  SET  foi projetado para atribuir valores a variáveis ​​locais.

Então ao comparar seu desempenho na instrução SELECT de loop, obtém-se melhor desempenho do que SET. Em outras palavras, SET é mais lento que SELECT. O motivo é que cada instrução SET é executada individualmente e atualiza os valores por execução, enquanto a instrução SELECT inteira é executada uma vez e atualiza todos os três valores em uma execução.

SET é o padrão ANSI para atribuição de variáveis, SELECT não é. SET só pode atribuir uma variável de cada vez, SELECT pode fazer várias atribuições de uma vez - o que dá a SELECT uma pequena vantagem de velocidade em relação a SET. Se atribuir a partir de uma consulta, SET só pode atribuir um valor escalar. Se a consulta retornar vários valores / linhas, SET gerará um erro. SELECT atribuirá um dos valores à variável e ocultará o fato de que vários valores foram retornados. Ao atribuir a partir de uma consulta, se não houver nenhum valor retornado, SET atribuirá NULL, onde SELECT não fará a atribuição mantendo a variável inalterada.

Referências Pinal Dave blog.sqlauthority.com
Estas e outras dicas aqui no blog acompanhe.

Grande abraços

Diferenças entre as funções SQL @@ IDENTITY, SCOPE_IDENTITY, IDENT_CURRENT

Na maior parte do nosso cotidiano de aplicação, precisamos obter as últimas informações de linha inseridas por meio da consulta SQL. E para isso, temos várias opções como:

• @@IDENTITY
• SCOPE_IDENTITY
• IDENT_CURRENT

Todas as três funções retornam valores de IDENTITY gerados pela última vez. No entanto, o escopo e a sessão em que o último é definido em cada uma dessas funções são diferentes.

@@IDENTITY

Ele retorna o último valor de identidade gerado para qualquer tabela na sessão atual, em todos os escopos. Deixe-me explicar ...  imaginamos que nós criamos um insert trigger na tabela que insere uma linha em outra tabela com gerar uma coluna de identidade e, em seguida, @@IDENTITY retorna esse registro de identidade que é criado por trigger.

SCOPE_IDENTITY

Ele retorna o último valor de identidade gerado para qualquer tabela na sessão atual e no escopo atual.

Deixe-me explicar isso ... imaginamos que criamos um trigger de inserção na tabela que insere uma linha em outra tabela com gerar uma coluna de identidade, então o SCOPE_IDENTITY resultado não é afetado, mas se um trigger ou uma função definida pelo usuário for afetada na mesma tabela que produziu o valor retorna esse registro de identidade e, em seguida, SCOPE_IDENTITY retorna esse registro de identidade que é criado por acionador ou uma função definida pelo usuário.

IDENT_CURRENT

Retorna o último valor de identidade gerado para uma tabela específica em qualquer sessão e qualquer escopo. Em outras palavras, podemos dizer que ele não é afetado pelo escopo e pela sessão, ele só depende de uma tabela específica e retorna esse valor de identidade relacionado à tabela que é gerado em qualquer sessão ou escopo.

Este artigo, juntamente com qualquer código-fonte e arquivos associados, está licenciado sob a Licença Aberta do Projeto de Código (CPOL).

Como reduzir o TempDB sem reiniciar o SQL Server ...

Durante atendimento de alguns clientes, fui encarregado desta tarefa. Quando solicitado rotinas de shrink database, questionamos por qual a razão eles gostariam que sempre esteja um dba acompanhando. O Shrink TempDB é uma tarefa omnipresente e elas não precisam de ajuda ou de nenhum acompanhamento. No entanto, sempre foram bastante inflexíveis que gostariam de uma presença em plantão durante a chamada.

Logo no primeiro momento percebemos qual era o problema. Eles não conseguiram encolher seu TempDB mesmo que eles estivessem executando o comando SHRINKFILE por diversas vezes.

Antes de todos pular e começar a falar, que não devemos reduzir o banco de dados, pois isso é ruim para o sistema e desempenho, Eu Concordo.

Agora, deixe-nos ver como podemos encolher o banco de dados TempDB.

1 2 3 4 5 6

CHECKPOINT GO DBCC FREEPROCCACHE GO DBCC SHRINKFILE (TEMPDB, 1024) GO

     

Quando os usuários estavam executando apenas o Shrink File, eles não conseguiram reduzir o banco de dados.No entanto, quando recorremos ao DROPCLEANBUFFERS funcionou bem. No entanto, note que DROPCLEANBUFFERS irá remover todo o cache de PROCEDURES, o que pode diminuir a velocidade de alguns sistemas imediatamente, pois eles precisam reconstruir novamente os caches.

Atenção, reduza o seu TempDB SOMENTE se estiver fora do ar ou em situações criticas!

Se você chegar ao ponto em que você necessite reiniciar os serviços para reduzir o database, você pode considerar uma ultima opção e então executar o DBCC FREEPROCCACHE (que irá funcionar como quando você reinicia os serviços, não apenas remove o cache, mas também todas as paginações de dados em cache).


Referências:  Pinal Dave

https://docs.microsoft.com/pt-br/sql/relational-databases/databases/shrink-a-database

https://docs.microsoft.com/pt-br/sql/t-sql/database-console-commands/dbcc-dropcleanbuffers-transact-sql

https://docs.microsoft.com/pt-br/sql/t-sql/database-console-commands/dbcc-freeproccache-transact-sql