为特定客户端分析 SQL Server 的影响最小的方法是什么?

发布于 2024-09-12 08:27:05 字数 310 浏览 2 评论 0原文

我的本地友好 DBA 不喜欢允许在 SQL 服务器(甚至是非生产服务器)上进行分析的想法,因为这会影响它们的性能。

具有讽刺意味的是,我试图减少对一大堆 SQL 查询的需求,并且希望能够以相当非侵入性的方式检查通过网络发送的查询,而不影响服务器性能。为此,有一个工具与 Fiddler 的方法类似,用于调试 HTTP 连接,但允许客户端SQL Server 的侧面分析(至少对于 .net 应用程序)?或者为单个客户端运行配置文件是否不会影响服务器性能?

My local friendly DBA does not like the idea of allowing profiling on the SQL servers (even non-production ones) due to the impact on performance they have.

Ironically, I'm trying to reduce the need for a whole bunch of SQL queries, and would like to be able to check in a fairly non-invasive manner what queries are being sent over the wire, without impacting on the server performance. To this end is there a tool similar in approach to how useful Fiddler is for debugging HTTP connections, but allows client side profiling of SQL Server (at least for .net applications)? Or is it the case that running a profile for a single client will not impact on server performance?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

GRAY°灰色天空 2024-09-19 08:27:05

在这种情况下,您能做的最好的事情就是使用 默认跟踪,假设它已启用,但您可能会发现它的实用性有限。

好吧,我收回那句话。您能做的最好的事情就是与您的 DBA 交谈并让他或她至少允许在开发服务器上进行跟踪。你现在的处境很可笑。

可以尝试使用Wireshark之类的工具并观察网络流量,然后提取感兴趣的查询并在 SSMS 中单独运行它们,并将 SET STATISTICS IO 设置为 ON,并从中收集一些信息。希望他也为您提供足够的访问权限来获取查询计划。但这是一个可怕的解决方案。事实上,你甚至应该因为我的建议而否决我。

这就像试图将双手绑在背后游泳一样。今晚我给你喝一杯冷饮。

The best you can do in this situation is to use the Default Trace in SQL Server, assuming it's enabled, but you may find that to be of limited utility.

Ok, I take that back. The best you can do is to talk some sense into your DBA and get him or her to at least allow traces on development servers. You're in a ridiculous situation right now.

You could try to use a tool like Wireshark and watch the network traffic, then pull out queries of interest and run them in SSMS individually with SET STATISTICS IO set to ON and glean some information from that. Hopefully he gives you enough access to get the query plans too. But that's a horrible solution. In fact, you should downvote me for even suggesting it.

This is like trying to swim with both hands tied behind your back. I will drink a cold one for you tonight.

极度宠爱 2024-09-19 08:27:05

您已标记此 ADO.NET。 ADO.NET 有内置跟踪工具您调查过这些吗?

您使用的是 SQL Server 2008 吗?如果是这样,您的 DBA 对扩展事件有何看法?这些可以配置为删除多余的事件,而不是像 SQL Trace/SQL Profiler 那样导致服务器降级。

一种了解正在运行的查询及其频率的轻量级方法,

select * from sys.dm_exec_cached_plans
outer apply sys.dm_exec_sql_text(plan_handle)
order by usecounts desc

但这不符合特定的客户端标准,并且会受到计划缓存的变化莫测的影响。

You've tagged this ADO.NET. ADO.NET has inbuilt tracing facilities have you investigated those?

Are you on SQL Server 2008? If so how does your DBA feel about extended events? These can be configured to drop surplus events rather than cause server degradation as SQL Trace/ SQL Profiler does.

A light weight way of getting some idea of the queries that are being run and how often is

select * from sys.dm_exec_cached_plans
outer apply sys.dm_exec_sql_text(plan_handle)
order by usecounts desc

but that wouldn't meet the specific client criteria though and is subject to the vagaries of plan caching.

半世蒼涼 2024-09-19 08:27:05

我的本​​地友好 DBA 不喜欢允许在 SQL 服务器(甚至是非生产服务器)上进行分析的想法,因为这会影响它们的性能。

好吧,他或她可能有道理,而且过去很可能因此而被烧伤。

但是,您有需求,因此如果您无法使用探查器,请将其交给 dba,以建议一种方法来满足您的需求。我坚信“你告诉我不,然后我希望你为我提供替代方法来完成我的工作”这一理念。当说“不”变得很痛苦时,人们就更倾向于说“是”。

探查器可以配置为仅分析非常有限的事件,这对性能影响较小。 dba 甚至可能是您建议设置探查器条件并运行它的人,在您运行要分析的进程时将结果保存到表中。这样,他就可以控制所分析的内容,并确保在不再需要时将其停止,并确保其影响尽可能小,并且您得到您想要的东西。毕竟,做这些事情是 dba 的工作。也许她需要提醒。

My local friendly DBA does not like the idea of allowing profiling on the SQL servers (even non-production ones) due to the impact on performance they have.

Well he or she may have a point and may well have burned by this in the past.

However, you have a need, so throw it over to the dba to suggest a method to fulfill your need if you can't use profiler. I'm a firm beliver in the "you tell me no, then I expect you to provide me with alternative way to do my job" philosophy. When it becomes painful to say no, people are more inclined to say yes.

Profiler can be configured to profile only very limited events which has less impact on performance. The dba could even be the one you suggest set up the profiler conditions and run it saving the results to a table for you while you run your processes that you want to profile. That way, he has control over what is profiled and makes sure it is stopped when not needed any more and makes sure that it will have as little impact as possible and you get what you want. It is after all the dba's job to do those sorts of things. Perhaps she needs a reminder.

蓝海似她心 2024-09-19 08:27:05

最新版本的 ANTS Performance Profiler 包括 SQL 和 I/O 分析,这样您就可以在客户端获取这些详细信息,而不会给服务器带来任何负载。

The latest version of ANTS Performance Profiler includes SQL and I/O profiling, so you can get those details client side, without putting any load on the server.

韬韬不绝 2024-09-19 08:27:05

Microsoft 的网络监视器 是我过去考虑过用于此类目的的一个工具 - 已经安装并试用了它,但后来不得不做一些实际工作,所以放弃了它。它看起来确实很有前途——并且具有 SQL 相关协议(包括 TDS)的解析器。

Microsoft's Network Monitor is a tool I've considered for such a purpose in the past - got as far as installing it and having a play but then had to do some real work so gave it up. It certainly looked promising - and has parsers for SQL-related protocols including TDS.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文