设为首页 收藏本站
查看: 423|回复: 0

[经验分享] 相同更改数据量的前提下,单次COMMIT和多次COMMIT对日志空

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2014-7-15 09:15:41 | 显示全部楼层 |阅读模式
相同更改数据量的前提下,单次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浪费更多的日志块空间。
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浪费更多的日志块空间。


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浪费更多的日志块空间。



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-22039-1-1.html 上篇帖子: 记一次因网卡心跳故障引发RAC节点重启故障分析 下篇帖子: Oracle数据库对象查询是否被锁定及解锁 空间 影响
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表