1、 软件项目维护方案1. 项目背景及目标1.1.项目背景在国家政策的指导和帮助下，信息化也越来越发挥出十分重要的作用。XXXX 不断加大信息化管理工作力度，积极实施“上网工程” ，大力推进全市局域网建设，加快办公自动化系统进程，信息技术在改革中发挥了重要的支撑作用，为充分发挥政府公共职能，促进依法理财、科学理财，提供了重要的信息技术保障。近年来建设各系统随着数据量的逐年增加，陆续出现了性能问题，有必要进行数据库系统的升级及性能优化，以确保应用系统的正常运行，为单位员工提供更好的信息服务。1.2.项目目标 对各系统数据库进行补丁升级服务，安装补丁前制定详细的升级计划和应急回退计划。 完成各系统数据
2、库的性能调优工作。 各业务持续性得到有效的保证。2. 需求分析XXXXXXX 项目，我公司有多年的行业经验。具有对运维服务对象进行适时监测、指标分析、和及时修复的能力。Oracle 产品日常运行维护项目主要从如下几个方面进行：(1). 每天对 ORACLE 数据库的运行状态,日志文件,备份情况,数据库的空间使用情况,系统资源的使用情况进行查看,发现并解决问题。 (2). 每周对数据库对象的空间扩展情况,数据的增长情况进行监控,对数据库做健康查看,对数据库对象的状态做查看。 (3). 查看表空间碎片,提出下一步空间管理计划。对 ORACLE 数据库状态进行一次全面查看。 （4）由于这些数据库系统
3、承载着 XXXX 非常重要的业务系统数据，所以在日常维护中需要非常仔细，每周、每月、每季都需要有相应的巡检记录，需要详细记载以下一些内容： 监控数据库对象的空间扩展情况 监控数据量的增长情况 系统健康查看，查看以下内容: 数据库对象有效性查看 查看是否有危害到安全策略的问题。 查看 alert、Sqlnet 等日志并归档报错日志 分析表和索引 查看对数据库会产生危害的增长速度 查看表空间碎片 数据库性能调整 预测数据库将来的性能 调整和维护工作 后续空间3. 整体运行维护服务方案3.1. Lifekeeper 维护3.1.1. 验证 LifeKeeper 的安装查看已经安装的 LifeKeep
4、er 软件包，可以使用命令：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 软
5、件的其它管理任务a) 停止 LifeKeeper 服务如果需要在服务器上永久停止 LifeKeeper 服务，可以输入下列命令$LKROOT/bin/lkstop该命令同时会使所有 LifeKeeper 保护的资源处于退出服务状态，如果希望在停止 LifeKeeper 时保持资源 /应用的运行，可以使用：$LKROOT/bin/lkstop -fb) 查看 LifeKeeper 进程键入下列命令可以查看当前运行的所有 LifeKeeper 进程列表ps -ef | grep LifeKeeper3.1.4. 启动 LifeKeeperGUI 配置工具进入 LifeKeeper GUI 管理工具
6、可以通过运行命令：/opt/LifeKeeper/bin/lkGUIapp则出现 LifeKeeper 登录界面：可以使用 root 用户登录，也可以使用新建的用户进行登录。3.1.5. 检测 LifeKeeper 集群运行状态可以使用 lcdstatus 命令对 LifeKeeper 集群的当前运行状态进行查看，命令格式：lcdstatus -q -d 该程序向 stdout 输出在 LifeKeeper 资源层次配置状态和通信路径的状态.选项 -q 表示输出采用简略的形式（建议使用该选项）选项d 表示要查看的主机，缺 X 查看本机3.1.6. 管理 LifeKeeper 中的资源注意：如果
7、能运行 LifeKeeper GUI，则使用其提供菜单命令执行相应操作；在执行命令行启动/停止资源前，一定先使用 lcdstatus 命令确认资源的实际状态。a) 启用资源(In-Service)可以使用命令：./perform_action -t -a restore将资源标记名所对应的资源在本机上投入服务（启动） 。如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行的结果相当于执行了一次手工切换！如果该资源在命令使用前是处于停止状态（即在备机上执行本命令） ，则本命令执行的结果相当于执行了一次手工切换b) 停止资源(out-of-service)可以使用命令：./perfo
8、rm_action -t -a remove将资源标记名所对应的资源在本机上停止服务。如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行不产生任何结果注意： 在执行命令行前后，一定先使用 lcdstatus 命令确认资源的当前状态。 命令停止/启动本地的资源 命令中的是区分大小写的 一定要等待命令完成，注意命令的输出。 详细用法见在线帮助手册。3.2. SQL SERVER 维护计算机系统各种软、硬件故障、用户误操作以及恶意破坏是不可避免的,这些影响到数据的正确性甚至造成数据损失、服务器崩溃等致命后果。数据库的备份对保证系统的可靠性具有重要的作用。下面会根据执行强度对维护任务及
9、其相应的程序进行分类描述，执行强度用不同的时间间隔定义，包括每天、每周、每月和每季度，能够建立起良好的维护实务，确保 SQL Server 数据库性能和安全。3.2.1. 每天的例行维护任务需要数据库管理员密切关注的维护任务，最好每天都查看一下，这样可以确保系统的可靠性、可用性、运行性能和安全。每天的例行维护任务包括：1、查看是不是所有被请求的 SQL Server 服务都正常运行。2、查看日常备份日志中成功、警告或者失败记录。3、查看 Windows 事件日志有没有错误记录。4、查看 SQL Server 日志有没有安全警告记录，例如非法登录。5、执行完全备份或差异备份。6、在设置了完全恢复
10、模型或大容量日恢复模型的数据库上执行事务日志备份任务。7、核实 SQL Server 作业没有失败。8、查看所有的数据库文件和事务日志具有合适的磁盘空间大小。9、至少要监控处理器、内存或者磁盘计数器没有出现瓶颈。3.2.2. 每周的例行维护任务关注程度稍逊于每天的例行维护任务，最好每周进行一次例行查看。每周的例行维护任务包括：1、执行完全备份或差异备份。2、查看以前执行的维护计划报告。3、查看数据库完整性。4、如果需要，执行收缩数据库任务。5、通过重新组织索引任务压缩聚集和非聚集表和视图。6、通过重新生成索引任务在数据页和索引页重新组织数据。7、更新所有用户表和系统表的统计信息8、清除备份、还
11、原、SQL Server 代理作业和维护计划等操作的历史数据。9、如果需要，手动增长数据库或事务日志文件10、清除执行维护计划残留下来的文件。3.2.3. 每月或每季度的维护任务有一些维护计划不需要执行得过于频繁，可以每个月或每个季度执行一次。但是请不要以为这些任务不需要天天执行就无足轻重，这些任务可以确保数据库环境的健康，所以不要轻视以下这些维护任务：1、在测试环境中执行备份还原操作。2、将历史数据归档。3、分析收集的性能统计数据，与基准值相比较。3、查看并更新维护文档。4、查看并安装最新的 SQL Server 补丁和补丁包。5、如果运行簇、数据库镜像或日志传送，则监测故障转移。6、验证备
12、份和还原进程是否遵循已定义的服务等级协议。7、更新 SQL Server 构建指南。8、更新 SQL Server 灾难恢复文档。9、更新维护计划列表10、修改管理员口令。11、修改 SQL Server 服务帐户口令。3.3. WebLogic 维护3.3.1. 性能调优3.3.1.1. 设定执行队列的溢出条件Weblogic Server 提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，并且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。通过启动管理控制台，在域（如：mydomain） 服务器 serv
13、er 实例（如：myserver） Execute Queue weblogic.kernel.Defalt 配置下面几项： 队列长度：此值表示执行队列中可容纳的最大请求数，默认值是 65536，最后不要手动改变此值。 队列长度阈值百分比：此值表示溢出条件，在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。 线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU 和内存不是足够的高，尽量不要改变默认值“0” 。因为 Weblogic 一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。 最大线程数：为了防止创建过多的线程数量
14、，可以通过设定最大的线程数进行控制。 在实际的应用场景中，应根据具体情况适当的调整以上参数。 3.3.1.2. 设定队列监测行为Weblogic Server 能够自动监测到当一个执行线程变为“阻塞” 。变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态，Weblogic server 可能改变状态为“警告”或“严重”状态。如果 Weblogic server 变为“ 严重”状态，可以通过 Node Manager 来自动关闭此服务器并重新启动它。具体请参考：Node Manager Capabilities 文档。 通过启动管理
15、控制台，在域（如：mydomain） 服务器 server 实例（如：myserver）配置 调整下可配置下面几项： 阻塞线程最长时间：在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作 600 秒后成为阻塞线程。 阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了“阻塞线程最长时间“ 字段中指定的时间长度的间隔时间(秒) 。默认情况下，WebLogic Server 将此时间间隔设置为 600 秒。 3.3.1.2.1. 尽量使用本地 IO 库WebLogic Serv
16、er 有两套套接字复用器：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. 调整默认执行
17、线程数名称 开发模式 产品模式 推荐个数Execute Queues 默认的执行线程为 15 默认的执行线程为 25 200在管理控制台修改默认执行队列线程数的步骤如下： 如果管理服务器没有运行，先启动。 访问管理控制台。 展开左边面板的 Servers 节点，显示 Server 列表。 右击 Server，在弹出菜单中选择 View Execute Queues ，就会在右边面板显示有执行队列的表用来修改。 注意：你只能修改默认的执行队列或者用户定义的执行队列。 在 Name 列，直接点击默认执行队列名称，显示配置标签用来修改执行队列数。 填下适当的线程数。 点击 Apply，保存刚才的修改
18、。 重启 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 线程数的设置和数据库进程数,游标的大小。
19、通常我们在一个线程中使用一个连接, 所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致；值等于WebLogic Server 的执行线程数。3.3.1.3.3. 其他配置尽管 JDBC Connection Pool 提供了很多高级参数,在开发模式下比较有用, 但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时 Test Reserved Connections 和 Test Released Connections 也无需勾上。当然如果你的数据库不稳定, 时断时续, 你就可能需要上述的
20、参数打开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
21、 对性能也有帮助。此外，还可以对 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
22、.1. 启动 weblogic server 启动管理服务器：执行 startAdmserver.sh 启动被管理服务器：执行 startManagedWebLogic.sh servername adminurl3.3.2.2. 停止 weblogic server 停止被管理服务器：执行 stopWebLogic.sh servername 启动被管理服务器：执行 stopWebLogic.sh3.3.2.3. 登录和退出管理控制台 管理服务器启动后可以在浏览器中登录管理控制台 输入 URL：http:/hostname:port/console 或 https:/hostname:por
23、t/console hostname：管理服务器的 ip 地址或 DNS 名 port：管理服务器监听的端口 如果管理服务器启动时使用 SSL，则使用 https 访问管理控制台 在弹出的窗口“Console Login“中输入用户名和密码登录3.3.2.4. 性能监控 查看性能参数 登录控制台后点击 Servers-servername-Monitoring-Performance 参数分析 1)Idle Threads 如果数据库长时间持续出现大量像 latch free，enqueue，buffer busy waits，db file sequential read，db file s
24、cattered 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 USER“COLUMN PROGRAM FORMAT A29COLUMN SQL FORMAT A60COLUMN OSNAME FORMAT A9 HEADING “OS USER“SELECT P.PID PI
25、D,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 %3.4.1.1.3. 查看碎片程度高的表SQL SEL
26、ECT 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,
27、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.
28、1.1.6. Disk Read 最高的 SQL 语句的获取SQLSELECT SQL_TEXT FROM (SELECT * FROM V$SQLAREA ORDER BY DISK_READS)WHERE ROWNUM 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 t
29、erminal 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 级
30、kill 掉该 session：alter system kill session 操作系统级 kill 掉 session：#kill -9 pid3.4.1.1.11.查看数据库 cpu、I/O、内存性能记录数据库的 cpu 使用、 IO、内存等使用情况，使用 vmstat,iostat,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 ru
31、nning, 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注意上面的加粗字体部
32、分，此部分内容表示系统剩余的 cpu，当其平均值下降至 10%以下的时视为 CPU 使用率异常，需记录下该数值，并将状态记为异常 内存使用情况：# free -m TotalusedfreesharedbufferscachedMem:20261958670761556-/+ buffers/cache: 326 1700Swap: 5992 92 5900如上所示，total 表示系统总内存，used 表示系统使用的内存，free 表示系统剩余内存，当剩余内存低于总内存的 10%时视为异常。 系统负载情况：#uptime 12:08:37 up 162 days, 23:33, 15 use
33、rs,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 db
34、a_tables Where owner=CTAIS2 Andchain_cntanalyze 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_
35、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。在以下情况更需要进行统计信息的更新：应用发生变化；大规模数据迁移、历史数据迁出、其他数据的导入等；数据量发生变化。查看表或索引的
36、统计信息是否需更新，如：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
37、 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. 性能调优及方法性能调优主要有主动调优和被动调优，主动调优在前面我们已经进行了阐述，被动调优主要有以下方法进行。 确定合理的性能优化目标 测试并记录当前的性能指标 确定当前存在的 Oracle 性能瓶颈 (Oracle 中何处存在等待，哪个 SQL 语句与此有关) 确定
38、当前的操作系统瓶颈 优化相关的组件 (应用、数据库、I/O 、连接 OS 及其它) 跟踪并实施变化管理制度 测试并记录目前的性能指标 重复第 3 到第 7 步直至达到既定的优化目标不要对并非性能瓶颈的部分进行优化，否则可能引起额外的问题。正如任何聪明的人会告诉你的：“如果还未坏，千万不要修” 。更重要的是，一旦既定的优化目标已经达到，就务必停止所有的优化。获取 Oracle 的性能指标 (测试前及测试后)必须在峰值处理时测试并获取系统在优化前和优化后的性能指标。数据采集不应在数据库 instance 刚刚起动后进行。同时，测试数据应在峰值期间每过 15 分钟进行一次。初始化参数TIMED_ST
39、ATISTICS 应该被设为 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，找出引起或经历等
40、待事件的进程。最后一步是通过v$session_wait 获得事件的细节。同时，应该进一步通过 OS 进行深入分析，了解核心的 CPU、内存和 IO 状态参数。最后，结合两种不同的诊断的结论，找出系统瓶颈所在。3.4.1.2.2. 应用优化从统计(和现实) 的角度看，80% 的 Oracle 系统性能问题可以通过 SQL 代码优化来解决。任何应用优化的过程，不外乎是索引优化、全表扫描、并行机制改进和选择正确数据组合方法的过程。这正是要达到最佳应用性能所必须考虑的因素。没有 SQL 的优化，就无法实现高性能的应用。良好的 SQL 语句可以减少 CPU 资源的消耗，提高响应速度。同时，优化后的 S
41、QL 语句还可以提高应用的可扩展性，这是除增加大量内存外，任何其它硬件手段也无法实现的。3.4.1.2.2.1. I-O 优化I-O 优化是系统优化中的一个关键步骤，还涉及到其它任务，将文件在不同驱动器/卷中进行分布，采用优化分区技术、确定 I-O 子系统瓶颈、确定控制器瓶颈并根据应用的类型选择最佳的 RAID 级。I-O 优化应该在全面了解 Oracle 及Oracle RDBMS 结构之后进行。应该在进行 I-O 优化前后实施 I-O 数据监控，如平均服务时间，IOPS，平均磁盘队列长度等。3.4.1.2.2.2. O-S 监控数据库忙时，应该对操作系统进行监控，因为操作系统的性能指标会揭
42、示数据库活动的性质及其对系统的影响。例如，为了了解 CPU 的利用率，可以通过system activity reporter (sar u interval frequency) 、 mpstat (SunSolaris), top (多数 UNIX)、 osview (SGI Irix) 及 vmstat 等命令。 Sar 和 vmstat 也可被用于确定包括内存使用率、I-O 参数、队列等待、读取 /交换区活动等信息。在 Solaris 上，mpstat utility 也可用于获取前面提到的 CPU 利用率数据。Solaris 上的 Adrian 性能管理工具也很有用。可以利用其中的一
43、到多个工具来确定系统的性能状况，找出可能存在的瓶颈。Oracle 数据库性能的管理需要遵循系统的方法论，以确保所有核心问题得以解决。多数问题可以事先得以管理。了解与 O-S 相关的问题是成功的关键。勿需置疑，系统硬件配置上的良好平衡也是至关重要的。必须承认， 80% 的系统性能问题可以通过书写更好的 SQL 语句来解决。来文试图探究其余 20%中可能覆盖的内容。同时，必须遵守严格的规定，在调优目标达到后终止所有努力。了解自己想到何处是重要的，更重要的是，要知道自己何时到达了目的地。3.4.1.2.2.3. 例程调优 需要配置的主要初始化参数以下是一些已知与例程优化关系最密切的一些核心 Orac
44、le 初始化参数。它们都会影响 Oracle 及 SGA 区的活动。任何对这些参数的改动，在实施到生产环境之前，都必须进行测试。一旦改变了生产环境的参数，就必须对相关的 Oracle 动态性能指标和操作系统的性能进行监测，寻找可能由此产生的异常现象。1) DB_BLOCK_SIZE该参数在数据库建立前设定，决定了数据库中每个数据块的大小。只有重新建立数据库，才有可能改变该参数。db_block_size 的配置应遵循以下公式：DB_BLOCK_SIZE = FILESYSTEM BLOCKSIZE = O-S PAGESIZE 这可以确保 Oracle 获得最佳 I/O 性能，同时不会由于冗余
45、或不必要的 I/O，给 I/O 子系统带来压力。2) DB_BLOCK_BUFFERS该参数决定了 SGA 区数据库缓冲区中的块数量。由于这是 Oracle 读取和写入的区域，它的不正确配置会引起严重的 I/O 性能问题。尽管缓冲区的大小与应用性质、数据库大小、同步用户数等无关，它的确是 SGA 区中最大的组件。经常可以看到缓冲区占用 75-80%SGA 区内存的情况。另外，这一参数设置过大，也会引起整个系统的内存不足，引起操作系统过多的读写操作。该参数及 SHARED_POOL_SIZE 通常是两个最重要的 SGA 优化目标。只有当数据库缓冲率长时间低于 70%时，才需要增加其大小说。即使在
46、这种情况下，也需要进一步审查应用的性能和整个系统的吞吐性。若存在延迟性的应用设计问题，则无论数据库缓冲区的大小如何，缓冲和读写率都不会有太大改变为。在实调优中，也曾发现由于 SQL 语句的问题，出现缓冲率很高，但仍存在全系统性能问题的情况。3)SHARED_POOL_SIZE该参数按字节数设定，定义了 SGA 中共享区的大小。该组件的大小严重依赖于应用的类型 (即该应用是重用 SQL，还是生成动态 SQL，等等)。同时它也取决于同步用户的数量，以及实例是否被配置成支持多线程服务器(MTS)。如果该应用采用了 MTS 配置，则共享区应该明显增加，因为光标状态和用户进程数据等程序全局区域(PGA)
47、都被置入了共享区。有关多数应用的 SHARED_POOL_SIZE 大小设置，可以从每 10 个同步用户 16 MB 共享区开始。这不是一成不变的，因为应用的性质最终会决定该组件的大小。只有当库缓冲和字典缓冲使用率一直低于 90%时，才需要关注这一参数。但如果应用并未采用变量合并和/共离图标时，内存的数量并不会使缓冲使用率高于 90%。共享区过大会导致处理时间增加，甚至 SQL 语句的挂起。如果应用不能有效地重用 SQL，则无论配置多大的库缓冲或字典缓冲都无济于事，不能改善缓冲使用率。另一个值得考虑的因素是需要随时使用的存储 PL/SQL 代码数量。应用的核心包可以通过查看 DBA_SOURC
48、E、USER_SOURCE 得以确认，其大小通过查询DBA_OBJECT_SIZE 了解。另外，为了确定存储 PL/SQL 是否被置于内存，可以查询动态性能视图 V$DB_OBJECT_SIZE。内时，包 DBMS_SHARED_POOL 中的程序大小可被用于确定应用中大包的规模。4) LOG_BUFFER根据字节设定，该参数定义了 SGA 缓冲区中 redo log 的大小。缺 X 值通常是数据库块大小的四倍，这对于多数环境并不是最佳的。对于中型的 Oracle 环境，其结构应该为 512 Kb 左右。对该存储结构而言，更大并不意味着更好。超过 1 MB 就可能有问题。需要监控 V$SESS
49、ION_WAIT 中 log buffer space 的等待事件，优化该内存结构。需要提醒的是，在线 redo log 文件的大小设置不当，会引起 redo 请求的等待。5) DB_WRITERS该参数可以针对所有文件系统支持，且不可使用 Direct I-O 的 Oracle 实施设定。这并不需要与 raw partitions 一起使用，因为异步 I-O 更加。建议将该参数设定为(2 * 独立磁盘驱动器数量/ 卷) 。该参数只有在 report.txt 中的“average write queue length”持续高于 1 时，才需要设定。在 Oracle 8.0 和更高版本中，该参数已不再被支持，而为其它两个名为 DB_WRITER_PROCESSES 和DBWR_IO_SLAVES 的参数取代。若需要设置 DB_WRITER_PROCESSES 值高于 8，则 DB_WRITER_PROCESSES 可被设为 1，且 DBWR_IO_SLAVES 可被设为“n”，其中 n 的值必须设置为 (2 * 独立磁盘驱动器数量/卷)3.
