❶ sql server需要做日誌備份嗎
請按步驟進行,未進行前面的步驟,請不要做後面的步驟
否則可能損壞你的資料庫.
一般不建議做第4,6兩步
第4步不安全,有可能損壞資料庫或丟失數據
第6步如果日誌達到上限,則以後的資料庫處理會失敗,在清理日誌後才能恢復.
--*/
--下面的所有庫名都指你要處理的資料庫的庫名
1.清空日誌
DUMP TRANSACTION 庫名 WITH NO_LOG
2.截斷事務日誌：
BACKUP LOG 庫名 WITH NO_LOG
3.收縮資料庫文件(如果不壓縮,資料庫的文件不會減小
企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件
--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
--選擇數據文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
也可以用SQL語句來完成
--收縮資料庫
DBCC SHRINKDATABASE(庫名)
--收縮指定數據文件,1是文件號,可以通過這個語句查詢到:select * from sysfiles
DBCC SHRINKFILE(1)
4.為了最大化的縮小日誌文件(如果是sql 7.0,這步只能在查詢分析器中進行)
a.分離資料庫:
企業管理器--伺服器--資料庫--右鍵--分離資料庫
b.在我的電腦中刪除LOG文件
c.附加資料庫:
企業管理器--伺服器--資料庫--右鍵--附加資料庫
此法將生成新的LOG，大小隻有500多K
或用代碼：
下面的示例分離 pubs，然後將 pubs 中的一個文件附加到當前伺服器。
a.分離
EXEC sp_detach_db @dbname = '庫名'
b.刪除日誌文件
c.再附加
EXEC sp_attach_single_file_db @dbname = '庫名',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\庫名.mdf'
5.為了以後能自動收縮,做如下設置:
企業管理器--伺服器--右鍵資料庫--屬性--選項--選擇"自動收縮"
--SQL語句設置方式:
EXEC sp_dboption '庫名', 'autoshrink', 'TRUE'
6.如果想以後不讓它日誌增長得太大
企業管理器--伺服器--右鍵資料庫--屬性--事務日誌
--將文件增長限制為xM(x是你允許的最大數據文件大小)
--SQL語句的設置方式:
alter database 庫名 modify file(name=邏輯文件名,maxsize=20)
❷ 如何快速掌握SQL Server中的日誌轉移
如何快速掌握SQL Server中的日誌轉移
集群是一種實現高可用性的有效解決方案，有時它會適得其反。而且，它還非常昂貴。因此，資料庫管理員可使用日誌轉移代替集群來提供較高的可用性。
日誌轉移是這樣一種處理過程，它能將某一資料庫中的事務日誌文件依次轉存到備份的資料庫中，進而為這一資料庫創建一個「近乎」熱備份。SQL Server 2000的資料庫引擎中設置了日誌轉移功能，並在其中進行處理。所以它會自動完成復原到備份伺服器的進程，而不需要資料庫管理員手動操作。只有你的產品伺服器操作失敗，你才需手動完成到備份伺服器的復原進程。(注釋：盡管SQL Server 7.0和2005中均有日誌轉移功能，但本文主要針對SQL Server 2000。)
為什麼要使用日誌轉移?
日誌轉移是一種解決高可用性的措施，並且十分有效。同樣作為高可用性的措施方案，日誌轉移相對集群來說，最大的.好處是它要便宜許多。這是因為，使用集群功能有硬體要求，而日誌轉移則不需要。
日誌轉移在資料庫與資料庫而非伺服器與伺服器之間進行;因此才有可能將備份資料庫存儲在你已用作其他用途的伺服器上。但如果轉移失敗則有可能會出現問題，這時你可換用備份資料庫，這種選擇是可用的。
日誌轉移相對比較容易安裝。SQL Server提供了非常完善的向導幫助你安裝這個進程。
日誌轉移允許你保存分布在不同地理位置中的冗餘數據，SQL Server的集群功能則很難做到這一點。這一特點十分出眾，因為，當你的數據中心遭到災難時，你仍能在備份伺服器中將其恢復過來。而在相同的數據中心，如果你使用的是集群功能，你就會陷入麻煩。
日誌轉移的另一優點是你能將備份資料庫作為報告資料庫使用，這對許多公司來說是很不錯的選擇。但如果你決定了用這個備份資料庫作報告使用，就必須注意它的局限性。使用原始資料庫中的日誌時，SQL Server 要求指定唯一的通道，所以，當日誌文件正在被應用時，報告則不能同時進行。
使用日誌轉移要考慮的相關因素
在將日誌轉移作為高可用性的方案來使用時，我們必須考慮以下幾點因素。由於從原始資料庫到備份資料庫有一個潛伏期，對你的公司而言，它並非一定是可行的實現高可用性的一種解決方案。潛伏期由資料庫管理員設置，時間也因需要而縮短, 但永遠不能避免。
日誌轉移中沒有設置恢復功能，這就意味著在將日誌轉移到備份伺服器上時，這些日誌都暫時不可用。因此，資料庫管理員必須在將備份資料庫放到網上前完成一系列的操作，這些步驟包括:
將已存儲在備份數據伺服器上原始資料庫里的備份標簽存儲起來。一旦所有的標簽被存儲後，資料庫就必須得到恢復，然後放到網上。
一旦所有的資料庫都已放在網上，所有需要訪問資料庫的應用程序就需要改變自身的鏈接。如果你不能將應用程序盡快指向剛剛恢復的資料庫，你就前功盡棄了。
一個SQL Server的實例能用於監控日誌轉移。這個實例可以在原始資料庫、備份資料庫或單獨的資料庫中。任何一種版本的SQL Server都能用於SQL Server監控。
注釋：資料庫登錄必須在原始資料庫與備份資料庫之間同時進行。
;❸ MS SQL SERVER 如何做日誌備份和還原。
備份一個事務日誌：
BACKUP LOG { database_name | @database_name_var }
{
TO < backup_device > [ ,...n ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]
[ [ , ] DESCRIPTION = { 'text' | @text_variable } ]
[ [ ,] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] FORMAT | NOFORMAT ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] MEDIADESCRIPTION = { 'text' | @text_variable } ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] NO_TRUNCATE ]
[ [ , ] { NORECOVERY | STANDBY = undo_file_name } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage ] ]
]
}
還原事務日誌：
RESTORE LOG { database_name | @database_name_var }
[ FROM < backup_device > [ ,...n ] ]
[ WITH
[ RESTRICTED_USER ]
[ [ , ] FILE = { file_number | @file_number } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] MOVE 'logical_file_name' TO 'operating_system_file_name' ]
[ ,...n ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] KEEP_REPLICATION ]
[ [ , ] { NORECOVERY | RECOVERY | STANDBY = undo_file_name } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [= percentage ] ]
[ [ , ] STOPAT = { date_time | @date_time_var }
| [ , ] STOPATMARK = 'mark_name' [ AFTER datetime ]
| [ , ] STOPBEFOREMARK = 'mark_name' [ AFTER datetime ]
]
]
例如：restore log dbname from disk='filename'
❹ sql server 2014日誌備份怎樣恢復
NORECOVERY
指定不發生回滾。
從而使前滾按順序在下一條語句中繼續進行。
在這種情況下，還原順序可還原其他備份，並執行前滾。
RECOVERY（默認值）表示，應在完成當前備份前滾之後執行回滾。
恢復資料庫要求要還原的整個數據集（「前滾集」）必須與資料庫一致。
如果前滾集尚未前滾到與資料庫保持一致的地步，並且指定了
RECOVERY，則資料庫引擎將發出錯誤。
也就是說，你還原一個文件後，後續還有文件要還原，就要使用NORECOVERY，如果後續沒有文件，或是你不想還原後續的文件，就使用recovery。
如果你要還原事務日誌，首先你要有一個完整備份，先還原完整備份，並使用NORECOVERY選項，然後，按順序還原日誌備份。只要後續還有文件要還原，就使用NORECOVERY選項，如果後續沒有文件或是不想再還原其他文件了，就使用RECOVERY選項。使用RECOVERY選項後，還原過程就完成了，資料庫就可以使用了。
❺ sql2008怎麼備份日誌文件
一、 結尾日誌備份的含義。
由於結尾日誌備份是SQLServer資料庫特有的一個內容。所以對於從其他資料庫轉型過來的管理員可能並不了解這個結尾日誌備份的含義。在大多數情況下，如在完成恢復模式或者大容量日誌恢復模式下，SQLServer資料庫要求管理員備份事務日誌的結尾部分以獲得尚未備份的日誌記錄。這個在還原操作之前對日誌尾部執行的日誌備份就叫做結尾日誌備份。對於SQLServer資料庫來說，在事務日誌恢復之前進行事務日誌的尾部備份是非常必要的。因為結尾日誌備份作業可以防止用戶修改數據的丟失並最終確保日誌鏈的完整性。在利用事務日誌將資料庫恢復到某一個指定的點，如資料庫故障點的時候，結尾日誌備份是恢復計劃中的最後一個相關備份。如果在還原之前無法備份日誌的尾部，那麼就只能夠將資料庫恢復為故障發生之前創建的最後一個備份。而不能夠恢復到故障發生的那一點。所以說，結尾日誌備份對於SQLServer資料庫非常的重要。
二、 在何時該進行結尾日誌備份?
從結尾日誌備份的含義中，我們也可以看出，並不是在任何情況下都需要作結尾日誌備份。也就是說，對於SQLServer資料庫來說，並非所有的還原方案都需要執行結尾日誌部分。如在資料庫恢復的時候，不需要恢復到故障的那一點，就不需要進行結尾日誌備份。同理，如果先前的日誌備份中已經包含了恢復點，或者說管理員准備覆蓋某個資料庫或者移動資料庫的時候，往往不需要進行結尾日誌備份。另外需要的是，在某些特定情況下即使資料庫管理員想進行事務日誌尾部備份都不行。如當事務日誌文件已經損壞時就無法繼續進行事務日誌尾部備份。此時雖然資料庫管理員任人可以在不使用結尾日誌備份的情況下恢復資料庫，但是已經不能夠恢復到故障發生的那一點。也就是說，最新日誌備份後進行的任何數據修改工作與資料庫結構調整工作都回丟失。
具體的來說，如果遇到如下兩種情況，需要先對馬上對事務日誌進行尾部備份。
一是需要對資料庫進行還原操作，而且是要還原到最近到的一個點時，那麼需要先對資料庫進行事務日誌尾部備份。即在資料庫處於聯機狀態時，如果資料庫管理員需要對資料庫進行的下一個操走就是還原操作，那麼就需要在還原操作之前進行事務日誌尾部備份。也就是說，在還原操作之前才能夠進行事務日誌尾部備份，即在事務日誌備份備份與資料庫還原之間不能夠再進行任何的資料庫修改作業。否則的話在還原後這個修改會丟失。另外需要注意的是，為了出現一些不必要的錯誤，最好在備份事務尾部日誌的時候，採用NORECOVERY選項。這個選項主要是為了確保資料庫事務日誌尾部備份之後資料庫不能夠再被修改。也就是說，可以保證事務日誌尾部備份到資料庫還原中間的時間間隔之內，不再發生任何的資料庫更改作業。以確保在利用事務日誌尾部備份進行資料庫還原的時候，能夠還原到一個最近的時點。而不會有任何數據的丟失。這是在最正常的情況下對事務日誌的尾部進行備份。
❻ sql server 2000 日誌備份
日誌處理方法:
/*--特別注意
請按步驟進行,未進行前面的步驟,請不要做後面的步驟
否則可能損壞你的資料庫.
一般不建議做第4,6兩步
第4步不安全,有可能損壞資料庫或丟失數據
第6步如果日誌達到上限,則以後的資料庫處理會失敗,在清理日誌後才能恢復.
--*/
--下面的所有庫名都指你要處理的資料庫的庫名
1.清空日誌
DUMP TRANSACTION 庫名 WITH NO_LOG
2.截斷事務日誌：
BACKUP LOG 庫名 WITH NO_LOG
3.收縮資料庫文件(如果不壓縮,資料庫的文件不會減小
企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件
--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
--選擇數據文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
也可以用SQL語句來完成
--收縮資料庫
DBCC SHRINKDATABASE(庫名)
--收縮指定數據文件,1是文件號,可以通過這個語句查詢到:select * from sysfiles
DBCC SHRINKFILE(1)
4.為了最大化的縮小日誌文件(如果是sql 7.0,這步只能在查詢分析器中進行)
a.分離資料庫:
企業管理器--伺服器--資料庫--右鍵--分離資料庫
b.在我的電腦中刪除LOG文件
c.附加資料庫:
企業管理器--伺服器--資料庫--右鍵--附加資料庫
此法將生成新的LOG，大小隻有500多K
或用代碼：
下面的示例分離 pubs，然後將 pubs 中的一個文件附加到當前伺服器。
a.分離
EXEC sp_detach_db @dbname = '庫名'
b.刪除日誌文件
c.再附加
EXEC sp_attach_single_file_db @dbname = '庫名',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\庫名.mdf'
5.為了以後能自動收縮,做如下設置:
企業管理器--伺服器--右鍵資料庫--屬性--選項--選擇"自動收縮"
--SQL語句設置方式:
EXEC sp_dboption '庫名', 'autoshrink', 'TRUE'
6.如果想以後不讓它日誌增長得太大
企業管理器--伺服器--右鍵資料庫--屬性--事務日誌
--將文件增長限制為xM(x是你允許的最大數據文件大小)
--SQL語句的設置方式:
alter database 庫名 modify file(name=邏輯文件名,maxsize=20)