《BS系统疑难问题分析与调优常见方法介绍》

1、BS系统疑难问题分析与调优常见方法介绍应用系统部署实施之后可能会出现一些部分功能模块不可用、系统运行缓慢、系统崩溃等莫名奇妙的问题，这些问题现象多种多样，导致问题的原因也并不相同，解决起来更是千差万别。分析与调优的方法并不能一概而论，但也并不是毫无规律可言，掌握一些要领、思路、常用的排查手段及常见的问题解决办法有助于缩短问题解决的周期。本文将以专题介绍及案例分析的方式对这些思路和方法做一些总结，希望能够帮助各个项目有效的排查并解决这些问题。疑难问题分析与系统调优是件十分复杂的事情，生产环境的复杂多样决定了不可能有人能够有百分之百的把握解决所有的问题，无论是从经验、技术还是逻辑的角度来说都是这样

2、。因此这项工作对人员的要求就较高，为了能够帮助不太熟悉这项工作的人员尽快进入角色，以往的经验总结就显得非常重要。因此本文永远都不会完结，仅做一个抛砖引玉，希望在以后的工作中，能够得到不断的完善。1. 要领敏锐的头脑，缜密的思维，细致的工作，广泛的联想能够帮助更好的适应这项工作。敏锐的头脑：强调能够快速的到记忆或文档中找到匹配或近似匹配当前问题的问题。这一点尤为重要，如果在记忆中或文档中找不到痕迹，则此问题就是一个全新的问题，而一个全新的问题对于任何人来说都是一件棘手的事情。缜密的思维：在当前人类认知的世界中，任何事情都是有因才有果，也就是所谓的符合逻辑。任何奇怪的现象，包括违背常识的事情，都有

3、着其内在的原因。因此即便是遇到严重违背常理的事情也不要慌乱，此时就需要用以往的一些经验及其他渠道，如网络、他人等查找可能的原因，然后逐一的按照逻辑进行排查。细致的工作：这能帮助你搜集到用以定位问题的关键点，用以支持判断逻辑的证据，用以触发联想的触点，也能保证已有的环境不会被破坏或改变。广泛的联想：基于已有的事情广泛的联想、寻找相关的事情，常常非常有助于事情的解决，也有助于将单个的、破碎的事情片段联系在一起形成一系列环环相扣的链条。2. 总体思路处理问题的总体思路如下：根据问题汇报、粗略的问题描述或一些已有的手段清晰、明确的定义问题；基于问题定义进行分析，寻找可能引发问题的原因；在某种环境下模拟

4、、重现问题进一步确定问题原因；对于分析出的问题进行修改；对问题修改的结果进行验证。问题定义：这个步骤十分关键，因为问题的汇报和粗略的问题描述往往并不准确，有时甚至是错误的。因此不能过分的相信这些汇报和描述，因为不准确的问题描述会将你引上歧路，大大延缓问题的解决时间。所以除了了解已有的问题描述外，还需要做一些相关的试验用以确定已有描述的准确性。问题分析：基于问题定义进行分析，寻找可能引发问题的原因。这个步骤找到的有可能不是根本原因，而且由于事情的复杂性，有可能会造成误判。这种情况不可能避免，因此下最终的结论时要慎重。在一些复杂的问题中可能需要与其他几个步骤一起进行迭代，才能判定问题的成因。问题重

5、现：重现问题有助于进一步确定问题的成因，也有助于将来问题解决后的回归测试。是在生产环境还是测试环境下重现问题，有很多因素，但其中最重要的一个因素是这个过程是否会不可逆的改变现有的生产环境。问题修改：对分析出的问题进行修改。问题验证：基于修改的结果进行回归测试，验证问题是否解决。一般来讲在条件允许的情况下，尽可能的先在测试环境下进行验证，确认无误后再在生产环境下进行验证。切忌过分的相信自己的能力。3. 专题3.1. 客户端技术在B/S系统中，传统web客户端组件及其各种变种，主要承担了界面展现及请求发送与接收的工作。传统的web客户端组件包括：HTML，各种Script，XML，CSS等。变种主

6、要指随着Web2.0而新兴起的一些技术：Flash，基于脚本的RIA，各种类型的自定义控件。这些组件或技术负责前台页面的展现，而与后台的通信一般通过HTTP协议来进行。3.1.1. 常见问题. 脚本性能问题描述：脚本性能问题主要在基于脚本的RIA解决方案中体现比较明显，这种解决方案为了达到良好的交互效果，大量的使用了脚本语言对页面进行渲染，由于脚本的复杂性，及浏览器的对脚本优化还不到位，经常会有一些性能问题。解决方案：1. 在满足兼容性的前提条件下，尽量升级客户端到较新版本的浏览器。新版本的浏览器一般内部会做优化，加快HTML和脚本的解析速度。2. 换用较新版本的RIA解决方案或

