㈠ 如何查詢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 的編輯器一般都是默認自動提交，也就是說你刪除後，就自動提交了；不能回滾。
當然如果你設置成不是默認提交的話，那麼你在提交之前可以回滾。
而如果是程序代碼中刪除的話，看你有沒有啟用事務，如果沒有啟用事務，那麼一般也是默認提交的，如果啟用事務，那麼再提交前可以回滾，如果已經提交了，那麼就回滾不了了。