导航

SQL Server 2005 - Default Trace (默认跟踪)

Posted on 2011-04-25 17:13  Rainbow.ding  阅读(298)  评论(0编辑  收藏  举报

  在我们的工作中可能会遇到这样一种情形。由于数据库中某些对象被altered/created/deleted,造成我们的应用程序crash。

当我们把问题解决之后,老板可能会问发生了什么?为什么会这样?是谁干的?

在SQL Server 2005中提供了DDL trigger,它能回答所用这些问题,但我们没有在事前实现这一工作。

在这种情况下,有些人可能会对老板说:“我不知道,但我能去查。”之后就疯狂地寻找第三方的工具来读transaction log(事物日志)。他们可能不知道SQL Server 2005有一个内置的功能能回到所用这些问题。


答案藏在一个运行在后台的跟踪(Default Trace)中,我们可以利用Default Trace来寻找排除故障。Default Trace默认会自动运行,因为其非常轻量级,所以不会给系统造成很多负担。对我来说,Default Trace所带来的益处远大于它给数据库带来的负担。Default Trace不能代替DDL trigger的功能,它应被用作SQL实例的监视器,或用来快速获得SQL问题事件的详细信息。


Default Trace不会跟踪所有的事件,它扑捉一些关键性信息,包括auditing events,database events,error events,full text events,object creation,object deletion,object alteration。在本文中我们会关注对象级(event level)的事件,这能回答老板的“是谁干的”这一问题。


下面的代码能查询Default Trace是否已经被开启了

如果Default Trace功能没有打开,我们先要打开这个Trace。可以是使用如下代码,注意运行这些代码需要相应的权限。


下一段代码是来获取当前跟踪文件的路径。在相应的文件夹下可能会有多个以log_开头的trace文件,我们可以把这些文件载入一个表中,进行分析,但载入多个文件会增加开销。最好只是载入需要分析的信息。

现在让我们看一看跟踪下来的数据。我们先从创建一个新数据库开始。


使用如下的代码来打开跟踪文件,获取创建数据库的信息。这里使用了一些限制性的条件来缩小结果集。


注意:你的跟踪文件路径和名称可能和我的不同。要使用你自己的跟踪路径。


 


你能看到超过一条的结果,这是因为捕捉到了2事件子类,begin和commit。


现在创建另一个对象并再次进行查询。这次我们创建一张表“MyTable”。




现在使用类似的脚本来查询Default Trace,对where条件部分进行修改。


 


我们同样可以修改对象,代码如下:



使用如下的条件来过滤查询,特别注意修改trace_event_id为164,因为164代表对象修改事件


 



 


最后我们可以把"MyTable"Drop掉。


 

使用如下的条件来过滤查询,注意修改trace_event_id为47,因为47代表对象删除事件


 

       Default Trace还能跟踪到其他一些事件。例如你的日志文件快速增长,这时需要知道其原因。Default Trace会捕获日志增长事件,这对于排查问题很有价值。下面的查询会获得Default Trace中所有的log auto growth事件。