Data Connectivity, Warehouses, and Caching
Data Connectivity, Warehouses, and Caching
This domain covers how MicroStrategy reaches a warehouse and when it reuses results. Expect questions on database instances, schema and catalog updates, Intelligent Cubes, and the cache layers.
Core rules
- A database instance holds connection details (DSN or driver, server, login). A project maps users and groups to an instance; the default instance applies when no mapping matches.
- The warehouse catalog stores table and column definitions. Renames or new columns require a catalog/schema update before the SQL engine can use them.
- VLDB properties tune generated SQL (joins, temp tables, pre/post statements) and can be set at project, report, or user level.
- Caching is layered: report/result cache stores a report result set; element cache stores attribute elements; schema cache stores metadata; Intelligent Cubes are published in-memory datasets with refresh schedules and partitioning.
- A cache key typically includes the report definition, prompt answers, security filter, database instance, and VLDB settings. Change any of these and you get a different entry.
Worked example
A nightly ETL loads yesterday's sales, but a dashboard still shows the day before. The dashboard is not broken: its report cache entry is still valid. Checking the report cache settings shows it is set to use cached results until the cube refresh. The fix is to refresh or reschedule the Intelligent Cube, or set the report to always refresh for that certification cycle. Reasoning: a cache hit never touches the warehouse, so fresh warehouse data is irrelevant until the key changes or the cache is invalidated.
Traps that cost marks
- Assuming a schema change is picked up without a catalog update.
- Confusing Intelligent Cube refresh with report cache invalidation.
- Forgetting that security filters are part of the cache key.
- Expecting direct data access or Freeform SQL results to be cached like a normal report.