7、较快的其他RIA解决方案。新版本的同类型RIA解决方案一般在性能方面都会有所提升。如果最新版本的依然无法满足渲染速度的要求，只能考虑更换其他RIA解决方案。3. 更换客户机硬件配置。RIA技术的理念是充分的利用客户机的资源进行渲染，在维持服务器压力不变、甚至降低服务器压力的情况下，给用户带来更好的交互体验。这里的一个前提是客户机的硬件配置不错，因此如果客户机硬件配置较低，则需要考虑升级客户机硬件或者放弃使用RIA技术。. 同步调用问题描述：在浏览器进行同步调用时，直到所有的同步调用都完成，页面才会展现出来。如果其中的某个请求的响应速度较慢，则会拖累整个页面进入一种空白、假死的状态

8、，用户体验十分不好。解决方案：1. 请求的响应较慢一般是由于中间件或数据库处理的慢而造成的，所以根本的解决办法是调整中间件、数据库或者算法，后台处理的速度上来了，前台的页面出来的也自然就快了。2. 在某些情况下，调整中间件、数据库或者算法实施成本都太高，为了快速的改善用户体验，一个重要的方案就是异步请求，将较慢的请求改成异步形式的，就可以避免一条臭鱼坏了一锅汤的结果了。. 带宽占用问题描述：有些应用，特别是采用了RIA技术的应用，经常会向中间件请求大量的资源，严重的占用了网络带宽资源，无形中同时对网络和中间件资源都造成了巨大的浪费，加重了他们的负担。解决方案：1. 在客户端缓存基

9、本不变的静态文件，减少文件的下载次数。2. 对脚本文件进行语法压缩，减小脚本文件的大小。3. 对HTTP响应开启GZIP压缩，对于文本型的资源能够有效的缩减传输的流量。3.1.2. 常用工具. HttpWatchPro此工具可以将客户端发出的Http请求细节捕获出来，并记录每个请求的时间，使用这个工具可以清楚的定位究竟客户机请求了些什么资源，以及哪些资源的请求耗时最长。3.2. 中间件技术中间件即BS系统中的应用服务器，我们生产环境下最常用的就是WebLogic系列。中间件是Web应用程序的容器，负责接收客户端请求，进行业务逻辑处理，并最终与数据库交互完成整个过程。因此其地位十分

10、重要，有很多种类型的问题发生在这个层面。3.2.1. 常见问题. 内存配置问题描述：中间件的控制台经常出现OutOfMemory错误，则很有可能是因为部署实施时没有修改JVM的默认内存配置参数，造成可用内存过少所致。解决方案：1. 通过简单的修改JVM内存参数即可，但要注意，修改完后要进行验证，确认参数是否起作用，不要想当然。. 内存溢出问题描述：如果内存参数已经修改成功，而中间件的控制台还是经常出现OutOfMemory错误，则很有可能是由于代码编写的不好，消耗内存过大所致。解决方案：1. 通过使用合适的JVM内存监控、分析工具，捕获到发生内存溢出的程序，进而修改

11、代码解决问题。. 内存泄露问题描述：如果中间件重启后的一段时间没有问题，但运行几天或更长的时间后却出现OutOfMemory错误，则很有可能是出现了内存泄露。内存泄露和内存溢出是有很大区别的。内存溢出通常是由于代码写的不好，程序运行消耗大量的内存，很有可能程序还没有执行完成就发生了错误，即OutOfMemory错误。而内存泄露一般是程序执行已经完成，但是使用到的内存资源却无法释放，随着程序的不断运行，这部分不能释放的内存资源越来越多，直至最后发生内存溢出错误。解决方案：1. 内存泄露程度和排查的难易的程度成反比，即内存泄露越严重排查起来越简单，内存泄露越轻微排查起来越困难。通过使

12、用合适的JVM内存监控、分析工具，可以逐渐找到发生内存泄露的程序，进而修改代码解决问题。. 线程配置问题描述：中间件是以线程的方式处理客户端请求的，因此线程是否够用并能有效的工作就决定了客户端的每个请求能否顺利完成。如果线程数配置过少，客户端的请求就不能得到及时的响应，如果配置过大，又造成资源的浪费。解决方案：1. 通过修改中间件的线程相关配置可以逐渐找到适合生产系统的线程数量。. 连接池配置问题描述：在业务应用程序中，不可避免的要进行数据库相关的操作，为了保证数据库连接的高效和稳定，在生产环境中一般都使用中间件自带的连接池。数据库连接消耗数据库主机的资源，所以连接

