Re: [oracle_br] ORA-07445: exception encountered: core dump

[Erik Castilho escasti...@gmail.com [oracle_br]]

Foi eu mesmo parceiro, eu só tinha me esquecido  dessa questão do SO, mas
independentemente não tem o suporte mesmo, estou levantando isso na Oracle
por completo.

Em 15 de mar de 2017 6:37 PM, "angelo angelolis...@gmail.com [oracle_br]" <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Sim,
>
> Infelizmente, quem instalou o servidor e o Oracle, não se ligou nesse
> pequeno detalhe... teria que fazer um upgrade nele também
>
>
>
> 2017-03-15 17:27 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br]
> :
>
>>
>>
>> CentOS 6 e a versão licenciada é a 11g mas o suporte realmente não foi
>> contrato no ato do licenciamento. Tem mais essa que realmente eu tinha
>> esquecido a Oracle homologa apenas RH, OEL e Suse, então usando CentOS
>> estou fora do suporte da Oracle mesmo que tivesse o suporte, certo?
>>
>> Em 15 de março de 2017 17:08, angelo angelolis...@gmail.com [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>
>>>
>>>
>>> Erik,
>>>
>>> Complemento da "bomba"... esse Linux é qual distribuição ? Se nao for
>>> RH, Suse ou a propria distribuicao da Oracle, o suporte da Oracle não
>>> suporta.. por nao ser homologado e tal..
>>>
>>> Se a empresa nao pagou o suporte desde que expirou, é isso mesmo.. vão
>>> cobrar um retroativo ou parte pra um novo licenciamento, porque fica tao
>>> caro que nem vale a pena.
>>>
>>> Agora se nunca foi licenciado... melhor não comentar nada e negociar o
>>> licenciamento direto.
>>>
>>>
>>>
>>> 2017-03-15 16:02 GMT-03:00 Erik Castilho escasti...@gmail.com
>>> [oracle_br] :
>>>


 Ricardo Arnoud, pois é sempre achei que essa história de homologar é
 balela pois pelo menos dessa empresa q eu sei o servidor do banco deles que
 talvez eles usam para essa homologação é em Windows, e eu aqui uso no
 Linux, ahhh...então a culpa é do Linux? rsss...paciência viu

 Já estou vendo essa questão do suporte da Oracle, mas o consultor da
 Oracle já me mandou que no caso eu vou ter que pagar o suporte retroativo
 do período que eu não renovei, estou esperando a "bomba".

 Primeira vez que esbarro em um bug, foi tenso mas foi bom.

 []'s

 Em 15 de março de 2017 15:25, Ricardo Arnoud ricardo...@gmail.com
 [oracle_br]  escreveu:

>
>
> Usar como argumento que o sistema foi homologado para a versão
> 11.2.0.1 é bengala, primeiramente esse ambiente deveria estar em uma 
> versão
> mais atual como por exemplo a 11.2.0.4. Para isso, se requer
> suporte/licenciamento.
>
> E amigo, parabéns pois você esbarrou em um bug.
>
> 2017-03-15 14:48 GMT-03:00 Erik Castilho escasti...@gmail.com
> [oracle_br] :
>
>>
>>
>> Boa tarde,
>>
>> Primeiramente obrigado pelas respostas de todos. O problema foi
>> solucionado, inicialmente setei o parâmetro 
>> set_optimizer_enable_extended_stats=false
>> conforme o colega sugeriu acima, depois rodei a aplicação novamente e 
>> deu o
>> erro. Posteriormente verifiquei os parâmetros 'shared_pool_size',
>> 'java_pool_size', 'large_pool_size' e todos estavam com 'Value=0', 
>> atribui
>> uns valores para cada um e depois alterei o parâmetro
>> "_optimizer_enable_extended_stats" para sessão novamente e deu certo.
>>
>> Tecnicamente não entendi a questão dos parâmetros acima, mas deu
>> certo, vou estudar mais para entender melhor essa situação, simular essa
>> situação mais vezes em ambiente de testes para tentar entender.
>>
>> Consultando um outro trace file pude verificar uma query gigantesca e
>> também chamadas para outras procedures que acredito ser dessa aplicação,
>> imaginei será que essa aplicação faz essa consulta desse tamanho? será 
>> que
>> não teria como otimizar isso? não estou fugindo da minha responsabilidade
>> com relação a empresa que presto serviço mas a software house 
>> simplesmente
>> jogou a 'bomba' pra cima do servidor e/ou da instalação do Oracle, tá 
>> certo
>> que foi uma questão de parâmetros, mas será que talvez a 'carga' de
>> consultas, chamadas e objetos utilizada nessa aplicação não ocasionou uma
>> excessiva carga no RDBMS que não suportou e cortava a conexão com a
>> aplicação? Pois a perda de conexão era apenas nessa aplicação pois outras
>> aplicações e módulos do mesmo ERP continuavam funcionando normalmente.
>>
>> Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para
>> o sistema, dai eu pergunto, como que foi homologada 100% sendo que esta
>> ocorrendo este erro? fico com essas dúvidas e questionamentos que nunca 
>> vão
>> ser respondidos por parte deles, mas na hora de falar que a culpa tá no
>> banco ou no servidor é fácil né
>>
>> Mais uma vez obrigado a todos!
>>
>>
>>
>> Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>

Re: [oracle_br] ORA-07445: exception encountered: core dump

[angelo angelolis...@gmail.com [oracle_br]]

Sim,

Infelizmente, quem instalou o servidor e o Oracle, não se ligou nesse
pequeno detalhe... teria que fazer um upgrade nele também



2017-03-15 17:27 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> CentOS 6 e a versão licenciada é a 11g mas o suporte realmente não foi
> contrato no ato do licenciamento. Tem mais essa que realmente eu tinha
> esquecido a Oracle homologa apenas RH, OEL e Suse, então usando CentOS
> estou fora do suporte da Oracle mesmo que tivesse o suporte, certo?
>
> Em 15 de março de 2017 17:08, angelo angelolis...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Erik,
>>
>> Complemento da "bomba"... esse Linux é qual distribuição ? Se nao for RH,
>> Suse ou a propria distribuicao da Oracle, o suporte da Oracle não suporta..
>> por nao ser homologado e tal..
>>
>> Se a empresa nao pagou o suporte desde que expirou, é isso mesmo.. vão
>> cobrar um retroativo ou parte pra um novo licenciamento, porque fica tao
>> caro que nem vale a pena.
>>
>> Agora se nunca foi licenciado... melhor não comentar nada e negociar o
>> licenciamento direto.
>>
>>
>>
>> 2017-03-15 16:02 GMT-03:00 Erik Castilho escasti...@gmail.com
>> [oracle_br] :
>>
>>>
>>>
>>> Ricardo Arnoud, pois é sempre achei que essa história de homologar é
>>> balela pois pelo menos dessa empresa q eu sei o servidor do banco deles que
>>> talvez eles usam para essa homologação é em Windows, e eu aqui uso no
>>> Linux, ahhh...então a culpa é do Linux? rsss...paciência viu
>>>
>>> Já estou vendo essa questão do suporte da Oracle, mas o consultor da
>>> Oracle já me mandou que no caso eu vou ter que pagar o suporte retroativo
>>> do período que eu não renovei, estou esperando a "bomba".
>>>
>>> Primeira vez que esbarro em um bug, foi tenso mas foi bom.
>>>
>>> []'s
>>>
>>> Em 15 de março de 2017 15:25, Ricardo Arnoud ricardo...@gmail.com
>>> [oracle_br]  escreveu:
>>>


 Usar como argumento que o sistema foi homologado para a versão 11.2.0.1
 é bengala, primeiramente esse ambiente deveria estar em uma versão mais
 atual como por exemplo a 11.2.0.4. Para isso, se requer
 suporte/licenciamento.

 E amigo, parabéns pois você esbarrou em um bug.

 2017-03-15 14:48 GMT-03:00 Erik Castilho escasti...@gmail.com
 [oracle_br] :

>
>
> Boa tarde,
>
> Primeiramente obrigado pelas respostas de todos. O problema foi
> solucionado, inicialmente setei o parâmetro 
> set_optimizer_enable_extended_stats=false
> conforme o colega sugeriu acima, depois rodei a aplicação novamente e deu 
> o
> erro. Posteriormente verifiquei os parâmetros 'shared_pool_size',
> 'java_pool_size', 'large_pool_size' e todos estavam com 'Value=0', atribui
> uns valores para cada um e depois alterei o parâmetro
> "_optimizer_enable_extended_stats" para sessão novamente e deu certo.
>
> Tecnicamente não entendi a questão dos parâmetros acima, mas deu
> certo, vou estudar mais para entender melhor essa situação, simular essa
> situação mais vezes em ambiente de testes para tentar entender.
>
> Consultando um outro trace file pude verificar uma query gigantesca e
> também chamadas para outras procedures que acredito ser dessa aplicação,
> imaginei será que essa aplicação faz essa consulta desse tamanho? será que
> não teria como otimizar isso? não estou fugindo da minha responsabilidade
> com relação a empresa que presto serviço mas a software house simplesmente
> jogou a 'bomba' pra cima do servidor e/ou da instalação do Oracle, tá 
> certo
> que foi uma questão de parâmetros, mas será que talvez a 'carga' de
> consultas, chamadas e objetos utilizada nessa aplicação não ocasionou uma
> excessiva carga no RDBMS que não suportou e cortava a conexão com a
> aplicação? Pois a perda de conexão era apenas nessa aplicação pois outras
> aplicações e módulos do mesmo ERP continuavam funcionando normalmente.
>
> Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para o
> sistema, dai eu pergunto, como que foi homologada 100% sendo que esta
> ocorrendo este erro? fico com essas dúvidas e questionamentos que nunca 
> vão
> ser respondidos por parte deles, mas na hora de falar que a culpa tá no
> banco ou no servidor é fácil né
>
> Mais uma vez obrigado a todos!
>
>
>
> Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Erik, um ponto adicional : como vc está tendo uma parada
>> completamente inesperada de um processo no Oracle, *** não é Incomum ***
>> que coisas que deveriam estar gravadas não o estejam, ou algo assim, se o
>> processo estiver sendo interrompido antes de gravar o necessário, 
>> levando á
>> ** CORRUPÇÃO ** ...
>>  ENtão, além de tentar um work-around se 

Re: [oracle_br] ORA-07445: exception encountered: core dump

[angelo angelolis...@gmail.com [oracle_br]]

Erik

Z Linux é pra mainframe ibm

https://en.wikipedia.org/wiki/Linux_on_z_Systems




2017-03-15 16:44 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Chiappa, é realmente não esta solucionado vc tá certo, foi apenas
> utilizado uma forma paliativa para tratar a situação nesse momento já estou
> vendo essa questão das versões superiores.
>
> No site da Oracle tem a versão 11.2.0.2.0 para arquitetura zLinux64, o
> que é essa zLinux64? Seria possível o download de releases mais recentes do
> 11g?
>
> []'s
>
> Em 15 de março de 2017 16:04, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Opa : então, lamento dizer mas vc *** não *** solucionou o problema : se
>> o BUG era causado por um parãmetro absolutamente válido setado de maneira
>> correta mas causando issues, o ** código ** do RDBMS que manipula esse
>> setting tá com bug, não usando o parâmetro vc apenas ** EVITOU ** o
>> problema, isso Não é Solução, é um Contorno apenas. Inclusive, bugs do
>> tipo são normalmente RAPIDAMENTE solucionados nos patchsets seguintes (o
>> mais recente é o que deixa o banco na versão 11.2.0.4.x), então aplicar o
>> patchset mais recente em cima desse 11.2.0.1 que vc tem não só solucionaria
>> este mas OUTROS possíveis bugs também, pelo jeito ESTA seria a ** SOLUÇÃO
>> ** para vc
>>  Para responder a sua pergunta, provavelmente quando o fornecedor do ERP
>> homologou o produto deles no 11.2.0.1 simplesmente ou usou um volume de
>> dados muito inferior OU simplesmente não estava com o parâmetro que dispara
>> o bug setado, simples assim, por isso ele não caiu no bug
>>
>>  Outra coisa, ainda que eles tenham feito uma Homologação no 11.2.0.1, a
>> cada vez que a Oracle solta um patchset grande em tese é ** OBRIGAÇÂO ** do
>> fornecedor avaliar/re-homologar : só pra vc ter uma idéia,
>> https://juliandontcheff.wordpress.com/2013/08/28/oracle-
>> database-11-2-0-4-new-features/ lista que até a versão  11.2.0.4 foram
>> consertados coisa de 5 mil bugs : não rola dizer que tem que ficar na
>> 11.2.0.1 por causa do raio do fornecedor e ficar sujeito a cair a qualquer
>> momento em um dos 5 mil, né não ?? ACho bem difícil se trabalhar assim em
>> Produção, pra dizer o mínimo ...
>>
>>  []s
>>
>>Chiappa
>>
>
> 
>

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Erik Castilho escasti...@gmail.com [oracle_br]]

