Data Connectivity and Caching
Data Connectivity and Caching
This domain tests how MicroStrategy reaches data and when it can avoid re-querying: connection types, Intelligence Server caches, and cube options. Expect scenario questions on slow reports, stale data, and cache reuse.
Core rules
- The Intelligence Server connects through gateways and drivers to warehouses; queries are generated as SQL and pushed down where possible.
- Caches include result/report caches and dataset/cube caches. A cache hit requires a compatible report definition, security context, warehouse, and VLDB settings.
- Row-level security changes the security context, so two users may not share a cache entry.
- Intelligent Cubes are in-memory datasets for fast, high-concurrency access; they must be refreshed and governed.
- Cache invalidation can be manual or scheduled; stale caches are a governance issue, not just a performance issue.
Worked example
A dashboard is fast for an analyst but slow for a regional manager. Both run the same report; the manager has a row-level security filter. The analyst's cached result is not reusable because the security context differs. Fix: verify cache matching and consider a cube partitioned or secured appropriately, not simply increasing cache size. Reason: cache keys include the user and security context.
Traps
- Assuming any second run is a cache hit.
- Treating a cube as always current.
- Tuning SQL before checking whether a cache or cube exists.
- Ignoring VLDB settings that change query text and cache compatibility.