Re: [oracle_br] Re: ORA-00604: error occurred at recursive SQL level 1

2016-07-11 Por tôpico jlchia...@yahoo.com.br [oracle_br]
yep... Há casos e casos, mas no exemplo ao que parece a sequência no error 
stack claramente parece indicar que o ORA-604 foi causado pelo 3135, que veio 
depois , como um "detalhe" suplementar do ORA-604, então por isso foquei 
nele... Fosse algum código diretamente relacionado á SQL e/ou PL/SQL (como 
digamos o ORA-6502) eu focaria em triggers, procedures e customizações de 
usuário do tipo...
 
 Agora, uma outra coisa que só vi agora : iirc LBACSYS é o schema owner do 
Oracle Label Security, me parece suspeito que as rotinas onde estourou o 3135 
(que em tese causou o 604) pertençam a ele - será que na verdade não pode ser 
bug do Oracle Label Security em si ?? Veja isso também... 
 
  []s
  
Chiappa

Re: [oracle_br] Re: ORA-00604: error occurred at recursive SQL level 1

2016-07-11 Por tôpico Wanderson Barrence wbarre...@gmail.com [oracle_br]
Obrigado Chiappa!!!

Já ajudou bastante, estava seguindo essa mesma linha de raciocínio, o que
perturbou foi o erro "ORA-00604: error occurred at recursive SQL level 1",
na última vez que tive esse problema era uma trigger que precisava ser
desabilitada.

Att,

Wanderson

Em 11 de julho de 2016 16:37, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Opa, blz ? Então, o ORA-03135: connection lost contact é simples e claro,
> a conexão que estava que estava atendendo à sessão foi eliminada e/ou parou
> de responder... Diversos elementos de Rede podem matar/bloquear uma
> conexão, por exemplo
> https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:1669523300346721212
> mostra um caso em que era Firewall o responsável, mas não só isso : filtros
> de pacotes, QOS agressivamente setado, infra de rede sobrecarregada, pools
> de conexão com BUG, e muitos Outros podem causar isso também E NADA
> DISSO vc resolve no banco, é TUDO EXTERNO
>  Porém, não há como não notar o fato que vc tá com 10.2.0.3 : isso é uma
> versão MEGA-ANTIGA, especialmente recheada de bugs, não é impossível que
> algum bug (seja do banco, seja do sql*net, seja dos serviços rac como o
> balance) esteja causando a desconexão/perda de contato, Analise isso no
> metalink
>
>   []s
>
> Chiappa
> 
>


[oracle_br] Re: Export/Import Sequences

2016-07-11 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Ô se tem, até Mais De uma  Vc pode :

a) via export fazer um export full :  as sequences são AUTOMATICAMENTE 
incluídas num export full, seja via exp tradicional seja via datapump... Vc 
poderia mandar um ROWS=N pra que sejam gerados só os DDLs, se quiser, pra ter 
uma performance algo melhor se for o caso... A Vantagem desta opção é que com 
ela além das Sequences vc já vai receber o DDL de ** todos ** os outros objetos 
do banco, das Tablespaces, dos sinônimos, de tudo enfim que se refere à dados 
de usuário

OU

b) via datapump , usando o expdp vc pode usar o parâmetro INCLUDE pra fazer um 
export só com as sequences, que vc importaria com o impdp sem prob algum - iirc 
isso já existia no 10g, tranquilo...

OU

c)  a melhor imho : vc usa a DBMS_METADATA para extrair o DDL com o CREATE 
delas, salvando ele prum arquivo-texto que vc transfere pro banco-destino e 
executa lá... Isso é simples, rápido e (já que vc é que está extraindo a 
informação) Facilmente permite customizações como pular linhas em branco, 
trocar CR+LF por LF (se tiver Windows e não-Windows envolvidos na parada), 
eliminar Cláusulas de START ou de MAXVALUES ou coisas assim, é a mais Fléxível 
das opções, imho, e por isso éminha Preferida...

 []s
 
   Chiappa

Re: [oracle_br] Export/Import Sequences

2016-07-11 Por tôpico Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br]
Boa noite, 

Você pode usar essa query ou usar a dba_objects passando o owner como parâmetro 
para a dbms_metadata.

Select DBMS_METADATA.GET_DDL('SEQUENCE',a.OBJECT_NAME) from user_objects a 
where a.OBJECT_TYPE ='SEQUENCE' order by a.OBJECT_NAME;
 

[ ]'s
#mufalani

   Desculpe por erros! Este e-mail foi escrito do meu smartphone!

Sorry for typos! This mail was written from my smartphone!!!

> Em 11 de jul de 2016, às 17:42, 'Ednilson Silva' ednilson.si...@jbs.com.br 
> [oracle_br]  escreveu:
> 
> Pessoal,
> 
> Existe alguma maneira de fazer um export de todas sequences de todos os owner 
> do meu banco 10.2.0.5 (PROD) e importar no meu banco de homologação 10.2.0.5?
> 
>  
> 
> Grato
> 
> Ednilson Silva
> 
> 


[oracle_br] Export/Import Sequences

2016-07-11 Por tôpico 'Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br]
Pessoal,

Existe alguma maneira de fazer um export de todas sequences de todos os
owner do meu banco 10.2.0.5 (PROD) e importar no meu banco de homologação
10.2.0.5?

 

Grato

Ednilson Silva



[oracle_br] Re: ORA-00604: error occurred at recursive SQL level 1

2016-07-11 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Opa, blz ? Então, o ORA-03135: connection lost contact é simples e claro, a 
conexão que estava que estava atendendo à sessão foi eliminada e/ou parou de 
responder... Diversos elementos de Rede podem matar/bloquear uma conexão, por 
exemplo 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:1669523300346721212
 mostra um caso em que era Firewall o responsável, mas não só isso : filtros de 
pacotes, QOS agressivamente setado, infra de rede sobrecarregada, pools de 
conexão com BUG, e muitos Outros podem causar isso também E NADA DISSO vc 
resolve no banco, é TUDO EXTERNO
 Porém, não há como não notar o fato que vc tá com 10.2.0.3 : isso é uma versão 
MEGA-ANTIGA, especialmente recheada de bugs, não é impossível que algum bug 
(seja do banco, seja do sql*net, seja dos serviços rac como o balance) esteja 
causando a desconexão/perda de contato, Analise isso no metalink
 
  []s
  
Chiappa

[oracle_br] ORA-00604: error occurred at recursive SQL level 1

2016-07-11 Por tôpico Wanderson Barrence wbarre...@gmail.com [oracle_br]
Olá Pessoal,

Estou com um problema que está ocorrendo todos os dias no Oracle RAC aqui
da empresa, por volta das 10:50 da manhã o listener de um dos nós cai, e
pelo trace e os logs não estou conseguindo diagnosticar com exatidão o
problema.

Alguém pode ajudar?

*Sistema Operacional: *
Red Hat Enterprise Linux AS release 4 (Nahant Update 6)

*Banco de dados: *
Oracle Database 10g Release 10.2.0.3.0 - 64bit Production
With the Real Application Clusters option

*Alert.log*
Mon Jul 11 10:52:04 2016
Errors in file /u02/app/oracle/admin/SIMPAT/udump/spt2_ora_7936.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-03135: connection lost contact
ORA-06512: at "LBACSYS.LBAC_CACHE", line 336
ORA-06512: at "LBACSYS.LBAC_EVENTS", line 141
ORA-06512: at line 2

*Trace*
/u02/app/oracle/admin/X/udump/spt2_ora_8445.trc
Oracle Database 10g Release 10.2.0.3.0 - 64bit Production
With the Real Application Clusters option
ORACLE_HOME = /u02/app/oracle/product/10.2.0/db_1
System name:Linux
Node name:  2.X.com.br
Release:2.6.9-67.ELsmp
Version:#1 SMP Wed Nov 7 13:56:44 EST 2007
Machine:x86_64
Instance name: XXX2
Redo thread mounted by this instance: 2
Oracle process number: 127
Unix process pid: 8445, image: oracl...@xxx2.x.com.br

