Преобразование триггера DB2 в триггеры Oracle вызывает ошибку ORA-04091.

Лучше всего по возможности избегать триггеров.
Посмотрите эти ссылки, чтобы узнать, почему не следует использовать триггеры:
http://www.oracle.com/technetwork/testcontent/o58asktom-101055.html
http://rwijk.blogspot.com/2007/09/database-triggers-are-evil.html

Используйте процедуру (API ) вместо триггеров - можно создать пакет с несколькими процедурами вроде add_new_job, add_new_task, change_task_status и т.д., и поместить всю логику в этих процедурах (проверка, изменение состояний задач, изменение состояний заданий и т.д.) в одном месте. Легко понять, легко поддерживать, легко отлаживать и легко отслеживать ошибки.

Если вы настаиваете на использовании триггеров, вы можете создать compound trigger, как Том Кайт упомянул в первой ссылке выше как workaround, например:

create or replace TRIGGER JOB_AUTHORED
FOR UPDATE OF TASK_STATUS on TASKS
COMPOUND TRIGGER

  TYPE JOB_ID_TABLE_TYPE IS TABLE OF PLS_INTEGER INDEX BY PLS_INTEGER;  
  JOB_ID_TABLE JOB_ID_TABLE_TYPE;
  dummy CHAR;

    AFTER EACH ROW IS
     BEGIN
       -- SELECT null INTO dummy FROM JOBS WHERE job_id = :NEW.JOB_ID FOR UPDATE;
        JOB_ID_TABLE( :NEW.JOB_ID ) := :NEW.JOB_ID;
     END AFTER EACH ROW;

     AFTER STATEMENT IS
     BEGIN
       FORALL x IN INDICES OF JOB_ID_TABLE
         UPDATE jobs set JOB_STATUS='Authored'
         WHERE JOBS.JOB_ID = JOB_ID_TABLE( x )
           and TASK_COUNT=(
                  select count(0) from TASKS
                  where TASKS.JOB_ID = JOBS.JOB_ID
                    and TASKS.TASK_STATUS in ('Authored','Completed')
          );
     END AFTER STATEMENT;

END JOB_AUTHORED;

но .....
Я не уверен, что в этом примере нет каких-либо подводных камней, о которых мы пока не знаем.

Например, в этом сценарии есть одна ловушка:
Предположим, что есть 18 задач со статусом Authored

• В момент времени X пользователь A запускает UPDATE TASK SET со статусом «Авторизовано», WHERE task_id = 2. Триггер срабатывает и видит 18+1 зафиксированную задачу со статусом Authored
  
• В момент времени X+10 мс пользователь B запускает UPDATE TASK1 SET status ' Authored' task_id = 4. Триггер срабатывает и видит 18+1 зафиксированную задачу со статусом Authored
  
• В момент времени X+20 мс пользователь А совершает коммит
  
• В момент времени X+30 мс пользователь Б совершает фиксацию
  
• В итоге имеем 21 задачу со статусом authored. но статус задания не был изменен на Authored (но его следует изменить на Authored, если количество задач = 20).

Чтобы избежать этой ловушки, вы можете использовать SELECT null INTO dummy FROM JOBS WHERE job_id = :NEW.JOB_ID FOR UPDATE; в части after each row триггера, чтобы поместить блокировку на соответствующую запись в таблице JOBS, чтобы сериализовать доступ (я прокомментировал это в примере выше).
Но я все еще не уверен, что это правильное решение - это, в свою очередь, может вызвать некоторые взаимоблокировки в сценарии, который я не могу себе представить и предсказать в настоящее время.

Вкратце - в Oracle в триггерах нельзя select from таблицу, по которой строится триггер. В противном случае вы можете/вы получите ошибку изменяющейся таблицы.

У вас есть несколько вариантов:

1) Вообще никаких триггеров - по моему скромному мнению, это лучший вариант, я бы сделал так (но наверное тема шире и мы не все знаем). Создайте представление, которое заменяет необходимость триггеров, например:

create or replace view v_jobs_done as 
  select * from jobs where not exists 
    select 1 from tasks 
      where TASKS.JOB_ID = jobs.JOB_ID
        and TASKS.TASK_STATUS not in ('Authored','Completed')

2) Вместо увеличения значения используйте уменьшающееся значение, поэтому, когда jobs.tasks_count достигает нуля, вы знаете, что все сделано. В этом случае вам нужно создать/перестроить другие триггеры,

