Supplies are limited. Contact info@espc.tech right away to save your spot before the conference sells out.
Get your discountScore big with last-minute savings on the final tickets to FabCon Vienna. Secure your discount
How is every1 coping up with the SQL end point lag which is currently killing my prod element.
This is lakehouse snapshot through spark sql after I made a delta merge in the table (through notebook)
(with baked in v order in the same notebook)
and the same table with endpoint
The ingestion_run_at is not being updated at all in the sql endpoint.
Is Microsoft aware of this delay? Are there any official documents that acknowledge this issue or provide a potential solution with a timeline?
At present, the SQL endpoint is unusable for production without this information.
Hi @smpa01 ,
Is my follow-up just to ask if the problem has been solved?
If so, can you accept the correct answer as a solution or share your solution to help other members find it faster?
Thank you very much for your cooperation!
Best Regards,
Yang
Community Support Team
If there is any post helps, then please consider Accept it as the solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!
Hi @smpa01 ,
Is my follow-up just to ask if the problem has been solved?
If so, can you accept the correct answer as a solution or share your solution to help other members find it faster?
Thank you very much for your cooperation!
Best Regards,
Yang
Community Support Team
If there is any post helps, then please consider Accept it as the solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!
Hi @smpa01 ,
Under normal circumstances, the lag time should be less than a minute, and you can refer to the following document for more information:
SQL analytics endpoint performance considerations - Microsoft Fabric | Microsoft Learn
There are several reasons why you get stale data when querying the sql endpoint. If you load data into the table via a notebook, the first query you run on the endpoint will freeze the data for all other queries until it completes. If the initial query runs for a long time, you will get stale data for all subsequent queries.
You can try the workaround mentioned here:
Solved: SQL Endpoint Slow To Reflect Changes In Lakehouse - Microsoft Fabric Community
Between the Sql.Database connector and the AzureStorage.DataLake connector, the latter is generally more accurate as it directly accesses the data in the lakehouse. However, the Sql.Database connector supports fully qualified SQL queries, which might be more convenient for your use case. If accuracy is your priority, AzureStorage.DataLake is the better choice.
Best Regards,
Yang
Community Support Team
If there is any post helps, then please consider Accept it as the solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!
Can you please elaborate with example
"the first query you run on the endpoint will freeze the data for all other queries until it completes. If the initial query runs for a long time, you will get stale data for all subsequent queries"
Are you suggesting that, if different semantic models send out different queries to sql end point at the same time , they could be completely inaccurate due to the condition mentioned above?
Hi @smpa01 ,
If you want to know more, please refer to the 11th reply of this similar case:
Solved: SQL Endpoint Slow To Reflect Changes In Lakehouse - Page 2 - Microsoft Fabric Community
This also provides some workarounds.
Best Regards,
Yang
Community Support Team
If there is any post helps, then please consider Accept it as the solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!
User | Count |
---|---|
4 | |
4 | |
2 | |
2 | |
2 |
User | Count |
---|---|
10 | |
8 | |
6 | |
6 | |
5 |