13、池配置过大，造成资源的浪费，配置过小，又无法满足业务应用的需要。解决方案：1. 通过修改中间件的连接池相关配置可以逐渐找到适合生产系统的连接池数量。. 问题程序问题描述：这里所谓的问题程序指在JAVA程序代码中使用循环次数很多，且循环体中又带有大量操作的循环程序，这种程序是最常见的一种问题程序。这种程序大量占用中间件的资源，可能也会大量的占用数据库资源，而且通常来讲执行速度较慢，一般都会造成比较坏的影响。解决方案：1. 通过监控工具找到这些问题程序，修改代码解决问题。3.2.2. 常用工具. WebLogic控制台性能监控此工具可以方便的监控WebLogic内存及线

14、程资源的使用情况。内存监控包括总量及当前已用量两个值及当前已用量变化的曲线。通过内存总量可以验证内存参数配置是否起作用。通过总量及当前已用量可以得出剩余的内存量，对这个参数进行一段时间的采集即可判断出是否存在内存泄露。通过当前已用量的变化曲线可以用以预估系统是否存在消耗内存资源过大的程序，通常表现为一条很陡的曲线。通过这条曲线还可以发现所谓的问题程序，问题程序一般会表现为一条剧烈起伏的折线。线程监控包括空闲线程数和队列长度值。如果空闲线程数经常很小，且队列长度经常有较大的值，可能的一个原因就是线程配置的不太合适了。. WebLogic执行线程监控此工具配合上面的工具一起使用，可以

15、详细的了解当前中间件上运行着哪些线程。配合上面的工具可以对内存溢出、问题程序进行排查。. WebLogic连接池监控此工具可以方便的监控WebLogic连接池的使用情况。通过对连接池运行情况的监控，可以检查连接池的最大最小连接数量配置的是否合适。由于中间件集群的存在，连接到数据库的总连接数等于每个集群节点的连接总数*集群节点的数量。而且由于生产环境下数据库服务器的性能有高有低，各个业务系统也不完全相同。因此不可能将所有连接池的最小连接数都配置为一个非常大的值。一般的做法是将最小连接数配置为一个相对保守的值，而最大连接数配置为一个能接受的较大的值。然后通过连接池监控中的总连接数来判

16、断最小值配置的是否合适。总连接数是说从某个连接池建立起来总共建立的连接数量，如果这个值很大，说明此连接池经常的扩大、收缩，一般来讲这就是最小连接配置的较小所导致的。这时可以增大最小值的设置，重新监控使用情况。. Jprofiler此工具实时的跟踪中间件的运行情况，将内存使用情况，CPU使用情况等详细信息显示出来，可以用于排查内存溢出、内存泄露、问题程序等问题。但需要注意的是这个工具对中间件的性能有一定的影响，所以如果在生产环境下使用，会拖慢中间件运行的速度，有一定风险。一般推荐用在测试环境、或压力较小的生产环境下。. MemoryAnalyzer专门用来分析JVM内

17、存转储文件的分析工具。内存转储的意思是将JVM内存中的东西存储成为一个专门的文件，然后通过特定的工具就可以对这个文件进行分析。所以首先要将JVM的内存转储出来才行，这需要用到JVM本身的一个功能，这个功能受JVM版本的影响，只有较高的版本的JVM才能提供这个功能。具体要求的最低版本号可以查阅MemoryAnalyzer工具的帮助文档。在满足要求的JVM版本配置上启动参数：-XX:+HeapDumpOnOutOfMemoryError，即激活了内存转储功能。这个参数的含义是当JVM发生内存溢出即OutOfMemory时，JVM会把内存中的东西存成一个文件，名为java_pid1464.hprof

18、，其中红色的部分为Java进程的进程标识符PID。文件存放的位置一般是中间件启动命令所在的目录。进行内存转储时后台会有所提示。这个工具对生产环境基本没有什么影响，推荐生产环境下调试问题采用。这样通过中间件运行时自动的内存溢出，当然也可以手工制造一个内存溢出，就可以获得内存的转储文件。然后就可以通过MemoryAnalyzer工具对其进行分析，找到内存溢出或泄漏的原因了。3.2.3. 常用配置. WebLogic启动内存分配Windows修改startWebLogic.cmd添加如下文字：set MEM_ARGS=-Xms1024M -Xmx1024M -XX:PermSize=2