*** 2016-07-11 10:52:07.343
*** SERVICE NAME:(SIMPAT) 2016-07-11 10:52:07.342
*** SESSION ID:(1183.9479) 2016-07-11 10:52:07.342
Skipped error 604 during the execution of LBACSYS.LBAC$LOGON
*** 2016-07-11 10:52:07.343
ksedmp: internal or fatal error
ORA-00604: error occurred at recursive SQL level 1
ORA-03135: connection lost contact
ORA-06512: at "LBACSYS.LBAC_CACHE", line 99
ORA-06512: at "LBACSYS.LBAC_EVENTS", line 137
ORA-06512: at line 2

*Listener.log*
11-JUL-2016 10:51:21 *
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=x)(CID=(PROGRAM=C:\x\.exe)(HOST=xx)(USER=Administrator)))
* (ADDRESS=(PROTOCOL=tcp)(HOST=x)(PORT=)) * establish * xxx*
12560
TNS-12560: TNS:protocol adapter error
 TNS-00517: Lost contact
  Linux Error: 32: Broken pipe
   TNS-12509: TNS:listener failed to redirect client to service handler
TNS-12571: TNS:packet writer failure
 TNS-12560: TNS:protocol adapter error
  TNS-00530: Protocol adapter error
   Linux Error: 104: Connection reset by peer

Att,

Wanderson


[oracle_br] Re: Procedure com erro

2016-07-11 Por tôpico germanopac...@gmail.com [oracle_br]
Chiappa, 

 Isso mesmo.
 Obrigado pela excelente explanação.
 

 []s


[oracle_br] Re: Procedure com erro

2016-07-11 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Blz : acho que ficou claro então que vc tem 3 frentes de atuação, Simultâneas 
(nenhuma Interfere na outra, então ** Todas as 3 ** vc faz ao mesmo tempo) :

1) implantar as ** outras ** tools de check contra corrupção, talvez até mesmo 
pensando em depois de corrigida implentar os CHECKSUMs de bloco nesse banco, 
pra ver se não volta mais essa corrupção

2) Implantar uma rotina que (via spool ou SQL dinâmico) mande as strings com os 
nomes das tabelas diretamente pra DBMS_REPAIR.CHECK, bypassando esse ORA-600 
que ocorre quando vc bota em variável o nome dela, como um work-around enquanto 
o patchset mais recente não é aplicado - NÂO ESQUECENDO detalhes de sintaxe 
como o OBJECT_TYPE, que eu APONTEI na resposta anterior, ok ? Joga no seguro 
aqui, não confie em defaults...

3) aplicar patchset mais recente e (provavalmente) o CPU ou PSU mais recente, 
PREFERENCIALMENTE com apoio do Suporte Oracle que vai Primeiro confirmar que o 
bugfix pra esse ORA-600 tá mesmo incluso (deve estar, pelo jeito) E depois que 
vai confirmar também se a CORRUPÇÃO que vc encontrou pode ter a ver com algum 
bug corrigido no patchset e/ou no CPU/PSU mais recente

[]s

  Chiappa

[oracle_br] Re: Procedure com erro

2016-07-11 Por tôpico germanopac...@gmail.com [oracle_br]
Chiappa, 

 Opa, isolei as tabelas com 0 linhas e mesmo assim o erro continua, mas 
obrigado pela observação, vou aplicar os patches e tentar novamente e me 
atentar para todos os pontos que vc coloca na 1a resposta.
 

 Obrigado.


[oracle_br] Re: Procedure com erro

2016-07-11 Por tôpico germanopac...@gmail.com [oracle_br]
Chiappa, 

 Excelente explanação. Vc tem toda razão quando fala ref. à verificação de 
