相同更改数据量的前提下,单次COMMIT和多次COMMIT对日志空间浪费的影响对比

LGWR进程按照顺序写在线日志,中间不会跳跃,而且LGWR进程不会在同一个日志快写2次,即使一次写入的日志快只占几个字节,下次不会再用了,这就造成日志空间的浪费。Oracle做一次Commit,就会触发LGWR进程进行日志缓冲到日志文件的写入操作,因此可以说更改相同数据量的前提下,如果提交过于频繁,产生的日志可能就会越多,即使第一次Commit占用的日志块仍可以存储下一次需要写入的日志缓冲,那么下一次Commit会再次占用一个新的日志块。

实验:

1、系统的日志块大小是512字节。

SQL> select max(lebsz) from sys.x$kccle;

MAX(LEBSZ)

----------

512

2、创建两张相同数据量的表。

SQL> select count(*) from t1;

COUNT(*)

----------

11188

SQL> select count(*) from t2;

COUNT(*)

----------

11188

3、查看删除t1表前系统的浪费日志空间量。

SQL> select name, value from v$sysstat where name like ‘%wastage%‘;

NAME                                              VALUE

---------------------------------------------------------------- ----------

redo wastage                                        208060

4、逐条删除t1表的记录。

SQL> begin

2  for i in 1 .. 11188 loop

3  delete from t1 where rownum < 2;

4  commit;

5  end loop;

6  end;

7  /

5、再次查看日志空间浪费量。

SQL> select name, value from v$sysstat where name like ‘%wastage%‘;

NAME                                              VALUE

---------------------------------------------------------------- ----------

redo wastage                                       1118740

SQL> select 1118740-208060 from dual;

1118740-208060

--------------

910680

浪费日志空间量是910680字节。

6、查看当前进程的SID。

SQL> select distinct sid from v$mystat;

SID

----------

215

进而查出当前进程消耗的redo量总大小。

SQL> select b.name, a.value from v$sesstat a, v$statname b

2  where a.statistic#=b.statistic#

3  and b.name like ‘%redo size%‘

4  and a.sid=215;

NAME                 VALUE

-------------------- ----------

redo size          9103304

可知日志空间浪费比率有10%

SQL> select 910680/9103304 from dual;

910680/9103304

--------------

.100038404

7、接下来选择一次性删除t2表记录,之前记录下日志空间浪费大小。

SQL> select name, value from v$sysstat where name like ‘%wastage%‘;

NAME                 VALUE

-------------------- ----------

redo wastage          1130636

SQL> delete from t2;

11188 rows deleted.

SQL> commit;

Commit complete.

8、查看当前日志空间浪费。

SQL> select name, value from v$sysstat where name like ‘%wastage%‘;

NAME                 VALUE

-------------------- ----------

redo wastage          1132060

9、计算日志浪费空间比率。

SQL> select 1132060-1130636 from dual;

1132060-1130636

---------------

1424

SQL> select b.name, a.value from v$sesstat a, v$statname b

2  where a.statistic#=b.statistic#

3  and b.name like ‘%redo size%‘

4  and a.sid=215;

NAME                 VALUE

-------------------- ----------

redo size            13154544

SQL> select 1424/13154544 from dual;

1424/13154544

-------------

.000108252

从结果看,日志空间浪费比率仅为0.01%。

结论:

1、LGWR进程按照顺序将日志缓冲写入日志块,不会在同一个日志块中写入两次,就可能造成上一次写入的最后一个日志块会有空间的浪费,但下一次不能再使用,只能再次写入一个新的日志块。

2、相同更改数据量的前提下,多次提交Commit要比一次Commit浪费更多的日志块空间。

相同更改数据量的前提下,单次COMMIT和多次COMMIT对日志空间浪费的影响对比

时间: 2024-10-13 10:21:34

相同更改数据量的前提下,单次COMMIT和多次COMMIT对日志空间浪费的影响对比的相关文章

数据库有百万数据量的情况下,分页查询的方法及其优化方式