19、56M -XX:MaxPermSize=256M其他操作系统 修改startWebLogic.sh添加如下文字：MEM_ARGS=-Xms1024M -Xmx1024M -XX:PermSize=256M -XX:MaxPermSize=256M 其中：-Xms为堆内存最小大小-Xmx为堆内存最大大小-XX:PermSize为永久保存区最小大小-XX:MaxPermSize为永久保存区最大大小. WebLogic参数配置1. 域JTA超时秒数:600(默认值30，为可选调节项，在使用WebLogic连接池时，如果应用中存在执行过于缓慢的事务操作，可以更改这个值，以便功能可以完成。

20、但并没有根本的解决问题，修改程序，加快业务操作的执行速度才是根本)2. 域日志最小文件大小:1024 限制保留的日志文件数：勾选要保留的日志文件:303. 服务器日志Stdout严重程度阈值:Error最小文件大小:1024 限制保留的日志文件数：勾选要保留的日志文件:30关闭Http日志4. 线程池配置线程计数:100（为CPU数量*25，一般不用超过100）. WebLogic连接池配置1. 拷贝工程lib下面的包ojdbc14.jar或者合适的ojdbc14.jar到WebLogic的Server lib下面，类似于D:beaweblogic81serverlib下，覆盖同

21、名文件（原始文件记得备份）。2. 启动WebLogic进入控制台，点击【连接缓冲池】，点击【配置新的JDBC 连接缓冲池】。选择驱动程序，一般为Oracle Thin XA 或 Oracle Thin。他们的区别是Thin XA驱动支持分布式事务，而Thin驱动不支持。具体选择什么根据需求确定。3. 点击【数据源】，点击【配置新的 JDBC 数据源】。4. 确认UNIEAP用户中drm_sys_datasource表中是否有WebLogic数据源配置及配置是否正确5. 修改OP.properties文件如下配置XTM_PROVIDER=UDOLINK XTM_PROVIDER= WEBLOGI

22、CMANAGED_ENVIRONMENT=false MANAGED_ENVIRONMENT=true6. 重启WebLogic，并在连接池监控界面中确认，是否连接池已经成功启用。. Web应用配置3.3. 数据库技术数据库是业务数据最终存储的位置，最为重要，也最为复杂。我们目前主要使用的是Oracle10g，因此下面的所有讲解都遵循这个前提进行。数据库的相关问题不是简单的一些文字能够描述清楚的，这里只简要的介绍一下最常遇到的一些问题。重点强调的是，由于数据库中存储着业务数据，因此对它的操作要格外的小心，不熟悉的操作不要随便执行，一些重要的调整尽量申请专业的系统工程师或DBA来执

23、行，注意多备份。3.3.1. 常见问题. 内存配置问题描述：此问题常见于一些初期业务压力不大的系统中，这些系统由于初期业务压力不大或缺少规划，通常在32位windows上运行着32位的oracle，而且数据文件多直接放在本机硬盘上，好一点的有可能本机做个了RAID5。这种数据库通常不是专业的系统工程师或DBA安装的，因此很可能什么参数都没有调整过，且硬件配置往往也较差，随着数据量的增加，不可避免的越来越慢。解决方案：1. 重新规划数据库部署方案，并全面进行调整。2. 调整数据库内存参数，看是否有所改观。. 连接数配置问题描述：此问题常见于一些初期业务压力不大的系统中

24、，这些系统由于初期业务压力不大或缺少规划，通常在32位windows上运行着32位的oracle，而且数据文件多直接放在本机硬盘上，好一点的有可能本机做个了RAID5。这种数据库通常不是专业的系统工程师或DBA安装的，因此很可能什么参数都没有调整过，由于默认的连接数较少，因此可能会有不够用的情况。解决方案：1. 重新规划数据库部署方案，并全面进行调整。2. 调整连接数配置。. SQL语句问题问题描述：数据库操作执行的缓慢，除了和系统软硬件配置有关外，还和SQL语句本身有着重大的关系，且绝大多数的情况都是后一种。解决方案：SQL语句的优化本身也是一门学问，涉及方方面面，这里不可能进

25、行全面的讲解，只进行基本的介绍，起到入门的作用即可。一般的，SQL语句的执行过程可以分为分析阶段和执行阶段，在分析阶段数据库对SQL语句进行语法分析、语义分析等操作并最终获取SQL语句的执行计划，在执行阶段数据库按照选定的执行计划执行SQL语句并最终获得数据。在这个过程中对性能影响较大的有两块：SQL语句的分析过程及根据分析获得的执行计划。1. SQL语句的分析过程Oracle对SQL语句进行分析的过程中区分大小写，即不同的SQL语句，即使仅仅是大小写不同，Oracle都会认为这是完全不同的SQL语句。对于新的SQL语句，Oracle会进行一系列的复杂分析，这个分析过程比较消耗资源，而分析完成

