undo系列学习之undo段及区的状态和使用概述

本文详细介绍了Oracle数据库中UNDO表空间的作用及其管理方式,包括如何查询激活的UNDO表空间、数据文件数量、段及区的分布状态等,并解释了不同状态下区的意义。

undo表空间只做一件事:保存旧值。在AUM下,段是自动生成,区是自动分配与回收,且是不连续的。每个段至少有2个区。oracle自动使用undo段,在某种意义上,我们只要关注undo表空间的大小就可以了。

查询当前哪个undo表空间被激活:

sys@ORCL> show parameter undo_tablespace

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_tablespace                      string      UNDOTBS1


查询undo表空间里面有多少个数据文件:

sys@ORCL> col file_name for a72
sys@ORCL> select file_name,bytes/1024/1024 m from dba_data_files where tablespace_name like '%UNDOTBS%';

FILE_NAME                                                                         M
------------------------------------------------------------------------ ----------
/u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_8050fkc6_.dbf              100
/u01/app/oracle/oradata/ORCL/datafile/thinkundo.dbf                              30


查询undo表空间里面在线有多少个段:

sys@ORCL> select * from v$rollname;

       USN NAME
---------- ------------------------------
         0 SYSTEM
         1 _SYSSMU1$
         2 _SYSSMU2$
         3 _SYSSMU3$
         4 _SYSSMU4$
         5 _SYSSMU5$
         6 _SYSSMU6$
         7 _SYSSMU7$
         8 _SYSSMU8$
         9 _SYSSMU9$
        10 _SYSSMU10$

11 rows selected.


查询段有多少个区和块:

sys@ORCL> select segment_name,extents,blocks from dba_segments where segment_name='_SYSSMU3$';

SEGMENT_NAME       EXTENTS     BLOCKS
--------------- ---------- ----------
_SYSSMU3$               17        256


查询区有多少个块:

sys@ORCL> select file_id,tablespace_name,segment_name,extent_id,block_id,blocks from dba_extents where
  2  segment_name='_SYSSMU3$';

   FILE_ID TABLESPACE_NAME                SEGMENT_NAME     EXTENT_ID   BLOCK_ID     BLOCKS
---------- ------------------------------ --------------- ---------- ---------- ----------
         2 UNDOTBS1                       _SYSSMU3$                0         41          8
         2 UNDOTBS1                       _SYSSMU3$                1         49          8
         2 UNDOTBS1                       _SYSSMU3$                2         17          8
         2 UNDOTBS1                       _SYSSMU3$                3         33          8
         2 UNDOTBS1                       _SYSSMU3$                4        161          8
         2 UNDOTBS1                       _SYSSMU3$                5        169          8
         2 UNDOTBS1                       _SYSSMU3$                6        177          8
         2 UNDOTBS1                       _SYSSMU3$                7        185          8
         2 UNDOTBS1                       _SYSSMU3$                8        201          8
         2 UNDOTBS1                       _SYSSMU3$                9        209          8
         2 UNDOTBS1                       _SYSSMU3$               10        217          8
         2 UNDOTBS1                       _SYSSMU3$               11        225          8
         2 UNDOTBS1                       _SYSSMU3$               12        233          8
         2 UNDOTBS1                       _SYSSMU3$               13        241          8
         2 UNDOTBS1                       _SYSSMU3$               14        249          8
         2 UNDOTBS1                       _SYSSMU3$               15        257          8
         7 UNDOTBS1                       _SYSSMU3$               16        521        128

17 rows selected.


从这里我们也可以看出,undo段中的区的分配是不连续的。

undo段中区的状态:
1)free:没有分配给任何一个段
2)active:区中有事务没有提交
3)inactive:区中的事务提交了
4)expired:事务提交而且达到了undo_retention
注:我们可以通过设定undo_retention来保住inactive的区,若没有free,则自动扩展;若扩展不了,则优先使用expired;若还不够,则就会使用inactive,但如果此时retention是guarantee保证的,则无法使用inactive,会报ORA-30036.

sys@ORCL> select extent_id,bytes,status from dba_undo_extents where segment_name='_SYSSMU3$';

 EXTENT_ID      BYTES STATUS
---------- ---------- ---------
         0      65536 EXPIRED
         1      65536 EXPIRED
         2      65536 EXPIRED
         3      65536 EXPIRED
         4      65536 EXPIRED
         5      65536 EXPIRED
         6      65536 EXPIRED
         7      65536 EXPIRED
         8      65536 EXPIRED
         9      65536 EXPIRED
        10      65536 EXPIRED
        11      65536 EXPIRED
        12      65536 EXPIRED
        13      65536 EXPIRED
        14      65536 EXPIRED
        15      65536 EXPIRED
        16    1048576 EXPIRED

17 rows selected.

undo段上默认只有一个事务,当有多个事务时,会优先选择空闲的undo段,只有在没有了空闲undo段时,oracle才会选择在一个undo段上建立多个事务。

<think>我们正在讨论MySQL的undo logredo log。用户要求详细介绍这两种日志。根据引用内容,我们可以总结如下: 引用[1][2]指出: - Redo Log(重做日志)Undo Log(撤销日志)用于确保数据完整性事务一致性。 - 它们在事务回滚系统恢复中起关键作用。 引用[2]进一步说明: - Undo Log用于保障事务的原子性(回滚)一致性。 - Redo Log用于保障事务的持久性。 引用[3][4]补充: - Undo Log记录事务修改前的数据,用于回滚。 - Redo Log记录事务修改后的数据,用于崩溃恢复。 引用[5]强调: - 当事务修改数据时,Undo Log会先保存原始数据,以便回滚时恢复。 - Redo Log则记录修改后的新数据,确保已提交事务的持久性。 我们需要详细说明这两种日志,包括它们的作用、工作原理、存储方式以及协同工作的情况。 回答结构: 1. 概述Undo LogRedo Log的作用别 2. 分别详细介绍Undo Log - 原理 - 实现机制 - 作用 3. 分别详细介绍Redo Log - 原理 - 实现机制 - 作用 4. 两者协同工作流程(例如在事务提交崩溃恢复时) 5. 总结 注意:在回答中适当添加引用标识。 另外,根据指令,需要生成相关问题。 </think>### Undo Log 与 Redo Log 深度解析 MySQL 通过 **Undo Log(撤销日志)** **Redo Log(重做日志)** 协同保障事务的 ACID 特性,以下是详细分析: --- #### 一、Undo Log:事务回滚与多版本控制的核心 **本质作用**:记录数据修改前的原始状态,实现**原子性(Atomicity)** **多版本并发控制(MVCC)**[^2][^5]。 **核心机制**: 1. **数据回滚** - 事务修改数据前,将原始值写入 Undo Log - 回滚时执行逆向操作: $$Rollback = Apply(UndoLog\_Record)$$ - 示例:UPDATE 语句失败时,通过 Undo Log 复原数据[^5] 2. **MVCC 支持** - 存储数据的历史版本(通过 `DB_ROLL_PTR` 指针链式存储) - 读操作访问对应版本快照,避免读写冲突 ```mermaid graph LR A[事务TX1读数据] --> B[检查Undo Log版本链] B --> C{选择TX1启动前的版本} C -->|是| D[返回历史快照] C -->|否| E[跳过新版本] ``` 3. **存储特性** - 位于共享表空间的 `ibdata1` 文件中 - 采用**管理**(UNDO Segments) - 空间回收由 Purge 线程异步处理[^3] --- #### 二、Redo Log:崩溃恢复与持久化的基石 **本质作用**:确保**持久性(Durability)**,防止事务提交后数据丢失[^1][^4]。 **核心机制**: 1. **Write-Ahead Logging (WAL)** - 修改数据前先写 Redo Log:$Commit \rightarrow Write(RedoLog) \rightarrow Flush(DataPage)$ - 日志写入顺序:内存 Log Buffer → 磁盘 Log File[^3] 2. **崩溃恢复流程** ```python def crash_recovery(): scan_redo_log() # 扫描所有Redo记录 for log in committed_tx: # 重做已提交事务 apply_log_to_page(log) for log in active_tx: # 撤销未提交事务(需结合Undo Log) rollback_via_undo(log) ``` 3. **日志结构优化** - **循环写入**:固定大小文件(通常 4GB),写满后覆盖旧日志 - **LSN 机制**:Log Sequence Number 全局唯一标识日志位置 - **组提交**:合并多个事务 I/O,提升吞吐量[^4] --- #### 三、Undo Log 与 Redo Log 的协同 | **场景** | **协作流程** | 关键目标 | |-------------------|-----------------------------------------------------------------------------|-----------------------| | **事务提交** | 1. Redo Log 持久化<br>2. Binlog 写入(若开启)<br>3. 内存数据页异步刷盘 | 持久性保障[^3] | | **事务回滚** | 1. 从 Undo Log 读取旧值<br>2. 通过 Redo Log 记录回滚操作 | 原子性实现[^2] | | **崩溃恢复** | 1. Redo Log 重做已提交操作<br>2. Undo Log 回滚未提交事务 | 一致性恢复[^1] | | **MVCC 读** | 1. 通过 Undo Log 定位历史版本<br>2. Redo Log 确保版本数据有效性 | 隔离性支持[^5] | **协同公式**: $$Atomicity_{Undo} + Durability_{Redo} \Rightarrow Consistency$$ --- #### 四、关键差异总结 | **特性** | Undo Log | Redo Log | |-----------------|-----------------------------------|-----------------------------------| | **核心目的** | 回滚事务 + MVCC 版本链 | 崩溃恢复 + 数据持久化 | | **写入时机** | 事务修改数据**前** | 事务提交**前** | | **存储内容** | 数据修改**前**的原始值 | 数据修改**后**的新状态 | | **日志类型** | 逻辑日志(记录逆向 SQL) | 物理日志(记录页修改) | | **空间回收** | 事务提交后异步 Purge | 检查点推进后覆盖旧日志 | | **性能影响** | 影响回滚速度 + 读性能 | 决定提交延迟 + 恢复速度 | > **设计哲学**:Undo Log 是"后悔药",Redo Log 是"安全气囊",二者共同构建事务安全网[^1][^4]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值