精华内容
下载资源
问答
  • REDO

    2018-12-04 20:05:57
    REDO——重做日志 所有关系型数据库都有重做日志 定义:所有数据的改变都会发生重做日志 用途:1、恢复数据 2、日志挖掘 3、流 REDO有两种一种是UNDO产生的REDO,一种是数据块本身产生的REDO。 数据库的每个改动...

    REDO——重做日志
    所有关系型数据库都有重做日志
    定义:所有数据的改变都会发生重做日志
    用途:1、恢复数据 2、日志挖掘 3、流
    REDO有两种一种是UNDO产生的REDO,一种是数据块本身产生的REDO。
    在这里插入图片描述
    数据库的每个改动都会发生重做日志
    写入数据块缓冲前,先写入重做日志——内存
    写入数据文件之前,先写入日志文件——数据文件

    重做日志速度快,只要日志写入,那么数据就不会丢失了。
    发生COMMIT ,发生REDO。
    在这里插入图片描述
    有三个重做日志组,依次写入。
    REDO与归档
    REDO存放的不是SQL语句,也不是更改的数值而是数据块上信息改变的大小。在这里插入图片描述

    展开全文
  • redo

    2015-02-06 15:10:30
    什么是REDO  REDO记录transaction logs,分为online和archived。以恢复为目的。 比如,机器停电,那么在重起之后需要online redo logs去恢复系统到失败点。 比如,磁盘坏了,需要用archived redo logs和online ...

     

    什么是REDO 
    REDO记录transaction logs,分为online和archived。以恢复为目的。 比如,机器停电,那么在重起之后需要online redo logs去恢复系统到失败点。 比如,磁盘坏了,需要用archived redo logs和online redo logs区恢复数据。 比如,truncate一个表或其他的操作,想恢复到之前的状态,同样也需要。


    下面是官网的解释:

    The most crucial structure for recovery operations is the redo log, which consists of two or more preallocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure.


    两个概念:

    改变向量(Change Vector)

    改变向量表示对数据库内某一个数据块所做的一次变更。改变向量中包含了变更的数据块的版本号、事务操作代码、变更从属数据块的地址(DBA)以及更新后的数据。例如:一个update事务包含一系列的改变向量,对于数据块的修改是一个向量,对于回滚段的修改又是一个向量。

    重做记录(Redo Record)

    重做记录通常由一组改变向量组成,是一个改变向量的集合,代表一个数据库的变更(INSERT、UPDATE、DELETE等操作),构成数据库变更的最小恢复单位。例如:一个Update的重做记录包括相应的回滚段的改变向量和相应的数据块的改变向量等。



    COMMIT和ROLLBACK操作:

    COMMIT 以前,常想当然地认为,一个大的TRANSACTION(比如大批量地INSERT数据)的COMMIT会花费时间比短的TRANSACTION长。而事实上是没有什么区别的, 
    因为ORACLE在COMMIT之前已经把该写的东西写到DISK中了, 
    我们COMMIT只是 
    1,产生一个SCN给我们TRANSACTION,SCN简单理解就是给TRANSACTION排队,以便恢复和保持一致性。 
    2,REDO写REDO到DISK中(LGWR,这就是log file sync),记录SCN在ONLINE REDO LOG,当这一步发生时,我们可以说事实上已经提交了,这个TRANSACTION已经结束(在V$TRANSACTION里消失了) 
    3,SESSION所拥有的LOCK(V$LOCK)被释放。 
    4,Block Cleanout(这个问题是产生ORA-01555: snapshot too old的根本原因) ROLLBACK ROLLBACK和COMMIT正好相反,ROLLBACK的时间和TRANSACTION的大小有直接关系。因为ROLLBACK必须物理上恢复数据。COMMIT之所以快,是因为ORACLE在COMMIT之前已经作了很多工作(产生UNDO,修改BLOCK,REDO,LATCH分配), 

    ROLLBACK慢也是基于相同的原因。 
    ROLLBACK会 
    1,恢复数据,DELETE的就重新INSERT,INSERT的就重新DELETE,UPDATE的就再UPDATE。 
    2,RELEASE LOCK ROLLBACK要比COMMIT消耗更多资源,因为ORACLE认为你一旦做数据更新,那么就意味着你要COMMIT(其他数据库不全是这种设计理念,比如DB2),所以在你更新数据的时候就做了大量的工作,这也可以理解为什么不建议用TABLE来做TEMPORARY TABLE。(TEMP TABLE消耗的REDO比固定表在INSERT时要少很多 ,UPDATE时差不多是1/2, 
    但是DELETE却相差无几) REDO 产生REDO 越多,你的系统越慢,不但影响你自己的SESSION,还影响其他SESSION,LGWR管理REDO,并且是TRANSACTION的结束标志。


    REDO和UNDO的区别

    写的次序:

    redo--> undo-->datafile insert一条记录时, 表跟undo的信息都会放进 redo 中, 在commit 或之前, redo 的信息会放进硬盘上. 故障时, redo 便可恢复那些已经commit 了的数据. redo->每次操作都先记录到redo日志中,当出现实例故障(像断电),导致数据未能更新到数据文件,则数据库重启时须redo,重新把数据更新到数据文件 undo->记录更改前的一份copy,但你系统rollback时,把这份copy重新覆盖到原来的数据 redo->记录所有操作,用于恢复(redo records all the database transaction used for recovery) undo->记录所有的前印象,用于回滚(undo is used to store uncommited data infor used for rollback) redo->已递交的事务,实例恢复时要写到数据文件去的 undo->未递交的事务. redo的原因是:每次commit时,将数据的修改立即写到online redo中,但是并不一定同时将该数据的修改写到数据文件中。因为该数据已经提交,但是只存在联机日志文件中,所以在恢复时需要将数据从联机日志文件中找出来,重新应用一下,使已经更改数据在数据文件中也改过来!

    undo的原因是:在oracle正常运行时,为了提高效率,加入用户还没有commit,但是空闲内存不多时,会由DBWR进程将脏块写入到数据文件中,以便腾出宝贵的内存供其它进程使用。这就是需要UNDO的原因。因为还没有发出commit语句,但是oracle的dbwr进程已经将没有提交的数据写到数据文件中去了。 undo 也是也是datafile, 可能dirty buffer 没有写回到磁盘里面去。只有先redo apply 成功了,才能保证undo datafile 里面的东西都是正确的,然后才能rollback 做undo的目的是使系统恢复到系统崩溃前(关机前)的状态,再进行redo是保证系统的一致性. 不做undo,系统就不会知道之前的状态,redo就无从谈起 所以instance crash recovery 的时候总是先rollforward, 再rollback undo 回退段中的数据是以“回退条目”方式存储。回退条目=块信息(在事务中发生改动的块的编号)+在事务提交前存储在块中的数据 在每一个回退段中oracle都为其维护一张“事务表” 在事务表中记录着与该回退段中所有回退条目相关的事务编号(事务SCN&回退条目) redo 重做记录由一组“变更向量”组成。每个变更变量中记录了事务对数据库中某个块所做的修改。

    当用户提交一条commit语句时,LGWR进程会立刻将一条提交记录写入到重做日志文件中,然后再开始写入与该事务相关的重做信息。 #事务提交成功后,Oracle将为该事备生成一个系统变更码(SCN)。事务的SCN将同时记录在它的提交记录和重做记录中。

    commit 提交事务前完成的工作:

    ·在SGA区的回退缓存中生成该事务的回退条目。在回退条目中保存有该事务所修改的数据的原始版本。

    ·在SGA区的重做日志缓存中生成该事务的重做记录。重做记录中记载了该事务对数据块所进行的修改,并且还记载了对回退段中的数据块所进行的修改。缓存中的重做记录有可能在事务提交之前就写入硬盘中。

    ·在SGA区的数据库缓丰中记录了事务对数据库所进行的修改。这些修改也有可能在事务提交之前就写入硬盘中。

    提交事务时完成的工作:

    ·在为该事务指定的回退段中的内部事务表内记录下这个事务已经被提交,并且生成一个惟一的SCN记录在内部事务表中,用于惟一标识这个事务。

    ·LGWR后进进程将SGA区重做日志缓存中的重做记录写入联机重做日志文件。在写入重做日志的同时还将写入该事务的SCN。

    ·Oracle服务进程释放事务所使用的所有记录锁与表锁。

    ·Oracle通知用户事务提交完成。

    ·Oracle将该事务标记为已完成。

     rollback 回退事务完成的工作:

    ·Oracle通过使用回退段中的回退条目,撤销事务中所有SQL语句对数据库所做的修改。

    ·Oracle服务进程释放事务所使用的所有锁

    ·Oracle通知事务回退成功。

    ·Oracle将该事务标记为已完成

    举个例子: insert into a(id) values(1);(redo) 这条记录是需要回滚的。回滚的语句是delete from a where id = 1;(undo) 试想想看。如果没有做insert into a(id) values(1);(redo) 那么delete from a where id = 1;(undo)这句话就没有意义了。 现在看下正确的恢复: 先insert into a(id) values(1);(redo) 然后delete from a where id = 1;(undo) 系统就回到了原先的状态,没有这条记录了。


    日志的状态

    CURRENT:指的是当前的日志文件,该日志文件是活动的,当前正在被使用的,在进行崩溃恢复时,Current的日志文件时必须的。

    ACTIVE:活动的非当前日志,该日志可能已经完成归档也可能没有归档,活动的日志文件在Crash恢复时会被用到。

    ACITVE状态意味着检查点尚未完成,如果日志文件循环使用再次到达该文件,数据库将处于等待的停顿状态,此时在alert文件中,可以看到类似如下记录:Checkpoint not complete

    当这种问题出现时,可以从数据库内部通过v$session_wait来观察,该视图会显示数据库当前哪些session正处于这种等待。

    Checkpoint not complete在数据库中体现为等待事件log file switch(checkpoint incomplete):

    SQL> select sid,event,state from v$session_wait;

    在此同时,可能DBWR进程正在进行db file parallel write,日志文件必须等待DBWR完成检查点触发的写操作之后才能被覆盖。如果设置了参数log_checkpoints_to_alert为TRUE的话,还可以在alert文件中清晰地看到检查点的增进和完成情况。

    引起Checkpoint Incomplete可能有以下多种原因

    日志文件过小,切换过于频繁;

    日志组太少,不能满足正常业务量的需要;

    日志文件所在磁盘I/O存在瓶颈,导致写出缓慢,阻塞数据库正常运行;

    由于数据文件磁盘I/O瓶颈,DBWR写出过于缓慢;

    由于事务量巨大,DBWR负载过高,不堪重负。

    解决方法

    适当增加日志文件大小;

    适当增加日志组数;

    使用更快的磁盘存储日志文件(如采用更高转速磁盘;使用RAID10而不是RAID5等方式);

    改善磁盘I/O的性能;

    使用多个DBWR进程或使用异步I/O等。

     

    注意:Checkpoint Incomplete是一类严重的等待,它意味着数据库不能再产生日志,所有数据库修改操作将全部挂起。

     

    INACTIVE:非活动日志,该日志在实例恢复时不再需要,但是在介质恢复时可能会用到。INACTIVE状态的日志也可能没有被归档。如果数据库启动在归档模式,在未完成归档之前,日志文件也不允许被覆盖,这时候活动进程会处于log file switch(archiving needed)等待之中。

    日志是否完成归档,可以根据v$log视图的archived字段进行判断。

     

    UNUSED:是指该日志从未被写入,这类日志可能是刚被添加到数据库或者在RESETLOGS之后被重置。被使用之后,该状态会被改变。


     

    产生多少Redo

    SQL*Plus中使用autotrace功能

    当在SQL*Plus中启用autotrace跟踪后,在执行了特定的DML语句时,Oracle会显示该语句的统计信息,其中,Redo size一栏表示的就是该操作产生的Redo的数量:

    SQL> set autotrace trace stat

    SQL> insert into test

     2 select empno,ename from scott.emp;

    已创建12行。

    Statistics

    ----------------------------------------------------------

           189 recursive calls

             2 db block gets

            37 consistent gets

             4 physical reads

           564 redo size

           778 bytes sent via SQL*Net to client

           823 bytes received via SQL*Net from client

             4 SQL*Net roundtrips to/from client

             1 sorts (memory)

             0 sorts (disk)

            12 rows processed

     

    通过v$mystat查询:

    Oracle通过v$mystat视图记录当前session的统计信息,也可以从该视图中查询得到session的Redo生成情况:

    SQL> col name for a30

    SQL> select a.name,b.value

     2 from v$statname a,v$mystat b

     3 where a.statistic#=b.statistic# and a.name='redo size';

     

    NAME                               VALUE

    ------------------------------ ----------

    redo size                              5000

     

    SQL> insert into test

     2 select empno,ename from scott.emp;

    已创建12行。

     

    SQL> select a.name,b.value

     2 from v$statname a,v$mystat b

     3 where a.statistic#=b.statistic# and a.name='redo size';

     

    NAME                               VALUE

    ------------------------------ ----------

    redo size                              5564

     

    SQL> select 5564-5000 from dual;

     

     5564-5000

    ----------

          564

     

    通过v$sysstat查询:

    对于数据库全局redo的生成量,可以通过v$sysstat视图来查询得到:

    SQL> col value for 999999999999

    SQL> select name,value from v$sysstat

     2 where name='redo size';

     

    NAME                                  VALUE

    ------------------------------ -------------

    redo size                          11471552

     

    从v$sysstat视图中得到的是自数据库实例启动以来累计日志生成量,可以根据实例启动时间来大致估算每天数据库的日志生成量:

    SQL> select

     2 (select value/1024/1024/1024 from v$sysstat where name='redo size')/

     3 (select sysdate-(select startup_time from v$instance) from dual)

     4 redo_gb_per_day from dual;

     

    REDO_GB_PER_DAY

    ---------------

        .073238253


    展开全文
  • Redo

    2016-05-30 12:51:05
    oracle规定:保证重做记录先于对应的脏数据块写入持久层 内存层面:Oracle先写日志缓冲数据后写数据缓冲数据 物理层面:oracle先写redo log后写datafile ...

    oracle规定:保证重做记录先于对应的脏数据块写入持久层

    内存层面:Oracle先写日志缓冲数据后写数据缓冲数据

    物理层面:oracle先写redo log后写datafile

     

    Redo中包含undo

    DDL操作虽然无法产生rollback,但是仍会产生redoundo

     

    Redo:记录所有操作,因为先写redo后写datafie,所以实例恢复时需要把redo中信息读取出来再判断是否需要写入datafile

     

     

    redo的原因是:每次commit时,将数据的修改立即写到online redo中,但是并不一定同时将该数据的修改写到数据文件中。因为该数据已经提交,但是只存在联机日志文件中,所以在恢复时需要将数据从联机日志文件中找出来,重新应用一下(前滚),使已经更改数据在数据文件中也改过来!非commit时,因redo log先于datafile写入持久层,所以重启时需要先前滚redo log中修改的数据,如果这些数据没有commit再从undo中回滚回去。

     

     

    实验验证:

    一次性写入400M数据记录为10万条,但是不commit,发现很多8个在线日志都归档了,并且发现数据文件也增长了400M,删除其中一个归档日志后shutdown abort并且startup后,数据文件大小不变(不会减少400M),但是记录为0,说明前滚不会用到归档日志(理论解释:因为归档日志切换的时候会触发checkpoint再出发dbwr写,所以数据必须先写入datafile才会做日志归档操作),但是回滚数据就全部用到了,因为回滚数据中只要事务标记为未提交,就会用做回滚。

     

     

    instance crash recovery 的时候总是先rollforward rollback

    实例恢复顺序:先redo,再undoredo范围之内的才undo

    例子:

    两个块,值分别是A1

    A修改为B,并且commit提交了,说明写到了redo日志

    1修改为2没有提交,写入到了undo,不一定写到了redo日志,事务槽状态一定是未提交

     

    如果1修改为2写到了redo日志,则恢复是:

    实例恢复的时候利用redo先前滚到a->b1->2,再利用undo回滚2->1,结果两个块的值分别B1

     

    如果1修改为2没写入redo日志,则恢复是:

    实例恢复的时候是利用redo先前滚到a->b,结果两个块的值分别B1虽然1->2undo,但是undo不在redo的范围,故不用回滚

     

     

     

    多个日志组的好处

    归档比较慢,切换比较快,比如ABC三组日志,A在归档,lgwrA切换到了BB也写满了需要切换到CC也写满了需要切换到A,而A可能还没有归档完,导致数据库等待

     

     

     

    Alter system switch logfile对单实例数据库或RAC中的当前实例执行日志切换;

    Alter system archive log current对数据库中的所有实例执行日志切换。

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30126024/viewspace-2109196/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/30126024/viewspace-2109196/

    展开全文
  • MySQL日志系统:redo log、binlog、undo log 区别与作用

    万次阅读 多人点赞 2019-03-13 10:21:01
    日志系统主要有redo log(重做日志)和binlog(归档日志)。redo log是InnoDB存储引擎层的日志,binlog是MySQL Server层记录的日志, 两者都是记录了某些操作的日志(不是所有)自然有些重复(但两者记录的格式不同)。 ...

    日志系统主要有redo log(重做日志)和binlog(归档日志)。redo log是InnoDB存储引擎层的日志,binlog是MySQL Server层记录的日志, 两者都是记录了某些操作的日志(不是所有)自然有些重复(但两者记录的格式不同)。

    图来自极客时间的mysql实践,该图是描述的是MySQL的逻辑架构。

    redo log日志模块

    redo log是InnoDB存储引擎层的日志,又称重做日志文件,用于记录事务操作的变化,记录的是数据修改之后的值,不管事务是否提交都会记录下来。在实例和介质失败(media failure)时,redo log文件就能派上用场,如数据库掉电,InnoDB存储引擎会使用redo log恢复到掉电前的时刻,以此来保证数据的完整性。

    在一条更新语句进行执行的时候,InnoDB引擎会把更新记录写到redo log日志中,然后更新内存,此时算是语句执行完了,然后在空闲的时候或者是按照设定的更新策略将redo log中的内容更新到磁盘中,这里涉及到WALWrite Ahead logging技术,他的关键点是先写日志,再写磁盘。

    有了redo log日志,那么在数据库进行异常重启的时候,可以根据redo log日志进行恢复,也就达到了crash-safe

    redo log日志的大小是固定的,即记录满了以后就从头循环写。

    图片来自极客时间,该图展示了一组4个文件的redo log日志,checkpoint之前表示擦除完了的,即可以进行写的,擦除之前会更新到磁盘中,write pos是指写的位置,当write pos和checkpoint相遇的时候表明redo log已经满了,这个时候数据库停止进行数据库更新语句的执行,转而进行redo log日志同步到磁盘中。

    binlog日志模块

    binlog是属于MySQL Server层面的,又称为归档日志,属于逻辑日志,是以二进制的形式记录的是这个语句的原始逻辑,依靠binlog是没有crash-safe能力的

    redo log和binlog区别

    • redo log是属于innoDB层面,binlog属于MySQL Server层面的,这样在数据库用别的存储引擎时可以达到一致性的要求。
    • redo log是物理日志,记录该数据页更新的内容;binlog是逻辑日志,记录的是这个更新语句的原始逻辑
    • redo log是循环写,日志空间大小固定;binlog是追加写,是指一份写到一定大小的时候会更换下一个文件,不会覆盖。
    • binlog可以作为恢复数据使用,主从复制搭建,redo log作为异常宕机或者介质故障后的数据恢复使用。

    一条更新语句执行的顺序

    update T set c=c+1 where ID=2;

    • 执行器先找引擎取 ID=2 这一行。ID 是主键,引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中,就直接返回给执行器;否则,需要先从磁盘读入内存,然后再返回。
    • 执行器拿到引擎给的行数据,把这个值加上 1,比如原来是 N,现在就是 N+1,得到新的一行数据,再调用引擎接口写入这行新数据。
    • 引擎将这行新数据更新到内存中,同时将这个更新操作记录到 redo log 里面,此时 redo log 处于 prepare 状态。然后告知执行器执行完成了,随时可以提交事务。
    • 执行器生成这个操作的 binlog,并把 binlog 写入磁盘。
    • 执行器调用引擎的提交事务接口,引擎把刚刚写入的 redo log 改成提交(commit)状态,更新完成。

    这个update语句的执行流程图,图中浅色框表示是在 InnoDB 内部执行的,深色框表示是在执行器中执行的。

    https://www.linuxidc.com/Linux/2018-11/155431.htm

     

    更多企业内的技术应用和使用技巧,请移步至我的公众号【程序员实用技能】

    图片

    ----------------------------------------------------

    innodb事务日志包括redo log和undo log。redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作。

    undo log不是redo log的逆向过程,其实它们都算是用来恢复的日志:
    1.redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置)。
    2.undo用来回滚行记录到某个版本。undo log一般是逻辑日志,根据每行记录进行记录。

    https://juejin.im/entry/5ba0a254e51d450e735e4a1f

    ----------------------------------------------------

    一、重做日志(redo log)

    作用:

    确保事务的持久性。防止在发生故障的时间点,尚有脏页未写入磁盘,在重启mysql服务的时候,根据redo log进行重做,从而达到事务的持久性这一特性。

    二、回滚日志(undo log)

    作用:

    保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读

    三、二进制日志(binlog):

    作用:

    用于复制,在主从复制中,从库利用主库上的binlog进行重播,实现主从同步。 
    用于数据库的基于时间点的还原。

    https://blog.csdn.net/u012834750/article/details/79533866

    --------------------------------------------------------

    数据库数据存放的文件称为data file;日志文件称为log file;数据库数据是有缓存的,如果没有缓存,每次都写或者读物理disk,那性能就太低下了。数据库数据的缓存称为data buffer,日志(redo)缓存称为log buffer;既然数据库数据有缓存,就很难保证缓存数据(脏数据)与磁盘数据的一致性。比如某次数据库操作:

    update driver_info set driver_status = 2 where driver_id = 10001;

    更新driver_status字段的数据会存放在缓存中,等待存储引擎将driver_status刷新data_file,并返回给业务方更新成功。如果此时数据库宕机,缓存中的数据就丢失了,业务方却以为更新成功了,数据不一致,也没有持久化存储。

    上面的问题就可以通过事务的ACID特性来保证。

    BEGIN trans;

    update driver_info set driver_status = 2 where driver_id = 10001;

    COMMIT;

    这样执行后,更新要么成功,要么失败。业务方的返回和数据库data file中的数据保持一致。要保证这样的特性这就不得不说存储引擎innodb的redo和undo日志。

    redo日志、undo日志:

    存储引擎也会为redo undo日志开辟内存缓存空间,log buffer。磁盘上的日志文件称为log file,是顺序追加的,性能非常高,注:磁盘的顺序写性能比内存的写性能差不了多少。

    undo日志用于记录事务开始前的状态,用于事务失败时的回滚操作;redo日志记录事务执行后的状态,用来恢复未写入data file的已成功事务更新的数据。例如某一事务的事务序号为T1,其对数据X进行修改,设X的原值是5,修改后的值为15,那么Undo日志为<T1, X, 5>,Redo日志为<T1, X, 15>。

    梳理下事务执行的各个阶段:

    (1)写undo日志到log buffer;

    (2)执行事务,并写redo日志到log buffer;

    (3)如果innodb_flush_log_at_trx_commit=1,则将redo日志写到log file,并刷新落盘。

    (4)提交事务。

    可能有同学会问,为什么没有写data file,事务就提交了?

    在数据库的世界里,数据从来都不重要,日志才是最重要的,有了日志就有了一切。

    因为data buffer中的数据会在合适的时间 由存储引擎写入到data file,如果在写入之前,数据库宕机了,根据落盘的redo日志,完全可以将事务更改的数据恢复。好了,看出日志的重要性了吧。先持久化日志的策略叫做Write Ahead Log,即预写日志。

    分析几种异常情况:

    • innodb_flush_log_at_trx_commit=2(innodb_flush_log_at_trx_commit和sync_binlog参数详解)时,将redo日志写入logfile后,为提升事务执行的性能,存储引擎并没有调用文件系统的sync操作,将日志落盘。如果此时宕机了,那么未落盘redo日志事务的数据是无法保证一致性的。
    • undo日志同样存在未落盘的情况,可能出现无法回滚的情况。

    checkpoint:

    checkpoint是为了定期将db buffer的内容刷新到data file。当遇到内存不足、db buffer已满等情况时,需要将db buffer中的内容/部分内容(特别是脏数据)转储到data file中。在转储时,会记录checkpoint发生的”时刻“。在故障回复时候,只需要redo/undo最近的一次checkpoint之后的操作。

    https://blog.csdn.net/bluejoe2000/article/details/80349499

     

    更多企业内的技术应用和使用技巧,请移步至我的公众号【程序员实用技能】

    图片

    展开全文
  • redo log

    2021-05-13 13:56:29
    文章目录@[toc]redo logredo log基本概念日志块(log block)日志块头log body(redo log的格式)redo log group和redo log fileredo log groupredo log file日志刷盘的规则数据页刷盘的规则redo log作用redo log 和 bin...
  • REDO扩展 – REDO与OWI 我觉得这节的内容是最重要的,前面学习诸多REDO的理论,其实就是为了快速理解REDO相关OWI的原理,知道产生原因以至于快速拿出解决方案。 OWI,Oracle Wait Interface,指的是记录和观察集成所...
  • redo日志

    2021-04-18 17:26:48
    redo日志记录了事务执行过程中都修改了哪些内容 事务提交时只将提交过程中产生的redo日志刷新到磁盘,而不是将所有修改过的页面都刷新到磁盘。这样做优先两个好处: redo日志占用的空间非常小 redo日志是顺序写入...
  • Oracle DG下修改redo log和standby redo log日志大小.txt
  • redo internal

    2019-02-20 08:18:06
    一、什么是redoredo log记录了数据库所有变更的历史记录,在对数据库做任何的修改之前,都必须先生成redo,在将任何脏数据库写入datafile之前,都必须保证该脏数据库对应的redo已经写入到redo log file...
  • REDO是一个综合的应用程序工具,可根据变异调用结果(VCF文件)来识别细胞器中的RNA编辑事件。 它是一套Perl脚本,可以在任何安装了Perl和R Environment的操作系统中轻松且直接地工作。 REDO中使用了严格的规则依赖...
  • 英文解释:名词:两种流程,redo重做流程,undo撤销还原流程;或则是redo日志与undo段的简称动词:redo即重做,undo即撤销还原。翻译有时候为了简单,常把动词和名称混用。不同场景不同的使用。1.redo记录了什么:...
  • mysql redo查看_mysql redo

    2021-01-19 23:05:26
    查看redo使用情况:1.show engine innodb2.select name,count from information_schema.innodb_metrics where name in('log_lsn_current','log_lsn_last_checkpoint);3.select * from sys.metrics where variable_...
  • InnoDB redo

    2018-10-22 22:45:00
    一、REDO简介 redo log用于记录除了 SELECT的所有操作。 重做日志作用是:当崩溃恢复期间用于前滚已经提交的数据,回滚未提交的数据。 MySQL以循环方式写入重做日志文件。 重做日志的增加以LSN值表示。 切换...
  • redo buffer大小由参数log_buffer决定。 在redo buffer中的每条记录称为redo entire。 LGWR将redo buffer中的redo entire写到重做日志文件中,LGWR进程只有1个。 LGWR在下列情况下对重做日志文件进行写入 commit发生...
  • 43 直接强行把redo log写入磁盘?非也,揭秘redo log buffer.pdf
  • (1)redo log的大小可以影响 DBWR 和 checkpoint ;(2)arger redo log files provide better performance. Undersized logfiles increase checkpoint activity and reduce performance.大的log file可以提供更好的...
  • 在Oracle数据库中,有一种日志文件叫做重做日志文件,他就是大家俗称的:redolog。在redolog中又分为两种:在线重做日志与归档日Redo log 重做日志在Oracle数据库中,有一种日志文件叫做重做日志文件,他就是大家...
  • 每个standby redo log file 至少要和primary database的redo log 一样大,为了方便管理,Oracle 建议主备库的redo log 设置成一样的大小。SQL> SELECT GROUP#, BYTES/1024/1024 M FROM V$LOG;2.Standby redo log ...
  • redolog

    2018-01-19 20:58:00
    redolog记录的是,硬盘上的页,和内存中的页之间不一致的地方。再细一点说,硬盘上的数据,是之前的结果。而内存中的数据,是现在的结果。 redolog 硬盘,内存,是三角关系,两者确定第三者,所以要二次写,所以...
  • redo log称为重做日志,用来保证事务的原子性和持久性。undo log用来保证事务的一致性。redo恢复提交事务修改的页操作,而undo回滚行记录到某个特定版本。因此两者记录的内容不同,redo通常是物理日志,记录的是页的...
  • 1.在一个dg环境中,配置的是实时同步,需要增加主库的redo大小和组数,本来是一个很简单的问题,解决思路是: a、先备库增加standby redo 删除老standby redo, b、然后主库增加redo删除老redo, c、备库增加新redo删除老...
  • undo redo stack is spent in Gemini instead of actually setting values. <p>This commit changes the undo / redo stack into a single stack with an integer keeping track of what is undo and what is redo. ...
  • 在线修改online redo logfiles size 大小在线修改online redo logfiles size 大小oracle redolog size 过小有时候会导致性能问题,现在我们在线修改redolog,一般在业务量比较小的时候进行此操作1. 首先查看当前的...
  • redo 维护 oracle

    2011-01-25 19:55:14
    redo 维护redo 维护redo 维护redo 维护redo 维护redo 维护

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 20,670
精华内容 8,268
关键字:

redo