软件项目维护方案示例

1、-. z.软件工程维护方案工程背景及目标工程背景在国家政策的指导和帮助下，信息化也越来越发挥出十分重要的作用。*不断加大信息化管理工作力度，积极实施上网工程，大力推进全市局域网建立，加快办公自动化系统进程，信息技术在改革中发挥了重要的支撑作用，为充分发挥政府公共职能，促进依法理财、科学理财，提供了重要的信息技术保障。近年来建立各系统随着数据量的逐年增加，陆续出现了性能问题，有必要进展数据库系统的升级及性能优化，以确保应用系统的正常运行，为单位员工提供更好的信息效劳。工程目标对各系统数据库进展补丁升级效劳，安装补丁前制定详细的升级方案和应急回退方案。完成各系统数据库的性能调优工作。各业务持续性得

2、到有效的保证。需求分析*工程，我公司有多年的行业经历。具有对运维效劳对象进展适时监测、指标分析、和及时修复的能力。Oracle 产品日常运行维护工程主要从如下几个方面进展：(1). 每天对ORACLE数据库的运行状态,日志文件,备份情况,数据库的空间使用情况,系统资源的使用情况进展查看,发现并解决问题。(2). 每周对数据库对象的空间扩展情况,数据的增长情况进展监控,对数据库做安康查看,对数据库对象的状态做查看。(3). 查看表空间碎片,提出下一步空间管理方案。对ORACLE数据库状态进展一次全面查看。4由于这些数据库系统承载着*非常重要的业务系统数据，所以在日常维护中需要非常仔细，每周、每月

3、、每季都需要有相应的巡检记录，需要详细记载以下一些容：监控数据库对象的空间扩展情况监控数据量的增长情况系统安康查看，查看以下容:数据库对象有效性查看查看是否有危害到平安策略的问题。查看 alert、Sqlnet 等日志并归档报错日志分析表和索引查看对数据库会产生危害的增长速度查看表空间碎片数据库性能调整预测数据库将来的性能调整和维护工作后续空间整体运行维护效劳方案Lifekeeper维护验证 LifeKeeper 的安装查看已经安装的LifeKeeper软件包，可以使用命令：rpm qa|grep stee启动 LifeKeepera)启动LifeKeeper 效劳器进程如果当前您的系统没有运

4、行 LifeKeeper 则在所有效劳器上以root用户身份输入如下命令# /opt/LifeKeeper/bin/lkstartb)启动LifeKeeper GUI效劳器进程同样以root用户运行命令# /opt/LifeKeeper/bin/lkGUIserver start 注意：以上命令只需运行一次，以后每次系统重新启动时，LifeKeeper会自动运行上述进程有关的LifeKeeper软件的其它管理任务a)停顿 LifeKeeper 效劳如果需要在效劳器上永久停顿LifeKeeper效劳，可以输入以下命令$LKROOT/bin/lkstop该命令同时会使所有LifeKeeper保护的

5、资源处于退出效劳状态，如果希望在停顿LifeKeeper时保持资源/应用的运行，可以使用：$LKROOT/bin/lkstop -fb)查看 LifeKeeper 进程键入以下命令可以查看当前运行的所有 LifeKeeper 进程列表ps -ef | grep LifeKeeper启动LifeKeeperGUI配置工具进入LifeKeeper GUI管理工具可以通过运行命令：/opt/LifeKeeper/bin/lkGUIapp则出现LifeKeeper登录界面：可以使用root用户登录，也可以使用新建的用户进展登录。检测LifeKeeper 集群运行状态可以使用lcdstatus命令对Li

6、feKeeper 集群的当前运行状态进展查看，命令格式：lcdstatus -q -d 该程序向 stdout 输出在LifeKeeper 资源层次配置状态和通信路径的状态.选项 -q 表示输出采用简单的形式建议使用该选项选项d 表示要查看的主机，缺*查看本机管理 LifeKeeper 中的资源注意：如果能运行LifeKeeper GUI，则使用其提供菜单命令执行相应操作；在执行命令行启动/停顿资源前，一定先使用lcdstatus命令确认资源的实际状态。a)启用资源(In-Service)可以使用命令：./perform_action -t -a restore将资源标记名所对应的资源在本机上

