营销业务系统系统级优化方案Word文件下载.docx
《营销业务系统系统级优化方案Word文件下载.docx》由会员分享，可在线阅读，更多相关《营销业务系统系统级优化方案Word文件下载.docx（25页珍藏版）》请在冰点文库上搜索。
第一阶段为优化小组在哈尔滨市对国网黑龙江电力公司营销业务系统进行现场调研和性能分析，形成性能分析报告，并提出初步优化建议。
第二阶段，优化小组和开发厂家在国网公司相关部门的领导下，在哈尔滨市成立联合测试小组，对主要问题的优化方案进行验证。
第三阶段，优化小组在哈尔滨市实施现场优化实施工作，并在实施完成后进行性能评估。
第四阶段，开发厂商完成应用优化的代码调整工作，发布新的版本；
与开发厂商协商，该部分工作在2013年12月完成。
2.项目定义
2.1.系统架构图
黑龙江省营销业务系统采用B/S架构，由用户登录浏览器进行操作，连接到中间件服务器，中间件服务器连接数据库底层，中间件服务器使用8台AIX服务器搭建的weblogic服务器，数据库为2台HP-unix服务器搭建的10gRAC数据库。
整体架构如以下图：
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小时处于繁忙状态，大量的等待进程。
中间件服务器配置不相同，没有配置集群管理，分发不平均，负载不均衡。
进度状况:
针对营销系统，采购IBMp750双机已经纳入今年的采购计划，明年采购完成会更换操作系统，解决系统瓶颈
4.数据库缺陷消除
4.1.死锁现象
优化理由：
通过对数据库日志分析，发现数据库日志出现大量的GESDeadlock死锁，如下所示：
MonOct2916:
30:
39GMT+08:
122013GlobalEnqueueServicesDeadlockdetected.Moreinfoinfile
/oracle/admin/pmdb/bdump/pmdb1_lmd1_5789710.trc.
优化依据：
通过对日志的分析，截取了近期的死锁类型为TX的5类排他锁。
最近一次：
GlobalWait-For-Graph（WFG）atddTS[0.5de]:
BLOCKED700001389ac88c05wq2cvtopsx1[0x1c001a][0x2e3197],[TX][1021-021C-000000B6]0
BLOCKER700001389ac87705wq1cvtopsx28[0x1c001a][0x2e3197],[TX][101F-01FD-0000026D]0
BLOCKED70000138fb0d4705wq2cvtopsx1[0x14001a][0x151d3c8],[TX][101F-01FD-0000026D]0
BLOCKER70000138a98e4f05wq2cvtopsx1[0x14001a][0x151d3c8],[TX][2029-0295-00000AC1]1
BLOCKED70000138a98e4f05wq2cvtopsx1[0x14001a][0x151d3c8],[TX][2029-0295-00000AC1]1
BLOCKER70000138a98e3a05wq1cvtopsx28[0x14001a][0x151d3c8],[TX][2029-0297-000019E5]1
BLOCKED70000138ef031285wq2cvtopsx1[0x1c001a][0x2e3197],[TX][2029-0297-000019E5]1
BLOCKER700001389ac88c05wq2cvtopsx1[0x1c001a][0x2e3197],[TX][1021-021C-000000B6]0
触发死锁的SQL语句有：
sid3065:
70000138db4c318UPDATEWF_ASSIGNMENTSETREAD_MARK=:
1WHEREACTIVITY_ID=:
2ANDPROCESS_ID=:
3ANDUSER_ID=:
4
sid:
2423:
70000138be9ce18UPDATEWF_ASSIGNMENTSETREAD_MARK=:
2290:
70000138aaa76c8UPDATEWF_ASSIGNMENTSETREAD_MARK=:
2874:
700001389ac88c0UPDATEWF_ASSIGNMENTSETREAD_MARK=:
3114:
700001389ac8770UPDATEWF_ASSIGNMENTSETREAD_MARK=:
70000138abc4038updatewf_assignmentsetRESOURCE_TYPE='
HUMAN'
STATUS_ID='
TASK_DELEGATED'
READ_MARK='
0'
whereactivity_id='
2013027760755211'
andUSER_ID!
='
29011918'
andRESOURCE_TYPE!
ROLE'
2377:
7000013881e6d68UPDATEWF_ASSIGNMENTSETREAD_MARK=:
优化方法：
建议开发商对该业务逻辑进行调整，避免死锁的发生。
4.2.ORA-7445现象
营销系统数据库每天都会在日志中生成以下报错：
ORA-07445:
出现异常错误:
核心转储[kksxsccmp+0428][SIGSEGV][Addressnotmappedtoobject][0xE86300987C7B03DA][][]
MonJul2916:
04:
56GMT+08:
002013Tracedumpingisperformingid=[cdmp_20130729160456]
从数据库层面来看，目前该报错对业务系统没有造成影响。
根据我们以往的类似的日志判断该报错一般由无效的数据库对象（如包，过程）在应用程序中被调用所造成。
从目前生成的trace来看，只发现了一些递归的系统SQL以及该问题是由weblogic创建的session所触发，没有看到其他有价值的信息。
我们将持续对问题的跟踪，并建议业务系统开发商对现有的无效对象进行编译和清理。
5.中间件优化
5.1.中间件基本配置
机器配置:
序号
硬件型号
安装软件
IP
用途说明
1
AIX5
AIX5.3，8CPU
，8G内存
，Weblogic9.2.2
，SUN-1.5.0_06
Weblogic应用服务器
2
3
5
6
7
8
Weblogic优化设置：
服务器类型
系统软件
参数类型
参数值
备注
数据库服务器
Oracle
最大连接数
500
默认值150
应用服务器
Weblogic
数据库连接池
初始连接数：
20
最大连接数：
50
积压数
登录超时时间
步长：
默认：
300
15
5000mS
JDK内存设置
最小内存：
2048M
采用默认值
最大内存：
默认为256M~512M
采用默认的连接数，如果业务量突然加大则会造成大量的用户等待，同时JDK采用默认的内存设置不利于充分的利用资源。
5.2.JDK优化
优化理由和依据:
采用sun的JDK没有采用经过优化的jrocket，不利于从硬件上优化硬件资源
在JDK1.4以后，BEAJROCKIT在CLASSLOAD速度进行了明显的优化，其中同一方法在第一次编译后，就驻留在内存里，而IBMJDK同一方法编译后，只有当调用的时候才进入到内存中，JROCKIT大大的加快了编译的速度，在其他方面JROCKIT的反应性能也超过了传统的IBMJDK在对于营销这样的生产负荷繁重的系统，使用JROCKITJDK可以大大降低程序在中间件层运行的速度。
5.3.堆栈优化
优化理由和依据：
在生产过程中尤其是业务高峰期，中间件服务器经常报内存溢出错误。
如下
JVM的栈堆优化，建议将现有的数值1610612736扩大1.5倍，这样可以增加程序的吞吐量，避免内存溢出等错误的发生。
5.4.负载均衡优化
1.连接数过小
2.JVM参数不一致
3.每个集群内存数不一样，造成相同的配置配置不同的机器或者不同的配置配置相同的机器，导致程序分发不平均，负载不均衡。
4.整个中间件系统由8台adminserver和8台managedsever组成，每台物理机器上都存在一个主管和一个受管服务器。
未配置集群管理，无法进行负载均衡。
性能，安全都不能得到最好的效果。
优化方案:
1.使用相应的机器配置。
2.配置相同的内存大小。
6.系统及数据库优化
6.1.数据库参数优化
6.1.1.db_keep_cache_size调整
对于数据库服务器来讲，CPU、内存资源是我们需要重点关注并进行有效控制的资源，黑龙江公司数据库服务器目前CPU负载不大，但内存消耗也不是很大。
但通过将频繁访问的表和索引放入KEEP池，可以确保这些对象不会被交换出缓冲池，从而减少了物理读，提升了性能，所以建议：
对db_keep_cache_size参数进行适当调整。
优化前db_keep_cache_size1504M，而SGA64G，为了可以keep更多的表和索引结合BufferPoolAdvisory，建议将db_keep_cache_size增加到5G。
6.2.数据库对象优化
6.2.1.KEEP池调整
ORACLE对SGA中的DBBuffer做了细分，分为普通池、KEEP池和回收池。
将频繁访问的表和索引放入KEEP池，可以确保这些对象不会被交换出缓冲池，从而减少了物理读，提升了性能。
因此，充分利用ORACLE的这一机制，是优化工作的一个重要内容。
当然，内存是有限的，不能把所有的表和索引都放入KEEP池中，因此我们需要精心挑选候选对象，主要是从热点表和索引着手，综合考虑对象的大小，把尽量多的中小型表和索引纳入其中。
优化方案：
通过分析表的统计信息找访问频繁表和索引
Selectdecode（pd.bp_id,1,'
KEEP'
2,'
RECYCLE'
3,'
DEFAULT'
4,
'
2KSUBCACHE'
5,'
4KSUBCACHE'
6,'
8KSUBCACHE'
7,
16KSUBCACHE'
8,'
32KSUBCACHE'
'
UNKNOWN'
）subcache,
bh.object_nameobject_name,bh.blocks,tch
fromx$kcbwdsds,x$kcbwbpdpd,
（selectset_ds,
o.nameobject_name,count（*）BLOCKS,sum（tch）tch
fromsys.obj$o,sys.x$bhx
whereo.dataobj#=x.obj
andx.state!
=0ando.owner#!
=0
groupbyset_ds,o.name）bh
whereds.set_id>
=pd.bp_lo_sid
andds.set_id<
=pd.bp_hi_sid
andpd.bp_size!
=0
andds.addr=bh.set_ds
ANDTCH>
2000
orderbysubcache,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
操作方法：
AlterindexEPM_HLJ.K_S_BATCH__S_APP_S_B_S_APPstorage（buffer_poolkeep）;
AltertableEPM_HLJ.S_APPstorage（buffer_poolkeep）;
AltertableEPM_HLJ.S_PS_CHG_SCHEMEstorage（buffer_poolkeep）;
AltertableEPM_HLJ.E_RS_PQstorage（buffer_poolkeep）;
AltertableEPM_HLJ.R_PLANstorage（buffer_poolkeep）;
详细信息参见
6.2.2.无用索引清理
创建合适的索引，对提升数据库性能非常重要。
但无用的索引不但占有大量的存储空间，而且还占有CPU、IO的系统资源，所以必须对无用索引进行清理。
黑龙江电力公司营销系统已经上线多年系统，通过对营销系统索引状况进行分析，发现由于大量的不使用的索引，这些索引占有大量存储空间，增加索引维护成本，将会降低数据库性能，所以需要清理。
通过对营销系统数据库索引监控，黑龙江电力公司营销系统索引共有3147条，索引数据量共1045688.56MB，占数据总量的61.41%，共有754条索引未使用，未使用索引数据量共223199.63MB，占索引总量的21.34%，占数据库总量的11.61%，预计清除无用索引可以节约220G的空间，并且能很大程度提高数据库性能。
索引具体清理过程详见《黑龙江公司营销系统索引清理方案》。
6.2.3.索引层次过高
索引层次过高导致通过索引进行检索的时候会产生大量的IO，严重影响系统性能。
索引层次过高可能是由于所以出现倾斜。
一般处理方法：
找到索引超过4层的索引，进行重建。
对于数据量巨大的表考虑对索引进行分区处理。
select*fromdba_indexeswhereblevel>
=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.表碎片清理
由于部分表的数据经常进行插入删除，并且长期未进行整理，因此存在较为严重的碎片问题。
从而导致了少量的数据占用了大量
升级会员 