Object usage settings

Querona records which tables and views are being used: when each one was last read, when it was last written to and when its statistics were last calculated, together with the counts behind those dates. The Administration Portal shows them on the table and view screens, and sys.qua_table_usage reports them over SQL. Both are server-state data and need the VIEW SERVER STATE permission: an administrator sees the dates and counts, and a user who can merely see the object does not.

What counts as usage

Any statement a user or an application runs counts, whoever issued it: a client session, a scheduled job, the body of a stored procedure or a statement forwarded by another node. Engine housekeeping does not. Refreshing a materialized view does not make its source tables look read, importing metadata records nothing, and calculating statistics moves the statistics date rather than the read date. A statement that fails records nothing, and a statement that defines an object, such as CREATE VIEW, records nothing against the objects its definition names.

An object that is written to by a statement is counted as written and not also as read, so an UPDATE does not inflate the read count of the table it changes.

Settings

Configuration option	Default value	Requires restart?	Description
Track object usage	Enabled	No	Whether usage is recorded at all. Turning it off stops recording and stops writing, and what the node has observed so far is forgotten at the next flush; rows already stored are left alone, so every object then reports the way one nothing has been observed for does.
Object usage flush interval	00:01:00	No	How often a node writes what it has observed to the metabase. A change takes effect after the interval currently running.
Object usage persist resolution	00:15:00	No	How far a read or write date has to move before it is worth another metabase write. This is what keeps a heavily queried object from being rewritten on every flush. The serving node reports exact dates whatever the value, so the setting trades how fresh the stored date is against how often the metabase is written. A statistics calculation ignores it and is written at the next flush.

Reading the dates

A date is empty until the Engine observes the first statement of that kind. Counting starts when object usage tracking is installed, not when the object was created, so an object that is genuinely in daily use still reports nothing until it is next used.

In a cluster every node keeps its own exact view and merges it into one shared row, so the counts an administrator sees cover the whole installation. A node’s own view is always at least as complete as the stored row, and the stored row catches up within a flush interval.