7、投入效劳启动。如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行的结果相当于执行了一次手工切换！如果该资源在命令使用前是处于停顿状态即在备机上执行本命令，则本命令执行的结果相当于执行了一次手工切换b)停顿资源(out-of-service)可以使用命令：./perform_action -t -a remove将资源标记名所对应的资源在本机上停顿效劳。如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行不产生任何结果注意：在执行命令行前后，一定先使用lcdstatus命令确认资源的当前状态。命令停顿/启动本地的资源命令中的是区分大小写的一定要等待命令完成，注意命令

8、的输出。详细用法见在线帮助手册。SQL SERVER维护计算机系统各种软、硬件故障、用户误操作以及恶意破坏是不可防止的,这些影响到数据的正确性甚至造成数据损失、效劳器崩溃等致命后果。数据库的备份对保证系统的可靠性具有重要的作用。下面会根据执行强度对维护任务及其相应的程序进展分类描述，执行强度用不同的时间间隔定义，包括每天、每周、每月和每季度，能够建立起良好的维护实务，确保SQL Server数据库性能和平安。每天的例行维护任务需要数据库管理员密切关注的维护任务，最好每天都查看一下，这样可以确保系统的可靠性、可用性、运行性能和平安。每天的例行维护任务包括：1、查看是不是所有被请求的SQL Ser

9、ver效劳都正常运行。2、查看日常备份日志中成功、警告或者失败记录。3、查看Windows事件日志有没有错误记录。4、查看SQL Server日志有没有平安警告记录，例如非法登录。5、执行完全备份或差异备份。6、在设置了完全恢复模型或大容量日恢复模型的数据库上执行事务日志备份任务。7、核实SQL Server作业没有失败。8、查看所有的数据库文件和事务日志具有适宜的磁盘空间大小。9、至少要监控处理器、存或者磁盘计数器没有出现瓶颈。每周的例行维护任务关注程度稍逊于每天的例行维护任务，最好每周进展一次例行查看。每周的例行维护任务包括：1、执行完全备份或差异备份。2、查看以前执行的维护方案报告。3、

10、查看数据库完整性。4、如果需要，执行收缩数据库任务。5、通过重新组织索引任务压缩聚集和非聚集表和视图。6、通过重新生成索引任务在数据页和索引页重新组织数据。7、更新所有用户表和系统表的统计信息8、去除备份、复原、SQL Server代理作业和维护方案等操作的历史数据。9、如果需要，手动增长数据库或事务日志文件10、去除执行维护方案残留下来的文件。每月或每季度的维护任务有一些维护方案不需要执行得过于频繁，可以每个月或每个季度执行一次。但是请不要以为这些任务不需要天天执行就无足轻重，这些任务可以确保数据库环境的安康，所以不要轻视以下这些维护任务：1、在测试环境中执行备份复原操作。2、将历史数据归档

11、。3、分析收集的性能统计数据，与基准值相比拟。3、查看并更新维护文档。4、查看并安装最新的SQL Server补丁和补丁包。5、如果运行簇、数据库镜像或日志传送，则监测故障转移。6、验证备份和复原进程是否遵循已定义的效劳等级协议。7、更新SQL Server构建指南。8、更新SQL Server灾难恢复文档。9、更新维护方案列表10、修改管理员口令。11、修改SQL Server效劳口令。WebLogic维护性能调优设定执行队列的溢出条件Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，效劳器改变其状态为警告状态，并且额外的再分配

12、一些线程去处理在队列中的请求，而到达降低队列长度的目的。通过启动管理控制台，在域如：mydomain 效劳器 server实例如：myserver E*ecute Queue weblogic.kernel.Defalt 配置下面几项：队列长度：此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。队列长度阈值百分比：此值表示溢出条件，在此效劳器指出队列溢出之前可以到达的队列长度大小的百分比。线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU和存不是足够的高，尽量不要改变默认值0。因为Weblogic一旦增加后不会自动缩减，虽然最终可能确实起到了

13、降低请求的作用，但在将来的运行中将影响程序的性能。最大线程数：为了防止创立过多的线程数量，可以通过设定最大的线程数进展控制。在实际的应用场景中，应根据具体情况适当的调整以上参数。设定队列监测行为Weblogic Server能够自动监测到当一个执行线程变为阻塞。变为阻塞状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为阻塞状态，Weblogic server可能改变状态为警告或严重状态。如果Weblogic server变为严重状态，可以通过Node Manager来自动关闭此效劳器并重新启动它。具体请参考：Node Manager Capabiliti

