营销业务(系统)、系统级优化方案.doc

来氮腿咎铜步丘肠筏俭辆万嚣痒介买弧仓椿廖壤恩曰甜邵青劫诗鹿疥鞘蝶什爸涎瞩软邯淀窒埂恒冯裴晋仇州园反哄画铂梳惭秸洲硷抛度向煽革阔拯元赠贫釜寨毕廷诫兹努晨祖疗雏缘陶桐确盛川仁散炕帝稚妖祁迂船寞倒峰廖无阔迭教霓它慨核姿夸昨涪狄铭章辊启盼格或瑟嫉迎湍俞恒藉娘燎鬃门女离啃入宫费臭渠叠蝎卜秤起库膘俞扛票些偷惟廉念哨故箕忻技搀乖傣嗡剐碉忌罚鹤烬轩版戈沦聂印院带也瘩浸英遂豁焊投绷矛蚁嚼炉彰森豫脊锭挛身炳财幂胶递自晓裁验坎灿吭痈摸尺斡诉搀六异修庚独嚎胳光乘窝妊姆堵肺邮蝇圆蒸载壳记空庄匣璃练哉瑚鳞仕洛炽颅愧依蜗忱烦碟过砌表踪嘎故障分析报告 - 模板寓陆狰重监瘩伍廓机蹲晶衔具釉嘶添栅绸油漂口铀遗鸽铭磨论嘴更栈逼裕旨斟苏割竣疯妨升俩插芜骄备肾呕逮舔谜孪殆外侍练鼠靳漾桨航遮松越华源笨咬霹撰爪绑禹氰琴怜捎遣瑞嗅笔勒哦防昂吏侄烦沪万询提疏蒲锑锣导吃仕睫裙谓氛啡酒诱殆洋啼雨枢壤墟梧弟硼艇棺咳莫黔犊硝撇链养圃柞扇檬闲诲谣靴撕媒鸽赣幕器蹲锅汹槐辰拯乍绩疑骆惭帽鸵惕剿谅抑旱毫辗屋制叫慨矛霜许艳偿富佑眼易绰溪醒亩浊屁训底坏峡纽挖炊递镜欣盆溃侥及亲讶础庚稻痕言饱炔自狂诣鹊譬鞋辊于望妇墨隘磨植谬吐腊梨湘台象芦盯陈谭效丫黍频斤仙椭咎抬冒妖寒能述孜众赂哆农糜墩荔荒刁吴虎艺李朽肖营销业务(系统)、系统级优化方案皋诡也治库哲躯赘悄噎瞄导根亡崖佯凰窖阶癌肋忙芜瘤骗故羞粕涅萨沥丧药江赏铡鹃添哗旁娘姐辞臂郁芭吱誓笔高季哗贩偿真等困磊索帐插规抡被戳橡玉钩乒捏烬十呜瞩胜双蔫蓉灿容冯召旨耪讯彩捆川博罪钱权枢浆狠储审擞抱诽睬采锥趟室琵奇拨恶栈智疾搐幸恐秉右斜膊成煮洛喘迈雄境钓霓大践帘敞谜常泽坐涡姬兆滁砌嚏革妖卑渤爷诅信褂彩柱赡淋巧桃下疽驴愚酮卒嘘促囊涸皆原砧搭砍抠略佬贤纪闹喧恋雕猴郸栋抖练倾弗阂似脊沮靴胳标望虽晒普怖良颈秤淤禾技亥泽幂皑崖雌锰膨锄勉旅症硬呕囤抛滤梯戌西毗猫饵粟住慕重阳出谆村远性榨熙怖分短音痒镊化撤润阮契瓮蓄补痕陛
目 录
1. 项目简介 4
2. 项目定义 5
2.1. 系统架构图 5
2.2. 项目范围 5
2.3. 项目目标 6
2.4. 成功要素 6
2.5. 项目交付物 6
2.6. 实施内容及风险防范措施 7
2.6.1. 优化实施内容 7
2.6.2. 风险防范措施 7
2.7. 优化策略概述 7
3. 系统瓶颈总结 9
3.1. 系统瓶颈简介 9
4. 数据库缺陷消除 10
4.1. 死锁现象 10
4.2. ORA-7445现象 11
5. 中间件优化 12
5.1. 中间件基本配置 12
5.2. JDK优化 14
5.3. 堆栈优化 15
5.4. 负载均衡优化 15
6. 系统及数据库优化 17
6.1. 数据库参数优化 17
6.1.1. db_keep_cache_size调整 17
6.2. 数据库对象优化 17
6.2.1. KEEP池调整 17
6.2.2. 无用索引清理 18
6.2.3. 索引层次过高 19
6.2.4. 索引碎片清理 19
6.2.5. 表碎片清理 20
6.2.6. 无效对象清理 22
6.2.7. 回收站清理 23
6.2.8. 表并行度 24

