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

软件项目维护方案

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 stee
3.1.2. 开启 LifeKeeper
a) 开启LifeKeeper 服务器进程
假如目前您系统没有运行 LifeKeeper 则在全部服务器上以root用户身份输入以下命令
# /opt/LifeKeeper/bin/lkstart
b) 开启LifeKeeper GUI服务器进程
一样以root用户运行命令
# /opt/LifeKeeper/bin/lkGUIserver start
注意：以上命令只需运行一次，以后每次系统重新开启时，LifeKeeper会自动运行上述进程
3.1.3. 相关LifeKeeper软件其它管理任务
a) 停止 LifeKeeper 服务
假如需要在服务器上永久停止LifeKeeper服务，能够输入下列命令
$LKROOT/bin/lkstop
该命令同时会使全部LifeKeeper保护资源处于退出服务状态，假如期望在停止LifeKeeper时保持资源/应用运行，能够使用：
$LKROOT/bin/lkstop -f
b) 查看 LifeKeeper 进程
键入下列命令能够查看目前运行全部 LifeKeeper 进程列表
ps -ef | grep LifeKeeper

3.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
默认实施线程为25
200
在管理控制台修改默认实施队列线程数步骤以下：
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 8192

3.3.2. 维护管理
3.3.2.1. 开启weblogic server
n 开启管理服务器：实施startAdmserver.sh
n 开启被管理服务器：实施startManagedWebLogic.sh servername adminurl
3.3.2.2. 停止weblogic server
n 停止被管理服务器：实施stopWebLogic.sh servername
n 开启被管理服务器：实施stopWebLogic.sh
3.3.2.3. 登录和退出管理控制台
n 管理服务器开启后能够在浏览器中登录管理控制台
n 输入URL：http://hostname:port/console或https://hostname:port/console
l hostname：管理服务器ip地址或DNS名
l port：管理服务器监听端口
l 假如管理服务器开启时使用SSL，则使用https访问管理控制台
n 在弹出窗口“Console Login“中输入用户名和密码登录

3.3.2.4. 性能监控
n 查看性能参数
l 登录控制台后点击Servers-servername-Monitoring-Performance

n 参数分析
n 1)Idle Threads && Queue Length && Throughout
正常情况下 idle threads >0 ，queue Length为0，Throughout呈不规则改变曲线，Memory Usage呈适度频度锯齿改变曲线。
通常来说，对于正常配置生产环境（线程数50~200），假如idle threads <10，或展现不停降低趋势，就应加以关注；
空闲线程数和队列长度通常有以下关系：
A、假如空闲线程数>0 ，则 queue length =0 ；
B、反之，假如queue length>0 ，则空闲线程数=0 ；
n 2)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 80
set lines 120
col event for a40
select 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 240
SET VERIFY OFF
COLUMN SID FORMAT 999
COLUMN PID FORMAT 999
COLUMN S_# FORMAT 999
COLUMN USERNAME FORMAT A9 HEADING "ORA USER"
COLUMN PROGRAM FORMAT A29
COLUMN SQL FORMAT A60
COLUMN OSNAME FORMAT A9 HEADING "OS USER"
SELECT 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 AND
S.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百分比
SQL>SELECT 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百分比
SQL>SELECTSUBSTR(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语句获取
SQL>SELECT SQL_TEXT FROM (SELECT * FROM V$SQLAREA ORDER BY DISK_READS)
WHERE ROWNUM<=5 desc;
3.4.1.1.7. 查找前十条性能差sql
SELECT * FROM (SELECT PARSING_USER_ID
EXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS,
SQL_TEXT FROM V$SQLAREA ORDER BY DISK_READS DESC)
WHERE ROWNUM<10 ;
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. 查看运行很久SQL
COLUMN USERNAME FORMAT A12
COLUMN OPNAME FORMAT A16
COLUMN PROGRESS FORMAT A8
SELECT USERNAME,SID,OPNAME,ROUND(SOFAR*100 / TOTALWORK,0) || '%' AS
PROGRESS,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 999999
col username for a10
col schemaname for a10
col osuser for a16
col machine for a16
col terminal for a20
col owner for a10
col object_name for a30
col object_type for a10
select sid,serial#,username,SCHEMANAME,osuser,MACHINE,
terminal,PROGRAM,owner,object_name,object_type,o.object_id
from dba_objects o,v$locked_object l,v$session s
where 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
3.4.1.1.11. 查看数据库cpu、I/O、内存性能
统计数据库 cpu 使用、IO、内存等使用情况，使用 vmstat,iostat,sar,top等命令进行信息搜集并查看这些信息，判定资源使用情况。
n CPU 使用情况：
[root@sale8 ~]# top
top - 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 buffers
Swap: 8385920k total, 665576k used, 7720344k free, 10358384k cached
PID USER
30495 oracle
32501 oracle
32503 oracle

注意上面加粗字体部分，此部分内容表示系统剩下 cpu，当其平均值下降至 10%以下时视为 CPU 使用率异常，需统计下该数值，并将状态记为异常
n 内存使用情况：
# free -m
Totalusedfreesharedbufferscached
Mem:202656
-/+ buffers/cache: 326 1700
Swap: 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. 查看行链接/迁移
Sql>select table_name,num_rows,chain_cnt From dba_tables Where owner='CTAIS2' Andchain_cnt<>0;
注：含有 long raw 列表有行链接是正常 ,找到迁移行保留到chained_rows 表中 , 如没有该表实施 ../rdbms/admin/utlchain.sql
Sql>analyze table tablename list chained rows;
可经过表 chained_rows 中table_name,head_rowid看出哪些行是迁移行如:
Sql>create table aa as selecta.* from sb_zsxx a,chained_rows b where a.rowid=b.head_rowid andb.table_name ='SB_ZSXX';
sql>delete from sb_zsxx where rowid in (selecthead_rowid from chained_rows where table_name = 'SB_ZSXX');
sql>insertinto sb_zsxx select * from chained_row where table_name = 'SB_ZSXX';
3.4.1.1.14. 定时做统计分析
对于采取 Oracle Cost-Based-Optimizer 系统，需要定时对数据对象统计信息进行采集更新，使优化器能够依据准备信息作出正确 explain plan。
在以下情况更需要进行统计信息更新：
应用发生改变；
大规模数据迁移、历史数据迁出、其它数据导入等；
数据量发生改变。
查看表或索引统计信息是否需更新，如：
Sql>Select table_name,num_rows,last_analyzed From user_tables wheretable_name ='DJ_NSRXX'
sql>select count(*) from DJ_NSRXX 如 num_rows 和 count(*)假如行数相差很多,则该表需要更新统计信息，提议一周做一次统计信息搜集，如：
Sql>exec 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 代码优化来处理。任何应用优化过程，不外乎是索引优化、全表扫描、并行机制改善和选择正确数据组合方法过程。这正是要达成最好应用性能所必需考虑原因。没有 SQL 优化，就无法实现高性能应用。良好 SQL 语句能够降低 CPU资源消耗，提升响应速度。同时，优化后 SQL 语句还能够提升应用可扩展性，这是除增加大量内存外，任何其它硬件手段也无法实现。
3.4.1.2.2.1. I-O 优化
I-O 优化是系统优化中一个关键步骤，还包含到其它任务，将文件在不一样驱动器/卷中进行分布，采取优化分区技术、确定 I-O 子系统瓶颈、确定控制器瓶颈并依据应用类型选择最好 RAID 级。I-O