當前位置:首頁 » 編程語言 » sqlserver日誌回滾
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

sqlserver日誌回滾

發布時間: 2023-04-05 16:52:49

㈠ 如何查詢sqlserver 2000操作日誌

你好!

1.如果要看日誌內容,sql server下不直接支持,但是可以用LogExplorer(只支持2000)等工具來查看
如果你的意思是想看資料庫在執行什麼語句,可以用Sql profiler
菜單 Tool->Sql Server Profiler
進到Profiler的界面後新建一個跟蹤(new Trace),選擇好你的資料庫和相應的用戶、密碼,然後就可以看到所有傳到Sql Server來執行的語句了。
如果想更多的了解,可以去找些 Sql Server Profiler的資料看下,最好還是自己試幾下,操作很簡單,但是平時開發過程中調試很好用

2.每個 Microsoft® SQL Server™ 2000 資料庫都有事務日誌,用以記錄所有事務和每個事務對資料庫所做的修改。記錄事務及其修改有三個作用:
恢復個別的事務。
如果應用程序發出 ROLLBACK 語句,或者 SQL Server 檢測到錯誤(例如失去與客戶端的通訊),就使用日誌記錄回滾未完成的事務所做的修改。
SQL Server 啟動時恢復所有未完成的事務。
當運行 SQL Server 的伺服器發生故障時,資料庫可能處於這樣的狀態:還沒有將修改從高速緩沖存儲器寫入數據文件,在數據文件內有未完成的事務所做的修改。當啟動 SQL Server 的復本時,它對每個資料庫執行恢復操作。前滾日誌中記錄的、可能尚未寫入數據文件的每個修改。然後回滾在事務日誌中找到的每個未完成的事務,以確保資料庫的完整性。
將還原的資料庫前滾到故障點。
丟失資料庫(在沒有 RAID 驅動器的伺服器上,硬碟驅動器出現故障時可能會出現這種情況)後,可以將資料庫還原到故障點。首先還原上一次的完整資料庫備份或差異資料庫備份,然後將事務日誌備份序列還原到故障點。當還原每個日誌備份時,SQL Server 重新應用日誌中記錄的所有修改以前滾所有事務。當最後的日誌備份還原後,SQL Server 將使用日誌信息回滾到該點未完成的所有事務。
SQL Server 2000 事務日誌的特點是:
事務日誌不是作為一個表實現,而是作為單獨的文件或資料庫內的一組文件實現。日誌高速緩存與數據頁的高速緩沖存儲器分開管理,從而使資料庫引擎內的編碼更簡單、更快速和更可靠。
日誌記錄和頁的格式不必遵守數據頁的格式。
事務日誌可以在幾個文件上實現。可以根據需要定義這些文件為自動增長。這樣可減少事務日誌內空間不足的可能性,同時減少管理開銷。
截斷日誌中未用部分的機制速度快且對事務吞吐量影響最小。

㈡ SQL Server 快速清除日誌文件的方法

SQL Server 2000快速清除日誌文件的方法

SQL Server 2000 資料庫日誌太大!

如何清理SQL Server 2000的日誌呢?

如何壓縮SQL Server 2000的日誌呢?

如何讓SQL Server 2000的日誌變小呢?

據我所知,辦法有很多很多,總結起來算有3類吧:

1、點幾下滑鼠,用SQL Server 2000管理工具中的企業管理器即可實現,待會兒詳解;

2、用SQL語句,在SQL Server 2000管理工具中的查詢分析器可以實現,此法高級人士喜歡用;

3、用第三方工具實現,原理嘛,我覺得應該是用SQL語句來實現的,這方法好,簡單易用,網上不乏精品工具,待會兒介紹一款。

一、現在我們詳細描述一下如何用企業管理器清理SQL 2000的日誌:

1、打開企業管理器,右擊要處理的資料庫--》屬性--》選項--》故障還原,選「簡單」--》確定。如圖:

2、右擊要處理的資料庫--》所有任務--》收縮資料庫--》什麼也不動,默認第一個是0%,其它兩個未選中,點確定--》如果您以前資料庫日誌文件大於1M那麼現在再看看,是不是只有1M了呢。

3、操作完後--》按第一步,把「故障還原」,選「完全」,傳說中SQL Server 2000 有自動還原功能,說是如果非法關機等因素造成數據丟失可以自動回滾,另外可以用程序來實現操作回滾,所以最好是讓故障還原是「完全」。

4、這樣便實現了「SQL Server 2000 資料庫日誌太大!如何管理,清除,變小,壓縮它」中的清除,變小,壓縮了,至於怎麼管理,自己看著辦吧,我一般只會用到這些,再有深入研究的話我會寫上來的`。

二、現在我們介紹用第三方SQL Server 日誌清理工具來清理日誌,簡單易用高效,推薦用這個方法。

我喜歡用 SqlServer日誌清除專家 v3.5 來實現這個功能。界面如下:

資料庫那裡一般會將整個伺服器的資料庫名都列舉出來,需要選擇為自己賬戶能管理到的那個,我這里DB_iszip賬戶能管理的是 iszip ,選擇好之後,點「清除日誌」按鈕,然後SQL Server 2000的日誌就被清理好了,此時你去伺服器看你資料庫日誌佔用空間就只有1M了。

;

㈢ sqlserver事務回滾中重啟

sqlserver事務回滾中重啟的解決辦法如下。乎物
1、耐心陪弊等待回滾完成。一些大型操作可能需要很長時間歲亂液才能回滾。這樣的SPID在sys.sysprocesses會顯示CPU、內存和io列大小的變化。
2、SPID在CPU、內存和IO列中沒有顯示任何變化,那麼它什麼也不做,找到spid來自哪台客戶端機器,進入這台客戶端機器,在任務管理器裡面結束這個進程。

㈣ 什麼是SQLSERVER事務處理和事務回滾

事務(Transaction)是訪問並可能更新資料庫中各種數據項的一個程序執行單元(unit)。事務通常由高級資料庫操縱語言或編程語言(如SQL,C++或Java)書寫的用戶程序的執行所引起,並用形如begin transaction和end transaction語句(或函數調用)來界定。事務由事務開始(begin transaction)和事務結束(end transaction)之間執行的全體操作組成。

當一個事務的某一個操作發生問題時,整個事務可以回滾掉,就像沒有做任何操作一樣。這就是事務回滾。
如果一個事務的所有操作均成功,則就可以提交事務,保證事務的完整性。

應用程序主要通過指定事務啟動和結束的時間來控制事務。

以MS SQL Server的Transac-SQL語言為例,
事務啟動:
BEGIN TRAN [ SACTION ] [ transaction_name | @tran_name_variable [ WITH MARK [ 'description' ] ] ]

結束事務
可以使用 COMMIT 或 ROLLBACK 語句結束事務。

1 事務的提交
BEGIN TRANSACTION T1
INSERT tabel1 ...
UPDATE table2 ...
...
/* 當所有成功操作完成,提交事務 */
COMMIT TRAN T1

2 事務的回滾
BEGIN TRANSACTION T1
INSERT tabel1 ...
...
/* 當發生錯誤或事務被取消, 回滾事務 */
ROLLBACK TRAN T1

㈤ 對於已經執行成功的sql命令,如何回滾

當啟動Binlog後,事務會產生Binlog Event,這些Event被看做事務數據的一部分。因此要保證事務的Binlog Event和InnoDB引擎中的數據的一致性。所以帶Binlog的CrashSafe要求MySQL宕機重啟後能夠保證:

- 所有已經提交的事務的數據仍然存在。

- 所有沒有提交的事務的數據自動回滾。

- 所有已經提交了的事務的Binlog Event也仍然存在。

- 所有沒有提交事務沒有記錄Binlog Event。

這些要求很好理解,如果重啟後數據還在,但是Binlog Event沒有了,就沒辦法復制到其他節點上了。如果重啟後,數據沒了,但是Binlog Event還在,那麼不存在的數據就會被復制到其他節點上,從而導致主從的不一致。

為了保證帶Binlog的CrashSafe,MySQL內部使用的兩階段提交(Two Phase Commit)。

2 - MySQL的Two Phase Commit(2PC)

在開啟Binlog後,MySQL內部會自動將普通事務當做一個XA事務來處理:
- 自動為每個事務分配一個唯一的ID
- COMMIT會被自動的分成Prepare和Commit兩個階段。
- Binlog會被當做事務協調者(Transaction Coordinator),Binlog Event會被當做協調者日誌。
想了解2PC,可以參考文檔:【https://en.wikipedia.org/wiki/Two-phase_commit_protocol。】

- 分布式事務ID(XID)

使用2PC時,MySQL會自動的為每一個事務分配一個ID,叫XID。XID是唯一的,每個事務的XID都不相同。XID會分別被Binlog和InnoDB記入日誌中,供恢復時使用。MySQ內部的XID由三部分組成:

- 前綴部分

前綴部分是字元串"MySQLXid"

- Server ID部分

當前MySQL的server_id
- query_id部分

為了保證XID的的唯一性,數字部分使用了query_id。MySQL內部會自動的為每一個語句分配一個query_id,全局唯一。

參考代碼:sql/xa。h的struct xid_t結構。

- 事務的協調者Binlog

Binlog在2PC中充當了事務的協調者(Transaction Coordinator)。由Binlog來通知InnoDB引擎來執行prepare,commit或者rollback的步驟。事務提交的整個過程如下:

1. 協調者准備階段(Prepare Phase)

告訴引擎做Prepare,InnoDB更改事務狀態,並將Redo Log刷入磁碟。

2. 協調者提交階段(Commit Phase)

2.1 記錄協調者日誌,即Binlog日誌。

2.2 告訴引擎做commit。
注意:記錄Binlog是在InnoDB引擎Prepare(即Redo Log寫入磁碟)之後,這點至關重要。

在MySQ的代碼中將協調者叫做tc_log。在MySQL啟動時,tc_log將被初始化為mysql_bin_log對象。參考sql/binlog.cc中的init_server_components():
if (opt_bin_log) tc_log= &mysql_bin_log;

而在事務提交時,會依次執行:
tc_log->prepare();
tc_log->commit();
參考代碼:sql/binlog.cc中的ha_commit_trans()。當mysql_bin_log是tc_log時,prepare和commit的代碼在sql/binlog.cc中:

MYSQL_BIN_LOG::prepare();
MYSQL_BIN_LOG::commit();

-協調者日誌Xid_log_event
作為協調者,Binlog需要將事務的XID記入日誌,供恢復時使用。Xid_log_event有以下幾個特點:
- 僅記錄query_id
因為前綴部分不變,server_id已經記錄在Event Header中,Xid_log_event中只記錄query_id部分。
- 標志事務的結束

在Binlog中相當於一個事務的COMMIT語句。

一個事務在Binlog中看起來時這樣的:
Query_log_event("BEGIN");DML產生的events; Xid_log_event;

- DDL沒有BEGIN,也沒有Xid_log_event 。
- 僅InnoDB的DML會產生Xid_log_event
因為MyISAM不支持2PC所以不能用Xid_log_event ,但會有COMMIT Event。
Query_log_event("BEGIN");DML產生的events;Query_log_event("COMMIT");

問題:Query_log_event("COMMIT")和Xid_log_event 有不同的影響嗎?

- Xid_log_event 中的Xid可以幫助master實現CrashSafe。
- Slave的CrashSafe不依賴Xid_log_event
事務在Slave上重做時,會重新產生XID。所以Slave伺服器的CrashSafe並不依賴於Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT"),只是作為事務的結尾,告訴Slave Applier去提交這個事務。因此二者在Slave上的影響是一樣的。

3 - 恢復(Recovery)
這個機制是如何保證MySQL的CrashSafe的呢,我們來分析一下。這里我們假設用戶設置了以下參數來保證可靠性:

- 恢復前事務的狀態
在恢復開始前事務有以下幾種狀態:
- InnoDB中已經提交
根據前面2PC的過程,可知Binlog中也一定記錄了該事務的的Events。所以這種事務是一致的不需要處理。
- InnoDB中是prepared狀態,Binlog中有該事務的Events。
需要通知InnoDB提交這些事務。
- InnoDB中是prepared狀態,Binlog中沒有該事務的Events。
因為Binlog還沒記錄,需要通知InnoDB回滾這些事務。
- Before InnoDB Prepare
事務可能還沒執行完,因此InnoDB中的狀態還沒有prepare。根據2PC的過程,Binlog中也沒有該事務的events。 需要通知InnoDB回滾這些事務。

- 恢復過程
從上面的事務狀態可以看出:恢復時事務要提交還是回滾,是由Binlog來決定的。
- 事務的Xid_log_event 存在,就要提交。
- 事務的Xid_log_event 不存在,就要回滾。

恢復的過程非常簡單:
- 從Binlog中讀出所有的Xid_log_event
- 告訴InnoDB提交這些XID的事務
- InnoDB回滾其它的事務

㈥ sqlserver 存儲過程事務回滾怎麼寫

begin tran
。。。。。。
在存儲過程後面加上:
if @@error<>0
rollback tran
else
commit tran

㈦ sql service 怎麼回滾

sqlserver 的編輯器一般都是默認自動提交,也就是說你刪除後,就自動提交了;不能回滾。
當然如果你設置成不是默認提交的話,那麼你在提交之前可以回滾。

而如果是程序代碼中刪除的話,看你有沒有啟用事務,如果沒有啟用事務,那麼一般也是默認提交的,如果啟用事務,那麼再提交前可以回滾,如果已經提交了,那麼就回滾不了了。