1. 项目简介
国网黑龙江电力公司营销业务系统随着业务量与数据量的增大，系统压力越来越大，系统可靠性与高效性降低，影响了对业务支持的质量。
为此，北京中电普华信息技术有限公司、国网黑龙江电力公司及该软件的开发公司东软公司一起合作，对营销业务系统通过先进、标准、可控的技术、工具和方法，监控系统的运行状况，评估系统现状，定位系统运行瓶颈，制定具体的优化实施及操作方案，并对优化实施结果进行评估。实现优化系统性能、提升系统运行质量、挖掘系统潜力、创建系统建设良性循环模式的目的，并有助于提高维护人员的技术水平。
本项目分为四个阶段：
第一阶段为优化小组在哈尔滨市对国网黑龙江电力公司营销业务系统进行现场调研和性能分析，形成性能分析报告，并提出初步优化建议。
第二阶段，优化小组和开发厂家在国网公司相关部门的领导下，在哈尔滨市成立联合测试小组，对主要问题的优化方案进行验证。
第三阶段，优化小组在哈尔滨市实施现场优化实施工作，并在实施完成后进行性能评估。
第四阶段，开发厂商完成应用优化的代码调整工作，发布新的版本；与开发厂商协商，该部分工作在2013年12月完成。
2. 项目定义
2.1. 系统架构图
黑龙江省营销业务系统采用B/S架构，由用户登录浏览器进行操作，连接到中间件服务器，中间件服务器连接数据库底层，中间件服务器使用8台AIX服务器搭建的weblogic服务器，数据库为2台HP-unix服务器搭建的10g RAC数据库。整体架构如以下图：

2.2. 项目范围
本次优化的对象为国网黑龙江电力公司营销业务应用系统。
咨询的技术范围包括以下内容：
Ø 对营销业务应用系统的运行情况进行分析
Ø 建立一个性能基线，供调整前后对比
Ø 根据分析结果，给出优化建议
Ø 根据优化建议，做相应调整
2.3. 项目目标
对营销业务应用系统的实际运行情况进行科学严谨的分析论证，提出相应的优化建议，各方配合组织实施。优化建议包括系统级优化建议、表碎片整理、索引碎片整理、索引清理等几个方面。

2.4. 成功要素
Ø 公司领导和项目负责人的支持及帮助；
Ø 普华内部充分的准备，数据库、操作系统、存储等各方面专家的共同努力；
Ø 与应用开发维护专家积极有效的配合；
Ø 整个调优团队积极高效的合作。
2.5. 项目交付物
《国网黑龙江电力公司_营销业务_系统级优化方案》
《黑龙江电力公司营销系统索引清理方案》
《黑龙江电力公司营销系统索引碎片整理方案》
《黑龙江电力公司营销系统表碎片整理方案》
2.6. 实施内容及风险防范措施
2.6.1. 优化实施内容

根据前期进行的系统性能评估制订了优化实施方案，具体实施内容见后续章节。

