Why Would The Logical Standby Lag?

Question

Oracle 11.2.0.2
Linux RedHat 5.3+
Logical standby
I have a logical standby that is lagging behind the primary a lot.
The databases have the same amount of data...about 20 million rows.
They have the same indexes.
I am using SQL Apply.
I know that the slow down is that the Logical Standby is doing a full table scan because the update statement contains DECODE statements.
It takes about 19 minutes to process this statement on the Logical Standby.
I know what the offending statement is.
update /*+ streams restrict_all_ref_cons */ "APPLICA"."ARCH" p set "AG_ID"=decode(:1,'N',"AG_ID",:2),
"CREATED_BY"=decode(:3,'N',"CREATED_BY",:4),
"CREATED_ON"=decode(:5,'N',"CREATED_ON",:6),
"DATA_CONTACT_EMAIL"=decode(:7,'N',"DATA_CONTACT_EMAIL",:8),
"DATA_CONTACT_NAME"=decode(:9,'N',"DATA_CONTACT_NAME",:10),
"DATA_CONTACT_PHONE"=decode(:11,'N',"DATA_CONTACT_PHONE",:12),
"DATA_ITEM_ID"=decode(:13,'N',"DATA_ITEM_ID",:14),
"ITEM_ACTION"=decode(:19,'N',"ITEM_ACTION",:20),
"ITEM_DATE"=decode(:21,'N',"ITEM_DATE",:22),
"ITEM_STATUS"=decode(:23,'N',"ITEM_STATUS",:24),
"MESSAGE_TIME"=decode(:25,'N',"MESSAGE_TIME",:26),
"MODIFIED_BY"=decode(:27,'N',"MODIFIED_BY",:28),
"MODIFIED_ON"=decode(:29,'N',"MODIFIED_ON",:30)
where
(:31='N' or
(1=1 and decode(:32,'N','Y',decode(:33,"CREATED_BY",'Y'))='Y'
and decode(:34,'N','Y',decode(:35,"CREATED_ON",'Y'))='Y'
and decode(:36,'N','Y',decode(:37,"DATA_CONTACT_EMAIL",'Y'))='Y'
and decode(:38,'N','Y',decode(:39,"DATA_CONTACT_NAME",'Y'))='Y'
and decode(:40,'N','Y',decode(:41,"DATA_CONTACT_PHONE",'Y'))='Y'
and 1=1 and decode(:46,'N','Y',decode(:47,"ITEM_ACTION",'Y'))='Y'
and decode(:48,'N','Y',decode(:49,"ITEM_DATE",'Y'))='Y'
and decode(:50,'N','Y',decode(:51,"ITEM_STATUS",'Y'))='Y'
and decode(:52,'N','Y',decode(:53,"MESSAGE_TIME",'Y'))='Y'
and decode(:54,'N','Y',decode(:55,"MODIFIED_BY",'Y'))='Y'
and decode(:56,'N','Y',decode(:57,"MODIFIED_ON",'Y'))='Y')) and
(:58="AG_ID") and
(:59="DATA_ITEM_ID")
This table does have indexes but they do not cover the entire table.
Primary Key: AG_ID,DATA_ITEM_ID
Index1 : ITEM_STATUS,AG_ID
I am NOT asking why the statement is doing a full table scan I know that much.
What I am asking is if everthing with the structure, indexes and statistics is the same why is there no problem on the PRIMDB and there is a problem on the STBYDB?

Answer 1

Well I found the issue...I should say a co-worker pointed me to the correct solution.
We were talking about the indexes and primary key and still attempting to understand why to SQL Apply was rewriting my update to include DECODE statments when he said.
"You have the same indexes and primary key but are they USABLE."
Well I thought of course they are usable...I just built the one index and the other is the primary key.
After looking a bit further we found that that index for the primary key was marked as unusable. Then I remembered that when we rebuilt the standby database that I had moved that table to reduce space within the tablespace. Moving a table can invalidate the primary key index. We rebuilt the index on the primary key and all is good now.
Regards
Tim