# Inspect requests that query a view

Views are named SELECT definitions, so diagnose a view query as a normal SQL request. Capture its query ID from the response or query history, then inspect that request's terminal event.

```sql
SELECT query_id, query, query_duration_ms, read_rows, peak_memory_usage
FROM system.query_log
WHERE type = 'QueryFinish'
  AND query LIKE '%order_amounts%'
ORDER BY event_time DESC
LIMIT 10;
```

A text search is only a convenient starting point. It can also match a comment, another object name or the diagnostic query itself. Use the exact query ID for a final correlation. `normalized_query_hash` groups structurally related statements but is not a catalog of view dependencies.

To understand how a particular view read accesses its source data, run `EXPLAIN QUERY PLAN` on that read. The plan describes the concrete statement; it does not prove that a stored materialization was refreshed. Coordinator DB ordinary views contain no stored result rows, and materialized views are unavailable.

Keep a record of the view definition with the diagnostic report so the source filters and joins are reviewable.

See [`CREATE VIEW`](https://coordinatordb.com/docs/reference/statements/create/view), [query history](https://coordinatordb.com/docs/reference/system-tables/query-log) and [`EXPLAIN`](https://coordinatordb.com/docs/reference/statements/explain).