UNDO相关问题总结（四）

最新推荐文章于 2024-08-26 23:54:25 发布
原创 最新推荐文章于 2024-08-26 23:54:25 发布 · 2.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#oracle #数据库 #undo #dba

这次主题继续介绍undo相关的内容，主要讲述undo数据文件丢失的处理示例（1），这次示例的处理方法简单，下一篇介绍一个更加复杂的处理示例。
模拟环境
os: linux x86-64
db: oracle 11gr2
mode: archivelog

模拟过程
1、用户发起事务（insert），未提交
2、shutdown abort 数据库
3、模拟undo数据文件丢失
4、数据库mount状态下offline drop掉undo数据文件
5、alter database open 数据库
6、完成后续处理

预备知识
"_offline_rollback_segments"/"_corrupted_rollback_segments"两个参数的解释:
if the rollback segments corrupt,we should recover it from bacup.sometimes there's no backup or it's not necessary to recover,we maybe consider using undocument parameter to avoid access these rollback segments,Oracle provides "_offline_rollback_segments" and "_corrupt_rollback_segments",before use them,we should be clear the difference between them.when opening a database,any rollback segments listed in "_offline_rollback_segments" or "_corrupted_rollback_segments" parameter:
  • are not scanned,and any active transactions are neither marked as dead nor rolled back;
  • appear offline in undo$
  • can't be acquered by instance for new transaction;
  • note that although the rollback segments listed in "_offline_rollback_segments",oracle actually reads the segemnts to find transaction status and gather undo records to perform rollback,if a corrupt block is found,the oracle will still fail.if an open ITL is found to associated with "_corrupted_rollback_segments",the segment is not read to find the transaction status
  • it is as though the rollback segment had been dropped,the transaction is assumed to be commited and delayed block cleanout is performed;
  • so the transaction was not commited,logical corruption will occur

以下描述转载于askmaclean博客：

_OFFLINE_ROLLBACK_SEGMENTS(offline undo segment list)隐藏参数(hidden parameter)的独有作用：

  • 在实例startup启动并open database的阶段仍将读取_OFFLINE_ROLLBACK_SEGMENTS所列出的Undo segments(撤销段/回滚段)，若访问这些undo segments出现了问题则将在alert.log和其他TRACE中体现出来，但不影响实际的startup进程
    • 若查询数据块发现活跃的事务，并ITL指向对应的undo segments则：
    • 若读取undo segments的transaction table事务表发现事务已提交则做数据块的清除
    • 若读取发现事务仍活动未commit，则生成一个CR块拷贝
    • 若读取该undo segments存在问题(可能是corrupted讹误，可能是missed丢失)则产生一个错误并写出到alert.log，查询将异常终止
  • 若DML更新相关的数据块会导致服务进程为了恢复活跃事务而进入死循环消耗大量CPU，解决方法是通过可以进行的查询工作重建相关表 

_CORRUPTED_ROLLBACK_SEGMENTS(corrupted undo segment list)隐藏参数所独有的功能:

  • 在实例启动startup并open database的阶段_CORRUPTED_ROLLBACK_SEGMENTS所列出的undo segments(撤销段/回滚段)将不会被访问读取
  • 所有指向这些被_CORRUPTED_ROLLBACK_SEGMENTS列出的undo segments的事务都被认为已经提交了commit，和这个undo segments已经被drop时类似
    • 这将导致严重的逻辑讹误（数据不一致）
    • 如果数据字典上有活跃事务那么将更糟糕，数据字典逻辑讹误会造成数据库管理问题
    • 如果bootstrap自举核心对象有活跃事务，那么将无法忽略错误ORA-00704: bootstrap process failure错误，导致无法强制打开数据库
  • 衷心地建议用_CORRUPTED_ROLLBACK_SEGMENTS这个参数打开数据库后导出数据并重建数据库，这个参数使用的后遗症可能很顽固
  • Oracle公司内部有叫做TXChecker的工具可以检查问题事务 
示例

（1）模拟undo数据文件丢失
[oracle@netdbhost dbs]$ sqlplus dbmon/dbmon_123
SQL*Plus: Release 11.2.0.1.0 Production on Mon May 5 10:23:55 2014
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> create table test as select * from dba_objects;
Table created.
SQL> select count(*) from test;
  COUNT(*)