14、es文档。通过启动管理控制台，在域如：mydomain 效劳器 server实例如：myserver配置 调整下可配置下面几项：阻塞线程最长时间：在此效劳器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作600 秒后成为阻塞线程。阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了阻塞线程最长时间 字段中指定的时间长度的间隔时间(秒)。默认情况下，WebLogic Server 将此时间间隔设置为600 秒。尽量使用本地IO库WebLogic Server有两套套接字复用器：Jav

15、a版和本地库。采用小型本地库更有效,尽量激活Enable Native IO(默认),此时UNI*默认使用CPUs+1个线程,Window下为双倍CPU。如果系统不能加载本地库,将会抛出java.lang.UnsatisfiedLinkE*ception,此时只能使用Java套接字复用器,可以调整socket readers 百分比,默认为33%。该参数可以在Console Server Tuning Configuration配置栏里设置，配置完，重新启动WebLogic Server即可。调整默认执行线程数名称开发模式产品模式推荐个数E*ecute Queues 默认的执行线程为15默认的

16、执行线程为25200在管理控制台修改默认执行队列线程数的步骤如下：如果管理效劳器没有运行，先启动。访问管理控制台。展开左边面板的Servers 节点，显示Server列表。右击Server，在弹出菜单中选择View E*ecute Queues ，就会在右边面板显示有执行队列的表用来修改。注意：你只能修改默认的执行队列或者用户定义的执行队列。在Name列，直接点击默认执行队列名称，显示配置标签用来修改执行队列数。填下适当的线程数。点击Apply，保存刚刚的修改。重启Server，使新的执行队列设置生效。JDBC调优驱动程序类型选择Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱

17、动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改良,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动调节连接池初始容量和最大容量JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为防止两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致；值等于WebLogic Server的执行线程数。其他配置尽管J

18、DBC Connection Pool提供了很多高级参数,在开发模式下比拟有用,但大局部在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数翻开WEB调优调整WEB应用描述符WEB应用除代码之外的调优比拟简单,仅仅是对一些WEB应用描述符的调整。首先关闭Session Monitoring Enabled,仅仅在Cluster环境下设置Session复制(优先使用存复制),在保证应用正常运行的情况下,设置较短的Sessi

19、on超时时间。同时生产环境下无需查看Jsp和servlet：JSPPage Check Secs和Servlet Reload Check Secs均设为-1,关闭JSP Keep Generated 和JSP Verbose对性能也有帮助。此外，还可以对jsp进展预编译,有两种方法：激活prepile选项；使用weblogic.appc事先编译，建议采用后者。其他调优设置WebLogic文件描述符大小调整首先设置WEB主机系统的ulimit参数为unlimited ，然后设置WebLogic中文件描述符的大小。在WL_HOME/bea/weblogic/mon/bin中翻开文件mEnv.sh

20、，修改设置文件描述符大小的指令，将默认的：ulimit n 1024修改为：ulimit n 8192维护管理启动weblogic server启动管理效劳器：执行startAdmserver.sh启动被管理效劳器：执行startManagedWebLogic.sh servername adminurl停顿weblogic server停顿被管理效劳器：执行stopWebLogic.sh servername启动被管理效劳器：执行stopWebLogic.sh登录和退出管理控制台管理效劳器启动后可以在浏览器中登录管理控制台输入URL：hostname:port/console或 s:/hos

21、tname:port/consolehostname：管理效劳器的ip地址或DNS名port：管理效劳器监听的端口如果管理效劳器启动时使用SSL，则使用 s访问管理控制台在弹出的窗口Console Login中输入用户名和密码登录性能监控查看性能参数登录控制台后点击Servers-servername-Monitoring-Performance参数分析1)Idle Threads & Queue Length & Throughout正常情况下 idle threads 0 ，queue Length为0，Throughout呈不规则变化曲线，Memory Usage呈适度频度的锯齿变化曲线

