Category: SQL

Deletes numa heap podem não reduzir nem o tamanho nem o número de reads

Esta é estranha… ou não. Só quem nunca passou por ela é que duvida. Eu já passei por ela. Estava a falar sobre isto com um colega que ainda não passou e que, naturalmente, duvidou. Nada como mostrar que é possível. Criamos uma tabela sem índice clustered, apenas um nonclustered. Heap mais simples não vão encontrar… Inserimos alguns valores. No meu caso, 24025 linhas. Vamos ver o...

Cuidados a ter com o uso de ROWCOUNT

Eu uso muitas vezes ROWCOUNT, normalmente para partir certas operações em batches. Exemplo clássico, um delete gigante que não queremos que encha o nosso transaction log. E sim, é mais usual do que pensamos. A questão deste post é que temos de ter muito cuidado como usamos esse rowcount, porque alguém pode mexer no nosso código mais tarde. A sério, não percebo porque é que alguém algum...

Vale a pena passar de SQL Server 2014 para SQL Server 2017?

Surgiu num cliente uma questão bem pertinente mas a que já vamos estando habituados. Será que vale a pena fazer upgrade de SQL Server 2014 Standard para SQL Server 2017 Standard? tl;dr Sim. Este cliente tem um misto de SGBD’s num misto de versões.A questão surgiu para um certo servidor que, estando agora em SQL Server 2014, poderia ser actualizado para SQL Server 2017. Duas vantagens que...

Mais cuidados a ter com select into para temporárias

Se bem se lembram, há uns dias fiz aqui um post a relembrar termos cuidado quando fazemos um select into para uma temporária. Este é outro caso em que as coisas podem não acabar como esperámos. Da última vez mostrei como num select into o coluna fica nullable se a tabela fonte tem a coluna nullable. Nesta demo mostro o contrário, como partimos de uma coluna que...

Num select into o campo é nullable se o campo da tabela original é nullable.

Passa muitas vezes despercebido aos mais incautos. Mesmo que tenhamos uma query em que explicitamente colocamos uma coluna not null, o select into vai deixar a definição da coluna nullable. Mas porque é que isso interessa? Interessa porque sabemos que é muito mais do que um preciosismo definirmos o nosso modelo de dados como deve de ser. Há muitas maneiras de o SQL Server melhorar um plano...

Será que quando se declara uma variável o SQL Server usa logo o espaço?

Eu sei que posso já ser considerado da “velha guarda”. Aprendi a programar com 11 anos, há mais anos do que muitos colegas meus têm de vida. Se calhar é por isso gosto de ver coisas feitas à moda antiga. Uma delas é ver todos os declare no topo do script. E de repente: Mas assim apenas declaro mais abaixo e só aí vou usar o espaço...

Cuidado com casts em campos char/nchar/varchar/nvarchar

Há erros que nunca cometemos. Por exemplo, um overflow num int que nos faz pensar por que raio é que a coluna não foi logo definida como bigint. Ou um destes casos que quero mostrar agora. Porque nunca acontecem. Sabemos que se tentarmos ultrapassar certos limites, o SQL Server nos avisa. Ou este Mas há outros… Vamos correr de novo para vermos os tamanhos reais em bytes...

Quando um erro dentro de um TRY não corre o código dentro do CATCH

Conversa interessante com um colega de profissão, estamos a discutir um caso em que anda um bug à solta e de repente digo-lhe: “Mas nem sempre um TRY/CATCH funciona como estás à espera, por vezes há erro dentro do código no TRY e não salta para o CATCH”. Sim, há quem não acredite. Mas acontece. E até está bem documentado. Vamos ver um desses casos para dissiparmos...

Adicionar um índice para ajudar nos updates e deletes pode não ajudar, revisitado.

Há poucos dias fiz um post sobre como nem sempre um índice ajuda em updates e deletes. Para situar quem não o leu, mostrei que um índice que à primeira vista pode ajudar nem sempre o faz. Por vezes até se revela desastroso em termos de performance. Mas como há sempre quem diga que “não cobriste todos os casos, se tivesses __________ seria diferente”. E ainda bem...

O tamanho dos varchar interessa, mesmo que o SQL Server só use o espaço que necessita, revisitado.

O meu post de há algum tempo sobre o tamanho das variáveis e o memory grant deu algo que falar, por isso resolvi, ao estilo de Hollywood destes últimos anos, revisitá-lo. Se se lembram desse post (também não foi há assim tanto tempo…) a questão era: O tamanho das variaveis não interessa, se eu colocar um varchar(max) ou varchar(50) é igual porque o SQL Server só usa...