SQL Server事務 事務日誌

事務 (SQL Server)

1、事務概念
    事務是一種機制、是一種操做序列，它包含了一組數據庫操做命令，這組命令要麼所有執行，要麼所有不執行。所以事務是一個不可分割的工做邏輯單元。在數據庫系統上執行併發操做時事務是做爲最小的控制單元來使用的。這特別適用於多用戶同時操做的數據通訊系統。例如：訂票、銀行、保險公司以及證券交易系統等。
 
2、事務屬性
事務4大屬性：
1   原子性(Atomicity):事務是一個完整的操做。
2   一致性（Consistency）：當事務完成時，數據必須處於一致狀態。
3   隔離性(Isolation):對數據進行修改的全部併發事務是彼此隔離的。
4   持久性(Durability):事務完成後，它對於系統的影響是永久性的。
 
3、建立事務
T-SQL中管理事務的語句：
1 開始事務: begin transaction
2 提交事務：commit transaction
3 回滾事務: rollback transaction
 
事務分類:
1 顯式事務:用begin transaction明確指定事務的開始。
2 隱性事務：打開隱性事務：set implicit_transactions on，當以隱性事務模式操做時，SQL Servler將在提交或回滾事務後自動啓動新事務。沒法描述事務的開始，只須要提交或回滾事務。
3 自動提交事務：SQL Server的默認模式，它將每條單獨的T-SQL語句視爲一個事務。若是成功執行，則自動提交，不然回滾。

 

事務日誌 (SQL Server)

Tue Oct 03 2017

每一個 SQL Server 數據庫都有事務日誌，用於記錄全部事務以及每一個事務所作的數據庫修改。

事務日誌是數據庫的一個關鍵組件。 若是系統出現故障，你將須要依靠該日誌將數據庫恢復到一致的狀態。

重要

永遠不要刪除或移動此日誌，除非你徹底瞭解執行此操做的後果。

提示

檢查點會建立一些正常點，在數據庫恢復期間將從這些正常點開始應用事務日誌。 有關詳細信息，請參閱數據庫檢查點 (SQL Server)。

事務日誌支持的操做

事務日誌支持如下操做：

• 恢復個別的事務。

• 在 SQL Server 啓動時恢復全部未完成的事務。

• 將還原的數據庫、文件、文件組或頁前滾至故障點。

• 支持事務複製。

• 支持高可用性和災難恢復解決方案： AlwaysOn 可用性組、數據庫鏡像和日誌傳送。

恢復個別的事務

若是應用程序發出 ROLLBACK 語句，或者數據庫引擎檢測到錯誤（例如失去與客戶端的通訊），使用日誌記錄回退未完成的事務所作的修改。

在 SQL Server 啓動時恢復全部未完成的事務

當服務器發生故障時，數據庫可能處於這樣的狀態：尚未將某些修改從緩存寫入數據文件，在數據文件內有未完成的事務所作的修改。 啓動 SQL Server 實例時，它將對每一個數據庫執行恢復操做。 前滾日誌中記錄的、可能還沒有寫入數據文件的每一個修改。 在事務日誌中找到的每一個未完成的事務都將回滾，以確保數據庫的完整性。

將還原的數據庫、文件、文件組或頁前滾至故障點

在硬件丟失或磁盤故障影響到數據庫文件後，能夠將數據庫還原到故障點。 先還原上次完整數據庫備份和上次差別數據庫備份，而後將後續的事務日誌備份序列還原到故障點。

還原每一個日誌備份時，數據庫引擎將從新應用日誌中記錄的全部修改，前滾全部事務。 最後的日誌備份還原後，數據庫引擎將使用日誌信息回退到該點上未完成的全部事務。

支持事務複製

日誌讀取器代理程序監視已爲事務複製配置的每一個數據庫的事務日誌，並將已設複製標記的事務從事務日誌複製到分發數據庫中。 有關詳細信息，請參閱 事務複製的工做原理。

支持高可用性和災難恢復解決方案

備用服務器解決方案、AlwaysOn 可用性組、數據庫鏡像和日誌傳送極大程度上依賴於事務日誌。

在 AlwaysOn 可用性組方案中，數據庫的每一個更新（主要副本）在數據庫的完整且獨立的副本（次要副本）中直接再現。 主要副本直接將每一個日誌記錄發送到次要副本，這可將傳入日誌記錄應用到可用性組數據庫，並不斷前滾。 有關詳細信息，請參閱 AlwaysOn 故障轉移羣集實例

在日誌傳送方案中，主服務器將主數據庫的活動事務日誌發送到一個或多個目標服務器。 每一個輔助服務器將該日誌還原爲其本地的輔助數據庫。 有關詳細信息，請參閱 關於日誌傳送。

在數據庫鏡像方案中，數據庫（主體數據庫）的每次更新都在獨立的、完整的數據庫（鏡像數據庫）副本中當即從新生成。 主體服務器實例當即將每一個日誌記錄發送到鏡像服務器實例，鏡像服務器實例將傳入的日誌記錄應用於鏡像數據庫，從而將其繼續前滾。 有關詳細信息，請參閱 數據庫鏡像。

Transaction Log characteristics

SQL Server 數據庫引擎 事務日誌的特徵：

• 事務日誌是做爲數據庫中的單獨的文件或一組文件實現的。 日誌緩存與數據頁的緩衝區高速緩存是分開管理的，所以可在數據庫引擎中生成簡單、快速和功能強大的代碼。 有關詳細信息，請參閱事務日誌物理體系結構。
• 日誌記錄和頁的格式沒必要遵照數據頁的格式。
• 事務日誌能夠在幾個文件上實現。 經過設置日誌的 FILEGROWTH 值能夠將這些文件定義爲自動擴展。 這樣可減小事務日誌內空間不足的可能性，同時減小管理開銷。 有關詳細信息，請參閱 ALTER DATABASE (Transact-SQL)。
• 重用日誌文件中空間的機制速度快且對事務吞吐量影響最小。

事務日誌截斷

日誌截斷將釋放日誌文件的空間，以便由事務日誌從新使用。 必須按期截斷事務日誌，防止其佔滿分配的空間（絕對會！）。 幾個因素可能延遲日誌截斷，所以監視日誌大小很重要。 某些操做能夠最小日誌量進行記錄以減小其對事務日誌大小的影響。

日誌截斷可從 SQL Server 數據庫的邏輯事務日誌中刪除不活動的虛擬日誌文件，釋放邏輯日誌中的空間以便物理事務日誌重用這些空間。 若是事務日誌從不截斷，它最終將填滿分配給物理日誌文件的全部磁盤空間。

爲了不空間不足，除非因爲某些緣由延遲日誌截斷，不然將在如下事件後自動進行截斷：

• 簡單恢復模式下，在檢查點以後發生。

• 在完整恢復模式或大容量日誌恢復模式下，若是自上一次備份後生成檢查點，則在日誌備份後進行截斷（除非是僅複製日誌備份）。

  有關詳細信息，請參閱本主題後面的 可能延遲日誌截斷的因素。

備註

日誌截斷並不減少物理日誌文件的大小。 若要減小物理日誌文件的物理大小，則必須收縮日誌文件。 有關收縮物理日誌文件大小的信息，請參閱 Manage the Size of the Transaction Log File。

Factors that can delay log truncation

在日誌記錄長時間處於活動狀態時，事務日誌截斷將延遲，事務日誌可能填滿，這一點咱們在本主題（很長）前面提到過。

[!IMPORTANT} 有關如何響應已滿事務日誌的信息，請參閱解決事務日誌已滿的問題（SQL Server 錯誤 9002）。

實際上，日誌截斷會因爲多種緣由發生延遲。 查詢 sys.databases 目錄視圖的 log_reuse_wait 和 log_reuse_wait_desc 列，瞭解哪些因素（若是存在）阻止日誌截斷。 下表對這些列的值進行了說明。

log_reuse_wait 值	log_reuse_wait_desc 值	說明
0	NOTHING	當前有一個或多個可重複使用的虛擬日誌文件。
1	CHECKPOINT	自上第二天志截斷以後，還沒有生成檢查點，或者日誌頭還沒有跨一個虛擬日誌文件移動。 （全部恢復模式） 這是日誌截斷延遲的常見緣由。 有關詳細信息，請參閱數據庫檢查點 (SQL Server)。
2	LOG_BACKUP	在截斷事務日誌前，須要進行日誌備份。 （僅限完整恢復模式或大容量日誌恢復模式） 完成下一個日誌備份後，一些日誌空間可能變爲可重複使用。
3	ACTIVE_BACKUP_OR_RESTORE	數據備份或還原正在進行（全部恢復模式）。 若是數據備份阻止了日誌截斷，則取消備份操做可能有助於解決備份直接致使的此問題。
4	ACTIVE_TRANSACTION	事務處於活動狀態（全部恢復模式）： 一個長時間運行的事務可能存在於日誌備份的開頭。 在這種狀況下，可能須要進行另外一個日誌備份才能釋放空間。 請注意，長時間運行的事務將阻止全部恢復模式下的日誌截斷，包括簡單恢復模式，在該模式下事務日誌通常在每一個自動檢查點截斷。 延遲事務。 「延遲的事務 」是有效的活動事務，由於某些資源不可用，其回滾受阻。 有關致使事務延遲的緣由以及如何使它們擺脫延遲狀態的信息，請參閱延遲的事務 (SQL Server)。 長時間運行的事務也可能會填滿 tempdb 的事務日誌。 Tempdb 由用戶事務隱式用於內部對象，例如用於排序的工做表、用於哈希的工做文件、遊標工做表，以及行版本控制。 即便用戶事務只包括讀取數據（SELECT 查詢），也可能會以用戶事務的名義建立和使用內部對象， 而後就會填充 tempdb 事務日誌。
5	DATABASE_MIRRORING	數據庫鏡像暫停，或者在高性能模式下，鏡像數據庫明顯滯後於主體數據庫。 （僅限完整恢復模式） 有關詳細信息，請參閱數據庫鏡像 (SQL Server)。
6	REPLICATION	在事務複製過程當中，與發佈相關的事務仍未傳遞到分發數據庫。 （僅限完整恢復模式） 有關事務複製的信息，請參閱 SQL Server Replication。
7	DATABASE_SNAPSHOT_CREATION	正在建立數據庫快照。 （全部恢復模式） 這是日誌截斷延遲的常見緣由，一般也是主要緣由。
8	LOG_SCAN	發生日誌掃描。 （全部恢復模式） 這是日誌截斷延遲的常見緣由，一般也是主要緣由。
9	AVAILABILITY_REPLICA	可用性組的輔助副本正將此數據庫的事務日誌記錄應用到相應的輔助數據庫。 （完整恢復模式） 有關詳細信息，請參閱：AlwaysOn 可用性組概述 (SQL Server)。
10	—	僅供內部使用
11	—	僅供內部使用
12	—	僅供內部使用
13	OLDEST_PAGE	若是將數據庫配置爲使用間接檢查點，數據庫中最先的頁可能比檢查點 LSN 早。 在這種狀況下，最先的頁能夠延遲日誌截斷。 （全部恢復模式） 有關間接檢查點的信息，請參閱數據庫檢查點 (SQL Server)。
14	OTHER_TRANSIENT	當前未使用此值。

可儘可能減小日誌量的操做

最小日誌記錄是指只記錄在不支持時間點恢復的狀況下恢復事務所需的信息。 本主題介紹在大容量日誌恢復模式下（以及簡單恢復模式下）按最小方式記錄、但在運行備份時例外的操做。

備註

內存優化表不支持最小日誌記錄。

備註

在完整 恢復模式下，全部大容量操做都將被完整地記錄下來。 可是，能夠經過將數據庫暫時切換到用於大容量操做的大容量日誌恢復模式，最小化一組大容量操做的日誌記錄。 最小日誌記錄比完整日誌記錄更爲有效，並在大容量事務期間，下降了大規模大容量操做填滿可用的事務日誌空間的可能性。 不過，若是在最小日誌記錄生效時數據庫損壞或丟失，則沒法將數據庫恢復到故障點。

下列操做在完整恢復模式下執行完整日誌記錄，而在簡單和大容量日誌恢復模式下按最小方式記錄日誌：

• 批量導入操做（bcp、BULK INSERT 和 INSERT...SELECT）。 有關在什麼時候對大容量導入表按最小方式進行記錄的詳細信息，請參閱 Prerequisites for Minimal Logging in Bulk Import。

啓用事務複製時，將徹底記錄 BULK INSERT 操做，即便處於大容量日誌恢復模式下。

• SELECT INTO 操做。

啓用事務複製時，將徹底記錄 SELECT INTO 操做，即便處於大容量日誌恢復模式下。

• 插入或追加新數據時，使用 UPDATE 語句中的 .WRITE 子句部分更新到大型值數據類型。 注意，在更新現有值時沒有使用最小日誌記錄。有關大型值數據類型的詳細信息，請參閱數據類型 (Transact-SQL)。

• 在UPDATETEXT 、 nUPDATETEXT 和 UPDATETEXT, nUPDATETEXT, 、 UPDATETEXT 語句。 注意，在更新現有值時沒有使用最小日誌記錄。

  重要

  不推薦使用 WRITETEXT 語句和 UPDATETEXT 語句，應該避免在新的應用程序中使用這些語句。

• 若是數據庫設置爲簡單或大容量日誌恢復模式，則不管是脫機仍是聯機執行操做，都會按最小方式記錄一些索引 DDL 操做。 按最小方式記錄的索引操做以下：

  • CREATE INDEX 操做（包括索引視圖）。

  • ALTER INDEX REBUILD 或 DBCC DBREINDEX 操做。

    重要

    不推薦使用「DBCC DBREINDEX 語句」；請不要在新的應用程序中使用該語句。

  • DROP INDEX 新堆從新生成（若是適用）。 （ DROP INDEX 操做期間將 始終 完整記錄索引頁的釋放操做。）