У меня есть несколько типов работ.
CREATE TABLE EMP (EMPNO NUMBER(10) PRIMARY KEY, JOB_TYPE VARCHAR2(20), PROCESSED VARCHAR2(3),
THREAD NUMBER(4));
INSERT INTO EMP VALUES (7125, 'MANAGER', 'NO', NULL);
INSERT INTO EMP VALUES (7250, 'MANAGER', 'NO', NULL);
INSERT INTO EMP VALUES (7400, 'MANAGER', 'NO', NULL);
INSERT INTO EMP VALUES (7445, 'CLERK', 'NO', NULL);
INSERT INTO EMP VALUES (7550, 'CLERK', 'NO', NULL);
INSERT INTO EMP VALUES (7600, 'CLERK', 'NO', NULL);
INSERT INTO EMP VALUES (7945, 'CLERK', 'NO', NULL);
INSERT INTO EMP VALUES (7965, 'ANALYST', 'NO', NULL);
INSERT INTO EMP VALUES (7970, 'ANALYST', 'NO', NULL);
INSERT INTO EMP VALUES (7975, 'ANALYST', 'NO', NULL);
INSERT INTO EMP VALUES (7980, 'ANALYST', 'NO', NULL);
INSERT INTO EMP VALUES (7985, 'ANALYST', 'NO', NULL);
INSERT INTO EMP VALUES (7990, 'ANALYST', 'NO', NULL);
COMMIT;
Теперь я хочу создать несколько параллельных потоков, которые будут обрабатывать каждый тип задания, не ожидая друг друга. Как только строка обработана, поток помечает ее обработкой (Обновить ОБРАБОТАНО до YES и THREAD до номера потока) и переходит к следующей строке.
Итак, наконец, таблица должна выглядеть следующим образом.
EMPNO JOB_TYPE PROCESSED THREAD
7125 MANAGER YES 1
7250 MANAGER YES 1
7400 MANAGER YES 1
7445 CLERK YES 2
7550 CLERK YES 2
7600 CLERK YES 2
7945 CLERK YES 2
7965 ANALYST YES 3
7970 ANALYST YES 3
7975 ANALYST YES 3
7980 ANALYST YES 3
7985 ANALYST YES 3
7990 ANALYST YES 3
Поток 1 обработал строки MANAGER, поток 2 обработал строки CLERK и поток 3 обработал строки ANALYST.
Я имею в виду:
Входит поток 1, БОЛЬШАЯ ВЫБИРАЕТ все строки МЕНЕДЖЕРА, блокирует их и обрабатывает их.
Приходит поток 2, пытается НАБРОСИТЬ ВЫБОР всех строк МЕНЕДЖЕРА, находит, что он заблокирован, поэтому переходит к следующему JOB_TYPE. БОЛЬШАЯ ПОЛУЧЕНИЕ УБИРАЕТ строки, блокирует их и обрабатывает.
Входит поток 3, он видит, что МЕНЕДЖЕР и КЛЕРК заблокированы, поэтому он перемещается в строки АНАЛИТИКИ.
Также обратите внимание, что каждый поток будет обрабатывать строки, помеченные как NO. Поэтому после того, как один поток завершит свою обработку и снимет блокировки, другой поток не должен повторно обрабатывать те же строки, поскольку они теперь помечены как PROCESSED = YES.
В производственной среде у меня будет сотни типов заданий и тысячи строк для каждого типа заданий. Число параллельных потоков будет контролироваться внешним администратором базы данных в зависимости от количества ресурсов, используемых в базе данных в любой момент времени.
Единственное предупреждение, которое я нашел в отношении FOR UPDATE SKIP LOCKED, заключается в том, что блокировки получаются, когда вы фактически выбираете строки (если вы используете курсор в pl / sql), а не когда вы открываете курсор.
Одним из важных критериев здесь является то, что я НЕ хочу, чтобы 2 потока обрабатывали 1 тип задания.
Имеет ли это смысл?
Мой комментарий о неиспользовании AQ заключается в том, что мне нужны дополнительные привилегии для настройки AQ в базе данных, в то время как SKIP LOCKED кажется, что он может просто выполнить это. Вы говорите, что SKIP LOCKED нельзя использовать для замены AQ в 11g?