Cerca de um ano e meio atrás, me mudei para uma nova empresa e comecei a trabalhar como DBA. A empresa não aplicou anteriormente nenhum patch em nenhum banco de dados Oracle. Desde que cheguei aqui, tenho visto a segurança do sistema de TI se tornar mais um ponto de foco e passar por um nível mais alto de escrutínio do que antes. Em vez de esperar por uma diretiva para começar a implementar patches de segurança regulares para nossos bancos de dados Oracle, decidi ser proativo. Chegará o dia em que seremos obrigados a começar a corrigir nossos bancos de dados Oracle regularmente e gostaria de dizer que já o implementamos.

A CPU de abril de 2012 foi lançada na semana passada e esta é a primeira CPU que aplicaremos aos nossos bancos de dados Oracle. Antes de aplicar a primeira CPU, pensei um pouco em como implementar essa mudança em nosso ambiente corporativo. Decidi compartilhar algumas dessas mudanças caso alguém mais chegue a uma situação semelhante no futuro.

1. Os 3 D's:Antes do início de qualquer correção, uma política de correção foi documentada, disseminada para a equipe e gerenciamento de TI e discutida. Este documento discutiu em alto nível a necessidade de patches de segurança regulares, quando os patches de segurança seriam lançados e como eles seriam aplicados aos nossos sistemas para reduzir o risco ao banco de dados, ao aplicativo e aos usuários finais.
2. Linha do tempo do patch – tenho o luxo de ter um clone do nosso banco de dados de produção apenas para uso do DBA e de mais ninguém. Minha linha do tempo começa aí. Dentro de uma semana do lançamento da CPU, devo aplicar a CPU ao meu banco de dados DBA e resolver quaisquer problemas. Com duas semanas do lançamento da CPU, devo aplicar o patch em nossos bancos de dados de desenvolvimento. Dentro de um mês do lançamento da CPU, devo aplicar o patch ao banco de dados Test and Stage. E, finalmente, dentro de 6 semanas do lançamento da CPU, devo aplicar o patch à produção. Esta é apenas a minha linha do tempo e o que funciona em nosso ambiente. Sua linha do tempo pode ser diferente. Mas é importante que todos entendam a linha do tempo e que a linha do tempo faça duas coisas aparentemente contraditórias – 1) aplique o patch lentamente para que qualquer problema de banco de dados ou aplicativo seja resolvido antes de prosseguir para a próxima etapa na linha do tempo. Quando o patch chegar à produção, não deve haver surpresas e confiança de que o patch não quebrará nada. 2) aplica o patch com rapidez suficiente para que as falhas de segurança sejam corrigidas em um tempo razoável. No meu ambiente, seis semanas para a produção é lento o suficiente para detectar problemas, mas tão rápido quanto nos sentimos confortáveis ​​em ir. Seu ambiente pode ter outras linhas do tempo.
3. Log It – Eu sinto fortemente que os patches devem ser documentados em algum tipo de log de alterações. Com o log, você poderá voltar e ver exatamente quando cada patch foi aplicado a cada banco de dados. Isso pode ajudar bastante no diagnóstico se um patch foi responsável por um problema. Se eu receber um tíquete de que um procedimento recebe erros e o problema foi observado pela primeira vez em 1º de maio, posso ver o log de alterações. Se eu apliquei o patch em 30 de abril, o patch pode ter introduzido o problema. Mas se eu apliquei o patch em 2 de maio e o problema existia um dia antes, o patch não é a causa do problema. Algumas organizações já possuem um mecanismo de Controle de Mudanças e o log de patches do Oracle deve se encaixar nessa estrutura.
4. Teste/Teste/Teste – Como DBA, temos o dever de garantir que as alterações introduzidas na produção tenham um alto grau de confiança de que o aplicativo não será interrompido. É de vital importância testar suas alterações e os patches não são diferentes. Se você não passar pela linha do tempo do patch, não terá tempo suficiente para testar e, se houver um problema que o patch tenha introduzido em seu ambiente, seria suicídio profissional se você não testasse adequadamente antes de iniciar a produção.
/>5. Backups – Deve-se fazer backup do banco de dados e do diretório inicial do Oracle que está sendo corrigido antes de aplicar o patch. Você nunca sabe se terá que voltar a um ponto anterior ao patch em uma ou ambas as áreas. Deve-se ocasionalmente testar a metodologia de restauração ou fazer backup de patches bem antes da produção. Este teste pode não necessariamente precisar ser feito uma vez por trimestre, mas deve ser pelo menos uma vez por ano.

Acho que aqueles sobre cobrem os principais pensamentos que tive sobre o assunto. Se você tiver perguntas/comentários, me avise.