Task 3.2: Optimize enterprise-scale semantic models

• AGet the latest data in real time with DirectQuery

  Correct

  It adds a DirectQuery partition, so rows after the refresh period are read from the source with every query.

• BTurn on Detect data changes on a LastModified column

  Incorrect

  It skips refreshing unchanged days; it doesn't make today's new rows visible between refreshes.

• CShorten the refresh period to the current day only

  Incorrect

  Today's rows would still appear only when a refresh runs, not within seconds.

• DOnly refresh complete days

  Correct

  This setting is optional unless the real-time DirectQuery option is on, which requires it.

• EAdd a refresh every 30 minutes during business hours

  Incorrect

  More refreshes are ruled out, and data would still be up to 30 minutes old.

An incremental refresh policy can include a real-time DirectQuery partition: all rows with a date and time later than the incremental refresh period are fetched from the source with every model query, so fast-changing data doesn't need a high refresh cadence. This option is supported for Power BI Premium, Premium Per User and Embedded models, requires Only refresh complete days, and can't be combined with nonfolding transformations.

• ARepublish from Power BI Desktop and then refresh only the latest partition

  Incorrect

  Republishing removes the existing partitions and data, so the history would have to be reloaded.

• BDeploy only the metadata changes through the XMLA endpoint, for example with ALM Toolkit

  Correct

  A metadata-only deployment changes the schema while keeping the existing partitions and their data.

• CDownload the model as a .pbix from the service, add the measures and republish it

  Incorrect

  After publishing, a model with incremental refresh can't be downloaded back as a .pbix.

• DAdd the measures in the service's report editor so they're saved to the model

  Incorrect

  Report-level measures in a report don't change the semantic model, so other reports wouldn't get them.

After a model with incremental refresh is published and refreshed, you can't publish the same model again from Power BI Desktop without removing its partitions and data, and you can't download it back as a .pbix. For models in Premium capacities, schema changes can be deployed as metadata only with tools such as the open-source ALM Toolkit or with TMSL through the XMLA endpoint, which retains the partitions and historical data.

• AcommitMode set to partialBatch

  Incorrect

  partialBatch commits each command separately, so a failure can leave the table empty or partly loaded.

• BAn objects array that lists the Inventory table

  Correct

  objects limits processing to the listed tables or partitions; without it, the whole model refreshes.

• CcommitMode set to transactional

  Correct

  Transactional commits the objects only when the whole operation completes, so a failure keeps the earlier data.

• Dtype set to clearValues

  Incorrect

  clearValues removes the table's data instead of reloading it.

• EapplyRefreshPolicy set to true together with commitMode partialBatch

  Incorrect

  With partialBatch, applyRefreshPolicy must be false, and partialBatch doesn't protect the earlier data anyway.

The enhanced refresh REST API, available for models in Premium, Premium Per User and Embedded, accepts an objects array of tables or partitions to process; with no objects, the whole model refreshes. commitMode transactional commits the objects only when the operation is complete, keeping the earlier data on failure, while partialBatch commits each command individually and can leave the model empty or with a subset of data. Types align with TMSL refresh types such as full, clearValues, calculate and dataOnly.

• AAs COALESCE([Sales], 0)

  Incorrect

  It still converts BLANK to zero, so every customer keeps a value and the visual stays dense.

• BAs [Sales] itself, returning BLANK when there are no sales

  Correct

  Visuals drop groupings whose measures are BLANK, so only customers with sales are retrieved and shown.

• CAs IF([Sales] > 0, [Sales], 0)

  Incorrect

  It still returns zero for customers without sales, so every customer keeps a value.

• DAs IF([Sales] = 0, BLANK(), [Sales]), with Show items with no data turned on

  Incorrect

  Show items with no data makes the visual display every grouping again, including customers without sales.

Measures that turn BLANK into zero turn a sparse calculation into a dense one: Power BI tries to retrieve every grouping in the filter context, which leads to slow rendering and too many rows. DAX guidance recommends that measures return BLANK when a meaningful value can't be returned, because visuals eliminate groupings whose summarizations are BLANK. Show items with no data displays all groupings again.

• AALM Toolkit

  Incorrect

  ALM Toolkit compares model schemas; it doesn't trace query execution.

• BMetadata Translator

  Incorrect

  Metadata Translator translates captions, descriptions and display folders.

