推薦：關于避免在 PL/SQL 中使用嵌套游標查詢
考慮下面的 PL/SQL 代碼，這段代碼生成一個 XML 格式的矩陣樣式的報表： 以下為引用的內容： 　　declare 　　l_count　　 intege

問題

在管理SQL Server時首先要做的一件事是建立一個合適的備份計劃以便將失敗事件中任何數據的丟失可能最小化。建立備份計劃之后當然要做些數據庫配置，這些配置是建立以確保你可以正確地備份數據庫。在這篇文章里我們將看看SQL Server所提供的不同恢復模型以及怎樣為你的數據庫選擇恢復模型。

專家解答

對于SQL Server 2000和2005，Microsoft為你的數據庫提供了三個不同的恢復模型。在你的服務器上，每個數據庫可以建立得各不相同，而且你還可以根據需要改變恢復模型，所以這個選擇不是永久不變的。

這三個恢復模型是：

Simple(簡單)

簡單恢復模型就如同它名字所顯示的，它為你提供了簡單的備份，可以在失敗或者如果你需要恢復你的數據庫到另一個服務器上的情況下用來替代你的整個數據庫。有了這個恢復模型你就具有了完成完全備份(整個復制)或不同備份(從上一個完全備份之后所做的任何改變)的能力。使用這個恢復模型你就暴露于自從上一次的備份之后的任何失敗。下面是你可以選擇這個恢復模型的原因：

你的數據不重要或很容易重新創(chuàng)建。

這個數據庫只用于測試或開發(fā)。

數據是靜態(tài)的并且不會改變。

在上一次備份之后丟失任何或所有事務都是沒關系的。

數據是獲取的并且很容易重新創(chuàng)建。

你可以運行的備份類型：

完全備份

差分備份

文件和/或文件組備份

部分備份

Copy-Only(僅復制)備份

Bulk_Logged(批日志)

批日志恢復如同它名字所示。有了這個模型，那么相當一部分的批操作例如BULK INSERT、CREATE INDEX、SELECT INTO等等就不會完全記錄到事務日志中，從而不會占據事務日志那么大的空間。使用這個恢復模型的優(yōu)點是如果你進行批操作你的事務日志也不會變得那么大，而且你還可以進行時間點恢復，只要你的最后一次事務日志備份不包括上面提到的批操作。如果沒有運行批操作，那么這個恢復模型就如同完全恢復模型一樣。要注意的一件事是如果你使用這個恢復模型，那么你還需要進行事務日志備份，否則你的數據庫事務日志將不斷地擴大。下面是你可能選擇這個恢復模型的原因：

數據很重要，但是你不想在日志中記錄大量批操作。

批操作與普通操作在不同的時間進行。

你仍然希望可以恢復到某時間點上。

你可以運行的備份類型有：　　

完全備份

差分備份

文件和/或文件組備份

部分備份

Copy-Only(僅復制)備份

事務日志備份　　　

Full(完全)

完全恢復模型是最完全的恢復模型，并且允許你將所有數據恢復到任何時間點上，只要所有的備份文件是可用的。有了這個模型，所有的操作都會被完整地記錄到日志里，這意味著你可以恢復你的數據庫到任何時間點上。此外，如果數據庫設置為完全恢復模型，那么你還需要進行事務日志備份，否則你的數據庫事務日志將一直不斷地擴大。下面是你可能選擇這個恢復模型的原因：

分享：解讀用最簡單的步驟備份SQL數據庫的文件到本地
用最簡單的步驟備份sql數據庫的文件到本地: 以下為引用的內容： 　　response.Charset = utf-8 　　Session.Codepage = 65001