ADA-C01 Question 403
Single answerLatency for historical viewsAn administrator is building an operations dashboard that must display near-real-time warehouse load, recent query activity, and task failures across the account. The first design uses ACCOUNT_USAGE views, but the dashboard often appears 1-3 hours behind actual activity, causing delayed incident response. The administrator needs the best source for lower-latency historical monitoring data while still querying with SQL. Which approach should the administrator choose?
- A
Query the corresponding Information Schema table functions, such as QUERY_HISTORY and WAREHOUSE_LOAD_HISTORY, instead of relying on ACCOUNT_USAGE views for the dashboard
- B
Continue using ACCOUNT_USAGE views, but run the dashboard queries on a larger virtual warehouse to reduce metadata latency
- C
Create a materialized view on top of SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY to force faster refresh of the underlying historical data
- D
Enable search optimization on the SNOWFLAKE database so ACCOUNT_USAGE views refresh more quickly
Show answer and explanation
Correct answer: A
Explanation
The key distinction is between ACCOUNT_USAGE historical views and lower-latency monitoring access patterns. SNOWFLAKE.ACCOUNT_USAGE is useful for reporting, trending, auditing, and account-level history, but many of its views are not intended for real-time operational dashboards because they can lag behind current activity. For near-real-time administrative monitoring, Snowflake documentation recommends using Information Schema table functions and related monitoring functions where available, such as QUERY_HISTORY and TASK_HISTORY. Increasing warehouse size, adding search optimization, or building a materialized view may improve query performance in some designs, but none of these changes reduce the inherent latency of when ACCOUNT_USAGE data becomes available. Best practice is to choose the metadata source based on freshness requirements: Information Schema for more recent operational visibility, ACCOUNT_USAGE for broader historical analysis and governance reporting.
- A. Correct.
Correct. For operational monitoring that needs lower latency, the Information Schema table functions are the better choice. Snowflake's ACCOUNT_USAGE views are historical and can have latency before new records appear, whereas Information Schema functions such as QUERY_HISTORY, TASK_HISTORY, and related monitoring functions are intended for more recent activity with lower latency. This is the practical design choice when a SQL-based dashboard must reflect recent account activity more quickly.
- B. Incorrect.
Incorrect. Warehouse size can improve execution speed of the dashboard query itself, but it does not change when metadata becomes available in ACCOUNT_USAGE. The issue in the scenario is data freshness latency in the historical view, not query compute performance.
- C. Incorrect.
Incorrect. A materialized view can only refresh based on data already visible from its source. It cannot make SNOWFLAKE.ACCOUNT_USAGE publish new metadata sooner. This option reflects a common misconception that downstream objects can reduce source-system latency.
- D. Incorrect.
Incorrect. Search optimization can improve selective query performance for supported workloads, but it does not alter the refresh schedule or publication latency of ACCOUNT_USAGE historical metadata. It addresses access speed, not monitoring-data freshness.