ORA-03113 while executing a sql query

One possible cause of this error is a thread crash on the server side. Check whether the Oracle server has generated any trace files, or logged any errors in its alert log.

You say that removing one condition from the query causes the problem to go away. How long does the query take to run without that condition? Have you checked the execution plans for both versions of the query to see if adding that condition is causing some inefficient plan to be chosen?

I've had similar connection dropping issues with certain variations on a query. In my case connections dropped when using rownum under certain circumstances. It turned out to be a bug that had a workaround by adjusting a certain Oracle Database configuration setting. We went with a workaround until a patch could be installed. I wish I could remember more specifics or find an old email on this but I don't know that the specifics would help address your issue. I'm posting this just to say that you've probably encountered a bug and if you have access to Oracle's support site (support.oracle.com) you'll likely find that others have reported it.

Edit:I had a quick look at Oracle support. There are more than 1000 bugs related to ORA-03113 but I found one that may apply:

Bug 5015257: QUERY FAILS WITH ORA-3113 AND COREDUMP WHEN QUERY_REWRITE_ENABLED='TRUE'

To summarize:

• Identified in 9.2.0.6.0 and fixed in 10.2.0.1
• Running a particular query(not identified) causes ORA-03113
• Running explain on query does thesame
• There is a core file in$ORACLE_HOME/dbs
• Workaround is to setQUERY_REWRITE_ENABLED to false: altersystem set query_rewrite_enabled =FALSE;

Another possibility:

Bug 3659827: ORA-3113 FROM LONG RUNNING QUERY

• 9.2.0.5.0 through 10.2.0.0
• Problem: Customer has long running query that consistently produces ORA-3113 errros.
  On customers system they receive core.log files but do not receive any errors in the alert.log. On test system I used I receivded ORA-7445 errors.
• Workaround: set "_complex_view_merging"=false at session level or instance level.

You can safely remove the "UPPER" on both parts if you are using the like with numbers (that are not case sensitive), this can reduce the query time to check the like sentence

AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')

Is equals to:

AND someMultiJoin.someColumn LIKE '%90936%'

Numbers are not affected by UPPER (and % is independent of character casing).