基于ERP系统的数据库性能优化分析(许培洪)

南阳理工学院本科毕业设计〔论文〕基于ERP系统的数据库性能优化分析MakesdatabaseperformanceoptimazitionanalysisbaseonERPsystem学院〔系〕：计算机科学与技术系专业：计算机科学与技术学生姓名：许培洪学号：64107077指导教师〔职称〕：王秋芬(讲师)评阅教师：完成日期：2021年5月南阳理工学院NanyangInstituteofTechnology基于ERP系统的数据库性能优化分析计算机科学与技术专业许培洪［摘要］随着信息技术的不断开展，中小型企业信息化建设越来越重要，采用先进的企业资源方案〔ERP〕系统已势在必行。ERP是顺应时代要求的信息技术与企业管理新思想相结合的产物。对商业套装软件进行性能优化是比拟困难的,但仍有时机对它进行调优.只要对应用系统有正确的理解,提供时间和相关资源,IT团队就能够改善复杂关键应用的性能。本文在系统分析研究ERP原理的根底上，通过对系统开发与实现过程中所涉及的理论和技术的研究，分析了ERP系统的功能模块结构，对后台oracle数据库做性能优化分析，并做持续跟踪优化。[关键字]ERP;IO，负载均衡，AWR，响应时间，并发MakesdatabaseperformanceoptimazitionanalysisbaseonERPsystemComputerscience&technologymajorXu PeihongAbstract: euseofadvansedERPisontherightway.ERPisthethecombinationofinformationtechnologyandnewenterprisemanagementcompliedwiththedemandofera.Itiscomprasivelydifficulttoperformanceoptimazitionofthecommercialsoftwarepackage,butaslohaschancetomakeitperformbetter.Ifonlywiththecorrectcomprehensionofapplicationsystemandprovidingtimeandrelatedresources,ITgroupscanimprovetheperfomanceofcomplexandkeyapplication.BasedonthesystematicanalysisresearchonthetheoryofERPsystem,thisarticleanalysesthefunctionmodulestructureofERPsystemthroughtheresearchontheoryandtechnologyrelatedtosystemdevelopmentandimplementationprocess.Ttalsomakesperformanceoptimazitionanalysistothebackstageoracledatabaseanddoesthecontinuoustrackingoptimization.Keyword:ERP;IO; AWR;OutboundLoadBalancing;paratera;目录1. ERP系统的现状 12. ORACLE数据库体系结构 2 物理结构 2 逻辑结构 2 块(block) 3 区(extent) 3 段(segment) 4 表空间(tablespace) 43. 主机性能调优 4 内存分配 4 CPU响应时间 5 IO和并发 5 其他磁盘优化 64. 参数调优 65. SQL调优 7 通过HINT来强制执行方案 7 变量绑定 9 使用索引 10 管理组织索引 105.3.2 聚簇的使用 11 使用分析函数 11 利用or代替unionall 126. 总结和建议 14 要有ORACLE优化意识 15 优化有步骤可遵循 15 要做大基准测试 16 防止重复创造轮子 16 力求使用简单方法 16 设计非常重要 177. 结束语 17参考文献 18ERP系统的现状随着信息技术的不断开展，中小型企业信息化建设越来越重要，采用先进的企业资源方案〔ERP〕系统已势在必行。ERP是顺应时代要求的信息技术与企业管理新思想相结合的产物。目前国内外的ERP系统是一类高度集成的软件，其涉及到众多的计算机技术。而ERP系统又不仅仅是一个软件，更重要的是一个管理思想，它实现了企业内部资源和外部资源的整合通过软件把企业的人、财、物、产、供、销及相应的物流、资金流、管理流、增值流紧密地集成起来。ERP系统的开发需要依靠具有一定的开发经验和很好的技术根底的开发公司来完成。企业所处的环境是不断变化的：企业的产品种类、产品所处生命周期的阶段、企业的方案模式、分销模式都不断变化，企业不断地进行业务流程的再造，企业的规模不断地缩小或者扩展，总之企业的变化是绝对的。对于国内的ERP软件供给商来说，即使软件的开发是对国情深入了解的前提下，即使他们的软件系统功能再全、适应性再强，当面对不通企业千差万别的具体情况和不同企业千变万化的特殊需求时，也不可能以以千变应万变。因而，客观行要求ERP系统具备适应各种变化的能力。而另外一方面，随着时间的推移，系统负载的增加，系统性能将下降，企业业务可能受到影响。因此不管企业采用国内还是国外的软件，都面临着系统的二次开发和性能优化问题。对商业套装软件进行性能优化是比拟困难的,但仍有时机对它进行调优.只要对应用系统有正确的理解,提供时间和相关资源,IT团队就能够改善复杂关键应用的性能。以oracleERP为例，ORACLE应用系统充分采用了数据库上的先进技术，将有些系统功能放到数据库中去实现，而不是通过编程的方式，因而大大简化了程序，提高了效率。ORACLE电子商务套件已经脱离了传统的ERP软件模式，提供了集成的商业智能、个性化管理界面、工作流和告警等全新的功能。传统的ERP软件，用户需要进入层层菜单，运行查询或报表，才能得到业务数据。而使用ORACLE，用户可以在个性化的企业门户网页中，自由定义所需的智能报表，就能迅速了解企业、相关业务的执行情况。系统还能够对非正常业务自动告警。ORACLE系统以人为本，帮助企业的管理人员充分利用ERP的业务数据，更高效地管理企业。本文在系统分析研究ORACLEERP原理的根底上，通过对系统开发与实现过程中所涉及的理论和技术的研究，通过对后台ORACLE数据库的架构进行分析研究，提出基于ERP系统的数据库性能优化模型，并做持续跟踪优化。ORACLE数据库体系结构Oracle数据库在存储数据的时候并不是简单地进行数据堆砌，而是由一整套严谨，高效的逻辑结构来管理数据库的存储，因此数据库的存储结构也可以分为两大类，物理结构和逻辑结构。物理存储结构对应一系列的不同格式、类型、作用的文件，用来存储对象及物理数据，逻辑结构那么是oracle内存存储机制。物理结构数据库由一系列物理文件组成，其中包括控制文件，数据文件，日志文件，临时文件等，他们在DBMS中充当不同的角色，共同协调DBMS的正常运行。我们可以建立一个模型。DBMS相当于一个公司，而控制文件是老板，只负责发号施令，数据文件是忠实的员工，只负责执行任务，而临时文件相当于公司的公用资产，谁都可以使用，日志文件了，就相当于公司买的保险了，用的上的时候才能用上。本论文调优涉及到数据文件的，我概要介绍一下数据的存储机制。数据库中每条数据都存储在数据文件中，一个数据库拥有很多数据文件，一个数据文件在物理上对应一个操作系统文件。Oracle在创立数据文件时，是通过操作系统在指定路径下分配一块磁盘空间并将其格式化。操作系统把这块存储区域分配给这个数据文件，并赋予其写磁盘的权限。但是我们存储数据的时候，数据会被随机存储到数据文件中，这是因为数据文件是一个物理的概念，我们不能指定在创立对象的时候指定它到那个数据文件中去，只能指定到哪个表空间。当然我么也可以通过动态视图来查看一个数据文件中拥有哪些对象。selectb.segment_name,A.FILE_NAME,b.BYTES,b.BLOCKS,a.BYTES,a.USER_BYTESfromdba_data_filesa,dba_extentsbwherea.file_id=b.file_idanda.file_name='D:\LMIS\DATAFILE\DATA27.DBF';逻辑结构数据库的物理存储结构对应一系列的物理存储文件，而数据是如何存储的？以什么机构存储到数据文件中的？这要取决于逻辑存储结构。Oracle数据库执行的每次操作都是从逻辑上定义一组结构，操作的数据可以一步步细分为不同的存储单元，oracle操作数据的过程，实际上就是对不同级别的存储单元进行维护和管理的过程，下面让我们来了解一下数据库的存储单元。按照如下从小到大顺序，逻辑存储单元可以做如下划分。块(block)块是oracle存储结构中的最小存储单元，所以数据的存储都是以块为单位进行存取的，块的大小可以通过出初始化参数db_block_size来设置。我们知道所有的读写操作都反映在磁盘IO上，最终的操作单位是字节，如果每次读写都是以字节为单位进行，将会是非常慢的，不同文件的默认块大小也不一样，般都设置成8KB或者是16KB.下列图为数据块的剖面图：数据块头行记录行目录表目录空闲记录图2-1数据块剖面图数据块头行记录行目录表目录空闲记录我们简要介绍行记录和空闲空间，当行记录有写入数据的时候就存储在行记录中，当数据被删除时这局部空间又会转换成空闲空间。空闲空间是当前块的可用空间，当对现有数据进行update和Insert的时候就是从这局部空间分配容量来写入数据，如果执行UPDATE的时候，块中的空间缺乏以存储被修改的数据，那么记录就将被存储到另外一个拥有足够空间的块中，而只在原块中保存一条指向新块的rowid，这种现象就是传说中的行迁移(RowMigration)。[1]区(extent)区是oracle最小的分配单位，有一组连续的块组成，这些块可能物理上并不连续，但是要属于同一个物理文件。单个区在分配时候不能跨文件分配，而我们数据库创立对象的时候至少为为该对象初始化一个分区初始化分配的空间叫走初始区。随着对象大小的不断增加，操作初始区后oracle还再为对象分配扩展区。〔IncrementalExtent〕，扩展区不一定药与初始化分区连续存放。段(segment)一个段又很多分区组成，以前段可以理解为一个对象，但是随着软件版本的演进，存储一个对象可以存储到不同的段中。比方一个对象包含索引，LOB类型，那么该对象会分别存储到表段，索引段，LOB段。如果一个单纯的堆组织表，那么该表只存储到一个段中，不管该表包含多少的数据。表空间(tablespace)一个表空间从逻辑上定义，是有多个段组成的从物理上定义，是由多个数据文件组成的。表空间是oracle逻辑上分配的最大存储单位i，我们平常做的创立对象操作都在表空间一级进行，如创立存储对象的时候只能指定在哪个表空间进，而不能指定存储到更细粒度的存储单元了，更不能指定存储到哪个数据文件中。分析数据库的体系结构是为了更好地建立数据库优化模型下列图为整体优化的模型：图2-2数据库优化模型主机性能调优内存分配我们知道在创立数据库的时候给ORACLE分配一个SGA〔systemglobalarea〕，SGA越大，数据库可用的内存就越大。我们操作系统一般是32位的，最大寻址空间为2的32次方，即4G的内存大小。当我们的操作系统是64位的时候，最大寻址空间变为了2的64次方了。在创立数据库的过程我们一般是手动设置内存分配大小，合理地设置databuffer、sharepool、logbuffer等大小能使系统的性能提升更快。CPU响应时间数据库效劳器响应时间由CPU处理时间和等待时间组成，其中等待时间往往和某种瓶颈有关，如ORACLE数据的写出需等待日志先写出〔lgwr进程〕，如果日志所在磁盘出现异常，那数据写出进程〔dbw进程〕再快也需等待！CPU处理时间中，重点在SQL执行时间，我总结出“访问量〞除以“吞吐量〞的方式，并将访问量细化为“执行次数〞和“单次访问量〞，这样目的在于，优化可从减少访问量入手，也可从降低执行次数着手！数据库响应时间如图二所示：图2-3数据库响应时间模型IO和并发数据库的硬件设计包含了数据库效劳器的架构和数据存储，这些因素在数据库设计阶段将作为重点的考虑因素，我们应该充分考虑到数据库可能到达的最大并发数，对于OLTP系统，并发将是一件非常重要的事.如果没有在设计阶段考虑到，可能会出现以下后果：a.系统资源严重被用，系统过负荷运行。b.严重的等待时间，可能造成系统频繁锁及热块的产生。对应IO问题，可以通过以下的语句来判断：Selectnamephyrds,phywrts,readtim,writetimfromv$filestata,v$datafilebwherea.file#=b..file#orderbyreadtimedesc其他磁盘优化在对ERP系统做优化的过程中还总结了一下提高性能的方法A别离表空间、oracle的安装目录、联机重做日志、经常被访问的数据文件、索引表空间，防止磁盘竞争。B增大日志文件的大小，从而增加处理大型insert,update,delete操作的比例。C增大日志组成员，提倡一个主日志文件加一个多路利用文件。D不要在系统表空间中执行排序。参数调优我们来认识以下数据库的一些重要的初始化参数SGA_MAX_SIZESGA_TARGETPGA_AGGREGATE_TARGETDB_CACHAE_SIZESHORE_POOL_SIZE调整DB_CACHE_SIZE来提高性能这个参数设定了用来存储和处理内存中的数据大小，我们知道从内存中读取数据比磁盘中快1000倍左右，DB_CACHE_SIZE越大能增大数据读取的缓存命中率。设定DB_BLOCK_SIZE来反映数据读取量大小OLTP一般为8K，OLAP一般为16K或者32K。调整SHARE_POOL_SIZE来优化性能此参数越大，说明共享的SQL越多，使得在内存中便能够找到使用过的SQL语句，为了减少硬解析次数，优化对共享SQL区域的使用需尽量使用存储过程、使用绑定变量。调整PGA_AGGREGATE_TARGET以优化对内存的应用OLTP:总内存*80%*20%。OLAP总内存*80%50%。SQL调优通过HINT来强制执行方案HINT是oracle提供的一种sql语法，他允许用户在sql语句中插入相关的语法，从而影响SQL的执行方式。下面来看一条系统里面的查询语句Selectcount(*)fromck_rwd_mx_oldSelect/*+index(tIDX_CK_RWD_MX_BHLSH)*/count(*)fromck_rwd_mx_old两者一共返回7161482第一个sql执行时间为21秒，第二个执行时间为3.75秒，很明显我们看到加了HINT的，强制进行索引扫描，效率明显提高了。当然，我们也可以根据应用的需要添加HINT，比方有些应用只是需要找到符合条件的第一条数据这时我么可以使用如下HINT:SELECT/*+FIRST_ROWS(1)*/STORID,FROMTAL_SOTEOracle默认的OPTIMIZER_MODE是ALL_ROW,基于规那么的优化器，加了FIRST_ROW后强制OPTIMIZER_MODE为FIRST_ROW;FIRST_ROW还可以指定参数FIRST_ROW(n)在日常维护中还发现一个问题，比方我用select/*+index(tckt_spkfk)*/count(*)fromspkfk;执行方案如下：ExecutionPlan0SELECTSTATEMENTOptimizer=ALL_ROWS(Cost=23Card=1)10SORT(AGGREGATE)21INDEX(FASTFULLSCAN)OF'PK_SPKFK'(INDEX(UNIQUE))(Cost=23Card=31883)而我执行select/*+index(tckt_spkfk)*/count(xslb)fromspkfk;执行方案如下：ExecutionPlan0SELECTSTATEMENTOptimizer=ALL_ROWS(Cost=444Card=1Bytes=3)10SORT(AGGREGATE)21TABLEACCESS(FULL)OF'SPKFK'(TABLE)(Cost=444Card=31883Bytes=95649)当我执行select/*+index(tckt_spkfk)*/count(spbh)fromspkfk;执行方案如下：ExecutionPlan0SELECTSTATEMENTOptimizer=ALL_ROWS(Cost=22Card=1Bytes=12)10SORT(AGGREGATE)21INDEX(FASTFULLSCAN)OF'CKT_SPKFK'(INDEX(UNIQUE))(Cost=22Card=31883Bytes=382596)我们看到第一个求count(*)变相选择PK_SPKFK做为索引扫描，第二个HINT被忽略了，而做全表扫描，只有第三个求count(spbh),选择索引扫描，，为什么呢？因为，要对表的记录求总数，HINT的索引是唯一索引且不为空，如果CBO选择在索引上做了COUNT,当索引字段有空值时，count字段必然不准确，当做COUNT(*)的时候oracle会默认选择不为空的的索引做扫描，这就是基于代价的优化器〔CBO〕的好处了。而第二个求count(xslb)因为改字段可为空，oracle找不到适宜的索引做扫描，而HINT使用的CKT_SPKFK是建在spbh字段的索引，做count的时候结果必然不准确。比方T表实际上有一千条数据，spbh字段有100空，xslb有200个空，这样求count(xslb)使用索引扫描得出的是900个，显然数据是错误的。所以这种情况下CBO是不会做索引的，因为他会导致错误的结果。而当在索引上创立了主键pk_spkfk，这样就保证了该字段不为空。当再次地表做count(*)的时候指定的HINT就起作用了，因为索引不为空，对索引的COUNT和对表的COUNT值是相同的。还有在日常维护中，发现表关联的操作比拟多，经过对系统的实验得出了一个结论：大表间的关联操作使用HASHJOIN会比NESTEDJOIN效率高一点，小表间的关联通常选择NESTEDJOIN比HASHJOIN效率高些，而一般能用MERGEJOIN提高性能的地方，HASHJOIN都会发现更出色的性能。变量绑定变量绑定是OLTP数据库系统中一个非常重要的技术点。良好的变量绑定会是OLTP系统数据库中的SQL跑的飞快，内存效率极高；不绑定变量可能会使OLTP数据库不堪重负，资源被SQL解析严重消耗，系统显得滞重而缓慢。我们知道一条sql在数据中是怎么被执行的，一条SQL被发送到效劳器中，会做一个HASH函数运算，得到一个HASH值，然后到共享池中找到是否有何这个HASH值匹配的SQL存在，如果找到了，oracle直接使用已经存在的执行方案去执行这条SQL，然后将结果返回给用户，如果在共享池中没有找到，那么把他当做一条新的SQL,将会按照以下顺序执行，语法分析->语义分析->生成执行方案->SQL的执行。下面比照一个一条SQL执行了10000次时，绑定变量和非绑定变量在资源上的消耗情况例一：PARSINGINCURSOR#1len=119dep=0uid=55oct=47lid=55tim=1017528684hv=293694880='c6937c78'beginforxin1..10000loopexecuteimmediate'select*fromall_objectswhereobject_name=:x'usingx;endloop;end;ENDOFSTMTPARSE1:c=0,e=1536,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1017528682执行时间：0.分析次数：34次执行次数：10084次例二PARSINGINCURSOR#1len=113dep=0uid=0oct=47lid=0tim=4150023581hv=1876790916ad='c66d8260'beginforxin1..10000loopexecuteimmediate'select*fromall_objectswhereobject_name='||x;endloop;end;ENDOFSTMTPARSE1:c=0,e=1701,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=4150023579执行时间：分析次数：30002次执行次数：30003次两种情况比照的结果显示，绑定变量SQL的资源消耗要远远少于未绑定变量的SQL资源消耗，sql的执行次数越多，这种差距就越明显，未绑定变量SQL的资源主要消耗在产生递归SQL中，这些SQL主要是对SQL语句做硬分析时使用的。如果我们让所有用户在数据库操作中传给ORACLE的都是这样一个由变量代替常量的SQL,那么oracle只需要硬分析第一条sql就可以了，这样省掉了前面很耗资源的硬分析过程。使用索引管理组织索引索引可以大大加快数据库的查询速度，索引把表中的逻辑值映射到平安的RowID，因此索引能进行快速定位数据的物理地址。但是有些DBA发现，对一个大型表建立的索引，并不能改善数据查询速度，反而会影响整个数据库的性能。这主要是和SGA的数据管理方式有关。ORACLE在进行数据块高速缓存管理时，索引数据比普通数据具有更高的驻留权限，在进行空间竞争时，ORACLE会先移出普通数据。对一个建有索引的大型表的查询时，索引数据可能会用完所有的数据块缓存空间，ORACLE不得不频繁地进行磁盘读写来获取数据，因此在对一个大型表进行分区之后，可以根据相应的分区建立分区索引。如果对这样大型表的数据查询比拟频繁，或者干脆不建索引。另外，DBA创立索引时，应尽量保证该索引最可能地被用于where子句中，如果对查询只简单地制定一个索引，并不一定会加快速度，因为索引必须指定一个适合所需的访问路径[2]聚簇的使用Oracle提供了另一种方法来提高查询速度，就是聚簇〔Cluster〕。所谓聚簇，简单地说就是把几个表放在一起，按一定公共属性混合存放。聚簇根据共同码值将多个表的数据存储在同一个Oracle块中，这时检索一组Oracle块就同时得到两个表的数据，这样就可以减少需要存储的Oracle块，从而提高应用程序的性能。优化设置的索引，就必须充分利用才能加快数据库访问速度。ORACLE要使用一个索引，有一些最根本的条件：a、where子名中的这个字段，必须是复合索引的第一个字段；b、where子名中的这个字段，不应该参与任何形式的计算。使用分析函数分析函数可以减少表扫描的次数，下面先看一个ERP系统中分析函数使用提高数据库性能的案例：selectdistinctdsl1.peer_idpeer_id,nvl(ne_disconnect_info.ne_state,1)ne_statefromdcc_sys_logdsl1,(selectdistinctdnl.peer_idpeer_id,decode(action,'disconnect',0,'connect',0,1)ne_statefromdcc_sys_logdsl,dcc_ne_logdnland((dsl.action='disconnect'anddsl.cause='关闭对端')or(dsl.action='connect'anddsl.cause='连接主机失败'))andlog_type='对端交互'anddsl.log_time=(selectmax(log_time)fromdcc_sys_logandlog_type='对端交互'))ne_disconnect_infowheredsl1.peer_id=ne_disconnect_info.peer_id(+)原先至少需要扫描2次！现在根据KEEP结合DENSE_RANK的方式，将表扫描从2次变为了1次，具体代码改写如下：SELECTa.peer_id,CASEWHENdnl.peer_idISNOTNULLANDstrIN('disconnect关闭对端','connect连接主机失败')THEN'0'ELSE'1'ENDne_stateFROM(SELECTpeer_id,MIN(action||cause)KEEP(DENSE_RANKLASTORDERBYlog_time)strFROMdcc_sys_logdslWHERElog_type='对端交互'GROUPBYpeer_id)a,(SELECTDISTINCTpeer_idFROMdcc_ne_log)dnlWHEREa.peer_id=dnl.peer_id(+))利用or代替unionallselectpeer_id对端标识,null源域名,null目标域名,alert_type告警类型,log_time告警时间,cause告警内容,deal_log处理状态,deal_staff处理人,deal_time处理时间,remark备注fromdcc_sys_logwhereaction='disconnect'andcauselike'对端被关闭%'anddeal_log='deal_log'andalert_type='alert_type'andlog_time>=TO_DATE('2010-08-02','YYYY-MM-DD')andlog_time<TO_DATE('2010-08-03','YYYY-MM-DD')+1union(selectpeer_id对端标识,origin_host源域名,dest_host目标域名,alert_type告警类型,log_time告警时间,cause告警内容,deal_log处理状态,deal_staff处理人,deal_time处理时间,remark备注fromdcc_ne_logwhereresult=0andcauselike'parser失败%'anddeal_log='deal_log'andalert_type='alert_type'andlog_time>=TO_DATE('2010-08-02','YYYY-MM-DD')andlog_time<TO_DATE('2010-08-03','YYYY-MM-DD')+1)union(selectpeer_id对端标识,origin_host源域名,dest_host目标域名,alert_type告警类型,log_time告警时间,cause告警内容,deal_log处理状态,deal_staff处理人,deal_time处理时间,remark备注fromdcc_ne_logwhereresult_code='DIAMETER_UNABLE_TO_DELIVER'andsvcctx_idlike'SR-Timeout%'anddeal_log='deal_log'andalert_type='alert_type'andlog_time>=TO_DATE('2010-08-02','YYYY-MM-DD')andlog_time<TO_DATE('2010-08-03','YYYY-MM-DD')+1)union(selectpeer_id对端标识,null源域名,null目标域名,alert_type告警类型,log_time告警时间,cause告警内容,deal_log处理状态,deal_staff处理人,deal_time处理时间,remark备注fromdcc_sys_logwhereaction='disconnect'andcauselike'接收消息异常%'anddeal_log='deal_log'andalert_type='alert_type'andlog_time>=TO_DATE('2010-08-02','YYYY-MM-DD')andlog_time<TO_DATE('2010-08-03','YYYY-MM-DD')+1)很明显，此处的UNIONALL完全可以用OR来改造，等价改写，减少表扫描次数。优化改造后SQL为：selectpeer_id对端标识,null源域名,null目标域名,alert_type告警类型,log_time告警时间,cause告警内容,deal_log处理状态,deal_staff处理人,deal_time处理时间,remark备注fromdcc_sys_logwhereaction='disconnect'and(causelike'对端被关闭%'orcauselike'接收消息异常%')anddeal_log='deal_log'andalert_type='alert_type'andlog_time>=TO_DATE('2010-08-02','YYYY-MM-DD')andlog_time<TO_DATE('2010-08-03','YYYY-MM-DD')+1unionselectpeer_id对端标识,origin_host源域名,dest_host目标域名,alert_type告警类型,log_time告警时间,cause告警内容,deal_log处理状态,deal_staff处理人,deal_time处理时间,remark备注fromdcc_ne_logwhere(result=0andcauselike'parser失败%')or(result_code='DIAMETER_UNABLE_TO_DELIVER'andsvcctx_idlike'SR-Timeout%')anddeal_log='deal_log'andalert_type='alert_type'andlog_time>=TO_DATE('2010-08-02','YYYY-MM-DD')andlog_time<TO_DATE('2010-08-03','YYYY-MM-DD')+1总结和建议通过以上生产中的优化案例描述，大家对前面总结的优化思路树模型应该有了较深刻的认识。本案例中，在使用未改写SQL进行优化并到达目的后，并没有就此结束研究。在人为增加了大量数据的情况下，发现系统暴露出许多新的问题，最后依赖改造SQL的方法来实现优化的目的。依次进行了为count(*)语句加上notnull关键字，改造中间表为真实临时表，去掉大量不必要的重做数据的删除语句，用分析函数及merge语句改造普通SQL，构造分区表加上分区字段等工作。如果数据库某些任务原本运行的很好，突然变慢了，我们可以通过对数据库整体做性能优化分析，这样可以迅速定位到真正的瓶径所在，从而解决问题。本文介绍了AWR的方法，由于篇幅所限仅仅只是说明了一下思路，希望能抛砖引玉，开启大家的兴趣之门。通过以上的探讨知道，其实优化还是有规律可循的，只要深入学习理解ORACLE体系结构和各个相关知识点，脑海中时刻有优化的思路模型树做为指导，当然，我所提及的两棵树模型是我自己所想的，限于水平，只是起到抛砖引玉，给大家做参考，大家可以自己思考，将自己的思想和技能融合进去，将优化模型的认识完善，希望在大家的共同努力下，将数据库调优工作做到最好！另外，相比优化而言，数据库设计其实显的更有重要，好的系统是设计出来的而不是优化出来的，设计中也是有规律可遵循的，也有模型可以建立，我会考虑后续在设计方面建立出一套设计思路模型，并不断完善和改良。限于篇幅本文很多内容不能深入展开探讨，许多方法只能说个思路，具体细节有兴趣朋友可以通过相关文档去深入学习了解。数据库应用部署的好坏会对ERP应用起到举足轻重的影响，结合优化数据库的工程经验及对相关数据库知识的学习探索，我总结了如下一些数据库管理应用中的建议给公司做参考，考虑不周和理解错误之处请批评指正。要有ORACLE优化意识开发人员和维护人员要掌握根本的查看执行方案的方法，不断加强优化意识！理解ORACLE是如何基于CBO模式进行工作的。如果开发人员和维护人员有了优化意识和相关知识，就能自己发现和防止前面提到的表和索引未分析导致执行方案不正确的问题。很多人根本缺乏这样的意识，在语句执行慢的时候，就只做简单的等待而不是去观察为什么慢。其实有的时候，比方plsqldeveloper工具一个简单的F8就可以查看执行方案是什么，从而得知有无走索引和是否用到分区；通过查看一个简单的v$session_wait视图就可以知道系统在等什么，通过观察v$sql视图的execute字段我们就可以知道数据库是否没有使用绑定变量。其实这些并不太难，关键是要有这个想法！公司开发设计维护人员人人都有这样的意识，一定能大大提高工作效率！[4]优化有步骤可遵循本文全篇都在描述优化的思路及步骤，并引进了优化思路模型树的概念，后续我会在公司中和大家一起分享这些优化的思考方法，希望和我交流过的同事都能理解和领会我在文中描述的内容，在遇到数据库性能问题的时候，能参考本文的思路总结，优化能做到有章可循，提高工作效率！要做大基准测试大家还记得我在进行改写SQL优化时做的准备工作吧，把所有表的数据量翻4番，数据量增大后原来没注意到的性能问题全部暴露出来了，接着做了四次修改SQL的优化后，才真正的改良了这个迁移程序的性能。[5]这个案例非常典型，告诉了我们这样一个道理，测试环境中的应用要真正部署到生产，必须模拟生产的大数据量，进行大基准测试，甚至要超过生产真正的数据量！如果只是简单的几个用户，少量的数据，你将永远也发现不了潜在的各种问题，这点尤其重要！防止重复创造轮子我发现不少人花了很大的精力开发了一个数据库本身就已经提供的功能，比方为了控制用户的连接数有人写了一个代码监控v$session中连接数量，到达某个值后强行将其kill实现，其实ORACLE中的profile早已提供了这样的功能，而且使用起来相单简单平安！还有开发人员编写了大量代码实现了sequence序列的功能，这样不止麻烦，还会遇到并发带来的各种问题，而且性能也将因为用不到cache等功能而大打折扣。在本文中中我们了解到oracle已经用全局临时表实现了开发人员构造的中间表实现的功能，而且在利用上ORACLE全局临时表后，代码大大减少的同时，性能还显著提升了！此外还有非常重要的一点就是利用上ORACLE自带功能，这些功能也可以随着数据库的版本升级而自动升级并更加强大。力求使用简单方法只要深入学习，开发人员就会发现，原来ORACLE已经提供了许多很好的方法，完全可以替代那些我们费尽心思编