SQL Server数据库错误9003(LSN无效)的处理方法

SQL Server数据库错误9003(LSN无效)的处理方法

---

万华数据

　　国内一些ERP、财务软件一般后台都使用SQL Server的数据库，SQL Server作为一个中大型数据库是不应该在桌面系统上运行的，小规模企业一般不使用专用服务器，大部分直接使用XP系统+桌面引擎MSDE作为SQL数据库的后台服务。这种方案当然就谈不上什么稳定性和可靠性了，最糟的是在死机、重启或意外掉电后数据库会出现打不开的现象，其中错误9003：LSN(xx:xx:x)无效是最常见的问题。

　　这种情况是数据库的日志文件（LDF）数据不同步造成的，可以根据数据库MDF文件重建日志文件修复。

　　以下是详细步骤，有颜色标注的部分应该按本机的实际名称进行修改。

　　假设损坏的数据库名称是MYDB_001，对应的数据库名称是MyDB_Data.MDF，日志文件是MyDB_Log.LDF，数据库所在文件夹为D:/MYDATA/；

1、先把损坏的数据库对应的文件MyDB_Data.MDF和MyDB_Log.LDF备份到别的地方；

2、在SQL Server和企业管理器中创建一个与损坏数据库同名的数据库，对应的数据库文件名称也是MyDB_Data.MDF和MyDB_Log.LDF；

3、停止SQL Server服务；

4、删除第2步新建数据库产生的MyDB_Log.LDF文件；

5、用损坏的数据库数据文件MyDB_Data.MDF覆盖第2步新建数据库产生的MyDB_Data.MDF文件

6、启动SQL Server服务；

7、进入企业管理器，刷新数据库状态，此时数据库MYDB_001状态为“置疑”；

8、在SQL Server服务器属性中设置SQL Server数据库服务器“允许对系统目录直接修改”

9、从SQL企业管理器的“工具”菜单启动“SQL 查询分析器”；

10、输入以下代码并运行使MYDB_001数据库进入紧急修复模式：

        update sysdatabases set status=-32768 where dbid=DB_ID('MYDB_001')

　　这句语句执行后，刷新企业管理器，MYDB_001数据库的状态变成“只读/置疑/脱机/紧急模式”。

11、输入以下语句并执行重建日志文件；

        dbcc rebuild_log('MYDB_001','D:/MYDATA/MyDB_Log.LDF')

　　这句语句执行后，刷新企业管理器，MYDB_001数据库的状态变成“只供DBO使用”。

12、输入并执行正面的语句设置数据库MYDB_001到正常状态；

        exec sp_dboption 'MYDB_001','dbo use only','false'  

　　这句语句执行后，刷新企业管理器，MYDB_001数据库变成正常状态。

 

　　到此，MYDB_001数据库修复成功。最后不要忘记关闭第8步中打开的“允许对系统目录直接进行修改”服务器开关。

　--7．下面执行真正的恢复操作，重建数据库日志文件　　

go

dbcc rebuild_log('pos','D:Program FilesMicrosoft SQL ServerMSSQLDatapos_log.ldf') 　

go

　　--执行过程中，如果遇到下列提示信息： 　

　　--服务器:　　 消息　　 5030，级别　　 16，状态　　 1，行　　 1 　

　　--未能排它地锁定数据库以执行该操作。 　

　　--DBCC　　 执行完毕。如果　　 DBCC　　 输出了错误信息，请与系统管理员联系。 　

　　--说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL　　 Server　　 Enterprise　　 Manager打开了pos库的系统表，那么退出SQL　　 Server　　 Enterprise　　 Manager就可以了。 　

　　--正确执行完成的提示应该类似于： 　

　　--警告:　　 数据库　　 'pos'　　 的日志已重建。已失去事务的一致性。应运行　　 DBCC　　 CHECKDB　　 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。 　

　　--DBCC　　 执行完毕。如果　　 DBCC　　 输出了错误信息，请与系统管理员联系。 　

　　--此时打开在SQL　　 Server　　 Enterprise　　 Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

　　--8．验证数据库一致性（可省略）　　

go
dbcc checkdb('pos') 　

　　--一般执行结果如下： 　

　　--CHECKDB　　 发现了　　 0　　 个分配错误和　　 0　　 个一致性错误（在数据库　　 'pos'　　 中）。 　

　　--DBCC　　 执行完毕。如果　　 DBCC　　 输出了错误信息，请与系统管理员联系。

　　--9．设置数据库为正常状态　　

go

exec sp_dboption 'pos','dbo use only','false' 　

go

　　--如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。 　

　　--10．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL　　 Server　　 Enterprise　　 Manager里面恢复，也可以使用如下语句完成 　
exec sp_configure　　 'allow updates',0 　
go　　 　
reconfigure　　 with　　 override 　
go