软件项目维护方案参考示例.docx

软件项目维护方案参考示例812020年4月19日文档仅供参考，不当之处，请联系改正。 软件项目维护方案1. 项目背景及目标1.1. 项目背景在国家政策的指导和帮助下，信息化也越来越发挥出十分重要的作用。XXXX不断加大信息化管理工作力度，积极实施“上网工程”，大力推进全市局域网建设，加快办公自动化系统进程，信息技术在改革中发挥了重要的支撑作用，为充分发挥政府公共职能，促进依法理财、科学理财，提供了重要的信息技术保障。近年来建设各系统随着数据量的逐年增加，陆续出现了性能问题，有必要进行数据库系统的升级及性能优化，以确保应用系统的正常运行，为单位员工提供更好的信息服务。1.2. 项目目标 对各系统数据库进行补丁升级服务，安装补丁前制定详细的升级计划和应急回退计划。 完成各系统数据库的性能调优工作。 各业务持续性得到有效的保证。2. 需求分析XXXXXXX项目，我公司有多年的行业经验。具有对运维服务对象进行适时监测、指标分析、和及时修复的能力。Oracle 产品日常运行维护项目主要从如下几个方面进行：(1). 每天对ORACLE数据库的运行状态,日志文件,备份情况,数据库的空间使用情况,系统资源的使用情况进行查看,发现并解决问题。(2). 每周对数据库对象的空间扩展情况,数据的增长情况进行监控,对数据库做健康查看,对数据库对象的状态做查看。(3). 查看表空间碎片,提出下一步空间管理计划。对ORACLE数据库状态进行一次全面查看。（4）由于这些数据库系统承载着XXXX非常重要的业务系统数据，因此在日常维护中需要非常仔细，每周、每月、每季都需要有相应的巡检记录，需要详细记载以下一些内容：n 监控数据库对象的空间扩展情况n 监控数据量的增长情况n 系统健康查看，查看以下内容:n 数据库对象有效性查看n 查看是否有危害到安全策略的问题。n 查看 alert、Sqlnet 等日志并归档报错日志n 分析表和索引n 查看对数据库会产生危害的增长速度n 查看表空间碎片n 数据库性能调整n 预测数据库将来的性能n 调整和维护工作n 后续空间3. 整体运行维护服务方案3.1. Lifekeeper维护3.1.1. 验证 LifeKeeper 的安装查看已经安装的LifeKeeper软件包，能够使用命令：rpm qa|grep stee3.1.2. 启动 LifeKeepera)启动LifeKeeper 服务器进程如果当前您的系统没有运行 LifeKeeper 则在所有服务器上以root用户身份输入如下命令# /opt/LifeKeeper/bin/lkstartb)启动LifeKeeper GUI服务器进程同样以root用户运行命令# /opt/LifeKeeper/bin/lkGUIserver start 注意：以上命令只需运行一次，以后每次系统重新启动时，LifeKeeper会自动运行上述进程3.1.3. 有关的LifeKeeper软件的其它管理任务a)停止 LifeKeeper 服务如果需要在服务器上永久停止LifeKeeper服务，能够输入下列命令$LKROOT/bin/lkstop该命令同时会使所有LifeKeeper保护的资源处于退出服务状态，如果希望在停止LifeKeeper时保持资源/应用的运行，能够使用：$LKROOT/bin/lkstop -fb)查看 LifeKeeper 进程键入下列命令能够查看当前运行的所有 LifeKeeper 进程列表ps -ef | grep LifeKeeper3.1.4. 启动LifeKeeperGUI配置工具进入LifeKeeper GUI管理工具能够经过运行命令：/opt/LifeKeeper/bin/lkGUIapp则出现LifeKeeper登录界面：能够使用root用户登录，也能够使用新建的用户进行登录。3.1.5. 检测LifeKeeper 集群运行状态能够使用lcdstatus命令对LifeKeeper 集群的当前运行状态进行查看，命令格式：lcdstatus -q -d 该程序向 stdout 输出在LifeKeeper 资源层次配置状态和通信路径的状态.选项 -q 表示输出采用简略的形式（建议使用该选项）选项d 表示要查看的主机，缺X查看本机3.1.6. 管理 LifeKeeper 中的资源注意：如果能运行LifeKeeper GUI，则使用其提供菜单命令执行相应操作；在执行命令行启动/停止资源前，一定先使用lcdstatus命令确认资源的实际状态。a)启用资源(In-Service)能够使用命令：./perform_action -t -a restore将资源标记名所对应的资源在本机上投入服务（启动）。如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行的结果相当于执行了一次手工切换！如果该资源在命令使用前是处于停止状态（即在备机上执行本命令），则本命令执行的结果相当于执行了一次手工切换b)停止资源(out-of-service)能够使用命令：./perform_action -t -a remove将资源标记名所对应的资源在本机上停止服务。如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行不产生任何结果注意：n 在执行命令行前后，一定先使用lcdstatus命令确认资源的当前状态。n 命令停止/启动本地的资源n 命令中的是区分大小写的n 一定要等待命令完成，注意命令的输出。n 详细用法见在线帮助手册。3.2. SQL SERVER维护计算机系统各种软、硬件故障、用户误操作以及恶意破坏是不可避免的,这些影响到数据的正确性甚至造成数据损失、服务器崩溃等致命后果。数据库的备份对保证系统的可靠性具有重要的作用。下面会根据执行强度对维护任务及其相应的程序进行分类描述，执行强度用不同的时间间隔定义，包括每天、每周、每月和每季度，能够建立起良好的维护实务，确保SQL Server数据库性能和安全。3.2.1. 每天的例行维护任务需要数据库管理员密切关注的维护任务，最好每天都查看一下，这样能够确保系统的可靠性、可用性、运行性能和安全。每天的例行维护任务包括：1、查看是不是所有被请求的SQL Server服务都正常运行。2、查看日常备份日志中成功、警告或者失败记录。3、查看Windows事件日志有没有错误记录。4、查看SQL Server日志有没有安全警告记录，例如非法登录。5、执行完全备份或差异备份。6、在设置了完全恢复模型或大容量日恢复模型的数据库上执行事务日志备份任务。7、核实SQL Server作业没有失败。8、查看所有的数据库文件和事务日志具有合适的磁盘空间大小。9、至少要监控处理器、内存或者磁盘计数器没有出现瓶颈。3.2.2. 每周的例行维护任务关注程度稍逊于每天的例行维护任务，最好每周进行一次例行查看。每周的例行维护任务包括：1、执行完全备份或差异备份。2、查看以前执行的维护计划报告。3、查看数据库完整性。4、如果需要，执行收缩数据库任务。5、经过重新组织索引任务压缩聚集和非聚集表和视图。6、经过重新生成索引任务在数据页和索引页重新组织数据。7、更新所有用户表和系统表的统计信息8、清除备份、还原、SQL Server代理作业和维护计划等操作的历史数据。9、如果需要，手动增长数据库或事务日志文件10、清除执行维护计划残留下来的文件。3.2.3. 每月或每季度的维护任务有一些维护计划不需要执行得过于频繁，能够每个月或每个季度执行一次。可是请不要以为这些任务不需要天天执行就无足轻重，这些任务能够确保数据库环境的健康，因此不要轻视以下这些维护任务：1、在测试环境中执行备份还原操作。2、将历史数据归档。3、分析收集的性能统计数据，与基准值相比较。3、查看并更新维护文档。4、查看并安装最新的SQL Server补丁和补丁包。5、如果运行簇、数据库镜像或日志传送，则监测故障转移。6、验证备份和还原进程是否遵循已定义的服务等级协议。7、更新SQL Server构建指南。8、更新SQL Server灾难恢复文档。9、更新维护计划列表10、修改管理员口令。11、修改SQL Server服务帐户口令。3.3. WebLogic维护3.3.1. 性能调优3.3.1.1. 设定执行队列的溢出条件Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，而且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。经过启动管理控制台，在域（如：mydomain） 服务器 server实例（如：myserver） Execute Queue weblogic.kernel.Defalt 配置下面几项：队列长度：此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。队列长度阈值百分比：此值表示溢出条件，在此服务器指出队列溢出之前能够达到的队列长度大小的百分比。线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU和内存不是足够的高，尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。最大线程数：为了防止创立过多的线程数量，能够经过设定最大的线程数进行控制。在实际的应用场景中，应根据具体情况适当的调整以上参数。3.3.1.2. 设定队列监测行为Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态，Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态，能够经过Node Manager来自动关闭此服务器并重新启动它。具体请参考：Node Manager Capabilities文档。经过启动管理控制台，在域（如：mydomain） 服务器 server实例（如：myserver）配置 调整下可配置下面几项：阻塞线程最长时间：在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作600 秒后成为阻塞线程。阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了阻塞线程最长时间 字段中指定的时间长度的间隔时间(秒)。默认情况下，WebLogic Server 将此时间间隔设置为600 秒。3.3.1.2.1. 尽量使用本地IO库WebLogic Server有两套套接字复用器：Java版和本地库。采用小型本地库更有效,尽量激活Enable Native IO(默认),此时UNIX默认使用CPUs+1个线程,Window下为双倍CPU。如果系统不能加载本地库,将会抛出java.lang.UnsatisfiedLinkException,此时只能使用Java套接字复用器,能够调整socket readers 百分比,默认为33%。该参数能够在Console Server Tuning Configuration配置栏里设置，配置完，重新启动WebLogic Server即可。3.3.1.2.2. 调整默认执行线程数名称开发模式产品模式推荐个数Execute Queues 默认的执行线程为15默认的执行线程为25200在管理控制台修改默认执行队列线程数的步骤如下：n 如果管理服务器没有运行，先启动。n 访问管理控制台。n 展开左边面板的Servers 节点，显示Server列表。n 右击Server，在弹出菜单中选择View Execute Queues ，就会在右边面板显示有执行队列的表用来修改。n 注意：你只能修改默认的执行队列或者用户定义的执行队列。n 在Name列，直接点击默认执行队列名称，显示配置标签用来修改执行队列数。n 填下适当的线程数。n 点击Apply，保存刚才的修改。n 重启Server，使新的执行队列设置生效。3.3.1.3. JDBC调优3.3.1.3.1. 驱动程序类型选择Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。因此在一般情况下建议使用thin驱动3.3.1.3.2. 调节连接池初始容量和最大容量JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。一般我们在一个线程中使用一个连接,因此连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致；值等于WebLogic Server的执行线程数。3.3.1.3.3. 其它配置尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开3.3.1.4. WEB调优3.3.1.4.1. 调整WEB应用描述符WEB应用除代码之外的调优比较简单,仅仅是对一些WEB应用描述符的调整。首先关闭Session Monitoring Enabled,仅仅在Cluster环境下设置Session复制(优先使用内存复制),在保证应用正常运行的情况下,设置较短的Session超时时间。同时生产环境下无需查看Jsp和servlet：JSPPage Check Secs和Servlet Reload Check Secs均设为-1,关闭JSP Keep Generated 和JSP Verbose对性能也有帮助。另外，还能够对jsp进行预编译,有两种方法：激活precompile选项；使用weblogic.appc事先编译，建议采用后者。3.3.1.5. 其它调优设置3.3.1.5.1. WebLogic文件描述符大小调整首先设置WEB主机系统的ulimit参数为unlimited ，然后设置WebLogic中文件描述符的大小。在WL_HOME/bea/weblogic/common/bin中打开文件commEnv.sh，修改设置文件描述符大小的指令，将默认的：ulimit n 1024修改为：ulimit n 81923.3.2. 维护管理3.3.2.1. 启动weblogic servern 启动管理服务器：执行startAdmserver.shn 启动被管理服务器：执行startManagedWebLogic.sh servername adminurl3.3.2.2. 停止weblogic servern 停止被管理服务器：执行stopWebLogic.sh servernamen 启动被管理服务器：执行stopWebLogic.sh3.3.2.3. 登录和退出管理控制台n 管理服务器启动后能够在浏览器中登录管理控制台n 输入URL：http:/hostname:port/console或https:/hostname:port/consolel hostname：管理服务器的ip地址或DNS名l port：管理服务器监听的端口l 如果管理服务器启动时使用SSL，则使用https访问管理控制台n 在弹出的窗口“Console Login“中输入用户名和密码登录3.3.2.4. 性能监控n 查看性能参数l 登录控制台后点击Servers-servername-Monitoring-Performancen 参数分析n1)Idle Threads & Queue Length & Throughout正常情况下 idle threads 0 ，queue Length为0，Throughout呈不规则变化曲线，Memory Usage呈适度频度的锯齿变化曲线。一般来说，对于正常配置的生产环境（线程数50200），如果idle threads 0 ，则 queue length =0 ； B、反之，如果queue length0 ，则空闲线程数=0 ；n2)Memory Usage Memory Usage = totalMemory() freeMemory()内存使用曲线反应了JVM Heap内存使用的变化情况，能够结合其它三个值的变化情况来判断server工作情况；比较理想的状态是适当频度的各种锯齿变化，由于JVM GC多采用“stop the world”机制，也就是垃圾回收时其它处理将暂停，过度频繁的GC将明显降低server工作效率和性能表现。3.4. Oracle维护Oracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。能够说Oracle数据库系统是当前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的 适应高吞吐量的数据库解决方案。3.4.1. 数据库性能优化Oracle 性能管理既是一种艺术，也是一种科学。从实用角度讲，它能够分为两种类型，主动式和被动式性能管理。主动式性能管理涉及到特定系统实施初期的设计和开发，包括硬件选择、性能及容量规划，海量存储系统的选择， I-O子系统配置及优化，以及如何对不同组件进行定制，以满足 Oracle 数据库和应用系统的复杂要求。被动式性能管理涉及到现有环境中不同组件的性能评估、故障排除和 Oracle环境的优化。本文旨在探讨如何进行被动式性能调优，以便为 Oracle 性能调优提供必要的指导，从而避免仅仅经过重复尝试的方式进行性能调优，提高 Oracle性能管理的效率。因此 ORACLE 数据库性能恶化表现基本上都是用户响应时间比较长，须要用户长时间的等待。获得满意的用户响应时间有两个途径：一是减少系统服务时间，即提高数据库的吞吐量；二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。对于以上的两个问题，一般我们采用以下几个方面来进行改进：n 调整服务器内存分配。例如，能够根据数据库运行状况调整数据库系统全局区（SGA 区）的数据缓冲区、日志缓冲区和共享池的大小；还能够调整程序全局区（PGA 区）的大小。n 调整硬盘 I/O 问题，达到 I/O 负载均衡。n 调整运用程序结构设计。n 优化调整操作系统参数和使用资源管理器。n SQL 优化、诊断 latch 竞争、Rollback(undo) Segment 优化、提升 block的效率等等。3.4.1.1. 查看Oracle数据库性能查看 Oracle 数据库性能情况，包含：查看数据库的等待事件，查看死锁及处理，查看 cpu、I/O、内存性能，查看是否有僵死进程，查看行链接/迁移，定期做统计分析，查看缓冲区命中率，查看共享池命中率，查看排序区，查看日志ORACLE 产品日常运行维护年度服务项目缓冲区，总共十个部分。3.4.1.1.1. 查看数据库的等待事件set pages 80set lines 120col event for a40select sid,event,p1,p2,p3,WAIT_TIME,SECONDS_IN_WAIT from v$session_wait where event notlike SQL% and event not like rdbms%;如果数据库长时间持续出现大量像latch free，enqueue，buffer busy waits，db file sequential read，db file scattered read 等等待事件时，需要对其进行分析，可能存在问题的语句。3.4.1.1.2. 查看消耗CPU最高的进程SET LINE 240SET VERIFY OFFCOLUMN SID FORMAT 999COLUMN PID FORMAT 999COLUMN S_# FORMAT 999COLUMN USERNAME FORMAT A9 HEADING ORA USERCOLUMN PROGRAM FORMAT A29COLUMN SQL FORMAT A60COLUMN OSNAME FORMAT A9 HEADING OS USERSELECT P.PID PID,S.SID SID,P.SPID SPID,S.USERNAME USERNAME,S.OSUSER OSNAME,P.SERIAL#S_#,P.TERMINAL,P.PROGRAM PROGRAM,P.BACKGROUND,S.STATUS,RTRIM(SUBSTR(A.SQL_TEXT, 1,80) SQLFROM V$PROCESS P, V$SESSION S,V$SQLAREA A WHERE P.ADDR = S.PADDR ANDS.SQL_ADDRESS = A.ADDRESS (+) AND P.SPID LIKE %&1%;3.4.1.1.3. 查看碎片程度高的表SQL SELECT segment_name table_name,COUNT(*) extents FROM dba_segments WHERE ownerNOT IN (SYS, SYSTEM) GROUP BY segment_name HAVING COUNT(*)=(SELECT MAX(COUNT(*)FROM dba_segments GROUP BY segment_name);3.4.1.1.4. 查看表空间的 I/O比例SQLSELECT DF.TABLESPACE_NAME NAME,DF.FILE_NAME FILE,F.PHYRDS PYR, F.PHYBLKRDPBR,F.PHYWRTS PYW, F.PHYBLKWRT PBW FROM V$FILESTAT F, DBA_DATA_FILES DF WHEREF.FILE# = DF.FILE_ID ORDER BY DF.TABLESPACE_NAME;3.4.1.1.5. 查看文件系统的 I/O比例SQLSELECTSUBSTR(A.FILE#,1,2)#,SUBSTR(A.NAME,1,30)NAME,A.STATUS,A.BYTES,B.PHYRDS,B.PHYWRTS FROM V$DATAFILE A, V$FILESTAT B WHERE A.FILE# =B.FILE#;3.4.1.1.6. Disk Read最高的SQL语句的获取SQLSELECT SQL_TEXT FROM (SELECT * FROM V$SQLAREA ORDER BY DISK_READS)WHERE ROWNUM=5 desc;3.4.1.1.7. 查找前十条性能差的sqlSELECT * FROM (SELECT PARSING_USER_IDEXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS,SQL_TEXT FROM V$SQLAREA ORDER BY DISK_READS DESC)WHERE ROWNUM10 ;3.4.1.1.8. 等待时间最多的 5 个系统等待事件的获取SELECT * FROM (SELECT * FROM V$SYSTEM_EVENT WHERE EVENT NOT LIKE SQL% ORDER BYTOTAL_WAITS DESC) WHERE ROWNUM=5;3.4.1.1.9. 查看运行很久的SQLCOLUMN USERNAME FORMAT A12COLUMN OPNAME FORMAT A16COLUMN PROGRESS FORMAT A8SELECT USERNAME,SID,OPNAME,ROUND(SOFAR*100 / TOTALWORK,0) | % ASPROGRESS,TIME_REMAINING,SQL_TEXT FROM V$SESSION_LONGOPS , V$SQL WHERETIME_REMAINING 0 AND SQL_ADDRESS=ADDRESS AND SQL_HASH_VALUE = HASH_VALUE;3.4.1.1.10. 查看死锁及处理查询当前锁对象信息：col sid for 999999col username for a10col schemaname for a10col osuser for a16col machine for a16col terminal for a20col owner for a10col object_name for a30col object_type for a10select sid,serial#,username,SCHEMANAME,osuser,MACHINE,terminal,PROGRAM,owner,object_name,object_type,o.object_idfrom dba_objects o,v$locked_object l,v$session swhere o.object_id=l.object_id and s.sid=l.session_id;oracle 级 kill 掉该 session：alter system kill session &sid,&serial#;操作系统级 kill 掉 session：#kill -9 pid3.4.1.1.11. 查看数据库cpu、I/O、内存性能记录数据库的 cpu 使用、IO、内存等使用情况，使用 vmstat,iostat,sar,top等命令进行信息收集并查看这些信息，判断资源使用情况。n CPU 使用情况：rootsale8 # toptop - 10:29:35 up 73 days, 19:54, 1 user, load average: 0.37, 0.38, 0.29Tasks: 353 total, 2 running, 351 sleeping, 0 stopped, 0 zombie Cpu(s): 1.2% us, 0.1% sy, 0.0% ni, 98.8% id,0.0% wa, 0.0% hi, 0.0% si Mem: 16404472k total, 12887428k used, 3517044k free, 60796k buffersSwap: 8385920k total, 665576k used, 7720344k free, 10358384k cached PID USER30495 oracle32501 oracle32503 oracle注意上面的加粗字体部分，此部分内容表示系统剩余的 cpu，当其平均值下降至 10%以下的时视为 CPU 使用率异常，需记录下该数值，并将状态记为异常n 内存使用情况：# free -m TotalusedfreesharedbufferscachedMem:202656-/+ buffers/cache: 326 1700Swap: 5992 92 5900如上所示，total表示系统总内存，used表示系统使用的内存，free表示系统剩余内存，当剩余内存低于总内存的 10%时视为异常。n 系统负载情况：#uptime 12:08:37 up 162 days, 23:33, 15 users,load average: 0.01, 0.15, 0.10如上所示，load average部分表示系统负载，后面的 3 个数值如果有高于 2.5 的时候就表明系统在超负荷运转了，并将此值记录到巡检表，视为异常。3.4.1.1.12. 查看是否有僵死进程select spid from v$process where addr not in (select paddr from v$session);有些僵尸进程有阻塞其它业务的正常运行，定期杀掉僵尸进程。3.4.1.1.13. 查看行链接/迁移Sqlselect table_name,num_rows,chain_cnt From dba_tables Where owner=CTAIS2 Andchain_cnt0;注：含有 long raw 列的表有行链接是正常的 ,找到迁移行保存到chained_rows 表中 , 如没有该表执行 ./rdbms/admin/utlchain.sqlSqlanalyze table tablename list chained rows;可经过表 chained_rows 中table_name,head_rowid看出哪些行是迁移行如:Sqlcreate table aa as selecta.* from sb_zsxx a,chained_rows b where a.rowid=b.head_rowid andb.table_name =SB_ZSXX; sqldelete from sb_zsxx where rowid in (selecthead_rowid from chained_rows where table_name = SB_ZSXX); sqlinsertinto sb_zsxx select * from chained_row where table_name = SB_ZSXX;3.4.1.1.14. 定期做统计分析对于采用 Oracle Cost-Based-Optimizer 的系统，需要定期对数据对象的统计信息进行采集更新，使优化器能够根据准备的信息作出正确的 explain plan。在以下情况更需要进行统计信息的更新：应用发生变化；大规模数据迁移、历史数据迁出、其它数据的导入等；数据量发生变化。查看表或索引的统计信息是否需更新，如：SqlSelect table_name,num_rows,last_analyzed From user_tables wheretable_name =DJ_NSRXXsqlselect count(*) from DJ_NSRXX 如 num_rows 和 count(*)如果行数相差很多,则该表需要更新统计信息，建议一周做一次统计信息收集，如：Sqlexec sys.dbms_stats.gather_schema_stats(ownname=CTAIS2,cascade=TRUE,degree = 4);3.4.1.1.15. 查看日志缓冲区SQL select name,value from v$sysstat where name in (redo entries,redo buffer allocationretries);如果 redo buffer allocation retries/redo entries 超过 1% ，则需要增大 log_buffer。3.4.1.2. 性能调优及方法性能调优主要有主动调优和被动调优，主动调优在前面我们已经进行了阐述，被动调优主要有以下方法进行。n 确定合理的性能优化目标n 测试并记录当前的性能指标n 确定当前存在的 Oracle 性能瓶颈 (Oracle 中何处存在等待，哪个 SQL语句与此有关)n 确定当前的操作系统瓶颈n 优化相关的组件 (应用、数据库、I/O、连接 OS 及其它)n 跟踪并实施变化管理制度n 测试并记录当前的性能指标n 重复第 3 到第 7 步直至达到既定的优化目标不要对并非性能瓶颈的部分进行优化，否则可能引起额外的问题。正如任何聪明的人会告诉你的：“如果还未坏，千万不要修”。更重要的是，一旦既定的优化目标已经达到，就务必停止所有的优化。获取 Oracle 的性能指标 (测试前及测试后)必须在峰值处理时测试并获取系统在优化前和优化后的性能指标。数据采集不应在数据库 instance 刚刚起动后进行。同时，测试数据应在峰值期间每过 15 分钟进行一次。初始化参数TIMED_STATISTICS 应该被设为 TRUE。经过运行以下脚本开始快照：$ORACLE_HOME/rdbms/admin/utlbstat.sql.经过运行以下脚本结束快照：$ORACLE_HOME/rdbms/admin/utlestat.sql.完成 utlestat.sql 操作后，会在当前目录中生成名为“report.txt”的文件，包含系统的性能数据。该报告包括每 15 分钟捕获的所有与 Oracle 例程相关的参数。3.4.1.2.1. 寻找问题根源如上所述，经过查看 v$system_event 事件开始系统事件的问题诊断。下一步是查看 v$session_event，找出引起或经历等待事件的进程。最后一步是经过v$session_wait 获得事件的细节。同时，应该进一步经过 OS 进行深入分析，了解核心的 CPU、内存和 IO 状态参数。最后，结合两种不同的诊断的结论，找出系统瓶颈所在。3.4.1.2.2. 应用优化从统计(和现实) 的角度看，80% 的 Oracle 系统性能问题能够经过 SQL 代码优化来解决。任何应用优化的过程，