Acho que seria interessante explicitar pro pessoal que nos lê de que ordem seria essa "perda de tempo", que ocorre sim, pra que se possa avaliar : pois (claro) ocorre que NÂO é pelo fato de a package/procedure/o que for estar inválido por si só que causa demora, o que ocorre é que se estiver inválido, na hora da PRIMEIRA execução o bd tenta recompilar, e a recompilação dura coisa de dois a três segundos, nos piores casos, um exemplo com uma de minhas packages mais complexas aqui :
[EMAIL PROTECTED]:SQL>set timing on [EMAIL PROTECTED]:SQL>alter package PCK_GEN_LOTE_PREST compile; Pacote alterado. Decorrido: 00:00:01.09 depois disso (óbvio) as N outras execuções VÃO ser do cache, portanto sub-segundo como sempre, no exemplo que vc dá, a primeira execução demoraria uns segundos, as outras 49999 (digamos) vão no tempo normal....Claro, se a package é base pra n outras, essas n outras estarão inválidas, cada uma quando for executada terá uns segundos a mais na primeira execução, vc teria n * um ou dois segundos no total. Assim, se a pessoa não compilar os objetos dependentes após um DDL, o preço que ela paga são alguns segundos a mais MAS só na primeira execução - imho, afora casos como o do colega que iniciopi a thread, que EXIGEM (por força de bugs na tool/linguagem) a compilação, num caso normal imho acho que não vale o esforço de poupar esses poucos segundos, eu deixo pro próprio banco re-compilar os objetos dependentes após um DDL (claro, exceto os casos onde isso NÂO é possível, como drops por exemplo). []s Chiappa --- Em [email protected], "Ricardo Henrique Oliveira" <[EMAIL PROTECTED]> escreveu > > Caro Jlchiappa, > > obrigado pelos esclarecimentos quanto à compilação. > > Imagine a seguinte situação, um banco de dados que tenha em média 50 mil > acessos > por dia, e que uma alteração de uma tabela invalide um pacote que é base > para mais 10 pacotes. > > Até o oracle recompilar todos os pacotes, haverá uma perda de tempo ai e > consequentemente reclamação de usuários. O que eu quis dizer para o Luiz, > foi na verdade uma medida de segurança para recompilar objetos dependentes > que estiverem invalidados e garantir a disponibilidade das funções. > > Att, > > Ricardo Oliveira > > > > Em 28/01/07, jlchiappa <[EMAIL PROTECTED]> escreveu: > > > > Ricardo, não só adição mas ALTERAÇÃO e outros DDLs sim, invalidam, > > cfrme demontro abaixo - isso faz TODO o sentido inclusive, já que > > (claro) o programa foi compilado e cacheado quando a estrutura de > > banco era X, mudou o progrma já não deveria ser o mesmo... Note > > também que o fato de que um DDL (seja ALTER, CREATE ou DROP) invalidar > > os programas NÂO DEVERIA ser "problema" coisa alguma, pois quando o > > programa for re-executado a compilação (e sub-sequente revlidação é > > AUTOMÁTICA) cfrme : > > > > [EMAIL PROTECTED]:SQL>@desc dept > > Nome Nulo? Tipo > > ----------------------------------------- -------- > > ---------------------------- > > DEPTNO NOT NULL NUMBER(2) > > DNAME VARCHAR2(14) > > LOC VARCHAR2(13) > > > > [EMAIL PROTECTED]:SQL>create procedure P2 (P_DNAME dept.dname%TYPE) is > > 2 BEGIN > > 3 null; > > 4 END; > > 5 / > > > > Procedimento criado. > > > > [EMAIL PROTECTED]:SQL>create or replace procedure P1 is > > 2 BEGIN > > 3 p2('ABC'); > > 4 END; > > 5 / > > > > Procedimento criado. > > > > ==> tudo está ok... > > > > [EMAIL PROTECTED]:SQL>select object_name, status from user_objects where > > object_type='PROCEDURE' and > > 2 object_name like 'P_'; > > > > OBJECT_NAME STATUS > > ------------------------------ ------- > > P1 VALID > > P2 VALID > > > > ==> vou fazer um DDL ** alrerando ** o que já existia quando o > > programa compilou : > > > > [EMAIL PROTECTED]:SQL>alter table DEPT modify dname varchar2(18); > > > > Tabela alterada. > > > > ==> automaticamente o programa P2 (que dependia do objeto alterado) > > ficou inválido, E o P1, que depende do P2, já que P2 está inválido P1 > > fica também : > > > > [EMAIL PROTECTED]:SQL>select object_name, status from user_objects where > > object_type='PROCEDURE' and > > 2 object_name like 'P_'; > > > > OBJECT_NAME STATUS > > ------------------------------ ------- > > P1 INVALID > > P2 INVALID > > > > ==> mas NÂO PRECISO RECOMPILAR MANUALMENTE, basta executar normalmente : > > > > [EMAIL PROTECTED]:SQL>exec p1; > > > > Procedimento PL/SQL concluído com sucesso. > > > > ==> que TUDO que era dependência dessa execução já é revalidado : > > > > [EMAIL PROTECTED]:SQL>select object_name, status from user_objects where > > object_type='PROCEDURE' and > > 2 object_name like 'P_'; > > > > OBJECT_NAME STATUS > > ------------------------------ ------- > > P1 VALID > > P2 VALID > > > > ==> o que já vi muito acontecer é linguagem de programação/ambiente > > metido a "esperto", que NÃO DEIXA vc executar um programa inválido, o > > que é ERRADO, pois como vimos mesmo inválido a execução VAI provocar > > uma compilação automática... Linguagens/tools que não deixam vc > > executar PLs inválidos (e portanto exigem compilação manual anterior) > > imho possuem é um BUG lógico, não estão respeitando uma das condições > > do banco... > > > > Luiz, o ponto que esta resposta tenta mostrar é que : > > > > a) NÂO EXISTE isso de quer "de repente ficam com status invalid", > > necessariamente PARA que fique inválido algo ou alguém alterou alguma > > coisa, isso NÃO ACONTECE "do vácio sideral", por obra e graça de San > > Gennaro, não... > > > > b) a tua tool aí de report, seja qual for, NÃO DEVERIA barrar de cara > > PLs inválidos, SEM permitir os re-executar... > > > > por causa de que b) ocorre aí no seu caso, o que vc DEVERIA > > implementar (e pelo jeito não tem) é uma POLÍTICA RÍGIDA de aplicação > > de DDLs na produção, E após cada DDL implantar como regra de que os > > obetos dependentes do que foi alterado (isso vc consulta na > > DBA_DEPENDENCIES) sejam re-compilados no ato.... Como mostrado acima, > > essa parte da política de re-compilar após DDLS NÂO DEVERIA ser > > necessária, mas por causa da sua tool de programação o será ... > > > > Como final, que fique claro que a execução re-compila e valida > > automaticamete APENAS o mínimo que é necessário para a execução ser > > bem sucedida, exemplo : > > > > [EMAIL PROTECTED]:SQL>alter table DEPT add regiao char(1); > > > > Tabela alterada. > > > > [EMAIL PROTECTED]:SQL>select object_name, status from user_objects where > > object_type='PROCEDURE' and > > 2 object_name like 'P_'; > > > > OBJECT_NAME STATUS > > ------------------------------ ------- > > P1 INVALID > > P2 INVALID > > > > [EMAIL PROTECTED]:SQL>exec p2('abc'); > > > > Procedimento PL/SQL concluído com sucesso. > > > > [EMAIL PROTECTED]:SQL>select object_name, status from user_objects where > > object_type='PROCEDURE' and > > 2 object_name like 'P_'; > > > > OBJECT_NAME STATUS > > ------------------------------ ------- > > P1 INVALID > > P2 VALID > > > > já que P2 ** não depende ** de P1, P1 não foi validada.... Isso via de > > regra num ambiente normal não tem importância, pois assim que qquer > > outra rotina que deoende de P1, ou a própria P1, for executada, a > > re-validação automática ocorrerá... > > []s > > > > Chiappa > > > > --- Em [email protected] <oracle_br% 40yahoogrupos.com.br>, > > "Ricardo Henrique Oliveira" > > <ricardo.henrique.oliveira@> escreveu > > > > > > Prezado Luiz, > > > > > > quanto ao join, procure outros tipos de join para fazer testes. > > > Quanto à procedures invalidas, tenho uma pergunta a fazer. > > > > > > Como é procedimento de adição de campos de colunas, tabelas > > > triggers e sequences no seu ambiente de produção ? > > > > > > Das versões anteriores do oracle até o 10G, se você fizer alguma > > alteração > > > em colunas ou em tabelas que são usadas nestes pacotes e procedures > > > mencionados, os pacotes ficam invalidos obrigando à você refazer a > > > compilação. > > > > > > Esse problema será corrigido no Oracle 11i, que tem previsão de > > chegar no > > > final de 2007 ou começo de 2008. > > > > > > Por enquanto, toda vez que você fizer alguma alteração, inclusive se > > > compilar pacotes de um determinado > > > esquema, verifique se existem pacotes inválidos. > > > > > > Att, > > > > > > Ricardo Oliveira > > > > > > > > > 2007/1/26, Luiz Scarpelli <luizsfm@>: > > > > > > > > Boa noite grupo, > > > > > > > > Tenho duas dúvidas e gostaria de obter ajuda de quem puder me > > > > esclarecer... > > > > > > > > Primeiramente tenho duas consultas: uma roda rapidamente > > > > > > > > SELECT PRODUTO, NVL(T2.PRECO + T2.VALFRETE, 0) AS CUSTREPO > > > > > > > > FROM DW_CMEDIO_MP_ME_MO_HISTORICA T1, VIEW_CUSTO_REPOSICAO T2 > > > > > > > > WHERE RTRIM(LTRIM(T2.PRODUTO)) = RTRIM(LTRIM(T1.PRODUTO)) > > > > > > > > AND T1.COMPETENCIA = '200610' > > > > > > > > E a outra praticamente não roda, a diferença é a utilização da > > clausula > > > > "inner join" > > > > > > > > SELECT PRODUTO, NVL(T2.PRECO + T2.VALFRETE, 0) AS CUSTREPO > > > > > > > > FROM VIEW_CUSTO_REPOSICAO T2 > > > > > > > > INNER JOIN DW_CMEDIO_MP_ME_MO_HISTORICA T1 ON > > RTRIM(LTRIM(T1.PRODUTO)) = > > > > RTRIM(LTRIM(T2.PRODUTO)) > > > > > > > > WHERE T1.COMPETENCIA = '200610' > > > > > > > > Outra situação as vezes acontece de store procedures que estão > > funcionando > > > > normalmente e derrepente ficam com status invalid causando erros no > > > > relatório do Crystal tendo que compilar a store procedure > > novamente para > > > > que > > > > a mesma volte a ser executada normalmente, praticamente todos os > > dias isto > > > > acontece. Alguém já passou por isso? > > > > > > > > Oracle 9i rodando em Windows. > > > > > > > > Att. > > > > > > > > -- > > > > > > > > Luiz Scarpelli > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
