Access history and audit logging in Snowflake - Time & Space Complexity
When we check access history and audit logs in Snowflake, we want to know how long it takes to get results as the amount of data grows.
We ask: How does the time to fetch logs change when there are more records?
Analyze the time complexity of the following code snippet.
SELECT event_time, user_name, action
FROM snowflake.account_usage.access_history
WHERE event_time > DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY event_time DESC
LIMIT 1000;
This query fetches the last 1000 access events from the past week, ordered by time.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Scanning the access_history table for events in the last 7 days.
- How many times: The database scans all matching rows for the 7-day period before sorting and limiting results.
As the number of access events in the last 7 days grows, the scan and sort take longer.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 rows scanned and sorted |
| 100 | About 100 rows scanned and sorted |
| 1000 | About 1000 rows scanned and sorted |
Pattern observation: The work grows roughly in direct proportion to the number of rows scanned before limiting.
Time Complexity: O(n log n)
This means the time grows a bit faster than the number of rows because sorting takes extra steps.
[X] Wrong: "Fetching audit logs always takes the same time no matter how many records there are."
[OK] Correct: The database must scan and sort all matching rows, so more records mean more work and longer time.
Understanding how log queries scale helps you design better monitoring and troubleshooting tools in real projects.
"What if we added a clustering key on event_time? How would the time complexity change?"
Practice
ACCESS_HISTORY view in Snowflake primarily provide?Solution
Step 1: Understand the purpose of ACCESS_HISTORY
The ACCESS_HISTORY view records user activity related to data access in Snowflake.Step 2: Identify what ACCESS_HISTORY tracks
It tracks who accessed what data and when, useful for audit and compliance.Final Answer:
Information about who accessed data and when -> Option AQuick Check:
ACCESS_HISTORY = Data access logs [OK]
- Confusing ACCESS_HISTORY with billing or performance views
- Thinking it shows database structure
- Assuming it tracks query performance
Solution
Step 1: Understand date filtering in Snowflake SQL
To get records from the last 7 days, filter where ACCESS_TIME is greater than current date minus 7 days.Step 2: Check each option's date condition
SELECT * FROM ACCESS_HISTORY WHERE ACCESS_TIME > CURRENT_DATE - 7; correctly uses ACCESS_TIME > CURRENT_DATE - 7 to get recent records.Final Answer:
SELECT * FROM ACCESS_HISTORY WHERE ACCESS_TIME > CURRENT_DATE - 7; -> Option CQuick Check:
Date filter for last 7 days = SELECT * FROM ACCESS_HISTORY WHERE ACCESS_TIME > CURRENT_DATE - 7; [OK]
- Using < instead of > for recent dates
- Using = which matches only one day
- Using BETWEEN with future dates incorrectly
SELECT USER_NAME, COUNT(*) AS ACCESS_COUNT FROM ACCESS_HISTORY WHERE OBJECT_NAME = 'CUSTOMERS' GROUP BY USER_NAME ORDER BY ACCESS_COUNT DESC LIMIT 3;
Solution
Step 1: Analyze the query components
The query counts accesses per user filtered by OBJECT_NAME = 'CUSTOMERS'.Step 2: Understand GROUP BY and ORDER BY
It groups by USER_NAME, orders by count descending, and limits to top 3 users.Final Answer:
Top 3 users who accessed the CUSTOMERS object most frequently -> Option DQuick Check:
GROUP BY USER_NAME with LIMIT 3 = Top 3 users who accessed the CUSTOMERS object most frequently [OK]
- Thinking it lists all users without limit
- Assuming OBJECT_NAME is invalid
- Confusing total accesses with per-user counts
SELECT * FROM ACCESS_HISTORY WHERE USER = 'JOHN';What is the likely cause and fix?
Solution
Step 1: Check column names in ACCESS_HISTORY
The correct column for user is USER_NAME, not USER.Step 2: Correct the query column name
Replace USER with USER_NAME to fix the error.Final Answer:
Column USER does not exist; use USER_NAME instead -> Option AQuick Check:
Use USER_NAME column, not USER [OK]
- Using USER instead of USER_NAME
- Assuming missing semicolon causes error
- Thinking ACCESS_HISTORY is inaccessible
Solution
Step 1: Identify correct column names and filters
ACCESS_HISTORY uses OBJECT_NAME for table, ACCESS_TYPE for operation, and ACCESS_TIME for timestamp.Step 2: Check filter conditions for SELECT and last 30 days
SELECT QUERY_TEXT, USER_NAME, ACCESS_TIME FROM ACCESS_HISTORY WHERE OBJECT_NAME = 'SALES' AND ACCESS_TYPE = 'SELECT' AND ACCESS_TIME > CURRENT_DATE - 30; filters OBJECT_NAME = 'SALES', ACCESS_TYPE = 'SELECT', and ACCESS_TIME > CURRENT_DATE - 30 correctly.Final Answer:
SELECT QUERY_TEXT, USER_NAME, ACCESS_TIME FROM ACCESS_HISTORY WHERE OBJECT_NAME = 'SALES' AND ACCESS_TYPE = 'SELECT' AND ACCESS_TIME > CURRENT_DATE - 30; -> Option BQuick Check:
Correct columns and filters = SELECT QUERY_TEXT, USER_NAME, ACCESS_TIME FROM ACCESS_HISTORY WHERE OBJECT_NAME = 'SALES' AND ACCESS_TYPE = 'SELECT' AND ACCESS_TIME > CURRENT_DATE - 30; [OK]
- Using TABLE_NAME or QUERY_TYPE which don't exist
- Filtering for INSERT instead of SELECT
- Using ACCESS_TIME < CURRENT_DATE - 30 (old data)
Ready to prove it?
Pass the test and this pattern moves unknown
