#### 23.6.14.41 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`](mysql-cluster-ndbinfo-operations-per-fragment.html) and [`memory_per_fragment`](mysql-cluster-ndbinfo-memory-per-fragment.html). 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`](mysql-cluster-ndbinfo-threadblocks.html) 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**](mysql-cluster-programs-ndb-show-tables.html).

 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
```