22、。一般来说，对于正常配置的生产环境线程数50200，如果idle threads 0 ，则 queue length =0 ； B、反之，如果queue length0 ，则空闲线程数=0 ；2)Memory Usage Memory Usage = totalMemory() freeMemory()存使用曲线反响了JVM Heap存使用的变化情况，可以结合其他三个值的变化情况来判断server工作情况；比拟理想的状态是适当频度的各种锯齿变化，由于JVM GC多采用stop the world机制，也就是垃圾回收时其他处理将暂停，过度频繁的GC将明显降低server工作效率和性能表现。Ora

23、cle维护Oracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的适应高吞吐量的数据库解决方案。数据库性能优化Oracle 性能管理既是一种艺术，也是一种科学。从实用角度讲，它可以分为两种类型，主动式和被动式性能管理。主动式性能管理涉及到特定系统实施初期的设计和开发，包括硬件选择、性能及容量规划，海量存储系统的选择， I-O子系统配置及

24、优化，以及如何对不同组件进展定制，以满足 Oracle 数据库和应用系统的复杂要求。被动式性能管理涉及到现有环境中不同组件的性能评估、故障排除和 Oracle环境的优化。本文旨在探讨如何进展被动式性能调优，以便为 Oracle 性能调优提供必要的指导，从而防止仅仅通过反复尝试的方式进展性能调优，提高 Oracle性能管理的效率。所以 ORACLE 数据库性能恶化表现根本上都是用户响应时间比拟长，须要用户长时间的等待。获得满意的用户响应时间有两个途径：一是减少系统效劳时间，即提高数据库的吞吐量；二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。对于以上的两个问题，通常我们采用以下几个方

25、面来进展改善：调整效劳器存分配。例如，可以根据数据库运行状况调整数据库系统全局区SGA 区的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区PGA 区的大小。调整硬盘 I/O 问题，到达 I/O 负载均衡。调整运用程序构造设计。优化调整操作系统参数和使用资源管理器。SQL 优化、诊断 latch 竞争、Rollback(undo) Segment 优化、提升 block的效率等等。查看Oracle数据库性能查看 Oracle 数据库性能情况，包含：查看数据库的等待事件，查看死锁及处理，查看 cpu、I/O、存性能，查看是否有僵死进程，查看行/迁移，定期做统计分析，查看缓冲区命中率，查

26、看共享池命中率，查看排序区，查看日志ORACLE 产品日常运行维护年度效劳工程缓冲区，总共十个局部。查看数据库的等待事件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

27、，db file scattered read 等等待事件时，需要对其进展分析，可能存在问题的语句。查看消耗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

28、 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_TE*T, 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%;查看碎片程度高的表SQL SELECT segment_na

29、me table_name,COUNT(*) e*tents FROM dba_segments WHERE ownerNOT IN (SYS, SYSTEM) GROUP BY segment_name HAVING COUNT(*)=(SELECT MA*(COUNT(*)FROM dba_segments GROUP BY segment_name);查看表空间的 I/O比例SQLSELECT DF.TABLESPACE_NAME NAME,DF.FILE_NAME FILE,F.PHYRDS PYR, F.PHYBLKRDPBR,F.PHYWRTS PYW, F.PHYBLKWRT P

30、BW FROM V$FILESTAT F, DBA_DATA_FILES DF WHEREF.FILE# = DF.FILE_ID ORDER BY DF.TABLESPACE_NAME;查看文件系统的 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#;Disk Read最高的SQL语句的获取SQLSELECT SQL_TE*T FROM (SEL

31、ECT * FROM V$SQLAREA ORDER BY DISK_READS)WHERE ROWNUM=5 desc;查找前十条性能差的sqlSELECT * FROM (SELECT PARSING_USER_IDE*ECUTIONS,SORTS,MAND_TYPE,DISK_READS,SQL_TE*T FROM V$SQLAREA ORDER BY DISK_READS DESC)WHERE ROWNUM10 ;等待时间最多的 5 个系统等待事件的获取SELECT * FROM (SELECT * FROM V$SYSTEM_EVENT WHERE EVENT NOT LIKE SQ

32、L% ORDER BYTOTAL_WAITS DESC) WHERE ROWNUM=5;查看运行很久的SQLCOLUMN USERNAME FORMAT A12COLUMN OPNAME FORMAT A16COLUMN PROGRESS FORMAT A8SELECT USERNAME,SID,OPNAME,ROUND(SOFAR*100 / TOTALWORK,0) | % ASPROGRESS,TIME_REMAINING,SQL_TE*T FROM V$SESSION_LONGOPS , V$SQL WHERETIME_REMAINING 0 AND SQL_ADDRESS=ADDRE

