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.

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.

 

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;