Chiappa, é realmente não esta solucionado vc tá certo, foi apenas utilizado
uma forma paliativa para tratar a situação nesse momento já estou vendo
essa questão das versões superiores.

No site da Oracle tem a versão 11.2.0.2.0 para arquitetura zLinux64, o que
é essa zLinux64? Seria possível o download de releases mais recentes do 11g?

[]'s

Em 15 de março de 2017 16:04, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Opa : então, lamento dizer mas vc *** não *** solucionou o problema : se o
> BUG era causado por um parãmetro absolutamente válido setado de maneira
> correta mas causando issues, o ** código ** do RDBMS que manipula esse
> setting tá com bug, não usando o parâmetro vc apenas ** EVITOU ** o
> problema, isso Não é Solução, é um Contorno apenas. Inclusive, bugs do
> tipo são normalmente RAPIDAMENTE solucionados nos patchsets seguintes (o
> mais recente é o que deixa o banco na versão 11.2.0.4.x), então aplicar o
> patchset mais recente em cima desse 11.2.0.1 que vc tem não só solucionaria
> este mas OUTROS possíveis bugs também, pelo jeito ESTA seria a ** SOLUÇÃO
> ** para vc
>  Para responder a sua pergunta, provavelmente quando o fornecedor do ERP
> homologou o produto deles no 11.2.0.1 simplesmente ou usou um volume de
> dados muito inferior OU simplesmente não estava com o parâmetro que dispara
> o bug setado, simples assim, por isso ele não caiu no bug
>
>  Outra coisa, ainda que eles tenham feito uma Homologação no 11.2.0.1, a
> cada vez que a Oracle solta um patchset grande em tese é ** OBRIGAÇÂO ** do
> fornecedor avaliar/re-homologar : só pra vc ter uma idéia,
> https://juliandontcheff.wordpress.com/2013/08/28/
> oracle-database-11-2-0-4-new-features/ lista que até a versão  11.2.0.4
> foram consertados coisa de 5 mil bugs : não rola dizer que tem que ficar na
> 11.2.0.1 por causa do raio do fornecedor e ficar sujeito a cair a qualquer
> momento em um dos 5 mil, né não ?? ACho bem difícil se trabalhar assim em
> Produção, pra dizer o mínimo ...
>
>  []s
>
>Chiappa
> 
>

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Tércio Costa terciosilvaco...@gmail.com [oracle_br]]

Acredito que esteja correto.




Em 15 de março de 2017 17:27, Erik Castilho escasti...@gmail.com
[oracle_br]  escreveu:

>
>
> CentOS 6 e a versão licenciada é a 11g mas o suporte realmente não foi
> contrato no ato do licenciamento. Tem mais essa que realmente eu tinha
> esquecido a Oracle homologa apenas RH, OEL e Suse, então usando CentOS
> estou fora do suporte da Oracle mesmo que tivesse o suporte, certo?
>
> Em 15 de março de 2017 17:08, angelo angelolis...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Erik,
>>
>> Complemento da "bomba"... esse Linux é qual distribuição ? Se nao for RH,
>> Suse ou a propria distribuicao da Oracle, o suporte da Oracle não suporta..
>> por nao ser homologado e tal..
>>
>> Se a empresa nao pagou o suporte desde que expirou, é isso mesmo.. vão
>> cobrar um retroativo ou parte pra um novo licenciamento, porque fica tao
>> caro que nem vale a pena.
>>
>> Agora se nunca foi licenciado... melhor não comentar nada e negociar o
>> licenciamento direto.
>>
>>
>>
>> 2017-03-15 16:02 GMT-03:00 Erik Castilho escasti...@gmail.com
>> [oracle_br] :
>>
>>>
>>>
>>> Ricardo Arnoud, pois é sempre achei que essa história de homologar é
>>> balela pois pelo menos dessa empresa q eu sei o servidor do banco deles que
>>> talvez eles usam para essa homologação é em Windows, e eu aqui uso no
>>> Linux, ahhh...então a culpa é do Linux? rsss...paciência viu
>>>
>>> Já estou vendo essa questão do suporte da Oracle, mas o consultor da
>>> Oracle já me mandou que no caso eu vou ter que pagar o suporte retroativo
>>> do período que eu não renovei, estou esperando a "bomba".
>>>
>>> Primeira vez que esbarro em um bug, foi tenso mas foi bom.
>>>
>>> []'s
>>>
>>> Em 15 de março de 2017 15:25, Ricardo Arnoud ricardo...@gmail.com
>>> [oracle_br]  escreveu:
>>>


 Usar como argumento que o sistema foi homologado para a versão 11.2.0.1
 é bengala, primeiramente esse ambiente deveria estar em uma versão mais
 atual como por exemplo a 11.2.0.4. Para isso, se requer
 suporte/licenciamento.

 E amigo, parabéns pois você esbarrou em um bug.

 2017-03-15 14:48 GMT-03:00 Erik Castilho escasti...@gmail.com
 [oracle_br] :

>
>
> Boa tarde,
>
> Primeiramente obrigado pelas respostas de todos. O problema foi
> solucionado, inicialmente setei o parâmetro 
> set_optimizer_enable_extended_stats=false
> conforme o colega sugeriu acima, depois rodei a aplicação novamente e deu 
> o
> erro. Posteriormente verifiquei os parâmetros 'shared_pool_size',
> 'java_pool_size', 'large_pool_size' e todos estavam com 'Value=0', atribui
> uns valores para cada um e depois alterei o parâmetro
> "_optimizer_enable_extended_stats" para sessão novamente e deu certo.
>
> Tecnicamente não entendi a questão dos parâmetros acima, mas deu
> certo, vou estudar mais para entender melhor essa situação, simular essa
> situação mais vezes em ambiente de testes para tentar entender.
>
> Consultando um outro trace file pude verificar uma query gigantesca e
> também chamadas para outras procedures que acredito ser dessa aplicação,
> imaginei será que essa aplicação faz essa consulta desse tamanho? será que
> não teria como otimizar isso? não estou fugindo da minha responsabilidade
> com relação a empresa que presto serviço mas a software house simplesmente
> jogou a 'bomba' pra cima do servidor e/ou da instalação do Oracle, tá 
> certo
> que foi uma questão de parâmetros, mas será que talvez a 'carga' de
> consultas, chamadas e objetos utilizada nessa aplicação não ocasionou uma
> excessiva carga no RDBMS que não suportou e cortava a conexão com a
> aplicação? Pois a perda de conexão era apenas nessa aplicação pois outras
> aplicações e módulos do mesmo ERP continuavam funcionando normalmente.
>
> Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para o
> sistema, dai eu pergunto, como que foi homologada 100% sendo que esta
> ocorrendo este erro? fico com essas dúvidas e questionamentos que nunca 
> vão
> ser respondidos por parte deles, mas na hora de falar que a culpa tá no
> banco ou no servidor é fácil né
>
> Mais uma vez obrigado a todos!
>
>
>
> Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Erik, um ponto adicional : como vc está tendo uma parada
>> completamente inesperada de um processo no Oracle, *** não é Incomum ***
>> que coisas que deveriam estar gravadas não o estejam, ou algo assim, se o
>> processo estiver sendo interrompido antes de gravar o necessário, 
>> levando á
>> ** CORRUPÇÃO ** ...
>>  ENtão, além de tentar um work-around se não puder fazer a análise de
>> correção, eu RECOMENDO que vc (ou o DBA encarregado) faça os 
>> procedimentos

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Erik Castilho escasti...@gmail.com [oracle_br]]

CentOS 6 e a versão licenciada é a 11g mas o suporte realmente não foi
contrato no ato do licenciamento. Tem mais essa que realmente eu tinha
esquecido a Oracle homologa apenas RH, OEL e Suse, então usando CentOS
estou fora do suporte da Oracle mesmo que tivesse o suporte, certo?

Em 15 de março de 2017 17:08, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Erik,
>
> Complemento da "bomba"... esse Linux é qual distribuição ? Se nao for RH,
> Suse ou a propria distribuicao da Oracle, o suporte da Oracle não suporta..
> por nao ser homologado e tal..
>
> Se a empresa nao pagou o suporte desde que expirou, é isso mesmo.. vão
> cobrar um retroativo ou parte pra um novo licenciamento, porque fica tao
> caro que nem vale a pena.
>
> Agora se nunca foi licenciado... melhor não comentar nada e negociar o
> licenciamento direto.
>
>
>
> 2017-03-15 16:02 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br]
> :
>
>>
>>
>> Ricardo Arnoud, pois é sempre achei que essa história de homologar é
>> balela pois pelo menos dessa empresa q eu sei o servidor do banco deles que
>> talvez eles usam para essa homologação é em Windows, e eu aqui uso no
>> Linux, ahhh...então a culpa é do Linux? rsss...paciência viu
>>
>> Já estou vendo essa questão do suporte da Oracle, mas o consultor da
>> Oracle já me mandou que no caso eu vou ter que pagar o suporte retroativo
>> do período que eu não renovei, estou esperando a "bomba".
>>
>> Primeira vez que esbarro em um bug, foi tenso mas foi bom.
>>
>> []'s
>>
>> Em 15 de março de 2017 15:25, Ricardo Arnoud ricardo...@gmail.com
>> [oracle_br]  escreveu:
>>
>>>
>>>
>>> Usar como argumento que o sistema foi homologado para a versão 11.2.0.1
>>> é bengala, primeiramente esse ambiente deveria estar em uma versão mais
>>> atual como por exemplo a 11.2.0.4. Para isso, se requer
>>> suporte/licenciamento.
>>>
>>> E amigo, parabéns pois você esbarrou em um bug.
>>>
>>> 2017-03-15 14:48 GMT-03:00 Erik Castilho escasti...@gmail.com
>>> [oracle_br] :
>>>


 Boa tarde,

 Primeiramente obrigado pelas respostas de todos. O problema foi
 solucionado, inicialmente setei o parâmetro 
 set_optimizer_enable_extended_stats=false
 conforme o colega sugeriu acima, depois rodei a aplicação novamente e deu o
 erro. Posteriormente verifiquei os parâmetros 'shared_pool_size',
 'java_pool_size', 'large_pool_size' e todos estavam com 'Value=0', atribui
 uns valores para cada um e depois alterei o parâmetro
 "_optimizer_enable_extended_stats" para sessão novamente e deu certo.

 Tecnicamente não entendi a questão dos parâmetros acima, mas deu certo,
 vou estudar mais para entender melhor essa situação, simular essa situação
 mais vezes em ambiente de testes para tentar entender.

 Consultando um outro trace file pude verificar uma query gigantesca e
 também chamadas para outras procedures que acredito ser dessa aplicação,
 imaginei será que essa aplicação faz essa consulta desse tamanho? será que
 não teria como otimizar isso? não estou fugindo da minha responsabilidade
 com relação a empresa que presto serviço mas a software house simplesmente
 jogou a 'bomba' pra cima do servidor e/ou da instalação do Oracle, tá certo
 que foi uma questão de parâmetros, mas será que talvez a 'carga' de
 consultas, chamadas e objetos utilizada nessa aplicação não ocasionou uma
 excessiva carga no RDBMS que não suportou e cortava a conexão com a
 aplicação? Pois a perda de conexão era apenas nessa aplicação pois outras
 aplicações e módulos do mesmo ERP continuavam funcionando normalmente.

 Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para o
 sistema, dai eu pergunto, como que foi homologada 100% sendo que esta
 ocorrendo este erro? fico com essas dúvidas e questionamentos que nunca vão
 ser respondidos por parte deles, mas na hora de falar que a culpa tá no
 banco ou no servidor é fácil né

 Mais uma vez obrigado a todos!



 Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] <
 oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Erik, um ponto adicional : como vc está tendo uma parada completamente