33、SS AND SQL_HASH_VALUE = HASH_VALUE;查看死锁及处理查询目前锁对象信息：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,PROGR

34、AM,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 pid查看数据库cpu、I/O、存性能记录数据库的 cpu 使用、IO、存等使用情况，使用 vmstat,iostat,

35、sar,top等命令进展信息收集并查看这些信息，判断资源使用情况。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,

36、3517044k free, 60796k buffersSwap: 8385920k total, 665576k used, 7720344k free, 10358384k cached PID USER30495 oracle32501 oracle32503 oracle注意上面的加粗字体局部，此局部容表示系统剩余的 cpu，当其平均值下降至 10%以下的时视为 CPU 使用率异常，需记录下该数值，并将状态记为异常存使用情况：# free -m TotalusedfreesharedbufferscachedMem:-/+ buffers/cache: 326 1700Swap: 5

37、992 92 5900如上所示，total表示系统总存，used表示系统使用的存，free表示系统剩余存，当剩余存低于总存的 10%时视为异常。系统负载情况：#uptime 12:08:37 up 162 days, 23:33, 15 users,load average: 0.01, 0.15, 0.10如上所示，load average局部表示系统负载，后面的 3 个数值如果有高于 2.5 的时候就说明系统在超负荷运转了，并将此值记录到巡检表，视为异常。查看是否有僵死进程select spid from v$process where addr not in (select paddr

38、from v$session);有些僵尸进程有阻塞其他业务的正常运行，定期杀掉僵尸进程。查看行/迁移Sqlselect table_name,num_rows,chain_t From dba_tables Where owner=CTAIS2 Andchain_t0;注：含有 long raw 列的表有行是正常的 ,找到迁移行保存到chained_rows 表中 , 如没有该表执行 ./rdbms/admin/utlchain.sqlSqlanalyze table tablename list chained rows;可通过表 chained_rows 中table_name,head_

39、rowid看出哪些行是迁移行如:Sqlcreate table aa as selecta.* from sb_zs* a,chained_rows b where a.rowid=b.head_rowid andb.table_name =SB_ZS*; sqldelete from sb_zs* where rowid in (selecthead_rowid from chained_rows where table_name = SB_ZS*); sqlinsertinto sb_zs* select * from chained_row where table_name = SB_Z

40、S*;定期做统计分析对于采用 Oracle Cost-Based-Optimizer 的系统，需要定期对数据对象的统计信息进展采集更新，使优化器可以根据准备的信息作出正确的 e*plain plan。在以下情况更需要进展统计信息的更新：应用发生变化；大规模数据迁移、历史数据迁出、其他数据的导入等；数据量发生变化。查看表或索引的统计信息是否需更新，如：SqlSelect table_name,num_rows,last_analyzed From user_tables wheretable_name =DJ_NSR*sqlselect count(*) from DJ_NSR* 如 num_r

41、ows 和 count(*)如果行数相差很多,则该表需要更新统计信息，建议一周做一次统计信息收集，如：Sqle*ec sys.dbms_stats.gather_schema_stats(ownname=CTAIS2,cascade=TRUE,degree = 4);查看日志缓冲区SQL select name,value from v$sysstat where name in (redo entries,redo buffer allocationretries);如果 redo buffer allocation retries/redo entries 超过 1% ，则需要增大 log

42、_buffer。性能调优及方法性能调优主要有主动调优和被动调优，主动调优在前面我们已经进展了阐述，被动调优主要有以下方法进展。确定合理的性能优化目标测试并记录当前的性能指标确定当前存在的 Oracle 性能瓶颈 (Oracle 中何处存在等待，哪个 SQL语句与此有关)确定当前的操作系统瓶颈优化相关的组件 (应用、数据库、I/O、连接 OS 及其它)跟踪并实施变化管理制度测试并记录目前的性能指标重复第 3 到第 7 步直至到达既定的优化目标不要对并非性能瓶颈的局部进展优化，否则可能引起额外的问题。正如任何聪明的人会告诉你的：如果还未坏，千万不要修。更重要的是，一旦既定的优化目标已经到达，就务必

