数据库回滚自动手动(怎么回滚数据库)

高端定制开发 33
今天给各位分享数据库回滚自动手动的知识,其中也会对怎么回滚数据库进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!oracle数据库引起自动回滚的原因 比如说你的事务未提交进程意外终止(掉线啊,点击叉叉退出连接啊)未提交的数据全部回滚。或者在你的事务提交过程中,数据违反约束条件,事务内部出现错误被终止,则该事务中所有操作也被自动回滚。还有其他一些情况,这两个是主要的。

今天给各位分享数据库回滚自动手动的知识,其中也会对怎么回滚数据库进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

oracle数据库引起自动回滚的原因

比如说你的事务未提交进程意外终止(

掉线

啊,点击

叉叉

退出连接啊)未提交的数据全部

回滚

。或者在你的事务提交过程中,数据违反约束条件,事务内部出现错误被终止,则该事务中所有操作也被自动回滚。还有其他一些情况,这两个是主要的。

MYSQL数据库自动提交与手动提交区别?

手动提交 可以对逻辑进行控制,打个比方:

你程序需要做两件事情,一个是 结账,一个是打印账单。这两个事情必须都要成功,才算是结账成功,否则认为失败。

那么这个时候我们就要使用手动提交了,因为打印账单不属于数据库控制范畴。

我们可以 先添加结账数据到数据库,然后等待打印机打印

,这个时候虽然我们的数据是添加成功了,如果打印机打印报错了,那么这个任务就没有完成,就必须回滚掉之前的数据库操作。

手动提交事务: 可以控制整个程序的任务完成情况和完成的逻辑。数据添加成功,打印失败,造成的结果就是:数据显示未结账,也没有账单打印出来。数据就是一致的!

自动提交:只管你数据库添加是否成功,打印机有没有打印账单就不能控制了,造成的结果就是,数据显示已结账,但是没有账单打印出来。那么就出现数据不一致的情况。

手动的话:整个任务完成,就完成,中间任何一个环节出错 就等于什么都没做

自动提交:整个任务完成一个是算一个!

JAVA 里面怎写Oracle的数据库回滚

//举例子,比如你在写一个级联删除的方法的时候,为了保证数据完整性,删除的时候一定要确定该删的都删了才行,否则就要回滚,下面是删除方法的例子:public boolean delete(int sID) {//成功删除会返回true;

 dbc = new DataBaseConnection();//根据你自己的方式创建数据库的连接

 Connection con = dbc.getConnection();//得到Connection

 try {

con.setAutoCommit(false);// 更改JDBC事务的默认提交方式,默认是true,是自动提交;

dbc.executeUpdate("delete from xiao where ID=" + sID);//删除

dbc.executeUpdate("delete from xiao_content where ID=" + sID);//删除

dbc.executeUpdate("delete from xiao_affix where bylawid=" + sID);//删除

con.commit();//提交JDBC事务,如果没问题,这时才真正的删除了;

con.setAutoCommit(true);// 恢复JDBC事务的默认提交方式,这是个好习惯;

dbc.close();//关闭连接

return true;//删除成功

 }

 catch (Exception exc) {

con.rollBack();//回滚JDBC事务,出现异常,为保证数据完整性,此次操作回滚,不删除;

exc.printStackTrace();//输出异常信息;

dbc.close();//关闭连接

return false;//删除失败

 }

}//顺便说一下,java中JDBC的事务管理,跟你用的是什么数据库没关系,用什么数据库都是这样;

mysql命令行下怎样实现数据的回滚操作

当启动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,可以参考文档:【。】

- 分布式事务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回滚其它的事务

数据库的手动提交和自动提交区别

一、处理方式不同

1、手动提交:用显式的方式定义其开始和结束的事务,当使用start transaction和 commit语句时则表示发生显式事务。

2、自动提交:指每一条数据操作语句都自动地成为一个事务,事务的开始是隐式的,事务的结束有明确的标记。

二、特点不同

1、手动提交:逻辑相关的操作分成了一个组,在数据永久改变前,可以预览数据变化。

2、自动提交:能够保证数据的读一致性。

三、处理结果不同

1、手动提交:务被提交给了DBMS(数据库管理系统),则DBMS(数据库管理系统)需要确保该事务中的所有操作都成功完成且其结果被永久保存在数据库中。

2、自动提交:事务中有的操作没有成功完成,则事务中的所有操作都需要被回滚,回到事务执行前的状态;同时,该事务对数据库或者其他事务的执行无影响,所有的事务都好像在独立的运行。

参考资料来源:百度百科-数据库事务

参考资料来源:百度百科-SQL数据库

数据库回滚自动手动的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于怎么回滚数据库、数据库回滚自动手动的信息别忘了在本站进行查找喔。

数据库回滚自动手动 数据库回滚操作mysql数据库回滚数据库重做和回滚oracle数据库回滚数据库回滚是什么意思oracle数据库回滚命令redis和数据库一起回滚oracle数据库回滚操作sqlserver数据库回滚命令oracle数据库回滚到指定时间
扫码二维码