Using xp_ReadErrorLog in SQL Server 2005

 

Using xp_ReadErrorLog in SQL Server 2005

By Guest Authors on 12 May 2008 | 8 Comments | Tags: Administration

 


 

 

I would like to share some interesting parameters I found for the undocumented extended stored procedure xp_ReadErrorLog. In doing some testing with this extended stored procedure I found four very interesting parameters. Adding to some of the articles already on the web that discuss undocumented stored procedures, in this article I will explain my testing, use and some examples of the procedure.

 

Parameters revealed

While working on some system startup procedures that would be making use of the xp_ReadErrorLog extended stored procedure, I came across some very interesting and useful parameters for the procedure. In testing I discovered some of the hidden parameter options that are similar, but still different in the way the extended stored procedure works from version SQL 2000 to SQL 2005. These are SQL 2005 only options. The parameter data types and size were determined by investigating the undocumented stored procedure sp_ReadErrorLog that uses the extended stored procedure.

Well, the interesting part starts now with the parameters. As in the previous versions parameter 1 reads the error log number passed to it, where the default "0" reads the current log.

xp_ReadErrorLog 

 
LogDate                  ProcessInfo  Text
2008-03-04 12:11:01.450  Server       Microsoft SQL Server 2005 - 9.00.3159.00 (Intel X86)    Mar 23 2007 16:15:11
2008-03-04 12:11:01.500  Server       (c) 2005 Microsoft Corporation.
2008-03-04 12:11:01.500  Server       All rights reserved.   2008-03-04 12:11:01.500 Server     Server process ID is 1284.
2008-03-04 12:11:01.500  Server       Authentication mode is MIXED.
2008-03-04 12:11:01.510  Server       Logging SQL Server messages in file 'D:/SRVAPPS/MSSQL.1/MSSQL/LOG/ERRORLOG'.

Now let's investigate Parameter (2). It turns out that a value of 1 (default) instructs the procedure to read the SQL error log. By passing a value of 2, the SQL server Agent log is read. Yes, the Agent log! So for example: xp_ReadErrorLog 0, 2 reads the current SQL server Agent log. Also note when using parameter 2 with the extended stored procedure that the column heading returned also changes.

xp_ReadErrorLog 0,2
 

LogDate                  ErrorLevel  Text
2008-03-04 12:11:10.000  3           [393] Waiting for SQL Server to recover databases...
2008-03-04 12:11:14.000  3           [100] Microsoft SQLServerAgent version 9.00.3042.00 (x86 unicode retail build) ..
2008-03-04 12:11:14.000  3           [101] SQL Server xxxxxxxx version 9.00.3159 (0 connection limit)
2008-03-04 12:11:14.000  3           [102] SQL Server ODBC driver version 9.00.3042 2008-03-04 12:11:01.450  Server

Now we know that we can read both SQL logs (error and agent) for any log file, so now let's look at parameter (3). For those times when you need to find some value in the logs and have used the old trick/process of reading the extended stored procedure into a table and then searching through the table to find a value, we now have parameter (3). Parameter 3 is a search string that can be used to return just the log entry rows that contain the value in the search string. And to make it even better or to refine the search further, parameter 4 is also a search string.

An extra feature of this new version is that parameters 3 and 4 can be used in conjunction with each other for searching SQL error log (parameter 2 = 1) or SQL Agent log (parameter 2=2). So for example, xp_ReadErrorLog 0,1,'failed' will read the current SQL error log and return only rows that contain "failed". For an example of using parameter (4) example, xp_ReadErrorLog 0,1,'failed','login' will read current SQL error log returning only rows that contain "failed" and "login" in the same row. This makes it quite easy for retrieving those log entries for failed user logins from the SQL error logs, or maybe looking for those failed Agent jobs. Or those occasional times when you need to quickly find the port SQL started on or what machine the cluster is executing on.

xp_ReadErrorLog 0, 1, 'Failed', 'login'
 

LogDate                  ProcessInfo  Text
2008-03-04 12:11:12.340  Logon        Login failed for user 'Domain/xxxxxx'. [CLIENT: <local machine>]
2008-03-04 15:29:08.710  Logon        Logon failed for login 'NT AUTHORITY/NETWORK SERVICE' due to trigger execution.
2008-03-04 15:29:08.710  spid54       The client was unable to reuse a session with SPID 54, which had been reset...

Parameters defined

  • Parameter 1 (int), is the number of the log file you want to read, default is "0" for current log. The extended stored procedure xp_enumerrorlogs will come in handy in determining what SQL server error logs or SQL server Agent logs exist and when they were created. NOTE: extended stored procedure xp_enumerrorlogs parameter (1) works just like xp_ReadErrorLog parameter (2). A value of 1 shows available SQL error logs and a value of 2 shows Agent logs. The default value is 0.
  • Parameter 2 (int), value of 1 reads SQL error logs, value of 2 reads SQL Server Agent logs, with a default value of 1.
  • Parameter 3 varchar (255), is a search string for the log entry, with a default value of NULL.
  •  Parameter 4 varchar (255), is another search string for the log entry, with a default value of NULL.

Background

An extended stored procedure is a dynamic link library that runs inside SQL server. It can execute from Query Analyzer or SQL Server Management Studio (SSMS) for example. In most cases these extended stored procedures can only be executed by users with sysadmin privileges. Also note as Microsoft has always said about undocumented processes may change in future release. And this is an example as it certainly has changed from previous version of SQL.

About the Author

Dan McClain is currently the Team Lead for the SQL Server DBA team at Anheuser-Busch, Inc. in Saint Louis, Missouri. He has been working in IT for over 25 years and with database for over 12. He is active in the local SQL Users Group.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: `xp_readerrorlog` 是一个系统存储过程,用于读取 SQL Server 错误日志文件中的信息。它可以帮助你快速查找 SQL Server 实例的错误信息,例如连接失败、备份失败、日志增长等。此存储过程有许多参数,允许你指定要读取的日志文件和时间范围。例如,以下是一个使用 `xp_readerrorlog` 存储过程检索最近 7 天内的错误日志的示例: ``` EXEC xp_readerrorlog 0, 1, N'', N'', N'', N'', '7days'; ``` ### 回答2: xp_readerrorlog 是一种系统存储过程,用于读取 SQL Server 错误日志中的信息。它可以帮助管理员和开发人员快速定位和排查数据库中的问题。xp_readerrorlog 的主要作用是读取 SQL Server 错误日志中的内容,包括错误记录、警告、信息和其他事件的详细描述。 使用 xp_readerrorlog 可以提供诸如以下信息:错误记录的日期和时间、错误等级、错误号、错误描述、错误发生的位置、影响的数据库、错误记录的源头等。这可以帮助管理员迅速了解数据库出现的问题,以便及时进行故障排除和修复。 此外,xp_readerrorlog 还支持通过指定日期范围、关键字等条件来筛选错误日志的结果。管理员可以根据自己的需求来获取特定时间段、特定类型的错误信息,从而更加精确地了解数据库的健康状况。 需要注意的是,只有具有 sysadmin 或 processadmin 角色的用户才有权限执行 xp_readerrorlog 存储过程。为了保护数据库的安全性,应该限制对该存储过程的访问权限,只授权给有需要的用户。 总之,xp_readerrorlogSQL Server 提供的一个非常有用的工具,可以帮助管理员和开发人员迅速定位和解决数据库中出现的错误和问题,提高数据库的可靠性和稳定性。 ### 回答3: xp_readerrorlog 是一个 SQL Server 存储过程,用于读取和分析 SQL Server 错误日志。当 SQL Server 遇到错误或发生异常时,会将相关的错误信息记录在错误日志中。这些错误日志对于排查和解决问题非常有帮助。而 xp_readerrorlog 正是用来访问和检索这些错误日志的。 使用 xp_readerrorlog,我们可以指定需要读取的错误日志的开始时间和结束时间,以及需要过滤的关键词。这样可以有针对性地检索和查看特定时间范围内发生的错误。返回的结果包含相关错误的时间戳、错误级别、错误信息等详细信息。 除了指定时间范围和关键词,xp_readerrorlog 还提供了一个可选的参数,用于指定需要读取的错误日志的文件号码。因为 SQL Server 错误日志会被分割为多个文件,每个文件都有一个唯一的文件号码。通过指定文件号码,我们可以选择读取特定的错误日志文件。 总的来说,xp_readerrorlog 是一个非常有用的工具,可以让我们快速有效地访问和查询 SQL Server 的错误日志,并帮助我们找出和解决数据库中的问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值