Eu estava participando de um tópico recente na comunidade OTN onde alguém estava fazendo perguntas sobre o downgrade após uma atualização do banco de dados. Uma das respostas perguntou quantas pessoas realmente praticam downgrades de banco de dados. Criei essa enquete para saber.
Fiquei surpreso ao encontrar uma contribuição para esse tópico que dizia:
Agora, aquele pôster não disse isso explicitamente, mas era quase como se aquele indivíduo estivesse dizendo que praticar downgrades era uma perda de tempo porque eles nunca precisariam disso. Vou dar ao pôster o benefício da dúvida e que esse funcionário da Oracle não estava realmente dizendo isso. Eu não estou tentando pegar esse indivíduo. Vou deixar este tópico me fornecer a oportunidade de discutir o tópico de um ponto de vista mais genérico. (Atualização: o postador que me levou a escrever esta entrada de blog voltou ao tópico no tempo que levei para escrever isso e disse:” não significava que não deveríamos ‘testar’ downgrades.” )
Em julho, escrevi um post no blog sobre o The Data Guardian. Nesse post do blog, eu disse:
O DBA precisa proteger os dados. Esse é o trabalho nº 1. O trabalho nº 2 é para o DBA fornecer acesso eficiente e oportuno aos dados. De que adianta ter os dados se as pessoas que precisam acessá-los não conseguem acessar os dados? Se essas pessoas têm um desempenho terrível ao interagir com os dados, elas podem não ter acesso.
Como o DBA, precisamos realizar o gerenciamento de risco. Precisamos determinar quais riscos podem se tornar realidade. O trabalho dos DBAs é medir esses riscos e determinar dois planos de ação. Que medidas podem ser tomadas para evitar que esse risco se torne realidade e que medidas devo tomar para resolver o problema quando esse risco se tornar realidade?
Mesmo um DBA de nível júnior entenderá a importância dos backups. Os backups são uma estratégia de gerenciamento de risco. Se os dados forem perdidos, podemos recuperar os dados do backup. E mesmo um DBA de nível júnior entende a importância de poder restaurar a partir do backup.
Neste tópico da OTN, escrevi isso:
Para mim, isso é uma espécie de lei de Murphy. Já disse coisas parecidas no passado. A ideia (e é o ponto principal desta entrada no blog) é que, se eu não tomar as medidas apropriadas de gerenciamento de risco, estou apenas pedindo aos deuses que transformem esse risco em realidade. Se eu me recusar a ajustar meu espelho retrovisor e usá-lo quando estou dando ré no meu veículo, bem, esse é o dia em que volto em algo. Se eu me recuso a amarrar meus cadarços, bem, esse é o dia em que piso em um e tropeço. O dia em que me recuso a usar googles de proteção ao usar uma ferramenta elétrica é o dia em que tenho algo no olho. O dia em que eu for à praia e me recusar a colocar protetor solar é o dia em que voltarei para casa com uma queimadura de sol. Você entendeu a ideia.
Alguns leitores podem estar pensando que eu sou louco e que o universo não tem esse plano mestre para me ferrar só porque estou sendo complacente. E eu concordaria. Então eu vou dizer de outra forma, se eu não planejo mitigar o risco, então não fiz nada para impedir que isso se torne uma realidade. As chances de se tornar realidade não diminuem por causa da minha inação.
Existem dois componentes principais no gerenciamento de riscos. 1) determinar a probabilidade desse item de risco ocorrer e 2) determinar o impacto quando esse risco ocorrer. Os itens que têm a maior probabilidade de ocorrência são mitigados primeiro. Isso é fácil e algo que muitos que trabalham em gerenciamento de risco costumam fazer. Eles colocam os itens de risco em uma planilha e preenchem algum valor para a probabilidade desse risco ocorrer. Quando concluídos, eles classificam na coluna de probabilidade e iniciam a mitigação de risco de cima para baixo. Muitas estratégias de gerenciamento de risco traçam uma linha em algum lugar no meio da lista e decidem que qualquer item de risco abaixo dessa linha tem probabilidade muito baixa de não nos preocuparmos com esse item de risco. Não podemos mitigar todos os riscos possíveis no universo. Simplesmente não há tempo suficiente para lidar com tudo isso. Então temos que traçar a linha em algum lugar.
Uma das falhas que vejo o tempo todo é que o gerenciamento de risco não gasta muito tempo focando no impacto desse risco se tornar realidade. A planilha precisa incluir uma coluna semelhante que forneça uma classificação do impacto para o negócio desse item de risco. O gerente de risco também precisa classificar a planilha nesta coluna. Qualquer item que tenha um grande impacto precisa ter atividades de mitigação de risco, mesmo que esse item tenha uma baixa probabilidade de ocorrer! Infelizmente, muitos no negócio de gerenciamento de risco não incluem esta etapa de avaliação do impacto do risco. Novamente, quando a planilha é classificada por impacto no negócio, uma linha é traçada em algum lugar.
Pode-se descobrir que itens de risco com uma probabilidade ALTA ter um impacto BAIXO ou mesmo MUITO BAIXO ao negócio. Gosto de planilhas de gerenciamento de risco que incluem uma terceira coluna que é "probabilidade x impacto". Esta coluna ajuda a entender a relação entre os dois componentes de risco.
Vamos voltar para a pergunta de atualização do banco de dados que motivou esta postagem no blog. Acho que todos que estão lendo este artigo do blog devem concordar que atualizar um banco de dados Oracle é uma proposta arriscada. Há tantas coisas diferentes que podem dar errado com uma atualização de banco de dados Oracle. A probabilidade de uma falha de atualização é HIGH. Os itens de mitigação de risco geralmente incluem, mas não se limitam a, praticar a atualização em clones de produção e fazer backup do banco de dados antes do início do processo de atualização. porque nós fazemos isso? Bem, o impacto para o negócio é MUITO ALTO. Se falharmos ao atualizar nosso banco de dados de produção, nossos usuários de negócios não terão acesso aos dados. Não somos um Guardião de Dados muito bom se não conseguirmos superar essa falha. Se praticarmos a atualização suficientemente em ambientes de não produção, podemos reduzir a probabilidade do item de risco para MÉDIO. Mas com toda a probabilidade, não podemos reduzir essa probabilidade de risco específico para BAIXO. É por isso que fazemos o backup antes do início da atualização. Ainda deve ter problemas, mesmo que tenhamos feito nosso melhor nível para reduzir a probabilidade desse item de risco, o impacto para o negócio ainda é MUITO ALTO. Portanto, a estratégia de correção de riscos do DBA é fazer anotações sobre onde e o que causou a falha do upgrade e restaurar a partir do backup. O banco de dados está funcionando e eliminamos o impacto ao negócio. O DBA então volta à prancheta para determinar como resolver o que deu errado. O DBA está tentando reduzir a probabilidade desse problema ocorrer novamente quando eles voltarem mais tarde para fazer o processo de upgrade novamente.
Então, vamos voltar ao comentário no tópico da OTN, onde parecia estar dizendo que praticar downgrades de banco de dados não vale a pena. Discordo. E minha discordância tem tudo a ver com o impacto ao negócio. Eu concordo com o comentário que o autor disse em sua resposta.
Concordo com isso 100%. Por que fazemos esse “teste completo”? É tudo por causa da mitigação de risco. Estamos tentando reduzir a probabilidade que a atualização causará baixo desempenho ou fará com que a funcionalidade do aplicativo seja interrompida. Mas mesmo como o pôster disse:“Sempre haverá problemas que aparecerão na produção após a atualização porque é impossível testar 100% do seu aplicativo”. Mais uma vez, concordo 100% com o que este pôster está dizendo aqui. Mas e o impacto ao negócio? Eu chegarei a isso em um minuto, mas primeiro eu tenho que divagar um pouco neste próximo parágrafo…
Recentemente, atualizei um sistema de produção crítico da versão 11.2.0.4 para a versão 12.1.0.2. Onde eu trabalho, temos mais testes de aplicativos do que eu já vi em meus outros trabalhos. Temos uma equipe completa de controle de qualidade que faz testes para nós. Temos até uma equipe responsável por nossos esforços de testes automatizados. Temos robôs automatizados que exercitam nosso código de aplicativo todas as noites. Além de tudo isso, temos outra rotina automatizada que sempre que as pessoas enviam alterações de código para Test ou Prod, essa rotina faz um exame rápido dos caminhos críticos do código. Atualizei os ambientes de desenvolvimento (mais de 15 deles) para 12.1.0.2 e esperei um mês. Em seguida, atualizei o Test e esperei 3 semanas antes de atualizar a produção. Foram encontrados e resolvidos problemas antes de atualizarmos a produção. Mas mesmo depois de tudo isso, tive grandes problemas quando a produção foi atualizada. Você pode visitar minhas postagens no blog em meados de outubro a meados de dezembro para ver alguns desses problemas. Eu estava muito perto de fazer o downgrade desse banco de dados, mas consegui resolver os problemas. Agora voltando ao ponto que eu estava fazendo...
Após a conclusão da atualização, o banco de dados é aberto para negócios. Os usuários do aplicativo agora têm permissão para usar o aplicativo. O que acontece dentro do banco de dados neste momento? Transações! E transações significam mudanças de dados. No momento em que o DBA abre o banco de dados para negócios após a conclusão de uma atualização, as alterações de dados começam a ocorrer. Depois de tudo isso, esse é o objetivo do banco de dados, não é? Capture alterações de dados e disponibilize os dados para os usuários finais do aplicativo.
Então, o que acontece se você estiver no barco que eu estava no outono passado com a atualização do meu banco de dados? Eu estava acertando coisas que não vimos na não produção, mesmo depois de todos os nossos testes. O impacto para o negócio foi ALTO. Eu preciso ser capaz de reduzir esse impacto para o negócio. Eu tinha três opções. 1) Corrija os problemas, um por um. 2) Restaurar a partir do backup que fiz antes da atualização para que eu pudesse voltar o banco de dados para a versão antiga. 3) Faça o downgrade do banco de dados e volte para a prancheta. Eu escolhi a primeira opção. como sempre fiz durante a minha carreira. Mas e se isso não fosse suficiente? Pode levar tempo para resolver os problemas. Algumas empresas simplesmente não podem permitir esse tipo de tempo com esse impacto negativo ao negócio. Quantos sites foram abandonados porque o desempenho foi terrível ou as coisas não funcionaram corretamente? E para a grande maioria dos bancos de dados de produção existentes, a opção 2 tem um impacto muito terrível ao negócio! Você perderá transações após a conclusão da atualização! O DBA não poderá avançar após a atualização mantendo o banco de dados na versão antiga, portanto, os dados serão perdidos e, para muitos bancos de dados de produção, isso é inaceitável. A empresa pode arcar com uma hora de perda de dados, mas quantas pessoas acionariam essa ação dentro de uma hora após a atualização? Muito provavelmente, essa ação seria executada dias após a atualização e o impacto para o negócio para esse tipo de perda de dados está bem acima de MUITO ALTO. Isso deixa a opção 3 como a opção com menor impacto para a empresa para ajudar a resolver quaisquer impactos que a empresa esteja enfrentando após a atualização.
Você provavelmente pode dizer a partir desse último parágrafo que eu sinto que é importante para o Oracle DBA saber como fazer o downgrade de seu banco de dados após a conclusão de uma atualização. Admito que a probabilidade do DBA que precisa fazer um downgrade é MUITO BAIXO. Mas o impacto de não rebaixar pode ser catastrófico para o negócio. (Há essas duas palavras novamente). Porque a probabilidade é baixo, não pratico downgrades com frequência, mas porque o impacto de não poder fazer downgrade é muito alto, eu pratico de vez em quando.
Então, para encerrar, vou voltar àquela coisa da Lei de Murphy novamente. O universo não está conspirando contra mim, mas como Guardião de Dados, preciso praticar bons princípios de gerenciamento de risco. Isso significa avaliar a probabilidade e o impacto dos itens de risco impostos pela minha mudança. Embora o universo e os deuses não possam fazer a Lei de Murphy ou seus primos entrarem em ação, não vou me favorecer mitigando itens de risco. Não estou reduzindo a probabilidade nem um pouco.