----------
     71896
SQL> insert into test select * from test;
71896 rows created.
SQL> alter system flush buffer_cache;
System altered.
SQL> quit
SQL> shutdown abort;
ORACLE instance shut down.
SQL> host mv /u01/test/test/undotbs1.dbf /u01/test/test/undotbs1.dbfbak


（2）启动数据库报错，提示undo文件不存在
SQL> startup
ORACLE instance started.
Total System Global Area 1369579520 bytes
Fixed Size                  2213216 bytes
Variable Size             905972384 bytes
Database Buffers          452984832 bytes
Redo Buffers                8409088 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: '/u01/test/test/undotbs01.dbf'

（3）查询undo文件的文件名，并offline drop 掉（这种方式处理后，数据库可以open成功！！）
SQL> select name from v$datafile where file#=3;
NAME
--------------------------------------------------------------------------------
/u01/test/test/undotbs01.dbf
SQL> alter database datafile '/u01/test/test/undotbs01.dbf' offline drop;    ----直接offline drop
Database altered.

(4)open数据库，这时数据库可以open成功！查看数据库内undo段的状态
SQL> alter database open;                      ---这种情况下，数据库可以open成功！
Database altered.
SQL> select status,count(*) from dba_rollback_segs group by status;
STATUS             COUNT(*)
---------------- ----------
NEEDS RECOVERY           10
ONLINE                    1
SQL> select usn,status from v$rollstat;
       USN STATUS
---------- ---------------
         0 ONLINE
SQL> col segment_name format a30
SQL> set linesize 200
SQL> select segment_name,status from dba_rollback_segs where status='NEEDS RECOVERY';
SEGMENT_NAME                   STATUS
------------------------------ ----------------
_SYSSMU1_3780397527$           NEEDS RECOVERY
_SYSSMU2_2232571081$           NEEDS RECOVERY
_SYSSMU3_2097677531$           NEEDS RECOVERY
_SYSSMU4_1152005954$           NEEDS RECOVERY
_SYSSMU5_1527469038$           NEEDS RECOVERY
_SYSSMU6_2443381498$           NEEDS RECOVERY
_SYSSMU7_3286610060$           NEEDS RECOVERY
_SYSSMU8_2012382730$           NEEDS RECOVERY
_SYSSMU9_1424341975$           NEEDS RECOVERY
_SYSSMU10_3550978943$          NEEDS RECOVERY
10 rows selected.

（5）重建新的undo表空间（这一步也可以延后执行，影响不大）
SQL> create undo tablespace undo2 datafile '/u01/test/test/undo2.dbf' size 50m;
Tablespace created.
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS
UNDO2
6 rows selected.
SQL> show parameter undo       
NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ------------------------------
_undo_autotune                       boolean                          FALSE
undo_management                      string                           AUTO
undo_retention                       integer                          1800
undo_tablespace                      string                           UNDOTBS1
SQL> alter system set undo_tablespace='undo2';
System altered.
SQL> alter system set undo_management=manual  scope=spfile;   ---调整为手工管理，执行后续的扫尾工作（drop rollbacksegment 的执行）
System altered.

（6）重新启动数据库，通过pfile来启动，同时将丢失undo文件中的undo段都通过隐含参数（_offline_rollback_segments）屏蔽掉，告知oracle这写回滚段已经丢次，如果数据库内有数据块需要用到这些回滚段，则默认数据块内的数据已经提交
SQL> create pfile='/home/oracle/dhtest.ora' from spfile;
File created.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
*.undo_management=manual
*._offline_rollback_segments=('_SYSSMU1_3780397527$','_SYSSMU2_2232571081$','_SYSSMU3_2097677531$','_SYSSMU4_1152005954$','_SYSSMU5_1527469038$','_SYSSMU6_2443381498$','_SYSSMU7_3286610060$','_SYSSMU8_2012382730$','_SYSSMU9_1424341975$','_SYSSMU10_3550978943$')
SQL> startup pfile=/home/oracle/dhtest.ora
ORACLE instance started.
Total System Global Area 1369579520 bytes
Fixed Size                  2213216 bytes
Variable Size             905972384 bytes
Database Buffers          452984832 bytes
Redo Buffers                8409088 bytes
Database mounted.
Database opened.
SQL> select count(*) from dh.test;             ---检查数据发现，为提交的数据默认为提交了。                                
  COUNT(*)
