标签: profiler

在 MySQL 上开发时，我真的很想念能够启动分析器。我发现SQLyog是查询分析器的一个足够好的替代品，但还没有找到一个像 SQL 分析器一样工作的工具。

对于没有看过微软的SQL Profiler的 MySQL 人，这里是一个截图

在我之前的工作中，我们有一个胜过 SQL Profiler的工具，甚至给了我们堆栈跟踪

有谁知道像我提到的那样适用于 MySQL 的任何工具。

（仅供参考，我可以让 Altiris Profiler 与 MySQL 一起使用，但它将涉及运行 Windows，而且它不是真正的赛门铁克 sku，因此许可非常棘手）

作为开发人员，我经常使用 SQL Profiler。这是一个很好的调试工具，既可以跟踪我的代码在做什么，也可以分析性能问题。

但是我一直在我的开发环境中使用它，并且以一种非常可控的方式使用它。

• 启动我的应用程序，并使其进入特定状态
• 在探查器上开始跟踪
• 对我的应用程序执行特定的操作序列
• 停止跟踪并检查结果。

SQL Profiler 能否在生产环境中实际使用？

我首先担心的是它会降低性能。

我的第二个担忧是，因为它正在生产中，您不会触发有趣的操作本身。您必须让分析器长时间运行，然后分析结果。结果集会变得太笨拙吗？（占用太多磁盘空间，查询太难）。

有人在生产中使用 SQL Profiler 吗？

我正在使用扩展事件收集阻塞的进程报告，并且由于某些原因，在某些报告中该blocking-process节点为空。这是完整的xml：

<blocked-process-report monitorLoop="383674">
 <blocked-process>
  <process id="processa7bd5b868" taskpriority="0" logused="106108620" waitresource="KEY: 6:72057613454278656 (8a2f7bc2cd41)" waittime="25343" ownerId="1051989016" transactionname="user_transaction" lasttranstarted="2017-03-20T09:30:38.657" XDES="0x21f382d9c8" lockMode="X" schedulerid="7" kpid="15316" status="suspended" spid="252" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2017-03-20T09:39:15.853" lastbatchcompleted="2017-03-20T09:39:15.850" lastattention="1900-01-01T00:00:00.850" clientapp="Microsoft Dynamics AX" hostname="***" hostpid="1348" loginname="***" isolationlevel="read committed (2)" xactid="1051989016" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
   <executionStack>
    <frame line="1" stmtstart="40" sqlhandle="0x02000000f7def225b0edaecd8744b453ce09bdcff9b291f50000000000000000000000000000000000000000" />
    <frame line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" />
   </executionStack>
   <inputbuf>
(@P1 bigint,@P2 int)DELETE FROM DIMENSIONFOCUSUNPROCESSEDTRANSACTIONS WHERE ((PARTITION=5637144576) AND ((FOCUSDIMENSIONHIERARCHY=@P1) AND (STATE=@P2)))   </inputbuf>
  </process>
 </blocked-process>
 <blocking-process>
  <process />
 </blocking-process>
</blocked-process-report>

此 hobt_id 所属索引的索引定义是

CREATE UNIQUE …

明年，我将帮助清理多个 SQL Server 环境。

我们有大约 10,000 个存储过程，估计其中只有大约 1000 个是定期使用的，另外还有 200 个左右是在极少数情况下使用的，这意味着我们有很多工作要做。

由于我们有多个部门和团队可以访问这些数据库和程序，因此我们并不总是调用这些程序的人，这意味着我们必须确定正在调用哪些程序。最重要的是，我们希望在几个月内而不是几天内确定这一点（这消除了一些可能性）。

一种方法是使用SQL Server Profiler并跟踪正在调用的过程，并将它们与我们拥有的过程列表进行比较，同时标记是否使用了这些过程。从那时起，我们可以将程序移动到不同的模式，以防部门尖叫。

Profiler在这里使用最有效的方法吗？和/或你们中有没有人做过类似的事情并找到了另一种方法/更好的方法来做到这一点？

扩展事件似乎是一种更好的技术，对服务器的压力更小，但 SQL Profiler/perfmon 具有更好的工具。此外，扩展事件似乎具有更陡峭的学习曲线。每个应该在什么上下文中使用？是否值得通过陡峭的学习曲线来利用扩展事件？

如何分析 SQL Server 2008 数据库以查看正在特定数据库上执行的代码？我记得使用过 SQL Server profiler，但是我在下载 SQL Server 2008 R2 Express 后在 SQL Server Management Studio 中没有看到它。我在哪里可以下载该工具并安装它？我是否需要完整版的 SQL Server 2008 才能看到此选项？

我们试图弄清楚如何优化查询（大约需要 100 毫秒），并运行我们看到Creating Sort Index使用75%的总时间的配置文件。首先，究竟是什么影响了创建排序索引？是磁盘/io吗？

其次，我们可以对查询本身进行任何优化吗？

SELECT r.`id`, 
       r.name, 
       r.public_uri, 
       rv.version, 
       rv.interpreter, 
       rv.notes, 
       rv.content, 
       r.added, 
       r.added_by, 
       r.modified, 
       r.modified_by, 
       r.public, 
       r.public_by
  FROM recipe_heads rh, 
       recipes r, 
       recipe_versions rv
 WHERE rh.recipe = r.`id` 
   AND rh.recipe_version = rv.`id` 
   AND r.`id` = rv.recipe
ORDER BY r.added DESC

解释：

我正在编写一个大量使用 SQL Azure 的网站。然而，它是痛苦的缓慢。

有没有一种简单的方法来分析实时 SQL Azure 实例？

我面临的问题是 sql server 2008 因某些高负载而失败。我需要找到那个负载情况并需要优化代码以便它可以处理负载。我在 Internet 上发现 SQL 分析器可用于跟踪数据库交互，稍后可以对其进行分析以找到问题发生的确切点。我还发现了如何启动 sql 分析器。但现在我的问题是，通过启动 sql profiler 我会影响服务器性能吗？

使用 SQL Server Profiler（我使用的是 SQL Server 2012），我试图生成一个有用的跟踪来显示参数值，而不仅仅是带有变量名的 SQL。存储过程遍历大量库存数据以生成一些非常有价值的结果，我正在尝试记录现有行为，以便我可以对其进行单元测试，准确定义它，然后将其重构为合理的东西。

我有一个存储过程，它在一个循环中执行一个 54 个参数的子过程，其中存储过程创建一个游标然后执行一个 while 循环。这是一个简化的视图：

CREATE PROCEDURE 
   [dbo].[OuterProcedure]       
   (  @ProductCode varchar(8),          
     -- 41 more parameters omitted
   )
AS            
  SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED   
  SET NOCOUNT ON           
 DECLARE @AboutFourHundredLocalvariables -- omit about 400 local variable declarations.
 -- OMIT ABOUT 10 temporary table declarations.
 DECLARE  aCursor CURSOR FAST_FORWARD FOR         
   SELECT [ID],bkno,  -- about 40 fields omitted.
              FROM vwVeryComplexViewThatDoesALotOfVeryBrutalJoins         
              WHERE  (about_80_boolean_expressions AND omitted_here)
        ORDER BY some,keys,like,this

OPEN aCursor          
FETCH NEXT FROM aCursor /* Get …