Session 1 gets a child cursor for a table_x_x_xxxx_x_x
cursor and hold the mutex in share mode
Session 2 marks the child cursor object INVALID here when
dropping the partition:
**1 atbdrv -> atbFMdrop -> kqlidpfgr -> kglivl0 -> kglhdiv0 ->
kgl_scan_dependents -> kglhdiv_callback
but it does NOT mark the LOCK as broken. Hence you have an INVL
child object with an unbroken lock on it held S mode by session 1.
Session 2 then reconnects and issues an insert to the table AA
and attempts DBMS_LOB.WRITEAPPEND to a LOB in that partition.
This now wants to check privileges of the LOB using the
table_x_x_xxxx_x_x cursor - when it looks at the child list
it sees the first child which is INVL and has an S lock and
waits on "cursor: pin X" under the stack:
kokacau -> kokapvpr -> kkspsc0 -> kksfbc -> kksSearchChildList
Session 1 does not release the mutex until it exits so session
2 is blocked indefinitely.
To be seeing this problem under 10.2 then you are likely to need to see the
* DDL on a partitioned table
* The partitioned table has an object column (LOB, CLOB etc)
* Sessions block on 'cursor: pin X' and 'kksfbc child completion'
* The 'cursor: pin X' is waiting on a pseudo cursor (a cursor with a name
that starts with "table_")
More generally (all versions), you might be seeing this bug if you see kgl
objects marked as invalid (INVL) but the associated kgl locks are not marked
For the symptoms seen by this customer the workaround is to avoid executing
DDL on partitioned tables with object column when there are other sessions
that may be concurrently executing DML against the partitioned table.
]]Executing DDL on partitioned tables that have CLOB, LOB (etc) columns might
]]cause other sessions to block. This has now been corrected.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16158219/viewspace-594449/，如需转载，请注明出处，否则将追究法律责任。