資料庫維護計畫

完整備份 每天做
差異備分  每天做
最佳化作業(重建索引)  每週日做
完整性檢查作業  每週日做

重建索引的語法：ALTER INDEX indexname ON dbo.tablename REBUILD

建立索引：Create CLUSTERED / NONCLUSTERED INDEX indexname ON dbo.tablename (columnname)

叢集索引與非叢集索引的差別==>

叢集索引：因為資料會因它而排序，所以一個資料表只能設一個叢集索引

非叢集索引：一個資料表最多可以設249個非叢集索引, 設立非叢集索引的順序建議為 越容易當做過濾條件的欄位越先做索引

索引設完後, 可以用執行計畫檢視一下, 看所設的索引, 在同樣的查詢與法

延伸閱讀：∮Ω奧米加空間∮【轉貼】[SQL]索引重整與效率

以下是網路上找到的相關資料

資料來源：點部落(行動版)

微軟SQL Server資料庫的備份與還原

原文：http://www.ithome.com.tw/itadm/article.php?c=48081

微軟SQL Server資料庫的備份與還原 文/林郁翔 2008-03-30

備份和還原雖然是兩件事，但兩者是彼此相依存的。事實上，我們之所以備份資料庫，是為了將來發生萬一時，可以順利還原資料庫，所以要先思考企業適合用何種方式還原資料庫，再規畫備份策略。

    Database Backup/Restore Strategy
將資料庫複製儲存，當系統發生問題時，藉此恢復正常運作

對很多企業來說，儲存在資料庫內的資料是一項很重要的資產，當這些資料遺失或損壞時，會對公司造成很嚴重的損害，然而我們不論電腦或資料庫，很容易因為各種原因而損毀，像是火災、地震、人為不當操作，甚至是硬體故障等，有時候還會影響其他資訊系統運作。為了確保在第一時間快速回復正常，資料庫管理系統都會具備各種的備份與還原功能。

備份和還原雖然是兩件事，但兩者是彼此相依存的。事實上，我們之所以備份資料庫，是為了將來發生萬一時，可以順利還原資料庫，所以要先思考企業適合用何種方式還原資料庫，再規畫備份策略。當然，要先完成備份任務，才有資料提供系統執行還原工作。

以SQL Server 2005為例，資料庫備份的方式主要有完整備份、差異備份和交易記錄備份，前兩者的儲存的內容為資料，而第三種則是依據序號，保存使用中的記錄。它們的作用都是保護資料，但每種方式所儲存的資料也不盡相同，而且每種備份方式的還原方式也不太一樣。

除了上述備份類型外，SQL Server 2005亦可針對檔案群組或資料庫部份執行備份並還原，並且能透過鏡像備份功能，產生額外的備份複本；或者利用系統內建的快照功能，可快速記錄資料庫在某個時間點的狀態。

即使定期備份，讓資料庫還原在特定時間點，但實際上依然會與現階段的資料庫有些差異，因此在還原時，要先將目前的記錄結尾先備份出來，保存時間差內異動的資料。文⊙林郁翔

Full Backup/Restore
完整備份／復原
直接擷取資料庫內的所有資料，並完整複製一份，然後存到指定的儲存空間內。這種方式可以用來重建整個資料庫，但是儲存的資料量較大，備份的時間也很久，有些企業的資料庫完整備份內容高達1TB，且備份時間要花上一整天。

如果在備份工作中，某部份資料已經寫入儲存裝置，但之後內容又被修改，就會導致備份資料與資料庫內容不一致，所以企業大多會選擇在周末例假日，設定排程離線作業。

Different Backup/Restore
差異備份／復原
由於差異備份的範圍，是上一次完整備份後，所有變更過的資料。所以要使用差異備份，需要先建立完整備份，要復原時，也是需先將資料庫完整復原後，才能執行差異還原。這種方式的資料量與完整備份相比，容量較小，備份耗時也較少。

差異備份保存的資料，並不是累加式的。若在4月1日做好完整備份，並分別於2日和3日執行備份，差異備份內容是從1日到3日期間的資料異動，2、3兩天各自的差異內容。

Transaction Log Backup/Restore
交易記錄備份／復原
交易記錄備份的對象，是資料庫內使用中的記錄（Active Log），這裡面儲存是記錄，而非資料，也就是當使用者修改資料庫內容時，輸入確認（Commit）後的操作指令執行歷程。當任務完成後，會儲存備份過的記錄序號，待下次執行備份時，就會由上回備份完成的序號開始。

和差異備份相同，使用交易記錄備份之前，需要先建立好一個完整備份，才能以此方法復原資料庫。

Filegroup Backup/Restore
檔案群組備份／復原
這是針對完整備份的另一種替代備份策略。當我們在完整備份資料庫時，有些資料表並沒有異動，但依然會因此而浪費時間及儲存空間；而檔案群組備份則是將資料庫內的個別檔案分組，在備份時可以指定個別群組，而非整個資料庫。

基本上，要執行檔案群組備份還原策略有一些限制，需要有全部群組的備份資料，才能在資料庫損壞時，重組這些檔案以回復資料庫。

Partial Backup/Restore
部份備份／復原
這是一種完整備份的折衷策略，和檔案群組備份類似。在某些資料庫中，有部分資料表會設定為禁止寫入，稱為唯讀檔案群組，而部份備份作業執行時，則是會跳過所有唯讀群組，讓備份任務只複製那些可能有異動的範圍。

要使用部份還原，需要有完整備份的資料檔，或是搭配檔案群組備份，建立唯讀檔案群組的備份資料，才能確保整體資料庫的完整性。

Mirror Backup
鏡像備份
為了避免資料庫系統，與備份資料同時損毀的風險，有些備份策略會將製作出來的複本，再次複製並儲存到另一獨立媒體上，並藉此分散風險。在SQL Server 2005中，具備了鏡像備份功能，協助管理人員同時在多個儲存媒體上建立複本。

這種方式會限制儲存媒體類型，且裝置數量也要與鏡像數量相同，若是我們使用磁帶建立3組鏡像備份，那除了原來備份方式的磁帶裝置外，還得額外準備3組相同類型的裝置才行。

Snapshot
快照
在SQL Server 2005中，快照功能會擷取資料庫在某個時間點的狀態。但不同於完整備份複製所有資料庫，快照是透過寫入複製技術（Copy on Write），先在某時間點建立快照集，每當之後有資料有更動時，系統就會將該資料頁複製一份，並儲存起來；當我們要讀取快照內容時，SQL Server會從快照集內擷取異動資料，並參考資料庫其他內容，快速重現當時的情況。

LSN，Log Sequence Number
記錄序號
在SQL Server中，每筆交易記錄都有一組識別用的記錄序號，就像交易記錄表的主鍵。記錄序號是循序產生的，藉由該序號，系統即可辨識出交易記錄產生的先後順序。
當我們採用交易記錄備份時，就是參考這組序號，來判斷哪些資料已經備份，藉此做到差異化備份；而還原時，SQL Server也會參考這組序號，將每筆紀錄依序執行，並搭配完整備份資料復原資料庫。

Tail of The Log
記錄結尾
資料庫在運作中，一定會有些確認過、但尚未備份的交易記錄，這些內容就稱為記錄結尾。

不論備份次數多頻繁，運作中的資料庫皆會存在些許記錄結尾，當資料庫發生問題需要還原時，首先要做的，就是將記錄結尾備份起來，並在資料庫還原的最後階段，將這些記錄一起更新，以免過程中遺失這些最新的資料異動，如果資料庫還原時沒有任何交易記錄，也就不會有記錄結尾需要備份。