Question
You have a Fabric F32 capacity that contains a workspace. The workspace contains a warehouse named DW1 that is modelled by using MD5 hash surrogate keys.
DW1 contains a single fact table that has grown from 200 million rows to 500 million rows during the past year.
You have Microsoft Power BI reports that are based on Direct Lake. The reports show year-over-year values.
Users report that the performance of some of the reports has degraded over time and some visuals show errors.
You need to resolve the performance issues. The solution must meet the following requirements:
- Provide the best query performance.
- Minimize operational costs.
What should you do?
- A. Change the MD5 hash to SHA256.
- B. Increase the capacity. Correct
- C. Enable V-Order.
- D. Modify the surrogate keys to use a different data type.
- E. Create views.
Explanation
Direct Lake guardrails depend on the capacity SKU. On F32 a table can have at most 300 million rows, and the fact table now has 500 million. When a guardrail is exceeded, Direct Lake on SQL falls back to DirectQuery, which is slower, and Direct Lake on OneLake can't query the model, so visuals return errors. That explains both the gradual slowdown and the failing visuals. F64 is the smallest SKU that allows 1.5 billion rows per table, so scaling the capacity up is the only option that brings the table back within the limit. V-Order is already on by default in a Fabric warehouse, so enabling it changes nothing. Changing the hash algorithm or the key data type doesn't reduce the number of rows. Views force DirectQuery fallback, which makes performance worse.