43、停顿所有的优化。获取 Oracle 的性能指标 (测试前及测试后)必须在峰值处理时测试并获取系统在优化前和优化后的性能指标。数据采集不应在数据库 instance 刚刚起动后进展。同时，测试数据应在峰值期间每过 15 分钟进展一次。初始化参数TIMED_STATISTICS 应该被设为 TRUE。通过运行以下脚本开场快照：$ORACLE_HOME/rdbms/admin/utlbstat.sql.通过运行以下脚本完毕快照：$ORACLE_HOME/rdbms/admin/utlestat.sql.完成 utlestat.sql 操作后，会在当前目录中生成名为report.t*t的文件，包含系统

44、的性能数据。该报告包括每 15 分钟捕获的所有与 Oracle 例程相关的参数。寻找问题根源如上所述，通过查看 v$system_event 事件开场系统事件的问题诊断。下一步是查看 v$session_event，找出引起或经历等待事件的进程。最后一步是通过v$session_wait 获得事件的细节。同时，应该进一步通过 OS 进展深入分析，了解核心的 CPU、存和 IO 状态参数。最后，结合两种不同的诊断的结论，找出系统瓶颈所在。应用优化从统计(和现实) 的角度看，80% 的 Oracle 系统性能问题可以通过 SQL 代码优化来解决。任何应用优化的过程，不外乎是索引优化、全表扫描、并行

45、机制改良和选择正确数据组合方法的过程。这正是要到达最正确应用性能所必须考虑的因素。没有 SQL 的优化，就无法实现高性能的应用。良好的 SQL 语句可以减少 CPU资源的消耗，提高响应速度。同时，优化后的 SQL 语句还可以提高应用的可扩展性，这是除增加大量存外，任何其它硬件手段也无法实现的。I-O 优化I-O 优化是系统优化中的一个关键步骤，还涉及到其它任务，将文件在不同驱动器/卷中进展分布，采用优化分区技术、确定 I-O 子系统瓶颈、确定控制器瓶颈并根据应用的类型选择最正确的 RAID 级。I-O 优化应该在全面了解 Oracle 及Oracle RDBMS 构造之后进展。应该在进展 I-

46、O 优化前后实施 I-O 数据监控，如平均效劳时间，IOPS，平均磁盘队列长度等。O-S监控数据库忙时，应该对操作系统进展监控，因为操作系统的性能指标会提醒数据库活动的性质及其对系统的影响。例如，为了了解 CPU 的利用率，可以通过system activity reporter (sar u interval frequency) 、 mpstat (SunSolaris), top (多数 UNI*)、 osview (SGI Iri*) 及 vmstat 等命令。Sar 和vmstat 也可被用于确定包括存使用率、I-O 参数、队列等待、读取/交换区活动等信息。在 Solaris 上，m

47、pstat utility 也可用于获取前面提到的 CPU 利用率数据。Solaris 上的 Adrian 性能管理工具也很有用。可以利用其中的一到多个工具来确定系统的性能状况，找出可能存在的瓶颈。Oracle 数据库性能的管理需要遵循系统的方法论，以确保所有核心问题得以解决。多数问题可以事先得以管理。了解与 O-S 相关的问题是成功的关键。勿需置疑，系统硬件配置上的良好平衡也是至关重要的。必须成认， 80% 的系统性能问题可以通过书写更好的 SQL 语句来解决。来文试图探究其余 20%中可能覆盖的容。同时，必须遵守严格的规定，在调优目标到达后终止所有努力。了解自己想到何处是重要的，更重要的是

48、，要知道自己何时到达了目的地。例程调优需要配置的主要初始化参数以下是一些与例程优化关系最密切的一些核心 Oracle 初始化参数。它们都会影响 Oracle 及 SGA 区的活动。任何对这些参数的改动，在实施到生产环境之前，都必须进展测试。一旦改变了生产环境的参数，就必须对相关的 Oracle动态性能指标和操作系统的性能进展监测，寻找可能由此产生的异常现象。1) DB_BLOCK_SIZE该参数在数据库建立前设定，决定了数据库中每个数据块的大小。只有重新建立数据库，才有可能改变该参数。db_block_size 的配置应遵循以下公式：DB_BLOCK_SIZE = FILESYSTEM BLO