hardware inclusive, pois de nada adianta corrigir o bloco corrompido se isso 
for gerado por memória ou disco bugado, em tese, vai resolver, depois acontece 
de novo.
 Quanto ao patch, correto de novo.
 

 Obrigado pela explanação e vou utilizar da forma como vc coloca mesmo.
 

 Abraços,
 



[oracle_br] Re: Procedure com erro

2016-07-11 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Só de curiosidade, mesmo sem os argumentos e detalhes do ORA-600, fiz uma 
pesquisa rapidinha no metalink/Oracle Support e de cara caí no artigo "Bug 
9256694 - DBMS_REPAIR fails with ORA-600 [kkpo_rcinfo_defstg:delseg] on table 
with 0 rows" (Doc ID 9256694.8) : Óbvio que outros bugs podem existir, mas veja 
lá, se for esse talvez o workaround seja tão simples quanto pular as tabelas 
com zero linhas
 E outra coisinha que reparei : vc está usando a sintaxe :
 
   sys.DBMS_REPAIR.CHECK_OBJECT ( SCHEMA_NAME => 'nomedoschema' ,  OBJECT_NAME 
=> i.table_name  ,  REPAIR_TABLE_NAME => 'REPAIR_TABLE',  CORRUPT_COUNT =>  
num_corrupt);
   
 enquanto na nota o pessoal exemplifica com :

sys.dbms_repair.check_object( 
schema_name   => 'nomedoschema'
   ,object_name   => 'nomedatabela'
   ,object_type   => 1
   ,corrupt_count => L_error_count); 

   ==> comparando, veja que vc Não Passa a informação de ** OBJECT_TYPE ** 
(afaik Crítica, se não como ele vai saber se é Tabela, View, o o que vc quer) - 
pode ter relação com seu prob, também...
   
   []s
   
 Chiappa

[oracle_br] Re: Procedure com erro

2016-07-11 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Blz ? Antes de responder, eu ** tenho que observar que o DBMS_REPAIR.CHECK é ** 
uma ** das maneiras de se checar por corrupção : vc TEM que usar várias, pois 
as Dieferentes ferramentas vão te verificar diferentes tipos de corrupção - 
assim sendo, além dela vc ** VAI ** ter que necessariamente usar Também o 
dbverify (tanto ONLINE quanto OFFLINE - algo que MUITA GENTE esquece!), ** VAI 
** usar o analyze table validate structure, um export full (só pra fazer a 
leitura geral de tudo), pelo RMAN fazendo primeiro um  BACKUP VALIDATE e depois 
um  BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL, E DEPOIS Óbvio que 
vai usar as tools que tiver no Sistema Operacional para (com banco Aberto no 
caso das não-destrutivas/que não alteram nada, E com o banco FECHADO nas 
outras) procurar por falhas eou olhar logsmsgs de sistema ref.  disco, 
filesystem, memória e hardware em geral SE vc está confiando Só e Apenas no 
DBMS_REPAIR,CHECK para identificar corrupção, vc está fazendo um serviço 
INCOMPLETO aí, blz ? fechado ?

 Isso posto, a sua resposta : um ORA-600 *** não é *** para ser tratado como 
uma Exceção (ie, algo Possível e passível de ocorrer) , mas sim indica um BUG, 
de pleno direito, okdoc ? É ERRO mesmo, então vc TEM que antes de mais nada 
fazer uma pesquisa por BUGs abertos na sua versão e no seu SO - dado que tua 
versão 11.2.0.1 indica que NENHUM PATCHSET (e talvez nenhum patch de forma 
geral ?) nunca  foi aplicado nesse ambiente, chances existem de que seja isso 
mesmo, Verifique, pois Provavelmente até já deve existir ou bugfix ou 
workaround... 
  
  Como vc diz que ao informar a string com o nome a rotina em tese funciona, 