当需要从数据库查询的表有上万条记录的时候,一次性查询所有结果会变得很慢,特别是随着数据量的增加特别明显,这时需要使用分页查询.对于数据库分页查询,也有很多种方法和优化的点. 下面简单说一下我知道的一些方法. 准备工作 为了对下面列举的一些优化进行测试,下面针对已有的一张表进行说明. 表名:order_history 描述:某个业务的订单历史表 主要字段:unsigned int id,tinyint(4) int type 字段情况:该表一共37个字段,不包含text等大型数据,最大为varch

对于数据量庞大的下拉菜单建立对应的联想查询

*效果展示:[如图左边为项目信息的下拉菜单,在其右边有一个输入框.实现效果在右边输入框的位置,输入"A",在昨天的下拉框信息中值显示"A"对应的信息] *功能实现: [jsp页面功能实现:] 获取你要的所有项目信息 <% List project_list = (List)request.getAttribute("project_list"); %> js组装成信息数组 <SCRIPT LANGUAGE="JavaS

千万级别数据量mysql优化策略(一)

表结构优化 1.  使用独立表空间 独立表空间指的是innodb表的一种数据结构 独占表空间:  每一个表都将会生成以独立的文件方式来进行存储,每一个表都有一个.frm表描述文件,还有一个.ibd文件. 其中这个文件包括了单独一个表的数据内容以及索引内容,默认情况下它的存储位置也是在表的位置之中. 2.  分区表 分区表是一种粗粒度,简易的索引策略,适用于大数据的过滤场景.最适合的场景是,没有合适的索引时,对其中几个分区表进行全表扫描.或者只有一个分区表和索引是热点,而且这个分区和索引能够全部存

数据量下高并发同步的讲解(不看,保证你后悔

4.常见的提高高并发下访问的效率的手段 首先要了解高并发的的瓶颈在哪里? 1.可能是服务器网络带宽不够 2.可能web线程连接数不够 3.可能数据库连接查询上不去. 根据不同的情况,解决思路也不同. 像第一种情况可以增加网络带宽,DNS域名解析分发多台服务器. 负载均衡,前置代理服务器nginx.apache等等 数据库查询优化,读写分离,分表等等 最后复制一些在高并发下面需要常常需要处理的内容: 尽量使用缓存,包括用户缓存,信息缓存等,多花点内存来做缓存,可以大量减少与数据库的交互,提高性能.

大数据量下高并发同步的讲解(转)

文章转自:http://blog.csdn.net/xcw931924821/article/details/52475742 *************************************************************************************************************************************************************************************** 对于

大数据量下高并发同步的讲解(不看,保证你后悔)

对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系          所谓同步,可以理解为在执行完一个函数或方法之后,一直等待系统返回值或消息,这时程序是出于阻塞的,只有接收到 返回的值或消息后才往下执行其它的命令. 异步

大数据量下高并发同步的讲解(不看,保证你后悔!)

偶然的机会在网上看到了这篇blog,觉得作者写得挺不错的(虽然自己并没有怎么看懂...),所以就转来跟大家分享分享吧~~~ 对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系          所谓同步,可以理解为在执行完

MySQL单表数据量过千万,采坑优化记录,完美解决方案

问题概述 使用阿里云rds for MySQL数据库(就是MySQL5.6版本),有个用户上网记录表6个月的数据量近2000万,保留最近一年的数据量达到4000万,查询速度极慢,日常卡死.严重影响业务. 问题前提:老系统,当时设计系统的人大概是大学没毕业,表设计和sql语句写的不仅仅是垃圾,简直无法直视.原开发人员都已离职,到我来维护,这就是传说中的维护不了就跑路,然后我就是掉坑的那个!!! 我尝试解决该问题,so,有个这个日志. 方案概述 方案一:优化现有mysql数据库.优点:不影响现有业务

大数据量下高并发同步的讲解

对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系         所谓同步,可以理解为在执行完一个函数或方法之后,一直等待系统返回值或消息,这时程序是出于阻塞的,只有接收到 返回的值或消息后才往下执行其它的命令. 异步,