『壹』 sql事務回滾
--創建存儲過程
alter proc proc_aa_aa1
(@id int,@name varchar(255) ,@sex char(2))
as
--創建事務
begin Transaction tran_charge
--定義變數記錄錯誤數
declare @reeSum int
set @reeSum=0
--嘗試執行sql語句
begin try
insert into aa(id,name,sex) VALUES ('1','as','男')
set @reeSum=@reeSum+@@ERROR
--@@error當前一個語句遇到錯誤，則返回錯誤號，否則返回0。需要注意的是@ERROR在每一條語句執行後會被立刻重置
insert into aa1(id,name,sex) VALUES ('1','as','男女')
print @@ERROR
set @reeSum=@reeSum+@@ERROR
end try
begin catch
--列印錯誤信息
print '錯誤編號：'+convert(varchar,error_number())+'錯誤消息'+error_message()
print @reeSum
set @reeSum=@reeSum+@@ERROR
end catch
print '111'
print @reeSum
if(@reeSum>0)--有錯誤
rollback Transaction tran_charge --回滾事務
else
commit Transaction tran_charge--提交事務
--通過調用存儲過程，給相應的參數，
exec proc_aa_aa1'2','1','3'
@@ROWCOUNT //返回
@@ERROR //返回錯誤碼
insert into aa(id,name,sex) VALUES ('1','as','男')
insert into aa1(id,name,sex) VALUES ('1','as','男女')
delete from aa
delete from aa1
select * from aa
select * from aa1
『貳』 sql2005備份資料庫怎麼恢復
資料庫數據恢復步驟
1、通過日誌恢復SQLSERVER2005數據(也可通過LogExplorer工具查找進行恢復數據)
(A)......通過日誌和時間點來恢復數據的前提條件：資料庫的故障恢復改為非簡單模式，去掉自動關閉和自動收縮兩個選項，如果是簡單模式：類似下面的語句操作數據就不會記錄到日誌中：select*intotfrom[表名].【採用LogExplorer工具可以在線操作，通過恢復日誌（指定時間點恢復）來恢復數據，必須停止資料庫或者再另一個資料庫恢復（前提是必須有一個完全備份和日誌備份）】
這時為保證數據的完整要將資料庫的恢復模式改成「完整.
1.1、這時對資料庫事務日誌做備份（注意，如果沒做個資料庫完整備份，是不能做事務日誌備份的）
這時新建一個資料庫zp（將以前的資料庫改名），恢復資料庫
這時我們看到，有兩個還原的資料庫備份，因為我對zp資料庫備份了兩次，兩次的備份的數據文件都一樣。這里我們選擇最近時間的備份默認在資料庫的設置如下：是追加到備份集里，所以會有兩個備份。
同時，在」選項「里設置」不回滾「事務，
注意：通過事務日誌還原資料庫，必須選擇"不回滾"事務
確定後：出現下面情況：
這時發現，資料庫一直是」正在還原「，這時還原資料庫事務日誌，
1.2、「常規」里選擇時間，（剛刪除的時間）
1.3、「選項」里將恢復狀態設置為」回滾未提交「事務
確定後，查詢資料庫，發現數據回來了.
2、無日誌的數據恢復
2.1.新建一個同名的資料庫
2.2再停掉sqlserver(注意不要分離資料庫)
2.3用原資料庫的數據文件覆蓋掉這個新建的資料庫
2.4再重啟sqlserver
2.5此時打開企業管理器時會出現置疑，先不管，執行下面的語句（注意修改其中的資料庫名)
2.6完成後一般就可以訪問資料庫中的數據了，這時，資料庫本身一般還要問題，解決辦法是，利用
資料庫的腳本創建一個新的資料庫，並將數據導進去就行了.
USEMASTER
SP_CONFIGURE'ALLOWUPDATES'，1RECONFIGUREWITHOVERRIDE
UPDATESYSDATABASESSETSTATUS=32768WHERENAME='資料庫名'
sp_dboption'資料庫名'，'singleuser'，'true'
DBCCCHECKDB('資料庫名')
updatesysdatabasessetstatus=28wherename='資料庫名'
sp_configure'allowupdates'，0reconfigurewithoverride
sp_dboption'資料庫名'，'singleuser'，'false'
『叄』 PLSQL事務提交了，要怎麼回滾
一組業務整體處理的行為叫一個事務。這一組的業務都能成功處理，我們就可以把這個事務提交來保存你已做的行為結果。但如果一組中有任何的差錯出現的話，我們就認為這事務不成功，需要回滾來撤消之前的操作。舉例：你去銀行轉賬，轉賬我們有兩步吧，從你賬戶中取出錢再往他賬戶中加錢。那這兩步銀行是必須要確保正確無誤的進行的。要被看做成一個事務。其中任何一步出錯就算是轉賬失敗，但可能你這時是已經從你賬戶中扣了錢了，又沒往他賬戶里加錢？怎麼辦算了？你不肯吧。所以銀行會事務回滾，不保存你剛才的操作，即恢復到你沒轉賬之前的狀態
『肆』 對於已經執行成功的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回滾其它的事務
『伍』 plsql誤刪除數據，提交事務後如何找回
你不是提交了事務么？直接 roll back 就行了。如果你不小心執行了 commit 。既然是PL-SQL你對應的資料庫就是oracle 可以通過日誌還原
『陸』 如何進行事務故障恢復，系統故障恢復，介質故障恢
1)事務故障恢復。由系統自動完成，對用戶是透明的。
DBMS執行恢復操作的步驟如下：
①反向掃描日誌文件(即從最後向前掃描日誌文件)，查找該事務的更新操作。
②對該事務的更新操作執行逆操作，即將日誌記錄中「更新前的值」寫入資料庫。
③繼續反向掃描日誌文件，做同樣處理。
④如此處理下去，直至讀到此事務的開始標記，該事務故障的恢復就完成了。
(2)系統故障恢復。系統故障可能會造成資料庫處於不一致性狀態：一是未完成事務對資料庫的更新可能已寫入資料庫；二是已提交事務對資料庫的更新可能還留在緩沖區，沒來得及寫入資料庫。因此，恢復操作就是要撤銷故障發生時未完成的事務，重做已完成的事務。
系統故障的恢復步驟如下：
①正向掃描日誌文件，找出在故障發生前已經提交的事務隊列(REDO隊列)和未完成的事務隊列(UNDO隊列)。
②對撤銷隊列中的各個事務進行UNDO處理。進行UNDO處理的方法是，反向掃描日誌文件，對每個UNDO事務的更新操作執行逆操作，即將日誌記錄中「更新前的值」寫入資料庫。
③對重做隊列中的各個事務進行REDO處理。進行REDO處理的方法是，正向掃描日誌文件，對每個REDO事務重新執行日誌文件登記的操作，即將日誌記錄中「更新後的值」寫入資料庫。
(3)介質故障恢復。介質故障是最嚴重的一種故障。恢復方法是重裝資料庫，然後重做已完成的事務。具體過程如下：
①DBA裝入最新的資料庫後備副本(離故障發生時刻最近的轉儲副本)，使資料庫恢復到轉儲時的一致性狀態。
②DBA裝入轉儲結束時刻的日誌文件副本。
③DBA啟動系統恢復命令，由DBMS完成恢復功能，即重做已完成的事務。
『柒』 sql恢復修改前數據
1、首先運行Recovery for SQL Server。
『捌』 sql server誤刪了資料庫怎麼找回
你好：
一、還原需要的條件設置
使用命令，是通過sqlserver的事務日誌以及一個誤刪除前的資料庫的完整備份進行還原，所以在sqlserver2012的維護計劃向導中，要建立完整備份，差異備份和事務日誌，具體如下
做好如上兩個設置，資料庫誤刪後找回數據就會非常輕松，現在說一下如何還原sqlserver數據到故障點。
二、還原命令
還原主要分為四步走：
1、出現故障後，首先執行備份事務日誌命令，這里以AdventureWorks作為資料庫名。命令如下：
BACKUP LOG AdventureWorks TODISK = 'C:_transcationlog.bak'
WITHNORECOVERY;
2、從完整備份還原數據
RESTORE DATABASE [QASupervision] FROM DISK='M:DatabaseOAAdventureWorks_Fullbackup_2014_03_18_010002_0155764.bak'
WITH NORECOVERY, REPLACE
3、從差異備份還原數據
RESTORE DATABASE [QASupervision] FROM DISK='M:DatabaseOAAdventureWorks_diffbackup_2014_03_18_020002_0155764.bak' WITH NORECOVERY, REPLACE
4、從事務日誌還原數據，還原到某個時間點之前
DECLARE@dt datetime
SELECT@dt=DATEADD(HOUR,-16,GETDATE())
select@dt
RESTORE LOG [QASupervision] FROMDISK='C:_transcationlog.bak'WITHSTOPAT=@dt,RECOVERY
5、還原資料庫，如果資料庫提示正在還原中，則執行此命令即可。
RESTORE DATABASEAdventureWorks WITHRECOVERY
『玖』 如何還原事務日誌備份 (SQL Server Management Studio)
備份必須按照其創建順序進行還原。在還原特定的事務日誌備份之前，必須先還原下列以前備份，而不回滾未提交的事務，即 WITH NORECOVERY：在特定事務日誌備份之前執行的完整資料庫備份和上次差異備份（如果有）。在完整資料庫備份之後執行的所有事務日誌備份或在特定事務日誌備份之前執行的差異備份（如果您還原了差異備份）。注意使用以下「恢復狀態」選項還原以前的備份： 不對資料庫執行任何操作，不回滾未提交的事務。可以還原其他事務日誌。(RESTORE WITH NORECOVERY)有關使用事務日誌備份的信息，請參閱使用事務日誌備份。還原事務日誌備份連接到相應的 Microsoft�0�2SQL Server 資料庫引擎實例之後，在對象資源管理器中，單擊伺服器名稱以展開伺服器樹。展開「資料庫」，然後根據資料庫的不同，選擇用戶資料庫，或展開「系統資料庫」，再選擇系統資料庫。右鍵單擊資料庫，指向「任務」，再單擊「還原」。 單擊「事務日誌」，這將打開「還原事務日誌」對話框。在「常規」頁上的「資料庫」列表框中，選擇或鍵入資料庫名稱。僅列出處於還原狀態的資料庫。 若要指定要還原的備份集的源和位置，請單擊以下選項之一： 從資料庫以前的備份選擇要還原其日誌備份的資料庫的名稱。從文件或磁帶單擊「瀏覽」按鈕以選擇一個或多個文件或磁帶作為事務日誌備份的來源。選擇文件或磁帶，將打開「指定備份」對話框。在「備份媒體」列表框中，從列出的設備類型選擇一種。若要為「備份位置」列表框選擇一個或多個設備，請單擊「添加」。將所需設備添加到列表框之後，單擊「確定」返回到「常規」頁。 在「選擇用於還原的備份集」網格中，選擇用於還原的備份。此網格列出了選定資料庫可以使用的事務日誌備份。只有在日誌備份的「第一個 LSN」大於資料庫的「最後一個 LSN」時，此日誌備份才可用。日誌備份按照它們所包含的日誌序列號 (LSN) 的順序排列，並且也必須按照這種順序恢復。下表列出了網格的列標題並對列值進行了說明。標題值還原如果復選框處於選中狀態，則指示要還原相應的備份集。備份集名稱備份集的名稱。備份組件已備份的組件：「資料庫」、「文件」或<空白>（表示事務日誌）。備份類型執行的備份類型：「完整」、「差異」或「事務日誌」。伺服器名稱執行備份操作的資料庫引擎實例的名稱。資料庫備份操作中所涉及的資料庫名稱。位置備份集在卷中的位置。第一個 LSN備份集中第一個事務的日誌序列號。對於文件備份為空。最後一個 LSN備份集中最後一個事務的日誌序列號。對於文件備份為空。檢查點 LSN創建備份時最近一個檢查點的日誌序列號。完整LSN 最近的完整資料庫備份的日誌序列號。開始日期備份操作開始的日期和時間（按客戶端的區域設置顯示）。完成日期備份操作完成的日期和時間（按客戶端的區域設置顯示）。大小備份集的大小（位元組）。用戶名執行備份操作的用戶的名稱。過期備份集的過期日期和時間。選擇下列操作之一： 時間點保留默認值（「最近狀態」）；或者通過單擊「瀏覽」按鈕，打開「時點還原」對話框，從中選擇特定的日期和時間。 標記的事務將資料庫還原為以前標記的事務。選擇此選項會啟動「選擇標記的事務」對話框，從而顯示一個網格，列出選定事務日誌備份中可以使用的標記的事務。默認情況下，將一直還原到（但不包含）標記的事務為止。若要同時還原標記的事務，請選擇「包含標記的事務」。下表列出了網格的列標題並對列值進行了說明。 標題值<空>顯示一個用於選擇標記的復選框。事務標記提交事務時，用戶為標記的事務指定的名稱。日期事務的提交日期及時間。事務日期和時間顯示為 msdbgmarkhistory 表中所記錄的日期和時間，而非客戶端計算機的日期和時間。說明提交事務時，用戶為標記的事務指定的說明（如果有的話）。LSN所標記事務的日誌序列號。資料庫提交標記的事務時所在資料庫的名稱。用戶名提交標記事務的資料庫用戶的名稱。若要查看或選擇高級選項，請在「選擇頁」窗格中單擊「選項」。 對於「還原到」選項，可選項有：保留復制設置將已發布的資料庫還原到創建該資料庫的伺服器之外的伺服器時，保留復制設置。此選項只能與「回滾未提交的事務，使資料庫處於可以使用的狀態...」選項（等效於使用 RECOVERY 選項還原備份，將在後面予以介紹）一起使用。選中此選項等效於在 Transact-SQL RESTORE 語句中使用 KEEP_REPLICATION 選項。還原每個備份之前進行提示如果選中此選項，則在第一個備份集之後還原每個備份集之前，將顯示「繼續還原」對話框，詢問您是否要繼續按此順序還原。此對話框顯示下一個媒體集（如果可用）的名稱、備份集的名稱以及備份集的說明。如果對於不同媒體集必須更換磁帶，則此選項特別有用。例如，如果伺服器只有一個磁帶設備，則可以使用此選項。待您做好繼續操作的准備後，再單擊「確定」。單擊「否」將使資料庫保持還原狀態。完成上次還原之後，您可以在方便時繼續按順序還原。如果下一個備份是數據備份或差異備份，請再次使用「還原資料庫」任務。如果下一個備份是日誌備份，請使用「還原事務日誌」任務。限制訪問還原的資料庫使還原的資料庫僅供 db_owner、dbcreator 或sysadmin 的成員使用。選中此選項等效於在 Transact-SQL RESTORE 語句中使用 RESTRICTED_USER 選項。對於「恢復狀態」選項，請指定還原操作之後的資料庫狀態。 回滾未提交的事務，使資料庫處於可以使用的狀態。無法還原其他事務日誌。(RESTORE WITH RECOVERY)恢復資料庫。此選項等效於 Transact-SQL RESTORE 語句中的 RECOVERY 選項。請僅在沒有要還原的日誌文件時選擇此選項。 不對資料庫執行任何操作，不回滾未提交的事務。可以還原其他事務日誌。(RESTORE WITH NORECOVERY)使資料庫處於未恢復狀態。此選項等效於在 Transact-SQL RESTORE 語句中使用 NORECOVERY 選項。如果選擇此選項，「保留復制設置」選項將不可用。 使資料庫處於只讀模式。撤消未提交的事務，但將撤消操作保存在文件中，以便可使恢復效果逆轉。(RESTORE WITH STANDBY)使資料庫處於備用狀態。此選項等效於在 Transact-SQL RESTORE 語句中使用 STANDBY 選項。選擇此選項需要您指定一個備用文件。（可選操作）在「備用文件」文本框中指定一個備用文件名。如果您使資料庫處於只讀模式，則必須選中此選項。您可以瀏覽到該備用文件，也可以在文本框中鍵入其路徑名。
『拾』 資料庫事務提交了還能用日誌恢復嗎
資料庫事務提交了還能用日誌恢復。
提交後，可以恢復最後一個日誌備份即剛做的日誌備份，指定恢復時間點到誤操作之前的時刻。就可以。
還有事務日誌備份保留上次事務日誌備份後發生的所有事務的痕跡。它還允許你把資料庫恢復到資料庫發生錯誤之前的一個時間點。事務日誌備份按順序發生，從而建立一個備份鏈。在把一連串事務日誌備份恢復到一個時間點時，事務日誌文件也必須按順序恢復