Fala Pessoal,

Hoje vou compartilhar com vocês sobre uma migração que fiz em um cliente no início do mês.

Cenário Antigo:

• Windows Server 2008
• SQL Server 2008 R2 Standard
• Servidor único (migração para o mesmo Hardware)

Novo Cenário:

• Windows Server 2012 R2
• SQL Server 2016 Standard Edition

Como não tínhamos um hardware em paralelo para fazer uma migração Side-by-Side que é a mais rápida e segura, tivemos que formatar o servidor para reinstalar o Sistema Operacional e o SQL Server. Contudo, as letras das bases do SQL Server ficavam em um Storage e foram mantidas na formatação.

Atividades pré-virada

• Instalar o SQL Server 2016 em uma VM para homologação
• Testar as aplicações apontadas para o SQL Server 2016
• Documentar todo o ambiente pois vamos ter que formatar o servidor. Se esquecer de algo, lascou!!!
  • Localização das bases
  • Localização da instalação
  • Collation da Instância
  • Configuração de memória do SQL
  • Configurações avançadas da Instância
  • Serviços do SQL Instalados
  • Usuários dos serviços do SQL Server, Agent e etc…
  • Tem alguma procedure na master ou msdb? (não deveria, mas é bom conferir)
  • Configurações do Database Mail
  • Usa plano de Manutenção? (confere)
  • Etc…
• Executar o DMA (Data Migration Assist) para identificar possíveis problemas de incompatibilidade das bases.
  • Nesse teste do DMA, identifiquei duas bases com problema e repassei ao cliente que teve que acertar essas bases antes de migrar.
  • Ele mostra inclusive o nome das procedures, functions ou views que estão com códigos incompatíveis. Sensacional!!!

Pouco antes da migração realizei as atividades abaixo:

• Gerar os scripts de logins para recriar posteriormente com a mesma senha.
  • https://support.microsoft.com/pt-br/help/918992/how-to-transfer-logins-and-passwords-between-instances-of-sql-server
  • Logins sysadmin, não são recriados como sysadmin. Dessa forma, você deve documentar para dar esse acesso manualmente na nova instalação.
• Gerar os Scripts dos Jobs, Operators e Linked Server direto no SSMS (F7->Seleciona os objetos->Generate Script).
  • Cuidado que LS que tem password, o script não é gerado com essa senha. Terá que ter a senha para recriar no novo server.

Atividades Durante a Virada

Esse cliente tinha um Mirror configurado e 24 bases na instância. Dentre elas uma de 528 GB e outra de 252 GB.

O servidor de mirror tem uma capacidade muito menor e por isso não foi utilizado para fazer uma migração Side-by-Side. A produção teve que se manter no mesmo hardware. O objetivo desse mirror é apenas ter o dado espelhado.

O planejado foi iniciar a virada as 19:00h de sexta-feira.

Atividades:

• Executar Backup FULL às 17:00 (duração de 1h e 30 min)
• Parar os Sistemas
• Desabilitar os Jobs do SQL Server
• Rodar um último backup do log (Agora tenho o backup da madrugada passada + todos os bkps do log do dia – Cópia 1)
• Executar um backup Diferencial  (Agora tenho o backup FULL e Diferencial que acabei de executar – Cópia 2)
• Retirar as bases do Mirror (Agora tenho as bases sincronizadas no servidor de Mirror – Cópia 3)
• Alterar o nível de compatibilidade das bases para 100 (SQL 2008). Já que o menor nível no SQL Server 2016 é 100, já estou fazendo logo antes de dar um attach nas bases.
• Realizar um Detach das bases (Agora tenho as bases no disco de Storage e que serão mantidos e utilizados para fazer o Attach quando reinstalar o servidor – Cópia 4)

Isso que é DBA medroso – Cópia 1, 2, 3 e 4!!!! #DBA #DBAMedroso #Soumesmo

