Data Retention¶
Reference for how long the MetaMiner Database (MMDB) keeps Power BI activity, capacity metrics, deleted objects and dashboard rollups, and which jobs remove older data.
How it works¶
Current inventory (workspaces, items, semantic models, users, groups) is kept as long as it exists in the tenant. Historical and high-volume data is removed by scheduled jobs in the MetaMiner Server (MMS). The jobs run only when at least one Power BI environment is enabled.
Weekly retention jobs¶
The jobs run every Sunday, in server time, one after another.
| Time | Job | What it removes | Default | Property |
|---|---|---|---|---|
| 03:00 | Orphan cleanup | Data sources no longer used by any semantic model, dataflow or item, refresh history of semantic models that no longer exist, and similar orphans, once unchanged for the period. Rows are moved to an archive table, then deleted. | 180 days | pbi.orphan.cleanup.retention.days |
| 04:00 | Deleted data retention | Rows in the archive table older than the period | 180 days | pbi.deleted.data.retention.days |
| 08:00 | Activity events retention | Activity events older than the period, in batches | 104 weeks (about 2 years) | pbi.activity.events.retention.period |
| 09:00 | Capacity metrics retention | Fabric Capacity Metrics detail, item, operation-hour and storage rows older than the period, and capacities removed earlier | 26 weeks (about 6 months) | pbi.fcm.retention.period |
Microsoft's own limits
Microsoft returns activity events for about the last 30 days, and the Capacity Metrics app holds a limited window. Data older than that exists only in the MMDB. Shortening a period deletes that history for good.
Change a retention period
Add the property to server\MetaMinerServer.properties, for example:
Restart the server. The batch sizes pbi.activity.events.retention.batch.size and pbi.fcm.retention.batch.size (default 50000) control how many rows each step deletes; change them only on advice from Infolytik Support.
Dashboard rollups¶
Three scheduled jobs compute the silver tables that the Power BI usage dashboards read. They run on all Power BI environments together and keep their own history.
| Job | Schedule | Produces | Kept |
|---|---|---|---|
pbi-usage-rollup |
Every 5 minutes | Hourly and daily activity and refresh facts | 180 days |
fcm-capacity-rollup |
Every 5 minutes | Hourly capacity usage per capacity | 180 days |
pbi-license-waste |
Every 6 hours | User population, last activity per user, daily license-waste snapshots | Snapshots: 400 days |
The rollups are recomputed incrementally from the pbi tables. A dashboard can show at most the history that both the rollup and the underlying pbi data still hold; for example capacity history is limited by the 26-week capacity metrics retention.
The job definitions are in server\silver-jobs\. Change their parameters only with Infolytik Support; MMA's Web Apps page writes the user group parameter for you.
Do not turn off the dashboard jobs
silver.jobs.enable=false in MetaMinerServer.properties stops all three jobs. The dashboards then show "preparing" or "not primed" states instead of figures. See Data Freshness.
Other data with its own retention¶
| Data | Where retention is set |
|---|---|
| Power BI backup archives | On each backup job; see How Backup Works |
| Server logs | Fixed per log file; see Log Files |
| Health incident files | 90 days; see Server Health Indicator |