Re: [oracle_br] Problema em compilação
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
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
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
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
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
É ** 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
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
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: