Forum Discussion
DirectLake on OL w/Import : Database consistency checks (DBCC) failed while checking the segment
I keep getting a random error, when refreshing a directlake partition in SSMS.
Database consistency checks (DBCC) failed while checking the segment statistics.
Technical Details:
RootActivityId: db14b55e-18ff-475b-a9a6-819399000263
Date (UTC): 6/23/2025 5:38:59 PM
Database consistency checks (DBCC) failed while checking the '<oii>REDIM02 StandardFiscalDate (6755)</oii>' column.
Database consistency checks (DBCC) failed while checking the '<oii>Hidden Cardex Activity (6745)</oii>' table.
Database consistency checks (DBCC) failed while checking the '2dc8be52-94ae-4f6a-9ac0-25f0fa264830' database.
Database consistency checks (DBCC) failed while checking the '' table.
An error occurred while attempting to save the dataset (reference ID '2dc8be52-94ae-4f6a-9ac0-25f0fa264830').
Run complete
The model has import tables as well as DirectLake tables (on onelake)
The data is coming from a very simple DeltaTable in a very simple lakehouse. There is no data movement whatsoever.
It is possible that it only happens the very first time I refresh a partition, then never happens again for the same model. But my workflow involves redeploying the model, so it seems like this happens to me all the time.
Any tips would be appreciated. Here is the SSMS error (image)
Hi dbeavon3,
Thank you for the response, I completely understand the need to look under the hood. Unfortunately currently there is no direct or supported way to inspect the segment statistics used by DBCC in DirectLake models.
Unlike imported models, where other tools like VertiPaq Analyzer or DAX Studio can expose segment and storage metadata but the DirectLake models do not yet expose this internal engine state, especially since the data remains external (like Delta Lake files in OneLake) and has not materialized in memory unless queried.
If you are consistently hitting this issue on a specific table or structure, I recommend raising a support ticket with the full DBCC error details and the timestamp.
If this post helps, then please consider Accepting as solution to help the other members find it more quickly, don't forget to give a "Kudos" – I’d truly appreciate it!
Thanks and regards,
Anjan Kumar Chippa
9 Replies
Hi dbeavon3,
Thank you for reaching out to Microsoft Fabric Community.
This issue likely happens because, the segment statistics validation fails during the first DirectLake partition refresh due to metadata not being fully cached immediately after the model deployment.
So I recommend adding a small basic warm up query before the refresh. And since it happens immediately after deployment, add a 2–5 minute delay after model deployment before running partition refresh. And also add retry logic in the refresh workflow, as the issue often resolves after the first retry.
If this post helps, then please consider Accepting as solution to help the other members find it more quickly, don't forget to give a "Kudos" – I’d truly appreciate it!
Thanks and regards,
Anjan Kumar Chippa
This is DirectLake on OneLake, and there should be no "cache" or "sql endpoint".
The explanation doesn't make sense, given the fact that the components you are referring to don't exist. My understanding is that during a refresh, the semantic model isn't doing more than gatering the metadata (just finding the parquet files in the DeltaTable, along with their logs.) There should be no other cache than the one it is trying to build for its own purposes. There are no other services involved either (like sql endpoint)Hi dbeavon3,
Since no external components are involved, the issue here is likely from a timing mismatch between model deployment and the internal metadata readiness within the engine.
Adding retry logic works because the failure typically does not occur on subsequent attempts, once the engine has fully established its view of the Delta structure.If this post helps, then please consider Accepting as solution to help the other members find it more quickly, don't forget to give a "Kudos" – I’d truly appreciate it!
Thanks and regards,
Anjan Kumar Chippa
