推薦：淺析SQL2008的Change Data Capture功能
在常見的企業(yè)數(shù)據(jù)平臺管理中有一項任務(wù)是一直困擾SQL Server DBA們的，這就是對數(shù)據(jù)更新的監(jiān)控。很多數(shù)據(jù)應(yīng)用都需要捕獲對業(yè)務(wù)數(shù)據(jù)表的更新。筆者見過幾種解決方案： 1、在數(shù)據(jù)表中加入特殊的

任何數(shù)據(jù)庫系統(tǒng)都無法避免崩潰的狀況，即使你使用了Clustered，雙機熱備等等，仍然無法完全根除系統(tǒng)中的單點故障，何況對于大部分用戶來說，無法承受這樣昂貴的硬件投資。所以，在系統(tǒng)崩潰的時候，我們應(yīng)該如何恢復(fù)原有的寶貴數(shù)據(jù)就成為一個極其重要的問題了。

在恢復(fù)的時候，最理想的情況就是你的數(shù)據(jù)文件和日志文件都完好無損了，這樣只需要sp_attach_db，把數(shù)據(jù)文件附加到新的數(shù)據(jù)庫上即可，或者在停機的時候把所有數(shù)據(jù)文件(一定要有master等)都copy到原有路徑下也行，不過一般不推薦這樣的做法，sp_attach_db比較好，雖然麻煩許多。

但是呢，一般數(shù)據(jù)庫崩潰的時候系統(tǒng)是未必能有時間把未完成的事務(wù)和臟頁等寫入磁盤的，這樣的情況sp_attach_db就會失敗。那么，寄希望于DBA制定了一個良好的災(zāi)難恢復(fù)計劃吧。按照你的恢復(fù)計劃，還原最新的完全備份，增量備份或者事務(wù)日志備份，然后如果你的活動事務(wù)日志還能讀得出來的話，恭喜你!你可以還原到崩潰前的狀態(tài)。

一般的單位都是沒有專職的DBA的，如果沒有可用的備份，更可能是最近一次備份的時間過于久遠而導(dǎo)致不可接受的數(shù)據(jù)損失，而且你的活動事務(wù)日志也處于不可用的狀態(tài)，那就是最麻煩的情況了。

不幸的很的是，一般數(shù)據(jù)庫崩潰都是由于存儲子系統(tǒng)引起的，而這樣的情況是幾乎不可能有可用的日志用于恢復(fù)的。

那么就只好試一下這些方案了。當然，是要求至少你的數(shù)據(jù)文件是存在的，要是數(shù)據(jù)文件、日志文件和備份都沒有了的話，別找我，你可以到樓頂上去唱“神啊，救救我吧”。

首先，你可以試一下sp_attach_single_file_db，試著恢復(fù)一下你的數(shù)據(jù)文件，雖然能恢復(fù)的可能性不大，不過假如這個數(shù)據(jù)庫剛好執(zhí)行了一個checkpoint的話，還是有可能成功的。

如果你沒有好到有摸彩票的手氣，最重要的數(shù)據(jù)庫沒有像你期盼的那樣attach上去，不要氣餒，還是有別的方案的。

我們可以試著重新建立一個log，先把數(shù)據(jù)庫設(shè)置為emergency mode，sysdatabases的status為32768 就表示數(shù)據(jù)庫處于此狀態(tài)。

不過系統(tǒng)表是不能隨便改的，設(shè)置一下先

Use Master

Go

sp_configure 'allow updates', 1

reconfigure with override

Go

然后

update sysdatabases set status = 32768 where name = ''

現(xiàn)在，祈求滿天神佛的保佑吧，重新建立一個log文件。成功的機會還是相當大的，系統(tǒng)一般都會認可你新建立的日志。如果沒有報告什么錯誤，現(xiàn)在就可以松一口氣了。

雖然數(shù)據(jù)是恢復(fù)了，可是別以為事情就算完成了，正在進行的事務(wù)肯定是丟失了，原來的數(shù)據(jù)也可能受到一些損壞。

先把SQL Server 重新啟動一下，然后檢查你的數(shù)據(jù)庫吧。

先設(shè)置成單用戶模式，然后做dbcc

sp_dboption '', 'single user', 'true'

DBCC CHECKDB('')

如果沒有什么大問題就可以把數(shù)據(jù)庫狀態(tài)改回去了，記得別忘了把系統(tǒng)表的修改選項關(guān)掉。

update sysdatabases set status = 28 where name = '' --當然你的數(shù)據(jù)庫狀態(tài)可能不是這個，自己改為合適的值吧。也可以用sp_resetstatus

go

sp_configure 'allow updates', 0

reconfigure with override

Go

checkdb的時候可能報告有一些錯誤，這些錯誤的數(shù)據(jù)你可能就只好丟棄了。

checkdb有幾種修復(fù)選項，自己看著用吧，不過最后你可能還是得用REPAIR_ALLOW_DATA_LOSS，完成所有修復(fù)。

chekcdb并不能完成所有的修復(fù)，我們需要更進一步的修復(fù)，用DBCC CHECKTABLE對每一個表做檢查吧。

表的列表可以用sysobjects里面得到，把OBJECTPROPERTY是IsTable的全部找出來檢查一下吧，這樣能夠基本上解決問題了，如果還報告錯誤，試著把數(shù)據(jù)select into到另一張表檢查一下。

這些都做完了之后，把所有索引、視圖、存儲過程、觸發(fā)器等重新建立一下。DBCC DBREINDEX也許可以幫你一些忙。

然后，就可以向boss吹噓一下你的豐功偉業(yè)，順便小小的提一下加薪的要求，如果(很有可能)不得逞的話，也只好回家睡覺去:'(

記得下次別忘了做好備份哦~

上面提到的命令、對象在Books Online中均有詳細說明，請注意參看。

分享：如何使用SQL Server嵌套子查詢
很多SQL Server程序員對子查詢（subqueries）的使用感到困惑，尤其對于嵌套子查詢（即子查詢中包含一個子查詢）。現(xiàn)在，就讓我們追本溯源地探究這個問題。 有兩種子查詢類型：標準和相關(guān)。標