‘壹’ 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 选项。选择此选项需要您指定一个备用文件。（可选操作）在“备用文件”文本框中指定一个备用文件名。如果您使数据库处于只读模式，则必须选中此选项。您可以浏览到该备用文件，也可以在文本框中键入其路径名。
‘拾’ 数据库事务提交了还能用日志恢复吗
数据库事务提交了还能用日志恢复。
提交后，可以恢复最后一个日志备份即刚做的日志备份，指定恢复时间点到误操作之前的时刻。就可以。
还有事务日志备份保留上次事务日志备份后发生的所有事务的痕迹。它还允许你把数据库恢复到数据库发生错误之前的一个时间点。事务日志备份按顺序发生，从而建立一个备份链。在把一连串事务日志备份恢复到一个时间点时，事务日志文件也必须按顺序恢复