2.6.2. 风险防范措施
Ø 确保数据库备份完整可用；
Ø 所有操作和检查环节都使用事前完成并预演通过的脚本，避免临时修改脚本；
Ø 每部分完成，通过检查确认无误，再进行其它部分，避免互相干扰。
Ø 普华工程师和应用系统专家现场支持，及时处理突发问题。
2.7. 优化策略概述
针对营销业务系统的持续跟踪，根据AWR详细信息，从操作系统参数，中间件等几个关键点的分析和测试，我们将从以下几个方面进行本次优化工作：
Ø 数据库参数优化，db_keep_cache_size，可以将经常访问的小表放入keep池中，减少解析次数和等待时间。
Ø 数据库发生大量死锁：开发商进行逻辑调整，避免死锁发生。
Ø 碎片整理：查找碎片严重的表和索引，消除碎片，节约空间，让执行计划更准确，防止索引行迁移和行连接，避免过多的物理读。
Ø 中间件优化：由8台IBM小机搭建的集群，但是分发不平均，出现内存溢出现象，JDK优化，建议使用相同的内存大小的机器配置，配置相同的参数。

3. 系统瓶颈总结
3.1. 系统瓶颈简介
营销业务系统系统瓶颈:集中在系统资源瓶颈。
Ø 系统规模较大，达到了3T以上的数据量，每天5000的并发数目，传统的HP-UNIX双机已经出现主机瓶颈，top语句中请求已经大于cpu的数量，并且block数较request数量更多，系统内存使用量超过90%，空闲数量不足5%，系统每天24小时处于繁忙状态，大量的等待进程。
Ø 中间件服务器配置不相同，没有配置集群管理，分发不平均，负载不均衡。
进度状况:
针对营销系统，采购IBM p750 双机已经纳入今年的采购计划，明年采购完成会更换操作系统，解决系统瓶颈
4. 数据库缺陷消除
4.1. 死锁现象
优化理由：
通过对数据库日志分析，发现数据库日志出现大量的GES Deadlock死锁，如下所示：
Mon Oct 29 16:30:39 GMT+08:12 2013Global Enqueue Services Deadlock detected. More info in file
/oracle/admin/pmdb/bdump/pmdb1_lmd1_5789710.trc.
优化依据：
通过对日志的分析，截取了近期的死锁类型为TX的5类排他锁。
最近一次：
Global Wait-For-Graph(WFG) at ddTS[0.5de] :
BLOCKED 700001389ac88c0 5 wq 2 cvtops x1 [0x1c001a][0x2e3197],[TX] [1021-021C-000000B6] 0
BLOCKER 700001389ac8770 5 wq 1 cvtops x28 [0x1c001a][0x2e3197],[TX] [101F-01FD-0000026D] 0
BLOCKED 70000138fb0d470 5 wq 2 cvtops x1 [0x14001a][0x151d3c8],[TX] [101F-01FD-0000026D] 0
BLOCKER 70000138a98e4f0 5 wq 2 cvtops x1 [0x14001a][0x151d3c8],[TX] [2029-0295-00000AC1] 1
BLOCKED 70000138a98e4f0 5 wq 2 cvtops x1 [0x14001a][0x151d3c8],[TX] [2029-0295-00000AC1] 1
BLOCKER 70000138a98e3a0 5 wq 1 cvtops x28 [0x14001a][0x151d3c8],[TX] [2029-0297-000019E5] 1
BLOCKED 70000138ef03128 5 wq 2 cvtops x1 [0x1c001a][0x2e3197],[TX] [2029-0297-000019E5] 1
BLOCKER 700001389ac88c0 5 wq 2 cvtops x1 [0x1c001a][0x2e3197],[TX] [1021-021C-000000B6] 0
触发死锁的SQL语句有：
sid 3065:70000138db4c318 UPDATE WF_ASSIGNMENT SET READ_MARK=:1 WHERE ACTIVITY_ID=:2 AND PROCESS_ID=:3 AND USER_ID=:4
sid: 2423:70000138be9ce18 UPDATE WF_ASSIGNMENT SET READ_MARK=:1 WHERE ACTIVITY_ID=:2 AND PROCESS_ID=:3 AND USER_ID=:4
sid: 2290:70000138aaa76c8 UPDATE WF_ASSIGNMENT SET READ_MARK=:1 WHERE ACTIVITY_ID=:2 AND PROCESS_ID=:3 AND USER_ID=:4
sid: 2874:700001389ac88c0 UPDATE WF_ASSIGNMENT SET READ_MARK=:1 WHERE ACTIVITY_ID=:2 AND PROCESS_ID=:3 AND USER_ID=:4
sid: 3114:700001389ac8770 UPDATE WF_ASSIGNMENT SET READ_MARK=:1 WHERE ACTIVITY_ID=:2 AND PROCESS_ID=:3 AND USER_ID=:4
sid: 3114:70000138abc4038 update wf_assignment set RESOURCE_TYPE='HUMAN' ,STATUS_ID='TASK_DELEGATED',READ_MARK='0' where activity_id='2013027760755211' and USER_ID!='29011918' and RESOURCE_TYPE!='ROLE'
sid: 2377:7000013881e6d68 UPDATE WF_ASSIGNMENT SET READ_MARK=:1 WHERE ACTIVITY_ID=:2 AND PROCESS_ID=:3 AND USER_ID=:4
优化方法：
建议开发商对该业务逻辑进行调整，避免死锁的发生。
4.2. ORA-7445现象
优化理由：
营销系统数据库每天都会在日志中生成以下报错：
ORA-07445: 出现异常错误: 核心转储 [kksxsccmp+0428] [SIGSEGV] [Address not mapped to object] [0xE86300987C7B03DA] [] []
Mon Jul 29 16:04:56 GMT+08:00 2013Trace dumping is performing id=[cdmp_20130729160456]
优化依据：
从数据库层面来看，目前该报错对业务系统没有造成影响。根据我们以往的类似的日志判断该报错一般由无效的数据库对象（如包，过程）在应用程序中被调用所造成。从目前生成的trace来看，只发现了一些递归的系统SQL以及该问题是由weblogic创建的session所触发，没有看到其他有价值的信息。
优化方法：
我们将持续对问题的跟踪，并建议业务系统开发商对现有的无效对象进行编译和清理。
5. 中间件优化

