Oracle AQ, messages dequeued after one hour

Question

Hi,
We are facing a weird issue in one of our databases.
ATESTMED
SQL> select count (*) from emx_alarm_qtab;
COUNT(*)
26
SQL> set serveroutput on
SQL> DECLARE
2 CURSOR c IS select * from emx_alarm_qtab;
3 r c%ROWTYPE;
4 i number;
5 BEGIN
6 i:=0;
7 FOR r in c LOOP
8 emx_queue.purge_alarm (r.msgid);
9 i := i + 1;
10 END LOOP;
11 dbms_output.put_line ('Count ' || i);
12 END;
13 /
Already purged MsgID=9E18AB1B7F1D3E9EE04083583A6E0BFA
Already purged MsgID=9E18AB1B7F1E3E9EE04083583A6E0BFA
Already purged MsgID=9E18AB1B7F1F3E9EE04083583A6E0BFA
Already purged MsgID=9E18AB1B7F203E9EE04083583A6E0BFA
Already purged MsgID=9E18AB1B7F213E9EE04083583A6E0BFA
Already purged MsgID=9E18AB1B7F223E9EE04083583A6E0BFA
Purged MsgID=9E1B6F30AE954564E04083583B6E1BB0
Purged MsgID=9E1B6F30AE964564E04083583B6E1BB0
Purged MsgID=9E1B6F30AE974564E04083583B6E1BB0
Already purged MsgID=9E1B6F30AE904564E04083583B6E1BB0
Already purged MsgID=9E1B6F30AE914564E04083583B6E1BB0
Already purged MsgID=9E1B6F30AE924564E04083583B6E1BB0
Purged MsgID=9E1B6F30AE984564E04083583B6E1BB0
Purged MsgID=9E1B6F30AE934564E04083583B6E1BB0
Purged MsgID=9E1B6F30AE944564E04083583B6E1BB0
Already purged MsgID=9E1B6F30AE9D4564E04083583B6E1BB0
Already purged MsgID=9E1B6F6FCDB86BA8E04083583B6E1BBD
Already purged MsgID=9E1B6F6FCDC06BA8E04083583B6E1BBD
Already purged MsgID=9E1B6F6FCDC16BA8E04083583B6E1BBD
Already purged MsgID=9E1B6F6FCDC26BA8E04083583B6E1BBD
Purged MsgID=9E1B6F6FCDC36BA8E04083583B6E1BBD
Purged MsgID=9E1B6F6FCDC46BA8E04083583B6E1BBD
Purged MsgID=9E1B6F6FCDC56BA8E04083583B6E1BBD
Purged MsgID=9E1B6F6FCDC66BA8E04083583B6E1BBD
Purged MsgID=9E1B6F6FCDC76BA8E04083583B6E1BBD
Purged MsgID=9E1B6F6FCDC86BA8E04083583B6E1BBD
Count 26
PL/SQL-procedur Σr utf÷rd utan fel.
SQL> commit;
COMMIT Σr utf÷rt.
SQL> select count (*) from emx_alarm_qtab;
COUNT(*)
26
in SOATEST
SQL> select count (*) from emx_alarm_qtab;
COUNT(*)
12
SQL> set serveroutput on
SQL> DECLARE
2 CURSOR c IS select * from emx_alarm_qtab;
3 r c%ROWTYPE;
4 i number;
5 BEGIN
6 i:=0;
7 FOR r in c LOOP
8 emx_queue.purge_alarm (r.msgid);
9 i := i + 1;
10 END LOOP;
11 dbms_output.put_line ('Count ' || i);
12 END;
13 /
Purged MsgID=9E1A8C9F2CA8ABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2C90ABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2C91ABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2C92ABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2C93ABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2C94ABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2C95ABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2CA9ABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2CAAABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2CABABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2CACABE1E040B30A2902673D
Purged MsgID=9E1A8C9F2CADABE1E040B30A2902673D
Count 12
PL/SQL-procedur Σr utf÷rd utan fel.
SQL> commit;
COMMIT Σr utf÷rt.
SQL> select count (*) from emx_alarm_qtab;
COUNT(*)
0
in ATESTMED, the rows are not getting dequeued. They get dequeued after one hour.
the aq_tm_processes is already 0 in both the databases.
This has started all of a sudden.
Please help.
Thanks,
Rosh

Answer 1

Is it exactly one hour? Has the timezone changed recently, there is a 10G R2 bug around timezones where the Queue Table is created in one timezone but isn't changed when the DB moves to a different timezone so they become out of sync. What does the Time Manager Info value tell you?