Menu de navegação

[airoospParticipante]

Boa tarde,

Gostaria de saber o que os colegas fazem para ter um controle de versão das packages, procedure e functions.

Ao fazer o backup de um owner, todos os objetos são copiados, mas se for necessário recuperar uma procedure, como fazer sem precisar fazer o restore completo do owner?

Ambiente aqui é Windows com banco 10g.

Obrigado.

Airton

[Paulo WerneckParticipante]

@airoosp

Esse artigo do Fabio Prado é excelente, dá uma olhada…

http://www.fabioprado.net/2012/06/repositorio-de-metadados-no-oracle.html

[José Laurindo ChiappaModerador]

Bem, sempre é possível se ter alguma coisa customizada, mas pra quem não quer/não precisa reinventar a roda (e portanto pode se ajustar à soluções externas), sempre existe a opção de se tratar os fontes PL/SQL como fontes quaisquer e usar um software de versionamento, Preferencialmente um dos que se integram com a ferramenta em uso, que se for Oracle SQL Developer pode ser CVS/SUBVERSION : http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/prod/appdev/sqldev/srccodexmlext/srccode_otn.htm#t2 tem um exemplo pequeno…
É *** óbvio ****, porém, que seja qual for a ferramenta, o DBA/Analista/Desenvolvedor-chefe ** tem ** que :

a. barrar o desenvolvimento direto no database, proibindo/tirando os privilégios que permitam que os desenvolvedores bypassem o acesso à tool de versionamento e saiam dando CREATE OR REPLACE PROCEDURE direto no banco : entre outras coisas, certamente isso vai implicar promoção de código (ie, apenas o DBA e/ou o analista-chefe implementam código em Produção, e o faz SEMPRE com os fontes já testados/homologados vindos dos Desenvolvedores)

b. se ASSEGURAR que os desenvolvedores seguem um ciclo de desenvolvimento formal, Evitando arquivos-fontes “esquecidos”na máquina pessoal do cabrón

c. se ASSEGURAR que os recursos da ferramenta que evitam 2 pessoas trabalhar no mesmo fonte estão ativos

d. usar os recursos de rollback da ferramenta, mantendo ao menos umas 3 versões dos fontes armazenadas na ferramenta

[]s

Chiappa

[airoospParticipante]

Boa tarde,

Vi no site do Fabio Prado o assunto sobre versionamento usando um repositório no banco de dados, criei o ambiente e fiz alguns testes.

Inicialmente funcionou, mas quando fui executar o processo que busca os objetos conforme o schema e verifica para acrescentar na tabela de versionamento “REPOSITORY_METADATA”, ocorre um erro de falta de memória após o processo estar em execução por quase 1 hora.

O total de schemas do banco é 67. Os testes estou fazendo no ambiente de homologação, banco 10g com Windows Server.

Alguém já utilizou a solução proposta pela Fabio?

Se sim, teve algum problema?

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Blz ? Eu não uso a solução indicada pelo Fábio Prado, vamos aguardar se alguém que use possa dar detalhes, e vc pode também mandar uma mensagem pro Fábio mesmo, provavelmente no site dele deve ter um email de contato….
Enquanto isso, como é feita em PL/SQL eu tenho algumas Sugestões pra te dar :

a) a primeira coisa é saber *** EXATAMENTE *** qual ponto de qual programa está dando o erro, ou está demorando muito : pra fazer isso, vc ** TEM ** que instrumentar o programa PL/SQL…. Há muitas possibilidades para isso, mas uma que eu aprecio DEMAIS para acompanhar o fluxo de execução é inserir umas chamadas DBMS_APPLICATION_INFO.SET_CLIENT_INFO, tipo :

