topic Re: Warehouse cannot be opened due to inaccessible files or insufficient memory or disk space in Data Warehouse

Warehouse cannot be opened due to inaccessible files or insufficient memory or disk space

jacarmonaro — Thu, 05 Mar 2026 01:10:35 GMT

Today, we saw a lot of our pipelines showing this error message:

Message = Database 'xxxxxxxxxx' cannot be opened due to inaccessible files or insufficient memory or disk space.

Basically, we were refreshing the tables in the fabric warehouse at night when we started getting these messages. We also observed that the warehouse was showing this "Recovery Pending" message:

We reviewed the Fabric Capacity metrics app and observed that the workspace reached 6 TB (unfortunately, the app does not show the size of each object inside the workspace).

We use the P1 capacity, which is supposed to allocate up to 100TB of data, so we don't know what is wrong with this. In that same workspace, we also have a couple of lakehouses ingesting daily data, and those were ok.

We have different theories here:

1. We don't really have 6TB of data. We delete tables every 6 hours and recreate them with new records. We believe the real warehouse size should be around 500GB.

2. We believe the automatic System-created restore points, are duplicating the size of the warehouse to the level of reaching 6TB. (I know the documentation says that it is just the metadata, but because we are deleting the table and recreating again from scratch, I believe the data for the recovery needs to live somewhere.)

3. We can't delete those system-created restore points, and we can't adjust the settings to reduce the number of times per day or the number of days we want to keep them.

The fabric warehouse has been in that Recovery Pending state for almost 24 hours, and I don't know what to do. I would buy more storage, but that is not possible because it is part of the overall SaaS solution. I also believe this is a warehouse issue, since the lakehouses in the same workspace are fine.

Any ideas? Has anyone faced this situation?

Re: Warehouse cannot be opened due to inaccessible files or insufficient memory or disk space

v-saisrao-msft — Thu, 05 Mar 2026 09:35:46 GMT

Hi jacarmonaro,

This process replaces the current warehouse with a version from an earlier restore point, allowing you to return to a known working state. Fabric automatically creates system-generated restore points every eight hours, and these are kept for 30 days. The restore points save only the metadata and reference the Parquet data files in OneLake for recovery. If any problems arise, you can use a restore point to recover the warehouse to an earlier state.

It is recommended to open a Microsoft support ticket so the backend engineer team can investigate the warehouse state and backend logs.

Create a Fabric and Power BI Support Ticket - Power BI | Microsoft Learn

Restore In-Place of a Warehouse from a Restore Point - Microsoft Fabric | Microsoft Learn

Thank you.

Re: Warehouse cannot be opened due to inaccessible files or insufficient memory or disk space

Gautam_Kumar01 — Thu, 16 Jul 2026 03:07:11 GMT

Hi jacarmonaro

I’ve seen this exact issue with Fabric Warehouse when there’s heavy DDL churn + auto restore points.

Here are 3 things to check/do right away:

1. The "6TB" is likely Restore Points + Version History

Even though you delete/recreate tables every 6 hours, Fabric Warehouse keeps transaction log + restore points for PITR. With DDL every 6 hours, each version gets stored. That’s why Capacity Metrics shows 6TB but your real data is 500GB.

Check: `SELECT * FROM sys.dm_pdw_nodes_db_file_space_usage` if accessible.

2. Quick Fix to get Warehouse online

Since it's stuck in "Recovery Pending", the fastest way is what v-saisrao-msft mentioned

Restore the warehouse to the latest healthy restore point from 24-48 hours ago.

Go to: Workspace > Warehouse > ... > Restore

This will roll back the log and free up the stuck state. You may lose 1-2 pipeline runs but warehouse will come up.

3. Long term prevention

- Instead of DROP/CREATE tables, use `TRUNCATE + INSERT` or `MERGE`. This avoids creating new objects for every restore point.

- Check if you can reduce restore point retention. Open a support ticket - MS can sometimes lower it from backend for P1.

- Monitor with Fabric Capacity Metrics app > "Storage" tab. Watch "Versioned Storage".

Your theory #2 is 100% correct. Lakehouses are fine because they use Delta log, not transactional log like Warehouse.

Has the restore worked for you? Also open a Fabric support ticket with `Severity B` - MS can clear old ghost restore points manually.

Hope this helps!