Re: [oracle_br] Re: copia de binários do oracle para outro S.O

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

Então é provavel que tenham corrigido o problema na versão 12c.. e a 11g
fica a ver navios por enquanto (ou mais um motivo pra sugerir o usuario
migrar.. )



2016-05-12 15:45 GMT-03:00 alexssandro0...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Boa tarde!
>
> Pessoal, as notas do metalink que falam do problema do pre_page_sga são:
>
> Bug 8505803 - PRE_PAGE_SGA results in excessive page table size when using
> MEMORY_TARGET [AMM] (Doc ID 8505803.8),
>
> Health Check Alert: Consider setting PRE_PAGE_SGA to FALSE (Doc ID
> 957525.1)
>
> Slow Connection or ORA-12170 During Connect when PRE_PAGE_SGA init.ora
> Parameter is Set (Doc ID 289585.1)
>
> Nas notas acima, nos mostra que temos problemas tanto no gerenciamento
> automático de memória quanto no manual. Sendo a solução desabilitar o
> pre_page_sga.
> Isso na versão Oracle 11G, que é a minha (11.2.0.4).
>
> Já para a versão 12C a história é outra, pois a nota Doc ID 1987975.1 nos
> diz que este parâmetro vem habilitado por default, "The default value for
> the parameter PRE_PAGE_SGA has changed in 12c to TRUE. It used to be FALSE
> in prior releases. "
> Na Doc acima eles demonstram a melhoria que foi realizado no 12c, para
> justificar o do por que o parâmetro passou a ser habilitado por default.
>
>
>
>
>
> 
>

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Boa tarde! 

 Pessoal, as notas do metalink que falam do problema do pre_page_sga são:
 

 Bug 8505803 - PRE_PAGE_SGA results in excessive page table size when using 
MEMORY_TARGET [AMM] (Doc ID 8505803.8),

 

 Health Check Alert: Consider setting PRE_PAGE_SGA to FALSE (Doc ID 957525.1)

 

 Slow Connection or ORA-12170 During Connect when PRE_PAGE_SGA init.ora 
Parameter is Set (Doc ID 289585.1)

  

 Nas notas acima, nos mostra que temos problemas tanto no gerenciamento 
automático de memória quanto no manual. Sendo a solução desabilitar o 
pre_page_sga.
 Isso na versão Oracle 11G, que é a minha (11.2.0.4).
 

 Já para a versão 12C a história é outra, pois a nota Doc ID 1987975.1 nos diz 
que este parâmetro vem habilitado por default, "The default value for the 
parameter PRE_PAGE_SGA has changed in 12c to TRUE. It used to be FALSE in prior 
releases. "
 Na Doc acima eles demonstram a melhoria que foi realizado no 12c, para 
justificar o do por que o parâmetro passou a ser habilitado por default. 
 

 

 

  

 

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Boa tarde! 

 Angelo, estou vendo com o suporte da Oracle este problema, pois ele é 
conhecido apenas com o AMM e não com o gerenciamento manual de memória.
 

 Assim que eu tiver uma resposta eu posto aqui..

Re: [oracle_br] Re: copia de binários do oracle para outro S.O

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

Vê se tem alguma correção pra isso..

teoricamente o parâmetro deveria funcionar, sem deixar o acesso ao ambiente
lento..



2016-05-11 16:29 GMT-03:00 alexssandro0...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Boa tarde!
>
> Pessoal, descobri o motivo pelo qual a conexão estava demorada.
>
> Se trata do parâmetro pre_page_sga que no meu ambiente da como "TRUE"
>
> No blog do Kevin, descreve o problema que passei com AMM, porém tive este
> problema com o gerenciamento manual de memória também.
> Oracle Database 11g Automatic Memory Management – Part IV. Don’t Use
> PRE_PAGE_SGA, OK?
> 
> [image: image]
> 
> Oracle Database 11g Automatic Memory Mana...
> 
> BLOG UPDATE (05.14.09): The bug number for this PRE_PAGE_SGA with
> Automatic Memory Management issue  is 8505803 It has been quite a while
> since...
> Visualizar em kevinclosson.net
> 
> Visualização pelo Yahoo
>
>
>
> Isso se deu pois no meu ambiente oficial eu tenho o hugepages habilitado,
> mas na Amazon eu optei por não habilitar.
> Sem o hugepages tem lentidão, já com o hugepages isso não ocorre.
>
> Mais uma vez obrigado a todos.
>
>
>
> 
>

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Boa tarde! 

 Pessoal, descobri o motivo pelo qual a conexão estava demorada.
 

 Se trata do parâmetro pre_page_sga que no meu ambiente da como "TRUE"
 

 No blog do Kevin, descreve o problema que passei com AMM, porém tive este 
problema com o gerenciamento manual de memória também.
 Oracle Database 11g Automatic Memory Management – Part IV. Don’t Use 
PRE_PAGE_SGA, OK? 
https://kevinclosson.net/2009/05/08/oracle-database-11g-automatic-memory-management-part-iv-dont-use-pre_page_sga-ok/
 
 
 
