最新等比数列前n项和求和公式课件PPT.ppt 54页

'进入夏天，少不了一个热字当头，电扇空调陆续登场，每逢此时，总会想起那一把蒲扇。蒲扇，是记忆中的农村，夏季经常用的一件物品。　　记忆中的故乡，每逢进入夏天，集市上最常见的便是蒲扇、凉席，不论男女老少，个个手持一把，忽闪忽闪个不停，嘴里叨叨着“怎么这么热”，于是三五成群，聚在大树下，或站着，或随即坐在石头上，手持那把扇子，边唠嗑边乘凉。孩子们却在周围跑跑跳跳，热得满头大汗，不时听到“强子，别跑了，快来我给你扇扇”。孩子们才不听这一套，跑个没完，直到累气喘吁吁，这才一跑一踮地围过了，这时母亲总是，好似生气的样子，边扇边训，“你看热的，跑什么？”此时这把蒲扇，是那么凉快，那么的温馨幸福，有母亲的味道！　　蒲扇是中国传统工艺品，在我国已有三千年多年的历史。取材于棕榈树，制作简单，方便携带，且蒲扇的表面光滑，因而，古人常会在上面作画。古有棕扇、葵扇、蒲扇、蕉扇诸名，实即今日的蒲扇，江浙称之为芭蕉扇。六七十年代，人们最常用的就是这种，似圆非圆，轻巧又便宜的蒲扇。　　蒲扇流传至今，我的记忆中，它跨越了半个世纪，也走过了我们的半个人生的轨迹，携带着特有的念想，一年年，一天天，流向长长的时间隧道，袅等比数列前n项和求和公式 故事：传说在古代印度，国王要奖赏国际象棋的发明者,发明者说：“请在棋盘的第1个格子里放上1颗麦粒，在第2个格子里放上2颗麦粒，在第3个格子里放上4颗麦粒，在第4个格子里放上8颗麦粒，依此类推，每个格子里放的麦粒数都是前一个格子里放的麦粒数的2倍，直到第64个格子。请给我足够的粮食来实现上述要求”。国王觉得并不难，就欣然同意了他的要求。你认为国王有能力满足发明者的要求吗？棋盘与麦粒 II、新课讲解：分析：由于每个格子里的麦粒数都是前一个格子里的麦粒数的2倍，且共有64个格子，各个格子里的麦粒数依次是那么，我们怎样求这个值呢？于是发明者要求的麦粒总数就是 V、课时小结：本节课应重点掌握的内容是等比数列的求和公式以及它的推导方法：课后应进一步熟练此公式，并掌握它的基本应用。错项相减法 谢谢观看！ 应用产品性能调整实例分析张春辉资深技术工程师 内容应用产品性能调整概要介绍性能调整常用方法应用产品性能调整实例分析 应用产品性能调整概要介绍问题的定义分清三种类型的应用问题四个领域(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！'