最新《There-is-a-cat-in-the-tree》PPT课件课件PPT.ppt 60页

'《There-is-a-cat-in-the-tree》PPT课件 birdhorsesnakeelephantpandatigermonkeyThereisasnake.Howmanyanimalscanyousee?giraffe Thereisanelephantunderthetree.Therearetwotigersinthetree. Thereisacatinthetree.Let’shelpthecat. Thereisachairoverthere.smallbigThetreeisverytall. Thereisatableoverthere.Weareveryshort. Thereisapolicemanoverthere. Thereisaduckunderthetree. Thereisa_______thetree. Thereisa_______thechair. 1、不要做刺猬，能不与人结仇就不与人结仇，谁也不跟谁一辈子，有些事情没必要记在心上。2、相遇总是猝不及防，而离别多是蓄谋已久，总有一些人会慢慢淡出你的生活，你要学会接受而不是怀念。3、其实每个人都很清楚自己想要什么，但并不是谁都有勇气表达出来。渐渐才知道，心口如一，是一种何等的强大!4、有些路看起来很近，可是走下去却很远的，缺少耐心的人永远走不到头。人生，一半是现实，一半是梦想。5、没什么好抱怨的，今天的每一步，都是在为之前的每一次选择买单。每做一件事，都要想一想，日后打脸的时候疼不疼。6、过去的事情就让它过去，一定要放下。学会狠心，学会独立，学会微笑，学会丢弃不值得的感情。7、成功不是让周围的人都羡慕你，称赞你，而是让周围的人都需要你，离不开你。8、生活本来很不易，不必事事渴求别人的理解和认同，静静的过自己的生活。心若不动，风又奈何。你若不伤，岁月无恙。9、与其等着别人来爱你，不如自己努力爱自己，对自己好点，因为一辈子不长，对身边的人好点，因为下辈子不一定能够遇见。10、你迷茫的原因往往只有一个，那就是在本该拼命去努力的年纪，想得太多，做得太少。11、有一些人的出现，就是来给我们开眼的。所以，你一定要禁得起假话，受得住敷衍，忍得住欺骗，忘得了承诺，放得下一切。12、不要像个落难者，告诉别人你的不幸。逢人只说三分话，不可全抛一片心。13、人生的路，靠的是自己一步步去走，真正能保护你的，是你自己的选择。而真正能伤害你的，也是一样，自己的选择。14、不要那么敏感，也不要那么心软，太敏感和太心软的人，肯定过得不快乐，别人随便的一句话，你都要胡思乱想一整天。15、不要轻易去依赖一个人，它会成为你的习惯，当分别来临，你失去的不是某个人，而是你精神的支柱;无论何时何地，都要学会独立行走，它会让你走得更坦然些。16、在不违背原则的情况下，对别人要宽容，能帮就帮，千万不要把人逼绝了，给人留条后路，懂得从内心欣赏别人，虽然这很多时候很难。17、做不了决定的时候，让时间帮你决定。如果还是无法决定，做了再说。宁愿犯错，不留遗憾!18、不要太高估自己在集体中的力量，因为当你选择离开时，就会发现即使没有你，太阳照常升起。19、时间不仅让你看透别人，也让你认清自己。很多时候，就是在跌跌拌拌中，我们学会了生活。20、命运要你成长的时候，总会安排一些让你不顺心的人或事刺激你。21、你的假装努力，欺骗的只有你自己，永远不要用战术上的勤奋，来掩饰战略上的懒惰。22、成长是一场和自己的比赛，不要担心别人会做得比你好，你只需要每天都做得比前一天好就可以了。23、你没那么多观众，别那么累。做一个简单的人，踏实而务实。不沉溺幻想，更不庸人自扰。24、奋斗的路上，时间总是过得很快，目前的困难和麻烦是很多，但是只要不忘初心，脚踏实地一步一步的朝着目标前进，最后的结局交给时间来定夺。25、你心里最崇拜谁，不必变成那个人，而是用那个人的精神和方法，去变成你自己。26、运气是努力的附属品。没有经过实力的原始积累，给你运气你也抓不住。上天给予每个人的都一样，但每个人的准备却不一样。不要羡慕那些总能撞大运的人，你必须很努力，才能遇上好运气。27、时间只是过客，自己才是主人，人生的路无需苛求，只要你迈步，路就在你的脚下延伸，只要你扬帆，便会有八面来风，启程了，人的生命才真正开始。28、每个人身上都有惰性和消极情绪，成功的人都是懂得管理自己的情绪和克服自己的惰性，并像太阳一样照亮身边的人，激励身边的人。29、最终你相信什么就能成为什么。因为世界上最可怕的二个词，一个叫执着，一个叫认真，认真的人改变自己，执着的人改变命运。只要在路上，就没有到不了的地方。30、人生，就要活得漂亮，走得铿锵。自己不奋斗，终归是摆设。无论你是谁，宁可做拼搏的失败者，也不要做安于现状的平凡人。31、不管做什么都不要急于回报，因为播种和收获不在同一个季节，中间隔着的一段时间，我们叫它为坚持。32、过自己喜欢的生活，成为自己喜欢的样子，其实很简单，就是把无数个“今天”过好，这就意味着不辜负不蹉跎时光，以饱满的热情迎接每一件事，让生命的每一天都有滋有味。 应用产品性能调整实例分析张春辉资深技术工程师 内容应用产品性能调整概要介绍性能调整常用方法应用产品性能调整实例分析 应用产品性能调整概要介绍问题的定义分清三种类型的应用问题四个领域(AREAS)的调整定期调整性能调整阶段 问题的定义精确地定义是解决问题的关键“WHAT”:问题的特性是什么?其相关的组件是什么?“WHERE”:问题在什么地方发生?“WHEN”:问题在什么时候发生?“EXTENT”:问题影响的用户或地点是什么?多少功能受影响?问题是否孤立?“PRIORITY”:问题的相关重要性有多高?性能目标设立基于用户需求的性能目标基于实际环境所能达到的性能性能问题的相关性不同模块/组件之间存在相互影响的关系,找到产生问题的主要原因 分清三种类型的应用问题在线事务处理后台批量数据处理应用报表 四个领域(AREAS)的调整调整数据库调整服务器调整SQL(执行计划)调整/监控网络 调整数据库收集应用数据库运行的统计数据(utlB/Estat,　V$patameter),调整数据库初始化参数分析数据库对象(AnalyzeTheDatabase)利用PackagePinning策略提高缓存命中率(HitRatio)减少资源竞争(ResourceContention)数据块的大小(DBBlockSize) 调整服务器磁盘I/O内存Paging和SwappingCPU进程 调整SQL(执行计划)发现耗时/资源的SQL(ExpensiveSQL)跟踪(Tracing)CBO统计/索引/视图/嵌套/表连接High-WaterMark 监控网络网络流量监控工具pingARPnetstat等客户端PC 定期调整用户数增加数据量增加上线模块增加第三方软件的加入客户化报表/程序增加使用时间 性能调整阶段“Why”–找到性能问题瓶颈，检查问题真正的原因“How”–分析原因，找到解决问题的办法 内容应用产品性能调整概要介绍性能调整常用方法应用产品性能调整实例分析 性能调整常用方法用OS工具来发现问题,找到最费时的OS进程,并关联到相应的ORACLESessionVmstatIostatPsTop(nmon/topas)sar检查是否有“死”(defunct)进程和运行时间异常长并消耗大量系统资源的进程通过运行Utlbstat/utlestat报告来调整数据库用OEM工具找出性能瓶颈确定费时的SQL语句，具体有下列几种办法： 性能调整常用方法(Cont.)trace(生成SQL的执行计划)：altersystemsettimed_statistics=true;initSID.ora:sql_trace=true;dbms_system.set_sql_trace_in_session(&sid,&serial,true);ProfileOption:(AR:EnableSQLtrace,INV:DebugTrace,MRP:TraceMode,OE:DebugTrace,PO:EnableSqlTrace)定义并发程序“Checktraceon”OEMtopsession＄FND_TOP/adminSQLscriptsV$sqlarea,V$sqltext 性能调整常用方法(Cont.)selectsid,serial#fromv$sessionwherepaddr=(selectaddrfromv$processwherespid=&ospid);selectspidfromv$processwhereaddr=(selectpaddrfromv$sessionwheresid=&orasid);selectrequest_id,oracle_process_idfromapps.fnd_concurrent_requestswhererequest_id=&request_id;selectsid,s.serial#,s.username,s.status,pid,spid,s.programfromv$sessions,v$processpwheres.paddr=p.addrandspid=&spid; 性能调整常用方法(Cont.)定期进行CBO统计，具体有下列几种办法：Analyzetable/indexcomputestatistics;execfnd_stats.gather_schema_statistics("＆Appl_shortname")运行并发：“GatherSchema/Table/Columnstatistics”运行并发：“AnalyzeAllIndexColumnStatistics“定期“Purge”过时的工作流数据和并发请求 性能调整常用方法(Cont.)及时安装上ORACLE建议的，特别是强制性PATCHMetalink是一个非常有用的工具，遇到性能问题建议先在Metalink上查一查，大部分的问题应该都有了解决方案调整SQL语句/视图等LogiTAR来获得技术支持及时联系硬件供应商以获得帮助性能问题的差异性现象一样，可能形成的原因不一样，解决的方法也不一样用户的实际情况不一样，同一原因，其影响程度也不一样 内容应用产品性能调整概要介绍性能调整常用方法应用产品性能调整实例分析 应用产品性能调整实例分析系统反应慢接收事务处理等非常慢ONT升级(R11i)SQL问题应用系统整体反应慢订单录入/预定性能问题PlanningManager运行不完 系统反应慢问题现象：应用系统反应非常慢，就连登录到应用系统就需5分钟，打开一FORM需3分钟问题检查：用vmstat查，有15个“Running”的OS进CPUidle一直为0用nmon/topas查，发现有14个运行的RGRARG进程，大部分运行了十几小时，有些运行了几天，它们占了约95％的CPU资源对这些TOPProcess找不到相应的OracleSession 系统反应慢(cont.)原因分析：取消FSG报表，OS进程还在运行并消耗资源用户较长时间未运行“GatherSchemaStatistics”引起FSG报表性能差解决办法：Kill这些OS进程再对GLSchema运行“GatherSchemaStatistics”和运行“GL优化程序” 系统反应慢(cont.)结果：FSG报表运行正常系统释放了被占用的95％的CPU资源，当然系统反应也恢复了正常问题分析：定期作CBO统计非正常的OS进程会消耗很大的系统资源 接收事务处理等非常慢问题现象：接收事务处理选择子库存一小时无反应，以前一直都很好(选择时间约一秒)应收接口程并发程序非常慢采购汇总报表运行不完问题检查：Vmstat–2CPU空闲一致为0并伴有较大的PageoutRuningQueue平均为20对此PO接收操作生成SQL执行计划:发现对MTL_SYSTEM_ITEMS和MTL_SECONDARY_INVENTORIES进行全表扫描,其中MSI表中有80万条记录 接收事务处理等非常慢(Cont.)修改了索引:MTL_SYSTEM_ITEMS_U1(organization_id,inventory_item_id)检查索引发现对MSI表新建了索引:MTL_SYSTEM_ITEMS_N8(organization_id,item_type,segment1)MTL_SYSTEM_ITEMS_N9(organization_id)采取的办法:altertableinv.mtl_material_itemsdropprimarykey;dropindexinv.mtl_system_items_u1;dropindexinv.mtl_system_items_n8; 接收事务处理等非常慢(Cont.)dropindexinv.mtl_system_items_n9;Createindexinv.mtl_system_items_u1(inventory_item_id,organiziotn_id)结果：系统恢复正常问题分析：不能修改标准索引对标准基表添加索引要特别小心建议只对客户化表建索引，并加上CUX_前缀和有自己独立的表空间(Tablespace) ONT升级SQL问题问题现象：R11i升级过程中ontup204.sql运行了一天无法完成问题检查：通过生成此SQL的执行计划发现:对MTL_DEMAND进行全表扫描(Fulltablescan),此表有1509351条记录检查MTL_DEMAND表上有相应的索引原因分析：R11i采用CBO,Optimizer=choose采取临时办法:修改ontup204.sql,加Hintaltersessionsetoptimizer_goal=rule; ONT升级SQL问题(Cont.)其他类似SQL:ont00031.sqlontupg43.sql问题分析：R11i采用CBO基于成本的优化方法，以前都是基于规则的优化方法(RuleBase)如不作CBO统计可能会引起执行计划的不合理，可能比RuleBase的还差建议定期作CBO统计 应用系统整体反应慢问题现象：应用系统整体性能差，特别是月结期间打开Forms，运行报表，并发程序运行都慢问题检查：Sar,vmstat结果CPU空闲很少OEM生成TOP50并发请求报告基于内存的快照(运行1444分钟)在制品收发存日报表_客户化(平均运行40分钟)钞票生产报表_客户化(平均运行30分钟)工序外废统计报表_客户化(平均运行27分 应用系统整体反应慢(Cont.)用户还反映“查询事务处理汇总”很慢用OEMTOPsession检查：”并发管理”程序本身消耗了较高的系统资源生成utlbstat/utlestat报告："dbfilescatteredread"–等待通过对表进行Fulltablescan发生的I/O"bufferbusywait’–由于undoblockandheader　contention引起的等。‘AverageWriteQueueLength’–为13.9,此统计值过大对TEMP表空间有较大的读写操作，特别是写操作，比一般的表空间要大100多倍 应用系统整体反应慢(Cont.)对上述各问题生成SQL执行计划解决方案：调整数据库init参数：增加db_file_multiblock_read_count为原来的2倍，尽量减少由于客户化程序而引起的Fulltablesacn.增加回滚段的个数,现在为8个,建议增加到12个并优化每个Segment的存储参数增加db_block_buffer值,现150M,建议增加到600M增加sort_area_size值,现为256000,建议增加到1.6M,为减少在TEMP表空间过多的读写，也要观察是那些客户化应用引起的，尽量对这些程序进行调优 应用系统整体反应慢(Cont.)标准应用查询事务处理汇总：删除表：MTL_SUMMARY_TEMP中的记录，此表有3268051，此查询程序有对它进行Fulltablescan并发管理程序：通过OEMTOPSession监控，发现系统并发管理调度程序消耗很大的CPU资源，进一步检查发现它对fnd_conc_pp_actions表进行FullTableScan,检查表：fnd_conc_pp_actions有62255条记录，并且此SQL运行非常频繁：Patch#1585448消除FullTableScan并解决此问题 应用系统整体反应慢(Cont.)标准应用：基于内存的快照：当运行MRP的计划参数设定为”NetWIP”,MRP的”基于内存的快照”将永远也运行不完，并耗用大量的系统资源．通过对此情况进行模拟，发现0837相关组件的任务令存在循环,解决办法是关闭0837相关的任务令再重新运行MRP，计划3分钟正常完成 应用系统整体反应慢(Cont.)客户化应用：在制品收发存日报表_客户化：通过调整数据库初始化参数，使此报表性能提高了3.5倍(现为12分钟)，在此基础上调整视图：cux_wip_xa_tmp的定义,改变”Where”条件的顺序，以减少”RangScan”的范围，这样，使此报表的运行时间缩短到2.5分钟，并且大大减少了系统IO钞票生产报表_客户化(平均运行30分钟)：分析此报表的TOPSQL，对表QA_RESULTS读取9256680条记录，应用程序是通过对QA_RESULTS_V进行读取的，检查发现有相应的Patch#1828261对此视图进行优化，安装此Patch后此TOPSQL的执行只选取91967条记录，报表运行时间缩短到10分钟 应用系统整体反应慢(Cont.)工序外废统计报表_客户化：此报表的TOPSQL，对表MTL_SYSTEM_ITEMS,WIP_MOVE_TRANSACTIONS进行了大量的”RangeScan”,经测试发现此SQL单独运行非常快，仅需3秒．检查此SQL是一报表公式，它处于内循环，对同一求和结果运行了多次．修改此报表，使运行时间由原来27分钟缩短到2分钟． 应用系统整体反应慢(Cont.)结果：系统的整体性能提高了4到5倍‘AverageWriteQueueLength’统计值由13.9降低到0‘dbfilesequentialread’统计值由267991/298562/1.1降低到2911/3895/1.34‘dbfilescatteredread’值由3763/15123/4.02降低到4/9/2.25‘bufferbusywait’统计值由104695/94150/.9降低到0.TEMP表空间的读写正常标准应用的性能问题解决，客户化应用有了十倍不等的提高 应用系统整体反应慢(Cont.)问题分析：应用环境变化后数据库系统需要依据现有情况进行调整用户数模块数数据量客户化管理临时数据对客户化报表应尽量优化，并先在测试环境下进行性能测试数据问题也会引起性能问题(MRP问题）第三方软件的加入 订单录入/预定性能差问题现象：输入销售订单“Nextfield/line”很慢(需要10+秒,1+分钟)预定订单非常慢(在一个用户使用的情况下都需要5+分钟) 订单录入/预定性能差(Cont.)问题检查：Vmstat(13~15runqueue,CPUstuck0idle)通过OEM发现一TOPSession引起了大量的“logicalread”:INSERTINTOQP_PREQ_LINE_ATTRS_TMP….通过nmon发现相应的TOPProcess占用了90%的CPU通过Metalink发现相应Patch#1318663 订单录入/预定性能差(Cont.)进一步检查：Selectcount(*)fromwf_itemswhereend_dateisnotnull;selectcount(*)fromWF_ITEMS_ACTIVITY_STATUSESwhereend_dateisnotnull;Selectcount(*)fromfnd_concurrent_requests;解决方案：安装Patch#1318663清除过时的工作流数据运行‘GatherSchemaStatistics’forthe"ALL"Schema清除过多的并发请求数据 订单录入/预定性能差(Cont.)结果：Vmstat(1~2runqueue,average50%idlelast2hrs)OEMTOPsession正常输入销售订单“Nextfield/line”(只需要１秒,2~3秒)预定订单(只需要3~10秒) 订单录入/预定性能差(Cont.)问题分析：当遇到问题时，建议多上Metalink查询建议定期清除过时的工作流数据建议定期运行‘GatherSchemaStatistics’forthe"ALL"Schema建议定期清除并发请求数据 计划经理运行不完问题现象：“计划经理”运行了2天还没有结束，平时只要十几分钟，另外一并发请求“Load/CopyMDS”也无法正常完成，也无法“Cancel"Shudtdown数据库和重新启动服务器都不能解决此问题问题检查：主要原因是由于在执行一语句时锁表：mrp_sales_order_updates引起的,分析此语句的执行计划都很正常 计划经理运行不完（Cont.)解决方案：取消"PlanningMgr"和"Load/CopyMDS"并发请求通过fnd_concurrent_requestsos_process_id域找到V$session中的SID,SERIAL#，Kill相应的sessions，和操作系统的进程运行"GatherschemaStatistics"对SchemaINV,ONT,MRP进行CBO统计信息收集修改Package:MRP_MANAGER_PK中的UPDATE_BATCH_SIZE，从100改到200000，以增加每次处理的记录数，减少发生死锁的可能性重新启动"PlanningMgr"，提交“Load/CopyMDS”请求 计划经理运行不完（Cont.)结果：“Load/CopyMDS”请求正常完成，“PlanningMgr”也恢复正常问题分析：“死锁”也是性能问题的一种，虽然它不消耗系统资源某些表中的记录数也会影响性能定期作CBO统计是不可少的 Thank　You！'