26、后，Oracle会对这条语句进行散列，然后将语句放置到高速缓存中。如果之后申请执行的SQL语句能够在高速缓存中查找到，则上述的分析过程不被执行，Oracle直接选用已经分析过的版本直接执行操作，反之，则Oracle需要重新执行上述过程。这里面最常遇到的问题就是变量的绑定，Oracle会认为下面的语句是完全不同的SQL语句。Select * from table1 where name =aaaSelect * from table1 where name =bbb这是十分糟糕的情况，正确的做法是使用变量绑定，由Oracle在SQL语句的执行阶段进行变量的绑定来完成。Select * from

27、table1 where name = ?2执行计划Oracle最终执行SQL语句是按照执行计划来进行的，因此执行计划的好坏就十分关键。那么优化SQL语句的根本其实就是改变语句的执行计划。执行计划受很多方面影响，下面列举一些，并找几个最常见的进行说明。 数据库的版本越高的数据库版本在相同的情况下做出的执行计划就越好，所以在可能的条件下，升级数据库的版本是个好的主意。 初始化参数如最重要的优化器模式参数，optimizer_mode，此参数决定了Oracle将使用何种优化器进行执行计划编排。Oracle的优化器分为两种：基于规则的优化器（RBO）和基于成本的优化器（CBO）。基于规则的优化器严格

28、按照优先级的次序制定执行计划，而基于成本的优化器则根据收集到的相关统计信息制定执行计划。Oracle10g中默认的optimizer_mode值为ALL_ROWS，使用基于成本的优化器。需要注意的是优化器评估出的成本cost是一个相对的值，即只有在环境完全相同的情况下，这个值才能够相互比较，一般情况下，此值越小，代表SQL语句执行的越快。在不同的环境下这个值完全不能互相比较。在有些极特殊的情况下，在相同的环境中有可能cost小的执行计划反而比cost大的执行计划更慢。因此改变SQL语句的执行计划后一定要进行实际的执行测试，不要想当然。 数据库的统计信息数据库的统计信息是使用基于成本的优化器的基

29、础，统计信息不准确，则优化器得出的执行计划就会不准。 增加或减少索引这个应该很好理解，不做过多说明。 改变索引的类型和顺序这个应该很好理解，不做过多说明。 改写SQL这个应该很好理解，不做过多说明。 使用HintsHints就是提示，作用是告诉Oracle使用什么样的方式制定执行计划，Hints有很多总类，这里不做过多说明，仅举个例子说明作用。使用规则优化器制定执行计划Select /*+ rule */ * from table1 where name =aaa使用成本优化器制定执行计划Select /*+ all_rows */ * from table1 where name =aaa3

30、.3.2. 常用工具. Oracle Enterprise ManagerOracle的企业管理器，自然是最权威，最全面的工具了。与性能有关的工具主要在其性能选项卡中。这其中包括了很多具体的工具，常用的如：ADDM，ASH报告，顶级活动，顶级使用者，快照（AWR），SQL优化指导。. Oracle Enterprise Manager ConsoleOracle的企业管理器客户端，可以脱离Web形式的企业管理器单独使用，这个工具需要单独的安装。常用的是会话查看功能，可以看到当前有多少会话，会话的状态，会话的操作系统进程标识符，会话正在执行的SQL及其执行计划等等的功

31、能。. PLSQL Developer的Sessions功能 此工具能方便的找到当前连接的会话，并查看会话执行的SQL语句。. 动态性能试图v$process，v$sessionv$process视图反映了当前系统Oracle的进程信息，v$session视图反映了数据库的会话信息，二者常被用来联合起来做一些信息的查询。连接方法为：select * from v$process p,v$session s where p.ADDR=s.PADDR;. 动态性能试图v$sqlarea此视图持续跟踪所有shared pool中的SQL语句的信息，通过这些信

32、息可以帮助我们寻找问题SQL。如：下面的语句是寻找基于成本优化方式中成本最高的SQL语句及执行次数等相关信息，其中OPTIMIZER_COST列即为优化成本。select t.OPTIMIZER_COST,t.SQL_TEXT,t.SQL_FULLTEXT,t.EXECUTIONS from v$sqlarea t order by t.OPTIMIZER_COST desc. PLSQL Developer的执行计划查看功能在PLSQL Developer中选中一条SQL语句，按F5键，即可查看当前SQL语句的执行计划。如果做了影响执行计划的操作，可以按F8键，刷新执行计划。其

33、中cost列为优化成本。. SQLPLUS的autotrace功能相对于上面的功能，此功能的使用稍显麻烦，但此功能可以获得额外的统计信息，对上面的功能是一个很好的补充。使用此功能需要按照以下的步骤进行。1. 运行sqlplus。输入sqlplus /nolog2. 用sys用户连接conn / as sysdba3. 建立plustrace角色D:oracleproduct10.2.0db_1sqlplusadminplustrce.sql（只需要执行一次建立角色即可，以后只进行授权就可以了）4. 根据sql语句所属的用户进行授权grant plustrace to elarp;

