J. *_*ini -2 sql-server t-sql waits ole-automation cpu
一些查询对我的 CPU 的影响非常严重。sp_WhoIsActive报告这sp_OAMethod就是原因(该sql_text列指向它)并且它具有PREEMPTIVE_OS_GETPROCADDRESS等待类型的巨大等待。鉴于这sp_OAMethod是一个内置存储过程,我该如何调试它?
我使用的是 2019 版本的 SQL Server,15.0.something。
我首先会完全停止使用 OLE 自动化,因为坦率地说,它充满了问题。有很多更好的选择。允许某人在 SQL Server 进程内托管 Web 服务器对任何人都没有帮助。
GetProcAddress是一个 Windows API,用于定位模块内函数的入口点。由于您使用的是 OLE 自动化,因此您要求自动化执行的“事情”需要它查找并执行这些“事情”,因此请输入Windows C/C++ 社区中随处使用的 Windows API。等待类型表示它正在等待。
要进一步调试它,您需要启用并捕获 SQL Server 的 ETW 跟踪(例如wpr、xperf、 logman )作为开始查看可能显示的内容。检查内核模式下的堆栈是否有闯入者或较长的磁盘读取时间将是一个开始。我相信那些通常的嫌疑人会抬起头来。
从赏金文本:
对当前答案的大量评论表明,关于 sp_OAMethod 及其 OLE 自动化同伴,还有很多东西需要学习。我希望看到关于它们可能引起什么问题的详细答案。尝试在 Stack Exchange 上找到它失败了。
堆栈交换数据库中没有足够的空间来详尽列出它们可能导致的所有问题。我有点夸张,但也很准确。这相当于问“代码中的未知错误究竟会导致什么问题?”。它可能是任何地方,从“什么也没有”,因为代码路径没有被执行,到崩溃、内存损坏等等,这是一个太宽泛的问题。
我们已经介绍了要点,因此创建一个摘要列表将是:
我的答案将回答你的问题。实际上,您现在有两个单独的问题,其中一个(赏金文本)我将其称为“冰山一角”,最有可能将 VTC 称为“需要细节或清晰度”。