> inesperada de um processo no Oracle, *** não é Incomum *** que coisas que
> deveriam estar gravadas não o estejam, ou algo assim, se o processo 
> estiver
> sendo interrompido antes de gravar o necessário, levando á ** CORRUPÇÃO **
> ...
>  ENtão, além de tentar um work-around se não puder fazer a análise de
> correção, eu RECOMENDO que vc (ou o DBA encarregado) faça os procedimentos
> de HEALTHCHECK e Verificação de Integridade desse banco, o quanto 
> antes
>
> []s
>
>   Chiappa
>


>>>
>>>
>>> --
>>> --
>>> Thanks,
>>> * Ricardo Arnoud*
>>>
>>>
>>>
>>>
>>>
>>>
>>> Porto Alegre - RS
>>> http://www.queroaprenderli

Re: [oracle_br] ORA-07445: exception encountered: core dump

[angelo angelolis...@gmail.com [oracle_br]]

Erik,

Complemento da "bomba"... esse Linux é qual distribuição ? Se nao for RH,
Suse ou a propria distribuicao da Oracle, o suporte da Oracle não suporta..
por nao ser homologado e tal..

Se a empresa nao pagou o suporte desde que expirou, é isso mesmo.. vão
cobrar um retroativo ou parte pra um novo licenciamento, porque fica tao
caro que nem vale a pena.

Agora se nunca foi licenciado... melhor não comentar nada e negociar o
licenciamento direto.



2017-03-15 16:02 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Ricardo Arnoud, pois é sempre achei que essa história de homologar é
> balela pois pelo menos dessa empresa q eu sei o servidor do banco deles que
> talvez eles usam para essa homologação é em Windows, e eu aqui uso no
> Linux, ahhh...então a culpa é do Linux? rsss...paciência viu
>
> Já estou vendo essa questão do suporte da Oracle, mas o consultor da
> Oracle já me mandou que no caso eu vou ter que pagar o suporte retroativo
> do período que eu não renovei, estou esperando a "bomba".
>
> Primeira vez que esbarro em um bug, foi tenso mas foi bom.
>
> []'s
>
> Em 15 de março de 2017 15:25, Ricardo Arnoud ricardo...@gmail.com
> [oracle_br]  escreveu:
>
>>
>>
>> Usar como argumento que o sistema foi homologado para a versão 11.2.0.1 é
>> bengala, primeiramente esse ambiente deveria estar em uma versão mais atual
>> como por exemplo a 11.2.0.4. Para isso, se requer suporte/licenciamento.
>>
>> E amigo, parabéns pois você esbarrou em um bug.
>>
>> 2017-03-15 14:48 GMT-03:00 Erik Castilho escasti...@gmail.com
>> [oracle_br] :
>>
>>>
>>>
>>> Boa tarde,
>>>
>>> Primeiramente obrigado pelas respostas de todos. O problema foi
>>> solucionado, inicialmente setei o parâmetro 
>>> set_optimizer_enable_extended_stats=false
>>> conforme o colega sugeriu acima, depois rodei a aplicação novamente e deu o
>>> erro. Posteriormente verifiquei os parâmetros 'shared_pool_size',
>>> 'java_pool_size', 'large_pool_size' e todos estavam com 'Value=0', atribui
>>> uns valores para cada um e depois alterei o parâmetro
>>> "_optimizer_enable_extended_stats" para sessão novamente e deu certo.
>>>
>>> Tecnicamente não entendi a questão dos parâmetros acima, mas deu certo,
>>> vou estudar mais para entender melhor essa situação, simular essa situação
>>> mais vezes em ambiente de testes para tentar entender.
>>>
>>> Consultando um outro trace file pude verificar uma query gigantesca e
>>> também chamadas para outras procedures que acredito ser dessa aplicação,
>>> imaginei será que essa aplicação faz essa consulta desse tamanho? será que
>>> não teria como otimizar isso? não estou fugindo da minha responsabilidade
>>> com relação a empresa que presto serviço mas a software house simplesmente
>>> jogou a 'bomba' pra cima do servidor e/ou da instalação do Oracle, tá certo
>>> que foi uma questão de parâmetros, mas será que talvez a 'carga' de
>>> consultas, chamadas e objetos utilizada nessa aplicação não ocasionou uma
>>> excessiva carga no RDBMS que não suportou e cortava a conexão com a
>>> aplicação? Pois a perda de conexão era apenas nessa aplicação pois outras
>>> aplicações e módulos do mesmo ERP continuavam funcionando normalmente.
>>>
>>> Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para o
>>> sistema, dai eu pergunto, como que foi homologada 100% sendo que esta
>>> ocorrendo este erro? fico com essas dúvidas e questionamentos que nunca vão
>>> ser respondidos por parte deles, mas na hora de falar que a culpa tá no
>>> banco ou no servidor é fácil né
>>>
>>> Mais uma vez obrigado a todos!
>>>
>>>
>>>
>>> Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] <
>>> oracle_br@yahoogrupos.com.br> escreveu:
>>>


 Erik, um ponto adicional : como vc está tendo uma parada completamente
 inesperada de um processo no Oracle, *** não é Incomum *** que coisas que
 deveriam estar gravadas não o estejam, ou algo assim, se o processo estiver
 sendo interrompido antes de gravar o necessário, levando á ** CORRUPÇÃO **
 ...
  ENtão, além de tentar um work-around se não puder fazer a análise de
 correção, eu RECOMENDO que vc (ou o DBA encarregado) faça os procedimentos
 de HEALTHCHECK e Verificação de Integridade desse banco, o quanto antes

 []s

   Chiappa

>>>
>>>
>>
>>
>> --
>> --
>> Thanks,
>> * Ricardo Arnoud*
>>
>>
>>
>>
>>
>>
>> Porto Alegre - RS
>> http://www.queroaprenderlinux.com.br
>> http://www.peritodigitalonline.com.br
>>
>>
> 
>

Re: [oracle_br] Desaster Recovery

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

Carlos,
  Acho que fiz a conta errada :-):
   List of Archived Logs in backup set 25  Thrd Seq     Low SCN    Low Time  
Next SCN   Next Time   --- -- - -- -  1 
   72      2797947    15-MAR-17 2798016    15-MAR-17
   Tenta o recover until scn 2798015.
   Antigamente, o backup database plus archivelog all não pegava todos os 
archives necessários para fazer um recover, então eu sempre fazia primeiro um 
"backup database", depois um "sql 'alter system archive log current'" e um 
backup archivelog all.
   Mas acho que esse problema foi resolvido na 11g. 
   O "until sequence" talvez tenha que ser até a sequencia 73 em vez de 72 :-).
Atc,Luis Freitas 

On Wednesday, March 15, 2017 4:21 PM, "carloseduard...@yahoo.com 
[oracle_br]"  wrote:
 

     O que deu a entender eh o seguinte:

Meus datafiles, após o restore, estão em um SCN 2797971.
O meu ultimo archive log disponivel possui o SCN 2798015 (next SCN - 1). E 
quando executo um recover, ele diz que eu preciso restaurar os meus datafiles 
de um SCN anterior ao 2797947.
Portanto, o ultimo backupset nao seria o ideal para recuperar o database? 
EU sempre fiz restore/recover inumeras vezes, mas esse cenario especifico estou 
tendo dificuldades para resolver.

 

Em Quarta-feira, 15 de Março de 2017 16:07, "carloseduard...@yahoo.com" 
 escreveu:
 

 Chiappa, respondendo seus questionamentos...
EM relação aos SCN/sequence do database, passei as informações necessárias, o 
estado da sequence antes da realização do backup, a localização dos backup sets 
dos datafiles, controlfiles e archives, informações do SCN e das sequences dos 
bakups dos datafiles e dos archives logs. Está tudo listado no cenário passado. 
Inclusive no restore database, ele mostra que o backup que está sendo 
restaurado foi o que realizei no exemplo, informando o backup set do dia 15, 
que eh o comportamento padrao sempre pegar o ultimo backup full como voce mesmo 
ja sabe.
Em relação da deletar backups anteriores, vc vai me desculpar, mas eu descordo 
de vc nesse ponto. Se por acaso, um backup set mais novo estivesse corrompido, 
eu nao poderia voltar um backup mais antigo, pelo simples fato de eu ter 
deletado os backups atenreiores, portanto eu prefiro deixar todo backup dentro 
da politica de retenção guardado.

Luis Freitas:
SQL> select file#, status, recover, checkpoint_change# from v$datafile_header;
     FILE# STATUS  REC CHECKPOINT_CHANGE#-- --- --- 
--  1 ONLINE   2797971  3 ONLINE   2797971  4 ONLINE   2797971  
5 ONLINE   2797971  6 ONLINE   2797971  7 ONLINE   2797971

RMAN> recover database until sequence 72 thread 1;
Starting recover at 15-MAR-17allocated channel: ORA_DISK_1channel ORA_DISK_1: 
SID=12 device type=DISKRMAN-00571: 
===RMAN-00569: 
=== ERROR MESSAGE STACK FOLLOWS ===RMAN-00571: 
===RMAN-03002: failure 
of recover command at 03/15/2017 16:06:50RMAN-06556: datafile 1 must be 
restored from backup older than SCN 2797947





 

Em Quarta-feira, 15 de Março de 2017 15:00, "carloseduard...@yahoo.com 
[oracle_br]"  escreveu:
 

     Pessoal, o backup que fiz, foi um backup HOT, com o database em estado 
OPEN, ok?
O que quis dizer com INSTANCE em SHUTDOWN, eh que na hora do restore/recovery o 
database estava em shutdown, ate pq foram deletados todos os datafiles do banco 
e consequentemente a instance estava em shutdown na hora do restore/recovery. 
Mas que o backup foi realizado com o database aberto, backup HOT. 

Em Quarta-feira, 15 de Março de 2017 13:12, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     "
 se entendi direito, você fez um backup 'cold'
"

==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e 
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles 
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas 
internas  em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER 
de um database que já está íntegro, sim

Se não for COLD, eu reforço também a necessidade de vc consultar 
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode 
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW 
antes da coisa real, sim...

[]s

  Chiappa  

 

   

 #yiv7468412983 #yiv7468412983 -- #yiv7468412983ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7468412983 
#yiv7468412983ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7468412983 
#yiv7468412983ygrp-mkp #yiv7468412983hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7468412983 #yiv7468412983ygrp-mkp #yiv7468412983ads 
{margin-bottom:10px;}#yiv7468412983 #yiv7468412983ygrp-mkp .yiv7468412983ad 
{padding:0 0;}#yiv7468412983 #yiv7468412983ygrp-mkp .yiv7468412983ad p 
{margin:0;}#yiv746841

Re: [oracle_br] Desaster Recovery

[carloseduard...@yahoo.com [oracle_br]]

O que deu a entender eh o seguinte:

Meus datafiles, após o restore, estão em um SCN 2797971.
O meu ultimo archive log disponivel possui o SCN 2798015 (next SCN - 1). E 
quando executo um recover, ele diz que eu preciso restaurar os meus datafiles 
de um SCN anterior ao 2797947.
Portanto, o ultimo backupset nao seria o ideal para recuperar o database? 
EU sempre fiz restore/recover inumeras vezes, mas esse cenario especifico estou 
tendo dificuldades para resolver.

 

Em Quarta-feira, 15 de Março de 2017 16:07, "carloseduard...@yahoo.com" 
 escreveu:
 

 Chiappa, respondendo seus questionamentos...
EM relação aos SCN/sequence do database, passei as informações necessárias, o 
estado da sequence antes da realização do backup, a localização dos backup sets 
dos datafiles, controlfiles e archives, informações do SCN e das sequences dos 
bakups dos datafiles e dos archives logs. Está tudo listado no cenário passado. 
Inclusive no restore database, ele mostra que o backup que está sendo 
restaurado foi o que realizei no exemplo, informando o backup set do dia 15, 
que eh o comportamento padrao sempre pegar o ultimo backup full como voce mesmo 
ja sabe.
Em relação da deletar backups anteriores, vc vai me desculpar, mas eu descordo 
de vc nesse ponto. Se por acaso, um backup set mais novo estivesse corrompido, 
eu nao poderia voltar um backup mais antigo, pelo simples fato de eu ter 
deletado os backups atenreiores, portanto eu prefiro deixar todo backup dentro 
da politica de retenção guardado.

