Azure SQL Database
An Azure relational database service.
Azure SQL Database Query Performance, misleading as it includes primary and standby data
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(160, 52%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ENW%3C/text%3E%3C/svg%3E)
Nancy Wotawa
0
Reputation points
Query Performance is including information for primary and secondary (note this is a business critical read-only replica, not a geo). Take a query ID provided, go to query store, it shows on Secondary, not Primary. This gives misleading information as it is reporting high consuming queries that are not running on this DB, they're actually running on the secondary. I'm betting this was introduced with this enhancement "https://techcommunity.microsoft.com/blog/azuredbsupport/read-only-queries-are-now-captured-in-the-primary-query-store-/4485048" in January. Why isn't there an option to select Primary/Secondary? What is this doing to automation? If it's including queries from the secondary, then making changes on primary based on this, could be very bad. Some cases could be good. Either way, it's misleading and I'd argue wrong. The page is labeled for the primary, no other metrics are for the secondary but this one buries information for the secondary in it.
Azure SQL Database
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 24%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPP%3C/text%3E%3C/svg%3E)
Pilladi Padma Sai Manisha 6,580 Reputation points Microsoft External Staff Moderator2026-04-09T15:54:27.4033333+00:00 Hi Nancy Wotawa,
Thank you for calling this out, your observation is absolutely valid, and I understand why this feels misleading when you’re looking at Query Performance from the Primary perspective.What you’re seeing is tied to the recent enhancement where read-only queries executed on replicas are now captured in the Primary Query Store. Because of this change, Query Store on the Primary is no longer limited to just Primary-executed workload , it can also include queries coming from the read-only replica.
In a Business Critical configuration, where read traffic is intentionally routed to the secondary, this can surface queries in the Primary Query Performance view that never actually ran on the Primary. At the moment, the UX does not clearly distinguish between Primary and Secondary execution, nor does it provide a filter to separate them. That’s why it appears as though high resource queries are impacting the Primary when they are in fact running on the replica.
From a support standpoint, this is currently expected behavior, but we agree it introduces ambiguity when interpreting performance data. Because of this, we recommend validating the execution context of top queries before taking any tuning actions. This can be done by correlating with connection intent (read-only routing) or using DMVs to confirm where the workload is originating from.
You also raised an important point around automation — any process that relies on Query Store data (for example, automatic tuning or plan forcing) should take this behavior into account, since decisions made solely on aggregated data could target the wrong workload.
There is a clear gap here in terms of visibility and control. Having the ability to distinguish or filter queries by Primary vs Secondary would make this feature much more usable, especially for read-scale scenarios like yours. I’ll make sure this feedback is captured and shared with the product team.
Please let me know if you’d like help with queries/DMVs to differentiate workloads, happy to assist further.
Sign in to comment
Sign in to answer