----------
    143792
SQL> select status,count(*) from dba_rollback_segs group by status;
STATUS             COUNT(*)
---------------- ----------
NEEDS RECOVERY           10
OFFLINE                  10
ONLINE                    1

（7）手工删除丢失undo数据文件中的undo段
SQL> drop rollback segment  "_SYSSMU1_3780397527$";
drop rollback segment  "_SYSSMU2_2232571081$";
drop rollback segment  "_SYSSMU3_2097677531$";
drop rollback segment  "_SYSSMU4_1152005954$";
drop rollback segment  "_SYSSMU5_1527469038$";
drop rollback segment  "_SYSSMU6_2443381498$";
drop rollback segment  "_SYSSMU7_3286610060$";
drop rollback segment  "_SYSSMU8_2012382730$";
drop rollback segment  "_SYSSMU9_1424341975$";
drop rollback segment  "_SYSSMU10_3550978943$";
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
Rollback segment dropped.
SQL> 
SQL> select status,count(*) from dba_rollback_segs group by status;
STATUS             COUNT(*)
---------------- ----------
OFFLINE                  10
ONLINE                    1

（8）删除原先的undo表空间，重新启动，将undo_management改回自动，同时去掉隐含参数，至此数据库恢复完毕
SQL> drop tablespace undotbs1 including contents and datafiles;
Tablespace dropped.
SQL> 
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 1369579520 bytes
Fixed Size                  2213216 bytes
Variable Size             905972384 bytes
Database Buffers          452984832 bytes
Redo Buffers                8409088 bytes
Database mounted.
Database opened.
SQL> 
SQL> show parameter undo
NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ------------------------------
_undo_autotune                       boolean                          FALSE
undo_management                      string                           MANUAL
undo_retention                       integer                          1800
undo_tablespace                      string                           undo2
SQL> alter system set undo_management=auto scope=spfile;
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 1369579520 bytes
Fixed Size                  2213216 bytes
Variable Size             905972384 bytes
Database Buffers          452984832 bytes
Redo Buffers                8409088 bytes
Database mounted.
Database opened.
oracle清理undo空间,删除Oracle Undo表空间
weixin_36488954的博客
04-10 3474
近期处理了一次删除、重建Undo表空间的事情，有些细节还是值得记下来备忘。事情的起因是工程师需要将分布在不同ASM磁盘组里的Oracle数据库文件，迁移到新建的ASM磁盘组，操作过程中，错误的删除了Undo磁盘组的所有文件。版本 11.2.0.4， RAC环境——测试、准生产环境；下文操作不保证在“生产环境”无害。Step 1：考虑新建Undo Tablespace，然后修改各个实例(Instan...
释放oracle undo表空间,undo表空间释放
weixin_42453228的博客
04-06 5610
一.概述:使用IMPDP工具导入大表(166G)数据时,报undo表空间不能扩展,导入工作失败.手工停止了impdp后,undo表空间存在无法自动释放的故障.本文主要描述如何通过重建undo表空间来手工释放undo表空间.数据库环境的描述:OS: AIX 6.1+HACMP 5.3DB: ORACLE 10.2.0.5 RAC二.问题的描述impdp 导入数据时,报ora-30036错误$impd...
学习笔记-事务与回滚段
wx370092877的博客
03-11 1594
1.常用事务操作 Oracle相关事务的SQL操作主要包含 insert:数据插入 update：数据更新 delete：数据删除 merge：合并操作 select …for update：锁定选择数据 2.事务的ACID原则： 1）A：原子性—事务是原子级的、不可分割的有机体，这意味着，事务过程修改是不能分割的，即过程修改或者全部执行成功，或者全部执行失败回滚，不能存在部分成功部分失败的场景；...
commit提交报错
H_duolalu的博客
11-17 732
subject may not be empty [subject-empty]
undo offline，一个不大不小的故障
07-13 444
周末，夜，放松了一天，周末的夜晚无所事事，本打算吃完了看看片，看完了睡睡觉，晃晃悠悠过周末。时近晚上10点，突然接到一个客户电话，一看号码，心说这可不好，肯定出问题了，希望不是大事。。。电话里，客户看样子还挺着急，原来是数据库起...
git commit 提交时无法提交报错
qq_47755376的博客
11-25 4340
git commit 提交时报错 fatal: Unable to create ‘e:/git/Android/XXXXXX/.git/index.lock’: File e xists. Another git process seems to be running in this repository, e.g. an editor opened by ‘git commit’. Please make sure all processes are terminated then try again.
互联网大厂高频面试题基本总结回顾（含笔试高频算法整理）
热门推荐
张彦峰的博客
04-03 176万+
1.自我介绍+项目介绍+项目细节/难点提问-------这个主要看个人的经历了，每个人都不一样 2.基础知识点考核---------还是可以去增强自己的，也是这次的主要的一些总结思路 3.算法题-----------一般都是LeetCode高频题，这个得在找工作之前的好好的练习(d对常见的高频题进行总结分析，见对应的链接提示)
MySQL日志篇之undo-log、redo-log、bin-log
vbgesab的博客
07-14 994
叨叨絮絮下来，就大致将MySQL中的一些常见、较为重要的日志讲明白啦，其实重点搞清楚即可，其他的会在后续篇章中再次提到，最后稍微总结一下这三个比较核心的日志：•undo-log：主要用于实现事务ACID原则中的原子性和MVCC机制。•redo-log：主要用于实现事务原则中的持久性，确保事务提交后就不会丢失。•bin-log：主要结合redo-log实现事务原则中的一致性，确保事务提交前后，数据的一致。
Mysql-redo logs,binlog以及undo logs的作用及区别
wendao76的专栏
08-26 1113
Redo logs是InnoDB存储引擎使用的一种日志文件，记录了对数据库缓冲池中的数据页所做的物理更改。用途：在系统崩溃后，redo logs用于恢复未完成的事务，确保数据的一致性和持久性。通过write-ahead logging（WAL）机制，确保所有的更改都被持久化到磁盘。Redo Logs是InnoDB存储引擎中用于崩溃恢复的重要机制。通过write-ahead logging确保数据更改被持久化。通过合理的配置和管理，可以确保数据的安全性和系统性能。
oracle 9i UNDO表空间数据文件丢失恢复
07-06
#### 四、离线并删除丢失的UNDO表空间数据文件 - **离线丢失的数据文件**： - 执行命令`ALTER DATABASE DATAFILE 'D:\oracle\oradata\orcl\undotbs01.dbf' OFFLINE DROP;`来离线并删除丢失的数据文件。这里需要...
[Oracle] 解析在没有备份的情况下undo损坏怎么办
12-16
如果Oracle在运行中很不幸遇到undo损坏，当然最好的方法是完全恢复，不过如果没有备份，可以采用一种非常规的手段（利用Oracle的隐藏参数），如果此时undo包含未提交的事务，会造成一点点的数据丢失（一般都是可忍受的），如果没有未提交的事务，则不会有数据丢失。其主要步骤有： 1. 修改undo表空间管理为手动；2. 设置隐藏参数(_offline_rollback_segments或_corrupted_rollback_segments)标识受影响的回滚段，使Oracle忽略其上的未提交事务；3. 手动删除受影响的回滚段和undo表空间，然后重建新的undo表空间；4. 还原undo表
处理undo回滚段问题
MissYouFY的博客
10-11 560
删除undo表空间失败，显示有活动的回滚段SQL> drop tablespace undotbs1 including contents and datafiles; drop tablespace undotbs1 including contents and datafiles * ERROR at line 1: ORA-01548: active rollback segment '_SY
oracle删除隐含参数,oracle中涉及到的隐含参数的解决办法
weixin_33212799的博客
04-04 303
隐含参数回滚段隐含参数：01)_offline_rollback_segments02)_corrupted_rollback_segmentsORA著名错误方法² Undo故障发生600,603错误信息！解决方案：1． 试着shutdownabortstartup3次2． 设置事件event="immediatetracenameadjust_scnlevel...
Oracle的临时表空间和UNDO表空间对应的文件丢失后的处理
01-17 109
数据库的临时文件和undo文件不需要做备份,丢失后可以恢复,数据不会有丢失. 一,临时表空间的文件丢失后,在数据库启动后自动创建,不需要做干预. 模拟:在数据库shutdown后将临时文件删除,启动的时候发现自动创建. 二,undo表空间对应的文件丢失. 模拟:在数据库shutdown后将undo文件删除,启动的时候出错: ORA-01157: cannot identify/lock ...
undo原理详解
weixin_43475880的博客
08-02 2578
undo作用 undo是datafile文件里面的内容，存放datafiles读出的数据块的前镜像，提供以下四种情况所需要的信息。 回滚事务：rollback 读一致性：正在做dml操作的数据块，事务结束前，其他用户读undo表中的事务前镜像 实例恢复：instance recover（undo--->rollback）smon全程监控，前滚再回滚 闪回查询：flashback query，flashback table undo表坏了，dml操作将不能进行。有时候内存中undo还有，..
_OFFLINE_ROLLBACK_SEGMENTS 和 _CORRUPTED_ROLLBACK_SEGMENTS的区别
weixin_34200628的博客
11-16 236
_OFFLINE_ROLLBACK_SEGMENTS 和 _CORRUPTED_ROLLBACK_SEGMENTS的这两个参数可以强制打开数据库，但是open后，最好导出，重建库，然后再导入。对这两个参数不是很了解，直到看到了maclean的帖子，下面是帖子地址_CORRUPTED_ROLLBACK_SEGMENTS隐藏参数http://www.askmaclean.com/...
7.1 - oracle管理undo数据
qq_41141058的博客
09-01 552
第七课 管理undo数据 还原撤销undo数据: oerr ora 01555 快照过旧 实例自动恢复： 1、前滚—应用redo 2、回滚—应用undo，回滚未提交事务 redo不能丢，undo也不能丢，否则数据库无法open select * from v$transaction; create table t_undo(id int,name varchar2(20)); insert i...
oracle手工释放undo,Linux下释放 Oracle 数据库 UNDO 表空间
weixin_36378771的博客
04-07 388
检查数据库表空间占用空间情况:select tablespace_name,sum(bytes)/1024/1024/1024 GB from dba_data_files group by tablespace_name union all select tablespace_name,sum(bytes)/1024/1024/1024 GB from dba_temp_files group ...
UNDO TABLESPACE切换后，旧的长时间没有完全OFFLINE，案列：
Vage Fang的Oracle
07-13 1326
案列： 由于生产库impdp导入一个分区表，期间出了问题，终止了导入，但是undo tablespace增长飞快增长到300G了，且经过两天才降下来，但是undo tablespace如果是自动扩展，只会扩展，当事务都结束了它自己也不会收缩的，所以只能手工去收缩。 于是创建一组新的undo tablespace，命名为undotbs2 alter system set
redolog和undolog
最新发布
04-19
<think>好的，我现在需要详细回答用户关于MySQL中redo log和undo log的区别与作用的问题。用户已经提供了一些站内引用，我需要结合这些引用以及之前回答中的内容来构建一个全面且准确的解释。 首先，我需要明确redo log和undo log的基本概念，然后分析它们的不同点，包括功能、存储位置、生命周期、日志类型、恢复方向以及关联事务等方面。同时，用户提到的引用中有关于两阶段提交和日志结构的内容，这些也需要整合到回答中，确保覆盖关键点。 接下来，我应该检查之前的回答是否已经涉及了这些日志类型。在之前的回答中，用户主要关注错误日志、二进制日志、慢查询日志和通用查询日志，而redo log和undo log属于事务日志，需要在此次回答中详细展开。 需要确保回答结构清晰，分点说明，使用用户要求的格式，如行内数学表达式用$...$，独立公式用$$...$$，并且正确引用提供的参考资料。同时，生成相关问题，帮助用户进一步理解。 另外，要注意引用标记的正确使用，例如引用[^1]、[^2]等，这些需要与用户提供的引用对应起来。例如，用户提供的引用[1]提到redo log和binlog的区别，引用[4]涉及两阶段提交和恢复机制，这些都需要在适当的位置引用。 最后，总结redo log和undo log的区别与作用，确保内容准确，语言简洁，符合用户要求的中文回答，并生成相关问题供用户参考。</think>### MySQL中redo log与undo log的对比解析 --- #### 一、核心概念与作用对比 1. **redo log（重做日志）** - **功能定位**：InnoDB存储引擎层日志，确保事务的**持久性**（Durability） - **核心作用**： - 记录物理层面的数据页修改（例如：$page\_no=5$的页中偏移量$offset=128$处更新为值$0x1A3F$）[^1][^4] - 用于崩溃恢复时**重放未写入数据文件的修改** - **写入机制**： - 采用**循环写入**模式（固定大小文件组） - 通过`innodb_flush_log_at_trx_commit`参数控制刷盘策略[^4] 2. **undo log（回滚日志）** - **功能定位**：实现事务的**原子性**（Atomicity）与多版本并发控制（MVCC） - **核心作用**： - 记录事务修改前的数据镜像，支持事务回滚（`ROLLBACK`） - 为读操作提供一致性视图（通过`Read View`访问历史版本数据）[^2] - **存储形式**： - 以**逻辑日志**形式记录反向操作（例如：INSERT对应DELETE，UPDATE记录旧值） - 存储在特殊的undo表空间中（MySQL 8.0默认使用独立UNDO表空间） --- #### 二、关键差异分析 | **对比维度** | **redo log** | **undo log** | |--------------------|---------------------------------------|---------------------------------------| | **所属层级** | InnoDB存储引擎层实现[^4] | InnoDB存储引擎层实现[^4] | | **日志类型** | 物理日志（记录数据页修改） | 逻辑日志（记录反向操作语句） | | **主要目的** | 崩溃恢复时保证数据持久性 | 事务回滚与MVCC支持 | | **生命周期** | 事务提交后仍可能保留（用于恢复） | 事务提交后随版本链清理逐渐删除 | | **写入触发条件** | 数据修改发生时立即记录 | 事务开启后首次数据修改时生成 | | **可见性** | 仅InnoDB内部使用 | 通过`SELECT ... FOR UPDATE`可间接访问| | **与事务的关系** | 所有事务共享日志缓冲区 | 每个事务拥有独立的undo链 | --- #### 三、协作流程示例（以UPDATE为例） 1. **事务启动**：生成事务ID（trx_id）并分配undo log段 2. **修改数据前**： - 将原始数据拷贝到undo log（构建回滚段） - 生成`UNDO LOG RECORD`记录旧值[^4] 3. **执行数据修改**： - 在内存中更新数据页，生成`redo log record`写入log buffer - 若开启binlog，同时写入binlog cache（两阶段提交）[^4] 4. **事务提交**： - 将redo log buffer刷盘（`prepare`阶段） - binlog刷盘后，redo log标记为`commit`状态[^4] 5. **崩溃恢复**： - 检查binlog完整性，通过redo log重做未落盘的数据页修改 - 使用undo log回滚未提交的事务修改 --- #### 四、高级特性关联 1. **两阶段提交（2PC）** redo log与binlog通过两阶段提交保证跨存储引擎的事务一致性[^4]： ```mermaid graph LR A(事务提交) --> B(redo log prepare) B --> C(binlog写入) C --> D(redo log commit) ``` 2. **MVCC实现基础** 通过undo log构建版本链实现非锁定读： $$ \text{Read View} = [trx\_id_{min}, trx\_id_{max}, active\_trx\_list] $$ 根据事务ID选择可见的undo log版本 --- #### 五、配置与管理要点 1. **redo log优化** - 设置合理的日志文件大小（`innodb_log_file_size`，建议4GB以上） - 调整刷盘策略（`innodb_flush_log_at_trx_commit=1`确保ACID） ```ini [mysqld] innodb_log_files_in_group=3 # 日志文件数量 innodb_log_file_size=4G # 单个文件大小 ``` 2. **undo log管理** - 控制undo表空间数量（MySQL 8.0+） - 设置自动清理阈值（`innodb_undo_log_truncate=ON`） ```sql ALTER UNDO TABLESPACE innodb_undo_001 SET INACTIVE; # 手动触发清理 ``` --- ### 相关问题 1. 如何通过redo log实现崩溃恢复的具体流程？ 2. undo log在MVCC中如何支持一致性读？ 3. 两阶段提交如何避免binlog与redo log数据不一致？ 4. 什么情况下需要调整redo log文件的大小？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值