https://kevinclosson.net/2009/05/08/oracle-database-11g-automatic-memory-management-part-iv-dont-use-pre_page_sga-ok/
 
 
 Oracle Database 11g Automatic Memory Mana... 
https://kevinclosson.net/2009/05/08/oracle-database-11g-automatic-memory-management-part-iv-dont-use-pre_page_sga-ok/
 BLOG UPDATE (05.14.09): The bug number for this PRE_PAGE_SGA with Automatic 
Memory Management issue  is 8505803 It has been quite a while since...
 
 
 
 Visualizar em kevinclosson.net 
https://kevinclosson.net/2009/05/08/oracle-database-11g-automatic-memory-management-part-iv-dont-use-pre_page_sga-ok/
 
 Visualização pelo Yahoo 
 
 
  
 
 Isso se deu pois no meu ambiente oficial eu tenho o hugepages habilitado, mas 
na Amazon eu optei por não habilitar.
 Sem o hugepages tem lentidão, já com o hugepages isso não ocorre.
 

 Mais uma vez obrigado a todos.
 

  

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Agradecemos demais o retorno, sempre é conhecimento compartilhado : 
particularmente, eu só conhecia issues de lentidão/timeout no boot, e em 
versões mais antigas, cfrme o doc do metalink/mos "Bug 8527473 - Various back 
ground processes fail to start causing instance to crash with ORA-443 / 
ORA-445" (Doc ID 8527473.8) 

 Eu não tinha visto um caso de randomização de posição do kernel code causar 
lentidão na comunicação , fica de conhecimento adquirido... 

[]s

  Chiappa

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Bom dia! 

 Pessoal, obrigado pela ajuda de todos, o problema está a nível de S.O/Rede.
 

 Trocamos o tipo de instancia na Amazon para força a troca do host e foi 
desativado o  ASLR do kernel.
 

 

  Agora passou de 40 segundos para 7 segundos.
 

 Estamos trabalhando para diminuir ainda mais este tempo, assim que tiver 
novidades eu posto aqui.
 

 Mais uma vez obrigado a todos.

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Posso palpitar ? Se vc vai tentar fazer uma nova instalação (num outro 
ORACLE_HOME, que seja) , experimenta com esses novos binários criar um NOVO 
database de testes (usa um dos templates de banco do dbca, aquele mais parecido 
com o seu banco original) e tenta fazer testes de conexão com esse outro 
database : SE a lentidão sumir, tá provado que era alguma trigger ou alguma 
config do database original que vc copiou que estava com problema, e SE a 
lentidão não sumir, aí tá mais que provado que não tem nada a ver com o 
software Oracle, aí vc vai explorar config de DNS, arqs /etc/hosts e arqs de 
configuração do database, arqs de config do sql*net (principalmente SQLNET.ORA 
e TNSNAMES.ORA), coisa assim ...

 []s

  Chiappa

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Não confunda as coisas, colega : quando a gente fala de INSTALAÇÃo estamos nos 
referendo as BINÀRIOS do RDBMS Oracle - CONTROLFILES, SPFILES, DATAFILES e cia 
bela compõem um DATABASE ORACLE... Sim, o DATABASE pode ser clonado (esse é a 
operação de "transferência" de um banco) , mas para o banco ser aberto os 
BINÁRIOS precisam ser instalados antes, E além disso para que os binários 
possam abrir um database criado/usado no release x.y.z.n.m , eles TEM que 
estarem EXATAMENTE nesse release x.y.z.n.m : vc obtém isso instalando o 
software na mesma versão-base e depois se preciso aplicando os ** PATCHES ** 
necessários para se chegar nesse exato release x.y.z.n.m, um por um 
 Uma vez o binário presente nesse exato release x.y.z.n.m, aí ** REALMENTE **, 
se o hardware todinho, inclusive os os filesystems/mount-points são EXATAMENTE 
IGUAIS nos dois ambientes, o procedimento de clone poderia sim ser uma simples 
cópia do database contendo o database TODO, ie, os DATAFILES mais o 
CONTROLFILES mais o SPFILE/initfile mais redo log files, etc LOGICAMENTE, 
esse cópia pode ser feita diretamente com o database fechado, OU (se o database 
e a versão permitem) pode-se usar o DUPLICATE ONLINE - googla por ORACLE  
DATABASE CLONE que vc acha diversas refs...

 []s

   Chiappa

Re: [oracle_br] Re: copia de binários do oracle para outro S.O

[Rosivaldo Ramalho rosiva...@gmail.com [oracle_br]]

Amigo,

Partindo do pressuposto que você de fato "clonou" a máquina, em geral
lentidão de sqlnet na mesma máquina é configuração de IP/hosts errada.

Verifique seu arquivo /etc/hosts e também os sqlnet.ora e tnsnames.ora para
bater o endereço da máquina setado estão todos corretos.

