一个COMMIT提交次数的问题

本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 一个COMMIT提交次数的问题

一个COMMIT提交次数的问题

提问:相同更改数据量的前提下,单次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浪费更多的日志块空间。

如果您觉得本文有帮助,欢迎关注转发:bisal的个人杂货铺,

一个COMMIT提交次数的问题 一个COMMIT提交次数的问题
本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 一个COMMIT提交次数的问题


 上一篇
路由冲突对数据库的影响 路由冲突对数据库的影响
虚拟机环境中,执行SQL,提示未登录错误, 正常关库报错, 正常启库还是错, 看一下监听状态, 配置文件信息, /etc/sysconfig/network
下一篇 
Tuxedo两个小问题解决 Tuxedo两个小问题解决
最近碰见了两个Tuxedo的问题,好久没有接触,有些生疏,记录于此。 案例1 一个Tuxedo Client,通过WSL方式调用Tuxedo Server,从应用现象看,调用不同,没有任何返回。 ULOG记录, 111920.