It is not of concern to have SMON hold a TS lock in SX mode for long periods of time.

The reason for SMON holding this lock has to do with OPS/RAC databases, but it present nevertheless in single instance Oracle as well. In parallel server, sessions running on distinct instances may need temporary disk space in the same temporary contents tablespace. Because space in temporary contents tablespaces is managed via an SGA data structure (the sort extent pool) it is imperative that each instance use a distinct segment within the tablespace. The allocation of tablespace extents to the temporary segments for distinct instances is managed normally via the data dictionary or tempfile bitmap.

The holding of the TS lock by SMON ensures that an instance cannot adopt and use an existing temporary segment that another instance still has an interest in. The lock identifiers in this case are the tablespace number and the tablespace relative database block address (rdba) of the segment header block.

Here is the result of running the script during a heavy process.

        RESOURCE              SID HOLDING WANTING    SECONDS
        -------------------- ---- ------- ------- ----------
        ....
        TS-3-511705090       SMON      SX                304

It depends on the lock types. Please include some output from the script.

I am running the query from the enqueue_lock.sql script and all the resources have small times, only resources allocated by SMON present huge times. I wonder whether because my initial extents and next extents are small and my tables present many extents, if this is causing contention with SMON. I have the theory that if I increase the size of my table extents, SMON won't present this huge locking times because it will be called less times to manage the space allocation. Could you tell me if my theory is right, or am I wrong and this indication of resource lock by SMON is normal?