找到问题的真正原因：20121021服务器故障处理经历

前言

在这篇博文中，我们将分享2012年10月21日服务器故障发生与处理的过程，这其中会反映出我们在服务器运维中存在的问题，也许会引来更多的指责、担忧。。。，但我们相信真诚的力量，相信我们战胜困难的决心，更相信大家的理解与支持！想起当初刚创建博客园的时候，自己组装的服务器频频当机，大家的理解、支持与帮助让我们度过了难关。

正文

2012年10月21日早晨8点起床后，像刷牙洗脸一样习惯性地打开首页（正常），打开闪存，出现在眼前的不是那熟悉的页面， 而是错误页面，心头一凉，糟糕的一天就这么开始了。上服务器一看，错误信息是：

Database 'CNBlogsUCenter' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.

大汗！难道数据库服务器又出问题了？同样是周日，同样是8点，难道历史真的在重演？控制内心的紧张，保持冷静，上数据库服务器一看究竟。。。

【插播】您可能会问为什么都是出现在周日早上8点？因为这时会进行数据库的日志备份操作，由于日志文件很大，所以硬盘读写负载很高（注：这个操作是在非RAID5的硬盘上进行的，数据在RAID5硬盘上）。

强行冷静+小心翼翼！登上服务器，发现在SQL Server Management Studio中对任何数据库的操作都出现错误提示：

The log for database 'tempdb' is not available. Check the event log for related error messages. Resolve any errors and restart the database. (Microsoft SQL Server, Error: 9001)

第一次遇到这样的问题，tempdb竟然当掉了。查看存放在非RAID5硬盘上的tempdb数据库文件（当初为了性能考虑，我们将tempdb数据库文件放在了非RAID5的独立硬盘上），文件是存在的，但突然发现这块硬盘上很多其他的文件夹不见了。看来是这块非RAID5的独立硬盘出问题了。当时我们想到的解决方案是将tempdb切换到RAID5的硬盘上。

【小知识点】如果tempdb数据库文件损坏或丢失，SQL Server会作如何处理？如果数据库文件的路径可以访问（硬盘没有坏，或者换了新硬盘并建立了相同路径的文件夹），SQL Server会自动重建tempdb。但是，现在硬盘出问题了，SQL Server即使想重建tempdb，使用当前的文件路径也无法新建tempdb数据库文件。SQL Server在设计上也没有对这个问题有容错考虑，比如，在重建tempdb失败时，使用默认路径再次重建。

接着，我们用下面的代码进行tempdb的切换操作：

use master
go
Alter database tempdb modify file (name = tempdev, filename = 'D:\TempDb\tempdb.mdf')
go
Alter database tempdb modify file (name = templog, filename = 'D:\TempDb\templog.ldf')
Go

但郁闷的是操作失败，从当时的错误信息看，在切换tempdb时，SQL Sever还是要读取原来的tempdb文件（感觉SQL Server在这个地方的设计有些不合理）。

我们短时间内没找到其他切换tempdb的方法，就重启了一下SQL Server服务，结果启动不起来。

由于时间紧迫，我们就启动了第二套恢复方案，将数据库文件复制至另外一台服务器进行恢复。 但是，由于日志文件(.ldf)存放在出问题的硬盘上，日志文件复制不出来，只能通过.mdf文件进行恢复，恢复方法详见数据库日志文件损坏的情况下如何恢复数据库。主要操作步骤如下：

• 新建同名的数据库(数据库文件名也要相同)。
• 停止数据库服务。
• 用.mdf文件覆盖新数据库的同名文件。
• 启动数据库服务。
• 运行alter database dbname set emergency，将数据库设置为emergency mode
• 执行一些命令进行恢复

之前，我们成功测试过在同一台服务器上进行这样的恢复，但没有测试过在不同服务器上的恢复。这次在不同服务器上的恢复，竟然不成功，出现错误：

One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files. If this is an existing database, the file may be corrupted and should be restored
from a backup.