• CPower BI Report Builder

  Incorrect

  Report Builder authors paginated reports; it doesn't break down DAX query execution.

• DDAX Studio

  Correct

  DAX Studio is built for DAX authoring, diagnosis and performance tuning, with integrated tracing and query execution breakdowns.

The External Tools ribbon passes the server, port and model name of Power BI Desktop's Analysis Services instance to registered tools. DAX Studio is a tool for DAX authoring, diagnosis, performance tuning and analysis, with object browsing, integrated tracing and query execution breakdowns with detailed statistics. ALM Toolkit compares schemas, and Metadata Translator handles translations.

• AA training operation followed by a refresh

  Incorrect

  Only the first scheduled refresh of the day, at 04:00, includes training.

• BA refresh that updates the existing aggregations

  Correct

  The day's later scheduled refreshes are refresh-only operations that update the aggregations data in the cache.

• CA training operation, with its data loaded at 14:00

  Incorrect

  Training runs with the first refresh of the day, and its data loads in the refresh operation that follows it.

• DNothing, because training replaces the later refreshes

  Incorrect

  Scheduled refreshes keep running; training is added only to the first one for the chosen frequency.

With automatic aggregations, the first scheduled refresh for the chosen frequency, Day or Week, starts with a training operation that evaluates the query log and creates, updates or drops aggregation tables; the aggregations data is loaded by the refresh operation that follows. The other scheduled refreshes of that day are refresh-only operations that update the existing aggregations in the in-memory cache. Train and Refresh Now triggers both operations on demand.

• AThe script must send POST with "cancel": true to the refresh object instead

  Incorrect

  Enhanced refresh cancellation uses DELETE on the refresh object.

• BOnly refreshes with commitMode partialBatch can be canceled

  Incorrect

  Cancellation doesn't depend on the commit mode.

• CDELETE can't cancel a refresh started from the portal button

  Correct

  The cancel operation works on enhanced refreshes; portal-triggered and scheduled refreshes can't be canceled that way.

• DThe operator must first pause the refresh in the service

  Incorrect

  There's no pause step; portal-started refreshes aren't cancelable through this API.

The enhanced refresh REST API supports refresh cancellation: send DELETE to the refresh object with its requestId to cancel an in-progress enhanced refresh. Scheduled or on-demand model refreshes that were triggered from the portal's refresh button can't be canceled by using DELETE /refreshes/<requestId>.

• ALarge semantic model storage format

  Correct

  The large storage format is required for semantic models to grow beyond 10 GB.

• BScale-out queries for large semantic models

  Incorrect

  Scale-out adds read-only replicas for query load; it doesn't raise the size limit.

• CAutomatic aggregations

  Incorrect

  Automatic aggregations cache aggregated data for DirectQuery queries; they don't raise the model size limit.

• DXMLA endpoint read-write

  Incorrect

  Read-write enables XMLA write operations; it doesn't lift the model size limit.

Semantic models have a default size limit, and with Fabric capacities they can exceed it when the Large semantic model storage format setting is enabled, up to the capacity's size or a limit set by the capacity administrator. The large format is required for models to grow beyond 10 GB, and it can also improve XMLA write performance. Power BI Desktop uploads remain limited to 10 GB; models grow beyond that in the service on refresh.

• AThe scheduled refresh settings of each model on that capacity

  Incorrect

  They set one model's own refresh times; they don't show the other refreshes that share a slot.

• BThe refresh history of each model in its settings

  Incorrect

  It lists one model's refresh attempts, not the capacity's schedule across models.

• CThe History view of the refresh summary page

  Incorrect

  History shows the outcomes of recent scheduled refreshes, not how the week's slots are booked.

• DThe Schedule view of the admin portal's refresh summary page

  Correct

  It splits the week into 30-minute slots and shows booked and available refresh minutes, including refreshes that overflow into the next slot.

The refresh summary page in the admin portal gives insight into refresh schedules, capacities and potential schedule overlaps for Premium capacities. Its History view shows the outcomes of recent scheduled refreshes, based on up to 60 records for each, and can be exported to a .csv file. Its Schedule view splits the week into 30-minute time slots with the refresh time booked, from the average durations of refreshes that start in or overflow into the slot, and the refresh time still available.