Re: [oracle_br] Problema em compilação

2016-08-03 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
Huge Pages é uma implementação já que está agendada. Já fizemos na homologação 
e o próximo passo será no banco de produção. :) 
 

Em Quarta-feira, 3 de Agosto de 2016 13:31, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Sobre o ORA-4030, realmente houveram situações onde o erro podia ser 
contornado via _realfree_heap_pagesize_hint (veja 
http://ksun-oracle.blogspot.com.br/2015/09/limit-pga-memory-usage.html , 
http://odbablogs.blogspot.com.br/2014/09/error-ora-04030-out-of-process-memory.html
 , 
http://manishnashikkar.blogspot.com.br/2013/02/solution-to-ora-04030-out-of-process.html
 e 
http://www.oracleracexpert.com/2014/11/ora-04030-out-of-process-memory-when.html
 para refs) , mas normalmente onde se vê isso é situação de Large SGA : vc já 
pensou sobre implentação de HUGE PAGES ? Muitas vezes quando se vê cpu sendo 
usada para gerenciamento de memória a gente pensa no Linux fazendo page steal / 
gerenciamento de memória, coisa que se o servidor é dedicado a RDBMS Oracle 
apenas e tão somente não há necessidade, é o caso onde pode ser viável huge 
pages...

[]s

  Chiappa  #yiv8998844042 #yiv8998844042 -- #yiv8998844042ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8998844042 
#yiv8998844042ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8998844042 
#yiv8998844042ygrp-mkp #yiv8998844042hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8998844042 #yiv8998844042ygrp-mkp #yiv8998844042ads 
{margin-bottom:10px;}#yiv8998844042 #yiv8998844042ygrp-mkp .yiv8998844042ad 
{padding:0 0;}#yiv8998844042 #yiv8998844042ygrp-mkp .yiv8998844042ad p 
{margin:0;}#yiv8998844042 #yiv8998844042ygrp-mkp .yiv8998844042ad a 
{color:#ff;text-decoration:none;}#yiv8998844042 #yiv8998844042ygrp-sponsor 
#yiv8998844042ygrp-lc {font-family:Arial;}#yiv8998844042 
#yiv8998844042ygrp-sponsor #yiv8998844042ygrp-lc #yiv8998844042hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8998844042 
#yiv8998844042ygrp-sponsor #yiv8998844042ygrp-lc .yiv8998844042ad 
{margin-bottom:10px;padding:0 0;}#yiv8998844042 #yiv8998844042actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8998844042 
#yiv8998844042activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8998844042
 #yiv8998844042activity span {font-weight:700;}#yiv8998844042 
#yiv8998844042activity span:first-child 
{text-transform:uppercase;}#yiv8998844042 #yiv8998844042activity span a 
{color:#5085b6;text-decoration:none;}#yiv8998844042 #yiv8998844042activity span 
span {color:#ff7900;}#yiv8998844042 #yiv8998844042activity span 
.yiv8998844042underline {text-decoration:underline;}#yiv8998844042 
.yiv8998844042attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8998844042 .yiv8998844042attach div a 
{text-decoration:none;}#yiv8998844042 .yiv8998844042attach img 
{border:none;padding-right:5px;}#yiv8998844042 .yiv8998844042attach label 
{display:block;margin-bottom:5px;}#yiv8998844042 .yiv8998844042attach label a 
{text-decoration:none;}#yiv8998844042 blockquote {margin:0 0 0 
4px;}#yiv8998844042 .yiv8998844042bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8998844042 
.yiv8998844042bold a {text-decoration:none;}#yiv8998844042 dd.yiv8998844042last 
p a {font-family:Verdana;font-weight:700;}#yiv8998844042 dd.yiv8998844042last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8998844042 
dd.yiv8998844042last p span.yiv8998844042yshortcuts 
{margin-right:0;}#yiv8998844042 div.yiv8998844042attach-table div div a 
{text-decoration:none;}#yiv8998844042 div.yiv8998844042attach-table 
{width:400px;}#yiv8998844042 div.yiv8998844042file-title a, #yiv8998844042 
div.yiv8998844042file-title a:active, #yiv8998844042 
div.yiv8998844042file-title a:hover, #yiv8998844042 div.yiv8998844042file-title 
a:visited {text-decoration:none;}#yiv8998844042 div.yiv8998844042photo-title a, 
#yiv8998844042 div.yiv8998844042photo-title a:active, #yiv8998844042 
div.yiv8998844042photo-title a:hover, #yiv8998844042 
div.yiv8998844042photo-title a:visited {text-decoration:none;}#yiv8998844042 
div#yiv8998844042ygrp-mlmsg #yiv8998844042ygrp-msg p a 
span.yiv8998844042yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8998844042 
.yiv8998844042green {color:#628c2a;}#yiv8998844042 .yiv8998844042MsoNormal 
{margin:0 0 0 0;}#yiv8998844042 o {font-size:0;}#yiv8998844042 
#yiv8998844042photos div {float:left;width:72px;}#yiv8998844042 
#yiv8998844042photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv8998844042 
#yiv8998844042photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8998844042
 #yiv8998844042reco-category {font-size:77%;}#yiv8998844042 
#yiv8998844042reco-desc {font-size:77%;}#yiv8998844042 .yiv8998844042replbq 

Re: [oracle_br] Problema em compilação

2016-08-03 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Sobre o ORA-4030, realmente houveram situações onde o erro podia ser contornado 
via _realfree_heap_pagesize_hint (veja 
http://ksun-oracle.blogspot.com.br/2015/09/limit-pga-memory-usage.html , 
http://odbablogs.blogspot.com.br/2014/09/error-ora-04030-out-of-process-memory.html
 , 
http://manishnashikkar.blogspot.com.br/2013/02/solution-to-ora-04030-out-of-process.html
 e 
http://www.oracleracexpert.com/2014/11/ora-04030-out-of-process-memory-when.html
 para refs) , mas normalmente onde se vê isso é situação de Large SGA : vc já 
pensou sobre implentação de HUGE PAGES ? Muitas vezes quando se vê cpu sendo 
usada para gerenciamento de memória a gente pensa no Linux fazendo page steal / 
gerenciamento de memória, coisa que se o servidor é dedicado a RDBMS Oracle 
apenas e tão somente não há necessidade, é o caso onde pode ser viável huge 
pages...

[]s

  Chiappa

Re: [oracle_br] Problema em compilação

2016-08-03 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
Obrigado Chiappa e o Evandro, ajudaram bastante, bons argumentos/artigos para 
que esse trabalho não deixe de ser feito.Gostaria de acrescentar duas coisas:
1- Consegui convencer com que ele fizesse, pois chamei o seu gestor e simulei 
uma consulta com variável BIND e outra sem (no Oracle - PL-SQL). A diferença de 
tempo foi absurdamente grande.
2 - Obs:
Em paralelo a isso, tinha aberto um chamado com a Oracle, pois após atualizar o 
RDBMS e o grid para a versão 11.2.0.4.16 começou a aparecer na aplicação alguns 
erros 
**ORA-04030 (QERGH-hash-agg,kllcqas:kllsltba)**
Após enviar alert.log, trace files, check healthy report e muito mais, o 
engenheiro pediu para que o ulimit (stack, data) do usuário oracle no sistema 
operacional fosse modificado para "unlimited" e além disso, um parâmetro do 
database (_use_realfree_heap) fosse alterado para FALSE.
Após essa modificação, o erro continuou, **PORÉM** meu database ficou 
extremamente rápido, não tenho mais problema de desempenho (parse, cpu, elapsed 
execute sql), os eventos em espera diminuíram bastante, o DB TIME melhorou 90% 
e o gerente de TI quase me deu uma medalha por isso, confesso que fiquei 
assustado (tentei matar um elefante de um lado, e acabei matando um leão do 
outro).
Bem, isso não impede que o desenvolvedor mude a sua aplicação para o que foi 
solicitado (utilização da variável BIND), continuo na luta com o Oracle Suport 
para que esse erro ORA-04030 seja sanado.
Obrigado mais uma vez a vocês.







 

Em Quarta-feira, 3 de Agosto de 2016 10:12, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bem provável que tenha sido isso : INCLUSIVE, concatenação de strings abre 
ENORMES BRECHAS de segurança (por exemplo na questão de SQL INJECTION), então 
eu aconselho o colega que perguntou a bater nessa tecla de Segurança - via de 
regra Diretoria e Gerência não tão nem aí pra performance e estabilidade mas se 
pélam de medo dos "hackers" , então é fazer medo nisso (regra do DBA #2, 3 
regras do DBA - Savepoint 
||
||||   3 regras do DBA - Savepoint  Esse eu estou copiando 
do Database Cast sobre Disaster e Recovery (recomendo ouvir o episódio).  Bom, 
ei-las: 1ª O DBA deve educar o usuário||
|  Visualizar em savepoint.blog.br  |Visualização pelo Yahoo|
||

   ) ...

[]s

  Chiappa  #yiv9316245945 #yiv9316245945 -- #yiv9316245945ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9316245945 
#yiv9316245945ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9316245945 
#yiv9316245945ygrp-mkp #yiv9316245945hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9316245945 #yiv9316245945ygrp-mkp #yiv9316245945ads 
{margin-bottom:10px;}#yiv9316245945 #yiv9316245945ygrp-mkp .yiv9316245945ad 
{padding:0 0;}#yiv9316245945 #yiv9316245945ygrp-mkp .yiv9316245945ad p 
{margin:0;}#yiv9316245945 #yiv9316245945ygrp-mkp .yiv9316245945ad a 
{color:#ff;text-decoration:none;}#yiv9316245945 #yiv9316245945ygrp-sponsor 
#yiv9316245945ygrp-lc {font-family:Arial;}#yiv9316245945 
#yiv9316245945ygrp-sponsor #yiv9316245945ygrp-lc #yiv9316245945hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9316245945 
#yiv9316245945ygrp-sponsor #yiv9316245945ygrp-lc .yiv9316245945ad 
{margin-bottom:10px;padding:0 0;}#yiv9316245945 #yiv9316245945actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9316245945 
#yiv9316245945activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9316245945
 #yiv9316245945activity span {font-weight:700;}#yiv9316245945 
#yiv9316245945activity span:first-child 
{text-transform:uppercase;}#yiv9316245945 #yiv9316245945activity span a 
{color:#5085b6;text-decoration:none;}#yiv9316245945 #yiv9316245945activity span 
span {color:#ff7900;}#yiv9316245945 #yiv9316245945activity span 
.yiv9316245945underline {text-decoration:underline;}#yiv9316245945 
.yiv9316245945attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9316245945 .yiv9316245945attach div a 
{text-decoration:none;}#yiv9316245945 .yiv9316245945attach img 
{border:none;padding-right:5px;}#yiv9316245945 .yiv9316245945attach label 
{display:block;margin-bottom:5px;}#yiv9316245945 .yiv9316245945attach label a 
{text-decoration:none;}#yiv9316245945 blockquote {margin:0 0 0 
4px;}#yiv9316245945 .yiv9316245945bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9316245945 
.yiv9316245945bold a {text-decoration:none;}#yiv9316245945 dd.yiv9316245945last 
p a {font-family:Verdana;font-weight:700;}#yiv9316245945 dd.yiv9316245945last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9316245945 
dd.yiv9316245945last p span.yiv9316245945yshortcuts 
{margin-right:0;}#yiv9316245945 div.yiv9316245945attach-table div div a 
{text-decoration:none;}#yiv9316245945 div.yiv9316245945attach-table 

Re: [oracle_br] Problema em compilação

2016-08-03 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Bem provável que tenha sido isso : INCLUSIVE, concatenação de strings abre 
ENORMES BRECHAS de segurança (por exemplo na questão de SQL INJECTION), então 
eu aconselho o colega que perguntou a bater nessa tecla de Segurança - via de 
regra Diretoria e Gerência não tão nem aí pra performance e estabilidade mas se 
pélam de medo dos "hackers" , então é fazer medo nisso (regra do DBA #2, 3 
regras do DBA - Savepoint http://savepoint.blog.br/3-regras-do-dba/ 
 
 http://savepoint.blog.br/3-regras-do-dba/ 
 
 3 regras do DBA - Savepoint http://savepoint.blog.br/3-regras-do-dba/ Esse eu 
estou copiando do Database Cast sobre Disaster e Recovery (recomendo ouvir o 
episódio).  Bom, ei-las: 1ª O DBA deve educar o usuário
 
 
 
 Visualizar em savepoint.blog.br http://savepoint.blog.br/3-regras-do-dba/ 
 Visualização pelo Yahoo 
 
 
  
) ...

[]s

  Chiappa

Re: [oracle_br] Problema em compilação

2016-08-02 Por tôpico Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
Olá Rafael.

Realmente, o argumento do Developer foi bem fraco.

Na certa ele deve ter sacado que você não manja de Java e jogou esse verde
para você não ficar enchendo o saco dele.

Na certa o cara usa o objeto do tipo Statement no código java para executar
a query... daí monta aquela string salsicha, dando vários concats para
montar os wheres.

A única coisa que mudaria para ele usar Bind seria utilizar o objeto do
tipo PreparedStatement. Na query que ele vai rodar, utiliza o caracter '?'
onde quer que haja um bind.

Depois, para cada ?, usa-se a substituição com um setInt, setString,
setDate, etc.

tipo assim:

String query = "select ename from emp where empid=?";

PreparedStatement stmt=con.prepareStatement(query);

stmt.setInt(1,empno);

O primeiro parâmetro de setInt (1) quer dizer que é o primeiro ? que
aparece na query.

Assim, se tivesse mais, vc iria setando os valores assim: setInt(2, valor)
setInt(3,valor) etc.

Espero ter sido claro...

Agora você já tem argumento par brigar com o seu developer.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 2 de agosto de 2016 20:02, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> É ** mais que fraco **, é Risível o 'argumento' do teu desenvolver :
> pesquisa em http://asktom.oracle.com por JAVA BIND que vc vai achar PELO
> MENOS uma dúzia de artigos que discutem algumas opções/best practices de
> como implementar BINDING em java/jdbc e demonstram os graves problemas que
> podem advir de não usar, E além disso ainda educam sobre a Recomendação e
> as Palpáveis Vantagens de usar PREPARED STATEMENT 
>  Nós sabemos que desenvolvedor é aquela água, neguim não quer saber de
> usar o banco de dados da maneira correta mas sim da maneira que ELE acha
> ser mais fácil, depois quando a coisa chega no ventilador a culpa é do DBA,
> ele VAI dar as maiores desculpas pra não aprender a usar a tecnologia de
> maneira correta, sim sim, mas pelo menos vc tem que deixar Claro (não só
> pra ele MAS pro gerente e pros Superiores de vcs) os Riscos (de
> performance, de mal-uso da capacidade de hardware, até de Segurança) a que
> estão sujeitos por não usar BIND VARIABLES e não acessar/trabalhar com o
> RDBMS da maneira correta e adequada...
>
> ´[]s
>
>Chiappa
> 
>


Re: [oracle_br] Problema em compilação

2016-08-02 Por tôpico jlchia...@yahoo.com.br [oracle_br]
É ** mais que fraco **, é Risível o 'argumento' do teu desenvolver : pesquisa 
em http://asktom.oracle.com por JAVA BIND que vc vai achar PELO MENOS uma dúzia 
de artigos que discutem algumas opções/best practices de como implementar 
BINDING em java/jdbc e demonstram os graves problemas que podem advir de não 
usar, E além disso ainda educam sobre a Recomendação e as Palpáveis Vantagens 
de usar PREPARED STATEMENT 
 Nós sabemos que desenvolvedor é aquela água, neguim não quer saber de usar o 
banco de dados da maneira correta mas sim da maneira que ELE acha ser mais 
fácil, depois quando a coisa chega no ventilador a culpa é do DBA, ele VAI dar 
as maiores desculpas pra não aprender a usar a tecnologia de maneira correta, 
sim sim, mas pelo menos vc tem que deixar Claro (não só pra ele MAS pro gerente 
e pros Superiores de vcs) os Riscos (de performance, de mal-uso da capacidade 
de hardware, até de Segurança) a que estão sujeitos por não usar BIND VARIABLES 
e não acessar/trabalhar com o RDBMS da maneira correta e adequada... 
 
´[]s

   Chiappa

Re: [oracle_br] Problema em compilação

2016-08-02 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são:
latch: row cache objectscursor: pin S wait on X

Verifiquei os principais agressores, consultando as consultas que não utilizam 
variáveis BIND com as consultas abaixo:
SELECT COUNT(SQL_TEXT), SUBSTR(SQL_TEXT,1,200) SUB_SQL_TEXT 
  FROM V$SQL 
HAVING (COUNT(SQL_TEXT) > 1000) 
GROUP BY SUBSTR(SQL_TEXT,1,200)   
ORDER BY 1;

  
SELECT   parsing_schema_name AS user_name, module,
 SUBSTR (sql_text, 1, 40) sql_text, COUNT (0) cnt,
 SUM (executions) executions
    FROM v$sqlarea
   WHERE executions < 5 AND kept_versions = 0
GROUP BY parsing_schema_name, module, SUBSTR (sql_text, 1, 40)
  HAVING COUNT (0) > 10
ORDER BY COUNT (0) DESC
/


Com a ajuda das consultas acima, mandei algumas consultas para os 
desenvolvedores deixarem de usarem variáveis literais, e passar a usar 
variáveis do tipo BIND.
O problema é que o desenvolvedor veio me falar que as consultas ficam na 
aplicação (JAVA) e que eles utilizam parâmetros, mas que esses parâmetros são 
carregados e que são enviados para o database já com as variáveis carregadas e 
que por isso, não teria como trocar por variáveis BIND.
Eu particularmente não entendo absolutamente NADA de JAVA. Achei o argumento do 
desenvolvedor muito fraco e sem muita segurança. Gostaria da opinião de vocês, 
como faço para convencer/ajudar o desenvolvedor a utilizar variáveis BIND na 
aplicação JAVA.

 

Em Terça-feira, 2 de Agosto de 2016 16:20, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  escreveu:
 

     Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são:

  #yiv4826885975 #yiv4826885975 -- #yiv4826885975ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4826885975 
#yiv4826885975ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4826885975 
#yiv4826885975ygrp-mkp #yiv4826885975hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4826885975 #yiv4826885975ygrp-mkp #yiv4826885975ads 
{margin-bottom:10px;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad 
{padding:0 0;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad p 
{margin:0;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad a 
{color:#ff;text-decoration:none;}#yiv4826885975 #yiv4826885975ygrp-sponsor 
#yiv4826885975ygrp-lc {font-family:Arial;}#yiv4826885975 
#yiv4826885975ygrp-sponsor #yiv4826885975ygrp-lc #yiv4826885975hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4826885975 
#yiv4826885975ygrp-sponsor #yiv4826885975ygrp-lc .yiv4826885975ad 
{margin-bottom:10px;padding:0 0;}#yiv4826885975 #yiv4826885975actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4826885975 
#yiv4826885975activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4826885975
 #yiv4826885975activity span {font-weight:700;}#yiv4826885975 
#yiv4826885975activity span:first-child 
{text-transform:uppercase;}#yiv4826885975 #yiv4826885975activity span a 
{color:#5085b6;text-decoration:none;}#yiv4826885975 #yiv4826885975activity span 
span {color:#ff7900;}#yiv4826885975 #yiv4826885975activity span 
.yiv4826885975underline {text-decoration:underline;}#yiv4826885975 
.yiv4826885975attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4826885975 .yiv4826885975attach div a 
{text-decoration:none;}#yiv4826885975 .yiv4826885975attach img 
{border:none;padding-right:5px;}#yiv4826885975 .yiv4826885975attach label 
{display:block;margin-bottom:5px;}#yiv4826885975 .yiv4826885975attach label a 
{text-decoration:none;}#yiv4826885975 blockquote {margin:0 0 0 
4px;}#yiv4826885975 .yiv4826885975bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4826885975 
.yiv4826885975bold a {text-decoration:none;}#yiv4826885975 dd.yiv4826885975last 
p a {font-family:Verdana;font-weight:700;}#yiv4826885975 dd.yiv4826885975last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4826885975 
dd.yiv4826885975last p span.yiv4826885975yshortcuts 
{margin-right:0;}#yiv4826885975 div.yiv4826885975attach-table div div a 
{text-decoration:none;}#yiv4826885975 div.yiv4826885975attach-table 
{width:400px;}#yiv4826885975 div.yiv4826885975file-title a, #yiv4826885975 
div.yiv4826885975file-title 

[oracle_br] Problema em compilação

2016-08-02 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são: