We Are Seeing "An Error Occurred When Calling Function 'sdq_dedup_realtime_nomemory () '" (Doc ID 1918376.1)

Last updated on MAY 11, 2016

Applies to:

Siebel CRM - Version [23030] and later
Information in this document applies to any platform.


When running DQ matches, Customer is seeing "An error occurred when calling function 'sdq_dedup_realtime_nomemory () '" and no response from IIR . This leads to no result from Siebel when running WS calls to match.

"DataQuality DataQualityDebug 5 0000125653df5f33:0 2014-08-07 13:40:53 DeDupByThirdParty: sdq_dedup_realtime (inputXML):

DataQuality DataQualityDebug 5 0000125653df5f33:0 2014-08-07 13:40:53 <Data><DriverRecord><NAME>Michael Martin</NAME><City>Santa Rosa</City><PrimaryPostalCode>95409</PrimaryPostalCode><State>CA</State><StreetAddress>6340 Meadowridge Dr</StreetAddress><RowId>1-FuzzyQuery</RowId></DriverRecord></Data> 

ObjMgrBusServiceLog Error 1 0000125653df5f33:0 2014-08-07 13:40:53 (dedupsvc2.cpp (3801)) SBL-APS-00118: Data Quality vendor-specific error: An error occurred when calling function 'sdq_dedup_realtime_nomemory () ' in connector 'ISS': "(6) ISS API Call failed."

The error "Extract keydata segment failed (wrong seq)" can be produced in the following scenarios:
1) When the IDX has a corrupted data. When IIR first creates the IDT and IDXs, it put data into IDX could in theory be just the fuzzy key and a pointer to the IDT record containing the rest of the data. But for speed, it actually takes a copy of what is in the IDT and stores it in a compressed format in the IDX. That means that when it does searches it only needs to get the IDX records and it will have everything it needs to do the matching as well.
The problem is that the IDX record can only be a maximum of 255 bytes long (for various reasons). So if IIR cannot squeeze all the data into one IDX record, it creates an extra (extension) record to hold the rest. (It might even have to create more than one extension).
This error is reported when IIR does a search and tries to get the extension but finds the extension record belongs to another IDT record. The only solution to resolve this issue is to rebuild the IDT and IDXs (Refresh and LoadIDT). To avoid this issue in future you can use --full-key-date in SDF before reloading the data. But this workaround will impact on performance as it will need to do extra I/O to fetch record from IDT table.

2) This issue also occurs if you are searching a record and search result finds a record that is partially updated by updsync. You need to make sure that it should not search the record which is in update process.

This is a known issue with IIR901 and addressed with 9.2 (FixO008 and FixO035) and 9.5.3HF2. Informatica can not back port these fixed due to lots of code dependency. 



Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms