Parem de migrar o Oracle Database para 12c

Pena que eu tive que demorar para escrever este Post, pois ele deve chegar tarde para muita gente.

Nas últimas semanas, recebi muito mais e-mails do tipo “socorro, fizemos upgrade e travou tudo” do que o usual.

Certamente esta onda de Upgrades se deve ao “Fim do Suporte para o 11g”.
Mais detalhes neste Post: Parem de falar que o 11gR2 não tem mais suporte.

Bem, façam Upgrade sim, mas para 19c, e último RU que encontrarem.

“Mas Portilho, o 19c é muito novo!”

Veja na imagem abaixo, do Doc ID 742060.1 (ou seja, um documento oficial do My Oracle Support), que o 18c na verdade é o 12.2.0.2. E o 19c é na verdade o 12.2.0.3.

Ou seja, o 19c é o 12cR2, mas corrigido.

Você deveria ter a mesma coragem de colocar em Produção o 12cR2 que você teria para colocar o 9.2.0.1, 10.2.0.1, ou 11.2.0.1.

“Mas Portilho, o 19c tem New Features!”

Todo PatchSet tem, desde o 11gR2. E compare a quantidade (e “tamanho”) de New Features do 12cR2 e do 18c / 19c:

New Features 12cR2

New Features 18c

New Features 19c

Outra coisa importante desta imagem, é que o 12cR1 já está em Extended Support desde 01/08/2019. Ou seja, sair do 11gR2 para o 12cR1 não vai mudar seu estado de Suporte. Se você migrou para o 12cR1 porque ia acabar o suporte do 11gR2, foi trabalho a toa. E para uma versão pior.

“Mas Portilho, migrei para 18c / 19c, e travou tudo também!”

Primeiramente, a situação “fizemos upgrade e travou tudo” em Oracle Database sempre foi muito, muito, muito comum. Dependendo da quantidade de cabelos brancos, os DBAs já viram isso acontecer de 9i para 10g, de 10g para 11g, e estão vendo agora.

O Oracle Database é o Sistema Gerenciador de Bancos de Dados Relacionais (dos que conheço) que historicamente tem maior impacto em alteração de Planos de Execução. Em tempo, este impacto é plenamente sanado pela Feature SPM (SQL Plan Management, mais conhecido simplesmente como Baselines), que foi lançado no 11g, mas ainda é pouco conhecido e portanto, pouco utilizado. E para piorar, é uma Feature exclusiva da Enterprise Edition (na 19c pode ser utilizado em SE2, obrigado pela informação Alex Zaballa).

Ou seja, o upgrade altera muito o comportamento do Oracle em tudo, especialmente planos de execução.
“Ué, entendo que altere, mas upgrade não era para melhorar?” Sim, mas imagine que de todos os (milhares de) SQLs executados no banco, a maioria fica igual, vários melhoram, e uns pioram. Em qual desses três tipos vão reparar? Qual destes três tipos tem o potencial de fazer você perceber que algo não está bem?

Fora isso, temos um componente psicológico / social / financeiro: geralmente upgrade vem com novo hardware, afinal, a maioria dos servidores por aí tem uns 5 anos de garantia, e este tempo batia mais ou menos com os Major Releases do Oracle Database. Então temos também na conta a expectativa e frustração do cliente. Ele deve ter comprado servidores novos, Storage novo, ele acha que RAC é mais rápido que Single (e não é), a versão do Oracle está “lustrando de nova” (como um carro novo, TEM que ser melhor em tudo), e por aí vai. Eu imagino que a cada reunião a respeito de problemas em sistemas, é proferido algo como “ah, mas logo estaremos no novo ambiente, e isso vai se resolver” ou pior, “ah, mas o novo ambiente vai aguentar este novo projeto, só aguardem”.

O correto a fazer, então, é testar bem no novo ambiente ANTES do Upgrade pra valer. Mas acho que a maioria dos testes é para ver “se abre as telas” e “se alguns relatórios funcionam”, e não levam em consideração desempenho em concorrência, e portanto escalabilidade.

As escolhas então são:
Número 1 – Não fazer upgrade.
Número 2 – Fazer upgrade e encontrar os problemas em Homologação, e corrigi-los antes de ir para Produção.
Número 3 – Fazer upgrade e encontrar os problemas em Produção.

Mas se sua escolha (sei que não foi sua escolha) foi o Número 3, então a primeira coisa a fazer é desapegar – se era bom na versão anterior, se era bom sem RAC, se era bom sem ASM, etc, tudo isto é o menos importante.

O importante é descobrir qual é o problema.