• Formatar o servidor
  • Essa parte é a mais demorada, até formatar e instalar todos os milhares de updates do windows, configurar Storage e etc…
• Instalar o SQL Server 2016, o Service Pack 1 e o CU mais recente que nesse caso era o 2.
• Configurar o SQL Server nas melhores práticas e de acordo com tudo o que foi documentado da instalação anterior
• Realizar um Attach das bases
• Criar os usuários com os scripts que geramos
• Criar os Jobs, LS e Operators
  • Se tentar criar os usuários e jobs antes das bases, vai ter problema, pois não terá a database default dos logins e não terá as databases dos steps dos jobs.
• Subir os sistemas
• Testar os sistemas
• Realizar um novo backup FULL no SQL Server 2016
• Executar um CheckDB após a migração
• Atualizar as estatísticas após a migração

Aqui que identifiquei um grande problema.

Regra mágica dos Arquivos do Tempdb

Vocês já estão cansados de ver por aí que TEMOS que criar vários arquivos para o tempdb de acordo com o número de cores que temos, mas com uma limitação de 8 arquivos inicialmente. O próprio SQL Server 2016 no momento da instalação já faz esse trabalho para nós agora.

Se você separar isso em discos diferentes, show de bola. Você é rico e tem vários discos diferentes para o tempdb. Mas na prática isso é difícil de acontecer.

Mesmo sem separar em discos diferentes, essa criação de vários arquivos para o TEMPDB é indicada com o intuito de reduzir contenções nas páginas GAM, SGAM e PFS.

Mas e ai, essa receita de bolo SEMPRE funciona?

Só dar next->next->finish no instalador do 2016 que ele já vai criar esse monte de arquivo para mim e isso sempre é bom?

Veja bem…

No meu caso, a versão antiga do sql server tinha 1 arquivo do tempdb. Como o servidor tinha 16 cores, o SQL Server 2016 sugeriu 8 arquivos para o tempdb durante a instalação. Para não fazer uma mudança tão drástica do que tinha antes para o novo SQL Server, eu criei apenas 4 arquivos para o tempdb (#DBAMedroso).

O pessoal fez os testes dos sistemas tranquilo até que eu comecei a atualizar as estatísticas das bases.

Ao colocar um UPDATE STATISTICS WITH FULL_SCAN o SQL Server engargalou o disco onde estava o TEMPDB.

Olha um dos retornos da DMV dm_io_pending_io_requests:

 

Olha as mensagens no Error Log:

“SQL Server has encountered 253 occurrence of I/O requests taking longer than 15 seconds to complete on file T:\….”

Minha conclusão foi que com o aumento de arquivos do tempdb, o sql passou a requisitar muito mais I/O para o Storage e ele não aguentou a pressão. Isso porque deixei só quatro arquivos, imagina se tivesse deixado o default da instalação de 8 arquivos? A receita de bolo para arquivos do tempdb poderia me gerar problemas na migração.

Tive que fazer o rollback e deixar apenas 1 arquivo para o tempdb. Feito isso o update statistics parou de gerar todo esse gargalo no disco.

Imagina se na segunda-feira com a produção bombando, o disco do tempdb resouvesse agarrar dessa forma?

Agora, quando eu tiver mais IOPS do Storage, poderei aumentar os arquivos do tempdb para evitar os gargalos da GAM, SGAM e PFS.

Nível de Compatibilidade x Query Store

• A última atividade que ficou pendente da migração é subir o nível de compatibilidade das bases para o 2016.

Mas antes de fazer isso, habilitei o Query Store para coletar informações sobre os planos de execução e após alterar o nível de compatibilidade, conferir se tivemos alguma regressão de planos.

Quando migramos o SQL Server de versão, a ideia é que as queries rodem mais rápidas com as melhorias implementadas na Engine, contudo, algumas queries mais específicas podem ficar mais lentas e temos que identificar esses casos para tratar.

Dito e feito!

Após mudar o nível de compatibilidade, algumas queries passaram a rodar mais lentas. Veja o que nosso novo best friend Query Store me mostrou:

Query 1:

Query 2:

Conseguem ver que após o dia 16, foi gerado um novo plano para essas duas queries com um tempo de duração muito maior?

Identifiquei isso em algumas queries que mereciam atenção.

Duas delas faziam join no WHERE:

SELECT …
FROM SE5010 SE5 , SA1010 SA1 , SE1010 SE1
WHERE …

Criei alguns índices para essas queries, o SQL passou a usar um novo plano com meus índices e elas passaram a rodar rápidas novamente.

Thanks Query Store por tornar minha vida mais fácil em uma migração.

Compactação de dados

Já comentei isso em outros posts nesse blog:

• https://www.fabriciolima.net/blog/2013/12/14/5-motivos-para-quem-utiliza-o-protheus-totvs-contratar-um-dba-sql-server/
• https://www.fabriciolima.net/blog/2016/11/21/tem-sql-server-standard-na-sua-empresa-hora-de-planejar-a-migracao-para-o-sql-server-2016/

Compactação de dados para bases Totvs Protheus é sensacional!!! Só com esse argumento estou conseguindo convencer alguns clientes a migrar para o 2016 Standard SP1 que liberou a compactação.

Olha o resultado nesse cliente:

Base de 252 GB reduziu para 72 GB

Base de 528 GB reduziu para 152 GB

Juntando todas as bases tivemos uma redução de 955 GB para 280 GB. 70% de ganho. Amazing!!!

Como nesse cliente CPU não era um problema, utilizei compressão de página para todos os índices. Em um ambiente que já tem um consumo alto de CPU, minha dica é ir compactando aos poucos e ir monitorando o consumo de CPU.

Mas e a CPU Fabrício, como ficou?

Nesse cliente, o consumo de CPU era muito baixo (menos de 10% de média). Identifiquei um aumento de 1% apenas.

E a utilização de memória, como ficou?

Veja com os próprios olhos a diferença do contador Page Life Expectance:

Ele tinha uma média diária de 4 mil e chegou até 51mil de média no dia 11/05.

Isso acontece porque as páginas agora vão compactadas para a memória e conseguimos manter mais páginas em memória. A migração/compactação fez um efeito semelhante a você ter comprado mais memória para o server.

Resumindo:

Disco: Reduziu demais o consumo (Economia de Storage)

Memória: Está muito melhor aproveitada (Economizamos um upgrade de memória)

CPU: Aumento insignificante no consumo para esse cliente. (Lembrando que cada caso é um caso)

Com essa melhor utilização do disco e memória, acaba que também ganhamos uma melhoria de performance para o ambiente. Exceto casos onde a CPU é um gargalo (Lembrando que cada caso é um caso).

Ufa… Post ficou um pouco grande, mas ficou legal…

É isso aí pessoal. Espero que tenha te ajudado caso esteja planejando uma migração para o SQL Server 2016.

Se você tem um ambiente Protheus Totvs, migre para ontem. Em alguns casos o custo de armazenamento pode amenizar bem o investimento nas licenças.

Esse cliente vai ficar um bom tempo sem ter que aumentar o Storage para o SQL (ele já estava perto de ter que fazer isso).

Até o próximo Casos do Dia a Dia do Fabricio Lima.

 

Atualizado no dia 07/10/2020:

Publiquei um curso com 11 horas de duração com toda minha experiência de anos no assunto e de dezenas de clientes Protheus atendidos:

Curso: Melhorando a Performance de Consultas no Totvs Protheus

Gravei uma aula grátis com 60 minutos de duração sobre o que você deve aprender para melhorar a performance no Protheus:

Gostou desse Post?

Curta, comente, compartilhe com os coleguinhas…

Assine meu canal no Youtube e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.

Até a próxima.

Abraços,

Fabrício Lima

Microsoft Data Platform MVP

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006