Provavelmente deve ser um bug de referência no PL/SQL , então o Workaround 
óbvio é , ao invés de ter um loop passando por ref o valor, gere um script com 
as n linhas que vc quer, mais ou menos tipo (se vc for usar sql*plus) :
  
  
delete from cerv.log10 ;
variable num_corrupt number;
select 'sys.DBMS_REPAIR.CHECK_OBJECT ( SCHEMA_NAME => ' || chr(39) || 'CERV' || 
chr(39) || ',  OBJECT_NAME =>' || table_name 

 || ',  REPAIR_TABLE_NAME => ' || chr(39) || 'REPAIR_TABLE' || chr(39) || ',  
CORRUPT_COUNT =>:num_corrupt'  as linha_comando
 table_name from user_tables where 1=1   and table_name not in ( select 
view_name from user_views)  ;
 
===> Isso te geraria uma lista com as N chamadas para o DBMS_RAPAIR (uma pra 
cada tabela) , é só jogar essa lista prum arquivo-texto (via SPOOL, 
provavelmente), salvar esse arquivo-texto com extensão .SQL e executá-lo como 
um script de comandos... 
 Uma variação da técnica é passar a string gerada para cada chamada pra um 
EXECUTE IMMEDIATE, pra já sair executando ao invés de salvar em disco o texto 
com os comandos - eu gosto mais de gerar o texto em um arquivo porque é mais 
fácil de debugar E já tou com ele na mão se precisar repetir e/ou se precisar 
executar só uma parte, mas vai do gosto...
 
 OBS : eu NEM PRECISO DIZER, imagino, que o código acima é PSEUDO-CÓDIGO mais 
que qquer outra coisa, é só uma SUGESTÃO, não é de forma NENHUMA código pronto 
pra sair executando, okdoc ??
 
  []s
  
Chiappa

[oracle_br] Procedure com erro

2016-07-11 Por tôpico germanopac...@gmail.com [oracle_br]
Pessoal, 
 

 Quero identicar algumas tabelas com blocos corrompidos.
 Sei que posso usar o RMAN, com o commando backup validate e checar a view 
apropriada para ver os blocos corrompidos e depois através do RMAN mesmo 
corrigi-los.
 Mas a dúvida aqui é outra.
 

 Estou tentando utilizar a DBMS_REPAIR. Dei grant para o usuário, criei as 
tabelas REPAIR_TABLE e ORPHAN_KEY_TABLE e criei uma procedure para ler todas as 
tabelas. A procedure coloco abaixo:
 

 Porém ao executá-la, ela me retorna uma exceção -600 ,  pude perceber que o 
problema é na instrução "OBJECT_NAME => i.table_name ",  se coloco  
"OBJECT_NAME => 'nome_tabela' " ai funciona sem problemas, mas quero passar 
dinamicamente o nome das tabelas, para checar todas.
 

 Alguém teria alguma idéia?
 

 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
 SUSE Linux Enterprise Server 11 SP1  (x86_64)

 

 Obrigado
 

 Fernando
 

 

 

 CREATE OR REPLACE PROCEDURE proc030
 as

  num_corrupt INT;

 begin

 

 delete from cerv.log10 ;
 

 for i in(select table_name from user_tables where 1=1   and table_name 
not in ( select view_name from user_views)
   ) LOOP
  
   num_corrupt := 0;
  
   sys.DBMS_REPAIR.CHECK_OBJECT ( SCHEMA_NAME => 'CERV' ,  OBJECT_NAME => 
i.table_name  ,  REPAIR_TABLE_NAME => 'REPAIR_TABLE',  CORRUPT_COUNT =>  
num_corrupt);
 

   insert into cerv.log10(log) values ( i.table_name) ;

 end loop;
 

 

   EXCEPTION when others then
   dbms_output.put_line('procd004 '|| sqlcode );
 

 

 end;
 
 /
 

  


[oracle_br] Re: Monitoring Index

2016-07-11 Por tôpico carlosaama...@yahoo.com.br [oracle_br]
Olá a todos, bom dia !
 

 Grato pela sua atenção de sempre.
 

Um abraço,
 

 Carlos