Minha primeira palestra

08f4ad19-7b49-4b0c-b4de-14722d6337d3

No dia 26/11/2016 aconteceu o SQL Saturday 573 aqui em Brasília conforme já havia falado no post de divulgação do evento , mas o quê eu não tinha falado é que eu ia palestrar. De fato, até a data que lancei o post, eu não havia decidido bem se ia palestrar ou não, mas com muito incentivo dos meus colegas/amigos de trabalho e SQL decidi palestrar juntamente com o Gustavo (também colaborador do blog) .

Então aproveitando a oportunidade que me foi concedida de palestrar no Sat de Brasília (que já me sentiria a vontade por ser a minha cidade), juntando em ter meu parceiro de algum tempo de SQL Server (Gustavo) palestrando do meu lado e um tema que gosto muito (índices) tive a coragem e encaminhei minha palestra.

A palestra foi voltada para os alunos da faculdade e para todos os DBA’s iniciantes que querem entender melhor para que serve um índice. Como o próprio tema deixa bem claro, “Indexação para iniciantes” foi bem básica mesmo, expliquei para que servia um índice, suas vantagens, melhores práticas e desvantagens seguidos de exemplos. Apesar da palestra ser bem básica, tive a presença de colegas DBA’s, que já entendem bastante do assunto, assistindo a nossa palestra. Todo esse apoio me deixou mais segura e confiante para passar um pouco do meu conhecimento.

Sou muito grata por ter essa oportunidade de poder contribuir um pouco com a comunidade. Essa gratidão é grande, pois a comunidade SQL Server é muito forte, cada um apoia o outro, passam o conhecimento sem nenhum interesse e sem nenhuma cobrança e posso dizer que minha carreira de DBA teve muita ajuda dela, então poder devolver um pouco do conhecimento adquirido é uma felicidade enorme. Agradecimento mais que especial para o Gustavo parceiro do blog e por ter palestrado comigo , Edvaldo pelo evento incrível e pela oportunidade de palestrar nele e Renato por ter assistido minha palestra e pelo feedback.

Espero que essa seja a primeira palestra de muitas que estão por vir (realmente espero não parar por aqui), aperfeiçoando cada vez mais a forma de passar o conhecimento.

Enfim, o material estará disponível no site do sql sat em alguns dias.

Seguem algumas fotos do evento para que quem não foi, não perder o próximo!

 

Adicionar MountPoint Cluster SQL Server

Hoje venho aqui mostrar um simples tutorial de como adicionar um mount point em seu Cluster do SQL Server.

Vamos lá!

  1. Antes de adicionar um mountpoint no cluster, o mesmo deverá ser adicionado pela equipe de armazenamento nos servidores físicos.

  2. Com as Luns já disponíveis nos servidores, os seguintes procedimentos deverão ser executados antes de acrescentá-las no cluster:

• Realizar o Rescan em todos os nós físicos do Cluster para que os mesmos possam enxergar o novo disco:

Img1

• Após realizar o Rescan, todos os nós conseguem enxergar e colocar a LUN Online. Para colocar a LUN Online, os seguintes passos deverão ser executados:

Img2

• Inicializar o disco:

img3

img4

o MBR: Utilizado para discos com menos de 2TB.

o GPT: Recomendável para discos com mais de 2TB.

  1. Adicionando disco no Cluster:

img5

Marcar o disco que está compartilhado a ser adicionado no Cluster.Nesse caso só temos um disco disponível.

img6

No próximo print podemos verificar se o disco foi adicionado corretamente e em qual servidor ele está associado.

img7

• Criar novo volume:

No servidor que está como Current Owner do disco, deveremos realizar os seguintes passos:

img8

img9

img10

img11

img12

Para os servidores do SQL Server é recomendado colocar o Allocation Unit com o tamanho de 64K.

img13

• Associando disco ao servidor virtual: Movendo o disco para a sua instância de destino.

img14

Escolher a instância que para onde será movido o disco.

img15

Após mover o disco para a instância, executar os seguintes comandos para renomear o disco no Cluster e adicionar a dependência.

img16

Renomeando o disco.

img17

