@stephenjust
感谢您的反馈意见。 我们正在积极研究此问题，并将尽快与您联系。

@stephenjust对不起，
下面是相同的屏幕截图。

请确认这是否是您的关注点。 或者如果我无法理解您的问题，请详细说明。

@ angoyal-MSFT我相信@stephenjust在谈论溢价/业务层Azure的SQL数据库的“读向外扩展”功能，这是在“设置”中找到>在Azure的门户网站“配置”时，选择了SQL数据库。 使用该功能时，我不知道有什么方法可以查看已读取从站的指标。

@ColeShepherdAG是正确的，我说的是启用读取横向扩展时从只读副本获取指标。

我们观察到的是，在门户网站中，统计信息仅在写入主服务器上可见。 如果设置ApplicationIntent = ReadOnly，则不会在Azure门户中观察到来自那些查询的任何资源消耗。

@stephenjust同时，一个（有限的）解决方法是在使用ApplicationIntent=ReadOnly连接到数据库时，定期从sys.dm_db_resource_stats中进行选择。

现在，我们将关闭该线程。 如果对此问题还有其他疑问，请发表评论，我们将继续讨论。

@ angoyal-msft我认为我们应该在线程关闭之前得到对我们最新评论的回应...

您是否已确认仅使用高级/业务层Azure SQL数据库的“读取横向扩展”功能创建的数据库（不包括主要的读/写数据库）没有度量标准？ 如果是这样，是否有计划将这些指标添加到Azure门户？ 你能在大约至少添加信息sys.dm_db_resource_stats表和ApplicationIntent=ReadOnly以这篇文章为其他读者？

@ColeShepherdAG感谢您的有用建议。
@ anosov1960您能否在文档中添加所需的信息。

对只读副本和指标进行轮询将极大地提高性能。 请添加。

我也想在这里投入2美分，以了解只读副本的指标。 我很乐意将此功能用作节省成本的功能，但目前无法做到这一点。 我们依靠指标和Azure SQL Analytics来获取警报和每日统计信息。 现在，我看不到如何在不了解其性能的情况下实现该功能。

您可以获取指标，只是不通过门户网站提供这些指标，并且随附所有典型的钟声（例如警报等）。 我一直在考虑建立自己的一些监视工具，因为Azure提供的功能还是不够的（例如在应用程序/程序级别查看相对DTU的利用率）。 如果您的监视工具使用ApplicationIntent=ReadOnly参数连接，则可以执行sp_who2或其他SP，以查看特定于副本的信息。 然后，自动调用该SP，收集结果并显示。 我正在为此添加一些监视： https :

我正在为此添加一些监视： https :
如何解决缺少SQL Agent的问题？

我仍在调查中，但是据我了解，您只需要定期调用一些存储的proc。 如果是这样，可以通过许多不同的方式来实现自动化。 从一台计算机上的脚本到Azure自动化以及介于两者之间的许多内容。

@ angoyal-msft由于此问题无法解决，请您重新打开该问题？ 仍然没有办法通过Azure门户从横向扩展的只读副本中获取指标。

绝对需要。 我不想依靠变通方法来实现诸如监视之类的重要功能。
度量标准也应可用于读取横向扩展数据库副本。

@ejjpi我们已重新打开此问题并分配给我们的作者。
@ anosov1960请检查此问题并提供指导。

@ NavtejSaini-MSFT有关此问题的任何更新？ 甚至我们也无法使用监控API查询SQL只读副本的指标。

@ angoyal-msft，对此有任何更新吗？ 这是我们需要尽快解决的主要问题。

您是否打算在主dtu_used指标中包括读取的横向扩展数据库副本指标，或者至少为副本添加一个单独的副本（后者实际上可能更有用）？ 我们希望继续利用Azure提供的指标并使用副本。

我们不想在不知不觉中耗尽DTU。

我认为此仓库将无法正确解决此问题：这不是有关文档的缺失部分，而是有关Azure门户缺少关键的监视功能。
Microsoft的任何人都可以将这个问题转移/升级到适当的地区/团队吗？