34、5. 连接到sql语句所属的用户conn elarp/elarp6. 根据想要的结果设置不同的跟踪级别set autot on(结果+计划+统计）set autot off(结果）set autot trace(计划+统计）set autot trace expl(计划）set autot trace stat(统计）7. 正常执行SQL语句，查看结果. 收集统计信息基于成本的优化器需要进行统计信息的收集，以下的两条命令比较常用。注意不要随便收集不清楚用户的全部统计信息，如system用户，sde用户等等。收集某个数据库用户的全部统计信息，包括索引信息。exec dbms_sta

35、ts.gather_schema_stats(elarp,cascade = true);收集某个数据库用户中某个表的统计信息，包括索引信息。exec dbms_stats.gather_table_stats(elarp,gg_jjb,cascade = true);. 常用命令1. 启停数据库sqlplus /nologconn / as sysdba启动数据库 startup停止数据库 shutdown immediate需要注意的是启停生产数据库一定要用命令启停，严禁在windows操作系统下用启停服务的方式进行。2. 启停监听服务启动监听 lsnrctl start停止

36、监听 lsnrctl stop3. 启停企业管理器启动企业管理器 emctl start dbconsole停止企业管理器 emctl stop dbconsole3.3.3. 常用配置. 内存配置调整内存配置之前需要注意，如果你对pfile和spfile不熟悉的情况下调整此参数，记得调整之前先备份pfile和spfile,采用直接拷贝备份的方式即可。一般情况下，pfile D:oracleproduct10.2.0db_1database init实例名.oraspfile D:oracleproduct10.2.0db_1dbs SPFILE实例名.ORA最好用show pa

37、rameter spfile确认一下spfile的位置。然后调整内存的参数配置，方法是：sqlplus /nologconn / as sysdbashow parameter sga 查看sga原始参数配置使用下面的两个命令修改sga大小alter system set sga_max_size = XXM scope=spfile;alter system set sga_target = XXM scope=spfile;show parameter pga 查看pga原始参数配置使用下面的命令修改pga大小alter system set pga_aggregate_target =

38、XXM scope=spfile;shutdown immediate 停止数据库startup 启动数据库用show parameter sga和show parameter pga查看新的参数设置是否成功。如果在启动数据库的时候报错误ORA-27102: out of memory，不要慌张，这是因为由于系统硬件内存配置的不同，操作系统的不同，oracle软件的不同，特别是32位windows配合32位oracle软件时，能够供数据库使用的物理内存是有限制的，所以在不同的环境中可以设置的sga和pga的最大大小是不一样的，可以通过查找网络资源或尝试法找到可以设置的最大值。这个错误解决起来很

39、简单，把刚才备份的spfile替换原来的文件，重启数据库，一般就可以了。如果启动的时候还是同样的错误，那有可能你的数据库使用pfile启动的，那就把备份的pfile也替换原来的文件，重启数据库，就可以了。. 连接数配置调整连接数之前最好也按照上面的方式备份一下pfile和spfile。调整的方法为：sqlplus /nologconn / as sysdbashow parameter processes 查看processes原始参数配置使用下面的命令修改processes大小alter system set processes = XX scope=spfile;show p

40、arameter sessions 查看sessions原始参数配置使用下面的命令修改sessions大小，关系为sessions =(1.1 * processes + 5)alter system set sessions= XX scope=spfile;shutdown immediate 停止数据库startup 启动数据库用show parameter processes和show parameter sessions查看新的参数设置是否成功。3.4. 操作系统技术3.4.1. 常用工具. Window任务管理器Windows任务管理器是很常用的工具，按照如图所示调整

41、出PID，I/O相关的数据，在查找某些问题时能够更有帮助。. Unix系统常用命令本小节的内容由于找不到合适的环境，因此无法截屏做详细的描述，在有合适的环境时可以自行实践。1. 寻找符合关键字的进程ps -ef|grep oracle 寻找oracle进程。ps -ef|grep java 寻找java进程2. kill -9 pid通过上面命令找到的进程标识符pid，强行终止一个进程。3. top/topas列出主机中顶级的活动，此命令支持通过附加参数，更详细的了解某一方面的信息。支持的参数可以通过-help参数获得。4. vmstat列出主机队列，内存，分页，CPU的一些有用

42、信息，常使用下面的形式vmstat 1，即每秒刷新一下结果。5. su 用户名切换操作系统用户到某个用户，常用来切换到数据库软件对应的操作系统用户。如su oracle，一般来讲切换到相应的数据库用户下才能执行如sqlplus等命令。6. df了解磁盘的剩余空间情况，常跟随df m或df g(以M或G的单位查看)一同使用。7. tail f 文件名查看一个文本文件的信息，如果文件发生了变化，则强制刷新终端的显示8. more 文件名以分页的形式查看一个文本文件的信息。9. nohup在服务器端后台执行一个命令，可以避免由于远程的终端连接中断，导致命令执行失败的情况。格式为：nohup XXX命

43、令 &如在服务器端后台执行启动WebLogic中间件的命令,并将后台文字输出到当前文件夹下的nohup.out文件中。nohup ./startWebLogic.sh nohup.out &在服务器端后台执行数据文件导入的命令nohup imp system/sys commit=yfile=/app/imp_data/oracle.dmplog=/app/imp_data/oracle_imp.logfromuser=(neudoc) touser=(neudoc) &如果需要查看后台的输出可以配合tail f nohup.out来实现。10. ls列出当前目录下的内容11. cd切换到指定

44、的目录下12. pwd查看当前目录3.5. UniEAP平台相关技术3.5.1. Platform1. 中间件集群时授权的不同步问题问题描述：此问题在中间件做集群的情况下发生，现象为使用平台的权限管理进行授权，结果发现只有当前授权的应用权限起了作用，而其他的集群节点上新授的权限都没有起作用。解决方案：这是因为平台只能实时的同步当前授权的应用的权限信息，而其他的集群节点权限需要被动的同步，即定期同步。这需要开启一个平台的组件。在EAPConfig.xml文件中找到如下组件描述：0将isEnabled调整为true，开启缓存同步组件，调整interval_time的设置，其单位为毫秒，例子中的设置

45、为5分钟检查一次权限是否变化，如果权限发生了变化就进行同步。使用如下语句向UniEAP用户中初始数据，如果已经存在记录则此步骤忽略。insert into CACHEOBJECT_STATUS (TYPE, UPDATE_TIME)values (menu, to_date(01-01-2005, dd-mm-yyyy);insert into CACHEOBJECT_STATUS (TYPE, UPDATE_TIME)values (org, to_date(01-01-2005, dd-mm-yyyy);insert into CACHEOBJECT_STATUS (TYPE, UPDAT

46、E_TIME)values (datasecurity, to_date(01-01-2005, dd-mm-yyyy);insert into CACHEOBJECT_STATUS (TYPE, UPDATE_TIME)values (page, to_date(01-01-2005, dd-mm-yyyy);commit;重启所有的集群节点，验证问题是否解决，注意被动同步不是实时的，是有时间间隔的。3.5.2. DRM1. DRM使用WebLogic数据源，接件模块出错问题描述：DRM使用WebLogic数据源，即业务应用配置使用WebLogic连接池时，配置方法见上文介绍的，接件模块出错

47、，错误为：Cant get a Connection from the DataSource: XASYS_WF。解决方案：替换最新的unieap-platform-drm-3.0.jar包，如果业务系统已经上线运行，觉得替换整个jar包风险比较大，可以尝试单独替换mon.impl.DBPersistenceManagerImpl.class类，看问题是否解决，并测试其他功能有无错误。2. 使用DRM进行查询，发现只查出了部分结果问题描述：使用DRM进行查询，发现只查出了部分符合条件的结果，而另一些数据明明存在，却没有被查询出来，反复检查代码发现并

48、没有什么问题。这是因为DRM对一次能够查询出来的最大结果集进行了限制，防止查询出的记录数过多，产生问题。解决方案：修改OP.properties文件的如下配置RESULTSET_LIMITATION为一个较大的数值。但需要注意的是一般来讲在程序中查询出过大的结果集然后再进行业务处理，看起来并不是一个明智的选择。3. 使用DRM进行数据库操作，希望查看操作的SQL语句问题描述：在解决很多问题中，都需要获得数据库操作的具体SQL语句才行。解决方案：修改OP.properties的配置IS_DEBUG为true，并修改log4j.xml文件中的Drm记录器的级别为debug。3.5.3. Form1

49、. 表单性能问题问题描述：系统中所有的表单，无论简单或复杂，数据量大或小，展现都不是很流畅，给人一种“卡”的感觉。使用WebLogic控制台监控系统内存，几乎一直是水平的直线，而不是有起有伏。解决方案：这是一个表单引擎本身的问题。首先寻找应用lib目录中是否有一个子目录oracle10g，有的话重命名里面的两个jar文件ojdbc14.jar为ojdbc14.jar.special，unieap-form-parser-3.0.jar为unieap-form-parser-3.0.jar.special接着使用反编译工具反编译应用lib目录下unieap-form-parser-3.0.jar

50、中的com.neusoft.form.engine.FormListener.class和com.neusoft.form.engine.FormReceiver.class类，并查找得到的java源文件中是否包含gc这两个字符。如果都没有找到，则清空weblogic中间件缓存文件后重试，问题就可以解决了。而如果找到了，替换最新的unieap-form-parser-3.0.jar包，如果业务系统已经上线运行，觉得替换整个jar包风险比较大，可以尝试单独替换com.neusoft.form.engine.FormListener.class和com.neusoft.form.engine.Fo

51、rmReceiver.class类，看问题是否解决，并测试其他功能有无错误。2. 表单使用WebLogic连接池问题问题描述：表单使用WebLogic连接池的情况下，可能会有两个错误,a. 在表单含有插入数据源的情况下，保存表单，后台报错误，java.sql.SQLException: Connection closed。b. 在表单中含有blob字段的情况下，保存表单，后台报错误，java.lang.ClassCastException解决方案：这是一个表单使用WebLogic连接池的问题。首先寻找应用lib目录中是否有一个子目录oracle10g，有的话重命名里面的两个jar文件ojdbc

52、14.jar为ojdbc14.jar.special，unieap-form-parser-3.0.jar为unieap-form-parser-3.0.jar.special然后替换最新的unieap-form-parser-3.0.jar包，如果业务系统已经上线运行，觉得替换整个jar包风险比较大，可以尝试单独替换com.neusoft.form.engine.persist. DefaultDataAccess.class类，看问题是否解决，并测试其他功能有无错误。3.5.4. Workflow1. 办件列表性能优化问题描述：如何能够实施小范围的修改提升办件列表的性能。解决方案：要弄清楚

53、这个问题，首先要清楚办件列表的性能大多都损失在哪里。首先，办件列表后台需要一个视图，这个视图由业务数据与工作流数据相关联构成。这个视图的复杂程度就决定了最后办件列表数据展现的快慢。其次，对工作流接口的调用，为了展现办件列表的数据，我们需要调用工作流接口，取得例如列表中数据的数量，数据的详细信息等东西。这些工作流接口从根本上是操作后台的那个视图。最后，数据取得后使用页面技术将数据展现出来。通过以上的分析我们可以得出如下的结论，按照现有的工作流设计，要想提升办件列表的性能，就必须提升后台视图的性能，减少视图的访问次数。故采取如下的方法优化办件列表的性能。a. 在设计阶段，尽可能的保证业务数据的全部

54、内容只包含在一个业务表中，个性化的数据尽量通过维持冗余字段的方式在这个业务表中再存储一份，避免仅仅为了获得一个字段的数据就和巨大的其他表进行毫无顾忌的关联，你关联的条件越多，越复杂，最后的结果就是越慢，这是毫无疑问的事情。b. 根据不同的生产环境，改变视图更确切的是说SQL语句的执行计划，提升性能。c. 在应用程序中减少访问这个视图的次数，即减少工作流接口调用的次数。早期的工作流只有count和list两种类型的接口，为了获得业务大类是否存在这个业务需求，无奈也只能使用count接口的多次调用来完成，这样有多少个业务大类就得调用count接口多少遍，无疑是大大影响速度。改进版的工作流提供了ge

55、tSearchCondtion型接口，这个接口允许在一定尺度范围内自行写SQL语句的前半部分完成查询功能。这样原来的n个count接口的调用就可以变为一个group by语句完成了。特别的通过增加一个额外的getSearchCondtion接口，可以在group by的同时count出当前业务大类的数量，这样就可以把对count接口的一次调用也省掉了。仅仅需要调用一次getSearchCondtion接口，同时进行group by和count操作，再调用一次list接口就能够获得需要的数据。如果办件列表使用的是多次count接口，则程序必须进行修改，因为这种方案在数据量变大时极大的影响速度，且

56、多次count接口的程序中一般都有一种类型的并发问题，可能造成案卷乱窜的现象。是否对增加一个额外的getSearchCondtion接口可以选择进行，办件列表中已办件的需求比较混乱，很多项目都不同，因此补充接口的时候要注意保证新增的接口和原有的接口逻辑的一致性。2. 工作流使用WebLogic连接池时内存泄漏问题描述：工作流使用WebLogic连接池过长时间不重启中间件，则出现内存溢出错误。解决方案：替换最新的unieap-workflow-common.jar包，如果业务系统已经上线运行，觉得替换整个jar包风险比较大，可以尝试单独替换com.neusoft.uniflow.persistence.vender.DrmOracleOperation.class类，看问题是否解决，并测试其他功能有无错误。注意这个类至少有两个版本DrmOracleOperation.java.fc和DrmOra