假设我有一个这样的存储过程（假设表模式很好）：
CREATE PROCEDURE p_MyProc
AS
INSERT MyTable SELECT Col1 FROM Table1
INSERT MyTable SELECT Col2 FROM Table2
INSERT MyTable SELECT Col3 FROM Table3
假设这些最终成为每次可能需要几分钟的大插入，是否可以确定当前在存储过程的上下文中运行的是哪一个？
我知道如何找到正在运行的存储过程，我只是想看看是否有办法获得更细化，而无需在其中添加 PRINT 或其他跟踪语句。有没有办法让语句显示在跟踪中？
多亏了一些很棒的帖子，我已经成功地在客户的 SQL Server 实例上启动了一些服务器端跟踪，但由于这确实是我在“现实生活”情况下的第一次，我想知道一些事情。
1) 我在创建跟踪的脚本中定义了跟踪文件的“基本”名称。我每天早上 6 点开始跟踪并在晚上 7 点再次关闭它。我真正想做的是将跟踪文件的基本名称设置为包含日期，例如，我希望将其设为
(some directory)\MyTrace-2012-Apr-19
等等 - 这样每天的跟踪文件将很容易识别。有没有办法实现这一目标？我是否必须每天实际创建和删除跟踪才能得到这个？？
2) 如果我每天打开和关闭跟踪，我昨天 ( MyTrace.trc) 的跟踪文件今天会被重用，直到它定义的最大大小吗？或者 SQL Server 会在每天启动时创建一个新的跟踪文件 ( MyTrace_1.trc, MyTrace_2.trc) 吗？
3）此外，即使在晚上 7 点之后，我也无法尝试获取该跟踪文件 - 似乎它仍然被某个进程锁定，我不能将它复制到其他地方......我假设一旦跟踪停止，文件将“免费”可用 - 我错了吗？
最近，我一直在 SQL Server 日志中看到错误。
代码：3930 描述：“当前事务无法提交，无法支持写入日志文件的操作。回滚事务。”
使用 SQL Profiler，如何找到导致此错误的确切语句？SQL Profiler 中的哪一列填充了 SQL 错误日志中的“消息”列？不幸的是，我们只在生产中得到这个，所以我需要在那里运行一个尽可能轻量级的跟踪。你们推荐什么来捕获有问题的代码？
我使用下面的查询来获取 sql server 中数据库发生的自动增长事件。
DECLARE @trcfilename VARCHAR(1000);
SELECT @trcfilename = path FROM sys.traces WHERE is_default = 1
SELECT COUNT(*)as no_of_autogrowths,
sum(duration/(1000*60)) as time_in_min,
Filename
FROM ::fn_trace_gettable(@trcfilename, default)
WHERE (EventClass = 92 OR EventClass = 93)
GROUP BY Filename
它输出自动增长的数量、自动增长所用的时间和文件的逻辑名称。但我想要文件的物理名称（mdf 和 ldf 文件名）而不是逻辑名称。我不知道是否从 sys.traces 中我会得到物理名称，或者请帮助我用另一种方法来做到这一点。
在处理每 10 分钟发生一次的意外 CPU 峰值时，我的一位同事准备了如下的服务器端跟踪：
-- Create a Queue
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
declare @DateTime datetime
set @DateTime = '2015-09-03 10:50:00.000'
set @maxfilesize = 10240 --10GB
-- Please replace the text InsertFileNameHere, with an appropriate
-- filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension
-- will be appended to the filename automatically. If you are writing from
-- remote server to local drive, please use UNC path and make sure server has
-- …由于 SQL Server 版本过时，我必须使用服务器端跟踪来收集一些信息，但如果我尝试实现它，则会收到错误Filters with the same event column ID must be grouped together。我的代码：
exec sp_trace_setfilter 2, 10, 0, 7, N'SQL Server Profiler%'
exec sp_trace_setfilter 2, 10, 0, 7, N'DatabaseMail%'
exec sp_trace_setfilter 2, 10, 0, 7, N'SQLAgent%'
sp_trace_setfilter 1, 10, 0, 6, N'SQLT%';
sp_trace_setfilter 1, 10, 0, 6, N'MS%';
通常它可能是显而易见的事情，但我不知道为什么它不起作用（它不是分号）。
你们中有人有想法吗？
我正在尝试使用跟踪捕获来确定有多少性能问题与数据库相关以及有多少与代码相关。但是，重放跟踪所需的时间比最初捕获所需的时间长。
我所追求的是单独运行我们的 SQL 语句所需的总时间，而没有我们实际代码的开销。如果重播花费了捕获总时间的一半，我将假设错误是代码和数据库，如果重播花费的时间与捕获几乎相同，我将假设它是数据库，如果重播与我们的捕获相比几乎没有时间，我会假设这是我们的代码。我假设重放是执行所有语句的一种非常有效的方式。
相反，当我重放我的跟踪时，运行时间至少是原始捕获时间的两倍。无论我允许多个线程还是要求它是顺序的，这都是正确的。我对此很陌生，所以我可能会做一些愚蠢的事情（可能这里的整个想法都是愚蠢的），但在我看来重播应该更快，而不是更慢。
我的捕获跟踪是重放模板 + SQL:statement completed （因此它兼作调整捕获）。
我想找到特定用户在一段时间内在数据库中执行的所有查询。
我了解了跟踪和 XEvents，但这些尚未设置，我仍然能够获取特定用户执行的查询吗？