30 de ago. de 2008

Curso de Performance e Tuning – Oracle 10g

Boa noite, acabei hoje meu curso de performance e Tuning. Apesar do curso não suprir tudo sobre a otimização, desempenho e performance, esclareceu algumas duvidas, e me ajudou muito em algumas coisas que estou estudando para o OCP. Umas das minhas duvidas era a respeito do KEEP_SIZE,Checkpoint e algumas coisas de Redo Online.

    Essa semana vai ser ótima para fazer alguns testes e realizar algumas verificações nos ambientes a qual administro. Espero colocar minhas experiências aqui, compartilhando conhecimentos. O primeiro trabalho a ser realizado será a verificação dos pontos fundamentais para desempenho no banco de dados. Ao longo da semana irei fazendo atualizações com notas realizadas. E com algumas notas da ORACLE (Best Pratices).

Abraços.

10 de jul. de 2008

JOB no Oracle 10G

Nossa nunca pensei que iria apanhar no agendamento de tarefas no Oracle (por ser uma atividade relativamente simples). Depois de vários erros abaixo igual os abaixo achei a solução:

ERRO na linha 1:
ORA-06550: line 1, column 23:
PLS-00363: expression '377' cannot be used as an assignment target
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

ERRO na linha 2:
ORA-06550: line 2, column 67:
PLS-00103: Encountered the symbol "SYSDATE" when expecting one of the following:
) , * & | = - + < / > at in is mod remainder not rem => ..
<um expoente (**)> <> or != or ~= >= <= <> and or like LIKE2_
LIKE4_ LIKEC_ between || multiset member SUBMULTISET_
The symbol "," was substituted for "SYSDATE" to continue.

Solução:

15:33:56 SQL> execute DBMS_JOB.iSUBMIT(377, 'SUPORTERJ.BCS_P_WEB_AGENTE;', SYSDATE,'(TRUNC(SYSDATE)+ 1)+3/24');
Procedimento PL/SQL concluído com sucesso.

Decorrido: 00:00:00.63

15:34:17 SQL> execute DBMS_JOB.REMOVE(377);
Procedimento PL/SQL concluído com sucesso.

8 de jul. de 2008

Bind Variables – Parametro Cursors_Sharing

Estou trabalhando em um banco de dados onde as consultas que são executadas com os valores fixos nos selects. Fazendo um levantamento nas querys que mais consomem pelo AWR, consegui levantar uma consulta 25 vezes, com 25 vezes levantadas em memória pois o CURSOR_SHARING está setado para EXACT.

O parâmetro Cursor_Sharing aceita 3 valores, sendo eles: FORCE, SIMILAR e EXACT

EXACT – é o padrão para banco de dados Oracle. O parâmetro EXACT envia ao otimizador do Oracle que toda e qualquer instrução deve ser igual inclusive os valores literais. Esse parâmetro é mais utilizado em ambientes que as instruções executadas não possui valores similares.

FORCE – O parâmetro troca as variáveis literais por valores bind, em sua execução, fazendo com que o HARD-PARSE se transforme em SOFT. O valor FORCE no parametro CURSOR_SHARING, gera apenas 1 plano de execução.

SIMILAR – O parâmetro troca as variáveis literais por valores bind, em sua execução, fazendo com que o HARD-PARSE se transforme em SOFT. O valor SIMILAR no parametro CURSOR_SHARING, gera mais de um plano de execução (se a tabela estiver com a coleta de estatísticas atualizada).

----TESTES-----

Meu primeiro passo é testar a performance de cada um desses comandos, vou habilitar o trace para buscar o HARD PARSE e SOFT PARSE de cada uma das consultas executadas. Meu primeiro desafio encontrado foi que o Trace não funcionava!! Tentei de tudo, fiquei até 23hs no serviço incomodando muita gente. Quase indo embora executei o comando:

SHOW PARAMETERS TRACE

E me trouxe uma peça importante:

trace_enabled boolean FALSE

Achei que esse parâmetro tinha alguma coisa a ver com minha dificuldade. Hoje confirmei com meu outro amigo DBA Rubens (FCESP) que esse parâmetro habilitar a geração do trace.Após o trace a recompensa! Achei que a diferença ia ser muito baixa fiz os testes rodando o mesmo conjunto de SQL (utilizando variáveis bindadas), mas para minha felicidade foram altas.

Segue abaixo os valores encontrados:


 

EXACT


 

FORCE



 

SIMILAR


 


Conclusão:

Para alteração nesse parâmetro faça o levantamento de instruções SQL sendo executadas no banco de dados e verifique a possibilidade de alteração para Bind Variables. Se verificado que não há possibilidade de alteração devido tempo (o principal fator), averigúe a possibilidade de alteração do parâmetro fazendo antes um levantamento no ambiente.


 

7 de jul. de 2008

Avisos dos Advisores na pagina principal do DbConsole

Consultando os avisos do Advisors gerados na pagina principal do DBConsole.

--ALERTAS AINDA NAO RESOLVIDOS
SELECT REASON,
OBJECT_TYPE TYPE,
OBJECT_NAME NAME
FROM DBA_OUTSTANDING_ALERTS;

--ALERTAS RESOLVIDOS NO DBA_OUTSTANDING_ALERTS
SELECT REASON,
OBJECT_TYPE TYPE,
OBJECT_NAME NAME
FROM DBA_ALERT_HISTORY;

18 de jun. de 2008

AWR - SQL Costs

Segue abaixo o sql para extrair do Awr as instruções mais impactantes:

spool INSTRUCOES_IMPACTANTES.LOG
col c1 heading ‘SQLID’ format a13

col c2 heading ‘Cost’ format 9,999,999
col c3 heading ‘SQL Text’ format a200

select p.sql_id c1,
p.cost c2,
DBMS_LOB.SUBSTR(s.sql_text,4000,1) c3
from dba_hist_sql_plan p,
dba_hist_sqltext s
where p.id = 0
and p.sql_id = s.sql_id
and p.cost is not null
order by p.cost desc;

spool off

15 de jun. de 2008

SendMail - Configurações.

Segue abaixo configurações do SendMail do Linux.

Removendo o SendMail do Startup do RedHat
chkconfig --del sendmail

Adicionando o SendMail no Startup do RedHat
chkconfig --add sendmail

Verificando Status do SendMail
chkconfig --list sendmail

31 de mai. de 2008

AWR configurações básicas

Awr - Statistics Level

Verificar parametro STATISTICS_LEVEL:
show parameter STATISTICTS_LEVEL

Parametros aceitos:

Typical (DEFAULT) - Força obtenção de todas estátisticas necessárias para o ajuste normal sem se coletar nehuma estátistica cuja obtenção teria um impacto adverso sobre o desempenho.

Basic - Desabilita praticamente todas as estátisticas, sem nenhum beneficio apreciavel em termos de desempenho

All - Coleta estátisticas extremamente detalhadas sobre a execução de instruções SQL, mas podem causar uma ligeira queda de desempenho quando estiverem sendo coletadas.

-------------

As estátisticas são armazenas em memoria, e isso é executado a cada 60 minutos escrito em disco. O processo que escreve é o processo MONITOR DE GERENCIABILIDADE ou MMON.

O MMON tem acesso direto a estruturas de memoria que compoe a SGA.

O AWR se localiza no tablespace SYSAUX e não pode ser movido para nenhum outro lugar.

Relátorios ADDM são mantidos por 30 dias.