25.6.17.42 The ndbinfo locks_per_fragment Table

The locks_per_fragment table provides information about counts of lock claim requests, and the outcomes of these requests on a per-fragment basis, serving as a companion table to operations_per_fragment and memory_per_fragment. This table also shows the total time spent waiting for locks successfully and unsuccessfully since fragment or table creation, or since the most recent restart.

The locks_per_fragment table contains the following columns:

• fq_name

  Fully qualified table name

• parent_fq_name

  Fully qualified name of parent object

• type

  Table type; see text for possible values

• table_id

  Table ID

• node_id

  Reporting node ID

• block_instance

  LDM instance ID

• fragment_num

  Fragment identifier

• ex_req

  Exclusive lock requests started

• ex_imm_ok

  Exclusive lock requests immediately granted

• ex_wait_ok

  Exclusive lock requests granted following wait

• ex_wait_fail

  Exclusive lock requests not granted

• sh_req

  Shared lock requests started

• sh_imm_ok

  Shared lock requests immediately granted

• sh_wait_ok

  Shared lock requests granted following wait

• sh_wait_fail

  Shared lock requests not granted

• wait_ok_millis

  Time spent waiting for lock requests that were granted, in milliseconds

• wait_fail_millis

  Time spent waiting for lock requests that failed, in milliseconds

Notes

block_instance refers to an instance of a kernel block. Together with the block name, this number can be used to look up a given instance in the threadblocks table.

fq_name is a fully qualified database object name in database/schema/name format, such as test/def/t1 or sys/def/10/b$unique.

parent_fq_name is the fully qualified name of this object's parent object (table).

table_id is the table's internal ID generated by NDB. This is the same internal table ID shown in other ndbinfo tables; it is also visible in the output of ndb_show_tables.

The type column shows the type of table. This is always one of System table, User table, Unique hash index, Hash index, Unique ordered index, Ordered index, Hash index trigger, Subscription trigger, Read only constraint, Index trigger, Reorganize trigger, Tablespace, Log file group, Data file, Undo file, Hash map, Foreign key definition, Foreign key parent trigger, Foreign key child trigger, or Schema transaction.

The values shown in all of the columns ex_req, ex_req_imm_ok, ex_wait_ok, ex_wait_fail, sh_req, sh_req_imm_ok, sh_wait_ok, and sh_wait_fail represent cumulative numbers of requests since the table or fragment was created, or since the last restart of this node, whichever of these occurred later. This is also true for the time values shown in the wait_ok_millis and wait_fail_millis columns.

Every lock request is considered either to be in progress, or to have completed in some way (that is, to have succeeded or failed). This means that the following relationships are true:

ex_req >= (ex_req_imm_ok + ex_wait_ok + ex_wait_fail)

sh_req >= (sh_req_imm_ok + sh_wait_ok + sh_wait_fail)

The number of requests currently in progress is the current number of incomplete requests, which can be found as shown here:

[exclusive lock requests in progress] =
    ex_req - (ex_req_imm_ok + ex_wait_ok + ex_wait_fail)

[shared lock requests in progress] =
    sh_req - (sh_req_imm_ok + sh_wait_ok + sh_wait_fail)

A failed wait indicates an aborted transaction, but the abort may or may not be caused by a lock wait timeout. You can obtain the total number of aborts while waiting for locks as shown here:

[aborts while waiting for locks] = ex_wait_fail + sh_wait_fail