Real World Performance 2013 – O GPO esteve lá !
Acordo ás 07:30 minutos , realizo as rotinas matinais tais quais banho ,passar a uma blusa, escovar os dentes e etc., confesso que não estou muito animado para o real world performance, assisti a palestra ano passado no guob tech day e sabia que 90% da abordagem era baseada no exadata e acredito que menos que 5% dos DBAs do nosso país tem a possibilidade de brincar com esse brinquedo.
Chego ao evento e de cara no credenciamento sinto um clima diferente, sim diferente de 99% dos outros eventos aos quais estive presente esse é no RJ, e por ser na minha cidade logo na entrada encontro amigos e conhecidos de longa data, e como é bom reencontrar antigos amigos de trabalho, de faculdade, pessoas que por diversidade da vida você perde certo contato, mas que você guarda carinho e lembranças de boas risadas, e eventos como esse te permite encontrar esses amigos que entendem as piadas com “chuck norris dba”, confesso que após o papo inicial com as pessoas minha animação para a palestra aumentou.
Credenciamento finalizado, todos de barriga parcialmente cheia porque o coffe break dos eventos do GUOB sempre é bom, vamos para o inicio do evento. Ao longo dos 20 minutos iniciais eu percebo que o evento não vai ser um “repeteco” do que assisti no ano passado, quando o tio tom (apelido carinhoso para o mestre tom kyte) começa a falar do que estar por vir durante o dia ,começo a perceber que um grande evento esta por vir.
Os palestrantes focaram bastante na primeira parte do dia em diferenciar os ambientes OLTP dos ambientes de DW(data warehouse), mostraram que é preciso entender que técnicas eficientes em um ambiente podem ser totalmente ineficientes no outro, como exemplo o uso de índices que precisam ser totalmente repensado em um ambiente DW.
Com uma divisão onde tínhamos 3 monitores com cada palestrante utilizando um e representando um papel (Arquiteto, Desenvolvedor, DBA) eles mostraram diversos cenários e pontos de performance. Gostaria de explicar todos, mas ai esse post não seria um resumo e sim livro, então enumerei abaixo os pontos aos quais eu achei mais interessante.
- Pense no número de conexões que você abre com banco de dados, esse número precisa ser proporcional ao número de CPUs do banco de dados, se a aplicação esta sobrecarregada não podemos aumentar o número de conexões e pensar que isso é solução, precisamos analisar e controlar o número de conexões que o pool envia para o banco de dados, por isso tenham extremo cuidado com pool de conexões dinâmicos.
- Caso tenha uma demanda de conexões muito alta, não aumente simplesmente o parâmetro processes e sim crie uma fila na camada da aplicação, caso o administrador do sistema reclame, peça um teste e tire suas próprias conclusões.
- Nunca faça a aplicação conectar diretamente ao banco de dados, é muito caro o custo de um logon/logoff é mais custoso que um parse de um SQL, sempre gerencie e reutilize conexões do seu pool.
- Log file sync, log file paralel write são eventos de espera muito prejudiciais ao desempenho, ter discos separados para os redo logs é o básico de performance do Oracle , sabemos que o maior gargalo dele são os logs, logo não tem como ter aplicações escaláveis e com performance se não separamos os redo logs dos demais discos.
- Se você ainda tem problema com os redo logs e se seus commits e se você PODE PERDER algumas transações e lidar com isso sem problemas para seu negocio , cogite usar o asynchronous commit essa feature permite que os commits respondam em tempo real sem esperar a confirmação de gravação dos logs.
Ps: Eu acredito que se você tem esse cenário você não precisa gastar rios de dinheiro com o Oracle, mas um amigo que trabalha em uma telecom onde licenças não são problema, me disse que existem diversas aplicações onde você pode perder transações e que essa feature era muito interessante pois nessas aplicações mas importa o tempo de resposta que a integridade, fiquei pensando, agora eu sei porque as operadoras de telefonia tem essa qualidade de serviço.
- Variaveis Bind, velho tópico e velho problema, é preciso conscientizar os desenvolvedores sobre isso, o Tom kyte fala disso há 15 anos, eu 6 anos, é repetitivo mas não podemos deixar de falar, um DBA até pode transformar um hard parse em soft parse, mas eliminar o hard parse somente um desenvolvedor pode.
- Tenha cuidado com o numero de cursores abertos (parametro open_cursors) , lembre que esse parâmetro é para a sessão, verifique se os cursores estão sendo fechados, caso contrário efetue o mapeamento dos casos e sente do lado do desenvolvedor para resolver o problema. PS: Eu sei que tem casos que isso é impossível, então fica aquele velho script fechando os cursores e matando sessões inativas, mas nunca aumente o open_cursores para números absurdos.
- Estatísticas são vitais para uma boa cardinalidade e conseqüentemente para uma boa estimativa de linhas estimadas para um plano de execução.
- Em tabelas particionadas sempre colha estatísticas das partições e da tabela global, caso contrario você pode ter problemas.
Esse foi o Real World Performance, mas um evento super bem organizado pelo GUOB, parabéns ao Eduardo Hahn pela organização e para quem foi ficou uma sensação que vem muita coisa boa no GUOB TECH DAY desse ano, agradeço ao convite de cobrir o evento ao Willians,Victor e o Roberto, e nos encontramos dia 10 de agosto no GUOB TECH DAY.
Abraço
