Menu de navegação

[Ricardo NevesParticipante]

Meus queridos amigos,

Tenho uma dúvida tola de que não entendo e espero que você me ajude.

Como posso saber quando um código-fonte de objeto de banco de dados foi atualizado. Eu sei que na tabela dba_objects existem várias colunas com esta informação, mas quando eu realmente sei quando o código-fonte de uma procedure por exemplo foi alterada, pois um simples comando de compilação pode atualizar essas colunas ou estou errado?

Me ajude a entender isso.

Obrigado.

[José Laurindo ChiappaModerador]

Deixa eu entender direitinho : vc gostaria de saber se quando da última compilação o código-fonte foi Alterado em relação ao que já existia (ie, foi feito um CREATE OR REPLACE nomedoobjeto AS codigofontecomalgumaalteração) OU se foi feito um simples ALTER nomedoobjeto COMPILE; sem qualquer alteração no fonte, é isso ?

Se é isso mesmo sim, vc está correto : mesmo que alguém faça um simples ALTER objetoprogramático COMPILE; sem mudar uma vírgula que seja do código-fonte a coluna LAST_DDL_TIME da DBA_OBJECTS ** vai ** sim refletir essa compilação…

Afaik para ter o que vc quer (ie, uma versionamento PRECISO do código-fonte, contendo a versão anterior E a versão alterada do texto do código-fonte do objeto, pra poder dizer se a última compilação implicou em mudança do fonte ou não) só mesmo implementando algum tipo de Auditoria : uma possíbilidade seria ter uma TRIGGER de DDL que captura o código-fonte antes da compilação/criação, tipo https://technology.amis.nl/2005/10/12/plsql-source-code-control-inside-the-database-after-compile-trigger-for-automatic-archiving/ por exemplo…. OU então, se é um ambiente restrito e profisionalmente controlado, necessariamente há algum tiupo de software de controle de código-fonte (git, svn, sourcesafe, qquer um) que Registra/Controla alterações no fonte, E o DBA *** não dá *** nem privs de compilação NEM a senha do dono dos obejtos programáticos ds Aplicação pra desenv nenhum…

[]s

Chiappa

[Ricardo NevesParticipante]

Como sempre, respostas com conteúdo muito proveitos, agora vou decidir como iremos resolver isto internamente. Obrigado Chiappa.

[José Laurindo ChiappaModerador]

Blz, fico contente de poder ter esclarecido a questão… Só te faço uma recomendação, que é a seguinte : ** INSISTA ** em ter políticas de code review, promoção de código E de controle de versão em produção adequadas, Fuja das “gambiarras” tipo trigger….
Insisto, num ambiente profissionalmente controlado, os desenvolvedores desenvolvem e fazem um teste inicial no banco de desenv deles, onde não há grande coisa de controle (mas a Equipe ** possui ** alguma ferramenta tipo sourcesafe/git/svn/whatever, que controla QUEM está alterando O QUE), depois quando se julgar que o código está com qualidade suficiente se faz um teste mais real e profundo – normalmente isso implica que os desenvolvedores NÂO POSSAM COMPILAR coisa alguma em PROD, que eles forneçam o código (E os DDLs/DMLs necessários exigidos pelo Código) para que o analista e/ou o DBA faça um review desse código (bloqueando coisas patentemente absurdas, inseguras e/ou que violem políticas da Empresa), e feito o review o código é aplicado e testado Profundamente num banco de HOMOLOGAÇÃO, que possui volumes de dados e concorrência similar ao PROD o mais possível, inclusive para se testar performance também…
Apenas com a Homologação ok é que se vai implementar em Prod, e nesse ponto é que se faz um BACKUP da versão anterior do código e das tabelas/objetos envolvidas … ok ? Aí sim vc NUNCA vai ter que se preocupar com quem alterou a procedure tal ou qual em Produção a última vez, como estava o código antes, etc…

[]s

Chiappa

[Autor]

Posts