Re: RES: RES: RES: [oracle_br] Re: p erfor mance em função
Bem, alguma coisa não bate lá muito bem nessas informações : primeiro, se "Segundo o fornecedor a consulta é simples, sem ordenação, sem where e sem join", não vejo AONDE exatamente novos índices poderiam ser úteis, a não ser que OU existam funções de grupo que possam ser satisfeitas pelos índices OU então (algo possível) a query é mesmo um simples SELECT FROM X; , sem where nem order nem nada, mas Acontece que X é uma view complexa, que faz de tudo e pôde utilizar índices Algo a se verificar - e se eu fosse vc, tentaria via algum tipo de trace (e junto com o Suporte do fornecedor) obter o SQL real que o banco tá executando, os valores de BIND e tudo o mais, pra poder analisar e entender EXATAMENTE o que estava pegando, qual o plano antes & depois, qual foi Exatamente a ação do Fornecedor... Sem isso, amanhã alguém altera alguma coisa de novo e vc tá sem saber o que fazer, de novo... Sobre a "bolinha verde" no SQL DEVELOPER : afaik esse ícone indica simplesmente que a rotina PL/SQL foi compilada com a opção de DEBUG, e some quando vc compila sem ela... Compilar em modo DEBUG coloca realmente um pouqinho mais de info no p-code PL/SQL, gera um tantinho de overhead mas deveria ser algo mínimo do mínimo, difícil até de quantificar Não me parece que isso por si só possa explicar o seu cenário, mas testa num ambiente Homologação e veja se casualmente no seu ambiente por qquer motivo a compilação com e sem informação adicional de debug tá dando uma diferença tão larga e significativa assim... []s Chiappa
[oracle_br] Novo artigo: Anatomia de utilização de memória em servidores Linux
Olá amigos! Estrando no blog, Carlos Furushima com esse excelente artigo: http://certificacaobd.com.br/2014/12/23/oracle-anatomia-de-utilizacao-de-memoria-em-servidores-linux/ Att,
RES: RES: RES: [oracle_br] Re: perfor mance em função
Chiappa, voltou a normalidade. Pelo SQL Developer, a função estava com uma bolinha verde, recompilei ela e não tem mais o gargalho. O fornecedor criou alguns índices e melhorou algumas views. Como conhecimento não é demais, estarei olhando os links para um aprofundamento dos eventos. De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: terça-feira, 23 de dezembro de 2014 16:07 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: RES: [oracle_br] Re: perfor mance em função Sem esses detalhes todos que citei, fica Bem Difícil se dizer seja o que for sem ser um belo dum chutão AO MENOS o tal fornecedor (ou vc mesmo, se vc tiver acesso ao database e puder extrair o texto exato da query em questão) tem que fazer esses testes mínimos que eu disse - ie, checar o texto do SQL e ver AONDE a tal função está sendo chamada, tentar extrair os Planos e as estats de execução (tais como tempo geral e de CPU gasto, número de linhas processadas, entre outros) na V$SQL a partir duma execução dum SQL equivalente mas sem função e depois com uma função dummy/mínima... Senão, rigorosamente Qualquer Coisa que digamos aqui vai estar pra chute, yes ??? PRINCIPALMENTE esse teste do SQL sem função alguma, ele vai ser Extremamente revelador , penso eu... Sobre o evento de wait "Library cache:x", normalmente ele aparece quando muitas e múltiplas execuções da mesma exata rotina PL/SQL estão ocorrendo, https://andreynikolaev.wordpress.com/2011/05/01/divide-and-conquer-the-true-mutex-contention/ tem um testcase... Dá uma olhada em http://www.wellingtonprado.com/2012/05/04/library-cache-mutex-x-e-agora/ que o Autor fala um pouco também dum cenário desses, E não deixe (como eu disse antes) de checar no Suporte Oracle por possíveis bugs de gasto de CPU em funções, e também com mutexes - afaik os principais bugs de mutexes já foram corrigidos no 11.2.0.3 que é a sua versão, mas vale SIM um check... Só repito : São os testes acima que vão te dar subsídios se a tal função realmente está sendo executada muitos milhares de vezes porque está sendo chamada numa query associada com tabelas de muitos e muitos milhares de linhas (caso em que, como eu disse na msg original, vc TALVEZ possa mitigar esse efeito implementando cache de resultados, vide os links que passei)... Mas antes de sair fazendo SEJA O QUE FOR, plz FAÇA OS TESTES ANTES, ok ? []s Chiappa
Re: RES: RES: [oracle_br] Re: perfor mance em função
Sem esses detalhes todos que citei, fica Bem Difícil se dizer seja o que for sem ser um belo dum chutão AO MENOS o tal fornecedor (ou vc mesmo, se vc tiver acesso ao database e puder extrair o texto exato da query em questão) tem que fazer esses testes mínimos que eu disse - ie, checar o texto do SQL e ver AONDE a tal função está sendo chamada, tentar extrair os Planos e as estats de execução (tais como tempo geral e de CPU gasto, número de linhas processadas, entre outros) na V$SQL a partir duma execução dum SQL equivalente mas sem função e depois com uma função dummy/mínima... Senão, rigorosamente Qualquer Coisa que digamos aqui vai estar pra chute, yes ??? PRINCIPALMENTE esse teste do SQL sem função alguma, ele vai ser Extremamente revelador , penso eu... Sobre o evento de wait "Library cache:x", normalmente ele aparece quando muitas e múltiplas execuções da mesma exata rotina PL/SQL estão ocorrendo, https://andreynikolaev.wordpress.com/2011/05/01/divide-and-conquer-the-true-mutex-contention/ tem um testcase... Dá uma olhada em http://www.wellingtonprado.com/2012/05/04/library-cache-mutex-x-e-agora/ que o Autor fala um pouco também dum cenário desses, E não deixe (como eu disse antes) de checar no Suporte Oracle por possíveis bugs de gasto de CPU em funções, e também com mutexes - afaik os principais bugs de mutexes já foram corrigidos no 11.2.0.3 que é a sua versão, mas vale SIM um check... Só repito : São os testes acima que vão te dar subsídios se a tal função realmente está sendo executada muitos milhares de vezes porque está sendo chamada numa query associada com tabelas de muitos e muitos milhares de linhas (caso em que, como eu disse na msg original, vc TALVEZ possa mitigar esse efeito implementando cache de resultados, vide os links que passei)... Mas antes de sair fazendo SEJA O QUE FOR, plz FAÇA OS TESTES ANTES, ok ? []s Chiappa
RES: RES: [oracle_br] Re: performance em função
Chiappa,
Segundo o fornecedor a consulta é simples, sem ordenação, sem where e sem join,
é o que tenho de detalhes sobre a sua utilização. Gerei um trace de uma sessão
agora, e me chamou a atenção o evento MUTEX X:
call count cpuelapsed disk querycurrentrows
--- -- -- -- -- -- --
Parse0 0.00 0.00 0 0 0 0
Execute 256680 21.98 80.68 0 0 0 0
Fetch 256679 7.01 271.58 0 0 0 256679
--- -- -- -- -- -- --
total 513359 28.99 352.27 0 0 0 256679
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 27 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
Waited --
library cache: mutex X 27403.97470.98
cursor: pin S 421.44 7.58
latch free 10.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpuelapsed disk querycurrentrows
--- -- -- -- -- -- --
Parse0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch0 0.00 0.00 0 0 0 0
--- -- -- -- -- -- --
total0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
Waited --
asynch descriptor resize 19700.00 0.00
latch: row cache objects 1110.54 5.11
buffer busy waits 240.65 1.55
latch: cache buffers chains 1290.65 10.11
latch free 40.35 0.63
wait list latch free20.03 0.04
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpuelapsed disk querycurrentrows
--- -- -- -- -- -- --
Parse0 0.00 0.00 0 0 0 0
Execute 256680 21.98 80.68 0 0 0 0
Fetch 256679 7.01 271.58 0 0 0 256679
--- -- -- -- -- -- --
total 513359 28.99 352.27 0 0 0 256679
Misses in library cache during parse: 0
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
Waited --
library cache: mutex X 27403.97470.98
cursor: pin S 421.44 7.58
latch free 10.00 0.00
Não tenho muitos detalhes do funcionamento interno dessa função na aplicação,
resumidamente foi o que te passei, passa-se uns parâmetros e ele retorna uma
string, não tem consulta a nenhuma tabela dentro da função.
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
Enviada em: terça-feira, 23 de dezembro de 2014 15:12
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] Re: performance em função
Colega, vc ** não respondeu ** o que eu perguntei : a função é usada no SELECT,
no WHERE, no ORDER BY, em QUAL lugar ?? o Plano de execução sem a dita-cuja é
diferente ?? A tal "validação" usa regexp, XML ou quetais ?? PO estar
acontecendo o caso de que a função em si roda em menos de um segundo mas está
sendo aplicada em não-sei-quantas centenas de milhares de linhas e assim
PORTANTO está levando DEZENAS de milhares de segundos na soma total ?? Vc FEZ
um teste da query fazendo a tal "validação de strings" em SQL puro, assim
EVITANDO context-switch e cia bela ?? Plz detalhes
[]s
Chiapp
Re: RES: [oracle_br] Re: performance em função
Colega, vc ** não respondeu ** o que eu perguntei : a função é usada no SELECT, no WHERE, no ORDER BY, em QUAL lugar ?? o Plano de execução sem a dita-cuja é diferente ?? A tal "validação" usa regexp, XML ou quetais ?? PO estar acontecendo o caso de que a função em si roda em menos de um segundo mas está sendo aplicada em não-sei-quantas centenas de milhares de linhas e assim PORTANTO está levando DEZENAS de milhares de segundos na soma total ?? Vc FEZ um teste da query fazendo a tal "validação de strings" em SQL puro, assim EVITANDO context-switch e cia bela ?? Plz detalhes []s Chiappa
RES: [oracle_br] performance em função
André, só validação simples de strings, nada complexo. Eu executo direto no banco, SQL Developer, e o retorno é instantâneo. De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: terça-feira, 23 de dezembro de 2014 14:19 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] performance em função Márcio A função tem algum algoritmo muito complexo ou com estruturas de repetição? [ ] André Em 23 de dezembro de 2014 13:02, 'Grupos' marcio_...@yahoo.com.br [oracle_br] escreveu: Boas! Estou com um select em uma função que está com um performance péssima. Como são várias conexões, esse select está elevando o consumo da minha CPU para 90%. Todas outras instruções no banco são executadas na normalidade, somente esse select na função. Verifiquei a função, e não tem consulta em tabela, apenas verificação. Alguém passou problema de performance na função, a função tem variáveis bind, como verificar o que realmente eleva esse alto consumo? Oracle 11.2.0.3 HP-UX Instância única para esse banco.
RES: [oracle_br] Re: performance em função
A função não faz consulta a dados nenhum, são passados alguns parâmetros e de acordo ele retorna o resultado, dentro da função é apenas algumas validações de strings. Já eu executando essa função direto no banco, SQL Developer, o retorno é em milissegundos. A consulta está vindo de uma aplicação Web criada em cima de um IIS. De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: terça-feira, 23 de dezembro de 2014 14:17 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: performance em função Opa, pra começo de conversa PL/SQL sendo chamado de dentro de um comando SQL é quase sempre uma Péssima *** idéia : pesquisa em asktom.oracle.com que vc vai encontrar artigos faklando sobre as issues que vc pode/vai encontrar, como por exemplo context switch (já que isso força o RDBMS a ficar "pulando" entre os engibes de SQL e de PL/SQL, o que consome SIM cpu : https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:5173758137186#20839207575486 é um dos exemplos que vc vai encontrar), OU então o fato Inescapável de que se vc está passando valores presentes em linhas de uma tabela pra rotina PL/SQL, vc LOGICAMENTE vai ter que executar a rotina PL/SQL uma vez para cada valor possível diferente. Essa última questão pode ser mitigada no banco 11g com o CACHE DE RESULTADOS (veja oracle-base.com/articles/misc/efficient-function-calls-from-sql.php e http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51asktom-453438.html para exemplos), mas o IDEAL é fugir desses custos... Isso posto, se vc REALMENTE, ABSOLUTAMENTE, TEM QUE chamar a rotina PL/SQL de dentro do SQL, pra gente poder responder melhor plz nos diga : a) a função está sendo usada só na cláusula de SELECT da query, ** OU ** está sendo referenciada no WHERE, no ORDER BY e/ou em outros pontos ?? Se não é só no SELECT, vc tem *** ENORMES *** chances da função estar causando mudanças negativas no Plano de Execução : por exemplo, a função está alterando uma coluna indexada, ou - já que OBVIAMENTE o CBO não consegue saber qual valor a função retorna, então não tem como usar nem Histogramas nem as estatísticas de que ele dispõe - o CBO não consegue Otimizar o plano, por aí... b) a função que vc está chamando tem a ver com as built-ins de XML ? Se sim, CONFIRA as correções presents nos patchsets 11.2.0.3 e 11.2.0.4, pois bugs como o 9919654 tipicamente tendem a se fazxer presentes com funções XML, que por natureza são complexas (tendem a fazer montes de SUBSTR/INSTR) e recursivas c) a tal função faz processamento ** pesado ** de strings, tipo expressões regulares ?? Se sim, cfrme https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:6071446400346871004#608340346455747 alerta, vc VAI SIM encontrar um overhead ao utilizar as built-ins de regex ao invés das funções primitivas de string do PL/SQL ==> Sobre debug : o primeiro e óbvio passo é testar a tal query ** SEM ** a função, depois testar com uma função dummy (ie, que só faça um comando simples, tipo um NOP, ou uma adição se o valor for numérico, ou seja, alguma coisa mínima, só pra testar) SE os testes acima retornaram o mesmo plano de execução mas consumiram muito menos CPU, vc já Provou que é a rotina em si que não está Otimizada ao máximo, é partir pro TUNING dela, ou então (o Melhor, como dito no início) substituir a rotina PL/SQL por built-ins SQL... []s Chiappa
Re: [oracle_br] performance em função
Márcio A função tem algum algoritmo muito complexo ou com estruturas de repetição? [ ] André Em 23 de dezembro de 2014 13:02, 'Grupos' marcio_...@yahoo.com.br [oracle_br] escreveu: > > > Boas! > > > > Estou com um select em uma função que está com um performance péssima. > Como são várias conexões, esse select está elevando o consumo da minha CPU > para 90%. > > > > Todas outras instruções no banco são executadas na normalidade, somente > esse select na função. Verifiquei a função, e não tem consulta em tabela, > apenas verificação. > > > > Alguém passou problema de performance na função, a função tem variáveis > bind, como verificar o que realmente eleva esse alto consumo? > > > > Oracle 11.2.0.3 > > HP-UX > > Instância única para esse banco. > > >
[oracle_br] Re: performance em função
Opa, pra começo de conversa PL/SQL sendo chamado de dentro de um comando SQL é quase sempre uma Péssima *** idéia : pesquisa em asktom.oracle.com que vc vai encontrar artigos faklando sobre as issues que vc pode/vai encontrar, como por exemplo context switch (já que isso força o RDBMS a ficar "pulando" entre os engibes de SQL e de PL/SQL, o que consome SIM cpu : https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:5173758137186#20839207575486 é um dos exemplos que vc vai encontrar), OU então o fato Inescapável de que se vc está passando valores presentes em linhas de uma tabela pra rotina PL/SQL, vc LOGICAMENTE vai ter que executar a rotina PL/SQL uma vez para cada valor possível diferente. Essa última questão pode ser mitigada no banco 11g com o CACHE DE RESULTADOS (veja oracle-base.com/articles/misc/efficient-function-calls-from-sql.php e http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51asktom-453438.html para exemplos), mas o IDEAL é fugir desses custos... Isso posto, se vc REALMENTE, ABSOLUTAMENTE, TEM QUE chamar a rotina PL/SQL de dentro do SQL, pra gente poder responder melhor plz nos diga : a) a função está sendo usada só na cláusula de SELECT da query, ** OU ** está sendo referenciada no WHERE, no ORDER BY e/ou em outros pontos ?? Se não é só no SELECT, vc tem *** ENORMES *** chances da função estar causando mudanças negativas no Plano de Execução : por exemplo, a função está alterando uma coluna indexada, ou - já que OBVIAMENTE o CBO não consegue saber qual valor a função retorna, então não tem como usar nem Histogramas nem as estatísticas de que ele dispõe - o CBO não consegue Otimizar o plano, por aí... b) a função que vc está chamando tem a ver com as built-ins de XML ? Se sim, CONFIRA as correções presents nos patchsets 11.2.0.3 e 11.2.0.4, pois bugs como o 9919654 tipicamente tendem a se fazxer presentes com funções XML, que por natureza são complexas (tendem a fazer montes de SUBSTR/INSTR) e recursivas c) a tal função faz processamento ** pesado ** de strings, tipo expressões regulares ?? Se sim, cfrme https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:6071446400346871004#608340346455747 alerta, vc VAI SIM encontrar um overhead ao utilizar as built-ins de regex ao invés das funções primitivas de string do PL/SQL ==> Sobre debug : o primeiro e óbvio passo é testar a tal query ** SEM ** a função, depois testar com uma função dummy (ie, que só faça um comando simples, tipo um NOP, ou uma adição se o valor for numérico, ou seja, alguma coisa mínima, só pra testar) SE os testes acima retornaram o mesmo plano de execução mas consumiram muito menos CPU, vc já Provou que é a rotina em si que não está Otimizada ao máximo, é partir pro TUNING dela, ou então (o Melhor, como dito no início) substituir a rotina PL/SQL por built-ins SQL... []s Chiappa
[oracle_br] performance em função
Boas! Estou com um select em uma função que está com um performance péssima. Como são várias conexões, esse select está elevando o consumo da minha CPU para 90%. Todas outras instruções no banco são executadas na normalidade, somente esse select na função. Verifiquei a função, e não tem consulta em tabela, apenas verificação. Alguém passou problema de performance na função, a função tem variáveis bind, como verificar o que realmente eleva esse alto consumo? Oracle 11.2.0.3 HP-UX Instância única para esse banco.