Mas mesmo sem olhar nada, se você fez Upgrade para 12c R1 ou R2, algumas coisas que me vem a mente:

  • Vejo que todo mundo está migrando para 12cR2, considerando que é uma versão estável (afinal, é R2), mas a 12.2.0.1 é uma péssima versão. Afinal, é uma versão de livre Download, é o primeiro PatchSet deste Release, ou seja, sem Patch nenhum. É praticamente um Beta. Mas agora já foi, não dá para falar para o cliente ir para 18c / 19c. Mas no mínimo, tem que aplicar Release Update.
  • Desde o 10.2.0.1, eu utilizei todos os PatchSets em situações simuladas, mas extremas – meus treinamentos. O 12.2.0.1 se comparou em estabilidade a 10.2.0.3, 11.2.0.1, 11.2.0.2… É ORA-600 brotando para todo lado. Já o 18c e 19c, um doce de estabilidade.
  • Se te der um desespero, altera o parâmetro OPTIMIZER_FEATURES_ENABLE para 11.2.0.4. Isto vai fazer com que muitos planos de execução voltem ao comportamento que tinha antes. Se possível, faça em ALTER SESSION, não em ALTER SYSTEM.
  • Existe alguma rotina manual ou agendada de coleta de estatísticas (além da automática)? Se existe, não use ESTIMATE_PERCENT. Tem uma explicação do porque neste Post: Coletar Estatísticas com ESTIMATE PERCENT 100% é pior
  • Teste os parâmetros OPTIMIZER_ADAPTIVE_FEATURES (12cR1) e OPTIMIZER_ADAPTIVE_STATISTICS (12cR2) e OPTIMIZER_ADAPTIVE_PLANS (12cR2) em FALSE. São Features novas do 12c que me deram muita dor de cabeça.
  • O MGMTDB foi uma ideia tão ruim que passou a ser opcional no 19c. É um peso morto no RAC que só atrapalha.
  • Sei que muitas vezes dependemos do fornecedor de Software. Mas no mínimo, expliquem o problema para gerentes, diretores, fornecedores. Temos que fazer nossa parte. No mínimo, isto irá lhe ajudar para acelerar o próximo Upgrade.
  • Eu tenho ambientes de Produção em 11gR2, 12cR1, 12cR2, 18c e 19c. Os ambientes 18c e 19c me acordam bem menos do que os outros.

14 comments

  1. Proni, algumas observacoes, com base no nosso ambiente em 12c R2 no Exadata X7-2.
    – Nós fizemos mais de 100 upgrades para 12.2.0.1 com último PSU e até agora não tivemos problemas referente a performance. Apenas desvios pontuais
    – 18c e 19c: De fato, por “trás dos panos”, as versões 18c e 19c seriam os antigos “PatchSets” da versão 12c. Porém, como já é sabido, o marketing share de produtos da Oracle é muito ruim, e ela não explicou de forma encisiva/ampla essa mudança de versionamento de Oracle, para os desenvolvedores de sistemas, DevOps e etc., com isso, esta quase ficando impossível efetuar upgrades de banco de dados, pois eles alegam que a versão da aplicação deles não é homologada nessa versão do Oracle. Logo, estaremos no Oracle 25c, e ambientes com 12c….
    – Neste novo modelo de versionamneto, as mudanças de optimizer continuam na versão, portanto, novas features de optimizer mudarão conforme você avançar a versão;
    Tem mais coisas sobre isso, mas não vou me estender mais do que ja fiz, neste post.

    Abraços

    1. Oi Hugo!

      – Nós fizemos mais de 100 upgrades para 12.2.0.1 com último PSU e até agora não tivemos problemas referente a performance. Apenas desvios pontuais
      Sim, pois imagino que vocês fizeram um bom e cuidadoso trabalho, e em Exadata X7-2. Mas a maioria não trata um upgrade com tanto cuidado, e em hardware que já era sofrível.

      – 18c e 19c: De fato, por “trás dos panos”, as versões 18c e 19c seriam os antigos “PatchSets” da versão 12c. Porém, como já é sabido, o marketing share de produtos da Oracle é muito ruim, e ela não explicou de forma encisiva/ampla essa mudança de versionamento de Oracle, para os desenvolvedores de sistemas, DevOps e etc., com isso, esta quase ficando impossível efetuar upgrades de banco de dados, pois eles alegam que a versão da aplicação deles não é homologada nessa versão do Oracle. Logo, estaremos no Oracle 25c, e ambientes com 12c….
      Concordo, o maior problema que vejo é a resistência (por desconhecimento) dor Fornecedores. Vai demorar até passarem pelo 12. Este é um dos motivos do Post, que os Fornecedores de Software o leiam.

      – Neste novo modelo de versionamneto, as mudanças de optimizer continuam na versão, portanto, novas features de optimizer mudarão conforme você avançar a versão;
      Mas terá menos. Se a 12cR2 tem 1000 New Features, e a 18c tem 100, é 10% das mudanças, 10% dos possíveis problemas.

  2. Excelente post Portilho! Obrigada por compartilhar!! Não aguento mais o 12cR1, é ORA600 pra todo lado! Não vejo a hora de migrarmos para o 19c também.

    1. Hérica, 12c R1 é o 12.1 (houve um 12.1.0.1, que praticamente ninguém instalou) e o 12.1.0.2 (que saiu logo depois e é o last release/LTS da família 12.1.

      O Portilho crítica (e com propriedade) o upgrade para 12.2.0.1, pois este é um base release.

      Não importa o doc “single source of truth” (nas palavras de Mike Dietricht) mais que demonstrando que o 18c é o 12.2.0.2 e que o 19c é o 12.2.0.3. E que este 19c é o last release/LTS da família 12.2.

      Quem manda nos upgrades das empresas é sempre c****. E para este o 18c é “do ano passado” e por isso é muito novo. E o 19c então nem fale pra ele.

      E fala isso com seu BMW 19 enquanto você segue no seu fretado…

    2. Hérica, 12c R1 é o 12.1 (houve um 12.1.0.1, que praticamente ninguém instalou) e o 12.1.0.2 (que saiu logo depois e é o last release/LTS da família 12.1.

      O Portilho crítica (e com propriedade) o upgrade para 12.2.0.1, pois este é um base release.

      Não importa o doc “single source of truth” (nas palavras de Mike Dietricht) mais que demonstrando que o 18c é o 12.2.0.2 e que o 19c é o 12.2.0.3. E que este 19c é o last release/LTS da família 12.2.

      Quem manda nos upgrades das empresas é sempre c****. E para este o 18c é “do ano passado” e por isso é muito novo. E o 19c então nem fale pra ele.

      E fala isso com seu BMW 19 enquanto você segue no seu fretado…

  3. Portilho,

    o problema (aqui, pelo menos) é conseguir convencer as softwarehouses a sair do 12cR1 pro 19c… quero ver quem vai pagar a conta do EE daqui!!!

    1. Não é só aí amigo!
      E olha que Software House boa é que está falando de “12c”..
      Grande abraço!

  4. Ótimo post Ricado!

    Mas o ideal era o deixar claro no titulo: “Parem de migrar para o 12c e já migrem para 19c.

    Recebi 2 vezes este link por Whatsapp de gente assustada falando “não era pra migrar pra Oracle”. Acredita?

    E isso tem muito a ver com seu ultimo post do “DBA Whatsapp”, pega o titulo da noticia, não leem o conteudo e já sem “implementando” rsrsrs

    Abs!

    1. Caramba, acredito sim!
      Mas acho que não vou resolver o problema cognitivo desse pessoa tão facilmente… 😀

  5. Portilho, excelente post.

    Eu tenho 12.1.0.1.0 em produção. Trabalho em uma estatal e com a crise não aprovaram a compra de versão EE… Então fizemos upgrade (usando nosso direito por pagar support &Upgrade) para o que dava e pra aproveitar o máximo do Hardware (RAC com 2 nós e 2 sockets cada nó). Gastamos pouco e a performance melhorou certa de 70% (saímos do 10g). Minha pergunta é: Qual seria a versão/release (18c ou 19c) que eu conseguiria fazer upgrade dessas licenças 12.1.0.1.0??
    abraço!!

    1. Obrigado pelo comentário Glaucio.
      A SE2 (que começou no 12.1.0.2) só permite 2 Sockets, mesmo em um Clsuter todo, ou seja., 1 Socket por Node. Ou seja, não é suportado para você.
      Adicionalmente, a SE2 em 19c não permite RAC. Ou seja, não é suportado para você.
      Se não pode sair do RAC nem ir para EE, aplica o último PSU, e é o que dá para fazer. E aproveita pois a 12.1 já está em Extended Support.

  6. Olá, Portilho.
    Excelente post.

    Você saberia dizer o que aconteceria com a compatibilidade de conexão para clients mais antigos, como algumas aplicações que até hoje usam libraries do 8i ou superior?

    Se migrar para o 19c, não teríamos problemas de erros ORA-28040 em clients 10g, por exemplo?

    Tenho dificuldade em testar isso, porque o ambiente de homologação é um RAC, e upgrade do Grid Infrastructure, e com ele o Listener, é o primeiro passo.

    Obrigado.

    1. Oi Ricardo. Obrigado pelo comentário.
      Obviamente o correto seria o Upgrade dos Clients, mas imagino que você deve ter algum impedimento na aplicação para fazer isso.
      Eu tive este problema, e tive que adicionar SQLNET.ALLOWED_LOGON_VERSION_SERVER=8 no sqlnet.ora do Servidor.
      Atenção pois em RAC este parâmetro deve estar no “RDBMS_HOME/network/admin directory and NOT GRID”, de acordo com o Doc ID 562589.1.

Leave a Reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.