那些被你忽略的性能 - Oracle Redo的产生场景及优化

冷菠,资深DBA,著有《Oracle高性能自动化运维》,有近10年的数据库运维、团队管理以及培训经验。擅长数据库备份恢复、数据库性能诊断优化以及数据库自动化运维等。目前致力于大数据、智能一体化、开源云计算等领域的佳实践探索。

Oracle Redo是以条目(Redo record)的形式记录数据库的所有更改操作。这些更改包括数据库物理文件的更改,数据库运行状况更改,后台进程的写操作,DML事务操作,数据字典DDL操作,数据库内部递归调用等。其中,最主要的原因是DML事务的操作。

本文将分析Redo对于数据库DML操作的记录信息,并提出通过减少Redo条目达到优化Redo,提高数据库性能的方案。

DML事务相关的数据库更改有哪些?

  1. 数据块更改;
  2. 回滚段数据块镜像更新;
  3. 数据库内部信息更新(数据字典表更新)。

我们可以通过日志挖掘获取到数据库更改的相关信息,如下:

可以看到,Redo中记录了DML事物的数据块更改、回滚段更新等信息。

如何来减少Redo的产生,从而达到优化Redo的目的

  1. 减少索引键更新操作;
  2. 大表(键)更新操作;
  3. 使用Direct Load加载数据;
  4. 使用Nologging进行特定操作;
  5. 使用临时表(Temporary Table);
  6. 使用外部表(External Table);
  7. 批量化处理DML业务程序;
  8. 减少事务Commit次数,采用组提交的方式;
  9. 减少Select For Update显示锁定,可以明显减少Redo产生;
  10. 减少表记录的数量规模(利用分区路由架构分区裁剪特性),例如使用分区、分表、分库等策略;
  11. 减少不必要的DML操作可以减少Redo产生,例如改写、整合SQL程序,优化业务逻辑。

通过示例验证优化的可行性

采用组提交减少Redo的产生:

不采用组提交插入数据:

采用组提交(提交一次)插入数据:

从上述数据可以看出:

  • 不采用组提交产生Redo :9268980;
  • 采用组提交产生Redo: 5241596;
  • 组提交大大减少了Redo的产生:4027384(9268980-5241596)。

采用临时表可以减少Redo产生:

采用普通表插入数据:

采用全局临时表插入数据:

从上述数据可以看出:

  • 普通表产生Redo:5479300;
  • 全局临时表产生Redo:1607268;
  • 全局临时表大大减少了Redo产生:3872032(5479300-1607268)。

论证结论

可以看到,采用组提交和使用临时表都能有效的减少Redo的产生,从而提升了数据库性能。有兴趣的读者可以尝试采用其余措施进行扩展验证。

时间: 2024-09-11 03:53:42

那些被你忽略的性能 - Oracle Redo的产生场景及优化的相关文章

Oracle Redo 以及 Archived日志简述

Oracle通过Redo Archived实现数据的归档 什么是Redo日志 Redo日志记录了数据的变更,用于在数据库出现故障后,进行数据恢复. 功能主要由三个组件实现:Redo Log Buffer.LGWR后台进程.Redo Log File. Redo Log Buffer是Oracle共享内存中的一段空间,记录了数据库的变更历史,包括:insert,update,delete,create,alter,drop等. 过程: 用户内存中的记录 --复制--> SGA中的Redo Log

Oracle 11g r2全外连接优化执行计划(三)NATIVE_FULL_OUTER_JOIN提示

虽然上一篇介绍了NATIVE_FULL_OUTER_JOIN和NO_NATIVE_FULL_OUTER_JOIN两个HINT,但是实际上NATIVE_FULL_OUTER_JOIN并没有发挥任何的作用,因为Oracle对全外连接的优化使得新的执行计划的代价比原始执行计划要低,所以Oracle默认就选择这个执行计划,因此看不到NATIVE_FULL_OUTER_JOIN提示的效果. SQL> SET AUTOT ON SQL> SELECT T1.ID, T2.ID 2  FROM T1 FUL

Oracle存储过程的编写经验与优化措施(分享)_oracle

一.前言:在经过一段时间的存储过程开发之后,写下了一些开发时候的小结和经验与大家共享,希望对大家有益.二.适合读者对象:数据库开发程序员,数据库的数据量很多,涉及到对SP(存储过程)的优化的项目开发人员,对数据库有浓厚兴趣的人.三.介绍:在数据库的开发过程中,经常会遇到复杂的业务逻辑和对数据库的操作,这个时候就会用SP来封装数据库操作.如果项目的SP较多,书写又没有一定的规范,将会影响以后的系统维护困难和大SP逻辑的难以理解,另外如果数据库的数据量大或者项目对SP的性能要求很,就会遇到优化的问题

Oracle数据库中SQL语句的优化技巧_oracle

在SQL语句优化过程中,我们经常会用到hint,现总结一下在SQL优化过程中常见Oracle HINT的用法: 1. /*+ALL_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳吞吐量,使资源消耗最小化. 例如: SELECT /*+ALL+_ROWS*/ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='SCOTT'; 2. /*+FIRST_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳响应时间,使资源消耗最小化.

磁盘:最容易被忽略的性能洼地

引言:从整个软件的性能来说,资源类性能就像是撑起冰山一角的下面的冰层.构成这部分的,是传统部分的磁盘.CPU.内存和网络以及因为移动网络而显得特别重要的电池(耗电).本文我们将向您着重介绍磁盘部分. 本文选自<Android移动性能实战>. 1 原理 在没有SSD硬盘之前,大家都会觉得我们的HDD硬盘很好用,什么5400转.7200转,广告都是棒棒的.直到有一天,SSD出现了,发现启动Windows的时候,居然可以秒开,这才幡然醒悟.因此,对于外行来说,磁盘I/O性能总是最容易被忽略的,精力会

Oracle Redo log日志组故障分析

数据库平台:SunOS 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-Enterprise 数据库版本:8.1.5.0.0 数据库症状:数据库响应缓慢,应用请求无法返回,业务操作陷于停顿,此时需要DBA介入并进行问题诊断及故障处理. 1. 登录数据库进行检查 首先我们登录数据库,检查故障现象. 经过检查发现,数据块的所有重做日志组除current外都处于active状态: oracle:/oracle/oracle8>sqlplus "/ as

Oracle 11g r2全外连接优化执行计划(二) 新增的两个相关的HINT

Oracle在推出了新的执行计划的同时,还提供了两个控制这个执行计划的提示NATIVE_FULL_OUTER_JOIN和NO_NATIVE_FULL_OUTER_JOIN. 这两个HINT的使用十分简单,不需要其他的任何参数.下面继续上一篇文章的例子: SQL> SELECT /*+ NO_NATIVE_FULL_OUTER_JOIN */ T1.ID, T2.ID 2  FROM T1 FULL OUTER JOIN T2 3  ON T1.ID = T2.ID; ID        ID -

Oracle 11g r2全外连接优化执行计划(一)

在11.2中,Oracle对于全外连接的执行计划进行了优化. 在以前的版本中,全外连接的执行计划如下: SQL> SELECT * FROM V$VERSION; BANNER ---------------------------------------------------------------- Oracle Database10gEnterpriseEdition Release10.2.0.3.0 - 64bi PL/SQL Release 10.2.0.3.0 - Product

Oracle SQL_TRACE和10046事件的优化SQL实例

一数据库版本 LEO1@LEO1>select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production PL/SQL Release11.2.0.1.0 - Production CORE