电力营销系统Oracle数据库优化研究

摘 要：针对电力营销管理信息系统在实用化运行当中所遇到的问题，重点对数据库的运行状况，通过运用AWR工具，收集性能指标，SQL语句语法等方式进行了分析，对Oracle数据库系统所做的优化和性能调整作了简要的描述。

关键词：Oracle数据库；电力营销系统；优化

前言

随着电力营销系统的信息化建设和应用，其重要性也日益显现。如电费收缴、银电联网等业务均在此系统上运行，具有业务处理繁忙、数据量大、高并发等特点。用户访问量和业务数据不断增加，导致系统负荷越来越重，性能也随之下降。因此，有必要对营销系统数据库进行性能优化调整，这样才能保证电力营销系统健康稳定运行，有效提高运行效率。

1 电力营销系统以及Oracle数据库的概述

电力营销是电力企业在发展过程中重要环节之一，很多业务活动以及项目进行都是电力营销的一种，而电力营销系统主要就是对电力企业营销工作的技术支持，是综合计算机技术、通信技术、自动化技术等为一体的综合系统[1]。Oracle数据库是一种通用性较强的数据库管理系统，具有数据的大量性、数据的共享性、数据保存的永久性、数据的可靠性等特点，Oracle数据库可以最大限度的提升资源的使用率以及灵活性，在电力营销系统中的应用为电力企业的发展做出一定的贡献。

2 电力营销系统Oracle数据库优化

2.1 对应用程序以及数据库表的优化

电力营销系统Oracle数据库的优化是确保电力企业营销系统运行效率的关键，对应用程序以及数据库表的优化是重要目标之一，主要从以下两方面进行优化。一方面，在检索时要选择最有效率的表名顺序[2]。一般情况下，在Oracle数据库解析器运行的过程中，按照正常的形式都是从右到左的顺序来处理FROM子句中的表名，也就是说，FROM子句中最后的表也会最先被处理，在对Oracle数据库解析器运行处理的过程中，如果FROM子句中存在多个表时，要将记录条数最少的表作为FROM处理的基础表。另一方面，在使用Oracle数据库检索时尽量不使用“*”。通过不使用“*”的语句查询，能够更精确查询内容。

2.2 对重做日志组的优化调整

电力营销系统Oracle数据库的优化，不仅要做好以上几方面的优化，同时还要针对运维的过程情况进行效应的优化[3]。在2014年3月份对系统数据库进行巡检的过程中，我们发现数据库告警日志在月初/月中/月末均出现“Checkpoint not complete”，即“检查点未完成”的报错。

checkpoint是一个数据库的内部机制，它存在有两个目的：一是保证数据的一致性。系统发生检查点将出发DBWR进程将缓冲区中的脏数据块写入到数据文件，同时更新数据文件中的SCN号，记录联机重做日志文件中LRBA（low redo block address）的位置到控制文件中，当在写入过程中，突然实例崩溃，脏数据块没有完全写入到数据文件中。当实例启动的时候，会检查控制文件中的 终止SCN号，（四种SCN）这时候发现是空的（数据库正常运行的时候是无穷大或者保持为空），就认为数据库没有正常关闭，需要实例恢复，于是SMON进程根据控制文件中的SCN号，到重做日志文件中取出重做条目重现实例崩溃的那个状态。二是数据库实例崩溃后的实例恢复。当实例恢复的时候，到底从重做日志文件的什么位置开始恢复呢？检查点checkpoint就是记录了一个SCN号，当实例回复的时候从最近的这个检查点做恢复，不必全部恢复重做日志的内容，减少了恢复时间。

日志切换会触发检查点，当检查点触发后会引起DBWR进程将脏数据块写入数据文件，这个时候写入数据文件的脏数据块已经都写入了联机重做日志中，是安全的，当日志缓冲区的日志写满需要切换日志文件的时候，由于下一个日志文件对应的脏数据块没有完全写入到数据文件中，所以不能被覆盖，于是就发生了检查点未完成事件。