Luis Freitas:
SQL> select file#, status, recover, checkpoint_change# from v$datafile_header;
     FILE# STATUS  REC CHECKPOINT_CHANGE#-- --- --- 
--  1 ONLINE   2797971  3 ONLINE   2797971  4 ONLINE   2797971  
5 ONLINE   2797971  6 ONLINE   2797971  7 ONLINE   2797971

RMAN> recover database until sequence 72 thread 1;
Starting recover at 15-MAR-17allocated channel: ORA_DISK_1channel ORA_DISK_1: 
SID=12 device type=DISKRMAN-00571: 
===RMAN-00569: 
=== ERROR MESSAGE STACK FOLLOWS ===RMAN-00571: 
===RMAN-03002: failure 
of recover command at 03/15/2017 16:06:50RMAN-06556: datafile 1 must be 
restored from backup older than SCN 2797947





 

Em Quarta-feira, 15 de Março de 2017 15:00, "carloseduard...@yahoo.com 
[oracle_br]"  escreveu:
 

     Pessoal, o backup que fiz, foi um backup HOT, com o database em estado 
OPEN, ok?
O que quis dizer com INSTANCE em SHUTDOWN, eh que na hora do restore/recovery o 
database estava em shutdown, ate pq foram deletados todos os datafiles do banco 
e consequentemente a instance estava em shutdown na hora do restore/recovery. 
Mas que o backup foi realizado com o database aberto, backup HOT. 

Em Quarta-feira, 15 de Março de 2017 13:12, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     "
 se entendi direito, você fez um backup 'cold'
"

==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e 
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles 
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas 
internas  em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER 
de um database que já está íntegro, sim

Se não for COLD, eu reforço também a necessidade de vc consultar 
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode 
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW 
antes da coisa real, sim...

[]s

  Chiappa  

 #yiv1968297007 -- #yiv1968297007ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1968297007 