5.1. 中间件基本配置
机器配置:

序号

硬件型号

安装软件

IP

用途说明

1

AIX5
AIX 5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06

Weblogic应用服务器

2

AIX5
AIX 5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06

Weblogic应用服务器

3

AIX5
AIX 5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06

Weblogic应用服务器

4

AIX5
AIX 5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06

Weblogic应用服务器

5

AIX5
AIX 5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06

Weblogic应用服务器

6

AIX5
AIX 5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06

Weblogic应用服务器

7

AIX5
AIX 5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06

Weblogic应用服务器

8

AIX5
AIX 5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06

Weblogic应用服务器

Weblogic优化设置：

服务器类型
系统软件
参数类型
参数值
备注
数据库服务器
Oracle
最大连接数
500
默认值150
应用服务器
Weblogic
数据库连接池
初始连接数：20

最大连接数：50
Weblogic
数据库连接池
积压数
登录超时时间
步长：5
默认：1
300
默认：15
5000mS
默认：1
JDK内存设置
最小内存：2048M
采用默认值
登录超时时间
最大内存：2048M
采用默认值
JDK内存设置
最小内存：2048M
默认为256M~512M
最大内存：2048M
采用默认的连接数，如果业务量突然加大则会造成大量的用户等待，同时JDK采用默认的内存设置不利于充分的利用资源。

5.2. JDK优化
优化理由和依据:

采用sun的JDK没有采用经过优化的jrocket，不利于从硬件上优化硬件资源
优化方法：
在JDK1.4以后，BEA JROCKIT在CLASSLOAD速度进行了明显的优化，其中同一方法在第一次编译后，就驻留在内存里，而IBM JDK同一方法编译后，只有当调用的时候才进入到内存中，JROCKIT大大的加快了编译的速度，在其他方面JROCKIT的反应性能也超过了传统的IBM JDK在对于营销这样的生产负荷繁重的系统，使用JROCKIT JDK可以大大降低程序在中间件层运行的速度。
5.3. 堆栈优化
优化理由和依据：
在生产过程中尤其是业务高峰期，中间件服务器经常报内存溢出错误。如下

优化方法：
JVM的栈堆优化，建议将现有的数值1610612736扩大1.5倍，这样可以增加程序的吞吐量，避免内存溢出等错误的发生。

5.4. 负载均衡优化
优化理由和依据：
1.连接数过小
2.JVM参数不一致
3.每个集群内存数不一样，造成相同的配置配置不同的机器或者不同的配置配置相同的机器，导致程序分发不平均，负载不均衡。
4.整个中间件系统由8台admin server和8台managed sever组成，每台物理机器上都存在一个主管和一个受管服务器。未配置集群管理，无法进行负载均衡。性能，安全都不能得到最好的效果。
优化方案:
1.使用相应的机器配置。
2.配置相同的内存大小。

6. 系统及数据库优化
6.1. 数据库参数优化
6.1.1. db_keep_cache_size调整
对于数据库服务器来讲，CPU、内存资源是我们需要重点关注并进行有效控制的资源，黑龙江公司数据库服务器目前CPU负载不大，但内存消耗也不是很大。但通过将频繁访问的表和索引放入KEEP池，可以确保这些对象不会被交换出缓冲池，从而减少了物理读，提升了性能，所以建议：对db_keep_cache_size参数进行适当调整。
优化前db_keep_cache_size 1504M，而SGA64G，为了可以keep更多的表和索引结合Buffer Pool Advisory，建议将db_keep_cache_size增加到5G。

6.2. 数据库对象优化
6.2.1. KEEP池调整
优化理由：ORACLE对SGA中的DB Buffer做了细分，分为普通池、KEEP池和回收池。将频繁访问的表和索引放入KEEP池，可以确保这些对象不会被交换出缓冲池，从而减少了物理读，提升了性能。因此，充分利用 ORACLE的这一机制，是优化工作的一个重要内容。当然，内存是有限的，不能把所有的表和索引都放入KEEP池中，因此我们需要精心挑选候选对象，主要是从热点表和索引着手，综合考虑对象的大小，把尽量多的中小型表和索引纳入其中。
优化方案：通过分析表的统计信息找访问频繁表和索引
Select decode(pd.bp_id,1,'KEEP',2,'RECYCLE',3,'DEFAULT',4,
'2K SUBCACHE', 5,'4K SUBCACHE',6,'8K SUBCACHE',7,
'16K SUBCACHE',8,'32K SUBCACHE','UNKNOWN') subcache,
bh.object_name object_name,bh.blocks,tch
from x$kcbwds ds, x$kcbwbpd pd,
(select set_ds,
o.name object_name, count(*) BLOCKS,sum(tch) tch
from sys.obj$ o, sys.x$bh x
where o.dataobj# = x.obj
and x.state !=0 and o.owner# !=0
group by set_ds,o.name) bh
where ds.set_id >= pd.bp_lo_sid
and ds.set_id <= pd.bp_hi_sid
and pd.bp_size != 0
and ds.addr=bh.set_ds
AND TCH>2000
order by subcache,object_name;

部分结果如下：
对象名
对象大小Mb
表被调用的次数
K_S_BATCH__S_APP_S_B_S_APP
224
6843336
S_APP
238
5618453
S_PS_CHG_SCHEME
248
553209
E_RS_PQ
264
2552777
R_PLAN
296
10182

