Forum Discussion
Azure SQL Mirrored DB says "metadata tables are corrupted" when stopping then restarting replication
- 1 year ago
I heard back from MS support. TL;DR: you need to grant VIEW PERFORMANCE DEFINITION to the managed identity fabric is using to connect to the db:
GRANT SELECT, ALTER ANY EXTERNAL MIRROR, VIEW PERFORMANCE DEFINITION TO [User];The official docs only mention the need for `SELECT, ALTER ANY EXTERNAL MIRROR`.
This does not fix a database that already has corrupted metadata, but it makes it so that the reproduction steps I mention in the first post do not generate a metadata corruption in the first place.
I believe MS is planning to push a fix for this before the end of the month, but I don't know whether that will be just an update to the documentation or a code fix that makes the "ANY EXTERNAL MIRROR" permission sufficient.
Hi nlucero,
We sincerely regret the inconvenience this issue has caused and appreciate your detailed investigation, especially your valuable workaround using the reconfiguration approach. Given that the metadata corruption resides in the Azure SQL Database and requires a reset beyond standard portal options, we recommend raising a Microsoft support ticket for further assistance. You can create a support ticket using the link below:
https://learn.microsoft.com/en-us/power-bi/support/create-support-ticket
Please include the following details in your ticket to help the support team:
- The full error message (Msg 22710... Cannot enable fabric link on the database because the metadata tables are corrupted).
- The ArtifactId (352bb680-e0cc-4927-85d9-333b0b391c78 from your original post).
- The specific sequence triggering the issue (e.g., compute pause > stop/start replication).
- Your finding that reconfiguration avoids corruption.
If this guidance helps, please “Accept as Solution” and drop a “kudos” to make it easier for other community members to find. We hope this resolves the issue for you.
Thank you.
Just to confirm I have experienced the exact same problem and managed to replicate the scenario using a Fabric Trial. Based on this risk we would not consider talking the technology to production. A simple start and stop of the replication should not have such a high impact on the source. For platform as a managed service this is truly alarming.
My steps were simply to:
1. Stop the fabric mirror
2. Start the fabric mirror
Since it was a Fabric Trial I could find no way to pause the capacity.
DBCC and using DMV's could not identify any problems / corruptions in the source Azure SQL Database. Dynamic Management Views are probably fruitless since the link itself cannot be established.
The exact same error : "Code: SqlChangeFeedError, Type: UserError, Message: Cannot enable fabric link on the database because the metadata tables are corrupted. ArtifactId: e21c6419-bdca-497c-8f00-96ad0c262608"
Destroying the mirror and trying to recreate it from scratch has absolutely no effect on the outcome ... which re-inforces the suspicion that something fundamentally changes in the source database.