2010-09-08 2 views
0

Я использую Oracle 10g и используя следующий сценарий для создания заданияOracle запланированное задание не удается

CREATE OR REPLACE PROCEDURE archtemp AS 
BEGIN 
    UPDATE ARCH_TEMP SET ARCH_DATE = SYSDATE; 
    COMMIT; 
END archtemp; 

VAR jobno NUMBER; 
BEGIN 
    DBMS_JOB.SUBMIT(:jobno, 'archtemp;', SYSDATE, 'sysdate + 1/1440'); 
    COMMIT; 
END; 

Задание не выполняется автоматически (хотя он работает вручную) с следующей ошибкой в ​​alert_sid.log

ORA-12012: error on auto execute of job 26 
ORA-01422: exact fetch returns more than requested number of rows 
ORA-06512: at line 8 

Я не могу связать ошибку ORA-01422 с любым из моего кода. Здесь я не делаю fetch.

+0

Я не думаю, что вы показываете нам правильный код (или сообщение об ошибке). Сообщение об ошибке ссылается на строку 8, которая, по-видимому, не находится в процедуре, которую вы опубликовали. И *, что * оператор обновления не мог выкинуть * это сообщение об ошибке. –

ответ

0

Здесь вы не делаете никаких данных, но я думаю, что какой-то ON UPDATE триггер на ARCH_TEMP может быть стол. Проверь это.

+0

Никаких триггеров вообще – Atti

+0

Возможно, что ammoQ прав, затем выполните 'select * from user_jobs, где job = 26', и посмотрите, какой из них действительно неисправен. Он должен иметь статус «broken». –

+0

Есть три других задания, но ни один из них не разбит или даже не был однажды выполнен. – Atti

1

Предполагая, что это скрипт для SQL * Plus, есть два/misssing, поэтому он ничего не делает вообще:

CREATE OR REPLACE PROCEDURE archtemp AS 
BEGIN 
    UPDATE ARCH_TEMP SET ARCH_DATE = SYSDATE; 
    COMMIT; 
END archtemp; 
/

VAR jobno NUMBER; 
BEGIN 
    DBMS_JOB.SUBMIT(:jobno, 'archtemp;', SYSDATE, 'sysdate + 1/1440'); 
    COMMIT; 
END; 
/

Я предполагаю, что это еще одна работа не удается, а не ваша.

+0

Даже если это задание удалено, я продолжаю получать следующую ошибку в журнале – Atti

+0

[Я нажал Enter для новой строки, и комментарий отправлен :)] ORA-00604: ошибка на рекурсивном уровне SQL 1 ORA-01422: точное fetch возвращает больше запрошенного количества строк ORA-06512: по строке 8 – Atti

+0

Ну, если вы можете (не производственная машина), отключите другие задания и посмотрите, что произойдет. Все еще получать ошибки в журнале? Нет? Повторно включите первое задание, подождите. Повторяйте до появления ошибки. Да? Войдите в систему как администратор базы данных и проверьте ALL_JOBS на задания, запущенные в другой схеме. –

0

Я бы использовал триггер SERVERERROR (как описано here), чтобы попытаться поймать утверждение, которое терпит неудачу. Но сначала вы можете проверить журнал предупреждений. Если рекурсивный SQL является ошибкой, может возникнуть проблема в словаре данных.

+0

Я не узнал о «СЕРВЕРЕРОРЕ». Я отключил все другие задания, но все еще не работает – Atti

+0

SERVERERROR - это тип триггера, который может захватывать дополнительную информацию при возврате ошибки. Вы получаете ошибку TOO_MANY_ROWS, и вам нужно идентифицировать SQL и таблицу (ы). След (DBMS_MONITOR) должен выполнять эту работу. –

0

Попробуйте ввести явный блок PL/SQL в качестве параметра WHAT.

dbms_job.submit(v_jobno, 'begin archtemp; end;', sysdate, 'sysdate+1/1440'); 

Вот мой тест, который, кажется, работает нормально:

create table arch_temp (
    arch_date date 
    ); 

-- create row to test update 
insert into arch_temp (arch_date) values (null); 

create or replace procedure archtemp as 
begin 
    update arch_temp set arch_date = sysdate; 
    commit; 
end archtemp; 
/

-- test everything works in isoloation 

begin 
    archtemp; 
end; 
/

select * from arch_temp; 
-- arch_date = 10:49:34 

select * from user_jobs; 
-- no rows returned 

declare 
    v_jobno number; 
begin 
    dbms_job.submit(v_jobno, 'begin archtemp; end;', sysdate, 'sysdate+1/1440'); 
    commit; 
    dbms_output.put_line('v_jobno: ' || to_char(v_jobno)); 
end; 
/

-- dbms_output... 
-- v_jobno: 50520 

select * from user_jobs; 

-- JOB 50520 returned 
-- LAST_DATE = 10:51:11 

select * from arch_temp; 

-- ARCH_DATE = 10:51:11 
0

Я попытался решением Ник Пирпойнт как хорошо, но это не работает для меня Это выглядит не так с удачей, поскольку Я попробовал то же самое на другой машине с Oracle 9i, и это не сработало !!!

Спасибо всем за ваши ответы.

С уважением

+0

Итак, вы прошли мой пример, и это не удалось? –

+0

Да, однако, я использовал тот же скрипт для создания двух заданий на другой службе (9i) с двумя разными таблицами и процедурами, и оба хорошо работали. Мой коллега создал 1 задание на 11g с помощью DBA, и он не удался, а другая работа на том же сервисе была создана с использованием ПОЛЬЗОВАТЕЛЯ, который работает нормально. Я пробовал как с DBA, так и без него на 10g, и оба не удалось. – Atti

Смежные вопросы