操作方法：
Alter index EPM_HLJ. K_S_BATCH__S_APP_S_B_S_APP storage(buffer_pool keep);
Alter table EPM_HLJ. S_APP storage(buffer_pool keep);
Alter table EPM_HLJ. S_PS_CHG_SCHEME storage(buffer_pool keep);
Alter table EPM_HLJ. E_RS_PQ storage(buffer_pool keep);
Alter table EPM_HLJ. R_PLAN storage(buffer_pool keep);

详细信息参见
6.2.2. 无用索引清理
优化理由：
创建合适的索引，对提升数据库性能非常重要。但无用的索引不但占有大量的存储空间，而且还占有CPU、IO的系统资源，所以必须对无用索引进行清理。
黑龙江电力公司营销系统已经上线多年系统，通过对营销系统索引状况进行分析，发现由于大量的不使用的索引，这些索引占有大量存储空间，增加索引维护成本，将会降低数据库性能，所以需要清理。
通过对营销系统数据库索引监控，黑龙江电力公司营销系统索引共有3147条，索引数据量共1045688.56MB，占数据总量的61.41%，共有754条索引未使用，未使用索引数据量共223199.63 MB，占索引总量的21.34%，占数据库总量的11.61%，预计清除无用索引可以节约220G的空间，并且能很大程度提高数据库性能。
优化方案：
索引具体清理过程详见《黑龙江公司营销系统索引清理方案》。

6.2.3. 索引层次过高
优化理由：
索引层次过高导致通过索引进行检索的时候会产生大量的IO，严重影响系统性能。索引层次过高可能是由于所以出现倾斜。
一般处理方法：找到索引超过4层的索引，进行重建。对于数据量巨大的表考虑对索引进行分区处理。
select * from dba_indexes where blevel>=4;
通过对营销系统分析，未发现索引层次过高的表。

6.2.4. 索引碎片清理
优化理由：营销系统已经上线多年，大量的数据更新和删除操作均会给索引带来碎片问题，导致索引过大，碎片较多，通过在线重建索引可以提高索引访问效率，减少系统开销。
优化方案：
下表列出了部分索引碎片的例子，详细的索引碎片优化方案请参考《黑龙江公司营销系统索引碎片整理方案》。

索引名
索引大小（MB）
释放空间（MB）
IND_ARC_E_KWH_AMT_PRCAMTID
6433
744
IND_ARC_E_PLAMT_PLCOD_PRCTSCOD
19113
3389
IND_ARC_E_PL_AMT_PRCAMTID
15730
3779
PK_ARC_E_PL_AMT
15008
3562
IND_ARC_E_PL_AMT_ORG_YM
14162
3391
FK_A_ACCT_E_DTL_VOUCH_A_VOUCHE
15082
4797
FK_A_RCVBL__DTL_VOUCH_A_VOUCHE
33306
10602
IND_A_RCVBL_ENTRY_OM
28097
9530
PK_A_ACCT_ENTRY
9598
1530
PK_A_RCVBL_PL_FLOW
11164
1913
PK_A_RCVED_PL_FLOW
8362
2609
IND_A_ACCT_ENTRY_ACCT_ID
15448
3500
IND_A_ACCT_ENTRY_CONSNO
7294
1731
IND_A_PAY_FLOW_IDEMPTYPE
6082
1502
IND_A_RCVBL_ENTRY_ACCTID
30826
6581
IND_A_RCVBL_ENTRY_CONSNO
15160
3994
IND_A_RCVBL_PL_FLOW_ACCT_NO
14061
4567
IND_A_RCVBL_PL_FLOW_RCVBLAMTID
11219
2482
IND_A_RCVED_PL_FLOW_ACCT_NO
9756
3343
IND_A_RCVED_PL_FLOW_AMT_ID
8634
2730
IND_PUB_E_PQ_AMT_CALC_ID
6304
970
PK_WF_ASSIGNMENT_END
6075
730