#yiv1968297007ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1968297007 
#yiv1968297007ygrp-mkp #yiv1968297007hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv1968297007 #yiv1968297007ygrp-mkp #yiv1968297007ads 
{margin-bottom:10px;}#yiv1968297007 #yiv1968297007ygrp-mkp .yiv1968297007ad 
{padding:0 0;}#yiv1968297007 #yiv1968297007ygrp-mkp .yiv1968297007ad p 
{margin:0;}#yiv1968297007 #yiv1968297007ygrp-mkp .yiv1968297007ad a 
{color:#ff;text-decoration:none;}#yiv1968297007 #yiv1968297007ygrp-sponsor 
#yiv1968297007ygrp-lc {font-family:Arial;}#yiv1968297007 
#yiv1968297007ygrp-sponsor #yiv1968297007ygrp-lc #yiv1968297007hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1968297007 
#yiv1968297007ygrp-sponsor #yiv1968297007ygrp-lc .yiv1968297007ad 
{margin-bottom:10px;padding:0 0;}#yiv1968297007 #yiv1968297007actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1968297007 
#yiv1968297007activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1968297007
 #yiv1968297007activity span {font-weight:700;}#yiv1968297007 
#yiv1968297007activity span:first-child 
{text-transform:uppercase;}#yiv1968297007 #yiv196829700

Re: [oracle_br] Desaster Recovery

[carloseduard...@yahoo.com [oracle_br]]

Chiappa, respondendo seus questionamentos...
EM relação aos SCN/sequence do database, passei as informações necessárias, o 
estado da sequence antes da realização do backup, a localização dos backup sets 
dos datafiles, controlfiles e archives, informações do SCN e das sequences dos 
bakups dos datafiles e dos archives logs. Está tudo listado no cenário passado. 
Inclusive no restore database, ele mostra que o backup que está sendo 
restaurado foi o que realizei no exemplo, informando o backup set do dia 15, 
que eh o comportamento padrao sempre pegar o ultimo backup full como voce mesmo 
ja sabe.
Em relação da deletar backups anteriores, vc vai me desculpar, mas eu descordo 
de vc nesse ponto. Se por acaso, um backup set mais novo estivesse corrompido, 
eu nao poderia voltar um backup mais antigo, pelo simples fato de eu ter 
deletado os backups atenreiores, portanto eu prefiro deixar todo backup dentro 
da politica de retenção guardado.

Luis Freitas:
SQL> select file#, status, recover, checkpoint_change# from v$datafile_header;
     FILE# STATUS  REC CHECKPOINT_CHANGE#-- --- --- 
--  1 ONLINE   2797971  3 ONLINE   2797971  4 ONLINE   2797971  
5 ONLINE   2797971  6 ONLINE   2797971  7 ONLINE   2797971

RMAN> recover database until sequence 72 thread 1;
Starting recover at 15-MAR-17allocated channel: ORA_DISK_1channel ORA_DISK_1: 
SID=12 device type=DISKRMAN-00571: 
===RMAN-00569: 
=== ERROR MESSAGE STACK FOLLOWS ===RMAN-00571: 
===RMAN-03002: failure 
of recover command at 03/15/2017 16:06:50RMAN-06556: datafile 1 must be 
restored from backup older than SCN 2797947





 

Em Quarta-feira, 15 de Março de 2017 15:00, "carloseduard...@yahoo.com 
[oracle_br]"  escreveu:
 

     Pessoal, o backup que fiz, foi um backup HOT, com o database em estado 
OPEN, ok?
O que quis dizer com INSTANCE em SHUTDOWN, eh que na hora do restore/recovery o 
database estava em shutdown, ate pq foram deletados todos os datafiles do banco 
e consequentemente a instance estava em shutdown na hora do restore/recovery. 
Mas que o backup foi realizado com o database aberto, backup HOT. 

Em Quarta-feira, 15 de Março de 2017 13:12, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     "
 se entendi direito, você fez um backup 'cold'
"

==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e 
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles 
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas 
internas  em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER 
de um database que já está íntegro, sim

Se não for COLD, eu reforço também a necessidade de vc consultar 
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode 
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW 
antes da coisa real, sim...

[]s

  Chiappa  

 #yiv9671287422 #yiv9671287422 -- #yiv9671287422ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9671287422 
#yiv9671287422ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9671287422 
#yiv9671287422ygrp-mkp #yiv9671287422hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9671287422 #yiv9671287422ygrp-mkp #yiv9671287422ads 
{margin-bottom:10px;}#yiv9671287422 #yiv9671287422ygrp-mkp .yiv9671287422ad 
{padding:0 0;}#yiv9671287422 #yiv9671287422ygrp-mkp .yiv9671287422ad p 
{margin:0;}#yiv9671287422 #yiv9671287422ygrp-mkp .yiv9671287422ad a 
{color:#ff;text-decoration:none;}#yiv9671287422 #yiv9671287422ygrp-sponsor 
#yiv9671287422ygrp-lc {font-family:Arial;}#yiv9671287422 
#yiv9671287422ygrp-sponsor #yiv9671287422ygrp-lc #yiv9671287422hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9671287422 
#yiv9671287422ygrp-sponsor #yiv9671287422ygrp-lc .yiv9671287422ad 
{margin-bottom:10px;padding:0 0;}#yiv9671287422 #yiv9671287422actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9671287422 
#yiv9671287422activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9671287422
 #yiv9671287422activity span {font-weight:700;}#yiv9671287422 
#yiv9671287422activity span:first-child 
{text-transform:uppercase;}#yiv9671287422 #yiv9671287422activity span a 
{color:#5085b6;text-decoration:none;}#yiv9671287422 #yiv9671287422activity span 
span {color:#ff7900;}#yiv9671287422 #yiv9671287422activity span 
.yiv9671287422underline {text-decoration:underline;}#yiv9671287422 
.yiv9671287422attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9671287422 .yiv9671287422attach div a 
{text-decoration:none;}#yiv9671287422 .yiv9671287422attach img 
{border:none;padding-right:5px;}#yiv9671287422 .yiv9671287422attach label 
{display:block;margin-botto

Re: [oracle_br] ORA-07445: exception encountered: core dump

[jlchia...@yahoo.com.br [oracle_br]]

Opa : então, lamento dizer mas vc *** não *** solucionou o problema : se o BUG 
era causado por um parãmetro absolutamente válido setado de maneira correta mas 
causando issues, o ** código ** do RDBMS que manipula esse setting tá com bug, 
não usando o parâmetro vc apenas ** EVITOU ** o problema, isso Não é Solução, é 
um Contorno apenas. Inclusive, bugs do tipo são normalmente RAPIDAMENTE 
solucionados nos patchsets seguintes (o mais recente é o que deixa o banco na 
versão 11.2.0.4.x), então aplicar o patchset mais recente em cima desse 
11.2.0.1 que vc tem não só solucionaria este mas OUTROS possíveis bugs também, 
pelo jeito ESTA seria a ** SOLUÇÃO ** para vc
 Para responder a sua pergunta, provavelmente quando o fornecedor do ERP 
homologou o produto deles no 11.2.0.1 simplesmente ou usou um volume de dados 
muito inferior OU simplesmente não estava com o parâmetro que dispara o bug 
setado, simples assim, por isso ele não caiu no bug 
 
 Outra coisa, ainda que eles tenham feito uma Homologação no 11.2.0.1, a cada 
vez que a Oracle solta um patchset grande em tese é ** OBRIGAÇÂO ** do 
fornecedor avaliar/re-homologar : só pra vc ter uma idéia, 
https://juliandontcheff.wordpress.com/2013/08/28/oracle-database-11-2-0-4-new-features/
 lista que até a versão  11.2.0.4 foram consertados coisa de 5 mil bugs : não 
rola dizer que tem que ficar na 11.2.0.1 por causa do raio do fornecedor e 
ficar sujeito a cair a qualquer momento em um dos 5 mil, né não ?? ACho bem 
difícil se trabalhar assim em Produção, pra dizer o mínimo ...
 
 []s
 
   Chiappa

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Erik Castilho escasti...@gmail.com [oracle_br]]

Ricardo Arnoud, pois é sempre achei que essa história de homologar é balela
pois pelo menos dessa empresa q eu sei o servidor do banco deles que talvez
eles usam para essa homologação é em Windows, e eu aqui uso no Linux,
ahhh...então a culpa é do Linux? rsss...paciência viu

Já estou vendo essa questão do suporte da Oracle, mas o consultor da Oracle
já me mandou que no caso eu vou ter que pagar o suporte retroativo do
período que eu não renovei, estou esperando a "bomba".

Primeira vez que esbarro em um bug, foi tenso mas foi bom.

[]'s

Em 15 de março de 2017 15:25, Ricardo Arnoud ricardo...@gmail.com
[oracle_br]  escreveu:

>
>
> Usar como argumento que o sistema foi homologado para a versão 11.2.0.1 é
> bengala, primeiramente esse ambiente deveria estar em uma versão mais atual
> como por exemplo a 11.2.0.4. Para isso, se requer suporte/licenciamento.
>
> E amigo, parabéns pois você esbarrou em um bug.
>
> 2017-03-15 14:48 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br]
> :
>
>>
>>
>> Boa tarde,
>>
>> Primeiramente obrigado pelas respostas de todos. O problema foi
>> solucionado, inicialmente setei o parâmetro 
>> set_optimizer_enable_extended_stats=false
>> conforme o colega sugeriu acima, depois rodei a aplicação novamente e deu o
>> erro. Posteriormente verifiquei os parâmetros 'shared_pool_size',
>> 'java_pool_size', 'large_pool_size' e todos estavam com 'Value=0', atribui
>> uns valores para cada um e depois alterei o parâmetro
>> "_optimizer_enable_extended_stats" para sessão novamente e deu certo.
>>
>> Tecnicamente não entendi a questão dos parâmetros acima, mas deu certo,
>> vou estudar mais para entender melhor essa situação, simular essa situação
>> mais vezes em ambiente de testes para tentar entender.
>>
>> Consultando um outro trace file pude verificar uma query gigantesca e
>> também chamadas para outras procedures que acredito ser dessa aplicação,
>> imaginei será que essa aplicação faz essa consulta desse tamanho? será que
>> não teria como otimizar isso? não estou fugindo da minha responsabilidade
>> com relação a empresa que presto serviço mas a software house simplesmente
>> jogou a 'bomba' pra cima do servidor e/ou da instalação do Oracle, tá certo
>> que foi uma questão de parâmetros, mas será que talvez a 'carga' de
>> consultas, chamadas e objetos utilizada nessa aplicação não ocasionou uma
>> excessiva carga no RDBMS que não suportou e cortava a conexão com a
>> aplicação? Pois a perda de conexão era apenas nessa aplicação pois outras
>> aplicações e módulos do mesmo ERP continuavam funcionando normalmente.
>>
>> Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para o
>> sistema, dai eu pergunto, como que foi homologada 100% sendo que esta
>> ocorrendo este erro? fico com essas dúvidas e questionamentos que nunca vão
>> ser respondidos por parte deles, mas na hora de falar que a culpa tá no
>> banco ou no servidor é fácil né
>>
>> Mais uma vez obrigado a todos!
>>
>>
>>
>> Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>
>>>
>>>
>>> Erik, um ponto adicional : como vc está tendo uma parada completamente
>>> inesperada de um processo no Oracle, *** não é Incomum *** que coisas que
>>> deveriam estar gravadas não o estejam, ou algo assim, se o processo estiver
>>> sendo interrompido antes de gravar o necessário, levando á ** CORRUPÇÃO **
>>> ...
>>>  ENtão, além de tentar um work-around se não puder fazer a análise de
>>> correção, eu RECOMENDO que vc (ou o DBA encarregado) faça os procedimentos
>>> de HEALTHCHECK e Verificação de Integridade desse banco, o quanto antes
>>>
>>> []s
>>>
>>>   Chiappa
>>>
>>
>>
>
>
> --
> --
> Thanks,
> * Ricardo Arnoud*
>
>
>
>
>
>
> Porto Alegre - RS
> http://www.queroaprenderlinux.com.br
> http://www.peritodigitalonline.com.br
>
> 
>

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

Erik,
   O sistema foi 100% homologado, com uma base de testes que não reflete o 
volume da sua base de produção, usando uma configuração de teste que também 
pode não refletir o que você tem ai.
   Também acho que o suporte dizer que o sistema foi homologado não serve pra 
nada. 
   Valeria apenas o contrário, ele dizer o está fora, que fugiu do cenário 
homologado e que precisa ajustar, quais os parâmetros do banco usados para 
homologação que você não tenha ai por exemplo, ou quais patches foram aplicados 
em cima da 11.2.0.1 para conseguir completar a homologação. Ou se há algum 
patch necessário no ERP para o uso com essa versão especifica do banco.
Atc,Luis Freitas

  From: "Ricardo Arnoud ricardo...@gmail.com [oracle_br]" 

 To: "oracle_br@yahoogrupos.com.br"  
 Sent: Wednesday, March 15, 2017 3:25 PM
 Subject: Re: [oracle_br] ORA-07445: exception encountered: core dump
   
    Usar como argumento que o sistema foi homologado para a versão 11.2.0.1 é 
bengala, primeiramente esse ambiente deveria estar em uma versão mais atual 
como por exemplo a 11.2.0.4. Para isso, se requer suporte/licenciamento.

E amigo, parabéns pois você esbarrou em um bug.

2017-03-15 14:48 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br] 
:

     Boa tarde,

Primeiramente obrigado pelas respostas de todos. O problema foi solucionado, 
inicialmente setei o parâmetro set_optimizer_enable_extended_ stats=false 
conforme o colega sugeriu acima, depois rodei a aplicação novamente e deu o 
erro. Posteriormente verifiquei os parâmetros 'shared_pool_size', 
'java_pool_size', 'large_pool_size' e todos estavam com 'Value=0', atribui uns 
valores para cada um e depois alterei o parâmetro "_optimizer_enable_extended_ 
stats" para sessão novamente e deu certo.

Tecnicamente não entendi a questão dos parâmetros acima, mas deu certo, vou 
estudar mais para entender melhor essa situação, simular essa situação mais 
vezes em ambiente de testes para tentar entender.

Consultando um outro trace file pude verificar uma query gigantesca e também 
chamadas para outras procedures que acredito ser dessa aplicação, imaginei será 
que essa aplicação faz essa consulta desse tamanho? será que não teria como 
otimizar isso? não estou fugindo da minha responsabilidade com relação a 
empresa que presto serviço mas a software house simplesmente jogou a 'bomba' 
pra cima do servidor e/ou da instalação do Oracle, tá certo que foi uma questão 
de parâmetros, mas será que talvez a 'carga' de consultas, chamadas e objetos 
utilizada nessa aplicação não ocasionou uma excessiva carga no RDBMS que não 
suportou e cortava a conexão com a aplicação? Pois a perda de conexão era 
apenas nessa aplicação pois outras aplicações e módulos do mesmo ERP 
continuavam funcionando normalmente.

Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para o sistema, 
dai eu pergunto, como que foi homologada 100% sendo que esta ocorrendo este 
erro? fico com essas dúvidas e questionamentos que nunca vão ser respondidos 
por parte deles, mas na hora de falar que a culpa tá no banco ou no servidor é 
fácil né

Mais uma vez obrigado a todos!


Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] 
 escreveu:

     Erik, um ponto adicional : como vc está tendo uma parada completamente 
inesperada de um processo no Oracle, *** não é Incomum *** que coisas que 
deveriam estar gravadas não o estejam, ou algo assim, se o processo estiver 
sendo interrompido antes de gravar o necessário, levando á ** CORRUPÇÃO ** ...
 ENtão, além de tentar um work-around se não puder fazer a análise de correção, 
eu RECOMENDO que vc (ou o DBA encarregado) faça os procedimentos de HEALTHCHECK 
e Verificação de Integridade desse banco, o quanto antes

[]s

  Chiappa   

   



-- 
--
Thanks,
Ricardo Arnoud




  

Porto Alegre - RS
http://www.queroaprenderlinux.com.br
http://www.peritodigitalonline.com.br

  #yiv2555710621 #yiv2555710621 -- #yiv2555710621ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2555710621 
#yiv2555710621ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2555710621 
#yiv2555710621ygrp-mkp #yiv2555710621hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2555710621 #yiv2555710621ygrp-mkp #yiv2555710621ads 
{margin-bottom:10px;}#yiv2555710621 #yiv2555710621ygrp-mkp .yiv2555710621ad 
{padding:0 0;}#yiv2555710621 #yiv2555710621ygrp-mkp .yiv2555710621ad p 
{margin:0;}#yiv2555710621 #yiv2555710621ygrp-mkp .yiv2555710621ad a 
{color:#ff;text-decoration:none;}#yiv2555710621 #yiv2555710621ygrp-sponsor 
#yiv2555710621ygrp-lc {font-family:Arial;}#yiv2555710621 
#yiv2555710621ygrp-sponsor #yiv2555710621ygrp-lc #yiv2555710621hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2555710621 
#yiv2555710621ygrp-sponsor #yiv2555710621ygrp-lc .yiv2555710621ad 
{margin-bottom:10px;padding:0 0;}#yiv2555710621 #yiv2555710621actions 
{font-family:Verdana;font-size:11px;padding:10

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Ricardo Arnoud ricardo...@gmail.com [oracle_br]]

Usar como argumento que o sistema foi homologado para a versão 11.2.0.1 é
bengala, primeiramente esse ambiente deveria estar em uma versão mais atual
como por exemplo a 11.2.0.4. Para isso, se requer suporte/licenciamento.

E amigo, parabéns pois você esbarrou em um bug.

2017-03-15 14:48 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Boa tarde,
>
> Primeiramente obrigado pelas respostas de todos. O problema foi
> solucionado, inicialmente setei o parâmetro 
> set_optimizer_enable_extended_stats=false
> conforme o colega sugeriu acima, depois rodei a aplicação novamente e deu o
> erro. Posteriormente verifiquei os parâmetros 'shared_pool_size',
> 'java_pool_size', 'large_pool_size' e todos estavam com 'Value=0', atribui
> uns valores para cada um e depois alterei o parâmetro
> "_optimizer_enable_extended_stats" para sessão novamente e deu certo.
>
> Tecnicamente não entendi a questão dos parâmetros acima, mas deu certo,
> vou estudar mais para entender melhor essa situação, simular essa situação
> mais vezes em ambiente de testes para tentar entender.
>
> Consultando um outro trace file pude verificar uma query gigantesca e
> também chamadas para outras procedures que acredito ser dessa aplicação,
> imaginei será que essa aplicação faz essa consulta desse tamanho? será que
> não teria como otimizar isso? não estou fugindo da minha responsabilidade
> com relação a empresa que presto serviço mas a software house simplesmente
> jogou a 'bomba' pra cima do servidor e/ou da instalação do Oracle, tá certo
> que foi uma questão de parâmetros, mas será que talvez a 'carga' de
> consultas, chamadas e objetos utilizada nessa aplicação não ocasionou uma
> excessiva carga no RDBMS que não suportou e cortava a conexão com a
> aplicação? Pois a perda de conexão era apenas nessa aplicação pois outras
> aplicações e módulos do mesmo ERP continuavam funcionando normalmente.
>
> Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para o
> sistema, dai eu pergunto, como que foi homologada 100% sendo que esta
> ocorrendo este erro? fico com essas dúvidas e questionamentos que nunca vão
> ser respondidos por parte deles, mas na hora de falar que a culpa tá no
> banco ou no servidor é fácil né
>
> Mais uma vez obrigado a todos!
>
>
>
> Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Erik, um ponto adicional : como vc está tendo uma parada completamente
>> inesperada de um processo no Oracle, *** não é Incomum *** que coisas que
>> deveriam estar gravadas não o estejam, ou algo assim, se o processo estiver
>> sendo interrompido antes de gravar o necessário, levando á ** CORRUPÇÃO **
>> ...
>>  ENtão, além de tentar um work-around se não puder fazer a análise de
>> correção, eu RECOMENDO que vc (ou o DBA encarregado) faça os procedimentos
>> de HEALTHCHECK e Verificação de Integridade desse banco, o quanto antes
>>
>> []s
>>
>>   Chiappa
>>
>
> 
>



-- 
--
Thanks,
* Ricardo Arnoud*






Porto Alegre - RS
http://www.queroaprenderlinux.com.br
http://www.peritodigitalonline.com.br

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Erik Castilho escasti...@gmail.com [oracle_br]]

Boa tarde,

Primeiramente obrigado pelas respostas de todos. O problema foi
solucionado, inicialmente setei o parâmetro
set_optimizer_enable_extended_stats=false conforme o colega sugeriu acima,
depois rodei a aplicação novamente e deu o erro. Posteriormente verifiquei
os parâmetros 'shared_pool_size', 'java_pool_size', 'large_pool_size' e
todos estavam com 'Value=0', atribui uns valores para cada um e depois
alterei o parâmetro "_optimizer_enable_extended_stats" para sessão
novamente e deu certo.

Tecnicamente não entendi a questão dos parâmetros acima, mas deu certo, vou
estudar mais para entender melhor essa situação, simular essa situação mais
vezes em ambiente de testes para tentar entender.

Consultando um outro trace file pude verificar uma query gigantesca e
também chamadas para outras procedures que acredito ser dessa aplicação,
imaginei será que essa aplicação faz essa consulta desse tamanho? será que
não teria como otimizar isso? não estou fugindo da minha responsabilidade
com relação a empresa que presto serviço mas a software house simplesmente
jogou a 'bomba' pra cima do servidor e/ou da instalação do Oracle, tá certo
que foi uma questão de parâmetros, mas será que talvez a 'carga' de
consultas, chamadas e objetos utilizada nessa aplicação não ocasionou uma
excessiva carga no RDBMS que não suportou e cortava a conexão com a
aplicação? Pois a perda de conexão era apenas nessa aplicação pois outras
aplicações e módulos do mesmo ERP continuavam funcionando normalmente.

Eles me passaram que essa versão 11.0.2.1.0 foi 100% homologada para o
sistema, dai eu pergunto, como que foi homologada 100% sendo que esta
ocorrendo este erro? fico com essas dúvidas e questionamentos que nunca vão
ser respondidos por parte deles, mas na hora de falar que a culpa tá no
banco ou no servidor é fácil né

Mais uma vez obrigado a todos!



Em 15 de março de 2017 13:05, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Erik, um ponto adicional : como vc está tendo uma parada completamente
> inesperada de um processo no Oracle, *** não é Incomum *** que coisas que
> deveriam estar gravadas não o estejam, ou algo assim, se o processo estiver
> sendo interrompido antes de gravar o necessário, levando á ** CORRUPÇÃO **
> ...
>  ENtão, além de tentar um work-around se não puder fazer a análise de
> correção, eu RECOMENDO que vc (ou o DBA encarregado) faça os procedimentos
> de HEALTHCHECK e Verificação de Integridade desse banco, o quanto antes
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] Re: merge join cartesiano

