What you will be able to do
- Open Query History, filter it, and explain who can see which query runs
- Read the query details panel: status, statement text, wall-clock duration versus aggregated task time, I/O and pruning
- Cancel a running query and know when cancellation must happen elsewhere
- Use the system.query.history table to spot cache hits and jump from a record to its query profile
Key concept
Reusing earlier work — Both query history and caching save time because Databricks keeps what an earlier run already produced. History keeps the statement, metrics and profile of past runs so you don't have to rerun them to debug. Caches keep results and data so a repeated query over unchanged tables doesn't have to be computed again.
1.Opening query history and who can see it
When a query is slow or wrong, you often want what already happened rather than another run: the exact statement, how long it took, and where the time went. Databricks SQL records this in Query History, which you open from the sidebar. The documentation sums up its purpose plainly: the screen is there to help you debug issues with queries. You can also work with it through the Query History API. If your workspace has serverless compute, the history goes beyond SQL warehouse statements and also includes SQL and Python queries run on serverless compute for notebooks and jobs.
A busy warehouse produces a long list, so use the filters at the top of the page to narrow it. You can filter by user, date range, compute, duration, query status, statement type, statement ID and query tags. Filtering by duration is a quick way to find your slowest statements. Filtering by statement ID takes you straight to one specific execution.
Visibility depends on ownership and warehouse permissions. You can always see runs of queries you own. Other users can see those runs if they have at least CAN VIEW access to the SQL warehouse that ran the query. Viewing the full query profile has a slightly higher bar: you must own the query or have at least CAN MONITOR on the warehouse.
Checkpoint 1 of 4· Check yourself
A colleague wants to look through earlier runs of a query you own. What is the minimum access they need?
Non-owners can view query runs once they have at least CAN VIEW on the warehouse that executed them.
“Other users can view query runs if they have at least CAN VIEW access to the SQL warehouse that executed the query.”Source: docs.databricks.com
2.Reading the query details panel
Click a query's text and a summary panel opens on the right. It shows the run's status (Queued, Running, Finished, Failed or Cancelled), the user and compute details, and a UUID for that execution. It also shows the complete query statement, so you can copy the exact SQL that ran instead of rebuilding it. Below the statement are popular metrics. Some of them have filter icons, which show what percentage of data was pruned during scanning. A low pruning percentage on a large table tells you the query read more data than it needed to.
Two timing figures answer different questions. Query wall-clock duration is the total elapsed time from the start of scheduling to the end of execution, broken down into scheduling, optimization and file pruning, and execution. Aggregated task time is the combined time spent across all cores of all nodes. The panel also shows I/O details for data read and written, and a link to the query source. A small preview of the query profile DAG helps you judge complexity, and the See longest operators button lists the operators that ran longest.
Checkpoint 2 of 4· Check yourself
A query's aggregated task time is far higher than its wall-clock duration. What is the most likely explanation?
Aggregated task time adds up work across all cores. When tasks run in parallel, that total can be much larger than the elapsed time. Waiting for nodes has the opposite effect.
“It can be significantly longer than the wall-clock duration if multiple tasks are excuted in parallel.”Source: docs.databricks.com
From the same panel you can stop a runaway statement, whether you started it or someone else did. Open the query, then click Cancel next to Status. The status changes to Canceled. The button only appears while the query is running. Statements that run on Lakeflow pipelines compute are an exception: you can only cancel them from the Pipelines UI. For the full execution plan, click View Query Profile at the bottom of the panel.
Checkpoint 3 of 4· Exam question
A data analyst wants to reuse a complex five-table join a colleague ran in the SQL editor sometime last week, but the analyst cannot find a saved copy and does not want to retype the join logic from memory. Which approach lets the analyst locate and copy the exact query text without rewriting it?
Correct answer: A — Open Query History in the SQL editor, filter the list by date range and by the colleague's user name, and open the matching entry to copy the full statement text.
- A. Query History records every executed statement with filters for user, date range, compute, and duration, so filtering by the colleague's name and last week's dates surfaces the run and its full statement text for copying.
- B. Query Profile visualizes the execution plan and timing of a specific completed query, but it does not search across other users' run history or recover a colleague's query text.
- C. The disk cache stores previously read data files on local SSD to speed up scans of the same underlying data; it does not index or expose the SQL text of past queries.
- D. Disabling result-cache reuse forces every query to recompute from the underlying tables and has no effect on finding or retrieving a previously run query's statement text.
Sources1
3.The system.query.history table
The UI shows one workspace at a time. For history across the whole account, privileged users can query the system table system.query.history. It holds records for SQL warehouses, serverless compute for notebooks and jobs, and Lakeflow pipelines, from every workspace in the same region. By default, only admins can access it. To share its data, Databricks recommends a dynamic view for each user or group. Records usually arrive within about an hour, so the table suits trend analysis better than live debugging. One more limit: statement_text returns <REDACTED> unless you are an account admin or a member of the databricks_pii_access group.
| Column | What it tells you |
|---|---|
| from_result_cache | TRUE if the statement result was fetched from the cache |
| cache_origin_statement_id | For cached results, the statement ID of the query that first put the result into the cache; otherwise the query's own ID |
| read_io_cache_percent | Percentage of bytes of persistent data read from the IO cache |
| waiting_at_capacity_duration_ms | Time spent queued waiting for available compute capacity |
| compilation_duration_ms | Time spent loading metadata and optimizing the statement |
| execution_duration_ms | Time spent executing the statement |
These columns let you check whether caching is actually doing its job. A run where from_result_cache is TRUE did no fresh computation, and its cache_origin_statement_id points to the run that did. Splitting total time into waiting, compilation and execution shows whether a slow statement was busy computing or just waiting in a queue. Once a record looks interesting, you can go from the table to the visual profile in the workspace UI.
Checkpoint 4 of 4· Put it in order
Put these steps in order to open the query profile for a record you found in system.query.history.
- 1.Check the record's workspace_id and make sure you are logged in to that workspace
- 2.Click Query History in the workspace sidebar
- 3.Paste the statement_id into the Statement ID field
- 4.Copy the record's statement_id
- 5.Click the name of the query to see its metrics overview
- 6.Click See query profile
The statement_id connects the system table to the UI. You must be in the matching workspace, filter by that ID, and then open the profile.
“In the Statement ID field, paste the statement_id on the record.”Source: docs.databricks.com
One of them computed the result and stored it in the cache. The other was served from that cached result. For a cache hit, cache_origin_statement_id holds the ID of the query that originally inserted the result, not the hit's own ID.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A query shared with Run as Owner permissions shows up in the owner's query history, because the owner's credentials were used.Why is that wrong?
The run appears in the history of the user who executed it, not the user who shared it.
Covered in Opening query history and who can see it
2.Any running statement can be canceled from the Query History panel.Why is that wrong?
Statements on Lakeflow pipelines compute can only be canceled from the Pipelines UI, and the Cancel button only appears while a query is running.
Covered in Reading the query details panel
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“You can use the information available through this screen to help you debug issues with queries.”
↩︎ Opening query history and who can see it“filter the list by user, date range, compute, duration, query status, statement type, statement ID, and query tags”
↩︎ Opening query history and who can see it“your query history also contains all SQL and Python queries run on serverless compute for notebooks and jobs”
↩︎ Opening query history and who can see it“The filter icons that appear with some metrics indicate the percent of data pruned during scanning.”
↩︎ Reading the query details panel“Cancel only appears when a query is running.”
↩︎ Reading the query details panel“By default, only admins have access to your account's system tables.”
↩︎ The system.query.history table“appear in the query history of the user executing the query and not the user that shared the query.”
↩︎ Exam trap 1“Statements that use Lakeflow pipelines compute can only be canceled from the Pipelines UI.”
↩︎ Exam trap 2“appear in the query history of the user executing the query and not the user that shared the query.”
↩︎ Prediction“Other users can view query runs if they have at least CAN VIEW access to the SQL warehouse that executed the query.”
↩︎ Checkpoint“It can be significantly longer than the wall-clock duration if multiple tasks are excuted in parallel.”
↩︎ Checkpoint - 2.
“To view a query profile, you must either be the owner of the query or you must have at least CAN MONITOR permission”
↩︎ Opening query history and who can see it - 3.
“Records are typically available within one hour.”
↩︎ The system.query.history table“For query results fetched from cache, this field contains the statement ID of the query that originally inserted the result into the cache.”
↩︎ The system.query.history table“TRUE indicates that the statement result was fetched from the cache.”
↩︎ The system.query.history table“In the Statement ID field, paste the statement_id on the record.”
↩︎ Checkpoint
Also cited
“If a query is re-submitted and the underlying tables have not changed, Databricks SQL can re-use the result set, reducing query execution cost.”
↩︎ Key concept