提高BOSS系统报表统计速度QC发表.ppt

提高BOSS系统报表统计速度 中国移动贵州公司业务支撑系统部系统优化QC小组2012年6月 2 亲爱滴报表啊 求求你再快一点吧 OMG 这个统计速度 实在受不了啦 有木有 有木有 额滴个神啊 报表你敢不敢再快一点 3 4 业务支撑系统部系统优化QC小组 成立于2007年3月 现场型小组 GearedE L Geared 87 PA15 CO90 IRIS1 Gearless 93 姓名 文化程度 组内职务 硕士 硕士 硕士 硕士 副组长 徐力 杨胜利 刘娟 龚珂 职称职务 部门副总经理 高级工程师 室经理 高级工程师 高级工程师 集团专家 工程师 集团专家 组长 组员 组员 硕士 硕士 马嘉 宋睿 工程师 工程师 组员 组员 由部门管理人员 行业专家和一线员工组成 5 活动时间 2011年2月 2011年7月 6 报表统计速度 报表统计总耗时 报表统计总次数 7 2010年11月至2011年1月BOSS系统报表统计速度情况 平均速度43秒 呈线性上升趋势 月底月初是高峰 8 按照报表类型进行分类 9 按照总耗时对报表类型进行排列 10 统计速度从平均43秒下降到25秒 11 8022 报表是营业员营业厅收费日报 小组成员对报表的业务逻辑和流程有充分的了解 另外 小组成员是行业专家 有丰富的系统优化技能和经验 从以往的优化经验来看 对系统的优化率可以达到50 以上 经过现状调查 8022 报表的平均统计速度为61秒 小组成员认为有较大优化空间 如果将 8022 报表的统计速度提高一倍 则BOSS系统报表统计速度为 43 1 85 58 50 24 6秒因此 小组成员认为目标值经过努力是可以实现的 从统计历史来看 月中时期曾达到并超过目标值 但考虑到月底月初由于业务量大 统计速度会相对较慢 因此不宜将目标值定得过低 12 8022 报表统计慢原因分析树图 8022 报表统计慢 SQL语句不优化 执行计划不优化 语句逻辑结构不优化 表统计信息不准确 未使用索引 系统能力不足 终端能力不足 数据库能力不足 存储IO能力不足 主机能力不足 排序能力不足 数据库性能差 主机内存不足 主机CPU能力不足 营业员操作不当 统计时间输入范围大 重复点击造成程序挂死 月底月初业务量大 13 共有12条末端因素 剔除 月底月初业务量大 因素 14 15 16 17 18 19 要因一对策 在前台统计时间输入窗口对最大统计时间范围进行限制 3月11日 通过业务支撑管理QQ群 对各个地州的业务人员进行了调查 了解到 8022 报表 普遍的统计需求是按日统计 在月底及月初会进行全月统计 基本上统计时间范围不会跨月 3月14日 整理并提交程序修改申请 将前台统计输入窗口最大统计时间范围限制为1个月 并且不允许跨月 3月25日 程序修改通过测试 3月31日 做了限制的统计前台程序上线 实施结果 限制了统计最大时间范围 避免了营业员因输入的统计时间跨度较大 造成统计时间较长 20 要因二对策 优化SQL语句 精简视图中子查询的业务逻辑 3月11日 分析 8022 报表的SQL语句涉及的视图 其中的子查询语句逻辑不够精简 经过测试 将视图进行修改 加上一个where条件 分组的查询范围可大大减少 性能可以有较大提高 fromzg acc stat daily 201103a selectstat idstat id sum decode book item id 10000023 paid prepay 0 aspaid prepay n2 sum decode book item id 80651 paid prepay 0 aspaid prepay n3fromZG ACC STAT DAILY BOOK 201103wherebook item idin 10000023 80651 groupbystat id b3月13日 提交数据结构变更申请 3月22日 在生产数据库修改视图定义代码 实施结果 8022 报表平均统计速度从61秒下降到18秒 3月23日起 8022 报表统计速度大幅下降 21 要因三对策 制定数据库分析策略并实施 3月10日 制定报表数据库分析策略如下 报表数据库采用 自动分析 月表手工分析 的策略 报表数据库打开了自动分析功能 设置的自动分析时间窗口为每日22点至6点 选取变化量超过10 的表进行关联分析 根据报表数据库的业务特性 在月底及月初要做以下特殊操作 以保证每月1日报表系统的正常运行 3月31日 打开数据库自动分析功能 3月31日 按照数据库分析策略进行操作 保证数据库对象分析数据相对准确 实施结果 数据库对象统计信息数据准确 保证了数据库各个SQL语句执行计划相对较优 22 要因四对策 对报表数据库主机CPU消耗最高的进程进行优化 3月14日 对报表数据库主机CPU消耗最高的进程进行了统计 发现其全部为ORACLE数据库进程 无其他应用进程 3月15日 提取了数据库使用CPU最多的前三条语句进行分析 这三条语句占到整个数据库CPU消耗的42 selectSO NBR REPORT NO REPORT TYPE REPORT FIELD VALUE FIELD SEQfromSTAT STAT QUERY ADDCOND RECwhereSO NBR owc0ANDREPORT NO owc1ANDREPORT TYPE 2ORDERBYFIELD SEQ此语句是用来提取 默认上次统计条件 的 STAT STAT QUERY ADDCOND REC这个表上没有索引 经分析 在SO NBR字段创建索引 性能将大大提升 SelectSO NBR REPORT NO OP ID REGION CODE START TIME END TIME CREATE TIME REMARKSfromSTAT STAT QUERY COND RECwhereOP ID owc0andREPORT NO owc1andCREATE TIMEIN SELECTMAX CREATE TIME FROMSTAT STAT QUERY COND RECWHEREOP ID owc2andREPORT NO owc3 此语句也是用来提取 默认上次统计条件 的 STAT STAT QUERY COND REC这个表上没有索引 经分析 在SO NBR OP ID字段创建索引 性能将大大提升 select PARALLEL a 8 a op id sum a recv cash fromstat acc busi rec 201103awherea busi typein 4735 4736 anda pay date to date 20110301000000 yyyymmddhh24miss anda pay date to date 20110315235959 yyyymmddhh24miss anda so org idin 56080132 56006915 and1 1groupbya op id此语句是 8023 自助终端缴费简表 经分析 该语句过度的使用了并行提示 造成了大量CPU资源浪费 经过测试 如果去掉并行提示 执行时间从31秒下降到5秒 3月16日 提交数据结构变更申请 3月31日 在生产数据库表建立索引 及修改语句 23 要因四对策 对报表数据库主机CPU消耗最高的进程进行优化 实施结果 1 整个数据库的CPU使用量大幅下降 100 满负荷状态消失 日均CPU使用量下降为10 瞬间最大峰值64 2 通过要因三和要因四的对策实施 8022 报表也因此速度得到继续提升 从18秒下降到6秒 4月1日起主机CPU使用率大幅下降 4月1日起 8022 报表速度继续提升 24 对策实施后 全月业务峰值4月1日报表统计速度平均为17秒 达到并低于目标值 25 由于降低主机CPU使用率 数据库分析策略等全局优化措施实施后产生了良好的效果 其他报表也不同程度受惠 速度得到提升 四种报表统计量占总统计量98 33 26 在巩固期 BOSS系统报表平均统计速度为8秒 月底月初业务峰值最慢速度为21秒 均低于目标值 优化前 对策实施中 优化后 巩固期 27 按照我部门原规划 为解决报表系统主机满负荷运行的问题 原计划在BOSS系统紧急扩容工程中对报表系统主机扩容16个CPU 折合人民币160万元 小组通过努力 在未增加一分钱硬件投资的情况下 使用优化手段 提高了BOSS系统报表统计的速度 降低了主机CPU资源消耗 从而为公司节省主机CPU硬件扩容投资160万元人民币 28 小组通过提高BOSS系统报表统计速度 提高了一线营业人员的劳动生产率 提高了内部客户的满意度 在5月开展的BOSS系统满意度调查中 全省共有3455人次根据使用感知参与了对报表优化效果进行的投票 其中83 的使用者认为速度提高了 对他们的工作产生正面的帮助 29 小组对活动采取的措施进行了标准化工作 将 8022 报表统计最大范围不超过一个月 并且不能跨月 固化到BOSS系统前台报表统计程序代码中 将优化后的视图stat stat mod 8002 ss YYYYMM定义固化到 BOSS系统数据字典 将 报表数据库分析策略 固化到 中国移