ORA-01403 No Data Found Issue

Question

Hi,
Im very new to streams and having a doubt regarding ORA-01403 issue happening while replication. Need you kind help on this regard. Thanks in advance.
Oracle version : 10.0.3.0
1.Suppose there are 10 LCRs in a Txn and one of the LCR caused ORA-01403 and none of the LCRs get executed.
We can read the data of this LCR and manually update the record in the Destination database.
Eventhough this is done, while re-executing the transaction, im getting the same ORA-01403 on the same LCR.
What could be the possible reason.
Since, this is a large scale system with thousands of transactions, it is not possible to handle the No data found issues occuring in the system.
I have written a PL/SQL block which can generate Update statements with the old data available in LCR, so that i can re-execute the Transaction again.
The PL/SQL block is given below. Could you please check if there are any issues in this while generating the UPDATE statements. Thank you
/* Formatted on 2008/10/23 14:46 (Formatter Plus v4.8.7) */
--Script for generating the Update scripts for the Message which caused the 'NO DATA FOUND' error.
DECLARE
RES NUMBER; --No:of errors to be resolved
RET NUMBER; --A number variable to hold the return value from getObject
I NUMBER; --Index for the loop
J NUMBER; --Index for the loop
K NUMBER; --Index for the loop
PK_COUNT NUMBER; --To Hold the no:of PK columns for a Table
LCR ANYDATA; --To Hold the Logical Change Record
TYP VARCHAR2 (61); --To Hold the Type of a Column
ROWLCR SYS.LCR$_ROW_RECORD; --To Hold the LCR caused the error in a Txn.
OLDLIST SYS.LCR$_ROW_LIST; --To Hold the Old data of the Record which was tried to Update/Delete
NEWLIST SYS.LCR$_ROW_LIST;
UPD_QRY VARCHAR2 (5000);
EQUALS VARCHAR2 (5) := ' = ';
DATA1 VARCHAR2 (2000);
NUM1 NUMBER;
DATE1 TIMESTAMP ( 0 );
TIMESTAMP1 TIMESTAMP ( 3 );
ISCOMMA BOOLEAN;
TYPE TAB_LCR IS TABLE OF ANYDATA
INDEX BY BINARY_INTEGER;
TYPE PK_COLS IS TABLE OF VARCHAR2 (50)
INDEX BY BINARY_INTEGER;
LCR_TABLE TAB_LCR;
PK_TABLE PK_COLS;
BEGIN
I := 1;
SELECT COUNT ( 1)
INTO RES
FROM DBA_APPLY_ERROR;
FOR TXN_ID IN
(SELECT MESSAGE_NUMBER,
LOCAL_TRANSACTION_ID
FROM DBA_APPLY_ERROR
WHERE LOCAL_TRANSACTION_ID =
'2.85.42516'
ORDER BY ERROR_CREATION_TIME)
LOOP
SELECT DBMS_APPLY_ADM.GET_ERROR_MESSAGE
(TXN_ID.MESSAGE_NUMBER,
TXN_ID.LOCAL_TRANSACTION_ID
INTO LCR
FROM DUAL;
LCR_TABLE (I) := LCR;
I := I + 1;
END LOOP;
I := 0;
K := 0;
dbms_output.put_line('size >'||lcr_table.count);
FOR K IN 1 .. RES
LOOP
ROWLCR := NULL;
RET :=
LCR_TABLE (K).GETOBJECT
(ROWLCR);
--dbms_output.put_line(rowlcr.GET_OBJECT_NAME);
PK_COUNT := 0;
--Finding the PK columns of the Table
SELECT COUNT ( 1)
INTO PK_COUNT
FROM ALL_CONS_COLUMNS COL,
ALL_CONSTRAINTS CON
WHERE COL.TABLE_NAME =
CON.TABLE_NAME
AND COL.CONSTRAINT_NAME =
CON.CONSTRAINT_NAME
AND CON.CONSTRAINT_TYPE = 'P'
AND CON.TABLE_NAME =
ROWLCR.GET_OBJECT_NAME;
dbms_output.put_line('Count of PK Columns >'||pk_count);
DEL_QRY := NULL;
DEL_QRY :=
'DELETE FROM '
|| ROWLCR.GET_OBJECT_NAME
|| ' WHERE ';
INS_QRY := NULL;
INS_QRY :=
'INSERT INTO '
|| ROWLCR.GET_OBJECT_NAME
|| ' ( ';
UPD_QRY := NULL;
UPD_QRY :=
'UPDATE '
|| ROWLCR.GET_OBJECT_NAME
|| ' SET ';
OLDLIST :=
ROWLCR.GET_VALUES ('old');
-- Generate Update Query
NEWLIST :=
ROWLCR.GET_VALUES ('old');
ISCOMMA := FALSE;
FOR J IN 1 .. NEWLIST.COUNT
LOOP
IF NEWLIST (J) IS NOT NULL
THEN
IF J <
NEWLIST.COUNT
THEN
IF ISCOMMA =
TRUE
THEN
UPD_QRY :=
UPD_QRY
|| ',';
END IF;
END IF;
ISCOMMA := FALSE;
TYP :=
NEWLIST
(J).DATA.GETTYPENAME;
IF (TYP =
'SYS.VARCHAR2'
THEN
RET :=
NEWLIST
(J
).DATA.GETVARCHAR2
(DATA1
IF DATA1 IS NOT NULL
THEN
UPD_QRY :=
UPD_QRY
|| NEWLIST
(J
).COLUMN_NAME;
UPD_QRY :=
UPD_QRY
|| EQUALS;
UPD_QRY :=
UPD_QRY
|| ' '
|| ''''
|| SUBSTR
(DATA1,
0,
253
|| '''';
ISCOMMA :=
TRUE;
END IF;
ELSIF (TYP =
'SYS.NUMBER'
THEN
RET :=
NEWLIST
(J
).DATA.GETNUMBER
(NUM1
IF NUM1 IS NOT NULL
THEN
UPD_QRY :=
UPD_QRY
|| NEWLIST
(J
).COLUMN_NAME;
UPD_QRY :=
UPD_QRY
|| EQUALS;
UPD_QRY :=
UPD_QRY
|| ' '
|| NUM1;
ISCOMMA :=
TRUE;
END IF;
ELSIF (TYP =
'SYS.DATE'
THEN
RET :=
NEWLIST
(J
).DATA.GETDATE
(DATE1
IF DATE1 IS NOT NULL
THEN
UPD_QRY :=
UPD_QRY
|| NEWLIST
(J
).COLUMN_NAME;
UPD_QRY :=
UPD_QRY
|| EQUALS;
UPD_QRY :=
UPD_QRY
|| ' '
|| 'TO_Date( '
|| ''''
|| DATE1
|| ''''
|| ', '''
|| 'DD/MON/YYYY HH:MI:SS AM'')';
ISCOMMA :=
TRUE;
END IF;
ELSIF (TYP =
'SYS.TIMESTAMP'
THEN
RET :=
NEWLIST
(J
).DATA.GETTIMESTAMP
(TIMESTAMP1
IF TIMESTAMP1 IS NOT NULL
THEN
UPD_QRY :=
UPD_QRY
|| ' '
|| ''''
|| TIMESTAMP1
|| '''';
ISCOMMA :=
TRUE;
END IF;
END IF;
END IF;
END LOOP;
--Setting the where Condition
UPD_QRY := UPD_QRY || ' WHERE ';
FOR I IN 1 .. PK_COUNT
LOOP
SELECT COLUMN_NAME
INTO PK_TABLE (I)
FROM ALL_CONS_COLUMNS COL,
ALL_CONSTRAINTS CON
WHERE COL.TABLE_NAME =
CON.TABLE_NAME
AND COL.CONSTRAINT_NAME =
CON.CONSTRAINT_NAME
AND CON.CONSTRAINT_TYPE =
'P'
AND POSITION = I
AND CON.TABLE_NAME =
ROWLCR.GET_OBJECT_NAME;
FOR J IN
1 .. NEWLIST.COUNT
LOOP
IF NEWLIST (J) IS NOT NULL
THEN
IF NEWLIST
(J
).COLUMN_NAME =
PK_TABLE
(I
THEN
UPD_QRY :=
UPD_QRY
|| ' '
|| NEWLIST
(J
).COLUMN_NAME;
UPD_QRY :=
UPD_QRY
|| ' '
|| EQUALS;
TYP :=
NEWLIST
(J
).DATA.GETTYPENAME;
IF (TYP =
'SYS.VARCHAR2'
THEN
RET :=
NEWLIST
(J
).DATA.GETVARCHAR2
(DATA1
UPD_QRY :=
UPD_QRY
|| ' '
|| ''''
|| SUBSTR
(DATA1,
0,
253
|| '''';
ELSIF (TYP =
'SYS.NUMBER'
THEN
RET :=
NEWLIST
(J
).DATA.GETNUMBER
(NUM1
UPD_QRY :=
UPD_QRY
|| ' '
|| NUM1;
END IF;
IF I <
PK_COUNT
THEN
UPD_QRY :=
UPD_QRY
|| ' AND ';
END IF;
END IF;
END IF;
END LOOP;
END LOOP;
UPD_QRY := UPD_QRY || ';';
DBMS_OUTPUT.PUT_LINE (UPD_QRY);
--Generate Update Query - End
END LOOP;
END;

Answer 1

Thanks for you replies HTH and Dipali.
I would like to make some points clear from my side based on the issue i have raised.
1.The No Data Found error is happening on a table for which supplemental logging is enabled.
2.As per my understanding, the "Apply" process is comparing the existing data in the destination database with the "Old" data in the LCR.
Once there is a mismatch between these 2, ORA-01403 is thrown. (Please tell me whether my understanding is correct or not)
3.This mismatch can be on date field or even on the timestamp millisecond as well.
Now, the point im really wondering about :
Some how a mismatch got generated in the destination database (Not sure about the reason) and ORA-01403 is thrown.
If we could update the Destination database with the "Old" data from LCR, this mismatch should be resolved isnt it?
Reply to you Dipali :
If nothing is working out, im planning to put a conflict handler for all tables with "OVERWRITE" option. With the following script
--Generate script for applying Conflict Handler for the Tables for which Supplymentary Logging is enabled
declare
count1 number;
query varchar2(500) := null;
begin
for tables in (
select table_name from user_tables where table_name IN ("NAMES OF TABLES FOR WHICH SUPPLEMENTAL LOGGING IS ENABLED")
loop
count1 := 0;
dbms_output.put_line('DECLARE');
dbms_output.put_line('cols DBMS_UTILITY.NAME_ARRAY;');
dbms_output.put_line('BEGIN');
select max(position) into count1
from all_cons_columns col, all_constraints con
where col.table_name = con.table_name
and col.constraint_name = con.constraint_name
and con.constraint_type = 'P'
and con.table_name = tables.table_name;
for i in 1..count1
loop
query := null;
select 'cols(' || position || ')' || ' := ' || '''' || column_name || ''';'
into query
from all_cons_columns col, all_constraints con
where col.table_name = con.table_name
and col.constraint_name = con.constraint_name
and con.constraint_type = 'P'
and con.table_name = tables.table_name
and position = i;
dbms_output.put_line(query);
end loop;
dbms_output.put_line('DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(');
dbms_output.put_line('object_name => ''ICOOWR.' || tables.table_name|| ''',');
dbms_output.put_line('method_name => ''OVERWRITE'',');
dbms_output.put_line('resolution_column => ''COLM_NAME'',');
dbms_output.put_line('column_list => cols);');
dbms_output.put_line('END;');
dbms_output.put_line('/');
dbms_output.put_line('');
end loop;
end;
Reply to u HTH :
Our Destination database is a replica of the source and no triggers are running on any of these tables.
This is not the first time im facing this issue. Earlier, we had to take big outage times and clear the Replica database and apply the dump from the source...
Now i cant think about that situation.