….
for r in (select colunachave, coluna1, coluna2 FROM tabela where condição) loop
i := i + 1;
DBMS_APPLICATION_INFO.SET_CLIENT_INFO(‘Reg#’ || i || ‘, Chave=’ || r.colunachave || ‘ em ‘ || to_char(sysdate, ‘hh24:mi:ss’));
….

Aí vc simplesmente abre outra sessão nesse banco (via sql*plus, que seja) e vai repetidamente consultando a coluna CLIENT_INFO da V$SESSION … Outra opção é vc lançar mão do UTL_FILE, que grava um arquivo em disco ..

==> Para Debugar, ie, saber onde dá erro, entre as muitas opções vc poderia ter EXCEPTIONs e em cada EXCEPTION vc informa o número da linha : em alguns casos dá pra vc implementar algo com as packages de error stack (tipo http://awads.net/wp/2006/07/25/how-to-find-where-an-error-was-raised-in-plsql/) , em outros vc pode ter que apelas pra baixa tecnologia e escrever assim :

…
v_pos := 50;
select nãoseique;
v_pos := 60;
update nãoseiquelá;
v_pos := 70;
v_status := x;
…
EXCEPTION
when others then
dbms_output.put_line(‘Erro na linha ‘ || v_pos….)

Juntando isso com as functions que mostram o código do erro, como a SQLERRM…
istro’)

===>> O QUE NÃO ADIANTA é vc só lançar uma frase “ah deu erro” e não saber exatamente QUAL erro em QUAL linha de QUAL programa…. Idem pra questão de tuning…

b) É ** extremamente Comum ** que erros de falta de memória tenham a ver com seu setup : no RDBMS Oracle, vc separa a memória dedicada a caches internos (a chamada SGA) da memória dedicada para uso de sessões( principalmente variáveis PL/SQL), a chamada PGA …. Muita gente desconhecendo isso bobamente acaba fazendo um setup troncho, deixando uma montanha pra SGA e ficando sem espaço pra PGA….
A minha primeira Recomendação seria portanto vc rever o seu setup de memória pra esse banco, Aumentando a sua PGA para o máximo possível que não interfira muito na sua SGA – até, já que (ao que entendo) essa rotina ** NÃO ** é algo que vc vai rodar frequentemente, é algo que vc roda de vez em quando, pense na possibilidade de TEMPORARIAMENTE desligar a política de gerenciamento automático (setando WORKAREA_SIZE_POLICY para MANUAL) na sessão que vai rodar a rotina…
iirc vc está no 10g, não sei exatamente o que vc pode setar sem reboot no 10g mas cheque lá na Documentação….
==>> EVIDENTEMENTE, tou dando de barato que vc TEM memória RAM em quantidade decente, teu Sistema Operacional tá corretamente setado/configurado para poder acessar toda a memória, etc, etc… EM ESPECIAL sendo Windows, se for Windows de 32 bits há limites pro máximo de RAM acessível por vez….

[]s

Chiappa

[airoospParticipante]

Chiappa,

Fiz algumas alterações na procedure, utilizei as informações que você passou e consegui identificar o erro:

ORA-31600: valor de entrada COMPATIBLE válido para o parâmetro VERSION na função GET_DDL
ORA-06512: em “SYS.DBMS_METADATA”, line 2681
ORA-06512: em “SYS.DBMS_METADATA”, line 2732
ORA-06512: em “SYS.DB

Este processo esta sendo executado no ambiente de homologação que tem o banco 10g (10.2.0.3) em servidor Windows.

Interessante que esta ocorrendo quando o processamento esta verificando os objetos de um schema, após 30 minutos de execução.

Este schema tem 20377 objetos no banco. Com o outro schema que contém 22059 objetos o erro não ocorre.

O total de schemas que serão processados é 45, o erro ocorreu quando o 32º schema é processado.

Um outro teste que fiz foi, executar separadamente o schema que apresentou o erro, e o processo funcionou corretamente.

Se tiver alguma dica, agradeço.

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Pelo jeito, não é nem questão de qtdade de objetos, parece que vc está enfrentando um BUG na versão do DBMS_METADATA.GET_DDL aí desse banco 10.2.0.3 – que alíás, ** IMAGINO ** que vc vai estar o quanto antes, PRA ONTEM mesmo, passando pra 10.2.0.5 com a aplicação do último patchset do 10Gr2 – o que teve de BUg corrigido na 10.2.0.4 E (PRINCIPALMENTE!!) no patchset 10.2.0.5 não tá no gibi…
Pelo que vc descreve, o bug deve ser algo do tipo : nesse esquema que dá erro há um objeto qualquer que foi criado com parâmetros que essa versão 10.2.0.3 do DBMS_METADATA não conhecia/antecipava, aí dá estouro…. Ou de repente uma OUTRA possibilidade é vc estar passando pra tal rotina de documentação que extrai metadados um objeto de um tipo que a DBMS_METADATA 10g ** não ** permite, veja https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1794096300346327738 para um caso desses, no caso lá da outra pessoa para user snapshots mas podem haver Outras situações….

