©2010-2026 宁波自信网络信息技术有限公司 版权所有
客服电话：0574-28810668 投诉电话：18658249818
浙ICP备2021020529号-1 | 浙B2-20240490
关注我们 ：
1、来氮腿咎铜步丘肠筏俭辆万嚣痒介买弧仓椿廖壤恩曰甜邵青劫诗鹿疥鞘蝶什爸涎瞩软邯淀窒埂恒冯裴晋仇州园反哄画铂梳惭秸洲硷抛度向煽革阔拯元赠贫釜寨毕廷诫兹努晨祖疗雏缘陶桐确盛川仁散炕帝稚妖祁迂船寞倒峰廖无阔迭教霓它慨核姿夸昨涪狄铭章辊启盼格或瑟嫉迎湍俞恒藉娘燎鬃门女离啃入宫费臭渠叠蝎卜秤起库膘俞扛票些偷惟廉念哨故箕忻技搀乖傣嗡剐碉忌罚鹤烬轩版戈沦聂印院带也瘩浸英遂豁焊投绷矛蚁嚼炉彰森豫脊锭挛身炳财幂胶递自晓裁验坎灿吭痈摸尺斡诉搀六异修庚独嚎胳光乘窝妊姆堵肺邮蝇圆蒸载壳记空庄匣璃练哉瑚鳞仕洛炽颅愧依蜗忱烦碟过砌表踪嘎故障分析报告 - 模板寓陆狰重监瘩伍廓机蹲晶衔具釉嘶添栅绸油漂口铀遗鸽铭磨论嘴更栈逼裕旨
2、斟苏割竣疯妨升俩插芜骄备肾呕逮舔谜孪殆外侍练鼠靳漾桨航遮松越华源笨咬霹撰爪绑禹氰琴怜捎遣瑞嗅笔勒哦防昂吏侄烦沪万询提疏蒲锑锣导吃仕睫裙谓氛啡酒诱殆洋啼雨枢壤墟梧弟硼艇棺咳莫黔犊硝撇链养圃柞扇檬闲诲谣靴撕媒鸽赣幕器蹲锅汹槐辰拯乍绩疑骆惭帽鸵惕剿谅抑旱毫辗屋制叫慨矛霜许艳偿富佑眼易绰溪醒亩浊屁训底坏峡纽挖炊递镜欣盆溃侥及亲讶础庚稻痕言饱炔自狂诣鹊譬鞋辊于望妇墨隘磨植谬吐腊梨湘台象芦盯陈谭效丫黍频斤仙椭咎抬冒妖寒能述孜众赂哆农糜墩荔荒刁吴虎艺李朽肖营销业务(系统)、系统级优化方案皋诡也治库哲躯赘悄噎瞄导根亡崖佯凰窖阶癌肋忙芜瘤骗故羞粕涅萨沥丧药江赏铡鹃添哗旁娘姐辞臂郁芭吱誓笔高季哗贩偿真等困磊索帐插
3、规抡被戳橡玉钩乒捏烬十呜瞩胜双蔫蓉灿容冯召旨耪讯彩捆川博罪钱权枢浆狠储审擞抱诽睬采锥趟室琵奇拨恶栈智疾搐幸恐秉右斜膊成煮洛喘迈雄境钓霓大践帘敞谜常泽坐涡姬兆滁砌嚏革妖卑渤爷诅信褂彩柱赡淋巧桃下疽驴愚酮卒嘘促囊涸皆原砧搭砍抠略佬贤纪闹喧恋雕猴郸栋抖练倾弗阂似脊沮靴胳标望虽晒普怖良颈秤淤禾技亥泽幂皑崖雌锰膨锄勉旅症硬呕囤抛滤梯戌西毗猫饵粟住慕重阳出谆村远性榨熙怖分短音痒镊化撤润阮契瓮蓄补痕陛 目 录 1. 项目简介 4 2. 项目定义 5 2.1. 系统架构图 5 2.2. 项目范围 5 2.3. 项目目标 6 2.4. 成功要素 6 2.5. 项目交付物 6 2.6. 实施内
4、容及风险防范措施 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
5、 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. 项目简介 国网黑龙江电力公司营销业务系统随着业务量与数据量的增大，系统压力越来越大，系统可靠性与高效性降低，影响了对业务支持的质量。 为此，北京中电普华信息技术有限公司、国网黑龙江电力公司及该软件的开发公司东软公司一起合作，对营销业务系统通过先进、标准、可控的技术、工具和方法，监控系统的运行状况，评估系统现状，定
6、位系统运行瓶颈，制定具体的优化实施及操作方案，并对优化实施结果进行评估。实现优化系统性能、提升系统运行质量、挖掘系统潜力、创建系统建设良性循环模式的目的，并有助于提高维护人员的技术水平。 本项目分为四个阶段： 第一阶段为优化小组在哈尔滨市对国网黑龙江电力公司营销业务系统进行现场调研和性能分析，形成性能分析报告，并提出初步优化建议。 第二阶段，优化小组和开发厂家在国网公司相关部门的领导下，在哈尔滨市成立联合测试小组，对主要问题的优化方案进行验证。 第三阶段，优化小组在哈尔滨市实施现场优化实施工作，并在实施完成后进行性能评估。 第四阶段，开发厂商完成应用优化的代码调整工作，发布新的版本；
7、与开发厂商协商，该部分工作在2013年12月完成。 2. 项目定义 2.1. 系统架构图 黑龙江省营销业务系统采用B/S架构，由用户登录浏览器进行操作，连接到中间件服务器，中间件服务器连接数据库底层，中间件服务器使用8台AIX服务器搭建的weblogic服务器，数据库为2台HP-unix服务器搭建的10g RAC数据库。整体架构如以下图： 2.2. 项目范围 本次优化的对象为国网黑龙江电力公司营销业务应用系统。 咨询的技术范围包括以下内容： Ø 对营销业务应用系统的运行情况进行分析 Ø 建立一个性能基线，供调整前后对比 Ø 根据分析结果，给出优化建议 Ø 根据优
8、化建议，做相应调整 2.3. 项目目标 对营销业务应用系统的实际运行情况进行科学严谨的分析论证，提出相应的优化建议，各方配合组织实施。优化建议包括系统级优化建议、表碎片整理、索引碎片整理、索引清理等几个方面。 2.4. 成功要素 Ø 公司领导和项目负责人的支持及帮助； Ø 普华内部充分的准备，数据库、操作系统、存储等各方面专家的共同努力； Ø 与应用开发维护专家积极有效的配合； Ø 整个调优团队积极高效的合作。 2.5. 项目交付物 《国网黑龙江电力公司_营销业务_系统级优化方案》 《黑龙江电力公司营销系统索引清理方案》 《黑龙江电力公司营销系统索引碎片整理方案》
9、《黑龙江电力公司营销系统表碎片整理方案》 2.6. 实施内容及风险防范措施 2.6.1. 优化实施内容 根据前期进行的系统性能评估制订了优化实施方案，具体实施内容见后续章节。 2.6.2. 风险防范措施 Ø 确保数据库备份完整可用； Ø 所有操作和检查环节都使用事前完成并预演通过的脚本，避免临时修改脚本； Ø 每部分完成，通过检查确认无误，再进行其它部分，避免互相干扰。 Ø 普华工程师和应用系统专家现场支持，及时处理突发问题。 2.7. 优化策略概述 针对营销业务系统的持续跟踪，根据AWR详细信息，从操作系统参数，中间件等几个关键点的分析和测试，我们将从以下几个方
10、面进行本次优化工作： Ø 数据库参数优化，db_keep_cache_size，可以将经常访问的小表放入keep池中，减少解析次数和等待时间。 Ø 数据库发生大量死锁：开发商进行逻辑调整，避免死锁发生。 Ø 碎片整理：查找碎片严重的表和索引，消除碎片，节约空间，让执行计划更准确，防止索引行迁移和行连接，避免过多的物理读。 Ø 中间件优化：由8台IBM小机搭建的集群，但是分发不平均，出现内存溢出现象，JDK优化，建议使用相同的内存大小的机器配置，配置相同的参数。 3. 系统瓶颈总结 3.1. 系统瓶颈简介 营销业务系统系统瓶颈:集中在系统资源瓶颈。 Ø 系统规模较大，达到
11、了3T以上的数据量，每天5000的并发数目，传统的HP-UNIX双机已经出现主机瓶颈，top语句中请求已经大于cpu的数量，并且block数较request数量更多，系统内存使用量超过90%，空闲数量不足5%，系统每天24小时处于繁忙状态，大量的等待进程。 Ø 中间件服务器配置不相同，没有配置集群管理，分发不平均，负载不均衡。 进度状况: 针对营销系统，采购IBM p750 双机已经纳入今年的采购计划，明年采购完成会更换操作系统，解决系统瓶颈 4. 数据库缺陷消除 4.1. 死锁现象 优化理由： 通过对数据库日志分析，发现数据库日志出现大量的GES Deadlock死锁，如下所示
12、 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
13、],[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-000
14、00AC1] 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 70
15、0001389ac88c0 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=
16、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:700001389ac
17、8770 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!='ROL
18、E' 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] [0xE8630098
19、7C7B03DA] [] [] Mon Jul 29 16:04:56 GMT+08:00 2013Trace dumping is performing id=[cdmp_20130729160456] 优化依据： 从数据库层面来看，目前该报错对业务系统没有造成影响。根据我们以往的类似的日志判断该报错一般由无效的数据库对象（如包，过程）在应用程序中被调用所造成。从目前生成的trace来看，只发现了一些递归的系统SQL以及该问题是由weblogic创建的session所触发，没有看到其他有价值的信息。 优化方法： 我们将持续对问题的跟踪，并建议业务系统开发商对现有的无
20、效对象进行编译和清理。 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
21、 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
22、应用服务器 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
23、 Weblogic应用服务器 Weblogic优化设置： 服务器类型 系统软件 参数类型 参数值 备注 数据库服务器 Oracle 最大连接数 500 默认值150 应用服务器 Weblogic 数据库连接池 初始连接数：20 最大连接数：50 Weblogic 数据库连接池 积压数 登录超时时间 步长：5 默认：1 300 默认：15 5000mS 默认：1 JDK内存设置 最小内存：2048M 采用默认值 登录超时时间 最大内存：2048M 采用默认值 JDK内存设置 最小内存：2048M
24、 默认为256M~512M 最大内存：2048M 采用默认的连接数，如果业务量突然加大则会造成大量的用户等待，同时JDK采用默认的内存设置不利于充分的利用资源。 5.2. JDK优化 优化理由和依据: 采用sun的JDK没有采用经过优化的jrocket，不利于从硬件上优化硬件资源 优化方法： 在JDK1.4以后，BEA JROCKIT在CLASSLOAD速度进行了明显的优化，其中同一方法在第一次编译后，就驻留在内存里，而IBM JDK同一方法编译后，只有当调用的时候才进入到内存中，JROCKIT大大的加快了编译的速度，在其他方面JROCKIT的反应性能也超过了传统的IB
25、M JDK在对于营销这样的生产负荷繁重的系统，使用JROCKIT JDK可以大大降低程序在中间件层运行的速度。 5.3. 堆栈优化 优化理由和依据： 在生产过程中尤其是业务高峰期，中间件服务器经常报内存溢出错误。如下 优化方法： JVM的栈堆优化，建议将现有的数值1610612736扩大1.5倍，这样可以增加程序的吞吐量，避免内存溢出等错误的发生。 5.4. 负载均衡优化 优化理由和依据： 1.连接数过小 2.JVM参数不一致 3.每个集群内存数不一样，造成相同的配置配置不同的机器或者不同的配置配置相同的机器，导致程序分发不平均，负载不均衡。 4.整个
26、中间件系统由8台admin server和8台managed sever组成，每台物理机器上都存在一个主管和一个受管服务器。未配置集群管理，无法进行负载均衡。性能，安全都不能得到最好的效果。 优化方案: 1.使用相应的机器配置。 2.配置相同的内存大小。 6. 系统及数据库优化 6.1. 数据库参数优化 6.1.1. db_keep_cache_size调整 对于数据库服务器来讲，CPU、内存资源是我们需要重点关注并进行有效控制的资源，黑龙江公司数据库服务器目前CPU负载不大，但内存消耗也不是很大。但通过将频繁访问的表和索引放入KEEP池，可以确保这些对象不会被交换出缓冲池
27、从而减少了物理读，提升了性能，所以建议：对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的这
28、一机制，是优化工作的一个重要内容。当然，内存是有限的，不能把所有的表和索引都放入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.ob
29、ject_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
30、 <= 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
31、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 k
32、eep); 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的系统资源，所以必须对无用索引进行清理。 黑龙江电力公司营销系统已经上线多年系统，通过对营销系统索引状况进行分析，发现由于大量的不使用的索引，这些索引占有大量存储空间，增加索引维护成本，将会降低
33、数据库性能，所以需要清理。 通过对营销系统数据库索引监控，黑龙江电力公司营销系统索引共有3147条，索引数据量共1045688.56MB，占数据总量的61.41%，共有754条索引未使用，未使用索引数据量共223199.63 MB，占索引总量的21.34%，占数据库总量的11.61%，预计清除无用索引可以节约220G的空间，并且能很大程度提高数据库性能。 优化方案： 索引具体清理过程详见《黑龙江公司营销系统索引清理方案》。 6.2.3. 索引层次过高 优化理由： 索引层次过高导致通过索引进行检索的时候会产生大量的IO，严重影响系统性能。索引层次过高可能是由于所以出现倾斜。
34、 一般处理方法：找到索引超过4层的索引，进行重建。对于数据量巨大的表考虑对索引进行分区处理。 select * from dba_indexes where blevel>=4; 通过对营销系统分析，未发现索引层次过高的表。 6.2.4. 索引碎片清理 优化理由：营销系统已经上线多年，大量的数据更新和删除操作均会给索引带来碎片问题，导致索引过大，碎片较多，通过在线重建索引可以提高索引访问效率，减少系统开销。 优化方案： 下表列出了部分索引碎片的例子，详细的索引碎片优化方案请参考《黑龙江公司营销系统索引碎片整理方案》。 索引名 索引大小（MB） 释放空间（MB） I
35、ND_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_
36、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 399
37、4 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. 表碎片清理 优化理由： 由于部分表的数据经常进行插入删除，并且长期未进行整理，因此存在较为严重的
38、碎片问题。从而导致了少量的数据占用了大量的数据库空间。通过表碎片整理可以提高系统的总体性能。 对于表碎片整理有两种方法： 1. 表整理的方法是在线alter table <表名> move，不建议move时进行索引重建，要在move后可以并行进行索引重建。 2. 在有条件的情况下可以停应用后进行整理，采用RENAME后重建表的方式，这种方式风险最小。 基于现场环境限制，我采用第一种方法进行表碎片清理。通过分析表的统计信息找到碎片率最高的表，然后进行move操作，来消除碎片。 优化方案： 以下列出分析得到碎片率靠前的表，详细信息请参考《黑龙江公司营销系统表碎片整理方案》。
39、 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
40、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 13
41、562 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 =
42、'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_LACK
43、PKGCOM_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_I
44、NSERT_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 E
45、PM_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
46、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 OBJ
47、ECT_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
48、 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
49、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_
50、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
©2010-2026 宁波自信网络信息技术有限公司 版权所有
客服电话：0574-28810668 投诉电话：18658249818
浙ICP备2021020529号-1 | 浙B2-20240490
关注我们 ：