经过几次尝试，未能解决这个问题。时间也不允许我们继续耗在这个问题上，我们要去见机房处理非RAID5硬盘问题。

在去机房之前，我们重启了一下数据库服务器，没能启起来。然后就赶往机房

。。。

到机房，接上显示器一看，与上次故障同样的错误信息：

Foreign configuration(s) found on adapter Press any key to continue or 'C' load the configuration utility, or 'F' to import foreign configuration(s) and continue.

There are offline or missing Virtual drives with preserved cache. Please check the cables and ensure that all drives are present. Press any key to enter the configuration utility.

这次，我们已经清楚地知道为什么会出现这个错误信息？

数据库服务器用的是Dell PowerEdge R710，那块非RAID5独立硬盘以RAID0的方式组成了一个虚拟磁盘（必须要这样），当这块硬盘出现问题时，RAID卡就会认为虚拟磁盘故障，必须要进行处理后，才能启动机器。

解决方法有两种：

1. 进入RAID卡的configuratin utility，清除preserved cache，也就是清除这块虚拟磁盘信息，只保留RAID5的虚拟磁盘，让机器启动起来，这是临时解决方法。

2. 换上新的硬盘，重新以RAID0的方式创建虚拟磁盘。

如果不是因为tempdb的原因（之前说过tempdb在出问题的硬盘上，又切换不到RAID5硬盘上），我们可以采用第一种解决方法，让服务器尽早恢复运行。现在即使用第一种方法让服务器启动起来，但SQL Server还是不能启动。所以我们只能采用第二方法，更换新的硬盘，然后在新硬盘上创建存放tempdb数据文件的同名文件夹，然后让SQL Server重建tempdb。

于是，我们致电Dell，让他们安排工程师过来更换硬盘。我们购买的Dell服务是当日4小时内上门服务，上次2小时左右就上门了，可这次将近4小时才上门，耗费不少时间在等Dell工程师上，这是我们无法控制的。

Dell工程师过来后，换上硬盘，创建好虚拟磁盘，服务器正常启动。然后，我们创建与原来硬盘同样的分区，并建立了同名的存放tempdb数据库文件的文件夹。启动SQL Server，tempdb自动重建，SQL Server正常启动。

但这时出现了意外的情况，数据库日志文件（.ldf）没有自动重建起来。之前，我们做过测试，当.mdf文件存在，而日志文件（.ldf）不存在时，SQL Server启动时会自动重建。这次可能是因为存放数据库日志文件的文件夹不存在造成SQL Server重建日志失败（仅是猜测，未经证实），之后，我尝试创建了相应的文件夹也没能解决问题。

接着我们用第二套方案成功恢复了数据库（方案来源），具体操作如下：

1. 运行alter database database set emergency，将数据库设置为emergency mode

2. 执行以下命令进行恢复：

use master 

declare @databasename varchar(255) 

set @databasename='要恢复的数据库名称' 

exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态 

dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) 

dbcc checkdb(@databasename,REPAIR_REBUILD) 

exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态 

这个恢复需要逐个数据库地进行操作，而且最好在没有其他数据库访问操作的情况下，操作很费时，有一个数据量最大的数据库，恢复花十几分钟。

结语

以上分享的就是服务器故障发生与处理的过程，从8:00左右点出现故障，到20:00左右恢复，竟然用了12小时左右的时间，实在很愧对大家！问题竟然是一块非RAID上的硬盘引起的，更愧对大家！

从单方面来看一个问题，似乎很简单就能解决。但是在复杂多变的现实情况下， 再加上你面前的问题堆积如山，每一个问题都不是那么简单。

只有身在其中，你才能真正体会其中的艰难；只有身在其中，你才能真正体会战胜困难的那种激动；只有身在其中，你才会相信任何问题都不是问题，只要你认真去面对！

我们已经知道如何从根本上解决这个问题，我们正在付诸运行，并将其中的过程与大家分享！

“出来创业，你在找的根本不是「成功」，你在找的是「进步」- Jamie”，我们要用我们的进步告诉大家博客园团队在成长！