49、CKSIZE = O-S PAGESIZE 这可以确保 Oracle获得最正确 I/O 性能，同时不会由于冗余或不必要的 I/O，给 I/O 子系统带来压力。2) DB_BLOCK_BUFFERS该参数决定了 SGA 区数据库缓冲区中的块数量。由于这是 Oracle 读取和写入的区域，它的不正确配置会引起严重的 I/O 性能问题。尽管缓冲区的大小与应用性质、数据库大小、同步用户数等无关，它确实是 SGA 区中最大的组件。经常可以看到缓冲区占用 75-80%SGA 区存的情况。另外，这一参数设置过大，也会引起整个系统的存缺乏，引起操作系统过多的读写操作。该参数及 SHARED_POOL_SIZE

50、 通常是两个最重要的 SGA 优化目标。只有当数据库缓冲率长时间低于 70%时，才需要增加其大小说。即使在这种情况下，也需要进一步审查应用的性能和整个系统的吞吐性。假设存在延迟性的应用设计问题，则无论数据库缓冲区的大小如何，缓冲和读写率都不会有太大改变为。在实调优中，也曾发现由于 SQL 语句的问题，出现缓冲率很高，但仍存在全系统性能问题的情况。3)SHARED_POOL_SIZE该参数按字节数设定，定义了 SGA 中共享区的大小。该组件的大小严重依赖于应用的类型 (即该应用是重用 SQL，还是生成动态 SQL，等等)。同时它也取决于同步用户的数量，以及实例是否被配置成支持多线程效劳器(MTS

51、)。如果该应用采用了 MTS 配置，则共享区应该明显增加，因为光标状态和用户进程数据等程序全局区域(PGA)都被置入了共享区。有关多数应用的 SHARED_POOL_SIZE 大小设置，可以从每 10 个同步用户 16 MB共享区开场。这不是一成不变的，因为应用的性质最终会决定该组件的大小。只有当库缓冲和字典缓冲使用率一直低于 90%时，才需要关注这一参数。但如果应用并未采用变量合并和/共离图标时，存的数量并不会使缓冲使用率高于 90%。共享区过大会导致处理时间增加，甚至 SQL 语句的挂起。如果应用不能有效地重用 SQL，则无论配置多大的库缓冲或字典缓冲都无济于事，不能改善缓冲使用率。另一个

52、值得考虑的因素是需要随时使用的存储 PL/SQL 代码数量。应用的核心包可以通过查看 DBA_SOURCE、USER_SOURCE 得以确认，其大小通过查询DBA_OBJECT_SIZE 了解。另外，为了确定存储 PL/SQL 是否被置于存，可以查询动态性能视图 V$DB_OBJECT_SIZE。时，包 DBMS_SHARED_POOL 中的程序大小可被用于确定应用包的规模。4) LOG_BUFFER根据字节设定，该参数定义了 SGA 缓冲区中 redo log 的大小。缺*值通常是数据库块大小的四倍，这对于多数环境并不是最正确的。对于中型的 Oracle 环境，其构造应该为 512 Kb 左

53、右。对该存储构造而言，更大并不意味着更好。超过 1 MB 就可能有问题。需要监控 V$SESSION_WAIT 中 log buffer space 的等待事件，优化该存构造。需要提醒的是，在线 redo log 文件的大小设置不当，会引起 redo 请求的等待。5) DB_WRITERS该参数可以针对所有文件系统支持，且不可使用 Direct I-O 的 Oracle 实施设定。这并不需要与 raw partitions 一起使用，因为异步 I-O 更加。建议将该参数设定为(2 * 独立磁盘驱动器数量/卷)。该参数只有在 report.t*t 中的average write queue le

54、ngth持续高于 1 时，才需要设定。在 Oracle 8.0 和更高版本中，该参数已不再被支持，而为其它两个名为 DB_WRITER_PROCESSES 和DBWR_IO_SLAVES 的参数取代。假设需要设置 DB_WRITER_PROCESSES 值高于 8，则DB_WRITER_PROCESSES 可被设为 1，且 DBWR_IO_SLAVES 可被设为n，其中 n的值必须设置为 (2 * 独立磁盘驱动器数量/卷)竞争优化多数与 Oracle 有关的竞争问题可以通过主动配置管理相关的初始化参数进展。不恰当地配置 init.ora 中的锁参数可能引起竞争。为了不打破其中的平衡，所需的参数

55、可进展配置并主动得以处理。包括表在的数据库对象可能存在两个竞争点。第一个是所配置的freelists的数量 (缺*值为 1)。freelist 构造维护着表中可用于插入的块。对于存在大量同步插入的表，有必要配置该构造。为了以主动方式处理freelist 竞争，必须在建立表时配置 FREELISTS。可考虑的最正确值为 (2 * CPU数量) 。V$WAITSTAT 不可能指示存在 freelist 竞争，除非存在 freelist 组，而这种设置只存在于 Oracle Parallel Server 中。即便如此，也无法了解哪个表存在竞争中。主动式的 freelist 竞争调优可以事先预防问题

56、出现。资源竞争的第二个来源与索引有关，即对象块头中配置的事务槽数量。事务槽是块头中的区域，是事务处理进程采用自身识别号进展注册，以便任何被修改的更能够通过特定事务槽数量在低层得以识别的地方。如果所有现存的事务槽已经被其它事务占用，效劳器器进程会从块的 PCTFREE 中请求 23 个字节，建立一个新的槽。这种情况适用于存在大量同步事务的对象。对于事务槽的竞争，需要设置 INITRANS 参数。对于块大小为 8K 的数据库，多数情况下，4 为最正确设置，占用的空间仅为 92 字节，却可以大大减少运行时故障和性能问题。数据库备份恢复为了保证客户数据库系统的数据平安性，降低各种故障、灾难给客户带来的

57、数据丧失，根据客户系统实际情况，协助客户规划实施符合客户工作要求的完善的备份恢复方案，以确保客户数据库系统的平安可靠运行。数据库的恢复与备份主要有以下几点：恢复管理器(RMAN)，能使备份恢复操作自动化Oracle 数据泵，用以数据库的逻辑备份用户管理允许用户通过操作系统命令手动备份数据库。各种各样的其他的数据库备份和恢复软件，增强了 Oracle 的备份实用程序Oracle 备份时应考前须知：当数据库处于运行状态时的热备份时，不备份活动事务；使用比方 Oracle 工具Oracle RAMN或者其他的第三方软件IBM/Tivoli的数据存储管理器压缩 Oracle 备份数据；如果维持数据存储

58、空间比备份和恢复数据库时间更重要的话，可以考虑使用二进制压缩。查看Oracle数据库备份结果查看 Oracle 数据库备份结果，是日常运维中必不可少的一个环节。包含：查看数据库备份日志信息，查看 backup 卷中文件产生的时间，查看 oracle 用户的 email，总共三个局部。查看数据库备份日志信息假设：备份的临时目录为/backup/hotbakup，我们需要查看 2012 年 7 月 22日的备份结果，则用下面的命令来查看：#cat /backup/hotbackup/hotbackup-09-7-22.log|grep i error备份脚本的日志文件为 hotbackup-月份-

59、日期-年份.log，在备份的临时目录下面。如果文件中存在ERROR:，则说明备份没有成功，存在问题需要查看。查看backup卷中文件产生的时间#ls lt /backup/hotbackupbackup 卷是备份的临时目录，查看输出结果中文件的日期，都应当是在当天凌晨由热备份脚本产生的。如果时间不对则说明热备份脚本没执行成功。查看oracle用户的email#tail n 300 /var/mail/oracle热备份脚本是通过 Oracle 用户的 cron 去执行的。cron 执行完后操作系统就会发一条 Email 通知 Oracle 用户任务已经完成。查看 Oracle email 中今

60、天凌晨局部有无 ORA-，Error，Failed 等出错信息，如果有则说明备份不正常。数据库迁移数据迁移是日常运维过程中存在的一个必不可少的应急方案。日常维护过程中，由于硬件的原因或其它一些外在因素需要对数据进展迁移，迁移到更加高级的主机上、迁移到远程的机房上、迁移到不同的平台下等等一些情况。对于数据迁移我公司有非常成熟的方案，从以下几种方式我们可以充分了解其优缺点：e*p/imp：这也算是最常用最简单的方法了，一般是基于应用的 owner 级做导出导入；优点是可以跨平台使用；缺点是停机时间长，停机时间为从 e*p 到网络传输到新库，再加上imp 的时间；存储迁移：这种情况下，数据文件、控制