Db2 has no SLEEP and no WAITFOR (WAITFOR is T-SQL, a common mislabel), so a delay is produced by forcing the database to do expensive work only when a condition is true. A large cross join over a catalog view is the usual device.

Joining a big catalog view to itself several times produces a huge intermediate result, and counting it costs measurable CPU. Gate it with CASE so the cost is paid only on a true test:

' AND (SELECT CASE WHEN (ASCII(SUBSTR((SELECT CURRENT USER FROM SYSIBM.SYSDUMMY1),1,1))>77) THEN (SELECT COUNT(*) FROM SYSCAT.COLUMNS a, SYSCAT.COLUMNS b, SYSCAT.COLUMNS c) ELSE 1 END FROM SYSIBM.SYSDUMMY1)>0-- 

When the test is true, Db2 evaluates the triple cross join (often seconds on a normal catalog); when false, the ELSE returns immediately. Tune the number of joined copies, or use a larger view such as SYSIBM.SYSCOLUMNS, so a true test adds a clear, repeatable delay without overloading the server.

Binary-search each character on the delay exactly as in boolean extraction. Because the delay is CPU-bound rather than a fixed sleep, it is noisier than pg_sleep or WAITFOR, so keep the work large enough to read clearly and repeat a positive hit before trusting it. Given Db2's weak error channel, boolean inference is usually preferred, with this heavy-query timing as the fallback when no boolean difference is visible.

References#

• IBM Db2 SQL Reference: subselect, joins, CASE, catalog views
• PortSwigger Web Security Academy: Blind SQL injection