1 背景

公司SQLserver2005数据库是在放在windows2003上面的,当时的sqlserver是给报表系统使用的.数据库上面差不多有2T的数据.
出问题那段时间,老是有短信告警提示从ORACLE数据库同步有异常(从平台同步基础数据过来加工),每小时的任务调度有一些存储过程莫名的错误,还超时调度不完,导致了很多任务都没能如期的完成,生成的统计数据也完成不了,赶紧用3板斧
(1) 检查锁表,查询耗时SQL
(2) dbcc checktable
(3) dbcc checkdb
以前这个经验之前用的比较灵验了,现在不灵验了, 纳尼,一个简单的数据同步插入语句就卡死了,kill掉后还是不行 再次同步数据的时候一样不行,想到的办法只能重启服务器了,这个事情白天不敢干的,只有等到晚上了.

检查sqlserver错误日志发现问题(大致意思是磁盘的某个位置出现异常导致写入失败),后来检查服务器上的事件查看器,磁盘错误,通知工程维护的同事去机房发现是富士通的一块磁阵坏了

本以为等他们换了磁阵(当时要把所有的MDF,LDF文件拷贝到新的地方,以防万一),重启服务器就万事大吉了,结果重启之后悲剧发生了,有一个数据库出现(置疑,恢复中),进度一直卡在59%那里过不去,这个数据库启动不起来,也就导致了报表应用无法使用,公司所有的日常工作都要分析数据也无法进行了.问题越来越严重了,之前是报表系统可以使用,只能不能查最新的数据而已,现在是连系统都不能用了

2 原因分析

前由于磁阵的问题导致写入失败,数据库LDF文件和MDF记录的数据存在不同步的情况,数据库恢复的时候导致无法正常通过,决定将LDF日志文件删除,弃用这部分数据(基础数据是从oracle平台同步过来的,所以不担心数据丢失的情况)

3 数据库恢复

3.1 新建伪数据库 zxdb_gz

所有的mdf ndf ldf文件名称必须一样

3.2 脱机数据库

ALTER DATABASE zxdb_gz SET OFFLINE;GO

3.3 将真实的数据库文件覆盖这个数据库的文件,然后联机数据库

ALTER DATABASE zxdb_gz SET ONLINE;GO

消息
Recovery of database ‘zxdb_gz’ (10) is 59% complete (approximately 198 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.

此时能将zxdb_gz数据库真实的关联上sqlserver,虽然还是卡在59%,无法执行过去.

3.4 停掉sqlserver服务

删除日志文件zxdb_gz_log.ldf

3.5 启动SQLSERVER服务

启动过后,系统会报错

FileMgr::StartLogFiles: Operating system error 2(系统找不到指定的文件。) occurred while creating or opening file ‘F:\zxdb_gz\sqlserverdata\zxdb_gz_log.ldf’. Diagnose and correct the operating system error, and retry the operation.

3.6 修改数据库为紧急模式

ALTER DATABASE zxdb_gz SET EMERGENCY;

3.7 使数据库变为单用户模式

ALTER DATABASE zxdb_gz SET SINGLE_USER;

3.8 修复数据库日志重新生成

 这个步骤会重新生成日志文件(系统会自动生成 zxdb_gz_log.ldf文件)

DBCC CheckDB (zxdb_gz, REPAIR_ALLOW_DATA_LOSS);

SELECT a.percent_complete,a.estimated_completion_time,a.command ,a.total_elapsed_time,row_count,dc.*,a.* 
FROM sys.dm_exec_requests a outer apply master.sys.dm_exec_sql_text(a.sql_handle) dc
WHERE session_id = 54;  --查看具体的进程进度

3.9 使数据库变回为多用户模式

修改为多用户模式

ALTER DATABASE zxdb_gz SET MULTI_USER ;