ACCOUNT_USAGE Deep Dive + Query Attribution History
Sub-objective 2.3 closes today with the schema every C03 candidate is expected to read fluently. SNOWFLAKE.ACCOUNT_USAGE holds 365 days of historical metadata across queries, warehouses, logins, storage, and access events. Two facts on it carry most of the exam weight: the 45-minute to 3-hour latency band, and the persistence of dropped-object records. The newer QUERY_ATTRIBUTION_HISTORY view also lands today, since C03 added query-level cost attribution as an explicit outcome. Day 28 then closes Week 4 with the recap and mixed quiz.
What You’ll Learn
- How the
ACCOUNT_USAGEschema differs fromINFORMATION_SCHEMA, and when each is the right answer. - The 45-minute to 3-hour latency band, and why a single-number latency option is always wrong.
- The five views the exam keeps coming back to:
QUERY_HISTORY,WAREHOUSE_METERING_HISTORY,LOGIN_HISTORY,STORAGE_USAGE, andACCESS_HISTORY. - Why
ACCESS_HISTORYrequires Enterprise Edition or higher, and what that gate means in a question stem. - What
QUERY_ATTRIBUTION_HISTORYadds in C03, and how it changes the answer to cost-attribution questions.
Plain-English First
Today introduces three terms that sound similar but are not interchangeable. Lock them in before the concepts.
| Plain meaning | Snowflake meaning |
|---|---|
| “Usage data” | The ACCOUNT_USAGE schema inside the SNOWFLAKE database. 365-day metadata views. |
| “Metadata schema” | INFORMATION_SCHEMA. Exists per database. Real-time. Currently-existing objects only. |
| “Latency” | Gap between an event happening and it appearing in ACCOUNT_USAGE. Up to about 3 hours. |
| “Retention” | How long the view keeps a row. 365 days for most ACCOUNT_USAGE views. |
| “Cost attribution” | Tying warehouse credits back to who or what caused them. Answered by QUERY_ATTRIBUTION_HISTORY. |
Today’s Concept
Micro-Concept 1: What ACCOUNT_USAGE Is, and How It Differs from INFORMATION_SCHEMA
The SNOWFLAKE.ACCOUNT_USAGE schema is an account-level catalogue of historical metadata. It sits inside the read-only SNOWFLAKE share that every account receives at signup. ACCOUNTADMIN can query it directly. It can also grant four SNOWFLAKE database roles for delegated access. USAGE_VIEWER covers cost and usage views. GOVERNANCE_VIEWER covers governance and access views. OBJECT_VIEWER covers object metadata. SECURITY_VIEWER covers login and grant audits.
INFORMATION_SCHEMA is the SQL-standard metadata schema. Snowflake creates one inside every database. It serves the current state of objects in that one database, with zero latency, but only for objects that exist right now.
The three structural differences are the only ones the exam tests:
- Latency.
ACCOUNT_USAGEhas a 45-minute to 3-hour delay, varying by view.INFORMATION_SCHEMAis real-time. - Retention.
ACCOUNT_USAGEretains roughly 365 days.INFORMATION_SCHEMAranges from 7 days to 6 months depending on the view. - Dropped objects.
ACCOUNT_USAGEkeeps rows for dropped objects, usually with aDELETEDtimestamp column.INFORMATION_SCHEMAshows currently-existing objects only.
If a stem mentions a dropped table, a six-month-old query, or a historical audit, the answer is ACCOUNT_USAGE. If a stem asks for the current state of a database with no delay, the answer is INFORMATION_SCHEMA. Candidates I have trained pick this pair correctly when they read the time horizon first and the latency requirement second.
Micro-Concept 2: The 45-Minute to 3-Hour Latency Band
The latency band on ACCOUNT_USAGE is the most-tested numeric fact in this sub-objective. The official C03 practice item phrases it as a range: 45 minutes to 3 hours. Most views land closer to two hours. A few sit at the high end.
Any answer that pins the latency to a single number is the trap. The exam will sometimes offer “30 minutes”, “exactly 45 minutes”, or “real-time” as distractors. None of those are correct. The right framing is the range, with the upper bound around 3 hours for most views.
One newer view sits outside the typical envelope. QUERY_ATTRIBUTION_HISTORY can have a latency of up to 8 hours, since it is computed from aggregated warehouse meter readings. That is documented separately. The exam treats the 45-minute-to-3-hour figure as the standard band for the schema overall.
A small operational note on the edge cases. Trial accounts and very quiet accounts can hit a longer delay. If a table sees too few writes, latency on some views can stretch up to 2 days. The exam does not test this edge case. The 45-minute to 3-hour figure is the one to memorise.
Micro-Concept 3: The Five Views the Exam Reuses
The C03 exam reuses a small set of ACCOUNT_USAGE views across cost, governance, and security questions. The table below lists the five that account for almost every question on this schema.
| View | What it stores | Edition gate |
|---|---|---|
QUERY_HISTORY | One row per query. Run time, warehouse, user, role, bytes scanned, credits used cloud services. | All editions |
WAREHOUSE_METERING_HISTORY | Hourly credit usage per warehouse, split into compute and cloud services credits. | All editions |
LOGIN_HISTORY | Authentication events. User, client IP, first authentication factor, success or failure reason. | All editions |
STORAGE_USAGE | Daily storage in bytes: active, stage, and fail-safe. Useful for the 7-day fail-safe footprint. | All editions |
ACCESS_HISTORY | Read and write history of tables, views, columns. Used for audit, lineage, and data sensitivity. | Enterprise+ |
The first four are available on Standard Edition. ACCESS_HISTORY is the only one with an edition gate. Two other names worth recognising are TABLE_STORAGE_METRICS and DATABASE_STORAGE_USAGE_HISTORY. They split storage by table or by database respectively.
TABLE_STORAGE_METRICS deserves a second mention. It is the view that retains storage rows for dropped tables, because dropped tables can still incur storage costs while in Time Travel and Fail-safe. The exam tests this directly. DATABASE_STORAGE_USAGE_HISTORY is database-level only and does not split out dropped tables.
Micro-Concept 4: ACCESS_HISTORY and the Enterprise Edition Gate
The ACCESS_HISTORY view records every object touched by every query: tables read, columns selected, views resolved to base tables, objects written. It is the cornerstone of audit and data-lineage workflows on Snowflake.
It is also the only governance view in the must-know set that requires Enterprise Edition or higher. Standard Edition accounts cannot query ACCESS_HISTORY at all. This is one of the few clean edition gates the exam can phrase unambiguously, so it shows up regularly. Day 3 grouped this gate alongside Dynamic Data Masking and Row Access Policies, the other Enterprise-minimum governance features.
Two trap distractors recur. The first claims ACCESS_HISTORY is Business Critical or VPS minimum. It is not. Enterprise is the floor. The second claims it is “real-time” or “queryable from INFORMATION_SCHEMA“. It is neither. It lives in ACCOUNT_USAGE and carries the same latency band as the rest of the schema.
Two related views often appear in the same question family. OBJECT_DEPENDENCIES reports static dependencies declared in DDL. POLICY_REFERENCES reports which masking or row-access policies are attached to which objects. Both are reference views, not historical event logs. Only ACCESS_HISTORY records actual reads and writes.
Micro-Concept 5: Query Attribution History, the C03 Cost Outcome
QUERY_ATTRIBUTION_HISTORY is a newer ACCOUNT_USAGE view released in 2024 and folded into the C03 exam outline. It reports the compute credits consumed by each individual query. C03 added query-level attribution as an explicit cost-management outcome, which is why this view earns its own section here.
The view exposes three attribution dimensions: user, role, and warehouse, with optional tag-based attribution if warehouses or users carry cost-centre tags. The headline column is CREDITS_ATTRIBUTED_COMPUTE, which assigns a weighted share of warehouse credits to one query. Idle time is excluded. Multi-cluster resize cost is included.
The view retains 365 days of history, like the rest of ACCOUNT_USAGE. Latency can run up to 8 hours, because attribution is computed from rolled-up warehouse meter intervals rather than raw query records. Access requires the USAGE_VIEWER or GOVERNANCE_VIEWER database role, or ACCOUNTADMIN.
Two distinctions show up on the exam. QUERY_HISTORY records what a query did, but it does not split warehouse credit cost per query. That gap is exactly what QUERY_ATTRIBUTION_HISTORY closes. WAREHOUSE_METERING_HISTORY reports credits at the warehouse level, hour by hour, but cannot answer the question “which query cost the most credits”. Cost-attribution questions on C03 land on QUERY_ATTRIBUTION_HISTORY. On a production project I worked on for chargeback to business units, this view replaced a fragile workaround. The previous approach joined QUERY_HISTORY to WAREHOUSE_METERING_HISTORY on time windows. The numbers never quite balanced.
Cheat Sheet
| Topic | What to remember | Exam keyword |
|---|---|---|
| Where it lives | SNOWFLAKE.ACCOUNT_USAGE schema, inside the read-only SNOWFLAKE share | “ACCOUNT_USAGE schema” |
| Latency | 45 minutes to 3 hours, varies by view. Never a flat number on the exam | “45 min to 3 hr” |
| Retention | 365 days (1 year) for most views | “1 year” |
| Dropped objects | Included in ACCOUNT_USAGE. Excluded from INFORMATION_SCHEMA | “Includes dropped” |
INFORMATION_SCHEMA retention | 7 days to 6 months by view. Real-time, no dropped objects | “7d to 6 months” |
QUERY_HISTORY | Per-query log: time, warehouse, user, role, bytes scanned. All editions | “Per-query log” |
WAREHOUSE_METERING_HISTORY | Hourly compute and cloud services credits per warehouse | “Hourly credits” |
LOGIN_HISTORY | Authentication events with success / failure reason and client IP | “Login audit” |
STORAGE_USAGE | Daily account-level storage: active, stage, fail-safe | “Account storage” |
TABLE_STORAGE_METRICS | Per-table storage. Keeps rows for dropped tables still in Time Travel / Fail-safe | “Dropped tables storage” |
ACCESS_HISTORY | Read / write log of objects per query. Enterprise+ minimum | “Enterprise gate” |
QUERY_ATTRIBUTION_HISTORY | Compute credits per query, by user / role / warehouse / tag. Up to 8-hour latency | “Credits per query” |
Exam Tip
Domain 2.3 questions on ACCOUNT_USAGE reward two reading habits. Read the time horizon in the stem first. Read the latency requirement second. Most wrong answers fail on one of these two axes.
The “dropped” tell. If the stem contains dropped, deleted, historical, audit, or any time horizon beyond a few weeks, the answer is in ACCOUNT_USAGE. INFORMATION_SCHEMA is the trap when those words appear.
The flat-latency trap. Any option that pins latency to a single number is almost always wrong. The correct phrasing on C03 is the 45-minute to 3-hour range. Pick the range option, not the exact-number option.
The Enterprise gate. ACCESS_HISTORY is the only must-know ACCOUNT_USAGE view with an edition gate. If a Standard Edition account is named in the stem, the access-log option is closed off. The available answer becomes “cannot use ACCESS_HISTORY on this edition”. This is the same pattern as Dynamic Data Masking and Row Access Policies from Day 23.
Cost attribution lands on the new view. A 2024-style C03 stem asks how to attribute warehouse credits to individual queries, users, or tags. The answer is QUERY_ATTRIBUTION_HISTORY, not QUERY_HISTORY and not WAREHOUSE_METERING_HISTORY. Older study materials may not list this view at all. If a candidate has not seen it, this is the question that catches them.
Hands-On Lab
lab_xs warehouse from Day 1, day10_orders table from Day 10. Run as ACCOUNTADMIN.Switch context and warm the warehouse.
USE ROLE ACCOUNTADMIN;
USE WAREHOUSE lab_xs;
USE DATABASE SNOWFLAKE;
USE SCHEMA ACCOUNT_USAGE;
SHOW VIEWS IN SCHEMA SNOWFLAKE.ACCOUNT_USAGE;INSERT or UPDATE attempt against these views fails. Trial accounts may have fewer views populated until they generate some history.Top ten longest-running queries from QUERY_HISTORY.
SELECT
QUERY_TEXT,
TOTAL_ELAPSED_TIME / 1000 AS elapsed_seconds,
WAREHOUSE_NAME,
USER_NAME,
ROLE_NAME,
CREDITS_USED_CLOUD_SERVICES,
BYTES_SCANNED
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME > DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY TOTAL_ELAPSED_TIME DESC
LIMIT 10;SELECT against day10_orders. CREDITS_USED_CLOUD_SERVICES shows the cloud services credit cost per query. Note that QUERY_HISTORY does not report warehouse compute credits per query. That gap is what QUERY_ATTRIBUTION_HISTORY fills in step 3. Latency means queries from the last hour or so may not appear yet.Inspect QUERY_ATTRIBUTION_HISTORY.
SELECT
START_TIME,
USER_NAME,
ROLE_NAME,
WAREHOUSE_NAME,
CREDITS_ATTRIBUTED_COMPUTE,
QUERY_ID
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY
ORDER BY START_TIME DESC
LIMIT 10;CREDITS_ATTRIBUTED_COMPUTE is the weighted share of warehouse credits for that query. Idle time is excluded from this figure. On a brand-new trial, this view may be empty for several hours because of the up-to-8-hour latency. If the view is empty, run the step again after lunch.Audit recent logins from LOGIN_HISTORY.
SELECT
EVENT_TIMESTAMP,
USER_NAME,
CLIENT_IP,
REPORTED_CLIENT_TYPE,
FIRST_AUTHENTICATION_FACTOR,
IS_SUCCESS,
ERROR_MESSAGE
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
ORDER BY EVENT_TIMESTAMP DESC
LIMIT 10;LOGIN_HISTORY is also exposed as a real-time table function in INFORMATION_SCHEMA, with a shorter retention window.Compare INFORMATION_SCHEMA.QUERY_HISTORY head-to-head.
-- Real-time, current-database scope
SELECT COUNT(*) AS rows_realtime
FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY(
END_TIME_RANGE_START => DATEADD('hour', -1, CURRENT_TIMESTAMP())
));
-- ACCOUNT_USAGE, delayed but historical
SELECT COUNT(*) AS rows_account_usage
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME > DATEADD('hour', -1, CURRENT_TIMESTAMP());INFORMATION_SCHEMA table function returns rows immediately. The ACCOUNT_USAGE view trails by tens of minutes. Run the same query again in 2 to 3 hours and the second count catches up. This is the latency band on the exam, demonstrated in your own account.Storage check: confirm day10_orders is still tracked.
SELECT
TABLE_NAME,
TABLE_SCHEMA,
ACTIVE_BYTES,
TIME_TRAVEL_BYTES,
FAILSAFE_BYTES,
DELETED
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE TABLE_NAME ILIKE 'DAY10_ORDERS'
ORDER BY DELETED NULLS FIRST;
-- No cleanup needed. ACCOUNT_USAGE is read-only.
-- day10_orders stays in place per the lab dependency map (used again through Day 39).day10_orders appears with non-zero ACTIVE_BYTES and a DELETED value of NULL, since the table still exists. If you had dropped the table earlier and it was within Time Travel, the same row would show differently. DELETED would carry a timestamp, and TIME_TRAVEL_BYTES or FAILSAFE_BYTES would be non-zero. This is the C03 fact for Q36-style questions on dropped-table storage.Snowflake Documentation
Official docs for today’s topics. The exam pulls directly from these.
External References
Reference pages to reinforce today’s concepts.
Practice Questions
Options:
A. There is no data latency
B. The data latency can vary from 45 minutes to 3 hours
C. The historical data is not retained
D. The historical data can be retained from 7 days to 6 months
E. Records for dropped objects are included in each view
Why B: ACCOUNT_USAGE views are populated from metadata services on a schedule, not in real time. Latency varies by view from roughly 45 minutes up to 3 hours. The official C03 practice item phrases the answer as this range, never a single number.
Why E: Unlike INFORMATION_SCHEMA, the ACCOUNT_USAGE views retain rows for dropped objects. This is the feature that makes them the right choice for historical audit and billing reconciliation questions.
Why not A: Zero-latency is the INFORMATION_SCHEMA property. Picking this trades the schemas.
Why not C: Most ACCOUNT_USAGE views retain 365 days of history. The data is retained.
Why not D: The 7-day to 6-month range describes INFORMATION_SCHEMA retention, not ACCOUNT_USAGE. The two retention numbers are flipped intentionally as a trap.
Options:
A. INFORMATION_SCHEMA.QUERY_HISTORY table function, filtered by the dropped table’s name
B. SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY, joined to ACCESS_HISTORY on QUERY_ID
C. Snowflake Fail-safe, since dropped objects are preserved there for 7 days
D. The Snowsight Query History panel only, since it persists indefinitely
Why B: ACCOUNT_USAGE.QUERY_HISTORY retains 365 days of history and keeps rows even when the referenced table no longer exists. Joining to ACCESS_HISTORY on QUERY_ID reveals exactly which objects each query touched. This is the documented pattern for historical access audits.
Why not A: The INFORMATION_SCHEMA query history function reflects current state and a short retention window. It does not retain references to dropped objects across 90 days.
Why not C: Fail-safe is a 7-day data recovery window managed by Snowflake. It is not user-queryable and does not log queries. Re-read Day 11 if missed.
Why not D: The Snowsight Query History panel is a UI on top of the same views. It does not persist longer than the underlying view retention. The UI itself has its own history caps.
Options:
A. Standard
B. Enterprise
C. Business Critical
D. Virtual Private Snowflake (VPS)
Why B: ACCESS_HISTORY records read and write access to objects per query. The minimum edition is Enterprise. Other governance features in the same family (Dynamic Data Masking, Row Access Policies, Object Tagging, Data Classification) also gate at Enterprise. Re-read Day 3 if missed.
Why not A: Standard Edition does not expose ACCESS_HISTORY at all. This is the most common trap, since the rest of ACCOUNT_USAGE is available on Standard.
Why not C: Business Critical is the floor for HIPAA, Tri-Secret Secure, PrivateLink, and account failover. None of those gate ACCESS_HISTORY. Always pick the lowest edition the feature actually requires.
Why not D: VPS would work, but it is far above the minimum. The keyword to read in the stem is MINIMUM.
Options:
A. QUERY_HISTORY, by summing CREDITS_USED_CLOUD_SERVICES per row
B. WAREHOUSE_METERING_HISTORY, since it reports credits per warehouse per hour
C. QUERY_ATTRIBUTION_HISTORY, which assigns compute credits to each query
D. METERING_DAILY_HISTORY, which rolls up daily account-level credit usage
Why C: QUERY_ATTRIBUTION_HISTORY exposes CREDITS_ATTRIBUTED_COMPUTE, the per-query share of warehouse credits, broken out by user, role, warehouse, and tag. This is the C03 answer for “credits per query” attribution.
Why not A: QUERY_HISTORY reports cloud services credits per query, not warehouse compute credits. Compute credits at the per-query level live in QUERY_ATTRIBUTION_HISTORY.
Why not B: WAREHOUSE_METERING_HISTORY reports credit usage per warehouse, per hour. It cannot tell you which query inside the hour consumed the most.
Why not D: METERING_DAILY_HISTORY rolls up daily usage at the account level. The granularity is wrong for query-level attribution.
Options:
A. DATABASE_STORAGE_USAGE_HISTORY
B. TABLE_STORAGE_METRICS
C. STORAGE_DAILY_HISTORY
D. STAGE_STORAGE_USAGE_HISTORY
Why B: TABLE_STORAGE_METRICS reports per-table storage and retains rows for dropped tables as long as they continue to incur Time Travel or Fail-safe storage. This is the view that supports billing for tables that are gone but still chargeable.
Why not A: DATABASE_STORAGE_USAGE_HISTORY aggregates storage at the database level. It does not break out per-table storage and does not preserve dropped-table detail.
Why not C: STORAGE_DAILY_HISTORY is not a standard ACCOUNT_USAGE view name. The option is fabricated as a distractor.
Why not D: STAGE_STORAGE_USAGE_HISTORY reports stage storage, not table storage.
Today you learned: SNOWFLAKE.ACCOUNT_USAGE is the account-wide historical metadata schema. It carries a latency of 45 minutes to 3 hours, retains 365 days of history, and keeps records for dropped objects. INFORMATION_SCHEMA is the per-database real-time alternative, with shorter retention and no dropped-object history. Five views cover most C03 questions on this schema: QUERY_HISTORY, WAREHOUSE_METERING_HISTORY, LOGIN_HISTORY, STORAGE_USAGE, and ACCESS_HISTORY. The first four are available on Standard Edition. ACCESS_HISTORY is the only one with an edition gate at Enterprise.
The new view in this sub-objective is QUERY_ATTRIBUTION_HISTORY, which reports compute credits per query and attributes them by user, role, warehouse, or tag. It has up to 8 hours of latency and 365 days of retention. Cost-attribution questions on C03 land on this view, not on QUERY_HISTORY and not on WAREHOUSE_METERING_HISTORY. TABLE_STORAGE_METRICS is also worth remembering, since it is the view that retains storage rows for dropped tables still consuming Time Travel or Fail-safe space.
Tomorrow (Day 28): Week 4 Recap and Mixed Quiz. Two files ship together. The review file walks the Week 4 gotchas across resource monitors, encryption and replication, governance policies, data classification, and ACCOUNT_USAGE. It uses the same “Tell:” pattern from Days 7, 14, and 21. The practice test runs 10 questions in real-exam style, mixed across the seven days covered.
