如何解读SQL Server日志

定期分析sqlserver日志是DBA很重要的任务,那如何才能查看sqlserver日志呢?

在SQL Server 7.0和SQL Server2000中，可以用下面的命令查看：

DBCC log ( {dbiddbname}, [, type={01234}] )

参数:

Dbid or dbname - 任一数据库的ID或名字

type - 输出结果的类型:

0 - 最少信息(operation, context, transaction id)

1 - 更多信息(plus flags, tags, row length)

2 - 非常详细的信息(plus object name, index name,page id, slot id)

3 - 每种 *** 作的全部信息

4 - 每种 *** 作的全部信息加上该事务的16进制信息

默认 type = 0

要查看MSATER数据库的事务日志可以用以下命令：

DBCC log (master)

这可能是因为该数据库： 处于可疑模式。 不再存在。 处于单用户模式，并且唯一可用的连接已由其他用户或事物使用。 已被分离。 已设置为 RESTRICTED_USER 状态。 处于脱机状态。 设置为紧急状态。 不具有映射到用户的登录帐户，或者该用户已被拒绝访问。 此外，该登录帐户可能是多个组的成员，且其中一个组的默认数据库在连接时不可用。 SQL Server 2005 在 SQL Server 2005 中，可以使用 sqlcmd 实用程序更改默认数据库。为此，请按照下列步骤 *** 作： 1. 单击“开始”，单击“运行”，键入 cmd，然后按 Enter。 2. 根据 SQL Server 登录使用的身份验证种类，请使用以下方法之一： 如果 SQL Server 登录使用 Microsoft Windows 身份验证连接到该实例，请在命令提示符处键入以下内容，然后按 Enter： sqlcmd –E -S InstanceName –d master 如果 SQL Server 登录使用 SQL Server 身份验证连接到该实例，请在命令提示符处键入以下内容，然后按 Enter： sqlcmd -S InstanceName -d master -U SQLLogin -P Password 注意：InstanceName 是要连接到的 SQL Server 2005 实例的名称的占位符。SQLLogin 是已删除其默认数据库的 SQL Server 登录的占位符。Password 是 SQL Server 登录密码的占位符。 3. 在 sqlcmd 提示符处，键入以下内容，然后按 Enter： Alter LOGIN SQLLogin WITH DEFAULT_DATABASE = AvailDBName 注意：AvailDBName 是可由实例中 SQL Server 登录访问的现有数据库的名称的占位符。 4. 在 sqlcmd 提示符处，键入 GO，然后按 Enter。 SQL Server 2000 和 SQL Server 7.0 在 SQL Server 2000 和 SQL Server 7.0 中，可以使用 osql 实用程序更改默认数据库。为此，请按照下列步骤 *** 作： 1. 在命令提示符处，键入以下内容，然后按 Enter： C:\>osql -E 2. 在“osql”提示符处，键入以下内容，然后按 Enter： 1>sp_defaultdb 'user's_login', 'master' 3. 在第二个提示符处，键入以下内容，然后按 Enter： 2>go 更简单明了的： 无法打开用户默认数据库，登录失败,这也是SQL Server使用者熟悉的问题之一。在使用企业管理器、查询分析器、各类工具和应用软件的时候，只要关系到连接SQL Server数据库的时候，都有可能会碰到此问题,引起此错误发生的原因比较多,下面我们就来详细分析引起此问题的原因以及解决办法。 一、原因 登录帐户的默认数据库被删除。

原贴地址:http://expert.csdn.net/Expert/topic/2931/2931668.xml

使用工具是LogExplore,(下载地址：http://down.chinaz.com/download.asp?id=7887&dp=1&fid=7&f=yes）

安装后打开log explorer file=>attach log file->选择服务器和登陆方式->connect->

选择数据库->attach->左面对话框中browse->view log->就可以看到log记录，

点击“View DDL Commands”里面就有很多drop table 命令

点击下面的“undo”按钮是生成表结构的语句（create table ....）

点击下面的“Salvage”按钮是生成插入语句的（insert into ...values....）

（以上lynx1111提供）

我是按照上述方法的“Salvage”来生成被删除表的Insert语句，实际上用这个方法生成的SQL脚本已经包含了CreateTable。该过程速度大概用了8个小时，当时觉得慢，后来相比恢复过程，这个速度简直快的不行。最大的表脚本生成后超过1G。

生成所有的SQL脚本后，防止万一，我将数据库停下，并把Date文件夹的Log和.MDF文件拷出来（怕破坏LOG文件，没有使用数据库的备份方式备份），文件大小总共为5.7G

此后开始进行正式的恢复工作。新建一个数据库，先试着用SQL查询分析器运行了一个小表的脚本，完全没有问题。但后来发现导入比较大的SQL脚本文件，查询分析器就报错了。请教了realgz得知logExplorer本身对大脚本有良好支持，因此改用LogExplorer--》Run SQL Script 功能来运行脚本。果然大文件也可以恢复了。

但开始运行后发现包含有ntext字段的表恢复起来异常缓慢，打开一个包含nText字段的表的恢复脚本发现里面使用writeText来写入数据。恢复一个30万数据的表居然用了将近12小时的时间，而数据库中又有大量这样的表，为了加快数据，我又在几个机器上装了LogExplorer加入恢复过程，终于经过3天的时间，全部的表都搞的差不多了，不过恢复过程有少量的错误。

接下来我将几个机器的表导到同一个数据库中，不过此时恢复的表是没有包含索引、标识等扩展属性的，因此需要重新建立索引、标识、默认值以及触发器。在建立主键的时候发现居然有数据重复。。。没办法只好删除重复数据。

使用 select distinct * into t_New from t_Old 可以删除重复数据，但遇到有ntext字段的表是不能用这个方法的，最后只好用 Delete From t_Table Where ID IN (Select ID From t_Table a where (Select Count(*) From t_Table a where a.ID = ID ) > 1 )直接删除了有重复数据的记录

经过72小时的努力，99.9%的数据恢复。并于4月8日晚上恢复运行网站。

这时候部分用户反映无法登陆，一查发现是有小部分数据丢失，也就是LogExplorer里报错误的那些数据……没办法，我重新用UEdit打开SQL脚本，查找这些数据，发现还在，仔细一看发现，这些数据里都有部分内容里使用大量的回车，LogExplorer无法识别，因此才出的错误。

呵呵，顾客是上帝，没办法，只好将用户表重新在本地恢复一次，遇到错误就记录下ID，然后再考出SQL脚本到查询分析器运行（查询分析器可以运行）

现在建立了维护计划，每个星期做一次完整备份。另外 *** 作数据库的流程也变的规范，防止此类事故出现

〔一些收获：]

1、慎重使用Text/nText字段

2、LogExplorer的脚本执行工具对付大文件很不错，但执行过程会对多个回车产生误判断

3、有问题不要着急，上csdn找高手帮忙，他们会很热心帮助你

---