ORA-00600: internal error code, arguments: [12406], [], [],

After the rebuild of structure table and corresponding domain indexes we are getting the following oracle error





SELECT * FROM COMPOUND


WHERE jc_compare(smiles , 'CC(=O)c1cn2ncc(-c3ccccc3C(F)(F)F)c2nn1','t:e') = 1





ORA-00600: internal error code, arguments: [12406], [], [], [], [], [], [], []





See below the jchem version we are using on that database





SQL*Plus: Release 10.2.0.1.0 - Production on Thu Apr 17 22:46:35 2008





Copyright (c) 1982, 2005, Oracle. All rights reserved.





Enter user-name:


Connected to:


Oracle Database 10g Release 10.2.0.1.0 - Production





SQL>


JCHEM_CORE_PKG.GETENVIRONMENT()


------------------------------------------------------------------------


Oracle Database 10g Release 10.2.0.1.0 - Production


PL/SQL Release 10.2.0.1.0 - Production


CORE 10.2.0.1.0 Production


TNS for Linux: Version 10.2.0.1.0 - Production


NLSRTL Version 10.2.0.1.0 - Production


NLSRTL Version 10.2.0.1.0 - Production


JChem version in the database: 3.2.6


JChem version in the Tomcat server: 3.2.6


java.vm.version: 1.5.0_04-b05


java.vm.vendor: Sun Microsystems Inc.


Apache Tomcat/5.0.28





JCHEM_CORE_PKG.GETENVIRONMENT()


------------------------------------------------------------------------


Major JDBC version in Tomcat: 10


Minor JDBC version in Tomcat: 2

Have you applied Oracle patch 4655283?





Please, see also:


http://www.chemaxon.com/jchem/doc/admin/cartridge.html#req





Thanks


Peter

Yes. Jchem was already installed in that database. So it is not a new installation on a new database.





We have resolved the ORA-600 problem by rebuilding jchem indexes one at a time. This may be a limitation in jchem cartridge where you cannot build indexes in different session as a parallel run. Can you verify and let us know as our rebuild script submits database jobs to rebuild as many indexes the table have which we can't do if the table contains jchem index?

I could not immediate reproduce the problem with the following configuration:

Code:

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi PL/SQL Release 10.2.0.3.0 - Production CORE    10.2.0.3.0      Production TNS for Linux: Version 10.2.0.3.0 - Production NLSRTL Version 10.2.0.3.0 - Production NLSRTL Version 10.2.0.3.0 - Production JChem version in the database: 3.2.6 JChem version in the Tomcat server: 3.2.6 java.vm.version: 1.5.0_15-b04 java.vm.vendor: Sun Microsystems Inc. Apache Tomcat/5.5.25 Major JDBC version in Tomcat: 10 Minor JDBC version in Tomcat: 2

I indexed three tables -- all of them containing the NCI 2000 dataset (250251 structures each) -- simultaneously without problem. Indexing the three tables in parallel (750k structures in total) took about 15 minutes on a 2.6GHz dual-core Athlon.





Let me know if you have suggestions about "improving" my test case.





In general, the following measures may potentially help removing the problem:





1. If there were problematic index operations (prior to the current problem) on the table where this problem occurred, drop the index on the table with the force clause. This will trigger additional clean-ups on Oracle's part, in particular removing potential inconsistencies left-over from a previous failure.





2. Upgrade to Oracle patch level 10.2.0.3 (the version I used for my test), because there have been many bug fixes since 10.2.0.1 in addition to the bug fix (4655283) mentioned in my first post to this topic.

Hi Rajeev,





Have you retested this problem after upgrading to Oracle patch level 10.2.0.3?





I have retried to reproduce the problem with a different setting: I created a single table with two structure columns and indexed the two structure columns of this same table in parallel. Still no errors on my side.





Note that the indexing process with jc_idxtype will automatically use all available CPU cores on the JChem Server host. So in a typical setup, indexing multiple structure columns in parallel (be they in the same or in different tables) will not have a significant performance benefit over indexing them one after the other. In my test environemnt, the typical performance gain was about 2-3 percent.





Still, this feature is supposed to work. I suggest to retest it with Oracle patch level 10.2.0.3.





Thanks


Peter