twitterfacebookgoogle pluslinkedinrss feedemail

sábado, 3 de agosto de 2013

Android SDK Manager MACOSX


Depois de realizar download do SDK do Android, que agora já está com SDK e Eclipse com o Plugin ADT instalado.
http://developer.android.com/sdk/index.html

Tive dificuldades em achar o SDK Manager, que na versão Windows tem um .exe já na raiz da Pasta.
No MacOSX, você terá que executar o android que fica dentro da pasta tools, no diretório do SDK.

quarta-feira, 17 de julho de 2013

Tuning Pool de Conexão Weblogic


Uma dica valiosa para configuração do pool de conexão JDBC para o Weblogic 10.3. Esta dica deve servir para todas as versão do Weblogic.
A aplicação estava apresentando problemas de lentidão, com demora para responder as interfaces para os usuários.

Lentidão é um problema difícil de ser diagnosticado, com isso, monitorei todos os aspectos de infraestrutura e da aplicação. Uma ferramenta útil e cara que ajuda no monitoramento de performance das aplicações é o Introscope, da CA, com ela conseguimos identificar alguns gargalos da aplicação.
Identificamos que o pool de conexão estava com problemas de performance, apresentando um tempo de espera para retorno de uma conexão. Com isso, a aplicação estava esperando uma conexão do pool de conexão, com isso gerando a lentidão para a aplicação.

Para identificar este problema através do console do Weblogic, verificar em Monitoring do Pool de Conexão, os seguintes campo de Waiting for connection, demonstram problemas de performance do pool.

No exemplo, identificamos que está com uma pequena espera no tempo total. Nesse caso, não geraria lentidão aparente, mas serve como exemplo.






Pela Oracle, uma forma de resolver este problema é definir o Initial Capacity igual o Maximum Capacity.
Em ambientes produtivos não é recomendável deixar o Initial Capacity igual a 1, com isso, ele vai abrindo as conexões conforme a demanda e em caso de precisar de mais conexões, irá demandar mais recursos. 


A configuração de Initial Capacity igual a 1 é definida em ambiente de desenvolvimento na máquina local, com isso ganhamos tempo em subir o servidor. Evidênciando que abrir conexão é um processo lento e custoso para a máquina. Definindo o mesmo igual a 1, o Pool irá abrir a conexão e depois de um tempo irá fechar a mesma, conforme a demanda.
Para ilustrar este comportamento, segue abaixo um gráfico do Introscope de número de conexões no pool de conexão durante um mês. Identificamos que o mesmo vai utilizando conforme a demanda, colocando e retirando conexões no pool. Este gráfico é do pool de configuração de Inicial igual a 1 e final igual a 30.



Abaixo gerei o gráfico deste mesmo pool no período de 2 horas, nele fica mais explicito a reclamação de lentidão dos usuários. Neste tempo de abrir conexões acaba gerando lentidão para o usuário, pois o mesmo fica na espera de uma conexão livre. Pelo gráfico, identificamos que o número de conexões abertas no pool vai variando, abrindo e fechando conexões conforme a demanda.



Em sistemas com grande utilização, esta demora para abrir conexões acaba gerando grandes transtornos, podendo o servidor entrar em overload. Em sistemas com pouca utilização, vai gerar reclamação de alguns usuários e se esses usuários forem chatos, vai gerar transtornos para o responsável do sistema.
A forma de aumentar a performance deste pool, seria definir o initial capacity para 30, deixando igual ao valor máximo permitido. Pelo gráfico mensal de número de conexões, identificamos que a máxima deste pool foi de 30 conexões, talvez poderíamos aumentar o máximo para 50 e o inicial para 50, assim verificando se estas 50 conexões serão necessárias para suportar a aplicação.Para verificar a eficiência desta configuração, no gráfico abaixo que foi gerado pelo Introscope, exibindo o tempo de espera para uma conexão do pool. Este gráfico exibe o tempo médio de espera para uma conexão do pool de conexão. Até o dia 25/02, o pool estava configurado como inicial e final do mesmo valor. Contudo, no dia 26/02, algum economista de conexões, resolveu abaixar o initial capacity para igual a 1. Depois deste dia, identificamos no gráfico que começou a ter na média de 1 segundo para a espera de uma conexão, chegando no máximo a 4 segundos. Com isso o sistema começou a gerar reclamações dos usuários. Depois de analisarmos, identificamos que houve esta troca de valor do initial capacity e voltamos para o valor correto no dia 14/03. Pelo gráfico, identificamos que depois de voltar o parâmetro, o tempo de espera de uma conexões voltou para 0.


