Monitoring and Tuning

Typically these operations are VERY fast and the mutex locking is transient. However, if you have several sessions actively modifying a table (inserting, deleting, creating indexes, compressing, reorging, etc.) there can be some contention for this single resource. There are some things you can do. Fragmenting the table ROUND ROBIN so that the number of concurrent accesses to each of the tables partitions' header page are reduced by a factor of the number of partitions/fragments is one. Changing large insert jobs to use INSERT/PUT cursors with a maximum sized communications buffer (see FET_BUF_SIZE) so that batches of many rows are inserted in a single operation is another.

Locked mutexes aren't by default bad, it could possibly indicate a performance problem if they are a large list of waiters on a particular mutex, or large wait times.

The uselock mutex is involved in shared memory communication and so it's normal to see
that mutex locked while the sqlexec threads have no work.