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

时间: 2024-10-26 13:59:49

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

数据量过大时数据库操作的处理

数据|数据库 随着"金盾工程"建设的逐步深入和公安信息化的高速发展,公安计算机应用系统被广泛应用在各警种.各部门.与此同时,应用系统体系的核心.系统数据的存放地――数据库也随着实际应用而急剧膨胀,一些大规模的系统,如人口系统的数据甚至超过了1000万条,可谓海量.那么,如何实现快速地从这些超大容量的数据库中提取数据(查询).分析.统计以及提取数据后进行数据分页已成为各地系统管理员和数据库管理员亟待解决的难题. 在以下的文章中,我将以"办公自动化"系统为例,探讨如何在

在ASP.NET 2.0中操作数据之二十五:大数据量时提高分页的效率_自学过程

导言 如我们在之前的教程里讨论的那样,分页可以通过两种方法来实现: 1.默认分页– 你仅仅只用选中data Web control的 智能标签的Enable Paging ; 然而,当你浏览页面的时候,虽然你看到的只是一小部分数据,ObjectDataSource 还是会每次都读取所有数据 2.自定义分页– 通过只从数据库读取用户需要浏览的那部分数据,提高了性能. 显然这种方法需要你做更多的工作. 默认的分页功能非常吸引人,因为你只需要选中一个checkbox就可以完成了.但是它每次都读取所有的

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

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

大数据量下的数据库查询与插入如何优化? (整理)

数据库经常要做一些查询与插入,但是如果查询和插入的数据量过大的时候就会引发数据库性能问题,降低数据库工作效率.因此性能调优是大家在工作中都能够预见的问题,大到世界五百强的核心系统,小到超市的库存系统,几乎都会有要调优的时候.面对形形色色的系统,林林总总的需求,调优的手段也是丰富多彩. 1.尽量使语句符合查询优化器的规则避免全表扫描而使用索引查询 2.避免频繁创建和删除临时表,以减少系统表资源的消耗. 3.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理. 4.建立高效的索引

关于大数据量下Core Data的数据迁移

Core Data版本迁移基础 通常,在使用Core Data的iOS App上,不同版本上的数据模型变更引发的数据迁移都是由Core Data来负责完成的.这种数据迁移模式称为Lightweight Migration(可能对于开发人员来说是lightweight),开发人员只要在添加Persistent Store时设置好对应选项,其它的就交付给Core Data来做了: 从命名上可以看出这两个选项分别代表:自动迁移Persistent Store,以及自动创建Mapping Model.

表单-多表头和可变表头(一条信息的数据量大小可变。)该怎么设计数据库的表结构。

问题描述 多表头和可变表头(一条信息的数据量大小可变.)该怎么设计数据库的表结构. 我现在有一个表单需要存入数据库.但是客户要求该表单的 表头可变.也就是他要自定义表单.这种情况我该怎么为这张表单设计表结构了?同时该表单中的所有字段都要参加计算的,有些项的值是其他项通过计算得出的.虽然是简单的加减乘除,但是客户要求可以自动的计算.小弟用的Spring MVC+JPA 数据库mysql 或者 oracle 解决方案 一般一个表单中的字段分为固定的字段和 动态的字段. 将固定的字段,设计成一张表,称

大数据量下的分页

分页|数据 对于非常大的数据模型而言,分页检索时,每次都加载整个数据源非常浪费.通常的选择是检索页面大小的块区的数据,而非检索所有的数据,然后单步执行当前行. 本文演示ASP.net的DataGrid和Sql Server 实现大数据量下的分页,为了便于实现演示,数据表采用了Northwind数据库的Orders表(830条记录). 如果数据表中有唯一的自增索引,并且这个字段没有出现断号现象.检索页面大小的块区数据就非常简单了.通过简单的Sql语句就可以实现这个功能:select * from

大数据量下MySQL插入方法的性能比较

文章讲的是大数据量下MySQL插入方法的性能比较,不管是日常业务数据处理中,还是数据库的导入导出,都可能遇到需要处理大量数据的插入.插入的方式和数据库引擎都会对插入速度造成影响,本文旨在从理论和实践上对各种方法进行分析和比较,方便以后应用中插入方法的选择. 插入分析 MySQL中插入一个记录需要的时间由下列因素组成,其中的数字表示大约比例: ·连接:(3) ·发送查询给服务器:(2) ·分析查询:(2) ·插入记录:(1x记录大小) ·插入索引:(1x索引) ·关闭:(1) 如果我们每插入一条都

大数据量下的查找最新的几条数据的通用方法

由于项目需要,需要获取一组数据的的最新一条数据,表结构如下: CREATE TABLE [dbo].[WUSU_SUOLITest_Table](  [ID] [bigint] IDENTITY(1,1) NOT NULL,  [ReceiveTime] [datetime] NULL,  [GroupID] [bigint] NOT NULL,  [DataValue] [float] NULL,  [SensorCode] [char](10) NOT NULL, ) 在这个表上只有两种操作