删除一张大表时为什么undo占用空间接近原表两倍?
2023-03-14 22:23:43 时间
概述
Oracle中,undo是保存记录的前镜像的,我理解如果delete from t;那产生的undo应该和t表的大小差不多,但测试结果却差的很远,undo产生的量基本上是t表大小的两倍,不知道为什么,难道我理解错了?下面看下这个奇怪的现象。
1. delete了8个小时
2. 原表大小
可以发现原表也就16.5G,需要删的数据是9G。
3. 查看undo块
这里忘记截图了,但是是有300多万个块,查看对应占用的undo空间是占了30多G,远远超过原表的大小。
为什么undo会占用这么多空间?
从原理上讲,UNDO表空间,有四个作用:
- 回滚事务;
- 一致性读;
- 事务恢复;
- 闪回查询
请教杨长老得到的一些信息:
对于回滚事务,他保存的是修改值的前镜像,注意,不是修改的数据块,或者整行记录的镜像。
除了考虑表大小之外,还有表上索引的总大小,是否存在触发器,物化试图日志等等。另外,看看数据库级的supplemental log是否打开。
undo是记录事物修改前镜像的,而delete的前镜像就是表中存储的数据。当然有一些可能会导致前镜像比表中的原始数据大,比如压缩,11g后存在的非空默认值。
另外,undo的记录一定有一些额外的成本,比如rowid,scn等信息,如果表中行记录本身很小,那么这些成本就会显得非常突出。
如果要非常精确地知道,多出来的每一个信息是多少,确实有些困难,但通过这个实验,至少能了解到,一次delete操作删除的容量,UNDO为了保存前镜像,需要占据的容量,要比他多得多,这就是为什么不推荐一次delete操作删除过多数据的原因之一。
总之,对于delete大量数据的情况一定要分批进行,宁愿时间花多点,风险也会少很多,避免意外导致回滚而造成的数据库卡顿。
相关文章
- 宣布推出适用于 API 的 AWS Data Exchange:查找、订阅和使用具有一致身份验证的第三方 API
- AWS Control Tower 新增功能 – 区域拒绝和防护机制可帮助您满足数据驻留要求
- 宣布推出 Amazon SageMaker Canvas — 面向业务分析师的可视化、无代码机器学习功能
- Amazon Kinesis Data Streams 按需模式 – 无需管理容量即可大规模流式传输数据
- AWS Lake Formation — 具有自动压缩功能的单元格级安全性和受控表正式发布
- 新功能 – Amazon DevOps Guru for RDS 使用 ML 检测、诊断和解决与 Amazon Aurora 相关的问题
- 新的 DynamoDB 表类别 – 节省多达 60% 的 DynamoDB 成本
- 新功能 – 面向 SQL Server 的 Amazon RDS 自定义现已正式推出
- 预览 — AWS Backup 添加了对 Amazon S3 的支持
- 新功能 – 简化对 Amazon S3 中所存储数据的访问管理
- Amazon S3 Glacier 是归档数据的最佳场所 — 引入 S3 Glacier 即时检索存储类
- python-fbprophet总结
- 新功能 — 使用 Amazon SageMaker Studio 创建和管理 EMR 集群和 Spark 任务
- 宣布推出 Amazon SageMaker Ground Truth Plus
- App Runner 新增功能 – VPC 支持
- 基于 Amazon EC2 快速部署高可用ClickHouse
- 在 Amazon RDS for MySQL 和 Amazon Aurora MySQL 上使用 TempTable 存储引擎
- Amazon GameTech 架构最佳实践系列 —— MOBA/FPS架构篇
- 将 Amazon DynamoDB 数据流式传输到集中式数据湖
- Amazon DynamoDB 的十年之约