Turbo Charge Oracle数据库11g性能

  • 2014年11月22日
  • 1回复
  • 824的浏览量

Userlevel 3
徽章 + 19
今天,我和我的团队正在帮助一个客户解决他们的Oracle 11g R2(11.2.0.4)数据库的性能问题,我们注意到完成一个检查点需要90秒到120秒。任何了解Oracle的人都知道,对于一个数据库来说,在切换联机重做日志文件和继续处理事务的过程中,等待时间是非常漫长的。这给客户带来了很多性能上的不满,这是可以理解的。但没过多久,我们就发现了问题所在,并解决了它。仅仅改变数据库中的一个参数并重新启动实例,就可以提高超过10X的性能。

在介绍用于解决性能问题的参数之前,首先让我们讨论一下此问题的一些症状,并介绍一些背景知识。还要注意的是,这与底层基础设施无关,它纯粹是一个数据库级别的设置。这个问题不会在Oracle 12c中发生。

问题的第一个迹象是,数据加载花费了很长时间,存储延迟似乎非常高。然后,在AWR报告中有一个条目说,76%的数据库等待时间是由日志文件切换(检查点不完整)引起的。检查点本身花了90秒才完成。在这段时间里,数据库实际上暂停了,并且没有处理任何事务,因为在检查点完成之前,它已经超出了联机重做日志文件空间。在数据加载和性能测试期间,我们注意到只有一两个未完成的IO进入数据库磁盘。

那么是什么导致了这个问题呢?即使安装了正确的库,也从未将数据库配置为使用异步或直接IO。我怀疑这是基于非常低的未完成IO的数量和低数量的IO并发。为了证实这个怀疑,我们从sqlplus运行SHOW PARAMETER FILESYSTEMIO_OPTIONS。输出如下:
名称类型值 ------------------------------------ ----------- ------------------------------ filesystemio_options字符串noneFortunately这是相当直接的答案。使用命令ALTER SYSTEM SET FILESYSTEMIO_OPTIONS=SETALL SCOPE=SPFILE;然后关闭并重新启动实例(您将为生产数据库计划一个维护周期)。
修改后IO时延明显降低,IOPS提高,IO并发性提高,性能比之前提高了10倍左右。客户非常高兴,同时我们也展示了我们的支持是多么的出色。这是一个团队的努力来解决这个问题,一旦客户与我们联系,我们没有花很长时间来解决它。

最后一句虽然这个简单的更改对于Oracle 11g是必需的,但是对于12c却不是必需的。Oracle数据库12c将使用异步或直接IO,如果它在您的操作系统中自动可用。

这篇文章最初发布在longwhiteclouds.com,并在得到允许的情况下复制在这里。原文可以在http://longwhiteclouds.com/2014/11/21/turbo-charge-oracle-database-io-performance/上找到。

1回复

徽章 +2
你好,

您的客户端使用的是什么O/S,它们使用的是成熟的(ext3/4)文件系统还是原始的(ASM)文件系统?

回复


Baidu