Atenciosamente
--
Rosivaldo Azevedo Ramalho 
Consultor Oracle Database & Fusion Middlerware
OCP DB 10g | OCP DB 11g | OCE RAC 11g | OCE PT 11g
OCP OAS 10g | OCE WLS 10g

http://about.me/rosivaldo

2016-05-09 13:00 GMT-03:00 alexssandro0...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Boa tarde!
>
> Ricardo, tenho duas trigger que já estão desabilitadas, e a lentidão
> continua.
>
> Ricardo tenho sim como instalar os binários em um novo home, mas como eu
> faço para vincular estes novos binários com o meu banco que já existe??
>
>
> 
>

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Boa tarde! 

 Ricardo, tenho duas trigger que já estão desabilitadas, e a lentidão continua.
 

 Ricardo tenho sim como instalar os binários em um novo home, mas como eu faço 
para vincular estes novos binários com o meu banco que já existe??  

Re: [oracle_br] Re: copia de binários do oracle para outro S.O

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

Por via das dúvidas, tem alguma trigger de logon ativada?
Já tentou instalar esses binários via runinstaller nesse novo host? Pode
até instalar em outro home se não for problema no teu ambiente.

2016-05-09 11:58 GMT-03:00 alexssandro0...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> bom dia!
>
> Chiappa, tem como eu fazer uma nova instalação do Oracle e utilizar o
> spfile da outra instalação nesta nova instalação, para que ele reconheça
> todas as confs do outro ambiente(datafile,controlfile etc), sem a
> necessidade de realizar um restore do ambiente para esta nova instalação??
> pois os dados já estão todos lá nos discos.
>
> 
>



-- 
--
Thanks,
* Ricardo Arnoud*

*Bacharel em Ciência da Computação* - 2013/1





(51) 9511-4658 VIVO / (51) 9259-2333 CLARO / Porto Alegre - RS
http://www.ricardoarnoud.com
http://www.alterdatabaseopen.com
FB http://www.facebook.com/ricardo.arnoud
Linkedin http://br.linkedin.com/pub/ricardo-arnoud/15/127/3b1

[oracle_br] Re: copia de binários do oracle para outro S.O

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

bom dia! 

 Chiappa, tem como eu fazer uma nova instalação do Oracle e utilizar o spfile 
da outra instalação nesta nova instalação, para que ele reconheça todas as 
confs do outro ambiente(datafile,controlfile etc), sem a necessidade de 
realizar um restore do ambiente para esta nova instalação?? pois os dados já 
estão todos lá nos discos.

[oracle_br] Re: copia de binários do oracle para outro S.O

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

 Bem, só por questão de método : vc diz que os pacotes e configs do SO são os 
mesmos - supondo que são extamente, até o último dígito de versão, exatamente 
os mesmos, pergunto, E as libraries ?? Entenda, no linux/unix os "executáveis" 
do RDBMS são LINKADOS, ie, montados NA HORA DA INSTALAÇÂO, via comando MAKE 
(basicamente o make junta os arquivos "objeto" fornecidos pela Oracle com as 
libraries do sistema operacional) , vc tem TOTAL E ABSOLUTA CERTEZA que as 
Libraries estão na mesma exata versão e sub-versão/release, IGUAIZINHAS à 
origem ??? Por isso (ie, por não ser viável/possível se ter essa informação 
exata e confiável) é que via de regra quando se vai mudar o RDBMS para outro 
servidor se RECOMENDA reinstalar, mesmo...

 Mas isso eu só digo por uma questão de método , de ordem : não me parece que 
seja nada disso o seu problema, já que vc não recebe erro nenhum, é só a demora 
- em casos assim, normalmente é MUITO ALTA a chance de ser problema na camada 
de rede, aí é algo 100% ** FORA ** do escopo do RDBMS, o RDBMS só CONSOME a 
infra de rede fornecida pelo hardware e pelo SO A minha recomendação seria 
vc fazer um TRACE DE REDE numa sessão que está tentando se conectar (veja nos 
manuais Oracle como se faz) e junto com um export em redes analise o resultado 
e veja quais pontos estão "pegando" aí pravc... Pode ser EXTREMAMENTE ÚTIL, 
também, vc comparar o trace de rede desse servidor contra um trace de rede 
similar feito no outro ambiente onde está funcionando normal 
  
[]s

  Chiappa

[oracle_br] Re: copia de binários do oracle para outro S.O

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

Bom dia! 

 Pessoal, a máquina está no Brasil, e a conexão que eu estou fazendo é local, a 
minha conexão sqlplus/ as sysdba é local, na máquina do EC2, e tá demorando 
muito para responder.
 

 Uma duvida, na máquina de onde eu copiei os binários tinha um IP e Host 
diferente da máquina que está no EC2, e lá no EC2 o que eu fiz foi editar o 
listener e o tnsnames e trocar o host antigo pelo host novo.
 

 Será que isso tem haver com a lentidão?? O correto seria recriar o 
listener,tnsnames e o sqlnet novamente em vez de apenas editar e fazer a 
alteração??