Um caso que ocorre com frequência é ter estruturas hierárquicas em tabelas. Um exemplo típico será uma tabela empregado, que pode ter e/ou ser um supervisor. Ou seja, temos uma chave estrangeira que aponta para a chave da própria tabela, algo tipo

ID_EMP  NOME           SUPERVISOR
------- -------------- ------------
1       João           NULL
2       Pedro          1
3       Ricardo        1
4       José           2

Em que o João é supervisor do Pedro e do Ricardo e o Pedro é supervisor do José.

Por vezes, temos uma estrutura deste tipo mais ou menos complexa, com mais ou menos níveis de profundidade e queremos saber, com base num identificador, todos os resultados hierarquicamente – neste caso, ao perguntar quais os supervisionados hierárquicos do João, teríamos o Pedro, Ricardo e José.

Tipicamente, até agora fazia uma função em pl/sql que fizesse isto pois não conhecia algumas das facilidades que o Oracle fornece para isto.

Introducing CONNECT BY

DBAs e pessoal com alguma experiência em Oracle deve conhecer isto, mas para mim foi uma novidade e foi-me imensamente útil.
Com esta directiva, consigo fazer o seguinte:

SELECT
  NOME, LEVEL
FROM
  EMPREGADO
START WITH
  NOME='João'
CONNECT BY NOCYCLE
  PRIOR ID = SUPERVISOR

O resultado desta query seria aproximado a:

NOME           LEVEL
-------------- -------
João           1
Pedro          2
Ricardo        2
José           3

O que se fez foi dizer que queríamos começam com o registo com o nome João e “ligá-lo” aos seus filhos. Isto é feito com a cláusula CONNECT BY e usando PRIOR num dos campos. Podemos pensar seguindo da raiz, de registo em registo iterativamente, sendo que na primeira iteração o PRIOR ID é o campo do registo raiz e estamos a seleccionar como próximos campos, todos os que tenham SUPERVISOR = PRIOR ID.
A palavra NOCYCLE é para não se entrarem em ciclos e a coluna LEVEL que está a ser usada é uma pseudo-coluna que indica o nível em que está o registo em relação à raiz (sendo a raiz o nível 1).

Podem encontrar uma explicação mais completa aqui.

Nos últimos tempos tenho trabalhado com jobs em base de dados Oracle.
Mesmo que a base de dados utilizada fosse a 10g é ainda utilizado o DBMS_JOB. Recentemente li o [1] e descobri o DBMS_SCHEDULER.

Dou dois exemplos de dificuldades que senti com o DBMS_JOB:

• definir o intervalo de execução: fraca legibilidade, demasiado código para conseguir o agendamento desejado;
• configurar o deploy de um job: apenas um campo númérico identifica univocamente o job na lista.

Neste post vou falar sobre o segundo ponto: o deploy de um job.

Oracle 9i: o DBMS_JOB

Na versão 9i a gestão de jobs é feita com o package DBMS_JOB.
Eis o script de deploy mais simples:

DECLARE
  V_JOB NUMBER;
BEGIN
  DBMS_JOB.SUBMIT(
		JOB => V_JOB,
		WHAT => 'BEGIN MY_PKG.MY_EXEC_PROC; END;',
		NEXT_DATE => SYSDATE);
  commit;
  dbms_output.put_line('Created MY_PKG.MY_EXEC_PROC job: '||v_job);
END;
/ 

Este script tem o seguinte problema: se executarmos o script outra vez o resultado vai ser a criação de outro job igual ao primeiro. Este foi alias a situação com que me deparei de início: a base de dados tinha dezenas de jobs a realizar a mesma tarefa!

Posto o problema de apenas o campo job (do tipo número) identificar univocamente o job, utilizei o campo what para o identificar. Criei o seguinte script de deploy:

DECLARE
  V_JOB NUMBER;
  V_WHAT VARCHAR2(100) := 'BEGIN MY_PKG.MY_EXEC_PROC; END;';
  V_NEXT_DATE DATE := SYSDATE;
BEGIN
  dbms_output.put_line('Deleting all MY_PKG.MY_EXEC_PROC jobs:');
	FOR jobs_to_delete IN (
    SELECT  job
	    FROM user_jobs
	    WHERE what like V_WHAT
   ) LOOP
     dbms_output.put_line('...removing MY_PKG.MY_EXEC_PROC job ' || jobs_to_delete.job);
     dbms_job.remove(jobs_to_delete.job);
  END LOOP;
  dbms_output.put_line('Deleted all MY_PKG.MY_EXEC_PROC jobs.');
  commit;

  DBMS_JOB.SUBMIT(V_JOB, V_WHAT, V_NEXT_DATE);
  commit;
  dbms_output.put_line('Created MY_PKG.MY_EXEC_PROC job: '||v_job);
END;
/ 

Reparar no loop para resolver o caso de fazerem deploy do mesmo job.
Este script não resolve outro problema: se numa fase de desenvolvimento alterarmos o what do job não iremos remover os jobs antigos – claro que esta situação tem pouco impacto com algum controlo regular sobre o que existe na base de dados.

