Fala pessoal!!
Fim de ano chegando, todo mundo se preparando para o Réveillon e por isso, eu gostaria de compartilhar com vocês os “TOP 10 artigos técnicos de 2019 que vocês mais gostaram”, isto é, os artigos que publiquei em 2019 e que vocês mais visualizaram. Espero que vocês gostem dessa pequena lista e que algum artigo possa ser útil para você, caso ainda não o tenha visto antes.
Sem muita enrolação e vamos para a lista.
#10 – SQL Server – Como evitar ataques de força bruta no seu banco de dados
Nesse artigo, demonstrei como ocorrem ataques de força bruta ao SQL Server e como tentar se defender desse tipo de ataque.
Ataque de força bruta é a técnica mais simples e demorada para invadir sistemas e bancos de dados. Ela consiste em utilizar bases de dados de senhas para testar cada uma dessas senhas ou realizar uma verificação sistemática de todas as possíveis chaves e senhas até que uma delas consiga logar com sucesso no destino.
Esse tipo de ataque pode ser usado quando não é possível tomar vantagem de outras fraquezas em um sistema de criptografia (se existir) que tornariam a tarefa mais fácil, já que o tempo necessário para testar todas as senhas possíveis pode passar de alguns segundos (3 caracteres) para milhares de anos, de acordo com a quantidade de caracteres da senha e complexidade dos caracteres utilizados.
#9 – SQL Server – Como identificar e coletar informações de consultas demoradas utilizando Extended Events (XE)
Nesse artigo compartilhei com vocês como identificar e coletar informações de consultas demoradas utilizando Extended Events (XE), num artigo bem parecido com o SQL Server – Como identificar e coletar informações de consultas demoradas utilizando Trace (SQL Server Profiler), que utiliza a tecnologia de Profiler (Trace).
O que me motivou a escrever esse artigo foi que o Profiler é um recurso que está marcado como deprecated há bastante tempo, é uma tecnologia bem mais antiga e o código não é nada amigável ou legível. Então, pensando em trazer uma solução mais moderna e intuitiva para vocês, resolvi compartilhar essa solução utilizando o XE.
#8 – SQL Server – Dicas de Performance Tuning: Conversão implícita? NUNCA MAIS!
Nesse artigo eu gostaria de comentar sobre um problema de performance em consultas que encontramos bastante aqui no nosso dia a dia na Fabrício Lima – Soluções em BD, uma das melhores e mais reconhecidas empresas de Performance Tuning do Brasil. Estamos falando de algo que, muitas vezes, é terrivelmente simples de resolver e inexplicavelmente e extremamente comum, conversão implícita.
A conversão implícita ocorre quando o SQL Server precisa converter o valor de uma ou mais colunas ou variáveis para outro tipo de dado com a finalidade de possibilitar a comparação, concatenação ou outra operação com outras colunas ou variáveis, já que o SQL Server não consegue comparar uma coluna do tipo varchar com outra do tipo int, por exemplo, se ele não convertesse uma das colunas para que ambas tenham o mesmo tipo de dado.
#7 – SQL Server – Quando você deve utilizar ORDER BY na consulta e quando não deve utilizar de jeito nenhum!
Nesse artigo, compartilhei com vocês quando se deve utilizar ORDER BY e quando não devemos utilizar de jeito nenhum, porque não produz efeito nenhum na prática e apenas deixa nossa consulta mais demorada e consumindo mais recursos.
O intuito principal desse artigo foi quebrar o mito de que os dados são ordenados fisicamente na tabela quando você faz o INSERT… FROM SELECT e ORDER BY, fazendo com que muitos programadores insistam em utilizar ORDER BY em operações de INSERT, um cenário que eu encontro bastante nos clientes de consultoria e é bem mais comum do que eu gostaria.
#6 – SQL Server – NOLOCK vs READPAST: Você sabe a diferença entre os dois ?
Nesse artigo, pude demonstrar na prática, o uso de 2 query hints bastante utilizados pelos desenvolvedores para evitar locks na leitura de dados, que são o NOLOCK e o READPAST, e demonstrar efetivamente qual o efeito desses hints em uma consulta.
A ideia de escrever esse artigo veio através de uma dúvida enviada no grupo “SQL Server – DBA”, do Telegram, e também num desejo antigo de escrever sobre isso sempre que vejo ambientes onde quase todas as consultas tem NOLOCK.
Depois de ler esse post, você será capaz de entender exatamente como esses 2 hints funcionam e vai utilizá-los sabiamente e apenas quando conveniente. Nada de sair colocando NOLOCK/READPAST em todas as suas consultas hein!
Caso seu ambiente tenha uma grande concorrência e os locks, blocks e deadlocks sejam frequentes e um problema para você, sugiro pensar numa abordagem mais completa que utilizar esse hints, que seria utilizar o modo de isolamento Read Committed Snapshot (RCSI), que permite utilizar o modo Read Commited sem travar as leituras quando ocorrem transações abertas. Como nem tudo são flores, existem alguns efeitos colaterais ao se utilizar esse modo, como possível queda de performance. Caso você queira saber mais sobre ele, sugiro a leitura do artigo Read Committed Snapshot Isolation: Writers Block Writers (RCSI), do grande mestre Brent Ozar.
#5 – SQL Server – Como evitar e se proteger de ataques de Ransomware, como WannaCry, no seu servidor de banco de dados
Nesse artigo de número 350 do blog, compartilhei com vocês a minha experiência durante diversos testes que eu fiz sobre Ransomwares em servidores de bancos de dados SQL Server, como o WannaCry, que baixei e “infectei” minha VM apenas para realizar esses testes, entender como ele age e como podemos nos proteger contra esse tipo de ataque, que por incrível que pareça, ainda é comum no dia a dia dos DBA’s que trabalham em empresas de consultoria.
De acordo com a Cartilha de Segurança para Internet, Ransomware é um tipo de código malicioso que torna inacessíveis os dados armazenados em um equipamento, geralmente usando criptografia, e que exige pagamento de resgate (ransom) para restabelecer o acesso ao usuário, onde pagamento do resgate geralmente é feito via bitcoins ou outra cryptomoeda.
O Ransomware mais conhecido até o momento é o WannaCry, que foi considerado o maior ataque deste tipo já registrado até o momento, tendo início no dia 12/05/2017, atacando cerca de 150 países e infectando mais de 230 mil sistemas, embora existam vários outros rodando pela rede.
#4 – SQL Server – Consultas úteis do dia a dia do DBA que você sempre tem que ficar procurando na Internet
Nesse artigo, eu tive o prazer de poder compartihar com vocês, vários scripts úteis do dia a dia do DBA que você sempre tem que ficar procurando na Internet quando precisa fazer uma determinada consulta. A minha ideia nesse artigo, foi facilitar a sua vida e ter uma artigo com vários scripts, de diversas finalidades, para você favoritar no seu navegador e ter sempre as informaçõs que deseja em um só local ?
#3 – SQL Server – Checklist de Segurança – Uma SP com mais de 70 itens de segurança para validar seu banco de dados
Nesse artigo, compartilhei com vocês um projeto que venho desenvolvendo desde novembro de 2018 e hoje conta com mais de 6.000 linhas de código, que é um Checklist de Segurança bem completo (provavelmente, o mais completo e abrangente que você encontrará na Internet), contando com mais de 70 itens de Segurança para validar seu banco de dados, passando pela parte de configurações e parâmetros, permissões, objetos de programação e muito mais!
Depois de tanto ver as empresas, desenvolvedores (e às vezes, os próprios DBA’s) negligenciarem a parte de segurança, onde vemos ambientes em que a aplicação utiliza o usuário “sa”, encontramos milhares de tentativas de conexão com senha incorreta e ninguém faz nada, ambientes SEM BACKUP e tantos outros absurdos, resolvemos criar uma forma muito prática e fácil de rapidamente ter uma visão geral de como está a segurança da instância, num formato amigável e com informações técnicas ao mesmo tempo, e que permita facilmente exportar para um Excel e demonstrar para o cliente os vários problemas encontrados, o impacto que issso pode causar no ambiente e como resolver.
Conheçam nesse artigo, a solução definitiva para a grande maioria dos problemas de segurança do seu SQL Server.
#2 – Lei Geral de Proteção de Dados Pessoais (LGPDP ou LGPD) aplicada a bancos de dados SQL Server
Neste artigo, eu pude abordar sobre um tema que está muito em alta na área de tecnologia em geral, que é a Lei Geral de Proteção de Dados Pessoais (LGPDP ou LGPD), uma “prima” da GDPR que está em vigor na Europa, e deve virar uma realidade no Brasil a partir de agosto de 2020, trazendo várias mudanças na forma em que os profissionais de TI atuam no seu dia a dia e na forma como produtos (Softwares, bancos de dados, etc) são desenvolvidos.
A LGPD é a sigla para Lei Geral de Proteção de Dados, cujo objetivo é aumentar a privacidade de dados pessoais e evitar casos como os grandes vazamentos de informações e escândalos que envolvem justamente o uso indevido de informações pessoais que temos acompanhado nos últimos anos. A criação dessa lei, coloca o Brasil no rol de mais de 100 países que, hoje, podem ser considerados adequados para proteger a privacidade e o uso de dados no cenário global.
Diferente de tudo o que eu já li de material sobre esse tema, o objetivo de criar esse artigo, foi focar essa análise especificamente em bancos de dados SQL Server, demonstrando como podemos melhorar a segurança do nosso banco de dados e estar em conformidade com essa nova lei.
#1 – SQL Server – Utilizando colunas calculadas (ou colunas computadas) para Performance Tuning
Neste artigo, eu gostaria de compartilhar com vocês algo que vejo bastante no dia a dia quando estou realizando consultoria de Tuning, que são consultas demoradas, com alto consumo de I/O e CPU, e que utilizam funções no WHERE ou JOIN em tabelas com muitos registros e como podemos utilizar uma técnica bem simples de indexação de coluna calculada (ou computada) para resolver esse problema.
Conforme eu comento no artigo Entendendo o funcionamento dos índices no SQL Server, ao utilizar funções em cláusulas WHERE ou JOINS, nós estamos ferindo o conceito de SARGability da consulta, ou seja, estamos fazendo com que essa consulta passe a não utilizar operações de Seek nos índices, uma vez que o SQL Server precisa ler toda a tabela, aplicar a função desejada para depois, comparar os valores e retornar os resultados.
O que eu quero nesse artigo, é demonstrar a vocês esse cenário acontecendo, como identificar isso e algumas possíveis soluções para melhorar a performance das consultas. Então, vamos lá!
Bom pessoal!
Espero que tenham gostado dessa pequena lista, um grande abraço e até o próximo post!
Portuguese 
English