Existem outras dicas para aumentar a performance do pool de conexão no Weblogic, com o tempo vou apresentando para vocês mais dicas. Esta certamente é a mais eficiente.
Segue a documentação da oracle que fala sobre esta técnica:http://docs.oracle.com/cd/E14571_01/web.1111/e13814/jdbc_tuning.htm


quinta-feira, 11 de julho de 2013

Dica Conversão Data Hora Oracle Erro ORA-01855

Erro de conversão de Data em BD com NLS Formato Brasileiro.
Quando ocorre o erro, apresenta o seguinte erro ORA-01855.

SELECT to_date('01/01/2011 12:42 AM','mm/dd/yyyy HH:MI AM','NLS_DATE_LANGUAGE=''AMERICAN''')
FROM DUAL;

terça-feira, 21 de maio de 2013

Tuning Oracle Exadata - Escolhendo Plano de Execução Errado

O Exadata é uma solução incrível da Oracle, apresentando grande performance no retorno de informações.

O Optimizer da Oracle Exadata tem características específicas, que em alguns casos impedem o mesmo de escolher o melhor plano de execução e utilizar algumas funcionalidades do Exadata que garantem uma melhor performance no retorno da consulta ao banco de dados. Algumas consultas começaram a apresentar problemas de lentidão e com isso foi necessário realizar um tuning de Hint nas consultas, forçando o Optimizer a escolher o recurso “smart scan”, que garante a melhor forma para realizar a busca de dados.
Esta técnica de utilização deste hint especifico, sendo utilizada em qualquer outra versão do banco de dados da Oracle, não sendo o Exadata, não poderia ser nunca utilizada, pois a mesma não faz a utilização de nenhum índice, realizando uma consulta completa na tabela.
Em toda a minha experiência com banco de dados, nunca imaginei que iria solucionar um problema de performance realizando péssimas práticas de consultas.
Duas frases interessantes foram citadas em uma apresentação sobre estes problemas no Exadata, que achei bem interessante:

“Exadata is NOT a magic cure fora bad SQL!”
“However, fixing bad SQL may make Exadata appear to be a magic cure.”
O defeito descrito em alguns sites especializados, definem este problema que ocorre com o Optimizer da Oracle Exadata, como sendo que as novas features do Exadata não são reconhecidas pelo Optimizer da Oracle, que o mesmo não teve alterações significativas para suportar estas novas funcionalidades.

Por exemplo, vemos o exemplo do select abaixo:

Diversos relatórios da Oracle, indicam definir o hint  /*+ full(t) */ para forçar o recurso especial do Exadata e ganhar em performance.

Algumas querys ganharam imensa performance utilizando este Hint. Contudo, logicamente não é recomendado utilizar este Hint em todas as querys, somente para em casos de query que apresentam lentidão.
Também para trabalhar com Exadata é necessário quebrar alguns conceitos, nem todas as consultas realizadas por índices, são necessariamente as mais rápidas, com isso, em alguns casos são necessários deletar ou deixar índices invisíveis.

 

Sobre o Blog

Neste blog irei compartilhar as minhas experiências e observações. Os temas serão variados, mas com ênfase em tecnologia. Inscreva-se nos nossos canais para receber atualizações.