No artigo, abordamos as melhores práticas que podem ajudar a aprimorar a eficiência operacional e fortalecer a segurança da sua empresa. Neste conteúdo, você encontrará uma lista abrangente de recomendações e dicas úteis para otimizar processos, proteger dados sensíveis e garantir a conformidade com regulamentações.

Abordaremos temas como gerenciamento de senhas, backups regulares, prevenção de ataques cibernéticos, conscientização da equipe, entre outros. Boa Leitura!

Trabalhe de forma inteligente com as práticas recomendadas do SQL Server

Práticas recomendadas do SQL Server

À medida que as pessoas começam a adotar e se familiarizar com novas tecnologias e novas plataformas, essas técnicas mais eficazes parecem borbulhar e se tornar o padrão para todos. É por isso que as chamamos de melhores práticas. Eles não estão necessariamente documentados na “literatura oficial”. Acreditamos que existem “melhores práticas” baseadas em suposições e teorias… e então existem melhores práticas baseadas na experiência e, bem, na prática.

Como nosso amigo Jeff Moden expressou uma vez no SQL Server Central:

Eu vi pessoas criarem artigos do “Santo Graal” que “provam” que os divisores XML vencerão os divisores do tipo Tally Table. E quase todo o mundo (incluindo o eu anterior) adotou algumas “Melhores Práticas” para manutenção de índice há mais de 20 anos por causa de algumas palavras erradas super simples e super infelizes na documentação oficial suportada pela Microsoft que também erroneamente fez cocô’ ed o uso de um tipo de dados notável, seus usos notáveis ​​e alguns métodos incríveis para desempenho. Que tal a “Best Practice” de fazer coisas como diminuir um Fill Factor até que a fragmentação pare, sempre usando colunas IDENTITY para praticamente tudo, ou mesmo desfragmentar índices apenas porque eles têm fragmentação lógica (o que nunca deve ser feito se eles tiverem um “0” Fator de preenchimento, BTW). Claro, é uma “melhor prática” não usar GUIDs aleatórios em um índice clusterizado, certo? Use NEWSEQUENTIALID() em vez disso, certo?”.

E depois há as alterações “especialistas” que foram feitas pela Microsoft, como o equivalente à invocação permanente do Trace Flag 1117 no TempDB, sem como desativá-lo, mesmo em uma base temporária necessária ou como LOBs padrão para in-row que destrói permanentemente a densidade da página do índice clusterizado. Sim … ambos são apenas dois exemplos de como as supostas “Melhores Práticas” colocaram duvidas nas pessoas sem que elas sequer soubessem disso.

Assim, assim como acreditamos que a zipper merge é uma prática recomendada quando o tráfego muda de duas faixas para uma, existem abordagens para o SQL Server que, quando aplicadas, oferecem resultados ideais. Aqui estão alguns dos nossos favoritos.

Práticas recomendadas do SQL Server do consultor sênior Dan Maenle

1. Teste seus backups! No domínio das restaurações do sistema, é bom ser um pouco pessimista. Em outras palavras, não é se, mas quando você precisará usar esses arquivos de backup úteis para voltar a funcionar. Portanto, você precisa ter 100% de confiança em seus backups, e isso significa testá-los. Nosso amigo Jonathan Kehayias tem outra maneira de ver isso: “Você não precisa de uma estratégia de backup, você precisa de uma estratégia de RESTORE, e planejar uma estratégia de BACKUP sem ter uma estratégia de RESTORE é fundamentalmente falho”.

2. Use tipos de dados corretos em joins e predicados. Os joins permitem que você recupere dados de duas ou mais tabelas com base em seu relacionamento lógico. Se os tipos de dados não forem idênticos, mas apenas compatíveis, o SQL Server deverá converter os dados de forma implícita ou explícita. Isso pode ser uma operação custosa. O SQL Server usa predicados para determinar quantas páginas de dados uma solicitação de dados deve buscar. Usar um tipo de dados incorreto com seu predicado também pode resultar em uma operação cara, pois envolve buscar muito mais registros do que o planejado.

3. Ative o Querystore. Dan é um defensor apaixonado do Querystore e organizou um webinar sobre o assunto para nós em 2022. Desde sua introdução no SQL Server 2016, o Query Store tem sido um salva-vidas de DBA… para aqueles que realmente o usam.

Daí esta melhor prática. Muitos usuários do SQL Server não sabem nada sobre esse recurso. É uma ferramenta ideal para resolver problemas de desempenho e encontrar diferenças de desempenho causadas por alterações no plano de consulta. É uma “caixa preta” para facilitar sua vida como DBA. Ele permite que você “volte no tempo” e analise o impacto no desempenho das alterações do plano de consulta e identifique e corrija quaisquer áreas problemáticas. Também é uma ferramenta importante para usar ao solucionar problemas de desempenho no Banco de Dados SQL do Azure. Ligue-o e beneficie-se de tudo o que ele faz.

4. Faça backup de sua master key de serviço. O SQL Server usa criptografia para proteger e proteger dados confidenciais. A Master key de Serviço (SMK) é a base dessa criptografia. O SQL Server gera automaticamente o SMK quando o SQL Server é iniciado pela primeira vez. O conselho da Microsoft é que o SMK “deve ser copiado e armazenado em um local seguro e externo. Criar esse backup deve ser uma das primeiras ações administrativas que você executa no servidor.” Sim, você pode restaurar o SMK, mas está longe de ser um exercício indolor. Faça um favor a si mesmo e siga a direção desta melhor prática.

Práticas recomendadas do SQL Server do consultor sênior Scott Klein

1. Não aceite as opções de configuração de memória padrão. O SQL Server pode e usa muita memória. As configurações padrão são 0 MB para memória mínima do servidor e 2.147.483.647 MB ​​para memória máxima do servidor, ou mais de 2 milhões de GB (lembre-se de que as configurações de memória são designadas em MB, não em GB). As advertências são: definir memória máxima muito alta significa que o SQL Server competirá pela memória com outras instâncias no mesmo host. Defini-lo muito baixo prejudica o desempenho. A Microsoft recomenda “75% da memória do sistema disponível não consumida por outros processos”.

A utilização de memória máxima e mínima ao executar várias instâncias é especialmente importante. Se você não for proativo em suas configurações de memória mínima e máxima do servidor, as instâncias que você acionar primeiro provavelmente alocarão toda a memória disponível, enquanto as instâncias ociosas não terão muito ou nada para trabalhar quando forem necessárias. Lembre-se de que o Windows não equilibra a memória entre os aplicativos.

E, a propósito, é uma má ideia definir a memória mínima do servidor para o mesmo nível da memória máxima do servidor. De acordo com a Microsoft, “quando a memória alocada para o SQL Server Database Engine atinge esse valor, o SQL Server Database Engine para de liberar e adquirir memória dinamicamente para o pool de buffers”. Então não faça isso.

2. Mantenha as funções fora da cláusula WHERE. Mais uma vez, trata-se de desempenho. Você pode se safar com funções na cláusula SELECT, mas pode ser um desastre com WHERE. O motivo é que as funções usadas com WHERE forçam o SQL Server a fazer uma verificação de tabela ou de índice em vez de uma busca de índice.

3. Pare de reduzir seus arquivos de dados. Ou: Só porque você pode reduzir seus arquivos de dados não significa que você deveria. Meu ponto aqui é que muitos simplesmente encolhem porque podem. A melhor prática é reduzir somente se você tiver feito um grande processo de arquivamento e removido grandes seções de dados do seu banco de dados. Ou, se você excluiu grandes quantidades de índices. Caso contrário, SAIBA QUANDO SHRINK seu banco de dados.

Por quê? A redução de seus arquivos de dados pode aumentar drasticamente a fragmentação do índice, o que pode prejudicar seu desempenho. Nada menos que um especialista do que Paul Randal escreveu: “A redução de arquivos de dados nunca deve fazer parte da manutenção regular e você NUNCA, NUNCA deve ativar a redução automática”. Que essa seja a palavra final sobre o encolhimento.

Ao aplicar essas práticas recomendadas do SQL Server em seu trabalho, tenho certeza de que você obterá os resultados desejados, evitando as dores de cabeça que não deseja.

Fale com um especialista

Fale com um especialista agora, e tenha a melhor solução de TI para sua empresa.

Acompanhe a Tripletech nas redes sociais: