MySQL 原理篇 MySQL 索引机制 MySQL 体系结构及存储引擎 MySQL 语句执行过程详解 MySQL 执行计划详解 MySQL InnoDB 缓冲池 MySQL InnoDB 事务 MySQL InnoDB 锁 MySQL InnoDB MVCC MySQL InnoDB 实现高并发原理 MySQL InnoDB 快照读在RR和RC下有何差异 转载:<InnoDB并发如此高,原因竟然在这?> 并发控制 为啥要进行并发控制? 并发的任务对同一个临界资源进行操作,如果不采取措施,可能

Undo的作用 数据的回滚 一致性读 表的闪回(事务,查询的闪回..) 失败会话的恢复 回滚rollback操作 SQL> archive log list; ORA-01031: 权限不足 SQL> conn /as sysdba 已连接. SQL> archive log list; 数据库日志模式 存档模式 自动存档 启用 存档终点 USE_DB_RECOVERY_FILE_DEST 最早的联机日志序列 45 下一个存档日志序列 47 当前日志序列 47 SQL> creat

1.Undo是干嘛用的?   在介绍undo之前先说一下另外一个东西 transaction ,翻译成交易或事务.我们在进行一个事务的过程中需要申请许多资源,一个复杂的事务也需要很多步来完成.那么一个复杂的事务是只有两个结果,要么成功,要么失败(相当于从来没发生过). 一个很典型的列子,银行转账,其实其需要两步操作,第一步先将你账户上的钱减去,第二步把被转账户的钱加上,(先减后加,出了问题银行不吃亏.呵呵!)这样就是一个完整的事务.如果执行了一半,你的钱减了,被转账户的钱没加上,这个时候事务就要

环境:RHEL 6.4 + Oracle 11.2.0.4 背景:备份恢复的测试库在一次不完全恢复后,没有来及做有效的全备,又一次数据库故障导致数据库无法正常open. 只能离线部分数据文件打开数据库,其中包含undo表空间数据文件. 适用场景:无有效备份,可以丢失数据,删除回滚段状态为NEEDS RECOVERY的undo表空间. 一.数据库当前情况 1.1 故障现象 1.2 查看数据文件的状态 1.3 尝试online数据文件失败 二.删除损坏数据文件所在表空间 2.1 普通数据文件4所在的

关于回滚段的问题,之前也小整理过一个,参考: Current online Redo 和 Undo 损坏的处理方法 http://blog.csdn.net/tianlesoftware/article/details/6261475 Roger同学昨天整理了一个更加详细的说明,转帖过来. Roger 的原文链接如下: http://www.killdb.com/?p=196 某些情况下,我们需要手动去清除一些有问题的回滚段,如果该回滚段中包含活动事务,那么使用正常的方式将无法drop,所以此时

今天新搭建了一个10g的测试数据库,运行都很正常,但是在打开autotrace功能后执行语句,报错 SQL> set autotrace on SQL> select username,sid,serial#,server,paddr,status from v$session where username=USER; USERNAME                              SID    SERIAL# SERVER    PADDR    STATUS ---------

回滚段概述  回滚段用于存放数据修改之前的值(包括数据修改之前的位置和值).回滚段的头部包含正在使用的该回滚段事务的信息.一个事务只能使用一个回滚段来存放它的回滚信息,而一个回滚段可以存放多个事务的回滚信息. 回滚段的作用  事务回滚:当事务修改表中数据的时候,该数据修改前的值(即前影像)会存放在回滚段中,当用户回滚事务(ROLLBACK)时,ORACLE将会利用回滚段中的数据前影像来将修改的数据恢复到原来的值. 事务恢复:当事务正在处理的时候,例程失败,回滚段的信息保存在重做日志文件中,ORA

ORACLE 回滚段 回滚段概述 回滚段用于存放数据修改之前的值(包括数据修改之前的位置和值).回滚段的头部包含正在使用的该回滚段事务的信息.一个事务只能使用一个回滚段来存放它的回滚信息,而一个回滚段可以存放多个事务的回滚信息. 回滚段的三个作用 事务回滚:当事务修改表中数据的时候,该数据修改前的值(即前影像)会存放在回滚段中,当用户回滚事务(ROLLBACK)时,ORACLE将会利用回滚段中的数据前影像来将修改的数据恢复到原来的值. 事务恢复:当事务正在处理的时候,例程失败,回滚段的信息保存在

因为上一次研究了Oracle的事务一致性,中间查阅资料的时候,看到这个地方与回滚段有关.所以就罗列了以下简单的知识.更为深层次的就不再深挖了,个人感觉对于事务的一致性和隔离级别是开发经理应该了解的,但是回滚段的具体机制应该是DBA的学习范畴了.   回滚段(ROLLBACK SEGMENT)的作用: 回滚段是在事务中间过程中,将修改前的状态记录下来,记录的过程中加上类似时间戳的scn.它的主要作用有两个: 当事务出现错误回滚的时候,原始数据可以从回滚段中找回. 实现读一致性.当读操作读取到某一行

/* 撤销表空间 */ 通过使用撤销技术,能够为Oracle数据库提供以下功能: * 使用ROLLBACK语句撤销事务 * 进行数据库恢复 * 提供数据的读一致性 Oracle强烈建议DBA在Oracle 9I数据库中应用自动撤销管理方式,任何数据库用户都不能在撤销表空间中创建对象,在撤销表空间中只能保存撤销记录. SQL> show parameter undo NAME                                 TYPE        VALUE -----------

MySQL中有六种日志文件,分别是:重做日志(redo log).回滚日志(undo log).二进制日志(binlog).错误日志(errorlog).慢查询日志(slow query log).一般查询日志(general log),中继日志(relay log).其中重做日志和回滚日志与事务操作息息相关,二进制日志也与事务操作有一定的关系,这三种日志,对理解MySQL中的事务操作有着重要的意义.这里简单总结一下这三者具有一定相关性的日志. 重做日志(redo log) 作用: 确保事务的持

一.回滚(ROLLBACK)和撤销(UNDO) 回滚和前滚是保证Oracle数据库中的数据处于一致性状态的重要手段. 在9i版本以前 Oracle使用数据库中的回滚段来实现未提交数据或因系统故障导致实例崩溃时进行回滚操作 每一个表空间需要创建回滚段,各个表空间对回滚段实现各自的管理 在9i及后续版本 提供了一种新的回滚数据的管理方式,即使用Oracle自动管理的撤销(Undo)表空间 自动撤销管理表空间统一管理所有DML的回滚操作,简化了对于回滚工作的管理 在9i,10g中的回滚段仅仅用作保留向

一.回滚日志(undo log) 1.作用 保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读 2.内容 逻辑格式的日志,在执行undo的时候,仅仅是将数据从逻辑上恢复至事务之前的状态,而不是从物理页面上操作实现的,这一点是不同于redo log的. 3.什么时候产生 事务开始之前,将当前是的版本生成undo log,undo 也会产生 redo 来保证undo log的可靠性 4.什么时候释放 当事务提交之后,undo log并不能立马

目录 一.前言 二.undo log表空间 三.关于undo log默认的配置 四.如何将undo log放到单独的表空间 文章公众号首发,持续更新中 五.rollback segment 六.什么是undo log truncate 七.如果做 undo log truncate 八.undo log的类型 九.insert undo log 长啥样? 十.一条update undo log 长啥样? 十一.事物是如何回滚的?(undo log 链条) 十二.问个问题 十三.补充: 文章公众号

      日志的记录和维护是数据库中相当重要的内容,写这篇文章和后面几篇文章作为学习官网文档的笔记.MariaDB数据库日志可分为二进制日志.查询日志.错误日志.myISAM表日志.relay日志和撤销日志(undo log). MariaDB(mysql)的undo log 保存数据被InnoDB事务修改前的版本,用于数据恢复或者提供给“一致读consistent read”级别的事务读取,具体细节如下: 1.在某行数据被修改前,首先复制数据到undo log中,表中的每行数据包含一个指针指

这篇文章主要描写叙述oracle的回滚机制,篇幅可能较长,由于对于oracle的回滚机制来说,要讨论和描写叙述的实在太多,仅仅能刷选自己觉得最有意义的一部分进行深入研究和分享 一.我们来看一个DML语句的处理过程描写叙述 update undotest set object_type='VIEW' where object_type='PROCEDURE'; 检查shared pool中是否存在同样的语句.假设存在.重用运行计划,运行扫描运算,假设不存在.运行硬解析生成运行计划 依据运行计划中的

InnoDB’s Undo 前言 Undo log是InnoDB MVCC事务特性的重要组成部分.当我们对记录做了变更操作时就会产生undo记录,Undo记录默认被记录到系统表空间(ibdata)中,但从5.6开始,也可以使用独立的Undo 表空间. Undo记录中存储的是老版本数据,当一个旧的事务需要读取数据时,为了能读取到老版本的数据,需要顺着undo链找到满足其可见性的记录.当版本链很长时,通常可以认为这是个比较耗时的操作(例如bug#69812). 大多数对数据的变更操作包括INSERT

    update.delete的条件写错甚至没有写,导致数据操作错误,需要恢复被误操作的行记录.这种情形,其实时有发生,可以选择用备份文件+binlog来恢复到测试环境,然后再做数据修复,但是这样其实需要耗费一定的时间跟资源.     其实,如果binlog format为row,binlog文件中是会详细记录每一个事务涉及到操作,并把每一个事务影响到行记录均存储起来,能否给予binlog 文件来反解析数据库的行记录变动情况呢?     业界已有不少相关的脚本及工具,但是随着MySQL版本的

一. MVCC 原理了解   原文点击:MVCC原理浅析 读锁: 也叫共享锁.S锁,若事务T对数据对象A加上S锁,则事务T可以读A但不能修改A,其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的S 锁.这保证了其他事务可以读A,但在T释放A上的S锁之前不能对A做任何修改. 写锁: 又称排他锁.X锁.若事务T对数据对象A加上X锁,事务T可以读A也可以修改A,其他事务不能再对A加任何锁,直到T释放A上的锁.这保证了其他事务在T释放A上的锁之前不能再读取和修改A. 表锁: 操作对象是数据表.My

前言:有人问了我一个问题,就是说在网络中断的时候,JTA的全局事务管理,会不会回滚?当时说会回滚,但没给对方说清楚理由,也不太认同我的观点.现在总结一下. 今天一天都在看文档(也查了一些博客和网站),主要看EJB.JTA.JDBC.Mysql,来分享一下地址(全是官方网址,可能更具有权威): http://docs.oracle.com/javaee/6/tutorial/doc/  备注:虽然是java EE 6的文档,但基本上不会差太多,主要看的是EJB.JTA https://docs.o

我已经讨论了各种确定恢复状态的方法,但是本周我参与了一个围绕回滚的有趣讨论.交易已经运行了14个小时,然后发出了KILL SPID.SPID进入回滚,并发生2天和4小时. 自然的问题是为什么不14小时回滚? 没有一些具体的细节很难说,但如果原来的查询使用了并行工作,那么可能会完成超过14个小时的工作.例如,如果更新与4名工作人员同时运行,则可以完成56个工作小时或2.3天.回滚大多是单线程的,所以可能需要4倍的时间来完成回滚.另外,在执行过程中,预读通常更高效,因为计划是已知的,回滚必须在日志记