I could probably guess 99% of the statement ;)
Joking aside, if the full SQL didn’t dump out into the process’s trace
file, you might be able to do some detective work based on the library
locks the session has taken out.
Joining v$libcache_locks to v$db_object_cache on object_handle = addr where
holding_user_session is your parser’s saddr. If you filter on namespace =
'TABLE/PROCEDURE', you should be able to see which tables the SQL needs to
be looking at.
Hope that helps,
Andrew
On Mon, 12 Jul 2021 at 16:27, Stefan Koehler <contact@xxxxxxxx> wrote:
Hello Nenad,
any chance with a process state dump (or error stack trace)?
Best Regards
Stefan Koehler
Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Twitter: @OracleSK<
Noveljic Nenad <nenad.noveljic@xxxxxxxxxxxx> hat am 12.07.2021 17:25geschrieben:
WHEN (CASE WHEN (CASE WHEN (CASE WHEN ((CASE WHEN ((CASE WHEN (((CASE WHEN …
Thanks!
I got a part of SQL (it’s chopped)
Any idea for getting the full text?
SQL> oradebug setospid 17876
Oracle pid: 107, Unix process pid: 17876, image: oracle@svdbp02p
SQL> oradebug current_sql
SELECT (CASE WHEN ((CASE WHEN (CASE WHEN (CASE WHEN (CASE WHEN (CASE
--
The problem might be with the parsing of a nested case.
Have to get the full text to experiment.
//www.freelists.org/webpage/oracle-l
