测试4——shrink和move产生的redo log量的比较

shrink过程和move过程日志产生量比较:

关于日志的问题,我们对比了同样数据量和分布状况的两张table,在move和shrink下生成的redo size(table上没有index的情况下):

SQL> select tablespace_name,SEGMENT_SPACE_MANAGEMENT from dba_tablespaces where tablespace_name
='ASSMTEST';
TABLESPACE_NAME SEGMENT_SPACE_MANAGEMENT
------------------------------ ------------------------
ASSMTEST AUTO

SQL> create table my_objects  as select * from dba_objects ;

SQL> create table my_objects1  as select * from dba_objects ;

SQL> select bytes/1024/1024 from user_segments where segment_name = 'MY_OBJECTS';

BYTES/1024/1024
---------------

9

SQL> delete from my_objects where object_name like '%C%';
7278 rows deleted
SQL> delete from my_objects1 where object_name like '%C%';
7278 rows deleted
SQL> delete from my_objects where object_name like '%U%';
2732 rows deleted
SQL> delete from my_objects1 where object_name like '%U%';
2732 rows deleted
SQL> commit;
Commit complete
SQL> alter table my_objects enable row movement;

Table altered

SQL>  select value from v$mystat, v$statname where v$mystat.statistic# = v$statname.statistic# and v$statname.name = 'redo size';
     VALUE
----------
  84466796

SQL> alter table my_objects shrink space;
Table altered.

SQL>  select value from v$mystat, v$statname where v$mystat.statistic# = v$statname.statistic# and v$statname.name = 'redo size';
     VALUE
----------
  97945584

SQL> alter table my_objects1 move;

Table altered

SQL>  select value from v$mystat, v$statname where v$mystat.statistic# = v$statname.statistic# and v$statname.name = 'redo size';
     VALUE
----------
  98004004

对于table my_objects,进行shrink,产生了 97945584 - 84466796 =

13 478 788,约13.5M的redo

;对table my_objects1进行move,产生了98004004-97945584=

58 420,约 58K 的 redo size.

那么,与move比较起来,shrink的日志写要大得多.

其最根本的原因,我们可以从move和shrink的原理中找到,shrink是行的移动,相当于对数据块内的数据行删除然后插入的操作,会产生大量的undo redo信息;

而move是对数据块的移动操作,不会产生dml操作类似的undo信息。

时间: 2024-09-23 16:35:41

测试4——shrink和move产生的redo log量的比较的相关文章

Oracle Online Redo Log能否放在Flash闪存卡上?

Flash 闪存卡的性能远超SAS 盘,所以在数据库中使用广泛. 但是online redo log 是否应该存放在闪存卡上一直是有争议的话题.今天由DBA+社群合肥发起人戴明明来谈一谈他通过理论和实际的实验去测试这个问题.   专家简介     戴明明 DBA+社群合肥发起人   Oracle ACE Associate,中国 ORACLE 用户组(ACOUG) 核心成员,中国浙江应用中间件与数据库用户组成员. 超过7年的DBA经验,在Oracle 高可用性方面有一定的经验积累,擅长Oracl

DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题

问题 最近一直头疼于DataGuard环境中万一网络失败将导致的Primary库短时间内无法正常工作的问题. 这个问题的现象基本上是这样:当Primary和Standby之间的网络出现问题,比如说在测试环境中我们拔掉Standby的网线,此时当Primary发生日志切换(Log Switch)的时候,Primary将试图通知Standby同样作归档,但是由于网络不通,就会默认有30秒的TimeOut,而在这30秒的时间内,Primary上的任何DML操作都将被悬停.至今为止我还没有找到很好的办法

Oracle高并发系列2:事务日志写入引发的Redo log风波

作者介绍 王鹏冲,平安科技数据库技术专家,浸淫数据库行业十多年,对Oracle数据库有浓厚兴趣,也对MySQL.MongoDB.Redis等数据库有一定架构和运维经验,目前正沉迷在PostgreSQL数据库与Oracle数据库的PK之中,重点在关系型数据库的分布式架构研究.   引言   关系型数据库强调事务的ACID特性,对于事务的持久性,主流的关系型数据库都是通过写事务日志来实现的.写数据是随机IO,写日志是顺序IO,常规的机械磁盘,随机IO比顺序IO要昂贵很多.所以虽然写日志同样要刷到磁盘

MySQL · 引擎特性 · InnoDB redo log漫游

前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性. 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘. LSN(log sequence number) 用于记录日志序号,它是一个不断递增的 unsigned long long 类型整数.在 InnoDB 的日志

数据库内核月报 - 2015 / 05-MySQL · 引擎特性 · InnoDB redo log漫游

前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性. 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘. LSN(log sequence number) 用于记录日志序号,它是一个不断递增的 unsigned long long 类型整数.在 InnoDB 的日志

在线修改Redo log的大小及增加新的日志组

如果在线日志文件设置过小,会导致日志切换非常频繁.可以通过以下步骤进行在线Redo日志修改. 相关的知识普及: 1.Redo log File存放了Redo log信息,最少有两组日志文件,供Oracle循环使用. 2.Redo log File每组最少一个,建议两个,防止损坏而导致的数据丢失. 3.每组中的文件大小必须一致,因为他们是同时修改的,不同组的文件大小可以不一致. 4.每组中的文件个数必须一致. 由于ORACLE并没有提供类似RESIZE的参数来重新调整REDO LOG FILE的大

archive log文件大小与redo log文件大小关系探究

     首先我们来看下什么是archive log file,oracle 11g 的concept中是这样定义的:When you enable archiving of the online redo logs, Oracle Database copies the online redo log files to another location before they are overwritten. These copied files are referred to as arch

MySQL: 对超长blob列的redo log限制

我们知道,Innodb使用固定长度的N个iblog文件来存储redo log,文件空间可以被复用.这些被复用的空间redo需要保证已经做了checkpoint. 假定我们的iblog大小为1G,如果我们更新一个非常大的字段,就有可能覆盖掉未checkpoint的redo log,因为Innodb并没有根据其可能产生的log长度来判断redo log空间是否够用.而只是保证会预留一定比例的redo log空间.详细见bug链接:http://bugs.mysql.com/bug.php?id=69

mysql源码-关于mysql redo log的问题。

问题描述 关于mysql redo log的问题. http://bugs.mysql.com/bug.php?id=73202 上面是一个官方的patch, According to the crash recovery logic of mysql server, we only need to write/sync prepared transaction before writing to binlog. And currently transactions are not groupe