Esta semana participei de um projeto de migração, junto com um colega, envolvendo a transferência de alguns bancos de dados de um Oracle Exadata X9 para um Exadata Cloud Service X11 na Oracle Cloud Infrastructure.
Durante o processo, configuramos o Oracle Data Guard para os databases, garantindo a sincronização completa entre os ambientes. No dia da migração, realizamos o switchover de forma controlada e bem-sucedida.
No início do projeto, identificamos que alguns databases já haviam sido previamente criados no ambiente de destino, porém estavam com status failed. Alinhamos então que esses bancos poderiam ser removidos posteriormente, após a migração, com o objetivo de evitar poluição na console e manter o ambiente organizado.
Pouco tempo após a migração, optamos por realizar a limpeza dos databases que estavam com status failed. Antes da exclusão, validamos cuidadosamente se os OCIDs dos databases com nomes semelhantes eram distintos. Essa verificação adicional foi adotada como medida de segurança, garantindo que não houvesse risco de remoção acidental de um banco de dados produtivo.
oci db database list --compartment-id ocid1.compartment.oc1..aaaaaaaalpkc2cocwollcdzffwfwfwfqfwdqwkkillolo --vm-cluster-id ocid1.cloudvmcluster.oc1.sa-vinhedo-1.de2mwdmwkdmwmd23232em2kdmwkdk22dd --query "data [].{Name:\"db-name\", UniqueName:\"db-unique-name\", OCID:id, State:\"lifecycle-state\", AgentID:\"agent-resource-id\", Role:\"database-role\"}" --output table
+---------+----------+----------------------------------------------------------------------------------------------+------+------------+------------+
| AgentID | Name | OCID | Role | State | UniqueName |
+---------+----------+----------------------------------------------------------------------------------------------+------+------------+------------+
| None | CDBPRD6 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qaq7k2m9p4v1s8t5n3j6r9l0x2w4z7b5v8c1m4n2q9p5r1 | None | AVAILABLE | cdbstb6 |
| None | CDBPRD1 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qax1z9c4v8b3n7m5k2l0p6o4i8u2y7t1r5e9w3q6s4a8d2 | None | AVAILABLE | cdbstb1 |
| None | CDBPRD4 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qa4f7g9h2j5k8l0n3m1p6o4i9u2y7t5r1e8w4q2s6a9d33 | None | AVAILABLE | cdbstb4 |
| None | CDBPRD4 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qa9v2c5b8n1m4k7l3j6h9g0f2d5s8a1p4o7i3u6y9t2r54 | None | FAILED | cdbstb4 |
| None | CDBPRD2 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qa1q8w4e2r7t5y3u9i6o0p4l1k7j5h3g9f2d4s6a8z0x25 | None | TERMINATED | cdbstb2 |
| None | CDBPRD02 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qa7m3n1b9v4c8x2z0l6k5j4h8g2f1d9s3a7p0o4i1u5y86 | None | AVAILABLE | CDBSTB02 |
| None | CDBPRD5 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qa5d8f2g4h6j0k1l3m9n7p5o1i4u2y6t8r0e3w7q9s1a57 | None | FAILED | cdbstb5 |
| None | CDBPRD5 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qa9n1m4k7j2h5g8f0d3s6a9p1o4i7u2y5t8r0e3w6q1s48 | None | AVAILABLE | cdbstb5 |
| None | CDBPRD3 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qa2w4e6r8t0y2u4i6o8p0l2k4j6h8g0f2d4s6a8z0x2c49 | None | FAILED | cdbstb3 |
| None | CDBPRD3 | ocid1.database.oc1.sa-vinhedo-1.an3ggljrxa5b46qa0z9x8c7v6b5n4m3l2k1j0h9g8f7d6s5a4p3o2i1u0y99 | None | AVAILABLE | cdbstb3 |
+---------+----------+----------------------------------------------------------------------------------------------+------+------------+------------+Após validarmos os OCIDs dos databases, abrimos um chamado junto à Oracle para confirmar que a exclusão poderia ser realizada com segurança. Após algum tempo, a equipe solicitou uma call com o time da Oracle Cloud Infrastructure para conduzir a remoção em conjunto dos databases com falha.
Durante a reunião, foi confirmado que poderíamos prosseguir com segurança. Realizamos a exclusão do primeiro database com status failed sem qualquer problema. No entanto, ao executar a exclusão do segundo database, a console da OCI removeu não apenas o database com falha, mas também um database com status available.
Nesse momento, houve um silêncio imediato na reunião. Em seguida, questionamos a equipe da Oracle para entender o ocorrido, já que a ação executada foi exclusivamente a exclusão de um database em estado failed. Prontamente, realizamos o cancelamento da janela de exclusão e solicitamos uma RCA (Root Cause Analysis), com o objetivo de compreender o incidente e evitar que situações semelhantes possam resultar na exclusão de um banco de dados produtivo no futuro.
Hoje o chamado junto à Oracle foi atualizado e, nele, recebemos a explicação oficial sobre o problema ocorrido:
Problema
Encerrar (terminar) o database com status FAILED (CDBPRD2) pela console da OCI também resultou na exclusão de outro database com o mesmo nome, mesmo estando em estado AVAILABLE e possuindo OCID e Agent Resource ID diferentes.
Causa Raiz (Root Cause)
Este problema foi investigado pela equipe de desenvolvimento e identificado como um bug no código. A correção está sendo acompanhada sob o bug não publicado 39221331 e será incluída em uma futura versão do utilitário dbaastool.
Fica o alerta: mesmo com todas as validações técnicas realizadas, ainda é possível enfrentar comportamentos inesperados na OCI. Em ambientes críticos, todo cuidado é pouco principalmente quando a ação envolve exclusão de databases produtivos.