3) Предложение близко к вашему - вы можете использовать современный составной триггер - тут я сомневаюсь в производительности, но работает:

create or replace trigger Job_Authored
for update of task_status on tasks compound trigger

  type t_ids   is table of tasks.job_id%type;
  type t_cnts  is table of number;
  type t_job_counts is table of number index by varchar2(10);
  v_ids        t_ids;
  v_cnts       t_cnts;
  v_job_counts t_job_counts;

before statement is
  begin
    select job_id, count(1) 
      bulk collect into v_ids, v_cnts
      from tasks where tasks.task_status in ('Authored','Completed')
      group by job_id;

    for i in 1..v_ids.count() loop
      v_job_counts(v_ids(i)) := v_cnts(i);
    end loop;
  end before statement;

after each row is
  begin
    if :new.task_status = 'Authored' then 
      update jobs set job_status='Authored'
        where job_id = :new.job_id
          and task_count = v_job_counts(:new.job_id);
    end if;
  end after each row;
end Job_Authored;

Лучше всего по возможности избегать триггеров.
См. эти ссылки для ответа, почему нельзя использовать триггеры:
http://www.oracle.com/technetwork/testcontent/o58asktom-101055.html
http://rwijk.blogspot.com/2007/09/database-triggers-are-evil.html

Используйте процедуру (API ) вместо триггеров - можно создать пакет с несколькими процедурами вроде add_new_job, add_new_task, change_task_status и т.д., и поместить всю логику в этих процедурах (проверка, изменение состояний задач, изменение состояний заданий и т.д.) в одном месте. Легко понять, легко поддерживать, легко отлаживать и легко отслеживать ошибки.

Если вы настаиваете на использовании триггеров, вы можете создать compound trigger, как Том Кайт упомянул в первой ссылке выше как workaround, например:

create or replace TRIGGER JOB_AUTHORED
FOR UPDATE OF TASK_STATUS on TASKS
COMPOUND TRIGGER

  TYPE JOB_ID_TABLE_TYPE IS TABLE OF PLS_INTEGER INDEX BY PLS_INTEGER;  
  JOB_ID_TABLE JOB_ID_TABLE_TYPE;
  dummy CHAR;

    AFTER EACH ROW IS
     BEGIN
       -- SELECT null INTO dummy FROM JOBS WHERE job_id = :NEW.JOB_ID FOR UPDATE;
        JOB_ID_TABLE( :NEW.JOB_ID ) := :NEW.JOB_ID;
     END AFTER EACH ROW;

     AFTER STATEMENT IS
     BEGIN
       FORALL x IN INDICES OF JOB_ID_TABLE
         UPDATE jobs set JOB_STATUS='Authored'
         WHERE JOBS.JOB_ID = JOB_ID_TABLE( x )
           and TASK_COUNT=(
                  select count(0) from TASKS
                  where TASKS.JOB_ID = JOBS.JOB_ID
                    and TASKS.TASK_STATUS in ('Authored','Completed')
          );
     END AFTER STATEMENT;

END JOB_AUTHORED;

но .....
Я не уверен, что в этом примере нет каких-либо подводных камней, о которых мы пока не знаем.

Например, в этом сценарии есть одна ловушка:
Предположим, что есть 18 задач со статусом Authored

• В момент времени X пользователь A запускает UPDATE TASK SET со статусом «Авторизовано», WHERE task_id = 2. Триггер срабатывает и видит 18+1 зафиксированную задачу со статусом Authored
  
• В момент времени X+10 мс пользователь B запускает UPDATE TASK1 SET status ' Authored' task_id = 4. Триггер срабатывает и видит 18+1 зафиксированную задачу со статусом Authored
  
• В момент времени X+20 мс пользователь А совершает коммит
  
• В момент времени X+30 мс пользователь А совершает коммит
  
• В итоге имеем 21 задачу со статусом authored. но статус задания не был изменен на Authored (но его следует изменить на Authored, если количество задач = 20).

Чтобы избежать этой ловушки, вы можете использовать SELECT null INTO dummy FROM JOBS WHERE job_id = :NEW.JOB_ID FOR UPDATE; в части after each row триггера, чтобы поместить блокировку на соответствующую запись в таблице JOBS, чтобы сериализовать доступ (я прокомментировал это в примере выше).
Но я все еще не уверен, что это правильное решение - это может привести к взаимоблокировкам в сценарии, который я сейчас не могу представить и предсказать.