[jlchia...@yahoo.com.br [oracle_br]]

O ponto é : sim, via de regra vc Tem que obdedecer às Recomendações do 
fornecedor do ERP (pois como eu disse, é ELE que conhece os SQLs e a lógica do 
aplicativo, né não), mas o que Não Dá pra engolir é frase do tipo "ah, porque 
sim, porque X é ruim pra performance e ponto" - o que eu ** ESPERO ** que tenha 
ficado Claro com a minha resposta e com o contra-exemplo no link indicado é que 
NENHUMA feature, NENHUM recurso de banco é ruim "porque sim", okdoc ?? Há 
situações e situações 
 O que vc deve fazer, se o Fornecedor jogou a carta do "porque sim" é obter um 
TRACE DE SQL+TKPROF ** E ** um Plano de Execução extendido (e talvez um trace 
10053) das principais rotinas COM e SEM o parâmetro e mandar pra ele, 
Comprovando que efetivamente Melhorou Ou Piorou Ou (como muitas vezes ocorre) o 
parâmetro foi INÓCUO para a performance. Aí SIM vc vai estar tomando uma 
decisão RESPALDADA, com Provas, yes ?? 
 
 []s
 
   Chiappa
   
 OBS : é EXTREMAMENTE COMUM que o pessoal de ERP *** não entenda *** a 
importância de CONSTRAINTs e de Estatísticas de dados (com HISTOGRAMAS, se for 
o caso) para um bom plano de execução - sendo assim, não deixe de Analisar / 
testar a possibilidade de fazer coleta de estatísticas mais precisas nas 
tabelas maiores/mais usadas do aplicativo Isso é por vezes ** extremamente 
efetivo ** mas dificilmente fornecedores de ERP pedem isso...

Re: [oracle_br] Desaster Recovery

[carloseduard...@yahoo.com [oracle_br]]

Pessoal, o backup que fiz, foi um backup HOT, com o database em estado OPEN, ok?
O que quis dizer com INSTANCE em SHUTDOWN, eh que na hora do restore/recovery o 
database estava em shutdown, ate pq foram deletados todos os datafiles do banco 
e consequentemente a instance estava em shutdown na hora do restore/recovery. 
Mas que o backup foi realizado com o database aberto, backup HOT. 

Em Quarta-feira, 15 de Março de 2017 13:12, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     "
 se entendi direito, você fez um backup 'cold'
"

==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e 
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles 
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas 
internas  em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER 
de um database que já está íntegro, sim

Se não for COLD, eu reforço também a necessidade de vc consultar 
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode 
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW 
antes da coisa real, sim...

[]s

  Chiappa  #yiv199977 #yiv199977 -- #yiv199977ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv199977 
#yiv199977ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv199977 
#yiv199977ygrp-mkp #yiv199977hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv199977 #yiv199977ygrp-mkp #yiv199977ads 
{margin-bottom:10px;}#yiv199977 #yiv199977ygrp-mkp .yiv199977ad 
{padding:0 0;}#yiv199977 #yiv199977ygrp-mkp .yiv199977ad p 
{margin:0;}#yiv199977 #yiv199977ygrp-mkp .yiv199977ad a 
{color:#ff;text-decoration:none;}#yiv199977 #yiv199977ygrp-sponsor 
#yiv199977ygrp-lc {font-family:Arial;}#yiv199977 
#yiv199977ygrp-sponsor #yiv199977ygrp-lc #yiv199977hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv199977 
#yiv199977ygrp-sponsor #yiv199977ygrp-lc .yiv199977ad 
{margin-bottom:10px;padding:0 0;}#yiv199977 #yiv199977actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv199977 
#yiv199977activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv199977
 #yiv199977activity span {font-weight:700;}#yiv199977 
#yiv199977activity span:first-child 
{text-transform:uppercase;}#yiv199977 #yiv199977activity span a 
{color:#5085b6;text-decoration:none;}#yiv199977 #yiv199977activity span 
span {color:#ff7900;}#yiv199977 #yiv199977activity span 
.yiv199977underline {text-decoration:underline;}#yiv199977 
.yiv199977attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv199977 .yiv199977attach div a 
{text-decoration:none;}#yiv199977 .yiv199977attach img 
{border:none;padding-right:5px;}#yiv199977 .yiv199977attach label 
{display:block;margin-bottom:5px;}#yiv199977 .yiv199977attach label a 
{text-decoration:none;}#yiv199977 blockquote {margin:0 0 0 
4px;}#yiv199977 .yiv199977bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv199977 
.yiv199977bold a {text-decoration:none;}#yiv199977 dd.yiv199977last 
p a {font-family:Verdana;font-weight:700;}#yiv199977 dd.yiv199977last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv199977 
dd.yiv199977last p span.yiv199977yshortcuts 
{margin-right:0;}#yiv199977 div.yiv199977attach-table div div a 
{text-decoration:none;}#yiv199977 div.yiv199977attach-table 
{width:400px;}#yiv199977 div.yiv199977file-title a, #yiv199977 
div.yiv199977file-title a:active, #yiv199977 
div.yiv199977file-title a:hover, #yiv199977 div.yiv199977file-title 
a:visited {text-decoration:none;}#yiv199977 div.yiv199977photo-title a, 
#yiv199977 div.yiv199977photo-title a:active, #yiv199977 
div.yiv199977photo-title a:hover, #yiv199977 
div.yiv199977photo-title a:visited {text-decoration:none;}#yiv199977 
div#yiv199977ygrp-mlmsg #yiv199977ygrp-msg p a 
span.yiv199977yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv199977 
.yiv199977green {color:#628c2a;}#yiv199977 .yiv199977MsoNormal 
{margin:0 0 0 0;}#yiv199977 o {font-size:0;}#yiv199977 
#yiv199977photos div {float:left;width:72px;}#yiv199977 
#yiv199977photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#yiv199977 
#yiv199977photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv199977
 #yiv199977reco-category {font-size:77%;}#yiv199977 
#yiv199977reco-desc {font-size:77%;}#yiv199977 

Re: [oracle_br] Re: merge join cartesiano

[angelo angelolis...@gmail.com [oracle_br]]

Então Chiappa.. eu nunca usei e nem tinha alterado esse parâmetro antes foi
a primeira vez mesmo

Realmente é um erp sim, um famoso da área tributaria e fiscal, o suporte do
fornecedor ja tentou mil coisas, cada hora pedem pra rodar um script
diferente ou alterar uma determinada configuração e isso já tem 1 semana...

E ai pediram para desabilitar o merge join porque para eles, seria ruim
para a performance.
E como esse banco é dedicado a esse sistema, acho que não tem stress.



2017-03-15 12:58 GMT-03:00 jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Colega, veja lá : primeiro de tudo, se uma determinada funcionalidade
> fosse nociva ** SEMPRE **, em Qualquer Situação (ou na Maioria das
> Situações) ela com certeza nem teria sido CRIADA, pra começo de conversa,
> não acha  https://asktom.oracle.com/pls/asktom/f?p=100:11:0p11_
> question_id:4105951726381 logo no começo da página mostra um caso onde
> devido à baixa cardinalidade esperada das tabelas esse approach é
> TOTALMENTE VÁLIDO e PERFORMÁTICO, sim sim ???
>  Então a sua resposta é : NENHUMA feature é maligna pra performance por si
> só,NEHUMA é "CUSTOSA"  seja qual for a situação  SIm 
>
>  Aí vem o segundo ponto : como vc usa um ERP (que por definição é um
> software ** complexo ** e que tende a lidar com volumes altos de dados e
> distribuições irregulares, ** ALÉM de SQL fixo e nem sempre muito bem
> feito), nessas situações específicas é comum que o fornecedor peça para vc
> DESABILITAR uma feature x ou y qualquer - isso ele faz baseado no
> conhecimento dos SQLs que ele mesmo criou ** E ** baseado na utilização
> comum/distribuições e volumes de dados que ele espera ver, ok ? Então, vc
> EM PRINCÍPIO segue as Recomendações do fornecedor ** mas ** se vc tiver um
> caso onde a sua experiência é diferente, aí antes de mais nada é acionar o
> SUporte desse ERP e discutir com ele a Viabilidade de habilitar a feature
> tal e qual
>
>  []s
>
>Chiappa
> 
>

Re: [oracle_br] Desaster Recovery

[jlchia...@yahoo.com.br [oracle_br]]

"
 se entendi direito, você fez um backup 'cold'
"

==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e 
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles 
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas 
internas  em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER 
de um database que já está íntegro, sim

Se não for COLD, eu reforço também a necessidade de vc consultar 
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode 
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW 
antes da coisa real, sim...

[]s

  Chiappa

Re: [oracle_br] ORA-07445: exception encountered: core dump

[jlchia...@yahoo.com.br [oracle_br]]

Erik, um ponto adicional : como vc está tendo uma parada completamente 
inesperada de um processo no Oracle, *** não é Incomum *** que coisas que 
deveriam estar gravadas não o estejam, ou algo assim, se o processo estiver 
sendo interrompido antes de gravar o necessário, levando á ** CORRUPÇÃO ** ...
 ENtão, além de tentar um work-around se não puder fazer a análise de correção, 
eu RECOMENDO que vc (ou o DBA encarregado) faça os procedimentos de HEALTHCHECK 
e Verificação de Integridade desse banco, o quanto antes

[]s

  Chiappa

[oracle_br] Re: merge join cartesiano

[jlchia...@yahoo.com.br [oracle_br]]

Colega, veja lá : primeiro de tudo, se uma determinada funcionalidade fosse 
nociva ** SEMPRE **, em Qualquer Situação (ou na Maioria das Situações) ela com 
certeza nem teria sido CRIADA, pra começo de conversa, não acha  
https://asktom.oracle.com/pls/asktom/f?p=100:11:0p11_question_id:4105951726381
 logo no começo da página mostra um caso onde devido à baixa cardinalidade 
esperada das tabelas esse approach é TOTALMENTE VÁLIDO e PERFORMÁTICO, sim sim 
??? 
 Então a sua resposta é : NENHUMA feature é maligna pra performance por si 
só,NEHUMA é "CUSTOSA"  seja qual for a situação  SIm 
 
 Aí vem o segundo ponto : como vc usa um ERP (que por definição é um software 
** complexo ** e que tende a lidar com volumes altos de dados e distribuições 
irregulares, ** ALÉM de SQL fixo e nem sempre muito bem feito), nessas 
situações específicas é comum que o fornecedor peça para vc DESABILITAR uma 
feature x ou y qualquer - isso ele faz baseado no conhecimento dos SQLs que ele 
mesmo criou ** E ** baseado na utilização comum/distribuições e volumes de 
dados que ele espera ver, ok ? Então, vc EM PRINCÍPIO segue as Recomendações do 
fornecedor ** mas ** se vc tiver um caso onde a sua experiência é diferente, aí 
antes de mais nada é acionar o SUporte desse ERP e discutir com ele a 
Viabilidade de habilitar a feature tal e qual 
 
 []s
 
   Chiappa

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Ricardo Arnoud ricardo...@gmail.com [oracle_br]]

Bom dia.

Bug 9474259 - Dump[kkestGetColGroupNdv] optimizing query (Doc ID 9474259.8)

Atualize para versao 11.2.0.2 ou sete o seguinte parametro da instance

Set _optimizer_enable_extended_stats=false

Abracos.


2017-03-15 10:37 GMT-03:00 Erik Castilho escasti...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Pessoal, bom dia!
>
> Utilizamos um ERP desenvolvido em Centura e tem uma aplicação que esta
> ocorrendo um erro ao fazer chamadas nos objetos do banco:
>
> *Alert:*
>
> ORA-07445: exception encountered: core dump [kkestGetColGroupNdv()+20]
> [SIGSEGV] [ADDR:0x68] [PC:0x101AACA] [Address not mapped to object] []
>
> *Trace File:*
>
> *** 2017-03-15 10:22:25.072
> *** SESSION ID:(46.234) 2017-03-15 10:22:25.072
> *** CLIENT ID:() 2017-03-15 10:22:25.072
> *** SERVICE NAME:(SYS$USERS) 2017-03-15 10:22:25.072
> *** MODULE NAME:(Gcp3bc00_GeraBoletoC5_RECN.exe) 2017-03-15 10:22:25.072
> *** ACTION NAME:() 2017-03-15 10:22:25.072
>
> Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x68]
> [PC:0x101AACA, kkestGetColGroupNdv()+20] [flags: 0x0, count: 1]
> Incident 67998 created, dump file: /u01/app/oracle/diag/rdbms/
> recon/recon/incident/incdir_67998/recon_ora_28759_i67998.trc
> ORA-07445: exception encountered: core dump [kkestGetColGroupNdv()+20]
> [SIGSEGV] [ADDR:0x68] [PC:0x101AACA] [Address not mapped to object] []
>
> ssexhd: crashing the process...
> Shadow_Core_Dump = PARTIAL
>
> Logo que ocorre esse erro a aplicação perde comunicação com o banco e
> fecha. A equipe de desenvolvimento esta informando que o problema é no
> Oracle ou no servidor e eu estou tentando identificar mas até agora nada,
> alguém já passou por isso e teria alguma ideia?
>
> *Ambiente:*
> - Linux plenodb 2.6.32-642.15.1.el6.x86_64 #1 SMP Fri Feb 24 14:31:22 UTC
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> - Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
>
> Antes que me perguntem, não tenho suporte da Oracle contratado.
>
> Grato pela atenção
>
> []'s
>
>
> 
>



-- 
--
Thanks,
* Ricardo Arnoud*






Porto Alegre - RS
http://www.queroaprenderlinux.com.br
http://www.peritodigitalonline.com.br

Re: [oracle_br] ORA-07445: exception encountered: core dump

[jlchia...@yahoo.com.br [oracle_br]]

Na verdade piadinhas à parte vai ser *** utilíssimo *** pro colega lá que 
perguntou, pois é uma outra fonte frisando e CONFIRMANDO o que acontece na 
real, ie : ORA-00600 e ORA-07445 são aborts de processos internos do RDBMS, só 
os programadores que criaram o código do RDBMS (os programadores da Oracle) é 
que podem dizer algo a respeito Notar que não apenas pode ser bug no código 
do RDBMS e nas libraries do sistema operacional mas TAMBÉM pode ser 
má-configuração dos parâmetros de kernel e ulimits, pode ser ** CONFLITO ** de 
software externo (drivers são culpados comuns) com o software do RDBMS... Tem 
n+1! opções de causa
 Sendo assim, Erik, para vc CORRIGIR o problema vc necessariamente TEM QUE TER 
ACESSO AO SUPORTE ORACLE, sim ? Se vc não tiver como abrir Chamado, pelo menos 
vc deveria ter acesso para consulta à base de documentos técnicos de Suporte, é 
comum que consultando lá vc ache correções ou ao menos work-arounds para a 
maioria dos aborts
 
 Se vc não tiver acesso nem à abertura de chamados e nem de consulta nos 
documentos do Oracle Support nem a baixar patches/correções/atualizações do 
software RDBMS Oracle (o fato de vc estar rodando a ** antiquíssima ** versão 
11.2.0.1 parece indicar isso) aí vc tá na pior : vc Não terá Como corrigir o 
problema, o máximo que vc poderá fazer é localizar o ponto do código onde tá o 
abort e ir trocando a lógica por comandos equivalentes pra tentar contornar : 
se vc vai conseguir é indeterminado, e provavelmente vai ser um esforço 
danado
 
 []s
 
   Chiappa

Re: [oracle_br] ORA-07445: exception encountered: core dump

[Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br]]

Bom dia,

Estou rolando aqui de rir com as respostas sobre ora-07445 no asktom... 
https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:228560700346935920

   Obs.: isso acima nao vai ser util para vc...

  Minha dica, visto vc já disse que nao tem suporte, é verificar os 
sqls/plsqls que rotina faz e fazer de outra forma, afim de "contornar" o bug. 
Assim como o Ora-00600 o 07445  são erros no código fonte do rdbms ou em alguma 
lib do SO que ele usa, e teria que trabalhar com o suporte da Oracle pra 
resolver o mesmo.



Get Outlook for iOS


From: oracle_br@yahoogrupos.com.br  on behalf of 
Erik Castilho escasti...@gmail.com [oracle_br] 
Sent: Wednesday, March 15, 2017 10:37:09 AM
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] ORA-07445: exception encountered: core dump



Pessoal, bom dia!

Utilizamos um ERP desenvolvido em Centura e tem uma aplicação que esta 
ocorrendo um erro ao fazer chamadas nos objetos do banco:

Alert:

ORA-07445: exception encountered: core dump [kkestGetColGroupNdv()+20] 
[SIGSEGV] [ADDR:0x68] [PC:0x101AACA] [Address not mapped to object] []

Trace File:

*** 2017-03-15 10:22:25.072
*** SESSION ID:(46.234) 2017-03-15 10:22:25.072
*** CLIENT ID:() 2017-03-15 10:22:25.072
*** SERVICE NAME:(SYS$USERS) 2017-03-15 10:22:25.072
*** MODULE NAME:(Gcp3bc00_GeraBoletoC5_RECN.exe) 2017-03-15 10:22:25.072
*** ACTION NAME:() 2017-03-15 10:22:25.072

Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x68] 
[PC:0x101AACA, kkestGetColGroupNdv()+20] [flags: 0x0, count: 1]
Incident 67998 created, dump file: 
/u01/app/oracle/diag/rdbms/recon/recon/incident/incdir_67998/recon_ora_28759_i67998.trc
ORA-07445: exception encountered: core dump [kkestGetColGroupNdv()+20] 
[SIGSEGV] [ADDR:0x68] [PC:0x101AACA] [Address not mapped to object] []

ssexhd: crashing the process...
Shadow_Core_Dump = PARTIAL

Logo que ocorre esse erro a aplicação perde comunicação com o banco e fecha. A 
equipe de desenvolvimento esta informando que o problema é no Oracle ou no 
servidor e eu estou tentando identificar mas até agora nada, alguém já passou 
por isso e teria alguma ideia?

Ambiente:
- Linux plenodb 2.6.32-642.15.1.el6.x86_64 #1 SMP Fri Feb 24 14:31:22 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux
- Oracle Database 11g Release 11.2.0.1.0 - 64bit Production

Antes que me perguntem, não tenho suporte da Oracle contratado.

Grato pela atenção

[]'s

[oracle_br] merge join cartesiano

[angelo angelolis...@gmail.com [oracle_br]]

Alguem ai ja teve problema de performance por causa de  merge join
cartesian ?


Dei uma catada no google, se é custoso para o BD porque vem habilitado por
default ?

pelo menos eu nunca tinha alterado isso, até hoje de manhã.

No spfile o parametro é

_optimizer_sortmerge_join_enabled
_optimizer_sortmerge_join_inequality

que aqui agora ta setado como false.

a pedido do fornecedor inclusive, uma situacao que ta rolando num sistema
aqui

[oracle_br] ORA-07445: exception encountered: core dump

[Erik Castilho escasti...@gmail.com [oracle_br]]

Pessoal, bom dia!

Utilizamos um ERP desenvolvido em Centura e tem uma aplicação que esta
ocorrendo um erro ao fazer chamadas nos objetos do banco:

*Alert:*

ORA-07445: exception encountered: core dump [kkestGetColGroupNdv()+20]
[SIGSEGV] [ADDR:0x68] [PC:0x101AACA] [Address not mapped to object] []

*Trace File:*

*** 2017-03-15 10:22:25.072
*** SESSION ID:(46.234) 2017-03-15 10:22:25.072
*** CLIENT ID:() 2017-03-15 10:22:25.072
*** SERVICE NAME:(SYS$USERS) 2017-03-15 10:22:25.072
*** MODULE NAME:(Gcp3bc00_GeraBoletoC5_RECN.exe) 2017-03-15 10:22:25.072
*** ACTION NAME:() 2017-03-15 10:22:25.072

Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x68]
[PC:0x101AACA, kkestGetColGroupNdv()+20] [flags: 0x0, count: 1]
Incident 67998 created, dump file:
/u01/app/oracle/diag/rdbms/recon/recon/incident/incdir_67998/recon_ora_28759_i67998.trc
ORA-07445: exception encountered: core dump [kkestGetColGroupNdv()+20]
[SIGSEGV] [ADDR:0x68] [PC:0x101AACA] [Address not mapped to object] []

ssexhd: crashing the process...
Shadow_Core_Dump = PARTIAL

Logo que ocorre esse erro a aplicação perde comunicação com o banco e
fecha. A equipe de desenvolvimento esta informando que o problema é no
Oracle ou no servidor e eu estou tentando identificar mas até agora nada,
alguém já passou por isso e teria alguma ideia?

*Ambiente:*
- Linux plenodb 2.6.32-642.15.1.el6.x86_64 #1 SMP Fri Feb 24 14:31:22 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux
- Oracle Database 11g Release 11.2.0.1.0 - 64bit Production

Antes que me perguntem, não tenho suporte da Oracle contratado.

Grato pela atenção

[]'s

Re: [oracle_br] Desaster Recovery

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

input 
datafile file number=5 name=/u01/app/oracle/oradata/ 
TERRA1/datafile/o1_mf_new_ user_dcchkvk9_.dbfinput datafile file number=4 
name=/u01/app/oracle/oradata/ TERRA1/datafile/o1_mf_ 
undotbs1_dcczlbll_.dbfinput datafile file number=6 
name=/u01/app/oracle/oradata/ TERRA1/datafile/o1_mf_tbs_ 
user_dccnlhxy_.dbfinput datafile file number=7 
name=/u01/app/oracle/oradata/ TERRA1/datafile/o1_mf_new_ 
user_dcchkvnx_.dbfchannel ORA_DISK_1: starting piece 1 at 15-MAR-17channel 
ORA_DISK_1: finished piece 1 at 15-MAR-17piece handle=/u01/app/oracle/fast_ 
recovery_area/TERRA1/ backupset/2017_03_15/o1_mf_ nnndf_TAG20170315T021022_ 
ddkm6036_.bkp tag=TAG20170315T021022 comment=NONEchannel ORA_DISK_1: backup set 
complete, elapsed time: 00:01:45Finished backup at 15-MAR-17
Starting backup at 15-MAR-17current log archivedusing channel ORA_DISK_1channel 
ORA_DISK_1: starting archived log backup setchannel ORA_DISK_1: specifying 
archived log(s) in backup setinput archived log thread=1 sequence=72 RECID=133 
STAMP=938657529channel ORA_DISK_1: starting piece 1 at 15-MAR-17channel 
ORA_DISK_1: finished piece 1 at 15-MAR-17piece handle=/u01/app/oracle/fast_ 
recovery_area/TERRA1/ backupset/2017_03_15/o1_mf_ a_TAG20170315T021210_ 
ddkm9bgq_.bkp tag=TAG20170315T021210 comment=NONEchannel ORA_DISK_1: backup set 
complete, elapsed time: 00:00:01channel ORA_DISK_1: deleting archived 
log(s)archived log file name=/u01/app/archivelog/arc_ 1_72_936747113.arc 
RECID=133 STAMP=938657529Finished backup at 15-MAR-17
Starting Control File and SPFILE Autobackup at 15-MAR-17piece 
handle=/u01/backup/ controlfile/control_file_c- 2182710439-20170315-00.ctl 
comment=NONEFinished Control File and SPFILE Autobackup at 15-MAR-17

