Olá colegas. * Ambiente: Oracle 10g + Linux (não tenho detalhes da máquina servidora, mas sei que é um quadriprocessado, ambiente de produção, com bom desempenho).
* O problema: Preciso fazer uma trigger after update na tabela WF_NOTIFICATIONS do Oracle Workflow. Neste ambiente, a tabela é particionada, possui algo em torno de 200 milhões de registros, e tenho os índices que preciso para as consultas. Alguns registros são identificados como pertencentes a um mesmo 'grupo' por uma coluna GROUP_ID de mesmo valor. Quando um registro mudar a coluna STATUS de 'OPEN' para diferente de 'OPEN', preciso verificar se ainda existe algum outro registro do mesmo GROUP_ID que esteja 'OPEN'. Caso não, preciso realizar um delete deste GROUP_ID em outra tabela que não é do produto Oracle, para fins de manutenção, de forma a impedir que esta outra tabela creça mais que o necessário. a) Não posso fazer uma consulta na própria tabela wf_notifications, pois terei problema de tabela mutante. b) Não gostaria de fazer uma procedure de transação autônoma para não correr o risco de realizar o delete mesmo caso ocorra alguma exceção e o update na wf_notifications seja cancelado. c) Pensei em criar um JOB com a chamada para a procedure que realiza a verificação e o delete, agendado para alguns minutos depois, tempo suficiente para o commit na wf_notifications ser realizado. Isso me serve. create or replace trigger trg_sgpd_wfno_categ_atividades after update on wf_notifications referencing old as reg_antigo new as reg_novo for each row when (reg_antigo.status = 'OPEN' and reg_novo.status <> 'OPEN') ... d) Também estou cogitando como alternativa rodar um procedimento a noite, que faça a varredura da tabela onde quero deletar, que é muito menor, e verifique se cada registro pode ser deletado. Mas isso não vai ser performático (fullscan na tabela a deletar) se forem mantidos muitos registros com status 'OPEN' na tabela principal. Em média, hoje tenho 50mil registros nestas condições, ou seja, que estão 'OPEN' na tabela do Workflow e portanto devem existir na tabela adicional, o que já acho considerável. * Minhas dúvidas: 1) Trata-se de um ambiente de produção grande, com muitos acessos simultâneos. Corro o risco de criar algum tipo de degradação da performance inundando com vários jobs seguidos? Não tenho prática de administração.... que parâmetro devo inquirir os administradores do ambiente para saber o máximo número de Jobs que o BD pode suportar? (Este número é de Jobs executados ou de Jobs rodando simultâneos?) 2) Supondo que a solução de agendar Jobs esteja ok, tenho vantagens em utilizar a DBMS_SCHEDULER ou posso utilizar a DBMS_JOB para criar o JOB ? 3) Recomendam alguma outra solução alternativa? Estava lendo as recomendações em http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96590/adg13trg.htm#786e http://asktom.oracle.com/tkyte/Mutate/index.html e não cheguei a uma avaliação de qual seria a solução indicada para minha situação. Agradeço por opiniões. Atenciosamente, Luís Fernando Heckler [As partes desta mensagem que não continham texto foram removidas]
