推薦：教你快速掌握數據庫設計范式的基本概念
于數據庫設計中所遵循的范式規則比較復雜，對于初學者來講很難完全記住，本文針對數據庫設計范式的基本概念進行了扼要的總結。 第一范式: 對于表中的每一行，必須且僅僅有唯一的行值.在一

　　工作告一段落，今天下午有空，寫篇文章，也許會對大家有幫助:)　　

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

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

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

　　不幸的很的是，一般數據庫崩潰都是由于存儲子系統引起的，而這樣的情況是幾乎不可能有可用的日志用于恢復的。
那么就只好試一下這些方案了。當然，是要求至少你的數據文件是存在的，要是數據文件、日志文件和備份都沒有了的話，別找我，你可以到樓頂上去唱“神啊，救救我吧”。

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

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

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

　　不過系統表是不能隨便改的，設置一下先
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
然后
update sysdatabases set status = 32768 where name = '<db_name>'
現在，祈求滿天神佛的保佑吧，重新建立一個log文件。成功的機會還是相當大的，系統一般都會認可你新建立的日志。如果沒有報告什么錯誤，現在就可以松一口氣了。

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

　　先把SQL Server 重新啟動一下，然后檢查你的數據庫吧。
先設置成單用戶模式，然后做dbcc
sp_dboption '<db_name>', 'single user', 'true'
DBCC CHECKDB('<db_name>')
如果沒有什么大問題就可以把數據庫狀態改回去了，記得別忘了把系統表的修改選項關掉。
update sysdatabases set status = 28 where name = '<db_name>' --當然你的數據庫狀態可能不是這個，自己改為合適的值吧。也可以用sp_resetstatus
go
sp_configure 'allow updates', 0
reconfigure with override
Go

　　checkdb的時候可能報告有一些錯誤，這些錯誤的數據你可能就只好丟棄了。
checkdb有幾種修復選項，自己看著用吧，不過最后你可能還是得用REPAIR_ALLOW_DATA_LOSS，完成所有修復。
chekcdb并不能完成所有的修復，我們需要更進一步的修復，用DBCC CHECKTABLE對每一個表做檢查吧。
表的列表可以用sysobjects里面得到，把OBJECTPROPERTY是IsTable的全部找出來檢查一下吧，這樣能夠基本上解決問題了，如果還報告錯誤，試著把數據select into到另一張表檢查一下。
這些都做完了之后，把所有索引、視圖、存儲過程、觸發器等重新建立一下。DBCC DBREINDEX也許可以幫你一些忙。

　　然后，就可以向boss吹噓一下你的豐功偉業，順便小小的提一下加薪的要求，如果（很有可能）不得逞的話，也只好回家睡覺去:'(
記得下次別忘了做好備份哦~

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

分享：實現刪除主表數據時, 判斷與之關聯的外鍵表是否有數據
問題描述： 某個基礎信息表，與系統中30多個表存在外鍵關系，當刪除基礎數據時，需要判斷是否已經被用過，如果用過則更改標志位，如果沒有用過則直接刪除，如何能很好實現這個處理？最