当前数据库联机在线日志文件采用裸设备的形式建立，系统共有2个日志线程，每个线程下5个日志组，每个组下面都只有1个成员，每个成员大小为250MB。随着营销业务的增长，原先的日志组成员过小的问题日趋明显。在数据库运行高峰时段，日志切换过于频繁，对性能有一定的影响。因此我们通过将日志组成员大小增加到1GB来解决这个问题。

实施前后性能对比：

（1）数据库告警日志对比

实施前：经常可以再数据库告警日志中看到“Checkpoint not complete”的报错。

实施后，通过以下命令检索告警日志：

yxdb：/tmp$ tail -n 800 /oracle/admin/styd/bdump/alert_styd.log | grep “Checkpoint not complete”

得知命令没有输出，证明营销数据库实例从实施后就没有出现过“检查点未完成”的事件。

（2）24小时内切换次数对比（两个日志线程的总和）

每个月的月初前6天，每天前13小时切换次数对比：

实施前：

实施后：

以上显示了每天00：00～13：00，每小时内日志的切换次数以及每天的切换总数。

每个月的月初前6天，每天后11小时切换次数对比：

实施前：

实施后：

以上显示了每天13：00～24：00，每小时内日志的切换次数以及每天的平均切换次数。通过对比分析可得知实施后，每天的总切换次数和平均切换次数都大幅下降，对系统性能有益。

（3）AWR报告对比

分析：

在redo日志量生成量少于2014年3月9日 04：00～05：00的情况下，2014年3月2日04：00～05：00共发生control file parallel write的等待2，691次，而调整日志组大小后，发生等待2，165次，总等待时间一样，效果显而易见。同样，日志切换次数减少后，实例之间共享控制文件信息的次数也会更少，所以control file sequential read的等待从13，144下降到11，529。

总结：日志组调整成功解决了Checkpoint not complete这个事件，并对系统性能有所优化。

2.3 对超大数据量表的优化

电力企业在运营的过程中，各项业务的数据都会写入电力营销系统Oracle数据库中，不同业务项目在不同时期下都会在Oracle数据库内生成相应的数据表，数据表的数量非常繁多，数据量较小的表格并不会对Oracle数据库产生影响，但是，一些数据量较大的表格会对Oracle数据库的正常运行产生一定的影响，因此，要对超大数据量表进行相应的优化[4-5]。就现阶段电力营销系统Oracle数据库的运行情况来看，超大数据量表主要有实收电费表、应收电费表等。从数据量的统计来看，普遍都在千万级以上，对这些超大数据量表的优化，不仅要采取以月为单位对其进行分区存储，同时应改全局索引为分区索引，这样不仅可以提高超大数据量表的管理效率，同时也能够提升Oracle数据库运行的有效性，可以分区对相关数据进行搜索，提高数据检索的速度，减少CPU的使用率。

3 结束语

综上所述，电力营销系统Oracle数据库在运行的过程中，产生的一些问题，主要是由于电力企业的发展速度较快，再加上业务量的不断增加，并没有对Oracle数据库进行及时优化而导致的，因此，要根据电力企业的发展趋势对电力营销系统Oracle数据库进行不断的优化。通过文章对电力营销系统Oracle数据库的优化分析，作者主要从应用程序以及数据库表的优化、对重做日志组大小的调整、超大数据量表的优化等几方面内容进行分析，希望通过文章的分析，对提升电力营销系统Oracle数据库的运行效率给予一定的帮助。

参考文献

[1]孙风栋，闫海珍.Oracle 10g数据库系统性能优化与调整[J].计算机技术与发展，2014（2）.

[2]潘敏，傅扬，史晓翠.Oracle数据库性能优化的分析[J].电脑编程技巧与维护，2012（20）.

[3]高攀，施蔚然.基于Oracle数据库的SQL语句优化[J].电脑编程技巧与维护，2013（22）.

[4]王可君，王爱红.浅谈Oracle数据库SQL语句的优化[J].有线电视技术，2014（3）.

[5]蒋亚璇.Oracle数据库调整、优化策略[J].经营管理者，2013（14）.