SQL Server 2008 事務日誌備份注意事項
1.事務處理及其日誌
SQL Server使用事務來跟蹤所有資料庫變化。事務是SQL Server的工作單元。一個事務包含一條或多條作為整體成功或失敗的T_SQL語句。每個資料庫都有自己的事務日誌,即系統表syslogs,事務日誌自動記錄每個使用者發出的每個事務,它飲食了每個事務足夠多的資訊,以確保資料能夠被恢復。
2.檢查點(CheckPoint)
伺服器在何時更新資料?
——在檢查點。在伺服器發出一個檢查點時:(1)更新資料;(2)在日誌中記錄下執行檢查點的標記。
檢查點可把所有“髒頁”寫到資料庫裝置上,“髒頁”是指從上一次檢查點以來,在記憶體中修改、但沒有在磁碟上修改的頁。SQL Server的自動檢查點機制保證了被完成的事務修改的資料頁有規律地從記憶體中的緩衝區寫到資料庫裝置上。
二、資料庫備份
若硬體介質出現故障(如磁碟損壞),當且僅當事先已對資料庫及其事務日誌作了備份,才能恢復資料庫。
注意:絕對不要使用作業系統的複製資料庫裝置,把這樣一個複製裝入SQL Server將導致大量資料庫受損。
備份的型別:
完全備份()
增量備份——備份事務處理日誌
說明:
(1)只有把事務日誌放在單獨的裝置上,才能進行增量備份;
(2)備份事務日誌會截斷日誌,因此備份的內容是自上次備份以來的事務處理。
(3)備份之前要啟動備份伺服器,並最好建立轉儲裝置。
命令語法:
dump database 資料庫名
to 轉儲裝置名/物理檔名
dump transaction 資料庫名
{with {truncate_only|no_log}
to 轉儲裝置名/物理檔名
[with No_truncate]
Truncate_only與no_log選項用於刪除事務處理而不作複製。Truncate_only截斷日誌;在事務處理日誌完全滿時用no_log,它不為資料庫建立檢查點。兩個選項都會丟掉日誌。當使用了這兩個引數後,應及時備份整個資料庫。
No_truncate複製日誌但不截斷日誌,在出現介質錯誤時使用該選項。
圖形介面的選項與命令引數的對應關係:
(1)dump transaction (2)dump transaction…… with no_truncate
(3)dump transaction…… with truncate_only
(4)dump transaction…… with no_log
三、資料庫的恢復
使用load database載入備份到現有資料庫,資料庫可以是用於建立轉儲的資料庫,也可以不是。語法為:
load database 資料庫名 from 轉儲裝置名/物理檔名
load transaction資料庫名 from 轉儲裝置名/物理檔名
●利用備份恢復資料庫舉例:
某資料庫資料和日誌分別儲存在兩個獨立的磁碟上,正常運轉時的執行的備份計劃如下,每天的17:00執行整個資料庫的備份,每天的10:00、12:00、14:00、16:00點執行增量備份:
週一17:00磁帶1(100M)週二10:00磁帶2(30M)週二12:00磁帶3(30M)週二14:00磁帶4(30M)週二16:00磁帶5(30M)週二17:00磁帶6(30M)
SQL Server使用事務來跟蹤所有資料庫變化。事務是SQL Server的工作單元。一個事務包含一條或多條作為整體成功或失敗的T_SQL語句。每個資料庫都有自己的事務日誌,即系統表syslogs,事務日誌自動記錄每個使用者發出的每個事務,它飲食了每個事務足夠多的資訊,以確保資料能夠被恢復。
2.檢查點(CheckPoint)
伺服器在何時更新資料?
——在檢查點。在伺服器發出一個檢查點時:(1)更新資料;(2)在日誌中記錄下執行檢查點的標記。
檢查點可把所有“髒頁”寫到資料庫裝置上,“髒頁”是指從上一次檢查點以來,在記憶體中修改、但沒有在磁碟上修改的頁。SQL Server的自動檢查點機制保證了被完成的事務修改的資料頁有規律地從記憶體中的緩衝區寫到資料庫裝置上。
二、資料庫備份
若硬體介質出現故障(如磁碟損壞),當且僅當事先已對資料庫及其事務日誌作了備份,才能恢復資料庫。
注意:絕對不要使用作業系統的複製資料庫裝置,把這樣一個複製裝入SQL Server將導致大量資料庫受損。
備份的型別:
完全備份()
增量備份——備份事務處理日誌
說明:
(1)只有把事務日誌放在單獨的裝置上,才能進行增量備份;
(2)備份事務日誌會截斷日誌,因此備份的內容是自上次備份以來的事務處理。
(3)備份之前要啟動備份伺服器,並最好建立轉儲裝置。
命令語法:
dump database 資料庫名
to 轉儲裝置名/物理檔名
dump transaction 資料庫名
{with {truncate_only|no_log}
to 轉儲裝置名/物理檔名
[with No_truncate]
Truncate_only與no_log選項用於刪除事務處理而不作複製。Truncate_only截斷日誌;在事務處理日誌完全滿時用no_log,它不為資料庫建立檢查點。兩個選項都會丟掉日誌。當使用了這兩個引數後,應及時備份整個資料庫。
No_truncate複製日誌但不截斷日誌,在出現介質錯誤時使用該選項。
圖形介面的選項與命令引數的對應關係:
(1)dump transaction (2)dump transaction…… with no_truncate
(3)dump transaction…… with truncate_only
(4)dump transaction…… with no_log
三、資料庫的恢復
使用load database載入備份到現有資料庫,資料庫可以是用於建立轉儲的資料庫,也可以不是。語法為:
load database 資料庫名 from 轉儲裝置名/物理檔名
load transaction資料庫名 from 轉儲裝置名/物理檔名
●利用備份恢復資料庫舉例:
某資料庫資料和日誌分別儲存在兩個獨立的磁碟上,正常運轉時的執行的備份計劃如下,每天的17:00執行整個資料庫的備份,每天的10:00、12:00、14:00、16:00點執行增量備份:
週一17:00磁帶1(100M)週二10:00磁帶2(30M)週二12:00磁帶3(30M)週二14:00磁帶4(30M)週二16:00磁帶5(30M)週二17:00磁帶6(30M)
DumpdatabaseDumptransactionDumptransactionDumptransactionDumptransactionDumpdatabase
若資料磁碟在週二的下午六點損壞,可以採用如下步驟恢復資料庫:
(1)使用dump transaction with no_truncate獲得當前的事務日誌轉儲,磁帶7;
(2)使用load database轉載最新的資料庫轉儲,磁帶6;(offline)
(3)使用load transaction提交最新的事務日誌轉儲,磁帶7;
(4)使用online database把資料庫狀態設定為online。
若資料磁碟在週二的下午4:50損壞,恢復過程如下:
(1)使用dump transaction with no_truncate獲得當前的事務日誌轉儲,磁帶7;
(2)使用load database轉載最新的資料庫轉儲,磁帶6;(offline)
(3)使用load transaction依次裝載磁帶2、3、4、5上的事務日誌;
(4)使用load transaction提交最新的事務日誌轉儲,磁帶7;
(5)使用online database把資料庫狀態設定為online。
四、制定備份與恢復的策略
由於事務日誌在恢復資料庫中的特殊作用,應定期備份資料庫及其事務日誌,而且事務日誌的備份要更頻繁一些。如:資料庫每週備份一次,事務日誌每天備份一次。
若資料磁碟在週二的下午六點損壞,可以採用如下步驟恢復資料庫:
(1)使用dump transaction with no_truncate獲得當前的事務日誌轉儲,磁帶7;
(2)使用load database轉載最新的資料庫轉儲,磁帶6;(offline)
(3)使用load transaction提交最新的事務日誌轉儲,磁帶7;
(4)使用online database把資料庫狀態設定為online。
若資料磁碟在週二的下午4:50損壞,恢復過程如下:
(1)使用dump transaction with no_truncate獲得當前的事務日誌轉儲,磁帶7;
(2)使用load database轉載最新的資料庫轉儲,磁帶6;(offline)
(3)使用load transaction依次裝載磁帶2、3、4、5上的事務日誌;
(4)使用load transaction提交最新的事務日誌轉儲,磁帶7;
(5)使用online database把資料庫狀態設定為online。
四、制定備份與恢復的策略
由於事務日誌在恢復資料庫中的特殊作用,應定期備份資料庫及其事務日誌,而且事務日誌的備份要更頻繁一些。如:資料庫每週備份一次,事務日誌每天備份一次。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28371090/viewspace-1664494/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 關於mysqldump備份非事務表的注意事項MySql
- SQL Server 表分割槽注意事項HXSQLServer
- SQL 語句的注意事項SQL
- SQLServer 2008中事務日誌已滿問題處理SQLServer
- MySQL 事務日誌MySql
- SQL登入失敗注意事項SQL
- 在SQL Server上測試事務日誌的自動增長(三)QOSQLServer
- 在SQL Server上測試事務日誌的自動增長(二)TGSQLServer
- 在SQL Server上測試事務日誌的自動增長(一)JPSQLServer
- sql server中巢狀事務*SQLServer巢狀
- Elasticsearch 的事務日誌Elasticsearch
- SQL Server中事務日誌自動增長對效能的影響(下)PGSQLServer
- SQL Server中事務日誌自動增長對效能的影響(上)OSSQLServer
- netcore後臺任務注意事項NetCore
- MySQL5.7 透過邏輯備份遷移到GreatSQL注意事項MySql
- RandomAccessFile注意事項randomMac
- @Lombok注意事項Lombok
- ERP選型準備、方法及注意事項
- Oracle vs PostgreSQL,研發注意事項(6)- 事務處理OracleSQL
- 函式注意事項函式
- 生產注意事項
- 電量注意事項
- CSP 考前注意事項
- 快取注意事項快取
- Mysql 事務日誌(Ib_logfile)MySql
- zookeeper 清理snapshot及事務日誌
- 11.日誌和事務@Transactional
- MySQL-14.MySQL事務日誌MySql
- Windows 11 & Server 2022 HLK kit WHQL認證注意事項WindowsServer
- 阿里雲初次備案全流程及注意事項阿里
- [爬坑日誌1]寫查詢的mysql一些小注意事項MySql
- SQLServer2012備份事務日誌報錯:讀取失敗: 1(函式不正確。)SQLServer函式
- SQL Server中存在真正的“事務巢狀”SQLServer巢狀
- SQL事務SQL
- Oracle vs PostgreSQL,研發注意事項(2)-DDL語句與事務OracleSQL
- TransactionScope事務處理方法介紹及.NETCore中的注意事項NetCore
- 安裝並使用 Ubuntu Server 的一些注意事項UbuntuServer
- 《MySQL 進階篇》十九:事務日誌MySql
- 部署專案注意事項