找到問題的真正原因: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”,我們要用我們的進步告訴大家博客園團隊在成長!


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM