我们有一个第三方的商业应用程序，我们认为这会导致我们的SQL Server 2005（64位）机器发生死锁。 为了帮助我们更好地pipe理软件，我们在上个星期与软件供应商进行了1/2/2天的培训后，正在做一些关于如何最好地利用SQL Server Profiler和跟踪模板的研究。
我个人的座右铭是“如果你是一个软件供应商构build一个需要你能够远程连接到客户端服务器的应用程序，那么你做错了。 不幸的是，我们现在没有太多的select。
我越来越了解这些家伙（软件供应商），他们对我印象深刻，而我自己也想做更多的“幕后”工作。 例如，我们一直在服务器缓慢爬行几个月的问题 – 但到目前为止，我看到系统上完全没有跟踪文件或跟踪模板文件。
在我的问题上…
运行跟踪文件是否会显着影响服务器性能？ 我的猜测是答案将是“这取决于”。 如果是这样，那么这里是我刚刚创build的新跟踪模板上select的“事件”：
在实际发生死锁之前是否必须运行一个跟踪，或者当我们注意到性能大幅降低时，是否能够运行跟踪？
我正在阅读关于现在查看SQL日志的技巧和技巧，因为这不是我们已经付出了很多的关注。 当我进入SQL Server Management Studio时，进入pipe理和SQL Server日志，我找不到那里说“死锁”/“死锁”等等的东西…所以也许没有什么是僵局。 有人可以确认死锁是否会显示在SQL日志中，如果是这样，我可以在我的search条件中使用什么来查找条目？
在SQL Server上运行跟踪将影响SQL Server。 基本的经验法则是，您在服务器上执行的任何操作都需要资源。 运行跟踪或SQL事件探查器对SQL Server性能问题吗？ 是的，如果你没有任何过滤，你一定可以。
如果遇到死锁问题，请打开Trace Flags 1204和1222 ，它将关于死锁的信息输出到错误日志。 不要一直留下这些，因为它们会影响性能。 输出到错误日志的信息将告诉你所有关于死锁部分的语句。
就像Trace一样运行诊断日志，它比Profiler使用更less的资源，但是一如既往，答案取决于服务器的规格以及在正常生产中一次执行多less次。 由于您仅使用SQL 2005，因此我认为硬件有点长，这意味着您应该小心在生产环境中运行它。 当尝试半盲或者甚至在一个全新的盒子上解决问题的时候，哪一个都不是真正推荐的。
对于＃2，如果你想捕获某些东西，IMO应该运行诊断程序，然后执行导致死锁的原因（假设你将它缩小到某个特定原因或事件types，或者只是一般的应用程序）
不幸的是，＃3帮不了多less。