Users may notice that Foglight for DB2 shows "Lock Waits" as 0 in the UI for a selected historical period, even though running a DB2 snapshot command for the same period reports lock wait activity (for example, 94 lock waits). This article explains why this difference occurs, how Foglight collects lock wait data, and how the retention policy affects what you see.
There are a few reasons for this difference:
1. Different Data Sources and Methods
The DB2 command `db2 get snapshot for database ievotep | grep -i lock` collects lock wait data using DB2's traditional snapshot monitoring, reporting the total number of lock waits since the last reset.
Foglight collects lock waits using the `MON_GET_DATABASE` function in its query (see example query above), which is a newer method in DB2. Both methods are supposed to provide the cumulative lock waits since the last reset, but there may be minor differences in how or when they count certain events, depending on DB2 version/configuration.
2. Timing
For the numbers to match, both the snapshot and Foglight's poll must read the counters at nearly the same time, and there must have been no resets in between.
3. How Foglight Displays Data
Foglight collects and stores the value of lock waits at every polling interval (such as every 5–15 minutes).
When you select a time range (such as 12:00–13:00), Foglight typically shows the last value collected in that window. If the agent did not collect data at the end of the period, or if the agent was not running, you may see 0.
4. Retention Policy
By default, Foglight stores historical lock wait data (`DB2_History_Locks_Wait` and `DB2_Partition_History_Locks_Wait`) for only 3 days.
After 3 days, this data is automatically deleted, so any attempt to view or query lock wait data older than 3 days will show 0 or blank, even if there was activity at the time.
Result: Foglight shows zero, because the data has been purged.