Adicionando dependência.

img18

Recurso de serviço do SQL Server, adicionar o novo disco como dependência (se necessário).

img19

img20

Pronto! O novo disco já está pronto para ser utilizado!

Dica: Como boa prática de teste, criar uma base Fake para testar o acesso ao disco antes de colocar a base de produção.

Administração de índices (Parte 2).

Depois de vários dias sem postar, finalmente consegui um tempinho para escrever a segunda parte da série de posts que falarão sobre a sua rotina de desfragmentação dos índices.

Como foi falado no Post anterior, muitos DBA’s usam o seguinte script para realizar a desfragmentação de seus índices: http://technet.microsoft.com/en-us/library/bb838727(v=office.12).aspx

Eu também já usei, mas hoje no ambiente em que trabalho esse script não serve mais e listo aqui o porquê que essa rotina já não é tão eficiente para mim.

  1. O ambiente não há uma janela muito flexível para esse tipo de manutenção;
  2. O ambiente é muito grande, pois temos várias instâncias e em cada instância temos no mínimo 50 bases de dados;
  3. Apesar de existirem tabelas que fragmentam mais de 15% diariamente, nem todas podem entrar na rotina, pois são muito grande (20GB cada uma) e se elas fizerem parte dessa rotina automática, podem causar um estouro no disco (justamente por não ter um controle de quais tabelas serão fragmentadas no dia);
  4. Essa rotina não faz a validação do tamanho da tabela. Apesar de a tabela estar fragmentada, se ela for pequena o SQL Server não realiza o REBUILD da mesma.

Pelo que eu me lembre, eu trabalhava em um ambiente em que a rotina de desfragmentação dos índices era esse script. Na época a base de dados tinha em torno de 200GB e essa rotina executava diariamente. O tempo de duração em média era 2h podendo demorar 1h e tinha dias de demorava até 4h, porém tinha dias também que essa rotina não executava, pois ocorria um DeadLock.  Naquele ambiente, apesar de demorar muito e ter essa concorrência no banco, essa rotina não tinha nenhum efeito colateral, pois a janela era realmente grande e não causava impacto para o usuário final.

Atualmente temos que reindexar algumas tabelas relativamente grandes, porém a minha janela diária de manutenção é de no máximo 30min, se passar disso já tem um impacto para o usuário final podem causar até um prejuízo financeiro para instituição. Nesse caso qual é a minha solução? Atualmente faço o Rebuild da forma “simples” com o seguinte comando:

 ALTER INDEX ALL ON Tabela REBUILD WITH (ONLINE=ON) 

Sim! É um trabalho bastante manual, pois tenho que saber direitinho quais são as tabelas que necessitam ser desfragmentadas, saber a frequência de fragmentação das mesmas, assim como o seu tamanho e dividir a rotina fazendo com que ela não estoure o nosso disco de log (isso porque tenho bastante espaço disponível). Lembrando que na minha rotina deve ter no máximo umas 30 tabelas (sendo que cada banco eu tenho em volta de 1700 tabelas). Essas 30 tabelas não são desfragmentadas tudo de uma única vez, temos rotinas que rodam diariamente, outras 2 vezes na semana e outra no Domingo.

Então, levando em consideração que temos 50 bases por instâncias, 1700 tabelas por base e somente 30min de janela por dia para realizar o Rebuild, concluímos que é muito arriscado colocar uma rotina automática para realizar a desfragmentação, pois não temos controle de quanto de log será gerado no momento da rotina…

Quero que pensem bem, sei que muitos ao realizarem essa rotina, não se preocupam com o log que será gerado nem com o espaço em disco utilizado por esse arquivo… Pensem um pouco sobre o quanto o Log pode sofrer com essas rotinas, lembrando que em um banco de dados, temos várias funcionalidades que utilizam o Log, alguém se habilita a dizer qual dessas funcionalidades “sofre” bastante com essa rotina de Rebuild? No próximo post (daqui um mês quem sabe rsrs) eu falo mais. Falarei também qual solução achamos para que os índices não fragmentem tanto, diminuindo assim, a frequência da rotina de desfragmentação.