ALL_CONSTRAINTS on TOP by GOLDENGATE user

POSSIBLE SLOW QUERY ON ALL_CONSTRAINTS VIEW RUN BY REPLICAT

GoldenGate software version:   
Version 11.1.1.0.0 Build 078
Linux, x64, 64bit (optimized), Oracle 11 on Sept 13 2010 20:12:09
  

Operating System Version:
RedHat 

Version #1 SMP Tue Mar 28 11:22:12 PST 2010, Release 2.6.18-194.el5
Machine: x86_64
  
Database Version:
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
  
There can be an incorrect query which might cause problems but presently now real problem can be seen:
 
select B.owner || '.' || B.table_name,        

       A.owner || '.' || A.table_name,        

       A.owner || '.' || A.constraint_name, 

       B.owner || '.' || B.constraint_name, 

       B.deferred  

from   all_constraints A, 

       all_constraints B 

where  B.owner = '<OWNER>' 

and    B.table_name = '<TABLE_NAME>' 

and    A.owner = B.owner 

and    A.constraint_name = B.r_constraint_name 

and    B.constraint_type = 'R'

Join condition between A.owner = B.owner seems to be wrong.
 
Condition "and a1.owner = a2.r_owner"  must be used instead. (like it is already used - "a1.constraint_name = a2.r_constraint_name" ). 

Because owner primary constraint and foreign constraint owner can be different.
  

When owner of the primary constraint is different than the owner of foreign constraint and replicat is in BATCHSQL mode, replicat will fail to order the batches based on foreign key dependency. This might lead to batch with foreign keys being processed before the batch with primary keys, and result into foreign key constraint vioation error.

FIX/WORKAROUND:
Run replicat in non-BATCHSQL mode by commenting out BATCHSQL parameter in replicat parameter file.