2) rm -rf em todos os datafiles, controlfiles, redo logs, spfile e init.

3) Restaurando o spfile
RMAN> set dbid=2182710439
executing command: SET DBID
RMAN> startup nomount;
startup failed: ORA-01078: failure in processing system parametersLRM-00109: 
could not open parameter file '/u01/app/oracle/product/12.1. 
0.2/db_1/dbs/initTERRA1.ora'
starting Oracle instance without parameter file for retrieval of spfileOracle 
instance started
Total System Global Area    1073741824 bytes
Fixed Size                     2932632 bytesVariable Size                
281018472 bytesDatabase Buffers             784334848 bytesRedo Buffers         
          5455872 bytes
RMAN> set dbid=2182710439
executing command: SET DBID
RMAN> restore spfile from '/u01/backup/controlfile/ control_file_c-2182710439- 
20170315-00.ctl';
Starting restore at 15-MAR-17using target database control file instead of 
recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=12 device 
type=DISK
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/backup/controlfile/ 
control_file_c-2182710439- 20170315-00.ctlchannel ORA_DISK_1: SPFILE restore 
from AUTOBACKUP completeFinished restore at 15-MAR-17
RMAN> EXIT

4) Restaurando o controlfile
SQL> shutdown abort;
RMAN> startup nomount;
Oracle instance started
Total System Global Area     838860800 bytes
Fixed Size                     2929936 bytesVariable Size                
570428144 bytesDatabase Buffers             260046848 bytesRedo Buffers         
          5455872 bytes
RMAN> set dbid=2182710439     
executing command: SET DBID
RMAN> restore controlfile from '/u01/backup/controlfile/ 
control_file_c-2182710439- 20170315-00.ctl';
Starting restore at 15-MAR-17using target database control file instead of 
recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=12 device 
type=DISK
channel ORA_DISK_1: restoring control filechannel ORA_DISK_1: restore complete, 
elapsed time: 00:00:01output file name=/u01/app/oracle/oradata/ 
TERRA1/controlfile/o1_mf_ dbz6roh5_.ctloutput file name=/u01/app/oracle/fast_ 
recovery_area/TERRA1/ controlfile/o1_mf_dbz6roox_. ctlFinished restore at 
15-MAR-17
RMAN> 
RMAN> alter database mount;
Statement processedreleased channel: ORA_DISK_1

5) Restaurando os datafiles
RMAN> list backup of database;
BS Key  Type LV Size       Device Type Elapsed Time Completion Time---  
-- -- ---  ---19      Full    1.14G     
 DISK        00:01:03     28-FEB-17              BP Key: 19   Status: AVAILABLE 
 Compressed: NO  Tag: TAG20170228T152646        Piece Name: 
/u01/app/oracle/fast_recovery_ area/TERRA1/backupset/2017_02_ 28/o1_mf_nnndf_ 
TAG20170228T152646_dccj773m_. bkp  List of Datafiles in backup set 19  File LV 
Type Ckp SCN    Ckp Time  Name   --  -- -   1       
Full 2479294    28-FEB-17 /u01/app/oracle/oradata/ 
TERRA1/datafile/o1_mf_system_ ddko3n6m_.dbf  3       Full 2479294    28-FEB-17 
/u01/app/oracle/oradata/ TERRA1/datafile/o1_mf_sysaux_ ddko3n6t_.dbf  4       
Full 2479294    28-FEB-17 /u01/app/oracle/oradata/ TERRA1/datafile/o1_mf_ 
undotbs1_ddko3nb2_.dbf  5       Full 2479294    28-FE

Re: [oracle_br] Desaster Recovery

[angelo angelolis...@gmail.com [oracle_br]]

Bom dia,

As vezes pode virar uma bateção de cabeça, ainda mais se o ambiente não
estiver previamente documentado...
Principalmente com relação ao *DBID do banco. *Guarda bem esse numero,
porque vc ainda vai precisar dele um dia

Passei por uma situação tosca outro dia, em que um tablespace nao era
backupeado, na configuração do rman estava excluido de proposito.

Mas na hora do restore, em outra maquina não retornava porque havia
referencia a ele, na listagem dos datafiles fazia uma referencia ao que não
tinha
Era uma emergência, precisava fazer uma correção em um sistema que o
usuário tinha feito uns lançamentos errados, então era uma copia do banco
de produção.

E pra completar, as pastas onde estavam os arquivos originais não eram as
mesmas no servidor ( era um outro servidor ), ter que sair adaptando com
set newname datafile..
E na pressa, até lembrar que existia o comando "recover database skip
tablespace fulano,beltrano,...  until sequence (ou scn) etc."

Pode tentar também  com  recover database until cancel.


Carlos, vou propor um outro desafio para treinar o restore, depois que vc
vencer este: => formata a maquina, reinstala o Oracle, zerado e tenta
voltar esse backup ai de novo..

Depois de praticar alguma vezes backup e restore, fica parecendo uma
receita de bolo, que muda pouco, dependendo da situação.




On 15 March 2017 at 03:39, Carlos Eduardo carloseduard...@yahoo.com
[oracle_br]  wrote:

>
>
> Cenário: Desastre e Recovery, COM BACKUP, SEM CATALOGO, INSTANCE SHUTDOWN.
> Enterprise Edition 12.1.0.2 Linux 64
>
> SQL> archive log list
> Database log mode   Archive Mode
> Automatic archival   Enabled
> Archive destination   /u01/app/archivelog2
> Oldest online log sequence 67
> Next log sequence to archive   70
> Current log sequence   70
>
>
> a) PASSO 1 - BACKUPEAR TODOS OS ARQUIVOS DO DATABASE
>
> run
> {alter system archive log current;
>  backup database plus archivelog delete input;
> }
>
> Starting backup at 15-MAR-17
> using channel ORA_DISK_1
> channel ORA_DISK_1: starting full datafile backup set
> channel ORA_DISK_1: specifying datafile(s) in backup set
> input datafile file number=1 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_system_dbz6nx14_.dbf
> input datafile file number=3 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_sysaux_dbz6m573_.dbf
> input datafile file number=5 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_new_user_dcchkvk9_.dbf
> input datafile file number=4 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_undotbs1_dcczlbll_.dbf
> input datafile file number=6 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_tbs_user_dccnlhxy_.dbf
> input datafile file number=7 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_new_user_dcchkvnx_.dbf
> channel ORA_DISK_1: starting piece 1 at 15-MAR-17
> channel ORA_DISK_1: finished piece 1 at 15-MAR-17
> piece handle=/u01/app/oracle/fast_recovery_area/TERRA1/
> backupset/2017_03_15/o1_mf_nnndf_TAG20170315T021022_ddkm6036_.bkp
> tag=TAG20170315T021022 comment=NONE
> channel ORA_DISK_1: backup set complete, elapsed time: 00:01:45
> Finished backup at 15-MAR-17
>
> Starting backup at 15-MAR-17
> current log archived
> using channel ORA_DISK_1
> channel ORA_DISK_1: starting archived log backup set
> channel ORA_DISK_1: specifying archived log(s) in backup set
> input archived log thread=1 sequence=72 RECID=133 STAMP=938657529
> channel ORA_DISK_1: starting piece 1 at 15-MAR-17
> channel ORA_DISK_1: finished piece 1 at 15-MAR-17
> piece handle=/u01/app/oracle/fast_recovery_area/TERRA1/
> backupset/2017_03_15/o1_mf_a_TAG20170315T021210_ddkm9bgq_.bkp
> tag=TAG20170315T021210 comment=NONE
> channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
> channel ORA_DISK_1: deleting archived log(s)
> archived log file name=/u01/app/archivelog/arc_1_72_936747113.arc
> RECID=133 STAMP=938657529
> Finished backup at 15-MAR-17
>
> Starting Control File and SPFILE Autobackup at 15-MAR-17
> piece handle=/u01/backup/controlfile/control_file_c-2182710439-20170315-00.ctl
> comment=NONE
> Finished Control File and SPFILE Autobackup at 15-MAR-17
>
>
> 2) rm -rf em todos os datafiles, controlfiles, redo logs, spfile e init.
>
>
> 3) Restaurando o spfile
>
> RMAN> set dbid=2182710439 <(21)%208271-0439>
>
> executing command: SET DBID
>
> RMAN> startup nomount;
>
> startup failed: ORA-01078: failure in processing system parameters
> LRM-00109: could not open parameter file '/u01/app/oracle/product/12.1.
> 0.2/db_1/dbs/initTERRA1.ora'
>
> starting Oracle instance without parameter file for retrieval of spfile
> Oracle instance started
>
> Total System Global Area107374

[oracle_br] Re: Desaster Recovery

[jlchia...@yahoo.com.br [oracle_br]]

Bem, primeiro não entendi o que vc quis dizer com  INSTANCE SHUTDOWN na hora de 
fazer o backup : vc quer dizer que imediatamente antes de fazer o backup vc 
pediu um shutdown ?? Shutdown normal/immediate ?? Se sim, logo depois vc pediu 
um STARTUP antes do backup, sendo portanto backup hot/inconsistente, é isso ?? 
Ou não ?? detalhes plz
 Agora, independente de qquer coisa, eu ** vejo ** que vc ABSOLUTAMENTE NÃO 
SEGUIU os ditames que indicamos em thread anterior : ** CADÊ ** a consulta dos 
SCNs dos DATAFILES, do SISTEMA, dos redo log files e dos archives além do SCN 
do controlfile ???  Nós TEMOS que confirmar quais SCNs de quais sequências de 
redo vai ser necessárias...
  E continuando, *** CADÊ *** o DELETE dos backups anteriores no sistema 
operacional / local de destino dos backups E no controlfile ** ANTES ** do 
comando BACKUP DATABASE ou então um list backup+deletes após o restore do 
controlfile ??? *** CADÊ *** o restore preview pra gente ** CONFIRMAR ** que 
tudo o que será necessário tá presente 
  
  Quando eu disse pra fazer tudo "no sapatinho", "by the book", são NESSAS 
coisas que a gente pensa - isso é necessário porque NÂO SABEMOS NADA do seu 
ambiente, por isso eu digo pra vc fazer as consultas TODINHAS pra Justamente 
mostrar como está seu ambiente, E além disso queremos Evitar ao máximo a chance 
de vc estar inadvertidamente querendo restaurar arquivo que já existe, versões 
anteriores ou coisas assim,  
  
  []s
  
Chiappa

OBS :

  a. normalmente não pega nada, mas eu *** detesto *** ter spfile E initfile ao 
mesmo tempo, vai saber se algum determinado parâmetro tá sendo setado num ou 
noutro. E ao mesmo ** odeio ** confiar em defaults E também detesto estar 
numa situação incomum, não-padrão, então minha Recomendação totalmente é NÃO 
FAÇA ISSO, não há razão para vc ter isso : é UM ou OUTRO, não os dois

  b. igualmente, eu *** detesto ** usar sem necessidade o SHUTDOWN ABORT : 
recomendaria ** FORTEMENTE ** que vc fizesse o SHUTDOWN normal/immediate após o 
backup, de modo a garantir 100% que não tenha ficado nenhum filehandle 
apontando pra qquer arquivo do database, nenhuma área temporária alocada.
  Feito o backup E parada a instância normalmente, vc ainda ** CONFIRMA ANTES 
** do restore (via ipcs, ps e lsof) que ** REALMENTE ** não tem nenhuma 'sobra' 
da instância anterior
  E principalmente *** MOSTRA ** pra gente uma listagem dos arquivos que 
compõem o database (vc pode obter isso facilmente via consultas OU até mesmo 
pedindo um backup controlfile to trace - o arquivo-texto gerado vai conter a 
lista dos arqs TODINHOS) e mostra o printscreen do sistema operacional 
removendo com sucesso cada um deles
  ===> IMHO seria muito mais simples pra vc que está Aprendendo testar o 
restore+recover num OUTRO servidor onde vc tem 100% de certeza que não tem 
database Oracle, mas Entendo que vc não tem essa máquina disponível, por isso 
está testando restore no mesmo servidor que já contém database Oracle...