我已经升级到拥有Azure SQL-Azure Portal集成的团队。

@stephenjust对此有任何更新吗？

重新分配：julieMSFT

@ Nikos-K @stephenjust感谢您与Microsoft联系！ 据我了解，您所描述的问题似乎与产品有关，对吗？ 如果是这样，很遗憾，这种联系方式是专门用于报告文档问题，而不是产品。 为了获得有关您的问题的进一步帮助，我们建议您与社区互动，或者通过Microsoft支持部门来打开票证。 可以在这里找到更多信息： https :

如果您希望提供有关产品改进的建议或想法，请访问https://aka.ms/sqlfeedback。

我现在正在关闭此问题24239。即使需要关闭某个项目，在需要进一步通信的情况下，@通知机制仍可以继续工作。

请关闭

每个人都同意这是与此处讨论的内容相关的正确产品问题吗？
https://feedback.azure.com/forums/908035-sql-server/suggestions/32899126-enable-query-store-for-collection-on-a-read-only-r

（如果是这样，请同时赞扬该UserVoice建议和此评论）

@JeremyWeir虽然您链接的问题与此问题相关，但它们似乎不是同一问题。 据我了解，这里的问题集中在公开读取的横向扩展副本的指标上，这些指标随后可以像其他任何Azure指标一样使用（即：构建图表，创建自动警报等），与之相关但又与之不同。为只读副本启用查询存储。 就是说，我已经离开并支持您的问题，因为这对我来说同等重要。

<rant>我也很失望，这个问题再次被关闭，只是说“这不是文档问题，这是产品问题”，却没有主动将问题转发给Microsoft内部的相应产品团队，然后通知此线程我们如何跟踪该新问题。 我在Microsoft工作了14年，然后在4年前离开，开始了自己的公司。我非常高兴地看到最近向开放式开发流程的转变，该流程使客户可以直接调试问题，提供反馈和跟踪进度他们关心的问题，我对常规问题被视为“不是我关注的领域”而感到失望。 对于任何想要利用读取-从属副本的人来说，此问题都极为重要，这是Azure SQL最顶层，最昂贵的选件的主要销售功能。 这里显示的对客户缺乏同理心使人感到沮丧。</ rant>

@kroymann好点了，我想我是假设查询存储是我们为Azure SQL数据库提供的指标的动力，但是，不管是不是事实，我们可以在查询存储之外获得的任何指标都会会有所帮助。

@JeremyWeir @kroymann我们正在学习如何最好地管理这个较新的频道。 最初的意图和今天仍然要使用的意图是解决与文档相关的主题，包括需要进行的增强和更正。 这还应该包括文档和产品不一致的问题。 随着特定产品随时间的发展或进行更改（例如以门户网站为例），以及需要对文档进行更正的地方，该渠道对于使我们意识到存在这些问题非常有用。 对于功能请求，此渠道并非旨在支持这些类型的请求，而是通过此渠道可以轻松地针对特定组件或功能提出建议，因为文档基于主题，可以针对特定主题进行对话功能，有助于将UserVoice条目与特定的文档主题结合在一起。 通过详述指向功能请求的UserVoice链接，产品组希望在该论坛中详细说明您的反馈。 我在此处包括了一些相关的UserVoice条目，以防需要的功能引起人们的兴趣。

循环读取副本并提供门户中副本的性能指标

深入了解Azure SQL数据库主副本与读取横向扩展副本之间的复制延迟

我们已经实施了一些流程来逐步升级属于该灰色区域的纯产品问题，这些问题在文档中是正确的，但问题与产品相关性更高。 在这些情况下，文档问题仍将关闭，但将在内部跟踪该问题。

我们非常感谢收到的反馈和您的协助，以提高我们对完全无法按设计工作的教程和示例的认识。

这也是相关和相关的
https://feedback.azure.com/forums/217321-sql-database/suggestions/34337935-monitor-queries-on-secondary-database-when-read-sc