undo日志分析
undolog 结构
undolog 结构undolog是一个基于log-structured存储的分布式事务日志引擎，它的目标是在保证高吞吐和低延迟的同时，提供强一致性和高可靠性。
本文将详细介绍undolog的结构。
1. 概述undolog将所有的操作都视为事务，并以事务为单位进行管理和存储。
每个事务包括一个或多个操作（例如读取、写入、修改等），并由一个全局唯一的事务ID来标识。
undolog将所有的事务日志划分为几个日志分区（Log Partition），每个分区包含若干日志段（Log Segment）。
2. 日志分区日志分区是undolog的基本单位，它可以是一个物理分区或者是一个逻辑分区。
undolog将一个物理分区划分为若干个逻辑分区，并将每个逻辑分区映射到一个或多个物理分区上。
这样，当一个逻辑分区达到其容量限制时，undolog可以自动将其数据迁移到其他物理分区上，从而实现动态扩容和平衡负载。
日志段是一个固定大小的文件，用于存储一组事务的日志。
undolog将所有的日志段组织成一个环形链表，形成一个不断增长的日志序列。
每个日志段包括一个头部（Header）和若干条日志记录（Log Record）。
3.1 头部每个日志段的头部包括如下信息：- 日志段ID：用于标识该日志段的全局唯一ID；- 下一个日志段ID：用于指向链表中下一个日志段的ID；- 上一个日志段ID：用于指向链表中上一个日志段的ID；- 日志条目数：该日志段中存储的日志记录数；- 日志总大小：该日志段中存储的所有日志记录（包括头部）的总大小。
- 事务ID：该日志记录所属的事务ID；- 日志类型：该日志记录的类型，包括：开始（start）、提交（commit）、中止（abort）、写入（write）和读取（read）；- 数据：该日志记录所涉及的数据，包括：键（key）和值（value）。
4. 索引为了快速定位每个事务的日志记录，undolog维护了一个基于B+树的索引结构。
Oracleredo与undo
Oracleredo与undoUndo and redoOracle最重要的两部分数据，undo 与redo，redo（重做信息）是oracle在线（或归档）重做⽇志⽂件中记录的信息，可以利⽤redo重放事务信息，undo（撤销信息）是oracle在undo段中记录的信息，⽤于撤销或回滚事务。
1 redo重做⽇志⽂件redo log，是数据库的事务⽇志，oracle维护着2类重做⽇志，在线重做⽇志⽂件和归档重做⽇志⽂件，归档⽇志⽂件就是重做⽇志的副本，系统将⽇志⽂件填满时arch进程会在另⼀个位置建⽴⼀个在线重做⽇志的副本每个oracle数据库⾄少有2个重做⽇志组，以便切换⽇志，每个⽇志组⾄少有1个⽇志组成员，这些在线重做⽇志⽂件是以循环写的⽅式使⽤，2 undo你对数据库执⾏修改时，数据库会⽣成undo信息，以便回滚到更改前的状态，undo⽤于取消⼀条语句或⼀组语句的作⽤，undo在数据库内部存放在⼀组特殊的段中，为undo段（回滚段 rollback segment），利⽤undo，数据库只是逻辑的恢复到原来的样⼦，所有修改都逻辑的取消，但是数据结构以及数据块本⾝在回滚后可能不⼤相同，对于undo⽣成对于直接路径操作不适⽤，直接路径操作能够绕过表上的undo⽣成。
SQL>set autotrace traceonly statisticsSQL>select*from t;--not first executeno rows selectedStatistics----------------------------------------------------------0 recursive calls0 db block gets3 consistent gets0 physical reads0 redo size995 bytes sent via SQL*Net to client374 bytes received via SQL*Net from client1 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)0 rows processedSQL>insert into t select*from all_objects;49789 rows created.SQL>rollback;Rollback complete.SQL>select*from t;no rows selectedStatistics----------------------------------------------------------0 recursive calls0 db block gets689 consistent gets -----I/O0 physical reads0 redo size995 bytes sent via SQL*Net to client374 bytes received via SQL*Net from client1 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)0 rows processedInsert导致⼀些块增加到表的⾼⽔位线(HWM),这些块没有因为回滚⽽消失，select extent_id, bytes, blocks from user_extentswhere segment_name = 'X' order by extent_id; 分配给表的存储空间—这个表没有使⽤任何区段3 undo 跟redo如何协作尽管undo信息存储在undo表空间或undo段中，但也会受到redo保护，会把undo信息当成表数据或索引数据⼀样，对undo的修改会⽣成⼀些redo，将记⼊重做⽇志，将undo数据增加到undo段中，并像其他部分的数据⼀样，在缓冲区缓存中得到缓存Insert-update-delete场景3.1 insertInsert语句，都会⽣成redo跟undo信息，插⼊发⽣后，如下图缓存了⼀下已修改的undo块，索引块和表数据块，这些块得到重做⽇志缓冲区相应条⽬的保护1假象现在系统崩溃，sga全部被清空，但是我们不需要sga的中的任何内容，重启动时就好像这个事务就没发⽣过，没有将任何修改的块刷新输出到磁盘，也没有任何redo信息刷新输出到磁盘，我们不需要这些undo或redo信息来实现实例失败恢复2假象：缓冲区缓存已满Dbwr进程要把已修改的块从缓存输出到磁盘，⾸先要求lgwr进程将保护这些数据库的redo条⽬输出到磁盘，dbwr在将任何修改的块输出到磁盘之前，都必须要求lgwr进程先刷新输出到redo⽇志，3.2 updateUpdate所带来的⼯作与insert⼤体⼀样，不过undo信息量更⼤，update，要保存系统的前映像，缓冲区中会有更多的undo块，为了撤销update，如果必要，已修改的数据库表和索引都会存在缓存中，其中重做⽇志有的已经输出到磁盘，有的还在redo buffer 中1 系统崩溃：启动时，oracle会读取重做⽇志，给定系统的当前状态，利⽤重做⽇志⽂件中对应的插⼊的redo条⽬，并利⽤仍在缓冲区中对应的redo条⽬，oracle会前滚插⼊，连接断开，oracle发现事务从未提交，因此将其回滚，利⽤undo，2 应⽤回滚事务Oracle发现这个事务的undo信息可能缓存在undo段中，也肯能已经刷新输出到磁盘，会把und信息应⽤到缓存中的数据和索引上，不在缓存中，则先要读⼊到缓存，恢复其原来的⾏，并刷新输出数据⽂件，回滚过程不涉及重组⽇志，只有恢复和归档才会读取重做⽇志，重做⽇志是⽤来写的，不⽤于读，3 deleteDelete 会⽣成undo⽇志，块将被修改，并把redo⽇志发送到重做⽇志缓冲区，与update类似4 commit已经修改的块放在缓冲区缓存中，可能已经输出到磁盘，重做这个事务所需的全部redo都安全的存放在磁盘上，undo信息会⼀直存在，除⾮undo段回绕并重⽤了这些undo块，4 提交和回滚处理Commit：commit并没有做太多的⼯作，Commit开销，频繁提交，会增加与数据库的往返同学，如果每个记录都提交，⽣成的往返通信量会⼤得多，每次提交时，必须等待redo写到磁盘，这会导致等待在commit之前可能：已经在sga中⽣成了undo 块，已经在sga中⽣成了已修改的数据块，已经在sga中⽣成了对应的2想的redo信息，取决于前3项的⼤⼩，已经这些花费的时间，前⾯的数据可能已经输出到磁盘，已经得到全部锁需要的锁在实际commit时， 1为事务⽣成⼀个scn（系统改变号），scn⽤于保证事务的顺序，并⽀持失败恢复，scn还⽤于保证数据库中的读⼀致性和检查点，每次有⼈commit，scn都会增加1。
mysql日志：redolog、binlog、undolog区别与作用
mysql⽇志：redolog、binlog、undolog区别与作⽤⼀、redo log 重做⽇志 作⽤：确保事务的持久性。
防⽌在发⽣故障的时间点，尚有脏页未写⼊磁盘，在重启mysql服务的时候，根据redo log进⾏重做，从⽽达到事务的持久性这⼀特性。
内容：物理格式的⽇志，记录的是物理数据页⾯的修改的信息，其redo log是顺序写⼊redo log file的物理⽂件中去的。
⼆、bin log 归档⽇志（⼆进制⽇志） 作⽤：⽤于复制，在主从复制中，从库利⽤主库上的binlog进⾏重播，实现主从同步。
⽤于数据库的基于时间点的还原。
内容：逻辑格式的⽇志，可以简单认为就是执⾏过的事务中的sql语句。
但⼜不完全是sql语句这么简单，⽽是包括了执⾏的sql语句（增删改）反向的信息，也就意味着delete对应着delete本⾝和其反向的insert；update对应着update执⾏前后的版本的信息；insert对应着delete和insert本⾝的信息。
binlog 有三种模式：Statement（基于 SQL 语句的复制）、Row（基于⾏的复制）以及 Mixed（混合模式）三、undo log 回滚⽇志 作⽤：保存了事务发⽣之前的数据的⼀个版本，可以⽤于回滚，同时可以提供多版本并发控制下的读（MVCC），也即⾮锁定读 内容：逻辑格式的⽇志，在执⾏undo的时候，仅仅是将数据从逻辑上恢复⾄事务之前的状态，⽽不是从物理页⾯上操作实现的，这⼀点是不同于redo log的。
redo log mysql，如果每次更新操作都要写进磁盘，然后磁盘要找到对应记录，然后再更细，整个过程io成本、查找成本都很⾼。
解决⽅案：WAL技术（Write-Ahead Logging）。
先写⽇志，再写磁盘。
具体来说，当有⼀条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log⾥⾯，并更新内存，这个时候更新就算完成了。
错误日志分析
该问题目前的分析：1、9312-A主板(1/13)忽然出现硬件故障，导致该单板不停复位。
Jan 19 2012 14:29:07 Quidway %%01CSSM/4/STACKBACKUP(l)[33]:This cluster CSS compete result is backup.Jan 19 2012 14:29:15 Quidway %%01ALML/4/CLOCKFAULT(l)[50]:The"CLK_33M_CHK" sensor15 of MPU board[1/13] detect clock signal faultJan 19 2012 14:29:15 Quidway %%01ALML/4/CLOCKFAULT(l)[51]:The"CLK_125M_CHK" sensor16 of MPU board[1/13] detect clock signal faultJan 19 2012 14:29:15 Quidway %%01ALML/4/CLOCKFAULT_RESUME(l)[55]:The "CLK_125M_CHK" sensor16 of MPU board[1/13] detect clock signal fault resume Jan 19 2012 14:29:15 Quidway %%01ALML/4/CLOCKFAULT(l)[56]:The"CLK_125M_CHK" sensor16 of MPU board[1/13] detect clock signal faultJan 19 2012 14:29:15 Quidway %%01ALML/3/CPU_RESET(l)[57]:The canbus node of MPU board[1/13] detects that CPU was reset.2、由于该单板的复位导致9312-A备板(1/14)也出现异常复位，应该是由于1/13单板复位导致，怀疑是1/13板一直复位，自动回退到了老的版本，此时出现主备板版本不一致引发。
InnoDB事务日志（redolog和undolog）详解
InnoDB事务⽇志（redolog和undolog）详解数据库通常借助⽇志来实现事务，常见的有undo log、redo log，undo/redo log都能保证事务特性，undolog实现事务原⼦性，redolog实现事务的持久性。
为了最⼤程度避免数据写⼊时io瓶颈带来的性能问题，MySQL采⽤了这样⼀种缓存机制：当query修改数据库内数据时，InnoDB先将该数据从磁盘读取到内存中，修改内存中的数据拷贝，并将该修改⾏为持久化到磁盘上的事务⽇志（先写redo log buffer，再定期批量写⼊），⽽不是每次都直接将修改过的数据记录到硬盘内，等事务⽇志持久化完成之后，内存中的脏数据可以慢慢刷回磁盘，称之为Write-Ahead Logging。
事务⽇志采⽤的是追加写⼊，顺序io会带来更好的性能优势。
为了避免脏数据刷回磁盘过程中，掉电或系统故障带来的数据丢失问题，InnoDB采⽤事务⽇志（redo log）来解决该问题。
⼀、先简单了解⼏个概念数据库数据存放的⽂件称为data file；⽇志⽂件称为log file；数据库数据是有缓存的，如果没有缓存，每次都写或者读物理disk，那性能就太低下了。
数据库数据的缓存称为data buffer，⽇志（redo）缓存称为log buffer。
内存缓冲池buffer pool如果mysql不⽤内存缓冲池，每次读写数据时，都需要访问磁盘，必定会⼤⼤增加I/O请求，导致效率低下。
所以Innodb引擎在读写数据时，把相应的数据和索引载⼊到内存中的缓冲池(buffer pool)中，⼀定程度的提⾼了数据读写的速度。
buffer pool：占最⼤块内存，⽤来存放各种数据的缓存包括有索引页、数据页、undo页、插⼊缓冲、⾃适应哈希索引、innodb存储的锁信息、数据字典信息等。
⼯作⽅式总是将数据库⽂件按页(每页16k)读取到缓冲池，然后按最近最少使⽤(lru)的算法来保留在缓冲池中的缓存数据。
undo日志
undo⽇志undo⽇志作⽤因⼀些原因（机器宕机/操作系统错误/⽤户主动rollback等)导致事务执⾏到⼀半，但这时事务的执⾏已经让很多信息修改了（提交前就会边执⾏边修改记录），但还有部分未执⾏，为了保证事务的⼀致性与原⼦性，要么全都执⾏成功，要么全都失败，所以就需要回滚，⽽rollback需要旧值依据，⽽这些旧值记录就存储在undo⽇志中。
redo⽇志记录记录时机InnoDB存储引擎在实际的进⾏增删改操作时，每操作⼀条记录都会先把对应的undo⽇志记录下来。
undo⽇志通⽤结构undo⽇志存储在类型为FIL_PAGE_UNDO_LOGO的页⾯中，⽽每条记录添加到数据页中时，都会隐式的⽣成两个列trix_id和roll_pointer，trix_id就是事务id，roll_pointer是指向记录对应的undo⽇志的⼀个指针end of record：本条undo⽇志在页中结束地址undo type：undo⽇志类型undo no：undo⽇志编号，事务没提交时，每⽣成⼀条undo⽇志就递增1table id：本条undo ⽇志对应记录所在table id（information_schema库中表innodb_sys_tables查看）主键各列信息列表：<len, value>关键列占⽤空间和真实值信息列表start of record：本条undo ⽇志在页中开始的地址各操作所对应的undo⽇志结构不同1. INSERT：回滚时，就是删除掉新增的这条记录。
暂时只考虑聚簇索引插⼊情况，因为⼆级索引也包含主键，所以删除时也会根据主键信息把⼆级索引中的内容也删除名称内容undo type TRX_UNDO_INSERT_REC2. DELETE：记录被删除时，该记录头部信息的delete_mask会置为1，且会根据头部信息中的next_record属性组成⼀个垃圾链表，⽽这个链表中各记录占⽤的空间可以被重⽤，数据页PAGE HEADER中有个PAGE_FREE属性记录了这个链表的头节点。
mysql日志redolog、undolog、binlog以及作用
mysql⽇志redolog、undolog、binlog以及作⽤什么是事务⽇志？事务要保证ACID的完整性必须依靠事务⽇志做跟踪，每⼀个操作在真正写⼊数据数据库之前，先写⼊到⽇志⽂件中如要删除⼀⾏数据会先在⽇志⽂件中将此⾏标记为删除，但是数据库中的数据⽂件并没有发⽣变化。
只有在(包含多个sql语句)整个事务提交后，再把整个事务中的sql语句批量同步到磁盘上的数据库⽂件。
在事务引擎上的每⼀次写操作都需要执⾏两遍如下过程：1. 先写⼊⽇志⽂件中写⼊⽇志⽂件中的仅仅是操作过程,⽽不是操作数据本⾝,所以速度⽐写数据库⽂件速度要快很多。
2. 然后再写⼊数据库⽂件中写⼊数据库⽂件的操作是重做事务⽇志中已提交的事务操作的记录。
⽇志组⼀般不⽌设置⼀个⽇志⽂件，⼀个⽂件写满之后使⽤另外⼀个⽇志⽂件提⾼服务器效率。
⽇志⽂件的⽇志同步到磁盘后空间会⾃动释放，单个⽇志⽂件不宜设置过⼤，如果⽇志⽂件过⼤mysql进程在把⽇志同步到数据⽂件的时候可能会崩溃。
事务⽇志⽤途事务⽇志可以帮助提⾼事务的效率，使⽤事务⽇志，存储引擎在修改表的数据的时候只需要修改其内存拷贝，再把该⾏为记录到持久在磁盘的事务⽇志中，⽽不⽤每次都将修改的数据本⾝持久到磁盘。
事务⽇志采⽤的是追加⽅式，因此写⽇志的操作是磁盘上⼀⼩块区域的顺序IO，⽽不像随机IO需要磁盘在多个地⽅移动。
所以采⽤事务⽇志的⽅式相对来说要快的多，事务⽇志持久后，内存中的修改在后台慢慢的刷回磁盘。
期间如果系统发⽣崩溃，存储引擎在重启的时候依靠事务⽇志⾃动恢复这部分被修改数据。
redo log在innoDB的存储引擎中，事务⽇志通过重做(redo)⽇志和innoDB存储引擎的⽇志缓冲(InnoDB Log Buffer)实现。
事务开启时，事务中的操作，都会先写⼊存储引擎的⽇志缓冲中，在事务提交之前，这些缓冲的⽇志都需要提前刷新到磁盘上持久化，这就是DBA们⼝中常说的“⽇志先⾏”(Write-Ahead Logging)。
redo和undo日志
redo和undo⽇志在数据库系统中，既有存放数据的⽂件，也有存放⽇志的⽂件。
⽇志在内存中也是有缓存Log buffer，也有磁盘⽂件log file，本⽂主要描述存放⽇志的⽂件。
MySQL中的⽇志⽂件，有这么两类常常讨论到：undo⽇志与redo⽇志。
1 undo1.1 undo是啥undo⽇志⽤于存放数据修改被修改前的值，假设修改 tba 表中 id=2的⾏数据，把Name=’B’ 修改为Name = ‘B2’ ，那么undo⽇志就会⽤来存放Name=’B’的记录，如果这个修改出现异常，可以使⽤undo⽇志来实现回滚操作，保证事务的⼀致性。
对数据的变更操作，主要来⾃ INSERT UPDATE DELETE，⽽UNDO LOG中分为两种类型，⼀种是 INSERT_UNDO（INSERT操作），记录插⼊的唯⼀键值；⼀种是 UPDATE_UNDO（包含UPDATE及DELETE操作），记录修改的唯⼀键值以及old column记录。
Id Name1A2B3C4D1.2 undo参数MySQL跟undo有关的参数设置有这些：1 mysql> show global variables like '%undo%';2 +--------------------------+------------+3 | Variable_name | Value |4 +--------------------------+------------+5| innodb_max_undo_log_size |1073741824 |6| innodb_undo_directory | ./ |7| innodb_undo_log_truncate |OFF |8| innodb_undo_logs |128 |9| innodb_undo_tablespaces |3 |10 +--------------------------+------------+1112 mysql> show global variables like '%truncate%';13 +--------------------------------------+-------+14 | Variable_name | Value |15 +--------------------------------------+-------+16| innodb_purge_rseg_truncate_frequency |128 |17| innodb_undo_log_truncate |OFF |18 +--------------------------------------+-------+innodb_max_undo_log_size控制最⼤undo tablespace⽂件的⼤⼩，当启动了innodb_undo_log_truncate 时，undo tablespace 超过innodb_max_undo_log_size 阀值时才会去尝试truncate。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.1 故障模式
• 1、错误数据输入 例如：电话号码的错误位和少输入一位。 解决方法：可以通过编写约束和触发器来找出被认为是错 误的数据。 • 2、介质故障 例如：磁盘故障 解决方法：可以通过与磁盘扇区相关联的奇偶校验检测到 • 3、灾难性故障 介质完全损坏，可以通过备份或者拷贝方法解决 • 4、系统故障 导致事务状态丢失的问题，比如掉电、软件错误。
日志恢复主要利用日志的两个重要规则
如果有日志记录<COMMIT T>，根据undo规则U2，事务T所做 的全部改变在此之前已写到磁盘上。因此当系统故障发生时， T自身不可能使数据库保持不一致的状态 如果在日志上发现<START T>记录，但未发现<COMMIT T> 记录，规则U1保证如果T在崩溃前改变了磁盘上的X，那么日 志中就会有<T,X,v>记录，并且该记录在崩溃发生前已被拷贝 到磁盘。
续1.2 事务
• 原语操作： 1、INPUT(X):将包含数据库元素X的磁盘块拷贝到主存缓 冲区 2、READ(X,t):将数据库元素X拷贝到事务的局部变量t。 即若X不在主存缓冲区中，此原语可将值赋给局部变量t 3、WRITE(X,t):将局部变量t拷贝到主存缓冲区中的数据元 素X 4、OUTPUT(X):将包含X的缓冲区中的块拷贝回磁盘
日志规 则重要 性举例
续2.2 日志恢复
按照日志恢复的顺序 原因：日志中可能有多个未提交的事务，并且可能有多个未提交的事务修改了X， 所以在日志在恢复值得顺序上必须是有计划的。 规则：恢复管理器从尾部开始扫描日志，过程中记住所有的<COMMIT T> 或<ABROT T>记录事务T。
向后扫 描，遇 到 <T,X,v>
指明所改变 数据库元素 的日志记录
改变的数据 库元素自身
COMMIT日 志记录
2.2 日志恢复
恢复原因：如果故障发生了，可能给定事务的某些数据库更新已经写入到 磁盘上，而同一事务的另一些更新尚未到达磁盘。如此破坏了数据库的原 子特性，数据库一致性也得不到保证。 恢复管理器：使用日志来将数据库恢复到某个一致的状态
1.2 事务
• 查询和修改数据库的进程称为事务 • 事务是数据库操作执行的单位
• 事务的四大特性：
A:原子性(Atomicity) 事务是数据库的逻辑工作单位，事务中包括的诸操作要么全做 B:一致性(Consistency) 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与 原子性是密切相关的。 C:隔离性(Isolation) 一个事务的执行不能被其他事务干扰。 D:持续性/永久性(Durability) 一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。要么全不做。
若扫描到 COMMIT 记录，则 什么也不 错，无需 撤销
若无COMMIT，则T是未 完成事务或一个中止事务。 必须将数据库中X的值改 为v，以防万一恰好在系 统崩溃前X已经被修改了
2.3 检查点——静止检查点
恢复需要检查整个日志 需要 检查 点原 因 采用undo类型的日志，一旦事务的COMMIT日志记录被写到磁盘上，该事务 的日志记录在恢复时就不在需要。但有时却不能删除它。原因在于许多事务 同时执行，可能会丢失某个活跃事务T的日志记录，从而不能在需要进行恢复 时用来撤销T。 1、停止接收新的事务 检查点 可以解 决的问 题 2、等到所有当前活跃的事务提交或中止并且在日志中写入 了COMMMIT或ABORT记录 3、将日志刷新到磁盘 4、写入日志记录<CKPT>，并再次刷新日志
事务未完成，撤销更改 事务未完成，撤销更改 可能到达磁盘，也可能未到 达，看是否包含COMMIT 不撤销T的结果
实例4——静止检查点
若日志的一种情况如下： 开 始
后 续
扫描规则 当我们看到<CKPT>记录时，则已经看到了所有未完成 的事务。由于只有在检查点结束后事务才能开始，因此 必然已经看到了关于未完成事务的所有日志记录。所以 没有碧瑶扫描<CKPT>以前的部分，并且事实上将改点 以前的日志删除或覆盖是安全的
数据库系统实现 ——undo日志
姓名：周兵 学号：1511414012
主要内容
• 1. 背景介绍
1.1 故障模式 1.2 事务
• 2.undo日志
2.1 日志规则 2.2 绍
• 控制数据访问两大问题： 1.1 当系统故障发生时数据必须收到保护，保护数据完整性 2.1 数据不能仅仅因为几个本身无措的查询或数据库更新同 时进行就受到破坏。 • 日志支持数据库的可恢复性 • 恢复是故障发生后使用日志重建对数据库所做更新的过程
续2 undo日志
2.1 日志规则
U1：如果事务T改变了数据库元 素X，那么形如<T,X,v>的日志 记录必须在X的新值写到磁盘之 前写到磁盘中 两个重要 规则 U2：如果事务提交，则其 COMMIT日志记录必须在事务 改变所有的数据库元素先写到磁 盘之后写到磁盘中
续2.1 日志规则
规则U1和U2与一个事物相关内容写入到磁盘的 顺序
缺点：进行 检查点时必 须关闭系统
5、重新开始接收事务
2.3 检查点——非静止检查点
非静止检查点优势：在系统进行检查点时允许新事务进入
写入日志记录<START CKPT(T1….k)>并刷新日志，其中T是所有活 跃事务的名字或标识符
非静 止检 查点 步骤
等待T1,…,k中的所有事务提交或中止，但允许其他事务开始
2 undo日志
• 日志是日志记录构成的文件，每个日志记录记载有关某个 事务已做的事的某些情况 • 事务终止不提交原因：
事务自身的代码中有某些错误情况。 也可能由于一个或多个原因需要中止事务。比如事务可能陷入死锁中，此时 该事物和其它事务各自占有其他事务等待的某个资源。
• 日志记录的形式
1 <START T>：事务开始 2 <COMMIT T>：事务已完成且对数据元素不会有修改 3 <ABORT T>：事务T不能成功完成
当T1，…,k都已完成时，写入日志记录<END CKPT>并刷新日志
实例1——原语步骤序列
事务T可表述为下面6个相关步骤的序列
则原语操作步骤为：
实例2——undo日志的建立
事务T可表述为下面6个相关步骤的序列
则undo日志的建立如下：
实例3——undo日志的恢复
根据规则U1，使用相应 的日志记录撤销更改