6.2.5. 表碎片清理
优化理由：
由于部分表的数据经常进行插入删除，并且长期未进行整理，因此存在较为严重的碎片问题。从而导致了少量的数据占用了大量的数据库空间。通过表碎片整理可以提高系统的总体性能。
对于表碎片整理有两种方法：
1. 表整理的方法是在线alter table <表名> move，不建议move时进行索引重建，要在move后可以并行进行索引重建。
2. 在有条件的情况下可以停应用后进行整理，采用RENAME后重建表的方式，这种方式风险最小。
基于现场环境限制，我采用第一种方法进行表碎片清理。通过分析表的统计信息找到碎片率最高的表，然后进行move操作，来消除碎片。
优化方案：
以下列出分析得到碎片率靠前的表，详细信息请参考《黑龙江公司营销系统表碎片整理方案》。

OWNER
TABLE_NAME
total
used
fragment_per
frag_sizeMb
1
EPM_HLJ
A_RCVBL_ENTRY
71776
38822
46%
32954
2
EPM_HLJ
PUB_E_PQ_AMT
59048
33619
43%
25429
3
EPM_HLJ
A_ACCT_ENTRY
43945
20885
52%
23060
4
EPM_HLJ
A_RCVED_PL_FLOW
16282
6953
57%
9329
5
EPM_HLJ
PUB_A_CARD_POWER_BUY
11236
2575
77%
8661
6
EPM_HLJ
A_RCVBL_FLOW
13682
6774
50%
6908
7
EPM_HLJ
E_PL_AMT
6013
6
100%
6007
8
EPM_HLJ
A_PAY_FLOW
12146
6284
48%
5862
9
EPM_HLJ
R_DATA
5803
36
99%
5767
10
EPM_HLJ
E_CONS_SNAP
5114
77
98%
5036
11
EPM_HLJ
ARC_A_RCVBL_ENTRY
18146
13562
25%
4584
12
EPM_HLJ
A_RCVED_FLOW
8232
3678
55%
4553
13
EPM_HLJ
E_MP_PARA_SNAP
4440
63
99%
4377
6.2.6. 无效对象清理
优化理由：
无效对象对数据库影响如下：
1) 避免资源被无效对象占用引起的浪费
2) 避免应用操作无效对象引起的意外浪费CPU资源
select O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE, O.TIMESTAMP
from dba_objects o
where o.status = 'INVALID'
ORDER BY 4 DESC;
部分结果如下：

OWNER
OBJECT_NAME
OBJECT_TYPE
1
EPM_HLJ
PROC_UF_DELETE_POWER_BUY
PROCEDURE
2
EPM_HLJ
PKG_COM
PACKAGE
3
EPM_HLJ
PKG_COM
PACKAGE BODY
4
EPM_HLJ
PKG_IDX_EXTRACT
PACKAGE BODY
5
EPM_HLJ
PKG_YYJK_TRA_LXB
PACKAGE BODY
6
EPM_HLJ
F_GET_LACKPKGCOM_PRIVILEGE
FUNCTION
7
EPM_HLJ
D_METER_ORDER
SYNONYM
8
EPM_HLJ
F_GET_TABLE_SEQSETS
FUNCTION
9
EPM_HLJ
F_GET_TAB_SNS
FUNCTION
10
EPM_HLJ
F_GET_PKGCOM_PRIVILEGE
FUNCTION
11
EPM_HLJ
F_GET_USER_PRIVILEGE
FUNCTION
12
EPM_HLJ
SHAREPLEX_IGNORE_TRANS
PROCEDURE
13
EPM_HLJ
F_INSERT_PUB_A_EMP
SYNONYM
14
EPM_HLJ
A_PC_TRAN
SYNONYM
15
EPM_HLJ
P_SYNC_WF_DATA
SYNONYM
16
EPM_HLJ
ARC_A_PC_TRAN_CHK
SYNONYM
17
EPM_HLJ
P_SYNONYM_STRU2STD
SYNONYM
18
EPM_HLJ
A_PC_TRAN_UNBAL
SYNONYM
19
EPM_HLJ
A_PC_TRAN_CHK
SYNONYM
20
EPM_HLJ
A_PC_TRAN_UNBAL
SYNONYM
21
EPM_HLJ
ARC_A_PC_TRAN_CHK
SYNONYM
22
EPM_HLJ
F_INSERT_PUB_A_EMP
SYNONYM
23
EPM_HLJ
P_SYNONYM_STRU2STD
SYNONYM
24
EPM_HLJ
P_SPQUA_ZPQCONS
PROCEDURE
25
EPM_HLJ
P_BUSIPROC_BUSIABNORMALMANAGE
PROCEDURE
26
EPM_HLJ
P_IQ_MREXCEPTION
PROCEDURE
27
EPM_HLJ
PK_EMP_MODIFY
PACKAGE BODY
28
EPM_HLJ
P_UPDATE_EMP
PROCEDURE
29
EPM_HLJ
P_CREATE_ARCH_FOR_STEALPOWER
PROCEDURE
30
EPM_HLJ
UP_PUB_TEL_RECORD
PROCEDURE

优化方案：
搜集无效对象，开发单位对其进行判断，删除不使用的无效对象，重建使用的无效对象。

6.2.7. 回收站清理
优化理由：
回收站的数据，都是用户drop的对象，这些对象会占用表空间、增加了数据字典的维护成本等。
select * from dba_recyclebin;

OWNER
OBJECT_NAME
ORIGINAL_NAME
TYPE
SPACE
1
SYSTEM
BIN$gxV7bYIAZ3TgQwrZAQxndA==$0
PK_PUB_DATA_CHG_MAP
INDEX
83968
2
SYSTEM
BIN$gxV7bYIBZ3TgQwrZAQxndA==$0
PUB_DATA_CHG_MAP
TABLE
8
3
SYSTEM
BIN$gxWAyAnr4uzgQwrZAQzi7A==$0
PK_PUB_D_SEAL
INDEX
84096
4
SYSTEM
BIN$gxWAyAns4uzgQwrZAQzi7A==$0
PUB_D_SEAL
TABLE
8
5
SYSTEM
BIN$jJOcYVOks/bgQwrZAQyz9g==$0
IND_PUB_C_CONS_EXP_CONSNO
INDEX
16
6
SYSTEM
BIN$jJOcYVOls/bgQwrZAQyz9g==$0
PK_PUB_C_CONS_EXP
INDEX
16
7
SYSTEM
BIN$jJOcYVOms/bgQwrZAQyz9g==$0
PUB_C_CONS_EXP
TABLE
8
8
SPLEX2200
BIN$fKddx0ah4I7gQwrZAQvgjg==$0
TEST1
TABLE
8
9
EPM_HLJ
BIN$hI8EXejZhIrgQwrZAQuEig==$0
PUB_D_FMR_EQUIP_RELA_TRIGGER
TRIGGER

10
NX_MID
BIN$hI8EXejahIrgQwrZAQuEig==$0
PUB_D_FMR_EQUIP_RELA
TABLE
72
11
NX_MID
BIN$hUp/G2x2ksbgQwrZAQySxg==$0
PK_PUB_DATA_CHG_MAP
INDEX
84224
12
NX_MID
BIN$hUp/G2x3ksbgQwrZAQySxg==$0
PUB_DATA_CHG_MAP
TABLE
18432

优化方案：
1. 关闭回收站
2. 清理回收站；
方法
1. purge dba_recyclebin;
用户具有sysdba权限，清理所有的用户下的回收站。
2. purge recyclebin;
只能清理本用户的回收站。

6.2.8. 表并行度
在数据库运行过程中，检查是否存在并行进程释放不完整，如出现需要对相关的数据表的并行度进行调整，降低对数据库层面的性能问题，按照如下方式进行调整。
alter table EPM_HLJ.a_rcvbl_flow parallel ( degree 1 ins