Enquanto a pessoa que escreveu a tal rotina (ou alguém que a esteja usando) não te responde, a minha Sugestão é que Primeiro vc continue o trabalho de debug, localizando EXATAMENTE qual objeto o DBMS_METADATA estava lendo / acessando quando dá o erro, e se depois de uma pesquisada por bugs vc não conseguir solucionar, minha Segunda recomendação é vc contornar o erro com uma EXCEPTION corretamente colocada num bloco dentro do LOOP (imagino que seja um LOOP) lendo a sua relação de objetos….

[]s

Chiappa

OBS : tudo o que eu falei de aumentar PGA ** continua ** Valendo, é algo que pode ser que esteja interferindo, sim…. Igualmente, eu recomendaria que (DEPOIS de ter debugado, aumentado PGA, colocado EXCEPTION pra “pular” o objeto que causa o erro, etc) além disso vc executasse essa tal rotina num momento em que POUCOS usuários estejam usando o banco….

[airoospParticipante]

Chiappa,

Na trigger “DDL_MONITOR AFTER CREATE OR DROP OR TRUNCATE OR ALTER ON DATABASE” tentei obter o código DDL do objeto que foi modificado, por exemplo uma tabela.

Para isso usei:

Declare
S_DDL CLOB;

select cast(dbms_metadata.get_ddl(ora_dict_obj_type, ora_dict_obj_name, ora_dict_obj_owner) as varchar2(4000)) into S_DDL from dual;

Mas o select não retorna nada.

Será que é possível obter o código DDL já com as alterações?

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Eu não estou com o 10g pra testar, mas se vc não conseguir contornar a questão do DBMS_METADATA fazendo um ** DEBUG ** como eu indiquei E tentando executar manualmente o DBMS_METADATA.GET_DDL, pra saber EXATAMENTE qual objeto, de que tipo e em qual situação está causando a falha e não trazendo o DDL (o que inclusive afaik deve ser SIM bug na sua exata versão/edição do 10g, iirc a DBMS_METADATA pode Sim ser usada em triggers de DDL), https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:33373327079924 e https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1433604222919 são artigos antigos, escritos na época do 10g, aonde o Autor não usou DBMS_METADATA para obter texto do SQL que disparou a DDL… Outra ALTERNATIVA de work-around seria obter diretamente das views xxx_OBJECTS, xxx_TABLES, xxx_INDEXES, etc, a informação necessária para criar o DDL do objeto : é TRABALHOSO mas pode ser feito sim, veja https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1113105138675 para um exemplo de rotina que gera CREATE TABLE, vc teria que escrever algo similar para gerar além disso CREATE INDEXES, CREATE PROCEDURE, CREATE FUNCTION e quais mais DDLs vc quer ter histórico…

[]s

Chiappa

[José Laurindo ChiappaModerador]

IMPORTANTE : imagino que vc saiba que para PROCEDURES, FUNCTIONS e PACKAGES (que são os objetos que vc quer versionar, ao que entendi) o RDBMS Oracle *** Automaticamente *** mantém o código em views internas do sistema (as DBA/ALL/USER_SOURCE), então talvez teu código esteja DESNECESSARIAMENTE complicado : não vejo NENHUMA necessidade de usar o DBMS_METADATA para se obter código fonte, ao que entendo seria simplesmente uma trigger CREATE OR REPLACE TRIGGER nomedela BEFORE CREATE ON DATABASE onde vc copia o código-fonte da procedure vindo da DBA/ALL/USER_SOURCE pra uma tabela sua…. Esse monte de chamadas à DBMS_METADATA me parecem meio que INÚTEIS se teu objetivo é Apenas e Tão Somente versionar procedures, Functions e Packages…

[]s

Chiappa

[Autor]

Posts