Este script poderia ser isolado num procedimento com a assinatura

  DEPLOY_JOB(
		job       OUT BINARY_INTEGER,
		what      IN  VARCHAR2,
		next_date IN  DATE DEFAULT sysdate,
		interval  IN  VARCHAR2 DEFAULT 'null',
		job_name  IN  VARCHAR2);   -- 'job_name' serve apenas para dbms_output

que não é mais do que estender as funcionalidades do DBMS_JOB.SUBMIT.

Oracle 10g: o DBMS_SCHEDULER

Mas eis que a 10g apresenta uma solução muito mais completa: o package DBMS_SCHEDULER.

Eis o novo script de deploy proposto

DECLARE
  V_JOB_NAME VARCHAR2(100) := 'MY_PKG_MY_EXEC_PROC';
BEGIN
  DBMS_SCHEDULER.DROP_JOB(
    job_name          =>  V_JOB_NAME );
  DBMS_SCHEDULER.CREATE_JOB(
		job_name          =>  V_JOB_NAME,
		job_type          =>  'PLSQL_BLOCK',
		job_action        =>  'BEGIN MY_PKG.MY_EXEC_PROC; END;');
		start_date        =>  SYSDATE );
END;
/ 

job_name
This attribute specifies the name of the job and uniquely identifies the job.
The name has to be unique in the SQL namespace. For example, a job cannot have the same name as a table in a schema.

If job_name is not specified, an error is generated. If you want to have a name generated by the Scheduler, you can use the GENERATE_JOB_NAME procedure to generate a name and then use the output in the CREATE_JOB procedure. The GENERATE_JOB_NAME procedure call generates a number from a sequence, which is the job name. You can prefix the number with a string. The job name will then be the string with the number from the sequence appended to it.

Além do job ter um identificador descritivo, não é apenas único na lista de jobs mas também em todo o schema.

E com o DBMS_SCHEDULER.GENERATE_JOB_NAME nem precisariamos de nos preocupar com o nome do job, similar ao DBMS_JOBS.
E óptimo disponibilizar a geração de valores para job_name com prefixo, muito útil em aplicações que geram internamente jobs e que teriam de implementar esta geração do nome.

Nota importante: ao contrário do DBMS_JOB.SUBMIT, o DBMS_SCHEDULER.CREATE_JOB faz commit, tentando ser similar a um statement DDL.

Leituras

• [1] Oracle Database Administrator’s Guide 10g Release 1 (http://www.oracle.com)
• [2] PLSQL Packages and Types Reference 10g Release 1 (http://www.oracle.com)

A notícia já tem alguns dias, mas a Oracle anunciou a aquisição da Tangosol, empresa especialista em soluções data grid, nomeadamente com o seu produto Coherence que permite transacções distribuídas de alta performance. Antes de mais, aproveito para dar a conhecer um pouco este produto que já investiguei um pouco, mas que não tive oportunidade de utilizar em projectos reais em Portugal, um pouco devido à dimensão.

O Tangosol Coherence é uma solução de gestão de dados in-memory em ambientes distribuídos, integra graciosamente com a maioria dos servidores aplicacionais (p.e. OracleAS, JBoss, Weblogic e Websphere) e é independente da datasource (pode ser uma base de dados, um webservice ou um qualquer sistema legacy). Permite-nos gerir de forma transparente o acesso e gestão de dados sobre conjuntos de máquinas, garantindo alta performance – tal como clientes real-time – e integridade de dados, sem grande esforço do utilizador.

O principal ponto do produto é o mecanismo de caching distribuído. Suporta caching Read-Through, Write-Through, Refresh-Ahead e Write-Behind, sendo que as duas últimas podem ter grandes impactos de performance. Pode-se ler uma explicação destas políticas de caching aqui. Temos também sub-produtos, nomeadamento o Coherence Web, que permite fazer caching de sessões HTTP de forma fácil e incrivelmente eficiente e performante.

O ponto seguinte do produto é a sua implementação de transacções distribuídas. Chama-se Extreme Transaction Processing e em conjunto com a cache write-behing, faz transacções in-memory, sendo assim mais rápido e obtendo uma menor latência.

Existem 3 edições do Coherence: Caching, Application e Data grid. O primeiro foca-se em mecanismos de cache, o segundo engloba as potencialidades do primeiro e ainda controle trasaccional e o último engloba todas as funcionalidades das outras versões, adicionando capacidades de computação, interacção realtime, sistema orientado a eventos e outras propriedades mais avançadas.

Em suma, é o produto líder nesta área, especificamente em ambientes J2EE e é aclamado como um dos poucos produtos java realmente pensados e tecnicamente a roçar a perfeição.

Coloca-se a questão de como se integrará isto tudo como os produtos middleware da oracle, nomeadamente com o Oracle TimesTen – uma base de dados in-memory adquirida pela Oracle há uns tempos atrás, altamente performante, para ser utilizada como caching local para aplicações – e com o Oracle TopLink – o Coherence integra bem com Hibernate, Toplink e pojo's mas prevê-se maior integração com o Toplink. No site da oracle dão algumas ideias sobre esta integração nos pdf's de ajuda, mas nada de muito concreto.

Fica então a esperança de poder vir a utilizar este produto cá na nossa terra, mesmo em sistemas tempo-real e de elevada garantia transaccional como sistemas bancários, de companhias aéreas, etc.