I am experiencing the following error, while I try to delete a triple from my model:
I am able to insert data into the model, however I recieve the error when I execute the following delete statement:
delete /*+ index(t test_model_tpl_idx) */
from test_model_tpl t
where BITAND( t.triple.rdf_m_id, 79228162514264337593543950335 - 4294967295 ) / 4294967296 = 0 -- Not using a Named Graph
and t.triple.rdf_s_id ='681797856971417497';
ORA-13199: Decr Link Cost (or Del if zeroed) step_num=1 SQLERRM=ORA-01422: exact fetch returns more than requested
number of rows Error during attempt to delete triple: < model_id=9
start_node_id = 681797856971417497 p_value_id=3413820271109615
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 17
ORA-06512: at "MDSYS.SDO_RDF_INTERNAL", line 9173
ORA-06512: at "MDSYS.TEST_MODEL_DEL", line 22
ORA-04088: error during execution of trigger 'MDSYS.TEST_MODEL_DEL' 13199. 00000- "%s"
*Cause: This is an internal error.
*Action: Contact Oracle Support Services.
Vendor code 13199 Error at Line:72
Previously to this error I ran the sem_apis.remove_duplicates() on our model. After that completed, nothing was being changed in the model, I noticed that the triggers on the application table were 'disabled'. I altered the triggers and enabled the INS, DEL, DML triggers.
I have been experiencing slowness with our queries that we previously were not experiencing. Therefore I have been trying different index combinations to find which indexes the optimizer wants to use and which is the fastest.
The most recent that I added was SCGM and it appears to be used over the SCM index, and is much faster as well. The default 'STRICT_DEFAULT=T' option is being used in our SEM_MATCH queries as well.
This has allowed duplicate entries to get into the RDF model, which has led to the failure during deletion attempt. (Note: app table can have duplicates, but not the corresponding RDF model.)
Please let us know if any operation was done to explicitly disable the PCSGM index or drop and re-create it as a nonunique index. If you would like, please send me direct email: souripriya dot das at oracle dot com.
In addition to what Souri suggested, I have a question regarding "... After that completed, nothing was being changed in the model, I noticed that the triggers on the application table were 'disabled'. I altered the triggers and enabled the INS, DEL, DML triggers..."
I assume the remove_duplicates call failed? Otherwise, the triggers should be re-enabled after the call.
If the data in your application table is out of sync with your RDFM_<model-name>, then you may want to dump
the data out in N-TRIPLES (or quads) and re-load them into a new model.
Thanks for the assistance. I did not see the remove_duplicates function 'fail', however I did see the triggers disabled, so it must have failed. Does remove_duplicates work to fix this problem?
I will rebuild the application table and be sure to not disable the PCSGM index (it's possible I ran execute sem_apis.drop_sem_index('PCSGM'); execute sem_apis.add_sem_index('PCSGM');) Would that cause the index to be recreated with NONUNIQUE?
Yes. The sequence of operations, execute sem_apis.drop_sem_index('PCSGM'); execute sem_apis.add_sem_index('PCSGM');, would drop the unique PCSGM index and re-create it as a nonunique index. That is very likely what has happened.
However, sem_apis.drop_sem_index('PCSGM') should have caused raising of an error disallowing the operation. When you get a chance, please submit a Service Request for this problem.
Please contact us directly if you need help in rebuilding the model(s) in your semantic network.